같은 IPv6 /64에 열쇠가 두 개라면, 입장 기록이 주인을 정한다

요약

• HCGA 개인 초안은 운영자가 관리하는 묶음 접두사와 /64 사이의 서브넷 비트를 공개키로 계산한다. RFC 3972가 다루는 인터페이스 식별자보다 위쪽까지 키의 영역을 넓힌다.
• /48 아래에서는 그 비트가 16개다. 다른 키도 약 2^16번 시도하면 같은 /64에 도달할 수 있어, 운영자는 독점 승인과 패킷 출처 통제를 기록해야 한다.

열쇠 두 개가 같은 문에 맞는다. 그렇다면 문패에 적힌 주소만 보고 거주자를 정할 수 있을까. Hierarchical Cryptographically Generated Addresses 초안이 맞닥뜨린 문제다. 제안은 여러 입주자가 쓰는 네트워크에서 작업 단위나 에이전트의 공개키에 IPv6 /64를 연결한다. 계산은 연결을 확인하지만, 누구에게 먼저 방을 내줬는지는 운영 기록이 말해준다.

기존 RFC 3972는 공개키에서 IPv6 주소 하단의 인터페이스 식별자를 만들고, /64 접두사는 네트워크가 제공한다. HCGA는 운영자 소유의 묶음 접두사부터 /64 경계까지의 서브넷 비트도 키와 접두사 수정값으로 유도한다. 나중에 검증하려면 공개키, 수정값들, 생성 당시 충돌 횟수가 필요하다. 이 값들을 남겨 두는 주체가 있어야 계산을 되짚을 수 있다.

초안의 보안 절은 숫자를 분명히 쓴다. /48 묶음 접두사 아래에서 /64까지는 16비트다. 다른 키나 수정값을 시험하면 대략 2^16번에 같은 서브넷 비트를 찾을 수 있다. 이는 서브넷 충돌 횟수다. IPv6 전체 128비트나 개인키를 그 횟수로 위조한다는 뜻은 아니다. 하단 인터페이스 식별자에는 별도의 훨씬 큰 해시 출력 한계가 있다. 그래도 /64 하나만으로 단 하나의 키를 지목할 수는 없다.

그래서 초안은 주변 시스템에 /64별로 어떤 키와 수정값을 승인했는지 기록하고, 다른 후보의 입장을 막으라고 요구한다. 패킷에 주소가 찍혔다는 사실만으로 발신자가 증명되는 것도 아니다. 대응하는 개인키 서명이나 네트워크의 출발지 주소 통제가 붙어야 한다. 로컬 링크 밖에 있는 검증자는 생성 매개변수를 받아야 한다. 기록이 사라지면 주소 계산만으로 승인된 주인을 복원할 길이 끊긴다.

라우팅 증거는 범위가 다르다. 운영자는 묶음 접두사를 BGP로 알리고 RPKI ROA로 그 기원 권한을 뒷받침한다. 내부 /64 경로는 외부에 알리지 않는다. 묶음 접두사에 유효한 ROA가 있더라도 내부 /64에 어떤 작업 단위의 키가 승인됐는지는 알 수 없다. 그 좁은 권한은 현지 승인 절차가 쥐고 있다.

승인이 제대로 이뤄져도 대가는 남는다. 초안대로라면 하단 인터페이스 식별자를 바꿔도 /64는 고정되어 활동을 이어 붙이기 쉬워진다. RFC 8981의 임시 IPv6 주소는 다른 개인정보 보호 목표를 가진다. HCGA 계산은 키가 하드웨어로 보호되는지 소프트웨어에만 있는지도 판별하지 못한다. RFC 9334는 별도의 증명 체계를 제공한다.

IETF Datatracker에는 10월 27일자 개인 제출 Standards Track 초안이 ‘I-D Exists’로 올라 있다. 확인할 시험은 명료하다. 실험용 /48에서 16비트가 겹치는 두 키를 만들고 두 번째 키의 승인을 거절한 뒤, 원격 검증자에게 첫 키와 생성 매개변수, 패킷 출처 증거를 재구성하게 한다. 주소의 계산값만큼 승인 장부의 완전성도 시험대에 오른다.