1 / 36

Distributed Systems

Distributed Systems. Topic 7: Security Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong. Outline. 1 Motivation 2 Styles of Attacks 3 Cryptography 4 Authentication 5 Security Systems 6 CORBA Security Service 7 Summary. 1 Motivation.

aretha-knox
Download Presentation

Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related