Validator Node Compromize Analysis

Archived Tendermint
1

We are currently evaluating the KMS softsign component for production use. Softsign has some good properties compared to a HSM. However, some risk analysis is required beforehand.

Assumptions
Let’s assume

  1. we have a sentry architecture with a KMS component,
  2. an adversary has taken over the validator node, and
  3. that the operator key is completely offline and not accessible by the attacker.

Implications
The adversary is able to send arbitrary commands to the KMS; e.g. SignVote, SignProposal and so on. As an effect, the adversary might be able to conduct a double-signing attack and therefore slash the validator.

Remediation Ideas

  1. Once the operator detects the attack, he should be able to put the validator into the inactive set on a voluntary basis (fees should be imposed anyhow)
  2. Afterwards, the operator should be able to change the validator keys, otherwise the validator cannot recover from attacks at all (in case the validator key has been accessed by the adversary)

What do you think?

3 Likes
2

The KMS prevents double signing as it will only sign for higher (Height, Round, Step).

I would also suggest using a HSM such as YubiHSM. It is fairly easy to setup and create a wrapped export of the secret key.

3

I don’t see any benefits when using a HSM over softsign when it comes to double-voting. Since gaiad sends commands to KMS (and therefore to softsign or HSM) it is easily possible to cause double-voting and slashing.

HSMs are dumb :slight_smile:

4

There are a number of best practices around KMS that makes double signing highly unlikely:

You would typically run the KMS process on a different, locked down host from the validator. The KMS connects to the validator process, so outbound connection to validator. It then signs request from the validator, but only those that would not result in double signing.

This double signing prevention is implemented in tmkms software but also runs in Ledger devices (not YubiHSM).

5

Good points, we are going to do some security testing around the double signing prevention in the KMS. I don’t see how HSMs are able to detect double signing.

6

The Ledger app prevents double-signing inside try_state_transition():

7

https://github.com/tendermint/ledger-validator-app/blob/bee890e5ccc7e98b8a2a8ce30db00cbe9b5fc2bf/src/lib/vote_fsm.c#L19 it’s rather a sanity than a security check. Quickly double vote twice will bypass this check

8

I disagree. This happens serially/sequentially over USB, there is no parallelism. It can’t be bypassed by timing.

State is updated here:

2 Likes
9

Thanks for the great feedback. This is a very interesting topic. However, I suppose KMS should do the same check, as well. I am still in learning mode and trying to get into details

10

Similarly to Ledger, the tmkms service itself does a similar check. As you can see in the config it stores state files for each chain, which contains last signed height etc.

1 Like
11

Correct @mdyring. It should not be possible to skip the check or to double sign. The ledger app keeps tracking the last vote. Ledger devices needs to reply before getting another request. There are no threads or possible race conditions… before signing the state is updated.

I am always open to hear about proof-of-concept for exploits and/or interesting analyses. Nevertheless, I think it is responsible to avoid claims about security issues without strong support, otherwise, this may mislead/confuse users.

12

Said all this, @unicorn Please! if you guys actually find anything interesting, we invite you to submit to the bounty program here: https://hackerone.com/tendermint
It is always good to hear about aspects that we might have overseen!

2 Likes
13

Sorry for the misunderstanding. There is no security issue to report right now. However, we are about to start fuzzing and real security analysis with respect to KMS … however, only if we will not drop out of the validator set :exploding_head: