요약

  • RFC 10042는 Panos Kampanakis, Douglas Stebila, Torben Hansen이 서명한 IETF 정보성 RFC로, ML-KEM과 기존 곡선 사이의 세 가지 하이브리드 SSH 교환을 정의한다.
  • 서버의 응답에는 여전히 호스트 공개키와 서명이 포함된다. 이후 다른 프로토콜이 사용자를 인증하므로, KEX와 호스트 신원, 사용자 신원은 검증 근거를 공유하지 않는다.
  • AWS의 SFTP 기록은 실무에서의 이 분리를 보여준다. 먼저 하이브리드 알고리즘, 다음으로 호스트 알고리즘과 지문, 마지막으로 공개키를 통한 사용자 인증이 이루어진다.

SSH 연결의 기록은 세 박자로 된 이야기를 들려준다. 먼저 클라이언트와 서버가 전송 비밀을 만드는 방식에 합의한다. 다음으로 클라이언트가 반대쪽 끝에서 서명하는 주체가 누구인지 확인한다. 마지막으로 서버가 접속 중인 사용자가 들어올 수 있는지, 어떤 서비스를 열 수 있는지 판단한다.

인터페이스는 초록색 라벨 하나로 이 모든 것을 요약할 수 있다. 프로토콜은 그렇게 하지 않는다.

RFC 10042는 첫 번째 박자를 강화한다. 2026년 8월에 Informational 문서로 공표된 이 RFC는mlkem768nistp256-sha256,mlkem1024nistp384-sha384,mlkem768x25519-sha256을 명시한다. 각 이름은 ML-KEM을 P-256, P-384 또는 X25519와 결합하고, 포스트퀀텀 기여와 고전 기여 양쪽으로부터 SSH 비밀을 도출한다.

이 RFC가 다루는 위험은 구체적이다. 공격자는 오늘 암호화된 세션을 기록해 두었다가, 고전 합의를 깰 수 있는 능력을 갖추는 시점까지 보관할 수 있다. 이 결합은 미래의 기밀성이 단일 계열에 의존하지 않도록 막는다. 이것은 명확한 검증 근거를 받아 마땅하다. 아직 평가하지 않은 신원들의 검증 근거까지 요구해서는 안 된다.

호스트 키는 계속 서명한다

하이브리드 교환이 서버의 신원을 치우는 것은 아니다. RFC 10042가 정의한 응답에는K_S, 즉 호스트 공개키, 서버의 하이브리드 자료, 교환 해시에 대한 서명이 함께 실린다.

비밀K는 ML-KEM 비밀과 고전 비밀을 연결한 것에 해시를 적용해 얻는다. 교환 해시는 소프트웨어 식별자,SSH_MSG_KEXINIT메시지들, 호스트 키, 하이브리드 값, 결과 비밀을 포괄한다. 호스트 개인키가 이 집합에 서명한다.

이 결합은 트랜스크립트를 보호하지만, 역할 분담을 지우지는 않는다. KEX는 암호화를 위한 새 비밀을 만든다. 서명은 트랜스크립트를 서버 키와 묶어 준다. 그래도 클라이언트는 그 키가 기대한 목적지에 속한다고 믿을 외부적 근거가 필요하다.

RFC 4253은 이를kex_algorithms와server_host_key_algorithms, 즉 따로 협상되는 두 목록으로 반영한다. 클라이언트는known_hosts, 대역 외에서 검증된 지문, 인증서 또는 다른 정책을 통해 신뢰할 수 있다. 검증 없이 키를 수용하면, 그 RFC 자체가 능동적 공격에 노출된다고 경고한다. 검증 없이 수용된 키를 가진 중간자를 ML-KEM 부분이 마법처럼 알아내지는 않는다.

따라서 호스트 검증 근거는 알고리즘, 지문 또는 인증서, 신뢰 출처, 검증 결과, 그리고 발생한 키 교체까지 보관해야 한다. 서명이 여전히 고전 방식이라면, 하이브리드 KEX를 공고히 하는 것만큼 정확하게 그 사실을 밝혀야 한다.

사용자 계정은 또 다른 경계다

전송이 이미 존재하는 시점에 RFC 4252는 클라이언트 인증을 시작한다.publickey는 구현체에 필수인 방식이고, 비밀번호와hostbased는 선택 사항이며, 확장이 존재할 수도 있다. 공개키 방식에서 서버는 사용자 이름, 요청된 서비스, 알고리즘, 키, 서명을 검토한다. 추가 요소를 요구할 수도 있다.

이것은 호스트 서명의 반복이 아니다. 신뢰의 방향이 바뀐다. 호스트 키는 클라이언트가 서버를 평가하게 한다. 사용자 자격 증명은 서버가 한 사람 또는 프로세스를 평가하고 이를 계정과 묶게 한다. 저장소, 책임자, 결과가 모두 달라진다.

authorized_keys도, 계정 삭제도, MFA도, 강제 명령도, SFTP 디렉터리 권한도 ML-KEM 교환의 이름 안에 들어가지 않는다. 조직은 그런 결정을 다른 단계에 남겨 둔 채 KEX를 마이그레이션할 수 있다. 하지 말아야 하는 것은 첫 번째 이정표를 나머지 작업이 이미 끝났다는 증거로 쓰는 일이다.

지름길을 막는 세 줄

AWS 보안 블로그에는 유용한 예가 남아 있다. 2023년 원본 버전은 Kyber 기반의 실험적 하이브리드 교환을 보여 주었다. 2025년 9월 5일의 갱신은 AWS Transfer Family의 두 정책이 ML-KEM으로 전환했다고 밝히고, 이후 RFC 10042가 수용한 세 방식을 나열한다.

오래된 트레이스를 RFC 10042 세션이라 불러서는 안 된다. 그것은 관찰 모델로 쓸모가 있다. 서로 다른 줄에 하이브리드 KEX, 호스트 알고리즘으로서의ssh-ed25519, 서버 지문이 나타나고, 나중에publickey를 통한 인증이 이루어진다. 그때에야 SFTP 세션이 열린다.

운영자는 이 순서를 세 칸짜리 영수증으로 바꿀 수 있다.

  1. 제안된 방식, 선택된 방식, 새 키의 활성화.
  2. 호스트 알고리즘과 지문, 그리고 신뢰를 허용한 규칙.
  3. 사용자 방식, 계정, 인증 요소, 부여된 권한.

«connected» 상태는 채널이 작동한다는 증거를 더한다. 사용자가 과도한 권한을 가졌는지, 파일이 저장 시점에 암호화되었는지, 감사 기록이 충분한지, 백업 사본을 다시 노출하지 않고 복구할 수 있는지는 드러내지 않는다.

실험용 이름이 ML-KEM으로 대체된 것은 수명 주기의 비용도 보여 준다. 오래된 클라이언트, 갱신된 서버, 내장된 자동화가 같은 날 앞서 가지는 않는다. 선호 순서와 호환성 정책이 결과를 결정한다. IANA는 공통 좌표를 등록한다. 연결에 대한 인구조사를 공표하지는 않는다.

모든 것을 약속하지 않기에 가치 있는 표준

Amazon Science는 Kampanakis를 AWS의 principal security engineer로 소개하며, 적용 암호학, 보안 자동화, 표준화에 걸친 업무를 꼽는다. 2023년 AWS 프로필에서 그는 비대칭 암호를 목록화하고, SSH 등 다른 프로토콜에 미치는 영향을 실험하고, 알고리즘 민첩성을 갖추는 일의 필요성을 설명했다. 또한 규모 있는 해결책을 유지하겠다는 약속과 통제된 프로토타입을 구분했다.

이 경력은 맥락이지 단독 저작이 아니다. Douglas Stebila와 Torben Hansen이 그와 함께 RFC에 서명한다. 문서는 AWS, OpenSSH, PuTTY 등 참여 프로젝트의 구현과 검토를 인정한다. NIST가 ML-KEM을 정의하고, IETF와 IANA가 상호운용 가능한 공간을 지탱한다.

RFC 10042는 모두가 똑같이 실행해야 하는 최소치를 구체화한다. 메시지, 비밀 결합, 인코딩, 길이 검사, 연결별 임시 키, 난수의 올바른 사용, 입력이 유효하지 않을 때의 연결 끊기. 이렇게 해야 한 구현을 다른 구현과 대조해 시험할 수 있다.

Lu Heng의 최소 초기 명세는 그 경계를 평가하는 데 도움이 된다. 공유 표준이 모든 신뢰 저장소와 모든 로컬 계정을 다스릴 필요는 없다. 미래의 결정은 위험을 감수하는 시스템 가까이에 남아야 한다. 실행 중인 코드 우선 원칙은 라벨이 말한 것이 아니라 실제 일어난 일을 측정하는 규율을 더한다.

완전한 검증 근거에는 버전, 제안된 목록들, 선택된 KEX, 호스트 지문, 신뢰 결정, 암호와 MAC,NEWKEYS, 사용자 방식, 권한 부여 결과, 열린 채널, 재협상(rekey), 롤백, 실패가 기록된다. RFC 10042는 첫 번째 칸을 결정적으로 개선한다. 나머지 두 칸을 계속 보이게 하는 것이 그 가치를 깎아 내리지 않는 방법이다.

출처