Software and Security

1. Software and Security Butler Lampson Microsoft

2. Real-World Security • It’s about value, locks, and punishment. • Locks good enough that bad guys don’t break in very often. • Police and courts good enough that bad guys that do break in get caught and punished often enough. • Less interference with daily life than value of loss. Security is expensive—buy only what you need. • People do behave this way • We don’t tell them this—a big mistake • Perfect security is the worst enemy of real security

3. Dangers and Vulnerabilities • Dangers • Vandalism or sabotage that • damages information • disrupts service • Theft of money • Theft of information • Loss of privacy integrity availability integrity secrecy secrecy • Vulnerabilities • Bad (buggy or hostile) programs • Bad (careless or hostile) peoplegiving instructions to good programs

4. Defensive strategies • Control the bad guys • Coarse: Isolate—keep everybody out • Medium: Exclude—keep the bad guys out • Fine: Restrict—Keep them from doing damage Recover—Undo the damage • Catch the bad guys and punish them • Auditing, police

5. The Access Control Model • Guards control access to valued resources. Do Reference Object Principal operation monitor Source Request Guard Resource

6. Mechanisms—The Gold Standard Authenticating principals • Mainly people, but also channels, servers, programs(encryption implements channels, so key is a principal) Authorizing access • Usually for groups, principals that have some property, such as “type-safe” or “safe for scripting” Auditing • Assurance • Trusted computing base

7. Assurance: Making Security Work • Trusted computing base • Limit what has to work to ensure security • Ideally, TCB is small and simple • Includes hardware and software • Also includes configuration, usually overlooked • What software has privileges • Database of users, passwords, privileges, groups • . . . • The unavoidable price of reliability is simplicity.—Hoare

8. Why We Don’t Have “Real” Security • A. People don’t buy it: • Danger is small, so it’s OK to buy features instead. • Security is expensive. • Configuring security is a lot of work. • Secure systems do less because they’re older. • Security is a pain. • It stops you from doing things. • Users have to authenticate themselves. • B. Systems are complicated, so they have bugs. • Especially the configuration

9. End-to-End Security • Be explicit about trust • Audit all security decisions • Take account of channels, machines, and software • Delegate authority (to groups or systems) • Work uniformly between organizations • Microsoft can securely accept Intel’s authentication • Groups can cross organization boundaries

10. End-to-End example • Alice is at Intel, working on Atom, a joint Intel-Microsoft project • Alice connects to Spectra, Atom’s web page, with SSL • Chain of responsibility: KSSLKtempKAliceAlice@IntelAtom@Microsoftr/wSpectra Microsoft says Intel Alice@Intel Atom@Microsoft says SpectraACL says KAlice KAlice Ktemp KSSL Alice’s smart card Alice’s login system Spectraweb page

11. Principals • Authentication: Who sent a message? • Authorization: Who is trusted? • Principal — abstraction of “who”: • People Alice, Bob • Services microsoft.com, Exchange • Groups UW-CS, MS-Employees • Secure channels key #678532E89A7692F, console • Principals say things: • “Read file foo” • “Alice’s key is #678532E89A7692F”

12. Speaks For • Principal A speaks for B: AÞTB • Meaning: if A says something in set T, B says it too. • Thus A is stronger than B, or responsible for B, about T • Examples • Alice ÞAtom group of people • Key #7438 ÞAlice key forAlice • We trust A to delegate its own authority. • Delegation rule: If Asays “BÞA” then BÞA • Why shouldA delegate to B? Analyze case by case. • Next: four examples of “speaks for”.

13. Microsoft says Intel Alice@Intel Atom@Microsoft says SpectraACL says KAlice KAlice Ktemp KSSL Alice’s smart card Alice’s login system Spectraweb page Authenticating Channels • Chain of responsibility: • KSSLKtempKAlice Alice@Intel … • KtempsaysKAlicesays • (SSL setup) (via smart card)

14. Microsoft says Intel Alice@Intel Atom@Microsoft says SpectraACL says KAlice KAlice Ktemp KSSL Alice’s smart card Alice’s login system Spectraweb page Authenticating Names: SDSI/SPKI • A name is in a name space, defined by a principal P • P is like a directory. The root principals are keys. • P speaks for any name in its name space KIntelÞKIntel / Alice (which is just Alice@Intel) KIntelsays • … KtempKAliceAlice@Intel …

15. Microsoft says Intel Alice@Intel Atom@Microsoft says SpectraACL says KAlice KAlice Ktemp KSSL Alice’s smart card Alice’s login system Spectraweb page Authenticating Groups • A group is a principal; its members speak for it • Alice@Intel Þ Atom@Microsoft • Bob@Microsoft Þ Atom@Microsoft • … • Evidence for groups: Just like names and keys. • … KAliceAlice@IntelAtom@Microsoftr/w …

16. Microsoft says Intel Alice@Intel Atom@Microsoft says SpectraACL says KAlice KAlice Ktemp KSSL Alice’s smart card Alice’s login system Spectraweb page Authorization with ACLs • View a resource object O as a principal • An ACL entry for P means P can speak for O • Permissions limit the set of things P can say for O • If Spectra’s ACL saysAtom can r/w, that means Spectrasays • … Alice@IntelAtom@Microsoftr/wSpectra

17. Microsoft says Intel Alice@Intel Atom@Microsoft says SpectraACL says KAlice KAlice Ktemp KSSL Alice’s smart card Alice’s login system Spectraweb page End-to-End Example: Summary • Request on SSL channel: KSSLsays “read Spectra” • Chain of responsibility: KSSLKtempKAliceAlice@IntelAtom@Microsoftr/wSpectra

18. Authenticating Systems: Loading • A digest X can authenticate a program SQL: • KMicrosoftsays “If image I has digest X then I is SQL”formallyXÞKMicrosoft/SQL • This is just like KAliceAlice@Intel • But a program isn’t a principal: it can’t say things • To become a principal, a program must be loaded into a host H • Booting is a special case of loading • XÞSQL makes H want to run I if H likes SQL • It also makes H assert that the running I is SQL

19. Authenticating Systems: Quoting • A loaded program depends on the host it runs on. • We write H | SQL for SQL running on H • H | SQL sayss = HsaysSQLsayss • H can’t prove that it’s running SQL • But H can be trusted to run SQL • KMicrosoftsaysH | SQL ÞKMicrosoft/SQL • This lets H convince others that it’s running SQL

20. Certifying Properties • Need a trusted authority: CAÞ “type-safe” • Actually KMSsays CA ÞKMS / “type-safe” • Usually done manually • Can also be done by a program P • A compiler • A class loader • A more general proof checker • Logic is the same: PÞ “type-safe” • Someone must authorize the program: • KMSsays P ÞKMS / “type-safe”

21. Compound Principals • A Bsayss = (Asayss)  (Bsayss) • H | Psayss = HsaysPsayss • A Bsayss = (Asayss)  (Bsayss) • Useful for weakening a principal: • A Bsays “read f” needs both A ÞRf and B ÞRf • Example: Java rule—callee Þ caller  callee-code • Example: NT restricted tokens—if process P is running untrusted-code for blampson thenP Þblampson untrusted-code

22. Auditing • Checking access: • Given a request KAlicesays “readSpectra” an ACL Atom may r/wSpectra • Check KAlice speaks KAliceÞAtom for Atom rights suffice r/wread • Auditing: Each step is justified by • A signed statement (certificate), or • A delgation rule

23. Assurance: NGSCB (Palladium) • A cheap, convenient, physically separate machine • A high-assurance OS stack (we hope) • A systematic notion of program identity • Identity = digest of (code image + parameters) • Can abstract this: KMSsays digest KMS / SQL • Host certifies the running program’s identity:HsaysK  H | P • Host grants the program access to sealed data • H seals (data, ACL) with its own secret key • H will unseal for P if P is on the ACL

24. Learn more • Computer Security in the Real World • at research.microsoft.com/lampson • (slides, paper; earlier papers by Abadi, Lampson, Wobber, Burrows) • Ross Anderson – www.cl.cam.ac.uk/users/rja14 • Bruce Schneier – Secrets and Lies