Oracle private key rotation

[Christewart]

One of the unique propositions for DLCs is that a public key can be a long standing identity for an Oracle. This can be used as a accountability mechanism to keep oracles honest by staking funds on a blockchain associated with this key. If an Oracle signs a message with different nonces, the private key is leaked.

This accountability mechanism does not come without security and UX tradeoffs in the case that the key is compromised.

@NicolasDorier and I were discussing on slack the merits of having longstanding public key associated with all of the oracles events, or rotating public keys on a per event basis.

In my opinion, from a security perspective, it is wise to rotate private/public keys on a per event basis. Here are my reasons

1. If the key is compromised signing an event even if the event is not related to your event you are dependent on the oracle for your DLCs are also compromised
2. From a security perspective, you should only access the private/public key for event if you are going to attest to that event. With re-using public keys across events, you incur security risk by constantly accessing the same private key. Oracle private keys should be kept in cold storage.
3. If the private key is compromised (from incompetence -- this is different if the oracle is malicious), all DLCs need to be re-negotiated. Since the odds of winning/losing bets have changed since the initial bet as placed, this will likely not be a easy/fair process. This re-negotiation risk is mitigated if there are unique key pairs on a per event basis.

[nkohen]

First of all I think that these considerations vary widely between different types of oracles. For example an oracle attesting to the time and signing every ten seconds can not feasibly have cold keys, this is only really feasible for manual oracles which I don't imagine will be the normal case.

Secondly I think that these concerns can be somewhat mitigated using threshold signatures (some variant of FROST) for the obvious reasons and also because I believe this allows for key shard rotation without changing the aggregate key (similar to how statechains shift ownership, two or more key shards can be altered in tandem to be completely different but without changing their aggregate)

I don't think this is an unreasonable proposal because in the long-term oracles are, economically speaking, just business models of private key security as use will correlate with trust. And I think that the extra work is worth the better UX (of avoiding oracle key rotation)

[nkohen]

Would be interested in @devrandom 's thoughts

[devrandom]

Here are some thoughts:

• the main scenario for key compromise is an attacker entering into contracts, and using a stolen oracle key to force their desired outcome ahead of the actual event time
• I believe that in the future, the value at risk from a single event key could be on the order of $100,000,000 and several times higher for an entire oracle identity
• some of the mainstream events (with a lot of value at risk) are monthly price indicators or similar - low frequency events

So I believe that we should give the oracles tools to spread and protect their keys. Some high value, low frequency events could have keys in cold storage. Others may be handled in separate systems, if they have different amount of value at risk. I can also see "semi-cold" storage, where there's a human in the loop and some optical connection that can be made or broken by the human.

The upshot of the above is that I think there should be a way for oracles to use a key per event, if they choose to do so. They should have an identity key that signs the event key. If they equivocate, a compact proof can be constructed that shows the chain of signatures rooted at their identity key, through the event key to the two different signed outcomes.

I also don't see much downside to allowing such a key hierarchy and the complexity is not high.

[LLFourn]

My thoughts on this are very simple and very strong.

If an oracle loses their key to someone then they are finished from all perspectives. The humans behind it can start a new one but client software should refuse to accept a new key under the same name.

Oracles are static trusted parties. Changing their key is changing their identity. This is even more true since the attractive punishment mechanism against equivocation requires this fact.

We could introduce a standard where the oracle can invalidate it's own key by signing a message if it thinks it has been compromised. This message must not include a new key or point to a new website or anything. Clients simply remember this invalidation and refuse to use that oracle in the future.

From a security perspective, you should only access the private/public key for event if you are going to attest to that event. With re-using public keys across events, you incur security risk by constantly accessing the same private key. Oracle private keys should be kept in cold storage.

I think you have the wrong model of secret key security. You do not incur a security risk by accessing your secret key. This is true even with libraries that are not side channel resistant since in the case of oracles they are just broadcasting things so there is no practical way to learn the side-channel information.

The oracle has one job: to use its secret key to sign things! It will be hard to do that if they are in cold storage.

How are you meant to know what the correct per-event key for an event is anyway? Does the oracle sign them with their main key? How do they do this if its in cold storage?

So I believe that we should give the oracles tools to spread and protect their keys. Some high value, low frequency events could have keys in cold storage.

If you want to attest to different events with different levels of secret key security just create different oracles with different public keys.

Secondly I think that these concerns can be somewhat mitigated using threshold signatures (some variant of FROST) for the obvious reasons and also because I believe this allows for key shard rotation without changing the aggregate key (similar to how statechains shift ownership, two or more key shards can be altered in tandem to be completely different but without changing their aggregate)

An oracle using threshold signatures internally is not a bad idea. I have no idea what this "rotation" idea is about. How can rotating anything make it more secure? It reminds me of the ill-advised policies of some companies to get their employees to change their passwords every 3 months or so.

[Christewart]

If an oracle loses their key to someone then they are finished from all perspectives. The humans behind it can start a new one but client software should refuse to accept a new key under the same name.

Absolutely, that is why I think we should optimize for secure private key management practices rather than creating a single point of failure (the long standing oracle identity key). This is a problem that already exists in cryptocurrency -- how do you know that an exchange's deposit address is actually owned by the exchange?

One way of doing this is to create a vanity bitcoin address that is NEVER rotated, but again, you have this massive risk of the key being compromised. Security professionals at exchanges have opted to distribute the risk amongst different keys. I think it would be wise to follow precedent set by the people currently securing billions of dollars worth of funds in the space -- or at minimum not discourage key rotation in the documentation.

I think you have the wrong model of secret key security. You do not incur a security risk by accessing your secret key. This is true even with libraries that are not side channel resistant since in the case of oracles they are just broadcasting things so there is no practical way to learn the side-channel information.

I think we may be talking about different types of security here, but you absolutely do incur risk by making your key easy to access. This is why the popular 'hot' and 'cold' storage key management paradigms have emerged. Maybe I didn't make myself clear in the original post.

If you want to attest to different events with different levels of secret key security just create different oracles with different public keys.

👍

If an oracle loses their key to someone then they are finished from all perspectives

Yes, which is why -- in my opinion -- we should optimize for secure private key management. All the accountability features for DLCs are worthless if a key gets compromised because an attacker has zero skin the game.

[ghost]

imho, probably we will eventually end up having a federation of oracles to attest that a public key belongs to some oracle ? What if we create some procedure to invalidate a public key from time to time, and use the old public key to attest the new one ?

Another perspective is that the ORACLE on an DLC might act like a TTP, both parties agree to trust their outcome in order to settle the contract ?

[devrandom]

To clarify, the advantages of segregating keys:

• if a key is compromised during a signing operation, other keys are not affected. This protects the users - it reduces the impact of a compromise. The oracle may still go out of business.
• the oracle can upgrade the security stance for new keys (e.g. move from a single key to a TSS scheme, or upgrade the way the key is held) without worrying that there are copies of the key lingering in the older setup or accessible by employees that left the company

[jesseposner]

The upshot of the above is that I think there should be a way for oracles to use a key per event, if they choose to do so. They should have an identity key that signs the event key. If they equivocate, a compact proof can be constructed that shows the chain of signatures rooted at their identity key, through the event key to the two different signed outcomes.

I like this idea but it creates a similar issue: (1) the identity key will need to be accessed for every event key generation and (2) if the identity key is compromised, then none of the event keys signed with it can be trusted.

Perhaps BIP32 can be used to create (1) child public keys that could be linked to a master public key and (2) create hierarchies where compromise of a child private key does not compromise other branches in the hierarchy.

EDIT: Actually, I think I might have misread the original proposal. @devrandom were you thinking of a hierarchy of identity keys: so the master identity key would be rarely used, and it could sign child identity keys and so on?

[NicolasDorier]

On my side, I share @LLFourn 's perspective. If a key is compromised, or need to be rotated, then it needs fully conscious and active change for the users of the oracle. It should not be done "silently", it should come with a big warning, and the user SHOULD do their homework knowing why the key changed, by asking to the oracle.

The whole point of DLC is that the reputation of the oracle builds on his public key. The more the oracle get trusted, the more he has to lose to attest to different outcome (and thus leak his private key).

If they can rotate keys easily, this completely ruins this essential feature of DLCs.

[jesseposner]

If child keys are linkable to a master key, then the reputation of the oracle would be shared across all of the keys. If the oracle attests to different outcomes with a child key, then users are not going to trust any keys in the hierarchy and the oracle will suffer significant reputational damage, as long as it's detectable and obvious to all users.

However, if there are no child keys, then an attacker's compromise of an oracle's sole key will significantly damage users who have contracts that are still in-flight, because the attacker will have the power to determine all of those contracts. And the more a key is used for signing, the more likely that it will be compromised, regardless of the competency of the oracle.

If there is a real trade-off here, and it's not possible to make compromise of a child key as detectable and obvious to users as compromise of a parent key, then there's a tough choice to be made, and ultimately users will be able to decide what type of oracle setup they value most. But it seems too early to conclude that it isn't possible at this point, and so I think it's worth exploring how it might be achieved.

[devrandom]

The upshot of the above is that I think there should be a way for oracles to use a key per event, if they choose to do so. They should have an identity key that signs the event key. If they equivocate, a compact proof can be constructed that shows the chain of signatures rooted at their identity key, through the event key to the two different signed outcomes.

I like this idea but it creates a similar issue: (1) the identity key will need to be accessed for every event key generation and (2) if the identity key is compromised, then none of the event keys signed with it can be trusted.

The event keys can be signed in batch, so this needs to happen much less frequently.

Perhaps BIP32 can be used to create (1) child public keys that could be linked to a master public key and (2) create hierarchies where compromise of a child private key does not compromise other branches in the hierarchy.

I'm not sure BIP32 helps in this case. With hardened derivation you still have to sign the children (because 3rd parties can't re-derive) and with non-hardened derivation a child compromise leads to a parent compromise.

EDIT: Actually, I think I might have misread the original proposal. @devrandom were you thinking of a hierarchy of identity keys: so the master identity key would be rarely used, and it could sign child identity keys and so on?

I was actually thinking of that as a possibility, but was worried it would complicate the discussion.

[devrandom]

On my side, I share @LLFourn 's perspective. If a key is compromised, or need to be rotated, then it needs fully conscious and active change for the users of the oracle. It should not be done "silently", it should come with a big warning, and the user SHOULD do their homework knowing why the key changed, by asking to the oracle.

The all-or-nothing aspect of a single key can create perverse incentives to cover up some gray-area cases.

The issue is that rotation might be desirable even if the probability of compromise is low. Here's a scenario: "A key employee left and we believe they were unhappy. We don't think the employee had free access to the key, but it would be nice to rotate the key on the 1% chance that they did manage to get a copy." If rotating the key has itself a revenue hit of let's say 10%, then no rotation will happen and the users won't know unless there is an actual compromise.

However, a real compromise of a key will be visible on the blockchain and easily identified, so it won't be silent.

[LLFourn]

My impression from reading responses here is that there are different visions for oracles should work.

The key idea proposed is to introduce a public key infrastructure where the oracle's main key signs a bunch of other keys and then goes into cold storage only to be brought out again when it needs to sign more keys.
The idea being that if one of these keys is compromised then you still have the reputational cost but not the "scorched earth" technical punishment.

I think this is missing the following:

1. It is not too difficult to set up a secure device with the oracle's main key that just does signing when it is told to. No employee ever has have to have access to the key itself. Indeed the key could be generated on the device and never leave it (perhaps with shares given to a few key employees in case it needs to be recovered).
2. why the compromise of a single per-event key wouldn't compromise all the per-event keys? What is the architecture here that makes this likely? I don't see it.

It seems straightforward to switch to per-event keys later on if things play out more according to that vision. It would be good to avoid the complexity of specifying a public key infrastructure before then.

[NicolasDorier]

If rotating the key has itself a revenue hit of let's say 10%, then no rotation will happen and the users won't know unless there is an actual compromise.

A compromised key can be used only once to cheat. This limit what a malicious oracle can do.

It seems straightforward to switch to per-event keys later on if things play out more according to that vision. It would be good to avoid the complexity of specifying a public key infrastructure before then.

Agreed, a PKI infrastructure is a can of worms. This whole problem is probably more complicated than DLC itself.

[jesseposner]

The idea being that if one of these keys is compromised then you still have the reputational cost but not the "scorched earth" technical punishment.

An important thing to underscore here is that the scorched earth technical punishment applies to the users not the oracle. This isn't about protecting the oracle, it's about protecting the users.

It is not too difficult to set up a secure device with the oracle's main key that just does signing when it is told to. No employee ever has have to have access to the key itself. Indeed the key could be generated on the device and never leave it (perhaps with shares given to a few key employees in case it needs to be recovered).

But even with something like an HSM, the HSM can be stolen, so even if the key can't be extracted, it can still be used for malicious signing. The other problem is that you're going to need to be able to generate lots of nonces on the HSM and keep them stored there until the signature is produced and also ensure that the HSM can never reuse a nonce (otherwise a key can be easily extracted from the HSM simply by reusing a nonce). There are going to be space constraints as the oracle scales up to handling a large number of DLCs. If you allow a nonce to be imported into the HSM, then the problem is even worse because the HSM will need to track every nonce that it has seen to prevent reuse.

why the compromise of a single per-event key wouldn't compromise all the per-event keys? What is the architecture here that makes this likely? I don't see it.

There are many types of access control systems that make it so a compromise of a single key would not result in compromising all keys. Keys can be stored in different physical locations, different cloud environments, shares can be distributed among different sets of employees, etc. Keys can also be stored in mediums that are difficult to exfiltrate en masse, such as printed QR codes in binders, with different sets of keys encrypted with different KEKs, that are themselves stored differently.

[Christewart]

It seems straightforward to switch to per-event keys later on if things play out more according to that vision. It would be good to avoid the complexity of specifying a public key infrastructure before then.

This is where I'm landing on this, I don't think we should really take a strong stance on this for now. If people ask about this we should link to this issue so they can see our discussion on the matter.

EDIT: I guess more importantly we cant even really enforce things one way or another, so the oracles themselves will choose.

[benthecarman]

Kinda late to the party but I think for 0.1 of the spec we should go with the assumption that an oracle has 1 key. This makes things far easier to reason about and simplifies a lot of the protocol / software

[Christewart]

This is something that came out of #101 and I commented on the oracle address issue but it is relevant here too

#99 (comment)