ECC and smartcards

[NIIBE Yutaka]

In February, we talked supporting ECC for OpenPGP card.

Since then, I did some part of ECDSA in GnuPG 2.1.x.  I tested it with
Gnuk development version for authentication.

This time, I'd like to talk (and will implement) ECDH part.

Currently, "7.2.9 PSO: DECIPHER" in the OpenPGP card specification
v2.0, decryption is defined as:

    Command:
    CLA           00 / 10
    INS           2A
    P1            80 = Return plain value
    P2            86 = Enciphered data present in the data field
    Lc            xx = Length of subsequent data field
    Data field    Padding indicator byte (00) followed by cryptogram
    Le            00

    Response:
    Data field    Plain data
    SW1-SW2       9000 or specific status bytes

For ECDH, how about the following?

    Command:
    Data field    Ephemeral public key in format: 04 || X || Y

    Response:
    Data field    Shared secret: x coordinate only

In the terms of RFC6637, host sends the ephemeral public key V (point
on the curve) to card, then, asks card to compute shared secret S = rV
where r is the private key (scalar), then, card responds by x
coordinate of the point S.  KDF and AESKeyUnwrap computation is done
on host.

Considering this command/response interaction, I have two references.

One is NIST SP 800-73-3, Interfaces for Personal Identity Verification
Part 2, section A.4.2 Elliptic Curve Cryptography Diffie-Hellman.
It's definition of command data field is:

    '7C' - L1 {'82' '00' '85' L2 {'04' || X || Y}}

Response data field is:

    '7C' - L1 {'82' L2 {shared secret Z}}
     Z is the X coordinate of point P as defined in SP 800-56A

Another is SmartCard-HSM by cardomatic.  I don't have its
specification at hand, but OpenSC has its support in
src/libopensc/card-sc-hsm.c.  It's response data field seems:

    '04' || X || Y

in the function sc_hsm_decipher.

			*	*	*

On 2013-02-18 at 14:01 +0900, NIIBE Yutaka wrote:
> In Japan, ECDH means C(2, 0, ECC CDH) by CRYPTREC.
> 
>     http://www.cryptrec.go.jp/english/method.html
> 
> Update of this specification is scheduled this year.

It was updated, but nothing has been changed for ECDH.  C(2, 0) means
two ephemeral keys model, which is irrelevant for message encryption
of S/MIME or OpenPGP (which use static key).  This means that there is
no reference in Japan for ECDH standard for message encryption with
static key, unfortunately.
--