DeforaNetworks/pentext
3
0
Fork 0
Code Releases Activity
Files
bd555ff841f0a89d780fb0a901688acfef173f8d
pentext/xml/target/document.fo

1002 lines
149 KiB
XML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8"?><fo:root xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:fo="http://www.w3.org/1999/XSL/Format" line-height-shift-adjustment="disregard-shifts"><fo:layout-master-set><fo:simple-page-master margin-top="2cm" margin-bottom="1.8cm" margin-left="2cm" margin-right="2cm" page-height="29.7cm" page-width="21.0cm" master-name="Cover"><fo:region-body margin-top="1cm" margin-bottom="1cm" region-name="region-body"/><fo:region-before precedence="true" extent="0.6cm" region-name="region-before-cover"/><fo:region-after precedence="true" extent="0.6cm" padding="0" region-name="region-after-cover"/></fo:simple-page-master><fo:simple-page-master margin-top="2cm" margin-bottom="1.8cm" margin-left="2cm" margin-right="2cm" page-height="29.7cm" page-width="21.0cm" master-name="Content"><fo:region-body margin-top="1cm" margin-bottom="1cm" region-name="region-body"/><fo:region-before precedence="true" extent="0.6cm" region-name="region-before-content"/><fo:region-after precedence="true" extent="0.6cm" padding="0" region-name="region-after-content"/></fo:simple-page-master><fo:page-sequence-master master-name="Report"><fo:repeatable-page-master-alternatives><fo:conditional-page-master-reference master-reference="Cover" blank-or-not-blank="not-blank" page-position="first"/><fo:conditional-page-master-reference master-reference="Content" blank-or-not-blank="not-blank"/></fo:repeatable-page-master-alternatives></fo:page-sequence-master></fo:layout-master-set><fo:page-sequence master-reference="Report"><fo:static-content font-family="LiberationSansNarrow" font-size="12pt" color="black" flow-name="region-before-cover"><fo:block text-align="right" font-weight="bold"/></fo:static-content><fo:static-content font-family="LiberationSansNarrow" font-size="12pt" color="black" flow-name="region-before-content"><fo:block text-align="right" font-weight="bold"/></fo:static-content><fo:static-content font-family="LiberationSansNarrow" font-size="12pt" color="black" flow-name="region-after-cover"><fo:block text-align-last="justify"><fo:page-number/>/<fo:page-number-citation ref-id="EndOfDoc"/><fo:leader leader-pattern="space"/><fo:inline font-family="LiberationSansNarrow" font-size="8pt" color="black">Radically Open Security B.V. - Chamber of Commerce
60628081</fo:inline></fo:block></fo:static-content><fo:static-content font-family="LiberationSansNarrow" font-size="12pt" color="black" flow-name="region-after-content"><fo:block text-align-last="justify"><fo:page-number/>/<fo:page-number-citation ref-id="EndOfDoc"/><fo:leader leader-pattern="space"/><fo:inline font-family="LiberationSansNarrow" font-size="8pt" color="black">Radically Open Security B.V. - Chamber of Commerce
60628081</fo:inline></fo:block></fo:static-content><fo:flow font-family="LiberationSansNarrow" font-size="12pt" color="black" flow-name="region-body"><fo:block>
<fo:block text-align="center" margin-bottom="5pt"><fo:external-graphic padding-top="2cm" padding-bottom="3cm" src="url(../graphics/logo.png)" width="70mm" content-width="scale-to-fit" content-height="scale-to-fit" scaling="uniform"/></fo:block><fo:block keep-with-next.within-page="always" font-weight="bold" text-align="center" font-size="16pt" margin-bottom="1cm" background-color="orange">OMEMO: CRYPTOGRAPHIC ANALYSIS REPORT</fo:block><fo:block keep-with-next.within-page="always" font-weight="bold" text-align="center" font-size="16pt" margin-bottom="6cm" background-color="silver" text-transform="capitalize">For PACIFIC RESEARCH ALLIANCE</fo:block><fo:block break-after="page"><fo:table width="100%" table-layout="fixed"><fo:table-column column-width="proportional-column-width(66)"/><fo:table-column column-width="proportional-column-width(33)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block/></fo:table-cell><fo:table-cell text-align="left"><fo:block> V1.0</fo:block><fo:block>Amsterdam</fo:block><fo:block>June 1st, 2016</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:block><fo:block keep-with-next.within-page="always" font-weight="bold" margin-bottom="5pt">Document Properties</fo:block><fo:block margin-bottom="1.5cm"><fo:table border-width="1pt" border-style="solid" border-color="black" width="100%" table-layout="fixed"><fo:table-column background-color="orange" border-width="1pt" border-style="solid" border-color="black" column-width="proportional-column-width(25)"/><fo:table-column column-width="proportional-column-width(75)"/><fo:table-body><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Title</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>OMEMO: CRYPTOGRAPHIC ANALYSIS REPORT</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Version</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>1.0</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Author</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block><fo:inline>Sebastian Verschoor</fo:inline></fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Reviewed by</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block><fo:block>Melanie Rieback</fo:block></fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Approved by</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Melanie Rieback</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:block><fo:block keep-with-next.within-page="always" font-weight="bold" margin-bottom="5pt">Version control</fo:block><fo:block margin-bottom="1.5cm"><fo:table border-width="1pt" border-style="solid" border-color="black" width="100%" table-layout="fixed"><fo:table-column border-width="1pt" border-style="solid" border-color="black" column-width="proportional-column-width(25)"/><fo:table-column border-width="1pt" border-style="solid" border-color="black" column-width="proportional-column-width(25)"/><fo:table-column border-width="1pt" border-style="solid" border-color="black" column-width="proportional-column-width(25)"/><fo:table-column border-width="1pt" border-style="solid" border-color="black" column-width="proportional-column-width(25)"/><fo:table-body><fo:table-row background-color="orange" border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Version</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Date</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Author</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Description</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block> 0.1</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>May 10th, 2016</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block><fo:inline>Sebastian Verschoor</fo:inline></fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Initial draft</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block> 0.2</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>May 11th, 2016</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block><fo:inline>Sebastian Verschoor</fo:inline></fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Conversations developer fixed the issue I found</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block> 0.3</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>June 1st, 2016</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block><fo:inline>Sebastian Verschoor</fo:inline></fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Changed client organisation</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>1.0</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>June 1st, 2016</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block><fo:inline>Sebastian Verschoor</fo:inline></fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Final version</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:block><fo:block keep-with-next.within-page="always" font-weight="bold" margin-bottom="5pt">Contact</fo:block><fo:block margin-bottom="5pt">For more information about this Document and its
contents please contact Radically Open Security B.V.</fo:block><fo:block break-after="page"><fo:table border-width="1pt" border-style="solid" border-color="black" width="100%" table-layout="fixed"><fo:table-column background-color="orange" border-width="1pt" border-style="solid" border-color="black" column-width="proportional-column-width(25)"/><fo:table-column column-width="proportional-column-width(75)"/><fo:table-body border-width="1pt" border-style="solid" border-color="black"><fo:table-row><fo:table-cell padding="2pt"><fo:block>Name</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Melanie Rieback</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Address</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>Overdiemerweg 28</fo:block><fo:block>1111 PP Diemen</fo:block><fo:block>The Netherlands</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Phone</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>+31 6 10 21 32 40</fo:block></fo:table-cell></fo:table-row><fo:table-row border-width="1pt" border-style="solid" border-color="black"><fo:table-cell padding="2pt"><fo:block>Email</fo:block></fo:table-cell><fo:table-cell padding="2pt"><fo:block>info@radicallyopensecurity.com</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:block>
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="16pt" margin-bottom="0cm" background-color="orange" padding-right="3pt">Table of Contents</fo:block><fo:block break-after="page">
<fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="introduction"><fo:inline>1</fo:inline>  Introduction</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="introduction"><fo:page-number-citation ref-id="introduction"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="terminology"><fo:inline>1.1</fo:inline>  Terminology</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="terminology"><fo:page-number-citation ref-id="terminology"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="attackermodel"><fo:inline>1.2</fo:inline>  Attacker Model</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="attackermodel"><fo:page-number-citation ref-id="attackermodel"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="attackergoals"><fo:inline>1.2.1</fo:inline>  Attacker Goals</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="attackergoals"><fo:page-number-citation ref-id="attackergoals"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="attackercapabilities"><fo:inline>1.2.2</fo:inline>  Attacker capabilities</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="attackercapabilities"><fo:page-number-citation ref-id="attackercapabilities"/></fo:basic-link></fo:block>
<fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="protocolanalysis"><fo:inline>2</fo:inline>  Protocol Analysis</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="protocolanalysis"><fo:page-number-citation ref-id="protocolanalysis"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="signalprotocol"><fo:inline>2.1</fo:inline>  Signal Protocol</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="signalprotocol"><fo:page-number-citation ref-id="signalprotocol"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="protocoldescription"><fo:inline>2.1.1</fo:inline>  Protocol Description</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="protocoldescription"><fo:page-number-citation ref-id="protocoldescription"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="Securityanalysis"><fo:inline>2.1.2</fo:inline>  Security Analysis</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="Securityanalysis"><fo:page-number-citation ref-id="Securityanalysis"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="omemo"><fo:inline>2.2</fo:inline>  OMEMO</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="omemo"><fo:page-number-citation ref-id="omemo"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="Protocoldescription"><fo:inline>2.2.1</fo:inline>  Protocol description</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="Protocoldescription"><fo:page-number-citation ref-id="Protocoldescription"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="Securityanalysis2"><fo:inline>2.2.2</fo:inline>  Security Analysis</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="Securityanalysis2"><fo:page-number-citation ref-id="Securityanalysis2"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="maliciousdevice"><fo:inline>2.2.3</fo:inline>  Malicious device</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="maliciousdevice"><fo:page-number-citation ref-id="maliciousdevice"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="forwardfuturesecrecy"><fo:inline>2.2.4</fo:inline>  Forward/future secrecy</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="forwardfuturesecrecy"><fo:page-number-citation ref-id="forwardfuturesecrecy"/></fo:basic-link></fo:block><fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="OMEMOEncryptedJingleFileTransfer"><fo:inline>2.3</fo:inline>  OMEMO Encrypted Jingle File Transfer</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="OMEMOEncryptedJingleFileTransfer"><fo:page-number-citation ref-id="OMEMOEncryptedJingleFileTransfer"/></fo:basic-link></fo:block>
<fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="codereview"><fo:inline>3</fo:inline>  Code Review</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="codereview"><fo:page-number-citation ref-id="codereview"/></fo:basic-link></fo:block>
<fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="conclusion"><fo:inline>4</fo:inline>  Conclusions/recommendations</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="conclusion"><fo:page-number-citation ref-id="conclusion"/></fo:basic-link></fo:block>
<fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="Acknowledgement"><fo:inline>5</fo:inline>  Acknowledgement</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="Acknowledgement"><fo:page-number-citation ref-id="Acknowledgement"/></fo:basic-link></fo:block>
<fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="References"><fo:inline>6</fo:inline>  References</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="References"><fo:page-number-citation ref-id="References"/></fo:basic-link></fo:block>
<fo:block text-align-last="justify" padding-right="3pt" background-color="orange"><fo:basic-link internal-destination="minorcorrections"><fo:inline> Appendix 1</fo:inline>  Minor corrections</fo:basic-link> <fo:leader leader-pattern="dots" leader-alignment="reference-area" leader-length.maximum="21cm"/> <fo:basic-link internal-destination="minorcorrections"><fo:page-number-citation ref-id="minorcorrections"/></fo:basic-link></fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="introduction">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="16pt" margin-bottom="1cm" background-color="orange"><fo:inline>1</fo:inline>   Introduction</fo:block>
<fo:block margin-bottom="5pt"> The OMEMO protocol is an adaptation of the Signal Protocol, created by Open
Whisper
Systems<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">1 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">1</fo:inline><fo:basic-link color="blue" external-destination="https://whispersystems.org/">https://whispersystems.org/</fo:basic-link></fo:block></fo:footnote-body></fo:footnote>.
OMEMO is designed to work in an XMPP environment <fo:basic-link internal-destination="bib26">[<fo:inline>26</fo:inline>]</fo:basic-link><fo:basic-link internal-destination="bib28">[<fo:inline>28</fo:inline>]</fo:basic-link>,
where users can have multiple devices with which they want to communicate
with each other. An XMPP session can involve multiple servers, instead of
just one Open Whisper Systems server. The impact of multiple servers should
be minimal, as a trusted server was never part of the security model that
guarantees the security of the Signal Protocol.</fo:block>
<fo:block margin-bottom="1.5cm">The predominant part of this report, the protocol security analysis, can be found
in Section 2, in which I analyze the full OMEMO protocol, including the used
Signal protocol and the protocol for encrypted file transfer. Section 3
discusses the results of a brief inspection of the open-source code
<fo:basic-link internal-destination="bib7">[<fo:inline>7</fo:inline>]</fo:basic-link> of the Conversations application <fo:basic-link internal-destination="bib9">[<fo:inline>9</fo:inline>]</fo:basic-link>, as a reference
implementation of the OMEMO specification. Finally, Section 4 provides a
summary of results and my recommendations for the OMEMO standard.</fo:block>
<fo:block margin-bottom="1.5cm" id="terminology">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-style="italic" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>1.1</fo:inline>   Terminology</fo:block>
<fo:block margin-bottom="5pt">OMEMO is a recursive acronym that stands for “OMEMO Multi-End Message and
Object Encryption”. In this report, the term OMEMO refers to the
protocol as specified by its ProtoXEP <fo:basic-link internal-destination="bib29">[<fo:inline>29</fo:inline>]</fo:basic-link>, also
called OMEMO version 0.</fo:block>
<fo:block margin-bottom="5pt">In order to eliminate confusion, Open Whisper Systems has very recently
<fo:basic-link internal-destination="bib20">[<fo:inline>20</fo:inline>]</fo:basic-link> changed the name of their protocol from the
difficult to pronounce “Axolotl” to the “Signal Protocol”. The old
name has been used to refer to both the entire protocol and to refer
to just the ratchet component of the full protocol. The OMEMO
specification was created before this announcement and uses the old
names. This report follows the new terminology: “<fo:inline font-weight="bold">Signal
Protocol</fo:inline>” refers to the full protocol, “Triple
Diffie-Hellman” refers to the initial handshake and “Double Ratchet”
refers to the ratchet algorithm. I recommend that the OMEMO
specification updates their terminology as well.</fo:block>
<fo:block margin-bottom="1.5cm">Throughout this report, I will follow the tradition in cryptographic
literature of naming the end-users Alice and Bob, while reserving
the name Eve to represent the adversary. Note that the end-users
represent persons, not the device (or multiple devices) that they
use.</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="attackermodel">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-style="italic" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>1.2</fo:inline>   Attacker Model</fo:block>
<fo:block margin-bottom="5pt">Section 2 of the OMEMO ProtoXEP lists only a few requirements for the
protocol. From a cryptographic perspective, many basic requirements
are missing, including the basic CIA triad<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">2 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">2</fo:inline>Confidentiality,
Integrity and Availability</fo:block></fo:footnote-body></fo:footnote>. That does not mean that
the protocol does not meet those requirements, it just means that
the specification is not as explicit as it can and should be. This
section aims to extend the requirements to list all security
properties that OMEMO achieves.</fo:block>
<fo:block margin-bottom="1.5cm">To claim that the protocol is secure, a well-defined attacker model is
required in order to specify what the protocol is secure
<fo:inline font-style="italic">against</fo:inline>. By defining the goals that adversaries might
have and defining their capabilities, it becomes clear what the
protocol needs to defend against and which security properties it
should provide to the end-users.</fo:block>
<fo:block margin-bottom="1.5cm" id="attackergoals">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>1.2.1</fo:inline>   Attacker Goals</fo:block>
<fo:block margin-bottom="5pt">The attacker goals are closely tied to the security properties of
the secure messaging protocol. Table 1 lists the different
goals that an attacker might have and the corresponding
security property that a protocol should provide in order to
be considered secure.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Table 1:</fo:inline> Attacker Goals</fo:block>
<fo:block margin-bottom="5pt"><fo:table table-layout="fixed" width="100%"><fo:table-body><fo:table-row keep-with-next.within-column="always">
<fo:table-cell padding="2pt" background-color="orange" border-style="solid" border-color="black" border-width="1pt"><fo:block>Attacker Goal</fo:block></fo:table-cell>
<fo:table-cell padding="2pt" background-color="orange" border-style="solid" border-color="black" border-width="1pt"><fo:block>Security property</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Compromise messages</fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Confidentiality of messages</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Alter sent messages</fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Integrity of messages</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Inject false messages</fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Authenticity of messages</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Identify as another person</fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Authentication of communication partner</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Block communication</fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Availability of communication</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Learn communication metadata </fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Privacy protection</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Prove <fo:inline font-style="italic">what</fo:inline> was said</fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Deniability of message content</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Prove that two persons communicated </fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Deniability of the conversation</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Learn past communication after compromise </fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Forward secrecy</fo:block></fo:table-cell>
</fo:table-row><fo:table-row>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Prolong a successful attack</fo:block></fo:table-cell>
<fo:table-cell padding="2pt" border-style="solid" border-color="black" border-width="1pt"><fo:block text-align="left">Future secrecy</fo:block></fo:table-cell>
</fo:table-row></fo:table-body></fo:table></fo:block>
<fo:block margin-bottom="5pt">Not every attack can be defended against by a secure messaging
protocol. It is especially hard to provide availability when
an attacker is assumed to be able to block messages on the
communications network. Having said that, the protocol
should not make it easy for an attacker to block
communication.</fo:block>
<fo:block margin-bottom="5pt">To protect the privacy of the users, the protocol should not leak
metadata about the users’ communication, such as who they
are communicating with, how many messages they sent and from
where. Communication layers below the secure messaging
protocol might leak this data as well, but it could be
hidden through anonymity tools such as Tor. In that case,
the protocol itself should not reveal any metadata.</fo:block>
<fo:block margin-bottom="5pt">To provide deniability, it should be impossible for anyone to
provide convincing proof to a third party about past
communication. To deny that any conversation ever took place
is a stronger claim than just denying the precise contents
of a message.</fo:block>
<fo:block margin-bottom="1.5cm">Forward secrecy<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">3 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">3</fo:inline>also called Perfect Forward Secrecy or Key
Erasure</fo:block></fo:footnote-body></fo:footnote> and future secrecy are properties
that ensure some damage control in case that a device or key
does get compromised. Forward secrecy ensures that keys that
are currently on the device do not compromise any past
communication, so that the impact of a device compromise is
minimized. Future secrecy ensures that an attacker that has
compromised a key in the past, does not get to prolong his
attack indefinitely. This is often achieved by introducing
fresh randomness that should remain unknown to a passive
adversary.</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="attackercapabilities">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>1.2.2</fo:inline>   Attacker capabilities</fo:block>
<fo:block margin-bottom="5pt">A base model for the attacker is the Dolev-Yao model
<fo:basic-link internal-destination="bib5">[<fo:inline>5</fo:inline>]</fo:basic-link>, in which the attacker has full control
over the network. The attacker can listen to, alter, inject
and drop any message on the network.</fo:block>
<fo:block margin-bottom="5pt">However, real attackers have capabilities beyond control over the
network. By inspecting the physical properties of the
implementation, they might learn secret information that is
on the communication device. This is called a side-channel
attack. Device compromises can also be achieved by low-tech
attacks such as a rubber-hose attack or through legal
procedures. An attacker is assumed to learn information
through side-channels and to be able to get temporary access
to the device.</fo:block>
<fo:block margin-bottom="5pt">An issue with some existing protocols is that users need to trust
in the communications server that is being used. The open
nature of XMPP allows arbitrary parties, including
adversaries, to set up a fully functional XMPP server. But
even if you trust the organization that runs the server, you
might not trust the government of the country in which the
server is located to protect your privacy. Therefore, the
attacker is assumed to have full control over the server
that is used for communication.</fo:block>
<fo:block margin-bottom="1.5cm">The last capability that is given to the attacker is to
compromise protocol participants themselves. When Alice
communicates with Bob, the protocol should provide some pro-
tection in case Bob turns out to be a dishonest participant.
Basically, the protocol should enforce Bob to play by the
rules.</fo:block>
</fo:block>
</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="protocolanalysis">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="16pt" margin-bottom="1cm" background-color="orange"><fo:inline>2</fo:inline>   Protocol Analysis</fo:block>
<fo:block margin-bottom="5pt">The OMEMO standard is best described as a wrapper protocol around the Signal
protocol. I will analyze the standard as specified by its ProtoXEP
<fo:basic-link internal-destination="bib29">[<fo:inline>29</fo:inline>]</fo:basic-link>, in order to find if it achieves the cryptographic
properties that it claims to uphold. In addition, this report analyses the
OMEMO Encrypted Jingle File Transfer protocol as specified by its ProtoXEP
<fo:basic-link internal-destination="bib11">[<fo:inline>11</fo:inline>]</fo:basic-link>.</fo:block>
<fo:block margin-bottom="5pt">In Section 2.1, I will first briefly inspect the Signal Protocol, to see how it
achieves its security properties. Those already familiar with the Signal
Protocol might want to skip this section. After that, Section 2.2 will fully
analyze how the OMEMO protocol uses the secure sessions created by Signal to
set up an OMEMO session between multiple devices of two users.</fo:block>
<fo:block margin-bottom="1.5cm">At the moment of writing, version 3 is that latest version of the Signal
Protocol. This is the version that is used by OMEMO version 0 and the one
that is analyzed in this report.</fo:block>
<fo:block margin-bottom="1.5cm" id="signalprotocol">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-style="italic" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.1</fo:inline>   Signal Protocol</fo:block>
<fo:block margin-bottom="5pt">Although the Signal Protocol is mentioned in the specification, there is
no reference given to this protocol.<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">4 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">4</fo:inline>The OMEMO website <fo:basic-link internal-destination="bib10">[<fo:inline>10</fo:inline>]</fo:basic-link>
references to Trevor Sprain’s GitHub page <fo:basic-link internal-destination="bib24">[<fo:inline>24</fo:inline>]</fo:basic-link>, but this is
only a draft specifi- cation of the Double Ratchet part of
the protocol.</fo:block></fo:footnote-body></fo:footnote> This is not a flaw of the OMEMO
specification, because a normative specification for the Signal
Protocol does not exist. The open-source library that Open Whisper
Systems provides on GitHub <fo:basic-link internal-destination="bib30">[<fo:inline>30</fo:inline>]</fo:basic-link> is a
straightforward implementation and I will use it as a basis for my
analysis of the Signal Protocol. In addition to the source code, OWS
published a series of blog posts <fo:basic-link internal-destination="bib18">[<fo:inline>18</fo:inline>]</fo:basic-link><fo:basic-link internal-destination="bib17">[<fo:inline>17</fo:inline>]</fo:basic-link><fo:basic-link internal-destination="bib16">[<fo:inline>16</fo:inline>]</fo:basic-link> that
further clarify how their protocol works.</fo:block>
<fo:block text-align="center" margin-bottom="1.5cm"><fo:block><fo:external-graphic src="../graphics/omemog1.png" width="17cm" content-width="scale-to-fit" content-height="scale-to-fit"/></fo:block><fo:block font-style="italic" text-align="center">Figure 1: Signal Protocol version 3</fo:block></fo:block>
<fo:block margin-bottom="1.5cm" id="protocoldescription">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.1.1</fo:inline>   Protocol Description</fo:block>
<fo:block margin-bottom="5pt">A simplified representation of the Signal Protocol is given in
Figure 1. The figure shows the start of a conversation
between Alice and Bob. In this abstracted example, the
participants are identified by their name. In reality, this
would be a phone number for the Signal application and an
XMPP address in case of OMEMO.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Notation</fo:inline> The following notation is used:
KDF<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub"><fo:inline font-style="italic">s</fo:inline></fo:inline>(<fo:inline font-style="italic">i</fo:inline>) derives a key using
salt <fo:inline font-style="italic">s</fo:inline>, info data <fo:inline font-style="italic">i</fo:inline> and a constant label that
is unique for each KDF computation in the figure. When no
salt is specified, the constant value 0 is used.
MAC<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub"><fo:inline font-style="italic">k</fo:inline></fo:inline>(<fo:inline font-style="italic">m</fo:inline>) computes an
authentication tag on message <fo:inline font-style="italic">m</fo:inline>, using key <fo:inline font-style="italic">k</fo:inline>.
enc<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub"><fo:inline font-style="italic">k</fo:inline></fo:inline> (<fo:inline font-style="italic">n</fo:inline>, <fo:inline font-style="italic">m</fo:inline>)
computes the symmetric encryption of message <fo:inline font-style="italic">m</fo:inline>, using
key <fo:inline font-style="italic">k</fo:inline> and nonce/initialization vector <fo:inline font-style="italic">n</fo:inline>. To
keep the diagram simple, the precise meaning for asymmetric
keys notation depends on the context, but it is
straightforward. For example: <fo:inline font-style="italic">a</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline> refers to
the entire key pair when generated, to the private key when
used in the DH computation and to the public key when sent
in the message. Only public keys are sent in messages.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Prekeys</fo:inline> First Bob uploads his client-side generated key
material to the server so that he can be contacted by Alice.
He sends his long-term identity key <fo:inline font-style="italic">B</fo:inline>, his signed
prekey <fo:inline font-style="italic">b</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline> with corresponding signature
sig<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub"><fo:inline font-style="italic">B</fo:inline></fo:inline>(<fo:inline font-style="italic">b</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline>) and a
one-time-use prekey <fo:inline font-style="italic">b<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">x</fo:inline></fo:inline>. Bob can go offline
at this point, the server will now act as an online cache
for others that want to initiate a conversation with
Bob.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">TripleDH</fo:inline> When Alice wants to talk with Bob, she requests
the cached data from the server. The server complies and
Alice can initiate the TripleDH<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">5 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">5</fo:inline>In older versions, the
key derivation did indeed consist of three DH
computations: it did not include the signed prekey.
The name “QuadrupleDH” is not used to avoid
confusion with a variant that also includes a DH
computation between the identity keys. The current
computation can be referred to as a variant on
standard TripleDH: “TripleDH with signed and
one-time prekeys”.</fo:block></fo:footnote-body></fo:footnote> handshake. She first
generates her own one-time key pair <fo:inline font-style="italic">a</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline>.
She combines the keys by concatenating the results of the DH
computations and computes <fo:inline font-style="italic">s</fo:inline>, a shared secret that
initializes the Double Ratchet. Using the KDF function,
Alice computes the initial root key rk<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline>.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">DH ratchet (every reply)</fo:inline> Alice updates the root key with
the DH ratchet. She first generates a fresh random key pair
<fo:inline font-style="italic">a</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">1</fo:inline> and does a DH computation with
the latest DH key she received from Bob (initially
<fo:inline font-style="italic">b</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline>). Using the previous root key
rk<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline> as a seed for the KDF, she computes a
new root key rk<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">1</fo:inline> and a new sending chain key
ck<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">1,0</fo:inline>. At this point, Alice should delete
the old root key rk<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline> and her previous key pair
<fo:inline font-style="italic">a</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline> to ensure forward secrecy.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Chain ratchet (every message)</fo:inline> Alice derives a message key
(mk<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">1,0</fo:inline>) and a new chain key
ck<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">1,1</fo:inline> from the old chain key
ck<fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">1,0</fo:inline> and she deletes the old chain key
for forward secrecy. Alice derives three keys from the mk
with the KDF: an encryption key <fo:inline font-style="italic">k</fo:inline>, an authentication
key <fo:inline font-style="italic">m</fo:inline> and a nonce/initialization vector <fo:inline font-style="italic">n</fo:inline>. She
encrypts the plaintext message and computes an
authentication tag over the (public) identity keys and the
ciphertext. She then sends the SignalMessage to Bob,
consisting of her one-time key <fo:inline font-style="italic">a</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">1</fo:inline>, the
ciphertext and the authentication tag. Only with the
PreKeySignalMessage (the first message) will she also
include her first one-time key <fo:inline font-style="italic">a</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline> and her
identity key <fo:inline font-style="italic">A</fo:inline>. Bob can use the key material from the
PreKeySignalMessage to initiate the root ratchet and
receiving chain ratchet, from which the key material can be
derived to validate and decrypt the message.</fo:block>
<fo:block margin-bottom="5pt">This diagram implicitly also shows how the conversation
continues. Every time the user replies to a message, the
steps below the first horizontal line are taken: the root
key is updated with a fresh random DH computation and a new
sending chain ratchet is initialized. For every additional
message, the sending chain key is updated and a fresh
message key is used to encrypt user messages. Note that both
users have one root ratchet and two chain ratches: one for
sending and one for receiving.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Key verification</fo:inline> In order to ensure that no
man-in-the-middle attack has taken place, Alice needs to
verify that the identity key she has connected with indeed
belongs to Bob. How they do this is not important, as long
as it happens over an authenticated channel, but no PKI is
assumed in the protocol. Instead, users must manually verify
the identity key “fingerprint” (which is just the full
public key) of the other party.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Message counters</fo:inline> Messages might arrive out of order and
can even arrive after the DH ratchet has been forwarded.
Therefore, the sender of the message also includes two
counters: one for how many messages were sent under the
current ratchet and one for the total under the previous
ratchet. With these counters, the receiver can see exactly
which messages did not (yet) arrive and store only the
corresponding message key mk. These counters are
authenticated by the tag, but they are not encrypted.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Multiple prekeys</fo:inline> In a real-world situation, Bob would want
more than one person to be able to communicate with him, so
he uploads multiple prekeys to the server. In the case of
the Signal application, Alice only gets a single one-time
prekey from the server. When the server runs out of prekeys,
Alice can complete the handshake without Bob’s one-time
prekey. This message has reduced forward secrecy, because
Bob cannot delete the signed prekey b0 immediately after
use. When Bob receives a PreKeySignalMessage, he should send
a fresh signed prekey to the the server, so that the key
that is cached on the server gets updated.</fo:block>
<fo:block margin-bottom="5pt">Bob needs to know which signed prekey and which one-time prekey
Alice used in her computation, so each prekey has its own
identifying number. Alice includes that number in the
PreKeySignalMessage and sends Bob, unauthenticated and
unencrypted. These numbers are generated sequentially.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Key lifetimes</fo:inline> The identity key lasts indefinitely. It is
possible that Alice sends a message using a signed prekey
that was already updated by Bob. For that reason, Bob should
keep a few old signed prekeys in storage, so that he does
not need to discard those messages. How long this should be
is not specified, but the specification should include at
least a guideline and/or upper bound for this lifetime. The
one-time prekeys are used only once and should be deleted
immediately after use. The server should delete a public
one-time prekey immediately after they handed it out to
someone, so it does not get used again. DH ratchet keys
should be deleted after the other party has sent their next
DH ratchet key and that DH computation has been
completed.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Used cryptographic primitives</fo:inline> The protocol so far is
lacking a description of which cryptographic primitives are
used as building blocks of the protocol. Technically, the
protocol does not need to be locked, but at this moment it
is non-trivial to change the used ciphers in the OWS code.
The following primitives are in use:</fo:block>
<fo:list-block provisional-distance-between-starts="0.75cm" provisional-label-separation="2.5mm" space-after="12pt" start-indent="1cm"><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>enc: AES <fo:basic-link internal-destination="bib23">[<fo:inline>23</fo:inline>]</fo:basic-link> in CBC mode and using
PKCS5padding</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>MAC: HmacSHA256 <fo:basic-link internal-destination="bib14">[<fo:inline>14</fo:inline>]</fo:basic-link></fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>KDF: HKDF <fo:basic-link internal-destination="bib15">[<fo:inline>15</fo:inline>]</fo:basic-link> using HmacSHA256</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>DH: X25519 <fo:basic-link internal-destination="bib1">[<fo:inline>1</fo:inline>]</fo:basic-link></fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>sig: Ed25519 <fo:basic-link internal-destination="bib2">[<fo:inline>2</fo:inline>]</fo:basic-link></fo:block></fo:list-item-body></fo:list-item></fo:list-block>
<fo:block margin-bottom="5pt">A standard of the protocol could benefit from allowing different
primitives or cipher suites. For example, when a
cryptographic breakthrough leads to breakage of a primitive,
clients can simply reject all suites that use that primitive
and remain secure. Or an implementer might want to use a
different suite because of business requirements or
performance issues. This cipher suite should be negotiated
at the start of the protocol: Bob can upload a list of all
suites he accepts to the server cache and Alice can pick
one. To avoid downgrade attacks, the full list and the
picked suite should be authenticated in the
PreKeySignalMessage.</fo:block>
<fo:block margin-bottom="5pt">Note that the identity key <fo:inline font-style="italic">B</fo:inline> is used both for signing
prekeys and in a DH computation, which is secure
<fo:basic-link internal-destination="bib4">[<fo:inline>4</fo:inline>]</fo:basic-link> with the current implementation over
Curve25519, but might not be trivial to implement for other
public key ciphers. The used structure of encrypt-then-MAC
could also be replaced with an authenticated encryption
cipher/mode as long as it allows for additional
authenticated data (AAD).</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Metadata</fo:inline> The protocol leaks metadata about who is
communicating with whom and how much they are communicating.
Alice’s request for the server cache leaks to the server
that she wants to start a conversation with Bob, as does the
PreKeySignalMessage. The plaintext message counters that are
included in each SignalMessage make it possible to track the
rest of the conversation.</fo:block>
<fo:block margin-bottom="1.5cm">Unlike the ratchet used in the Signal Protocol, the regular
variant of the Double Ratchet <fo:basic-link internal-destination="bib24">[<fo:inline>24</fo:inline>]</fo:basic-link> also
encrypts the message headers, which would make it possible
to avoid tracking of the conversation. It would only make
sense to implement this if this information is not leaked
already in the transport layer.</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="Securityanalysis">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.1.2</fo:inline>   Security Analysis</fo:block>
<fo:block margin-bottom="5pt">A more thorough analysis of the Signal protocol has been done
before by Frosch, Mainka, Bader, Bergsma, Schwenk and Holz
<fo:basic-link internal-destination="bib6">[<fo:inline>6</fo:inline>]</fo:basic-link>. In their work, the researchers provide a detailed
description of the application, the underlying protocol and
the environment in which the application operates. That
environment includes the Google Cloud Messaging
infrastructure in order to send push messages to the
devices.</fo:block>
<fo:block margin-bottom="5pt">In their analysis, the researchers found no major weaknesses in
the Signal Protocol. They give security proofs for the
building blocks that make up the Signal Protocol: the
initial key exchange, the subsequent key derivation and the
authenticated encryption. In addition, they identify a minor
weakness in the authentication of users identity keys, named
the unknown key-share attack, and they comment on the
claimed additional security features (future secrecy,
forward secrecy and deniability).</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Unknown key-share attack</fo:inline> In an unknown key-share attack,
Eve downloads the public key material of Bob and uploads the
keys as if they are her own. When Alice wants to initiate a
conversation with Eve, she checks that the identity key she
downloaded from the server match with the one that Eve
presents to her out-of-band. Alice completes the handshake
on her side and sends here initial messages. Eve forwards
these (still encrypted) messages to Bob.<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">6 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">6</fo:inline>Forwarding
messages is trivial for an attacker, because we
assume she has full control of the
server.</fo:block></fo:footnote-body></fo:footnote></fo:block>
<fo:block margin-bottom="5pt">The result of a successful attack is that Alice falsely believes
that she sent her messages to Eve, while Bob falsely
believes that the received messages were intended for him.
Eve is unable to compromise the confidentiality or integrity
of the messages, making the impact of this attack relatively
low.</fo:block>
<fo:block margin-bottom="5pt">The underlying cause of the above attack is that Eve never needed
to prove to Alice that she was in possession of the private
key corresponding to the presented identity public key. The
researchers propose a solution, where the users engage in an
out-of-band interactive zero-knowledge proof over an
authenticated channel, such as exchange of messages with
QR-codes. Because this solution is based on an interactive
protocol, it would disable users from sending messages
immediately if the recipient is not online at that
moment.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Future secrecy</fo:inline> Future secrecy ensures that a key
compromise at some point in time will not propagate
indefinitely. The Signal protocol achieves this by
introducing new randomness with every reply in order to
forward the root ratchet. A key compromise by a passive
attacker will not propagate from that point on. However, an
active attacker that has compromised both the root key and
an identity key is able to set up a man in the middle attack
that can be prolonged indefinitely.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Forward secrecy</fo:inline> Forward secrecy ensures that when a device
is compromised, no past messages can be decrypted. This is
achieved by erasing message encryption/decryption keys as
soon as possible. One of the problems with the Signal
Protocol is that Bob’s private prekeys need to remain stored
on the device until a message has been received that was
encrypted with the corresponding public prekey. If Eve
manages to intercept and block that message from being
delivered, Bob will keep holding on to that private prekey,
so that Eve can read the content of the message if she is
able to extract Bob’s private prekeys from his device. But
for any message that is delivered and decrypted correctly,
Bob discards the private part of the prekey and ensures
forward secrecy.</fo:block>
<fo:block margin-bottom="5pt">Version 2 of the Signal Protocol was also vulnerable to an attack
on the forward secrecy of the first message by an active
adversary. Eve could provide her own prekey (of which she
knew the corresponding private key) and provide it to Alice,
pretending it was the prekey of Bob, together with Bob’s
identity key. Bob would not be able to decrypt the message,
but Eve would be able to if she was able to compromise just
Bob’s private identity key. Version 3 fixes this
vulnerability by introducing adding a prekey that is signed
by the identity key. This signature ensures that Eve cannot
provide her own prekey and pretend that it belongs to Bob,
thus preventing the attack.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Deniability</fo:inline> Deniability for a messaging application can
occur on two levels: denial of the message content and
denial of the full conversation. The researchers prove that
the Signal Protocol achieves the former, but they claim that
the latter might only be theoretical. Because clients
authenticate to the Open Whisper Systems server (similar to
how an XMPP client authenticates to an XMPP server) and this
server needs to know the addresses of the sender and
recipient in order to guarantee delivery, the logs that
might be stored by the server can reveal that a conversation
took place.</fo:block>
<fo:block margin-bottom="1.5cm">The fact that a conversation took place might leak, but through
another layer than the application layer of the core Signal
Protocol. The solution to such leaking of metadata should
also be contained in the appropriate layer and should stay
out of scope for the OMEMO specification.</fo:block>
</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="omemo">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-style="italic" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.2</fo:inline>   OMEMO</fo:block>
<fo:block margin-bottom="1.5cm">OMEMO uses Signal in order to set up a session. In Section 2.2.1, I will
show how OMEMO uses those Signal sessions in order to set up a
secure conversation between multiple devices. In Section 2.2.2, I
will analyze the cryptographic strength of the design and describe
minor issues I found in the specification. Two major problems are
described in their own sections: Section 2.2.3 explains how a
malicious device can compromise the entire conversation and Section
2.2.4 shows how forward secrecy and future secrecy can be affected
by other devices.</fo:block>
<fo:block margin-bottom="1.5cm" id="Protocoldescription">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.2.1</fo:inline>   Protocol description</fo:block>
<fo:block margin-bottom="5pt">At a very high level, OMEMO works similar to how a Signal group
messages <fo:basic-link internal-destination="bib19">[<fo:inline>19</fo:inline>]</fo:basic-link> work, but with multiple devices instead of
multiple users. A Signal session is set up between each
device. Messages are encrypted and authenticated with a
random key and the encryption of that key is sent as message
content of a SignalMessage.</fo:block>
<fo:block margin-bottom="5pt">A complete overview of OMEMO is given in the use cases of section
4 of the ProtoXEP, but I will provide a brief description
here. A typical XMPP setup is shown in Figure 2. Alice is
registered at a different server as Bob. Alice has
registered two OMEMO enabled devices, while Bob has only
registered his phone and wants to register his laptop as
well.</fo:block>
<fo:block margin-bottom="5pt">In order to register his laptop, Bob generates a random 31-bit
device id and registers it by adding it to his device list
on the server via PEP. He then generates a random identity
key B, a signed prekey <fo:inline font-style="italic">b</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline> with
corresponding signature sig(<fo:inline font-style="italic">b</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub">0</fo:inline>) and 100
one-time prekeys <fo:inline font-style="italic">b</fo:inline><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="sub"><fo:inline font-style="italic">x</fo:inline></fo:inline>. He then
uploads this in an OMEMO bundle, again via PEP. This bundle
contains the same information that Bob caches on the server
in regular Signal.</fo:block>
<fo:block margin-bottom="5pt">Assume Alice wants to send an OMEMO encrypted message from her
phone. She can detect that Bob’s device(s) support OMEMO by
requesting his device list with PEP. If he does, she
encrypts and authenticates her message using a randomly
generated key. For every device that Alice wants to send the
encrypted message to, she fetches the entire bundle via PEP.
If she wants to add more of her own devices in the
conversation, she gets their bundles as well from her own
server. Alice creates a PreKeySignalMessage for every device
by picking a random one-time prekey from each bundle and
encrypting the randomly generated key to each device. She
combines all information in a single MessageElement: the
encrypted payload (<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;payload/&gt;</fo:inline>),
the plaintext iv (<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;iv/&gt;</fo:inline>), the
sender id (<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">sid</fo:inline>) and the encrypted
random key (<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;key/&gt;</fo:inline>) tagged with
the corresponding receiver id
(<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">rid</fo:inline>).</fo:block>
<fo:block text-align="center" margin-bottom="5pt"><fo:block><fo:external-graphic src="../graphics/omemog2.png" width="17cm" content-width="scale-to-fit" content-height="scale-to-fit"/></fo:block><fo:block font-style="italic" text-align="center">Figure 2: OMEMO version 0</fo:block></fo:block>
<fo:block margin-bottom="5pt">Bob’s device can decrypt the message by selecting the correct
<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;key/&gt;</fo:inline> element based on
the rid attribute and use it to initialize the Signal
session on his side.</fo:block>
<fo:block margin-bottom="5pt">At this point, Alice’s phone has set up a Signal session with
each of the devices. If Bob wants to reply, he still needs
to initialize a session with Alice’s PC, so he also needs to
download all bundles and initialize Signal sessions by
sending a PreKeySignalMessage where necessary. If all
devices (but one) have sent a message, each device will have
a pairwise Signal session set up.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Device synchronization</fo:inline> The regular delivery mechanism of
XMPP was built to send a message to one user only and to
send it only to online devices. Message Carbons
<fo:basic-link internal-destination="bib13">[<fo:inline>13</fo:inline>]</fo:basic-link> are used to deliver the messages to
multiple devices per user and Message Archive Management
(MAM) <fo:basic-link internal-destination="bib21">[<fo:inline>21</fo:inline>]</fo:basic-link> is used to enable delivery to
devices that are currently offline. This achieves
inter-client history synchronization if no malicious device
is taking part in the conversation.<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">7 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">7</fo:inline>see also Section
2.2.3.</fo:block></fo:footnote-body></fo:footnote></fo:block>
<fo:block margin-bottom="5pt">The MAM was designed as a message archive, but instead it is used
here as a message cache. The ciphertext messages will remain
stored online after they have been downloaded, even though
the keys will be discarded upon encryption. This does not
affect security, but it wastes space on the server. A client
should delete the message from the server after they
decrypted it and deleted the message keys.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">KeyTransportElement</fo:inline> Instead of sending a MessageElement, a
device can also send a message without a payload, called a
KeyTransportElement. The randomly generated key might be
used for example to encrypt a file, see Section 2.3. Sending
a KeyTransportElement also has the advantage that the Signal
ratchet gets forwarded.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Prekey collision</fo:inline> When Alice wants to create a
PreKeySignalMessage for Bob, she gets the full bundle and
randomly selects one of his prekeys. When Bob receives
multiple PreKeySig- nalMessages, the prekeys might collide.
Because of the birthday problem, collisions are expected to
occur often. With 100 prekeys a collision is expected after
12.3 PreKeySignalMessages and for the suggested minimum of
20 keys, a collision is expected after approximately 5.86
PreKeySignalMessages.</fo:block>
<fo:block margin-bottom="5pt">When Bob receives PreKeySignalMessages with prekey collisions, he
replies to Alice with a KeyTransportElement containing his
own PreKeySignalMessage, so that a new session can be
initiated. If Bob no longer has the corresponding private
prekey, he silently discards the message.</fo:block>
<fo:block margin-bottom="5pt">When fetching a PreKeySignalMessage with MAM, Bob should keep the
private prekey in memory (but he may also delete them) until
all MAM messages have been downloaded, so that he can still
decrypt messages. He can decrypt, but he should set up a new
session with Alice anyway. The specification warns for a
small subgroup attack <fo:basic-link internal-destination="bib22">[<fo:inline>22</fo:inline>]</fo:basic-link> that applies when reusing
one-time keys. However, that attack does not apply to X25519
<fo:basic-link internal-destination="bib3">[<fo:inline>3</fo:inline>]</fo:basic-link>. Implementers should make sure that the prekeys also get
discarded if the MAM catch-up does not complete successfully
(for example when the device crashes), or the forward
secrecy of the message will be compromised.</fo:block>
<fo:block margin-bottom="5pt">A more elegant solution would be to do what OWS does: let the
server send each one-time prekey once and delete them
afterwards, instead of delivering the entire list of
prekeys. That way, no collisions can occur on the prekeys
and fewer initial messages get dropped. When the server runs
out of one-time prekeys, the server lets Alice know and she
can complete the PreKeySignalMessage without a one-time key,
just as the Signal application.</fo:block>
<fo:block margin-bottom="5pt">It is unclear if this solution is possible to implement in XMPP,
as it appears that there currently is no XMPP extension that
allows a server to delete/mark PEP nodes while the user is
offline.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Device ID</fo:inline> The resourcepart of the XMPP address <fo:basic-link internal-destination="bib27">[<fo:inline>27</fo:inline>]</fo:basic-link> is not
used, but instead a separate device id is used. This is
because the resourcepart can change during an OMEMO session,
in which case a device will no longer be able to detect the
correct key in the header. With the current setup, the
device id should be unique among all device ids that
participate in a conversation, so they potentially collide
with any other device in use. Using 31 random bits for a
device id might be enough to avoid a collision most of the
time, but if the full XMPP address were used instead the
user can guarantee no collisions as he only needs to take
care of not colliding with himself.</fo:block>
<fo:block margin-bottom="1.5cm">Colliding device ids do not affect the security of the protocol:
in the worst case, colliding devices are unable to
participate in the conversation, affecting only the
usability.</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="Securityanalysis2">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.2.2</fo:inline>   Security Analysis</fo:block>
<fo:block margin-bottom="5pt">The pairwise Signal session in OMEMO are very similar to that of
the Signal application, so their security properties are
similar. The server model for XMPP is slightly different as
that of OWS, but since the protocol does not rely on trust
in the server this should not affect the security of the
Signal sessions. The way that multiple Signal sessions are
combined to create a multi-device OMEMO session does affect
the security properties of the entire protocol, so I will
analyze that in this Section.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Signed prekey lifetime</fo:inline> OMEMO does not specify when a
signed prekey should be renewed on the server. When this key
does not get updated, the forward secrecy of a PreKeySig-
nalMessage is not protected against an active attacker (see
Section 2.1.2). The device should send a fresh key to the
server regularly and old signed prekeys should be deleted
from the device after a while.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Cryptographic primitives</fo:inline> OMEMO adds only one cryptographic
primitive: authenticated encryption of the payload, which is
fixed to AES in GCM mode. There is no reason to fix the
cipher for OMEMO, any form of encryption with authentication
can be used. A non-authenticated encryption cipher can also
be used when the payload authentication is included in the
tag of the SignalMessage, as described in Section 2.2.3.</fo:block>
<fo:block margin-bottom="5pt">The specification should allow for alternative ciphers, for the
same reason that the Signal protocol should. Preferably, the
negotiation of this cipher should be merged with that of the
negotiation of the Signal cipher suite, so that clients only
need to negotiate this once at the start of a conversation.
Unfortunately, Signal is not standardized and it would
probably be unwise to specify in the OMEMO standard how
Signal should negotiate its primitives.</fo:block>
<fo:block margin-bottom="1.5cm"><fo:inline font-weight="bold">Metadata</fo:inline> Communication metadata is already leaked through
the Signal protocol and probably also through the XMPP
transport layer, but OMEMO also leaks this information
through the plaintext device ids. The payload is encrypted
in GCM mode, so the size of the plaintext is also
leaked.</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="maliciousdevice">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.2.3</fo:inline>   Malicious device</fo:block>
<fo:block margin-bottom="5pt">One cannot expect messages to remain confidential when one of the
participating devices is malicious. However, a user might
suspect at least that the integrity of messages sent by an
honest device is guaranteed by the protocol. After all, a
secure Signal session with that honest device has been set
up. However, the Signal session only protects the random
key. A malicious device has access to that key and can thus
re-encrypt and re-authenticate any payload with that key,
without the receiving party being able to detect it. This is
illustrated in Figure 3.</fo:block>
<fo:block margin-bottom="5pt"> The displayed attack only shows the attack in one direction: Eve
is able to modify and read anything sent by Alice. Eve needs
to apply the same attack to Bob in order to setup up a
bidirectional man in the middle attack. Note that Eve needs
to strip of her own <fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;key/&gt;</fo:inline> element
from the list of keys in every message in order to remain
undetected from Bob.</fo:block>
<fo:block text-align="center" margin-bottom="5pt"><fo:block><fo:external-graphic src="../graphics/omemog3.png" width="17cm" content-width="scale-to-fit" content-height="scale-to-fit"/></fo:block><fo:block font-style="italic" text-align="center">Figure 3: OMEMO man in the middle attack</fo:block></fo:block>
<fo:block margin-bottom="5pt">Two careful users will not be susceptible to this attack, because
neither of them will ever accept an unvalidated key.
However, no matter how careful Bob is with validating the
identity key of the sending device, he must assume that
Alice has never made a mistake and none of the devices were
compromised in order to be guaranteed the authenticity of
messages that come from any of her devices. This trust in
the other party is not necessary, if the messages were
authenticated inside the Signal session. Also, Bob could
make it less likely for Alice to accept a malicious device
by creating a cryptographic link between devices.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Message authentication</fo:inline> Messages are authenticated by the
randomized key, which protects the message integrity from
outsiders. However, anyone with access to the key can alter
the message, which includes a malicious device. There are a
few possible mitigations, each with their advantages and
disadvantages.</fo:block>
<fo:block margin-bottom="5pt"> A possible solution would be to authenticate inside the Signal
session. By authenticating the payload with the tag of the
SignalMessage, the full message is authenticated in such a
way that no other device can compromise the integrity. The
ciphertext (and not the plaintext) of the payload message
should be authenticated, so that the MAC-then-encrypt
pattern is applied.<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">8 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">8</fo:inline>Which also means that the payload
ciphertext must be known when the header is sent,
which is problematic for on-the-fly encryption. See
also Section 2.3.</fo:block></fo:footnote-body></fo:footnote> This solution increases
the computational load on the sender side, because the
payload needs to be authenticated more than once. When the
ciphertext is added as authenticated additional data (AAD)
of the Signal message, it would reduce the message size
slightly, because no authentication tag is required on the
payload. The payload encryption method should then be
simplified to a non-authenticated block cipher mode. It will
also require some alterations on the Signal library, as the
current implementation does not allow the library user to
add their own AAD.</fo:block>
<fo:block margin-bottom="5pt"> The payload can also be authenticated by including a hash of the
payload ciphertext in the SignalMessage plaintext (and
therefore the corresponding encrypted hash in the SignalMes-
sage ciphertext). This would not require changes to the
Signal library, but it would increase the size of each
<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;key/&gt;</fo:inline> element. This
solution is less elegant than the previous, as the hash of
the payload ciphertext is sent encrypted, even though the
recipient can compute this value themselves.</fo:block>
<fo:block margin-bottom="5pt"> By authenticating a list of all recipient device ids in the tag
of the SignalMessage, Bob has a guarantee about which
devices Alice has sent the message to. Bob’s client might
provide him with a warning if that list includes untrusted
devices. This protects him against the specific attack
described above, but the protocol remains vulnerable if one
of the devices gets compromised by another attack. This
solution can be combined with the above solution of
authenticating the payload ciphertext with the SignalMessage
ciphertext or tag.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Device linkage</fo:inline> There is no cryptographic link between
identities and device keys. In other words, Eve can attach
her own device identity key as if it is a resource belonging
to Bob and fool Alice into adding it.</fo:block>
<fo:block margin-bottom="5pt"> There is a solution: each device could sign a certificate on
each device identity key of the same user. While Eve might
fool Alice into thinking that Bob has another device, it is
highly unlikely that Bob is tricked into accepting another
device as his own. Device identity keys with a certificates
that was signed by an already accepted device of the same
user could be accepted automatically.</fo:block>
<fo:block margin-bottom="1.5cm"> In order to account for compromised devices, users must have the
ability to revoke certificates and certificates should have
a finite lifetime. This solution can be extended into a
full-blown public key infrastructure (PKI) or web of trust,
but I recommend to keep that out of the scope of the OMEMO
specification (although compatibility with such systems
could be taken into account when updating the OMEMO
specification).</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="forwardfuturesecrecy">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.2.4</fo:inline>   Forward/future secrecy</fo:block>
<fo:block margin-bottom="5pt">The forward secrecy and future secrecy of the protocol might be
affected in unexpected ways when a user has read-only
devices or inactive devices.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Read-only devices</fo:inline> Read-only devices will forward their
Signal chaining key, but never is there any message sent
from these devices, so the Signal root key will never be
ratcheted forward. Such a device compromises the future
secrecy of the entire conversation: if the receiving
chaining key of such a device gets compromised, the rest of
the conversation from that point on is compromised.</fo:block>
<fo:block margin-bottom="5pt"> The solution is simple, the read-only device should regularly
send a KeyTransportElement in order to forward the ratchet.
The interval for this message can be based on a number of
received messages, on time, or on a combination of
these.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Inactive devices</fo:inline> Devices that are no longer used and never
come online anymore, should be pruned from the conversation:
they keep a copy of a very old chain key in their memory,
which compromises the forward secrecy of the entire
conversation. There is currently no way specified for
removing keys from a conversation, except for just removing
them.</fo:block>
<fo:block margin-bottom="1.5cm">A device can interpret the above message for read-only devices as
an authenticated heartbeat message. When the device has not
not received a heartbeat for too long, it can decide to
prune the device from the conversation.</fo:block>
</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="OMEMOEncryptedJingleFileTransfer">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-style="italic" font-size="14pt" margin-bottom="0.8cm" background-color="silver"><fo:inline>2.3</fo:inline>   OMEMO Encrypted Jingle File Transfer</fo:block>
<fo:block margin-bottom="5pt">The OMEMO Encrypted Jingle File Transfer is defined in its ProtoXEP
<fo:basic-link internal-destination="bib11">[<fo:inline>11</fo:inline>]</fo:basic-link>. It uses the Jingle File transfer
<fo:basic-link internal-destination="bib25">[<fo:inline>25</fo:inline>]</fo:basic-link> to send the data to the other user. The
KeyTransportElement is included in the Jingle File description and
the file contents can be sent separately, encrypted with the random
key that was sent in the KeyTransportElement. </fo:block>
<fo:block margin-bottom="5pt">From a cryptographic perspective, there is no difference between sending
an OMEMO text message and sending an OMEMO-encrypted Jingle file,
even if that file gets sent over another channel. The one difference
is that Jingle allows for some file metadata to be sent. This
metadata is neither encrypted nor authenticated. The specification
does not provide a method for encrypting the metadata as well.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Message authentication</fo:inline> Just as a normal message is not
authenticated in the presence of a malicious device (see Section
2.2.3), so is the file content not authenticated when a malicious
device is present.</fo:block>
<fo:block margin-bottom="5pt"> The earlier proposed solution for authenticating the payload
(authenticating the ciphertext in the SignalMessage tag) would
disable on-the-fly encryption when sending a file, because the
payload ciphertext must be known when constructing the
<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;header/&gt;</fo:inline>. If losing the ability
to do on-the-fly encryption is acceptable, this solution should be
preferred. Otherwise, just authenticating the list of all recipient
devices should be sufficient to protect against the described
attack.</fo:block>
<fo:block margin-bottom="5pt"><fo:inline font-weight="bold">Metadata</fo:inline> Even though the metadata is not secured by the
specification, it should not leak any information on the raw file
contents. The Jingle protocol requires a hash of the file. The OMEMO
file-transfer specification is correct in requiring that this hash
is of the file ciphertext: a plaintext hash would lead to a
“confirmation-of-data” vulnerability <fo:basic-link internal-destination="bib31">[<fo:inline>31</fo:inline>]</fo:basic-link>.</fo:block>
<fo:block margin-bottom="1.5cm"> All other metadata can simply be removed from the
<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;description/&gt;</fo:inline> in order to
minimize metadata leakage, as they are considered optional for
Jingle. However, the “size” and “range” elements can be included, as
these already leak from the ciphertext length and the transfer
method.</fo:block>
</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="codereview">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="16pt" margin-bottom="1cm" background-color="orange"><fo:inline>3</fo:inline>   Code Review</fo:block>
<fo:block margin-bottom="5pt">Conversations is an open-source <fo:basic-link internal-destination="bib8">[<fo:inline>8</fo:inline>]</fo:basic-link> XMPP client for Android. In this section, I
will use their published code as a reference implementation for the OMEMO
ProtoXEP. I have inspected the implementation, looking for bugs that
compromise the security of an OMEMO session in any way. The goal of the code
review is twofold: it attempts to find security weaknesses and it should
reveal if inconsistencies exist between the specification and its
implementation. In the rest of this session I will give a summary of my
findings.</fo:block>
<fo:block margin-bottom="5pt"> The Conversations code simply uses the Signal library by OWS. Generation of
Signal keys, encryption of <fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;key/&gt;</fo:inline> elements and
managing of the corresponding Signal sessions is handled by the Signal
library. The biggest problem with this approach was that the Signal library
accepted messages without a one-time prekey, which OMEMO should never do
(since the server will never “run out” of one-time prekeys).<fo:footnote><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">9 </fo:inline><fo:footnote-body font-family="LiberationSansNarrow" font-size="8pt" color="black"><fo:block><fo:inline font-family="LiberationSansNarrow" font-size="60%" color="black" vertical-align="super">9</fo:inline>The
developers fixed this in commit cc209af.</fo:block></fo:footnote-body></fo:footnote> Combined with the
fact that the signed prekeys never get removed/updated, this means that
there was no <fo:inline font-style="italic">forward secrecy</fo:inline> for PreKeySignalMessages.</fo:block>
<fo:block margin-bottom="5pt"> Key generation for the Signal keys (identity key, prekeys and ephemeral keys) is
handled by the Signal library. The random key for the OMEMO payload is
generated by <fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">javax.crypto.KeyGenerator</fo:inline> class,
instantiated for 128 bits AES and a 128 bit payload IV is generated by
<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">java.security.SecureRandom</fo:inline>.</fo:block>
<fo:block margin-bottom="5pt"> The Conversations application does not keep prekeys in memory during a MAM
catch-up. Instead, the application uses the Signal library, which always
deletes the keys from the store after decryption of a
PreKeySignalMessage.</fo:block>
<fo:block margin-bottom="5pt">
<fo:inline font-weight="bold">HTTP file upload</fo:inline> Instead of using the OMEMO encrypted Jingle File
Transfer as a default method for file transfer, the application gives
preference to HTTP upload <fo:basic-link internal-destination="bib12">[<fo:inline>12</fo:inline>]</fo:basic-link>. That setup adds another
layer of indirection: the file is encrypted using AES in GCM mode, using a
random 128 bit key and a 64 bit IV, both generated by the
<fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">java.security.SecureRandom</fo:inline> class. The file is
then uploaded and the sender gets an URL. The used key and IV are appended
to the URL as fragment identifier. The full URL is then considered to be the
payload of the OMEMO MessageElement. This is not necessarily wrong (a HTTP
client should not send the fragment identifier to the server in the HTTP
request), but it is not a clean solution and there is a significant chance
that some other client will get this wrong. In addition, the additional
layer of indirection suffers from the same problem when a malicious device
is present: it offers no authentication of the file content. To fix this,
both the OMEMO payload and the file would have to be authenticated inside
the Signal session.</fo:block>
<fo:block margin-bottom="5pt">
<fo:inline font-weight="bold">X509 certificates</fo:inline> The code allows X509 certificates on identity keys,
although this is currently disabled by default. I have not looked in to much
detail, as this is outside the scope of the OMEMO specification, but there
appears to be nothing wrong with this approach.</fo:block>
<fo:block margin-bottom="5pt">
<fo:inline font-weight="bold">Purge</fo:inline> The conversations application allows users to purge the key of
other devices, which says that it irreversibly marks the key as compromised.
This irreversibility is not guaranteed and is only enforced by the fact that
the application provides no user interface for reversing. Users have no
method for purging their own keys or otherwise marking them as
compromised.</fo:block>
<fo:block margin-bottom="1.5cm">
<fo:inline font-weight="bold">Group messages</fo:inline> The Conversations application allows for group
conversations, although this is not specified by the ProtoXEP. From a
cryptographic perspective, these multi-user chats are no different from a
multi-device chat: to send a message to all users, the sending device will
have to set up a Signal session with each of the participating devices,
regardless of the user to which the device belongs.</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="conclusion">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="16pt" margin-bottom="1cm" background-color="orange"><fo:inline>4</fo:inline>   Conclusions/recommendations</fo:block>
<fo:block margin-bottom="5pt">The OMEMO standard provides a protocol for secure communication with multiple
devices. This protocol is only secure if both users apply good operational
security in securing their devices and in adding devices of the other
party.</fo:block>
<fo:block margin-bottom="5pt"> When both users are careful, they can set up a secure multi-device session.
However, if one of the users makes a mistake and adds a malicious device, or
if just one device of the users gets compromised, the authentication of all
messages is compromised, which is not necessary. The (ciphertext of the)
payload should be authenticated in each SignalMessage, preferably as
AAD.</fo:block>
<fo:block margin-bottom="5pt"> The current OMEMO specification provides no link between devices that belong to
the same user. Eve might trick Alice thinking that her key belongs to Bob.
Bob should be able to sign a certificate that tells Alice which devices
belong to him, she would not be tricked so easily by Eve.</fo:block>
<fo:block margin-bottom="5pt"> Each devices should regularly send a message (a heartbeat) in order to forward
the root ratchet of the Signal sessions, so that future secrecy can be
ensured. The already existing KeyTransportElement can be used as an empty
message that achieves this functionality.</fo:block>
<fo:block margin-bottom="5pt"> Inactive devices, devices that never come online anymore, should be removed from
a conversation by the owning user. Their presence in a conversation means
that the forward secrecy of the entire conversation is compromised, because
they hold on to an old key. In addition, I recommend that inactive devices
may be removed by the other user. The above described heartbeat would
provide users with a method for detecting if a device has become
inactive.</fo:block>
<fo:block margin-bottom="5pt"> The lifetime of (signed) prekeys should be mentioned in the standard. Signed
prekeys should be changed regularly in order to achieve forward secrecy.
This should at least be done after every time the user receives a
PreKeySignalMessage that uses the latest signed prekey, but it can be done
more often (based on time) to ensure the forward secrecy of dropped
messages. The standard should allow for alternative ciphers. However, the
standard should limit itself to the ciphers used in the OMEMO encryption.
Signal also has no way for specifying ciphers, but it is not in the scope of
the OMEMO standard to specify that.</fo:block>
<fo:block margin-bottom="5pt"> Prekey collisions can be greatly reduced if the server hands out each key only
once, instead of all keys to every user that asks. This would not affect
security, but it would make successful delivery of the first message of the
protocol more reliable.</fo:block>
<fo:block margin-bottom="5pt"> The specification should update its terminology to reflect the recent name
changes by Open Whisper Systems. Specifically, the term “Axolotl” should be
replaced with “the Signal Protocol” and the message names
“PreKeyWhisperMessage” and “WhisperMessage” should be replaced with
“PreKeySignalMessage” and “SignalMessage”.</fo:block>
<fo:block margin-bottom="1.5cm"> My final remark is about the reference implementation. Unless a change is made
in the way that servers provide the keys, the code should not accept
PreKeySignalMessages without a one-time prekey. As stated before, this has
already been fixed in commit cc209af.</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="Acknowledgement">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="16pt" margin-bottom="1cm" background-color="orange"><fo:inline>5</fo:inline>   Acknowledgement</fo:block>
<fo:block margin-bottom="1.5cm">I would like to thank Daniel Gultsch for helping me out with some of the
questions I have had on the protocol and for his quick processing of my
feedback in the Conversations code.</fo:block>
</fo:block>
<fo:block margin-bottom="1.5cm" id="References">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="16pt" margin-bottom="1cm" background-color="orange"><fo:inline>6</fo:inline>   References</fo:block>
<fo:list-block provisional-distance-between-starts="0.75cm" provisional-label-separation="2.5mm" space-after="12pt" margin-bottom="1.5cm"><fo:list-item margin-bottom="5pt" id="bib1"><fo:list-item-label end-indent="label-end()"><fo:block>[1] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel J. Bernstein. <fo:inline font-style="italic">Public Key Cryptography - PKC 2006: 9th International
Conference on Theory and Practice in Public-Key
Cryptography, New York, NY, USA, April 24- 26, 2006.
Proceedings</fo:inline>, <fo:inline>chapter Curve25519: New Diffie-Hellman Speed Records, pages 207–228</fo:inline>. <fo:inline>
Springer Berlin Heidelberg,
Berlin, Heidelberg
</fo:inline>, <fo:inline>2006</fo:inline>. <fo:basic-link color="blue" external-destination="https://cr.yp.to/papers.html#curve25519">https://cr.yp.to/papers.html#curve25519</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib2"><fo:list-item-label end-indent="label-end()"><fo:block>[2] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, Bo-Yin Yang. <fo:inline>High-speed high-security signatures</fo:inline>, <fo:inline font-style="italic">Journal of Cryptographic Engineering</fo:inline>, <fo:inline>2(2):77–89, 2012</fo:inline>. <fo:basic-link color="blue" external-destination="https://ed25519.cr.yp.to/">https://ed25519.cr.yp.to/</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib3"><fo:list-item-label end-indent="label-end()"><fo:block>[3] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel J. Bernstein, Tanja Lange. <fo:inline>SafeCurves: choosing safe curves for elliptic-curve
cryptography</fo:inline>. <fo:basic-link color="blue" external-destination="http://safecurves.cr.yp.to">http://safecurves.cr.yp.to</fo:basic-link>. Accessed: 2015-05-04.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib4"><fo:list-item-label end-indent="label-end()"><fo:block>[4] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, Mario Strefler. <fo:inline>On the joint security of encryption and signature in
emv</fo:inline>, <fo:inline>Cryptology ePrint Archive</fo:inline>, <fo:inline>Report 2011/615, 2011</fo:inline>. <fo:basic-link color="blue" external-destination="https://eprint.iacr.org/2011/615">https://eprint.iacr.org/2011/615</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib5"><fo:list-item-label end-indent="label-end()"><fo:block>[5] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Danny Dolev, Andrew C. Yao. <fo:inline>On the security of public key protocols</fo:inline>, <fo:inline font-style="italic">Information Theory, IEEE
Transactions on</fo:inline>, <fo:inline>29(2):198–208, March 1983</fo:inline>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib6"><fo:list-item-label end-indent="label-end()"><fo:block>[6] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Tilman Frosch, Christian Mainka, Christoph Bader, Florian Bergsma, Jrg Schwenk, Thorsten Holz. <fo:inline>How Secure is TextSecure?</fo:inline>, <fo:inline>Cryptology ePrint Archive</fo:inline>, <fo:inline>Report 2014/904, November 2014</fo:inline>. <fo:basic-link color="blue" external-destination="http://eprint.iacr.org/2014/904">http://eprint.iacr.org/2014/904</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib7"><fo:list-item-label end-indent="label-end()"><fo:block>[7] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel Gultsch. <fo:inline>Conversations</fo:inline>. <fo:basic-link color="blue" external-destination="https://github.com/siacs/Conversations">https://github.com/siacs/Conversations</fo:basic-link>. Accessed: 2016-04-07.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib8"><fo:list-item-label end-indent="label-end()"><fo:block>[8] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel Gultsch. <fo:inline>Conversations is an open source XMPP/Jabber client for
Android 4.0+ smart phones</fo:inline>. <fo:basic-link color="blue" external-destination="https://github.com/siacs/Conversations">https://github.com/siacs/Conversations</fo:basic-link>. Accessed: 2016-05-10.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib9"><fo:list-item-label end-indent="label-end()"><fo:block>[9] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel Gultsch. <fo:inline>Conversations: the very last word in instant
messaging</fo:inline>. <fo:basic-link color="blue" external-destination="https://conversations.im/">https://conversations.im/</fo:basic-link>. Accessed: 2016-04-07.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib10"><fo:list-item-label end-indent="label-end()"><fo:block>[10] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel Gultsch. <fo:inline>OMEMO Multi-End Message and Object Encryption</fo:inline>. <fo:basic-link color="blue" external-destination="https://conversations.im/omemo/">https://conversations.im/omemo/</fo:basic-link>. Accessed: 2016-04-07.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib11"><fo:list-item-label end-indent="label-end()"><fo:block>[11] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel Gultsch. <fo:inline>XEP-xxxx: OMEMO Encrypted Jingle File Transfer</fo:inline>. <fo:inline>ProtoXEP, XMPP Standards Foundation</fo:inline>, <fo:inline>September 2015</fo:inline>. <fo:basic-link color="blue" external-destination="https://xmpp.org/extensions/inbox/omemo-filetransfer.html">https://xmpp.org/extensions/inbox/omemo-filetransfer.html</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib12"><fo:list-item-label end-indent="label-end()"><fo:block>[12] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Daniel Gultsch. <fo:inline>XEP-0363: HTTP File Upload</fo:inline>. <fo:inline>Standards Track, XMPP Standards Foundation</fo:inline>, <fo:inline>March 2016</fo:inline>. <fo:basic-link color="blue" external-destination="https://xmpp.org/extensions/xep-0263.html">https://xmpp.org/extensions/xep-0263.html</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib13"><fo:list-item-label end-indent="label-end()"><fo:block>[13] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Joe Hildebrand, Matthew Miller. <fo:inline>XEP-0280: Message Carbons</fo:inline>. <fo:inline>Standards Track, XMPP Standards Foundation</fo:inline>, <fo:inline>February 2016</fo:inline>. <fo:basic-link color="blue" external-destination="https://xmpp.org/extensions/xep-0280.html">https://xmpp.org/extensions/xep-0280.html</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib14"><fo:list-item-label end-indent="label-end()"><fo:block>[14] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Hugo Krawczyk, Mihir Bellare, Ran Canetti. <fo:inline>HMAC: Keyed-Hashing for Message Authentication</fo:inline>. <fo:inline>RFC 2104, RFC Editor</fo:inline>, <fo:inline>February 1997</fo:inline>. <fo:basic-link color="blue" external-destination="https://www.rfc-editor.org/rfc/rfc2104.txt">https://www.rfc-editor.org/rfc/rfc2104.txt</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib15"><fo:list-item-label end-indent="label-end()"><fo:block>[15] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Hugo Krawczyk, Pasi Eronen. <fo:inline>HMAC-based Extract-and-Expand Key Derivation Function
(HKDF)</fo:inline>. <fo:inline>RFC 5869, RFC Editor</fo:inline>, <fo:inline>May 2010</fo:inline>. <fo:basic-link color="blue" external-destination="https://www.rfc-editor.org/rfc/rfc5869.txt">https://www.rfc-editor.org/rfc/rfc5869.txt</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib16"><fo:list-item-label end-indent="label-end()"><fo:block>[16] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Moxie Marlinspike. <fo:inline>Advanced cryptographic ratcheting</fo:inline>. <fo:inline>November 2013</fo:inline>. <fo:basic-link color="blue" external-destination="https://whispersystems.org/ blog/advanced-ratcheting/">https://whispersystems.org/ blog/advanced-ratcheting/</fo:basic-link>. Accessed: 2016-05-10.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib17"><fo:list-item-label end-indent="label-end()"><fo:block>[17] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Moxie Marlinspike. <fo:inline>Forward Secrecy for Asynchronous Messages</fo:inline>. <fo:inline>Augustus 2013</fo:inline>. <fo:basic-link color="blue" external-destination="https://whispersystems.org/blog/asynchronous-security/">https://whispersystems.org/blog/asynchronous-security/</fo:basic-link>. Accessed: 2016-05-10.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib18"><fo:list-item-label end-indent="label-end()"><fo:block>[18] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Moxie Marlinspike. <fo:inline>Simplifying OTR deniability</fo:inline>. <fo:inline>July 2013</fo:inline>. <fo:basic-link color="blue" external-destination="https://whispersystems.org/blog/ simplifying-otr-deniability/">https://whispersystems.org/blog/ simplifying-otr-deniability/</fo:basic-link>. Accessed: 2016-05-10.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib19"><fo:list-item-label end-indent="label-end()"><fo:block>[19] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Moxie Marlinspike. <fo:inline>Private Group Messaging</fo:inline>. <fo:inline>May 2014</fo:inline>. <fo:basic-link color="blue" external-destination="https://whispersystems.org/blog/private-groups/">https://whispersystems.org/blog/private-groups/</fo:basic-link>. Accessed: 2016-04-07.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib20"><fo:list-item-label end-indent="label-end()"><fo:block>[20] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Moxie Marlinspike. <fo:inline>Signal on the outside, Signal on the inside</fo:inline>. <fo:inline>March 2016</fo:inline>. <fo:basic-link color="blue" external-destination="https://whispersystems.org/blog/signal-inside-and-out/">https://whispersystems.org/blog/signal-inside-and-out/</fo:basic-link>. Accessed: 2016-04-07.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib21"><fo:list-item-label end-indent="label-end()"><fo:block>[21] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Kevin Smith, Matthew Wild. <fo:inline>XEP-0313: Message Archive Management</fo:inline>. <fo:inline>Standards Track, XMPP Standards Foundation</fo:inline>, <fo:inline>March 2016</fo:inline>. <fo:basic-link color="blue" external-destination="https://xmpp.org/extensions/ xep-0313.html">https://xmpp.org/extensions/
xep-0313.html</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib22"><fo:list-item-label end-indent="label-end()"><fo:block>[22] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Alfred Menezes, Berkant Ustaoglu. <fo:inline>On reusing ephemeral keys in Diffie-Hellman key agreement
protocols</fo:inline>, <fo:inline font-style="italic">International Journal of Applied Cryptography</fo:inline>, <fo:inline>2(2):154–158,
2010</fo:inline>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib23"><fo:list-item-label end-indent="label-end()"><fo:block>[23] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt"> NIST. <fo:inline>Announcing the Advanced Encryption Standard (AES)</fo:inline>. <fo:inline>Technical
report, NIST</fo:inline>, <fo:inline>November 2001</fo:inline>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib24"><fo:list-item-label end-indent="label-end()"><fo:block>[24] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Trevor Perrin. <fo:inline>Double Ratchet Algorithm</fo:inline>. <fo:basic-link color="blue" external-destination="https://github.com/trevp/doubleratchet/wiki">https://github.com/trevp/doubleratchet/wiki</fo:basic-link>. Accessed: 2016-04-07.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib25"><fo:list-item-label end-indent="label-end()"><fo:block>[25] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Lance Stout, Peter Saint-Andre. <fo:inline>XEP-0234: Jingle File Transfer</fo:inline>. <fo:inline>Standards Track, XMPP Standards
Foundation</fo:inline>, <fo:inline>March 2016</fo:inline>. <fo:basic-link color="blue" external-destination="https://xmpp.org/extensions/xep-0234.html">https://xmpp.org/extensions/xep-0234.html</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib26"><fo:list-item-label end-indent="label-end()"><fo:block>[26] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Peter Saint-Andre. <fo:inline>Extensible Messaging and Presence Protocol (XMPP):
Core</fo:inline>. <fo:inline>RFC 6120,
RFC Editor</fo:inline>, <fo:inline>March 2011</fo:inline>. <fo:basic-link color="blue" external-destination="https://www.rfc-editor.org/rfc/rfc6120.txt">https://www.rfc-editor.org/rfc/rfc6120.txt</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib27"><fo:list-item-label end-indent="label-end()"><fo:block>[27] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Peter Saint-Andre. <fo:inline>Extensible Messaging and Presence Protocol (XMPP):
Core</fo:inline>. <fo:inline>RFC 6122,
RFC Editor</fo:inline>, <fo:inline>March 2011</fo:inline>. <fo:basic-link color="blue" external-destination="https://www.rfc-editor.org/rfc/rfc6122.txt">https://www.rfc-editor.org/rfc/rfc6122.txt</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib28"><fo:list-item-label end-indent="label-end()"><fo:block>[28] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Peter Saint-Andre. <fo:inline>Extensible Messaging and Presence Protocol (XMPP): Instant
Messaging and Presence</fo:inline>. <fo:inline>RFC 6121, RFC Editor</fo:inline>, <fo:inline>March 2011</fo:inline>. <fo:basic-link color="blue" external-destination="https://www.rfc-editor.org/ rfc/rfc6121.txt">https://www.rfc-editor.org/ rfc/rfc6121.txt</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib29"><fo:list-item-label end-indent="label-end()"><fo:block>[29] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Andreas Straub. <fo:inline>XEP-xxxx: OMEMO Encryption</fo:inline>. <fo:inline>ProtoXEP, XMPP Standards Foundation</fo:inline>, <fo:inline>October 2015</fo:inline>. <fo:basic-link color="blue" external-destination="https://xmpp.org/extensions/inbox/omemo.html">https://xmpp.org/extensions/inbox/omemo.html</fo:basic-link>. </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib30"><fo:list-item-label end-indent="label-end()"><fo:block>[30] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt"><fo:inline>Open Whisper Systems</fo:inline>. <fo:inline>Signal Protocol library for Java/Android</fo:inline>. <fo:basic-link color="blue" external-destination="https://github.com/ WhisperSystems/libsignal-protocol-java">https://github.com/ WhisperSystems/libsignal-protocol-java</fo:basic-link>. Accessed: 2016-05-10.</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt" id="bib31"><fo:list-item-label end-indent="label-end()"><fo:block>[31] </fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block margin-bottom="5pt">Zooko Wilcox-O’Hearn. <fo:inline>Attacks on Convergent Encryption</fo:inline>. <fo:inline>Technical report, Tahoe-LAFS</fo:inline>, <fo:inline>March 2008</fo:inline>. <fo:basic-link color="blue" external-destination="https://tahoe-lafs.org/hacktahoelafs/drew perttula.html">https://tahoe-lafs.org/hacktahoelafs/drew perttula.html</fo:basic-link>. Accessed: 2016-05-10.</fo:block></fo:list-item-body></fo:list-item></fo:list-block>
</fo:block>
<fo:block margin-bottom="1.5cm" break-before="page" id="minorcorrections">
<fo:block keep-with-next.within-page="always" font-weight="bold" font-size="16pt" margin-bottom="1cm" background-color="orange"><fo:inline> Appendix 1</fo:inline>   Minor corrections</fo:block>
<fo:block margin-bottom="5pt">During my review of the OMEMO documentation, I noted some minor errors in the
specification, most of which are typographical errors. This appendix
contains a list of corrections. None of these errors affect the security of
the protocol in any way.</fo:block>
<fo:block margin-bottom="5pt">In the OMEMO XEP:</fo:block>
<fo:list-block provisional-distance-between-starts="0.75cm" provisional-label-separation="2.5mm" space-after="12pt" start-indent="1cm"><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 4.5: both own devices (should be: both owned devices)</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 6: axoltol (should have been: axolotl; should be: “the Signal
Protocol”) </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Appendix G: duplicate references </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Inconsistent usage of “.” (period) at the end of list items</fo:block></fo:list-item-body></fo:list-item></fo:list-block>
<fo:block margin-bottom="5pt">In the OMEMO file transfer XEP:</fo:block>
<fo:list-block provisional-distance-between-starts="0.75cm" provisional-label-separation="2.5mm" margin-bottom="1.5cm" space-after="12pt" start-indent="1cm"><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 3: Remeo and Juliet (should be: Romeo and Juliet) </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 3: file tranfer (should be: file transfer) </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 3, Example 1: <fo:inline font-family="LiberationMono" font-size="90%" color="black" background-color="#eeeeee">&lt;/file&gt;</fo:inline> has wrong
indentation </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 5: intilization (should be: initialization) </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 5: the hash of encrypted file (should be: the hash of the
encrypted file)</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 5: rangend tranfer (should be: ranged transfer) </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 7: might not the Device ID (should be (?): might not have)</fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Section 8: Last list item is missing a “.” (period) </fo:block></fo:list-item-body></fo:list-item><fo:list-item margin-bottom="5pt"><fo:list-item-label end-indent="label-end()"><fo:block>•</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>The document is missing a reference to the OMEMO XEP</fo:block></fo:list-item-body></fo:list-item></fo:list-block>
</fo:block>
</fo:block><fo:block id="EndOfDoc"/></fo:flow></fo:page-sequence></fo:root>
View Git Blame Copy Permalink