Architecture and Modules

The Lockbox platform encompasses a highly proven suite of security and privacy components. At the perimeter, client-side software controls all encryption and keys. Intermediate is an "encrypted cloud" where Lockbox only knows about users as "labels" and workspaces as sets of encrypted "blobs".

System Principles

The Lockbox system is engineered quite differently compared to most other systems.  In particular: 

• Lockbox is decentralised so that nearly all control and processing is performed client-side. This distributed environment significantly increases system security, privacy, scalability, performance, concurrency, response times etc.
• Client software operates in a peer-to-peer like way. The only role of the system services is to facilitate the exchange and storage of encrypted information and facilitate the lifecycle of credentials. As a result, administrators are powerless to influence user controls (e.g. generation of keys, authorisation codes, encryption, signing etc) or eavesdrop on user information (which is encrypted end-to-end).
• System services have minimal knowledge about users or their information. Where possible, Lockbox follows the principle of "don't trust anyone, not even us". To this end, Lockbox central servers only know users by a "label" (their email address) and need only maintain the mapping between this "label" and groups of encrypted blobs (the workspaces).

Major Components

The following diagram shows the major components and protocols in the Lockbox system. In a custom implementation, any of the modules may be replaced with in-house or third party ones. Abbreviations and acronyms are listed at the bottom of this page.

Keystore

The local keystore stores personal keys of a user.  This includes private keys and associated certificates for signing, encryption, email, (SSL) communications and certificate management. The certificates are X.509 certificates and include appropriate certificate paths (CA certificates along with the end-entity certificate). The keystore is protected by a passphrase. It may be stored on the user's local disk or on a portable USB drive. It may also be archived in Lockbox's credential backup facility. Custom implementations can easily use a smart card.

Lockbox Client Application

The Lockbox client application handles all the client-side functions. This includes uploading/downloading, encryption/decryption, signing/verification, invitations and managing files inside workspaces. The Java application is code-signed and normally deployed using Java WebStart. It is a real-time application via event listeners so that changes in the workspace appear almost instantaneously to other users within the workspace.

The "Crypto Functions" component in the above diagram includes:

• Handling introductions, which involves the encrypted exchange of certificates (used for encryption and signing)
• Managing invitations, which involves encrypting and distributing workspace and community keys
• Rotating keys e.g. when a user is uninvited from a workspace
• Checking OCSP for revocation e.g. whenever encryption of keys is performed or signatures are verified
• Encrypting and decrypting documents and keys
• Signing documents or verifying digital signatures
• Generating assymetric keys e.g. signing, encryption, email, SSL (communications) and registrar (certificate management)
• Generating symmetric keys e.g. document, workspace, community keys
• Generating codes e.g. contact codes, invitation codes, change box ownership codes

Note that all keys are client-generated and there are various levels of key-encrypting-keys (KEK). For example each document is encrypted with its own document key (DEK), each document key is encrypted with a workspace key, each workspace key is encrypted with a community key and each community is key is encrypted with each invited user's certificate (public key).

The "GUI" component is the graphical user interface.  It gives a way for users to visually interact with their Lockbox's and other users. The GUI provides facilities such as upload/download files, drag-n-drop files, configure preferences, manage users and invitations, manage workspaces, annotate files, view and compose messages etc.

Registration Authority

The Registration Authority (RA) manages the registration process. This includes verifying a registering user's email address and interfacing to the CA in order to obtain certificates in the keystore. The RA effectively hides the CA from the outside world and ensures that all requests for certificates have been properly validated.  For example:

• When a CSR (Certificate Signing Request) is made for a registrar certificate, the MAC (Message Authentication Code) within the CMP message is verified using the email confirmation code provided by the user. CSR's use CRMF (Certificate Request Message Format) because public/private keys in Lockbox are strictly single purpose.
• When a CSR is made for signing, encryption and/or SSL certificates, the signature is checked that it was signed with the registrar key
• When a revocation message is received the signatures of the CMP message of the sender is checked as well as the signature of the carried CMP message of the originator.

Certification Authority

The Certification Authority (CA) manages the lifecycle of certificates.  This includes issuing X.509 certificates, handling revocation and providing an Online Certificate Status Protocol (OCSP) service. End-entity certificates are signed using a CA certificate issued by a separate root CA (locked away trust anchor) certificate.

There are separate CA certificates for signing, encryption, email, SSL and registrar certificates. Each CA certificate is a X.509 v3 certificate with appropriate restrictions such as basic constraints (e.g. path length constraint of zero so that all issued certificates are end-entity certificates), key usage (e.g. encipherment, signature, certificate signing), etc.

Unlike normal PKI CA's, the Lockbox CA does not store anyone's certificates (which may be a privacy issue). Instead, it provides an OCSP service to allow end-users to validate certificates.

The Lockbox CA also provides a separate certificate service for short lived temporary SSL certificates. This is necessary because the Credential Backup service will only accept mutual (client-authenticated) SSL.

Resource Manager

The Resource Manager is used to for control business and operational functions within Lockbox.  Examples include:

• Inviting and uninviting users
• Creating and removing workspaces (lockboxes)
• Creating and removing client workspaces (sub-boxes)
• Maintaining a history (audit) of workspace activity (available in the GUI)
• Managing branding e.g. the ability of clients to add a logo to their portal
• Synchronising billing activity with an external billing provider
• Sending emails e.g. invitations and notifications.

Repository Server

The Repository manages encrypted information. Examples of functions it performs include:

• Relationships - between communities (people who have access to each box), workspaces (each box) and the encrypted information in each box
• Events - to clients and the Resource Manager following a subscribe/publish model
• Storage - of encrypted information e.g. encrypted user files, encrypted user keys, encrypted messages between users, encrypted file annotations, encrypted key transfer etc. Each encrypted "blob" is stored as a CMS (Cryptographic Message Syntax) message. CMS is the IETF's standard for cryptographically protected messages and specifies how to digitally sign, digest, authenticate or encrypt any form of digital data.
• Access controls - such as restricting visibility to encrypted blobs and enforcing read-only properties. Note that access controls leverage client-side SSL authentication. In the case of introductions, access control is granted only if a user can provide the appropriate access code which is encrypted in the introduction/invitation.

Application Download Server

The web application download server is where a user's browser downloads the Java WebStart application. The HTTPS connection protects the WebStart JNLP file and WebStart verifies the signatures of downloaded JAR files.

Abbreviations and Acronyms

• AES - Advanced Encryption Standard specified in FIPS 197
• CA - Certification Authority
• CMP - Certificate Management Protocol specified in RFC 4210
• CSR - Certificate Signing Request
• CRMF - Certificate Request Message Format specified in RFC 4211
• DEK - Data Encryption Key
• FIPS - Federal Information Processing Standard
• GUI - Graphical User Interface
• HTTP(S) - Hyper Text Transfer Protocol (Secure socket)
• IETF - Internet Engineering Task Force
• JAR - Java Archive
• JNLP - Java Network Launching Protocol
• KEK - Key Encryption Key
• MAC - Message Authentication Code
• MSSL/MTLS - Mutual (client authenticated) Secure Sockets Layer/Transport Layer Security
• OCSP - Online Certificate Status Protocol specified in RFC 2560
• PKCS - Public-Key Cryptography Standards
• PKCS#10 - Certification Request Syntax Specification Version 1.7 specified in RFC 2986
• PKI - Public Key Infrastructure
• RA - Registration Authority
• RFC - Request for Comments documents of IETF
• RSA - Rivest, Shamir, Adelman (an algorithm)
• SSL/TLS - Secure Sockets Layer/Transport Layer Security
• X.509 - Public Key Certificate specified in RFC 5280