From: Alon Bar-L. <alo...@gm...> - 2013-06-14 09:37:02
|
On Fri, Jun 14, 2013 at 12:31 PM, Andreas Schwier (ML) <and...@ca...> wrote: > O.K. so how do you as a private person register your key with a 3rd > party ? And why should that third party trust your keys to be unique > (and not spread across the Facebook community) ? I am more concerned of how it is used/trusted internally in organizations. The model of RSASecurity "trust us" had failed. 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 > |