l'utilizzo di un firmatario remoto o di un libro mastro migliora davvero la sicurezza?

Question

l'utilizzo di un firmatario remoto o di un libro mastro migliora davvero la sicurezza?

- 2
- 147 2019-04-04
TL; DR L'utilizzo di unfirmatario remoto o di un libromastrofa un ottimo lavoronelproteggere le chiavi segrete. Manonprotegge dal ritiro di XTZ dagli account. Chiunque abbia accesso alpanettierepuòprelevarefondi daesso utilizzando un semplice comandotezos-client. È corretto?

Pensavo di aver capitotuttoe avevo lapiacevole sensazione chei mieipiccolitezzies dormissero al sicuro lanotte. Ma ora stomettendoin dubbiotutto quello che hofattopermetterli al sicuro. Unmese o duefa hoposto una domanda sulla sicurezza con la cotturain solitaria e ora ètornato aperseguitarmi.

Riepilogo rapido:

Ho unpanettiere con solo unminimo di XTZper coprirei depositi. Ho unindirizzo KT1 originato che ho creato da unindirizzoimplicito di Ledger TZ1. Lamaggiorparte deimiei XTZ sono ragionevolmente sicuri.

Tuttavia,perproteggere l'XTZ delmiofornaio,ho deciso diimpostare unfirmatario remoto su una scatola diversae moltoisolata. Pertuttigli scopipratici soloilmionodo Tezospuòparlarglitramite una reteprivata.

Come ha sottolineato Lukenellamiaprecedente domanda collegata a sopra,e quello che all'epocanon avevo capito completamenteera:

Poichéilfirmatarionon dispone di autenticazione,chiunquepuò accedere a iltuo sistema di cotturain qualchemodopuòfirmaremessaggi conilfirmatario remoto, compresoiltrasferimento del saldo dellatua obbligazione/deposito.

Ora capiscoperfettamente cosaintendeva. Allora qual èilpunto di avere unfirmatario remoto dato questoproblema?

Anche se stessi usando un libromastro,ilproblemanon sarebbe lo stesso? Sepotessi accedere al sistema di cottura,potreiprelevare denaro dal conto.

Inentrambigli scenari difirma remotae registro,sembra cheproteggiamo le chiavi - rimangono al sicuro -ma l'XTZpuò ancoraesseretrasferitoe non è sicuro.

Se vogliamo automatizzare la cottura (firmatario remoto o libromastro),dobbiamoimpostare le cosein questomodo. Nonpossiamo stare sedutiintorno ainostri computertuttoilgiornoe inserire lapassword quando richiesto.

Cosami manca qui?

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 risposta

voti

Tom · Accepted Answer · 2019-04-05

6

2019-04-05

tezos-signer supporta le opzioni --require-authentication,--magic-bytese --check-high-watermark. Dovresti capirli.

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

L'app di cottura Ledger di Obsidian convalidailmagicbyte,consentendo solo 0x01e 0x02,che vengono utilizzatiperblocchie approvazioni (rispettivamente). Puoitrovare questimagicbytesin

L'app di cotturamantiene anche un livello difiligrana altoperevitare doppioni. Dovrestiesserein grado di rovinaretutto con set ledger high watermark (con conferma sul dispositivo),durantegli aggiornamenti delle app di cottura (che cancellano l'HWM) o utilizzandopiù Ledgerper la stessa chiave.

Seilfirmatario ditezos è sicuroe funziona comeprevistoe utilizzi almeno --magic-bytese --check-high-watermark correttamente,allora dovrebbefunzionarepiù omeno come l'app Ledger: qualcuno che ottiene un accessonormale dovrebbeesserein grado difirmare soloblocchie approvazioni,senza causare doppi.

Potrebbe comunqueessere dannosoperte,perchépotrestiperdereblocchi/approvazionie perderepremi. Potrebbeessere unmale ancheper altrimotivi ... Manon sitratta difirmaretrasferimenti!

L'uso di --require-authentication èprobabilmente unabuonaidea,ma avremo dinuovo lo stessoproblema. Il client (es. Panettiere) che utilizza unfirmatario remoto con autenticazione deveesserein grado difirmaretutte le richieste alfirmatario con una chiave autorizzatae avremo le stesse domande sulla sicurezza di questa chiave autorizzata come abbiamofattoper la chiave chefirmai blocchi/endorsements/ecc.

Nota che dovrebbeesserepossibile usare un altrotezos-signer (locale o remoto)per la chiave di autenticazione. Non l'hoprovato.

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.

fonte
Tom

Ah,questa è un'ottimainformazione.Graziemille.Per quanto riguarda l'utilizzo di --magic-bytese --require-authenticationinsiemein modo specifico,questa sembra la soluzioneperfetta.Se utilizzoentrambi questiflag,significa che le richieste con 0x01e 0x02passeranno senza richiedere la convalida,mailtrasferimentoe altre richieste richiederanno comunque l'autenticazione?Se è così,èesattamente quello che voglio.Maforsenonfunzionain questomodo come dici allafine deltuopost "L'uso di --require-authentication èprobabilmente unabuonaidea,ma avrai dinuovo lo stessoproblemaper la chiave di autenticazione".

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
modifica:passerà senza richiedere * autenticazione *

edit: will pass through not requiring *authentication*
- 0
- 2019-04-05
- lostdorje
Un vecchioticket,main base a questo: https://gitlab.com/tezos/tezos/issues/185 sembra,sì,iniziareilfirmatario conentrambii flag --magic-bytese --require-authentication dovrebbefunzionare.Imessaggi 0x02passeranno senzabisogno di ulteriori autenticazioni/passwordecc. 0x03 (transazioni) richiederà lafirma (o come haimenzionatoe collegato,forseilnuovo valore è 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,la convalidae l'autenticazione delmagicbyte sono ortogonali.Se è richiesta l'autenticazione,è sempre richiesta.Sei magicbyte vengono convalidati,vengono sempre convalidati (nessun dato con unmagicbyte diverso verràfirmato,autenticazione omeno). Aggiornerò la rispostaperessere unpo 'più chiaro suimagicbytes.

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
Hogiocato dipiù con le cosee ho raggiunto quelposto diblocco.Ha senso.Le dueidee dovrebberoessere ortogonali.D'altraparte,questo sembra un caso d'usomolto valido.Consenti alfirmatario difirmareblocchiinfornatie firmare approvazioni senza autenticazione aggiuntiva.Tuttavia,se arriva unblocco 0x03 o 0x04ecc.,Richiedi che abbia un'autenticazioneextra.Questo sarebbemolto utile,anche se c'è ancorailproblema deipagamenti automatici (adesempio:backerei)e lasciarlofunzionare senza doverlo autenticaretuttoiltempo.

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
Ignora quello che ho detto su 0x04.Ho cercato di chiarire.Potrebbeinteressarti 0x04 seprovi a usare untezos-signerperfirmare richieste autenticate a un altrotezos-signer;è lì che viene utilizzato.

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