OMEMO

December 8th 2016 @ XMPP Security Meetup London

Crypto features

Forwared secrecy
Authenticity
(Deniability)

Security in general and end-to-end encryption in particular is always a tradeoff. You can't have everything and you basically need to know what you to be secure agains.
However when designing OMEMO we wanted it to have some specific cryptographic features:
First of all we wanted it to have forward secrecy which means that if the keys are compromised at any time an attacker won't automatically gain access to past conversations.
Second of all we wanted it to have authenticity which of course means that messages can't be spoofed by a third party.
XEP-27 for example doesn't have neither of these features because it doesn't sign the messages.
Deniablity is also a feature common in modern end-to-end encryption methods but I'm putting this brakets because I personally doubt that who ever breaks your encryption will care that mathematically someone else could have written those messages

Usability features

Reliable
Multiple devices
Existing XMPP servers

An Introduction to Ratchets

Key exchange at beginning of ‘session’
Message keys within a ‘session’ are derived from each other
Message keys are destroyed after decryption

OTR vs Axolotl

Lifelong sessions
First part of key exchange stored on server (pre keys)
Resilient against lost messages, reordering, replay

Naming confusion

Axolotl renamed to Signal Protocol
Copyright claims by OWS lead to several third party libraries with the same algorithm
Actual algorithm public domain (Double Ratchet)
Libraries differ in wire (binary) format

History of OMEMO

Google Summer of Code 2015 (June - September)
Conversations release in September
protoXEP in October 2015
Gajim Plugin Christmas 2015
ChatSecure Beta November 2016
As of yesterday: XEP-0384

Integrating Axolotl in XMPP

Session for every device
Pre keys are stored in PEP for each device
Index node holds list with devices
Clients subscribe (+notify) to index node

Integrating Axolotl in XMPP (2)

Individual node for every device (namespace contains device id)
Every node has >100 pre keys. Clients pick one at random
<body/> gets encrypted with random key (AES-GCM)
Random key gets encrypted in n sessions

OMEMO over MUC

n * m sessions w/ n: average number of devices/participant, m: number of participants
Requires presence subscription with each participant
Reliably detect participants (retrieve member list) & changes (notification of affiliation changes even if participant is offline)
MUC MAM needs to communicate real JID

OMEMO over MIX

Presence subscription no longer required
Improved method to detect participant changes

Accomplishments

Hassle-free communication between multiple devices
Works with carbons and MAM
Even in (private, non-anonymous) conferences
Existing servers not so much. PEP was a rocky road

So what can we do right now? We set out to create an end-to-end encryption that is reliable enough to be always on without the user noticing it. We wanted the user to be able to switch between multiple devices. Thats totally possible now if you use Conversations and Gajim. I'm using it on a daily basis with several of my contacts. Even in MUC.
One of our goals was to make it work with existing servers and that let us to choose PEP as a storage mechanism despite the downsides like deliverying 100 preykeys even though we just need one.
That actually wasn't as succesful as we hoped it to be because a year ago PEP was very very broken in ejabberd and people had to update their servers anyway. OpenFire actually just released a fix for their PEP two weeks ago.
And when looking at how fast HTTP Upload got adopted we probably could have created our own server component.

Future

Provide a way to optionally encrypt XML
No plan to support large conferences

Trust multiple devices

TOFU doesn’t work if you can’t judge plausibility
Signal/WhatsApp are migrating to trust everything
Conversations >1.15.0 had manual mode
Let user decide for each and every new device
BTBV (Blind Trust Before Verification)
Trust everything by default. After first actual verification (scanning barcode) go to manual mode and let user decide for subsequent devices

OMEMO is capable of encryption but OMEMO doesn't have an answer on how to verify the indivdual devices.
In general Trust on First Use doesn't work very well because people change keys and you can't judge if they actually did or if you are being Man in the middled. Compare that to SSH where you usually control the server as well and where you have a chance to judge if it was plausible that the server got new keys because you reinstalled the operating system.
For this reason the mainstream messenger are switching to Trust Everything and merly warn.
So Conversations introduced this new mode called Blind Trust Before Verification where we trust everything by default but stop with the trust everything after the first actual verification.
I don't have time to go into the details but I'd love to chat with you about this later

Reading material

en.wikipedia.org/wiki/Double_Ratchet_Algorithm
conversations.im/omemo/
Blind Trust Before Verification gultsch.de/trust.html
Getting started with OMEMO gist.github.com/iNPUTmice/e3fe475752e39b40ea87ae5ed73b3e01