deon/gnuk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

version 0.18

Browse Source
This commit is contained in:
NIIBE Yutaka
2012-05-15 10:16:25 +09:00
parent 4505715cf3
commit a921d408c5
12 changed files with 116 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
doc/NOTES
View File

@@ -1,28 +1,72 @@
USB communication
=================
USB communication (current)
===========================
* No command chaining, but extended APDU and extended Lc and Le.
I think that this keep the code simple.
* Get response, command chaining, short APDU only.
* Once in the past (version <= 0.4), the value of
dwMaxCCIDMessageLength was 64 and we supported ICC block chaining,
so that we could not handle multple Bulk transactions.
* Now, the value of dwMaxCCIDMessageLength is 320, that's the size
of header of ICC block plus size of maximum APDU (by 64
granularity). Still, some ccid implementation (ccid 1.3.11, for
example) sends ICC block using chaining unfortunately, so we keep
the code of ICC block chaining.
If it were only for token and no smartcard:
* Get response, command chaining and short APDU would be considered
useless.
* It would be wise to use extended APDU and CCID/ICCD block chaining.
The question would be: When lower layer (CCID/ICCD layer) support
enough mechanism of block assembly, why not use one in the application
layer (ISO 7816)?
For token implementation, CCID/ICCD would be lower layer and ISO 7816
would be higher layer, but it's different in fact. The figure of
communication is like::
host <-----------> reader <---------> smartcard
CCID/ICCD ISO 7816
host <--> token
Given the situation host side (GnuPG) already has the features of
handling get response, command chaining, and short APDU only, it is
rather better to do that on token side too.
Besides, supporting extended APDU on host side, it would be needed to
prepare 64KB buffer (that's the maximum size), as there is no explicit
limitation for buffer size. 64KB would be large, and this could be
avoided when we use short APDU only.
USB communication (second attempt)
==================================
* No get response, no command chaining, but extended APDU and extended
Lc and Le. I think that this keep the code simple.
* The value of dwMaxCCIDMessageLength is 320, that's the size
of header of ICC block plus size of maximum APDU (by 64
granularity). Still, some ccid implementation (ccid 1.3.11, for
example) sends ICC block using chaining unfortunately, so we keep
the code of ICC block chaining.
USB communication (initial attempt)
===================================
* Once in the past (version <= 0.4), the value of
dwMaxCCIDMessageLength was 64 and we supported CCID/ICCD block chaining,
so that we could not handle multple Bulk transactions.
OpenPGP card protocol implementation
====================================
I try to follow "no clear password(s)" policy, even if it is on
protected flash memory. Futher, keystrings for user and reset code
are removed after key imports. Because of this, replacing keys
are not possible without password information. Thus, replacing
existing keys are not supported.
protected flash memory. Further, keystrings for user and reset code
are removed after key imports. Because of this, replacing keys are
not possible without password information. (Thus, replacing existing
keys are not supported.)
Therefore, there is "no clear password" and "no keystrings" on flash
ROM when Gnuk is used by admin-less mode. When it is used with admin,
the keystring of admin is on flash ROM.
How a private key is stored