CSE 484 / CSE M 584: Computer Security and Privacy Spring 2017 - - PowerPoint PPT Presentation

▶
cse 484 cse m 584 computer security and privacy
SMART_READER_LITE
LIVE PREVIEW

CSE 484 / CSE M 584: Computer Security and Privacy Spring 2017 - - PowerPoint PPT Presentation

Jun 05, 2023 49 likes •419 views

CSE 484 / CSE M 584: Computer Security and Privacy Spring 2017 Franziska (Franzi) Roesner franzi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, Yoshi Kohno, Ada Lerner, John Manferdelli, John Mitchell, Vitaly Shmatikov,

slide-1
SLIDE 1

CSE 484 / CSE M 584: Computer Security and Privacy

Spring 2017 Franziska (Franzi) Roesner franzi@cs.washington.edu

Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, Yoshi Kohno, Ada Lerner, John Manferdelli, John Mitchell, Vitaly Shmatikov, Bennet Yee, and many others for sample slides and materials ...

slide-2
SLIDE 2

Announcements / Answers

  • If you’re on the class mailing list, you should

have received a test email.

  • Late days: everyone in the group uses them

simultaneously

  • Example final projects: we will post some!
  • Prereqs…

3/29/17 CSE 484 / CSE M 584 - Spring 2017 2

slide-3
SLIDE 3

Prerequisites (CSE 484)

  • Required: Data Structures (CSE 326) or Data Abstractions

(CSE 332)

  • Required: Hardware/Software Interface (CSE 351) or

Machine Org and Assembly Language (CSE 378)

  • Assume: Working knowledge of C and assembly

– One of the labs will involve writing buffer overflow attacks in C – You must have detailed understanding of x86 architecture, stack layout, calling conventions, etc.

  • Assume: Working knowledge of software engineering tools

for Unix environments (gdb, etc)

  • Assume: Working knowledge of Java and JavaScript

3/29/17 CSE 484 / CSE M 584 - Spring 2017 3

slide-4
SLIDE 4

Prerequisites (CSE 484)

  • Strongly recommended: Computer Networks;

Operating Systems

– Will help provide deeper understanding of security mechanisms and where they fit in the big picture

  • Recommended: Complexity Theory;
Discrete

Math; Algorithms

– Will help with the more theoretical aspects of this course.

3/29/17 CSE 484 / CSE M 584 - Spring 2017 4

slide-5
SLIDE 5

Last Time

  • Importance of the security mindset

– Challenging design assumptions – Thinking like an attacker

  • There’s no such thing as perfect security

– But, attackers have limited resources – Make them pay unacceptable costs to succeed!

  • Defining security per context: identify assets,

adversaries, motivations, threats, vulnerabilities, risk, possible defenses

3/29/17 CSE 484 / CSE M 584 - Spring 2017 5

slide-6
SLIDE 6

SECURITY GOALS (“CIA”)

3/29/17 CSE 484 / CSE M 584 - Spring 2017 6

slide-7
SLIDE 7

Confidentiality (Privacy)

3/29/17 CSE 484 / CSE M 584 - Spring 2017 7

network

  • Confidentiality is concealment of information.

Eavesdropping, packet sniffing, illegal copying

slide-8
SLIDE 8

Integrity

3/29/17 CSE 484 / CSE M 584 - Spring 2017 8

network

  • Integrity is prevention of unauthorized changes.

Intercept messages, tamper, release again

slide-9
SLIDE 9

Authenticity

3/29/17 CSE 484 / CSE M 584 - Spring 2017 9

network

Unauthorized assumption of another’s identity

  • Authenticity is knowing who you’re talking to.
slide-10
SLIDE 10

Availability

3/29/17 CSE 484 / CSE M 584 - Spring 2017 10

network

  • Availability is ability to use information or resources.

Overwhelm or crash servers, disrupt infrastructure

slide-11
SLIDE 11

THREAT MODELING

3/29/17 CSE 484 / CSE M 584 - Spring 2017 11

slide-12
SLIDE 12

What Drives Attackers?

  • Money, theft, fun
  • Malice, revenge, wreak havoc
  • Curiosity, fun
  • Politics, terror

3/29/17 CSE 484 / CSE M 584 - Spring 2017 12

slide-13
SLIDE 13

Threat Modeling (Security Reviews)

  • Assets: What are we trying to protect? How

valuable are those assets?

  • Adversaries: Who might try to attack, and why?
  • Vulnerabilities: How might the system be weak?
  • Threats: What actions might an adversary take to

exploit vulnerabilities?

  • Risk: How important are assets? How likely is

exploit?

  • Possible Defenses

3/29/17 CSE 484 / CSE M 584 - Spring 2017 13

slide-14
SLIDE 14

Example: Electronic Voting

  • Popular replacement to

traditional paper ballots

3/29/17 CSE 484 / CSE M 584 - Spring 2017 14

slide-15
SLIDE 15

Pre-Election

3/29/17 CSE 484 / CSE M 584 - Spring 2017 15

Ballot definition file

Pre-election: Poll workers load “ballot definition files” on voting machine.

Poll worker

slide-16
SLIDE 16

Active Voting

3/29/17 CSE 484 / CSE M 584 - Spring 2017 16

Voter token Voter token Interactively vote Ballot definition file

Active voting: Voters obtain single-use tokens from poll workers. Voters use tokens to activate machines and vote.

Voter Poll worker

slide-17
SLIDE 17

Active Voting

3/29/17 CSE 484 / CSE M 584 - Spring 2017 17

Encrypted votes Voter token Voter token Interactively vote Ballot definition file

Active voting: Votes encrypted and stored. Voter token canceled.

Voter Poll worker

slide-18
SLIDE 18

Post-Election

3/29/17 CSE 484 / CSE M 584 - Spring 2017 18

si.edu si.edu

Voter token Tabulator Voter token Interactively vote Ballot definition file

Post-election: Stored votes transported to tabulation center.

Encrypted votes Recorded votes

Voter Poll worker

slide-19
SLIDE 19

Security and E-Voting (Simplified)

  • Functionality goals:

– Easy to use, reduce mistakes/confusion

  • Security goals:

– Adversary should not be able to tamper with the election outcome

  • By changing votes (integrity)
  • By voting on behalf of someone (authenticity)
  • By denying voters the right to vote (availability)

– Adversary should not be able to figure out how voters vote (confidentiality)

3/29/17 CSE 484 / CSE M 584 - Spring 2017 19

slide-20
SLIDE 20

Can You Spot Any Potential Issues?

3/29/17 CSE 484 / CSE M 584 - Spring 2017 20

si.edu si.edu

Voter token Tabulator Voter token Interactively vote Ballot definition file Encrypted votes Recorded votes

Voter Poll worker

slide-21
SLIDE 21

Potential Adversaries

  • Voters
  • Election officials
  • Employees of voting machine manufacturer

– Software/hardware engineers – Maintenance people

  • Other engineers

– Makers of hardware – Makers of underlying software or add-on components – Makers of compiler

  • ...
  • Or any combination of the above

3/29/17 CSE 484 / CSE M 584 - Spring 2017 21

slide-22
SLIDE 22

What Software is Running?

3/29/17 CSE 484 / CSE M 584 - Spring 2017 22

Problem: An adversary (e.g., a poll worker, software developer, or company representative) able to control the software or the underlying hardware could do whatever he or she wanted.

slide-23
SLIDE 23

3/29/17 CSE 484 / CSE M 584 - Spring 2017 23

slide-24
SLIDE 24

Bad file Tabulator Voter token Interactively vote Ballot definition file Encrypted votes

Problem: Ballot definition files are not authenticated. Example attack: A malicious poll worker could modify ballot definition files so that votes cast for “Mickey Mouse” are recorded for “Donald Duck.”

Recorded votes

Voter Poll worker

slide-25
SLIDE 25

Voter token Interactively vote Ballot definition file

Problem: Smartcards can perform cryptographic operations. But there is no authentication from voter token to terminal. Example attack: A regular voter could make his or her own voter token and vote multiple times.

Tabulator Encrypted votes Recorded votes

Voter Poll worker

slide-26
SLIDE 26

Ballot definition file Tabulator Encrypted votes

Problem: Encryption key (“F2654hD4”) hard-coded into the software since (at least) 1998. Votes stored in the order cast. Example attack: A poll worker could determine how voters vote.

Recorded votes Voter Voter token Interactively vote

Voter Poll worker

slide-27
SLIDE 27

Ballot definition file Tabulator Encrypted votes

Problem: When votes transmitted to tabulator over the Internet

  • r a dialup connection, they are decrypted first; the cleartext

results are sent the the tabulator. Example attack: A sophisticated outsider could determine how voters vote.

Voter token Interactively vote Recorded votes

Voter Poll worker

slide-28
SLIDE 28

TOWARDS DEFENSES

3/29/17 CSE 484 / CSE M 584 - Spring 2017 28

slide-29
SLIDE 29

Approaches to Security

  • Prevention

– Stop an attack

  • Detection

– Detect an ongoing or past attack

  • Response

– Respond to attacks

  • The threat of a response may be enough to

deter some attackers

3/29/17 CSE 484 / CSE M 584 - Spring 2017 29

slide-30
SLIDE 30

Whole System is Critical

  • Securing a system involves a whole-system view

– Cryptography – Implementation – People – Physical security – Everything in between

  • This is because “security is only as strong as the

weakest link,” and security can fail in many places

– No reason to attack the strongest part of a system if you can walk right around it.

3/29/17 CSE 484 / CSE M 584 - Spring 2017 30

slide-31
SLIDE 31

Whole System is Critical

  • Securing a system involves a whole-system view

– Cryptography – Implementation – People – Physical security – Everything in between

  • This is because “security is only as strong as the

weakest link,” and security can fail in many places

– No reason to attack the strongest part of a system if you can walk right around it.

3/29/17 CSE 484 / CSE M 584 - Spring 2017 31

slide-32
SLIDE 32

Whole System is Critical

  • Securing a system involves a whole-system view

– Cryptography – Implementation – People – Physical security – Everything in between

  • This is because “security is only as strong as the

weakest link,” and security can fail in many places

– No reason to attack the strongest part of a system if you can walk right around it.

3/29/17 CSE 484 / CSE M 584 - Spring 2017 32

slide-33
SLIDE 33

Attacker’s Asymmetric Advantage

3/29/17 CSE 484 / CSE M 584 - Spring 2017 33

slide-34
SLIDE 34

Attacker’s Asymmetric Advantage

3/29/17 CSE 484 / CSE M 584 - Spring 2017 34

  • Attacker only needs to win in one place
  • Defender’s response: Defense in depth
slide-35
SLIDE 35

From Policy to Implementation

  • After you’ve figured out what security means to

your application, there are still challenges:

– Requirements bugs

  • Incorrect or problematic goals

– Design bugs

  • Poor use of cryptography
  • Poor sources of randomness
  • ...

– Implementation bugs

  • Buffer overflow attacks
  • ...

– Is the system usable?

3/29/17 CSE 484 / CSE M 584 - Spring 2017 35

Don’t forget the users! They are a critical component!

slide-36
SLIDE 36

Many Participants

  • Many parties involved

– System developers – Companies deploying the system – The end users – The adversaries (possibly one of the above)

  • Different parties have different goals

– System developers and companies may wish to optimize cost – End users may desire security, privacy, and usability – But the relationship between these goals is quite complex (will customers choose not to buy the product if it is not secure?)

3/29/17 CSE 484 / CSE M 584 - Spring 2017 36

slide-37
SLIDE 37

Better News

  • There are a lot of defense mechanisms

– We’ll study some, but by no means all, in this course

  • It’s important to understand their limitations

– “If you think cryptography will solve your problem, then you don’t understand cryptography… and you don’t understand your problem” -- Bruce Schneier

3/29/17 CSE 484 / CSE M 584 - Spring 2017 37