Distributed Systems

1. Distributed Systems Topic 7: Security Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong

2. Outline 1 Motivation 2 Styles of Attacks 3 Cryptography 4 Authentication 5 Security Systems 6 CORBA Security Service 7 Summary

3. 1 Motivation • More vital/secret data handled by distributed components. • Security: protecting data stored in and transferred between distributed components from unauthorised access. • Security is a non-functional requirement that cannot be added as a component but has to be built into all components.

4. 1 Why are Distributed Systems insecure? • Distributed component rely on messages sent and received from network. • Is network (especially WANs and wireless networks) secure? • Is client component secure? • Is client component who it claims to be? • Are users of calling components really who they claim to be?

5. 1 Effects of Insecurity • Confidential Data may be stolen, e.g.: • corporate plans. • new product designs. • medical/financial records (e.g. Access bills....). • Data may be altered, e.g.: • finances made to seem better than they are. • results of tests, e.g. on drugs, altered. • examination results amended (up or down).

6. 1 Need for Security • Loss of confidence: above effects may reduce confidence in computerized systems. • Claims for damages: legal developments may allow someone to sue if data on computer has not been guarded according to best practice. • Loss of privacy: data legally stored on a computer may well be private to the person concerned (e.g. medical/personnel) record.

7. 2 Threats • Categorization of attacks (and goals of attacks) that may be made on system. • Three broad classes: • leakage: information leaving system. • tampering: unauthorised information altering. • vandalism: disturbing correct system operation. • Used to specify what the system is proof, or secure, against.

8. 2 Methods of Attack • Eavesdropping: Obtaining message copies without authority. • Masquerading: Using identity of another principal without authority. • Message tampering: Intercepting and altering messages. • Replaying: Storing messages and sending them later. • Denial of service: Flooding server resources with messages in order to deny other’s access.

9. 2 Some Security Attack Scenarios Eavesdropping: Mary Peter “Let’s meet at 5pm, old place” Tom “hee hee…” Tampering: “Let’s meet at 5pm, old place” Peter Mary Tom “Let’s meet at 3pm, old place” Replaying: Peter Mary “Let’s meet at 5pm today” One day later: “Let’s meet at 5pm today” Tom

10. 2 Infiltration • Launch of attack requires access to the system. • Launched by legitimate users. • Launched after obtaining passwords of known users. • Subtle ways of infiltration: • Viruses • Worms • Trojan horses.

11. 3 Cryptography 1 Introduction 2 Terminology 3 Encryption 4 Secret Keys 5 Public Keys 6 RSA Encryption Algorithm

12. 3.1 Introduction • Cryptography: encode message data so that it can only be understood by intended recipient. • Romans used it in military communication. • Given knowledge of encryption algorithm, a brute force attempt: try every possible decoding until a valid message is produced. • Computers are good at this! • Modern schemes must be computationally hard to solve to remain secure.

13. 3.2 Cryptographic Terminology • Plain text: the message before encoding. • Cipher text: the message after encoding. • Key: information needed to convert from plain text to cipher text (or vice-versa). • Function: the encryption or decryption algorithm used, in conjunction with key, to encode or decode message. • Key distribution service: trusted service which hands out keys.

14. 3.3 Encryption • Encrypting data prevents unauthorised access to the data (i.e. prevents eavesdropping). • If encrypted data can only be encrypted with a matching key, this can be used to prove sender’s identity (i.e. prevents masquerading). • Likewise, it can be used to ensure that only intended recipients can use the data. • Two main ways: secret key and public key.

15. 3.4 Secret Keys • One key is used to both encrypt and decrypt data • Encryption and decryption functions are often chosen to be the same type • Security should not be compromised by making function well-known as security comes from secret keys

16. 3.4 Using Secret Keys • Sender and recipient exchange keys through some secure, trusted, non-network based means. • Sender encodes message using encryption function and sends the message, knowing that only the holder of key (the intended recipient) can make sense of it. • Recipient decodes message, and knows that only intended sender could generate it. • Message can be captured but is of no use.

17. 3.5 Public Keys • Gives 'one-way' security. • Two keys generated, one used with decryption algorithm (private key) and one with encryption algorithm (public key). • Generation of the private key, given only the public key, is computationally hard. • Do not need secure key transmission mechanism for key distribution.

18. 3.5 Using Public Keys • Recipient generates key pair. • Public key is published by trusted service. • Sender gets public key, and uses this to encode a message. • Recipient decodes the message. • Replies can be encoded using sender’s public key from the trusted distribution service if two-way security is needed. • Message can be captured but is of no use.

19. 3.6 RSA Encryption Algorithm • Named after the three inventors • Ron Rivest • Adi Shamir • Leonard Adleman • A common and well-known Public-key algorithm

20. 3.6 Methods used in RSA • Choose a pair of large prime number (p and q) • Calculate n = p * q • Find an encryption key (e) such that e and (p-1)(q-1) are relatively prime. • Then decryption key (d) will be obtained by the formula 1 = e*d mod (p-1)(q-1) • ed = 1 mod (p-1)(q-1) • d = e-1 mod (p-1)(q-1)

21. 3.6 RSA Encryption/Decryption Key • (e, n) will be the encryption key available to public: ci = mie mod n • (d, n) will be the decryption key owners keeps private: mi = cid mod n • The decryption holds because cid = (mie)d = mied = mik(p-1)(q-1)+1 = mimik(p-1)(q-1) = mi*1 = mi; all (mod n)

22. 4 Authentication 1 Motivation 2 Types of Authentication 3 Needham/Schroeder Protocol

23. 4.1 What is Authentication? Authentication: Proving you are who you claim to be. • In centralized systems: Password check at session start. • In distributed systems: • Ensuring that each message came from claimed source. • Ensuring that each message has not been altered. • Ensuring that each message has not been replayed.

24. 4.2 Types of Authentication • Authentication can be used to ensure a number of different aspects of an interaction. • Proving that a client of a server is who it claims to be. • This can be refined to proving that the end user has the right to use a service.

25. 4.2 Types of Authentication • Proving both client and server are who they say they are. • This is needed to prevent impostor services from collecting information or disrupting (vandalizing) the system. • This is really just an extension of the idea of authentication a client.

26. 4.2 Types of Authentication • Securing communication from eavesdropping. • Authentication will usually involve encrypting data. • This can be used just at the start to prove the identity of ends of the communication link.

27. 4.3 Needham/Schroeder Protocol • Provides a secure way for pairs of components to obtain keys to be used during communication. • Based on an authentication server: • maintains a name and a secret key for each component. • can generate keys for peer-to-peer communications. • Secret keys are used for communication with authentication server.

28. Authentication Server 1: C, S, NC 2: {NC,S,KCS,{KCS,C}KS}KC C: Client Name S: Server Name KC: Client´s secret key KS: Server´s secret key KCS: Secret key for client/server communication Nx: Nonce generated by x {M}K: Message encrypted in key K 3: {KCS,C}KS C S 4: {NS}KCS 5: {NS-1}KCS 4.3 Needham/Schroeder Protocol

29. 5.1 Security Systems: Kerberos • Based on Needham/Schroeder Protocol. • Developed by Steiner at MIT (1988). • Used in • OSF/DCE. • Unix NFS.

30. Kerberos Key Distribution Centre Authentication database Step A Ticket- Authen- granting tication 1. Request for service T service A TGS ticket 2. TGS ticket Step B 3. Request for server ticket Login Step C 4. Server ticket session setup 5. Service Server request Service Client session setup Server function C Request encrypted with session key S DoOperation Reply encrypted with session key 5.1 System architecture of Kerberos

31. 5.2 Security Systems: CORBA Supports the following security algorithms: • Authentication of users. • Authentication between objects. • Authorisation and access control. • Security auditing. • Non-repudiation. • Administration of security information. Cryptography is not exposed at interfaces.

32. 5.2 CORBA Security Architecture • The security model: Server User Client requests Message protection, access control device, etc. ORB Message protection, access control device, etc. Security Implementation enforcing security policy • All object invocations are mediated by the security implementation • No specific security policy defined in the model, so that a wide variety of different policies can be defined according to different needs

33. 5.2 CORBA Security • Principals • Human users or system entities (e.g., the client acting for a user) registered in and authenticated to the system • Credentials • Each principal in a CORBA environment with Security Service is associated with credentials • Credentials contain security attributes of an object, e.g., its identity and privileges (like gate-passes) • Credentials are used for access controls, authentication, etc. • An object may have several credentials, representing privileges in different domains

34. 5.2 CORBA Security • Delegation • Passing of credentials from one object to another, so that the receiving object (intermediate) can invoke a third object (target) on behalf of the passing object (invoker) • Options of delegation: • no delegation • simple delegation • composite delegation • combined delegation • traced delegation invoker Client credentials intermediate Client credentials / intermediate credentials / mixed, according to different options target

35. 5.2 CORBA Security • Non-repudiation service • provide services that make users / principals accountable for their actions • Implementation: SSL services come with Orbix; separate purchase for Visibroker Object A Object B Dispute/judgement Adjudicator Non-repudiation service Evidence generation & verification Evidence storage & retrieval Delivery Authority Service requests / responses

36. 6 Summary • Threats, Methods of Attack, Infiltration • Cryptology: • Secret Keys • Public Keys • Authentication: Needham/Schroeder Protocol • Systems: • Kerberos • CORBA