Fix factory-reset for admin-less mode.
[gnuk/gnuk.git] / README
diff --git a/README b/README
index 77e665d..08feaed 100644 (file)
--- a/README
+++ b/README
-Gnuk - software for GPG USB Token
+Gnuk - An Implementation of USB Cryptographic Token for GnuPG
 
-                                                          Version 0.10
-                                                            2011-02-10
-                                                          Niibe Yutaka
+                                                         Version 1.2.4
+                                                            2017-05-12
+                                                          Niibe Yutaka
                                      Free Software Initiative of Japan
 
+Release Notes
+=============
+
+This is the release of Gnuk, version 1.2.4, which has major
+incompatible changes to Gnuk 1.0.x.  Specifically, it now supports
+overriding key import, but importing keys (or generating keys) results
+password reset.  Please update your documentation for Gnuk Token, so
+that the instruction of importing keys won't cause any confusion.
+
+It has supports of EdDSA, ECDSA (with NIST P256 and secp256k1), and
+ECDH (with X25519, NIST P256 and secp256k1), but this ECC feature is
+somehow experimental, and it requires modern GnuPG 2.1 with libgcrypt
+1.7.0 or later.
+
+It also supports RSA-4096, but users should know that it takes more
+than 8 seconds to sign/decrypt.  Key generation of RSA-4096 just fails,
+because the device doesn't have enough memory.
+
+
 What's Gnuk?
 ============
 
-Gnuk is software implementation of a USB token for GNU Privacy Guard.
-Gnuk supports OpenPGP card protocol version 2, and it runs on STM32
-processor.
+Gnuk is an implementation of USB cryptographic token for GNU Privacy
+Guard.  Gnuk supports OpenPGP card protocol version 3, and it runs on
+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
-solved by a USB token which is small enough.
+There is a solution with OpenPGP card, but it is not the choice for
+me, as card reader is not common device.  With Gnuk, this issue will
+be solved by a USB token.
 
 Please look at the graphics of "gnuk.svg" for the software name.  My
-son used to be with his NUK(R), always, everywhere.  I will be with a
-USB Token by Gnuk everywhere.
+son used to be with his NUK(R), always, everywhere.  Now, I am with a
+USB Cryptographic Token by "Gnuk", always, everywhere.
 
 
-Release notes
-=============
+FAQ
+===
 
-This is eleventh release of Gnuk.  While it works well for specific
-usages, it is still experimental.  Note that you need to write random
-bits after installation of gnuk executable to the chip from this
-release.  This procedure is required to share a single executable
-among multiple devices.
+Q0: How Gnuk USB Token is superior than other solutions (OpenPGP
+    card 2.0, YubiKey, etc.) ?
+    https://www.g10code.de/p-card.html
+    https://www.yubico.com/
+A0: Good points of 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 an 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.), 
+           "for Free Software"; Gnuk supports GnuPG.
 
-Tested features are:
+Q1: What kind of key algorithm is supported?
+A1: Gnuk version 1.0 only supports RSA-2048.
+    Gnuk version 1.2.x supports 255-bit EdDSA, as well as RSA-4096.
+    (Note that it takes long time to sign with RSA-4096.)
 
-       * Personalization of the card
+Q2: How long does it take for digital signing?
+A2: It takes a second and a half or so for RSA-2048. 
+    It takes more than 8 secondd for RSA-4096.
 
-         * Changing Login name, URL, Name, Sex, Language, etc.
+Q3: What's your recommendation for target board?
+A3: Orthodox choice is Olimex STM32-H103.
+    FST-01 (Flying Stone Tiny 01) is available for sale, and it is a
+    kind of the best choice, hopefully.
+    If you have a skill of electronics, STM32 Nucleo F103 is the best
+    choice for experiment.
 
-       * Password handling (PW1, RC, PW3)
+Q4: What's version of GnuPG are you using?
+A4: In Debian GNU/Linux system, I use GnuPG modern 2.1.18 in
+    unstable.
 
-       * Key import for three types:
+Q5: What's version of pcscd and libccid are you using?
+A5: I don't use them, pcscd and libccid are optional, you can use Gnuk
+    Token without them.
+    I tested pcscd 1.5.5-4 and libccid 1.3.11-2 which were in Debian
+    squeeze.
 
-         * key for digital signing
+Q6: What kinds of hardware is required for development?
+A6: You need a target board plus a JTAG/SWD debugger.  If you just
+    want to test Gnuk for target boards with DfuSe, JTAG debugger is
+    not the requirement.  Note that for real use, you need JTAG/SWD
+    debugger to enable flash ROM protection.
 
-         * key for decryption
+Q7: How much does it cost?
+A7: Olimex STM32-H103 plus ARM-USB-TINY-H cost 70 Euro or so.
 
-         * key for authentication
+Q8: How much does it cost for DIY version?
+A8: STM32 Nucleo F103 costs about $10 USD.
 
-       * PSO: Digital Signature
+Q9: I got an error like "gpg: selecting openpgp failed: ec=6.108", what's up?
+A9: Older GnuPG's SCDaemon has problems for handling insertion/removal of
+    card/reader.  When your newly inserted token is not found by
+    GnuPG, try killing scdaemon and let it to be invoked again.  I do:
 
-       * PSO: Decipher
+        $ gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye
 
-       * INTERNAL AUTHENTICATE
+    and confirm scdaemon doesn't exist, then,
 
-       * Changing value of password status bytes (0x00C4)
+        $ gpg-connect-agent learn /bye
 
-       * Verify with pin pad
+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:
 
-       * Modify with pin pad
+      $ gconftool-2 --type bool --set /apps/gnome-keyring/daemon-components/ssh false
 
-It is known not-working well:
+Qb: With GNOME 3.0, I can't use Gnuk Token at all.  Why?
+Ab: That's because gnome-keyring-daemon interferes GnuPG.  Type:
+
+      $ gnome-session-properties
+
+    and at the tab of "Startup Programs", disable check buttons for
+    "GPG Password Agent" and "SSH Key Agent".
+
+Qc: With GNOME 3.x (x >= 8?), I can't use Gnuk Token at all.  Why?
+Ac: That's because gnome-keyring-daemon interferes GnuPG.  Please
+    disable the invocation of gnome-keyring-daemon.  In Debian
+    wheezy, it's in the files /etc/xdg/autostart/gnome-keyring-ssh.desktop
+    and /etc/xdg/autostart/gnome-keyring-gpg.desktop.
+    We have a line something like:
+
+        OnlyShowIn=GNOME;Unity;MATE;
 
-       * For some version of kernel and libccid, --enable-debug can't
-          work well.  Please disable DEBUG option if it doesn't work well.
+    Please edit this line to:
 
-       * Card holder certificate
-         It is implemented in Gnuk side.  But its size matters (>
-         1KB).  GnuPG cannot handle a data object of large size with
-         PC/SC backend.  Specifically, handle_transmit function in
-         pcsc-wrapper.c uses the buffer of size 1024-byte.
+        OnlyShowIn=
 
-Not supported feature(s):
+Qd: Do you know a good SWD debugger to connect FST-01 or something?
+Ad: ST-Link/V2 is cheap one.  We have a tool/stlinkv2.py as flash ROM
+    writer program.  STM32 Nucleo F103 comes with the valiant of
+    ST-Link/V2.  However, the firmware of ST-Link/V2 is proprietary.
+    Now, I develop BBG-SWD, SWD debugger by BeagleBone Green.
 
-       * Overriding key import.  You need to remove all keys first.
 
-       * Key generation
+Tested features
+===============
+
+Gnuk is tested by test suite.  Please see the test directory.
+
+       * Personalization of the card
+         * Changing Login name, URL, Name, Sex, Language, etc.
+       * Password handling (PW1, RC, PW3)
+       * Key import for three types:
+         * key for digital signing
+         * key for decryption
+         * key for authentication
+       * PSO: Digital Signature
+       * PSO: Decipher
+       * INTERNAL AUTHENTICATE
+       * Changing value of password status bytes (0x00C4): forcesig
+       * Verify with pin pad
+       * Modify with pin pad
+       * Card holder certificate (read)
+       * Removal of keys
+       * Key generation on device side for RSA-2048
+       * Overriding key import
+
+Original features of Gnuk, tested manually lightly:
+
+       * OpenPGP card serial number setup
+       * Card holder certificate (write by UPDATE BINARY)
+       * Upgrading with "EXTERNAL AUTHENTICATE" by reGNUal
+
+It is known not-working well:
+
+        * It is known that the specific combination of libccid 1.4.1
+         (or newer) with libusb 1.0.8 (or older) had a minor problem.
+         It is rare but it is possible for USB communication to be
+         failed, because of a bug in libusb implementation.  Use
+         libusbx 1.0.9 or newer, or don't use PC/SC, but use internal
+         CCID driver of GnuPG.
+
 
 Targets
 =======
 
-We use Olimex STM32-H103 board.  We also use STM32 part of STM8S
-Discovery Kit.
+We use Olimex STM32-H103 board and Flying Stone Tiny 01 (FST-01).
 
-With DfuSe support, CQ STARM, STBee, and STBee Mini are also our
-targets.  But those targets with DfuSe are basically not for normal
-use but for experiments, because it would be impossible for DfuSe to
+With DfuSe support, STBee is also our targets.  But this target with
+DfuSe is for experiment only, because it is impossible for DfuSe to
 disable read from flash.  For real use, please consider killing DfuSe
-and enable read protect using JTAG debugger.
+and enabling read protection using JTAG debugger.
+
+For experimental PIN-pad support, I connect a consumer IR receive
+module to FST-01, and use controller for TV.  PIN verification is
+supported by this configuration.  Yes, it is not secure at all, since
+it is very easy to monitor IR output of the controllers.  It is just
+an experiment.  Note that hardware needed for this experiment is only
+a consumer IR receive module which is as cheap as 50 JPY.
+
+Note that you need pinpad support for GnuPG to use PIN-pad enabled
+Gnuk.  The pinpad support for GnuPG is only available in version 2.
 
-I think that it could run on Olimex STM32-P103, or other boards with
-STM32F103.  Besides, we are porting it to STM32 Primer 2.
 
-For PIN-pad support, I connect a consumer IR receive module to STBee
-Mini and STM8S Discovery Kit, and use controller for TV.  PIN
-verification is supported by this configuration.  Yes, it is not
-secure at all, since it is very easy to monitor IR output of the
-controllers.  It is just an experiment.  Note that hardware needed for
-this experiment is only a consumer IR receive module which is as cheap
-as 50 JPY.
+Build system and Host system
+============================
 
-Another PIN-pad support is connecting rotary encoder, push switch and
-7-segment LED display.  Both of PIN verification and PIN modification
-are supported for this circuit extension.
+Makefile is written for GNU make.  You need Bash 4.x for configure.
+
+If your bash is not installed as /bin/bash, you need to run configure
+script prepending 'bash' before './configure'.
+
+Some tools are written in Python.  If your Python is not installed as
+/usr/bin/python, please prepend 'python' for your command invocation.
+Python 2.7 and PyUSB 0.4.3 is assumed.
 
 
 Souce code
@@ -110,6 +221,11 @@ Souce code
 
 Gnuk source code is under src/ directory.
 
+Note that SHA-2 hash function implementation, src/sha256.c, is based
+on the original implementation by Dr. Brian Gladman.  See:
+
+  http://gladman.plushost.co.uk/oldsite/cryptography_technology/sha/index.php
+
 
 License
 =======
@@ -118,14 +234,13 @@ It is distributed under GNU General Public Licence version 3 or later
 (GPLv3+).  Please see src/COPYING.
 
 Please note that it is distributed with external source code too.
-Please read relevant licenses for external source code, too.
+Please read relevant licenses for external source code as well.
 
 The author(s) of Gnuk expect users of Gnuk will be able to access the
 source code of Gnuk, so that users can study the code and can modify
-if needed.  This doesn't mean person who has a USB Token by Gnuk
-should be able to acess everything on the Token, regardless of its
-protections.  Private keys, random bytes, and other information should
-be protected properly.
+if needed.  This doesn't mean person who has a Gnuk Token should be
+able to access everything on the Token, regardless of its protections.
+Private keys, and other information should be protected properly.
 
 
 External source code
@@ -133,40 +248,109 @@ External source code
 
 Gnuk is distributed with external source code.
 
-* ChibiOS_2.0.8/  -- ChibiOS/RT 2.0.8
+* chopstx/  -- Chopstx 1.3
 
-  Taken from http://chibios.sourceforge.net/
-  Note that CRLF is converted to LF in this repository.
-  We use ChibiOS/RT as the kernel for Gnuk.
+  We use Chopstx as the kernel for Gnuk.
 
-* polarssl-0.14.0/  -- PolarSSL 0.14.0
+  Chopstx is distributed under GPLv3+ (with a special exception).
 
-  Taken from http://polarssl.org/
-  We use PolarSSL for RSA computation, AES encryption/decryption
-  and SHA-1 computation.
 
-* STM32_USB-FS-Device_Driver/ -- a part of USB-FS-Device_Lib
-* Virtual_COM_Port/ -- a part of USB-FS-Device_Lib
+* polarssl/  -- based on PolarSSL 1.2.10 (now mbedTLS)
 
-  STM32F10x USB Full Speed Device Library (USB-FS-Device_Lib)
-  is a STM32F10x library for USB functionality.
+  Souce code taken from: http://polarssl.org/
 
-  I took Libraries/STM32_USB-FS-Device_Driver and 
-  Project/Virtual_COM_Port in STM32_USB-FS-Device_Lib distribution.
-  See http://www.st.com/ for detail.
+  We use PolarSSL for RSA computation, and AES encryption/decryption.
 
+  PolarSSL is distributed under GPLv2+.  We use PolarSSL under GPLv3
+  as our options.
 
-Host Requirements
-=================
+  The file include/polarssl/bn_mul.h is heavily modified for ARM
+  Cortex-M3.
+
+  The function rsa_private in polarssl/library/rsa.c is modified so
+  that it doesn't check T against N.  The function rsa_pkcs1_sign is
+  modified to avoid warnings in case of !POLARSSL_PKCS1_V21.
+
+  The functions rsa_pkcs1_verify and rsa_rsassa_pkcs1_v15_verify in
+  include/polarssl/rsa.h and polarssl/library/rsa.c are modified
+  (fixed) for last argument SIG, as the memory at SIG aren't modified
+  by those routines.
+
+  The constant POLARSSL_MPI_MAX_SIZE in include/polarssl/bignum.h is
+  modified for 2048-bit keys only Gnuk.
+
+  The function mpi_mul_hlp in library/bignum.c is modified for more
+  optimization for ARM Cortex-M3.  Functions mpi_montred, mpi_sub_hlp,
+  mpi_sub_abs, mpi_mul_mpi, mpi_montmul, and mpi_exp_mod are modified
+  to avoid side channel attacks.  Note that we don't use RSA-blinding
+  technique for Gnuk.  Function mpi_gen_prime and mpi_is_prime are
+  modified to use Fouque-Tibouchi method.  Function mpi_exp_mod is
+  modified to use new function mpi_montsqr for speed up.
+
+  The file library/aes.c is modified so that some constants can
+  go to .sys section.
+
+  The file include/polarssl/config.h are modified not to define
+  POLARSSL_HAVE_LONGLONG to avoid linking libgcc, to define
+  POLARSSL_AES_ROM_TABLES to have AES tables, not to define
+  POLARSSL_CIPHER_MODE_CTR, POLARSSL_FS_IO, POLARSSL_PKCS1_V21,
+  POLARSSL_SELF_TEST, and POLARSSL_PADLOCK_C, and only define
+  POLARSSL_GENPRIME when defined KEYGEN_SUPPORT.
+
+
+USB vendor ID and product ID (USB device ID)
+============================================
+
+When you have a vendor ID and assign a product ID for Gnuk, edit the
+file GNUK_USB_DEVICE_ID and add an entry for yours.  In this case,
+please contact Niibe, so that it is listed to the file in the official
+release of the source code.
 
-For GNU/Linux, libccid version >= 1.3.11 is required.
-libccid version == 1.3.9 is known not working well by the issue [r4235].
+When you are modifing Gnuk and installing the binary to device, you
+should replace the vendor string and serial number to yours (in the
+file GNUK_USB_DEVICE_ID and SERIALNO of the script of src/configure),
+so that users can see it's not by original vendor, and it is modified
+version.
 
-I think that it should not be requirment but the kernel version of my use is:
-Linux version 2.6.32-5-686 (Debian 2.6.32-18) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Sat Jul 24 02:27:10 UTC 2010
+FSIJ allows you to use USB device ID of FSIJ (234b:0000) for devices
+with Gnuk under one of following conditions:
 
-Linux 2.6.30 is known *NOT* working well with DEBUG option.
-Linux 2.6.24 is known working well with DEBUG option.
+  * For everyone for experimental purpose:
+
+    - You must not distribute a binary with FSIJ's USB device ID, but
+      must use the binary by yourself only for your experiment.  Note
+      that "Distributing binary" includes distributing a device which
+      holds the binary.
+
+  * For general individuals:
+
+    - You must use your Gnuk device with a card serial number which is
+      *not* by FSIJ.  Easy one would be a card serial number generated
+      by chip unique ID.
+
+  * For individuals with explicit permission from FSIJ.
+
+    - You should have an assigned card serial number by FSIJ,
+      please use that number for your device.
+      (There a file 'GNUK_SERIAL_NUMBER' in the official release.)
+
+FSIJ could give companies or business entities "second source
+manufacturer" license to use USB device ID of FSIJ for devices with
+unmodified version of Gnuk, provided they support Free Software and
+respect users' freedom for computing.  Please ask FSIJ for the
+license.
+
+Otherwise, companies which want to distribute Gnuk devices, please use
+your own USB vendor ID and product ID.  Please replace vendor string
+and possibly product string to yours, when you modify Gnuk.
+
+
+Host Requirements
+=================
+
+For GNU/Linux, PC/SC service is an option, you can use GnuPG's
+internal CCID driver instead.  If you chose using PC/SC service,
+libccid version >= 1.3.11 is recommended for GNU/Linux.
 
 
 How to compile
@@ -174,7 +358,15 @@ How to compile
 
 You need GNU toolchain and newlib for 'arm-none-eabi' target.
 
-See http://github.com/esden/summon-arm-toolchain/ for preparation of
+On Debian we can install the packages of gcc-arm-none-eabi,
+gdb-arm-none-eabi and its friends.  I'm using:
+
+       binutils-arm-none-eabi  2.28-4+9+b2
+       gcc-arm-none-eabi       15:5.4.1+svn241155-1
+       gdb-arm-none-eabi       7.12-6+9+b2
+       libnewlib-arm-none-eabi 2.4.0.20160527-2
+
+Or else, see https://launchpad.net/gcc-arm-embedded for preparation of
 GNU Toolchain for 'arm-none-eabi' target.
 
 Change directory to `src':
@@ -183,13 +375,18 @@ Change directory to `src':
 
 Then, run `configure':
 
-  $ ./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.
+
 
-Type:
+Then, type:
 
   $ make
 
-Then, we will have "gnuk.elf".
+Then, we will have "gnuk.elf" under src/build directory.
 
 
 How to install
@@ -198,62 +395,36 @@ How to install
 Olimex STM32-H103 board
 -----------------------
 
-If you are using Olimex JTAG-Tiny, type following to invoke OpenOCD:
+If you are using Olimex JTAG-Tiny, type following to invoke OpenOCD
+and write "gnuk.elf" to Flash ROM:
 
-  $ openocd -f interface/olimex-jtag-tiny.cfg -f board/olimex_stm32_h103.cfg
+  $ openocd -f interface/ftdi/olimex-jtag-tiny.cfg \
+            -f board/olimex_stm32_h103.cfg \
+            -c "program build/gnuk.elf verify reset exit"
 
-Then, with another terminal, type following to write "gnuk.elf" to Flash ROM:
+Command invocation is assumed in src/ directory.
 
-  $ telnet localhost 4444
-  > reset halt
-  > flash write_image erase gnuk.elf
-  > reset
-  > exit
-  $ 
-
-
-STM8S Discovery Kit
--------------------
-
-If you are using FTDI-2232D module and the connection is standard, type:
-
-  $ openocd -f interface/openocd-usb.cfg -f target/stm32.cfg
-
-Initially, the flash ROM of the chip is protected.  you need to do:
-
-  $ telnet localhost 4444
-  > reset halt
-  > stm32x unlock 0
-  > reset
-  > shutdown
-  $ 
-
-and re-connect the board.  Note that power-off / power-on sequence is
-required to reset flash ROM.
-
-Then, invoke OpenOCD again and telnet to connect OpenCD and write
-image as above example of Olimex STM32-H103.
 
+Flying Stone Tiny 01
+--------------------
 
-CQ STARM
---------
+If you are using Flying Stone Tiny 01, you need a SWD writer.
 
-Put jumper for J6 to enable DfuSe.  Connecting the board, and type:
+OpenOCD 0.9.0 now supports ST-Link/V2.  We can use it like:
 
-  # cd ../tool
-  # ./dfuse.py ../src/gnuk.hex
+  $ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg \
+            -c "program build/gnuk.elf verify reset exit"
 
-Then, remove the jumper and reset the board.
 
 
-STBee and STBee Mini
---------------------
+STBee
+-----
 
 Reset the board with "USER" switch pushed.  Type following to write
 to flash:
 
   # cd ../tool
-  # ./dfuse.py ../src/gnuk.hex
+  # ./dfuse.py ../src/build/gnuk.hex
 
 Then, reset the board.
 
@@ -261,59 +432,63 @@ Then, reset the board.
 How to protect flash ROM
 ========================
 
-Invoke your OpenOCD and type:
+To protect, invoke OpenOCD like (for FST-01):
 
-  $ telnet localhost 4444
-  > reset halt
-  > stm32x lock 0
-  > reset
-  > shutdown
+  $ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg \
+            -c init -c "reset halt" -c "stm32f1x lock 0" -c reset -c exit
 
 After power-off / power-on sequence, the contents of flash ROM cannot
 be accessible from JTAG debugger.
 
-Note that it would be still possible for some implementation of DfuSe
-to access the contents.  If you want to protect, killing DfuSe and
-accessing by JTAG debugger is recommended.
+Unprotecting is:
 
+  $ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg \
+            -c init -c "reset halt" -c "stm32f1x unlock 0" -c reset -c exit
 
-How to configure
-================
+Upon unprotection, flash is erased.
 
-You need python and PyUSB (python-usb package in Debian).
+Note that it would be still possible for some implementation of DfuSe
+to access the contents, even if it's protected.  If you really want to
+protect, killing DfuSe and accessing by JTAG debugger is recommended.
 
-(1) In the 'src' directory, type
 
-  $ make random_bits
+(Optional) Configure serial number and X.509 certificate
+========================================================
 
-In this process, it takes time for the command of
+This is completely optional.
 
-   dd if=/dev/random bs=1 of=random_bits count=1024
+For this procedure, you need python and pyscard (python-pyscard
+package in Debian) or PyUSB 0.4.3 (python-usb package in Debian).
 
-Don't just wait, but do some other works on your PC.
-/dev/random needs entropy to finish.
+(1) [pyscard] Stop scdaemon
+    [PyUSB] Stop the pcsc daemon.
 
-(2) Stop the pcsc daemon.
+If scdaemon is running, please kill it, or you will get "Smartcard
+Exception" by "Sharing violation".
 
-  # /etc/init.d/pcscd stop
+  $ gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye
 
-(3) Write the random bits to the device
+In case of PyUSB tool, you need to stop pcscd.
 
-Connect your board to USB port of your PC.  And invoke gnuk_put_binary.py:
+  # /etc/init.d/pcscd stop
 
-  # ../tool/gnuk_put_binary.py -r random_bits random_bits: 1024
 
-(4) [Optional] Write fixed serial number
+(2) [Optional] Write fixed serial number
 
 If you use fixed serial number in the file 'GNUK_SERIAL_NUMBER', you can do:
 
-  # EMAIL=<YOUR-EMAIL-ADDRESS> ../tool/gnuk_put_binary.py -s ../GNUK_SERIAL_NUMBER 
+  $ EMAIL=<YOUR-EMAIL-ADDRESS> ../tool/gnuk_put_binary_usb.py -s ../GNUK_SERIAL_NUMBER
+  Writing serial number
+  ...
 
-(5) [Optional] Write card holder certificate
+(3) [Optional] Write card holder certificate
 
 If you have card holder certificate binary file, you can do:
 
-  # ../tool/gnuk_put_binary.py ../../<YOUR-CERTIFICATE>.bin 
+  $ ../tool/gnuk_put_binary_usb.py ../../<YOUR-CERTIFICATE>.bin
+  ../../<YOUR-CERTIFICATE>.bin: <LENGTH-OF-YOUR-CERTIFICATE>
+  Updating card holder certificate
+  ...
 
 
 How to run
@@ -331,52 +506,38 @@ virtual COM port by:
 and you will see debug output of Gnuk.
 
 
-Libccid fix needed
-------------------
+Testing Gnuk
+------------
 
-For libccid (< 1.4.1), we need following change:
+Type following command to see Gnuk runs:
 
---- /etc/libccid_Info.plist.dpkg-dist  2009-07-29 06:50:20.000000000 +0900
-+++ /etc/libccid_Info.plist    2010-09-05 09:09:49.000000000 +0900
-@@ -104,6 +104,7 @@
-       <key>ifdVendorID</key>
-       <array>
-+              <string>0x234B</string>
-               <string>0x08E6</string>
-               <string>0x08E6</string>
-               <string>0x08E6</string>
-@@ -237,6 +238,7 @@
-       <key>ifdProductID</key>
-       <array>
-+              <string>0x0000</string>
-               <string>0x2202</string>
-               <string>0x3437</string>
-               <string>0x3438</string>
-@@ -370,6 +372,7 @@
-       <key>ifdFriendlyName</key>
-       <array>
-+              <string>FSIJ USB Token</string>
-               <string>Gemplus Gem e-Seal Pro</string>
-               <string>Gemplus GemPC Twin</string>
-               <string>Gemplus GemPC Key</string>
-------------------
+  $ gpg --card-status
 
-This entry has been added into libccid 1.4.1 already ([r5425]).
 
+Besides, there is a functionality test under test/ directory.  See
+test/README.
 
-Testing Gnuk
-------------
 
-Try following to see Gnuk runs:
+Personalize the Token, import keys, and change the password
+-----------------------------------------------------------
 
-  $ gpg --card-status
+You can personalize the token, putting your information like: Name,
+Login name, Sex, Languages, URL.  To do so, GnuPG command is:
+
+  $ gpg --card-edit
+
+Note that the factory setting of user password is "123456" and admin
+password is "12345678" as the specification.
 
+It is recommended to create your keys on your computer, and import
+them to Gnuk Token.  After you create your keys (they must be 2048-bit
+RSA), you can import them.
 
-For more, see doc/DEMO.
+Gnuk supports key generation, but this feature is young and should be
+considered experimental.
 
+For detail, please see documentation under doc/.  You can see the HTML
+version at: http://www.fsij.org/doc-gnuk/
 
 
 How to debug
@@ -391,6 +552,10 @@ Inside GDB, we can connect OpenOCD by:
 
   (gdb) target remote localhost:3333
 
+or
+
+  (gdb) target extended-remote localhost:3333
+
 
 You can see the output of PCSCD:
 
@@ -402,28 +567,59 @@ You can observe the traffic of USB using "usbmon".  See the file:
 linux/Documentation/usb/usbmon.txt
 
 
-Read-only Git Repository
-========================
+Firmware update
+===============
+
+See doc/note/firmware-update.
+
+
+Git Repositories
+================
+
+Please use: https://anonscm.debian.org/cgit/gnuk/gnuk/
 
 You can get it by:
+    $ git clone git://anonscm.debian.org/gnuk/gnuk/gnuk.git
+
+It's also available at: www.gniibe.org
+You can browse at: http://git.gniibe.org/gitweb?p=gnuk/gnuk.git;a=summary
+
+I put Chopstx as a submodule of Git.  Please do this:
 
-  $ git clone http://www.gniibe.org/git/gnuk.git/
+    $ git submodule update --init
+
+Gnuk 1.0 uses ChibiOS/RT, and then, we have migrated from to Chopstx
+in the development phase of Gnuk 1.1.  If you have old code of
+ChibiOS/RT, you need:
+
+    Edit .git/config to remove chibios reference and
+    $ git rm --cached chibios
 
 
 Information on the Web
 ======================
 
-Please see: http://www.fsij.org/gnuk/
+Please visit: http://www.fsij.org/gnuk/
+
+Please see the FST-01 support pages:
+
+    https://www.gniibe.org/category/fst-01.html
+
+Please consider to join Gnuk-users mailing list:
+
+    https://lists.alioth.debian.org/mailman/listinfo/gnuk-users
 
 
 Your Contributions
 ==================
 
 FSIJ welcomes your contributions.  Please assign your copyright
-to FSIJ (if possible).
+to FSIJ (if possible), as I do.
 
 
 Foot note
 ==========
+
 * NUK(R) is a registered trademark owend by MAPA GmbH, Germany.
 --