What we did, and why we stopped doing it
At the centre of this platform is a way of holding a key so that no single party has it. Five separate services hold a piece each, three of them are needed to answer, and the key is worked out fresh at the moment it is used and then discarded. We wrote that method out ourselves and then set about breaking it.
We broke it. Twice. The second attempt put five independent reviewers over the document and came back with about seventy findings, fifteen of them serious. The shape of the failure was the useful part. Every attack that landed came from the rules arranged around the mathematics: what happens when one service disagrees with another, how a dispute is settled, what silence means. The mathematics itself held under attack from three directions. Writing a third version of our own document was not the answer to that.
What we found
The method we had designed was published in 2019 by Jarecki, Krawczyk and Resch, and the paper sets out the use we are putting it to as well as the method itself: keys worked out on demand instead of kept in a wrapped form, one independent key for each thing being protected, and key rotation that leaves the archive where it is.
Arriving at published work by ourselves cost us several weeks, and we would not pretend the detour was free. What it changes for a client is what a reviewer can check. A design we assure you we were careful about is a different document from a design with a name, a proof and a citation behind it. The architecture page now carries the references. We would sooner be checked than believed.
Something we had been getting wrong
The research also corrected us on a point we had been stating loosely, and it belongs in front of a reader.
The starting point for each key is a public label: which collection, which generation, which part of the record. It has to be public, because each service checks that a request is for what it claims to be for. The mathematics therefore offers nothing at all against somebody who is entitled to ask and simply asks.
-
Who is allowed to ask, held as a row that can be deleted
-
How often they may ask, counted across the services and not at each one separately
-
That every request is recorded and attributed at three services the hosting provider does not run
Ordinary controls, doing real work we had been crediting to the cryptography
Those controls are the same ones we had always intended to build. What changes is where they sit in the description. They are the defence, and we had been describing them as a second line behind something else.
What we can and cannot promise about erasure
A contact at an owner or a manager can ask us to erase their details. Our answer is that their details sit under a key of their own, held in pieces across the services, and erasing them destroys those pieces, so a backup of the book taken years ago holds something nobody can open.
That has a limit, and we found it this week. It is a limit of the mathematics and not of our engineering. Nothing proves that data has been deleted, because data that has been copied cannot be uncopied. What we can build is that an attempt to put a service back to how it stood before the request is detected, refused and recorded. We have taken the stronger claim down from this log and from the review written for Gallagher, and put that one in its place.
What is next
One piece of the method has no published implementation we can license, which is the scheduled refresh of the pieces each service holds. That one is ours to write. It is also the part where a quiet mistake would be expensive, so it will be written against a published scheme and reviewed before it runs.
Five specific questions have gone to an external cryptographer. The first decides how much of the key setup we have to specify at all, and one of them may take the refresh out of our hands entirely.