Crypto-mail-safe

Introduction

At Techinc we end up having to deal with having to store Identification-documentation in a secure manner because of requirements that Urban Resort puts on us for the availability of RFID-fobs to open the door to the building.

As such, we've looked at a number of options on how to deal with these sensitive documents; ranging from storing them in a safe at the space, at someonebody's home, in a bank-vault, etc.

The challenges are several. They include, but are not limited to:

• Acquisition: how do we make the process of getting the document to us as secure as possible
• Storage: How do we store it so that only authorized people entrusted with access can get to it securely
• Access: How do we implement any kind of access-control that we can verifiably demonstrate is secure/honest towards our members
• Change of roles: How do we ensure that people who do not need access anymore lose their ability to access these types of documents.

What follows is a proposal from me (User:Justa) to address a number of these issues via a system based on cryptograpy, using mail as transfer-method and crypted image-files as a manner for storage. I will try to explain the theory of operation, it's challenges and it's limitations as honestly as possible.

Outline

The proposed system would use a combination of PGP and [Shamir's Secret Sharing] algorithm to come to an environment that'd function as follows:

• There would be a 'secure drop-point' email-adress on the techinc-domain, let's call this 'secure@techinc.nl' for convenience
• The 'secure@techinc.nl' address would have a well-published and verifiable public PGP-key available for people to mail to it.
• Preferably, it will ONLY accept PGP-encrypted mails, but it could be made to accept (and subsequently process) plain emails as well.

Behind 'secure@techinc.nl' is a script/program that parses incoming mail, verifies that there's an encrypted attachment and proceeds to storing that attachment on disk somewhere, and/or uploading it to dropbox, whatever. Additionally, when receiving a non-encrypted mail, one could choose to EITHER deny the mail and send a refusal-notice to the sender OR proceed to encrypting the contents of the mail with the public key of 'secure@techinc.nl' itself and inform the sender about the action taken.

Additionally, the script should/could keep a log of all the actions it's performed; preferably via mail to a number of admins/board-members in charge of the system's functioning. Possibly also allowing people to admin/moderate incoming mail so as to prevent obvious spam-mails being stored.

At this point, one has:

• An email-gateway that allows people to securely send crypted data to us
• A secure way to store the data
• A transaction-log of where the data came from, who sent it (possibly with PGP-signatures and SMTP-logs)

It has not been mentioned yet, but the PRIVATE key belonging to 'secure@techinc.nl' is stored using the aforementioned 'shamir's secret sharing' algorithm. It exists as a message that's been split up in N parts and given to a number of admins/moderators/boardmembers of which a certain number of M parts are required to provide the full PGP key again. Please refer to the wiki-page mentioned earlier for an outline of the theory behind it and it's operation.

This would allow you to build a process that'd work as follows (as a suggested procedure/functioning):

• The Private PGP key has been split over 7 board-members (N=7) with the number of required parts to get to the key set to 3 (M=3).
• This would allow 3 board-members to get together and get to the key, preventing any one single board-member or two board-members from conspiring together and plundering the store of ID's.
• The 'M' can be set to 4 or higher, all the way to 7.. but for convenience and continuity reasons this would likely be unwanted.
• When a request-for-information comes from UR, there will be the need for a committee of (at least) 3 people to agree to the need for complying with the request and to be able to get to the PGP key to decrypt the proper file into plaintext.

Extra considerations

There are a number of 'special situations' that need to be addressed in ways that ensure a reliably secure functioning of this mechanism , as well as a continued capability to trust the system's security. I suggest implementing these by way of specially tailor-made Raspberry PI images as I will explain in the following segments. Each SD-card image should be made available for public scrutiny by members/etc. for verification of intended operation. At no time should any of the Raspberry PI's running these following processes be connected to a network-connection of any kind.

Issuing the initial key-parts

There will be the need to create a Private and Public PGP keypair in a way that people can trust that the PRIVATE key is not known to any one person individually. Upon creation, the Public key needs to be published/exported. In contrast, the PRIVATE key needs to be split up into N-segments as soon as possible, after which each of the N people that are entrusted with such a segment should, each individually, have access to only their segment and their segment alone.

I propose to implement that as a special-purpose raspi SD-card image that does the following:

• Boots a linux-distro
• Create a MEM-disk to perform all disk-based operations to required for the following steps
• Starts a script that asks for the N and M params for the Shamir Secret Sharing algo, as well as the params for the PGP-key creation process
• Requires some source of (NON NETWORK-based) entropy to be supplied (i suggest mice/keyboards/joysticks)
• After creation of the PGP key, it will ask for a USB-stick to be inserted; this will get the PUBLIC key on it.
• After transfer, it will unmount the stick and require a further N USB-sticks to be inserted sequentually, transferring a segment of the PRIVATE key onto it each time, unmounting, waiting for a next stick to be inserted and waiting for a confirmation before continuing.. etc.
• Erase the memory-disk
• Possibly require the SD-card to be destroyed after use for added trust.

At this point, you will have N sticks with N segments of the PGP key, split properly. None of the people involved will have had access to the full private key at any one point. The public key is stored on a seperate stick. The SD-image does not store anything on disk and/or is subsequently erased and/or destroyed (SD-card burned)

Decrypting a file

There will be the need to access a file every now and then when the need arises.

When this happens, M people come together with a USB-stick containing their segments of the PGP key that would enable to decrypt the file. It would not be good to assemble the key on any machine that'll be re-used later; for that would compromise the trust that members should have in the assurance that nobody individually has access to the key alone.

As such I propose to implement this as a special-purpose RasPI SD-card image that does the following:

• Boots some linux
• Starts a script that asks for insertion of a USB-stick that contains a crypted file.
• Asks to identify the file and copies it to SD-card or MEM-disk.
• It asks an M-number of USB-sticks to be inserted that all contain a segment of the PRIVATE key required to decrypt the file. It might be possible to have the system auto-detect the amount of segments required for it to succesfully get the PRIVATE key. If required, the PRIVATE key and/or all M-number of segments is stored ONLY on MEM-disk
• The file is decrypted, a USB stick is asked to write the decrypted file to.
• Erase the M-number of segments from MEM-disk and the PRIVATE key as well
• Reboot the system
• The SD-card is destroyed/wiped if required (or it should do PGP activity on MEM-disks only)

Re-issuing keys upon change of admins/board/etc

It is clear that the group of people entrusted with management and access to the securely stored data will change over time. Board-members join and leave, etc.

It will be required to re-do the distribution of the PRIVATE key across N people (with M required to re-assemble the PRIVATE key). This should preferably be done on a non-networked machine, not reused later for other purposes.

I propose implementing this as a RasPI Sd-card image that does the following:

• Boots a linux
• Starts a script requiring M people to insert a USB-stick to find M parts of the distributed PRIVATE key and store this on mem-disk
• Ask for a new N and M parameter to start re-splitting the PRIVATE key across N participants
• Split the private key across N segments, store it on MEM-disk
• Require N participants to insert a USB-stick in sequence that will get a single part of the N parts of the message written on it
• Delete both the PRIVATE key and all N keys from the MEM-disk before rebooting
• Destroy the SD-card afterwards if required/wanted/desired.

Concluding remarks

One could possibly go with a system that re-crypts the content of the mails halfway; using a seperate pub/private keypair for the 'secure@techinc.nl' address and the subsequent secure storage.

This would have the following implications:

• One could verify the contents of the encrypted segment, assuring that it's indeed a valid image-file and is thus usable for ID-purposes
• One would have to go through great lengths to ensure that the receiving script behind secure@techinc.nl can be trusted to do only what it's meant to do and not leak the decrypted info to another party.

In closing, I think that properly implemented, the above system could be re-used for different purposes that have the same challenges; perhaps by other groups such as other hackerspaces or people with a need to store documents in such a way that any one single person cannot be coerced to give access to an un-authorized third-party against their will. The use for whistle-blowing purposes seems a possible avenue of exploration.

Publishing the source and the prepared SD-card images should be a nice way to make it easy to implement by others and integrate into their procedures as well as ensuring that the trust in the system is stimulated as much as possible.