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

5/20/2018 Distributed Systems How does the OS ensure security? 13C. Distributed Systems: Security • 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 Systems: Synchronization • all users are authenticated to the OS 13J. Distributed Systems: Transactions – by a trusted agent that is (essentially) part of the OS 13E. Distributed Systems: Consensus • all access control decisions are made by the OS 14A: Remote Data Access Services – 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: Issues and Approaches 1 Distributed Systems: Issues and Approaches 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: Issues and Approaches 3 Distributed Systems: Issues and Approaches 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: Issues and Approaches 5 Distributed Systems: Issues and Approaches 6 1

5/20/2018 Practical Public Key Encryption A Principle of Key Use • 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 – the key stays around in various places longer • We should use PKE as little as possible – 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 example: Secure Socket Layer Symmetric and Asymmetric Encryption • 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: Issues and Approaches 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: Issues and Approaches 11 2

5/20/2018 Distributed Temporal Separation Distributed Locking - Leases • Synchronization must be centralized Reader Writer Server Server Writer Reader 1 1 1 2 2 2 x=1 – a single server is responsible for issuing locks x=1 x=1 x=1 – traditional mechanisms can ensure atomicity – locks should be managed with message exchanges x=2 Different clients see • Authorization must be distributed x=1 x=2 different values at the same time x=3 – lock servers issue signed “cookies” x=2 x=3 – servers verify cookies before performing requests Different clients see x=2 successive values in x=3 • Client failures must be recoverable x=2 different orders x=3 – locks automatically expire after lease time 1. The system does not have a scalar state. State is a vector. – automatic preemption prevents deadlock 2. There is no total ordering; There are only partial orderings. 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 • each request includes a lease “cookie” – any operation involving a “stale cookie” fails – 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 – requests with stale cookies should be rejected • object must be restored to last “good” state • 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 Successful Atomic Transaction Atomic Transactions 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 3