Security Issues in Embedded Networking
Mark Eichin, Cygnus Support
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.
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
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
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
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
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
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.
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.
- anything that uses kerberos to gain access to a remote service.
This refers to the program itself rather than the user.
- a program that provides some service to a client. Examples
include remote login and file system access.
- an entity that is known to Kerberos. This includes servers and
- 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.
- 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
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.
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
- 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.
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.
- Pick a name for the target configuration (trivial, but it is the
first step.) The abbreviated name used was i960vx, the full name
- Next, adjust the PATH and Makefiles to actually use the cross
compiler instead of the native one.
- Identify the byte order (in this case, LSB first) and set it in
the configuration target file and conf-i960vx.h.
- Identify preprocessor defines for the target (__i960__) and use
them in osconf.h to select this particular target.
- configure the tree.
- Run "make depend" to build the header files. This substitutes
some values into header files and attempts to build some tools which
aren't needed on a target.
- Build the DES library.
- Compile it first to allow debugging, and seperately with
full optimization to get good size estimates.
- Skip the "read_password" routine provided by the DES
library since we're not providing any user interface on the server.
- Build "verify" and make sure the DES implementation is
valid. (It was, the first time, no debugging required.)
- Build the main Kerberos library.
- It turns out that a simple build attempt with no changes
covered almost everything that didn't use sys/file.h -- and most of
those were unneeded on a server.
- Several modules referred to IP headers that have
different names in the cross-development system; this was easily
- The error table library built, though it turned out to be
unnecessary on the server side. (The additional code is only used to
report errors to the user on the client side.)
- The command table code didn't build but it is also
irrelevant to the server.
- Given the kerberos and des libraries, try building a server.
- The simple client and simple server demonstrate both
public and private messages.
- Since getservent isn't provided by the target
environment, simply specify the port to listen on directly.
- Also fix the code so that it binds to any available
interfaces rather than specifically looking for the primary one.
- A few functions weren't available the first time through.
- is used by the server to check the timestamp of the
incoming message (to within a 5 minute window.) For demonstration,
this can be left out; however, the server code should be modified to
record tickets received so duplicates are not used.
- turned out to be used by some unnecessary debugging log
functions, which could easily be turned off.
- The normal library routines attempt to open the file
"/etc/krb-srvtab" to find the server keys. Since this experiment was
performed on a board with no local filesystem, these routines were
modified to read a string which was input to the VXWorks environment
using a directly connected serial port.
- A bug was found and fixed in the byte-swapping used by
the quadratic checksum routine.
- After determining that everything works, go back and build the DES
performance measurement program.
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
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
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.
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.
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 22.214.171.124
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
- ftp athena-dist.mit.edu
- login as anonymous
- change directory to pub/kerberos
- get README.KRB4 -- it describes how to get the actual source code
- change directory to doc
- get dialogue.PS, krb_evol.PS, techplan.PS, usenix.PS to start
with; these describe Kerberos at various levels. Other files in this
directory may also be interesting.
- Kerberos, Project Athena
- are trademarks of the Massachusetts Institute of Technology.
- 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.
- is a trademark of Wind River Systems, Inc.