CSN11111/8

Network Security
Cryptography & SSL
Dr. Sana Ullah Jan
Lecture outline
 Cryptography
 Symmetric Key Encryption
 Asymmetric Key Encryption
 Digital Signature, Digital Envelop, Certificate Authority, Digital Certificate

 Securing TCP
 Secure Socket Layer (SSL) & Transport Layer Security (TLS)
 Almost SSL
 Real SSL/TLS
 TLS 1.3
 Attacks on SSL/TLS
 Connection Replay Attack
 Truncation Attack
 Browser Exploit Against SSL/TLS Attack (BEAST)
Introduction to Cryptography
 Cryptography elements
 Algorithm – DES/3DES & RSA
 Keys for encryption and decryption
 Two types of encryption schemes:
 Symmetric key encryption:
 Encryption and decryption keys are the same
 Stream ciphers
 Block ciphers
 Asymmetric key encryption:
 Encryption and decryption keys are not the same
Stream ciphers vs. Block ciphers

 Symmetric-key encryption can use

either stream ciphers or block ciphers
 A stream cipher encrypts one bit/byte of
plaintext at a time
 The most widely one: RC4
 A block cipher encrypts a
block/chunk (i.e., a fixed size of n-
bits of data) of plaintext at a time
 The usual block sizes : 64 bits, 128 bits, and 256
bits
 Popular steam cipher: DES, 3DES, AES, and
Blowfish
Block Ciphers
 CBC (Cipher Block Chaining) is one such mode used by
the block ciphers
 To make each message unique, an Initialization Vector
(IV) is used in the first block
 Each block of plaintext is XORed with the previous
cipher text block before being encrypted
Digital Signature (DS)

 Digital Signature is a digital equivalent of a

handwritten signature or stamped seal, but offering
far more inherent security
 A digital signature is intended to solve the problem of
tampering and impersonation in digital communications
 In many countries, digital signatures have the same
legal significance as the more traditional forms of
signed documents
Digital Signature (DS)

 Digital Signatures are based on public key

cryptography, also known as asymmetric cryptography
– public key algorithm such as RSA
 In terms of CIA, DS provides Integrity and
Authentication but not Confidentiality
 DS shows even a single bit of data was changed
 DS verifies the sender of the message
Digital Signature Cont.

 Sender has two keys: a public and a private key

 To create a digital signature, signing software (such as
an email program) creates a one-way hash of the
electronic data to be signed
 The private key is then used to encrypt the hash
 The encrypted hash -- along with other information,
such as the hashing algorithm -- is the digital signature
Digital Signature Cont.

 This attribute enables others to validate the integrity

of the data by using the signer's public key to decrypt
the hash
 If the decrypted hash matches a second computed hash
of the same data, it proves that the data hasn't
changed since it was signed
 If the two hashes don't match, the data has either been
tampered with in some way (integrity) or the signature
was created with a private key that doesn't correspond
to the public key presented by the signer
(authentication)
Digital Signature Cont.
 Sender:

1. Calculates the hash of 2. Encrypts the hash with the Private Key
the message

3. Signs the message with private key 4. Sends the signed message

 Receiver:
5. Re -calculates the 6. Decrypts the received signature with Public Key
hash of the message

7. Compares 5 with 6 – if they are

same there was no alteration
Digital Signature Cont.
 Using public-private key pairs to create a digital
signature: Sender → Receiver
Hi George, Hi George, 101101…
I will see you at 12:00 in I will see you at 12:00 in
Appex café tomorrow. Appex café tomorrow.
3. Message and encrypted
1. Sender
message digest (hash) value
creates
are combined, forming a
message
digitally signed message

101101…

2. Sender’s software computes hash value and use

sender’s private key to encrypt the hash
Digital Envelope
 In terms of CIA, DS provides Integrity and
Authentication but not Confidentiality
 We never send a digitally signed message out
without further encryption
 Because the message itself could still be read by
anyone
 Need to put the message and its digest in a
secured envelope
 The secured envelope is called Digital Envelop
(DE)
Digital Envelope Cont.
 Use the recipient's public key (of which you already
have a copy or know where to find it) to encrypt both
the message and digest
 Output is called: Digital Envelope (DE)
 No one else has the private key of the receiver so no
one else can open the envelope
 Now we have all three elements
 Confidentiality
 Integrity
 Authentication
Digital Envelope Cont.
 Using public-private key pairs to create a
digital envelope: Sender → Receiver
Hi George, 101101…
I will see you at 12:00 in
Appex café tomorrow.

5. Sender uses receiver's public 6. Sealed envelopes is

key to encrypt the digitally signed sent to receiver via the
message, creating a digital Internet or other
envelope untrusted comm.
channel

4. Sender obtained a copy of the receiver ‘s public key

(from receiver’s digital certificate) –send via
communication channel desired
Using public and private key
in DS, DE
Create Verify Create Open Digital
Digital Digital Digital Envelope
Signature Signature Envelope
Sender’s private key X
Sender’s public key X
Receiver’s public key X
Receiver’s private X
key
Digital Certificate (DC)
Structure Digital Certificate (DC)
 Digital Certificate includes Example – X.509 certificate
 Certificate
 Version Number
 Serial Number
 Signature Algorithm ID
 Issuer Name
 Validity period
 Not Before
 Not After

 Subject name
 Subject Public Key Info
 Public Key Algorithm
 Subject Public Key

 Issuer Unique Identifier (optional)

 Subject Unique Identifier (optional)
 Extensions (optional)
 ...

 Certificate Signature Algorithm

 Certificate Signature
Revision

DS vs DE vs DC?
Certificate Authority (CA)
 The Certificate Authority (CA) is the device which issues and verifies
digital certificates.
 GoDaddy
 Symantec
 Comodo
 Entrust
 Let's Encrypt
Unsecured TCP Connections

 In terms of security, TCP is a vulnerable transport protocol

 Bob is surfing the Web to buy a gift

 Bob arrives at the Alice’s incorporated site
 Bob needs to fill out the form:
 Type of gift
 Quantity
 Bob’s address
 Bob’s credit card information
 Bob expects to receive the gift and the charge on his credit card…
 All sounds good and perfect!
Unsecured TCP Connections Cont.

 But…what if no security measures are taken

 If there is no Confidentiality, Integrity, client Authentication & server
Authentication (CIAA)
 Bob could be in for a few surprises
 If no confidentiality is used?
 If no data integrity is used?
 If no server authentication is used?
Securing TCP Connections Cont.
 Cryptography can enhance TCP with security services,
including CIAA
 Commonly known as Secure Sockets Layer (SSL)
 Originally designed by Netscape and supported by all popular Web
browsers and Web servers
 SSL version 3: Transport Layer Security (TLS)
Securing TCP Connections Cont.
 SSL/TLS protects connections between servers and clients
 Any connection between a website and its visitors, email servers,
a mobile application and its servers, or video game servers and
players.
 It is used by Internet commerce sites (Amazon, eBay, Yahoo)
 Tens of billions of dollars spent over SSL/TLS every year
 Protecting your credit card – during the transaction you can see http changed to
https!

 SSL/TLS is application agnostic

 It doesn’t care about the type of content encrypted. It can be
used for
 Web-based applications that rely on the HTTP protocol
 Any system where a client computer or device needs to initiate a connection
with a remote server
Secure Socket Layer (SSL)
 SSL is enhancing TCP with CIAA
 It often used to secure transactions over HTTP
 SSL can be employed by any application that runs over TCP
 SSL provides Application Programme Interface (API) with sockets which
is similar to TCP API
 When an application wants to employ SSL, the application includes SSL
classes/libraries
 Although SSL technically resides in the application layer, from the
developer’s perspective it is a transport protocol that provides TCP’s
services enhanced with security services
 SSL has two layers of protocols
SSL and OSI Model
 SSL Protocol Stack

The SSL Protocol Stack is composed of two layers:

 The first layer is the upper layer which is composed of

SSL Handshake Protocol, SSL Change Cipher Spec
Protocol, and SSL Alert Protocol, which are used in the
management of SSL exchanges
 The second layer is the lower layer composed of the SSL
Record Protocol, TCP, and IP
SSL Record
 SSL record includes: type field, version field, length
field, data field, and MAC field
 First three fields are not encrypted but the rest are
 The type field indicates whether the record is a
handshake message or a message that contains
application data
 The length field to extract the SSL records out of the
incoming TCP byte stream
The Big Picture

 How does SSL work for Bob and Alice communication?

 Two way for explaining SSL in today’s lecture
 Almost-SSL (simplified version of SSL)
 Real SSL (filling in the details)
 Both explanations have three phases
 Handshake
 Key derivation
 Data transfer
Handshake – almost SSL

 It has three steps

 Step (A) Bob to Alice
 TCP connection establishment
 Step (B)
 Bob to Alice: SSL Hello message - Establish security capabilities
 Alice to Bob: SSL Hello message - Confirm the chosen cipher suite
 Alice to Bob: Certificate - Bob verifies that Alice is really Alice
 Step (C) Bob to Alice
 Generates: Master Secret (MS) key
 Sends: Encrypted Master Secret (EMS) key
Q. How Alice decrypts the EMS received from
Q.
Bob?Can Mallory decrypts the EMS generated by
Bob?
Handshake – almost SSL

 At the end of the handshake the MS key is shared

by Bob and Alice
 They both can use MS key as the symmetric
session key for all subsequent encryption and
data integrity checking
 However, generally considered safer for Alice and
Bob to each use different cryptographic keys,
and also to use different keys for encryption and
integrity checking
Key Derivation – almost SSL

 Alice and Bob use the MS key to generate four keys

 EB = session encryption key for data sent from Bob to Alice
 MB = session Message Authentication Code (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
 At the end, Alice and Bob have all four keys
 The two encryption keys and two MAC keys each
Key Derivation – almost SSL

 At the end of the key Derivation phase, Alice and

Bob share the same four session keys (EB, MB, EA,
and MA)
 Now, Alice & Bob can start to send secured data
to each other over the TCP connection
Data Transfer – almost SSL

 TCP is a byte-stream protocol

 A natural approach would be for SSL to encrypt
application data on the fly and then pass the
encrypted data on the fly to TCP
 But if we were to do this, where would we put
the MAC for the integrity check?
 We don’t want to wait until the end of the TCP
session to verify the data integrity from Bob
Data Transfer – almost SSL

 SSL breaks the data stream into records, appends

a MAC to each record for integrity checking , and
then encrypts the result.
 This means encrypt [record + MAC]
 But how Bob would create the MAC…
Data Transfer, Bob sends - Almost SSL
Credit card Order Postal address Billing
information information address

Record1 Record2 Record3 Record4

Hash f(x)

 Record1 along with MB -----------> Encryption

MAC f(x) using EB

 Record1 and MAC (appended ) -----------> Encrypted

 This encrypted package is then passed to TCP for transport over the Internet

 Same procedure for Record2, Record3, Record 4

Data Transfer, Alice receives - Almost SSL
Credit card Order Postal address Billing
information information address

Record1 Record2 Record3 Record4

This is the actual
MAC
Decrypt using EB
 Encrypted data from Bob ------> Record1 and MAC (appended)
This is the new MAC
Hash f(x)
 Record1 along with MB ------> MAC (new MAC)

 Compare the actual MAC and new MAC, if they are same, there was no
alteration

 Same procedure for Record2, Record3, Record4

Data Transfer - Almost SSL

 Although this approach goes a long way, it still isn’t

bullet-proof when it comes to providing data integrity for
the entire message stream
 Suppose Mallory is a man-in-the-middle and has the
ability to insert, delete, and replace segments in the
stream of TCP segments sent between Alice and Bob
 Mallory could capture two segments sent by Bob, reverse
the order of the segments, adjust the TCP sequence
numbers (which are not encrypted), and then send them
to Alice
Data Transfer - Almost SSL

 Assuming that each TCP segment encapsulates exactly

one record
 TCP running in Alice would think everything is fine and
pass the two records to the SSL sublayer
 SSL in Alice would decrypt the two records
 SSL in Alice would use the MAC in each record to verify
the data integrity of the two records
 SSL would then pass the decrypted byte streams of the
two records to the application layer; but the complete
byte stream received by Alice would not be in the
correct order due to reversal of the records by Mallory!
Data Transfer - Almost SSL

 How could we still trust the TCP Sequence Numbers

(SN) when we know that Mallory could manipulate
them?
 Answer: DO NOT TRUST TCP SN– GENERTAE YOUR OWN SN
COUNTER AND INCLUDE THEM IN MAC
 Bob can generates his own sequence number counter
begins at zero and is incremented for each SSL record he
sends
 This prevents Mallory from carrying out a man-in-the-
middle attack, such as reordering or replaying segments
Data Transfer, Bob sends - Almost SSL
Credit card Order Postal address Billing
information information address

Record1 Record2 Record3 Record4

Hash f(x)

 Record1 along with MB & SN -----------> MAC

Encryption f(x) using EB

 Record1 and MAC (appended ) -----------> Encrypted

 This encrypted package is then passed to TCP for transport over the Internet

 2 3
Same procedure for Record , Record , Record 4
Data Transfer, Alice receives - Almost SSL
Credit card Order Postal address Billing
information information address

Record1 Record2 Record3 Record4

This is the actual
MAC
Decrypt using EB

 Encrypted data from Bob ------> Record1 and MAC (appended)

This is the new MAC
Hash f(x)

 Record1 along with MB & SN ------> MAC (new MAC)

 Compare the actual MAC and new MAC, if they are same, there was no alteration

 2 3
Same procedure for Record , Record , Record 4
A More Complete Picture
Real SSL
 The previous slides covered the almost-SSL protocol, what about the actual
SSL??

☺
SSL/TLS Handshake – Real SSL/TLS

 SSL does not mandate that Alice and Bob use a

specific symmetric key algorithm, a specific public-
key algorithm, or a specific MAC
 SSL allows to agree on all these algorithms during the
handshake
 Also, during the handshake phase, they send nonces
to each other, used in the creation of the session keys
(EB, MB, EA, and MA)
Q. Where Alice and Bob use symmetric key algorithm?
Q. Where Alice and Bob use public key algorithm?
Q. Where Alice and Bob use MAC algorithm?
SSL/TLS Handshake - Real SSL/TLS

The steps of the real SSL handshake…

 Bob sends a list of the supported cryptographic
algorithms with a client nonce (A.K.A cipher suites)
 Cipher suites, allows the server and client to
negotiate an encryption and MAC algorithm and
cryptographic algorithms to be used to protect data
sent in an SSL record
SSL/TLS Handshake - Real SSL/TLS
Cipher suites
Cipher suites, allows the
server and client to
negotiate an encryption
and MAC algorithm and
cryptographic keys to be
used to protect data sent in
an SSL record.
SSL/TLS Handshake - Real SSL/TLS

The steps of the real SSL handshake…

 Alice chooses a symmetric algorithm, an
asymmetric algorithm, and a MAC algorithm
 Alice sends back to Bob its choices, as well as
a certificate and a server nonce
SSL/TLS Handshake - Real SSL/TLS

 Bob verifies the certificate, extracts the server’s public key, generates a Pre
Master Key (PMS), encrypts the PMS with the server’s public key, and sends
the encrypted PMS to the server
SSL/TLS Handshake - Real SSL/TLS

 Using the same key derivation function, the client

and server independently compute the Master
Secret (MS) from the PMS and nonces
 The MS is then sliced up to generate the two
encryption and two MAC keys. Henceforth, all
messages sent between client and server are
encrypted and authenticated (with the MAC)
SSL/TLS Handshake - Real SSL/TLS

 The last two steps:

 The client sends a MAC of all the handshake messages
 The server sends a MAC of all the handshake messages

…protect the handshake from tampering

Q. Why do we need to protect the handshake?

Q. How they generate the handshake MAC and protect it?
SSL/TLS Handshake - Real SSL/TLS

 Why do we need nonces during handshaking?

 Don’t sequence numbers suffice for preventing the segment replay
attack?
 Yes, but they don’t alone prevent the “connection replay attack.”
 Mallory can sniff all messages between Alice and Bob
 The next day, Mallory masquerades as Bob and sends to Alice exactly the
same sequence of messages that Bob sent to Alice on the previous day
 If Alice doesn’t use nonces, she will respond with exactly the same
sequence of messages she sent the previous day
 Alice will not suspect any funny business, as each message she receives
will pass the integrity check
 Alice thinks Bob placing the second order
SSL/TLS Handshake - Real SSL/TLS

 On the other hand, by including a nonce in the protocol,

Alice will send different nonces for each TCP session,
causing the encryption keys to be different on the two
days
 Therefore, when Alice receives played-back SSL records
from Mallory, the records will fail the integrity checks
 In summary, in SSL, nonces are used to defend against
the “connection replay attack” and sequence numbers
are used to defend against replaying individual packets
during an ongoing session
Change Cipher Spec Protocol

 The change cipher spec protocol exists to

signal transitions in ciphering strategies
 The change cipher spec message is sent by
both the client and server to notify the
receiving party that subsequent records
will be protected under the just-negotiated
CipherSpec and keys
Connection Closure

 Either Bob or Alice will want to end the SSL session

 One approach:
 Having Bob send a TCP FIN segment to Alice
 What is FIN?
Connection Closure Cont.

 Either Bob or Alice will want to end the SSL session

 One approach:
 FIN is a naïve approach as it vulnerable to truncation attack
Connection Closure Cont.

• Truncation attack
 Mallory once again gets in the middle of an ongoing SSL
session and ends the session early with a TCP FIN
 Alice would think she received all of Bob’s data when
actuality she only received a portion of it
 But what would be a solution?
Connection Closure Cont.

• To indicate the type field in SSL record

• In SSL record, it is in clear text but it will be
authenticated at the receiver using the record’s MAC
• This is an addition to TCP FIN and does not replace it
Q. What would happen if Alice receives TCP FIN after connection
closure?
Q. What would happen if Alice receives FIN before connection closure?
Browser Exploit Against SSL/TLS Attack
(BEAST)

• This attack was revealed at the Ekoparty Security Conference in 2011

• BEAST is based on a type of cryptographic attack called the “chosen plain text
attack”
• BEST vulnerability in TLS 1.0 came from the use of Cipher Block Changing (CBC)
mode encryption
Cipher Block Changing (CBC) mode
encryption Cont.

• In CBC mode, to make each message unique, an Initialization Vector (IV) is used
in the first block
• An IV is a random string that is XORed with the plaintext message prior to
encryption
How Is the Attack Accomplished?

 It was noticed that TLS 1.0

 An attacker who can see the encrypted traffic
can note the IV used for session cookie
 An active attacker will be able to gather the IVs
for each record just by sniffing the network
 So if the attacker can “guess” a plaintext
message, he can see if the cipher text matches
Practical example
Limitations
 The attacker has to be in the same network and play a MITM attack

 The attacker has to modify the traffic to see if the results match; as a
result, multiple requests have to be sent in this process

 The attacker can guess only one block at a time

Solution

 This is a vulnerability in block ciphers that use the CBC mode of operation. It
was identified in TLS 1.0. However it was addressed in TLS 1.1 and TLS 1.2 by
the use of “explicit IVs” for each block.
 Hence, TLS 1.1 and TLS 1.2 are not exposed to this attack.
Solution Cont.

 Some of the browsers have attempted to implement a solution to address

the vulnerability while still remaining compatible with the SSL 3.0/TLS 1.0
protocol

 Apple’s Safari, even though it has released a mitigation, has chosen to keep it
disabled by default

 Google: Update to Chrome 16 or later

 Microsoft: Apply the patch MS12-006

 Mozilla: Update to Firefox 10 or later

New Features in TLS 1.1 and 1.2

 IETF standard RFC 2246 similar to SSLv3

 With minor differences
 in record format version number
 uses HMAC for MAC
 a pseudo-random function expands secrets
 has additional alert codes
 some changes in supported ciphers
 changes in certificate negotiations
 changes in use of padding
Improvement with TLS 1.3

 In 2013, started working on TLS 1.3.

 The main objectives to be address in TLS 1.3:
 Reducing handshake latency
 Encrypting more of the handshake
 Improving resiliency to cross-protocol attacks
 Removing legacy features
 Two main advantages TLS 1.3 has over previous versions:
 Security
 Performance
Improvement with TLS 1.3

 TLS is a “hybrid” cryptosystem

 It uses both symmetric key cryptography and Asymmetric key
cryptography.
 Asymmetric key crypto is slow and expensive - to establish a shared secret
between both parties
 Symmetric key crypto is fast and cheap - to create symmetric keys that
can be used to encrypt the data exchanged
 Hybrid encryption schemes let a lot of encrypted data to be sent with very
little overhead by only doing the expensive establishment of symmetric
keys once.
 Much of the work in TLS 1.3 has been about improving the part of
the handshake
 Where Asymmetric key crypto is used to establish symmetric keys.
Improvement with TLS 1.3
 In comparison with the predecessor, TLS 1.3
 Eliminates support for outmoded algorithms and ciphers
 RC4 Stream Cipher
 SHA-1 Hash Function
 MD5 Algorithm
 DES
 3DES
 Simplified Key Exchange
 Eliminates RSA key exchange, mandates Perfect Forward Secrecy
 Eliminates Various non-ephemeral Diffie-Hellman groups
 Leaves ephemeral Diffie-Hellman families as the only key exchange mechanism
 Eliminates block mode ciphers
 Eliminates CBC (Block) Mode Ciphers
 EXPORT-strength ciphers: low-grade cryptographic ciphers that were authorized to be used outside the US
during the 1990’s. This allowed intelligence agencies greater ease to eavesdrop on foreign communication
channels of interest.

 Mandates AEAD (Authenticated Encryption with Additional Data) bulk encryption

Improvement with TLS 1.3

 In comparison with the predecessor, TLS 1.3

 Supports additional elliptic curves
 Uses HKDF cryptographic extraction and key derivation
 HKDF is a simple key derivation function (KDF) based on HMAC message
authentication code.
 Reduces the number of negotiations in the handshake
Improvement with TLS 1.3

 In comparison with the predecessor, TLS 1.3

 Reduces the number of algorithms in a cipher suite to 2
 TLS 1.2 and its predecessors use Cipher Suites that include 4 ciphers.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 In TLS 1.3, cipher suites no longer include the signature and key exchange algorithms.
Now it’s just the bulk cipher and the hashing algorithm.
TLS_AES_256_GCM_SHA384
 TLS 1.3 now just recommends five cipher suites:
 TLS_AES_256_GCM_SHA384
 TLS_CHACHA20_POLY1305_SHA256
 TLS_AES_128_GCM_SHA256
 TLS_AES_128_CCM_8_SHA256
 TLS_AES_128_CCM_SHA256
Improvement with TLS 1.3

 In comparison with the predecessor, TLS 1.3

 Offers 1-RTT (single Round-Trip Time) mode and Zero Round
Trip Resumption
 Signs the entire handshake, an improvement of TLS 1.2
SSL vs. OpenSSL

 OpenSSL is a tool and a library that can be used to

Generate Certificate Requests (CSR), self-signed
certificates and issue certificates from a Certificate
Authority (CA), if it's a CA you control of course
 SSL is bought from a CA e.g. thawte while OpenSSL is
self-issued
 The biggest difference between a self-issued (with
OpenSSL) certificate and one you buy from thawte (or
somewhere else) is that of trust
SSL vs. OpenSSL Cont.

 If you want your users to access your SSL enabled website

without being prompted for "do you trust the certificate
from this issuer?“, you need to buy a certificate from
a trusted certification authority, such as thawte or one of
the others
 If you only have a few people accessing your SSL enabled
site, you may convince them to trust your self-issued
certificate and save the money for the certificate
 Or you make your users import it explicitly (which is fine
for corporate CAs for example, but is impractical in
general)
SSL/TLS Benefits

 Ease of implementation
 For network application developers
 As easy as implementing unsecured Sockets

 For network implementation developers

 Simply add layer to established network protocol stack
 For Users
 Only need to authorize certificates
SSL/TLS Drawbacks

 More bandwidth needed

 Slower
 Needs a dedicated port – 443 for HTTPS
 Assumes reliable transport for underlying
transport protocol
 No UDP
 Implications for streaming media, VoIP