Re: [opensc-devel] PIV: signature output format
Hi Douglas,
I'm fine with that. I already changed our card driver to provide the
r||s format anyway.
After 0.13.0 we should work on the issue.
Did anyone already considered implementing support for PKCS#1 PSS format ?
We have support for it in the SmartCard-HSM and want to add it to OpenSC.
Andreas
Am 13.08.2012 00:45, schrieb Douglas E. Engert:
On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote:
Hi Viktor and Douglas,
I do also favour to keep the DER signature format at the interface
between the card driver and the pkcs15 framework.
OK, we could do that. I would like to wait till after 0.13.0 is released,
as the current code is working.
What is your scheduling requirements?
At the card driver level we don't know the field size, but we do at the
pkcs15 framework level. And all cards I know use the DER encoded
signature format anyway.
Maybe we can reuse Douglas code and do a conditional conversion in
sc_pkcs11_signature_final.
Andreas
Am 26.06.2012 08:06, schrieb Viktor Tarasov:
On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert deeng...@anl.gov
mailto:deeng...@anl.gov wrote:
Just back from vacation...
On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
Hi Douglas,
I'm trying to get signature with the PIV card and verify it
with the 'openssl pkeyutl'.
I use EC key #04 CARD AUTH Key.
It fails because of the 'raw' output format of the signature
produced by OpenSC.
OpenSSL expects the signature as a ASN1 sequence of two integers.
I've seen in card-piv.c your comments:
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
/* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
* Which may have leading 00 to force positive
* TODO: -DEE should check if PKCS15 want the same
It seems that PKCS#15 really wants it.
* But PKCS11 just wants 2* filed_length in bytes
Can you explain more? Why it wants 'raw' data?
PKCS#11 v2.30: says:
6.3.1 EC Signatures
For the purposes of these mechanisms, an ECDSA signature is an
octet string of even
length which is at most two times nLen octets, where nLen is the
length in octets of the
base point order n. The signature octets correspond to the
concatenation of the ECDSA
values r and s, both represented as an octet string of equal
length of at most nLen with the
most significant byte first. If r and s have different octet
length, the shorter of both must
be padded with leading zero octets such that both have the same
octet length.
PKCS#11 2.20 in Section 12.3.1 says the same as above.
PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
fixed size of nLen=20.
So PKCS#11 is not returning ASN1 but just the concatenation of r
and s.
Ok, thanks.
* So we have to strip out the integers
* if present and pad on left if too short.
*/
I would propose to keep the ASN1 encoded data at the PKCS#15
level,
and, if needed, to convert it to the 'raw' format by dedicated
procedure in the pkcs15 framework of pkcs11.
Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
If it needs to be ASN1, then yes the conversion could be done in
the framework.
Ok, there is no signature in ASN.1 in pkcs#15, but there some
practical reasons.
The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
OpenSSL, for which the pkcs15-tool have to provide data in a suitable
format, needs also the ASN.1 encoding.
So, my suggestion is to keep the encoding returned by the card at the
pkcs#15 level,
and change it to the 'raw' mode on the pkcs#11 side.
Finally, I have no preference, if you prefer to keep it like it is
now, we'll be living with.
Kind regards,
Viktor.
--
Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444 tel:%28630%29%20252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
-CardContact Software System Consulting
|.## ##.| Andreas Schwier
|# #| Schülerweg 38
|# #| 32429 Minden, Germany
|'## ##'| Phone +49 171 8334920
-http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
Re: [opensc-devel] PIV: signature output format
On 8/13/2012 3:00 AM, Andreas Schwier wrote:
Hi Douglas,
I'm fine with that. I already changed our card driver to provide the
r||s format anyway.
After 0.13.0 we should work on the issue.
Did anyone already considered implementing support for PKCS#1 PSS format ?
Not that I know of. Cards that do support padding on the card may need changes
to the card driver modules to take advantage of PSS.
For the PIV all padding is done in by the calling application
or by the OpenSC software if OpenSSL is used. The PIV card
supports only the RSA RAW operation, so it has not been an issue
so far. NIST 800-78-2 says PSS it is an acceptable padding to use.
We have support for it in the SmartCard-HSM and want to add it to OpenSC.
Andreas
Am 13.08.2012 00:45, schrieb Douglas E. Engert:
On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote:
Hi Viktor and Douglas,
I do also favour to keep the DER signature format at the interface
between the card driver and the pkcs15 framework.
OK, we could do that. I would like to wait till after 0.13.0 is released,
as the current code is working.
What is your scheduling requirements?
At the card driver level we don't know the field size, but we do at the
pkcs15 framework level. And all cards I know use the DER encoded
signature format anyway.
Maybe we can reuse Douglas code and do a conditional conversion in
sc_pkcs11_signature_final.
Andreas
Am 26.06.2012 08:06, schrieb Viktor Tarasov:
On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert deeng...@anl.gov
mailto:deeng...@anl.gov wrote:
Just back from vacation...
On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
Hi Douglas,
I'm trying to get signature with the PIV card and verify it
with the 'openssl pkeyutl'.
I use EC key #04 CARD AUTH Key.
It fails because of the 'raw' output format of the signature
produced by OpenSC.
OpenSSL expects the signature as a ASN1 sequence of two integers.
I've seen in card-piv.c your comments:
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
/* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
* Which may have leading 00 to force positive
* TODO: -DEE should check if PKCS15 want the same
It seems that PKCS#15 really wants it.
* But PKCS11 just wants 2* filed_length in bytes
Can you explain more? Why it wants 'raw' data?
PKCS#11 v2.30: says:
6.3.1 EC Signatures
For the purposes of these mechanisms, an ECDSA signature is an
octet string of even
length which is at most two times nLen octets, where nLen is the
length in octets of the
base point order n. The signature octets correspond to the
concatenation of the ECDSA
values r and s, both represented as an octet string of equal
length of at most nLen with the
most significant byte first. If r and s have different octet
length, the shorter of both must
be padded with leading zero octets such that both have the same
octet length.
PKCS#11 2.20 in Section 12.3.1 says the same as above.
PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
fixed size of nLen=20.
So PKCS#11 is not returning ASN1 but just the concatenation of r
and s.
Ok, thanks.
* So we have to strip out the integers
* if present and pad on left if too short.
*/
I would propose to keep the ASN1 encoded data at the PKCS#15
level,
and, if needed, to convert it to the 'raw' format by dedicated
procedure in the pkcs15 framework of pkcs11.
Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
If it needs to be ASN1, then yes the conversion could be done in
the framework.
Ok, there is no signature in ASN.1 in pkcs#15, but there some
practical reasons.
The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
OpenSSL, for which the pkcs15-tool have to provide data in a suitable
format, needs also the ASN.1 encoding.
So, my suggestion is to keep the encoding returned by the card at the
pkcs#15 level,
and change it to the 'raw' mode on the pkcs#11 side.
Finally, I have no preference, if you prefer to keep it like it is
now, we'll be living with.
Kind regards,
Viktor.
--
Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444 tel:%28630%29%20252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
[opensc-devel] Some elementary questions on smart card usage
I have some elementary questions concerning the usage of smart cards. They will probably be way too basic for members of this forum; maybe even inappropriate. My hope is that contributors to this forum with the necessary expertise will be able to point me in the right direction so I can carry on researching this subject further. Please, bear with me and my ignorance. I am particularly interested in the Common Access Card (CAC) used by the military (and others) to provide a two-factor authentication mechanism. My understanding is that the factors are something that you know (a PIN to unlock the card) and something that you have (the card itself.) Access to the card takes place by means of some specialized hardware - a card reader. I believe that the card reader may be physically connected to the device (server, computer, whatever one calls it) for which the smart card-provided authentication is required. Alternatively, the card reader may be provide authentication over the network. Let me go over these two cases, which I will refer to as cases 1 and 2, respectively. Case 1: I will refer to the card reader as CR, and to the server it is physically connected to as S. CR will allow a smart card user U to be authenticated in S. U inserts his or her CAC into CR. U is prompted for a PIN. Assuming the PIN punched in is correct, the CAC is unlocked. At this point CR will interact with S via some specialized application in S. This application must use a driver specifically developed for the CR hardware and whatever operating system (loosely speaking) that is used to control S. Assuming that this driver is in place and working correctly, what is the information exchanged between CR and S? I understand that the CAC uses X.509 certificates. How does the information exchange take place? My guess: S will access certificate information from the CAC using some cryptographic API (PKCS-11 seems to be a common one.) Each CAC will have an X.509 certificate assigned to it that has been signed by some certificate authority (CA) that must be known to S in advance. Essentially, S will use the appropriate CA certificate (which it will typically retrieve form local storage) in order to verify the X.509 certificate associated with the CAC in question that S has retrieved from CR. The verification may be a chained one. Is this a more or less accurate description, or am I totally off the bull's eye? Case 2: The setup here would be the following: A card reader CR physically connected to some device D (typically, but not necessarily, a PC) that can connect to some remote server S through some secure transport mechanism. The interaction wold be similar to the one described above, the difference being that D mediates the authentication. I.e. D will retrieve the CAC's certificate through interaction with CR, and will pass it on to S by means of the transport mechanism used by D to connect to S. The most straightforward one I can think of would be SSL/TLS: Once D has got the CAC's certificate C from CR, it will use C to start an SSL/TLS handshake with S. S will use standard SSL/TLS mechanisms to verify C. If this verification succeeds then the owner of CAC will be allowed to establish an SSL/TLS session with S. It's obvious that the example that I have in mind consists of establishing an HTTPS connection from a PC to some HTTPS server S. Again, is this a correct description? Feedback on this will be much appreciated. Again, if this is not the right forum for these questions, I will be most thankful if somebody could point me to the appropriate forum(s). ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Some elementary questions on smart card usage
On 8/13/2012 12:36 PM, JC wrote: I have some elementary questions concerning the usage of smart cards. They will probably be way too basic for members of this forum; maybe even inappropriate. My hope is that contributors to this forum with the necessary expertise will be able to point me in the right direction so I can carry on researching this subject further. Please, bear with me and my ignorance. Yes these are very elementary. I am particularly interested in the Common Access Card (CAC) used by the military (and others) to provide a two-factor authentication mechanism. My understanding is that the factors are something that you know (a PIN to unlock the card) and something that you have (the card itself.) Access to the card takes place by means of some specialized hardware - a card reader. The military CAC cards are being converted dual CAC and PIV cards using the NIST PIV standards. I suggest that you read NIST FIPS-201 (or NIST FIPS 201-2 draft) and NIST 800-73-3 to see what the U.S. Government is doing with smart cards. I believe that the card reader may be physically connected to the device (server, computer, whatever one calls it) for which the smart card-provided authentication is required. Alternatively, the card reader may be provide authentication over the network. Let me go over these two cases, which I will refer to as cases 1 and 2, respectively Much of what you want to do is already developed, with USB card readers, PC/SC card reader drivers, and vendor or open source middleware such as OpenSC or Coolkey, that can talk to applications using CAPI on Windows or PKCS#11 on any sustem. For example Mozilla Security Devices are PKCS#11 shared libs, that use the pcscd daemon to access CCID card readers, that that access the smartcard. Smart cards can be used with HTTPS via TLS for authentication. Windows 7 has built in support for PIV cards and pcsc, and IE and Outlook can use them as well as other applications. And in a Windows Domain the PIV can be used for login to AD. (The Kerberos PKINIT protocol is used here and can work on Linux too.) Case 1: I will refer to the card reader as CR, and to the server it is physically connected to as S. CR will allow a smart card user U to be authenticated in S. U inserts his or her CAC into CR. U is prompted for a PIN. Assuming the PIN punched in is correct, the CAC is unlocked. At this point CR will interact with S via some specialized application in S. This application must use a driver specifically developed for the CR hardware and whatever operating system (loosely speaking) that is used to control S. Assuming that this driver is in place and working correctly, what is the information exchanged between CR and S? I understand that the CAC uses X.509 certificates. How does the information exchange take place? My guess: S will access certificate information from the CAC using some cryptographic API (PKCS-11 seems to be a common one.) Each CAC will have an X.509 certificate assigned to it that has been signed by some certificate authority (CA) that must be known to S in advance. Essentially, S will use the appropriate CA certificate (which it will typically retrieve form local storage) in order to verify the X.509 certificate associated with the CAC in question that S has retrieved from CR. The verification may be a chained one. Is this a more or less accurate description, or am I totally off the bull's eye? NIST 800-73-3 part 1 Appendix B has some nice diagrams of using a card for authentication, with and without the PIN. Most cards need the PIN sent to the card, either via the application prompting for the PIN and sending it to the card, or by using a card reader with a build in pin pad reader, thus avoiding the application and host OS from seeing the PIN. (Not all middle ware of applications support pin pad readers.) The application either locally or the server at the other end of the network such as TLS or PKINIT verify the certificate. Case 2: The setup here would be the following: A card reader CR physically connected to some device D (typically, but not necessarily, a PC) that can connect to some remote server S through some secure transport mechanism. The interaction wold be similar to the one described above, the difference being that D mediates the authentication. I.e. D will retrieve the CAC's certificate through interaction with CR, and will pass it on to S by means of the transport mechanism used by D to connect to S. The most straightforward one I can think of would be SSL/TLS: Once D has got the CAC's certificate C from CR, it will use C to start an SSL/TLS handshake with S. S will use standard SSL/TLS mechanisms to verify C. If this verification succeeds then the owner of CAC will be allowed to establish an SSL/TLS session with S. It's obvious that the example that I have in mind consists of establishing an HTTPS connection from a PC
