Security Issues in Embedded Networking

Mark Eichin, Cygnus Support

Introduction

As embedded systems have become more advanced, the tools for working with them have also improved. Often the easiest way to debug an embedded device is to hook it up to a local network, and then interrogate the device using remote debugging tools, often on a workstation of some kind. Many devices continue to use a network in production, for reporting data or further diagnostics. These so-called "local" networks are often far more widespread -- that is, after all, part of their convenience. This convenience can introduce a number of risks, due to unauthorized access to networked equipment. The Kerberos Authentication System, developed at MIT, is well suited to providing the missing pieces necessary to provide safety as well as convenience. Even though Kerberos is commonly used on workstation and server systems, it can fit into a reasonably small box.

What's the problem?

Modern networks go everywhere. Even small networks often connect an entire lab or a work site, larger ones connect multiple continents even within the same company. If you put a device on such a network, you can easily connect to it from anywhere that the network reaches... and without proper access control, anyone else can too.

Why would this matter? Aside from the obvious dangers of deliberate malicious access, accidental access to an improperly secured device that controls significant real equipment can cause real world damage. Even when control is not an issue, measurements taken by such devices can be valuable, and thus need protection.

With otherwise harmless devices, access control can still be useful. At the very least, if the embedded device gets correct identification information about access requests, it can log them somewhere for later debugging, or specifically allow only access by one user at a time.

What are the solutions?

There are a number of conventional ways of limiting or controlling access to equipment already. They provide various levels of security, and have various problems.

Nothing at all

The simplest solution is to do nothing at all. It is possible to simply not provide access restrictions of any kind, and trust that all employees are trustworthy and competent in their use of the shared network. This approach (by far the most common) also assumes that noone ever makes an expensive mistake on the network.

Passwords

A straightforward solution is to use some kind of password scheme. This puts up a first level barrier to accidental intrusion, but actually does fairly little about deliberate attack. Passwords usually pass over the network in cleartext, so any eavesdropper on the network (which means anyone with any control at all of their hardware) can simply record the password any time it is actually used.

Having distinct passwords for distinct devices is sometimes a problem, as people will write them down (making them easy for others to find), share them (since various people may need the same hardware for a project), or include them in automatic scripts (eliminating the inconvenience of typing them and also eliminating the protection from accidental access.)

Secure SNMP

One more effective solution is SNMP, the Simple Network Management Protocol. SNMP was originally designed to provide a low overhead mechanism for gathering data from networked devices; it is most commonly used to monitor the network itself (either by querying routers and gateways for information or by asking hosts directly.) SNMP does have a control mechanism, and because of this a security mechanism has been developed and discussions about standardizing it are underway. However, SNMP is not a general purpose tool. While it can be used for virtually any device (there are SNMP controlled toasters and model railroad systems) it is somewhat clumsy in these applications. The semantics of SNMP are tuned for lightweight monitoring, and as a result it does not perform well as a reliable control mechanism.

While SNMP is an international standard, Secure SNMP is still in the proposal stage. There are some concerns about how to specify an international standard involving cryptography when there are great variations in export control on cryptographic software, thus there is debate over whether it is more appropriate to specify a weak but exportable standard or a correct but more restricted one.

The Kerberos Authentication System

The Kerberos Authentication System was developed at MIT in the early days of Project Athena. As MIT was deploying several hundred workstations for general student use, with full connectivity to the Internet, it was clear from the start that once useful resources were made available, students would start exploring them, whether they were authorized to or not. Thus a strong security system was needed.

Kerberos was named for the mythological three-headed dog which guarded the gates of Hades. The three heads represented Authentication, Authorization, and Accounting. Kerberos eventually provided only the first of the three components, Authentication; it was recognized that different applications had vastly different authorization needs, but as long as they could determine reliably who was requesting access, the application could make the authorization decision itself. (Accounting received little attention as the Project Athena was originally the product of corporate funding, and eventually became part of Information Systems without losing the goal of general free student access.)

When Kerberos was originally implemented, the MicroVAX II was roughly the state of the art workstation. A goal of Project Athena was to provide services on machines that students might own themselves, so Kerberos was designed to be practical on a classic IBM PC (8088 processor at 4.77 Mhz) as well as larger machines. While the code has changed since then, the protocol has remained small and straightforward, making it still appropriate for small machines.

Another goal of Project Athena was to advance the state of the art; to support this goal, the source code to Kerberos (and much of the other work of the Project) is freely available for any use. This has made it easier to adopt as a standard, and it is available as system software from several workstation vendors, as well as in the form of an add on product.

Kerberos is a general purpose authentication system. In the Kerberos model, you prove your identity (authenticate) to a service, and it decides if you should have access based on your identity. This allows arbitrarily complex access control decisions, or at the other extreme making no decision at all but simply recording the identity of the request.

This presentation shall attempt to show how Kerberos can in fact be used for a real embedded controller. The example system is an Intel i960 microprocessor running the VXWorks real-time operating system, with an ethernet interface and a serial port. While this is a moderately high performance RISC microcontroller, it should provide an adequate demonstration of the techniques involved.

How Kerberos Works

First, a few definitions to help clarify the explanation to follow.
Client
anything that uses kerberos to gain access to a remote service. This refers to the program itself rather than the user.
Server
a program that provides some service to a client. Examples include remote login and file system access.
Principal
an entity that is known to Kerberos. This includes servers and actual users.
Kerberos Ticket
a piece of data presented by a client to a server in order to prove identity and request access, like a movie ticket. A ticket is marked with a time and is only good for a particular service.
Key Distribution Center
or KDC is the heart of Kerberos. The KDC (or a replicated slave KDC) distributes Kerberos Tickets in response to requests from clients.
DES
The Data Encryption Standard is the private-key encryption mechanism used by Kerberos. It was developed by IBM and the US Government and standardized. Software and hardware implementations are widely available, and while they are not exportable, the description of the algorithm is, resulting in numerous implementations outside the US.
The security of Kerberos is based on a simple principle of secret key cryptography: if a message is encrypted in my key, only I can decrypt it; therefore, by decrypting it I can prove that I have the key (and thereby prove who I am.) The KDC keeps a database of DES encryption keys for all principals. For server principals, the key is only stored on the KDC and on the machine where server runs. For user principals, the key is only stored on the KDC -- when the user logs in, the key is generated from the typed password.

When a user needs to access a service, first the client requests a ticket for that service from the KDC. The KDC creates a packet with the content of the request, the current time, and the length of time for which the ticket will remain valid. It also includes a randomly generated key, for later use. It then encrypts this packet in the key of the server.

The KDC then adds the random key and the identifying information to the outside of the encrypted packet and encrypts it again with the key of the principal who asked for it (the user.) The packet is then sent back to the client; this is the last of the KDC's involvement.

The client then decrypts the ticket. This unwraps the outer layer, providing the verifying information as well as the random key. Note that this random key was not exposed over the network between the KDC and the client -- Kerberos does not require a secure network. The client is also left with the encrypted inner component. Now the client can send that component on to the server.

The server, on receiving the ticket, decrypts it using the key for its own principal. Given a successful decryption, it can examine the time stamp to see if the ticket is still valid (and check that this ticket hasn't already been presented, if appropriate) and make a decision about the identity given. The server is assured that the ticket can only have been presented by someone in possession of the key for the principal claimed therein, since only the KDC could have constructed the inner part of the ticket, and the KDC would only have sent it out encrypted in the key of the principal listed.

As a side effect, the client and server have now both been securely delivered a randomly generated key which they can use to encrypt or sign further messages between themselves, without needing to talk to the KDC again. The application can make whatever policy it wants to regarding how long such a key can be reused.

How Much Overhead?

Kerberos was designed to incur a very small amount of overhead. However, there are many kinds of overhead to consider.
Additional Code
The Kerberos libraries are broken down into small units, so that a given application will only link in the code that it needs. The DES library implementation used here is quite compact. While the size varies among different processors and compilers, the Intel i960 simple server example only used 8K bytes of code space for Kerberos and another 6K for DES.
Additional Data
The Kerberos libraries themselves need very little data; the DES implementation does need 6528 bytes of permutation tables.
Secure Storage on Servers
A server needs to be able to store the private key for it's principal; in the minimal case, this needs 9 bytes of secure storage (the 8 byte DES key and one byte for the key version number.) The current implementation records the name of the principal in a file along with the key (to allow multiple keys in a file).
Network Traffic
An authenticator is roughly 100 bytes, and is usually only sent when a connection is established and authentication is needed. Further messages can be protected by the randomly generated session key.
Computation Time
The message encoding is simple; tickets are transmitted in the byte order of the sender, and tagged so that the receiver can either switch the bytes around or do nothing. Most of the computational time involved is the DES encryption and decryption of the message. A SPARCstation ELC workstation can encrypt at 200,000 bytes per second, and the total amount encrypted for authentication is roughly 100 bytes. The Intel i960 used for the test was able to encrypt 120,000 bytes per second, or 8 microseconds per byte -- less than 1 millisecond total overhead per authentication.
So there is a cost for the use of Kerberos, but it is reasonable well contained, given a system that already has a "socket" style network layer.

How much work does it take?

In order to demonstrate the effort involved with using Kerberos on a target platform, I tried to reuse existing components of the MIT Kerberos release. MIT provides a "simple_client" and "simple_server" among other more useful sample applications in the public release of Kerberos. My goal was to get the simple_server running under VXWorks.

The porting effort

Porting was straightforward. It progressed as follows.

Embedded Clients

The discussion so far has only addressed putting a secure server on an embedded system. The client that talks to the server (in this example) was run on a workstation. It makes sense that one might want to deal with secure embedded client programs as well. Embedded processors are found in terminal concentrators and X display terminals, as well as other hardware that provides user access to a network. There is at least one vendor already including client side Kerberos support in their terminal concentrator; they've made some creative adjustments to it to deal with limited memory. X terminals are the next place to expect to integrate Kerberos. Moving Kerberos client code into an embedded system is a straightforward extension of the work described above.

Future Directions

The libraries can probably be pruned a bit more; there are multiple layers of subroutines that could be compacted.

It may be possible to make other space-time tradeoffs, such as a version of DES that uses much smaller tables but takes more time to run. (This might be useful for systems with 16 bit address spaces.)

This work was based on Kerberos version 4, which was "mature" at the time this paper was written (July 1993); Kerberos version 5 is under development, and should be released by the time this is in print (October 1993). Kerberos 5 is the "Standards Track" version of Kerberos, it has been rearchitected to be an acceptable standard protocol. This includes reworking the protocol using ASN.1, which will enlarge the code needed to simply handle the packets, but it is hoped that the public release will include a reasonbly efficient implementation.

The libraries themselves could be rearranged along more functional lines -- for example, server-specific components could be built seperately from client-specific components, to simplify porting to non-workstation environments such as embedded tools.

Conclusion

It is possible, even practical, to use Kerberos to provide authenticated access to a fairly small system. It can easily be customized to handle the special needs of an embedded environment, largely due to free availability of the source code.

Appendices

Sample output from server

Note that it identifies who the request was from (eichin@CYGNUS.COM, where CYGNUS.COM is the Kerberos "realm" rather than a domain name.) "Jennifer" is probably Jennifer Steiner, one of the Kerberos developers at Project Athena. -> socket has port # 9307 Received 104 bytes krb_rd_req returned 0: OK Got authentication info from eichin@CYGNUS.COM &c_sock.sin_addr is 192.80.44.2 Received 45 bytes krb_rd_safe returned 0: OK Safe message is: hi, Jennifer! Received 38 bytes krb_rd_priv returned 0: OK Decrypted message is: hi, Jennifer!

Actual Program Size

The following chart shows the actual space used by the code in the simple server, the Kerberos (krb) libraries it pulls in, and the DES libraries that get pulled in by Kerberos. Note that the text component of both libraries can be shared among multiple servers, if the target environment supports shared libraries. text data bss filename 1488 108 0 simple_server.o 10196 1400 3024 simple_server -lkrb 22484 2080 3224 simple_server -lkrb -ldes

Kerberos Sources

Trademarks

Kerberos, Project Athena
are trademarks of the Massachusetts Institute of Technology.
SPARCstation
is the trademark of Sun Microsystems Inc.
Intel, i960
are trademarks of Intel Corporation.
MicroVAX II
is a trademark of Digital Equipment Corporation.
IBM, IBM PC
are trademarks of International Business Machines.
VXWorks
is a trademark of Wind River Systems, Inc.