Q: What challenges in security do engineers face when designing electronics for the military?
By Cary Eskow, vice president, Avnet Lightspeed
Just a few weeks ago, the U.S. Government Accountability Office published its report, “Weapon Systems Cybersecurity” to the Senate Committee on Armed Services. They identified cybersecurity threats in a wide range of weapon systems deployed on aircraft, ships, and, also, secure communications systems. The findings served, in part, as a “wake-up call” to the Department of Defense (DoD) and all contractors, system architects, engineers, and supply chain partners in the defense industry.
In the past, the DoD focused on the cybersecurity of its networks—not on the vulnerabilities of the weapon systems themselves. This is a critical distinction, especially as our newer and increasingly sophisticated weapons are integrated into vast C3 systems, potentially exposing cyberattack surfaces far beyond the compromised weapons themselves. In this scenario, an individual “connected” weapon’s cyber vulnerabilities could provide a back door to DoD’s mission planning, combat direction, tactical systems, strategic databases, real-time targeting, warning systems, and other weapons—conceivably, nearly everything in the arsenal.
If that’s not sobering enough, consider two other factors. In the past, “air-gapped” architectures (systems that do not directly connect to the internet or to each other) reduced vulnerability to an extent by limiting electrical/data/communications access. However, as these systems have evolved in complexity and firmware, they often have onboard diagnostics ports, USB ports, RF links, etc. Air gaps are not enough. The second factor is supply chain security. Many years ago when I entered the industry, a “counterfeit” IC was typically a low-quality functionally-equivalent device, or one that was stale-dated and re-marked. Today, however, sophisticated and state-sponsored cyber combatants can produce ICs such as microcontrollers that are functionally-equivalent under normal operating conditions, yet include added covert circuitry, which enables remote access and control when remotely triggered. Once they enter the supply chain, the attack comes from within. So, along with the warfighting benefits of tightly integrated weapons systems, comes a nearly exponentially increased requirement to secure weapons inside, outside, and even at the component procurement stage.
By Steve Travis, technical and commercial advisor, Chassis Plans
With heightened requirements for military computer and network security, there is an increased need for rugged computer systems that meet FIPS 140-2 certification requirements.
The National Institute of Standards and Technology (NIST) released the FIPS 140 series and its four levels of security to standardize the requirements for cryptography modules. These requirements were designed to protect cryptographic modules within a secured system to maintain the confidentiality and integrity of the systems data.
Listed below is a basic overview of each security level:
- FIPS 140-2 Level 1: Only the software is required to be validated. Utilizing application such as Bitlocker (under an approved version of Windows operating in FIPS mode) is sufficient for certification.
- FIPS 140-2 Level 2: Software applications must run on an operating system approved to Common Criteria at Evaluation Assurance Level 2 (EAL2). System components such as Intel CPUs using vPro technology, Trusted Platform Modules (TPM), and encrypted hard drives, are used computer into security compliance. The system enclosure itself must be tamper-resistant, preventing unauthorized access to internal system components.
- FIPS 140-2 Level 3: Requires physical or logical division between the interfaces that “critical security parameters” enter and exit the module. The system enclosure is further enhanced to prevent any tampering and additionally requires the cryptographic module to be rendered inoperable if tampering has occurred.
- FIPS 140-2 Level 4: Unique internal components are required due to the advanced encryption levels required as well as additional environmental considerations. The system must be designed to be tamper-active, erasing the contents of the device if it detects various forms of environmental attacks, such as in high temperatures and voltages that might be used to exploit the crypto module.
Of course, when designing a secure system, a large part of the final certification process revolves around the additional hardware and/or software the customer requires for their individual solution.
By John Rodwig, director, Program Management, IEE
The defense supply chain has become much more global and complex over the decades. This makes the chain of custody, or design provenance, more difficult to determine, and increases the risk of deploying counterfeit or malicious components. Security must be designed in the same way as maintenance, electromagnetic compatibility, manufacture, etc. Engineers have to understand the critical need for, and participate in, security processes that are executed at the individual designer level and above.
Hardware engineers should identify and track every logic-bearing component, and work with procurement to select components that have Defense Microelectronics Activity (DMEA) Trusted Foundry and Trusted Supplier Status. Additional test points may be needed to facilitate connection of third-party analyzers for independent verification activities such as tracing management port messages from logic-bearing components. All configuration data and status must be accounted for in complex devices.
Software and firmware engineers may have fewer choices for development tools, and must work within a more stringent development atmosphere, with increased access control, closed networks, frequent computer scans, and increased scrutiny of utility and test code. The means of delivery of software and firmware must be protected from interception and require more effort than just electronic or physical mail. Engineers should subscribe to, receive, review, and act on vulnerability alerts, and be familiar with the common vulnerability and exposures process. Architecture and peer reviews will have an increasing security component, and source code will be subjected to computer analysis for common weaknesses. Additional software and firmware design should be considered to detect and isolate the effects of a failure and provide persistent log data for post event analysis.
By Jim McElroy, VP marketing, LDRA
There are many security challenges and considerations when designing military electronics. Fundamentally, standalone systems are now, for the most part, a thing of the past. Therefore systems must be designed to collaborate with other systems safely and securely. That means that when designing such systems, software and hardware engineers must work to prevent bad actors, untrusted data, or counterfeit and ill-intentioned parts from entering the collaborative system during design time and runtime, including during all maintenance activities.
On the hardware side of things, securing and authenticating the supply chain is critical. That is a major topic all on its own. Speaking from the software perspective, security must be planned from the ground up. Software must be designed, analyzed, and tested in order to prevent vulnerabilities from entering the source code at any phase of development. Software design must include operational authentication of the actors and the data in the system to ensure the system can communicate with trusted actors and operate with trusted data. Furthermore, as additional protection, the platform on which the software runs needs to be considered for security purposes. The processor and operating system must be capable of supporting safe and secure functions, even while under attack. This may warrant quarantining any elements of operation, i.e. software, data, and devices that may have been compromised. These are just some of the many challenges that engineers need to consider when designing security into military systems of today.
By Scott Phillips, vice president of marketing, Virtium Solid State Storage and Memory
There are two things you’re unlikely to ever see: a unicorn, and a military-electronics designer shopping at the local electronics retailer. When it comes to security, military systems are held to significantly higher standards; off-the-shelf hardware and basic password protection just don’t cut it when it comes to securing crucial military data.
From a data-authentication perspective, designers have multiple options, ranging from a relatively simple password protection based on the tried-and-true ATA storage interface to data-securing write-protection method to more sophisticated pre-boot scheme, such as that supported by the Trusted Computing Group standard.
When it comes to data-security, there are many encryption methodologies, including RSA, 3DES, and the self-encrypting drive, or SED, methodology popular with industrial-grade solid-state drives, commonly called SSDs. An SED doesn’t require software or host-based key generation and exchange but rather encrypts SSD data on the fly with sophisticated encryption ciphers. Based on the Advanced Encryption Standard, AES-256 is arguably the most powerful cipher. Its 256-bit key size provides an astounding 1.1 x 1077 number of possible combinations, rendering unauthorized data access virtually impossible.
From a data-elimination standpoint, several methodologies exist, from the fairly simple—though sometimes time-consuming—ATA-based secure-erase mechanism to various implementations of what’s called purge, such as rapid purge; purge levels 1, 2, and 3; and destructive purge. A relatively recent—and more thorough—option for making a drive unusable is called crypto-erase that essentially destroys a drive’s crypto-keys, rendering it unusable. This option can be automatically initiated through hardware or software that destroys AES encryption keys in milliseconds. This approach secures SSDs much faster than standard secure-erase methods and at much lower power. To strengthen security further, the crypto-erase command can be followed by an uninterruptible secure-erase command.