This document takes a closer look at the inner workings of Jess. It does not, however, define the formats and some other aspects. First, some basics will be covered. Then, the wire protocol is given a closer look.
The basic building blocks of jess are:
Envelopes hold the configuration for cryptographic operations.
Given an envelope and and a message, jess creates a letter, an encrypted container that also holds any information needed to successfully open the letter, if the keys/passwords are supplied.
Given an envelope and and a message, jess creates a letter - an encrypted container that also holds any information needed to successfully open the letter, if the keys/passwords are supplied.
Signets hold secrets, such as a private key. Recipients represents the public (ie. secret-less) versions of signets.
Seals hold key establishment data, such as public keys or encapsulated keys.
Every operation is subject to requirements:
- Confidentiality
- Integrity
- Recipient Authentication
- Sender Authentication
The basic ability of jess is to open and close letters - discrete data blobs, such as a file stored on disk.
The algorithms used depend on the requirements, normally the full range of key exchange, encryption, MAC, and signing is used. Keys are established as with the wire protocol, but stop as soon as [client—>server] shared key has been established.
The wire protocol is requires the Confidentiality, Integrity and Recipient Authentication requirements.
Keys are established using ephemeral keys and are re-established frequently, providing forward secrecy:
- Even if the static key is compromised, data encrypted in the past will remain secured.
- An attacker must execute an active Man-in-the-Middle attack or continually compromise all ephermal keys in order to sustain full compromise.
- If a session key is compromised, only encrypted data until the next key re-establishment will be compromised.
Continually evolving session keys provide backward secrecy:
- Even if a session key is compromised, data encrypted before the compromise remains secured.
Connections are established in a 0-RTT (zero round trip time) manner, enabling the first message to carry data. The caveat is that until the first key establishment has fully finished, transmitted data from the client to the server will be only protected by the static key (ie. without forward secrecy).
When used for tunneling or with a sub-protocol, this usually won't be an issue, as the sub-protocol will most likely have a synchronous establishment procedure anyway, guaranteeing a full key establishment when the sub-protocol is finished with it's own setup.
There will be a way to force a full establishment before transmitting data in the future.
This protocol is also inspired by the Double Ratchet Algorithm.
If you are familiar with the Noise Protocol Framework, you will notice that this protocol is very similar to the "NK handshake". The main difference is that the handshake of this protocol is asynchronous, is periodically repeated and it uses evolving keys, making it suitable for long lived high-volume connections.
Currently, all key establishment elements and signatures are not hidden and can be seen on the wire. This will change in a future protocol version. Also, signatures, pre-shared keys and passwords - as part of the handshake - are not yet supported and future support is uncertain.
In order to dynamically support different types of algorithms, Jess always uses a KDF to provide keys and nonces to algorithms:
init only signifies steps that are only performed in the initial handshake. Other steps are performed for both the initial handshake and renewals. The semi-ephemeral keys [se] are rather short-lived keys (hours to days), that are securely distributed in a separate manner.
init only signifies steps that are only performed in the initial handshake. Other steps are performed for both the initial handshake and renewals. The semi-ephemeral keys [se] are rather short-lived keys (hours to days), that are securely distributed in a separate manner.
The wire protocol is able to send data in the first message. Until the first roundtrip has been completed (client to server to client), there are weakened security guarantees:
- If the static key (semi-static 24h TTL key in case of SPN) is compromised, there are lesser to no security guarantees:
- A passive attacker, in possession of the private static key, is able to read all outgoing messages until the first roundtrip is completed.
- An active attacker is able to execute a Man-in-the-Middle attack and completely obliterate all security guarantees.
- Incoming messages (server to client) have a reduced guarantee of security until the first roundtrip is completed:
An active attacker is able to execute a Man-in-the-Middle attack, completely replacing the first outgoing (client to server) message. The attacker can choose the contents of that message to his liking. The response from the server will then be readable by the attacker, but the client will discard the message as authentication of it will fail.
As the Wire Protocol does not do any form of client/sender authentication, this is a problem for protocols that use underlying information, such as the IP address, for authentication. The sub-protocol must always authenticate clients to their needs and do not expect any guarantees from the Wire Protocol in that regard.
Also, note that this is also the case with the protocols in the Noise framework that start with an "N".
This wire protocol was specifically built for SPN and the implementation there is fully aware of all the limitations of the protocol.