feature article
Subscribe Now

Automatic Security Policy Implementation

Secure Thingz and IAR Simplify Security Infrastructure

They say that security can’t be designed as an afterthought. That security must be thought through as an early aspect of planning and architecture design. (“They” being… well, the same “they” that say lots of things.)

It would be so much easier if a small design house could have one security expert (at most) that everyone could run to with last-minute implementation requests. “Hey, we need PKI authentication. Can you quick add that in?” Or, “Hey, it turns out that, if we bury the same private key in every device, then, if it gets hacked, all devices are exposed. Who knew?! So… can you bury it deeper please?” “Hey, we need to say we have security on the data sheet. Can you do something so we can say that and have it be plausible? Kthxbai!”

But if we need to think this stuff through from the get-go, then… well, the implementation folks aren’t really involved then. So you need at least one person to deal with the high-level aspects of security. In other words, the security policy. When that’s in place, then we need a code jockey to implement that policy. (Yes, you could have one person do both… but bear with me.)

To be clear, there are two aspects (at least) to security:

  • There’s the infrastructure: the capacity for the 3 As (Authentication, Authorization, and Attestation), encryption, secure boot, secure updates, etc.
  • Then there’s making sure that there aren’t any hidden gotchas in the rest of the software code that might provide a way for someone to hack past the security infrastructure.

It’s that first one that we’re going to focus on here. The other is also important, but we’ll leave that for another time. Basic security infrastructure is a major addition to small, simple designs that have never had to consider security before. And there’s not necessarily any one-size-fits-all solution. Yeah, the high-level things you need to have may cover lots of systems, but it’s the details of what they’re intended to protect and how they protect them that vary from system to system.

This discussion comes courtesy of an announcement by IAR and Secure Thingz (now wholly owned by IAR) that’s intended to simplify the implementation of robust infrastructure. And the products that they’ve announced – created by Secure Thingz and made available in IAR’s environment – are split according to the two phases of security design that we mentioned above.

Creating Embedded Trust

We start with that most critical aspect of security: creating the policy. At this stage, all implementation details are abstracted away. In fact, you could be creating a single policy that would apply to a whole series of products. Those products might have different microcontrollers (MCUs); some might implement security in software, others in hardware. Doesn’t matter: the policy can apply to them all equally – because the policy doesn’t hinge on lower-level implementation options.

Here you’re answering questions about how you want to handle certificates and keys, how you want to do secure updates, and what aspects of the software suite should be attested at boot-up (or at other times). We’re not talking about elements that will be implemented in app software or will be laid over an RTOS or other OS; we’re talking about functions that will be embedded in the boot code and come up as a fundamental part of the low-level system architecture.

The security policy should be digestible by anyone with solid security expertise – whether or not they’re equipped to code that infrastructure.

Secure Thingz provides a way to capture all of this in a machine-readable security profile. They call it Embedded Trust. The profile contains enough specificity that implementation can proceed directly from the policy, modulated by the details of the underlying platform – the MCU and other hardware.

Can You See Trust?

The second part then takes place for every system as part of the implementation, and it’s handled by another product called C-Trust. This is used, not necessarily by security planners and architects, but by coders.

Ordinarily, coders could read the security profile and then… well, write code that implements the policy. Hopefully correctly. Not to cast aspersions on the huge population of coders out there, but manual interpretation of policies is subject to interpretation. Give two coders the same profile, and you run a decent chance of ending up with two different implementations.

Part of that could be due to ambiguities in the strategy as written. By intent, anyway, a machine-readable Embedded Trust profile should be clear as to what’s needed. But are all implementations the same? Is the code airtight for each one? Was anything inadvertently omitted from the implementation?

Secure Thingz have decided that, within an environment like the one provided by IAR, an easier, less error-prone approach is to have a tick box for security. If selected, then you get an opportunity to select a profile to import into the project. A profile created by Embedded Trust can be interpreted by C-Trust. That profile, along with specific knowledge of the MCU and other security hardware (like encryption acceleration) for a specific system, lets C-Trust auto-generate boot code that implements the details of the security policy.

That all sounds straightforward – maybe, depending on some details. Code generators often create source code that is then compiled into the rest of the software. If that’s the case, then what if there’s a compile error involving the security code that the coder didn’t write by hand? On the other hand, if object code is used, then might some issues create a need to debug the security stuff – again, that the coder didn’t write or compile?

I checked on this with CEO Haydn Povey, and he clarified that the IDE imports binary code in a filed called the SREC. The Security Manager then takes that SREC, modifies it according to the system and policy, and puts out a new version called the mastered SREC. This is the actual binary code that will be executed in the system.

As far as the IDE is concerned, the security code is treated as a blob of data, so it is never involved in the compile process, and it should cause no issues at that point. He also said that the code should never cause any operational issues that would require working through the auto-generated code. ‘Correct by construction,” I guess you’d call it. Specifically, there should not be instances where the SREC code needs to be accessed by a debugger.

Embedded Trust and C-Trust don’t necessarily cover everything you need to ensure a secure device – like making sure code doesn’t open back doors – but it could be a decent step in making security easier to implement in a consistent, robust fashion.

 

More info:

Secure Thingz

Sourcing credit:

Haydn Povey, Founder and CEO, Secure Thingz

One thought on “Automatic Security Policy Implementation”

Leave a Reply

featured blogs
May 26, 2022
Introducing Synopsys Learning Center, an online, on-demand library of self-paced training modules, webinars, and labs designed for both new & experienced users. The post New Synopsys Learning Center Makes Training Easier and More Accessible appeared first on From Silico...
May 26, 2022
CadenceLIVE Silicon Valley is back as an in-person event for 2022, in the Santa Clara Convention Center as usual. The event will take place on Wednesday, June 8 and Thursday, June 9. Vaccination You... ...
May 25, 2022
There are so many cool STEM (science, technology, engineering, and math) toys available these days, and I want them all!...
May 24, 2022
By Neel Natekar Radio frequency (RF) circuitry is an essential component of many of the critical applications we now rely… ...

featured video

EdgeQ Creates Big Connections with a Small Chip

Sponsored by Cadence Design Systems

Find out how EdgeQ delivered the world’s first 5G base station on a chip using Cadence’s logic simulation, digital implementation, timing and power signoff, synthesis, and physical verification signoff tools.

Click here for more information

featured paper

Intel Agilex FPGAs Deliver Game-Changing Flexibility & Agility for the Data-Centric World

Sponsored by Intel

The new Intel® Agilex™ FPGA is more than the latest programmable logic offering—it brings together revolutionary innovation in multiple areas of Intel technology leadership to create new opportunities to derive value and meaning from this transformation from edge to data center. Want to know more? Start with this white paper.

Click to read more

featured chalk talk

Simplifying Brushless Motor Controls with Toshiba Motor Control Solutions

Sponsored by Mouser Electronics and Toshiba

Making sure your motor control design is efficient and ready for primetime can be a complicated process. In this episode of Chalk Talk, Amelia Dalton chats with Alan Li from Toshiba about the basics of brushless motor control, more advanced variables including lead angle control and intelligent phase control and most importantly, how you can simplify your next brushless motor control design.

Click here for more information about Toshiba Brushless Motor Driver ICs