[Cryptography] Key escrow scheme

Thierry Moreau thierry.moreau at connotech.com
Wed Apr 12 08:04:31 EDT 2017


On 11/04/17 08:06 PM, John Gilmore wrote:
>> I encrypt the RSA private key in AES 256 and store it on a cloud
>> service as the first step.
>
> This seems to me to be the single-point-of-failure-prone step.  Why do
> you think that the "cloud" will still deliver up this small opaque bag
> of bits many years from now when the share-holders so desparately need
> it?  Is somebody paying the bill for that storage all along?  Can that
> person decline to pay, some year, and unilaterally make the recovery
> key disappear?  Or, if the bill-payer is authorized over this account,
> can't they just submit a request to delete this blob?  What happens to
> your system's data when the cloud storage company fails (after clouds
> are replaced by vapor, for example, as the trendy new tech company VC
> fad)?
>

This looks like an "N out of M plus one" (more or less) instead of the 
nominal "N out of M". We have (as relying parties) such a little-touted 
"plus one" with the DNSSEC root KSK recovery scheme (the "plus one" 
agent being IANA holding an HSM encrypted configuration blob as part of 
their regular operational backups).

> I thought that the point of secret-sharing was to distribute the
> needed information in such a way that no single point of failure could
> cause the information to be lost.  And that e.g. a 3-out-of-7 secret
> share would mean that four failures would still not disable the
> ability of the remaining three to recover the secret.  Thinking this
> way suggests that the entire "recovery blob" should be stored INSIDE
> the shared secret, rather than being encrypted by the shared secret.
>

About this last sentence: I think the most obvious N out of M scheme 
deployment is the RSA private key encrypted in AES 256 with the 
resulting ciphertext given to each of the M key recovery agents (along 
with their respective secret sharing share).

One important reminder about secret sharing: nice concept in theory, 
which totally breaks if an individual recovery agent understands its 
role in isolation: the key share is believed to deserve no 
out-of-routine confidentiality protection since it is analogue to a key 
management ciphertext. (In FIPS 140-2, an encrypted secret present in a 
key management scheme falls out of certification scope.) The role in 
isolation merely suggests to report a "failure" in case of key share 
loss (while a suspected key share breach may result in the overall 
scheme failure).

In other words, if I was the enemy of a deployed scheme, I would -- 
assisted by social engineering -- provide backup services to recovery 
agents (please avoid a key share loss by all means) ...

(I was actually served an argument based on the individual agent role 
perspective while criticizing some aspect of the DNSSEC root KSK 
recovery scheme -- then I just gave up any educational attempt in these 
matters, I was not the "expert" telling what the audience wanted to listen.)

Have fun!

- Thierry

> 	John
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>



More information about the cryptography mailing list