Can a large corporation make a believable promise

Question

Say there is a secret encryption key that a third party has to handle. The third party is supposed to destroy the secret key when they are done, and tell everyone else it was destroyed and therefore safe to use. However, if the third party makes a secret copy, then they can covertly sell it for large amounts of money.

Let's say I want to get a large corporation to be that third party. It is possible for the corporation to make sure no employee can steal the key for themselves without conspiring with many other employees. How could the company show that it instructed the employees to destroy the key? I understand that no legal mechanism can totally prove that no one is lying, but I want to be close.

Example: Say a company has a board of directors, collectively known as Alice, and a CEO known as Bob. Alice votes on an official policy that the company may not lie to the public by saying that they have destroyed private key when they did not. Alice publishes this policy to the shareholders making it publicly known. After that, Alice makes a new policy that the company may lie about the destroying a key at Bob's discretion. This new policy is NOT published.

Bob is known to reliably obey Alices orders. The public knows that Bob has been ordered not to lie, but they do not know that the order is outdated. I want to know if Alice can make a publicly known policy that she may not secretly revoke.

Answer 1

Companies make promises they can't renege on all the time - that's what a contract is. After all, insurance wouldn't exist if an insurer could wriggle out of paying claims through things like secret policies.

That's not to say you can't breach a contract - of course you can, things go to court all the time. But a contract is as binding as anything you can do with directors and shareholders passing resolutions, and would need equally careful drafting.

The weaknesses of contracts in this situation are:

1. The courts can't put the toothpaste back in the tube (and compensation may not be sufficient for your situation)

2. The courts can't deal with things that are undetectable

As such applications with serious needs will often call for public transparency, hardware security modules, witnesses from multiple organisations, certifications from audit firms, and suchlike.

Answer 2

However, if the third party makes a secret copy, then they can covertly sell it for large amounts of money.

The thing about this is when it comes to a pivotal and highly-valued asset such as said key, it should never be,

• created
• transmitted
• kept
• deleted

by a third-party vendor. These processes if possible should be done internally.

Let's say if you would want to task a third-party vendor to delete said assets, it should be done with automation and limit that human/employee interaction, or keep it to the bare minimum.

Another solution would be, another layer of encryption on this already encrypted key. So that even if the vendor would to lay their eyes on this key, it wouldn't mean much to them, only your organization can see it, but this kinda deems the purpose of the third-party vendor a tad bit redundant.

Answer 3

How could the company show that it instructed the employees to destroy the key?

Easy. When an employee was instructed, he/she signs a document that he/she was instructed and understood fully the requirements.

But from the point of view of security this is absolutely useless.

1. Some employees can violate it intentionally. In many cases it is almost impossible to find out who did it.
2. Some employees can forget to do some important steps.
3. Some employees can misunderstand some instructions and violate them, believing they do everything right.
4. It is very hard and very expensive to implement this technically. Each file on a disk can be moved many times from one place on the disk to another one. Information on the disk may remain recoverable. It is expensive to make sure it is not recoverable.
5. For storing of important information reliably often RAID disks are used. One of such disks could have been replaced. One would need to search for it and make sure it doesn't contain your key.
6. The key could have been copied to other devices many times, intentionally or not. E.g. many companies apply regular automated backups. Such key file could have been put to many backups. Important backups are normally distributed to several remote data centers (e.g. one in US, one in Europe, one in Australia).
7. Such backups are stored on their disks. Means one would need to determine all drives involved and clean them properly or destroy them.

TLDR: No matter who and what promises, there is no way to guarantee that your key is not recoverable.

Solution: Don't share your secrets with others, or accept that from now on they will always know your secrets. You can withdraw physical objects, but there is no way to "withdraw" information.

Answer 4

I am not sure I completely understood your question, but technically speaking you may want to use an encryption method which distributes the key to several parties, and all must be present in order to consolidate a key.

This way one partial key has no use and there is not much to destroy (and beside that ensuring that one is destroyed is enough to invalidate the others)

Depending on your specific case, it may or may not be easy to decide on whom to distribute, but one of the keys could be trusted to someone independent (a notary, an outside organization, ...)

Answer 5

As already noted, this is a problem of trust.

Trust is a fragile asset. It's difficult to gain, and easy to lose.

There are many reasons I may trust Alice company:

• It is a big company, so "it should be fine"
• Foo trust Alice, so I would trust her, too (trust by imitation)
• I know that Alice is honest
• I know that Bob is honest, and he will resign before following such order
• I trust in $thirdparty, and $thirdparty considers that they can be trusted
• I have a signed contract with them, I could sue them for millions if they weren't honest
• The cost of breaking this would be far higher than the benefit (e.g. it could bankrupt the company if that was discovered, Alice would end up in jail...)
• I have overviewed all the process

Also note that even with an honest Alice, Bob might not act as expected:

• He may be honest, but misguided / not able to perform the steps properly
• He was approached by an Elbonian agent, willing to pay him millions for traitioning his company
• Elbonians kidnapped his family and he is being extorted
• Bob was honest, but the computer on which all these was to be done was compromised and the secret leaked, anyway.

Another interesting point is why you want to trust someone else. Sometimes the goal is not so much protecting the information as so far to move the associated liability to a third party. I might be able to keep $INFORMATION safer than Alice's (e.g. very confidential medical records). However, should I fail to do so, there would be a huge liability associated with that. By transfering such responsability to Alice's, this is mitigated. From a company point of view it may be sensible to transfer this risk elsewhere.

As a company, you have several ways to promote trust on you doing the Right Thing™

• You may pass periodical audits by reputable auditors (which live by their reputation, but obviously is not foolproof, see Arthur Andersen case)
• You may involve respectable members to validate/solve the issues (see Zoom acquiring KeyBase to improve their security)
• You may use technical means to restrict yourself (such as creating the keys in a HSM)
• You may create a procedure with internal/external witnesses validating your honesty. I recommend you to review the ceremonies for Root DNS certificate renewals.
• You may use (or create) technical means that preclude you from doing the bad action, such as using a multiparty computation to generate the key, or use zero-knowledge algorithms. See how Google and Apple algorithms for the Covid-tracing apps.
• You may show your procedures and code (transparency), so that anyone can verify them.
• You may let other people build their own programs, such as building their own copy from your code, so that they can be sure you are not distributing a trojanized version. This may also mean that it if you didn't follow the protocol you claim to use that could be detectable.
• Or that could even be made so that it would be detectable when you are not using the claimed code (see work on reproducible builds)

(obviosulsy they can be combined)

Finally, do note that although many concerns can be mitigated, by applying technical measures, organizational (like requiring multiple sign-offs, or applying a two-man rule), restricting trusted principals, adding re moving the to 'more trusted' (like moving the trust to yourself or your own organization), etc. ultimately, there will always be a trust component (c.f. the classic Reflections on trusting trust).

Answer 6

What you are mentioning here is the problem of trust, which is the major and unsolved problem in IT security.

Despite maths and algorithms, everything in security is ruled by trust in the parties with whom you transact.

What you have illustrated here is a huge human factor problem that has economic and political implications.

One thing you forgot to mention, is that the Big Corporate might be issued a Government (secret?) order to keep the keys. So the whole thing has a lot of implications.

My theorems about Computer Science

The following applies to the current scope

1. Once a piece of information is copied, it is no longer under your control

2. Every piece of information stored in digital computers must be made a copy of when getting transmitted

3. Digital computer primitives are only load and store

I could go ahead and expand #3 in Turing-equivalent machines and algorithm theory. Once a secret key is stored in terms of bytes in a Turing-equivalent machine or a mass-memory readable by a Turing-equivalent machine, it can be made infinite copies of

Technical Solution: a true DRM framework

I would think about opting for the following kind of solutions

1. Theoretically, use quantum computing

Those machines are not commercially available today on large scale. One of the key principles of quantum computing is that certain particles may share the same effects at distance (quantum teleporting). Scientific research is working on that.

You may think about storing secret keys in quantum particles, so that you can "destroy" them (destroy or alter the information stored in them) from your office, even without network connection, and without the counterparty to make a copy of the quantum keys.

2. Practically, Try to employ encryption hardware

You may design your crypto system to rely on hardware devices. Apart from advanced techniques of register-reading on hardware, which is extremely cost, you may find it useful to use a machine (e.g. programmable smart card) that destroys its keys after a certain amount of decryptions.

A time-based disposal requires additional hardening in order to authenticate the timestamp or prevent the smart device's clock from being altered.

Since encryption hardware prevents the keys from being copied, this is the only technical way to make sure your contractors obey. You may also demand them to return the device once they finished with it

3. Another approach is to use multi-escrow keys

You mentioned "without conspiring with too many people". One of the things I loved from certain Bitcoin wallets is the ability to designate a quorum (M over N) of cryptographic signers for a transaction. Let's revert Bitcoin's example here.

Given N a set of secret keys, and given M the minimum number of keys to fully decrypt the piece of information, you may design M and N to be enough large for the conspiracy to be excessively large (too many individuals to bribe/threat?) and M to be enough smaller than N so that if one of the people holding the keys may fail, even physically.

Example: 13 over 25 means that you create a set of 25 keys so that a minumum of any 13 is necessary. 14 is the minimum number of people to bribe, and that if 12 or more people fail you lost your encryption information forever.

Answer 7

This is routinely done inside companies. Companies sometimes have to do precisely this for their own internal reasons. Destroying a key is just a special case of the very common problem of ensuring that there are no unauthorized copies of a key.

This is done by pre-planning precisely what will be done, having the plans approved by an external auditor, and then having an independent witness of the process. The entire process is usually called a "key ceremony". Sometimes secure hardware is used, but not always. The crux is that people are present who answer to at least two different authorities. For example, one may be the company, the other may be an independent lawfirm.

Corrupting such a ceremony would require corrupting numerous people within the company performing the ceremony and at least one person outside that company. More parties can be brought in if needed by the security requirements, though this results in additional cost and complexity.

Securing keys worth billions of dollars can be done this way.

Answer 8

Since this is now on information security, not law, I'll give an answer from a crypto perspective, ignoring legal questions.

Assuming that all policies of the company are digitally signed and only digitally signed policies are in effect (by law or because the company has this rule), you could:

1. include a counter on each policy as part of the signature process, chaining policies together so that with each new public policy, at least the number of non-public policies (and thus their existence) since the last public policy is known.
2. generate a chain of signing keys derived from a common master key, so that each key signed one and only one policy, allowing you to revoke individual policies. (1 and 2 can possibly be combined)
3. let the generation of keys for signing and revocation be handled by a trusted third party, but keep the master key for yourself. So you would go to the notary with your master key, together generate the signing and revocation keys, sign the policy, and the notary only keeps the revocation key.
4. if under such a scheme you would destroy the revocation key, it would make it impossible to revoke the policy. If you had a secret policy that counters the published one, you would have a conflict.

A less drastic measure would be to have an organizational rule that in case of conflict, published policy wins over secret policy, and older over newer. This way you could amend something with a new, secret policy, but it wouldn't count until you (publicly) revoke the old rule. This, however, would need to be enforced by someone.