BitGo TSS: Uma análise técnica aprofundada

Para validar e processar qualquer transação na blockchain, é necessário assiná-la digitalmente usando chaves criptográficas especiais. Por definição, quem detém essas chaves tem o poder de realizar transações. Isso significa que é fundamental manter suas chaves em segurança.

Surgiram vários provedores para ajudar pessoas físicas e jurídicas a proteger suas chaves. Cada um deles utiliza um "esquema de assinatura digital" para proteger as informações das chaves e, assim, garantir que apenas pessoas autorizadas possam movimentar fundos.

Uma visão geral do Multi-Sig e do TSS

Dois desses esquemas de segurança se destacam dos demais: o Multi-Sig (esquema de assinatura múltipla) e o TSS (esquema de assinatura com limiar). Ambos os esquemas oferecem a segurança e a confiança necessárias para manter as chaves protegidas, embora apresentem algumas diferenças em seu funcionamento.

Tanto o Multi-Sig quanto o TSS criam assinaturas digitais utilizando criptografia de chave pública. Nesse modelo, a criptografia de chave pública baseia-se em pares de chaves pública e privada, em que a chave privada gera uma assinatura única que só pode ser autenticada pela sua chave pública correspondente.

Tanto a Multi-sig quanto o TSS evitam um ponto único de falha ao compartilhar o material secreto da chave privada entre vários participantes. Isso significa que um agente mal-intencionado precisaria atacar vários detentores da chave para recuperar a chave privada.

Uma diferença notável é que o Multi-Sig utiliza várias chaves distribuídas, sendo necessário um número mínimo de chaves para assinar qualquer transação. No TSS, por outro lado, há uma única chave, dividida em várias partes e distribuída de maneira semelhante. Ele também exige um número mínimo - ou seja, um número mínimo de partes da chave necessárias para assinar uma transação.

Entendendo a SST

Utilizando o protocolo de geração distribuída de chaves, o TSS permite que várias partes contribuam para o processo de geração de chaves. Ele também cria uma assinatura digital sem revelar a chave privada em nenhum momento do processo.

Durante uma transação, cada participante gera um valor destinado aos demais e, em seguida, compartilha esses valores ao longo de várias rodadas. Ao combinar as partes secretas, cada participante pode então gerar sua própria parte da chave privada. Durante a assinatura, basta que o número mínimo de participantes se reúna para obter a assinatura final.

Ao longo desse processo, a chave privada nunca é gerada - o que significa que ela nunca é exposta. Um agente mal-intencionado precisaria comprometer pelo menos o número de participantes exigido pelo limite para conseguir recuperar a chave privada.

Uma analogia muito utilizada para o TSS consiste em calcular o salário médio de um grupo de pessoas sem revelar o salário de cada um.

Digamos que haja quatro pessoas: Arnold, Bonnie, Chen e Daniel. Arnold ganha US$ 45.000, Bonnie ganha US$ 41.000, Chen ganha US$ 53.000 e Daniel ganha US$ 27.000 - totalizando US$ 166.000.

Agora, cada participante divide seu salário em quatro números aleatórios cuja soma resulta no seu salário individual.

• Arnold divide seu salário em quatro valores aleatórios: -1.000, 30.000, 1.000 e 15.000. Arnold divide 30.000 com Bonnie, 1.000 com Chen e 15.000 com Daniel.

• Bonnie divide seu salário em quatro valores aleatórios: 23.000, 7.000, 9.000 e 2.000. Bonnie divide 7.000 com Arnold, 9.000 com Chen e 2.000 com Daniel.

• Chen divide seu salário em quatro valores aleatórios: 5.000, 20.000, 25.000 e 3.000. Chen divide 20.000 com Arnold, 25.000 com Bonnie e 3.000 com Daniel.

• Daniel divide seu salário em quatro valores aleatórios: 3.000, 5.000, 10.000 e 9.000. Daniel divide 5.000 com Arnold, 10.000 com Bonnie e 9.000 com Chen.

Em seguida, cada um monta as peças que recebeu dos outros:

• Arnold soma todos os números recebidos de cada grupo com -1.000, o que resulta em 31.000

• Bonnie soma todos os números recebidos de cada grupo, que totalizam 23.000, o que dá um total de 88.000

• Chen soma todos os números recebidos de cada parte com 5.000, o que resulta em 24.000

• Daniel soma todos os números recebidos de cada grupo com 3.000, o que dá um total de 23.000

Por fim, todas as partes se reúnem e somam os valores finais que calcularam, que totalizam 166.000. Em seguida, dividem esse valor por 4 para calcular o salário médio: 41.500 dólares.

Arnold + Bonnie + Chen + Daniel = 166 mil

Sem nunca revelar o salário individual de ninguém, o grupo conseguiu calcular o seu média salário.

O TSS funciona de maneira semelhante. A assinatura final - semelhante ao salário médio em nosso exemplo - pode ser gerada pela combinação de partes secretas, que seriam os valores aleatórios gerados por cada parte, sem revelar a parte da chave privada de cada uma (que seriam os salários individuais em nosso exemplo acima).

O TSS não deve ser confundido com o Shamir's Secret Sharing (SSS). No SSS, a chave privada é dividida em partes (fragmentada) e distribuída entre os participantes. Para assinar uma transação, os detentores dos fragmentos se reúnem para reconstruir a chave privada.

No SSS, a chave privada é criada tanto durante a geração da chave quanto durante a assinatura. Isso cria uma vulnerabilidade potencial, na qual um invasor poderia expor e recuperar a chave privada por meio de um ataque man-in-the-middle.

O TSS, no entanto, elimina esse risco. Como ele nunca gera a chave privada em nenhum momento do processo - seja durante a geração da chave ou a assinatura da transação -, ele está imune a essa vulnerabilidade específica.

Como o TSS se compara ao Multi-Sig

O TSS e o Multi-Sig são otimizados para objetivos ligeiramente diferentes.

Prestação de contas: Se os usuários finais quiserem saber quais partes participaram da assinatura da transação, as carteiras Multi-Sig são a melhor opção. A blockchain registra exatamente qual chave foi usada, o que permite rastreá-la retroativamente. Já o TSS registra apenas se um limite mínimo de partes da chave foi utilizado - e não quais, especificamente. Portanto, não há uma maneira direta, na própria blockchain, de identificar quem participou da assinatura da transação.

Compatibilidade: Nem todos os protocolos oferecem suporte nativo à Multi-Sig. Por exemplo, o BTC oferece suporte nativo ao esquema Multi-Sig, graças ao seu padrão Pay to Script Hash (P2SH), no qual o usuário final pode especificar quantas assinaturas são necessárias para enviar uma transação a partir de um endereço - mas isso não se aplica a certas outras blockchains.

Se o protocolo não oferecer suporte nativo à Multi-Sig, é necessário criar um contrato inteligente para proporcionar a mesma funcionalidade. Se o contrato inteligente não tiver sido devidamente auditado, ele pode estar sujeito a vulnerabilidades, como no caso do Vulnerabilidade nas carteiras Parity no qual foram roubados cerca de US$ 30 milhões. Leva tempo para escrever contratos inteligentes de forma segura e submetê-los a uma auditoria, de preferência por uma empresa terceirizada, o que tende a retardar o processo de adição de suporte a novas moedas.

Custo: As transações Multi-Sig contêm mais dados, pois incluem várias assinaturas por transação, que precisam ser armazenadas e verificadas na cadeia. Já as transações TSS contêm apenas uma assinatura e dispensam a necessidade de contratos inteligentes adicionais - resultando, assim, em menos dados na cadeia. Isso torna o TSS um pouco mais econômico em comparação com o Multi-Sig no que diz respeito às taxas de gás.

Velocidade: O Multi-Sig e o TSS oferecem velocidades de transação comparáveis. Seria de se esperar que o Multi-Sig fosse mais lento, já que gera múltiplas assinaturas que precisam ser verificadas na cadeia. O TSS, no entanto, tem seu próprio desafio, envolvendo mais trocas de mensagens entre os participantes para gerar a transação inicialmente. De qualquer forma, tudo isso é um pouco irrelevante: a velocidade de uma blockchain é geralmente limitada pelo seu próprio protocolo, mais do que pelo esquema de assinatura utilizado por uma carteira específica.

Flexibilidade: O TSS é mais flexível para os provedores implementarem, pois é mais independente de protocolos do que o Multi-Sig; ele pode ser usado em qualquer blockchain sem a necessidade de contratos inteligentes. Os contratos inteligentes levam tempo para serem desenvolvidos e precisam passar por auditorias minuciosas. Com o TSS, qualquer moeda pode ser integrada rapidamente a aplicativos web3.

Como a solução TSS da BitGo se compara a outras soluções de MPC

Embora o TSS tenha origem no MPC (Computação Multipartidária) - um esquema de segurança alternativo -, a solução TSS da BitGo resolve os seguintes problemas que afetam algumas das implementações atuais de MPC/TSS disponíveis no mercado:

Prestação de contas. Por natureza, o TSS não revela quem assinou uma transação na blockchain. A BitGo, no entanto, mantém registros seguros e detalhados que indicam quais partes da chave foram utilizadas em uma determinada transação.

A solução TSS da BitGo segue nosso modelo Multi-Sig, no qual existem partes da chave do usuário, da BitGo e de backup, respectivamente, e duas dessas partes precisam ser combinadas para formar uma assinatura. Armazenamos registros em nossa plataforma indicando quais das três partes da chave foram utilizadas durante a assinatura da transação e, em seguida, protegemos esses registros para garantir que sejam imutáveis.

Tecnologia desenvolvida especificamente para esse fim. A BitGo não depende de soluções de terceiros para proteger as partes das chaves da BitGo. Em vez disso, a BitGo conta com uma equipe dedicada de P&D para desenvolver Módulos de Segurança de Hardware (HSM) adaptados para criptomoedas.

Ao projetar nossos HSMs, nos protegemos contra ataques à cadeia de suprimentos. Também não assinamos transações cegamente, o que representa um risco nos HSMs tradicionais, que foram desenvolvidos para um mundo anterior às criptomoedas. Em vez disso, os HSMs da BitGo, projetados especificamente para esse fim, realizam verificações adicionais em cada transação que recebem antes de assiná-la completamente e enviá-la para a blockchain.

Abordagem híbrida. A BitGo não depende exclusivamente de uma determinada tecnologia para proteger as partes da chave; garantimos a continuidade dos negócios por meio de uma abordagem diversificada e híbrida, na qual diferentes tipos de tecnologias armazenam e protegem as partes da chave.

A parte da chave da BitGo - também conhecida como parte da chave da plataforma - permanece sob a custódia da BitGo e é protegida pelo nosso Módulo de Segurança de Hardware (HSM) desenvolvido especificamente para esse fim. A parte da chave do usuário, por sua vez, permanece sob a custódia do cliente.

A tecnologia do cliente que protege a parte da chave do usuário pode ser um TPM, um HSM ou qualquer enclave seguro implantado no local ou na nuvem. A chave de backup é protegida offline para fins de backup e recuperação de desastres.

Com uma abordagem híbrida, a BitGo evita um ponto único de falha: se for detectada uma vulnerabilidade em uma determinada tecnologia que protege o material de chave, todo o material de chave fica em risco e, consequentemente, também os fundos administrados por essa tecnologia.

Se a empresa descobrir a vulnerabilidade antes que ela seja explorada, ela precisa encontrar uma correção o mais rápido possível e suspender seus serviços até que a correção seja disponibilizada. Caso não haja uma correção disponível, ela precisa encontrar uma nova tecnologia para migrar seu material de chave, o que pode levar meses e resultar em interrupções no serviço. A BitGo resolve esse problema ao não depender de uma única tecnologia para proteger as partes da chave do TSS.

A abordagem híbrida da BitGo também garante a continuidade dos negócios, pois as tecnologias que utilizamos para proteger as partes da chave estão geograficamente separadas. No caso de um desastre natural, depender de um único local geográfico poderia resultar na perda total dos fundos do cliente.

Revisão por pares. Muitas soluções de TSS não são de código aberto nem foram testadas em condições reais, o que significa que podem conter vulnerabilidades ainda não identificadas. Atualmente, muitas empresas recorrem à criptografia proprietária para encobrir o fato de que apressaram o trabalho na tentativa de chegar mais rapidamente ao mercado. Isso significa que é bem provável que existam vulnerabilidades na tecnologia criptográfica que possam ser e serão exploradas no futuro - tudo devido à falta de testes e transparência.

Especialista em segurança Bruce Schneier argumenta que só porque você O fato de não conseguir decifrar o código que você criou não significa que ninguém pode. Da mesma forma, OWASP (o Open Web Application Security Project) afirma: "Não se deve confiar em algoritmos de criptografia proprietários, pois eles geralmente se baseiam na 'segurança por obscuridade' e não em fundamentos matemáticos sólidos. Esses algoritmos devem ser evitados, se possível."

Tornamos o nosso código aberto e criamos um programa de recompensa por falhas para resolver essa questão, pois acreditamos que essa é a única maneira de garantir a segurança dos nossos clientes. Nossa tecnologia é comprovada e testada em condições reais - você não precisa acreditar apenas na nossa palavra.

Chaves de backup. Algumas implementações do TSS tratam todas as chaves de forma idêntica e não destinam nenhuma delas para fins de backup. No entanto, os clientes precisam ser capazes de assinar transações sem a necessidade de provedores de serviço. Se o provedor de serviço estiver indisponível devido a um desastre natural, falha tecnológica ou interrupção do serviço, o cliente ainda deve ser capaz de processar suas transações.

Por isso, a BitGo atribui uma das partes da chave a ser utilizada para fins de backup sob a custódia do cliente, de modo que os usuários possam processar transações tanto com as partes da chave do usuário quanto com as partes da chave de backup.

Isso também protege os clientes nos casos em que perdem uma parte da chave - por exemplo, se o detentor da parte da chave do usuário deixar a empresa ou se uma senha for perdida. Nesse caso, o usuário ainda poderia usar suas partes de chave de backup para assinar transações juntamente com as partes de chave da BitGo.

Para saber mais sobre as carteiras BitGo, entre em contato com sales@bitgo.com. Para participar do nosso programa de recompensa por bugs, consulte nossa página do programa para mais informações.