Bem vindo! Novo em Zcash?
The Zcash network is young, but evolving quickly! Sign up and we'll be in touch with monthly highlights on ecosystem growth, network development and how to get started with Zcash!

Idioma

Corrigindo Vulnerabilidades no protocolo Zcash

Taylor Hornby, Zooko Wilcox | Apr 26, 2016

Intro

por Zooko

Eu trabalhei em criptografia, segurança da informação, e dinheiro digital para metade da minha vida (20 anos, mas quem está contando?), e eu nunca trabalhei em um sistema de criptografia tão ambicioso como a Zcash. Felizmente, eu também nunca trabalhei com um time tão singularmente qualificados para a tarefa exigente de construção de sistemas de encriptação seguros e práticos.

Uma parte essencial da prática de segurança de computadores é um "contraditório" processo em que você tentar atacar um sistema - para encontrar pontos fracos em que - ao mesmo tempo que você está tentando fortalecê-lo. Este processo pode ser desconcertante para algumas pessoas de fora, mas os especialistas em segurança de computadores, se vemos alguém encontrar correções e publicam questões de segurança, isso nos dá confiança de que o sistema está ficando mais forte.

Os membros da nossa equipe têm feito anteriormente este tipo de trabalho de auditoria de segurança para outros, incluindo Cryptocat, GlobaLeaks, SpiderOak, e Ethereum.

Neste post, vamos apresentar um relatório sobre as questões de segurança que encontramos no protocolo Zcash enquanto nos preparamos para implantá-lo como um processo aberto, não autoritário sistema financeiro.

Alguns de nossa equipe publicou o paper de ciência originais da Zerocash, com análise científica revisada em pares, em 2014. Recentemente, temos ampliado e melhorando o protocolo, escrevemos uma nova especificação de protocolo detalhada do protocolo e percorri-o para vulnerabilidades de segurança.

Até à data, temos encontrados e corrigidos três vulnerabilidades de segurança:

1. Zooko Wilcox encontrou o vulnerabilidade das fadas de ouro , que teria tornado possível enganar um usuário Zcash em pensar que eles receberam um bando de notas passíveis de dispêndio. Quando na verdade, quando eles tentam passar as notas que vão encontrar que só um deles pode ser gasto.

2. Taylor Hornby encontrou o vulnerabilidade da colisão InternaH, que deixaria alguém ter gasto duplo de uma nota especialmente concebida para o efeito, se eles têm um computador poderoso o suficiente para encontrar colisões de hash de 128 bits.

3. Daira Hopwood encontrou um erro não-explorável na prova de segurança , onde se uma das funções pseudo-aleatórias que o protocolo usa não é resistente à colisão, em seguida, as notas enviados para um endereço privado especialmente criado poderia ser de gasto duplo. (Isto não foi explorada por causa da função que está sendo utilizadas não acontece a resistente à colisão.)

Aqui é Taylor escreve o maior impacto destes três - a Vulnerabilidade de Colisão InternalH Vulnerabilidade, que ele encontrou.

— Zooko Wilcox, 2016-04-25

A Vulnerabilidade Colisão InternaH

por Taylor

Se tivéssemos lançado Zcash sem encontrar e corrigir a Vulnerabilidade de Colisão InternalH, que poderia ter sido explorada para falsificação de moeda. Alguém com poder de computação suficiente para encontrar colisões de hash de 128 bits teria sido capaz de ter gasto duplo para si, criando Zcash fora do ar.

Encontrar colisões de hash de 128 bits requer: \(2^{64}\) operações paralelizável, que está ao alcance de atacantes hoje, então a vulnerabilidade teria sido explorados na prática. Vamos ver como o ataque funciona, e o que nós fizemos para corrigi-lo.

O Erro

A fraqueza foi no esquema de compromisso para anotações. Esquemas de compromisso são ferramentas criptográficas úteis porque eles permitem que você publicar um compromisso para alguns, sem revelar informações. Então, em algum momento posterior, você pode abrir o compromisso para revelar a informação e provar a todos que é a mesma informações que você cometeu no primeiro lugar.

Para que isso funcione, os esquemas de autorização precisam satisfazer duas propriedades:

1. Hiding: Você não sabe nada sobre a informação de ver o compromisso. Mesmo se você tem certeza de que a informação era, você não deve ser capaz de confirmar o seu palpite.

2. Binding: Se você comitar a algum valor, você não deve ser capaz de mudar a sua mente mais tarde e dizer que você realmente tinha comprometido com um valor diferente. Um compromisso deve ser aberto a um valor único, e não deve ser possível abrir o compromisso para qualquer outro valor.

Na Zcash, o objeto fundamental de valor é chamado de "Nota", que consiste os valores \((a_{pk}, v, \rho , r)\), que têm significados especiais no protocolo. Como parte do protocolo, compromissos com notas são publicadas no blockchain. Veja como esse compromisso foi computado no projeto original:

\(InternalH = \text{SHA256Compress}(a_{pk} \text{ \| } \rho ) \text{ truncated to 128 bits }\)
\(k = \text{SHA256Compress}(r \text{ \| } InternalH)\)
\(cm = \text{SHA256Compress}(k \text{ \| } [0]^{192} \text{ \| } v)\)

Aqui, SHA256Compress é a função de compressão usado internamente pela função hash SHA256.

A Vulnerabilidade de Colisão InternaH existe porque este esquema está faltando a propriedade de ligação. É possível comprometer-se a uma nota e, em seguida, abrir o compromisso mais tarde para uma nota diferente.

É fácil ver como isso pode ser feito se você pode colidir hashes de 128 bits. O compromisso começa por computação \(InternalH\), um hash de 128 bits de \(a_{pk}\) e \(\rho \), e depois de cometer ao hash. Se você encontrar uma colisão InternalH, então você tem dois diferentes:math:a_{pk} and \(\rho \) pares \((a_{pk}, \rho )\) e \((a_{pk}\prime, \rho \prime)\) que da na mesma \(InternalH\), e você será capaz de abrir o compromisso de qualquer um dos \((a_{pk}, v, \rho , r)\) ou \((a_{pk}\prime, v, \rho \prime, r)\). Então o esquema de compromisso não é vinculativo. Como é que essa fraqueza se traduzir em um ataque?

O Ataque

Compromissos com todas as notas existentes são armazenados no blockchain. Com o intuito de passar uma nota, você deve provar em conhecimento-nulo de que você sabe a chave de gastos para uma nota que estava comprometido com no blockchain e você deve revelar o nullifier de nota. O nullifier é um valor que é suposto ser único para cada nota. Para certificar-se nenhuma nota pode ser gasta duas vezes, todos os nodes no rede devem checar que eles não viram o nullifier recém-revelado antes.

O nullifier de uma nota \((a_{pk}, v, \rho , r)\) da propriedade de uma chave de gastos \(a_{sk}\) é calculado pela aplicação de uma função psuedo-aleatória para: \(\rho \), ou seja, o nullifier é \(PRF_{a_{sk}}^{nf}(\rho )\). O gastador deve provar conhecimento-nulo (sem revelar \(\rho \) ou \(a_{sk}\)) que eles computaram o nullifier corretamente.

A fraqueza InternalH permite que um atacante criar um compromisso nota para a qual dois diferente válida \(\rho \) valores existentes. Eles podem encontrar \(\rho _1\) e uma diferente \(\rho _2\) de tal forma que o compromisso é aberta para qualquer um \((a_{pk}, v, \rho _1, r)\) ou \((a_{pk}, v, \rho _2, r)\). O atacante pode passar a nota de compromisso na primeira vez usando \(\rho _1\) revelando o nullifier \(PRF_{a_{sk}}^{nf}(\rho _1)\), e, em seguida, gastá-lo de uma segunda vez utilizando \(\rho _2\) revelando a nullifier \(PRF_{a_{sk}}^{nf}(\rho _2)\). Com efeito, esta nota tem dois anuladores diferentes em vez de apenas um, para que ele possa ser gasto duas vezes. Uma vez que tudo isto é feito de conhecimento-nulo, nenhum dos nós da rede pode dizer o tanto gasto está referenciando o mesmo compromisso da nota. Outra variante do ataque funciona por encontrar dois diferentes \(a_{pk}\), em vez de dois ρ diferente.

Para cada colisão hash de 128 bits que o atacante encontra, eles podem efetivamente dobrar sua riqueza através da combinação de todas as suas Zcash em uma nota de gasto duplo e em seguida passar-lo para si mesmo. Portanto, embora o \(2^64\) operações para encontrar uma colisão não são baratas, o ataque paga rapidamente off.

A Correção

Se você ler a Seção 5.1 do paper de ciência originais da Zerocash, você encontrará que \(InternalH\) foi escolhido para ser de 128 bits, com o intuito de dar o esquema de compromisso de uma propriedade muito forte chamada esconderijo estatístico. O esconderijo comum de propriedade é computacional: ele diz que você não pode aprender alguma coisa sobre a entrada a menos que você tem um computador rápido absurdamente (isto é, capaz de quebrar SHA256). Esconderijo estatístico diz que, mesmo se você tiver um computador infinitamente rápido, você ainda não pode aprender alguma coisa sobre a entrada. Isto teria permitido Zcash de manter a sua privacidade mesmo se um dia a função de hash SHA256 for quebrada.

Para corrigir a vulnerabilidade, nós transferimos para um esquema de compromisso diferente que tenha que assegurar a ligação. Com o intuito de manter a Zcash conhecimento-nulo eficiente de computação nós soltamos a poderosa propriedade esconderijo estatístico e estabilizamos para o um regular. Isto não deve importar, na prática, uma vez que, a fim de quebrar a propriedade de esconderijo do nosso novo esquema de compromisso, você teria que quebrar um bem estudada propriedade de segurança de SHA256, o que parece improvável que isso aconteça em breve. Aqui está nosso projeto atual para o esquema de nota compromisso:

\(cm = \text{SHA256}(\text{0xB0} \text{ \| } a_{pk} \text{ \| } v \text{ \| } \rho \text{ \| } r)\)

Você pode encontrar todos os detalhes em nossa especificação de protocolo.

Conclusão

Construção de protocolos de criptografia seguras é difícil, e até mesmo a nossa equipe de classe mundial de criptógrafos e engenheiros de segurança vai cometer erros ao longo do caminho. Apesar do desafio, estamos otimistas de que nossas práticas de revisão de segurança cuidadosa e transparência irá conduzir a um produto seguro.

Neste ponto, o protocolo Zcash foi submetido a uma revisão de segurança, primeiro através de análise científica, e depois pela nossa equipe interna de especialistas. Mas precisamos ainda mais de escrutínio para obter uma garantia de que o protocolo é seguro.

Se você gosta do desafio de caça de bugs nos protocolos de criptografia, nós gostaríamos que você pudesse dar uma olhada em nossa nossa especificação de protocolo. Se você pode quebrar o nosso protocolo e dizer como você fez isso, você estará ajudando toda a humanidade para ganhar um aberto, não-autoritário, sistema financeiro de preservação da privacidade!

— Taylor Hornby com Zooko Wilcox, 2016-04-25