Distributed Systems How does the OS ensure security? 13C. Security - PDF document

5/27/2017 Distributed Systems How does the OS ensure security? 13C. Security for Distributed Systems • all key resources are kept inside of the OS – protected by hardware (mode, memory management) 13I. Secure Sessions – processes cannot access them directly 13D. Distributed Synchronization • all users are authenticated to the OS 13J. Distributed Transactions – by a trusted agent that is (essentially) part of the OS 14A. Remote Data Access Architectures • all access control decisions are made by the OS – the only way to access resources is through the OS – we trust the OS to ensure privacy and proper sharing • what if key resources could not be kept in OS? Distributed Systems - Synchronization and Security 1 Distributed Systems - Synchronization and Security 2 Network Security – things get worse Man-in-the-Middle Attacks • the OS cannot guarantee privacy and integrity • assume someone watching all network traffic – network transactions happen outside of the OS – your traffic is being routed through many machines • authentication – most internet traffic is not encrypted – snooping utilities are widely available – all possible agents may not be in local password file – passwords may be sent in clear text • "man-in-the-middle" attacks • assume someone can forge messages from you – wire connecting the user to the system is insecure – your traffic is being routed through many machines • systems are open to vandalism and espionage – some of them may be owned by bad people – many systems are purposely open to the public – they can hijack connection after you log in – even supposedly private systems may be on internet – they can replay previous messages, forge new ones Distributed Systems - Synchronization and Security 3 Distributed Systems - Synchronization and Security 4 Goals of Network Security Elements of Network Security • simple symmetric encryption • secure conversations – can be used to ensure both privacy and integrity – privacy: only you and your partner know what is said • cryptographic hashes – integrity: nobody can tamper with your messages – powerful tamper detection • positive identification of both parties • public key encryption – authentication of the identity of message sender – basis for modern digital privacy and authentication – assurance that a message is not a replay or forgery • digital signatures and public key certificates – non-repudiation: he cannot claim "I didn't say that" – powerful tools to authenticate a message's sender • they must be assured in an insecure environment • delegated authority – messages are exchanged over public networks – enabling us to trust a stranger's credentials – messages are filtered through private computers Distributed Systems - Synchronization and Security 5 Distributed Systems - Synchronization and Security 6 1

5/27/2017 A Principle of Key Use Practical Public Key Encryption • Both symmetric and PK crypto require secret keys • Public Key Encryption algorithms are expensive – if key gets out, we lose both privacy and authentication – 10x to 100x as expensive as symmetric ones • The more you use a key, the less secure it becomes – key distribution is also complex and expensive • We should use PKE as little as possible – the key stays around in various places longer – there are more opportunities for an attacker to get it – for initial authentication/validation – there is more incentive for attacker to get it – to negotiate/exchange symmetric session keys – given enough time, any key can be brute forced • Communication should use symmetric encryption • Therefore: – use short-lived, disposable, session keys – use a given key as little as possible , change them often – much less expensive to encrypt/decrypt – the longer you keep it, the less you should use it Distributed Systems - Synchronization and Security 7 Distributed Systems - Synchronization and Security 8 Symmetric and Asymmetric Encryption example: Secure Socket Layer • Use asymmetric to start the session • establishes secure two-way communication – e.g. RSA or other Public Key mechanism – privacy – nobody can snoop on conversation – authenticate the parties – integrity – nobody can generate fake messages – securely establish initial session key • certificate based authentication of server • Use symmetric encryption for the session – client knows what server he is talking to – e.g. DES or AES • optional certificate based authentication of client – very efficient algorithm based on negotiated key – if server requires authentication and non-repudiation • Periodically move to new session key • uses PK to negotiate symmetric session keys – e.g. sequence based on initial session key – safety of public key, efficiency of symmetric – e.g. “switch to new key” message Distributed Systems - Synchronization and Security 9 Distributed Systems - Synchronization and Security 10 SSL session establishment Distributed Synchronization • spatial separation CLIENT SERVER algorithm selection, and random string A – different processes run on different systems algorithm selection, and random string B – no shared memory for (atomic instruction) locks server’s Public Key certificate – they are controlled by different operating systems validate server’s certificate • temporal separation generate random string C encrypt C with server’s public key encrypted string C – can’t “totally order” spatially separated events compute F(A,B,C) decrypt C with server’s Private key – before/simultaneous/after lose their meaning use result to generate session keys compute F(A,B,C) • independent modes of failure use result to generate session keys – one partner can die, while others continue subsequent communication encrypted w/symmetric session keys Distributed Systems - Synchronization and Security 11 Distributed Systems - Synchronization and Security 12 2

5/27/2017 Distributed Temporal Separation Distributed Locking - Leases Reader Writer Server Server Writer Reader • Synchronization must be centralized 1 1 1 2 2 2 x=1 x=1 – a single server is responsible for issuing locks x=1 x=1 – traditional mechanisms can ensure atomicity x=2 Different clients see – locks should be managed with message exchanges x=1 x=2 different values at the • Authorization must be distributed same time x=3 – lock servers issue signed “cookies” x=2 x=3 Different clients see x=2 – servers verify cookies before performing requests successive values in x=3 x=2 different orders x=3 • Client failures must be recoverable – locks automatically expire after lease time 1. The system does not have a scalar state. State is a vector. 2. There is no total ordering; There are only partial orderings. – automatic preemption prevents deadlock Distributed Systems - Synchronization and Security 13 Distributed Systems - Synchronization and Security 14 Leases and Enforcement Lock Breaking and Recovery • all requests are exchanged via messages • revoking an expired lease is fairly easy – in general, all resources are on other nodes – lease cookie includes a “good until” time – client does not have direct access to resources – any operation involving a “stale cookie” fails • each request includes a lease “cookie” – from resource manager (possibly signed) • this makes it safe to issue a new lease – identifies client, resource, and lease period – old lease-holder can no longer access object – lease automatically expires at end of period – was object left in a “reasonable” state? • validate cookies before performing operation • object must be restored to last “good” state – requests with stale cookies should be rejected • handles a wide range of failures – roll back to state prior to the aborted lease – process, client node, server node, network – implement all-or-none transactions Distributed Systems - Synchronization and Security 15 Distributed Systems - Synchronization and Security 16 Atomic Transactions Successful Atomic Transaction client • guaranteed uninterrupted, all-or-none execution send startTransaction server • solves multiple-update race conditions – all updates are made part of a transaction send updateOne updateOne • updates are journaled, but not actually made send updateTwo updateTwo – after all updates are made, transaction is committed updateThree send updateThree – otherwise the transaction is aborted • e.g. if client, server, or network fails before the commit send commit • resource manager guarantees “all-or-none” – even if it crashes in the middle of the updates – journal can be replayed during recovery Distributed Systems - Synchronization and Security 17 Distributed Systems - Synchronization and Security 18 3