Menu
▾
▴
opensc-devel — discussion of developement of OpenSC and related projects
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(26) |
Feb
(64) |
Mar
(78) |
Apr
(36) |
May
(51) |
Jun
(40) |
Jul
(43) |
Aug
(102) |
Sep
(50) |
Oct
(71) |
Nov
(42) |
Dec
(29) |
| 2014 |
Jan
(49) |
Feb
(52) |
Mar
(56) |
Apr
(30) |
May
(31) |
Jun
(52) |
Jul
(76) |
Aug
(19) |
Sep
(82) |
Oct
(95) |
Nov
(58) |
Dec
(76) |
| 2015 |
Jan
(135) |
Feb
(43) |
Mar
(47) |
Apr
(72) |
May
(59) |
Jun
(20) |
Jul
(17) |
Aug
(14) |
Sep
(34) |
Oct
(62) |
Nov
(48) |
Dec
(23) |
| 2016 |
Jan
(18) |
Feb
(55) |
Mar
(24) |
Apr
(20) |
May
(33) |
Jun
(29) |
Jul
(18) |
Aug
(15) |
Sep
(8) |
Oct
(21) |
Nov
(5) |
Dec
(23) |
| 2017 |
Jan
(3) |
Feb
|
Mar
(17) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(20) |
Sep
(17) |
Oct
(21) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(62) |
Feb
(4) |
Mar
(4) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
|
Dec
(5) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(14) |
Feb
(21) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2023 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Frank M. <mo...@in...> - 2015-12-08 11:28:26
|
Please file an issue at https://github.com/OpenSC/OpenSC/issues and give a step-by-step guide how to reproduce this error. Am Dienstag, dem 08. Dezember, um 14:47 Uhr schrieb faezeh rahmani: > Hi; > The function of waitForSlotEvent with detaching the reader doesn't get the > correct event. I tested it with pkcs11-tools.exe > Also in using the pkcs#11.dll in Firefox , when the reader has been > attached, the list of slots changes but when the reader has been detached > the list doesn't change. > The driver of reader is pcsc. > How can I correct it? > Thanks > Fa > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: faezeh r. <fh....@gm...> - 2015-12-08 11:17:20
|
Hi; The function of waitForSlotEvent with detaching the reader doesn't get the correct event. I tested it with pkcs11-tools.exe Also in using the pkcs#11.dll in Firefox , when the reader has been attached, the list of slots changes but when the reader has been detached the list doesn't change. The driver of reader is pcsc. How can I correct it? Thanks Fa |
|
From: Douglas E E. <dee...@gm...> - 2015-12-07 17:52:37
|
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
looking at keysupport/nist80073/datamodel/PIVCardHolderUniqueID.java
<br>
it looks like getEncoded() <br>
does an encode(). <br>
<br>
Bit the encode() line 203 does:<br>
this.chuid = baos.toByteArray();<br>
<br>
but this does not have the PIV_DATA TLV that piv-tool is
expecting. <br>
<br>
./nist80073/cardedge/PIVDataTempl.java encode will add this:<br>
<br>
111 TLV _data = BERTLVFactory.encodeTLV(new
Tag(Tag.PIV_DATA), this.data);<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 12/7/2015 1:42 AM, Ryan Chapman
wrote:<br>
</div>
<blockquote
cite="mid:CAE...@ma..."
type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I'm trying to get an asymmetric CHUID signature on a PIV
card, in this case a Yubikey NEO. The FIPS 201 standard
requires it, but yubkey-piv-tool only supports writing a
random chuid to the card.</div>
<div>The basic question is... does someone have an example
program that, given a signing certificate and associated
private key, can write the asymmetric key to a PIV card??</div>
<div><br>
</div>
<div>I'm close, but am stuck on long CHUIDs. I can write a
short length one successfully, but the longer one required for
the asymmetric key is failing.</div>
<div><br>
</div>
<div>Now a little more detail on what I've got so far, if anyone
cares...</div>
<div>I've using the piv-tool program to write a short CHUID like
so:</div>
<div><br>
</div>
<div># Check current CHUID</div>
<div>
<div>$ piv-tool -A A:9B:03 -s
"00:CB:3F:FF:05:5C:03:5F:C1:02:00"</div>
<div>Using reader with a card: Yubico Yubikey NEO CCID</div>
<div>Sending: 00 CB 3F FF 05 5C 03 5F C1 02 00</div>
<div>Received (SW1=0x90, SW2=0x00):</div>
<div>53 3B 30 19 D4 E7 39 DA 73 9C ED 39 CE 73 9D 83
S;0...9.s..9.s..</div>
<div>68 58 21 08 42 10 84 21 38 42 10 C3 F5 34 10 78
hX!.B..!8B...4.x</div>
<div>E1 97 B4 5A CA C0 1A 82 64 63 A9 92 3B 56 26 35
...Z....dc..;V&5</div>
<div>08 32 30 33 30 30 31 30 31 3E 00 FE 00
.20300101>...</div>
<div><br>
</div>
<div># Write desired CHUID to file 'chuid'</div>
<div>$
X="53:3B:30:19:D4:E7:39:DA:73:9C:ED:39:CE:73:9D:83:68:58:21:08:42:10:84:21:38:42:10:C3:F5:34:10:37:6F:92:E6:EA:92:65:85:0B:AB:D6:9D:73:8B:15:F0:35:08:32:30:33:30:30:31:30:31:3E:00:FE:00"</div>
<div><br>
</div>
<div>$ (OLDIFS=$IFS; IFS=:; for x in $X; do echo 0x$x | awk
'{printf "%c", $1}'; done; IFS=$OLDIFS ) > chuid<br>
</div>
<div><br>
</div>
<div># Write chuid file to the Yubikey</div>
<div>$ piv-tool -A A:9B:03 -O 3000 -i chuid</div>
<div>Using reader with a card: Yubico Yubikey NEO CCID</div>
<div><br>
</div>
<div># Verify it worked... appears to have worked</div>
<div>$ piv-tool -A A:9B:03 -s
"00:CB:3F:FF:05:5C:03:5F:C1:02:00"</div>
<div>Using reader with a card: Yubico Yubikey NEO CCID</div>
<div>Sending: 00 CB 3F FF 05 5C 03 5F C1 02 00</div>
<div>Received (SW1=0x90, SW2=0x00):</div>
<div>53 3B 30 19 D4 E7 39 DA 73 9C ED 39 CE 73 9D 83
S;0...9.s..9.s..</div>
<div>68 58 21 08 42 10 84 21 38 42 10 C3 F5 34 10 37
hX!.B..!8B...4.7</div>
<div>6F 92 E6 EA 92 65 85 0B AB D6 9D 73 8B 15 F0 35
o....e.....s...5</div>
<div>08 32 30 33 30 30 31 30 31 3E 00 FE 00
.20300101>...</div>
</div>
<div><br>
</div>
<div>TLV '3E' is where the asymmetric signature goes. Above,
look at the last four bytes '3E 00 FE 00'; the '3E 00'
signifies a null asymmetric signature.</div>
<div><br>
</div>
<div>I loaded my cert authority's pub/private keypair in the
java keystore, then used the library at <a
moz-do-not-send="true"
href="https://code.google.com/p/keysupport-java-api/"><a class="moz-txt-link-freetext" href="https://code.google.com/p/keysupport-java-api/">https://code.google.com/p/keysupport-java-api/</a></a>
to generate the CHUID signature, which ends up being 2077
(0x81D) bytes, a little strange, but ok.</div>
<div><br>
</div>
<div>I then try the same thing as before, but encode the '3E'
TLV as such:</div>
<div>3E 82 08 1D .. .. <total of 2077 bytes for CHUID
asymmetric signature payload> .. ..</div>
<div>82 08 1D is BER-TLV to indicate 2077 bytes</div>
<div><br>
</div>
<div>What ended up in the 'chuid' file:</div>
<div>53 3b 30 19 d4 e7 39 da 73 9c ed 39 ce 73 9d 83 68 58 21 08
42 10 84 21 38 42 10 c3 f5 34 10 05 9b 23 97 21 6e ee b0 2d b8
d6 01 0a 69 99 3c 35 08 32 30 33 30 30 31 30 31 3e 82 08 1d ..
.. <2077 bytes for asymm signature> .. .. fe 00<br>
</div>
<div><br>
</div>
<div>When I attempt to write the 'chuid' file using piv-tools, I
get this error:</div>
<div><br>
</div>
<div>
<div>$ piv-tool -A A:9B:03 -O 3000 -i chuid</div>
<div>Using reader with a card: Yubico Yubikey NEO CCID</div>
<div>object tag or length not valid</div>
</div>
<div><br>
</div>
<div>I'm hoping I missed something elementary. Any ideas?</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Ryan</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140">http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensc-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ope...@li...">Ope...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/opensc-devel">https://lists.sourceforge.net/lists/listinfo/opensc-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="200">--
Douglas E. Engert <a class="moz-txt-link-rfc2396E" href="mailto:DEE...@gm..."><DEE...@gm...></a>
</pre>
</body>
</html>
|
|
From: Douglas E E. <dee...@gm...> - 2015-12-07 13:29:07
|
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The encoding does not look correct. The 53 tab should be followed by
length of the rest of the object including the signature. and FE:00
on the end. <br>
An example from the NIST demo card 1 where this is in the CHUID:<br>
Expiration: 20301231<br>
FASCN: ;3201=0295=759494=1=1=6464979587132011?8<br>
FASCN-HEX: D6501858289D6DCACC9325A16859A46927C9D45C86501843E2<br>
GUID: 00000000000000000000000000000000<br>
<br>
The chuid is of length 2315 0x090b<br>
The tag 53 has length 82 (two byte length following)<br>
0907 is the length of the rest of the data <br>
0907 + 4 (length of (tag and length bytes)) = 2315<br>
<br>
<br>
$ od -t x1 < chuid<br>
0000000 53 82 09 07 30 19 d6 50 18 58 28 9d 6d ca cc 93<br>
0000020 25 a1 68 59 a4 69 27 c9 d4 5c 86 50 18 43 e2 34<br>
0000040 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br>
0000060 00 35 08 32 30 33 30 31 32 33 31 3e 82 08 ca 30<br>
0000100 82 08 c6 06 09 2a 86 48 86 f7 0d 01 07 02 a0 82<br>
0000120 08 b7 30 82 08 b3 02 01 03 31 0f 30 0d 06 09 60<br>
0000140 86 48 01 65 03 04 02 01 05 00 30 0a 06 08 60 86<br>
0000160 48 01 65 03 06 01 a0 82 06 09 30 82 06 05 30 82<br>
0000200 04 ed a0 03 02 01 02 02 01 01 30 0d 06 09 2a 86<br>
0000220 48 86 f7 0d 01 01 0b 05 00 30 72 31 0b 30 09 06<br>
0000240 03 55 04 06 13 02 55 53 31 1f 30 1d 06 03 55 04<br>
0000260 0a 13 16 54 65 73 74 20 43 65 72 74 69 66 69 63<br>
0000300 61 74 65 73 20 32 30 31 30 31 10 30 0e 06 03 55<br>
0000320 04 0b 13 07 54 65 73 74 20 43 41 31 30 30 2e 06<br>
0000340 03 55 04 03 13 27 54 65 73 74 20 52 53 41 20 32<br>
0000360 30 34 38 2d 62 69 74 20 43 41 20 66 6f 72 20 54<br>
...<br>
0004340 55 8d af 92 94 3d 16 b3 b3 60 32 f5 12 16 53 db<br>
0004360 39 68 b7 3c fd 45 1f aa 31 f0 4a 31 d5 47 a1 36<br>
0004400 22 d5 53 dd 5a c2 6c a7 53 fe 00<br>
0004413<br>
<br>
Note NEO may have length restrictions on objects. At least the NEO
3 did. <br>
The NEO 4 may not, I have not tried this yet. <br>
<br>
<br>
<div class="moz-cite-prefix">On 12/7/2015 1:42 AM, Ryan Chapman
wrote:<br>
</div>
<blockquote
cite="mid:CAE...@ma..."
type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I'm trying to get an asymmetric CHUID signature on a PIV
card, in this case a Yubikey NEO. The FIPS 201 standard
requires it, but yubkey-piv-tool only supports writing a
random chuid to the card.</div>
<div>The basic question is... does someone have an example
program that, given a signing certificate and associated
private key, can write the asymmetric key to a PIV card??</div>
<div><br>
</div>
<div>I'm close, but am stuck on long CHUIDs. I can write a
short length one successfully, but the longer one required for
the asymmetric key is failing.</div>
<div><br>
</div>
<div>Now a little more detail on what I've got so far, if anyone
cares...</div>
<div>I've using the piv-tool program to write a short CHUID like
so:</div>
<div><br>
</div>
<div># Check current CHUID</div>
<div>
<div>$ piv-tool -A A:9B:03 -s
"00:CB:3F:FF:05:5C:03:5F:C1:02:00"</div>
<div>Using reader with a card: Yubico Yubikey NEO CCID</div>
<div>Sending: 00 CB 3F FF 05 5C 03 5F C1 02 00</div>
<div>Received (SW1=0x90, SW2=0x00):</div>
<div>53 3B 30 19 D4 E7 39 DA 73 9C ED 39 CE 73 9D 83
S;0...9.s..9.s..</div>
<div>68 58 21 08 42 10 84 21 38 42 10 C3 F5 34 10 78
hX!.B..!8B...4.x</div>
<div>E1 97 B4 5A CA C0 1A 82 64 63 A9 92 3B 56 26 35
...Z....dc..;V&5</div>
<div>08 32 30 33 30 30 31 30 31 3E 00 FE 00
.20300101>...</div>
<div><br>
</div>
<div># Write desired CHUID to file 'chuid'</div>
<div>$
X="53:3B:30:19:D4:E7:39:DA:73:9C:ED:39:CE:73:9D:83:68:58:21:08:42:10:84:21:38:42:10:C3:F5:34:10:37:6F:92:E6:EA:92:65:85:0B:AB:D6:9D:73:8B:15:F0:35:08:32:30:33:30:30:31:30:31:3E:00:FE:00"</div>
<div><br>
</div>
<div>$ (OLDIFS=$IFS; IFS=:; for x in $X; do echo 0x$x | awk
'{printf "%c", $1}'; done; IFS=$OLDIFS ) > chuid<br>
</div>
<div><br>
</div>
<div># Write chuid file to the Yubikey</div>
<div>$ piv-tool -A A:9B:03 -O 3000 -i chuid</div>
<div>Using reader with a card: Yubico Yubikey NEO CCID</div>
<div><br>
</div>
<div># Verify it worked... appears to have worked</div>
<div>$ piv-tool -A A:9B:03 -s
"00:CB:3F:FF:05:5C:03:5F:C1:02:00"</div>
<div>Using reader with a card: Yubico Yubikey NEO CCID</div>
<div>Sending: 00 CB 3F FF 05 5C 03 5F C1 02 00</div>
<div>Received (SW1=0x90, SW2=0x00):</div>
<div>53 3B 30 19 D4 E7 39 DA 73 9C ED 39 CE 73 9D 83
S;0...9.s..9.s..</div>
<div>68 58 21 08 42 10 84 21 38 42 10 C3 F5 34 10 37
hX!.B..!8B...4.7</div>
<div>6F 92 E6 EA 92 65 85 0B AB D6 9D 73 8B 15 F0 35
o....e.....s...5</div>
<div>08 32 30 33 30 30 31 30 31 3E 00 FE 00
.20300101>...</div>
</div>
<div><br>
</div>
<div>TLV '3E' is where the asymmetric signature goes. Above,
look at the last four bytes '3E 00 FE 00'; the '3E 00'
signifies a null asymmetric signature.</div>
<div><br>
</div>
<div>I loaded my cert authority's pub/private keypair in the
java keystore, then used the library at <a
moz-do-not-send="true"
href="https://code.google.com/p/keysupport-java-api/"><a class="moz-txt-link-freetext" href="https://code.google.com/p/keysupport-java-api/">https://code.google.com/p/keysupport-java-api/</a></a>
to generate the CHUID signature, which ends up being 2077
(0x81D) bytes, a little strange, but ok.</div>
<div><br>
</div>
<div>I then try the same thing as before, but encode the '3E'
TLV as such:</div>
<div>3E 82 08 1D .. .. <total of 2077 bytes for CHUID
asymmetric signature payload> .. ..</div>
<div>82 08 1D is BER-TLV to indicate 2077 bytes</div>
<div><br>
</div>
<div>What ended up in the 'chuid' file:</div>
<div>53 3b 30 19 d4 e7 39 da 73 9c ed 39 ce 73 9d 83 68 58 21 08
42 10 84 21 38 42 10 c3 f5 34 10 05 9b 23 97 21 6e ee b0 2d b8
d6 01 0a 69 99 3c 35 08 32 30 33 30 30 31 30 31 3e 82 08 1d ..
.. <2077 bytes for asymm signature> .. .. fe 00<br>
</div>
<div><br>
</div>
<div>When I attempt to write the 'chuid' file using piv-tools, I
get this error:</div>
<div><br>
</div>
<div>
<div>$ piv-tool -A A:9B:03 -O 3000 -i chuid</div>
<div>Using reader with a card: Yubico Yubikey NEO CCID</div>
<div>object tag or length not valid</div>
</div>
<div><br>
</div>
<div>I'm hoping I missed something elementary. Any ideas?</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Ryan</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140">http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensc-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ope...@li...">Ope...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/opensc-devel">https://lists.sourceforge.net/lists/listinfo/opensc-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="200">--
Douglas E. Engert <a class="moz-txt-link-rfc2396E" href="mailto:DEE...@gm..."><DEE...@gm...></a>
</pre>
</body>
</html>
|
|
From: Ryan C. <ry...@rc...> - 2015-12-07 08:07:24
|
Hi,
I'm trying to get an asymmetric CHUID signature on a PIV card, in this case
a Yubikey NEO. The FIPS 201 standard requires it, but yubkey-piv-tool only
supports writing a random chuid to the card.
The basic question is... does someone have an example program that, given a
signing certificate and associated private key, can write the asymmetric
key to a PIV card??
I'm close, but am stuck on long CHUIDs. I can write a short length one
successfully, but the longer one required for the asymmetric key is failing.
Now a little more detail on what I've got so far, if anyone cares...
I've using the piv-tool program to write a short CHUID like so:
# Check current CHUID
$ piv-tool -A A:9B:03 -s "00:CB:3F:FF:05:5C:03:5F:C1:02:00"
Using reader with a card: Yubico Yubikey NEO CCID
Sending: 00 CB 3F FF 05 5C 03 5F C1 02 00
Received (SW1=0x90, SW2=0x00):
53 3B 30 19 D4 E7 39 DA 73 9C ED 39 CE 73 9D 83 S;0...9.s..9.s..
68 58 21 08 42 10 84 21 38 42 10 C3 F5 34 10 78 hX!.B..!8B...4.x
E1 97 B4 5A CA C0 1A 82 64 63 A9 92 3B 56 26 35 ...Z....dc..;V&5
08 32 30 33 30 30 31 30 31 3E 00 FE 00 .20300101>...
# Write desired CHUID to file 'chuid'
$
X="53:3B:30:19:D4:E7:39:DA:73:9C:ED:39:CE:73:9D:83:68:58:21:08:42:10:84:21:38:42:10:C3:F5:34:10:37:6F:92:E6:EA:92:65:85:0B:AB:D6:9D:73:8B:15:F0:35:08:32:30:33:30:30:31:30:31:3E:00:FE:00"
$ (OLDIFS=$IFS; IFS=:; for x in $X; do echo 0x$x | awk '{printf "%c", $1}';
done; IFS=$OLDIFS ) > chuid
# Write chuid file to the Yubikey
$ piv-tool -A A:9B:03 -O 3000 -i chuid
Using reader with a card: Yubico Yubikey NEO CCID
# Verify it worked... appears to have worked
$ piv-tool -A A:9B:03 -s "00:CB:3F:FF:05:5C:03:5F:C1:02:00"
Using reader with a card: Yubico Yubikey NEO CCID
Sending: 00 CB 3F FF 05 5C 03 5F C1 02 00
Received (SW1=0x90, SW2=0x00):
53 3B 30 19 D4 E7 39 DA 73 9C ED 39 CE 73 9D 83 S;0...9.s..9.s..
68 58 21 08 42 10 84 21 38 42 10 C3 F5 34 10 37 hX!.B..!8B...4.7
6F 92 E6 EA 92 65 85 0B AB D6 9D 73 8B 15 F0 35 o....e.....s...5
08 32 30 33 30 30 31 30 31 3E 00 FE 00 .20300101>...
TLV '3E' is where the asymmetric signature goes. Above, look at the last
four bytes '3E 00 FE 00'; the '3E 00' signifies a null asymmetric signature.
I loaded my cert authority's pub/private keypair in the java keystore, then
used the library at https://code.google.com/p/keysupport-java-api/ to
generate the CHUID signature, which ends up being 2077 (0x81D) bytes, a
little strange, but ok.
I then try the same thing as before, but encode the '3E' TLV as such:
3E 82 08 1D .. .. <total of 2077 bytes for CHUID asymmetric signature
payload> .. ..
82 08 1D is BER-TLV to indicate 2077 bytes
What ended up in the 'chuid' file:
53 3b 30 19 d4 e7 39 da 73 9c ed 39 ce 73 9d 83 68 58 21 08 42 10 84 21 38
42 10 c3 f5 34 10 05 9b 23 97 21 6e ee b0 2d b8 d6 01 0a 69 99 3c 35 08 32
30 33 30 30 31 30 31 3e 82 08 1d .. .. <2077 bytes for asymm signature> ..
.. fe 00
When I attempt to write the 'chuid' file using piv-tools, I get this error:
$ piv-tool -A A:9B:03 -O 3000 -i chuid
Using reader with a card: Yubico Yubikey NEO CCID
object tag or length not valid
I'm hoping I missed something elementary. Any ideas?
Thanks
Ryan
|
|
From: Vincent Le T. <vin...@my...> - 2015-12-01 15:02:50
|
Yes, this is exactly the same except that it is not limited to the application file (3F FF). GIDS cards set the ACL for a BER TLV EF, and then DO are stored in the EF depending on the permission requested. see https://msdn.microsoft.com/en-us/library/windows/hardware/dn642100%28v=vs.85%29.aspx chap 12.7 regards, Vincent 2015-12-01 14:59 GMT+01:00 Douglas E Engert <dee...@gm...>: > I don't have a copy of 7816-4:2013. As a side note, could you read and see > if there is "CB" GET DATA, with p1-p2 as 3F FF? > If so, does it appear to match what NIST 800-73 is doing? > > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf > "PART 2: > 3.1.2 GET DATA Card Command > The GET DATA card command retrieves the data content of the single data > object whose tag is given in the data field.5" > > On 12/1/2015 6:34 AM, Vincent Le Toux wrote: > > ok, I'll follow Douglas advice and I'll emulate the DO behavior as if > their EF was a DF and the DO an EF. > > (GIDS cards doesn't support DF) > > @Frank: if GIDS cards can use the Embedded minidriver, they have no > PKCS#11 Library, that's why I want to include them in OpenSC. > > As far as I know, there is no implementation available, nor cards > (except maybe the Gemalto IDPrime MD). > > I've made with the help of Philp Webdland of isoApplet a working > javacard applet. > > The idea would be to publish at the same time both the javacard applet & > opensc version. > > Because it must use gzip, I'll have to fix the zlib problem on Windows > x64. > > Will it be possible to include the zlib-static Library in the github > tree ? > > It could be then downloaded by Appveyor ... > > regards, > > Vincent > > > > > > > ------------------------------------------------------------------------------ > > Go from Idea to Many App Stores Faster with Intel(R) XDK > > Give your users amazing mobile app experiences with Intel(R) XDK. > > Use one codebase in this all-in-one HTML5 development environment. > > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > > > > > > > > _______________________________________________ > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm...> > > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
|
From: Douglas E E. <dee...@gm...> - 2015-12-01 14:07:30
|
I don't have a copy of 7816-4:2013. As a side note, could you read and see if there is "CB" GET DATA, with p1-p2 as 3F FF? If so, does it appear to match what NIST 800-73 is doing? http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf "PART 2: 3.1.2 GET DATA Card Command The GET DATA card command retrieves the data content of the single data object whose tag is given in the data field.5" On 12/1/2015 6:34 AM, Vincent Le Toux wrote: > ok, I'll follow Douglas advice and I'll emulate the DO behavior as if their EF was a DF and the DO an EF. > (GIDS cards doesn't support DF) > @Frank: if GIDS cards can use the Embedded minidriver, they have no PKCS#11 Library, that's why I want to include them in OpenSC. > As far as I know, there is no implementation available, nor cards (except maybe the Gemalto IDPrime MD). > I've made with the help of Philp Webdland of isoApplet a working javacard applet. > The idea would be to publish at the same time both the javacard applet & opensc version. > Because it must use gzip, I'll have to fix the zlib problem on Windows x64. > Will it be possible to include the zlib-static Library in the github tree ? > It could be then downloaded by Appveyor ... > regards, > Vincent > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Vincent Le T. <vin...@my...> - 2015-12-01 12:34:43
|
ok, I'll follow Douglas advice and I'll emulate the DO behavior as if their EF was a DF and the DO an EF. (GIDS cards doesn't support DF) @Frank: if GIDS cards can use the Embedded minidriver, they have no PKCS#11 Library, that's why I want to include them in OpenSC. As far as I know, there is no implementation available, nor cards (except maybe the Gemalto IDPrime MD). I've made with the help of Philp Webdland of isoApplet a working javacard applet. The idea would be to publish at the same time both the javacard applet & opensc version. Because it must use gzip, I'll have to fix the zlib problem on Windows x64. Will it be possible to include the zlib-static Library in the github tree ? It could be then downloaded by Appveyor ... regards, Vincent |
|
From: Douglas E E. <dee...@gm...> - 2015-12-01 04:29:26
|
On 11/30/2015 3:57 PM, Vincent Le Toux wrote: > Hi, > > I'm working on adding GIDS cards. This card is defined in a Microsoft specification. > https://msdn.microsoft.com/en-us/library/windows/hardware/dn642100%28v=vs.85%29.aspx > > The main advantage of this card is that it is the only card (except PIV cards) coming with a native minidriver (it do not need anything to be used immediately) and it is read/write with the minidriver. > What is unusual is that it is not a PKCS#15 card and it uses BER TLV files defined in the iso 7816-4:2013. The NIST PIV is not PKCS#15 either and uses a command called GET DATA but the command is 00:CB:3F:FF and it returns BER-TLV. NIST 800-73 does not define read/write APDUs. All access to objects is to be via GET DATA. pkcs15-piv.c emulate a PKCS#15 card providing file paths. card-piv.c has piv_select_file, piv_read_binary and piv_write_binary to override the normal select_file, read_binary and write_binary. piv_select_file takes the path and maps it to a container_id. The first piv_read_binary then uses the container_id with a GET DATA to read the whole object, and cache it. Subsequent read_binary will then return parts of the cached object. So as part of writing the emulation, the card driver gets control and can do whatever it need to do to read/write the data. Much of what you want to do can be done in your card driver, with little or no modifications to the common routines in OpenSC. and you may want to look at the routines in card-piv.c and pkcs15-piv.c If on the other hand, 7816-4:2013 use of this feature is likely to be used by other cards in the future, then a common routines make more sense. > > The BER TLV file is not known / defined in OpenSC. > This is a new value of the file descriptor byte (added in iso 7816-4:2013 7.4.5) whose value is: 0x39 (111001). (the second file type added is SIMPLE TLV structure) > Then each data is stored in a DO of this BER TLV file and is accessed with a GET DATA / PUT DATA ADPU. > > I would like to modify the sc_path_t structure to add a new type named SC_PATH_TYPE_FILE_ID_DO and modify the sc_pkcs15_read_file like functions to use getdata instead of read binary / read record > when accessing data. > => is it ok for you or do you have any comment ? > > Thanks in advance for your attention > > regards, > -- > -- > Vincent Le Toux > > My Smart Logon > www.mysmartlogon.com <http://www.mysmartlogon.com/> > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Frank M. <mo...@in...> - 2015-12-01 03:51:58
|
On Monday, November 30 at 10:57PM, Vincent Le Toux wrote: > Hi, > > I'm working on adding GIDS cards. This card is defined in a Microsoft > specification. > https://msdn.microsoft.com/en-us/library/windows/hardware/dn642100%28v=vs.85%29.aspx > > The main advantage of this card is that it is the only card (except PIV > cards) coming with a native minidriver (it do not need anything to be used > immediately) and it is read/write with the minidriver. > What is unusual is that it is not a PKCS#15 card and it uses BER TLV files > defined in the iso 7816-4:2013. > > The BER TLV file is not known / defined in OpenSC. > This is a new value of the file descriptor byte (added in iso 7816-4:2013 > 7.4.5) whose value is: 0x39 (111001). (the second file type added is SIMPLE > TLV structure) > Then each data is stored in a DO of this BER TLV file and is accessed with > a GET DATA / PUT DATA ADPU. > > I would like to modify the sc_path_t structure to add a new type named > SC_PATH_TYPE_FILE_ID_DO and modify the sc_pkcs15_read_file like functions > to use getdata instead of read binary / read record when accessing data. > => is it ok for you or do you have any comment ? If I understand correctly, you are talking about the DOs that are by definition (ISO 7816-4 2013) selectable objects. Generally speaking, this would be a good improvement to have in OpenSC. I hope I find time to check against a recent version of ISO 7816-15 if this is also a Path object which can be used in EF.CIA, for example. Anyway, I am not sure if this would be the easiest path for you to go. Historically, all cards that don't have a filesystem (e.g. PIV, OpenPGP) emulate a PKCS#15 like structure. This is because the OpenSC PKCS#15 framework assumes transparent EFs for historical reasons. You should especially look at the OpenPGP implementation, because the card you describe sounds very similar. Note that in OpenSC there is already sc_get/put_data. And there are several BER-TLV implementations (I know of): One in cwa14890.c and one in card-openpgp.c that uses sc_asn1_read_tag. *Please* do not add yet an other one... If there is a native minidriver, why do you want to add this card to OpenSC? Who uses this card and for what purpose? -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: Vincent Le T. <vin...@my...> - 2015-11-30 21:57:35
|
Hi, I'm working on adding GIDS cards. This card is defined in a Microsoft specification. https://msdn.microsoft.com/en-us/library/windows/hardware/dn642100%28v=vs.85%29.aspx The main advantage of this card is that it is the only card (except PIV cards) coming with a native minidriver (it do not need anything to be used immediately) and it is read/write with the minidriver. What is unusual is that it is not a PKCS#15 card and it uses BER TLV files defined in the iso 7816-4:2013. The BER TLV file is not known / defined in OpenSC. This is a new value of the file descriptor byte (added in iso 7816-4:2013 7.4.5) whose value is: 0x39 (111001). (the second file type added is SIMPLE TLV structure) Then each data is stored in a DO of this BER TLV file and is accessed with a GET DATA / PUT DATA ADPU. I would like to modify the sc_path_t structure to add a new type named SC_PATH_TYPE_FILE_ID_DO and modify the sc_pkcs15_read_file like functions to use getdata instead of read binary / read record when accessing data. => is it ok for you or do you have any comment ? Thanks in advance for your attention regards, -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
|
From: Douglas E E. <dee...@gm...> - 2015-11-28 21:46:57
|
In response to https://github.com/OpenSC/OpenSC/issues/596 Please have a look at https://github.com/OpenSC/OpenSC/pull/624 This tries to have C_GetSessionInfo do what it should do,that is determine the state of the card right now by querying PCSC and doing a operations to the card to check it state. Have tested with FireFox with card_disconnect = reset; and card_disconnect = leave; I have not tried adding sc_pkcs15_pincache_revalidate to sc_pkcs15_check_state yet. In reader-pcsc.c: pcsc_lock if SCARD_W_RESET was returned, a sleep(1) was added. -- Douglas E. Engert <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2015-11-27 18:07:27
|
On 11/27/2015 10:44 AM, Frank Morgner wrote: > Hi! > >> https://github.com/OpenSC/OpenSC/pull/618 appear to address the issues from >> a PKCS#11 >> perspective, but it is not clear how they would work with a pin pad reader. > > With forced PIN-pad usage it doesn't work. But to be clear: This problem > can't be solved with a PIN-pad reader regardless of the approach taken. I agree. If the card is reset or or has lost its login state, then the pin must be sent to the card. But I am also looking for at what happens if the card's login state is preserved across applications and disconnect_action = leave; is set. (And other applications like Java based may still reset the card.) (And yes I know this could be a security risk if any of the user's other applications can access the card, and if the OS or PCSC is not restricting access to the reader from processes of other users. These would be addressed later.) > >> I have been taking a different approach, by trying to recognize if the state >> of the card has been >> modified by some other application, before trying to login again. Thus to >> would work better with >> a pin pad and could possibly allow the card to be logged in across multiple >> applications. >> (opensc.conf disconnect_action = leave) >> >> These two approaches could coexist, and be controllable via opensc.conf. >> >> There are still some issues with my code, that could be a problem for #618. >> Another application (call it B) could steal the card while our application >> (call it A) is in card_match or card_init. >> Error recovery in this area is not handled well. >> >> It appears that PCSC may return too soon after a card_reset done by (B) and >> pcsc_lock is released >> but the reset is still active in the reader. (A) gets control sees that >> SCARD_W_RESET_CARD was returned >> tries do a transmit and ends up in reader-pcsc.c here: >> >> 266 /* unable to transmit ... most likely a reader problem >> */ >> 267 sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "unable to >> transmit"); >> I have not found the solution for this yet. I think it is problem in PCSC. >> >> >> The simple way to test is to start FireFox (A) go to >> preferences->Advanced->view Certificates >> This should prompt from the PIN, then show the certificates. >> >> To steal the card opensc-tool cab be used as application (B). In another >> window: >> opensc-tool -a >> If opensc.conf has disconnect_action = reset; this will cause a card_reset >> and get FireFox (A) to have to recover from this. >> >> To test with disconnect_action = leave; this will switch the AID to the >> global platform >> AID and my PIV card has both AIDs. >> opensc-tool -s 00:A4:04:00:07:a0:00:00:01:51:00:00 >> I am still looking at the reset problem, but need to address this. >> >> Error handling in OpenSC is too distributed across all layers, and PCSC will >> only >> return to the next SCARD command SCARD_W_RESET_CARD to (A) to indicate (B) >> has done a reset. >> >> This will most likely be from the SCardBeginTranaction initiated from >> sc_lock. >> >> I am still working on this, as it includes C_GetSessionInfo doing a >> sc_pkcs15_check_state >> that gets the latest state of the card, and also tries to chenc the AID and >> login state >> as reported be the card using a VERIFY class 1 APDU. > > I highly doubt that it is possible to *reliably* detecting a > modification/usage of the card's state by an other application. If this > detection mechanism does not work 100% then your card is open for > misusage by other applications. We are back to what does the user want? enter pin for every application, where each application may cache it. It also depends on the card. If the card is writable, and if SM must be reestablished (with or without a PIN.) I am looking for one login for all the user's applications. The PIV may be capable of this, and is not writable by a user, and user_consent/CKA_ALWAYS_AUTHENTICATE is enforced for the signing key, but not the Authentication key. So for signing the user will have to enter the PIN.) > > The only solution I see is to always save and restore the complete state > of the card. And, seen from a PKCS#11 perspective, the only volatile > state is whether some user is logged in or not (correct me if I'm > wrong). Card could have multiple applets (AIDs), like the Neo with OpenPGP and PIV applets. Or official gov issued cards with CAC and PIV applets. PIV specs say login state of PIV applet must be reset if other AID is selected. > Validating the PIN on a PIN-pad always modifies the card's > state, that's why the state *must* be restored by entering the PIN on > the PIN-Pad again and again and again for every transaction. Thus, > solving this problem with a PIN-pad reader is either really really > annoying or simply impossible. Some card issuers may set policy the pin pad reader is required. Yes it is ugly. > > Why solve this problem on the PKCS#11 level? This only needs to be > solved in PKCS#11; tokend and minidriver have their OS-builtin > mechanisms for avoiding interfering applications. > >> On 11/26/2015 8:21 AM, Frank Morgner wrote: >>> I withdrew my original PR to create a new one: >>> >>> >>> >>> Please check if it fits your needs of statelessness! >>> >>> Am 15. November 2015 00:49:35 MEZ, schrieb Frank Morgner >>> <mo...@in...>: >>> >>> I quickly hacked my proposition; it's open for review/suggestions here: >>> https://github.com/OpenSC/OpenSC/pull/608 >>> >>> Greets, Frank. >>> >>> Am Freitag, dem 13. November, um 14:07 Uhr schrieb Frank Morgner: >>> >>> Please rephrase this problem to something like "session locking"! >>> >>> Doug is correct, this can't be solved purely on the lower level. >>> Your >>> best bet would be the PKCS#11 Sessions. I just checked with Client >>> authentication in Firefox and the workflow is something like this: >>> >>> 1. Read card/token/certificates/slots/whatever >>> 2. C_OpenSession(0x1) >>> 3. C_Login >>> 4. C_OpenSession(0x1) >>> 5. C_SignInit/C_Sign >>> 6. (immediately after signature) C_CloseSession >>> 7. Go to 4. and repeat >>> 8. Terminate Firefox9. C_CloseAllSessions >>> >>> As you can see, as soon as the PIN is verified Firefox expects to >>> have >>> exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and >>> C_CloseSession/C_CloseAllSessions should be a quick fix for your >>> problem. Yes, it locks the card on the PC/SC level, but that's all >>> a >>> library without global knowledge can do. >>> >>> Despite this quick win, the problems listed below by Doug still >>> apply! >>> Also, the card driver for your card needs to be reviewed in more >>> depth. >>> >>> As I am writing this I can see that sc_lock also tries to open an >>> SM >>> channel, which I'm pretty sure is not always a good idea... So all >>> in >>> all, you have a lot of testing ahead of you ;-) >>> >>> Greets, Frank. >>> >>> >>> Am Donnerstag, dem 12. November, um 8:26 Uhr schrieb Douglas E >>> Engert: >>> >>> Each ! applet, card or calling application may have its own >>> issues. Can you say what applets, cards or applications you are trying to >>> address? >>> >>> There are a number of factors to consider, these are in >>> particular order: >>> >>> (1) PKCS#11 already has sessions that require login designed to >>> give exclusive access. >>> But PKCS#11 on most systems, is at the application level not at >>> the system level. >>> >>> (2a) PC/SC is at the system level and can enforce exclusive >>> access with a lock/unlock. >>> >>> (2b) Remote desktop connections can make a card available over >>> the network by transmitting PC/SC >>> calls. This could cause complications. >>> >>> (3) OpenSC uses the pcsc lock/unlock for transactions, but this >>> does not match the >>> PKCS#11 session level. >>> >>> (4) Some cards are starting to use secure messaging, that needs >>> to be reestablished if some other >>> application jumped in the middle. >>> >>> (5) Some cards don't have an un-verify to ! reset the security >>> state of the card. A ATR reset is used instead. >>> >>> (6) How would you handle the caching of a card state of a >>> read/write card, if some other application >>> changed files, keys or pins on the card? >>> >>> (7) Many applications may keep a PKCS#11 session open for long >>> periods, and they poll to see if the card has been removed. >>> >>> (8) Some cards, users or applications may expect that once a >>> card is unlocked by the user, any of the user's processes can use the card >>> without reentering the PIN. >>> >>> (9a) PIN caching may be against policy, PIN PAD readers may be >>> required by policy. Don't count on pin caching as a solution. >>> >>> (9b) Other ways to authenticate may be required other the PIN, >>> such as fingerprint matching on card. >>> >>> (10) OpenSC and PCSC already has some options to control >>> releasing/holding of the locks. >>> >>> (11) OpenSC already will try and uses a cached pin if a sign, >>> decrypt or derive operati! on fails. Could this be extended? >>> To the user it looks stateless. (Did I say I don't like cached >>> pins?) >>> >>> (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to >>> force a reauthentication for selected keys. (Some cards enforce that a >>> crytpo command for some keys must be proceeded by a VERIFY >>> command >>> with no other commands in between.) OpenSC already supports >>> this. You may want to look at using this concept for all the keys even >>> though the card does not require it. >>> Applications may not need any changes! The application is the >>> responsible to do another C_Login. >>> >>> (13) OpenSC does have an on disk cache of card objects for the >>> eid card. This might help if you need to >>> reconnect to a card, you would not need to reread objects from >>> the card. Microsoft's cert store does something like this. >>> >>> (14) Adding "save"/"restore" calls to PKCS#11 will then require >>> applications to call these. Many applications will not, >>> if only so! me uses these, will the concept still work? >>> >>> >>> (15) Many of the OpenSC bugs lately deal with multiple >>> applications resetting the cards (or using multiple applets on the card) >>> and issues with SM or >>> reestablishment of authentication. These are usually addressed >>> in the card driver. >>> >>> On 11/12/2015 5:03 AM, Martin Vogt wrote: >>> >>> >>> On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner >>> <mo...@in... <mailto:mo...@in...>> >>> wrote: >>> >>> Nobody is working on this. Could you state what you think >>> the (security) problem currently is? >>> >>> >>> I'm using closed source drivers, because opensc/pkcs11 >>> cannot be used >>> simultaneously. (since ~ 5 years now) >>> >>> Are there ideas how "stateless" support should be >>> implemented? >>> >>> My idea was to add two methods to a d! river plugin >>> "save"/"restore" state, >>> and call this from maybe the pkcs11 layer(?) >>> >>> I would like to ask for an advice how it should be done. >>> >>> >>> >>> >>> >>> >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >>> >>> >>> -- >>> >>> Douglas E. Engert <DEE...@gm...> >>> >>> >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >>> >>> -- >>> Frank Morgner >>> >>> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net >>> OpenPACE ! http://openpace.sourceforge.net >>> IFD Handler for libnfc Devices >>> http://sourceforge.net/projects/ifdnfc >>> >>> >>> >>> >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>> >>> >>> >>> -- >>> Frank Morgner >> >> -- >> >> Douglas E. Engert <DEE...@gm...> >> > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Frank M. <mo...@in...> - 2015-11-27 16:54:20
|
Hi!
> > > typedef void* sc_card_state_t;
> > >
> >
> > As far as I can see, all operations to use a card's key in C_Sign, for
> > example, is carried out automatically (except the login): select
> > application, set security environment, ... What should be the content of
> > some sc_card_state_t?
> >
>
> This depends on the card. I would say that for starcos 3.x its the
> directory path
> and the password, this should work.
>
> Thus:
>
> typedef struct sc_starcos_card_state_s {
> char* path;
> char* password;
> int pass_encoding;
> } sc_startcos_card_state_t;
>
>
> I don't have that much experience in OpenSC, this was only a guess
> how it could be done.
> And if some cards have different needs, like these "auth cookies",
> it can be handles in the card driver.
>
>
>
> >
> > What are "auth cookies" and where are they stored/generated?
> >
>
> it was mentioned in this thread, but I never used it.
>
> > On Fri, Nov 13, 2015 at 2:38 PM, Alon Bar-Lev <alo...@gm...>
> wrote:
> >This is why a card should support authentication cookie as I outlined
> >and some do.
> >You use credentials to establish authentication and accept a cookie as
> >a response.
Well, whatever authentication cookies are, no card driver in OpenSC
implements them. Also, what you outlined above for Starcos is exactly
what I implemented on the PKCS#11 level.
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE http://openpace.sourceforge.net
IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc
|
|
From: Frank M. <mo...@in...> - 2015-11-27 16:44:53
|
Hi! > https://github.com/OpenSC/OpenSC/pull/618 appear to address the issues from > a PKCS#11 > perspective, but it is not clear how they would work with a pin pad reader. With forced PIN-pad usage it doesn't work. But to be clear: This problem can't be solved with a PIN-pad reader regardless of the approach taken. > I have been taking a different approach, by trying to recognize if the state > of the card has been > modified by some other application, before trying to login again. Thus to > would work better with > a pin pad and could possibly allow the card to be logged in across multiple > applications. > (opensc.conf disconnect_action = leave) > > These two approaches could coexist, and be controllable via opensc.conf. > > There are still some issues with my code, that could be a problem for #618. > Another application (call it B) could steal the card while our application > (call it A) is in card_match or card_init. > Error recovery in this area is not handled well. > > It appears that PCSC may return too soon after a card_reset done by (B) and > pcsc_lock is released > but the reset is still active in the reader. (A) gets control sees that > SCARD_W_RESET_CARD was returned > tries do a transmit and ends up in reader-pcsc.c here: > > 266 /* unable to transmit ... most likely a reader problem > */ > 267 sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "unable to > transmit"); > I have not found the solution for this yet. I think it is problem in PCSC. > > > The simple way to test is to start FireFox (A) go to > preferences->Advanced->view Certificates > This should prompt from the PIN, then show the certificates. > > To steal the card opensc-tool cab be used as application (B). In another > window: > opensc-tool -a > If opensc.conf has disconnect_action = reset; this will cause a card_reset > and get FireFox (A) to have to recover from this. > > To test with disconnect_action = leave; this will switch the AID to the > global platform > AID and my PIV card has both AIDs. > opensc-tool -s 00:A4:04:00:07:a0:00:00:01:51:00:00 > I am still looking at the reset problem, but need to address this. > > Error handling in OpenSC is too distributed across all layers, and PCSC will > only > return to the next SCARD command SCARD_W_RESET_CARD to (A) to indicate (B) > has done a reset. > > This will most likely be from the SCardBeginTranaction initiated from > sc_lock. > > I am still working on this, as it includes C_GetSessionInfo doing a > sc_pkcs15_check_state > that gets the latest state of the card, and also tries to chenc the AID and > login state > as reported be the card using a VERIFY class 1 APDU. I highly doubt that it is possible to *reliably* detecting a modification/usage of the card's state by an other application. If this detection mechanism does not work 100% then your card is open for misusage by other applications. The only solution I see is to always save and restore the complete state of the card. And, seen from a PKCS#11 perspective, the only volatile state is whether some user is logged in or not (correct me if I'm wrong). Validating the PIN on a PIN-pad always modifies the card's state, that's why the state *must* be restored by entering the PIN on the PIN-Pad again and again and again for every transaction. Thus, solving this problem with a PIN-pad reader is either really really annoying or simply impossible. Why solve this problem on the PKCS#11 level? This only needs to be solved in PKCS#11; tokend and minidriver have their OS-builtin mechanisms for avoiding interfering applications. > On 11/26/2015 8:21 AM, Frank Morgner wrote: > > I withdrew my original PR to create a new one: > > > > > > > > Please check if it fits your needs of statelessness! > > > > Am 15. November 2015 00:49:35 MEZ, schrieb Frank Morgner > > <mo...@in...>: > > > > I quickly hacked my proposition; it's open for review/suggestions here: > > https://github.com/OpenSC/OpenSC/pull/608 > > > > Greets, Frank. > > > > Am Freitag, dem 13. November, um 14:07 Uhr schrieb Frank Morgner: > > > > Please rephrase this problem to something like "session locking"! > > > > Doug is correct, this can't be solved purely on the lower level. > > Your > > best bet would be the PKCS#11 Sessions. I just checked with Client > > authentication in Firefox and the workflow is something like this: > > > > 1. Read card/token/certificates/slots/whatever > > 2. C_OpenSession(0x1) > > 3. C_Login > > 4. C_OpenSession(0x1) > > 5. C_SignInit/C_Sign > > 6. (immediately after signature) C_CloseSession > > 7. Go to 4. and repeat > > 8. Terminate Firefox9. C_CloseAllSessions > > > > As you can see, as soon as the PIN is verified Firefox expects to > > have > > exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and > > C_CloseSession/C_CloseAllSessions should be a quick fix for your > > problem. Yes, it locks the card on the PC/SC level, but that's all > > a > > library without global knowledge can do. > > > > Despite this quick win, the problems listed below by Doug still > > apply! > > Also, the card driver for your card needs to be reviewed in more > > depth. > > > > As I am writing this I can see that sc_lock also tries to open an > > SM > > channel, which I'm pretty sure is not always a good idea... So all > > in > > all, you have a lot of testing ahead of you ;-) > > > > Greets, Frank. > > > > > > Am Donnerstag, dem 12. November, um 8:26 Uhr schrieb Douglas E > > Engert: > > > > Each ! applet, card or calling application may have its own > > issues. Can you say what applets, cards or applications you are trying to > > address? > > > > There are a number of factors to consider, these are in > > particular order: > > > > (1) PKCS#11 already has sessions that require login designed to > > give exclusive access. > > But PKCS#11 on most systems, is at the application level not at > > the system level. > > > > (2a) PC/SC is at the system level and can enforce exclusive > > access with a lock/unlock. > > > > (2b) Remote desktop connections can make a card available over > > the network by transmitting PC/SC > > calls. This could cause complications. > > > > (3) OpenSC uses the pcsc lock/unlock for transactions, but this > > does not match the > > PKCS#11 session level. > > > > (4) Some cards are starting to use secure messaging, that needs > > to be reestablished if some other > > application jumped in the middle. > > > > (5) Some cards don't have an un-verify to ! reset the security > > state of the card. A ATR reset is used instead. > > > > (6) How would you handle the caching of a card state of a > > read/write card, if some other application > > changed files, keys or pins on the card? > > > > (7) Many applications may keep a PKCS#11 session open for long > > periods, and they poll to see if the card has been removed. > > > > (8) Some cards, users or applications may expect that once a > > card is unlocked by the user, any of the user's processes can use the card > > without reentering the PIN. > > > > (9a) PIN caching may be against policy, PIN PAD readers may be > > required by policy. Don't count on pin caching as a solution. > > > > (9b) Other ways to authenticate may be required other the PIN, > > such as fingerprint matching on card. > > > > (10) OpenSC and PCSC already has some options to control > > releasing/holding of the locks. > > > > (11) OpenSC already will try and uses a cached pin if a sign, > > decrypt or derive operati! on fails. Could this be extended? > > To the user it looks stateless. (Did I say I don't like cached > > pins?) > > > > (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to > > force a reauthentication for selected keys. (Some cards enforce that a > > crytpo command for some keys must be proceeded by a VERIFY > > command > > with no other commands in between.) OpenSC already supports > > this. You may want to look at using this concept for all the keys even > > though the card does not require it. > > Applications may not need any changes! The application is the > > responsible to do another C_Login. > > > > (13) OpenSC does have an on disk cache of card objects for the > > eid card. This might help if you need to > > reconnect to a card, you would not need to reread objects from > > the card. Microsoft's cert store does something like this. > > > > (14) Adding "save"/"restore" calls to PKCS#11 will then require > > applications to call these. Many applications will not, > > if only so! me uses these, will the concept still work? > > > > > > (15) Many of the OpenSC bugs lately deal with multiple > > applications resetting the cards (or using multiple applets on the card) > > and issues with SM or > > reestablishment of authentication. These are usually addressed > > in the card driver. > > > > On 11/12/2015 5:03 AM, Martin Vogt wrote: > > > > > > On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner > > <mo...@in... <mailto:mo...@in...>> > > wrote: > > > > Nobody is working on this. Could you state what you think > > the (security) problem currently is? > > > > > > I'm using closed source drivers, because opensc/pkcs11 > > cannot be used > > simultaneously. (since ~ 5 years now) > > > > Are there ideas how "stateless" support should be > > implemented? > > > > My idea was to add two methods to a d! river plugin > > "save"/"restore" state, > > and call this from maybe the pkcs11 layer(?) > > > > I would like to ask for an advice how it should be done. > > > > > > > > > > > > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > > > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > -- > > > > Douglas E. Engert <DEE...@gm...> > > > > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > -- > > Frank Morgner > > > > Virtual Smart Card Architecture http://vsmartcard.sourceforge.net > > OpenPACE ! http://openpace.sourceforge.net > > IFD Handler for libnfc Devices > > http://sourceforge.net/projects/ifdnfc > > > > > > > > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > Opensc-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > > > > -- > > Frank Morgner > > -- > > Douglas E. Engert <DEE...@gm...> > -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: Martin V. <mv...@gm...> - 2015-11-27 16:31:59
|
Hello,
On Fri, Nov 27, 2015 at 5:08 PM, Frank Morgner <
mo...@in...> wrote:
> Am Freitag, dem 27. November, um 14:48 Uhr schrieb Martin Vogt:
> > I looked at the patch/source, but I cannot test.
> > The Problem is, my StarCos 3.2 card currently does not
> > work with the D-Trust starcos 3.4 driver.
>
> PRs are welcome ;-)
>
I will see ;-). The ATR/Pin encoding patches are easy, but the testsuite
is not working.
>
>
> > typedef void* sc_card_state_t;
> >
>
> As far as I can see, all operations to use a card's key in C_Sign, for
> example, is carried out automatically (except the login): select
> application, set security environment, ... What should be the content of
> some sc_card_state_t?
>
This depends on the card. I would say that for starcos 3.x its the
directory path
and the password, this should work.
Thus:
typedef struct sc_starcos_card_state_s {
char* path;
char* password;
int pass_encoding;
} sc_startcos_card_state_t;
I don't have that much experience in OpenSC, this was only a guess
how it could be done.
And if some cards have different needs, like these "auth cookies",
it can be handles in the card driver.
>
> What are "auth cookies" and where are they stored/generated?
>
it was mentioned in this thread, but I never used it.
> On Fri, Nov 13, 2015 at 2:38 PM, Alon Bar-Lev <alo...@gm...>
wrote:
>This is why a card should support authentication cookie as I outlined
>and some do.
>You use credentials to establish authentication and accept a cookie as
>a response.
regards,
Martin
|
|
From: Frank M. <mo...@in...> - 2015-11-27 16:08:47
|
Am Freitag, dem 27. November, um 14:48 Uhr schrieb Martin Vogt: > Hello, > > On Thu, Nov 26, 2015 at 3:21 PM, Frank Morgner < > mo...@in...> wrote: > > > I withdrew my original PR to create a new one: > > https://github.com/OpenSC/OpenSC/pull/618 > > Please check if it fits your needs of statelessness! > > > > I looked at the patch/source, but I cannot test. > The Problem is, my StarCos 3.2 card currently does not > work with the D-Trust starcos 3.4 driver. PRs are welcome ;-) > I would have expected a different handling, with > callback functions on the card driver level ,eg: > > // callbacks into card plugins. > > typedef void* sc_card_state_t; > > sc_card_state_t* card_alloc_state(); > card_free_state(sc_card_state_t* sc_card_state); > > int card_save_state(void** ptr); > int card_restore_state(void* ptr); > > Where the driver can store "what is needed" for this card. > The pkcs11 layer then have to keep track for the slot<->void pointer, with > a hash. > > If a card supports auth cookies, it can do that in the void pointer, or if > not > it can store the directory/pin. > This means the pkcs11 layer does not know about: "struct sc_pkcs11_login", > but only > manages a dummy typedef. As far as I can see, all operations to use a card's key in C_Sign, for example, is carried out automatically (except the login): select application, set security environment, ... What should be the content of some sc_card_state_t? What are "auth cookies" and where are they stored/generated? -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: Douglas E E. <dee...@gm...> - 2015-11-27 14:38:37
|
https://github.com/OpenSC/OpenSC/pull/618 appear to address the issues from a PKCS#11 perspective, but it is not clear how they would work with a pin pad reader. I have been taking a different approach, by trying to recognize if the state of the card has been modified by some other application, before trying to login again. Thus to would work better with a pin pad and could possibly allow the card to be logged in across multiple applications. (opensc.conf disconnect_action = leave) These two approaches could coexist, and be controllable via opensc.conf. There are still some issues with my code, that could be a problem for #618. Another application (call it B) could steal the card while our application (call it A) is in card_match or card_init. Error recovery in this area is not handled well. It appears that PCSC may return too soon after a card_reset done by (B) and pcsc_lock is released but the reset is still active in the reader. (A) gets control sees that SCARD_W_RESET_CARD was returned tries do a transmit and ends up in reader-pcsc.c here: 266 /* unable to transmit ... most likely a reader problem */ 267 sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "unable to transmit"); I have not found the solution for this yet. I think it is problem in PCSC. The simple way to test is to start FireFox (A) go to preferences->Advanced->view Certificates This should prompt from the PIN, then show the certificates. To steal the card opensc-tool cab be used as application (B). In another window: opensc-tool -a If opensc.conf has disconnect_action = reset; this will cause a card_reset and get FireFox (A) to have to recover from this. To test with disconnect_action = leave; this will switch the AID to the global platform AID and my PIV card has both AIDs. opensc-tool -s 00:A4:04:00:07:a0:00:00:01:51:00:00 I am still looking at the reset problem, but need to address this. Error handling in OpenSC is too distributed across all layers, and PCSC will only return to the next SCARD command SCARD_W_RESET_CARD to (A) to indicate (B) has done a reset. This will most likely be from the SCardBeginTranaction initiated from sc_lock. I am still working on this, as it includes C_GetSessionInfo doing a sc_pkcs15_check_state that gets the latest state of the card, and also tries to chenc the AID and login state as reported be the card using a VERIFY class 1 APDU. On 11/26/2015 8:21 AM, Frank Morgner wrote: > I withdrew my original PR to create a new one: > > > > Please check if it fits your needs of statelessness! > > Am 15. November 2015 00:49:35 MEZ, schrieb Frank Morgner <mo...@in...>: > > I quickly hacked my proposition; it's open for review/suggestions here: > https://github.com/OpenSC/OpenSC/pull/608 > > Greets, Frank. > > Am Freitag, dem 13. November, um 14:07 Uhr schrieb Frank Morgner: > > Please rephrase this problem to something like "session locking"! > > Doug is correct, this can't be solved purely on the lower level. Your > best bet would be the PKCS#11 Sessions. I just checked with Client > authentication in Firefox and the workflow is something like this: > > 1. Read card/token/certificates/slots/whatever > 2. C_OpenSession(0x1) > 3. C_Login > 4. C_OpenSession(0x1) > 5. C_SignInit/C_Sign > 6. (immediately after signature) C_CloseSession > 7. Go to 4. and repeat > 8. Terminate Firefox9. C_CloseAllSessions > > As you can see, as soon as the PIN is verified Firefox expects to have > exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and > C_CloseSession/C_CloseAllSessions should be a quick fix for your > problem. Yes, it locks the card on the PC/SC level, but that's all a > library without global knowledge can do. > > Despite this quick win, the problems listed below by Doug still apply! > Also, the card driver for your card needs to be reviewed in more depth. > > As I am writing this I can see that sc_lock also tries to open an SM > channel, which I'm pretty sure is not always a good idea... So all in > all, you have a lot of testing ahead of you ;-) > > Greets, Frank. > > > Am Donnerstag, dem 12. November, um 8:26 Uhr schrieb Douglas E Engert: > > Each ! applet, card or calling application may have its own issues. Can you say what applets, cards or applications you are trying to address? > > There are a number of factors to consider, these are in particular order: > > (1) PKCS#11 already has sessions that require login designed to give exclusive access. > But PKCS#11 on most systems, is at the application level not at the system level. > > (2a) PC/SC is at the system level and can enforce exclusive access with a lock/unlock. > > (2b) Remote desktop connections can make a card available over the network by transmitting PC/SC > calls. This could cause complications. > > (3) OpenSC uses the pcsc lock/unlock for transactions, but this does not match the > PKCS#11 session level. > > (4) Some cards are starting to use secure messaging, that needs to be reestablished if some other > application jumped in the middle. > > (5) Some cards don't have an un-verify to ! reset the security state of the card. A ATR reset is used instead. > > (6) How would you handle the caching of a card state of a read/write card, if some other application > changed files, keys or pins on the card? > > (7) Many applications may keep a PKCS#11 session open for long periods, and they poll to see if the card has been removed. > > (8) Some cards, users or applications may expect that once a card is unlocked by the user, any of the user's processes can use the card without reentering the PIN. > > (9a) PIN caching may be against policy, PIN PAD readers may be required by policy. Don't count on pin caching as a solution. > > (9b) Other ways to authenticate may be required other the PIN, such as fingerprint matching on card. > > (10) OpenSC and PCSC already has some options to control releasing/holding of the locks. > > (11) OpenSC already will try and uses a cached pin if a sign, decrypt or derive operati! on fails. Could this be extended? > To the user it looks stateless. (Did I say I don't like cached pins?) > > (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a reauthentication for selected keys. (Some cards enforce that a crytpo command for some keys must be proceeded by a VERIFY > command > with no other commands in between.) OpenSC already supports this. You may want to look at using this concept for all the keys even though the card does not require it. > Applications may not need any changes! The application is the responsible to do another C_Login. > > (13) OpenSC does have an on disk cache of card objects for the eid card. This might help if you need to > reconnect to a card, you would not need to reread objects from the card. Microsoft's cert store does something like this. > > (14) Adding "save"/"restore" calls to PKCS#11 will then require applications to call these. Many applications will not, > if only so! me uses these, will the concept still work? > > > (15) Many of the OpenSC bugs lately deal with multiple applications resetting the cards (or using multiple applets on the card) and issues with SM or > reestablishment of authentication. These are usually addressed in the card driver. > > On 11/12/2015 5:03 AM, Martin Vogt wrote: > > > On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <mo...@in... <mailto:mo...@in...>> wrote: > > Nobody is working on this. Could you state what you think the (security) problem currently is? > > > I'm using closed source drivers, because opensc/pkcs11 cannot be used > simultaneously. (since ~ 5 years now) > > Are there ideas how "stateless" support should be implemented? > > My idea was to add two methods to a d! river plugin "save"/"restore" state, > and call this from maybe the pkcs11 layer(?) > > I would like to ask for an advice how it should be done. > > > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm...> > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > -- > Frank Morgner > > Virtual Smart Card Architecture http://vsmartcard.sourceforge.net > OpenPACE ! http://openpace.sourceforge.net > IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > Frank Morgner -- Douglas E. Engert <DEE...@gm...> |
|
From: Martin V. <mv...@gm...> - 2015-11-27 13:48:21
|
Hello, On Thu, Nov 26, 2015 at 3:21 PM, Frank Morgner < mo...@in...> wrote: > I withdrew my original PR to create a new one: > https://github.com/OpenSC/OpenSC/pull/618 > Please check if it fits your needs of statelessness! > I looked at the patch/source, but I cannot test. The Problem is, my StarCos 3.2 card currently does not work with the D-Trust starcos 3.4 driver. I would have expected a different handling, with callback functions on the card driver level ,eg: // callbacks into card plugins. typedef void* sc_card_state_t; sc_card_state_t* card_alloc_state(); card_free_state(sc_card_state_t* sc_card_state); int card_save_state(void** ptr); int card_restore_state(void* ptr); Where the driver can store "what is needed" for this card. The pkcs11 layer then have to keep track for the slot<->void pointer, with a hash. If a card supports auth cookies, it can do that in the void pointer, or if not it can store the directory/pin. This means the pkcs11 layer does not know about: "struct sc_pkcs11_login", but only manages a dummy typedef. regards, Martin |
|
From: Frank M. <mo...@in...> - 2015-11-26 14:21:20
|
I withdrew my original PR to create a new one: https://github.com/OpenSC/OpenSC/pull/618 Please check if it fits your needs of statelessness! Am 15. November 2015 00:49:35 MEZ, schrieb Frank Morgner <mo...@in...>: >I quickly hacked my proposition; it's open for review/suggestions here: >https://github.com/OpenSC/OpenSC/pull/608 > >Greets, Frank. > >Am Freitag, dem 13. November, um 14:07 Uhr schrieb Frank Morgner: >> Please rephrase this problem to something like "session locking"! >> >> Doug is correct, this can't be solved purely on the lower level. Your >> best bet would be the PKCS#11 Sessions. I just checked with Client >> authentication in Firefox and the workflow is something like this: >> >> 1. Read card/token/certificates/slots/whatever >> 2. C_OpenSession(0x1) >> 3. C_Login >> 4. C_OpenSession(0x1) >> 5. C_SignInit/C_Sign >> 6. (immediately after signature) C_CloseSession >> 7. Go to 4. and repeat >> 8. Terminate Firefox >> 9. C_CloseAllSessions >> >> As you can see, as soon as the PIN is verified Firefox expects to >have >> exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and >> C_CloseSession/C_CloseAllSessions should be a quick fix for your >> problem. Yes, it locks the card on the PC/SC level, but that's all a >> library without global knowledge can do. >> >> Despite this quick win, the problems listed below by Doug still >apply! >> Also, the card driver for your card needs to be reviewed in more >depth. >> >> As I am writing this I can see that sc_lock also tries to open an SM >> channel, which I'm pretty sure is not always a good idea... So all in >> all, you have a lot of testing ahead of you ;-) >> >> Greets, Frank. >> >> >> Am Donnerstag, dem 12. November, um 8:26 Uhr schrieb Douglas E >Engert: >> > Each applet, card or calling application may have its own issues. >Can you say what applets, cards or applications you are trying to >address? >> > >> > There are a number of factors to consider, these are in particular >order: >> > >> > (1) PKCS#11 already has sessions that require login designed to >give exclusive access. >> > But PKCS#11 on most systems, is at the application level not at the >system level. >> > >> > (2a) PC/SC is at the system level and can enforce exclusive access >with a lock/unlock. >> > >> > (2b) Remote desktop connections can make a card available over the >network by transmitting PC/SC >> > calls. This could cause complications. >> > >> > (3) OpenSC uses the pcsc lock/unlock for transactions, but this >does not match the >> > PKCS#11 session level. >> > >> > (4) Some cards are starting to use secure messaging, that needs to >be reestablished if some other >> > application jumped in the middle. >> > >> > (5) Some cards don't have an un-verify to reset the security state >of the card. A ATR reset is used instead. >> > >> > (6) How would you handle the caching of a card state of a >read/write card, if some other application >> > changed files, keys or pins on the card? >> > >> > (7) Many applications may keep a PKCS#11 session open for long >periods, and they poll to see if the card has been removed. >> > >> > (8) Some cards, users or applications may expect that once a card >is unlocked by the user, any of the user's processes can use the card >without reentering the PIN. >> > >> > (9a) PIN caching may be against policy, PIN PAD readers may be >required by policy. Don't count on pin caching as a solution. >> > >> > (9b) Other ways to authenticate may be required other the PIN, such >as fingerprint matching on card. >> > >> > (10) OpenSC and PCSC already has some options to control >releasing/holding of the locks. >> > >> > (11) OpenSC already will try and uses a cached pin if a sign, >decrypt or derive operation fails. Could this be extended? >> > To the user it looks stateless. (Did I say I don't like cached >pins?) >> > >> > (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a >reauthentication for selected keys. (Some cards enforce that a crytpo >command for some keys must be proceeded by a VERIFY command >> > with no other commands in between.) OpenSC already supports this. >You may want to look at using this concept for all the keys even though >the card does not require it. >> > Applications may not need any changes! The application is the >responsible to do another C_Login. >> > >> > (13) OpenSC does have an on disk cache of card objects for the eid >card. This might help if you need to >> > reconnect to a card, you would not need to reread objects from the >card. Microsoft's cert store does something like this. >> > >> > (14) Adding "save"/"restore" calls to PKCS#11 will then require >applications to call these. Many applications will not, >> > if only some uses these, will the concept still work? >> > >> > >> > (15) Many of the OpenSC bugs lately deal with multiple applications >resetting the cards (or using multiple applets on the card) and issues >with SM or >> > reestablishment of authentication. These are usually addressed in >the card driver. >> > >> > On 11/12/2015 5:03 AM, Martin Vogt wrote: >> > > >> > > On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner ><mo...@in... ><mailto:mo...@in...>> wrote: >> > > >> > > Nobody is working on this. Could you state what you think the >(security) problem currently is? >> > > >> > > >> > > I'm using closed source drivers, because opensc/pkcs11 cannot be >used >> > > simultaneously. (since ~ 5 years now) >> > > >> > > Are there ideas how "stateless" support should be implemented? >> > > >> > > My idea was to add two methods to a driver plugin >"save"/"restore" state, >> > > and call this from maybe the pkcs11 layer(?) >> > > >> > > I would like to ask for an advice how it should be done. >> > > >> > > >> > > >> > > >> > > >> > > >> > > >------------------------------------------------------------------------------ >> > > >> > > >> > > >> > > _______________________________________________ >> > > Opensc-devel mailing list >> > > Ope...@li... >> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > > >> > >> > -- >> > >> > Douglas E. Engert <DEE...@gm...> >> > >> > >> > >------------------------------------------------------------------------------ >> > _______________________________________________ >> > Opensc-devel mailing list >> > Ope...@li... >> > https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > >> >> -- >> Frank Morgner >> >> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net >> OpenPACE http://openpace.sourceforge.net >> IFD Handler for libnfc Devices >http://sourceforge.net/projects/ifdnfc > > > >> >------------------------------------------------------------------------------ > >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel > > >-- >Frank Morgner > >Virtual Smart Card Architecture http://vsmartcard.sourceforge.net >OpenPACE http://openpace.sourceforge.net >IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ > > >------------------------------------------------------------------------ > >_______________________________________________ >Opensc-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Frank Morgner |
|
From: Douglas E E. <dee...@gm...> - 2015-11-18 20:30:35
|
Well try uncommenting in opensc.conf: 96 # enable_pinpad = false; Most pin pad readers can function as non-pin pad readers. On 11/18/2015 1:57 PM, Ferdinand Rau wrote: > Douglas, > > I don't have a reader without pin pad at hand, currently, but I will try this once I'll have the chance. > Just for the record: Setting "use_pin_caching = false;" when using a reader _with_ pin pid did not change anything (as expected). > > Best, > Ferdinand > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Ferdinand R. <ra...@we...> - 2015-11-18 19:57:48
|
Douglas, I don't have a reader without pin pad at hand, currently, but I will try this once I'll have the chance. Just for the record: Setting "use_pin_caching = false;" when using a reader _with_ pin pid did not change anything (as expected). Best, Ferdinand |
|
From: Douglas E E. <dee...@gm...> - 2015-11-18 19:33:29
|
One of the sign operations looks like it works. Data to be signed 7648 7691. Response with the signature 7691. PKCS#11 return 7722 and Start of failed sign 7773 data to be signed 7842 response 7849 with 7982 PKCS#11 return 9868 It could be that the newer card wants CKA_ALWAYS_AUTHENTICATE = TRUE, which is called in PKCS#15 user_consent. CKA_ALWAYS_AUTHENTICATE says the card requires the PIN to have been sent before each crypto operation for the selected key. pkcs11-tool.c line 3675 if (getALWAYS_AUTHENTICATE(sess, privKeyObject)) is asking if pin needs to be sent again. When uses without a pin pad reader, the PIN may have been cached, and sc_pkcs15_pincache_revalidate may have provided the pin without you knowledge. With a pin pad reader, the pin can not be cached, it never enters the host computer. Some simple things to try to prove the above is the problem. Use a non pinpad reader. If that works look at the log for the sc_pkcs15_pincache_revalidate being called and providing the key. then try uncomenting in opensc.conf this line. # use_pin_caching = false; it should fail, with sc_pkcs15_pincache_revalidate saying there is not pin cached. On 11/18/2015 7:13 AM, Ferdinand Rau wrote: > Hello Andreas, > > I took a step back and tried to get things working just using the commend line tools, but without success. > Eventually, I found out that I cannot even run 'pkcs11-tool --test' successfully. > > Here, you can download a log file of a failed 'pkcs11-tool --test' with OPENSC_DEBUG=9: > https://www.dropbox.com/s/3jhe77n5ri1674k/log.txt.zip?dl=1 > > The reader does ask for the PIN and reports "PIN correct", but the test fails anyway with the following message: >> error: PKCS11 function C_Sign failed: rv = CKR_USER_NOT_LOGGED_IN (0x101) > > Best regards, > Ferdinand > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Ferdinand R. <ra...@we...> - 2015-11-18 13:13:44
|
Hello Andreas, I took a step back and tried to get things working just using the commend line tools, but without success. Eventually, I found out that I cannot even run 'pkcs11-tool --test' successfully. Here, you can download a log file of a failed 'pkcs11-tool --test' with OPENSC_DEBUG=9: https://www.dropbox.com/s/3jhe77n5ri1674k/log.txt.zip?dl=1 The reader does ask for the PIN and reports "PIN correct", but the test fails anyway with the following message: > error: PKCS11 function C_Sign failed: rv = CKR_USER_NOT_LOGGED_IN (0x101) Best regards, Ferdinand |
|
From: Vincent Le T. <vin...@my...> - 2015-11-16 15:48:34
|
My contribution: how Windows is sharing cards between applications You have one service whose call is to manage the card driver. It is the endpoint for the PCSC API (scardsrv) Then each application can use the smartcard. They lock the card before doing authentication, do some authenticated things, then unlock the card. (the card is locked for a maximum of a few seconds). The PIN is cached into the "driver" (CSP) when it is know to work. For pinpad, the card is supposed to ask for a session pin which is reused for the next authentication. When you are asking to select a certificate then sign some code, you have : - lock get all certificates - unlock show all certificate and the user pick one ask for pin - lock try the pin -unlock put it in cache -lock authenticate with the previous pin sign -unlock & reset => no pin share / state between applications But there are caches at many level (public key, certificates, ...) 1) Inside the CSP (current process) 2) At the smart card service level (SCardReadCache) Because there is a lot of reset, Windows recommend to implement a deauthentication APDU (for example verify with FF as described in the latest iso 7816-4) What can be done in OpenSC is to have a function "restarting" the card after a reset (for example select the applet), an optional deauthentication function (by default a reset) and to mimic the lock / unlock behavior of Windows regards, Vincent 2015-11-16 9:31 GMT+01:00 Frank Morgner <mo...@in...>: > Yes correct, If the card does not use sm. Same problem is discussed here > https://github.com/OpenSC/OpenSC/issues/596 > > Am 16. November 2015 09:09:20 MEZ, schrieb Martin Vogt <mv...@gm...>: > >> >> >> On Sun, Nov 15, 2015 at 12:49 AM, Frank Morgner < >> mo...@in...> wrote: >> >>> I quickly hacked my proposition; it's open for review/suggestions here: >>> https://github.com/OpenSC/OpenSC/pull/608 >>> >> >> If I understand it correctly the card/reader is not locked, like in the >> "lock_login" case. >> Another user then can use my unlocked card to send signed emails? >> >> >> >> ------------------------------ >> >> Presto, an open source distributed SQL query engine for big data, initially >> developed by Facebook, enables you to easily query your data on Hadoop in a >> more interactive manner. Teradata is also now providing full enterprise >> support for Presto. Download a free open source copy now. >> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 >> >> ------------------------------ >> >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> >> > -- > Frank Morgner > > > ------------------------------------------------------------------------------ > Presto, an open source distributed SQL query engine for big data, initially > developed by Facebook, enables you to easily query your data on Hadoop in a > more interactive manner. Teradata is also now providing full enterprise > support for Presto. Download a free open source copy now. > http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
5 messages has been excluded from this view by a project administrator.
