요약

  • 10월 27일자 개인 Internet-Draft는 BPSec 수신자가 필수 보안 서비스와 대상 블록마다 권한 있는 Security Source 및 그 키를 미리 기록하도록 제안한다. 다른 합법적 노드의 유효한 블록은 그 요건을 대신 충족하지 못한다.
  • 페이로드를 보호하는 BIB 자체가 기본 블록까지 무결성 범위에 포함해야 한다. 별개로 검증된 진짜 블록 두 개를 조립했다고 같은 Bundle이었다는 증거가 생기지는 않는다.

누가 서명했는지는 맞다. 무엇에 서명할 권한이 있었는지가 틀렸다

단절을 견디는 네트워크에서는 Bundle이 여러 중계 노드를 지나간다. 중계 노드에도 정당한 키가 있고, 맡은 구간에 보안 처리를 더할 권한이 있을 수 있다. 문제는 그 노드가 원래 발신자의 보호를 걷어내고 페이로드를 바꾼 뒤 자기 키로 새 Block Integrity Block, 즉 BIB를 만들 때 드러난다. 수신자가 “합법적 참여자의 서명인가”만 확인하면 검증은 성공할 수 있다. 하지만 원래 발신자가 보낸 내용은 이미 사라졌다.

RFC 9172의 8.2.2절은 정당한 노드에 의한 이런 대체를 다룬다. 명세는 한 Bundle에 여러 보안 출처가 관여할 수 있게 하고, 어느 출처를 신뢰할지는 배치 환경의 정책에 맡긴다. 원래의 BIB를 Block Confidentiality Block, 즉 BCB로 감싸는 방법도 제시한다. 그러나 수신자가 바깥 BCB를 “허가된 출처라면 누구나” 제공할 수 있다고 판단하면, 다른 합법적 노드가 내용을 다시 포장할 수 있다. 암호 계산은 옳다. 그 결과에 붙인 권한 해석이 틀렸다.

N. D. S. Gupthaa의 초안은 수신자의 기준을 좁힌다. 대상 블록에 필요한 각 보안 서비스에 대해 어느 Security Source가 권한자인지, 어떤 키 자료가 그 출처에 묶여 있는지를 로컬 정책에 기록한다. 도착한 BIB나 BCB는 그 미리 지정한 키로 검증될 때에만 요구 사항을 충족한다. 다른 노드가 네트워크의 성실한 일원이라는 사실은 원 발신자의 자리를 넘겨주지 않는다.

IETF Datatracker는 이 문서를 RFC 경로가 없는 00판 개인 Internet-Draft로 표시한다. IETF의 공식 승인을 받은 표준도, 특정 운영망에서 작동했다는 보고서도 아니다.

신뢰 명단만으로는 직무표가 되지 않는다

초안의 R1은 서비스와 블록마다 예상 출처 및 키를 정하도록 한다. R2는 다른 출처의 유효한 보안 블록을 대체 증거로 인정하지 않는다. R3는 맞는 블록이 없으면 필수 서비스를 실패로 처리한다. R4는 권한의 옆자리 이동을 막는다. 게이트웨이가 한 목적을 위해 다시 보안 처리를 할 수 있다는 허가는 다른 발신자의 데이터에 대한 포괄적인 대표권이 아니다.

운영 현장에서는 한 노드를 통째로 “신뢰”한다고 부르기 쉽다. 하지만 전달을 맡기는 일, 특정 구간에서 암호화하는 일, 어떤 발신자를 대신해 무결성을 증명하는 일은 서로 다른 직무다. 좋은 키의 명단은 직원 명단과 비슷하다. 누가 회사에 있는지는 보여줘도 누가 어느 계약에 서명할 수 있는지는 말해주지 않는다.

수신한 블록 안의 Security Source 필드 역시 스스로 권한을 만들 수 없다. 초안은 이를 신뢰할 수 없는 검색 단서로 본다. 블록이 주장하는 출처를 읽은 다음, 수신자가 이미 갖고 있던 정책의 예상 출처와 대조해야 한다. 들어온 데이터가 자신을 심사할 규칙까지 고르게 하면 검증은 자기 추천서 확인에 그친다.

출처마다 다른 키가 있어야 이 구분도 작동한다. RFC 9172는 모든 노드가 하나의 키를 공유하면 그 키를 가진 합법적 노드 모두가 사실상 특권을 가진다고 설명한다. 키 관리 단계에서 출처를 섞어 놓고 수신 정책만 정교하게 써 봐야 실제 서명자를 되찾을 수 없다.

진짜 문서 두 장이 하나의 진짜 계약은 아니다

R5는 또 다른 조립 문제를 다룬다. 하나의 BIB가 페이로드를 보호하고, 별도의 BIB가 기본 블록을 보호할 수 있다. 두 검증이 모두 성공하고 같은 발신자가 만든 블록일 수도 있다. 그래도 서로 다른 Bundle에서 한 장씩 가져온 것이라면 둘 사이의 연결은 입증되지 않았다.

초안은 페이로드 자체의 BIB가 기본 블록을 무결성 계산 범위에 넣으라고 요구한다. RFC 9173의 3.3.3절은 그 범위를 지정하는 bit 0을 정의하며, 매개변수를 생략했을 때의 기본값 7에도 그 비트가 포함된다. 기본 블록에 BIB를 따로 붙이는 방식으로는 공동 보호를 대체할 수 없다. RFC 9171에 따르면 기본 블록은 Bundle의 식별과 처리 정보를, 페이로드 블록은 애플리케이션 데이터를 담는다. 수신자가 확인해야 할 것은 바로 그 정보와 그 데이터가 같은 보호 계산 안에 함께 있었다는 사실이다.

초록색 체크 표시의 빈칸

초안은 Tamarin 형식 모델과 설정 검사기를 언급하지만, 관련 산출물은 추후 공개 예정이고 현재는 요청 시 제공된다고 적는다. 공개 본문만으로 모델을 재현하거나 실제 배치의 방어 결과를 확인할 수 없다. 수신 설정과 재현 가능한 바꿔치기 기록이 공개되면 운영상 효과를 더 분명히 검증할 수 있다.

지금도 수신 시스템에 물어야 할 질문은 명확하다. 어느 서비스가 어느 블록에 필요했는가. 예상 출처와 키는 무엇이었는가. 페이로드의 BIB가 기본 블록까지 실제로 보호했는가. 이 질문을 지운 채 “서명 유효”만 띄우면 바뀐 택배 상자의 도장만 감탄하는 셈이다.

출처