Mailing List Archive: GnuPG: users

Required patches for the OpenPG card v2.0

Index | Next | Previous | View Threaded

wk at gnupg

Jun 23, 2009, 9:26 AM

Post #1 of 2 (550 views)
Permalink

Required patches for the OpenPG card v2.0

Hi!

Unfortunately I realized too late that 2.0.12 still had bugs with the
new OpenPGP card[1]. Without actual hardware testing stuff is a bit
hard; I had 2 engineering samples during development and we swapped card
back and forth to squash the bugs in the card's firmware while also
hacking gnupg. Thus some things got not tested for 2.0.12.

Find attached 2 patches against GnuPG 2.0.12 to fix the card problem as
well as an unlrealted Windows-only problem. These patches are already
in the Gpg4win 2.0.0rc1 installer currently being copied to the servers.

GnuPG 1.4 does not yet support the v2 cards. I plan to backport the
code from 2.0 in the next week and then it should not take too long to
get 1.4.10 out. If you don't want to wait: gpg2 is the perfect version
for the desktop or laptop ;-)

A cautionary note: If you plan to buy a smartcard reader, please abstain
From Omnikey based readers (Cardman and some others). They do not work
with 2048 bit smartcards. They work on Windows, but not on a free OSes.
We need to do some protocol analysis to see how the Windows driver
achieves to send so-called extended lengths APDUs. The vendors are not
very helpful in this regard, thus I can only suggest to resort to SCM
based readers.

Salam-Shalom,

Werner

[1] Meanwhile we received the first batch of cards; they will be sold at
the LinuxTag and if cards are left over by next week through the
well known distributor.

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.

Attachments:

01-scd-pw2.patch (3.42 KB)

02-pth-estream.patch (1.72 KB)

wk at gnupg

Jul 22, 2009, 7:57 AM

Post #2 of 2 (399 views)
Permalink

Re: Required patches for the OpenPG card v2.0 [In reply to]

On Sat, 18 Jul 2009 18:36, patrick [at] mozilla-enigmail said:

> have the wrong card inserted (e.g. for decryption), gpg 1.4.9 responds
> with these status messages:
>
> [GNUPG:] ENC_TO 12A7990DF2541241 1 0
> [GNUPG:] CARDCTRL 3 D2760001240101010001000000460000
> [GNUPG:] CARDCTRL 1 D2760001240102000005000000700000
> [GNUPG:] SC_OP_FAILURE
> [GNUPG:] BEGIN_DECRYPTION
> [GNUPG:] DECRYPTION_FAILED
>
>
> Version 2.0.12+ only responds with this:
> [GNUPG:] ENC_TO 12A7990DF2541241 1 0
> [GNUPG:] BEGIN_DECRYPTION
> [GNUPG:] DECRYPTION_FAILED
> [GNUPG:] END_DECRYPTION

Yo used 1.4.9 without scdaemon support; if you would have used it with
gpg-agent/scdaemon, the output would be similar to:

[GNUPG:] ENC_TO 10B671F6860B1CFE 1 0
[GNUPG:] CARDCTRL 3
[GNUPG:] SC_OP_FAILURE
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION

Thus the CARDCTRL 1 is also missing. I changed gpg2 to emit:

[GNUPG:] ENC_TO 10B671F6860B1CFE 1 0
[GNUPG:] CARDCTRL 3 D2760001240101010001000003470000
[GNUPG:] SC_OP_FAILURE
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION

Which is basically the same. It just adds the s/n of the current card
to CARDCTRL 3.

The question now is what to do with the cardctrl values used on a
standalone gpg:

CARDCTRL 1 = Request insertion of a card. Serialnumber may be given
to request a specific card.
CARDCTRL 2 = Request removal of a card.

With scdaemon handling all access to the cards, including the PIN
question, it would make sense to have scdaemon ask for inserting the
right card as well. To allow for a bit of unattended operation this
needs to be suppressed if --batrch is given to gpg. Do you see any
problem with such an approach?

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads