> On 2010-11-26 13:20 PDT, [email protected] wrote: > [snip] > > And to save you a bit of trouble/pain: for CryptoAPI, you cannot > > simply sign raw data - you can only sign previously hashed data. I > > understand this to mean that you cannot write a pure PKCS#11 -> > > CryptoAPI mapper, whether .NET or at the raw Win32 level, because the > > CryptoAPI specifically forbids signing raw data of arbitrary length, > > while PKCS#11 permits it [7]. Your best bet, and a common approach > for > > the specific case of TLS client authentication, is to combine > > CryptCreateHash/CryptSetHashParam(HP_HASHVAL)/CryptSignHash. > [snip] > > [7] http://msdn.microsoft.com/en-us/library/aa380280(VS.85).aspx > > Ryan, Thanks for your comprehensive answer to Matej's question. > I suspect that not many readers of this list are very familiar with the > crypto capabilities of .NET. Speaking of > CryptSetHashParam(HP_HASHVAL), > http://msdn.microsoft.com/en-us/library/aa380270(VS.85).aspx says: > > > HP_HASHVAL. > > > > A byte array that contains a hash value to place directly into the > hash > > object. [snip] > > > > Some cryptographic service providers (CSPs) do not support this > > capability. > > Do you know which, if any, of Microsoft's CSPs do not support it? > > -- > /Nelson Bolyard > --
No, unfortunately I don't know - although I have not had any particular problems with this approach using the "stock" RSA CSP, PROV_RSA_SCHANNEL [1]. Since the concept of a CSP provider type may not be clear, a single DLL may implement multiple CSP types - as does the standard Microsoft DLL - each "type" representing a different set of required algorithms, key lengths, cipher modes, etc that MUST be implemented [2]. My understanding is that any provider implementing the PROV_RSA_SCHANNEL CSP type MUST support/implement this sequence [3], but CSPs / implementations of other provider types are neither required to nor particularly encouraged to. In the Microsoft Smart Card Minidriver Certification requirements, it details the API sequence for both CNG (Cryptography Next Generation, the Vista+ API) and CryptoAPI use for SSL client authentication (RSA) [4]. The sequence I described above is the sequence that Microsoft has documented as part of their Sequence Tests for conformant smart card minidrivers, so it can be presumed to be widely supported. A minidriver isn't required for a smart card to work with Windows, so it's not a MUST support, but the sequence is fairly well documented by Microsoft as being how they do it, so any vendor wanting to interoperate with Internet Explorer and the like will almost certainly implement it. It's also worth nothing, in the CNG world, this sequence is completely different, due to a whole set of new APIs meant to abstract SSL/TLS [5], and the concept of mapping to PKCS#11 really goes out the window. I should again note that my response was really in the context of SSL client authentication, which was the specific case of Matej's original question, and does not readily generalize to a pure PKCS#11 mapping. This is because the HP_HASHVAL must be the same length as the output of the hash algorithm, whereas the PKCS#11 mapping allows any size, up to k - 11, where k is the length in bytes of the RSA modulus. In addition to the documentation you referenced, there is also the note in CPSetHashParam [6], which is the low-level function that a CSP exports for CryptoAPI to call when the high-level function is called. The note for HP_HASHVAL there includes the following: "This parameter gives applications the ability to sign hash values, without having access to the base data. Because the application and the user have no idea what is being signed, this operation is intrinsically risky. It is envisioned that most CSPs will not support this parameter." And, to bring it back to NSS, this is the approach that exists in NSS's CryptoAPI wrapper/PKCS#11 provider [7], which also briefly comments on some of the above and previously discussed behaviours. The wrapper wraps the CKM_RSA_PKCS mechanism, as well as basic object certificate retrieval and storage, if I recall correctly, so it's a useful reference of sorts for this conversation. I'm not aware if this was actually deployed/shipped, considering the code exists almost verbatim as the day it was checked in, but it still exists in NSS CVS, so it is worth mentioning. It also works around a couple other CryptoAPI gotchas (eg: CryptSignHash outputs little-endian, rather than big-endian), so I'd encourage anyone interested in finding out more to check it out. Hope that helps, Ryan [1] http://msdn.microsoft.com/en-us/library/aa388168(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa380244(VS.85).aspx [3] http://msdn.microsoft.com/en-us/library/aa387710(VS.85).aspx [4] http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver_certreqs. mspx , Section 2.5.8.1 [5] http://msdn.microsoft.com/en-us/library/ff468652(VS.85).aspx [6] http://msdn.microsoft.com/en-us/library/aa379855(VS.85).aspx [7] http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ckfw/ca pi/crsa.c&rev=1.4&mark=512,519,532,538#470 -- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
