서명과 체크섬은 서로 다른 질문에 답한다

체크섬이 알려 주는 것

SHA-256 같은 암호학적 해시는 파일 바이트를 일정 길이의 요약값으로 결정적으로 변환한다. 내 사본의 요약값이 예상값과 다르면 해당 기준과 일치하지 않는다. 예상값이 정확히 어느 버전을 가리키는지 안다면 전송 중 손상이나 의도하지 않은 변경을 찾는 데 유용하다.

하지만 누구나 바꾼 파일의 해시를 계산해 새 요약값을 게시할 수 있다. 적대적인 출처가 다운로드와 비교값을 모두 통제한다면 둘의 일치가 출처를 크게 안심시켜 주지는 않는다. 무해한 한 바이트 메시지 두 개로 작은 사실을 확인했다. 요약값은 서로 다르고, 각 메시지는 자신에 대해 새로 계산한 요약값과 일치했다.

비교 대상은 정확한 산출물이다. 압축 파일과 풀어낸 파일, 다시 묶은 압축본은 비슷한 내용을 담아도 바이트가 다르다. 게시자의 지침이 지정한 대상을 비교하자. 편의상 다른 것을 해시해 불일치했다고 곧바로 변조가 입증되지는 않는다. 대상을 잘못 비교했을 수도 있다.

서명은 증거를 더한다

공개키 서명 방식에서는 개인키로 서명하고 대응하는 공개키로 검증한다. 검증 성공은 해당 방식의 가정 아래 정확한 바이트와 그 키에 대한 판단을 뒷받침한다. 검증자에게 서명용 개인키를 줄 필요가 없으므로 공개 소프트웨어 배포에 유용하다.

그러나 공개키가 의도한 게시자와 연결된다는 신뢰할 만한 근거는 여전히 필요하다. 임의의 키 아래 유효한 서명은 신원 확인이 아니다. 서명은 메시지를 암호화하지도 않는다. 원래 읽을 수 있는 파일이라면 가진 사람은 여전히 읽을 수 있다. 진위, 기밀성, 유용성은 서로 다른 속성이다.

공개 키와 게시자의 관계는 단순한 검증 결과 밖의 근거가 필요하다. 낯선 파일과 함께 온 키만으로는 그 관계를 독립적으로 확인할 수 없다. 확립된 소프트웨어 배포 체계의 지원 도구가 신뢰 관계를 관리할 수 있다. 경고를 없애려고 새 키를 받아들이기보다 문서화된 절차를 따르자.

자격 증명 생성 없이 검증

실제 로컬 확인에는 RFC 8032의 Ed25519 벡터 중 TEST 2를 사용했다. 메시지는 16진수 72인 한 바이트다. 공개된 32바이트 공개키와 64바이트 서명만 설치된 cryptography 라이브러리에 불러왔다. 자격 증명 생성, 개인키 불러오기, 새 서명 만들기는 하지 않았다.

공개된 메시지는 검증에 성공했다. 메시지 바이트를 16진수 73으로 바꾸자 거부됐다. 원래 메시지로 되돌린 뒤 서명의 한 비트를 뒤집어도 거부됐다. 이는 검증 API에서 실제로 나온 결과이며 로그인 시스템 시험, 다운로드 서비스 보호, 실제 조직 인증의 증거는 아니다.

기준은 어디에서 왔는가

실제 소프트웨어는 게시자가 문서화한 검증 절차를 따르고, 적절하다면 검증된 설치 프로그램, 패키지 관리자, 운영체제 신뢰 체계를 사용하자. 중요한 것은 예상 키나 요약값이 어떤 경로로 왔는가이다. 낯선 페이지에서 파일 옆에 키를 놓았다는 사실만으로 소유자가 독립적으로 입증되지는 않는다.

키는 바뀌거나 폐기되거나 유출될 수 있다. 의미 있는 검증에는 수학적 검사 성공뿐 아니라 최신 신뢰 정보와 올바른 릴리스 맥락이 필요할 수 있다. 이번 공개 표준 예시는 그런 운영 문제를 의도적으로 다루지 않는다. 재현 가능하다는 장점이 있지만 시험 키는 신뢰할 수 있는 소프트웨어 게시자를 나타내지 않는다.

공식 출시 페이지와 채팅으로 받은 파일, 같은 채팅의 체크섬을 생각해 보자. 둘이 일치하면 보낸 사람이 일관된 쌍을 제공했다는 뜻일 수 있지만 공식 페이지의 권위를 재현하지는 않는다. 게시자에게 독립적으로 접근해 제품과 버전, 플랫폼을 확인한 뒤 어떤 기준값이나 서명 신원이 관련되는지 정한다.

서명됐어도 적합하지 않을 수 있다

올바르게 서명된 프로그램에도 결함이 있거나 원치 않는 일을 하거나 부여하면 안 되는 권한을 요청할 수 있다. 서명은 키 관계를 확인하는 데 도움이 될 뿐 모든 동작에 대한 검토는 아니다. 서명된 구버전 역시 진짜 게시물일 수 있지만 최신 지원 버전의 수정 사항이 없을 수 있다.

정확한 파일, 대상 플랫폼, 릴리스 정보와 출처를 확인하자. 페이지에 서명됐다고 적혀 있다는 이유로 경고를 넘기지 말자. 검증이 실패하면 불편한 추가 절차로 치부하지 말고 멈춘 뒤 게시자의 알려진 경로로 조사해야 한다. 검사 성공과 실행할 만한 충분한 근거는 관련 있지만 같지는 않다.

파일을 보관할지와 실행할지를 나누자. 검증 성공은 출처를 뒷받침해도 필요성과 권한, 호환성을 해결하지는 않는다. 검증 실패는 멈춰 조사할 이유이지 작동할 때까지 검사를 끌 이유가 아니다. 게시자의 지원 경로로 차이를 해결하고 모든 실패를 특정 공격의 증거로 보지 않는다.

줄바꿈 하나도 서명 대상을 바꾼다

같은 공개 RFC 시험 벡터의 한 바이트 메시지에 줄바꿈 바이트를 붙였다. 두 바이트 버전은 거부됐다. 캐리지 리턴과 줄바꿈을 붙인 세 바이트 버전도 거부됐고 원래 한 바이트는 통과했다. SHA-256 값 세 개도 달랐다. 실제 내려받은 문서 외형이 아니라 작은 바이트 변경의 결과다.

다음에는 원래 메시지와 서명을 유지하고 다른 공개 RFC 시험 벡터의 공개 키를 제공했다. 검증은 실패했다. 그럴듯한 공개 키 아무거나 주면 통과하는 것이 아니라는 음성 대조다. 새 키나 서명은 만들지 않았다. 두 공개 시험 키는 소프트웨어 게시자 신원이 아닌 교육용 표본이다.

일반 독자도 16진수를 다루지 않고 이 구분을 활용할 수 있다. 공식 검증 단계 동안 받은 산출물을 보존하고 서명된 텍스트를 확인 전에 열어 다시 저장하지 않는다. 불일치가 나오면 신뢰하는 출처에서 대상과 출시 정보를 확인한다. 거부는 검사 실패를 뜻할 뿐 원인을 스스로 설명하지 않는다.

새 프로토콜을 만들 필요는 없다

일반 독자에게 유용한 능력은 어떤 증거가 있는지 묻는 것이다. 체크섬은 기준과의 비교이고, 서명은 키 관계를 더한다. 믿을 수 있는 배포 경로는 키에 더 많은 맥락을 제공하지만 소프트웨어 목적과 권한은 여전히 살펴야 한다. 낯선 배지가 이 과정을 대신해서는 안 된다.

짧은 암호 예시를 새 보안 시스템에 복사하기보다 지원되는 검증 도구를 사용하자. 이번 코드는 공개 예시와 몇 가지 실패 검사로 의도적으로 제한했다. 결론은 작고 정확하다. 주어진 공개 시험 키에서 서명된 메시지나 해당 서명을 바꾸면 검증이 중단됐다.