원격 서명자 또는 원장을 사용하면 실제로 보안이 향상됩니까?

Question

원격 서명자 또는 원장을 사용하면 실제로 보안이 향상됩니까?

- 2
- 147 2019-04-04
TL; DR 원격 서명자 또는 원장을 사용하면 비밀 키를 보호 할 수 있습니다. 그러나 계정에서 XTZ가 인출되는 것을 방지하지 않습니다. 베이커에 접근 할 수있는 사람은 누구나 간단한tezos-client 명령을 사용하여 자금을 인출 할 수 있습니다. 맞습니까?
<시간>
나는이 모든 것을 알아 내고 밤에 안전하게 잠을 자고있는 내 작은 테 지의 아늑한 느낌을 받았다고 생각했습니다. 하지만 이제 나는 그들을 보호하기 위해 내가 한 모든 것에 의문을 제기하고 있습니다. 한두 달 전에 솔로 베이킹의 보안에 대한 질문 을 요청했는데 이제 나를 괴롭히기 위해 돌아 왔습니다.

간단한 요약 :

저는 예금을 충당하기 위해 최소 XTZ 만 가진 제빵사가 있습니다. Ledger 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 삭제) 중에 또는 동일한 키에 대해 여러 Ledger를 사용하는 방식으로 만 엉망이 될 수 있습니다.

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.

출처
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-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