CC3220SF: ECDH or ECIES with NWP key storage

Balazs,

Trying to understand the use case alittle bit: You want to use the Device Unique Key pair to create a way to do offline secure content delivery. In a sense, you would download the public key of the device to a PC, then sometime in the future, if you needed to transfer data you want to encrypt with the public key, place the data on a sd card, and have the device read the encrypted data and decrypt using the private key?

BR,

Vince

Yes, that matches the intended use-case well.

Thanks

Balazs

Vince,

do you have any suggestion on how this use-case could be supported?

Thanks,

Balazs

Balazs,

Yes I believe this should be possible. I have not tested this so please let me know if you run into issues:

1st get the public key/Cert - http://www.ti.com/lit/ug/swru455h/swru455h.pdf Section 17.1.1.4 (Key index 0 is internal private key)

2nd encrypt data using this - Use Openssl or whatever you prefer

3rd send this data to the apps core, and use secure content delivery special flags to save the file (Section 17.2.1).

4th Open file as normal and check data is correct.

Let me know how your testing goes!

BR,

Vince

I tried to test this. I can get the public key for the device-unique key, any key I installed or the temporary key all right.

I used the GenerateSecureDeliveryContent.sh to make the download binary. One problem is a bug that causes this script to sometimes create incorrect encryption, because the key XOR-ing code sometimes forgets nibbles when they are leading zeros. Fix is like this, four lines need to be modified: 

key+=`printf '%08x' "$((${t1}^${t2}))"`

The next problem I ran into is that when opening the file with the encrypted content delivery, the documentation refers to syntax that does not exist in the API. In section 17.2.1 the code is

secAccessFlags = SL_FS_FILE_MODE_OPEN_CREATE(fpInSize,SL_FS_FILE_DOWNLOAD_SECURED_CONTENT);

but neither SL_FS_FILE_MODE_OPEN_CREATE nor SL_FS_FILE_DOWNLOAD_SECURED_CONTENT exists as macros in the CC3220 SDK. The correct code seems to be:

secAccessFlags = SL_FS_CREATE | SL_FS_CREATE_MAX_SIZE(fpInSize) | SL_FS_WRITE_ENCRYPTED;

Next problem is that in this API there is no way to refer to the ObjId of the key I wish to use for the decryption. Also in the encrypted file format there is no reference to which public key the file was encrypted for. This means that the NWP has no way to guess which of the 8 keys it would need to be using for the decryption of the file. Any pair of ECDSA keys can create a meaningful ECDH secret which turns into a meaningful IV and AES key which turns the encrypted payload into some plain text and SHA256 value.

My experience when trying this in practice is that I can write the encrypted payload, and when trying to close the file I get error -10304

#define SL_ERROR_FS_SECURE_CONTENT_INTEGRITY_FAILURE                    (-10304L)

which presumably means that the decrypted SHA256 value did not match the decrypted content. In other words, the wrong AES key was used or the wrong ECDH secret was computed.

I found that this error is generated in both of the following scenarios:

1) do not install any ECDSA key (only key 0 / device unique key exists), encrypt to key 0 public key.

2) install a permanent key into slot 1, encrypt to the public key of that permanently installed key.

The only case I could find that does not generate this error is to create the temporary key, then without rebooting, transmit the public key, encrypt to that public key, then write the such generated encrypted payload, i.e., the original documented method.

If there was an API to select the Object Id (the key slot) at the time I open the file for write with encrypted delivery, I think that would solve the problem. It would also help to understand why test 2) did not work.

thanks

Balazs

[see reply below]

Balazs,

Your observations are correct. The Secure Content Delivery using key index 1. It requires the user to create the temporal key, and performing this secure content delivery using this key pair. 

I would suggest not using the secure content delivery flow for what you are trying to do. This method involves the sflash encryption and as you've seen you won't be able to get it working exactly how you expect.

Instead, use the crypto engines to decypt the data on the apps processor, then do whatever you'd like with that data (Create new secure file, parse the data, etc).

Look at our TI Drivers documentation and software and look for the APIs CryptoCC32XX_encrypt() and CryptoCC32XX_decrypt()

BR,

Vince