Protecting transient symmetric keys by XORing with a randomised non-persisting processor register..?

[np]

Hi everyone,

I'm currently trying to prevent transient symmetric keys from persisting in memory over a reboot. My cunning plan is to XOR them with an i.MX RT1064 processor register (that's guaranteed to be zeroed at reboot) that I set to a random number at reboot. (This would be the opposite of a non-volatile register.)

Has anyone tried to do this before? If so, which processor register did you use? Or if not, which i.MX RT1064 register would you suggest?

Thanks, Nick

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Actually, I'm not very clear with your proposal, whether you want to use the registers that will be cleared to 0 once reset, to store the symmetric keys, is it right? If not, please clarify it again.
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.
-------------------------------------------------------------------------------

[np]

Hi Jeremy

The sequence I have in mind is more like this:

• Device boots up
• A random value is placed in an (otherwise unused) CPU register
• When a transient symmetric key needs to be stored, it is XORed with the register contents
• When a transient symmetric key needs to be read back, it is XORed with the register contents
• The device reboots, automatically clearing the CPU register to zero
• (Anyone trying to sniff memory for the transient symmetric key contents will be disappointed!)

Thanks, Nick

[jeremyzhou]

Hi @np ,
Thanks for your reply.
According to statements, in my opinion, you can store the value to the SNVS_LPGPR or IOMUXC_SNVS_GPR, even internal RAM is available too.
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.
-------------------------------------------------------------------------------

[np · Accepted solution]

Hi Jeremy,

The SNVS_LPGPR registers are the opposite of what I want! The SNVS_LPGPR registers persist over a warm reset, but I want registers that are designed to be cleared or reset by a warm reset.

Anyway, I've now spent some time going through the datasheet, and I think I'll be using LPSPI4->DMR0 and LPSPI4->DMR1 (i.e. LPSPI4's 2 x 32-bit data match registers). This is because I'm not using LPSPI4 (or indeed LPSPI data matching), and these data match values get cleared on reset.

Thanks, Nick

[np]

...the only problem is that I don't seem to be able to set the DMR0/DMR1 registers in the way I expect. But I'll raise a separate ticket on that.