version 0.18 release/0.18
authorNIIBE Yutaka <gniibe@fsij.org>
Tue, 15 May 2012 01:16:25 +0000 (10:16 +0900)
committerNIIBE Yutaka <gniibe@fsij.org>
Tue, 15 May 2012 04:50:32 +0000 (13:50 +0900)
12 files changed:
ChangeLog
NEWS
README
doc/NOTES
src/Makefile.in
src/main.c
src/usb_desc.c
src/usb_endp.c [deleted file]
tool/openocd-script/lock.tcl
tool/openocd-script/options_read.tcl
tool/openocd-script/unlock.tcl
tool/openocd-script/write.tcl

index 663e048..7038335 100644 (file)
--- a/ChangeLog
+++ b/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.
diff --git a/NEWS b/NEWS
index 606c98f..f6a8bad 100644 (file)
--- a/NEWS
+++ b/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.
diff --git a/README b/README
index 0a071ab..e25625c 100644 (file)
--- a/README
+++ b/README
@@ -1,8 +1,8 @@
 Gnuk - software for GnuPG USB Token
 
-                                                          Version 0.17
-                                                            2012-02-02
-                                                          Niibe Yutaka
+                                                          Version 0.18
+                                                            2012-05-15
+                                                          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
-me to bring a card reader all the time.  With Gnuk, this issue will be
+There is a solution with OpenPGP card, but it is not the choice for me
+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.
-    (It is welcome for me that some vendor will manufacture Gnuk USB
-     Token.  Even I can help design of hardware, if needed.)
-    Good points are:
+A0: IMRHO, not quite, since there is no ready-to-use out-of-box Gnuk
+    product yet.  (It is welcome for me that some vendor will
+    manufacture Gnuk USB Token.  Even I can help design of hardware,
+    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
-                               (GNU Toolchain, Python, etc.), 
+           "by Free Software"; Gnuk development requires only Free Software
+                               (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
-          doesn't work well.
+         work well.  Please make sure to disable DEBUG option if it
+         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
-
-Please read section 'USB vendor ID and product ID' above.
+it's: --vidpid=234b:0000 .  Please read section 'USB vendor ID and
+product ID' above.
 
 Type:
 
index 457ee66..ad39233 100644 (file)
--- a/doc/NOTES
+++ b/doc/NOTES
@@ -1,28 +1,72 @@
-USB communication
-=================
+USB communication (current)
+===========================
+
+* Get response, command chaining, short APDU only.
+
+
+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::
 
-  * No command chaining, but extended APDU and extended Lc and Le.
-    I think that this keep the code simple.
+    host <-----------> reader <---------> smartcard
+           CCID/ICCD           ISO 7816
+    
+    host <--> token
 
-  * 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.
+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.
 
-  * 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.
+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
index 743618a..eed49be 100644 (file)
@@ -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) \
index 47bfd68..0f4bb0b 100644 (file)
@@ -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)
index b9c9c5d..0ebc03d 100644 (file)
@@ -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,
diff --git a/src/usb_endp.c b/src/usb_endp.c
deleted file mode 100644 (file)
index ac60fe7..0000000
+++ /dev/null
@@ -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);
-}
index ecb5a96..9142fd0 100644 (file)
@@ -3,4 +3,4 @@ reset
 halt
 stm32x lock 0
 reset
-exit
+shutdown
index 7ea8c40..7c7658a 100644 (file)
@@ -2,4 +2,4 @@ init
 reset
 halt
 stm32x options_read 0
-exit
+shutdown
index 2f14aeb..67883ed 100644 (file)
@@ -3,4 +3,4 @@ reset
 halt
 stm32x unlock 0
 reset
-exit
+shutdown
index 50d4382..1ddf8cd 100644 (file)
@@ -2,4 +2,4 @@ init
 reset
 halt
 flash write_image erase gnuk.elf
-exit
+shutdown