On 2012-02-21 18:16, Douglas E. Engert wrote: > <snip> >>> 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.
You are right. My scheme does indeed store a ECDH Z-result in the token. However, this is a token management/provisioning key, rather than a "user key". For user-keys I currently have no ambitions beyond what PIV supports. I have "played" with the idea of creating a "secure stack-machine" for performing arbitrary cryptographic operations on result-data but I couldn't figure out how this would work without introducing vulnerabilities. :-( Anders > >> >> 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
