Whishlist for next-gen card

[Yuji -UG- Imai]

Hi,

2015年2月20日金曜日、NdK<ndk.clanbo at gmail.com
<javascript:_e(%7B%7D,'cvml','ndk.clanbo at gmail.com');>>さんは書きました:

> Hello all.
>
> What I'd like to see addressed in future card
> 6 - support for out-of-band authorization (HW)
>

For token type card, how about appending one more usb port to connect
keyboard? It's just for inputing PIN/passphrase or out-of-bound auth
by hitting the Enter key. USB ten keys like V7 KP0N1-7N0P Numeric keypad
looks suitable for this purpose. Micro USB plug may be prefarable
for compact board design.

I don't like wireless features by two reasons. It may introduce complexity
for middleware
of the card. I like KISS. Another is break visibility to check HSM
composition validness.

For FST-01 spesific request, I ask gniibe to consider about case
design with physical hole
to tightly bind a token with keyring.

Yuji

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.
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150222/17d1ce80/attachment-0001.html>