Slides are at: upon2020.com/talks

Paradux: Recovering From Maximum Personal Data Disaster

Johannes Ernst, Indie Computing Corp.

mail: jernst@indiecomputing.com · blog: upon2020.com
Mastodon: @j12t@social.coop · Twitter: @Johannes_Ernst

About myself: Johannes Ernst

The California "Camp Fire", November 2018

  • deadliest and most destructive wildfire in California history
    Wikipedia
  • burned 70,000 acres in 24 hours
    Wired
  • 86 people died
    Wikipedia
  • "If we’d stayed 10 minutes longer we would have been burned."
    New York Times
When I flew back from Seattle in November 2018

Bank of the West, Paradise, CA

www.paradisepost.com/2017/12/13/fire-destroys-bank-of-the-west/

Paradux: the Problem

Disaster scenarios

  • fire burns your house & everything in it
  • ... and your backups
  • ... but you keep your laptop / phone
  • ... or not
  • ... and you cannot remember your "root" e-mail password
  • ... and you are temporarily out of commission
  • ... or permanently

Impact

  • can you continue to earn a (the same) living?
  • can you recover all your e-mail?
  • can you recover all your money?
  • can you recover all your family photos?
  • can your surviving spouse or children?

Personal data disasters with similar impact

  • other natural disasters
  • burglary
  • malware attack
  • Google disables your account
  • Facebook disables your account
  • AWS disables your account

Defining the Problem

  • personal data is distributed: mobile, laptops, desktops, home servers, cloud...
  • at home, with a friend, a colo, a lock box at the bank
  • some in your head only
  • any location of data can "disappear" without warning
  • this includes your memory

We want to be able to recover all data. Without enabling data theft.

How Paradux works: outline

1. Create a data inventory
(& some more metadata)
  • documentation for you and your survivors
  • you can't recover what you don't know of
  • basis for automation
  • highly sensitive
2. Secure the metadata
  • LUKS encrypted volume
  • "everyday password" (in your head only)
  • long recovery key (never exported)
  • split into K pieces (Shamir "secret sharing")
3. Distribute many copies of the secured metadata
  • so not all copies disappear at once
  • after stripping "everyday password"
4. Distribute key fragments
to N trusted "stewards"
  • K<N stewards are necessary and sufficient to recover the recovery key
  • also distribute locations of the encrypted metadata

Paradux step 1: create data inventory & metadata

Data inventory:

  • locations of all data
  • relationships between data locations ("X is backed up to Y")
  • data location access credentials
  • backup decryption credentials

Plus info about:

  • stewards
  • location of metadata

Paradux step 1: data inventory example

"datasets" : [ {
    "name" : "home-myself",
    "source" : {
        "name" : "Home directory on laptop",
        "url" : "rsync+ssh://laptop.local/home/myself",
        "credentials" : {
            "ssh-user" : "me",
            "ssh-private-key"  : "ssh-rsa ..."
        }
    },
    "destinations" : [
        {
            "name" : "Apple Time Capsule",
            "location" : "Home office",
            "frequency" : "automatic"
        },
        {
            "name" : "Amazon S3",
            "url" : "s3://mybucket/home-myself",
            "credentials" : {
                "aws-access-key" : "Axxx",
                "aws-secret-key" : "Axxx"
            },
            "frequency" : 86400,
            "encryption" : ...
        }, ...
    ]
} ]

Paradux step 2: secure the metadata

  • LUKS encrypted volume
  • day-to-day access with "everyday passphrase" (never exported)
  • recovery secret (never exported as a whole: split into K-of-N parts)
  • wrapped in Paradux commands that briefly mounts it when needed

Paradux step 3: distribute the secured metadata

  • without at least one copy, recovery is impossible
  • reasonably small size
  • good locations: cloud hosting; your friend's server
  • (relatively short) everyday passphrase is stripped first
  • long recovery key

Paradux step 4: distribute key fragments to N trusted "stewards"

Dear Jane Moe,

you have graciously agreed to help John Doe recover from personal data disasters that
might befall them or their family. This sheet contains all information you need to have to
assist when needed. Please keep it in a place where it safe from disasters (like fires)
and unauthorized access (like burglars).

Should you note unauthorized access, loss of this sheet, or if you do not want to
assist John Doe any more, please notify them immediately at: john.doe@example.com.

Paradux version:
    0.2

Your recovery fragment:
    x = 5
    y = 21405987023469813046...
    m = 13
    k = 3

Locations for recovery data:
    https://johndoe.amazons3.com/some/place
    http://his.friend/~joedoe/paradux

Paradux 0.2: How to get started

  • need: Linux box
  • install Paradux from github.com/paradux.
  • run paradux init
  • this will:
    • set up the LUKS volume with an everyday password
    • generate the recovery key
    • generate templates for data inventory, list of stewards etc.

Paradux 0.2: Configuration

Create/update data inventory:

  • on your Linux box, run paradux edit-datasets
  • requires everyday password
  • edit JSON file with data inventory

.. and other metadata:

  • identify stewards: paradux edit-stewards
  • some user details for recovery sheets: paradux edit-user
  • locations of the metadata: paradux edit-metadata-locations

Paradux 0.2: Upload metadata

paradux publish-metadata

  • requires everyday password
  • strips everyday password
  • uploads to all previously defined metadata locations
  • currently supported: scp
  • should become automatic

Paradux 0.2: Notify stewards

paradux export-steward-packages

  • currently stdout only
  • future: to paper, to USB sticks

Paradux 0.2: Recover some data (have Paradux box, no amnesia)

  • on your Linux box, run paradux status-datasets
  • requires everyday password
  • tells you about data locations and their relationships,
    so you can find out where the data is backed up you need to recover

Paradux 0.2: Recover Paradux box (no amnesia)

  • contact K of your stewards
  • download (public, encrypted) LUKS image
  • on a spare machine, install Paradux and run paradux recover.
  • enter steward-provided data and reconstruct the recovery secret
  • you have your paradux configuration back
  • continue with previous scenario.

Paradux 0.2: Recover everything (full amnesia)

  • "Somebody" wants to recover:
    • executor of estate
    • holder of power of attorney
    • you (with amnesia)
  • maybe they are a steward and remember?
  • executor traverses social network and finds K stewards.
  • continue with previous scenario.

Paradux 0.2: Attack scenarios

  • attacker accesses data inventory when LUKS is mounted
    • compare to password manager
  • attacker gains access to encrypted data inventory
    • LUKS-encrypted with long secret stored nowhere
    • has no everyday password
  • stewards go rogue
    • need conspiracy of at least K stewards who all know each other

Paradux 0.2: Commands

paradux edit-datasets
paradux edit-metadata-locations
paradux edit-stewards
paradux edit-user
paradux export-metadata
paradux export-steward-packages
paradux init
paradux publish-metadata
paradux recover
paradux status-datasets
paradux status-metadata-locations
paradux status-stewards
paradux status-user

Paradux implementation status

Current

  • it's very early
  • version 0.2, what do you expect!
  • very geeky: e.g. must edit JSON files
  • upload/download not automated

To do

  • add backup automation
  • automatic reporting
  • make user friendly
  • improve recovery process
  • integration with password managers?
  • and much else

Contributions welcome

github.com/paradux

Python 3, AGPL 3

Johannes Ernst, Indie Computing Corp.

mail: jernst@indiecomputing.com · blog: upon2020.com
Mastodon: @j12t@social.coop · Twitter: @Johannes_Ernst