CS162 Operating Systems and Systems Programming Lecture 26 Protection and Security II ManyCore Operating Systems December 2nd 2009 Prof John Kubiatowicz http inst eecs berkeley edu cs162 Review Use of Hash Functions Several Standard Hash Functions MD5 128 bit output SHA 1 160 bit output SHA 256 256 bit output Can we use hashing to securely reduce load on server Yes Use a series of insecure mirror servers caches First ask server for digest of desired file Use secure channel with server Then ask mirror server for file Can be insecure channel File X Insecure Check digest of result and catch faulty or malicious Read X Data mirrors File X Mirror File X Read File X Here is hx H X 12 02 09 Client Kubiatowicz CS162 UCB Fall 2009 Server Lec 26 2 Review Public Key Encryption Details Idea Kpublic can be made public keep Kprivate private Insecure Channel Bpublic Aprivate Alice Bprivate Apublic Insecure Channel Bob Gives message privacy restricted receiver Public keys can be acquired by anyone used by anyone Only person with private key can decrypt message What about authentication Alice Bob I m Alice Aprivate Rest of message Bpublic Provides restricted sender and receiver Suppose we want X to sign message M Use private key to encrypt the digest i e H M Xprivate Send both M and its signature M H M Xprivate Now anyone can verify that M was signed by X 12 02 09 Simply decrypt the digest Kubiatowicz CS162 with UCBX Fall 2009 public Lec 26 3 Goals for Today Use of Cryptographic Mechanisms Distributed Authorization Remote Storage Worms and Viruses ManyCore operating systems Note Some slides and or pictures in the following are adapted from slides 2005 Silberschatz Galvin and Gagne Also slides on Taint Tracking adapted from Nickolai 12 02 09 Kubiatowicz CS162 UCB Fall 2009 Lec 26 4 Zeldovich Recall Authorization Who Can Do What How do we decide who is authorized to do actions in the system Access Control Matrix contains all permissions in the system Resources across top Files Devices etc Domains in columns A domain might be a user or a group of permissions E g above User D3 can read F2 or execute F3 In practice table would be huge and sparse Two approaches to implementation Access Control Lists store permissions with each object Still might be lots of users UNIX limits each file to r w x for owner group world More recent systems allow definition of groups of users and permissions for each group Capability List each process tracks objects has permission to touch Popular in the past idea out of favor today Consider page table Each process has list of pages it has access to not each page has list of processes 12 02 09 Kubiatowicz CS162 UCB Fall 2009 Lec 26 5 How to perform Authorization for Distributed Systems Different Authorization Domains Issues Are all user names in world unique No They only have small number of characters kubi mit edu kubitron lcs mit edu kubitron cs berkeley edu However someone thought their friend was kubi mit edu and I got very private email intended for someone else Need something better more unique to identify person Suppose want to connect with any server at any time Need an account on every machine possibly with different user name for each account OR Need to use something more universal as identity Public Keys Called Principles People are their public keys 12 02 09 Kubiatowicz CS162 UCB Fall 2009 Lec 26 6 Distributed Access Control File File X X Access Control List ACL for X l Kc C A 9 X BC er D d rv e 7 Client 1 Ks ea 6 4 R Domain 1 x6 ta a 0 d y Ke RX Group Key 0xA2D3498672 GACL Server 1 Domain 2 nt ie ACL verifier Hash Timestamp R Key 0x546DFEFA34 Signature owner RW Key 0x467D34EF83 Read Group Owner Owner Key Key 0x22347EF 0x22347EF Group ACL GACL verifier Hash Timestamp Key 0xA786EF889A Signature group Key 0x6647DBC9AC Server 2 Domain 3 Distributed Access Control List ACL Contains list of attributes Read Write Execute etc with attached identities Here we show public keys ACLs signed by owner of file only changeable by owner Group lists signed by group key ACLs can be on different servers than data Signatures allow us to validate them ACLs could even be stored separately from verifiers 12 02 09 Kubiatowicz CS162 UCB Fall 2009 Lec 26 7 Analysis of Previous Scheme Positive Points Identities checked via signatures and public keys Client can t generate request for data unless they have private key to go with their public identity Server won t use ACLs not properly signed by owner of file No problems with multiple domains since identities designed to be cross domain public keys domain neutral Revocation What if someone steals your private key Need to walk through all ACLs with your key and change This is very expensive Better to have unique string identifying you that people place into ACLs Then ask Certificate Authority to give you a certificate matching unique string to your current public key Client Request request unique ID Cprivate give server certificate if they ask for it Key compromise must distribute certificate revocation since can t wait for previous certificate to expire What if you remove someone from ACL of a given file If server caches old ACL then person retains access Here cache inconsistency leads to security violations 12 02 09 Kubiatowicz CS162 UCB Fall 2009 Lec 26 8 Analysis Continued Who signs the data Or How does client know they are getting valid data Signed by server What if server compromised Should client trust server Signed by owner of file Better but now only owner can update file Pretty inconvenient Signed by group of servers that accepted latest update If must have signatures from all servers Safe but one bad server can prevent update from happening Instead ask for a threshold number of signatures Byzantine agreement can help here How do you know that data is up to date Valid signature only means data is valid older version Freshness attack Malicious server returns old data instead of recent data Problem with both ACLs and data E g you just got a raise but enemy breaks into a server and prevents payroll from seeing latest version of update Hard problem Needs to be fixed by invalidating old copies or having a trusted group of servers Byzantine Agrement 12 02 09 Kubiatowicz CS162 UCB Fall 2009 Lec 26 9 Administrivia Final Exam Thursday 12 17 8 00AM 11 00AM 105 Stanley Hall All material from the course With slightly more focus on second half but you are still responsible for all the material Two sheets of notes both sides Will need dumb
View Full Document
Unlocking...