In order to encrypt and authenticate (or decrypt and verify) messages, the commsec routines require a 128 bit key, 32 bit salt, counter values, and source address for the local system. The key and salt can be distributed in a manner specified by the key agreement phase while the counters can initially be zero.
AES GCM is a NIST-approved, but independently developed, authenticating encryption algorithm. Given a unique (96 bit) initialization vector (IV) and secret AES key, AES GCM provides confidentiallity and integrity. By careful construction of IVs commsec also provides replay protection, communications security that can withstand power-cycles, flexible in key-distribution, and reduced overhead (when compared with most other transportation security protocols).
As stated, most the properties are due to the data used to construct IVs and its interpretation. The IV is a concatenation of the bits from the salt, message counter, epoch counter, and system identifier (ID). These values fill the following purposes:
When powered-on, all existing keys, salts, epoch-counters, and 16 bit system identifiers are loaded from non-volitile memory. These values are stored in RAM using a dictionary that is indexed by the 16 bit system identifier. The epoch-counter associated with the current system’s ID is incremented to avoid re-using IVs in the event of power failure.
In order to send data, a fresh IV is constructed from the 32 bit salt, 32 bit message counter, 16 bit epoch counter, and 16 bit source identity. AES Galois Counter Mode (GCM) is used to encrypt and authenticate the frame. The message counter is incremented and stored in RAM.
After encryption, we encapsulate the message with an initialization vector and authentication tag. The initialization vector is composed of fields of source identifier, epoch counter, and counter.
On the receiving end, the sender’s ID is used to lookup the key, salt, latest message and epoch counters. The IV is reconstructed from the transmitted portions (the counter, epoch counter, and source identifier) and the salt from the local database. If the message counter loaded from memory is greater than or equal to the received message counter, or the epoch counter is greater than its received counterpart, then the message is discarded. The IV and key is then used to decrypt and authenticate the message following the AES GCM specification.
Finally, if a message bearing a greater epoch counter is received, and is successfully authenticated, then this larger epoch counter should be stored in non-volitile memory. In order to ensure secure communications can survive an unexpected power failure the most recent key, salt and an epoch counter should always be stored in non-volitile memory. The message counter is only stored in RAM, allowing fast operation and avoiding unnecessary wear on the flash storage.
|Key||persistent||128||Should be random|
|Salt||persistent||32||Should be random|
|Counter||volitile||32||Starts at 0, resets to 0 at power-cycle|
|Epoch Counter||persistent||16||Starts at 0, incremented at power-cycle (epoch for local system’s) or read from flash (epochs for remote systems)|
|Identity||persistent||16||Set by admin to a unique value for each system|
A note on GCM: It is an implementation detail, but important from a hardware requirement standpoint, that there is additional data computed and stored in RAM as an optimization (a time-memory trade-off). This data balloons the total memory use to ~5KB per key.