Designing Security That Empowers Users

Kyle Rankin

President

Purism

Author of Linux Hardening in Hostile Networks

@kylerankin

https://kylerank.in/talks/security/security_that_empowers.html

Introduction

• Security comes with tradeoffs
• Often at odds with convenience, freedom
• Most security designed by vendors selling something
• Vendor-designed security is vendor-focused
• Assumption is user is helpless, untrustworthy
• Vendor holds keys, anchors trust
• User dependent on vendor
• Most people wouldn't choose to live in a prison
• Most digital security built on prison model
• Doesn't have to be this way.

Introduction

This talk:

• My background
• Security that empowers vendors
• Why security empowers vendors
• Why security should empower users
• Security that empowers users
• Designing security that empowers users:
• User-focused threat modeling
• Trust agility and key management
• Security self-sufficiency.

My Background

• My approach to security is unconventional
• Long-time Linux user, FOSS advocate
• Started career as sysadmin, traditional IT
• "Blue team" systems hardening
• Managing user security
• Transitioned to security full-time
• Blend of admin, defender, vendor, user, FOSS advocate.

Security that empowers vendors

• Most security measures at user expense
• Many also explicitly empower vendors
• Generally all-or-nothing security
• Two specific examples:
• UEFI Secure Boot
• iOS App Store.

Security that empowers vendors

UEFI Secure Boot

• UEFI Secure Boot secures boot process
• Most commonly associated with Windows, but can be used with Linux
• UEFI Secure Boot ensure boot firmware signed by vendor-provided signature
• Only executables with proper signature allowed to run
• Vendor signature typically provided by Microsoft
• RH, Ubuntu, others have gotten boot "shim" signed by MS to support Secure Boot
• UEFI shim then loads the rest of the Linux boot process
• Secure Boot usually (but not always!) can be disabled in UEFI settings.

Security that empowers vendors

iOS App Store

• iOS App Store secures software on iOS
• Software run on iOS must be signed by Apple
• App Store only way to install software on IOS
• Apps must get Apple approval to appear in App Store
• Enforced by secured boot firmware with vendor-controlled, hardware-backed keys
• Considered a jail, bypassing security is literally called "jailbreaking"
• Installing software like on normal computer called "sideloading".

Why security empowers vendors

• Motivation 1: Easy mode
• Security architects often well-meaning
• Simplest threat model removes user from equation
• Often easiest architecture to design/implement
• Reusing existing products/libraries/"best practices"
• Motivation 2: Lock-in
• Vendors motivated by gaining, retaining customers
• Security industry full of snake oil
• "Leave everything to us"
• Empowering users = reducing their dependence
• Risks losing users to competitors.

Why security should empower users

• "Security" often marketing speak for "control"
• Users should control their property
• Empowered users can hire experts
• Security is too important to leave to vendors
• Companies get hacked too
• Some companies violate trust
• Some companies coerced by govts.

Security that empowers users

• Security can empower users
• Two examples:
• Heads/PureBoot
• Reproducible Builds.

Security that empowers users

Heads/PureBoot

• Heads is Free Software firmware that provides similar features to Secure+Trusted Boot
• Uses Open Source coreboot firmware as BIOS to initialize hardware
• Provides tamper detection not tamper proofing
• Uses TPM + signing keys under user's control
• Can detect tampering in firmware, kernel, initrd, GRUB
• Limited to hardware w/ TPM that supports coreboot (Thinkpad X220/230, Librem laptops, some servers)
• PureBoot combines Heads with other boot security measures using user keys.

Security that empowers users

How Heads Works

• Coreboot loads Heads as main payload (instead of SeaBIOS or GRUB)
• Heads uses own Linux kernel + initrd
• Detects tampering in two stages:
• Stage 1: Use TPM to prove Heads not tampered with
• Stage 2: Use user GPG keys to prove files in /boot not tampered with
• If everything checks out, loads GRUB config and boots default kernel.

Security that empowers users

Reproducible Builds

• FOSS blazing trail in secure software with reproducible builds
• "Does the binary I get from my distro match upstream?"
• Lets you test for tampering/backdoors in binaries using freely-available code
• Download source, compile, compare results with public binary
• Debian working to make all packages reproducible
• Arch, Fedora, Qubes, Heads, Tails, coreboot, and others also working on own implementations
• Something you just can't do with proprietary software.

Designing security that empowers users

User-focused threat modeling

• Attackers factor real users into attack
• Security architects focus on attackers, ignore users
• Traditional threat model:
• What are you protecting?
• Who are you protecting it from?
• What are their capabilities?
• Add:
• Who are you protecting it for?
• What are their capabilities?
• Leads to defense-in-depth, layered security

Designing security that empowers users

Trust agility and key management

• Trust agility = ability to revoke trust
• Coined by Moxie about CA trust issues
• If vendor holds keys, what happens if they:
• Go down?
• Get hacked?
• Better agility:
  • Less reliance on vendor
  • Users holding more keys
  • Users revoking/replacing trust/keys
  • Less centralization of trust.

Designing security that empowers users

Security self-sufficiency

• Increasing self-sufficiency, reducing dependency, reduces risk
• People expect to hold keys to their house/car
• People want convenience, not dependency
• Most people aren't helpless:
• Modern computer literacy is high
• Many "digital native" adults
• Most confusion reinforced by bad vendor advice
• Spy movie threat models don't help
• Security can be convenient, effective and empowering
• Difference between a fortress and a prison is who holds the keys.

Questions?

Additional Resources

• This talk: https://kylerank.in/talks/security/security_that_empowers.html
• Heads: https://github.com/osresearch/heads
• PureBoot: https://puri.sm/projects/pureboot/
• Reproducible builds: https://reproducible-builds.org/
• Purism article on security self-sufficiency: https://puri.sm/posts/security-self-sufficiency/