정적 키 파일의 비트 수는 OpenVPN 암호 강도가 아니다

스캐너나 동료가 OpenVPN 정적 키 파일 안에 인쇄된 비트 수를 가리키며 왜 터널이 그 크기의 암호를 쓰지 않느냐고 묻는다. 질문은 그럴듯하게 들리지만 답은 숫자가 아니다: 배너는 저장된 키 자재를 세고, 암호는 자기 키 크기가 요구하는 부분만 소비한다. 그 합계를 강도 설정으로 다루면 아무것도 바꾸지 못하는 편집이 된다. 이 형식은 어떤 단일 알고리즘이 쓰는 양보다 많은 자재를 담도록 만들어졌다.

여기서 파일이 얼마나 많은 키 자재를 저장하는가와 협상된 암호가 얼마나 강한가라는 두 가지 질문이 섞인다. 터널을 설명하는 것은 두 번째뿐이다.

배너의 숫자가 실제로 세는 것

컨테이너는 암호 자재와 HMAC 자재를 별개의 구조로 직렬화하고, 양방향 형식은 그런 집합을 두 벌 담아 각 방향이 자기 키를 가질 수 있게 한다. 쓰기 코드는 인쇄된 숫자를 직렬화된 구조의 개수와 크기, 바이트당 여덟 비트에서 도출한다. 이것은 저장량에 대한 산술이지 하나의 암호가 저장된 모든 바이트를 소비한다는 주장이 아니다. 헤더는 또한 암호 자재의 최대 할당을 고정해 라이브러리 변경이 형식의 치수를 조용히 바꾸지 못하게 한다.

인증서 키와 비교해 보라. 거기서는 비트 수가 정말로 한 객체의 크기를 설명하지만, 4,096비트 RSA 키와 배너에 4,096비트라고 적힌 키 파일은 하는 일이 다른 별개의 산출물이며, 둘을 하나의 다이얼에 있는 두 설정으로 나란히 놓으면 잘못된 결론이 나온다.

한 파일에 두 벌의 키

파일의 각 절반이 암호화와 인증 자재를 공급하는 것은 사전 공유 키 모드가 그 별개의 조각들로 양방향 패킷을 보호하기 때문이다. 활성 암호는 자기 키 크기가 요구하는 바이트만 쓰고, 다이제스트는 자기 출력 크기를 쓰므로 쓸 만한 강도는 파일 길이가 아니라 옵션에서 나온다. 십육진 덩어리를 늘려도 설정된 알고리즘이 그것을 더 소비하도록 요구하지 않는다. 주석을 더 큰 숫자로 고치는 것은 더욱 아무것도 바꾸지 않는다.

정말로 더 긴 키를 원한다면 바꿔야 할 설정은 암호나 다이제스트이고, 생성기는 선택한 알고리즘이 필요로 하는 것을 만들어 낸다.

프로필을 읽으면 어떤 모드인지 알 수 있다

같은 파일 형식이 아주 다른 두 가지 일을 하며, 어느 쪽인지는 프로필만 말해 준다. 예전 secret 줄은 파일을 터널의 유일한 키 자재로 만들고, tls-auth 이나 tls-crypt 는 인증서와 나란히 제어 채널 보호로 만든다. 어느 용도도 블록이 아무리 비슷해 보여도 그것을 클라이언트 인증서의 개인 키로 바꾸지 않는다. 대체물을 만들기 전에 옵션과 버전을 확인하고, 문자를 덧붙이는 대신 문서화된 생성기를 사용하라.

그 구분은 노출에 대한 대응도 결정한다. 유출된 tls-auth 키는 세션 키를 드러내지 않지만 공격자가 제어 채널 트래픽을 주입하게 해 주므로 여전히 교체해야 한다. 유출된 secret 키는 데이터 자체를 보호하던 자재였기 때문에 더 나쁘다.

보안 검토가 기록해야 할 것

협상된 데이터 채널 보호, 제어 채널 보호, 그리고 피어가 서로를 어떻게 인증하는지, 이 세 가지를 따로 기록하라. data-ciphers AES-256-GCM 같은 줄은 첫째만 설명하므로 거기서 멈추는 보고서는 제어 채널이 보호되는지조차 답할 수 없다. 정적 키 파일은 tls-auth 이나 tls-crypt 과 함께 쓸 때 둘째 범주에 속하고, 쓰지 않을 때는 어디에도 속하지 않는다. 범주를 뒤섞는 검토자는 더 강한 암호를 원하면서 더 큰 키 파일을 요구한다.

파일이 노출되었다면 승인된 경로로 교체하고 다시 배포하라. 침해된 비밀에 문자를 덧붙이는 것은 교체가 아니며, 노출된 자재를 유효한 상태로 남긴다.

교체 기록은 그것이 속한 프로필과 함께 보관하라. 다음 검토는 어떤 키가 어느 기간을 보호했는가를 물을 것이며, 배너는 그 답을 하지 않는다.