[opensc-devel] Support for C_InitializeToken and C_InitPIN

[Andreas Schwier (ML)]

Dear all,

we've created a pull request towards OpenSC/staging in order to
implement support for PKCS#11 like token initialization and PIN
management [1].

This patch shall allow a token to perform a one-step initialization
rather than deleting the individual PKCS#15 objects from the card. The
patch is in particular useful for cards using the PKCS#15 emulation
layer. The patch also adds the ability to pass hardware and firmware
information from the PKCS#15 level into the PKCS#11 level.

C_InitializeToken and C_InitPIN are used by some PKCS#11 aware
application (like XCA) to perform a complete re-initialization of the
token, removing all keys and resetting the SO and user PIN.

Please review and comment on github.

Kind regards,

Andreas

[1] https://github.com/OpenSC/OpenSC/pull/96

-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

Re: [opensc-devel] W3C takes on Web+SecurityElements

[Andreas Schwier (ML)]

Hi Anders,

of course I know your concept around SKS.

My point is, that the security of the key provisioning mechanism must be
grounded in the device itself. And because it is a limited device, the
mechanisms must be a little more smart card friendly. That's why we
designed the solution using standard based chip authentication, secure
messaging and card verifiable certificates as they are widely used in
passports, eID cards and electronic driving licenses. Rather than
reinventing the wheel, we allow CAs to use what they already have (e.g.
have an EJBCA with support for CVCs).

Andreas



Am 03.10.2012 16:44, schrieb Anders Rundgren:
> On 2012-10-03 14:42, Andreas Schwier (ML) wrote:
>> Hi Anders,
> 
> Hi Andreas,
> 
>>
>> fine, just another API to access smart cards, token or secure elements -
>> this time using APDUs from within JavaScript. Why not ?
>>
>> I just don't see the application for it. What problem are they going to
>> solve ?
>>
>> Would I trust some foreign JavaScript code in my browser to freely
>> access my smart card ?
>>
>> The only real justification left for smart cards, token or secure
>> elements is to manage cryptographic keys and to perform operations that
>> require some kind of trusted execution environment (e.g. card based risk
>> management in EMV, totalling VAT in a fiscal meter). Storing plain data
>> on smart cards is a left-over from the early off-line days and is pretty
>> much useless in an always on-line world.
>>
>> Given that, there are two problems to solve:
>>
>> a) Allow applications (on the desktop, on the web or as app) to access
>> keys on the smart card, token and secure element.
>>
>> b) Manage (create, certify, import, export and delete) keys on the smart
>> card, token and secure element.
>>
>> a) is pretty well solved using standards like PKCS#11, CSP Minidriver or
>> JCE. However, controlling access to the keys needs to be carefully
>> managed (using PIN-PAD readers or educating users to "don't leave the
>> key in the lock").
> 
> We might mot agree on all this but you're IMO basically right.
> 
> 
>> b) is a little more tricky, as it requires a certain level of trust in
>> the device where keys are to be stored. This trust level can be either
>> based on the central model "I - the CA - purchase the device and put the
>> keys into it" or the de-centralized model "I trust the manufacturer or
>> issuer of the device to create a genuine device".
>>
>> The central model is pretty much what PKI operators are doing today:
>> They purchase a device and - in a trusted environment - put keys and
>> certificates into it.
>>
>> The de-centralized model is little more complicated, as the issuer might
>> be a national authority, a mobile network operator, a mobile device
>> manufacturer, a bank or a private operation. Quite often these issuers
>> have no interest to allow others to issue certificates for keys on the
>> device they had to paid for - or they just don't see the benefit of the
>> next big think.
>>
>> Here comes the user centric model: Let the user decide where to store
>> the keys and allow the CA to determine how trustful that device is:
>> Might be a software token, a hardware token or a hardware token with a
>> trusted provisioning mechanism. If the CA knows, that the keys are
>> stored on a genuine device and asserts that a validated identity is
>> linked to that key, then we don't need any further identity management
>> scheme.
> 
> yes, this is exactly the thinking behind SKS/KeyGen2:
> 
> http://webpki.org/auth-token-4-the-cloud.html
> 
> 
>> I pretty much like the StartSSL approach: Once you've proved your
>> identity by submitting copies of two id documents, paying a fee and
>> answering a phone call, they will issue certificates for "things you
>> own" like domains and e-mail addresses. The next level could be "keys
>> you own, that can not be duplicated and only stolen physically".
>>
>> I guess the trusted provisioning mechanism is what we need to work on
>> (and already do as far as we are concerned).
> 
> You should consider SKS a contender in this space.  However, SKS is also
> about creating a standardized SE, something the smart card industry has
> proved very unwilling to do (they sort of live on NDAs...).
> 
> IMO, *a standard SE is a requirement for success*.  Jean-Michel, do you hear 
> me? :-) :-)
> 
> Anders
> 
>>
>> Andreas
>>
>>
>> Am 03.10.2012 13:23, schrieb Anders Rundgren:
>

Re: [opensc-devel] W3C takes on Web+SecurityElements

[Andreas Schwier (ML)]

Hi Anders,

fine, just another API to access smart cards, token or secure elements -
this time using APDUs from within JavaScript. Why not ?

I just don't see the application for it. What problem are they going to
solve ?

Would I trust some foreign JavaScript code in my browser to freely
access my smart card ?

The only real justification left for smart cards, token or secure
elements is to manage cryptographic keys and to perform operations that
require some kind of trusted execution environment (e.g. card based risk
management in EMV, totalling VAT in a fiscal meter). Storing plain data
on smart cards is a left-over from the early off-line days and is pretty
much useless in an always on-line world.

Given that, there are two problems to solve:

a) Allow applications (on the desktop, on the web or as app) to access
keys on the smart card, token and secure element.

b) Manage (create, certify, import, export and delete) keys on the smart
card, token and secure element.

a) is pretty well solved using standards like PKCS#11, CSP Minidriver or
JCE. However, controlling access to the keys needs to be carefully
managed (using PIN-PAD readers or educating users to "don't leave the
key in the lock").

b) is a little more tricky, as it requires a certain level of trust in
the device where keys are to be stored. This trust level can be either
based on the central model "I - the CA - purchase the device and put the
keys into it" or the de-centralized model "I trust the manufacturer or
issuer of the device to create a genuine device".

The central model is pretty much what PKI operators are doing today:
They purchase a device and - in a trusted environment - put keys and
certificates into it.

The de-centralized model is little more complicated, as the issuer might
be a national authority, a mobile network operator, a mobile device
manufacturer, a bank or a private operation. Quite often these issuers
have no interest to allow others to issue certificates for keys on the
device they had to paid for - or they just don't see the benefit of the
next big think.

Here comes the user centric model: Let the user decide where to store
the keys and allow the CA to determine how trustful that device is:
Might be a software token, a hardware token or a hardware token with a
trusted provisioning mechanism. If the CA knows, that the keys are
stored on a genuine device and asserts that a validated identity is
linked to that key, then we don't need any further identity management
scheme.

I pretty much like the StartSSL approach: Once you've proved your
identity by submitting copies of two id documents, paying a fee and
answering a phone call, they will issue certificates for "things you
own" like domains and e-mail addresses. The next level could be "keys
you own, that can not be duplicated and only stolen physically".

I guess the trusted provisioning mechanism is what we need to work on
(and already do as far as we are concerned).

Andreas


Am 03.10.2012 13:23, schrieb Anders Rundgren:
> On 2012-10-03 12:08, Andreas Schwier (ML) wrote:
>> So why do you think the smart card industry has never managed to get
>> their stuff "web compatible" ?
>>
>> Isn't OpenSC the best example that "Yes, you can access a protected
>> website / webapplication / webservice using a smart card and standard
>> based technology" works ?
>>
>> The issue really is, that the topic at hand (PKI) is way to complex for
>> the average Doe to manage. That's always the downside: Security often
>> means complexity and comes with a price tag. And if it is complex, hard
>> to understand and someone offers some cheaper snake-oil, I probably go
>> for that.
>>
>> Rather than exposing the complexity of the matter with a zoo of options
>> you can choose from, we need to focus on a single generic mechanism and
>> a well designed user experience.
>>
>> It's all there (meaning S/MIME and TLS), it just needs to become a
>> little simpler to manage. So rather than re-inventing the n-solution for
>> Web-ID, SSO or One-Time-Passwords, we - as a community - should improve
>> what is already existing.
> 
> What do you decipher from the following?
> 
> http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0058.html
> 
> Anders
> 
> 
>>
>> Andreas
>>
>>
>>
>>
>>
>>
>> Am 03.10.2012 11:09, schrieb Anders Rundgren:
>>> http://www.w3.org/2012/09/sysapps-wg-charter 
>>> <http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charter&urlhash=Tqzg&_t=tracking_disc>
>>>
>>> Since the smart card industry have never managed making their stuff "web 
>>> compatible" be

Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required

[Andreas Schwier (ML)]

Am 03.10.2012 12:08, schrieb Jean-Michel Pouré - GOOZE:
>> did anyone try the issue tracking and wiki functions on github ? Seems
>> that it provides the same functionality as trac. 
> 
> You are right.
> 
> Github features:
> https://github.com/features/projects
> 
> The issue tracking is already in use:
> https://github.com/OpenSC/OpenSC/issues
> 
> But I don't understand how to use the Wiki.
> It could be nice to migrate the wiki and clean it.
> 
> The issue with Github is that the whole team should be listed.
> Not one or two people like previously.
> 
> The members now are listed here:
> https://github.com/OpenSC?tab=members
> 
> Ludovik, Martin and Viktor.
> 
> IMHO we need more people for a community project.
> A team of 10 would be nice.

I think it's not a matter of how many people are on the list, but how
responsive people are.

Having worked in the project for a couple of weeks now, I'm quite
confident that we have the right people in the right places.

> 
> Kind regards,
> Jean-Michel
> 
> 


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

Re: [opensc-devel] W3C takes on Web+SecurityElements

[Andreas Schwier (ML)]

So why do you think the smart card industry has never managed to get
their stuff "web compatible" ?

Isn't OpenSC the best example that "Yes, you can access a protected
website / webapplication / webservice using a smart card and standard
based technology" works ?

The issue really is, that the topic at hand (PKI) is way to complex for
the average Doe to manage. That's always the downside: Security often
means complexity and comes with a price tag. And if it is complex, hard
to understand and someone offers some cheaper snake-oil, I probably go
for that.

Rather than exposing the complexity of the matter with a zoo of options
you can choose from, we need to focus on a single generic mechanism and
a well designed user experience.

It's all there (meaning S/MIME and TLS), it just needs to become a
little simpler to manage. So rather than re-inventing the n-solution for
Web-ID, SSO or One-Time-Passwords, we - as a community - should improve
what is already existing.

Andreas






Am 03.10.2012 11:09, schrieb Anders Rundgren:
> http://www.w3.org/2012/09/sysapps-wg-charter 
> 
>
> Since the smart card industry have never managed making their stuff "web 
> compatible" before, I assume they will fail this time as well.
>
> Anders
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required

[Andreas Schwier (ML)]

Hi,

did anyone try the issue tracking and wiki functions on github ? Seems
that it provides the same functionality as trac.

Migrating the data might be a pain, but also gives the opportunity to
clean things up.

I would prefer a solution where everything is nicely integrated.

Other than that, I agree with Viktor to use the existing CI service and
move the other parts there.

Andreas


Am 03.10.2012 09:43, schrieb Viktor Tarasov:
>
> Hello Andreas,
>
> On Tue, Oct 2, 2012 at 11:13 PM, Andreas Jellinghaus
> mailto:andr...@ionisiert.de>> wrote:
>
> So, have you agreed on something? I read different opinions,
> offers, comments, but nothing that points out coming to some
> consent. What is your preference? Since I'm not really active, I
> don't want to decide this.
>
> I checked googlegroups and code.google.com
> , worst case I can figure out how to
> copy/move things there.
>
>
> I will look into code.google.com , but beside
> this,
> one of the solution could be to :
> - move the sources of the projects to github;
> - use my CI service for nightly builds;
> - install on the same platform file server for release tarbals, RPMs,
> MSIs, etc;
> - move onto the same platform wiki, trac and mailing lists.
>
> If there will not be other suggestions, 
> and if the study of the googlegroups or similar will not bring other
> solution,
> we could start the migration.
>
>  
>
> Regards, Andreas
>
>
>
> Kind regards,
> Viktor.
>  
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> 
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

[opensc-devel] Testing

[Andreas Schwier (ML)]

Hi Viktor,

we've tested the nightly build (OpenSC-git20121002092635-win32.msi) that
includes write support for the SmartCard-HSM and found no issues.

We've tested with our own PKCS#11 test suite, integration with Firefox
15.0.1 and Thunderbird 15.0.1 on Windows XP SP3.

Will there be a new release candidate ?

Andreas

-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

[opensc-devel] SIGV when deleting certificate but not related public key

[Andreas Schwier (ML)]

Hi all,

there is apparently a nasty bug in framework-pkcs15.c that causes a SIGV
when via PKCS#11 a certificate object is deleted, but not the related
public key object.

Occasionally this triggers a SIGV when the caller later accesses the
CKA_ID attribute which tries to access the then deleted certificate object.

Is there any expert on the list that has intimate knowledge of the
framework code that could take a look at it ?

Andreas


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

[opensc-devel] Strange issue in framework-pkcs15.c / pkcs15_gen_keypair

[Andreas Schwier (ML)]

Dear all,

we've come a across a strange issue in OpenSC. When we try to generate a
key pair with parameters not supported by the card, then the framework
code still tries to allocate private/public key objects rather than
returning an error code.

The questionable code is in line 2675 of framework-pkcs15.c /
pkcs15_gen_keypair.

Is that an intended behaviour or a plain bug ?

Andreas

-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

[opensc-devel] Domain Parameter for ECC Keys

[Andreas Schwier (ML)]

Dear all,

we've come across a strange behaviour of the pkcs15-lib in OpenSC when
we generate an EC key pair:

After generating an fresh EC key pair, our code returns a
sc_pkcs15_pubkey containing the EC public key and DER encoded domain
parameter. The public key is then encoded in sc_pkcs15init_generate_key
and added to the DF in the framework when it's immediately decoded again.

During this encode / decode step the domain parameter are lost.

I'm wondering why this encode / decode step is done ?

If it is required for some reason, then I would rather encode the public
key in SubjectPublicKey structure that would also preserve the domain
parameter in AlgorithmIdentifier.

Andreas

-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

Re: [opensc-devel] Creating a new PKCS#15 profile

[Andreas Schwier (ML)]

Dear Matthias,

what does opensc-tool -n report for this card ?

Did you check if the card OS is supported by OpenSC ?

Andreas


Am 18.09.2012 15:43, schrieb Mathias Tausig:
> Hy!
>
> I have a smartcard which is initialized with a signature application. Now I 
> want to add a PKCS#15 application to the card, which references that data.
>
> I have started to add a new DF with some basic information according to the 
> PKCS#15 specifications, so far I have an Object directory file and a 
> certificate 
> directory file. I tried to access the card with pkcs15-tool --dump, but I got 
> th error message:
>
> PKCS#15 binding failed: Unsupported card
>
> I assume, that I somehow have to create a new profile for the card. Is this 
> correct? Is there some guidance, how this is done?
>
> cheers
> Mathias
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required

[Andreas Schwier (ML)]

Hi,

wouldn't it be better to move the remaining parts of the project to github ?

Is there anything else important left on the server than the wiki ?

What about the old svn repos ? We're still maintaining the opensc-java
code here in our repository but have no way to bring the code back into
opensc. We already thought about migrating this part into our repo at
github.

Andreas

Am 12.09.2012 22:03, schrieb Andreas Jellinghaus:
> Hi,
>
> opensc-project.org  needs a new home:
> someone with a (real or virtual) server and the interest in
> setting it up from scratch and keeping it running and maintaining that
> server, installation and service
> for the project. someone who is able to win the trust of the community
> as new server administrator.
>
> The current installation is terribly old. It is based on ubuntu hardy
> and I think that is nearing the end of its supported livetime or even
> is unsupported now, thus it is urgently required to rebuild the
> server. Over the
> years we had several approaches and various people offered to take
> over running the server, but so far none of those worked out in the
> end, noone followed up after the initial discussion.
>
> To give this new efford more motivation here is some presure: running
> a server without maintenance and security updates is not a good idea.
> Thus I will shut down the current installation at the last end of this
> year.
>
> Any motivated linux administrator can setup a simple server with
> apache and a few copies of trac, plus postfix and a few mailing lists
> in a few hours or a day, with maybe a bit more time for fine tuning
> and migration of the content. This shouldn't be a big deal, thus there
> should be enough time to find someone interested in doing so and
> migrating opensc and related projects of the outdated installation.
>
> Regards, Andreas
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

[opensc-devel] Patch for pkcs15init/pkcs15-lib

[Andreas Schwier (ML)]

Dear all,

while we are working on write support for the SmartCard-HSM we've come
across some issues in pkcs15-lib. The issues are mostly related to the
isolation between the pkcs15 framework and the emulation layer. We've
authored a patch for the issues.

Because we can not oversee the impact of our patch for other cards, we
would like to ask card driver writers for a review.

The patch can be found at [1].

Thanks,

Andreas

[1]
https://github.com/CardContact/OpenSC/commit/b3b9bde068c6ebd96469b71235a76ce4c719a490

-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number

[Andreas Schwier (ML)]

Hi Douglas,

see below.

Am 22.08.2012 18:00, schrieb Douglas E. Engert:
>
> On 8/22/2012 10:09 AM, Andreas Schwier wrote:
>> Hi Douglas,
>>
>> thanks for your infos.
>>
>> The minidriver.c already ensures that the cardid file is always 16 byte.
>> It does this by repeating the token serial number until 16 bytes are filled.
> Unfortunately that gives OpenbSC 16 bytes but does not improve the uniqunness.
>
> Fortunately the uniqueness today only needs to extend over all the cards
> as seen on a single machine which may be only a hand full. the cardid
> is not sent to AD for example.  But it also means that if the certificates
> or keys on a card are changed, the cardid should also change.
>
>> We can ensure uniqueness of the serial number for our cards, but no
>> uniqueness among all other card vendors. There remains a (very) little
>> probability that a hexadecimal encoded serial number of another vendor's
>> card resembles one of our ASCII serial numbers.
>>
>> Our serial numbers are based on the numbering scheme for machine
>> readable travel documents, a 2 digit country code followed by up to 9
>> ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
>> in cardid).
> You did not say what was the minimum number of digits are, and
> in you example the first 4 "ACSII digits" are letters not numbers that
> introduce more uniqueness then numbers. Also for a single machine would
> it always see the same country code?
The serial number is always 11 characters (0-9, A-Z). The country code
is the country of the card issuer, within a country the card issuer gets
a 2-character prefix and will define the remaining 7 character.
>
> If you have 9 ASCII characters that should introduce enough uniqueness
> to avoid conflicts with your other cards and other vendors cards.
>
> One point I am trying to make is the cardid value is not really seen
> by the user, thus it does not have to be printable, and it could
> hold more uniqueness then a printable string. But if there is not
> enough unique data on the card to populate the cardid you have to use
> whatever you have.
Yes, I understand. I'm just concerned about the serial number visible to
the user at the PKCS#15 and PKCS#11 level. There it would be nice to see
the same serial number as the one printed on the card. My point is, that
currently the minidriver silently assumes that the
tokeninfo->serial_number contains a string with hexadecimal characters.
>
>> Our proposed change (see [1]) will not alter the current behaviour with
>> existing cards. It will just allow a card that uses a ASCII serial
>> number to work as well.
>>
>> An alternative approach - and probably more invasive - would be to use
>> the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
>> cardid file. This way we could still have our human readable serial
>> number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
>> the cardid file.
> On some cards whewre there is no serial readable form the card the
> SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a "serial number"
> from what ever data it can use on the card.
>
>
>> This will however break existing installations, as the
>> content of the cardid file might change with the driver update.
>>
> Yes it might break existing installations, as it would look like  a new card
> to the application, but with the same certificate on two cards. This could be
> an issue if Windows searches the cert store for a certificate, then asks the
> user to insert the matching card. i.e. the old card, not the new one.
>
> As long as you have 6 digits or characters in your printable string that 
> should
> be fine.
>
>> Andreas
>>
>> [1]
>> https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
>>
>> Am 22.08.2012 16:29, schrieb Douglas E. Engert:
>>> On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote:
>>>> Hi everyone,
>>>>
>>>> we've come across an issue with the minidriver which assumes the card
>>>> serial number to be a hex string.
>>>>
>>>> In our card the serial number is a string composed of ASCII characters.
>>>> This works well with pkcs15-tool and the PKCS#11 library, however it
>>>> fails with the current minidriver when it tries to convert the hex
>>>> string into binary data for the cardid file.
>>>>
>>>> Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for
>>>> encoding the serial number as hex string.
>>> The minidriver does not use the PKCS#11 standar

[opensc-devel] Minidriver assume hexstring encoding for card serial number

[Andreas Schwier (ML)]

Hi everyone,

we've come across an issue with the minidriver which assumes the card
serial number to be a hex string.

In our card the serial number is a string composed of ASCII characters.
This works well with pkcs15-tool and the PKCS#11 library, however it
fails with the current minidriver when it tries to convert the hex
string into binary data for the cardid file.

Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for
encoding the serial number as hex string.

I therefore propose to change the code in minidriver.c to do the following:

1. try parsing tokeninfo->serial_number as hex string
2. if that fails copy serial_number as is with the length being the
length of the ASCII encoded string

This should not interfere with current card drivers which all use a hex
string as serial number.

Any objections ?

Andreas

-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

Re: [opensc-devel] PIV: signature output format

[Andreas Schwier (ML)]

Hi Viktor and Douglas,

I do also favour to keep the DER signature format at the interface
between the card driver and the pkcs15 framework.

At the card driver level we don't know the field size, but we do at the
pkcs15 framework level. And all cards I know use the DER encoded
signature format anyway.

Maybe we can reuse Douglas code and do a conditional conversion in
sc_pkcs11_signature_final.

Andreas


Am 26.06.2012 08:06, schrieb Viktor Tarasov:
>
>
> On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert  > wrote:
>
> Just back from vacation...
>
>
> On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
>
> Hi Douglas,
>
> I'm trying to get signature with the PIV card and verify it
> with the 'openssl pkeyutl'.
> I use EC key #04 "CARD AUTH Key".
>
> It fails because of the 'raw' output format of the signature
> produced by OpenSC.
> OpenSSL expects the signature as a ASN1 sequence of two integers.
>
> I've seen in card-piv.c your comments:
> 
> https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>
> /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>  * Which may have leading 00 to force positive
>  * TODO: -DEE should check if PKCS15 want the same
>
>
> It seems that PKCS#15 really wants it.
>
>  * But PKCS11 just wants 2* filed_length in bytes
>
> Can you explain more? Why it wants 'raw' data?
>
>
> PKCS#11 v2.30: says:
>
>   6.3.1 EC Signatures
>   For the purposes of these mechanisms, an ECDSA signature is an
> octet string of even
>   length which is at most two times nLen octets, where nLen is the
> length in octets of the
>   base point order n. The signature octets correspond to the
> concatenation of the ECDSA
>   values r and s, both represented as an octet string of equal
> length of at most nLen with the
>   most significant byte first. If r and s have different octet
> length, the shorter of both must
>   be padded with leading zero octets such that both have the same
> octet length.
>
> PKCS#11 2.20 in Section 12.3.1 says the same as above.
>
> PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
> fixed size of  nLen=20.
>
> So PKCS#11 is not returning ASN1 but just the concatenation of r
> and s.
>
>
> Ok,  thanks.
>
>  * So we have to strip out the integers
>  * if present and pad on left if too short.
>  */
>
>
>
> I would propose to keep the ASN1 encoded data at the PKCS#15
> level,
> and, if needed, to convert it to the 'raw' format by dedicated
> procedure in the pkcs15 framework of pkcs11.
>
>
> Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
> If it needs to be ASN1, then yes the conversion could be done in
> the framework.
>
>
> Ok, there is no signature in ASN.1 in pkcs#15, but there some
> practical reasons.
>
> The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
> OpenSSL, for which the pkcs15-tool have to provide data in a suitable
> format, needs also the ASN.1 encoding.
>
> So, my suggestion is to keep the encoding returned by the card at the
> pkcs#15 level,
> and change it to the 'raw' mode on the pkcs#11 side.
>
> Finally, I have no preference, if you prefer to keep it like it is
> now, we'll be living with.
>
>
>
> Kind regards,
> Viktor.
>
>
>
>
>
>
>
>
>
>
>
> -- 
>
>  Douglas E. Engert  mailto:deeng...@anl.gov>>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444 
>
>
>
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

[opensc-devel] Initial support for SmartCard-HSM

[Andreas Schwier (ML)]

Hi everyone,

we've put in a pull request in github/opensc/staging to include a card
driver and PKCS#15 emulation module for our SmartCard-HSM [1].

This driver is a read-only driver that works with SmartCard-HSMs that
already contain keys and certificates.

In order to work correctly with our card profile, we had to add support
for EC private keys in pkcs15-prkey.c.

If someone would like to receive a free sample card and specifications,
please write me a personal e-mail.

Kind regards

Andreas

[1] http://www.cardcontact.de/products/SmartCard-HSM_V1.0.pdf


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org

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

Re: [opensc-devel] questions on {ERASE, WRITE, UPDATE} BINARY commands

[Andreas Schwier (ML)]

Hi Peter,

ERASE and WRITE are left-overs from the old smart card days. Most - if
not all - cards and applications today only implement UPDATE BINARY.

There is also no common understanding that UPDATE BINARY must not extend
the length of an EF. Some implementations maintain a maximum EF and a
current EF size. The maximum size is typically set in CREATE FILE,
whereas the current EF size depends on the amount of data written to the
EF. An EF may start with no data contained and and UPDATE BINARY command
with P1|P2 = Length of EF (or zero based offset after last byte ;-)
appends the amount of data provided in the C-Data of the APDU. Usually
gaps are not allowed, so an offset beyond end-of-file + 1 gives
SW1/SW2=6B00.

Other implementations allocate the full EF size at creation, so you can
immediately read from the EF, even though no data has been written yet.

Hope this helps,

Andreas

Am 07.06.2012 22:01, schrieb Peter Marschall:
> Hi,
>
> thanks for the quick reply/correction.
>
> On Thursday, 7. June 2012, Martin Paljak wrote:
>> On Thu, Jun 7, 2012 at 10:35 PM, Martin Paljak  
> wrote:
>>> Hello,
>>>
>>> On Thu, Jun 7, 2012 at 10:24 PM, Peter Marschall  wrote:
 Here they are:
 * What's the exact difference between WRITE BINARY & UPDATE BINARY?
  My understanding of the spec is that WRITE BINARY can extend a file's
 size, while UPDATE BINARY can only update data elements that are
 already within the file (i.e. in the range [0 .. file_size-1]).
  Is my understanding correct or did I misunderstand the specscompletely?
>>> AFAIU either can change file size (which can be done though 7816-9).
>> Correction, can NOT change file size.
> Does that mean that none of them can change the number of data elements that
> are in the file ?
>
> This seems to contradict the sentence in ISO 7816-4 7.2.4 WRITE BINARY which 
> states:
> "- the write-once of the bits given in the command data field (the command 
> shall be aborted if thestring of data units is not in the logical erased 
> state)"
>
> To me that sentence sounds like WRITE BINARY is an operation that 
> A) can only be used on data that is logically reset, 
> (i.e. once WRITE_BINARY was performed, it cannot be used on the same data
> any more without a preceding ERASE BINARY of that region)
> B) can extend the number of data units in the file
> (this is what I sloppily called existing_file_size in my< previous mail)
>
> In the other hand, ISO 7816-4 7.2.4 UPDATE BINARY says:
> "the command initialtes the update of the bits already present in an EF ..."
>
> This is what I interpret as "can only update existing data units in the file, 
> but not create more.
>
> Am I completely wrong?
> Are there "interpretation helpers" for the spec available somewhere?
>
>
> While I am at it: 
> Would you mind to pull Pull Request #53
>   https://github.com/OpenSC/OpenSC/pull/53
> into the staging branch of github's open/opensc?
> (It is a little bit frustrating to not get any feedback at all for a PullReq 
> ;-)
>
> Thanks
> PEter
>


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org


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

Re: [opensc-devel] proving a key is on a smart card

[Andreas Schwier (ML)]

Hi Frank,

you are right with the German identity card, however our approach is
different: Our card (which is no nPA) stores the key required for
terminal authentication, not for chip authentication. The key for
terminal authentication must be certified by a DVCA, which in turn is
certified by a national CVCA. So the challenge is to prove, that the key
pair for terminal authentication was actually generated at the secure
token in the terminal.

We are just reusing the established authenticated CSR format from
TR-03110 and build that into the card. The key for signing the
authenticated request can only be used for this specific purpose - this
is enforced internally in the card. There is no secure messaging
involved, because we only need to provide integrity and authenticity of
the CSR. The scheme has no need for confidentiality, as all information
is public anyway (CSR and certificate written to the card).

Andreas

Am 20.01.2012 11:49, schrieb Frank Morgner:
> Hi!
>
>>> I don't think that's enough?  It doesn't matter if the card trusts the CA,
>>> it's that the CA has to trust the card.
>> Difficult to do more with the common cards.
> As Andreas said, the German identity card (nPA) has this functionality
> (BSI TR-03110). A whole bunch of technical guidelines (TRs) describe
> every entity and process needed. Services that use the ID card for
> online authentication and identification are already available.
>
> What Andreas did not mention is that a card's key is actually shared
> among multiple cards for privacy reasons. This makes revocation a bit
> difficult. So for the nPA we will soon see chip individual keys and/or
> group signature schemes.
>
> Cheers, Frank.
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org


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

Re: [opensc-devel] proving a key is on a smart card

[Andreas Schwier (ML)]

Dear Frank,

we have such a card. Take a look at [1].

The card internally generates a key pair and a CSR as defined in
TR-03110 (that is the standard for biometric passports, in particular
Extended Access Control). Such an authenticated request contains two
signatures: the inner signature is the proof-of-correspondence (I own
the private and public key) and the outer signature provides
proof-of-origin (the key was generated in an authentic device).

Each card contains a device authentication key that gets certified
during production. A CA receiving a certificate request must

1. first verify the device authentication certificate read from the card,
2. then verify the outer signature with the public key obtained from the
device authentication certificate,
3. then verify the inner signature to prove that the sender actually
owns the private key and
4. finally issue a certificate for the public key contained.

The scheme is specifically used for remote certificate issuance, where
you can not rely on a secure communication channel between the CA and
the token.

Andreas

[1] http://www.cardcontact.de/products/SmartCard-HSM_V1.0.pdf

Am 19.01.2012 01:20, schrieb Frank Cusack:
> In a CSR, how is it proven that the key resides on a smart card (and
> is not exportable)?  In my understanding, the CSR is signed by the
> private key of the (to be) cert itself.  Thus that signature only
> proves that the requester actually possesses the private half, not
> that the private key resides on a smart card.
>
> Looking at the cryptoflex command set, I don't see anything there that
> would add something to the CSR asserting that the key was generated
> on-card.  Same for ISO 7816-8, but I could easily be missing
> something.  Are there card specific APDUs that add some proof?  If so,
> any pointers to what cards can do this?
>
> Or is the typical method basically to require use of a "secure"
> enrollment station?
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org


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

Re: [opensc-devel] Java and pkcs11

[Andreas Schwier (ML)]

The latest OCF package at [1] has support for smartcardio - so if you
need more than just the APDU interface.

Andreas

[1] http://www.openscdp.org/ocf/download.html

Am 12.08.2011 12:11, schrieb resoli - libero:
> Il giorno mer, 10/08/2011 alle 08.36 +0200, NdK ha scritto:
>> On 09/08/2011 20:48, Vlastimil Pavicek wrote:
>>> I haven't read the whole thread, but you might find this library useful (it 
>>> is easier to use than JNI/JNA):
>>> http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/PKCS-11-Wrapper
>> Tks.
>> Found last night. It's used by j4sign[1] that targets multiple 
>> platforms. By its own it seems it's not enough, but it have to be used 
>> in parallel with the OCF wrapper (for card detection).
> I'm the main developer of j4sign; as someone already suggested,
> smartcardio is better suited at the moment for interfacing pcsc
> directly.
>
> j4sign will switch soon to smartcardio .
>
> bye,
> Roberto Resoli
>> I'll have to dig better...
>>
>> [1] http://j4sign.sourceforge.net/index.html
>>
>> BYtE,
>>   Diego.
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

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

Re: [opensc-devel] AccessMode in ISO7816-15

[Andreas Schwier (ML)]

Hi Viktor,

ISO 7816-15:2004 defines read(0), update(1), execute(2) and delete(3).

Andreas

Viktor TARASOV schrieb:
> Hi,
>
> The 'accessMode' bit string, encoded by the native Oberthur middleware 
> for the IAS/ECC cards,
> can be up to 10 bits length.
>
> In PKCS#15 (v1.1) for the 'accessMode' only three bits defined: 'read', 
> 'update', 'execute'.
> In ECC specification (CEN/TS 15480-2:2007) one more: 'delete'.
>
> Have you an access to 7816-15, please? Does it's 'accessMode' definition 
> identical to the one defined in PKCS#15?
>
> Do you know other specifications that define more of the AccessMode 
> operations?
>
> Kind wishes,
> Viktor.
>
>   

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

Re: [opensc-devel] OpenSC-java: Web application

[Andreas Schwier (ML)]

Hello Martin,

we also maintain a current version of the OpenCard Framework as part of
the OpenSCDP Project at [1]. This has build in support for
javax.smartcardio, secure messaging, generic ISO 7816 file services and
much more. We use OCF as part of the Smart Card Shell scripting environment.

Andreas

[1] http://www.openscdp.org/ocf

Martin Paljak schrieb:
> Hello,
> On Apr 7, 2010, at 17:28 , Harry Anuszewski wrote
>   
>> I currently have a java application that allows the user to login to a 
>> website using a smart card. I use openSC-java to select a card reader, 
>> create a session and pull out certificate information, etc. I would like to 
>> make this a web application but I know that openSC-java depends on a few 
>> .dll files for windows and a few .so files for linux. Right now I am just 
>> working with the windows half. The way my app works now is it checks for 
>> openSC in the system path if it doesn’t find it then it prompts to run an 
>> installer that I created that puts openSC in C:\program files\opensc and 
>> then adds that to the system path and reboots the computer. The next time 
>> the user goes to run the program they will be able to use opensc.
>>  
>> What I am basically wondering is, is their a way to create a jar that has 
>> the opensc dependencies (.dll) so that the user never has to download and 
>> run my installer? Everything will be handled online.
>> 
> There are three aspects of Java and smart cards that matter in the context of 
> web applications:
> - TLS/SSL client authentication (means configuration of the web container, so 
> not really related to OpenSC)
> - access to cryptographic smart cards in applets via a JNI bridge to PKCS#11 
> (possible via Sun PKCS#11 provider available since Java 1.5+ or OpenSC-Java 
> one, the problem you're facing)
> - access to smart cards via javax.smartcardio in Java 1.6+
>
> IMO, the preferred way would be to use javax.smartcardio and bypass the JNI 
> problem, if you have a specific smart card to talk to and don't need to rely 
> on the PKCS#11 provider availability on the client machine. There is 
> preliminary support for reading PKCS#15 structures a la OpenSC does, in Java, 
> as pointed out in [1]
>
> There are some *very* preliminary pointers to Java resources on OpenSC wiki 
> [1] which will be improved ASAP
>
> [1] http://www.opensc-project.org/opensc/wiki/Java
>
>
>   

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

Re: [opensc-devel] OpenSC-Java required Dll and exe

[Andreas Schwier (ML)]

Hi Harry,

to access a PKCS#11 DLL you will just need the opensc-java.jar included
in your classpath and opensc-PKCS11-0.3.dll file in a directory
contained in the PATH environment variable or defined in java.library.path.

The location and name of the PKCS#11 DLL is passed to the PKCS11Provider
constructor.

Andreas

Harry Anuszewski schrieb:
> Hello,
>
>  
>
> I am just wondering what the minimally required dlls / exe to use
> opensc-java on a Windows 32 bit machine. Without using the Smart Card Bundle
> and just compiling a fresh copy of OpenSC what is needed to be copied to the
> System32 directory to make openSC-java load the provider and work. 
>
>  
>
> Thank you,
>
>  
>
> Harry
>
>
>   
> 
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

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

[opensc-devel] Scripts for MuscleCard Applet

[Andreas Schwier (ML)]

For those of you using the MuscleCard applet we've released a set of
Smart Card Shell scripts and documentation [1] to get things going.

The scripts have been tested with JCOP and Cyberflex 64K card, but maybe
you want to give it a try with other JavaCards. Please let me know, if
it works for you.

Andreas

[1] http://www.openscdp.org/scsh3/musclecard/index.html

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