[Cryptography] Escrowing keys

[Phillip Hallam-Baker]

I am currently wrapping up the Mesh code. At this point I am halfway
through the set of test cases for the line mode client. And almost all the
functionality being tested is already tested at the library level.

One area I am still working to get right is the offline escrow mechanism.
The basic idea of the Mesh is that we want to enable people to use a single
fingerprint to identify their personal root of trust and this should be
able to last their entire life. I have eliminated the idea of
pre-determined certificate expiry completely.


So the root of trust comes down to:

1) The master signature key
2) A list of master encryption escrow keys

Yes, there are certainly cases where you do not want to escrow an
encryption key. Transport encryption keys should never be escrowed but
encryption keys for static data usually do require escrow. In 99% of cases,
the loss of the data would be a far more serious risk than disclosure.

One corollary of this is that all message encryption schemes require
separate transport and message level security.

Trusted hardware is really interesting and useful. But I don't think it
actually helps in this application. The main advantage of using HSMs in CA
Key Ceremony is that they allow audit. The use of the key requires a
physical device and that can be monitored. Even better of course would be
HSMs that track each private key operation.

But no hardware can really be trusted beyond a ten year service life. CAs
provide continuity using a very expensive to manage set of processes. These
really don't work for the individual. So I prefer a process in which the
only data that needs to be trusted can be written down on a sheet of paper
by hand. Hence Shamir secret sharing.


So my current escrow scheme looks like this:

meshman /personal test at prismproof.org
Created new personal profile MD2DE-5Y2KJ-DIIFI-GNKOA-NG6YX-EKRDZ
Profile registered to test at prismproof.org

meshman  /escrow /quorum 2 /shares 3

Created offline escrow entry Shares=3, quorum=2
Share ECTQR-Z3C2F-GJSPM-PNX4K-TY7IL-E5QC
Share EERHF-HOJTU-YZQV2-OCXM3-WYLAL-QAQ
Share EKCNW-UZQNI-LJO4I-NXW44-3X6XL-3DQA


The escrow record itself is stored in the cloud encrypted using AES-256. To
decrypt the escrow record, you need the escrow record data plus two of the
three shares. The master escrow key is 128 bit, a KDF is used to extract
the AES256 key. The secret sharing scheme is based on Shamir.

So this means that the brute force difficulty of breaking the key is 128
bits but conventional cryptanalysis is almost certain to present a 256 bit
workfactor.

The index of the escrow record is the fingerprint (SHA-512-T) of the
encryption key. This provides a simple mechanism to validate the recovery
process.


OK so that is the default way to store keys. If we assume the Mesh business
model works then it seems pretty certain someone will store the offline
escrow blobs in perpetuity even if only out of curiosity. The blobs are 21K
in JSON encoding and would be rather smaller in JSON-B encoding. The escrow
records for the entire planet could sit comfortably on a $5K RAID array.

But as John Gilmore points out, that isn't going to be enough for everyone.
So in addition, I have an option to write out an escrow entry to a file
instead.

meshman /escrow /quorum 2 /shares 3 /file escrow.json
Written to file escrow.json
Share EBOOQ-VFCBQ-BZNXV-NX76I-MDII3-X2QA
Share EGAS3-LKK2K-SFILU-S3J5N-HTSYO-GOQC
Share EK7XE-BPTS5-DBG7T-W6X4B-7EFJA-VCQ

OK so far, not controversial. Now I am also thinking about providing an
option to simply write out the private keys without any encryption. This
will greatly simplify my development/debugging process but will introduce a
possibility that end users screw up bad.

Ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170428/3270a5ae/attachment.html>