does using a remote-signer or a ledger really improve security?

Question

TL;DR Using a remote signer or a ledger does a great job at protecting secret keys. But it doesn't protect against the withdrawal of XTZ from accounts. Anyone that gains access to the baker can withdraw funds from it using a simple tezos-client command. Is this correct?

---

I thought I had this all figured out and had a cozy feeling of my little tezzies sleeping securely at night. But now I'm questioning everything I've done to secure them. I asked a question about security with solo baking a month or two ago and it has now come back to haunt me.

Quick summary:

I have a baker with just a minimum of XTZ to cover deposits. I have an originated KT1 address I created from a Ledger TZ1 implicit address. The majority of my XTZ are reasonably secure.

However, to protect my baker's XTZ, I decided to setup a remote signer on a different, very isolated box. For all practical purposes only my Tezos Node can talk to it via a private network.

As Luke pointed out in my earlier question linked to above, and what I didn't fully understand at the time was:

Because the signer has no authentication, anyone that can login to your baking system somehow can sign messages with the remote signer, including balance transfer of your bond/deposit.

Now I fully understand what he meant. So what's the point of having a remote-signer given this problem?

Even if I was using a ledger, wouldn't the problem still be the same? If I could get access to the baking system, I could withdrawal money from the account.

In both remote-signer and ledger scenarios, it seems we protect the keys -- they stay safe -- but the XTZ can still be transferred out and is not safe.

If we want to automate baking (remote-signer or ledger), we need to set things up this way. We can't sit around our computers all day and enter the password when prompted.

What am I missing here?

Answer 1

tezos-signer supports --require-authentication, --magic-bytes, and --check-high-watermark options. You should understand these.

$ tezos-signer man -v 3
...
  -A --require-authentication: Require a signature from the caller to sign.
...
    -M --magic-bytes <0xHH,0xHH,...>: values allowed for the magic bytes, defaults to any
    -W --check-high-watermark: high watermark restriction
      Stores the highest level signed for blocks and endorsements for each
      address, and forbids to sign a level that is inferior or equal
      afterwards, except for the exact same input data.
...
  add authorized key <pk> [-N --name <name>]
    Authorize a given public key to perform signing requests.
    <pk>: full public key (Base58 encoded)
    -N --name <name>: an optional name for the key (defaults to the hash)

The Ledger baking app by Obsidian validates the magic byte, allowing only 0x01 and 0x02, which are used for blocks and endorsements (respectively). You can find these magic bytes in signer_messages.ml. The "Generic_operation" 0x03 magic byte is used for all other signed operations defined by the protocol: transfers, originations, delegation, voting, etc.

The baking app also keeps a high watermark level to prevent doubles. You should only be able to mess this up with set ledger high watermark (with confirmation on the device), during baking app upgrades (which wipe the HWM), or by using multiple Ledgers for the same key.

If the tezos-signer is secure and working as intended, and you use at least --magic-bytes and --check-high-watermark properly, then it should work roughly like the Ledger app: someone gaining normal access should only be able to sign blocks and endorsements, without causing doubles.

That could still be bad for you, because you might miss blocks/endorsements and lose rewards. It could maybe be bad for other reasons too... But it's not signing transfers!

Using --require-authentication is probably a good idea, but we will have the same problem again. The client (e.g. baker) using a remote signer with authentication must be able to sign all requests to the signer with an authorized key, and we will have the same questions about the security of this authorized key as we did for the key signing the blocks/endorsements/etc.

Note that it should be possible to use another (local or remote) tezos-signer for the authentication key. I haven't tried this.