3. 8.4 Securing E-mail
Why have multiple-layer security?
• To provide user level security
• It is easier to deploy security services at higher
layers in protocol stack
13. 8.5 Securing TCP Connections: SSL
SSL Key Derivation
• Generate Four Keys:
▫ EB = encryption
▫ MB = MAC
▫ EA = encryption
▫ MA = MAC
14. 8.5 Securing TCP Connections: SSL
SSL Data Transfer
• Break data stream into records:
Data MACVersion LengthType
Encrypted with EB
15. 8.5 Securing TCP Connections: SSL
Real SSL
• Server authentication
• Negotiation: agree on crypto algorithms
• Establish keys
• Client authentication (optional)
16. 8.5 Securing TCP Connections: SSL
Closing Connection
• TCP FIN
• Type field
17. Bibliography
• [1] J. Kurose and K. Ross, Computer Networking: A top-down approach, 5th
edition. New York: Pearson Education, Inc., 2010.
• [2] M.S.Bhiogade, “Secure Socket Layer”, in InSITE - “Where Parallels
Intersect,” June 2002, pp. 85-90.
• [3]A. Weaver, “How Things Work Secure Sockets Layer,” in Computer –
Innovative Technology for Computing Professionals, April 2006.
• [4] R. Bazile and O. Wong, “Pretty Good Privacy Network Security and
Cryptography, CS682,” November 4, 2002.
• [5] D.V. Bhatt, S. Schulze, G.P. Hancke, L. Horvath, “Secure Internet access
to gateway using secure socket layer,” in Virtual Environments, Human-
Computer Interfaces and Measurement Systems, July 2003, pp. 157- 162.
• [6] S. Garfinkel and G. Spafford, Web Security and Commerce. Sebastopol,
CA : O'Reilly & Associates, Inc. , 1997.
• [7] A. Levi and Ç. K. Koç, “Risks in Email Security,” in Inside Risks, 2001.
• [8] M. Sunner , “Email Security,” in Network Security, Volume 2005, Issue
12, December 2005, pp. 4-7.
Editor's Notes
4 of the layers in the protocol stack make use of security features. I will be discussing an example of application layer security through email and transport layer security through the SSL protocol. The network and link layers also have their own security features which Bill will be discussing.
You may ask yourself why even have multiple-layer security??
1. An example of that would be a customer who is purchasing goods from a website. Although, security at the network layer can offer “blanket security” by encrypting all the data in the datagrams & by authenticating all the source IP addresses, it can’t authenticate the customer without some other means of security. Thus, there is a need for security at both higher and lower layers in the protocol stack.
2.An example of that would be PGP (Pretty Good Privacy) which is used for securing email which I will discuss later. In other words, many users implement security functionality into their favorite applications because they don’t want to wait around for security to be broadly developed at the network layer.
The affair of Alice and Bob:
Alice sends Bob and email.
1.Alice doesn’t want someone to intercept the message and read it.
2.Bob wants to know that he is actually receiving the message from Alice.
3.Alice doesn’t want someone intercepting the message and changing its content.
4.Alice wants to know that she is actually sending the message to Bob.
Public Key cryptography: In this case, Bob generates public/private key pair and would make his PUBLIC key publically available
(public key server or web page). Alice then encrypts the message with Bob’s public key, and sends it off.
Once Bob receives the message, he just decrypts it with his PRIVATE key.
So in other words, the only person who can decrypt the message is Bob because he has the PRIVATE key to do so.
(Inefficient for long messages, however symmetric session keys can be used for long messages)
Symmetric Session Key: Alice generates a symmetric session key Ks and encrypts her message Ks (m) with the key.
She then encrypts the symmetric key with Bob’s PUBLIC key KB+ (Ks).
Alice concatenates the encrypted message and encrypted symmetric key to form a “package”
The package is sent off to Bob where he deconcatenates it.
Bob uses his PRIVATE key KB- to obtain the symmetric key Ks , and then uses the symmetric key to decrypt to message m.
Without Confidentiality: Alice applies a Hash function, H (MD5) to her message m to obtain a message digest
Alice signs the result of the hash function with her PRIVATE key to create a digital signature
Alice then concatenates the original message m with the signature to create a “package”
Bob receives the package and applies Alice’s PUBLIC key to the signed message digest
Bob then compares the results of this operation with his own hash of the message
Verifies that the message is indeed from Alice and unaltered
Alice and Bob must have each other’s PUBLIC keys to perform THIS:
With Confidentiality: Alice creates the concatenated package I just discussed. Then Alice generates a symmetric session key Ks and encrypts her the package Ks (p) with the key.
She then encrypts the symmetric key with Bob’s PUBLIC key KB+ (Ks).
Alice concatenates the encrypted message and encrypted symmetric key to form a new “package”
The package is sent off to Bob where he deconcatenates the first portion.
Bob uses his PRIVATE key KB- to obtain the symmetric key Ks , and then uses the symmetric key to decrypt to message m.
With this new message, Bob applies Alice’s PUBLIC key to the signed message digest
Bob then compares the results of this operation with his own hash of the message
Verifies that the message is indeed from Alice and unaltered
Developed by Phil Zimmermann in 1991
Is basically the Sender Authentication, Message Integrity and Confidentiality method
PGP uses MD5 or SHA for calculating the message digest
CAST, triple-DES or IDEA for symmetric key encryption
RSA for public key encryption
PGP creates a public key pair for the user
Public key (public key server or web server)
Private key protected by use of password – password must be entered every time the private key is accessed
Gives options of: digitally signing message, encrypting message, or doing both
To verify the first message, Bob must have Alice’s PUBLIC key to decrypt her signature which provides sender authentication
The second message has the signature and message encrypted which provides message integrity
PGP also provides a mechanism for public key certification
Unlike CA, PGP allows the user to certify that the key pairs belong together
Can also have another user vouch for authenticity of keys
“KEY SIGNING PARTIES”
Originally designed by Netscape in 1993
SSL is supported by all web browsers and web servers
Provides confidentiality, data integrity and end-point authentication
Used by all Internet commerce sites which can be identified by https instead of http
While SSL and TLS differ in ways that make them inoperable with each other, they are generally considered equal in terms of security. The main difference is that, while SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure "hello" to the server and only switch to secured communications after the handshake between the client and the server is successful. If the TLS handshake fails for any reason, the connection is never created.
Intruder can intercept the clients order and obtains payment information and they can start making purchases at the clients expense.
Intruder can modify the clients order, increasing/decreasing the order quantity dramatically.
Could be a fake website using the name of the website you intended to buy from.
Could take the clients money and run
Take the clients name, address and credit card number (identity theft)
SSL can secure any application that runs over TCP, not just HTTP.
Handshake: Client & Server use their certificates and private keys to authenticate each other and exchange shared secret
Key Derivation: Client & Server use shared secret to derive their own set of keys to encrypt and decrypt data
Data Transfer: Data to be transferred is broken up into a series of records
Connection Closure: Special messages are sent to securely close connection
Client and server establish a TCP connection
The client then sends the server an SSL hello message
Server responds with a certificate containing its PUBLIC key
(Certify by a CA to know that the PUBLIC key is the servers)
The client then generates a MS (Master Secret) and encrypts it with servers PUBLIC key to create an (EMS) Encrypted Master Secret
and sends the EMS to the server
The server decrypts the EMS with its PRIVATE key
Only the server and the client know the MS for this SSL session
MS is used as the Symmetric Session keys
The server and client each generate these four keys from the MASTER SECRET
Two keys are used to encrypt data and the two MAC (message authentication code) keys are used to verify integrity of the data
It is generally considered safer for server and client to each use different cryptographic keys: they each generate keys for encryption and integrity checking
EB= session encryption key for data sent from Bob to Alice
MB= session MAC key for data sent from Bob to Alice
EA= session encryption key for data sent from Alice to Bob
MA= session MAC key for data sent from Alice to Bob
Append MAC to each record for integrity checking
To create MAC, Bob uses the data along with the MB key into a hash function
To encrypt the record + MAC, Bob uses the session encryption key EB
Sent off to server, Alice
SSL Record
Type indicates if the record is a handshake message, contains data, or is used to close the TCP connection
type 0 for data; type 1 for closure
Length is used for the receiving end to extract SSL records out of the incoming TCP byte stream
Version is version of SSL
One problem exists where an intruder can insert, delete and replace segments in the stream of TCP segments sent between server and client
To avoid this, client calculates the MAC as a hash of the MB key and the data PLUS a sequence number
Sequence number allows the server to keep track of the segments
SSL allows the client & server to agree upon the cryptographic algorithms for the symmetric key, public-key, and MAC during the handshake phase.
Client sends list of algorithms it supports, along with client random nonce
Server chooses algorithms for symmetric key, public-key & MAC from list; sends back: choices + certificate + server random nonce
Client verifies certificate, extracts server’s public key, generates pre-master-secret (PMS), encrypts it with server’s public key, sends to server
Client and server independently compute encryption and MAC keys from pre-master-secret and nonces. Henceforth, all messages sent between client and server are encrypted and authenticated with the MAC.
Client sends a MAC of all the concatenation of all handshake messages it sent and received.
Server sends a MAC of all the concatenation of all handshake messages it sent and received.
Threats:
Steps 5 & 6 help prevent intrusion (Intruder deleting stronger algorithms from list sent to server, and if inconsistent the server can terminate connection)
Nonce used because if an intruder sniffs all messages between client and server and the next day tries to send the same messages to the server
The sequence numbers may be the same, however, the nonce prevents this from happening (server would send a different nonce the next day)
Client or server can end the connect with TCP FIN
However, with just a TCP FIN, an intruder could just send a TCP FIN to the server and the server would terminate the connection without receiving all of the clients information
To resolve this problem the type field is either set to 0 for data; or 1 for closure
