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
Nov 24, 2021
The need for automatic mesh generation has never been clearer. The CFD Vision 2030 Study called most applied CFD 'onerous' and cited meshing's inability to generate complex meshes on the first... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Nov 24, 2021
I just saw an amazing video showing Mick Jagger and the Rolling Stones from 2021 mixed with Spot robot dogs from Boston Dynamics....
Nov 23, 2021
We explain clock domain crossing & common challenges faced during the ASIC design flow as chip designers scale up CDC verification for multi-billion-gate ASICs. The post Integration Challenges for Multi-Billion-Gate ASICs: Part 1 – Clock Domain Crossing appeared f...
Nov 8, 2021
Intel® FPGA Technology Day (IFTD) is a free four-day event that will be hosted virtually across the globe in North America, China, Japan, EMEA, and Asia Pacific from December 6-9, 2021. The theme of IFTD 2021 is 'Accelerating a Smart and Connected World.' This virtual event ...

featured video

See 400 GbE Running on a Speedster®7t FPGA from Achronix

Sponsored by Achronix

400GbE is required for next-generation, high-performance networking applications. In this video, Achronix demonstrates 400GbE connectivity on a Speedster7t FPGA integrated into a VectorPath™ PCIe accelerator card. The demonstration shows 400GbE traffic generated within the FPGA and transmitted across the FPGA’s 2D network on chip or NoC to the Ethernet subsystem. The 400GbE traffic is then looped back and checked within the FPGA fabric to compare to the original data stream.

Contact Achronix for a Demonstration of Speedster7t FPGA

featured paper

3D-IC Design Challenges and Requirements

Sponsored by Cadence Design Systems

3D-ICs are expected to have a broad impact on networking, graphics, AI/ML, and high-performance computing. While there’s interest in 3D-ICs, it’s still in its early phases. Standard definitions are lacking, the supply chain ecosystem is in flux, and design, analysis, verification, and test challenges need to be resolved. Read this white paper to learn about 3D integration and packaging of multiple stacked dies, design challenges, ecosystem requirements, and needed solutions.

Click here to read more

featured chalk talk

Using Intel FPGA to Develop Video and Vision Solutions

Sponsored by Mouser Electronics and Intel

Today’s video applications require enormous amounts of compute performance on small power budgets. And, the wide variety of specifications, rates, and resolutions makes flexibility a key design requirement. In this episode of Chalk Talk, Amelia Dalton chats with Omi Oliyide of Intel about how Intel FPGAs are ideal to take on even the most challenging video and vision designs, and explain how you can get started with this exciting technology in your next project.

More information about Intel Arria® 10 GX FPGA Development Kit