Penetration Test Report (RadicallyOpenSecurity): 2016 CryptographicReview OMEMO protocol v1.0

Public
OMEMO: CRYPTOGRAPHIC ANALYSIS
REPORT
for
PACIFIC RESEARCH ALLIANCE
V1.0
Amsterdam,
June 1, 2016
1/24 Chamber of Commerce 60628081
Public
Document Properties
Client Pacific Research Alliance
Title OMEMO: Cryptographic Analysis Report
Version V1.0
Author Sebastian Verschoor
Reviewed by Melanie Rieback
Approved by Melanie Rieback
Classification Public
Version Info
Version Date Author Description
V1.0 June 1, 2016 Sebastian Verschoor Final version
V0.3 June 1, 2016 Sebastian Verschoor Changed client organisation
V0.2 May 11, 2016 Sebastian Verschoor Conversations developer fixed the
issue I found
V0.1 May 10, 2016 Sebastian Verschoor Initial Draft
Contact
For more information about this Document and its contents please contact Radically Open
Security BV.
Name Sebastian Verschoor
Address Radically Open Security BV
Overdiemerweg 28, 1111 PP Diemen
Phone +31 6 1021 3240
Email sebastian.verschoor@gmail.com
2/24 Chamber of Commerce 60628081
Public
Contents
1. Introduction 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Attacker Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Attacker goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Attacker capabilities . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Analysis 6
2.1. Signal Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Protocol Description . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. Security analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. OMEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Protocol description . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Security analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3. Malicious device . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4. Forward/future secrecy . . . . . . . . . . . . . . . . . . . . . . 17
2.3. OMEMO Encrypted Jingle File Transfer . . . . . . . . . . . . . . . . . 18
3. Code Review 18
4. Conclusions/recommendations 20
A. Minor corrections 23
3/24 Chamber of Commerce 60628081
Public
1. Introduction
The OMEMO protocol is an adaptation of the Signal Protocol, created by Open Whisper
Systems 1. OMEMO is designed to work in an XMPP environment [26][28], 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.
The predominant part of this report, the protocol security analysis, can be found in Sec-
tion 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 [7] of the Conversations application [9], as a reference implementa-
tion of the OMEMO specification. Finally, Section 4 provides a summary of results and my
recommendations for the OMEMO standard.
1.1. Terminology
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 [29], also called OMEMO version 0.
In order to eliminate confusion, Open Whisper Systems has very recently [20] 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: “Signal
Protocol” 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.
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.
1.2. Attacker Model
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
triad2. 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.
To claim that the protocol is secure, a well-defined attacker model is required in order to
specifywhattheprotocolissecureagainst. Bydefiningthegoalsthatadversariesmighthave
1https://whispersystems.org/
2Confidentiality, Integrity and Availability
4/24 Chamber of Commerce 60628081
Public
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.
1.2.1. Attacker goals
Theattackergoalsarecloselytiedtothesecuritypropertiesofthesecuremessagingprotocol.
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.
Table 1: Attacker goals
Attacker goal Security property
Compromise messages Confidentiality of messages
Alter sent messages Integrity of messages
Inject false messages Authenticity of messages
Identify as another person Authentication of communication partner
Block communication Availability of communication
Learn communication metadata Privacy protection
Prove what was said Deniability of message content
Prove that two persons communicated Deniability of the conversation
Learn past communication after compromise Forward secrecy
Prolong a successful attack Future secrecy
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.
Toprotecttheprivacyoftheusers, theprotocolshouldnotleakmetadataabouttheusers’
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.
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.
Forward secrecy3 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.
3also called Perfect Forward Secrecy or Key Erasure
5/24 Chamber of Commerce 60628081
Public
1.2.2. Attacker capabilities
A base model for the attacker is the Dolev-Yao model [5], in which the attacker has full
control over the network. The attacker can listen to, alter, inject and drop any message on
the network.
However, real attackers have capabilities beyond control over the network. By inspecting
the physical propertie