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

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

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 <Pet...@kn...>
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:ago...@gm...]
> *Sent:* Wednesday, June 15, 2016 5:44 PM
> *To:* Marx, Peter
> *Cc:* Douglas E Engert; ope...@li...
> *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 <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
>
>
>
>
> 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.
>