RE: Certificate login in Firefox - how does it work?
> -Original Message- > From: dev-tech-crypto-bounces+ryan- > mozdevtechcrypto=sleevi@lists.mozilla.org [mailto:dev-tech-crypto- > bounces+ryan-mozdevtechcrypto=sleevi@lists.mozilla.org] On Behalf > Of Matej Kurpel > Sent: Sunday, November 28, 2010 11:24 AM > To: mozilla's crypto code discussion list > Subject: Re: Certificate login in Firefox - how does it work? > [snip] > On 26. 11. 2010 22:20, ryan-mozdevtechcry...@sleevi.com wrote: > > While I've not spent time hacking with PCKS#11, my understanding is > > that the C_Sign function should be treating the input as raw/opaque, > > dictated by the mechanism that was used to initialize. If you're > > relying on the input being in a particular format, you need to ensure > > that format is specified in the underlying PKCS#11 specification for > > that mechanism, otherwise it sounds like you're making assumptions that > > shouldn't be made. > This assumption is made by NSS and not by me. When signing e-mail in > Thunderbird, it sends DigestInfo (with DER-encoded OID and Hash value), > and when performing a SSL login, it sends raw data. The mechanism used > is always CKM_RSA_PKCS. I don't have a bulletproof way to determine > which of these two cases it is. What I meant to say is that your attempt to interpret the data being sent in is an assumption: that the data is meaningful. According to the PKCS#11 specification, you are just supposed to sign the data as provided, provided it meets the constraints inposed (l <= k-11). You're correct that, in the case of Thunderbird, it will send a full DigestInfo structure to be signed [1], while in the case of TLS client auth, it only sends the hashes [2]. In an "ideal world", your PKCS#11 module should not ascribe any meaning to that data. Please consider reviewing the PKCS#11 specification again [3]. For CKM_RSA_PKCS, it reads "This mechanism corresponds only to the part of PKCS #1 v1.5 that involves RSA; it does not compute a message digest or a DigestInfo encoding as specified for the md2withRSAEncryption and md5withRSAEncryption algorithms in PKCS #1 v1.5 ." The actual specification for PKCS #1 v1.5 is at [4]. Section 10.1 details how signatures are computed, and includes this: "The signature process consists of four steps: message digesting, data encoding, RSA encryption, and octet-string-to-bit-string conversion." When combined with what the PKCS#11 specification says for how the CKM_RSA_PKCS method behaves, it becomes clear that the mechanism should only apply the last two steps: "RSA encryption, and octet-string-to-bit-string conversion." The PKCS #1 v1.5 specification details the RSA encryption portion of signatures in section 10.1.3, which states that it should be computed using the behaviour described in Section 8.1 with a block type of 01 and a private key as described in Section 7. Ignoring the private key format as unrelated to this discussion, Section 8.1 describes the Encryption behaviour. While not intending to quote the whole thing, the format is described as: A block type BT, a padding string PS, and the data D shall be formatted into an octet string EB, the encryption block. EB = 00 || BT || PS || 00 || D . (1) Putting it all together, when PK11_Sign/C_Sign is called with CKM_RSA_PKCS, what you are provided as input is D. It may be a DigestInfo, where the caller has computed the hash of the original message M, and then encoded both it and the hash mechanism OID into the structure, as Thunderbird does and as specified by PKCS #7. But it may also be a "bare" hash, as described in TLS v1.0, where the DigestInfo is omitted and D is the concatenation of both the MD5 and SHA-1 hashes. Or it may be neither - simply raw data that should be encrypted, perhaps by using some new method that accommodates some weakness in the PKCS #1 v1.5 encryption/signature method. [5] In terms of conceptualizing the relationship between PKCS#11's CKM_RSA_PKCS and the PKCS #1 v1.5 specification, "PK11_Sign" is better thought of as "PK11_Encrypt" - the behaviour of the mechanism is specified by Section 8.1, Encryption, rather than Section 10.1, Signatures. As I mentioned, CryptoAPI does not expose this raw functionality - it only allows "encryption" of previously computed hashes, and it will compute the DigestInfo for you before encrypting. However, as I mentioned, you can suppress the computing the DigestInfo by passing CRYPT_NOHASHOID. Further, you can import the hash, generated via NSS, into CryptoAPI, by using CALG_SSL3_SHAMD5 and using CryptSetHashParam(HP_HASHVAL). This works because your input data, D, is 36 bytes, the same length as CALG_SSL3_SHAMD5, and presumably the CSP allows you to set HP_HASHVAL. The net result of this is the behaviour you desire. The reaso
Re: Certificate login in Firefox - how does it work?
On 28. 11. 2010 17:24, Matej Kurpel wrote: On 26. 11. 2010 22:20, ryan-mozdevtechcry...@sleevi.com wrote: -Original Message- Sent: Friday, November 26, 2010 3:16 PM To: mozilla's crypto code discussion list Subject: Certificate login in Firefox - how does it work? Hello, I am developing a PKCS#11 module and currently I am having problems getting the certificate login working in Firefox. I load a page, click on login button and then Firefox starts communicating with my PKCS#11 module (the page wants its users to log in using their certificates). It lets me select a certificate from a list - well, I only have one so I select it and continue. Then, after some more communication, C_Sign is performed. However, this fails because I have no way of dealing with the data Firefox sends to my PKCS#11 module (the data to sign using the C_Sign function). Signing works properly in Thunderbird since it sends DER-encoded data (hash algorithm OID and the hash itself) and dealing with that is fairly straightforward. However, Firefox sends some seemingly-random 36-byte data. If I use the same algorithm as for Thunderbird (doesn't matter if SHA1 or MD5), the page fails to load and says "ssl_error_decrypt_error_alert". I don't know what should my PKCS#11 module provide for the page to accept it correctly and continue. Just FYI, there is a C# .NET program on the other end and trying SignData or SignHash to compute the value to return proved unsuccessful. Please, could anybody enlighten this issue to me? Please see the TLS 1.0 RFC, Section 7.4.8. Certificate Verify [1] (or later, but TLS 1.0 is appropriate for the current release of NSS) The handshake of a TLS 1.0 client using an RSA key is the concatenation of the SHA-1 and MD-5 hashes of the handshake messages exchanged since the Client Hello. If you're mapping this to CryptoAPI types (since you mentioned C#, I'm presuming some Windows& CryptoAPI familiarity), this is CALG_SSL3_SHAMD5 [2]. The 36 bytes comes from the size of MD5 (16 bytes) and SHA-1 (20 bytes). For other key types (eg: DSA, ECC), and depending on whether you're acting as a server or a client, the signature data may differ, see the appropriate RFCs (ie: [3]) The actual call is made as part of ssl3_SignHashes, assuming you're using SSL 3.0/TLS 1.0. If you're using SSL 2.0, you've got more problems than hash signing. The implementation of this method is at [4]. I don't know what the page is actually using (I don't have it under my control). How can I determine it? While I've not spent time hacking with PCKS#11, my understanding is that the C_Sign function should be treating the input as raw/opaque, dictated by the mechanism that was used to initialize. If you're relying on the input being in a particular format, you need to ensure that format is specified in the underlying PKCS#11 specification for that mechanism, otherwise it sounds like you're making assumptions that shouldn't be made. This assumption is made by NSS and not by me. When signing e-mail in Thunderbird, it sends DigestInfo (with DER-encoded OID and Hash value), and when performing a SSL login, it sends raw data. The mechanism used is always CKM_RSA_PKCS. I don't have a bulletproof way to determine which of these two cases it is. For SSL/TLS signatures, and for RSA keys, the mechanism passed is CKM_RSA_PKCS [5]. According to the PKCS#11 specification, this mechanism corresponds to computing the raw RSA signature over data, *excluding* computing the message digest or DigestInfo structure [6]. In CryptoAPI terms, this is the option CRYPT_NOHASHOID [7]. For what it's worth, I'm not aware of this flag being exposed by the .NET implementation, eg: System.Security.Cryptography.RSACryptoServiceProvider's SignHash. You'll likely need to do some marshalling to the native APIs if you're using C#. Yes, I think so too. But I am not familiar with WinAPI and the source codes in MSDN look really terrible. Also I don't use CryptoAPI, I manage my certificates and keys myself in my C# .NET program and use RSACryptoServiceProvider for the cryptographic operations. So I have access to raw key and certificate data, I don't want to mess with all the CryptoAPI things. I think it would involve more than just marshalling, I would have to make my own C++ dll file which would perform such operations and then marshal data between it and my C# program. I have tried it before with something else and it didn't work as expected... The second thing is that the C# .NET program I am talking about is actually .NET CF program which is run on a Windows Mobile system. The .NET CF framework is somewhat crippled of some features so I really don't know if the API functions described in MSDN are available. And to save you a bit of trouble/pain: for CryptoAPI, you cannot simply sign raw data
Re: Certificate login in Firefox - how does it work?
On 26. 11. 2010 22:20, ryan-mozdevtechcry...@sleevi.com wrote: -Original Message- Sent: Friday, November 26, 2010 3:16 PM To: mozilla's crypto code discussion list Subject: Certificate login in Firefox - how does it work? Hello, I am developing a PKCS#11 module and currently I am having problems getting the certificate login working in Firefox. I load a page, click on login button and then Firefox starts communicating with my PKCS#11 module (the page wants its users to log in using their certificates). It lets me select a certificate from a list - well, I only have one so I select it and continue. Then, after some more communication, C_Sign is performed. However, this fails because I have no way of dealing with the data Firefox sends to my PKCS#11 module (the data to sign using the C_Sign function). Signing works properly in Thunderbird since it sends DER-encoded data (hash algorithm OID and the hash itself) and dealing with that is fairly straightforward. However, Firefox sends some seemingly-random 36-byte data. If I use the same algorithm as for Thunderbird (doesn't matter if SHA1 or MD5), the page fails to load and says "ssl_error_decrypt_error_alert". I don't know what should my PKCS#11 module provide for the page to accept it correctly and continue. Just FYI, there is a C# .NET program on the other end and trying SignData or SignHash to compute the value to return proved unsuccessful. Please, could anybody enlighten this issue to me? Please see the TLS 1.0 RFC, Section 7.4.8. Certificate Verify [1] (or later, but TLS 1.0 is appropriate for the current release of NSS) The handshake of a TLS 1.0 client using an RSA key is the concatenation of the SHA-1 and MD-5 hashes of the handshake messages exchanged since the Client Hello. If you're mapping this to CryptoAPI types (since you mentioned C#, I'm presuming some Windows& CryptoAPI familiarity), this is CALG_SSL3_SHAMD5 [2]. The 36 bytes comes from the size of MD5 (16 bytes) and SHA-1 (20 bytes). For other key types (eg: DSA, ECC), and depending on whether you're acting as a server or a client, the signature data may differ, see the appropriate RFCs (ie: [3]) The actual call is made as part of ssl3_SignHashes, assuming you're using SSL 3.0/TLS 1.0. If you're using SSL 2.0, you've got more problems than hash signing. The implementation of this method is at [4]. I don't know what the page is actually using (I don't have it under my control). How can I determine it? While I've not spent time hacking with PCKS#11, my understanding is that the C_Sign function should be treating the input as raw/opaque, dictated by the mechanism that was used to initialize. If you're relying on the input being in a particular format, you need to ensure that format is specified in the underlying PKCS#11 specification for that mechanism, otherwise it sounds like you're making assumptions that shouldn't be made. This assumption is made by NSS and not by me. When signing e-mail in Thunderbird, it sends DigestInfo (with DER-encoded OID and Hash value), and when performing a SSL login, it sends raw data. The mechanism used is always CKM_RSA_PKCS. I don't have a bulletproof way to determine which of these two cases it is. For SSL/TLS signatures, and for RSA keys, the mechanism passed is CKM_RSA_PKCS [5]. According to the PKCS#11 specification, this mechanism corresponds to computing the raw RSA signature over data, *excluding* computing the message digest or DigestInfo structure [6]. In CryptoAPI terms, this is the option CRYPT_NOHASHOID [7]. For what it's worth, I'm not aware of this flag being exposed by the .NET implementation, eg: System.Security.Cryptography.RSACryptoServiceProvider's SignHash. You'll likely need to do some marshalling to the native APIs if you're using C#. Yes, I think so too. But I am not familiar with WinAPI and the source codes in MSDN look really terrible. Also I don't use CryptoAPI, I manage my certificates and keys myself in my C# .NET program and use RSACryptoServiceProvider for the cryptographic operations. So I have access to raw key and certificate data, I don't want to mess with all the CryptoAPI things. I think it would involve more than just marshalling, I would have to make my own C++ dll file which would perform such operations and then marshal data between it and my C# program. I have tried it before with something else and it didn't work as expected... The second thing is that the C# .NET program I am talking about is actually .NET CF program which is run on a Windows Mobile system. The .NET CF framework is somewhat crippled of some features so I really don't know if the API functions described in MSDN are available. And to save you a bit of trouble/pain: for CryptoAPI, you cannot simply sign raw data - you can only sign previously hashed data.
RE: Certificate login in Firefox - how does it work?
> 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
Re: Certificate login in Firefox - how does it work?
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
RE: Certificate login in Firefox - how does it work?
> -Original Message- > Sent: Friday, November 26, 2010 3:16 PM > To: mozilla's crypto code discussion list > Subject: Certificate login in Firefox - how does it work? > > Hello, > I am developing a PKCS#11 module and currently I am having problems > getting the certificate login working in Firefox. > I load a page, click on login button and then Firefox starts > communicating with my PKCS#11 module (the page wants its users to log > in using their certificates). It lets me select a certificate from a > list - well, I only have one so I select it and continue. Then, after > some more communication, C_Sign is performed. However, this fails > because I have no way of dealing with the data Firefox sends to my > PKCS#11 module (the data to sign using the C_Sign function). > Signing works properly in Thunderbird since it sends DER-encoded data > (hash algorithm OID and the hash itself) and dealing with that is > fairly straightforward. > However, Firefox sends some seemingly-random 36-byte data. If I use the > same algorithm as for Thunderbird (doesn't matter if SHA1 or MD5), the > page fails to load and says "ssl_error_decrypt_error_alert". I don't > know what should my PKCS#11 module provide for the page to accept it > correctly and continue. > Just FYI, there is a C# .NET program on the other end and trying > SignData or SignHash to compute the value to return proved > unsuccessful. > Please, could anybody enlighten this issue to me? Please see the TLS 1.0 RFC, Section 7.4.8. Certificate Verify [1] (or later, but TLS 1.0 is appropriate for the current release of NSS) The handshake of a TLS 1.0 client using an RSA key is the concatenation of the SHA-1 and MD-5 hashes of the handshake messages exchanged since the Client Hello. If you're mapping this to CryptoAPI types (since you mentioned C#, I'm presuming some Windows & CryptoAPI familiarity), this is CALG_SSL3_SHAMD5 [2]. The 36 bytes comes from the size of MD5 (16 bytes) and SHA-1 (20 bytes). For other key types (eg: DSA, ECC), and depending on whether you're acting as a server or a client, the signature data may differ, see the appropriate RFCs (ie: [3]) The actual call is made as part of ssl3_SignHashes, assuming you're using SSL 3.0/TLS 1.0. If you're using SSL 2.0, you've got more problems than hash signing. The implementation of this method is at [4]. While I've not spent time hacking with PCKS#11, my understanding is that the C_Sign function should be treating the input as raw/opaque, dictated by the mechanism that was used to initialize. If you're relying on the input being in a particular format, you need to ensure that format is specified in the underlying PKCS#11 specification for that mechanism, otherwise it sounds like you're making assumptions that shouldn't be made. For SSL/TLS signatures, and for RSA keys, the mechanism passed is CKM_RSA_PKCS [5]. According to the PKCS#11 specification, this mechanism corresponds to computing the raw RSA signature over data, *excluding* computing the message digest or DigestInfo structure [6]. In CryptoAPI terms, this is the option CRYPT_NOHASHOID [7]. For what it's worth, I'm not aware of this flag being exposed by the .NET implementation, eg: System.Security.Cryptography.RSACryptoServiceProvider's SignHash. You'll likely need to do some marshalling to the native APIs if you're using C#. 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. Discussing that solution is veering off the topic from this list, but with that above information and some targeted searching, you should find a number of discussions on this approach. Hope that helps. [1] http://www.ietf.org/rfc/rfc2246.txt [2] http://msdn.microsoft.com/en-us/library/aa379865(VS.85).aspx [3] http://www.ietf.org/rfc/rfc4492.txt [4] http://mxr.mozilla.org/security/source/security/nss/lib/ssl/ssl3con.c#845 [5] http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11mech.c#1859 [6] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf , Section 12.1.6. [7] http://msdn.microsoft.com/en-us/library/aa380280(VS.85).aspx -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Certificate login in Firefox - how does it work?
Hello, I am developing a PKCS#11 module and currently I am having problems getting the certificate login working in Firefox. I load a page, click on login button and then Firefox starts communicating with my PKCS#11 module (the page wants its users to log in using their certificates). It lets me select a certificate from a list - well, I only have one so I select it and continue. Then, after some more communication, C_Sign is performed. However, this fails because I have no way of dealing with the data Firefox sends to my PKCS#11 module (the data to sign using the C_Sign function). Signing works properly in Thunderbird since it sends DER-encoded data (hash algorithm OID and the hash itself) and dealing with that is fairly straightforward. However, Firefox sends some seemingly-random 36-byte data. If I use the same algorithm as for Thunderbird (doesn't matter if SHA1 or MD5), the page fails to load and says "ssl_error_decrypt_error_alert". I don't know what should my PKCS#11 module provide for the page to accept it correctly and continue. Just FYI, there is a C# .NET program on the other end and trying SignData or SignHash to compute the value to return proved unsuccessful. Please, could anybody enlighten this issue to me? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
