Designing Security That Empowers Users
Kyle Rankin
President
Purism
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:
- 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