On 2/21/2012 6:01 AM, Anders Rundgren wrote: > On 2012-02-20 23:22, Douglas E. Engert wrote: >> >> >> On 2/20/2012 3:41 PM, Anders Rundgren wrote: >>> On 2012-02-20 21:40, Peter Stuge wrote: >>>> Anders Rundgren wrote: >>>>> I don't know what USB P11 is, can you send me a pointer? >>>> >>>> It's my old idea of implementing PKCS#11 directly over USB. Issues >>>> have been pointed out, and they would have to be solved of course. >>> >>> Maybe you would like to have an STM32F215-based token? >>> 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES >>> It may happen this year. >>> >>> Anders >> >> I have not tried this, but check out this token too: >> >> http://www.goldkey.com/usb-smart-card-with-piv.html >> >> Built-in PIV Support >> Basic functionality and support for PIV cards and tokens already >> exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions. >> >> It does not say what what the Linux support is, but I bet it is OpenSC. > > Douglas, > I believe you have misunderstood my intentions. The idea with my > project is not finding a suitable PIV token but creating a new standard > for cryptographic modules. However, I may have to hijack some of PIV > stack in order to not get swamped by contra-productive middleware > development.
OK. Note the PIV standards really define an application, and it could be extended or an additional application on the card could be used to do what you propose. > > My FOSDEM 2012 presentation: > http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf The current PIV ECDH operations only return the ECDH keying material, and do not save it on the token. This is what the ECDH mods I want to get into OpenSC are all about. The mods return the raw keying material as a PKCS#11 symmetric key Session Object to the caller who could then use this with software based ECDH Key Agreement. Pushing the ECDH Key Agreement to the token for use by the token looks very interesting. > > Anders > >> >> >> >>> >>>> >>>> >>>>> Although PKCS #11 is good it is not particularly popular on Windows. >>>>> It is essentially only Mozilla who insists on not supporting the >>>>> native Windows crypto system. SUN/Oracle have managed to do 3(!) >>>>> major Java releases (5,6,7) without PKCS #11 support for Win-64. >>>>> They have though added support for Crypto-API. >>>> >>>> The same USB device could support Crypto-API primitives too. >>>> >>>> >>>>> Regarding my token-project it has no direct ties to PKCS #11; it is >>>>> closer to the NXP GP-chip which is powering Google's Wallet. >>>>> >>>>> The reason for this is that PKCS #11 doesn't have a interface >>>>> supporting secure remote provisioning, something which absolutely >>>>> necessary in the mobile phone world. >>>> >>>> Provisioning is indeed outside PKCS#11 and could be done in some >>>> other, also convenient, way. USB is really easy to use. >>>> >>>> >>>>> I have stretched this notion to include connected tokens as well >>>>> with a hope reaching the critical mass needed for establishing a >>>>> de-facto standard. >>>> >>>> I fear that you are ahead of your time. :\ Adam Dunkels implemented >>>> the internet of things many years ago, but I don't even have IPv6. >>>> Things are changing, but still slowly. >>>> >>>> >>>>>>> it seems that NIST's PIV would be good choice >>>>>> >>>>>> It would be a much better candidate if there was not such a thick >>>>>> layer of components involved which serve little to no purpose. >>>>> >>>>> If you talk about the actual card standard I have no idea what >>>>> you are referring to. It looks quite simple to me. If you OTOH >>>>> refer to the OpenSC implementation, this is something that PIV >>>>> isn't responsible for. >>>> >>>> Actually neither, I refer to the entire stack of software required >>>> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >>>> >>>> >>>>> Anyway, I know that the PIV vendors verify their cards against >>>>> Microsoft's driver and that is IMO the way to go. >>>> >>>> If there's a superior alternative Microsoft may well catch up at some >>>> point. They did with USB. >>>> >>>> >>>>>> But it would be nice to try to do even better. :) >>>>> >>>>> That is what my project is all about but that is hardly an >>>>> alternative for Feitian at this stage. >>>> >>>> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >>>> they do that's perfectly fine and totally awesome, but I'm keeping >>>> the idea alive only because *I* think it is good and would like to >>>> try it out. >>>> >>>> >>>> //Peter >>>> _______________________________________________ >>>> opensc-devel mailing list >>>> opensc-devel@lists.opensc-project.org >>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>> >>> >>> _______________________________________________ >>> opensc-devel mailing list >>> opensc-devel@lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >>> >> > > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
