Security Engineering

1
Security Engineering

• Chapter 6
• Distributed Systems

2
Intro

• Security Engineering A Guide to Building
  Dependable Distributed Systems, by Ross Anderson
• Chapter 6 Distributed Systems
• Who is Ross Anderson?
• Professor at Cambridge
• Lots of real-world security work
• for example, ATM machines

3
Distributed System

• You know you have a distributed system when the
  crash of a computer youve never heard of stops
  you from getting any work done.
  --- Leslie Lamport

Terminology principal entity
4
Distributed Systems Security

• Ross Andersons view
• A broad perspective
• Lots of anecdotes (not always clear)
• Many familiar, real world examples
• Read it!
• Easy to read on one level
• Hard to read on another level
• Almost every sentence alludes to something
• Lots of stuff on naming

5
Chapters 1 Thru 5

• Protocols
• Authentication, authorization, key establishment,
  etc., over a network
• Access control
• Passwords
• Authentication
• Authorization
• Crypto
• Secret codes

6
Topics in Chapter 6

• Concurrency
• Things happen at same time
• More generally, the order matters
• Fault tolerance/failure recovery
• How to survive and recover?
• Naming
• About half of the chapter

7
Concurrency

• Concurrent processes
• Run at the same time
• More broadly, order/timing matters
• Many potential problems
• Is data old or new?
• Order of updates
• Convergence
• Hard to agree on time

8
Concurrency

• Concurrency-related security issues
• Replay attack
• A protocol issue
• Password/hashed password example
• Prevention?
• Race condition
• Usually considered a software issue
• Debit card example
• Prevention?
• Other?

9
Concurrency

• Concurrency control
• Stop processes from interfering with each other
• This is an access control issue
• Concurrency makes programming hard
• Errors can lead to security flaws
• Threads open to lots of problems
• In general
• Not easy to deal with random/accidental errors
• Intelligent adversary is much more difficult
• We try to minimize security problems
• Cannot eliminate security problems

10
Concurrency

• Is data old or new?
• Credit card example
• Verify all transactions with bank that issued
  card?
• Instead multiple levels of processing
• Small versus big
• System scales well since most transactions are
  small and local

11
Concurrency

• Order of updates
• Suppose
• 500,000 credit to an account
• 400,000 debit to same account
• Does order of operations matter?
• How to decide order in practice?
• Credit card pre-authorization
• Debit in real time, credit is not
• Passports --- order does not matter

12
Concurrency

• Convergence
• Conventional wisdom is that distributed system
  protocols should be
• Atomic --- all or nothing
• Consistent --- e.g., debits and credits balance
• Isolated --- serializable
• Durable --- cannot be undone
• ACID can be too much or not enough
• Alternative to ACID
• Convergent --- if transactions stop, system will
  eventually reach a consistent state

13
Concurrency

• Time
• Why is this a security issue?
• Some protocols use time (Kerberos)
• Cinderella attack
• Time needed for synchronization

14
Concurrency

• What time is it?
• Radio clocks
• Voting --- designed to withstand errors, not
  malicious attacks
• Lamport time --- relative time
• Challenge-response instead of timestamp is an
  example of relative time
• Network Time Protocol --- OK for some
  applications
• RFC 2030 --- Simple Network Time Protocol,
  Security issues are not discussed in this memo.

15
Faults and Failures

• Fault
• May cause an error
• Error
• Incorrect state
• Failure
• Deviation from correct behavior
• Fault ? Error ? Failure

16
Faults and Failures

• Classic view of security CIA
• Confidentiality --- no unauthorized reading
• Integrity --- no unauthorized writing
• Availability --- self-explanatory
• Fault tolerance and failure recovery
• These are issues of availability
• Availability neglected by researchers
• But most critical in practice

17
Faults and Failures

• Classic fault tolerance methods
• Such as logs and locking
• Not designed to withstand malicious attack
• What kinds of failures?
• Byzantine failure n generals, t traitors
• A model for malicious attack
• If t lt n/3 then traitors do not win

18
Faults and Failures

• How to deal with failures?
• Fail-stop processors --- stop if problem is
  detected (issues?)
• Redundancy --- multiple copies (issues?)
• Replication --- availability and integrity
• Popular in commercial systems
• Tamper resistance --- confidentiality
• Popular in military systems
• Example credit card system
• Error check and crypto integrity check

19
Faults and Failures

• What is resilience for?
• Confusing section
• Direction of mistrust in protocol design
• Server mistrusts clients --- require password
• Client mistrusts server --- SSL
• Client faces multiple unreliable servers ---
  reuse of Kerberos tickets is a feature, not a bug
• Both mistrust each other --- more complicated
• Security renewability
• Pay TV example
• More generally, DRM

20
Faults and Failures

• At what level is the redundancy?
• In security in general
• The higher the layer, the more complex and less
  reliable and less secure
• For example, key in tamper-resistant hardware
  versus key in software
• For example, access control at kernel level
  versus access control at application layer

21
Faults and Failures

• At what level is the redundancy?
• Hardware
• Multiple CPUs, mirrored disks, RAID
• Again, not designed for malicious attack
• Process group redundancy
• Run multiple copies, vote on answer
• Backup/checkpoint
• Fallback
• E.g., credit card zip-zap machine

22
Faults and Failures

• At what level is the redundancy?
• Hardware redundancy, group redundancy, backup,
  fallback
• Are all different
• Each most useful against different threat
• Hardware redundancy
• Cannot stop software attacks
• Fallback
• Might open new attacks (credit cards), etc.

23
Faults and Failures

• Bottom line
• Hard to protect availability
• Hard to prevent denial of service
• Often, no optimal solution
• Password lockout
• Similar issues in many other contexts
• A is an important research area
• To date, far more research into C and I

24
Naming

• Naming is a minor, if troublesome, aspect of
  ordinary distributed systems, but it becomes
  surprisingly hard in security engineering.
• Most of the problem due to ignoring the
  established lessons of naming in ordinary
  distributed systems.

25
Naming

• Needhams view of naming
• Names exist to facilitate sharing
• Name resolution may be distributed
• Bad idea to limit number of possible names
• Global names are not as useful as you think
• Naming scheme should be flexible
• Names may serve other (security) purposes
• Incorrect names should be obvious
• Consistency is hard
• Simpler is usually better
• When to bind names?

26
Naming

• Names exist to facilitate sharing
• Names needed when data can change
• Name resolution may be distributed
• Naming includes all the problems of distributed
  systems
• Example early online bank might use telephone
  number to authenticate user
• Bad idea to limit number of possible names
• Timely example?
• Credit card example

27
Naming

• Global names are not as useful as you think
• For example, IPv6?
• Name (e.g., at bank) must resolve to local name
• Intermediate name is at same scale and same level
  of security as name we are trying to protect
• One reason why banks not excited about PKI
• Naming scheme should be flexible
• Private key tied to department?
• Reorganization?
• Names may serve other (security) purposes
• Todays name is tomorrows password

28
Naming

• Incorrect names should be obvious
• Credit card checksum can be checked locally
• Crypto checksum must be checked remotely
• Consistency is hard
• Barcode example
• Simpler is usually better
• Phone numbers more robust than IP addresses
• SET designed as new credit card protocol
• SET to be revived?
• When to bind names?
• Generally want to bind names late
• In security, probably want to bind early

29
Naming

• Anderson considers 6 more issues
• Naming and identity
• Cultural assumptions
• Semantic content of names
• Uniqueness of names
• Stability of names
• Restrictions on use of names

30
Naming

• Naming and identity
• Identity --- 2 different names correspond to the
  same principal (a symbolic link)
• May link 2 different systems, such as bank and
  passport office
• Cultural assumptions
• Example Names on scientific articles
• National ID cards

31
Naming

• Semantic content of names
• Example
• To better target junk mail, bank linked all
  accounts to owner
• Caused bank account info for mistress to go to
  wife
• Example
• Store card later changed to bank card
• Uniqueness of names
• Lots of people named mark stamp

32
Naming

• Stability of names
• IPv6 addresses permanent
• Or not?
• Restrictions on use of names
• Legal restrictions on use of SS number
• Medical databases
• Easy for police to trace who you called and when,
  but much harder to tap the calls
• How does this translate to cyberspace?

33
Naming

• Alice as computer game player
• Alice as system admin
• Often treated as different principals
• Then no link between them
• Or could use RBAC

34
Naming

• Businesses want to get paid
• Governments want to identify people
• Businesses want a credit card number
• Governments want a passport number
• Can show your passport to a million people
• Dont try that with your credit card!