요약

  • RFC 3394는 별도의 무결성 레지스터를 여섯 번의 패스에 걸쳐 섞어 넣으면서n개의 64비트 키 데이터 블록을n+1개의 암호문 블록으로 감쌌다. 맨 앞의 추가 블록은 수동적인 패딩이 아니라 변형된 상태였다.
  • 언랩은 복구된 레지스터가 기대한 초기값과 일치할 때에만 키 데이터를 반환할 수 있었다. 이 영수증은 암호학적 패키지를 검사했지만, 발신자를 식별하거나 권한이나 보관을 증명하거나, 신선함을 제공하거나, 배출된 키가 나중에 실제로 동작했는지를 보여주지는 못했다.

꾸러미는 포장할 때 커진다. 그 추가 공간은 보통 포장재처럼 보인다. 모양을 잡아주는 데는 유용하지만 정체와는 무관하다는 식이다. RFC 3394는 자신의 추가 블록에게 더 의미심장한 일을 맡겼다. 그 블록은 화물과 함께 장치를 통과해 나아갔고, 출구에서 그것을 배출하기 위한 조건으로 서게 되었다.

2002년 9월 Informational RFC로 발표된 이 문서는 NIST 사양에서 온 AES Key Wrap 알고리즘을 인터넷 표준 기록으로 옮겼다. 출처에 대해 특이할 만큼 솔직했다. 본문 대부분은 NIST 작업에서 왔으며, 보안 주장은 RFC 저자들에게 귀속되지 않고 미국 정부에 귀속되었다. 이 문서는 독립적인 암호학적 발견의 주장이 아니라 재현 가능한 변환을 제공했다.

“키 데이터”라고 불린 입력은 하나의 AES 키보다 넓은 개념이었다. 하나의 키, 여러 개의 키 또는 연관 정보를 담을 수 있었다. 키 암호화 키, 즉 KEK는 어떤 AES 키 크기든 사용할 수 있었다. 128, 192 또는 256비트였다. 보호할 데이터는 64비트 블록n개로 나뉘었고,n은 최소 2였다. 출력에는 그런 블록이n+1개 담겼다.

그 팽창은 상태 설계에서 비롯되었다. 평문 블록은R[1]부터R[n]까지의 레지스터로 들어갔다. 별도의 64비트 레지스터A는 초기값으로 시작했다. 알고리즘은R배열을 여섯 번 훑었고, 총6n번의 AES 연산을 수행했다. 각 단계에서A와 하나의R블록을 이어붙인 128비트 값을 암호화했다. 하위 절반이 그 데이터 레지스터를 대체했다. 상위 절반은 단계 카운터t와 XOR되어 새로운A가 되었다.

마지막 패스 이후 최종A가 암호문 블록C[0]가 되었고, 변형된R레지스터들이 뒤를 따랐다. 따라서 맨 앞 블록은 길이를 맞추려고 암호화 뒤에 덧붙인 바이트가 아니었다. 그것은 모든 데이터 블록과 모든 카운터 위치와 섞여 있었다. 감싸진 블록을 바꾸거나, 잘못된 KEK를 쓰거나, 다른 초기값 계약을 고르거나, 순서를 어지럽히면 역변환은 기대한 시작 상태를 복구하지 못하고 실패해야 했다.

언랩은 변환을 거꾸로 실행했다.C[0]를A에 넣고 카운터와 AES 연산을 역순으로 돌려 후보 평문 레지스터들을 만들었다. 그 후보들은 아직 호출자가 받을 자격이 있는 키가 아니었다. 구현은 먼저 복구된A를 적절한 초기값과 비교했다. 일치하면R값들이 경계를 넘을 수 있었다. 불일치하면 오류가 요구되었고, RFC의 필수 언어에 따라 어떤 키 데이터도 반환될 수 없었다.

기본 초기값은 16진수 바이트A6가 64비트 전체를 채우도록 반복된 값이었다. RFC 3394는 언랩이 그 값을 산출하면 손상된 키 데이터일 확률이2^-64라고 말했고, 다른 값은 반드시 거부해야 한다고 명시했다. 이 수치는 변환의 보안 가정 아래에서 무결성 검사를 설명한 것이었다. 관측된 사건 빈도도, 발신자 신뢰도도, 그것을 둘러싼 래핑 시스템이 안전하게 구현되었다는 증명도 아니었다.

이 구분이 중요한 이유는 수용이 아주 좁은 질문에 답하기 때문이다. 수용은 암호문, KEK, 알고리즘, 기대한 초기값이 명시된 암호학적 강도 범위에서 서로 일치했음을 말할 뿐이다. 대칭 KEK를 쓰는 한, 어떤 사람이나 프로세스가 그 암호문을 만들었는지 식별하지 못한다. 래핑이 승인되었는지, 패키지가 재생(replay)된 것이 아니라 신선한지, KEK가 한 번도 복사되지 않았는지, 복구된 바이트가 다음 구성요소가 기대하는 알고리즘과 용도에 속하는지도 보여주지 못한다.

RFC 3394 자체가 레지스터 밖의 가장 큰 권한인 KEK 보관에 대해 경고했다. KEK가 유출되면 그것으로 보호되던 모든 항목이 드러날 수 있었다.A검사는 KEK가 비밀로 유지되었다고 증언할 수 없는데, 같은 유출된 키가 완벽히 정상적인 랩을 만들어낼 수 있기 때문이다. 성공한 테스트 벡터가 부채널 저항성, 격리, 오류 균일성, 운영 환경의 키 처리를 증명할 수도 없다. 벡터는 그 사례에 대해 명세된 바이트 변환을 증명할 뿐이다.

입력 경계 역시 의도적이었다. 원래 구성은 최소 두 개의 64비트 데이터 블록을 요구했고, 64비트 배수인 길이만 받아들였다. 문서는 키 관리 시스템이 다른 무결성 범위와 다른 길이를 필요로 할 수 있음을 예상해 대안 초기값을 위한 공간을 남겨 두었다. 범용 구현은 그 값들이 설정되고 검사되는 방식에 유연할 것으로 기대되었다.

RFC 5649는 나중에 그 기존 경계를 없던 것처럼 꾸미는 대신 그 여지를 활용했다. AES Key Wrap with Padding은 1옥텟부터 데이터를 받아들였다. 그 대안 초기값은 32비트 상수와 32비트 메시지 길이 표시를 결합했다. 언랩은 상수를 검사했고, 길이가 패딩된 블록 수에 대해 타당한지, 패딩 옥텟이 0인지를 확인했다. 짧은 입력을 위한 특별한 단일 블록 사례도 있었다. 후대의 설계는 주장을 바꾸었기 때문에 영수증도 바꾼 것이다.

이 진화는A가 마법의 상수가 아니라 아키텍처적 표면이었던 이유를 보여준다. 원래 형태에서 그것은 사실상 “고정 길이 블록 열이 선택된 KEK 아래에서 래핑을 살아남았다”라고 말했다. 패딩 형태에서는 길이 주장까지 함께 운반했다. 서로 다른 초기값 구조는 서로 다른 응용 계약을 지원할 수 있었다. 그 전부를 호환 가능한 “AES wrap”으로 취급하면 레지스터가 보존하도록 설계된 바로 그 증거가 지워져 버린다.

후대 프로토콜들은 자신들의 명명 계층을 더했다. RFC 3565는 CMS에서 AES 키 래핑 식별자를 배정했다. JOSE와 COSE는 결국 웹과 CBOR 컨테이너에서 AES-KW 알고리즘 계열을 정의했다. 이 식별자들은 파서에게 프로토콜 안에서 어떤 변환과 키 크기를 호출할지 알려준다. 그것들이 핵심 레지스터를 신원 시스템으로 확장하거나 구형 변형과 패딩 변형을 호환 가능하게 만들지는 않는다.

정정 기록(errata)은 안정된 메커니즘과 그 인쇄된 표기 사이의 차이를 강화한다. 검증된 정정은 문구와 배열 첨자를 고친다. 보류 항목은 색인과 죽은 역사 링크를 명확히 한다. 이것들은 충실한 구현과 인용에 중요하지만, 여섯 번의 패스를 다른 알고리즘으로 바꾸거나 배출 경계를 옮기지는 않는다. 정정된 기록을 읽는 것은 같은 변환을 재현하는 과정의 일부다.

Lu Heng의 최소 초기 명세(Minimum Initial Specification) 원칙은 이 절약을 설명해 준다. RFC 3394는 독립 구현들이 같은 보호 시퀀스를 만들고 되돌리는 데 필요한 최소 장치를 고정했다. 블록 크기, 상태, 카운터, 패스, 초기값 검사, 실패 규칙이 그것이다. 그리고 키 보관, 권한 부여, 프로토콜 결합은 실제로 그 권한을 쥐고 있는 시스템들에 맡겼다.

Running-Code Primacy가 마지막 부담을 제공한다. 등록된 알고리즘과 통과하는 예제는 배포된 구현이 실패 시 평문을 쥐고 있지 않는지, KEK를 보호하는지, 누출을 피하는지, 결과를 의도한 용도에 결합하는지 증명할 수 없다. 그 주장들은 동작 중인 시스템에 대한 관찰을 필요로 한다. 표준은 기대되는 영수증을 정확히 만들며, 운영이 그 영수증이 실제 관문을 지배한다는 것을 증명해야 한다.

RFC 3394의 추가 레지스터는 오버헤드로 오해되기에 충분히 작았다. 그러나 실제로는 후보 바이트와 배출된 키 사이의 차이를 운반했다. 그럼에도 그 권한은 그 경계에서 끝났다. 암호학적 패키지가 기대한 모양으로 돌아왔다고 말할 수는 있었다. 누가 그 내용물을 받을 자격이 있는지, 래핑 키가 여전히 신뢰할 수 있는지, 관문이 열린 뒤 무슨 일이 벌어졌는지는 말할 수 없었다.

출처