org.jivesoftware.smackx.omemo.package-info Maven / Gradle / Ivy
Show all versions of smack-omemo Show documentation
/**
*
* Copyright 2017 Paul Schaub
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/**
* Classes and interfaces for OMEMO Encryption. This module consists of the XMPP logic and some abstract crypto classes
* that have to be implemented using concrete crypto libraries (like signal-protocol-java or olm). See
* smack-omemo-signal for a concrete implementation (GPL licensed).
* About OMEMO
*
* OMEMO (XEP-0384) is an adaption of the Signal protocol for
* XMPP. It provides an important set of cryptographic properties including but not restricted to
*
*
* - Confidentiality
* - Integrity
* - Authenticity
* - Forward Secrecy
* - Future Secrecy (break-in recovery)
* - Plausible Deniability
*
*
* Contrary to OTR it is capable of multi-end-to-multi-end encryption and message synchronization across multiple
* devices. It also allows the sender to send a message while the recipient is offline.
*
*
* It does not provide a server side message archive, so that a new device could fetch old chat history.
*
*
* Most implementations of OMEMO use the signal-protocol libraries provided by OpenWhisperSystems. Unlike Smack, those
* libraries are licensed under the GPLv3, which prevents a Apache licensed OMEMO implementation using those libraries
* (see licensing
* situation). The module smack-omemo therefore contains no code related to signal-protocol. However, almost all
* functionality is encapsulated in that module. If you want 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. It is also possible, to port
* smack-omemo to other libraries implementing the double ratchet algorithm.
*
* 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 partners must support PEP
* (XEP-0163) to store and exchange key bundles. Optionally your
* server should support Message Carbons (XEP-0280) and Message
* Archive Management (XEP-0313) to achieve message
* synchronization across all (on- and offline) devices.
*
* Client-side Requirements
*
* If you are want to run smack-omemo related code on the Windows platform, you might have to install the
* Java Cryptography
* Extension). 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.
*
* 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();
*
*
*
* The `setup()` method registers the service as a singleton. You can later access the instance by calling
* `SignalOmemoService.getInstance()`. The service can only be registered once. Subsequent calls will throw an
* {@link 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.
*
*
*
*
* SignalOmemoService service = SignalOmemoService.getInstace();
* service.setOmemoStoreBackend(new SignalCachingOmemoStore(new SignalFileBasedOmemoStore(new File("/path/to/store"))));
*
*
*
* Just like the `OmemoService` instance, the `OmemoStore` instance can only be set once.
*
* 3. Get an instance of the OmemoManager for your connection
*
* For the greater part of OMEMO related actions, you'll use the `OmemoManager`. The `OmemoManager` represents
* your OMEMO device. While it is possible to have multiple `OmemoManager`s per `XMPPConnection`, you really
* only need one.
*
*
*
* OmemoManager manager = OmemoManager.getInstanceFor(connection);
*
*
*
* If for whatever reason you decide to use multiple `OmemoManager`s at once, it is highly advised to get them like this:
*
*
*
* OmemoManager first = OmemoManager.getInstanceFor(connection, firstId);
* OmemoManager second = OmemoManager.getInstanceFor(connection, secondId);
*
*
* Set an OmemoTrustCallback
*
* As stated above, the `OmemoTrustCallback` is used to query trust decisions. Set the callback like this:
*
*
*
* manager.setTrustCallback(trustCallback);
*
*
*
* If you use multiple `OmemoManager`s each `OmemoManager` MUST have its own callback.
*
* 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 or 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.
*
* 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.
*
*
*
* connection.login();
* manager.initialize();
*
*
*
* 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:
*
*
* {@code
* List devices = manager.getDevicesOf(contactsBareJid);
* }
*
*
* To get the OmemoFingerprint of a device, you can call
*
*
*
* OmemoFingerprint fingerprint = manager.getFingerprint(device);
*
*
*
* This fingerprint can now be displayed to the user who can decide whether to trust the device, or not.
*
*
*
* // Trust
* manager.trustOmemoIdentity(device, fingerprint);
*
* // Distrust
* manager.distrustOmemoIdentity(device, fingerprint);
*
*
* Encrypt a Message
*
* Currently only Message bodies can be encrypted.
*
*
*
* String secret = "Mallory is a twerp!";
* OmemoMessage.Sent encrypted = manager.encrypt(contactsBareJid, secret);
*
*
*
* The encrypted message will contain some information about the message. It might for example happen, that the encryption 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:
*
*
*
* manager.multiUserChatSupportsOmemo(muc);
*
*
*
* Encryption is then done analog to single message encryption:
*
*
*
* OmemoMessage.Sent encrypted = manager.encrypt(multiUserChat, secret);
*
*
* Sending an encrypted Message
*
* 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 for MAM,
* an Explicit Message Encryption hint for OMEMO,
* as well as an optional cleartext hint about OMEMO to the message.
*
* Configuration
*
* smack-omemo has some configuration options that can be changed on runtime via the `OmemoConfiguration` class:
*
*
* - 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)
* - 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.
* - 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.
* - setCompleteSessionWithEmptyMessage when set to true, whenever a preKeyMessage arrives, smack-omemo will respond with an empty message to complete the session.
*
* Integration Tests
*
* smack-omemo comes with a set of integration tests. Lets say you want to run the integration test suite for smack-omemo-signal. You can do so by using the following gradle task:
*
*
*
* gradle omemoSignalIntTest
*
*
*
* @author Paul Schaub
* @see XEP-0384: OMEMO
*/
package org.jivesoftware.smackx.omemo;