Lecture 25 Secure Communications CPE 401 / 601 Computer Network Systems slides are modified from Jim Kurose & Keith Ross and Dave Hollinger
Dec 19, 2015
Lecture 25
Secure Communications
CPE 401 / 601Computer Network Systems
slides are modified from Jim Kurose & Keith Ross and Dave Hollinger
Secure Protocols
There are a growing number of applications for secure protocols email electronic commerce electronic voting
Many application protocols include the use of cryptography as part of application level protocol The Cryptographic scheme employed is part of the
protocol If stronger cryptographic tools become available we
need to change the protocol
Secure Communications 2
Message Integrity
Bob receives msg from Alice, wants to ensure: message originally came from Alice message not changed since sent by Alice
Cryptographic Hash: takes input m, produces fixed length value, H(m)
e.g., as in Internet checksum
computationally infeasible to find two different messages, x, y such that H(x) = H(y) equivalently: given m = H(x), (x unknown), can not
determine x. note: Internet checksum fails this requirement!
Secure Communications 3
Internet checksum: poor crypto hash function
Internet checksum has some properties of hash function: produces fixed length digest (16-bit sum) of message is many-to-one
But given message with given hash value, it is easy to find another message with same hash value:
I O U 10 0 . 99 B O B
49 4F 55 3130 30 2E 3939 42 4F 42
message ASCII format
B2 C1 D2 AC
I O U 90 0 . 19 B O B
49 4F 55 3930 30 2E 3139 42 4F 42
message ASCII format
B2 C1 D2 ACdifferent messagesbut identical checksums!
Secure Communications 4
Message Authentication Code
m
s(shared secret)
(message)
H(.)H(m+s)
publicInternetappend
m H(m+s)
s
compare
m
H(m+s)
H(.)
H(m+s)
(shared secret)
Secure Communications 5
MACs in practice
MD5 hash function widely used (RFC 1321) computes 128-bit MAC in 4-step process. arbitrary 128-bit string x, appears difficult to
construct msg m whose MD5 hash is equal to x
• recent (2005) attacks on MD5
SHA-1 is also used US standard [NIST, FIPS PUB 180-1]
160-bit MAC
Secure Communications 6
Digital Signatures
cryptographic technique analogous to hand-written signatures.
sender (Bob) digitally signs document, establishing he is document owner/creator.
verifiable, nonforgeable: recipient (Alice) can prove to someone that Bob, and
no one else (including Alice), must have signed document
Secure Communications 7
Digital Signatures
simple digital signature for message m: Bob “signs” m by encrypting with his private
key KB, creating “signed” message, KB(m)--
Dear Alice
Oh, how I have missed you. I think of you all the time! …(blah blah blah)
Bob
Bob’s message, m
public keyencryptionalgorithm
Bob’s privatekey
K B-
Bob’s message, m, signed (encrypted) with his private key
K B-(m)
Secure Communications 8
Digital Signatures (more) suppose Alice receives msg m, digital signature
KB(m)
Alice verifies m signed by Bob by applying Bob’s public key KB to KB(m) then checks KB(KB(m) ) =
m.
if KB(KB(m) ) = m, whoever signed m must have
used Bob’s private key.
Alice thus verifies that: Bob signed m. No one else signed m. Bob signed m and not m’.
non-repudiation: Alice can take m, and signature KB(m) to court
and prove that Bob signed m.
+ +
-
-
- -
+
-
Secure Communications 9
Digital signature = signed MAC
Alice verifies signature and integrity of digitally signed message:
large messagem
H: hashfunction H(m)
digitalsignature(encrypt)
Bob’s private
key K B-
+
Bob sends digitally signed message:
KB(H(m))-
encrypted msg digest
KB(H(m))-
encrypted msg digest
large messagemH: hashfunction
H(m)
digitalsignature(decrypt)
H(m)
Bob’s public
key K B+
equal ?
Secure Communications 10
Public Key Certification
public key problem: When Alice obtains Bob’s public key (from web
site, e-mail, diskette), how does she know it is Bob’s public key, not Trudy’s?
solution: trusted certification authority (CA)
Secure Communications 11
Certification Authority (CA): binds public key to particular entity, E.
E registers its public key with CA. E provides “proof of identity” to CA. CA creates certificate binding E to its public key. certificate containing E’s public key digitally signed by CA:
CA says “This is E’s public key.”
Certification Authorities
Bob’s public
key K B+
Bob’s identifying informatio
n
digitalsignature(encrypt)
CA private
key K CA-
K B+
certificate for Bob’s public
key, signed by CA
-K CA(K ) B+
Secure Communications 12
when Alice wants Bob’s public key: gets Bob’s certificate (Bob or elsewhere). apply CA’s public key to Bob’s certificate,
get Bob’s public key
Certification Authorities
Bob’s public
key K B+
digitalsignature(decrypt)
CA public
key K CA+
K B+
-K CA(K ) B+
Secure Communications 13
Secure e-mail
Alice: generates random symmetric private key, KS. encrypts message with KS (for efficiency) also encrypts KS with Bob’s public key. sends both KS(m) and KB(KS) to Bob.
Alice wants to send confidential e-mail, m, to Bob.
KS( ).
KB( ).+
+ -
KS(m
)
KB(KS )+
m
KS
KS
KB+
Internet
KS( ).
KB( ).-
KB-
KS
mKS(m
)
KB(KS )+
Secure Communications 14
Secure e-mail
Bob: uses his private key to decrypt and recover KS
uses KS to decrypt KS(m) to recover m
Alice wants to send confidential e-mail, m, to Bob.
KS( ).
KB( ).+
+ -
KS(m
)
KB(KS )+
m
KS
KS
KB+
Internet
KS( ).
KB( ).-
KB-
KS
mKS(m
)
KB(KS )+
Secure Communications 15
Secure e-mail (continued)
• Alice wants to provide sender authentication message integrity.
• Alice digitally signs message.• sends both message (in the clear) and digital signature.
H( ). KA( ).-
+ -
H(m )KA(H(m))-
m
KA-
Internet
m
KA( ).+
KA+
KA(H(m))-
mH( ). H(m )
compare
Secure Communications 16
Secure e-mail (continued)• Alice wants to provide secrecy, sender authentication, message integrity.
Alice uses three keys: her private key, Bob’s public key, newly created symmetric key
H( ). KA( ).-
+
KA(H(m))-
m
KA-
m
KS( ).
KB( ).+
+
KB(KS )+
KS
KB+
Internet
KS
Secure Communications 17
Pretty good privacy (PGP)
Internet e-mail encryption scheme,
de-facto standard.
uses symmetric key cryptography, public key cryptography, hash function, and digital signature as described .
provides secrecy, sender authentication, integrity.
---BEGIN PGP SIGNED MESSAGE---Hash: SHA1
Bob:My husband is out of town tonight.Passionately yours, Alice
---BEGIN PGP SIGNATURE---Version: PGP 5.0Charset: noconvyhHJRHhGJGhgg/
12EpJ+lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2
---END PGP SIGNATURE---
A PGP signed message:
Secure Communications 18
Secure sockets layer (SSL) provides transport layer security to any TCP-
based application using SSL services. e.g., between Web browsers, servers for e-commerce
security services: server authentication, data encryption, client authentication (optional)
TCP
IP
TCP enhanced with SSL
TCP socket
Application
TCP
IP
TCP API
SSL sublayer
Application
SSLsocket
Secure Communications 19
SSL: three phases
1. Handshake: Bob establishes TCP
connection to Alice authenticates Alice
via CA signed certificate
sends master secret key to Alice encrypted with Alice’s
public key nonce exchange not
shown
SSL hello
certificate
KA+(MS)
TCP SYN
TCP SYNACK
TCP ACK
decrypt using KA
-
to get MS
create MasterSecret (MS)
Secure Communications 20
SSL: three phases
2. Key Derivation: Alice, Bob use shared secret (MS) to generate
4 keys: EB: Bob->Alice data encryption key
EA: Alice->Bob data encryption key
MB: Bob->Alice MAC key
MA: Alice->Bob MAC key
encryption and MAC algorithms negotiable between Bob, Alice
Secure Communications 21
SSL: three phases3. Data transfer
H( ).MB
b1b2b3 … bn
d
d H(d)
d H(d)
H( ).EB
TCP byte stream
block n bytes together compute MAC
encrypt d, MAC, SSL seq. #
SSL seq. #
d H(d)Type Ver Len
SSL record format
encrypted using EBunencrypted
Secure Communications 22
HTTPS Usage
HTTPS is HTTP running over SSL. used for most secure web transactions.
HTTPS server usually runs on port 443.
Include notion of verification of server via a certificate.
Central trusted source of certificates.
Secure Communications 23
IPsec: Network Layer Security
network-layer secrecy: sending host encrypts the
data in IP datagram TCP and UDP segments;
ICMP and SNMP messages. network-layer authentication
destination host can authenticate source IP address
two principal protocols: authentication header
(AH) protocol encapsulation security
payload (ESP) protocol
for both AH and ESP, source, destination handshake: create network-layer
logical channel called a security association (SA)
each SA unidirectional. uniquely determined by:
security protocol (AH or ESP)
source IP address 32-bit connection ID
Secure Communications 24
Authentication Header (AH) Protocol provides source
authentication, data integrity, no confidentiality
AH header inserted between IP header, data field.
protocol field: 51 intermediate routers
process datagrams as usual
AH header includes: connection identifier authentication data:
source- signed message digest calculated over original IP datagram.
next header field: specifies type of data (e.g., TCP, UDP, ICMP)
IP header data (e.g., TCP, UDP segment)AH header
Secure Communications 25
ESP Protocol
provides secrecy, host authentication, data integrity.
data, ESP trailer encrypted.
next header field is in ESP trailer.
ESP authentication field is similar to AH authentication field.
Protocol = 50.
IP header TCP/UDP segmentESPheader
ESPtrailer
ESPauthent.
encryptedauthenticated
Secure Communications 26
Kerberos
Trusted 3rd party authentication scheme
Assumes that hosts are not trustworthy
Requires that each client (each request for service) prove it’s identity
Does not require user to enter password every time a service is requested!
Kerberos 28
Kerberos Design User must identify itself once at the
beginning of a workstation session login session
Passwords are never sent across the network in cleartext or stored in memory
Every user has a password. Every service has a password. The only entity that knows all the
passwords is the Authentication Server. Kerberos 29
Kerberos 30
ServerServerServerServerServerServerServerServer
ServerServerServerServerServerServerServerServer
KerberosKerberosDatabaseDatabase
Ticket GrantingTicket Granting ServerServer
Ticket GrantingTicket Granting ServerServer
AuthenticationAuthentication ServerServer
AuthenticationAuthentication ServerServer
WorkstationWorkstationWorkstationWorkstation
Kerberos Key Distribution ServiceKerberos Key Distribution Service
Secret Key Cryptography
The encryption used by current Kerberos implementations is DES, Kerberos V5 has hooks so that other
algorithms can be used.
encryption plaintext ciphertext
keyciphertext plaintext
decryption Kerberos 31
Tickets Each request for a service requires a ticket.
A ticket provides a single client with access to a single server.
Tickets are dispensed by the “Ticket Granting Server” (TGS), which has knowledge of all the encryption keys.
Tickets are meaningless to clients, they simply use them to gain access to servers.
Kerberos 32
Tickets (cont.)
The TGS seals (encrypts) each ticket with the secret encryption key of the server.
Sealed tickets can be sent safely over a network only the server can make sense out of it
Each ticket has a limited lifetime a few hours
Kerberos 33
Ticket Contents
Client name (user login name)
Server name
Client Host network address
Session Key for Client/Server
Ticket lifetime
Creation timestamp
Kerberos 34
Session Key
Random number that is specific to a session.
Session Key is used to seal client requests to server.
Session Key can be used to seal responses application specific usage
Kerberos 35
Authenticators
Authenticators prove a client’s identity.
Includes: Client user name. Client network address. Timestamp.
Authenticators are sealed with a session key.
Kerberos 36
Bootstrap
Each time a client wants to contact a server, it must first ask the 3rd party (TGS) for a ticket and session key.
In order to request a ticket from the TGS, the client must already have a TG ticket and a session key for communicating with the TGS !
Kerberos 37
Authentication Server
The client sends a plaintext request to the AS asking for a ticket it can use to talk to the TGS.
REQUEST: login name TGS name
Since this request contains only well-known names, it does not need to be sealed.
Kerberos 38
Authentication Server
The AS finds the keys corresponding to the login name and the TGS name.
The AS creates a ticket: login name TGS name client network address TGS session key
• The AS seals the ticket with the TGS secret key.
Kerberos 39
Authentication Server Response The AS also creates a random session key
for the client and the TGS to use. The session key and the sealed ticket are
sealed with the user (login name) secret key.
Kerberos 40
TGS session key
Ticket:login nameTGS namenet addressTGS session key
Sealed with user keySealed with user key
Sealed with TGS keySealed with TGS key
Accessing the TGS
The client decrypts the message using the user’s password as the secret key.
The client now has a session key and ticket that can be used to contact the TGS.
The client cannot see inside the ticket, since the client does not know the TGS secret key.
Kerberos 41
Accessing a Server
When a client wants to start using a server (service), the client must first obtain a ticket.
The client composes a request to send to the TGS:
Kerberos 42
TGS Ticket
Authenticator
Server Name
sealed withsealed withTGS keyTGS key
sealed withsession key
TGS response
The TGS decrypts the ticket using it’s secret key. Inside is the TGS session key.
The TGS decrypts the Authenticator using the session key.
The TGS check to make sure login names, client addresses and TGS server name are all OK.
TGS makes sure the Authenticator is recent. Kerberos 43
TGS Response
Once everything checks out - the TGS:
builds a ticket for the client and requested server. The ticket is sealed with the server key.
creates a session key
seals the entire message with the TGS session key and sends it to the client.
Kerberos 44
Client accesses Server
The client now decrypts the TGS response using the TGS session key.
The client now has a session key for use with the new server, and a ticket to use with that server.
The client can contact the new server using the same format used to access the TGS.
Kerberos 45
Kerberos Summary Every service request needs a ticket. Tickets come from the TGS
except the ticket for the TGS!
Workstations cannot understand tickets, they are encrypted using the server key.
Every ticket has an associated session key. Tickets are reusable. Tickets have a finite lifetime. Authenticators are only used once
new connection to a server
Authenticators expire fast ! Server maintains list of authenticators
prevent stolen authenticators Kerberos 46