Initial support for SmartCard-HSM

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

Peter Stuge-4
Andreas Schwier (ML) wrote:
> 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].

That sounds nice. I haven't yet looked at the code.


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

Is there a technical reason for the driver to be read-only? I mean,
it would be nice if OpenSC could also be used to initialize tokens.

Perhaps write support would be optional at build time.


Kind regards

//Peter
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

Andreas Schwier
Dear Peter,

there is no technical reason, it's just because it's an easier first
milestone.

We plan to add full support in the next steps, including secure messaging.

Andreas


Am 04.08.2012 13:59, schrieb Peter Stuge:

> Andreas Schwier (ML) wrote:
>> 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].
> That sounds nice. I haven't yet looked at the code.
>
>
>> This driver is a read-only driver that works with SmartCard-HSMs that
>> already contain keys and certificates.
> Is there a technical reason for the driver to be read-only? I mean,
> it would be nice if OpenSC could also be used to initialize tokens.
>
> Perhaps write support would be optional at build time.
>
>
> Kind regards
>
> //Peter
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

Jean-Michel Pouré - GOOZE
In reply to this post by Andreas Schwier (ML)
Le vendredi 03 août 2012 à 15:54 +0200, Andreas Schwier (ML) a écrit :
> 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].

Nice.

Out of question, why is it called HSM?
What does it provide more than a crypto card?

Kind regards,
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

Andreas Schwier
Dear Jean-Michel,

the name's just a name ;-)

Right now it provides support for RSA and ECC keys with a special remote
provisioning scheme, but later we will add support for DES and AES keys
and more advanced key management functions.

Andreas

Am 04.08.2012 18:15, schrieb Jean-Michel Pouré - GOOZE:

> Le vendredi 03 août 2012 à 15:54 +0200, Andreas Schwier (ML) a écrit :
>> 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].
> Nice.
>
> Out of question, why is it called HSM?
> What does it provide more than a crypto card?
>
> Kind regards,
>
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

NdK-3
Il 06/08/2012 10:15, Andreas Schwier ha scritto:

> the name's just a name ;-)
Probably he (like me) hoped it was something more like (would-be)
MicroCA: a card taking a CSR and outputting a cert if constraints are
satisfied...

BYtE,
 Diego.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

Andreas Schwier
I would assume, that checking constraints is the job of the RA, not the CA.

Anyway, our design works the other way around: The card generates the
CSR internally, so the RA/CA can prove the key was generated in a
legitimate device. The device can be anywhere out in the wild.

Andreas

Am 06.08.2012 11:04, schrieb NdK:

> Il 06/08/2012 10:15, Andreas Schwier ha scritto:
>
>> the name's just a name ;-)
> Probably he (like me) hoped it was something more like (would-be)
> MicroCA: a card taking a CSR and outputting a cert if constraints are
> satisfied...
>
> BYtE,
>  Diego.
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

Anders Rundgren
On 2012-08-06 11:23, Andreas Schwier wrote:
> I would assume, that checking constraints is the job of the RA, not the CA.
>
> Anyway, our design works the other way around: The card generates the
> CSR internally, so the RA/CA can prove the key was generated in a
> legitimate device. The device can be anywhere out in the wild.

Which is the future for smart cards, otherwise they must be physically
distributed after provisioning.

Anders

>
> Andreas
>
> Am 06.08.2012 11:04, schrieb NdK:
>> Il 06/08/2012 10:15, Andreas Schwier ha scritto:
>>
>>> the name's just a name ;-)
>> Probably he (like me) hoped it was something more like (would-be)
>> MicroCA: a card taking a CSR and outputting a cert if constraints are
>> satisfied...
>>
>> BYtE,
>>  Diego.
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

Nikos Mavrogiannopoulos-2
On Mon, Aug 6, 2012 at 11:30 AM, Anders Rundgren
<[hidden email]> wrote:
> On 2012-08-06 11:23, Andreas Schwier wrote:
>> I would assume, that checking constraints is the job of the RA, not the CA.
>>
>> Anyway, our design works the other way around: The card generates the
>> CSR internally, so the RA/CA can prove the key was generated in a
>> legitimate device. The device can be anywhere out in the wild.
>
> Which is the future for smart cards, otherwise they must be physically
> distributed after provisioning.

But how do you prove that the key was generated in the card? You'd
need some kind of provisioning to do that.

regards,
Nikos
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Initial support for SmartCard-HSM

Anders Rundgren
On 2012-08-06 12:51, Nikos Mavrogiannopoulos wrote:

> On Mon, Aug 6, 2012 at 11:30 AM, Anders Rundgren
> <[hidden email]> wrote:
>> On 2012-08-06 11:23, Andreas Schwier wrote:
>>> I would assume, that checking constraints is the job of the RA, not the CA.
>>>
>>> Anyway, our design works the other way around: The card generates the
>>> CSR internally, so the RA/CA can prove the key was generated in a
>>> legitimate device. The device can be anywhere out in the wild.
>>
>> Which is the future for smart cards, otherwise they must be physically
>> distributed after provisioning.
>
> But how do you prove that the key was generated in the card? You'd
> need some kind of provisioning to do that.

The card (crypto module) should contain a key provisioned during
manufacturing that is restricted to only attest public keys.

A certificate fingerprint of the attestation key certificate is
then typically used for identifying the crypto module.

I see this primarily as a very useful method for "cloning" an ID.

Lets say that you have an eID and you rather want a mobile ID
in the Y2014 model of Android.  Then browse to the eID RA,
authenticate with your eID, type the 8 first characters of the
Android attestation certificate fingerprint, and ask for a
"clone" to device with phone +46nnnnnnnn.  You get an SMS
with an URL that you click on that will take you to enroll.
If the eID RA accepts this device brand (based on attestation
certificate) and the fingerprint matches you will get a
new certificate in your phone.  Naturally the entire process
must be carried out using some kind of secure messaging mechanism.

This could be called SCC (Secure Credential Cloning).

Yes, the eID will most likely only be a "bootstrap" credential
that you keep in a drawer...

However, the same concept can also be used in M2M communication
ike required by SPOC, ATMs, etc.

Anders


>
> regards,
> Nikos
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel