Presentation is loading. Please wait.

Presentation is loading. Please wait.

Security 2 Outline Various Attacks to Computer Security Cryptography Authentication & Key Distribution Access Control Logic of Authentication.

Similar presentations


Presentation on theme: "Security 2 Outline Various Attacks to Computer Security Cryptography Authentication & Key Distribution Access Control Logic of Authentication."— Presentation transcript:

1

2 Security

3 2 Outline Various Attacks to Computer Security Cryptography Authentication & Key Distribution Access Control Logic of Authentication

4 3 Security Needs in Distributed Systems  Basic security needs –protect against malicious attempts of one user to user resources belonging to another user  authentication: identity verification  access control: authorization on use of a given resource

5 4 Secure channels  Properties  Each process is sure of the identity of the other  Data is private and protected against tampering  Protection against repetition and reordering of data  Employs cryptography  Secrecy based on cryptographic concealment  Authentication based on proof of ownership of secrets Cryptographic concealment is based on: Confusion and diffusion Ownership of secrets: Conventional shared crypto keys Public/private key pair * Principal A Secure channel Process p q Principal B The enemy Cryptography

6 5 Worst case assumptions and design guidelines  Interfaces are exposed  Networks are insecure  Limit the lifetime and scope of each secret  Algorithms and program code are available to attackers  Attackers may have access to large resources  Minimize the trusted base

7 6 Threats and forms of attack  Eavesdropping –obtaining private or secret information  Masquerading –assuming the identity of another user/principal  Message tampering –altering the content of messages in transit  man in the middle attack (tampers with the secure channel mechanism)  Replaying –storing secure messages and sending them at a later date  Denial of service –flooding a channel or other resource, denying access to others

8 7 Threats not defeated by secure channels or other cryptographic techniques  Denial of service attacks –Deliberately excessive use of resources to the extent that they are not available to legitimate users  E.g. the Internet 'IP spoofing' attack, February 2000  Trojan horses and other viruses –Viruses can only enter computers when program code is imported. –But users often require new programs, for example:  New software installation  Mobile code downloaded dynamically by existing software (e.g. Java applets)  Accidental execution of programs transmitted surreptitiously –Defences: code authentication (signed code), code validation (type checking, proof), sandboxing.

9 8 The February 2000 IP Spoofing DDoS attack Echo request | source = x.x.x.x | destination = n.n.n.i Echo reply | source = n.n.n.i | destination = x.x.x.x Untrue! Compromised host on each local network sends repeatedly (for all i): resulting in: *

10 9 Security notations KAKA Alice’s secret key KBKB Bob’s secret key K AB Secret key shared between Alice and Bob K Apriv Alice’s private key (known only to Alice) K Apub Alice’s public key (published by Alice for all to read) {M} K MessageM encrypted with keyK [M ]K]K MessageM signed with key K AliceFirst participant BobSecond participant CarolParticipant in three- and four-party protocols DaveParticipant in four-party protocols EveEavesdropper MalloryMalicious attacker SaraA server

11 10 Alice and Bob share a secret key K AB. 1.Alice uses K AB and an agreed encryption function E(K AB, M) to encrypt and send any number of messages {M i } K AB to Bob. 2.Bob reads the encrypted messages using the corresponding decryption function D(K AB, M). Alice and Bob can go on using K AB as long as it is safe to assume that K AB has not been compromised. Scenario 1: Secret communication with a shared secret key Issues: Key distribution: How can Alice send a shared key K AB to Bob securely? Freshness of communication: How does Bob know that any {M i } isn’t a copy of an earlier encrypted message from Alice that was captured by Mallory and replayed later? *

12 11 Bob is a file server; Sara is an authentication service. Sara shares secret key K A with Alice and secret key K B with Bob. 1.Alice sends an (unencrypted) message to Sara stating her identity and requesting a ticket for access to Bob.  2.Sara sends a response to Alice. {{Ticket} K B, K AB } K A. It is encrypted in K A and consists of a ticket (to be sent to Bob with each request for file access) encrypted in K B and a new secret key K AB. 3.Alice uses K A to decrypt the response. 4.Alice sends Bob a request R to access a file: {Ticket} K B, Alice, R. 5.The ticket is actually {K AB, Alice} K B. Bob uses K B to decrypt it, checks that Alice's name matches and then uses K AB to encrypt responses to Alice. Scenario 2: Authenticated communication with a server  This is a simplified version of the Needham and Schroeder (and Kerberos) protocol.  Timing and replay issues – addressed in N-S and Kerberos.  Not suitable for e-commerce because authentication service doesn't scale… A ticket is an encrypted item containing the identity of the principal to whom it is issued and a shared key for a communication session. *

13 12 Bob has a public/private key pair 1.Alice obtains a certificate that was signed by a trusted authority stating Bob's public key K Bpub 2.Alice creates a new shared key K AB, encrypts it using K Bpub using a public-key algorithm and sends the result to Bob. 3.Bob uses the corresponding private key K Bpriv to decrypt it. (If they want to be sure that the message hasn't been tampered with, Alice can add an agreed value to it and Bob can check it.) Scenario 3: Authenticated communication with public keys  Mallory might intercept Alice’s initial request to a key distribution service for Bob’s public-key certificate and send a response containing his own public key. He can then intercept all the subsequent messages. *

14 13 Alice wants to publish a document M in such a way that anyone can verify that it is from her. 1.Alice computes a fixed-length digest of the document Digest(M). 2.Alice encrypts the digest in her private key, appends it to M and makes the resulting signed document (M, {Digest(M)} K Apriv ) available to the intended users. 3.Bob obtains the signed document, extracts M and computes Digest(M). 4.Bob uses Alice's public key to decrypt {Digest(M)} K Apriv and compares it with his computed digest. If they match, Alice's signature is verified. Scenario 4: Digital signatures with a secure digest function The digest function must be secure against the birthday attack *

15 14 1.Alice prepares two versions M and M' of a contract for Bob. M is favourable to Bob and M' is not. 2.Alice makes several subtly different versions of both M and M' that are visually indistinguishable from each other by methods such as adding spaces at the ends of lines. She compares the hashes of all the versions of M with all the versions of M'. (She is likely to find a match because of the Birthday Paradox). 3.When she has a pair of documents M and M' that hash to the same value, she gives the favourable document M to Bob for him to sign with a digital signature using his private key. When he returns it, she substitutes the matching unfavourable version M', retaining the signature from M. Birthday attack –If our hash values are 64 bits long, we require only 2 32 versions of M and M’ on average. –This is too small for comfort. We need to make our hash values at least 128 bits long to guard against this attack. Birthday paradox Probability of finding a matching pair in a given set is far greater than for finding a match for a given individual. Statistical result: if there are 23 people in a room, the chances are even that 2 of them will have the same birthday. Conversely we require a set of 253 people for an even chance that there will be one with a birthday on a given day. *

16 15 Certificates 1.Certificate type:Account number 2.Name:Alice 3.Account:6262626 4.Certifying authority:Bob’s Bank 5.Signature:{Digest(field 2 + field 3)} K Bpriv Alice’s bank account certificate Public-key certificate for Bob's Bank 1.Certificate type:Public key 2.Name:Bob’s Bank 3.Public key:K Bpub 4.Certifying authority:Fred – The Bankers Federation 5.Signature: {Digest(field 2 + field 3)} K Fpriv Certificate: a statement signed by an appropriate authority. Certificates require: An agreed standard format Agreement on the construction of chains of trust. Expiry dates, so that certificates can be revoked. *

17 16 X509 Certificate format

18 17 Access control  Protection domain –A set of pairs  Two main approaches to implementation: –Access control list (ACL) associated with each object  E.g. Unix file access permissions   For more complex object types and user communities, ACLs can become very complex –Capabilities associated with principals  Like a key  Format:  Must be unforgeable  Problems: eavesdropping, difficulty of cancellation drwxr-xr-x cs582 staff 264 Oct 30 16:57 Acrobat User Data -rw-r--r-- cs582 unknown 0 Nov 1 09:34 Eudora Folder -rw-r--r-- cs582 staff 163945 Oct 24 00:16 Preview of xx.pdf drwxr-xr-x cs582 staff 264 Oct 31 13:09 iTunes -rw-r--r-- cs582 staff 325 Oct 22 22:59 list of broken apps.rtf *

19 18 Credentials  Requests to access resources must be accompanied by credentials: –Evidence for the requesting principal's right to access the resource –Simplest case: an identity certificate for the principal, signed by the principal. –Credentials can be used in combination. E.g. to send an authenticated email as a member of LUMS, one would need to present a certificate of membership of LUMS and a certificate of their email address.  The “speaks for” idea –We don't want users to have to give their password every time their PC accesses a server holding protected resources. –Instead, the notion that a credential speaks for a principal. *

20 19 Delegation  Consider a server that prints files: –wasteful to copy the files, should access users' files –server must be given restricted and temporary rights to access protected files  Can use a delegation certificate or a capability –a delegation certificate is a signed request authorizing another principal to access a named resource in a restricted manner. –a capability is a key allowing the holder to access one or more of the operations supported by a resource. –The temporal restriction can be achieved by adding expiry times. *

21 20 Digital signatures Requirement: –To authenticate stored document files as well as messages –To protect against forgery –To prevent the signer from repudiating a signed document (denying their responsibility) Encryption of a document in a secret key constitutes a signature -impossible for others to perform without knowledge of the key -strong authentication of document -strong protection against forgery -weak against repudiation (signer could claim key was compromised) *

22 21 Secure digest functions -Encrypted text of document makes an impractically long signature -so we encrypt a secure digest instead -A secure digest function computes a fixed-length hash H(M) that characterizes the document M -H(M) should be: -fast to compute -hard to invert - hard to compute M given H(M) -hard to defeat in any variant of the Birthday Attack -MD5: Developed by Rivest (1992). Computes a 128-bit digest. Speed 1740 kbytes/sec.  SHA: (1995) based on Rivest's MD4 but made more secure by producing a 160-bit digest, speed 750 kbytes/second  Any symmetric encryption algorithm can be used in CBC (cipher block chaining) mode. The last block in the chain is H(M) *

23 22 Digital signatures with public keys Signing h H(doc) D(K pub,{h}) h' h = h'?authentic:forged Verifying M H(M) 128 bits h E(K pri, h) {h} Kpri M signed doc M {h} Kpri *

24 23 MACs: Low-cost signatures with a shared secret key Signing Verifying M K M K h = h'?authentic:forged h M signed doc H(M+K) h h' H(M+K) * Signer and verifier share a secret key K MAC: Message Authentication Code

25 24 Cryptographic Algorithms  Symmetric (secret key) E(K, M) = {M} K D(K, E(K, M)) = M Same key for E and D M must be hard (infeasible) to compute if K is not known. Usual form of attack is brute-force: try all possible key values for a known pair M, {M} K. Resisted by making K sufficiently large ~ 128 bits  Asymmetric (public key) Separate encryption and decryption keys: K e, K d D(K d. E(K e, M)) = M depends on the use of a trap-door function to make the keys. E has high computational cost. Very large keys > 512 bits  Hybrid protocols - used in SSL (now called TLS) Uses asymmetric crypto to transmit the symmetric key that is then used to encrypt a session. * Message M, key K, published encryption functions E, D

26 25 Cipher blocks, chaining and stream ciphers n n+3n+2n+1 XOR E(K, M) n-1n-2 n-3 plaintext blocks ciphertext blocks Cipher block chaining (CBC) XOR E(K, M) number generator n+3n+2n+1 plaintext stream ciphertext stream buffer keystream Stream cipher Most algorithms work on 64-bit blocks. Weakness of simple block cipher:- repeated patterns can be detected. *

27 26 Symmetric encryption algorithms These are all programs that perform confusion and diffusion operations on blocks of binary data TEA: a simple but effective algorithm developed at Cambridge U (1994) for teaching and explanation. 128-bit key, 700 kbytes/sec DES: The US Data Encryption Standard (1977). No longer strong in its original form. 56-bit key, 350 kbytes/sec. Triple-DES: applies DES three times with two different keys. 112-bit key, 120 Kbytes/sec IDEA: International Data Encryption Algorithm (1990). Resembles TEA. 128-bit key, 700 kbytes/sec AES: A proposed US Advanced Encryption Standard (1997). 128/256-bit key. There are many other effective algorithms. See Schneier [1996]. The above speeds are for a Pentium II processor at 330 MHZ. Today's PC's (January 2002) should achieve a 5 x speedup.

28 27 TEA encryption function void encrypt(unsigned long k[], unsigned long text[]) { unsigned long y = text[0], z = text[1]; unsigned long delta = 0x9e3779b9, sum = 0; int n; for (n= 0; n < 32; n++) { sum += delta; y += ((z > 5) + k[1]);5 z += ((y > 5) + k[3]);6 } text[0] = y; text[1] = z; }  Lines 5 & 6 perform confusion (XOR of shifted text) and diffusion (shifting and swapping) * Figure 7.8 key 4 x 32 bits plaintext and result 2 x 32 Exclusive OR logical shift

29 28 TEA decryption function void decrypt(unsigned long k[], unsigned long text[]) { unsigned long y = text[0], z = text[1]; unsigned long delta = 0x9e3779b9, sum = delta << 5; int n; for (n= 0; n < 32; n++) { z -= ((y > 5) + k[3]); y -= ((z > 5) + k[1]); sum -= delta; } text[0] = y; text[1] = z; } Figure 7.9 *

30 29 TEA in use void tea(char mode, FILE *infile, FILE *outfile, unsigned long k[]) { /* mode is ’e’ for encrypt, ’d’ for decrypt, k[] is the key.*/ char ch, Text[8]; int i; while(!feof(infile)) { i = fread(Text, 1, 8, infile);/* read 8 bytes from infile into Text */ if (i <= 0) break; while (i < 8) { Text[i++] = ' ';}/* pad last block with spaces */ switch (mode) { case 'e': encrypt(k, (unsigned long*) Text); break; case 'd': decrypt(k, (unsigned long*) Text); break; } fwrite(Text, 1, 8, outfile);/* write 8 bytes from Text to outfile */ } Figure 7.10 *

31 30 Asymmetric encryption algorithms RSA: The first practical algorithm (Rivest, Shamir and Adelman 1978) and still the most frequently used. Key length is variable, 512-2048 bits. Speed 1-7 kbytes/sec. (350 MHz PII processor) Elliptic curve: A recently-developed method, shorter keys and faster. Asymmetric algorithms are ~1000 x slower and are therefore not practical for bulk encryption, but their other properties make them ideal for key distribution and for authentication uses. A trapdoor provides a secret way into a room. If you're inside, the way out is obvious, if you're outside, you need to know a secret to get in. They all depend on the use of trap-door functions A trap-door function is a one-way function with a secret exit - e.g. product of two large numbers; easy to multiply, very hard (infeasible) to factorize.

32 31 RSA Encryption - 1 To find a key pair e, d: 1. Choose two large prime numbers, P and Q (each greater than 10 100 ), and form: N = P x Q Z = (P–1) x (Q–1) 2. For d choose any number that is relatively prime with Z (that is, such that d has no common factors with Z). We illustrate the computations involved using small integer values for P and Q: P = 13, Q = 17 –> N = 221, Z = 192 d = 5 3.To find e solve the equation: e x d = 1 mod Z That is, e x d is the smallest element divisible by d in the series Z+1, 2Z+1, 3Z+1,.... e x d = 1 mod 192 = 1, 193, 385,... 385 is divisible by d e = 385/5 = 77

33 32 RSA Encryption - 2 To encrypt text using the RSA method, the plaintext is divided into equal blocks of length k bits where 2 k < N (that is, such that the numerical value of a block is always less than N; in practical applications, k is usually in the range 512 to 1024). k = 7, since 2 7 = 128 The function for encrypting a single block of plaintext M is: E'(e,N,M) = M e mod N for a message M, the ciphertext is M 77 mod 221 The function for decrypting a block of encrypted text c to produce the original plaintext block is: D'(d,N,c) = c d mod N Rivest, Shamir and Adelman proved that E' and D' are mutual inverses (that is, E'(D'(x)) = D'(E'(x)) = x) for all values of P in the range 0 ≤ P ≤ N. The two parameters e,N can be regarded as a key for the encryption function, and similarly d,N represent a key for the decryption function. So we can write K e = and K d =, and we get the encryption function: E(K e, M) ={M} K (the notation here indicating that the encrypted message can be decrypted only by the holder of the private key K d ) and D(K d, {M} K ) = M.

34 33 Performance of encryption and secure digest algorithms Key size/hash size (bits) Extrapolated speed (kbytes/sec.) PRB optimized speed (kbytes/s) TEA128700- DES563507746 Triple-DES 1121202842 IDEA1287004469 RSA 512 7- RSA2048 1- MD5128174062425 SHA 16075025162 PRB = Preneel, Rijmen and Bosselaers [Preneel 1998] Algorithm Public key Secret key Digest speeds are for a Pentium II processor at 330 MHZ *

35 34 Case study: Needham - Schroeder protocol In early distributed systems (1974-84) it was difficult to protect the servers –E.g. against masquerading attacks on a file server –because there was no mechanism for authenticating the origins of requests –public-key cryptography was not yet available or practical  computers too slow for trap-door calculations  RSA algorithm not available until 1978 Needham and Schroeder therefore developed an authentication and key-distribution protocol for use in a local network –An early example of the care required to design a safe security protocol –Introduced several design ideas including the use of nonces. *

36 35 HeaderMessageNotes 1. A->S: A, B, N A A requests S to supply a key for communication with B. 2. S->A:{N A, B, K AB, {K AB, A} K B } K A S returns a message encrypted in A’s secret key, containing a newly generated key K AB and a ‘ticket’ encrypted in B’s secret key. The nonce N A demonstrates that the message was sent in response to the preceding one. A believes that S sent the message because only S knows A’s secret key. 3. A->B: A sends the ‘ticket’ to B. 4. B->A: B decrypts the ticket and uses the new key K AB to encrypt another nonce N B. 5. A->B: A demonstrates to B that it was the sender of the previous message by returning an agreed transformation of N B. {K AB, A} K B {N B } K AB {N B - 1} K AB Ticket The Needham–Schroeder secret-key authentication protocol N A is a nonce. Nonces are integers that are added to messages to demonstrate the freshness of the transaction. They are generated by the sending process when required, for example by incrementing a counter or by reading the (microsecond resolution) system clock. * Weakness: Message 3 might not be fresh - and K AB could have been compromised in the store of A's computer. Kerberos (next case study) addresses this by adding a timestamp or a nonce to message 3.

37 36 Case study: Kerberos authentication and key distribution service  Secures communication with servers on a local network –Developed at MIT in the 1980s to provide security across a large campus network > 5000 users –based on Needham - Schroeder protocol  Standardized and now included in many operating systems –Internet RFC 1510, OSF DCE –BSD UNIX, Linux, Windows 2000, NT, XP, etc. –Available from MIT  Kerberos server creates a shared secret key for any required server and sends it (encrypted) to the user's computer  User's password is the initial secret shared with Kerberos *

38 37 Server Client DoOperation Authentication database Login session setup Ticket- granting service T Kerberos Key Distribution Centre Server session setup Authen- tication service A Service function System architecture of Kerberos 3. Request for server ticket 4. Server ticket Step B 5. Service request Request encrypted with session key Reply encrypted with session key Step C 1. A->S: A, B, N A 2. S->A:{N A, B, K AB, {K AB, A} K B } K A 3. A->B: 4. B->A: {K AB, A} K B {N B } K AB Needham - Schroeder protocol 5. A->B: {N B - 1} K AB Step B once per server session Step C once per server transaction * Step A once per login session 1. Request for TGS ticket 2. TGS ticket Step A TGS: Ticket- granting service

39 38 Kerberized NFS  Kerberos protocol is too costly to apply on each NFS operation  Kerberos is used in the mount service: –to authenticate the user's identity –User's UserID and GroupID are stored at the server with the client's IP address  For each file request: –UserID and GroupID are sent encrypted in the shared session key –The UserID and GroupID must match those stored at the server –IP addresses must also match  This approach has some problems –can't accommodate multiple users sharing the same client computer –all remote filestores must be mounted each time a user logs in *

40 39 Case study: The Secure Socket Layer (SSL)  Key distribution and secure channels for internet commerce –Hybrid protocol; depends on public-key cryptography –Originally developed by Netscape Corporation (1994) –Extended and adopted as an Internet standard with the name Transport Level Security (TLS) –Provides the security in all web servers and browsers and in secure versions of Telnet, FTP and other network applications  Design requirements –Secure communication without prior negotation or help from 3rd parties –Free choice of crypto algorithms by client and server –communication in each direction can be authenticated, encrypted or both

41 40 SSL protocol stack SSL Handshake protocol SSL Change Cipher Spec SSL Alert Protocol Transport layer (usually TCP) Network layer (usually IP) SSL Record Protocol HTTPTelnet SSL protocols:Other protocols: * negotiates cipher suite, exchanges certificates and key masters changes the secure channel to a new spec implements the secure channel

42 41 Client A Server B ClientHello ServerHello SSL handshake protocol Establish protocol version, session ID, cipher suite, compression method, exchange random start values Certificate Certificate Request ServerHelloDone Optionally send server certificate and request client certificate Certificate Certificate Verify Send client certificate response if requested Change Cipher Spec Finished Change Cipher Spec Finished Change cipher suite and finish handshake * Includes key master exchange. Key master is used by both A and B to generate: 2 session keys2 MAC keys K AB M AB K BA M BA ComponentDescriptionExample Key exchange method the method to be used for exchange of a session key RSA with public-key certificates Cipher for data transfer the block or stream cipher to be used for data IDEA Message digest function for creating message authentication codes (MACs) SHA Cipher suite

43 42 SSL handshake configuration options ComponentDescriptionExample Key exchange method the method to be used for exchange of a session key RSA with public-key certificates Cipher for data transfer the block or stream cipher to be used for data IDEA Message digest function for creating message authentication codes (MACs) SHA *

44 43 SSL record protocol Application data abcdefghi abcdefghi Record protocol units Fragment/combine Compressed units Compress MAC Hash Encrypted Encrypt TCP packet Transmit *

45 44 Summary  It is essential to protect the resources, communication channels and interfaces of distributed systems and applications against attacks.  This is achieved by the use of access control mechanisms and secure channels.  Public-key and secret-key cryptography provide the basis for authentication and for secure communication.  Kerberos and SSL are widely-used system components that support secure and authenticated communication. *


Download ppt "Security 2 Outline Various Attacks to Computer Security Cryptography Authentication & Key Distribution Access Control Logic of Authentication."

Similar presentations


Ads by Google