Menu
▾
▴
Re: [Opensc-devel] Google introduces Web-based smart card
|
From: Alon Bar-L. <alo...@gm...> - 2013-06-14 12:16:49
|
On Fri, Jun 14, 2013 at 12:59 PM, Andreas Schwier (ML) <and...@ca...> wrote: >> The model of RSASecurity "trust us" had failed. > That's why we allow an organization to issue their own device > certificates. This way you can decide if you trust a device certificate > issued by a device issuer (e.g. a card supplier) or only trust your own > device certificates. Who is 'we'? > > You could even operate your own root CA if you like to do so. > >> >> Enrollment can be done only once, and a public key can be assigned to >> single user. Hacked the device and succeeded in import external >> private key then his fault that people can login on his behalf. But >> importing a private key should be forbidden by the device. So I do not >> see any problem. >> >>> >>> The proposed mechanism only ensures that the key is unique and contained >>> in a secure device from which there is no escape. And this assertion is >>> quite important if you want to bind the identity to a device. >>> >>> I agree that there are some parallels with UEFI, but isn't PKI primarily >>> about trusting at least someone along the chain ? >>> >>> To get your RootCA certificate integrated into the browser list, you can >>> either ask the browser vendors to trust your CA or you put the >>> certificate in there on your own. >>> >>> Same for the attestation key of the device. You either rely on someone >>> else who verified the trustwortyness of the device manufacturer or you >>> verify it yourself. >>> >>> Andreas >>> >>> Btw. I don't read that the private key is exposed to anyone. >> >> If it is done outside my reach it can be at some government request to >> be exposed. >> >>> >>> Am 14.06.2013 11:10, schrieb Alon Bar-Lev: >>>> Hi, >>>> >>>> Sorry, I totally disagree... >>>> >>>> Manufacturer should manufacture secure platform that can be used for >>>> various of implementations. It should be accountable for the operation >>>> of the device. The trust within the manufacturer is limited to >>>> providing a device with no backdoors. >>>> >>>> The content, and in this case the private key, should not be exposed >>>> to anyone, including the manufacturer if I to trust the device. >>>> >>>> Establishing manufacturer trust chain will be the same as UEFI, bad >>>> for everyone but who ever hold the key for the CA. >>>> >>>> Had you said that I can somehow generate a public key after I bought >>>> the device and enroll it to some 3rd part to have it trusted, I would >>>> have agreed. But enforcing trust is not something that should be >>>> acceptable. >>>> >>>> Regards, >>>> Alon >>>> >>>> >>>> On Fri, Jun 14, 2013 at 12:03 PM, Andreas Schwier (ML) >>>> <and...@ca...> wrote: >>>>> As the scheme is based on a piece of hardware it makes sense to trust >>>>> the manufacturer to provide a genuine device. >>>>> >>>>> This way you know the key remains safe on the client side and is not >>>>> some software based / man-in-the-middle generated key pair. >>>>> >>>>> It's quite the same what Anders does with the webpki attestation key and >>>>> what we do with the device authentication key in the SmartCard-HSM. >>>>> >>>>> The key questions is how this network of trusted suppliers will be >>>>> build. Who will certify suppliers ? Who operates a root CA that >>>>> certifies suppliers ? Will there be a security evaluation of the devices >>>>> (like CC) ? >>>>> >>>>> Andreas >>>>> >>>>> Am 14.06.2013 10:54, schrieb Alon Bar-Lev: >>>>>> Yes, at first read I thought there is nothing new, we can do this with >>>>>> existing smartcards... >>>>>> >>>>>> But then read: >>>>>> """ >>>>>> Initial Signup: Site sends Javascript call to browser asking for >>>>>> public key for user. Browser finds activated U2F, asks it for public >>>>>> key to remember for user. U2F returns signed public key (signature is >>>>>> by U2F vendor). Site (optionally) verifies public key signature to >>>>>> ensure its an accepted vendor and saves public key + attached blob >>>>>> (encrypted private key). >>>>>> """ >>>>>> >>>>>> So it is a meter of trust, same as PKI... only that you are forced to >>>>>> trust the manufacturer... which is totally wrong. >>>>>> >>>>>> Initially I thought that each registration will create its own key >>>>>> pair... which could have been nice if the device has enough memory. >>>>>> Even single key pair is OK if you would like to share it between >>>>>> services. >>>>>> >>>>>> Regards, >>>>>> Alon >>>>>> >>>>>> On Fri, Jun 14, 2013 at 11:41 AM, helpcrypto helpcrypto >>>>>> <hel...@gm...> wrote: >>>>>>> I love the big brother. >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 11, 2013 at 6:59 PM, Anders Rundgren <and...@te...> wrote: >>>>>>>> https://sites.google.com/site/oauthgoog/gnubby >>>>>>>> >>>>>>>> I think it is actually good that I finally have a competitor! >>>>>>>> >>>>>>>> Smart Card middleware will be a thing of the past. Hooray! >>>>>>>> >>>>>>>> Anders >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> This SF.net email is sponsored by Windows: >>>>>>>> >>>>>>>> Build for Windows Store. >>>>>>>> >>>>>>>> http://p.sf.net/sfu/windows-dev2dev >>>>>>>> _______________________________________________ >>>>>>>> Opensc-devel mailing list >>>>>>>> Ope...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> This SF.net email is sponsored by Windows: >>>>>>> >>>>>>> Build for Windows Store. >>>>>>> >>>>>>> http://p.sf.net/sfu/windows-dev2dev >>>>>>> _______________________________________________ >>>>>>> Opensc-devel mailing list >>>>>>> Ope...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> This SF.net email is sponsored by Windows: >>>>>> >>>>>> Build for Windows Store. >>>>>> >>>>>> http://p.sf.net/sfu/windows-dev2dev >>>>>> _______________________________________________ >>>>>> Opensc-devel mailing list >>>>>> Ope...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>>>> >>>>> >>>>> -- >>>>> >>>>> --------- CardContact Software & System Consulting >>>>> |.##> <##.| Andreas Schwier >>>>> |# #| Schülerweg 38 >>>>> |# #| 32429 Minden, Germany >>>>> |'##> <##'| Phone +49 571 56149 >>>>> --------- http://www.cardcontact.de >>>>> http://www.tscons.de >>>>> http://www.openscdp.org >>>>> >>>>> >>>>> -- >>>>> >>>>> --------- CardContact Software & System Consulting >>>>> |.##> <##.| Andreas Schwier >>>>> |# #| Schülerweg 38 >>>>> |# #| 32429 Minden, Germany >>>>> |'##> <##'| Phone +49 571 56149 >>>>> --------- http://www.cardcontact.de >>>>> http://www.tscons.de >>>>> http://www.openscdp.org >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF.net email is sponsored by Windows: >>>>> >>>>> Build for Windows Store. >>>>> >>>>> http://p.sf.net/sfu/windows-dev2dev >>>>> _______________________________________________ >>>>> Opensc-devel mailing list >>>>> Ope...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >>> >>> -- >>> >>> --------- CardContact Software & System Consulting >>> |.##> <##.| Andreas Schwier >>> |# #| Schülerweg 38 >>> |# #| 32429 Minden, Germany >>> |'##> <##'| Phone +49 571 56149 >>> --------- http://www.cardcontact.de >>> http://www.tscons.de >>> http://www.openscdp.org >>> > > > -- > > --------- CardContact Software & System Consulting > |.##> <##.| Andreas Schwier > |# #| Schülerweg 38 > |# #| 32429 Minden, Germany > |'##> <##'| Phone +49 571 56149 > --------- http://www.cardcontact.de > http://www.tscons.de > http://www.openscdp.org > |
