Security Engineering Chapter 6 Distributed Systems Security Engineering

Security Engineering Chapter 6 Distributed Systems Security Engineering (Chapter 6) 1

Intro q Security Engineering: A Guide to Building Dependable Distributed Systems, by Ross Anderson q Chapter 6: Distributed Systems q 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 q Ross Anderson’s view o A broad perspective o Lots of anecdotes (not always clear) o Many familiar, real world examples q Read it! o Easy to read on one level o Hard to read on another level o Almost every sentence alludes to something q Lots of stuff on naming Security Engineering (Chapter 6) 4

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

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

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

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

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

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

Concurrency Order of updates q Suppose q o o q $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 o Debit in real time, credit is not q Passports --- order does not matter Security Engineering (Chapter 6) 11

Concurrency q q Convergence Conventional wisdom is that distributed system protocols should be o o q q 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 o Convergent --- if transactions stop, system will eventually reach a consistent state Security Engineering (Chapter 6) 12

Concurrency q Time q 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

Concurrency q 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 applications o RFC 2030 --- Simple Network Time Protocol, “Security issues are not discussed in this memo. ” Security Engineering (Chapter 6) 14

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

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

Faults and Failures q Classic fault tolerance methods o Such as logs and locking o Not designed to withstand malicious attack q 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 q How to deal with failures? o Fail-stop processors --- stop if problem is detected (issues? ) o Redundancy --- multiple copies (issues? ) q Replication --- availability and integrity o Popular in commercial systems q Tamper resistance --- confidentiality o Popular in military systems q Example: credit card system o Error check and crypto integrity check Security Engineering (Chapter 6) 18

Faults and Failures q q q 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 q Security renewability o Pay TV example o More generally, DRM Security Engineering (Chapter 6) 19

Faults and Failures q At what level is the redundancy? q In security in general… q 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? q Hardware q o Multiple CPUs, mirrored disks, RAID o Again, not designed for malicious attack q Process group redundancy o Run multiple copies, vote on answer Backup/checkpoint q Fallback q o E. g. , credit card “zip-zap” machine Security Engineering (Chapter 6) 21

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

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

Naming q “Naming is a minor, if troublesome, aspect of ordinary distributed systems, but it becomes surprisingly hard in security engineering. ” q Most of the problem due to “ignoring the established lessons of naming in ordinary distributed systems. ” Security Engineering (Chapter 6) 24

Naming q 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

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

Naming q Global names are not as useful as you think o For example, IPv 6? 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 o o Private key tied to department? Reorganization? o Today’s name is tomorrow’s password o o o q q Naming scheme should be flexible Names may serve other (security) purposes Security Engineering (Chapter 6) 27

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

Naming q 1. 2. 3. 4. 5. 6. 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 Security Engineering (Chapter 6) 29

Naming q Naming and identity o o q 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 o o Example: Names on scientific articles National ID cards Security Engineering (Chapter 6) 30

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

Naming q q Stability of names o o IPv 6 addresses permanent Or not? o o o 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? Restrictions on use of names o Security Engineering (Chapter 6) 32

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

Naming Businesses want to get paid q Governments want to identify people q Businesses want a credit card number q Governments want a passport number q Can show your passport to a million people q Don’t try that with your credit card! q Security Engineering (Chapter 6) 34