CMSC 414
Computer and Network Security
Lecture 12
Jonathan Katz
Announcement
 Midterm exam Oct. 28, covering material through
Oct. 21
Side channel attacks
Side channel attacks
 Power attacks
– Possible for crypto implemented on hardware in
possession of the adversary
• Smartcards
• DRM modules
• TPM
 Timing attacks
– Possible for crypto implemented on hardware in
possession of the adversary
– Also possible over a network…
Simple timing attack
 Consider the following code for verifying a MAC
Vrfy(k, m, t){
correct = MAC(k,m);
for (i=0 to 15)
if correct[i] != t[i] return FALSE;
return TRUE; }
 Assume adversary able to measure the response
time until authentication fails
– Do you see the attack?
Power attack
 Example of experimental results (DES)
 Each of the 16 rounds of DES clearly visible
Attacking exponentiation
 Recall that naïve exponentiation does not run in
polynomial time
 Fast exponentiation, basic idea
exp(x, d, N) {
// compute xd mod N
ans = 1;
for i=0 to length(d) {
ans = ans * ans mod N;
if (d[i] == 1) ans = ans * x mod N; }
return ans; }
 Time/power differ in each iteration depending on d[i] !
Power/timing attacks on RSA
 Power/timing analysis of RSA implemented on a
smartcard can recover d
 Attacks via timing analysis (over a network) more
difficult
– Attacker only gets the total time of the exponentiation,
but cannot see timing for individual iterations
– Must also contend with network effects
– Boneh-Brumley show that it is possible when
exponentiation implemented in a particular way
Fault analysis
 Induce (controlled) faults in an attempt to learn
information
 Simple example (in practice more difficult!):
– Assume key hardwired into smartcard
– Set bits of key to 0, one-by-one; observe whether
output changes
– This yields all bits of the original key!
Preventing side channel attacks
 Difficult to prevent entirely…
 Power analysis
– Shielding, tamper resistance, etc.
– “Obfuscating” the algorithm to make power analysis
less useful
– Add random noise using “empty” instructions
 Timing analysis
– Make all operations take the same amount of time
– Randomize amount of time operations take (essentially
a variant of the above)
System Security
What is “system security”?
 We now know about the crypto…
– …but how do we build a secure system?
 The existence of crypto doesn’t solve everything:
– Tells us how to achieve secrecy/integrity, not when
secrecy/integrity are required
– Doesn’t tell us how to integrate crypto into the system
– Doesn’t address detection/recovery
System security -- components
 Policy (specification)
– What security properties to focus on
– What is and is not allowed
 Mechanism (implementation)
– The mechanism enforces the policy
– Includes procedural controls, not just technical ones
• E.g., who may enter the room where backup tapes are stored
• How new accounts are established
– Prevention/detection/recovery
 Assurance
– Verifying that the mechanism implements the policy
Mechanisms for enforcing policy
 The precision of a mechanism measures how
closely the mechanism matches the policy
– E.g., an overly restrictive mechanism may prevent
things that are allowed by the policy
 Hard (in general) to develop a “maximally-
precise” mechanism for an arbitrary given policy
 Impossible (in general) to determine whether a
given mechanism implements a given policy
 Made worse by the fact that policy is often
specified informally to begin with
Design considerations
 Where should security mechanism(s) be placed?
Applications
Services
(DBMS*, object reference broker)
OS
(file/memory management, I/O)
Kernel
(mediates access to processor/memory)
Hardware
*Database
management system
Design considerations
 How to prevent an attacker from getting access to
a layer below the protection mechanism?
– E.g., recovery tools (Norton utilities) that access raw
physical memory without regard for file structure
– E.g., memory reuse when multiple processes (owned by
different users) run on the same machine
– E.g., access to backup tapes or core dumps
Design considerations
 Simplicity or feature-rich system?
 A simpler system will be easier to secure, and it
will be easier to provide assurance of security
Design considerations
 Centralized or decentralized?
 A centralized system may be more secure
– Policy will always be enforced consistently
– No propagation delays if policy changes
 A centralized system can lead to performance
bottlenecks, and is less flexible
Security Principles
General principles
 Seminal article by Saltzer and Schroeder (1975)
– Linked from the course homepage
 Eight principles underlying design and
implementation of security mechanisms
 These are guidelines, not hard and fast rules
 Not exhaustive
Key point I: Simplicity
 Make designs/mechanisms/requirements easy to
understand and use
 This applies to both the policy and the
mechanism!
 Less chance of error
Key point II: Restriction
 Minimize the “power” of an entity
– E.g., only allow access to information it needs
– E.g., only allow necessary communication; restrict type
of communication allowed
 Less chance of harm!
Principle 1
 “Principle of least privilege”
– A subject should be given only the privileges it needs to
accomplish its task
– The function of a subject (not its identity) should
determine this
• I.e., if a subject needs certain privileges only to complete a
specific task, it should relinquish those privileges upon
completion of the task
• If reduced privileges are sufficient for a given task, the subject
should request only those privileges
In practice…
 There is a limit to how much granularity a system
can handle
 Systems are often not designed with the necessary
granularity
– E.g., “append” may not be distinct from “write”
– E.g., in UNIX, nothing between user and root
• Anyone who can make backup files can also delete those files
Principle 2
 “Principle of Fail-Safe Defaults”
– Unless a subject is given explicit access to an object, it
should be denied access
• I.e., the default is no access
– More generally, in case of ambiguity the system should
default to the more restrictive case
Principle 3
 “Economy of Mechanism”
– Security mechanisms should be as simple as possible…
– …but no simpler!
– Can simplify assurance process
 Offering too much functionality can be dangerous
– E.g., finger protocol: cap how much information can be
returned, or allow an arbitrary amount?
• DoS attack by returning an infinite stream of characters
– E.g., macros in Excel, Word
– E.g., postscript can execute arbitrary code
Principle 4
 “Principle of Complete Mediation”
– All accesses to objects should be checked to ensure
they are allowed
– OS should mediate any request to read an object --even on the second such request by the same subject!
• Don’t cache authorization results
• Don’t rely on authentication/authorization performed by
another module
– Time of check to time of use flaws…
 Good examples: re-authentication (on websites, or
systems) when performing sensitive tasks
Insecure example…
 In UNIX, when a process tries to read a file, the
system checks access rights
– If allowed, it gives the process a file descriptor
– File descriptor is presented to OS for access
 If permissions are subsequently revoked, the
process still has a valid file descriptor!
– Insufficient mediation
Principle 5
 “Open Design”
– No “security through obscurity”
– Security of a system should not depend on the secrecy
of its implementation
• Of course, secret keys do not violate this principle!
Principle 6
 “Separation of Privilege”
– (As much as is feasible…) a system should not grant
permission based on a single condition
– E.g., require more than one sys admin to issue a critical
command, or more than one teller to issue an ATM card
Principle 7
 “Principle of Least Common Mechanism”
– Minimize mechanisms depended upon by all users
• Minimize effect of a security flaw!
– Shared mechanisms are a potential information path,
and so may be used to compromise security
– Shared mechanisms also expose the system to potential
DoS attacks
Principle 8
 “Psychological Acceptability”
– Security mechanisms should not make access to the
resource more difficult
– If mechanisms are too cumbersome, they will be
circumvented!
– Even if they are used, they may be used incorrectly
OS Security
Overview
 Traditional OS security motivated by multi-user
systems
– E.g., unix
– This is what we focus on in this segment
 There is a movement away from such systems
– Computing done on desktop PC, and/or on a remote
(shared) server but without “awareness” of other users
 Multi-user systems still used in business, govt.
environments (shared files, shared databases, etc.)
Threats in multi-user context
 Unauthorized reading/modification of files by
legitimate users
 Unauthorized use of system resources by
legitimate users
 Unauthorized access by illegitimate users