search

SolutionGuidance / psm

Welcome to the Medicare/Medicaid Provider Enrollment Screening Portal
http://projectpsm.org/
Other
26 stars 18 forks source link

Use FIPS-approved encryption #465

Closed cecilia-donnelly closed 6 years ago

cecilia-donnelly commented 7 years ago

"The PSM shall use only FIPS Pub 140-2-approved (or higher) encryption algorithms." and "The Contractor's data encryption solution shall meet Federal Information Processing Standard (FIPS) 140-2 and at a minimum use AES 128 encryption."

The first step here is to get the list of FIPS-approved algorithms (I think @jasonaowen may know about this?). See also #104.

cecilia-donnelly commented 7 years ago

@jasonaowen tells us that he's worked with this before and we may well be able to set bouncycastle to do the right thing and then make any necessary code changes. Finally, we'll validate that it works as intended.

jvasile commented 7 years ago

This blog post is old but it is actually a pretty good intro to FIPS 140-2. If you've never dealt with this stuff, please take a look at that page. It gets into more than just AES-128.

I'm ok letting bouncycastle DTRT, but I do think we should list all our encryption uses in this issue and check them all explicitly. And if we're going to rely on FIPS bouncycastle, we should probably read its security policy.

This doc might help:

The purpose of this document, and of Annexes C and D, is to provide a list of the approved security functions applicable to FIPS 140-2. Annex C lists the approved Random Bit Generators, while Annex D shows the approved Key Establishment Methods. The remaining approved security functions are listed in this Annex. The Annexes also provide the links to the descriptions of the allowed algorithms.

@jasonaowen Can you tell me where we are using encryption in the app?

Two quick things come to mind on action items:

Keys and CSPs may be stored within a module in any form – encrypted or unencrypted. To make a claim that keys and CSPs are stored encrypted, or, more precisely, “protected”, the module shall protect them using one of the following algorithms: • An AES or a Triple-DES encryption using any approved mode of AES or the Triple-DES as defined in Annex A of FIPS 140-2 • An RSA-based key encapsulation that may either comply with the requirements of SP 800-56B or be allowed by IG D.9. • An approved hash algorithm for a CSP such as a password that does not need to be recovered but is used to check if it matches any other values.

Likewise, https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions says

SHA-3 (i.e., SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256): Federal agencies may use the four fixed-length SHA-3 algorithms—SHA3-224, SHA3-256, SHA3-384, and SHA3-512 for all applications that employ secure hash algorithms.

With that in mind, I say we just settle on SHA3-256.

What else is encrypted?

Two more docs we should think about: I suppose our RNG should comport with https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexc.pdf. Similarly, https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexd.pdf

jvasile commented 7 years ago

We might want to mention FIPS in the docs so that future integration efforts keep it in mind. We should make sure our scripts DTRT for SSL to any proxy servers.

jvasile commented 7 years ago

After consultation with @jasonaowen we're going to (a) make sure we know what security code we have and (b) make sure that code exclusively uses bouncycastle. That should get us what we need. We'll put off auth delegation for another day.

cecilia-donnelly commented 7 years ago

Some ideas of what data should be stored encrypted:

A+ on that plan, @jvasile.

jvasile commented 7 years ago

We have encryption in the login process, SSL that wraps all traffic on 443 (but do we need it for the ETL stuff?), and hashed passwords. Is that the full list?

jasonaowen commented 6 years ago

We have encryption in the login process, SSL that wraps all traffic on 443 (but do we need it for the ETL stuff?), and hashed passwords. Is that the full list?

Yes, I believe so. The login process we're familiar with is the password-in-the-database method, but there's also some LDAP code floating around that we haven't spent any time on (see also the discussion in #34 ). We may need to use HTTPS for some of the external data services, depending on where they live, but right now we only have the LEIE which we serve over HTTP.

For the passwords we store in the database, we should use PBKDF2: if used with a FIPS-compliant pseudorandom function (such as SHA1), then PBKDF2 is FIPS-compliant. And, indeed, Spring Security has support for PBKDF2.

Currently, we load the "SHA" algorithm in a few places (1, 2, 3), which winds up being SHA1. You can verify this by comparing a known password (p1) with one in the database:

$ echo "SELECT password FROM cms_authentication WHERE username = 'p1';" \
  | psql -h localhost -U psm psm
             password              
-----------------------------------
 {SHA}t49XZhHsBvlq88plTCIXKl10bEA=
(1 row)
$ echo -n t49XZhHsBvlq88plTCIXKl10bEA= | base64 -d | xxd
00000000: b78f 5766 11ec 06f9 6af3 ca65 4c22 172a  ..Wf....j..eL".*
00000010: 5d74 6c40                                ]tl@
$ echo -n p1 | sha1sum
b78f576611ec06f96af3ca654c22172a5d746c40  -

The SHA series of hashing algorithms are not appropriate for passwords. From About Secure Password Hashing, on Security.SE:

A password hashing algorithm should be slow to prevent bruteforce attacks, [preferably] it should have features which actually decrease the feasibility of a distributed brute force attack on the hashes. This immediately throws out [SHA-1 and SHA-3].

After chatting briefly about this with @cecilia-donnelly , switching our password hashing to PBKDF2 will be my next priority.

I also looked into how to configure WildFly to be FIPS-compliant. It looks to be a combination of operating system configuration and selecting FIPS-compliant algorithms. See:

cecilia-donnelly commented 6 years ago

@jasonaowen, what's the status of this? I know we still need to fix #34, but can we close this FIPS issue?

cecilia-donnelly commented 6 years ago

@jasonaowen confirms that we can close this.