editor's blog
Subscribe Now

A PIC for the IoT

If you’re building a Thing for the Things’ Internet (consumer-edition – i.e., the CIoT), then, even though you may do your heavy computing work in the Cloud, you’ll still need something to make your thing act more intelligent than the assembly of metal and plastic that it is.

Perhaps you’ll need it for management, perhaps for sensor fusion; it’s not likely to be a difficult computing challenge, but you’ll need something. To address this need, Microchip recently tossed a new PIC device into the fray: their PIC24F “GB2” family. Consistent with a growing IoT trend to integrate and make things simple, this one incorporates two critical elements for Thing computing: security and low power.

For security, they’ve built an encryption engine into the device, with one-time-programmable (OTP) key storage. Critically, the key is inaccessible to anything except the encryption engine itself, as shown in the drawing below. In fact, this version of the drawing is my Microchip-approved edit to their original drawing, which showed (for simplicity) both the key and the random number generator (RNG – note, this is true random, not pseudo-random) as also hanging off the peripheral bus, which would be a big security hole.

PIC_diagram_red.png

(Click to enlarge)

Image courtesy Microchip

Programming the key is done… programmatically. (Duh!). That is, it’s not some separate port that you plug a programmer or something into; the CPU does it.

There is an example in their documentation showing code that would do this. I assume it’s for explanatory purposes only, since, in that code, the desired key is effectively defined as a constant. If you actually used that code, stored in the Flash, then the unsecured Flash could happily dish up the key to anyone wishing to explore the memory. But it got me thinking: exactly how do you program this OTP without exposing the key in the process?

I asked Microchip, and they provided a number of scenarios. Having digested that, it seems to me that  there are three considerations:

  • Does every unit end up with the same key, or does each unit have its own unique key?
  • Where does the key come from?
  • What happens to the code that does the programming?

Let’s take those in order.

Microchip recommends that, for best security, each unit have its own key. That way any hacking (which is destructive) results only in a key to the now destroyed part. For your newbie hacker only.

One scenario with every unit having the same key occurs for folks wanting to secure boot code. The easiest way to do that is to encrypt the .hex file once with a single key and then use that image on all units. More complex approaches could allow unique keys, but, for instance, the factory would need to keep a database with key/serial number pairs in it so that, if the customer requested an updated version, it could be sent encrypted with that unit’s individual key.

Of course, if you’re a customer and have to update several units, then you’d receive one update image per unit (vs. one total if they all had the same key). And you’d have to make dang sure that the right image went in the right unit!

That moves the point of failure, of course, to that database – how secure is it? An alternative is to generate the image encryption key by encrypting the serial number (which is unique per device) with a secret factory key that only developers know. That can be calculated on the fly in the factory, eliminating the database. But, of course, it also assumes no disgruntled employees will divulge the key. Not airtight.

Coming back to the three considerations, the source of the key is important. If you store it in the Flash code, as in the example, it can be read in the clear. If you deliver it via some communication from a host PC or something similar, it is traveling in the clear, and is therefore vulnerable.

You can certainly operate that way, but Microchip recommends something different: use the RNG. That way each unit generates its own unique key, and no one knows what that key is. It simply works. This is airtight (except for the newbie hacker and his pyrrhic victory).

Finally, the programming code. Here’s the scenario: when you program the OTP key, it also sets a bit saying that the OTP has been programmed. Once set, that bit can never be cleared. So the first time the unit is powered on, it may not have a key yet, and the first thing you want to do is quick program the key. By checking for that flag, you know whether or not you need to program the key before moving on to the rest of the application.

Simple enough, but this is a one-time application. At the very least, you’ll be allocating scarce code space for a function (a few hundred bytes) that runs only once both in Flash and in RAM when executing.

If that’s an issue, another option is to have two applications: one for programming the key and the other being the main application. Store them on separate Flash pages and run them separately (so they’re not in RAM at the same time). On first power-up, run the key programming code and then erase that Flash page, destroying that code and freeing the page up for other use. Then load the main application, and off you go.

So, as you can see, there are a number of ways of handling this, some more airtight than others, and, as with anything having to do with security, you can make it as complicated as you want.

As to that other critical IoT function, low power, the chip uses their “XLP” (Xtra Low Power) technology, with Idle, Doze, Sleep, and Deep Sleep modes that monkey with what’s on or off and the clock rate. In Deep Sleep mode, it can draw as little as 40 nA.

You can get more info in their announcement.

By the bye, at the same time, they also released a new Bluetooth module, the RN4020. While they already have modules for various other Bluetooth flavors, this one supports Bluetooth Low Energy (BLE). You can find more about it their other announcement.

Leave a Reply

featured blogs
Sep 22, 2021
'μWaveRiders' 是ä¸ç³»åˆ—æ—¨å¨æŽ¢è®¨ Cadence AWR RF 产品的博客,按æˆæ›´æ–°ï¼Œå…¶å†…容涵盖 Cadence AWR Design Environment æ新的核心功能,专题视频ï¼...
Sep 22, 2021
3753 Cruithne is a Q-type, Aten asteroid in orbit around the Sun in 1:1 orbital resonance with the Earth, thereby making it a co-orbital object....
Sep 21, 2021
Learn how our high-performance FPGA prototyping tools enable RTL debug for chip validation teams, eliminating simulation/emulation during hardware debugging. The post High Debug Productivity Is the FPGA Prototyping Game Changer: Part 1 appeared first on From Silicon To Softw...
Aug 5, 2021
Megh Computing's Video Analytics Solution (VAS) portfolio implements a flexible and scalable video analytics pipeline consisting of the following elements: Video Ingestion Video Transformation Object Detection and Inference Video Analytics Visualization   Because Megh's ...

featured video

Accurate Full-System Thermal 3D Analysis

Sponsored by Cadence Design Systems

Designing electronics for the data center challenges designers to minimize and dissipate heat. Electrothermal co-simulation requires system components to be accurately modeled and analyzed. Learn about a true 3D solution that offers full system scalability with 3D analysis accuracy for the entire chip, package, board, and enclosure.

Click here for more information about Celsius Thermal Solver

featured paper

What is a smart DAC?

Sponsored by Texas Instruments

See how to add simple logic and programmability to analog circuits, without writing, maintaining and qualifying software. These devices have built-in non-volatile memory and are factory programmable. They also include programmable state machines, PWM generators and custom waveform generators – all in a single device. This means that adding simple intelligence to your analog circuits no longer requires a microcontroller.

Click to read more

featured chalk talk

The Gateway to Connected Intelligent Vehicles

Sponsored by Mouser Electronics and NXP Semiconductors

Connectivity is going to play a vital role in the future of connected and autonomous vehicles. One of the keys to the success of our future automotive designs will be the incorporation of service-oriented gateways. In this episode of Chalk Talk, Amelia Dalton chats with Brian Carlson from NXP about the role that service-oriented gateways will play in the future of connected and autonomous vehicles and the details of NXP’s new S32G2 vehicle network processors that are going to make all of this possible.

Click here for more information about the NXP Semiconductors S32G2 Vehicle Network Processor