From Cryptography Decrypted
Part IV Overview: Real World Systems
E-mail, SSL, IPsec, Smartcards
Now that we’ve presented all the ingredients (secret keys, public/private keys, hash functions, and digital certificates) for cryptographic systems, let’s see how those pieces operate collectively in the real world.
Here we’ll look at how three real world systems -- secure e-mail (S/MIME, PGP), Secure Socket Layer (SSL), and Internet Protocol Security (IPsec) -- provide security. We also describe a few famous attacks and discuss how to protect your keys.
These real-world systems implement some or all of the cryptographic assurances we’ve discussed -- authentication, confidentiality, integrity, and nonrepudiation. In addition, because all three systems encrypt the majority of their data with a secret key, each includes (secret) key agreement or key exchange. In this overview, key exchange means that Alice encrypts a secret key with Bob’s public key and sends it to Bob. Key agreement means that Alice and Bob independently compute the identical secret key using Diffie-Hellman. At times we also use key exchange more broadly to apply to both situations.
Compare and Contrast: Secure E-mail, SSL, IPsec
Although the three systems don’t implement the assurances and key exchange in the same order, they all follow roughly the path shown below. Secure e-mail users can demand all the protections shown here, and, with the exception of nonrepudiation, so can SSL and IPsec users.
General flow and attributes of cryptographic systems, secure e-mail, SSL, and Ipsec:
Authentication
(Validate the other side)
Key Agreement / Exchange
(Agree on or exchange a secret key)
Confidentiality
(Exchange encrypted messages)
Integrity
(Proof message not modified)
Nonrepudiation
(Proof you got exactly what I sent)
E-mail Cryptographic Parameters
Let’s return to our stockbroker and customer example. Alice ’s e-mail messages to Bob usually go to Bob’s e-mail server and usually are not sent directly to Bob’s computer. Bob can retrieve Alice ’s e-mail after Alice sends it, whether or not Alice is still connected to the Internet.
Alice unilaterally chooses her cryptographic protections and parameters. So an e-mail receiver doesn’t negotiate cryptographic assurances or parameters with an e-mail sender; the receiver takes it or leaves it. For example, if Alice encrypts e-mail with AES, Bob’s computer must be able to decrypt parameters using AES. This shouldn’t be a problem if both e-mail users are using the same cryptographic program—for example, PGP. But some older versions of a program (such as PGP) may be incompatible with newer versions of the same program.
Negotiation of SSL/ Ipsec Cryptographic Parameters
Unlike secure e-mail, SSL and IPsec assume that Alice’s and Bob’s computers are connected to each other, and they allow Alice and Bob to negotiate which cryptographic assurances and parameters they want to use.
SSL assumes that a client and a server relationship exists between the two parties: A customer (for example, Bob) wishes secure exchanges with some merchant (for example, AliceDotComStocks). IPsec, on the other hand, treats each end of the connection in the same way. Both SSL and IPsec first exchange plaintext in which Bob sends a greeting to Alice and offers a variety of potential suites of cryptographic parameters from which Alice should choose.
SSL and IPsec can be roughly categorized as two-part systems, shown as follows. In part 1, both SSL and IPsec exchange plaintext messages, authenticate each other, and agree on secret keys. In part 2 they use their agreed-on secret keys to encrypt (decrypt) confidential messages with integrity. Both SSL and IPsec offer assurances in many different ways; for example, depending on the situation, secret key exchange may be completed before authentication.
General overview of IPsec and SSL as two-part systems:
Part 1
Hello There Bob initiates an Internet connection with Alice
Authentication Bob challenges Alice : prove you have private key
…and then Alice challenges Bob
Key exchange Exchange secret key
Part 2
Confidentiality Encryption using secret key cryptography
Integrity Detect whether confidential messages altered in transit
(Neither SSL nor IPsec offers nonrepudiation.)
User Initiation of Cryptographic E-mail, SSL, and IPsec
Cryptographic e-mail applications and SSL require that the user explicitly invoke cryptographic protections. For example, as you’ll see, an e-mail user must select the option of encrypting his or her e-mail. Similarly, a user must invoke SSL. In contrast, IPsec provides its cryptographic protections by default and does not require invocation by the user. In fact, IPsec is meant to be transparent to the user, who may not be aware IPsec is even installed on the computer.
Some Specifics: Secure E-mail
There are many secure email packages, each with it’s own particular characteristics. Each can offer different choices for secret key methods, public key methods, message digest methods, etc.
In general secure mail encryption follows this pattern:
1. Alice generates a session (secret) key.
2. She encrypts the plaintext message with the secret key (confidentiality).
3. She encrypts the session key with Bob’s public key (key distribution).
4. She signs a hash of the message and time stamp (authentication, integrity and non-repudiation).
5. She sends the secret key encrypted message, public key encrypted session key and the signed hash to Bob.
Most secure email packages require the sender to purposefully invoke encryption, either by setting the default in the program to automatic encryption or by selecting encryption and signing each time email is sent. Knowing the difference between encryption and signing and what assurances each provides can help users make appropriate choices when encrypting email messages.
Some Specifics: SSL
Secure Socket Layer (SSL) and the newer standard Transport Layer Security (TLS) are used to securely send information over the Internet and are very similar. Both are designed to negotiate cryptographic parameters between two computers. SSL/TLS implement three cryptographic assurances — authentication, confidentially, message integrity— and provide secure key exchange between an Internet Browser and Internet Server.
SSL/TLS go through the following steps to complete a secure transaction: Hello and negotiate, Exchange digital certificates, Secret key agreement (exchange), Authentication, Bulk Encryption (confidentiality and message integrity).
Some Specifics: IPsec
IPsec is based on the assumption that cryptographic protections should be delivered to the user as unobtrusively as possible. IPsec authenticates data entering and encrypts data leaving an IPsec enabled computer.
The current IPsec standard can be visualized as having two parts. The first part, IKE, manages authentication and key exchange. The second part manages the bulk encryption process.
IKE is a two-phase protocol. The first phase makes encryption parameters that are used to protect the second phase. The second phase makes encryption parameters that are used in IPsec part two, bulk encryption. Two-phase protocol key management enables quick changes to encryption parameters.
IPsec bulk encryption offers confidentiality and message integrity protections in four potential configurations. Many virtual private network (VPN) vendors implement their products using IPsec ESP protocol in tunnel mode.
Although IPsec has some controversial issues, even most of its critics agree it’s currently the best possible solution.
Common Attacks
Attacks against cryptographic systems are as creative as cryptographic systems themselves. There are lessons to be learned from looking at various attacks.
Replay: Messages should contain a timestamp or some other way to identify it as new or old.
Man-in-the-Middle: Trusted public keys need to be validated and protected.
Finding Keys in Memory: If secret keys can be identified, they can be attacked when they are outside of cryptographic protections.
Confidentiality Does Not Imply Integrity: Secret key encryption does not prevent BlackHat from altering a message.
Public and private keys must be used carefully. Adhere to standards, use a separate method and/or key for confidentiality and signing and never use your private key to sign the exact message sent to you. And never, never sign unknown messages.
Protecting Keys
No matter how strong any cryptographic system is, an identity thief could steal who you are (biometric scans), what you know (password) or what you have (smart card). One of the best ways to be vigilant about your keys is to store them someplace more secure than a desktop computer.
Smart cards, similar to a credit card, let you do that. They come in two different varieties—memory and microprocessor cards. Microprocessor cards, more sophisticated than memory cards, can hold multiple applications, passwords and even a co-processor that encrypts data stored in the card’s chip.
Manufacturers of smart cards design them in ways to protect against tampering. Though smart cards offer good security, they can still be attacked and are subject to technological advances weakening once strong keys.
At docrypt.com our computer application teaches about securing your keys in a key store.
(c) H. X. Mel & Doris Baker all rights reserved
Back to "Free Chapters"