검증은 두 층이고, 한 층만 보면 반드시 하나를 통과시킨다

한 줄 요약

해시는 맞는데 서명이 깨지는 경우와 서명은 맞는데 해시가 어긋나는 경우는 원인도 대응도 완전히 다르고, 그 둘을 구분하려면 두 층을 다 봐야 한다.

왜 이게 필요했나

"검증을 통과했다" 는 말은 생각보다 애매합니다. 무엇을 통과했는지 물어보면 대개 둘 중 하나만 답합니다. 해시를 대조했다거나, 서명을 확인했다거나. 그런데 이 둘은 서로 다른 것을 지켜 줍니다.

파일 해시가 지키는 것: 매니페스트가 말한 그 파일이 맞는가. 매체에서 옮기다 깨졌는지, 도중에 누가 파일을 바꿨는지를 잡습니다.

서명이 지키는 것: 그 매니페스트를 우리가 아는 사람이 만들었는가. 목록 자체가 바뀌었는지를 잡습니다.

한 층만 보면 어떻게 되는지가 이 글의 요점입니다.

파일 해시만 보는 경우. 누군가 파일을 바꾸고, 들키지 않으려고 매니페스트의 해당 줄까지 새 해시로 고쳐 넣었다고 합시다. 파일 해시 대조는 전부 통과합니다 — 고쳐진 목록을 기준으로 대조했기 때문입니다. 검증은 아무것도 잡지 못합니다.

서명만 보는 경우. 매니페스트와 서명은 손대지 않고 페이로드 파일 하나만 바꿉니다. 서명 검증은 통과합니다 — 매니페스트가 그대로이기 때문입니다. 바뀐 파일은 그대로 설치됩니다.

그래서 두 층을 다 봐야 하고, 순서도 정해져 있습니다.

어떻게 동작하나

받는 쪽의 순서는 이렇습니다.

1) 번들 전체 해시   매체에서 옮기다 깨졌는가.        틀리면 그 자리에서 끝.2) 서명 검증        이 목록을 아는 사람이 만들었는가.  틀리면 파일은 볼 것도 없다.3) 파일별 해시      목록이 말한 그 파일들이 맞는가.

왜 2번이 3번보다 먼저인가. 3번을 먼저 하면 아직 진위가 확인되지 않은 매니페스트를 기준으로 대조하게 됩니다. 고쳐진 목록으로 대조하면 당연히 전부 맞습니다. 순서를 바꾸는 것만으로 검증이 무력해집니다. 이것이 이 모듈에서 가장 자주 틀리는 지점입니다.

그리고 한 가지가 더 있습니다. 공개키가 번들 안에 들어 있으면 서명 검증은 아무것도 지키지 못합니다. 번들을 쥔 사람이 자기 키쌍을 만들어 페이로드·매니페스트·서명·공개키를 한꺼번에 바꿔 넣으면, 받는 쪽은 그 번들 안의 공개키로 그 번들 안의 서명을 검증하고 통과시킵니다. 서명이 의미를 가지려면 신뢰의 뿌리 하나는 다른 길로 와야 합니다. 공개키는 번들과 별도 경로로 전달하고, 받는 쪽은 미리 알고 있는 지문과 대조한 뒤에 씁니다.

현장에서 만나는 모습

두 실패는 무게가 다릅니다. 서명은 맞는데 파일 해시가 하나 어긋난 경우는 전송 중 손상일 가능성이 높습니다. 다시 받아 보면 대개 해결됩니다. 반대로 파일 해시는 전부 맞는데 서명이 깨진 경우는 목록이 통째로 바뀐 것이므로, 다시 받는 것으로 끝날 문제가 아닙니다. 보고 체계가 달라집니다. 그래서 반입 기록에는 "검증 실패" 가 아니라 어느 층에서 깨졌는지 를 적습니다.

개인키의 위치가 자주 사고를 냅니다. 서명 작업 디렉터리를 통째로 압축해 넘겼다가 개인키가 함께 나간 사고가 있습니다. 개인키는 권한을 600 으로 두고, 번들에 무엇이 들어갔는지는 tar -tzf 로 반드시 눈으로 확인합니다. 넣지 않았다고 생각하는 것과 목록에 없는 것은 다른 사실입니다.

해시 파일과 번들은 같이 낡습니다. 번들을 다시 묶으면 해시가 바뀝니다. 문서에 적어 둔 값, 해시 파일, 실제 번들 이 셋이 언제나 같아야 하는데, 다시 묶는 순간 셋이 갈라집니다. 묶기와 해시 뜨기와 문서 갱신을 하나의 절차로 묶어 두지 않으면 반드시 어긋납니다.

다음 실습에서 할 것

같은 번들을 두 벌 풀어 각각 다른 변조를 넣습니다. 하나는 바이너리 한 바이트만 바꾸고, 다른 하나는 같은 변조에 더해 매니페스트의 해당 줄까지 새 해시로 고칩니다. 그리고 두 벌 모두에 서명 검증과 파일 해시 대조를 걸어, 어느 쪽이 어디서 깨지는지를 숫자로 확인합니다. 두 결과가 정반대로 나오는 것을 직접 보는 것이 이 실습의 핵심입니다.