1.0.0
- 1.0.0
- Initial record
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This document describes the behavior by which a Structured Data which has been encrypted is decrypted. We define decryption over this Structured Data to mean that we obtain back the original Structured Data, and ensure integrity and authenticity is ensured over a set of Terminal Data.
The following inputs to this behavior are REQUIRED:
The following inputs to this behavior MUST be OPTIONAL:
The logical name for the structure. This can be the same as the physical name. For example the name of the table to hold the encrypted record.
The Auth List to be decrypted.
This Auth List MUST contain data located at the header index and the footer index.
The Auth List describes how each Terminal Data should be treated during decryption.
The Auth List MUST include at least one SIGN Authenticate Action; otherwise, this operation MUST yield an error.
The Auth List MUST NOT contain duplicate Paths.
A CMM that implements the CMM interface.
See encryption context.
In order for decryption to succeed:
- This MUST include any key-values pairs that were used during the original encryption of the input data, but not stored in the input Structured Data's header.
- This MAY include any key-values pairs that are stored in the input Structured Data's header.
- This MUST NOT include any key-values pairs that were not used during the original encryption of the input data.
This operation MUST output the following:
- Crypto List: Decrypted Terminals and the Crypto Schema for each Terminal, calculated using the Crypto Legend in the header, the signature scope used for decryption, and the data in the input structure.
- Parsed Header
This structure MUST contain the following values, representing the deserialized form of the header of the input encrypted structure:
- Algorithm Suite ID: The Algorithm Suite ID associated with the Format Flavor on the header.
- Stored Encryption Context: The Encryption Context stored in the header.
- Encrypted Data Keys: The Encrypted Data Keys stored in the header.
- Encryption Context: The full Encryption Context used.
All inputs MUST adhere to their requirements; otherwise this operation MUST immediately yield an error.
The Decrypt Structure operation is divided into several distinct steps:
- Parse the Header
- Retrieve Decryption Materials
- Verify Signatures
- Construct Decrypted Structured Data
This operation MUST perform all the above steps, and it MUST perform them in the above order.
If any of these steps fails, this operation MUST halt and indicate a failure to the caller.
Given the input data, this operation MUST access the Terminal Data at "aws_dbe_head".
The Terminal Type Id on this Terminal Data MUST be 0xFFFF.
We refer to the Terminal Value
on this Terminal Data as the header bytes.
This operation MUST deserialize the header bytes according to the header format.
The header field value MUST be verified
The below calculations REQUIRE a Crypto Schema, which is determined based on the input Authentication Schema and the parsed Encrypt Legend in the header, such that for each Terminal Data in the input Structured Data:
- The Crypto Action is DO_NOTHING if the Authentication Schema indicates DO_NOT_SIGN for this Terminal Data.
- The Crypto Action is SIGN_ONLY if
the Authentication Schema indicates SIGN for this Terminal Data
and the Encrypt Legend byte corresponding to this Terminal Data is
0x73. - The Crypto Action is SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT if
the Authentication Schema indicates SIGN for this Terminal Data
and the Encrypt Legend byte corresponding to this Terminal Data is
0x63. - The Crypto Action is ENCRYPT_AND_SIGN if
the Authentication Schema indicates SIGN for this Terminal Data
and the Encrypt Legend byte corresponding to this Terminal Data is
0x65.
This operation MUST calculate the appropriate CMM and encryption context.
This operation MUST obtain a set of decryption materials by calling Decrypt Materials on the CMM calculated above.
The call to the CMM's Decrypt Materials operation MUST be constructed as follows:
- Encryption Context: The Encryption Context parsed from the header.
- Algorithm Suite ID: The algorithm suite indicated by the Message Format Flavor parsed in the header.
- Commitment Policy: DBE_COMMITMENT_POLICY
- Encrypted Data Keys: The Encrypted Data Keys parsed from the header.
- Reproduced Encryption Context: This is the encryption context calculated above.
The algorithm suite used in all further aspects of this operation MUST be the algorithm suite in the decryption materials returned from the Decrypt Materials call. Note that the algorithm suite in the retrieved decryption materials MAY be different from the input algorithm suite. If this algorithm suite is not a supported suite for DBE this operation MUST yield an error.
If the version stored in the header is 1, then the input cmm and encryption context MUST be used unchanged.
Otherwise, this operation MUST add an entry to the encryption context for every SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT Crypto Action Terminal Data in the input record, plus the Legend.
An error MUST be returned if any of the entries added to the encryption context in this step have the same key as any entry already in the encryption context.
Then, this operation MUST create a Required Encryption Context CMM with the following inputs:
- This input CMM as the underlying CMM.
- The name of every entry added above.
A footer field MUST exist with the name aws_dbe_foot
The footer field TypeID MUST be 0xFFFF
The footer field value MUST be verified.
Decryption MUST fail immediately if verification fails.
This operation MUST deserialize the bytes in Terminal Value according to the footer format.
The number of HMACs in the footer MUST be the number of Encrypted Data Keys in the header.
The Cipherkey and Nonce must be calculated as for encryption.
In the output Crypto List:
- An entry MUST NOT exist with the key "aws_dbe_head" or "aws_dbe_foot".
- For every entry in the input Auth List, other than the header and footer, an entry MUST exist with the same key in the output Crypto List.
- For every entry in the output Crypto List an entry MUST exist with the same key in the input Auth List. Put plainly, the output does not add or drop any entries during decryption, other than the header and footer.
For each entry in the output Crypto List:
If the action is ENCRYPT_AND_SIGN this Terminal Data MUST have Terminal Type ID equal to the first two bytes of the input Terminal Data's value, and a value equal to the decryption of the input Terminal Data's value.
Otherwise, this Terminal Data MUST have Terminal Type ID and Terminal Value equal to the input Terminal Data.
The output MUST also include a Parsed Header that contains data that was serialized into the header included in the output Structured Data.
Decryption of Terminal Data takes a encrypted Terminal Data as input, and returns a Terminal Data.
The input Terminal Value MUST be deserialized as follows:
| Field | Length |
|---|---|
| Terminal Type Id | 2 |
| Encrypted Terminal Value | Variable |
The output Terminal Data MUST have a Terminal Type Id equal to the deserialized Terminal Type Id.
The output Terminal Data MUST have a Terminal Value equal to the following decryption:
- The decryption algorithm used is the encryption algorithm indicated in the algorithm suite.
- The AAD is the canonical path for this Terminal Data.
- The Cipherkey and Nonce are as calculate above.
- The ciphertext is the deserialized Encrypted Terminal Value.