요약

  • RFC 3185는 한 객체의 CMS 콘텐츠 암호화 키가 이후 객체들에 대한 키 암호화 자료를 공급하도록 허용하여 반복적인 비대칭 연산을 줄였지만, 첫 번째 봉투보다 오래 남는 상태를 만들어냈습니다.
  • MSG1이 수신자 집합 S1에 도달했고 MSG2가 그 중 일부만 명시적으로 표시했다면, S1의 모든 구성원은 여전히 MSG2에 필요한 키를 도출할 수 있었습니다. 이후 목록에서의 생략은 이미 전달된 권한의 철회가 아니었습니다.

첫 번째 암호화 객체를 MSG1이라고 부르겠습니다. 이 객체는 다섯 명의 수신자에게 전달됩니다. 이후 MSG2는 두 명에게 전달됩니다. MSG2를 검사하는 관찰자는 나머지 세 명이 제외되었다고 추론할 수 있습니다. RFC 3185는 이 추론이 안전하지 않다고 경고합니다. MSG2의 키 암호화 키가 MSG1의 콘텐츠 암호화 키에서 도출되었을 때, 기존 키를 보유한 다섯 명 모두 여전히 새 콘텐츠 키를 얻을 수 있습니다.

이 경계는 2001년 10월에 발표된 간결한 표준 트랙 문서인CMS 콘텐츠 암호화 키의 재사용(Reuse of CMS Content Encryption Keys)안에 담겨 있었습니다. RFC Editor는 이 문서를 제안 표준(Proposed Standard)으로 분류합니다. 그 목적은 효율성이었습니다. CMSEnvelopedData는 대칭 또는 비대칭 키 관리를 통한 대칭 콘텐츠 암호화를 지원했으며, 비대칭 키 설정은 비용이 클 수 있었습니다. 클라이언트가 하나의 트랜잭션에서 여러 필드를 각각 암호화하거나, 두 서버가 보호된 객체를 자주 교환할 수 있습니다. 이미 확립된 대칭 자료를 재사용하면 비용이 큰 작업의 반복을 피할 수 있습니다.

이 RFC는 범용 세션 프로토콜을 기술하지 않았습니다. 자신의 메커니즘을 더 큰 맥락을 필요로 하는 “트릭”이라고 불렀습니다. 그 맥락은 저장된 키 상태가 손실되었을 때 어떤 일이 발생하는지 결정해야 했습니다. 암호화 API는 필요한 키 자료를 노출하거나 변환할 수 있어야 했습니다. 콘텐츠 암호화 알고리즘과 키 암호화 알고리즘은 호환되는 키 형식과 강도를 수용해야 했습니다. 이 설계는 명시적으로 범용 그룹 키 관리가 아니었습니다.

그 기본 동작은 두 표현을 연결했습니다. MSG1은 보호되지 않은CEKReference속성, 즉 MSG1에서 사용된 콘텐츠 암호화 키의 식별자를 실었습니다. MSG2는 같은 값을 자신의KEKIdentifier로 사용했습니다. 참조 값 자체는 비밀이 아니었습니다. 참조는 수신자가 MSG1에서 이미 보유하고 있는 비밀 CEK를 찾아, MSG2의 새 CEK를 풀기 위해 필요한 키 암호화 키(KEK)를 도출하도록 해주었습니다.

키 형식이 일치할 때 도출은 바이트 역순 변환이었습니다. RFC 3185는 이 연산을 현대적 범용 키 도출 권고로 선택한 것이 아니었습니다. 특정한 기지평문과 암호문 블록이 MSG2의 암호화된 키 자료로 직접 사용되는 것을 막기 위해 선택한 것입니다. 알고리즘이 다른 키 길이나 형식을 요구할 때, 선택적 속성이 이전 CEK를 암호가 아닌 입력으로 사용하는 PBKDF2 도출을 명시할 수 있었습니다. 이 2001년의 알고리즘 선택은 그 시대의 맥락에 속합니다. 이후의 CMS, PBKDF2, 키 랩 RFC들이 이를 무단으로 다시 쓰지 않습니다.

이 메커니즘은 메시지를 미래 권한의 원천으로 만들었습니다. MSG1을 정당하게 수신하고 그 CEK를 보유한 사람은 누구나 도출 체인에 참여할 수 있게 되었습니다. 이후 발신자가 MSG2의 수신자 필드를 변경할 수 있지만, 그 필드는 이전 보유 사실을 지우지 않습니다. 실제 복호화 가능 인구는 최신 봉투만이 아니라 키 전달 이력과 보유 상태로 결정되었습니다.

이것이 본 기사의 용어인수신자 집합 지속성(recipient-set persistence)입니다. 선언된 집합이 축소되더라도 유효 집합은 이전 객체로부터 구성원을 상속할 수 있습니다. 이는 RFC 용어가 아니며, 모든 CMS 교환에 대한 주장도 아닙니다. RFC 3185에서 명시된 S1/부분집합 결과를 기술합니다. 참조된 CEK가 없는 구성원은 참조 값을 안다고 해서 접근 권한을 얻지 못합니다.

이 구분은 완전한 철회 프로토콜은 아니면서 철회와 비슷합니다. 새 표현에서 이름을 제거하는 것은 발신자가 지금 무엇을 선언하는지에 대한 결정입니다. 이전에 전달된 암호화 능력을 철회하려면, 그 보유자를 도출에서 배제하는 새 키 자료와 기존 능력이 더 이상 수용되지 않는다는 증거가 필요합니다. 이 RFC의 재사용 경로는 효율성을 위해 정반대로 기존 보유에 의존했습니다.

CEKMaxDecrypts는 수명 힌트를 추가했습니다. 발신자는 이후 몇 개의 암호문이 참조된 CEK를 재사용할지 선언할 수 있었습니다. 발신자는 그 수를 준수해야 했고, 수신자는 이를 힌트로 취급하여 더 많은 메시지를 기대하면서 참조와 CEK를 보유하고, 로컬 시간 한도 이후에 상태를 삭제했습니다. 속성이 없으면 당사자들은 한 번의 재사용이 계획된 것처럼 행동했습니다.

그 수는 원격 삭제기가 아니었습니다. 모든 수신자가 같은 성공 메시지 수를 세었다는 것, 한도 이후 모든 복사본이 삭제되었다는 것, 저장소가 소거되었다는 것, 오프라인 보유자가 CEK를 잊었다는 것을 증명하지 못했습니다. 매우 큰 값이나 약속되었으나 도착하지 않는 암호문은 수신자가 상태를 보유하고 메모리를 소비하게 만들 수 있었습니다. 따라서 RFC 3185는 수신자에게 로컬 크기 및 시간 한도를 부과하는 일을 남겼습니다.

보안 절은 제품 언어가 자주 잃어버리는 두 가지 경계를 더 그렸습니다. 암호화는 발신자를 인증하지 않았습니다. 누구나 알려진 참조 값을 포함하는EnvelopedData객체를 만들 수 있었고,CEKReference의 인식은 객체를 보낸 사람이 누구인지, 발신자가 진짜인지를 증명하지 못했습니다. 올바른 참조 사용도 재전송(replay)이나 삽입을 막지 못했습니다. 별도의 인증, 무결성, 순서 및 신선도 증거가 여전히 필요했습니다.

성공적인 복호화도 마찬가지로 경계를 가졌습니다. 그것은 수신자가 실제 수행된 검사 하에서 수용 가능한 평문을 산출하는 키 자료와 매개변수를 찾았음을 보였습니다. 메시지가 신선한지, 승인된 것인지, 의도된 모든 수신자에게 전달되었는지, 생략된 수신자에게 접근 불가능한지, 복호화 후 안전하게 처리되는지, 응용 프로그램에 수용되는지를 증명하지 않았습니다.

기본인 한 단계 재사용은 롤링 체인을 형성할 수 있었습니다. MSG[n]은 MSG[n−1]의 CEK에서 도출된 KEK를 사용했으며, MSG[n]의 새로운 무작위 CEK는 MSG[n+1]의 기초가 될 수 있었습니다. RFC 3185는 예상치 못한 고정 키를 만들 수 있는 방식으로 메시지 CEK를 자신의 KEK에서 역으로 도출하는 것을 경고했습니다. 따라서 체인은 출처와 독립성을 모두 보존해야 했습니다. 어느 이전 CEK가 어느 이후 언랩을 승인했는지, 새 CEK가 실제로 신선한지 여부입니다.

실패에도 어휘가 필요했습니다. 지원되지 않는 도출 속성, 누락된 참조, 로컬 만료 상태, 호환되지 않는 알고리즘, 잘못된 키 자료, 변경된 매개변수는 모두 “복호화할 수 없음”으로 나타날 수 있었습니다. 이 RFC는 특정 이유를 호출 응용 프로그램에 신호하도록 권고했습니다. 그 구분이 없으면 운영자는 정책에 의한 축출을 손상으로, 지원되지 않는 기능을 공격으로 오해할 수 있었습니다.

RFC 3185의 역사적 교훈은 효율성이 실수였다는 것이 아닙니다. 암호학적 권한은 소프트웨어가 표시하는 최신 목록이 아니라 이미 배포된 자료를 따른다는 것입니다. 최신 CMS 객체는 하나의 표현입니다. 유효한 읽기 집합은 시간에 걸친 보유에 대한 주장입니다. 누가 MSG2를 읽을 수 있었는지 아려면 조사자는 MSG1의 전달 증거, 보유된 CEK 상태, 도출 매개변수, 로컬 만료 결정, 복호화 관찰이 필요하며, MSG2의 가시적 수신자 목록만으로는 부족합니다.