In this alternative history, Centurion Marcus Antonius has many legionnaires at his disposal, and fortunately, he also has a laptop computer. The commanders send their messages over a network called RomanNet, which is surprisingly similar to today's Internet. The Celts...intercept messages by placing sniffers on the lines interconnecting the nodes in the RomanNet. The barbarian's resourcefulness requires that the Roman commanders use the latest security technology to ensure the confidentiality of their messages. Caesar will need the secret key to decrypt and extract the contents of the SignedData object. Don't Miss Early Registration! Register by Feb. 25, 2000 and save $200 on conference sessions and up to $260 on tutorials plus you'll get a free O'Reilly "Java Tiger" Conference T-shirt.

Java and the Public Key Infrastructure (PKI)in 52 B.C. by Theodore Shrader and Anthony Nadalin Our Java and Public Key Infrastructure (PKI) presentation at The O'Reilly Conference on Java introduces the technologies behind public keys and their current and possible future representation in Java. But you're asking yourself exactly how Java and PKI worked in 52 B.C.-right? To address your inquiry, let's go back in time to Gaul (an ancient region corresponding roughly to modern-day France). We arrive on one side of the vast Roman siege works that ring the Celtic hilltop fortifications at Alesia. In this alternative history, Centurion Marcus Antonius (Antony) has many legionnaires at his disposal, and fortunately, he also has a laptop computer in which to communicate with his fellow commanders and his commander-in-chief, Julius Caesar. On his laptop, Antony has the latest Java 2 Runtime Environment (JRE) and an e-mail application, which was written in Java and uses the Java PKI layers. The commanders use Java applications since the empire has not standardized on a single software platform. The laptop also includes other applications, such as recreational programs like ProngSweeper, but we'll focus on Antony's urgent need to use the e-mail application. (As part of their defenses, the Romans dug pits in front of their entrenchments and at the base of the pits placed prongs--affectionately called "lilies"--to impede an attacker's advance.) Let's first look at how the Roman commanders can communicate with each other. The commanders send their messages over a network called RomanNet, which is surprisingly similar to today's Internet. There are lots of nodes--the empire is vast--but the network is insecure. The Celts and barbarian tribes to the east can eavesdrop and intercept messages by placing sniffers on the lines interconnecting the nodes in the RomanNet. (The messages would be just Latin to us.) To subvert their Roman opponents, they have even tried to alter messages in transit. The barbarian's resourcefulness requires that the Roman commanders use the latest in security technology to ensure the confidentiality of their messages. To accompany their armor, gladius, and public and private key pair, the Centurion Academy (CA) issued each Roman commander upon graduation a certificate to represent their public key in a trusted fashion to the empire. (The CA is also known as a Certificate Authority.) The commanders keep their private keys on their laptops under password protection. Each of the commanders' public keys are wrapped within a certificate object and the certificates are published on a LDAP server that is located in Rome and accessible to anyone in the civilized world. With the public and private key pair, Roman commanders can send and receive encrypted mail as well as sign the contents of their messages to guard against tampering and to guarantee the identity of the sender. Want to learn more about Java? Check out The O'Reilly Conference on Java, March 27-30, in Santa Clara, CA. Let's get back to Antony. He has just received disturbing news. A large force of Celtic troops is marching towards them to relieve the garrison at Alesia. This requires the Romans to not only maintain their siegeworks around Alesia, but they must also guard against an attack to their rear. Antony devises a brilliant plan. The Romans should build an additional set of fortifications, which face outwards, behind the current siege lines. Looking at Antony's plans, we would see a crude donut, but an effective one, since it continues to bottle up Alesia in addition to protecting the legionnaires from outside attack from any direction. Antony must send his plans to Caesar, but he must do so securely so that enemy eyes cannot intercept his plans. Antony will do this with his e-mail program and the Java PKI layer. Marc Antony's Fortification Plans for Julius Ceasar When Antony composes the message, he indicates that the message should be signed and encrypted. Signed because he wants Caesar to know he sent the message and encrypted because he wants to shield the contents from enemy eyes. When Antony presses the send button, the e-mail program acts upon these attributes and creates a Secure/Multipurpose Internet Mail Extensions (S/MIME) Java object for transmitting the message. The S/MIME object knows that it needs SignedData and EnvelopedData, which are both defined as Public Key Crytography Standards (PKCS) objects. These two objects are defined as classes within the Java pkcs7 package. The S/MIME object first creates a SignedData object, constructing it with the contents of the message and Antony's public certificate. Methods on the SignedData object take the message and create a signature for it from Antony's private key, which the SignedData object extracted from his personal storage. (A PKCS #12 object typically bundles together a Centurion's certificate with his private key and encrypts the entire contents with a secret key in the form of a password.) The signature algorithm, implemented with an instance of the Signature object from the Java Cryptography Architecture (JCA), generated a message digest and encrypted it with the public key. The SignedData object contains Antony's certificate, his message, and signature information. Next, the S/MIME object will encrypt the SignedData object by wrapping it within an EnvelopedData object. As its inputs for encryption, the EnvelopedData object takes the SignedData object and the recipient's certificate, in this case Caesar's certificate extracted from the LDAP library in Rome. The EnvelopedData object first generates a secret key for the encryption, using an instance of the Cipher class in the Java Cryptography Extension (JCE). Secret keys are different then public and private keys: The secret key can be used for encryption and decryption. Data encrypted with a public key, on the other hand, can be decrypted from the corresponding private key, or vice versa. If you find the information in this article of interest, check out the authors' presentation at the O'Reilly Conference on Java. The EnvelopedData object uses a selected JCE symmetric Cipher algorithm to encrypt the SignedData object. Caesar will need the secret key to decrypt and extract the contents of the SignedData object, but the secret key cannot be sent in the clear as a companion to the encrypted SignedData object. Instead, the EnvelopedData object encrypts the secret key with Caesar's public key, again using algorithms within the JCE. The EnvelopedData object contains the SignedData object, encrypted with the generated secret key, and the secret key that was encrypted with Caesar's public key. With the preliminary objects in hand, the S/MIME object calculates the base64 encoding of the EnvelopedData object and attaches MIME headers before sending it to futureemperor@roman.net. Base-64 encoding translates binary data to character form so that the data can be sent across the technological aqueducts within the RomanNet. The e-mail program notifies Caesar that he has mail, and he pushes his campfire rations aside and opens his message. Under the covers, the application program creates a Java S/MIME object that parses the S/MIME message by first retrieving Caesar's protected private key. Like his fellow commanders, Caesar's private key is protected locally with a PKCS #12 object stored in a file on his laptop. The S/MIME object extracts the EnvelopedData object stored with the S/MIME object and uses a JCE Cipher instance of the specified symmetric algorithm and Caesar's private key to decrypt the encrypted secret key. With the decrypted secret key, the application can decrypt the encrypted SignedData object, again using an instance of the Cipher object from the JCE. Although the SignedData object contains the message, decrypting it is not enough. The e-mail application calls the verify method on the SignedData object. The object in turn calls upon an instance of the JCA Signature class to verify the signed message by first extracting the Antony's certificate from the SignedData object and extracting the public key from the certificate. If the SignedData object can trace Antony's certificate up the chain to a trusted CA, the SignedData object gets an instance of the Signature class and calls the verify method with the public key, signature bytes, and message. If the verify method returns true, pax in the Java and PKI process continues. (Note that the application could have indicated to the SignedData object that it should bypass checking the certificate chain and instead just verify the signature bytes.) Once the e-mail application decrypts and verifies the message successfully, it can provide its user, the future emperor of Rome, a level of guarantee that: The information was hidden from barbarian eyes. No one changed the message from the time it was sent. Marc Antony was the one who sent the message. The e-mail program will display Antony's message, perhaps with an accompanying animated GIF file showing the proposed ring of entrenchments and the approaching Celtic reinforcements. Once Caesar recognizes the urgency of Antony's message, he can direct his engineer, Benjamin Antietam, to construct the additional fortifications. (Caesar will later claim the idea was his own.) If we examine at the technologies used by the e-mail application, we see the following Java PKI layers at work: Task Package Constructing and parsing a S/MIME Message smime Constructing and parsing an EnvelopedData object pkcs7 Encrypting and decrypting the secret key and message JCE Constructing and parsing a SignedData object pkcs7 Signing and verifying the message signature JCA Storing the certificate and private key objects pkcs12 Note the difference between the JCA and JCE packages: Before regaining the upper hand on their Carthaginian adversaries, the Roman Senate decreed that cryptographic functions must be divided into two packages, one for export beyond the borders of Rome and the other for consumption by Roman citizens. The exportable package, JCA, does not include cryptographic functions, such as those used for encrypting or decrypting data. The JRE includes the JCA, but the JCE must be obtained externally. The Roman Senate had recently issued new guidelines to help loosen the export restrictions on applications that use cryptographic functions. This action stemmed in part from the action of Rome's border countries, like Germany, which are already developing cryptographic applications on their own in competition with Roman industry. Other Java PKI technologies could have been involved in this process. For example, PKCS #9 attributes, such as SigningTime, could have been included with the SignedData object when it was constructed. When Antony or Caesar requested their certificates, they could have used PKCS #10 CertificationRequest objects that were sent to the CA. Once the Roman Authority (RA) grants the request, the CA could return the certificate in a PKCS #7 SignedData object. (The RA is also known as a Registration Authority.) With Java PKI technologies, Caesar was able to fend off the Celtic reinforcements, win the battle, go on to subdue the rest of Gaul. Antony sent him another message, "Beware the Ides of March," but what Caesar did with that advice is covered elsewhere. Theodore Shrader is a feature lead for the IBM Java Security project. He has written numerous patents and articles dealing with Internet and Java development, distributed computing, object-oriented design, and database architecture and programming. He is also a co-author of an operating systems programming guide published by John Wiley and Sons. You can contact him by crossing the Rubicon or by sending him e-mail at tshrader@us.ibm.com. You can hear him speak at The O'Reilly Conference on Java. Anthony Nadalin is the Lead Architect for the IBM Java Security project. As the senior architect, he has responsibility for infrastructure design and development across IBM. He serves as the primary security liaison to JavaSoft for security design and development collaboration. You can contact him at drsecure@us.ibm.com. You can hear him speak at The O'Reilly Conference on Java.