encryption of application code

RE: encryption of application code

John — Tue, 05 Jul 2016 12:19:22 GMT

Interesting. I wasn't aware of that Android capability. I get why as a developer that would be really handy, but that sure is a security nightmare. As long as the attacker had that sniffer enabled when the devices paired, then yes I believe the encryption could be defeated.

RE: encryption of application code

babaly — Fri, 01 Jul 2016 22:22:07 GMT

It seems you forget about a trivial option on Android systems, a hacker can sniff his own Bluetooth traffic easily by enabling Bluetooth HCI Snoop Log and if your firmware is not encrypted it can be stolen during a firmware upgrade process. I think BLE security options don't help in this case but please correct me if I'm wrong.

RE: encryption of application code

mstrouse — Thu, 23 Jun 2016 16:01:46 GMT

Consider "scrambling" the binary before you generate your hex file. In doing what you are currently doing, you are scrambling the hex file header(s) and trailer(s). And after that, nothing can make sense of it.

I agree with John tho ... look into BLE security options before you spend a lot more time on this.

RE: encryption of application code

John — Thu, 23 Jun 2016 12:45:45 GMT

Then you should look at the BLE pairing and security options. The latest bootloader is set up to be able to share pairing information with your application firmware so you can preserve an encrypted connection between your devices when in bootloader mode. Scrambling the hex file is not going to work.

RE: encryption of application code

lee — Thu, 23 Jun 2016 12:43:23 GMT

I wish to protect the algorithms in the application hex file on their way to the nrf52 during over the air updates. Not so worried about people reading our code back using a debugger as we'll be using read back protection.

RE: encryption of application code

John — Thu, 23 Jun 2016 12:37:03 GMT

It is hardly surprising that scrambling your hex file results in a corrupted hex file. If you are looking to protect your application from being reverse engineered I'd look at the read back protection features of the nRF52 instead.