1 of 87

Introduction and Security Principles

CS 161 Summer 2023 - Lecture 1

Computer Science 161

2 of 87

First Half of Today: Introductions and Logistics

  • Staff introductions
  • Course overview: What will you learn in this class?
  • Course logistics
    • Lectures, discussions, office hours, and exams
    • Resources and communication platforms
    • Collaboration and academic honesty
    • DSP and extenuating circumstances
    • Stress management and mental health
    • Ethics
    • Case studies and blue slides
  • What is security? Why is it important?

2

Computer Science 161

3 of 87

Staff Introductions

3

Computer Science 161

4 of 87

Who Am I? Madison (she/hers)

  • 4th time teaching CS 161
    • Have also taught CS61C!
  • Research focus
    • CS Education
    • Cyber systems exploitation
  • My name is technically Madison, but I go by Maddie too
    • Please use whichever name is more comfortable for you! I have no preference
    • No “professor”, “Mrs.”, “Ms.”, “Ma’am”, etc. I’m not paid enough for that. I’m just an Instructor/Lecturer!

4

Computer Science 161

5 of 87

Who Am I? Ana (she/hers)

  • 4th time teaching CS 161
  • Doing a 5th Year Master’s
    • Advised by Prof. Miki Lustig
    • Computer Vision for MRI
    • Very much unrelated to 161 🙃
  • Like Maddie, please just call me Ana :)

5

Computer Science 161

6 of 87

Our team of talented staff!

6

Abhi Ganesh

he/him

Andrei Tan

he/him

Derek Awender

he/him

Eric Huang

he/him

Medhaav Mahesh

he/him

Henry Zeng

he/him

Minjune Kim

he/him

Kenneth Lien

he/him

Lawrence Shieh

he/him

Levy Deng

he/him

Hari Vallabhaneni

he/him

Imran Khaliq-Baporia

he/him

Nicholas Ngai

he/him

Phillip Chen

he/him

Pradyun Kumar

he/him

Sai Achalla

he/him

Sora Kanosue

he/him

Vibha Tantry

she/hers

Vron Vance

they/them

Ryan Cottone

he/him

Lyna Jiang

she/hers

EvanBot

any/all

Trader Joe’s, likes writing

cryptography fan

El Psy Congroo

saw Hachiko at 5am

Computer Science 161

7 of 87

Course Overview

7

Computer Science 161

8 of 87

Learning Objectives

  • How to think adversarially about computer systems
  • How to assess threats for their significance
  • How to build computer systems with robust security properties
  • How to gauge the protections and limitations provided by today's technology
  • How attacks work in practice

  • What mistakes not to make!

8

Computer Science 161

9 of 87

Course Outline

  • Introduction to Security
    • What are some general philosophies when thinking about security?
  • Memory Safety
    • How do attackers exploit insecure software? How do we defend against these attacks?
  • Cryptography
    • How do we securely send information over an insecure channel?
  • Web Security
    • What are some attacks on the web, and how do we defend against them?
  • Network Security
    • What are some attacks on the Internet, and how do we defend against them?
  • Miscellaneous Topics
    • Useful, interesting, or fun applications of topics. Maybe some guest lectures!

9

Computer Science 161

10 of 87

Extra Tools and Skills

  • Some extra non-security-related skills you can take away from this class:
  • Memory safety
    • x86 assembly: A commonly-used assembly language
    • Using GDB: Debugging C code
  • Cryptography
    • Becoming a better consumer: Be able to analyze security products and pick the right security tools for your software
  • Web Security
    • Software engineering: Understanding how websites are built and how your web browser interacts with remote web servers (CS 169 preview)
  • Network Security
    • Networking: How the Internet works (CS 168 preview)

10

Computer Science 161

11 of 87

Prerequisites

  • CS 61B: Ability to work with large and complex codebases, data structures
    • Relevant for Project 2 (500–1000 lines of Go code)
  • CS 61C: Familiarity with low-level memory layouts and assembly
    • We’ll have a lecture reviewing all the 61C material you need to succeed
    • Relevant for the memory safety unit (Project 1, first four weeks of class only)
  • CS 70: Familiarity with basic mathematical notation and proof structures
    • Relevant for the cryptography unit
    • We’ll review CS 70 material as we encounter it during the cryptography lectures
  • An ability to pick up new programming languages quickly
    • Project 2 will be in Go

11

Computer Science 161

12 of 87

Course Logistics

12

Computer Science 161

13 of 87

Enrollment

  • Course staff does not control enrollment; we have to follow department policy
  • No waitlist at the moment
  • Summer sessions contact information can be found here: https://ssall.zendesk.com/

13

Computer Science 161

14 of 87

Course Structure: Lectures

  • You are here!
  • Monday/Tuesday/Wednesday/Thursday, 12:30–2 PM PT
  • Attendance is not taken

14

In-person

Synchronous online

Asynchronous online

  • Live lectures in Evans 10
  • Live lectures over Zoom
  • Lecture recordings posted on the website

Computer Science 161

15 of 87

Course Structure: Discussions

  • Smaller sections (typically led by a TA) to practice with material
  • Discussion schedule available at https://su23.cs161.org/calendar
  • All discussions start this Wednesday and will be held twice a week
    • Monday/Tuesday discussions cover the same content; Wednesday/Thursday discussions similarly will cover the same content
  • You can attend any discussion section you want (no need to enroll in a section)
  • Attendance is not taken

15

In-person

Synchronous online

Asynchronous online

  • Discussion rooms posted on Ed/calendar
  • Discussion zoom links posted on Ed
  • Some sections will be recorded
  • Discussion walkthrough videos will be posted

Computer Science 161

16 of 87

Course Structure: Office Hours

  • Space to ask questions about content, get help with projects, raise concerns with the course, etc. with a TA or instructor
  • Instructor only office hours will be held on Fridays (to discuss anything privately with the instructors, etc), but we will be floating around regular office hours as well as needed
  • Office hours schedule available at https://su23.cs161.org/calendar
  • Office hours queue at https://oh.cs161.org/
  • All office hours start today
  • All office hours will be available both in-person and online

16

Computer Science 161

17 of 87

Course Structure: Exams

  • Midterm: Thursday, July 13, 2023, 5–7pm PT
  • Final: Wednesday, August 9, 2023, 4–7pm PT
  • Remote exam offered only at the same time as the regular exam
    • This class is offered officially in-person.
    • Remote exams are opt-in. If you are not comfortable/do not consent to recorded zoom proctoring, please come in person.
    • We reserve the right to revoke remote exam privileges in instances of misconduct.
  • Alternate exam offered in-person only, immediately after the regular exam
  • Forms to request online/alternate exams will be released closer to the exam

17

Computer Science 161

18 of 87

Resources

  • Textbook: https://textbook.cs161.org/
    • Free! There’s no textbook you need to pay for.
    • Readings are optional, but past students have said the textbook is helpful
  • Course website: https://su23.cs161.org/
    • Course schedule, lecture slides, assigned readings, and other resources are all posted here

18

Computer Science 161

19 of 87

Platforms

  • Ed
    • Discussion forum (replacement for Piazza)
    • Course-related communication should take place in Ed or happen in office hours
    • For private matters, you can make a private post
    • Please don’t post publicly about project spoilers!
  • Gradescope
    • All assignments are submitted and graded on Gradescope
  • Email
    • cs161-staff@berkeley.edu for private matters
      • Staff with email access are tagged as “Staff Email Access” on the staff page of the website.
    • Ed response is faster, but staff will monitor the email if you’re more comfortable with that

19

Computer Science 161

20 of 87

Grading Structure

  • Homework: 10%
    • Completed individually
    • For now, 7 homeworks in total, weighted equally
      • Some homeworks will involve hands-on lab components
    • Gradescope with instant feedback: You can keep trying until you get the answer right
  • Projects: 40%
    • P1 = 10%, P2 = 20%, P3 = 10%
    • Completed individually or in groups of 2
  • Midterm: 20%
  • Final: 30%

20

Computer Science 161

21 of 87

Class Policies: Extensions

  • We do not have slip days or assignment drops in this course!
  • However, you can request extensions on any assignment for any reason:
    • Extensions form linked at the top of the website, will be live soon
    • Most extensions ≤3 days will be automatically approved if submitted before the deadline
    • Longer extensions may be approved, but we’ll need to check in first to make sure you’re on pace to finish the class
  • It is okay to request an extension if things come up! We’re here to support you!
    • Life happens.
    • You can always request an extension for any reason (e.g. stress, other classes, etc.)
    • We want to keep deadlines to make sure you’re on track to finish, while reducing the associated stress

21

Computer Science 161

22 of 87

Class Policies: DSP

  • Disabled Students’ Program (DSP)
    • There’s a variety of accommodations UC Berkeley can help us set up for you in this class
    • https://dsp.berkeley.edu/
  • Are you facing barriers in school due to a disability?
    • Apply to DSP!
    • If you are already registered with DSP, please make sure you have submitted your letter of accommodation to us & look out for an onboarding email in the coming week
    • We maintain proper access controls on this information: Only instructors, course managers, head TAs, and logistics TAs can access any DSP-related info. These are noted on the staff page with “DSP Data Access” tags
  • Our goal is to teach you the material in our course. The more accessible we can make it, the better.

22

Computer Science 161

23 of 87

Class Policies: Collaboration

  • Asking questions and helping others is encouraged
    • Discussing course topics with other is welcome!
    • The class is graded using grading bins, so you aren’t graded against your peers
  • Limits of collaboration
    • Don’t share solutions with each other (except project partners)
    • You should never see or have possession of anyone else’s solutions—including from past semesters

23

Computer Science 161

24 of 87

Class Policies: Academic Honesty

  • We’re here to help! There are plenty of staff and resources available for you
    • You can always talk to a staff member if you’re feeling stressed or tempted to cheat
  • Academic dishonesty policies
    • At minimum, the student will receive negative points on the assignment
      • Example: If the midterm is worth 150 points, the student will receive a score of -150 on the midterm.
    • The student will be referred to the Center for Student Conduct
      • CSC often doesn’t care that much about first-time cases! They are there to make sure a student doesn’t make the same mistake a second time.
    • If you take the class honestly, you don’t need to worry about these!

24

Computer Science 161

25 of 87

Class Policies: Academic Honesty

  • As a computer security class, we view potential cheaters as “attackers.”
  • Our threat model assumes “rational” attackers.
    • A rational attacker will only launch an attacker if (expected benefit) > (expected cost)
      • (expected cost) = (cost of launching attack) + (cost of getting caught) * (probability of getting caught)
  • Two-fold approach to academic integrity:
    • Detection: Use our tools to analyze and detect instance of academic dishonesty.
      • You will learn that “security through obscurity” is bad, but obscurity can help. We have ways.
    • Response: At minimum, you will receive negative points on the assignment.

25

Computer Science 161

26 of 87

Ethics

  • In this class, you will learn a lot about attacks out of necessity
    • To be able to defend against the attacker, you must learn the techniques that attackers use
  • It is usually okay to break into your own systems
    • This is a great way to evaluate your own systems
  • It is usually okay to break into someone else’s systems with their explicit permission
  • It is grossly unethical and exceedingly criminal to break into someone else’s systems without their permission

26

Computer Science 161

27 of 87

Stress Management and Mental Health

  • We want to reduce your stress where we can
    • Project 2 (mid-semester) is going to be the most intensive part of this class, but we’ve made things lighter towards the end (when every other class has stuff due)
  • Your health is more important than this course
  • If you feel overwhelmed, there are options
    • Academically: Ask on Ed, talk to staff in office hours, set up a meeting with staff to make a plan for your success this semester
    • Non-academic:

27

Computer Science 161

28 of 87

Course Climate

  • Please respect each other! This includes but is not limited to: using the preferred pronouns of your fellow students & staff members, posting appropriate content on Ed, respecting the identities of others, being kind, etc.
  • Staff reserves the right to lower your grade for exceptionally rude or disrespectful behavior. You do not need to be concerned with this policy if you treat others with even the bare minimum of respect.
  • If you feel as though you have been impacted by a poor course climate, we have an anonymous feedback form to submit concerns to.

28

Computer Science 161

29 of 87

Case Studies and Blue Slides

  • Security is often best taught through real-world case studies and stories
    • Lectures will sometimes use real-world examples to demonstrate concepts
    • Slides with a blue background are case study slides
  • Content on blue slides are not tested on exams
    • You do not need to remember the exact details of the story
  • Some blue slides will end in a takeaway that describes the moral of the story
    • You do need to understand the takeaway from the story

29

Computer Science 161

30 of 87

What is security?

30

Computer Science 161

31 of 87

What is security?

Enforcing a desired property in the presence of an attacker

data confidentiality

user privacy

data and computation integrity

authentication

availability

31

Computer Science 161

32 of 87

Why is security important?

  • It is important for our
    • physical safety
    • confidentiality/privacy
    • functionality
    • protecting our assets
    • successful business
    • a country’s economy and safety
    • and so on…

32

Computer Science 161

33 of 87

Why is security important?

  • Consider: Physical Safety

33

FBI probe of alleged plane hack sparks worries over flight safety

Drew Harwell

May 18, 2015

Pacemaker hack can kill via laptop

Jeremy Kirk

October 21, 2012

Computer Science 161

34 of 87

Why is security important?

  • Consider: Privacy/Confidentiality

34

In 2020, there were over 1001 breaches, affecting the data of 155,000,000 individuals

Computer Science 161

35 of 87

Why is security important?

  • Consider: National security

35

America’s Electric Grid Has a Vulnerable Back Door—and Russia Walked Through It

Rebecca Smith and Rob Barry

January 10, 2019

A Wall Street Journal reconstruction of the worst known hack into the nation’s power system reveals attacks on hundreds of small contractors

Computer Science 161

36 of 87

What is hackable?

  • Everything!
    • Especially things connected to the Internet
    • Assume that every system is a target
    • A casino was hacked because a fish-tank thermometer was hacked within the network

36

For the First Time, Hackers Have Used a Refrigerator to Attack Businesses

Julie Bort

January 17, 2014

Computer Science 161

37 of 87

Security Principles

Textbook Chapter 1

37

Computer Science 161

38 of 87

Second Half of Today: Security Principles

  • Security principles
    • Know your threat model
    • Consider human factors
    • Security is economics
    • Detect if you can’t prevent
    • Defense in depth
    • Least privilege
    • Separation of responsibility
    • Ensure complete mediation
    • Don’t rely on security through obscurity
    • Use fail-safe defaults
    • Design in security from the start

38

Computer Science 161

39 of 87

Know Your Threat Model

Textbook Chapter 1.1 & 1.12

39

Computer Science 161

40 of 87

The Parable of the Bear Race

“I don’t have to outrun the bear. I just have to outrun you.”�Takeaway: You often just need to have “good enough” defense to make attackers turn somewhere else.

40

Reminder: blue slides are case studies. Remember the takeaway, not the story!

Computer Science 161

41 of 87

Security Principle: Know Your Threat Model

  • Threat model: A model of who your attacker is and what resources they have
  • It all comes down to people: The attackers
    • No attackers = No problem!
    • One of the best ways to counter an attacker is to attack their reasons
  • Why do people attack systems?
    • Money
    • Politics
    • Retaliation
    • Fun, watching the world burn

41

Computer Science 161

42 of 87

Security Principle: Know Your Threat Model

  • Consider: Personal security
  • Who and why might someone attack you?
    • Criminals might attack you for money
    • Teenagers might attack you for laughs or to win online games
    • Governments might spy on you to collect intelligence
    • Intimate partners might spy on you
      • This is a surprisingly dangerous threat model!

42

Computer Science 161

43 of 87

The National Security Agency (NSA)

  • Stated purpose: To collect information to protect US national security
  • Since its founding in 1952, the NSA has:
    • Decoded secret enemy communications in wars
    • Spied on people in the US and other countries (sometimes legally, sometimes illegally)
    • Participated in security research and helped develop security standards
    • Developed secret techniques for surveillance and cyberattacks
  • The NSA are an essential part of computer security
    • We’ll see many stories with the NSA this semester

43

Computer Science 161

44 of 87

Threat Model: Common Assumptions for Attackers

  • Assume the attacker…
    • Can interact with systems without notice
    • Knows general information about systems (operating systems, vulnerabilities in software, usually patterns of activity, etc.)
    • Can get lucky
      • If an attack only succeeds 1/1,000,000 times, the attacker will try 1,000,000 times!
    • May coordinate complex attacks across different systems
    • Has the resources required to mount the attack
      • This can be tricky depending on who your threat model is
    • Can and will obtain privileges if possible

44

Computer Science 161

45 of 87

Trusted Computing Base

  • Trusted computing base (TCB): The components of a system that security relies upon
  • Properties of the TCB:
    • Correctness
    • Completeness (can’t be bypassed)
    • Security (can’t be tampered with)
  • Generally made to be as small as possible
    • A smaller, simpler TCB is easier to write and audit.
    • KISS principle: Keep It Simple, Stupid

45

Computer Science 161

46 of 87

TCB example

Goal: only authorized users are allowed to log into a system using SSH

What is the TCB:

  • SSH daemon
  • Operating system
  • CPU

Examples of what is not in the TCB:

  • A video streaming application installed on the same machine

46

Computer Science 161

47 of 87

Consider Human Factors

Textbook Chapter 1.2

47

Computer Science 161

48 of 87

Warning Dialogs

48

When you send information to the Internet, it might be possible for others to see that information. Do you want to continue?

In the future, do not show this message.

Yes

No

Computer Science 161

49 of 87

Warning Dialogs

49

When you see a dialog box like this, click ‘Yes’ to make it go away. If available, click the checkbox first to avoid being bothered by it again.

Yes

No

In the future, do not show this message.

Computer Science 161

50 of 87

Warning Dialogs

50

Examine Certificate...

Accept this certificate permanently

Accept this certificate temporarily for this session

Do not accept this certificate and do not connect to this Web site

Website Certified by an Unknown Authority

Unable to verify the identity of svn.xiph.org as a trusted site.

Possible reasons for this error:

- Your browser does not recognise the Certificate Authority that issued the site’s certificate.

- The site’s certificate is incomplete due to a server misconfiguration.

- You are connected to a site pretending to be svn.xiph.org, possibly to obtain your confidential information.

Please notify the site’s webmaster about this problem.

Before accepting this certificate, you should examine this site’s certificate carefully. Are you willing to accept this certificate for the purpose of identifying the Web site svn.xiph.org?

OK

Cancel

Computer Science 161

51 of 87

Warning Dialogs

51

View Incomprehensible Information

The presence of warning dialogs often represent a failure: How is the user supposed to know what to do?�Takeaway: Consider human factors

Unable to verify the identity of svn.xiph.org as a trusted site.

Blah blah geekspeak geekspeak geekspeak.

Before accepting this certificate, your browser can display a second dialog full of incomprehensible information. Do you want to view this dialog?

Make this message go away permanently

Make this message go away temporarily for this session

Stop doing what you were trying to do

OK

Cancel

Computer Science 161

52 of 87

Security Principle: Consider Human Factors

  • It all comes down to people: The users
    • Users like convenience (ease of use)
    • If a security system is unusable, it will be unused
    • Users will find way to subvert security systems if it makes their lives easier
  • It all comes down to people: The programmers
    • Programmers make mistakes
    • Programmers use tools that allow them to make mistakes (e.g. C and C++)
  • It all comes down to people: Everyone else
    • Social engineering attacks exploit other people’s trust and access for personal gain
  • Consider the tools presented to users, and make them fool-proof

52

Physical security keys use the fact that humans are trained to safeguard keys

Computer Science 161

53 of 87

Security is Economics

Textbook Chapter 1.3

53

Computer Science 161

54 of 87

Physical Safes

Takeaway: Security is economics

  • We want our safes to stop people from breaking in, so let’s measure them by how long it takes an expert to break into one:

54

TL-15 ($3,000)�15 minutes with common tools

TL-30 ($4,500)�30 minutes with common tools

TRTL-30 ($10,000)�30 minutes with common tools and a cutting torch

TXTL-60 (>$50,000)�60 minutes with common tools, a cutting torch, and up to 4 oz of explosives

Computer Science 161

55 of 87

Security Principle: Security is Economics

  • Cost/benefit analyses often appear in security: The expected benefit of your defense should be proportional to the expected cost of attack
    • More security (usually) costs more
    • If the attack costs more than the reward, the attacker probably won’t do it
  • Example: You don’t put a $10 lock on a $1 item…
    • … unless a $1 item can be used to attack something even more valuable
  • Example: You have a brand-new, undiscovered attack that will work on anybody’s computer. You wouldn’t expose it on a random civilian
    • iPhone security vulnerabilities are often sold for ~$1M on the market, so it’s probably safe to use an iPhone on a hostile network if you aren’t a $1M target

55

Computer Science 161

56 of 87

Detect If You Can’t Prevent

Textbook Chapter 1.4

56

Computer Science 161

57 of 87

Burglar Alarms

  • Security companies are supposed to detect home break-ins
    • Problem: Too many false alarms. Many alarms go unanswered
    • Placing a sign helps deter burglars from entering at risk of being caught…
      • … even if you don’t have an alarm installed!
  • Takeway: Prevent attacks when you can, but detect them if you can’t

57

Computer Science 161

58 of 87

Security Principle: Detect if You Can’t Prevent

  • Deterrence: Stop the attack before it happens
  • Prevention: Stop the attack as it happens
  • Detection: Learn that there was an attack (after it happened)
    • If you can’t stop the attack from happening, you should at least be able to know that the attack has happened.
  • Response: Do something about the attack (after it happened)
    • Once you know the attack happened, you should respond
    • Detection without response is pointless!

58

Computer Science 161

59 of 87

Response: Mitigation and Recovery

  • Assume that bad things will happen! You should plan security in way that lets you to get back to a working state.
  • Example: Earthquakes
    • Have resources for 1 week of staying put
    • Have resources to travel 50 miles from my current location
  • Example: Ransomware
    • Keep offsite backups!
    • If your computer and house catch on fire, it should be no big deal.

59

Computer Science 161

60 of 87

Detection but no Response

  • Bitcoin transactions are irreversible. If you are hacked, you can never recover your Bitcoins.
    • $68M stolen from NiceHash exchange in December 2017
    • Four multi-million-dollar attacks on Ethereum in July 2018
    • Coinbase: One detected theft per day
  • Takeaway: Prevention is great, but you must not only depend on prevention; you must also respond

60

Hacked Bitcoin Exchange Says Users May Share $68 Million Loss

Lulu Yilun Chen and Yuji Nakamura

August 5, 2016

Computer Science 161

61 of 87

Defense in Depth

Textbook Chapter 1.5

61

Computer Science 161

62 of 87

The Theodosian Walls of Constantinople

  • The ancient capital of the Byzantine empire had a wall…
    • Well, they had a moat…
    • then a wall…
    • then a depression…
    • … and then an even bigger wall
  • It also had towers to rain fire and arrows upon the enemy…
  • Takeaway: Defense in depth

62

Computer Science 161

63 of 87

Security Principle: Defense in Depth

  • Multiple types of defenses should be layered together
  • An attacker should have to breach all defenses to successfully attack a system
  • However, consider security is economics
    • Defenses are not free.
    • Defenses are often less than the sum of their parts

63

Computer Science 161

64 of 87

Least Privilege

Textbook Chapter 1.6

64

Computer Science 161

65 of 87

uTorrent

65

Computer Science 161

66 of 87

uTorrent

66

Computer Science 161

67 of 87

uTorrent

  • What was this program able to do?
    • Leak your files
    • Delete your files
    • Send spam
    • Run another malicious program
  • What does this program need to be able to do?
    • Access the screen
    • Manage some files (but not all files)
    • Make some Internet connections (but not all Internet connections)
  • Takeaway: Least privilege

67

Computer Science 161

68 of 87

Security Principle: Least Privilege

  • Consider what permissions a entity or program needs to be able to do its job correctly
    • If you grant unnecessary permissions, a malicious or hacked program could use those permissions against you

68

Computer Science 161

69 of 87

Separation of Responsibility

Textbook Chapter 1.7

69

Computer Science 161

70 of 87

Welcome to a Nuclear Bunker

70

Computer Science 161

71 of 87

Security Principle: Separation of Responsibility

  • If you need to have a privilege, consider requiring multiple parties to work together (collude) to exercise it
    • It’s much more likely for a single party to be malicious than for all multiple parties to be malicious and collude with one another

71

Computer Science 161

72 of 87

Ensure Complete Mediation

Textbook Chapter 1.8 & 1.13

72

Computer Science 161

73 of 87

Spot the Issue

73

Computer Science 161

74 of 87

Security Principle: Ensure Complete Mediation

  • Ensure that every access point is monitored and protected
  • Reference monitor: Single point through which all access must occur
    • Example: A network firewall, airport security, the doors to the dorms
  • Desired properties of reference monitors:
    • Correctness
    • Completeness (can’t be bypassed)
    • Security (can’t be tampered with)
    • Should be part of the TCB

74

The cars drove around the barrier

Computer Science 161

75 of 87

Time-of-Check to Time-of-Use

  • A common failure of ensuring complete mediation involving race conditions
  • Consider the following code:

75

procedure withdrawal(w)

// contact central server to get balance

1. let b := balance

2. if b < w, abort

// contact server to set balance

3. set balance := b - w

4. give w dollars to user

Suppose you have $5 in your account. How can you trick this system into giving you more than $5?

Computer Science 161

76 of 87

Time-of-Check to Time-of-Use

76

withdrawal(5)�1. let b := balance�2. if b < w, abort

withdrawal(5)�1. let b := balance�2. if b < w, abort�

// contact server to set balance�3. set balance := b - w��4. give w dollars to user

// contact server to set balance�3. set balance := b - w��4. give w dollars to user

The machine gives you $10!

Time

Computer Science 161

77 of 87

Don’t Rely on Security Through Obscurity

Textbook Chapter 1.9

77

Computer Science 161

78 of 87

Accident on Motorway

78

Here’s the hidden computer inside the sign.

Here’s a highway sign.

Here’s the control panel. Most signs use the default password, DOTS.

Computer Science 161

79 of 87

Caution! Zombies Ahead!!!

Note: Do not ever do this. Yes, some former CS 161 students did it once.

79

Computer Science 161

80 of 87

Trapped in Sign Factory! Send Help!

Takeaway: Shannon’s maxim/Don’t rely on security through obscurity

80

Computer Science 161

81 of 87

Security Principle: Shannon’s Maxim

  • Shannon’s maxim: “The enemy knows the system”
  • You should never rely on obscurity as part of your security. Always assume that the attacker knows every detail about the system you are working with (algorithms, hardware, defenses, etc.).

81

Assume the attacker knows where the “secret” control panel is located, and has read the manual with instructions on resetting the password.

Computer Science 161

82 of 87

Use Fail-Safe Defaults

Textbook Chapter 1.10

82

Computer Science 161

83 of 87

Soda Hall

  • Rooms in Berkeley’s Soda Hall are guarded by electronic card keys
  • What do you do if the power goes out?
    • Fail closed: No one can get in if the power is out
    • Fail open: Anyone can get in if the power goes out
  • What’s the best option to choose for closets with expensive equipment? What about emergency exit doors?
  • Takeaway: Use fail-safe defaults

83

Computer Science 161

84 of 87

Security Principle: Use Fail-Safe Defaults

  • Choose default settings that “fail safe,” balancing security with usability when a system goes down
    • This can be hard to determine

84

Computer Science 161

85 of 87

Design in Security from the Start

Textbook Chapter 1.11

85

Computer Science 161

86 of 87

Security Principle: Design in Security from the Start

  • When building a new system, include security as part of the design considerations rather than patching it after the fact
    • A lot of systems today were not designed with security from the start, resulting in patches that don’t fully fix the problem!
  • Keep these security principles in mind whenever you write code!

86

Computer Science 161

87 of 87

Security Principles: Summary

  • Know your threat model: Understand your attacker and their resources and motivation
  • Consider human factors: If your system is unusable, it will be unused
  • Security is economics: Balance the expected cost of security with the expected benefit
  • Detect if you can’t prevent: Security requires not just preventing attacks but detecting and responding to them
  • Defense in depth: Layer multiple types of defenses
  • Least privilege: Only grant privileges that are needed for correct functioning, and no more
  • Separation of responsibility: Consider requiring multiple parties to work together to exercise a privilege
  • Ensure complete mediation: All access must be monitored and protected, unbypassable
  • Shannon’s maxim: The enemy knows the system
  • Use fail-safe defaults: Construct systems that fail in a safe state, balancing security and usability.
  • Design in security from the start: Consider all of these security principles when designing a new system, rather than patching it afterwards

87

Computer Science 161