3
Basic Requirements for Secure Communication Availability: Will the network deliver data? –Infrastructure compromise, DDoS Authentication: Who is this actor? –Spoofing, phishing Integrity: Do messages arrive in original form? Confidentiality: Can adversary read the data? –Sniffing, man-in-the-middle Provenance: Who is responsible for this data? –Forging responses, denying responsibility –Not who sent the data, but who created it

4
Other Desirable Security Properties Authorization: is actor allowed to do this action? –Access controls Accountability/Attribution: who did this activity? Audit/Forensics: what occurred in the past? –A broader notion of accountability/attribution Appropriate use: is action consistent with policy? –E.g., no spam; no games during business hours; etc. Freedom from traffic analysis: can someone tell when I am sending and to whom? Anonymity: can someone tell I sent this packet?

8
Integrity Attack - Tampering Stop the flow of the message Delay and optionally modify the message Release the message again A B Perpetrator

9
Authenticity Attack - Fabrication Unauthorized assumption of other’s identity Generate and distribute objects under this identity A B Masquerader: from A

10
Attack on Availability Destroy hardware (cutting fiber) or software Modify software in a subtle way Corrupt packets in transit Blatant denial of service (DoS): –Crashing the server –Overwhelm the server (use up its resource) A B

11
Basic Forms of Cryptography

12
Confidentiality through Cryptography Cryptography: communication over insecure channel in the presence of adversaries Studied for thousands of years Central goal: how to encode information so that an adversary can’t extract it …but a friend can General premise: a key is required for decoding –Give it to friends, keep it away from attackers Two different categories of encryption –Symmetric: efficient, requires key distribution –Asymmetric (Public Key): computationally expensive, but no key distribution problem

13
Symmetric Key Encryption Same key for encryption and decryption –Both sender and receiver know key –But adversary does not know key For communication, problem is key distribution –How do the parties (secretly) agree on the key? What can you do with a huge key? One-time pad –Huge key of random bits To encrypt/decrypt: just XOR with the key! –Provably secure! …. provided: You never reuse the key … and it really is random/unpredictable –Spies actually use these

14
Using Symmetric Keys Both the sender and the receiver use the same secret keys Internet Encrypt with secret key Decrypt with secret key Plaintext Ciphertext

15
Asymmetric Encryption (Public Key) Idea: use two different keys, one to encrypt (e) and one to decrypt (d) –A key pair Crucial property: knowing e does not give away d Therefore e can be public: everyone knows it! If Alice wants to send to Bob, she fetches Bob’s public key (say from Bob’s home page) and encrypts with it –Alice can’t decrypt what she’s sending to Bob … –… but then, neither can anyone else (except Bob)

26
Public Key Authentication Each side need only to know the other side’s public key –No secret key need be shared A encrypts a nonce (random number) x using B’s public key B proves it can recover x A can authenticate itself to B in the same way E(x, Public B ) x A B

28
Digital Signatures Suppose Alice has published public key K E If she wishes to prove who she is, she can send a message x encrypted with her private key K D –Therefore: anyone w/ public key K E can recover x, verify that Alice must have sent the message –It provides a digital signature –Alice can’t deny later deny it  non- repudiation

29
RSA Crypto & Signatures, con’t

30
Summary of Our Crypto Toolkit If we can securely distribute a key, then –Symmetric ciphers (e.g., AES) offer fast, presumably strong confidentiality Public key cryptography does away with problem of secure key distribution –But not as computationally efficient –Often addressed by using public key crypto to exchange a session key –And not guaranteed secure but major result if not

31
Summary of Our Crypto Toolkit, con’t Cryptographically strong hash functions provide major building block for integrity (e.g., SHA-1) –As well as providing concise digests –And providing a way to prove you know something (e.g., passwords) without revealing it (non-invertibility) –But: worrisome recent results regarding their strength Public key also gives us signatures –Including sender non-repudiation Turns out there’s a crypto trick based on similar algorithms that allows two parties who don’t know each other’s public key to securely negotiate a secret key even in the presence of eavesdroppers

39
But should we believe it? Enter DNSSEC DNSSEC protects against data spoofing and corruption DNSSEC also provides mechanisms to authenticate servers and requests DNSSEC provides mechanisms to establish authenticity and integrity

40
PK-DNSSEC (Public Key) The DNS servers sign the hash of resource record set with its private (signature) keys Public keys can be used to verify the SIGs Leverages hierarchy: –Authenticity of nameserver’s public keys is established by a signature over the keys by the parent’s private key –In ideal case, only roots’ public keys need to be distributed out-of-band

43
Public Key Infrastructure (PKI) Public key crypto is very powerful … … but the realities of tying public keys to real world identities turn out to be quite hard PKI: Trust distribution mechanism –Authentication via Digital Certificates Trust doesn’t mean someone is honest, just that they are who they say they are…

44
Managing Trust The most solid level of trust is rooted in our direct personal experience –E.g., Alice’s trust that Bob is who they say they are –Clearly doesn’t scale to a global network! In its absence, we rely on delegation –Alice trusts Bob’s identity because Charlie attests to it …. –…. and Alice trusts Charlie

46
PKI Conceptual Framework Trusted-Root PKI: –Basis: well-known public key serves as root of a hierarchy –Managed by a Certificate Authority (CA) To publish a public key, ask the CA to digitally sign a statement indicating that they agree (“certify”) that it is indeed your key –This is a certificate for your key (certificate = bunch of bits) Includes both your public key and the signed statement –Anyone can verify the signature Delegation of trust to the CA –They’d better not screw up (duped into signing bogus key) –They’d better have procedures for dealing with stolen keys –Note: can build up a hierarchy of signing

47
Components of a PKI

48
Digital Certificate Signed data structure that binds an entity with its corresponding public key –Signed by a recognized and trusted authority, i.e., Certification Authority (CA) –Provide assurance that a particular public key belongs to a specific entity Example: certificate of entity Y Cert = E({name Y, KY public }, KCA private ) –KCA private : private key of Certificate Authority –name Y : name of entity Y –KY public : public key of entity Y In fact, they may sign whatever glob of bits you give them Your browser has a bunch of CAs wired into it

50
Registration Authority People & processes responsible for: –Authenticating the identity of new entities (users or computing devices), e.g., By phone, or physical presence + ID –Issuing requests to CA for certificates The CA must trust the Registration Authority –This trust can be misplaced

51
Certificate Repository A database accessible to all users of a PKI Contains: –Digital certificates –Policy information associated with certs –Certificate revocation information Vital to be able to identify certs that have been compromised Usually done via a revocation list

53
HTTPS Connection (SSL/TLS), con’t Browser (client) connects via TCP to Amazon’s HTTPS server Client sends over list of crypto protocols it supports Server picks protocols to use for this session Server sends over its certificate (all of this is in the clear) SYN SYN ACK ACK BrowserAmazon Hello. I support (TLS+RSA+AES128+SHA1) or (SSL+RSA+3DES+MD5) or … Let’s use TLS+RSA+AES128+SHA1 Here’s my cert ~1 KB of data

54
54 Inside the Server’s Certificate Name associated with cert (e.g., Amazon) Amazon’s public key A bunch of auxiliary info (physical address, type of cert, expiration time) URL to revocation center to check for revoked keys Name of certificate’s signatory (who signed it) A public-key signature of a hash (MD5) of all this –Constructed using the signatory’s private RSA key

55
Validating Amazon’s Identity Browser retrieves cert belonging to the signatory –These are hardwired into the browser If it can’t find the cert, then warns the user that site has not been verified –And may ask whether to continue –Note, can still proceed, just without authentication Browser uses public key in signatory’s cert to decrypt signature –Compares with its own MD5 hash of Amazon’s cert Assuming signature matches, now have high confidence it’s indeed Amazon … –… assuming signatory is trustworthy