Implementing A Multi-Hat PDA

Matthew Johnson and Frank Stajano

University of Cambridge Computer Laboratory

The Problem

Psion MX5
  • The PDA is obviously designed as a single-user machine
  • Some functions of a PDA we want to be passworded:
    • Diary / Journal
    • Email
  • Some functions do not not need a password:
    • Calculator
    • Games
  • Just using a calculator requires a password.
  • Still cannot lend the calculator without giving access to email.

The many hats idea

  • PDA may be a single-user machine, but it doesn't have a single policy.
  • User can assume several roles with different privileges and credentials.
  • Roles may be changed between without interrupting sessions in progress.
  • One role can be accessed with no credentials.

Multi-hat security rules

  1. Hats. The machine supports a finite number of hats which have credentials. One of these is the null hat, which has no credentials.
  2. Sessions. The machine supports simultaneous sessions, each belonging to a hat, each active or locked.
  3. Session Unicity. For each hat there is at most one session.
  4. Hat Selection. There is a convenient way to select any hat. This activates or, if necessary, creates the session for that hat.
  5. Switching Sessions. To activate a session you must present the credentials of its hat.

The Null Hat

  • Requires no credential, and can always be easily accessed.
  • Can access stateless programs:
    • Calculator
    • Calendar
    • World time
  • Cannot access scarce or expensive resources:
    • Internet/network access
  • Default session if no valid credentials are available.

Restricted Hats

  • Security policy allows any number of restricted hats.
  • Can access selected extra resources to the null hat.
  • Can use stateful applications.
  • Require configurable credentials to access.

Changing Session

  • Explicitly select a particular hat
  • Shortcut to get to the null hat
  • Automatically switch on events
    • Power on
    • Suspend/sleep
    • Authentication token presence/absence
    • Lid closing

Authentication delegation

Nokia 6310i
  • Authentication may be delegated to a proximity token.
  • The token will report the distance from the token to the PDA.
  • Presence of the token may be either required or sufficient to access a hat.
  • Current prototype based on Bluetooth.
  • Possible Middle-Person attacks.

Demo

Demo

Related Work

  • Investigated similar features in several existing systems
  • Windows XP—Fast User Switching
  • Xen—Virtual Machines
  • Linux
  • KDE—Integrated GUI Session management
  • SELinux—Role-based access control

The Prototype

prototype architecture
  • Using an IA-32 laptop based upon KDE on SELinux.
  • Multiple roles as Linux users.
  • Sessions on separate X servers using KDM.
  • KDE remote session management and locking.
  • Custom event-based mechanism for switching.
  • Bluetooth locality system.
  • ACPI events trigger events.

Prototype Hats

  • Two restricted hats:
    • Less secure hat has network access and some stateful applications.
    • More secure hat has access to sensitive data as well.
  • Bluetooth proximity token for the less secure hat.
  • More secure hat always requires explicit credentials (password).
  • Null hat with stateless applications.

Further Work: Authentication methods

iButton Smart Cards
  • Don't want to use passwords.
  • Hardware tokens:
    • iButton.
    • Smart Cards.
  • Biometrics:
    • fingerprint reader.
  • Can reduce user interaction in authentication step.
  • Issues with sessions with identical credentials.

Furthur Work: Interface

  • X is not the common Linux PDA interface
  • Multiple X Sessions are wasteful
  • Most solutions for multiple programs in single X servers don't separate the programs
  • Generic proxies, such as VNC, have overhead and cater for the lowest denominator