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: Douglas E E. <dee...@gm...> - 2015-07-08 01:47:50
|
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Is this an Italian CNS card?<br>
<br>
Can you run the OpenSC commands:<br>
pkcs11-tool -O to see what it is doing? <br>
<br>
adding -v -v -v -v -v -v -v would also help. <br>
<br>
It could be the OpenSC implementation for the CNS applet on your
card is not complete, or the OpenSC card driver is for a previous
version of the applet/card. <br>
Either you or someone with a similar card would need to submit a
patch to OpenSC. <br>
<br>
<div class="moz-cite-prefix">On 7/7/2015 10:52 AM, Andrea Dell'Anna
wrote:<br>
</div>
<blockquote
cite="mid:CAM...@ma..."
type="cite">
<div dir="ltr">
<div>
<div>Hi, thank you for your reply!<br>
<br>
</div>
I logged both results with pkcs11-spy for the same inputset on
the same java program. <br>
It simply seems that opensc driver retrieves just one cert.<br>
Instead Athena proprietary driver retrieves both certs on the
smartcard. <br>
<br>
</div>
Here's the attachments for both driver logs and my testing java
program.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jul 7, 2015 at 2:52 PM, Douglas
E Engert <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dee...@gm..." target="_blank">dee...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> What wold help to see
if the problem in in the Java side, opensc, or the vendors
pkcs11 implementation, would be a PKCS#11 trace.<br>
<br>
Look at how to use PKCS#11 SPY:<br>
<br>
<a moz-do-not-send="true"
href="https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC#pkcs-11-spy"
target="_blank">https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC#pkcs-11-spy</a><br>
<br>
See if you can use it in place of the <span
style="font-family:monospace,monospace">opensc-pkcs11.so
to trace the </span><span
style="font-family:monospace,monospace">opensc-pkcs11.so.
<br>
Then try it with the </span>vendor's <span><span
style="font-family:monospace,monospace">libASEP11.so</span></span>
by setting:<br>
<code>export PKCS11SPY=</code><code><span><span
style="font-family:monospace,monospace">/lib64/libASEP11.so<br>
<br>
If using opensc-pkcs11.so, an OpenSC debug output
would also help, its on the same web page as above.<br>
</span></span><br>
Look at the queries and what attributes are requested
and what certificates are returned. <br>
</code><br>
NOTE: that the PIN may be in the output, as well as the
certificates. You may want to edit the output before
posting it. <br>
<br>
PKCS#11 does not provide for a NON-REPUDATION attribute,
but X509 and PKCS#15 do. <br>
<br>
Also see OpenSC src/pkcs11/pkcs11-opensc.h<br>
which provides for a PKCS#11 "vendor-specific
attribute". But this may not be implemented for your card.<br>
Your card vendor may have its own "vendor-specific
attribute" that is different. <br>
One should avoid using "vendor-specific attributes" <br>
<br>
Most applications would request all the certificates, and
then parse the certificate to get the KeyUsage flags. <br>
<div>
<div class="h5"> <br>
<br>
<br>
<div>On 7/7/2015 5:55 AM, Andrea Dell'Anna wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Goodmorning everyone.<br>
<br>
</div>
<div>I'm writing my first message here so I hope
it's the right place to do it.<br>
I'm a java developer writing a program for
Ubuntu and I need to access to my Athena
smartcard pkcs11 features using <span
style="font-family:monospace,monospace">opensc-pkcs11.so</span>
driver.<br>
<br>
</div>
<div>There are two x509 certs into the
smartcard:<br>
-One is for "non-repudiation" key usage
(digital signature) <br>
</div>
<div>-the other one is for "Critical" "Signing"
"Key Encipherment" (web authentication and
encryption)<br>
</div>
<br>
The <span
style="font-family:monospace,monospace">sun.security.pkcs11.SunPKCS11</span>
provider is loaded with no problem using the <span
style="font-family:monospace,monospace">opensc-pkcs11.so</span>
driver.<br>
</div>
<div>When I load the pkcs11 keystore and I list
all the aliases, my code is able to see <b><u>JUST</u></b>
the alias with "Critical" "Signing" "Key
Encipherment" (web authentication and
encryption) x509 cert, <u><b>NOT THE
NON-REPUDIATION ONE!!</b></u><br>
<br>
</div>
<div>If I load the pksc11 keystore using the
Athena's smartcard <span>Proprietary driver (<span
style="font-family:monospace,monospace">/lib64/libASEP11.so</span>),
my code is able to load <b><u>all my
smartcard keystore aliases</u></b>.<br>
<br>
</span></div>
<div><span>I tried with some other smartcard
produced by different vendors (Incard and
Siemens). I'm always able to load the </span><span
style="font-family:monospace,monospace">sun.security.pkcs11.SunPKCS11</span>
provider<span> using </span><span
style="font-family:monospace,monospace">opensc-pkcs11.so</span>.
<br>
But I'm able to see the non-repudiation x509
cert <u>only using the proprietary smartcard
driver</u>. Why?<br>
</div>
<div><span><br>
Why I'm not able to load the "non-repudiation"
key usage x509 cert using </span><span
style="font-family:monospace,monospace">opensc-pkcs11.so</span>?</div>
</div>
</blockquote>
<br>
</div>
</div>
<blockquote type="cite">
<fieldset></fieldset>
<br>
<pre>------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
<a moz-do-not-send="true" href="https://www.gigenetcloud.com/" target="_blank">https://www.gigenetcloud.com/</a></pre>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Opensc-devel mailing list
<a moz-do-not-send="true" href="mailto:Ope...@li..." target="_blank">Ope...@li...</a>
<a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/opensc-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensc-devel</a><span class="HOEnZb"><font color="#888888">
</font></span></pre>
<span class="HOEnZb"><font color="#888888"> </font></span></blockquote>
<span class="HOEnZb"><font color="#888888"> <br>
<pre cols="200">--
Douglas E. Engert <a moz-do-not-send="true" href="mailto:DEE...@gm..." target="_blank"><DEE...@gm...></a>
</pre>
</font></span></div>
<br>
------------------------------------------------------------------------------<br>
Don't Limit Your Business. Reach for the Cloud.<br>
GigeNET's Cloud Solutions provide you with the tools and
support that<br>
you need to offload your IT needs and focus on growing your
business.<br>
Configured For All Businesses. Start Your Cloud Today.<br>
<a moz-do-not-send="true"
href="https://www.gigenetcloud.com/" rel="noreferrer"
target="_blank">https://www.gigenetcloud.com/</a><br>
_______________________________________________<br>
Opensc-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Ope...@li...">Ope...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/opensc-devel"
rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensc-devel</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</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: Andrea Dell'A. <ad...@li...> - 2015-07-07 16:22:58
|
Hi, thank you for your reply! I logged both results with pkcs11-spy for the same inputset on the same java program. It simply seems that opensc driver retrieves just one cert. Instead Athena proprietary driver retrieves both certs on the smartcard. Here's the attachments for both driver logs and my testing java program. On Tue, Jul 7, 2015 at 2:52 PM, Douglas E Engert <dee...@gm...> wrote: > What wold help to see if the problem in in the Java side, opensc, or the > vendors pkcs11 implementation, would be a PKCS#11 trace. > > Look at how to use PKCS#11 SPY: > > https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC#pkcs-11-spy > > See if you can use it in place of the opensc-pkcs11.so to trace the opensc-pkcs11.so. > > Then try it with the vendor's libASEP11.so by setting: > export PKCS11SPY=/lib64/libASEP11.so > > If using opensc-pkcs11.so, an OpenSC debug output would also help, its on > the same web page as above. > > Look at the queries and what attributes are requested and what > certificates are returned. > > NOTE: that the PIN may be in the output, as well as the certificates. You > may want to edit the output before posting it. > > PKCS#11 does not provide for a NON-REPUDATION attribute, but X509 and > PKCS#15 do. > > Also see OpenSC src/pkcs11/pkcs11-opensc.h > which provides for a PKCS#11 "vendor-specific attribute". But this may > not be implemented for your card. > Your card vendor may have its own "vendor-specific attribute" that is > different. > One should avoid using "vendor-specific attributes" > > Most applications would request all the certificates, and then parse the > certificate to get the KeyUsage flags. > > > > On 7/7/2015 5:55 AM, Andrea Dell'Anna wrote: > > Goodmorning everyone. > > I'm writing my first message here so I hope it's the right place to do > it. > I'm a java developer writing a program for Ubuntu and I need to access to > my Athena smartcard pkcs11 features using opensc-pkcs11.so driver. > > There are two x509 certs into the smartcard: > -One is for "non-repudiation" key usage (digital signature) > -the other one is for "Critical" "Signing" "Key Encipherment" (web > authentication and encryption) > > The sun.security.pkcs11.SunPKCS11 provider is loaded with no problem > using the opensc-pkcs11.so driver. > When I load the pkcs11 keystore and I list all the aliases, my code is > able to see *JUST* the alias with "Critical" "Signing" "Key Encipherment" > (web authentication and encryption) x509 cert, *NOT THE NON-REPUDIATION > ONE!!* > > If I load the pksc11 keystore using the Athena's smartcard Proprietary > driver (/lib64/libASEP11.so), my code is able to load *all my smartcard > keystore aliases*. > > I tried with some other smartcard produced by different vendors (Incard > and Siemens). I'm always able to load the sun.security.pkcs11.SunPKCS11 > provider using opensc-pkcs11.so. > But I'm able to see the non-repudiation x509 cert *only using the > proprietary smartcard driver*. Why? > > Why I'm not able to load the "non-repudiation" key usage x509 cert using > opensc-pkcs11.so? > > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today.https://www.gigenetcloud.com/ > > > > _______________________________________________ > Opensc-devel mailing lis...@li...://lists.sourceforge.net/lists/listinfo/opensc-devel > > > -- > > Douglas E. Engert <DEE...@gm...> <DEE...@gm...> > > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > |
|
From: Douglas E E. <dee...@gm...> - 2015-07-07 12:59:08
|
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
What wold help to see if the problem in in the Java side, opensc, or
the vendors pkcs11 implementation, would be a PKCS#11 trace.<br>
<br>
Look at how to use PKCS#11 SPY:<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC#pkcs-11-spy">https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC#pkcs-11-spy</a><br>
<br>
See if you can use it in place of the <span
style="font-family:monospace,monospace">opensc-pkcs11.so to trace
the </span><span style="font-family:monospace,monospace">opensc-pkcs11.so.
<br>
Then try it with the </span>vendor's <span class=""><span
style="font-family:monospace,monospace">libASEP11.so</span></span>
by setting:<br>
<code>export PKCS11SPY=</code><code><span class=""><span
style="font-family:monospace,monospace">/lib64/libASEP11.so<br>
<br>
If using opensc-pkcs11.so, an OpenSC debug output would also
help, its on the same web page as above.<br>
</span></span><br>
Look at the queries and what attributes are requested and what
certificates are returned. <br>
</code><br>
NOTE: that the PIN may be in the output, as well as the certificates.
You may want to edit the output before posting it. <br>
<br>
PKCS#11 does not provide for a NON-REPUDATION attribute, but X509
and PKCS#15 do. <br>
<br>
Also see OpenSC src/pkcs11/pkcs11-opensc.h<br>
which provides for a PKCS#11 "vendor-specific attribute". But this
may not be implemented for your card.<br>
Your card vendor may have its own "vendor-specific attribute" that
is different. <br>
One should avoid using "vendor-specific attributes" <br>
<br>
Most applications would request all the certificates, and then parse
the certificate to get the KeyUsage flags. <br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 7/7/2015 5:55 AM, Andrea Dell'Anna
wrote:<br>
</div>
<blockquote
cite="mid:CAM...@ma..."
type="cite">
<div dir="ltr">
<div>
<div>Goodmorning everyone.<br>
<br>
</div>
<div>I'm writing my first message here so I hope it's the
right place to do it.<br>
I'm a java developer writing a program for Ubuntu and I need
to access to my Athena smartcard pkcs11 features using <span
style="font-family:monospace,monospace">opensc-pkcs11.so</span>
driver.<br>
<br>
</div>
<div>There are two x509 certs into the smartcard:<br>
-One is for "non-repudiation" key usage (digital signature)
<br>
</div>
<div>-the other one is for "Critical" "Signing" "Key
Encipherment" (web authentication and encryption)<br>
</div>
<br>
The <span style="font-family:monospace,monospace">sun.security.pkcs11.SunPKCS11</span>
provider is loaded with no problem using the <span
style="font-family:monospace,monospace">opensc-pkcs11.so</span>
driver.<br>
</div>
<div>When I load the pkcs11 keystore and I list all the aliases,
my code is able to see <b><u>JUST</u></b> the alias with
"Critical" "Signing" "Key Encipherment" (web authentication
and encryption) x509 cert, <u><b>NOT THE NON-REPUDIATION
ONE!!</b></u><br>
<br>
</div>
<div>If I load the pksc11 keystore using the Athena's smartcard
<span class="">Proprietary driver (<span
style="font-family:monospace,monospace">/lib64/libASEP11.so</span>),
my code is able to load <b><u>all my smartcard keystore
aliases</u></b>.<br>
<br>
</span></div>
<div><span class="">I tried with some other smartcard produced
by different vendors (Incard and Siemens). I'm always able
to load the </span><span
style="font-family:monospace,monospace">sun.security.pkcs11.SunPKCS11</span>
provider<span class=""> using </span><span
style="font-family:monospace,monospace">opensc-pkcs11.so</span>.
<br>
But I'm able to see the non-repudiation x509 cert <u>only
using the proprietary smartcard driver</u>. Why?<br>
</div>
<div><span class=""><br>
Why I'm not able to load the "non-repudiation" key usage
x509 cert using </span><span
style="font-family:monospace,monospace">opensc-pkcs11.so</span>?</div>
</div>
</blockquote>
<br>
<blockquote
cite="mid:CAM...@ma..."
type="cite">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
<a class="moz-txt-link-freetext" href="https://www.gigenetcloud.com/">https://www.gigenetcloud.com/</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: Andrea Dell'A. <ad...@li...> - 2015-07-07 11:25:05
|
Goodmorning everyone. I'm writing my first message here so I hope it's the right place to do it. I'm a java developer writing a program for Ubuntu and I need to access to my Athena smartcard pkcs11 features using opensc-pkcs11.so driver. There are two x509 certs into the smartcard: -One is for "non-repudiation" key usage (digital signature) -the other one is for "Critical" "Signing" "Key Encipherment" (web authentication and encryption) The sun.security.pkcs11.SunPKCS11 provider is loaded with no problem using the opensc-pkcs11.so driver. When I load the pkcs11 keystore and I list all the aliases, my code is able to see *JUST* the alias with "Critical" "Signing" "Key Encipherment" (web authentication and encryption) x509 cert, *NOT THE NON-REPUDIATION ONE!!* If I load the pksc11 keystore using the Athena's smartcard Proprietary driver (/lib64/libASEP11.so), my code is able to load *all my smartcard keystore aliases*. I tried with some other smartcard produced by different vendors (Incard and Siemens). I'm always able to load the sun.security.pkcs11.SunPKCS11 provider using opensc-pkcs11.so. But I'm able to see the non-repudiation x509 cert *only using the proprietary smartcard driver*. Why? Why I'm not able to load the "non-repudiation" key usage x509 cert using opensc-pkcs11.so? |
|
From: Frank M. <mo...@in...> - 2015-07-06 11:01:01
|
Has anybody looked at the problem on OS x 10.10 or later? Am 6. Juli 2015 11:25:58 MESZ, schrieb Frank Morgner <mo...@in...>: > > >Yes, this would at least resolve the memory handling. However, the >second copy of the handle would still be useless though release has >never been called by the second client. > >Do you know how this is solved in Apple's implementation? > >Am 6. Juli 2015 09:27:09 MESZ, schrieb Ludovic Rousseau ><lud...@gm...>: >>2015-07-06 2:07 GMT+02:00 Frank Morgner >><mo...@in...>: >>> I think we have two problems here: >>> >>> 1. The only thing we should do is freeing the memory which gets >>copied >>> into the child's address space. And that's where I think we have >a >>> problem in pcsc-lite: >>> >>> I don't know the inner workings of pcsc-lite but I suppose when >>> calling SCardEstablishContext there will be some memory that can >>only >>> be free'd by calling SCardReleaseContext. This memory will exist >>in >>> the parent's and in the child's address space. But with David's >>log >>> it looks like pcsc-lite has a sanity check that disallows freeing >>the >>> same handle twice in SCardReleaseContext. >> >>You are right. >>pcsc-lite allocates some memory on the client side and also on the >>server side. >>After a fork the memory on the client side is duplicated, but nothing >>changes on the server side. >> >>Calling SCardReleaseContext will release the memory on 1 client and on >>the server. >>A second call to SCardReleaseContext will try to free resources on the >>server side but the server will then return an error (resources >>already freed). The memory on the client side will then NOT be freed. >> >>I can change the pcsc-lite code to free memory on the client side >>first before asking the server to free its memory. With this change a >>second call to SCardReleaseContext would still return an error but the >>memory on the client would be freed. >> >>That would solve a memory leak when fork() is used. >>I created a ticket >>https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085 >> >>Bye >> >>-- >> Dr. Ludovic Rousseau >> >>------------------------------------------------------------------------------ >>Don't Limit Your Business. Reach for the Cloud. >>GigeNET's Cloud Solutions provide you with the tools and support that >>you need to offload your IT needs and focus on growing your business. >>Configured For All Businesses. Start Your Cloud Today. >>https://www.gigenetcloud.com/ >>_______________________________________________ >>Opensc-devel mailing list >>Ope...@li... >>https://lists.sourceforge.net/lists/listinfo/opensc-devel > >-- >Frank Morgner >-- >Frank Morgner > >------------------------------------------------------------------------------ >Don't Limit Your Business. Reach for the Cloud. >GigeNET's Cloud Solutions provide you with the tools and support that >you need to offload your IT needs and focus on growing your business. >Configured For All Businesses. Start Your Cloud Today. >https://www.gigenetcloud.com/ >_______________________________________________ >Opensc-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Frank Morgner |
|
From: Frank M. <mo...@in...> - 2015-07-06 09:26:13
|
Yes, this would at least resolve the memory handling. However, the second copy of the handle would still be useless though release has never been called by the second client. Do you know how this is solved in Apple's implementation? Am 6. Juli 2015 09:27:09 MESZ, schrieb Ludovic Rousseau <lud...@gm...>: >2015-07-06 2:07 GMT+02:00 Frank Morgner ><mo...@in...>: >> I think we have two problems here: >> >> 1. The only thing we should do is freeing the memory which gets >copied >> into the child's address space. And that's where I think we have a >> problem in pcsc-lite: >> >> I don't know the inner workings of pcsc-lite but I suppose when >> calling SCardEstablishContext there will be some memory that can >only >> be free'd by calling SCardReleaseContext. This memory will exist >in >> the parent's and in the child's address space. But with David's >log >> it looks like pcsc-lite has a sanity check that disallows freeing >the >> same handle twice in SCardReleaseContext. > >You are right. >pcsc-lite allocates some memory on the client side and also on the >server side. >After a fork the memory on the client side is duplicated, but nothing >changes on the server side. > >Calling SCardReleaseContext will release the memory on 1 client and on >the server. >A second call to SCardReleaseContext will try to free resources on the >server side but the server will then return an error (resources >already freed). The memory on the client side will then NOT be freed. > >I can change the pcsc-lite code to free memory on the client side >first before asking the server to free its memory. With this change a >second call to SCardReleaseContext would still return an error but the >memory on the client would be freed. > >That would solve a memory leak when fork() is used. >I created a ticket >https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085 > >Bye > >-- > Dr. Ludovic Rousseau > >------------------------------------------------------------------------------ >Don't Limit Your Business. Reach for the Cloud. >GigeNET's Cloud Solutions provide you with the tools and support that >you need to offload your IT needs and focus on growing your business. >Configured For All Businesses. Start Your Cloud Today. >https://www.gigenetcloud.com/ >_______________________________________________ >Opensc-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Frank Morgner -- Frank Morgner |
|
From: Ludovic R. <lud...@gm...> - 2015-07-06 07:33:15
|
2015-07-06 2:07 GMT+02:00 Frank Morgner <mo...@in...>: > I think we have two problems here: > > 1. The only thing we should do is freeing the memory which gets copied > into the child's address space. And that's where I think we have a > problem in pcsc-lite: > > I don't know the inner workings of pcsc-lite but I suppose when > calling SCardEstablishContext there will be some memory that can only > be free'd by calling SCardReleaseContext. This memory will exist in > the parent's and in the child's address space. But with David's log > it looks like pcsc-lite has a sanity check that disallows freeing the > same handle twice in SCardReleaseContext. You are right. pcsc-lite allocates some memory on the client side and also on the server side. After a fork the memory on the client side is duplicated, but nothing changes on the server side. Calling SCardReleaseContext will release the memory on 1 client and on the server. A second call to SCardReleaseContext will try to free resources on the server side but the server will then return an error (resources already freed). The memory on the client side will then NOT be freed. I can change the pcsc-lite code to free memory on the client side first before asking the server to free its memory. With this change a second call to SCardReleaseContext would still return an error but the memory on the client would be freed. That would solve a memory leak when fork() is used. I created a ticket https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085 Bye -- Dr. Ludovic Rousseau |
|
From: Frank M. <mo...@in...> - 2015-07-06 00:10:51
|
I think we have two problems here: 1. The only thing we should do is freeing the memory which gets copied into the child's address space. And that's where I think we have a problem in pcsc-lite: I don't know the inner workings of pcsc-lite but I suppose when calling SCardEstablishContext there will be some memory that can only be free'd by calling SCardReleaseContext. This memory will exist in the parent's and in the child's address space. But with David's log it looks like pcsc-lite has a sanity check that disallows freeing the same handle twice in SCardReleaseContext. 2. We should not perform any "terminating" actions on the card when detecting a fork. This card belongs to the parent process and we should not touch it. That means that calling C_Finalize from C_Initialize as currently implemented is not correct. In that regard your changes, Nikos, look good, though I'd prefer something like `sc_terminate_context` instead of `sc_release_context_after_fork`. This would put the focus on the desired action (destroy the memory NOW instead of doing some additional magic) instead of the circumstances (being called after fork). This would raise readability/maintainability, I think. However, your current patch still leaks gpriv in reader-pcsc.c (because finish is not called). Right? Am Freitag, dem 03. Juli, um 10:10 Uhr schrieb Nikos Mavrogiannopoulos: > On Wed, May 6, 2015 at 1:37 AM, David Woodhouse <dw...@in...> wrote: > >> Here's a test case. I've verified that it fails with OpenSC with both > >> a PIV device (Yubikey NEO) and a Feitian ePass PKI token: > > And this "fixes" it, although obviously it's more of a proof of > > concept than something we could apply as-is: > > The issue is quite complex because shared resources are not > distinguished to per-process resources. I've attempted to solve it at > the C_Finalize() function with the following pull request: > https://github.com/OpenSC/OpenSC/pull/493 > > regards, > Nikos > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > 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: Jean-Marc <jea...@6j...> - 2015-07-03 22:10:11
|
Sun, 21 Jun 2015 14:25:52 +0200 Jean-Marc <jea...@6j...> écrivait : > hi, > > I made some tests with new eid belgian cards. > Unfortunately, it is not possible to access certs on new cards. > I checked a bit on eid doc' and the new cards have a new applet version v1.7. > > Any idea if this new applet will be implemented in openSC too ? I got in touch with the Fedict helpdesk and they told me someboy is preparing a patched version including the v1.7 applet usage but it is waiting for Fedict approval or something like that. Can you tell me if it is correct ? Regards, Jean-Marc <jea...@6j...> |
|
From: Nikos M. <n.m...@gm...> - 2015-07-03 08:10:59
|
On Wed, May 6, 2015 at 1:37 AM, David Woodhouse <dw...@in...> wrote: >> Here's a test case. I've verified that it fails with OpenSC with both >> a PIV device (Yubikey NEO) and a Feitian ePass PKI token: > And this "fixes" it, although obviously it's more of a proof of > concept than something we could apply as-is: The issue is quite complex because shared resources are not distinguished to per-process resources. I've attempted to solve it at the C_Finalize() function with the following pull request: https://github.com/OpenSC/OpenSC/pull/493 regards, Nikos |
|
From: Anders R. <and...@gm...> - 2015-06-29 05:34:51
|
Hi Card-lovers,
The following is NOT a Smart Card to Web interface but a scheme for communicating
between native applications and Web-pages, where such an application for example
could be something related to smart cards like a signature plugin:
https://github.com/cyberphone/web2native-bridge
The system is a fairly mature prototype running on Chrome/Chromium desktop browsers.
The purpose of the prototype is for concept verification and getting input on the design
of the API etc. The latter is very important so you are extremely welcome testing :-)
Cheers,
Anders
|
|
From: Frank M. <mo...@in...> - 2015-06-28 22:39:27
|
Hi! I can't really give a guide, but here you can find an example https://github.com/frankmorgner/vsmartcard/blob/master/npa/src/card-npa.c with its configuration file https://github.com/frankmorgner/vsmartcard/blob/master/npa/opensc.conf.in I hope, this helps! On Tuesday, June 16 at 09:49PM, Hammer, Tim wrote: > I have been unable to locate any documentation describing how to create an "external" card driver that is loaded by a directive in the conf file. The "New card driver" example and description seems to be only for a "built-in" driver. > > Can someone please help me with a better search string or a pointer to such a document? > > Thanks! > -- > .Tim > Tim D. Hammer > Software Developer > Global Business & Services Group > Xerox Corporation > M/S 0207-02Z > 800 Phillips Road > Webster, NY 14580 > > Phone: 585/427-1684 > Fax: 585/422-7532 > Mail: Tim...@xe...<mailto:Tim...@xe...> > > ------------------------------------------------------------------------------ > _______________________________________________ > 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: Jean-Marc <jea...@6j...> - 2015-06-21 13:45:04
|
hi, I made some tests with new eid belgian cards. Unfortunately, it is not possible to access certs on new cards. I checked a bit on eid doc' and the new cards have a new applet version v1.7. Any idea if this new applet will be implemented in openSC too ? Regards, Jean-Marc <jea...@6j...> |
|
From: Douglas E E. <dee...@gm...> - 2015-06-17 00:41:56
|
On 6/16/2015 4:49 PM, Hammer, Tim wrote: > I have been unable to locate any documentation describing how to create an “external” card driver that is loaded by a directive in the conf file. The “New card driver” example and description seems to > be only for a “built-in” driver. Not sure if there is any documentation on how to do this. One issue with external drivers is they can get out of sync with the rest of OpenSC, so all newer drivers have been internal. This allows the driver to get updated even if the original author or the code is not available. They also have to be built separately. look at load_card_drivers in ctx.c. Basicly the external driver is in its own library and is dynamically loaded. Each card driver both internal and external have one public function, sc_get_<name>_driver, that returns a sc_card_driver_t structure. External drivers have a sc_module_init that is used by the load_card_drivers. Hope this helps. > > Can someone please help me with a better search string or a pointer to such a document? > > Thanks! > > -- > > */.Tim/* > > *Tim D. Hammer > Software Developer > Global Business & Services Group > *Xerox Corporation > M/S 0207-02Z > 800 Phillips Road > Webster, NY 14580* > > *Phone: 585/427-1684 > Fax:585/422-7532 > Mail:Tim...@xe... <mailto:Tim...@xe...>// > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Hammer, T. <Tim...@xe...> - 2015-06-16 21:50:08
|
I have been unable to locate any documentation describing how to create an "external" card driver that is loaded by a directive in the conf file. The "New card driver" example and description seems to be only for a "built-in" driver. Can someone please help me with a better search string or a pointer to such a document? Thanks! -- .Tim Tim D. Hammer Software Developer Global Business & Services Group Xerox Corporation M/S 0207-02Z 800 Phillips Road Webster, NY 14580 Phone: 585/427-1684 Fax: 585/422-7532 Mail: Tim...@xe...<mailto:Tim...@xe...> |
|
From: latac <ben...@es...> - 2015-06-11 13:43:38
|
It works well with OpenSC 0.15.0 Thanks ! -- View this message in context: http://opensc.1086184.n5.nabble.com/Troubles-with-a-Gemalto-USB-token-tp15367p15371.html Sent from the Developer mailing list archive at Nabble.com. |
|
From: Thomas C. <cal...@gm...> - 2015-06-10 21:11:48
|
Hi, Douglas and Ludovic are right. You should try out compiling OpenSC 0.15.0. I worked on those IAS cards, it should work with the latest release. Bye. Thomas Le 10 juin 2015 10:34 PM, "Ludovic Rousseau" <lud...@gm...> a écrit : > Hello, > > 2015-06-10 13:46 GMT+02:00 Douglas E Engert <dee...@gm...>: > > > > > > On 6/10/2015 3:31 AM, latac wrote: > >> Hello > >> > >> I have troubles with a Gemalto USB token. It is listed as supported > >> on OpenSC wiki, but OpenSC is unable to use it. > > > > The Wiki is at: > > > https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-(smart-cards-and-USB-tokens) > > > > Can you point out where it says it is supported? > > It may be supported by pcsc, but not by OpenSC. > > > > It might also need to be initialized, or have some applet loaded to work > with OpenSC. > > > > Google for: OpenSC Gemalto USB Shell Token > > > > May be a virtualization problem: > > > http://opensc.1086184.n5.nabble.com/Smartcard-recognized-by-pcsc-scan-but-not-opensc-tools-td13768.html > > > >> > >> Here is what happens: > >> $ opensc-tool -n > >> Using reader with a card: Gemalto USB Shell Token V2 (3F91D002) 00 00 > >> Unsupported card > > > > Says it is not supported. > > OpenSC-0.13.0 is from 2012, 0.15.0 is from 2015, maybe the support is in > 0.15.0. > > The "Gemalto USB Shell Token V2" is not a token but a smart card > reader with a SIM size smart card in it. > The problem is not with the smart card reader but with the smart card > inserted in the reader. > > >> Here is the configuration: > >> USB token "Gemalto USB Shell Token V2 (3F91D002)" > >> > >> PCSC-lite version: > >> pcsc-lite version 1.8.10. > >> Copyright (C) 1999-2002 by David Corcoran <cor...@li...>. > >> Copyright (C) 2001-2011 by Ludovic Rousseau < > lud...@fr...>. > >> Copyright (C) 2003-2004 by Damien Sauveron <sau...@la...>. > >> Report bugs to <mu...@li...>. > >> Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev > >> usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd > >> configdir=/etc/reader.conf.d > >> > >> CCID version: > >> CCID 1.4.15 > >> > >> OpenSC version: > >> opensc 0.13.0 [gcc 4.8.2] > >> Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) > >> > >> OS version: > >> Ubuntu 14.04 LTS > >> Linux virtual-ubuntu 3.16.0-36-generic #48~14.04.1-Ubuntu SMP Wed > Apr 15 > >> 13:11:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > >> > >> And attached is the pcscd log. > >> log.txt <http://opensc.1086184.n5.nabble.com/file/n15367/log.txt> > > > > What is output of: opensc-tool -a > > According to the log the ATR is > 3B 7F 96 00 00 00 31 B8 64 40 F3 85 10 73 94 01 80 82 90 00 > > According to > https://smartcard-atr.appspot.com/parse?ATR=3B7F9600000031B86440F3851073940180829000 > the card is a "IAS ECC Type 1". > > I don't know if this smart card is supported by OpenSC. > > Bye > > -- > Dr. Ludovic Rousseau > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: Ludovic R. <lud...@gm...> - 2015-06-10 20:33:31
|
Hello, 2015-06-10 13:46 GMT+02:00 Douglas E Engert <dee...@gm...>: > > > On 6/10/2015 3:31 AM, latac wrote: >> Hello >> >> I have troubles with a Gemalto USB token. It is listed as supported >> on OpenSC wiki, but OpenSC is unable to use it. > > The Wiki is at: > https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-(smart-cards-and-USB-tokens) > > Can you point out where it says it is supported? > It may be supported by pcsc, but not by OpenSC. > > It might also need to be initialized, or have some applet loaded to work with OpenSC. > > Google for: OpenSC Gemalto USB Shell Token > > May be a virtualization problem: > http://opensc.1086184.n5.nabble.com/Smartcard-recognized-by-pcsc-scan-but-not-opensc-tools-td13768.html > >> >> Here is what happens: >> $ opensc-tool -n >> Using reader with a card: Gemalto USB Shell Token V2 (3F91D002) 00 00 >> Unsupported card > > Says it is not supported. > OpenSC-0.13.0 is from 2012, 0.15.0 is from 2015, maybe the support is in 0.15.0. The "Gemalto USB Shell Token V2" is not a token but a smart card reader with a SIM size smart card in it. The problem is not with the smart card reader but with the smart card inserted in the reader. >> Here is the configuration: >> USB token "Gemalto USB Shell Token V2 (3F91D002)" >> >> PCSC-lite version: >> pcsc-lite version 1.8.10. >> Copyright (C) 1999-2002 by David Corcoran <cor...@li...>. >> Copyright (C) 2001-2011 by Ludovic Rousseau <lud...@fr...>. >> Copyright (C) 2003-2004 by Damien Sauveron <sau...@la...>. >> Report bugs to <mu...@li...>. >> Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev >> usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd >> configdir=/etc/reader.conf.d >> >> CCID version: >> CCID 1.4.15 >> >> OpenSC version: >> opensc 0.13.0 [gcc 4.8.2] >> Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) >> >> OS version: >> Ubuntu 14.04 LTS >> Linux virtual-ubuntu 3.16.0-36-generic #48~14.04.1-Ubuntu SMP Wed Apr 15 >> 13:11:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> And attached is the pcscd log. >> log.txt <http://opensc.1086184.n5.nabble.com/file/n15367/log.txt> > > What is output of: opensc-tool -a According to the log the ATR is 3B 7F 96 00 00 00 31 B8 64 40 F3 85 10 73 94 01 80 82 90 00 According to https://smartcard-atr.appspot.com/parse?ATR=3B7F9600000031B86440F3851073940180829000 the card is a "IAS ECC Type 1". I don't know if this smart card is supported by OpenSC. Bye -- Dr. Ludovic Rousseau |
|
From: Douglas E E. <dee...@gm...> - 2015-06-10 11:52:36
|
On 6/10/2015 3:31 AM, latac wrote: > Hello > > I have troubles with a Gemalto USB token. It is listed as supported > on OpenSC wiki, but OpenSC is unable to use it. The Wiki is at: https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-(smart-cards-and-USB-tokens) Can you point out where it says it is supported? It may be supported by pcsc, but not by OpenSC. It might also need to be initialized, or have some applet loaded to work with OpenSC. Google for: OpenSC Gemalto USB Shell Token May be a virtualization problem: http://opensc.1086184.n5.nabble.com/Smartcard-recognized-by-pcsc-scan-but-not-opensc-tools-td13768.html > > Here is what happens: > $ opensc-tool -n > Using reader with a card: Gemalto USB Shell Token V2 (3F91D002) 00 00 > Unsupported card Says it is not supported. OpenSC-0.13.0 is from 2012, 0.15.0 is from 2015, maybe the support is in 0.15.0. > > Here is the configuration: > USB token "Gemalto USB Shell Token V2 (3F91D002)" > > PCSC-lite version: > pcsc-lite version 1.8.10. > Copyright (C) 1999-2002 by David Corcoran <cor...@li...>. > Copyright (C) 2001-2011 by Ludovic Rousseau <lud...@fr...>. > Copyright (C) 2003-2004 by Damien Sauveron <sau...@la...>. > Report bugs to <mu...@li...>. > Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev > usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd > configdir=/etc/reader.conf.d > > CCID version: > CCID 1.4.15 > > OpenSC version: > opensc 0.13.0 [gcc 4.8.2] > Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) > > OS version: > Ubuntu 14.04 LTS > Linux virtual-ubuntu 3.16.0-36-generic #48~14.04.1-Ubuntu SMP Wed Apr 15 > 13:11:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > And attached is the pcscd log. > log.txt <http://opensc.1086184.n5.nabble.com/file/n15367/log.txt> What is output of: opensc-tool -a > > > -- > View this message in context: http://opensc.1086184.n5.nabble.com/Troubles-with-a-Gemalto-USB-token-tp15367.html > Sent from the Developer mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: latac <ben...@es...> - 2015-06-10 08:31:23
|
Hello I have troubles with a Gemalto USB token. It is listed as supported on OpenSC wiki, but OpenSC is unable to use it. Here is what happens: $ opensc-tool -n Using reader with a card: Gemalto USB Shell Token V2 (3F91D002) 00 00 Unsupported card Here is the configuration: USB token "Gemalto USB Shell Token V2 (3F91D002)" PCSC-lite version: pcsc-lite version 1.8.10. Copyright (C) 1999-2002 by David Corcoran <cor...@li...>. Copyright (C) 2001-2011 by Ludovic Rousseau <lud...@fr...>. Copyright (C) 2003-2004 by Damien Sauveron <sau...@la...>. Report bugs to <mu...@li...>. Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/etc/reader.conf.d CCID version: CCID 1.4.15 OpenSC version: opensc 0.13.0 [gcc 4.8.2] Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) OS version: Ubuntu 14.04 LTS Linux virtual-ubuntu 3.16.0-36-generic #48~14.04.1-Ubuntu SMP Wed Apr 15 13:11:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux And attached is the pcscd log. log.txt <http://opensc.1086184.n5.nabble.com/file/n15367/log.txt> -- View this message in context: http://opensc.1086184.n5.nabble.com/Troubles-with-a-Gemalto-USB-token-tp15367.html Sent from the Developer mailing list archive at Nabble.com. |
|
From: Douglas E E. <dee...@gm...> - 2015-06-04 10:29:48
|
On 6/4/2015 4:16 AM, Frank Morgner wrote:
> We've discussed this kind of issue earlier. Yes, we need to fix those issues if we can. In the past couple of month we fixed a lot of issues that were discovered by static code analysis, for this
> reason. However, we still believe that a malicious card requires more or less physical access to the machine. With this premise there are a number of problems arising that are currently more likely to
> be exploited.
If the machine is accessible via Remote Desktop(windows) or rdesktop(linux) the attacked does not have to have
physical access. The OpenSC code is run on the machine, not the attacker's machine.
>
>
> Am 3. Juni 2015 18:41:47 MESZ, schrieb Douglas E Engert <dee...@gm...>:
>
> Good point. A card to designed to cause a segfault... We really do need to make sure we don't segfault.
>
> On 6/3/2015 3:44 AM, Dirk-Willem van Gulik wrote:
>
>
> On 02 Jun 2015, at 18:36, Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote:
>
>
>
> On 6/2/2015 10:32 AM, Dirk-Willem van Gulik wrote:
>
> We seem to be a bit trusting of the cruft which can be on a card; found I needed below to stop naughty cards
> from causing segfaults (and hence locking subsequent users out of their desktops (a bit of fragility outside OpenSC)).
>
> ! Just wondering - is this sort of thing common (and should I scan most of the code for this) — or have i found a rare case ?
>
>
> It depends. The part of OpenSC that tries to determine the type of card, would be more likely to run into "naughty cards"
> or cards that don't follow all the standards or cards that have not been initialized as expected.
>
> Cards that may have worked with older versions of OpenSC, may not work with newer versions, as newer code
> may not have been tested against the older cards For example There are cards that emulate PKCS#15 and newer code
> added to OpenSC for example the sc_enum_apps() may not be emulated correctly. For example the ODF in older code
> does not need to be emulated. Not clear if it does now.
>
> Older versions of cards that may have worked before. But newer versions of the card or the files on new cards
> are not the same as before because the card issuer changed something.
> Can you say what cards caused these problems?
>
>
> We dove into this because we saw a card specifically designed to make (login) daemons segfault (and hence fall back to lesser systems due to non ideal designed processes).
>
> This is basically an organisational/procedure attack - where a DoS leads to the human/apparatus complex to do unsafe things to tide over; and the exploit is then there; not in OpenSC per-se.
>
> By pure co-incidence (going through old logs) we discovered that various AET cards; including a card issued to most Dutch civil servants also causes pretty much all opensc tools (and pkcs11/15) to
> segfault.
>
> In this case it is more ‘silly’ — cards respond to queries with a:
>
> {
> (char []) "I am the SafeSign Applet of A.E.T. Europe B.V. please authenticate yourself\n”,
> 0x90, 0x00
> }
>
> that confuses OpenSC enough to segfault in various places on mere insertion/que! ry.
>
> Dw.
>
>
>
> Dw.
>
> https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff
>
> src/libopensc/dir.c
> @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card)
> r = sc_select_file(card, &path, &card->ef_dir);
> LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file");
>
> +if (card->ef_dir == NULL) {
> +LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant.");
> +}
> +
> if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) {
> sc_file_free(card->ef_dir);
> card->ef_dir = NULL;
>
> src/libopensc/pkcs15.c
> @@! -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid)
> sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err);
> goto end;
> }
> +if (p15card->file_odf == NULL) {
> +sc_log(ctx, "After making absolute path to EF(ODF) still no odf.");
> +goto end;
> +}
> sc_log(ctx, "absolute path to EF(ODF) %s", sc_print_path(&tmppath));
> err = sc_select_file(card, &tmppath, &p15card->file_odf);
> }
> @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid)
> goto end;
> }
>
> +assert(p15card->file_odf);
> +
> len = p15card->file_odf->size;
> if (!len) {
> sc_log(ctx, "EF(ODF) is empty”);
>
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Opensc-devel mailing list
> Ope...@li... <mailto:Ope...@li...>
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>
>
> --
>
> Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>>
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Opensc-devel mailing list
> Ope...@li... <mailto:Ope...@li...>
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>
>
> --
> Frank Morgner
--
Douglas E. Engert <DEE...@gm...>
|
|
From: Dirk-Willem v. G. <di...@we...> - 2015-06-04 09:37:48
|
On 04 Jun 2015, at 11:16, Frank Morgner <mo...@in...> wrote: > We've discussed this kind of issue earlier. Yes, we need to fix those issues if we can. In the past couple of month we fixed a lot of issues that were discovered by static code analysis, for this reason. However, we still believe that a malicious card requires more or less physical access to the machine. With this premise there are a number of problems arising that are currently more likely to be exploited. Right - may be good to stress here that in this case the original vector was RFID ‘cards’. We’re fairly sure it was a virtual card/emulated thing - and likely not physically that near either. Dw. |
|
From: Frank M. <mo...@in...> - 2015-06-04 09:16:30
|
We've discussed this kind of issue earlier. Yes, we need to fix those issues if we can. In the past couple of month we fixed a lot of issues that were discovered by static code analysis, for this reason. However, we still believe that a malicious card requires more or less physical access to the machine. With this premise there are a number of problems arising that are currently more likely to be exploited.
Am 3. Juni 2015 18:41:47 MESZ, schrieb Douglas E Engert <dee...@gm...>:
>Good point. A card to designed to cause a segfault... We really do
>need to make sure we don't segfault.
>
>On 6/3/2015 3:44 AM, Dirk-Willem van Gulik wrote:
>>
>>> On 02 Jun 2015, at 18:36, Douglas E Engert <dee...@gm...
><mailto:dee...@gm...>> wrote:
>>>
>>>
>>>
>>> On 6/2/2015 10:32 AM, Dirk-Willem van Gulik wrote:
>>>> We seem to be a bit trusting of the cruft which can be on a card;
>found I needed below to stop naughty cards
>>>> from causing segfaults (and hence locking subsequent users out of
>their desktops (a bit of fragility outside OpenSC)).
>>>>
>>>> Just wondering - is this sort of thing common (and should I scan
>most of the code for this) — or have i found a rare case ?
>>>
>>> It depends. The part of OpenSC that tries to determine the type of
>card, would be more likely to run into "naughty cards"
>>> or cards that don't follow all the standards or cards that have not
>been initialized as expected.
>>>
>>> Cards that may have worked with older versions of OpenSC, may not
>work with newer versions, as newer code
>>> may not have been tested against the older cards For example There
>are cards that emulate PKCS#15 and newer code
>>> added to OpenSC for example the sc_enum_apps() may not be emulated
>correctly. For example the ODF in older code
>>> does not need to be emulated. Not clear if it does now.
>>>
>>> Older versions of cards that may have worked before. But newer
>versions of the card or the files on new cards
>>> are not the same as before because the card issuer changed
>something.
>>>
>>> Can you say what cards caused these problems?
>>
>> We dove into this because we saw a card specifically designed to make
>(login) daemons segfault (and hence fall back to lesser systems due to
>non ideal designed processes).
>>
>> This is basically an organisational/procedure attack - where a DoS
>leads to the human/apparatus complex to do unsafe things to tide over;
>and the exploit is then there; not in OpenSC per-se.
>>
>> By pure co-incidence (going through old logs) we discovered that
>various AET cards; including a card issued to most Dutch civil servants
>also causes pretty much all opensc tools (and pkcs11/15) to
>> segfault.
>>
>> In this case it is more ‘silly’ — cards respond to queries with a:
>>
>> {
>> (char []) "I am the SafeSign Applet of A.E.T. Europe B.V. please
>authenticate yourself\n”,
>> 0x90, 0x00
>> }
>>
>> that confuses OpenSC enough to segfault in various places on mere
>insertion/query.
>>
>> Dw.
>>
>>>
>>>>
>>>> Dw.
>>>>
>>>>
>https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff
>>>>
>>>> src/libopensc/dir.c
>>>> @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card)
>>>> r = sc_select_file(card, &path, &card->ef_dir);
>>>> LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file");
>>>>
>>>> +if (card->ef_dir == NULL) {
>>>> +LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant.");
>>>> +}
>>>> +
>>>> if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) {
>>>> sc_file_free(card->ef_dir);
>>>> card->ef_dir = NULL;
>>>>
>>>> src/libopensc/pkcs15.c
>>>> @@ -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct
>sc_pkcs15_card *p15card, struct sc_aid *aid)
>>>> sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err);
>>>> goto end;
>>>> }
>>>> +if (p15card->file_odf == NULL) {
>>>> +sc_log(ctx, "After making absolute path to EF(ODF) still no
>odf.");
>>>> +goto end;
>>>> +}
>>>> sc_log(ctx, "absolute path to EF(ODF) %s",
>sc_print_path(&tmppath));
>>>> err = sc_select_file(card, &tmppath, &p15card->file_odf);
>>>> }
>>>> @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card
>*p15card, struct sc_aid *aid)
>>>> goto end;
>>>> }
>>>>
>>>> +assert(p15card->file_odf);
>>>> +
>>>> len = p15card->file_odf->size;
>>>> if (!len) {
>>>> sc_log(ctx, "EF(ODF) is empty”);
>>>>
>>>>
>>>>
>>>>
>------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> Ope...@li...
><mailto:Ope...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>
>>> --
>>>
>>> Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>>
>>>
>>>
>>>
>------------------------------------------------------------------------------
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> Ope...@li...
><mailto: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 |
|
From: Douglas E E. <dee...@gm...> - 2015-06-03 16:47:42
|
Good point. A card to designed to cause a segfault... We really do need to make sure we don't segfault.
On 6/3/2015 3:44 AM, Dirk-Willem van Gulik wrote:
>
>> On 02 Jun 2015, at 18:36, Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote:
>>
>>
>>
>> On 6/2/2015 10:32 AM, Dirk-Willem van Gulik wrote:
>>> We seem to be a bit trusting of the cruft which can be on a card; found I needed below to stop naughty cards
>>> from causing segfaults (and hence locking subsequent users out of their desktops (a bit of fragility outside OpenSC)).
>>>
>>> Just wondering - is this sort of thing common (and should I scan most of the code for this) — or have i found a rare case ?
>>
>> It depends. The part of OpenSC that tries to determine the type of card, would be more likely to run into "naughty cards"
>> or cards that don't follow all the standards or cards that have not been initialized as expected.
>>
>> Cards that may have worked with older versions of OpenSC, may not work with newer versions, as newer code
>> may not have been tested against the older cards For example There are cards that emulate PKCS#15 and newer code
>> added to OpenSC for example the sc_enum_apps() may not be emulated correctly. For example the ODF in older code
>> does not need to be emulated. Not clear if it does now.
>>
>> Older versions of cards that may have worked before. But newer versions of the card or the files on new cards
>> are not the same as before because the card issuer changed something.
>>
>> Can you say what cards caused these problems?
>
> We dove into this because we saw a card specifically designed to make (login) daemons segfault (and hence fall back to lesser systems due to non ideal designed processes).
>
> This is basically an organisational/procedure attack - where a DoS leads to the human/apparatus complex to do unsafe things to tide over; and the exploit is then there; not in OpenSC per-se.
>
> By pure co-incidence (going through old logs) we discovered that various AET cards; including a card issued to most Dutch civil servants also causes pretty much all opensc tools (and pkcs11/15) to
> segfault.
>
> In this case it is more ‘silly’ — cards respond to queries with a:
>
> {
> (char []) "I am the SafeSign Applet of A.E.T. Europe B.V. please authenticate yourself\n”,
> 0x90, 0x00
> }
>
> that confuses OpenSC enough to segfault in various places on mere insertion/query.
>
> Dw.
>
>>
>>>
>>> Dw.
>>>
>>> https://github.com/OpenSC/OpenSC/commit/1061b5ded0edbc6a1f2cb4fd599b7c950ffe18ff
>>>
>>> src/libopensc/dir.c
>>> @@ -149,6 +149,10 @@ int sc_enum_apps(sc_card_t *card)
>>> r = sc_select_file(card, &path, &card->ef_dir);
>>> LOG_TEST_RET(ctx, r, "Cannot select EF.DIR file");
>>>
>>> +if (card->ef_dir == NULL) {
>>> +LOG_TEST_RET(ctx, SC_ERROR_INVALID_CARD, "EF(DIR) nonexistant.");
>>> +}
>>> +
>>> if (card->ef_dir->type != SC_FILE_TYPE_WORKING_EF) {
>>> sc_file_free(card->ef_dir);
>>> card->ef_dir = NULL;
>>>
>>> src/libopensc/pkcs15.c
>>> @@ -1044,6 +1044,10 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid)
>>> sc_log(ctx, "Cannot make absolute path to EF(ODF); error:%i", err);
>>> goto end;
>>> }
>>> +if (p15card->file_odf == NULL) {
>>> +sc_log(ctx, "After making absolute path to EF(ODF) still no odf.");
>>> +goto end;
>>> +}
>>> sc_log(ctx, "absolute path to EF(ODF) %s", sc_print_path(&tmppath));
>>> err = sc_select_file(card, &tmppath, &p15card->file_odf);
>>> }
>>> @@ -1059,6 +1063,8 @@ sc_pkcs15_bind_internal(struct sc_pkcs15_card *p15card, struct sc_aid *aid)
>>> goto end;
>>> }
>>>
>>> +assert(p15card->file_odf);
>>> +
>>> len = p15card->file_odf->size;
>>> if (!len) {
>>> sc_log(ctx, "EF(ODF) is empty”);
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> Ope...@li... <mailto:Ope...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>> --
>>
>> Douglas E. Engert <DEE...@gm... <mailto:DEE...@gm...>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li... <mailto:Ope...@li...>
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
--
Douglas E. Engert <DEE...@gm...>
|
|
From: <J.W...@mi...> - 2015-06-03 14:41:14
|
-----Original Message----- From: Anders Rundgren [mailto:and...@gm...] Sent: vrijdag 29 mei 2015 21:26 To: OpenSC Subject: [Opensc-devel] Google's secure micro-SD http://www.cnet.com/news/googles-project-vault-is-a-security-chip-disguised-as-an-micro-sd-card/ This is a pretty strange thing since both ARM and Intel offer built-in security solutions in the CPU itself. Anders -----Original Message----- Most interesting part is that their storage range from 8GB till 64GB. Question remain how secure their "secure solution" is. Is it just "A system on a chip", or does it really uses a crypto co-processor, like they do at smartcard_hsm? ______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. |
5 messages has been excluded from this view by a project administrator.
