wk at gnupg.org
Thu May 19 09:55:58 CEST 2011
On Thu, 19 May 2011 01:57, marcus.brinkmann at ruhr-uni-bochum.de said:
> The problem is that you can not declare it not to be a security feature by
> fiat. Users will perceive it as a security feature or not depending on the
Right. However, I neither view the security features of a desktop (ACL,
root permissions, kernel permissions) as a strong measure against
attacks. In my threat model you own the box as soon as you get the
permission to execute any program of your choice on the box. This is
due to the fact that it is virtually impossible to avoid local exploits.
In this regard desktop boxes are not different than smartphones.
The architecture of GnuPG may only help against such attacks if we move
gpg-agent to a small dedicated box. Of course we can't use a simple
title string then to show which process requests a private key
You have a similar problem with PINpad equipped card readers - you'll
never know which process triggered the PIN query and thus the signature
creation or decrypt operation. With a little bit of social engineering
it is easy to trick a user to sign a different document or to decrypt a
> story is different on recent mobile devices). I think the best that can be
> achieved in a simple manner is to make sure that a cached passphrase is not
> used in quick succession many times without the user being able to notice this
That would fail on my box. I have scripts which open ssh connections to
several other boxes quite often - they rely on passphrase caching.
Further malware may well be aware of the fact that your proposed
countermeasure is in place and delay all actions. I bet spam bots do
that already to foil similar countermeasures at ISP's mail smarthosts
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel