CEO Network Security Panel

Greg Nicoloso, CEO, Eurotech

THE QUESTION: With embedded devices increasingly connected not only to local networks, but also via gateways to the Internet and ultimately to large servers, the issue of security spreads from the servers to even the smaller and resource-limited devices. Where do you see the major vulnerabilities for such diverse networks and what do you see as the effective strategies for securing them?


  • Page 1 of 1
    Bookmark and Share

Article Media

Currently, there is still a large percentage of manufacturers within the “embedded” appliance product sector who are relying on the notion of “security by obscurity” strategy for TCP/IP network security. As both wired and wireless network connectivity become a requirement for even the smallest embedded computer node, product designers must start looking at how to secure these devices for continuous operations in a “hostile” network environment. 

There are several layers of technology that can be examined here with regard to where device security needs to be addressed. This includes hardware design, BIOS/bootloader, operating system implementations and application framework design.

At the most basic level, hardware designers need to consider the implications of hardware-level security. This includes hardware-based security “firmware” devices such as trusted platform modules (TPMs) and tamper detect hardware features. Many sectors including banking and gaming require both the physical level of security offered by tamper detect circuitry as well as the initial core “root of trust” offered by the functionality of trusted platform modules. A final consideration of the hardware design must offer the option of write disabling the bootloader or BIOS device in final production such that initial core root of trust can be established.

At a firmware level, overall device security must start with the bootloader/BIOS firmware. As noted above, most secure device specifications dictate (from both a physical and programmatic standpoint) that the device can power up and determine that neither the bootloader/BIOS nor operating system binary images have been changed or tampered with. In most cases this is accomplished through the use of a TPM in conjunction with the boot firmware. TPM technology offers a hardware “vault” that can encrypt and contain hash keys of both the booting firmware as well as the selected operating system image. The booting firmware must then validate both itself as well as the operating system image using the TPM hardware. This validation process establishes the core “root of trust” so that the device can then continue the boot process into the operating system knowing that no malicious changes have occurred on either the boot media or the operating system.

At this point the hardware design can be considered a “secure platform” in a raw sense of the word, and we can proceed to the next level of examining operating system selection. If we follow along in this process, the security of the platform is handed off from the boot media to the operating system. Most available OSs provide the capability to add a layer of “security-enhanced” operations. We won’t go into a great level of detail here, but suffice it to say that Windows, Linux and other popular RTOSs provide the APIs required to continue the security policies established by the TPM, and have “access control security policies” for secure user and application access to the system resources (file system, network access, device access, etc.). 

Up to this point we have considered the security aspects from the perspective of physical and internal security, but now with the operating systems up and running, we can turn our attention to the various communications interfaces and how to address their security requirements. Most embedded compute platforms still provide a local console (RS-232, USB, etc.). Of course, local console security still needs to be managed by the configuration and set up of the system with additional attention to user access control. The primary consideration here is the use of TCP/IP networking interfaces given the critical role of many of these types of embedded compute platforms. Ethernet, Cellular, WiFi, Bluetooth and RS-232 (via PPP) can all have connections into the TCP/IP stack of an embedded platform and can all present security risks. 

At a basic level it is critical to have an up-to-date TCP/IP stack implementation. Most of the modern embedded OSs do supply this level of conformance to the latest TCP/IP standards and the associated RFCs that specify the operations. Software engineers porting the OSs must have a good understanding of all levels of TCP networking implementation since risks can even exist at the lowest level of the stack implementations. ICMP, TCP and IP layers of the stack all need to be considered when porting an OS and again in context to the manner in which the system is configured. TCP/IP utilities within the OS itself, such as routing, address translation, open ports and security, must all be considered and set up as the default to be secure and not allow access without authorization and authentication. These would all be considerations within the initial setup of a system. On top of these concerns, the final level of consideration is the end application.

Overall device security is only as good as the final application running on it. At the lower levels this does include the APIs to the operating systems with regard to existing security features and default configuration. But the application has the ability to open ports, allow access, configure routes, etc., within the overall scope of the system. Even following all of the TCG recommendations at a platform level does not guarantee security if the application developer is not well versed in TCP/IP networking technology. 

One excellent source of information for an overall platform security specification is offered by the Trusted Computer Group (TCG) ( This specification covers the lifecycle of an entire “secure compute” platform. 

Columbia, MD.
(301) 490-4007.