Page MenuHome GnuPG

OpenPGP card protocol 3.4 with Yubikey
Closed, ResolvedPublic

Description

In 3.4, Yubikey has a specific feature of "Attestation key".
This would cause compatibility issue with GnuPG, so, we need to care about the "Attestation key" (even if it won't be supported by standard tool).

Event Timeline

gniibe triaged this task as Normal priority.May 28 2020, 8:15 AM

Here is the dump of "Application Related Data" (6E):

6e 82 01 47
   4f 10
      d2760001240103040006106160490000
   5f 52 08
      00730000e0059000
   7f 74 03
      810120
   73 82 01 20
      c0 0a
         7d000bfe080000ff0000
      c1 0b
         162b06010401da470f0100
      c2 0c
         122b06010401975501050100
      c3 0b
         162b06010401da470f0100
      da 06  <-------------------------------------- This is algorithm attributes for Attestation key (Yubikey specific)
         010800001100
      c4 07
         ff7f7f7f030003
      c5 50
         eeeed1b50b1b1d9c669033fe019e94a27992b44c
         d00b630fdcb5c4397d5ffbd69aa68a3ff9f8ed10
         1b2a3d46f4f0c5afd0115e7eb858d476daf64cdb
         0000000000000000000000000000000000000000  <--- This appears to be fingerprint of Attestation key
      c6 50
         0000000000000000000000000000000000000000
         0000000000000000000000000000000000000000
         0000000000000000000000000000000000000000
         0000000000000000000000000000000000000000  <--- This appears to be fingerprint of some key related to Attestation key???
      cd 10
         5e58b1e65e58b1c55e58b1f900000000
      de 08
         0102020203028102
   7f 66 08
      02020bfe02020bfe
   d6 02
      0020
   d7 02
      0020
   d8 02
      0020
   d9 02
      0020

And here is (raw) dump of the data object FA:

raw apdu: 00ca00fa00
response: sw=61E4  datalen=256
     dump:  fa8201e2c106010800001100c106010c00001100c106011000001100c109132a \
8648ce3d030107c106132b81040022c106132b81040023c106132b8104000ac1 \
0a132b2403030208010107c10a132b240303020801010bc10a132b2403030208 \
01010dc10a162b06010401da470f01c10b162b060104019755010501c2060108 \
00001100c206010c00001100c206011000001100c209122a8648ce3d030107c2 \
06122b81040022c206122b81040023c206122b8104000ac20a122b2403030208 \
010107c20a122b240303020801010bc20a122b240303020801010dc20a162b06 \
010401da470f01c20b162b060104019755010501c306010800001100c306010c \
61e4

raw apdu: 00c00000e4
response: sw=9000  datalen=228
     dump:  00001100c306011000001100c309132a8648ce3d030107c306132b81040022c3 \
06132b81040023c306132b8104000ac30a132b2403030208010107c30a132b24 \
0303020801010bc30a132b240303020801010dc30a162b06010401da470f01c3 \
0b162b060104019755010501da06010800001100da06010c00001100da060110 \
00001100da09132a8648ce3d030107da06132b81040022da06132b81040023da \
06132b8104000ada0a132b2403030208010107da0a132b240303020801010bda \
0a132b240303020801010dda0a162b06010401da470f01da0b162b0601040197 \
550105019000

Note that the command-responses are composed by two times.

Hand parsing the data object content:

fa 82 01 e2
   c1 06
      010800001100
   c1 06
      010c00001100
   c1 06
      011000001100
   c1 09
      132a8648ce3d030107
   c1 06
      132b81040022
   c1 06
      132b81040023
   c1 06
      132b8104000a
   c1 0a
      132b2403030208010107
   c1 0a
      132b240303020801010b
   c1 0a
      132b240303020801010d
   c1 0a
      162b06010401da470f01
   c1 0b
      162b060104019755010501
   c2 06
      010800001100
   c2 06
      010c00001100
   c2 06
      011000001100
   c2 09
      122a8648ce3d030107
   c2 06
      122b81040022
   c2 06
      122b81040023
   c2 06
      122b8104000a
   c2 0a
      122b2403030208010107
   c2 0a
      122b240303020801010b
   c2 0a
      122b240303020801010d
   c2 0a
      162b06010401da470f01
   c2 0b
      162b060104019755010501
   c3 06
      010800001100
   c3 06
      010c00001100
   c3 06
      011000001100
   c3 09
      132a8648ce3d030107
   c3 06
      132b81040022
   c3 06
      132b81040023
   c3 06
      132b8104000a
   c3 0a
      132b2403030208010107
   c3 0a
      132b240303020801010b
   c3 0a
      132b240303020801010d
   c3 0a
      162b06010401da470f01
   c3 0b
      162b060104019755010501
   da 06
      010800001100
   da 06
      010c00001100
   da 06
      011000001100
   da 09
      132a8648ce3d030107
   da 06
      132b81040022
   da 06
      132b81040023
   da 06
      132b8104000a
   da 0a
      132b2403030208010107
   da 0a
      132b240303020801010b
   da 0a
      132b240303020801010d
   da 0a
      162b06010401da470f01
   da 0b
      162b060104019755010501

Here is a dump of my token (Yubikey 5.2.6). I used the new apdu command of gpg-card along with "undump | dumpasn1 -", which saves quite some time:

   0 482: [PRIVATE 26] {
   4   6:   [PRIVATE 1] 01 08 00 00 11 00
  12   6:   [PRIVATE 1] 01 0C 00 00 11 00
  20   6:   [PRIVATE 1] 01 10 00 00 11 00
  28   9:   [PRIVATE 1] 13 2A 86 48 CE 3D 03 01 07
  39   6:   [PRIVATE 1] 13 2B 81 04 00 22
  47   6:   [PRIVATE 1] 13 2B 81 04 00 23
  55   6:   [PRIVATE 1] 13 2B 81 04 00 0A
  63  10:   [PRIVATE 1] 13 2B 24 03 03 02 08 01 01 07
  75  10:   [PRIVATE 1] 13 2B 24 03 03 02 08 01 01 0B
  87  10:   [PRIVATE 1] 13 2B 24 03 03 02 08 01 01 0D
  99  10:   [PRIVATE 1] 16 2B 06 01 04 01 DA 47 0F 01
 111  11:   [PRIVATE 1] 16 2B 06 01 04 01 97 55 01 05 01
 124   6:   [PRIVATE 2] 01 08 00 00 11 00
 132   6:   [PRIVATE 2] 01 0C 00 00 11 00
 140   6:   [PRIVATE 2] 01 10 00 00 11 00
 148   9:   [PRIVATE 2] 12 2A 86 48 CE 3D 03 01 07
 159   6:   [PRIVATE 2] 12 2B 81 04 00 22
 167   6:   [PRIVATE 2] 12 2B 81 04 00 23
 175   6:   [PRIVATE 2] 12 2B 81 04 00 0A
 183  10:   [PRIVATE 2] 12 2B 24 03 03 02 08 01 01 07
 195  10:   [PRIVATE 2] 12 2B 24 03 03 02 08 01 01 0B
 207  10:   [PRIVATE 2] 12 2B 24 03 03 02 08 01 01 0D
 219  10:   [PRIVATE 2] 16 2B 06 01 04 01 DA 47 0F 01
 231  11:   [PRIVATE 2] 16 2B 06 01 04 01 97 55 01 05 01
 244   6:   [PRIVATE 3] 01 08 00 00 11 00
 252   6:   [PRIVATE 3] 01 0C 00 00 11 00
 260   6:   [PRIVATE 3] 01 10 00 00 11 00
 268   9:   [PRIVATE 3] 13 2A 86 48 CE 3D 03 01 07
 279   6:   [PRIVATE 3] 13 2B 81 04 00 22
 287   6:   [PRIVATE 3] 13 2B 81 04 00 23
 295   6:   [PRIVATE 3] 13 2B 81 04 00 0A
 303  10:   [PRIVATE 3] 13 2B 24 03 03 02 08 01 01 07
 315  10:   [PRIVATE 3] 13 2B 24 03 03 02 08 01 01 0B
 327  10:   [PRIVATE 3] 13 2B 24 03 03 02 08 01 01 0D
 339  10:   [PRIVATE 3] 16 2B 06 01 04 01 DA 47 0F 01
 351  11:   [PRIVATE 3] 16 2B 06 01 04 01 97 55 01 05 01
 364   6:   [PRIVATE 26] 01 08 00 00 11 00
 372   6:   [PRIVATE 26] 01 0C 00 00 11 00
 380   6:   [PRIVATE 26] 01 10 00 00 11 00
 388   9:   [PRIVATE 26] 13 2A 86 48 CE 3D 03 01 07
 399   6:   [PRIVATE 26] 13 2B 81 04 00 22
 407   6:   [PRIVATE 26] 13 2B 81 04 00 23
 415   6:   [PRIVATE 26] 13 2B 81 04 00 0A
 423  10:   [PRIVATE 26] 13 2B 24 03 03 02 08 01 01 07
 435  10:   [PRIVATE 26] 13 2B 24 03 03 02 08 01 01 0B
 447  10:   [PRIVATE 26] 13 2B 24 03 03 02 08 01 01 0D
 459  10:   [PRIVATE 26] 16 2B 06 01 04 01 DA 47 0F 01
 471  11:   [PRIVATE 26] 16 2B 06 01 04 01 97 55 01 05 01
Error: Inconsistent object length, 2 bytes difference.
        :   }

(let's ignore the error messages)

Why do you think that we need to care about the attestation key? Where possible I take in new code in account that we will have more OpenPGP keys, but right now I don't think that is makes sense to replace our data structures for that the 3 element arrays we currently use are okay for the 3 standard keys. We can latter see how to replace them. At one place I already introduced something new:

> scd getattr KEY-STATUS
S KEY-STATUS OPENPGP.1 1
S KEY-STATUS OPENPGP.2 1
S KEY-STATUS OPENPGP.3 0
S KEY-STATUS OPENPGP.129 2
OK

Thus the key with id 0x81 should be represented in decimal. I am not sure why in the FA DO Yubikey uses 0x26; that would be OPENPGP.38 with the above scheme.

Perhaps, no change would be required.
My major concern is that: the data object for fingerprints C5 and C6 were defined as fixed-size 60-byte objects (and actually _is_ defined still in the current specification of 3.4), but it's 80-byte (newer Yubikey), which might cause problem(s).

Ok. However, I don't think that the fingerprint is really important. We can compute it anyway as long as we have the creation date. The keygrip is meanwhile more important but that is also easy to compute.

I agree.
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).

The data object 0x00FA is now supported. And other changes are not needed.