Fund administration

LockBox was given a minimalist, flexible design so that it can be more easily understood and thus adapted to an organization's specific needs. In what follows, we first explain the general intended operation of LockBox, followed by how the client organization chose to implement those operations.

LockBox Flow

The two cryptographic keys generated by the LockBox desktop app, one public and one private, can be managed in a variety of ways. In the "version 0" prototype of the app, the public key had to be manually uploaded to the webserver via a secure channel. In more recent versions, the user first logs in to the website, then retrieves a configuration token for the form they wish to configure. This token is entered into the app, and contains the information required to upload a fresh locally-generated key to the respective form on the webserver. Questions for the form are configured via the web interface similar to any other online form creator. This is all the setup that is required, and the public link provided by the website form manager can be shared with submitters.

Instructions (and now, our illustrated primer!) inform the user about the importance of managing the private key file. It should be kept offline somewhere it cannot be easily accessed or copied by unauthorized users, but it should also be backed up, ideally to multiple places. Organizational characteristics should also be taken into account here. For example, should multiple people have a copy of the key in case one was unavailable for some reason? Should the key be kept somewhere that multiple people have to cooperate to access it? Should there be a log recording who accessed it and when?

Submitters do not have to install any software; the form is entirely online. The web app administration panel will generate a static public link that can be distributed via social media, printed on posters, etc. The form itself can be themed to match the organization's branding. Form submissions are encrypted in transit by HTTPS and then public-key encrypted upon receipt by the server before being stored to disk. (This creates a window of opportunity for a sophisticated hacker who has managed to compromise the server to replace or alter the software with something that exfiltrates the submitted data; see Future Plans for one potential way of mitigating this possibility.)

Encrypted submissions are stored in a log-like structure on the webserver with one submission per line/entry. This allows the web interface to inform the form admins of how many submissions have been received in total, in order to determine if new data needs to be downloaded.

If so, downloading encrypted submissions takes a single click and proffers a single cumulative file. By saving file this to the form's data folder that was autogenerated by the desktop app (or specifying its location manually), the app's "decrypt" function will become available and the submissions can be decrypted to a .csv (spreadsheet) file.

Organizational flow

Our client organization in this case chose to form a five member council that met weekly to review new applications and dispurse funds. Details and determinants of that decision-making process are beyond the purview of this case study.

Two members of their staff met virtually with the Open Privacy staff member developing the application to complete the setup process together. Keys were generated on a computer dedicated to the task, and backup copies created using USB keys. This proved prescient, as later, someone using the administration computer accidentally shift-deleted the private key and other configuration files. One of the backup USB keys was used to restore the private key and fund administration resumed unimpeded.

For the weekly review council meetings, a staff member would log in to the website shortly before the meeting and download a fresh copy of the form submissions. Decryption was reported to always proceed painlessly, and the resulting spreadsheet was handled in offline Microsoft Excel. The need to meet remotely introduced by the pandemic at the time caused some awkwardness around distributing the submissions for review; they chose to err on the side of safety and have the staff member with the computer read relevant portions (e.g., non-contact information) of submissions to the rest of the council over secure video conference. Members met at a later date to review the files and confirm records against the data in person.

At the conclusion of the mutual aid fund's run, the web form was replaced with a thank-you message and the encrypted data was simply deleted once it was confirmed that all submissions had been downloaded and archived.