CC3235SF: Verify an RSA signature inside the code

David Näslund

Part Number: CC3235SF
Other Parts Discussed in Thread: UNIFLASH, AES-128

Tool/software:

Hi,
I want to verify a signature of an external file (OriginalFile, not in the filesystem).

I can get the signature via OTA, and the hash (SHA256) via UART or SPI.
Obs, the certificate is already in flash.

So, I have all the pieces needed, but I always get errors when closing the file (which is when the signature is verified).

Here is what I have so far:

Perform OTA to get OriginalFileSignature.bin on the file system.
Read the file into the variable signedHash[256].
Get OriginalFileHash from other external source, put into unsignedHash[32].

Here is what I want to do:

Create/Overwrite new secure file, called Data.bin.
Write unsignedHash[32] to Data.bin.
Close the file with signedHash[256] as the Signature, and CERTNAME pointing to the cert with the public key.
If closed properly, then the signature has been verified.

So if it is successfully written/closed then the signature would be confirmed.

    FileHandle =  sl_FsOpen((unsigned char *)FileName,
                            SL_FS_CREATE | SL_FS_CREATE_SECURE | SL_FS_CREATE_MAX_SIZE( MaxSize )  | SL_FS_OVERWRITE ,
                            &MasterToken);
    if(FileHandle >= 0)
    {
        RetValWriteToFile = sl_FsWrite(FileHandle, 0, &unsignedHash[0], sizeof(unsignedHash));
        RetValCloseFile = sl_FsClose(FileHandle, CERTNAME, (const unsigned char *)&signedHash[0], sizeof(signedHash));
    }

    Display_printf(dispHandle, 0, 0, "The file [%s] opened: %s \t[%d]  \n\rWrote To File: %s \t[%d]  \n\rClosed/Verified: %s \t[%d]", FileName,
                   (FileHandle >= 0)        ? "Successfully" : "Error",  FileHandle, 
                   (RetValWriteToFile > 0)  ? "Successfully" : "Error",  RetValWriteToFile,  
                   (RetValCloseFile == 0)   ? "OK" : "Not ok",           RetValCloseFile);

I was not sure how the signature should be structured. In OpenSSL, I've tried the following.
(Note that <Data> is the <HashOfOriginalFile>)

$ openssl dgst -sha256 -binary -sign <PrivateKey> -out <Signature> <Data>
$ openssl dgst -sha1 -binary -sign <PrivateKey> -out <Signature> <Data>
$ openssl dgst -sha256 -binary <Data> > <TempFile>
$ cat <Data> >> <TempFile>
$ openssl dgst -sha256 -binary -sign <PrivateKey> -out <Signature> <TempFile>
(this is the same way I verify the Image of the CC3235SF)

Then I turn the <Signature> into an array in c (like "uint8_t signedHash[256] = {0xF8, 0x2c, ...};" to test it).

So, basically, the <HashOfOriginalFile> is a normal secure file, but I have no Idea how to use them (except for the Image).
I have the "MasterToken=0" for now, since I do not know how to use/deal with it.

The error I get when closing the file is "-10289", meaning "SL_ERROR_FS_WRONG_SIGNATURE_SECURITY_ALERT",
but when I verify it directly with OpenSSL it works fine.

Would appreciate any help or suggestions on the issue!

Best Regards
David

5 months ago

0 David Näslund 4 months ago

Prodigy 90 points

(I also tried having the data as a Base64 string and signing the resulting text file.
But everything leads to the -10289 error.)

(Writing the data to the opened file seems to work fine, the error happens when closing it.)

0 David Näslund 4 months ago

Prodigy 90 points

If there is a better way to verify the signature of the external file, then I am open for suggestions.

When we get this to work, if the wrong signature is given 15 times, there will be security alerts
locking the unit in a secure state. Which makes it unusable (not ideal in our case).

0 Shlomi Itzhak 4 months ago in reply to David Näslund

TI__Guru 64455 points

Hi,

I am currently out of office, returning next week, but the error means that the signature cannot be validated.

Could be the signature itself or maybe the certificate that is used to verify the signature.

Basically, you can read on the NWP guide, chapter 8.4.6 on closing a secured file.

You can also maybe try to use Uniflash instead of openssl and see if it works.

It is supposed to be under the Tools option.

Regards,

Shlomi

0 Shlomi Itzhak 3 months ago in reply to Shlomi Itzhak

TI__Guru 64455 points

Hi,

Have you tried Uniflash instead of SSL as I suggested?

Reading through again, I am a little confused with what you are trying to do.

Basically, the way a signature is created is by calculating the digest of a file first, then applying the private key on the digest.

From what you are describing, you get the digest and call it unsignedHash[], write it to a file and close with signedHash[] as a signature?

the signedHash[] is the signature for the original file for which the unsignedHash[] was calculated for.

Can you clarify?

Shlomi

0 David Näslund 3 months ago in reply to Shlomi Itzhak

Prodigy 90 points

Hi,

Thank you for taking time for this.
I understand that this is a bit confusing, but I basically only want to verify a file that is located outside of the CC3235SF.
Hopefully this explains it in a better way.

The file is located in the flash of another processor, and is too large to read in one piece.
We therefor calculate the hash in chunks and send the result to the CC3235SF.

Whenever we update the file, we want to verify it using the security of the CC3235SF. We can add a signed version of the hash
in the OTA-package, meaning, the CC3235SF gets access to the hash and a signed version of the hash.

Now we want to do the verification, by either
1. Signing the hash, and comparing with the signature - (Here we would have the Key as a secure file)
2. Saving the hash as a secure file, using the signature as the signature - (I have not gotten this to work)

There are problems with both solutions
1. Higher risk of exposing the Key. - (also, not sure it is possible to create a digital signature inside of the SW)
2. Might "brick" the unit if it fails 15 times - (according to my understanding)

Option (2.) would check against an actual certificate inside the Root-Of-Trust, which is very good.
Otherwise, we could simply use (1.) with HMAC, which is not as good but much simpler.

To answer your questions (this was 2 months ago, so might not remember fully),
But here are my tests:

Since I have to do the verification inside the code, I took the signature-output from Uniflash and put it into an array.
I tried using output from both Uniflash and OpenSSL (same output in both cases):
1. as a string
2. as B64,
3. as byte array

And tried using both AES-256 with RSA-2048 keys, AES-128 with RSA-1024 keys, and also EC keys. I even tried
concatenating the hash and the signature as the saved file (like we do with the SW-Image). I know the key is good for
the AES-256 RSA-2048 (same key that signs the SW, and that part works). But I always get the errors.

Even if we use the HMAC option (which I know how to do), we will still need to get the secure files working from within the SW.
Because we are going to start storing some material as secure files soon anyways.

Also, to clarify your last question. Yes, I'm trying to save/close unsignedHash with signedHash as a signature.
And Yes, signedHash and unsignedHash are calculated from the same file (signed with the private key of a certificate in the Catalog).
The signature has the same output in both Uniflash and OpenSSL, and can be successfully verified with OpenSSL.

Thanks for the help!

0 Shlomi Itzhak 3 months ago in reply to David Näslund

TI__Guru 64455 points

Hi,

The description is clear but maybe I am still missing something.

When we close a secured file in our filesystem, what happens under the hood is that the hash of the file is calculated, and compared against the public key (in the certificate) that runs against the signature. Since the signature is the outcome of the matching private key and the hash of the same file, they should match.

In your case, it seems that the original file you need is the long file that is not on our file system because the hash is taken on this file. You try to create a file on our file system which is only the hash of the long file and provide the signature to the long file, not the short one that you store in out file system.

What would actually happen is that we will compute the hash on the hash of the long file and hence it would not match the signature.

Shlomi

Wi-Fi

Wi-Fi forum

CC3235SF: Verify an RSA signature inside the code