I am trying to understand how Header Enrichment encryption is implemented.
According to the manual there are two algorithms to encrypt:
(1) RC4MD5
(2) AES-256-GCM-sha384
================================================================
How RC4MD5 works is pretty straightforward and clearly described in the documentation:
1. The MD5 hash of the configure key will be calculated.
2. This MD5 hash will be used as a key for RC4 encryption.
3. This encrypted value will be base64 encoded to get the final X-header value. The final inserted X-header will be X-alias: base64(RC4(MD5(key),MSISDN)).
================================================================
But how AES-256-GCM-sha384 works is not clearly described.
Based on the information from here, such as:
"For AES-GCM encryption, use the optional salt flag. This flag is used to randomize the keys, which are generated from the passphrase, and the Initialization Vectors (IV)."
"In AES-256-GCM-SHA384 encryption, the SHA384 hash of the key, which is 384 bits value, is used to encrypt the value using the AES-GCM algorithm. The base 64 of this encrypted value is then inserted in the x-header."
Here's how AES-256-GCM-sha384 probably works:
0) Initial data
What we are given to perform encryption is the following:
- passPhrase, salt, plainText.
- "passPhrase" is set in the config and is constant (important: "passPhrase" is defined in the config as "key").
- "salt" is random 8-byte long string, which is generated before every encryption.
- "plainText" is 9-digit MSISDN (e.g. "502160992").
1) Hashing
sha384_hash(salt + passPhrase)
- the input to the hash fucntion is concatination of "salt" and "passPhrase".
- the order is important, "salt" goes first, then "passPhrase".
- the output of the hash function is 48 bytes long.
- KEY is the first 32 bytes of the 48 bytes.
(a) IV is the following 12 bytes (4 last bytes are dropped).
(b) alternatively IV is the rest of the hash (16 bytes).
2) Encryption
aes_256_gcm_encrypt(KEY, IV, plainText)
- the input to the encryption function is KEY, IV and "plainText".
- KEY.length is 32 bytes.
- IV.length is 12 bytes (or alternatively, 16 bytes).
- the output is "chipherText" and "authTag".
- authTag.length is 16 bytes.
3) Encoding
base64_encode(salt + authTag + chipherText)
- the input to the base64 encoding fucntion is concatination of "salt", "authTag", and "chipherText".
- the order is important, "salt" goes first, then "authTag", and "chipherText" at the end.
- salt.length is 8 bytes.
- authTag.length is 16 bytes.
- chipherText.length is the rest (11 bytes, given "plainText" is 9-digit MSISDN).
- the output is base64 encoded string, which is sent as "X-MSISDN" header value.
***
Here's some pseudo code for easier reading:
salt = ... //salt is randomly generated before every encryption, length is 8 bytes.
passPhrase = ... // passPhrase is constant, length might differ.
hash = hash_sha384(concatenate[salt, passPhrase]) // hash length is 48 bytes.
KEY = hash.slice(0,32) // KEY length is 32 bytes.
IV = hash.slice(32,44) // IV length is 12 bytes (alternately it might be 16 bytes).
cipherText = aes_256_gcm(KEY, IV, plainText) // chipherText length is 11 bytes, given that plainText length is 9 bytes.
authTag = aes_256_gcm(KEY, IV, plainText).getAuthTag() //authTag length is 16 bytes.
encoded_string_to_send = base64_encode(concatenate[salt,authTag,cipherText])
***
Some assumptions about how AES-256-GCM-sha384 encryption works are obviously wrong, because it is impossible to decrypt the real data from the header following the specification above.
My questions are:
1) why the documentation is so vague about AES-256-GCM-sha384, whereas it is a recommended algorithm to use for the encryption? https://www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html
2) and which of the assumptions above of how AES-256-GCM-sha384 encryption works are wrong?
