Ferramentas para desenvolvedores · SHA calculadora de hash
Uma soma de verificação correspondente não é uma assinatura: integridade versus autenticidade
· Por que é importante
sha-256 criptografia segurança
Um SHA-256 publicado permite que os usuários detectem um download corrompido, mas se o invasor controlar a página, ele também controlará a soma de verificação. Esta postagem separa integridade de autenticidade e explica o que as assinaturas acrescentam.
A soma de verificação na mesma página do download — por que protege contra corrupção, mas não contra um host comprometido
Uma versão de software é publicada com uma soma de verificação SHA-256 na mesma página do download. Os usuários podem buscar o arquivo, fazer hash e comparar o resultado com o valor publicado. Se corresponderem, o download não está corrompido. Esta é uma verificação de integridade e é uma verificação real e útil. No entanto, se um invasor comprometer o servidor web que hospeda a versão, ele poderá substituir o binário, recalcular seu SHA-256 e atualizar a soma de verificação na página. O usuário verifica a soma de verificação e o malware do invasor parece vir do editor. O sistema funcionou exatamente como projetado, mas não conseguiu responder à pergunta que o usuário pensava estar fazendo.
Isto não é uma falha da soma de verificação em si. É uma observação correta sobre o que uma soma de verificação faz e o que não faz. Uma soma de verificação prova que duas cópias dos dados são idênticas. Não prova quem criou os dados. Essa é a distinção entre integridade e autenticidade, e combiná-las é um dos erros de segurança mais comuns na verificação de lançamentos. Muitos sistemas são quebrados não porque suas somas de verificação estejam erradas, mas porque os usuários confiam neles para responder a perguntas que não conseguem responder.
O que um hash prova – que duas entradas são os mesmos bytes e nada sobre quem as produziu
A integridade é uma propriedade dos próprios dados. Se você tiver um arquivo e seu SHA-256, e o arquivo não tiver sido modificado, o hash corresponde. O hash prova que cada byte permanece inalterado desde quando foi calculado. Se o arquivo foi corrompido por um erro de transmissão, uma falha no disco ou um bit invertido em um cabo de rede, o hash não corresponderá. Isto é o que as somas de verificação fazem bem. Eles são excelentes para detectar acidentes e corrupção aleatória. Eles falham contra um adversário que também pode calcular hashes.
A autenticidade é uma propriedade da afirmação sobre quem produziu os dados. A pergunta "este arquivo veio do editor em que confio?" é fundamentalmente diferente da pergunta "este arquivo foi modificado?" Um hash por si só não pode responder à questão da autenticidade porque qualquer pessoa pode computar um hash. O invasor que modifica o arquivo pode calcular o novo hash e publicá-lo com a mesma facilidade que o editor legítimo faria. Hashing é simétrico; tanto o defensor quanto o atacante têm a mesma capacidade computacional.
O requisito do canal confiável – por que uma soma de verificação é tão confiável quanto onde você a obteve
O requisito do canal confiável é o insight principal. Uma soma de verificação é tão confiável quanto o canal por onde passou. Se você baixar o binário do software do CDN oficial do editor e baixar a soma de verificação do mesmo servidor, eles percorreram o mesmo caminho. Comprometer o servidor significa que um invasor controla ambos. A soma de verificação fornece defesa contra corrupção durante a entrega – um arquivo danificado não corresponderá – mas não contra um invasor que controle a fonte. A soma de verificação e o arquivo compartilham um único ponto de falha.
Se a soma de verificação for publicada separadamente, em um servidor diferente, com controles de acesso diferentes, ela fornecerá mais defesa. Um invasor que comprometa o site primário precisaria comprometer ambos os locais para falsificar um par correspondente. Isto é melhor, mas ainda depende de dois pontos de controle independentes que permanecem seguros. O invasor deve agora violar dois sistemas em vez de um, aumentando o custo do ataque. Mas ainda não é prova de autenticidade; é apenas um ataque mais caro.
Assinaturas vinculam um hash a uma identidade – como assinar o resumo com uma chave privada adiciona autenticidade
Uma assinatura digital resolve isso vinculando os dados a uma identidade usando criptografia. O editor gera um par de chaves: uma chave privada que mantém em segredo e uma chave pública que publica. Eles assinam o arquivo calculando um resumo e depois criptografando esse resumo com sua chave privada. O resultado é a assinatura. Um usuário verifica a assinatura descriptografando-a com a chave pública do editor e verificando se o resultado corresponde ao resumo computado do arquivo recebido. A criptografia cria uma assimetria que a soma de verificação não consegue alcançar.
Se isso funcionar, duas coisas serão comprovadas: os dados correspondem ao resumo assinado pelo editor e a chave privada usada para assiná-lo corresponde à chave pública publicada. Isso prova que o editor o criou, e não apenas que foi um invasor. A chave pública deve passar por um canal seguro – geralmente um certificado de uma autoridade de certificação confiável – mas depois de ter a chave pública, você poderá verificar as assinaturas desse editor indefinidamente. O ataque agora exige o roubo da chave privada, o que é muito mais difícil do que comprometer um servidor web.
Exemplo resolvido – três cenários de ameaça (espelho corrompido, página comprometida, insider malicioso) e qual soma de verificação e assinatura cada uma captura
Três cenários de ameaça ilustram a diferença. Cenário um: o espelho de download está corrompido por um erro aleatório. A soma de verificação detecta isso; a assinatura o pega. Ambos funcionam igualmente bem porque nenhum deles precisa derrotar um invasor. Cenário dois: o espelho é comprometido por um invasor que substitui o arquivo e a soma de verificação. A soma de verificação não protege; a assinatura ainda funciona porque o invasor não possui a chave privada e não pode falsificar uma assinatura válida. O invasor pode postar qualquer coisa, mas a assinatura prova que não é do editor.
Cenário três: o CDN está comprometido, mas a assinatura foi publicada por meio de um canal diferente. A soma de verificação em CDN não é confiável, mas a verificação da assinatura ainda funciona, porque a verificação de integridade está criptograficamente vinculada à chave do editor, não ao canal. O invasor deve agora falsificar uma assinatura, que requer a chave privada. A assinatura é a única verificação que sobrevive ao comprometimento do servidor. É por isso que as assinaturas são necessárias para a autenticidade; eles são a única ferramenta que prova a identidade apesar do comprometimento do canal.
A função de TLS e seus limites – a segurança do transporte protege o download em andamento, não o servidor do editor
A segurança de transporte protege a conexão com o host nomeado pelo certificado. Ele pode impedir que um observador no caminho substitua bytes de download, mas não pode tornar honesta a origem de um editor comprometido. Se essa origem servir um arquivo modificado e uma soma de verificação recém-computada sobre TLS válido, ambos chegarão intactos e ainda descreverão o conteúdo controlado pelo invasor.
É por isso que transporte, integridade e autenticidade são camadas separadas. TLS protege um canal, um resumo compara bytes e uma assinatura vincula um resultado de verificação ao controle de uma chave privada. Nenhuma camada deve ser descrita como prova da propriedade fornecida por outra, mesmo quando um fluxo de trabalho de lançamento combina sensatamente todas as três.
O que isso não cobre – distribuição de chaves e raízes de confiança, que são a parte difícil das assinaturas
A distribuição de chaves é o limite rígido que esta calculadora resumida não ultrapassa. Um verificador de assinatura ainda precisa de uma chave pública autêntica ou cadeia de certificados e de uma política de rotação, revogação e algoritmos aceitáveis. Uma assinatura matematicamente válida sob uma chave não confiável prova apenas que o detentor dessa chave não confiável assinou os bytes.
Conseqüentemente, os cenários trabalhados param onde uma chave confiável já está disponível. Eles não prescrevem fixação de certificados, infraestrutura de chave pública ou cerimônias de liberação de chave. Essas opções de implantação precisam de seu próprio design revisado; ToolAcre fornece o resumo simples que pode ser assinado, não a raiz confiável usada para validar uma identidade.
Conclusão: somas de verificação para integridade, assinaturas para autenticidade - a calculadora de hash ToolAcre SHA calcula resumos; verificar quem os publicou é uma etapa separada
A calculadora de hash ToolAcre SHA calcula o lado da integridade desta verificação. Use-o para fazer o hash do arquivo baixado e verificar um valor publicado. Se corresponderem, o download não está corrompido. Mas se eles corresponderem porque um invasor reescreveu ambos, a verificação de integridade por si só não detectará o problema. A ferramenta é honesta quanto a esta limitação e não pretende verificar a autenticidade. Apenas para integridade, as somas de verificação são rápidas e boas. Para autenticidade, você precisa de assinaturas. TLS fornece segurança de transporte para o download em si. A conexão com o servidor é criptografada e autenticada, portanto, um invasor na rede não pode modificar o arquivo em trânsito. No entanto, TLS não ajuda se o próprio servidor estiver comprometido. Um servidor comprometido pode servir qualquer arquivo em qualquer conexão TLS segura. É por isso que a verificação no nível da aplicação – somas de verificação e assinaturas – é importante separadamente da segurança do transporte.
Um padrão comum em lançamentos de software é publicar somas de verificação e assinaturas. As somas de verificação são convenientes; os usuários podem verificá-los rapidamente com um comando shell de uma linha. As assinaturas fornecem autenticidade para usuários que possuem a chave pública do editor. Um usuário pode verificar a soma de verificação primeiro para obter uma passagem rápida de integridade e, em seguida, verificar a assinatura em relação a uma chave armazenada em seu chaveiro GPG para autenticidade. As duas verificações servem a propósitos diferentes e podem ser colocadas em camadas para defesa em profundidade. A parte difícil das assinaturas é a distribuição e a confiança das chaves. Você precisa da chave pública do editor e precisa confiar que ela é realmente dele. Este é o problema que as autoridades de certificação existem para resolver: elas assinam certificados de editor e os certificados de CA raiz vêm pré-carregados em navegadores e sistemas operacionais. Para um projeto menor, você pode publicar uma chave GPG em um site separado e protegido ou em um servidor de chave pública. A soma de verificação é barata para verificar; assinaturas exigem o gerenciamento de raízes de confiança. A complexidade adicional é o preço da autenticidade.