메타, NTS(Network Time Security) 지원으로 공개 시간 서비스 강화

메타, NTS 도입

메타는 공개 시간 서비스인 nts.meta.com에 NTS(Network Time Security, RFC 8915)를 적용하여 시간 동기화의 보안을 강화한다. 이로써 기기는 수신된 시간 정보가 메타에서 제공되었으며 전송 과정에서 변조되지 않았음을 검증할 수 있다. 메타는 NTS 프로토콜, 서버, 클라이언트 코드를 GitHub의 메타 타임 라이브러리를 통해 오픈 소스로 공개했다.

이는 이전에 ntpd에서 chrony로 마이그레이션하고 시간 정확도를 10밀리초에서 100마이크로초로 개선하며 time.meta.com을 공개했던 노력에 이어, 시간 정보의 검증 가능성을 확보하는 데 중점을 둔다.

시간 동기화 보안 필요성

NTP(Network Time Protocol)는 1985년 이후 인증 기능 없이 사용되어 왔으며, 이는 인터넷의 많은 기반 프로토콜과 유사하다. 그러나 NTP는 모든 인증서, 토큰, 서명의 유효성을 검사하는 데 사용되는 핵심 요소이다. 클라이언트가 48바이트를 보내고 서버가 48바이트를 돌려주면 클라이언트는 이를 신뢰하는 방식이어서 서명이나 신원 확인 절차가 없었다.

과거에는 몇 초 정도의 시간 오차는 운영상의 불편함에 불과했지만, 오늘날에는 인증서 유효성 검사, 토큰 및 자격 증명 만료, 리플레이 윈도우, 로그 상관관계 및 순서 지정 등 다양한 보안 결정에 필수적인 요소가 되었다. 인증되지 않은 시간은 X.509 인증서의 notBefore/notAfter 유효성 검사를 어렵게 만들며, 이를 해결하기 위한 임시방편은 기기를 가장 취약한 상태에 노출시키거나 양측이 서로의 오차를 추측하는 방식으로 이루어졌다.

특히 CA/Browser Forum의 SC-081v3 투표로 인해 새로 발급되는 공개 신뢰 TLS 인증서의 유효 기간이 2026년 3월 200일, 2027년 3월 100일, 2029년 3월 47일로 단축되면서, 자동화된 인증서 갱신 과정에서 시간 왜곡은 심각한 문제를 야기할 수 있다. 예를 들어, 클럭이 왜곡된 호스트에서 자동 갱신 루프가 실행되면, 아무도 모르게 인증서가 재발급되거나 실패할 수 있다.

NTS 동작 방식

NTS는 두 단계로 작동하여 배포 용이성을 높인다. 첫 번째 단계인 키 설정(NTS-KE)은 TCP/4460 포트에서 TLS 1.3을 통해 ALPN ntske/1로 협상된다. 클라이언트와 서버는 AEAD(Authenticated Encryption with Associated Data) 알고리즘(AES-SIV-CMAC-256 (ID 15), AES-SIV-CMAC-512 (17), AES-128-GCM-SIV (30) 중 하나)을 합의하고, RFC 5705 익스포터를 사용하여 TLS 세션에서 두 개의 단방향 세션 키(C2S, S2C)를 파생한다. 서버는 8개의 쿠키를 발행하고, 실제 사용할 NTP 서버를 클라이언트에게 알린 후 연결을 닫는다. 이 과정은 패킷당 한 번이 아니라 한 번만 발생한다.

두 번째 단계인 인증된 NTP는 광고된 서버로 UDP/123 포트를 통해 표준 NTPv4를 사용하며 NTS 확장 필드를 포함한다. 요청에는 고유 식별자, 쿠키, 인증자가 포함되며, 인증자는 그 이전의 모든 내용을 커버하지만 아무것도 암호화하지 않는다. 서버는 쿠키를 열어 세션 키를 복구하고 인증자를 검증한 후, 고유 식별자를 다시 보내고 자체 인증자를 포함하여 응답한다. 이 응답 인증자 안에는 새로운 쿠키가 암호화되어 포함된다. 위조된 패킷은 검증에 실패하면 폐기되며, NTS NAK는 전송되지 않아 패킷 손실과 구별할 수 없다. 재전송된 응답은 잘못된 고유 식별자를 가지므로 처리되지 않는다.

NTS의 쿠키는 서버 상태를 클라이언트에게 맡겨 보관하는 방식으로, 세션 키를 AES-SIV로 봉인하여 서버만 열 수 있도록 한다. 메타는 키를 복제하지 않고, 각 서버가 공유 마스터 시크릿과 현재 날짜(유닉스 에포크 이후 24시간 단위, 시간대/DST 없음)로부터 봉인 키를 파생한다. 이 날짜는 쿠키의 키 ID로 평문으로 전송된다. 서버는 최대 2일 전과 1일 후의 날짜에 해당하는 키를 재파생하여 쿠키를 열 수 있도록 허용하여 시간 왜곡에 대비한다. 이 방식은 키 링, 복제, 세션 테이블, 공유 상태 없이 작동하며, NTS-KE 서버와 NTP 서버가 서로 다른 장소에 있어도 상호작용 없이 작동할 수 있게 한다. 기존의 일반 NTP 경로는 NTS 확장 필드가 있을 때만 파싱되므로, 인증되지 않은 클라이언트는 이전과 동일한 방식으로 작동한다.

개발자 및 사용자 영향

NTS는 중간자 공격(MITM)으로부터 시간 정보를 위조하는 것을 방지하여 보안을 크게 강화한다. 공격자가 클럭을 조작하여 만료된 인증서를 다시 유효하게 만들거나 취소된 토큰을 다시 작동시킬 수 있는 위험을 제거한다. 또한, 클럭을 미래로 조작하여 모든 것이 한꺼번에 만료되게 하는 공격도 방어한다. 예를 들어, 2036년 2월에 32비트 필드가 랩어라운드되는 NTP의 특성상, 클럭이 2037년으로 설정된 기기는 모든 인증서가 만료되어 TLS 통신이 불가능해지고, 업데이트 서비스에도 접근할 수 없게 되어 공장 초기화나 서비스 센터 방문 없이는 복구 불가능한 상태에 빠질 수 있다. NTS는 이러한 시나리오를 방지하여 대규모 기기 관리의 물류 문제를 해결하는 데 기여한다.

개발자는 chrony 설정 파일에 'pool nts.meta.com nts iburst maxsources 5' 한 줄을 추가하는 것으로 NTS를 사용할 수 있다. nts.meta.com은 키 교환만 처리하며, 핸드셰이크 중에 time.meta.com을 NTP 응답 서버로 광고하여 클라이언트를 해당 서버로 유도한다. 'pool' 지시어를 사용하면 여러 개의 독립적인 인증된 시간 소스를 확보할 수 있어 단일 장애점을 피하고, 잘못된 소스를 투표로 배제할 수 있다.

각 소스는 자체 TLS 세션을 통해 키 교환을 수행하며 고유한 세션 키 쌍을 갖게 된다. 예를 들어, chrony는 협상된 AEAD인 AES-128-GCM-SIV (Type 30)와 128비트 세션 키(KLen 128)를 사용하며, 68바이트 쿠키(CLen 68)를 통해 두 개의 16바이트 키를 전달한다.

NTS의 한계와 과제

NTS는 모든 유형의 공격을 해결하지는 않는다. 지연 공격은 RFC 8915에 명시된 한계로, 공격자가 패킷을 지연시키면 클럭이 지연 시간의 절반만큼 이동할 수 있으며, 프로토콜의 암호화로는 이를 감지할 수 없다. 인증은 패킷을 누가 작성했는지 알려주지만, 전송에 걸린 시간은 알려주지 않는다. 이에 대한 완화책으로는 여러 독립적인 소스 사용, 건전성 검사, 제한된 단계 조정 등이 있다. 즉, 경로상의 공격자는 패킷을 지연시키거나 드롭할 수 있지만, 내용에 대해 거짓말을 할 수는 없다.

부트스트랩 문제도 존재한다. NTS-KE는 TLS를 통해 실행되며, TLS는 작동하는 클럭을 필요로 한다. 이는 위에서 언급된 순환 문제와 동일하다. RTC(Real-Time Clock)가 고장 난 기기는 첫 핸드셰이크 전에 대략적으로 올바른 시간을 확보해야 한다. 또한, NTS는 경로를 인증하지만 응답 자체를 인증하지는 않는다. 올바르게 구성되고 인증되었지만 단순히 잘못된 시간을 제공하는 서버는 완벽한 서명과 함께 잘못된 시간을 제공할 수 있다. 따라서 다수결, 건전성 검사, 모니터링은 여전히 필요하다.

단조성(Monotonicity) 역시 NTS가 해결하지 못하는 부분이다. 인증된 시간은 여전히 벽시계 시간이며, 벽시계는 윤초나 보정 시 뒤로 이동할 수 있다. 코드에서 경과 시간을 측정하는 경우 단조 클럭을 사용해야 한다.

NTS는 2020년 9월 IETF 표준 트랙의 제안 표준(Proposed Standard)으로 RFC 8915가 발행되었다. 클라우드플레어는 2019년 6월에 이미 time.cloudflare.com에 NTS를 도입하여 대규모 환경에서의 작동 가능성을 입증했다. 현재 서버 측에서는 PTB, Netnod, time.nl과 같은 국가 계측 기관 및 인터넷 인프라 운영자를 포함하여 수십 개의 공개 NTS 서버가 운영 중이며, 메타도 여기에 합류한다.

그러나 클라이언트 측, 특히 모바일 플랫폼에서의 NTS 지원은 여전히 큰 공백이다. 안드로이드의 플랫폼 시간 동기화는 일반 SNTP를 사용하며, 애플 기기는 timed를 통해 time.apple.com과 동기화하는데, 이들 모두 NTS 지원이 확인되지 않는다. 수십억 대의 휴대폰, 시계, 헤드셋이 인증되지 않은 UDP 패킷에 의존하고 있는 상황이다. 메타는 공개 시간 서비스 운영자, NTP 클라이언트 개발자, 모바일 OS 시간 스택 소유자들에게 NTS 지원 활성화를 촉구한다.