1 June 1997: Add Appendix S.
1 June 1997: Activate links to Images 43-107.
OFFICIAL USE ONLY
SANDIA REPORT
SAND91--2201 • UC--706
Official Use Only
Originator Controlled
Printed June 19 1992
William H. Payne
Prepared by
Sandia National Laboratories
Albuquerque, New Mexico 87185 and Livermore, Calitornia 94550
for the United States Department of Energy
under Contract DE-AC04-76DP00789
OFFICIAL USE ONLY
Contains information which may be exempt from public release
under the Freedom of Information Act (5 USC 552), exemption
number(s) 3 . Approval by the Department ot Energy prior to public
release is required.
Originator: Paul A. Stokes Date: 4/28/92
DESTRUCTION NOTICE
Destroy by any method that will prevent disclsoure of contents or
reconstruction ot the document. (See Sandia National Laboratories
Instructions (SLI) 1008-4,5).
SF 2900Q(8-81)
OFFICIAL USE ONLY
[2]
Issued by Sandia National Laboratories, operated for the United States Department of Energy by Sandia Corporation.
NOTICE: This report was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor any of their employees, nor any of their contractors, subcontractors, or their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government, any agency thereof or any of their contractors or subcontractors. The views and opinions expressed herein do not necessarily state or reflect those of the United States Government, any agency thereof or any of their contractors.
[3]
SAND91--2201
Official Use Only
Originator Controlled Printed
June 1992
Distribution
Category UC--706
William H. Payne
Verification Systems and Technology Department IV
Sandia National Laboratories
Albuquerque, NM 87185
Data authentication is the process of computing a keyed checksum designed to ensure that a frame of data has not been altered after it has left a transmitter. The Deployable Seismic Verification System data authenticator implements a sensitive shift register algorithm in hardware. Key management and loading are done with an 80C31 microcontroller. The data authenticator is housed in a cast-aluminum TEMPEST enclosure. Interface cards connect the data authenticator to the PC/XT, VME, and authenticator buses. The data authenticator costs approximately $1500; it processes about 20K bytes per second, draws approximately 200 milliamperes, and occupies about 5-3/8 inches diameter by 10-1/2 inches of space.
OFFICIAL USE ONLY
Contains information which may be exempt from public release Originator: Paul A. Stokes Date: 4/28/92 |
[4]
The author thanks the following people who gave so much of their time and effort to this project:
G. D. Blanchard for drafting, casting, and machining the TEMPEST container; Douglas Downen for providing the DOE-NSA interface; H. B. Durham who served as project leader; my supervisor, J. M. Holovka; Charles Kirk for drafting, tooling, and fabricating the plastics; C. R. Rethy for designing the diode protection circuits on the bus decode board, the analog switch circuits on the 32Kx8 EEPROM board, and the TEMPEST filter placement on the vestibule; R. Serna for the layout and fabrication of the printed circuit board; and Thomas White who served as the NSA interface on the authenticator project.
[5]
Contents |
|
| ___________________________________________________________________ | |
| Introduction | 7 |
| The DSVS Authenticator | 7 |
| The Algorithm | 13 |
| The F Register | 17 |
| The V Register and State Sequencer | 18 |
| The R Register | 21 |
| The Bus Decode Board | 22 |
| The Command/Status Board | 22 |
| The Watchdog Timer Board | 23 |
| The Mother Board | 24 |
| Maintenance Support Board | 24 |
| The EEPROM Board | 24 |
| Bus Extender Card | 27 |
| External Bus Exerciser | 27 |
| VME Bus-Authenticator Interface Card | 27 |
| IBM PC/XT-to-Authenticator Bus Interface Card | 27 |
| Address Assignments and Functions | 27 |
| Message Formats | 27 |
| Test Source Code | 27 |
| Photographs | 30 |
| Field Test Record | 33 |
| Silicon-Compiled Chip | 35 |
|
|
| APPENDIX A--Authenticator Address Map | 39 |
| APPENDIX B--TEMPEST Enclosure Diagrams | 41 |
| APPENDIX C--F Register Schematic | 49 |
| APPENDIX D--V Register and State Sequencer Schematic | 55 |
| APPENDIX E--R Register Schematic | 57 |
| APPENDIX F--F Register Schematic | 61 |
| APPENDIX G--Command/Status Board Schematic | 65 |
| APPENDIX H--Watchdog Timer Board Schematic | 69 |
| APPENDIX I --Mother Board Schematic | 73 |
| APPENDIX J--Maintenance Support Board Schematic | 77 |
| APPENDIX K--32Kx8 EEPROM Board Schematic | 81 |
| APPENDIX L--64Kx8 EEPROM Board Schematic | 85 |
| APPENDIX M--Bus Expansion Board Schematic | 89 |
| APPENDIX N--External Bus Exerciser Schematic | 93 |
| APPENDIX O--VME Bus Interface Schematic | 97 |
| APPENDIX P--IBM PC/XT (ISA) Bus Interface Schematic | 105 |
| APPENDIX Q--NSS Authenticator Addresses | 109 |
| APPENDIX R--Message Formats and Protocol | 123 |
| APPENDIX S--Test Source Code | 145 |
| APPENDIX T--Benincasa's Algorithm Deficiencies | 181 |
|
|
Figures |
|
| ___________________________________________________________________ | |
| 1 Artists's conception of the authenticator TEMPEST enclosure | 9 |
| 2 Artist's conception of the printed circuit card assembly extending
from the TEMPEST enclosure |
|
|
[6]
Figures (continued) |
|
| ___________________________________________________________________ | |
| 3 Polycarbonate-glass endplate used with authenticator | 11 |
| 4 Polycarbonate-glass load/thrust bearing pieces | 12 |
| 5 Photograph of the injection mold die for the load/thrust bearing
pieces and endplate of the authenticator supports |
|
| 6 Diagram of the data authenticator algorithm structure | 14 |
| 7 Four authenticators to VME U6 bus card | 28 |
| 8 Authenticator to PC/XT bus interface card | 29 |
| 9 Data authenticator TEMPEST enclosure | 30 |
| 10 Disassembled authenticator | 30 |
| 11 Authenticator with bus extender and maintenance support board
ready to undergo test |
|
| 12 Authenticator-to-authenticator bus card and cable | 32 |
| 13 Memo dated September 3, 1991 | 33 |
| 14 Memo dated September 11, 1991 | 34 |
| 15 Architecture of authenticator | 35 |
| 16 Silicon compiled chip of the algorithm portion of the authenticator | 36 |
| 17 Floor plan of the silicon compiled authenticator | 37 |
[7]
Data authentication is the process of computing a key-dependent checksum of a message. The checksum is appended to the message by the transmitter and checked by the receiver. Messages that contain valid checksums are called authentic messages. Messages with bad authentication checksums either contain errors in the checksum, errors in the message, or are counterfeit.
A data authentication algorithm produces a pseudorandom checksum for each processed message bit. A key is the "seed" for the pseudorandom sequence.
The National Security Agency (NSA) provides data authentication algorithms for treaty verification applications. Most of the algorithms are classified. NSA will declassify a treaty verification algorithm to a classification level that allows it to be shared with a treaty participant after the treaty has been signed.
In 1973 NSA supplied to Sandia National Laboratories (SNL) a data authentication algorithm, called the Unmanned Seismic Observatory algorithm, for use in the Comprehensive Test Ban Treaty seismic verification systems. The report, submitted by R. Benincasa of NSA, is classified and therefore cannot be cited here.
The purpose of this SAND report is to document the construction at SNL of the data authenticator used for the Deployable Seismic Verification System (DSVS). This documentation should be of value in the years to come for those who may want to know how it was built, how to maintain it, and how to upgrade it.
Thus far, SNL has implemented the algorithm three times. Each time, the hardware and software were upgraded. The first implementation was done in 1974, by R. E. D. Stewart, D. A. Reynolds, and J. G. Deasey. This was a "bench test" implementation in the sense that the algorithm was done in hardware wire, wrapped on "cash" cards, and placed in a test rack. This algorithm implementation was done entirely in the hardware. The authenticator hardware was exercised by a Nova 800 minicomputer (Data General Corp.). They did not try to make the authenticator small, low power, or to enclose it in a TEMPEST container. This implementation was for a feasibility study. R. Stewart provided complete documentation, including schematics and computer codes; this also cannot be cited here because it is classified.
The second implementation, by M. A. Schaefer, took place between January 1978 and September 1979. This was done in low-power 4000-series CMOS logic; an NSC800 microcomputer was used to pass bytes to the authenticator hardware and read back the values. This authenticator, which processed data at 19,200 bits per second, was housed in a TEMPEST container that had been tested and approved by NSA. There were, however, three major problems with this second authenticator:
1. Its hardware was classified.2. Its cost was high--about $75,000. This included two authenticators and the TEMPEST containers for both. Cost of each container was about $20,000 of this $75,000.
3. Its processing speed was low.
The author was assigned to build a third version for the Deployable Seismic Verification System. The goal was to eliminate the problems attributed to the second version. Additional requirements were
[8]
that it be of sufficiently low technology to make it exportable, and that its development costs be kept low. Design and construction began in 1987. This third version of the authenticator was working successfully by 1989.
Since this authenticator was to be attached to the DSVS downhole logic (DHL) and to the Receiving and Monitoring Station (RAMS), interface specifications had to be drawn up and made available at the outset to the hardware designers. The designers were told that the hardware interface would look like an Intel 82C55A Programmable Peripheral Interface chip. If they met the electrical specifications for connecting their systems (the local memory or I/O bus) to an 82C55, they would then be able to communicate with the authenticator. The 82C55A contains a reset, chip select, read, write, three address input lines, and eight bidirectional data lines.
The new authenticator was designed top-down. The next step was to do a preliminary assignment of the chip port functions. The three address input lines offer eight read/write options. The basic function of an authenticator--any authenticator--is to receive data, and to provide status and authenticator values. Key management was also included. The reasons for this were: (1) the keys could be contained in the TEMPEST enclosure; and (2) DHL and RAMS software would be much simpler since the complicated key management software would be included in the authenticator and therefore not duplicated. There was concern that if the interface to the authenticator--in both hardware and software--was not simple, it might be unusable. This required that messages relating to key management be passed into and out of the authenticator, and led to the following chip interface specifications:
Address Offset |
Read |
Write |
0 |
Status | Byte-to-authenticate |
1 |
Low-byte authenticate value | |
2 |
High-byte authenticate value | |
3 |
Data-in | Data-out |
4 |
||
5 |
||
6 |
||
7 |
Blank entries mean that a read or write function has not been assigned. A detailed address map is shown in Appendix A.
The author simulated Benincasa's algorithm on a PC to make sure he could understand it. This was done by comparing the simulated intermediate output provided by Benincasa to the results of the simulation. Benincasa's software was written in APL, the author's in FORTH.
Several meetings with NSA resulted in the directive that the algorithm be implemented in hardware, as opposed to software or a combination of both. The author then proceeded to decompose the algorithm functions, each of which could be contained on a reasonably sized printed circuit board.
The size of the TEMPEST container--and thus the authenticator boards--was constrained by the 5-3/8-in. diameter of the tube into which it had to fit. Room was needed for a cable run under the authenticator; thus, the end profile of the authenticator had to be D-shaped (the length could vary at this stage but the diameter could not).
The next decision was how to include the maximum number of logic chips in a minimum volume. The best method was the packaging used by IBM in the design of its personal computer. Main computer functions are included on a "mother" board. Edge connectors connect "daughter" boards to the mother board. This modular design of a parallel bus system allows us to use the inexpensive 31/2 edge connector.
A mother board was designed using the 80C31 microcontroller, which had local RAM, EEPROM, and I/O space, and fits in the bottom of the D-space. The 80C31 was selected because it was the smallest low-technology processor available that could perform the functions required by the authenticator. One critical function is a high-speed synchronous serial communications link, required
[9]
to load keys into the shift register. Another consideration was that SNL build a radiation-hardened version of the 80C31.
The next step was to select the container. High reliability was required, coupled with low cost in a low-vibration environment. Experts with access to connector reliability data were consulted. As a result, a semi-bellows 31/2 edge connector was selected. This connector is sometimes used in the IBM PC/XT, although more frequently a cantilever beam version is used; the two are interchangeable. The semi-bellows connector has greater mating force.
The TEMPEST container was designed next. Understandably, there were overlaps in time in performing these tasks, but this narrative presents them in an approximate order. A primary objective in designing the container, in addition to satisfactorily performing its intended function, was keeping its cost low. The TEMPEST container used on the previous unit had been machined from a block of aluminum, which had proved to be one of the authenticator's more expensive elements.
Construction methods that were considered included TIG-welded tubing, extrusions, die casting, and rubber-plaster casting. Rubber-plaster casting was selected because of the low cost of the tooling and parts, and the easy evolution to die casting in the event we later required higher volumes. The tool cost was approximately $5000, with an eventual three-piece part cost of approximately $330 for quantities of ten or more. This included the secondary machining and epoxy vacuum filling of the porous aluminum casting.
A conductive glue (Tracon) was used to epoxy together the three-piece TEMPEST container. Glue has very low tensile strength, but high shear strength. The design of the shear surface was such that the electronics could be removed only by machining off the container once it had been joined and cured.
Figure 1 shows a TEMPEST enclosure. The parallel interface connector is located in the recessed face of the container to protect it against mechanical stress. Two authenticators are stacked end to end. The second section of the container is the "vestibule." It contains the TEMPEST rf filters and a dill valve, which is similar to an air valve on an automobile tire. The valve is used to evacuate the interior of the container, then backfill it to a slightly positive pressure with helium. The container is then epoxied shut. Appendix B shows mechanical drawings of the TEMPEST container.
[Image 46K] Figure 1. Artist's conception of the authenticator TEMPEST enclosure. |
[10]
Figure 2 shows authenticator PC boards protruding from the TEMPEST enclosure. The top interconnect board was needed because there were not enough interconnect paths on the mother board. A connector with more slots would have made the unit longer, and this would have prohibited the use of the cost-saving PC/XT connector.
[Image 60K]
Figure 2. Artist's conception of the printed circuit card assembly
|
There are seven connectors on the mother board and three on the top interconnect board. Observe also that chips are shown at the bottom of the interconnect board. None appear on the final authenticator. This space was reserved for any additional chips that might be needed. The board spacing, which was to have been the same as on the Regional Seismic Test Network (RSTN), is 1/2 in. on center.
The next step was to design the circuit cards essential to execute the algorithm. The goal was to separate the algorithm by function and have each board near filled to capacity. Details of the design are presented later in this report.
Manila envelopes were cut to the same size as the PC cards. The computer chips were laid over them to ensure they would fit. The mother board was designed first. Foam versions of the boards were cut and the chips were fastened to them. When the PC board layout of the mother board was completed, an additional inch was required for interconnect wiring (6 to 7 in.), even though all of the chips fitted on the foam mother board.
The authenticator PC board assembly is suspended in the TEMPEST container. Because the container is conductive, care must be taken not to short out the electronics. The least expensive technology for the supports proved to be glass-reinforced polycarbonate plastic. The author designed the load/thrust bearing parts, and Charles Kirk (Precision Molded Concepts) refined the drawings for production (Figures 3 and 4), built the mold (Figure 5), and shot the parts. Endplate pins hold the cards vertically. A molded pin at the top of each slot on the endplate was mated into a recess at the end of each PC card. This prevented the cards from leaving the connectors.
[11]
[Image 82K]
Figure 3. Polycarbonate-glass endplate used with authenticator. Note
the molded |
[12]
[Image 49K]
Figure 4. Polycarbonate-glass load/thrust bearing pieces. The TEMPEST container
|
[13]
[Image 76K]
Figure 5. Photograph of the injection mold die for the load/thrust
bearing pieces |
To ensure that all parts of the authenticator package were finished at about the same time, design and construction of the TEMPEST container and the plastic supports was started before the construction of the PC boards. There was risk, of course, that the authenticator would not fit into its container. But there were two hedges to this risk: (1) additional space had been reserved for electrical components on the underside (and possibly even the top side) of the top interconnect board; and (2) programmable array logic chips could be used to reduce the chip count, if necessary, to reclaim space.
A general unclassified diagram of the seismic algorithm is presented in Figure 6. One design goal was to keep the hardware unclassified because the authenticator is deployed at unmanned test sites. This is accQmplished by building a hardware device capable of executing numerous authentication algorithms, including classified codes. The computer hardware itself is not classified. The system becomes classified only when it is operating, or contains remnants of, classified information.
[14]
[Image 44K]
Figure 6. Diagram of the data authenticator algorithm structure. The
algorithm is |
The NSA R register feedback function is classified. For each data bit processed, both the F and R registers are stepped multiple times. The number of steps is classified. All remaining parts of the algorithm are unclassified. The output from the R shift registers is used as address lines into a fast static CMOS 16Kx1 RAM. The output of the RAM is fed back into the R register. The boolean feedback function is loaded into the static RAM under the control of an 80C31 microcontroller; the step value is loaded into a latch under the software control of an 80C31 microcontroller. The classified aspects of NSA's algorithm reside in software.
The data authenticator is its own development system. It hosts an operating system, compiler, assembler, and full-screen editor. The only development tools required are a personal computer, a logic probe, and (infrequently) an oscilloscope. The authenticator software is designed to be given in its entirety to any treaty participant; thus, all software used is in the public domain. SNL's operating system is FORTH.
A personal computer is connected, via a serial port, to a daughter board called a Maintenance Support Board. This board contains either a 32Kx8 EPROM or EEPROM. This board also contains a National 82C50 Asynchronous Communications Element, and contains the authenticator's operating system during hardware check-out and software development time. The board communicates both terminal and disk data over a serial port running at 19.2 kilobits.
A terminal/disk program that runs on a personal computer makes it possible for the user to log on to an authenticator. When this program is running, the authenticator takes keyboard input from the PC and outputs data to the PC screen. The authenticator can also read or write from a single-disk file located on the PC. The easiest way to show how an authenticator works is by example; therefore, the author will log on to the authenticator and give some examples. Borland's SideKick is used to capture
[15]
screen output from the authenticator into a note file. This note file is read into this report. After the terminal emulator program is entered and the authenticator is powered, the logo will appear on the screen.
| 8051 televideo 910 terminal emulator |
| Authenticator 8051 series microcontroller ROMed DOS MC 2.2 19.2 kbs, rts, cts flow control Version 1.412/33/89 09:42 |
| ok |
The first line on the screen is printed by the terminal emulation program. The lines beginning with "Authenticator" are from the authenticator.
The following shows an example for making interactive calculation 2 plus 3 and printing the result; compiling and running an interactively entered program that prints out the indices of a loop counter; and assembling and testing an interactive assembler routine.
2 3 + . 5 ok : X 5 0 DO I CR . LOOP ; X 0 1 2 3 4 ok CODE Y GETSP, A # 9 MOV A0PUSH, END-CODE Y . 9 ok
A book by William H. Payne (the author of this report), Embedded Controller FORTH For the 8051 Family (Academic Press, Inc.; Harcourt, Brace, and Jovanovich, 1990) contains all the details of the operating system.
Authenticator applications software was entered interactively from disk files and debugged. The software was then combined with the operating system. The operating system plus the application code was metacompiled and ROMed. The examples using the authenticator boards are invoked from ROMed code.
Examples of each of the authenticator's daughter boards will be demonstrated from the keyboard to show how the hardware operates. The authenticator I/O bus closely resembles the PC/XT. Because the authenticator uses the 80C31 instead of the 8086/88, pin definitions are not exactly the same. Pins not used by the 80C31 are used for authenticator-specific functions. Here is the internal bus definition:
[16]
5/09/89 whp
AUTHENTICATOR INTERNAL BUS
i/o pin signal name i/o i/o pin signal name i/o
Al -RD&-PSEN o *Bl F out i/o
A2 D7 i/o B2 RESET i/o
A3 D6 i/o *B3 V out i/o
A4 D5 i/o +B4 -INTO P3.2 i/o
A5 D4 i/o +B5 P1.1 Poll req i/o
A6 D3 i/o *B6 Clk FR i/o
A7 D2 i/o ^B7
A8 D1 i/o +B8 P1.4 i/o
A9 D0 i/o ^B9
A10 -PSEN o +B10 P1.6 i/o
All -FF o +Bll -WR P3.6 i/o
+A12 P1.0 clr int0 i/o +B12 -RD P3.7 i/o
+A13 P1.2 Soft busy i/o +B13 P3.0 RxD i/o
+A14 P1.3 i/o +B14 P3.1 TxD i/o
+A15 P1.5 i/o *B15 Clk DV i/o
A16 A15 o *B16 Step i/o
A17 A14 o *B17 D+V i/o
A18 A13 o *B18 Osc Busy i/o
A19 A12 o +B19 P1.7 IntO in i/o
A20 A11 o +B20 P3.4 TO i/o
A21 A10 o *B21 GO i/o
A22 A9 o *B22 R int i/o
A23 A8 o *B23 F int i/o
A24 A7 o *B24 V int i/o
A25 A6 o +B25 -INT1 P3.3 i/o
A26 A5 o +B26 -RAM Osc offline
A27 A4 o +B27 -ROM maintenance support
A28 A3 o B28 ALE o
A29 A2 o B29 +5 Vdc power
A30 A1 o +B30 P3.5 T1 i/o
A31 A0 o B31 GND ground
* no termination on motherboard
+ jumpered on motherboard
^ not used on battery powered motherboard
[17]
The external bus is the top interconnect board connection. Its pin definition is:
02/08/89 whp AUTHENTICATOR EXTERNAL BUS i/o pin signal name i/o i/o pin signal name i/o XA1 XD7 i/o XBl D reg/status i/o XA2 XD6 i/o XB2 XA3 XD5 i/o XB3 R1 XA4 XD4 i/o XB4 RO XA5 XD3 i/o XB5 XA6 XD2 i/o XB6 Data in/out XA7 XDl i/o XB7 XA8 XDO i/o XB8 XA9 XAO i XB9 XAlO xAl i XB10 XAll XA2 i XBll XA12 -XCS i XB12 XA13 -xRD i XB13 XA14 -XWR i XB14 XA15 XRESET i XB15 XA16 Outl o XB16 XA17 Out2 o XB17 XA18 XB18 XA19 XB19 XA20 XB20 XA21 XB21 XA22 XB22 XA23 XB23 XA24 XB24 XA25 XB25 XA26 XB26 XA27 XB27 XA28 XB28 XA29 XB29 XA30 XB30 XA31 XB31
The F register is a 63-bit linear feedback shift register built with parallel-out, high-speed CMOS chips. It is contained on a single card. The shift register clock and data-in inputs are multiplexed so that the shift register can be clocked from software. The FORTH command FEXT selects the software clock. FINT selects the hardware clock. ONE places a logic 1 at the input to the register; ZERO places a logic 0 at the input. CLOCK is defined: CLOCK--CLK CLK ;. CLOCK drops the clock input to the register low, then high. This causes the input to be shifted one position to the right. The command CLRF clears the F register. Following is a dialog with an authenticator placed just left of the keyboard while the author is writing this report. .F prints a copy of the F register.
[18]
F Register x is the unused 64th bit of the linear feedback shift register 6 5 4 3 2 1 0 210987654321098765432109876543210987654321098765432109876S43210x 0100000000000000000000000000000000000000000000000000000000000000ok CLRF ok 6 5 4 3 2 1 O 210987654321098765432109876543210987654321098765432109876543210x OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOok FEXT ok ONE CLOCK ok F Register x is the unused 64th bit of the linear feedback shift register 6 5 4 3 2 1 0 210987654321098765432109876543210987654321098765432109876543210x 1000000000000000000000000000000000000000000000000000000000000000ok CLOCK .F F Register x is the unused 64th bit of the linear feedback shift register 6 5 4 3 2 1 0 210987654321098765432109876543210987654321098765432109876543210x 1100000000000000000000000000000000000000000000000000000000000000ok ZERO CLOCK .F F Register x is the unused 64th bit of the linear feedback shift register 6 5 4 3 2 1 0 210987654321098765432109876543210987654321098765432109876543210x 0110000000000000000000000000000000000000000000000000000000000000ok CLOCK .F F Register x is the unused 64th bit of the linear feedback shift register 6 5 4 3 2 1 0 210987654321098765432109876543210987654321098765432109876543210x 0011000000000000000000000000000000000000000000000000000000000000ok ONE CLOCK .F F Register x is the unused 64th bit of the linear feedback shift register 6 5 4 3 2 1 0 2109876543210987654321098765432109876S4321098765432109876543210x 1001100000000000000000000000000000000000000000000000000000000000ok
This demonstration shows that some of the F registers appear to work properly. Diagnostics can be interactively written or run in a batch mode to isolate faults quickly.
Appendix C presents the F register schematic.
The V register is a 16-bit circular shift register. Serial input permits loading using the 80C51 Mode O synchronous serial expansion communications. Parallel read-out on the bus allows the user to verify that the load matches the read-out. The clock is multiplexed between software and a crystal oscillator. Below is a demonstration of the V register operation, taken directly from an authenticator onto the same screen and used to write this report. CLRV clears the contents of the V register. ONE places a 1 at the V register input; ZERO places a 0 at the input. CLOCK drops the multiplexed input to the shift register low, then high. VEXT selects the software clock, and VINT selects the hardware oscillator.
[19]
CLRV ONE CLOCK .V V Register 1 0 5432109876543210 1000000000000000ok CLOCK .V V Register 1 0 5432109876543210 1100000000000000ok ZERO CLOCK .V V Register 1 0 5432109876543210 0110000000000000ok ONE CLOCK CLOCK CLOCK ZERO CLOCK CLOCK ONE CLOCK CLOCK .V V Register 1 0 5432109876543210 1100000000000000ok
The hardware state sequencer supplies clocks to the authenticator hardware logic. The clock to the state sequencer is multiplexed so that it can be "single-stepped" from software, run at full software speed, or run from a hardware crystal oscillator. The speed of operation of the state sequencer requires the use of several advanced CMOS logic chips instead of the high-speed CMOS.
The history of the state sequencer is informative. Its design, prototype, and the initial tests were all subcontracted. The subcontractor implemented the circuit using only a crystal input; the design was implemented on an authenticator daughter board. The oscillator was routed to a port pin on the mother board 8051. The subcontractor's design contained a logic fault, however, that could not be easily fixed. The author had to redesign the circuit and order high-speed CMOS parts. L. vanBlaricum (SNL) found that the oscillator frequency could be halved by changing only one wire. This improvement was incorporated into the design.
The state sequencer is complicated from the standpoint of (1) making it produce the right clocks transitioning on the correct edges, and (2) stopping. The sequencer is designed to produce full clocks (no partial clocks) without skew. The faster it runs, the more difficult it is to produce the final clock, and then stop. HC74's run at only half their rated speed. Before vanBlaricum's improvement, clock pulses were rounded off at frequencies above 10 MHz.
Appendix D is a schematic of the V register and state sequencer. The number of steps for each bit is stored in the software's loaded latch (U20, an HC374). This number can range from 0 to 255.
Following is an example for loading '5' into the step latch, and printing the contents of the latch. '7' is then loaded into the latch and the contents are verified by reading and printing, which is done by the command .STEP.
| 5 STEP C! .STEP 5 ok 7 STEP C! .STEP 7 ok |
The contents of the state sequencer can be read on the 80C51 bus. The command .OSC does this. S stands for Step, 8 for divide by 8, 3 for divide by 32, and B is the "busy" bit that indicates that the oscillator is busy. Following is an example of the state sequencer in its initialized state:
| S83B 1110ok |
[20]
The state sequencer can be exercised from software in either a static mode or at full software speed. Below is a program that the author entered from the screen employing vanBlaricum's modified state sequencer:
: T INITOSC OSC -OSC .OSC SGO CR (.OSC) BEGIN -CLK CR (.OSC) CLK CR (.OSC) PCEY 27 = IF QUIT THEN AGAIN ; ok
INITOSCR initializes the state sequencer by setting the step to 32. OSC connects the hardware oscillator to the state sequencer, which causes it to return to an initialized condition.--OSC connects the software clock to the state sequencer. .OSC prints the state of the state sequencer. (.OSC) prints the oscillator state without CRs. SGO gives a start pulse to the state sequencer. Writing a byte to be authenticated does the same function when the hardware oscillator is connected. --CLK drives the clock low; CLK drives it high. CR is a carriage return. The program continues until the escape key (hex lB, decimal 27) is keyed.
Following is the first part of the sequence when the program is invoked:
T S83B 1110 1111 1111 1111 1101 0011 0001 0111 0101 0111 0101 0111 0101
The output below from the state sequencer shows it clocking the data and setting the step gate:
0101 0111 0101 llll 1101 0011 0001 0111
The vanBlaricum clock differs from the original in that all clock inputs are held high and the clock to be pulsed is given a single high-low-high pulse. Note that the--CLK - CLK sequences are used as commands to exercise the modification. The original clock is used on CLOCK commands (: CLOCK --CLK CLK ;). The original clock, however, operates at twice the frequency. Four authenticators (deployed) have been authenticating about 1900 bytes per second for 1-1/2 years with no observed
[21]
failures (there are other authenticators in the field; memorandums addressing the field record are presented later in this report). No problems with the state sequencer have been observed.
The R register is a 14-bit boolean feedback shift register. NSA's feedback function for the R register is classified. This R register takes the output of two serial-in, parallel-out shift registers as address inputs into fast (20 ns) 16Kx1 static RAM. The boolean function output is the data bit out. The static RAM is filled by loading the R register's serial input with the address of the bit to be accessed. One can write to the RAM by decoding a location in I/O space.
There are 2**14 possible R register feedback functions.
The R register occupies an entire daughter board. Appendix E shows the schematic of the R register.
The contents of the R register are loaded with the command TOR (to R) and printed with the command .RREG. The state sequencer oscillator must be disconnected before setting the R register. Following are several examples for setting the R register:
1 TOR ok .RREG R Register 1 0 54321098765432xQ 0000000000000101ok 2 TOR .RREG R Register 1 0 54321098765432xQ 0000000000001001ok 4 TOR .RREG R Register 1 0 54321098765432xQ 0000000000010001ok
Note that the bits are shifted two places to the right. This is because only the high-order 14 bits are used (see U13 on the schematic). The column labeled 'Q' is the output of the RAM (see pin 17, U14). The column labeled 'x' is always 0 since it is tied to ground (pin 15, U14).
The contents of the static RAM are dumped with the command DRAM, which requires Start Address/Length as arguments. Following is an example for dumping the first 100 locations, starting at location 0.
0 100 DRAM 0110011111101100111100111011100001001101101100111111111111000000 110010011110011101001111000100001111 ok
Now, we have an example of storing a '1' to location 0, fetching location 0, and printing it. The first 10 locations are dumped.
1 0 !RAM 0 @RAM . 0 10 DRAM 1110100101 ok
The same operations are repeated, except that a '0' is stored.
[22]
1 0 !RAM 0 @RAM . 0 10 DRAM 0 1110100101 ok
The static RAM is zeroed with the command ZERORAM. Following is an example:
ZERORAM ok 0 100 DRAM 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000 ok
The static RAM was tested with the RT command by writing 0's and 1's to it. The RAM was read to see if the results are correct. Following is an example:
RT 0 1 2 3 4 5 6 7 8 9 10 11 ok
The column number identifies the location in memory. If an error occurs, a message identifies a "bad one" or a "bad zero."
Using a fast-column static RAM to hold the feedback function was sufficiently risky to justify wire-wrapping and testing it before building a board.
The functions of the bus decode board are to route the authenticator input and output signals to the authenticator bus; provide overvoltage protection, some power filtering, added pull-up resistors (vanBlaricum), and Schmitt-trigger input buffers (vanBlaricum) so that the authenticator can work reliably at the end of approximately 15 ft of cable at the Receiving and Monitoring Station. The added pull-ups and Schmitt trigger buffers were not included in an earlier version of the board. Appendix F shows the schematic of the bus decode board.
The command/status board stores the data byte to be authenticated, gives output status, buffers a data message input byte, holds a data message output byte, and contains the interrupt hardware. Appendix G shows the schematic for the command/status board.
The data byte to be authenticated is held in the D register. This is the source of Data Bits in Figure 6. This is an HC165 parallel-in, serial-out shift register (chip U2). A 'write' to the D register (offset 0) triggers the authenticator to perform a 'hardware authenticate'.
[23]
The command .IS prints the contents of the status register internal to the authenticator. The status register can also be read externally through the connector. Following is an example:
| Internal bus status 1 D register 0 Watchdog time-out 0 Data out ready 1 Software busy 1 Poll Micro 1 INT1 0 INT0 1 Osc busy ok |
The D register.can be taken off-line so that it will not accept a byte through the external connector. The command to disable the D register is DEXT; the command to enable it is DINT.
A '1' in the 'watchdog time-out' means that the authenticator watchdog timer timed out and was not reset by the 80C31.
In 'data-out ready' a '1' means that the authenticator wrote a byte to the outside world and that it has been read through the connector. This bit is cleared when the data is read through the external connector.
'Software busy' and 'Poll Micro' are an 80C31 software set bit to indicate the status of the authenticator software. They are controlled by the FORTH command SB (set),--SB (clear), SPOLL (set), and--SPOLL (clear).
'INT1' set means that a byte has been written to the authenticator from the outside world through the connector. It is cleared when the authenticator 80C31 reads the byte.
'INT0' set means that a frame start is requested from the outside world. When this is set, the 80C51 executes an INT0 interrupt and loads the current key into the R and V registers with a 1-megabitper-second serial (Mode 0) load.
The 'OSC busy' set indicates that the state sequencer has been activated but is not done. 'OSC busy clear' indicates that the authenticator is ready to accept a byte (providing the D register is connected, status bit clear).
The watchdog board contains the watchdog timer. If the timer is activated and times out, it performs a hardware reset on the 80C31. The board also contains a piezoelectric buzzer, six light-emitting diodes (LEDs), and a battery backed-up real-time clock calendar.
NSA hardware and software guidelines state that the cryptographic device should give clear audio and visual indications that it has passed the self-test. The buzzer and LEDs perform this function.
A record of key manipulation activities requested from the outside world consists of date/time stamped. The authenticator can be interrogated for a history of activity. An example of screen output response to the command SHOWTIME is:
| Wednesday 09/04/91 02:20:28 pm |
The authenticator used to write this report has been unpowered for about six months. The clock was not trimmed, but the authenticator still responded with the correct date within 10-minute accuracy. The date/time stamping resolves conflicts regarding what commands were sent to the authenticator at what time.
Software or hardware faults can cause a processor to "hang" in an unending loop. The watchdog timer's function is to correct software upsets. The code
1 $: SCON 1 $ JNB
[24]
could lead to an endless loop. The watchdog, however, will time out and reset the processor. This would bring the processor out of the loop. The watchdog timer is implemented with a serial-in, parallel-out shift register. The input is a '1'. The '1' is shifted slowly to the right. The watchdog shift register is cleared by writing to it. If it does not receive a 'clear' by the time a '1' is shifted to the far right position, the watchdog resets the 80C31.
The word FIDO exercises the watchdog timer. In the example, FIDO is typed and the watchdog timer times-out. Two final zeros are printed. The reason for this is that the 1's are shifted at a frequency of 1 ms and reset was entered before the first two 1's were printed. The time-out invokes a hardware reset so that the cold start logo is printed.
| Watchdog Timer Demo Hit a key to reset the dog or ESC to stop the dog 11111100
Authenticator ok |
The authenticator beeps at different frequencies and durations as it proceeds through the power-on reset. It also turns off its LEDs in order. If this does not occur, it is likely that the authenticator has not successfully completed initialization. The authenticator gives positive acknowledgment of successful initialization.
A schematic of the watchdog timer board is presented in Appendix H.
The mother board contains an 80C31, a 32Kx8 EEPROM, 32Kx8 byte RAM, and address-mapped 256 I/O locations. --PSEN and --RD are ANDed together to combine the code and data spaces. EEPROM--RD,--WR, and --CS are jumpered. Software can be transferred from a PC through its serial port to EEPROM soldered on the mother board. When the transfer is complete, EEPROM --WR can be tied high, disabling further "writes" to it.
Details of the mother board are included in the author's book, Embedded Controller FORTH For the 8051 Family (Academic Press; Harcourt, Brace, and Jovanovich, 1990).
Appendix I shows the schematic of the mother board.
The maintenance support board contains 32Kx8 bytes of either EEPROM or EPROM. The type of ROM is jumper-selectable. The board also contains a National 82C50 access control element for serial communication to a PC. A Maxim 5-volt-only 235 is used for line drivers and receivers. The schematic for this board is in Appendix J.
The authentication keys are contained in a 32Kx8 byte EEPROM or 64Kx8 EEPROM board. 'Bulk memory erase' is implemented in both voltages to erase the memory, whereas the 64K needs only + 5.
In the event of a 'tamper detect', the downhole logic unit sends a command to the authenticator that causes it to bulk-erase the keys. The only 'tamper detect' is a microswitch closure that indicates that the authenticator is being lifted from its borehole.
[25]
Following is an example of the operation of the 32K board. INITEE initializes the logic for controlling the power to the chip. A DC-DC converter and analog switches are required to control the power to the chip. Locations 0 to 100 of the EEPROM are dumped.
INITEE 0 100 EDUMP 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0 02 00 54 02 80 64 00 00 02 00 00 02 80 67 00 00 ..T..d.......g.. 10 02 00 00 02 80 6A 00 00 02 00 00 02 80 6D 00 00 .....j.......m.. 20 02 00 00 02 80 70 00 00 02 00 00 02 00 75 01 03 .....p.......u.. 30 00 OE 44 06 00 08 F6 B6 F5 B6 F6 B6 F5 B7 00 1F ..D............. 40 00 00 80 73 80 73 3E 4D 00 05 B2 B5 F5 B6 F6 B6 ...s.s>M........ 50 F6 B6 23 5B 75 81 2F 90 00 4C EO FC A3 EO FD 90 ..#[u./..L...... 60 00 4E En FE A3 EO FF 90 00 52 E5 82 FB E5 83 FA .N.......R...... ok
The memory has an additional 64 bytes for tracking the part's use. This memory is dumped using the EEDUMP verb. This is an example:
0 10 EEDUMP 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 7FC0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 7FD0 1B FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 7FE0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 7FF0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ ok
The chip is erased with the ECHIP command. Here, we have an example of the dump, after erasure, of the first hex 100 bytes of the part:
ECHIP ok 0 100 EDUMP 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 10 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 20 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 30 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 40 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 50 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 60 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ ok
The following is an example of programming the part with a '3' in location 3.
3 3 EC! ok 0 10 EUDUMP 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0 FF FF FF 03 FF FF FF FF FF FF FF FF FF FF FF FF ................ ok
[26]
The 64K FLASH board is bulk-erased with the following code. The code sequences are internally processed by the FLASH memory to complete the erase.
HEX CODE ECHIP0 DPTR # EEPROM MOV A # 55 MOV @DPTR A MOVX DPTR INC A # 55 MOV @DPTR A MOVX DPTR INC A # 0AA MOV @DPTR A MOVX DPTR # EEPROM MOV A # 2A MOV @DPTR A MOVX DPTR INC A # 0AA MOV @DPTR A MOVX DPTR INC A # 055 MOV @DPTR A MOVX DPTR # EEPROM MOV A # 55 MOV @DPTR A MOVX DPTR INC A # 55 MOV @DPTR A MOVX DPTR INC A # 80 MOV @DPTR A MOVX DPTR # EEPROM MOV A # 55 MOV @DPTR A MOVX DPTR INC A # 55 MOV @DPTR A MOVX DPTR INC A # 0AA MOV @DPTR A MOVX DPTR # EEPROM MOV A # 2A MOV @DPTR A MOVX DPTR INC A # 0AA MOV @DPTR A MOVX DPTR INC A # 055 MOV @DPTR A MOVX DPTR # EEPROM MOV A # 55 MOV @DPTR A MOVX DPTR INC A # 55 MOV @DPTR A MOVX DPTR INC A # 10 MOV @DPTR A MOVX NEXT LJMP END-CODE HEX CODE ECHIP1 DPTR # EEPROM MOV A # 55 80 OR MOV @DPTR A MOVX DPTR INC A # 55 MOV @DPTR A MOVX DPTR INC A # 0AA MOV @DPTR A MOVX DPTR # EEPROM MOV A # 2A 80 OR MOV @DPTR A MOVX DPTR INC A # 0AA MOV @DPTR A MOVX DPTR INC A # 055 MOV @DPTR A MOVX DPTR # EEPROM MOV A # 55 80 OR MOV @DPTR A MOVX DPTR INC A # 55 MOV @DPTR A MOVX DPTR INC A # 80 MOV @DPTR A MOVX DPTR # EEPROM MOV A # 55 80 OR MOV @DPTR A MOVX DPTR INC A # 55 MOV @DPTR A MOVX DPTR INC A # 0AA MOV @DPTR A MOVX DPTR # EEPROM MOV A # 2A 80 OR MOV @DPTR A MOVX DPTR INC A # 0AA MOV @DPTR A MOVX DPTR INC A # 055 MOV @DPTR A MOVX DPTR # EEPROM MOV A # 55 80 OR MOV @DPTR A MOVX DPTR INC A # 55 MOV @DPTR A MOVX DPTR INC A # 10 MOV @DPTR A MOVX NEXT LJMP END-CODE : ECHIP ECGIP0 ECHIP1 ;
[27]
The schematic for the 32Kx8 board is presented in Appendix K; the schematic for the 64Kx8 board is in Appendix L.
The authenticator contains seven edge connectors on the mother board. All are used during the operation of the mother board. In order to have room to plug in the maintenance support card, a bus extender card containing three additional edge connects was built. The expansion card has two edge connections on either end. This permits it to be inserted into either end of the mother board--the A side or the B side. The schematic for this board is presented in Appendix M.
The external bus exerciser is a board that simulates the proper external interface to send commands to an authenticator. It plugs into the mother board of an authenticator. One authenticator acts as the external interface to another authenticator. In this way, the authenticator interface can be checked for proper operation. The schematic of this board is presented in Appendix N.
The "de-authentication" or authentication verification requires that the receiver process an incoming data frame and compare its computed authentication value with that in the received frame. Receiver station computers will generally be in machines having the larger bus architecture. Therefore, the author helped design four authenticators to a VME bus card. Bill Holloway and Don Baril (VME, Inc.) designed the interface. A bare card is seen in Figure 7. The cara, on the VME side, has been debugged and is waiting for the authenticator side to be debugged. The board, which meets IEEE 1014 specifications, is jumpered to meet previous revised (IACKIN not before IACK at interrupter) standards. The board fits in a 6U slot. The schematic is shown in Appendix O.
An IBM PC/XT-to-authenticator interface card was designed for the purpose of (1) deauthenticating PC hosts; (2) keying authenticators; and (3) testing authentications with inexpensive PCs. Additional buffering and pull-up resistors were added to help drive through authenticator TEMPEST filters. De-authentication does not usually require that an authenticator be housed in its TEMPEST enclosure. A photograph of the board is seen in Figure 8. Wait state logic was included. The current authenticator requires no additional wait states, but a future single-chip authenticator may; therefore, wait state logic was included for future use. The board schematic is shown in Appendix P.
Authenticator addresses are assigned as the cards are tested. Appendix Q gives the address assignments. Address selection is determined by jumpers.
Messages may be sent to or received from the authenticator by reading or writing data bytes. Appendix R gives the formats of the message read or written to the authenticator. Each message written to the authenticator must include a CRD-16 checksum.
The test source code includes the FORTH operating system. If a failure occurs, a maintenance support board can be plugged into the device and the operating system used to find the problem. This code is in a form that can be processed by Sandia's Nautilus 2 metacompiler.
Final code involves removing all of the code not referenced by the application and including hardware diagnostics (not part of this report). Some classified code can be added. This source is metacompiled to produce a minimum-sized binary image. The test source code is shown in Appendix S.
[28]
[Image 261K] Figure 7. Four authenticators to VME U6 bus card. |
[29]
[Image 221K]
Figure 8. Authenticator-to-PC/XT bus interface card. Additional |
[30]
Figure 9 shows an authenticator in its TEMPEST enclosure. A disassembled authenticator is shown in Figure 10. The TEMPEST enclosure is made up of three parts: the cap, the vestibule, and the body. The vestibule contains TEMPEST rf filters and Dill values for evacuating and backfilling the body with helium. The aluminum enclosure was epoxy-treated in a vacuum to eliminate porosity and hold the helium. The approximate cost of the TEMPEST enclosure, including secondary machining and epoxy fill, is $330 in quantities of ten. The length of the unit is 10-1/2 in.; its diameter is 5-3/8 in.
[Image 45K]
Figure 9. Data authenticator TEMPEST enclosure. The three pieces of
|
[Image 34K] Figure 10. Disassembled authenticator. |
[31]
Figure 11 shows an authenticator ready to undergo testing. The maintenance support board is inserted in a bus extender. Figure 12 shows an authenticator-to-authenticator interface card and cable. This card is used to simulate a proper downhole logic hardware interface and checks out authenticators through the connector.
[Image 178K]
Figure 11. Authenticator with bus extender and maintenance support
|
[32]
[Image 145K]
Figure 12. Authenticator-to-authenticator bus card and cable. This
card |
[33]
Two SNL memos (Figures 13 and 14) document the field record of authenticators deployed to date.
Sandia National Laboratories
|
[34]
Sandia National Laboratories Figure 14. Memo dated September 11, 1991.
|
[35]
The layout of the authenticator algorithm's processing hardware is similar to that of a computer chip--specifically, an Intel 82C55A programmable peripheral interface chip but it is implemented with the discrete CMOS logic chips. Two university professors took the authenticator algorithm design and silicon-compiled the design using the GENESIL compiler. This design included the F, V, R, D, and state sequencer (osc) seen in Figure 15.
[Image 63K]
Figure 15. Architecture of authenticator. The silicon compiled chip
|
The chip is shown in Figure 16; the associated floor plan is shown in Figure 17. This work began about the same time as the construction of the authenticator described in this report. Sandia Labs needs a small, low-power, high-peformance authenticator for such applications as video authentication. The present authenticator is specifically designed for seismic applications: it authenticates about 20,000 bytes per second and can be modified to run faster. It draws 200 mA when operating at full speed. This includes the 80C31 microcontroller mother board, EEPROM, and the watchdog, clock. and calendar boards.
Simulations using the silicon compiler show the estimated power consumption to be 250 mA. Lack of capability to eliminate unneeded transistors using the silicon compiler caused the power consumption to be unacceptably high.
The author found several deficiencies in NSA's algorithm. These were reported to the Agency in a June 21,1989, draft memorandum (Appendix T). NSA designed a new data authentication algorithm that eliminated many of the problems associated with the old algorithm.
[36]
[Image 137K] Figure 16. Silicon compiled chip of the algorithm portion of the authenticator. |
[37]
[Image 133K] Figure 17. Floor plan of the silicon compiled authenticator. |
[38]
Work on the silicon-compiled chip has been halted. Another chip construction technology that applies to the new algorithm appears to be the best strategy for building a high-speed, low-power authenticator chip.
[39]
[40]
Authenticator Address Map Address Offset
Frame Start is initiated by writing any byte value to offset 6. |
[41-42 not provided]
[Image 125K] Technical drawing: Container vestibule - Item 2 - Authenticator TEMPEST
[Duplicate of 43; 44 not provided]
[45]
[Image 59K] Technical drawing: Container vestibule - Item 3 - Cap
[46]
[Image 91K] Technical drawing: Cap - Authenticator TEMPEST - Item 3
[47]
[Image 108K] Technical drawing: Authenticator TEMPEST Container
[48]
[Image 94K] Technical drawing: Enclsoure - Item 1 - Authenticator TEMPEST
[49; 50 blank]
[51-52]
[Image 171K] Technical drawing: F Register Decoder Board
[53; 54 blank]
[55-56]
[Image 173K] Technical drawing: V-Register and OSC Decode
[57; 58 blank]
[59-60]
[Image 172K] Technical drawing: R Register
[61; 62blank]
[63-64]
[Image 163K] Technical drawing: Bus Decode Board
[65; 66 blank]
[67-68]
[Image 160K] Technical drawing: Command Status Slave Decode
[69; 70 blank]
[71-72]
[Image 156K] Technical drawing: Watchdog Decode
[73; 74 blank]
[75-76]
[Image 161K] Technical drawing: Authenticator Motherboard Decoder
[77; 78 blank]
[79-80]
[Image 118K] Technical drawing: 5V Only Maintenance Support Bd.
[81; 82 blank]
[83-84]
[Image 150K] Technical drawing: Authenticator EEPROM Board
[85; 86 blank]
[87-88]
[Image 131K] Technical drawing: 5V 64K Byte EEPROM
[89; 90 blank]
[91-92]
[Image 154K] Technical drawing: Fabrication Drawing Authenticator Buss Expansion
[93; 94blank]
[95-96]
[Image 93K] Technical drawing: Authentication External Bus Exerciser
[97; 98 blank]
[99]
[Image 92K] Technical drawing: No title.
[100]
[Image 70K] Technical drawing: No title.
[101]
[Image 109K] Technical drawing: No title.
[102]
[Image 92K] Technical drawing: No title.
[103]
[Image 136K] Technical drawing: No title.
[104]
[Image 108K] Technical drawing: No title.
[105; 106 blank]
[107-108]
[Image 210K] Technical drawing: Schematic Authenticator XT
[109]
[NSS Authenticator Addresses 12 K pages 110-122]
[123]
[Message Formats and Protocol 26 K pages 124-144]
[145]
[Test Source Code 57K pages 146-179; page 180 blank]
[181]
| This draft memorandum was circulated at NSA. No final copy was required. Sandia Labs received one new algorithm. |
[182]
DRAFT June 21, 1989 Dr. James J. Hearn Deputy Director for Information Security National Security Agency Fort &eorge G. Meade, MD 20755-6000 Dear Dr. Hearn: The National Security Agency provided an approved data authentication algorithm for the SALT II seismic verification program in the middle 1970's. It is called the National Seismic Station - Unmanned Seismic Observatory data authentication algorithmandis authored by Ronald Benincasa. The algorithm is currently being used for the Deployable Seismic Verification System. Data rates increased so the NSS-USO algorithm implementation technology is upgraded. The alogrithm continues to servewellfor this particular program. We considered using this approved algorithm for other treaty verification programs but it has severalmajordeficiencies which make it awkward to apply. These deficienciesareinclude: 1. The algorithm is bit oriented as opposed to byte, 16 bit word, 32 bit double word or 64 bit quad word oriented. 2. The algorithm requires stepping two of its internal registers at a rate many times the data rate. This limits the maximum rate at which data can be authenticated. 3. The algorithm, because of deficiency 2, is only suitable for implementation in hardware. 4. The hardware implementation requires too much hardware using low technology chips releasable to treaty participants. The device is too big and expensive. 5. The original algorithm specification was amended by NSA to handle resynchronization in event of data transmission errors. It requires additional information to be added to a data frame to preserve adequate security. DRAFT
[183] DRAFT 6. The algorithm is currently classified SECRET although its declassification to a level so its details can be given to the Soviet Union has been promised. 7. We expect to have data authentication applications with bilateral and multilateral treaties. We feel itisadvisable to use different algorithms for different treaties. We need a number of unclassified data authentication algorithms which which apply to different data widths and speeds. The algorithms should permit inexpensive implementation in small packages. I ask that NSA assist us by providing us these algorithms. Sincerely, TBD by DOE DRAFT To: Mark and Ed, R From: Bill FAX 505-846-6652 phone 505-844-6847 Tom read and approved this. We wait for your comments. When we all agree we'll forward this to Doug at DOE. cc Amy Johnston
[184]
DISTRIBUTION:
2 Air Force Technical Applications Center 3 Lawrence Livermore National Laboratory,
Att: F. Pilotte L205
G. Rothe Att: D. Harris
Patrick Air Force Base, FL 32925 K. Nakanishi
S. Taylor
1 University of New Mexico PO Box 808
Att: Prof. N. Ahmed, Chairman Livermore, CA 94550
Dept of Electrical & Computer Engineering
Albuquerque, NM 87131 2 University of New Mexico
Att: Dr. Donald R. Hush
2 Center for Seismic Studies Prof. Neeraj Magotra
Att: C. Romney Dept. of Electrical & Computer Engineering
S. Bratt Albuquerque, NM 87131
1300 N. 17th St., Ste 1450
Arlington, VA 22209 1 University of Central Florida
Att: Dr. Wasfy B. Mikhael
1 Pacific-Sierra Research Corp. Electrical Engineering Dept.
Att: Dr. A. P. Ciervo Orlando, FL 32816-0450
12340 Santa Monica
Los Angeles, CA 09925 1 Kaman Sciences Corp.
Att: Kenneth Sabisch
3 Defense Advanced Research Projects Agency 6400 Uptown Blvd. NE
Nuclear Monitoring Research Office Albuquerque, NM 87110
Att: R. Alewine
A. Kerr 1 Science Applications International Corp.
R. Blandford Att: T. Bache
1400 Wilson Blvd. 10210 Campus Point Rd.
Arlington, VA 22209 San Diego, CA 92121
1 Prof. Delores M. Etter 1 Arizona State University
3167 Nelson Rd. Att: Prof. A. S. Spanias
Longmont, CO 80503 Dept. of Electrical & Computer Engineering
Tempe, AZ 85287-5706
1 US Geological Survey
Att: Dr. J. F. Everenden 3 Teledyne Geotech
345 Middlefield Rd. Att: O. Starkey
Menlo Park, CA 94025 O. D. Stanley
R. Bartholomew
1 Southern Methodist University 3401 Shiloh Rd.
Att: Dr. Eugene Herrin Garland, TX 75040
Institute for the Study of Earth and Man
Geophysical Laboratory 3 US Dept. of Energy
Dallas, TX 75275 Office of International Security Affairs
Att: D. Dowen
M. Koontz
D. Larson
Forrestal Bldg., DP-52
1000 Independence Ave. SW
Washington, DC 20585
[185]
DISTRIBUTION (Continued):
2 USGS Albuquerque Seismological Laboratory 1 Atomic Weapon Research Establishment
Att: C. R. Hutt Att: Dr. P. Marshall
J. Peterson Blacknest
Bldg. 10002, Kirtland AFB East Aldermaston, Berkshire
Albuquerque, NM 87115 UNITED KINGDOM
2 Oregon State University 2 NFNT/NORSAR
Att: Dr. T. G. Lewis Att: S. Mykkeltveit
Prof. T. G. Lewis F. Ringdal
Computer Science Dept. PO Box 51
Corvallis, OR 97331 2007 Kjeller
NORWAY
4 National Security Agency
Att: Paul Bridge, U6 1 700 G. J. Simmons
Tom White, X431 1 5000 R. L. Hagengruber
Bruce Bottomly, S9 1 5023 J. R. Wayland Jr.
Mark Unkenholtz, R21 5 5031 W. H. Payne
9800 Savage Rd. 1 9100 R. G. Clem
Fort George G. Meade, MD 20755-6000 1 9123 J. Holovka
1 9236 P. B. Herrington
1 Digital Computer Laboratory 1 9240 P. A. Stokes
Att: Prof C. L. Liu 1 9311 S. D. Stearns
Computer Science Dept. 1 8523-2 Central Technical Files
1304 W. Springfield 5 3141 S. A. Landenberger
Champain-Urbana, IL 61801 3 3151 G. C. Claycomb
1 H. B. Durham
420 S. Fleishauer Ln
McMinnville, OR 97128
[End Report]