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.

If application A's encryption is not in compliance with regulation B, it doesn't follow that application A's encryption is badly designed. It could be that regulation B does not dictate good design.

1. scrypt is used as password-based KDF, which violates NIST 140-2.

This is confusing. How was VMWare able to get FIPS 140-2 level 1 validation despite using scrypt? http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm

There is no place for home-made cryptography in USG systems - so says the law.

While I agree, FIPS is a trashfire.

Seems more to me like FIPS is badly designed.

For anyone not knowledgeable about cryptography, this is not a high quality audit. My personal opinion on review of the design document is that it was written by a professional with knowledge of the field; any mistakes present are not amateur or "rookie" in quality by any means.

I personally strongly disagree with the recommendation. Any mistakes present, which I am not qualified to comment on, can most likely be fixed in this design.

@mquander is right on the money.

@soatok Because scrypt is listed as "Other algorithms", and not under "FIPS Approved Algorithms".

scrypt uses PBKDF2 on both the input and output pass. Keys "derived by scrypt" are, in fact, derived by PBKDF2: PBKDF2 is the first thing that touches the user password and the last thing to generate KDF output.

Beyond that though, scrypt was the first maximally memory hard KDF, and from a cryptographic point of view is very much superior to using PBKDF2 alone.

@tarcieri No one is arguing superiority or inferiority of scrypt over PBKDF2. You don't get to choose what is/isn't superior when designing and accrediting USG systems: you follow NIST requirements (FIPS) and FISMA law. Those who try to argue that everything that precedes PBKDF2 in scrypt should be considered as "key extraction", should read NIST SP800-56c, also referenced by FIPS-140-2 Annex-D (tldr: scrypt does not fly). Welcome to USG infosec compliance.

scrypt is one of the problems in Login.gov, but not the only problem - let's not make this about improper use of scrypt alone.

@sdrapkin Have you considered opening an issue in their repo at https://github.com/18F/identity-idp ? Or, if you would prefer, login.gov is in scope for the TTS Bug Bounty we run at https://hackerone.com/tts . Either way, the team welcomes all kind of feedback!

@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.