Whishlist for next-gen card

NdK ndk.clanbo at gmail.com
Fri Feb 20 09:32:45 CET 2015


Hello all.

What I'd like to see addressed in future card specifications:
1 - support for more keys (expired ENC keys, multiple signature keys)
2 - different PINs for different keys
3 - separate key for NFC auth (with its own optional PIN)
4 - HOTP PINs for signature/certification keys
5 - possibility to export private keys to user-certified devices
6 - support for out-of-band authorization (HW)
7 - support for more informative signing (requires a small display: HW)

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.

Since smartcards have evolved (slowly...) and nowadays we have other
much-less-constrained alternatives (GnuK), I feel that many limitations
are just an heavy heritage that's becoming nonsensical.

The reasons behind my list, point by point:
1 - I'd like to roll the key used for reading mail every year, but
currently that would mean I'd have to use a new card every year or have
old keys on-disk, defeating the purpose of using a smartcard/token (from
my tests on actual smartcards, it's not hard to have room for 14 to 20
keys on an 80k smartcard, more than 30 on a 144k one, WAY more are
possible on GnuK)
2 - If I have to use my card to login on a possibly untrusted computer,
I don't want it to steal my PIN and sign/certify without me knowing it
3 - Since NFC readers often have no pinpad (or could have easily been
tampered with) I don't want to expose my main PIN nor the same key I use
for "wired" auth
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)
5 - I know, it's debatable and many see it as dangerous... but is it
more dangerous than keeping an on-disk (or on-paper) copy of the key?
Key export should be protected by a "certificate" (policy object defines
an "allowed KeyID for export" and the private key is exported only
encrypted to that KeyID); might even set a "fuse" to mark the fact that
the key have been exported
6 - like in Yubikey NEO, a physical button to authorize some operations
can be useful (certification, signature, NFC PIN-less auth)
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

What do you think? Complete BS or could something be considered for
inclusion?

PS: 1 is the main reason I'm not yet using GPG much, even if I started
using it since DOS & FIDO-BBSs era...

BYtE,
 Diego.



More information about the Gnupg-users mailing list