Re: [opensc-devel] Docs/Specs on ACLs / security attributes?

[Peter Koch]

Hi Peter

I am trying to extend openpgp-tool to load data to the various writable DOs,
> and - if possible - I want it to determine automatically the permissions of
> the (emulated) files using standard interfaces, i.e. security attributes or
> preferably ACLs. As the file system on openPGP cards only is emulated using
> opensc, I need to emulate these data structures too.
>
> I searched the net, but did not get anything that that really helped (I
> guess,
> I did not know/ use the correct search terms ;-)
>
> I found that ISO 7816-9 should contain info on security attributes, but I
> am
> not really keen on paying ~€60 for this information alone.
>

Have a look at "Security Attributes" in ISO 7816-4 and table
"Access mode byte for EFs".

You may either use compact or expanded form to describe your access rules.
When those DOs are selected I would return a FCP with tag A0
which should contan two access mode bytes (one for reading
and one for writing) each followed by security condition bytes.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] OpenPGP card / Cryptostick - current status???

[Peter Koch]

Hi Peter

> But changing the contents of DOs on an OpenPGP card is exactly
> > what the gpg administration tools do, so why reimplementing this into
> > pkcs15-init
> Because it
> * looks possible ;-)
> * helps to better understand PC/SC, opensc, gpg, ...
> * is fun
> * may improve opensc's PKCS#* support for OpenPGP cards
> * ...
>

I did not know that the pkcs15-init routines are used by opensc-pkcs11.
So I was wonderung why Quân was trying to extend the functionality
of the pkcs15-init executable. In the meantime I understood what he
is trying to do


>  > And I'm afraigth that those things that "gpg --edit-card" cannot do
> > are impossible to do.
> How can one write a certificate to an OpenPGP card using gpg?
>

gpg does not use certificates so you cannot store a cert into
an OpenPGP card with gpg. I use my own PKCS#11-library
(available at www.smartcard-auth.de) and download the cert with
Firefox. Firefox will then store the certifiate into my Cryptostick.


> What about the DOs 0101 - 0104?
>

These are DOs that are not used by gpg. Unfortunately the maximal
length of these DOs is 254 bytes. Otherwise one could use then
to store additional certificates. When TrueCrypt is configured with
my OpenPGP PKCS#11-library I'm using one of these DOs to
store the TrueCrypt key.

I consider  Quân's goal a very honorable one.
>

So do I


> Even if e do not reach 100% compatibility, his work should be honored.
>

Absolutely right, My only intention was to start a discussion about the
direction Quân should take.

 > Peter
> Dito ;-)
>
Dito :-)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] CRYPTOMATE64

[Peter Koch]

Hi

2012/5/23 NdK 

> Someone already tested that token? It's the only one I could find that
> handles RSA4096...
>

So does the OpenPGP card and the CryptoStick (which contains that card)

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] OpenPGP card / Cryptostick - current status???

[Peter Koch]

Hi Quân

I still don't understand what you are trying to do - maybe you can
explain that in more detail:

The purpose of pkcs15-init is to create a PKCS#15 filesystem layout
on a card.

The purpose of a pkca15-emulation routine is to make OpenSC believe
that a card has a PKCS#15 filesystem which in reality does NOT
have such a layout.

We have such an emulation for OpenPGP cards and OpenPGP cards
don't have a PKCS#15 layout and there is no way to create such a
layout on an OpenPGP card due to the lack of a CREATE EF/DF/DO
command.

So the only thing pkcs1-init might do is to change the contents of certain
already existing DOs on an OpenPGP card. And this might happen via
emulated UPDATE BINARY commands (which would do PUT DATA instead).

But changing the contents of DOs on an OpenPGP card is exactly
what the gpg administration tools do, so why reimplementing this into
pkcs15-init

And I'm afraigth that those things that "gpg --edit-card" cannot do
are impossible to do.

You cannot create a private key file on an OpenPGP card. There are
3 of them already on every OpenPGP card and the only thing you can
do is to replace their contents.

Same situation with certificates: You cannot create them. There's one
DO on an OpenPGP card meant to store one certificate. You can
replace its content with a PUT DATA but I don't see any possibility
to create additional certificates.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] OpenPGP card / Cryptostick - current status???

[Peter Koch]

Hi

Early this year I was asked by the German Privacy Foundation
wether I was willing to enhance OpenSC support for their
CryptoStick.
http://www.crypto-stick.com/2011/opensc-pkcs11-driver-development

I wrote a PKCS#11-library for OpenPGP cards in 2010 so I have
some experience with this kind of card. But I did not have
enough time to do this job and I was unsure wether full OpenSC
support for OpenPGP card was passible or not.

Now Nguyễn Hồng Quân is trying to do this and I'm not
sure wether he is going into the right direction. So my suggestion
is to discuss the right direction first here on the mailing list.

Peter Marshall seems to have written most of the current OpenPGP
driver and Jan Suhr from German Privacy Foundation told me that
Martin Paljak already tried to enhance the driver.

Could you give us some information what the status of OpenPGP
support is right now.

Here are my own impressions - if they are wrong, please correct me:

1: OpenPGP cards do NOT have a filesystem like other smart cards.
Instead of storing informations in EFs which are located in DFs an
OpenPGP card stores information in Data Objects. Here my conclusion
is: Without EFs and DFs and in particular without commands to
create EFs and DFs pkcs15-init does not make any sense.

2: The current driver emulates SELECT and READ BINARY APDUs
by reading from the corresponding Data Objects. I believe this
was done in order to emulate a (read only) PKCS#15 file layout.
If that was true - is there any hope to extend this emulation?

3: What features are missing in the current implementation and
what bugs should be fixed?

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] flex.profile missing and PIN-EIntry broken

[Peter Koch]

Hi

I just tried to erase my old Cryptoflex card an recreate a PKCS#15-structure
under Windows.

First problem was: flex.profile was missing - here's the relevant debug
output from pkcs15-init -Cvvv

2012-05-06 10:57:54.577 Trying profile file C:\Programme\OpenSC
Project\OpenSC\profiles\pkcs15.profile
2012-05-06 10:57:54.577 profile C:\Programme\OpenSC
Project\OpenSC\profiles\pkcs15.profile loaded ok
2012-05-06 10:57:54.577 [pkcs15-init] profile.c:380:sc_profile_load:
returning with: 0 (Success)
2012-05-06 10:57:54.587 [pkcs15-init] profile.c:327:sc_profile_load: called
2012-05-06 10:57:54.587 Using profile directory 'C:\Programme\OpenSC
Project\OpenSC\profiles'.
2012-05-06 10:57:54.587 Trying profile file C:\Programme\OpenSC
Project\OpenSC\profiles\flex.profile
2012-05-06 10:57:54.598 profile C:\Programme\OpenSC
Project\OpenSC\profiles\flex.profile loaded ok
2012-05-06 10:57:54.598 [pkcs15-init] profile.c:373:sc_profile_load:
returning with: -1201 (File not found)
2012-05-06 10:57:54.598 Failed to load profile 'flex': File not found
2012-05-06 10:57:54.608 [pkcs15-init] pkcs15-lib.c:374:sc_pkcs15init_bind:
Load profile error: -1201 (File not found)
Couldn't bind to the card: File not found

So I copied flex.profile (and some other profiles which were also missing)
into
the profiles-directory.

Next problem: pkcs15-init -C tells me it cannot read the PIN:

C:\Programme\OpenSC Project\OpenSC\tools>pkcs15-init -C
Using reader with a card: SCM Microsystems Inc. SPRx32 USB Smart Card
Reader 0
Failed to read PIN: Not supported
Failed to create PKCS #15 meta structure: Generic PKCS#15 initialization
error

Debug-output does not help but there seems to be a ticket and a fix.

Is this ticket #402: http://www.opensc-project.org/opensc/ticket/402 ?

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] APDU to verify Admin PIN

[Peter Koch]

Hi Nguyễn Hồng Quân

Since you are trying to change the preferred language with a
PUT DATA command I assume you are using an OpenPGP card

OpenPGP cards use ASCII coding of PINs so the correct APDU
to verify your admin PIN (assuming its value is the default 12345678)
is

00 20 00 83 08 31 32 33 34 35 36 37 38

How about using gnupg and the "gpg --card-edit" command? Would
be much easier than using PUT DATA apdus in opensc-explorer.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Pinpad, TCOS card

[Peter Koch]

Hi Martin!

2011/7/18 Martin Paljak 

> > Some reader expect just 4 bytes (CLA INS P1 P2) without Le. Some other
> > readers insist on getting a 0-Le byte. And very few readers handle both
> cases.
>
> This should be tested and documented if possible. Creating conditional
> reader-specific code is probably inevitable.
>

Maybe Ludouvic can add this information to his CCID reader matrix
http://pcsclite.alioth.debian.org/ccid/iManufacturer.html in the
limitation column

 > And they should use better return codes than 6B:80 (no idea what this
> > SW-value is supposed to mean)
> This is from PC/SC v2 spec
>
> case 0x6B80: /* Wrong data in the buffer, rejected by firmware */
>

I was absolutely sure that all PC/SC v2 codes start with 64xx. But you
are right - there's one exception :-)

Since the Xiring people are using a correct error code chances are pretty
good that their readers do support the 4-byte APDU-template only.

I just checked my own code. I'm using the 4-byte APDU-template with
almost all readers and the 5-byte verion with only a few (broken) readers.

So maybe we should change this in OpenSC too.

Another idea: if a 5-byte template fails with the above SW 6B80 we could
try the 4-byte template as well. This would make Johannes happy and
would not brake working SPE support with other readers.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Pinpad, TCOS card

[Peter Koch]

Hi Johannes!

2011/7/15 Johannes Becker 

> Hello,
>
> I'm testing a new Firmware for the Xiring MyLeo card reader. It
> will support extended APDU. It works with a CardOS chip, but
> with a TCOS chip firefox displays quickly the small window asking
> you to enter the pin on the pinpad several times. You have no chance
> to do so and there is subsequently no connection to the web site.
>
> To help the Xiring developers, does anybody know how to find the crucial
> point in the log
>

Here it is:

Control TxBuffer: 1E 1E 02 00 00 10 06 02 FF 00 00 00 00 00 00 05 00 00 00
00 20 00 00 00
-> 00 69 14 00 00 00 00 39 00 00 00 00 1E 02 00 00 10 06 02 FF 00 00 00
00 00 00 00 20 00 00 00
<- 00 80 02 00 00 00 00 39 00 00 00 6B 80
Control RxBuffer: 6B 80

Your CardOS card has a fixed length PIN format while your TCOS card has a
variable length PIN format. The PC/SC standard is not precise when it comes
to secure PIN entry with avariable length PIN format.

Some reader expect just 4 bytes (CLA INS P1 P2) without Le. Some other
readers insist on getting a 0-Le byte. And very few readers handle both
cases.

OpenSC uses 5 bytes in the control buffer: 05:00:00:00 is the length
followed
by 00:20:00:00:00 with is CLA:INS:P1:P2:Le.

The OpenSC developers could change this to 04:00:00:00 - 00:20:00:00
and maybe your Xiring-reader will work then. But several other readers
will stop working with this modification, so I would not suggest to do this.

But you can try yourself. In function part10_build_verify_pin_block()
in file reader-pcsc.c (line 1309-1314) you will find

/* Copy data if not Case 1 */
if (data->pin1.length_offset != 4) {
pin_verify->abData[offset++] = apdu->lc;
memcpy(&pin_verify->abData[offset], apdu->data, apdu->datalen);
offset += apdu->datalen;
}

Just remove them and give it a try.

So please tell the Xiring developers to change their firmware such that
both versions are supported.

And they should use better return codes than 6B:80 (no idea what this
SW-value is supposed to mean)

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Static PKCS#11 for OpenPGP v.2

[Peter Koch]

Hi Adam

If you are looking for a standalone PKCS#11-library for
OpenPGP cards you may try the library that I wrote
for the CrytpStick http://www.privacyfoundation.de/crypto_stick/

The CryptoStick is a USB device with a builtin OpenPGP chip
so all software for the CryptoStick works with "normal"
OpenPGP cards as well.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Pinpad Dell Smartcard Keyboard TCOS 2

[Peter Koch]

2011/6/1 Martin Paljak 

> > Yes, it works on Linux. Windows is the problem. Maybe the fault is with
> the SCM Windows
> > driver.
>
> IIRC you need to very closely match the Windows driver and the device
> Firmware. It had byte ordering issues and I *think* the Windows driver
> requires the incorrect firmware, unless you manually change the driver
> version.
>

I remember that byte ordering problem. We are using firmware 5.10
with driver version 4.45 from Oct 19 2009 with our own software under
Windows XP. And with this combination SPE works well. I have not
tried OpenSC under Windows.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Pinpad Dell Smartcard Keyboard TCOS 2

[Peter Koch]

Hi

Actually I'm not sure if in case of unpadded PIN blocks, should the initial
> APDU prefix include CLA INS P1 P2 only or an additional 0x00 (which you
> refer to as empty Lc) or not ? IMHO CCID spec leaves room for interpretation
> there... I remember different behavior from different readers/cards and
> cards in different protocol mode.
>

My experience is that sending CLA INS P1 P2 without Lc works
with more readers than including Lc=0 in the controll buffer. Some
readers work with both versions (for example the SCM532) and some
others only work with one of the two interpretation of the CCID spec.

The Dell USB Smartcard Keyboard does not work with either version.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Pinpad Dell Smartcard Keyboard TCOS 2

[Peter Koch]

Hi,

we are using TCOS2 card for more than 7 years and our policy is
to only use smartcard readers with secure PIN entry. The CCID
standard improved things a lot but unfortunately only a few readers
have 100% correct implementations.

The Dell USB Smartcard Keyboard seems to support SPE only
if the VERIFY command has a fixed length.

TCOS does not need padding so OpenSC sends the following
control buffer to your reader:

> winscard_msg_srv.c:317:SHMProcessEventsContext() command CONTROL received
by client 10
> ifdhandler.c:1323:IFDHControl() ControlCode: 0x42330006,
usb:413c/2101:libhal:/org/freedesktop/Hal/devices
> /usb_device_413c_2101_noserial_if1 (lun: 0)
> Control TxBuffer: 1E 1E 02 00 00 10 06 02 00 00 00 00 00 00 00 05 00 00 00
00 20 00 00 00
> openct/proto-t1.c:571:t1_build() more bit: 0
> -> 00 69 14 00 00 00 00 3E 00 00 00 00 1E 02 00 00 10 06 02 00 00 00
00 00 40 05 00 20 00 00 00
> <- 00 80 06 00 00 00 00 3E 00 00 00 00 40 02 67 00 25
> Control RxBuffer: 67 00

The control buffers contains a 5-byte verify command, namely 00 20 00 00 00
and your card reader is supposed to add the PIN and replace the fifth byte
with the PIN length. So if you enter 1234567 on your pinpad the verify
command should be changed into 00 20 00 00 07 31 32 33 34 35 36 37.

This does NOT work with the Dell USB Smartcard Keyboard. It will only
add the PIN but does not change the PIN lenght. So the verify command
sent to your card will be 00 20 00 00 00 31 32 33 34 35 36 37 which
results in error code 67 00. Fortunately this does not reduce your cards
retry counter

All our TCOS cards have a 6 digit PIN so we use a verify command with
fixed PIN length, i.e. 00 20 00 00 06. We hardcoded this into our
software and only use this dirty hack if our software has detected a
Dell USB Smartcarc Keyboard.

Unfortunately OpenSC cannot do this as it does not know in advance what the
PIN length will be.

CardOS PINs are padded to a fixed length and there is no need to
replace a byte within the verify-APDU with the PIN length. Therefore
this problem does not happen with CardOS cards.

I have no idea why your SCM reader behaves different under Windows and
Linux. Does it have old firmware?

Could you produce debug-output and compare the Control TxBuffers that
are sent to your reader under WIndows and Linux.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] OpenSC now supports TCOS3 IdKey cards

[Peter Koch]

Hi

I just added support for IDKey cards (
http://www.telesec.de/tcos/LB_IDKey_100318_dt.pdf ).

If anybody out there is using this card with OpenSC (besides me)
please let me know wether it works or not.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] OpenSC 0.12.1 RC1

[Peter Koch]

2011/5/12 Johannes Becker 

> Am Freitag 29 April 2011 schrieb Martin Paljak:
>
> >
> > I froze r5409 [1] as OpenSC 0.12.1 RC1.
>
> It works with iceweasel (firefox) and  CardOS V4.3B
>
> It doesn't work with TCOS 2 .
> This the same with OpenSC 0.12.0, we discussed the
> problem without a solution last september and
> probably tracked it down to the missing
>
>  token flag: login required
>
> shown then by pkcs11-tool  -L
>

Johannes, could you please test with version 5508. TCOS2 should
work again.


> Now the command pkcs11-tool in OpenSC 0.12.1 RC1 doesn't work at all.
> You get
>
> $  pkcs11-tool -L
> error: Failed to load pkcs11 module
> Aborting.
>

I don't think this problem (pkcs11-tool cannot load module) has anything to
do
with the above TCOS2-problem. Does this problem happen with TCOS-cards
only? Maybe specifying the module path will helo, i.e.

pkcs11-tool --module /path/to/opensc-pkcs11.so -L

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] FOSDEM 2011: february 5th and 6th

[Peter Koch]

Hi Andreas and Jean-Michel!

> I always wanted to go to FOSDEM conference in Brussels, Belgium.
> > Next year the conference will be on 5th and 6th of february.
>
> > Maybe more people on this list are interested in going there
> > and meeting up, and maybe having a devroom, a talk, or whatever
> > other options we have?
>
> You can count on me.
>

You can count on me too.

Should we get a booth like we did on LinuxTag 2006 [1] ?

[1] http://www.opensc-project.org/opensc/wiki/ProjectHistory#LinuxTag2006

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release

[Peter Koch]

Hi Martin;

The TCOS driver marks the user PIN as unblocking PIN [3], which I believe is
> incorrect (only PUK should have the unblocking code flag set)
>
> The attached patch should fix this. Peter, please add your comment.
>

PKCS#15-spec says:

PinAttributes.pinFlags: This field signals whether the PIN:
> - is an unblockingPin (ISO/IEC 7816-8: resetting code), meaning
> that this PIN may be used for unblocking purposes, i.e. to reset
> the retry counter of the related authentication object to its initial
> value;
>

TCOS-cards have 4 PINs, i.e. PIN, PUK, PIN1 and PIN2. If PIN is blocked it
may by unblocked by PUK. If PIN1 or PIN2 are blocked they may be unblocked
by PIN. So PIN is both a regular PIN (i.e. protects certain objects) and an
unblockingPIN with respect to PIN1 and PIN2.

For this reason I set the unblocking-flag for PIN as PIN MAY be used to
unblock other PINs.

Of course it will do absolutely no harm if the unblocking-flag will be
removed from PIN.

pkcs15-tcos.c does not support  the newest TCOS3-cards [1] and I will commit
a new version this weekend. The new version will set the unblocking-flag for
PUK only.

[1]
http://www.opensc-project.org/pipermail/opensc-user/2010-July/004195.html

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release / PIN not asked

[Peter Koch]

Hi Johannes:

2010/9/9 Johannes Becker 

> Hello,
>
> now I have the opensc-debug logs for pkcs11-tool  -L with TCOS
>
> opensc version 0.11.13-1 gives
>  token flags:   login required, PIN initialized, token initialized
> http://www.uni-giessen.de/~g013/opensc/opensc-debug.0.11.13-1.log
>
> opensc version 0.12.0-svn-r4700 gives
>   token flags:   readonly, PIN pad present, token initialized
>
> http://www.uni-giessen.de/~g013/opensc/opensc-debug.opensc-0.12.0-svnr-4700.log
>

Has the problem been fixed with latest SVN (in particular with patch set
4722) ?

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] card->max_recv_size problem

[Peter Koch]

Hi Martin!

2010/9/13 Martin Paljak 

> > Should I set card->max_recv_size and card->max_send_size
> > in tcos_init()?
> >
> No. Sorry, this place was erroneously  left untouched and is fixed in SVN
> trunk. Please verify that it works as expected.
>

Not yet! I had to replace line 122 of iso7816.c
> assert(count <= card->max_recv_size);
by
> assert(count <= card->max_recv_size>0 ? card->max_recv_size : 256);

And then everything worked as expected.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] card->max_recv_size problem

[Peter Koch]

Hi!

tcos_init() does NOT set card->max_recv_size and therefore
some default value (i.e. 256) was used.

With current svn this does not work anymore. sc_read_binary()
checks wether count > card->max_recv_size and then tries
to read count bytes in chunks of card->max_recv_size.
If card->max_recv_size is 0 this fails.

Should I set card->max_recv_size and card->max_send_size
in tcos_init()?

This will fix the problem with TCOS-cards but there are other
drivers that do NOT set max_recv_size (i.e. card-cardos.c)

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] MyEID microSD

[Peter Koch]

Hi Andre!

Have a look at: http://www.certgate.com/index.php?id=71

Certgate was the first company that offered smart cards
built into microSD cards.

I got two testcards from certgate in 2008. One was java-based
and one contained a TCOS3-chip. They were planning to offer
an ifd-handler for linux. Since OpenSC has TCOS3 support this
microSD-card might work in combination with PCSClite and a
vendor supplied ifd-handler.

Giesecke & Devrient no offers microSD smart cards as well
but I have no idea what card operating system they use and
wether they support linux or not.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release / PIN not asked

[Peter Koch]

@Johannes:

> Apply this patch locally, and everything should work fine. BTW the
> unicard support was added by Peter Koch [1]. Maybe you want to contact
> him for an upstream patch.
>

pkcs15-tcos.c has not been modified for a long time (except some
minor cosmetic changes). So something else must have changed.

I just did a quick "grep LOGIN_REQUIRED *.c" and it seems that only
the WestCOS and OpenPGP emulations set LOGIN_REQUIRED
while all other emulation-routines don't.

If LOGIN_REQUIRED must now be set from within the emulation-routine
and if that was not necessary before then the LOGIN_REQUIRED flag
will be now missing for every card that has a pkcs15-emulation (except
WestCOS and OpenPGP).

So before adding

> +   p15card->flags |= SC_PKCS15_CARD_FLAG_LOGIN_REQUIRED;
>
in pkcs15-tcos.c (and all other emulation routines) we should investigate
why this wasn't necessary in 0.11.13

Unfortunately I have no testcard for which some of the other emulation
routines are used.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Aladdin eToken Pro w/PKCS15 (was Re: OpenPGP card v2)

[Peter Koch]

Hi David!

> Ok, thanks for the summary (depressing though it is).
>
> I'm beginning to suspect that for someone like myself who just wants to
> test NSS/sysdb interaction with external PKCS#11 modules, my best option
> is just to crawl back under my rock and write a sane PKCS#11 plugin for
> a TPM¹.
>
> Or failing that, to make the GnuPG v2 card work -- at least I have docs
> for that and "all" I have to do is try to get a clue about ISO7816,
> PKCS#15 and how the opensc stack fits together.

I just wrote a PKCS#11-library for the CryptoStick-people here in
germany ( http://www.privacyfoundation.de/crypto_stick/crypto_stick_english )
Since the CryptoStick is an OpenPGP-card soldered into a CCID USB-reader
this library will work for OpenPGP-cards too.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Fix Netkey SigG application

[Peter Koch]

Hi Christian,

You take care to push my patch or an improved one into opensc?
>

I fixed the incorrect PIN-IDs in trunk on last saturday.

We actually also own some TCOS3 2048 bit cards which are pretty useless
> for us until opensc supports secure messaging.
>
> Are there any plans to implement it ?
>

As far as I know there has been some discussion on the mailing
list about Secure messaging but nobody is working on this right now.

One could implement secure messaging within the TCOS signature
routine. OpenSC would then support the signature key of TCOS3
cards without having general SM-support. Of course this implementation
(creating a new secure channel for each sign-operation) would slow
down application that create multiple signatures.

So far there has been almost no interest in using the SigG-key of
TCOS3 cards with OpenSC. And I heard rumours that the next
TCOS-card will not have this "feature" anymore.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Fix Netkey SigG application

[Peter Koch]

Hi Christian

Somewhere between 0.11.4 and 0.11.8 the SigG application of
> "TeleSec GmbH" Netkey cards got broken.
>

Yes and this was due to an incorrecr renumbering of the PINs. The
SigG-key of both TCOS2 and TCOS3-cards are protected by PIN 5.

Both cards have 6 different PIN (PIN 1 - 6), but these PINs were incorrectly
given the following IDs: 1,2,3,4,6,7. No wonder OpenSC had problems
when trying to use the SigG-key after verification of PIN 5.

Sorry for any inconveniences this might have caused. And thanks
very much Christian for your testing an patching efforts.

By the way: OpenSC does not support the SigG-key of TCOS3-cards as
this key can used with secure messaging ONLY, And OpenSC does
not support SM yet. So I assume you are still using TCOS2-cards. But
all Signature-Law conforming 1024bit certificates should have expired
by now. So for my own curiosity: What are using the SigG-key on TCOS2
cards for?

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Active developers on opensc-project.org

[Peter Koch]

Hi Martin!

I'm maintaining the TCOS-driver and the PKCS#15-emulation for german
signature cards and some TCOS-based University cards. There was no need to
change the driver for about two years, but this doesn't mean that the
TCOS-driver is unmaintainted.

I therefore changed the Wiki-tags and removed my entry from the Emeritus
list.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Question / Searching Peter Koch

[Peter Koch]

Hi Jochen!

> in the passed there was a developer who got informations about the TUD 
> Smartcard projekt at the TU Darmstadt. I think his name was Peter Koch. 
> Please can he contact me, i am the successor of Ronny John at the 
> Smartcard projekt and have some Questions and Informations.
> 
> What about the TCOS 3 cards? will they be supported by opensc, the last 
> information on the wiki is 10month ago.

I extended the TCOS2-driver in december 2007 and OpenSC 0.11.5 
was the first version with full TCOS3-support. I also extended
the PKCS#15-emulation for NetKey E4 cards such that NetKey E4 V3
cards are supported as well. There's one limitation with
NetKey E4 V3 cards: the signature key from the SigG-application
can be used over a secure channel only. So you cannot use
this key until OpenSC has support for secure messaging.
But you can use all the other keys.

There were no TCOS-related changes within the OpenSC
source within the last year, so the wiki-information
is up to date.

Does the university of Damrstadt still use TCOS2-based
smart cards. Or did you switch to TCOS3 or are planning
to do so. If you are using a different card now you
may sent me a test-card and I will add OpenSC support
for your new card.

Peter Koch
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] test of German health card (eGK)

[Peter Koch]

Hi!

The german eGK specification does NOT specify a complete
card operating system but only a few commands. Every
card operating system that implements those commands
(among others) is eGK-compliant.

In order to support a card OpenSC must implement a
couple of basic commands and only some of them are
specified within the eGK spec.

So in order to support your card we must first know
what card operating system it is based on. My guess is
that you have a StarCos 3.0 based eGK. So in order
to support this specific eGK OpenSC needs a StartCos 3.0
driver first.

Right now there is no such driver and that's why OpenSC
tells you "unknown card".

To my knowlege none of the eGKs out there is based on
a card operating system that OpenSC has support for already.

But support for the card operating system of you eGK is
not enough. You would also need a driver for the layout of your
card (the so called PKCS#15 emulation). Since I know eGKs
and HBAs very well I'm willing to write such a driver.
But the first step must be to add support for the
unknown card operating system.

Peter

> Andreas wrote:
> p.s. you could look at http://smartcard-auth.de/download-de.html for a
> commercial software vor windows that works with eGK. if you need linux,
> maybe peter also has a linux version.

There is no eGK support right now. I will add this to my
authentication software as soon as someone is interested.
And so far nobody was.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Secure PIN Entry does not work

[Peter Koch]

Hi!

I'm trying to use the secure PIN entry with
a SPR 532. pcsclite version is 1.4.102, CCID
version is 1.3.8 (newest versions as of yesterday).

I do a SCardControl with SCARD_CTL_CODE(3400). The
SPR 532 can do a Verify Direct and a Modify Direct
command. After sending the Verify Direct command
the reader beeps, I can enter my PIN, the reader
acknowledges my PIN and the yellow LED will be on
permanently.

But the SCardControl call does not return immediately
after I pressed the OK-Button on my reader. Instead it
will wait for about 30 seconds and will then fail
with return code 80100016 which means:
"An attempt was made to end a non-existent transaction."
I have no idea why this happens. It happens with
other readers too.

I have attached a short test-program and full
pcscd-debug log. Maybe Ludovic knows what I'm
doing wrong.

By the way: This program works as expected under
windows.

Peter Koch


#include 
#include 
#include 
#include 

int main(){
SCARDCONTEXT hContext;
SCARDHANDLE hCard;
LONG ret;
DWORD i, ol, dw, spe_ctl_direct, state, proto, buflen, atrlen;
BYTE obuf[100], atr[32];
char buf[1000];
// char *reader="Cherry SmartTerminal ST-2XXX (0096) 00 00";
char *reader="SCM SPR 532 (54000669) 00 00";
#pragma pack(1)
struct {
BYTE  bTimeOut;
BYTE  bTimeOut2;
BYTE  bmFormatString;
BYTE  bmPINBlockString;
BYTE  bmPINLengthFormat;
WORD  wPINMaxExtraDigit;
BYTE  bEntryValidationCondition;
BYTE  bNumberMessage;
WORD  wLangID;
BYTE  bMsgIndex;
BYTE  bTeoPrologue[3];
DWORD ulDataLength;
BYTE  abData[200];
} data;
#pragma pack()

ret=SCardEstablishContext(SCARD_SCOPE_USER, NULL, NULL, &hContext);
printf("SCardEstablishContext()=%lX\n", ret);

ret=SCardConnect(hContext, reader, SCARD_SHARE_SHARED, 
SCARD_PROTOCOL_T1, &hCard, &dw);
printf("SCardConnect()=%lX, hCard=%lX\n", ret, hCard);

ret=SCardControl(hCard,SCARD_CTL_CODE(3400), NULL,0, 
obuf,sizeof(obuf),&ol);
printf("SCardControl()=%lX, ol=%lu\n", ret, ol);
for(i=spe_ctl_direct=0;i+5no 
PIN-length insertion)
  // Bit 3-0: Size of PIN-Block in byte
data.bmPINLengthFormat=0; // 000.0.0
  // Bit 7-5: RFU
  // Bit   4: Unit: 0=Bits, 1=Bytes
  // Bit 3-0: PIN-length position in APDU after 
Lc
data.wPINMaxExtraDigit=256*1+16; // min.max
data.bEntryValidationCondition=0x02; // 0.0.1.0
   // Bit 7-3: RFU
   // Bit   2: Timout occurred
   // Bit   1: Validation Key pressed
   // Bit   0: Max size reached
data.bNumberMessage =0xFF;
data.wLangID=0x0904;
data.bMsgIndex  =0;
data.bTeoPrologue[0]=0;
data.bTeoPrologue[1]=0;
data.bTeoPrologue[2]=0;

data.ulDataLength=0;
data.abData[data.ulDataLength++]=0x00;
data.abData[data.ulDataLength++]=0x20;
data.abData[data.ulDataLength++]=0x00;
data.abData[data.ulDataLength++]=0x00;

dw= (data.abData-&data.bTimeOut) + data.ulDataLength;
printf("Data"); for(i=0; i Here I enter my PIN, then nothing happens for about 30 seconds
SCardControl(23 bytes)=80100016, ol=0, SW=0604

 pcscdaemon.c:280:main() pcscd set to foreground with debug send to 
stderr
0063 debuglog.c:239:DebugLogSetLevel() debug level=debug
0035 debuglog.c:268:DebugLogSetCategory() Debug options: APDU
0755 pcscdaemon.c:498:main() pcsc-lite 1.4.102 daemon ready.
00118633 hotplug_libusb.c:476:HPAddHotPluggable() Adding USB device: 003:003
5129 readerfactory.c:1082:RFInitializeReader() Attempting startup of SCM 
SPR 532 (54000669) 00 00 using 
/usr/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so
0214 readerfactory.c:949:RFBindFunctions() Loading IFD Handler 3.0
0074 ifdhandler.c:1323:init_driver() Driver version: 1.3.8
0290 ifdhandler.c:1336:init_driver() LogLevel: 0x0003
0038 ifdhandler.c:1346:init_driver() LogLevel from LIBCCID_ifdLogLevel: 
0x0007
0271 ifdhandler.c:1356:init_driver() DriverOptions: 0x
0040 ifdhandler.c:81:IFDHCreateChannelByName() lun: 0, device: 
usb:04e6/e003:libusb:003:003
0067 ccid_usb.c:158:OpenUSBByName() Reader index: 0, Device: 
usb:04e6/e003:libusb:003:003
0493 ccid_usb.c:236:OpenUSBByName() Manufacturer: Ludovic Rousseau ([EMAIL 
PROTECTED])
0275 ccid_usb.c:246:OpenUSBByName() ProductString: Generic CCID driver
000

Re: [opensc-devel] A graphical PIN dialog for PKCS#11?

[Peter Koch]

Sorry - I did not read the OpenSC mailinglist for a while,
otherwise I could have informed you about my FireFox 2/3
experiences regarding smart cards and PIN-dialogs.

1) FireFox 2 always asks for a PIN before C_Login is
called. If CKF_PROTECTED_AUTHENTICATION_PATH is set FireFox 2
will ignore whatever PIN was entered and calls C_Login with pPin==NULL.
If CKF_PROTECTED_AUTHENTICATION_PATH is not set FireFox 2
feeds the entered PIN into C_Login.
FireFox 3 tries to do it the correct way. If
CKF_PROTECTED_AUTHENTICATION_PATH is not set it behaves
like FireFox 2 (ask for PIN then feed it into C_Login). If
CKF_PROTECTED_AUTHENTICATION_PATH is set FireFox 3 does
not ask for a PIN and immediately calls C_Login with pPin==NULL.
At the same time a seperate thread is started that displays a message
what requests the user to authenticate with the token by
whatever method the token may support (PIN-pad, fingerprint).
This is perfect behaviour, but unfortunately FireFox 3.0.1
crashes when C_Login returns and the separate thread is killed.
This bug will be fixed in a furure version (hopefully FireFox
3.0.2, if you cannot wait and need an unofficial version of
FireFox 3.0.1 without this bug - let me know).

2) FireFox (2 and 3) do not implement the re-authentication
method that is described in PKCS#11 V2.20 10.9 and it is
my impression that the Mozilla NSS team will not change this
is the near future. This means that any error code that
C_Sign returns will be fatal, even CKR_USER_NOT_LOGGED_IN.
But read on - you don't need this.

3) Every PKCS#11 application must be prepared that the
session state will change due to side effects of operations
that happen within other sessions that were opened with the
same token. Therefore FireFox will check the session state
before every cryptographic operation. If the session state
is either CKS_RO_PUBLIC_SESSION or CKS_RW_PUBLIC_SESSION
then C_Login will be called and if the Login is successfull
C_Login will have the side effect of changing the session
state changes to CKS_RO_USER_FUNCTIONS or CKS_RW_USER_FUNCTIONS
for all sessions that are open with the token in question.

What happens in your case is that using the private key
has the side effect of changing the session state back to
CKS_RO_PUBLIC_SESSION or CKS_RW_PUBLIC_SESSION. Before
FireFox will do the next cryptographic operation it will
check the session state by calling C_GetSessionInfo. FireFox
will then realize that a new C_Login is required and will
ask you for your PIN again.

So all you must do is to change the session state after
every signature operation.

This works for me. Some german signature cards have a
signature counter that require a PIN-verification every
100 signature operation. So I check the signature counter
after every cryptographic operation and whenever the
signature counter reaches 0 I do an implicit logout.

I have not tried this with the OpenSC PKCS11-library. But
calling C_Logout(hSession) from within C_Sign() for
certain cards should be easy to realize.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Externally generated keys

[Peter Koch]

Hi Marc:

> From the FAQ at http://www.opensc-project.org/faq.html 
> 
> "Can I store my ssh private key on a smart card?
> 
> "Most people prefer to use a smart card with a key that was generated on
> the card and cannot ever leave it. In fact everyone seems to do that. So
> while it might be technically possible to convert a private key in ssh
> format into pem format and then store it on a smart card, until now no
> one wrote such a code, so you can't. If you really need it, please ask
> on the mailing list"
> 
> 
> Is this to say the card cannot accept any externally generated private
> keys?

No, it just says that storing a private key that was generated by
OpenSSH (or PuTTY) cannot be stored into a smartcard with OpenSC
since OpenSC can only store keys on smartcards that were saved
in PEM- or DER-Format.

There are two possibilities:

1) Create a private key with OpenSSL. This key will be in PEM-format
and OpenSC will be able to store it into a smartcard. Also OpenSC
will be able to read the public key from your smartcard and store
it in either PEM-, DER- or SSH-format.

2) Create a private key with OpenSSH (or PuTTY). Convert this key
into PEM- or DER-format and store it into your smartcard with
OpenSC. Most likely you must write the conversion program yourself.

> I would be uncomfortable letting any closed-source application, such as
> firmware on a card, generate a key for me.  Even more so, as I read that
> many cards have no hardware random number generator and in essence
> generate keys from their serial numbers.  This feels like walking
> directly into a trap.

If you don't trust the key-generation mechanism within your smartcard
you should not use smartcards at all. If there were smartcards out there
that generate keys based on their serial number than those smartcards
will also have undocumented commands by which the NSA can read your
private key out of your smartcard. Such a card would be absolutely
useless. The only purpose of a smartcard is to protect your private
key and ensure that this key key can be used only WITHIN the card.

Of course you can ask your smartcard to create a couple of keys and
compare them. Please let us know if you own a smartcard that "generates"
the same key over and over.

> I am a "Global War on Terror" surveillee, and I am uncomfortably
> accustomed to being monitored for thinly veiled political reasons.
> 
> Another excellent reason for not generating a key on a card is that I
> cannot have a backup.  I can hide a backup key securely... that is, if
> the NSA didn't generate the key for me in the first place.

If you want a backup you MUST create your key outside your card (or
find the unddocumented commands by which you can read a private key
out of your card)

How about using the OpenPGP card. If you don't trust closed source
firmware than this card may be the right choice.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] eToken AKS support

[Peter Koch]

Hi Dmitry,

> I try to provide user logon on eToken AKS application.
> Token based on Cardos V4.2B. 

What kind of logon do you mean (ie. Windows-logon, SSH-logon, ...)

> Aladdin's utility eToken Property use EXTERNAL_AUTHENTICATE for this. 
> Utility send adpu GET_CHALLENGE "00 84 00 00 08" and 
> EXTERNAL_AUTHENTICATE "00 82 00 81 08 2D 42 BC F8 C1 65 A3 D5"
> 
> But I don't know how built EXTERNAL_AUTHENTICATE data.
> It's look like hashed pin + challenge response.
> But how correctly combine pin and challenge response, and which hash alg is 
> using?  
> 
> If I try simple ASCII VERIFY:
> 00 20 00 81 A0 30 31 32 33 34 35 36 37 38 39
> get error 0x6984 (BS Object has invalid format).

Have a look at the following thread on the OpenSC devel
mailing list (from december 2006):
http://www.opensc-project.org/pipermail/opensc-devel/2006-December/009396.html

Same problem ??

Aladdin does not protecet their private keys by a PIN
but uses a symmetric key instead. Therefore you must
use a GET_CHALLENGE/EXTERNAL_AUTHENTICATION-APDU instead of
a VERIFY-APDU.

This only happens if you are using an Aladdin eToken that
was formatted by the Aladdin-tools. If you format your
eToken with OpenSC your keys will be protected the
"normal" way.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] nightly snapshots missing

[Peter Koch]

Hi all

People asked me how they could download an OpenSC
version with TCOS3-support, which I added with
revision 3309.

I told them to download the latest nightly snapshot
but http://www.opensc-project.org/files/opensc/snapshots/ 
does not contain current versions. Seems like no
nightly snapshot ws built since verions 0.11.4 was released.

Can we create snapshots automatically again?

Can I create a snapshot manually from my local OpenSC
source tree and upload it into the snapshot directory.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] TCOS3 support - SM replated question

[Peter Koch]

Hi,

I just extended the TCOS driver. It's now supposed to
support both TCOS2 and TCOS3 cards.

I changed almost all TCOS-related stuff and pkcs15-tcos.c
is a complete rewrite of the old version. So chances are
pretty good that something does not work anymore.

I did some tests with my new TCOS3 card and some
of my old TCOS2 cards. Please let me know if you notice
a problem with one of your TCOS cards.

The new NetKey card has 5 different keys and one of then
(the one that conforms to the german signature law) can
be used only over a secure channel.

How should I preceed in order to support this key?

Right now I see only one possibility: implementing
the SM-stuff in tcos_compute_signature().

Are there any plans to add SM-support to OpenSC?

Peter
_
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! 
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] opensc-explorer, cat does not work with TCOS-cards

[Peter Koch]

Hi,

I'm working on the TCOS driver (support for new TCOS 3.0 cards)
and I noticed a problem with TCOS-cards in opensc-explorer. It
happens with both TCOS 2.0 and TCOS 3.0 cards.

cat 2f02  does not work and here's the relevant debug-output:


Outgoing APDU data [8 bytes] =
00 A4 00 00 02 2F 02 FF .€.../.ÿ

Incoming APDU data [2 bytes] =
6A 80 j.

unable to select file: Incorrect parameters in APDU

opensc-explorer tries to select the file with P1=00. With TCOS-cards this will
fail as P1=00 will only select 3F00 and requires Lc=0.

Why does opensc-explorer use a path with path->type=SC_PATH_TYPE_FILE_ID
instead of SC_PATH_TYPE_FROM_CURRENT which would make TCOS-cards happy?

Or must I change the TCOS-driver such that select-APDUs with P1=00 and
Lc>0 will be changed into P1=09.

Peter
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=0066

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Aladdin emulation

[Peter Koch]

Hi Chaskiel,

> I'd also like to confirm that there's no emulation for the aladdin 
> filestructure or anyone working on such. (my employer is considering 
> these devices, and windows/cisco vpn client compatibility will be 
> important)

There is no emulation in OpenSC for the filestructure that Aladdin
creates with their own middleware. Adding one would be relatively
easy, but there's another problem:

Aladdin does not protect their private keys by a PIN but use a
challenge response mechanism instead. So even if OpenSC would
know about the filstructure of an eToken you could not use it
without also knowing the details about the challenge response
mechanism.

Of course you can create an OpenSC filestructure on an Aladdin
eToken without erasing an already existing Aladdin filestructure.

Peter

PS: If you are interested in a PuTTY-version that supporte eToken
have a look at http://smartcard-auth.de/ssh-en.html
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] tcos encipherment

[Peter Koch]

> Question: what is limitation on size of pbData for successful decryption. 
> I know, what for successful encryption, size of pbData must be less of equal 
> max_in_size. On decryption for NetKey card max_in_size == 117 (ex_size == 
> 128,  
> RSA_PKCS1_PADDING_SIZE == 11), but if in RSA_public_encrypt *pdwDataLen > 
> 114, 
> then tcos decrypt adpu return error 0x6988 ("key object used for sm has 
> invalid 
> format").

With TCOS cards and 1024 bit keys your padding must be at least 11 bytes.
PKCS#1-padding will add another 3 bytes, i.e.

00   00 

Hence your data must contain no more than 128-11-3=114 bytes. If it
does not, then TCOS will respond with 6988.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] tcos encipherment

[Peter Koch]

> > How did you encrypt your data? Looks like a padding problem to me.
> > OpenSC assumes that you used PKCS#1-padding before you encrypted
> > your data. I'm not sure whether all keys on your SignTrust card
> > supports non-PKCS#1-padding. Let me know if you must decrypt
> > non-PKCS#1-padded data.
> 
> I encrypt data with OpenSSL. 
> 
> First, I create RSA object by d2i_RSAPublicKey then call
> RSA_public_encrypt with RSA_PKCS1_PADDING last parameter.
> Size of exit buffer obtain by RSA_size.
> 
> On decrypt operation, ADPU has first data byte "0x81", as I
> know it is indicate to use PKCS1 crypted data. 
> 
> I was testing this code on other cards (cardos and netkey).
> Cardos don't support PKCS#1-padding, so in exit buffer after
> decryption don't cut out pudding bytes (other problem :( ).
> But encrypt\decrypt operations on both cards complete successfully.

Seems that you know what you are doing :-)
If your code works with NetKey E4 cards then it MUST work with 
your SignTrust card too. Both cards are TCOS 2.0 cards and use the
same driver so I cannot imagine why a NetKey card should behave
different from a SignTrust card. But this might be a limitation of
my imagination.

Could you post the relevant parts of your code or send it to me.

I just tried the following script with my SignTrust card:

KEY=46
echo "Testdata" >cleartext
pkcs15-tool --read-public-key $KEY >pubkey.pem
openssl rsautl -encrypt -inkey pubkey.pem -pubin -in cleartext -out ciphertext
pkcs15-crypt --decipher --input ciphertext --key $KEY --pkcs1

Works with both key 46 and key 47. Does not work with key 45 since
key 45 is a signature-key and cannot do decryption-operations.

Could you try this with your SignTrust card and/or NetKey card.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] tcos encipherment

[Peter Koch]

> I try to decrypt ciphertext with Deutsche Post card (tcos).
> ATR: 3B BA 96 00 81 31 86 5D 00 64 05 7B 02 03 31 80 90 00 7D.
>
> Data encrypted by RSA, using OpenSSL with public key of Deutsche Post
> certificate.
>
> On decryption operation I have error on ADPU:
>
> ...
>
> transmitted: 00 22 C1 B8 03 84 01 80
> received: 90 00
>
> transmitted:
> 00 2A 80 86 81 81 5C C6 FA 52 75 C8 F4 21 6D 7D FA AB 17 AA 17 CE C8 30 2B 5D
> AC 54 09 F5 74 66 0C 4B 19 38 74 78 DA 5A 23 5A 01 C9 A3 81 78 32 A8 B4 87 24
> 30 AB 28 80 97 35 EF 9E EE 50 6A 6D BF F3 90 EC 50 8A 69 8E 8E C2 AB 20 6D DC
> 3A DF FD 3A C6 5F 84 9C 4F C9 99 8F 5E 8B D1 1C 3F 3B 50 C8 4F C3 CD 30 97 98
> 3C 1C CB 55 53 1E ED 16 24 FD 3C 0C 32 39 B2 0E EC 6A 2D A9 7B 27 AC 4D BD C1
> 63 E0 57 6A 80
> received: 69 88 ("SM data objects incorrect")
>
> ...
>
> What does it mean?

How did you encrypt your data? Looks like a padding problem to me.
OpenSC assumes that you used PKCS#1-padding before you encrypted
your data. I'm not sure whether all keys on your SignTrust card
supports non-PKCS#1-padding. Let me know if you must decrypt
non-PKCS#1-padded data.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] GET CHALLENGE / EXTERNAL AUTHENTICATE Problem

[Peter Koch]

Hi Nils

> sure that a normal pin is used (or is this a DES key which
> somehow needs to be enlarged to 64 bits) ?

Of course a key is needed to calculate the response. I assumed
that this key was caluclated from the PIN by just 0-padding it.

> > I have already tried stuff like
> >
> > echo -en '\x58\x4e\xb5\x6f\x6d\x9f\x13\xc5' |\
> > openssl enc -des-ede3-ofb -K 313233343536 -iv 0 |\
> > od -tx1
> >
> > with different cyphers. Unfortunately I don't know what IV-value
> > must be used. Any ideas?
>
> afaik this cannot work as the cardos m4.01a either uses public
> key cryptography or a MAC calculation for EXTERNAL AUTHENTICATE.
> As the response is 8 bytes long I would guess that a MAC
> algorithm is used in your case (hence either a [i]MAC or a
> [i]3MAC (the 'i' specifies whether ISO-padding or not is used)).
> As [3]DES key is needed in this case it would be interesting how
> the full key is derived ... Perhaps the application which created
> the above APDUs could be helpful to answer these questions ;-)

Do you know of any docs that describe the [i][3]MAC Algorithm? I
looked into the CardOS manual and there are some pictures only,
which I don't understand.

Can openssl do [i][3]MAC-calculations? Or any other software?

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] GET CHALLENGE / EXTERNAL AUTHENTICATE Problem

[Peter Koch]

Hi all!

I'm trying to do an EXTERNAL AUTHENTICATE against a CardOS 4.01 card.

Requesting the challenge is easy. But how do I calculate the response?

Here's an example that I captured with an USB-sniffer:

APDU 1: 0084 08, Response 584eb56f6d9f13c5 9000
APDU 2: 00820081 08 cdddb92642a38d3b, Response 9000

Does anybody know how response cdddb92642a38d3b was calculated
from challenge 584eb56f6d9f13c5 using PIN 123456.

I have already tried stuff like

echo -en '\x58\x4e\xb5\x6f\x6d\x9f\x13\xc5' |\
  openssl enc -des-ede3-ofb -K 313233343536 -iv 0 |\
  od -tx1

with different cyphers. Unfortunately I don't know what IV-value
must be used. Any ideas?

Peter
___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

___
opensc-devel mailing list
[EMAIL PROTECTED]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Status of StarCos support

[Peter Koch]

Hi!

What's the status of OpenSCs StarCos support. I just looked into SVN and lately 
only bug-fixes where applied to card-starcos.c.

Is sombody working on StarCos 3.0 support or has already looked into the 
StarCos 3.0 manual?
Is anybody planning to do this?

Peter
 
___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] DATEV-SmartCard classic

[Peter Koch]

Hi Stesie!

> first of all, I'd like to thank you for writing OpenSC.
nice to know !

> I recently got myself a `DATEV SmartCard classic' and tried to use it
> with OpenSC today (svn snapshot 3144).
> 
> However I had to slightly modify libopensc to make it recognize the
> card:

Seems that you understand my sourcecode !! I normally don't :-)

What's going on is that some TCOS based cards have optional keys.
So when the pkcs15-tcos.c tries to detect a card it looks for the
mandatory keys. For the SmartCard Classic I assumed that the
signature key is contained in every SmartCard Classic.
I'm sure your card has a signature key too but Datev must have
changed its location.

With your patch pkcs15-tcos will now detect your card but it will ignore
your signature key as you changed it into an optional key.

Please post opensc-tool -f output of your card. I collect inforamtion
about all kinds of TCOS based signature cards and this will
help me to change the code such that all keys on all Datev Cards
will be properly detected.

When did you buy your card? Signature cards conforming to the
german signature law should have keys >=1280bit now. 
But OpenSC does NOT support TCOS 3.0 yet. So your card must
be a TCOS 2.0 card and hence will support 1024bit keys only.

Maybe that's the reason why Datev changed the layout of their
cards. I would have expected them to use TCOS 3.0 cards now.

Peter
___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Request for advice: want to support MS

[Peter Koch]

> > Unfortunately the login-process uses some sort of challenge-response
> > mechanism (GET CHALLENGE command followed by EXTERNAL AUTH)
> > So far I have absolutely no idea how to compute the response from
> > a given challenge. I do know where the certs and keys are, and I do
> > know all APDUs that are necessary. So the response-computation
> > is the only missing information.
>
> for this you need to extract the secret key used for the MAC
> generation (I assume a symmetric key is used here) from the
> library ;-) The rest shouldn't be too difficult (although opensc
> doesn't really support the various EXT. AUTHENTICATE variants
> at the moment).
> Getting the key could be the fun part. Btw: it is a windows or
> linux binary ?

I'm afraid the secret key is not stored in the library as it
must be different for each eToken. My guess is that the library
will generate the key from the PIN.

Indeed OpenSC does not support EXT AUTH but here my idea was to
add a special PIN_TYPE and implement the challenge response
mechanism in the pin_cmd routine of the card-driver like this:

switch (data->pin_type) {
  case SC_AC_CHV: return iso_ops->pin_cmd(card, data, tries_left);
  case SC_AC_ALADDIN:
compute symmetric key from PINi;
do GET CHALLENGE;
do EXT AUTH;
break;
  default: return SC_ERROR_INVALID_ARGUMENTS;
}

Anyway - until someone (from Alddin) explains the details to me
I cannot implement this.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Request for advice: want to support MS Windows-initialised Aladdin eToken pro

[Peter Koch]

Hi Persival!

On this years LinuxTag in Wiesbaden, Germany, Aladdin donated two
eTokens to me and I tried to do exactly what you are asking for,
namely writing a PKCS15-emulation for the Aladdin proprietary file
layout.

Writing the source is relatively simple, just have a look at one
of the existing pkcs15-.c files.

The hard part is reverse engineering the token. You must find
out where the keys and certs are and by what security
mechanisms they are protected. Of course you can ask Aladdin
and they will tell you - but only after signing a NDA. I used an
USB-sniffer instead :-).

Unfortunately the login-process uses some sort of challenge-response
mechanism (GET CHALLENGE command followed by EXTERNAL AUTH)
So far I have absolutely no idea how to compute the response from
a given challenge. I do know where the certs and keys are, and I do
know all APDUs that are necessary. So the response-computation
is the only missing information.

If someone has this missing piece of information - please let me
know.

Peter
___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] OpenSC logo

[Peter Koch]

Hi Matti!

> Hello, I'm the original author of the logo (chip-key) you still seem to be 
> using, after all these years  :)  Don't panic, I'm NOT writing here to claim 
> it back, or to make demands, since it was commissioned exclusively for
> the project by one (ex-)project member (Antti Tapaninen), anyway.
>
> Actually, I just wish to inquire whether you'd like the original
> SVG file(s) which I noticed I still have in my archives. I'm not sure if
> I ever gave them to Antti or placed them anywhere, so if you still want
> them, just tell.
>
> I'm afraid, however, that I don't have the original font/typeface I used 
> for the blue/red OpenSC text anymore, and it seems I didn't embed it in 
> the SVG, so the data might be partially lost now.

very nice to hear from you. In May we needed the logo when
Andreas and me were at the LinuxTag 2006 in Wiesbaden Germany.

The only version we could find was a bitmap, so I had the "pleasure"
to recreate a SVG file. Have a look at one of the pictures Andreas
took (http://www.opensc-project.org/pictures/linuxtag2006/03logo.jpg)
And the SVG file (created with Inkscape) is here:
http://www.opensc-project.org/media/Logo.svg

I added some shading to the key. Please send your version to me so
I can add it to http://www.opensc-project.org/media/.

Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Re: Datev Smart Card support added

[Peter Koch]

Hi Andreas!

> I also have an DATEV SmartCard. But whatever i try, i can't get 
> Thunderbird to work with that card. How did you do that ?
> If i can make some dumps with an opensc-tool for "debugging" or whatever 
> just let me know (and tell me how to do this - on an windows-xp-system).

I added DATEV-support two weeks ago, so you need a very recent version
of OpenSC. The SCB-package 0.7 was created in May 2006, so DATEV-support
is not included. You must either compile a windows-version from the current
sources or wait until a new SCB- package will be published.

Peter
__
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Datev Smart Card support added

[Peter Koch]

Hi all

Daniel Zauft donated a DATEV card (DATEV smartcard classic),
so I was able to add support for this kind of preformatted TCOS-card.

Please test and let me know whether you were able to use your DATEV
card or not.

Peter
__
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Datev Smart Card support for PKCS11?

[Peter Koch]

Hi

> I've noticed that the wiki is not up to date in this section
> (http://www.opensc-project.org/opensc/wiki/GermanEid). According to the
> Datev Homepage, the Smart Card is based upon the Telesec TCOS 2.03 MIN
> and the Siemens SLE66CX322P-Microchip (http://datev.de/info-db/0903358).
> 
> opensc-explorer works fine and can browse all directories ("info", "ls").
> pkcs15-tool.exe or pkcs11-tool.exe report "unsupported card".
>
> I can't tell if there is a fundamental difference to the supported TCOS
> 2.0 cards. I know that these cards aren't available for the public.

There is none. All TCOS 2.0 card are in fact TCOS 2.03 cards, but supporting
a signature card means to support BOTH the card operating system
(TCOS in this case) AND the file layout of the card.

I heard rumours that DATEV cards are some sort of NetKey E4 cards, but
obviously that's wrong since if that was the case OpenSC would recognize them
as such.

Adding support for a card without a test card is possible but needs some time.
If at all possible I would prefer to get a testcard.

opensc-tool -f ouput may be helpful too.

Peter
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=0066

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Netkey-card with multiple certs per private key

[Peter Koch]

Hi Andreas!

> Try strongSwan from http://www.strongswan.org which has a regular
> PKCS#11 smartcard interface and allows to select certificates
> according to position e.g.
> 
>   leftcert=%smartcard#4
> 
> which is the fourth certificate in the enumeration shown by
> 
>   ipsec listcards
> 
> Read the details in the strongSwan smartcard configuration howto
> 
>   http://www.strongswan.org/docs/readme.htm#section_8

That's definitely a lot betten than selecting a certificate by ID only.
If the PKSCS11-spec would have named this value key-id instead
of just id (with the additional requirement that the id of a certificate
MUST be the same as the id of its key) this whole confusion
could have been avoided.

Peter
___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Netkey-card with multiple certs per private key

[Peter Koch]

Hi Christian!

> sorry to bug you again with this issue, but i want to
> clean stuff up here.

I like to hear from people that use my TCOS emulation :-)

> > Here's what I might do: I could reorder the certificates in the
> > Netkey emulation such that the user-certificates will be
> > the first to be loaded (if they exist). And the TeleSeec
> > certificate will be loaded last.
> 
> Sounds like a nice solution, but its currently not implemented:
> the certs with id 47 are looked up in files df01c200 and df0143b1
> so OpenSwan grabs the first one but i need the latter one.

It was a suggestion only. Seems that you are interested, so I
will implement this tomorrow.

> Is there a better way to do this?
Since OpenSwan selects the cert by an non-unique criteria
(i.e. its key-id) OpenSC must pick one and it selects the
first one it finds. So the only way to get the right one
is to make sure it's the first one in OpenSCs list.

> A patch like the one attached would help me. Unfortunatelly i
> didnt figure out what card-type, the first field there ist about,
> so didnt change it.

Your patch always loads the user cert first even with cards that do
not have such a cert. If the (optional) user-cert is missing no
cert will be loaded at all. So plain TeleSec cards without
user-certs won't work anymore. I will take care of that.

Peter
___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] debug-output under Windows

[Peter Koch]

Hi all!

I would like to analyse the APDUs that are sent to a smart card
when Firefox does certificate based client authentification under
windows.

Here's what I put into C:\Programme\Smart card bundle\opensc.conf:

app default {
  debug = 9;
  debug_file= C:\Temp\OpenSC.log
.

But whatever debug level I use, no APDU-traces are written
to the debug file.

Any ideas?

Peter
___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] PuTTYcard - who's using it

[Peter Koch]

Hi all!

> > Anything new with the eToken Pro issue?
> > 
> > I have formated my eToken Pro direct with openSC but PuTTYcard does not work
> > :(
> > 
> > I thought that I’m not impacted by the file layout problem because I have
> > used the pkcs15-init command. Is there any way to use a Aladdin eToken for
> > PuTTYcard?
>
> so I wonder: why don't you use the putty provided by the scb package?
> it works fine with opensc, no need for puttycard (which is more of a 
> hack, I'm sure peter will for give me:) ).

In particular it is a very old hack. I got almost no feedback which made me
believe that there are no PuTTYcard-users out there. I do use PuTTYcard
every day since it allows me to use both PuTTY and WinSCP with smartcards
at the same time. And I do use scp under unix after having logged in from
my PC, so I need agent forwarding.

Using PuTTYcard ist easy. It does not depend on any other libraries. Its just
a replacment for PuTTYs pageant.exe. Put putty.exe and pageant.exe
on your USB-stick and it will work on every PC that has a smart card reader
with PC/SC-driver.

But configuring PuTTYcard is a real pain. You need informations about your
card that you normally don't have (i.e. the keyreference of your private
key, its file identifier and other stuff) 

Are there any users out there that were able to use PuTTYcard with tokens
or smartcards other then TCOS-cards?

If there are I will build a new version that has builtin support for those
tokens / smart cards. So let me know, if you are interested.

Peter
___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Re: netkey-tool

[Peter Koch]

Hi Andreas

> > Or maybe even
> >
> > COPY SRC\TOOLS\*.EXE $(DEST)
> 
> done. do you need a new scb package right now?

I don't need one, but I got emails from three different
persons all asking for a windows copy of netkey-tool.

Probably all participants of this years LinuxTag :-)

You cannot use a NetKey card without setting the local
PINs first. And this is almost impossible without
netkey-tool (the only alternative is to send the
correct APDUs to your card via opensc-tool -s).

A new SCB would be nice. Alternatively you can send
me the latest NETKEY-TOOL.EXE and I will distribute
it to all those peolple that asked for it.

Peter
___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Re: netkey-tool

[Peter Koch]

Hi

I had a look at the Makefile that creates the SCB-package.

http://www.opensc-project.org/svn/scb/trunk/Makefile.mak

It contains the following block that copies all the Opensc
executables:

COPY SRC\TESTS\BASE64.EXE $(DEST)
COPY SRC\TESTS\P15DUMP.EXE $(DEST)
COPY SRC\TESTS\PINTEST.EXE $(DEST)
COPY SRC\TOOLS\CARDOS-INFO.EXE $(DEST)
COPY SRC\TOOLS\OPENSC-EXPLORER.EXE $(DEST)
COPY SRC\TOOLS\OPENSC-TOOL.EXE $(DEST)
COPY SRC\TOOLS\PKCS11-TOOL.EXE $(DEST)
COPY SRC\TOOLS\PKCS15-INIT.EXE $(DEST)
COPY SRC\TOOLS\PKCS15-TOOL.EXE $(DEST)
COPY SRC\TOOLS\PKCS15-CRYPT.EXE $(DEST)
COPY SRC\INCLUDE\opensc\*.h $(DEST)\include\opensc

How about adding the following lines:

COPY SRC\TOOLS\NETKEY-TOOL.EXE $(DEST)
COPY SRC\TOOLS\CRYPTOFLEX-TOOL.EXE $(DEST)
COPY SRC\TOOLS\PIV-TOOL.EXE $(DEST)

Or maybe even

COPY SRC\TOOLS\*.EXE $(DEST)

Peter
___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Re: netkey-tool

[Peter Koch]

Hi Karl,
 
> Hi Peter,
>
> Where can I download netkey-tool for use on xp.
> 
> Many thanks,
> 
> Karl
 
netkey-tool is part of the regular OpenSC package for quite a while.
It is supposed to be in the windows version too. If for some reason
it is not - please complain about it on the OpenSC mailing list.
 
I'm not very familiar with building windows applications. If you are,
please have a look at the Windows Makefile. My guess is that
the building process for the windows binaries does not build
netkey-tool.exe. This can be fixed easily (by someone that is
more familiar with building windows applications than me).
 
Peter
___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Issue with SignTrust TCOS Card

[Peter Koch]

Hi Holger!

> I have run into an issue using a SignTrust TCOS Card (issuer: Deutsche
> Telekom) in a Reiner SCT cyberjack smart card reader. I am using the
> CTAPI driver supplied by ReinerSCT (libctapi-cyberjack).
> 
> I can't create signatures on the card using the default siganture key in
> slot 0. The error message is:
> { 0x6A87, SC_ERROR_INCORRECT_PARAMETERS,"Lc inconsistent with P1-P2" },
> Using the keys in Slot 1 or 2 works fine for generating signatures.

> From the debug data, I suppose, that signatures in the non-default
> security environment succedd, while the siganture in the default
> security environment fails...
> 
> Unfortunately I got no idea whycan anybody comment and direct me
> towards a fix?

There is no fix :-(. TCOS supports two different sorts of keys, i.e.
signature-keys and decryption-keys.

With a signature-key you can do only signature-operations, with a
decryption-key you can do decryption-operations only.

Now calculating the signature of a hash-value is just the same
as decrypting the padded hash-value. Therefore one can calculate
signatures with decryption-keys. But you cannot decrypt with
signature-keys.

So what where you trying to do? Creating a signature (possible with
all keys) or decrypting (possible with decryption-keys only)?

Please let me know - it seems that you were trying to sign something
and this should be possible with all keys.

Peter

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail


-- 
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] PKCS#15-question about Cert-IDs and Key-IDs

[Peter Koch]

Hi,

> There are two ways to select a certificate:
>
> a) by CKA_ID and optionally by slot
> ...
>
> b) by enumeration (positional parameter)
> ...
>
> strongSwan can now select one of the certs using the position
> #1, #2, #3, #4. Currently in order to retrieve the desired certificate
> and to use the private key, the 'slot' and the CKA_ID is used
> for the actual query.
>
> If according to your proposal all certs belonging to a common private
> key must have the same CKA_ID then additionally I would have to
> include either the 'subject' or 'the label in the PKCS#11 query
> in order to achieve a unique resolution to a single cert.

I would recommend to select the certificate by CKA_VALUE. Its the
only mandatory PKCS#11-attribute that uniquely identifies a
certificate :-)

Peter

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] PKCS#15-question about Cert-IDs and Key-IDs

[Peter Koch]

> BTW - I've been wondering why the CKA_IDs of the CA certs which
> were stored onto the card using the command
> 
> pkcs15-init  --format PKCS12 --store-private-key myCert.p12
> 
> don't show up as 0x46 and 0x48, respectively, but as 0x00.
> 
> Any ideas?

Might be sensitive data which is available only after pin was verified.

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] PKCS#15-question about Cert-IDs and Key-IDs

[Peter Koch]

Hi!

Before I programmed the PKCS#15 emulations routine for TCOS-cards
I downloaded the PKCS15-spec but it was too long and I was too lazy
to read it. So I just used my common sense. One consequence was
that I chosed unique IDs for certificates. I still believe that
a non-unique identifier does not fulfill its only purpose namely to
(uniquely) identify something. But read on. We all believe that
the ID of a certificate is an identifier of the certificate itself.
It's not :-)

Here's what I read in the PKCS11# and PKCS15# specification:

=
PKCS#11, section 10.7.2: Common Key Attributes

"The CKA_ID field is intended to distinguish among multiple keys.
In the case of public and private keys, this field assists in
handling multiple keys held by the same subject; the key identifier
for a public key and its corresponding private key should be the
same. The key identifier should also be the same as for the
corresponding certificate, if one exists. Cryptoki does not enforce
these associations, however."

=
PKCS#11, section 10.9: Private Key Attributes

"It is intended in the interests of interoperability that the subject
name and key identifier for a private key will be the same as those
for the corresponding certificate and public key. However, this is
not enforced by Cryptoki, and it is not required that the certificate
and public key also be stored on the token."

=
PKCS#11, section 12.3.2: X509 Certificate Attributes

In Table 30:
Attribute=CKA_ID, Type=Byte array, Meaning=Key identifier for
public/private key pair (default empty)

"The CKA_ID attribute is intended as a means of distinguishing
multiple public-key/private-key pairs held by the same subject
(whether stored in the same token or not). (Since the keys are
distinguished by subject name as well as identifier, it is possible
that keys for different subjects may have the same CKA_ID value
without introducing any ambiguity.)"


Here's how I interpret PKCS#11. Keys are identified by a CKA_ID
value which must be unique for each object type. Corrensponding
private and public keys should have the same ID.

Certificates are NOT identified by a CKA_ID value, but the CKA_ID
value of a certificate is not an identifier of the certificate itself
but it references the id of the corresponding public/private key.
So the CKA_ID value should better be named CKA_KEY_ID.


=
PKCS#15, section 5.5.3: Public Key Directory Files (PuKDFs)

". When the private key corresponding to a public key also resides
on the card, the keys must share the same identifier. 

NOTE – When a certificate object on the card contains the public key, 
the public key object and the certificate object shall share the same
identifier. This means that in some cases three objects (a private key,
a public key and a certificate) will share the same identifier."

=
PKCS#15, section 5.5.5: Certificate Directory Files (CDFs)

". When a certificate contains a public key whose private key
also resides on the card, the certificate and the private key must
share the same identifier. "



So while PKCS#11 only recommends to use identical identifiers for
certificates and their corresponding keys, PKCS#15 makes this a MUST.

So I should change my TCOS-card emulation if I want to fulfill the
PKCS#15 spec.

On the other hand OpenSwan (and most likely other applications too)
use the ID of a certificate (which does not identify the certificate
itself, but the corresponding key) as a way to specify which certificate
they want to use.

This will not work (and according to PKCS#15 this is not supposed to
work) for cards that have more than one cert per key.

So OpenSwan should change change its way to select a certificate.

But maybe OpenSwan does not care about which certificate is used if
only the public key has the correct id.

Peter

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] PKCS#15-question about Cert-IDs and Key-IDs

[Peter Koch]

> > I just learned that PKCS#15 IDs are non-unique and MUST be choosen
> 
> it is not a must, just a recommendation to simplify the search for
> the corresponding private key (btw: afaik pkcs11 recommends to use
> subject key identifier (normally a digest of the key) as id)

If this is a recommendataion only then OpenSwan should not rely on
it. On the other hand OpenSwan seems to select certificates by ID,
so it seems ta assume that an ID (uniquely) identifies a certificate.

If PKCS#11 recommends to user subject identifiers as IDs then this is
a recommendation to use unique IDs as different certificates will most
likely have different subject identifiers. If one follows this
recommendation, what ID should be choosen for a private key that
is shared by two different certificates?

The following two assumptions (or recommendation):

1) certificates can be uniquely identified by ID
2) for each certificate there exists a private key with the same ID

cannot be fulfilled at the same time if a token has more than one
certificate per key. I therefore guess that the PKCS#11-recommendations
were meant for tokens with a on-to-one mapping between certificates
and keys only.

So I cannot change my NetKey-emulation such that OpenSwan can
use both certificates and Christian must hardcode in pkcs15-tcos.c
which certificate he wants to use with OpenSwan - very unsatisfying !!

Peter

-- 
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] PKCS#15-question about Cert-IDs and Key-IDs

[Peter Koch]

Hi

I just learned that PKCS#15 IDs are non-unique and MUST be choosen
such that a certificate has the same ID as its correspoding
private and public key.

Therefore I changed my PKCS#15-emulation for NetKey cards.

This kind of card contains more then one certificate that correspond
to the same private key and now all this certificates will be given the
same ID (namely the ID of the corresponding private key).

IS THAT CORRECT BEHAVIOUR 

If yes - how is pkcs15-tool -r  supposed to work if the given
ID is non-unique.

Peter

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] configure opensc to deliver an other ce rt as the one requested

[Peter Koch]

> Peter Koch wrote:
> ...
> > OpenSwan should NOT assume that the key has the same ID as the
> > certificate as this cannot be true for cards that have more than
> > one certificate per key.
> 
> the pkcs11 (and pkcs15) ids are not unique ids. It is possible
> that there is more than one cert with a specific id (actually, all
> cert belonging to a specific private key should have the same id
> as the corresponding private key as otherwise it would be difficult
> to find the private key for a certificate).

Non-unique identifiers - isn't that a contradiction in terms ?

So the final conclusion of this discussion is: The current
implementation for NetKey E4-cards is buggy. There might be
more than one certificate on a NetKey card that belong to the
same private key and all this certificates MUST have the same
id (namely the id of the corresponding private key).

I will fix that this weekend.

Peter

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] configure opensc to deliver an other ce rt as the one requested

[Peter Koch]

> > That's a quick (and dirty) hack. 
> Yes, but seems to do what i want. If more people need this and i have
> overseen an official way to configure this it could be implemented
> i.e. using opensc.conf.

I'm sure this works with OpenSwan and with NetKey-cards that have
additional user-certificates. But NetKey-card without user-certificates
won't work at all. So we cannot add this patch into OpenSC. That's why
I called this a "dirty" hack.

> > Your software should be able to use a certificate even if the private
> > key that corresponds to your certificate has a different id. If
> > you want to use the private key that corresponds to a certificate
> > with a certain id do NOT assume that this private key has the
> > same id.
> Didnt see this config-option in OpenSwan.

First: I have never used OpenSwan nor know anything about it.
But from my point of view OpenSwan should allow you to configure
BOTH the cert-id and the key-id of the the cert/key pair to be used.
Or OpenSwan should only allow you to configure the id of the
certificate to be used. In the latter case OpenSwan MUST figure
out themself what key must be used for the configured certificate.

OpenSwan should NOT assume that the key has the same ID as the
certificate as this cannot be true for cards that have more than
one certificate per key.

So maybe you should inform the OpeScwan team about this problem.

Peter

-- 
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] configure opensc to deliver an other ce rt as the one requested

[Peter Koch]

Hi Christian

> > >The problem is this: the usual case seems to be someone tells the
> > >application to use private-key with ID 1, and the application also
> > >uses the cert with ID 1 for that communication. Due to a different
> > >use of certs in this card here that doesnt work out: i have to use
> > >private-key with ID 1 and in the same operation the cert with ID 2.
> > 
> > doesn't the cert with the id 1 belong to the private key with the
> > id 1 (or what is the exactly problem) ?
> Yes, that was the problem here.
> 
> 
> > >Ive had a look at the debugging-output that gets generated from
> > >'pkcs15-tool -r'eading certs, but didnt find the hook to overwrite
> > >the path to the cert-file that is read out.
> > 
> > the binding between the certs and keys is defined in pkcs15-tcos.c
> > ( in src/libopensc/ ) as this is most likely not a pkcs15 compliant
> > card.
>
> Thanks a lot! That worked, pkcs15-tool gives me now the cert i need,
> not the that is requested, libopensc appears to behave the same way
> now.
> Unfortunatelly the other side of the OpenSwan-connection still doesnt
> accept my authentication, but OpenSwan-debugging show now the cert
> with the right subject is used.
> 
> On OpenSC-side everything looks good now, guess i will have to look
> at the firewall-debug-logs now.

That's a quick (and dirty) hack. Could you please supply more details
what exactly you are trying to do. A NetKey card has 3 keys, 3 read-only
certificates and 6 empty certificate files where you can store your
own certificates. It's quite normal that a card has more than one
certificate per key so you normally don't have a one-to-one mapping
between key-ids and cert-ids.

What happens very often is that your card does not contain public
keys. In this case the public key corresponding to private key X
will be extracted from certificate X. This means that for each
private key there must exist either a public key or a certificate
with the same ID.

Your software should be able to use a certificate even if the private
key that corresponds to your certificate has a different id. If
you want to use the private key that corresponds to a certificate
with a certain id do NOT assume that this private key has the
same id.

Peter

-- 
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel