Software and Security

1
Software and Security

• Butler Lampson
• Microsoft

2
Real-World Security

• Its about value, locks, and punishment.
• Locks good enough that bad guys dont 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 expensivebuy only what you need.
• People do behave this way
• We dont tell them thisa 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) people giving
  instructions to good programs

4
Defensive strategies

• Control the bad guys
• Coarse Isolatekeep everybody out
• Medium Excludekeep the bad guys out
• Fine RestrictKeep them from doing damage
• RecoverUndo the damage
• Catch the bad guys and punish them
• Auditing, police

5
The Access Control Model

• Guards control access to valued resources.

Reference
Do
Object
Principal
monitor
operation
Resource
Guard
Request
Source
6
MechanismsThe 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 Dont Have Real Security

• A. People dont buy it
• Danger is small, so its OK to buy features
  instead.
• Security is expensive.
• Configuring security is a lot of work.
• Secure systems do less because theyre 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 Intels
  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, Atoms web page, with
  SSL
• Chain of responsibility
• KSSL ? Ktemp ? KAlice ? Alice_at_Intel
  ?Atom_at_Microsoft ?r/w Spectra

Microsoft
says
Intel
Alice_at_Intel
Atom_at_Microsoft
says
Spectra ACL
says
Ktemp
KAlice
KAlice
KSSL
Alices smart card
Alices 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
• Alices key is 678532E89A7692F

12
Speaks For

• Principal A speaks for B A ÞT B
• 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 for Alice
• We trust A to delegate its own authority.
• Delegation rule If A says B Þ A then B Þ A
• Why should A delegate to B? Analyze case by case.
• Next four examples of speaks for.

13
Authenticating Channels

• Chain of responsibility
• KSSL ? Ktemp ? KAlice ?
  Alice_at_Intel ?
• Ktemp says KAlice says
• (SSL setup) (via smart card)

14
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_at_Intel)
• KIntel says
• Ktemp ? KAlice ? Alice_at_Intel ?

15
Authenticating Groups

• A group is a principal its members speak for it
• Alice_at_Intel Þ Atom_at_Microsoft
• Bob_at_Microsoft Þ Atom_at_Microsoft
• Evidence for groups Just like names and keys.
• KAlice ? Alice_at_Intel ? Atom_at_Microsoft ?r/w

16
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 Spectras ACL says Atom can r/w, that means
• Spectra says
• Alice_at_Intel ? Atom_at_Microsoft ?r/w Spectra

17
End-to-End Example Summary

• Request on SSL channel KSSL says read Spectra
• Chain of responsibility
• KSSL ? Ktemp ? KAlice ? Alice_at_Intel
  ?Atom_at_Microsoft ?r/w Spectra

18
Authenticating Systems Loading

• A digest X can authenticate a program SQL
• KMicrosoft says If image I has digest X then I
  is SQL formally X Þ KMicrosoft / SQL
• This is just like KAlice ? Alice_at_Intel
• But a program isnt a principal it cant 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 says s H says SQL says s
• H cant prove that its running SQL
• But H can be trusted to run SQL
• KMicrosoft says H SQL Þ KMicrosoft / SQL
• This lets H convince others that its running SQL

20
Certifying Properties

• Need a trusted authority CA Þ type-safe
• Actually KMS says 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
• KMS says P Þ KMS / type-safe

21
Compound Principals

• A ? B says s (A says s) ? (B says s)
• H P says s H says P says s
• A ? B says s (A says s) ? (B says s)
• Useful for weakening a principal
• A ? B says read f needs both A ÞR f and B ÞR f
• Example Java rulecallee Þ caller ? callee-code
• Example NT restricted tokensif process P is
  running untrusted-code for blampson thenP Þ
  blampson ? untrusted-code

22
Auditing

• Checking access
• Given a request KAlice says read Spectra an
  ACL Atom may r/w Spectra
• 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 KMS says digest ? KMS / SQL
• Host certifies the running programs identity
  H says K ? 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