0. Course Overview. Architecture models; network architectures: OSI, Internet and LANs; interprocess communication

Transcription

1 0. Course Overview I. Introduction II. Fundamental Concepts of Distributed Systems Architecture models; network architectures: OSI, Internet and LANs; interprocess communication III. Time and Global States Clocks and concepts of time; Event ordering; Synchronization; Global states IV. Coordination Distributed mutual exclusion; Multicast; Group communication, Byzantine problems (consensus) V. Distribution and Operating Systems Protection mechanisms; Processes and threads; Networked OS; Distributed and Network File Systems (NFSs) VI. Peer to peer systems Routing in P2P, OceanStore, Bittorrent, OneSwarm, Ants P2P, Tor, Freenet, I2P VII. Security Security concepts; Cryptographic algorithms; Digital signatures; Authentication; Secure Sockets Distributed Systems Fall 2009 VII 1

2 Computer Security Security Objective abstract requirement to be met by system examples confidentiality of word/data protection from loss Security Policy organizational guidelines established in order to achieve security objectives example access to building only allowed for regular employees or registered visitors Security Mechanism technical mechanism used to implement security policies badges front desk clerk Distributed Systems Fall 2009 VII 2

3 Computer Security Security Threats leakage eavesdropping masquerading message tampering replaying denial of service Distributed Systems Fall 2009 VII 3

4 Computer Security Challenges in the Design of Secure Distributed Systems insecurity of open networks (like Internet) forgery: message sources can be modified address spoofing : Mallory (impostor) can pretend to be Alice and receive messages destined for her cryptographic algorithms widely distributed don t rely on own secret cryptographic algorithm the best cryptographic algorithms are usually in the public domain, there is even source code publicly available (c.f. [Schneider]) rely on secrecy of cryptographic keys instead! large computing resources available to everyone in particular to attackers example: distributed code hacking attempts via distributed background computation trusted base minimize the availability of secrets be sceptical e.g., don t trust Java VM s protection mechanisms when implementing security Distributed Systems Fall 2009 VII 4

5 Computer Security Some examples of Security Problems in Distributed Systems secrecy of contents authentication of sender e commerce payment for goods and services on the web authenticate vendor to buyer ensure privacy of payment information (e.g., credit card number) Access to restricted information stored in databases Security mechanisms need to be provided at reasonable cost Distributed Systems Fall 2009 VII 5

6 Computer Security invocation Access rights Object Client result Server Principal (user) Network Addison-Wesley Publishers 2000 Principal (server) Processes and Principals client server interactions each client/server interaction has an authorized user or process that invokes the request, or receives the results these processes or users are called principals central problem to computer security authentication of principals use or secure channels Distributed Systems Fall 2009 VII 6

7 Computer Security Principal A Principal B Process p Secure channel Process q Addison-Wesley Publishers 2000 Secure Channels each process knows identity of principal on behalf of whom peer process is executing ensures privacy and integrity of data transmitted there is a protection mechanism against replaying or reordering of messages, usually a sequence number or time stamp Distributed Systems Fall 2009 VII 7

8 Cryptography Protagonists Alice Bob Carol Dave Eve Mallory Sara First participant Second participant Participant in three- and four-party protocols Participant in four-party protocols Eavesdropper Malicious attacker A server Addison-Wesley Publishers 2000 Distributed Systems Fall 2009 VII 8

9 Cryptography Notation K A K B K AB K Apriv K Apub {M} K [M] K Alice s secret key Bob s secret key Secret key shared between Alice and Bob Alice s private key (known only to Alice) Alice s public key (published by Alice for all to read) Message M encrypted with key K Message M signed with key K Addison-Wesley Publishers 2000 Distributed Systems Fall 2009 VII 9

10 Cryptography Basic Concepts encoding of information so that content is hidden from naïve third party keys parameter of encoding and decoding process decoding cannot be obtained without knowledge of a suitable key notation: encryption for message M using key K E(K, M) = {M} K pair of keys K 1 and K 2 is called cognate, if D(K 1, E(K 2, M)) = M symmetric, if cognate and K 1 = K 2 asymmetric, if cognate and K 1 K 2 Distributed Systems Fall 2009 VII 10

11 Cryptography Basic Concepts shared secret keys symmetric cryptography same key used for encoding and decoding sender and receiver share knowledge of key key not revealed to third party public/private keys asymmetric cryptography different keys used for encoding and decoding sender encodes message using recipient's public key recipient decodes message using her/his private key Distributed Systems Fall 2009 VII 11

12 Cryptography Basic Concepts symmetric cryptography, one way property: F k ([M]) := E(K, M) and D(K, {M} K ) are easy to compute F 1 k ([M]) so hard to compute that it is practically infeasible naïve approach: given M, {M} K, try all possible values for K on M until {M} K is obtained example: DES requires 2 K tries at maximum 2 K 1 tries on average i.e., trial procedure is exponential in the length of K Distributed Systems Fall 2009 VII 12

13 Cryptography Basic Concepts asymmetric cryptography goal: avoid the need for trust no need to share secret key with communication partner trap door function: one way function with secret exit easy to compute in one direction infeasible to compute inverse unless a secret is known example (RSA) given two large prime numbers is root multiply prime numbers to yield key use key for encoding decoding impossible (factorization of primes) unless one of the primes given depends on safe sizes for N generally, computationally quite heavy Distributed Systems Fall 2009 VII 13

14 Cryptography plaintext blocks ciphertext blocks n+3 n+2 n+1 XOR n-3 n-2 n-1 n E(K, M) Addison-Wesley Publishers 2000 Cypher Block Chaining encoding of fixed length blocks attacker may infer key from repetitions cannot detect if message corrupted make one block depend on previous block use XOR indempotence: repeated application of XOR delivers original data (do second XOR at receiver before decryption) problem sending of same message to two recipients means identical cyphertext will be sent to both destinations eavesdropper may draw conclusions from this prepend randomly generated initialization string before every message Distributed Systems Fall 2009 VII 14

15 Cryptography keystream number generator n+3 n+2 n+1 E(K, M) buffer XOR plaintext stream Addison-Wesley Publishers 2000 ciphertext stream Stream Cypher continuous data streams, e.g., telephone samples of 8 bit length wasteful to fit into 64 bit block for encoding encryption algorithm encrypting one bit at a time keystream secure, arbitrary length sequence of bits obscuring the plaintext required to be able to decrypt ({M} K xor plaintext) at receipient in order to filter original stream use identical keystream and number generator at receipient to generate argument for XOR operation of ({M} K xor plaintext) works only for symmetric cryptography Distributed Systems Fall 2009 VII 15

16 Symmetric Cryptography void encrypt(unsigned long k[], unsigned long text[]) { unsigned long y = text[0], z = text[1]; 1 unsigned long delta = 0x9e3779b9, sum = 0; int n; 2 for (n= 0; n < 32; n++) { 3 sum += delta; 4 y += ((z << 4) + k[0]) ^ (z+sum) ^ ((z >> 5) + k[1]); 5 z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]); 6 } text[0] = y; text[1] = z; 7 } Addison-Wesley Publishers 2000 Tiny Encryption Algorithm (TEA) components integer addition (4, 5, 6) bitwise logical shifts >> and << (5, 6), achieves diffusion hide repetition and redundancy in plaintext confusion combine each block of plaintext with key obscures relationship of blocks in M and {M} K avoids inferring key from character frequencies in text (c.f. German Enigma cypher machine: used one character blocks) Distributed Systems Fall 2009 VII 16

17 Symmetric Cryptography 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 << 4) + k[2]) ^ (y + sum) ^ ((y >> 5) + k[3]); y -= ((z << 4) + k[0]) ^ (z + sum) ^ ((z >> 5) + k[1]); sum -= delta; } text[0] = y; text[1] = Addison-Wesley z; Publishers 2000 } Tiny Encryption Algorithm (TEA) components integer addition (4, 5, 6) bitwise logical shifts >> and << (5, 6), achieves diffusion hide repetition and redundancy in plaintext confusion combine each block of plaintext with key obscures relationship of blocks in M an {M}K avoids inferring key from character frequencies in text (c.f. German Enigma cypher machine: used one character blocks) Distributed Systems Fall 2009 VII 17

18 Symmetric Cryptography Data Encryption Standard (DES) developed at IBM, then ANSI standard (1977) encrypts 64 bit long plaintext in ciphertext of the same length uses 56 bit key encryption 16 rounds of bit rotation, number of bits to be rotated determined by key plus 3 key independent transpositions fast if implemented in VLSI hardware DES was cracked first in 1997 brute force attack based on a plaintext/cyphertext sample cracked key to be used to decrypt challenge message set of up to Internet users who allowed decoding processes to run in background on their computers each had computing power comparable to a 200 MHz Pentium Processor key discovered after about 12 days, after 25% of the possible 2 56 (6*10 16 ) values had been explored second attack 1998 on dedicated hardware successful after three days DES with 56 bit can be considered obsolete triple DES : E 3DES (K 1, K 2, M) = E DES (K 1, D DES (K 2, E DES (K 1, M))) comparable to a key with 112 bit Distributed Systems Fall 2009 VII 18

19 Symmetric Cryptography International Data Encryption Algorithm (IDEA) uses 128 bit key to encode 64 bit blocks (block cipher) uses both confusion and diffusion based on algebra of groups, depending on key, eight rounds of XOR additon modulo 2 16 mutiplication modulo like DES, uses same function for encoding like for decoding allows for efficient hw implementation no major weaknesses known to date Advanced Encryption Standard (AES) proposed by NIST in the US selected algorithm (October 2000): Rijndael (Daemen and Rijmen) iterated block cipher algorithm variable block and key lengths both of which can be independently specified as being of 128, 192 and 256 bits in length see likely to become the most heavily used symmetric algorithm Distributed Systems Fall 2009 VII 19

20 Asymmetric Cryptography Principle cognate pair of keys K e and K d for secure communication produce K e and K d keep K d as secret publish K e sender can send {M} K e only authorized receipient can decode {M} K using trap door e Rivest, Shamir and Adleman (RSA) Algorithm (1978) principle encoding: multiplication of very large prime numbers decoding: division (trap door function) without knowledge of secret key this would amount to factorization of very large numbers, computationally impossible Distributed Systems Fall 2009 VII 20

21 Asymmetric Cryptography Rivest, Shamir and Adleman (RSA) Algorithm (1978) choose prime numbers P, Q > form N = P*Q Z = (P 1) * (Q 1) choose d a number that has no common factors with Z (other than 1) find e by solving e*d = 1 mod Z i.e., e is smallest element divisible by d in the series Z+1, 2Z+1,... to encrypt, use plaintext blocks of equal length k bits such that 2 k < N (k in practice usually between 512 and 1024) E (e, N, M) = M e mod N to decrypt ciphertext block c D (d, N, c) = c d mod N it has been proven that E and D are mutual inverses Example with small numbers P = 13, Q = 17 N = 221 Z = 192 d = 5 e*d = 1 mod 192 = 1, 193, 385, is divisible by d = 5 e = 385 / 5 = 77 k = 7 (2 7 = 128 < 221) ciphertext = M 77 mod 221 plaintext = ciphertex 5 mod 221 Distributed Systems Fall 2009 VII 21

22 Asymmetric Cryptography Rivest, Shamir and Adleman (RSA) Algorithm (1978) K e = <e, N> key for encryption function K d = <d, N> key for decryption function security argument recipient must publish K e does not compromise security of d, since determination of d depends on original prime numbers P and Q can only be obtained through factorization of N complexity of factorization equivalent to cracking of code 1978: Rivest et al. predicted factoring number as large as would take four billion years today, numbers of 155 digits (corresponds to 500 binary digits) have been successfully factorized consider 512 bit key length not entirely secure RSA Corp. recommends key lengths of at least 768 bits (230 digital digits) for long term (~20 years) security keys of up to 2048 bits are used in some applications Distributed Systems Fall 2009 VII 22

23 Asymmetric Cryptography Rivest, Shamir and Adleman (RSA) Algorithm (1978) chosen plaintext attack public key available to attackers use public key to encode arbitrary bit strings until they match observed ciphertext infer private key counter measure make sure all messages are at least as long as key attack at least as heavy as direct attack on key Distributed Systems Fall 2009 VII 23

24 Asymmetric Cryptography Hybrid Symmetric/Asymmetric Protocols asymmetric cryptography, i.e., RSA, is computationally extremely expensive, even for smaller message exchanges approach: combine asymmetric and symmetric protocols use public key cryptography to authenticate parties and exchange secret (session) keys afterwards, use exchanged session keys to en and decrypt application data example: ssl Distributed Systems Fall 2009 VII 24

25 Digital Signatures Objectives of Ink on Paper Signatures convinces recipient of document that (take with grain of salt...) signer, and nobody else but signer, deliberately signed document (authenticity of signature), and document was not altered since signing the signature was meant to be placed on this document, and no other document, since signatures cannot be copied the signer cannot claim that s/he didn t sign the document (nonrepudiability) Differences for digital, electronic documents simply appending identity of sender in digital form won t suffice, since this process can easily be forged therefore, find ways to irrevocably bind signer s identity to a digital document non repudiation of electronic documents deliberate publication of private key special protocols needed undeniable digital signatures (c.f. [Schneier]), or non transferable signatures cannot be verified without signer s consent Alice can prove she did not sign, and cannot falsely do so Distributed Systems Fall 2009 VII 25

26 Digital Signatures Approaches to Digital Signatures digital signatures signing of document M by prinicpal A [M] KA : encryption of M by A with Key K A signed document M, A, [M] KA [M] KA can be used by receiving principal to verify that message originated from A and was not subsequently modified secret keys requires sharing keys public key cryptography signer uses its private key to encrypt message arbitrary receipients use signers public key to decrypt more like ink on paper signatures non repudiability problem remains secure hash functions H(M) design H so that H(M) H(M ) for all likely pairs of messages M and M otherwise, principal could deny having signed M, saying that it had originally sent M Distributed Systems Fall 2009 VII 26

27 Digital Signatures Digital Signatures with Public Keys Signing through A 1. generate K pri M H(M) h E(K pri, h) signed doc {h} Kpri K pub 2. compute h = H(M) and encrypts h to {h} Kpriv 3. send signed Message M, {h} Kpriv 128 bits M Verification through B 4. receive M*, {h*} Kpri h = D(K pub, {h*} Kpri ) h = H(M*) if h = h signature authentic document contents unchanged {h*} Kpri M* D(K pub,{h*}) h' H(M*) h Addison-Wesley Publishers 2000 h = h '? Distributed Systems Fall 2009 VII 27

28 Digital Signatures Digital Signatures with Shared Secret Key problematic, since shared key must be disclosed transmission of key must be secured signer may not know at time of signing who will later want to verify signature delegate verification to trusted third party holding secret keys for all signers signatures are more likely to be forged frequently used to authenticate messages sent across secure channels established according to hybrid protocol signatures are then called message authentication codes (MACs) Distributed Systems Fall 2009 VII 28

29 Digital Signatures Digital Signatures with Shared Secret Key Signing through A 1. generate random key K 2. distribute K to principals through secure channels, principals trusted not to reveal K 3. compute h = H(M;K) 4. send [M] K = M,h (h is a MAC) Signing M K H(M;K) signed doc h M Verification through B 5. receive M*, h* h = H(M*;K) if h* = h signature verified Verifying M* K H(M*;K) h* h' h* = h'? Addison-Wesley Publishers 2000 Distributed Systems Fall 2009 VII 29

30 Digital Signatures Secure Digest Functions requirements for one way hash functions given M, H(M) is easy to compute given H(M), M is difficult to compute given M, it is difficult to find M such that H(M) = H(M ) threat of birthday attack A generates M and M, M is favourable to B, M isn t A makes several subtly different versions of both M and M that are visually indistinguishable (e.g., by adding spaces at end of line) A compares hashes for all of the Ms and all for all of the M s until she finds two that are identical gives favourable variant of M to Bob for him to sign using his private key replaces M by variant of M that hashes to same value and combines it with the original signature obtained from M 64 bit hash values means we need 2 32 variants of M and M on average min key length 128 hash functions used in practice MD5: generates 128 bit digest from 512 bit block, very efficient SHA: based on MD4, produces 160 bit digest, much less efficient than MD5 Distributed Systems Fall 2009 VII 30

31 Cryptographic Algorithm Performance Key size/hash size (bits) Extrapolated speed (kbytes/sec.) PRB optimized (kbytes/s) TEA DES Triple-DES IDEA RSA RSA MD SHA Addison-Wesley Publishers 2000 key size: rough estimate of relative security against brute force attacks speed: estimate of algorithm s performance left column: non optimized C code as given in literature PRB optimized: commercial, proprietary assembler implementation Distributed Systems Fall 2009 VII 31

32 Certificates Certificate somebody s key, signed by a trusted authority avoids substitution of one key for another example authentication, that Alice has an account with Bob (a bank) 1. Certificate type: Account number 2. Name: Alice 3. Account: Certifying authority: Bob s Bank 5. Signature: {Digest(field 2 + field 3)} KBpriv Addison-Wesley Publishers 2000 Alice needs to prove to merchant Carol that she can validate the signature using K Bpub attack Alice generates K B pub and K B priv Alice uses this to generate a forged certificate, claiming it comes from Bob solution Carol needs certificate for K Bpub signed by a trusted authority Distributed Systems Fall 2009 VII 32

33 Certificates 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)} KFpriv Addison-Wesley Publishers 2000 Chained Certificates choice of trusted authority? revelation of private keys => keep chain as short as possible Revocation of Certificates Bob manages a club, maintains list list open only to members Bob issues certificates ( Alice is a member, Bob, {digest( Alice is a member )}KB priv ) problem: what if Alice leaves the club? explicit certificate revocation too expensive add expiry date to certificate Distributed Systems Fall 2009 VII 33

34 Certificates Subject Issuer Period of validity Administrative information Extended Information Distinguished Name, Public Key Distinguished Name, Signature Not Before Date, Not After Date Version, Serial Number Addison-Wesley Publishers 2000 X.509 Certificate Standard useful if certificates have common format used in Secure Socket Layer (SSL) protocol certificate authorities Verisign Distributed Systems Fall 2009 VII 34

35 Authentication Authentication authentication between pair of principals each principal is assured of the identity of its communication peer possible with secret and public key schemes Authenticated Communication via Authentication Server assume Sara to be a securely operated authentication server maintains user passwords holds secret keys for all principals in system generated by applying a one way function to principal s password maintains tickets encrypted data object identity of principal to whom it is issued shared key that has been set up for the current principal toprincipal communication session Distributed Systems Fall 2009 VII 35

36 Authentication Authenticated Communication via Authentication Server a simple protocol: Alice sends plaintext request for ticket to access Bob to Sara Sara returns {{Ticket} KB, K AB } KA to Alice {Ticket} KB : ticket to be decoded and used by Bob Ticket = {K AB, Alice} KB K AB : session key K A : key derived from Alice s password Alice decrypts received message uses K A if her password is consistent with that stored on Sara, she will obtain valid ticket for access to Bob this is called a challenge neither Alice nor any impostor can make use of ticket unless s/he can generate K A Alice sends {{Ticket} KB, Alice, access request} in plaintext to Bob Bob decrypts ticket using K B note password is not transmitted prior knowledge of Alice s password on Sara requires secure network Distributed Systems Fall 2009 VII 36

37 Authentication Authenticated Communication with Public Keys using a hybrid cryptographic protocol assume Bob has generated K Bpub and K Bpriv and has a certificate with trusted authority Alice obtains Bob s public key certificate from trusted authority and retrieves K Bpub Alice creates shared key K AB and encrypts it using K Bpub Alice sends {keyname, {K AB }KB pub } to Bob unique keyname, since Bob may be using a number of private/public key pairs at any given time Bob uses K Bpriv corresponding to keyname and obtains K AB note if message corrupted in transit from Alice to Bob, then they don t share common key message may contain a string like address so that having obtained an incorrect key can be detected by Bob Distributed Systems Fall 2009 VII 37

38 Authentication Authenticated Communication with Public Keys man in the middle attack Mallory intercepts Alice s initial request sends a response to Alice containing its own public key henceforth, Mallory can intercept all messages and pretend to be Bob protection: Alice needs to make sure that Bob s public key originates from a certificate that is signed by a trusted authority Distributed Systems Fall 2009 VII 38

39 Needham Schroeder Authentication Needham Schroeder (1978) here: only secure key variant public key variant similar to ssl goal: authentication and key distribution based on authentication server supplies secret keys to pairs of clients basic principle A requests key from server often: A is client, and B provides some service obtains key one version to use one version encrypted for secure transfer to B authentication server maintains name and key (= password) for all clients in system protocol based on tickets to ensure freshness, protocol uses nonces integers used only once, generated on demand protocol ensures A receives message decoded with K AB, it knows it can only come from B A sends message encoded with K AB, it knows it can only be read by B Distributed Systems Fall 2009 VII 39

40 Needham Schroeder Authentication Needham Schroeder Secret Key Authentication Protocol Header Message Notes 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} KB } KA 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: {K AB, A} KB A sends the ticket to B. 4. B->A: {N B } KAB B decrypts the ticket and uses the new key K AB to encrypt another nonce N B. 5. A->B: {N A demonstrates to B that it was the sender of the B - 1} KAB previous message by returning an agreed transformation of N B. Addison-Wesley Publishers 2000 Distributed Systems Fall 2009 VII 40

41 Needham Schroeder Authentication One Known Weakness in Needham Schroeder assume intruder manages to obtain K AB and get a copy of ticket {K AB, A}K B not unrealistic since these may reside in unprotected memory of an application programme then intruder can later reuse ticket and pretend to be A possible solution: add nonce or timeout to ticket {K AB, A, t}k B Distributed Systems Fall 2009 VII 41

42 Kerberos Kerberos server based authentication extension of Schroeder Needham often used to support secure client server communication History developed at MIT (1988) Internet standard: RFC 1510 (1993) part of OSF/DCE part of Windows 2000 as default authentication protocol Distributed Systems Fall 2009 VII 42

43 Kerberos Security objects ticket verifies that a client has recently been authenticated usually valid for a few hours has fixed begin/end time of validity authenticator session key encrypted token sent from client to server contains client name and timestamp proving identity of user and currency of server communication session key randomly generated by authentication server used for encrypting all authenticators used for client server communication whenever client requires it Comparison to Needham Schroeder uses time values to avoid re use of old tickets impose lifetime for tickets allows system to cancel authorization Distributed Systems Fall 2009 VII 43

44 Kerberos Kerberos Architecture Kerberos Key Distribution Centre Step A 1. Request for TGS ticket Authentication service A Authentication database Ticketgranting service T 2. TGS ticket Client C Login session setup Server session setup DoOperation Step B 3. Request for server ticket 4. Server ticket Step C 5. Service request Request encrypted with session key Reply encrypted with session key Service function Server S Addison-Wesley Publishers 2000 Distributed Systems Fall 2009 VII 44

45 Kerberos Kerberos Protocol challenge Addison-Wesley Publishers 2000 Notation A: authentication service T: ticket granting service C: client n: a nonce t: a timestamp t 1 /t 2 : start/ending time for ticket Distributed Systems Fall 2009 VII 45

46 Kerberos Kerberos Protocol challenge Addison-Wesley Publishers 2000 Note use of K C if principal is user, K C is a scrambled (transformed) version of password upon receipt of message 2, client will prompt user for password client will use user password to decode challenge Distributed Systems Fall 2009 VII 46

47 Kerberos Kerberos Protocol when client has obtained ticket for ticket granting server, it can obtain an arbitrary number of server tickets until ticket for ticket granting server expires protocol to obtain ticket for server note: {auth(c)} KCT = {C, t} KCT Addison-Wesley Publishers 2000 Distributed Systems Fall 2009 VII 47

48 Kerberos Kerberos Protocol client issues request to server server returns nonce to assure client of its authenticity Addison-Wesley Publishers 2000 Distributed Systems Fall 2009 VII 48

49 Kerberos Application of Kerberos authentication in an insecure network environment only Kerberos servers are assumed to be operated in a secure manner possible application areas: any type of client server interactions user login client sends user name to Kerberos server returns session key, nonce encoded in user s password, ticket for TGS login client decrypts session key, nonce, using user s password client checks nonce, stores session key and ticket for further use login client can erase user pw from memory (no longer needed) client can now start login session with login server note: password never revealed on network network file access (e.g., NFS or Andrew FS) (access to smtp server/imap server) rlogin printing Distributed Systems Fall 2009 VII 49

50 Kerberos Critique of Kerberos Kerberos 4 uses timestamps for freshness nonces requires at least loose clock synchronization synchronization protocol itself must be secured against attacks Kerberos 5 allows nonces to be implemented as sequence numbers need to be unique servers need to keep memory of recently used nonces to detect replay inconvenient implementation constraint Kerberos variant that does not rely on timestamps has been suggested Kerberos security depends on session lifetime choice of life span too short: may cause inconvenient interruptions of service too long: users no longer authenticated may continue to use service Distributed Systems Fall 2009 VII 50

51 Secure Socket Layer Objective achieve secure channels adjusted security in a heterogeneous environment like the Internet the cryptographic capabilities and security needs of the prinicpals are highly varied cryptographic overkill may waster resources therefore: adjusted, negotiable levels of security switches: from unencoded to public key to secret key History of SSL originally developed by Netscape for use in Web Browser Transport Layer Security (TSL) extended version of SSL Internet standard: RFC 2246 (1999) Use of SSL secure HTTP interactions on Internet ( e commerce basis for secure telnet, ftp, pop, remote login, etc proprietary and public domain implementations exist include Java and CORBA APIs Distributed Systems Fall 2009 VII 51

52 Secure Socket Layer SSL Handshake protocol SSL Change Cipher Spec SSL Alert Protocol HTTP Telnet SSL Record Protocol Transport layer (usually TCP) Network layer (usually IP) SSL protocols: Addison-Wesley Publishers 2000 Other protocols: SSL Protocol Architecture session level layer protocol implementing a secure channel above transport layer beneath application level authentication mechanisms Distributed Systems Fall 2009 VII 52

53 Secure Socket Layer SSL Protocol Handshake Phases ClientHello ServerHello Establish protocol version, session ID, cipher suite, compression method, exchange random values Certificate Certificate Request ServerHelloDone Optionally send server certificate and request client certificate Client Certificate Server Send client certificate response if Certificate Verify requested Change Cipher Spec Finished Change cipher suite and finish handshake Change Cipher Spec Finished Addison-Wesley Publishers 2000 Distributed Systems Fall 2009 VII 53

54 Secure Socket Layer Cipher Suites particular choice for each of the following components facilitates negotiation of cryptographic mechanisms each cipher suite can be understood as a cryptographic profile example cipher suite configuration: Component Description Example Key exchange method Cipher for data transfer Message digest function the method to be used for exchange of a session key the block or stream cipher to be used for data for creating message authentication codes (MACs) Addison-Wesley Publishers 2000 RSA with public-key certificates IDEA SHA Distributed Systems Fall 2009 VII 54

55 Secure Socket Layer SSL Record Protocol Application data Fragment/combine abcdefghi Record protocol units abc def ghi Compressed units Compress (opt.) MAC Encrypted Hash Encrypt Transmit TCP packet Distributed Systems Fall 2009 VII 55

56 Security in Distributed Systems Kerberos based Authentication in NFS in standard NFS, there is no check whether the supplied user identity in each request is correct approach: use Kerberos authentication use full Kerberos tickets and authenticators as credentials problem NFS server is state less necessary to perform Kerberos authentication for every single request considered too expensive solution when mounting root and home file systems supply NFS mount server with full Kerberos user authentication credentials user s numerical id address of client computer when serving accesses, compare numerical id and address of client with data stored on server resistant against most attacks works only if not more than one user logs on to one client computer Distributed Systems Fall 2009 VII 56

57 Security in Distributed Systems Firewalls used to protect intranets, in particular to control communication in and out of an intranet goals of firewall policies service control: limit allowed services on the intranet disallow http requests to certain machines reject non secure remote login behaviour control: disallow behaviours that infringe on organization s policies spam detection user control: discriminate between user groups allow only system personnel to download and install software Distributed Systems Fall 2009 VII 57

58 Security in Distributed Systems Firewall Mechanisms IP packet filtering destination/source address inspection inspection of service type filed of IP packets e.g., prohibit use of NFS servers by external clients usually done by router ensure that router runs securely TCP gateway check all TCP connection requests check all TCP segment transmissions avoidance of denial of service attacks application level gateway check content of TCP segments often, implemented as a proxy for application process e.g.: telnet connection request starts telnet proxy connection application/telnet proxy and telnet proxy/external user bastion: separate secure computer for TCP gateway and application level gateway Distributed Systems Fall 2009 VII 58

59 Security in Distributed Systems Firewall Architectures a) Filtering router Router/ filter Protected intranet Internet web/ftp server b) Filtering router and bastion R/filter Bastion Internet web/ftp server c) Screened subnet for bastion R/filter Bastion R/filter Internet web/ftp server advantages of c) IP addresses of hosts on intranet need not be made public if first filter fails, second (inner) filter will step in Distributed Systems Fall 2009 VII 59

60 Security in Distributed Systems Virtual Private Networks (VPNs) extend the intranet security beyond intranet boundaries requires establishing secure channels across internet links usually used: IPSec extensions of IPv4 (RFC 2411) variant 1: transport mode client supports cryptography inside TCP/IP stack variant 2: tunnel mode security is achieved only between gateways gateways encrypt IP packets and wrap new headers around them Distributed Systems Fall 2009 VII 60

61 Security in Distributed Systems Virtual Private Networks (VPNs) IPSec services confidentiality through encryption authentication of sender integrity through detection of data tampering replay protection methodologies for key management: Internet Key Exchange (IKE) Standardization IPSec and IKE developed by IETF and standardized as RFCs Why not rely on application level end to end cryptography and authentication? avoids relying on correct handling of security mechanisms at application program level avoids cryptographic overhead inside intranet disadvantage reliance on faithful handling of keys inside and by IP routers IPv6 implements secure channels using extension IP header types authentication encrypted payload Distributed Systems Fall 2009 VII 61

62 Security in Distributed Systems Access Control objects encapsulate data that may need to be protected against unauthorized accesses objects often maintained by servers that provide methods for access to data generic server request format <operation, principal, resource> steps authenticate request message authenticate principal's credentials evidence provided by principal when accessing a resource apply access control protection domains execution environment shared by a number of processes contains list of <resource, rights> pairs specifies rights on resources that all processes in protection domain are entitled to often, protection domain corresponds to all rights that a user has defined by user id and group id in UNIX access control schemes capabilities access control lists (ACLs) Distributed Systems Fall 2009 VII 62

63 Security in Distributed Systems Access Control capabilities: concept similar to certificates format resource identifier operations authentication code digital signature, rendering capability unforgeable capability will only be granted if grantee is authenticated by server as belonging to the protection domain necessary to perform the requested operation requests have format <operation, userid, capability> access control validation of the capability (authentication code) check that requested operation is in set of allowed operations for that capability problems key theft, e.g., through eavesdropping include information identifying holder of capability revocation of capabilities include timeouts Distributed Systems Fall 2009 VII 63

64 Security in Distributed Systems Access Control access control lists (ACLs) ACL stored with every resource entries <domain, operations>, one for each domain domain may be identifier expression, e.g., "owner of the file", "users in the same group as file" (UNIX) requests <operation, principal, resource> authenticate principal check admissibility or operation for requested resource Implementation digital signatures, credentials and public key certificates used Java allows objects to manage access control with ACL, Principal and Signer classes CORBA security service offering access control with credentials and ACLs for ORBs Distributed Systems Fall 2009 VII 64

65 Security in Distributed Systems CORBA Security Service included services principal authentication generation of credentials for principals delegation of credentials, including restriction access control for remote invocations access rights can be specified using ACLs auditing of remote invocations facilities for non repudiation secure remote invocation client s credentials included in request message server validates credentials and checks for freshness and whether they are signed by an acceptable authority server makes access control decision made by contacting object holding access right mappings possibly using an ACL target server may log invocations and store non repudiation credentials Distributed Systems Fall 2009 VII 65

66 Security in Distributed Systems CORBA Security Service security policies message protection policy authentication of client and/or server protection of messages against corruption/disclosure auditing policy non repudiation policy access control policy one per domain, a group of objects user credentials are called privileges, and access control checks whether user has credentials to access objects in a given domain methods are categorized into four classes get: return part of object state set: alter object state use: cause object to perform a task manage: functions not available for general use application programmer must use these attributes for any new interface s/he defines also application programmer s task to: setting privilege attributes and helping users to obtain necessary privileges Distributed Systems Fall 2009 VII 66

67 Biographic References for Cryptography Generally, refer to the extensive bibliography in the [Coulouris] textbook, or to the list of online reference available through Specific references on cryptography B. Schneier, Applied Cryptography, 2nd ed., John Wiley, 1996 A. Menezes et al., Handbook of Applied Cryptography, CRC Press, 1997 Distributed Systems Fall 2009 VII 67