White Paper

Whitepaper: Building Safe and Secure Systems for Autonomous Platforms

Issue link: https://read.uberflip.com/i/1427516

Contents of this Issue

Navigation

Page 4 of 7

WHITE PAPER Building Safe and Secure Processing Systems for Future Autonomous Platforms mrcy.com 5 5 Protecting data with encryption Data stored on system devices must be protected from theft and unauthorized changes. The most common tool for protecting data from theft is encryption. Cryptography does not wholly solve data-protection problems, although it does make them more manageable. Encryption requires a key that must be kept private, but how does a system protect the key, which is a form of data? Key management is one of the toughest challenges to achieving strong security. To be effective, key management and cryptography, in general, are typically rooted in secure storage. Note that secure storage does not necessarily mean physical security. It may be sufficient to isolate the secure storage from what an adversary can access or influence, perhaps by using an out-of-band key distribution network or a low- level hardware feature like a trusted platform module. INTEL BOOT GUARD AND MERCURY ROOT OF TRUST Intel's Boot Guard technology determines whether the firmware booting the platform can be trusted or was inappropriately modified. With Intel Boot Guard, the OEM creates a digital signature for the firmware that must be validated before the boot sequence can be completed. Mercury 's OpenVPX subsystems and servers with BuiltSECURE™ feature a hardware-based root of trust and cyber-resilient BIOS that mitigates multiple security threats to the application by minimizing boot devices. A second tool is a tamper-resistant physical enclosure, as defined by the FIPS-140 standard, that can prevent physical attacks that might otherwise circumvent secure boot features. Finally, physical security can be increased at the board circuitry level to detect and respond to tampering attempts. Although, as discussed later, this type of "detect and react " paradigm is an area where respective theories of security and safety can come into conflict, in part because an adversary can develop countermeasures against defenses using disclosed technology information. FIPS 140 Federal Information Processing Standard (FIPS) 140-2 is a U.S. government standard for approved hardware, software and firmware cryptographic modules. The standard comprises four levels (1–4) and specifies the security requirements that must be satisfied at each level. Level 4 provides the highest level of security-defining requirements for modules used in physically unprotected environments. Mercur y 's ADTS Advanced Data Transfer System features tamper- resistant technologies plus FIPS 140-2 and advanced encr yption options to protect data in case of loss or compromise. Systems security engineering and firmware protection with secure boot While many commercial products offer security features, they typically address cybersecurity objectives and rely on the "guns, gates and guards" approach to provide physical security. But, protecting a deployed embedded or edge system from attacks requires multiple layers of physical security, and SSE and should include the following, at a minimum. Protecting firmware from tampering helps prevent a cyber adversary from gaining a persistent foothold in the system or intentionally misconfiguring security features. One essential tampering protection tool is a secure boot, often implemented via hardware-rooted cryptographic signature to validate all software and data used during the boot process.

Articles in this issue

Links on this page

view archives of White Paper - Whitepaper: Building Safe and Secure Systems for Autonomous Platforms