Crypto Chip Support imaginable ?

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

Crypto Chip Support imaginable ?

Marx, Peter

I’m IT architect in a big IoT project. I’m looking for getting PKCS#11 support for Java applications on Linux, so i can get rid of the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys shall be created/stored in hardware instead.

 

But I can’t use Smartcards. The idea is to use a cryptochip on the mainboard (headless Linux field unit) like the ATMEL ATECC108A. The chip is on I2C bus and is e.g. accessible from Linux as a device.

 

I had asked ATMEL about software support for their chips beyond the embedded level. But they can only provide a Linux I2C reference implementation of the HAL, nothing in the direction of a PKCS#11 module. And an OpenSSL add-on is available.

 

Not having in-depth knowledge from PKCS#11 wrapper down to the chip my questions are:

 

-          What components have to be developped to make a cryptochip look as Smartcard to OpenSC

-          Has this been done before ?

-          Can this be purchased or is it available for free ?

-          Can this be done in native Java or is some C/C++ wrapping with JNI needed ?

-          What effort would this be ?

-          In case there is no open solution: who knows a company which could deliver a solution ?

 

Peter



Knorr-Bremse IT-Services GmbH
Sitz: München
Geschäftsführer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht München, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Andreas Schwier (ML)
Hi Peter,

I'd recommend to use a Secure Element platform like the NXP A700 which
has a JavaCard Operating System and can run JavaCard applets
implementing PKI functions.

That way you get an embedded smartcard controller that has the security
attributes you are looking for. You could use one of the available
JavaCard applets that work with OpenSC, e.g.

* the IsoApplet [2],
* the myEID Applet [3] or
* (of course) our SmartCard-HSM Applet [4].

If you want to go with the Atmel chip, integrating a stack smaller than
OpenSC might be simpler. I'd recommend to take a look at our
sc-hsm-embedded project, which is a lightweight PKCS#11 stack for
embedded scenarios.

Andreas



[1]
http://www.nxp.com/products/identification-and-security/authentication/secure-authentication-microcontroller:A700X_FAMILY
[2] https://github.com/philipWendland/IsoApplet
[3] https://github.com/OpenSC/OpenSC/wiki/Aventra-MyEID-PKI-card
[4] http://www.smartcard-hsm.com/
[5] https://github.com/CardContact/sc-hsm-embedded

On 06/14/2016 11:42 AM, Marx, Peter wrote:

> I'm IT architect in a big IoT project. I'm looking for getting PKCS#11 support for Java applications on Linux, so i can get rid of the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys shall be created/stored in hardware instead.
>
> But I can't use Smartcards. The idea is to use a cryptochip on the mainboard (headless Linux field unit) like the ATMEL ATECC108A. The chip is on I2C bus and is e.g. accessible from Linux as a device.
>
> I had asked ATMEL about software support for their chips beyond the embedded level. But they can only provide a Linux I2C reference implementation of the HAL, nothing in the direction of a PKCS#11 module. And an OpenSSL add-on is available.
>
> Not having in-depth knowledge from PKCS#11 wrapper down to the chip my questions are:
>
>
> -          What components have to be developped to make a cryptochip look as Smartcard to OpenSC
>
> -          Has this been done before ?
>
> -          Can this be purchased or is it available for free ?
>
> -          Can this be done in native Java or is some C/C++ wrapping with JNI needed ?
>
> -          What effort would this be ?
>
> -          In case there is no open solution: who knows a company which could deliver a solution ?
>
> Peter
>
> Knorr-Bremse IT-Services GmbH
> Sitz: Muenchen
> Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
> Registergericht Muenchen, HR B 167 268
>
> This transmission is intended solely for the addressee and contains confidential information.
> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


--

    ---------    CardContact Systems GmbH
   |.##> <##.|   Schülerweg 38
   |#       #|   D-32429 Minden, Germany
   |#       #|   Phone +49 571 56149
   |'##> <##'|   http://www.cardcontact.de
    ---------    Registergericht Bad Oeynhausen HRB 14880
                 Geschäftsführer Andreas Schwier

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Dirk-Willem van Gulik
And I would not underestimate how well a USB dongle with a smartcard/PKCS support works (if needed - use the type with a 4x1 pin IDC connector which can go straight onto the motherboard). And the integrate rather well with Java land (for client or server SSL certs; but certainly also all the way ‘up’ to a (very) low-volume HSM to use with something like EJBCA).

Going down that route also makes your tooling (on linux) easier than i2c (though we found doing an SSL engine for just signing over i2c quite easy*).

Dw.

*) The problem is that the NDA’s and licenses you need to enter into with the chip folks mean that you are then on the hook for the next N years to maintain such an engine on your own - no open source synergy.

> On 14 Jun 2016, at 12:15, Andreas Schwier <[hidden email]> wrote:
>
> Hi Peter,
>
> I'd recommend to use a Secure Element platform like the NXP A700 which
> has a JavaCard Operating System and can run JavaCard applets
> implementing PKI functions.
>
> That way you get an embedded smartcard controller that has the security
> attributes you are looking for. You could use one of the available
> JavaCard applets that work with OpenSC, e.g.
>
> * the IsoApplet [2],
> * the myEID Applet [3] or
> * (of course) our SmartCard-HSM Applet [4].
>
> If you want to go with the Atmel chip, integrating a stack smaller than
> OpenSC might be simpler. I'd recommend to take a look at our
> sc-hsm-embedded project, which is a lightweight PKCS#11 stack for
> embedded scenarios.
>
> Andreas
>
>
>
> [1]
> http://www.nxp.com/products/identification-and-security/authentication/secure-authentication-microcontroller:A700X_FAMILY
> [2] https://github.com/philipWendland/IsoApplet
> [3] https://github.com/OpenSC/OpenSC/wiki/Aventra-MyEID-PKI-card
> [4] http://www.smartcard-hsm.com/
> [5] https://github.com/CardContact/sc-hsm-embedded
>
> On 06/14/2016 11:42 AM, Marx, Peter wrote:
>> I'm IT architect in a big IoT project. I'm looking for getting PKCS#11 support for Java applications on Linux, so i can get rid of the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys shall be created/stored in hardware instead.
>>
>> But I can't use Smartcards. The idea is to use a cryptochip on the mainboard (headless Linux field unit) like the ATMEL ATECC108A. The chip is on I2C bus and is e.g. accessible from Linux as a device.
>>
>> I had asked ATMEL about software support for their chips beyond the embedded level. But they can only provide a Linux I2C reference implementation of the HAL, nothing in the direction of a PKCS#11 module. And an OpenSSL add-on is available.
>>
>> Not having in-depth knowledge from PKCS#11 wrapper down to the chip my questions are:
>>
>>
>> -          What components have to be developped to make a cryptochip look as Smartcard to OpenSC
>>
>> -          Has this been done before ?
>>
>> -          Can this be purchased or is it available for free ?
>>
>> -          Can this be done in native Java or is some C/C++ wrapping with JNI needed ?
>>
>> -          What effort would this be ?
>>
>> -          In case there is no open solution: who knows a company which could deliver a solution ?
>>
>> Peter
>>
>> Knorr-Bremse IT-Services GmbH
>> Sitz: Muenchen
>> Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
>> Registergericht Muenchen, HR B 167 268
>>
>> This transmission is intended solely for the addressee and contains confidential information.
>> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
>> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>
>
> --
>
>    ---------    CardContact Systems GmbH
>   |.##> <##.|   Schülerweg 38
>   |#       #|   D-32429 Minden, Germany
>   |#       #|   Phone +49 571 56149
>   |'##> <##'|   http://www.cardcontact.de
>    ---------    Registergericht Bad Oeynhausen HRB 14880
>                 Geschäftsführer Andreas Schwier
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

David Woodhouse
In reply to this post by Marx, Peter
On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
> I’m IT architect in a big IoT project. I’m looking for getting
> PKCS#11 support for Java applications on Linux, so i can get rid of
> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
> shall be created/stored in hardware instead.
>  
> But I can’t use Smartcards. The idea is to use a cryptochip on the
> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
> chip is on I2C bus and is e.g. accessible from Linux as a device.

OK... first question: why do you want certificates in hardware? 
What's the point in that?

Is there some kind of design requirement where you want to be able to
wipe and re-image the operating system storage, but leave the
*certificates* in the store intact? And even if it's that, isn't it
easier to just have separate storage for the certificates?

Here's a straw man proposal; tell me why/if it doesn't work for you.

Take an existing software PKCS#11 token, like SoftHSM or the NSS
softokn (which is entirely usable outside NSS; I was using it with
wpa_supplicant only a few hours ago). That's your certificate storage.

For keys though, this doesn't work — I assume you're here because you
really *do* want hardware security so that the private key can't be
copied away from the device; only used in situ.

For this, the TPM model works. Not the whole complex TSS stack, but
just the basic concept — you store your private keys in software, but
*encrypted*. With a key that only exists inside the hardware (and is
fairly much the *only* thing the hardware stores).

So when you want to perform an encrypt/decrypt/sign/verify operation
with a given key, you hand the encrypted key to the Atmel µc and ask
*it* to decrypt the key and then perform the operation. Optionally, it
can demand a PIN when you do so.

I'm not sure how well that would fit into OpenSC, but it does seem like
the low-effort way to achieving (what I assume to be) your
requirements.

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Crypto Chip Support imaginable ?

Marx, Peter
In reply to this post by Andreas Schwier (ML)
Hi Andreas,

there is no more chance to introduce something like the NXP A700 to the board design, so I'm stuck with the ATMEL...
A smaller stack could be an option, but a read-only implementation could be insufficient, as provisioning process and in-field usage would take different paths, tools and methods. But this has to be clarified.

Reading though your sc-hsm-embedded link, I don't get an idea what kind of drivers/modules need to be implemented to get that stuff work with the ATMEL chip, may it be through a Linux device or directly.
Could you give some hints here ?

Peter


-----Original Message-----
From: Andreas Schwier [mailto:[hidden email]]
Sent: Tuesday, June 14, 2016 12:15 PM
To: [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

Hi Peter,

I'd recommend to use a Secure Element platform like the NXP A700 which has a JavaCard Operating System and can run JavaCard applets implementing PKI functions.

That way you get an embedded smartcard controller that has the security attributes you are looking for. You could use one of the available JavaCard applets that work with OpenSC, e.g.

* the IsoApplet [2],
* the myEID Applet [3] or
* (of course) our SmartCard-HSM Applet [4].

If you want to go with the Atmel chip, integrating a stack smaller than OpenSC might be simpler. I'd recommend to take a look at our sc-hsm-embedded project, which is a lightweight PKCS#11 stack for embedded scenarios.

Andreas



[1]
http://www.nxp.com/products/identification-and-security/authentication/secure-authentication-microcontroller:A700X_FAMILY
[2] https://github.com/philipWendland/IsoApplet
[3] https://github.com/OpenSC/OpenSC/wiki/Aventra-MyEID-PKI-card
[4] http://www.smartcard-hsm.com/
[5] https://github.com/CardContact/sc-hsm-embedded

On 06/14/2016 11:42 AM, Marx, Peter wrote:

> I'm IT architect in a big IoT project. I'm looking for getting PKCS#11 support for Java applications on Linux, so i can get rid of the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys shall be created/stored in hardware instead.
>
> But I can't use Smartcards. The idea is to use a cryptochip on the mainboard (headless Linux field unit) like the ATMEL ATECC108A. The chip is on I2C bus and is e.g. accessible from Linux as a device.
>
> I had asked ATMEL about software support for their chips beyond the embedded level. But they can only provide a Linux I2C reference implementation of the HAL, nothing in the direction of a PKCS#11 module. And an OpenSSL add-on is available.
>
> Not having in-depth knowledge from PKCS#11 wrapper down to the chip my questions are:
>
>
> -          What components have to be developped to make a cryptochip look as Smartcard to OpenSC
>
> -          Has this been done before ?
>
> -          Can this be purchased or is it available for free ?
>
> -          Can this be done in native Java or is some C/C++ wrapping with JNI needed ?
>
> -          What effort would this be ?
>
> -          In case there is no open solution: who knows a company which could deliver a solution ?
>
> Peter
>
> Knorr-Bremse IT-Services GmbH
> Sitz: Muenchen
> Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen,
> Harald Schneider Registergericht Muenchen, HR B 167 268
>
> This transmission is intended solely for the addressee and contains confidential information.
> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
>
>
>
> ----------------------------------------------------------------------
> -------- What NetFlow Analyzer can do for you? Monitors network
> bandwidth and traffic patterns at an interface-level. Reveals which
> users, apps, and protocols are consuming the most bandwidth. Provides
> multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make
> informed decisions using capacity planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


--

    ---------    CardContact Systems GmbH
   |.##> <##.|   Schülerweg 38
   |#       #|   D-32429 Minden, Germany
   |#       #|   Phone +49 571 56149
   |'##> <##'|   http://www.cardcontact.de
    ---------    Registergericht Bad Oeynhausen HRB 14880
                 Geschäftsführer Andreas Schwier

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Anders Rundgren-2
In reply to this post by David Woodhouse
On 2016-06-14 13:11, David Woodhouse wrote:

> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
>
> OK... first question: why do you want certificates in hardware?
> What's the point in that?
>
> Is there some kind of design requirement where you want to be able to
> wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it
> easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS
> softokn (which is entirely usable outside NSS; I was using it with
> wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you
> really *do* want hardware security so that the private key can't be
> copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but
> just the basic concept — you store your private keys in software, but
> *encrypted*. With a key that only exists inside the hardware (and is
> fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation
> with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it
> can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like
> the low-effort way to achieving (what I assume to be) your
> requirements.

Since Intel have firmware in their CPUs it seems that Intel is the
party that should enable this capability...

Unfortunately Intel seems to be fairly uninterested in solutions
they don't get paid for in spite of the fact that their IPT system
http://www.intel.com/content/www/us/en/architecture-and-technology/identity-protection/identity-protection-technology-general.html
probably haven't generated a single cent in profits ever.

Anders

>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Marx, Peter
In reply to this post by David Woodhouse
let's start with the requirements part:

1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.

2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.

2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
The keystore and truststore files plus the cleartext passwords to access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and
providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.

Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.

For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.

Peter


-----Original Message-----
From: David Woodhouse [mailto:[hidden email]]
Sent: Tuesday, June 14, 2016 1:12 PM
To: Marx, Peter; [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

* PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM

On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
> I’m IT architect in a big IoT project. I’m looking for getting
> PKCS#11 support for Java applications on Linux, so i can get rid of
> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
> shall be created/stored in hardware instead.
>  
> But I can’t use Smartcards. The idea is to use a cryptochip on the
> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
> chip is on I2C bus and is e.g. accessible from Linux as a device.

OK... first question: why do you want certificates in hardware? What's the point in that?

Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
*certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?

Here's a straw man proposal; tell me why/if it doesn't work for you.

Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.

For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.

For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).

So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
*it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.

I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation

* [hidden email] <[hidden email]>
* Issuer: StartCom Ltd. - Unverified

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Andreas Schwier (ML)
TLS via Java with a PKCS#11 Module can be done with opensc-java or the
SunPKCS11 Provider. That works for both, client and server authentication.

On 06/15/2016 03:57 PM, Marx, Peter wrote:

> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and
> providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.
>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:[hidden email]]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; [hidden email]
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>  
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
>
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>


--

    ---------    CardContact Systems GmbH
   |.##> <##.|   Schülerweg 38
   |#       #|   D-32429 Minden, Germany
   |#       #|   Phone +49 571 56149
   |'##> <##'|   http://www.cardcontact.de
    ---------    Registergericht Bad Oeynhausen HRB 14880
                 Geschäftsführer Andreas Schwier

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Douglas E Engert
In reply to this post by Marx, Peter


On 6/15/2016 8:57 AM, Marx, Peter wrote:

> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and
> providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

But the public key in the cert only works with the private key in the device. Copying the certs should not work.
This security depends on the CA only signing a CSR with the UUID from the chip. That is not clear how the CA verifies the UUID is the one on the chip. This is a card management issue for the CA.  If
the CA is only signing CSRs generated at you factory where you have physical control of the chip, then it could work. If the CSR is generated by the user or in the field, the CA may not be able to
validate the UUID is from the chip that signed the CSR.

>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:[hidden email]]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; [hidden email]
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>  
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>

--

  Douglas E. Engert  <[hidden email]>
 


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Marx, Peter
In reply to this post by Andreas Schwier (ML)
but I don't have a PKCS#11 module for the ATECC108. This seems to be the missing link, as such modules are only existing for HSMs and Smartcards. They are delivered by their producers.
My question is how to create such a module, hopefully by adopting an existing solution.

-----Original Message-----
From: Andreas Schwier [mailto:[hidden email]]
Sent: Wednesday, June 15, 2016 4:14 PM
To: [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

TLS via Java with a PKCS#11 Module can be done with opensc-java or the
SunPKCS11 Provider. That works for both, client and server authentication.

On 06/15/2016 03:57 PM, Marx, Peter wrote:

> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to
> access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.
>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:[hidden email]]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; [hidden email]
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>  
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
>
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to
> wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation
> with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>


--

    ---------    CardContact Systems GmbH
   |.##> <##.|   Schülerweg 38
   |#       #|   D-32429 Minden, Germany
   |#       #|   Phone +49 571 56149
   |'##> <##'|   http://www.cardcontact.de
    ---------    Registergericht Bad Oeynhausen HRB 14880
                 Geschäftsführer Andreas Schwier

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Marx, Peter
In reply to this post by Douglas E Engert
good point. Hopefully we can limit the enrollment to a trusted subcontractor's network. As the UUIDs resemble a known set which is relayed from ATMEL to us before the chips are soldered onto the boards,
only "spoofing" UUIDs out of this set would be the final attack vector I can't mitigate.

-----Original Message-----
From: Douglas E Engert [mailto:[hidden email]]
Sent: Wednesday, June 15, 2016 4:20 PM
To: [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?



On 6/15/2016 8:57 AM, Marx, Peter wrote:

> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to
> access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

But the public key in the cert only works with the private key in the device. Copying the certs should not work.
This security depends on the CA only signing a CSR with the UUID from the chip. That is not clear how the CA verifies the UUID is the one on the chip. This is a card management issue for the CA.  If the CA is only signing CSRs generated at you factory where you have physical control of the chip, then it could work. If the CSR is generated by the user or in the field, the CA may not be able to validate the UUID is from the chip that signed the CSR.

>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:[hidden email]]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; [hidden email]
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>  
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>

--

  Douglas E. Engert  <[hidden email]>
 


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Alexander Gostrer
Hi Peter,

Here is the OpenSSL Engine that we wrote by the Atmel request: https://github.com/AtmelCSO/cryptoauth-openssl-engine. It supports ATECC508A that is a superset of ATECC108 (has Diffie-Hellman). The engine also supports keeping certificates on the ATECC508A hardware. Like Douglas and David already said, it will not add any protection. But it is implemented. Youy can use it.

We do not use OpenCS in this project: we found that we didn't need any http support. Let me know if you want to talk to Atmel's FAE: they are very responsive and knowledgeable. 

Regards,
Alex

On Wed, Jun 15, 2016 at 7:29 AM, Marx, Peter <[hidden email]> wrote:
good point. Hopefully we can limit the enrollment to a trusted subcontractor's network. As the UUIDs resemble a known set which is relayed from ATMEL to us before the chips are soldered onto the boards,
only "spoofing" UUIDs out of this set would be the final attack vector I can't mitigate.

-----Original Message-----
From: Douglas E Engert [mailto:[hidden email]]
Sent: Wednesday, June 15, 2016 4:20 PM
To: [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?



On 6/15/2016 8:57 AM, Marx, Peter wrote:
> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to
> access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

But the public key in the cert only works with the private key in the device. Copying the certs should not work.
This security depends on the CA only signing a CSR with the UUID from the chip. That is not clear how the CA verifies the UUID is the one on the chip. This is a card management issue for the CA.  If the CA is only signing CSRs generated at you factory where you have physical control of the chip, then it could work. If the CSR is generated by the user or in the field, the CA may not be able to validate the UUID is from the chip that signed the CSR.

>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:[hidden email]]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; [hidden email]
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>

--

  Douglas E. Engert  <[hidden email]>



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Marx, Peter

Hi Alex,

 

I’m aware of this engine, see requirement #1. That indeed can cover the provisioning process, combined with certmonger’s getcert via SCEP -> EJBCA PKI solution.

But the Java apps are not aware of this store, as they expect to access the store via PKCS#11…

 

Thanks

 

Peter

 

 

From: Alexander Gostrer [mailto:[hidden email]]
Sent: Wednesday, June 15, 2016 5:44 PM
To: Marx, Peter
Cc: Douglas E Engert; [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

 

Hi Peter,

 

Here is the OpenSSL Engine that we wrote by the Atmel request: https://github.com/AtmelCSO/cryptoauth-openssl-engine. It supports ATECC508A that is a superset of ATECC108 (has Diffie-Hellman). The engine also supports keeping certificates on the ATECC508A hardware. Like Douglas and David already said, it will not add any protection. But it is implemented. Youy can use it.

 

We do not use OpenCS in this project: we found that we didn't need any http support. Let me know if you want to talk to Atmel's FAE: they are very responsive and knowledgeable. 

 

Regards,

Alex

 

On Wed, Jun 15, 2016 at 7:29 AM, Marx, Peter <[hidden email]> wrote:

good point. Hopefully we can limit the enrollment to a trusted subcontractor's network. As the UUIDs resemble a known set which is relayed from ATMEL to us before the chips are soldered onto the boards,
only "spoofing" UUIDs out of this set would be the final attack vector I can't mitigate.

-----Original Message-----
From: Douglas E Engert [mailto:[hidden email]]
Sent: Wednesday, June 15, 2016 4:20 PM
To: [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?



On 6/15/2016 8:57 AM, Marx, Peter wrote:
> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to
> access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

But the public key in the cert only works with the private key in the device. Copying the certs should not work.
This security depends on the CA only signing a CSR with the UUID from the chip. That is not clear how the CA verifies the UUID is the one on the chip. This is a card management issue for the CA.  If the CA is only signing CSRs generated at you factory where you have physical control of the chip, then it could work. If the CSR is generated by the user or in the field, the CA may not be able to validate the UUID is from the chip that signed the CSR.

>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:[hidden email]]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; [hidden email]
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>

--

  Douglas E. Engert  <[hidden email]>



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

 



Knorr-Bremse IT-Services GmbH
Sitz: München
Geschäftsführer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht München, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

David Woodhouse
In reply to this post by Anders Rundgren-2
On Wed, 2016-06-15 at 15:24 +0200, Anders Rundgren wrote:
>
> Since Intel have firmware in their CPUs it seems that Intel is the
> party that should enable this capability...

Intel has SGX, which theoretically allows you do do basically the same
thing as I described to Peter, purely in a software enclave.

You could just store your keys in a PKCS#11 token and your keys would
be magically bound to the hardware to prevent copying them, in exactly
the same way.

If only there was someone from Intel who was interested in that use
case. Of course, even while they were tilting at windmills internally
to fix the SGX signing model and make it possible to ship open source
code to use such an enclave in a PKCS#11 token, they'd probably have
their work cut out making PKCS#11 a first-class citizen in the open
source world so that it's *feasible* to just use a key from PKCS#11
instead of a filename, for various applications and crypto libraries.

https://fedoraproject.org/wiki/PackageMaintainers/PKCS11
https://bugzilla.gnome.org/show_bug.cgi?id=679860
https://bugzilla.gnome.org/show_bug.cgi?id=719982
...etc...

--
dwmw2
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Crypto Chip Support imaginable ?

Alexander Gostrer
In reply to this post by Marx, Peter
Hi Peter,

From your explanation my understanding is that you are limited with resources (CPU speed, memory, etc). Did you consider using C/C++ rather than Java? 

Regards,
Alex.

On Wed, Jun 15, 2016 at 9:37 AM, Marx, Peter <[hidden email]> wrote:

Hi Alex,

 

I’m aware of this engine, see requirement #1. That indeed can cover the provisioning process, combined with certmonger’s getcert via SCEP -> EJBCA PKI solution.

But the Java apps are not aware of this store, as they expect to access the store via PKCS#11…

 

Thanks

 

Peter

 

 

From: Alexander Gostrer [mailto:[hidden email]]
Sent: Wednesday, June 15, 2016 5:44 PM
To: Marx, Peter
Cc: Douglas E Engert; [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

 

Hi Peter,

 

Here is the OpenSSL Engine that we wrote by the Atmel request: https://github.com/AtmelCSO/cryptoauth-openssl-engine. It supports ATECC508A that is a superset of ATECC108 (has Diffie-Hellman). The engine also supports keeping certificates on the ATECC508A hardware. Like Douglas and David already said, it will not add any protection. But it is implemented. Youy can use it.

 

We do not use OpenCS in this project: we found that we didn't need any http support. Let me know if you want to talk to Atmel's FAE: they are very responsive and knowledgeable. 

 

Regards,

Alex

 

On Wed, Jun 15, 2016 at 7:29 AM, Marx, Peter <[hidden email]> wrote:

good point. Hopefully we can limit the enrollment to a trusted subcontractor's network. As the UUIDs resemble a known set which is relayed from ATMEL to us before the chips are soldered onto the boards,
only "spoofing" UUIDs out of this set would be the final attack vector I can't mitigate.

-----Original Message-----
From: Douglas E Engert [mailto:[hidden email]]
Sent: Wednesday, June 15, 2016 4:20 PM
To: [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?



On 6/15/2016 8:57 AM, Marx, Peter wrote:
> let's start with the requirements part:
>
> 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support.
>
> 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent  illegal hardware copies.
>
> 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file.
> The keystore and truststore files plus the cleartext passwords to
> access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware.

But the public key in the cert only works with the private key in the device. Copying the certs should not work.
This security depends on the CA only signing a CSR with the UUID from the chip. That is not clear how the CA verifies the UUID is the one on the chip. This is a card management issue for the CA.  If the CA is only signing CSRs generated at you factory where you have physical control of the chip, then it could work. If the CSR is generated by the user or in the field, the CA may not be able to validate the UUID is from the chip that signed the CSR.

>
> I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path.
>
> For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option.
>
> Peter
>
>
> -----Original Message-----
> From: David Woodhouse [mailto:[hidden email]]
> Sent: Tuesday, June 14, 2016 1:12 PM
> To: Marx, Peter; [hidden email]
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
> * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM
>
> On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote:
>> I’m IT architect in a big IoT project. I’m looking for getting
>> PKCS#11 support for Java applications on Linux, so i can get rid of
>> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys
>> shall be created/stored in hardware instead.
>>
>> But I can’t use Smartcards. The idea is to use a cryptochip on the
>> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The
>> chip is on I2C bus and is e.g. accessible from Linux as a device.
> OK... first question: why do you want certificates in hardware? What's the point in that?
>
> Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the
> *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates?
>
> Here's a straw man proposal; tell me why/if it doesn't work for you.
>
> Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage.
>
> For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ.
>
> For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores).
>
> So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask
> *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so.
>
> I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements.
>

--

  Douglas E. Engert  <[hidden email]>



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Knorr-Bremse IT-Services GmbH
Sitz: Muenchen
Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht Muenchen, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

 



Knorr-Bremse IT-Services GmbH
Sitz: München
Geschäftsführer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht München, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

Anders Rundgren-2
In reply to this post by David Woodhouse
On 2016-06-15 21:03, David Woodhouse wrote:
> On Wed, 2016-06-15 at 15:24 +0200, Anders Rundgren wrote:
>>
>> Since Intel have firmware in their CPUs it seems that Intel is the
>> party that should enable this capability...
>
> Intel has SGX, which theoretically allows you do do basically the same
> thing as I described to Peter, purely in a software enclave.

https://software.intel.com/en-us/articles/providing-hardware-based-security-by-leveraging-intel-identity-protection-technology-and

"To obtain a copy of the IntelJCE you need to contact your Intel representative"

Anders

>
> You could just store your keys in a PKCS#11 token and your keys would
> be magically bound to the hardware to prevent copying them, in exactly
> the same way.
>
> If only there was someone from Intel who was interested in that use
> case. Of course, even while they were tilting at windmills internally
> to fix the SGX signing model and make it possible to ship open source
> code to use such an enclave in a PKCS#11 token, they'd probably have
> their work cut out making PKCS#11 a first-class citizen in the open
> source world so that it's *feasible* to just use a key from PKCS#11
> instead of a filename, for various applications and crypto libraries.
>
> https://fedoraproject.org/wiki/PackageMaintainers/PKCS11
> https://bugzilla.gnome.org/show_bug.cgi?id=679860
> https://bugzilla.gnome.org/show_bug.cgi?id=719982
> ...etc...
>


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

David Woodhouse
On Wed, 2016-06-15 at 22:14 +0200, Anders Rundgren wrote:

> On 2016-06-15 21:03, David Woodhouse wrote:
> > On Wed, 2016-06-15 at 15:24 +0200, Anders Rundgren wrote:
> >>
> >> Since Intel have firmware in their CPUs it seems that Intel is the
> >> party that should enable this capability...
> >
> > Intel has SGX, which theoretically allows you do do basically the same
> > thing as I described to Peter, purely in a software enclave.
>
> https://software.intel.com/en-us/articles/providing-hardware-based-security-by-leveraging-intel-identity-protection-technology-and
>
> "To obtain a copy of the IntelJCE you need to contact your Intel representative"
One windmill at a time...

--
dwmw2
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Crypto Chip Support imaginable ?

Marx, Peter
In reply to this post by Alexander Gostrer

Hi Alex,

 

we don’t have a tight resource limit – It’s much more horsepower than e.g. Raspberry. It’s a NXP T1042 CPU, so no chance to leverage the discussed INTEL features.

 

Native Java would be preferred, but JNI wrapped C/C++ Code is a 2nd option.

 

 

Regards

 

Peter

 

From: Alexander Gostrer [mailto:[hidden email]]
Sent: Wednesday, June 15, 2016 9:20 PM
To: Marx, Peter
Cc: Douglas E Engert; [hidden email]
Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?

 

Hi Peter,

 

From your explanation my understanding is that you are limited with resources (CPU speed, memory, etc). Did you consider using C/C++ rather than Java? 

 

Regards,

Alex.

 

On Wed, Jun 15, 2016 at 9:37 AM, Marx, Peter <[hidden email]> wrote:

Hi Alex,

 

I’m aware of this engine, see requirement #1. That indeed can cover the provisioning process, combined with certmonger’s getcert via SCEP -> EJBCA PKI solution.

But the Java apps are not aware of this store, as they expect to access the store via PKCS#11…

 

Thanks

 

Peter

 



Knorr-Bremse IT-Services GmbH
Sitz: München
Geschäftsführer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
Registergericht München, HR B 167 268

This transmission is intended solely for the addressee and contains confidential information.
If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crypto Chip Support imaginable ?

David Woodhouse
In reply to this post by Marx, Peter
On Wed, 2016-06-15 at 13:57 +0000, Marx, Peter wrote:
> let's start with the requirements part: 
>
> 1. I want hardware security. Key pair generation shall happen on
> device and private key shall not leave the device. Minimum solution
> would be to do this with WolfSSL or OpenSSL plus the existing
> ATECC108 support.

I'll read that as "private key shall not leave the device except in
encrypted form". You're allowed to *store* it off-chip, right? As long
as it's encrypted such that only the chip can get it back again.

(This just simplifies the storage requirements and the API between host
and the crypto processor — you no longer need the whole filesystem and
PKCS#15 complexity.)

> 2a. I want to leverage the UUID existing in the chip to safeguard the
> TLS certificate enrollment process towards the PKI, where the UUIDs
> are pre-registered. Idea is to prevent  illegal hardware copies. 

This is kind of orthogonal to the precise model used for making keys
available via PKCS#11 to the Java apps. But OK.

> 2b. TLS client certificate CSR shall be created based on the UUID and
> the keypair. Resulting client cert signed by the CA (via SCEP) today
> goes into Java Keystore file. CA cert or TLS server cert go into java
> truststore file.
> The keystore and truststore files plus the cleartext passwords to
> access them are configured in ActiveMQ. As this is potentially
> unsecure, I had the idea of leveraging the chip a second time by
> storing the certs in it and
> providing a PKCS#11 interface to them, so that Java applications like
> AMQ can access them in a transparant way. Only Java JCE
> reconfiguration plus a little AMQ tweak would be necessary.
>
> Based on these requirements I'm not sure whether storing the certs in
> SoftHSM would be beneficial - one could still take away the certs and
> use them on another hardware.
No. Certificates are public. It's the corresponding private *keys* that
need protecting.

> I had checked TPM also, but more for safeguarding the boot process
> and integrity of the OS. And as a TPM chip is too bulky (28 pins) for
> our board, it wasn't an option anyway.
> For TLS via Java there is also no option to interfere with the
> encryption (at least to my maybe incomplete knowledge), so again no
> solution path.

Right. A full TPM isn't what you want. I was only referring to the
model we use in the openssl TPM engine, and other places, for asking
the TPM to 'sign <this> with <this> key'... where the key is an opaque
blob, previously encrypted by the TPM itself (using an internal key of
its own) and just handed back to us for *storage*.

> For something like data encryption before transmitting you have more
> options, as you code yourself. There your proposal of "TPM light"
> could indeed be an option.

Right. All your private keys — that you're currently storing in the
Java keystore — can be available through PKCS#11. They're stored on the
host side (managed by the PKCS#11 token) in *encrypted* form so the
*only* thing you can do with them is pass them to the crypto chip and
ask it nicely to perform an operation with them.

If I understand your requirements properly, that seems like the
simplest path to a solution. Perhaps you don't even need to make your
PKCS#11 token store certificates at all — just leave them where they
are at the moment.

--
dwmw2
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Crypto Chip Support imaginable ?

Anders Rundgren-2
In reply to this post by Marx, Peter


On Jun 16, 2016 9:29 AM, "Marx, Peter" <[hidden email]> wrote:
>
> Hi Alex,
>
>  
>
> we don’t have a tight resource limit – It’s much more horsepower than e.g. Raspberry. It’s a NXP T1042 CPU, so no chance to leverage the discussed INTEL features.

I would consider contacting the linaro organizatiob which works with similar issues for ARM.

Anders

>
>  
>
> Native Java would be preferred, but JNI wrapped C/C++ Code is a 2nd option.
>
>  
>
>  
>
> Regards
>
>  
>
> Peter
>
>  
>
> From: Alexander Gostrer [mailto:[hidden email]]
> Sent: Wednesday, June 15, 2016 9:20 PM
>
> To: Marx, Peter
> Cc: Douglas E Engert; [hidden email]
> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ?
>
>  
>
> Hi Peter,
>
>  
>
> From your explanation my understanding is that you are limited with resources (CPU speed, memory, etc). Did you consider using C/C++ rather than Java? 
>
>  
>
> Regards,
>
> Alex.
>
>  
>
> On Wed, Jun 15, 2016 at 9:37 AM, Marx, Peter <[hidden email]> wrote:
>
> Hi Alex,
>
>  
>
> I’m aware of this engine, see requirement #1. That indeed can cover the provisioning process, combined with certmonger’s getcert via SCEP -> EJBCA PKI solution.
>
> But the Java apps are not aware of this store, as they expect to access the store via PKCS#11…
>
>  
>
> Thanks
>
>  
>
> Peter
>
>  
>
>
>
> Knorr-Bremse IT-Services GmbH
> Sitz: München
> Geschäftsführer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider
> Registergericht München, HR B 167 268
>
> This transmission is intended solely for the addressee and contains confidential information.
> If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system.
> Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
12