요약

  • RFC 2104는 기존의 반복형 해시를 두 번의 키 적용 패스로 감싸, 고정된 내부 패드와 외부 패드를 사용함으로써 구현체가 압축 함수를 수정하지 않고도 빠른 해시 코드를 재사용할 수 있게 했습니다.
  • 이 문서는 해시를 교체 가능하게 만들고 출력을 선택적으로 잘라낼 수 있게 했지만, 값에 의미를 부여하는 알고리즘, 키 처리 방식, 태그 길이를 프로토콜이 명시하도록 요구했습니다.
  • 일치하는 HMAC은 공유된 키와 명명된 알고리즘 아래에서 정확한 바이트에 대한 근거입니다. 그것만으로 고유한 발신자, 승인, 신선함, 정규화, 기밀성, 전달 또는 올바른 배포를 증명하지는 않습니다.

1997년에 중요한 공학적 대상은 새로운 블록 암호나 새로운 전송 패킷이 아니었습니다. 바로 래퍼였습니다. 암호학적 해시 함수는 이미 빠르고 이식 가능하며 널리 구현되어 있었습니다. 프로토콜들은 키가 적용된 무결성을 원했지만, 비밀을 메시지 앞이나 뒤에 붙이는 겉보기에 단순한 행위는 불편한 보안 특성을 지니고 있었습니다. RFC 2104는 이전의 암호학적 분석을 소프트웨어가 재사용할 수 있는 작은 공통 구성으로 전환했습니다.

그 소박한 인터페이스가 HMAC이 되었습니다. 그 역사적 강점은 곧 근거적 한계이기도 했습니다. 즉, 키, 알고리즘, 바이트 문자열에 대한 정확한 질문에 답했을 뿐, 그 답 이후에 시스템이 추론하고 싶은 모든 것은 다른 누군가의 책임으로 남았습니다.

두 개의 패드는 해시를 교체하지 않고도 분리를 만들었다

RFC 2104는 해시 함수를 H로, 입력 블록 크기를 B로, 출력 길이를 L로 표기합니다. B보다 긴 키는 먼저 해시되고, 더 짧은 키는 0으로 채워 B바이트로 만들어집니다. 이어서 두 개의 고정된 B바이트 문자열이 두 패스를 분리합니다.ipad는 바이트 0x36을 반복하고,opad는 0x5c를 반복합니다.

그 구성은H((K xor opad) || H((K xor ipad) || text))입니다. 내부 패스는 키에서 유도된 하나의 블록을 메시지와 결합하고, 외부 패스는 서로 다른 키 유도 블록을 내부 다이제스트와 결합합니다. 기존의 해시 코드는 두 패스를 모두 수정 없이 실행할 수 있습니다. 문서의 목표는 명시적이었습니다. 즉, 기존 구현과 그 성능을 유지하고, 키 처리를 단순하게 유지하고, 분석을 지원하며, 기반 해시를 쉽게 교체할 수 있게 하는 것이었습니다.

이것은 이례적으로 얇은 공통 계층이었습니다. 메시지가 무엇을 의미하는지, 어떻게 직렬화되는지, 누가 보낼 수 있는지, 수신자가 무엇을 해야 하는지 규정하지 않았습니다. 인접한 선택들이 이미 이루어진 이후에 양쪽이 동일한 인증 값을 어떻게 계산할지만을 규정했습니다.

재사용에는 운영상의 비밀도 포함되었다

RFC 2104는 구현체가 내부 및 외부 키 블록을 처리한 후에 도달하는 해시 상태를 사전 계산할 수 있다고 언급했습니다. 짧은 메시지의 경우, 그 두 번의 반복 압축 단계를 피하는 것이 의미 있을 수 있습니다. 이 최적화는 지역적이었고 상호 운용성을 바꾸지 않았습니다.

그러나 캐시된 상태는 키의 민감성을 그대로 물려받았습니다. RFC는 이 상태들이 비밀 키처럼 보호되어야 한다고 명시합니다. 이 문장은 흔한 범주 오류를 막습니다. 즉, 유도된 성능 산출물은 원래 키 파일이 아니라고 해서 무해하지 않다는 것입니다. K를 보호하면서 재사용 가능한 키 적용 상태를 노출하는 배포는 공식은 보존했지만 보안 경계는 잃은 것입니다.

키 자체도 공식의 자동적 보호 밖에 있었습니다. RFC 2104는 무작위 또는 암호학적으로 의사무작위적인 선택, 비밀 유지, 주기적 갱신을 요구했습니다. 올바른 구현과 안전한 키 교환이 필수적인 요소라고 지목했습니다. 중첩된 구성은 하나의 계산을 표준화할 수는 있었지만, 엔트로피나 보관 책임, 교체를 만들어낼 수는 없었습니다.

태그는 자신의 맥락과 함께 있을 때만 의미를 지닌다

HMAC 응용은 결과를 왼쪽 t비트로 잘라낼 수 있습니다. RFC 2104는 당대의 지침을 제공하면서 t의 선택은 응용에 맡겼습니다. 이 선택은 유효한 태그를 추측하는 데 필요한 작업량에 영향을 미치며, 프로토콜 정의의 몫입니다. 96비트 태그와 전체 길이 태그는 모두 HMAC 출력일 수 있지만, 서로 교환 가능한 근거는 아닙니다.

해시 알고리즘, 키 식별자, 정확한 바이트에도 동일하게 적용됩니다. 검증자에게는 네 가지가 모두 필요합니다. 알고리즘, 키, 메시지 표현, 태그 규칙입니다. 이것들 없이 “HMAC 검증됨”이라고 말하는 것은 불완전한 영수증입니다.

정확한 바이트는 강조할 가치가 있습니다. HMAC은 두 JSON 객체, 헤더 집합 또는 유니코드 문자열이 같은 생각을 표현하는지 알지 못합니다. 발신자가 한 직렬화를 인증하고 수신자가 다른 직렬화를 재구성하면 태그는 달라집니다. 양쪽이 일관되게 의도하지 않은 표현을 인증한다면 태그는 일치하지만 의미론적 실수는 살아남습니다. 정규화는 인접한 프로토콜이지, MAC이 제공하는 속성이 아닙니다.

테스트 벡터가 인터페이스를 실행 가능하게 만들었다

7개월 뒤RFC 2202는 적합성 확인을 위한 HMAC-MD5 및 HMAC-SHA-1 테스트 케이스를 공개했습니다. 알려진 키와 메시지가 알려진 출력으로 이어진다는 사실은 구현자들에게 공유된 검증 지점을 주었습니다. 텍스트로 된 구성이 실행 가능한 공통 관행이 된 방식이 바로 이것입니다. 즉, 독립적인 코드가 바이트 경계에서 일치함을 보일 수 있었습니다.

그 영수증의 범위는 한정되어 있었습니다. 테스트 벡터를 통과한다는 것은 그 케이스들이 기대된 값을 산출했다는 뜻입니다. 모든 입력 길이가 동작한다는 것, 비교가 부채널에 저항적이라는 것, 운영 환경이 올바른 키를 선택한다는 것, 재생 방지 상태가 존재한다는 것, 인증된 요청이 승인되었다는 것을 증명하지 않습니다. 상호 운용성 근거는 주변 시스템 전체의 증명으로 확대되지 않을 때 정확히 가치가 있습니다.

교체 가능성은 설계에 담겼지만, 마이그레이션은 자동이 아니었다

RFC 2104는 MD5와 SHA-1을 당대의 예로 언급했지만 H를 일반화했습니다. 저자들은 더 빠르거나 더 안전한 해시가 필요해질 것이라 예상했습니다. 이후의 역사는 그 인터페이스를 검증했습니다.RFC 4868은 IPsec을 위한 SHA-256, SHA-384, SHA-512를 사용하는 HMAC을 정의했습니다.RFC 6151은 MD5 평가를 갱신하고 새 프로토콜 설계에서 HMAC-MD5를 사용하지 말 것을 권고했습니다.

그렇다고 알고리즘 민첩성이 저절로 일어났다는 뜻은 아닙니다. 식별자, 협상, 구현, 정책, 테스트 범위, 키 수명 주기가 여전히 이동해야 했습니다. HMAC은 교체해야 할 개념적 장치의 양을 줄였지만, 그것을 교체하는 조직적 작업까지 없애지는 않았습니다.

NIST의 이후FIPS 198-1은 이 구성의 제도적 도달 범위를 보여줍니다. 인터페이스의 지속성을 모든 개별 인스턴스화의 영구성과 혼동해서는 안 됩니다. 안정적인 합성 구조는 그것을 처음 익숙하게 만든 해시 선택보다 오래 살아남을 수 있습니다.

일치하는 태그는 더 긴 결정 속의 하나의 영수증이었다

공유된 대칭 키 아래에서 모든 합법적 키 보유자는 일치하는 태그를 생성할 수 있습니다. 따라서 그 태그는 그 보유자들 중에서 특정 사람, 프로세스 또는 호스트를 고유하게 지명하지 않습니다. 디지털 서명이 아니며 부인 방지를 제공하지 않습니다.

유효한 오래된 태그가 유효하다는 이유만으로 신선해지는 것도 아닙니다. 재생 저항에는 논스, 카운터, 타임스탬프 창 또는 다른 상태, 그리고 재설정과 중복에 대한 규칙이 필요합니다. 승인에는 인증된 맥락에서 허용된 행동으로의 매핑이 필요합니다. 기밀성에는 암호화가 필요합니다. 전달과 확정된 비즈니스 효과에는 다운스트림 영수증이 필요합니다. 올바름에는 알려진 답안 케이스를 넘어서는 검토, 테스트, 안전한 운영이 필요합니다.

RFC 2104의 지속적인 유산은 하나의 16진수 값이 그 모든 질문을 해결했다는 것이 아닙니다. 경계를 명확히 진술할 수 있는 좁고 재사용 가능한 구성 요소를 인터넷에 제공했다는 것입니다. 두 번의 해시 패스가 의존할 수 있는 MAC 인터페이스를 만들었습니다. 신뢰는 여전히 그 주위에서 조립되어야 했습니다.

출처