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

[Douglas E E. <dee...@gm...>]

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...>