Page 35

EETE JULAUG 2014

The good news for secure boot is that most general-purpose microprocessors have on-chip key storage for this root of trust approach without requiring any other specialized hardware. Secure boot by itself does not prevent malicious impersonation. For example, a smart meter can be ripped off of the telephone pole and replaced with a rogue smart meter that looks the same but covertly sends private energy accounting information to a malicious web site. Users and administrators may require assurance that a deployed product is actively running the known good TCB. When embedded systems are connected to management networks, remote attestation can be used to provide this important security function. A simple, hardwareindependent approach can be used for any computing system by establishing a mutually authenticated connection (e.g. via IKE/IPsec or TLS). As long as the device’s static private key and secure connection protocol software are included in the TCB validated during secure boot, the attester has assurance that the device is running known good firmware. An improvement to this approach, providing assurance that the device is running a specific set of trusted firmware components, is to have the client transmit the complete set of digital signatures Fig. 2: Hyperhooking. corresponding to the TCB chain to the attester that stores the known good set of signatures locally. Hyperhooking Secure boot and attestation do not protect against run-time subversion via some vulnerability – the genre used in the airliner hack. The software security industry is overflowing with snake oil solutions claiming to prevent such malware. But every day brings a zero-day, and rootkits remain commonplace. Computer security and operating system firms are slowly coming to the realization that modern sophisticated operating systems cannot be adequately protected from within, but rather require some out-of-band mechanism. Due to its increasing availability in chipsets from all major embedded microprocessor architectures, hardwarebased virtualization support is rapidly emerging as the mechanism of choice. Hardware virtualization hooks enable a piece of software to take over control of the computer during certain security-sensitive computing operations (e.g. operating system exceptions and interrupts, supervisor mode instructions, write accesses to sensitive memory locations, etc.). We introduce the term hyperhooking for this general security approach: the hardware virtualization hooks enable a trusted agent to look for malware by examining system state during these trapped operations – see figure 2. These are the same hardware hooks that commercial hypervisors use to provide virtual machine services. The enterprising reader will note that these same hardware virtualization hooks were used in the aforementioned hypervisor rootkit attacks; secure boot is required to ensure that only the trusted agent is installed and able to use these capabilities. And the trusted agent itself must be secure against attack. A commercial example of hyperhooking is McAfee’s Deep- SAFE technology (Intel VT hardware specific), although little is publicized about what DeepSAFE actually does. Another commercial example that uses Intel VT is Bromium’s vSentry, in which the hyperhook agent’s actions in response to hardware traps can be configured via policy. Both DeepSAFE and vSentry attempt to retrofit rootkit protection to sophisticated operating systems. But as has been proven with other OS-visors like SELinux, there simply is too much complexity in these operating systems to manage and control. The retrofit will only temporarily raise the bar for attackers. In 2009, an excellent research paper demonstrated how thousands of Linux control functions could be protected against manipulation using hyperhooking. Yet the researchers admit that the technique fails to address the independent problem of malware that manipulate dynamic data objects (vs. control flow) to achieve their purpose. Even the set of protected functions is not complete; a single vulnerable control point is sufficient to defeat the entire system. As the researchers state, “a fundamental limitation … is that hook access profiles are constructed on dynamic analysis and thus may be incomplete.” The researchers admit that determining the complete set of exploitable kernel hooks exploitable is an “interesting research problem” with no known solution. Hyperhosting Rather than use virtualization hardware hooks for operating system introspection, they can be used to remove and isolate critical capabilities of the operating system by moving them into separate virtual machines or processes. Regardless of what malware may be successfully installed in the operating system or its applications and services, the hyperhosted components remain unaffected. Hyperhosting scope can range from simple cryptographic functions, such as those commonly found in smart cards, to full-scale secondary operating system environments. The INTEGRITY Multivisor is an example of bare metal hypervisor that runs on ARM or Intel processors and provides hyperhosting capabilities. Unlike typical hypervisors, INTEGRITY Multivisor can hyperhost lightweight processes in addition to full virtual machines containing guest operating systems such as Linux. This architecture - see figure 3 - can be used for malware hyperhooking, network security, data encryption, Fig. 3: Hyperhosting security functionality. operating system root detection, system monitoring, etc. The hypervisor is built on top of separation kernel technology that has been certified to numerous security and safety certifications (including flight safety). www.electronics-eetimes.com Electronic Engineering Times Europe July/August 2014 35


EETE JULAUG 2014
To see the actual publication please follow the link above