lesudu wrote on May 22, 2018:
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.
As the board does not have dedicated non-volatile memory, I am making flash function as EEPROM. This is done by this method: [https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en592077]
I am initiating the EEPROM, reading and writing using the functions provided. I am calling those read/write functions from PKCS11.c.
We get to choose the emulated EEPROM size as 511 or 255 or 127 bytes.
I am using 511 as EEPROM size.
But, is this the correct way to do this? Also, is this memory enough for writing root certificate, device certificate and the keys?
Kindly suggest if there is any other way to do this.
Thanks in advance!
aws-Xueli wrote on May 23, 2018:
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.
In the meantime, for lab testing purposes, an approach you can try is to split the larger crypto objects between multiple emulated EEPROM sections. For example, that logic could be implemented in our PKCS11_PAL_ReadFile and PKCS11_PAL_SaveFile internal helper routines (please see https://github.com/aws/amazon-freertos/blob/master/lib/pkcs11/mbedtls/aws_pkcs11_mbedtls.c#L135).
lesudu wrote on May 25, 2018:
Thanks a lot for the reply.
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!
aws-Xueli wrote on May 25, 2018:
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:
Once you’ve got that working, if your device ported code still won’t connect, I suggest that you enable verbose logging in mbedTLS. In the latest Amazon FreeRTOS code on github (v1.2.6 or newer), all that should be required is to uncomment this line in the mbedTLS config file, https://github.com/aws/amazon-freertos/blob/master/lib/third_party/mbedtls/include/mbedtls/config.h#L1915.
That assumes that you’ve got serial console output hooked up for your device. Debugging will be difficult without that, though.
lesudu wrote on May 28, 2018:
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!
lesudu wrote on May 28, 2018:
Clicked as answered by mistake
SarenaAtAws wrote on May 29, 2018:
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().
When you are able to get serial output working, please enable MBEDTLS_DEBUG_C in https://github.com/aws/amazon-freertos/blob/master/lib/third_party/mbedtls/include/mbedtls/config.h#L1915 and update this thread with your logs, from beginning to end, so we can help you further.
lesudu wrote on June 05, 2018:
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)?
Gaurav-Aggarwal-AWS wrote on June 07, 2018:
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.
lesudu wrote on June 07, 2018:
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.