Login.gov encryption is badly designed

Login.gov encryption is badly designed.md

Login.gov encryption is badly designed

Disclaimer: everything that follows is a personal opinion - not an assertion of fact.

Regulatory/Compliance flaws

NIST has created Federal Information Processing Standard (FIPS) 140-2: Security Requirements for Cryptographic Modules. FIPS requirements are mandatory for Federal Government agencies, as prescribed by FISMA law. FIPS-140-2 Annex D covers Approved Key Establishment Techniques. The only FIPS-approved password-based key derivation algorithm is PBKDF2 (NIST SP800-132). Login.gov uses scrypt, which is not FIPS-approved. The FIPS-approved key-derivation algorithms are mostly covered by NIST SP800-108. Login.gov uses several custom approaches for key derivation, none of which are FIPS-approved.

Summary:

Login.gov likely violates FISMA law. US-Government Agencies which operate IT systems/applications which rely on Login.gov (as presently designed) likely violate FISMA law.

Cryptographic flaws

My analysis is based on Login.gov encryption overview available here and here. The following problematic design choices are noted:

1. scrypt is used as password-based KDF, which violates NIST 140-2.
2. Two subkeys Z1 and Z2 are derived via a non-approved KDF.
3. The purpose of Z1 is to act as a 2nd layer of encryption over the KMS-encrypted server-secret R. This violates FIPS, since the only FIPS-approved encryption is AES (in various approved encryption modes).
4. PII encryption key E is derived as hash (Z2 + Random). This is not a FIPS-approved KDF.
5. hash(E) is stored right next to the ciphertext from (4). Who thought that storing a hash of the encryption key right next to PII ciphertext encrypted with that key was a good idea?

(3) might also indicate an inadequate familiarity/understanding of AWS KMS. Z1 should have been passed as EncryptionContext to KMS_GCM_Encrypt, instead of the xor-masking silliness.

Summary:

It is my opinion that Login.gov cryptography was put together by amateurs, and was never reviewed by professionals. If NIST has truly consulted on and approved the current design, NIST has a lot of explaining to do.

Conclusion

Login.gov encryption design is flawed and exhibits serious "rookie" mistakes. If I were an auditor reviewing their Assessment & Authorization, I would revoke their ATO (Authorization to Operate). There is no place for home-made cryptography in USG systems - so says the law.

P.S. For those who do not know what an audit is - this is clearly not an audit.

@commit-dkp That's the right response (refreshing). I have full faith in 18F team's ability to manage their repo. Opening an issue did not seem appropriate when the system is running live in production. Your AO bears responsibility for running a non-compliant system in production - somehow I doubt he/she monitors the repo.

When 18F tries to be the tip of the spear to effect meaningful change within USG IT practices (which I definitely welcome), and acts as if it will be showing the way for all other USG agencies to follow, the spotlight is shining and both successes and mistakes need to be visible, acknowledged, understood, and learned from for everyone's benefit. With something as ambitious as Login.gov, the team needs to get it right, and so far it's not right.