Browse Prior Art Database

Cryptographic Microcode Loading Controller for Secure Function

IP.com Disclosure Number: IPCOM000121617D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 3 page(s) / 114K

Publishing Venue

IBM

Related People

Weingart, SH: AUTHOR

Abstract

This article describes a method of implementing a single-chip microcontroller such that microcode may be loaded, when desirable, in a secure way.

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

Cryptographic Microcode Loading Controller for Secure Function

      This article describes a method of implementing a
single-chip microcontroller such that microcode may be loaded, when
desirable, in a secure way.

      The ability to load microcode into a microcontroller at IPL is
advantageous in that one device could be used in a large number of
applications, reducing inventory and cost. Microcode updates could be
installed without having to change physical hardware.  This also has
inventory and cost-saving implications.

      An obstacle to this approach, however, is that many
manufacturers of microcontrollers consider the microcode proprietary
and do not wish to have it exposed in plain text while awaiting
loading.  For example, the microcode which implements a disk or LAN
controller on a common microcontroller is valuable.  If the microcode
is made public by ex posing it in plain text in open storage or on
disk, it could simply be copied and used elsewhere.  This article
describes a method by which microcode could be kept in open storage,
protected by encryption, and then loaded into the microcontroller at
IPL, where it is decrypted for use.

      In a typical microcontroller, a microprocessor executes
microcode out of a Read-Only Memory (ROM), has some data storage
(RAM), and reads and writes from some I/O (which is how it connects
to the device(s) that it is controlling). The important part, for
this discussion, is the microcode ROM.  In typical applications the
microcode ROM is masked into the microcontroller during fabrication.
This effectively turns a general-purpose device into a
special-purpose device.  At the point where the microcode becomes
fabricated into the part, the microcontroller becomes a DASD
controller or a LAN adapter, etc., and can no longer be changed or
upgraded.

      One way of fixing the problem is to use loadable microcode.
This permits a general-purpose device to be customized or updated by
writing new or additional microcode.  The problem with this, as was
mentioned previously, is one of security.  If the microcode is
exposed in a public area of the system in which the controller is
used, it can be copied or changed without authorization. One solution
is to encrypt the microcode for transportation and storage, and
decrypt it only within the confines of the microcontroller itself.

      Fig. 1 shows a block diagram of this type of system. The
microprocessor, I/O, and RAM remain unchanged.  The microcode ROM is
now split into two segments (both ROM and RAM or EEPROM), and a new
storage element (key storage) is defined.  The microcode ROM is now a
smaller...