기술 요약: 암호 민첩성을 위한 의도 기반 암호 API 설계

문제 정의

양자 내성 암호로 전환하는 조직들은 대규모의 복잡한 소프트웨어 포트폴리오 전반에서 암호 알고리즘을 업데이트해야 하는 중대한 엔지니어링 과제에 직면해 있다. 현재의 암호 API는 대부분 특정 알고리즘을 중심으로 설계되어 있어, 키 생성 및 운용 시점에 명시적인 알고리즘 선택을 요구한다. 이러한 설계는 애플리케이션 코드와 암호 구현 간의 밀접한 결합(tight coupling)을 초래한다. 동반 평가 프레임워크 [31]에서 언급된 바와 같이, 기존 시스템들(PKCS#11, OpenSSL 3.0, JCA, Google Tink, AWS KMS, HashiCorp Vault 포함)은 세 가지 결정적인 결함을 가지고 있다:

1. 의도 기반 키 생성의 부재: 시스템이 암호적 의도(예: "인증된 암호화")를 지정하는 대신 알고리즘별 식별자를 요구한다.
2. 암호 거버넌스의 부재: 시스템이 액세스 제어와 구별되는, 허용된 알고리즘 및 구성에 대한 정책을 강제할 수 있는 메커니즘이 부족하다.
3. 알고리즘 변환의 부재: 평가된 어떤 API도 키의 정체성을 유지하면서 사용된 알고리즘을 업데이트하는 명시적인 연산을 노출하지 않는다.

결과적으로, 양자 내성 알고리즘(NIST의 FIPS 203, 204, 205 등)으로 마이그레이션하는 것은 단순한 운영 절차가 아니라, 여러 파일에 걸친 코드 변경을 요구하는 거대한 소프트웨어 엔지니어링 프로젝트가 된다.

방법론

저자들은 다섯 가지 근본적인 아키텍처 특성인 **추상화(Abstraction), 안정성(Stability), 시간적 유연성(Temporal Flexibility), 분리(Separation), 확장성(Extensibility)**으로부터 도출된 설계 프레임워크를 제안한다. 이 속성들로부터, 그들은 암호 민첩성을 달로 하기 위해 필요한 13가지 설계 원칙(10개의 핵심 원칙과 3개의 지원 원칙)을 도출한다.

이 원칙들을 실현하기 위해, 본 논문은 Protocol Buffers와 gRPC를 사용한 구체적인 API 설계를 제시한다. 이 설계는 네 가지 아키텍처 추상화의 "바인딩 체인"에 의존한다:

1. 스코프(Scope): 호환 가능한 운영 인터페이스를 가진 알고리즘들을 그룹화하는 명명된 의도 범주 (예: 컨텍스트 파라미터를 요구하는 서명을 위한 sig_context).
2. 템플릿(Template): 등록된 라이프사이클 상태를 가진, 구체적인 알고리즘과 그 파라미터(예: 키 크기, 모드)를 정의하는 불변의 명명된 구성 (예: AES-GCM).
3. 정책(Policy): 특정 정책 언어를 규정하지 않으면서 스코프를 템플릿에 매핑하고 제약 조건을 강제하는 거버넌스 도구.
4. 프로바이더(Provider): 실행 백엔드 (예: HSM, 소프트웨어 라이브러리, 클라우드 KMS).

이 설계는 애플리케이션 로직을 암호 세부 사항으로부터 분리하기 위한 특정 메커니즘을 도입한다:

• 운영 파라미터 분류: 파라미터를 알고리즘 파라미터(템플릿에 결합됨), 시스템 생성 값(프로바이더가 관리함), 운영 파라미터(애플리케이션이 공급함)로 엄격히 분류한다. 이 분류는 특정 데이터를 처리하는 적절한 주체를 보장함으로써 API 오용을 방지한다.
• 이중 레지스트리 아키텍처: 정적 알고리즘 속성을 정의하는 템플릿 레지스트리와 동적 배포 구성을 정의하는 프로바이더 레지스트리를 둔다. 이 분리를 통해 실행 환경과 독립적으로 알고리즘을 선택할 수 있다.
• 키 진화 연산: API는 순환(Rotation)(새로운 재료, 동일한 알고리즘), 변환(Transformation)(새로운 알고리즘, 동일한 정체성), 마이그레이션(Migration)(새로운 프로바이더, 동일한 정체성)을 위한 명시적인 RPC를 정의한다. 이러한 연산은 데이터 연속성을 보장하기 위해 버전 이력을 보존한다.
• 정책 엔진 추상화: 정책은 이름으로 참조되며 키 생성 및 운 operation 시점에 모두 평가된다. 이를 통해 코드 변경 없이 정책 결정이 애플리케이션의 선택을 무효화(override)할 수 있도록 한다.

주요 기여

본 논문은 배포된 시스템에서 식별된 "민첩성 격차(Agility Gap)"를 해결하는 종합적인 API 설계를 기여한다. 주요 기여는 다음과 같다:

1. 의도 기반 어휘: 키 생성의 주요 메커즘으로서 **스코프(Scopes)**를 도입한다. 애플리케이션은 알고리즘(예: AES-GCM) 대신 의도(예: AEAD_WITH_AAD)를 지정한다. 정책 엔진은 이 의도를 구체적인 템플릿으로 해결하여, 애플리케이션을 알고리즘 정체성으로부터 분리한다.
2. 운영 파라미터 일관성: 입력 파라미터 요구사항에 따라 암호 프리미티브를 스코프로 세분화함으로써, 스코프 내에서의 알고리즘 교체가 애플리케이션의 호출 계약을 변경하지 않도록 보장한다.
3. 명시적 알고리즘 변환: TransformKey 연산은 키가 안정적인 식별자와 버전 이력을 유지하면서 새로운 알고리즘(예: ECDSA에서 ML-DSA로)으로 마이그레이션할 수 있게 한다. 이는 코드 수정 없이 역사적 데이터의 복호화/검증을 가능하게 한다.
4. 거버넌스 분리: 암호 거버넌스(정책 강제)를 액세스 제어와 분리한다. 보안 관리자가 정책을 관리하고 개발자가 암호 서비스를 소비하는 역할 기반 액세스 제어를 지원하며, 정책은 템플릿, 프로바이더 및 키 라이프사이클에 대한 제약을 강제할 수 있다.
5. 배포 불가지론(Deployment Agnosticism): 단독 실행(로컬 실행)부터 완전 중앙 집중형(원격 서비스)에 이르는 다섯 가지 배포 모드를 지원한다. 결정적으로, 인프라 구성만 변경될 뿐 애플리케이션 코드는 모든 모드에서 동일하게 유지된다.

결과 및 평가

제안된 API 설계는 동반 논문 [31]의 7가지 차원 평가 프레임워크를 기준으로 평가되었다. 설계는 다음 수준을 달성한다:

• C1.3 (스코프 일관적 연산): 연산이 균일하며 키는 알고리즘 정체성을 추상화한다.
• C2.2 (의도 기반 생성): 애플리케이션은 알고리즘이 아닌 스코프를 통해 의도를 지정한다.
• C3.3 (키 기반 프로바이더 선택): 프로바이더는 키 생성 시 바인딩되지만, 연산은 프로바이더에 독립적이다.
• C4.3 (정책 엔진): 정책은 스코프를 템플릿 및 프로바이더로 해결한다.
• C5.3–5.4 (스코프 기반/연합 거버넌스): 정책은 도메인별로 정의될 수 있으며 계층적이다.
• E1.3 (명시적 알고리즘 변환): 키 변환을 위한 전용 연산이 존재한다.
• E2.2 (명시적 마이그레이션 API): 마이그레이션을 위한 전용 연산이 존재한다.

평가는 이 설계가 식별된 세 가지 격차(의도 기반 생성, 암호 거버넌스, 알고리즘 변환)를 해소함을 확인한다. 저자들은 유연성을 유지하기 위해 설계가 최대 자율성(예: C1.4 또는 정책 기반 자동 변환)에는 미치지 못하며, 오케스트레이션을 외부 시스템에 남겨두었다고 언급한다.

의의

본 논문은 양자 내성 암호로의 전환이 암호학적인 문제라기보다 소프트웨어 엔지니어링 문제라고 주장한다. 알고리즘 선택과 마이그레이션의 부담을 애플리케이션 개발자로부터 암호 거버넌스 및 정책 엔진으로 전환함으로써, 제안된 API 설계는 전환 과정을 분산된 코드 재작성 작업에서 운영 절차로 변화시킨다.

그 의의는 애플리케이션 코드를 수정하지 않고도 정책 업데이트와 통제된 키 변환을 통해 조직 전체의 암호 체계를 업데이트할 수 있는 능력에 있다. 이러한 접근 방식은 전환 중에도 기존 데이터에 대한 접근성을 보장하며(버전 이력을 통해), 조직이 새로운 표준(NIST의 양자 내성 알고리즘 등)에 신속하고 안전하게 적응할 수 있도록 한다. 이 설계는 건축적 재설계 없이 시간이 지남에 따라 진화할 수 있는 암호 민첩한 시스템을 구축하려는 실무자들에게 재현 가능한 패턴을 제공한다.