QuantumGate Key Update
After the successful completion of the initial handshake two communicating peers enter the "Ready" phase where they can send data to each other. Any extenders that are running on both peers can also communicate and send data to each other. Communications are encrypted using the symmetric session keys that were derived during the initial handshake.
However, it may be required to update the symmetric session keys during communications. This can be for various reasons, one of which is to much better guarantee forward secrecy. Another reason is that, if we want to maintain a good level of security, we have to limit the total amount of data that can be encrypted and transmitted using a single symmetric session key.
QuantumGate periodically checks to see if the latest symmetric session keys that are in use need to be updated, and if so, initiates a key update procedure. Any other communications by the peers and their extenders can continue simultaneously during this procedure using the ephemeral symmetric session keys available at that time, while new ones are being generated and agreed upon. If the key update procedure fails for some reason (like not completing quick enough) the connection gets dropped.
QuantumGate allows you to configure the key update procedure via the custom SecurityParameters (see the KeyUpdate member). In addition, the default Security Levels each have their own configuration for the key update.
The key update procedure can be seen schematically below.
The key update procedure can be divided into 3 phases which are discussed in more detail below. It can only be initiated by the inbound peer (the one accepting the connection from another peer).
Depending on the chosen primary asymmetric algorithm, ephemeral public key(s) is/are exchanged in order to arrive at a shared secret.
Once the peers have used the exchanged public key(s) to arrive at a primary shared secret, primary symmetric session keys are derived from the primary shared secret (combined with the Global Shared Secret if used), and the peers begin encrypting communications from this point on using those keys.
Refer to the Key Exchange page for more details about what happens during a key exchange.
Depending on the chosen secondary asymmetric algorithm, ephemeral public key(s) is/are exchanged in order to arrive at a secondary shared secret.
Once the peers have a secondary shared secret, secondary symmetric session keys are derived from the secondary shared secret (combined with the Global Shared Secret if used), and the peers begin encrypting communications from this point on using those keys.
You'll note that the secondary key exchange is similar to the primary key exchange. The purpose of the secondary key exchange is to allow for a second asymmetric algorithm to be used, preferably one that is quantum-resistant.
Once the secondary symmetric session keys are available to be used, the peers stop using the primary symmetric session keys for encrypting new messages. The primary symmetric session keys can still be used for a brief period to decrypt messages that were still in transit and encrypted using those keys.
Refer to the Key Exchange page for more details about what happens during a key exchange.
During this phase the peers use the latest symmetric session keys derived in the previous phase to encrypt and decrypt communications, while waiting for the next required update. As soon as a key update is required based on the configured security settings, the procedure starts again with the Primary Key Update Exchange.