요약

  • RFC 3961은 0이 아닌 키 사용 번호를 커버로스 암호화 및 체크섬 연산의 일부로 만들어, 하나의 기본 키가 메시지 유형과 프로토콜 역할을 가리지 않는 무차별적 기능이 되지 않도록 했습니다.
  • 단순화된 프로필에서 이 사용 번호는 별도의 체크섬, 암호화, 무결성 키를 도출하는 데 도움을 주었고, 유효한 결과는 사용자의 권한이나 애플리케이션의 최종 동작이 아니라 그 암호학적 맥락과의 일치를 입증했습니다.

같은 세션 키에서 만들어진 두 개의 봉인된 편지봉투를 상상해 보십시오. 하나는 요청을 인증하기 위한 것이고, 다른 하나는 응답을 보호하기 위한 것입니다. 암호가 '키와 바이트'만 본다면 두 작업의 구분은 암호학적 계산 바깥에 존재하게 됩니다. 한 지점에서 수락된 메시지가 같은 키를 공유하는 다른 지점에서 유용하게 쓰일 수 있습니다.

RFC 3961은 2005년 2월에 발표되며 이 작업 설명을 계산 안에 넣었습니다. 커버로스 사양은 각 연산에 키 사용 번호를 부여하게 됩니다. 암호화 및 체크섬 메커니즘은 그 번호를 입력으로 받게 됩니다. 이 번호는 공개되었고, 부호 없는 32비트였으며, 절대 0이 아니었습니다. 그 가치는 비밀이 아니라 맥락에 있었습니다.

이 조치는 더 큰 분리의 일부였습니다. 이 RFC는 다른 커버로스 문서가 지정하는 장기 키 또는 세션 키인 프로토콜 키와, 단일 암호학적 연산에 사용되는 구체적 재료를 구분했습니다. 다른 사양은 암호의 IV, 체크섬, 패딩 또는 파생 키 구조 내부를 들여다보지 않고도 '이 키와 이 사용 번호로 이 옥텟을 암호화하라'고 말할 수 있었습니다. 애플리케이션이 목적을 지정하고, 프로필이 그 목적이 암호학적 작업을 어떻게 바꾸는지 결정했습니다.

암호화 유형만으로는 완전한 답이 아니었다

이 RFC의 제목은 알고리즘 목록처럼 들리고 실제로 암호화 및 체크섬 유형 번호를 할당했습니다. 그러나 지속적인 기여는 하나의 계약이었습니다. 규격을 준수하는 암호화 프로필은 회선 키 형식, 문자 대 키 및 난수 대 키 함수, 파생, 암호 상태, 암호화, 무결성 동작, 의사난수 함수를 정의해야 했습니다. 체크섬 프로필은 어떤 키를 사용할 수 있는지, MIC 생성 및 검증이 어떻게 동작하는지 명시해야 했습니다. 문서는 필수 연산이나 속성이 하나라도 빠지면 메커니즘이 불완전하다고 경고했습니다.

이것이 중요한 이유는etype이 그러한 프로필의 식별자일 뿐이기 때문입니다.etype은 클라이언트가 프로필을 구현했다는 것, 서버가 이를 활성화했다는 것, KDC가 이를 선택했다는 것, 또는 그 결과 교환이 무엇인가를 승인했다는 것을 말해주지 않습니다. 현재IANA 커버로스 파라미터 레지스트리는 할당된 번호와 참조를 보존하고 있습니다. 이는 이름의 대장이지 배치 현황 지도가 아닙니다.

이 구분은RFC 4537에서 운영적으로 드러났습니다. 이 확장은 클라이언트가 암호화 유형을 선호 순서로 제시하고 서버가 로컬 정책에 따라 하나를 선택할 수 있게 했으며, 경우에 따라 새 서브키를 만들 수도 있었습니다. 할당된 유형, 제시된 유형, 선택된 유형은 서로 다른 세 개의 기록입니다. 협상으로 더 강한 유형이 선택되더라도 그 보호는 이전 세션 키에 의존했으므로, 약한 보호가 깨지면 더 강한 서브키도 노출될 수 있었습니다. '지원됨'이 '사용됨'은 아니었고, '사용됨'이 '모든 주변 조건에서 안전'은 아니었습니다.

다섯 바이트가 세 가지 다른 작업을 만들었다

RFC 3961의 단순화된 프로필은 이 분리를 구체적으로 구현했습니다. 이 프로필은 4바이트 사용 번호를 빅엔디안 순서로 인코딩하고 1바이트 상수를 추가했습니다. 같은 기본 키에서 독립 체크섬용Kc는usage | 0x99로, 암호화용Ke는usage | 0xAA로, 암호화된 메시지의 무결성 검사용Ki는usage | 0x55로 파생되었습니다.

결과는 단순히 세 개의 변수 이름이 아니었습니다. 기본 키는 파생 재료로만 쓰이도록 되어 있었습니다. 한 역할에서 유출된 파생 키는 다른 파생 키를 드러내서는 안 됐습니다. 특정 사용 번호 하에서 보호된 요청이 응답이나 다른 프로토콜 교환의 필드로 자동 유효해서는 안 됐습니다. 프로토콜의 의미론적 경계가 암호학적 경계의 입력이 된 것입니다.

RFC 3961은 과거의 실패 사례를 통해 이것이 왜 중요한지 설명했습니다. 일부 소프트웨어는 커버로스 버전 4와 버전 5에 같은 키를 사용했습니다. 버전 4는 버전 5를 공격하기 위한 암호화 오라클 역할을 할 수 있었습니다. 무작위 컨파운더는 예측 가능한 평문의 유용성을 줄였고, 목적별 파생은 하나의 키를 만능으로 취급하는 데서 오는 피해를 제한했습니다. 이 문서는 특정 사건을 보고하지 않았습니다. 이 프레임워크가 좁히기 위해 만들어진 공격 표면을 기술했을 뿐입니다.

검증은 여전히 로컬 영수증이었다

복호화 시 프로필은 무결성을 검증하고 검증에 실패하면 데이터를 폐기했습니다. 이는 의미 있는 결과이지만 커버로스 판단 전체는 아닙니다. 이는 암호문, 파생 키, 사용 맥락, 무결성 태그가 서로 일치한다는 것을 말합니다. 기본 키가 속한 주체를 독립적으로 식별하거나, 호출자가 프로토콜이 요구하는 사용 번호를 선택했음을 보이거나, 신선함을 입증하거나, 재생을 막거나, 애플리케이션 동작을 승인하거나, 서비스가 실제로 제공되었음을 확립하지는 않습니다.

이러한 조인은 프리미티브 위에 존재합니다.RFC 4120은 커버로스 V5 프로토콜, 티켓 및 인증자 의미론을 정의하며, RFC 3961이 암호학적 재료를 가져와 분리한 이전 문서인RFC 1510을 대체했습니다.RFC 6113은 나중에 이 프레임워크를 일반화된 사전 인증에 사용했습니다. 이 어떤 계층도 다음 계층의 판단을 없애지 않습니다.

따라서 깔끔한 감사 기록에는 '복호화 성공'보다 더 많은 내용이 들어갑니다. 메시지 유형, 선택된etype, 키 버전 또는 비밀이 아닌 키 참조, 정확한 사용 번호와 그 번호를 부여한 조항, 보호 대상 해시, 라이브러리 버전, 무결성 결과, 재생 및 신선함 검사, 티켓 결과, 애플리케이션 승인, 관찰된 서비스 결과가 조인되어야 합니다. 비밀 키 바이트는 그 기록에 속하지 않습니다.

추상화는 초기 권고보다 오래 살아남았다

이 프레임워크는 알고리즘 변화를 견디도록 설계되었습니다.RFC 3962는 AES 유형을 그 안에 넣었습니다.RFC 6649는 나중에 단일 DES를 폐기했고,RFC 8429는 더 많은 구형 암호를 폐기하면서 RFC 3961을 갱신했습니다. 이 문서들은 허용 가능한 알고리즘 집합을 바꿨지만, 레지스트리 항목이 모든 릴름이 이전을 마쳤다는 증거가 되지는 않았습니다.

더 시사적이었던 것은RFC 8009였습니다. 이 RFC는 자신의 AES-CTS/HMAC-SHA2 메커니즘이 더 넓은 RFC 3961 프레임워크에는 부합하지만 단순화된 프로필은 사용하지 않는다고 명시했습니다. 현대적 관행은 복호화 전에 암호문을 인증하는 것이었기 때문에, 이후의 프로필이 추상화는 유지하면서 기존 구조를 대체한 것입니다. 이 인터페이스가 끝까지 남은 이유는 하나의 암호 설계를 커버로스 자체와 혼동하지 않았기 때문입니다.

유지 관리되는 기록은 쉬운 신화에도 저항합니다.RFC Editor 정보 페이지와IETF Datatracker 이력은 발표와 상태를 확립합니다.정오표 기록에는 검증된 유니코드 코드 포인트 수정, 구형 DES 키 생성에 대한 보류 중인 기술적 수정, 그리고 검증자가 암호화에 내장된 체크섬과 독립 체크섬 연산을 구분했던 기각된 제안이 들어 있습니다. 정오표 상태는 사양 기록에 대한 증거이지, 실제 운영 중단에 대한 증거가 아닙니다.

RFC 3961의 역사적 교훈은 '커버로스는 강력한 암호를 사용했다'는 문장보다 더 작고 더 오래 지속됩니다. 이 RFC는 프로토콜에 키가 어떤 작업을 수행 중인지 명시하고, 그 명시가 파생 키에 영향을 미치도록 가르쳤습니다. 그 번호는 권한을 부여하지 않았습니다. 권한 맥락이 하나의 암호학적 바구니로 조용히 무너지는 것을 막았습니다.

출처