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

[Anders R. <and...@gm...>]

On 2016-06-14 13:11, David Woodhouse wrote:
> 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.

Since Intel have firmware in their CPUs it seems that Intel is the
party that should enable this capability...

Unfortunately Intel seems to be fairly uninterested in solutions
they don't get paid for in spite of the fact that their IPT system
http://www.intel.com/content/www/us/en/architecture-and-technology/identity-protection/identity-protection-technology-general.html
probably haven't generated a single cent in profits ever.

Anders

>
>
>
> ------------------------------------------------------------------------------
> 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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>