Upload
lycong
View
239
Download
0
Embed Size (px)
Citation preview
1
310 Computer Networks Department of Computer Science Wellesley College
Securing communcations Secure E-mail & SSL
Securing Communications 30-2
Getting it right o We mortals should never
need to design our own cryptographic algorithms.
o However, it may be the case that we will need to design security features into protocols.
o We had better understand (at least some of) what can go wrong.
2
Protocol 1.0. Name only o Many protocols were designed in an environment where
authentication was not a concern. A
lice
Bob I’m Alice
Securing Communications 30-3
Protocol 2.0. Name and IP address
Alic
e
Bob I’m Alice
Alice’s IP address
Securing Communications 30-4
3
Protocol 3.1. Name and encrypted password
Alic
e
Bob I’m Alice, KA-B(fiddlesticks)
Securing Communications 30-5
Protocol 4.0. Name and nonce*
Alic
e
Bob
I’m Alice
R
KA-B(R)
*A nonce is a number that a protocol will use only once in a lifetime.
Securing Communications 30-6
4
Protocol 4.1. Alice signs away the farm o Our protocols based on shared secrets all have several
disadvantages. Secret keys must be exchanged. Furthermore, a bad guy can impersonate Alice if he can read Bob’s database.
o Protocols based on public key technology can avoid this.
Alic
e
Bob
I’m Alice
a challenge R
KA-[R]
Securing Communications 30-7
Protocal 4.2. Let’s try that one again
Alic
e
Bob
I’m Alice
R
*A minor variant, possible with reversible public key schemes that avoids tricking Alice into signing away the farm.
Securing Communications
KA+[R]
30-8
5
How can we avoid getting into trouble? o The general rule is that
you should not use the same key for two different purposes unless the designs for all uses of the key are coordinated.
o Part of the purpose of the Public-key Cryptography Standard is to impose enough structure to prevent this sort of problem.
Securing Communications 30-9
Securing E-Mail o We use the cryptographic principles from last time to
create a secure e-mail system that provides confidentiality, message integrity, and receiver authentication.
Securing Communications 30-10
6
We start with confidentiality*
*Why not just use plain old symmetric crypto then?
plaintext ciphertext
K S
encryption algorithm
decryption algorithm
K S
plaintext message, m
K (m) S m = KS(KS(m))
Securing Communications 30-11
Okay, then use public key crypto
plaintext message, m
ciphertext encryption algorithm
decryption algorithm
Bob’s public key
plaintext message K (m) B
+
K B +
Bob’s private key
K B -
m = K (K (m)) B +
B -
Securing Communications 30-12
7
Best of both worlds
Securing Communications
KS( ) .
KB( ) . +
+ -
KS(m )
KB(KS ) +
m
KS
KS
KB +
Internet
KS( ) .
KB( ) . -
KB -
KS
m KS(m )
KB(KS ) +
30-13
Next we design another system providing authentication and message integrity
Securing Communications
H( ) . KA( ) . -
+ -
H(m ) KA(H(m)) - m
KA -
Internet
m
KA( ) . +
KA +
KA(H(m)) -
m H( ) . H(m )
compare
30-14
8
And combine the two
Securing Communications
H( ) . KA( ) . -
+
KA(H(m)) - m
KA -
m
KS( ) .
KB( ) . +
+
KB(KS ) +
KS
KB +
Internet
KS
30-15
Securing TCP connections o We have seen how
cryptographic techniques can provide confidentiality, data integrity, and end-point authentication to specific applications
o Today, we drop down a protocol layer to examine how to enhance TCP with security services.
o This version of TCP is known as Secure Sockets Layer (SSL).
Securing Communications 30-16
9
Alice buys a new computer online* o If no confidentiality,
Trudy could obtain Alice’s credit card information.
o If no data integrity, Trudy could modify Bob’s order to buy 10 computers.
o If no server authentication is used, Trudy could masquerade as the computer company, take the money and run.
*With no security measures in place. Securing Communications 30-17
SSL and TCP/IP
Application
TCP
IP
normal application
Application
SSL sublayer
TCP
IP
application with SSL
TCP socket TCP socket
SSLsocket
Securing Communications 30-18
10
Almost-SSL o We begin with a simplified
version of SSL which like SSL has three phases: handshake, key derivation, and data transfer.
o Client (Bob) and server (Alice) establish a communication session with Alice having a private/public key pair and a certificate that binds her identity to her public key.
o Bob first establishes a TCP connection.
TCP SYN
TCP SYNACK
TCP ACK
Securing Communications 30-19
Once established, ... o Bob sends Alice a hello
message. o To which Alice responds
with her certificate, which contains her public key.
o Because the certificate has been certified by a CA, Bob knows for sure that public key belongs to Alice.
TCP SYN
TCP SYNACK
TCP ACK SSL hello
certificate
Securing Communications 30-20
11
Bob creates an MS o Bob generates a Master
Secret (MS) which will be used only for this SSL session.
o The MS is encrypted with Alice’s public key to create the Encrypted Master Secret (EMS) which is sent to Alice.
TCP SYN
TCP SYNACK
TCP ACK SSL hello
certificate
EMS = KA+(MS)
Create Master Secret (MS)
Decrypt EMS with KA
-
Securing Communications 30-21
In principle, ... o The shared MS could be
used as the symmetric session key for all subsequent encryption and data integrity checking.
o However, is considered safer for Alice and Bob to each use different cryptographic keys ...
o ... and to use different keys for encryption and integrity checking.
Securing Communications 30-22
12
Both Alice and Bob use MS to generate four keys
o EB = session encryption key for data sent from Bob to Alice
o MB = session key MAC key for data sent from Bob to Alice
o EA = session encryption key for data sent from Alice to Bob
o MA = session MAC key for data sent from Alice to Bob
30-23
Data transfer o Alice and Bob share four
sessions keys and can start to send secured data to each other over TCP.
o Since TCP is a byte-stream protocol, we could encrypt application data on the fly and then pass the encrypted data on the fly to TCP.
o But where would be put the MAC for the integrity check?
Securing Communications 30-24
13
SSL breaks the data stream into records ...
MCompare
Destination B
| |S
| | M
H
H
Source A
H(M | | S)
| |S
o ... appends a MAC to each record to integrity checking, then encrypts the record + MAC.
o To create the MAC, Bob inputs the record M along S = MB into a hash function H. The record+MAC is encrypted with his session key EB. We’ve seen this part before:
Securing Communications
B A
Entire message is then encrypted using EB on
B’s side …
and decrypted on A’s side
30-25
Bad news for
Bois owes Bullwinkle $10,000 Plaintext records
tsrwmqp wplsmaka os02%sb@ gwom*bxz SSL records
os02%sb@
wplsmaka tsrwmqp gwom*bxz
Altered SSL records
Bullwinkle owes Bois $10,000 Altered plaintext records
Securing Communications 30-26
14
The solution, you guessed it ... o Sequence numbers!
Bullwinkle doesn’t add sequence numbers, but maintains a counter, beginning at zero.
o When SSL calculates the MAC, it includes the sequence number in the MAC calculation.
o The MAC is now a hash of the data plus the MAC key MB, plus the current sequence number.
Securing Communications 30-27
Almost the SSL record
content type SSL version length
MAC
Data
1 byte 2 bytes 3 bytes
Securing Communications 30-28
15
SSL record protocol
data
data fragment
data fragment MAC MAC
encrypted data and MAC
encrypted data and MAC
record header
record header
Securing Communications 30-29
Truncation attack o Alice or Bob could end the
SSL session by simpley terminating the underlying TCP connection, i.e., Bob sends a TCP FIN segment to Alice.
o However, suppose Trudy in the middle ends the session early with TCP FIN.
o Alice would think she got the whole story, but didn’t.
Securing Communications 30-30
16
Solution
content type SSL version length
MAC
Data
1 byte 2 bytes 3 bytes
Indicate in the type field whether the record
serves to terminate the SSL session
Securing Communications 30-31
Keeping communication lines open o The RFC 6520 Heartbeat
Extension tests TLS/DTLS secure communication links by allowing a computer at one end of a connection to send a “Heartbeat Request” message, consisting of a payload, typically a text string, along with the payload’s length as a 16-bit integer.
o The receiving computer then must send the exact same payload back to the sender.
Securing Communications 30-32
17
Oops, I did it again o Heartbleed is a security
bug in the open-source OpenSSL cryptography library, which is widely used to implement the Internet's Transport Layer Security (TLS) protocol.
o This vulnerability, classified as a buffer over-read, results from a missing bounds check in the handling of the Transport Layer Security (TLS) heartbeat extension, the heartbeat being behind the bug's name.
Securing Communications 30-33