Document Sample
SE Powered By Docstoc
					            Security Engineering

                         Chapter 6
                    Distributed Systems

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

Security Engineering (Chapter 6)           2
             Distributed System
   You know you have a distributed
   system when the crash of a computer
   you’ve never heard of stops you from
   getting any work done.
      --- Leslie Lamport

  Terminology: principal == entity

Security Engineering (Chapter 6)      3
Distributed Systems Security
   Ross Anderson’s view
    o A broad perspective
    o Lots of anecdotes (not always clear)
    o Many familiar, real world examples
   Read it!
    o Easy to read on one level
    o Hard to read on another level
    o Almost every sentence alludes to something
   Lots of stuff on naming

Security Engineering (Chapter 6)                   4
                Chapters 1 Thru 5
   Protocols
    o Authentication, authorization, key
        establishment, etc., over a network
   Access control
    o Passwords
    o Authentication
    o Authorization
   Crypto
    o “Secret codes”

Security Engineering (Chapter 6)              5
              Topics in Chapter 6
 Concurrency
    o Things happen at same time
    o More generally, the order matters
 Fault         tolerance/failure recovery
    o How to survive and recover?
 Naming
    o About half of the chapter

Security Engineering (Chapter 6)             6
 Concurrent                 processes
    o Run at the same time
    o More broadly, order/timing matters
 Many          potential problems
    o   Is data old or new?
    o   Order of updates
    o   Convergence
    o   Hard to agree on time

Security Engineering (Chapter 6)           7
 Concurrency-related security issues
 Replay attack
    o A protocol issue
    o Password/hashed password example
    o Prevention?
   Race condition
    o Usually considered a software issue
    o Debit card example
    o Prevention?
   Other?

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

Security Engineering (Chapter 6)                    9
 Isdata old or new?
 Credit card example
    o Verify all transactions with bank that
      issued card?
    o Instead multiple levels of processing
    o Small versus big
 System   scales well since most
   transactions are small and local

Security Engineering (Chapter 6)               10
 Order of updates
 Suppose
    o   $500,000 credit to an account
    o   $400,000 debit to same account
    o   Does order of operations matter?
    o   How to decide order in practice?
   Credit card pre-authorization
    o Debit in real time, credit is not
   Passports --- order does not matter

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

Security Engineering (Chapter 6)                              12
 Time
 Why          is this a security issue?
    o Some protocols use time (Kerberos)
    o Cinderella attack
    o Time needed for synchronization

Security Engineering (Chapter 6)           13
   What time is it?
    o Radio clocks
    o Voting --- designed to withstand errors, not
        malicious attacks
    o   Lamport time --- relative time
    o   Challenge-response instead of timestamp is an
        example of relative time
    o   Network Time Protocol --- OK for some
    o   RFC 2030 --- Simple Network Time Protocol,
        “Security issues are not discussed in this memo.”

Security Engineering (Chapter 6)                      14
                Faults and Failures
 Fault
   o May cause an error
 Error
   o Incorrect state
 Failure
   o Deviation from correct behavior
 Fault         Error  Failure

 Security Engineering (Chapter 6)      15
                Faults and Failures
 “Classic”           view of security: CIA
   o Confidentiality --- no unauthorized reading
   o Integrity --- no unauthorized writing
   o Availability --- self-explanatory
 Fault        tolerance and failure recovery
   o These are issues of availability
 Availability              neglected by researchers
   o But most critical in practice

 Security Engineering (Chapter 6)                      16
                Faults and Failures
 Classic          fault tolerance methods
   o Such as logs and locking
   o Not designed to withstand malicious attack
 What          kinds of failures?
   o Byzantine failure: n generals, t traitors
   o A model for malicious attack
   o If t < n/3 then traitors do not win

 Security Engineering (Chapter 6)                17
               Faults and Failures
   How to deal with failures?
    o Fail-stop processors --- stop if problem is
      detected (issues?)
    o Redundancy --- multiple copies (issues?)
   Replication --- availability and integrity
    o Popular in commercial systems
   Tamper resistance --- confidentiality
    o Popular in military systems
   Example: credit card system
    o Error check and crypto integrity check

Security Engineering (Chapter 6)                    18
               Faults and Failures
   What is resilience for?
   Confusing section…
   Direction of mistrust in protocol design
    o Server mistrusts clients --- require password
    o Client mistrusts server --- SSL
    o Client faces multiple unreliable servers --- reuse of
      Kerberos tickets is a feature, not a bug
    o Both mistrust each other --- more complicated
   Security renewability
    o Pay TV example
    o More generally, DRM

Security Engineering (Chapter 6)                              19
               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
    o For example, key in tamper-resistant
      hardware versus key in software
    o For example, access control at kernel level
      versus access control at application layer

Security Engineering (Chapter 6)             20
               Faults and Failures
 At what level is the redundancy?
 Hardware
    o Multiple CPUs, mirrored disks, RAID
    o Again, not designed for malicious attack
   Process group redundancy
    o Run multiple copies, vote on answer
 Backup/checkpoint
 Fallback
    o E.g., credit card “zip-zap” machine

Security Engineering (Chapter 6)                 21
               Faults and Failures
 At what level is the redundancy?
 Hardware redundancy, group redundancy,
  backup, fallback
    o Are all different
    o Each most useful against different threat
   Hardware redundancy
    o Cannot stop software attacks
   Fallback
    o Might open new attacks (credit cards), etc.

Security Engineering (Chapter 6)                    22
               Faults and Failures
 Bottom line
 Hard to protect availability
    o Hard to prevent denial of service
   Often, no optimal solution
    o Password lockout
    o Similar issues in many other contexts
 “A” is an important research area
 To date, far more research into “C” and “I”

Security Engineering (Chapter 6)              23
 “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.”

Security Engineering (Chapter 6)            24
    Needham’s view of naming
    1. Names exist to facilitate sharing
    2. Name resolution may be distributed
    3. Bad idea to limit number of possible names
    4. Global names are not as useful as you think
    5. Naming scheme should be flexible
    6. Names may serve other (security) purposes
    7. Incorrect names should be obvious
    8. Consistency is hard
    9. Simpler is usually better
    10. When to bind names?

Security Engineering (Chapter 6)                     25
    Names exist to facilitate sharing
    o     Names needed when data can change
    Name resolution may be distributed
    o     Naming includes all the problems of distributed
    o     Example: early online bank might use telephone
          number to authenticate user
    Bad idea to limit number of possible names
    o     Timely example?
    o     Credit card example

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

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

Security Engineering (Chapter 6)                        28
     Anderson considers 6 more issues
1.    Naming and identity
2.    Cultural assumptions
3.    Semantic content of names
4.    Uniqueness of names
5.    Stability of names
6.    Restrictions on use of names

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

Security Engineering (Chapter 6)                      30
       Semantic content of names
       Example
    o      To better target junk mail, bank linked all
           accounts to owner
    o      Caused bank account info for mistress to go
           to wife…
       Example
    o      Store card later changed to bank card
       Uniqueness of names
    o      Lots of people named “mark stamp”

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

Security Engineering (Chapter 6)                         32
 Alice as computer game player
 Alice as system admin
 Often treated as different principals
    o Then no link between them
 Or      could use RBAC

Security Engineering (Chapter 6)            33
 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
 Don’t try that with your credit card!

Security Engineering (Chapter 6)               34