개발자 도구 · SHA 해시 계산기
일치하는 체크섬은 서명이 아닙니다: 무결성 대 신뢰성
· 그것이 중요한 이유
샤-256 암호화 보안
게시된 SHA-256을 통해 사용자는 손상된 다운로드를 감지할 수 있지만 공격자가 페이지를 제어하는 경우 체크섬도 제어합니다. 이 게시물에서는 무결성과 진정성을 분리하고 서명이 추가되는 내용을 설명합니다.
다운로드와 동일한 페이지의 체크섬 - 손상으로부터 보호하지만 손상된 호스트로부터는 보호하지 않는 이유
소프트웨어 릴리스는 다운로드와 동일한 페이지에 SHA-256 체크섬과 함께 게시됩니다. 사용자는 아카이브를 가져와 해시하고 결과를 게시된 값과 비교할 수 있습니다. 일치하면 다운로드가 손상되지 않은 것입니다. 이는 무결성 검증이며 실제적이고 유용한 점검입니다. 그러나 공격자가 릴리스를 호스팅하는 웹 서버를 손상시키는 경우 바이너리를 교체하고 해당 SHA-256을 다시 계산하고 페이지의 체크섬을 업데이트할 수 있습니다. 사용자가 체크섬을 확인하면 공격자의 악성 코드가 게시자로부터 온 것으로 보입니다. 시스템은 설계된 대로 정확하게 작동했지만 사용자가 묻는 질문에 대답하지 못했습니다.
이는 체크섬 자체의 실패가 아닙니다. 체크섬이 수행하는 작업과 수행하지 않는 작업에 대한 올바른 관찰입니다. 체크섬은 두 개의 데이터 복사본이 동일하다는 것을 증명합니다. 누가 데이터를 생성했는지는 증명되지 않습니다. 이것이 무결성과 신뢰성의 차이이며 이를 혼동하는 것은 릴리스 검증에서 가장 흔한 보안 실수 중 하나입니다. 많은 시스템이 고장나는 이유는 체크섬이 잘못되었기 때문이 아니라 사용자가 대답할 수 없는 질문에 대답할 것이라고 신뢰하기 때문입니다.
해시가 증명하는 것 — 두 입력이 동일한 바이트이며 누가 생성했는지는 알 수 없습니다.
무결성은 데이터 자체의 속성입니다. 파일과 해당 SHA-256이 있고 파일이 수정되지 않은 경우 해시가 일치합니다. 해시는 모든 바이트가 계산된 시점부터 변경되지 않았음을 증명합니다. 전송 오류, 디스크 오류 또는 네트워크 케이블의 비트 반전으로 인해 파일이 손상된 경우 해시가 일치하지 않습니다. 이것이 체크섬의 역할입니다. 그들은 사고와 무작위 부패를 포착하는 데 탁월합니다. 해시도 계산할 수 있는 적에게는 실패합니다.
진위성은 데이터를 생성한 사람에 대한 주장의 속성입니다. "이 파일은 내가 신뢰하는 게시자가 보낸 것입니까?"라는 질문이 있습니다. "이 파일이 수정되었습니까?"라는 질문과 근본적으로 다릅니다. 누구나 해시를 계산할 수 있기 때문에 해시 자체만으로는 진위 여부에 대한 질문에 답할 수 없습니다. 파일을 수정하는 공격자는 합법적인 게시자가 할 수 있는 것처럼 쉽게 새 해시를 계산하고 게시할 수 있습니다. 해싱은 대칭적입니다. 방어자와 공격자 모두 동일한 계산 능력을 가지고 있습니다.
신뢰할 수 있는 채널 요구 사항 — 체크섬을 어디서 얻었는지에 따라 신뢰할 수 있는 이유
신뢰할 수 있는 채널 요구 사항이 핵심 통찰력입니다. 체크섬은 통과한 채널만큼만 신뢰할 수 있습니다. 게시자의 공식 CDN에서 소프트웨어 바이너리를 다운로드하고 동일한 서버에서 체크섬을 다운로드하면 동일한 경로를 이동했습니다. 서버를 손상시킨다는 것은 공격자가 두 가지 모두를 제어한다는 것을 의미합니다. 체크섬은 배달 중 손상에 대한 방어 기능을 제공하지만(손상된 파일은 일치하지 않음) 소스를 제어하는 공격자에 대해서는 방어할 수 없습니다. 체크섬과 파일은 단일 실패 지점을 공유합니다.
체크섬이 다른 액세스 제어를 사용하여 다른 서버에 별도로 게시된 경우 더 많은 방어력을 제공합니다. 기본 사이트를 손상시키는 공격자는 일치하는 쌍을 위조하기 위해 두 위치를 모두 손상시켜야 합니다. 이것이 더 좋지만 여전히 보안을 유지하는 두 개의 독립적인 제어 지점에 의존합니다. 공격자는 이제 하나가 아닌 두 개의 시스템을 침해해야 하므로 공격 비용이 증가합니다. 그러나 이는 아직 진위 여부를 증명하는 것은 아닙니다. 그것은 단지 더 비싼 공격일 뿐입니다.
서명은 해시를 ID에 바인딩합니다. 개인 키로 다이제스트에 서명하여 신뢰성을 추가하는 방법
디지털 서명은 암호화를 사용하여 데이터를 ID에 바인딩하여 이 문제를 해결합니다. 게시자는 키 쌍(비밀로 유지하는 개인 키와 게시하는 공개 키)을 생성합니다. 다이제스트를 계산한 다음 해당 다이제스트를 개인 키로 암호화하여 파일에 서명합니다. 결과는 서명입니다. 사용자는 게시자의 공개 키로 서명을 해독하고 결과가 수신된 파일의 계산된 다이제스트와 일치하는지 확인하여 서명을 확인합니다. 암호화는 체크섬이 달성할 수 없는 비대칭성을 만듭니다.
이것이 작동하면 데이터가 게시자가 서명한 다이제스트와 일치하고 서명하는 데 사용된 개인 키가 게시된 공개 키와 일치한다는 두 가지가 입증됩니다. 이는 공격자가 만든 것이 아니라 게시자가 만든 것임을 증명합니다. 공개 키는 보안 채널(일반적으로 신뢰할 수 있는 인증 기관의 인증서)을 통해 제공되어야 하지만 일단 공개 키가 있으면 해당 게시자의 서명을 무기한 확인할 수 있습니다. 이제 공격을 위해서는 개인 키를 훔쳐야 하는데, 이는 웹 서버를 손상시키는 것보다 훨씬 어렵습니다.
실제 사례 — 세 가지 위협 시나리오(손상된 미러, 손상된 페이지, 악의적인 내부자) 및 각각이 포착하는 체크섬 및 서명
세 가지 위협 시나리오가 차이점을 보여줍니다. 시나리오 1: 다운로드 미러가 임의의 오류로 인해 손상되었습니다. 체크섬이 이를 포착합니다. 서명이 그것을 포착합니다. 둘 다 공격자를 물리칠 필요가 없기 때문에 둘 다 똑같이 잘 작동합니다. 시나리오 2: 공격자가 파일과 체크섬을 대체하여 미러가 손상되었습니다. 체크섬이 보호되지 않습니다. 공격자가 개인 키를 갖고 있지 않고 유효한 서명을 위조할 수 없기 때문에 서명은 여전히 작동합니다. 공격자는 무엇이든 게시할 수 있지만 서명을 보면 게시자가 보낸 것이 아니라는 것이 입증됩니다.
시나리오 3: CDN이 손상되었지만 서명이 다른 채널을 통해 게시되었습니다. CDN의 체크섬은 신뢰할 수 없지만 서명 확인은 여전히 작동합니다. 무결성 검사는 채널이 아닌 게시자의 키에 암호화 방식으로 연결되어 있기 때문입니다. 공격자는 이제 개인 키가 필요한 서명을 위조해야 합니다. 서명은 서버 손상 후에도 살아남는 유일한 확인 방법입니다. 이것이 진정성을 위해 서명이 필요한 이유입니다. 채널 손상에도 불구하고 신원을 증명하는 유일한 도구입니다.
TLS의 역할 및 한계 - 전송 보안은 게시자의 서버가 아닌 이동 중인 다운로드를 보호합니다.
전송 보안은 인증서에 지정된 호스트에 대한 연결을 보호합니다. 경로에 있는 관찰자가 다운로드 바이트를 대체하는 것을 방지할 수 있지만 손상된 게시자 원본을 정직하게 만들 수는 없습니다. 해당 원본이 수정된 아카이브와 유효한 TLS를 통해 새로 계산된 체크섬을 제공하는 경우 둘 다 그대로 도착하고 여전히 공격자가 제어하는 콘텐츠를 설명합니다.
이것이 전송, 무결성 및 신뢰성이 별도의 레이어인 이유입니다. TLS는 채널을 보호하고 다이제스트는 바이트를 비교하며 서명은 확인 결과를 개인 키 제어와 연결합니다. 릴리스 워크플로가 세 가지 모두를 현명하게 결합하는 경우에도 레이어가 다른 레이어에서 제공하는 속성을 증명하는 것으로 설명되어서는 안 됩니다.
여기서 다루지 않는 내용 — 서명의 어려운 부분인 키 배포 및 신뢰 루트
키 배포는 이 다이제스트 계산기가 넘지 않는 엄격한 경계입니다. 서명 검증자에게는 여전히 인증된 공개 키 또는 인증서 체인과 교체, 해지 및 허용 가능한 알고리즘에 대한 정책이 필요합니다. 신뢰할 수 없는 키 아래의 수학적으로 유효한 서명은 해당 신뢰할 수 없는 키의 소유자가 바이트에 서명했다는 것만 증명합니다.
따라서 신뢰할 수 있는 키를 이미 사용할 수 있는 경우 작업된 시나리오가 중지됩니다. 인증서 고정, 공개 키 인프라 또는 릴리스 키 행사를 규정하지 않습니다. 이러한 배포 선택에는 자체적으로 검토된 설계가 필요합니다. ToolAcre는 신원을 검증하는 데 사용되는 신뢰 루트가 아닌 서명될 수 있는 일반 다이제스트를 제공합니다.
요약: 무결성을 위한 체크섬, 진위를 위한 서명 — ToolAcre SHA 해시 계산기는 다이제스트를 계산합니다. 누가 게시했는지 확인하는 것은 별도의 단계입니다.
ToolAcre SHA 해시 계산기는 이 확인의 무결성 측면을 계산합니다. 이를 사용하여 다운로드한 파일을 해시하고 게시된 값을 확인합니다. 일치하면 다운로드가 손상되지 않은 것입니다. 그러나 공격자가 둘 다 다시 작성했기 때문에 일치하는 경우 무결성 확인만으로는 이를 포착할 수 없습니다. 이 도구는 이러한 제한 사항에 대해 솔직하며 진위 여부를 확인한다고 주장하지 않습니다. 무결성을 위해서만 체크섬이 빠르고 양호합니다. 진정성을 위해서는 서명이 필요합니다. TLS는 다운로드 자체에 대한 전송 보안을 제공합니다. 서버에 대한 연결은 암호화되고 인증되므로 네트워크의 공격자가 전송 중인 파일을 수정할 수 없습니다. 그러나 서버 자체가 손상된 경우 TLS는 도움이 되지 않습니다. 손상된 서버는 보안 TLS 연결을 통해 모든 파일을 제공할 수 있습니다. 이것이 애플리케이션 수준 확인(체크섬 및 서명)이 전송 보안과 별도로 중요한 이유입니다.
소프트웨어 릴리스의 일반적인 패턴은 체크섬과 서명을 모두 게시하는 것입니다. 체크섬은 편리합니다. 사용자는 한 줄의 셸 명령으로 이를 신속하게 확인할 수 있습니다. 서명은 게시자의 공개 키를 가지고 있는 사용자에게 신뢰성을 제공합니다. 사용자는 빠른 무결성 통과를 위해 먼저 체크섬을 확인한 다음 GPG 키링에 저장된 키에 대해 서명의 진위 여부를 확인할 수 있습니다. 두 가지 검사는 서로 다른 목적으로 사용되며 심층적인 방어를 위해 계층화될 수 있습니다. 서명의 어려운 부분은 키 배포와 신뢰입니다. 게시자의 공개 키가 필요하며 그것이 실제로 게시자의 것임을 신뢰해야 합니다. 이는 인증 기관이 해결하기 위해 존재하는 문제입니다. 발행자 인증서에 서명하고 루트 CA 인증서는 브라우저 및 운영 체제에 미리 로드됩니다. 소규모 프로젝트의 경우 별도의 강화된 웹사이트나 공개 키 서버에 GPG 키를 게시할 수 있습니다. 체크섬은 확인하는 것이 저렴합니다. 서명에는 신뢰 루트 관리가 필요합니다. 추가적인 복잡성은 진정성의 대가입니다.