vanitasvitae/Smack
1
0
Fork 0
mirror of https://github.com/vanitasvitae/Smack.git synced 2024-11-23 20:42:06 +01:00
Code Issues Releases Wiki Activity

Update omemo.md

Browse source
This commit is contained in:
Paul Schaub 2018-01-10 16:22:15 +01:00
parent 1cbc112c88
commit ebf7969954
1 changed files with 209 additions and 129 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

296
documentation/extensions/omemo.md
View file

@ -3,6 +3,9 @@ Encrypting messages with OMEMO
[Back](index.md) [Back](index.md)
About OMEMO
-----------
OMEMO ([XEP-0384](https://xmpp.org/extensions/xep-0384.html)) is an adaption OMEMO ([XEP-0384](https://xmpp.org/extensions/xep-0384.html)) is an adaption
of the Signal protocol for XMPP. It provides an important set of of the Signal protocol for XMPP. It provides an important set of
cryptographic properties including but not restricted to cryptographic properties including but not restricted to
@ -22,18 +25,44 @@ It does NOT provide a server side message archive, so that a new device could
fetch old chat history. fetch old chat history.
Most implementations of OMEMO use the signal-protocol libraries provided by Most implementations of OMEMO use the signal-protocol libraries provided by
OpenWhisperSystems. Unlike Smack, those libraries are licensed under the GPL, OpenWhisperSystems. Unlike Smack, those libraries are licensed under the GPLv3,
which prevents a Apache licensed OMEMO implementation using those libraries (see which prevents a Apache licensed OMEMO implementation using those libraries (see
[licensing situation](https://github.com/igniterealtime/Smack/wiki/OMEMO-libsignal-Licensing-Situation)). [licensing situation](https://github.com/igniterealtime/Smack/wiki/OMEMO-libsignal-Licensing-Situation)).
The module smack-omemo therefore contains no code related to signal-protocol. The module smack-omemo therefore contains no code related to signal-protocol.
However, almost all functionality is encapsulated in that module. If you want However, almost all functionality is encapsulated in that module. If you want
to use OMEMO in a GPL client, you can use the smack-omemo-signal to use OMEMO in a GPLv3 licensed client, you can use the smack-omemo-signal
Smack module, which binds the signal-protocol library to smack-omemo. Smack module, which binds the signal-protocol library to smack-omemo.
It is also possible, to port smack-omemo to other libraries implementing the It is also possible, to port smack-omemo to other libraries implementing the
double ratchet algorithm. double ratchet algorithm.
Requirements Understanding the Double Ratchet Algorithm
------------ ------------------------------------------
In the context of OMEMO encryption, a *recipient* is a not a user, but a users *device* (a user might have
multiple devices of course).
Unlike in PGP, each device capable of OMEMO has its own identity key and publishes its own key bundle.
It is not advised to migrate OMEMO identities from one device to another, as it might damage the ratchet
if not done properly (more on that later). Sharing one identity key between multiple devices is not the purpose of
OMEMO. If a contact has three OMEMO capable devices, you will see three different OMEMO identities and their
fingerprints.
OMEMO utilizes multiple layers of encryption when encrypting a message.
The body of the message is encrypted with a symmetric message key (AES-128-GCM) producing a *payload*.
The message key is encrypted for each recipient using the double ratchet algorithm.
For that purpose, the sending device creates a session with the recipient device (if there was no session already).
Upon receiving a message, the recipient selects the encrypted key addressed to them and decrypts it with their
counterpart of the OMEMO session. The decrypted key gets then used to decrypt the message.
One important consequence of forward secrecy is, that whenever an OMEMO message gets decrypted,
the state of the ratchet changes and the key used to decrypt the message gets deleted.
There is no way to recover this key a second time. The result is, that every message can be decrypted
exactly once.
In order to provide the best user experience, it is therefore advised to implement a client side message archive,
since solutions like MAM cannot be used to fetch old, already once decrypted OMEMO messages.
Server-side Requirements
------------------------
In order to use OMEMO encryption, your server and the servers of your chat In order to use OMEMO encryption, your server and the servers of your chat
partners must support PEP ([XEP-0163](http://xmpp.org/extensions/xep-0163.html)) partners must support PEP ([XEP-0163](http://xmpp.org/extensions/xep-0163.html))
@ -42,170 +71,221 @@ Optionally your server should support Message Carbons ([XEP-0280](http://xmpp.or
and Message Archive Management ([XEP-0313](http://xmpp.org/extensions/xep-0313.html)) and Message Archive Management ([XEP-0313](http://xmpp.org/extensions/xep-0313.html))
to achieve message synchronization across all (on- and offline) devices. to achieve message synchronization across all (on- and offline) devices.
Setup Client-side Requirements
----- ------------------------
First you need to setup a OmemoService, for example the libsignal one: If you are want to run smack-omemo related code on the Windows platform, you might have to install the
[Java Cryptography Extension](http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html).
This is needed to generate cryptographically strong keys.
Storing Keys
------------
smack-omemo needs to create, store and delete some information like keys and session states during operation.
For that purpose the `OmemoStore` class is used. There are multiple implementations with different properties.
* The `(Signal)FileBasedOmemoStore` stores all information in individual files organized in a directory tree.
While this is the most basic and easy to use implementation, it is not the best solution in terms of performance.
* The `(Signal)CachingOmemoStore` is a multi-purpose store implementation. It can be used to wrap another
`(Signal)OmemoStore` implementation to provide a caching layer (for example in order to reduce access to a database backend or
a the file system of the `FileBasedOmemoStore`. It is therefore advised to wrap persistent `(Signal)OmemoStore`
implementations with a `(Signal)CachingOmemoStore`.
On the other hand it can also be used standalone as an ephemeral `OmemoStore`, which "forgets" all stored information
once the program terminates. This comes in handy for testing purposes.
If you are unhappy with the `(Signal)FileBasedOmemoStore`, you can implement your own store (for example with a
SQL database) by extending the `(Signal)OmemoStore` class.
It most certainly makes sense to store the data of the used `OmemoStore` in a secure way (for example an
encrypted database).
Handling Trust Decisions
------------------------
In order for a cryptographic system to make sense, decisions must be made whether to *trust* an identity or not.
For technical reasons those decisions cannot be stored within the `OmemoStore`. Instead a client must implement
the `OmemoTrustCallback`. This interface provides methods to mark `OmemoFingerprints` as trusted or untrusted and to
query trust decisions.
In order to provide security, a client should communicate to the user, that it is important for them to compare
fingerprints through an external channel (reading it out on the phone, scanning QR codes...) before starting to chat.
While not implemented in smack-omemo, it is certainly for the client to implement different trust models like
[Blind Trust Before Verification](https://gultsch.de/trust.html).
Basic Setup
-----------
Before you can start to send and receive messages, some preconditions have to be met. These steps should be executed
in the order as presented below. In this example we will use components from the *smack-omemo-signal* module.
1. Register an OmemoService
The `OmemoService` class is responsible for handling incoming messages and manages access to the Double Ratchet.
``` ```
SignalOmemoService.setup(); SignalOmemoService.setup();
``` ```
As a first step you have to prepare the OmemoStore. The `setup()` method registers the service as a singleton. You can later access the instance
You can either use your own implementation, or use the builtin FileBasedOmemoStore (default). by calling `SignalOmemoService.getInstace()`. The service can only be registered once.
If you do not want to use your own store, the implementation uses a file based store, so you HAVE to set the default path. Subsequent calls will throw an `IllegalStateException`.
2. Set an OmemoStore
Now you have to decide, what `OmemoStore` implementation you want to use to store and access
keys and session states. In this example we'll use the `SignalFileBasedOmemoStore` wrapped in a
`SignalCachingOmemoStore` for better performance.
``` ```
//set path in case we want to use a file-based store (default) SignalOmemoService service = SignalOmemoService.getInstace();
OmemoConfiguration.setFileBasedOmemoStoreDefaultPath(new File("path/to/your/store")); service.setOmemoStoreBackend(new SignalCachingOmemoStore(new SignalFileBasedOmemoStore(new File("/path/to/store"))));
``` ```
For each device you need an OmemoManager. Just like the `OmemoService` instance, the `OmemoStore` instance can only be set once.
In this example, we use the smack-omemo-signal
implementation, so we use the SignalOmemoService as 3. Get an instance of the OmemoManager for your connection
OmemoService. The OmemoManager must be initialized with either a deviceId (of an existing
device), or null in case you want to generate a fresh device. For the greater part of OMEMO related actions, you'll use the `OmemoManager`. The `OmemoManager` represents
The OmemoManager can be used to execute OMEMO related actions like sending a your OMEMO device. While it is possible to have multiple `OmemoManager`s per `XMPPConnection`, you really
message etc. If you don't pass a deviceId, the value of defaultDeviceId will be used if present. only need one.
``` ```
OmemoManager omemoManager = OmemoManager.getInstanceFor(connection); OmemoManager manager = OmemoManager.getInstanceFor(connection);
``` ```
As soon as the connection is authenticated, the module generates some keys and If for whatever reason you decide to use multiple `OmemoManager`s at once,
announces OMEMO support. it is highly advised to get them like this:
To get updated with new OMEMO messages, you should register message listeners.
``` ```
omemoManager.addOmemoMessageListener(new OmemoMessageListener() { OmemoManager first = OmemoManager.getInstanceFor(connection, firstId);
@Overwrite OmemoManager second = OmemoManager.getInstanceFor(connection, secondId);
public void omOmemoMessageReceived(String decryptedBody, Message encryptedMessage, Message wrappingMessage, OmemoMessageInformation omemoInformation) {
System.out.println(decryptedBody);
}
});
omemoManager.addOmemoMucMessageListener(new OmemoMucMessageListener() {
@Overwrite
public void onOmemoMucMessageReceived(MultiUserChat muc, BareJid from, String decryptedBody, Message message,
Message wrappingMessage, OmemoMessageInformation omemoInformation) {
System.out.println(decryptedBody);
}
});
``` ```
Usage 4. Set an OmemoTrustCallback
-----
Before you can encrypt a message for a device, you have to trust its identity. As stated above, the `OmemoTrustCallback` is used to query trust decisions. Set the callback like this:
smack-omemo will throw an UndecidedOmemoIdentityException whenever you try
to send a message to a device, which the user has not yet decided to trust or distrust.
``` ```
omemoManager.trustOmemoIdentity(trustedDevice, trustedFingerprint); manager.setTrustCallback(trustCallback);
omemoManager.distrustOmemoIdentity(untrustedDevice, untrustedFingerprint);
``` ```
The trust decision should be made by the user based on comparing fingerprints. If you use multiple `OmemoManager`s each `OmemoManager` MUST have its own callback.
You can get fingerprints of your own and contacts devices:
5. Set listeners for OMEMO messages.
To get notified of incoming OMEMO encrypted messages, you need to register corresponding listeners.
There are two types of listeners.
* `OmemoMessageListener` is used to listen for incoming encrypted OMEMO single chat messages and
KeyTransportMessages.
* `OmemoMucMessageListener` is used to listen for encrypted OMEMO messages sent in a MultiUserChat.
Note that an incoming message might not have a body. That might be the case for
[KeyTransportMessages](https://xmpp.org/extensions/xep-0384.html#usecases-keysend)
or messages sent to update the ratchet. You can check, whether a received message is such a message by calling
`OmemoMessage.Received.isKeyTransportMessage()`, which will return true if the message has no body.
The received message will include the senders device and fingerprint, which you can use in
`OmemoManager.isTrustedOmemoIdentity(device, fingerprint)` to determine, if the message was sent by a trusted device.
6. Initialize the manager(s)
Ideally all above steps should be executed *before* `connection.login()` gets called. That way you won't miss
any offline messages. If the connection is not yet logged in, now is the time to do so.
``` ```
OmemoFingerprint myFingerprint = omemoManager.getFingerprint(); connection.login();
OmemoFingerprint otherFingerprint = omemoStore.getFingerprint(omemoManager, otherDevice); manager.initialize();
``` ```
To encrypt a message for a single contact or a MUC, you do as follows: Since a lot of keys are generated in this step, this might take a little longer on older devices.
You might want to use the asynchronous call `OmemoManager.initializeAsync(initializationFinishedCallback)`
instead to prevent the thread from blocking.
Send Messages
-------------
Encrypting a message for a contact really means to encrypt the message for all trusted devices of the contact, as well
as all trusted devices of the user itself (except the sending device). The encryption process will fail if there are
devices for which the user has not yet made a trust decision.
### Make Trust Decisions
To get a list of all devices of a contact, you can do the following:
``` ```
Message encryptedSingleMessage = omemoManager.encrypt(bobsBareJid, "Hi Bob!"); List<OmemoDevice> devices = manager.getDevicesOf(contactsBareJid);
Message encryptedMucMessage = omemoManager.encrypt(multiUserChat, "Hi everybody!");
``` ```
Note: It may happen, that smack-omemo is unable to create a session with a device. To get the OmemoFingerprint of a device, you can call
In case we could not create a single valid session for a recipient, a
CannotCreateOmemoSessionException will be thrown. This exception contains information
about which sessions could (not) be created and why. If you want to ignore those devices,
you can encrypt the message for all remaining devices like this:
``` ```
Message encryptedMessage = omemoManager.encryptForExistingSession(cannotEstablishSessionException, "Hi there!"); OmemoFingerprint fingerprint = manager.getFingerprint(device);
``` ```
The resulting message can then be sent via the ChatManager/MultiUserChatManager. This fingerprint can now be displayed to the user who can decide whether to trust the device, or not.
You may want to generate a new identity sometime in the future. That's pretty straight
forward. No need to manually publish bundles etc.
``` ```
omemoManager.regenerate(); // Trust
manager.trustOmemoIdentity(device, fingerprint);
// Distrust
manager.distrustOmemoIdentity(device, fingerprint);
``` ```
In case your device list gets filled with old unused identities, you can clean it up. ### Encrypt a Message
This will remove all active devices from the device list and only publish the device
you are using right now.
Currently only Message bodies can be encrypted.
``` ```
omemoManager.purgeDevices(); String secret = "Mallory is a twerp!";
OmemoMessage.Sent encrypted = manager.encrypt(contactsBareJid, secret);
``` ```
If you want to find out, whether a server, MUC or contacts resource supports OMEMO, The encrypted message will contain some information about the message. It might for example happen, that the encryption
you can use the following methods: failed for some recipient devices. For that reason the encrypted message will contain a map of skipped devices and
the reasons.
### Encrypt a Message for a MultiUserChat
A MultiUserChat must fulfill some criteria in order to be OMEMO capable.
The MUC must be non-anonymous. Furthermore all members of the MUC must have subscribed to one another.
You can check for the non-anonymity like follows:
``` ```
boolean serverCan = omemoManager.serverSupportsOmemo(serverJid); manager.multiUserChatSupportsOmemo(muc);
boolean mucCan = omemoManager.multiUserChatSupportsOmemo(mucJid);
boolean resourceCan = omemoManager.resourceSupportsOmemo(contactsResourceJid);
``` ```
It might happen, that the server you or your contact are using is not delivering devicelist updates correctly. Encryption is then done analog to single message encryption:
In such a case smack-omemo cannot fetch bundles or send messages to devices it hasn\'t seen before. To mitigate this, it
might help to explicitly request the latest device list from the server.
``` ```
omemoManager.requestDeviceListUpdateFor(contactJid); OmemoMessage.Sent encrypted = manager.encrypt(multiUserChat, secret);
``` ```
If you want to decrypt a MamQueryResult, you can do so using the following method: ### Sending an encrypted Message
````
List<ClearTextMessage> decryptedMamQuery = omemoManager.decryptMamQueryResult(mamQueryResult);
````
Note, that you cannot decrypt an OMEMO encrypted message twice for reasons of forward secrecy.
A ClearTextMessage contains the decrypted body of the message, as well as additional information like if/how the message was encrypted in the first place.
Unfortunately due to the fact that you cannot decrypt messages twice, you have to keep track of the message history locally on the device and ideally also keep track of the last received message, so you can query the server only for messages newer than that.
To send the message, it has to be wrapped in a `Message` object. That can conveniently be done like follows.
```
Message message = encrypted.asMessage(contactsJid);
connection.sendStanza(message):
```
This will add a [Message Processing Hint](https://xmpp.org/extensions/xep-0334.html) for MAM,
an [Explicit Message Encryption](https://xmpp.org/extensions/xep-0380.html) hint for OMEMO,
as well as an optional cleartext hint about OMEMO to the message.
Configuration Configuration
------------- -------------
smack-omemo has some configuration options that can be changed on runtime via the `OmemoConfiguration` class: smack-omemo has some configuration options that can be changed on runtime via the `OmemoConfiguration` class:
* setFileBasedOmemoStoreDefaultPath sets the default directory for the FileBasedOmemoStore implementations.
* setIgnoreStaleDevices when set to true, smack-omemo will stop encrypting messages for **own** devices that have not send a message for some period of time (configurable in setIgnoreStaleDevicesAfterHours) * setIgnoreStaleDevices when set to true, smack-omemo will stop encrypting messages for **own** devices that have not send a message for some period of time (configurable in setIgnoreStaleDevicesAfterHours)
* setDeleteStaleDevices when set to true, smack-omemo will remove own devices from the device list, if no messages were received from them for a period of time (configurable in setDeleteStaleDevicesAfterHours) * setDeleteStaleDevices when set to true, smack-omemo will remove own devices from the device list, if no messages were received from them for a period of time (configurable in setDeleteStaleDevicesAfterHours)
* setRenewOldSignedPreKeys when set to true, smack-omemo will periodically generate and publish new signed prekeys. Via setRenewOldSignedPreKeysAfterHours you can configure, after what period of time new keys are generated and setMaxNumberOfStoredSignedPreKeys allows configuration of how many signed PreKeys are kept in storage for decryption of delayed messages. * setRenewOldSignedPreKeys when set to true, smack-omemo will periodically generate and publish new signed prekeys. Via setRenewOldSignedPreKeysAfterHours you can configure, after what period of time new keys are generated and setMaxNumberOfStoredSignedPreKeys allows configuration of how many signed PreKeys are kept in storage for decryption of delayed messages.
* setAddOmemoBodyHint when set to true, a plaintext body with a hint about OMEMO encryption will be added to the message. This hint will be displayed by clients that do not support OMEMO. Note that this might not be desirable when communicating with clients that do not support EME. * setAddOmemoBodyHint when set to true, a plaintext body with a hint about OMEMO encryption will be added to the message. This hint will be displayed by clients that do not support OMEMO. Note that this might not be desirable when communicating with clients that do not support EME.
* setAddEmeEncryptionHint when set to true, an Explicit Message Encryption element will be added to the message. This element tells clients, that the message is encrypted with OMEMO. * setRepairBrokenSessionsWithPreKeyMessages when set to true, whenever a message arrives, which cannot be decrypted, smack-omemo will respond with a preKeyMessage which discards the old session and builds a fresh one.
* setAddMAMStorageProcessingHint when set to true, a storage hint for Message Archive Management will be added to the message. This enabled servers to store messages that contain no body. * setCompleteSessionWithEmptyMessage when set to true, whenever a preKeyMessage arrives, smack-omemo will respond with an empty message to complete the session.
Customization
-------------
You can integrate smack-omemo with your existing infrastructure.
It is possible to create your own OmemoStore implementations eg. using an SQL database as backend.
For this purpose, just inherit OmemoStore/SignalOmemoStore and implement the missing methods.
You can register that Store with your OmemoService by calling
```
SignalOmemoService.getInstance().setOmemoStoreBackend(myStore);
```
Features
--------
* decryption and encryption of OMEMO messages (single and multi user chat)
* provides information about trust status of incoming messages
* automatic publishing of bundle
* automatic merging of incoming deviceList updates
* ignores stale devices after period of inactivity
* removes stale devices from device list after period of inactivity
* automatic repair of broken sessions through ratchet update messages
* automatic renewal of signed preKeys
* multiple devices per connection possible
Integration Tests Integration Tests
----------------- -----------------