Improving Embedded Security: Proper Runtime Selection

By Bill Graham

Bill GrahamSelection of secure components for an embedded system is key to a secure system. Leveraging a secure RTOS, middleware, virtualization and tools significantly reduces the effort and development costs. Moreover, there are additional benefits from using commercial-off-the-shelf (COTS) software components over Roll Your Own (RYO) code or self-ported and maintained open source code. Some of the COTS components worth considering include:

Five_steps_blog_part3

  • Virtual System Simulation: System, board and processor level simulation accelerates software and hardware integration, ubiquitous platform availability (whereas reference hardware is a scarce resource) and enables sophisticated debugging and analysis techniques that hardware cannot provide. Wind River Simics provides virtual system simulation platform that provides a powerful development, test, debug and deployment platform ideal for secure development and test.
  • Hardware support layer (aka Board Support Package): Runtime platforms such as hypervisors and operating systems require low-level hardware support layers. Relying on commercial hardware support is a critical first step in leveraging off-the-shelf components. Commercial offerings are optimized for the target hardware, come with technical support and maintenance, and in some cases are certified to specific standards or regulations.
  • Embedded Virtualization (Hypervisor): To support sophisticated partitioning schemes, multi-OS, multicore and other architectures, embedded virtualization is the solution of choice.
  • Real-Time Operating System (RTOS): For many embedded systems, in particular ones that require small footprint, strict timing constraints, or safety certification, an RTOS is the operating system choice. In the past, security has not been a top consideration for RTOS, but this has obviously changed. Nowadays, an RTOS must be as secure as a General Purpose OS (GPOS). Things to consider in the selection of the RTOS include:
    • Secure networking – for example, does the network stack include a firewall?
    • Secure default configurations – is the RTOS available in a secure default configuration? For example, are non-essential services turned off and network ports blocked?
    • Certification – has the OS been tested to a security certification that’s applicable to your device?
    • Secure communications – does the OS support secure communications standards? For example, does the RTOS include encryption capabilities, secure sockets, VPN, IPsec, etc.?
    • Security response – does the vendor treat security issues with a high priority, is there a security response team and process in place?
  • Embedded General Purpose OS: Typically this is Linux or possibly Microsoft Windows. These GPOSes can be considered secure (e.g. Wind River Linux Secure) and provide their own security features. GPOSes can also be partitioned (as is done often with Windows) to allow for possibly non-secure execution separate and in isolation from the safety and functional critical part of the system.
  • Middleware: Depending on the definition, this layer can include basic and advanced networking, wireless support, communication security (IPsec, IKE, VPN support, etc.) plus many more diverse services such as audio, video, and graphics. Obviously, the selection here is particularly important for supporting network security via encryption libraries and communication protocols such as SSL and IPsec. Additionally, intrusion protection can be enhanced via firewall and use authorization support at this level. Certification of operating systems and middleware is possible — for example, Wurldtech’s Achilles Certification program for embedded systems.
  • Tools: Tools for testing and debugging support secure design techniques. Static analysis tools play a critical role in preventing insecure code from entering the project early on in the lifecycle. Test management and simulation tools greatly increase embedded development productivity.

Once a platform has been chosen that provides the right starting point for secure development, test, debug and deployment, the next step is to secure the applications that are built on top of this base. In the next post, I’ll discuss the steps needed to ensure only known and trusted applications run on your device.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>