Whishlist for next-gen card

[Peter Lebbing]

On 20/02/15 09:32, NdK wrote:
> 1 - support for more keys (expired ENC keys, multiple signature keys)

Yes! This would be a great feature to keep expired encryption keys on a card. I
personally would have no use for more than 1 signature and 1 authentication key,
but I don't see a reason why you wouldn't just have a whole bunch of generic key
slots and only indicate its intended usage on creation/upload so people can do
that as well.[1]

If ECC were supported by the card, you'd need quite a lot less storage to keep
all these keys.

> 2 - different PINs for different keys

This would partly amount to resurrecting an old feature. IIRC, there were 2 user
PINs in the v1.1 spec, but the v2 spec pretty much retired the second PIN. Don't
take my word for it, though, check the spec.

I suppose it makes sense. Especially when combined with 2 signature keys: one
could be your primary key, and the other your subkey. You would still keep them
on the same card, but would be more careful about entering the PIN that belongs
to your primary key.

However, I think the primary key/subkey feature is already covered pretty well
by simply having two smartcards (it's what I do).

> 3 - separate key for NFC auth (with its own optional PIN)

Sounds like an interesting concept. I don't know how much work it would be to
have the ISO 7816 parts needed by the OpenPGP card really working for NFC. Do
you just exchange the lower few communication layers (physical, data, ...) and
is everything above the same for the subset of ISO 7816 you need? I haven't
looked at NFC yet.

What I'm hinting at: NFC and cards with contacts are different enough that it
might warrant handling NFC separately from the rest and hence doesn't need to be
"integrated into" the process for determining the next cards-with-contacts
standard and implementation.

But NFC authentication through asymmetric crypto sounds interesting.

> 4 - HOTP PINs for signature/certification keys

What generates the HOTP then? Do you type a PIN on the HOTP device to get the HOTP?

What I'm guessing you might mean, is that the HOTP device might be more trusted
than the pinpad of the card reader: the card reader is connected to the PC. The
HOTP device is simply a standalone device; is air-gapped. So even if the PC is
compromised, it will not be able to learn your PIN, which you entered on the
HOTP device.

Is this what you're getting at?

I don't really see the use. Smartcards protect extraction of the private key;
they're not equipped to prevent usage of the key material through a compromised
PC. So what they can't learn your PIN; they'll just get you to enter it for
them. I don' see this adding something beyond your point 6, which I'll treat there.

> 5 - possibility to export private keys to user-certified devices

I'm not terribly interested in that. Firstly, you would still need a backup of
the key the data is encrypted to; the chain has to start somewhere. Secondly,
provided you can have a trusted system for the generation of the keys, you could
simply generate them on that trusted system, encrypt them to the key you wish to
encrypt it to, and then store the encrypted data as you see fit.

On-card generation is putting a lot of trust in the on-card RNG as well; I put
more trust in Linux's PRNG on a trusted system. As long as you're generating the
keys on a PC anyway, you might as well handle all the backup thingies there.

> 6 - support for out-of-band authorization (HW)

This and 7 have been discussed in this[2] thread as well; just as a reference. I
think it serves a useful canary role, in that as long as I only press the button
once for each decryption/signature, I'm fairly sure that it's doing the
decryption or signature that I want. As soon as stuff starts to exhibit hickups,
I can at least account for the fact that perhaps it's not hardware failing but
someone playing me. Robert J Hansen clearly strongly disagrees with me on that
subject, as evidenced in the thread I indicated.

It's not watertight. Neither is a canary. I see it as defence in depth. But it
is clearly a contested subject. And I've never seen any indication that Werner
believes in this solution; I get the feeling he doesn't. I suppose he's the main
influence on what goes in the card specification and what doesn't.

> 7 - support for more informative signing (requires a small display: HW)

See below for my view.

> 3 to 6 should be under a "policy" object connected to the main key to
> make it public and let relying parties evaluate how much trust to give.

This seems to preclude ever allowing the user access to their own private key
material; otherwise you're moving your trust back again from the smartcard
attesting this policy to the user attesting this policy, since they can do what
they want, whatevah! I don't think we should limit the user in handling their
own keys; it reeks like DRM to me. But if you don't limit the user, there's no
reason to have the smartcard attest to any attributes, since the card can't
guard them anyway. Just leave the policy to the user.

> 2 - If I have to use my card to login on a possibly untrusted computer

Hmmm. I would definitely use a different card for this, regardless of all the
cool protections on the card. Say I have a card with my work identity, and one
with my private identity. I wouldn't ever stick the private identity in a work
PC, even if the keys were protected by a different PIN. It only seems to serve
the purpose of having one piece of plastic less in your wallet; but I already
need a separate card wallet because of all the cards I have, one more isn't
going to matter.

> 4 - since HOTP changes at every use, it makes keyloggers nearly useless
> and gives a third factor to the auth process (might be combined by
> simple means -like digit-by-digit addition modulo 10- to the PIN)

Third factor IMHO implies a different *kind* of factor. You already have
possession (the OpenPGP card) and knowledge (the PIN). What's your third factor;
biometrics?

To bend the terms to breaking point: I currently employ 9-factor authentication.
I have the OpenPGP card, and I know 8 PIN digits. This is a useless definition;
I think "factor" only makes sense as a *kind* of authentication.

Still, this is just about terminology; my substantial answer is above.

> 7 - malaware currently can replace the hash of the object being signed
> and the user can't know it till it's late... a small display could be
> used to report some metadata (file name type and size for signature,
> keyID and owner data for certification, peer ID for auth...) to give the
> user more feedback

Malware can replace the hash of the object being signed... and still display the
correct file name type and size, etcetera, everything you mention. So I'm not
sure what you're getting at. You need to present data that is actually *signed*
for this to be useful in any way. It might be that SSH authentication does
include a "peer ID" in its challenge; I haven't checked. But that is all.

What is signed[3] is a hash computed over the data and a few OpenPGP
(sub)packets. People can't compute hashes. So you need a computer to do it. If
there's a computer you trust to do this for you, just sign the data there
already. I only see this work with trust in numbers: compute the hash on many
computers, and if they all agree, they're probably not all hacked. I say I see
this work, but I don't, really: I don't believe in this mechanism. And it's a
tremendous amount of work for the user for one single signature.

[... half a proofread of this mail later ...]

Oh ouch. I suddenly realise something about the canary press-to-decrypt button
(point 6). I've thought of a nasty attack. Maybe it's not such a great canary
for decryption keys...

So I access mail A, which is encrypted, and my PC is compromised. The malware
listens in, and, crucially, secretly saves the session key for mail A! A few
days later, I again access mail A. Now, I expect to be prompted for my PIN:
that's how it normally works when I access an encrypted mail. However, the
malware arranges that a document it is interested in is decrypted instead. And
since it has saved the session key for mail A, it still presents to me mail A as
expected. Now I haven't pressed the button any more than I expect to do, but
still it decrypts other data than I expect it to. I've just helped the malware
access my encrypted documents, and I'm totally unaware.

Detecting false signatures is already more complicated.

Now I'm really starting to have doubts about the canary button.

My 2 cents,

Peter.

[1] It would probably be reasonable to not be able to change its usage. If you
really want to do that, you could also upload the key again, proving you already
have the secret material. If your point 5 were to be implemented, the usage
indicator could be combined with that.

[2] http://lists.gnupg.org/pipermail/gnupg-users/2013-February/045994.html

[3] Forgetting about authentication for a moment; as I said, the "peer ID" might
actually work for authentication.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>