Making the case for smart cards for the average user

[MFPA]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Saturday 14 March 2015 at 9:00:08 PM, in
<mid:CAAocvpuOT+Ezp6p3Genj4qrFiW4kN84aQxMJyw+mELah-GXL-Q at mail.gmail.com>,
Joey Castillo wrote:

First [OT], I'll point out that your message didn't thread below my
message to which you replied. Your message arrived missing the
"In-Reply-To:" and "References:" headers, which would have enabled
this to happen.



> even with a password manager, the security
> of that still depends on choosing and guarding a
> complex password to secure the password store. It's
> passwords all the way down.

Fair enough, the user needs a password for the password manager. But
it is no extra effort to have the password manager remember a complex
password for the key.



> Certainly; if your system is compromised by malware it
> could substitute the message, store session keys, or
> keylog your PIN for that matter. If your system is
> compromised, all bets are off.

Pretty much any system *could* be compromised. Should we say all bets
are off because there is a possibility the system might be
compromised?



> The difference is that
> with your keys on a smart card, at least such a breach
> won't compromise your secret key material.

Good point. We are told that smartcard design precludes copying the
key material without physically destroying the card and applying some
pretty heavy-duty forensics. But do we *know* this to be true, or is
it just collective wishful thinking?



> Without smart cards, if I want to use GnuPG on my
> laptop, my iPhone and my Nexus 7, I have to put my
> secret key on each of those devices and enter my
> passphrase into each of those devices. This
> dramatically increases the surface area available for
> an attack on my secret keys.

The secret key material is safe if it is protected by a
suitably-strong passphrase. Passphrase-compromise is the issue on any
networked device (even an air-gapped device that occasionally
receives/sends files by sneakernet).



> tradeoff: in exchange for better security for my secret
> key material, I'm exposing myself to a threat from a
> determined, active attacker that's able to get
> specialized gear into the same room as me while I'm
> using my card. For some minority of people, that may be
> a reasonable concern; for most people, it really isn't.

Sounds like less of an issue than NFC payments from credit/debit cards
with no requirement for a PIN or a signature.

PIN-entry being on the Android device you are using presumably means
that an attacker who managed to evesdrop your NFC connection would be
able to record the signal containing the PIN. Which they may then be
able to re-send, hypothetically allowing them to continue signing or
decrypting so long as your card was within range of their equipment.
How is this type of threat mitigated against in your current
specification?



> Also, there's nothing preventing us from better
> securing the NFC channel in a future card
> specification; in particular, NFC's resistance to man
> in the middle attacks makes it easy to establish a
> shared secret to secure the channel, as proposed in a
> 2010 standard. [2]

That would be a future solution to my question above. (-:


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Put knot yore trust inn spel chequers
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJVBYPwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwi6MH/A8gK4haIH6RoVV2zTlA7RAT
CnC3n3l53TvCtwXAsBzetaTLQnCWX3LvTioMzkuG39IWkUWhIZgvXVHOqBIFSi9e
3CIfWx3LFohQ0jDnWafqk/zlqqesmF4+I8Fr6B6nU4+CkoP2GkStQaqPEd7Kcsww
55tDGDj0sBiwmjGugSVrD4PPqhztjlACeZnTLaxz5kpgO8QtMpiqdLJFeOniAVUI
/sBYlQMkprKsZVO5ssHGIrOQLdyDLjOflp8SDCkVWrFIPzS7956Q3rA0q94d1pom
reU6CEx8Ix5KpEAqCLuwFoFrz+7T9mK6rpmAzPxaOmhCNt0D8hXAexv1C7C2+mOI
vgQBFgoAZgUCVQWD/F8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45BgdAQByZOf8R/U7W3ub6p0jJdEkmJLq
sdSU5g0YCOM52N2uxQEAjwUbEOHl6SPq61jH5Ffrx749BMEiybJzrj5XDPmDcQQ=
=PLgc
-----END PGP SIGNATURE-----