On 2015-02-06 09:12, Andreas Schwier wrote:
> On 02/06/2015 01:21 AM, Matthias-Christian Ott wrote:
>> What is the threat model in which a smartcard is an effective defense
>> and what are attacks that smartcards protect against? How are smartcards
>> supposed to protect against malware on the host computer?
> Smart cards (if done well) protect from unwanted key duplication or
> disclosure. It's much harder to break into someones home to steal the
> card than it is to steal a file and a number of key strokes.
If you use Schneier's attack tree for PGP encryption [1] as the threat
model (for the lack of something better), a smartcard would protect
against 1.4.2 ("Get private key from recipient's key ring") and 1.4.3
("Monitor recipient's memory"). But if your goal is 1 ("Read a message
encrypted with PGP") and you have infected the host computer (as you
scenario says) you can't protect against 1.2.1 ("Fool sender into
encrypting message using public key whose private key is known"), 1.2.3
("Monitor sender's computer memory") and 1.2.4 ("Monitor receiver's
computer memory"), any of which suffices to achieve the goal. A similar
argument can be made for digital signatures.
Maybe smartcards can increase the costs of an attack but security
economics are a really dangerous field that equates people to money and
works by the "garbage in garbage out" principle which is also dangerous
if you are non-critical. Peter Gutmann reports in the draft of his book
"Engineering Security" [2] that there is in fact malware that steals
keys and certificates. Perhaps a smartcard could have prevented some
current malware from stealing your keys from the smartcard but stealing
the keys is just a means to an end and the ultimate goal is to either
break confidentiality (decrypt messages) or impersonation (sign messages
of the attackers choice).
Perhaps one can say that smartcards can improve the usability,
especially for average computer users who know how to protect bank cards
and want portable key storage. Perhaps this in itself improves security
because these users would better understand the system. I have setup
some users with smartcards for HBCI banking and noticed that they
applied more "security measures" and caution with the card than logging
into the website of their bank with username and password.
> Of course a smart card can not protect against malware on the host
> computer, but it can prevent that the key is gone after malware has
> infected the host. If my card is suddenly missing from my desk, than
> that is much easier to spot than an illegal copy of my key file - which
> I can't really detect.
That is definitely a usability advantage, especially if you consider
ransomware that wants to get money from the user for decrypting their
files. However, randsomware could also destroy your smartcard by
entering a wrong PIN and PUK (or whatever they are called) too many times.
> And we are talking about the average user that can not easily control
> what processes are running on their computer and if it's good or bad.
> For them it's much easier to lock important keys away in their desk than
> it is to keep a computer free from malware.
I agree. But if your adversary is more powerful than an average
cybercriminal that won't help you either because such adversary could
intercept the communication between smartcard and host computer and
would trick you into performing a key rollover or decrypt or sign other
messages that you did not intend to decrypt or sign. Of course you would
notice this at some point and perhaps notice it more likely with a
smartcard (if you can trust it) than with a key file but if you notice
it, it might be already too late: Imagine for example a journalist
communicating with a source (just too use an example that has been used
too many times ;)) and an adversary who wants to find the source. The
adversary could feed the smartcard a different message that the
journalist wanted to sign and for example sign the message "meet me at t
at l". Instead of the journalist the adversary would wait at l at time t
to arrest the source. Another example would be malware that wants to get
another piece of malware signed (see Gutmann's book for examples) that
infects computer of a software developer or company and instead of
signing the new release of a software it signs a new release that also
contains malware because it is able to control the communication between
host computer and smartcard (this would also work with source code only
releases). You can also see this problem when you look at online
banking. When German banks employed indexed TAN lists there was malware
that simply substituted the recipient fields of wire transfer forms but
displayed the original recipient fields to the user. German banks had to
take the extreme measure of distributing air-gapped devices to their
customers that display the entire contents of the wire transfer form on
their tiny screen to prevent this attack (this doesn't help if the
attacker also manipulates the bill that you received via email and want
to pay). For OpenPGP this is simply infeasible to display the entire
message in hexdecimal on a tiny one line screen and a hash value won't
help either. For example the attack on the German eID card, where users
signed PDFs with embedded data that the eID PDF reader could not
display, demonstrated this. In all of these cases it does not matter for
the attacker whether the attacker is in possession of the private keys.
Moreover, sandboxing and update mechanisms like those employed by the
Google Chrome and Chromium web browsers have probably saved more average
users from malware than any smartcards combined (see more lengthy
description in previous emails). So from the perspective of security
economics (if you want to apply it and have given up absolute security)
such mechanisms are a cheaper and more effective countermeasure for the
average user.
Regards,
Matthias-Christian
[1] https://www.schneier.com/attacktrees.pdf
[2] https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
