Authentication and technology Secure Communication people Jeff Chase Duke University 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 Exhibit A • “Security is at least as much a social problem as it is a This is a picture of a $2.5B move in the value of Emulex Corporation, in technical problem.” response to a fraudulent press release by short-sellers through InternetWire in 2000. The release was widely disseminated by news media as a statement – Translation: humans are the weak link. from Emulex management, but media failed to authenticate it. • We will focus on the technical elements, but do not lose sight of the social dimension. EMLX – Keys left in lock – Phishing – Executable attachments – Trojan software – Post-it passwords – Bribes, torture, etc. – Etc. [reproduced from clearstation.com ] Trusted vs. Trustworthy (NSA) “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 • Trusted they pollute the environment.) It is astonishing that these – A component that can break the security policy if devices continue to be manufactured and deployed. But they it fails. (“It has power.”) are sufficiently pervasive that we must design our protocols around their limitations.” – Integrity cannot be verified by external observation. (“You can’t tell if it breaks”.) - Kaufman, Perlman, and Speciner • Trustworthy As quoted in: – 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. 1
Questions and Answers #1 Questions and Answers #2 • Who is the sender? • Authentication? – Challenge/response: passwords, certificates – Authentication – A subject bound to a strong identity is a principal. • Is the sender allowed to do this? • Authorization? – Authorization – Access control lists or capabilities (ticket/token) • Is this really what the sender said? • Integrity? – Integrity – Message digests and digital signatures • Could anyone else have intercepted it? • Privacy – Privacy – Encryption (provides integrity too) All of these require some form of a shared secret or shared trust in a third party, or both. Familiar names for the protagonists in security Security protocols Cryptography Security algorithms services Secret Public Message Privacy Authentication Message Alice First participant key key digest integrity Bob Second participant (e.g., DES) (e.g., RSA) (e.g., MD5) 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 Using Crypto: the Basics • Encrypt and Decrypt functions • Privacy – M = Decrypt(Encrypt(M) – Attacker cannot read encrypted data. – Standard and efficient enough to be practical. • Integrity • Crypto functions are parameterized by keys. – Encrypt a hash/checksum/digest of the message. – Fixed-width “random” value. • Authentication – Everybody has their own key(s) or key pair(s). – Challenge-response with a nonce – “Computationally infeasible” to decrypt without the key. • “number used once” – Key length really matters. – Receiver encrypts the nonce and sends it back. • Two fundamental variants: • Proves it possesses the matching key. – Public-key or asymmetric crypto (e.g., RSA) – Nonces can be timestamps, serial numbers, etc. to – Secret-key, private-key, symmetric crypto (e.g., DES) prevent replay attacks. • Foundation of many/all security mechanisms. 2
Symmetric Crypto Asymmetric Crypto • “Secret key” or “private key” cryptography. • Sometimes called “public key” cryptography. • Each subject/principal possesses a keypair: K -1 and K – DES, 3DES, DESX, IDEA, AES • Sender and receiver must possess a shared secret – Decrypt(K, Encrypt(K -1 , M)) = M – Shared key K • Given Encrypt(K -1 , M), cannot compute M without K. • Message M, Key K • Given M and Encrypt(K -1 , M), cannot compute K or K -1 {M} K = Encrypt(M, K) • Given x, cannot compute y such that Decrypt(K, y) = x, unless you know K -1 . M = Decrypt({M} K , K) • Each principal keeps one key private. • The inverse key may be public. • Either key can be used to encrypt/decrypt. Figure 7.3 Pros and Cons Cryptography notations Symmetric crypto (DES, AES, …) – Pro: cheap and easily supported by hardware – Con: need a shared secret. K A Alice’s secret key • Shared secrets are harder to keep secret. K B Bob’s secret key • key distribution problem K AB Secret key shared between Alice and Bob Asymmetric crypto (Diffie-Hellman, RSA) K Apriv Alice’s private key (known only to Alice) – Con: expensive K Apub Alice’s public key (published by Alice for all to read) – Pro: no need for a shared secret { M } Message M encrypted with key K K • The recipient just needs to know sender’s public key. [ M ] K Message M signed with key K • Multicast or broadcast? Message storage? No problem. • Solves the private-key distribution problem – Con: introduces a new public-key distribution problem Performance of encryption Better Together, Part 1 and secure digest algorithms • Use asymmetric crypto just to “handshake” and establish a Key size/hash size Extrapolated PRB optimized secret session key. (bits) speed (kbytes/s) • Converse with the efficiency of symmetric crypto. (kbytes/sec.) • Example: Secure Sockets Layer (SSL) or Transport-Layer TEA 128 700 - Security (TLS), used in HTTPS. DES 56 350 7746 • End-to-end security above TCP. Triple-DES 112 120 2842 IDEA 128 700 4469 “SYN, etc.” RSA 512 7 - “My public key is K.” RSA 2048 1 - “Let’s establish a session key: {S} K .” MD5 128 1740 62425 Server Client SHA 160 750 25162 {M} S … 3
SSL is not so simple… Secure Hash / Message Digest • How do we know who we are talking to? • Well-known, standard, hash functions digest = h(M). – MD5, SHA1 – Do we care? Somebody does… – Very efficient to compute. • How do we prevent replays of encrypted content? – Digest is a small, fixed-width quantity: i.e., it is a hash. • SSL/TLS uses this basic handshake protocol, but • Often called a fingerprint or cryptographic checksum. there are many other aspects: – Collision-resistant – Nonces, serial numbers, timestamps • There exist distinct M 1 and M 2 such that h(M 1 ) == h(M 2 ). – Hashes and MACs • Such collisions are “hard” to find. – One way – Certificates • Given digest, cannot generate an M with h(M) == digest. – More on this later… – Secure • The digest does not help to discover any part of M. Messages with both Digital Signatures Authenticity and Secrecy • How can the sender/writer A of M allow any receiver • How does A send a message x to B with: to verify or prove that A sent/stored M? – Authenticity (B knows that only A could have sent it) – authenticity – Secrecy (A knows that only B can read the message) • Digital signature using asymmetric crypto, e.g., RSA. 1. A Transmits the following message x – A computes digest h(M) – {{ x }K A -1 }K B – A computes signature {h(M)} K and appends to M. 2. What if x is large (performance concerns)? • Encrypted with A’s private key K. – A transmits K A to B, B transmits K B to A – Receiver decrypts digest using A’s public key K -1 – A picks J A , transmits {J A }K B to B – Receiver computes h(M) and compares to digest. – B picks J B , transmits {J B }K A to A • Digital signatures are “unforgeable” and “non-repudiable”. – Each computes secret key, K sk = Hash(J A , J B ) – Unlike physical signatures, they are bound to a particular message or document. – A transmits {x}K sk to B – Legally binding in the US. [Vahdat] Digital signatures with public Low-cost signatures with a keys shared secret key M signed doc M signed doc H(M) {h} Kpri h E(K pri , h) H(M+K) Signing h Signing Message M 128 bits authentication M K code (MAC) • Pro: fast • Con: repudiable {h} Kpri h' D(K pub ,{h}) • Con: shared secret M h Verifying M h = h'? Verifying h H(doc) h = h'? h' H(M+K) K 4
Recommend
More recommend
