coelner/gnuk
1
0
Fork 0
mirror of https://salsa.debian.org/gnuk-team/gnuk/gnuk.git synced 2024-09-20 02:40:08 +00:00
Code Issues Packages 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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
ChangeLog
View File

@ -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.

6
NEWS
View File

@ -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.

40
README
View File

@ -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:

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

7
src/Makefile.in
View 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) \

13
src/main.c
View 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)

3
src/usb_desc.c
View 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,

21
src/usb_endp.c
View File

@ -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);
}

2
tool/openocd-script/lock.tcl
View File

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

2
tool/openocd-script/options_read.tcl
View File

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

2
tool/openocd-script/unlock.tcl
View File

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

2
tool/openocd-script/write.tcl
View File

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