기술 요약: 암호학적 레지스트리 출처

1. 문제 제기

이 논문은 현대 소프트웨어 배포 생태계의 치명적인 구조적 결함인 **의존성 혼란 (Dependency Confusion)**을 식별합니다. 기존 방어 수단 (예: .npmrc 매핑, GOPROXY 변수 등) 은 구성 계층에서 작동하지만, 잘못 구성되거나 CI/CD 변수에 의해 재정의되거나 부재일 경우 침묵하며 실패합니다. 한 번 패키지가 설치되면, 어떤 레지스트리가 이를 배포했는지에 대한 암호학적 증명이 존재하지 않습니다.

핵심 취약점은 패키지 해결사 (resolver) 가 여러 레지스트리 (공용 및 전용) 를 쿼리하고 버전 번호에 따라 아티팩트를 선택한다는 점입니다. 공격자는 피해 조직이 전용으로 사용하는 네임스페이스 하에 공용 레지스트리에 더 높은 버전 번호를 가진 악성 패키지를 게시할 수 있습니다. 아티팩트 자체가 배포 경로의 증거를 담고 있지 않기 때문에, 해결사는 합법적인 전용 아티팩트 대신 공격자의 아티팩트를 침묵하며 선택할 수 있습니다. 현재 생태계는 배포 경로를 암호학적으로 검증하거나 아티팩트 수준에서 네임스페이스 권한을 강제하는 메커니즘이 부족합니다.

2. 방법론 및 아키텍처

저자들은 구성에서 아티팩트 자체로 방어를 전환하는 암호학적 배포 출처 시스템을 제안합니다. 이 시스템은 세 가지 핵심 구성 요소에 의존합니다:

A. 2 계층 아카이브 형식

효율적인 검증을 위해 시스템은 특정 아카이브 구조를 도입합니다:

• 외부 포장 (비압축 Tar): 출처 매니페스트, 발행자 서명, 레지스트리 인증서 및 체크섬을 포함합니다. 이를 통해 소스 코드를 압축 해제하지 않고도 검증을 수행할 수 있습니다.
• 내부 콘텐츠 (Gzipped Tar): 실제 소스 파일, 프로젝트 매니페스트 및 타입 정의를 포함합니다.
• 이점: 검증 비용은 잠재적으로 큰 소스 아카이브가 아닌 작은 포장 (~2–5 KB) 에 비례합니다.

B. 암호학적 레지스트리 신원

모든 레지스트리 인스턴스 (공용, 전용 또는 스코프 지정) 는 고유한 Ed25519 키 쌍을 할당받습니다.

• 레지스트리는 잘 알려진 엔드포인트 (/.well-known/package-registry.json) 에서 자신의 신원 (URL, 공개 키, 지문 및 주장하는 네임스페이스) 을 게시합니다.
• 키 지문 ($F_R = \text{SHA-256}(\text{공개 키})$) 은 짧고 검증 가능한 식별자 역할을 합니다.
• 레지스트리는 자신이 권한을 가진 네임스페이스를 선언하여 위계적 신뢰 (예: 공용 $\to$ 조직 $\to$ 팀) 를 가능하게 합니다.

C. 이중 서명 배포 모델

아티팩트는 서로 다른 시간적 및 논리적 주장을 가진 두 개의 독립적인 서명을 포함합니다:

1. 발행자 서명 ($\sigma_P$): 패키징 시점 ($t_1$) 에 생성됩니다. 발행자는 출처 매니페스트에 서명하여 저자성과 콘텐츠 무결성을 주장합니다.
2. 레지스트리 인증서 ($\sigma_R$): 게시 시점 ($t_2 > t_1$) 에 생성됩니다. 레지스트리는 발행자의 서명을 검증하고 콘텐츠 해시를 확인한 후 인증서 문서에 서명합니다. 이는 레지스트리가 아티팩트를 수신, 검증 및 배포했음을 주장합니다.

• 반서명 (Countersigning) 의미: 이 접근 방식은 사건을 혼동하는 공동 서명과 달리 시간적 순서와 독립적인 주장을 유지합니다.

D. 권한 있는 네임스페이스 바인딩

소비자는 프로젝트 매니페스트 (예: mashin.toml) 에서 특정 네임스페이스에 대해 어떤 레지스트리가 권한을 가지는지 선언합니다.

• 고정 (Pinning): 소비자는 레지스트리의 키 지문을 고정합니다 (첫 사용 시 신뢰 - TOFU).
• 강제: 해결사는 권한이 없는 레지스트리의 아티팩트를 암호학적으로 거부합니다. 네임스페이스가 특정 레지스트리에 바인딩된 경우, 해결사는 해당 레지스트리만 쿼리하고 다른 레지스트리의 아티팩트를 (버전 번호가 더 높더라도) 거부합니다.

3. 주요 기여

이 논문은 다음과 같은 7 가지 구체적인 기여를 제시합니다:

1. 암호학적 레지스트리 신원: 모든 레지스트리가 Ed25519 키 쌍을 보유하고 모든 아티팩트에 서명하여 배포 경로의 아티팩트 수준 증명을 확립합니다.
2. 이중 서명 모델: 발행자가 패키징 시 서명하고 레지스트리가 게시 시 반서명하는 배포 모델로, 시간적 순서를 유지합니다.
3. 권한 있는 네임스페이스 바인딩: 소비자가 레지스트리 지문을 고정하고 권한이 없는 레지스트리의 아티팩트를 암호학적으로 거부할 수 있는 메커니즘입니다.
4. 2 계층 아카이브 형식: 출처 포장과 소스 콘텐츠를 분리하여 빠르고 부분적인 검증을 가능하게 하는 구조입니다.
5. 6 단계 검증 체인: 파일 무결성 (1 단계) 에서 계보 출처 (6 단계) 에 이르는 점진적 검증 프로세스로, 1~5 단계가 핵심 기여입니다.
6. 체계적인 생태계 비교: npm, Cargo, Hex.pm, PyPI, Go, Docker/OCI, NuGet, Maven 등 8 대 생태계를 분석하여 기존 생태계 중 어느 곳도 의무적 발행자 서명, 암호학적 레지스트리 신원, 의무적 레지스트리 반서명, 그리고 소비자 측 암호학적 강제를 결합하지 않았음을 입증합니다.
7. 런타임 거버넌스 통합: 배포 출처가 3 계층 구조 거버넌스 아키텍처와 통합되어 정의, 배포, 기능, 실행의 4 단계 수명 주기 체인을 형성하는 사례 연구입니다.

4. 결과 및 평가

보안 분석

정의된 위협 모델 (공격자는 CI/CD 구성을 침해하거나 공용 레지스트리에 게시할 수 있지만 레지스트리 개인 키는 침해할 수 없음) 하에서, 이 시스템은 3 계층 방어를 제공합니다:

• 1 계층 (레지스트리): 네임스페이스 강제 기능을 통해 무단 게시를 방지합니다.
• 2 계층 (소비자): 권한 있는 바인딩을 통해 무단 레지스트리에서의 해결을 방지합니다.
• 3 계층 (아티팩트): 레지스트리 인증서 (서명 검증) 를 통해 1 계층과 2 계층이 우회되더라도 무단 레지스트리의 아티팩트 설치를 방지합니다.

이 논문은 성공적인 의존성 혼란 공격이 소비자의 해결사 구성과 대상 레지스트리의 개인 서명 키가 동시에 침해되어야만 가능함을 증명합니다. 엄격한 위협 모델 (키 침해 제외) 하에서 성공적인 공격의 확률은 0 입니다.

성능 평가

Apple M 시리즈 프로세서에서 측정된 결과:

• 검증 지연 시간: 4 개 머신 프로젝트의 엔드투엔드 검증은 기본 모드 (13 단계) 의 경우 1.18 ms(중앙값) 이고, 엄격 모드 (15 단계) 의 경우 1.61 ms입니다.
• 오버헤드: 암호학적 연산 (Ed25519 서명/검증, SHA-256) 은 무시할 수 수준 (마이크로초) 입니다. 지배적인 비용은 외부 포장의 tar 추출 (~259 µs) 입니다.
• 비교: 제안된 시스템은 15 단계에 대한 네트워크 호출을 피하기 때문에 기존 생태계 검증 (예: npm 감사 서명은 투명성 로그로의 네트워크 왕복으로 인해 종종 100500 ms 소요) 과 비슷하거나 더 빠릅니다.
• 저장 오버헤드: 출처 포장은 몇 킬로바이트의 고정 크기를 추가합니다. 작은 프로젝트의 경우 이는 높은 비율의 오버헤드 (예: 203 바이트 소스의 경우 2,659%) 이지만, 더 큰 프로젝트 (12 개 머신) 의 경우 약 300% 로 감소하여 소스 크기에 비해 무시할 수 있게 됩니다.

5. 중요성 및 주장

이 논문은 의존성 혼란은 구성 문제가 아닌 출처 문제라고 주장합니다.

• 구조적 방어: 침묵하며 실패하는 구성 기반 방어와 달리, 이 시스템은 아티팩트에 내장된 암호학적 증명을 제공합니다. 검증은 해결사의 구성 상태와 무관하게 가능합니다.
• 독창성: 이 시스템은 의무적 발행자 서명, 암호학적 레지스트리 신원, 의무적 레지스트리 반서명, 그리고 소비자 측 암호학적 강제를 결합한 최초의 시스템입니다.
• 확장성: 아키텍처는 AI 생성 출처(모델 사용 및 구성 수준을 서명된 속성으로 추적) 와 거버넌스 강제 의존성 해결(사후가 아닌 설치 중 신뢰 계층 및 효과 권한을 강제) 로 확장됩니다.
• 완전성: 빌드 출처 및 런타임 거버넌스와 통합될 때, 이 시스템은 소스 코드 생성부터 실행까지의 연속적이고 변조가 드러나는 체인을 생성하여 소프트웨어 공급망의 암호학적 격차를 해소합니다.

저자들은 이 시스템이 타이포스쿼팅 (이름 계층 공격) 이나 레지스트리 서버 접근과 관련된 내부자 위협 (키 침해) 을 다루지 않는다고 지적하며, 이는 HSM 및 행동 분석과 같은 직교적 방어가 필요하다고 덧붙였습니다.