Trusted Computing Series Developing a Secure COTS-based Trusted Computing System

The designer must look at each system element and understand how they work together. If a single discrete element of the system is insecure, it is not possible for the designer to claim confidently that the entire system is secure. You need to know how each system element integrates with the rest, what interfaces are available to those elements, and how each element communicates with the other parts of the system.

Frequently, designers can meet system-level security requirements in several different ways. For example, to resist a particular malicious attack targeting one weak hardware component, the designer could use either a more resistant component or implement a distributed system approach, presenting the attacker with the far more difficult task of targeting multiple components at the same time.


What’s more, the ways in which the system uses those interfaces, whether during operation or in maintenance activities, may raise additional considerations. The designer must perform an appropriate level of validation or authentication of data prior to its acceptance for processing at each different levels of integration. That means the designer must make choices about what sort of access control or authentication capability is necessary at the I/O boundary.

In an ideal world, one trusted and capable vendor would handle all components to optimize security. Yet security challenges often stem from using modules from different suppliers. Frequently, the system integrator must deal with multiple COTS vendors, but not every COTS vendor can support the same levels of trusted computing capabilities, so the designer also must weigh supply chain management issues and their COTS vendor’s ability to meet the system’s needs.

The impact of trusted computing on performance will vary from system to system, and may require tradeoffs between security and performance. Size, weight, and power (SWaP) limitations also can play a part in weighing tradeoffs. For new “bleeding edge” system designs the tradeoff might be between implementing security (and/or other overhead) and meeting the mission requirements.

Testing for system-level security brings its own set of challenges. For some security implementations, the designer might need to classify pieces of a system, and test them in a classified laboratory. Afterward, when security is enabled, the system can be tested in an unclassified environment where the sensitive component can be integrated with additional elements of the system. The challenge is how to undertake the integration of classified and unclassified components in a way that’s cost-effective and ensures the ability to perform debugging in each set of environments effectively.

Prior to a system’s deployment, the designer must decide how to manage security certificates and keys. The key management plan must be fully vetted, and include the ability to revoke keys to reduce the program’s long-term maintenance costs. These decisions should be made early in the program, since the choices will affect how they are designed into the system.

It’s always easier to make decisions about trusted computing protections at the very beginning of system development; there is great value in discussing anti-tamper and cyber security at the earliest stages of system design. Security touches every element of the system. To add in needed “hooks” after a module or system is already designed often requires undoing a lot of previously undertaken and costly design work.