Re: [opensc-devel] proving a key is on a smart card
Frank Cusack wrote: For example, if I had some key/cert on the card (and I know it can only exist on the card -- this might happen before it is shipped to me or in bulk secure provisioning on site) that is not able to be used for anything externally. ie, you cannot encrypt,decrypt,sign or verify any external data with this key/cert. But when you ask for a CSR, there's actually a CSR APDU -- not a software generation of CSR then asking the card to sign the CSR. You pass the relevant attributes to be included in the CSR, and the card itself adds some signed data as a CSR attribute which the CA can verify. There is no way for the user to add that signed data to a software CSR because the key used to sign that data is not available to the user. That's just a way I thought of, maybe there is some other way as well. The current (but under revision) Swedish eID card includes a scheme like this. The card is delivered with a special key+cert which is meant to authenticate the card when it is enrolling. So far for the theory. In practise I've seen zero software solutions use this key+cert. I guess there may be one at the police (they issue passports and this card) but.. It seems it would be a good advantage to be able to do this, you could provision on demand at an insecure station, instead of (e.g.) having a secure station and provisioning with a single-use PIN. OTOH you need special cards and special software on the insecure station. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
On Wed, Jan 18, 2012 at 11:30:36PM -0800, Frank Cusack wrote: On Wed, Jan 18, 2012 at 11:04 PM, Christian Hohnstaedt christ...@hohnstaedt.de wrote: On Wed, Jan 18, 2012 at 04:20:05PM -0800, Frank Cusack wrote: In a CSR, how is it proven that the key resides on a smart card (and is not exportable)? In my understanding, the CSR is signed by the private key of the (to be) cert itself. Thus that signature only proves that the requester actually possesses the private half, not that the private key resides on a smart card. Looking at the cryptoflex command set, I don't see anything there that would add something to the CSR asserting that the key was generated on-card. Same for ISO 7816-8, but I could easily be missing something. You're probably missing the fact that noone stops the owner of a software key to add the same information to the CSR. Not if there's an APDU that adds that information as part of the operation, and the key used in that operation cannot be used except for CSR generation. For example, if I had some key/cert on the card (and I know it can only exist on the card -- this might happen before it is shipped to me or in bulk secure provisioning on site) The problem is, that nobody can distinguish the public key of a smart card from a software key. That means, there must be a secret on the card that is known by the CA. Therefore the CA operator needs prior access to the cards. If the CA operator has prior access to the cards, a simple solution could be to extract the public key and probably store it in a hashed way in some sort of database. For every incoming CSR the CA searches for the public key hash in its database. No additional APDU or secret required. that is not able to be used for anything externally. ie, you cannot encrypt,decrypt,sign or verify any external data with this key/cert. But when you ask for a CSR, there's actually a CSR APDU -- not a software generation of CSR then asking the card to sign the CSR. You pass the relevant attributes to be included in the CSR, and the card itself adds some signed data as a CSR attribute which the CA can The question is: What shall the the signed data be ? verify. There is no way for the user to add that signed data to a software CSR because the key used to sign that data is not available to the user. That is what i doubt. Anything that can be signed by the card can be signed by a software key, too. Cheers Christian ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
Seriously, please trim replies. Christian Hohnstaedt wrote: Anything that can be signed by the card can be signed by a software key, too. Yes of course. But the point is that the card can come with the special key pre-installed. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
Il 19/01/2012 09:16, Peter Stuge ha scritto: Christian Hohnstaedt wrote: Anything that can be signed by the card can be signed by a software key, too. Yes of course. But the point is that the card can come with the special key pre-installed. I see at least two ways here: 1) the 'technical' way: have a card that, when issued (= before being given to the user), already contains a cert for a key generated on-card. When the user requests a new cert, the old (referencing the same private key) must be included as a proof (actually, the 'public key' part could be taken from this cert, simplifying CSR that could even be a simple web form for the other infos). 2) the 'legal' way (might not be applicable everywhere): when the user submits a CSR, (s)he must swear that the key have been generated on-card and is not extractable It's the usual chicken-and-egg problem. :) PS: a doubt just popped in my mind: can I store multiple certs for the same private key? How? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
Dear Frank, we have such a card. Take a look at [1]. The card internally generates a key pair and a CSR as defined in TR-03110 (that is the standard for biometric passports, in particular Extended Access Control). Such an authenticated request contains two signatures: the inner signature is the proof-of-correspondence (I own the private and public key) and the outer signature provides proof-of-origin (the key was generated in an authentic device). Each card contains a device authentication key that gets certified during production. A CA receiving a certificate request must 1. first verify the device authentication certificate read from the card, 2. then verify the outer signature with the public key obtained from the device authentication certificate, 3. then verify the inner signature to prove that the sender actually owns the private key and 4. finally issue a certificate for the public key contained. The scheme is specifically used for remote certificate issuance, where you can not rely on a secure communication channel between the CA and the token. Andreas [1] http://www.cardcontact.de/products/SmartCard-HSM_V1.0.pdf Am 19.01.2012 01:20, schrieb Frank Cusack: In a CSR, how is it proven that the key resides on a smart card (and is not exportable)? In my understanding, the CSR is signed by the private key of the (to be) cert itself. Thus that signature only proves that the requester actually possesses the private half, not that the private key resides on a smart card. Looking at the cryptoflex command set, I don't see anything there that would add something to the CSR asserting that the key was generated on-card. Same for ISO 7816-8, but I could easily be missing something. Are there card specific APDUs that add some proof? If so, any pointers to what cards can do this? Or is the typical method basically to require use of a secure enrollment station? ___ 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 http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
On 2012-01-19 09:38, NdK wrote: Il 19/01/2012 09:16, Peter Stuge ha scritto: Christian Hohnstaedt wrote: Anything that can be signed by the card can be signed by a software key, too. Yes of course. But the point is that the card can come with the special key pre-installed. I see at least two ways here: 1) the 'technical' way: have a card that, when issued (= before being given to the user), already contains a cert for a key generated on-card. When the user requests a new cert, the old (referencing the same private key) must be included as a proof (actually, the 'public key' part could be taken from this cert, simplifying CSR that could even be a simple web form for the other infos). 2) the 'legal' way (might not be applicable everywhere): when the user submits a CSR, (s)he must swear that the key have been generated on-card and is not extractable It's the usual chicken-and-egg problem. :) This is since long solved problem. It is an intrinsic part of GlobalPlatform where you don't really use CSR's and PoP's but a session-key to secure that you are really talking to the card. On http://webpki.org/auth-token-4-the-cloud.html you can find a lot of material on a system that takes this concept to a new level by making the entire provisioning session a transaction. I hope to present it on FOSDEM but I haven't heard from Martin yet... -- Anders PS: a doubt just popped in my mind: can I store multiple certs for the same private key? How? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
On Thu, Jan 19, 2012 at 12:38 AM, NdK ndk.cla...@gmail.com wrote: Il 19/01/2012 09:16, Peter Stuge ha scritto: Christian Hohnstaedt wrote: Anything that can be signed by the card can be signed by a software key, too. Yes of course. But the point is that the card can come with the special key pre-installed. I see at least two ways here: 1) the 'technical' way: have a card that, when issued (= before being given to the user), already contains a cert for a key generated on-card. When the user requests a new cert, the old (referencing the same private key) must be included as a proof (actually, the 'public key' part could be taken from this cert, simplifying CSR that could even be a simple web form for the other infos). Thanks. I independently just thought of this and seeing your response validates my thought. This method seems much easier than my convoluted approach, but I like even more the method suggested by Christian: the CA just knows the public keys in advance. It's also nice (for both methods: public key or cert exchange) that the user doesn't have to sit there waiting for key generation. On Thu, Jan 19, 2012 at 12:03 AM, Christian Hohnstaedt christ...@hohnstaedt.de wrote: On Wed, Jan 18, 2012 at 11:30:36PM -0800, Frank Cusack wrote: verify. There is no way for the user to add that signed data to a software CSR because the key used to sign that data is not available to the user. That is what i doubt. Anything that can be signed by the card can be signed by a software key, too. Not if the operation requires that the card add the data, and the key used won't sign raw input data. For example, consider a CA. It doesn't just sign what you pass to it. It adds some locally generated attributes (most importantly a serial number, which can't be user influenced) and signs that. A software key can do all that, of course, but in my proposal we have to already know that the signing (attestation?) key is card generated and resident. My point was that this attestation key is not personalized to the user and can be provisioned in bulk. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
On Thu, Jan 19, 2012 at 1:10 AM, Anders Rundgren anders.rundg...@telia.comwrote: This is since long solved problem. It is an intrinsic part of GlobalPlatform where you don't really use CSR's and PoP's but a session-key to secure that you are really talking to the card. On http://webpki.org/auth-token-4-the-cloud.html you can find a lot of material on a system that takes this concept to a new level by making the entire provisioning session a transaction. I hope to present it on FOSDEM but I haven't heard from Martin yet... Cool. Intel has a similar process for their (non-GP I think) devices. Even generically, could SM be used for this? (Or is that in fact what you are referring to?) It means the CA, not the user, is interacting with the card, which might even be a good thing. Someone emailed me privately mentioning SM but I told him he was incorrect since the CA wasn't part of the SM session. Maybe that's what he meant. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
On 2012-01-19 10:16, Frank Cusack wrote: On Thu, Jan 19, 2012 at 1:10 AM, Anders Rundgren anders.rundg...@telia.com mailto:anders.rundg...@telia.com wrote: This is since long solved problem. It is an intrinsic part of GlobalPlatform where you don't really use CSR's and PoP's but a session-key to secure that you are really talking to the card. On http://webpki.org/auth-token-4-the-cloud.html you can find a lot of material on a system that takes this concept to a new level by making the entire provisioning session a transaction. I hope to present it on FOSDEM but I haven't heard from Martin yet... Cool. Intel has a similar process for their (non-GP I think) devices. Even generically, could SM be used for this? (Or is that in fact what you are referring to?) It means the CA, not the user, is interacting with the card, which might even be a good thing. Indeed I was referring to SM. The big thing is really how the session key is created. Most cards use static symmetric keys but this is a bad solution; SKS uses a combination of ephemeral ECDH keys and a separate attesting card PKI for this purpose. -- Anders Someone emailed me privately mentioning SM but I told him he was incorrect since the CA wasn't part of the SM session. Maybe that's what he meant. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Always 3F00 is returned after reading (select has no effect)
Hi, I have to test a rather old Bull card with the OpenSC v0.12.2 on Windows, I try to retrieve all the stored files by using SELECT FILE and READ BINARY APDU commands (after performing a successful authentication by using VERIFY). I can easily get the content of the MF (3F00) but I also get the same content for any other file I select and read. Is it possible that the file ID parameter of SELECT FILE can not be evaluated in my case? As you can see below, I select and read the 3F00, 17FF, 2F02 and I always got the same content which is stored in the 3F00 (I checked it with another tool). Any idea? Best regards, Aron --- opensc-tool.exe --atr -v Using reader with a card: OMNIKEY CardMan 3621 0 Connecting to card in reader OMNIKEY CardMan 3621 0... Using card driver Default driver for unknown cards. Card ATR: 3B 67 00 00 29 20 1A 01 78 90 00 ;g..) ..x.. opensc-tool.exe --send-apdu BC:20:00:00:08:XX:XX:XX:XX:XX:XX:XX:XX Received (SW1=0x90, SW2=0x00) opensc-tool.exe --send-apdu BC:A4:00:00:02:3F:00 Received (SW1=0x90, SW2=0x00) opensc-tool.exe --send-apdu BC:B0:00:00:00 Received (SW1=0x90, SW2=0x00): 17 FF 06 E4 0E 10 03 DF 0E 2F FF C4 1F 6C 04 71 ./...l.q 2F 03 00 80 B0 BB FF E4 2F 02 00 80 B0 BB FF E5 /.../... 17 01 14 D4 FF FF FF FF FF FF FF FF FF FF FF FF [...] opensc-tool.exe --send-apdu BC:A4:00:00:02:17:FF Received (SW1=0x90, SW2=0x00) opensc-tool.exe --send-apdu BC:B0:00:00:00 Received (SW1=0x90, SW2=0x00): 17 FF 06 E4 0E 10 03 DF 0E 2F FF C4 1F 6C 04 71 ./...l.q 2F 03 00 80 B0 BB FF E4 2F 02 00 80 B0 BB FF E5 /.../... 17 01 14 D4 FF FF FF FF FF FF FF FF FF FF FF FF [...] opensc-tool.exe --send-apdu BC:A4:00:00:02:2F:02 Received (SW1=0x90, SW2=0x00) opensc-tool.exe --send-apdu BC:B0:00:00:00 Received (SW1=0x90, SW2=0x00): 17 FF 06 E4 0E 10 03 DF 0E 2F FF C4 1F 6C 04 71 ./...l.q 2F 03 00 80 B0 BB FF E4 2F 02 00 80 B0 BB FF E5 /.../... 17 01 14 D4 FF FF FF FF FF FF FF FF FF FF FF FF [...] --- ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Always 3F00 is returned after reading (select has no???effect)
On Thursday, January 19 at 11:46AM, Szabó Áron wrote: Hi, I have to test a rather old Bull card with the OpenSC v0.12.2 on Windows, I try to retrieve all the stored files by using SELECT FILE and READ BINARY APDU commands (after performing a successful authentication by using VERIFY). I can easily get the content of the MF (3F00) but I also get the same content for any other file I select and read. Is it possible that the file ID parameter of SELECT FILE can not be evaluated in my case? As you can see below, I select and read the 3F00, 17FF, 2F02 and I always got the same content which is stored in the 3F00 (I checked it with another tool). Any idea? Best regards, Aron --- opensc-tool.exe --atr -v Using reader with a card: OMNIKEY CardMan 3621 0 Connecting to card in reader OMNIKEY CardMan 3621 0... Using card driver Default driver for unknown cards. Card ATR: 3B 67 00 00 29 20 1A 01 78 90 00 ;g..) ..x.. opensc-tool.exe --send-apdu BC:20:00:00:08:XX:XX:XX:XX:XX:XX:XX:XX Received (SW1=0x90, SW2=0x00) opensc-tool.exe --send-apdu BC:A4:00:00:02:3F:00 Received (SW1=0x90, SW2=0x00) opensc-tool.exe --send-apdu BC:B0:00:00:00 Received (SW1=0x90, SW2=0x00): 17 FF 06 E4 0E 10 03 DF 0E 2F FF C4 1F 6C 04 71 ./...l.q 2F 03 00 80 B0 BB FF E4 2F 02 00 80 B0 BB FF E5 /.../... 17 01 14 D4 FF FF FF FF FF FF FF FF FF FF FF FF [...] opensc-tool.exe --send-apdu BC:A4:00:00:02:17:FF Received (SW1=0x90, SW2=0x00) opensc-tool.exe --send-apdu BC:B0:00:00:00 Received (SW1=0x90, SW2=0x00): 17 FF 06 E4 0E 10 03 DF 0E 2F FF C4 1F 6C 04 71 ./...l.q 2F 03 00 80 B0 BB FF E4 2F 02 00 80 B0 BB FF E5 /.../... 17 01 14 D4 FF FF FF FF FF FF FF FF FF FF FF FF [...] opensc-tool.exe --send-apdu BC:A4:00:00:02:2F:02 Received (SW1=0x90, SW2=0x00) opensc-tool.exe --send-apdu BC:B0:00:00:00 Received (SW1=0x90, SW2=0x00): 17 FF 06 E4 0E 10 03 DF 0E 2F FF C4 1F 6C 04 71 ./...l.q 2F 03 00 80 B0 BB FF E4 2F 02 00 80 B0 BB FF E5 /.../... 17 01 14 D4 FF FF FF FF FF FF FF FF FF FF FF FF [...] --- Your log looks like you are using select and read binary in different sessions. I think when opensc-tool is done it resets the card's state by disconnecting (which on some readers means that the card gets unpowered). I haven't used opensc-tool too much, but I know that opensc-explorer has a commandline to enter multiple APDUs in one session. Cheers, Frank. pgpdXZFTXmEAN.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fosdem 2012, donation of 50 ePass2003 to security devroom
Dear all, Just a quick note that GOOZE will be attending FOSDEM security devroom (day one) and we will donate 50 ePass2003 tokens to the assistance. http://www.gooze.eu/epass-2003 People interested will only need to register an online form during the security devroom and I will hand them free tokens. Hoping this can make the devroom a success. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
