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

[David W. <dw...@in...>]

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