Mailing List Archive: GnuPG: devel

FSIJ USB Token version 2 and Gnuk

Index | Next | Previous | View Threaded

gniibe at fsij

Sep 5, 2010, 11:07 AM

Post #1 of 5 (864 views)
Permalink

FSIJ USB Token version 2 and Gnuk

Hi there,

In 2008, we tried USB Token implementation for GnuPG with Atmel AVR.
It worked a little. It was 8-bit processor with no USB controller
and it was not for real use.

This year, I am trying to build a new version with STM32. I named
the software "Gnuk", and initial version is at:

http://www.gniibe.org/oitoite/gnuk/gnuk-0.0.tar.gz

It uses ChibiOS/RT, and uses polarSSL for RSA computation.

For hardware, I am using STM32-H103 board by Olimex:

http://www.olimex.com/dev/stm32-h103.html

Currently, it only supports RSA 2048-bit digital signature.

With Gnuk, I am learning OpenPGP card protocol version 2.

Today, I just put a tar ball. We will have Git repository soon.

Enjoy,
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

gniibe at fsij

Sep 12, 2010, 8:05 PM

Post #2 of 5 (787 views)
Permalink

Re: FSIJ USB Token version 2 and Gnuk [In reply to]

2010-09-06 03:07, NIIBE Yutaka wrote:
> This year, I am trying to build a new version with STM32. I named
> the software "Gnuk"
[...]

Now, we have a web page at: http://www.fsij.org/gnuk/
Read-only Git: http://www.gniibe.org/git/gnuk.git/

And I released version 0.2 today. I think that it is
somewhat usable now.

Enjoy,
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Sep 15, 2010, 11:13 AM

Post #3 of 5 (781 views)
Permalink

Re: FSIJ USB Token version 2 and Gnuk [In reply to]

On Mon, 13 Sep 2010 05:05, gniibe [at] fsij said:

> Now, we have a web page at: http://www.fsij.org/gnuk/
> Read-only Git: http://www.gniibe.org/git/gnuk.git/

I have this version now running using
openocd -f interface/neodb.cfg -f board/olimex_stm32_h103.cfg
.

I try to use it with GnuPG's internal CCID driver ("scdaemon
--debug-ccid-driver --server"). This requires to ignore the test on
"Auto configuration based on ATR" in dwFeatures. The problem now is a
ERR01 from gnuk due to an unexepcted state - on the scdaemon side this
is an usb_bulk_read_error. Quite some time passed since I wrote the
internal driver and it is possible it does something which is not
allowed by the USB specs. gnuk seems to be a nice tool to figure out
such problems.

BTW, does anyone know how to restrict openocd to listen for the telnet
connection only on localhost?

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Sep 15, 2010, 12:00 PM

Post #4 of 5 (784 views)
Permalink

Re: FSIJ USB Token version 2 and Gnuk [In reply to]

Hi,

I looked into the problem with the GnuPG'c CCID driver and found this:

DBG: ccid-driver: PC_to_RDR_IccPowerOn:
DBG: ccid-driver: dwLength ..........: 0
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 1
DBG: ccid-driver: bPowerSelect ......: 0x00 (auto)
DBG: ccid-driver: [0008] 00 00

We sent the power on command

DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 12
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 1
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 3B 94 11 81 31 FE
DBG: ccid-driver: [0016] 55 46 53 49 4A 88

We received the ATR as response to the power on command.

DBG: ccid-driver: PC_to_RDR_GetParameters:
DBG: ccid-driver: dwLength ..........: 0
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 2
DBG: ccid-driver: [0007] 00 00 00

We sent a GetParameters command to gnuk. This is not implemented and on
the debug channel we get "ERR03". gnuk puts itsself back into the init
state and did not sent and error response.

DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable
DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable
DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable
DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable

Thus GnuPG's try to read the response fails at the USB level....

DBG: ccid-driver: GetParameters failed

and finally concludes that GetParameters failed. Because it does not
know that gnuk is now in the init state again and all further commands
result in "ERR01" (invalid command for the init state). I see a line
with "6c" before the first "ERR01", though.

I am not sure whether GetParameters must be implemented, I would ned to
study the specs again. In any case I suggest to return a proper error
response.

What we can do in GnuPG's CCID driver is to issue a PowerOn command
after an USB read failure. I hesitated to do this because it resets the
card and a few read errors may happen from time to time without bad
consequences.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

gniibe at fsij

Sep 15, 2010, 5:19 PM

Post #5 of 5 (779 views)
Permalink

Re: FSIJ USB Token version 2 and Gnuk [In reply to]

Hi,

Thanks for testing Gnuk.

The document I read was:

http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_USB-ICC_ICCD_rev10.pdf

I think that this is a subset of CCID specification.

I read it as ICCD implementation allow to implement only
three kinds of interactions.

=====================================================
Section# PC->Target Target->PC
-----------------------------------------------------
6.1.1.1 PC_to_RDR_IccPowerOn RDR_PC_DataBlock
6.1.1.2 PC_to_RDR_IccPowerOff RDR_PC_SlotStatus
6.1.1.3 PC_to_RDR_XfrBlock RDR_PC_DataBlock
-----------------------------------------------------

I don't know how an implementation should behave for unsupported
commands.

Let me think about the handling of unsupported commands. I think
that there is better way than ignoring.

Werner Koch wrote:
> DBG: ccid-driver: PC_to_RDR_GetParameters:
> DBG: ccid-driver: dwLength ..........: 0
> DBG: ccid-driver: bSlot .............: 0
> DBG: ccid-driver: bSeq ..............: 2
> DBG: ccid-driver: [0007] 00 00 00
>
> We sent a GetParameters command to gnuk. This is not implemented and on
> the debug channel we get "ERR03". gnuk puts itsself back into the init
> state and did not sent and error response.
>
> DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable
> DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable
> DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable
> DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable
>
> Thus GnuPG's try to read the response fails at the USB level....

Or, it would be easy for Gnuk to just implement GetParameters.

In fact, Gnuk supports more commands, so that it works well with
libccid implementation. Specifically, it supports:

PC_to_RDR_GetSlotStatus RDR_to_PC_SlotStatus
PC_to_RDR_SetParameters RDR_to_PC_Parameters

Besides, it is known that libccid sends CCID class specific request of
GET_DATA_RATES to control pipe (Endpoint 0), which Gnuk ignores.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads