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

[Marx, P. <Pet...@kn...>]

Confirmed by this source:

http://www-01.ibm.com/support/knowledgecenter/SSCQGF_7.1.0/com.ibm.IBMDI.doc_7.1/adminguide07.htm%23ToC_102?lang=en-us

the  ActiveMQ Java Keystore File used to handle the TLS connections does not only contain the public key / certificate, but also the private key.   

This holds true for all applications based on Java Secure Socket Extension(JSSE) .  And the password to access the key pair is in the app's configuration file... 

This drives my requirement to get rid of the keystore files.  Maybe I misunderstood something at the basis - I'm a late adopter of the crypto stuff.



-----Original Message-----
From: David Woodhouse [mailto:dw...@in...] 
Sent: Thursday, June 16, 2016 9:46 AM
To: Marx, Peter; ope...@li...
Subject: [Secure Email] Re: [Opensc-devel] Crypto Chip Support imaginable ?

* PGP - S/MIME Signed by an unverified key: 06/16/2016 at 09:45:44 AM

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

* dw...@in... <dw...@in...>
* 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.