I am trying to port Amazon FreeRTOS to Atmel SAM4E devices. I am using SAM4E Xplained pro development board. I did most of the porting and everything is compiled. But, I have a problem with key provisioning.
Hello, most X.509 certificates used in production are unfortunately not going to fit in 511 bytes. For example, the VeriSign root certificate that is used by AWS IoT for server authentication is roughly 1.7 kB in encoded form. Also, an RSA “Thing” certificate generated by AWS IoT is 1.2 kB and its (encoded) private key is more than 1 kB.
As an alternative for your Thing certificate and key type, an ECDSA private key can be encoded into roughly 240 bytes. The corresponding certificate still ends up being around 1k, but you can probably make it a little smaller by creating a certificate with a very short subject name, and all optional extensions omitted. Please note that while AWS IoT will generate an RSA certificate and private key for you (for the purpose of lab testing), if you want to use ECDSA, you need to create your own. For more information, please see “Creating an AWS IoT thing based on a P-256 client certificate” in https://docs.aws.amazon.com/freertos/latest/userguide/security-pkcs.html.
I therefore recommend the following. For production, it is advisable to use a crypto offload engine that offers asymmetric key generation, limits key exportability, and uses memory not accessible to the main app. Our vendor partners offer a variety of options. Without that level of protection, device cloning (i.e., based on theft of the private key) is a risk.
Currently, for testing purposes, I switched to FAT file system. I am using FreeRTOS+FAT file operations to write and read the Certificate and key data to and from the SD Card. I implemented it in PKCS11.c functions prvSaveFile and prvReadFile.
How different is these functions from the ones mentioned above: PKCS11_PAL_SaveFile and PKCS11_PAL_ReadFile? Am I supposed to use this instead of the functions in PKCS11.c?
Even though reading and writing is happening properly, I am having troubles connecting to secure sockets. Sometimes mbedtls_ssl_handshake() function hangs. When it does not, the connection is not successful and the socket is closed gracefully.
FYI, my entropy source is EEPROM and read/write is working as expected.
I am stuck and can not figure out where the error is!
Regarding PKCS11_PAL_SaveFile and PKCS11_PAL_ReadFile, those are newer names that are more consistent with our coding style guidelines, but they have essentially the same behavior as the old versions.
Regarding debugging the TLS handshake failure, the first thing to check is that the same certificate and private key can be successfully used with the MQTT Hello World demo running on our Visual Studio based simulator. Please see:
Hello,
I have already tested the Certificate-key with Hello world demo in windows simulator. It is working fine and I am using the same for Micro controller ported code.
Error I see is whenever the Handshake works properly, Sockets_Connect() is returning -128, which means socket is already been closed.
As I am sure about using correct key and certificate, the problem cannot be this. However, i am using the default root certificate. Can that be an issue by any chance?
I am using mbedTLS library working with Amazon FreeRTOS Simulator without any considerable modifications. I do not have a serial console output yet, but I will check with verbose debug options with mbedTLS when I have it running.
Depending on the information given, can you make out anything so that it can be solved asap?
Thanks in advance!
Given that you have tested the certificate-key associated with your AWS IoT Thing on Windows Simulator and it works, I would agree that there is not an issue here. Regarding your comment about the “default root certificate”, I assume you are talking about the certificates in +aws_default_root_certificates.h+ used by the Amazon FreeRTOS TLS library? If that is the case, then there is no need to change anything here as the Windows Simulator Hello World demo uses these as well.
It is hard to tell your issue from just the return value of SOCKETS_Connect().
Yes. I am using default root certificates.It seems to be working now!
Regarding the storage for certificate and key, I do not have dedicated non-volatile memory.So, temporarily storing those in SD card. But I don’t actually want to use the SD card to store credentials.
However, I have embedded flash memory of 1024kB, which is enough to carry out most of the operations.
As I am doing some kind of lab testing, would it be possible to store and retrieve the certificate and key from the flash memory? (for SAM4E Xplained pro hardware)
If possible, is it recommended (considering this is not used for production)?
In our experience, lab tested solutions have a way of making it into production, so we recommend adopting secure key storage now rather than later. If flash is your only near-term option, be aware that private keys not protected by dedicated hardware can potentially be stolen via physical or remote attacks.
Thank you for the insights.I will keep that in mind.
There seems to be bunch of hardware constraints in my case (like absence of dedicated NV memory and TRNG and less flash memory), which can make the final product not so secure. Even though most of the functions are already ported, I will consider using the different hardware. It should not be a problem because it is in the prototype phase. Thanks again for the support.