OpenPGP card specification enhancement for ECDSA support

[Achim Pietig]

Hi,

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 [3]. 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 defined 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,
Achim



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:
>> Hello,
>>
>> 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) 4.3.3.6 Algorithm Attributes
>>
>> ECDSA:
>>
>> 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.
>>
> 
>