- Board Level
- Physical Access to Components
- PCB Design and Routing
- Bus Protection
- Memory Devices
- PLDs and FPGAs
- Power Supply
- Clock and Timing
- I/O Port Properties
- Cryptographic Processors and Algorithms
- Conclusion
- References
Cryptographic Processors and Algorithms
The secure coprocessor originated from the notion of a protected subsystem that can execute sensitive functions in a trusted manner. This topic is extremely broad and cannot be covered in sufficient depth in this article. Programmable secure coprocessors typically contain a number of essential ingredients, including hardware tamper response, randomness, layered design, self-initialization, authentication, general-purpose processor and coprocessor, persistent storage, and third-party programming interface. If possible, any cryptographic functions in your design should be moved out of firmware and into a dedicated cryptographic device. Physical security is a central assumption on which secure distributed systems are built; without a secure foundation, even the best cryptosystem or the most secure kernel will fail.
Yee's "Using Secure Coprocessors" [9] provides a well-rounded look at secure coprocessor design and implementation. The IBM 4758 is likely the most recognized, commercially available secure coprocessor. Its design has been presented through a number of academic papers and articles, including Dyer, et al.'s "Building the IBM 4758 Secure Coprocessor." [10] Bond and Clayton [11] provide the first known attack against the IBM 4758 by taking advantage of a flaw in the Common Cryptographic Architecture (CCA) support software to export any and all of the program's DES and 3DES keys. IBM also has a PCI-X Cryptographic Coprocessor. Other vendors providing cryptographic devices include Hifn, SafeNet, Philips Semiconductors' VMS747 Security Processor, and Rainbow Technologies' CryptoSwift HSM.
The strength of cryptography relies on the secrecy of a key (contained in the user hardware), not the employed algorithm. However, it is not sufficient to assume that a large key size will guarantee security. Even if a trusted encryption algorithm is used, such as DES or AES, improper implementation could make the product easy to break. One must have a complete understanding of the requirements and functionality of an encryption solution before it is implemented into a system. Many product companies claim they use "encryption" in their product, when in reality it is nothing more than a simple encoding scheme (usually some type of logic operation). Generating custom encryption solutions, also known as "rolling your own," is typically a bad idea, as they end up being very insecure.
An example of improperly used encryption can be seen in Grand's "DS1991 MultiKey iButton Dictionary Attack Vulnerability." [12] The DS1991 iButton is a hardware authentication token that has three internal 48-byte data areas, each protected by a distinct password. Only the correct password will grant access to the data stored within the area. While the marketing literature claimed that "false passwords written to the DS1991 will automatically invoke a random number generator that replies with false responses...which eliminates attempts to break security by pattern association," it was determined that the data returned on an incorrect password attempt is not random at all, and is calculated based on the input password and a constant block of data stored within the DS1991 device.