Assinaturas com Limite (Threshold Signatures)
P√°gina Inicial
Artigos
Assinaturas com Limite (Threshold Signatures)

Assinaturas com Limite (Threshold Signatures)

Avançado
Publicado em Jul 21, 2019Atualizado em Apr 29, 2021
12m
O esquema de assinaturas com limite (TSS) √© um princ√≠pio de criptografia para gera√ß√£o e assinatura de chaves distribu√≠das. O uso da TSS em clientes blockchain √© um novo paradigma que pode proporcionar in√ļmeros benef√≠cios, especialmente em termos de seguran√ßa. Em um sentido mais amplo, o TSS pode influenciar o design de sistemas de gerenciamento de chaves (como as carteiras de criptomoedas) e abrir caminho para um suporte nativo em casos de uso DeFi. Dito isto, o TSS ainda √© uma nova tecnologia, portanto, os riscos e limita√ß√Ķes tamb√©m devem ser considerados.

Neste artigo, explicaremos o que √© o TSS, quais as potenciais vantagens que ele traz para o campo da blockchain, como pode ser implementado em um cliente blockchain, como √© comparado aos sistemas Shamir secret sharing e Multisig, quais as diferentes formas de uso do TSS para a gest√£o de chaves distribu√≠da e, finalmente, discutiremos sobre seus riscos e limita√ß√Ķes.

O poder da criptografia

Para entender a tecnologia TSS, precisamos primeiro de algum conhecimento b√°sico em criptografia. Desde a d√©cada de 1970, cada vez mais sistemas de Internet (como o TLS e o PGP) empregam criptografia assim√©trica, que tamb√©m √© conhecida como criptografia de chave p√ļblica (PKC). O PKC utiliza duas chaves: uma p√ļblica e uma privada. Embora a chave p√ļblica n√£o seja secreta e possa ser publicada e utilizada por qualquer um, a chave privada √© um elemento de informa√ß√£o secreta que representa a seguran√ßa do sistema.
Encripta√ß√£o e assinaturas digitais s√£o dois dos usos mais comuns do PKC. Tanto o sistema de encripta√ß√£o quanto o de assinaturas digitais dependem de um conjunto de tr√™s algor√≠timos. O primeiro, √© respons√°vel pela gera√ß√£o do par de chaves privada e p√ļblica, o segundo pela gera√ß√£o de um texto de base/assinatura, e o terceiro pelo processo de desencripta√ß√£o/verifica√ß√£o. No que diz respeito √†s assinaturas digitais, o algoritmo de assinatura requer a chave privada, que √© de conhecimento exclusivo do propriet√°rio, para produzir uma assinatura √ļnica. A assinatura est√° anexada a uma determinada mensagem de uma forma que qualquer pessoa que tenha a chave p√ļblica possa verificar a sua autenticidade e exatid√£o.


Blockchain

N√£o h√° d√ļvidas de que a blockchain √© uma tecnologia muito poderosa. Ele fornece uma camada de consenso que organiza e registra eventos. Uma infraestrutura desse tipo proporciona, aos seus usu√°rios, potencial para construir economias e at√© mesmo governos descentralizados. Surpreendentemente, a criptografia necess√°ria para executar uma blockchain simples pode ser inteiramente baseada em assinaturas digitais. No contexto de uma Blockchain, as chaves privadas representam identidades enquanto uma assinatura √© uma afirma√ß√£o p√ļblica ou uma reivindica√ß√£o feita por alguma identidade. A blockchain ir√° ordenar as instru√ß√Ķes e valid√°-las de acordo com um conjunto de regras, que garantem, entre outras coisas, que as assinaturas s√£o corretas e n√£o podem ser falsificadas.
Ao contr√°rio da criptografia mais cl√°ssica utilizada na blockchain, a caixa de ferramentas moderna da criptografia inclui alguns incr√≠veis truques: provas de conhecimento zero (zero-knowledge proofs), criptografia homom√≥rfica e computa√ß√£o de m√ļltiplas partes (multi-party) s√£o alguns dos exemplos que podemos citar. Como vimos ao longo da √ļltima d√©cada, as pesquisas sobre blockchain impulsionaram fortemente a aplica√ß√£o da criptografia, com avan√ßos recentes em todas as aplica√ß√Ķes citadas acima e muitas outras.¬†

Neste artigo, concentraremos a nossa aten√ß√£o em um √ļnico avan√ßo: assinaturas com limite (TSS) seguras e eficazes.


MPC e o esquema de assinatura com limite (TSS)

A computa√ß√£o de m√ļltiplas partes (MPC) √© um ramo da criptografia que come√ßou com o trabalho de Andrew C. Yao, h√° quase 40 anos. Na MPC, um grupo composto por partes ou agentes que n√£o confiam uns nos outros, tentam processar de forma conjunta uma fun√ß√£o sobre seus inputs, mantendo a privacidade do conte√ļdo dos mesmos.¬†

Como exemplo, digamos que os funcionários de uma empresa querem saber quem é o funcionário mais bem pago entre eles, mas sem que nenhum deles revele ao outro o seu salário. Aqui, as entradas privadas (inputs) são os salários e a saída (output) será o nome do empregado com o maior salário. A execução deste cálculo computacional usando MPC permite que nenhuma informação de salário vaze durante o processo. 

As duas principais características da MPC são a exatidão e privacidade:

  • Exatid√£o: a sa√≠da (output) produzido por um algoritmo √© correta (como previsto).

  • Privacidade: os dados secretos de entrada (input) que uma das partes mant√©m n√£o vazam para as outras partes.

Usaremos a MPC para calcular uma assinatura digital de uma forma distribuída. Vejamos como as propriedades mencionadas se aplicam às assinaturas. Lembrando que, para assinaturas, temos três passos: 

  • Gera√ß√£o da chave: o primeiro passo √© tamb√©m o mais complexo. Precisamos gerar uma chave que seja p√ļblica e utilizada para verificar futuras assinaturas. Mas tamb√©m precisamos gerar um segredo individual para cada parte, que chamaremos de¬†"secret share" (parte do segredo). Em termos de exatid√£o e privacidade, dizemos que a fun√ß√£o ir√° produzir como output a mesma chave p√ļblica para todas as partes, e uma outra parte secreta (secret share) para cada um desses elementos de modo que: (1) privacidade: nenhum dos dados da parte secreta sejam divulgados entre as partes e (2) exatid√£o: a chave p√ļblica √© uma fun√ß√£o das partes secretas.

  • Assinatura: esta etapa envolve uma fun√ß√£o para gera√ß√£o de assinatura. A entrada (input) de cada parte ser√° sua parte secreta (secret share), criada como sa√≠da (output) da etapa anterior (gera√ß√£o de chaves distribu√≠da). Existe tamb√©m uma informa√ß√£o de entrada (input) p√ļblica conhecida por todos, que √© a mensagem que deve ser "assinada" (confirmada). A sa√≠da (output) ser√° uma assinatura digital, e a propriedade da privacidade garante que n√£o ocorra nenhum vazamento de partes secretas durante o processo de computa√ß√£o dos dados.

  • Verifica√ß√£o: o algoritmo de verifica√ß√£o permanece como est√° na configura√ß√£o cl√°ssica. Para ser compat√≠vel com as assinaturas de chave √ļnica, todos os que tiverem conhecimento da chave p√ļblica devem ser capazes de verificar e validar as assinaturas. Isso √© exatamente o que os n√≥s de valida√ß√£o da blockchain fazem.

Threshold signature scheme (TSS) é o nome que damos a esse processo composto pela geração de chaves distribuídas (DKG) com a assinatura distribuída de um esquema de assinaturas com limite.


Combinação do TSS com blockchains

A forma natural de implementar o TSS em uma blockchain é alterando um cliente de blockchain para gerar chaves e assinaturas usando o esquema TSS. Aqui, usamos o termo cliente blockchain para se referir ao conjunto de comandos executados por um nó completo (full node). Na prática, a tecnologia TSS permite substituir todos os comandos relativos à chave privada por uma tecnologia de computação distribuída.

Para explicar mais detalhes, come√ßaremos descrevendo brevemente como novos endere√ßos s√£o criados no esquema cl√°ssico da blockchain. ¬†Basicamente, podemos criar um novo endere√ßo gerando uma chave privada para depois computar a chave p√ļblica a partir dessa chave privada. Por fim, o endere√ßo p√ļblico ser√° um derivado da chave p√ļblica.

Assim, usando o esquema TSS, ter√≠amos um conjunto de "n" partes, cada uma delas na posse de uma "secret share" da chave privada, que computaria conjuntamente a chave p√ļblica (sem revelar as partes secretas individuais entre si). Da chave p√ļblica, podemos extrair o endere√ßo p√ļblico da mesma forma que no sistema tradicional, fazendo com que a blockchain seja indiferente em rela√ß√£o √† maneira que o endere√ßo foi criado. A vantagem √© que a chave privada n√£o √© mais um √ļnico ponto de falha porque cada uma das partes tem apenas uma parcela dela.¬†

O mesmo pode ser feito ao assinar (validar) transa√ß√Ķes. Neste caso, em vez de uma √ļnica parte assinar com a sua chave privada, realizamos uma gera√ß√£o de assinaturas distribu√≠da entre m√ļltiplas partes. Assim, cada uma das partes pode produzir uma assinatura v√°lida, contanto que um n√ļmero suficiente das partes esteja agindo honestamente. Ou seja, novamente passamos de um m√©todo de computa√ß√£o local (ponto √ļnico de falha) para um m√©todo interativo.

√Č importante mencionar que a gera√ß√£o de chaves distribu√≠das pode ser feita de uma maneira que permite diferentes tipos de estruturas de acesso: a configura√ß√£o geral ‚Äút out of n‚ÄĚ ser√° capaz de suportar, sem comprometer a seguran√ßa, at√© "t" falhas arbitr√°rias em opera√ß√Ķes relacionadas √† chave privada.


TSS vs. Multisig

Algumas blockchains oferecem funcionalidade TSS como parte integrante ou programável do software. Chamamos esta funcionalidade de multisig ou multi-assinatura. Para entender melhor as diferenças, podemos ver o multisig como uma TSS na camada de aplicação da blockchain.

Em outras palavras, tanto o multisig como o esquema TSS tentam, essencialmente, alcan√ßar os mesmos resultados. Entretanto, o TSS usa criptografia off-chain (fora da cadeia), enquanto o multisig ocorre on-chain (na cadeia). No entanto, a blockchain precisa de uma maneira de codificar o multisig. Isso pode prejudicar a privacidade porque a estrutura de acesso (n√ļmero de assinaturas) √© exposta na blockchain. O custo de uma transa√ß√£o multisig √© maior porque a informa√ß√£o sobre os diferentes assinantes (validadores) tamb√©m deve ser comunicada na blockchain.

Em TSS, os dados dos assinantes’ são guardados em uma transação de aparência regular, reduzindo o custo e mantendo a privacidade. Por outro lado, o multisig pode ser não interativo, o que resolve o problema de executar uma complexa camada de comunicação entre os diferentes assinantes.

A principal diferen√ßa √© que o multisig √© espec√≠fico da blockchain e precisa ser reimplementado para cada blockchain mas, em alguns casos, isso √© totalmente invi√°vel. Por outro lado, o TSS est√° dependendo de criptografia pura, ent√£o o suporte √© sempre poss√≠vel. Um excelente artigo com ilustra√ß√Ķes sobre essas diferen√ßas pode ser encontrado aqui.


TSS vs. Shamir secret sharing scheme

O esquema de compatilhamento de segredos de Shamir (SSSS) fornece uma maneira de armazenar a chave privada de uma forma distribu√≠da, de modo que enquanto a chave privada for mantida¬†em repouso¬† ela √© mantida em m√ļltiplas localiza√ß√Ķes. Existem duas diferen√ßas entre SSSS e TSS:

  • Gera√ß√£o de chave: no esquema SSSS, h√° uma √ļnica parte chamada de ‚Äúthe dealer‚ÄĚ que √© respons√°vel por gerar as partes secretas (secret shares) da chave privada. Isso significa que, no momento da gera√ß√£o de chave, a chave privada √© gerada em um √ļnico local e depois distribu√≠da pelo dealer para diferentes locais. No TSS, n√£o h√° nenhum dealer, uma vez que essa fun√ß√£o √© feita de modo a que a chave privada completa nunca esteja em uma √ļnica localiza√ß√£o.

  • Assinatura: em SSSS, as partes devem reconstruir a chave privada completa para assinar, o que mais uma vez resulta em um √ļnico ponto de falha para cada vez que uma assinatura √© necess√°ria. No TSS, a assinatura √© feita de forma distribu√≠da sem nunca reconstruir as partes secretas (secret shares).

Como podemos ver, no TSS, a chave privada (que representa a seguran√ßa do sistema) nunca est√° em um √ļnico local ao longo de toda a sua exist√™ncia.


Threshold wallets

Uma carteira baseada na tecnologia TSS √© um pouco diferente das tradicionais carteiras de criptomoedas. Normalmente, uma carteira convencional gera uma "seed phrase" (frase semente) e a usa para determinar os endere√ßos. Depois o usu√°rio pode usar essa estrutura hier√°rquica e determinista (HD) para 1) alcan√ßar as chaves privadas que correspondem aos endere√ßos p√ļblicos de carteira e assinar transa√ß√Ķes com eles; e 2) recuperar todas as chaves de carteira usando a seed phrase.

Em uma threshold wallet, as coisas são mais complexas. Embora seja possível gerar uma estrutura HD, sua geração deve ser computada de forma distribuída, como outro protocolo MPC. As partes devem decidir em conjunto qual é a próxima chave a ser utilizada. Em outras palavras, cada uma das partes terá uma seed phrase própria. As seed phrases são geradas separadamente e nunca combinadas para que uma parte sozinha não possa derivar a chave privada de sua seed phrase.

As carteiras baseadas em TSS, tamb√©m t√™m um bom recurso de seguran√ßa, que habilita a rota√ß√£o de chave privada sem alterar os endere√ßos de chave p√ļblica e de blockchain correspondentes. A rota√ß√£o de chave privada, tamb√©m conhecida como proactive secret sharing, √© mais um protocolo MPC que recebe as secret shares como entrada (input) e extrai (output) um novo conjunto de secret shares. As antigas secret shares podem ser exclu√≠das e as novas podem ser utilizadas da mesma forma.

Esta estrutura adiciona uma dimensão de tempo à segurança, o que significa que um agente malicioso deve estar em vários locais ao mesmo tempo para ser capaz de invadir uma threshold wallet. Combinar secret shares antes e depois da rotação não dará ao agente invasor nenhum poder adicional se ele tiver a intenção de falsificar uma assinatura. 

Um ponto negativo deste tipo de carteira √© que a falta de uma seed phrase a torna incompat√≠vel com o sistemas de carteira de chaves √ļnicas. Ent√£o, √© importante considerar quais partes ter√£o posse das secret shares.

Existem algumas arquiteturas possíveis:

  • Outsourcing TSS: o usu√°rio permitir√° que ‚Äún‚ÄĚ servidores executem o processo de computa√ß√£o em seu nome. Externalizar efetivamente a gera√ß√£o de chave, gest√£o e assinatura √† provedores de servi√ßos que n√£o s√£o donos dos ativos por√©m, fornecem uma camada de seguran√ßa em retorno de algum incentivo.

  • Usar m√ļltiplos dispositivos: O usu√°rio executar√° o TSS entre os dispositivos que possui. Por exemplo - uma das partes ser√° um dispositivo IoT, outra parte ser√° o celular do usu√°rio, outra parte seu laptop, etc.

  • H√≠brido: O TSS ser√° executado de tal forma que algumas partes s√£o controlados por prestadores de servi√ßos externos e outras s√£o executadas em dispositivos de propriedade do usu√°rio.

O primeiro m√©todo alivia o cliente do usu√°rio da parte pesada de c√°lculos computacionais do TSS. Por outro lado, os prestadores de servi√ßos podem conspirar (presumindo que eles n√£o sofreram ataques simult√Ęneos, mas na pr√°tica pode acontecer) e roubar os bens do usu√°rio.

O segundo m√©todo proporciona controle total ao usu√°rio, por√©m torna o processo mais pesado para realizar transa√ß√Ķes, pois ser√£o necess√°rios v√°rios dispositivos online executando os c√°lculos computacionais do TSS.

A terceira op√ß√£o √© considerada a melhor, pois d√° ao usu√°rio uma maneira f√°cil e r√°pida de realizar transa√ß√Ķes, mas sem descartar a necessidade de sua autoriza√ß√£o para a realiz√°-las.


TSS e contratos inteligentes 

Ao longo dos anos, pesquisadores encontraram muitas utiliza√ß√Ķes para assinaturas digitais, e algumas s√£o surpreendentemente importantes. Conforme mencionado anteriormente, o TSS √© um princ√≠pio criptogr√°fico que pode melhorar muito a seguran√ßa. No contexto das blockchains, podemos dizer que muitas funcionalidades podem ser substitu√≠das pela criptografia baseada no TSS. Aplica√ß√Ķes descentralizadas, solu√ß√Ķes de escala layer 2, atomic swaps, mixing, heran√ßa e muito mais podem ser constru√≠dos sobre a estrutura TSS. Isto permitiria, eventualmente, substituir opera√ß√Ķes caras e arriscadas de contratos inteligentes on-chain (na cadeia) por alternativas mais baratas e confi√°veis.
Alguns exemplos concretos: MultiHop Locks utiliza assinaturas de duas partes de uma forma inteligente e pode ser usado como alternativa √† lightning network da Bitcoin com uma rede de pagamento mais segura e com maior privacidade. ShareLock √© provavelmente a solu√ß√£o de mixing on-chain mais barata para o sistema Ethereum, baseada na verifica√ß√£o de uma √ļnica assinatura com limite (threshold signature).


Riscos

Nos √ļltimos dois anos, registrou-se um aumento significativo das implementa√ß√Ķes do esquema TSS. No entanto, por ser uma tecnologia relativamente nova, ainda apresenta algumas limita√ß√Ķes e preocupa√ß√Ķes. Em compara√ß√£o com a criptografia de chave p√ļblica cl√°ssica, protocolos TSS podem ser muito complexos e ainda precisam passar por mais testes. Geralmente, o esquema TSS requer pressupostos adicionais (relacionados √† criptografia) mais fracos quando comparados com assinaturas digitais simples. Como resultado, agentes maliciosos que n√£o existiam em configura√ß√Ķes tradicionais est√£o agora sendo descobertos (veja esta apresenta√ß√£o da Breaking Bitcoin Conference 2019). Os engenheiros de seguran√ßa e cript√≥grafos podem ajudar na implanta√ß√£o segura do TSS no sistema.


Considera√ß√Ķes finais

Neste artigo, introduzimos os conceitos básicos do esquema de assinatura com limites (TSS), que é um princípio criptográfico fascinante e que tem o potencial de mudar significativamente a forma como utilizamos a blockchain.

Como este artigo n√£o discutiu o Threshold ECDSA que pode ser usado na Binance Chain e na Bitcoin, os interessados podem consultar a seguinte lista de documentos recentes. Al√©m disso, se quiser testar algumas implementa√ß√Ķes do TSS, voc√™ pode encontrar um c√≥digo para a carteira de duas partes (two-party wallet) da Binance Chain aqui ou testar aZenGo wallet, que utiliza o m√©todo h√≠brido para fornecer uma carteira two-party wallet da Binance Chain, sem cust√≥dia.


Leituras adicionais: