views:

1829

answers:

7

I'm running into an issue with an ASP.NET 2.0 application. Our network folks just upped our security, and now I get the floowing error whenever I try to access the app:

"This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms."

I've done a little research, and it sounds like ASP.NET uses the RijndaelManaged AES encryption algorithm to encrypt the ViewState of pages... and RijndaelManaged is on the list of algorithms that aren't FIPS compliant. We're certainly not explicitly calling any encryption algorithm... much less anything on the non-compliant list.

This ViewState business makes sense to me, I guess. The thing I can't muddle out, though, is what to do about it. I've found a KB article that suggests using a web.config setting to specify a different algorithm... but either that didn't stick, or that algorithm isn't up to snuff, either.

So:

1) Is the RijndaelManaged / ViewState thing actually the problem? Or am I barking up the wrong tree?

2) How to I specify what algorithm to use instead of RijndaelManaged? I've got a list of algorithms that are and aren't compliant; I'm just not sure where to plug that information in.

Thanks!

Richard

+2  A: 

Regarding your 2nd question: Maybe this MSDN Article helps.

According to the docs you can configure the encryption algorithm like this:

<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>

For validation, you can use one of the following: [SHA1 | MD5 | 3DES | AES]

For decryption, you can use one of te following: [Auto | DES | 3DES | AES]

So in order to be FIPS compliant, you might use 3DES (although AFAIK theoretically less secure).

kay.herzam
A: 

We've tried the machineKey you suggest. It's helped with some web applications (when paired with ), which is great, but not all of them, which is frustrating.

I'm missing something, but danged if I can tell what.

R Rush
A: 

you will also need to do this on the box

Enforcing FIPS Certified Cryptography

Though not terribly relevant, hardly worthy of a -1, whoever you are - so balancing out by upvoting (if the -1er comes back and explains, I'm happy to remove my upvote). (The link explains how the network folks in question would have switched this policy on in the first place)
Ruben Bartelink
+4  A: 

Double check that you don't have <compilation debug="true" /> in your Web.config. When debug compilation is set, .NET uses an MD5 hash for some internal bookkeeping. MD5 is not FIPS compliant so you get this error.

Paul Alexander
A: 

Some sites like SharePoint sites have the SHA1 machine key already in the web config so check to see if there is already an algorythm there if there is delete it and add the above.

ross
A: 

Source: http://blogs.msdn.com/b/shawnfa/archive/2008/03/14/disabling-the-fips-algorithm-check.aspx

You could add the following to your web.config or machine config so your ASP.Net applications will stop failing due to the FIPs compliance checks.

<configuration>   

  <runtime>
        <enforceFIPSPolicy enabled="false"/>
    </runtime>

Your machine.config can be found here: \Microsoft.NET\Framework\\config\machine.config

If you change your machine.config, an iisreset may be required for the settings to take effect. Note: changing your maching.config will effect all .NET applications on the system.

WWC
A: 

The viewstate machine key and compilation="debug" config issues are the most common causes of this problem from what I've seen. As far as I know, in .NET 2.0, the 3DES algorithm for viewstate validation/encryption is the ONLY one that is FIPS compliant. So the SHA1, MD5, and AES options won't work there.

It's also important to realize that if a reference to ANY non-FIPS compliant algorithm is in the code, even if never actually used/reachable will cause the FIPS compliance error. For example just declaring an MD5CryptoServiceProvider variable without even instantiating it will cause the error. This includes other referenced .NET assemblies, so be sure no referenced dlls are possibly using non-fips compliant algorithms as well.

Here's a handy site that lists all of the FIPS and non-FIPS algorithms in .NET http://blog.aggregatedintelligence.com/2007/10/fips-validated-cryptographic-algorithms.html

zerrias