scd: change_keyattr_from_string for ECC.

Achim Pietig achim at pietig.com
Tue Jul 21 08:37:09 CEST 2015


Hi,

answers in the text.

Regards
Achim

Am 21.07.2015 um 01:23 schrieb NIIBE Yutaka:
> On 07/20/2015 11:25 PM, Werner Koch wrote:
>> Why not use
>>
>>   SCD SETATTR KEY-ATTR --force 3 1 rsa2048
>>
>> and handle card specific details in app-openpgp.c ?
> 
> Yes, I'd like to support that.  And, I'm wondering HOW we can
> implement that.
> 
> When SCDaemon composes the data to be sent, it's like:
> 
>     01 08 00 00 20 00
> 
>     where
> 
>     01: RSA
>     08 00: 2048-bit modulus size (of n)
>     00 20: 32-bit exponent size  (of e)
>     00: private key format from host to card is (e, p, q)
> 
> OpenPGPcard allows four formats for RSA key (to be stored into the
> card);
> 
>     00: e, p, q
>     01: e, p, q, n
>     02: e, p, q, dp, dq
>     03: e, p, q, dp, dq, n
>
My cards <= V2 do not allow to change the private key format byte and algo-ID, because it is hardware specific. You can change only byte 2-7.
Cards >= V3 allow changing byte one (algo-ID) and dependent from that changing byte 2-7 (RSA) or OID (ECC).
Other values are rejected.
Plain ISO cards that do not support parsing of data in PUT DATA may have a different behaviour - in most caeses they will not support this in general.

> When the key attribute is for RSA, and being asked (by a user) to
> change the size of RSA key, SCDaemon only change the size of public
> key in the key attribute data object (by reading out the data object,
> then writing the changed value).  That is, SCDaemon does not change
> the format specifier of the key attribute.
>
That is OK for all card <= V2.

> When the key attribute is for ECC, and being asked to change it back
> to RSA, SCDaemon doesn't have an idea what format the card supports.
>
That is a problem because there is no feature list available - Extended Capabilites show only values needed for runtime.
Can be solved only by special tools from the card developers.

> So, I wonder: SCDaemon to
> 
>     (1) try all those four possibilities
>     (2) have a card specific information which card/version support what
>     (3) assume that (in future) the card has flag to specify which format
>     (4) assume that
>           the card ignore the format specifier by SCDaemon
>     (5) not specify the format specifier and let the card decide it
>           but... sending only 5-byte (01 08 00 00 20) for PUT DATA is OK?
> 
> If (5) doesn't violate ISO 7816, this sounds good.
>
A featue list (all missing possibilities of the card) can be added, because there is only few usage I did not mention it up to now.
In PUT DATA the whole DO has to be sent, partial data are not possible.
A card may check the values (my do) and reject incompatible input - but there may be implementations that do not pasrse and allow all values.
In that case the card will not run properly after the changes.



More information about the Gnupg-devel mailing list