使用远程签名者或分类帐真的可以提高安全性吗？

Question

使用远程签名者或分类帐真的可以提高安全性吗？

- 2
- 147 2019-04-04
TL; DR 使用远程签名者或分类帐在保护密钥方面做得很好.但这并不能防止XTZ从帐户中提款.能够访问面包师的任何人都可以使用简单的tezos-client命令从面包师提取资金.这是正确的吗?

我以为我已经弄清了这一切,并且对自己的小头昏昏欲睡的夜晚感到安心.但是现在,我质疑为保护它们所做的一切.我在一两个月前问过关于单独烘焙安全性的问题,现在又回来困扰我了.

快速摘要:

我有一个面包师,他至少要支付XTZ才能支付存款.我有一个从Ledger TZ1隐式地址创建的原始KT1地址.我的大多数XTZ都相当安全.

但是,为了保护面包师的XTZ,我决定在另一个非常隔离的盒子上安装一个远程签名器.出于所有实际目的,只有我的Tezos Node可以通过专用网络与之对话.

如卢克在我先前与上面相关的问题中所指出的那样,当时我还不完全了解:

由于签名者没有身份验证,因此任何人都可以登录您的烘焙系统可以通过某种方式与远程签名者签署消息, 包括您的保证金/存款的余额转帐.

现在我完全理解他的意思了.那么让远程签名者解决这个问题又有什么意义呢?

即使我使用分类帐,问题是否仍会相同?如果我可以使用烘焙系统,则可以从帐户中提款.

在远程签名者和分类账两种情况下,似乎我们都可以保护密钥-它们保持安全-但是XTZ仍然可以移出并且不安全.

如果要自动化烘焙(远程签名者或分类帐),我们需要以这种方式进行设置.我们不能整天坐在电脑旁,在出现提示时输入密码.

我在这里想念什么?

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?

baking ledger remote-signer

1 个回答

投票数

Tom · Accepted Answer · 2019-04-05

6

2019-04-05

tezos-signer支持--require-authentication,-magic-bytes和--check-high-watermark选项.您应该了解这些.

 $ 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)

Obsidian的Ledger烘焙应用程序验证魔术字节,仅允许使用0x01和0x02,分别用于块和背书.您可以在 signer_messages中找到这些魔术字节.一个>. " Generic_operation" 0x03魔术字节用于协议定义的所有其他已签名操作:传输,发起,委派,投票等.

烘焙应用程序还保持较高的水印级别,以防止出现双打现象.您应该只能在烘焙应用程序升级(擦除HWM)期间,或者通过对同一密钥使用多个Ledger,使用set ledger high watermark(在设备上进行确认)来弄乱此设置.

如果tezos签名者是安全的并且可以按预期工作,并且您至少正确使用了--magic-bytes和--check-high-watermark,则它应该大致类似于Ledger应用程序:拥有正常访问权限的人应该只能签署禁令和认可,而不会引起重复.

那仍然可能对您不利,因为您可能会错过块/背书并失去奖励.出于其他原因,可能也很糟糕……但这不是在签署转帐！

使用--require-authentication可能是一个好主意,但是我们将再次遇到相同的问题.使用具有身份验证的远程签名者的客户端(例如,贝克)必须能够使用授权密钥对签名者的所有请求进行签名,并且关于此授权密钥的安全性,我们将与对块进行密钥签名时遇到相同的问题/endorsements/etc.

请注意,应该可以使用另一个(本地或远程)tezos签名者作为认证密钥.我没有尝试过.

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.

原文
Tom

啊,这是很好的信息.非常感谢.关于专门使用--magic-bytes和--require-authentication,这听起来像是完美的解决方案.如果我同时使用这两个标志,是否意味着具有0x01和0x02的请求将通过而不需要验证,但是传输和其他请求仍将需要认证?如果是这样,那正是我想要的.但是,就像您在文章末尾提到的那样,也许这种方式行不通:"使用--require-authentication可能是个好主意,但是对于身份验证密钥,您将再次遇到相同的问题."

Ah, this is great information. Thanks so much. Regarding using --magic-bytes and --require-authentication together specifically, this sounds like the perfect solution. If I use both of these flags does it mean that requests with 0x01 and 0x02 will pass through not requiring validation, but transfer and other requests will still require authentication? If so, that's exactly what I want. But perhaps it doesn't work a that way as you mention at the end of your post "Using --require-authentication is probably a good idea, but you will have the same problem again for the authentication key."
- 0
- 2019-04-05
- lostdorje
编辑:将通过不需要*验证*

edit: will pass through not requiring *authentication*
- 0
- 2019-04-05
- lostdorje
一张旧票,但根据此内容:https://gitlab.com/tezos/tezos/issues/185听起来像是的,同时使用--magic-bytes和--require-authentication标志启动签名者应该起作用.0x02消息将通过,而无需进一步的身份验证/密码等.0x03(事务)将需要签名(或者正如您提到并链接到的,也许新值是0x04?)

An old ticket, but according to this: https://gitlab.com/tezos/tezos/issues/185 it sounds like, yes, starting signer with both the --magic-bytes and --require-authentication flags should work. 0x02 messages will go through with no need for further authentication/passwords etc.. 0x03 (transactions) will require signing (or as you mentioned and linked to, maybe the new value is 0x04?)
- 0
- 2019-04-05
- lostdorje
不,魔术字节验证和认证是正交的.如果需要身份验证,则始终是必需的.如果验证了魔术字节,则它们始终都会被验证(不会对具有不同魔术字节的数据进行签名,身份验证或不进行签名.)我将更新答案,以使魔术字节更加清楚.

No, magic byte validation and authentication are orthogonal. If authentication is required, it is always required. If magic bytes are validated, they are always validated (no data with a different magic byte will be signed, authentication or not.) I will update the answer to be a bit more clear about the magic bytes.
- 0
- 2019-04-05
- Tom
我玩的更多,遇到了障碍.这说得通.这两个想法应该是正交的.另一方面,这似乎是一个非常有效的用例.让签名者在无需额外身份验证的情况下签署烘焙的区块和签名背书.但是,如果出现0x03或0x04等块,则要求它具有额外的身份验证.这将非常有用-尽管仍然存在自动付款问题(例如backerei),并且无需一直对其进行身份验证即可让其运行.

I played around with things more and hit that road-block. It makes sense. The two ideas should be orthogonal. On the other hand, this seems like a very valid use-case. Let the signer sign baked blocks and sign endorsements without extra authentication. However if a 0x03 or 0x04 etc block comes in, require it to have extra authentication. This would be very useful -- although there is still the automated payouts problem (eg: backerei) and letting that run without having to authenticate it all the time.
- 0
- 2019-04-05
- lostdorje
忽略我对0x04所说的内容.我试图澄清.如果尝试使用tezos签名者将经过身份验证的请求签名到另一个tezos签名者,则可能需要注意0x04.这就是使用它的地方.

Ignore what I said about 0x04. I tried to clarify. You might care about 0x04 if you try to use a tezos-signer to sign authenticated requests to another tezos-signer; that's where it's used.
- 0
- 2019-04-07
- Tom