Plugging Security Vulnerabilities in Servers and Data Center Architectures

Adding secure boot to virtually any system offers designers a new tool for thwarting would-be hackers.

Security has been a buzz word for several years across numerous applications. Not surprisingly, defense, military, and government systems were first to implement significant security countermeasures. Other markets such as communications, data center, and embedded applications have been inconsistent in implementing real security measures. Unfortunately for many companies, security is still a check list item and not a hard requirement in the initial architecture of the product. Understandably, companies which have had their brands significantly tarnished by hacks have become serious about implementing layers of security in their end products. With so much to lose in terms of dollars and stock valuation, the server and data center markets have become increasingly more serious about securing their systems, and the security steps being implemented in these applications can be used throughout many other markets.

In a server or data center architecture, the heart of the system is a high-performance processor doing the heavy lifting for calculating and transporting data. In the vast majority of the cases, an Intel-based processor is being used, with significant effort spent on ensuring the processor is secure. This article is not focused on this area because numerous solutions to address the vulnerabilities already exist. What is often overlooked and underappreciated are the other processors in a system.

For example, a server’s bus management controller (BMC) poses a backdoor security vulnerability. If a hacker were to obtain access to a BMC, he could have direct access to the motherboard of the host system. Such access often means the ability to reboot and reinstall the host server. And many times these interfaces provide interactive keyboard, video, and mouse (KVM) support for virtual media access. Even worse, if the BMC allows root access, the hacker could control the I2C and other control buses on the host system.

Many architectures today have multiple processors. The main processor is frequently fortified, while the other control/monitor or bus processors are an afterthought. Another common error occurs when designers expect the software team to implement the security required and also believe that no hardware security is necessary. These preconceptions usually result in a system which is vulnerable to many different types of attacks.

Figure 1: SAS expander block diagram


Secure Boot Vulnerability
In the system shown in Figure 1, an SAS expander blade provides access to the hard drives. If this blade were hacked the data would be accessible and could be extracted. The Marvell SoC, which runs Linux and is responsible for the network management, does not have secure boot capability; it simply boots from external SPI flash. Secure boot security is designed to protect a system against malicious code being loaded and executed early in the boot process—before the operating system has been loaded. This approach aims to prevent malicious software from installing malware or a root kit and maintaining control over a system to hide its presence.

If a hacker were to obtain physical access to the system or connect to the system via network probing using Intelligent Platform Management Interface (IPMI) commands, she could create a backdoor account with administrative privileges. Although there are software steps that can be taken such as requiring stronger passwords, filtering untrusted networks, and not allowing backdoor accounts, these types of software barriers are not adequate. What is required are layers of security achievable by both hardware and software implementations. Ensuring a processor boots securely is not an issue limited to servers and data center applications, and the techniques described next can be implemented for virtually any system.

Implementing secure boot for a system should encompass both physical and remote network attacks. Although some systems are physically protected, one should not assume a single layer of security is adequate. It was recently proven that keys can be extracted by inexpensive electromagnetic probes several meters away from a product by using differential power analysis (DPA). The multi-layer security suggested for securely booting a processor involves authenticity, integrity, and confidentiality. See Figure 2 for how the previous SAS expander board can be modified to implement secure boot.

Figure 2: SAS Expander with secure boot

What is most notable is how little affected the overall design is by the modification to implement secure boot. In fact,  only two hardware modifications to the system take place. One is the FPGA/CPLD being migrated to a low-density flash-based SmartFusion2 SoC FPGA, and the other is connecting the SPI flash to the SoC FPGA instead of directly to the Marvell SoC. In this implementation, there are minimal if any required software modifications for the Marvell SoC, as the SmartFusion2 is doing the majority of the authenticity, integrity, and confidentiality to ensure a secure boot of this design. The SmartFusion2 device is chosen because of five key reasons. It has on-chip secure flash to store keys and other data, and the device contains an Arm Cortex M3 to provide the needed flexibility. Also, various security protocols are built in, the devices are inexpensive and most importantly, the SmartFusion2 device is the only low-density SoC FPGA with built-in DPA countermeasures.

Implementing Secure Boot—Authenticity, Integrity and Confidentiality
The security layers to implement secure boot involve three steps—authenticity, integrity and confidentiality. Only after each step checks out does the system proceed to the next step. If all are checked, then and only then will the system boot. Authenticity is achieved by checking an RSA signature in the SPI flash. At power up, the SmartFusion2 will read a particular location, which is known only by the developer of the system, and this location in the SPI flash contains the signature. The manufacturer signs the RSA key based on their private key, and the SmartFusion2 contains the public key, enabling an RSA algorithm to ensure the signature checks out. If it does, then it would move on to the next step, which is integrity.

The integrity step involves the SmartFusion2 calculating a hash on the contents in the SPI flash. Hash algorithms are cryptographic functions performed on variable size data formats to create a fixed size value and are deterministic such that the same input data provides the same hash value. They are also quick to run. A small change on the input data results in a hash value that is uncorrelatable to the original. Finally, no two different data sets will output the same hash value. A common secure hash algorithm is SHA-256. During the integrity step, the SmartFusion2 would calculate a SHA-256 output and check that against a value stored in its on-chip flash. If the output matches what is stored, then the next step is allowed.

The confidentiality step is implemented by requiring the contents of the SPI flash to be encrypted. At power up, after the authenticity and the integrity check are completed, the SmartFusion2 decrypts the contents of the SPI flash before passing them on to the Marvell SoC. The decryption is done based on a key stored in the flash of the SmartFusion2. If the contents of the SPI flash were modified, then the key would not correctly decrypt the data, and the system would not be allowed to boot. Because we are leveraging an SoC FPGA, after each step a custom response can be implemented. For example, if any of the steps fail, designers can power down all the supplies or as each step passes, illuminate an LED or store the information to view during system maintenance. There are numerous other possible responses that can be implemented.

Secure boot will certainly be added in more embedded processors as next-generation architectures come to fruition. Until that time, this secure boot layer of security can be added to virtually any system, as most processors boot from SPI or other types of flash. It is exciting the know that this implementation causes minimal disruption of the system architecture. Given this fact and the major benefits it provides, designers should seriously consider implementing this type of security to their system and control processors.

Ted Marena is the director of FPGA/SOC marketing at Microsemi. He has over 20 years’ experience in FPGAs. Previously Marena has held roles in design engineering, technical sales/support, business development, product and strategic marketing. He was awarded Innovator of the Year in February 2014 when he worked for Lattice Semiconductor. Marena has defined, created and executed unique marketing platform solutions for vertical markets including consumer, wireless small cells, industrial, cameras, displays and automotive applications. Marena holds a Bachelor of Science in electrical engineering Magna Cum Laude from the University of Connecticut and a MBA from Bentley University’s Elkin B. McCallum Graduate School of Business.


Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google


Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.