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

Security Engineering (Chapter 6) 1

Security Engineering

Chapter 6Distributed Systems


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


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


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


Chapters 1 Thru 5 Protocols

o Authentication, authorization, key establishment, etc., over a network

Access controlo Passwordso Authentication o Authorization

Cryptoo “Secret codes”


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


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


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?


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


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


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


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


Concurrency Time Why is this a security issue?

o Some protocols use time (Kerberos)o Cinderella attacko Time needed for synchronization


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.”


Faults and Failures Fault

o May cause an error Error

o Incorrect state Failure

o Deviation from correct behavior Fault Error Failure


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


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


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


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


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


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


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.


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”


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.”


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?


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


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


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

http://news.com.com/2100-1017-225723.html


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


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


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”


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?


Naming Alice as computer game player Alice as system admin Often treated as different

principalso Then no link between them

Or could use RBAC


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!

Documents

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