Opinião: Enterprise Blockchains Redux: Como não ser compatível com NIST sem quebrar o banco

Opinião de Andreas Freund, Membro do EEA Mainnet Interest Group

Blockchains têm um problema raramente falado que é independente dos altos e baixos dos mercados criptográficos, e que pode dificultar a adoção de Blockchain de longo prazo fora do direto ao consumidor e alguns casos de uso B2B: os algoritmos criptográficos Blockchain não são compatíveis com NIST, o que é um fator importante para alcançar a conformidade com a FISMA (Lei Federal de Gerenciamento de Segurança da Informação)! E a conformidade com o NIST/FISMA, ou equivalente fora dos EUA, é importante quando as empresas lidam com governos ou empresas que lidam regularmente com empresas que lidam com governos.

Por que Blockchains normalmente não são compatíveis com NIST? Bem, a principal razão é que os Blockchains nasceram da profunda desconfiança de qualquer coisa operada pelo governo e endossada após a Grande Recessão de 2008; incluindo algoritmos criptográficos endossados ​​pelo governo. De qualquer forma, o algoritmo de hash SHA-3 amplamente aceito hoje não foi finalizado até 2015, depois que Blockchains como o Ethereum já haviam feito suas escolhas em algoritmos de hash. Portanto, a maioria dos Blockchains, como o Ethereum, está usando algoritmos que não são apenas não aprovados pelo NIST, mas que o NIST recomenda não usar. Observe que existem Blockchains compatíveis com NIST, como Simba-Chain ou Fabric, operando no LinuxONE da IBM. No entanto, eles são de alto custo e difíceis de gerenciar na produção[1]  como as empresas aprenderam depois de gastar algumas dezenas de milhões de dólares em taxas de consultoria e implementação. Para agravar o problema de custo, eles geralmente não produzem os resultados de negócios esperados porque os casos de uso escolhidos não eram adequados para Blockchains para começar! O principal argumento para a discussão abaixo é que qualquer nova abordagem Enterprise Blockchain deve abordar não apenas a conformidade com o NIST, mas também a complexidade de custo e gerenciamento de forma eficaz para atrair novos patrocinadores de negócios.

Isso significa que tudo é inútil para o Blockchain em uma empresa quando a conformidade com o NIST, o custo e a complexidade do gerenciamento são uma preocupação?

Felizmente, a resposta é não, não é impossível. Não trivial, mas não desesperador.

Para entender o que isso significa, vamos recapitular quais características os aplicativos baseados em Blockchain pode ter:

• Integridade de dados: Se você só precisa disso, não use um Blockchain. Existem alternativas mais baratas.
• Carimbo de data/hora comprovável: muito mais interessante e útil para trilhas de auditoria, por exemplo, em cadeias de suprimentos.
• Sem ponto único de falha: Se você precisa de 100% de disponibilidade, a um preço baixo.
• Resistência à censura: Acesso a dados que, por exemplo, precisam ser auditados por terceiros não necessariamente identificados no momento da criação dos dados, ou executando (basicamente) transações irreversíveis independentes de terceiros.
• Proteção contra gastos duplos: Relevante apenas se você estiver lidando com ativos digitais em um Blockchain. Em outras palavras, você realmente gosta de DeFi.
• Herdando garantias de segurança Blockchain: Esse é muito interessante, se você precisa de escalabilidade de aplicativo, mas alta segurança. Chegaremos a isso daqui a pouco.

Observe que nenhum dos itens acima fala sobre privacidade de dados, uma das joias inestimáveis ​​dos requisitos de aplicativos corporativos. Mas não se preocupe, você pode obter privacidade de dados sem divulgar dados confidenciais de negócios em todos os lugares. Nós vamos chegar a isso daqui a pouco também.

Antes de nos anteciparmos, vamos fazer uma pausa aqui e discutir como essas características se relacionam com a conformidade com o NIST. À primeira vista, nem tanto, mas vamos examinar cada característica e discutir suas implicações com um pouco mais de detalhes. Em primeiro lugar, porém, vale a pena mencionar que para obter permissões de Autoridade para Operar (ATO) de um governo, por exemplo, o governo dos EUA[2], não há problema em usar algoritmos criptográficos não compatíveis com o NIST ou algoritmos sobre os quais o NIST não formou uma opinião, desde que esses algoritmos não sejam fundamentais para a segurança do aplicativo e a privacidade de seus dados. Por exemplo, você precisa provar que um contrato foi executado em um dia específico e não foi alterado desde então. Usando um Blockchain, seria possível formar uma impressão digital criptográfica usando um hash criptográfico (aprovado pelo NIST) do contrato e, em seguida, ancorar esse hash em um Blockchain (público) que fornece, uma vez incluído em um bloco, um registro de data e hora provável por meio da combinação de número do bloco, hash do bloco e carimbo de data/hora. Se o Blockchain fosse reorganizado, por exemplo, por meio de um ataque de 51%, ainda seria possível pegar a transação com o hash do contrato e seu bloqueio e incluir ambos em outro Blockchain (público). Portanto, a segurança do Blockchain original (público) não é fundamental para o caso de uso.

Com isso em mente, vamos olhar novamente para cada característica, com foco em seu impacto na conformidade NIST de um aplicativo usando a tecnologia Blockchain:

• Integridade de dados: Este é fácil, pois você sempre pode ter uma cópia dos dados relevantes que ancorou, por exemplo, por meio de um hash criptográfico no Blockchain com outra forma de proteção da integridade dos dados, como uma credencial verificável W3C inviolável com um algoritmo de assinatura criptográfica aprovado pelo NIST .
• Carimbo de data/hora comprovável: Um pouco mais difícil, mas factível. Se a cadeia utilizada for comprometida, ainda é possível pegar o bloco com a transação relevante contendo, por exemplo, um hash criptográfico compatível com NIST de um documento e seu registro de data e hora e ancorar o bloco inteiro com a transação por meio de outro hash criptográfico compatível com NIST em outro Blockchain; nenhum dano real causado.
• Sem ponto único de falha: Ok, isso é um pouco complicado, já que o NIST não formulou recomendações sobre algoritmos de consenso. Isso significa que, desde que o modelo de consenso tenha uma base acadêmica sólida, por exemplo, uma prova matemática de segurança, ele pode ser defendido com sucesso e o colocamos no balde não compatível com o NIST.
• Resistência à censura: Isso parece fácil, mas porque significa que os dados serão prontamente visíveis para (quase) todos os participantes, muito cuidado deve ser tomado para usar os métodos de ofuscação corretos para dados colocados em um Blockchain, para argumentar com sucesso que a privacidade dos dados é mantida . Então esse é um pouco complicado, mas pode ser superado. Aguente firme, subindo.
• Proteção contra gastos duplos: Agora, este é realmente difícil porque combina os pontos anteriores com execução de transação determinística, validação de transação e formação de bloco, que dependem intrinsecamente dos algoritmos criptográficos usados. Sem entrar em detalhes, se você precisa de proteção contra gastos duplos como um recurso-chave em seu aplicativo baseado em Blockchain, você está sem sorte quanto à conformidade com o NIST … se seu ativo digital nasceu no Blockchain! Voltaremos a esse ponto em um segundo também.
• Herdando garantias de segurança Blockchain: Isso parece ser claro. Se a sua segurança depende criticamente da segurança do Blockchain subjacente, e esse Blockchain depende de sua segurança em algoritmos não compatíveis com o NIST; fim da história. Novamente, não tão rápido. A questão é garantias de segurança para quê? Se for para ativos digitais nascidos em um Blockchain, a resposta é a mesma que para proteção de gasto duplo. Mas, se os ativos digitais são criados a partir do Blockchain primeiro e só então replicados no Blockchain, a segurança desse ativo digital não está mais fundamentalmente ligada ao Blockchain subjacente, e temos o mesmo argumento para carimbo de tempo provável para nos livrarmos do enigma do NIST!

A avaliação de impacto acima agora pode servir como uma lista de verificação em relação às necessidades de conformidade NIST de um aplicativo Blockchain, dados os requisitos específicos do caso de uso desse aplicativo.

Antes de prosseguir e fornecer um plano de aplicativo para um aplicativo baseado em Blockchain não compatível com o NIST, vamos falar sobre privacidade de dados. Dados os critérios acima e os regulamentos de privacidade de dados existentes, colocar até mesmo dados criptografados em um Blockchain se qualifica como uma ideia estúpida, mesmo ao usar algoritmos de criptografia compatíveis com o NIST. Então, qual é a alternativa?

Resposta: Provas de conhecimento zero (ZKPs)

Os ZKPs tratam de fazer declarações sem revelar dados confidenciais subjacentes, por exemplo, o saldo da conta da corporação ACME é superior a $ 100,000 ou este código de desconto foi aplicado corretamente a este pedido.

Existem muitos tipos de ZKPs úteis – Merkle Proofs, Pedersen Commitments, Bulletproofs, ZK-SNARKs, ZK-STARKs e assim por diante. A chave é usar algoritmos criptográficos compatíveis com NIST ou não compatíveis com NIST ao usar ZKPs. Caso contrário, vá em frente! Os ZKPs são uma ótima ferramenta para as empresas atenderem aos seus requisitos de privacidade de dados internos e regulatórios.

Agora estamos em um lugar para fazer uma recomendação sensata sobre como construir um aplicativo corporativo baseado em Blockchain compatível com NIST - um projeto.

Os custos reais de implantação e operação não estão disponíveis publicamente, mas com base no conhecimento dos autores, variam entre oito e bons números em USD, com custos operacionais tipicamente na faixa de 15 a 25% - veja também algumas referências SUA PARTICIPAÇÃO FAZ A DIFERENÇA e SUA PARTICIPAÇÃO FAZ A DIFERENÇA. Essas faixas de custo são típicas de implementações e operações de sistemas corporativos de grande escala, como sistemas ERP.

Com origem na Lei FISMA e na circular A-130 da OMB, é responsabilidade dos órgãos garantir que o risco de uso de um sistema de informação para realizar atividades como acesso, transferência, armazenamento, processamento de dados federais foi determinado e aceito e que um A ATO foi aprovada para tais sistemas.

Como mostra a figura, começamos com uma pilha de software empresarial tradicional no topo – primeiro, a camada de aplicativo, depois a camada de abstração do aplicativo e, por fim, a camada de middleware – com toda a conformidade necessária, por exemplo, conformidade NIST integrada. No fundo da pilha, temos um Blockchain público porque isso elimina a necessidade de as empresas construírem consórcios complexos, gastarem muito dinheiro e permitirem que se movam muito mais rapidamente com o desenvolvimento de novos produtos. Entre o middleware e a camada Blockchain pública, está a camada de processamento “mágica” focada em privacidade e velocidade. Como a pilha usará ZKPs que preservam a privacidade e não utilizará principalmente ativos digitais criados no Blockchain público, as preocupações anteriores sobre o uso de Blockchains públicos desapareceram repentinamente. Como indicam as setas para cima e para baixo à esquerda da figura, a segurança da pilha aumenta à medida que passamos da camada superior para a inferior, o Blockchain público. O exato oposto acontece com as outras três características principais – privacidade, velocidade e controle; eles aumentam da camada inferior para a camada superior, onde uma única empresa tem controle total de todos os dados e, portanto, pode garantir privacidade enquanto mantém alta velocidade/escalabilidade mesmo para os dados mais confidenciais. Isso não significa, no entanto, que privacidade, velocidade e controle sejam baixos na parte inferior da pilha, apenas significa que é maior nas camadas superiores da pilha do que na parte inferior.

Agora, e aquela camada/rede de processamento “mágica”?

Aqui está o que essa camada pode fazer usando a tecnologia existente para atender aos requisitos da empresa:

• Dados privados
  • Provas de transações de conhecimento zero
  • Criptografia forte (quando necessário)
  • Técnicas de criptografia mais recentes, por exemplo, algoritmos de segurança quântica
• Segurança
  • Herda as garantias de segurança do Blockchain público ao usar os ZKPs corretos ancorados no Blockchain
  • Os dados de ativos digitais podem estar disponíveis diretamente via ZKPs no Blockchain público para serem usados, se necessário
• Verificabilidade
  • Qualquer um pode verificar as provas no Blockchain público
  • As provas podem verificar recursivamente todas as transações de ativos e todo o histórico de transações de ativos
  • Nada é finalizado até que as provas sejam verificadas no Blockchain público
• Velocidade
  • Paralelização de transações
  • Acumulação de transações agrupando-as com provas (recursivas)
  • Menos custo por transação

Em resumo, a camada de processamento “mágica”

• as mesmas garantias de segurança que o Blockchain público usado,
• 100 – 1000x mais escalabilidade,
• disponibilidade de dados garantida,
• privacidade preservada em todos os momentos,
• taxas de transação muito mais baixas,
• verificabilidade de todas as provas por qualquer pessoa no Blockchain público
• permite KYC e AML

Isso parece bom demais para ser verdade. Essa tecnologia já existe? A resposta é sim, e empresas como Starkware, Aztec, zkSync e outras estão trabalhando para obter suas tecnologias ZK-Rollup “Layer 2” totalmente prontas para empresas. O foco de todos esses esforços é o Ethereum público porque oferece as mais altas garantias de segurança (número de mineradores/validadores e valor total bloqueado (TVL)), combinado com o suporte criptográfico necessário incorporado em sua camada de execução.

Naturalmente, esta não é a única abordagem possível para um aplicativo baseado em Blockchain obter um ATO do governo. No entanto, é uma abordagem bastante direta e agora bem compreendida.

Então, qual é o net-net aqui?

As empresas agora têm

• A quadro para avaliar as necessidades do caso de uso versus as características do Blockchain e como essas necessidades podem ser atendidas por aplicativos empresariais baseados em Blockchain que podem obter um ATO do governo.
• A projeto para construir aplicativos corporativos baseados em Blockchain de uma maneira que lhes permitisse obter um ATO do governo enquanto, conforme ilustrado na figura acima, também permitia benefícios adicionais:
  • Confiança Superior através de Blockchains públicos, verificabilidade pública e privacidade imposta por criptografia
  • Custo mais baixo por meio de auditabilidade mais fácil (verificar ZKPs é rápido e barato) e lotes de transações sofisticados (rollups) no aplicativo de Camada 2
  • Processamento mais rápido por meio da paralelização da computação, mais transações por meio de rollups e uma pegada menor do Blockchain, já que os Blockchains públicos devem ser lentos por design para fornecer mais segurança
  • Mais flexibilidade e escolha através da capacidade de ter ativos tradicionais para sustentar ativos de criptografia no Blockchain, integração mais simples entre a Camada 2 e um Blockchain público e fácil extensão dos ativos da camada 2, por exemplo, nos ecossistemas DeFi existentes

Para encerrar, é importante observar que, no exemplo do governo dos Estados Unidos, a obtenção de um ATO para um sistema de informação não se limita apenas a artefatos criptográficos e criptomódulos. Eles representam uma parte importante dos controles de segurança que são identificados durante o processo de gerenciamento de risco necessário para obter um ATO, conforme listado e explicado em detalhes expansivos no NIST SP 800-37 Rev 2 e NIST FIPS-199. O processo também inclui elementos como autenticação/autorização do usuário em diferentes cenários de uso, controles de alteração de sistema e processo, recuperação de desastres e continuidade de negócios.

A conformidade com ATO/NIST para aplicativos Blockchain é relevante para o seu negócio? O Grupo de Trabalho ATO da EEA gostaria da sua opinião. Por favor entre em contato .

Siga-nos no Twitter, LinkedIn e Facebook para manter-se atualizado sobre tudo relacionado ao EEE.