Security and Reliability Issues in Distributed Systems

1. Security and Reliability Issues in Distributed Systems Chan Hing Wing, Anthony MPhil Term 1, CSE CUHK December 11, 1998

2. Presentation Outline • Introduction • Distributed system security • Common requirements and approaches • The SSL protocol • CORBA Security • Distributed system reliability • Common requirements and approaches • Summary • Questions and Answers

3. Introduction • Distributed systems developed rapidly over the past two decades • E.g., WWW, automatic teller machines, distant learning • As distributed systems become widely used, their security and reliability becomes very important • Distributed Systems: hardware (autonomous computers, the linking network) and software (distributed system software)  Security and Reliability both have hardware aspect and software aspect

4. Distributed System Security Hardware Vs Software: • Hardware security: keys, locks, cards, visitor monitoring, etc. (not main focus) • Software security: (in terms of user requirements) • integrity: message transmitted over network must be identical to the original • confidentiality: message transmitted must not be readable to unintended entities • availability: the system must not be unavailable due to security attacks • accountability: user actions that is security-critical must be traceable

5. Common Approaches • Cryptography encryption Data Secret-form data decryption • The secret-form data must be unreadable without prior knowledge of a secret / key (confidentiality), but recoverable with knowledge of the secret (availability) • Usually the secret-form data cannot be decrypted successfully if it is tampered it can be used to ensure the integrity of data, (e.g., message authentication codes (MACs), digital signatures)

6. Common Approaches • Cryptography (cont’d) • Secret-key cryptography: the same key is used in encryption and decryption, e.g., DES, block/stream ciphers, MACs • Public-key cryptography: different keys are used, e.g., RSA, digital signatures • Public keys (PK) Vs Secret keys (SK) • PK do not require distribution of shared secret  more convenient for distributed systems • PK rely heavily on the computational unfeasibility to solve some hard problems (e.g., factoring, travelling salesman)  breakable if these problems were solved

7. Common Approaches • Authentication • the process of verifying a claimed identity • the entity to be authenticated may be a person (e.g., in password checking), a message (i.e., integrity) or a program (e.g., client/server authentication) • usually make use of cryptography, in which a secret (key) of the entity of the owner of it is used to verify its identity • authentication protocols • ways for two components in a DS to ensure each other is the intended entity • usually by negotiating a short-term key for communication (e.g., Needham/Schroeder)

8. Common Approaches • Authorization / Access Control • the process of granting suitable rights to legitimate users • usually by means of access control lists (ACLs) (e.g., permissions in UNIX NFS) • Logging • logging security-critical activities of users (e.g., “su” logs in UNIX), so that any internal security attacks can be accounted for

9. The SSL protocol • Secure Socket Layer, by Netscape • Provides security for applications over the insecure Internet • Overview: Application 2 Application 1 (e.g., telnet, ftp) Application data protocol Application data protocol SSL handshake protocol SSL handshake protocol SSL record protocol SSL record protocol Reliable transport protocol (e.g., TCP)

10. The SSL Protocol -The Three Components • Record protocol • encapsulate higher level protocols • divide messages into blocks • compresses message blocks • applies MAC to message blocks • encrypts and transmits message blocks • SSL handshake protocol • allow the client to authenticate the server, and the server to authenticate the client • negotiate an encryption algorithm and key for application data transmission • Application data protocol • transmits data from applications to the record layer, which then sends the data securely

11. The SSL Handshake Protocol • An authentication protocol • A sample session: “Hello! I want to connect with you. I understand encryption algorithms like DES, RC4, IDEA, etc.…” CLIENT SERVER “Hello, then let’s use DES. This is my certificate. Please check. Please also send yours.” (Client authenticate server by verifying server’s certificate...) “Alright, here is my certificate, and I’ve generated a DES master key. Here I encrypt it with your public key and send it to you I’m finished..” (Server authenticate client by verifying client’s certificate...) (Server decrypts the DES key received from client…) Ok, I received your key. I’m finished. Data encrypted with the DES master key . . .

12. The SSL Protocol - Implementation • SSLeay • A commonly used implementation of the SSL protocol (2.0 and 3.0) • Written by Eric Young in Australia • Contains library functions for making SSL communications (e.g., SSL_connect, SSL_free, SSL_get_certificate, SSL_get_cipher) • Includes many encryption algorithms: • ciphers (e.g., DES, RC4, RC2, IDEA) • digests (MD5, MD4, SHA-1) • public keys (RSA, DSA, Diffie-Hellman) • Applications built on top of SSLeay: SSLtelnet, SSLftp, SSLhttpd, etc., by Tim Hudson in Australia • Patches (< 100 K size) to some existing server and client programs that support SSLeay

13. CORBA Security • Security is provided as a kind of CORBA services (not part of the core ORB) • Two levels of security defined: • level 1: does not change IDL definition; applications are unaware of the security mechanism. Users may be authenticated before calling an application, and then security is enforced automatically during object invocation • level 2: new IDL definition introduced; applications can make use of objects such as credentials and Principal-Authenticators to define their own security policies

14. CORBA Security • 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

15. CORBA Security • Principals • Human users or system entities (e.g., the client acting for a user) registered in and authentic 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

16. CORBA Security invoker • 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 Client credentials intermediate Client credentials / intermediate credentials / mixed, according to different options targe

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

18. Distributed System Reliability • Reliability: broad meaning (dependability): • security • availability • fault tolerance • recoverability • correctness • consistency • timeliness

19. Reliability • A narrower definition (J. Stankovic): • Fault: a mechanical or algorithmic defect which may generate an error • Error: an item of information which will produce a failure • Failure: an event at which a system violates its specifications Reliability: the degree of tolerance against errors and faults

20. Reliability Hardware Vs Software: • Hardware reliability • hardware redundancy, high-quality IC, wires, UPS, etc. (not main focus) • Software reliability • fault tolerance • error recovery • data / code redundancy

21. Common Approaches • Replication • keeping > 1 copies of data / programs in system, increase availability • Fault masking: • masking out the effects of faults by data / program redundancy in replicas • Majority voting: • process requests on different servers, and produce the most possible results by voting on results from different servers • Crash recovery • E.g., by logging, checkpointing

22. Common Approaches • Reliable transmission protocols • protocols with error detection, correction e.g., TCP/IP • Concurrency control • locking • ordering

23. Summary • Security requirements and approaches in distributed systems • The SSL protocol • CORBA Security Service • Reliability requirements and approaches in distributed systems

24. Next Steps • Know more about distributed system reliability • Study the CORBA Security Service specification; investigate existing implementations of the spec. • Probably implement a system that demonstrates security & reliability in the CORBA environment

25. The End Questions and Answers session