Authentication and
Secure Communication
Jeff Chase
Duke University
technology
people
Where are the boundaries of the “system” that you
would like to secure?
Where is the weakest link?
What happens when the weakest link fails?
The First Axiom of Security
• “Security is at least as much a social problem as it is a
technical problem.”
– Translation: humans are the weak link.
• We will focus on the technical elements, but do not
lose sight of the social dimension.
– Keys left in lock
– Phishing
– Executable attachments
– Trojan software
– Post-it passwords
– Bribes, torture, etc.
– Etc.
Exhibit A
This is a picture of a $2.5B move in the value of Emulex Corporation, in
response to a fraudulent press release by short-sellers through InternetWire in
2000. The release was widely disseminated by news media as a statement
from Emulex management, but media failed to authenticate it.
EMLX
[reproduced from clearstation.com]
“Humans are incapable of securely storing high-quality
cryptographic keys, and they have unacceptable speed and
accuracy when performing cryptographic operations. (They
are also large, expensive to maintain, difficult to manage, and
they pollute the environment.) It is astonishing that these
devices continue to be manufactured and deployed. But they
are sufficiently pervasive that we must design our protocols
around their limitations.”
- Kaufman, Perlman, and Speciner
As quoted in:
Trusted vs. Trustworthy (NSA)
• Trusted
– A component that can break the security policy if
it fails. (“It has power.”)
– Integrity cannot be verified by external
observation. (“You can’t tell if it breaks”.)
• Trustworthy
– A component that is unlikely to fail.
• Trusted Computing Base (TCB)
– The minimal core of a computer system that is
trusted, and so must be trustworthy if the system
is to remain safe.
Questions and Answers #1
• Who is the sender?
– Authentication
• Is the sender allowed to do this?
– Authorization
• Is this really what the sender said?
– Integrity
• Could anyone else have intercepted it?
– Privacy
Questions and Answers #2
• Authentication?
– Challenge/response: passwords, certificates
– A subject bound to a strong identity is a principal.
• Authorization?
– Access control lists or capabilities (ticket/token)
• Integrity?
– Message digests and digital signatures
• Privacy
– Encryption (provides integrity too)
All of these require some form of a shared secret or
shared trust in a third party, or both.
Security
Cryptography
algorithms
Secret
key
(e.g., DES)
Public
key
(e.g., RSA)
Security
services
Message
digest
(e.g., MD5)
Privacy
Authentication
Message
integrity
Familiar names for the
protagonists in security
protocols
Alice
First participant
Bob
Second participant
Carol
Participant in three- and four-party protocols
Dave
Participant in four-party protocols
Eve
Eavesdropper
Mallory
Malicious attacker
Sara
A server
Cryptography for Busy People
• Encrypt and Decrypt functions
– M = Decrypt(Encrypt(M)
– Standard and efficient enough to be practical.
• Crypto functions are parameterized by keys.
– Fixed-width “random” value (length matters)
– M = Decrypt(Encrypt(M,K1), K2)
• Two fundamental variants:
– Public-key or asymmetric crypto (e.g., RSA)
– Secret-key, private-key, symmetric crypto (e.g., DES)
• Foundation of many/all protection systems.
Crypto Properties
– Given Encrypt(K1, M)
• cannot compute M (without K2).
– Given M and Encrypt(K1, M)
• cannot compute K1 or K2
– Given M
• cannot compute M1 such that
Decrypt(K2, M1) = M (without K1)
– “Cannot” means “it is believed to be
computationally infeasible to”.
Using Crypto: the Basics
• Privacy
– Attacker cannot read encrypted data.
• Integrity
– Encrypt a hash/checksum/digest of the message.
• Digital signature
– Append signature to the message
• Authentication
– Force party to prove it possesses some key that
only the “right” entity would/could/should know.
– How to do that safely?
Simple shared-secret based
cryptographic authentication
shuque@isc.upenn.edu
Replay Attacks and Nonces
• The “random” challenge is a nonce
– “number used once”
– Receiver encrypts the nonce and sends it back.
• Why is the challenge “random” or “only used once”?
– An attacker could replay a previous response
– The replay could falsely authenticate the attacker
as Alice
• Nonces can be timestamps, serial numbers, etc.
• Replay attacks are a common threat, and nonces are
widely used in security protocols.
Symmetric Crypto
• “Secret key” or “private key” cryptography.
– DES, 3DES, DESX, IDEA, AES
• Sender and receiver must possess a shared secret
– Shared key K
– K = K1 = K2
• Message M, Key K
{M}K = Encrypt(M, K)
M = Decrypt({M}K , K)
Asymmetric Crypto
• Sometimes called “public key” cryptography.
• Each subject/principal possesses a keypair: K-1 and K
– Decrypt(K, Encrypt(K-1, M)) = M
• Each principal keeps one key private.
• The inverse key may be public.
• Either key can be used to encrypt/decrypt.
– Encrypt() = Decrypt()
– K1 = K and K2 = K-1 OR K2 = K and K1 = K-1
Pros and Cons
Symmetric crypto (DES, AES, …)
– Pro: cheap and easily supported by hardware
– Con: need a shared secret.
• Shared secrets are harder to keep secret.
• key distribution problem
Asymmetric crypto (RSA, etc.)
– Con: expensive
– Pro: no need for a shared secret
• The recipient just needs to know sender’s public key.
• Multicast or broadcast? Message storage? No problem.
• Solves the private-key distribution problem
– Con: introduces a new public-key distribution problem
• How to bind public key to identity securely?
Figure 7.3
Cryptography notations
KA
Alice’s secret key
KB
Bob’s secret key
KAB
Secret key shared between Alice and Bob
KApriv
Alice’s private key (known only to Alice)
KApub
Alice’s public key (published by Alice for all to read)
{M}K
MessageM encrypted with keyK
[M]K
MessageMsigned with keyK
Performance of encryption
and secure digest algorithms
Key size/hash size ExtrapolatedPRB optimized
(bits)
speed
(kbytes/s)
(kbytes/sec.)
TEA
128
700
-
DES
56
350
7746
Triple-DES
112
120
2842
IDEA
128
700
4469
RSA
512
7
-
RSA
2048
1
-
MD5
128
1740
62425
SHA
160
750
25162
Secure Communication with an
Untrusted Infrastructure
Mallory
ISP D
ISP B
Bob
ISP C
Alice
ISP A
Better Together, Part 1
• Use asymmetric crypto just to “handshake” and establish a
secret session key.
• Converse with the efficiency of symmetric crypto.
• Example: Secure Sockets Layer (SSL) or Transport-Layer
Security (TLS), used in HTTPS.
• End-to-end security above TCP.
“SYN, etc.”
“My public key is K.”
“Let’s establish a session key: {S}K .”
Client
{M}S
…
Server
SSL is not so simple…
• How do we know who we are talking to?
– Do we care? Somebody does…
• How do we prevent replays of encrypted content?
• SSL/TLS uses this basic handshake protocol, but
there are many other aspects:
– Nonces, serial numbers, timestamps
– Hashes and MACs
– Certificates
– First some background…
Authenticity on the Cheap
• How can the sender/writer A of M allow any receiver
B to verify or prove that A sent/stored M?
– authenticity
• Answer: encrypt the message, or just a digest.
– A computes digest h(M) using a secure hash.
–
–
–
–
A encrypts digest: {h(M)}K
A appends encrypted digest to M
B decrypts digest with matching key
B computes h(M) and compares to digest.
• Proves that sender of M was in possession of K.
Secure Hash / Message Digest
• Well-known, standard, hash functions digest = h(M).
– MD5, SHA1 (Secure Hash Algorithm)
– Very efficient to compute.
– M is arbitrary length
– Digest is a small, fixed-width quantity: i.e., it is a hash.
• Often called a fingerprint or cryptographic checksum.
• An encrypted digest can be thought of as a “signature”.
– Unforgeable: need the right key to encrypt
– Securely bound to a specific document!
– Easy to check
Properties of Secure Hashing
– Collision-resistant
• There exist distinct M1 and M2 such that h(M1) == h(M2).
• Such collisions are “hard” to find.
– One way
• Given digest, cannot generate an M with h(M) == digest.
• Such collisions are “hard” to find.
– Secure
• The digest does not help to discover any part of M.
Hasn’t SHA-1 been broken?
Sort of…it turns out collisions are easier to find than
thought, at least in some instances.
Two Flavors of “Signature”
• A digest encrypted with a private asymmetric key is
called a digital signature
– “Proves” that a particular identity sent the message.
• “Unforgeable”
– The sender cannot deny sending the message.
• “non-repudiable”
– Legally binding in the US (if using strong policies to
protect and endorse keys).
• A digest encrypted with a shared symmetric key is called a
message authentication code (MAC).
• faster, but…
Digital signatures with public
keys
M
signed doc
H(M)
Signing
h
E(K pri , h) {h} Kpri
M
128 bits
{h} Kpri
Verif y ing
D(Kpub ,{h})
h'
M
h = h'?
H(doc)
h
Low-cost signatures with a
shared secret key
M
signed doc
H(M+K)
Signing
h
Message
authentication
code (MAC)
M
K
• Pro: fast
• Con: repudiable
• Con: shared secret
M
h
Verify ing
h = h'?
K
H(M+K)
h'
Certifying Public Keys
• Digital signatures enable any entity to endorse the
(public key, identity) binding of another entity.
• A certificate is a special type of digitally signed
document:
– “I certify that the public key in this document
belongs to the entity named in this document,
signed X.”
– E.g., certificate format standard X.509
• Provides a “toehold” to address the crucial problem
of public-key distribution.
• Recipient must trust the issuer X, and must know
the public key of X.
Figure 7.13
X509 Certificate format
Subject
Distinguished Name, Public Key
Issuer
Distinguished Name, Signature
Period of validity
Not Before Date, Not After Date
Administrativeinformation
Version, Serial Number
Extended Information
Certifying Authorities and
Trust Management
• What (id)entities do you trust?
– To do what?
– I trust Amazon if I want to buy stuff, but I don’t
give them the keys to my house. (?)
• In general, your trust in a public key depends on:
– Security attributes of the identity bound to it.
– Who endorsed it for me.
• A certifying authority (CA) is an identity trusted by
some community to issue/endorse certificates.
– Public key of CA is widely available to community.
– E.g., the public key of Verisign is wired into every
browser.
Approaches to Public Key
Distribution
• The “key” challenge today is public key distribution (and
revocation).
• Approach #1: trust e-mail/web (i.e., assume DNS and IP really
go where you want, and authenticate the source.)
– Example: PGP, GPG, “pretty good”…or do it in person.
• Approach #2 : use a Public Key Infrastructure (PKI)
– Requires everyone to agree on a central point of trust
(Certifying Authority or CA).
– Difficult to understand and deploy.
– Hierarchy helps.
• Approach #3: “web of trust” in which parties establish pairwise
trust and endorse public keys of third parties.
– Local example: SHARP. Involves transitive trust.
Certificate Hierarchy
or Web of Trust
• Chain of Trust
– If X certifies that a certain public key belongs to
Y, and Y certifies that another public key belongs
to Z, then there exists a chain of certificates
from X to Z
– Someone that wants to verify Z’s public key has to
know X’s public key and follow the chain
– X forms the root of a tree (web?)
• Certificate Revocation List
– What happens when a private key is compromised?
[Vahdat]
PKI
• Public Key Infrastructure
• Everyone trusts some root CAs.
– Sure….
• Institutions/organizations set up their own CAs, and
the root CAs endorse them to issue certificates for
their members.
– $$$
• And so on, recursively, to form a hierarchy like DNS.
• Network applications will have access to the keypairs
and certificates of their users, and will validate the
certificates of servers.
– Any day now…
What happens…
https://www.shop.com/shop.html
•
•
•
•
How to authenticate shop.com?
How to assure integrity/privacy of communications?
How to prevent man-in-the-middle attack?
How does shop.com authenticate you?
Secure HTTP
• Uses SSL/TLS over TCP.
• Browser always authenticates the server.
– Server presents certificate signed by root CA.
– Domain name must match the certificate, etc.
– Browser has some set of public keys for root CAs
wired into it, so it can check the signature.
• Server optionally requests to authenticate the
browser.
– Browser presents certificate.
– Password authentication is much more common.
• Browser and server negotiate a bulk cipher and
secret session key.
A Short Quiz
1. What is the most important advantage of symmetric
crypto (DES) relative to asymmetric crypto (RSA)?
2. What is the most important advantage of
asymmetric crypto relative to symmetric crypto?
3. What is the most important limitation/challenge for
asymmetric crypto with respect to security?
4. Why does SSL “change ciphers” during the
handshake?
5. How does SSL solve the key distribution problem for
symmetric crypto?
6. Is key exchange vulnerable to man-in-the-middle
attacks?
CPS 110, Fall 2008
• All the preceding material is “fair game”.
• The preceding material is also presented in a
different way on Landon Cox’s slides.
• The following details of SSH, Kerberos, TPM, etc. are
left in for completeness, but will not be tested.
• I discussed TPM briefly in class, but I only expect
you to understand the key idea: the hardware
platform makes signed assertions to software about
the software running below it, and it can hide data
(keys) if the software stack is not “right”.
CPS 110 Fall 2008, continued
• We discussed TPM with reference to Butler
Lampson’s “Accountability and Freedom”, which can be
found through Google.
• Key ideas from Lampson’s presentation that are “fair
game”:
– Concept of “reference monitor”
– Classical security based on Authentication,
Authorization, and Auditing
– Alternative approaches based on reputation and
accountability: punishing transgressions after the
fact.
Handshake Protocol Structure
ClientHello
ServerHello,
[Certificate],
[ServerKeyExchange],
[CertificateRequest],
ServerHelloDone
C
[Certificate],
ClientKeyExchange,
[CertificateVerify]
switch to negotiated cipher
Finished
switch to negotiated cipher
Finished
S
Figure 7.18
SSL handshake protocol
Es tablis h pr otocol ver sion, sess ion ID,
cipher s uite, compres sion method,
exc hang e random values
Cl ientH ello
ServerH ello
Certific ate
Opti onall y send ser ver c ertificate and
Certific ate R equest
req ues t client certific ate
ServerH elloDone
Cl ient
Certific ate
Certific ate Verify
Server
S end client certific ate r esponse i f
req ues ted
Change Cipher Spec
Finished
Change Cipher Spec
Finished
Change cipher s uite and fi nish
handshake
Figure 7.17
SSL protocol stack
SSL
Handshake SSL Change SSL Alert
Cipher Spec Protocol
protocol
HTTP Telnet
SSL Record Protocol
Transport layer (usually TCP)
Network layer (usually IP)
SSL protocols:
Other protocols:
Figure 7.19
SSL handshake configuration
options
Component
Description
Example
Key exchange
method
the method to be used for
exchange of a session key
RSA with public-key
certificates
Cipher for data the block or stream cipher to beIDEA
transfer
used for data
Message digest for creating message
SHA
function
authentication codes (MACs)
OpenSSH
• Uses SSL
– User’s public key installed on host side
– Host’s public key installed on client side
• Or Kerberos
SSL Questions
•
•
•
How do SSL endpoints verify the integrity of
certificates (IDs)?
Does s-http guarantee non-repudiation for electronic
transactions? Why/how or why not?
Does SSL guarantee security of (say) credit numbers
in electronic commerce?
"Using encryption on the Internet is the
equivalent of arranging an armored car to deliver
credit-card information from someone living in a
cardboard box to someone living on a park
bench"
- Gene Spafford, CERIAS @ Purdue
More PKI
• (Public key) infrastructures
– Many organizations now have set up their own
– Many have not (e.g., Duke)
• Public (key infrastructure)
– Still elusive
– Failure of Secure Electronic Transactions (SET)
PGP
• Pretty Good Privacy
• Each user has an asymmetric keypair
• Secure e-mail, possibly with multiple receivers
– Digitally sign message with your private key.
– Encrypt message and signature with random
session key.
– Append session key encrypted with public key of
each intended recipient.
• Users may sign/endorse each other’s public keys and
endorsements.
• Should this be illegal?
– Zimmerman case, 1993
What happens…
https://www.library.duke.edu
Kerberos 101
• Secure end-to-end communication (like SSL)
– But always authenticates both ends
• Trusted authentication server (like SSL)
– But requires synchronous interaction with AS
• Symmetric crypto only
– No RSA, no certificates, no PKI.
– (Actually, webauth uses a certificate to
authenticate the authentication server.)
• A form of single sign-on
– Only have to type your password to the AS
• Based on “Needham-Schroeder key distribution”
Simple shared-secret based
cryptographic authentication
shuque@isc.upenn.edu
Add mutual authentication
shuque@isc.upenn.edu
Problems with this scheme
• Generalizing the model for m users and n services,
requires a priori distribution of m x n shared keys
• Possible improvement:
– Use trusted 3rd party, with which each user and
service shares a secret key: m + n keys
– Also has important security advantages
shuque@isc.upenn.edu
Mediated Authentication
• A trusted third party mediates authentication
• Called the Key Distribution Center (KDC)
– aka Authentication Server
• Each user and service shares a secret key with the KDC
• KDC generates a session key, and securely distributes it
to communicating parties
• Communicating parties prove to each other that they
know the session key
shuque@isc.upenn.edu
shuque@isc.upenn.edu
Mediated Authentication
shuque@isc.upenn.edu
Mediated Authentication
shuque@isc.upenn.edu
Kerberos (almost)
shuque@isc.upenn.edu
Kerberos (roughly)
shuque@isc.upenn.edu
Kerberos (detailed)
• Each user and service registers a secret key with the KDC
• Everyone trusts the KDC
– “Put all your eggs in one basket, and then watch that basket
very carefully” - Anonymous Mark Twain
• The user’s key is derived from a password, by applying a hash
function
• The service key is a large random number, and stored on the
server
shuque@isc.upenn.edu
Needham-Schroeder Protocol
[Provided for completeness]
shuque@isc.upenn.edu
Mediated Authentication
• Nomenclature:
– Ka = Master key for “alice”, shared by alice and the KDC
– Kab = Session key shared by “alice” and “bob”
– Tb = Ticket to use “bob”
– K{data} = “data” encrypted with key “K”
shuque@isc.upenn.edu
How Federated Identity
Works
1. A user tries to access a protected
application
2.The user tells the application
where it’s from
3.The user logs in at home
4.Home tells the application about
the user
5.The user is rejected or accepted
66
Rick Summerhill: I2 CTO
1. I’d like access
2. What is your
4. I’d like to
login for SP.
Identity
Provider
5. Login
6. Here is data
about you for
SP. Send it.
Directory
home?
Use
r
3. Please login
at home.
Service
Provider
7. Here is
my data.
8a. See the page!
8b. Access Denied
Database
Rick Summerhill: I2 CTO
Don’t Forget
1. All of this relies on various fragile assumptions about
people and communities.
– Security technology only works if people use it.
– Find the weakest link in the end-to-end chain.
– Compromised key? All bets are off.
– Beware false sense of security! (E.g., WEP)
2. Design for easy, incremental, organic deployment.
– What layer? IPSEC or VPN vs. TLS
3. Understand full range of potential attacks.
– Man-in-middle, replays and nonces,
challenge/response
– Useful model to guide analysis: logic of “belief”
(BAN)
Figure 7.20
SSL record protocol
abcdefghi
Application data
Fragment/combine
Record protocol units
Compress
Compressed units
Hash
MAC
Encrypt
Encrypted
Transmit
TCP packet
[Provided for completeness]
abc
def
ghi
PKI: The Concept
Verisign
duke
washington
unc
cs
mc
chase
cs
env
cs
Etc.
Verisign (or Thawte, etc.) issues certificate signing keys to organizations.
Trusted Platform Module: TPM
•
•
•
•
New hardware support for secure environments
PCR registers and SHA1 extension
Key function: attested measurement
Measurement = hash contents of a byte array
(VALUE) with a SHA-1 hash and place in PCR.
• Extend operation: chained hashing
• PCR = SHA-1(PCR concat VALUE)
• So PCR can certify/attest a sequence of values
presented as arguments to a sequence of extends.
TPM Keys
• Chip has private key burned in at manufacture
– Chip’s public key is endorsed by the manufacturer
– Uses: sealed measurements, remote attestation
• Chip has shared secret with its current owner
– Uses: authenticated commands from owner
• Volatile storage of loaded keypairs
• Chip has storage root key keypair, minted when owner
takes control of the platform
– Uses: encrypt external storage of keys associated
with current owner and the owner’s software.
Secure Booting with TPM
•
•
•
•
•
•
BIOS is Core Root of Trust for Measurement (CRTM)
That’s a hack
BIOS to Boot Loader to OS to Applications
At the end, app can ask: can I trust this context?
Also notion of sealed data
Is it dangerous for an app to know what software you
are running?
• What if the app refuses to work unless you are using
a specific vendor’s product?
TPM in Linux
• Driver
• Command request/response through /dev/tpm
– Reset
– Read PCR
– Read chip’s public key (endorsement key)
– Generate keypair
– Seal/encrypt
– Take ownership