Embedded Systems Design Europe - October 2007 - (Page 25)

Linux ing a MAC mechanism is one way to implement effective containment. One method to achieve a MAC is by implementing Role-Based Access Control (RBAC). NSA’s SELinux, among other features such as MLS (Multi Level Security), provides Linux with MAC through RBAC. SELinux wasn’t originally designed for the ARM architecture, or for embedded devices. However, there have been previous (and reasonably successful) attempts to port SELinux or parts of it into an ARM-based embedded device. By adding a MAC mechanism such as SELinux on top of Secure Boot, we can address one of its fundamental shortcomings—providing a level of protection at run time. Figure 3 shows this architecture, combining Secure Boot and MAC mechanisms. In this approach, not only have we accomplished augmenting the Secure Boot mechanism (by way of providing run-time containment), but we’ve also enabled a way to expose hardware-security capabilities such as the Trusted Platform Module (TPM) standard services to the applications and processes during the system run time. As a side-note, it’s important to mention that RBAC isn’t the only mechanism to implement MAC. Other implementations exist that might be suited for embedded devices: Tomoyo Linux and Novel’s AppArmor are examples of such solutions that implement a technology called Name-Based Access Control (NBAC). Linux Intrusion Detection System (LIDS) is another example. At the time of this writing, neither of these implementations have gained enough traction (by embedded-device manufacturers) to be the default MAC mechanism for such devices. This state, however, may change as the above-mentioned technologies mature. The embedded industry of late is focusing on adding more computing power to embedded devices. This means not only adding more processing capabilities to each core, but also increasing the number of cores. One advantage to using multiple cores is the 25 executable image prior to passing the control to it. Assuming the veriﬁcation mechanism is based on the digital signature of the image being veriﬁed, the reliability of this veriﬁcation is at best as good as the reliability of the protection mechanism provided in the device for the public key of the image signer. The most important assumption here is that the code that performs the integrity veriﬁcation process is itself trustworthy. To assert this assumption, the implementations typically put the public key material (as well as the veriﬁcation code) into non-writable areas of memory, which in turn are protected using some sort of hardware protection mechanism. Figure 2 shows a generic Secure Boot architecture. In this approach, the ﬁrst step after boot-up is to verify the integrity of the Secure Boot code itself using digital signature veriﬁcation. Next, the Secure Boot code performs integrity checking of basic security parameters (such as the signers’ public key), and then after that validation of system images (such as the entire kernel or individual system libraries) occurs, and ﬁnally the user-space application validation takes place. The integrity of each layer relies on the integrity of the layers underneath. At any point, if the veriﬁcation fails, the system can be put in a halt-state. This approach enables establishing the chain of trust by ensuring that the trust on each layer of the system is based on (and is only based on) the trust on the layer(s) underneath it, all the way down to the hardware security component, which serves as the “root of trust.” If veriﬁcation fails to succeed at any given stage, the system might be put in a suspended mode to block possible attacks. One must note, however, that this architecture, although ensuring the integrity of the operating environment when a “hard boot” occurs, doesn’t guarantee its integrity “during” the run time; that is, in case of any malicious modiﬁcation to the operating environment when running, this approach won’t detect it until the next hard boot occurs. The Buffer Overﬂow class of attacks is practically impossible to prevent in native environments with no type- and boundary-checking available at run time. Executing native code in operating environments like Linux makes it speciﬁcally susceptible to this category of attacks. This, therefore, makes exploiting a buffer overﬂow attack of particular interest to hackers; mounting it is considered a badge of honor! Effective Containment in this context, is therefore referred to as a class of techniques that “contain” (as opposed to “prevent”) such attacks for which there are no practical prevention mechanisms available. This could be achieved using various security technologies. Apply- www.embedded.com/europe | embedded systems design europe | OCTOBER 2007 022-023-024-025-026-027_ESDE.ind25 25 9/10/07 16:55:53 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - October 2007

Embedded Systems Design Europe - October 2007 Contents Linux Set to Dominate Torvalds Updates Linux Kernel ARM Establishes Smart Card Foundry Program Emerson Buys Motorola's Embedded Comms Group LynuxWroks and TTTech to Cooperate on Avionics MontaVista CEO Looks for Acquisitions in Europe Ready: Multiprocessing Technology Provides Opportunity Automotive to Drive MCU Market New Supporters Join COM Express Group Analyst Weighs TI Versus Xilinx Versus PicoChip Cover Feature: Embedded Systems Security Has Moved to the Forefront Trace Exposes the Toughest Real-Time Bugs Employ a Secure Flavor of Linux Use an MCU's Low-Power Modes in Foreground/Background Systems Transporting Video Over Wireless Networks New Products Advertising Contacts

Embedded Systems Design Europe - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.