OpenPGP Smartcard + signing email = two signatures?

[Pete Stephenson]

On 10/1/2013 7:48 PM, Peter Lebbing wrote:
> On 30/09/13 23:10, Pete Stephenson wrote:
>> Has anyone else observed this behavior? If so, is there an explanation?
> 
> It's probably a benign bug, but it would obviously also be a reasonably good way
> to get signatures if somebody had compromised your PC. Put a payload in GnuPG
> such that when you try to sign something, it will first sign the attackers
> message with your first pinentry prompt, and then just prompt again for your
> signature. People who work with computers generally just try again if the first
> time mysteriously failed.

Indeed. I assumed it was merely a bug rather than something with
malicious intent, as it occurred even with fresh-from-the-CD VMs that I
was testing. I assume the bug also occurs without the "force signature
PIN" bit enabled on the smartcard and with non-smartcard based keys.
I've been in touch with Olav at Engimail and provided him with debugging
information that might help.

And yes, if one's computer was compromised  then this is a good way for
a bad guy to get signatures. In my case, I take reasonable precautions
to prevent compromise and, while I can't prove it, I am reasonably
certain that my systems are clean. (Let's hop!)

> This does presume that you enter your PIN on the cardreader, because otherwise
> it would be simpler to just use the PIN you give to the PC :).

In this particular case, I'm using card readers without built-in PINpads
(one is USB and connected to a desktop system, the other is integrated
into a laptop) -- I'm being prompted for the pin by PINentry, which
comes with GnuPG2.

> But I think it's more likely there's a little bug somewhere that loses the message.

That's my thought too. I'll post any updates to this thread.

Cheers!
-Pete


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131011/eb26cb97/attachment-0001.sig>