No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0384.xml 23KB

  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM "xep.ent">
  4. %ents;
  5. ]>
  6. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  7. <xep>
  8. <header>
  9. <title>OMEMO Encryption</title>
  10. <abstract>This specification defines a protocol for end-to-end encryption in one-on-one chats that may have multiple clients per account.</abstract>
  12. <number>0384</number>
  13. <status>Experimental</status>
  14. <type>Standards Track</type>
  15. <sig>Standards</sig>
  16. <approver>Council</approver>
  17. <dependencies>
  18. <spec>XMPP Core</spec>
  19. <spec>XEP-0163</spec>
  20. </dependencies>
  21. <supersedes/>
  22. <supersededby/>
  23. <shortname>OMEMO</shortname>
  24. <author>
  25. <firstname>Andreas</firstname>
  26. <surname>Straub</surname>
  27. <email></email>
  28. <jid></jid>
  29. </author>
  30. <revision>
  31. <version>0.2</version>
  32. <date>2017-06-02</date>
  33. <initials>dg</initials>
  34. <remark>
  35. <p>Depend on SignalProtocol instead of Olm.</p>
  36. <p>Changed to eu.siacs.conversations.axolotl Namespace which is currently used in the wild</p>
  37. </remark>
  38. </revision>
  39. <revision>
  40. <version>0.1</version>
  41. <date>2016-12-07</date>
  42. <initials>XEP Editor: ssw</initials>
  43. <remark><p>Initial version approved by the council.</p></remark>
  44. </revision>
  45. <revision>
  46. <version>0.0.2</version>
  47. <date>2016-09-22</date>
  48. <initials>ssw, dg</initials>
  49. <remark><p>Depend on Olm instead of Axolotl.</p></remark>
  50. </revision>
  51. <revision>
  52. <version>0.0.1</version>
  53. <date>2015-10-25</date>
  54. <initials>as</initials>
  55. <remark><p>First draft.</p></remark>
  56. </revision>
  57. </header>
  58. <section1 topic='Introduction' anchor='intro'>
  59. <section2 topic='Motivation' anchor='intro-motivation'>
  60. <p>
  61. There are two main end-to-end encryption schemes in common use in the XMPP
  62. ecosystem, Off-the-Record (OTR) messaging (&xep0364;) and OpenPGP
  63. (&xep0027;). OTR has significant usability drawbacks for inter-client
  64. mobility. As OTR sessions exist between exactly two clients, the chat
  65. history will not be synchronized across other clients of the involved
  66. parties. Furthermore, OTR chats are only possible if both participants are
  67. currently online, due to how the rolling key agreement scheme of OTR
  68. works. OpenPGP, while not suffering from these mobility issues, does not
  69. provide any kind of forward secrecy and is vulnerable to replay attacks.
  70. Additionally, PGP over XMPP uses a custom wireformat which is defined by
  71. convention rather than standardization, and involves quite a bit of
  72. external complexity.
  73. </p>
  74. <p>
  75. This XEP defines a protocol that leverages the SignalProtocol encryption to provide
  76. multi-end to multi-end encryption, allowing messages to be synchronized
  77. securely across multiple clients, even if some of them are offline. The SignalProtocol
  78. is a cryptographic double ratched protocol based on work by Trevor Perrin
  79. and Moxie Marlinspike first published as the Axolotl protocol. While the
  80. protocol itself has specifications in the public domain, the
  81. protobuf-based wire format of the signal protocol is not fully
  82. documented. The signal protocol currently only exists in GPLv3-licensed
  83. implementations maintained by OpenWhisperSystems.
  84. </p>
  85. </section2>
  86. <section2 topic='Overview' anchor='intro-overview'>
  87. <p>
  88. The general idea behind this protocol is to maintain separate,
  89. long-standing SignalProtocol-encrypted sessions with each device of each contact
  90. (as well as with each of our other devices), which are used as secure key
  91. transport channels. In this scheme, each message is encrypted with a
  92. fresh, randomly generated encryption key. An encrypted header is added to
  93. the message for each device that is supposed to receive it. These headers
  94. simply contain the key that the payload message is encrypted with, and
  95. they are seperately encrypted using the session corresponding to the
  96. counterpart device. The encrypted payload is sent together with the
  97. headers as a &lt;message&gt; stanza. Individual recipient devices can
  98. decrypt the header item intended for them, and use the contained payload
  99. key to decrypt the payload message.
  100. </p>
  101. <p>
  102. As the encrypted payload is common to all recipients, it only has to be
  103. included once, reducing overhead. Furthermore, SignalProtocols’s transparent handling
  104. of messages that were lost or received out of order, as well as those sent
  105. while the recipient was offline, is maintained by this protocol. As a
  106. result, in combination with &xep0280; and &xep0313;, the desired property
  107. of inter-client history synchronization is achieved.
  108. </p>
  109. <p>
  110. OMEMO currently uses version 3 SignalProtocol. Instead of a Signal key
  111. server, &xep0163; (PEP) is used to publish key data.
  112. </p>
  113. </section2>
  114. </section1>
  115. <section1 topic='Requirements' anchor='reqs'>
  116. <ul>
  117. <li>Provide forward secrecy</li>
  118. <li>Ensure chat messages can be deciphered by all (capable) clients of both parties</li>
  119. <li>Be usable regardless of the participants' online statuses</li>
  120. <li>Provide a method to exchange auxilliary keying material. This could for example be used to secure encrypted file transfers.</li>
  121. </ul>
  122. </section1>
  123. <section1 topic='Glossary' anchor='glossary'>
  124. <section2 topic='General Terms' anchor='glossary-general'>
  125. <dl>
  126. <di><dt>Device</dt><dd>A communication end point, i.e. a specific client instance</dd></di>
  127. <di><dt>OMEMO element</dt><dd>An &lt;encrypted&gt; element in the eu.siacs.conversations.axolotl namespace. Can be either MessageElement or a KeyTransportElement</dd></di>
  128. <di><dt>MessageElement</dt><dd>An OMEMO element that contains a chat message. Its &lt;payload&gt;, when decrypted, corresponds to a &lt;message&gt;'s &lt;body&gt;.</dd></di>
  129. <di><dt>KeyTransportElement</dt><dd>An OMEMO element that does not have a &lt;payload&gt;. It contains a fresh encryption key, which can be used for purposes external to this XEP.</dd></di>
  130. <di><dt>Bundle</dt><dd>A collection of publicly accessible data that can be used to build a session with a device, namely its public IdentityKey, a signed PreKey with corresponding signature, and a list of (single use) PreKeys.</dd></di>
  131. <di><dt>rid</dt><dd>The device id of the intended recipient of the containing &lt;key&gt;</dd></di>
  132. <di><dt>sid</dt><dd>The device id of the sender of the containing OMEMO element</dd></di>
  133. </dl>
  134. </section2>
  135. <section2 topic='SignalProtocol-specific' anchor='glossary-signalprotocol'>
  136. <dl>
  137. <di><dt>IdentityKey</dt><dd>Per-device public/private key pair used to authenticate communications</dd></di>
  138. <di><dt>PreKey</dt><dd>A Diffie-Hellman public key, published in bulk and ahead of time</dd></di>
  139. <di><dt>PreKeySignalMessage</dt><dd>An encrypted message that includes the initial key exchange. This is used to transparently build sessions with the first exchanged message.</dd></di>
  140. <di><dt>SignalMessage</dt><dd>An encrypted message</dd></di>
  141. </dl>
  142. </section2>
  143. </section1>
  144. <section1 topic='Use Cases' anchor='usecases'>
  145. <section2 topic='Setup' anchor='usecases-setup'>
  146. <p>
  147. The first thing that needs to happen if a client wants to start using
  148. OMEMO is they need to generate an IdentityKey and a Device ID. The
  149. IdentityKey is a &curve25519; public/private Key pair. The Device ID is a
  150. randomly generated integer between 1 and 2^31 - 1.
  151. </p>
  152. </section2>
  153. <section2 topic='Discovering peer support' anchor='usecases-discovering'>
  154. <p>In order to determine whether a given contact has devices that support OMEMO, the devicelist node in PEP is consulted. Devices MUST subscribe to 'eu.siacs.conversations.axolotl.devicelist' via PEP, so that they are informed whenever their contacts add a new device. They MUST cache the most up-to-date version of the devicelist.</p>
  155. <example caption='Devicelist update received by subscribed clients'><![CDATA[
  156. <message from='juliet@capulet.lit'
  157. to='romeo@montague.lit'
  158. type='headline'
  159. id='update_01'>
  160. <event xmlns=''>
  161. <items node='eu.siacs.conversations.axolotl.devicelist'>
  162. <item>
  163. <list xmlns='eu.siacs.conversations.axolotl'>
  164. <device id='12345' />
  165. <device id='4223' />
  166. </list>
  167. </item>
  168. </items>
  169. </event>
  170. </message>]]></example>
  171. </section2>
  172. <section2 topic='Announcing support' anchor='usecases-announcing'>
  173. <p>In order for other devices to be able to initiate a session with a given device, it first has to announce itself by adding its device ID to the devicelist PEP node. </p>
  174. <example caption='Adding the own device ID to the list'><![CDATA[
  175. <iq from='juliet@capulet.lit' type='set' id='announce1'>
  176. <pubsub xmlns=''>
  177. <publish node='eu.siacs.conversations.axolotl.devicelist'>
  178. <item>
  179. <list xmlns='eu.siacs.conversations.axolotl'>
  180. <device id='12345' />
  181. <device id='4223' />
  182. <device id='31415' />
  183. </list>
  184. </item>
  185. </publish>
  186. </pubsub>
  187. </iq>]]></example>
  188. <p>This step presents the risk of introducing a race condition: Two devices might simultaneously try to announce themselves, unaware of the other's existence. The second device would overwrite the first one. To mitigate this, devices MUST check that their own device ID is contained in the list whenever they receive a PEP update from their own account. If they have been removed, they MUST reannounce themselves.</p>
  189. <p>Furthermore, a device MUST announce it's IdentityKey, a signed PreKey, and a list of PreKeys in a separate, per-device PEP node. The list SHOULD contain 100 PreKeys, but MUST contain no less than 20.</p>
  190. <example caption='Announcing bundle information'><![CDATA[
  191. <iq from='juliet@capulet.lit' type='set' id='announce2'>
  192. <pubsub xmlns=''>
  193. <publish node='eu.siacs.conversations.axolotl.bundles:31415'>
  194. <item>
  195. <bundle xmlns='eu.siacs.conversations.axolotl'>
  196. <signedPreKeyPublic signedPreKeyId='1'>
  197. BASE64ENCODED...
  198. </signedPreKeyPublic>
  199. <signedPreKeySignature>
  200. BASE64ENCODED...
  201. </signedPreKeySignature>
  202. <identityKey>
  203. BASE64ENCODED...
  204. </identityKey>
  205. <prekeys>
  206. <preKeyPublic preKeyId='1'>
  207. BASE64ENCODED...
  208. </preKeyPublic>
  209. <preKeyPublic preKeyId='2'>
  210. BASE64ENCODED...
  211. </preKeyPublic>
  212. <preKeyPublic preKeyId='3'>
  213. BASE64ENCODED...
  214. </preKeyPublic>
  215. <!-- ... -->
  216. </prekeys>
  217. </bundle>
  218. </item>
  219. </publish>
  220. </pubsub>
  221. </iq>]]></example>
  222. </section2>
  223. <section2 topic='Building a session' anchor='usecases-building'>
  224. <p>In order to build a session with a device, their bundle information is fetched.</p>
  225. <example caption="Fetching a device's bundle information"><![CDATA[
  226. <iq type='get'
  227. from='romeo@montague.lit'
  228. to='juliet@capulet.lit'
  229. id='fetch1'>
  230. <pubsub xmlns=''>
  231. <items node='eu.siacs.conversations.axolotl.bundles:31415'/>
  232. </pubsub>
  233. </iq>]]></example>
  234. <p>A random preKeyPublic entry is selected, and used to build a SignalProtocol session.</p>
  235. </section2>
  236. <section2 topic='Sending a message' anchor='usecases-messagesend'>
  237. <p>
  238. In order to send a chat message, its &lt;body&gt; first has to be
  239. encrypted. The client MUST use fresh, randomly generated key/IV pairs with
  240. AES-128 in Galois/Counter Mode (GCM).
  241. The 16 bytes key and the GCM authentication tag (The tag SHOULD have at least
  242. 128 bit) are concatenated and for each intended recipient device,
  243. i.e. both own devices as well as devices associated with the contact, the
  244. result of this concatenation is encrypted using the corresponding
  245. long-standing SignalProtocol session. Each encrypted payload key/authentication tag
  246. tuple is tagged with the recipient device's ID. The key element MUST be
  247. tagged with a prekey attribute set to true if a PreKeySignalMessage is being
  248. used. This is all serialized into a MessageElement, which is transmitted
  249. in a &lt;message&gt; as follows:
  250. </p>
  251. <example caption="Sending a message"><![CDATA[
  252. <message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
  253. <encrypted xmlns='eu.siacs.conversations.axolotl'>
  254. <header sid='27183'>
  255. <key rid='31415'>BASE64ENCODED...</key>
  256. <key prekey="true" rid='12321'>BASE64ENCODED...</key>
  257. <!-- ... -->
  258. <iv>BASE64ENCODED...</iv>
  259. </header>
  260. <payload>BASE64ENCODED</payload>
  261. </encrypted>
  262. <store xmlns='urn:xmpp:hints'/>
  263. </message>]]></example>
  264. </section2>
  265. <section2 topic='Sending a key' anchor='usecases-keysend'>
  266. <p>
  267. The client may wish to transmit keying material to the contact. This first
  268. has to be generated. The client MUST generate a fresh, randomly generated
  269. key/IV pair. The 16 bytes key and the GCM authentication tag (The tag
  270. SHOULD have at least 128 bit) are concatenated and for each intended
  271. recipient device, i.e. both own devices as well as devices associated
  272. with the contact, this key is encrypted using the corresponding
  273. long-standing SignalProtocol session. Each encrypted payload key/authentication tag
  274. tuple is tagged with the recipient device's ID. The key element MUST be
  275. tagged with a prekey attribute set to true if a PreKeySignalMessage is being
  276. used This is all serialized into a KeyTransportElement, omitting the
  277. &lt;payload&gt; as follows:
  278. </p>
  279. <example caption="Sending a key"><![CDATA[
  280. <encrypted xmlns='eu.siacs.conversations.axolotl'>
  281. <header sid='27183'>
  282. <key rid='31415'>BASE64ENCODED...</key>
  283. <key prekey="true" rid='12321'>BASE64ENCODED...</key>
  284. <!-- ... -->
  285. <iv>BASE64ENCODED...</iv>
  286. </header>
  287. </encrypted>]]></example>
  288. <p>This KeyTransportElement can then be sent over any applicable transport mechanism.</p>
  289. </section2>
  290. <section2 topic='Receiving a message' anchor='usecases-receiving'>
  291. <p>When an OMEMO element is received, the client MUST check whether there is a &lt;key&gt; element with an rid attribute matching its own device ID. If this is not the case, the element MUST be silently discarded. If such an element exists, the client checks whether the element's contents are a PreKeySignalMessage.</p>
  292. <p>If this is the case, a new session is built from this received element. The client SHOULD then republish their bundle information, replacing the used PreKey, such that it won't be used again by a different client. If the client already has a session with the sender's device, it MUST replace this session with the newly built session. The client MUST delete the private key belonging to the PreKey after use.</p>
  293. <p>If the element's contents are a SignalMessage, and the client has a session with the sender's device, it tries to decrypt the SignalMessage using this session. If the decryption fails or if the element's contents are not a SignalMessage either, the OMEMO element MUST be silently discarded.</p>
  294. <p>If the OMEMO element contains a &lt;payload&gt;, it is an OMEMO message element. The client tries to decrypt the base64 encoded contents using the key and the authentication tag extracted from the &lt;key&gt; element. If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the &lt;body&gt; of the received message.</p>
  295. <p>If the OMEMO element does not contain a &lt;payload&gt;, the client has received a KeyTransportElement. The key extracted from the &lt;key&gt; element can then be used for other purposes (e.g. encrypted file transfer).</p>
  296. </section2>
  297. </section1>
  298. <section1 topic='Business Rules' anchor='rules'>
  299. <p>Before publishing a freshly generated Device ID for the first time, a device MUST check whether that Device ID already exists, and if so, generate a new one.</p>
  300. <p>Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial PreKeySignalMessage later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message. </p>
  301. <p>As there are no explicit error messages in this protocol, if a client does receive a PreKeySignalMessage using an invalid PreKey, they SHOULD respond with a KeyTransportElement, sent in a &lt;message&gt; using a PreKeySignalMessage. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session.</p>
  302. <p>If a PreKeySignalMessage is received as part of a &xep0313; catch-up and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after MAM catch-up is completed. If this is done, the client MUST then also send a KeyTransportMessage using a PreKeySignalMessage before sending any payloads using this session, to trigger re-keying. (as above) This practice can mitigate the previously mentioned race condition by preventing message loss.</p>
  303. <p>As the asynchronous nature of OMEMO allows decryption at a later time to currently offline devices client SHOULD include a &xep0334; &lt;store /&gt; hint in their OMEMO messages. Otherwise, server implementations of &xep0313; will generally not retain OMEMO messages, since they do not contain a &lt;body /&gt;</p>
  304. </section1>
  305. <section1 topic='Implementation Notes' anchor='impl'>
  306. <!-- TODO: I think this is still true? -->
  307. <p>
  308. The SignalProtocol-library uses a trust model that doesn't work very well with
  309. OMEMO. For this reason it may be desirable to have the library consider all
  310. keys trusted, effectively disabling its trust management. This makes it
  311. necessary to implement trust handling oneself.
  312. </p>
  313. </section1>
  314. <section1 topic='Security Considerations' anchor='security'>
  315. <p>Clients MUST NOT use a newly built session to transmit data without user intervention. If a client were to opportunistically start using sessions for sending without asking the user whether to trust a device first, an attacker could publish a fake device for this user, which would then receive copies of all messages sent by/to this user. A client MAY use such "not (yet) trusted" sessions for decryption of received messages, but in that case it SHOULD indicate the untrusted nature of such messages to the user.</p>
  316. <p>When prompting the user for a trust decision regarding a key, the client SHOULD present the user with a fingerprint in the form of a hex string, QR code, or other unique representation, such that it can be compared by the user.</p>
  317. <p>While it is RECOMMENDED that clients postpone private key deletion until after MAM catch-up and this standards mandates that clients MUST NOT use duplicate-PreKey sessions for sending, clients MAY delete such keys immediately for security reasons. For additional information on potential security impacts of this decision, refer to <note>Menezes, Alfred, and Berkant Ustaoglu. "On reusing ephemeral keys in Diffie-Hellman key agreement protocols." International Journal of Applied Cryptography 2, no. 2 (2010): 154-158.</note>.</p>
  318. <p>
  319. In order to be able to handle out-of-order messages, the SignalProtocol stack has to
  320. cache the keys belonging to "skipped" messages that have not been seen yet.
  321. It is up to the implementor to decide how long and how many of such keys to
  322. keep around.
  323. </p>
  324. </section1>
  325. <section1 topic='IANA Considerations' anchor='iana'>
  326. <p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA). </p>
  327. </section1>
  328. <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  329. <section2 topic='Protocol Namespaces' anchor='namespaces'>
  330. <p>This specification defines the following XMPP namespaces:</p>
  331. <ul>
  332. <li>eu.siacs.conversations.axolotl</li>
  333. </ul>
  334. </section2>
  335. <section2 topic='Protocol Versioning' anchor='versioning'>
  336. &NSVER;
  337. </section2>
  338. </section1>
  339. <section1 topic='XML Schema' anchor='schema'>
  340. <code><![CDATA[
  341. <xml version="1.0" encoding="utf8">
  342. <xs:schema xmlns:xs=""
  343. targetNamespace="eu.siacs.conversations.axolotl"
  344. xmlns="eu.siacs.conversations.axolotl">
  345. <xs:element name="encrypted">
  346. <xs:element name="header">
  347. <xs:attribute name="sid" type="xs:integer"/>
  348. <xs:complexType>
  349. <xs:sequence>
  350. <xs:element name="key" type="xs:base64Binary" maxOccurs="unbounded">
  351. <xs:attribute name="rid" type="xs:integer" use="required"/>
  352. <xs:attribute name="prekey" type="xs:boolean"/>
  353. </xs:element>
  354. <xs:element name="iv" type="xs:base64Binary"/>
  355. </xs:complexType>
  356. </xs:element>
  357. <xs:element name="payload" type="xs:base64Binary" minOccurs="0"/>
  358. </xs:element>
  359. <xs:element name="list">
  360. <xs:complexType>
  361. <xs:sequence>
  362. <xs:element name="device" maxOccurs="unbounded">
  363. <xs:attribute name="id" type="integer" use="required"/>
  364. </xs:element>
  365. </xs:sequence>
  366. </xs:complexType>
  367. </xs:element>
  368. <xs:element name="bundle">
  369. <xs:complexType>
  370. <xs:sequence>
  371. <xs:element name="signedPreKeyPublic" type="base64Binary">
  372. <xs:attribute name="id" type="integer"/>
  373. </xs:element>
  374. <xs:element name="signedPreKeySignature" type="base64Binary"/>
  375. <xs:element name="identityKey" type="base64Binary"/>
  376. <xs:element name="prekeys">
  377. <xs:complexType>
  378. <xs:sequence>
  379. <xs:element name="preKeyPublic" type="base64Binary" maxOccurs="unbounded">
  380. <xs:attribute name="id" type="integer" use="required"/>
  381. </xs:element>
  382. </xs:sequence>
  383. </xs:complexType>
  384. </xs:element>
  385. </xs:sequence>
  386. </xs:complexType>
  387. </xs:element>
  388. </xs:schema>
  389. ]]></code>
  390. </section1>
  391. <section1 topic='Acknowledgements' anchor='ack'>
  392. <p>Big thanks to Daniel Gultsch for mentoring me during the development of this protocol. Thanks to Thijs Alkemade and Cornelius Aschermann for talking through some of the finer points of the protocol with me. And lastly I would also like to thank Sam Whited, Holger Weiss, and Florian Schmaus for their input on the standard.</p>
  393. </section1>
  394. </xep>