요약

  • RFC 3962는 Kerberos AES 비밀번호 작업 계수를 빅엔디안 4옥텟으로 인코딩했다. 명시적인 전체 0 값은 4,294,967,296회 PBKDF2 반복을 뜻했고, 필드가 없는 경우는 KDC가 매개변수를 공급할 기회를 가진 뒤에만 4,096회를 뜻했다.
  • 높은 계수는 클라이언트를 고갈시킬 수 있고 낮은 계수는 공격자의 비밀번호 탐색을 저렴하게 만들 수 있으므로, 지속 가능한 통제는 하나의 마법 숫자가 아니라 인증된 출처, 로컬 경계, 그리고 키 유도·사전인증·권한 부여에 대한 별도의 기록이었다.

Kerberos 클라이언트가 0처럼 보이는 4바이트를 받았다고 가정해 보자. 관례적인 파서는 이를 정수 0으로 바꾸고, 0을 기본값으로 대체한 뒤 계속 진행할 수 있다. 또 다른 파서는 이 필드를 빈 것으로 버릴 수도 있다. 어느 쪽이든RFC 3962가 특별한 주의를 기울여 보존한 구분을 지워버린다.

이 매개변수는 빅엔디안 순서의 부호 없는 4옥텟 정수였다. 평소에는 이 정수가 암호구(passphrase)와 솔트로부터 AES 키를 유도하는 데 쓰이는 PBKDF2 반복 횟수였다. 그러나00 00 00 00비트 패턴에는 특별한 수치적 의미가 부여되어 있었다. 즉 4,294,967,296회, 즉 (2^{32}) 회였다. 따라서 표현 가능한 최소 계수는 0이 아니라 1이었다.

부재는 다른 의미를 가졌다. KDC가 이를 공급할 기회를 가졌음에도 string-to-key 매개변수 필드가 공급되지 않으면, 클라이언트는00 00 10 00, 즉 10진수 4,096을 사용했다. 이는 렘(realm) 데이터베이스에 대한 일반적 권고도 아니고, 낙관적 사전인증을 위한 지정된 추측값도 아니었다. 그것은 오직 그 프로토콜 맥락에서 누락된 필드에 대한 해석일 뿐이었다.

하나의 필드에 두 종류의 상태가 담겼다

이것은 작은 인코딩 설계 조각이지만 시스템적 파장은 컸다. 기록에는 최소한 두 좌표가 필요했다. 필드가 존재하는지 여부, 그리고 존재한다면 그 4바이트가 무엇인지. “누락됨”, 0, 빈 버퍼를 하나의 값으로 정규화하는 파이프라인은 비용을 1,048,576배 변경할 수 있었다.

RFC 3962는 2005년 2월에 Kerberos 5용 AES 프로파일로 발표되었다. 이 문서는RFC 3961이 정의한 암호 인터페이스에 AES를 맞추었다. 128비트 블록, 128비트 또는 256비트 키, 블록에 맞지 않는 메시지를 위한 암호문 훔치기(ciphertext stealing), 무결성을 위한 HMAC-SHA1-96이 그것이다. 할당된 암호화 타입은 17과 18이었고, 체크섬 타입은 15와 16이었다. 현재의IANA Kerberos Parameters 레지스트리에도 해당 식별자와 참조가 기록되어 있지만, 레지스트리 등재가 어떤 렘이 이를 활성화하거나 선택했는지에 대한 증거는 아니다.

비밀번호 유도 키의 경우, 프로파일은 암호구와 솔트에 PBKDF2를 적용해 임시 키를 만들고, 그 뒤 상수kerberos로 RFC 3961 유도 연산을 적용했다. 당대의 PBKDF2 사양은RFC 2898이 공급했으며,RFC 8018이 나중에 PKCS #5 계열을 재출판했다. 256비트 출력이 사람의 비밀번호를 256비트의 엔트로피로 바꾸지는 못한다. 반복 횟수는 추측 검증 비용을 올릴 수 있지만, 비밀번호가 원래 가지지 못한 예측 불가능성을 만들어낼 수는 없다.

공격자는 다이얼을 양쪽으로 돌릴 수 있었다

작업 계수는 두 사람의 비용을 동시에 곱했다. PBKDF2 라운드가 하나 늘어날 때마다 오프라인 공격자의 후보 검증은 느려지고, 정당한 클라이언트의 올바른 키 유도도 같은 비율로 느려졌다. RFC 3962는 이 계수를 비대칭적 이점이 아니라 주로 상수 배율로서 유용하다고 서술했다.

이 대칭성은 정반대의 두 가지 스푸핑 공격을 낳았다. 침입자가 매우 높은 계수를 담은 KDC 응답을 위조할 수 있다면, 클라이언트는 잘못된 키를 계산하며 많은 CPU를 태울 수 있다. RFC는 이런 서비스 거부 위험을 통제하기 위해 구현이 수용하는 계수에 상한을 둘 수 있도록 허용했고, 상한이 존재한다면 50,000보다 낮지 않아야 한다고 했다. 40억 라운드는 빠른 하드웨어에서도 오래 걸리므로, 중단 가능한 연산이 현명했다.

다이얼을 내리면 위협의 방향이 바뀐다. 낮은 계수를 담은 위조 응답은 클라이언트로 하여금 더 적은 작업으로 파생된 응답을 만들도록 유도할 수 있다. 관찰자는 그 다음 비밀번호 추측을 더 저렴하게 검증할 수 있다. 따라서 문서는 상한뿐 아니라 하한도 고려했다. 안전한 결정은 “가장 큰 것이 항상 가장 강하다”도, “와이어가 말하는 것을 무조건 수용하라”도 아닌, 로컬히 통제된 구간이었다.

이는 출처(provenance)가 규모만큼 중요해진다는 뜻이다.iterations=4096만 기록하는 로그는 그 바이트가 인증된 KDC 교환에서 왔는지, 인증되지 않은 오류에서 왔는지, 캐시된 사이트 설정인지, 필드 부재 규칙인지, 테스트 오버라이드인지 보여주지 못한다. 클라이언트가 작업을 시작하기 전에 경계를 강제했는지도 보여주지 못한다. 같은 정수가 합법적 정책 선택, 호환성 폴백 또는 공격자가 통제하는 입력일 수 있다.

낙관은 신선도를 구성 문제로 바꾸었다

Kerberos 클라이언트는 때때로 낙관적 사전인증을 시도한다. 즉, KDC에 현재 매개변수를 먼저 묻지 않고 장기 키를 유도해 보호된 타임스탬프를 보내는 것이다. 추측이 맞으면 왕복 한 번을 절약한다. 그러나 추가 정보가 없는 클라이언트는 반복 횟수를 추측할 수밖에 없다.

RFC 3962는 “마지막 값을 기억하라”는 유혹적인 답을 거부했다. 몇 시간 전 같은 주체에 사용된 계수도 이미 틀릴 수 있었는데, 특히 하드웨어가 좋아짐에 따라 사이트가 계수를 늘리도록 기대되었기 때문이다. 이 문서는 권고할 특정한 영구 기본값을 찾지 못했고, 대신 수신 값에 사용하는 하한·상한과 동일한 범위 안에서 유지되는 사이트 로컬 구성을 가리켰다.

역사적 교훈은 4,096, 50,000 또는 40억이 오늘의 올바른 수치라는 것이 아니다. 하드웨어, 비밀번호 분포, 허용 가능한 지연은 계속 움직인다. 요점은 보안과 가용성에 영향을 주는 값이 소유자, 관측 시점, 진위 상태를 가졌다는 것이다. 낙관은 신선한 KDC 관측을 제거했으므로, 그 자리를 다른 거버넌스 메커니즘이 대신해야 했다.

키를 유도하는 것이 사용자를 인증하는 것은 아니었다

매개변수가 올바르게 파싱되고 PBKDF2가 완료되더라도 결과는 키 재료일 뿐이었다.RFC 4120은 더 넓은 Kerberos 티켓, 인증자, 재방지 재생, 프로토콜 기계를 공급한다. string-to-key 성공은 비밀번호가 올바른지, KDC가 사전인증을 수용했는지, 티켓이 유효한지, 애플리케이션이 요청을 승인했는지, 서비스가 제공되었는지를 증명하지 못한다.

이후 사양들은 이러한 분리를 보존했다.RFC 4537은 제안된 암호화 타입과 서버 정책 하에서 선택된 타입을 구분했다.RFC 6113은 사전인증과 암호 매개변수 운반을 일반화했다.RFC 8009는 AES-CTS/HMAC-SHA2 프로파일을 도입했고,RFC 8429는 여러 오래된 Kerberos 알고리즘을 폐기 예정으로 지정했다. 각각 체인의 일부를 바꾸었지만, 어느 것도 레지스트리 번호나 작업 계수, 성공한 키 유도를 권한과 동일시하지 않았다.

AES 구성에는 또 하나의 독립적 한계가 있었다. 암호문 훔치기는 패딩 확장을 피했는데, 이는 암호문 길이가 정확한 평문 길이를 노출한다는 뜻이었다. 길이 프라이버시가 중요하다면 상위 계층이 자체적으로 난독화 데이터를 추가해야 했다. 더 많은 CPU로는 그 누출을 수복할 수 없다. 하나의 통제가 다른 경계의 문제를 해결한 것으로 여겨져서는 안 된다.

따라서 충분한 운영 기록은 필드의 존재 비트, 정확한 옥텟, 파싱된 계수, 원본 메시지와 진위 상태, 로컬 경계, 선택된 암호화 타입, 솔트 출처, 라이브러리 버전, 소비된 시간과 자원, 중단 여부, 비밀이 아닌 유도 결과를 함께 보존해야 한다. 그리고 사전인증, 티켓, 재생, 애플리케이션 승인, 서비스 결과는 별도로 기록해야 한다. 비밀번호와 유도된 키는 로그에 속하지 않는다.

유지 관리되는 사양 기록은 신중한 독해를 지지한다.RFC Editor 정보 페이지와IETF Datatracker는 발표와 상태를 확정하며,RFC 3962 오류 검색은 수집 시점에 일치하는 항목을 반환하지 않았다. 그 부재는 구현에 대한 전면적 보장이 아니라, 하나의 증거 장부의 상태일 뿐이다.

RFC 3962의 기억에 남는 숫자가 가장 중요한 교훈은 아니었다. 교훈은 “0”, “부재”, “기본값”이 서로 다른 세 가지 주장이라는 것이다. 프로토콜이 그 차이에 수백만, 수십억 번의 연산을 걸어두는 순간, 그 구분을 보존하는 일은 보안과 가용성 양쪽의 일부가 된다.

출처