OpenPGP Card implementation

[Peter Lebbing]

Perhaps this is more a discussion for gnupg-devel or even not a gnupg
mailing list at all?

I have a question regarding the current OpenPGP Card for Werner: does it
blind RSA calculations? If not, is there a different firewall against
using power analysis to obtain the secret key?

Benjamin Donnachie wrote:
> Alternatively, this link raises some interesting possibilities -
> http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=6412
> 
> Some people might even like the "retro" feeling that a PIC hanging off
> the end out give! :-)

> ... and so it SOSSE - Simple Operating System for Smartcard
> Education[1]

A 16C84 has 68 bytes RAM, only 1 data register, 0,25 MIPS per MHz and no
hardware multiply instruction. A probably completely impossible basis
for RSA calculations. I was more thinking along the line of the AT Mega
Funcard with an Atmel ATmega161 or -163, with 1 KiB RAM, 32 registers, 1
MIPS per MHz and 8x8 multiply instruction (with 0,5 million
multiplications per second per MHz), or possibly the SuperPIC Zen with
PIC18F452: 1,5 KiB RAM, 1 data register, 1 MIPS per MHz and 8x8 multiply
with 1 million multiplications per second per MHz.

My personal preference goes to the Atmel, just a more pleasant platform
imo; the lower multiplication speed might be compensated by other
factors, or maybe not. Also, the ATmega Funcards are much easier to come
by than the SuperPIC Zen.

The lack of RNG might be a problem: obviously you need randomness for
key generation; but you could choose to omit this feature (and just not
be fully OpenPGP compliant) and still use the card effectively. However,
it greatly improves secret key secrecy when RSA calculations are
blinded, and that requires randomness as well. It might be possible to
obtain reasonable randomness; and if not, a non-blinded RSA card is imho
at least more secure than a private key file with a passphrase: for the
file, access to the computer, be it local or remote, plus the passphrase
is required to learn the secret key. For the card, *physical* access to
the card and the passphrase are required to be able to obtain the secret
key. The nice property that a key cannot be copied from the card is
lost, though, without blinding.

SOSSE is a nice starting ground for development; however, as this is a
security product, I think one should rewrite large parts of it with
constantly keeping security in mind. SOSSE is developed as an
educational platform, not a crypto provider. I think, if you audited
SOSSE code for security, you have more chance of overseeing a weakness
than if you wrote completely new code.

I'm not touching legality with a 40-feet pole, by the way :).

Peter.