Browse Prior Art Database

Secure Remote Configuration for Networked Computer Systems

IP.com Disclosure Number: IPCOM000122949D
Original Publication Date: 1998-Jan-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 141K

Publishing Venue

IBM

Related People

McCall, CD: AUTHOR

Abstract

Protocols currently available for configuring or booting computer systems from a server over a network are fundamentally insecure. Any system on the network can set itself up as a configuration or boot server, receive requests from client systems, and cause them to download and execute programs. A malicious user could use this process to steal or delete data from the client machine, or install additional unwanted programs such as viruses.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 39% of the total text.

Secure Remote Configuration for Networked Computer Systems

      Protocols currently available for configuring or booting
computer systems from a server over a network are fundamentally
insecure.  Any system on the network can set itself up as a
configuration or boot server, receive requests from client systems,
and cause them to download and execute programs.  A malicious user
could use this process to steal or delete data from the client
machine, or install additional unwanted programs such as viruses.

      The problem is addressed in the improved system described here
by extending the configuration or boot process so that the server and
client authenticate each other and validate the content of the boot
messages before proceeding with the boot process.

      Standard boot protocols are initiated by the client and server
exchanging packets in clear unencrypted form over the network.  The
request is usually broadcast so that the client does not need to be
configured with the address of a particular server in advance.

      In the improved system each trusted server system saves a KEY
in its secure storage.  The server may keep a list of different keys
for different clients, indexed by a field in the request that
uniquely identifies each client.  In current boot protocols the
client's network  address usually fulfils this function.  The client
either stores the key  in non-volatile memory, or prompts the user
for the key each time it boots, or uses a combination of a stored
system key and a user key. The  key may be the same as the Privileged
Access Password or Power On Password commonly used for access to a
PC's BIOS settings, although a longer key may be preferred to improve
security.  In any case the key should be long enough to make it
impractical to break by trying all possible values.

      This implementation is based on the DHCP configuration and boot
protocol.  This requires the following exchanges to configure the
client:
     Client                            Server
  DHCPDISCOVER ->
                                   <-  DHCPOFFER
  DHCPREQUEST  ->
                                   <-  DHCPACK

      When the client sends its DHCPDISCOVER request packet it
includes a security tag field as part of the 'DHCP Extensions'
field.  The security tag contains two subfields.  The first is the
boot identifier (BI), a pseudo-random number which is highly likely
to be different every time the client boots, and is not predictable
from one  boot to the next.  The BI acts as both an identifier to
ensure that the  server is responding to the current discover, and as
a challenge to the  server to encode it correctly.  The second is the
Message Digest (MD),  a number calculated from the content of the
packet with the key which is  highly likely to be different for
different packets and different...