Agent에서 사용하는 파일 무결성 검증 방식
Agent에서 맵 파일을 배포할 때는 파일을 다운로드한 뒤 무결성 검증을 수행한다.
여기서 무결성 검증이란 Agent가 다운로드한 파일이 서버에서 전달한 원본과 동일한지 확인하는 과정이다.
파일이 네트워크를 통해 전송되는 동안 일부 데이터가 손상되거나 잘못된 파일이 전달되면, 이후 압축 해제나 맵 로드 과정에서 문제가 발생할 수 있다.
이를 방지하기 위해 Agent는 파일을 다운로드한 직후 무결성을 확인한다. 검증에 실패하면 압축 해제나 맵 적용 단계로 넘어가지 않고 배포를 중단한다.
맵 파일 다운로드
↓
파일 무결성 검증
↓
검증 성공 여부 확인
┌────┴────┐
│ │
성공 실패
│ │
압축 해제 배포 중단
│
맵 로드파일 무결성을 확인하는 방법
파일 무결성을 확인하는 방법에는 여러 가지가 있다.
대표적으로 다음과 같은 방식을 생각해볼 수 있다.
- CRC32와 같은 단순 체크섬
- BLAKE3와 같은 암호학적 해시
- Merkle Tree 기반 검증
각 방식은 검증 목적과 파일 전달 구조에 따라 장단점이 다르다.
단순 체크섬
체크섬은 파일 내용을 바탕으로 짧은 검증 값을 계산하는 방식이다.
서버가 원본 파일의 체크섬을 미리 계산하고, Agent가 파일을 다운로드한 뒤 같은 방식으로 다시 체크섬을 계산한다.
서버의 체크섬 값
↕ 비교
Agent가 계산한 체크섬 값두 값이 같으면 파일이 정상적으로 전달된 것으로 판단하고, 값이 다르면 전송 과정에서 파일이 손상되었거나 다른 파일이 전달된 것으로 판단한다.
CRC32와 같은 단순 체크섬은 계산 속도가 빠르고 구현이 간단하다. 따라서 네트워크 전송 중 발생할 수 있는 우발적인 데이터 손상을 확인하는 용도로 널리 사용된다.
하지만 파일 동일성을 더 강하게 확인해야 하는 상황에서는 한계가 있다.
단순 체크섬은 충돌 가능성이 상대적으로 높고, 의도적으로 변경된 파일을 검증하는 용도로 설계된 방식도 아니다.
따라서 중요한 배포 파일을 검증할 때는 일반적으로 암호학적 해시를 사용하는 것이 더 적합하다.
BLAKE3
BLAKE3는 파일 내용을 기반으로 고정된 길이의 해시 값을 계산하는 암호학적 해시 함수다.
파일 내용이 아주 조금만 달라져도 이전과 전혀 다른 해시 값이 생성된다.
예를 들어 파일에서 한 바이트만 변경되더라도 계산 결과는 크게 달라진다.
원본 파일
→ 7b4c...
일부가 변경된 파일
→ a19f...서버와 Agent가 같은 파일을 대상으로 BLAKE3 해시를 계산했을 때 결과가 같다면, 두 파일의 내용이 동일하다고 판단할 수 있다.
BLAKE3의 주요 장점은 다음과 같다.
- 대용량 파일에서도 빠르게 계산할 수 있다.
- 파일 내용 변경에 민감하다.
- 병렬 처리를 고려해 설계되었다.
- 단순 체크섬보다 충돌 가능성이 매우 낮다.
- 전체 파일 동일성 검증에 적합하다.
즉, BLAKE3는 파일 검증의 정확성을 유지하면서도 처리 시간을 줄이기 좋은 방식이다.
Merkle Tree
Merkle Tree는 파일 전체를 하나의 값으로만 검증하지 않고, 파일을 여러 개의 블록으로 나눠 각각의 해시를 계산하는 방식이다.
각 블록의 해시는 다시 상위 해시로 결합되고, 최종적으로 하나의 Root Hash가 만들어진다.
Root Hash
/ \
Hash A Hash B
/ \ / \
Block 1 Block 2 Block 3 Block 4Merkle Tree의 가장 큰 장점은 부분 검증이 가능하다는 것이다.
예를 들어 대용량 파일의 일부만 변경되었거나 손상된 경우, 전체 파일을 다시 비교하지 않고 문제가 있는 블록만 찾아낼 수 있다.
다음과 같은 환경에서는 Merkle Tree가 유리하다.
- 파일 일부만 다시 다운로드하는 구조
- 블록 또는 Chunk 단위 데이터 검증
- 여러 노드에 데이터가 분산된 저장소
- 데이터 일부를 병렬로 검증하는 구조
- 변경된 부분만 동기화하는 시스템
하지만 Merkle Tree를 사용하려면 파일 분할 기준, 블록별 해시, 트리 구성 정보 등을 별도로 관리해야 한다.
전체 파일을 한 번에 다운로드한 뒤 정상 여부만 확인하는 구조라면, 이러한 복잡도에 비해 얻을 수 있는 이점이 크지 않을 수 있다.
현재 Agent에서 사용하는 방식
현재 Agent는 맵 파일의 무결성을 확인하기 위해 BLAKE3 기반 해시 검증을 사용한다.
검증 흐름은 다음과 같다.
1. 서버가 원본 맵 파일의 BLAKE3 해시를 계산한다.
2. Agent가 맵 파일과 해시 값을 전달받는다.
3. Agent가 다운로드한 파일의 BLAKE3 해시를 계산한다.
4. 서버에서 받은 해시와 Agent가 계산한 해시를 비교한다.
5. 값이 다르면 배포를 중단한다.
6. 값이 같으면 압축 해제와 맵 로드를 진행한다.검증은 압축 파일을 해제하기 전에 수행한다.
파일 다운로드
↓
BLAKE3 해시 계산
↓
서버 해시와 비교
↓
일치 여부
┌──┴──┐
│ │
일치 불일치
│ │
압축 해제 배포 실패
│
맵 로드파일이 손상되었거나 원본과 다른 경우에는 후속 작업을 실행하지 않는다.
이를 통해 잘못된 파일이 실제 배포 경로로 진입하는 것을 방지할 수 있다.
단순 체크섬을 사용하지 않은 이유
CRC32와 같은 단순 체크섬은 빠르고 구현하기 쉽다.
하지만 현재 Agent가 검증하는 파일은 단순한 로그나 임시 데이터가 아니다. 실제 Robot의 맵 배포에 사용되는 중요한 파일이다.
맵 파일에 문제가 생기면 단순히 압축 해제에 실패하는 것으로 끝나지 않을 수 있다.
- 잘못된 맵이 로드될 수 있다.
- 기존 맵과 다른 데이터가 적용될 수 있다.
- Robot의 위치 추정이나 주행에 영향을 줄 수 있다.
- 배포된 장비마다 서로 다른 파일이 적용될 수 있다.
따라서 단순히 전송 과정에서 데이터가 깨졌는지를 확인하는 것보다, Agent가 받은 파일이 서버의 원본과 동일한지를 확인하는 것이 중요하다.
BLAKE3는 단순 체크섬보다 강한 동일성 검증을 제공하면서도 대용량 파일을 빠르게 처리할 수 있다.
이러한 이유로 현재 배포 구조에서는 속도와 검증 신뢰성 사이의 균형이 좋은 선택이라고 판단했다.
Merkle Tree를 사용하지 않은 이유
Merkle Tree는 부분 검증과 Chunk 단위 동기화에 강한 방식이다.
하지만 현재 Agent의 파일 배포 구조에서는 파일 일부만 다운로드하거나 변경된 블록만 다시 전송하지 않는다.
서버에서 하나의 배포 파일을 다운로드한 뒤, 파일 전체가 정상인지 확인하고 다음 단계로 넘어간다.
현재 Agent에 필요한 검증은 다음과 같다.
다운로드한 전체 파일이 서버의 원본과 같은가?반면 Merkle Tree는 다음과 같은 요구사항에서 더 큰 장점을 가진다.
파일의 어느 부분이 변경되었는가?
어떤 Chunk만 다시 다운로드해야 하는가?
일부 데이터만 빠르게 검증할 수 있는가?현재 구조에 Merkle Tree를 적용하면 블록별 해시와 트리 데이터를 추가로 관리해야 하지만, 실제 배포 과정에서 얻는 이점은 제한적이다.
따라서 Agent에서는 더 단순하고 관리하기 쉬운 BLAKE3 기반 전체 파일 검증을 선택했다.
BLAKE3만으로 모든 보안 문제가 해결되는가
BLAKE3 해시가 일치하면 Agent가 받은 파일의 내용이 서버에서 계산한 파일과 동일하다는 것을 확인할 수 있다.
다만 해시 값과 파일이 모두 신뢰할 수 없는 경로를 통해 함께 전달된다면, 공격자가 파일과 해시를 동시에 바꾸는 상황까지 막을 수는 없다.
파일만 변경
→ 해시 비교로 감지 가능
파일과 해시를 함께 변경
→ 별도의 신뢰 수단이 필요악의적인 파일 교체까지 방지해야 한다면 다음과 같은 방법을 추가로 고려할 수 있다.
- HTTPS 또는 TLS를 통한 전송 구간 보호
- HMAC을 이용한 해시 인증
- 전자서명을 이용한 배포 파일 검증
- 신뢰할 수 있는 별도 경로로 해시 전달
현재 BLAKE3 검증의 주된 목적은 다운로드 과정에서 발생한 손상이나 잘못된 파일 전달을 확인하는 것이다.
향후 배포 파일의 출처까지 검증해야 한다면 전자서명이나 HMAC 기반 검증을 추가할 수 있다.
정리
파일 무결성을 확인하는 대표적인 방식으로는 단순 체크섬, BLAKE3, Merkle Tree가 있다.
단순 체크섬은 빠르고 구현하기 쉽지만, 주로 우발적인 데이터 손상을 감지하는 데 적합하다.
Merkle Tree는 파일을 여러 블록으로 나눠 부분적으로 검증할 수 있다는 장점이 있지만, 전체 파일을 하나의 단위로 배포하는 현재 구조에서는 복잡도가 높다.
현재 Agent는 맵 파일을 하나의 배포 단위로 다운로드한 뒤, 서버가 전달한 원본과 동일한지만 확인하면 된다.
따라서 Agent에서는 다음과 같은 이유로 BLAKE3를 사용한다.
- 대용량 파일을 빠르게 처리할 수 있다.
- 파일의 작은 변경도 감지할 수 있다.
- 단순 체크섬보다 강한 동일성 검증이 가능하다.
- Merkle Tree보다 구현과 운영이 단순하다.
- 현재의 전체 파일 배포 방식과 잘 맞는다.
결국 현재 Agent의 무결성 검증은 복잡한 검증 시스템을 구축하기 위한 것이 아니다.
배포 과정에서 가장 중요한 다음 질문에 빠르고 정확하게 답하기 위한 방식이다.
Agent가 다운로드한 파일은 서버가 전달한 원본 파일과 동일한가?
테스트..
- merkle tree는 애초에 우리가 사용하고 있던 방식과 다르기 때문에 테스트를 진행하지 않았다.
- 이후 더욱 고도화를 위한 방식으로는 생각해볼 수 있다.
