--require-authenticationと互換性のあるリモート署名者でベイクしますか？

Question

--require-authenticationと互換性のあるリモート署名者でベイクしますか？

- 10
- 128 2019-02-16
クライアント操作の場合、--require-authenticationでリモート署名者を使用するには、クライアントキーの復号化パスワードを手動で入力する必要があります.

どこにも文書化されていません-これはベーキングと互換性がありませんか?ベイク処理を設定するときにクライアントキーを復号化する方法はありません.ベイク処理のために認証がバイパスされていないと思います.

ありがとう

For client ops, using a remote signer with --require-authentication requires manually entering the client key's decryption password.

It's not documented anywhere -- is this incompatible with baking? There's no way that I'm aware of to decrypt the client key when setting up baking and I assume authentication isn't bypassed for baking.

Thanks

baking

- alphanetでは認証キーのパスワードを入力しなくても機能しますが、mainnetでは端末でパスワードを要求しますが、パスワードを入力する端末がないために失敗します.私もこれに対する答えを探しています.
  
  On alphanet it works without entering the password for the authentication key, but in mainnet it ask for password on terminal, but due to absence of any terminal to enter the password it fails. I am also looking out for an answer to this.
  - 0
  - 2019-02-22
  - Sachin Tomar
- ただし、tezos-signerコマンドで--require-authenticationフラグを使用しないことで、認証方法をバイパスできます.ただし、認証方法をバイパスする場合は、ファイアウォールを使用してサーバーとポートへのアクセスを制限してください.
  
  Although you can bypass the authentication method by not using --require-authentication flag in tezos-signer command. Make sure to restrict access to your server and port using firewall though if you bypass the authentication method.
  - 0
  - 2019-02-25
  - Sachin Tomar

3 回答

投票

- 3
- 2019-02-25
tezosメインネットでは、暗号化されていない形式でキーを生成することはできません.したがって、キーを復号化するにはパスワードを入力する必要があります.

解決策は、暗号化されていないキーをインポートしてから、リモート署名者との通信を認証することです. tezboxウォレットを使用して暗号化されていないキーを生成し、秘密キーをコピーして、以下のコマンドを使用してサーバーにインポートしました.
>
./mainnet.sh client import secret key auth-alias unencrypted:edskxxxxxxxxxxxxxTnZR
On tezos mainnet, you cannot generate your key in unencrypted form. So you have to enter the password to decrypt the key.

Solution is to import an unencrypted key and then use is to authenticate any communication with remote-signer. I used tezbox wallet to generate unencrypted keys and then copy the private key and imported to my server using below command.

./mainnet.sh client import secret key auth-alias unencrypted:edskxxxxxxxxxxxxxTnZR
- 暗号化されていない暗号化されていない秘密鍵を生成し、これを別のサーバーにコピーすることは本質的に*安全ではありません*?
  
  isn't it intrinsically *unsafe* to generate an unencrypted unencrypted private keys and copy this around for another server ?
  - 0
  - 2019-02-25
  - Ezy
- はい、このキーをベーキングキーとして使用している場合は安全ではありません.ただし、ここでの唯一の目的は認証キーとして使用することですが、秘密キーをサーバーにコピーする際には、明らかに予防策を講じる必要があります.秘密鍵をコピーせず、サーバー上でのみ秘密鍵を生成したい場合は、https://github.com/TezTech/eztzを使用できます.
  
  Yes it is unsafe if you are using this key as baking key. But here the only purpose for this is to be used as authentication key, but obviously precautions need to be taken while copying your private key to the server. If you don't want to copy the private key and want to generate the private key on the server only you can use https://github.com/TezTech/eztz
  - 0
  - 2019-02-25
  - Sachin Tomar
- 単純に元帳を使用するのはどうですか?
  
  how abt simply using ledger ?
  - 1
  - 2019-02-25
  - Ezy
- はい、元帳を使用するのが最も安全な方法ですが、私は元帳の経験がありません.このためのドキュメントは本当に役に立ちます.
  
  Yes using ledger would be most secure way but i don't have any experience with ledger. Any documentation for this would be really helpful.
  - 0
  - 2019-02-25
  - Sachin Tomar
- TSEでここを検索して、始めるための答えがあります.例:https://tezos.stackexchange.com/q/395/118およびhttps://tezos.stackexchange.com/q/477/118.これが十分でない場合は、新しい質問をしてください！
  
  you can search here on TSE there are answers to get you started. Eg: https://tezos.stackexchange.com/q/395/118 and https://tezos.stackexchange.com/q/477/118 . If this is not sufficient then feel free to ask a new question!
  - 0
  - 2019-02-25
  - Ezy
- 間違いなく、彼は暗号化されていないキーを使用すべきではありません-それは本当にひどい考えです.
  
  Definetly he shouldn't use unencrypted keys - that's a really terrible idea.
  - 1
  - 2019-02-25
  - moonrider_unchained
- ネットワークにアクセス可能なマシンに暗号化されていないキーを配置することは、おそらく悪い考えです.
  
  It's probably a bad idea to have unencrypted keys on a network-accessible machine.
  - 0
  - 2019-02-26
  - latte_jed
- 1
- 2019-12-04
両方の回答よりもセキュリティを強化する方法があります(今日現在) https://tezos.stackexchange.com/a/607/29 (回答A)および https://tezos.stackexchange.com/a/598/29 (回答B)提案します.

署名者の場合

マジックバイト0x01,0x02のみを受け入れます

署名者はファイアウォールで保護されており、パン屋のIPからのリクエストのみを受け入れます

トンネルは暗号化されています(できれば)

暗号化されていない署名者認証キーをパン屋に残しておいてもかまいません.回答Bの利便性が得られますが、署名者認証キー(回答A)を使用するというセキュリティが追加されています.すべての可能性からユーザーを保護するわけではありません(現時点では、これらの方法の1つ)ですが、暗号化されていない署名者認証キーを使用することで、依然として回避できますいくつかの潜在的なリスク.たとえば、不正なマシンがIPを取得した場合(たとえば、誤ってIPを解放した場合、またはホストがIPを誤ってルーティングした場合)、攻撃者は単純にダブルベイク/承認することさえできません.

少しの利益のためにもっと仕事が必要だと言う人もいるかもしれませんが、私は少し妄想的で、もっと簡単なルートを取るのは好きではありません.

結論として、--require-authenticationは他の予防策の代わりにはなりません.
There is a way to have more security than both answers (as of today) https://tezos.stackexchange.com/a/607/29 (Answer A) and https://tezos.stackexchange.com/a/598/29 (Answer B) suggest.

If the signer

only accepts magic bytes 0x01,0x02,

and the signer is firewalled to only accept request from the baker's IP

and the tunnel is encrypted (preferably),

it is ok to leave the unencrypted signer auth key in the baker. You get the convenience of answer B, but with the added security of using a signer auth key (answer A). It doesn't protect you against every possibility (it is not possible at this time to pass the password to the baker/endorser, AFAIK even using one of these methods), but by having an unencrypted signer auth key you are still avoiding some potential risks . For example, if a rogue machine obtains your IP (say you release the IP by accident, or your host misroutes your IP) the attacker still won't be able to even simply double bake/endorse.

Some might say it is more work for little gain, but I am a bit paranoid and don't like to take the easier route.

Bottom line, --require-authentication is not a substitute for other precautions.

latte_jed · Accepted Answer · 2019-02-26

2

2019-02-26

コメントで触れたように、これに対する最も正しい答えは次のとおりです.

いいえ、ベーキング用の署名者で--require-authenticationを使用することはできません.TTYが存在せず、承認/ベイク操作を実行する必要があるときに認証キーを復号化することはできません.

ここでのベストプラクティスは、署名者とパン屋の間で暗号化されたトンネルを使用し、署名者がネットワークに直接アクセスできないようにすることです.