You’ve spent months or even years creating IP that belongs to your company and/or its customers. In many cases, that IP is what makes you stand out from your competitors. The last thing you need is for some hacker to come along and grab that code and use it for their own good. Or worse, they alter the code within that running system, potentially crashing the system or putting people in harm’s way or jeopardizing your brand.

Register for Webinar Series Here 

The bottom here is that you have to design your code such that it’s secure. And that means designing it to be secure from Day 1, not after it’s been written, compiled, debugged, etc. To do this requires a slight altering of the code-writing process, adding security to the developer’s DNA. In other words, keeping code secure needs to be part of the process and not something to be thought about later. And just as important, it has to be easy for the developer or it won’t happen.

What makes this process even more difficult is that code within an embedded system, especially one that’s aimed at the IoT, never seems to be finished. In that, pieces are continually being added, and each additional is another potential door through which a hacker can gain access. In other words, you can have the strongest possible door on your house, but if you forget to lock that door, the hacker gets easy entry.

To get to that point, the security process must be inherent in the developer’s toolset. In theory, it shouldn’t come from a separate security tool. It should be part of the tool that’s already in the developer’s arsenal. In other words, when I wrote code, the security features should be included without me saying “what do I need to add here to make sure this is secure?”

Integrated Tools, Not Add-Ins

One tool that offers such integration is IAR Systems’ C-Trust. But, as detailed above, it does not work independently as a bolt-on tool. It works cohesively with the company’s IAR Embedded Workbench product—the company calls it an “extension.” And IAR Embedded Workbench is likely already in the arsenal of seasoned developers. IAR Systems claims to have a 50% market share amongst embedded developers.

When you start your project, you enable the security setting, which adds the encryption keys and denies version rollbacks. The image that’s generated is encrypted, and that’s the majority of what the developer needs to do.

The alternative to a tool like C-Trust would be collecting bits of information from various tools/companies, develop the security features internally, or employ an open-source solution. With any of these options, the developer has to figure out how to assemble all those disparate parts. And this would need to be recreated each time a new project commences.

While we’re just scratching the surface here, lots more detail can be seen in a webinar (part two of five) hosted by IAR System’s Rafael Taubinger, the company’s global FAE manager. Titled Protect the IP in Your Embedded System, the webinar will walk you through IAR Systems’ C-Trust security tool, allaying the fears of developers who don’t have security in their DNA. When they learn that the process really doesn’t add any pain, they’ll become converts.

Submit your questions prior to each webinar here.