1 / 41

Distributed Systems

Distributed Systems. Session 10: Security Christos Kloukinas Dept. of Computing City University London. Session 10 - Outline. 1 Motivation 2 Styles of Attacks 3 Cryptography 4 Authentication 5 Security Systems 6 Summary. Security in Distributed Systems. Non-Repudiation. Auditing.

ianthe
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 Session 10: Security Christos Kloukinas Dept. of Computing City University London

  2. Session 10 - Outline 1 Motivation 2 Styles of Attacks 3 Cryptography 4 Authentication 5 Security Systems 6 Summary

  3. Security in Distributed Systems Non-Repudiation Auditing High Level Authentication Access Control ENCRYPTION Low Level E.g. Consider online Bank Example

  4. 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.

  5. 1 Why are Distributed Systems insecure? • Distributed component rely on messages sent and received from network. • Is network (especially WAN networks) secure? • Packets can be intercepted and modified at network layer! • Is client component secure? • Is client component who it claims to be? • Are users of calling components really who they claim to be?

  6. 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).

  7. 1 Need for Security • Loss of confidence: above effects may reduce confidence in computerised 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.

  8. 2 Threats • Categorisation of attacks (and goals of attacks) that may be made on system. • Four main areas: • leakage: information leaving system. • tampering: unauthorised information altering. • resourcestealing: illegal use of resources. • vandalism: disturbing correct system operation. • denialofservice: disrupting legitimate system use. • Used to specify what the system is secure against.

  9. 2 Threats • Leakagedenotes the disclosureof information to unauthorised subjects. • Baazi hacking into a CAD System of Rolls Royce in order to obtain the latest design RR's jet engines. • Although fatal in this case, leakage is probably the category that causes the least damage of the above. • Tampering denotes the unauthorised modification of data. • We would have a case of tampering, if you hacked into the School's database in order to alter the marks of your Distributed System courseworks

  10. 2 Threats (ctd.) • Resource stealing identifies the illegal use of resources and not paying, e.g CPU time, Bandwith, Air time of mobiles • A case of resource stealing has occurred when hackers hacked into computers of telephone companies and managed to have their phone calls charged to other customer's accounts. • Vandalism denotes the disturbance of correct system operation. • The security of CS Dept. in Milan was broken and super user privileges were acquired and then the system's hard disks were formatted. This caused serious damage to the departmental operations for a session.

  11. 2 Methods of Attack • Eavesdropping: Obtaining message copies without authority. • Masquerading (Spoofing): Using identity of another principle without authority. • Message tampering: Intercepting and altering messages. • Replaying: Storing messages and sending them later. • Flooding: sending too many messages

  12. Message Example ->balance ->Credit(...) Msg in XDR Stub MessageType requestID IIOP ObjectRef Method ORB Arguments

  13. Some Examples • Eavesdropping • request parameters from client to server may contain sensitive information, e.g pins, balances • Stubs marshal these into standard data representation • By listening to or sniffing traffic attackers can obtain and decode request parameters-->eavesdropping • Tampering • Attacker modifies request parameters before they reach server, e.g credit amount • Replaying • Attacker intercepts and stores message and has server repeatedly execute operation • NB: no need to interpret messages, so encryption doesn’t help!

  14. 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 • Trojan horses.

  15. 3 Cryptography 1 Terminology 2 Modern cryptography: Symmetric encryption 3 Modern cryptography: Asymmetric encryption and PGP

  16. 3.1 Cryptographic Terminology • Plaintext: the message before encryption. • Ciphertext: the message after encryption. • 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 encrypt or decrypt message. • Key distribution: How to distribute keys between senders and receivers

  17. 3.2 Requirements for modern cryptography • Kerkhoff’s principle: knowledge of encryption algorithm should not be an advantage • With computers a brute force attempt is possible, i.e. try every possible substitution until a valid message is produced. • Computers are good at this, modern schemes must be computationally hard to solve to remain secure. • 15 May 1973 American National Bureau of standards requests proposals for encryption standard • Data Encryption Standard, DES, developed. Standard describes DEA, Data Encryption Algorithm • DEA is an improvement of IBM’s 1970 Lucifer algorithm • Since November 26, 2001, there’s AES, based on Rijndael

  18. 3.2 DES/AES: SymmetricEncryption • One key is used to both encrypt and decrypt data • Encryption and decryption functions are often chosen to be the same • Security should not be compromised by making function well-known as security comes from secret keys

  19. 3.2 DES/AES: Using Secret Keys • Sender and recipient exchange keys through some secure, trusted, non-network based means. • Sender encodes message using function and sends, knowing that only the holder of the key (the intended recipient) can make sense of it. • Recipient decodes message & knows that only a key-holding sender could have generated it. • Message can be captured but is of no use.

  20. Secret Key Encryption for Distributed Objects Client A Server B Caller Called Skeleton Stub 1.acquire KAB 2.f(KAB, M) --> {M}KAB {M}KAB 1.acquire KAB 3. send() 2. receive() -1 3.f (KAB, {M}KAB) --> M Figure also suggests how to deploy

  21. Secret Key Encryption for Distributed Objects • Encryption is done after marshalling (before un-marshalling) and it has been noted that the server object is not local. • Encrypted object request that is transmitted via network is secured against eavesdropping and message tampering • Note that the encryption can be kept entirely transparent for client and server programmers, as it is done by middleware or by the stubs created by middleware • NB: Disadvantage: For Secret Key encryption for distributed objects, number of keys needed increases quadratically by number of objects(one key per pair of communicating objects…) • Public Key (aka Asymmetric) Encryption overcomes this problem

  22. 3.3 Asymmetric Encryption • Gives 'one-way' security. • Two keys generated, one used with decryption algorithm (private key) and one with encryption algorithm (public key). • Generation of private key, given public key is computationally hard. • Does not need secure key transmission mechanism for key distribution.

  23. 3.3 Asymmetric Encryption: Using Public Keys • Recipient generates key pair. • Public key is published by trusted service. • Sender gets public key, and uses it to encode message. • Recipient decrypts message with its private key. • Replies can be encoded using sender’s public key from the trusted distribution service. • Message can be captured but is of no use.

  24. Sender Recipient Message Message Public key of recipient Private key of recipient Encrypted Message Encrypted Message 3.3 Asymmetric Encryption: Sending a msg securely transmit

  25. Sender Recipient Message Message Private key of sender Public key of sender Encrypted Message Encrypted Message 3.3 Asymmetric Encryption: Signing a msg Asymmetric encryption is very versatile: Besides secure transmission, it can be used to sign messages. Question: How to sign a message and send it securely? transmit

  26. 3.3 Asymmetric Encryption with RSA: How does it work? • Rivest, Shamir, Adleman (Boston, Aug 77) develop the RSA algorithm • We need a one-way function (e.g “Yx mod P”) with trap door • Solution: • Private key: p,q (both large prime numbers), Public key: N = p q and e • Encryption: C = Me mod N • Decryption: Calculate d such that e d = 1 mod (p-1)(q-1) then M=Cd mod N • Can it be attacked: No!!! • as the power in modular arithmetic is a one-way function • computing p,q from N does not work as prime factorisations is another one-way function (and it’s believed to be computationally hard to factor a number – but nobody has proved that it’s NP… :-()

  27. Public Key Encryption for Distributed Objects Caller Called Skeleton Stub 1.acquire KPB 1.generate KPB, KSB 2.f(KPB, M) --> {M}KPB {M}KAB 1.publish KPB 3. send() 2. receive() 3. g(KSB, {M}KPB) --> M

  28. Public Key Encryption for Distributed Objects • Transmission of message is secure • as only B has the matching private key to decrypt message • For decryption: • Apply function g to private key and encrypted message. • Differences between public and secret key • One pair of keys generated for every object, so number of keys is linear to number of objects • Because different functions, f and g • use of public of public keys is more complicated for reply messages. A must generate pair of keys and publish its public key, which B acquires to encrypt reply message

  29. 3.3 DES, RSA and PGP – some history • Both DES and RSA were independently discovered in 1975 by Ellis,Cocks and Williamson in top secret Government communication HQ in UK • DES and RSA not available to the public (classified as weapons!) • In the 80s Zimmermann implements PGP (pretty good privacy) as freeware! • And gets to meet some nice fellows from the FBI…

  30. 3.3 Pretty Good Privacy • Public Key encryption used in PGP • Generally available, and can be used for • encryption of messages • digital signatures. • PGP combines DES and RSA • DES fast, but symmetric, hence key distribution problem • RSA slower, but no key distribution problem • Solution: Use RSA to encrypt and distribute key for DES encryption!!!

  31. Hybrid: Secure Layer (SSL) Protocol • Uses RSA encryption • SSL/TLS Client • generates a secret key for one session, that key is encrypted using server’s public key • Server’s Pub key: in server’s certificate • Client can validate certificate with cert. authority • Session key then forwarded to the server and used for further communication between clients and server • Most O-O middleware use SSL rather than straight TCP as transport protocol, to prevent eavesdropping and tampering of object request traffic

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

  33. 4.1 What is Authentication? Authentication: Proving you are who you claim to be. • In centralised 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.

  34. 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.

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

  36. 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 the two ends of the communication link.

  37. 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 server.

  38. 4.3 Needham/Schroeder Protocol Assumptions: • AS is a trusted authority Authentication Server,AS • C & S’s identity registered with AS • AS and object share secret key for mutual communication 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: NEW 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

  39. 5 Security Systems: Kerberos • Kerberos is a network authentication protocol • allow users and services to authenticate themselves to each other • Based on Needham/Schroeder Protocol. • Developed by Steiner at MIT (1988). • Used in • OSF/DCE.(OSF Distributed Computing Environment ) • Unix NFS. • An adapted version of it is used in Microsoft Windows

  40. 5 Security Systems: CORBA Supports the following security functionality: • Authentication of users. • Authentication between objects. • Authorisation and access control. • Security auditing. • Non-repudiation. • Administration of security information. Cryptography is not exposed at interfaces - The OMG has taken explicit care to avoid exposing keys and any other confidential knowledge within the specs. This was done to avoid that the CORBA security specification would be classified by the US Government as a weapon & as such be unavailable for use outside the US.

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

More Related