요약

  • RFC 3537은 HMAC 키 앞에 1옥텟 길이를 두고, 그 결과 레코드를 3DES 또는 AES 래핑 경로가 요구하는 블록 경계에 맞춰 패딩했습니다.
  • 유효한 언랩은 의도한 바이트를 반환할 수 있지만, 그 무결성 결과는 HMAC 알고리즘, 승인된 용도 또는 데이터 출처를 식별해 주지 않습니다.

CMSAuthenticatedData패키지를 여는 메일 게이트웨이를 상상해 보십시오. 하나의 키가 수신자를 위해 보호되어 있고, 수신자의 시스템이 그것을 언랩하여 정확한 바이트열을 복구하고 처리를 계속합니다. 봉투는 자신의 몫을 다 했습니다. 그러나 성공적인 언랩이 답한 것은 좁은 질문입니다. 이 표현이 해당 키 래핑 무결성 검사를 통과했는가? 그것 자체로는 답하지 않은 것들도 있습니다. 어떤 해시 함수가 이 바이트를 소비해야 하는가, 이 서비스가 그것을 사용할 수 있는가, 누구의 권한이 그것을 이 자리에 두었는가, 그리고 이 패키지가 현재 유효한 것인가.

이 구분이 RFC 3537의 역사적 기여입니다. 2003년 5월에 S/MIME 워킹 그룹의 Standards Track Proposed Standard로 발표된 이 문서는, 상속받은 구조에 맞지 않는 길이와 패리티 특성을 지닌 HMAC 키를 위해 기존의 3DES 및 AES 래핑 방식을 조정했습니다. 이 문서는 CMSAuthenticatedData를 응용 사례 중 하나로 명시했습니다. 그것은 키 전송 메커니즘이었지, 완전한 인가 또는 출처 형식이 아니었습니다.

바이트 수, 그다음 바이트

각 구조는LENGTH || KEY로 시작합니다.LENGTH는 1옥텟이며, 그 뒤에 그만큼의 옥텟으로 이루어진 키 재료가 옵니다. 래퍼는 레코드가 8바이트의 배수가 되도록 필요한 최소한의 무작위 패딩 옥텟을 추가합니다. 따라서 서론의 "임의 길이"는 키가 기존 랩 알고리즘의 고정 크기에 맞을 필요가 없다는 뜻이지, 길이 필드가 무제한이라는 뜻이 아닙니다. 이 RFC는 이를 최대 키 크기에 대한 응용 정책으로 제시하지 않습니다.

패딩은 자유롭게 붙는 주석이 아닙니다. 그것은 랩된 표현 안에 있으며, 적용되는 무결성 구조의 보호를 받습니다. 언랩 시 수신자는 먼저 인코딩된 객체의 무결성을 검사하고, 길이·키·나머지를 분리하며, 7옥텟을 초과하는 패딩은 거부합니다. 이를 통해 수신자는 키가 어디서 끝나는지 추측하지 않고도 바이트열을 복구할 수 있습니다. 그러나 무작위 패딩에는 의미 라벨이 없습니다. "이 테넌트의 감사 기록용 HMAC-SHA-256"이나 "이 로테이션까지 유효"라고 말할 수 없습니다.

상속된 두 보호 경로

RFC 3537은 하나의 공통 암호 변환을 발명하지 않았습니다. 3DES 경로는 RFC 3217의 래핑 구조를 따르고, 3DES 패리티 요건이 없는 키를 수용하며, 8옥텟 체크섬을 포함하고, 외부 고정 IV 단계 전에 무작위 초기화 벡터를 사용합니다. AES 경로는 RFC 3394 키 랩 알고리즘을 재사용하며, 래핑 전에 길이·패딩 레코드를 추가합니다. AES 무결성 값과 3DES 체크섬은 서로 바꿔 쓸 수 있는 세부 사항이 아닙니다. 각각은 자신의 구조에 따라 해석됩니다.

그렇기 때문에 RFC 3394의 추가 AES 레지스터는 별개의 이야기로 남습니다. RFC 3394는 변환 전반에 섞이고 후보 평문이 공개되기 전에 검사되는A값을 담당합니다. RFC 3537은 그 메커니즘을 둘러싼 HMAC 키 봉투, 즉 가변 길이 키가 어떻게 프레이밍되어 랩되고 복구될 수 있는지를 담당합니다. 앞선 RFC 3058 기사 역시 별개로 남습니다. 그것은 IDEA 래핑과 그 별도의 기능 및 체크섬 질문을 다룹니다. RFC 3217은 3DES 분기의 배경이지 이 글의 논지가 아닙니다.

알고리즘 식별자는 또 하나의 경계를 보여 줍니다. RFC 3537은 3DES와 AES를 사용한 HMAC 키 래핑에 OID를 할당하고NULL매개변수를 요구합니다. 이 이름들은 CMS를 이해하는 소비자에게 어떤 래핑 연산이 표현되어 있는지 알려 줍니다. 그것들은 나중에 복구된 키를 소비할 HMAC 다이제스트의 신원이 아닙니다. RFC 2104의 키 지침은 HMAC에 관한 것이고, RFC 3537의 OID는 봉투에 관한 것입니다. 후자를 전자로 취급하면 두 프로토콜 계층이 하나로 뭉개집니다.

무결성이 참인 동시에 출처는 알 수 없을 수 있다

보안 절은 KEK를 보호해야 한다고 말하며, KEK가 유출되면 그 아래 랩된 모든 HMAC 키가 노출될 수 있다고 경고합니다. 이어서 더 미묘한 한계를 밝힙니다. 랩 함수는 기밀성과 데이터 무결성을 제공하지만, 데이터 출처 인증을 반드시 제공하지는 않는다는 것입니다. KEK를 가진 누구든 무결성 검사를 통과하는 메시지를 만들 수 있습니다. 출처 인증이 필요하다면 KEK 배포 메커니즘이 그 출처를 인증하거나, 디지털 서명이 그 증거를 제공할 수 있습니다.

이것은 알고리즘이 자신에게 명시된 검사를 실패한다는 주장이 아닙니다. 그 검사들이 무엇을 증명하는가에 대한 진술입니다. 시스템이 "언랩 성공"을 "의도된 권한이 이 연산에 대해 이 키를 승인했다"로 취급한다면, 그 시스템은 그런 역할을 지니지 않은 영수증에 그 역할을 부여한 것입니다. 암호 객체는 잘 형성되고 온전할 수 있지만, 그 출처·목적·인가는 여전히 증명되지 않은 상태로 남습니다.

알고리즘이 아니라 기록에 대한 정정

RFC Editor Verified Erratum 254는 3DES 테스트 벡터의 한 값을 정정합니다.PAD줄은38be62가 아니라be62fe여야 합니다. 정정된 값은 다음LKEYPADICV줄에 표시된 바이트와 일치합니다. 이것은 공개된 벡터에 대한 편집적 수리이지, 래핑 절차의 변경도 배포된 암호 실패의 증거도 아닙니다.

더 넓은 교훈은 알고리즘보다 아키텍처에 관한 것입니다. 시스템은 복구 가능한 키가 필요하지만, 다이제스트·의도된 연산·주체·출처·유효 기간에 대해서는 별도로 인증된 증거가 필요합니다. 서명된 매니페스트나 프로토콜별 인증 컨텍스트가 그 결정들을 담을 수 있습니다. 키 랩 봉투에는 그것이 인코딩한 적 없는 필드의 공을 돌려서는 안 됩니다. RFC 3537은 유용한 전송 경계를 그렸습니다. 그 경계를 지키는 시스템은 감사 가능성을 유지합니다.

출처