As cargas úteis de dados UDP devem incluir um CRC?

Para uma empresa em que eu trabalhava, tive que implementar um receptor de soquete que, em sua maioria, usava dados em formato UDP por uma conexão local de algum hardware de sensor especializado. Os dados em questão eram um pacote UDP bem formado, mas, curiosamente, a carga útil dos dados sempre terminava com uma soma de verificação CRC16 formada usando o restante dos dados.

Eu implementei a verificação no meu final, conforme as especificações, mas sempre me perguntei se isso era necessário. Afinal, o próprio protocolo UDP não carrega um CRC de 16 bits? Portanto, embora os pacotes UDP possam ser perdidos ou fora de ordem, fiquei com a impressão de que eles não podem ser corrompidos sem serem descartados pelo hardware da rede antes de atingirem os processos do sistema operacional. Ou há algum caso de uso especial em falta?

Vale acrescentar que eu estava trabalhando na indústria de defesa, que, como posso imaginar, gosta de ser super-explícita em relação a tudo isso, por isso estou me perguntando se foi apenas um caso de "OCD de segurança". ..

security networking data-integrity

— Xenoprima
fonte

Se for para fins de segurança, não apenas para evitar corrupção acidental, você precisará usar um MAC, que é o equivalente com chave de uma soma de verificação.

— CodesInChaos

A soma de verificação UDP é válida apenas para os dados que foram injetados no pacote UDP. O que realmente cria a soma de verificação? O que usa a soma de verificação? É usado para garantir a integridade antes de o pacote UDP ser criado ou talvez transportado junto com o pacote para garantir que ele mantenha a integridade enquanto flui através de outros sistemas? Sem uma compreensão mais ampla dos componentes do seu sistema e de como os dados são criados, transformados e usados, não tenho certeza de que sua pergunta seja respondida.

— Thomas Owens

@ThomasOwens Os dados foram enviados do dispositivo de origem, lado a lado, para o hardware receptor. Sem intermediários. A soma de verificação foi criada pelo remetente como uma última etapa antes do envio.

— Xenoprimate

Respostas:

O protocolo UDP não garante que as mensagens sejam entregues em ordem ou entregues em tudo, mas garante que essas mensagens que não se entregues estão completos e inalterados, incluindo automaticamente uma soma de verificação de 16 bits. Isso significa que adicionar outra soma de verificação de 16 bits na camada do aplicativo geralmente é redundante.

...usualmente....

Primeiro, com o IPv4 (não o IPv6), a soma de verificação é opcional . Isso significa que você pode estar usando uma configuração exótica que não gera geração e validação de soma de verificação (mas, nesse caso, você deve preferir consertar sua pilha de rede em vez de manipular isso por júri na camada de aplicação).

Segundo, com uma soma de verificação de 16 bits, há uma chance em 65536 de que uma mensagem completamente aleatória tenha uma soma de verificação válida. Quando essa margem de erro é muito grande para o seu caso de uso (e no setor de defesa eu poderia imaginar vários onde está), a adição de outra soma de verificação CRC-16 a reduziria ainda mais. Mas, nesse caso, você pode considerar usar um resumo de mensagem adequado como SHA-256 em vez de CRC-16. Ou vá até o fim e use uma assinatura criptográfica real. Isso protege não apenas a corrupção aleatória, mas também a corrupção intencional de um invasor.

Terceiro, dependendo de onde os dados vêm e para onde vão, eles podem estar corrompidos antes ou depois de serem enviados pela rede. Nesse caso, a soma de verificação adicional dentro da mensagem pode proteger a integridade da mensagem mais do que apenas entre os dois hosts de rede.

— Philipp
fonte

Por que criptográfico ? As restrições usadas no design de hashes criptográficos não são as mesmas usadas no design de um hash usado na transmissão (por exemplo, o uso intensivo de recursos é um recurso para os hashes criptográficos e o problema na transmissão).

— AProgramador

@ AProgrammer Admito que a escolha das palavras possa ter sido enganosa. Substituí-o por "resumo adequado da mensagem". As funções de resumo de mensagens são muito mais longas, tornando tão improváveis as colisões acidentais que elas podem ser consideradas impossíveis para fins práticos.

— Philipp

Ele tenta garantir que as mensagens não sejam alteradas, mas a soma de verificação usada no UDP é bastante fraca. Embora a chance de uma mensagem aleatória possuindo uma soma de verificação válida seja de 1 em 65536 para todas as somas de verificação de 16 bits, as medidas mais úteis envolvem um número detectável de inversões de bits organizadas aleatoriamente ou em uma sequência, e todas as somas de verificação não apresentam o mesmo desempenho de acordo com essa métrica.

— Ben Voigt

Os hashes criptográficos do @AProgrammer (MD5, SHA-1/2/3, ...) visam ser o mais barato possível, garantindo propriedades de segurança como resistência à colisão. Normalmente, eles podem processar várias centenas de MB por segundo, portanto, não devem ser um gargalo para nada menos que as conexões Gbit. Eles ainda são mais lentos do que muitos não criptográficos que não precisam ser resistentes à colisão. Somente hashes de senha (PBKDF2, bcrypt, scrypt, Argon, ...) visam ser caros de calcular.

— CodesInChaos

No entanto, o UDP fornece uma soma de verificação.

A soma de verificação UDP é de apenas 16 bits. Isso significa uma chance de 1 em 65536 de um pacote corrompido passar na soma de verificação.
no UDP sobre IPv4, a soma de verificação é opcional; portanto, um remetente teoricamente pode acabar enviando um pacote sem uma soma de verificação.
A soma de verificação cobre as informações de IP / porta e os dados. Embora isso seja útil para descartar pacotes com endereços corrompidos, significa que, se o pacote passar por um NAT, a soma de verificação deverá ser recalculada pelo NAT.
A soma de verificação protege apenas os dados enquanto viaja no pacote UDP. Uma soma de verificação no nível do aplicativo pode proteger os dados de ponta a ponta à medida que passam por um sistema mais complexo.
A soma de verificação UDP clealy apenas informa que o pacote foi gerado por uma implementação UDP. Não diz que veio do seu sensor. Uma soma de verificação no nível do aplicativo, por outro lado, pode ajudar a rejeitar pacotes que são UDP válidos, mas vieram de alguma outra fonte.

Portanto, posso ver razões legítimas para não confiar na soma de verificação UDP, mas igualmente não confiar na soma de verificação UDP e, em seguida, implementar uma soma de verificação igualmente fraca no nível do aplicativo parece estranho.

Existe a possibilidade de a pessoa que deseja o protocolo simplesmente não saber que o UDP forneceu somas de verificação ou que o protocolo é na verdade uma ligeira variante de uma projetada para executar sobre uma mídia que não fornece somas de verificação.

PS: como esta postagem é marcada como segurança, saiba que as somas de verificação em questão foram projetadas para proteger contra alterações inadvertidas. Proteger contra modificação ou falsificação deliberada requer o uso de funções hash criptográficas resistentes a colisões / pré-imagens deliberadas e o uso de algum mecanismo (por exemplo, assinaturas feitas usando uma chave pública) para verificar se os hashes em si não foram modificados.

— Peter Green
fonte