Note: Descriptions are shown in the official language in which they were submitted.
CA 02303297 2000-03-13
DEMANDES OU BREVETS VOLUMINEUX
LA PRESENTE PARTIE DE CETTE DEMANDE OU CE BREVET
COMPREND PLUS D'UN TOME.
CECI EST LE TOME DE ~
~
NOTE: Pour les tomes additionels, veuillez contacter le Bureau canadien des
brevets
--------------
JUMBO APPLICATIONS/PATENTS
TH1S SECTION OF THE APPLICATlON/PATENT CONTAINS MORE
THAN ONE VOLUME
THIS )S VOLUME OF
NOTE: For additional volumes =piease contact'the Canadian Patent Office
CA 02303297 2003-05-27
CR~GRAPHIC CO-PROCF5SCfR
COPYRIGHT ?V'OTICE
A portion of the disclosure of this patent document contains material which
is subject to copyright protection. The copyright owne; has no objection to
the
facsimile reproduction by anyone of the patent disclosure, as it appears in
the
Patent and Trademark Office patent files or records, but otherwise reserves
all
copyright rights whatsoever.
BACKGROL'ND OF THE INVENTION
Field Of The Invention
The present invention relates generally to a secure communication platform
on an integrated circuit, and more particulariy relates to a digital signal
processor
(DSP) with embedded encryption security features.
Description Of The Prior Art
Digitai signai processors (DSPs) are widely used in devices such as
modems, cellular telephones and facsimiles. With an increase in digital
communications, data transmission security has become an issue in numerous DSP
applications. A standard DSP is not capable ofproviding data transmission
security; thus, additional hardware and software are recluired.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Security tor digital communications is available on various integrated
circuits. The integrated circuit security features include hardware
implemented
encryption algorithms such as the Data Encryption Standard (DES), Hash
function
algorithms and hardware implemented public key accelerators. The availability
of
this hardware makes it possible to provide security for distributed computing;
however, no hardware implemented encryption algorithms have been known to be
incorporated in a DSP.
Software encryption algorithms have also been developed to provide
security for distributed computing. One commonly used encryption algorithm is
the Data Encryption Standard (DES). DES is a block cipher which operates on
64-bit blocks of data and employs a 56-bit key. Another commonly used standard
is the Digital Signature Algorithm (DSA). The DSA standard employs an
irreversible public key system. These algorithms and more are part of the
public
domain and are available on the Internet.
Hash function algorithms are used to compute digital signatures and for
other cryptographic purposes. One Hash function algorithm is the U.S.
government's Secure Hash Algorithm (SHA 1).
Another security standard commonly used is the Internet Protocol Security
Standard (IPsec). This standard provides security when communicating across
the
Internet. The standard requires DES to encrypt an Internet Protocol data
packet,
SHA-1 for authentication, and a public key algorithm for hand-shaking.
Since the IPsec standard requires different encryption algorithms, a
software library is usually created so that a desired algorithm may be
accessed
when needed. Security systems employing encryption libraries are software
implemented and designed specifically to run on the user's processor hardware.
Digital communication systems are not generally designed with security
hardware. In most systems, security is achieved by software, such as described
above, which is not entirely secure because there is no security hardware to
block
access to the security software by an intruder. Another problem associated
with
software encryption algorithms is that some of the software encryption
algorithms
run slower than when hardware implemented.
2
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
OBJECTS AND SUMMARY OF THE INVENTION
It is an object of the present invention to provide a digital signal processor
with embedded security functions on a single integrated circuit.
It is another object of the present invention to provide a secure
communications platform that can implement a user's application and dedicate
cryptographic resources to encryption and decryption requests on demand.
It is another object of the present invention to provide an increase in
encryption security through hardware implementations.
It is another object of the present invention to provide a security co-
processor for high speed networking products such as routers, switches and
hubs.
A cryptographic co-processor constructed in accordance with one form of
the present invention includes a processor having encryption circuits built
into it.
The processor is capable of processing various applications, such as modem and
networking applications. The encryption circuits and firmware make it possible
to
add security to the various processing applications. Hardware such as
encryption
and hash circuits are provided and structured to work together to provided
accelerated encryption/decryption capabilities. A memory is programmed with
cryptographic algorithms that support various encryption/decryption
techniques.
The cryptographic co-processor is structured so that a manufacturer of data
communication products could substitute a current processor with the
cryptographic co-processor and receive encryption capabilities with little
modification to the existing product.
Since DSP's are the building block of many communication systems, a
secured DSP with universal security features that may be selected by the
manufacturer of the equipment in which the DSP forms part of would have far
raaging benefits.
The benefits of a universal cryptographic co-processor (e.g., DSP) is that it
can perform standard processor functions and standard encryption functions
with
no peripheral hardware or cryptographic software. Because the cryptographic co-
3
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
processor is implemented on a standard processor platform (i.e., substrate or
monolithic chip), the processor that is being used in a manufacturer's product
can
be substituted with the cryptographic co-processor with little or no
modification to
the original design. The manufactured product incorporating the secure,
universal
co-processor now has encryption capabilities along with the original processor
capabilities.
A preferred form of the cryptographic co-processor, as well as other
embodiments, objects, features and advantages of this invention, will be
apparent
from the following detailed description of illustrated embodiments, which is
to be
read in connection with the accompanying drawing.
BRIEF DESCRIPTION OF THE DRAWING
Figure 1 is a block diagram of the cryptographic co=processor formed in
accordance with the present invention.
Figure 1 A is a block diagram similar to Figure 1 showing another view of
the cryptographic co-processor of the present invention.
Figure 2 is a block diagram of the program memory preferably used in the
co-processor of the present invention for MMAP=O.
Figure 3 is a block diagram of the program memory preferably used in the
co-processor of the present invention for MMAP=1.
Figure 4 is a block diagram of the data memory preferably used in the co-
processor of the present invention.
Figure 5 is a block diagram of the PCI memory preferably used in the co-
processor of the present invention.
Figure 6 is a block diagram of the DMA subsystem preferably used in the
co-processor of the present invention.
Figure 7 is a block diagram of the DSP "local" memory preferably used in
the co-processor of the present invention.
Figure 8 is a flow chart showing the DMA control preferably used in the
co-processor of the present invention.4
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
Figure 9 is a block diagram of the hash/encrypt circuit preferably used in
the co-processor of the present invention.
Figure 10 is a block diagram of the interrupt controller preferably used in
the co-processor of the present invention.
Figure 1 I is a block diagram of the CGX software interface preferably used
in the co-processor of the present invention.
Figure 12 is a block diagram illustrating the layers of software preferably
used in the co-processor of the present invention.
Figure 13 is a block diagram of the CGX overlay interface preferably used
in the co-processor of the present invention.
Figure 14 is a block diagram illustrating the hierarchical interface of the
CGX kernel cryptographic service preferably used in the co-processor of the
present invention.
Figure 15 is a functional state diagram illustrating the CGX kemel
preferably used in the co-processor of the present invention.
Figure 16 is a functional tree diagram showing the KEK hierarchy
preferably used in the co-processor of the present invention.
Figure 17 is a block diagram of a symmetric key weakening algorithm
preferably used in the co-processor of the present invention.
Figure 18 is a functional tree diagram showing the symmetric key hierarchy
preferably used in the co-processor of the present invention.
Figure 19 is a portion of a computer program defining the PCDB data type
preferably used in the co-processor of the present invention.
Figure 20 is a block diagram of the kernel block preferably used in the co-
processor of the present invention.
Figure 21 is a portion of a computer program defining the kernel block
preferably used in the co-processor of the present invention.
Figure 22 is a portion of a computer program defining the command block
preferably used in the co-processor of the present invention.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Figure 23 is a portion of a computer program defining the secret key object
preferably used in the co-processor of the present invention.
Figure 24 is a portion of a computer program defining the public keyset
preferably used in the co-processor of the present invention.
Figure 25 is a portion of a computer program defining the Diffie-Hellman
public keyset preferably used in the co-processor of the present invention.
Figure 26 is a portion of a computer program defining the RSA public
keyset preferably used in the co-processor of the present invention.
Figure 27 is a portion of a computer program defining the DSA public
keyset preferably used in the co-processor of the present invention.
Figure 28 is a portion of a computer program defining the DSA digital
signature preferably used in the co-processor of the present invention.
Figure 29 is a portion of a computer program defining the DSA seed key
preferably used in the co-processor of the present invention.
Figure 30 is a portion of a computer program defining the key cache
register data type preferably used in the co-processor of the present
invention.
Figure 31 is a portion of a computer program defining the symmetrical
encryption context store preferably used in the co-processor of the present
invention.
Figure 32 is a portion of a computer program defining the one-way hash
context store preferably used in the co-processor of the present invention.
Figure 33 is a portion of a computer program defining one example of the
CGX wrap code and command interface preferably used in the co-processor of the
present invention.
Figure 34 is a portion of a computer program defining the CGX overlay
table preferably used in the co-processor of the present invention.
Figure 35 is a portion of a computer program defining the KCS object
preferably used in the co-processor of the present invention.
6
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
DETAILED DESCRIP'ITON OF THE PREFERRED EMBODIMENTS
A block diagram of the cryptographic co-processor hardware formed in
accordance with the present invention is illustrated in Figure 1. The
cryptographic
co-processor is effectively broken down into three major components:
Input/Output (I/O) blocks 2, processor blocks 4 and security blocks 6.
Preferably,
the co-processor may fnrther include a standard direct memory access (DMA)
controller circuit 42, which will be described in greater detail. The
Input/Output
blocks 2 provide several customized functions that enable the application to
gain
access outside the cryptographic co-processor. The processor blocks 4 make up
the central processing unit and control circuitry used to run and control the
overall
device. The security blocks 6 implement the security features of the
cryptogaphic
co-processor as well as protection schemes.
Like most general purpose DSP platforms, the cryptographic co-processor
includes components which provide several Input/Output (UO) functions. These
components include a synchronous serial port 12, a bit 1/0 circuit 8, and an
I/O
interface circuit 14 to support Personal Computer Memory Card Industry
Association (PCMCIA) standard, or Peripheral Component Interconnect (PCI)
interfaces. The IDMA I/O interface circuit 14 is a standard 16 bit interface
provided directly on the integrated DSP co-processor. The synchronous serial
port
12 is a standard serial port which may be used for serial communications and
multiprocessor communications. The synchronous serial port 12 may be used to
interface to a coder/decoder (CODEC). The I/O pins 8 are used to control
external devices such as analog to digital converters and are used for sensing
inputs
from external devices (e.g., flow control bits, ring detection).
The processor blocks 4 include a DSP 20, reset control circuit 16 and clock
control circuit 22. The DSP 20 used in this embodiment is preferably Part No.
2183 manufactured by Analog Devices Inc. of Norwood, MA. However, the
secure communication platform may be embedded in any standard DSP or other
processor. The 2183 DSP provides the necessary processing power (MIPS) and
instructions to implement various applications (e.g., V.34 modem, ADSL, 10
Base
T Ethernet). The reset control circuit 16 is a standard circuit used to manage
the
7
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
reset of the DSP 20 and/or other hardware blocks tied to the cryptographic co-
processor platform. The clock control 22 contains a standard system clock
which
synchronizes data flow. Standard program random access memory (RAM) 10 and
data RAM 18 are included in the DSP for storing application programs and data.
The security portion of the co-processor 6 includes an encryption circuit
36, a random number generator circuit 38, a hardware public key accelerator
circuit 28, a secure kernel read only memory (ROM) 26, protected kernel random
access memory (RAM) 32, volatile key cache registers 34, hash circuit 30 and
kernel mode control circuit 24. It is, of course, understood that the
encryption
circuit 36, random number generator circuit 38, public key accelerator circuit
28,
registers 34, hash circuit 30, mode control circuit 24 and other circuits used
in the
co-processor may be implemented by discrete components or may be equivalently
formed as part of the DSP 20, which may be programmed to provide the functions
of these circuits. It should also be noted that the term "circuit" used herein
incorporates both hardware and software implemented connotations.
The encryption circuit 36 provides a hardware assisted DES engine. A
hardware assisted DES engine is provided because it is faster than a software
DES
engine, which would require more operations to encrypt and decrypt. The DES
engine can be used to implement DES and Triple DES encryption and decryption.
Furthermore, it implements four cipher modes: Electronic Code Block (ECB),
Cipher Block Chaining (CBC), Cipher Feed Back (CFB), and Output Feed Back
(OFB). The DES and Triple DES encrypt/decrypt operations are pipelined and
preferably execute full 16-round DES in 4 clock cycles. The DES engine
preferably encrypts 64 bits of data at a time and has a separate state
register 40
(i.e., the feed-back or initialization vector register) that can be read and
written.
The state register 40 is important in allowing multiple encryption circuit
contexts,
thus allowing packet switching. With a writable state register 40, a previous
context can be reloaded or a new one created. This murimizes the overhead of
changing cryptographic keys and initialization vectors. Hardware circuits are
provided for padding insertion, verification and removal which accelerates the
encryption operation. A control register is provided to program the algorithm
and
mode to be used.
8
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The hardware random number generator 38 provides a true, non-
deterministic noise for the purpose of generating keys, initialization vectors
and
other random number requirements. Random numbers are preferably 16 bit words
provided to the kernel. The secure kernel requests random numbers as needed to
perform requested commands and can directly supply from 1 to 65,535 random
bytes to a host application.
The hash circuit 30 provides hardware accelerated SHA-1 and MD5 one-
way hash processing. The hash circuit is coupled with the encryption circuit
36
where the combined operation chains both hashing and encrypt/decrypt
operations
to reduce processing time for data which needs both operations applied. For
hash-
then-encrypt and hash-then-decrypt operations, the cryptographic co-processor
performs parallel execution of both functions from the same source and
destination
buffers. For encrypt-then-hash and decrypt-then-hash operations, the
processing is
sequential; however, minimum latency is achieved through the pipeline chaining
design. An offset can be specified between the start of hashing and the start
of
encryption to support certain protocols such as IPsec.
The hardware public key accelerator 28 is provided to support large
number addition, subtraction, squaring and multiplication. It operates with
the
secure kernel to provide full public key services to the application program.
The
kernel provides macro-level algorithms to perform numerous security functions,
such as Diffie-Heliman key agreement, Rivest Shamir Adleman (RSA) encrypt or
decrypt and calculate/verify digital signatures. The hardware public key
accelerator speeds up the computation intensive operations of the algorithms
by
9
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
providing the mathematicai calculations. The secure kernel is embodied as
firmware which is mask programmed into a ROM. There are preferably 32K
words of kernel ROM 26 available for a cryptographic library and an
Application
Programming Interface (API).
A kernel mode control circuit 24 is provided for controlling a security
perimeter around the cryptographic hardware and software. Because the
cryptographic co-processor has a general purpose DSP and a cryptographic co-
processor, the device may operate in either a user mode or a kernel mode. In
the
user mode the kernel space is not accessible, wbile in the kernel mode it is
accessible. When in the kernel mode, the kernel RAM and certain registers and
functions are accessible only to the secure kernel firmware. The kernel
executes
host requested macro level functions and then returns control to the caUing
appiication.
The protected kernel RAM 32 provides a secure storage area on the
cryptographic co-processor for sensitive data such as keys or intermediate
calculations during public key operations. The kernel mode control circuit 24
controls access by only allowing the internal secure kernel mode access to
this
RAM. A public keyset and a cache of 15 secret keys may be stored in the
protected kernel RAM 32. The purpose of having a separate area for volatile
key
RAM is security related. It isolates the RAM from the application thus making
it
more difficult to accidentally leak RED (plaintext) key material.
A key feature of the co-processor of the present invention is its
universality.
First, a.manufacturer may substitute the co-processor of the present invention
for a
conventional digital signal processor (DSP) in the equipment (e.g., modem,
cellular
phone, etc.) which is being manufactured. The conventional digital signal
processor (DSP) does not provide secure communications. However, the co-
processor of the present invention performs all of the functions of the
conventional
DSP but also has the unique capability of providing secure communications.
Secondly, the co-processor of the present invention is also universal in that
it provides a library of cryptographic algorithms which may be selected by the
manufacturer for use in the digital communications equipment that is being
manufactured. The manufacturer may select one or more encryption algorithms or
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
functions (e.g., DES, HASH functions, etc.) for particular use with the
equipment
being manufactured. The manufacturer uses one or more commands to access the
library and select the desired encryption algorithm or function from the
library.
The advantage of the universal co-processor is that the user does not have to
recreate any encryption or hashing or public key algorithms, as they are pre-
programmed in the ROM library all the manufacturer has to do is select
whichever
algorithm he wishes to use in the encryption or hashing process. Selection of
a
particular algorithm is facilitated by using a pre-programmed command set
which
includes a number of encryption, public key and HASH commands. For example,
the command CGX-PUBKEY-ENCRYPT refers to a public key encrypt command
which is used to encrypt the application's data using an RSA encryption
algorithm
which is stored in the library. This operation implements encryption or the
RSA
signature operation using the pubkey member of a public key structure.
These commands are recognized by a microprocessor forming part of the
co-processor, which accesses the library and retrieves the particular
encryption
algorithm, for example, the RSA algorithm, from the library and uses it in the
encryption process.
The application software designer selects the encryption and/or HASH
functions from the library and thus avoids having to directly communicate with
the
crypto hardware.
Because the algorithms are mask programmed into the read only memory
(ROM) and are on the same platform, i.e., substrate, as the DSP, they are more
secure than if they were embodied in pure software.
As mentioned previously, a standard direct memory address (DMA)
controller circuit 42 is preferably included within the cryptographic co-
processor to
facilitate bulk data movements without requiring continuous processor
supervision.
It preferably allows 32 bit transfers to occur at up to 40 M words per second.
The
DMA controller circuit 42 is coupled to the input/output section 2 and the
security
section 6 of the co-processor.
An interrupt controller circuit 50 is coupled to the security blocks 6 and the
processor blocks 4. The interrupt controller circuit 50 provides enhancements
to
the existing interrupt functions in the processor blocks 4. The interrupt
controller
11
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
circuit 50 provides interrupt generation capabilities to the processor blocks
4 or to
a standard external host processor. Under programmable configuration control,
an
interrupt may be generated due to the completion of certain operations such as
encryption complete or hash complete.
An application register circuit 52 is coupled to the security blocks 6 and the
processor. blocks 4. The application register circuit 52 is a set of memory-
mapped
registers which facilitate communciations between the processor blocks 4 and a
standard host processor via the PCI or PCMCIA bus. One of the registers is
preferably 44 bytes long and is set as a'mailbox' up to hold a command
structure
passed between standard host processor and the processor blocks 4. The
application register circuit 52 also provides the mechanism which allows the
processor blocks 4 and the standard host processor to negotiate which has
ownership of the hash block circuit 30 and the encryption block circuit 36.
An external memory interface circuit 54 is coupled to the security blocks 6,
the processors blocks 4 and the direct memory address (DMA) controller circuit
42. The external memory interface circuit 54, provides an interface to
external
memory. The preferred address width is 26 bits wide and the preferred data
width
is 32 bits wide.
A laser variable storage circuit 56, is coupled to the security blocks 6 and
the processor blocks 4. The laser variable storage circuit 56 consists of 256
bits of
tamper-proof factory programmed data which is preferably accessible to the
processor blocks 4 and the secure kernel. Included in the laser variable bits
are:
112-bit local storage variable (master key encryption key), 80-bit randomizer
seed,
48-bit program control data (enables/disables various IC features and
configures
the IC), and 16-bit standard cyclic redundancy check (CRC) of the laser data.
The
program control data bits (PCDB) preferably includes configuration for
permitted
key lengths, algorithm enables, red key encryption key loading and internal IC
pulse timing characteristics. Some of the PCDB settings may be overridden with
a
digitally signed token which may be loaded into the cryptographic co-processor
when it boots. These tokens are created by the IC manufacturer and each is
targeted to a specific IC, using a hash of its unique identity (derived from
the above
laser variable).
12
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
A serial electrically erasable programmable read-only memory (EEPROM)
interface circuit 58 is coupled to the security blocks 6 and the processor
blocks 4.
The serial EEPROM interface circuit 58 is used to allow an external non-
volatile
memory to be connected to the cryptographic co-processor for the purpose of
storing PCI or PCMCIA configuration information (plug and play), as weil as
general purpose non-volatile storage. For example, encrypted (black) keys
could
be stored into EEPROM for fast recovery after a power outage.
The cryptographic co-processor may be integrated into a wide variety of
systems, including those which already have a processor and those which will
use
the cryptographic co-processor as the main processor. The cryptographic co-
processor and more specificaiiy the input/output blocks 2, can be configured
to one
of three host bus modes: IDMA 72, PCI 76 or PCMCIA 76. All three of these
interface modes are industry standards. A bus mode input 66 and a bus select
input
68 is coupled to the input/output blocks 2 for selecting the mode.
The bus mode input 66 is also coupled to a multiplexing circuit 60. The
multiplexing circuit 60 is a standard multiplexing circuit used to select
between one
of the three host bus modes (II)MA, PCI, PCMCIA).
An external memory interface (EMI) 70 is a standard memory interface
used to interface with external devices. This interface is coupled to the
processor
block 4.
An interrupt input circuit 62 is coupled to the processor blocks 4. The
interrupt input circuit 62 is a standard interrupt input circuit provided for
the use
by external devices. A standard flag input/output circuit 64 is also coupled
to the
processor blocks 4.
The master key (LSV) is intended to be different on each chip. Therefore,
it is not mask-programmed. Mask programming is done with lithography which
affects the artwork of the integrated circuit. Since no two chips should have
the
same LSV, the LSV is preferably programmed into a memory of the chip by laser
trimming. Laser trimming is advantageous in that each die may be fabricated
with
a different LSV so that each cryptographic co-processor is individualized with
a
particular LSV.
13
CA 02303297 2006-03-20
The following is a detailed description of the cryptographic co-processor
taken from a User's Manual prepared by the assignee and owner of the
invention,
Information Resource Engineering, Inc. (IRE). The cryptographic co-processor
is
often referred to herein by the trademark 'CryptIC'. The co-processor is also
often
referred to by part number ADSP 2141. The following includes a desciiption of
each
of the major subsystems within the CryptIC co-processor, including complete
register
details.
GENERAL DESCRIPTION
It can be seen from Figure lA that the ADSP 2141 CryptlC is a highly
integrated Security Processor ASIC which incorporates a sophisticated, general
purpose DSP, along with a number of high-performance Cryptographic function
blocks,
as well as a PCI, PCMCIA and Serial EEPROM interface. It is fabricated in .35
CMOS triple-layer metal technology utilizing a 3.3V Power Supply. It is
initially
available in a 208-pin MQFP package with a Commercial (0 - 70 C) Temperature
Range. A 208-pin TQFP package will follow.
DSP Core
The DSP Core is a standard Analog Devices ADSP-2183 with full ADSP-2 100
family compatibility. The ADSP-2183 combines the base DSP components from the
ADSP-2100 family with the addition of two serial ports, a 16-bit Internal DMA
port, a
Byte DMA port, a programmable timer, Flag UO, extensive interrupt
capabilities, and
on-chip program and data memory. The Extemal Memory Interface of the 2183 has
been extended to support up to 64M-words addressing for both Program and Data
memory. Some core enhancements have been added in the CryptIC version,
including
on-chip Security ROM and Interrupt functions.
14
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Secure Kernel (Firmware)
The Secure Kemel is embodied as firmware which is mask-programmed into
ROM within the DSP, thus rendering it tamper-proof. The Kernel provides the
API
(Application Programming Interface) to applications which require security
services
from the CryptIC. Those applications may be software executing in the 'User
Mode'
on the DSP, or they may be external 'Host' software accessing the CryptIC via
a PCI
or PCMCIA bus. Approximately 40 Crypto commands - called CGX (CryptoGraphic
eXtensions) - are provided at the API and a simple Control Block structure is
used to
pass arguments into the secure Kemel and return Status.
The Secure Kernel firmware runs under a'Protected Mode' state of the DSP
as described below in section 0. This guarantees the security integrity of the
system
during the execution of Kernel processes and, for example, prevents disclosure
of
Cryptographic Key data or tampering with a security operation.
Kernel Mode Control
The Kernel Mode Control block is responsible for enforcing the 'Security
Perimeter' around the cryptographic functions of the CryptIC. The device may
either
be operating in 'User Mode' (Kernel Space is nQ accessible) or 'Kernel Mode'
(Kernel Space is accessible) at a given time. When in the Kernel mode, the
Kernel
RAM and certain protected Crypto registers and functions (Kernel Space) are
accessible only to the Secure Kernel firmware. The Kernel executes Host-
requested
Macro-level functions and then retums control to the calling application. The
Kemel
Mode Control hardware subsystem will reset the DSP should any security
violation
occur, such as attempting to access a protected memory location while in User
mode.
(A readable register reports the memory address of the violation for debug
purposes.)
Protected Kernel 2AL'N-I
The 4K x 16 Kernel RAM provides a secure storage area on the CryptIC for
sensitive data such as Keys or intermediate calculations during Public Key
operations.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The Kernel Mode Control block (above) enforces the protection by only allowing
internal Secure Kernel Mode accesses to this RAM. A Public Keyset and a cache
of
up to 15 Secret keys may be stored in Kernel RAM. Secure Key storage may be
expanded to 700 Secret Keys by assigning segments of the ADSP2183 internal
Data
RAM to be 'Protected'. This is accomplished via a CGX INIT command argument.
Encrypt Block
The Encrypt Block performs high-speed DES and Triple DES encrypt/decrypt
operations. AIl 4 standard modes of DES are supported: Electronic Code Book
(ECB), Cipher Block Chaining (CBC), 64-bit Output Feedback (OFB) and 1-bit, 8-
bit
and 64-bit Cipher Feedback (CFB). The DES encrypt/decrypt operations are
highly
pipelined and execute full 16-round DES in only 4 clock cycles. Hardware
support for
Padding insertion, verification and removal fiuther accelerates the encryption
operation. Context Switching is provided to minimize the overhead of changing
crypto
Keys and IV's to nearly zero.
Hash Block
The Secure Hash Block is tightly coupled with the Encrypt Block and provides
hardware accelerated one-way Hash functions. Both the MD-5 and SHA-1
algorithms
are supported. Combined operations which chain both Hashing and
Encrypt/Decrypt
functions are provided in order to significantly reduce the processing time
for data
which needs both operations applied. For Hash-then-Encrypt and Hash-then-
Decrypt
operations, the CryptIC can perform parallel execution of both functions from
the
same source and destination buffers. For Encrypt-then-Hash and Decrypt-then-
Hash
operations, the processing must be sequential, however minimum latency is
still
provided through the pipeline chaining design. An Offset may be specified
between the
start of Hashing and the start of Encryption to support certain protocols such
as IPsec,
and 'Mutable bit' handling is provided in hardware.
16
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Random Number Generator (RNG) Block
The hardware Random Number Generator provides a true, non-deterministic
noise source for the purpose of Generating Keys, Initialization Vectors
(IV's), and
other random number requirements. Random numbers are provided as 16-bit words
to
the Kernel. The Security Kemel requests Random Numbers as needed to perform
requested CGX commands such as CGX Gen Key, and can also directly supply from
1
to 65,535 Random Bytes to a host application via the CGX Random CGX command.
Public Key Accelerator
The Public Key Accelerator module works in concert with the CGX Secure
Kernel fumware to provide full Public Key services to the host application.
The CGX
Kemel provides Macro-level library functions to perform Diffie-Hellman Key
Agreement, RSA Encrypt or Decrypt, Calculate and Verify Digital Signatures,
etc.
The hardware accelerator block speeds the computation-intensive operations
such as
32 x 32 multiply, 32-bit adds/subtracts, Squaring, etc..
PCMCIA/OProcessor Interface
A standard 16-bit PCMCIA interface is provided directly on the CryptIC. This
interface may also be used in certain applications as a generic 16-bit
OProcessor
Interface.
PCI/Cardbus Interface
A full 66/33MHz PCI v2.1 bus interface has been added to the core DSP
functions. The 32-bit PCI interface supports both Bus Master and Target modes.
The
CryptIC is capable of using DMA to directly access data on other PCI entities
and pass
that data through its Encryption/Hash engines.
17
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
32-Bit DMA Controller
The CryptIC incorporates a high-performance 32-bit DMA controller which
can be set-up to efficiently move data between Host PCI memory, the
Hash/Encrypt
blocks, and/or External Memory. The DMA controller can be used with the PCI
bus
in Master mode, thus autonomously moving 32-bit data with minimal DSP
intervention. Up to 255 long words (1020 bytes) can be moved at a time.
Application Registers
The Application Registers are a set of memory-mapped registers which
facilitate communications between the CryptIC DSP and a Host processor via the
PCI
or PCMCIA bus. One of the Registers is 44 bytes long and is set-up to hold the
CGX
command structure passed between the Host and DSP processors. The Application
Registers also provide the mechanism which allows the DSP to arbitrate whether
it or
the DMA controller (Host) has ownership of the External Memory interface.
Serial EEPROM Interface
The Serial EEPROM interface is used to allow an external non-volatile memory
to be connected to the CryptIC for the purpose of storing PCI or PCMCIA
configuration information (Plug and Play), as well as general-purpose non-
volatile
storage. For example, encrypted (Black) Keys or a digital certificate could be
stored
into EEPROM for fast recovery after a power outage.
Interrupt ControUer
The Security Block Interrupt Controller provides enhancements to the existing
Interrupt Functions in the ADSP 2183 core.
Primarily, the Interrupt Controller provides a new Interrupt Generation
capability to
the DSP or to an external Host Processor. Under programmable configuration
18
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
control, a'Crypto Interrupt' may be generated due to completion of certain
operations such as Encrypt Complete, Hash Complete, etc. The interrupt may be
directed either at the DSP core, or provided on an output line (PF7) to a Host
subsystem.
Laser Variable Storage
The Laser Variable Storage consists of 256 bits of Tamper-Proof Factory
programmed data which is only accessible to the internal function blocks and
the
Security Kernel. Included in these Laser Variable bits are:
= 112-bit Local Storage Variable (Master Key-Encryption-Key)
= 80-bit Randomizer Seed
= 48-bits Program Control Data (Enables/Disables various IC features and
configures
the IC)
= 16-bit CRC of the Laser Data
The Program Control Data (PCD) bits include configuration for permitted Key
Lengths, Algorithm Enables, Red KEK loading, Internal IC Pulse Shaping
Characteristics, etc. Some of the PCD settings may be overridden with a
Digitally
Signed Token which may be loaded into the CryptIC when it boots. These Tokens
are
created by IRE and each is targeted to a specific CryptIC using a Hash of its
unique
identity (derived from the above Laser Variable).
Downloadable Secure Code
The CryptlC is designed to allow additional Security Functions to be added to
the device through a Secure Download feature. Up to 16k words of code may be
downloaded into internal memory within the DSP and this code can be given the
security privileges of the Kemel firmware. All downloaded firmware is
authenticated
with a Digital Signature and verified with an on-chip Public Key. Additional
functions
could include new Encryption, Hash or Public Key algorithms such as IDEA, RC-
4,
RIPEMD, Elliptic Curve, etc.
19
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
MEMORY CONFIGIJRATION
The CryptIC provides a large amount of on-chip 0 wait-state RAM, a block of
mask-programmed ROM and also provides an external memory bus interface in
order
to allow a considerable expansion using off-chip devices. The on-chip RAM
consists
of three separate groups: 16k x 24 of Internal Program RAM, 16k x 16 of
Internal
Data RAM, and 4k x 16 of Kernel RAM.
Memorv Maa
The CryptlC memory map is very similar to that of the ADSP 2183, except
that it includes significantly more Off-Chip memory addressing, and has
additional
Crypto Registers which are accessible to the User. The CryptIC memory maps are
shown in Figures 2-4 of the drawings.
The PMOVLAY register is responsible for selecting 8k-word 'Pages' of upper
Program Memory, as shown in the table below.
PMOVLAY register
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Ix x X x x x x x x x X x x x x X
msb Lsb
PMOVLAYH PMOVLAYI,
External Address Page Select
The 41sb's (bits 3:0) are interpreted as follows:
1111 F Kernel ROM 0(Base Page)
1110 E Kernel ROM 1
1101 D Kernel ROM 2
1100 C Kernel ROM 3 (Top)
1011 B reserved
0011 3 reserved
0010 2 External RAM Odd Pages
0001 1- External RAM Even Pages
0000 0 Internal RAM
The 12 msb's (bits 15:4) are mapped to the most-significant external address
pins on the CryptIC (addr 25:14).
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Thus, to address Kernel ROM page 1, the PMOVLAY register should be set
to Ox000E (although the uppermost 12 bits are ignored in this case). To
address
External memory page 38, the PMOVLAY register should be set to Ox0131 (Ox013
are the 12 msb's representing pages 38 & 39 and a 1 in the least-significant
nibble
indicates External even page).
The DMOVLAY register is responsible for selecting 8k-word 'Pages' of lower
Data Memory, as shown in the table below.
DMOVLAY register
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Ix x X x x x x x x x X x x x x x
lsb.
DMOVLAYH DMOVLAYL
10 External Address Page Select
The 41sb's (bits 3:0) are interpreted as follows:
1111 Kernel RAM and Kernel Registers
15 1110 reserved
1101 reserved
0011 reserved
0010 Externai RAM Odd Pages
0001 External RAM Even Pages
0000 Internal RAM
The 12 msb's (bits 15:4) are mapped to the most-significant externai address
pins on the CryptIC (addr 25:14).
Thus, to address the Kernel RAM/Crypto Registers page, the DMOVLAY
register should be set to Ox000F (although the uppermost 12 bits are ignored
in this
case). To address External memory page 159 (decimal), the DMOVLAY register
should be set to 0x04F2 (OxO4F are the 12 msb's representing pages 158 & 159
and a
2 in the least-significant nibble indicates External odd page).
21
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Register Set
The CryptIC contains a number of additional registers (beyond those in a
ADSP 2183) which are mapped into the ADSP 2183's external data memory space.
Some of the Registers are intended to be accessed only by the Secure Kernel
and are
referred to as Protected Registers (Table 2 below). (In some cases, designers
may
require features of the CryptIC which are only available in Protected
Registers.) The
Registers which are accessible either to the DSP running in the User mode or
to an
outside PCI/PCMCIA Bus entity are referred to as Unprotected Registers and are
listed Table I below.
All of the Protected Registers are memory-mapped in the Data Memory space
of the DSP at Ox1000 - Ox17FF. The Unprotected registers reside at 0x1800 -
Ox1FFF. The DMOVLAY register must be set to Ox000F to access these registers.
From the Host perspective, the base register address in the PCI/PCMCIA space
is set
by the BASEADDR register.
Note that although the DSP cannot directly read 32-bit registers, it can
perform
a 32-bit DMA operation from a 32-bit register into its own external memory
space.
See section on 32-bit DMA Controller, described under a main heading below.
In the table below, 16-bit address refers to the DSP and 32-bit address refers
to
PCI host.
UNPROTECTED REGISTERS
ADDRESS ADDRESS REGISTER R/W Reset DESCRIPTION
16 B (32 Brl) NAME Defanlt
APPLICATION REGISTERS
1880- - Ox0000-2B CGX Command R/DV 44-byte CGX command register
0x
0x1895
Ox18A0 0x0040-41 Status R Ox0000 Applicatign status
Ox18A1 0x0042-43 Lock R/W DSP/Host lock control
Ox18A2 0x0044-47 Misc Status R/W Miscellaneous status bits: DSP <-> host
0s18A3 N/A Select Delav R/W Delay configuration for memory pulse
xeneration
Ox18A4 N/A Hash/Encrypt R/W Byte enables for data R/W to
Enable h/Encypt block
Ox18A5 N/A Reset Violation R Ox0000 Holds the memory type and Address of
22
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
MemtypeJAddr the last protection violation-induced
Reset
Ox18A6 OxOO4C-4F Extmem Confi R/W External memorv confi 'on
DMA & PCI REGLSTERS
DSP-Visible ' ters=
0x1840 N/A = Host Address R/W Lower 16-bits of Host Address
15:0
0x1841 N/A Host Address R/W Upper 16-bits of Host Address
[31:161
0x1842 N/A Local Address R/W Lower 16-bits of Local Address
15:0
0x1843 N/A Local Address R/W Upper 16-bits of Local Address
f3l:161
0x1844 N/A Command R/W Command
0x1845- N/A Status/Config. R/GV Status/Confition Re ' er
0x1846 N/A PCI Core R/W Status/Configuration for PCI core
Statns/Confi.
0x1847 N/A PCI Extmem R PCI External Memory Status
Status
PCI Host-Visible Retisters.
N/A Ox00C0-C3 PCI Target Page R/W Target Page specifier when CryptlC
External Memorv is Target
OxOOC4-C7 PCI Target Read R/W Maximnm mimber of dwords for Target
Count Read Transfer
N/A OxOOC8-CB Endian R/W Big/Little Endian select
PCMCIA Host-Visible R rs:
N/A Ox00C0-Cl DMA Address R/W DMA address re ' er
N/A OxOOC4-C5 Start/St DMA R/W DMA control
N/A OxOOC8-CB Endian R/W Big/Little Endian select
UNPROTECTED REGISTERS (cont.)
HASH/ENCRYPT REGISTERS
Confi ration Rec-nsters:
Protected 0x0200 HB control R/W Ox0000 Hash/Encrypt block control word
Protected OxO2lE Pad control R/W Ox0000 Pad control word
Protected 0x0220-0223 Lengtb R/W Ox0000 32-bit data length, in bYtes
Protected 0x0224 Offset R/W Ox0000 Offset, (0 to 15 in dwords), from start of
hash (encryption) to start of encryption
hash)
Protected 0x0226 Control R/W~ 0x0007 Operation control.
Protected 0x0228 Consume Pad W Command to consume final block
Status Redsftrs:
0x1016 0x022C Pad Status 0 R Decrypted next header byte, # Pad bytes,
Context 0
0x1017 0x022E Pad Status 1 R Decrypted next header bvte # Pad
23
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Context 1
Protected 0x0230 CGeneralStatus R Status result fram Hash/Encrypt
on
Protected Ox0232 ControlReady R 1= input ready for new control word, 0
= not readv
Protected .00234 DataReady R 1= inpnt ready for data FIFO, 0= not
readv
Protected 0x0236 StatFroeBytes R Number free input bytes in crypto FIFO
(in 64-bit blocks)
Protected 0x0238 StatOutBytes R Number outpnt bytes ready in crypto
FIFO (in 64-bit blocks)
Context 0 Re ' ers=
Protected 0x0240-0247 Key3 0 W Key 3, for Triple DES: Crypto Context
0
Protected 0x0248-024F Ke32_0 W Key 2, for Triple DES: Crypto Context
0
Protected 0x0250-0257 Keyl-0 W Key 1, for Triple DES or DES: Crypto
Context 0
Protected 0Y0258-025F Salt 0 W IV for kev decryption: C to Context 0
Protected 0x0260-0267 IV 0 R/W IV for data enciypt/decrypt: Crypto
Context 0
Protected 0x0268-027B Di 0 R/W (Inner) Digest: Crypto Context 0
Protected 0x027C-028F OuterDigest 0 W Outer Digest: C to Context 0
Protected 0x0290-0293 HashByoeCnt 0 R/W Startiug byte connt, for hash resume:
C o Context 0
Context 1 Re ' ers=
Protected Ox02A0-02A7 Key3_1 W Key 3, for Triple DES: Crypto Context
1
Protected 0x02A8-02AF Key2_1 W Key 2, for Triple DES: Crypto Context
1
Protected Ox02B0-02B7 Keyl_i W Key 1, for Triple DES or DES: Crypto
Context I
Protected 0x02B8-02BF Salt I W N for kev decrygdon: Crypto Context I
Protected OxO2CO-02C7 IV 1 R/W IV for data encrypddecrypt: Crypto
Context 1
Protected 0x02C8-02DB Di est 1 R/W Inner) Di est: C to Context 1
Protected OxO2D0-02EF OWierDigest I W Oater Digest: Crypto Context 1
Protected Ox02F0-02F3 HashByteCnt_1 R/W Starting byte count, for hash resume:
C to Context 1
Data In/Out FIFOs=
Protected 0x0380 Data F1F0 R/W FIFO: Data In/Data Out
INTERRUPT CONTROLLER REGISTERS
DSP-Visible Registers:
Ox1800 N/A DSP Unmasked R Interrupt source current states - Prior to
Status mask
Ox1801 N/A DSP Masked Statu R Intermpt sonrce current states - Post
mask
24
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
0x1801 N/A DSP Clear Int W Clear selected Internmt
0x1802 N/A DSP Masic Control R/W Intenupt mask register
Ox1803 N/A DSP Int Config. R/W DSP Interrupt confi 'on register
Ox1804 N/A Force Host Int W Force int t to Host (PCI/PCMCIA)
0x1805 N/A HB Ertor Code R Provides the H/E Error Code
iJNPROTECTED REGISTERS (cont.)
Host-VisIble Repisters:
N/A 0x0080-0081 Host Unmasked R Interrnpt source cuaem states - Prior to
Status mask
N/A 0x0084-0085 Host Masked Statu R Inteirupt source current states - Post
mask
N/A 0x0084-0085 Host Clear Int w Clear selected intemipt
N/A 0x0088-0089 Host Mask Control R/W Intemipt mask re ' er
N/A Ox008C-008D Host Int Config. R/W Host inte t configuration register
N/A 0x0090-0091 Force DSP Int W Force interrupt to DSP
N/A 0x0094-0095 H/E Error Code R Provides the H/E Error Code
IDMA INTERFACE REGISTERS
Host-Visible ReLyisters:
N/A Ox00A0-Al IDMA Indirect W Address latch for IDMA Indirect
Address transfers
N/A OxOOA4-A5 IDMA Config R/W IDMA Configuration (Direct or Indirect)
N/A Ox8000-FFFF IDMA Data R/W 32K IDMA Data Range
SERIAL EEPROM REGISTERS
Ox1900 N/A Device ID R/W 16-bit PCI device ID
0x1901 N/A Vendor ID R/W 16-bit PCI vendor ID 11D4h)
0x1902 N/A Rev ID/Class R/W 8-bit chip Revision ID, 8-bits of PCI
Class Code
0x1903 N/A Class Code R/W remaining 16-bits of PCI Class Code
Ox1904 N/A Header TypeJlnt R/W PCI header type & hftmipt Pin
Ox1905 N/A Subsvstem ID R/W 16-bit PCI Subsvstem ID
Ox1906 N/A Subsystem R/W 16-bit Subsystem Vendor ID
Vendor ID
Ox1907 N/A Max Lat, Min R/W Maximum Latency, Min Grant
Gnt parameters
0x1908 N/A Cardbusl R/W lower 16-bits of Cardbus CIS pointei
Ox1909 N/A Cardbus2 R/W upper 16bits of Cardbus CIS pointer
Ox190A N/A Baddr maskl R/W Specifies 1= modifiable 0= our
addresses
Ox190B N/A Baddr mask2 R/W LTpper 16 bits
Ox190C N/A CIS Size R/W CIS Size spec 16-bit r 8 bits are 0)
Oxl9OF N/A Cmd/Status R/W EEPROM Command and Status Register
Table 1 CryptlC Unprotected Register Set
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
PROTECTED REGISTERS
ADDRESS REGISTER NAME R/W Reset DESCRIIYTION
16 B Defs.nlt
HASH/ENCRYPT REGISTERS
Confi tion Reeisters:
Ox1000 H/E control R/W Ox0000 Hash/E t block control word
Ox100F Pad control R/W Ox0000 Pad control word
Ox1010-1011 Len R/W Ox0000 32-bit data lmgth, in bytes
0x1012 Offset R/W Ox0000 Offset, (0 to 15 in dwords), fram start of hash
en tion to start of
'on (hash) encr
0x1013 Control R/W 0x0007 ration control.
0x1014 Consume Pad W Command d to consume final pad block
Status Re ' ers=
0x1016 Pad Status 0 R Decrypted next header bvte, # Pad bvtes. Context 0
0x1017 Pad Status 1 R D ed next header bvte, # Pad bytes, Comext 1
0x1018 GeneralStatus R Status result from Hash/Encrypt operation
0x1019 ControlReadv R 1= input readv for new control word, 0= not readv
Ox101A DataReadv R 1= input readv for data FIFO. 0 = not readv
Ox101B StatFreeBytes R Number free input bytes in crypto FIFO (in 64-bit
bloclcs)
Ox101C StatOutBytes R Number output bytes ready in crypto FIFO (in 64-bit
blocks
Context 0 Re 'sters=
0x1020-1023 Kev3 0 W Kev 3, for Tri le DES: C o Context 0
0x1024-1027 Kev2 0 W Key 2, for Triple DES: C o Context 0
0x1028-102B Kevl-0 W Key 1, for Triple DES or DES: C o Context 0
Ox102C-102F Salt 0 W IV for key d tion: Crypto Context 0
0x1030-1033 IV 0 R/W IV for data en t/d t: Crypto Context 0
0x1034-103D Di est 0 R/W (Inner) Digest: C to Context 0
Ox103E-1047 OuterDi est 0 W Outer Digest: Crypto Context 0
0x1048-1049 HashByteCnt 0 R/W Starting byte count, for hash resume: Crypto
Context 0
Context 1 Re ' ers=
0x1050-1053 Kev3 1 W Key 3, for Triple DES: Crypto Context 1
0x1054-1057 KeW2 1 W Kev 2, for Triple DES: C to Context 1
0xI058-105B K 1 I W Key 1, for Triple DES or DES: Crypto Context 1
OxI05C-105F Salt 1 W IV for kev decmtion: C o Context 1
0x1060-1063 IV 1 R/W N for data encrypt/decrypt: C to Context 1
0x1064-106D Di est 1 R/W Inner Di est: Crypto Context 1
Ox106E-1077 OuterDi est 1 W Outer Digest: C o Context 1
0x1078-1079 HashByteCnt_1 R/W Starting byte count, for hash resume: Crypto
Context 1
Data In/Out FIFOs:
Ox10C0 Data FIFO R/W FIFO: Data In/Data Out
KEY MANAGEMENT REGISTERS
0x1180 RAM control R/W Selects the cturent KRAM owner: DSP, PK, DMA
0x1181 PM Reserve R/W Selects lkword segments of PM to 'Protect' into
26
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
ICernel
Ox1182 DM Reserve R/W Selects Ikword segmentS of DM to 'Protect' into
Kernel
0x1183 KM RAM Raserve R/W Selects 256fiyte segments of KM to 'Protect' into
Kernel
Ox1184 Hash/Enc Control R/W Selects owmer of H/E block: DSP or Host
0x1185 Reset Control R/W Allows intental reset of H/E. PK, RNG
Table 2 CryptIC Protected Register Set
BUS INTERFACES
The CryptIC supports multiple bus interfaces in order to allow it to be
integrated
into a wide variety of host systems. These buses are:
= Host Processor bus
~ PCI (also Cardbus) - or -
~ PCMCIA - or -
=> 2183 IDMA
= External Memory Interface (EMI) bus
These buses will be described in the following sections.
Host Bus Mode Selection
The CryptlCHost Bus may be configured for one of 4 personalities: ADSP
2183 Compatible IDMA Mode, IDMA Enhanced Mode, PCI Bus Mode, or PCMCIA
Bus Mode. The selection of mode is made with 2 Hardware control inputs
BUS MODE and BUS SEL at boot time.
Bus Mode 0 Pins 0 a<:B~S'':.11I~3DE s>: >;:: >BIIB >':51~~::':><;:
2183 IDMA Compatible Mode 0 0
2183 IDMA Enhanced Mode 0 1
PCI Bus Mode 1 0
PCMCIA Bus Mode 1 1
Table 3 Bus Mode Selection
A number of pins on the CryptIC are internally multiplexed in order to change
bus personalities. Refer to the CryptIC Datasheet for details.
27
CA 02303297 2000-03-13
WO 99/14881 'PCT/US98/19316
This selection may not be changed after the CryptIC comes out of power-up
Reset. It is typically expected that the Bus Mode signals are tied to ground
or Vm on
the PC Board.
PCI/Cardbus Host Processor Bus
When the CryptIC is configured for the PCI host bus mode, the Multiplex bus
pins become personalized to directly connect to a 3.3V PCI local bus. The PCI
core
on the CryptIC is compliant with version 2.1 of the standard and supports a 32-
bit
wide bus. The PCI clock speed may be run from 10MHz to 66MHz.
PCI Interface Specifications
The CryptIC's PCI 'core' meets the following specifications:
= PCI Version 2.1
= Target / Master transfer capability
= Configuration Space Read/Write
= Memory Mode Read/Write - Single word or Burst transfer
= Abort and auto re-try
The PCI interface does NOT support the following:
= I/O Mode Read/Write
= Fast Back-to-Back transactions
= Memory Write Invalidate operations
PCI Address Map
As shown in Figure 5, the CryptIC appears on the PCI Bus as a single
contiguous memory space of 128k bytes.
The CryptlC presents a 17 bit [ 16:0] address interface as a PCI Target.
Inbound PCI address bits [31:17] are decoded by the CryptlC PCI core to
determine
28
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
whether or not the PCI access matches the PCI Memory Base Address Register,
thus
determining whether the access is to the CryptIC or not. However, bits [31:17]
are
not reflected in the CryptIC register addresses.
Once the CryptIC's PCI address has been decoded, the next most significant
address bit, [A16], determines whether the lower 16 address bits should be
decoded as
an internal CryptIC register/memory address or reflected to the CryptIC 's
external
memory interface. If address bit 16 is 0, the 161sb's are interpreted as
CryptIC
internal register/memory address bits. If address bit 16 is 1, the 161sb's
[A15-AO] are
combined with the 11-bit page designator in the PCI Target Page Register to
form the
external memory address. The PCI Target Page register is addressable by the
Host
through the PCI Interface and specifies the 11 upper address bits for PCI
transfers
from/to external memory. See section on PCI Target Page Register (TARGADCNT)
described further below.
PCI Target Mode Transfers
As a PCI Target entity, the CryptIC provides memory-mapped or I/O-mapped
access to its 'unprotected' memory and register space. This includes
read/write access
through the CryptlC to the external memory connected to the EMI bus.
For all Target mode transfers, the CryptIC DMA engine is called upon to
perform the data movements inside the CryptIC between the PCI core and the
desired
memory or register location(s). This DMA action is automatic and the
initiating PCI
entity is unaware of the DMA participation in the transfer. It is important
however to
note the DMA's target transfer role as it effects other DSP-initiated DMA
operations.
Since Target transfers initiated from other PCI entities are typically unaware
of other
DMA activities occurring within the CryptIC, the DMA arbiter gives precedence
to
Target DMA transfers. A DMA transfer in-process will not be preempted, however
any pending DSP-inititated DMA will be deferred until after all Target
transfers have
been completed. (A status register in the DMA controller allow the DSP to
determine
29
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
whether it has seized the controller or whether a Target transfer is running.)
Refer
also to 0 for more information on the DMA controller.
In addition, in order for Target transfers to occur to/from External Memory,
the DSP must grant ownership of the External Memory bus to the DMA engine. If
the
Ext. mem. bus is not granted, then the data written to External memory will be
lost and
a read will return invalid data. See section 0 for more information.
PCI Target transfers to/from the CryptIC may in some cases experience a
timeout abort and re-start due to latencies in the PCI core FIFO's,
address/data setup
times, memory wait-states, etc.. These are more likely to occur with reads
than writes
due to the 'round-trip' nature of a read. In fact, if writes are kept to 8
dwords or
fewer, then timeout aborts can be avoided, since the PCI core write FIFO (12
dwords)
can store the written data until it can be DMA'ed to its destination within
the CryptIC.
The interaction of the clock speeds of the PCI bus and of the CryptIC core
must also be considered. Ideally, the CryptIC core clock should be equal to or
faster
than the PCI bus clock in order to allow it to unload incoming PCI data at
least as fast
as it arrives. If this is the case, then only IDMA transfers or transfers to
external
memory with > 1 wait state will result in PCI timeout aborts for transfers >8
dwords.
PCI Master Mode Transfers
The CryptIC can use PCI Master Mode transfers for the most efficient transfer
of data into or out of the device. Master mode transfers are always performed
under
control of the DSP. Refer also to 0 for more information on the DMA
controller.
PCI Core Configuration Registers
As viewed from the PCI Host perspective, the 256-byte PCI configuration
space is defined below in Table 4. The fields marked aoQaooooc are 'don't
cares'.
Shaded fields are read-only registers and are loaded from the serial EEPROM
connected to the CryptIC.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
31 16 15 0 Addr.
,- ---... .......
-,F i'v i::.i }':::'5:~:'t2.i - ...: . ' ' .. :Y; , .=..{+
=x.:
y: a n f ~ ~a;:..
. OOh
Status Command 04h
.. . ,.... . :.
. . . ..:. ..,.: :
}. ,. . . ~;t:: =:..:t><:::.n-: = ~ - . : .. . .. .,.,.., .
08h
. . . .:: .:::.
.::,.,:.. . .. . .. ...:..
., ::'...
., .. . . ,.:.. . . .
:.:. Master Latencv Timer Cacheline Size OCh
.. ...... . .. ... . .. .. .. ...
1/0 Base Address 10h
Memoiv Base Address 14h
Reserved (Dual Base) 18h
Reserved 1Ch
XXXooooc xxxxxxxx xac3000ca ~onarx 20h
XxDMa YJooC= ~ooooQOQC saoocxxQC 24h
XxXac)cxx xxxxxxxx XoQOOQOQC XIDCXXXoX 28h
: -:::: . . ..:
.:, . ,.
.,,.. ,; : .,..::::t'..:: ,,:~~~5 ~::<.:::::~:a, :.:t.:}"}:..:.:;. : ':~
='=~', ~ .
. ......::},'n.~ -.y = b . . ff v.}t.:=.:.'.4 :,~:. =.~,{==~=+ I:,,'t~c, 4.
.vC
:t4 # = . ;.:::::::i:t.x}.;=, = f ~~t}}%o-.c;:=<=:::~;..:,'S'~.f ~{!.2;.::: :'
J~ '' >>Y ''~' J=
:::..;';?:a::. .: .d~ ':'.:::=:;:~. ==:.:./. . . . . . . . :. ..
:r...ti3..;;:t:,..:=....., ..'.:.t;=.: = =:~ :...:..:::. :::. . . ...:...
..X2... .~' '= .:sie; J
:.~ ~'~~ ... . . 2Ch
. . .. ....:.. .
xxxxxxxx xxxxxxxx 1ot~nnonac Xooonoaac 30h
Reserved 34h
Reseived 38h
:.:.;; ; 4:;:: =;= =:.: ::: ~::.:=::::.~: .,.....::: ... .....
, ., . . . . ;. . _ <..
. ..: r . .
:,~~ .~ ~ :.t#t<}:= ..,: .. .. : ;: ;.~ ~~~t . }: ,:.. . ,.~ Interrupt Line
3Ch
. =. ....,õ .'
. .n:i4 . . =.}1~
= ,.n.. .. . :yN.}i:. .v . ='i n .. . . . 4....}..~.-:r "= y, . .
:...... .:.~:..... .. . . :.... Y :}:j}.::4i:... . . :., . =
. .. . . . .. .. :. .... .....:..
Reserved Retrv Timeout Value TRDY Timeout Value 40h
Reserved 44h-
FFh
Table 4 PCI Configuration Registers
The default values for the above registers are as follows:
Device ID = 2F44h Subsystem ID = 0000h
Vendor ID = I ID4h Subsystem Vendor ID = 0000h
Class Code = FF0000h Max_Lat = OOh
Revision ID = OOh Min_Gnt = OOh
BIST = OOh Interrupt Pin = Olh
Header Type = OOh
The upper 15 bits of the Base Address registers are writable, allowing the
selection of a 128k-byte address space for the CryptIC. As part of automatic
(plug &
play) PCI address mapping, it is common for the Host BIOS to write FF's into
the
Base Address registers and then to read-back the value to determine the
address range
required by the target PCI device. In the case of the CryptIC, the lower 17
bits will be
read as 0's, indicating 128k. Then, the BIOS writes an appropriate Base
Address into
the upper 15 bits which were read as 1's.
31
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
2183 IDMA Host Processor Bus
The 2183 IDMA Host selection (Internal Direct Memory Access) allows the
CryptIC to offer the IDMA interface directly to an outside Host processor. The
CryptIC's usage of the IDMA bus is identical to that described in the ADSP
2183
datasheet and ADSP-2 100 Family User's Manual.
The IDMA port allows a Host Processor to perform 16-bit DMA reads and
writes of selected areas of the CryptIC's internal memory space. These areas
include:
Internal Data Memory (DM) and Internal Program Memory (PM). Since PM is 24-
bits wide, two IDMA cycles are required to access it. IDMA transfers are
implemented using cycle-stealing from the CryptIC's internal DSP processor.
Note
that the~ CryptIC supports optional memory locking of 1 kword slices of DM or
PM.
Any locked areas of memory are not visible to a Host via the IDMA port.
Typically,
the locking of these memory spaces is performed by a custom 'Extended' program
invoked via the CGX Kernel interface.
Eaternai Memory Interface
The External Memory Interface (EMI) bus is a logical extension to the EMI
bus presented on a standard ADSP 218x processor. The CryptlC has enhanced this
bus as follows:
= Extended data bus width from 8 / 16 / 24-bits to 8 / 16 / 24 / 32-bits
= Additional Addressing: from 14-bits (16k words) to 26-bits (64M words)
The EMI interface can support multiple memory types, including 1/0, Program
Memory (PM), Byte Memory (BM), and 16-bit or 32-bit Data Memory (DM).
Since the EMI bus is shared between the DSP and the DMA engine within the
CryptlC, a control register is used to select which bus controller 'owns' the
EMI bus.
(This applies to all EMI accesses - PM, DM, I/O, BM). Only the DSP has access
to
this register, so it effectively becomes the arbiter for the ENII bus. This
allows
straightforward contention management between direct DSP access and DMA access
32
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
to external memory. It becomes more interesting when Host-initiated Target
transfers
are expected to external memory, since there is no intrinsic arbitration
provided. If a
Target transfer is attempted while the DSP owns the EMI bus, the PCI transfer
will re-
try and then be aborted.
32-BIT DMA CONTROLLER
Overview
The CryptIC integrates a high-performance 32-bit DMA controller in order to
facilitate bulk data movements within the chip without requiring continuous
DSP
supervision. The DMA subsystem allows 32-bit transfers to occur within the
CryptIC
at up to 40 Mwords per second (160 Mbytes/s).
Figure 6 illustrates the functionality of the 32-bit DMA subsystem.
DMA Controller Functional Descrintion
The DMA controller is shared between one of two 'owners'; either the DSP or
the PCI Host processor. This essentially corresponds to whether a'Master' (DSP-
owned) or 'Target' (Host-owned) transfer is needed. An arbiter manages any
contention issues when both the DSP and the Host attempt to control the DMA
engine
at the same time, with Target transfers getting priority.
All DMA operations occur on 32-bit buses within the CryptIC, although for some
internal locations, the source or destination could be 16-bits wide. In this
case, a bus
interface state machine converts the data between 16 and 32 bits (see the '*'
markings
in the figure above).
Because the External Memory bus interface is also multiplexed between the
DMA engine and a direct connection to the DSP's EMI bus, a DSP-controlled
register
output bit (PCIEXTMEM bit 1) selects which is the 'owner' of the External
Memory
bus. In typical applications (and the CGX Kernel), this bit is normally set to
give
control to the DMA engine - ensuring that Target bus transactions can complete
- and
would only be momentarily switched to the DSP during a non-DMA EMI transfer.
33
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
DSP Initiated Transfers
When the DSP controls the DMA engine, it truly behaves as a general-purpose
DMA controller: The DSP specifies source and destination devices/addresses and
the
byte count, and the DMA engine then executes the transaction. Status registers
may
be polled for completion, or an interrupt may be generated at the end of the
transfer.
For a PCI host bus, data movements can be handled between:
Case 1. PCI Host <-> D SP/Crypto * = DSP/~ mcludw All Crypto mpteM ga&T-ypt
block,
IDMA to DSP itrtanal RAM, and ICanel RAM - if nnloc3ced.
Case 2.PCI Host <-> Externat Memory
Case 3. External Memory <-> DSP/Crypto*
For cases 1& 2 above, this is how a PCI 'Master' transaction occurs. Case 3 is
a memory-to-memory type transfer.
For a PCMCIA host bus, data movements can be only handled as Taaet
reads/writes between:
Case 1.PCI Host <-> DSP/Crypto*
For most DMA transactions, both the source and destination address pointers
will be automatically incremented for each word transferred. The only
exceptions to
this are when either the source or destination of a transfer is:
= Hash/Encrypt Input FIFO
= Hash/Encrypt Output FIFO
= IDMA Data Register (Indirect mode only)
For those transfers, the FIFO/register address remains fixed and only the
'memory'
side address automatically increments.
34
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Memory Map
Addresses and memory domains are specified as part of the DMA setup. Each
of the 3 domains - Host memory, External Memory, and DSP/Crypto-register -
have
slightly different addressing techniques as shown below.
Host memory:
When one end of the DMA transaction is PCI memory (case 1& 2 above), a
full 32-bit address is specified in the Host Address register. This allows a
transfer to
be done to/from any location in PCI memory space.
Ezte'rnal memory:
When transferring to or from External memory, the addressing is slightly
different for cases 2 & 3 above. For case #2 (PCI Host to/from External
memory), a
full 26-bit external memory address is specified in the Local Address
register. Also, bit
#31 in the Local Address register is set to '1' to indicate External Memory.
For case #3 (External memory to/from DSP/Crypto-registers), bit #14 in the
Command register is set to '1'. Then, the 26-bit external memory address is
specified
in the Host Address register.
DSP/Crypto-register memory:
When one end of the transaction is DSP/Crypto-register/KRAM space, then a
Word (16-bit) address is specified in the Local Address register. This causes
the
address map to be shifted one address bit from the PCI (byte-oriented) map
shown in
Figure 7 is the word memory map of DSP/Crypto-register addresses.
DMA Control Flow
Figure 8 is a flow chart showing the steps which are typically followed for a
DSP-initiated Master transfer.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Code Samples
Below are some code samples for the three types of DSP-initiated DMA
transfers:
1. PCI Host <-> DSP/Crypto
void
!pci master transfer(unsigned short *host hiaddr, - Host 31-16 address bits
! unsigned short *host loaddr, - Host 15-0 address bits
! unsigned short *dsp_addr, - DSP 15-0 address bits, intnl
unsigned short read, - 0=write, nonO is a read
! unsigned short bytes) - Number of bytes to read/write
of Host memory
!
! This operation is used to read/write N bytes (i.e. bytes) from/to PCI
HOST memory using the DMA controller and performing master reads/writes.
The PCI HOST addresses are the source addresses. In this example, the
=! DSP is the destination. In fact, the DSP address will be to a crypto
! register. This code is not concerned with locking in external memory,
! so it will not allow external memory access.
!
! This operation wili not bump the Host or DSP addresses after the read/write
! of the block is complete. This will be left to the calling operation.
!
! Register ar contains the 1st argument: host hiaddr, and register ayl
contains
! the 2nd argument: host loaddr. This is how the calling interface works with
! Analog Device's C compiler and assembler tools.
! This operation assumes the calling fiinction will not request a read or a
! write that exceeds the maximum transfer size of 1023 bytes.
pci_master transfer
il=i4; Iget ptr to stack to get remaining args
m3=1;
modify(il,m3); lalign to argument 3, dsp_addr
myl=dm(il,m3); !obtain dsp address, dsp_addr
mr0=dm(il,m3); lobtain transfer direction, read
sr0=dm(il,m3); lobtain byte cnt, bytes
si=dmovlay; Isave away old DMOVLAY value
dmovlay=15; lenable CryptlC register's data page
! Ensure that the DMA controller is available to accept a command.
dma control ready:
srl=dm(0x1845); lread DMA status
af-srl and 0x8000; !if DMA control is not ready
if eq jump dma_control_ceadv; lthen continue to poll for readv
! Setup DMA address block for actual PCI HOST master read operation
dm(0x1840)=ayl; llower 16 bits of 32bit address of host
36
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
dm(Ox1841)-ar, !upper 16 bits of 32bit address of host
dm(0x1842)=myl; lDSP address, 0:15
srl=0;
dm(0x1843)=srl; linternal access, no upper address
! Setup the DMA command and issn.e it:
No HOST generated intennipt
Byte com as read from stack above this
Master read or write, depends on read argument
! PCI transfer
ar=sr0; lsets up transfer as master read
af=pass mr0; lif transfer is a read
if ne jump dma write_control; lthen write DMA control register
ar=sr0 or 0x8000; lset master write bit with length
dma_write control:
dm(0x1844)=ar, lwrite DMA control reg.
! Important, insert a delay of 2 instruction cycles to ensure that
! the transfer-active flag of the DMA status register will have time
! to be asserted. This avoids a false read by the DSP.
nop; nop;
! Poll imtil the PCI transfer is complete
!
dma master traasfer_poll:
srl=dm(0x1845); lread DMA status
af-srl and 0x0008; !if master transfer in progress
if ne jump dma master transfer_poll; lkeep polling
I Restore the DMOVLAY register and return to the calling fiuiction.
dmovlay=si; lrestore previous data page
rts; lreturn to caller, pop return address
PCI Host Initiated Transfers (Target Mode)
When a PCI Host performs a Target Read or Target Write of memory or a
register within the CryptIC, the DMA controller is automatically called into
use. From
the Host's perspective, most of the operation of the DMA controller is hidden.
The
DMA controller interprets the PCI-supplied addresses and other bus control
signals
and then generates the appropriate addresses for internal/external memory
space.
For some PCI Target reads which experience latencies before data is retrieved,
the DMA controller may 'fetch-ahead' two or three dwords and place them in the
PCI
37
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
core's read FIFO. This is important to oonsider when performing reads from the
Hash/Encrypt FIFO, since once data is read from the HB FIFO, it cannot be
reversed.
Thus, the Host must ensure that no 'fetch-ahead' is performed in these cases.
The PCI_Target Read_Count register is the mechanism to limit the maximum
'fetch-ahead' data which can be read. For example, if the Host is moving data
through
the Hash/Encrypt FIFOs in 8-dword blocks, then the PCI_Target Read_Count
register
should be programmed with an 0x08. See section on Target Read Count Register
(TARGRDCNT) described further below.
All Target mode reads or writes must occur on 32-bit dword boundary. The
only exception is reads or writes to the Hash/Encrypt block. In this case, the
PCI
starting-and ending address is decoded down to the byte level so that any
number of
bytes may be written to or read from the H/E data FIFO.
PCMCIA Host Initiated Transfers
All PCMCIA transactions to the CryptIC are Target transfers. The DMA
controller described in this chapter is disabled when the PCMCIA bus is
selected.
Instead, a separate 16-bit DMA controller is enabled and is controlled via the
PCMCIA DMA controller registers described in Applications Registers.
Both single-word reads and writes, as well as multi-word burst DMA transfers
are supported.
DMA Arbitration
Since the DMA is a shared resource between the DSP and Host Target mode
requests, a deterministic arbitration scheme is required for predictable
results. The
Arbiter shown in Figure 6 is responsible for moving DMA requests into the DMA
engines working registers. The Arbiter gives priority to Host Target mode
requests,
so this means the following:
- Assume a DMa transaction is in progress, and that another DSP-initiated
transfer request is queued-up in the DSP control registers. If a Host (PCI or
PCMCIA) Target read or write request occurs before the in-progress transaction
has
38
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
completed, then the Host request will be serviced 'or t the queued DSP
request.
Note that any DMA transfer which is already running will never be preempted.
The
only way for a DMA transfer to be aborted in mid-stream is for a Host bus
error to
occur (e.g. a PCI abort due to a Parity error) or for the DSP to force an
abort by
writing to the PCICSC register 'Force End Transfer' bit.
DMA Restister Set
A set of memory-mapped control and status registers are used to operate the
DMA controller. These are considered Unprotected Registers, and therefore are
visible to either the DSP rtmning in User mode or to an outside PCMCIA/PCI bus
entity. They are summarized in Table 5 and described in detail in the
following
subsections.
(In the table below, 16-bit address refers to the DSP and 32-bit address
refers
to PCI/PCMCIA host.
ADDRESS ADDRESS REGLSTER RW Reset Defiult DESCRIPTION
(16 Brr) 2 B NAME
PCI APPLICATION REGISTERS
DSP Visible ters:
Ox1840 N/A Host Addtess R/W Lower 16-bits of Host Address
f15:01
Ox1841 N/A Host Address R/W Upper 16-bits of Host Address
131:161
Ox1842 N/A Local Address R/W Lower 16-bits of Local Addtesa
15:0
Ox1843 N/A Local Address R/W Upper 16-bits of Local Address
31:16
Ox1844 N/A Command R/W DMA Command
Ox1845 N/A Status/Confia. R/W DMA Status/Confi~uration Reaister
Oxl846 N/A PCI Core R/W Stetus/Configuration for PCI cm
Status/Cani'i~.
Ox1847 N/A PCI Extmem R PCI External Memory Status
Statos
PCI Host Visible Recisters:
N/A OxOOCO-C3 PCI Target Page R/W Target Page specifier when CryptlC Extemal
Memotv is T et
N/A OxOOC4-C7 PCI Target Read R/W Ivlaximum number of dwords for Target Read
Couat Transfer
N/A OxU0C8-CB Bndian R/W B' 'ttle Endian select
PCMCIA Host Visible Reeiisten:
N/A OxU0C0-CI DMAAddress R/W DMA address reaister
N/A OxOOC4-C5 Stact/S DMA R/W DMA control
N/A Ox00C8-CB Endian R/W B' 'ttle Endian select
Table 5 DMA Controller Register Set
39
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
PCI Host Address Low Register (PCIHAL)
This 16-bit Read/Write register allows the DSP Software to configure the
lower 16 bits of a PCI Host Address for a Master mode transaction. For a DSP-
to-
External memory transfer, this contains the lower 16-bits of the External
Memory
address, as shown in the table below. Note that this is a~te address.
Re ' Address (READ / wR1TE
. .... .: .. ...... ..
DSP..:.... <;.:..:.P.::.::~:..
0xI840 Not Visible Not Visible
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
X x X X x x x x x x x x x X x x
Msb lsb
16 lsb's of Host Address [ 15:0]
10 PCI Host Address High Register (PCIHAH)
This 16-bit Read/Write register allows the DSP Software to configure the
upper 16 bits of a PCI Host Address for a Master mode transaction. If the
transfer is
between External Memory and the DSP memory space (case 3), then this register
holds the 10 most-significant bits of the External Address [25:16], as shown
in the
15 table below. Note that this is aby~.e address.
Re ' Address (READ / wRITE)
............ .. . ...... ...
Ox1841 Not Visible Not Visble
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
X x x X x x x x x x x x x x x x
Msb lsb
16 msb's of Host Address [31:16]
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
PCI Local Address Low Register (PCIHAL)
This 16-bit Read/Write register allows the DSP Software to configure the
lower 16 bits of Local (CryptlC) Address for a PCI Master transaction, as
shown in
the table below. Note that this is a 16-bit word address.
Re ' ter Address (READ /
..:.....:1k5P. .. ...: : ;....::.....I?i~Ti~i.:.:.::: . ;:.: .. .. :. 1
.
.. . .........
~
0x1842 Not V'~able Not V'~sble
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
X X X X x x x x x x x x x x x x
Msb lsb
161sb's of Local Address [15:0]
PCI Local Address High Register (PCIHAH)
If the transfer is between a PCI Host and External Memory (case 3), then this
10 register holds the 10 most-significant bits of the External Address [25:16]
and the
most-significant bit will be set to ' 1'. If the transfer is to/from the
DSP/Crypto-
register space (cases 1& 2), then there are no address bits contained here and
the
most-significant bit will be '0', as shown in the table below. Note that this
is a 16-bit
word address.
41
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Re ' er Address =AD/ WRITE
...... .
.
..............: ....................... .. .. . .
......., ~!! ~t~ ' . '.
i~}: =i$:i::: i i;' ;v t11='t".'(j,' ..} . .=>'%':: 55 y.}?'.f . ..)..
)i~i):.t:~ 1:' >'.
4[
= ? 3ss =~:i::ti~'r{ s t s .KS? $~S~iel~~3'.!#~) s )'~ '' :i r -
=~rrrrs;::::::~:i=
'Ai. ..?i.. .:~~..
Ox1843 Not VisH)le Not Visible
151 1 1 1 1 9 8 7 6 5 4 3 2 1 0
4 3 2 1 0
I X;:: :... . .:::..... ..... X X R X X X X X X X
msb lsb
msb's of EXternal Memory
Address [25:16].
(ignored for transfers
to/from DSP/Crypto-
regs)
Reserved (set to 0 on write)
I = EXtemal Memory access,
0 = Internal access
PCI Command Register (PCIC)
This 16-bit Read/Write register, as shown in the table below, is used by the
DSP to write Commands to the DMA Controller function.
The first 10 bits indicate the byte count of the requested transfer. Bit 14
selects the type of transfer: Between the DSP/crypto registers and the
External
Memory space (case 3), or between a PCI Host and either External Memory or the
DSP/crypto registers (case 1 or 2).
Bit 15 selects the direction of the DMA transfer.
42
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Re ' Address (READ / WRTTE
= ' . .;
. .. : i~i:: %i::
>.~' 's,...#:..>.
0X1844 Not V'imble Not V'oble
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
X X X X X X X X X
Byte Coaat (0 -1023)
Reserved (set to 0 on wtite)
1 = DSP/Cryptcegs<->Extemat Memory ttanafer,
0 = PCI Host treasfer
1= Iutaster Write (i.e. towards Host Addreaa)
0= Master Read (Le. towards Local Addresa)
DMA Status/Configuration Register (PCISC)
This 16-bit Read/Write register, as shown in the table below, allows the
DSP to configure/monitor the DMA function.
The first 2 bits are Read/Write and select the Wait States when the DMA
engine is transferring to or from External Memory. Note that the same number
of
Wait States should be selected internal to the DSP in the DWAIT bits of the
Wait
State Control Register.
Bit 2 is a Read-Only status bit which reflects the Host-selected Endian
state. All memory and registers within the DSP are Little Endian. The Endian
bit
determines whether or not the CryptIC has to do Endian conversion on data
to/from the host.
The next three bits [3-5] are general status bits which indicate the busy
status of the DMA engine for each of its three modes:
= Bit 3 set to 1 indicates that a DSP-initiated master transfer is running
(could be
case 1, 2 or 3). Note that when this bit transitions from 1 to 0, it may cause
a
Master PCI Transfer Complete interrupt to occur (see section 0).
= Bit 4 set to 1 indicates that a Host-initiated target transfer is running
(could be
case 1 or 2).
43
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
= Bit 5 set to 1 is a further qualifier on Bit 3 (i.e. bit 3 will also be
set): It
indicates that the transaction is for case 3.
Bits 12-14 provide PCI core status to the DSP:
= Bit 12 indicates that the PCI core has completed a DSP-initiated master
transfer.
= Bit 13 indicates that the PCI core has detected a PCI parity error on the
bus.
= Bit 14 indicates that the PCI core has experienced a PCI fatal error.
The last bit [15] indicates that the DSP may write into the DMA engine
register set. (Note that another DMA transfer may be underway, but since the
DSP side has double-buffered registers, another set of addresses and a command
may be queued. Note that when this bit transitions from 0 to 1, it may cause a
Master PCI Transfer
Queued interrupt to occur. (See section on DSP Unmasked Status Register
(DUSTAT) described further below.)
Re ' er Address atEAD / WRTTE)
~F . . :::::
0x1845 Not Visible Not V'Isible
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
,,.. ~, ,;.,:,:~ ..; ~:;r:. :: ::: <::: ~ =...:;.<:::
x x x x~~> 1~' .." ~ r# i~F n~ < x x x x x x
J L_I~Ezen,d Memory Wait States (0 - 3) }- Control (R/W)
1= Big Endian, 0- I.rtde Endian
1 - Master Transfer Active
1 - Target Transfer Active
1= Local to Exi. Memory Transfer Active
Resarved (set to 0 on write) StBtus (RIO)
1- PCI Core Master Complate
1 a PCI Core Parity Etror
1- PCI Core Fatal Error
I - Command Register Available
44
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
PCI Core Status/Configuration Register (PCICSC)
This 16-bit Read/Write register, as shown in the table below, allows the
DSP to configure and monitor the PCI Core function. This register is not
normally
accessed for most applications.
The first 7 bits allow the DSP to ternninate PCI transfers under abnormal
circumstances. The last 8 bits provide real-time visibility of PCI core
operation
status.
Re ' Address OIEAD
/
:. D~1~..:.... R1~A:;::}:
0x18Et6 Not V'Lsible Not V'lsele
15 1A 13 12 11 10 9 8 7 6 5 4 3 2 1 0
:;'=:'r,~..
X x X X X X X X,.: ,;; X x X X X X x
Target Force Retry
Target Force Abort
Target Transmit FIFO Flush
Target Receive FIFO Flush Control (R/W)
1Vlester Transmit FIFO Flush
Master Receive FIFO Flush
Force End Transfer
Rese.rved (set to 0 on write)
Target Transmit FIFO Write
Target Transmit FIFO Full
Target Receive FIFO Read
Target Receive F1FO Emptv Status
Master Transmit FIFO Write (R/O)
Master Transmit FIFO Full
Mester Receive F1FO Read
Master Receive FIFO Empty
PCI Ezteraal Memory Status Register (PCIEMS)
This 16-bit Read only register, as shown in the table below, reports the
status of External memory and Master transfers. The least-significant 8 bits
report
on the current word count of a transfer. They will start initialized to the
number of
words in the transfer and will decrement down to 0. Bit 8 indicates if the
External
Memory bus is in use by the DMA engine.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Re ' Address (READ)
. Ã~::..fE~~>~:;:.:::
...:...: ... :.:..:. : :~>.::.....::.::, .
::.:..
Not Vistble Not V~stble
0x1847
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
I. r= . ~r;1119 ~ ; F :. .::.:,. x x x x x x x x x
~.. ~
Masterumda word couod (0 - 255)
L 1- B:tamai mmaocy bus requea t, 0 - idle
Rmerved (.et to 0 cn write)
PCI Target Page Register (TARGPAGE)
The table below shows the bit definitions for the Target Page Register.
These are used in order to select the 64 kbyte page which the PCI Host may
access
for a Target read or write. This register is not used for DSP-initiated
(Master)
transfers. Note that this register is only visible to the PCI Host processor.
/ WR1TE
Re ' er Address (READ
'l?~
- - - ---------
N/A N/A Ox00C0-C3
1514131211109876543210
o 0 0 0 0 0 0 0 0 0 0
I
11 msb's of 26-bit external address
Reserved
Target Read Count Register (TARGRDCNT)
This register, as shown in the table below, specifies the maximum number
of dwords to fetch after a Target mode read has begun. Since Target reads can
sometimes timeout due to the access latencies in the path from PCI core to the
addressed location, it is desirable to fetch enough data so that on the PCI re-
try,
sufficient data will be available in the PCI core read FIFO to complete the
transaction.
46
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
On the other hand, anticipatory fetching data from an internal FIFO such as
the Hash/Encrypt data FIFO can be dangerous. If the Target read only requires
2
bytes from the FIFO, and 8 bytes are pre-fetched, then data will be lost. For
Target reads of the FIFOs, this register should be programmed with the size of
the
transfer.
RepsterAddress WAD/ WR1TE
.,: .. ..... ...
. ...........
,.. .. ,.. . . , :.. ...........
... .. ..:}. . ....
.: ,,. ............ .. ........ ..,.. . ,.. . ,. .. .: ....:.
N/A N/A Ox00C4-C7
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
f;;: <:. w . =f. ~.: =; :~ ;xr< ~= :..
.'~ ~:~ 0 0 0 0 0 0 0 0
Maximum number of dwords to fetch on
Target read
Reserved
Endian Register (PCIENDIAN)
This register, as shown in the table=below, specifies the 'Endianness' of
data transfers between the PCI bus and the CryptIC. The DSP is little-endian,
so if
it is communicating with a big-endian Host, then byte swapping is needed.
Setting
a 1 in this register will cause a hardware byte-swap to occur on all PCI
transfers to
any element of the CryptIC, including external memory and internal registers
or
memory spaces.
The status of this Host selection is reflected on the DSP side in the DMA
Status/Configuration register, described above.
Aaaress / vvRT1E
.., .;.;..: . .. . : > ......
N/A N!A OxOOC4-C7
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ry f: $~ ~:.:.. 0
õ :.,}}:;, ,;;<~;~z >~$~ }~.., = }.. :.:::~ = ,:,}.. . . .}:: .= .: ~
?' 5% ~ G . .}:~.{ . ''=y =R= ~. ,~({,{. j? '
+ . R .F.~:: ~,!:W!. ..~:;4,'. '~~
= :+N. i.} r ~~:i . '})H:{ ...~: ' ~ = =~
I I
L Fndian Seleck I= Blg Sndlan, 0=
Little Endian
Reserved
47
CA 02303297 2003-05-27
HASH/ENCRYPT SUBSYSTEM
Hash and Encrypt Block Overview
The Encrypt Block is tightly coupled to the Hash Block in the CryptIC and
therefore the two are discussed together. Refer to Figure 9 for the following
description:
The algorithms implemented in the Combined Hash and Encryption Block
are: DES, Triple DES, MD5 and SHA-1. Data can be transferred to and from the
module once to perform both hashing 118 a.nd encryption 110 on the same data
stream.
The DES encrypt/decrypt operations are highly paralleled and pipelined, and
execute full 16-round DES in only 4 clock cycles. The intema: data flow and
buffering allows parallel execution of liashing 118 and encryption 110 wlaere
possible, and
allows processing of data concurrently with .U'C of previous and subsequent
blocks.
Context switching is optimized to minimi7e the overhead of changing
cryptographic keys to near zero.
The 'software' interface to the module consists of a set of memory-mapped
registers 102, all of which are visible to the DSP and most of which can be
enabled for
Host access. A set of five, 16-bit registers define the operation to be
performed,
the length of the data buffer to be processed, in bytes, the offset between
the start
of hashing and encryption (or vice versa), and the .Fadding operation. If the
data
length is unknown at the time the encrypt/decrypt operation is started, the
Data
Length register may be set to zero which specifies special handling. In this
case,
data may be passed to the Hash/Encrypt block 124 indefinitely until the end
of' data is
encountered. At that time, the operation is terminated by writing a new
control
word to the Hash/Encrypt Control Register (either to process the next packet
or to
invoke the 'idle' state if there is no further work to do), This will ' close-
out' the
processing for the packet, including the addition of the selected crypto
padding.
A set of seven status registers provides information on when a new
operation can be started, when there is space available to accept new data,
when
there is data available to be read out, and the results from the Padding
operation.
48
CA 02303297 2003-05-27
Crypto Contexts
There are also two sets of 'crypto-context' registers 114. Each context
contains a DES or Triple DES key, Initialization Vector (Fv''), and pre-
computed
hashes (inner and outer) of the Authentication key for IiMAC operations. The
contexts also contain registers to reload the byte count from a previous
operation
(which is part of the hashing context), as well as an IV (also called 'salt')
for
decrypting a Black key, if necessary.
Once a crypto-context has been loaded, and the operation defined, data is
processed by writing it to a data input FIFO :",t the I/O interface, data is
always
written to, or read from, the same address. Irternally, *he hash and
encryption
functioris have separate 5 1:2-bit FIFOs 108, 116, each with their own FIFO
management
pointers. Incoming data is automatically routed to one or both of these FIF)s
108,116
depending on the operation in progress.
Output from the encryption block is read from the data output FIFO 112. In
encrypt-hash 110,118 or decrypt-hash 110,118 operations, the data is also
automatically
passed to the hashing data FIFO 1 16. Output ti-oni the hash function is
always read from
the digest register of the appropriate crypto-context,
The Initialization Vector (IV) to be used for a crypto operation can be
loaded as part of a crypto-context. When an operation is complete, the same
context will contain the resulting IV produced at the end, which can be saved
aNvay
and restored later to continue the operation with more data.
In certain packet-based applications such as IPsec, a feature is available
that
avoids the need to generate and load random IV's for outgoing (encrypted)
packets. The operating sequence .or t.b;s feature is as ffr,llows:
49
CA 02303297 2003-05-27
1) For the first encrypted packet after the C;rvptlC is initialized, two
random
numbers should be generated and written to each context's IV register. (This
can actually be done as part of the C:'ryptlC boot process.)
2) Control bit 0 in the Hash/Encrypt Control register is set to a' 1' in order
to
prevent subsequent software overwriting of the IV field in the two context
registers.
3) Now, at the end of each packet encryption or decryption, the IV register in
the
active context will contain the last 8 bytes of ciphertext. This 'random'
value
will remain in the IV register and riot be overwritten wlien the context for
the
next packet is loaded. (This technique is fully cocnpliant with the IPsec
standards.)
4) For decrypted packets, the IV is typicallv explicitly included with the
incoming
packet. Thus, the Control bit in step 2 will have to be set to a' 0' prior to
writing the IV into the context register. After the IV is written, the control
bit
should be restored to
Padding
When the input data is not a multiple of 8 bytes (a 64-bit DES block), the
encrypt module can be configured to automatically append pad bytes. There are
several options for how the padding is constructed, which are specified using
the
pad control word of the operation description. Optioras include zero padding,
pad-
iength character padding (PKCS #7), incrementing count, ivith trailing pad
length
and next header by-te (for IPsec), or fixed character padding. Note that for
the
IPsec and PKCSr~r'7 pad protocols, there are cases where the padding not only
fills-
out the last 8-byte block, but also causes an additional 8-byte block of
padding to
be added.
For the Hash 118 operations, padding 120 is automatically added as specified
in
the MD-5 and SHA-1 standards. W'hen the 'Hash Final' command is issued
indicating
the last of the input data, the algorithm-specified padding bits are added to
the end
of the hash input buffer 116 prior to cornput:ing the hash.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Data Offsets
Certain security protocols, including IPsec, require portions of a data
packet to be Hashed while the remainder of the data is both hashed and
encrypted.
The CryptIC supports this requirement through the OFFSET register which allows
specifying the number of 32-bit dwords of offset between the hash and encrypt
operations.
Black Key Loads
The cryptographic keys loaded as part of a crypto-context can be stored
off-chip in a "black" (encrypted) form. If the appropriate control bit is set
(HECNTL bit 15), the DES or 3DES key will be decrypted immediately after it is
written.into the Context register. The hardware handles this decryption
automatically. The KEK that covers the black keys is loaded in a dedicated KEK
register within the CryptIC. The N for decrypting the Black secret key is
called
'Salt' and must be stored along with the black key (as part of the context).
Note
that 3DES CBC mode is used for protecting 3DES Black keys and single-DES
CBC is used for single-DES Black keys.
When Black keys are used, there is a 6-cycle overhead (0.18 s @ 33MHz)
for DES keys or 36-cycle overhead (I. l s @ 33MHz) for triple-DES keys each
time a new crypto-context is loaded. (Note that if the same Context is used
for
more than one packet operation, the Key decryption does not need to be
performed again.) Depending on the sequencing of operations, this key
decryption
may in fact be hidden (from a performance impact perspective) if other
operations
are underway. This is because the Black key decryption process only requires
that
the DES hardware be available. For example, if the DSP is reading the previous
Hash result out of the output FIFO, the Black Key decryption can be going on
in
parallel. Also note that the data driver firmware does NOT have to wait for
the
key to be decrypted before writing data to the input FIFO. The hardware
automatically waits for the key to be decrypted before beginning to process
data
for a given packet. So it is possible to make the impact of black key
essentially
zero with efficient pipeline programming.
51
CA 02303297 2003-05-27
The Key Encryption Key (KEK) for key decryption is loaded via the Secure
Kernel firmware using one of the CGX Key Maaipulation commands (see "CGX
Interface Programmer's Guide"). This KEK is typically the same for all black
keys, since it is usually protecting local storage only. It is designated the
KKEK in
the CGX API.
One of the Laser Programmed confzguration bits specifies whether Red
(Plaintext) keys are allowed to be loaded into the Crvp11C from a Host. If the
RedKeyLoad Laser bit is set, keys may only be loaded in their 'Black' form.
This
is useful in systems where export restrictions limit the key length which may
be
used or where the external storage environznent is untrusted. If the
BlackKeyLoad
bit is not set, then keys may either be loaded either in their Black form, or
in the
'Red' (unencrypted) form. Note that the Laser Configuration bit may be
overridden with a signed Enabler Token (see "CGX Interface Programmer's
Guide").
Depending on the definition of the'Security Module Boundary' in a given
application, FIPS 140-1 may require the use of 'black key' i:o protect key
material.
In other words, if the Security Boundary does not enclose the database where
keys
are stored, then those keys must be protected from cornpromise. Black key is a
satisfactory way to meet this FIPS requirement.
Encrvgt and Hash Detailed Drscription
The following sections provide details on the operation of the
Hash/Encrypt block of the CrypclC,
DES Subsystem
The 512-bit (64 byte) crypto data FIFO 108,112 allows up to eight 64-bit
blocks
to be queued for processing. The FIFO 108,112 is implemented as a circular
buffer,
where the processed data is wr.itteri back to the same location it carne from,
For most
applications, the optimum transfer size is ?56-bits (32 bytes) which provides
the most
52
CA 02303297 2003-05-27
efficient 'pipelining'. This allows a set of four 64-bit blocks to be queued,
then while
those are being processed, the previous four blocks can be output, and a new
set of
four blocks input.
DES Modes
The CryptlC DES/3-DES engine 110 can perfor-:n any of the standard DES
modes: ECB, CBC, OFB, CFB in either Single-DES or 3"riple-DES. Since DES
operates on 64-bits at a time, data is always input to the algorithm in 8-byte
lumps
(or padded to 8 bytes by the CryptlC). The mode of DES operation is selected
in
the HECNTL register at the same time as an Encrypt/Decrypt operation is
started.
In the CBC, OFB and CFB modes, the DES algorithm block is used to generate a
'Keystream' which is XORed with Plaintext data in order to product Ciphertext.
This XORing is performed within the Encryption, hardware, so the user only
passes
Plaintext or Ciphertext data in and out of the CrvptlC.
For Cipher Feedback mode, one of three feedback choices is available: 64-
bit, 8-bit, or 1-bit. In 64-bit CFB, data is written to t.he input FIFO 108 in
the same
nranner as for all other modes. However in 8-bit or 1-bit CFB modes, null
bytes
must be written to the data FIFO 1(2 in order to align tl-ie desired byte or
bit within the
8-byte DES output. For example, in 8-bit CFB inode, 7 d:tull bytes must be
written
after each 'payload' byte is written to ttit. irtpui FIFO 108.
"Che 'hriple-DES (3DES) processiri8 performed by the encrypt hardware 110
employs the 'Outer' 3DES algorithm (as opposed to 'Inner' 3DES). This means
that, for a given input block of 8-bytes, the DES engine is drst run in
Encrypt, then
Decrypt, and finally again in Encrypt mode pri~c to any feedback or XOR.
operations. Inner 3DES performs feedback operations betwe n each of the 3 DES
operations. Most of the security protocol standards call for Outer 3DES, and
it is
considered the stronger of the two modes
Crypto Padding
To facilitate peak encryptldecrypt performance, the (:."ryptlC, supports the
most
commonly needed Paddirig; 104,106 furtctions in haxdware The features include:
53
CA 02303297 2003-05-27
= Generating and appending Pad bytes to the end of a Plaintext packet prior to
encryption
= Verifying correct Pad bytes after decrypting a packet
= Consuming (discarding) Pad bytes after decrypting a packet.
Four Padding Modes are supported in the CryptlG' hardware, as shown in the
table
below.
sC12 t1o2I
Niunber Made I7e
0 Zero Pad Appends 0 to 7 bytes of OxOO to the Plai=:Yt data to ensure the
total nurnber of
bvtes has no remainder modulo 8.
1 IPsec Appends 0 to 7 pad b.vtes, followed by pad couut 'n' (0 to 7) and then
a'next
header" byte. The pad byte values are a count from I to n. The 'Next Header'
byte is specified in the Pad Control register. A total of 2 to 9 bytes may be
a euded.
2 PKCS #7 I Appends i to S bytes- Pad bqte value = hex value of Pad coiuzt, so
if 3 pad bytes
are needed. thev will be: '03, 03, 03'
3 Constaat Appends 0 to 7 bytes of a user-specified chsxacter to the
Plai.ntext data to ensure
Pad the total number of bytes has no reinainder modulo 8. The byte (any value
from
OxOO to Oxff) is specrfied in the Readl'Write Pad Contro! Register.
If the Host system software wishes to implement another type of Padding
than is supported in hardware, then Mode 0 (Zero Pad) should be selected. The
Host simply insures that the end of the data to be encrypted lalls on an 8-
byte
boundary by inserting Pad characters on its own, in which case the Hardware
Padding engine will not add any bytes.
Pad Verification
There is a Pad Verifv bit in the General Status register 102 which checks for
proper
padding in Pad Modes 1 and 2. (Note that this bit is invalid for all blocks
read frotn the
hash/encrypt FIFO 108, 112 except the last block to be processed.) The Pad
Verification
106 operation checks the decrypted data for the correct Pad properties as
specified in the
54
CA 02303297 2003-05-27
selected Padding Mode (The Next Header byte value is not validated for IPsec
mode).
If Pad Modes 0 or 3 are selected, the Pad Verify bit wi:ll always read 0.
Pad Consumption
The application must always read-out the last block (8-bytes) of decrypted
plaintext data if there is at least one user-payload byte in it. When either
Pad Mode
1(IPsec) or Pad Mode 2 (PKCS 97) is selected, the Cryptlt:' can notify the
application of the number of Pad bytes (including Pad, Pad Iength, and Next
Header if applicable) detected in the decrypted plaintext through the Pad
Status
registers 102 (HEPADSTATO/1). A count of-0 to 1) can be reported.
In addition, these padding modes can cause an additional block of 8 bytes
to be produced (since more than 7 bytes may have originally been added to the
packet). The presence of this additional block is detected by the CrvptlC and
the
application may command the CryprIC to discard the last Pad block in order to
save the time of reading those 8 bytes. A write of any value to the Consume
Pad
register 102 will cause this discard to occur.
Hash Subsystem
Like the EncryptlDecrypt subsystem, the hash processing section also has a
512-bit (64 byte) FIFO 116. This represents a single S 12-hit input block to
the hash
algorithm 118. When the hash buffer is full, and the algorithni section is
done
processing previous data, the input block is iztimediately copied to the 512-
bit
algorithm working buffer, and the entirc. 512-bit FIF(::) buffer 116 is
available for data
input again.
There are several options available to control hashing, in addition to
selecting
between SHA-1 and MD5. The application may choose to either set the initial
state of
the hash operation from the constants defined for the algorithms, or from a
digest
which is loaded as part of a crypto-conte,:t. To continue a previous
operation, the
5
CA 02303297 2000-03-13
WO 99/14881 PCT/l3S98/19316
previous 'interim' digest must be reloaded. If an operation is to be resumed,
it is also
necessary to load the previous count of bytes processed. This can also be
loaded as
part of the crypto-context.
Hash Paddina
Controls are also provided to determine what is done at the end of the input
data stream. If the operation is to be resumed at a later time, then the
operation
should be defined to exclude 'final' processing. In this case, no special
processing
will be done at the end beyond making the resulting digest available as part
of the
output crypto-context. If the operation is to include the end of last of the
input
data, then the control for 'final' processing should be set, which will cause
the
padding operations defined for the hashing algorithms to be performed. These
include adding a'pad byte' following the last byte of data, and placing a 64-
bit
data length, expressed in terms of bits, at the end. If less than 9 bytes are
available
between the last input data byte, and the next 512-bit block boundary, an
extra
512-bit padding hash block will be added to contain the length. Any additional
bytes required to fill out the last or extra 512-bit blocks are set to zero.
As previously described, the same input data stream is internally buffered
by both the hash and encryption sections, depending on the data flow of the
operation selected. In the case of hash-encrypt, where the two components of
the
operation are done in parallel, if any padding is added to the crypto block
according to the option selected, the same padding is added to the hash block.
HMAC
To support the IETF HMAC protocol, the module supports processing an
'outer' hash. Each crypto-context supports loading an 'inner' and an 'outer'
pre-
computed initial digest. Typically, these would be the results of the HMAC
keyed hash
pre-processing, and would be stored as part of the security association (SA)
negotiated
for an IP connection. The pre-computed inner hash is loaded as the initial
state of the
hash algorithm before processing the input data stream. At the end of the
56
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
input data, normal 'final' processing is done, then the resulting digest is
used as
data for an additional round of hash processing, where the initial state is
the pre-
computed initial 'outer' keyed hash digest.
Hash/Encrypt Data Flow
Depending on how IP headers are processed in the packets to be
transformed using hash-encrypt, it may be that the data buffer ends up not
being
double word aligned with respect to the starting point of the operation in the
buffer. If this is the case, PCI transfers can be done using PCI byte enables
to
begin and end the operation on arbitrary bytes within their respective double
words. When the on-chip DSP is used to setup the PCI transfers using PCI
Master
Mode, it has the capability to control the byte enables by setting the
starting offset
and byte count. When PCI Target Mode transfers are used, the PCI host is
responsible for controlling the byte enables. Byte enables are also used on
the 16-
bit DSP bus. In this case, the enable signais are set in a register in another
block
and passed in as a two bit wide signal. This capability only applies to 1/0 to
the
data FIFOs. All other registers assume full word (16-bit bus) or double word
(32-
bit bus) transfers.
The hash-encrypt block also supports communication with host processors
which may be either big endian or little endian, in terms of the order of
storage
within a double word. The default assumption is little endian. If big endian
is
selected, the module will reorder the input and output bytes, and in the case
of the
32-bit bus, align them with the proper edge of the resulting double word.
Endian
processing applies to both the data and crypto-context registers, but not the
control and status registers, where it can be handled in the application
software.
The hash-encrypt block is designed to support zero wait state reads on the 16-
bit bus to the DSP, and 1 wait state reads on the 32-bit bus to PCI (due to
endian
processing). Writes experience a one clock latency, as they are first latched,
then
written to the target address. Writes can be zero wait from the host's
perspective,
however, as long as a read is not attempted in the immediately following
cycle.
57
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Hash/Encrypt Subsystem Notes
Note that due to the pipelining nature of the module, it is possible to begin
a new operation before all the data from the previous operation has been
processed
and read out. The sequence of steps is simplified if operations are performed
serially with no overlap.
Final processing for hasbing operations, and padding of a short trailing
crypto block, is initiated automatically. The end of the input data stream for
an
operation is determined by counting the number of bytes input and comparing to
the byte length entered as part of the operation control. An operation may be
ended prematurely by entering a new operation control. If the length field is
set to
zero, this is the only way to cause a normal end.
Operations can be aborted by resetting the hash-encrypt block. All
registers except the KEK will be reinitialized. The hash-encrypt block can be
reset
in the CryptIC via the kernel mode block hash-encrypt control register.
If black keys are used, the KEK register must be loaded prior to loading
either of the crypto contexts.
In the case where the DSP is performing all hash-encrypt actions as a result
of calls from application software to the Crypto CGX interface, then all
actions
described above are reads and writes via DSP (16-bit).
When the DSP is managing the interactions in PCI system, and the data
resides in PCI host memory, then the status polling and control actions take
place
via DSP reads and writes on the 16-bit bus. It this case, however, the crypto-
context and data FIFO UO takes place on the 32-bit bus, as a result of PCI
Master
Mode transfers initiated by the DSP.
When a host processor is directly managing all aspects of hash-encrypt
operation, then all I/O takes place on the 32-bit bus, although in some cases
the upper
58
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
16-bits of the bus are not used (such as in a PCMCIA environment or with a 16-
bit
embedded processor).
The Kernel Mode firmware releases access of the Hash/Encrypt function
block to the PCI/PCMCIA host whenever it is not executing a CGX command.
Hash/Encrvnt Reaisters
Table 6lists the memory-mapped register interface to the hash-encrypt
module within the CryptIC. These registers may be accessed either from the DSP
in Kernel mode, or if granted permission, from a PCI/PCMCIA host external to
the
CryptIC. Addresses on the 16-bit bus from the DSP are to 16-bit words.
Addresses on the 32-bit bus (from PCI host) are to the first 8-bit byte of the
32-bit
transfer. Transfers on the 32-bit bus should always be aligned to double word
boundaries.
ADDRESS ADDRESS REGISTER R/W Reset DESCRIPTION
(16 B (32 B NAME Default
Confi 'on Re 'sters=
Ox1000 0x0200 H/E control R/W Ox0000 HashXncrypt block control word
Ox100f OxO2le Pad control R/W Ox0000 Pad control word
Ox1010-1011 0x0220-0223 Length R/W Ox0000 32-0it data length, in bvtes
0x1012 0x0224 Offset R/W Ox0000 Offset, (0 to 15 in dwords), from start of
hash
(en 'on) to start of en tion (hash)
0x1013 0x0226 Control R/W 0x0007 Operation control.
0x1014 0x0228 Consume Pad W Command to consume final ad block
Status Re ' ers=
Ox1016 Ox022c Pad Status 0 R Decr
ed next header byte, # Pad bytes, Context 0
0x1017 0x022e Pad Status I R Decrvoted next header byte. # Pad bytes, Context
1
0x1018 0x0230 GeneralStatus R Status result from HashfflmcMt operaton
0x1019 0x0232 ControlReadv R 1 ffi' readv for new control word, 0= not readv
Ox101a 0x0234 DataReadv R 1= iinm readv for data FIFO. 0 = not mady
OxlOlb 0x0236 StatFreeBytes R Number free input bytes in crypto FIFO (in 64-
bit
blocks)
Ox101c 0x0238 StatOutBytes R Number output bytes ready in crypto FIFO (in 64-
bit
blocks)
Context 0 Re ' ters=
0xI020-1023 0s0240-0247 :C..~'3 0 :V Kev 3, for Triple DES: C:N to Context 0
0x1024-1027 0x0248-024F Key2 0 w Key 2 for Triple DES: Crypto Context 0
0x1028-102B 0x0250-0257 Kevl-0 W Key 1 for Triple DES or DES: Crypto Context 0
0x102C-102 0x0258-025F Sait 0 w N for kev decryption: CryLAo Context 0
Ox1030-1033 0x0260-0267 IV 0 R/W N for data en decriZ: Crypto Context 0
0x1034-103D 0x0268-027B Di st 0 R/W (Inner) Digest: Crypto Context 0
Ox103E-1047 0x027c-028F OuterDi 0 W Outer Di est: C o Context 0
59
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
0x1048-1049 0x0290-0293 HashByteCnt 0 R/W Starting byte count, for hash
resume: Crypto
Context 0
Coatext 1 Re dfters:
0x1050-1053 OxO2AO-02A7 Kev3 I W Key 3, for Tri le DES: Crypto Context 1
0x1054-1057 Ox02A8-02 Kev2 1 W Key 2, for Triple DES: Crypto Context 1
0x1058-105B OxO2BO-02B7 Kevl 1 W Key 1, for Triple DES or DES: CxyM Context 1
Ox105C-10 Ox02B8-02BF Salt I w IV for 'on: Crypto Context 1
0x1060-1063 Ox02C0-02C7 IV 1 R/W IV for data encry
tlWdecrypt: C Context 1
0x1064-106D x02C8-02D Di est 1 R/W (Inner) Di : CryM Context 1
Ox106E-1077 Ox02D0-02EF OuterDi 1 w Outer Digest: C to Context 1
0x1078-1079 Ox02F0-02f3 HashByteCnt_1 R/W Starting byte count, for hash
resume: Crypto
Context 1
Data In/Out FIFOs=
Ox10c0 0x0380 Data FIFO R/W FIFO: Data In/Data Out
Table 6 Hash/Encrypt Registers
Hash/Encrypt Control Register (HECNTL)
This 16-bit Read/Write register, as shown in the table below, allows
selecting configuration settings for the Hash/Encrypt subsystem.
Address MEAD/
WRITE
~?"f~iC~i : :: ....... 1>~
.. ..... .
:::::: ::';:
Ox1000 0x0200 - 0x0201 0x0200 - 0x0201
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
.:: .. ..
.. .. . .;..
'':3:. ;g
.. ':(~~> ~<:,: 0
:> >
:; ' r:l#>"fl;:; ~:~:<
.... ..
.... ... ''.:.~. :::........ ....... .. ..... ....... ........ .~'. ........
:::~k::::......
Allow IV wzites to crnRext
regotem
0- allow soflware to write to IP
1- igwra data wriuen to rV registen
Raavad
Pad Control Register (HEPADCNTL)
Shown in the table below are the bit definitions for the Pad Control
Register:
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Reedw ' Addrae (READ/ WRI't'E)
...
::::DSix :::::::::::::: ::::::::::::::::::::::::::
0x1009 OxOlle-OrOllf Ox01ic-Ox011f
1514 13 12 11 10 9 8 7 6 5 4 3 2 1 0
o 10 10 0 0 o o o~::
l I I
L Pad Mode:
O-Zero Pad, 1-IYaeo, 2-PKCS#7,
3-CaopaoaPad
Ruaved
Ne& Headar ime (IPeec), or Pad Byte comtaos
(Mode 3)
Control Register (HECNTL)
Shown in the table below are the bit definitions for the Hash/Encrypt
Control Register:
R ' Addrar READ / WRIrEI
:P(R41C[~4::::::::::.: :::::::::::;::;;:YC1'::::
0x1013 0x0126 - Ox0127 0x0126 - Ox0127
I 15 14 113 112 I11 110 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 1 1
OpelBhon :
(0=encrypt; 1=dectypt; 2=hash; 3=hesh-enc; 4-dec-
hash; 5=hash-dec; 6=ewhash:, 7=idle) f I"
1= Triple-DES, 0= DES R of 2
Mode: (O=ECB; 1=CBC; 2=OFB; 3=CFB)
# feedback bits (0 = 64-bits; 1= 8-bits; 2=1 bit)
I=SHA,0=MD5
1= initial hash state is algo:ithm constants
0= use i:mer Digest as initial state
1= load hash byte count, 0= start from zero
I = perfocm outer bash
I = perform hash 'finaP processing
I = use context 1, 0= use context 0
1= offset is from stact of 2ie sub-operation to start of I
sub-operation.
0= offset is ffom start of 1" sub-operation to start of 2"
sub-operation
1= decrypt key before use
61
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
Consume Pad Register (HECONSPAD)
This 16-bit Write-Only register, as shown in the table below, allows the
Software to command a discard of the last 8-byte block of decrypted data in
the
Hash/Encrypt output FIFO. This is typically used to avoid the bus bandwidth of
transferring the Pad block back to host memory.
Rc ' er Address (WRrrE ONL
........... 0x1014 0x0228 - Ox0229 0x0228 - Ox0229
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
X x x X x I x I x I x I x I x I x I x I x I x I x I x
l I
Don't Care
Pad Status Register 0 (HEPADSTATO)
Shown in the table below are the bit definitions for the Pad Status Register
0:
Re ' er Address (READ/ WRITE)
.: ;::... . DSl' : . ? ::1'f~k~ ...: :.. .. . . .. ... :. .~!Cg:.:
0x1016 0x012c - 0x012d 0012c - 0x012d
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 o 0 0:1,mo 0 0 0
~JNtunber of Pad Bytes in lad deaypted Block (0-
15)
Rmerved
Deayptcd Nwct Headar byte (IPaKC)
Pad Status Register 1 (HEPADSTATI)
Shown in the table below are the bit definitions for the Pad Status Register
1:
62
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Re ' Address atEAD
/ WRITE
:. ..... ..................
.. ..... ......::.....:.... .
.. ...... .............
.. .:..: .... . ..::.......... .::?.... .. ...:........:............:::~:.:. ~
. ..........
0x1017 0x012e - 0x012f 0x012e - 0x012f
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 U 0 0 0 0
0 0 0 0
Number of Pad Bytea in lsat deiaypted Blodc (0-15)
Reaaxved
Deaypted Next Header byte (IPaec)
General Status Register (HESTAT)
Shown in the table below are the bit definitions for the Hash/Encrypt General
Status Register:
Re ' Address MSAD
/ONL
......:......... . ... .
:>:::::: ::::::I3~::: ... :::: . >;;:::[:::::>::::::
..... . ..... . . . .. . . .... .:..... . . PÃ,~tdE3T~ . .. . ... . PCt
0x1018 0x0130 - 0x0131 0x0130 - 0x0131
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0;~ 0 0 0 10 0 0
1= Output data available (from crypto block)
1= Hashing is complete for context 0
1= Hashing is complete for context 1
1= Encryption / Decryption is complete for context 0
1= Encryption / Decryption is complete for context I
1= Processing for Context 0 is complete
1= Processing for Context 1 is complete
Reserved
1= Pad Block Added on Encrypt, context 0
I= Pad Block Added on Encrypt, context 1
1= Pad Verification Fault, context 0==
1= Pad Verification Fault, context 1'=
I= Extra Pad Block Detected on decrypt, context 0==
1= Extra Pad Block Detected on decrypt, context 1==
Resaved
Reserved
= IV is available to be read from Context
== Valid only after last decrypted block
63
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
APPLICATION REGISTERS
The Application Registers (AppRegs) subsystem provides a bi-directionat
mailbox facility between a Host and the CryptlC and also contains some
miscellaneous
configuration registers. The mailbox is specifically designed to facilitate
the transfer of
CGX crypto commands back and forth between the CryptIC and the calling Host.
Overview
The AppRegs mailbox subsystem is designed to follow a'ping-pong' protocol
between CryptIC and Host. Default power-up ownership of the mailbox is given
to
the Host. After either side writes an entire message to the mailbox, it
automatically
switches state so that the other entity is given 'ownership' of the mailbox.
Optionally,
an Interrupt may be sent to the DSP/Host when the other side has finished
writing a
message.
Up to a 44-byte (22 word) message may be written to the mailbox by the DSP.
The procedure should designate that the least-significant word of the message
be
written last, since that initiates an 'End-of-Message' sequence. (By using the
least-
significant word for termination, any length of message from 1 to 44 bytes can
be
supported.)
Application Registers Register Set
A set of memory-mapped control and status registers are provided in the
'Application Registers' subsystem. These are considered Unprotected Registers,
and
therefore are visible to either the DSP running in User mode or to an outside
PCMCIA/PCI bus entity. They are summarized in Table 7 and described in detail
in
the following subsections.
(In the table below, 16-bit address refers to the DSP and 32-bit address
refers
to PCI/PCMCIA host.
64
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
ADDRESS ADDRESS REGISTER ~ R~ DESCRIPTION
(16 B (32 B NAME efanl
APPLICATION REGISTERS
0x1880- Ox0000-2B CGX Command R/W 44-byte CGX command register
0x1895
Ox18A0 0x0040-41 Status R Ox000 A lication re ' ers status
Ox18A1 0x0042-43 Lock R/W DSP/Host lock control
Ox18A2 0x0044-47 Misc Status R/W Miscellaneous statns bits: DSP <-> host
Ox18A3 N/A Select Delay R/W Delay configuration for memory pulse
eneration
0x18A4 N/A Hash/Encrypt R/W Byte enables for data R/W to Hash/Encypt block
Bvte Enable
Ox18A5 N/A Reset Violation R Ox0000 Holds the memory type and Address of the
last
Mem Addr rotection violation-indnced Reset
Ox18A6 OxOO4C-4F Extmem Config R/W External memorv confion
Table 7 Application Register Set
Maitboz Data Register (MAILDAT)
This is actually a contiguous set of register comprising 44-bytes, as shown in
the table below. The least significant word of this register has special
properties.
When written by the DSP, the lsword will cause a'DSP Wrote Command' interrupt
to be issued to the Host processor (if enabled). Similarly, a Host write will
cause a
'Host Wrote_Command' interrupt to be issued to the DSP processor (if enabled).
In
addition, writing the least-significant word will cause the ownership of the
mailbox to
automatically flip to the other party.
From the DSP perspective, the mailbox appears as 22 consecutive 16-bit
locations:
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
DSP Re ' Address (READ / WRTIE)
. ...,.....
~ ............; .; . Y'=ii:4i'v: i.. ; . .; :~ ........:: ..ry ........
........:: .y.y.; v:: , .
'4 r.,tih:ii.;$C=''P~. =
r')~.=ki
. . . . . ......... .. .
0x1895 Data Word 21 msw
0x1894 Data Word 20
0x1893 Data Word 19
0x1882 Data Word 02
0x1881 Data Woni 0 1
Ox1880 Data Word 00 sw **
** End-of-Write Trigger Word
From the Host perspective, the maiibox appears as 11 consecutive 32-bit
locations which are byte-addressable, as shown in the table below:
Host Re ' Address (READ / WRITE
Ox002B Data Byte 43 msb
OxOO2A Data Byte 42
0x0029 . Data Bvte 41
0x0002 Data Byte 02
Ox0001 Data B 01
Ox0000 Data Byte 00 (Isb)
**
* * End-of-Write Trigger Byte
DSP AppRegs Status Register (DSPAPPSTAT)
This 16-bit Read-only register, as shown in the table below, allows the DSP
Software to monitor the status of the Mailbox.
Bit #0, Mailbox Write Own, allows the DSP to determine who may next write into
the
Mailbox.
Bit #1, Host has read Mailbox, allows the DSP to monitor when the Host
processor
has received a transmitted message in the Mailbox. Bit I will be latched as
a'1' when
the Host has read the least significant data byte of the Mailbox. As soon as
the DSP
66
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
reads DSPAPPSTAT, this bit will automatically be cleared and re-armed for the
next
Host Mailbox read.
Bits #2 & 3 are read-only status bits which reflect the semaphores written
(and read) in
the DSPSEMA and HOSTSEMA registers.
Address atEAD
ONL
:::...1~~ "t~l~i:::: :<.:
Ox18A0 Not Visible Not Visible
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
>::<>::=:=:::::::; ,.:::,;~ ::;; ...}:.. .{,.:..ti .. .
. t t={ f .o z:
P> ~t{ : ~~::: 0
~
Mailbox Write Ownershi
P
10 1= DSP has Write Access
0= Host has Write Access
1= Host has Read iviailbox
DSP Miscellaneous Semaphore bit
Host MisceIlaneous Semaphore bit
15 Iteserved
Host AppRegs Status Register (HOSTAPPSTAT)
This Read-only register, as shown in the table below, allows the Host Software
to monitor the status of the Mailbox.
Bit #0, Mailbox Write Own, allows the Host to determine who may next write
into the
Mailbox.
Bit #1, DSP has read Mailbox, allows the Host to monitor when the DSP
processor
has received a transmitted message in the Mailbox. Bit 1 will be latched as a'
1' when
the DSP has read the least significant data byte of the Mailbox. As soon as
the Host
reads HOSTAPPSTAT, this bit will automatically be cleared and re-armed for the
next
DSP Mailbox read.
Bits #2 & 3 are read-only status bits which reflect the semaphores written
(and read) in
the DSPSEMA and HOSTSEMA registers.
67
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
RevisW Address (READ ONL
.... ....: ::::::::: :: ::::::::::... , .. ....... ...... . . . .
DEgt?:::::.::::::::::::::::::::::::>:;;' _:::::::::::::::::
Not Visible 0x0040-0x0041 0x0040-0x0041
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
y .. ..: ,.: ~ = ::: ~:.. :;~.,, : :, =:.<:.:. ;:.,;:,: =:::::.;
~e{;' ;i,~= {y ~y w;~:.Qj u; { {y~}.. ;~. =/y .
~;p=+~' ;2~.ci ~,~'=1f-::' iV:s' ?'~i :~:~<. ;+xi,.. ~.~:f.=. :::~$. :%~i7'i<
=>:VS::~ 0 0 Q o
Mailbox Write Ownership
1= Host has Write Access
0= DSP has Write Access
1= DSP has Read Mailbox
Host Miscellaneous Semaphore bit
DSP Miscellaneous Semaphore bit
Reserved
AppRegs Lock (APPLOCK)
This 16-bit Read/Write register, as shown in the table below, allows the DSP
to
lock-out Host write access to the Command/Response register. Setting this
register to
Ox01 effectively makes the Mailbox one-way from the DSP to the Host.
From the Host perspective, this register is read-only.
Reaister Address (READ / VVRTIB)
: ..... ..
Ox18AI Ox0042-0x0043 0x0042-Ox0043
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
{ . :: i; ~ ~~~~+ :i ~"i: '!.! : i:L;~ ~= ii:.~. '}~'/:i:. 0
: {~!. :~%~ '= i ';~55 =:..:Si=':~. :'.:~::;. ;;.~?:i ;;ii~: :;:~I::% :?ii%~:
~:T3ii~ E~'~i''-i' ::7i::.. ..
I
Mailbox Lock
0= Host has Write Pemiission
I= DSP has Locked-out Host Writes
Reurved
68
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
DSP (Host) Miscellaneous Semaphore Register (DSPSEMA, HOSTSEMA)
Viewed from the DSP, this 16-bit Read/Write register, as shown in the table
below, allows the DSP Software to assert a semaphore bit to be read by the
Host via.
the AppRegsStatus register.
When viewed from the Host, the lsb of this 32-bit Read/Write register allows
the Host Software to assert a semaphore bit to be read by the DSP via the
AppRegsStatus register.
The CGX Kernel may be programmed to use these two bits for ownership
arbitration of the Hash/Encrypt subsystem. In order to enable this feature,
the =
appropriate CIS initfalization bit must be set when calling the CGX INIT
routine.
Refer to the CGX Software Users Guide for more details on the behavior of this
function.
If the above CGX usage of these semaphores is not selected, then they may be
used for any general purpose DSP to Host signalling.
DSPSEMA
Re Adcln%S (READ / WRiTE
::II.~s.;:' PCIi-iL'l~i....
Ox18A3 Not Visiuie Not'.9sible ~
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+= f.i:::. ~ijyti4.
:::;~= ,
(~ 0
y~ . ~=R:'; r.=' ::$~7i?. i:~.; \/
/~. :: :,>.;+ '.>f~;: i~'-'+: :j:~":. >:~'': i'!(~'i:'~=V ~.. :.~',
DSP Tvtisce11nC0us gemaphore bit
Reserved
69
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
HOSTSEMA
WRTTE
Re Address =AD/
Not V'isible Ox0044-OX0047 Ox0044-Oac0047
1514131211109876543210
.,:<. ~= ; ..:..:. : >r _ ,:: f. =:>: = ::r: ;:,;>:<;
.. !:'~~3= '~:.:'' 4 ~ '= 4=~S c: .' ;; f.~y.x. t ,. i~: %:'r o 'i':1~>'.:
=.at?=: . ikT.. ...SL~:: ta~:::i i'i~'::. :r,.tF:;. :~:~ ;. ;~.%~ :1f.~?: fG,.
.i=. :.:1~~5:: .G.. .'r.: :,>..7~f..; _ .;;Yt::~:
I Host Miscellaneous Sema
p$01'C bit
Roserved
Hash/Encrypt Byte Enable Register (HEBYTEEN)
This 16-bit Read/Write register, as shown in the table below, allows the DSP
Software to manage reading and writing fractional words in or out of the
Hash/Encrypt FIFO's. Since the DSP is oriented towards a 16-bit bus width, but
the
FIFO's can manipulate data down to byte granularity, it is necessary for the
DSP to
specify whether its low or high order byte is to be transferred in or out of
the FIFOs.
Re ' er Address QTWM&RD
ONL
: .:
Ox18A0 Not Visible Not Visible
1514131211109876543210
L 1= DSP low Byte Enable
1= DSP high Byte Enable
Resetved
Reset Reason/Instruction Register (RSTREASON)
This 16-bit Read/Write register, as shown in the table below, allows the DSP
processor to determine the offending address and memory type which caused a
Kernel
protection violation reset. The contents of this register are preserved across
a CryptlC
reset (although of course, not across a power-cycle.) This is useful in de-
bugging
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
software which is written for the User Mode of the CryptlC. Refer to section
previous described on Kernal Mode Control for more information about the
protection
features of the CryptIC.
The four memory types are as follows:
PM InsGniction Fetch An instruction fetch was made either to one of the four
blocks of
Kernel ROM (i.e. the 41sb's of PMOVLAY were set to OxC, D, B or
F and a fetch was made between address 0x2000 and Ox3FFF), or to
an internal program memory (PM) location which has been locked-ia
as Protected Memory by an Extended Mode program
DM Data Fetch A data fetch was made to an internal data memory (DM) location
which has been lockad-in as Protected Memory by the Kernel. With
the standard CGX kernel and no Extended Mode programs active,
none of the internal DM should be protected.
PM Data Fetch A data fetch was made to an internal progcam memory (PM)
location
which has been locked-in as Protected Memory by the Kernel. With
the standard CGX kernel and no Extended Mode programs active,
none of the internal PM should be proteeted.
Protected Registers/ A data fetch was made to either the Kernel RAM area or
one of the
Kernel RAM Data Fetch Protected crypto registers. This would mean that the
41sb's of
DMOVLAY were set to OxF and a data fetch was made between
address Ox0000 and Ox17FF
Due to a design 'feature' of the CryptIC, this register must be read twice,
ignoring the first data read.
Re ' Address (READ/ W1tITE
:a:?::::::::Ã : ::::::::::: .~: ::::::' :
>:: pCl ...:.......::....
Ox18A5 Not Viszble Not Visible
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
l0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
LC I I I 14-bit Memory Addreu which caased vioLiion
10 Memory Type wluch caused violation
00 - PM Ioahudion Fetch
01 - DM Data Fetch
10 - PM Data Fetch
15 11 s Protected Regiawa/Kanel RAM dats fetch
External Memory Configuration Register (EXMEMCFG)
This 16-bit Read/Write register, as shown in the table below, allows selecting
configuration settings for the external memory subsystem.
71
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Bit 0 configures the nature of the externat memory bus. It should normally be
programmed at CryptIC power-up and left unchanged. One effect of this bit is
that it
changes the behavior of external address bit [0] and the CS32 and DMS pins. In
16-bit
memory mode, only DMS should be used and AO functions to select even and odd
words of memory.
In 32-bit mode, then memory devices must be used which allow 16-bit bus
enables (e.g. either a 32-bit wide device with upper and lower 16-bit enables,
or a pair
of 16-bit wide devices). In this case, AO should be left disconnected. DMS
will select
the 'lower' 16-bits of external memory, and CS32 will select the 'upper' 16-
bits.
Bit #1, External Memory Own, allows the DSP to arbitrate who owns the external
memory bus: either the DSP or the DMA controller (and therefore also the Host
processor). Typically, software will leave this bit set to 1 except when
external
memory must be accessed by the DSP. This allows PCI Target mode transfers to
occur to ExtMem (since a Target transfer cannot always be predicted by the
DSP).
IRE's CGX software always leaves this bit set to 1(DMA controller owns),
unless it is in the middle of an operation which requires DSP access to
ExtMem.
Register Address (READ / WR1TE)
...,, _.
Ox18A6 1 Ox004C - Ux004F uxU04C - Jx004F
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
. ::==.= y. ....
%rf=i ' T=:fJ /::;; .i : ;;:{i : ' LFi=r,'./t. ji:i+:i: = .
:i , = ' <''"'~ ;.t~; :~~:>< v '> ;.. : >~ :: o o
I Extecnal Memory Width
0 = 32-bits
I = 16-bits
External Memory Own
0=DSP
1= DMA Engine (ie. Host)
Reserved
72
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
INTERRUPT CONTROLLER
Interrupt Controfler Overview
The CryptlC enhances the existing Interrupt controller within the ADSP 2183
DSP with some additional functions related to the Crypto functional blocks and
the
external Host bus interfaces. Two additional Interrupt Controller subsystems
have
been added to the basic 2183 Interrupt Controller as shown in Figure 10.
The DSP Interrupt Controller allows programming between 1 and 7 sources
for the IRQ2 interrupt to the DSP. The DIMASK register provides the Mask to
select
which interrupt source is enabled. A pair of status registers, DUSTAT and
DMSTAT,
allow the DSP firmware to read the status of any interrupt source either
before or after
the Mask is applied.
The Host Interrupt Controller allows programming between 1 and 4 sources
for the HostIntO interrupt output signal (which may be connected to the
interrupt
input of the Host system). The HIIVIASK register provides the mask to select
which
interrupt source is enabled. A pair of status registers, HUSTAT and HMSTAT,
allow
the Host firmware to read the status of any interrupt source either before or
after the
Mask is applied.
InterruDt Source Descriotions
The DSP and Host Interrupt Controllers support the following additional
interrupt sources, as shown in the table below.
73
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
. . . v:.:v. :.t=a~+ '1'=T.':o-:'i~:... . . . f=~:r.=..
::.: =:::... .,..:. ~, . = :: .. . .: _sr,.':i
r:,:F:;:%r;?::r='t;:;:SM:',;.;:R<:%;:.. .. ::., v..
. ':
: .: .. , :
,.r. .
~==' ,y;::.=..: r #,i=3.,t . ::$~i~ : ..: ~ == :.. ~ .S y:: .Y ;r ..;:SP r '.
r;:v:y.~ '= y~'. .'e=.,,.>=;yr~'i ....... , r . ,
b :t:... ~r. . . ~., : = .. J i . =/".: ~: j .- R' .. ~ = ry4: '':r3..
, :.,.;:.:o... r~2. ='.X''if~.'1~7i.= :. ... =: .:::. . s~{~''~==:.. = =:
:. . .:~~. .:=~..~=:..
Host hMmupt This is a software-forced ftmmrupt towards the DSP from the Host.
DSP Intemipt This is a soRware-forced intmnipt towards the Host from the DSP.
H/E Context 0 Done This indicates that the Hash/Encrypt engine within the
CryptlC has just
finished fully processing a command for Context 0. It will occur after either
the Length bytecount has decremented to 0 or if the H/E Control word is
written with an idle command (111 in the 3 Isb's).
H/E Context 1 Done Same as above, but for Context 1.
Host wrote Command The Host Processor has just written the least-significant
word of the
A licati on Re ' ers mailbox. This notifies the DSP of this event.
DSP wrote Command The DSP has just written the least-significant word of the
Application
Registers mailbox. This notifies the Host of this event.
Master DMA Transfer Done Indicates that a DSP-initiated Master DMA transaction
is complete. This is
triggered from bit 3 of the DMA Status/Confi. Register going from 1 to 0.
Master DMA Transfer Qaened Indicates that a DSP-initiated Master DMA
transaction has just been
queued in the double-buffered holding register, thus there is no room for
another DSP DMA command. This is triggered from bit 15 of the DMA
Status/Confi . register going from 0 to 1.
Host External Memory Conflict A DMA transfer was attempted to or from External
Memory, but the
ownership bit was not set to allow the transfer (ie. the DSP had ownership.)
See EXMEMCFG re ' in section 0.
Hash/Encrypt Error A Hash/Encrypt error occurred. The error code is given in
the H/E Error
Code register.
IRQ2 This is simply the IRQ2 external pin on the CryptIC. This allows the DSP
to 'OR' it in with the other crvpto-related interrupt sources
Table 8 Interrr~pt So:rrces
Interrupt Control Registers (INTC)
The Interrupt Control and Status Registers, as shown in the table below,
consist of two sets of 6 registers which allow the DSP or the Host system to
enable or
disable crypto interrupts, check the status of the most recent interrupt,
force an
interrupt, etc.
74
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
ADDRESS ADDRESS REGISTER R/W Reset DESCR>pTION
16 B (32 B NAME efaul
INTERRUPT CONTROLLER REGISTERS
P-Visible e Re ' ers:
DS
0x1800 N/A DSP Unmasked R Interrupt source ciurent states - Piior to mask
Status
0x1801 N/A DSP Ntasked R Internupt source current states - Post mask
Statos
Ox1801 N/A DSP Clear Im. W Clear selected IntmTupt
0x1802 N/A DSP Mask R/W Internipt mask register
Control
0x1803 N/A DSP Int Config. R/W DSP In t confi'on register
04804 N/A Force Host Int W Force interru t to Host (PCI/PCMCIA)
0x1805 N/A H/E Error Code R Provides the HB Error Code
Host-Visible Re 'sters:
N/A 0x0080-0081 Host Unmasked R Interrupt source carrent states - Prior to
mask
Status
N/A 0x0084-0085 Host Masked R Interrupt source current states - Post mask
Status
N/A 0x0084-0085 Host Clear Int W Clear selected intemipt
N/A 0x0088-0089 Host Mask R/W Interrupt mask register
Control
N/A OxOO8C-008D Host Int Config. R/VV Host interru t configuration re ' r
N/A 0x0090-0091 Force DSP Int W Force interrupt to DSP
N/A 0x0092-0093 HB Error Code R Provides the H/E Error Code
Table 9 Interrupt Register Set
DSP Unmasked Status Register (DUSTAT)
This 16-bit Read-Only register, as shown in the table below, provides
interrupt
status visibility to the DSP, prior to the interrupt mask being applied. Thus,
the DSP
can view all potential sources of incoming interrupt. All of these sources,
whether
masked in or out, will be latched in this register and must be cleared using
the DICLR
register in order to view a subsequent interrupt.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
ONL
OMD
Re ' ,ddress
x:=?Yri:fi .~~ ~.'is :a :a ~[
,jm~:>~iii'r.i?i :iSFS'rA'i;:a
:f:=<:;a$ai'::?2F~fiA.s:..~E[cr':ri".:i:?;:;;:m
0x1800 Not Visible Not Vistble
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
o o o o o o o a a
1 = IRQ2
L
1= Master DMA Tranafer has been Queued
1= Mester DMA Memoty Transfer is Done
1= Host Wrote Command Register
1= Hesh/Facrypt Ceaitext 0 is Done
1= Hash/Encrypt Context 1 is Done
1= Host Extetnal Memory Conflict =
1 = Host Issued lntecrupt
I = Hsah/Enctypt Euor
Reserved
DSP Masked Status Register (DMSTAT)
This 16-bit Read-Only register, as shown in the table below, provides
Interrupt Status visibility to the DSP, after the Intenvpt Mask is applied.
This lets
the DSP view the selected sources of Interrupts which are directed to IRQ2.
(Note that the DSP must enable IRQ2 via the IMASK register and the global ENA
INTS command must be issued in order to actually receive the interrupt.) As
with
the Unmasked status register, all interrupt bits are latched and must be
cleared
using the DSP Clear Interrupt register.
Address ONL
....,...... . .: :: =:: ::: ::::
:: :::: ....
::: ' .:;
0x1801 Not V'uble Not Vistble
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
o 0 0 0 0 0 0 0 0
., . ..: f. . . ... ~ .
~
L'1Q2
1= Master DMA Transfer has been Queued
1= Master DMA Memory Transfer is Done
1= Host Wrote Cmmawnd Register
1=1=Tesh/Eacrypt Context 0 is Done
1= Hesh/Enciypt Camtext 1 is Dwe
1= Host External Memory Conflict
I = Host Issued latenupt
I = Hash/F.ncrypt Error
Reserved
76
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
DSP Clear Interrupt Register (DICLR)
This 16-bit Write-Only register allows the Processor to Clear pending
Interrupts. It is located at the same address as the Masked Status Register
(Write vs.
Read) which facilitates performing a read to detect pending interrupts
followed by a
write of the same bits in order to clear the latched irnerrupt status.
Re ' Address (WRITE ONLY)
B.I/I. :: :
DSP:::::::::
0x1801 Not Visible Not Visible
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0
~
1 = Clear IRQ2 intemupt
10 H 1= Clear Master DMA Transfer Queued interrupt
1= Clear Master DMA Transfer Done interrnpt
1= Clear Host Wrote Command intemipt
1= Clear HashEnc Context 0 done intenvpt
1= Clear HashEnc Context I done interrupt
15 1 = Clear Host Ext. Memory Conflict Status intemtpt
1= Clear Host Issued Intemipt
1= Clear Hash/Enc Error intetrupt
Reserved
DSP Mask Control Register (DIMASK)
This 16-bit Read/Write register, as shown in the table below, allows
configuring the Interrupt Masks for the Crypto subsystem.
77
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Re ' ..... Address (READ / WR1TE
...............:. . . ..............~.,::::: = :. ............--
:;:b~:;:::::>:: p~ :::::::::: : .................
0x1802 Not Visble Nut Visible
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
'. 0 0 0 0 0 0 0 0 0
~ I
1= Meslc IRQ2
1= Mask Mester DMA Traasfer Queued
1= Mask Master DMA Transfer Done
1= Mask Host Wrote Command Register
1= Mask Hesh/Emarypt Context 0 Done atted
1= Mask Hash/Enctypt Context 1 Done
mm
1= Mask Extntnal Memory Conflict
1= Mask Host Isstud Iate:rnpt
I = Mask Hash/Enc Error
Reserved
DSP Interrnpt Coafigaration Register (DICFG)
This 16-bit Read/Write register, as shown in the table below, allows
configuring the Interrupt type which will be fed into the IRQ2 interrupt line
of the
CryptIC's DSP. Note that this only effects the final output of the Interrupt
subsystem.
Configuring for Pulse will cause the internal interrupt signal to pulse low
for two clock cycles when activated. When set for Level, the interrupt signal
will
be set low until cleared by the DSP (i.e. it will follow the bit in the Masked
Status
Register).
Address /
. ..
:.. ..,,.:...~-..::.: ....::.::>; , == .;:;:: :.:..;: ~:': > $~t ,.;
0x1803 Not V'~sible Not Visible
1514131211109876543210
I
Intarupt Output Swat Type:
I = Pulae, 0 = Level
Resaved
Force DSP Interrupt Register (DIFRC)
This 16-bit Write-Only register, as shown in the table below, allows the
DSP Software to Force a Crypto subsystem Interrupt to the emernal Host
78
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
processor. ihe data contents of the Write operation are ignored - any Write to
this address will cause an interrupt, if enabled by the HIlViASK register.
Re ' Address (WRrrE ONL
I ::.>= :.,.,: r > ;>:,. } .::<:::~;:::
::i3i's3~i:i:'~:= :i:'s~.:i:3i.2,#,:::2i':t~3.'.',3~~~~362~#:"?'s: ~>:;i.t
~rrr. . . ... . . . . . . . ..:. .. ... .. . r- .. :... ..... :.a: .o.::..r.
0x1804 Not V'~ble Not Visible
1514 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Ix x x x x x x x x x x x x x x X
~ I
Don't Care
DSP or Host H/E Errors Register (DSPHERR, HOSTHERR)
This 32-bit Read/Write register, as shown in the table below, provides the
error code which resulted in a H/E Error interrupt. Reading a'1' in a bit
position
within this register indicates the type of error which occurred. In order to
clear the
error latch, 0's should be written to the desired bit positions.
Re Address %EADMaUM
=ii'=> b ) i i' . .. . ........ 5. . , .. .. :..., .~' .... .
........ .. .. ...... .. . ..... .. ... . . . ..... : . .. :' :
0x1805 Not Visible Not Visible
13 14 13 12 11 10 9 8 7 6 3 4 3 2 1 0
:. :. .:. : . . ...: . ... .. :.. :. : 0 0 0 0 0
L1= Write attempted to Hash FIFO, buff not rdy
1= Write attempted to Crypt FIFO, buff not rdy
1= Attempted to uae Red key when not allowed
1= Attempt to vvdte Control word when not rdy
1= Overflow oparation on Length count (more
bytes writtea than noa-0 Length specifies)
Resecved
Host Unmasked Status Register (HUSTAT)
This 32-bit Read-Only register, as shown in the table below, provides
interrupt status visibility to the Host, prior to the interrupt mask being
applied.
Thus, the Host can view all potential sources of incoming interrupt. All of
these
sources, whether masked in or out, will be latched in this register and must
be
cleared using the HICLR register in order to view a subsequent interrupt.
79
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
can view all potential sources of incoming interrupt. All of these sources,
whether
masked in or out, will be latched in this register and must be cleared using
the HICLR
register in order to view a subsequent interrupt.
Address (READ ONLYI
Not Visft)le 0x0080 - 0x0081 0x0080 - 0x0081
1514 13 12 11 10 9 8'1 6 5 4 3 2 1 0
0 0 0 0 0
1= DSP Wrote Command Register
~ Li
1= Hash/Enoiypt Cantext 0 is Dmie
1= Iiash/Encrypt Context 1 is Done
1 = DSP Issued Intenupt
1 = Hesh/Eac Error
Reserved
Host Masked Status Register (HMSTAT)
This 32-bit Read-Only register, as shown in the table below, provides
Interrupt
Status visibility to the Host, after the Interrupt Mask is applied. This lets
the Host
view the selected sources of Interrupts which are directed to PF7 which is
normally
connected to the Host bus interrupt. As with the Unmasked status register, all
interrupt bits are latched and must be cleared using the Host Clear Interrupt
register.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Re ' Address ONL
:: .,..
............ . . .. .. . : ... ... ...... . .. . .. ... ... . . .. . ...
Not Visible 0x0084 - 0x0085 0x0084 - 0x0085
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
{q= 'ryj= =:=';} "rt.+. i:::;ry,j'! fC: =
...
. . ~. .. .:= ' = .
, ., r. =,... . i
r ~.r;. . . . 'i: =:'s : i:
:..,: ~: .<::~;: <>~<. :~..... . ' = .. =;: U U U 0 0
I ,_~ =
L 1= DSP Wrote Command Register
1= Hesb/Enarypt Eontext 0 is Done
1 = llash/Encrypt Coatext I is Done
1 = DSP lssued Interrupt
1 = Hash/Enc Etror
Reserved
Host Clear Interrupt Register (HICLR)
This 32-bit Write-Only register, as shown in the table below, allows the Host
to
Clear pending Interrupts. It is located at the same address as the Masked
Status
Register (Write vs. Read) which facilitates performing a read to detect
pending
interrupts followed by a write of the same. bits in order to clear the latched
interntpt
status.
Re ' ter Address ONL _OYRTM
:::::::::::::.:>:::: :::::::::::.
~~:~:~~a::::~t?
r.......... ... ..
Not Visible 0x0084 - 0x0085 0x0084 - 0x0085
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
::..:.:,..; , ::::~... .. ~. :.:: f ! :r=:;.;. : ::<;;~. .,;: r.
o 0 o 0 o
Li 1= Clear DSP Wrote Command iaterruPt
1= Clear Ha.ghEnc Context 0 done inteaupt
1= Clear HashEnc Context 1 done interrupt
1= Clear DSP Issued Interrupt intetrupt
1 = Clear Hash/Enc Etrorintetrupt
Reserved
Host Mask Control Register (HIMASK)
This 32-bit Read/Write register, as shown in the table below, allows
configuring the Interrupt Masks for the Crypto subsystem.
81
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Re ' Address /
.... . . . . ....... .
Not Vis7ble 0x0088 - 0x0089 0x0088 - 0x0089
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
:;:=. = :y: =:= . : , = ;.,.x :~ := ,. ~ ~ ,::,>:.=:.
0 0 0 0 0
Rqoster
Li I Mask DSP Wrote Command
1= Mask Hash/Enarypt Context 0 Done
1= Mask Hash/Encrypt Context I Done
1= Mask DSP Issued Inteaupt
I = Mesk Hash/Enc Faor
Resecved
Host Interrupt Configuration Register (HICFG)
This 32-bit Read/Write register, as shown in the table below, allows
configuring the Interrupt type which will be fed to the PF7 interrupt line out
of the
CryptIC. Note that this only effects the final output of the Interrupt
subsystem.
Configuring for Pulse will cause the PF7 interrupt output to pulse low for two
clock cycles when activated. When set for Level, the interrupt signal will be
set low
until cleared by the Host (i.e. it will follow the bit in the Masked Status
Register).
ReigtiLstfte r Address (READ / WRITE
...:.1U5::. : .... . ::
Not Visible Ox008C - OxOO8D Ox008C - Ox008D
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
>=,:. . . { ,: . a:::t::< = .: =:3 = ;>:;.,, = = ~x:=:,; ..... , ;,,.~:;;
;~~ ~
' .. :: y~i'~ x~: 1
taruPt Output Sipal Type:
Iln
1 = Pulse, 0 = Level
Reserved
Force Host Interrupt Register (HIFRC)
This 32-bit Write-Only register, as shown in the table below, allows the Host
Software to Force a Crypto subsystem Interrupt to the DSP processor. The data
82
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
contents of the Write operation are ignored - any Write to this address will
cause an
interrupt, if enabled by the DEVIASK register.
ONLY)
Re ' Address
. .. .. ....... ...... ..
~> :'<:I~~..:::
Not V'mble 0x0090 - 0x0091 0x0090 - 0x0091
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
X x x x x x x x x x x x x x x x
I I
Don't Care
SERIAL EEPROM
Serial. EEPROM Overview
The CryptIC provides an interface port for connection of a 2kbit (256-byte)
serial EEPROM (93C66 or equiv.). The principal purpose of this is to allow
automatic
boot-loading of the PCI or PCMCIA port configuration parameters. The serial
EEPROM is not mandatory however, since the DSP may directly program these
configuration settings into the PCI/PCMCIA bus core using the registers
described
below. It should be noted however, that the DSP must be able to program these
settings before it can communicate using the PCI/PCMCIA bus. This implies that
the
CryptIC could not be boot-loaded from the PCI/PCMCIA bus unless a EEPROM was
connected.
A secondary use of this EEPROM port can be application-specific. Since there
is extra unused space in the EEPROM, a user application may use the remaining
space
for non-volatile storage of a relatively small amount of data. Examples could
include:
A Black KEK, a digital certificate, a user authentication 'master' password,
etc.. Since
the EEPROM is directly connected to the CryptlC and can only be controlled by
the
DSP, there is a certain amount of intrinsic protection to this data store.
For PCI applications, the PCI configuration parameters occupy the first 13
locations of the EEPROM, leaving 243 bytes remaining for user-specific
applications.
In Cardbus systems, there is additional CIS storage required after the first
131ocations.
83
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
For PCMCIA applications, the CIS configuration parameters occupy the first
TBD locations of the EEPROM, leaving TBD bytes remaining for user-specific
applications.
For applications which do not use either the PCI or the PCMCIA buses, the
entire EEPROM (256 bytes) is available for applications.
In order for user appfications to utilize the serial EEPROM, a low-level
software driver must be written on the DSP to implement the unique bit-level
protocol
of the serial EEPROM. The EEPROM Command/Status port simply provides
read/write access directly to the four EEPROM signal lines: Serial Clock (SK),
Data In
(DI), Data Out (DO), and Chip Select (CS). Refer to the manufacturers
datasheet for
the EEPROM for information on its protocol.
'Manual' Host Bus Confiauration
As mentioned above, the DSP can override the automatic bootloading of the
Host bus (PCI/PCMCIA) static configuration parameters from a EEPROM. The
sequence of operations is as follows:
a) Set [bit 1] of the EECMDSTAT register to ' 1' to stop the autoload state
machine.
b) Write valid configuration into the first 13 EEPROM registers.
c) Set [bit 0 & bit 1] of the EECMDSTAT register to '1' to remove the
EEPROM busy indication and enable the Host bus.
d) Poll [bit 2] of the EECMDSTAT register to verify a'0' (not busy).
EEPROM Control Registers
The EEPROM Control and Status Registers, as shown in the table below,
consist of 14 registers which allow the DSP to directly configure the PCI or
PCMCIA
84
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
configuration registers. The last register, the Command/Status register allows
general
control of the serial EEPROM interface.
ADDRESS ADDRESS REGISTER IR/W Reaet DESCRIPTION
(16 B (32 B NAME Defaalt
SERIAL EEPROM REGLSTLRS
0x1900 N/A Device ID R/W 16-bit PCI device ID
0x1901 N/A Vendor ID R/W 16-bit PCI vendor ID(11D4h
0x1902 N/A Rev ID/Class R/W 8-bit chip Revision ID, 8-msb's of PCI Cless
Code
0x1903 N/A Class Code R/W remaining 16-Isb's of PCI Cless Code
Ox1904 N/A Header TypeAnt R/W PCI header t-vpe & Intemipt Pin
0x1905 N/A Subsvstem ID R/W 16-bit PCI Subsvstem ID
Ox1906 N/A Subsystem R/W 16-bit Subsystem Vendor ID
Vendor ID
0x1907 N/A Max Lat. Mm Gnt R/W Maximum Latencv, Min Grant parameters
0x1908 N/A Cardbusl R/W lower 16-bits of Cardbus CIS poitftr
0x1909 N/A Cardbus2 R/W upper 16-bits of Cardbus CIS inter
Ox19OA N/A Baddr maskl R/W Specifies 1= modifiable 0 = our addresses
Ox19UB N/A Baddr mask2 R/W U er 16 bits
Ox190C N/A CIS Size R/W CIS Size spec 16-bit (Upper 8 bits are 0)
Ox190F N/A Cmd/Status R/W EEPROM Command and Status Re ' er
EEPROM Command/Status Register (EECMDSTAT)
This 16-bit Read/Write register, as shown in the table below, allows control
and status monitoring of various serial EEPROM functions. It also provides
access to
the input/output lines of the EEPROM, if enabled.
Bit 0: Clear EEPROM busy indication. The DSP should write a 1 to this bit
after it
has loaded the 13 PCI configuration registers.
Bit 1: Allows the DSP to shut-off the automatic hardware state machine which
attempts to automatically download the PCI config/PCMCIA CIS into the bus
interface core. It must be set to a 1 in order to program the first 13 EEPROM
registers.
Bit 2: This bit indicates whether the hardware state machine is still
attempting to load
the configuration from the EEPROM into the bus core. It must be a 0 to enable
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
the PCI interface. It will clear to 0 if state machine finishes or if the DSP
writes
a 1 to bit 0.
Bits [7:4] allow the DSP direct access to the corresponding pins on the EEPROM
device. For these register bits to be active, a'1' must be written to the Stop
EEPROM
State Machine [bit 1] of this register.
Re ' Address (READ/ WRrM
... y ~/aq.-/..;/~....... ~.~!{~
...5 > ' ~~........ ... :. :~..}...li.~IM1.1.~..:....' ::::
. ........ . .. .......::.. . .........
Ox190F N/A N/A
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
~.. ..},Ff+. .y':.,. y~a~; ; ~fi:f, y:tifi, hro.~.': ti:s:.=:<~::::~
:.:~<:>:%~> :}~:::'~: M 0 X x X0 0 0
J Li
1= Force EEPROM busy clear & enable PCI (r/w)
10 1= Stop EEPROM state machine (r/w)
1= EEPROM Busy (read only)
Reserved
EEPROM SK (Setial Clock) (r/w)
EEPROM CS (Chip Select) (r/w)
15 EEPROM DI (Data In to EEPROM) (r/w)
EEPROM DO (Data Out from EEPROM) read only
Reserved
BOOT LOADING
Boot Loading Overview
The CryptIC provides multiple modes of boot-loading it operating software.
Virtually all implementations of the CryptlC require at least some application-
specific
code running on its internal DSP. Of course, the CGX security kernel is hard-
coded
into ROM on the device and does not need to be boot-loaded from the outside.
The boot modes are as follows:
= Byte Memory Booting (BDMA)
o Host Bus Booting
- From PCI
- From PCMCIA
86
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
- From IDMA
Local ROM Booting
Byte Memory Bootin~
In order to bootload the CryptIC from Byte memory, an 8-bit wide PROM
must be connected to the CryptIC's external memory bus in the 'Byte Memory'
space
(using BMS chip select).
.To specify bootloading from Byte memory via the BDMA port, the following
mode pin states must be set:
1VuvIAP = 0
BMODE=O
BUS MODE = Don't care
BUS SEL = Don't care
When the Crypt powers-up, it will automatically begin DMA'ing the first 32
Program Memory words (96 bytes) into the base of internal Program Memory (PM).
It will then begin program execution at address Ox0000 with a BDMA interrupt
pending.
In fact, this bootloading process is identical to that for a standard ADSP
2181/2183 device. Refer to the Analog Devices ADSP-2100 Family User's Manual
for more information on 'Boot Memory Interface'.
Host Bus Booting
The CryptIC may also be bootloaded via the Host processor bus interface. The
procedure is slightly different, depending on which bus mode is selected.
87
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
PCI Bus Booting
In order to bootload from the PCI bus, the following mode pin states must be
set:
MMAP=O
BMODE = 1
BUS MODE = 1
BUS SEL = 0
In addition, a serial EEPROM must be connected to the CryptIC in order for it
to automatically load its PCI default configuration parameters and enter the
PCI-
Enabled state.
Once the CryptIC is powered-up, its PCI core will automatically initialize
itself
and the DSP will enter a Reset state. It will then wait for code to be
bootloaded from
the PCI host.
The PCI host will initially program the necessary data in the PCI
Configuration
registers of the CryptIC (ie. Base Address Registers, etc.), and then may
begin
downloading a bootloader code segment into the CryptlC's internal PM memory
space. Downloading occurs by using Target mode IDMA writes into the internal
PM
space. See section PCI Address Map described previously for additional
information.
The procedure dictates that PM address Ox0000 be loaded last, since this
causes program execution to begin automatically (Reset is deasserted by the
CryptlC).
Refer to the Analog Devices ADSP-2 100 Family User's Manual for more
information
on 'Bootloading through the IDMA port'.
ACRONYMS/TERMS
ACRONYMS
The following table is a list of acronyms used with the description of the co-
processor.
88
CA 02303297 2000-03-13 .
WO 99/14881 PCT/US98/19316
Acronvm Meanin
ASIC A lication-S ci c Integrated Circuit
CGX C toG hic eXtensions
CT Cipher Text
DES Data En tion Standard
D-H Di e-Hellman
DMA Direct Memory Access
DSA Digital Signature Algorithm
N Initialization Vector
KCR Key Cache Register
KEK Kev Encryption Key
LSV Local Storage Variable
MAC Message Authentication Code
PCDB Program Control Data Bits
PIN Personal ldenti ication Number
PT Plain Text
SHA Secure Hash Al orithm
SHS Secure Hash Standard
TERMS
The following table is a list of terms used with the description of the co-
processor.
Term Meaning
BLACK Key A secret/private key that is encrypted or covered
by a KEK, it can be securely given to another
artv.
Covered Key A secret key that has been encrypted via a KEK,
to protect the key from being seen by an
undesirable artv. Similar to a Black kev.
Key Cache Register (KCR) A working storage area for secret keys,
addressable via a register ID between 0 and N.
Key RAM (KRAM) A volatile public key work area. The public key
will be lost during a power-down or reset.
Local Storage Variable (LSV) A non-volatile Laser-programmed secret key that
can be used by the application as its own unique
private key. Each CryptIC has a unique LSV
programmed into it at the actorv.
Program Coatrol Data Bits Programmable control bits to customize the secure
(PCDB) Kernel features (such as allowing RED key
exportation/importation, LSV changes, exportable
chip, etc.).
RED Key A secret/private key that is not encrypted or
covered by another KEK It is in its raw
un rotected orm.
89
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The following is a detailed description of the cryptographic co-processor
taken from a CGX interface programmer's guide prepared by the assignee and
owner
of the invention, Information Resource Engineering, Inc. (IRE). As with the
previous
description taken from the user's guide, the cryptographic co-processor is
often
referred to herein by the trademark 'CryptIC'. The co-processor is also often
referred
to by part number ADSP 2141. The following includes a detailed description for
software developers intending to use the CGX library embedded in the CryptlC .
It
includes an overview of the CryptIC's CGX software architecture, its key
management
structure, the command interface, and a detailed description of CGX commands.
Incorporated herein by reference is also the Analog Devices ADSP-2100 family
User's Manual which includes further information on programming the DSP
embedded within the CryptIC.
GENERAL DESCRIPTION
The CryptIC device is designed to be a highly integrated, general purpose
'security system on-a-chip'. It combines a set of high-performance Hardware
blocks to
accelerate time consuming cryptographic operations, together with an embedded
Digital
Signal Processor (DSP) which serves as a crypto system controller. The DSP:
- Implements a'Security Kernel' which simultaneously enforces certain security
policies within the CryptIC and insulates Applications from the details of
many
complex cryptographic operations.
- Can be used as a security co-processor to manage data movement between a
Host system and the CryptIC.
- Can be used to run general-purpose User applications such as a V.34 modem
or a Network Interface Card controller.
The Security firmware which is mask-programmed into ROM on the CryptIC is
designated as the CGX (CryptoGraphic eXtensions) Kernel. It is a suite of
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
approximately 40 functions which are available to Applications which require
security
services.
A protection model is built into the DSP so that security-related and real-
time
intensive applications can coexist. At any instant in time, the DSP can either
be
operating in 'Kernel Made' which means that one of the CGX commands is in
process
or it can be in 'User Mode ' which means that a user application is running.
In Kernel
Mode, all of the CryptIC resources are available to the CGX firmware. In User
Mode,
access to Key Storage locations and many of the Security Blocks is restricted
in order
to enforce proper security policy. A degree of multi-tasking can be achieved
between
User and Kernel processes, and Kernel Mode processing can be interrupted by
User
code. In addition, a subset of the CGX commands may be preempted by another
CGX
command.
To simplify Application-level access to crypto functions and allow the
coexistence of general-purpose applications running on the DSP, an Application
Programming Interface (API) is provided to the CGX Kernel. The CGX Command
Interface defines the boundaries between the security functions (which the CGX
Kernel implements) and the externally running applications, either on the
CryptIC's
DSP or on external Hosts communicating via the PCI/PCMCIA bus. A block diagram
of the CGX software interface is shown in Figure 11.
CGX SOFTWARE OVERVIEW
One of the primary goals of the CryptIC CGX software is to abstract the
hardware blocks of the CryptIC from the application in a secure and efficient
manner.
The CGX Kernel has been designed so as to avoid the common problems of linking-
in
security software with an application or worrying about what resources the
application
must set aside to accommodate the security software.
The CGX interface is designed so that it can be viewed in one of two ways,
depending on the preference of the application programmer. The actual CGX
interface
91
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
is the same for both views; the difference is in how the application utilizes
the CGX
interface.
= It can be viewed as a Crypto Library with a C-structure like interface with
argument and pointer-passing
= It can be viewed as a Hardware-accelerated subsystem of the chip, with a
register-
based interface
In the hardware-oriented view, the CGX interface appears as a 21-word
register set (the command block) which is mapped into an application-specified
memory space in the CryptIC. This is similar to the concept of the MMX (Multi-
Medza eXtension) instructions enhancements to Intel's Pentium chips. The
CryptIC
can similarly be viewed as a single-chip general-purpose processor with added
CGX
(CryptoGraphic eXtensions) instructions.
To implement the CGX command set, both hardware and software components
are integrated on the CryptlC. The hardware components are essential in
providing
the crypto acceleration and for the protection/security of the CGX Kernel and
key
material from the user application and the external world. As shown in Figure
12, the
CryptlC's hardware components are accessed mainly in the Crypto Library, and
some
are also used in the CGX Command Processor to implement protection features.
The CGX software resides within the dashed line illustrated in Figure 12. The
application runs on the DSP and uses the CGX Command Interface as an API to
access the CGX command set. To better understand the software architecture of
the
CryptlC security software, a description of each layer is provided in the sub-
sections
below.
Application Layer
The application layer is where the actual application program and data space
resides. The application has full-control of the general purpose DSP and its
associated
92
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
hardware resources. In order to access the cryptographic services, the
application
must invoke the command interface and pass-in a command code and arguments.
The
application running in the User space of the DSP can implement anything from a
router
security co-processor to a V.34 modem data pump.
Residing as part of the application layer are the macro functions which IRE
provides in its cgx.h file. These macros assist the application in preparing
the
command messages prior to calling the CGX kernel.
CGX Command Interface Laver
The CGX command interface layer is an Application Programming Interface
(API) which defines the boundaries between the application and the CGX Kernel.
The
CGX command interface provides the hardware mechanism to enter and exit the
CGX
Kernel to execute a specific cryptographic command. Part of the command
interface
function invokes the kernel protection logic to isolate the CGX Kernel and its
associated security resources from the external application via the Kernel
Protection
Logic built into the CryptIC. This prevents the possibility of leaking Red key
material
or of unauthorized external access to the CGX Kernel's program or data space.
The software interface to the CGX Kernel is via a data structure called the
kernel block. The kernel block is split into two fields: the command block and
status
block. The command block is used to request a specific cryptographic command
and
to provide a means to pass-in arguments. The status block provides the
application
with a means to track the status of the CGX Kernel (i.e. is it active or idle)
and a
means to determine the result status of a requested cryptographic service.
Therefore, all communications between the application and CGX Kernel is via
the command interface and a Kerrrel block. The command interface is discussed
in
more detail in the section Command Interface.
93
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
CGX Command Processor Laver
The CGX Command Processor implements a secure Operating System
responsible for processing application requests for various cryptographic
services. The
CGX Command Processor is invoked by the application via a call to the CGX
entry
address (0x2000 with PMOVLAY=0x000F). Once the CGX Kernel is active, it can
process the requested cryptographic function specified in the kernel block
defined as
part of the CGX command interface layer. The CGX Command Processor is
responsible for maintaining the security of the internal cryptographic
software, key
material, and associated security devices.
Like other operating systems, the CGX Command Processor is responsible for
time-sharing the security resources. It does this through DSP context
management,
preemption management, and system integrity management.
DSP Context Mana eg ment: Once the CGX Command Processor is activated
via the call to address 0x2000, it invokes its DSP context management
software. The
DSP context management software is responsible for saving the application's
current
context (i.e. the DSPs registers, frame pointer, and stack pointer). This
allows the
CGX Kernel to use the full DSP register set. Furthermore, the CGX Command
Processor must update the application's status block to reflect a'running'
state. Once
a cryptographic funetion is complete, the CGX Command Processor cleans up,
modifies the application's status block with the result of the cryptographic
service,
restores the applications DSP context, and returns back to the application.
Preemption Manaaement: For certain CGX commands, the Command
Processor can allow a new command to preempt a running one. This includes when
it
is actively processing one of the public key or digital signature commands and
the
preempting command is a hash or symmetric key command. This feature is
provided
because some of the public key commands can take hundreds of milliseconds to
complete. However, if a preemptive request comes in and the CGX Kernel is ~o
94
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
executing one of the preemptable commands, the CGX Command Processor will
return a CGX BUSY S status code and will not execute the command.
Sygtem Integtiy Mana eg ment: Lastly, the CGX Command Processor is
responsible for monitoring the security integrity of the CryptIC software and
hardware
resources. As part of initialization processing, the CGX Command Processor
runs a
suite of self-tests to verify the health of the security components. The CGX
Command
Processor will not give control of the DSP to the application until the self-
test suite
completes successfully. Furthermore, there are several protection mechanisms
to
prevent key material leakage which require the CGX Command Processor to
explicitly
set hardware register bits enabling specific cryptographic service. This level
of control
is only permitted for the CGX Command Processor; thus preventing accidental or
intentional access to areas of the security blocks not allowed.
CGX Overlav Laver
The CGX overlay layer is provided as the interface into IRE's CryptoLIB
software. The CryptoLIB software is a library that is designed for multiple
platforms,
ranging from the PC to embedded systems. The CGX overlay acts as the 'wrap
code'
to enable the library to execute on the CryptlC platform unmodified. Figure 13
illustrates the data flow through the CGX overlay layer.
When a cryptographic request is received, the CGX Command Processor
parses the kernel block to determine the cryptographic command to execute. The
CGX Command Processor executes a CGX overlay operation from a table, based on
the command value embedded in the command block portion of the kernel block.
The
CGX overlay operation is responsible for extracting the arguments from the
kernel
block and invoking the proper CryptoLIB operations. In some cases, the CGX
overlay
operation may invoke several CryptoLIB operations. In effect, this is an
object-
oriented approach where the CGX overlay class is the parent class to the
CryptoLIB
classes.
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
CrvntoLlB Laver
The CryptoLlB layer contains IRE's Crypto Library software and it also
contains drivers for the CryptIC hardware blocks as well as 'soft' versions of
the
hardware algorithms (the soft versions are ifdef ed out at compile time for
the
CryptlC). The CryptoLIB software is a library of many cryptographic classes
implementing various cryptographic algorithms from symmetrical encryption
algorithms to one-way Hash functions, to public key operations.
The CryptoLlB API is transparent to whether it is running with hardware
acceleration or utilizing the library's software crypto functions. This hides
the
implementation of the CryptIC platform and allows full reuse of the general
CryptoLlB
software. This provides several advantages including:
= The CryptoLlB software can be independently used in the PC environment
= The software only 'C' version of CryptoLIB can be used during development of
products which will use the CryptIC.
= Enhancements and modifications to the CryptoLlB can be made and tested in
the
PC environment before migrating them into the hardware of the CryptIC.
CGX SOFTWARE COMPONENTS
This section describes the various software components that make up the
CryptIC in more detail than the previous section. From the CGX programmer's
perspective, it is primarily an architectural reference, since most of this
functionality is
hidden inside the CGX kernel.
Cg_X Command Processor
The CGX Command Processor is made up of many software components:
= Reset processing
96
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
= Initialization processing
= Contention/preemption/reentrance processing
= Configuration storage
= Key storage
= Command interface
= Context management
= Kernel operations
The following sub-sections describe the components that make up the CGX
Command Processor.
Reset Processing
When the CryptIC is first powered-up, or after any Reset event, control is
given to the CGX Kernel prior to allowing any application code to execute. The
CGX
Kernel performs a very quick 'reset-initialization': It first checks a 32-bit
INIT flag
location in KRAM to determine if the Kern.el has previously been initialized.
If it has,
then the DSP's Computational registers and DAG registers are cleared. If the
Kernel
has not been initialized, then the DM Reserve and P1VI Reserve registers are
cleared in
order to free the DSP's internal PM and DM for application use. Finally, the
CGX
Kernel jumps to address Ox0000 in program memory (PMOVLAY=O) to resume the
normal reset sequence.
Initialization Processing
There are two modes of initialization processing in the CGX kernel: Full-Init
and Basic Init. Full-Init occurs when the application issues the CGX IlSTIT
command
to the CGX kernel. Basic-Init is a safety net which will be automatically run
if a CGX
command is issued prior to the Full-Init being run. .
The Full-Init actually executes the Basic-Init processing, but in addition
provides some Kernel and Hardware configuration capability. When CGX INIT is
97
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
called, the application may supply a Kernel Configuration String (KCS) and/or
a
Program Control Data Bits (PCDB) configuration string in order to modify the
behavior of the CGX kernel and the hardware functions of the CryptlC.
At some point after a reset, and the application code has control, the first
CGX
command is executed, passing control to the CGX Kernel. When the CGX Kernel is
entered, it must first determine what type of operation to perform: Basic
Initialization
or CGX command processing. To determine what to do, the CGX Kernel reads the
INIT flag, which is a 32-bit location in Kernel RAM. This flag represent the
initialization state of the CGX kernel: If the flag is set to a pre-determined
value, then
it is an indication that the kernel mode has been previously entered and
initialization
has occurred, thus the CGX Command Processor proceeds to service the kernel
block
and implement the requested CGX command.
If the flag is not set to the proper value, then the kernel will assume that
it first
has to perform Basic-Init processing.
Note that it is normally expected that the application will first execute the
CGX INIT command prior to requesting any other CGX commands.
However, since this cannot be guaranteed, the following processing is included
in the CGX entry processing.
Basic-Init Processing
If the CGX Kernel sees that the INIT flag has not been set when a CGX
command is issued, it first enters the 'Basic-Init' mode to perform self-tests
and other
initialization steps. Upon returning from Basic-Init, the CGX Kernel sets the
1NIT
flag, assuming the self-tests pass. From this point on, until the next power-
cycle, the
INIT flag will indicate that the kernel has been initialized and the CGX
Kernel will not
re-execute the startup self-tests.
As part of the Basic-Init processing, the CGX Kernel executes a set of self-
tests to check the integrity of its ROM (using a pre-calculated MAC) Kernel
RAM,
98
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
and associated security devices (i.e. RNG). If any of these self-tests fail,
the CGX
Kernel returns a failure code (ie. CGX RAM FAIL_S)to the application via the
status
field of the kernel block and does not set the INIT flag. Furthermore, it will
not
execute any command until the self-tests pass and the I1VIT flag is written
with a valid
value.
Once the self-tests complete successfully, the CGX Kernel can proceed with
the remainder of its initialization. There are several areas to initialize,
the extended
RAM/ROM Reserve bits, the PCDBs, and the KCS. Once the Basic-Init is complete,
the CGX Kernel will proceed to process the original requested CGX command.
Full-'Init Processing
At any time after reset, the initialization mode can be reentered by the
application by using the CGX INIT command. As part of the initialization
command,
the application must pass in two initialization strings, the PCDB string and
the Kernel
Configuration String (KCS). The initialization strings are an array of defined
bits to
allow the application to set, disable, and enable various features of the CGX
Kernel
(KCS) and of the CryptIC hardware blocks (PCDBs). Once the full initialization
is
complete, the CGX Kernel enters an idle mode and returns to the caller,
waiting to
service application requested CGX commands received across the command
interface.
The following sub-sections define the initialization strings and the areas
that are
initialized as part of the Basic-Init or upon the application's request for
the CGX INIT
command.
PMIDM Reserve Bits
If the initialization mode is entered for the first time, the INIT flag will
not
match its predefined value. In this case, the initialization routine must
clear the
P1VI Reserve and D1VI Reserve registers. These are two 16-bit registers for
which
each bit represents a 1 K memory block of internal PM or DM memory. A bit set
to '1'
99
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
indicates that the corresponding lk memory block has been locked into use by
the
CGX Kernel and cannot be accessed in user mode.
These bits are preserved through resets. Therefore, if any of the
PM/DM Reserve bits are set (i.e. a 1) the CGX Kernel must erase the RAM blocks
that are locked, since there may be sensitive information in this memory. Then
after
each locked block is erased, the CGX kernel can release them by clearing the
PM &
DM Reserve bits to a 0.
Programmable Control Data Bits (PCDB) Initialization
The PCDBs are laser-programmed at the factory with a set of defaults and may
later be changed by the application via a special unlock-data token that IRE
or a
designated OEM can provide. The end-user can use an unlock-data token provided
by
IRE to later enable/disable various features via the initialize command (i.e.
CGX INIT). Managing the access to the PCDBs with an unlock data message allows
IRE or other OEMs to control what type of services customers have access to.
The
PCDB bits must be initialized if not already done. Initially, the laser-burned
copy of
the PCDBs are moved to the working RAM copy. However, by invoking the
CGX INIT command, the application can re-program some of the RAM shadowed
PCDB bits, providing a digitally-signed token is presented along with the
request.
If the application desires to later change the PCDBs back to the factory laser
default, the application can use the restore-default command, CGX DEFAULT.
The PCDBs allow the application to customize the CGX Kernel's
cryptographic operations and control. The PCDBs contain such items as: a bit
to
allow importing Red KEKs, enabling/disabling crypto-algorithms to make a
device
exportable, configuring symmetric and public key lengths, etc. Refer to the
section
Kernal Comfiguration String (KCS) for a detailed description of the PCDB bits
and
their meanings.
100
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Contention, Preemption, and Reentrance Processing
The CGX Kernel is preemptive, and for cestain commands it is also reentrant.
Being preemptive means that if an interrupt occurs while the CGX Kernel is
active, it
allows the interrupt to vector to the application's interrupt service routine
(ISR) in
'User memory'. Then after the interrupt has been completely processed, the CGX
Kernel is resumed via the application's Return From Interrupt (RTI)
instruction; thus
the preempted CGX operation is continued.
For certain CGX commands (ie. public key and digital signature), it is
possible
to interrupt the command while it is running and then, within the interrupt
service
routine, issue another CGX command. The CGX Kernel firmware maintains two
stacks and workspaces in order to allow 1 level of preemption/reentrance. The
CGX
commands are shown in the table below.
.< .. : y~,r <.;:..2:,::..,.i . ...... .:v .::= =-
=::.. }o :.:-~.:=..:: ... ::=:.::~:<...;=.:::'ta ~ . .:.3,1 ':, ............
.... ::.~:.=:.;~7.;..':
-'~;~'.'~.~= . ' :~,''''1t+'',~~:; .r~;:: ~;.:~X<;'<~.~::;:o. r y f= <e;.::;a.
s=' ''r'>~3:E*i=':ri:;:u; = .;; =: =
. =:~.= ' .y ~~ "~'~o'~',=: :4:~.'i'h;= k, == ;'=i~=
:~; -~=~ .= -,;~'s~;::s~ ~ .;;y,.:. ~ ,~ ; .'
+=I;~'~/~=I.{::J :Si;i.';{:in+:, ty t y +ni::: :~5:~. ~~~~'...:~~ ,., =.1 'Sa
.
~='iy\~. Ci,. yiY:=....... ..... ~~~' ,~Y.[ x~ . ,=~:vy..:...
=:= '>~Oa';{:!:~~, =..M~... : .+{H.~.;i=~~hti1.~ .}:=. i n ti=Yf.: {~T??~
XrFiF::}:v.~~.Y~'=,f.:} :l1.R?=. :'vx}..v,=n=i:i[ Y.-
Y.~.ri~:%Si~}::<::fV:~=:'<
CGX INTr
CGX DEFAULT
CGX RANDOM ~
CGX GET CHIPINFO ~ ~
..
: :::::: ::::: :
s . brt~>~et?.L'omnranr~ ::: .....................................
.............................. ....... : .;..::.
CGX UNCOVER KEY ~
CGX GEN KEK ~
CGX GEN KEY ~
CGX LOAD REY ~
CGX DERIVE KEY ~
CGX TRANSFORM KEY ~
CGX ERPORT KEY ~
CGX IIvlPORT KEY ~
CGX DESTROY KEY ~
CGX LOAD KG ~
101
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
I cGx ENCRYPT ~
CGX DECRYI'T ~
. .................
.:..:..:......... t
l'omiitrlrt~l's
CGX GEN PUBKEY ~
CGX GEN NEWPUBKEY ~
CGX GEN NEGKEY ~
CGX PUBKEY ENCRYPT ~
CGX PUBKEY DECRYPT ~
CGX EXPORT PUBKEY ~
CGX EXPORT PUBKEY ~
;>
:
::::.L#t . ....trtre.C6mnur~iLs
CGX SIGN ~
CGX VERIIY ~
~zrrened~l..:: ...............
CGX LOAD EXTENDED
CGX EXECUTE EXTMNDE ~ ~
D
:. : ...: . .::.
CGX HASH INIT ~
CGX HASH DATA ~
CGX HASH ENCRYPT ~
CGX HASH DECRYPT ~
102
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
. . ..k~J~.~C~M'. ~ - > 5 > t +~Y kt > > } }Y {
'..... ....:... .:..: .::. .....:.... ..:...... . ':..:.... ........ -.
:........ .. ....... . ...:.............
CGX PRF DATA ~
CGX PRF KEY ~
CGX NILRGE KEY ~
CGX MERGE LONG KEY ~
CGX LONG2BLACK ~
.>:
>
::. .1~
..::.. , ., <
CGX GEN RKEK
CGX SAVE KEY
:.
.....
:: .. ~ tatft;~om ~a~r:..... .:: :.. . .. ..:.. : . . .. ....
CGX MATH ~
Table 10 CGX Command Preemption
If an application attempts to perform a CGX preemption (ie. 2"d call into CGX)
which violates the above policy, or if it attempts to preempt a CGX command
with
another one while the Kernel is already running a 2~d command, then the CGX
call will
return quickly with a CGX BUSY S error code in the Status block. In this case,
the
application will have to return from interrupt in order to let the currently
running CGX
command complete before attempting another CGX call.
To aid the application in determining the state of the CGX Kemel, a simple
contention management scheme is available to the application. Contention
management is necessary in order to prevent the application from attempting to
re-
enter the CGX Kernel while it is in a preempted state. This is a simple
problem from
the stand-point of the CGX Kemel because intemally it can maintain semaphores
to
determine if preemption of an active command is allowed or whether it is
already one
level deep, executing a 2"d CGX command. To easily allow the application to
determine the CGX Kernel's state, the status of the CGX Kemel (i.e. active,
complete,
etc.) can be queried by the application at any time. The state can be obtained
by
looking at the current status block in DSP intemal or external memory (the
status
block is part of the kernel block, as explained later).
103
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
This scheme has three advantages: First, the application does not have to
invoke a command to query the state of the CGX Kernel, it can be read directly
from
the status block in memory. Secondly, it removes the complexity and burden of
the
application keeping track of the CGX Kernel's state on its own. Lastly, the
status
block provides the means for the CGX Kernel to retrieve the status result of
the CGX
operation (success or error code) which can be used by the application to
debug/test
the cryptographic operations.
Saving DSP Context at Intenupt
When a CGX operation is interrupted by the application, certain elements of
the DSP processor's context must be saved and then restored upon return-from-
interrupt. (This is of course necessary with any interrupt service routine.)
The DSP
hardware automatically saves the Program Counter on the hardware PC Stack and
the
Status Registers on the Status Stack. It is up to the application to determine
if it
should pull these values off of the hardware stack and move them to an
application
software stack.
In addition, the interrupting code must save the DAG registers, the PX
register
(lower 8-bits of Program Memory reads) and PMOVLAY, DMOVLAY registers as
well as the computational registers (2 banks). In order to optimize interrupt
processing, the application code can be designed to run in the Primary
register set,
while the CGX code can execute in the Secondary set. In this case, the
application
code will have to insure that the register set selection (MSTAT register) is
properly
handled upon interrupt and return-from-interrupt.
Once the external interrupt service completes, it restores the CGX Kernel
context and invokes the RTI operation. The Status registers and Program
Counter are
automatically popped off the hardware stack at the RTI instruction. The retuin-
from-
interrupt operation vectors back into the CGX Kernel mode, at which point the
Kernel
Protection logic will resume and the interrupted CGX command processing will
continue.
104
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Storage Management
The CGX Command Processor is responsible for the storage devices associated
with the security block of the CryptIC. The storage areas that concern the CGX
Command Processor are the CGX Kerael's KRAM, the volatile Key Cache Registers,
and the PM/D1VI Reserve RAM blocks.
Furthermore, for the CGX Command Processor to fuliy protect key material
and algorithms, it provides a protection of the DSP's registers as well as its
RAM
space. Although the RAM space is protected via specialized hardware, the CGX
Command Processor uses critical regions (interrupts disabled) to protect
registers. For
exaniple, when key material is moved in or out of the Kernel RAM, the DSP's
registers are used. Therefore, a potential to read the key material exists
should an
intruder try to single-step the CGX Kernel via interrupts. Although the
application can
not read the protected KRAM and kernel ROM, it could read the DSP's registers.
Therefore, all key material movement is done via the mem cpy operation. This
operation copies data from one place to another with interrupts disabled, and
at the
end it sets the registers it used to 0. This prevents applications from single
stepping
the Kernel. The same is done to the pm cpy operation which is used to read
program
memory.
As mentioned earlier, the hardware provides key aspects to protecting various
memory stores. In particular, the hardware provides several bus transceivers.
to only
allow one memory to be accessed at a time. So that when the external RAM/ROM
is
accessed the external application can not read any of the CGX Kernel's
internal
memory (KRAM, kernel ROM, and extended RAM/ROM). Furthermore, the bus
transceivers are placed on some of the security block memory devices in order
to
prevent the CGX Kernel from accidentally mixing Red key material with other
memory
devices used by the CGX Kernel. The following sub-sections outline the areas
where
the CGX Kernel enforces the security model.
105
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
Yolatile Key Storage
The volatile key storage houses the private portion of a public key in the
public
key area and a fixed number of secret keys in the Key Cache Register (KCR)
area. The
volatile key area is also referred to as the actively working keys. All
cryptographic
commands operate only on the active volatile working keys. The application is
responsible for moving keys between the outside world and the KCRs.
The CGX Command Processor only allocates enough space in the volatile
KRAM for 15 symmetric Key Cache Registers. The CGX Command Processor
provides ease of access to the secret keys by allowing them to be referenced
by a
register ID with numbers from 0 through 14.
Extended (Reserved) RAM Blocks
Under various circumstances, one or more lkword segments of PM and/or DM
memory can be locked-into the kernel space. For example, as part of the CGX
INIT
processing, the application can request to allocate some of the DM towards
extending
the number of Key Cache Registers.
The CGX Command Processor takes care of setting and resetting the
PM Reserve and DIvI Reserve bits to lock and unlock blocks of memory. It also
manages the secure information which is stored in these blocks and insures
that if a
block is unlocked, that its data is first erased.
Command Interface Processing
The CGX Command Processor is responsible for managing the command
interface between the application and itself or the cryptographic services.
The
command interface to the CGX Kernel is accomplished using a shared memory
block
and a special transfer address mechanism. The shared memory block (kernel
block)
provides the means for the application to communicate with the CGX Kernel,
allowing
the application the ability to query the CGX Kernel's status and request
cryptographic
106
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
services. The special transfer mechanism (CGX Kernel transfer routine) allows
the
application to invoke the CGX Kernel. The command interface is described in
detail in
the section Command Interface.
Command Processor Micro-Operations
The CGX Command Processor is similar to a command interpreter; it
consumes the command and its arguments, invokes the proper service to execute
the
command, and returns the result. However, the CGX Command Processor is a
little
more complicated than that since it must perform several more micro-tasks
similar to
an OS. It must perform context switching, I/O services, and monitor the
security,
integrity, and health of the internal hardware components.
The CGX Command Processor is comprised of three modules of software: the
entry code, the cryptographic service executor, and the exit code.
Enby
When the transfer vector is initiated by the application, the CGX Kemel is
entered by setting the PMOVLAY register to Ox000F and then executing a CALL
0x2000 instruction. From the call instruction and some associated hardware
logic and
signals, the internally ROM encoded CGX Kernel program block is overlaid in
the
upper portion of the DSP's program space. This allows the CGX Kernel code to
become active and transparent to the application. When the ROM-based CGX
Kernel
program block is overlaid, the processor immediately branches to the CGX
Command
Processor entry handler. The purpose of the CGX Command Processor entry
handler
is to determine the type of service it must perform. The entry code is all
written in
assembler due to real-time constraints of context saving and service
restoration in the
case of a command preemption.
The entry code runs with all interrupts disabled upon entry. The interrupts
remain disabled for just for the entry code, until a point at which the CGX
kernel has
verified that it can perform the operation and has saved the application's
context.
107
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Once the entry code is operational, it sets up a local stack to execute from,
and the CGX Command Processor saves the context of the externally running
application (i.e. saves registers, the PC return address, the stack pointer,
frame pointer,
etc.), assigns a global pointer to the command block, writes a CGX RiJNNING S
code to the external status block (i.e. the CGX Command Processor is active),
reenables interrupts, and calls the cryptographic command interpreter
(described in the
next sub-section).
However, if the CGX Command Processor is already active, it sets up a second
local stack to execute from, (i.e. it is. now being preempted) it saves the
context of the
externally running application (i.e. saves registers, the PC return address,
the stack
pointer, frame pointer, etc.), it saves a context of the preempted
cryptographic
command (i.e. save the global pointers to the command/status blocks, etc.),
assigns a
global pointer to the command block, writes a CGX RUNNING S code to the
external status block (i.e. the CGX Command Processor is active), reenables
interrupts, and calls the cryptographic command interpreter (described in the
next sub-
section).
Cryptographic Service Execution
The cryptographic command interpreter is fairly simple. The code accesses the
command block pointer established in the entry code and based on the command,
it
invokes a cryptographic operation from a table of CGX overlay operations. No
arguments are passed into the overlay operations. The overlay operations use
the
command block pointer to get access to the argument list. Figure 14
illustrates this
hierarchical approach to accessing the cryptographic operations.
The purpose of the layered hierarchical approach is simply to isolate the
knowledge each layer needs to operate within the CGX Kernel. This allows the
lowest
level, the CryptoLIB to only have to implement cryptographic operations. To
make
this work, a middle layer called the CGX overlay is provided. The middle layer
108
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
actually implements the wrap code around the cryptographic library, enabling
memory, accessing the key RAM, etc..
As Figure 14 shows, the overlay operation is responsible for invoking the
CryptoLlB operations in order to carry out the requested cryptographic
service. The
overlay wrap code extracts the inputs and outputs from the command block and
passes
them as arguments to the CryptoLIB operations. Furthermore, the overlay
operations,
which are actually CGX Kernel operations, are responsible for enabling write
access to
external RAM and for updating the status field of the status block. This
isolates the
control of the sensitive hardware access features to the CGX Kernel only. Once
the
overlay operation is complete, the exit code is invoked.
Exit
The exit handler of the CGX Command Processor performs the following:
= disable interrupts to establish a critical region,
= restores the external application's DSP context,
= writes the result code to the status block,
= re-enables interrupts, and
= cause the transfer back into the application and user memory space.
Also, as a security precaution, the write access enable to external RAM is
disabled before returning to the application.
CGX Overl
The purpose of the overlay operations is two fold: first, it provides a
standardized interface to IRE's CryptoLlB. The overlay operations contain some
wrap
code and calls to CryptoLIB operations. The second purpose is to allow the
reuse of
IRE's CryptoLIB intact. Without the overlay operations, the CryptoLIB code
would
have to understand the kernel block interface; thus creating a non-standard
package.
Instead, a clean implementation of the CryptoLIB, using a C interface, is
possible.
109
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
There is a CGX overlay operation for every cryptographic command provided
by the command interface. The CGX operations reside in a single table that is
accessed
by the CGX Command Processor software by the command value embedded in the
command block of the kernel block. Part of this table are bits that represent
the
preemption requirements and the privilege access bits.
CryntoLEB
The CryptoLIB software is a library of software functions that implement a
full
suite of cryptographic services. It is designed to be portable and flexible
and the
interface allows for certain functions to be customized by the application.
The interface to the CryptoLIB follows the ANSI C standards, and the
CryptoLIB is all written in ANSI C format. The reason behind this is so that
the same
library base can be used in desktop environments as well as embedded
applications like
the CryptlC.
Therefore, since no special modifications to the CryptoLlB have been made,
the CGX Kernel is recognized as another application to the CryptoLlB software.
The
CGX Kernel uses the library calls as would any other application in a PC
environment
or another embedded environment would. This has been accomplished because of
the
CryptoLIB's ability to allow it to be customized by the application.
Hardware / Platform Specific Drivers
A number of CryptIC specific drivers are provided. The drivers provided are:
= a BIGNUM hardware assist driver,
= a random number generator driver, and
= crypto-block operations (i.e. DES engine).
110
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
SELF-TESTS
The self-test routines provide an integral part of determining the integrity
and
health of the security blocks. The self-test operations are used as part of
the CGX
Kernel reset processing to verify the health of the security blocks. The
following is a
list of self-tests that are supported:
= CGX Kernel code integrity check,
- This self-test checks the integrity of the CGX Kernel's program by running a
MAC over its entire 32K program space and comparing the MAC to the
ROM encoded MAC.
= randomizer check,
- This self-test checks the operation of the hardware randomizer. The method
for this test is described in the FIPS 140-1 document for 'Continuous
Random Number' test.
= volatile key storage checks
- This self-test checks the volatile key storage (i.e. internal KRAM). The
purpose is to verify the key storage integrity. To do this read, write, and
stuck-at checks are performed.
SOFTWARE STATES
The CGX Kernel is driven by a state machine as shown in Figure 15. As can be
seen in the figure, the state machine is fairly simple, comprising only four
states.
RESET State
The RESET state can be transitioned to from any one of the four states,
including the RESET state. The RESET state is entered upon powering up of the
CryptIC, through the command of the application, or a fatal error detected by
the
CGX Kemel.
111
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
As discussed in the section Reset Processing, the RESET state performs the
Basic-Init functions which include testing the sanity and integrity of its
services,
resources, and program. If any of these items fail, the CGX Kernel will reset
the
processor and the RESET state will be re-entered.
At the successful completion of self-tests the CGX Kernel will transition to
the
IDLE state. The only other state the CGX Kernel can transition to is the RESET
state.
IDLE State
The IDLE state can be transitioned to from either the COMMAND state or
CONI1ViAND BLOCK state. The IDLE state is entered upon the successful
completion of the CGX Kernel's reset self-test suite or after the completion
of a
cryptographic command requested by the application.
In the IDLE state the CGX Kernel is inactive, it is idly waiting for the
application's request for the next cryptographic command. Upon the request of
a
cryptographic command the CGX Kernel will transition to the RESET, CONIMAND,
or COMMAND BLOCK state. The CGX Kernel will transition to the RESET state if
an invalid kernel block is received. The CGX Kernel will transition to the
COMMAND state if the preemption bit in the control field in the CGX overlay
tupple
data structure (cgx overlay_tuple) is set to a 0; otherwise if the bit is set
to a 1, it
transitions to the COIVIMAND BLOCK state. The preemption bit is described in
the
section CGX Overlay Interface.
COMMAND State
The COMMAND state can be transitioned to from either the
COMMAND BLOCK state or IDLE state. The CONIMATTD state is entered upon a
request from the application of a cryptographic command; either back from
preemption
or an initial application request. When in the COMMAND state, the CGX Kernel
112
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
allows the current cryptographic command to be preempted. However, only
certain
commands can be preempted and only certain commands can cause the preemption.
All of the public key and digital signature operations have the preemption bit
set to a 0; thus allowing them to be preempted and causing the CGX Kernel to
enter
the CONEVIAND state from the IDLE state. A number of other CGX commands are
allowed to preempt the public key and digital signature algorithms (see
section 0).
Furthermore, the CGX Kernel only allows one level deep of preemption.
Therefore, upon preemption the CGX Kemel transitions into the
COh4VIAND BLOCK state to prevent further preemptions. Thus, the cryptographic
operation that caused the preemption must run to completion before the
original one
can complete or another one can preempt. I
At the completion of the requested cryptographic command the CGX Kernel
transitions back to the IDLE state. However, if some sort of severe error or
hardware
failure occurred the CGX Kernel will reset the processor; thus transition to
the RESET
state.
COMMAND BLOCK STATE
The COMMAND BLOCK state can be transitioned to from either the
COhOAAND state or IDLE state. The COMMAND_BLOCK state is entered upon
request by the application of a cryptographic command; either through
preemption out
of the COMMAND state, or via a single application request of a non-preemptable
cryptographic command. When in the CONOAAND BLOCK state, the CGX Kernel
will not allow the current cryptographic command to be preempted.
At the completion of the requested cryptographic command, the CGX Kernel
transitions back to the IDLE state if it was not previously entered due to
preemption.
If the CGX Kernel entered the COMMAND BLOCK state because the application
requested a CGX command that caused an active CGX command to be preempted, the
CGX Kernel will transition back into the COMMAND state to complete the
original
113
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
CGX command. However, if some sort of severe error or hardware failure
occurred,
the CGX Kernel will reset the processor-, thus transitioning to the RESET
state.
KEY MANAGEMENT
INTRODUCTION
It is well known that a carefully designed and implemented Key Management
infrastructure is a critical component of a good security system. In keeping
with the
philosophy of a'security system on-a-chip', the CryptIC incorporates a
powerful and
secure key management system into both its hardware and CGX firmware.
There are generally 5 elements of key management to consider:
1) Key Generation
2) Key Distribution
3) Key Storage
4) Key Selection (and use)
5) Key Destruction
The CryptIC's features support a consistent flow of Key Material through all
of the
five phases. In particular:
= The facilities are provided by the CGX library (and the integrated hardware
blocks)
to generate and safely store key material.
= Key 'covering' with a Key Encryption Key (KEK) is a CGX service which allows
secure key distribution and secure storage.
= Key selection is consistently handled through CGX library arguments and
safeguards are implemented against key hijacking, spoofing, alteration, etc..
= Key destruction may easily be achieved either by powering-off the CryptIC,
or by
executing a Destroy_Key CGX command.
114
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The CryptIC allows a wide range of key management implementations, since it
is only concerned with supplying the primitive key management utilities. This
allows
the application using the CryptIC to create either a simple 'flat' key
management
structure, or a highly layered and complex 'military-grade' key management
system.
The following sections describe the types of keys used on the CryptIC, the key
handling and usage conventions, and finally a discussion of key storage
requirements
and definitions.
KEYS
The CryptIC supports the following algorithms and key sizes for Symmetric
(secret key) and Asymmetric (public key) cryptographic operations, shown in
the table
below:
.. ; ....: ...
,, ..........:.. _ . : . .>Y: ...
... . ., .: .. . ' .:.
DES 40 - 56 bits 8 bits
Triple-DES (two key) 64 -112 bits 8 bits
T' DES (three key) 120 - 168 bits 8 bits
:: ....... ..... ....... .. .... ... . .. ..... ......... ...... .. ::... _ ..
,,,.:
... ..,..~: ~ . .~~+~.;v.... . ti,iiy;:Sii.'..~+=:.nw.k:i:
=
' .' ! . =..; = :. : " .. : .. ' (~~
~:if~{~~~ i'.~i:'};iy: ~ r~== .... ~ :ffiii}i'i.4'< :~;i:.=Y = ~ :~r=.i'.'=..=
. . . . . .. v.... ) i..ti::=. 32v:.. ...n.:i:. = %O:t
' % . . .. .. .:::' 1?:==.~~. ~: ~.$~~< ~=~r:r ~
Diffie-Hellman 512 - 2048 bits 64 bits
PUSA * 512 - 2048 bits 64 bits
/}p~ .. .. . .
:,:........ _.,.:....Y.._ :.y.,.: . ..... . :;::~;:.:.,..; .:.:.::.::::::
.:::,.::. =
{~~.~?~M'+I.I,-y~y. . , ~ .~Y. .,Y~.,= {"~z:,,:;:::;:~. "' ;:3:.~:~'~: ;%r
:'sn r:~;r.
;> .:y;:'=v~:;~.G:i,'v,~.=:r :;~:;k~,:i'~ ,.::: ...,a~,~. .. r:ia:~. =::~:+
Y.~~Vii'i~.=lIW':fliiV':~~'~~s'4.:.:: ::....:..:::: Y.. = ~
n:.~J:'i'.~':'y':~:::. : :.~.. =:S:~+i,n6~ ::>iir:ir.>4r:\ .
.:.... ... .. .. .... .r , ...... . ....
DSA 512 - 2048 bits 64 bits
RSA* 512 - 2048 bits 64 bits
* requires RSA licensed version of CryptIC
Table 11 Algorithms and Key Sizes
Since the CryptIC implements multiple cryptographic algorithms, there is a
need for several types of key. The following descriptions of the keys are
grouped into
Symmetric keys (also known as secret keys) and Asymmetric keys (or public key
pairs).
SYMMETRIC KEYS
Symmetric keys are used in order to support the symmetric cryptographic
algorithms (i.e. DES, Triple DES). The CryptIC supports several symmetric key
types
115
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
for data encryption and key encryption (covering/covering). In addition to
describing
the three types of symmetric keys, there are several other issues discussed in
this
section. These include: key length, key generation, key access, and key
protection.
Symmetric Key Types
There are three types of symmetric keys used on the CryptlC:
= Data Encryption Keys (DEKs)
= Key Encryption Keys (KEKs)
= Message Authentication Code keys (HMAC).
Each of the keys are described along with their respective properties in the
following subsections.
Data Encryption Keys (DESs)
Data encryption keys (otherwise known as session keys or traffic keys) allow a
message, a communications channel, a data file, etc. to be encrypted using one
of the
symmetric algorithms (i.e. DES, triple-DES, etc.) supported by the CryptIC.
All DEKs are stored in and retrieved from volatile Key Cache Registers
(KCRs) or written to the encrypt hardware engine's context 0 or context_1 data
key
register. By default, a DEK is not allowed to be exported (i.e. read by the
application)
unless it is covered by a key encryption key. However, the DEK must be
uncovered in
the CryptlC device to be used as a traffic key.
A DEK can be generated via all the means described in the section Symmetric
Key Generation, or can be imported as a Red key that was generated by an
external
application (assuming the applicable Program Control Data Bit allows Red key
load).
Typically, DEKs are short lived (ephemeral); they are around long enough to
encrypt the active secure channel. Once the secure channel is no longer
required, the
DEK is destroyed. The CGX Kernel that controls the cryptographic operations on
the
CryptIC is not responsible for destroying DEKs since it doesn't know when a
secure
116
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
channel has terminated. This is left to the application via the CGX DESTROY
KEY
command. However, the CGX Kesnel will destroy all volatile key cache locations
upon a reset or protection violation.
Key Encryption Keys (gEHs)
A key encryption key (otherwise known as a covering key) allows keys to be
off-loaded from the CryptIC for storage (ie. power-down recovery, key escrow,
etc.),
to allow key distribution, or for the secure exchange of traffic keys. The
CryptlC
supports five types of KEKs:
= Local Storage Variable (LSV)
= internai Generator Key Encrypting Key (GKEK)
= one or more application Key Encrypting Keys (KEKs)
= one or more Hash/Encrypt Data Key protection KEKs (DKEKs)
= optionally a Recovery KEK (RKEK)
Only the LSV is preserved across resets since it is laser-stored within the
CryptlC. Therefore, the storage requirements for other KEKs must be
implemented by
the application. This would be achieved by off-loading the KEK covered by
another
KEK. (The LSV is used to cover the RKEK and GKEKs. GKEKs or other KEKs are
used to cover application KEKs, DKEKs and DEKs.) The KEK heirarchy is shown in
Figure 16.
Local Storage Variable (LSV)
The LSV is a non-volatile 112-bit KEK which is laser-burned into each
CryptIC device at fabrication. It is unique to each CryptIC produced and can
be
considered that chip's master 'root' key. Only GKEKs and the RKEK may be
covered
by the LSV.
117
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Internal Generator KEK (GKEK)
The GKEK allows the application to safely build its own symmetric key
hierarchy trees securely by not allowing any of the user key's Red material to
be
exposed. The GKEKs allow for the off-loading of internally generated user keys
to be
stored in the application's non-volatile store. The GKEKs effectively insulate
the LSV
from any direct attack, since GKEKs are always trusted and cannot be imported
or
exported.
Application-created KEKs
Applications can generate multiple KEKs by calling upon the CGX library to
generate a KEK and then request the CryptlC to use the generated key to
cover/uacover other keys. The application must off-load or export the KEK and
store
it for later use. This means the application must first cover the newly
generated KEK
with either the GKEK or another KEK so that it can leave the CryptIC. This
approach
offers a layered model of KEKs.
Hash/Encrypt Data key protection KEKs (DKEKs)
DKEKs are used exclusively to cover and uncover DEKs which will be used in
the Hash/Encrypt hardware engine. This KEK wili typically be written into the
hardware context 0 or context 1 DKEK register so that it can automatically
decrypt
'Black' DEKs which may be stored in a crypto context database off-chip. DKEKs
cannot encrypt other KEKs.
Recovery KEK (RKEK)
A single RKEK is supported in the CryptIC. The RKEK is always a Diffie-
Hellman derived key and requires an IRE-certified request to generate it. It
may be
off-loaded from the CryptlC covered by the LSV. The RKEK is used for covering
DEKs, KEKs, or DKEKs for escrowing off-chip or for Key Recovery
implementations.
118
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
HMAC%ys
An HMAC key is a special type of key which does not impose formatting
constraints. An HMAC key type may be used to store the secret output of a hash
result - perhaps as part of a key derivation process, or it may be used to
store a secret
value to be used as the jou to an BNIAC function. HMAC keys may be from 40 to
160-bits long in 8-bit steps.
Since it is un-formatted, key weakening is never applied to an HMAC key.
Symmetric Key Lengths
The CryptIC supports several key lengths depending on the symmetric block
algorithm and the type of device (i.e. domestic version versus exportable
one). The key
length can be adjusted between the range of 40 bits and 168 bits, depending pn
the
PCDB programming within the CryptIC (i.e. configured for domestic or export).
For a domestic CryptlC all DES and Triple DES keys can have a 40 bit to 168
bit key length, programmable in 8-bit increments by the application. This
allows for
variable key lengths other than the typical 40, 56, 112, and 168-bit key
lengths. The
CryptIC defines triple DES keys as three 56 bit DES keys (i.e. 168 bits in
total),
however a triple DES key will actually occupy 192 bits (i.e. 24 bytes) since
in DES,
one bit of each key byte is considered a parity bit.To allow for non-standard
size keys,
a symmetric key weakening algorithm is used and described below in this
section.
Any key which is specified to be 40, 48 or 56-bits will automatically be
considered a single-DES key. Any key which has an effective length of 64 to
112 bits
will become a two-key, triple-DES key. That is, the significant bits of the
key will be
distributed between the first and second 56-bit sub-keys, and then the third
sub-key
will be a copy of the first. Any key with an effective length of 120 to 168
bits will
become a three-key, triple-DES key.
119
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
This means that any key longer than 56 bits is represented in a triple DES
form - ie. three 56-bit DES keys. The keys are always expanded to the full 168-
bits in
a manner to reflect the number of bits chosen by the application.
Symmetric Key Generation
Symmetric keys can be generated six ways on the CryptIC as described in the
table below:
: .::..:.::.~....
.....:.:...
x ..,::: = = = - ,:: >. . :yr; .;.. ..f:~;..=
: ==. H. =:
, .M::...~ .= :y~:,.
.. { . ~ . = . .== : :~ r;
:;$c
. K. :~: ::. : = . . .. : .r: r,. . .,<. ~.T'~5.:..: =. . ...:. . .. . . i
':a.a. 'i. ;>. .
Generate DEK from RNG CGX GEN KEY Samples the output of the Random Number
Generator to assemble the desired length DEK
Generate KEK from RNG CGX GEN_KEK Samples the output of the Random Number
Generator to assemble the desired length GIKEK
Negotiate Diffie-Hellman CGX GEN NEGKEY Perform the Diff.te-Hellman G'''
exponentiation
in order to arrive at a shared secret value. Based
on ANSI X9.42.
Hash from CGX DERIVE_KEY Derive a symmatric secret key by hashing an
Password/P hrase a lication- ed Password or P hrase.
Transform key (i.e. IPsec) CGX_TRANSFORM_KEY Transform a key using a
combination of Hashing,
Miaring with fixed data and re-Hashing, XORing,
etc.
Import a Red key from the CGX LOAD KEY Import a Red key provided by the
application.
a lication
Table 12 Key Generation Techniques
Symmetric Key Representation
Symmetric keys are represented in three ways, an Internal form, an IRE
External form, and a Inter-operable External form The first two
representations
are used in order to enforce the security policy of the CryptIC, and the last
is used in
order to allow the CryptIC to share key material with other vendor's
implementations.
Symmetric Key IRE Internal Representation
Symmetric keys are stored within the CryptIC in Key Cache Registers (KCRs).
Note that all of the data stored is in a plaintext (Red) form so that the CGX
software
may access it without the overhead of decrypting anything. Untrusted software
running in the 'User Mode' of the DSP does = have access to the KCRs.
120
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The format of the storage is as follows:
[type] [keylength] [key-bits] [weakened keybits] [keycount] [attributes]
The type field specifies the algorithm for which the key is to be used (eg.
DES,
3-DES, RC-5, etc.)
The keylength field indicates the length, in bytes, of the key. For the
CryptIC,
it will be either 8 or 24.
The keybits field is 192-bits long (three 64-bit DES keys). It contains the
actual key bits which will be used by the DES or triple-DES algorithm. For
single-
DES, only 64-bits are used and the remaining 128-bits will be zero. The least
significant bit of each byte is considered the DES parity bit and is ignored.
The weakened keybits field is 64-bits long and contains the 'original' bit
values which
were overwritten by 0's during the key weakening process. This is necessary if
the key
needs to be Exported in an interoperable format. Prior to exporting, the key
is 'un-
weakened' back to its original form. Upon importing a key, the weakening
process is
again performed to restore the original key. This behavior and thus the need
to
preserve the 'weakened bits' is needed in order to protect against key-size
tampering
when exporting/importing a key.
The keycount field indicates the length of the key in 64-bit blocks. For the
CryptlC, it will be either 1 or 3. Although the keycount can be inferred from
the
keylength field, it is provided in order to optimize performance.
121
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The attributes field is a 16-bit value with the following bit definitions,
shown in the table below:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
., .; .. ... .r .
. . .... ~;;.-: ;. .:~x
x x x x x x x x x x
pt}'
Lhim
I = DEK
I = HMAC key
I = DKEK
I = KEK
1 = OKEK
t = RKEK
I = LSV
1 = Tnisted key
1= Parent KEK is TnLsted
Reserved
This attributes field is created when the key is first generated and stays
with
the key both internally and when it is off-loaded. The only exception is when
a key
is Exported or Imported. In these operations, the key is always considered
Untrusted and the import/export operation specifies the key type.
Symmetric Key IRE External Representauon
When a symmetric key is off-loaded, the key must be put into an 'IRE-
external' form. The external form consists of all of the original random key
bits,
salt bits, attributes, and SHA-1 message digest. The entire external form is
encrypted, including the SHA 1 message digest. The salt bits and attributes
are
pre-pended to the key bits to provide randomness to skew the external key once
it
is encrypted (in CBC mode).
[userfield] [type] [keylength] . . .
... Emm{[salt][attributes][key-bits][weakened-bits][keylength][hash-
digest][DES-
pad])
... [32-pad]
Where Enc indicates the encryption of the data in {) by the specified KEK.
122
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The secretkey object is 576 bits / 72 bytes / 18 dwords long. This contains
the
following:
,. , ; . . .. . . . . . . ..
_ , . ... .., .
~ ...:.
.. ~ ~.r . ::~g. .~. :,,~..,- = ,,=~. .;.. ,.,.: ,:v .~, = :.:,.: .
~~ ~~{ ; :<-. =<:~, . f f
. . . . . .... .... .. . . . . . . : : . .: . ;:.. .. . . . .,... .,:.~ :
Useerfield 16 An applicadon-specified field which may be used for
tim 16 Algorithm for which the key was created (DES, triple DES)
Wength 16 Length of the key, in bytes . This field is dapficated inside the
covered portion
salt 54 Random bits used to enhance the key encryption process. Similar to an
IV
attributes 10 Attribate bitmap. See d 'on above
key4)its 192 The actual DES or triple-DES key bits. If DES, then last 128 bits
are zero
weakened-bits 64 The bits ovewiitten in the key-weakenin
keylength 16 Length of the key
, in byta. licated here to be included in the Hash
hash di est 160 A SHA-1 hash of the key, attributes and salt. Provides an
authentication code
DES-pad 16 Zero-pad bits to round-up to the nean.st 64-bit boundarv (for DES
on
32- d 16 Zero-pad bits to round- to the nearest 32-bit dword boundary
The purpose of the DES-pad field is because DES is 8-byte block oriented and
the seven blocks are formed so they can each be properly encrypted without
needing
padding. The 32-pad field allows the secretkey object to fatl on a 32-bit
dword
boundary which eases handling on the PCI bus.
The SHA-1 message digest is computed over the salt, attributes, key-bits and
weakened-bits fields. Once the message digest is inserted in the object, the
salt
through message digest fields are encrypted by a KEK. The encryption mode is
typically CBC, although for untrusted keys, the application may specify a
different
mode. A fixed IV is used for encrypting the key blob, since the random salt
takes care
of randomizing the encryption. This symmetric key blob is then returned to the
application.
Upon loading-in the Black symmetric key blob, the CGX Kernel decrypts the
key blob and runs the SHA-1 hash over the specified bits and compares the
message
digest to the one stored in the blob. If the message digest comparison fails,
the
symmetric key is rejected (i.e. not loaded).
123
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Symmetric Key Inter-Operable External Representation
When an application chooses to exchange an IRE symmetric key with another
crypto-vendor, the symmetric key must be converted from IRE's storage format
into
one that is more easily extractable so that it can inter-operate with other
crypto-
vendors. (Note that keys which are exported from or imported to the Cr)ptIC
are
always considered untrusted.)
To do this, a basic storage format based on NGcrosoft's CryptoAPI has been
adopted. The general form of the symmetric key to be exported/'imported is:
Exm{ [salt-bits][key-bits][data-bits] )
Where EKEx indicates the encryption of the data in {} by the specified KEK.
The application can specify no salt, it can explicitly define the salt bits,
or it can
request the CryptIC to generate the salt bits. The key bits consist of the Red
symmetric key bits as defined in the IRE external symmetric key formation. A
DES
key will occupy 8 bytes and a triple-DES key (2-key or 3-key) will occupy 24
bytes.
The key bits are laid out in big-endian form. The data field is supplied by
the
application, it can contain anything the application chooses, or it may be
omitted if the
application desires.
The one to three pieces of external symmetric key (salt, key bits, and data)
are
put into a buffer that is then encrypted by a symmetric KEK. The attributes
and
message digest of the IRE External form are not included in this format.
Since the externat symmetric key must be covered with a symmetric KEK, the
salt bits (if present) must be in multiples of 8 bytes and the data bits (if
present) must
be in multiples of 8 bytes as well. The exception to this rule is for HMAC
keys. In
this case the key must be in multiples of 2 bytes. Therefore, an HMAC key with
a
length of 5 bytes will be exported as 6 bytes with the 6'h byte exported as a
0.
In the case of covering the external symmetric key with a public key, the salt
bits (if present) can be as many bytes as the application chooses and the data
bits (if
124
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
present) can be as many bytes as the application chooses. However, the entire
size of
the salt, key, and data bits must be less than or equal to the size of the
public key's
modulus used to cover them.
Symmetric Key Weakening Process
As shown in Figure 17, the symmetric key weakening algorithm is similar to the
one created by IBM called CDMF key shortening. IRE's approach is similar, with
the
difference in that we write Os into the key bits starting at 0 going for the
amount to be
shortened by. In the CDMF approach, various bits are masked with zero.
To implement the key weakening scheme, the number of random key bits to be
used is important. For 40-bits to 56-bits, 64-bits of random data are to be
provided, for
64-bits to 112-bits, 128-bits of random data are to be provided, and for 120-
bits to
169-bits, 192-bits of random data are to be provided. The number of random
bits
specified is critical in that it allows the key shortening algorithm to work
correctly.
The weakening process consists of two encryptions; thus implying there are at
least two fixed symmetric keys used to do this. There are 14 unique fixed
symmetric
keys used for this process. A set of symmetric keys for each key length
between 8-bits
and 56-bits is provided; thus 7 pairs of fixed symmetric keys.
The algorithm to shortening the symmetric key is first to encrypt a full 64-
bits
with the first key of the fixed symmetric key set. Once the encryption is
complete that
output is shortened by overwriting it with zeros for the amount to be
shortened by.
For example, if a 40-bit key is needed, the first 24-bits of the interim
result will be
overwritten. Once the zeros are written onto the interim result, it is
encrypted again
with the second fixed key. The result of the second encryption is then used as
the
weakened symmetric key. This has the effect of distributing the weakened bits
over
the entire key.
Since we allow for key lengths to be between 40-bits and 192-bits with
increments of 8-bits we also have to distribute the weakened key between the 3
key
125
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
blocks (a block is defined as a 64-bit key block) if the key is to be 64-bits
or greater.
For 40-bits to 56-bits the key distribution does not occur, it fits in one key
block.
To distribute larger keys they are first evenly distributed between the first
two
key blocks if they can all fit. This means that a 72-bit key is broken up so
that 40-bits
are in block one and the other 32-bits in block 2. This means that the bits
are evenly
distributed into blocks 1 and 2 and if the key length is odd (meaning the key
length can
not evenly distribute into the two key blocks) the extra 8 bits is put into
block 1. Then
when the key is laid out in the two blocks, block 1 is copied to block 3 to
create a
triple DES key. However, if there 128-bits or more of key, then the remaining
bits are
put into block 3 to complete the triple DES key.
HMAC keys are never weakened.
Symmetric Key Access and Protection
Providing access to the symmetric keys has been carefully considered in light
of
security and flexibiiity. Since the philosophy of the CryptIC is to provide a
general-
purpose interface, the application is given a variety of importing and
exporting rules.
Each of the symmetric key types have their own rules on key access and are
addressed in more detail below in their respective sections. Furthermore,
depending
on the Program Control Data Bits (PCDBs), the application could be allowed to
import its own Red keys to be used as KEKs and DEKs.
ASYMMETRIC KEYS
Asymmetric keys allow for the implementation of public key algorithms and
digital signatures. The following sections describe the public keysets (public
and
private) that are used by the three asymmetric cryptographic algorithms
supported by
the CryptIC.
126
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Asymmetric Key Types
Like symmetric keys, the CryptIC supports several flavors of asymmetric keys.
The three types are:
Difffo-HeIIman public keys: Used for compwation of a ncgotiated key based on a
previously
gtnerated modulus and base
RSA public keys: Used for both encryption and digftal signatiares
DSA public keys: Used for digital siguamm only
The application is responsible for storage of public keysets, eliminating the
need for the CGX Kernel to store public keys. The modulus and public parts of
the
keyset are stored off-chip in the Red form, while the private portion of the
key is
covered. When requesting a public key operation, the application is required
to provide
as a parameter the public keyset it wishes to use. The CGX Kernel, in turn,
makes a
local copy of the public key and, if necessary, uncovers the private portion
into the
public key working kernel RAM in the CryptIC. When the operation completes,
the
local copy of the private key is destroyed.
Diffie-Hellman
As in all public key schemes Diffie-Hellman uses a pair of keys, public and
private. However, Diffie-Hellm.an is unique in that it does not perform
encryption/decryption or signatures as do the other public key systems.
Rather, it
implements a means to generate a shared secret or a negotiated DEK (i.e.
traffic key or
session key).
Unlike RSA, a fixed modulus (n) and generator (g) can be shared among a
community of users; therefore, the generation of a new stored modulus will not
occur
often. The modulus, public key and private keys can be exported/imported
from/to the
CryptlC.
A new public key (X) is generated upon request by the application; many
private and public keys can be generated from one common modulus. At the same
127
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
time, a private key (x) is also generated. The public key is generated using
the newly
generated private key (X = g" mod n).
A shared secret key or DEK can laxer be created by using the other CryptlC's
public key (DEK =Y" mod n). The negotiated DEK can be exported from the
CryptlC but it must first be covered by one of the CryptIC's KEKs (GKEK, or an
application-generated KEK).
RSA
As in all public key schemes RSA uses a pair of keys, public and private, to
encrypt/decrypt and implement digital signatures. However, unlike Diffie-
Hellman the
modulus can not be fixed. A new modulus must be generated for each new public
key
pair. The public exponent is calculated, based on a starting point specified
by the
application (up to 64-bits maximum). Typically, the starting exponent is
65537, which
avoids all of the known attacks on the fixed exponent of 3. Therefore, the
public key
is made up of the modulus (n = pq) and an exponent (e >= 65537).
The private key (d) is generated by taking the multiplicative inverse of the
public key (d = e"1 mod ((p-1)(q-1)). Like the public key, an optimization is
performed
by using the values of p and q during the decryption and signing operations of
RSA.
The optimization consists of precomputing dp and dq and using the Chinese
Remainder
theorem (CRT). Therefore, the CGX kernel keeps p and q and the precomputations
around as part of the private key.
The key pair can be exported from the CryptIC. The public key returned is
made up of e and n, the private key returned is made up of d, p, q, dP, dq,
p"mod q,
and q''mod p. Storing all of these values is essential in order to optimize
the RSA
decryption process using the Chinese Remainder Theorem. Naturally, allowing
these
private components to be seen would be a security breach, therefore the
private key
components are returned covered via one of the CryptIC's GKEKs or an
application-
generated KEK.
128
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
DSA
DSA also uses a pair of keys, public and private, to implement digital
signatures only. Unlike RSA, fixed moduli (p and q, and generator g) can be
shared
among a community of users. Therefore, the generation of a new stored modulus
will
not occur often. The modulus, public key and private keys can be
exported/imported
from/to the CryptIC.
The public key is composed of two pieces: the public key (y) and the modulus
data (p, q, and g). The CryptIC will allow a modulus size to be between 512
and 2048
bits with increments of 64 bits.
The private key (x) is a random 160-bit number. For every signature, a new
160-bit k is created. Once the signature is created, k can be destroyed.
Furthermore,
the signature process creates r and s, they are used in the verification
process to
generate v which is compared to r to verify a signature. The CryptIC's command
CGX SIGN returns r and s and the command CGX VERIFY expects r and s as
arguments.
A DSA key pair can be exported from the CryptlC. The public key returned is
made up of y, p, q, and g; the private key retumed is made up of x. The
private key is
returned covered via one of the CryptIC's GKEKs or an application-generated
KEK.
Program Control Data Key (PCDA)
The PCDK is a fixed DSA public key that is stored in masked ROM. The
PCDK is used to verify the digital signature on a PCDB modification token
(this is
explained in more detail in the section Programmable Control Data Bits
Initialization
String (PCDB IS) or to verify the signature on 'Extended Code' which may be
loaded
into the chip at run-time. The PCDK is hard-coded into the CGX kernel and
cannot be
off-loaded or exported.
129
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Asymmetric Key Lengths
Since the CryptlC supports several public key algorithms, the requirements for
public key pairs and their moduli differ. However, in general the CryptlC will
support
keys and moduli in the range of 512 bits to 2048 bits in multiples of 64 bits.
Asymmetric Key Generation
Public key generation like symmetric key generation is very important to the
security of the system. Poorly generated public keys or moduli will result in
inferior
crypto-protection. The main tenet behind public key generation is the
generation of
random numbers with a high probability of being prime. The CryptIC implements
a
widely accepted method of testing for primality, the Rabin-Miller algorithm.
Moreover, all prime numbers generated by the chip will have the most
significant bit
set and will be odd.
The CryptlC will never reuse the same modulus for an RSA or DSA new
public key. However, the CryptIC does allow for a common exponent to be used
for
the RSA exponent. The typical choice is to use the a starting point of 65537
as the
RSA encrypt exponent.
DSA Key Generation
The application has several configurable ways to generate the public-keyset
for
DSA operations. It can generate the modulus' p and q in a safe or weak manner.
The
safe method is based on appendix A of the X9.30 specification. It goes through
a
formal method of creating p and q from a 160 bit seed and 16 bit counter. In
this
method the application is ensured of not using a'cooked modulus'.
In the weak method, the modulus' p and q are generated in a simple method of
finding q a prime factor of p - 1. This doesn't provide for a seed and counter
but
generates p and q faster.
130
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
In either case, p and q are tested to determine if they are prime. As noted
earlier, they are tested using the Rabin Mller primality test and the
application can
specify the number of times it wants to run the test. The more times it is
run, the
higher the probability that the number is prime. However, the more times the
test is
run, the longer it takes to generate p and q. Also, as part of the primality
test, the
prime number to be tested goes through a small divisor test of the primes
between 1
and 257.
The private exponent is generated using the random number generator and the
public exponent is derived from the private and modulus data. Furthermore, the
application can change the private and public parts as often as it chooses for
a given
modiilus using the CGX GEN NEWPUBKEY command.
RSA Key Generation
The RSA moduli, p and q, are generated by first finding a prime number p and
then another prime number q that is close in value to p.
In either case, p and q are tested to determine if they are prime. As noted
earlier, they are tested using the Rabin-Mller primality test and the
application can
specify the number of times it wants to run the test. The more times it is ruq
the
higher the probability that the number is prime. However, the more times the
test is
run, the longer it takes to generate p and q. Also, as part of the primality
test, the
prime number to be tested goes through a small divisor test of the primes
between 1
and 257.
The public exponent is created by finding an e that is relatively prime to
~(n),
the product (p-1)(q-1). The starting point of this search is 65537. In most
cases e
remains 65537. In the event that ~(n) = 65537k, where k >= 1, then the
encryption
exponent will be the next largest odd value which is relatively prime to ~(n).
The private exponent is found by taking the multiplicative inverse of e mod (p-
131
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Diffie-Hellman Key Generution
The application has several configurable ways to generate the public keyset
for
Diff e-Hellman operations. It can generate the modulus p in a safe or weak
manner.
The safe method finds a safe prime, one of 2q + 1.
In the weak method, the modulus p is generated as a random number. In this
case, the modulus is weak but will be generated very quickly. Furthermore, the
modulus p is not tested for primality.
In either case, p and q are tested to determine if they are prime. As noted
earlier, they are tested using the Rabin-1V!'ler primaiity test and the
application can
specify the number of times it wants to run the test. The more times it is
run, the
higher the probability that the number is prime. However, the more times the
test is
run, the longer it takes to generate p and q. Also, as part of the primality
test, the
prime number to be tested goes through a small divisor test of the primes
between 1
and 257.
The private exponent is generated using the random number generator and the
public exponent is derived from the generator, private exponent and modulus.
Furthermore, the application can change the private and public parts as often
as it
chooses for a given modulus using the CGX_GEN NEWPUBKEY command.
Asymmetric Key Representation
Asymmetric key sets are represented in one of two forms, an IRE external
form, or an Inter-operable External form. The IRE External form is a subset of
the
Inter-operable External form. The external form is modeled after the Microsoft
CryptoAPI specification.. Note that the asymmetric key sets contain the Public
key, the
Modulus/Generator, and the Private key. Only the private key portion is
covered by a
KEK.
132
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Asymnutric Key IRE External Representation
When an application chooses to create an IRE private key for local storage,
this foraiat is used. This is the format that is returned for the CGX GEN
PUBKEY
and CGX GEN NEWPUBKEY operations.
[userfield][type][keylength][datapage][pointer-to-modulus][pointer-to-pubkey]
... ...
[pointer-to-privkey] and:
The modulus/generator element is: [modulus-generator-packed]
The public key element is: [public-keybits-packed]
The private key element is: Exm{[salt-bits][private-keybits-packed]}
Where EKm indicates the encryption of the data in {} by the specified KEK
For the private key portion, the application can specify salt, no salt, or
request
the CryptIC to generate the salt-bits. Moreover the application can use the
salt bits as
a means to prepend a formatted packet of data in front of the private key. The
key bits
are the Red private key bits. For DSA it will just include, x, a 160-bit key.
For Diffie-
Hellman it will just include the private key, x, a key between 160 and 2048-
bits. For
RSA the private key bits will be p, q, d mod (p-1), d mod (q-1), and q'1 mod
p, and d
(in this order). The key bits are laid out in little-endian form.
The private key bits and salt are put into a buffer that is encrypted by an
untrusted symmetric KEK.
If salt is to be supplied, it must be in 16-bit units, no single bytes
allowed.
Furthermore, the total byte count of salt, and key bits must be a multiple of
8-bytes in
order to fall on a DES block boundary.
Asymmetric Key Inter-Operable External Representation
When an application chooses to exchange an IRE private key with another
crypto-vendor, the private key must be translated from IRE's storage format
into one
that is more easily extractable.
133
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
To do this, a basic storage format based on Microsoft's CryptoAPI has been
adopted. The general form of the private key element to be exported/'imported
is:
The private key element is: Eux{[salt-bits][key-bits][data-bits]}
Where Eux indicates the encryption of the data in {} by the specified KEK.
The application can specify salt, no salt, or request the CryptIC to generate
the
salt bits. Moreover the application can use the salt bits as a means to
prepend a
formatted packet of data in front of the private key. The key bits are the Red
private
key bits. For DSA it will just include, x, a 160 bit key. For Diffie-Hellman
it will just
include the private key, x, a key between 160 and 2048 bits. For RSA the
private key
bits will be p, q, d mod (p-1), d mod (q-1), and q" mod p, and d (in this
order). The
key bits are laid out in little endian form. The data field is supplied by the
application, it
can contain anything the application chooses or it can be left out if the
application does
not require it.
The private key (salt, key bits, and data) are put into a buffer that is
encrypted
by an untrusted symmetric key.
If salt or data are to be supplied, they must be in 16 bit units, no single
bytes
allowed. Furthermore, the total byte count of salt, key bits, and data bits
must be a
multiple of 8 bytes in order to fall on a DES block boundary.
M HANDLING REOUIREMENTS
An important requirement to defining a key management scheme is setting
forth requirements on how the keys are handled by the CGX Kernel and
application.
The CGX Kernel presents several requirements on key handling for both public
and
symmetric keys. This is followed by a detailed discussion of secret/public key
hierarchy and control.
The following are requirements the application must abide by in order to
create and
manipulate keys using the CryptIC:
134
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
1) By default, Red key exchange between the application and the CGX Kernel is
only allowed in the direction from the application to the CGX Kernel (i.e.,
loading), for all user symmetric keys (KEKs and DEKs). Absolutely no Red
key exportation is allowed.
2) All keys stored in the internal KCRs are in the Red form, no internal Black
key
storage is allowed.
3) Black keys are not allowed as part of encryption or public key operations.
In
other words a key must be uncovered, in its Red form, before it can be used in
any of the CGX Kernel commands. This is true for the private key of a public
keyset as well.
4) All key management commands supported by the CryptIC (e.g.
CGX GEN KEY, CGX GEN KEK, or CGX GEN PUBKEY, etc.) are
atomic. This means that when a key is created, derived, or negotiated, a
covered (i.e. Black or encrypted) copy of the key is returned at the same
time,
as part of the same command. Therefore, the only way to get back a key (i.e.
the Black one) is via the command that created it. This prevents an intruder
application from hijacking a key.
5) AII keys used or stored by the CryptIC fall under two umbrellas of
protection,
trusted or untrusted. Trusted keys can never be exposed in their Red form; the
CryptlC stores them in a secure and protected manner. An untrusted key can
be used in many flexible ways but secure protection is left to the
application.
6) All keys in a trusted tree (see Figure 18) can not move from that tree,
they are
permanently stored in the tree.
7) All keys in an untrusted tree (see Figure 18) can move to other untrusted
trees
and/or a trusted tree, once under a trusted tree the key can not move (as
stated
in item 6 above).
135
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
8) There are two classes of keys, IRE external keys (symmetric and public) and
interoperable keys (symmetric and public).. IRE external keys contain secure
attributes that describe its trust and key type. Interoperable keys contain
nothing but the key material, formatted with optional salt bits in the front
and
optional application-supplied data bits at the end of the key material.
9) Internal IRE keys contain two attributes: Use and Trust level. The use
attributes specify the key type (ie. KEK, DEK, DKEK). The trust level is
Trusted or Untrusted (as explained in item 5 above). The use attribute
mandates how a key can be used and which commands will allow it.
10) As a means to combat many types of cipher-text attacks on Red key storage,
all
symmetric keys and private keys (of a public keyset) will include 'Salt' which
are random bits prepended to the key material prior to encrypting. The random
salt data helps to prevent statistical cipher-text attacks; thus better
securing a
covered key.
11) In order to off load and protect user keys securely (i.e. Diffie-Hellman
negotiated ones, CGX GEN KEY ones, or imported Red user keys) a
generated internal key encryption key (GKEK) must be used. This provides an
internally protected conceptual boundary around the CryptlC device and the
application's non-volatile storage memory. This is because the GKEK is an
extension of the CryptIC, it is never exposed and the keys covered under it
are
therefore never exposed.
12) The LSV is laser programmed at the factory and is unique for each CryptIC
device.
13) The LSV is a two-key, triple-DES key (i.e. 112 bits), a(1 GKEKs are
covered
under the LSV using triple DES in the CBC mode.
14) All GKEKs are internally generated using the CGX GEN KEK command.
136
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
15) To off-load a GKEK, it must be covered under the LSV (no other covering
key is permitted).
16) All GKEKs are triple DES keys (i.e. 192 bits), all user keys are covered
under
the GKEK using triple DES in the CBC mode. The CGX Kernel supplies a
fixed IV.
17) The LSV can not be exported in any form. Furthermore, the LSV can only be
used by the CGX GEN KEK, CGX GEN RKEK or
CGX UNCOVER KEY commands.
18) GKEKS rAU no~ be exported/imported, although they may be off-loaded in
IltE
External form. Furthermore, GKEKs can only be used to cover user keys, not
as traffic keys. Therefore, the GKEK can only be used by the
CGX UNCOVER KEY, CGX GEN KEY, CGX DERIVE KEY,
CGX LOAD KEY, CGX GEN PUBKEY, and CGX GEN NEWPUBKEY
commands.
19) A user key can be created internally via CGX GEN KEY (for symmetric keys)
and CGX. GEN_PUBKEY (for public keys), imported in the Red form,
derived via CGX DERIVE KEY, or negotiated via the Diffie-Hellma.n key
exchange (symmetric key only).
20) User keys are also known as KEKs, DEKs (a symmetric key), or a Public
keyset. All user keys must be covered by a GKEK, RKEK or KEK in order to
be exported.
21) Once a user key is covered under a GKEK it can not be covered by any other
key. In other words, the user key can not be propagated down or across in the
symmetric key hierarchy. This rule prevents key stealing or spoofing.
22) User keys covered by a KEK can use either the DES or triple-DES algorithm.
For untrusted keys, the application is responsible for providing an IV for the
appropriate modes (i.e., CBC, CFB, and OFB).
137
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
23) The depth of the symmetric key hierarchy is unlimited, KEKs can be covered
under KEKs 'N' deep as long as it abides by these key handling rules. This is
the same for tiusted KEKs as well.
24) The CGX Kernel knows if a KCR contains a key, the key type, the key
length,
and its attributes. Anything beyond that is the responsibility of the
application.
Symmetric Key Handling
The CryptlC provides support for eight kinds of symmetric keys: LSV,
hardware only, protection, generated, loaded, imported, negotiated,
transformed, and
derived. The master key is the unique LSV laser programmed into each CryptIC
device. The LSV provides the ability for the application to safely off-load
key material
with out the possibility of exposing the key's Red contents.
Hardware only keys, DKEKs, are internally generated symmetric keys (via the
CGX GEN KEY operation) that are used to cover symmetric keys, DEKs, only. The
DKEK keys allow applications to load Black symmetric DEKs into the
hash/encrypt
crypto interface to be uncovered and used as traffic keys. This allows the
application
to use the hash/encrypt hardware interface securely since keys are never
exposed in the
Red form.
Protection keys, GKEKs, are internally generated symmetric keys (via the
CGX GEN KEK operation) that can only be covered by the LSV. The protected
keys allow the application to build a symmetric key tree hierarchy that to the
application is protected internally within the CryptlC device. This protection
is a
conceptual boundary around the CryptIC and the application's non-volatile
memory
storage. Protected keys are returned in the Black form.
Generated keys are user keys generated internally to the CryptIC, they never
reside in the Red form outside the bounds of the CryptIC device. All generated
keys
are created via the CGX GEN KEY operation. An internal user key can be used as
a
138
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
KEK or DEK, but is always known as a trusted key by the CGX Kernel unless the
application requests it to be untrusted.
Loaded keys are user keys loaded in the Red form They can be used as a KEK
or DEK, but is always known as a untrusted key by the CGX Kernel. The loaded
key
may be covered by a GKEK or another trusted or untrusted KEK. Loaded keys play
an important role for applications such as ANSI X9.17 where the application
must
supply the master keys. The master keys are then used to cover the session
keys that
can be generated by the CryptIC or imported.
Imported keys are user keys imported from another vendor's crypto-system, in
the Black form. They can be used as a KEK or DEK, but is always known as an
untrusted key by the CGX Kernel. The imported key can be covered by a GKEK or
a
trusted/untrusted KEK
Negotiated secret keys are the result of a Diffie-Hellman key exchange.
Negotiated user keys can be used as KEKs or Ks, but are always known as an
untrusted key by the CGX Kernel. The negotiated key can be covered by a GKEK
or a
trusted/untrusted KEK.
Transformed symmetric keys are the result transforming an HMAC key into a
useable DES, Triple DES, or RC5 key. The transforms are all based on the
current
IPsec working group papers on HMACs. Transformed user keys can be used as KEKs
or DEKs, but are always known as an untrusted key by the CGX Kernel. The
negotiated key can be covered by a GKEK or a trusted/untrusted KEK.
Derived keys are the result of a cryptographic operation that converts a pass-
phrase into a symmetric key using a one-way HASH algorithm. Derived keys can
be
used as KEKs or DEK, but are always known as an untrusted key by the CGX
Kernel.
The derived key can be covered by a GKEK or a trusted/untrusted KEK.
Figure 18 presents the symmetric key tree hierarchy supported by the
commands of the CryptlC.
139
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The keys shown in Figure 18 represent their type (in upper case: LSV,
GKEK, KEK, DKEK, or DEK), trust level (the lower case letter to the left of
key
type, t for trusted and u for untrusted), generation method (the superscript
as defined
below), and the key movement method (the subscript as defined below).
!e = not exportable
e = exportable
g = generated
n = negotiated (Diffie-Hellman)
1=loaded
i = imported
t = transformed
d = derived
Since the CryptIC does not contain non-volatile storage, the CGX Kernel must
allow a means for the application to safely off-load symmetric keys into some
external
non-volatile storage for fixture use. This is accomplished through the
classification of
symmetric keys shown in Figure 18 above. AIl trusted keys (the ones in the
white oval)
are securely protected via the LSV symmetric key hierarchy. All the other keys
(in the
gray shaded are of the box) are untrusted and the storage scheme is left to
the
application.
The trusted tree provides a means to securely store symmetric keys. The
storage is secure because the parent KEK is a trusted key and by definition a
trusted
key means that the key was created in a manner that prevents it from being
exposed in
the Red form. Therefore, the child keys under a trusted KEK are securely
protected
because the parent KEK is not compromised.
A trusted key must contain attributes. The attributes are used to define the
class of the key and its type. The class defines the key as a trusted or
untrusted and
the type defines the key to be used as a KEK or data key (DEK) only; it can't
be both.
140
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
For aiI IltE symmetric keys, the type and class will be securely stored with
the key
material. Therefore when a key is reloaded into the CryptIC, the type and
class is
reliably restored.
At the root of the trusted tree resides the LSV. The diagram shows that the
LSV is trusted (tLSV), it has been laser programmed (LSV'n, and is not
exportable
(LSV,.). The LSV is the master KEK for the CryptIC; it is used as the covering
KEK
of protected keys, GKEKs; it can not be used by the general encryption
commands.
Under the LSV resides the protection keys, the GKEKs. The sole purpose of
these keys is to limit the exposure of the LSV so that the application can not
determine
the L$V from plain-text attacks. The GKEKs are trusted keys (tGKEK), are
internally
generated so that the Red key material is not easily detectable (GKEKg), and
are not
exportable (GKEKia).
Under the GKEKs, the application is free to build its own trusted tree or make
it a flat one which resides directly under the GKEK and no deeper. To build a
deeper
secure trusted tree, the application must create trusted KEKs. The trusted
KEKs
(tKEK) shown in Figure 18 are formed via the CGX GEN KEY command (KEKg)
and can never be exported (KEK!Q). A trusted KEK is similar to the GKEK in all
aspects except that its parent KEK is either a GKEK or another trusted KEK;
not the
LSV. Therefore, the trusted tree can be as deep as one wants but the parent of
each
branch must be a trusted KEK. Furthermore, all child keys under a trusted KEK
can
not be exported, they are permanently stored under the trusted KEK.
All session keys (DEKs) stored under a trusted KEK or GKEK can be either
trusted or untrusted. The trust state of these keys does not matter, it's the
fact that
they are stored under a trusted parent that matters. Being a trusted DEK has
one
slight difference then an untrusted DEK. The difference is that trusted DEKs
(tDEK)
shown in Figure 18 are formed via the CGX GEN KEY command (DEKS).
Untrusted DEKs are created in some untrusted means therefore the Red key
material
141
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
could be determined more easily. However, like trusted DEKs untrusted DEKs
under
a trusted KEK can not be exported.
Before describing the untrusted trees there is one more interesting point
about
trusted trees. In Figure 18, there are two untrusted KEKs which both reside
under
trusted KEKs (one under a tKEK and the other under a tGKEK). They are both
untrusted and therefore their children reside in the untrusted umbrella (the
gray area).
Although the untrusted KEKs can not be exported (because their parent KEKs are
trusted) their children can because their parent is untrusted.
Untrusted trees are ones where the parent KEK of the tree is untrusted.
Therefore, all keys regardless of depth under the initial untrusted parent
will be marked
as untrusted and will be allowed to be exported. No trusted DEK or KEK can be
created under an untrusted KEK.
A good example of the untrusted tree is shown in the bottom right side of
Figure 18. The parent KEK is untrusted (i.e. KEK) and could have been created
in a
multitude of ways (KEK''itd, generated, negotiated, loaded, imported, and
derived)
and is exportable (KEI{.). All of its children are marked as untrusted and
could have
been created in many ways, as with its parent. The child keys are exportable.
There is another type of an untrusted tree, called the dangling tree. All
dangling trees are by definition are untrusted because the root key is always
an
untrusted KEK or it has no root KEK at all (ie. an untrusted DEK). The upper
right
hand of Figure 18 shows an example of a dangling tree. In this example the
parent is
the root and is an untrusted KEK. Furthermore, the parent KEK is not
exportable
because there is no parent KEK to cover it.
One example of this dangling untrusted tree is the case where the untrusted
parent or root KEK was created as a derived key (i.e. via a pass-phrase). The
application then stores keys under this derived untrusted KEK. It can now
safely store
away the untrusted keys and not have to store the parent KEK. Anytime it wants
to
142
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
use one of the stored keys it must use the CGX DERIVE KEY operation to
regenerate the untrusted parent KEK.
Another example of a dangling tree is shown in the lower left corner of Figure
18. In this example the dangling tree is flat, it is a single untrusted DEK.
This key is
untrusted and can not be exported because it has no parent to uncover it with.
However, the real usefulness of this key is its use as a session key for one
time only.
The DKEK keys are not shown in the diagram in Figure 18 because they
function identically to the KEKs in the diagram with one exception. The
exception is
that the only keys that can be covered under them are DEKs of any type (i.e.
derived,
loaded, etc). At no time will a KEK or another DKEK be allowed under a DKEK.
The DKEK key' is reserved for the use of the hardware crypto-block interface.
To
allow applications to load in Black symmetric DEKs from an extemal context
store (ie.
in PCI or Extemal memory space) and not have to expose their keys in the Red
form.
Asymmetric Key Handling
Asymmetric keys contain three components: the public exponent, the modulus
and generator, and the private exponent. The private exponent can be imported
in the
Red form, but only exported in the Black form (the private key must be
covered).
Public key sets can be intemally generated using the CGX_GEN PUBKEY or
CGX GEN NEWPUBKEY (generates the exponents of a Diffie-Hellman or DSA
public keyset) commands.
All asymmetric keys are known as untrusted keys, therefore they can be used to
cover symmetric keys to be exported or be exported themselves.
Public keys can be used as covering keys, key exchange keys, and signature
keys. However, the appfication should create different keys for these tasks to
protect
the keys from various attacks. The CryptlC does not enforce key types for
public
keysets as it does with symmetric keys.
143
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
A public keyset can only be covered by a trusted or untrusted symmetric key,
not another public key. Only the private part of the public keyset gets
covered; the
public key and modulus/generator are always in the Red form.
SOFTWARE DATA OBJECTS
This section describes the various software data objects that make up the CGX
Kernel.
Configuration Data
The CGX Kernel maintains the program control data bits. The functionality of
the bits are described in the section Kernal Configuration String (KCS). The
following
sub-sections describe the data storage definitions for the program control
data bits.
Program Control Data Bits
The PCDB allows the application to customize the CGX Kernel. For example,
the PCDB contains a bit to allow the exportation of Red key material. However,
the
application must obtain an unlock-data message to get the proper permission to
permanently change the non-volatile copy of the PCDBs. Without the appropriate
unlock-data message the application is denied access to the PCDBs. Obtaining
the
unlock-data message and the process of using it is discussed in the section
Kernal
Configuration String (KCS).
Figure 19 specifies the data definition for the PCDB bits.
PCDB Bit Definitiions
The following lists the PCDB words in lowest memory order, defining the bits
that are programmable by the application:
Word 0:
As shown in the table below:
144
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
= Bits 0- 4 set the maximum allowed symmetric key (DES, triple-DES) length.
The starting size is 40-bits and these bits allow a step size of I byte up to
168-bits.
= Bits 5- 7 set the maximum allowed asymmetric key (RSA, DSA, D-H) length.
The starting size is 512-bits and these bits allow a step size of 256-bits up
to 2048
bits.
= Bit 8 selects whether triple-DES is allowed for traffic encryption. It is
always
allowed for Key encryption.
= Bit 9 selects whether the CryptlC will allow Red key loading.
= Bit 10 selects whether the RSA public key algorithms are enabled. A royalty
fee is
due to RSA for those chips which have this feature enabled.
= Bits 11 - 15 are reserved.
Word 0
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
' : . ~ V{f : x x x x x x x x x x x
Symmetiric key maximum length (in bytes - 40 to 168)
15 Asymmetric key maximum length (in 256's - 512 to 2048
1= Triple-DES enabled for tratl'ic encryption
1= Allow Red key loading
1 = RSA algorithms enabled
Reserved (set to 0)
Word 1:
As shown in the table below:
= Bits 0- 2 set a hardware delay-line which is used for adjusting the timing
pulse for
External Memory access. This is typically configured at the factory to account
for
IC process changes.
= Bits 3 - 14 set the hardware revision number of the CryptIC. This value is
returned
in the CGX GET CHIPINFO command.
145
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
= Bit 15 is reserved.
Wordl
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
~ x x x x x x x x x x x x x x x
L__[~xternal memory pulse shaping
Hardware revision number code
Reserved (set to 0)
Command Interface
The major component to the command interface is the use of the shared
memory, the kernel block, to allow command communication between the
application
and the CGX Kernel. The following sub-sections defined the kernel block and
its two
members: the command block and the status block.
Kernel Block
The kernel block is the CGX Kernel's pipeline or socket to the outside world
(i.e. the application). The kernel block provides the application and CGX
Kernel with
the ability to communicate with one another. The kernel block is a pre-
formatted
shared block of RAM located in the DSP's data address space, either in
internal DM or
external DM. The kernel block is shown in Figure 20.
The kernel block is comprised of two areas: the command block and the status
block. The command block is used as the data transfer area between the
application
and CGX Kernel for servicing cryptographic commands. The status block is used
to
keep the application updated on the status of the CGX Kernel.
The kernel block consists of a status member and a pointer to the command
block.
Allowing the blocks to be defined as pointers allows the application to build
static
kernel blocks with the possibility of globaiizing the status block. By
globalizing the
status block the application can reference the single instance; thus making
status
checks easier to perform. The section Kernal Block Object defines the kernel
block as
a very simple C data structure.
146
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Moreover, the shared block approach is important for two other reasons. The
first is to make the software interface to the CGX Kernel compiler-
independent.
Otherwise, the interface would be achieved via arguments pushed onto the
software
stack. All compiler languages support different calling frames; therefore, it
would be
difficult to come up with a simple scheme to handle all languages easily and
efficiently.
The second reason for the shared block approach is to optimize the access to
the CGX Kernel. Using the shared block approach, the application can set up
static
kernel blocks. A static kernel block would have pre-configured arguments and
commands. The application would reuse the command block and never have to
update
it, similar to using a DMA controller. For example, the application could set
up a
static traffic encryption command block. The command block would be set up
once
with the following arguments: CGX ENCRYPT command, the crypto-block context
object, a data-in and data-out pointer, and a data-in size. Then for every
block(s) of
data to encrypt the application would only invoke, cgx secure transferQ, with
a
pointer to the static kernel block. Like a DMA operation, the input buffer is
obtained
from the data-in pointer and the output buffer is obtained from the data-out
pointer.
The application would only have to replenish the data-in buffer and consume
the data
in the data-out buffer after the service completes. This would save processing
time
because the application would only have to populate the kernel block once
prior to
traffic.
The status field provides the CGX Kernel status back to the application (ie.
return result code). The status field is a place holder for cryptographic
service result
codes, the acceptable status codes are specified in the section Status
Definitions.
Kernel Block Object
The kernel block object is made up of two independently addressable blocks.
Figure 21 illustrates the kernel block.
The kernel block uses a pointer to the command block to allow for global
substitutions of the block. For example, the application may have many static
147
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
command blocks for several cryptographic services while it only has one kernel
block
for the entire appfication.
The 4 word kernelblock object may reside in either the internal DM data page
or in any external DM page of the CryptIC. It is important however that when
the
CGX call is made (transfer vector), that the DMOVLAY register is set to the
page in
which the kernelblock object resides. The CGX Kernel will not modify the
DMOVLAY register until it has read-in the kernel block.
Member Details
The DeviceNo member, as shown below, is used to allow the application to
specifywhich class of command is being requested and the memory model for the
command block arguments.
:.: r.., .
.:r::r:::t;Y:r'<#=x:;:'.:}"'~v;'= .=: = . ti%=:,; f~;j:}v:'=y} .;
y:tu:i:~=:r:ti: =
,;?=~ .y '..':n:' ,;'=yj"~a. ' '.}i{,.>;:~t'}"...::= ; :.;..;r+:,,y~
::= .};y,=:;
:. .:. },' =~ . . 'y'}},v ;,:y.::~
;~.., +~}... :=;::.:}~:
:i+F.<tiii}:=:!:' :n:h/{.}}.=i~,} ry:i8:9.:Y?:3.~::;n: I.=.. r f.S:i.r.
n3yr::p./.=:JY.Ii .:Cih':~S';::Y.{:Q'n,+r};i'f,'},.:=';.
...;.:=};.: = == = : ~'ti:f!~' ;~s:' ~ l ?.: ....'...~~
. . .. .... . . . . . .. . ... . ... . .
Ox0000 ByteCode Command DSP Internal PM
Ox0001 ByteCode Command DSP Iaternal DM
0x0002 CGX Command PCI (32-bit addresses
0x0003 CGX Command DSP DM (14-bit address, data page)
0x0004 CGX Command Mixed Mode d= bitmap)
DeviceNo codes 0 and 1 are reserved for special ByteCode commands which
are used in factory testing. Codes 2- 4 are used for CGX commands.
DeviceNo code 0x0002 specifies that if any of the 10 arguments in the
command block are pointers, then they will be defined as 32-bit PCI address
pointers.
For example, if for a given CGX command, argument #3 is a pointer to a data
source,
then it will be a 32-bit PCI address.
DeviceNo code 0x0003 specifies that if any of the 10 arguments in the
command block are pointers, then they will be defined as DSP Data Memory (DM)
address pointers. The least-significant word of each argument will hold the 14-
bit DM
address. The most-significant word for each argument will hold the 16-bit
DMOVLAY value for the DM address, thus allowing the pointer to reference any
page
in internal or external CryptIC memory.
148
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
DeviceNo code 0x0004 specifies that the dp member of the kernel block is a
bitmap, specifying for each of the 10 arguments whether they are a pointer
into PCI
memory space (1) or an address/overlay page in DSP data memory space (0).
Again,
this only applies for those arguments which are pointers rather than explicit
data. For
example, a CGX command could be executed with a command block pointing to data
values both in local DSP memory as well as PCI memory. This avoids having to
copy
data into the DSP memory prior to executing a CGX command.
The member, dp, is provided to allow flexible location of the command block
within the CryptIC's memory spaces. The kernel block (which includes the
status
block) will be in whatever page is currently active (specified by the DMOVLAY
register) when CGX was entered. However, the dp member allows the application
to
allocate the command block in any of the external data pages available. This
avoids
having to use the valuable internal data space if the application chooses not
to. As part
of the CGX Kernel entry operation the CGX Kernel will save the previous data
page
and set the 2183 data page to the one passed in the kernel block. Upon exit
the CGX
Kernel will restore the old data page it saved in the entry operation.
The application may use the status field to determine if a cryptographic
service
completed successfully or not. The status code will indicate whether the CGX
Kernel
is busy or not, and will provide a success or failure result code. Note: the
application
must never modify the status field. The CGX Kernel is the only software that
should
write to the status field. If the application modifies the status field it may
not know if
the CGX Kernel is active.
Command Block
The command block provides the argument interface between the application
and the CGX Kernel. The command block is comprised of several fields as shown
in
the C data structure definition below. The command block is made up of a
command
149
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
field and argument list. The command field is loaded with the operation code.
The
available commands are listed in the section Command Definitions.
The argument list is used to pass-in the command arguments. The argument
list is a fixed array of void pointers. The void pointer allows you to
establish a pointer
to any object as well as passing in arguments by value.
Although most of the commands take a variable number of arguments, the
command block is always fixed with 10 argument locations. However, the
application
does not have to assign the unused arguments to anything if the command does
not use
them. See the section Command Specification & Arguments for a detail Iisting
of
command argument specifications.
Command Block Object
The command block object is used by the application as the communication
channel to the CGX Kernel or as the argument list for a cryptographic service.
The
command block is made up of a command (i.e. the micro commands as defined in
the
section Command Definitions), and the list of arguments (a maximum of 10
arguments
are allowed). The argument list can contain pointers to various objects to be
passed
into the CGX Kernel. Figure 22 illustrates the command block object.
KEY OBJECTS
Secret Key
As shown in Figure 23, the secret key object, secretkey, is used to represent
a
symmetrical key between the application and the CGX Kernel. The data structure
contains the key length (i.e. length, allowing the maximum key length of 192
bits for
the triple DES algorithm), application specific data, the secret key type
(i.e. DES,
triple DES, etc.), and the raw buffer (i.e. k[16]).
The raw buffer, k, houses the actual secret key. As part of the secret key,
some salt bits are pre-pended to the buffer, k. There are a total of 54 bits
of salt
150
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
added, followed by 10 bits of key attributes. The key attributes (for details
see the
section Symmetric Key IRE Internal Representation) define the type of key
(i.e.
KKEK, KEK, DEK etc.) and its trust level (i.e. Trusted or Untrusted). The next
192
bits contain the actual key bits, followed by 64 bits of overwritten
key_weakening
data. Then, the 16-bit keylength field appears, followed by a 160-bit SHA-1
digest of
the first 256 bits of k. The digest is used to authenticate the salt,
attributes, and key.
The secretkey object is only used as a means to communicate and securely
store keys off of the chip. Internally, the chip uses the same secretkey
structure minus
the last 192 bits of the buffer, k, the SHA-1 digest data.
All secret keys will have a type defined as: CGX DES A or
CGX TRIPLE DES A. The secret key type is used by the CGX Kernel so that it can
internatly transform the secret key to be usable for the secret key algorithm
specified in
the type field.
The secret key is stored in a buffer of 16 bit units or WORD 16 data types.
This allows for more efficient storage and access schemes. By default, the key
is
stored with its most significant bits in the upper bits of the final WORD 16
item. The
salt data will fill-in the unused least significant bits of the raw key
buffer.
The extra field is 16 bits of data provided to the application for what ever
it
chooses. The CGX Kernel does not read or write this field. Furthermore, it
will
preserve this field while the key is internaily stored in volatile or non
volatile memory.
PubGc Key
The public key object, publickey, is used to represent an asymmetric key that
is to be used between the application and the CGX Kernel. The data structure
is made
up of a modulus, public key, and private key objects. The publickey object can
accommodate Diffie-Hellman, DSA, and RSA public keys; otherwise known as the
public keysets. The publickey object can only manage a maximum key length
and/or
151
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
modulus length of 2048 bits. Public key modulus length can be regulated with
PCDBs. If required, an 'Enabler Token' can oveaide the factory laser settings
of the
PCDBs.
Figure 24 defines a generic public keyset. The type field identifies the kind
of
public key contained in the structure. Based on the type field, the
application assigns
pointers to the appropriate keyset objects: modulus, privkey, and pubkey
objects for
the appropriate type (i.e. Diffie-Heliman, RSA, and DSA). These pointers
reference
blocks of data stored in little-endian form.
All public keysets are stored in a packed form. Packed keys are defined as key
structures in which the least significant byte of the next public key
structure member
abuts the most significant byte of the current member. In this way,
fragmentation
within data structures is minimized and portability of data is enhanced.
The length field specifies the length (in bits) of the modulus for this public
key
object. The extra field is 16 bits of data provided to the application for
whatever it
chooses. The CGX Kernel does not read or write this field. Furthermore, it
will
preserve this field while the public keyset is internally stored in volatile
or non-volatile
memory.
The following sections define the public keyset objects for each of the
algorithm types supported.
Diffie-Hellman Public Keyset
The Diffie-Hellman keyset implements the following formula: Y mod n.
The two variables g and n are combined to form the modulus, Y is the public
key, and y
is the private key. The contents of the private key must be protected.
Therefore, the
variable y of the DHprivkey object must be covered before it can be exported.
Also, a
salt field is included to avoid cipher-text attacks on the covered Diffie-
Hellman private
key. Figure 25 illustrates the three objects that make up a Diffie-Hellman
keyset.
152
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
RSA Public %yset
The RSA keyset implements the following formulas: c = m' mod n, m = cd mod
n, where n = p q. The variable n is the modulus, e is the public key, and p,
q, and d
make up the private key. The variables p, q, d mod (p-1), d mod (q-1), and q71
modp
are kept around as for optimization; they are used by the Chinese remainder
theorem.
This data must be protected as the private key is. Therefore, the privkey
object must
be covered before it can be exported. Also, a salt field has been added to
avoid cipher-
text attacks on the covered RSA private key. Figure 26 illustrates.the three
objects that
make up a RSA keyset.
DSA-Public 1%yset
The DSA keyset's variables implements the following signing formula: r=(g"
modp) mod q, and s=(k 1(H(m) + x r)) mod q. The following variables implement
the verification formula: ul = (H(m) (s 1 mod q)) mod q, and u2 = (r (s' mod
q)) mod
q, and v=((g"1 yi2) modp) mod q, where y = gx modp. The variables p, q, and g
make up the modulus, y is the public key, and x is the private key. The other
variables
r, s, and v are results from the actual calculation and are not stored in a
DSA public
keyset. However, the contents of the private key must be protected. Therefore,
the
variable x of the DSAprivkey object must be covered before it be exported.
Also, a salt
field has been added to avoid cipher-text attacks on the covered DSA private
key.
Figure 27 illustrates the three objects that make up a DSA keyset.
Digital Signature
The digital signature object, signblock, is used to represent a digital
signature
for DSA public key only. The data structure contains the sign result vectors.
The DSA signblock is represented as two vectors, r and s, to house the results
of the DSA digital signature sign operation; stored in two buffers of 16 bit
units or
WORD 16 data types. This allows for more efficient storage and access schemes.
By
153
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
default, the two vectors are stored with its most significant bits in the
upper bits of the
WORD16 buffers. Figure 28 shows the DSA signblock object definition.
Seed Key
For generating reproducible prime numbers for DSA modulus', p and q, a seed
key object is required. The seed key object is used by the application to
provide a 160
bit seed value for generating the primes and for a counter to be used in
verifying the
primes.
The DSA seedkey object is represented as a 32 bit counter and a 160 bit seed
buffer. Figure 29 shows the DSA seedkey object definition.
Key Cache Register Data Type
Key cache registers are represented by a register ID value. The register ID
can
be between 0 and 14 (the maximum allowable key cache registers). However, key
cache register number 0 is reserved for reference to the LSV (laser-trimmed)
key cache
register. The key cache register data type is shown in Figure 30.
Red Keys
The CGX Kernel allows the importation of Red key material, both secret and
public keys.
Context Manasement
Context management for the CGX Kernel is a critical requirement from the
point of view of security, real-time, and storage. Context management allows
the
application to interleave several occurrences of a cryptographic operation.
For
example, the CGX Kernel only has one KG (or crypto-block) to encrypt with.
However, some applications (e.g. packet networks) may have several encryption
sessions going on at the same time. If the CGX Kernel did not implement
context
management then it could not start an encryption session for another party
until the
154
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
current party released the resource. This is because the use of the crypto-
block
requires state information about the encryption session to be saved between
calls to the
encryption command, CGX ENCRYPT. If the state information isn't saved between
calls then the next block will not encrypt correctly. So without context
management,
the application cannot share various resources of the CGX Kernel.
Context Stores
Like the kernel block the context stores are defined as blocks of memory with
pointers to buffers specified by byte counts or implicit byte counts; thus
providing a
language (i.e. compiler or assembler) independent block interface.
Symnted ical Encryption Context Store
The context store for symmetrical (i.e. secret key) cryptographic commands
(CGX ENCRYPT and CGX DECRYPT) are shown in Figure 31.
The size of the crypto cntxt block is 12 bytes of contiguous memory. The
config field is used to select the encryptioa configuration (i.e. modes,
loading
configuration, and feed-back count); the constants to use for this field are
defined in
the document titled, CryptlC Command Interface Specification. The size of the
KCR
ID is 2 bytes. Note that the iv buffer size is fixed to 8 bytes. However,
depending on
algorithms used in the future, the iv buffer can grow easily if need be. This
is because
the iv buffer is at the end of the object and can be added to and still allow
for backward
compatibility.
The state information to restore the secret key context is saved in the
buffer, iv,
after each call to the CGX ENCRYPT or CGX DECRYPT commands. The
application is responsible for priming the iv buffer with an initial random
value when
starting a new encryption session for a key. Moreover, to implement a simple
resynchronization service, the application only needs to modify the iv buffer.
The CGX Kemel writes back the feed-back register of the hardware crypto-block
into
the iv buffer for the CBC, CFB, and OFB modes after each call to CGX ENCRYPT
or CGX DECRYPT. The iv buffer must remain unchanged by the application to
155
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
maintain synchronization with the receiving end of the encryption session.
There is no
iv buffer required in the case of the ECB mode; the iv buffer pointer is
ignored and the
application is not required to set it. Another advantage of the crypto_cntxt
is that the
application has full access to the iv (i.e. the feed-back register or crypto-
block state
information) at any time.
One- Way HASH Context Store
The context store for the one-way HASH cryptographic commands
(CQX INIT HA.SH and CGX HASH DATA) is shown in Figure 32.
The size of the hash cntxt block is 96 bytes of contiguous memory. The
algorithm field is used to select the one-way HASH function algorithm (i.e.,
MD5 or
SHS); the constants to use for this field are defined in the document titled,
CryptIC
Command Interface Specffrcation. Note that the digest buffer size is variable
depending on the algorithm used;1V1D5 uses a 128-bit digest and SHS uses a 160-
bit
digest. Only after closing the hash will the message digest field point to the
message
digest. The length of the state information is fixed for all algorithms based
on the use
of a union. The length of the state buffer is defined to be 96 bytes or 48
words.
SOFTWARE INTERFACES
This section describes the two major software interfaces, the command
interface and the CGX overlay.
Command Interface
As discussed earlier the command interface provides the API between the CGX
Kernel and the application. This is accomplished via a shared memory block and
a
transfer vector. The shared memory is implemented via the kernel block and the
transfer mechanism is via specialized hardware logic.
156
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Shared Memory
The kernel block (defined in the section Kernel Block) provides the shared
memory necessary for the CGX Kernel and application to communicate with one
another. Furthermore, unlike other shared memory schemes the kernel block is
not a
static area. The kernel block is reestablished for each cryptographic command
request.
This has the advantage of allowing the application to dynamically allocate the
kernel
block on the fly or better yet controlling which pieces of the kernel block
(the
command and/or status blocks) are statically versus dynamically allocated. The
advantage with this is that the application can setup several static copies
for each of
the -cryptographic commands before hand. Thus reducing the overhead of having
to
repopulate the command fields before each call to the CGX Kernel.
Like everything there are disadvantages to not having a fixed static kernel
block. The most interesting disadvantage is that the CGX Kernel becomes a
synchronously driven engine; not asynchronous. This is because if it was
asynchronous, the CGX Kernel could post events, asynchronously, to the status
block
to report the health of its crypto-functions in real-time. However, the CGX
Kernel
does not run asynchronously; it only runs when it is invoked by the
application and the
rule is that it has control of the processor until it completes. Furthermore,
the CGX
Kernel will only modify the current kernel block while a cryptographic command
is
executed.
CGX Kernel Transfer Vector
In order to execute a cryptographic service, the application must explicitly
invoke the CGX Kernel. To do this a special transfer vector mechanism has been
created. The transfer mechanism is a specific call to address 0x2000
instruction with
the PMOVLAY register set to Ox000F. The AR register must contain a pointer to
the
kernel block which defines the command requested.
When the software call instruction occurs, the special hardware logic (along
with some hardware signals and counters) overlay the ROM encoded CGX Kernel
157
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
program block over a portion of the application's program space. Once control
has
been passed to the KemeI, the application is prevented from monitoring the CGX
Kernel's ROM, RAM or register areas.
To avoid forcing the application to understand the transfer mechanism, a
single
transfer vector routine is supplied by IRE to be used by the application.
Furthermore,
all of the cryptographic command definitions are provided as 'wrap code'
around this
single transfer operation; thus alleviating the application of supporting this
operation.
CGX gernel Transfer Vector Operation
The CGX Kernel transfer operation is fast and simple. The general idea behind
the transfer operation is to establish a calling frame (kernel block and
command block),
transfer into the command mode of the CGX Kernel, execute the command, and
return
back to the application with the results.
The CGX Kernel transfer operation may be implemented as a function call by
the application. A header file defining the operations for all of the
cryptographic
services is provided. These definitions consist of a macro that is used as
wrap code to
the transfer vector operation. The macros populate the kernel block with the
appropriate commands and arguments. For example, to encrypt a block of data
using
the encryption command, CGX ENCRYPT, the application would use the macro
wrap definition illustrated in Figure 33 and found in the cgx.h header file
provided by
IRE to the customer. The cgx.h header file is provided to the application as
the
software interface to the CGX Kernel cryptographic services. The application
only
needs to use this definition file and the transfer operation,
cgx transfer secure kernel, to interface to the CGX KerneI .
As can be seen in Figure 33,the wrap code prepares the kernel block for
communications between the application and the CGX Kernel. (Optimizations to
the
wrap code have been previously suggested in the description of the kernel
block. It is
possible that the application can establish the kernel block once and just
call the
transfer operation cgx transfer secure kernel over and over. This would speed
things
158
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
up so that the kernel block populate code would not be re-executed. This would
only
be useful for repetitive commands, like traffic encryption.) Looking at the
example
closer, one notices a call to the operation, cgx transfer secure kernel, at
the end of
the macro wrap code cgx encrypt. The transfer operation,
cgx transfer secure kernel, performs the actual transfer of control from the
application to the CGX Kernel. The transfer operation is responsible for
assigning the
kernelblock object pointer to the AR register and forcing a software interrupt
to cause
control to be transferred to the CGX Kernel.
When the transfer operation is invoked it simply performs these four steps:
= First it saves the return address to the calling function (i.e. the
application) on the
software stack,
= second it populates a general purpose register with the pointer to the
kernel block
in the AR register,
= third it transfers control to the CGX Kernel by forcing a software
interrupt, and
= fourth the CGX Kernel returns back into the transfer operation in the
application
memory space, because of the PC stack save caused by the software interrupt,
and
it returns to the calling application's operation because of the saved address
in step
1.
CGX Overtav Interface
As discussed earlier, the main purpose of the overlay operation is to provide
the proper wrap code around the CryptoLIB operations. This allows the total
reuse of
the CryptoLIB software and hiding the CryptIC platform specific hardware
functions
from the application and the CryptoLIB software. To do this, there is a one to
one
mapping of CGX overlay operations (the wrap code) to each cryptographic
command
supported by the CGX Kernel.
159
CA 02303297 2000-03-13
WO 99114881 PCT/US98/19316
CGX Overlay Table Def nition
Figure 34 shows a single CGX overlay tupple. The CGX overlay table
contains N CGX overlay tupples or entries. The member cgxf is a pointer to the
CGX
overlay operation that is invoked by the CGX Kernel if the control variable
satisfies the
necessary requirements. The control variable contains a preemption bit.
CGX Overlay Table Processing
To simplify things, the CGX overlay operations reside in a table of CGX
overlay tuples as defined by the data structure, cgx overlay_tuple, that is
indexed by
the cmd field of the command block of the kernel block (e.g. kb->cb->cmd).
Once the
CGX Kernel determines which tupple out of the CGX overlay table is the correct
tupple to access, it must perform another check to determine if the
appIication has
proper access to the tupple.
To do this, the CGX Kernel must first verify the preemption bit (part of the
control field) allows it to enter the command mode. The preemption bit
occupies the
most significant bit (i.e. bit 15) of the control variable; thus the
preemption mask value
is 0x8000. If the bit is a 1, it must enter the command block mode. In the
command block mode, the CGX Kernel will not let another command preempt the
current command. If the bit is a 0, the CGX Kernel will enter the command mode
where the current command can be preempted by a secret key
encryption/decryption
or one-way Hash command.
COMMAND INTERFACE RESOURCES
Besides the set of CGX cryptographic commands, the application is presented
with various resources, mainly in the area of configuration registers and
storage. As in
most processor platforms, the developer is presented with a set of
instructions and
160
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
memory stores (either memory or registers) to manipulate data; with the
CryptIC the
application is also presented with memory storage capabilities.
IIyTITALIZATION PROCESSING
The initialization process of the CGX Kernel can be invoked at any time via
the
CGX Command Interface. To invoke the initialization processing of the CGX
Kernel,
the CGX INIT command is issued. This command allows the application to
customize the CGX Kernel in two ways: the Kernel Configuration String and PCDB
settings.
To do this, the CGX Kernel allows the application to pass in initialization
strings for the two areas. The initialization strings are an array of defined
bits to allow
the application to set, disable, and enable various features of the CGX
Kernel. The
following sub-sections define the initializa.tion strings allowed as part of
the
CGX INIT command.
Kernel Configuration String (KCS)
The Kernel Configuration String is a set of bit-mapped words which control
certain features in the CGX kernel. These features include: Semaphore handling
and
feature enables. The KCS object definition is shown in Figure 35.
Programmable Control Data Bits Initialization String (PCDB_IS)
Program Control Data Bits (PCDBs) are a set of bit-mapped words which
control certain features in the CryptIC. These features include: Symmetric and
Public
key lengths, RED key load enable, Algorithm enables, etc. The CryptIC is laser-
programmed at the factory with a default set of PCDBs.
The PCDB IS allows the application to customize the CGX Kernel PCDBs.
For example, the PCDB IS allows the application to give the CGX Kernel
permission
to change lengths of key material. However, the PCDB IS needs an unlock-data
161
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
message to gain permission to change the PCDBs. This message is digitally
signed
using an IRE private key, and the CryptIC verifies the signature with its
public key.
Without the unlock-data message the application is denied access to the PCDBs
and
the PCDB-IS is ignored.
The PCDB IS's first word is used to specify the number of words succeeding
the first word. If the application only wants to program data in the first
word of the
PCDB IS it would only need to set the size word (the first word of the PCDB
IS) to a
Oxl, and then pass in a PCDB_IS buffer of two words. The remaining words take
on
the factory default settings. Furthermore, depending on the unlock-data
message, the
application may not gain permission to all of the PCDBs. The CGX Kernel will
ignore
any bits in the PCDB IS that the application has no permission to change In
the
PCDBs.
The following lists the PCDB_IS words in lowest memory order, defining the
bits that are programmable to the application:
Word 0:
As shown in the table below:
= Bits 0- 4 set the maximum allowed symmetric key (DES, triple-DES) length.
The
starting size is 40-bits and these bits allow a step size of I byte up to 168-
bits.
= Bits 5- 7 set the maximum allowed asymmetric key (RSA, DSA, D-H) length.
The starting size is 512-bits and these bits allow a step size of 256-bits up
to 2048
bits.
= Bit 8 selects whether triple-DES is allowed for traffic encryptioa It is
always
allowed for Key encryptioa
= Bit 9 selects whether the CryptlC will allow Red key loading.
= Bit 10 selects whether the RSA public key algorithms are enabled. A royalty
fee is
due to RSA for those chips which have this feature enabled.
162
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
= Bits 11-15 are reserved.
Word 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
:
";:::::
X X X X X X X X X X X
Symmetric key maximnm length (in bytes - 40 to 168)
Asymmetric key maximum length (in 256's - 512 to 2041
1= Triple-DES enabled for traffic encryption
1= Allow Red key loading
1 = RSA algorithms enabled
Reserved (set to 0)
Word 1:
As shown in the table below:
= Bits 0 - 2 set a hardware delay-line which is used for adjusting the timing
pulse for
External Memory access. This is typically configured at the factory to account
for
IC process changes.
= Bits 3 - 14 set the hardware revision number of the CryptIC. This value is
returned
in the CGX GET CHIPINFO command.
= Bit 15 is reserved.
Word 1
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
'~'
x x x x x X X x X x x x x x x
~
L-:External memory pulse shaping
Hardware revision number code
Reserved (set to 0)
KEY STORAGE
The CGX Kernel provides several areas for storage of symmetric and public
keys. It contains three areas: Key RAM, Key Cache Registers (KCRs), and the
Application Space. The Key RAM is a working area for one pubfic key. A working
area inlplies that it is volatile; in other words the public key is lost on
power-down and
163
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
resets. All public key operations (i.e., encryption or digital signatures) use
the volatile
key RAM for that single public key storage and for intermediate results.
The volatile Key Cache Registers provide a working area for many symmetric
keys. Again, this is a working area so all the keys will be lost during a
power-down or
reset. The 15 volatile Key Cache registers are addressable via register Ids
from 0
through 14 (where 14 is the last addressable register). The key cache
register, 0, is
reserved for the LSV symmetric key. The command interface uses the key cache
register Ids as the addressing mechanism for storage, retrieval, and
encryption.
Note: Additional key storage can be achieved within the CryptIC through the
use of extended RAM. A parameter can be passed in the CGX INIT command to
request allocation of increments of lkbyte of internal DSP Data RAM to key
storage.
Up to 700 symmetric keys can be accomodated in this manner.
The Application Space can be used for non-volatile or long time storage for
persistent key material. The CryptIC does not contain non-volatile memory
(other
than the Laser-programmed bits). However, the section Key Management discusses
how keys can be stored off chip securely using the commands discussed in this
memo.
COMMAND INTERFACE DEFINITIONS
The following sub-sections provide a listing of the command interface
definitions. The definitions provide the proper argument values for micro
commands,
status information, and object definitions. These definitions must be used in
order to
communicate correctly with the CGX Kernel.
COMMAND DEFINTTIONS
The following table represents the valid command definitions:
164
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Name Value
Gateral Commands
CGX IN1T Ox0000
CGX DEFAULT Ox0001
CGX RANDOM 0a0002
CGX GET CElII'INFO 0x0003
' Conanands
Ennyptum CGX UNCOVER KEY 0x0004
CGX GEN KEK 0x0005
CGX GEN REY 0x0006
CGX LOAD KEY Ox0007
CGX DERIVE KEY 0x0008
CGX TRANSFORM REY 0x0009
CGX EXPORT KEY Ox000A
CGX IIvIPORT KEY Ox000B
CGX DESTROY KEY Ox000C
CGX LOAD KG Ox000D
CGX ENCRYPT Ox000E
CGX DECRYPT Ox000F
Public Key Commands
CGX GEN PUBKEY Ox0010
CGX GEN NEOVPUBKEY Ox0011
CGX GEN NEGKEY 0x0012
CGX PUBKEY ENCRYPT 0x0013
CGX PUBKEY DECRYPT 0x0014
CGX EXPORT PUBKEY 0x0015
CGX IIvIPORT PUBKEY 0x0016
D' ' Signature Commands
CGX SIGN 0x0017
CGX VERIFY 0x0018
Extended A orithm Command.s
CGX LOAD EXTENDED 0x0019
CGX EXEC EXTENDED Oa001A
Sash Commands
CGX HASH INIT Ox001C
CGX HASH DATA OxOOlD
CGX HASH ENCRYPT Ox001E
CGX HASH DECRYPT Ox001F
Math Commands
CGX MATH 0x0021
Name Value
PRFCommmtds
CGX PRF KEY 0x0020
CGX PRF DATA Ox001F
CGX MERGE KEY 0xW21
CGX MERGE LONG KEY 0x0022
CGX LONG KEY EXTRACT 0x0023
R$E$ Commands
CGX GEN RKEK Ox0024
CGX SAVE KEY Ox0025
Table 13 Command Definitions
165
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
STATUS DEFINITIQNS
The following table represents the allowable status definitions, returned by
the
CGX Kernel:
Command Value Deacri tion
CGX SUCCESS S Ox0000 C hic service completed succesdhUy.
CGX WEAK KEK S Ox0001 A weakly generated KEK (a secret key) was used as an
argummt The KEK is rejected and the service fails.
CGX E1vIPTY REG S 0x0002 An empty key cache register was referenaed, the
service fails.
CGX IIWALIDREG S 0x0003 An invalid key cache register was given, the service
fails.
CGX ACCESS DENIED_S 0x0004 Attempt to export RED key material but the
RED KEY EXPORT_ENABLED PCDB bit is not
enabled, the service faiLs.
CGX WEAK KEY S 0x0005 A weakly generated key (a secret key) was used as an
ar ent. The key is rejected and the service faiLs.
CGX HARDWARE_FAII.URE_S 0x0006 One or more hardware devices used to implement
the
requesW service has failed.
CGX BAD MODULUS S 0x0007 A bad modulus (i.e., not greater than 0) was used.
CGX INVALIDKEY LEN_S Ox0008 Invalid secret key length used. Only 40, 64, and
128
bit length secret kev lengths allowed.
CGX BAD MODE S 0x0009 Invalid mode (i.e., only ECB, CBC, CFB, and OFB
modes allowed) used. The service fails.
CGX_PRIVILEGE DENIED_S Ox000A Invalid login ID and/or PIN, or login ID does
not have
rivile e access to cryptogmphic operation-
CGX INVALID CMD S Ox000B Invalid command opcode constant val. provided.
CGX INVALIDLEN S Ox000C Invalid length (i.e., constant value) provided.
Retnrned
for public kev operations onlv.
CGX_BAD KEYSET_S Ox000D Specified public keyset source location is empty or
contains the incorrect public kevset.
CGX INVALID_SIGNATURE_S Ox000E The digital signature verification failed; the
signature
of the application's message does not match the
signature of the verification signature block. '
CGX BIGNUM FAIL_S Ox000F Public key processing failed due to large integer
failure
(i.e., overIIow condition).
CGX BAD KEK S Ox001F Invalid KEK or NULL when KEK az ent required.
CGX RAM_FAIL_S Ox0011 low level RAM diag's failed
CGX ROM FAIL_S Ox0012 low level ROM diag's failed
CGX LSV FAIL S 0x0013 low level LSV CRC test failed
CGX NULL PTR S 0x0020 NULL Pointer oassed when argument required.
CGX FAII.ED TOKEN SN S 0x0028 cmd failed token serial number check
CGX FAILED TOKEN_VERIFY_ 0x0029 cmd failed token verify signature
S
CGX FAILED RKEK S Ox002A cmd failed RKEK
CGX FAILED NEG KEY S OxOO2B failed Diffie HeIIman negotiate key
CGX FAILED SAVE KEY S Ox002C failed save key operation
CGX FAILED GEN RKEK S Ox002D failed gen RKEK on
CGX FAILED LOAD KEY S Ox002E failed load kev operation
CGX PROG NOT RUN OxOO2F Start address 0 lied (to IRE internal test
166
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Commaad Value Desc ' tion
CGX STARTED S OxOOFC Apphcation has made the requen to CGX
CGX RUNNING S OxOOFD CGX has acmpted the call and is mumng.
CGX FAII. S OxOOFE General catch-all failure code.
CGX BUSY S OxOOFF Secare Kernel Busv, can not be preeniptecL
Table 14 Status Definitions
ALGORITHM. MODE. AND KEY USAGE DEFINITIONS
This section defines the algorithms, mode, and key usage definitions for
symmetric key, public key, digital signatures, and one-way Hash operations.
Key Usage Definitions
The following table defines the key usage bits that must be specified when
generating, loading, negotiating, or deriving a public or symmetric key. The
constant
vatues referenced in the table must be used in order to use an IRE symmetric
or public
key within the confines of the CryptIC device.
167
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
Name Value Deacii n
CGX_KCR DEK 0x0002 This key definition is re.served for symmerric keys that
are
to be used for traffic or messa e encrMon only
.
CGX KCR DKEK 0x0008 This key defmition is resmved for symmetric keys that are
to be used to cover other symmetric or public keys. The
covered key must be a DEK, not a KEK.
CGX KCR KEK Ox0010 This key de6nition is reserved for public keys and
symmetric keys that are to be used to cover other symmetric
or public k.evs.
CGX KCR UNTRUSTED Ox0100 This constant can be or'ed with any of the three
definitions
above to force a newly generated, loaded, negotiated, or
derived symmetric or public key to be known as an
untivsted key. This is important if the application intends
to export a particular key, only untrnsted keys can be
exported. Fnrthermore, the nntcvsted key must not be
under (i.e. covered by) a tcusted parent or it can't be
exported as well.
Table 15 Key Usage Definitions
Symmetric Key Algorithms
The following tables define the sqmmetric key algorithms and thair operating
modes. The
constant values referenced in the tables must be used in order to access the
CGX Kernel's symmebric
key algorithms.
Name Value State Contezt Description
Length (ie., the
dynamic IV)
DES
CGX DES A Ox000I 0 bits 0 bytes) Single DES: ECB, CBC. CFB, and OFB
' IeDES
CGX TRIPLE DES A 0x0002 128 bits (16 bytes) Triple DES: ECB, CBC. CFB, and OFB
RCS
CGX RC5 A 0x0004 0 bits 0 bytes) Single RC5: ECB, and CBC
SMAC
CGX HMAC_A 0x0008 0 bits (0 bytes) Only used by the CGX TRANFORM KEY
command for IPsec kev transforms.
Table 16 Symmetric KeyAlgorithm Bits
.168
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Name Value D tion
CGX ECB M Ox0001 Electronic CodeBook Mode. No N
CGX CFB M 0xOO02 Cipher FeedBadc Mode. N required
CGX OFB M 0x0004 Output FeedBack Mode. IV reqmred
CGX CBC M 0x0008 Cipher Block Chaining Mode. N required
CGX 1B1T FB OxOo 10 Feedback bits for both the OFB mode and the
CFB modes above. Defines 1-bit feedback.
CGX BBIT FB 0x0020 Defines 8-bit feedback
CGX 64B1T FB 0x0040 Defines 64-bit feedback.
Table 17 Symmetric Key Mode Bits
The symmetric key algorithm bits are supplied in the symmetric key object
(discussed in the memo, Cr)ptIC Software Architecture), the key type field.
When
symmetric keys are created or imported into the CryptIC the type of the
symmetric
key specified in the key type field of the symmetric key object defines the
type of
symmetric key algorithm to use. The symmetric key algorithm bits are not used
as part
of the algorithm field of the crypto_cntxt object.
Also, the bits (7 through 9) of the algorithm word, of the algorithm field of
the
crypto_cntxt object, is used to contain the special encryption control bits.
Currently,
there are two bits used to specify how keys are loaded into the KG during
encryption.
The masks are or'ed into the algorithm and mode constants defined above.
169
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Name Bit Mask Description
CGX AUTOLOAD_C 0x0080 This mask is used to request the CGX Kernel to
perform an auto load key when encrypting. The use
of auto load means that if the key is already loaded
into the KG (i.e., the crypto-block) don't repeat the
key load for this operation. This is the default
mode.
This mask is used to reqnest that the CGX Kernel
CGX FORCELOAD_C Ox0100 always loads the key when enccypting.
This mask is used to request that the CGX Kernel
CGX NOLOAD_C 0x0200 perform no key load when encrypting.
This mask is used to request that the CGX Kernel
CGX_RESYNC_C 0x0400 re-start the OFB or CFB mode. To restart traffic
synchronization it only has to encrypt the N before
it can aimvpVdecript traffic.
Table 18 Symmetric Key Load Definitions
Public Key Algorithms
The following table defines the supported public key algorithms (this includes
digital signatures as well) and their operating modes. The constant values
referenced
in the table must be used to access the CGX Kernel's public key algorithms.
Name Value Description
CGX RSA A 0x0001 RSA pubhc key, encr3Ttion and si tures.
CGX DSA A 0x0002 DSA ublic kev, signatma.
CGX DH A 0x0003 Diffie-Helltnan public kev exchange.
Table 19 Public Key Algorithm Definitions
One-Way Hash Algorithms
The following table defines the supported one way HASH algorithms and their
operating modes. The constant values referenced in the table must be used to
access
the CGX Kernel's one-way HASH algorithms.
170
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Name Value Ms Digest Length Description
CGX MID5 A Ox0000 128 bits (16 bytes) Specifies the MD5 one wav HASH al
orithm.
CGX SHS A Ox0001 160 bits (20 bytes) Specifies NIST's one wav HASH al orithm,
SHS-1.
Table 20 One Way HASHAIgorithm Definitions
IPsec Symmetric Key Transformation Algorithms
The following table defines the supported IPsec symmetric key transformation
algorithms supported. The constant values referenced in the table must be used
to
access the CGX Kernel's CGX TRANSFORM KEY command.
Name Vsdue Descrition
CGX XOR V Ox0001 This operation exclusive-ors a data pattern with
the svmmetric kev and then HASHes it.
CGX PREPEND_V 0x0002 This operation pre-pends the data pattern to the
svmmetric kev and then HASHes it.
CGX APPEND_V Ox0004 This operation appends the data pattern to the
svmmetric kev and then HASHes it.
Table 21 IPsec Symmetric Key Transformation Algorithm Definitions
171
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
COMMAND SPECIFICATION & ARGUMENTS
The following portion of this description defines the command set by
specifying
in detail a description of the command, the argument list specification (i.e.,
the kernel
block and' command block configuration), and result codes. When an asterisk is
pre-
pended to the command name it implies the command is optional and it may not
be
implemented.
General Commands
INIT (Initialize Secure Kernel)
Command Name: CGX 1NIT
Command Description:
The Init command is used to initiaGze the secure Kernel; the Init
command can be used at any time. However, the entire command
interface, volatile key RAM, and volatile key cache registers are reset;
the processor is not reset. The Init command allows the application to
customize the secure Kernel's PCDBs, the number of Key Cache
Registers (from 15 to 700) and the command interface using the KCS.
In particular the application must present the unlock-data message at
this time to reprogram any PCDBs that it has permission to change.
The command takes, as an input, pointers to unsigned character
buffers. The use of unsigned char is to standardize on a little endian
memory model as the default. Using the Init command, the application
can then change the endian memory model to the memory model it
desires.
There are three programmable areas: Program Control Data
Bits via the pcdb initialization string (includes the signed token),
extending the Key Cache Registers by requesing to lock internal DM,
172
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
and the Kernel Configuration via the kc initialization string. See the
section Software Data Objects for detailed information defining the
PCDB and KCS initialization strings.
Command Interface:
/* initialize the secure kernel */
cgx init( kernelblock *kb,
unsigned char *pcdb,
unsigned char *kdat,
unsigned char *kstart,
unsigned char *kc)
Arguments:
kb->cb->cmd = CGX IlvIT;
/* the PCDB initialization string
/* set to NULL if no initialization required */
/* the first byte must contain string length in bytes */
kb->cb->argument[0] = (VPTR)pcdb;
/* extended key RAM pointer */
/* set to NULL if no extended KCR required
kb->cb->argument[ 1 ] = (VPTR)kdat;
/* extended key RAM start pointer */
/* set to NULL if no extended KCR required
kb->cb->argument[2] = (VPTR)kstart;
/* the Kernel Configuration String */
/* set to NULL if no initialization required */
/* the first byte must contain string length in bytes */
kb->cb->argument[3] = (VPTR)kc;
Status:
kb->sb->status = CGX SUCCESS S
DEFAULT (Restore Factory Default Settings)
Command Name: CGX DEFAULT
Command Description:
The Default command is used to undo all of the initialization
processing that occurred via the CGX 1NIT command. This command
173
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
forces the secure Kernel to reset all of the settings (i.e., command
interface and PCDBs) back to factory default settings.
The Default command can be used at any time. However, the
entire command interface, volatile key RAM, volatile key cache
registers, and PCDB settings are reset; the processor is not reset.
Command Interface:
/* Restore factory default settings
cgx default( kernelblock *kb )
Arguments:
kb->cb->cmd = CGX DEFAULT;
Status:
kb->sb->status = CGX SUCCESS S
RANDOM (Generate Random Numbers)
Command Name: CGX RANDOM
Command Description:
The Random command is used to obtain random bytes of data.
The random bytes come from the random number generator hardware
device. The application is allowed to request between 1 and 65535
bytes of random data at a time.
Command Interface:
/* Generate a random number */
cgx random( kemelblock *kb,
VPTR rbuf,
unsigned short rbuf size )
Arguments:
kb->cb->cmd = CGX RANDOM;
/* the number of random bytes, between 1 and 65535 bytes
kb->cb->argument[O] = (VPTR)rbuf_size;
/* a buffer to hold the requested random numbers
174
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
kb->cb->argument[l] = (VPTR)rbuf;
Status:
kb->sb->status = CGX_SUCCESS_S, or
CGX HARDWARE FAILURE /* RNG hardware failure
See Also: CGX TEST
GET CHIPINFO (Return CryptIC System Information)
Command Name: CGX GET CHII'INFO
Command Description:
The Get Chipinfo command is used to obtain system
information about the secure Kernel. The system information is
returned in a data structure defined as:
typedef struct _clripinfo {
WORD 16 hw vsn; /* contains the hardware version mimber
WORD16 sw vsn; /* comtains the softatare version number
WORD16 kcr max; /* returns max number of KCRs */
WORD 16 kcr used; /* retnrns bit-map of active KCRs */
WORD 16 pcdb[N]; /* contains atll of the program control */
/* data bit values */
WORD16 serial_number[10]; /* unique CryptlC ID*/
} chipinfo;
The application need not use the data structure; however it must
pass a pointer to a buffer of the same size as the chipinfo data structure.
In any case, the returned data reflects the current status of the secure
Kernel's programmable values and its hardware and software release
numbers.
Command Interface:
/* obtain information about the secure Kernel and CryptlC */
cgx chipinfo( kernelblock *kb,
VPTR cbuf)
Arguments:
kb->cb->cmd = CGX GET_CHIPINFO;
175
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* a buffer to hold the reqnested chip info, */
/* must allow enough space as defined in data stnuKUre above */
/* in fact an instance of the data stiuC[ can be used
kb->cb->a:gutnentf ll = (VP'IR)dn&,
Status:
kb->sb->status = CGX SUCCESS S
See Also: CGX_INIT
Encrvation Commands
UN.COVER KEY (Load And Decrypt A Secret Key)
Command Name: CGX UNCOVER KEY
Command Description:
The Uncover Key command allows a generated KEK (i.e.
GKEK) or user created key to be decrypted and stored in the key
cache. The generated or internal GKEK can only be uncovered by the
LSV (i.e. KCR 0) and the user keys can be uncovered by a generated or
internal KEK or a user key (i.e. KKEK or KEK), not the LSV. The
Uncover Key operation allow user keys to be uncovered using any of
the supported secret key algorithms (i.e., DES, Triple DES, etc.), in
any of the modes (i.e., ECB, CFB, OFB, and CBC). As for GKEKs,
they can only be uncovered by the LSV in the triple DES CBC mode;
any attempt to bypass this will fail. The operation copies the secret key
from the application's memory in the covered form (i.e., BLACK) and
decrypts it into the source key cache register, key.
Like the rule for uncovering the GKEK, any key to be
uncovered by a GKEK must also use the triple DES CBC mode. Also,
an IV will be returned in the application supplied IV buffer of the
crypto_cntxt object. Therefore, the basic requirement is that the parent
KEK (i.e. LSV) to GKEKs must be a triple DES key and the GKEK
176
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
itself must be a triple DES key. This implies the use of triple DES in
the CBC mode when these two KEKs are used for uncovering and
covering of keys.
Prior to invoking the encryption command, the application must
setup the crypto_cntxt block. The application is responsible for setting
the mode, masking in one of the special key load options (described
below), setting the appropriate secret key KCR ID, and for populating
the iv buffer. If the key is a trafficlencryption key (i.e., keys that are
not GKEKs), the N buffer must be populated with the same N used by
the cover operation. Therefore, the application must have archived the
N buffer along with the covered key.
The iv buffer of the crypto_cntxt block must be read- and write-
able; the iv buffer is used to maintain the feedback register for the CBC,
CFB, and OFB modes. In the ECB mode the iv buffer is ignored.
However, in the case of uncovering keys, the N buffer is not updated
as is done in normal encryption. This is because the original N may be
needed to uncover the key again later.
The Uncover Key command allows the application to mask in
one of the special configuration and mode control bits defined in section
0, into the algorithm field of the crypto_cntxt block. The control bits
are used by the secure Kernel to determine how to load secret keys
before the actual encryption of the plain text takes place. The control
bits allow the application to request one of these options: auto-load,
force-load, or no-load. Auto-load allows the secure Kernel to check
which key is currently loaded into the KG, if it's the same as the key
specified for the encryption command it is not loaded; otherwise the
key is loaded. Force-load tells the secure Kernel to always load the
key. No-load tells the secure Kernel to not load the key; more than
177
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
likely the application has already loaded the key (maybe via the
CGX LOAD KG command). By default, auto-load is assumed.
Command Interfaces:
/* single encryption mode for key uncover
cgx uncover( kernelblock *kb,
kcr key,
secretkey *black key,
crypto_cntxt *cc)
Arguments:
kb->cb->cmd = CGX UNCOVER KEY;
/* uncovered and store in key cache rCglsiCr number, key kb->cb->argument[Ul =
(VPTR)key;
/* the sa7etkey object holding key to uncover ktr>cb->argument[IJ =
(VPTR)black key,
/* cumfiguration and mode definition, KEK kcr, crypto_cnUct
kb->cb->argnment[2] = (VPTR)cc;
Status:
kb->sb->status = CGX SUCCESS S.
CGX EMPTY REG S,
CGX BAD MODE S, or // GKEK only uses 3DES, CBC
CGX_INVALID REG_S
See Also: CGX COVER KEY
GEN KEK (Generate An Internal Key Encryption Key)
Command Name: CGX GEN KEK
Command Description:
The Generate KEK command allows the application to generate
an internal key encryption key (i.e. a GKEK) to be used to cover user
secret keys or public keys. The GKEK is generated using the output of
the random number generator. In order to return the GKEK it must be
covered with the LSV, no other secret key is allowed.
178
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Besides generating a GKEK, this command places a copy of
the key in its RED form in a KCR location and returns a BLACK copy
of the key ail at one time; thus it is an intrinsic key function. By
returning a BLACK copy of the GKEK immediately, another
application is prevented from obtaining the GKEK before the
application responsible for its creation does so. Furthermore, this
avoids the potential of duplicate copies of a GKEK; thus strengthening
its trust.
The GKEK is viewed as a trusted KEK by the secure Ke:nel.
Therefore, it can never be exported from the device in a BLACK or
RED form after it has been created and the initial BLACK copy was
returned to the application.
The newly generated KEK is left in the specified key cache
register, destkey, in the RED form.
is The Generate KEK command only generates Triple-DES secret
keys. Once a GKEK is created, the secure Kernel only recognizes the
GKEK as an internal key. Furthermore, the newly generated GKEK
can only be used to cover/uncover application secret keys and public
keys. Moreover, when an uncover operation is invoked to load a
GKEK, the application is not allowed to specify any algorithm; the
secure Kernel assumes triple DES in CBC mode. Also, the application
is not allowed to provide a N;, the secure Kernel provides it. This
holds true for keys that are covered under a GKEK as well.
Command Interfaces:
/*generate a secret key GKEK
cgx_gen kek( kernelblock *kb,
kcr destkey,
secretkey *bk)
179
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Argaments:
kb->cb->cmd = CGx GErr KEK;
/* KCR ID number to plaae newly generated GKEK
lcbacb->argument[0] = (VPTR)destlcey;
/* BLACK secretkey to redun the covered GKEK in
/* The GKEK is covered by the LSV */
kbacb->argum=t[1] = (VPTR)bk;
Status:
]cb->sb->status = CGX SUCCESS S,
CGX FAII._S,
CGX IIdVALID REG S, or
CGR HARDWARE FAII..URE_S /* RNG hardware failure
See Also: CGX UNCOVER KEY
GEN RKEK (Generate a Recovery Key Encryption Key)
Command Name: CGX GEN RKEK
Command Description:
An RKEK is a Diffie-Hellman negotiated, triple DES, trusted
symmetrical key. The RKEK is created by an application, an escrow
agent and IRE safenet trusted services to produce the two parts of a
negotiated key. IRE safenet trusted services delivers to the application
a signed token that contains the chip's serial number and the public key
necessary to create the negotiated key. The RKEK can only be
generated once the token has been verified.
Besides generating an RKEK, this command places a copy of
the key in its RED form in a KCR location and returns a BLACK copy
of the RKEK covered by the LSV all at one time; thus it is an intrinsic
key function. By returning a BLACK copy of the RKEK immediately,
another application is prevented from obtaining the RKEK before the
application responsible for its creation does so. Furthermore, this
avoids the potential of duplicate copies of a RKEK; thus strengthening
its trust.
180
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The RKEK is viewed as a trusted KEK by the secure Kernel.
Therefore, it can never be exported from the device in a BLACK or
RED form after it has been created and the initial BLACK copy was
returned to the application.
The newly generated RKEK is left in the specified key cache
register, destkey, in the RED form.
The Generate RKEK command only generates Triple-DES
secret keys. Once an RKEK is created, the secure Kernel only
recognizes the RKEK as an intemal key. Furthermore, the newly
generated RKEK can only be used to cover/uncover application secret
keys and public keys. Moreover, when an uncover operation is invoked
to load an RKEK, the application is not allowed to specify any
algorithm; the secure Kernel assumes triple DES in CBC mode. Also,
the application is not allowed to provide a IV;, the secure Kernel
provides it. This holds true for keys that are covered under an RKEK
as well.
Command Interfaces:
/*generate an RKEK
cgx_gen rkek(kernelblock *kb,
token no_data *t,
KCR kcr
publickey *dhpk
publickey *dhkek
secretkey *rkek)
Arguments:
(kb)->cb->cmd = CGX_GEN RKEK; \
(kb)->cb->argument[0].addr.dp = (UINT16)((kb)->dp); \
(kb)->cb->argument[0].ptr = (VPTR)(t); \
(kb)->cb->argument[ 1 ].ptr = (VPTR)(kcr); \
(kb)->cb->argument[2].addr.dp = (LJINT16)((kb)->dp); \
(kb)->cb->argument[2].ptr = (VPTR)(dhpk); \
181
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
(kb)->cb->argument[3].addr.dp = (UINT16)((kb)->dp); \
(kb)->cb->argument[3].ptr = (VPTR)(dhkek); \
(kb)->cb->argument[4].addr.dp = (YTIlVTI6)((kb)->dp); \
(kb)->cb->arguzment[4].ptr = (VPTR)(rkek); \
Status:
kb->sb->status = CGX SUCCESS_S,
CGX FAILED RKEK S,
CGX_FAILED_GEN_RKEK_S.
See Also: CGX UNCOVER KEY and CGX SAVE KEY
SAVE KEY (Save a Key Under an ItKEK)
Command Name: CGX SAVE KEY
Command Description:
The save key operation is a special operation used exclusively
by an
RKEK. The save key operation uncovers a secret key under its
context, then covers it under the RKEK.
Command Interfaces:
/*Save a key under an RKEK*/
cgx save_key( kernelblock *kb,
secretkey *bk_uncover,
crypto_cntxt *bkek,
secretkey *bk returned,
crypto_cntxt *rkek)
Arguments:
(kb)->cb->cmd = CGX_SAVE_KEY; \
(kb)->cb->argument[O].addr.dp = (UINT16)((kb)->dp); \
(kb)->cb->argument[0].ptr = (VPTR)(bk uncovered); \
(kb)->cb->argument[1].addr.dp = (U1AITI6)((kb)->dp); \
(kb)->cb->argument[1].ptr = (VPTR)(bkek); \
(kb)->cb->argument[2].addr.dp = (UI1VT16)((kb)->dp); \
(kb)->cb->argument[2].ptr = (VPTR)(bk returned); \
182
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
(kb)->cb->argument[3].addr.dp = (UIlNT16)((kb)->dp); \
(kb)->cb->argument[3].ptr = (VPTR)(rkek); \
Status:
kb->sb->status = CGX_SUCCES S_S,
CGX FAII.ED SAVE KEY S.
See Also: CGX UNCOVER KEY and CGX GEN RKEK
GEN KEY (Generate A Secret Key)
Command Name: CGX GEN KEY
Command Description:
The Generate Key command allows the application to generate
a user secret key. The secret key is generated using random numbers;
then transformed into the secret key form as directed by the type of
secret key specified (i.e. key_type) in the argument interface. The
generated secret key can only be covered by an internai generated KEK
(i.e. a GKEK) or via another user secret key (i.e. KKEK [if the
generated key is an encryption key] or KEK), not the LSV.
Besides generating a secret key, this command places a copy of
the key in its RED form in a KCR location and returns a BLACK copy
of it all at one time; thus it is an 'intrinsic key' function. By returning a
BLACK copy of the secret key immediately, another application is
prevented from obtaining the secret key before the application
responsible for its creation does so.
The application must also provide a key usage definition. This
is passed in via the argument 'use' and is provided to announce the use
of the newly generated secret key. Currently, the application has three
183
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
options: KKEK (CGX KCR KKEK) , KEK (CGX KCR KEK) or K
(CGX KCR K). Defining it as KEK or KKEK directs the secure
Kernel to only recognize this secret key as a KEK. Furthermore, when
defined as a KKEK, the key cannot be used to cover anything other
than data keys (type K). KEKs can only be used in key management
operations (e.g. CGX UNCOVER KEY, etc.). Defining it as K
directs the secure Kernel to only recognize it as a session key for traffic
or message encryption operations (e.g. CGX ENCRYPT, etc.).
A trust level must be given to a newly generated secret key.
The user can force the secret key to be recognized as an untrusted
secret key by or-ing in CGX KCR UNTRUSTED with the 'use'
argument. This directs the secure Kernel to automatically mark the
secret key as untrusted. This is useful if the application has plans to
eventually export the secret key via the CGX EXPORT KEY
command. Although, an untrusted secret key covered under a trusted
KEK (i.e. GKEK, LSV, or a trusted KEK or KKEK) can not be
exported; it is a securely protected key of the CryptIC device.
Moreover, if the application does not apply the un-trusted
attribute to the 'use' argument, the secure Kernel will determine the
trust level for the generated secret key. If the secret key is covered
under a trusted KEK it will become a trusted key. If the secret key is
covered under an untrusted KEK or KKEK it becomes an untrusted
secret key. In other words, it inherits its parents trust attribute.
The newly generated secret key is left in the specified key cache
register, destkey, in the RED form. A BLACK copy is retumed if the
application provides storage for a secretkey object and crypto_cntxt
object. If either of these objects are NULL then no BLACK secret key
184
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
is returned. This is otherwise known as a dangling key. A dangling
key is dynamic (one time or session oriented) because once the power is
lost the secret key is lost as well. Furthermore, the key can not be
exported because it has no covering KEK; this is required as
authentication for exporting a secret key.
If storage for a BLACK secret key is provided then the newly
generated secret key is covered by a KEK or KKEK specified in the
crypto cntxt object. The KCR location referenced in the crypto_cntxt
object must point to a KCR that contains a KEK or KKEK or the
operation fails. If the referenced KCR contains a KEK or KKEK the
newly generated secret key is covered and returned to the application.
The Generate Key command only allows the generation of keys
between 32bits and 168bits depending on the secret key type and if the
state of the device (i.e. domestic or export). The application can
choose between that range in increments of 8-bit units. Furthermore,
the newly created user secret key can be used as an
encryption/decryption key or as a user key encryption key (i.e. KEK) to
cover other user secret keys.
Command Interfaces:
/*generate a secret key or KEK
cgx_gen key( kernelblock *kb,
kcr destkey,
unsigned short key_type,
unsigned short length,
unsigned short use,
secretkey *bk,
crypto_cntxt *kek cc)
Arguments:
kb->cb->cmd = CGX GEN_KEY;
/* KCR ID number to place newly generated user secret key */
kb->cb->atgnment[Ol = (VP'TR)destkey;
185
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* type of secret key to generate, use one of the following:
* CGX DESA, and CGX_TRIPLE DES A
kb->cb->argumem[l] = (VPTR)IW! type;
/* length of user secret key to generate, 40 to 192 bits */
/* specified in units of bytes, in 8bit units
kb->cb->argnment[2] = (VPTR)length;
/* specify the key usage: CGX KCR K, CGX KCR KKEK or CGX KCR KEK
kb->cb->argnment[3] = (VPTR)use;
/* storage for a BLACK secret key */
kb->cb->argument[4] = (VPTIt)bk;
/* the KCR KEK location to cover the RED key into a BLACK key */
kb->cb->argument[5] = (VPTR)kek cc;
Status:
kb->sb->status = CGX SUCCESS S,
CGX INVALID REG S,
CGX_INVALIDKEY_LEN_S, or
CGX HARDWARE FAII,URE S/* RNG hardware failure */
See Also: CGX EXPORT KEY, and CGX UNCOVER KEY
LOAD KEY (Import A RED User Secret Key)
Command Name: CGX LOAD KEY
Command Description:
The Load Key command is used to load a user secret key into a
specified key cache register. The secret key to be imported is in the
RED form, depending on the value of use, the key can be used as either
a KEK or as an encryption key. This key is known as a user key to the
secure Kernel and can never be covered by the LSV, the secure Kernel
does not allow it.
After the secret key is loaded, if the user requested the black
copy of the key (i.e., bk is non-NULL), the key is covered using the key
encryption key specified in kek_cc. This is the only opportunity for the
application to receive the black version of the key; the cover command
no longer exists.
186
CA 02303297 2000-03-13
WO 99/14881 PCTIUS98/19316
The secret key is to be loaded by using the secretkey data
structure. The length field of the secretkey structure must be set by the
application to indicate the length of the imported secret key. Salt is not
required to be added to the key, it is in the RED form.
Command Interface:
/* import an application secret key */
cgx load key( kernelblock *kb,
kcr key,
secretkey *sk,
UINT16 use,
secretkey *bk,
crypto_cntxt *kek cc)
Arguments:
kb->cb->cmd = CGX LOAD KEY;
/* key cache registtr ID to load key into
kb->cb->argument[0] = (VPTR)kcy,
/* seaetkcy data stcucmre poinser for key to be loaded */
kb->cb->argumtnt[1] = (VPTR)sk;
/* kcr type to be used for loaded key (e.g. CGX KEK K)
kb->cb->argum.ent[2] = (VPTR)use;
/* pointer to buffer for storing BLACK key (NULL=>ignore) kb->cb->argument[3]
= (VPTR)bk;
/* cxypto context for the key encryption key
kb->cb->argument[4] = (VPTR)kek cc;
Status:
kb->sb->status = CGXSUCCES S_S,
CGX_FAILS, or
CGX I]WA_I.ID REG S
See Also: CGX UNCOVER KEY
DERIVE KEY (Derive A Secret Key From a Pass Phrase)
Command Name: CGX DERIVE KEY
Command Description:
187
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The Derive Key command allows a user secret key to be
created from an application's pass-phrase. The secret key is derived by
taking the one-way HASH of the application's pass phrase and using
the message digest for it as the secret key bits; then transformed into
the secret key form as directed by the type of secret key specified (i.e.
key type) in the argument interface. Furthermore, the derived secret
key can only be covered by an internal generated KEK (i.e. a GKEK) or
via another user secret key (i.e. KEK or KKEK, if the newly generated
key is not a KEK), not the LSV.
The application can choose the HASH algorithm to be used via
the argument, hash alg. Furthermore, the algorithm for choosing
which bits to use is outlined in Microsoft's CryptoAPI document, this
command is implemented to their specification. Also, the algorithm
only supports key bit lengths between 32 bits and 112 bits when
creating DES or Triple DES keys, 32 bits through 160 bits when
creating HMAC keys, and 32 bits through 128 bits when creating RC5
keys.
Besides deriving a secret key this command places a copy of the
RED form in a KCR location and retums a BLACK copy of it all at one
time; thus an intrinsic key function. By returning a BLACK copy of the
secret key immediately another application is prevented from grabbing
the secret key before the application responsible for its creation does
so.
The application must also provide a key usage definition. This
is passed in via the araument, use, and is provided to announce the use
of the newly derived secret key: Currently, the application has three
options: KEK (CGX KCR KEK), KKEK (CGX KCR KKEK) or K
188
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
(CGX KCR K). Defining it as KEK directs the secure Kernel to only
recognize this secret key as a KEK. Defining the key as a KKEK
restricts the use of the key to only covering other keys of type K
(CGX KCR K). Therefore, these keys can only be used in key
management operations (e.g. CGX UNCOVER KEY, etc.). Defining
it as K directs the secure Kernel to only recognize it as a session key for
traffic or message encryption operations (e.g. CGX ENCRYPT, etc.).
Furthermore, a tiust level must be given to a newly derived
secret key. The user can force the secret key to be recognized as an
untrusted secret key by or-ing in CGX KCR UNTRUSTED with the
use argument. This directs the secure Kernel to automatically mark the
secret key as untrusted. This is useful if the application has plans to
eventually export the secret key via the CGX EXPORT KEY
command. Although, an untrusted secret key covered under a trusted
KEK (i.e. GKEK, LSV, or a trusted KEK or KKEK) can not be
exported; it's a securely protected key of the CryptIC device.
Moreover, if the application does not apply the un-trust
attribute to the use argument the secure Kemel will determine the trust
level for the derived secret key. Unlike the secret keys generated via the
CGX GEN KEY command all secret keys derived with this command
are set as untrusted by the secure Kernel.
The newly derived secret key is left in the specified key cache
register, destkey, in the RED form. A BLACK copy is returned if the
application provides storage for a secretkey object and crypto_cntxt
object. If either of these objects are NULL then no BLACK secret key
is returned. This is otherwise known as a dangling key. A dangling key
is dynamic (one time or session oriented) because once the power is
189
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
lost the secret key is as well. Furthermore, the key can not be
exported because it has no covering KEK, this is required as
authentication for exporting a secret key.
If storage for a BLACK secret key is provided then the newly
derived secret key is covered by a KEK specified in the crypto cntxt
object. The KCR location referenced in the crypto cntxt object must
point to a KCR that contains a KEK or the operation fails. If the
referenced KCR contains a KEK the newly derived secret key is
covered and returned to the application.
The Derive Key command only allows the generation of keys
between 32-bits and 112-bits depending on the secret key type and if
the state of the device (i.e. domestic or export). The application can
choose between that range in increments of 8bit units. Furthermore, the
newly created user secret key can be used as an encryption/decryption
key or as a user key encryption key (i.e. KEK) to cover other user
secret keys.
Command Interfaces:
/*derive a secret key */
cgx_gen key( kernelblock *kb,
unsigned short pswd_pg,
unsigned short *pswd,
unsigned short pswd_len,
unsigned short hash alg,
kcr destkey,
unsigned short keytype,
unsigned short length,
unsigned short use,
secretkey *bk,
crypto_cntxt *kek cc)
Arguments:
kb->cb->cmd = CGX DERIVE KEY;
190
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* the application's pass phrase string
kb->eb->argament[0] = (VP'i'R)pswd;
/* the length of the application's pass phrase string in bytes
kb-'*cb->argameat[1] = (VPTR)pswd_len;
/* the HASH aig to use: CGX SHS_A, or CGX NIDS A
kbacb->azgument[2] = (VPTR)Lash a1g;
/* KCR ID number to place newly generated user secret key */
kb->cb->ar8ument[3l = (VPTR)destkcY:
/* type of secret key to generate, use one of the following:
CGX DES_A, and CGX TRIPLE DES A
kb->eb->argument[4] = (VPTR)key_type;
/* length of user secret key to ganerate, 40 to 192 bits */
/* specified in units of bytes, in 8bit units
kb->cb->argnment[5] = (VPTtt)length;
/* specify the key usage: CGX KCR K, CGX KCR KKEK, or CGX KCR KEK
kb->cb->argnment(6] = (VPTR)use;
/* storage for a BLACK secret key
kb->cb->argument(7] = (VP'lZt)bk;
/* the KCR KEK location to cover the RED key into a BLACK key
kb->cb->argument[8] = (VPTR)kck cc;
/* For the ADI target only, the data page where the pswd resides */
kb'>cb->argument[9] _ (VPTR)pswd_pg;
Status:
kb->sb->status = CGX SUCCESS_S,
CGX INVALID REG S,
CGX INVALID KEY LEN S, or
CIX_IiARDWARE_FAII.URE_S /* RNG hacdwate failure */
See Also: CGX EXPORT KEY, and CGX UNCOVER KEY
TRANSFORM KEY (Transform A Secret Key Using IPsec)
Command Name: CGX TRANSFORM KEY
Command Description:
The Transform Key command allows the application to perform one of
the IPsec secret key transforms on an existing secret key. The transform
command allows the application to create the HMAC, CBC DES, or CBC
Triple DES keys. Furthermore, it can be used to create the IV and replay
counters and beyond that it can be used to create the HMAC inner and outer
pre-computed digests to speed up the AH processing.
191
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
There are several variants of this command. This section describes the
common function that supports them all. The Command Interface subsections
describe macros that invoke the common function to achieve a specific
variation of the command. Users are urged to employ the specific macros to
invoke the command variants.
Any untrusted or trusted secret key, K, can be transformed., At no time
can a trusted or untrusted KEK, KKEK, GKEK, or LSV be used as the root
secret key to be transformed. The result can be retumed as a new covered
BLACK secret key or as a clear pre-computation of a secret key. However, in
either case, the root secret key remains intact - it is read-only.
Besides transforming a secret key, this command places a copy of the
key in its RED form (if an HMAC or CBC DES key is to be generated) in a
KCR location and returns a BLACK copy of it all at one time; thus it is an
intrinsic key function. By returning a BLACK copy of the secret key
immediately, another application is prevented from grabbing the secret key
before the application responsible for its creation does so.
In the case of generating another secret key the key usage definition of
the root secret key is inherited. Therefore, the newly generated secret key
will
inherit the tcust level (i.e. trusted or untrusted) and key usage (i.e. K).
However, the application can change the key type to any valid supported key
(i.e. DES, triple DES, or RC5) via the argument, ktype. Furthermore, it can
generate any key length it desires via the argument, klen.
The newly transformed secret key is left in the specified key cache
register (kcr), destkey, in the RED form. A BLACK copy is returned if the
application provides storage for a secretkey object, tk. It is covered under
the
192
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
root secret key's KEK which is passed in as the crypto_cnw object argument,
bkek. If the secretkey object argument, tk, is passed in as a NULL pointer,
the
operation will return a message digest via the hash context object argument,
hc. This returned hash context may be red or black (covered.) If the caller
wishes the returned hash context to be black, the user must specify a crypto
context, hkek, which the command will use to cover the returned hash context,
hc. If the user supplies a NULL parameter for hkek, hc will be returned in the
red (uncovered.)
In order to support the current IPsec transform, the application must
pass-in the patteras and operation data as arguments. The 'patterns' are the
data patterns to be applied (ie. XORed) to a root secret key and then HASHed.
Although the IPsec patterns are currently fixed to a single byte that is
repeated
64 times, this command forces the application to pass in the full 64-byte
patterns required to create a transformed secret key. This allows for the
possibility of future changes.
The application must pass in as many 64-byte patterns (i.e. as one large
array) as they will generate key bits or as long as specified by the argument,
klen. If the key to transform is to be a DES key and kien is less then or
equal
to 7 bytes, then 64 bytes of pattern are required, if the klen is less than or
equal
to 14 bytes then 128 bytes - or two 64 byte patterns - in one array are
required,
and if klen is less than or equal to 21 bytes then 192 bytes - or three 64
byte
patterns - in one array are required. If the key to transform is an RC5 key,
then
the application is only required to pass-in one 64 byte pattern.
The operation argument, oper, is used to specify the operation which
will 'combine' the root secret key and the data patterns. Cwrently, the
command supports three operations: exclusive-or (i.e. CGX XOR O), pattern
193
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
append (i.e. CGX APPEND_O), and pattern pre-pend (i.e.
CGX PREPEND O).
Command Interfaces:
/*transform a root secret key into a DES or HMAC key
/* Common interface. Caller must select proper combination of parameters to
achieve desired
fiutctionality. */
/* This interface is not recbmmended for user applications; instead user
should use one of the
subsequeufly desedbed varients */
cgx transform key_comm.on( karnelblock *kb,
secretkey *bk,
czypto cntxt *blcek,
secretiCeY *tk,
unsigned short ktype,
tmsigned short klen,
imsigned short *patterns,
unsigned short oper,
unsigned short haig,
hash cnixt *hc,
ciypto cnbct *hkek);
Arguments:
kb->cb->cmd = CGX TRANSFORM KEY;
/* the BLACK root secret key */
kb->cb->argununt[Ol = (VPTR)bk;
/* the KCR KEK location to uncover the root BLACK key */
kb->cb->argument[1] = (VP'1'R)bkek;
/* storage for a new BLACK transformed secret key
kb->c:b->argument[21 =(VPTR)tk; /* see text above */
/* KCR ID number to place newly generated tcansformed secret key
kb->cb->argument[3] = (VPTR)destkey;
/* type of secret key to generate, use one of the following:
* CGX RC5_A, CGX DES_A, and CGX TRIPLE_DES A
kb->cb->argument[4] = (VPTR)ktyPe;
/* length of user secret key to generate, 40 to 168 bits */
/* specified in units of bytes, in 8-bit units (5 - 21) */
kb->cb->argument[5] = (VPTR)klen;
/* transform 64 byte data patterns */
kb->cb->argnment[6] = (VPTR)patterns;
/* the data pattern transform operation, XOR, APPEND, PREPEND
kb->cb->argun-ent[7l = (VPT'R)oper,
/* the HASH alg to use: CGX SHS_A, or CGY RID5_A
kb->cb->argument[8] = (VIrTR)hash alg:
/* the hash cntxt to return the pre-comp of HMAC key */
kb->cb->argument[9] = (VPTR)hc;
kb->cb->argument[10l = (VPTR)hkek; /* see text above */
194
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Status:
kb->sb->status = CGX SUCCESS_S,
CGX F~AII.,_S, and
CGX IIVVALID REG S
/* This variant is preswired only for backward compaaility. One of the next
three vanaats to be
described is iecommended for new developmcrt. This variant snpplies a NULL
hkek parameter to the
common function, thus requesting that any rctnrrned hash context (in hc) will
be red
cga transform key( kernelblock *kb,
secretkey *bk,
crypto_cntxt *bkek,
secretkey *tk,
unsigned short ktype,
unsigned short kien,
unsigned short *patterns,
unsigned short oper,
unsigaed short halg,
hash cntxt *hc)
This variant is defined as:
cgx transform key_common( (kb), (bk), (bkek), (tk), (ktype), (kien),
(patterns), (oper), (hash ai8), (hc), NUI.L)
/* variant: Transform a root secret key into a pre-wmputed HMAC .bash context
retiuned in the red*/
cgx transformprxompute key( kernelblock *kb,
secretkeY *bk,
ayptc catxt *bkek,
unsigned short f nal, /* close has context ff final TRUE */
unsigned short *patterns,
unsigned short oper,
imsigned short bash alg,
l~ash pitict *lic)
This variant is defined as:
cgx transform key_common( (kb), (bk), (bkek), NULL, NULL,
(final), (patterns), (oper), (hash alg), (hc), NULL)
195
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* vaaant: Traasform a root secret key into a biack key. */
cgx transform_gen key( kernelblock *kb,
secretkey *bk,
crypto_cntxt *bkek,
secretkey *tk,
unsigned short ktype,
unsigned short klen,
unsigned short *patteras,
unsigned short oper,
unsigned short hash alg)
This variant is defined as:
cgx transform key_common( (kb), (bk), (bkek), (tk), (ktype), (kien),
(patterns), (oper), (hash alg), NULL, NULL)
/* variant: Transform a root secret key into a pre-computed HMAC hash context
returned in the black*/
cgx transform_precomputed bkey( kernelblock *kb,
secretkey *bk,
crypto_cntxt *bkek,
unsigned short final,
unsigned short *pattems,
unsigned short oper,
unsigned short hash alg,
hashcntxt *hc,
crypto_cntxt *hkek);
This variant is defined as:
cgx transform_key_common( (kb), (bk), (bkek), NULL, NULL,
(final), (patterns), (oper), (hash alg), hc, hkek)
See Also: CGX HASH ENCRYPT or CGX HASH DECRYPT
196
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
EXPORT KEY (Export An IRE Secret Key)
Command Name: CGX EXPORT KEY
Command Description:
The Export Key command allows the application to move an
IRE secret key form into an external secret key form. The external
secret form must be covered either with a secret key or public key, this
is specified by the application via the command arguments.
The application must present a BLACK copy of the IRE secret
key to export along with the crypto_cntxt object to reference the KEK
or KKEK to uncover it. Also, the application must provide a buffer
(i.e. ebk) to copy the external secret key into that is converted from the
BLACK IItE secret key along with a crypto cntxt object referencing a
KEK to cover it or a publickey object to cover it with.
The IltE secret key to export must be an untrusted key, KKEK
or KEK. Furthermore, it must not reside (or covered by) under a
parent KEK that is trusted (i.e. LSV, GKEK, or trusted KEK or
KKEK). Moreover, the secure attributes stored in each of the IRE
BLACK secret keys are removed before the secret key is exported.
These bits are not used or would not be understood in other vendor's
crypto equipment. Therefore, the main purpose of this command is to
provide some sort of key interoperability between an IRE crypto device
and some other vendor's crypto equipment (software or hardware
based).
As part of the command the application is allowed to program
salt bits that will be prepended to the secret key bits of the external
secret key. When exporting a secret key under another secret key the
197
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
application has the choice of providing salt bits in multiples of 2 bytes,
requesting the secure Kernel generate salt bits in multiples of 2 bytes, or
not storing any salt bits. However, the total of salt bytes, data bytes,
and the key bytes must be a multiple of 8 bytes. When covering under a
public key it can request salt in multiples of 2 bytes and the total of salt,
data, and secret key only has to be a multiple of 2 bytes and less than
the modulus length; at least make sure its most significant bit is not set.
Also, the command allows the application to program data bits
that will be appended to the secret key bits of the external secret key.
When exporting a secret key under another secret key the application
has the choice of providing data bits in muitiples of 2 bytes, requesting
the secure Kemel generate data bits in multiples of 2 bytes, or not
storing any data bits. However, the total of salt bytes, data bytes, and
the key bytes must be a multiple of 8 bytes. When covering under a
public key it can request data in multiples of 2 bytes and the total of
salt, data, and secret key only has to be a multiple of 2 bytes.
The command does not store all keys in multiples of 8 bytes.
For example the HMAC and RC5 keys may not be exported out in an 8
byte multiple if its size is not of 8 byte multiples. However, DES and
Triple DES keys will always be exported in multiplies of 8 bytes.
Furthermore the secret key is flipped when exported, it is put into big
endian order.
All DES and Triple DES keys follow these storage rules. If the
key is less than or equal to 7 bytes in length then it is exported as 8
bytes, if the key is less than or equal to 14 bytes in length then it is
exported as 16 bytes, and if the key is less than or equal to 21 bytes in
length it is exported as 24 bytes. The expansion in key size is due to
the DES parity bits.
198
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
All RC5 keys follow these storage rules. If the key is odd size
in length an extra byte is added to make it a multiple of 2; the extra byte
is a 0. Otherwise, the RC5 key is exported out as is, its programmed
length. The zero is appended to key so that the 0 can be used by
Microsoft CAPI CSPs as a key delimiter.
All HMAC keys follow these storage rules. If the key is odd
size in length an extra byte is added to make it a multiple of 2; the extra
byte is a 0. Otherwise, the IHMAC key is exported out as is, its
programmed length. The zero is appended to key so that the 0 can be
used by Microsoft CAPI CSPs as a key delimiter.
If the argument, salt_len, is set to 0 the application requests that
no salt bits be prepended. If the argument, salt, is NULL it requests
that the secure Kernel generate salt len bytes; otherwise the application
is providing salt len bytes of salt.
If the argument, data len, is set to 0 the application requests
that no data bits be prepended. If the argument, data, is NLTLL it
requests that the secure Kernel generate data len bytes; otherwise the
application is providing data_len bytes of data.
If the publickey argument, pk, is NULL then the secret key to
export is covered with the KEK, ekek_cc. If pk is not NULL then the
secret key to export is covered with the public key pk object.
Command Interfaces:
/*export an IItE secret key under another untrusted secret key */
cgx export key( keinelblock *kb,
secretkey *bk,
crypto_cntxt *bkek cc.
unsigned short *ebk,
crypto_cntxt * ekek_cc,
unsigned short *salt,
unsigned short salt len,
199
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
unsigned short *data,
unsigned short data len)
Arguments:
kb->cb->cmd = CGX EXPORT KEY;
/* the BLACK IRE secret key to export
kb->cb->argument[O] = (VP'I'R)bk;
/* the KCR KEK location to uncover the BLACK IRE secret key 10 kb->cb-
>argument[1] = (VPTR)bkek cc;
/* the buffer to house the axternal secret key */
kb->cb->argument[2] - (VPTR)ebk,
/* the KCR KEK location to cover the RED exported IRE secret key
kb->cb->arBnment[3] = (VPTR)ekek cc;
/*salt bits to prepend to key bits */
kb->cb->arguntent[4] = (VPTR)salt;
/* the number of salt bits to prepend to the key bits
/* this must be in units of 2bytes */
kb->cb->argument[5] = (VPTR)salt_len;
/*data bits to prepend to key bits */
kb->cb->argament[6] = (VP'1Zt)data;
/* the number of data bits to prepend to the key bits */
/* this must be in units of 2bytes */
kb->cb->argnment[7] = (VPTR)data len;
/* pubkey key to cover with */
kb->cb->argament[8] = (VPTR)MJLL;
/*export an IItE secret key under a public key */
cgx_export_key( kernelblock *kb,
secretkey *bk,
crypto cntxt *bkek cc,
unsigned short *ebk,
publickey *pk,
unsigned short *salt,
unsigned short salt len,
unsigned short *data,
unsigned short data len)
Arguments:
kb->cb->cmd = CGX EXPORT KEY;
/* the BLACK IRE secret key to eaport */
kb->cb->argument[0] = (VPTR)bk;
/* the KCR KEK location to uncover the BLACK IRE secret key */
kb->cb->argument[l] = (VPTR)bkedc cc;
/* the buffer to house the external secret key */
kb->cb->argament[2] = (vPTR)obk;
/* the KCR KEK location to cover the RED exported IltE secret key */
kb->cb->argument[3] _ (VPTR)NULL;
200
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/*salt bits to picpend to key bits */
kb>cb->argnn,ent[a] _ (vPTR)satt;
/* the number of salt bits to prepend to the key bits
/* this must be in units of 2bytes */
kb->cb->argument[5] = (VPTR)salt len;
/*data bits to prepend to key bits */
kb->cb->argument[6] = (VPTR)dat$;
/* the number of data bits to prepend to the key bits
/* this must be in units of 2bytes */
kb->cb->argument[7] = (V'TR)data,_IM
/* pnbkey key to cover with */
kb->cb->argument[8] = (VPTR)pk;
Status:
kb->sb->status = CGX_SUCCESS_S, or
CGX INVALIDREG S
See Also: CGX_GEN KEY, CGX_DERIVE_KEY, CGX_LOAD_KEY, and
CGX I1viPORT KEY
IlViPORT KEY (Import An IRE Secret Key)
Command Name: CGX A1NiPORT KEY
Command Description:
The Import Key command allows the application to load an
IRE secret key form in externai secret key form into the secure kernel.
This command allows the application to import a key into the
specified key cache register. The application must present the external
form of the key to be imported, ibk, and specify the length of the salt
prepended to the key through the salt len parameter. The salt length is
assumed to be a multiple of 2 bytes, and can be 0 bytes. The
crypto_cntxt, ikek_cc, will be used to decrypt the salt (if present), key
and any additional padding.
The application controls the algorithm type, key_type, and
length of the key being imported. The application also specifies how
201
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
the key is to be used, e.g. encryption key or key encryption key.
However, the kernel makes no assumptions about the security of the
key being imported. Therefore, upon completion of the command, the
newly imported key is treated as an untrusted key.
The bk parameter can be used to request a covered version of
the key once it has been successfully imported. If bk is non-NULL, and
the import succeeds, the key will be covered under the crypto_cntxt
pointed to by kek cc and stored at the location specified by bk.
Command Interfaces:
/*import an IltE secret key */
cgx import key( kernelblock *kb,
secretkey *ibk,
UINT16 salt len,
crypto_cntxt *ikek cc,
kcr dest kcr,
LTIlVT 16 key_type,
IJINT 16 length,
LJINT 16 use,
secretkey *bk,
crypto_cntxt *kek cc)
Arguments:
kb->cb->cmd = CGX IIvlPORT KEY;
/* the secret key blob to import
kbacb->argument[0] _ (VPTR)ibk;
/* the length of the salt before the key matorial
kb->cb->argnment[1] _ (VPTR)salt len;
/* the KCR KEK location used to uncover the imported secret key
kb->cb->argument[2] = (VPTR)ikek cc;
/* the destination KCR location for storing the imported key */
kb->cb->arBument[3] = (VPTR)dest kcr
/* the algorithm type of key being imported */
lb->cb->argument[4] = (VPTR)key_type;
/* the KCR KEK location to cover the imported IRE seaet key */
kb->cb->argument[5l = (VIrTR)lengtb:,
/* how the imported key will be used in the key hierarchy
*(e.g. CGX KCR K)
kb->cb->argument[6] = (VP'!TZ)use;
/* location to store resulting covered secretkey (NULL=>ignore)
202
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
kb->cb->argument[7l = (VFTR)bk;
/* the KCR KEK location to cover the imported IItE secret key */
kl>a~umem[8] = (VPTR)kek cc',
Status:
kb->sb->status = CGX_SUCCES S_S,
CGX IIWALID_REG S,
CGXEMPTY REG S,
CGX_IIWALID LE1V S, or
CGX_FAII _S
See Also: CGX GEN KEY, CGX DERIVE KEY, CGX LOAD KEY, and
CGX_EXPORT_KEY
DESTROY KEY (Remove Secret Key From KCR)
Command Name: CGX DESTROY KEY
Command Description:
The Destroy Key command is used to remove a secret key from
one the specified key cache register.
Access to the secret keys is via key cache register IDs. The key
cache register IDs are numbered from 0 to N, there are N secret key
registers available to the application. Key cache register 0 is reserved
for the LSV and, therefore, cannot be destroyed. Therefore, the key
cache register available to the application range are from 1 to N.
If the KCR is already empty, the command will report back as
though it successfully removed the secret key from the KCR
Command Interface:
/* destray a secret key in either the F1.ASH or volatile KCR areas
csrx destrov key( kernelbiock *kb, kcr key )
Arguments:
kb->cb->cmd = CGX DESTROY_KEY;
203
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* the KCR ID to remove
kb->cb->argument[0] = (VPTR) key;
Status:
kb->sb->statas = CGX SUCCESS_S, or
CGX INVALID REG S/* KCR invaIid id
See Also: CGX LOAD KEY
LOAD KG (Load Secret Key Into HW/SW KG)
Command Name: CGX LOAD KG
Command Description:
The Load KG command is used to load DES/Triple DES secret
keys into the hardware key generator and RC5 keys into the RC5
software key generator. The typical use of this command is to fully
optimize secret key traffic. For example, loading the KG once and
using the static kernel block approach will speed the encryption process
because of fewer secret key context switches.
Prior to invoking the Load KG command, it is preferred if the
application sets up the crypto_cntxt block. The application is
responsible for setting the mode, setting the appropriate secret key
KCR ID, and for priming the iv buffer with an initial random number (if
this is the first time the crypto cntxt is loaded). After this the
application need not modify the crypto_cntxt block unless something
changes (i.e., secret key KCR ID location, and/or the iv to cause a
resynchronization).
The iv buffer of the crypto_cntxt block must be read- and write-
able; the iv buffer is used to maintain the feed-back register for the
CBC, CFB, and OFB modes. In the ECB mode the iv buffer is ignored.
204
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The secret key to be loaded as referenced via the crypto_cntxt
must have the key usage setting of CGX KCR K. This command only
allows traffic or data keys to be loaded or it will fail. The key usage
information is programmed by the application at the time a secret key
has been loaded, generated, derived, or negotiated and is maintained
securely by the secure Kernel. This means an LSV, GKEK, or KEK
type of secret key can not be loaded by this command.
If a KKEK (i.e. DES or Triple DES only) is loaded it is loaded
into the special hardware KKEK register to be used to externally
uncover application BLACK secret keys.
Command Interface:
/* load a single secret key into the SW/HW KG
cgx load kg( kemelblock *kb,
crypto_cntxt *cb,
unsigned short direction)
/* load multiple secret keys for triple DES into the HW KG
Arguments:
kb->cb->cmd = CGX LOAD KG;
/* pointer to the crypto_cntxt to load into the HW/SW KG */
kb->cb->argument[0] = (VPTR)cb;
// direction is used to specify the use of the KG,
// encrypt or decrypt. To specify the encrypt operation direction
// must be set to non-0, for decrypt then direction must be set
//to0
kb ->cb->argument[1] _ (vPTR)directiqn;
Status:
kb->sb->status = CGX SUCCESS_S,
CGX WEAK KEY S,
CGX_EMPTYREG_S, or
CGX IIWALID REG S
205
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
See Also: CGX ENCRYPT, CGX DECRYPT, CGX HASH ENCRYPT,
CGX HASH DECRYPT, or CGX STREAM
ENCRYPT (Encrypt Data)
Command Name: CGX ENCRYPT
Command Description:
The Encrypt command is used to perform symmetrical
encryption. The encrypt operation supports many secret key algorithms
(i.e., DES, Triple DES, and RC5) in any of the modes (i.e., ECB, CFB,
OFB, and CBC).
The Encrypt command only supports block encryption, a block
must be 64 bits long. The Encrypt command can handle as many
blocks as the application chooses to encrypt at one time. Furthermore,
an encrypted data session can extend beyond one call to the encryption
command; this is accomplished via a crypto_cntxt block (described
below).
The data buffers, datain (plain-text) and dataout (cipher-text),
can share the same address. Moreover, the chip currently only supports
cipher-block symmetrical algorithms but the encrypt interface provides
for the addition of a stream interface. It does this by defining datain
and dataout as unsigned. char pointers and the data length of datain to
be in bytes. Allowing the byte count makes the interface portable for
the later addition of stream based algorithms. However, if the
algorithm to be used in the encrypt operation is cipher-block based the
byte count must be evenly divisible by 8, any fragments are ignored by
the operation.
206
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Prior to invoking the encryption command the application must
setup the crypto_cntxt block. The application is responsible for setting
the mode, masking in one of the special key load options (described
below), setting the appropriate secret key KCR ID, and for priming the
iv buffer with an initial random number (only for the first call). After
this the application need not modify the crypto_cntxt block unless
something changes (i.e., secret key KCR ID location, algorithm, and/or
the iv to cause a resynchronization).
The KCR key specified in the crypto_cntxt contains the
algorithm to use as part of the secret key object stored in the specified
KCR location. This secret key type specifies the secret key algorithm
to use.
The iv buffer of the crypto cntxt block must be read and
writeable; the iv buffer is used to maintain the feed-back register for the
CBC, CFB, and OFB modes. In the ECB mode the iv buffer is ignored.
The Encrypt command allows the application to mask in one of
the special algorithm and mode control bits defined in section 0, into
the algorithm field of the crypto_cntxt block. The control bits are used
by the secure Kernel to determine how to load secret keys before the
actual encryption of the plain-text takes place. The control bits allow
the application to request one of these options: auto-load, force-load,
or no-load. Auto-load allows the secure Kernel to check which key is
currently loaded into the KG, if it's the same as the key specified for the
encryption command it is not loaded; otherwise the key is loaded.
Force-load tells the secure Kernel to always load the key. No-load tells
the secure Kernel to not load the key; more than tikely the application
207
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
has already loaded the key (maybe via the CGX LOAD KG
command). By default, auto-load is assumed.
The secret key to be loaded as referenced via the crypto_antxt
must have the key usage setting of CGX KCR K. This command only
allows traffic or data keys to be loaded or it will faiL The key usage
information is programmed by the application at the time a secret key
has been loaded, generated, derived, or negotiated and is maintained
securely by the secure Kernel. This means an LSV, GKEK, or KEK
type of secret key can not be loaded by this command.
When using the CFB or OFB modes the application can signal
the start of secure traffic or resynchronize it by setting the
CGX RESYNC_C control bit. This will signal the CGX ENCRYPT
command to first encrypt the application's N before encrypting the
input data. This command does not clear the bit so upon return the
application should clear the CGX RESYNC C bit before invoking the
command again or the IV resynchronization will occur again.
Command Interface:
cgx_encrypt( kemeIblock *kb,
unsigned short datain_,page,
unsigned char *datain,
unsigned short dataout_page,
unsigned char *dataout,
unsigned byte cnt,
crypto_cntxt *cb)
Arguments:
kb->cb->cmd = CGX ENCRYPT;
/* mode seleatioe,
* mask one of the special algorithm
* control bits with the mode here via the crypto_cntxt block
kb-xb->arSument[0] = (VPTR)cb;
/* data block(s) to be encrypted data page, only needed */
208
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* for the ADI 2181 platform, all other platform igaore it
kb-xb->argument[1] _ (vPTR)aatain_pagc;
/* data block(s) to be eacrypted */
kb->cb->argumcnt[2] = (VPTR)datain;
/* specified in units of bytes, in the current case all the
/* algorithms use 64 bit blocks so the value of byte cnt must
/* be evenly divisi'ble by 8, any fragments are ignored */
kb->cb->argament[3] = (VP'IR)byte_cnt:
/* data block(s) to be encrypted data page, only needed
*/
/* for the ADI 2181 platform, all other platform ignore it
lcb->cb->argoment[4] = (VPTR)dataout_page;
/* ontpM the encrypted data blocks */
kbacb->argument[5] = (vPTR)dataout;
Status:
kb->sb->status = CGX SUCCESS_S,
CGX WEAK KEY S,
CGX EMPTY REG S, or
CGX_INVALID_REG S
See Also: CGX LOAD KG and CGX DECRYPT
- -
209
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
DECRYPT (Decrypt Data)
Command Name: CGX DECRYPT
Command Description:
The Decrypt comniand is used to perform symmetrical
decryption. The decrypt operation supports many secret key algorithms
(i.e., DES, Triple DES, and RC5) in any of the modes (i.e., ECB, CFB,
OFB, and CBC).
The Decrypt command only supports block decryption, a block
must be 64 bits long. The Decrypt command can handle as many
blocks as the application chooses to decrypt at one time. Furthermore, a
decrypted data session can extend beyond one call to the decryption
command; this is accomplished via a crypto_cntxt block (described
below).
The data buffers, datain (plain-text) and dataout (cipher-text),
can share the same address. Moreover, the chip currently only supports
cipher-block symmetrical algorithms but the decrypt interface provides
for the addition of a stream interface. It does this by defining datain
and dataout as unsigned char pointers and the data length of datain to
be in bytes. Allowing the byte count makes the interface portable for
the later addition of stream based algorithms. However, if the
algorithm to be used in the decrypt operation is cipher-block based the
byte count must be evenly divisible by 8, any fragments are ignored by
the operation.
Prior to invoking the Decrypt command the application must
setup the crypto_cntxt block. The application is responsible for setting
the mode, masking in one of the special key load options (described
below), setting the appropriate secret key KCR ID, and for priming the
210
CA 02303297 2000-03-13
WO 99/14881 PCT/[1S98/19316
iv buffer with an initial random number (only for the first call). After
this the application need not modify the crypto cntxt block unless
something changes (i.e., secret key KCR II) location, algorithm, and/or
the iv to cause a resynchronization).
The KCR key specified in the crypto_cntxt contains the algorithm to
use as part of the secret key object stored in the specified KCR
location. This secret key type specifies the secret key algorithm to use.
The iv buffer of the crypto_cntxt block must be read and
writeable; the iv buffer is used to maintain the feed-back register for the
CBC, CFB, and OFB modes. In the ECB mode the iv buffer is ignored.
The Decrypt command allows the application to mask in one of
the special algorithm and mode control bits defined in section 0, into
the algorithm field of the crypto cntxt block. The control bits are used
by the secure Kernel to determine how to load secret keys before the
actual encryption of the plain-text takes place. The control bits allow
the application to request one of these options: auto-load, force-load,
or no-load. Auto-load allows the secure Kernel to check which key is
currently loaded into the KG, if its the same as the key specified for the
encryption command it is not loaded; otherwise the key is loaded.
Force-load tells the secure Kernel to always load the key. No-load tells
the secure Kernel to not load the key; more than likely the application
has already loaded the key (maybe via the CGX LOAD KG
command). By default, auto-load is assumed.
The secret key to be loaded as referenced via the crypto_cntm
must have the key usage setting of CGX KCR K. This command only
allows traffic or data keys to be loaded or it wiII fail. The key usage
information is programmed by the application at the time a secret key
211
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
has been loaded, generated, derived, or negotiated and is maintained
securely by the secure Kernel. This means an LSV, GKEK, or KEK
type of secret key can not be loaded by this command.
When using the CFB or OFB modes the application can signal
the start of secure traffic or resynchronize it by setting the
CGX RESYNC_C control bit. This will signal the CGX DECRYPT
command to first encrypt the application's N before decrypting the
input data. This command does not clear the bit so upon return the
application should clear the CGX RESYNC_C bit before invoking the
command again or the IV resynchronization will occur again.
Command Interface:
cgx decrypt( kernelblock *kb,
unsigned short datain_page,
unsigned short *datain,
unsigned short dataout_page,
unsigned short *dataout,
unsigned byte_cnt,
crypto_cntxt *cb)
Arguments:
kb->cb->cmd = CGX DECItYPT;
/* mode selection,
* mask one of the apectiai algorithm
* control bits with the mode here via the crypto_cntaet block
kb->cb->argument[Ol = (VPTR)cb;
/* data block(s) to be decrypted data page, only needed
/* for the ADI 2181 platform, all other platform ignore it
kb->cb->argammt[Il = (VP'TR)datain_page;
/* data block{s) to be decxypted */
Icb->cb->argument[2] = (vPTR)datain;
/* specified in units of blocks, in the current case all the */
/* algorithms use 64 bit blocks so the vahie of byte cat must
/* be evenly divisible by 8, any fragments are ignored
kb-'*cb->azgnment[3] = (VPTZt)byte len;
/* data block(s) to be deciypted data page, only needed */
/* for the ADI 2181 platform, all other platform ignore it
kb->cb->argament[4] = (VPTR)dataout_page;
21 2-
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* outpud the deaypted data blocks
*/
kb->cb->argument[5] = (VPTR)dataoui;
Status:
kb->sb->status = CGX_SUCCESS_S,
CGX WEAK KEY S,
CGX_EMPTY REG S, or
CGX INVALID REG S
See Also: CGX LOAD KG and CGX ENCRYPT
Public Key Commands
GEN PUBKEY (Generate a Public Keyset)
Command Name: CGX GEN PUBKEY
Command Description:
This operation will generate an entire public keyset comprised
of the modulus, private, and public blocks. This operation can create
public keysets for severr.l pubfic key algorithms. It currently supports:
Diffie-Hellman, RSA, and DSA public keys. The retumed keyset will
consist of data stored in little endian order.
The newly generated public keyset is returned to the application
via the publickey parameter. The modulus and public key are returned
in the RED form while the private key is returned in the BLACK form
covered by the specified secret key. The crypto_cntxt parameter is
used for this purpose. The application can invoke other public key
commands operating on the newly created public key by passing it as a
parameter to the desired operation.
All public keysets are returned to the application in a packed
form. Packed keys are defined as key structures in which the least
213
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
sigaificant byte of the next public key structure member abuts the most
significant byte of the current member. In this way, fragmentation
within data structures is minimized and portabil'ity of data is enhanced.
Depending on the type of key being generated, some specific key
generation parameters may be required. The sixth element of the kernel
block's parameter area is used for this purpose:
= For DSA keys, the application may specify a seed key to be used for
prime number generation. The seed key consists of a 16-bit counter
and a 160-bit seed value. If no seed is specified (i.e., NULL is
passed as this parameter), then the kernel will generate its own seed
key. If a seed key is presented, the operation may fail if it cannot
generate a prime from the seed. If so, the application should
continue re-seeding the seed value and retrying until the operation
succeeds. Upon success, the kernel will set the 16-bit counter.
This command is responsible for generating the random numbers
and prime numbers to create the vectors for the public keyset.
Furthermore, the command is responsible for executing the primality
test specified by Rabin-Miller to accept/reject prime numbers. In all
cases, the application is responsible for specifying the number of Rabin-
Miller tests to perform. This allows the application to trade the
strength of the generated prime numbers against the amount of time
required to generate the primes.
The method parameter is a bit-mask controlling: 1) the type of
prime numbers to generate, either weak or strong, and 2) how to search
for prime numbers, either randomly (i.e. choosing a new random
number for each prime number candidate) or sequentially from a
random base (i.e. choose a random base and continue sequentially for
each prime number candidate).
214
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
This command can be preempted by any command with the
exception of the other public key commands.
Command Interface:
/* generate a Diffie-Hellman Public Keyset
cgx_gen dhpubkey(kemelblock *kb,
unsigned short moduhis len,
unsigned short tests,
unsigned short method,
publickey *pk,
crypto cntxt *cc)
/* generate a RSA Public Keyset
cgx_gen rsa_pubkey(kernelblock *kb,
unsigned short modulus_len,
unsigned short base,
unsigned short tests,
unsigned short method,
publickey *pk,
crypto_cntxt *cc)
1* generate a DSA Public Keyset
cgx_,gen dsa_pubkey(kernelblock *kb,
unsigned short modulus len,
unsigned short tests,
unsigned short method,
seedkey *sk,
publickey *pk,
crypto_cntxt *cc)
Arguments:
kb->cb->cmd = CGX GEN PUBKEY;
cgx_gen dh. Pubkey(k, modulos_len, tests, method, Pk, cc)
/* a pointer to the public key to work with
kb,'cb-'argument[01 = (VPTTZ)pk;
/* a pointer to the public key's ciypto_cavct. (for pm+ate
* poriion)
kb->cb-'ar8ument[l1 = (VPTR)cc;
/* specify the public keyset to generate */
kb->cb->argument[2] = (VPTR)CGX DH A.;
/* the length of the modulus key to generate, between 512 and
* 2048 bits in increments of 64 bits, specify in units of bits
215
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
kb->cb->argument[3] _ (vP'ITt) modatusL1en;
/* the number of Rabin-Miller Pamality Tests to perfoim */
lcb->cb->argumenc[41 = (VPTR)te.sts;
/* the methods for generating prime numbers 5 kb->eb->argument[5] =
('/pTR)method;
cgx_gen rsa_pubkoy(k, modatns len, base, tests, method, pk, cc)
/* a poinRer to the public key to work with
kb ->cb->arBument[Ol = (VP7'R)pk;
/* a pointer to the public key's crypto_catxt (for private
s pottion)
kb->cb->argament[I] = (VPTR)cc;
/* specify the public keyset to generate
kb->cb->argnment[2] = (VPTR)CGX RSA M;
/* the length of the modulus key to generate, between 512 and
* 2048 bits in increments of 64 bits, speoify in units of bits
lcba~ument[3] _ (VP'IR) modulos_len;
/* the number of Rabin-Miller Primality Tests to pcrform
kb->cb->argument[4] = (VPTR)tests;
/* the methods for generating prime numbers */
kb->cb->argument[5] _ (VPTR)mothod;
/* the sixth parameter holds the starting point for the publfc
* exponentsearch.
kb->cb->argument[6] = (VPTR) base;
cgx_gen dsa_pubkey(k, modulus len, tests, method, sk, pk, cc)
/* a pointer to the pnblic kay to work with
kb->cb->argnment[0] = (VPTR)pk;
/* a pointer to the public key's crypto cntxt (for private
* portion)
kb->cb->argument[ll = (VPTR)cc;
/* specify the pablic keyset to generate
kb->cb->argument[2] = (VPTR)CGX DSA M;
/* the length of the modulus key to generate, between 512 and
* 2048 bits in increments of 64 bits, specify in units of bits
kb->cb->argninent[3] = (VPTR) modnlus len;
/* the number of Rabia-Miller Primalfty Tests to perform */
kb->cb->argument[4] = (VPTR)tests;
/* the methods for generating prime numbers
kb->eb->argnwent[5] = (Vl'T'R)method;
/* a pointer to the seed key */
kb->cb->argnment[6] = (VPTR) NULL;
Status:
kb->sb->status = CGX SUCCESS_S,
216
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
CGX BAD MODE S, /* invalid type requested
*/
CGX INVALID LEN S, or /* invaiid modulns or private
* length used
CGX FAII._S /* failurc during specific key
* generation opcration
See Also: CGX GEN NEWPUBKEY, CGX_PUBKEY_ENCRYPT,
CGX PUBKEY DECRYPT
GEN NEWPUBKEY (Generate Part of A Public Keyset)
Command Name: CGX GEN NEWPUBKEY
Command Description:
The Generate New public key operation is used to generate new
pubGc and private blocks for a Diffie-Hellman or DSA public keyset.
This command is only valid for Diffie-Hellman or DSA public keysets.
The command allows the flexibility to import a modulus block
from the application and use it to generate the new private and public
blocks. Furthermore, the application has control over which parts to
generate and return via the two control constants CGX X V(i.e. the
private part) and CGX Y V(i.e. the public part). Using combinations
of these control masks allows the application with a flexible key
generation interface. The following uses of the masks are permissible:
= CGXXV
generates and returns a new private part, no public part
is returned.
= CGX Y V
217
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
generates and returns a new public part, no public part
is returned. A private member must be passed in to
create the new public part.
= CGX X VI CGX Y V
generates and returns a new private/public part, both
parts are returned.
Once generated, the public key is returned to the application for
use with subsequent public key commands. The modulus and public
portions of the key are returned in the RED while the private portion of
the key is returned in the BLACK, reflecting the sensitivity of the
private data. As with all public key commands, this operation will
generate key components which are stored in little endian order and are
stored "packed".
For Diffie-Hellman keys, this operation provides the application
with the ability to substitute its own value for the generator, eg. When a
Diffie-HeIlman key is generated, the value 2 is used for the generator.
Typically, this command is used to generate new public and
private keys reusing the publicly shared modulus vectors so that a new
secret keys can be derived. For Diffie-Hellman keys, the application
can foilow this command with the CGX GEN NEGKEY to generate
the derived secret key from the receiver's public key.
For DSA keys, this operation can be followed by the
CGX SIGN and CGX VERIFY operations using the newly generated
DSA keyset.
218
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
This command can be preempted by any command which is not
a public key command.
Command Interface:
/* modify the public and private vectors of a Diffie-Hellman or DSA Public
Keyset
cgx_gen newpubkey(kernelblock *kb,
publickey *moduius,
crypto cntxt *cc,
unsigned short key_gen)
Arguments:
kb->cb->cmd ~ CGX GEN NEWPUBKEY;
/* modulus must point to either a Diffie-Hellman or DSA keyset.
/* the kernel will load the modulus portion of the key and use
/* it to create the new private and public poraons of the
/* keyset. For Diffie-Hellman keys, the length member of the
/* private portion of the key will be used when generating the */
/* private portion of the key.
kb->cb->argument[O] = (VP'TR.) modulus;
/* the crypto cntxt to use when covering the newly generated */
/* private pordon of the keyset. */
kb->cb>argument[1l = (VPTR) cc;
/* specifies which key parts to return: CGX X V and/or CGX Y V
kb->cb->argument[2] = (VPTR) key..Ben;
Status:
kb->sb->status = CGX SUCCESS_S,
CGX BAD_KEYSET S, /* keyset contains NULL data
C.rX INVALID LEN_S, /* invalid mod/priv len used
*/
CGX FAII,_S, or /* invalid keyset type (RSA) or
* error during key generation
CGX BAD MODE S, /* unrecognized keyset type
See Also: CGX_GEN_PUBKEY, CGX_GEN_NEGKEY, CGX_SIGN, and
CGX VERIIFY
GEN NEGKEY (Generate the DH Derived Secret Key)
Command Name: CGX GEN NEGKEY
GEN NEGKEY GXY
219
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
(Cover and return the DH Derived Secret Key, (g~z)~y)
Command Name: CGX GEN NEGKEY GXY
Command Descriptions:
These operations will complete the Diffie Hellman exchange by
deriving the shared secret key from the receiver's public key. The
CryptIC supports dynamically negotiated keys as specified in the X9.42
Standard. Currently, the MQV 1 and 2 protocols are not supported.
This command is only used for Diffie-Hellman public keysets.
To calculate the derived secret key the application must import
the receiver's public key vector using the publickey definition. For the
received public key, the application only needs to populate the public
key field and algorithm type of the publickey. For the local private key,
both the modulus and private keys are required. Because the private
portion of the locally stored key is used, the crypto cntxt which was
used to cover the key must be presented as a parameter also. The
secure kernel uses the imported public key to derive g"'' .
The conmmands CGX GEN NEGKEY and
CGX GEN NEGKEY GXY differ in what they do with the derived
Diffie-Hellman shared secret key, C.
The command CGX GEN NEGKEY truncates the shared
secret key into a secret key of the desired length. The imported public
key is discarded after the command completes. If for some reason the
application needs to regenerate the derived secret key, it must reload
the other parties' public key.
The application calling command CGX GEN NEGKEY must
provide a destination key cache register to receive the derived secret
220
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
key and a destination black secret key and a KEKcc (a crypto context.)
Furthermore, the application must specify the size of the derived secret
key. The size can be specified as: 32-168 bits in length, specified in
units of bytes (8 bits). The secret key will be created from the least
significant bits of the shared secret. By definition, secret keys created
via this command are untrusted keys. The secret key can be either a
key encryption key (KEK or KKEK) or a data encryption key (K). The
KEKcc designates a kcr holding an encryption key and also supplies an
initialization vector, which, using the kcr, is used to cover the derived
private key. The covered (black) key is then returned to the calling
application via the argument supplied.
The command CGX GEN NEGKEY GXY returns a covered
(black) version of the shared secret key. The application calling
command CGX GEN NEGKEY GXY must provide a destination
public key and a KEKcc (a crypto context.) The KEKcc must
designate a key cache register ID(kcr) to cover the shared key. The
KEKcc supplies the initialization vector, which, using the kcr, is used to
cover the shared secret key, e'' . The covered key is then returned to
the calling application via the argument supplied. Only the privatekey
member of the destination public key is populated; the calling
application must ensure that the privatekey member of the destination
public key has sufficient memory to receive the covered private key,
viz., local public key's modulus size plus 8 bytes. The returned covered
key may be used subsequently as input to the command
CGX PRF GXY or other CGX commands which facilitate IPSec
operations.
Both commands can be preempted by any command which is
not a public key command.
221
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Command Interface:
/* derive a secret key using the Diffie4lellman algorithm and public keysct
cgx negkey(kernelblock *kb,
publickey *1ocalpk,
crypto cntxt *ikek cc,
publickey *remotepk,
kcr destkcr,
UINT 16 type,
UINT16 len,
LJINT 16 use,
secretkey *bk,
crypto_cntxt *bkek cc)
Arguments:
kb->cb->cmd = CGX GEN NEGKEY;
/* a pointer to the publickey used to house the local public */
/* key. The modulus and private key fields are used to derive */
/* the shared secret. */
kb->cb->argument[O] = (VPTR)locatpk;
/* a pointer to the crypto aavct which will be used to uncover
/* the private portion of the local public key.
kb,>cb->argument[1] _ (VPTR)lkek cc;
/* a pointer to the publickey where the receiver's public key
/* is stored. The receiver's public key is used to derive */
/* a secret key. All other fields except the pubkey member of */
/* the publickey are ignored. */
kb->cb->argument[2] = (VPTR)remotepk;
/* destination KCR ID for newly derived secret key */
kb->cb->argnment[3] = (VPTR)destkcr;
/* the algorithm type of the secret key which will be derived */
kb->cb->argument[4] = (VPTR)type;
/* the length of the secret key which will be derived. The
/* length indicates how many bits to use for the secret key,
/* ranging from 32-168 bits (expressed in units of bytes). */
kb->cb->argument[5j = (VPTR)len;
/* how this key will be used. By definition, the key will be
/* untrusted, but the application must identify this as either
/* a key encryption key (KEK) or a data encryption key (K).
kb->cb->argument[6] = (VPTR)use;
/* pointer to storage for the black version of the generated
/* key. A NULL value for this pazameter will cause a"dangling"
/* key to be generated in a kcr within the key hierarchy. */
kb-?cb->argument[7] = (VPTR)bk;
/* the crypto cntxt used to cover the black version of the key. */
kb->cb->argument[8] = (VPTR)bkek_cc;
kb->cb->argument[9] ffi (VPTR)MJLL;
Statoa:
222
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
kb->sb->status = CGX SUCCESS_S,
CGX BAD KEYSET S, /* either local or remate
/* publickey is not a DH key */
CGX INVALID KEY LEN S, /* invalid secret key len */
CGX_WEAK KEY_S, /* remote public key was +/-1
CGX FAII,_S, or /* use or type not provided */
CGX IIVVALIDREG S, /* invalid destkcr or bkek_cc
/* kcr
Command Interface:
/* derive a secret key using the Diffie-Heilinan algorithm and public keyset
cgx negkey_gxy(k.ernedblock *kb,
publickey *localpk,
crypto_cntxt *lkek cc,
publickey *remotepk,
publickey *gxy,
crypto_cntxt *gyx kek cc)
Arguments:
kb->cb->cmd = CGX GEN NEGKEIr;
/* a pointer to the publickey used to house the local public */
/* key. The modulus and private key fields are used to derive */
1* the shared secret. */
kb->cb->argument[O] = (VPTR)localpk;
/* a pointer to the crypto_cntact which will be used to uncover
/* the private portion of the local public key.
kbacb->argument[l] = (VPTR)lkek_cc;
/* a pointer to the publickey where the receiver's public key
/* is stored. The receiver's public key is used to derive */
/* a secret key. All other fields except the pubkey member of */
/* the publickey are ignored. */
kb->cb->argument[2] = (Vl'TR)remotepk;
kb->cb->argument[7] = (VPTR)NULL;
/* ptr to returaed covered public key suncture */
/* the crypto cntxt used to cover the black version of the key. */
kb->cb->argument[8l = (Vi''TR)gx3! kek cc;
kb->cb->arg-m-ent[9] = (VP'I'R)gXY
Status:
kb->sb->status = CGX SUCCESS S,
CGX BAD_KEYSET S, /* either local or remote
/* publickey is not a DH key */
CGX IIVVALIDKEY LEN_S, /* invalid secret key len */
CGX WEAK KEY S, /* remote public key was +/-1
CGXFAII._S, or /* use or type not provided */
CGX_INVALID_REG_S, /* invalid destkcr or bkek cc
/* kcr
223
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
See Also: CGX_PRF GXY, CGX GEN PUBKEY and
CGX. GEN_+NEWPUBKEY
PUBKEY ENCRYPT (Encrypt Data Using RSA Public Key)
Command Name: CGX PUBKEY ENCRYPT
Command Description:
The Public Key Encrypt command is used to encrypt the
application's data using the RSA encryption algorithm. This operation
implements encryption or the RSA signature operation using the
pubkey member of a publickey structure. Control over which operation
is performed lies with the application. If the private key member if
NULL, RSA encryption occurs. If the public key is NULL, an RSA
signature is generated. The public keyset member of the RSA
publickey structure must be present for either of these operations to
occur.
The input data buffer, datain, must be a multiple of the length of
public keyset's modulus. Also, the value of the message must not
exceed the value of the modulus. (The message to be encrypted, like the
public keyset components, is stored in little endian order.)
Furthermore, the output buffer, dataout, must be at least as large as the
input buffer. Data from the datain buffer will be encrypted in blocks
equal to the size of the modulus and stored at the same relative offset in
the dataout buffer. This implies that the encryption algorithm will break
the input message into chunks of modulus length size and process each
chunk until the input is consumed.
224
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
If the output buffer isn't the same size as the input buffer, the
application takes the chance of the operation failing if the result of the
encryption can overflow the size of the output data buffer.
Command Interface:
/*encrypt the application's data using the RSA public kayset
cgx_pubkey_enciypt(kernelblock *kb,
publickey *pk,
crypto cntxt *pkek cc,
UINT 16 dataoutpg,
BYTE *dataout,
LJINTI6 datainpg,
BYTE *datain,
UINT16 len)
Arguments:
kb->cb->cmd = CGX PUBKEY ENCRYPT;
/* a pointer to the public keyset to use for the encryption
/* operation. If the pkek cc is NULL, the public portion of
/* the keyset will be used for this operation. If the pkek cc
/* is not NULL, the private exponent will be used for encrypiion
bk->cb->argument[0] _ (VP'TR)(pk);
/* a pointer to the crypto context used to cover the private /* portion of the
public keyset */
bk->cb->argument[1] = (VPTR)(pkek cc);
/* data page of output data buffer store the cipher-text */
bk->cb->argument(2] = (VPTR)(dpg);
/* output data buffer to store cipher-text of the message
bk->cb->argument[3] = (VPTR)(dp);
/* data page of input data buffer to be encrypted
bk,>cb->argument(4] = (VPTR)(sdp);
/* input data buffer to be encrypted */
bkacb->argument(5] _ (VPTR)(sp);
/* the length of the data to encrypt. The buffer length must be */
/* a multiple of the modulus size. In addition, the output */
/* buffer length should be at least as large as the input buffer */
bk->cb->argument[6] = (VPTR)(len);
Status:
kb->sb->status = CGX SUCCESS_S,
CGX BAD_KEYSET S, /* both privkey and pnbkey
* present
CGX INVALID _LEN S, /* invalid length specified
CGX BAD_KEYSET S, /* keyset nat an RSA keyset
CGX BAD MODULUS_S, or /* message > modulus */
225
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
CGX FAIL,_S /* zero modulus See Also: CGX GEN PUBKEY, CGX PUBKEY DECRYPT
PUBKEY DECRYPT (Decrypt Data Using RSA Public Key)
Command Name: CGX PUBKEY DECRYPT
Command Description:
The Public Key Decrypt command is used to decrypt the
application's data using the RSA decryption algorithm, or to verify an
RSA signature. Control over which operation is performed lies with
the application. If the public key member of the key is NULL, an RSA
decryption will be performed. If the private key member of the structure
is NULL, a signature verification wiIl be performed. The public keyset
must be provided by the application and contain the private key portion
of the keyset in order for this command to complete.
The size of the input data buffer, datain, must be a multiple of
the public keyset's modulus size. Furthermore, the output buffer,
dataout, must have a length greater than or equal to the size of the
input buffer. The input buffer will be decrypted in chunks equal to the
size of the modulus, until the input buffer is consumed. The output
message will be written into the dataout buffer at the same relative
offset as the input buffer.
If the output buffer size isn't at least as large as the input buffer,
the application takes the chance of the operation failing if the result of
the decryption can overflow the size of the output data buffer:
Command Interface:
/*decrypt the application's data using the RSA public koyset
cgx_pubkey_decrypt(kernelblock *kb,
publickey *pk,
crypto_cntxt *pkek cc,
226
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
UINT 16 dataoutpg,
BYTE *dataout,
UINT16 datainpg,
BYTE *datain,
UINT16 len)
Arguments:
kb->cb->cmd = CGX PUBKEY_DECRYPT;
/* a pointer to the public keyset to use for the decryption */
/* operation. If the pkek cc is NULL, the public portion of */
/* the keyset will be used for this operation. If the pkek cc
/* is not NULL, the private exponent will be used for decryption
bk->cb->argument[0] = (VPTtt)(pk);
/* a pointer to the crqpto context used to cover the private
/* portion of the public keyset */
bk->cb->argument[i] = (VPTR)(pkek_cc);
/* data page of output data buffer store the plain-text */
bk->cb->argument[21 = (VPTR)(dpg);
/* ontput data buffer to store plain-text of the message
bk->cb->argnment[3] = (VPTR)(dp);
/* data page of input data buffer to be decrypted */
bk->cb->arg~ment[4] = (VPTR)(sdP);
/* input data buffer to be decrypted */
bk->cb->argunment[5] _ (VPTR)(sp);
/* the length of the data to decrypt. The buffer length must be */
/* a multiple of the modulus size. In addition, the output */
/* buffer length should be at least as large as the input buffer */
bk->cb->argument[6] = (VPTR)(len);
Status:
kb->sb->status = CGX SUCCESS S,
CGX_BAD OUTPUT, /* output buffer too small */
CGX BAD_INPUT, or /* input buffer too large
CGX BAD_KEYSET S/* empty key RAM */
See Also: CGX GEN PUBKEY and CGX ENCRYPT PUBKEY
227
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
EXPORT PUBKEY (Export An IRE Public Key)
Command Name: CGX EXPORT PUBKEY
Command Description:
The Export Pubkey command allows the application to move an
IRE public key form into an external public key form. The external
public form must be covered with a secret key, this is specified by the
application via the command arguments.
The application must present a BLACK copy of the IRE public
key to export along with the crypto_cntxt object to reference the KEK
to uncover it. Also, the application must provide a buffer (i.e. ebk) to
copy the external public key into that is converted from the BLACK
IRE public key along with the publickey object. Furthermore, the
exported public key can be covered by an untrusted key (i.e. K) or a
KEK.
The IRE public key to export must not reside (or covered by)
under a parent KEK that is trusted (i.e. LSV, GKEK, or trusted KEK).
The main purpose of this command is to provide some sort of key
interoperability between an IRE crypto device and some other vendor's
crypto equipment (software or hardware based).
The public key to export is passed in via the argument, pk, the
publickey object. The privkey, type and length members must be
present in order to export the public key. Therefore, the private key is
the only portion of the public keyset that is exported. The application
can move the public and modulus portion itself.
As part of the command the application is allowed to program
salt bits that will be prepended to the private key bits of the external
228
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
public key. When exporting a private key under a secret key the
application has the choice of providing salt bits in multiples of 2 bytes,
requesting the secure Kernel generate salt bits in multiples of 2 bytes, or
not storing any salt bits. However, the total of salt bytes, data bytes,
and the private key bytes must be a multiple of 8 bytes.
Also, the command allows the application to program data bits
that will be appended to the private key bits of the external secret key.
When exporting a private key under a secret key the application has the
choice of providing data bits in multiples of 2 bytes, requesting the
secure Kernel generate data bits in multiples of 2 bytes, or not storing
any data bits. However, the total of salt bytes, data bytes, and the key
bytes must be a multiple of 8 bytes.
If the argument, salt len, is set to 0 the application requests that
no salt bits be prepended. If the argument, salt, is NULL it requests
that the secure Kernel generate salt len bytes; otherwise the application
is providing salt len bytes of salt.
If the argument, data len, is set to 0 the application requests
that no data bits be prepended. If the argument, data, is NULL it
requests that the secure Kernel generate data len bytes; otherwise the
application is providing data len bytes of data.
Command Interfaces:
/*export an IRE private key under an untrusted secret key KEK
cgx_export_pubkey( kernelblock *kb,
publickey *pk,
crypto_cntxt *pkek cc,
unsigned short *ebk,
crypto_cntxt *ekek cc,
unsigned short *salt,
unsigned short salt len,
unsigned short *data,
229
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
unsigned short data len)
Arguments:
kb->cb-Ncmd = CGX EXPORT PUBKEY;
/* the BLACK IRE private key to cxport
kb->cb->arBument[O] = (VPTR)pk;
/* the KCR KEK location to uncover the BLACK IRE private key
kb->cb->argument[ll = (VPTR)pkak ca;
/* the buffer to house the external private key */
kbacb->argnment[2) = (VPTR)ebk;
/* the KCR K or KEK location to cover the IRE private key */
kb->cb->argumant[3] = (VPTR)ek.ek cc;
/*salt bits to prepend to key bits */
kbacb->argument[4l = (VPTR)salt;
/* the number of salt bits to prepend to the key bits */
/* this must be in units of 2bytes */
kb->cb->argument[5l -i (VPTR)salt_1en;
/*data bits to prcpend to kry bits */
kb->cb->argument[6l = (VPTR)data;
/* the number of data bits to prepend to the key bits
/* this must be in units of 2bytes */
kb->cb->argnment[7] = (VPTR)data leq
Status:
kb->sb->status = CGX SUCCESS_S, or
CGX IIWALID REG S
See Also: CGX_GEN PUBKEY, CGX GEN_NEWPUBKEY, and
CGX IlVIPORT PUBKEY
IIVIPORT PUBKEY (Import An IRE Public Key)
Command Name: CGX IlVIPORT PUBKEY
Command Description:
The Import Pubkey command allows the application to move an
externa[ public key form into an IRE internal form. The external public
form must be covered with a secret key, this is specified by the
application via the command arguments. The main purpose of this
command is to provide some sort of key interoperability between an
230
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
IRE crypto device and some other vendor's crypto equipment
(software or hardware based).
The application must present a BLACK copy of the external
public key via the ibuf argument to import along with the crypto_cntxt
object to reference the untrusted K or KEK to uncover it, an untrusted
secret key. Also, the application must provide a public key object (i.e.
pk) to convert the external pubIic key buffer, ibut into an internal IItE
public key form.
The external public key to import can not reside (or covered by)
under a parent KEK that is trusted (i.e. LSV, GKEK, or trusted KEK).
When it was exported it must have been under an untrusted secret key
KEK only. If an attempt to uncover the imported key under anything
but the correct untrusted KEK the operation will fail. However, the
KEK to cover the converted public key with (the newly converted IRE
public key) can be a trusted or untrusted secret key KEK.
The public key to imported is eventually copied into the
argument, pk, the publickey object. The privkey, type and length
members must be present in order to import the public key. Therefore,
the private key is the only portion of the public keyset that is imported.
The application can move the public and modulus portion itself.
As part of the command the application must indicate the
number of salt bits that will be skipped before it can extract the private
key bits. This is accomplished via the argument, skip len, and it must
be in multiples of 2 bytes.
Command Interfaces:
/*import an oxternal private key onder an untiusted secret key KEK
cgx import_pubkey( kernelblock *kb,
231
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
unsigned short *ibui;
ciypto_cntxt *ikek,
unsigned short skip len,
publickey *pk,
crypto_cntxt *pkek)
Arguments:
kb->cb->cmd = CGX Il&IORT PUBKEY;
/* the BLACK IRE private key to import into
]cb->cb->ar8ument[O] = (VP7R)pk:
/* the KCR K or KEK location to uncover the extetnal private key */
kb-~cb->argument[ll = (VPTR)ikok
/* the buffer that houses the external piivate key */
1cb->cb->argnment[2l = (VPTR)tbuF,
/* the KCR KEK location to cover the IRE private key
*/
kb->cb->argument[3] = (VPTR)pkek;
/*salt bits to skip */
kb->cb->argument[S) = (VPTR)sldp_leq
Status:
kb->sb->status = CGX SUCCESS S, or
CGX INVALIDREG S
See Also: CGX GEN PUBKEY, CGX GEN NEWPUBKEY, and
CGX EXPORT PUBKEY
Digital Signature Commands
SIGN (Digitally Sign A Message)
Command Name: CGX SIGN
Command Description:
The digital signature sign command is used to sign the
application's message using the DSA digital signature algorithm.
The application can pass in a covered(i.e. BLACK) DSA public
key or an uncovered (i.e. RED) public key. If the color of the public
key is determined by the argument, kek. If it is NULL then the public
key is assumed to be in the RED form. If the argument is non-NULL
232
CA 02303297 2000-03-13
WO 99/14881 PCT/13S98/19316
then the public key is in the BLACK form and must be uncovered with
the kek.
To digitally sign a message a one-way hash result is processed
by the digital signature algorithm. The result of the sign command is
placed into the signblock.
The result is returned in the signblock, it's the data in this block
that must be used by the CGX VERIFY command to verify the
message's signature.
Also, the application is allowed to pass in K, of the DSA
vectors. Remember K is typicalty a random vector that should be
considered secret. If K is known by anyone they can forge the
signature. Therefore, using this feature must be used only in extreme
cases; otherwise pass in a NULL pointer and let the secure Kernel
generate K.
Prior to using this command the application must calculate the
one-way hash value of the message to sign. The result of the one-way
hash value is stored in the hash cntxt block object. This block must be
passed in as an argument to the command.
Command Interface:
/*DSA sign the application's message
cgx sign( kemelblock *kb,
publickey *pk,
crypto_cntxt *kek,
signblock *sb,
hash cntxt *hc,
unsigned short *K)
Arguments:
kb->cb->cmd = CGX SIGN;
233
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* the DSA public keyset
kb->cb->argnment[Ol = (vPTR)pk;
/* signature block, contains result of signature (input/output)
kb-~rgament(ll = (vPTR)sb,
/* one-way hash value of inessage to sign
]cb->cb->argument[2l = (VPTR)hc;
/* The KEK to uncover the DSA private part, NULL privato is RED */
kbacb->argument[3l = (VPTR)kek;
/* vector K, NULL Kernel generates K, highly risky to use
kb->cb->argumentl4l = (VPTR)K;
/* a non-zero value requests the sign be vorified */
kb->cb->argument[5] = (vPTR)recheck;
Status:
kb->sb->status = CGX SUCCESS S.
CGX FAIL_S,
CGX BAD_KEYSET S/* empty key RAM or wrong alg *1
See Also: CGX VERIFY, CGX Il~TIT HASH, and CGX HASH DATA
- - -
VERIFY (Verify A Digital Signature)
Command Name: CGX VERIFY
Command Description:
The digital sigaature verify command is used to verify the
signature of the application's message using the DSA public key
algorithni.
To verify a digital signature a one-way hash is calculated over
the message and its result is processed by the digital signature algorithm
for verification. The result of the verify command is compared to the
result already in the signblock.
The result of the calculation is compared to the signature result
already stored in the signblock, if the results compare then the signature
is valid; otherwise the signature fails and is not valid.
The application need only pass in the modulus and public parts
of the DSA public keyset, the private part is ignored.
234
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Prior to using this command the application must calculate the
one-way hash value of the message to verify. The result of the one-way
hash value is stored in the hash cntxt block object. This block must be
passed in as an argument to the command.
Command Interface:
/*DSA verify the application's signed message
cgx verify( kernelblock *kb,
publickey *pk,
signblock *sb,
hash cntxt *hc)
Arguments:
kb->cb->cmd = CGX VERIFY;
/* the DSA public koyset */
Icb->cb->argumenclOJ = (NPTR)Ik;
/* signature block, contains result of signature (input/ontput) */
kb->cb->argumentll] = (VPTR)sb;
/* one-way hash value of message to sign
kb->cb->argumentl2] = (VPTR)hc;
Status:
kb->sb->staaus = CGX SUCCESS S,
CGX INVALID_SIGNATURE_S, or /* sig not valid */
CGX BAD_KEYSET S/* empty key RAM or wrong alg */
See Also: CGX SIGN, CGX INIT HASH, and CGX HASH DATA
Extended Algorithm Commands
LOAD EXTENDED (Load/Enable Extended Algorithm Block)
Command Name: CGX LOAD EXTENDED
Command Description:
The load extended algorithm command allows up to 8 kilo-
words of expansion for secure kernel program memory. This block can
be used to augment the secure kernel with algorithms (e.g., IDEA or
Blowfish) or features which are not contained in the standard kernel.
235
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Because this command will cause the kernel to accept the application
code as legitimate, the application must be signed by IRE. When
invoking the load extended command, the application must present the
signature provided by IRE. The signature will be authenticated by the
secure kernel before enabling the extended algorithm block. If the
signature is not successfully authenticated, the secure kernel will not
transfer the application code to the extended algorithm block and
hardware protection for the extended algorithm block will not be
enabled.
The extended algorithm block must be bound beginning at
location xxaa. When the signature over the algorithm block has been
verified, the kernel will transfer the application from program memory
into the extended algorithm block and enable kernel protection over the
block.
Once the extended algorithm block has been authenticated and
loaded, the application can invoke operations in the extended algorithm
block via the CGX EXEC EXTENDED command. When the
application no longer needs the extended algorithm block, the block
may be disabled via the CGX CLEAR EXTENDED command.
If the application does not to use the extended algorithm block
to expand the secure kernel, it may still be used for application code.
Command Interface:
/* load the extended algorithm block and enable hardware protection
cgx load_extended(kernelblock *kb,
unsigned char pm *prog,
LJINT 16 len,
signblock *sb)
Arguments:
236
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
kbaid~d CGX LOAD_EXTENDED;
/* the address of the extended algorithm block
kb-Ncb->argument[ol - (VP1'R)prog;
/* the length of the block in 24-bit words */
kb->cb->argumGnt[l] = (VPTTt)len;
/* the sigoatnre for the extended algorithm bloclc
kb->cb->argument[2] = (VPTR)sb;
Status:
kb--i-sb->statUS = CGX SUCCESS S,
CGX ACCESS DENIED, /* Extended algorithms not
* permitted.
or CGX IIWALIDSIGNATURE_S.
See Also: CGX EXEC EX"13/NDED and CGX CLEAR EXTENDED
EXECUTE EXTENDED (Execute Extended Algorithm Block)
Command Name: CGX EXEC EXTENDED
Command Description:
The execute extended algorithm command allows the
application to invoke operations contained in the extended algorithm
block. Operations are permitted a maximum of 10 parameters stored in
the urgument member of the cmdblock structure. In order for a request
to execute from the extended algorithm block to be honored, the
algorithm must already have been loaded via the
CGX LOAD EXTENDED command.
Before invoking the extended algorithm block, the secure kernel
will verify that the block is active (i.e., has a valid algorithm loaded). If
so, control is transferred to the extended algorithm block via the
block's entry point (the specific location is yet to be determined). It is
the algorithm block's responsibility to handle branching to the
appropriate handier operation. In other words, once control is
transferred to the extended algorithm block's entry point, the
application is responsible for handling the command.
237
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Upon completion of command processing, the extended
algorithm can return a UINT16 value indicating the completion status
of the command. This value will be available to the application in the
status field of the kernel block.
Command Interface:
/* execute from the extended algorithm block
cgx execute extended(kernelblock *kb)
Arguments:
kbacb->cmd ~ CGX EXEC EX 1'ENDED;
/* arguments can be passed by the application via the argument
* array. This data will be available to the algorithm block.
Status:
kb->sb->status = CGX ACCESS DENIED_S, /* extended algorithms not
* permitted.
CGX FAII._S, /* extended algorithm block not
* initialized.
result from extended algorithm.
See Also: CGX LOAD EXTENDED and CGX CLEAR EXTENDED
Hash Commands
HASH INIT (Initialize The HASH Operator)
Command Name: CGX HASH INIT
Command Description:
The Initialize Hash command is used to initialize a Hash context
block, hash cntxt, and prepare it for the start of a Hash calculation. The
application must invoke the initialize Hash operation prior to starting a
new Hash calculation; if not the hash_cntxt is not initialized and the
Hash calculation will be incorrect. Having the Iinitialize Hash
command allows the application to run simultaneous Hash calculations,
238
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
interleaving the calls to CGX HASH DATA. This is facilitated due
to the Hash context management.
The Hash operations support SHS-1 and MID5 one way Hash
algorithms. Both Hash algorithms have a limit of 2" bits message
length and both process units of words.
The application must setup the hash cnbxt with an algorithm
mode (i.e., CGX SHS A or CGX NIDS A) prior to the execution of
the initialize Hash command. Upon completion of this operation, the
hash context will contain a NULL value in the digest member of the
hash cntxt. When the hash is closed, the digest member will be a valid
pointer to the hash digest.
Command Interface:
/* initialize HASH context, prepare to HASH */
cgx hash init(kernelblock *kb,
hash cntxt *hb)
Arguments:
kb->cb->cmd = CGX INIT HASH;
/* the hash context block to initialize
kb->cb->argument[4] = (VPTR)hb;
Status:
kb->sb->statas = CGX SUCCESS_S, or
CGX BAD MODE S/* only SHS-1 or MD5 available */
See Also: CGX_HASH_DATA
HASH DATA (HASH Customer Data)
Command Name: CGX HASH DATA
Command Description:
239
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The Hash Data command is used to calculate a Hash value of
the application's data. The hash may include a data key either
prepended to the data, appended to the data, or both (the keys need not
be the same). The key may not be inserted into the middle of the data
due to security concerns [in this context, "data" encompasses the entfre
data stream to be hashed - in other words, keys can only be hashed at
the very beginning or end of the data]. Neither the key, nor its parent in
the key hierarchy (i.e., its KEK) may be trusted. Any attempt to hash a
trusted key will result in a failure. The hash_cntxt block allows the
application to run simultaneous Hash calculations interleaving the calls
to CGX HASH DATA.
The HASH operations support SHS-1 and MD5 one-way Hash
algorithms. Both Hash algorithms have a message length limit of 264
bits and operate on units of bytes.
The application must set up the hash cntlct with an algorithm
mode (i.e., CGX SHS M or CGX 1VID5 M) prior to the execution of
the HASH data command. The application must set the context block
up and invoke the CGX INTT HASH command first.
Because it illegal to request hashing of the LSV, a value of non-
0 for the key indicates that a keyed hash is being requested. When
keyed hashing is requested, the position of the key in the data must be
identified as either CGX PREPEND O, CGX APPEND_O, or both.
The position parameter is a bit field.
Setting the final argument to I signals the end of the message.
This causes the secure kernel to prepare the message digest. If the final
operation is not performed, the message digest is incorrect. If the
application has no message to Hash and has set final to 1 then it must
set message len to 0. When message len is set to 0 the message buffer
240
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
is ignored. However, if there are still more messages to Hash, the
application must set finul to 0.
Command Interface:
/* calculate HASH of message cgx hash data(kernelblock *kb,
unsigned short message_pg,
unsigned short *message,
unsigned long length,
unsigned short final,
kcr key,
unsigned short position,
hash cntxt *hb)
Arguments:
kb->cb->cmd = CGX HASH_DATA;
/* the hash context block */
Ib->cb->argument[U] = (VP'TR)hb;
/* the data page of the message. If necessary, the underlying
* sofl.ware will up temporarily switch pages in order to access
* the message data.
kb->cb->argument[ 1 ] = (VPTR)message_pg;
/* pointer to length bytes of memory to HASH, a nussage can be
* variable length. The application can make as many calls to
* calculate the HASH message digest. This is because of the
* hash cntxt block. If final operation and no message set to NULL.
kb->cb->argument[2] _ (VPTR)massage;
/* length, set to 0 if no more data to hash. The data length is 4
* bytes long, broken into two arguments. Length represents the
* number of bytes to hash, up to a total of 2d' bits (26'
*byws)to hasIL
kb->cb->ar8ament[3] = (VP'TRx(leng@- 16) & Oxf[M;
lcb->cb->argument[4] = (vPTR)(length & oxBM;
/* if no more message data to hash, set Snal to 1*/
/* otherwise there is more data to come or at least another */
/* call to CGX_HASH DATA so set final to a 0*/
kb->cb->argumart[5] = (VPTR)final;
/* identify the KCR containing the key to be hashed into the
/* data. The key (and its KEK) cannot be trusted keys or the*/
/* operation wiu fail */
kb->cb->argument[6] = (VPTR)k3'.
/* specify where the key is to be added relative to the data */
/* this parameter is a bit-field; so, prepending and appending */
/* of the key is permitted using arithmetic OR */
241 -
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
kb->cb->r.6""'.=[7] = (V= M)pOstnon,
Status:
kb->sb->status = CGX SUCCESS_S,
CGX FAIL_S, /* length = 0 and final = 0*/ or
CGX BAD MODE S/* only SHS-1 or 1vID5 available */
See Also: CGX INTT HASH
HASH ENCRYPT (Hash and Encrypt User Data)
Command Name: CGX HASH ENCRYPT
Command Description:
The Hash and Encrypt command is used to perform a hash
calculation and symmetrical encryption of the customer's data. Having
a hash cntxt and crypto_cntxt block allows the application to run
simultaneous hash calculations interleaving the calls with
CGX HASH DATA and CGX HASH DECRYPT commands; this is
because of the context management objects, hash cntxt and
crypto cntact.
The hash algorithms supported are SHS-1 and MD5 one-way
hash algorithms. For any invocation of hash encrypt, the algorithms
have a limit of 216 bytes. Due to requirements imposed by the
encryption operations, the length must be evenly divisible by 8 (the
encryption/decryption operations operate on blocks of 8 bytes). A
message not evenly divisible by 8 must be padded by the application.
The message or block may be padded with any pattern the application
wishes.
The encrypt algorithms supported are: DES, Triple DES, and
RC5, in several modes: ECB, CFB, OFB, and CBC. The encryption
algorithms only support block encryption, a block must be divisible by
64 bits long (to be performed by the application). A encrypted data
242
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
session can extend beyond one call to the encryption command; this is
accomplished via a crypto cntxt block (described below).
The data buffers, datain (plain-text) and dataout (cipher-text),
can share the same address.
Prior to invoking the hash and encrypt command the application
must setup the crypto_cntxt block. The application is responsible for
setting the configuration, masking in one of the special key load options
(described below), setting the appropriate secret key KCR ID, and for
priming the iv buffer with an initial random number (only for the first
call). After this, the application need not modify the crypto_cntxt block
unless something changes (i.e., secret key KCR ID location, and/or the
iv to cause a resynchronization).
The iv buffer of the crypto_cntxt block must be read- and write-
able; the iv buffer is used to maintain the feed-back register for the
CBC, CFB, and OFB modes. In the ECB mode the iv buffer is ignored.
The hash and encryption command allows the application to
mask in one of the special mode control bits defined in section 0, into
the config field of the crypto_cntxt block. The control bits are used by
the secure kernel to determine how to load secret keys before the actual
encryption of the plain-text takes place. The control bits allow the
application to request one of these options: auto-load, force-load, or
no-load. Auto-load allows the secure kernel to check which key is
currently loaded into the KG, if it's the same as the key specified for the
encryption command it is not loaded; otherwise the key is loaded.
Force-load tells the secure kernel to always load the key. No-load tells
the secure kernel to not load the key; more than likely the application
has already loaded the key (maybe via the CGX LOAD KG
command). By default auto-load is assumed.
243
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
The application must also set up the hash cntxt with an
algorithm (i.e., CGX SHS M or CGX MD5_M) prior to the execution
of the hash data command. The application must set-up the context
block and invoke the CGX INIT HASH command first.
Setting the final argument to I instructs the secure kernel to
prepare the hash value for return to the application. If the final
operation is not performed the message digest is incorrect. If the
application has no message to hash and has set final to 1 then it must set
length to 0. When length is 0, the datain buffer is ignored. If there are
still more messages to hash the application must set final to 0.
The order parameter allows the application to specify the hash
and encrypt order. The value CGX HASH CRYPT O indicates hash
before encrypt and CGX CRYPT HASH O implies encrypt before
hash.
The offset parameter indicates the number of bytes to process
according to the value of order before applying the other operation.
That is, if offset = 4 and order = CGX H.ASH CRYPT O, then 4
bytes of data will be hashed, and then the remaining length-4 bytes will
be hashed and encrypted. The value of offset must be even (i.e., align
on a word boundary).
The secret key to be loaded as referenced via the crypto_cntxt
must have the key usage setting of CGX KCR K. This command only
allows traffic or data keys to be loaded or it wili fail. The key usage
information is programmed by the application at the time a secret key
has been loaded, generated, derived, or negotiated and is maintained
securely by the secure Kernel. This means an LSV, GKEK, or KEK
type of secret key can not be loaded by this command.
Command Interface:
244
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
/* calculate HASH and encrypt the message
cgx hash encrypt( kerneiblock *kb,
UINT16 datain_pg,
IJINT16 *datain,
LJIlVT 16 dataout_pg,
UINT16 *dataout,
UINT16 length,
UINT16 order,
UINT16 offset,
iJIlVT16 final,
crypto_cntxt *cb
hash cntxt *hb)
Arguments:
kb->cb->cmd = CGX HASH ENCRYPT;
/* mode selection, mask the special mode and configuration
* control bits with the mode here via the crypto cntxt block
kb->cb->argument[0] = (VP'I'R)cb;
/* the hash context block to initialize
kb->cb->argument[1] _ (VI''TR)hb;
/* input message to be encrypted and hashed (data page, offset)
kb->cb->ar8un=W[2] = (VPTR)datain_pf.
kb->cb->argument[3] = (VPTR)datain;
/* mmber of bytes (byte = 8 bits) to encrypt
kb->cb->argument[4] = (VPTR)length;
/* if no more message data, set finai to a 1*/
/* otherwise there are more messages to come or at least another
/* call to CGX HASH_DATA so set final to a 0*/
kb->cb->argument[5] = (VF'TR)&nal;
/* if hash before encrypt set order to a CGX HASH CRYPT_O
/* if encrypt before hash set order to a CGX CRYPT'._HASH O
kb->cb->argument[6] _ (VPTR)order,
/* output the encrypted data blocks (data page, offset)
kb->cb->argument[7] = (VPTR)dataout;
kb->cb->argument[8] = (VPTR)daMM_p8:
/* hasb/decrypt offset */
kb->cb->argument[9] = (VPTR)offsot;
Status:
kb->sb->status = CGX SUCCESS S,
CGX WEAK_KEY_S,
CGX_BAD MODE S,
CGX EMP'ITREG S, or
CGX_INVALID_REG S
See Also: CGX INIT HASH, CGX ENCRYPT, and CGX HASH DATA
245
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
HASH DECRYPT (Hash and Decrypt User Data)
Command Name: CGX HASH DECRYPT
Command Description:
The hash and decrypt command is used to perform a hash
calculation and symmetrical decryption of the customer's data. Having
a hash cntxt and crypto cntxt blocks allows the application to run
simultaneous hash catculations interleaving the calls with
CGX HASH DATA and CGX HASH ENCRYPT commands; this is
because of the context management objects, hash cntxt and
crypto_cntxt.
The one-way hash algorithms supported are: SHS-1 and MD5.
For any invocation of hash decrypt, the algorithms have a limit of 216
bytes. Due to requirements of the encryption algorithms, message
lengths must be evenly divisible by 8. Any message or block not evenly
divisible by 8 bytes must be padded by the application. The message
may be padded with any pattern which the application chooses.
The decrypt algorithms supported are: DES, Triple DES, and
RC5, in several modes: ECB, CFB, OFB, and CBC. The decryption
algorithms only support block decryption, a block must be 64 bits long.
The decryption command can handle up to 213 bytes at one time.
Furthermore, an encrypted data session can extend beyond one call to
the decryption command; this is accomplished via a crypto cntxt block
(described below).
The data buffers, datain (plain-text) and dataout (cipher-text),
can share the same address.
246
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
Prior to invoking the hash and decrypt command the
application must setup the crypto cntxt block. The application is
responsible for setting the configuration, masking in one of the special
key load options (described below), setting the appropriate secret key
KCR ID, and for priming the iv buffer with an initiat random number
(only for the first call). After this, the application need not modify the
crypto_cntxt block unless something changes (i.e., secret key KCR ID
location, algorithm, and/or the iv to cause a resynchronization).
The iv buffer of the crypto_cntxt block must be read- and write-
able; the iv buffer is used to maintain the feed-back register for the
CBC, CFB, and OFB modes. In the ECB mode, the iv buffer is
ignored.
The hash and decrypt command allows the application to mask
one of the special mode control bits, defined in section 0, into the
algorithm field of the crypto cntxt block. The control bits are used by
the secure kernel to determine how to load secret keys before the actual
encryption of the plain-text takes place. The control bits allow the
application to request one of these options: auto-load, force-load, or
no-load. Auto-load allows the secure kernel to check which key is
currently loaded into the KG, if its the same as the key specified for the
decryption command it is not loaded; otherwise the key is loaded.
Force-load tells the secure kernel to always load the key. No-load tells
the secure kernel to not load the key; more than likely the application
has already loaded the key (maybe via the CGX LOAD KG
command). By default auto-load is assumed.
The application must also set up the hash cntxt with an
algorithm mode (i.e., CGX SHS M or CGX 1VID5 M) prior to the
247
CA 02303297 2000-03-13
WO 99/14881 PCT/US98/19316
execution of the hash data command. The application must setup the
context block and invoke the CGX INIT HASH command first.
Setting the final argument to I signals the secure kernel to
prepare the message digest for the application. This is important to
correctly calculating the message digest. If the final operation is not
performed the message digest is incorrect. If the application has no
message to hash and has set final to 1. When nblocks is set to 0 the
datain buffer is ignored. However, if there are stiII more messages to
hash the application must set final to 0.
The parameter order allows the application to specify the hash
and decrypt order. The value CGX HASH CRYPT_O indicates hash
before decrypt and CGX CRYPT HASH_O implies decrypt before
hash. The offset parameter indicates the number of bytes to process
according to the value of order before applying the other operation.
That is, if offset = 4 and order = CGX HASH CRYPT_O, then 4
bytes of data will be hashed, and then the remaining length-4 bytes will
be hashed and decrypted. The value of offset must be even (i.e., align
on a word boundary).
The secret key to be loaded as referenced via the crypto_cntxt
must have the key usage setting of CGX KCR K. This command only
allows traffic or data keys to be loaded or it will fail. The key usage
information is programmed by the application at the time a secret key
has been loaded, generated, derived, or negotiated and is maintained
securely by the secure Kernel. This means an LSV, GKEK, or KEK
type of secret key can not be loaded by this command.
Command Interface:
248
CA 02303297 2000-03-13
DEMANDES OU BREVETS VOLUMlNEUX
LA PRESENTE PARTIE DE CETTE DEl1ItANDE OU CE BREVET
COMPREND PLUS iD'UN TOME.
CECI EST LE TOME DE 2-'
~
NOTE: Pour les tomes additionels, veuiliez contacter le Bureau canadien des
brevets
-- - ---- - ------
Jl1MBO APPLlCATIONS/PATE111TS
THiS SECTION OF THE APPUCATION/PATENT CONTAINS MORE
THAN ONE VOLUME
THIS IS VOLUME OF
NOTE: For additional voiumes=please cantact-the Canadian Patent Office
i 11
