2010-02-19 16 views
5

Se si abilita l'opzione "Usa gli algoritmi di conformità FIPS per la crittografia, l'hashing e la firma" dell'opzione di politica di sicurezza in Windows, il tentativo di utilizzare molte delle classi crittografiche in .NET Framework genererà InvalidOperationException. Per impostazione predefinita, ASP.NET utilizza AES per crittografare il blob ViewState, quindi non riesce. Puoi aggirare questo problema aggiungendo una chiave come questa a web.config:È possibile che ASP.NET ScriptManager funzioni con la politica di sicurezza FIPS di Windows?

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

E questo copre l'utente per l'utilizzo di base di ASP.NET. Il mio problema è questo: ho una grande, complessa applicazione web ASP.NET che fa un uso pesante di ScriptManagers (il fondamento di ASP.NET AJAX) e deve essere distribuito da un cliente governativo che deve abilitare questa impostazione dei criteri FIPS. Ogni pagina ASP.NET con uno ScriptManager su di esso genera questa eccezione:

[InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.] 
    System.Security.Cryptography.SHA1Managed..ctor() +3607454 
    System.Security.Policy.Hash.get_SHA1() +45 
    System.Web.Handlers.ScriptResourceHandler.GetAssemblyInfoInternal(Assembly assembly) +85 
    System.Web.Handlers.ScriptResourceHandler.GetAssemblyInfo(Assembly assembly) +99 
    System.Web.Handlers.RuntimeScriptResourceHandler.GetScriptResourceUrlImpl(List`1 assemblyResourceLists, Boolean zip, Boolean notifyScriptLoaded) +525 
    System.Web.Handlers.RuntimeScriptResourceHandler.System.Web.Handlers.IScriptResourceHandler.GetScriptResourceUrl(List`1 assemblyResourceLists, Boolean zip, Boolean notifyScriptLoaded) +910 
    System.Web.Handlers.RuntimeScriptResourceHandler.System.Web.Handlers.IScriptResourceHandler.GetScriptResourceUrl(Assembly assembly, String resourceName, CultureInfo culture, Boolean zip, Boolean notifyScriptLoaded) +193 
    System.Web.UI.ScriptReference.GetUrlFromName(ScriptManager scriptManager, IControl scriptManagerControl, Boolean zip) +306 
    System.Web.UI.ScriptManager.RegisterUniqueScripts(List`1 uniqueScripts) +169 
    System.Web.UI.ScriptManager.RegisterScripts() +407 
    System.Web.UI.ScriptManager.OnPagePreRenderComplete(Object sender, EventArgs e) +200 
    System.Web.UI.Page.OnPreRenderComplete(EventArgs e) +11041982 
    System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3672 

Anche aggiungendo l'elemento <enforceFIPSPolicy enabled="false"/> al web.config non risolve l'eccezione.

Esiste un modo per configurare ASP.NET in modo tale che ScriptManager possa essere utilizzato con la politica di sicurezza FIPS di Windows?

risposta

3

aggiornamento fornito da Microsoft: La correzione a caldo è disponibile presso http://code.msdn.microsoft.com/KB981119

La risposta è che non è possibile utilizzare ScriptManager con FIPS di server abilitati. :(

Il metodo statico GetAssemblyInfo di classe System.Web.Handlers.ScriptResourceHandler crea un oggetto hash che non è FIPS compatibile. Questo è stato cambiato tra .Net 3.5 SP1 e .Net 3.51

(System.Web. estensioni versione 3.5.30729.196)
XP/2003/2008 .Net 3.5 SP1

private static Pair<AssemblyName, DateTime> GetAssemblyInfoInternal(Assembly assembly) 
{ 
    return new Pair<AssemblyName, DateTime>(new AssemblyName(assembly.FullName), GetLastWriteTime(assembly)); 
} 

(versione System.Web.Extensions 3.5.30729.4926)
Win7/2008R2 .Net 3.51

private static Pair<AssemblyName, string> GetAssemblyInfoInternal(Assembly assembly) 
{ 
    AssemblyName first = new AssemblyName(assembly.FullName); 
    return new Pair<AssemblyName, string>(first, Convert.ToBase64String(new Hash(assembly).SHA1)); 
} 

Ovviamente il passaggio dal timbro data/ora all'hash ha infranto la conformità FIPS. Abbiamo aperto un caso di supporto con Microsoft.

1

Microsoft ha rilasciato un hotfix per risolvere questo problema: KB981119. Non penso che la correzione sia pubblicamente disponibile tramite il sito Web Microsoft.