Microcontroller with secure signature extraction

Details Microcontroller with secure signature extraction Microcontroller with secure signature extraction

1999-01-08

2002-09-17

Hayes, Gail (Department: 2131)

Electrical computers and digital processing systems: support

Multiple computer communication using cryptography

Protection at a particular protocol layer

C711S103000

Reexamination Certificate

active

06453417

ABSTRACT:

BACKGROUND OF THE INVENTION
The invention relates to verification of firmware programming, and relates particularly to verification of the programming of read-protected firmware.
It is well known to use a microprocessor in a system having a stored program in memory to accomplish any of a variety of functions for a user. The stored program may be in RAM but in many present-day systems the stored program is in ROM, PROM, EEPROM or nonvolatile RAM.
It is also well known to use a controller, a term that is generally used to describe a single-chip integrated circuit with a processor, some input/output port circuitry, and some onboard memory to accomplish user functions. Many controllers are made so that the stored program may be stored in ROM or PROM or EEPROM that is part of the controller package. Such a package offers many engineering benefits, including small parts count, low cost, and simple design, at least for those user functions that fall within the computational and I/O capabilities of the controller. Controllers are used for many consumer applications, including the control of mechanical devices such as clothes washers. Controllers are also used for many industrial control applications. Many personal computers use controllers to handle serialization of key scan codes within the keyboard, to handle receipt of serial scancodes from the keyboard, and to handle motherboard functions external to the main processor. In laptop and notebook computers it is commonplace to use a controller for floppy disk and hard disk control, as well as for power management.
The design process for use of a controller in an application necessarily involves some software design since the controller is useless without firmware. The programming tasks are more daunting than most modern-day high-level language programming tasks, for several reasons. First, a high-level language task typically is running on a relatively fast processor, so that the code need not be particularly efficient. Second, most high-level programming tasks are able to ignore time-critical issues such as the servicing of interrupts and frequency of polling for data values, because the hardware and operating system protect the high-level language programmer. Third, for many high-level language tasks memory is considered to be arbitrarily low in cost so that no one cares how large the program is.
In contrast, the firmware coding for a controller application is often quite difficult. The computational task has to be accomplished with the typically slow processor found in a general-purpose controller. The computational task requires that the programmer be skilled in handling of interrupts and other time-critical events. The memory is not unlimited, but is often quite small by modern standards, so that conservation of bytes matters. Heaped onto these factors is the fact that much of the coding has to be in machine language or assembler rather than a high-level language to accomplish the desired goals. It will be appreciated that the programming skills and insights required in the programming of a controller are quite different from those of the average high-level language programmer, and indeed bring to mind the programming skills that were required decades ago when core memory meant iron cores and 256 bytes was a common core size. Another way to appreciate the challenge of the controller programming tasks is to realize that the software written for execution in a controller is not an application running over an operating system, but instead is software that must fulfill all requirements of both the application and the operating system.
These considerations make it unsurprising that the engineering community has demanded, and the chip makers have supplied, controllers that are made so that the firmware cannot readily be read or otherwise obtained by one who is in possession of a controller. This contrasts most strikingly with systems having a processor and a distinct ROM chip which could be read out in straightforward fashion using commonly available electronic equipment. Such a controller is sometimes called a “copy protected” controller.
For many applications, especially noncritical consumer applications, the copy protected controller satisfies all its demands well. The firmware is in a nonvolatile store, so that it may be relied upon even if power is interrupted. The many benefits of the use of a controller, such as the small chip count and savings of space, are available. And the executable code, stored in the “copy protected” memory, is safe from prying eyes.
For some applications, however, such as those with safety and government regulatory, approval, exemption or certification requirements, the copy protection feature of the controller runs afoul of the perfectly understandable desire on the part of the regulator to be able to be sure it knows what is in the copy-protected memory. In a typical regulatory setting such as the U.S. Food and Drug Administration there is an initial approval, exemption or certification activity that leads to a particular regulatory status for an item of equipment. It may later be necessary, however, for the regulator to be able to perform spot checks of the items of equipment from time to time. Among the spot checks may be checks that individual components are identical to the components that were in use when the equipment was first certified. The difficulty arises, however, when a copy-protected controller is used, that the regulator is not readily able to determine whether a controller is, or is not, programmed identically to the controller that was used at the time of the initial approval or certification.
The usual engineering decisions that have been made in such circumstances have been either to abandon use of a controller completely, using instead separate chips the contents of which can be read out if necessary to satisfy the regulator, or to switch to a controller that is not copy-protected, namely that permits direct readout of the contents of the stored program memory.
It is thus desirable to have a way to make a system including a controller, in which the stored program of the controller is safe from prying eyes, and yet in which a party wishing to confirm the contents of the stored program, as for regulatory purposes.
SUMMARY OF THE INVENTION
In accordance with the invention, a controller contains software which, when triggered in some prearranged way such as assertion of a unique input combination to the controller, calculates a digital signature for the contents of the protected memory of the controller. The digital signature is preferably extracted from the contents of the memory by means of a function that varies greatly with even small changes to the memory contents. The function preferably is such that one cannot easily determine from the output what input generated the output. The function is preferably such that one cannot easily create a data set for input that yields any particular predetermined output.
In a preferred embodiment, the circuitry generating the signature is embedded in hardware of the controller so that its digital signature function is unknown even to the programmer writing the main body of code to be stored in the protected memory. With such a hardware configuration, a regulator may have a very high degree of confidence that the memory contents are what they are expected to be.


REFERENCES:
patent: 4467444 (1984-08-01), Harmon, Jr. et al.
patent: 4584665 (1986-04-01), Vrielink
patent: 4648750 (1987-10-01), Wilkie et al.
patent: 4897842 (1990-01-01), Herz et al.
patent: 5036461 (1991-07-01), Elliot et al.
patent: 5099516 (1992-03-01), Durkin et al.
patent: 5101498 (1992-03-01), Ehlig et al.
patent: 5115435 (1992-05-01), Langford, II et al.
patent: 5144659 (1992-09-01), Jones
patent: 5175840 (1992-12-01), Sawase et al.
patent: 5191608 (1993-03-01), Geronimi
patent: 5220567 (1993-06-01), Dooley et al.
patent: 5220606 (1993-06-01), Greenberg
patent: 5224166 (1993-06-01), Hartman, Jr.
patent: 5251304 (1993-10-01), Sibigtroth et al.
patent: 5255244 (1993-10-01), Dey

Affiliated with

Also associated with

Rating

Microcontroller with secure signature extraction does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Microcontroller with secure signature extraction, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Microcontroller with secure signature extraction will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2887160