From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design. Edition 4 Pearson Education 2005

Transcription

1 Chapter 7: Security From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 4 Introduction Security policies Provide for the sharing of resources within specified limits Independent of the technology used Security mechanisms Enforce the security policies Security model Resources are encapsulated by processes and must be protected against unauthorized access. Processes interact through network that are shared by users and enemies. 1

2 Threat Leakage The acquisition of information by unauthorized recipients Tampering The unauthorized alteration of information Vandalism Interference with the proper operation of a system without gain to perpetrator Attack Eavesdropping Obtain copies of messages without authority Masquerading Sending or receiving messages using the identity of another principal without authority Message tempering Intercepting messages and altering their contents before passing them on to the intended recipient Replaying Storing intercepted messages and sending them at a later date. It works even with authenticated and encrypted messages Denial of service Flooding a channel or other resource with messages in order to deny access for others 2

3 Threats from Mobile Code Programs are loaded from a remote server, and execute locally Java Each application has its own execution environment Each environment has a security manager that decides which resources are available to the application Once a security manager is set, it cannot be replaced The downloaded classes are stored separately from the local classes, preventing them from replacing local classes The bytecode are checked for validity Type-checking and code-validation mechanisms may not work as well as they are used for communication Information Leakage If the transmission of a message between two processes can be observed, some information can be gleaned from its mere existence A flood of messages to a dealer in a particular stock might indicate a high level of trading in that stock Assign security levels to information and channels Analyze the flow information into channels with the aim of ensuring that high-level information cannot flow into lower-level channels 3

4 Designing Secure Systems Analysis Worst-case assumption Design Validation List of threats Informal or formal (logical proof) Audit No list of threats is likely to be exhaustive Detect violations E.g. security log Balancing costs and inconvenience against the threats Worst-Case Assumptions and Design Guidelines Interfaces are exposed Networks are insecure Limit the lifetime and scope of each secret Algorithm and program code are available Publish the encryption and authentication algorithm, rely only on the secrecy of keys Ensure the algorithm is strong by throwing them open to scrutiny by public Attackers may have access to larger resources Should assume attackers may access the most powerful computers to break the security systems Minimize the trusted base Only trust the portion of a system that implement the security, and all the hardware and software components upon which they rely. 4

5 Security Techniques Cryptography Certificates Access control Credentials Firewalls Cryptography Encoding a message to hide its contents Symmetric: shared secret key, e.g. DES, IDEA, AES Asymmetric: public/private key pairs, e.g. RSA times slow Use Secrecy and integrity Ensure that content is unreadable and unaltered by third parties during transmission Authentication Ensure the identities between pairs of principals Digital signatures Ensure to a third party that a message is an unaltered copy of one produced by the signer 5

6 Figure 7.1 Familiar names for the protagonists in security protocols 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 Figure 7.2 Cryptography notations 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 Msigned with key K 6

7 Secrecy and Integrity Secret communication with a shared secret key Alice uses K AB and an agreed encryption function E(K AB, M) to encrypt and send any number of messages {M i } KAB to Bob Bob reads the encrypted messages using the corresponding decryption function D(K AB, M) Problems How can Alice send a shared key to Bob securely? 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? Note that replaying works with encrypted messages Authentication Authenticated communication with a server Alice sends an unencrypted message to Sara stating her identity and requesting a ticket for access to Bob Sara sends a response to Alice encrypted in K A consisting of a ticket encrypted in K B and a new secret key K AB for communicating with Bob, i.e. {{Ticket} KB, K AB } KA Alice decrypt the response using K A for ticket and K AB Alice sends the ticket to Bob together with her identity and a request R to access a file: {Ticket} KB, Alice, R The ticket is actually: {K AB, Alice} KB. Bob decrypts the ticket to authenticate the identity of Alice and communicate with Alice using K AB, called session key 7

8 Authentication (cont) Authenticated communication with public keys Alice accesses a key distribution service to obtain public-key certificate giving Bob s public key K Bpub Alice creates a new shared key K AB and encrypts it using K Bpub with a public-key algorithm, i.e. {K AB } KBpub Bob selects the corresponding private key K Bpriv to decrypt K AB Problems The key exchange is vulnerable to man-in-the-middle attacks. Mallory may intercept Alice s initial request for Bob s public-key certificate and send a response containing his own public key to Alice. He can then intercept all subsequent messages Digital Signatures Digest function: produce a fixed-length bit pattern that characterizes an arbitrary-length document, similar to checksum function Example: MD5, SHA Digital signatures with a secure digest function Alice computes a fixed-length digest of the document Digest(M) Alice encrypts the digest in her private key, appends it to M and makes the result M, {Digest(M)} KApriv available to the intended users Bob obtains the signed document, extracts M and computes Digest(M) Bob decrypts {Digest(M)} KApriv using Alices public key K Apub and compares the result with his calculated Digest(M). If they match, the signature is valid. 8

9 Certificates A digital certificate is a document containing a short statement in a standard format, such as X509, signed by a principal Example Alice can obtain a certificate from bank, Bob, stating account number to shop online Carol can accept such a certificate for charging items to Alice s account provided she can validate the signature in field 5 Carol needs bank s public key, and thus a certificate stating Bob s public key from trusted authority, Fred, to avoid false public/private key Recursive problem of authenticity: Carol can only rely on this certificate if she can be sure she knows Fred s authentic public key Hard to track down, invalidate, and delete all certificates Figure 7.3 Alice s bank account certificate 1. Certificate type: Account number 2. Name: Alice 3. Account: Certifying authority: Bob s Bank 5. Signature: {Digest(field 2 + field 3)} KBpriv 9

10 Figure 7.4 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)} KFpriv Figure 7.12 X509 Certificate format 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 10

11 Figure 7.5 Cipher block chaining plaintext blocks n+3 n+2 n+1 XOR E(K, M) ciphertext blocks n-3 n-2 n-1 n Figure 7.6 Stream cipher keystream number generator n+3 n+2 n+1 E(K, M) buffer XOR plaintext stream ciphertext stream 11

12 Figure 7.13 Performance of encryption and secure digest algorithms Key size/hash size (bits) Extrapolated speed (kbytes/sec.) PRB optimized (kbytes/s) TEA DES Triple-DES IDEA RSA RSA MD SHA Access Control Protected resource request messages: <op, principal, resource> Protection domain An execution environment shared by a collection of processes A set of <resource, rights>, listing the resources that can be accessed by all processes executing within the domain and specifying the operations permitted on each resource Implementations Capabilities Access control lists 12

13 Access Control (cont) Capabilities A binary value acts as an access key allowing the holder access to certain operations on a specified resource An access control check on a service request via only the validation of the capability, no authentication once the capability is obtained Problem: key theft, key retaining or copying Access control lists A list with entries of the form <domain, operations> for each domain that has access to the resource and the operations permitted to the domain A domain is specified by an identifier for a principal or an expression for the membership of the domain, e.g. owner of this file Request is in the form of <op, principal, resource> Credentials It is not convenient for authentication on each operation from a user A credential speaks for a principal E.g. public-key certificate speaks for that user Delegation A form of credential that entitles a principal, or a process acting for a principal, to perform an action with the authority of another principal E.g. printer server It will be wasteful of resources to copy the file, so the file name is passed to the server and it is accessed by the print server on behalf of the user May be achieved using signed certificate of a capability 13

14 Case Study Authentication protocol Needham-Schroeder Kerberos Application-level security protocol TLS (Transport Layer Security) An extension of SSL (Secure Sockets Layer) IEEE WiFi Needham-Schroeder Authentication Protocol To use authentication server for secret keys to clients Nonces are added to messages to avoid replaying attacks Message 3 is a weakness, because an intruder may obtain the key K AB and make a copy of the ticket They may be left in an exposed storage location by a careless or a failed client program running under A s authority 14

15 Figure 7.14 The Needham Schroeder secret-key authentication protocol Header Message Notes 1. A->S: A, B, N A requests S to supply a key for communication A with B. 2. S->A: {N A, B, K AB, S returns a message encrypted in A s secret key, containing a newly generated key K {K AB, A} KB } AB and a KA 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 B - 1} KAB A demonstrates to B that it was the sender of the previous message by returning an agreed transformation of N B. Kerberos An authentication service A and ticket granting service T Need login to access T via A Need to get tickets to access other services via T To avoid a new ticket and session key for each client-server interaction, most tickets are granted to client with a lifetime of several hours Use time as nonces To guard against replaying attacks To enable the system to revoke users authorities Login Login program sends user name to A in plain text A replies with a session key encrypted in user s password and ticket to T Login will prompt user for password (challenge) to obtain the session key The password will be erased from memory, and is never exposed out of login program 15

16 Figure 7.15 System architecture of Kerberos Kerberos Key Distribution Centre Step A 1. Request for TGS ticket Authentication service A Authentication database Ticketgranting service T Client C 2. TGS ticket 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 TLS Negotiable encryption and authentication algorithm In an open network, it is impractical to assume that all parties use the same client software or that all client and server include a particular encryption algorithm Handshake to establish a secure channel Plain text, then public-key and finally secret private-key cryptography The TLS initial handshake is potential vulnerable to man-in-the-middle attacks Instead of plain text message, a set of public keys for some well-known certificate authorities may be used 16

17 Figure 7.16 TLS protocol stack TLS Handshake protocol TLS Change Cipher Spec TLS Alert Protocol HTTP Telnet TLS Record Protocol Transport layer (usually TCP) Network layer (usually IP) TLS protocols: Other protocols: Figure 7.17 TLS handshake protocol 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 Certificate Verify Server Send client certificate response if requested Change Cipher Spec Finished Change cipher suite and finish handshake Change Cipher Spec Finished 17

18 Figure 7.18 TLS handshake configuration options 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) RSA with public-key certificates IDEA SHA Figure 7.19 TLS record protocol Application data abcdefghi Fragment/combine Record protocol units Compress abc def ghi Compressed units MAC Encrypted Hash Encrypt Transmit TCP packet 18

19 IEEE WiFi Security Design Wired Equivalent Privacy (WEP) Access control: by a challenge-response protocol (cf. Kerberos). A single key K is assigned by a network administrator and shared between base station and all authorized devices Privacy and integrity: optional encryption mechanism based on RC4. The same key K is also used in encryption. The key lengths are 40, 64 or 128 bits. An encrypted checksum is included in each packet. Weaknesses in the IEEE WiFi Security Design The sharing of a single key by all users of a network : A public-key based protocol for negotiating individual keys, as TLS Base station are never authenticated Whoever knows the current shared key could introduce a spoof base station : base station should supply certificate that can be authenticated by public key from a third party 19

20 Weaknesses in the IEEE WiFi Security Design, cont. In appropriate use of a stream cipher rather than a block cipher Sender and receiver use RC4 to generate the same key stream to encrypt/decrypt the data RC4 need to be restarted with 24-bit initial value and shared key to avoid stream synchronizations errors when packets are lost or corrupted. The initial value is updated and included in clear in each packet transmitted. Shared key cannot be changed normally; the starting value has only 2 24 or about 10 7 different states. : Negotiate a new key after a time less that the worst case for repetition. Figure 7.20 Use of RC4 stream cipher in IEEE WEP Encryption IV K Increment Decryption IV K RC4 RC4 keystream plaintext XOR cipher text IV cipher text IV XOR plaintext IV: initial value K: shared key 20

21 Weaknesses in the IEEE WiFi Security Design, cont. Key lengths of 40 bits and 64 bits were included in the standard to enable products to be shipped abroad by US suppliers : 128 bits only User often do not deploy the protection : Better default settings and documentation 21