ssl for securing

Editor's Notes

• #3: 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.
• #4: 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.
• #5: 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.
• #6: 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.
• #7: 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
• #8: 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
• #9: 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”
• #10: 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.
• #11: 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.
• #12: 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
• #13: 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
• #14: 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
• #15: 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
• #16: 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)
• #17: 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