Re: [opensc-devel] proving a key is on a smart card
Hi Frank, you are right with the German identity card, however our approach is different: Our card (which is no nPA) stores the key required for terminal authentication, not for chip authentication. The key for terminal authentication must be certified by a DVCA, which in turn is certified by a national CVCA. So the challenge is to prove, that the key pair for terminal authentication was actually generated at the secure token in the terminal. We are just reusing the established authenticated CSR format from TR-03110 and build that into the card. The key for signing the authenticated request can only be used for this specific purpose - this is enforced internally in the card. There is no secure messaging involved, because we only need to provide integrity and authenticity of the CSR. The scheme has no need for confidentiality, as all information is public anyway (CSR and certificate written to the card). Andreas Am 20.01.2012 11:49, schrieb Frank Morgner: > Hi! > >>> I don't think that's enough? It doesn't matter if the card trusts the CA, >>> it's that the CA has to trust the card. >> Difficult to do more with the common cards. > As Andreas said, the German identity card (nPA) has this functionality > (BSI TR-03110). A whole bunch of technical guidelines (TRs) describe > every entity and process needed. Services that use the ID card for > online authentication and identification are already available. > > What Andreas did not mention is that a card's key is actually shared > among multiple cards for privacy reasons. This makes revocation a bit > difficult. So for the nPA we will soon see chip individual keys and/or > group signature schemes. > > Cheers, Frank. > > > ___ > 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
Hi! > > I don't think that's enough? It doesn't matter if the card trusts the CA, > > it's that the CA has to trust the card. > Difficult to do more with the common cards. As Andreas said, the German identity card (nPA) has this functionality (BSI TR-03110). A whole bunch of technical guidelines (TRs) describe every entity and process needed. Services that use the ID card for online authentication and identification are already available. What Andreas did not mention is that a card's key is actually shared among multiple cards for privacy reasons. This makes revocation a bit difficult. So for the nPA we will soon see chip individual keys and/or group signature schemes. Cheers, Frank. pgpTxT2N9kdXh.pgp Description: PGP signature ___ 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)
Yes, you are right: each opensc-tool.exe call sets a resets the session, so I have to send multiple APDUs in one command line call! Now, it works fine! Thx!!! BR, Aron -Original Message- From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Frank Morgner Sent: Thursday, January 19, 2012 2:55 PM To: opensc-devel@lists.opensc-project.org Subject: 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. ___ 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
TPMs already have an EK (Endorsement Key) on the chip. However, the TPM guys didn't look into SM (Secure Messaging) so at least the current version (1.2) is quite crippled. Microsoft intends making TPM 2.0 a standard feature in W8 "pads". Their take on secure silicon is making it a part of the CPU itself: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T -- anders ___ 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 7:25 PM, Frank Cusack wrote: > On Thu, Jan 19, 2012 at 2:27 AM, Viktor Tarasov > wrote: > >> >> >> On Thu, Jan 19, 2012 at 9:52 AM, Frank Cusack wrote: >> >>> On Wed, Jan 18, 2012 at 11:57 PM, Viktor Tarasov < >>> viktor.tara...@gmail.com> wrote: >>> On Thu, Jan 19, 2012 at 8:30 AM, 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. > If the generate/import key operations are protected by secure-messaging, then the 'ticket' will be included into the successful APDU's response. This 'ticket' can be checked by caller to be sure that key was really injected/generated by card. >>> >>> You're missing the point. Of course the caller can know if the key was >>> really generated on card, but the CA cannot know that. >>> >>> >> Secure messaging can be established in asymmetric mode, using the CA >> certificate trusted by card. >> > > I don't think that's enough? It doesn't matter if the card trusts the CA, > it's that the CA has to trust the card. > Difficult to do more with the common cards. Possible solution could be organisational : - OpCA dedicated only for mutual authentication between the cards and enrollment/other entities; - OpCA certificate is not widely published and is only known by the upper actors. (like symmetric keys for symmetric SM.) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
