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.


(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
May 7, 2021
In one of our Knowledge Booster Blogs a few months ago we introduced you to some tips and tricks for the optimal use of Virtuoso ADE Product Suite with our analog IC design videos . W e hope you... [[ Click on the title to access the full blog on the Cadence Community site. ...
May 7, 2021
Enough of the letter “P” already. Message recieved. In any case, modeling and simulating next-gen 224 Gbps signal channels poses many challenges. Design engineers must optimize the entire signal path, not just a specific component. The signal path includes transce...
May 6, 2021
Learn how correct-by-construction coding enables a more productive chip design process, as new code review tools address bugs early in the design process. The post Find Bugs Earlier Via On-the-Fly Code Checking for Productive Chip Design and Verification appeared first on Fr...
May 4, 2021
What a difference a year can make! Oh, we're not referring to that virus that… The post Realize Live + U2U: Side by Side appeared first on Design with Calibre....

featured video

Introduction to EMI

Sponsored by Texas Instruments

Conducted versus radiated EMI. CISPR-25 and CISPR-32 standards. High-frequency or low-frequency emissions. Designing a system to reduce EMI can be overwhelming, but it doesn’t have to be. Watch this video to get an overview of EMI causes, standards, and mitigation techniques.

Click here for more information

featured paper

Three considerations for automotive powertrain safety and security

Sponsored by Texas Instruments

With functional safety and security concerns in automotive electronics gaining attention, including in standards bodies, it’s important for automotive designers to enable functionally safe and secure automotive electric powertrains. Learn about three key safety and security considerations designers need to keep in mind when developing in the automotive space.

Click here to read

featured chalk talk

Accelerating Physical Verification Productivity Part Two

Sponsored by Synopsys

Physical verification of IC designs at today’s advanced process nodes requires an immense amount of processing power. But, getting your design and verification tools to take full advantage of the compute resources available can be a challenge. In this episode of Chalk Talk, Amelia Dalton chats with Manoz Palaparthi of Synopsys about dramatically improving the performance of your physical verification process. 

Click here for more information about Physical Verification using IC Validator