On Thu, Jan 19, 2012 at 7:25 PM, Frank Cusack <fr...@linetwo.net> wrote:
> On Thu, Jan 19, 2012 at 2:27 AM, Viktor Tarasov > <viktor.tara...@gmail.com>wrote: > >> >> >> On Thu, Jan 19, 2012 at 9:52 AM, Frank Cusack <fr...@linetwo.net> 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 <fr...@linetwo.net>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
