authentication and secure communication jeff chase duke university

60
Authentication and Secure Communication Jeff Chase Duke University

Upload: todd-mcdonald

Post on 03-Jan-2016

221 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Authentication and Secure Communication Jeff Chase Duke University

Authentication and Secure Communication

Jeff ChaseDuke University

Page 2: 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?

Page 3: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 4: Authentication and Secure Communication Jeff Chase Duke University

Exhibit A

EMLX

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.

[reproduced from clearstation.com]

Page 5: Authentication and Secure Communication Jeff Chase Duke University

“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:

Page 6: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 7: Authentication and Secure Communication Jeff Chase Duke University

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

Page 8: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 9: Authentication and Secure Communication Jeff Chase Duke University

Security

Cryptographyalgorithms

Publickey

(e.g., RSA)

Secretkey

(e.g., DES)

Messagedigest

(e.g., MD5)

Securityservices

AuthenticationPrivacy Messageintegrity

Page 10: Authentication and Secure Communication Jeff Chase Duke University

Familiar names for the protagonists in security

protocolsAlice 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

Page 11: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 12: Authentication and Secure Communication Jeff Chase Duke University

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”.

Page 13: Authentication and Secure Communication Jeff Chase Duke University

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?

Page 14: Authentication and Secure Communication Jeff Chase Duke University

Simple shared-secret based cryptographic authentication

[email protected]

Page 15: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 16: Authentication and Secure Communication Jeff Chase Duke University

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)

Page 17: Authentication and Secure Communication Jeff Chase Duke University

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

Page 18: Authentication and Secure Communication Jeff Chase Duke University

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?

Page 19: Authentication and Secure Communication Jeff Chase Duke University

Figure 7.3Cryptography 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 Message M encrypted with key K

[M]K Message M signed with key K

Page 20: Authentication and Secure Communication Jeff Chase Duke University

Performance of encryption and secure digest

algorithmsKey size/hash size

(bits)Extrapolated

speed(kbytes/sec.)

PRB optimized(kbytes/s)

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

Note: these numbers are OLD! Only the relative speeds are useful.

Page 21: Authentication and Secure Communication Jeff Chase Duke University

Secure Communication with an Untrusted Infrastructure

ISP AISP A

ISP DISP D

ISP CISP C

ISP BISP B

Alice

Bob

Mallory

Page 22: Authentication and Secure Communication Jeff Chase Duke University

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.”

Client Server

“Let’s establish a session key: {S}K .”

{M}S

Page 23: Authentication and Secure Communication Jeff Chase Duke University

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…

Page 24: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 25: Authentication and Secure Communication Jeff Chase Duke University

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

Page 26: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 27: Authentication and Secure Communication Jeff Chase Duke University

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…

MACs not discussed in class: provided for completeness

Page 28: Authentication and Secure Communication Jeff Chase Duke University

Digital signatures with public keys

{h}Kpri

M

Signing

Verifying

E(Kpri , h)

128 bits

H(M) h

M

hH(doc)

D(Kpub ,{h}) {h}Kpri h'

h = h'?

M

signed doc

Page 29: Authentication and Secure Communication Jeff Chase Duke University

Low-cost signatures with a shared secret key

M

Signing

Verifying

H(M+K) h

h'H(M+K)

h

h = h'?

K

M

signed doc

M

K

Message authentication

code (MAC)

• Pro: fast• Con: repudiable• Con: shared secret

MACs not discussed in class: provided for completeness

Page 30: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 31: Authentication and Secure Communication Jeff Chase Duke University

Figure 7.13X509 Certificate format

Subject Distinguished Name, Public Key

Issuer Distinguished Name, Signature

Period of validity Not Before Date, Not After Date

Administrative information Versi on, Serial Number

Extended Information

Provided for completeness

Page 32: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 33: Authentication and Secure Communication Jeff Chase Duke University

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.

– Involves transitive trust.

Provided for completeness

Page 34: Authentication and Secure Communication Jeff Chase Duke University

Certificate Hierarchyor 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]Provided for completeness

Page 35: Authentication and Secure Communication Jeff Chase Duke University

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…

Page 36: Authentication and Secure Communication Jeff Chase Duke University

What happens…

• 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?

https://www.shop.com/shop.html

Page 37: Authentication and Secure Communication Jeff Chase Duke University

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.

Page 38: Authentication and Secure Communication Jeff Chase Duke University

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 SSL key exchange vulnerable to man-in-the-middle attacks?

Page 39: Authentication and Secure Communication Jeff Chase Duke University

"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

Page 40: Authentication and Secure Communication Jeff Chase Duke University

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)

Provided for completeness

Page 41: Authentication and Secure Communication Jeff Chase Duke University

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

Provided for completeness

Page 42: Authentication and Secure Communication Jeff Chase Duke University

What happens…

https://www.library.duke.edu

Page 43: Authentication and Secure Communication Jeff Chase Duke University

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”

Page 44: Authentication and Secure Communication Jeff Chase Duke University

Simple shared-secret based cryptographic authentication

[email protected]

Page 45: Authentication and Secure Communication Jeff Chase Duke University

Add mutual authentication

[email protected]

Page 46: Authentication and Secure Communication Jeff Chase Duke University

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

[email protected]

Page 47: Authentication and Secure Communication Jeff Chase Duke University

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

[email protected]

Page 49: Authentication and Secure Communication Jeff Chase Duke University

Mediated Authentication

[email protected]

Page 50: Authentication and Secure Communication Jeff Chase Duke University

Mediated Authentication

[email protected]

Page 51: Authentication and Secure Communication Jeff Chase Duke University

Kerberos (almost)

[email protected] for completeness

Page 52: Authentication and Secure Communication Jeff Chase Duke University

Kerberos (roughly)

[email protected] for completeness

Page 53: Authentication and Secure Communication Jeff Chase Duke University

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

[email protected]

Page 54: Authentication and Secure Communication Jeff Chase Duke University

Needham-Schroeder Protocol

[email protected][Provided for completeness]

Page 55: Authentication and Secure Communication Jeff Chase Duke University

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”

[email protected] for completeness

Page 56: Authentication and Secure Communication Jeff Chase Duke University

56

How Federated Identity Works (e.g., Shibboleth)

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 home4.Home tells the application about

the user5.The user is rejected or accepted

Rick Summerhill: I2 CTOProvided for completeness

Page 57: Authentication and Secure Communication Jeff Chase Duke University

IdentityIdentityProviderProvider

ServiceServiceProviderProvider

DatabasDatabasee

DirectorDirectoryy

1. I’d like access

2. What is your

home?

3. Please login at home.

4. I’d like to login for SP.

UseUserr

5. Login

6. Here is data

about you forSP. Send it.

7. Here is my data.

8a. See the page!

8b. Access Denied

Rick Summerhill: I2 CTO

Shibboleth

Provided for completeness

Page 58: Authentication and Secure Communication Jeff Chase Duke University

Trust Management and Authorization Policy

– X.509 certificate is one form of key endorsement.• Signer certifies bearer’s key

– The signer of an endorsement could include all sorts of other useful information.• Security assertions

– Authorization based on general security assertions• Identity attributes (e.g., in Shibboleth)• Delegation of rights (credentials)• Delegation of resource control

– ORCA leases

Provided for completeness

Page 59: Authentication and Secure Communication Jeff Chase Duke University

Don’t Forget1. 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)

Page 60: Authentication and Secure Communication Jeff Chase Duke University

Trusted Platform Module: TPM

• New hardware support for secure environments• Will be everywhere soon

– Intel TXT technology built into Nehalem• Key function: attested measurement• Measurement = hash contents of a byte array

(VALUE) with a SHA-1 hash.• Can certify/attest a sequence of values presented

as arguments to a sequence of extends.

Provided for completeness