Building in secure remote management

These are common occurrences in the nitty-gritty world of embedded systems, even with the availability of nearly ubiquitous connectivity. Until recently they were unavoidable. But now, with increasingly connected computing and embedded control, there's an alternative: a three-link chain in the form of secure remote product management (SRPM).

At one end is the client device, which needs network connectivity and the ability to receive new programming, implement new programming and send status reports. The middle link is the network, which can be standard or proprietary, local or global, wired or wireless. At the front end is special server software that allows a manufacturer or vendor to easily manage the remote devices. No chain is stronger than its weakest link, and this is particularly true with SRPM. The whole chain must be tightly integrated from end to end.

There are several ways to implement SRPM in a network-connected embedded-client device. Perhaps the easiest method is a high-level software application that runs on the real-time operating system (RTOS). It has the least impact on the hardware design and is relatively straightforward.

But software also has many disadvantages. A system crash will disable all high-level software, including the SRPM software-just when it's needed most. Even if the system reboots itself, the RTOS boots before the SRPM, possibly preventing the SRPM from performing certain critical operations.

Another option is to integrate the SRPM logic with the Transmission Control Protocol/Internetworking Protocol (TCP/IP) interface chip. This has the advantages of a low-level hardware solution while avoiding the disadvantages of FPGA integration. If you think of SRPM as a networking function, why not integrate it at the networking level? But again, there are distinct disadvantages. Foremost is that integrating SRPM with TCP/IP reduces the system developer's design flexibility. Also, integrating SRPM with TCP/IP imposes more CPU/memory overhead and introduces new delays into the critical communication path.

After considering the alternatives, the road we took was to implement SRPM as a low-level process in the nonvolatile flash memory (NVRAM) of a common microcontroller. In this approach, the client side of the chain performs several important functions.

First, the TCP/IP stack sniffs the communication stream for the unique headers of SRPM packets. Then the client diverts any SRPM packets to its SRPM microcontroller over a common serial interface (SPI, I2C, JTAG). Third, SRPM software in the microcontroller carries out the special instructions in the packets. Packet payloads may include new code or data for the system. The SRPM software also verifies that the new code has been installed correctly. If verification fails, an automatic archive-and-rollback function restores the system's previous state. After verification, the SRPM software sends a status report to the SRPM server.

Our engineers found the chief advantages are versatility and affordability. It works with any TCP/IP or proprietary network-protocol stack or processor. Sniffing the communication stream for SRPM packets requires the addition of only a dozen lines of code-about 256 bytes.

Due to their nature, however, SRPM packets should rarely, if ever, need the wire-speed processing required for other types of packets. They don't need to be forwarded anywhere else on the network. Indeed, it's wise to keep the bulk of SRPM processing out of the wire-speed communication path, which is often the system's critical path.

Using a serial interface to transport the SRPM packets within a system is a case of serendipity. Virtually all networking chips have some kind of serial interface, even if it's primarily intended for debugging and verification during development. Why not use this readily available pathway for SRPM packets? Using the existing serial interface eliminates the need for a special interface or bus to hook the SRPM microcontroller into the packet stream.

Implementing the SRPM software in a microcontroller's NVRAM realizes more cost savings. Even an 8-bit part can handle the modest client-side processing requirements of SRPM in this fashion. The microcontroller can be clocked as low as 4 MHz, ensuring compatibility with dirt-cheap embedded-system designs. The amount of NVRAM required is trivial.

Disadvantages are few. It does add one chip-the SRPM microcontroller-to the system, albeit a small and inexpensive chip. A future goal is to implement the In-System Programming Gateway as soft IP (synthesizable intellectual property), allowing designers to integrate the client-side SRPM into an out-of-the-way corner of an ASIC or FPGA that's already found in the system. Although IP integration is more work for developers, it might be the only solution for embedded systems that have the strictest cost and board-space requirements.

This low-level, microcontroller-centric approach also faces the same challenge as all other approaches to SRPM: Making it work requires a complete end-to-end solution, not just a clever client-side solution. The SRPM server software that completes the chain must operate seamlessly with the client software or the system won't be easy to manage-and manageability is the whole point.

We found that to make the low-level protocol approach to SRPM work requires the use of a secure service hub, but any good SRPM implementation should perform similar functions. One function is to assign and track each client's ID number. Networked clients already have an Internet Protocol address, but to preserve security, the SRPM ID is private. Another function is to track the history and activity status of the clients and provide registration services. A third function is to manage the actual one-to-one transactions with clients.