Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Construct secure networked applications with certificates, Part 1

Certificates add value to public-key cryptography

By Todd Sundsted, JavaWorld.com, 01/12/01

  • Print
  • Feedback
.

Page 2 of 3

Key exchange illustrates one of the problems with symmetric-key cryptography that public-key cryptography so elegantly solves. It also introduces the inherent need in public-key cryptography that certificates solve, verifying the authenticity of an entity's purported public key.

Let's take a look.

Key exchange

For any cryptographic process to work, the entities that are intent on using the process must hold the necessary cryptography keys. In the case of shared-key cryptography, both entities must hold the same key. Since the shared key must be kept absolutely secret for the process to be secure, the act of key exchange becomes critical to the security of the process as a whole. You can't just mail the key to your buddy. If any flaws in the key exchange process crop up, the security of the entire application weakens.

Public-key cryptography nicely avoids the key-exchange issue. In public-key cryptography, owners keep their private-keys private and never exchange them. On the other hand, owners can publish public keys anywhere they'd like. As long as you keep your private-key private, and a potential correspondent can obtain your public key, the communication between the two of you remains secure.

Therein lies the problem with public-key cryptography. Consider two entities that have never previously communicated. How can you be sure that the public key that one entity is using to communicate with the other entity is, in fact, that entity's public key? What if the public key, in fact, belongs to a malicious third party performing a man-in-the-middle attack?

Keys are, after all, nothing more than strings of bits. Even if they are tagged with metadata, how can you be sure that no one has tainted the metadata? The solution involves the introduction of an item called a certificate and a trusted third-party known as a certificate authority.

An introduction to certificates

Certificates come in many shapes and sizes, but they all play the same role. At the barest minimum, a certificate is a document that contains information identifying an entity (in the case of X.509 certificates, using that entity's X.500 distinguished name (DN)) and the entity's public key. Another entity digitally signs and therefore certifies both pieces of information.

If you believe that the signing entity is honest and that its private key hasn't been compromised, then you can safely assume that the signing entity believes that the public key indeed belongs to the named entity. Depending on how much you trust the signing entity, that may be all that's required to conduct business.

Of course, to validate the signature of the signing entity, you need the signing entity's public key. Often, that public key is stored in a self-signed certificate -- a certificate digitally signed by the same entity whose public key is contained within. That certificate, to be effective, must be generally distributed (as part of a software package, for example) and easily verified (via a published SHA1 or MD5 hash, for example).

  • Print
  • Feedback

Resources