WO1999014881A2 - Coprocesseur cryptographique - Google Patents

Coprocesseur cryptographique Download PDF

Info

Publication number
WO1999014881A2
WO1999014881A2 PCT/US1998/019316 US9819316W WO9914881A2 WO 1999014881 A2 WO1999014881 A2 WO 1999014881A2 US 9819316 W US9819316 W US 9819316W WO 9914881 A2 WO9914881 A2 WO 9914881A2
Authority
WO
WIPO (PCT)
Prior art keywords
memory
key
kemel
cgx
integrated circuit
Prior art date
Application number
PCT/US1998/019316
Other languages
English (en)
Other versions
WO1999014881A3 (fr
Inventor
Michael M. Kaplan
Robert Walker Doud
Bronislav Kavsan
Timothy Ober
Peter Reed
Original Assignee
Information Resource Engineering, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Information Resource Engineering, Inc. filed Critical Information Resource Engineering, Inc.
Priority to CA002303297A priority Critical patent/CA2303297C/fr
Priority to AU10609/99A priority patent/AU1060999A/en
Priority to EP98953170A priority patent/EP1013026A4/fr
Publication of WO1999014881A2 publication Critical patent/WO1999014881A2/fr
Publication of WO1999014881A3 publication Critical patent/WO1999014881A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0485—Networking architectures for enhanced packet encryption processing, e.g. offloading of IPsec packet processing or efficient security association look-up
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/79—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82—Protecting input, output or interconnection devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • G06F9/3879—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor for non-native instruction execution, e.g. executing a command; for Java instruction set
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • H04L9/0656—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher
    • H04L9/0662—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher with particular pseudorandom sequence generator
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/04—Masking or blinding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/125—Parallelization or pipelining, e.g. for accelerating processing of cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/20—Manipulating the length of blocks of bits, e.g. padding or block truncation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/34—Encoding or coding, e.g. Huffman coding or error correction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present invention relates generally to a secure communication platform on an integrated circuit, and more particularly relates to a digital signal processor (DSP) with embedded encryption security features.
  • DSP digital signal processor
  • DSPs Digital signal processors
  • DES Data Encryption Standard
  • Hash function algorithms hardware implemented public key accelerators
  • DES Data Encryption Standard
  • DSA Digital Signature Algorithm
  • 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).
  • LIPS Internet Protocol Security Standard
  • 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 appUcations.
  • 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.
  • a universal cryptographic co-processor e.g., DSP
  • DSP digital signal processor
  • the cryptographic co-processor is implemented on a standard processor platform (i.e., substrate or monoUthic chip)
  • the processor that is being used in a manufacturer's product can be substituted with the cryptographic co-processor with Uttle 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.
  • FIG. 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 4 is a block diagram of the data memory preferably used in the coprocessor of the present invention.
  • FIG. 5 is a block diagram of the PCI memory preferably used in the coprocessor of the present invention.
  • FIG. 6 is a block diagram of the DMA subsystem preferably used in the co-processor of the present invention.
  • FIG. 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.
  • 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.
  • FIG 11 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 kernel 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 coprocessor 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.
  • 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 pubUc keyset preferably used in the co-processor of the present invention.
  • Figure 25 is a portion of a computer program defining the Diffie-HeUman pubUc keyset preferably used in the co-processor of the present invention.
  • Figure 26 is a portion of a computer program defining the RS A pubUc 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.
  • FIG. 1 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.
  • the co-processor may further include a standard direct memory access (DMA) controller circuit 42, which will be described in greater detail.
  • DMA direct memory access
  • the Input/Output blocks 2 provide several customized functions that enable the appUcation 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 overaU device.
  • the security blocks 6 implement the security features of the cryptographic co-processor as weU as protection schemes.
  • the cryptographic co-processor includes components which provide several Input/Output (I/O) functions. These components include a synchronous serial port 12, a bit I/O 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 (MLPS) 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 reset of the DSP 20 and/or other hardware blocks tied to the cryptographic coprocessor 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.
  • RAM program random access memory
  • the security portion of the co-processor 6 includes an encryption circuit 36, a random number generator circuit 38, a hardware pubUc 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.
  • the encryption circuit 36, random number generator circuit 38, pubUc 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.
  • 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).
  • EBC Electronic Code Block
  • CBC Cipher Block Chaining
  • CFB Cipher Feed Back
  • OFB Output Feed Back
  • the DES and Triple DES encrypt decrypt operations are pipeUned 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 aUowing multiple encryption circuit contexts, thus aUowing packet switching. With a writable state register 40, a previous context can be reloaded or a new one created. This minimizes 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.
  • 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 appUcation.
  • the hash circuit 30 provides hardware accelerated SHA-1 and MD5 oneway 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.
  • the cryptographic co-processor performs paraUel 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 LPsec.
  • the hardware public key accelerator 28 is provided to support large number addition, subtraction, squaring and multipUcation. 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-Hellman 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 providing the mathematical 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 AppUcation 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 coprocessor, the device may operate in either a user mode or a kernel mode. In the user mode the kernel space is not accessible, while 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 appUcation.
  • 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.
  • a manufacturer may substitute the co-processor of the present invention for a conventional digital signal processor (DSP) in the equipment (e.g., modem, ceUular phone, etc.) which is being manufactured.
  • the conventional digital signal processor (DSP) does not provide secure communications.
  • the coprocessor of the present invention performs all of the functions of the conventional DSP but also has the unique capability of providing secure communications.
  • 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 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 Ubrary and select the desired encryption algorithm or function from the Ubrary.
  • the advantage of the universal co-processor is that the user does not have to recreate any encryption or hashing or pubUc key algorithms, as they are preprogrammed in the ROM Ubrary; aU the manufacturer has to do is select whichever algorithm he wishes to use in the encryption or hashing process.
  • a pre-programmed command set which includes a number of encryption, pubUc key and HASH commands.
  • the command CGX-PUBKEY-ENCRYPT refers to a public key encrypt command which is used to encrypt the appUcation' 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 pubUc key structure.
  • commands are recognized by a microprocessor forming part of the co-processor, which accesses the Ubrary and retrieves the particular encryption algorithm, for example, the RSA algorithm, from the Ubrary and uses it in the encryption process.
  • a microprocessor forming part of the co-processor, which accesses the Ubrary and retrieves the particular encryption algorithm, for example, the RSA algorithm, from the Ubrary and uses it in the encryption process.
  • the appUcation software designer selects the encryption and/or HASH functions from the Ubrary and thus avoids having to directly communicate with the crypto hardware.
  • a standard direct memory address (DMA) controUer circuit 42 is preferably included within the cryptographic co-processor to faciUtate bulk data movements without requiring continuous processor supervision. It preferably aUows 32 bit transfers to occur at up to 40 M words per second.
  • the DMA controUer 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 controUer circuit 50 provides enhancements to the existing interrupt functions in the processor blocks 4.
  • the interrupt controUer circuit 50 provides interrupt generation capabUities 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 appUcation register circuit 52 is coupled to the security blocks 6 and the processor blocks 4.
  • the appUcation register circuit 52 is a set of memory-mapped registers which faciUtate 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 appUcation 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) controUer 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.
  • PCDB settings may be overridden with a digitaUy 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).
  • a serial electricaUy 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 weU 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 w l use the cryptographic co-processor as the main processor.
  • the cryptographic coprocessor and more specificaUy the input/output blocks 2 can be configured to one of three host bus modes: LDMA 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 (LDMA, 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 is intended to be different on each chip. Therefore, it is not mask-programmed. Mask programming is done with Uthography which affects the artwork of the integrated circuit. Since no two chips should have the same LSN, the LSN 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 LSN so that each cryptographic co-processor is individualized with a particular LSN.
  • 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. (LRE).
  • 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 description of each of the major subsystems within the CryptIC co-processor, including complete register details.
  • the ADSP 2141 CryptIC 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 avaUable in a 208-pin MQFP package with a Commercial (0° - 70°C) Temperature
  • the DSP Core is a standard Analog Devices ADSP-2183 with full ADSP-2100 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 I O, extensive interrupt capabilities, and on-chip program and data memory.
  • the External 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.
  • the Secure Kernel is embodied as firmware which is mask-programmed into ROM within the DSP, thus rendering it tamper-proof.
  • the Kernel provides the API (AppUcation Programming Interface) to appUcations which require security services from the CryptIC. Those appUcations 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.
  • CGX Circuit Extensions
  • 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.
  • 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 not accessible) or 'Kernel Mode' (Kernel Space is accessible) at a given time.
  • Kernel RAM and certain protected Crypto 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 calling application.
  • the Kernel 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.)
  • 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.
  • the Kernel Mode Control block (above) enforces the protection by only aUowing internal Secure Kernel Mode accesses to this RAM.
  • a PubUc 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.
  • the Encrypt Block performs high-speed DES and Triple DES encrypt decrypt operations. All 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).
  • EBC Electronic Code Book
  • CBC Cipher Block Chaining
  • OFB 64-bit Output Feedback
  • CFB Cipher Feedback
  • the DES encrypt/decrypt operations are highly pipeUned and execute full 16-round DES in only 4 clock cycles.
  • Hardware support for Padding insertion, verification and removal further accelerates the encryption operation.
  • Context Switching is provided to minimize the overhead of changing crypto Keys and IN' s to nearly zero.
  • 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.
  • Hash-then-Encrypt and Hash-then-Decrypt operations the CryptIC can perform parallel execution of both functions from the same source and destination buffers.
  • Encrypt-then-Hash and Decrypt-then-Hash operations the processing must be sequential, however minimum latency is still provided through the pipeUne chaining design.
  • An Offset may be specified between the start of Hashing and the start of Encryption to support certain protocols such as LPsec, and 'Mutable bit' handling is provided in hardware.
  • the hardware Random Number Generator provides a true, non-deterministic noise source for the purpose of Generating Keys, Initialization Vectors (IN's), and other random number requirements. Random numbers are provided as 16-bit words to the Kernel.
  • the Security Kernel 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 appUcation via the CGX_Random CGX command.
  • the Public Key Accelerator module works in concert with the CGX Secure Kernel firmware to provide fuU PubUc Key services to the host application.
  • the CGX Kernel provides Macro-level Ubrary 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
  • 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 DProcessor
  • 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.
  • CryptIC is capable of using DMA to directly access data on other PCI entities and pass that data through its Encryption/Hash engines.
  • the CryptIC incorporates a high-performance 32-bit DMA controUer which can be set-up to efficiently move data between Host PCI memory, the Hash Encrypt blocks, and/or External Memory.
  • the DMA controUer 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.
  • the Application Registers are a set of memory-mapped registers which faciUtate 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.
  • 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.
  • the Security Block Interrupt Controller provides enhancements to the existing
  • the Interrupt Controller provides a new Interrupt Generation capability to the DSP or to an external Host Processor.
  • 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.
  • 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:
  • the Program Control Data (PCD) bits include configuration for permitted Key Lengths, Algorithm Enables, Red KEK loading, Internal IC Pulse Shaping
  • the CryptIC 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 Kernel firmware. AU downloaded firmware is authenticated with a Digital Signature and verified with an on-chip Public Key. Additional functions could include new Encryption, Hash or PubUc Key algorithms such as LDEA, RC-4, RIPEMD, ElUptic Curve, etc. MEMORY CONFIGURATION
  • 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 aUow 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
  • the CryptIC 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.
  • Kernel ROM 0 Base Page
  • Kernel ROM 1 Kernel ROM 0 (Base Page) 1110
  • Kernel ROM 1 Kernel ROM 0 (Base Page) 1110
  • the 12 msb's (bits 15:4) are mapped to the most-significant external address pins on the CryptIC (addr 25: 14).
  • the PMOVLAY register should be set to OxOOOE (although the uppermost 12 bits are ignored in this case).
  • the PMOVLAY register should be set to 0x0131 (0x013 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.
  • Kernel RAM and Kernel Registers 1110 reserved
  • the 12 msb's (bits 15:4) are mapped to the most-significant external address pins on the CryptIC (addr 25: 14).
  • the DMOVLAY register should be set to OxOOOF (although the uppermost 12 bits are ignored in this case).
  • the DMOVLAY register should be set to 0x04F2 (0x04F are the 12 msb's representing pages 158 & 159 and a 2 in the least-significant nibble indicates External odd page).
  • 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 Usted Table 1 below. All of the Protected Registers are memory-mapped in the Data Memory space of the DSP at 0x1000 - 0xl7FF.
  • the Unprotected registers reside at 0x1800 - OxlFFF.
  • the DMOVLAY register must be set to OxOOOF to access these registers.
  • the base register address in the PCI/PCMCIA space is set by the B ASEADDR 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.
  • 16-bit address refers to the DSP and 32-bit address refers to PCI host.
  • the CryptIC supports multiple bus interfaces in order to allow it to be integrated into a wide variety of host systems. These buses are:
  • PCI also Cardbus
  • PCMCIA PCMCIA
  • the CryptIC Host Bus may be configured for one of 4 personaUties: ADSP 2183 Compatible LDMA Mode, LDMA 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.
  • a number of pins on the CryptIC are intemaUy multiplexed in order to change bus personaUties. Refer to the CryptIC Datasheet for detaUs. 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 groimd or V DD on the PC Board.
  • the Multiplex bus pins become personalized to directly connect to a 3.3N 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.
  • the PCI interface does NOT support the following:
  • the CryptIC appears on the PCI Bus as a single contiguous memory space of 128k bytes.
  • the CryptIC presents a 17 bit [16:0] address interface as a PCI Target.
  • Inbound PCI address bits [31 : 17] are decoded by the CryptIC PCI core to determine 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.
  • 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 16 lsb's are interpreted as CryptIC internal register/memory address bits. If address bit 16 is 1, the 16 lsb's [A15-A0] 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.
  • the CryptIC provides memory-mapped or I/O-mapped access to its 'unprotected' memory and register space. This includes read/write access through the CryptIC to the external memory connected to the EMI bus.
  • 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 wiU not be preempted, however any pending DSP-inititated DMA wiU be deferred until after all Target transfers have been completed. (A status register in the DMA controller aUow the DSP to determine whether it has seized the controUer or whether a Target transfer is running ) Refer also to 0 for more information on the DMA controUer.
  • the DSP 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 FLFO (12 dwords) can store the written data until it can be DMA'ed to its destination within the CryptIC.
  • 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 LDMA transfers or transfers to external memory with >1 wait state will result in PCI timeout aborts for transfers >8 dwords.
  • 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.
  • the 256-byte PCI configuration space is defined below in Table 4.
  • the fields marked xxxxxxxx are 'don't cares'. Shaded fields are read-only registers and are loaded from the serial EEPROM connected to the CryptIC. 31 16 15 Addr.
  • the upper 15 bits of the Base Address registers are writable, aUowing 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.
  • the lower 17 bits will be read as O's, indicating 128k. Then, the BIOS writes an appropriate Base Address into the upper 15 bits which were read as l's. 2183 IDMA Host Processor Bus
  • the 2183 LDMA Host selection (Internal Direct Memory Access) aUows the CryptIC to offer the LDMA interface directly to an outside Host processor.
  • the CryptIC 's usage of the LDMA bus is identical to that described in the ADSP 2183 datasheet and ADSP-2100 Family User' s Manual.
  • the LDMA 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 LDMA cycles are required to access it. LDMA transfers are implemented using cycle-stealing from the CryptIC 's internal DSP processor. Note that the CryptIC supports optional memory locking of lkword slices of DM or PM. Any locked areas of memory are not visible to a Host via the LDMA port. TypicaUy, the locking of these memory spaces is performed by a custom 'Extended' program invoked via the CGX Kernel interface.
  • DM Internal Data Memory
  • PM Internal Program Memory
  • the External Memory Interface (EMI) bus is a logical extension to the EMI bus presented on a standard ADSP 218x processor.
  • the CryptIC has enhanced this bus as foUows: • Extended data bus width from 8 / 16 / 24-bits to 8 / 16 / 24 / 32-bits
  • the EMI interface can support multiple memory types, including I/O, Program Memory (PM), Byte Memory (BM), and 16-bit or 32-bit Data Memory (DM).
  • I/O Program Memory
  • BM Byte Memory
  • DM 16-bit or 32-bit Data Memory
  • a control register is used to select which bus controUer 'owns' the EMI bus.
  • the CryptIC integrates a high-performance 32-bit DMA controller in order to faciUtate bulk data movements within the chip without requiring continuous DSP supervision.
  • the DMA subsystem aUows 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.
  • 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).
  • a DSP-controlled register output bit 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.
  • DSP Initiated Transfers are 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.
  • the DSP 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 poUed for completion, or an interrupt may be generated at the end of the transfer.
  • Case 3 is a memory-to-memory type transfer.
  • 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 sUghtly different addressing techniques as shown below.
  • bit #14 in the Command register is set to T. Then, the 26-bit external memory address is specified in the Host Address register.
  • Figure 8 is a flow chart showing the steps which are typically followed for a DSP-initiated Master transfer. Code Samples
  • 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.
  • the DSP is the destination.
  • 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 will 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.
  • the DMA controller 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-suppUed addresses and other bus control signals and then generates the appropriate addresses for internal/external memory space.
  • the DMA controller may 'fetch-ahead' two or three dwords and place them in the PCI core's read FLFO. This is important to consider when performing reads from the Hash Encrypt FLFO, since once data is read from the H/E 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 FLFOs 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.
  • 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:
  • DMA Register 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 running 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.
  • PCIHAL PCI Host Address Low Register
  • This 16-bit Read/Write register aUows 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 byte address.
  • PCfflAH PCI Host Address High Register
  • This 16-bit Read/Write register aUows 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 table below. Note that this is a byte address.
  • PCfflAL PCI Local Address Low Register
  • This 16-bit Read/Write register allows the DSP Software to configure the lower 16 bits of Local ⁇ CryptIC) Address for a PCI Master transaction, as shown in the table below. Note that this is a 16-bit word address.
  • PCIHAH PCI Local Address High Register
  • PCIC PCI Command Register
  • This 16-bit Read/Write register is used by the DSP to write Commands to the DMA ControUer 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.
  • This 16-bit Read/Write register as shown in the table below, aUows 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. AU 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).
  • Bit 5 set to 1 is a further qualifier on Bit 3 (i.e. bit 3 wiU also be set): It indicates that the transaction is for case 3.
  • Bits 12-14 provide PCI core status to the DSP:
  • 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
  • PCI Core Status/Configuration Register PCI Core Status/Configuration Register
  • This 16-bit Read/Write register as shown in the table below, aUows the DSP to configure and momtor the PCI Core function. This register is not normaUy accessed for most appUcations.
  • the first 7 bits aUow the DSP to terminate PCI transfers under abnormal circumstances.
  • the last 8 bits provide real-time visibiUty of PCI core operation status.
  • Target Force Retry Target Force Abort Target Transmit FIFO Flush Target Receive FTFO Flush > Control (R W) Master Transmit FIFO Flush Master Receive FIFO Flush
  • Target Transmit FIFO Write ⁇ Target Transmit FIFO Full Target Receive FIFO Read Target Receive FIFO Empty Status Master Transmit FIFO Wnte (R O) Master Transmit FIFO Full Master Receive FIFO Read
  • This 16-bit Read only register 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 initiaUzed to the number of words in the transfer and wiU decrement down to 0. Bit 8 indicates if the External Memory bus is in use by the DMA engine.
  • Register Address READ
  • Target Page Register 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.
  • Target Read Count Register (TARGRDCNT)
  • This register 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 wiU be available in the PCI core read FIFO to complete the transaction. 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 FLFO, and 8 bytes are pre-fetched, then data will be lost. For Target reads of the FLFOs, this register should be programmed with the size of the transfer.
  • This register specifies the 'Endianness' of data transfers between the PCI bus and the CryptIC.
  • the DSP is Uttle-endian, so if it is communicating with a big-endian Host, then byte swapping is needed. Setting a 1 in this register wttl 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 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 foUowing 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 and encryption on the same data stream.
  • the DES encrypt/decrypt operations are highly paralleled and pipeUned, and execute full 16-round DES in only 4 clock cycles.
  • the internal data flow and buffering aUows paraUel execution of hashing and encryption where possible, and allows processing of data concurrently with I/O of previous and subsequent blocks. Context switching is optimized to minimize the overhead of changing cryptographic keys to near zero.
  • the 'software' interface to the module consists of a set of memory-mapped registers, 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 Padding 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 indefinitely until the end of data is encountered.
  • 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 wiU 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.
  • Each context contains a DES or Triple DES key, Initialization Vector (IV), and pre-computed hashes (inner and outer) of the Authentication key for HMAC operations.
  • the contexts also contain registers to reload the byte count from a previous operation (which is part of the hashing context), as weU as an IV (also called 'salt') for decrypting a Black key, if necessary.
  • Output from the encryption block is read from the data output FLFO.
  • the data is also automaticaUy passed to the hashing data FLFO.
  • Output from 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 IN produced at the end, which can be saved away and restored later to continue the operation with more data.
  • a feature is available that avoids the need to generate and load random IN's for outgoing (encrypted) packets.
  • the operating sequence for this feature is as foUows: 1) For the first encrypted packet after the CryptIC is initialized, two random numbers should be generated and written to each context's IV register. (This can actuaUy be done as part of the CryptIC boot process.)
  • Control bit 0 in the Hash/Encrypt Control register is set to a J ' in order to prevent subsequent software overwriting of the IV field in the two context registers.
  • the IV register in the active context will contain the last 8 bytes of ciphertext. This 'random' value wiU remain in the IV register and not be overwritten when the context for the next packet is loaded. (This technique is fully compUant with the LPsec standards.)
  • the IV is typically expUcitly included with the incoming packet.
  • 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 T.
  • the encrypt module can be configured to automaticaUy append pad bytes.
  • the padding is constructed, which are specified using the pad control word of the operation description. Options include zero padding, pad- length character padding (PKCS #7), incrementing count, with trailing pad length and next header byte (for LPsec), or fixed character padding. Note that for the LPsec and PKCS#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.
  • padding is automaticaUy added as specified in the MD-5 and SHA-1 standards.
  • the algorithm-specified padding bits are added to the end of the hash input buffer prior to computing the hash.
  • Certain security protocols including LPsec, require portions of a data packet to be Hashed whUe the remainder of the data is both hashed and encrypted.
  • the CryptIC supports this requirement through the OFFSET register which aUows specifying the number of 32-bit dwords of offset between the hash and encrypt operations.
  • 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 wiU be decrypted immediately after it is writteninto 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 FV for decrypting the Black secret key is caUed '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.
  • 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.
  • the Key Encryption Key (KEK) for key decryption is loaded via the Secure Kernel firmware using one of the CGX Key Manipulation 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 configuration bits specifies whether Red (Plaintext) keys are aUowed to be loaded into the CryptIC 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 Umit the key length which may be used or where the external storage environment 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").
  • FLPS 140-1 may require the use of 'black key' to protect key material.
  • the Security Boundary does not enclose the database where keys are stored, then those keys must be protected from compromise. Black key is a satisfactory way to meet this FLPS requirement.
  • the foUowing sections provide details on the operation of the Hash/Encrypt block of the CryptIC
  • the FLFO is implemented as a circular buffer, where the processed data is written back to the same location it came from.
  • the optimum transfer size is 256-bits (32 bytes) which provides the most efficient 'pipeUning'. This aUows 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.
  • the CryptIC DES/3-DES engine can perform any of the standard DES modes: ECB, CBC, OFB, CFB in either Single-DES or Triple-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 CryptIC). The mode of DES operation is selected in the HECNTL register at the same time as an Encrypt/Decrypt operation is started.
  • 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 CryptIC
  • Cipher Feedback mode For Cipher Feedback mode, one of three feedback choices is available: 64- bit, 8-bit, or 1-bit.
  • 64-bit CFB data is written to the input FIFO in the same manner as for aU other modes.
  • nuU bytes must be written to the data FIFO in order to aUgn the desired byte or bit within the 8-byte DES output.
  • 8-bit CFB mode 7 nuU bytes must be written after each 'payload' byte is written to the input FLFO.
  • the Triple-DES (3DES) processing performed by the encrypt hardware employs the 'Owter ' 3DES algorithm (as opposed to 'Inner ' 3DES). This means that, for a given input block of 8-bytes, the DES engine is first run in Encrypt, then Decrypt, and finally again in Encrypt mode prior to any feedback or X ⁇ R operations. Inner 3DES performs feedback operations between 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.
  • the CryptIC supports the most commonly needed Padding functions in hardware.
  • the features include: • Generating and appending Pad bytes to the end of a Plaintext packet prior to encryption
  • Mode 0 Zero Pad
  • the Host simply insures that the end of the data to be encrypted falls on an 8-byte boundary by inserting Pad characters on its own, in which case the Hardware Padding engine wUl not add any bytes.
  • Pad Verify bit in the General Status register which checks for proper padding in Pad Modes 1 and 2. (Note that this bit is invaUd for all blocks read from the hash/encrypt FIFO except the last block to be processed.)
  • the Pad Verification operation checks the decrypted data for the correct Pad properties as specified in the selected Padding Mode (The Next Header byte value is not vaUdated for IPsec mode). If Pad Modes 0 or 3 are selected, the Pad Verify bit will always read 0.
  • the appUcation must always read-out the last block (8-bytes) of decrypted plaintext data if there is at least one user-payload byte in it.
  • the CryptIC can notify the appUcation of the number of Pad bytes (including Pad, Pad length, and Next Header if applicable) detected in the decrypted plaintext through the Pad Status registers (HEPADSTATO/1). A count of 0 to 9 can be reported.
  • 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 CryptIC and the application may command the CryptIC 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 wdl cause this discard to occur.
  • the hash processing section also has a 512-bit (64 byte) FLFO. This represents a single 512-bit input block to the hash algorithm.
  • the hash buffer is buffer is full, and the algorithm section is done processing previous data, the input block is immediately copied to the 512-bit algorithm working buffer, and the entire 512-bit FLFO buffer is available for data input again.
  • 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-context. To continue a previous operation, the 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.
  • 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' foUowing the last byte of data, and placing a 64-bit data length, expressed in terms of bits, at the end.
  • the same input data stream is internally buffered by both the hash and encryption sections, depending on the data flow of the operation selected.
  • 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.
  • 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 LP connection.
  • SA security association
  • 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 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.
  • PCI transfers can be done using PCI byte enables to begin and end the operation on arbitrary bytes within their respective double words.
  • PCI Master Mode When the on-chip DSP is used to setup the PCI transfers using PCI Master Mode, it has the capabiUty to control the byte enables by setting the starting offset and byte count.
  • PCI Target Mode transfers 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.
  • the enable signals are set in a register in another block and passed in as a two bit wide signal.
  • This capabiUty only appUes to I/O to the data FLFOs.
  • AU other registers assume fuU 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.
  • 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 Uttle endian. If big endian is selected, the module wUl 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. Hash/Encrypt Subsystem Notes
  • Final processing for hashing operations, and padding of a short trailing crypto block is initiated automaticaUy.
  • 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.
  • AU 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.
  • the KEK register must be loaded prior to loading either of the crypto contexts.
  • 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.
  • Table 6 Usts 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 PC17PCMCIA 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 aUgned to double word boundaries.
  • This 16-bit Read/Write register as shown in the table below, aUows selecting configuration settings for the Hash/Encrypt subsystem.
  • Register Address (READ / WRITE)
  • This 16-bit Write-Only register as shown in the table below, aUows the Software to command a discard of the last 8-byte block of decrypted data in the Hash/Encrypt output FLFO. This is typically used to avoid the bus bandwidth of transferring the Pad block back to host memory. Register Address (WRITE ONLY)
  • the Application Registers ⁇ AppRegs) subsystem provides a bi-directional maUbox faciUty between a Host and the CryptIC and also contains some misceUaneous configuration registers.
  • the mailbox is specificaUy designed to facilitate the transfer of CGX crypto commands back and forth between the CryptIC and the calling Host.
  • the AppRegs mailbox subsystem is designed to foUow 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 automaticaUy switches state so that the other entity is given 'ownership' of the maUbox. OptionaUy, 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 ⁇ nd-of-Message' sequence. (By using the least- significant word for termination, any length of message from 1 to 44 bytes can be supported.)
  • 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.
  • 16-bit address refers to the DSP and 32-bit address refers to PCI/PCMCIA host.
  • the least significant word of this register has special properties.
  • the Isword When written by the DSP, the Isword 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' mterrupt to be issued to the DSP processor (if enabled).
  • writing the least-significant word wiU cause the ownership of the mailbox to automatically flip to the other party.
  • the maUbox appears as 11 consecutive 32-bit locations which are byte-addressable, as shown in the table below:
  • This 16-bit Read-only register as shown in the table below, aUows the DSP Software to monitor the status of the MaUbox.
  • Bit #1 Host has read Mailbox, allows the DSP to monitor when the Host processor has received a transmitted message in the MaUbox. Bit 1 wiU be latched as a T when the Host has read the least significant data byte of the Mailbox. As soon as the DSP reads DSPAPPSTAT, this bit will automaticaUy be cleared and re-armed for the next Host MaUbox read.
  • Bits #2 & 3 are read-only status bits which reflect the semaphores written (and read) in the DSPSEMA and HOSTSEMA registers.
  • This Read-only register as shown in the table below, aUows the Host Software to monitor the status of the Mailbox. Bit #0, Mailbox Write Own, aUows the Host to determine who may next write into the
  • Bit #1 DSP has read Mailbox, aUows the Host to monitor when the DSP processor has received a transmitted message in the Mailbox. Bit 1 will be latched as a T when the DSP has read the least significant data byte of the Mailbox. As soon as the Host reads HOSTAPPSTAT, this bit wiU automatically be cleared and re-armed for the next
  • Bits #2 & 3 are read-only status bits which reflect the semaphores written (and read) in the DSPSEMA and HOSTSEMA registers. Regisl er Address (READ ONLY"
  • This 16-bit Read/Write register as shown in the table below, aUows the DSP to lock-out Host write access to the Command/Response register. Setting this register to 0x01 effectively makes the MaUbox one-way from the DSP to the Host.
  • this register is read-only.
  • this 16-bi, Read/Write register allows the DSP Software to assert a semaphore bi, to be read by the Host via the AppRegsStatus register.
  • the lsb of this 32-bit Read/Write register aUows 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 arb i trat i on of the Hash/Encrypt subsystem.
  • the appropriate CIS initialization bit must be set when calling the CGX NIT routine Refer to the CGX Software Users Guide for more detaUs on the behavior of this function.
  • Hash/Encrypt Byte Enable Register (HEBYTEEN)
  • This 16-bit Read/Write register as shown in the table below, aUows 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.
  • This 16-bit Read/Write register as shown in the table below, aUows 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 CryptIC reset (although of course, not across a power-cycle.) This is useful in de-bugging software which is written for the User Mode of the CryptIC 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 foUows:
  • PM Instruction Fetch An instruction fetch was made either to one of the four blocks of Kernel ROM (i.e. the 4 lsb's of PMOVLAY were set to OxC, D, E or F and a fetch was made between address 0x2000 and 0x3FFF), or to an internal program memory (PM) location which has been locked-in 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 locked-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 program memory
  • EXMEMCFG External Memory Configuration Register
  • This 16-bit Read/Write register as shown in the table below, aUows selecting configuration settings for the external memory subsystem. Bit 0 configures the nature of the external memory bus. It should normaUy 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.
  • aUow 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.
  • 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 controUer (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 aUows PCI Target mode transfers to occur to ExtMem (since a Target transfer cannot always be predicted by the DSP).
  • the CryptIC enhances the existing Interrupt controUer within the ADSP 2183 DSP with some additional functions related to the Crypto functional blocks and the external Host bus interfaces. Two additional Interrupt ControUer subsystems have been added to the basic 2183 Interrupt Controller as shown in Figure 10.
  • the DIMASK register provides the Mask to select which interrupt source is enabled.
  • the Host Interrupt Controller aUows programming between 1 and 4 sources for the HostlntO interrupt output signal (which may be connected to the interrupt input of the Host system).
  • the ELLMASK register provides the mask to select which interrupt source is enabled.
  • the Interrupt Control and Status Registers 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.
  • This 16-bit Read-Only register provides interrupt status visibiUty to the DSP, prior to the interrupt mask being applied.
  • the DSP can view all potential sources of incoming mterrupt. AU of these sources, whether masked in or out, wiU be latched in this register and must be cleared using the DICLR register in order to view a subsequent interrupt.
  • This 16-bit Read-Only register provides Interrupt Status visibiUty to the DSP, after the Interrupt Mask is appUed. This lets the DSP view the selected sources of Interrupts which are directed to LRQ2. (Note that the DSP must enable LRQ2 via the LMASK register and the global ENA LNTS command must be issued in order to actuaUy receive the interrupt.) As with the Unmasked status register, all interrupt bits are latched and must be cleared using the DSP Clear Interrupt register.
  • DICLR DSP Clear Interrupt Register
  • This 16-bit Write-Only register aUows the Processor to Clear pending Interrupts. It is located at the same address as the Masked Status Register (Write vs. Read) which facUitates performing a read to detect pending interrupts foUowed by a write of the same bits in order to clear the latched interrupt status.
  • DMASK DSP Mask Control Register
  • This 16-bit Read Write register as shown in the table below, aUows configuring the Interrupt Masks for the Crypto subsystem.
  • Re ister Address (READ / WRITE)
  • This 16-bit Read/Write register as shown in the table below, aUows configuring the Interrupt type which wiU be fed into the LRQ2 interrupt Une of the CryptIC 's DSP. Note that this only effects the final output of the Interrupt subsystem.
  • This 16-bit Write-Only register as shown in the table below, aUows the DSP Software to Force a Crypto subsystem Interrupt to the external Host processor. 1 he data contents of the Write operation are ignored - any Write to this address wUl cause an interrupt, if enabled by the HIMASK register.
  • DSP DSP or Host H/E Errors Register
  • This 32-bit Read/Write register provides the error code which resulted in a H/E Error interrupt. Reading a T in a bit position within this register indicates the type of error which occurred. In order to clear the error latch, O's should be written to the desired bit positions.
  • Register Address (READ/WRITE)
  • This 32-bit Read-Only register provides interrupt status visibiUty to the Host, prior to the interrupt mask being appUed. Thus, the Host can view aU potential sources of incoming interrupt. AU 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.
  • This 32-bit Read-Only register provides Interrupt Status visibiUty 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 mterrupt bits are latched and must be cleared using the Host Clear Interrupt register.
  • HICLR Host Clear Interrupt Register
  • This 32-bit Write-Only register allows the Host to Clear pending Interrupts. It is located at the same address as the Masked Status Register (Write vs. Read) which facUitates performing a read to detect pending interrupts foUowed by a write of the same bits in order to clear the latched interrupt status.
  • This 32-bit Read/Write register as shown in the table below, aUows configuring the Interrupt Masks for the Crypto subsystem.
  • Register Address (READ / TTE)
  • HCFG Host Interrupt Configuration Register
  • This 32-bit Read/Write register as shown in the table below, aUows configuring the Interrupt type which wiU be fed to the PF7 interrupt line out of the CryptIC Note that this only effects the final output of the Interrupt subsystem.
  • HPFRC Force Host Interrupt Register
  • This 32-bit Write-Only register allows the Host Software to Force a Crypto subsystem Interrupt to the DSP processor.
  • the data contents of the Write operation are ignored - any Write to this address wiU cause an interrupt, if enabled by the DIMASK register.
  • 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.
  • 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-volatUe storage of a relatively smaU 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 CryptIC and can only be controlled by the DSP, there is a certain amount of intrinsic protection to this data store.
  • the PCI configuration parameters occupy the first 13 locations of the EEPROM, leaving 243 bytes remaining for user-specific applications.
  • the CIS configuration parameters occupy the first TBD locations of the EEPROM, leaving TBD bytes remaining for user-specific appUcations.
  • serial EEPROM In order for user appUcations 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).
  • SK Serial Clock
  • DI Data In
  • DO Data Out
  • CS Chip Select
  • 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 foUows: 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 Control Registers consist of 14 registers which allow the DSP to directly configure the PCI or PCMCIA configuration registers.
  • the last register, the Command/Status register allows general control of the serial EEPROM interface.
  • This 16-bit Read/Write register 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 AUows the DSP to shut-off the automatic hardware state machine which attempts to automaticaUy 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 attemptmg to load the configuration from the EEPROM into the bus core. It must be a 0 to enable 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 T must be written to the Stop EEPROM State Machine [bit 1] of this register.
  • the CryptIC provides multiple modes of boot-loading it operating software. Nirtually all implementations of the CryptIC 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:
  • the CryptIC may also be bootloaded via the Host processor bus interface.
  • the procedure is slightly different, depending on which bus mode is selected. PCI Bus Booting
  • 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.
  • 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 CryptIC s internal PM memory space. Downloading occurs by using Target mode LDMA writes into the internal PM space. See section PCI Address Map described previously for additional information.
  • the foUowing table is a Ust of terms used with the description of the co-processor.
  • BLACK Key A secret/private key that is encrypted or covered by a KEK, it can be securely given to another party.
  • KCR Key Cache Register
  • KRAM Key RAM
  • LSV Local Storage Vanable
  • PCDB secure Kernel features
  • RED Key A secret/private key that is not encrypted or covered by another KEK. It is in its raw unprotected form.
  • the foUowing is a detaUed 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. (LRE). 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 foUowing includes a detailed description for software developers intending to use the CGX Ubrary embedded in the CryptIC . 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 AJDSP-2100 family
  • the CryptIC device is designed to be a highly integrated, general purpose
  • DSP Digital Signal Processor
  • 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 approximately 40 functions which are avaUable to AppUcations which require security services.
  • a protection model is buUt into the DSP so that security-related and real-time intensive appUcations can coexist.
  • the DSP can either be operating in 'Kernel Mode ' which means that one of the CGX commands is in process or it can be in ' User Mode ' which means that a user appUcation is running.
  • Kernel Mode aU of the CryptIC resources are available to the CGX firmware.
  • User Mode access to Key Storage locations and many of the Security Blocks is restricted in order to enforce proper security poUcy.
  • a degree of multi-tasking can be achieved between User and Kernel processes, and Kernel Mode processing can be interrupted by User code.
  • a subset of the CGX commands may be preempted by another CGX command.
  • an Application Programming Interface is provided to the CGX Kernel.
  • CGX 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 appUcation or worrying about what resources the appUcation 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 is the same for both views; the difference is in how the application utilizes the CGX interface.
  • the CGX interface appears as a 21 -word register set (the command block) which is mapped into an appUcation-specified memory space in the CryptIC.
  • This is simUar to the concept of the MMX (Multi- Media 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.
  • both hardware and software components are integrated on the CryptIC
  • 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 extemal world.
  • the CryptIC 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.
  • CGX command Interface as an API to access the CGX command set.
  • 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 hardware resources.
  • the appUcation In order to access the cryptographic services, the appUcation must invoke the command interface and pass-in a command code and arguments.
  • the appUcation running in the User space of the DSP can implement anything from a router security co-processor to a N.34 modem data pump.
  • Residing as part of the appUcation layer are the macro functions which LRE provides in its cgx.h file. These macros assist the appUcation in preparing the command messages prior to calling the CGX kemel.
  • the CGX command interface layer is an Application Programming Interface
  • the CGX command interface provides the hardware mechanism to enter and exit the CGX Kemel to execute a specific cryptographic command.
  • Part of the command interface function invokes the kemel protection logic to isolate the CGX Kemel and its associated security resources from the extemal application via the Kemel Protection
  • the software interface to the CGX Kemel 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 Kemel (i.e. is it active or idle) and a means to determine the result status of a requested cryptographic service.
  • CGX Command Processor Layer CGX Command Processor Layer
  • the CGX Command Processor implements a secure Operating System responsible for processing application requests for various cryptographic services.
  • 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 Management Once the CGX Command Processor is activated via the caU 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 Kemel 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 function 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.
  • the Command Processor can aUow 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 miUiseconds to complete. However, if a preemptive request comes in and the CGX Kemel is not executing one of the preemptable commands, the CGX Command Processor wiU return a CGX_BUSY_S status code and wiU not execute the command.
  • 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 wiU not give control of the DSP to the appUcation 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 expUcitly 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.
  • the CGX overlay layer is provided as the interface into LRE's CryptoLLB software.
  • the CryptoLLB software is a Ubrary 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 CryptIC platform unmodified.
  • Figure 13 illustrates the data flow through the CGX overlay layer.
  • the CGX overlay operation is responsible for extracting the arguments from the kernel block and invoking the proper CryptoLLB operations.
  • the CGX overlay operation may invoke several CryptoLLB operations. In effect, this is an object- oriented approach where the CGX overlay class is the parent class to the CryptoLIB classes.
  • the CryptoLIB layer contains LRE's Crypto Library software and it also contains drivers for the CryptIC hardware blocks as weU as 'soft' versions of the hardware algorithms (the soft versions are ifdef ed out at compUe time for the
  • the CryptoLIB software is a Ubrary of many cryptographic classes implementing various cryptographic algorithms from symmetrical encryption algorithms to one-way Hash functions, to public key operations.
  • the CryptoLIB 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 CryptoLIB software. This provides several advantages including:
  • the CryptoLIB software can be independently used in the PC environment
  • the CGX Command Processor is made up of many software components:
  • the foUowing sub-sections describe the components that make up the CGX Command Processor.
  • FuU-Init occurs when the appUcation issues the CGX_LNIT command to the CGX kemel.
  • Basic-Init is a safety net which will be automatically run if a CGX command is issued prior to the FuU-Init being run.
  • the Full-Init actuaUy executes the Basic-Init processing, but in addition provides some Kemel and Hardware configuration capability.
  • the appUcation may supply a Kemel Configuration String (KCS) and/or a Program Control Data Bits (PCDB) configuration string in order to modify the behavior of the CGX kemel and the hardware functions of the CryptIC
  • KCS Kemel Configuration String
  • PCDB Program Control Data Bits
  • the first CGX command is executed, passing control to the CGX Kemel.
  • the CGX Kemel When the CGX Kemel 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 Kemel reads the INIT flag, which is a 32-bit location in Kemel RAM. This flag represent the initialization state of the CGX kemel: If the flag is set to a pre-determined value, then it is an indication that the kemel 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.
  • the INIT flag which is a 32-bit location in Kemel RAM. This flag represent the initialization state of the CGX kemel: If the flag is set to a pre-determined value, then it is an indication that the kemel 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
  • the kemel wiU assume that it first has to perform Basic-Init processing. Note that it is normally expected that the appUcation will first execute the
  • the CGX Kemel If the CGX Kemel 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 Kemel sets the INIT flag, assuming the self-tests pass. From this point on, untU the next power-cycle, the INIT flag will indicate that the kemel has been initiaUzed and the CGX Kemel will not re-execute the startup self-tests.
  • the CGX Kemel executes a set of self- tests to check the integrity of its ROM (using a pre-calculated MAC) Kemel RAM, and associated security devices (i.e. RNG). If any of these self-tests fail, the CGX Kemel returns a faUure code (ie. CGX_RAM_FAIL_S)to the application via the status field of the kernel block and does not set the LNIT flag. Furthermore, it wiU not execute any command until the self-tests pass and the LNLT flag is written with a vaUd value.
  • a faUure code ie. CGX_RAM_FAIL_S
  • the CGX Kemel 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 Kemel will proceed to process the original requested CGX command.
  • the initialization mode can be reentered by the appUcation by using the CGX_LNLT command.
  • the application must pass in two initialization strings, the PCDB string and the Kemel 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 Kemel
  • the CGX Kemel enters an idle mode and returns to the caller, waiting to service application requested CGX commands received across the command interface.
  • the initialization routine must clear the PM_Reserve and DM_Reserve registers. These are two 16-bit registers for which each bit represents a IK memory block of internal PM or DM memory. A bit set to T indicates that the corresponding Ik memory block has been locked into use by the CGX Kemel and cannot be accessed in user mode.
  • PCDB Programmable Control Data Bits
  • the PCDBs are laser-programmed at the factory with a set of defaults and may later be changed by the appUcation via a special unlock-data token that LRE or a designated OEM can provide.
  • the end-user can use an unlock-data token provided by LRE to later enable/disable various features via the initialize command (i.e. CGX_LNIT).
  • CGX_LNIT the initialize command
  • 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_LNIT command, the application can re-program some of the RAM shadowed PCDB bits, providing a digitally-signed token is presented along with the request.
  • the appUcation 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.
  • KCS Kernal Comfiguration String
  • the CGX Kemel is preemptive, and for certain commands it is also reentrant. Being preemptive means that if an interrupt occurs while the CGX Kemel 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 Kemel is resumed via the apphcation' s Retum From Interrupt (RTI) instruction; thus the preempted CGX operation is continued.
  • ISR interrupt service routine
  • RTI Retum From Interrupt
  • CGX commands ie. public key and digital signature
  • the CGX Kemel firmware maintains two stacks and workspaces in order to aUow 1 level of preemption/reentrance.
  • the CGX commands are shown in the table below.
  • a simple contention management scheme is avaUable to the application. Contention management is necessary in order to prevent the application from attempting to re- enter the CGX Kemel whUe it is in a preempted state. This is a simple problem from the stand-point of the CGX Kemel because intemaUy 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 nd CGX command.
  • the status of the CGX Kemel i.e.
  • the appUcation can be queried by the appUcation at any time.
  • the state can be obtained by looking at the current status block in DSP internal or extemal memory (the status block is part of the kernel block, as explained later).
  • This scheme has three advantages: First, the application does not have to invoke a command to query the state of the CGX Kemel, 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 Kemel to retrieve the status result of the CGX operation (success or error code) which can be used by the appUcation to debug/test the cryptographic operations.
  • 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).
  • the application code can be designed to ran 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 intermpt and retum-from-intermpt.
  • the extemal interrupt service restores the CGX Kemel context and invokes the RTI operation.
  • the Status registers and Program Counter are automaticaUy popped off the hardware stack at the RTI instruction.
  • 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 Kernel's KRAM, the volatUe Key Cache Registers, and the PM/DM_Reserve RAM blocks.
  • the CGX Command Processor to fuUy 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 speciaUzed hardware, the CGX Command Processor uses critical regions (interrupts disabled) to protect registers. For example, when key material is moved in or out of the Kemel 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 Kemel via intermpts. Although the apphcation can not read the protected KRAM and kemel 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 intermpts disabled, and at the end it sets the registers it used to 0. This prevents applications from single stepping the Kemel. The same is done to the pm_cpy operation which is used to read program memory.
  • the hardware provides key aspects to protecting various memory stores.
  • the hardware provides several bus transceivers to only aUow one memory to be accessed at a time. So that when the extemal RAM/ROM is accessed the extemal application can not read any of the CGX Kernel's internal memory (KRAM, kemel ROM, and extended RAM/ROM).
  • the bus transceivers are placed on some of the security block memory devices in order to prevent the CGX Kemel from accidentally mixing Red key material with other memory devices used by the CGX Kemel. The following sub-sections outline the areas where the CGX Kemel enforces the security model. Volatile Key Storage
  • the volatUe key storage houses the private portion of a pubUc key in the pubUc key area and a fixed number of secret keys in the Key Cache Register (KCR) area.
  • the volatUe key area is also referred to as the actively working keys.
  • AU cryptographic commands operate only on the active volatile working keys.
  • the appUcation is responsible for moving keys between the outside world and the KCRs.
  • the CGX Command Processor only aUocates enough space in the volatUe 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 ED with numbers from 0 through 14.
  • one or more lkword segments of PM and/or DM memory can be locked-into the kemel space.
  • the appUcation 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 DM_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.
  • 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 Kemel is accompUshed using a shared memory block and a special transfer address mechanism.
  • the shared memory block ⁇ kernel block provides the means for the appUcation to communicate with the CGX Kemel, allowing the application the ability to query the CGX Kernel's status and request cryptographic services.
  • the special transfer mechanism (CGX Kemel transfer routine) allows the appUcation to invoke the CGX Kemel.
  • the command interface is described in detaU in the section Command Interface.
  • the CGX Command Processor is simUar to a command interpreter; it consumes the command and its arguments, invokes the proper service to execute the command, and returns the result.
  • the CGX Command Processor is a Uttle 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 momtor 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.
  • the CGX Kemel is entered by setting the PMOVLAY register to OxOOOF and then executing a CALL
  • the internally ROM encoded CGX Kemel program block is overlaid in the upper portion of the DSP's program space. This allows the CGX Kemel code to become active and transparent to the application.
  • the processor immediately branches to the CGX Command
  • 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 aU intermpts disabled upon entry. The interrupts remain disabled for just for the entry code, until a point at which the CGX kemel has verified that it can perform the operation and has saved the application's context.
  • the CGX Command Processor sets up a second local stack to execute from, (i.e. it is now being preempted) it saves the context of the externally mnning application (i.e. saves registers, the PC retum 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_RUNNLNG_S code to the extemal status block (i.e. the CGX Command Processor is active), reenables interrupts, and calls the cryptographic command interpreter (described in the next subsection).
  • 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 iUustrates 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 Kemel. This aUows the lowest level, the CryptoLIB to only have to implement cryptographic operations.
  • a middle layer called the CGX overlay is provided. The middle layer actually implements the wrap code around the cryptographic Ubrary, enabling memory, accessing the key RAM, etc..
  • the overlay operation is responsible for invoking the CryptoLIB 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.
  • the overlay operations which are actually CGX Kemel operations, are responsible for enabling write access to extemal RAM and for updating the status field of the status block. This isolates the control of the sensitive hardware access features to the CGX Kemel only.
  • the exit handler of the CGX Command Processor performs the following:
  • the write access enable to extemal RAM is disabled before returning to the appUcation.
  • the purpose of the overlay operations is two fold: first, it provides a standardized interface to LRE's CryptoLIB.
  • the overlay operations contain some wrap code and caUs 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.
  • 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.
  • the CryptoLIB software is a Ubrary of software functions that implement a full suite of cryptographic services. It is designed to be portable and flexible and the interface aUows 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 Ubrary base can be used in desktop environments as well as embedded applications like the CryptIC Therefore, since no special modifications to the CryptoLIB have been made, the CGX Kemel is recognized as another application to the CryptoLIB software.
  • the CGX Kemel uses the Ubrary caUs as would any other application in a PC environment or another embedded environment would. This has been accomplished because of the CryptoLLB 's ability to allow it to be customized by the application.
  • a number of CryptIC specific drivers are provided.
  • the drivers provided are:
  • 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 Kemel reset processing to verify the health of the security blocks. The following is a
  • This self-test checks the integrity of the CGX Kernel's program by mnning a MAC over its entire 32K program space and comparing the MAC to the ROM encoded MAC.
  • the CGX Kemel 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 appUcation, or a fatal error detected by the CGX Kemel.
  • 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 Kemel wiU reset the processor and the RESET state will be re-entered. At the successful completion of self-tests the CGX Kemel wUl transition to the
  • IDLE state The only other state the CGX Kemel can transition to is the RESET state.
  • the LDLE state can be transitioned to from either the COMMAND state or
  • the LDLE 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.
  • the CGX Kemel In the LDLE state the CGX Kemel is inactive, it is idly waiting for the application's request for the next cryptographic command.
  • the CGX Kemel Upon the request of a cryptographic command the CGX Kemel will transition to the RESET, COMMAND, or COMMAND_BLOCK state.
  • the CGX Kemel will transition to the RESET state if an invaUd kernel block is received.
  • the CGX Kernel wiU 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 COMMAND_BLOCK state.
  • the preemption bit is described in the section CGX Overlay Interface.
  • the COMMAND State can be transitioned to from either the
  • COMMAND_BLOCK state or LDLE state.
  • the COMMAND state is entered upon a request from the application of a cryptographic command; either back from preemption or an initial application request.
  • the CGX Kemel aUows the current cryptographic command to be preempted. However, only certain commands can be preempted and only certain commands can cause the preemption.
  • AU of the pubUc key and digital signature operations have the preemption bit set to a 0; thus aUowing them to be preempted and causing the CGX Kemel to enter the COMMAND state from the LDLE state.
  • a number of other CGX commands are aUowed to preempt the pubUc key and digital signature algorithms (see section 0).
  • the CGX Kemel only aUows one level deep of preemption. Therefore, upon preemption the CGX Kemel transitions into the COMMAND_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.
  • the CGX Kemel transitions back to the LDLE state. However, if some sort of severe error or hardware failure occurred the CGX Kemel will reset the processor; thus transition to the RESET state.
  • the COMMAND_BLOCK state can be transitioned to from either the COMMAND state or LDLE 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.
  • the CGX Kemel will not allow the current cryptographic command to be preempted.
  • the CGX Kemel transitions back to the LDLE state if it was not previously entered due to preemption.
  • the CGX Kemel entered the COMMAND_BLOCK state because the appUcation requested a CGX command that caused an active CGX command to be preempted, the CGX Kemel will transition back into the COMMAND state to complete the original CGX command. However, if some sort of severe error or hardware faUure occurred, the CGX Kemel wUl reset the processor; thus transitioning to the RESET state.
  • the CryptlC's features support a consistent flow of Key Material through all of the five phases.
  • the CryptlC's features support a consistent flow of Key Material through all of the five phases.
  • Key destmction may easily be achieved either by powering-off the CryptIC, or by executing a Destroy_Key CGX command.
  • the CryptIC allows a wide range of key management implementations, since it is only concerned with supplying the primitive key management utihties. This aUows the appUcation using the CryptIC to create either a simple 'flat' key management structure, or a highly layered and complex 'mUitary-grade' key management system.
  • the following sections describe the types of keys used on the CryptIC, the key handling and usage conventions, and finaUy a discussion of key storage requirements and definitions.
  • the CryptIC supports the foUowing algorithms and key sizes for Symmetric
  • Symmetric keys are used in order to support the symmetric cryptographic algorithms (i.e. DES, Triple DES).
  • the CryptIC supports several symmetric key types for data encryption and key encryption (covering/covering).
  • key length 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.
  • HMAC Message Authentication Code keys
  • 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 AU DEKs are stored hi and retrieved from volatile Key Cache Registers
  • KCRs or written to the encrypt hardware engine's context_0 or context_l data key register.
  • a DEK is not allowed to be exported (i.e. read by the application) unless it is covered by a key encryption key.
  • the DEK must be uncovered in the CryptIC device to be used as a traffic key.
  • a DEK can be generated via all the means described in the section Symmetric
  • 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.
  • CryptIC is not responsible for destroying DEKs since it doesn't know when a secure channel has terminated. This is left to the appUcation via the CGX_DESTROY_KEY command. However, the CGX Kemel wiU destroy all volatUe key cache locations upon a reset or protection violation.
  • KAKs Key Encryption Keys
  • a key encryption key (otherwise known as a covering key) aUows 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 CryptIC supports five types of KEKs:
  • LSN Local Storage Variable
  • GKEK internal Generator Key Encrypting Key
  • the LSN 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.
  • LSV Local Storage Variable
  • the LSV is a non- volatile 1 12-bit KEK which is laser-bumed 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.
  • Internal Generator KEK GKEK
  • the GKEKs effectively insulate the LSV from any direct attack, since GKEKs are always tmsted and cannot be imported or exported.
  • DKEKs are used exclusively to cover and uncover DEKs which wUl be used in the Hash Encrypt hardware engine. This KEK wiU 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.
  • RKEK is always a Diffie- HeUman derived key and requires an ERE-certified request to generate it. It may be off-loaded from the CryptIC covered by the LSV.
  • the RKEK is used for covering DEKs, KEKs, or DKEKs for escrowing off-chip or for Key Recovery implementations.
  • HMAC Keys are used for covering DEKs, KEKs, or DKEKs for escrowing off-chip or for Key Recovery implementations.
  • 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 input to an HMAC function.
  • HMAC keys may be from 40 to
  • 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 on the PCDB programming within the CryptIC (i.e. configured for domestic or export).
  • 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.
  • CryptIC defines triple DES keys as three 56 bit DES keys (i.e. 168 bits in total), however a triple DES key wiU actually occupy 192 bits (i.e. 24 bytes) since in DES, one bit of each key byte is considered a parity bit.
  • 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. 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 fuU 168-bits in a manner to reflect the number of bits chosen by the appUcation.
  • Symmetric keys can be generated six ways on the CryptIC as described in the table below:
  • 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 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. Untmsted software mnning in the 'User Mode' of the DSP does not have access to the KCRs.
  • KCRs Key Cache Registers
  • 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 wiU be either 8 or 24.
  • the keybits field is 192-bits long (three 64-bit DES keys). It contains the actual key bits which wiU be used by the DES or triple-DES algorithm. For single- DES, only 64-bits are used and the remaining 128-bits wiU be zero. The least significant bit of each byte is considered the DES parity bit and is ignored.
  • the weakened 'Jeybits field is 64-bits long and contains the 'original' bit values which were overwritten by O'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 CryptIC, 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.
  • the attributes field is a 16-bit value with the foUowing bit definitions, shown in the table below: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
  • 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 Untmsted and the import/export operation specifies the key type.
  • the extemal form consists of all of the original random key bits, salt bits, attributes, and SHA-1 message digest.
  • the entire extemal 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 extemal key once it is encrypted (in CBC mode).
  • E KEK indicates the encryption of the data in ⁇ by the specified KEK.
  • the secretkey object is 576 bits / 72 bytes / 18 dwords long. This contains the foUowing:
  • 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 aUows the secretkey object to faU 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.
  • the salt through message digest fields are encrypted by a KEK.
  • the encryption mode is typically CBC, although for untmsted 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 appUcation.
  • the CGX Kemel decrypts the key blob and mns 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).
  • the symmetric key When an appUcation chooses to exchange an ERE symmetric key with another crypto-vendor, the symmetric key must be converted from LRE's storage format into one that is more easUy extractable so that it can inter-operate with other crypto- vendors. (Note that keys which are exported from or imported to the CryptIC are always considered untrusted.)
  • EK indicates the encryption of the data in ⁇ by the specified KEK.
  • the appUcation can specify no salt, it can expUcitly 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 ERE extemal symmetric key formation.
  • a DES key wiU 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 appUcation desires.
  • the one to three pieces of extemal 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 ERE Extemal form are not included in this format.
  • 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 mle 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 th byte exported as a 0.
  • the salt bits (if present) can be as many bytes as the application chooses and the data bits (if present) can be as many bytes as the appUcation chooses.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)

Abstract

Une plate-forme de communications sécurisée sur un circuit intégré constitue un processeur à sécurité intégrée comprenant un processeur de signal numérique polyvalent (DSP), plusieurs éléments fonctionnels cryptographiques hautes performances, une interface PCI, et une interface PCMCIA. La plate-forme de communications sécurisée est intégrée à un processeur de signal numérique du commerce, de façon qu'un revendeur se préoccupant de traitement de signal numérique puisse également recevoir les fonctions de sécurité intégrée coopérant avec le processeur de signal numérique. Le circuit intégré comporte une bibliothèque consultable de commandes cryptographiques et d'algorithmes de cryptage. L'invention concerne également un processeur de cryptage opérant au niveau clé et données, ainsi qu'un processeur d'adressage calculé hautes performances et un accélérateur à clé publique.
PCT/US1998/019316 1997-09-16 1998-09-16 Coprocesseur cryptographique WO1999014881A2 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA002303297A CA2303297C (fr) 1997-09-16 1998-09-16 Coprocesseur cryptographique
AU10609/99A AU1060999A (en) 1997-09-16 1998-09-16 Cryptographic co-processor
EP98953170A EP1013026A4 (fr) 1997-09-16 1998-09-16 Coprocesseur cryptographique

Applications Claiming Priority (20)

Application Number Priority Date Filing Date Title
US5984297P 1997-09-16 1997-09-16
US5908297P 1997-09-16 1997-09-16
US5983997P 1997-09-16 1997-09-16
US5984697P 1997-09-16 1997-09-16
US5984397P 1997-09-16 1997-09-16
US5984097P 1997-09-16 1997-09-16
US5984197P 1997-09-16 1997-09-16
US5984497P 1997-09-16 1997-09-16
US5984597P 1997-09-16 1997-09-16
US5984797P 1997-09-16 1997-09-16
US60/059,839 1997-09-16
US60/059,840 1997-09-16
US60/059,845 1997-09-16
US60/059,843 1997-09-16
US60/059,842 1997-09-16
US60/059,841 1997-09-16
US60/059,847 1997-09-16
US60/059,846 1997-09-16
US60/059,844 1997-09-16
US60/059,082 1997-09-16

Publications (2)

Publication Number Publication Date
WO1999014881A2 true WO1999014881A2 (fr) 1999-03-25
WO1999014881A3 WO1999014881A3 (fr) 1999-07-22

Family

ID=27580864

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1998/019316 WO1999014881A2 (fr) 1997-09-16 1998-09-16 Coprocesseur cryptographique

Country Status (4)

Country Link
EP (1) EP1013026A4 (fr)
AU (1) AU1060999A (fr)
CA (3) CA2303297C (fr)
WO (1) WO1999014881A2 (fr)

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088800A (en) * 1998-02-27 2000-07-11 Mosaid Technologies, Incorporated Encryption processor with shared memory interconnect
EP1043860A2 (fr) * 1999-04-07 2000-10-11 Sony Corporation Dispositifs de sécurité, unités de mémoire, dispositifs de traitement de données et procédés de chiffrage de données
WO2000072500A2 (fr) * 1999-05-20 2000-11-30 Storage Technology Corporation Systeme et procede de chiffrement d'informations
EP1079581A2 (fr) * 1999-08-17 2001-02-28 Hewlett-Packard Company Chiffrage et déchiffrage fort de données en paquets à travers un réseau de communications
WO2001029652A2 (fr) * 1999-10-20 2001-04-26 Accelerated Encryption Processing Limited Accelerateur crytographique
EP1191736A2 (fr) 2000-09-25 2002-03-27 Broadcom Corporation Logique de cadrage d'un processeur pour le commerce électronique sécurisé
DE10056989A1 (de) * 2000-11-17 2002-05-23 Secware Technologies Ag Verschlüsselungssystem
WO2002101976A1 (fr) * 2001-06-13 2002-12-19 Corrent Corporation Antememoire de donnees securitaires
WO2002101977A1 (fr) * 2001-06-13 2002-12-19 Corrent Corporation Processeur et procede de chiffrement a passage unique
EP1292082A2 (fr) * 2001-07-24 2003-03-12 Cavium Networks Inc. Procédé et appareil permettant d'établir une session sécurisée
EP1310855A2 (fr) * 2001-11-09 2003-05-14 Lifescan, Inc. Système et procédé d'authentification de chaínes de données
US6591366B1 (en) * 1997-11-27 2003-07-08 Fujitsu Siemens Computer Gmbh Method and configuration for loading data for basic system routines of a data processing system
EP1447740A1 (fr) * 2003-02-11 2004-08-18 IP-First LLC Microprocesseur avec générateur de nombres aléatoires, dont la disponibilité dépend du résultat d'un autotest
US6871206B2 (en) 2001-11-20 2005-03-22 Ip-First, Llc Continuous multi-buffering random number generator
US6928162B1 (en) 2000-04-07 2005-08-09 International Business Machines Corporation Method and system for manipulating and telescoping a hash function
WO2005091109A1 (fr) * 2004-03-19 2005-09-29 Nokia Corporation Dispositif a coprocesseur cryptographique
US6965254B2 (en) 2002-12-10 2005-11-15 Ip-First, Llc Dynamic logic register
US7136991B2 (en) 2001-11-20 2006-11-14 Henry G Glenn Microprocessor including random number generator supporting operating system-independent multitasking operation
US7139785B2 (en) 2003-02-11 2006-11-21 Ip-First, Llc Apparatus and method for reducing sequential bit correlation in a random number generator
US7149764B2 (en) 2002-11-21 2006-12-12 Ip-First, Llc Random number generator bit string filter
US7165084B2 (en) 2002-11-20 2007-01-16 Ip-First, Llc. Microprocessor with selectivity available random number generator based on self-test result
US7173456B2 (en) 2002-12-10 2007-02-06 Ip-First, Llc Dynamic logic return-to-zero latching mechanism
US7249255B2 (en) 2001-06-13 2007-07-24 Corrent Corporation Apparatus and method for a hash processing system using multiple hash storage areas
EP1826694A2 (fr) * 2006-02-27 2007-08-29 Broadcom Corporation Procédé et système d'architecture, système sur une puce sécurisée pour le traitement de données multimédia
US7555121B2 (en) 2000-09-25 2009-06-30 Broadcom Corporation Methods and apparatus for implementing a cryptography engine
US7564976B2 (en) 2004-03-02 2009-07-21 International Business Machines Corporation System and method for performing security operations on network data
US20100067689A1 (en) * 2008-09-15 2010-03-18 Laffey Thomas M Computing platform with system key
US8468337B2 (en) 2004-03-02 2013-06-18 International Business Machines Corporation Secure data transfer over a network
KR101336278B1 (ko) 2012-09-19 2013-12-03 충북대학교 산학협력단 무선 센서 네트워크에서 데이터 보안을 위한 경량 해시 알고리즘
US9489318B2 (en) 2006-06-19 2016-11-08 Broadcom Corporation Method and system for accessing protected memory
US9652637B2 (en) 2005-05-23 2017-05-16 Avago Technologies General Ip (Singapore) Pte. Ltd. Method and system for allowing no code download in a code download scheme
US9860055B2 (en) 2006-03-22 2018-01-02 Synopsys, Inc. Flexible architecture for processing of large numbers and method therefor
EP3279826A1 (fr) * 2016-08-04 2018-02-07 Nagravision SA Vérification de séquence
US9904809B2 (en) 2006-02-27 2018-02-27 Avago Technologies General Ip (Singapore) Pte. Ltd. Method and system for multi-level security initialization and configuration
US10380007B2 (en) 2009-07-10 2019-08-13 Certicom Corp. System and method for managing electronic assets
WO2022125943A1 (fr) * 2020-12-11 2022-06-16 Nebulon, Inc. Distribution et mise à jour sécurisées de clés de chiffrement dans un système de stockage en grappe
WO2022126022A1 (fr) 2020-12-11 2022-06-16 Tethers Unlimited, Inc. Circuits cryptographiques intégrés dans des applications spatiales
CN114662082A (zh) * 2022-02-25 2022-06-24 荣耀终端有限公司 电子设备的访问控制方法、可读介质和电子设备
EP4276633A1 (fr) * 2022-05-13 2023-11-15 Thales Dis France SAS Dispositif semi-conducteur sécurisé et procédé

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102648471B (zh) 2008-11-24 2015-05-27 塞尔蒂卡姆公司 用于基于硬件的安全的系统和方法
MY155814A (en) 2009-07-10 2015-11-30 Certicom Corp System and method for performing serialization of devices
US20110010770A1 (en) * 2009-07-10 2011-01-13 Certicom Corp. System and method for performing key injection to devices
US11169935B2 (en) * 2018-06-20 2021-11-09 Intel Corporation Technologies for low-latency cryptography for processor-accelerator communication
US11263316B2 (en) * 2019-08-20 2022-03-01 Irdeto B.V. Securing software routines
US11347875B2 (en) 2020-01-28 2022-05-31 Intel Corporation Cryptographic separation of memory on device with use in DMA protection

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4987595A (en) * 1989-09-11 1991-01-22 Motorola, Inc. Secure cryptographic processor arrangement
US5557346A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for key escrow encryption
US5623545A (en) * 1995-08-31 1997-04-22 National Semiconductor Corporation Automatic data generation for self-test of cryptographic hash algorithms in personal security devices
US5631960A (en) * 1995-08-31 1997-05-20 National Semiconductor Corporation Autotest of encryption algorithms in embedded secure encryption devices
US5721777A (en) * 1994-12-29 1998-02-24 Lucent Technologies Inc. Escrow key management system for accessing encrypted data with portable cryptographic modules

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3827029A (en) * 1972-09-25 1974-07-30 Westinghouse Electric Corp Memory and program protection system for a digital computer system
US4914697A (en) * 1988-02-01 1990-04-03 Motorola, Inc. Cryptographic method and apparatus with electronically redefinable algorithm
JPH01237785A (ja) * 1988-03-18 1989-09-22 Canon Inc 電子機器
US5073934A (en) * 1990-10-24 1991-12-17 International Business Machines Corporation Method and apparatus for controlling the use of a public key, based on the level of import integrity for the key
GB2294140B (en) * 1992-05-29 1996-11-27 Toshiba Kk Data processing apparatus
JP3520102B2 (ja) * 1993-12-28 2004-04-19 株式会社東芝 マイクロコンピュータ
US5577213A (en) * 1994-06-03 1996-11-19 At&T Global Information Solutions Company Multi-device adapter card for computer
US5530753A (en) * 1994-08-15 1996-06-25 International Business Machines Corporation Methods and apparatus for secure hardware configuration
US5764969A (en) * 1995-02-10 1998-06-09 International Business Machines Corporation Method and system for enhanced management operation utilizing intermixed user level and supervisory level instructions with partial concept synchronization
IL113259A (en) * 1995-04-05 2001-03-19 Diversinet Corp A device and method for a secure interface for secure communication and data transfer
CA2242777A1 (fr) * 1996-01-10 1997-07-17 John Griffits Systeme a la carte securise pour logiciels d'ordinateur

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4987595A (en) * 1989-09-11 1991-01-22 Motorola, Inc. Secure cryptographic processor arrangement
US5557346A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for key escrow encryption
US5721777A (en) * 1994-12-29 1998-02-24 Lucent Technologies Inc. Escrow key management system for accessing encrypted data with portable cryptographic modules
US5623545A (en) * 1995-08-31 1997-04-22 National Semiconductor Corporation Automatic data generation for self-test of cryptographic hash algorithms in personal security devices
US5631960A (en) * 1995-08-31 1997-05-20 National Semiconductor Corporation Autotest of encryption algorithms in embedded secure encryption devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1013026A2 *

Cited By (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6591366B1 (en) * 1997-11-27 2003-07-08 Fujitsu Siemens Computer Gmbh Method and configuration for loading data for basic system routines of a data processing system
US6088800A (en) * 1998-02-27 2000-07-11 Mosaid Technologies, Incorporated Encryption processor with shared memory interconnect
US6434699B1 (en) 1998-02-27 2002-08-13 Mosaid Technologies Inc. Encryption processor with shared memory interconnect
USRE44697E1 (en) 1998-02-27 2014-01-07 Mosaid Technologies Incorporated Encryption processor with shared memory interconnect
EP1043860A2 (fr) * 1999-04-07 2000-10-11 Sony Corporation Dispositifs de sécurité, unités de mémoire, dispositifs de traitement de données et procédés de chiffrage de données
US7124436B2 (en) 1999-04-07 2006-10-17 Sony Corporation Security unit for use in memory card
EP1043860A3 (fr) * 1999-04-07 2005-09-14 Sony Corporation Dispositifs de sécurité, unités de mémoire, dispositifs de traitement de données et procédés de chiffrage de données
WO2000072500A2 (fr) * 1999-05-20 2000-11-30 Storage Technology Corporation Systeme et procede de chiffrement d'informations
WO2000072500A3 (fr) * 1999-05-20 2001-01-11 Storage Technology Corp Systeme et procede de chiffrement d'informations
US6708272B1 (en) 1999-05-20 2004-03-16 Storage Technology Corporation Information encryption system and method
EP1079581A2 (fr) * 1999-08-17 2001-02-28 Hewlett-Packard Company Chiffrage et déchiffrage fort de données en paquets à travers un réseau de communications
EP1079581A3 (fr) * 1999-08-17 2006-05-17 Hewlett-Packard Company, A Delaware Corporation Chiffrage et déchiffrage fort de données en paquets à travers un réseau de communications
WO2001029652A3 (fr) * 1999-10-20 2002-01-10 Accelerated Encryption Proc Lt Accelerateur crytographique
US6963979B2 (en) 1999-10-20 2005-11-08 Aep Systems Limited Cryptographic accelerator
WO2001029652A2 (fr) * 1999-10-20 2001-04-26 Accelerated Encryption Processing Limited Accelerateur crytographique
US6928162B1 (en) 2000-04-07 2005-08-09 International Business Machines Corporation Method and system for manipulating and telescoping a hash function
US7555121B2 (en) 2000-09-25 2009-06-30 Broadcom Corporation Methods and apparatus for implementing a cryptography engine
EP1191736A2 (fr) 2000-09-25 2002-03-27 Broadcom Corporation Logique de cadrage d'un processeur pour le commerce électronique sécurisé
DE10056989A1 (de) * 2000-11-17 2002-05-23 Secware Technologies Ag Verschlüsselungssystem
WO2002101976A1 (fr) * 2001-06-13 2002-12-19 Corrent Corporation Antememoire de donnees securitaires
US7360076B2 (en) 2001-06-13 2008-04-15 Itt Manufacturing Enterprises, Inc. Security association data cache and structure
WO2002101977A1 (fr) * 2001-06-13 2002-12-19 Corrent Corporation Processeur et procede de chiffrement a passage unique
US7266703B2 (en) 2001-06-13 2007-09-04 Itt Manufacturing Enterprises, Inc. Single-pass cryptographic processor and method
US7249255B2 (en) 2001-06-13 2007-07-24 Corrent Corporation Apparatus and method for a hash processing system using multiple hash storage areas
EP1292082B1 (fr) * 2001-07-24 2018-12-19 Cavium, LLC Procédé et appareil permettant d'établir de session sécurisée
EP1292082A2 (fr) * 2001-07-24 2003-03-12 Cavium Networks Inc. Procédé et appareil permettant d'établir une session sécurisée
EP1310855A3 (fr) * 2001-11-09 2005-07-13 Lifescan, Inc. Système et procédé d'authentification de chaínes de données
EP1310855A2 (fr) * 2001-11-09 2003-05-14 Lifescan, Inc. Système et procédé d'authentification de chaínes de données
US7334009B2 (en) 2001-11-20 2008-02-19 Ip-First, Llc Microprocessor with random number generator and instruction for storing random data
US7818358B2 (en) 2001-11-20 2010-10-19 Ip-First, Llc Microprocessor with random number generator and instruction for storing random data
US6871206B2 (en) 2001-11-20 2005-03-22 Ip-First, Llc Continuous multi-buffering random number generator
US7849120B2 (en) 2001-11-20 2010-12-07 Ip-First, Llc Microprocessor with random number generator and instruction for storing random data
US7712105B2 (en) 2001-11-20 2010-05-04 Ip-First, Llc. Microprocessor including random number generator supporting operating system-independent multitasking operation
US7219112B2 (en) 2001-11-20 2007-05-15 Ip-First, Llc Microprocessor with instruction translator for translating an instruction for storing random data bytes
US7136991B2 (en) 2001-11-20 2006-11-14 Henry G Glenn Microprocessor including random number generator supporting operating system-independent multitasking operation
US8296345B2 (en) 2001-11-20 2012-10-23 Ip-First, Llc Microprocessor with selectively available random number generator based on self-test result
US7174355B2 (en) 2002-11-20 2007-02-06 Ip-First, Llc. Random number generator with selectable dual random bit string engines
EP2068239A1 (fr) * 2002-11-20 2009-06-10 IP-First LLC Microprocesseur avec générateur de nombres aléatoires, dont la disponibilité dépend du résultat d'un autotest
US7165084B2 (en) 2002-11-20 2007-01-16 Ip-First, Llc. Microprocessor with selectivity available random number generator based on self-test result
US7149764B2 (en) 2002-11-21 2006-12-12 Ip-First, Llc Random number generator bit string filter
US6965254B2 (en) 2002-12-10 2005-11-15 Ip-First, Llc Dynamic logic register
US7173456B2 (en) 2002-12-10 2007-02-06 Ip-First, Llc Dynamic logic return-to-zero latching mechanism
EP1447740A1 (fr) * 2003-02-11 2004-08-18 IP-First LLC Microprocesseur avec générateur de nombres aléatoires, dont la disponibilité dépend du résultat d'un autotest
US7139785B2 (en) 2003-02-11 2006-11-21 Ip-First, Llc Apparatus and method for reducing sequential bit correlation in a random number generator
US8468337B2 (en) 2004-03-02 2013-06-18 International Business Machines Corporation Secure data transfer over a network
US7564976B2 (en) 2004-03-02 2009-07-21 International Business Machines Corporation System and method for performing security operations on network data
WO2005091109A1 (fr) * 2004-03-19 2005-09-29 Nokia Corporation Dispositif a coprocesseur cryptographique
CN100435063C (zh) * 2004-03-19 2008-11-19 诺基亚有限公司 带加密协处理器的装置
KR100851623B1 (ko) * 2004-03-19 2008-08-13 노키아 코포레이션 암호 코프로세서를 포함하는 장치
EP3462366A1 (fr) * 2004-03-19 2019-04-03 Nokia Technologies Oy Dispositif avec coprocesseur cryptographique
US9652637B2 (en) 2005-05-23 2017-05-16 Avago Technologies General Ip (Singapore) Pte. Ltd. Method and system for allowing no code download in a code download scheme
EP1826694A3 (fr) * 2006-02-27 2009-01-14 Broadcom Corporation Procédé et système d'architecture, système sur une puce sécurisée pour le traitement de données multimédia
US9904809B2 (en) 2006-02-27 2018-02-27 Avago Technologies General Ip (Singapore) Pte. Ltd. Method and system for multi-level security initialization and configuration
US9177176B2 (en) 2006-02-27 2015-11-03 Broadcom Corporation Method and system for secure system-on-a-chip architecture for multimedia data processing
EP1826694A2 (fr) * 2006-02-27 2007-08-29 Broadcom Corporation Procédé et système d'architecture, système sur une puce sécurisée pour le traitement de données multimédia
US9860055B2 (en) 2006-03-22 2018-01-02 Synopsys, Inc. Flexible architecture for processing of large numbers and method therefor
US9489318B2 (en) 2006-06-19 2016-11-08 Broadcom Corporation Method and system for accessing protected memory
US20100067689A1 (en) * 2008-09-15 2010-03-18 Laffey Thomas M Computing platform with system key
US9444622B2 (en) * 2008-09-15 2016-09-13 Hewlett Packard Enterprise Development Lp Computing platform with system key
US10380007B2 (en) 2009-07-10 2019-08-13 Certicom Corp. System and method for managing electronic assets
US11119905B2 (en) 2009-07-10 2021-09-14 Blackberry Limited System and method for managing electronic assets
KR101336278B1 (ko) 2012-09-19 2013-12-03 충북대학교 산학협력단 무선 센서 네트워크에서 데이터 보안을 위한 경량 해시 알고리즘
WO2018024797A1 (fr) * 2016-08-04 2018-02-08 Nagravision Sa Vérification de séquences
EP3279826A1 (fr) * 2016-08-04 2018-02-07 Nagravision SA Vérification de séquence
CN109891425A (zh) * 2016-08-04 2019-06-14 耐瑞唯信有限公司 序列验证
US11314518B2 (en) 2016-08-04 2022-04-26 Nagravision S.A. Verification of instructions from main processor to auxiliary processor
CN109891425B (zh) * 2016-08-04 2022-11-15 耐瑞唯信有限公司 序列验证
WO2022125943A1 (fr) * 2020-12-11 2022-06-16 Nebulon, Inc. Distribution et mise à jour sécurisées de clés de chiffrement dans un système de stockage en grappe
WO2022126022A1 (fr) 2020-12-11 2022-06-16 Tethers Unlimited, Inc. Circuits cryptographiques intégrés dans des applications spatiales
CN114662082A (zh) * 2022-02-25 2022-06-24 荣耀终端有限公司 电子设备的访问控制方法、可读介质和电子设备
EP4276633A1 (fr) * 2022-05-13 2023-11-15 Thales Dis France SAS Dispositif semi-conducteur sécurisé et procédé
WO2023217760A1 (fr) * 2022-05-13 2023-11-16 Thales Dis France Sas Dispositif à semi-conducteur sécurisé et procédé

Also Published As

Publication number Publication date
CA2634812A1 (fr) 1999-03-25
CA2641215A1 (fr) 1999-03-25
EP1013026A2 (fr) 2000-06-28
CA2641215C (fr) 2010-05-25
CA2634812C (fr) 2010-03-30
AU1060999A (en) 1999-04-05
WO1999014881A3 (fr) 1999-07-22
CA2303297A1 (fr) 1999-03-25
CA2303297C (fr) 2008-11-25
EP1013026A4 (fr) 2004-09-08

Similar Documents

Publication Publication Date Title
CA2634812C (fr) Coprocesseur cryptographique
US6704871B1 (en) Cryptographic co-processor
US6708273B1 (en) Apparatus and method for implementing IPSEC transforms within an integrated circuit
US9043615B2 (en) Method and apparatus for a trust processor
US8438658B2 (en) Providing sealed storage in a data processing device
US7636858B2 (en) Management of a trusted cryptographic processor
US6385727B1 (en) Apparatus for providing a secure processing environment
US6959086B2 (en) Cryptographic key management scheme
US6438666B2 (en) Method and apparatus for controlling access to confidential data by analyzing property inherent in data
US20050132226A1 (en) Trusted mobile platform architecture
US20070180271A1 (en) Apparatus and method for providing key security in a secure processor
US20070162964A1 (en) Embedded system insuring security and integrity, and method of increasing security thereof
EP1855476A2 (fr) Système et procédé de traitement sécurisé de données
EP1429224A1 (fr) Autentification du firmware en temps d'exécution
JPH0816826B2 (ja) 管理方法及びデータ処理システム
US7970133B2 (en) System and method for secure and flexible key schedule generation
AU743775B2 (en) An apparatus for providing a secure processing environment
AU750573B2 (en) Method and apparatus for controlling access to confidential data
Nicholas SSL Hardware Hiding: Increasing the Security of OpenSSL Through Tightly-Coupled FPGA Hardware
CN116776323A (zh) 一种面向ZYNQ SoC的FPGA可信执行环境构建方法
Edition RSA BSAFE®
Module Approved Document
ME RSA BSAFE®
Module Security Policy Subscriber Encryption Module
DETTBARN Protecting the copyright of an embedded device with cryptography

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

ENP Entry into the national phase in:

Ref country code: CA

Ref document number: 2303297

Kind code of ref document: A

Format of ref document f/p: F

Ref document number: 2303297

Country of ref document: CA

NENP Non-entry into the national phase in:

Ref country code: KR

WWE Wipo information: entry into national phase

Ref document number: 1998953170

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1998953170

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642