2.1.x regression (Re: gpg2 keytocard removes secret key)

[NIIBE Yutaka]

On 02/18/2015 02:35 AM, micah anderson wrote:
> To move the secret key material to the card, removing it from the
> computer, you would simply do a 'keytocard' operation, and then quit and
> save. In order to keep the secret key material on the computer, you
> would do the same operation, but this time you would *not* save when you
> quit. There are a number of tutorials out there that describe this step
> as the way to do it.
>
> I discovered yesterday that this third method does not work with gpg2,
> when you do the 'keytocard' operation, the secret key material is
> removed, you do not have the ability to opt-out of the saving process.

On 02/18/2015 09:26 AM, NIIBE Yutaka wrote:
> I opened the issue here to track:
> 
> 	https://bugs.g10code.com/gnupg/issue1846

This bug was fixed in 2.1.3.  Please note that the solution is not
perfect.  It generates a private key stub from the card information.
I'm going to close this issue on the tracker.

It usually works well, but there are at lease two cases it doesn't
work.

(1) When a user remove the card before quit after keytocard.

(2) When a card reader has some problem reading out RSA public key
    from the card.

For (1), it can be recovered by manually remove private key file on host
and invoke 'gpg --card-status'.

I encountered the problem of (2), when I tested VASCO DIGIKEY 920
reader with OpenPGPcard for RSA-2048.  It supports extended APDU level
exchange, but it's dwMaxCCIDsize is only 271.  With this reader,
chaining blocks works well for host-to-reader, but it seems that
chaining is not implemented for the reader-to-host and the response
from card (to reader, then, to host) for read-public-key always fails
because the CCID message size were more than 271 in extended APDU
level.

I know this is a corner case.  But, it is a good lesson for me.


I think that it would be better for OpenPGPcard specification (and
implementations) to work with such (broken) readers.  To do that, it
should support working with short APDU level exchange with
command-chaining (for host-to-reader, reader-to-card) and get-response
(for card-to-reader, reader-to-host).

I guess that this kinds of problems (of extended APDU level exchange)
are already noticed by smartcard industry.  In the document of PC/SC
standard, "Interoperability Specification for ICCs and Personal
Computer Systems", Part 10 IFDs with Secure PIN Entry Capabilities
(revision 2.02.09, November, 2012), we can find the addition of
dwMaxAPDUDataSize for reader attribute.

Unfortunately, it's not the addition to the USB CCID specification
(yet).

Yes, this can improve an application program to cope with readers with
extended APDU level exchange, a bit.  Simultaneously, it is an
evidence that abstraction/encapsulation by extended APDU level
exchange doesn't work well (as intended), and an application program
has to care reader's capability, in detail, when it communicates to
card.

With dwMaxAPDUDataSize, we can avoid a mysterious error which might be
caused by reader's buffer size limitation, that's true.  But, still,
some large command or large response would have no way to work with
extended APDU level.  It only suggests short APDU level exchange or
TPDU level exchange.
--