リモート署名者または元帳を使用すると、セキュリティが本当に向上しますか？

Question

リモート署名者または元帳を使用すると、セキュリティが本当に向上しますか？

- 2
- 147 2019-04-04
TL; DR リモート署名者または元帳を使用すると、秘密鍵を保護するのに役立ちます.ただし、アカウントからのXTZの引き出しを防ぐことはできません.パン屋にアクセスできる人は誰でも、簡単なtezos-clientコマンドを使用してパン屋から資金を引き出すことができます.これは正しいですか?

私はこれをすべて理解し、私の小さなテジーが夜にしっかりと眠っているという居心地の良い感じがしたと思いました.しかし今、私はそれらを保護するために私がしたすべてに疑問を投げかけています. 1、2か月前にソロベーキングによるセキュリティについての質問をしました.今、私を悩ませるために戻ってきました.

簡単な要約:

私は、預金をカバーするために最小限のXTZを備えたパン屋を持っています.元帳TZ1暗黙アドレスから作成した発信KT1アドレスがあります.私のXTZの大部分はかなり安全です.

ただし、パン屋のXTZを保護するために、別の非常に隔離されたボックスにリモート署名者を設定することにしました.すべての実用的な目的で、プライベートネットワークを介して通信できるのは私のTezosノードだけです.

上記にリンクされた以前の質問でルークが指摘したように、当時私が完全に理解していなかったのは次のとおりです.

署名者には認証がないため、ログインできる人は誰でもあなたのベーキングシステムはどういうわけかリモート署名者とメッセージに署名することができます、債券/預金の残高移行を含みます.

今、私は彼の意味を完全に理解しています.では、この問題を考慮してリモート署名者がいることの意味は何ですか?

元帳を使用していても、問題は同じではないでしょうか.ベーキングシステムにアクセスできれば、アカウントからお金を引き出すことができます.

リモート署名者と元帳の両方のシナリオで、キーを保護しているようです.キーは安全に保たれていますが、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.ml . 「Generic_operation」0x03マジックバイトは、プロトコルによって定義された他のすべての署名された操作(転送、発信、委任、投票など)に使用されます.

ベーキングアプリは、ダブルを防ぐために高い透かしレベルも維持します.これを台無しにできるのは、set ledger high watermark(デバイスでの確認あり)、アプリのアップグレード中(HWMをワイプする)、または同じキーに複数の元帳を使用する場合のみです.

tezos-signerが安全で意図したとおりに機能していて、少なくとも--magic-bytesと--check-high-watermarkを適切に使用している場合は、 Ledgerアプリとほぼ同じように機能するはずです.通常のアクセス権を取得した人は、ダブルを発生させることなく、ブロックと承認にのみ署名できる必要があります.

ブロック/承認を見逃して報酬を失う可能性があるため、それでも悪い場合があります.他の理由でも悪いかもしれません...しかし、それは転送に署名していません！

--require-authenticationを使用することはおそらく良い考えですが、同じ問題が再び発生します.認証付きのリモート署名者を使用するクライアント(ベイカーなど)は、承認されたキーを使用して署名者へのすべての要求に署名できる必要があります.この承認されたキーのセキュリティについては、ブロックに署名するキーの場合と同じ質問があります./endorsements/etc.

認証キーに別の(ローカルまたはリモートの)tezos-signerを使用できる必要があることに注意してください.私はこれを試していません.

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.

ああ、これは素晴らしい情報です.本当にありがとう.特に--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
私はもっと物事をいじって、その障害にぶつかりました.それは理にかなっている.2つのアイデアは直交している必要があります.一方、これは非常に有効なユースケースのようです.署名者に焼きたてのブロックに署名させ、追加の認証なしで承認に署名させます.ただし、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-signerを使用して、別のtezos-signerへの認証済みリクエストに署名しようとすると、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