Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite

This KB article mentions an issue where signing or encrypting information may result in a network IO call to a Domain Controller.

Apparently the RSACryptoServiceProvider's SignData and VerifyData looks up the OID in AD, but the purpose of this call eludes me.

What could be the possible security benefit of this? I'd like to learn more about it.

share|improve this question

2 Answers

up vote 2 down vote accepted

When you call SignData() or VerifyData(), you must specify which hash function to use (because signatures operate on hashed messages). Moreover, with RSA specifically as described by PKCS#1, the hash value is encapsulated inside a structure which contains the object identifier (OID) of the hash function. The invoked method must thus map the provided hash function specification (which can be a string) to the corresponding OID, and, in the Active Directory, this must go through the AD server (the AD server is a kind of gatekeeper for such mappings).

When the calling code runs as a local account, the AD server may refuse to respond, hence the delay.

This is a misfeature of the .NET implementation: for hash functions specifically, the code should know of the OID of the hash functions it implements (there are not so many) and should not need to talk to the AD server for that (these OID are "well-known" and standardized, they cannot change at the whim of an AD administrator).

share|improve this answer
So I guess that means that OIDs are stored in AD somewhere for this to work? Is there any legitimate reason for this feature? – makerofthings7 Aug 22 '12 at 14:40
I suppose that the OID are not really in the AD, but the code in .NET first tries a generic conversion method which looks in the AD. After all, when the delay occurs, the AD refuses to respond, but the signature generation or verification still succeeds. – Tom Leek Aug 22 '12 at 21:49
up vote 0 down vote

Isn't the AD acting as a Certificate Authority:

013e3928 794f8a95 mscorlib_ni!System.Security.Cryptography.X509Certificates.X509Utils.OidToAlgId(System.String)+0x15

Example:

        // 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);
share|improve this answer
Are you saying that you debugged VerifyData to see the call to AD? I'm not sure if a CA even needs to be present to make the API connect to AD (RSA can make its own keys). Does the call still exist when the CA is moved to a non DC? – makerofthings7 Jul 23 '12 at 14:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.