MCU Bootloader: Encrypted firmware upload on KV3x?

[ac80]

Hullo,

We are using the KV31 on a custom board, and would like to deliver encrypted firmware updates to our clients, so our stuff can't be backward engineered if we need to deploy a feature or security update.

The SDK for MCU Bootloader is great - thank you for this. However, I haven't been able to build it with the encryption feature enabled.

#define BL_FEATURE_ENCRYPTION (1)

For this, we get 

fatal error: aes_security.h: No such file or directory	

 
From reading the manual, I'm led to believe this option will only be available when the MCU has an mmCAU (memory mapped crypto acceleration unit)...please feel free to correct this if untrue.

If this is the case, is it correct that we need to modify the bootloader source and implement our own aes_security.h and source?


Thanks in advance for any insight!

[mjbcswitzerland · Accepted solution]

Hi

For professionals requiring out-of-the-box secure loader solutions for any Kinetis or i.MX RT 10xx the uTasker project provides a proven, documented and supported solution. This includes also encrypted MCU Bootloader (KBOOT) compatibility - see video https://youtu.be/MXsJvTdCcH4

Regards

Mark

https://www.utasker.com/kinetis/FRDM-KV31F.html
https://www.utasker.com/kinetis/TWR-KV31F120M.html

[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1064.html

[ac80]

That's great, mjbcswitzerland

Thanks for the link to the video. This looks to be exactly what we were hoping for!

Since our interface is half-duplex, guessing we'll need to disable the uart receiver while transmitting, but judging from your video, modifying the bootloader looks straightforward... Presumably there will not be too much more involved in porting from the freedom project to our custom board? 

Appreciate the response and also your team's work with the uTasker project - looks very slick

Kind regards,
k

[mjbcswitzerland]

Hi

Porting is no issue - the project is designed to be very easily configurable for custom boards.

The UART for KBOOT mode is configured with

tInterfaceParameters.ucSpeed = SERIAL_BAUD_57600; // fixed baud rate for kboot compatibility
tInterfaceParameters.Config = (CHAR_8 | NO_PARITY | ONE_STOP | CHAR_MODE); // ensure no XON/XOFF mode used since the transfer is binary

There are additional option flags for RS485 or single-wire modes.
In the worst case (if the existing options don't prove to be as needed) the Rx can be disabled each time a transmission is started and re-enabled in the (optional) end of transmission call-back.

eg.
fnWrite(SerialPortID, (unsigned char *)ucAck, sizeof(ucAck)); // acknowledge the reception
becomes
fnDriver(SerialPortID, (RX_OFF), 0); // disable Rx during transmission
fnWrite(SerialPortID, (unsigned char *)ucAck, sizeof(ucAck)); // acknowledge the reception

When opening the UART:
tInterfaceParameters.txFrameCompleteHandler = _enableRx; // enter frame complete callback
SerialPortID = fnOpen(TYPE_TTY, FOR_I_O, &tInterfaceParameters);

static void __callback_interrupt _enableRx(QUEUE_LIMIT channel)
{
    fnDriver(SerialPortID, (RX_ON), 0); // re-enable Rx after frame transmission has completed
}

Devices with mmCAU will default to using this for AES256 decryption, those with LTC will default to using this and parts without HW accelerators will default to using AES256 code from mbedTLS, WolfSSL or OpenSSL (one can decide which one - there are details here https://www.utasker.com/docs/uTasker/uTasker_Cryptography.pdf , whereby I have found mbedTLS to be as good as any). Speed of the decryption is also secondary when loading via UART anyway and is not noticeable either.

Serial Loader guide: https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf

Regards

Mark

[ac80]

You're the man, Mark! 

Looking forward to running this on our boards  

[myke_predko]

@ac80 

Can I ask what is the likelihood of somebody reverse-engineering your code without the source?  

In 40 years, I've only seen it done once and that was the owning company's sponsored effort because the source code was lost and its author had died.  It took 18 months even with a tool that provided a guess at what the source would look like from the executable AND having engineers understood how the code functions worked - and I was quite impressed with the quality of the code that the tool produced.  This was in 1986-'87 and the code was written in PLS, so the tools and experience really aren't relevant to today.  

Now, I have seen quite a few cases of source code being found (usually on unprotected GitHub folders) and product code being copied.  

I'm not sure of the process of encrypting the code for distribution and then decrypting it when burning into Flash, but based on my experience I have to think that the most prudent course of action is to make sure your source code is well protected with procedures in place to make sure it doesn't get left on laptops or other potentially unsecured systems.  

Comments please?

myke

[ac80]

Hey Myke, 

Good question and thank you for the anecdote. The answer is I don't fully know, but it is my understanding that there are tools that would break down a binary into readable formats; also I understand that the binaries are essentially plaintext machine code.

It seems possible that the binaries could be decomposed to see how data moves from the ADCs through the memory and how it is worked on, which could be very telling. It would also show how PWMs and other controls are manipulated. 

It's part of our IP strategy to keep our algorithms and sensor array geometries secret. The electronics are encapsulated to prevent physical access, leaving only some RS485 (uart) lines exposed, and potentially binaries if we have to update in the field (likely since it's a new product line). 

As you say, keeping the source code secret (and backed up!) is also a significant concern too. However, when distributing firmware to other countries, we will be encrypting the images, just to cover our bases.

And from the looks of things, it will be by implementing our own software decryption in a custom bootloader!  

Thank you for the feedback!

[jingpan]

Hi ac80,

yes, you have to use your own software AES code. 

Regards,

Jing