NOTE: This page is defunct and archived for historical purposes.

Overview

• Brian Warner, Chris Karlof, 20-Feb-2013

This is a simple (lack of) security architecture that will hopefully captures the general flow of the full security architecture proposal in Identity/CryptoIdeas/03-ID-Attached-Data, but avoids most of the complexity. The intention is to prevent the security design from blocking general development, but still include some of the basic steps we expect in the final protocol. We would then iterate over time to add in the necessary security mechanisms.

Key Server API

POST /user

Creates a user at the key server. The request body must be a JSON object of the form:

{ email: <email address> }

The response body returns the users kA value and success => true. Example response:

{ kA: <kA value>, success: true }

In the full proposal, kA is used to derive a token value which authenticates the user to storage servers. In this simplified proposal, we won't derive a token value, but just use kA directly as the token, as well as the user id.

GET /user?email=<user's email>

Returns the user's kA value. Example response:

{ kA: <kA value>, success: true }

Storage Server API

For storage server API calls that require a token, the client should use kA. No explicit user provisioning step is required. For storage server API calls that require a user id, the client should use kA. For each request to a storage server, if a storage "bucket" associated with kA doesn't exist yet, then one should should be created. All data sent to and received from storage servers should be in plaintext. See https://docs.google.com/document/d/1aU0Gdga-JBr6f4eqPF5YHkXyGYXtWCP7lTLJThjG3KE/edit?usp=sharing for more information on the Storage Server API.