Check out the new USENIX Web site.

Toward an open and secure platform

for using the Web

Will Drewry -- <wad@chromium.org>

EXTENDED PLAY

  • I work on Google Chrome OS security.
  • It's a platform for web users . . .
  •    . . . including the security conscious
  • We'll dig in to some specific security features by area: Survivability, Data Protection, Openness(?!)

The baseline

  • Built on Linux
  • Has no user-installed local applications
  • Web only: HTML 5, Flash, NativeClient
  • Users see Chrome running on Xorg
  • Runs a mix of new and existing daemons beneath

Feature Dive: Survivability

Attack mitigations

The usual suspects on laptops

  • Address space randomization
  • Default non-executable stack and heap
  • Discretionary access controls
  • Sandboxed Chrome renderers

Attack mitigations

The usual suspects seen on servers

  • Read-only root filesystem
  • Restricted mount flags for non-rootfs
  • Kernel config and code hardening
  • Capabilities and Mandatory Access Controls
  • MAC options still GRSec or Tomoyo; Capsicum very compelling
  • Access control != restricted attack surface

A little less usual

  • All system services use breakpad for crash logging

Attack mitigations: Connectivity

    Robust architecture:
  • Isolate all front-facing services
  • Centralize all privileged operations into flimflam
  • More work still to be done hardening
    • private dbus channel
    • isolation

Attack mitigations: Reducing bugs

    Testing and Auditing:
  • Black, grey, and whitebox automated testing
    • nightly stability testing
    • unit testing
    • fuzzing (of course!)
    • interested in fully integrated automated fuzzing frameworks
  • Security code audits: internal and third party

Automatic updates

  • Two root filesystems: active and passive
  • Allows full or delta differences streamed directly to disk
  • Delta differencing is based on block dependency graph
  • Dependencies are for write-order
  • A reboot switches to the new version; falls back on failure
  • Rebooting is fast

Verified Boot

  • A boot path that assures users Chrome OS is running
  • Static root of trust model
  • Root of trust lives in read-only firmware
  • Trusted Platform Module (TPM) used . . .

. . . but not how you'd expect

Seriously, PCRs are not involved

Verified Boot: Firmware

  • Execution starts in read-only (RO) firmware segment
  • RSA signature verified on a subkey in RW firmware
  • Subkey used to check the signature on RW firmware code
  • On success, execution jumps to the RW firmware
  • Rinse and repeat for handing off to the kernel
    • after loading it from its own partition (GPT)
    • verifies the kernel and its commandline
    • There is no standalone bootloader
  • Lockable TPM NVRAM used for rollback protection
  • More on failure modes and other boot paths later

Verified Boot: Firmware

  • TPM provides early access to NVRAM during boot
  • It stores indices for image and subkey versions
  • NVRAM can be locked in a number of ways
  • We use a combination to lock in stages:
    • The global lock as we leave the RO firmware
    • "Physical presence" assertion as we leave the RW firmware
    • Avoid STWRITE locking; it requires physical write cycles per boot

Verified Boot: Kernel

  • Device-mapper target overlays the root filesystem
  • Named dm-verity
  • Loads a hash tree off disk
    • appended after the root filesystem
    • Uses 4 KiB blocks for data and intermediary nodes
    • aka a Merkle tree
    • Implemented in dm-bht.c
  • Chain of trust is maintained without in-kernel RSA
    • by passing the root hash on the kernel command line
    • initramfs is slow so bake it in: UUID & dm

Verified Boot: Kernel

A tree looks something like:
 depth = 2, alg= sha256, num_blocks = 32767
                                 [   root    ]
                                /    . . .    \
                     [entry_0]                 [entry_1]
                    /  . . .  \                 . . .   \
         [entry_0_0]   . . .  [entry_0_127]    . . . .  [entry_1_127]
           / ... \             /   . . .  \             /           \
     blk_0 ... blk_127  blk_16256   blk_16383      blk_32640 . . . blk_32767
  • Currently blocks are fixed to 4096 bytes
  • Breadth-based read ahead is supported if needed
  • Supports directly booting to a UUID-specified partition
  • Patches not yet upstream but are out for discussion
  • Adds just under 2s to our boot without optimization

System Recovery

  • Recovery code path in the read-only firmware
  • Triggered by:
    • Verification failure
    • User button press+hold
  • Recovery path requires signed USB boot images
  • Even on factory reset, Google sync brings back bookmarks, themes, etc

Feature Dive: Data Protection

Identity

  • Login with a cloud identity
    • Currently, Google Accounts and Google AfyD
    • Generic, programmatic web login is an open challenge
    • E.g., Mozilla's account spec
    • Can login offline with cached credentials
    • Cryptohome. We never store the actual credentials.
  • Ephemeral sessions for browsing without signing in
    • Stores session on tmpfs

Cryptohome

  • Centralized cryptographic daemon
  • Handles offline authentication & encryption keys
  • Per-user encrypted data directories
  • User passphrase required for decryption
  • With brute force mitigations:
    • If available, wraps the key via the TPM
    • If not, uses a memory-bound strengthening function
    • Colin Percival's scrypt
    • netbook v desktop brute force protection is hard

Cryptohome: Key Wrapping

(1/2)

The vault key is stored encrypted by a key wrapped as follows:

When the TPM is enabled, there is a system-wide
cryptohome RSA key that is used during the encryption/decryption of these
keys.  The method when TPM is enabled:
  UP -
      |
      + AES (no padding) => IEVKK -
      |                            |
EVKK -                             |
                                   + RSA (in TPM) => VKK
                                   |
                                   |
                          TPM_CHK -

Where:
  UP - User Passkey
  EVKK - Encrypted vault keyset key (stored on disk)
  IEVKK - Intermediate vault keyset key
  TPM_CHK - TPM-wrapped system-wide Cryptohome Key
  VKK - Vault Keyset Key
The end result, the Vault Keyset Key (VKK), is an AES key that is used to
decrypt the Vault Keyset, which holds the ecryptfs keys (filename encryption
key and file encryption key).

The User Passkey (UP) is used as an AES key to do an initial decrypt of the
encrypted "tpm_key" field in the SerializedVaultKeyset (see
vault_keyset.proto).  This is done without padding as the decryption is done
in-place and the resulting buffer is fed into an RSA decrypt on the TPM as
the cipher text.  That RSA decrypt uses the system-wide TPM-wrapped
cryptohome key.  In this manner, we can use a randomly-created system-wide
key (the TPM has a limited number of key slots), but still require the user's
passkey during the decryption phase.  This also increases the brute-force
cost of attacking the SerializedVaultKeyset offline as it means that the
attacker would have to do a TPM cipher operation per password attempt
(assuming that the wrapped key could not be recovered).

Cryptohome: Key Wrapping

(2/2)

The VKK then wraps the final vault key:

VKK -
     |
     + AES (PKCS#5 padding + SHA1 verification) => VK
     |
EVK -

Where:
  EVK - Encrypted vault key (stored on disk)
  VKK - Vault Keyset Key

Feature Dive: Openness

Software

  • Open source project: Chromium OS
  • Using existing software packages and contributing back
  • Work out in the open:
    • Designs: chromium.org/chromium-os
    • Issues/tasks: code.google.com/p/chromium-os
    • IRC: freenode #chromium-os
    • Mail: chromium-os-dev@chromium.org
  • Code is available for review by anyone

Hardware

  • Static root of trust and openness
  • Physical switch under the battery: developer mode!
  • Developer mode:
    • allows booting self-signed OS images
    • warns the user during boot each time
    • clears the TPM and zeroes RAM (once)

Emphasis on Toward

Challenges and Future Work

  • Mutable data verification: downloads, cache, wifi, ...
  • Attack mitigation and testing: it's not an on-off thing
  • Fine-grained manageability
  • TPMs
    • are not crypto accelerators
    • are not HSMs
    • have challenging and inconsistent APIs
  • Peripheral firmware validation; DRTM
  • Secure, open wireless access
  • Platform-supported trusted UI: is it possible?

CrOS

Want more?

Press '1' to see some extra notes
  • Well done.
  • Press '2' at the beginning to enable EXTENDED PLAY
  • Not really that extended
  • Love the slide template?