On 2/21/2012 9:53 AM, Anders Rundgren wrote: > On 2012-02-21 16:17, Douglas E. Engert wrote: >> >> >> 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. > > That's correct and may very well be what I end-up with :-) > >> >>> >>> 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.
The above allows for example Thunderbird to use ECDH for encrypted email, with most if the work done in software, as the derived key is not stored on the token. >> >> Pushing the ECDH Key Agreement to the token for use by the token >> looks very interesting. > I meant based on your slides it looks like that is what you would like to do as a new operation. > I'm not sure I understand what you are trying to do here. The PIV > specification doesn't (AFAIK...) allow you to store the result of an > operation on the card. Correct. > I could imagine that "super-operations" like > > HMACSHA256 (ID-to-ECDH-priv-key-on-token, > Other-party's-ECDH pubkey, > KDF-Algorithm, > KDF-Data, > "Argument Data") > > could be interesting but that looks like a new token method to me. Based on you slides, this sounds like a version of NIST 800-56A Section 6.1.1.2. with all the operations done on the token, and the key (Z) stored on the token for use by other operations. > > Anders > > > >> >> >>> >>> 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
