Related Articles
Designers have been worrying about security since well before the first PC or cell phone hit the market. Unfortunately, they sometimes were the only people thinking about it because security hasn’t always been on the feature checklist.
The lack of security made it easier to develop software and build networks. It also eliminated a lot of headaches and overhead. Of course, the downside is that a malicious or poorly written application can cause havoc within a system. The Internet is to blame, because it effectively provides a worldwide network in which computer viruses and worms can play.
It could be much worse because there are varying levels of security within the Internet and connected networks. Firewalls, encrypted traffic, passwords, and authentication requirements are just a few aspects of security used with varying degrees of effectiveness, but the threat of computer attacks remains.
This file type includes high resolution graphics and schematics.
Table of Contents
- Start With Secure Boot
- Securing Systems With SE Android
- Separation Kernels and Virtual Machines
- Program WhiteListing
- Embedded Firewalls
- Updates or the lack thereof
- Wireless And Network Security
- DRM Is Not About Security
- Securing The Keys
Start With Secure Boot
Users typically think about security from their perspective, such as when they’re using a smart phone or tablet. The problem is that by the time a system is up and running, security is a lost cause. Security should start when a system is booting. Even a lowly microcontroller has to start somewhere. The very first instruction can modify how the rest of the system comes up:
- With a BIOS-based PC, the processor starts running code in a flash-based memory. If the flash memory is corrupt, the system crashes.
- Next, a sector is loaded from a storage device into memory and then executed. If the sector is corrupt, the system crashes.
- A file, usually the core operating system (OS), is then loaded from a storage device into memory and executed. If the file is corrupt, the system crashes.
- Finally, files that make up the rest of the OS are loaded from a storage device for execution. If these files are corrupt, the system crashes.
Notice a pattern?
The system can crash when something is corrupt, but that isn’t the worst part of the scenario. The crashes usually happen because of bad update procedures or bad code, but they could also happen because of malicious attacks.
The boot procedures often check for hardware failures, but they typically don’t check for malicious attacks. Likewise, the ability to make changes to the various storage areas including flash memory and boot sectors wasn’t initially part of the support for BIOS-based PCs. This has been changing.
Restrictions on updating the flash BIOS and writing to boot records on storage devices are now common features that help secure a system, but they are still stopgap measures. Secure boot is the answer because it only lets the system run if the lowest level of software has been authenticated. The processor must support this feature, and a range of systems can provide this support.
The Unified Extensible Firmware Interface (UEFI) has replaced or coexists with the PC BIOS on most new x86 PCs and servers. The UEFI Secure Boot option forces the boot code to be signed. Any modification of the code will cause a mismatch with the associated digital signature. UEFI takes a modular approach to device support as well. Device support modules are also signed, and these signatures are checked when the system boots and the modules are used.
This illustrates how digital signatures and the boot process provide a secured environment. All of the used components must be authenticated. This can eventually extend to the applications as well. The main purpose of a secure boot is to make sure that what is running is what is intended. It also forces a particular piece of code to run. This isn’t an issue for an intelligent washing machine, but it may be for a PC or other user programmable device.
A Microsoft Windows 8 certified PC must implement the UEFI Secure Boot option. This means it will boot Windows 8, which is fine unless the user wants to boot another OS like Linux or Windows 7. Some secure boot-based systems can support multiple keys to address this situation. One key would be used for Windows 8 while another could be used for another OS.
UEFI has been deployed on x86 platforms, but it is applicable to other architectures like Arm. The application programming interfaces (APIs) and semantics are the same, although the code that would be employed would be specific to the host processor. UEFI also isn’t the only means to utilize secure boot support, but it is one of the more notable ways.
This secure boot approach does have potential downsides. In Microsoft’s case, the key that’s used to sign everything becomes a commodity that must be secured at all costs. Compromising the key would render all systems secured with it open to attack. This will be true for any system using this approach, but the number of Microsoft Windows 8 machines will probably be larger than all but a few consumer electronic products like smart phones.
Another issue can be long-term support. The key must be available to sign subsequent updates. That probably won’t be an issue for Microsoft, but it could be for other vendors and products that use the same approach.
Securing Systems With SE Android
Secure boot is designed to get an OS up and running, but its effective support ends there. The OS then must keep things secure. As noted, Windows 8 supports secure boot, and Windows 8 systems being sold are required to have UEFI Secure Boot support.
Windows 8 has a host of new security features, but antivirus is still high on any user’s feature list. This has to do more with its attack vectors and the way it gets used. Boot and OS security are just parts of the puzzle. On the other hand, it will be much harder to get a bootkit or rootkit virus into Windows 8 systems.
These days, Windows is only one of many OSs used in consumer and embedded platforms. Linux is one of the other major solutions, and it has its own security features and issues.
Initially developed by the U.S. National Security Agency (NSA), SE Linux is designed to give Linux more control over access rights compared to the standard Linux file modes. It adds fine-grained granularity to access controls including network resources and interprocess communication. SE Android, which is part of the Secure Enhanced Linux (SE Linux) project, builds on SE Linux and addresses the Android software stack.
The challenge with SE Android, SE Linux, Windows 8, and other advanced OSs is that the security configuration options are numerous and the security profiles employed can be quite complex. This provides flexibility to developers, but it also means that proper configuration and maintenance tends to require someone well versed in the intricacies of security management.
The problem at the user end occurs when the security configuration is too strict and frustrates the user operating the device or computer. PC and even tablet users may be able to bypass or modify their security configurations, though viruses then can bypass the security as well. Developers and network managers often have to balance security with sufficient user flexibility.
Separation Kernels and Virtual Machines
Virtualization can be used to balance security and flexibility. Virtual machines (VM) are isolated from each other. Separation kernel hypervisors have cropped to implement asymmetric multiprocessing (AMP) in multicore environments in embedded applications. AMP enables systems to be certified along the lines of the hypervisor and one or more of its VMs while allowing VMs that are less secure to coexist.
These hypervisors tend to be small not only for efficiency but also to meet security certification requirements. A typical configuration would have a hypervisor running a secured OS in one VM and a more generic user OS like Linux or Windows running in another VM.
This file type includes high resolution graphics and schematics.
The separation kernel approach has been common in deeply embedded applications, especially military and medical. But the approach is becoming more common in consumer devices as well.
Green Hills Software’s Integrity Multivisor for Trusted Mobile Devices is designed to bring two versions of Android under user control. A more open, personal, user configurable version has access to the display and peripherals when the green status LED is on (Fig. 1a). A double click on a control button toggles to a locked-down enterprise instance of Android that is shown with the LED showing red (Fig. 1b).
This approach would permit a network administrator to lock down the enterprise instance, forcing the use of a hypervisor-managed VPN and preventing the addition of any new apps. A virus in the personal side would not be able to infect or compromise the secure side. Integrity also provides a virtual Self-Encrypting Drive (vSED).
Wind River’s Solution Accelerators for Android Security use a similar partitioning scheme. They support Android and SE Android. Inactive lightweight domains can be encrypted, and the number of domains is only limited by storage. Like most similar approaches, it can have different security profiles for each domain.
Lynuxworks also has a separation kernel with its LynxOS. Its latest LynxSecure addresses zero-day rootkit and bootkit attacks. Many other BIOS and hypervisors provide similar protection against changing the BIOS or boot records, but LynxSecure goes further and actively looks for this type of attack. It provides notification in addition to preventing attacks.
Program WhiteListing
Isolating OSs running on a multicore chip will become more common, but the approach does not scale as we move up the stack to applications. The challenge is that a high-level OS like Windows or Linux is designed to run programs that are found on a storage device. The OS will run any valid program, even if it’s a virus or a worm.
Whitelisting prevents unwanted programs from running by limiting the programs that can run on a system to those that appear on the whitelist. Even if an application is installed by nefarious ways, it won’t be executed. McAfee Embedded Control targets Windows, Linux, and Solaris OSs including older versions of Windows such as Windows NT. It is designed for embedded applications where the programs are fixed.
Embedded Firewalls
Isolation at the network level also can help secure a device. Firewalls, VPNs, and intrusion detection systems are all part of a developer’s repertoire. They often are incorporated into the OS or an OS distribution.
Another approach is to put these features into a separate physical or virtual device. This simplifies the host environment and is really the only alternative to protecting legacy environments. It does not protect the legacy system if an attack can make it onto the system, but limiting access to the system can go a long way in protecting it. Isolation can be very effective if there is a dedicated VPN link between the device and an isolated network.
Virtualization allows each inclusion of virtual firewall. A VM will have access to a network through another VM that acts as a firewall. Physical firewalls are common, with smaller ones targeting embedded and legacy systems.
Icon Labs’ Floodgate Defender is a firewall targeting this space (see “Securing Embedded Devices” at electronicdesign.com). It can restrict communication between network ports and addresses so a host device can only communicate with other whitelisted devices within the network. Secured with McAfee Application Control, it incorporates intrusion detection and prevention support. Logging and alert messaging allows a large group of devices to be managed.
Zilog’s ZGate reference design puts Icon Labs technology on an 8-bit eZ80Acclaim microcontroller (Fig. 2). This type of system is intended for customization by developers who would incorporate the chip into an embedded system offloading the network security support.
Updates or the lack thereof
Keeping software up to date can be a challenge in a security-oriented environment. Locking down applications, the OS, and even the firewalls help to prevent inadvertent or malicious changes from occurring, and this can be an advantage. Unfortunately, rarely are all threats and application features known ahead of time. Bugs are always a common source of irritation that can be fixed if the software can be updated.
Features like secure boot, firewalls, and whitelists need to be addressed when dealing with more advanced embedded devices because they are designed to prevent changes. In this case, the changes to proper procedures are wanted, and security measures need to be addressed. Unfortunately, no single standard addresses this, so developers, network managers, and users need to contend with different devices having their own methodologies for updates.
Embedded and consumer devices often have the added challenge of dealing with updates at different levels and by different groups. For example, a smart phone may have low-level driver updates that would come from a service provider while a user may manage application updates.
Updates have to meet more than just the reliability standards. They also have to meet the security requirements that may include authentication and decryption.
However, the additional security also limits the ability for users to have an updated device since they usually cannot change the underlying system. This issue has cropped up with smart phones and tablets that are locked into a particular instance of an OS such as an older version of Android or Windows.
Wireless And Network Security
Firewalls are useful on wireless devices, but a wireless firewall bridge won’t provide the same level of security as a wired bridge. Many various wireless systems have no security for transmission or transactions.
Still, the trend is toward more security, and standard protocols like 802.15.3 and 802.11 have a range of security protocols that can be employed. Earlier protocols like WEP have been broken, though. This was an issue when devices and drivers only supported WEP, but most now support more advanced and secure protocols like WPA.
Keep in mind that securing the wires and airwaves doesn’t guarantee that everything will be secure. Wired and wireless device developers need to keep security in mind at all times. One security issue that arises with the Internet is the use of the domain name system (DNS). A corrupted DNS server can redirect communication to a rogue site. It is one way to attempt a man-in-the-middle attack.
DNSSEC extends the standard DNS protocol to provide protection against DNS spoofing. DNSSEC is also used between DNS servers when exchanging information.
DRM Is Not About Security
Digital rights management (DRM) often crops up in security discussions, especially when consumer or mobile devices are involved. DRM techniques employ many of the technologies used in securing a system such as encryption and authentication.
DRM is all about third-party control. It’s used to limit the use of multimedia content such as music or movies, but the technology can apply to any type of electronic content including e-books and applications. The keys used when installing Microsoft Windows are part of a DRM scheme.
The discussion of whether DRM is a good thing or not can be left to another article, but it is germane to security because DRM is a lot easier to implement and harder to bypass if the underlying operating system and applications are secure.
Securing The Keys
Security systems assume that the keys used for authentication and encryption are secure. Keeping a single key secure on a host usually is sufficient to protect additional keys that would be used in a system since this first key could be used to encrypt and decrypt the other keys.
Secure memory chips have been used in a number of applications, and a trusted platform module (TPM) is a common option on motherboards these days. Putting the secure storage on chip is even better. Chips that support secure boot often provide this facility, but they will cost more than a similar product without it.
Security probably isn’t on the minds of most users and developers of consumer electronic products, but it’s no longer being ignored. It remains to be seen whether improved security measures will reduce or eliminate security-related attacks on our smart phones and intelligent washing machines.
We will also have to contend with the downside of security. Badly implemented or deployed security can make systems inoperable. For example, some systems have locked up because the UEFI support improperly handled properly signed device driver files. It is also the reason why you can’t play some Blu-ray disks on a particular combination of hardware. Then again, is security ever perfect?
This file type includes high resolution graphics and schematics.
