For developers building and deploying applications based on a smart embedded OS, it is imperative to consider four key areas of embedded security: access control, resiliency against untrusted software, network stream security and content protection.

Access control for embedded devices is most comparable to enterprise security doctrine, especially for networked devices. Devices conceived as Internet appliances, as well as traditional embedded applications that extend their control and configuration options over a network, present numerous opportunities for exploitation.

Devices with visible consoles are susceptible to password cracking and login spoofing, as are devices with networked consoles running a Telnet session. Devices sporting Web interfaces and FTP access can be defaced and hacked through CGI and other upload channels. Devices with embedded Web browsers, e-mail and other clients need to be secured against malicious content and other downloads.

On the other hand, standalone devices are not necessarily immune from attack. "Toaster" type systems need to protect themselves against intrusion over specialized user interfaces. Even if a recognizable login console is absent, it may be possible to exploit standard input sequences to gain unwarranted control over an embedded system. Moreover, developers and manufacturers often leave open a variety of small back doors — for example, for production line testing and technical support — that later prove exploitable.

The simplest back door may be as visible as a spare serial port enabled for debugging, on the back of a POS system, or may involve undocumented "chords" of buttons or other controls. Numerous examples exist for printers (overriding mechanical safeguards), multimedia devices (overcoming conditional access) and tricks for advancing in videogames.

Exacerbating those basic security challenges are audience and attitude. The growing market for consumer electronics and personal communications devices (phones and PDAs) puts tiny servers and vulnerable clients into the hands of users unaccustomed to security discipline. Those users may regard such discipline as a nuisance and might disable the safeguards altogether.

For embedded devices with "peer" status (workstation-like CPU, memory, file system and networking resources), manufacturers, channel support staff, carriers and users themselves need to echo the security-conscious behavior of good enterprise system administrators.

In many cases, embedded platforms inherit many of the features as well as the liabilities of their corresponding desktop/enterprise operating systems. Windows CE and Embedded XP share security architectures with Windows; most embedded Linux implementations track the mechanisms in the standard Linux kernel; and even proprietary RTOS platforms reflect the security architectures of the networking and other stacks they deploy, such as BSD and derivatives.

Just as those workstation and server releases receive regular patches and security updates, so may embedded devices need to be patched against exploitation, viruses and other security risks in the field.

Applications that build on and deploy embedded Linux face the same security challenges as system administrators of Web and enterprise application servers. They must address the fact that embedded Linux can be a multiuser/multisession system. For networked applications (pretty much all embedded Linux use) they must consider the degree of exposure to network-based attacks. Even if the system in question resides on a private, local network (such as a printer), designers must still contemplate the possibility of exploitation from local nodes and applications.

Independently of measures designed to limit access to a device, the software and hardware architecture of the embedded system itself determine the possibilities for exploitability, containment strategies and overall consequences of security breaches.

While a multiuser/multisession OS like embedded Linux seems to offer more opportune points of vulnerability (via shells, network daemons, Web interfaces, scripting languages and the like), it also features greater resiliency and stronger defenses against rogue programs, Trojan Horses and other programmed exploitations

Buffer overflows and other exploitations in a traditional embedded operating system immediately yield access to all program instructions, user data and I/O devices in the simple, "flat" address spaces common to real-time OSes and embedded executives.

The virtually addressed, protected program and data in Linux/Posix processes isolates programs from one another. This model also helps limit the scope of exploitation damage: Exploitation-inspired failures can be isolated to single, restartable processes instead of requiring costly system-wide rebooting.

Integrated security mechanisms also protect such resources as files and I/O devices. Only privileged users and programs can gain access to key resources, but as with enterprise systems, misconfiguration and cavalier use of administrative (root) accounts can undermine otherwise highly secure embedded environments.

Embedded devices that leverage public networks or whose data and control streams flow outward through gateways to those nets are on a par with enterprise systems in terms of stream security. Legacy embedded nodes, like many existing desktop and server installations, do not leverage the inherent security mechanisms available in the protocols they employ or utilize software that predates available mechanisms.

Use of simple or proprietary datagram-based networking is no guarantee of security. Such ad hoc schemes are not immune to sniffing and spoofing and thus can give crackers access to data and control information for the client device, the server to which it is attached or both.

Embedded designers need to understand their options for authentication and encryption of network streams, make informed choices about applying those options to data and control over their fabric of choice, and provide and document configuration options to their customers — integrators, carriers, administrators and end users.

Unlike in the enterprise world, there are many embedded and small-footprint information appliance applications to which even trusted users may be denied access or given conditional access to secure content. Key examples include copy and regional protection schemes for digital media like DVDs and music CDs, pay-per-use resources like cable TV movies, transaction control information on point-of-sale devices, classified information on battlefield and other military applications, and trade secrets embodied in program code itself in a variety of industrial applications.

Numerous encryption schemes exist for the developer and content provider alike, with long public key encryption methods favored for generic document and message protection (DES, PGP, etc.), and variously proprietary, industry- and application-specific schemes, such as DeCSS for DVDs and extremely robust encryption for military and intelligence applications. In the area of content protection, again, obscurity is no guarantor of security, as evidenced by the recent, newsworthy cracking of DeCSS.

In the commercial arena, conditional access and content protection tend to aggregate with industry-specific middleware, leveraging Java security or schemes built into platform specifications like the Multi-media Home Platform (MHP).

Security seldom comes free. Encryption/decryption and processing of secure protocols exact a toll in throughput and overall system performance. A sprightly node on a high-speed network, nominally capable of approaching wire speed, and server applications nominally able to service dozens of connections in an unsecured context can be slowed to a crawl by the need to perform block encryption and decryption on data streams and content.

In the desktop and enterprise such performance challenges are addressed with resources (more memory, faster CPUs, additional nodes) usually unavailable in an embedded application. One solution is to offload security-related processing to co-processors, much as signal processing is handled by dedicated DSPs and as network packet forwarding is handed over to network processors like Intel's IXP and IBM's PowerNP).

Security processors (SPUs) such Motorola's MPC18x and 19x family support either look-aside processing, wherein the SPU performs operations on behalf of the main CPU as part of control-plane processing, or "in-line" security processing, with data and control streams traversing the SPU itself.

In the absence of such specialized hardware, the distributed architecture of many network and telecommunications applications provides opportunities for sharing the encryption load. Line cards and system blades boast multiple, powerful CPUs with enough spare cycles to "crunch" parts of the encrypted streams as they come in.