Difference between revisions of "XMPP E2E Security"

From XMPP WIKI
Jump to navigation Jump to search
 
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page aims to provide an overview, comparison and evaluation of existing and proposed end-to-end security solutions for XMPP, after providing the characteristings of the XMPP setting with regard to communication and the security of it.
This page aims to provide an overview, comparison and evaluation of existing and proposed end-to-end security solutions for XMPP, after providing the characteristings of the XMPP setting with regard to communication and the security of it.


= Security properties =
= Proposals =


# [http://en.wikipedia.org/wiki/Information_security#Authenticity Authenticity]
== XEP-0384: OMEMO Encryption (Signal / Text Secure) ==
# [http://en.wikipedia.org/wiki/Information_security#Integrity Integrity]
# [http://en.wikipedia.org/wiki/Encryption Encryption]
# [http://en.wikipedia.org/wiki/Forward_secrecy Forward secrecy]
# [http://en.wikipedia.org/wiki/Deniable_encryption#Malleable_encryption Malleable encryption]


'''Recommendation:''' Implement if you need forward secrecy.


= Compatibility of Security Properties with XMPP Features =
OMEMO is based on the Signal double ratchet and provides forward secrecy, compatibility with history retrieval for devices that are already part of the ratchet, and a number of other benefits over legacy encryption mechanisms. It has had an independent third party audit (see related links at bottom).
== One-to-One Chat ==


== Multi-User Chat ==
== XEP-0373: OpenPGP for XMPP / XEP-0374: OpenPGP for XMPP Instant Messaging ==


== Multiple resources ==
'''Recommendation:''' Exploratory implementations are encouraged.
Using multiple resources almost certainly contradicts having forward secrecy:
* Forward secrecy uses short-lived (decryption) keys that are negotiated between two endpoints (clients)
* Multiple resources must use the same decryption key to be able to decrypt messages originally sent to the other resource after a spontaneous resource switch
* Multiple resources must use the same signing key to avoid multiple authentications between the same partners using different resources
Either the resources would have to exchange their key material frequently (themselves retaining the forward secrecy) or share a long-living signing key that is used for authentication.


Of course, this assumes that you only have to authenticate the user/JID once and not for every resource. If you are willing to authenticate every resource of your communication partner separately, the problem is reduced to that of a Multi-User Chat.
The OpenPGP for XMPP (OX) specification currently consists of a baseline specification: [https://xmpp.org/extensions/xep-0373.html XEP-0373] and a profile for Instant Messaging specification [https://xmpp.org/extensions/xep-0374.html XEP-0374]. It is under active development and thus subject to change although can be considered pretty stable regarding most parts.


= Proposals =
OX attempts to fix the various security design flaws of XEP-0027, and additionally specifies features like "arbitrary extension element" verification and protection.
== XEP-0027 (PGP) ==
One of the first proposals for end-to-end security is based on [http://en.wikipedia.org/wiki/Pretty_Good_Privacy PGP] and described in [http://xmpp.org/extensions/xep-0027.html XEP-0027].


The way XEP-0027 uses PGP, it doesn't provide protection from replay attacks. It also only encrypts messages and doesn't sign them, so they could be replaced with different correctly encrypted messages on the wire.[http://logs.xmpp.org/xsf/140301/#11:22:52 (Source: chat in xsf@m.x.o)] Thus it has been obsoleted by the XMPP Council in it's [http://logs.xmpp.org/council/2014-03-12/#16:08:19 meeting on 2014-03-12].
Implementations are available for Gajim and Smack, and have been successfully tested against each other for interoperability.


== RFC 3923 (S/MIME) ==
== XEP-0027 (Legacy OpenPGP) ==


== XEP-0200 (Stanza Encryption) ==
'''Recommendation:''' Do '''not implement''', as the specification has [https://xmpp.org/extensions/xep-0027.html#security serious security issues].
The Stanza Encryption, as described in [http://xmpp.org/extensions/xep-0200.html XEP-0200] is a general framework for securing arbitrary stanzas in a one-to-one established session. It relies on other XEPs to provide the necessary parameters like key material and algorithms, but itself supports re-keying. This XEP as well as those required to use it are very abstract to support a wide range of algorithms and methods.


=== XEP-0116 (ESession) ===
One of the first proposals for end-to-end security is based on [http://en.wikipedia.org/wiki/Pretty_Good_Privacy PGP] and described in [http://xmpp.org/extensions/xep-0027.html XEP-0027].
For usage between two online partners, the ESession protocol as defined in [http://xmpp.org/extensions/xep-0116.html XEP-0116] specifies how to exchange parameters for XEP-0200 using [http://xmpp.org/extensions/xep-0155.html XEP-0155 (Stanza Session Negotiation)]. Its support for various methods to authenticate the partner (or letting that be) makes it very complex to implement.  


=== XEP-0217 (Simple ESession) ===
The way XEP-0027 uses PGP, it doesn't provide protection from replay attacks. It also only encrypts messages and doesn't sign them, so they could be replaced with different correctly encrypted messages on the wire.[http://logs.xmpp.org/xsf/140301/#11:22:52 (Source: chat in xsf@m.x.o)] Thus it has been obsoleted by the XMPP Council in it's [http://logs.xmpp.org/council/2014-03-12/#16:08:19 meeting on 2014-03-12].
To simplify implementation, the simpler [http://xmpp.org/extensions/xep-0217.html XEP-0217] defines only a subset of XEP-0116 with exactly one method (Short authentication codes, SAS) to authenticate the partner, and thus is compatible to XEP-0116 implementations.
 
=== XEP-0187 (Offline ESession) ===
For usage with offline messages, the offline version of ESessions as defined in [http://xmpp.org/extensions/xep-0187.html XEP-0187] uses [http://xmpp.org/extensions/xep-0189.html XEP-0189 (Public Key Publishing)] via PEP (Personal Eventing Protocol) instead of the active initiation of an ESession.
 
== XTLS ==
XTLS, as described in [https://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption draft-meyer-xmpp-e2e-encryption], uses Jingle to negotiate an end-to-end stream between two XMPP clients and establishes a TLS connection over this stream. This stream can also reside within existing connections, with [http://xmpp.org/extensions/xep-0047.html In-Band Bytestreams].
 
== miller-e2e ==
This is the protocol described in [http://tools.ietf.org/html/draft-miller-xmpp-e2e draft-miller-xmpp-e2e], which allows encryption and signing of arbitrary XMPP stanzas.


== OTR (Off-the-record Messaging) ==
== OTR (Off-the-record Messaging) ==
[https://otr.cypherpunks.ca/ OTR] is a crypto protocol, specifically designed to secure instant messaging conversations.


== TS (Text Secure Protocol) ==
'''Recommendation:''' do not implement unless compatibility with legacy clients is required.
Text Secure is a rather new open mobile messenger which has an openly specified protocol. This protocol is described [https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2 here].
.


== SCIMP ( Silent Circle Instant Messaging Protocol) ==
[https://otr.cypherpunks.ca/ OTR] is a crypto protocol, specifically designed to secure instant messaging conversations. Its usage in XMPP is documented (but not standardized) in https://xmpp.org/extensions/xep-0364.html
[https://silentcircle.com/web/scimp-protocol/ SCIMP] is the cryptographic protocol used by Silent Text, which enables private conversations over standard XMPP.


= Comparative Overview =
= Comparative Overview =
Line 65: Line 40:
!colspan="5" |Security property
!colspan="5" |Security property
!colspan="2" |Communication patterns
!colspan="2" |Communication patterns
!colspan="4" |Compatibility with XMPP
!colspan="3" |Compatibility with XMPP
|-
|-
!Authenticity
![https://en.wikipedia.org/wiki/Digital_signature#Authentication Authenticity]
!Integrity
![https://en.wikipedia.org/wiki/Information_security#Integrity Integrity]
!Encryption  
![https://en.wikipedia.org/wiki/Encryption Encryption]
!Forward secrecy
![https://en.wikipedia.org/wiki/Forward_secrecy Forward secrecy]
!Malleable encryption
![https://en.wikipedia.org/wiki/Malleability_(cryptography) Malleability]
!One-to-One
!One-to-One
!Groupchat
!Groupchat
!Online chats
!Offline messages
!Offline messages
!Multiple resources
!Multiple resources
!Discovery of support
!Discovery of support
|-
|-
|XEP-0027
|OMEMO (XEP-0384)
|No (messages only encrypted, not signed)
|No
|Yes
|Yes
|No
|Except in the case of a malicious authenticated device
|N/A
|Yes
|Yes
|No
|Yes
|Yes
|By authenticated devices
|Yes
|Yes
|Yes (if same keypair at all resources)
|Yes (Non-anonymous only)
|No
|-
|RFC 3923
|?
|?
|?
|?
|?
|?
|?
|?
|?
|?
|?
|-
|XEP-0200
|Yes
|Yes
|Yes
|Yes
|Yes
|Yes
|-
|XEP-0374: OpenPGP for XMPP Instant Messaging
|Yes
|Yes
|Yes
|Yes
|Yes
|Yes
|No
|No
|Yes (XEP-0116/XEP-217)
|N/A
|Yes (XEP-0187)
|Yes
|No
|Possible and planned, but currently unspecified
|Yes
|Yes
|-
|XTLS
|?
|?
|?
|?
|?
|?
|?
|?
|?
|?
|?
|-
|miller-e2e
|Optional (Nesting signature/encryption)
|Yes
|Yes
|Yes
|Yes
|-
|Legacy PGP (XEP-0027)
|No (messages only encrypted, not signed)
|No
|No
|Yes
|No
|No
|N/A
|Yes
|Yes
|Possible
|No
|Yes
|Yes
|Yes (if same keypair at all resources)
|No
|No
|Yes
|Yes
|-
|-
|OTR
|OTR
Line 152: Line 97:
|Yes
|Yes
|No
|No
|Yes
|No
|No
|No
|No
|No
|No
|-
|TS
|?
|?
|?
|?
|?
|?
|?
|?
|?
|?
|?
|-
|SCIMP
|?
|?
|?
|?
|?
|?
|?
|?
|?
|?
|?
|}
|}


Line 187: Line 105:
* https://developer.pidgin.im/wiki/EndToEndXMPPCrypto
* https://developer.pidgin.im/wiki/EndToEndXMPPCrypto
* http://trevp.net/talk_2014_04_02.pdf
* http://trevp.net/talk_2014_04_02.pdf
* https://conversations.im/omemo/audit.pdf


= Discussion =
= Discussion =
If you have any questions or comments regarding this page, please [xmpp:xsf@muc.xmpp.org?join join the XSF chatroom at xsf@muc.xmpp.org].
If you have any questions or comments regarding this page, please [xmpp:xsf@muc.xmpp.org?join join the XSF chatroom at xsf@muc.xmpp.org].
= Abandoned and Legacy E2EE specifications =
Those specifications are very likely not relevant any more. They either gained no adoption or where replaced in favor of newer specifications. They are listed here only for the sake of completeness.
== draft-miller-xmpp-e2e ==
https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/
== ESessions ==
https://xmpp.org/extensions/xep-0187.html
https://xmpp.org/extensions/xep-0188.html
== RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) ==
https://tools.ietf.org/html/rfc3923

Latest revision as of 09:37, 14 November 2018

This page aims to provide an overview, comparison and evaluation of existing and proposed end-to-end security solutions for XMPP, after providing the characteristings of the XMPP setting with regard to communication and the security of it.

Proposals

XEP-0384: OMEMO Encryption (Signal / Text Secure)

Recommendation: Implement if you need forward secrecy.

OMEMO is based on the Signal double ratchet and provides forward secrecy, compatibility with history retrieval for devices that are already part of the ratchet, and a number of other benefits over legacy encryption mechanisms. It has had an independent third party audit (see related links at bottom).

XEP-0373: OpenPGP for XMPP / XEP-0374: OpenPGP for XMPP Instant Messaging

Recommendation: Exploratory implementations are encouraged.

The OpenPGP for XMPP (OX) specification currently consists of a baseline specification: XEP-0373 and a profile for Instant Messaging specification XEP-0374. It is under active development and thus subject to change although can be considered pretty stable regarding most parts.

OX attempts to fix the various security design flaws of XEP-0027, and additionally specifies features like "arbitrary extension element" verification and protection.

Implementations are available for Gajim and Smack, and have been successfully tested against each other for interoperability.

XEP-0027 (Legacy OpenPGP)

Recommendation: Do not implement, as the specification has serious security issues.

One of the first proposals for end-to-end security is based on PGP and described in XEP-0027.

The way XEP-0027 uses PGP, it doesn't provide protection from replay attacks. It also only encrypts messages and doesn't sign them, so they could be replaced with different correctly encrypted messages on the wire.(Source: chat in xsf@m.x.o) Thus it has been obsoleted by the XMPP Council in it's meeting on 2014-03-12.

OTR (Off-the-record Messaging)

Recommendation: do not implement unless compatibility with legacy clients is required. .

OTR is a crypto protocol, specifically designed to secure instant messaging conversations. Its usage in XMPP is documented (but not standardized) in https://xmpp.org/extensions/xep-0364.html

Comparative Overview

Proposal Security property Communication patterns Compatibility with XMPP
Authenticity Integrity Encryption Forward secrecy Malleability One-to-One Groupchat Offline messages Multiple resources Discovery of support
OMEMO (XEP-0384) Yes Except in the case of a malicious authenticated device Yes Yes By authenticated devices Yes Yes (Non-anonymous only) Yes Yes Yes
XEP-0374: OpenPGP for XMPP Instant Messaging Yes Yes Yes No N/A Yes Possible and planned, but currently unspecified Yes Yes Yes
Legacy PGP (XEP-0027) No (messages only encrypted, not signed) No Yes No N/A Yes No Yes Yes (if same keypair at all resources) No
OTR Yes Yes Yes Yes Yes Yes No No No No

Related Documents

Discussion

If you have any questions or comments regarding this page, please join the XSF chatroom at xsf@muc.xmpp.org.

Abandoned and Legacy E2EE specifications

Those specifications are very likely not relevant any more. They either gained no adoption or where replaced in favor of newer specifications. They are listed here only for the sake of completeness.

draft-miller-xmpp-e2e

https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/

ESessions

https://xmpp.org/extensions/xep-0187.html https://xmpp.org/extensions/xep-0188.html

RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

https://tools.ietf.org/html/rfc3923