Security Engineering (Chapter 6) 2
Intro Security Engineering: A Guide to
Building Dependable Distributed Systems, by Ross Anderson
Chapter 6: Distributed Systems Who is Ross Anderson?
o Professor at Cambridgeo Lots of real-world security work…o …for example, ATM machines
Security Engineering (Chapter 6) 3
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) 4
Distributed Systems Security
Ross Anderson’s viewo A broad perspectiveo Lots of anecdotes (not always clear)o Many familiar, real world examples
Read it!o Easy to read on one levelo Hard to read on another levelo Almost every sentence alludes to something
Lots of stuff on naming
Security Engineering (Chapter 6) 5
Chapters 1 Thru 5 Protocols
o Authentication, authorization, key establishment, etc., over a network
Access controlo Passwordso Authentication o Authorization
Cryptoo “Secret codes”
Security Engineering (Chapter 6) 6
Topics in Chapter 6 Concurrency
o Things happen at same timeo More generally, the order matters
Fault tolerance/failure recoveryo How to survive and recover?
Namingo About half of the chapter
Security Engineering (Chapter 6) 7
Concurrency Concurrent processes
o Run at the same timeo More broadly, order/timing matters
Many potential problemso Is data old or new?o Order of updateso Convergenceo Hard to agree on time
Security Engineering (Chapter 6) 8
Concurrency Concurrency-related security issues Replay attack
o A protocol issueo Password/hashed password exampleo Prevention?
Race conditiono Usually considered a software issueo Debit card exampleo Prevention?
Other?
Security Engineering (Chapter 6) 9
Concurrency 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 flawso Threads open to lots of problems
In generalo Not easy to deal with random/accidental
errorso Intelligent adversary is much more difficulto We try to minimize security problemso Cannot eliminate security problems
Security Engineering (Chapter 6) 10
Concurrency Is data old or new? Credit card example
o Verify all transactions with bank that issued card?
o Instead multiple levels of processingo Small versus big
System scales well since most transactions are small and local
Security Engineering (Chapter 6) 11
Concurrency Order of updates Suppose
o $500,000 credit to an accounto $400,000 debit to same accounto Does order of operations matter?o How to decide order in practice?
Credit card pre-authorizationo Debit in real time, credit is not
Passports --- order does not matter
Security Engineering (Chapter 6) 12
Concurrency Convergence Conventional wisdom is that distributed
system protocols should beo Atomic --- all or nothingo Consistent --- e.g., debits and credits balanceo Isolated --- serializableo 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) 13
Concurrency Time Why is this a security issue?
o Some protocols use time (Kerberos)o Cinderella attacko Time needed for synchronization
Security Engineering (Chapter 6) 14
Concurrency What time is it?
o Radio clockso Voting --- designed to withstand errors, not
malicious attackso Lamport time --- relative timeo Challenge-response instead of timestamp is
an example of relative timeo Network Time Protocol --- OK for some
applicationso RFC 2030 --- Simple Network Time Protocol,
“Security issues are not discussed in this memo.”
Security Engineering (Chapter 6) 15
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) 16
Faults and Failures “Classic” view of security: CIA
o Confidentiality --- no unauthorized reading
o Integrity --- no unauthorized writingo Availability --- self-explanatory
Fault tolerance and failure recoveryo These are issues of availability
Availability neglected by researchers o But most critical in practice
Security Engineering (Chapter 6) 17
Faults and Failures Classic fault tolerance methods
o Such as logs and lockingo Not designed to withstand malicious
attack What kinds of failures?
o Byzantine failure: n generals, t traitorso A model for malicious attacko If t < n/3 then traitors do not win
Security Engineering (Chapter 6) 18
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) 19
Faults and Failures What is resilience for? Confusing section… Direction of mistrust in protocol design
o Server mistrusts clients --- require passwordo Client mistrusts server --- SSLo Client faces multiple unreliable servers --- reuse of
Kerberos tickets is a feature, not a bugo Both mistrust each other --- more complicated
Security renewabilityo Pay TV exampleo More generally, DRM
Security Engineering (Chapter 6) 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 secureo For example, key in tamper-resistant
hardware versus key in softwareo For example, access control at kernel
level versus access control at application layer
Security Engineering (Chapter 6) 21
Faults and Failures At what level is the redundancy? Hardware
o Multiple CPUs, mirrored disks, RAIDo Again, not designed for malicious attack
Process group redundancyo Run multiple copies, vote on answer
Backup/checkpoint Fallback
o E.g., credit card “zip-zap” machine
Security Engineering (Chapter 6) 22
Faults and Failures At what level is the redundancy? Hardware redundancy, group
redundancy, backup, fallbacko Are all differento Each most useful against different threat
Hardware redundancyo Cannot stop software attacks
Fallbacko Might open new attacks (credit cards), etc.
Security Engineering (Chapter 6) 23
Faults and Failures Bottom line Hard to protect availability
o Hard to prevent denial of service Often, no optimal solution
o Password lockouto 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) 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.”
Security Engineering (Chapter 6) 25
Naming Needham’s view of naming
1. Names exist to facilitate sharing2. Name resolution may be distributed3. Bad idea to limit number of possible names4. Global names are not as useful as you
think5. Naming scheme should be flexible6. Names may serve other (security)
purposes7. Incorrect names should be obvious8. Consistency is hard9. Simpler is usually better10.When to bind names?
Security Engineering (Chapter 6) 26
Naming 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 systems
o Example: early online bank might use telephone number to authenticate user
Bad idea to limit number of possible nameso Timely example?o Credit card example
Security Engineering (Chapter 6) 27
Naming Global names are not as useful as you think
o For example, IPv6?o Name (e.g., at bank) must resolve to local nameo Intermediate name is at same scale and same level
of security as name we are trying to protecto One reason why banks not excited about PKI
Naming scheme should be flexibleo Private key tied to department?o Reorganization?
Names may serve other (security) purposeso Today’s name is tomorrow’s password
Security Engineering (Chapter 6) 28
Naming Incorrect names should be obvious
o Credit card checksum can be checked locallyo Crypto checksum must be checked remotely
Consistency is hardo Barcode example
Simpler is usually bettero Phone numbers more robust than IP addresseso SET designed as new credit card protocolo SET to be revived?
When to bind names?o Generally want to bind names lateo In security, probably want to bind early
Security Engineering (Chapter 6) 29
Naming Anderson considers 6 more issues1. Naming and identity2. Cultural assumptions3. Semantic content of names4. Uniqueness of names5. Stability of names6. Restrictions on use of names
Security Engineering (Chapter 6) 30
Naming 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 assumptionso Example: Names on scientific articleso National ID cards
Security Engineering (Chapter 6) 31
Naming 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…
Exampleo Store card later changed to bank card
Uniqueness of nameso Lots of people named “mark stamp”
Security Engineering (Chapter 6) 32
Naming Stability of names
o IPv6 addresses permanento Or not?
Restrictions on use of nameso Legal restrictions on use of SS numbero Medical databaseso Easy for police to trace who you called and
when, but much harder to tap the callso How does this translate to cyberspace?
Security Engineering (Chapter 6) 33
Naming Alice as computer game player Alice as system admin Often treated as different
principalso Then no link between them
Or could use RBAC
Top Related