Questo articolo della Knowledge Base menziona un problema per cui la firma o la crittografia delle informazioni potrebbe causare una chiamata IO di rete a un controller di dominio.
Apparentemente i SignData e VerifyData di RSACryptoServiceProvider cercano l'OID in AD, ma lo scopo di questa chiamata mi sfugge.
Quale potrebbe essere il possibile vantaggio in termini di sicurezza di questo? Mi piacerebbe saperne di più.
Quando chiami SignData() o VerifyData() , devi specificare quale funzione hash usare (perché le firme funzionano sui messaggi con hash). Inoltre, con RSA specificamente come descritto da PKCS # 1 , il valore di hash è incapsulato all'interno di una struttura che contiene l' identificatore di oggetto (OID) della funzione di hash. Il metodo invocato deve quindi eseguire il mapping della specifica della funzione hash (che può essere una stringa) all'OID corrispondente e, in Active Directory, deve passare attraverso il server AD (il server AD è una sorta di gatekeeper per tali mapping) .
Quando il codice chiamante viene eseguito come account locale, il server AD potrebbe rifiutarsi di rispondere, quindi il ritardo.
Questa è una disfunzione dell'implementazione .NET: per le funzioni hash specifiche, il codice dovrebbe conoscere l'OID delle funzioni hash implementate (non ce ne sono così tante) e non dovrebbe essere necessario parlare al server AD per quello (questi OID sono "ben conosciuti" e standardizzati, non possono essere modificati a piacimento di un amministratore AD).
L'AD non funziona come autorità di certificazione:
013e3928 794f8a95 mscorlib_ni! System.Security.Cryptography.X509Certificates.X509Utils.OidToAlgId (System.String) + 0x15
Esempio:
// Verify the data using the signature. Pass a new instance of SHA1CryptoServiceProvider
// to specify the use of SHA1 for hashing.
return RSAalg.VerifyData(DataToVerify, new SHA1CryptoServiceProvider(), SignedData);
Leggi altre domande sui tag windows .net encryption active-directory