Authentication and Secure Communication the First Axiom Of
Total Page：16
File Type：pdf, Size：1020Kb
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 response to a fraudulent press release by short-sellers through InternetWire in technical problem.” 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] “Humans are incapable of securely storing high-quality cryptographic keys, and they have unacceptable speed and Trusted vs. Trustworthy (NSA) 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 •Trusted devices continue to be manufactured and deployed. But they – A component that can break the security policy if are sufficiently pervasive that we must design our protocols it fails. (“It has power.”) around their limitations.” – Integrity cannot be verified by external - Kaufman, Perlman, and Speciner observation. (“You can’t tell if it breaks”.) • 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? – Authentication – Challenge/response: passwords, certificates • Is the sender allowed to do this? – A subject bound to a strong identity is a principal. –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 Security protagonists in security Cryptography Security algorithms services protocols Secret Public Message PrivacyAuthentication Message Alice First participant key key digest integrity (e.g., DES) (e.g., RSA) (e.g., MD5) 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 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. – DES, 3DES, DESX, IDEA, AES • Each subject/principal possesses a keypair: K-1 and K • 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. KA Alice’s secret key • Shared secrets are harder to keep secret. KB Bob’s secret key • key distribution problem KAB Secret key shared between Alice and Bob Asymmetric crypto (Diffie-Hellman, RSA) KApriv Alice’s private key (known only to Alice) –Con: expensive KApub Alice’s public key (published by Alice for all to read) –Pro: no need for a shared secret {M}K MessageM encrypted with keyK • The recipient just needs to know sender’s public key. [M]K MessageM signed with keyK • 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 ExtrapolatedPRB optimized (bits) speed (kbytes/s) secret session key. (kbytes/sec.) • Converse with the efficiency of symmetric crypto. TEA 128 700 - •Example: Secure Sockets Layer (SSL) or Transport-Layer 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 - MD5 128 1740 62425 “Let’s establish a session key: {S}K .” SHA 160 750 25162 Client {M}S Server … 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). – Do we care? Somebody does… –MD5, SHA1 – 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 M1 and M2 such that h(M1) == h(M2). – Hashes and MACs • Such collisions are “hard” to find. – Certificates –One way •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 -1 – A computes digest h(M) –{{x}KA }KB – 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 KA to B, B transmits KB to A – Receiver decrypts digest using A’s public key K-1 –A picks JA, transmits {JA}KB to B – Receiver computes h(M) and compares to digest. –B picks JB, transmits {JB}KA to A • Digital signatures are “unforgeable” and “non-repudiable”. – Each computes secret key, Ksk = Hash(JA, JB) – Unlike physical signatures, they are bound to a particular message or document. – A transmits {x}Ksk 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} h E(Kpri, h) Kpri H(M+K) Signing Signing h 128 bits M Message M authentication K code (MAC) • Pro: fast •Con: repudiable {h}Kpri h' D(Kpub,{h}) M •Con: shared secret h Verifying M h = h'? Verifying H(doc) h h = h'? h' K H(M+K) 4 Public Key Distribution Certifying Public Keys • The “key” challenge today is public key distribution (and • Digital signatures enable any entity to endorse the revocation). (public key, identity) binding of another entity. • Approach #1: trust e-mail/web (i.e., assume DNS and IP really •Acertificate is a special type of digitally signed go where you want, and authenticate the source.) document: – Example: PGP, GPG, “pretty good”…or do it in person. – “I certify that the public key in this document • Approach #2 : use a Public Key Infrastructure (PKI) belongs to the entity named in this document, signed X.” – Requires everyone to agree on a central point of trust (Certifying Authority or CA). • Recipient must trust the issuer X, and must know the public key of X. – Difficult to understand and deploy. • E.g., X may be a widely trusted certifying authority – Hierarchy helps. (CA) whose public key is widely available. • Approach #3: “web of trust” in which parties establish pairwise – The public key of Verisign is wired into every trust and endorse public keys of third parties. browser. – Local example: SHARP. Involves transitive trust. Figure 7.13 Certificate Hierarchy X509 Certificate format or Web of Trust •Chain of Trust –If X certifies that a certain public key belongs to Subject Distinguished Name, PublicKey Y, and Y certifies that another public key belongs Issuer Distinguished Name, Signature to Z, then there exists a chain of certificates from X to Z Period of validity Not Before Date, Not After Date Administrativeinformation Version, Serial Number – Someone that wants to verify Z’s public key has to know X’s public key and follow the chain Extended Information – X forms the root of a tree (web?) • Certificate Revocation List – What happens when a private key is compromised? [Vahdat] PKI What happens… • Public Key Infrastructure • Everyone trusts some root CAs.