VPN을 두 겹으로 쌓아야 할까? 확인해야 할 세 가지 조건

VPN에 두 번째 암호화 계층을 추가하기 전에 한 가지 질문에 솔직히 답하십시오. 두 계층이 각자의 일을 마친 뒤에도 관찰자는 무엇을 여전히 쥐고 있습니까? 답이 내부 암호문이고 변하지 않았다면, 중첩은 시간을 산 것이고 그 이상은 아닙니다. 이어지는 내용은 권장 사항이 아니라 결정 절차입니다. 같은 다이어그램이 어떤 배포에서는 낭비되는 CPU이고 다른 배포에서는 정답이며, 그 둘을 가르는 것은 세 가지 조건뿐입니다.

관찰자가 무엇을 보관하는지 적어 두십시오

공격자가 오늘 저장할 수 있는 객체를 기록하고, 그다음 결국 평문을 드러낼 제거의 연쇄를 기록하십시오. 바깥 터널은 암호문을 만들어 냅니다. 그 보호가 끝나면 남는 것은 안쪽 터널의 암호문이며, 여전히 봉인되어 있습니다. 겉포장을 벗기는 것은 복호가 아닙니다. 그 문장은 중첩을 설명하며, 안쪽 키가 살아 있는 동안에만 성립합니다. 두 계층이 무엇이든 공유하는 순간, 시간선은 하나의 사건으로 무너집니다.

따라서 쓸모 있는 산출물은 상자 그림이 아니라 시간선입니다. 각 계층마다 종단점, 키 소유자, 신원 확인, 그리고 그 가정이 깨질 것으로 예상되는 연도를 적으십시오.

자기 주장을 시험하는 실용적인 방법은 관찰자가 모든 것을 기록하고 결코 포기하지 않는다고 가정하는 것입니다. 그 가정 아래에서 설계는 요구되는 수명 동안 여전히 페이로드를 보호합니까? 답이 관찰자가 트래픽을 저장하지 않기로 선택하는 데 달려 있다면, 그 설계에는 답이 없습니다.

조건 하나: 계층이 서로 다른 곳에서 끝나는가

중첩은 두 계층이 서로 다른 신뢰 도메인에서 끝날 때 값을 합니다. 예를 들어 공급자가 관리하는 IPsec 게이트웨이 앞에, 자신의 네트워크 안에서 끝나는 응용 계층 터널을 두는 경우입니다. 그러면 바깥 계층을 깨도 자신의 호스트만 열 수 있는 암호문이 나오고, 공급자는 어느 시점에도 평문을 보지 못합니다. 두 계층을 같은 게이트웨이에 두면 그 성질은 사라집니다. 상자를 침해한 사람은 다이어그램이 몇 겹의 겉포장을 보여 주든 두 복호 작업 사이의 트래픽을 읽습니다.

그것은 설계가 아니라 설치된 상태로 확인하십시오. Linux에서는 ip xfrm state가 모든 보안 연관과 그 종단점을 나열하며, 이는 각 계층이 실제로 어디서 멈추는지를 확정합니다.

조건 둘: 키 자료가 실제로 독립적인가

하나의 인증서, 하나의 사전 공유 키 또는 하나의 공급자 라이브러리로 만든 두 계층은 단계가 늘어난 하나의 계층입니다. 그러면 자격 증명 하나가 유출될 때 둘 다 열리고, 구현 버그 하나가 둘 다 한꺼번에 제거합니다. 독립성은 설정에서 보여야 하며, 슬라이드에서 주장해서는 안 됩니다.

여기서 하이브리드 키 설정이 터널 쌓기를 앞섭니다. IKEv2는 한 번의 협상에서 여러 키 교환을 실을 수 있으므로, 고전적 그룹과 포스트 양자 KEM이 서로를 감싸는 대신 같은 세션 키에 함께 공급될 수 있습니다. 결과는 두 비밀 모두에 의존하는 키를 가진 하나의 보안 연관이며, 공격자는 둘 다 깨야 합니다. 이것은 구성이 정의된 문서화된 구조이며, 두 VPN 제품을 손으로 쌓은 것과는 다릅니다. strongSwan에서는 swanctl --list-sas가 각 SA에 대해 협상된 제안을 출력하며, 이렇게 설정한 것이 아니라 실제로 무엇이 실행되었는지를 확인합니다.

조건 셋: 데이터가 바깥 가정보다 오래 사는가

이십 년을 견뎌야 하는 계층에는 이십 년짜리 논거가 필요합니다. 지금 기록하고 나중에 복호하는 것은 저렴하며, 그래서 고전적 바깥 계층을 더 강한 무언가를 둘러싼 임시 겉포장으로 취급할 수 없습니다.

각 키가 언제 복구 가능해지는지를 물으십시오. 암호가 오늘 깨졌는지가 아닙니다. 전방 비밀성이 없는 정적 키 교환은 개인 키가 떨어지는 날 소급해서 실패합니다. 일시적 키 합의는 공격자가 살아 있는 동안 공격할 수 있는 세션에서만, 또는 알고리즘 자체가 약해질 때 실패합니다. 그 차이가 안쪽 계층이 2040년에도 여전히 도움이 되는지를 결정합니다. 또한 바깥 계층이 애초에 무엇을 바꾸는지도 결정합니다. 키 수명이 더 약한 바깥 계층은 그저 시간선에서 가장 이른 지점이 되기 때문입니다.

답이 아니오일 때 대신 무엇을 지을 것인가

세 조건 중 하나라도 실패하면 중첩을 버리고 그 노력을 수명 요구를 실제로 지니는 계층에 쓰십시오. 이미 운영 중인 프로토콜에서 하이브리드 키 교환을 구성하고, 구현을 최신으로 유지하며, 의존하는 구성을 적어 두십시오. 설계 문서에 ML-KEM을 적는 것은 보안 속성이 아니며, FIPS 203은 키 캡슐화 메커니즘을 정의할 뿐 당신의 터널을 정의하지 않습니다.

두 번째 계층이 정말로 제 몫을 하는 경우, 그것을 증명이 아니라 심층 방어로 설명하십시오. 그다음 구성을 검증하십시오. 어느 종단점이 어느 키를 쥐고 있는지, 각 측이 어떤 신원을 확인하는지, 콘솔 접근 권한이 있는 운영자가 무엇을 읽을 수 있는지. 이 세 질문을 견디는 설계는 추가 CPU 값을 합니다. 견디지 못하는 설계는 그저 그림입니다.

변경 창 전에 현재 SA 표와 협상된 제안을 캡처하고 그 뒤에 다시 캡처해 비교하는 이유는, 중요한 유일한 증거가 장치들이 실제로 합의한 내용이기 때문입니다.