The process of developing, certifying, and implementing embedded security features has several problems that can be compared to providing deadbolts for residential properties. The deadbolt itself, no matter how well designed and tested, offers little security if it is not installed correctly. What’s more, the deadbolt is of no use if the owner does not lock it into place at night.

These problems likewise apply to chip security features. If implemented incorrectly by the system developer or not utilized at all, a processor’s security properties are of no value in the end system.

Where’s the security?

Embedded security features typically come to the marketplace as hardware or software solutions, though of course all security capabilities have aspects of both.

A good example of software security features includes a set of crypto libraries and reference codes used to protect data. The hard problems of creating encryption subroutines that are security certified, lack known coding vulnerabilities, and resist side-channel examinations are often undertaken by companies with security specialties and licensed to embedded developers. An example of hardware security features includes hard memory partitioning and hard trust modes and circuits invoked for sensitive operations. In both hardware and software cases, using the feature in a normal embedded development requires a configuration and software implementation step.

The implementation of security capabilities through vendor software tools is usually not a simple process. It is a product of the embedded development environment and must be performed in a way that is reliable, testable, and verifiable. Often it is integrated into the software development environment and provided to the developer bundled in the normal development suite.

Embedded development environment elements

The most common success metrics of an embedded development environment are productivity and ease of use. With high-security products and projects that fully utilize security features available on the market, however, an additional primary objective is to provide a trusted development environment.

This represents a high degree of either third-party certification of the software elements’ integrity or extensive documentation and interoperability testing of the embedded security configuration software and other development tools. Interface bugs that affect security configurations can have severe long-term consequences for development companies, not unlike liability in automotive and medical applications.

Implementing security configurations

Configuring security capabilities in an embedded system is done with a software development tool appended to the customer’s software development kit. Some examples include setting up bitstream encryption keys for an FPGA, fuse settings or hashing keys for a digital signature-checking circuit, and code obfuscation tools.

Though there are some exceptions, few vendors implement a digital signature or trust check on their own security configuration tools. This leaves the entire development environment vulnerable to code tampering, both intentional and unintentional.

A valuable approach to creating a secure design environment is performing security configuration and code checking on an entirely different hardware and network platform from the user development environment. In this way, the embedded user does not take on the burden of developing a security-pristine work environment, but instead isolates security concerns to a narrower range of the development schedule and tool flow.

Adding a secure configuration step

The goal of creating a secure configuration step is to segment security configuration as a separate step in the design process. If an embedded provider is developing an entirely new development environment, this becomes a value-add feature in early requirements. If this is being attempted with an existing or legacy design environment, the process might be more difficult.

An example of this process is the Acalis Sentry device, which is used to configure the security parameters of the Acalis secure processor. The processor’s security configuration resides in a uniquely encrypted and signed boot file, and the Acalis Sentry performs the step of creating a final encrypted boot file for the device.

A separate hardware appliance like Sentry can be used for a variety of other security configuration tasks as well. These include linking sensitive libraries, installing keys in final user configuration (in a similar fashion to military encryption equipment), or checking digital signatures and software licenses. Figure 1 shows how this security separation is implemented in an embedded development environment.

(click graphic to zoom by 1.9x)

Another example of security separation is the process of separating data flows in FPGA designs. Both Xilinx and Altera offer the capability to partition data flow designs into separation regions. Each company also provides an independent verification tool to perform rule checking and layout management to ensure the design is partitioned correctly. In this manner, FPGA users who are designing for high-assurance systems can perform the most important step – verification – in a completely separated design environment if so desired.

Embedded security verification

Verifying security configuration settings differs greatly from embedded code testing. Testing refers to checking application code for operation to functional and performance requirements. Verification is the operation of this tested application code to ensure that the proper security safeguards are in place to prevent unauthorized access or tampering.

Performing write and read-back testing in security configurations is only as secure as the configuration tools and the communication channel used for testing. For this reason, three attributes of security verification testing are practiced widely in government security and are now lexicon steps in verifying embedded system code security. These attributes include authentication, command integrity, and audit logs.

User authentication

User authentication can be built into the security configuration tool (user name and password unique to the security verifier) or designed into the hardware host for security setting and verification software. The capability to match the verification module and the silicon device or software module being verified should also be provided.

Command integrity

Command integrity is a property of security command procedures that redundantly checks and rechecks or utilizes several command pathways to implement security configuration commands. This is similar to storage data integrity requirements that rely on forward error correction, redundant coded and fragmented data copies, and interdependence rules in logic that prohibit certain combinations of states.

Audit logs

Audit logs include a process of recording and securing the records of all transactions taking place from one logical module to another. It provides the benefit of a tracking mechanism for debugging and forensics, as well as vastly complicating the tampering process by creating and protecting an auditable trail of activity.

Secure features need secure processes

A great deal of publicity in 2011 has focused on how complex and integrated supply chains have become for large companies. The maze of suppliers contributing to an embedded system includes silicon designers, manufacturers, Real-Time Operating System (RTOS) providers, IP providers, design tools, debug/check tools, and so on. The complexity of this supplier picture presents issues for business risk and product security and integrity.

Providing guarantees regarding the security and integrity of each of these elements is an unsolvable problem as the issue of embedded security rises in the minds of customers and users. The smart way to address these customer concerns is to enable a secure process for verifying security features.

An important part of this approach is to isolate the process of implementing and verifying security configurations from the rest of the development process and environment. This will more than likely lead to the appointment of security specialists in an embedded organization and the rise of embedded security engineering as a best practice in product development. This could also result in development environments providing tools and capabilities targeted at supporting this emerging role. Given our society’s growing dependence on embedded technology, it’s safe to say this is a good thing.

With tools, training, and best practices, embedded systems designers will now be able to lock and secure the deadbolt in place on the front door. Then we can start to focus on all the unlocked windows elsewhere in the system.

J. Ryan Kenny is an electronic security consultant at QuantumTrace. He has more than 10 years of experience in space and defense electronics in the U.S. Air Force and defense systems engineering. He graduated from the U.S. Air Force Academy and completed an MSEE and MBA from California State University and Santa Clara University, respectively.

QuantumTrace jamesryankenny@msn.com www.quantumtrace.com