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. > > Pushing the ECDH Key Agreement to the token for use by the token > looks very interesting. 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. 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. 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 >>>> >>>> >>> >> >> > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
