CMSC 414 Computer and Network Security Lecture 12

1. CMSC 414Computer and Network SecurityLecture 12 Jonathan Katz

2. Announcement • Midterm exam Oct. 28, covering material through Oct. 21

3. Side channel attacks

4. 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…

5. 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?

6. Power attack • Example of experimental results (DES) • Each of the 16 rounds of DES clearly visible

7. 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] !

8. 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

9. 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!

10. 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)

11. System Security

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. Security Principles

20. 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

21. 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

22. 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!

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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!

30. 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

31. 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

32. 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

33. OS Security

34. 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.)

35. 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