Ataques ao protocolo Bitcoin: o que são Replay Attack e 51% Attack?

johannes-w-251375-unsplash

Dizer que a informação guardada num protocolo blockchain está 100% segura e que, uma vez registada, é impossível ser alterada ou adulterada, não é o mesmo que dizer que é impossível atacar um protocolo blockchain.

Sim, é possível, se não forem respeitadas as regras da criptografia.

Criptografia moderna é a intersecção de várias disciplinas: matemática, ciências da computação, engenharia elétrica e ciências da comunicação.

As soluções descentralizadas, sem uma autoridade central, que os protocolos blockchain proporcionam apenas são possíveis devido ao uso de criptografia.

No artigo de hoje, vamos explorar dois tipos de ataques possíveis ao protocolo Bitcoin e à grande maioria dos outros protocolos blockchain.

  1. Replay attack (ataque repetição)
  2. 51% attack (ataque 51%)

Ficar a conhecer como funcionam estes ataques dá-nos um conhecimento mais profundo da tecnologia.

O motivo pelo qual apenas abordaremos dois tipos de ataque é por estes serem os mais populares e conhecidos. No futuro pretendo escrever mais sobre este tema e outros ataques.

Quando ouvimos pessoas a discutir Mining e Proof of Work, é comum ouvirmos alguém mencionar também a probabilidade de um 51% attack.

Da mesma forma, quando se discutem Forks, é frequente ouvirmos os termos replay attack e replay protection (que é a proteção contra replay attacks).

(Se ainda não dominam os conceitos de Hard e Soft Forks sugiro a leitura do meu artigo “Forks do protocolo blockchain: como surgiram Litecoin e Bitcoin Cash. Provavelmente será complicado acompanhar este texto sem esse conhecimento).

REPLAY ATTACKS

Quando ocorre um Hard Fork e apenas alguns dos nodes adoptam o upgrade existe uma separação da comunidade e um novo protocolo é criado. Foi o que aconteceu, por exemplo, com Bitcoin Cash em 2017.

Numa situação destas, as private keys que tenham sido criadas antes do Fork, controlam agora os mesmos UTXO’s, ou addresses, em ambos os protocolos. No original e no novo.

(Escrevi também um artigo sobre private e public keys e outro onde abordo os conceitos de UTXO e transações se quiserem avivar a memória).

É por este motivo que, quando ocorre um Hard Fork passamos a ter o mesmo número de moedas no novo protocolo. Se tinhamos, por exemplo 10 BTC (bitcoin) antes do Fork, passámos a ter também 10 BCH (bitcoin cash) depois do Fork.

É importante ainda relembrar como são criadas transações no protocolo Bitcoin:

  1. Wallet constrói a transação
  2. Wallet “decide” o valor da fee
  3. Wallet define os inputs e outputs
  4. Wallet assina a transação
  5. A transação é propagada, ou anunciada ao resto da rede

Este último ponto é importante quando falamos de replay attacks. Vamos analisar porquê.

Se as private keys criadas antes do Fork controlam agora os mesmos addresses em ambos protocolos, então as transações assinadas no protocolo A são agora também válidas no protocolo B, e vice-versa.

Para facilitar a compreensão vamos assumir que o protocolo A é o protocolo Bitcoin e o B é o protocolo Bitcoin Cash.

Suponhamos que a Alice tem uma loja de ecommerce e o Bob faz uma compra no valor de 0.1 BTC (bitcoin).

A Alice pode agora pegar nessa transação e repeti-la também no protocolo Bitcoin Cash uma vez que, como vimos, ambos os protocolos utilizam as mesmas private keys e os mesmos UTXO’s.

Estamos perante uma situação de replay attack.

No entanto, existem obviamente mecanismos de defesa. Cada vez que existe um Hard Fork duas situações são possíveis.

Uma delas é conhecida como Mandatory Replay Protection (proteção de repetição obrigatória) e foi o que aconteceu, por exemplo, com o protocolo Bitcoin Cash.

Neste caso, altera-se o formato da transação no novo protocolo, de forma a que as transações não mais possam ser válidas em ambos os protocolos simultaneamente.

Esta alteração de formato é pré-definida e, como o nome indica, toda a rede é forçada a adoptá-la.

A outra situação possível é conhecida como Opt-in Replay Protection (proteção de repetição opcional). Como o nome indica, ela não é obrigatória.

Neste caso, é introduzida uma nova regra que dá a possibilidade aos participantes da rede de alterarem o formato das suas transações (caso queiram), de acordo com a nova regra, de forma a que esta seja não-replicável na rede original.

A definição é um pouco vaga. Mas a verdade é que não existe uma regra oficial. Diferentes Forks podem fazê-lo de formas diferentes. O importante a reter é que esta alteração do formato da transação não é obrigatória, é opcional.

Existem ainda alguns Forks que nem sequer se preocupam com replay protection, o que é obviamente muito grave. Sempre que nos deparamos com um Fork, é essencial perceber como é que ele garante a proteção contra ataques de repetição (replay attacks).

51% ATTACKS

O ataque 51% é um ataque teórico. A teoria diz que, se alguém detiver mais do que 50% do poder de hashing do protocolo blockchain, essa pessoa ou entidade, consegue corromper a rede.

Vamos explorar para perceber.

Importa recordar a regra de ouro nos protocolos blockchain: “a corrente mais longa ganha sempre”

Se existem duas versões da verdade, isto é, duas versões da blockchain, a rede escolherá sempre a versão mais longa.

(Para melhor compreensão desta regra aconselho a leitura do meu artigo sobre mining e puzzles criptográficos).

Imaginemos agora o seguinte cenário, e voltemos a usar o protocolo Bitcoin para facilitar: paralelamente à rede Bitcoin, existe uma outra rede, clandestina, que também esta a minerar blocos do protocolo Bitcoin.

Mas esta rede clandestina não anuncia os seus blocos publicamente. E tem um maior poder de hashing do que a rede legítima.

Se quisermos, podemos imaginar um grupo de miners com mais de 50% do poder de hashing, que continuou a minerar blocos mas deixou de propagá-los ou anunciá-los à rede, propositadamente.

A esta situação de mineração de blocos em segredo, isto é, sem propagação pela rede, damos o nome de selfish mining, ou em português, mineração egoísta.

Neste caso, este grupo ilegítimo de miners, consegue minerar a blockchain mais rapidamente. E quanto mais tempo passa, mais longa fica a sua versão (secreta) da blockchain.

Ao mesmo tempo, os miners legítimos do protocolo continuam a minerar blocos, mas a um ritmo mais lento devido ao seu menor poder de hashing.

Além disso, uma vez que a rede ilegítima nunca anuncia os seus blocos, o Mining Difficulty (dificuldade de mining), nunca se ajusta e, por isso, mantém-se mais baixo que na rede legítima, o que contribui para uma maior facilidade e rapidez de mineração.

(Mais sobre Mining Difficulty aqui.)

Mais cedo ou mais tarde, esta rede ilegítima irá anunciar a sua versão da blockchain ao resto da rede.

Esta versão é aparentemente legítima e, naturalmente mais longa. Assim, quando a restante rede se deparar com a nova versão, irá adoptá-la.

Mas qual o incentivo para este tipo de ataque?

Suponhamos que eu sou um dos hackers e vou fazendo varias compras que são validadas pela rede legítima.

Quando a versão ilegítima for adoptada, todas as compras que fiz serão revertidas e recuperarei as bitcoins que gastei. Isto porque não incluí, naturalmente, estas transações na versão ilegítima da blockchain que anunciei à rede – e que agora passa a ser a oficial.

No entanto, existem inúmeras razões que tornam este tipo de ataque impossível (ou altamente improvável), que mais do que tudo, se devem a um jogo de incentivos – ou falta deles.

Primeiro, seria extremamente caro conseguir juntar um poder de hashing capaz de derrubar a rede. Os hackers acabariam por gastar demasiado dinheiro em hardware e eletricidade, o que muito dificilmente tornaria o seu ataque lucrativo.

Além disso, quando a nova versão (ilegítima) da blockchain fosse aceite, o valor da bitcoin provavelmente cairia imediatamente para um valor perto de zero, fazendo com que todas as bitcoins que eventualmente recuperassem passassem a não ter qualquer valor.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s

search previous next tag category expand menu location phone mail time cart zoom edit close