Sensor Open Systems Architecture (SOSA), unmanned vehicles, and trusted computing

Story

March 08, 2022

Steve Edwards

Curtiss-Wright

Today, with the increasing use of unmanned platforms to host intelligence, surveillance, and reconnaissance [ISR] sensor applications, system integrators need to ensure that the sensor systems and the critical data they collect and store are protected from falling into the wrong hands. By their very nature, unmanned platforms – whether airborne, on land, or at sea – pose more complex problems for security. All systems, regardless if deployed on manned or unmanned platforms, are now required to adhere to the Department of Defense (DoD) mandate for a Modular Open Systems Approach (MOSA). The good news for unmanned ISR system designers is that The Open Group’s SOSA [Sensor Open System Architecture] Consortium recently released Technical Standard for SOSA Reference Architecture, Edition 1.0, which defines many aspects of trusted computing for sensor systems. The SOSA standard combines MOSA principles with security to enable the rapid and affordable deployment of secure sensor systems on unmanned platforms.

Within the Sensor Open System Architecture (SOSA) Technical Standard, all security requirements are open, independent of any particular vendor or implementation. The requirements are relatively high-level and meant to facilitate the understanding of what is needed, not meant as a “how-to” regarding implementation. They operate within the framework of the SOSA software and hardware components within the technical standards, so that they mesh with the other aspects of those standards. Efforts were focused on leveraging as much of the existing capability and existing standards as possible. For example, existing standardized security capabilities such as SYSLOG and TLS are used where applicable, rather than developing something unique for the SOSA Technical Standard. Leveraging existing capabilities, where possible, reduces cost and time to deployment.

Security within the SOSA Technical Standard is designed to be flexible: Every system is different and has different security requirements. The security capabilities in the SOSA Technical Standard can be thought of as a library of functions, to be used as needed to address security. This mindset enables each system to tailor security to address their requirements– as security – like the rest of the SOSA Technical Standard, is adaptable. As new threats emerge and certain mitigations become less secure over time, adjustments will have to be made, a reality that will be reflected in future versions of the standard.

SOSA Service View 1 (Figure 1) documents the SOSA modules and their top-level relationships to one another. Security components defined in SOSA Technical Standard 1.0 include 6.1 Security Services and 6.2 Security Encryptor/Decryptor. There is also a placeholder for 6.3 Guard/Cross-Domain Service, which will be addressed in a future version of the standard.

[Figure 1 | SOSA Service View 1 documents the SOSA modules and their top-level relationships.]

SOSA security services

SOSA Security Services contain a set of functions that provide a standardized way of ensuring the integrity of the system. It is a toolbox to be used to address the security requirements within a system.

For example, the SOSA Technical Standard includes functions that monitor and assess the integrity of the system throughout the operation of that system. At startup, the integrity of hardware and software is established, and continually monitored during operation so that changes are flagged and handled accordingly. When a system starts up, security evaluates the integrity of that system and determines it to be protected, degraded, or compromised. The integrity of the system is okay in a protection state. If there is an issue with integrity of some components, then the system is considered degraded or compromised depending on how severe the issues are. In this case, it is up to the system to determine what to do. It may continue to run in a less secure state, prohibit certain modules from running, or even shut down.

There may be security requirements outside of the standard that are not covered in the SOSA Technical Standard, and that is fine. In that case, the requirements are not implemented within the framework of the SOSA Technical Standard, but if SOSA does cover the mandated security components that are required, and the program will make use of them, then they must be implemented in accordance with the requirements specified in the technical standard. So, if your system is going to use TLS or SYSLOG, for example, they are covered by other standards, but if startup is going to be performed securely, the SOSA Technical Standard defines what is required for implementing it.

Security services in the SOSA Technical Standard 1.0

Secure startup: Monitor/assess the integrity of the system during initialization and continuing through operation.

Audit: Audit logging/processing of system events.

Authentication: Verifies that a module (generally – but not always – in SOSA, “module” refers to a software module) instance is intended to be used on the system.

Authorization: Grants access to privileged functions within the sensor.

Data at rest and data in transit (Data in motion): Ensures confidentiality, integrity, and availability of data stored within nonvolatile memory or transiting on a SOSA system.

Encryptor/decryptor: Provides cryptographic functions both for DAR for confidentiality, integrity, availability of system.

Intermodule interaction: For data in transit, provides confidentiality, integrity, and availability to data traversing between modules (leverages TLS/DTLS). At this time, only data traveling between modules within a specific system are covered by the SOSA Technical Standard.

Key management: Provides a mechanism for loading, storing, retrieving, and managing SOSA controlled keys within a system. SOSA key management doesn’t define how to control every one of the many keys in a system, many of which might be used outside of the SOSA key management. For example, it doesn’t define those keys used to start up an individual plug-in card, or keys used for TLS, which makes use of session keys. Those types of keys are created as needed and destroyed when the session ends. They are controlled within the TLS domain, for example, not by the SOSA key management.

Software package verification: Assists the runtime environment with verification of software packages to authenticate their use.

Zeroization: Provides a mechanism to remove/erase critical security parameters (CSPs) such as keys, passwords, and certificates.

System security life cycle

Holistic security is multidisciplinary and is needed throughout the system life cycle, which starts with design and runs through build, test, operate, and maintain before ending at retire. (This process might refer to the entire system life cycle.) Within the SOSA Technical Standard, for security the focus is on runtime, the operational and maintenance components of the system life cycle, which begins at startup and proceeds from runtime to shutdown and ends at the maintain phase.

Runtime security

Ensuring runtime security involves continual monitoring of security states. The startup states continue to work and monitor the system to understand any changes in status that might affect integrity. There is a standardized set of services that can be used to provide data integrity (for data at rest, data in transit, and key management), detection of anomalous behavior for things like SYSLOG, and – in the case that anomalous behavior is detected – being able to respond to it by zeroizing critical security parameters.

The SOSA Technical Standard does not currently contain any content that defines secure shutdown, but discussions are underway and it’s expected that the subject will be covered in future versions of the standard.

Interoperability

Interoperability enables disparate systems to exchange data and information and work together. It’s achieved at the interface between modules by having well-defined interactions and behaviors between modules. Within the SOSA Technical Standard there are different hardware modules – for example plug-in cards (PICs) and software modules – that may be created by different vendors.

It’s important to make sure that these various elements can work together correctly. In many cases, they will have security aspects and will need to be authenticated (and perhaps authorized to use privileged functions) and they will also need to be able to send data back and forth between the modules. There is an entire group within the SOSA Consortium, called Inter-Module Interaction, that works on defining those APIs [application programming interfaces] and what the parameters that get passed back and forth are, to ensure that at the interaction level (the API level), there is common set of functions and data that gets passed back and forth so that the modules can communicate. That also applies, off-sensor, to other systems on a platform going forward.

Within the SOSA Technical Standard, the Security Services group works with the Inter-Module Interaction and Data Modeling groups to make sure that the parameters needed to ensure security are defined so that modules making use of security services can do so in a standardized way, and can interoperate with those security services and with each other.

Security and plug-in cards

Generally speaking, the internals of the various PICs and how they deal with security is the purview of the vendor, which means that the security requirements of the SOSA Technical Standard apply at the interface of the PIC. For example, SOSA does not directly impose internal requirements on how a particular PIC will boot securely. However, security requirements do apply to modules that will run on the PIC, and certain functions, such as secure startup, will want to know the integrity of the PIC. Functions will want to know how to verify that the PIC is who it says it is and will want to know what information the PIC will provide to inform that it has started up in a known secure state. That means there will need to be information passed back and forth.

Modules running on the PIC can use security services for the various security-related functions, and then communicate between where those security services are located (on a PIC in the system, most likely). The ability to communicate must be provided, typically via Ethernet, so that security services can gain the information needed to run and perform its functions.

To make the implementation of security on a PIC easier, the system designer can use a trusted platform module (TPM, an international standard for a secure cryptoprocessor), FPGA [field-programmable gate array], and root of trust. TPMs are used for encryption, storing certificates, and hardware attestation support, all of which are useful from a security context in the SOSA Technical Standard. For Intel-based PICs, having a TPM onboard is now standard practice. TPMs can be implemented as dedicated pieces of hardware. If an FPGA is available on the PIC, there are software TPMs that can be used. Hardware cryptography can also be used within the FPGA to handle some of the TPM functions. Root of trust, which is a generally trusted entity on the PIC, can be implemented in hardware, which is more secure, or in some cases can be implemented in software. Root of trust is discussed within the current SOSA Technical Standard but is not yet defined.

SOSA Security Services does not address every cryptographic key, password, or certificate in the system. Also, the internal bring-up and integrity of a PIC is not covered by security services today. At the system-to-system level, SOSA Security Services does not currently address security between SOSA systems on a platform, or between a SOSA and a non-SOSA system. SOSA does contain the concept of a “host platform interface,” which is likely to be used in the future for defining secure intersystem communications.

Steve Edwards is Director of Secure Embedded Solutions for Curtiss-Wright. He has been with Curtiss-Wright for more than 22 years in a number of roles. Steve co-designed Curtiss-Wright’s first rugged multiprocessor and FPGA products and was involved in the evangelization of the industry’s first VPX products. He was Chair of OpenVPX (VITA 65) from 2013 to 15 and is currently a contributor to the Sensor Open Systems Architecture (SOSA) Security Subcommittee. He has been leading Curtiss-Wright’s AT and cybersecurity efforts since 2010. Readers may reach him at [email protected].

Curtiss-Wright Defense Solutions • https://www.curtisswrightds.com/