version 0.18

ChangeLog

@@ -1,3 +1,14 @@
+2012-05-15  Niibe Yutaka  <gniibe@fsij.org>
+
+	* Version 0.18.
+
+	* src/usb_desc.c (gnukStringSerial): Updated.
+
+	* src/main.c (EP3_IN_Callback, EP5_OUT_Callback): Move from
+	usb_endp.c.
+
+	* src/usb_endp.c: Remove.
+
 2012-05-14  Niibe Yutaka  <gniibe@fsij.org>
 
 	* tool/gnuk_remove_keys.py: New.

NEWS

@@ -2,12 +2,16 @@ Gnuk NEWS - User visible changes
 
 * Major changes in Gnuk 0.18
 
-  Released 2012-05-XX, by NIIBE Yutaka
+  Released 2012-05-15, by NIIBE Yutaka
 
 ** New mandatory option '--vidpid' for configure
 You must specify USB vendor ID and product ID for Gnuk.
 The file GNUK_USB_DEVICE_ID lists valid USB device IDs.
 
+** New tool: gnuk_remove_keys.py
+The tool gnuk_remove_keys.py is to remove all keys in Gnuk Token
+and reset PW1 and RC (if any).
+
 ** New USB stack
 Gnuk used to use USB stack of USB-FS-Device_Lib by ST.  Now, it has
 original implementation.  Hopefully, size and quality are improved.

README

@@ -1,8 +1,8 @@
 Gnuk - software for GnuPG USB Token
 
-							   Version 0.17
+							   Version 0.18
-							     2012-02-02
+							     2012-05-15
-						           Niibe Yutaka
+							   Niibe Yutaka
 				      Free Software Initiative of Japan
 
 What's Gnuk?
@@ -14,8 +14,8 @@ STM32F103 processor.
 
 I wish that Gnuk will be a developer's soother who uses GnuPG.  I have
 been nervous of storing secret key(s) on usual secondary storage.
-While I want to work at different places, but it is not the choice for
+There is a solution with OpenPGP card, but it is not the choice for me
-me to bring a card reader all the time.  With Gnuk, this issue will be
+to bring a card reader all the time.  With Gnuk, this issue will be
 solved by a USB token which is small enough.
 
 Please look at the graphics of "gnuk.svg" for the software name.  My
@@ -30,18 +30,19 @@ Q0: How Gnuk USB Token is superior than other solutions (OpenPGP
     card 2.0, GPF Crypto Stick, etc.) ?
     http://www.g10code.de/p-card.html
     http://www.privacyfoundation.de/crypto_stick/
-A0: IMRHO, not quite.  There is no ready-to-use out-of-box product.
+A0: IMRHO, not quite, since there is no ready-to-use out-of-box Gnuk
-    (It is welcome for me that some vendor will manufacture Gnuk USB
+    product yet.  (It is welcome for me that some vendor will
-     Token.  Even I can help design of hardware, if needed.)
+    manufacture Gnuk USB Token.  Even I can help design of hardware,
-    Good points are:
+    if needed.)
+    Good points for Gnuk are:
     * If you have skill of electronics and like DIY, you can build
       Gnuk Token cheaper (see Q8-A8).
     * You can study Gnuk to modify and to enhance.  For example, you
       can implement your own authentication method with some sensor
       such as acceleration sensor.
     * It is "of Free Software"; Gnuk is distributed under GPLv3+,
-            "by Free Software"; Gnuk development requires only Free Software
+	    "by Free Software"; Gnuk development requires only Free Software
-	    	                (GNU Toolchain, Python, etc.), 
+				(GNU Toolchain, Python, etc.), 
 	    "for Free Software"; Gnuk supports GnuPG.
 
 Q1: What kind of key algorithm is supported?
@@ -90,7 +91,7 @@ A9: GnuPG's SCDaemon has problems for handling insertion/removal of
     and confirm scdaemon doesn't exist, then,
       $ gpg-connect-agent learn /bye
 
-Qa: With GNOME, I can't use Gnuk Token for SSH.  How can we use it for SSH?
+Qa: With GNOME 2, I can't use Gnuk Token for SSH.  How can we use it for SSH?
 Aa: You need to deactivate seahorse-agent and gnome-keyring, but use
     gpg-agant for the role of ssh-agent.  For gnome-keyring please do:
 
@@ -112,7 +113,8 @@ Ac: Perhaps, you can use a part of STM32F4 Discovery Kit as SWD
 Release notes
 =============
 
-This is eighteenth release of Gnuk.  While it works well for specific
+This is nineteenth release of Gnuk.  In this release, the usage of USB
+device ID by FSIJ is clarified.  While it works well for specific
 usages and it is considered stable, it is still somewhat experimental.
 
 Tested features are:
@@ -131,16 +133,17 @@ Tested features are:
 	* Verify with pin pad
 	* Modify with pin pad
 	* Card holder certificate
+	* Removal of keys (Overriding key import is not supported,
+	  but you can remove all keys to import again).
 
 It is known not-working well:
 
 	* For some version of kernel and libccid, --enable-debug can't
-          work well.  Please make sure to disable DEBUG option if it
+	  work well.  Please make sure to disable DEBUG option if it
-          doesn't work well.
+	  doesn't work well.
 
 Not supported feature(s):
 
-	* Overriding key import.  You need to remove all keys first.
 	* Key generation on device side
 
 
@@ -316,9 +319,8 @@ Then, run `configure':
   $ ./configure --vidpid=<VID:PID>
 
 Here, you need to specify USB vendor ID and product ID.  For FSIJ's,
-it's: --vidpid=234b:0000
+it's: --vidpid=234b:0000 .  Please read section 'USB vendor ID and
-
+product ID' above.
-Please read section 'USB vendor ID and product ID' above.
 
 Type:
 

doc/NOTES

@@ -1,28 +1,72 @@
-USB communication
+USB communication (current)
-=================
+===========================
 
-  * No command chaining, but extended APDU and extended Lc and Le.
+* Get response, command chaining, short APDU only.
-    I think that this keep the code simple.
 
-  * 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
+If it were only for token and no smartcard:
-    of header of ICC block plus size of maximum APDU (by 64
+
-    granularity).  Still, some ccid implementation (ccid 1.3.11, for
+* Get response, command chaining and short APDU would be considered
-    example) sends ICC block using chaining unfortunately, so we keep
+  useless.
-    the code of ICC block chaining.
+
+* 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
+protected flash memory.  Further, keystrings for user and reset code
-are removed after key imports.  Because of this, replacing keys
+are removed after key imports.  Because of this, replacing keys are
-are not possible without password information.  Thus, replacing
+not possible without password information.  (Thus, replacing existing
-existing keys are not supported.
+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

src/Makefile.in

@@ -3,9 +3,6 @@
 BOARD_DIR=@BOARD_DIR@
 @PINPAD_MAKE_OPTION@
 @DEBUG_MAKE_OPTION@
-ifneq ($(ENABLE_DEBUG),)
-ENABLE_VCOMPORT=1
-endif
 
 ##############################################################################
 # Build global options
@@ -72,10 +69,6 @@ include $(CHIBIOS)/os/ports/GCC/ARMCMx/STM32F10x/port.mk
 include $(CHIBIOS)/os/kernel/kernel.mk
 include crypt.mk
 
-ifneq ($(ENABLE_VCOMPORT),)
-VCOMSRC += usb_endp.c
-endif
-
 # C sources that can be compiled in ARM or THUMB mode depending on the global
 # setting.
 CSRC = $(PORTSRC) \

src/main.c

@@ -140,6 +140,19 @@ STDOUTthread (void *arg)
   goto again;
   return 0;
 }
+
+void
+EP3_IN_Callback (void)
+{
+  if (stdout_thread)
+    chEvtSignalI (stdout_thread, EV_TX_READY);
+}
+
+void
+EP5_OUT_Callback (void)
+{
+  usb_lld_rx_enable (ENDP5);
+}
 #else
 void
 _write (const char *s, int size)

src/usb_desc.c

@@ -258,8 +258,9 @@ static const uint8_t gnukStringLangID[] = {
 const uint8_t gnukStringSerial[] = {
   18*2+2,			/* bLength */
   USB_STRING_DESCRIPTOR_TYPE,	/* bDescriptorType */
+  /* FSIJ-0.18 */
   'F', 0, 'S', 0, 'I', 0, 'J', 0, '-', 0, 
-  '0', 0, '.', 0, '1', 0, '7', 0, /* Version number of Gnuk */
+  '0', 0, '.', 0, '1', 0, '8', 0, /* Version number of Gnuk */
   '-', 0,
   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,

src/usb_endp.c

@@ -1,21 +0,0 @@
-/*
- * Virtual COM port (for debug output only)
- */
-
-#include "config.h"
-#include "ch.h"
-#include "gnuk.h"
-#include "usb_lld.h"
-
-void
-EP3_IN_Callback (void)
-{
-  if (stdout_thread)
-    chEvtSignalI (stdout_thread, EV_TX_READY);
-}
-
-void
-EP5_OUT_Callback (void)
-{
-  usb_lld_rx_enable (ENDP5);
-}

tool/openocd-script/lock.tcl

@@ -3,4 +3,4 @@ reset
 halt
 stm32x lock 0
 reset
-exit
+shutdown

tool/openocd-script/options_read.tcl

@@ -2,4 +2,4 @@ init
 reset
 halt
 stm32x options_read 0
-exit
+shutdown

tool/openocd-script/unlock.tcl

@@ -3,4 +3,4 @@ reset
 halt
 stm32x unlock 0
 reset
-exit
+shutdown

tool/openocd-script/write.tcl

@@ -2,4 +2,4 @@ init
 reset
 halt
 flash write_image erase gnuk.elf
-exit
+shutdown