OpenPGP card specification enhancement for ECDSA support
openpgp at brainhub.org
Sun Mar 3 05:41:20 CET 2013
Hello Achim. If you are you implementing the key generation on the card,
please consider generating "compliant" keys. There are the keys that
allow efficient compression. If you cannot use compression in some part
of communication, that's up to you. However, this will allow efficient
representation of any such a key in a compressed form (for anybody for
whom it's an option). As proven in the spec, no security is lost by
On 03/02/2013 05:30 AM, Achim Pietig wrote:
> actual all relevant ECDSA standards follow the BSI specification "Technical Guideline TR-03110-1 - Advanced Security Mechanisms for Machine Readable Travel Documents".
> In addition BSI launched "Technical Guideline TR-03111 - Elliptic Curve Cryptography" as basis for codings etc.
> The following standards/inplementations aggreed to follow:
> EN 14890: Application Interface for smart cards used as Secure Signature Creation Devices
> CEN 15480: Identification card systems - European Citizen Card
> German Electronic Health Card (eGK) Gen2
> ISO 7816-8 in the next version (in progress, I'm member of the national body of the standardisation committee and will get information early).
> All relevant ECDSA implementation on smart cards will follow this in the nearest future, so the OpenPGP card should do also.
> BSI defines the following for PubKeys:
> The conversion of Elliptic Curve Points to octet strings is specified in . The uncompressed format SHALL be used.
> The data objects contained in an EC public key are shown in Table 27. The order of the data objects is fixed, CONDITIONAL domain parameters MUST be either all present, except the cofactor, or all
> absent as follows:
> Data Object Abbrev. Tag Type Certificate
> Object Identifier 0x06 Object Identifier m (mandatory)
> Prime modulus p 0x81 Unsigned Integer c (conditional)
> First coefficient a 0x82 Unsigned Integer c
> Second coefficient b 0x83 Unsigned Integer c
> Base point G 0x84 Elliptic Curve Point c
> Order of the base point r 0x85 Unsigned Integer c
> Public point Y 0x86 Elliptic Curve Point m
> Cofactor f 0x87 Unsigned Integer c
> German eGK (e. g.) uses Tag 06 and 86 only, I prefere this for the Open PGP card also.
> The coding of Tag 86 is as follows:
> In uncompressed encoding the point P is represented by two eld elements, its x-coordinate denoted by xP and its y-coordinate denoted by yP.
> If b is the bit length of p, storing (xP ; yP ) requires 2b bits (excluding additional data required for the encoding).
> The uncompressed encoding PU is defined as PU = C || X || Y , where
> C = 0x04
> X = FE2OS(xP )
> Y = FE2OS(yP )
> All this relates to Niibes proposal and I see no way to change it, if the card will be in compliance with standards.
> The response of GENERATE ASYMMETRIC KEY PAIR will be:
> 7F49 xx
> 06 xx OID
> 86 xx Elliptic Curve Point
> For key import we have to check if this information is enough or if we should use additional parameters (see conditional information in BSI table).
> Best regards,
> Am 01.03.2013 20:02, schrieb Andrey Jivsov:
>> Hi NIIBE.
>> Please consider using the compact representation of an ECC point: http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card.
>> I plan to submit a relevant proposal to use the compact representation in OpenPGP.
>> The benefit of the compact representation is that you will have to transmit less than half of bytes of the point over in the host-to-card protocol.
>> For this compact representation of the ECC point to work one needs to slightly adjust the key generation. It's always possible to do so with the proposed method, even with any existing method that
>> generates keys on the card (one uses "black box" approach in this case).
>> The ideal scenario is when the key generation is already generating compliant keys. Thus, I suggest to change the key generation on the card to always return the compliant keys.
>> IMO we should all generate compliant OpenPGP keys in the entire OpenPGP ecosystem (and beyond as well, as keys are sometimes migrated between PKI and OpenPGP). Well, at least compliant keys are within
>> our reach at OpenPGP.
>> ( I will say that it's unfortunate that RFC 6637 was specified to use SEC format 04 | x | y. The reason is that at the time I didn't know about all the benefits that a *single* format such as
>> http://tools.ietf.org/html/draft-jivsov-ecc-compact would bring. I plan to remedy this with another draft. So, it's a heads up. Please consider not using the SEC format. )
>> Thank you.
>> On 02/28/2013 10:22 PM, NIIBE Yutaka wrote:
>>> This message is CC-ed to GnuPG-Devel List.
>>> I am currently extending GnuPG so that it will support OpenPGP card
>>> with ECDSA feature in future.
>>> So far, following two things are modifications to the current OpenPGP
>>> card specification.
>>> Could you please give me comments?
>>> (1) 126.96.36.199 Algorithm Attributes
>>> Byte Length Value
>>> 01 01 Algorithm ID (RFC6637) 13 = ECDSA
>>> 02- Variable OID (RFC6637)
>>> 2A 86 48 CE 3D 03 01 07 NIST curve P-256
>>> 2B 81 04 00 22 NIST curve P-384
>>> 2B 81 04 00 23 NIST curve P-521
>>> I think that use of OID here would be best, since OID is used to
>>> identify the curve in OpenPGP ECC (RFC 6637).
>>> (2) 7.2.11 GENERATE ASYMMETRIC KEY PAIR
>>> Set of public key data objects for ECDSA
>>> 81 xx Public key
>>> In the format of uncompressed point:
>>> 04 || x || y
>>> where x and y are coordinate of the point P = (x, y).
>>> Big-endian, zero-padded.
>>> (c.f. Section 6. Conversion Primitives in RFC 6637)
>>> I think that curve specification (For example, Generator, Order, etc.)
>>> is defined by OID in the Algorithm Attributes, it's enough to return
>>> the public key, EC point, and it's natural to use standard encoding
>>> of uncompressed point.
More information about the Gnupg-devel