Security Engineering

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

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 Security Engineering (Chapter 6) 2

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) 3

4. Distributed Systems Security • Ross Anderson’s 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 Security Engineering (Chapter 6) 4

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

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 Security Engineering (Chapter 6) 6

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 Security Engineering (Chapter 6) 7

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? Security Engineering (Chapter 6) 8

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 Security Engineering (Chapter 6) 9

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 Security Engineering (Chapter 6) 10

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 Security Engineering (Chapter 6) 11

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 Security Engineering (Chapter 6) 12

13. Concurrency • Time • Why is this a security issue? • Some protocols use time (Kerberos) • Cinderella attack • Time needed for synchronization Security Engineering (Chapter 6) 13

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

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

16. Faults and Failures • One 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 Security Engineering (Chapter 6) 16

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 < n/3 then traitors do not win Security Engineering (Chapter 6) 17

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 Security Engineering (Chapter 6) 18

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 Security Engineering (Chapter 6) 19

20. Faults and Failures • At what level is the redundancy? • 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 Security Engineering (Chapter 6) 20

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 Security Engineering (Chapter 6) 21

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. Security Engineering (Chapter 6) 22

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, way more research into “C” and “I” Security Engineering (Chapter 6) 23

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) 24

25. Naming • Needham’s 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? Security Engineering (Chapter 6) 25

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 Security Engineering (Chapter 6) 26

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

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 Security Engineering (Chapter 6) 28

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 Security Engineering (Chapter 6) 29

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 Security Engineering (Chapter 6) 30

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

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? Security Engineering (Chapter 6) 32

33. Naming • Alice as computer game player • Alice as system admin • May be treated as different principals • Then no link between them • Or could use RBAC Security Engineering (Chapter 6) 33

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