Professor G. slides derived from : Tanenbaum/Bo, and -Gavitt Thanks !!
Copyright By PowCoder代写 加微信 powcoder
• The Security Environment
• OS Security
• Controlling Access to Resources
• Formal Models of Secure Systems
• Basics of Cryptography
• Authentication
• Software Security
Computer Security
• Security is a big field, encompassing:
• Application security
• Network security
• Authentication
• Digital forensics
• Cryptography
• Privacy/Anonymity
Threat Modeling
• It usually doesn’t make sense to talk about a system being “secure” or “insecure”
• Instead, we need to be more precise:
• What are we trying to protect?
• Who do we need to protect against? What are their capabilities?
Threat Modeling
• Roughly, we can divide this into three steps:
• System understanding
• Threat categorization
• Countermeasures and mitigation
System Understanding
• To properly protect a system, you need to understand it:
• Identify assets that need protecting
• Look at ways the system can be used and assets can be accessed
• Figure out what rights should be granted to what assets and classes of user
• Identify privilege boundaries – places where a program or user changes their privilege level
Example System Diagram
Source: OWASP
Threat Categorization
• Look at the system from an attacker’s point of view
• What goals might an attacker have?
• How could they achieve these goals?
• May help to use a threat categorization such as STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
Mitigation
• For each of the threats to some asset, come up with a plan for mitigating or nullifying the threat, for example:
• Attacker might guess someone’s password => enforce password complexity requirements
• Attacker might snoop on network traffic => encrypt data that is sent on the network
Operating Systems Security
• In this course we will only worry about security as it applies to operating systems
• This is some mix of authentication, access control, and application security
Computer Security
• Generally, we talk about computer security in three broad categories:
• Confidentiality – Exposure of data or preventing others from finding out information we don’t want them to have
• Integrity – Tampering with Data or preventing others from modifying our data without permission
• Availability – Denial of Service or preventing others from denying us access to some service ()
Computer Security
• Generally, we talk about computer security in three broad categories:
• Confidentiality – Exposure of data or preventing others from finding out information we don’t want them to have
• Integrity – Tampering with Data or preventing others from modifying our data without permission
• Availability – Denial of Service or preventing others from denying us access to some service ()
Threat Modeling
• It usually doesn’t make sense to talk about a system being “secure” or “insecure”
• Instead, we need to be more precise:
• What are we trying to protect?
• Who do we need to protect against? What are their capabilities?
Threat Modeling
• Roughly, we can divide this into three steps:
• System understanding
• Threat categorization
• Countermeasures and mitigation
System Understanding
• To properly protect a system, you need to understand it:
• Identify assets that need protecting
• Look at ways the system can be used and assets can be accessed
• Figure out what rights should be granted to what assets and classes of user
• Identify privilege boundaries – places where a program or user changes their privilege level
Example System Diagram
Source: OWASP
Threat Categorization
• Look at the system from an attacker’s point of view
• What goals might an attacker have?
• How could they achieve these goals?
• May help to use a threat categorization such as STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
Mitigation
• For each of the threats to some asset, come up with a plan for mitigating or nullifying the threat, for example:
• Attacker might guess someone’s password => enforce password complexity requirements
• Attacker might snoop on network traffic => encrypt data that is sent on the network
• The Security Environment
• OS Security
• Formal Models of Secure Systems
• Basics of Cryptography
• Authentication
• Software Security
Trusted Computing Base
• One strategy for building secure operating systems is to organize them into trusted and untrusted components
• The goal is that if the trusted component performs according to its specification, then some specific set of guarantees about security must hold
• A reference monitor checks all accesses between the trusted and untrusted components
Trusted Computing Base
• The TCB typically consists of:
• Most of the hardware except (I/O devices that don’t affect security)
• Part of the kernel (process creation, proc. Switching, mem management, file I/0)
• In a secure design the TCS will be separate from the rest of the OS
Aside: Bugs & Program Size
• One rule of thumb is that as program size increases, the number of bugs increases as well
• It’s harder to reason about code the more of it there is
• Therefore, if we want to be confident in our trusted computing base, we should work to minimize the amount of code in it
• How big is the TCB(Trusted Computed Base) for widely- used operating systems?
Access Control: Resources
• Systems tend to have resources that need to be protected
• Hardware: CPUs, memory, disk drives, …
• Software: processes, files, databases, …
• We’ll refer to these generally as “objects” for now
Protection Domain
• A protection domain is a set of (object, rights) pairs
• A right, in this context, means an operation that can
be performed on an object
• So, for example, a protection domain might correspond to a user, and the set of objects they have access to
• Or, a group of users that all share the same rights
Protection Domain
Principle of Least Privilege
• One principle for designing secure systems is principle of least privilege, also called the principle of least authority
• Idea: Give the minimal set of rights to an object.
• Seems obvious, but is often violated in practice
Processes and Protection Domains
• At any given time, a process operates in one protection domain
• I.e., there is some specific set of objects that it has permission to perform some actions on
• Processes can also typically switch between protection domains as they run
• The rules for when and how they do this vary widely between different operating systems
The UNIX Protection Model
• The protection domain of a process in UNIX is defined by its user id (UID) and group id (GID)
• The objects are files (including special files like hardware devices)
Cryptographic Capabilities
• Cryptography provides us with a way to store a capability wherever we like (even in user space) while protecting it from modification
• Suppose we have a cryptographic one-way function: f(Data, Secret) => Output (fixed length)
• Where it is computationally infeasible to figure out Secret if we only have Output
Cryptographic Capabilities
• To give a process a capability, kernel gives out ObjectId, Rights, Token
where Token = f(ObjectId+Rights, Secret)
• Now when the process wants to access something, it includes the capability, including the token
• The kernel can now compute f(ObjectId+Rights, Secret) and compare it to the Token
• If they match, we know the ObjectId and Rights have not been modified
Cryptographic Capabilities
• The nice thing about using cryptography in this way is that we can store the capability anywhere
• In particular, capabilities can even be given out to remote machines that we don’t control
• This makes them ideal for distributed systems
• Example: the Kerberos protocol uses capabilities this way (though it calls them tickets)
• The Security Environment
• OS Security
• Controlling Access to Resources
• Formal Models of Secure Systems
• Basics of Cryptography
• Authentication
• Software Security
Multi-Level Security
• The usual way to do mandatory access control is by splitting users and information into access levels
• Classic example: unclassified, secret, top secret
• However, there still has to be some policy for allowing information to move between levels so work can get done
Bell-LaPadula
• Designed to formally model the US Department of Defense security policy
• Users and data are assigned security levels from low to high
• Then we have the policy:
• Users at a lower level cannot read information at a higher level (no read up)
• Users at a higher level cannot send information to a lower level (no write down)
Multilevel Security Systems
• Levels are confidential, Secret and Top Secret
• Compartments: Crypto, Subs, NoForn (no foreign nationals)
• To read a document, you must have at least as high a clearance level and you must be cleared for each compartment
• Systems that support this level are called Multilevel security systems.
• Pat is cleared for Secret, subs
• Chris is cleared for Top Secret, planes
• We have the following files:
warplan Top Secret Runway Confidential Sonar Top secret Torpedo Secret
• Who can read which file?
Troops, Subs, Planes Planes
• Do these models actually guarantee that in practice, unauthorized information can’t leak between levels?
• No! It turns out there are many more ways to transfer information than the authorized channels
• For example, a user at one security level could send sensitive information to a lower level by performing more or less computation
• Resulting delays could be observable to lower levels, transmitting information
Steganography
• Even if we allow a human to inspect all data passed between levels, we can still have covert channels
• The way to do this is with steganography – hiding data inside other data
• Essentially, make changes that are not observable unless you know what you’re looking for, and use those changes to encode information
Steganography
• How does this work? Suppose each color is represented by three bytes (red, green, blue)
• Take the least significant bit of each byte and use it to store your own information
• This only adds or subtracts 1 from each color value – not visually detectable
• So we can now get 1 bit of secret information per byte of public information!
• The Security Environment
• OS Security
• Controlling Access to Resources
• Formal Models of Secure Systems
• Basics of Cryptography
• Authentication
• Software Security
Cryptography
• Cryptography has been around a long time – at least since the Greeks, and probably earlier
• But it has changed a lot since then
• Particularly since World War II, many advances have been made in both codemaking and codebreaking
• (Right now, the codemakers are winning!)
Kerckhoffs’s Principle
• Basic principle: it should not matter if the cryptographic algorithm is known by everyone
• The only secret information should be a secret key chosen by the participants
• Less information to keep secret
• If the key is revealed, we can just change it
• Restated by : “The enemy knows the system”
Secret Key Cryptography
• Two parties who want to communicate agree on a secret key shared between them
• Then they use encryption and decryption functions:
• E(Data, Key) = Encrypted Data
• D(Data, Key) = Decrypted Data
• D(E(Data, Key), Key) = Data
• Algorithm: take each letter and shift it forward in the alphabet by n letters
• Secret key: the number to shift by (1-25)
• For example, ROT13: shift by 13 letters
• ATTACK AT DAWN
• NGGNPX NG QNJA
Secret Key Cryptography
• Modern secret key crypto is much more sophisticated
• Algorithms like AES (the Advanced Encryption Standard) employ substitutions and permutations so that the output has no relationship to input unless the secret is known
• As far as we know! We have been wrong before…
• Keys are generally 128 or 256 random bits – much too large to try all combinations
Public Key Cryptography
• Secret key cryptography was the only kind that existed until the 1970s
• It’s inconvenient! Two parties have to somehow securely transmit (or agree on) a secret key
• Particularly on the Internet, this is impractical
• Imagine having to visit an Amazon office to get a secret key in order to shop online…
Public Key Cryptography
• Instead of a single secret key, we now have a key with two parts: a public key and a private key
• E(PubKey, Data) = Encrypted Data
• D(PrivKey, Data) = Decrypted Data or Data
• D(PrivKey, E(PubKey, Data)) = Data
• So now to communicate securely, we just need to know someone’s public key
Public Key Crypto Algorithms
• Some examples:
• RSA (1977)
• Elliptic Curve Algorithms
Key Exchange
• A slightly different twist on this: can we use only public communications to allow two people to agree on a secret key?
• Surprisingly, the answer is yes!
• and first showed this was possible in 1976
Diffie-Hellman by Analogy
A.J. , Introduction to public key cryptography, p. 16
Hash Functions
• We saw before that one-way functions can let us do useful things like store capabilities
• Basic idea: Hash(x) = y
• Preimage resistance: It should be very difficult to take y and figure out x
• Second preimage resistance: It should be very difficult to find another value z where Hash(z) = y
• Collision resistance: It should be very difficult to find x1 and x2 such that Hash(x1) = Hash(x2)
• Examples: MD5, SHA-1, SHA-3
• The Security Environment
• OS Security
• Controlling Access to Resources
• Formal Models of Secure Systems
• Basics of Cryptography
• Authentication
• Software Security
Authentication
• To prove you are who you say you are, we usually use one of three things:
• Something you know
• Something you have
• Something you are
• “Something you know” – one of the simplest and oldest forms of authentication, and still ubiquitous
• Generally easy to change
• Very easy to implement, since you can just ask for a short string and compare it with the one you have stored
Password Storage
• It’s generally a bad idea to store passwords directly
• If someone gets ahold of the password file, they can read all passwords
• This is particularly bad since people tend to re-use their passwords in multiple places…
Password Storage
• Instead, we use a cryptographic hash function on the password
• We compute (for example):
• SHA1(“goodpassword”) = 7e5ce399fbe3713ec7f6aae370448cdf990f0aaa
• Then we only store 7e5ce399fbe3713ec7f6aae370448cdf990f0aaa
• Now to check the password someone entered, we hash it and compare the hashes instead
How Passwords are Broken
• Assuming they only have a file with password hashes, how can an attacker find out the original passwords?
• Password hashes nowadays are broken primarily in two ways:
• Precomputation: Spend a lot of time beforehand computing the hash of every possible password, then just look up each hash in your table
• Dictionary Attacks: Guess the most common passwords (e.g. using a dictionary), hash them, and compare
Password Salts
• To avoid precomputation attacks, we can use a salt
• Instead of computing and storing Hash(Password), we instead:
• Generate a random string (a salt)
• Compute Hash(Salt+Password)
• Store on disk Salt, Hash(Salt+Password)
• Now to do a precomputation, you have to store not just the hash of every possible password (hard but doable) but the hash of every possible password+salt (way too much space)
Time- and Memory-Hard Password Hashing
• Cryptographic hash functions were developed to be fast
• This is good for many uses of them, but bad for passwords: it
lets an attacker try billions of passwords per second
• To avoid this, people have developed hash algorithms that are
deliberately very slow (and cannot be sped up)
• One example is bcrypt
• We may also want it to take a lot of memory
• A newer algorithm called scrypt does this
One-Time Passwords
• An alternative to having a single password is to use a different password every time
• Even if an attacker eavesdrops on a connection and learns the password, it doesn’t do them any good
• A password list can be exchanged securely (e.g., banks sometimes send them in the mail)
Nordea Bank one-time password list
Lamport Hash Chain
• Instead of mailing out passwords each time, we can get many of the benefits using a hash chain
• The idea is to use a one-way function to create a sequence of hashes
• If you repeatedly apply a hash to some starting value, you get a sequence that is:
• Easy to compute starting from the seed going forward
• Hard to compute starting from a hash value and going backward
Lamport Hash Chain
• Initially, user chooses a password p
• Compute fk(p) = f(f(f(…f(p)))) and store this value on the server
• To log in, user computes and sends h = fk-1(p)
• Server checks that f(h) matches its stored value, and then replaces the current stored value with h
Challenge-Response
• Another way to avoid sending a password directly over the network is challenge response authentication
• The idea is that the server sends a challenge (a random value)
• Client then uses their secret and the challenge to compute a response
• Server can now verify that the response is the correct one for that challenge
Challenge-Response
• One simple way to implement challenge response is to once again use a one-way function
• Client and server each know some secret s (say, a password)
• Server computes a random r and sends it to the client
• Client computes f(r+s) and sends it to the server
• Server can do the same computation to verify
• Value sent over the network is useless to an attacker since the challenge (r) will not be reused
Authentication
• To prove you are who you say you are, we usually use one of three things:
• Something you know
• Something you have
• Something you are
Physical Tokens
• Oldest examples: physical keys
• Basically – something you physically possess that grants you access to something
• There are lots of these now: ATM cards, smart cards, RFIDs, secure tokens, smartphones
Smart Cards
• Credit card sized
• Contain a chip that can do some simple cryptographic computations and stores a secret key
• The reader can then ask the chip to do cryptographic operations without revealing the key to the reader
RFID Authentication
• Radio communications can be used instead of direct contact
• When you put the card near a reader, the reader actively probes
• The card can collect energy from the incoming radio waves, compute a response, and send it back
The Great Seal Bug
• An early predecessor to RFID technology was the great seal bug
• This was a carved wooden seal presented by the Soviets to the US in 1945
• If radio waves at the right frequency were sent to the device, it activate the circuit and send sound back
• Entirely passive listening device – very hard to detect!
Physical Tokens
Authentication
• To prove you are who you say you are, we usually use one of three things:
• Something you know
• Something you have
• Something you are
Biometrics
• Idea: measure something intrinsic to a person that is different for everyone
• Things you can measure (partial list):
• Fingerprints
• Retina pattern • Voiceprint
• Keystroke timing
• Finger length
• Face recognition • DNA?
Biometrics
• Two phases: enrollment and verification
• Enrollment consists of taking the measurements of a user and
converting them into digital form
• Often measurements are taken multiple times to account for measurement error and natural variation
• At verification time, redo the measurement, and decide if it’s close enough (will almost never be exactly the same)
• Note the tradeoff here: risk o
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com