2

I got tasked with coming up with a way to change our company's data library to be FIPS 140-2 compliant. We're primarily a microsoft shop and currently have a crypto library leveraging RijndealManaged to perform our encryption/decryption. There are multiple environments involved, so whatever solution I come up with would require encryption/decryption of the same message to happen on independent machines (So I dont think I can use the .net libraries like AESCryptoProvider which relies on the OS)

I don't have a deep understanding or background in cryptography but off the research that I've done to this point, I know that AES is still a FIPS 140-2 compliant algorithm. My question is: is there is an updated .NET AES Managed module that I could use across these environments to be FIPS 140-2 compliant? Does the AESManaged module just require me to configure it in a particular way (i.e. 256 key size and 128 block size) in order be FIPS compliant?

I can't use third party libraries.

Zeus82
  • 6,065
  • 9
  • 53
  • 77
JakeHova
  • 1,189
  • 2
  • 15
  • 36
  • Don't waste time with FIPS-140. It is too complex and too expensive "thing". – i486 Mar 09 '16 at 15:21
  • 2
    The issue is using the NIST Certified FIPS compliant algorithm. Microsoft only had NIST certify the algorithms built into the OS (since certification is a costly/lengthy process). Any framework (.Net or otherwise) that does not use the OS algorithms is not NIST certified FIPS compliant. So, essentially, RijndealManaged is FIPS compliant (it is the exact same algorithm as in the OS), but it is not NIST certified. – Kevin Mar 09 '16 at 15:23
  • See http://stackoverflow.com/a/939106/613130 – xanatos Mar 09 '16 at 15:26
  • 1
    @i486 In some instances FIPS 140-2 is required. – zaph Mar 09 '16 at 16:06
  • @i486 From what's been explained to me, the client is planning on moving into an environment where FIPS compliance is enabled on the servers hence the need to find a way to get it to work. – JakeHova Mar 09 '16 at 16:33
  • @Kevin - Thanks for the info, very helpful albeit unfortunate for my case. – JakeHova Mar 09 '16 at 16:34
  • @xanatos - Yeah, I saw that link but was hoping there was some updated information considering that answer was written in '09. – JakeHova Mar 09 '16 at 16:34
  • I don't think that one system is FIPS-140 compliant because some of its elements (algorithms, etc.) are FIPS-140 compliant. To get real FIPS-140 certification is too complex. – i486 Mar 09 '16 at 16:38
  • What, specifically, are your other environments if they are not Windows? – Kevin Mar 09 '16 at 16:45
  • @Kevin - After reading, your question, it hit me that the crypto library is not machine specific but rather OS platform specific. Is that right? if the downstream systems are some flavor of Windows (server 2008r2 & 2012 & server 2016 techprev are the ones I know of right now), then they should all be able to decrypt the message accordingly right? There are no UNIX based servers (which would obviously eliminate the usage of .net anyway) – JakeHova Mar 09 '16 at 16:55
  • 1
    As long as the .Net Framework installed is 3.5+ the classes that wrap the NIST certified FIPS 140-2 compliant algorithms will be available. – Kevin Mar 09 '16 at 17:05
  • @Kevin - If you want to reply to the question as this being the answer, I'd gladly accept it. Thanks for your help! – JakeHova Mar 09 '16 at 17:06
  • The trick is to encrypt on one machine and decrypt on another, you have to use the same key and initialization vector values. – Kevin Mar 09 '16 at 17:07

1 Answers1

4

As long as the .Net Framework installed is 3.5+ the classes that wrap the NIST certified FIPS 140-2 compliant algorithms will be available.

The trick is to encrypt on one machine and decrypt on another, you have to use the same key and initialization vector values.

You should be able to simply replace the calls in your library to the RijndaelManaged class with the same calls to AESCryptoServiceProvider class.

Kevin
  • 1,462
  • 9
  • 9