O teste de resiliência mais intenso que os algoritmos de criptografia já passaram está ocorrendo agora graças as criptomoedas. Não existe forma mais eficiente de se premiar alguém que quebre um algoritmo criptográfico: basta fazer com que a própria quebra daquele algoritmo signifique um ganho financeiro. Você não precisa se identificar, não precisa provar, não precisa de autorização. É quebrar e ganhar.
Por isso, imagine que cada chave privada é um alvo para quem tem interesse em desafiar a matemática. Cada endereço de bitcoin que compõe uma carteira é uma possibilidade a mais, e quanto maior o valor de um endereço, maior será o investimento no ataque.
Em outras palavras, depender de uma única chave privada para armazenar uma centena de Bitcoins pode não ser uma boa ideia. Inclusive, muita gente não sabe que o protocolo do Bitcoin estabelece uma camada de abstração entre a chave privada e uma carteira – a chamada de “conta”. Essa camada foi criada com o intuito de deixar o sistema mais próximo do bancário e fazer com que cada usuário tivesse suas próprias contas em um node, similar a uma agencia de banco.
Da mesma forma que as contas de banco, a abstração das contas precisava criar mecanismos que possibilitassem algumas funções iguais a do sistema bancário, incluindo a gestão de contas por várias pessoas. Essa feature em especial era extremamente difícil de ser executada no protocolo de bitcoin, uma vez que você tem a relação de 1 chave privada para 1 endereço (e por questões de segurança o sistema deveria permanecer assim).
Para solucionar este problema, criou-se um smart contract que era capaz de armazenar os Bitcoins em seu endereço, delegando sua movimentação a um conjunto de endereços, cada um com sua devida chave privada. Tornou-se possível inclusive estabelecer seleções de N/M para a movimentação (Ex: A transferência só deve ocorrer se houverem 3 de 5 assinaturas).
Essa questão tornou-se relevante para a segurança. Quer dizer, se podemos adicionar mais de uma chave privada a um smart contract (que na prática é um endereço de bitcoin como qualquer outro, como veremos mais a frente), por que não incluirmos mais chaves privadas para garantir que seja necessário um número maior de processamento para quebrar as chaves?
A parte importante de ser analisada no diagrama acima é a quantidade de chaves privadas. No exemplo, tenho 4 chaves privadas, contra 8 chaves privadas no segundo modelo. Entretanto, o interessante é que tenho exatamente o mesmo número de carteiras, contas e endereços.
Sendo assim, vamos imaginar que os endereços que tem mais de uma chave privada necessitem de 100% das chaves privadas para poder realizar uma transação. Quais são as chances de termos nossa carteira invadida por métodos de força bruta da chave privada?
Sei que você deve estar pensando: mas os métodos de força bruta contra chave privada são ineficientes. É verdade, mas vamos assumir por hora que tais métodos sejam práticos e eficientes. Atualmente eles são práticos – acho que todo desenvolvedor do protocolo já montou um brute force de chave privada baseado no alinhamento dos planetas -, mas não eficientes. Vou explicar mais na frente porque devemos considerar este cenário.
Supondo que eu gaste um esforço computacional N para ter 100% de chance de quebra de um endereço com uma única chave privada, e que eu gaste um esforço computacional P para testar uma combinação contra a chave privada. Logicamente eu terei o somatório de todos os P’s, e caso eu os dividisse pelo N, eu teria 1 como resultado, uma vez que caso eu some todo o processamento que eu gastei com cada combinação, eu vou ter 100% de chance, e quando dividimos números iguais (somatório de P e o total N) o resultado é um, ok?
Agora vamos ver o que acontece com o esforço N quando aumentamos a quantidade de chaves privadas. Aqui a coisa complica mais um pouco porque duas coisas ocorrem quando adicionamos novas chaves:
Para termos 100% de certeza que testamos todas as combinações possíveis de chaves privadas, nós teremos que multiplicar o somatório dos esforços P pelo número de chaves privadas que um smart contract possui – e em muitos casos não sabemos quantas chaves esse endereço tem. Quer dizer, para cada P que tivermos, teremos que testar um N inteiro dentro daquele P.
Quer dizer, a cada chave privada que você adiciona, a dificuldade de se quebrar usando métodos convencionais aumenta exponencialmente comparando a uma única chave privada. Relembro que nesse caso você precisa estabelecer que 100% das X chaves privadas sejam usados para fazer uma transação. Se você estabelecer que você pode usar 1 de X das chaves privadas para fazer a transação, você estará deixando sua conta mais insegura contra esse tipo de ataque.
Mas nem só de segurança contra força bruta vivem as multisigns. Existem outros fatores em que nós podemos inseri-las. Por exemplo, para múltiplas pessoas administrarem um mesmo endereço, é ideal que existam duas chaves privadas diferentes. Assim, caso uma chave seja comprometida, nem toda a cadeia ficará comprometida, o que é bom.
Outra coisa importante para as carteiras multisigns é que é possível estipular uma quantidade específica do total de chaves privadas existentes para se administrar uma carteira. Você pode, por exemplo, dizer que vc tem 10 chaves privadas, mas é necessário que 3 delas assinem a transação para que ela ocorra. Em alguns casos, isso é bom e pode ajudar em auditorias.
Como já falei, as carteiras multi-assinadas nada mais são do que scripts para o Bitcoin. Nesse script, a transação é assinada pelo próprio script quando recebem a assinatura correta de dois endereços comuns do Bitcoin. Quer dizer, para criar cada uma das chaves privadas, é necessário criar um endereço P2PKH antes de incluir as chaves públicas na carteira multi-assinada.
Para quem ainda não é familiarizado com o Bitcoin, recomendo dar uma pesquisada na Bitcoin Wiki, onde você poderá encontrar mais informações sobre os tipos de endereço que o Bitcoin possui.
Se você quiser ter uma carteira multi-assinada, você pode fazer uma usando alguns aplicativos de carteiras como o Electrum ou a carteira da Coinbase. A página da Coinb.in oferece um javascript para criar carteiras multi-assinadas, mas não recomendaria seu uso uma vez que não confio em nada que venha da internet de mão beijada. Se você quiser realizar esse procedimento de maneira segura, minha recomendação é lançar um node próprio e usar uma call RPC para criar. O exemplo abaixo é a call que deve ser executada no RPC do node. (exemplo retirado da Bitcoin Wiki).
bitcoind addmultisigaddress 2 '["..first bubkey","..second pubkey..","..third pubkey.."]'
Por si só, tais métodos de força bruta já são difíceis de gerar resultados – não de serem executados. A quantidade de processamento necessária torna o processo praticamente impossível. Entretanto, devemos relembrar que temos algumas ameaças próximas da realidade, incluindo um computador quântico, cuja escalabilidade é praticamente infinita uma vez que se atinja uma temperatura próxima a zero Kelvin. Além disso, me espanta que até o presente momento as pessoas não remunerem uma rede pela quebra de um hash.
Também temos o crescimento da computação elástica, o que leva a crer que dependendo do valor armazenado por uma carteira, seria possível realizar uma espécie de “Address-Value Abuse”, onde o valor armazenado por uma carteira compensaria o atacante a apostar no uso da computação elástica para tentar roubá-lo. No caso de uma rede que remunere a quebra de hashes, esse processo seria simples.
Por fim, repito uma frase retirada do filme Capitão Falcão: “Prefiro pecar pelo excesso de zelo.”
OBS: O correto é multi-assinada ou multiassinada?
This website uses cookies.