[Gnuk-users] Storing Certification Key on Gnuk?

[NdK]

Il 17/02/2015 02:27, NIIBE Yutaka ha scritto:

>> Could way maybe somehow work around this by extending it?
> Certainly, extending the specification is possible and we can enhance
> scdaemon of GnuPG, and the gpg frontend, accordingly.
Not strictly necessary, *if* you can stand some limitations. That's what
I thought for selecting extra ENC keys in MyPGPid: a non-standard APDU
that switches the key to an alternate one. That could easily be extended
to include different keys.

> But, with my limited knowledge (and access to documents), I don't know
> exactly how we can extend the specification without breaking standards
> in the industry.  I think that OpenPGPcard specification is designed
> to comform those standards.
As long as you don't change the documented commands, you can add others.

> I think that the update of OpenPGPcard specification (for forthcoming
> version 3) is not so far, since people want ECC much nowadays.  That
> will be a good opportunity to discuss the specification.  Please stay
> tuned on gnupg-devel.
That's probably the place where extra commands should be discussed to
avoid future incompatibilities.

>> We have a physical hardware limit of 20KiB RAM of STM32F103, and I
>> think that it's the main factor for Gnuk.  When all three keys are
>> loaded into RAM, memory pressure is high.
What would be the overhead of keeping in RAM just the S2K result and
decoding the needed key on the fly? Maybe using full-size s2k-count and
keeping keys on the currently unused EEPROM? If you think that that
would expose firmware-replacement as an attack vector, a simple
user-auth-key (that have to be supplied once by the user after every
firmware update) should do the trick.

> For decryption private key and authentication private key, it remains
> on RAM, after PIN authentication.
> 
> I think that something like this is required for any OpenPGPcard
> implementations.  Either keeping PIN (or its hash) to decrypt
> encrypted private key, or keeping raw private key.  That's because
> smartcard/token should be ready to compute signature or to decrypt
> message after PIN authentication.
Well, decrypting the needed key on the fly could greatly help in
reducing pressure on RAM, especially in the case of big RSA keys. The
decoding overhead should be negligible given the time required for RSA
ops anyway.

BYtE,
 Diego