Download Study Guide of Operating System Security - Lecture Notes | EECS 482 and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!
EECS 482: Operating Systems Lecture NotesDepartment of EECS, University of Michigan
Professor Atul Prakash
OS Security
We looked at few aspects of operating systems security already.
•^
Isolating processes from each other
-^ Separation between users and OS Basic aspects of security
•^
Authentication
: proving who you are or verifying a service’s identity
•^
Access control
: controlling what a user is allowed to do, once
authenticated
-^ Some other aspects
o^
Confidentiality
: may want to exchange or store data securely
o^ Integrity
: may want to ensure that any tampering of data is detected o^ Availability
: preventing denial-of-service attacks
•^
Threat model:
When designing a security solution, you generally have to
assume something about capabilities of the adversary. You design asystem to be secure against what you believe to be reasonable resourcesfor an attacker.E.g., your house is secure when locked provided the adversary does not have the key or is able to replicate the key.
Additional assumptions may be required here.
Authentication:
•^
Passwords on accounts on operating systems. o^ Why needed? What is the threat model that passwords handle? o^ Who verifies whom?
-^ ATM card or debit card + PIN o^ Is this better than a password in some way? -^ Biometrics: fingerprint scans, iris scans. o^ How does compare with passwords? With ATM + PIN?
What if the user wishes to authenticate over a network? One solution:
•^
Simulate a terminal over the network o^ telnet User ID, password sent over TCPRemote OS login server sends accept or reject.
•^
Encrypt(cleartext, e-key) = ciphertext
-^ Decrypt(ciphertext, d-key) = cleartext For the above to work, the e-key and d-key are chosen so that the aboveare inverses of each other
Decrypt(Encrypt(cleartext, e-key), d-key) = cleartext Some necessary properties:
•^
Given ciphertext, must not be able to determine d-key
-^ Given (cleartext, ciphertext), must not be able to determine thekeys. (Attacker may be able to obtain samples of both cleartext andciphertext in some cases. How?) •^ Given multiple ciphertexts, one must not be able to figure outanything about corresponding plaintexts. Bad encryption function:
•^
Ceaser cipher (e.g., Rot13) o^ Easy to determine from ciphertext and plaintext pair
-^
XOR
o^ Why?
Good encryption functions:
•^
Generate “random-looking” output from cleartext
-^ Even one bit change in cleartext generates an uncorrelated output Symmetric encryption
•^
d-key and e-key are the same. The sender and the receiver share a common key. The key can be used
for both encryption and decryption.Think of a symmetric key as the key to a box. It can be used to bothopen and close a box.Using symmetric encryption: sender and receiver share a common key.No one else has the key. •^ Ann can send a message to Bob after encrypting it, putting it on aCD, and send it through an untrusted courier (Eve). Guaranteesprovided: o^ Confidentiality: Eve does not have the key. Can’t decryptit. o^ Authentication: Bob knows the message from Ann if itdecrypts “properly” Attacks on the above protocol:
o^ Suppose I want to send you your grade securely.
^
Encrypt(“A”, your-key) o^ What can Eve (an eavesdropper) do?
^
With reasonable assumptions, he can’t read o^ Can he modify the message?
^
Sure. ^ But then you will get jibberish (hopefully) onreceipt. o^ How will you know with confidence that the message istampered with?
^
You could try to interpret the message. E.g., gradesare A-E. Decrypting to anything else meanstampering. ^ But what if this data is binary (e.g., data block for afile system)? We want more robust and general-purpose mechanisms.
•^
Detecting modifications using checksums:
Let’s revisit the secure login problem between the client and a machine:
•^
Client needs to provide his user-id and password securely to thelogin service on the machine.
-^ What key do the client and the server use? -^ Simplest thing: o^ Use the password as the key.(Technically, key is “derived” from the password becausethe password may not be the right length to be used as akey directly). -^ What sequence number does the client use? o^ How about zero? Is that secure? Ann -> Server: userid, Encrypt(userid |wish to login | 0, key) o^ What about n+1, where n is the sequence number used atprevious login? -^ More general solution is to use
nonces
(numbers that used only
once). Any reuse of a nonce is detected. E.g. attempt,Ann -> Server: This is Ann, I wish to login, nonce1Server -> Ann: Hi Ann, prove your identity, nonce2Ann -> Server: Ann, Encrypt(Ann, nonce1, nonce2, key)Server -> Ann: Success, Encrypt(nonce1+1, key)
Server is confident that the Ann’s second message is fresh becauseit encrypts nonce2.Ann is confident that the server’s second message is fresh becauseit encrypts nonce1.For the above to work, nonce1 and nonce2 should be eithersequence numbers (non-repeating) or random values from a largespace. Otherwise, the attacker could save lots of sessions and findways to replay an old session that used the same nonces.Usually, the goal of authentication is to establish a “session key”that is used for encrypting further exchanges. The final messagefrom Server to Ann could contain a session key. The session keyshould be a randomly generated key so that it is hard to guess foran attacker.(They could continue to use the password as the session key, butgenerally, it is a bad idea to use the same key too often).
Project 3 protocol: It is a very simple protocol.
•^
password used as a key for all exchanges
-^ Replays within a session are prevented because of per-sessionsequence numbers -^ Different clients distinguished using session numbers -^ Session number+sequence number are like a nonce
^
any reuse is
detected by the server.
The keys must be related of course for them to work as matchingencryption/decryption keys.This will be logically similar to symmetric key encryption if one key could beeasily derived from the other.
•^
Possession of e-key would imply that you could get the d-key, and vice-versa. In a public-key cryptosystem, a pair (e-key, d-key) is generated from somecommon seed data. The seed data is then thrown away.After that, it is computationally hard to derive one key from the other.
•^
Possession of e-key does not lead to an easy discovery of the d-key.(even though they are related). Typical use scenario:Each person issued a d-key.
(“private key”)
Make e-key public to the world. (“public key” of the person)Often (e.g., RSA), encrypt() = decrypt(). We will just use “crypt” for bothfunctions when using asymmetric keys.Sending a confidential message to the person.
•^
Ann -> Bob: crypt(message, Bob’s e-key)
-^ Only Bob can read this message
Digital signing:
•^
Bob -> Ann: “Bob”, crypt(message, Bob’s d-key) Ann (and the rest of the world) can verify that Bob must have sent themessage. No one else could have generated the crypt part. Think of the cryptpart above as a digitally signed message.
o^ Why include “Bob” in the message? o^ Is the above different from:Bob -> Ann: “Bob”, Encrypt(message, symmetric-key of
Ann and Bob)?
Yes:
^
Non-repudiation. Ann can “prove” to a third-party that Bobmust have sent the message. Only possible withasymmetric keys.
Asymmetric keys are typically much longer than symmetric keys to be resistant tobrute-force attacks on breaking the keys.
•^
Typical symmetric key lengths: 128 bits (256 bits for really sensitiveuses).
-^ Typical asymmetric key lengths: 1024 bits (2048 for more sensitive uses). o^ Keys are longer because the keys can be derived from each other ifthey are too short. o^ Implication: asymmetric key encryption and decryption is orders of
Try “md5sum file” on a Linux system.Properties of good cryptographic hash functions:They may infinite set of messages to a limited space (e.g., 128-bit value).Thus collisions are possible. But, given the large destination space,collisions should be very rare.The function is “one-way”. In other words, given a hash value, it is difficult to find a corresponding message.
However, given a message, it is easy to find its hash.Using cryptographic hashes in digital signatures:cleartext, crypt(hash(cleartext), author-private-key)The above is much more efficient to compute since hash is much shorter than cleartext.
Verification:
Receiver computes hash(cleartext).Receiver computes crypt(
nd-part of above message, author-public-
key)
Receiver compares the above two values. If they match, message is
signed correctly. Else it is not. Revising Password Verification on a Machine
How does the OS know that a user has typed the correct password?One possibility is for the OS to store every user’s password on its local disk (ala project 3).
What are the risks with that?A more secure solution:
•^
The OS stores <userid, hash(password)> pairs.
-^ When a user types a password, its hash is computed and looked upto see if it matches the stored value. -^ Linux does this. It stores the hash in /etc/shadow files. -^ Also a good idea for designing secure web sites. Web sites oftenget broken into. You don’t want someone to steal all thepasswords. Better to lose the hashes than the passwords.
Access Control
Assuming that the user has authenticated, the OS still needs to decide what rights to give to the user.
Given, userid, operation, and an object, the access control module will reply YES or NO.
Several ways to implement this. Let’s consider an example:file1: read-write by Ann, read by Bob, and no rights for anyone else(owner Ann)file 2: owner Bob. Read-write-execute by Bob, read-execute by Ann,
no rights for anyone else.
The above examples are not easy to handle in Unix, but can be handled usinggroups. •^ For file1:
-^ For file 2: -^ What would be an example set of permissions on a file that cannot behandled in a Unix file system? Sample commands:% ls –l (shows permissions)% chmod ugo+rwx file
(give read-write-execute access to everyone)
% chmod o-rwx file (give no rights to others)% chown newowner file
(changes the owner. Who should be allowed to
do this?).
% chgrp newgrp file
(changes the group. Who should be allowed to do this?)
•^
AFS: ACL-based. But a full list.% afs setacl –dir -acl <username|groupname> % afs listacl(setacl leaves existing permissions intact. It is a “delta” on existingpermissions).file1:
file2: ACLs versus capabilities
•^
Capabilities are more portable. User carries it. Could be more appropriatefor highly distributed systems.
-^ Capabilities are harder to revoke. E.g., risk of misuse of your passport orID or gift card even if you cancel it. The enforcement point must knowthat your capability is canceled – sometimes that knowledge does notpropagate. -^ Harder to give “public” access with capabilities. Every user’s capabilitymust be modified (or ACLs used in some way, in addition to capabilities). -^ Harder to take away a previously granted access to a user. If the user hascash on their debit card, hard for the bank to change the amount of cash. -^ Capabilities must be designed to be tamper-proof. -^ Capabilities could be easier to give away in some cases (e.g., give a giftcard to a friend).
