Securing the QN90x0

EmilS — Thu, 14 Apr 2022 02:07:06 GMT

There is no document describing how to secure the flash content on a QN90x0
part. The only information is scattered through the UM and there's also a Python
script example called 'dk6_image_tool.py'. That's all, nothing else.
The 'DK6Programmer.exe' tool only reads/writes areas of the flash but it's up
to you what to write in the various areas.

So I've turned to internal ROM disassembly and this is the flash layout for
a QN9090:

{ 0, 0x9DE00}, // 0 Flash
{0x9E800, 0x400}, // 1 Psect
{0x9EC00, 0x400}, // 2 Pflash
{0x9FC00, 0x400}, // 3 Config
{0, 0x80}, // 4 Efuse
{0x9DE00, 0xA00}, // 5 Unk1
{0x9F000, 0xC00}, // 6 Unk2

The Efuse is not part of the flash, those are 128 bytes containing random data
which cannot be read the MCU, only the AES peripheral can load them as a key
to generate temporary transport keys.
Beside these fuses the chip has another 11 efuse bits which can be read by
the MCU and configure various operating modes (internal ROM). These bits are
not even mentioned in the manual.

BTW, there is an error in the UM at page 475 the SEC_CODE is described as writing
any value other than 0x87654321 will enable SWD access. That is incorrect and should
be: writing any other other value than 0x87654320 will disable SWD access.

My understanding is that the part protection works like this:
- right after reset the 2 SWD lines are normal inputs and don't respond to
SWD messages.
- based on the value of the 'SWD_DIS' flash bit (bit 31 of word 0x9FC00 in the 'Config' sector)
the SEC_CODE register is written with 0x87654320 and the 2 lines are
configured as alternate function SWD (to enable SWD), otherwise 0x789ABCDF
is written to SEC_CODE and since this is a write only register the SWD
cannot be re-enabled in the user code.

Another entry point is via ISP when DIO4 is high and DIO5 is low at reset time.
The 'Psect' and 'Pflash' areas are different from the others because they
each have 2 copies (0x200 bytes long) and a header with a magic number and a checksum.
Via ISP you can only see one of the copies. If one is corrupted the ROM uses the other one.
The ISP access is controlled by a word stored in the 'Psect' area at offset 0x14
which is in fact the word at address 0x9E834 if the first copy is used.

This word can have 5 values: 0, 0x01010101, 0x02020202, 0x03030303, 0x04040404
Any other value completely disables the ISP. The manual only documents the
0x02020202 one as write-only level. What are the others?

The reason I am looking into this is that I'm preparing for production and
the ISP method of programming the parts is not suitable for us for two reasons:
it's too slow and we also need to program a 4MB SPI serial flash.

For programming both the internal flash and the serial I'm using the Segger RTT
via J-Link. I first load a small program which executes in RAM and them I'm
sending at 4Mbps all the programming data for the serial flash, the internal
flash and finally I write to Psect and Config areas to secure the part.
This works great but has one disadvantage: if I want to reprogram the part
(other than via Bluetooth OTA) I need to remove the protection via ISP and
an AES key because the SWD is disabled now. On another part that we've used
in the past (the RSL10) you could re-enable the SWD with unlock registers
via SWD but the QN9090 doesn't support this.

What I would like to know is how do I set an unlock key?
The ISP Unlock function has a payload of 0x120 bytes, first 0x20 are
a magic number and a hash (signature) followed by 0x100 AES encrypted
unlock key. The plain unlock key is at offset 0x100 in 'Psect' and
another flag at offset 0x3C signals if it needs to be encrypted.

The ISP Unlock Key setting is not documented at all!

Re: Securing the QN90x0

antonioconcio — Thu, 14 Apr 2022 13:45:02 GMT

Hello Emil,

I am going to provide you additional details on it in a private support project.
I will set that up and get back to you early next week, after the Easter break.

Best Regards,
Antonio

Re: Securing the QN90x0

EmilS — Wed, 20 Apr 2022 02:08:57 GMT

I'm still waiting for that support. I presume the majority of QN90x0 buyers would want to secure their parts so why isn't a document about this?

topic Securing the QN90x0 in Wireless MCU

Securing the QN90x0

Re: Securing the QN90x0

Re: Securing the QN90x0