On 2010-11-26 13:20 PDT, ryan-mozdevtechcry...@sleevi.com 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
