[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [FORGED] [pkcs11] Updated CKA_PUBLIC_KEY_INFO
We're still talking past each other a bit. Let me try again. On 5/13/2013 12:25 AM, Peter Gutmann wrote:
Sorry - I assumed it was understood that the hardware (or rather the firmware on the hardware) would have to be updated to provide the data for the CKA_PUBLIC_KEY_INFO object. The actual formatting of such data into a DER blob could either be done on the token side or completed on the driver side. Any token that can generate key pairs has sufficient library routines to regen the public key from the private data.Michael StJohns <msj@nthpermutation.com> writes:For DSA and EC keys, the public key can be derived from the private key info. For example, the public key for an EC private key is Pub = priv * G where G is the generator point on the curve and "priv" is the scalar that makes up the EC private key. This is a multiplication on the curve. Given that the curve info (including G) is part of the required info for an EC private key in PKCS11, you can always derive the public key from a private key.This works OK in a software-only implementation where you've got access to both the key components and a set of bignum maths routines, but how is it supposed to work for hardware?
What I meant to convey from the above is that the underlying representation of the data for each type of private key EXCEPT RSA had enough information to regenerate the public key. With RSA, what was missing was the public exponent, so that needed to be added. As a nice side effect, simply adding that data makes the RSA public key accessible from PKCS11 from the private key thanks to both the modulus and public exponent being public data.
In software it's easy enough to calculate y = g^x mod p (for DLP) or Q = d * G (for ECDLP), but if your x or d are locked up in hardware (which I assume they are) then your token will need to perform the operations, you can't do them in your driver and you definitely shouldn't be asking the user to do them in their application (which they can't anyway, since they can't get at x/d).
Yup.
Heh. And some token developers would like it just the opposite. When it gets to the point, I'll cast a vote for MUST though.Again - this was a compromise based on a push back. I'm perfectly happy to make this a MUST, but there was sufficient FUD being tossed about that I just punted. I agree with you, but I wasn't willing to force all products to comply.As an application developer I would rather have it a MUST and some vendors can choose to be non-compliant, rather than have it a MAY and have to guess at which vendors do it, add kludges if possible, and otherwise just tell users "you can't use tokens from this vendor". If the vendor doesn't implement the MUST then it makes it obvious that you can't use their tokens, with a MAY you have to experiment around with every token to see what it does and how it reacts to attempts to get the public components.
It may be the case that this is an absolute MUST for a FIPS 140-2 profile compliant token.
If we're close enough on the current draft, I'll go through it and extract the MUST/MAY/SHOULD points for argument and vote.
Peter.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]