Menu
▾
▴
Re: [Opensc-devel] Google introduces Web-based smart card
|
From: Andreas S. (ML) <and...@ca...> - 2013-06-14 09:59:43
|
> 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. 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 |
