How to generate a HASH (or similar) value of program stored in QSPI flash that is unique to the processor that it is running on?

[mjbcswitzerland]

Hi All

I am looking for a solution that allows me to generate a HASH value for code stored in the QSPI flash. However the value generated must be unique to the processor that it is being generated by. Furthermore, it must not be possible to be able to know how to generate the same HASH based on any 'visible' information read from the processor itself.

I expect that this is possible by using features of system security (such as HAB) but the details to this operation are restricted to a certain degree so rather than attempt to work out low level details maybe generally someone knows of how it could nevertheless be done using general features.

The idea is the following - the i.MX RT have unique IDs and I understand that there is one that can't be read (not even by NXP) and is used as unique number input to the security system. This would be perfect since it could neither be accessed over the serial interface (eg. when eFuse values were to be used) not via JTAG.
If I could cause the security module to be able to generate a HASH value with this unique (secret) ID it would solve the problem.

Eg. I could imagine a pseudo-call that does:

void hash_my_code(unigned long *pointer_to_code_in QSPI, unsigned long LengthOfCode, unsigned long *ptrHashResult); // prototype the routine to be developed, based on security module capability (if possible usable on all i.MX RT 1011..1064 range)

unsigned long ulHash[LENGTH_OF_HASH_LONGS]; // buffer for the result
hash_my_code(0x60000000, 0x4000, ulHash);
// the unique hash of the code stored in QSPI flash area is now available unique to this processor!!

I could do this be using the visible ID in the eFUSEs (but it is not very "random") or by programming random values to general purpose eFUSE registers but then both JTAG access and also serial interface access to the eFUSEs needs to be disabled, which I desperately want to avoid in this case.

Does anyone know how this could be done?

Thanks

Regards

Mark

[jeremyzhou]

Hi Mark Butcher ,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
I think the authentic boot can give us some inspiration, the hash value is generated by a hash algorithm, and to make the hash value be unique to the particular chip, you can use a key which can use the unique ID or just random number to encrypt the above hash value.
After this encryption, it will generate a unique identifier.
During the process, the Data Co-Processor (DCP) module can provide hardware acceleration for cryptographic and hash algorithms.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

Thanks for the response.

The main difficulty is that I don't have access to the details to the modules (I don't have an FAE at the moment and so can't obtain the documents) but I may have found a solution.

I could reverse engineer some BEE initialisation code and therefore seed its AES128 key with a random value [using TRNG] (SW_GP2) that is not readable by either the code nor external sources. Then by reading the firmware I could use the decryption to generate an array that is only achievable on that particular processor. Probably this is suitable and of high enough quality to make it practically impossible to be able to generate the same array using the same input on a different processor.

I am banking on being able to find a similar method for the i.MX RT 1011 (I see the same protected eFUSE register SW_GP2 can also be used by OCOTP1, in order to have a general solution) in order to maintain a processor-independent method.

Regards

Mark

[jeremyzhou]

Hi Mark,

Thanks for your reply.
According to your introduction, in my opinion, the mechanism is very close to the asymmetric cryptography, firstly use the public key to encrypt a firmware, then reading the firmware and decrypt it with the private key in the MCU to generate an array.
BTW, the private key should be protected from being read by the hackers.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------