(문서 작성 이유)

• BLE 펌웨어 업데이트 기능을 개선하기 위해 OTA 기능 구현부를 분석하던 중, 데이터 전송 과정에 있어 CRC와 SHA를 사용한 흔적이 발견되어 관련 내용을 학습하고자 함

SHA (Secure Hash Algorithm)

• 데이터의 위변조를 감지하고 무결성을 보장하기 위해 사용한다.
• 암호학적 해시 함수의 한 종류로 입력 데이터를 고정된 길이의 출력 값으로 변환한다.
• 고정된 비트 크기의 해시 값을 반환하며 충돌 발생 확률이 지극히 낮다. (충돌 공격에 취약한 MD5 대신 사용)
• SHA는 충돌 저항성이 높은 만큼 더 복잡한 계산을 필요로 하므로 무거운 연산에 속한다.

CRC (Cyclic Redundancy Check)

• 데이터 전송 중에 발생할 수 있는 오류를 검출하기 위해 사용한다.
• CRC 계산에 사용되는 다항식은 16진수(혹은 2진수)로 나타낸다.
  • CRC-16-IBM: x^16 + x^15 + x^2 + 1 (0x8005 = 1000 0000 0000 0101)
  • 참고로 CRC 다항식에서는 가장 높은 차수를 암시적으로 포함시기기 때문에 해당 값은 나타내지 않는다.
• 검증 프로세스
  • 원본 데이터에 다항식의 비트 수 - 1 만큼의 0을 추가한다.
  • 데이터의 앞자리가 1비트인 곳에 다항식 비트를 두고 xor 연산을 수행한다.
  • 연산 수행 결과에서 다시 앞자리가 1비트인 곳에 다항식 비트를 두고 xor 연산 수행하기를 반복한다.
  • 이후 송신측에서 보낸 CRC 값과 수신측이 계산한 CRC 값의 일치 여부 확인
• 어떤 길이의 CRC를 사용해야 하는가?
  • CRC 비트의 길이는 검사 결과 값의 크기를 의미한다.
  • CRC-8은 8비트의 검사 값을 생성하고, CRC-16은 16 비트의 검사 값을 생성한다.
  • 이는 결과적으로 검사 가능한 시나리오가 각각 256개, 65536개가 됨을 의미한다.
  • CRC가 길수록 더 많은 오류를 검출할 수 있지만, 계산 비용도 그만큼 커질 수밖에 없다.
  • 작은 데이터에 대해서는 작은 비트의 CRC를, 큰 데이터에 대해서는 큰 비트의 CRC를 사용하도록 한다.
    • 통신 프로토콜에서 패킷의 오류 검출은 16, 파일 무결성 체크의 경우 32, 매우 큰 데이터 세트를 처리할 경우 64를 사용한다고 한다. (보다 상세한 기준 관련해서는 추가 스터디 필요)
• CRC vs SHA
  • CRC는 오류 검출 목적으로는 적합하나 보안 목적(위조 방지, 정합성 보증)으로 사용하기에는 다소 취약하다.
  • SHA는 해시 충돌이 거의 없으므로 데이터의 위조 여부를 확인하는 암호학적인 보안 강화 목적으로 사용한다.
  • 단, SHA는 내부에 복잡한 비트 연산이 포함되어 있으므로 최종 단계에서 한 번만 사용하도록 한다.
• 어떤 시나리오에서 주로 사용하는가?
  • 데이터 블록 전송 중 오류 검출 -> CRC
  • 데이터 전체에 대한 무결성 검증 -> SHA

Parity Bit

• 데이터 전송 중에 발생할 수 있는 오류를 검출하기 위해 사용한다.
• 전송할 데이터에 1비트의 추가 비트를 더하여, 데이터 내의 비트가 홀수 또는 짝수가 되도록 맞추는 방식
• 구현이 매우 간단하고 연산이 빠르다는 장점을 지닌다.
• 단일 비트 오류만을 검출할 수 있다는 한계를 지닌다.

Checksum

• 데이터 전송 중에 발생할 수 있는 오류를 검출하기 위해 사용한다.
• 데이터를 숫자나 이진수의 합으로 변환한 후, 전송 중에 데이터가 변경되었는지 확인하는 방식
• 단순 체크섬 외에 1의 보수 체크섬 등 다양한 방식이 존재한다.
• 다중 비트 오류를 검출하는데 한계가 있다.
  • 체크섬 충돌일 발생할 수 있다. (두 아스키 코드의 합을 체크섬으로 가정할 경우 "AB" = "BA")
  • CRC는 다항식을 기반으로 다중 비트 오류를 검출할 수 있다.
• CRC에 비해 연산은 가벼우나 그만큼 오류 검출 능력은 떨어진다.