![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This article is a continuation of the Big iron lessons series. Mainframes like the z990 have a rich tradition of high security and performance to support e-commerce and data-critical enterprise systems as well as government organizations. One of the best lessons that can be learned from the cryptographic coprocessors used with the zSeries® concerns the development of an extensible and flexible yet very secure API. Often the nature of local regulations, the security required, the lifetime of sensitive data, and cost and performance requirements vary significantly from environment to environment, so applications must be able to tailor a security policy using cryptographic coprocessing. Given the wide range of embedded cryptographic applications, this flexibility is even more important for embedded systems, which are often much more resource-constrained and must operate in real-time.
In this continuing article on cryptography (see the first article), I discuss modern methods that have evolved since the rotor encryption methods pioneered before and during World War II. This article also concludes the Big iron lessons series.
After the War, IBM developed the Lucifer algorithm to address privacy, authentication, and data integrity issues in computing systems. IBM worked with NIST and eventually defined DES (Data Encryption Standard), which became an official standard in the 1970s and remained in use until recently. The original 56-bit DES has mostly been abandoned due to several different groups' success in cracking it. New standards are emerging from NIST, including AES (Advanced Encryption Standard) and TDES (Triple DES). IBM remains a principal contributor to these standards, and the PCIXCC cryptographic coprocessor presently implements a wide selection of current standards, including:
- DES (56-bit key)
- TDES (168-bit key)
- AES (128, 192, and 256-bit keys)
- SHA-1
- MD5
- RSA (1024-bit CRT key)
A taxonomy of encryption schemes
Encryption methods have evolved over time from simple substitution and transposition ciphers and early machines like Enigma to more modern algorithmic schemes. In a broad sense, the history of cryptography can be broken down into these categories:
- Classical: Substitution and transposition
- Rotor machines: Those like Enigma
- Digital computer algorithms: Public and private keys
The following sections review aspects of algorithmic schemes and their strengths and weaknesses. While any of these algorithmic schemes are amenable to embedded encryption, care should be taken to consider the strength of the protection, ease of use, and the computational complexity of each. A full comparison of all modern algorithms is beyond the scope of this article, but the overview should provide you with enough background to do further research in order to make wise choices for your application.
The DES standard and commercial encryption
The DES encryption standard has been used in banking and e-commerce for almost thirty years and is still used for some applications, although DES is no longer considered strong encryption. By the late 1990s, security researchers had been able to break the 56-bit DES algorithms in as little as three hours. This fact led to the development of AES (Advanced Encryption Standard) by NIST, the TDES algorithms (an improved DES with a much larger key), and to some extent, RSA; the latter also has the advantage of offering public key encryption (which a later section discusses). So, presently, the DES algorithm is not recommended and is no longer considered secure, but might be acceptable for systems needing a very basic level of security.
For any data privacy requirements, the aging of information should be considered and the lifetime of the information being protected should be shorter than the best known cryptanalysis attack. So, in theory, 56-bit DES would still be secure for protecting passwords that are changed more frequently than every three hours. The newer standards -- TDES, RSA, and AES -- have estimated cryptanalysis times that are practically infinite, taking many years (and a huge associated cost) to crack with supercomputer technology. Given this cryptographic strength, these algorithms are a better choice for protecting data that has a significant lifetime. Find more information on the DES algorithm and its history in Resources. Since 56-bit DES has been cracked, TDES (Triple DES) has been used as a quick replacement, but NIST recommends AES as the ultimate replacement.
The emergence and importance of public key encryption
In 1976, Whitfield Diffie and Martin Hellman devised a scheme by which two parties may establish a shared secret key, even when communicating over an insecure network. This became known as the Diffie-Hellman key exchange, a comprehensive discussion of which is beyond the scope of this article (see Resources for more exhaustive references). One of the things that Diffie-Hellman allows for is the safe transport of a public key with a message, allowing this public key to be paired with a private key and then used to decrypt private data. This Diffie-Hellman key exchange protocol is used, for example, by RSA and PGP. By comparison, most encryption algorithms, including the Enigma example you saw in the first part of this series, are secret key (or single key) algorithms, where a seed or starting code is used for encrypting plain text and that common key must also be used for decryption. For example, in the Enigma example code in the first part of this series, the starting position of the rotors is the common key. In the case of encryption using random number generation, the seed used would be a common key. Clearly, if this common key is divulged, then all security is lost.
Diffie-Hellman public key algorithms have been designed so that the key used for encryption is different from the key used for decryption; the decryption key can't be calculated from the encryption key. The encryption key can therefore be public, since it is not useful for decryption. In fact, the public encryption key is given out freely so remote users can encrypt messages, but the private decryption key is kept secret. Both PGP and RSA provide public key encryption.
Pretty Good Privacy: Strong encryption for the masses
When Phil Zimmermann introduced PGP (Pretty Good Privacy), his intent was to make private communication available to all with public free software. Furthermore, PGP provides the Diffie-Hellman public and private key pair, making the software easy to use between a trusted source and recipient for practical applications like secure e-mail. This allows a sender to encrypt a message with an intended recipient's public key (distributed to others in plain text) and send an encrypted message that can only be decrypted with a corresponding private key that is secret and held only by the intended recipient. A nice feature of PGP and any Diffie-Hellman public key encryption method is that the need to secretly distribute a single key, as is the case for DES, is now eliminated. PGP also provides a simple document-signing feature to provide authentication of message source.
The license for the freeware version of the PGP software does not permit commercial use, but PGP provides personal use privacy comparable to commercial solutions and, for applications like e-mail, is far more secure than sending sensitive messages in plain text. For example, I might want to send bank account information privately to a son or daughter in college; PGP allows me to do so safely over plain-text e-mail. I have included my PGP public key in the downloads section of this article.
Encryption for a secure enterprise and for secure embedded systems
Security for Internet and computing systems is a much broader topic than cryptography. Cryptography is required for any serious security policy. So encryption is a necessary feature of a good security design, but it is not sufficient on its own. Additional tools need to be incorporated, including firewalls, virus detection, trip-wires, and numerous operating system patches. Overall, however, encryption does contribute to some of the most important aspects of any security design, including:
- Authentication: Knowing the true source of a message
- Data privacy and integrity: Knowing data has not been tampered with and that it has not been seen by those other than the intended audience
- Access control: Ensuring that resources and files are only accessed by authorized entities
- Non-repudiation: Ensuring that transactions made or messages sent can't be denied by the originator
- Prevention of spoofing: Ensuring that messages can't be saved and re-transmitted again at a later time by an unauthorized source
- Prevention of denial of service: Ensuring that resources can't be tied up by repeated unauthorized access attempts
Encryption provides for the ability to sign data with a digital signature that is difficult to forge and hard to spoof (or, to save and play back later). Obviously, encryption provides data privacy, but it also provides data integrity when data blocks are decrypted. So, encryption is at the heart of any secure enterprise, but is not sufficient alone to fully protect a system.
Noteworthy features of the IBM PCIXCC
The Enigma listing in the previous part of this series showed you how complex even the very simple Enigma is to implement. When you consider the increased mathematical complexity of RSA or TDES, it's clear that any cryptographic coprocessor will have to run very efficiently to provide any sort of encryption or decryption on-line. The IBM PCIXCC not only supports all current encryption standards, including the highest NIST FIPS standards such as AES and RSA; it does so with a hardware architecture that allows it to run quickly (see Resources for detailed information on the PCIXCC).
In the PCIXCC, a combination of ASIC and FPGA hardware is used to speed up cryptographic algorithms and random number generation, and to support high-performance communications between the host system and the card, and between the PowerPC and the cryptographic engines inside the card. This is much more efficient than a firmware implementation of these functions. Furthermore, the coprocessor has been designed with a fast path that gives the host server a direct hardware path to the public-key cryptographic engine so that data does not have to be stored, processed, and then forwarded by software. The software stays out of this data fast path entirely. PCIXCC also features secure layers and upgrade. Upgrade is tricky for a cryptographic coprocessor, since it presents an opportunity for corruption and attack. The PCIXCC includes an unmodifiable ROM segment (protected by FIPS-compliant packaging) and then three higher-level upgradeable segments with digital certificates. The digital certificate ensures that all modifications are made by authenticated sources and methods.
The PCIXCC meets or exceeds all NIST requirements for a secure encryption device. One of the features of the PCIXCC that would be hard to implement in an embedded chipset is its tamper proofing. Overall, the PCIXCC meets the highest standards. The PCIXCC provides both private key and public key encryption algorithms, along with an API to allow for easy integration with existing software. The PCI-X bus interface makes hardware integration simple as well. One of the biggest lessons learned by IBM in the development of cryptographic coprocessors is that you need to provide a flexible API and selection of algorithms. The users of these coprocessors must have options for interoperability and for migrating to more secure protocols once older algorithms become vulnerable to cryptanalysis.
Will the encryption versus cryptanalysis battles ever end?
As long as there is encryption, there will be cryptanalysis. Eternal vigilance is required of all system architects involved with encryption and the design of secure systems. Many of those involved in cryptanalysis are simply testing a new encryption method to ensure that it is not vulnerable to some simple attack. The Rijndael (pronounced Rhine doll) algorithm proposed as the final AES standard is estimated to require a current cryptanalysis system 149 trillion years to decrypt.
Remember, though, that this estimate is based on current computing technology, with speeds on the order of gigahertz and memory on the order of gigabytes. When DES was first introduced in 1977, the IBM XT™, with its 4.77 MHz processor, was still six years away. By January 1999, when DES was first cracked by the Electronic Frontier Foundation, the Pentium III PC ran at 450 Mhz, more than 100 times faster than any PC readily available at the time DES was standardized. Furthermore, EFF's initial assault on DES involved 100,000 networked PCs, a scenario that the creators of 56- bit DES probably would never have anticipated. The second successful attack on 56-bit DES by the EFF involved hardware acceleration of the cryptanalysis and lead to cracking DES in just under three hours. The wide availability of devices like the 18,000 custom ASICs used in the attack would likewise not have been predictable in 1977.
The point of these observations is that even algorithms that seem very secure today should not be considered unbreakable. In fact, public challenges to break encryption schemes should be promoted so that the strength of current algorithms is known. Flexibility in cryptographic coprocessors is therefore of paramount importance. System engineers should carefully consider supporting a selection of algorithms and may need to support legacy encryption methods such as DES for interoperability. Currently, supporting AES, Triple DES, and public key encryption such as RSA would be a good starting point, but these algorithms may be refined over time for ease of use or to remove vulnerabilities, so secure methods for upgrading cryptographic coprocessing should be kept in mind.
Note: This article has been updated with a number of clarifications and fixes. Many thanks to Jeremy Bishop (and the many other readers) who mailed in with comments when this article was first posted.
- If you want to send me an encrypted e-mail, download my PGP public key, Sam-Siewert-PGP-Public-Key.txt.
- Find a broad overview of cryptography and what it's good for in "Introduction to cryptography, Part 1: The
broad view," Murdoch Mactaggart (developerWorks, March 2001).
- The IBM PCIXCC cryptographic coprocessor is described in "The IBM
PCIXCC: A new cryptographic coprocessor for the IBM eServer," T.
W. Arnold and L. P. Van Doorn (IBM Journal of Research and
Development, 2004). This processor provides high-performance
NIST FIPS 140-2-level security with a flexible API supporting DES,
Triple DES, AES, MD5, and RSA public key encryption.
- The IPsec
standards, developed through the IETF (Internet Engineering Task
Force), are a collection of related standards all related to IP
security and cryptography.
- Check out this information on finding good random number generators,
which are essential to encryption. You can learn more from this
ACM paper, "Random number generators: Good ones are hard to find,"
S.K. Park and K.W. Miller (October 1988).
- Applied Cryptography,
Bruce Schneier (John Wiley and Sons, 1996) is one of the most
comprehensive sources on encryption algorithms and theory.
- Firewalls and Internet
Security: Repelling the Wily Hacker, W. Cheswick, S.
Bellovin, and A. Rubin (Addison Wesley Professional, 2003) is a very
practical guide on methods to increase security for UNIX® systems,
including Linux™.
- Privacy on the Line: The Politics of
Wiretapping and Encryption," Whitfield Diffie and
Susan Landau (MIT Press, 1999) provides a great historical overview
of both the development of encryption technology and the U.S.
government policies and organizations that have exercised legal
controls and influence on the technologies.
- See the RSA Web site for a more detailed
discussion of Diffie-Hellman including its susceptibility in some cases
to "man in the middle" attacks.
- Philip Zimmermann's essay
"Beware of
snake oil" provides insight into what constitutes good encryption
and why PGP got him into trouble with U.S. Customs. The PGP freeware
version should only be downloaded by U.S. or Canadian citizens
meeting all conditions required on the PGP download site at MIT. While PGP freeware
is still available, it is not intended for commercial use; using it
for commercial purposes is a violation of its license agreement. For
commercial use, see the PGP
Corporation's home page.
- Learn more about the Data Encryption Standard, or DES, including how the EFF broke
the encryption.
- Get more details on the
Deep
Crack ASIC employed to crack DES from the EFF site (note in particular
the photos of the board and Deep Crack Chips).
- The Linux Journal published a nice article on public key
encryption using RSA. "Exploring RSA encryption," Jack Dennon (June 2003), provides
a theoretical view and coverage of the RSA basic algorithms. An
alternative overview of the RSA algorithm and math, "An example of the RSA
algorithm," may also be helpful.
- Wikipedia has a description of the Diffie-Hellman key exchange
used for public key encryption.
- More information on AES encryption can be found at the NIST AES Web
site. NIST also has more information specifically on Rijndael;
you can learn more from this Dutch Rijndael site
maintained by the inventors of the cipher. The IBM developerWorks
article Exit DES, enter Rijndael (November 2000) provides a good overview on the replacement
of DES
by the AES Rijndael standard.
Dr. Sam Siewert is an embedded system design and firmware engineer who has worked in the aerospace, telecommunications, and storage industries. He also teaches at the University of Colorado at Boulder part-time in the Embedded Systems Certification Program, which he co-founded. His research interests include autonomic computing, firmware/hardware co-design, microprocessor/SoC architecture, and embedded real-time systems.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
