PKCS11 support

[matriedel]

Storing the private key in a file is not a good approach in terms of security.
A solution is adding an HW crypto device with PKCS11 support.

Could you please accomplish a direct read of the key via PKCS11

[JonathanHenson]

We’re currently planning on adding this support soon. Could you possibly give us a bit more of your use case so we can make sure to deliver what you need.

Current plan:

Refactor tls options to use byte buffer instead of paths. This should give you a DIY solution.

After that we’ll do the hard part of reading the devices. If you want us to do this for you could you provide platform info? What type of device? What OS?

[JonathanHenson]

Ill add, we never plan on making is specific formats first class citizens. We’ve done a lot of work to make PEM armored pkcs#7 work everywhere. We support pkcs#12 on apple and cert manager on windows, but we want to avoid coupling users to those platform specific formats.

[matriedel]

We have developed a Linux based IoT embedded HW that includes the cryptographic object ECC608.
We added the PKCS#11 as an abstraction API according to https://github.com/MicrochipTech/cryptoauthlib/wiki/PKCS11-Linux-Setup

Our connectivity is limited by low datarate M2M connection.
To transmit data to the AWS IoT cloud we want to use MQTT in a secure way.

Examples like [1] make use of e.g. API function call myMQTTClient.configureCredentials that requests for the /DEVICE/KEY/PATH parameter and does not offer any means to use any kind of cryptographic object e.g. via PKCS#11 instead.
Also here the private key is stored in a file.

References:

[1] https://aws.amazon.com/de/blogs/iot/how-to-implement-mqtt-with-tls-client-authentication-on-port-443-from-client-devices-python/

[JonathanHenson]

okay, here's phase 1:
#107

[JonathanHenson]

@matriedel can you have a look at this PR (I'll be merging it in a few minutes), to see if that's all you need for pkcs#11?

Namely, We may need to do another pass that allows non-PEM formats to be loaded assuming the user can get the read into a DER format and pass it to us. But we won't have to break the API again to support that.

[matriedel]

Thanks a lot for your progress. Currently, we are working on Python
I learned that the aws-c-io libraries used by the v2 SDK for using a key imported via buffer. https://github.com/awslabs/aws-iot-device-sdk-python-v2.
This support has not yet been exposed via per-language bindings, but should be in the near future.
Once it is available I am looking forward to integrating and testing.

[ColdenCullen]

@matriedel I believe support for importing keys via buffer should be available in the latest versions (by using the TlsContextOptions functions not postfixed with _from_path). Can you let us know if that meets your needs?

[bryan-hunt]

@JonathanHenson @ColdenCullen
I started looking through these libraries due to a request to evaluate what would be required to add hardware backed credentials to aws-iot-device-sdk-cpp-v2 by an AWS Solutions Architect which has led me to this, the IO library.

The primary driver for using a hardware device is that is that it keeps private keys out of system memory (see HSM, TPM, etc) in a purpose designed device. Can you verify there is a plan (or work currently underway) to eventually support the pkcs11 signing mechanism?

I have found that @dwmw2 's commentary on pkcs11 to be very helpful in understanding the larger community needs of pkcs11.

[justinboswell]

We do have plans to support pkcs11 in the near future. I can't give a specific time frame, but we have both internal and external customers that need to do TPM and other hardware solutions. We need to build a bit of infrastructure into aws-c-io, and then it should be relatively straightforward to add support for additional vendors.

[dwmw2]

Before we can do this, we need s2n to support it properly. Ideally, it should conform to my best practice document which basically says that any software which accepts a private key in the form of a filename should also transparently support RFC7512 PKCS#11 URIs in place of a filename.

My doc also covers the format used for TPMv1.2 wrapped key files, and I need to expand it to cover the PEM storage of TPMv2.0 keys too (cf. tpm2-software/tpm2-tools#1599 (comment))

@colmmacc, any thoughts?

[SuicidalLabRat]

It's great to hear there is movement on this front, as this functionality is critical path for us. Frankly, when we worked with Microchip and AWS in the design of our most recent sku, we were led to believe this functionality would be exposed (outside of greengrass core) in the near term.

I'm curious, is none of the work to implement HSI in GG core portable for use here?

Is there somewhere we might track progress on this effort?

[drewwestrick]

I'm curious if there has been any movement on this topic. We just finished our own custom integration of Microchip's ATEC TPM to work with AWS IOT Core. It works for our use case (C), but really lacks the ability to support a wide variety of languages like most of the aws sdks now. Like others have said, pkcs11 support in s2n since it's already using openssl seems like the easiest and most abstract way to support this device as well as others.

[vishalSpintly]

Hello,
We have an IoT device running Linux.
Currently, the certificates are stored on file system and use the AWS IOT Core C library to connect and authenticate with the AWS servers.

We are evaluating on our device, a ATEC TPM connected over an I2C interface to store the keys.
So far using resources available on the internet, we are able to configure the PKCS11 interface and able to communicate with the TPM device.

My area of exploration next is how do I use the open source PKCS11 infrastructure in conjunction with the AWS IOT Core ( C) library to connect and authenticate with the AWS servers seemlessly.

Is the infrastructure to achieve this available?

Please do guide.

[graebm]

Supported circa #451