Re: [Opensc-devel] Crypto Chip Support imaginable ?

[Alexander G. <ago...@gm...>]

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 <Pet...@kn...>
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:dee...@gm...]
> Sent: Wednesday, June 15, 2016 4:20 PM
> To: ope...@li...
> 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:dw...@in...]
> > Sent: Tuesday, June 14, 2016 1:12 PM
> > To: Marx, Peter; ope...@li...
> > 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  <DEE...@gm...>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Ope...@li...
> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>