UDP 데이터 페이로드에 CRC가 포함되어야합니까?

내가 일했던 회사의 경우, 일부 특수 센서 하드웨어에서 로컬 연결을 통해 UDP 형식으로 데이터를 가져 오는 소켓 수신기를 구현해야했습니다. 문제의 데이터는 올바른 형식의 UDP 패킷이지만 흥미롭게도 데이터 페이로드는 항상 나머지 데이터를 사용하여 형성된 CRC16 체크섬으로 끝났습니다.

나는 사양에 따라 내 말에 체크를 구현했지만 이것이 필요한지 항상 궁금했다. 결국, UDP 프로토콜 자체가 16 비트 CRC를 전달하지 않습니까? 따라서 UDP 패킷이 손실되거나 순서가 잘못 될 수는 있지만 OS 프로세스에 도달하기 전에 네트워크 하드웨어에 의해 버리지 않고 손상 될 수 없다는 인상을 받았습니다. 아니면 내가 놓친 특별한 유스 케이스가 있습니까?

내가 방어 산업에서 일하고 있다고 덧붙일 가치가있다. 나는 당신이 상상할 수 있듯이, 이와 같은 모든 것에 대해 명백한 것을 좋아한다. 그래서 그것이 단지 "보안 OCD"의 사례인지 궁금하다. ..

security networking data-integrity

— 제노 프리 메이트
소스

실수로 인한 손상을 막는 것이 아니라 보안을 목적으로하는 경우 체크섬과 같은 키인 MAC을 사용해야합니다.

— 코드 InChaos

UDP 체크섬은 UDP 패킷에 주입 된 데이터에만 적합합니다. 실제로 체크섬을 만드는 것은 무엇입니까? 체크섬을 사용하는 것은 무엇입니까? UDP 패킷이 작성되기 전에 무결성을 보장하거나 다른 시스템을 통과 할 때 무결성을 유지하기 위해 패킷과 함께 전달 될 수 있습니까? 시스템 구성 요소와 데이터 생성, 변환 및 사용 방법에 대한 폭 넓은 이해가 없으면 귀하의 질문에 대한 답변이 확실하지 않습니다.

— Thomas Owens

@ThomasOwens 데이터는 원래 장치에서 수신 하드웨어로 연속적으로 전송되었습니다. 중년 남자는 없습니다. 체크섬은 송신자에 의해 송신 전 마지막 단계로 작성되었습니다.

— Xenoprimate

답변:

UDP 프로토콜은 메시지의 전송 순서 또는 전체에 전달되는 것을 보장하지 않지만, 이러한 메시지되도록 않습니다 않는 전달받을 자동으로 16 비트 체크섬을 포함하여 완전하고 변경되지 않습니다. 즉, 응용 프로그램 계층에 다른 16 비트 체크섬을 추가하는 것은 일반적으로 중복됩니다.

...보통....

먼저 IPv6이 아닌 IPv4의 경우 체크섬은 선택 사항 입니다. 즉, 체크섬 생성 및 유효성 검사를 수행하지 않는 이국적인 구성을 사용 중일 수 있습니다 (이 경우 응용 프로그램 계층에서 네트워크 장비를 판단하는 대신 네트워크 스택을 수정해야 함).

둘째, 16 비트 체크섬을 사용하면 65536의 확률로 완전히 임의의 메시지가 유효한 체크섬을 가질 가능성이 있습니다. 이 오류 한계가 사용 사례에 비해 너무 크면 (그리고 방위 산업에서는 여러 곳을 상상할 수 있습니다) 다른 CRC-16 체크섬을 추가하면 오류가 더욱 줄어 듭니다. 그러나이 경우 CRC-16 대신 SHA-256과 같은 적절한 메시지 요약을 사용하는 것이 좋습니다. 또는 모든 길을 가고 실제 암호화 서명을 사용하십시오. 이는 임의의 손상뿐만 아니라 공격자의 의도적 인 손상도 방지합니다.

셋째, 데이터의 출처와 위치에 따라 네트워크를 통해 전송되기 전이나 후에 손상 될 수 있습니다. 이 경우 메시지 내부의 추가 체크섬이 두 네트워크 호스트 사이의 메시지 무결성을 넘어서 메시지 무결성을 보호 할 수 있습니다.

— 필립
소스

왜 암호화 ? 암호화 해시를 설계하는 데 사용되는 제약 조건은 전송에 사용되는 해시를 설계 할 때 사용되는 제약 조건과 동일하지 않습니다 (예를 들어, 리소스를 많이 사용하는 것은 암호화 해시의 기능이며 전송 문제입니다).

— AProgrammer

@AProgrammer 나는 단어의 선택이 오해의 소지가 있음을 인정한다. 나는 "적절한 메시지 요약"으로 대체했다. 메시지 다이제스트 기능이 훨씬 길어 우발적 인 충돌이 거의 일어나지 않아 실제적인 목적으로는 불가능하다고 가정 할 수 있습니다.

— Philipp

그것은 시도 메시지가 변경되지 않도록하지만, UDP에 사용되는 검사는 다소 약합니다. 모든 16 비트 체크섬에 대해 임의의 메시지가 유효한 체크섬을 가질 확률이 실제로 65536에서 1이지만,보다 유용한 측정은 무작위로 또는 버스트로 배열 된 검출 가능한 비트 플립 수를 포함하며 모든 체크섬은 다음에 따라 동일하게 수행되지 않습니다. 이 측정 항목.

— 벤 Voigt

@AProgrammer Cryptographic hash (MD5, SHA-1 / 2 / 3, ...)는 충돌 저항과 같은 보안 속성을 보장하면서 가능한 한 저렴한 것을 목표로합니다. 일반적으로 초당 수백 MB를 처리 할 수 있으므로 Gbit 연결보다 작은 병목 현상이 발생하지 않아야합니다. 충돌 저항이 필요하지 않은 많은 비 암호화보다 느립니다. 만 암호 해시 (PBKDF2, bcrypt, scrypt, 아르곤, ...)를 계산하는 비싼 것을 목표로하고 있습니다.

— 코드 InChaos

그러나 UDP는 체크섬을 제공합니다.

UDP 체크섬은 16 비트입니다. 이는 손상된 패킷이 체크섬을 통과 할 가능성이 65536의 1을 의미합니다.
IPv4를 통한 UDP에서 체크섬은 선택 사항이므로 보낸 사람은 이론적으로 체크섬없이 패킷을 보낼 수 있습니다.
체크섬은 데이터뿐만 아니라 IP / 포트 정보도 포함합니다. 이는 손상된 주소의 패킷을 삭제하는 데 유용하지만 패킷이 NAT를 통과하면 NAT에 의해 체크섬을 다시 계산해야합니다.
체크섬은 데이터가 UDP 패킷으로 이동하는 동안에 만 데이터를 보호합니다. 응용 프로그램 수준 체크섬은 더 복잡한 시스템을 통과 할 때 데이터를 끝까지 보호 할 수 있습니다.
UDP 체크섬 clealy는 패킷이 UDP 구현에 의해 생성되었음을 알려줍니다. 센서에서 나온 것임을 알려주지는 않습니다. 반면에 애플리케이션 레벨 체크섬은 유효한 UDP이지만 다른 소스에서 온 패킷을 거부하는 데 도움이 될 수 있습니다.

따라서 UDP 체크섬을 신뢰하지 않고 UDP 체크섬을 신뢰하지 않고 합법적으로 약한 체크섬을 응용 프로그램 수준에서 구현하는 합법적 인 이유를 알 수 있습니다.

프로토콜을 사용하는 사람이 UDP가 체크섬을 제공했는지 또는 프로토콜이 실제로 체크섬을 제공하지 않는 매체를 통해 실행되도록 설계된 약간의 변형이라는 것을 알지 못할 가능성이 있습니다.

PS는이 게시물에 보안 태그가 지정되어 있으므로 해당 체크섬이 실수로 변경되는 것을 방지하도록 설계되었습니다. 고의적 인 수정 또는 스푸핑을 방지하려면 고의적 인 충돌 / 사전 이미지에 내성이있는 암호화 해시 기능과 해시 자체가 수정되지 않았 음을 확인하기 위해 일부 메커니즘 (예 : 공개 키를 사용하여 서명)을 사용해야합니다.

— 피터 그린
소스