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
Jan 22, 2021
Amidst an ongoing worldwide pandemic, Samtec continues to connect with our communities. As a digital technology company, we understand the challenges and how uncertain times have been for everyone. In early 2020, Samtec Cares suspended its normal grant cycle and concentrated ...
Jan 22, 2021
I was recently introduced to the concept of a tray that quickly and easily attaches to your car'€™s steering wheel (not while you are driving, of course). What a good idea!...
Jan 22, 2021
This is my second post about this year's CES. The first was Consumer Electronics Show 2021: GM, Intel . AMD The second day of CES opened with Lisa Su, AMD's CEO, presenting. AMD announced new... [[ Click on the title to access the full blog on the Cadence Community...
Jan 20, 2021
Explore how EDA tools & proven IP accelerate the automotive design process and ensure compliance with Automotive Safety Integrity Levels & ISO requirements. The post How EDA Tools and IP Support Automotive Functional Safety Compliance appeared first on From Silicon...

featured paper

Speeding Up Large-Scale EM Simulation of ICs Without Compromising Accuracy

Sponsored by Cadence Design Systems

With growing on-chip RF content, electromagnetic (EM) simulation of passives is critical — from selecting the right RF design candidates to detecting parasitic coupling. Being on-chip, accurate EM analysis requires a tie in to the process technology with process design kits (PDKs) and foundry-certified EM simulation technology. Anything short of that could compromise the RFIC’s functionality. Learn how to get the highest-in-class accuracy and 10X faster analysis.

Click here to download the whitepaper

Featured Chalk Talk

0 to 112 (Gbps PAM4) in 5 Seconds

Sponsored by Samtec

With serial connections hitting 112Gbps, we can’t mess around with our interconnect. We need engineered solutions that will keep those eyes open and deliver the signal integrity we need in our high-speed designs. In this episode of Chalk Talk, Amelia Dalton talks with Matt Burns of Samtec about the interconnect options for speeds up to 112Gbs, and Samtec’s Flyover interconnect technology.

Click here to download the Silicon-to-Silicon Solutions Guide