FIDO 인증 체계의 구현상 보안 취약점의 분류와 실제 사례 분석을 통한 설계 가이드라인 제시

Classification of Implementation-Level Security Vulnerabilities in FIDO Authentication Systems and Design Guidelines Basedon Real-World Case Analysis

Abstract

FIDO 프로토콜은 공개 키 암호화 방식 기반의 비밀번호 없는 강력한 인증 표준으로서 높은 수학적 안전성을 보장하지만, 실제 서비스 환경에서의 구현 과정에서는 다수의 보안 사각지대가 발생할 수 있다. 본 연구에서는 FIDO 인증 구현 단계에서 발생 가능한 보안 위협을 체계적으로 분류하고, 이를 기반으로 정부24 서비스에서 발생한 중간자 공격을 통한 전자서명 탈취 취약점 및 인증 우회로 인한 대규모 계정 탈취 취약점 사례를 분석한다. 아울러 이러한 분석을 토대로 설계 시 필수적으로 검증하여야 할 보안 요구사항을 제언함으로써 안전한 FIDO 인증 체계의 구축을 위한 구체적인 가이드라인을 제시한다. 본 연구는 FIDO 인증 도입 과정에서 반복적으로 발생할 수 있는 취약점의 예방을 위한 실무적 기준을 제시한다는 점에서 의의를 갖는다.

Although the FIDO protocol provides a strong passwordless authentication standard based on public-key cryptography and ensures a high level of mathematical security, numerous security blind spots may arise during its implementation in real-world service environments. This study systematically classifies security threats that can occur at the implementation stage of FIDO authentication and, based on this classification, analyzes practical vulnerability cases identified in the Government24 service, including a man-in-the-middle attack leading to the theft of electronic signatures and an authentication bypass vulnerability resulting in large-scale account takeover. Furthermore, drawing on these analyses, this study derives essential security requirements that must be verified during the design phase and presents concrete guidelines for building secure FIDO-based authentication systems. This work contributes practical criteria for preventing recurrent implementation vulnerabilities in the deployment of FIDO authentication systems.

I. 서론

비밀번호를 기반으로 하는 전통적인 인증 방식은 사용자 편의성과 보안성 간의 근본적인 충돌로 인해 오래전부터 보안 사고의 주요 원인 중 하나로 지적되어 왔다[1][2]. 이러한 문제를 해결하기 위한 대안으로 공개 키 암호화(public-key cryptography)를 기반으로 하는 인증 프로토콜인 FIDO(Fast IDentity Online) 표준이 등장하였다. FIDO는 사용자 디바이스의 보안 영역에 개인 키를 저장하고, 서버에는 이에 대응되는 공개 키만을 등록함으로써 서버 측에서 정보 유출이 발생하더라도 공격자(attacker)가 사용자의 실질적인 인증 정보를 파악할 수 없도록 설계되었다[3]. 또한 지문·얼굴 인식, 물리적 보안 키를 포함한 다양한 사용자 친화적인 인증 방식을 활용하여 비밀번호 없는(passwordless) 환경에서도 높은 수준의 보안성과 사용자 편의성을 동시에 제공함으로써, FIDO는 높은 시장성을 바탕으로 차세대 인증 체계의 주류로 부상하고 있다[2].

그러나 FIDO 표준 자체가 보장하는 이론적 안전성이 이를 구현한 서비스 환경의 실제적인 안전성까지 온전히 담보하는 것은 아니다. 실제 FIDO 인증 체계는 FIDO 프로토콜 자체를 구성하는 요소만으로 이루어진 구조가 아니라, 인증 절차 전반에 걸쳐 클라이언트 측 구성 요소와 서버 측 구성 요소가 상호 의존적으로 연동되는 종단 간(end-to-end) 시스템이다. 이로 인해 개발자가 표준 명세를 실제 코드로 구현하는 과정에서 필수 보안 요구사항을 누락하거나, 개발 편의 또는 비용 절감을 목적으로 검증 절차를 불완전하게 설계할 경우 표준이 의도한 보안 목표가 무력화될 가능성이 존재한다. 이러한 구현상의 결함은 FIDO 인증 체계의 구조적 안전성을 훼손하며, 그 결과로 공격자가 인증 우회 또는 세션 탈취를 통해 계정 탈취(account takeover)와 같은 높은 심각도(severity)의 공격을 수행할 수 있는 환경을 초래한다.

이러한 문제를 해결하기 위해서는 FIDO 프로토콜의 표준 규격과 실제 구현 환경 사이에 존재하는 보안 간극(security gap)에 주목할 필요가 있다. 본 연구에서는 FIDO 인증 체계의 구현 단계에서 발생 가능한 보안 취약점을 구성 요소 관점에서 종단간으로 체계적으로 분류하고, 이를 바탕으로 국내 전자정부 서비스인 정부24에서 확인된 클라이언트 측 및 서버 측 구현 취약점 사례를 분석하여, 이러한 구 현상의 결함이 실제 보안 사고로 이어질 수 있음을 실증적으로 보인다. 최종적으로는 이러한 분석 결과를 토대로 안전한 비밀번호 없는 인증 시스템 구축을 위한 실질적인 시사점을 제시하고자 한다.

II. 배경 지식

2.1 FIDO 인증 체계의 구조

FIDO는 공개 키 암호화 기반의 비밀번호 없는 인증 표준으로, 사용자의 디바이스와 신뢰 당사자(relying party) 간에 강한 소유 증명(proof of possession)을 제공한다[4]. FIDO 인증 과정에서는 서버에 어떠한 공유 비밀(shared secret)도 저장할 필요가 없으므로, 서버 측 데이터베이스가 유출되더라도 전통적인 계정 탈취 시나리오를 근본적으로 방지할 수 있다[3].

FIDO 인증 절차는 크게 등록(registration)과 인증(authentication)의 두 단계로 구성되며, 전체적인 흐름은 Fig. 1과 같다[5]. 등록 단계에서 사용자는 신뢰 당사자가 제공한 챌린지와 정책에 따라 인증기 내부의 보안 영역에서 개인키를 생성하고, 이에 대응하는 공개 키와 기기 증명(attestation)정보를 서버에 등록한다. 서버는 수신한 공개키를 사용자 계정과 대응시켜 저장한다. 이후 인증 단계에서는 서버가 전송한 새로운 챌린지에 대해 인증기가 보관 중인 개인 키로 전자서명을 생성하여 반환하며, 서버는 등록된 공개 키를 통해 해당 서명을 검증함으로써 사용자의 신원을 확인한다.

Fig. 1. Procedure of FIDO Registration and Authentication

신뢰 당사자는 수신한 응답을 통해 다음 사항을 검증한다. 첫째, 등록된 인증기의 개인키를 사용하여 서명이 생성되었는지를 확인함으로써 응답의 진위성을 검증한다. 둘째, 서명된 데이터가 신뢰 당사자가 발급한 챌린지와 일치하는지를 비교하여 요청의 신선성(freshness)을 확인한다. 셋째, 도메인 바인딩(domain binding) 여부를 검증하여 피싱, 중간자 공격(man-in-the-middle attack), 그리고 Cross-Site Request Forgery(이하 CSRF)와 같은 공격을 원천적으로 차단한다. 마지막으로, 인증기 카운터 값이 이전 인증 시점보다 증가하였는지를 검사하여 재사용 공격(replay attack)을 방지한다.

이러한 FIDO 인증 구조가 의도한 보안 목표가 달성되기 위해서는 다음 세 가지의 가정이 전제되어야 한다. 첫째, 전송 계층에서의 보안 채널의 가용성이 담보되어야 한다. 통신 간의 기밀성과 무결성이 보장되어야 인증 결과가 감청되거나 변조되지 않았다고 판단하고 신뢰할 수 있기 때문이다. 둘째, 인증이 수행되는 클라이언트 환경의 신뢰성이 보장되어야 한다. FIDO 인증에 필요한 모든 자원 및 인증의 결과로서 접근 가능한 자원이 특정 절차 또는 보안 요소의 누락으로 인해 공격자에 의해 변조되거나 무단 접근 가능해서는 안 된다. 마지막으로, 신뢰 당사자가 인증 결과를 온전히 검사해야 한다. 서버 측의 결함으로 인해 이러한 결과에 대한 우회가 가능하다면 이전의 모든 인증 절차가 무용해지기 때문이다.

2.2 FIDO 프로토콜의 유형

FIDO 인증 체계는 다양한 유형의 서비스에 적용될 수 있도록 단계적으로 발전해 왔으며, 그 결과 UAF(Universal Authentication Framework), U2F(Universal 2nd Factor), 그리고 FIDO2로 구분되는 세 계열의 프로토콜을 형성하였다[6]. 각 프로토콜은 설계 목표, 지원 기능, 그리고 플랫폼 호환성 측면에서 차이를 보인다. Table 1에서 세 프로토콜이 갖는 특성을 표 형태로 간단히 정리하였다.

Table 1. Comparison of FIDO Protocol Features

FIDO2는 통합된 상호운용성과 높은 보안성을 달성함으로써 기술적 진보를 이루었음에도 불구하고, UAF는 여전히 다수의 서비스에서 대체 불가능한 위치를 차지하고 있다[7]. 이는 보안이 중시되는 다수의 서비스가 폐쇄적인 성격을 갖는 모바일 애플리케이션 환경을 중심으로 발전해 왔으며, 이러한 환경에서 이미 구축된 UAF 인프라를 FIDO2로 전면 교체하는 과정에서 비용 및 호환성 문제가 발생하기 때문이다. 그 결과, 많은 서비스가 여전히 UAF 기반의 인증 체계를 유지하고 있다. 따라서 최신 표준인 FIDO2뿐만 아니라, 실제 운영 환경에서 광범위하게 사용되고 있는 UAF 구현체의 보안성을 점검하는 것 또한 여전히 시의적절한 과제이다.

2.3 프로토콜 중심 보안 분석의 한계

FIDO Alliance는 FIDO 프로토콜이 달성하고자 하는 보안 목표를 명확히 정의하기 위해 공식 보안 참조 문서인 FIDO Security Reference를 제시하였다[3]. 해당 문서는 UAF, U2F, 그리고 FIDO2를 포괄하는 공통 보안 기준으로서, 프로토콜이 고려해야 할 보안 목표, 보호해야 할 자산, 필요한 보호 조치, 그리고 위협 모델을 체계적으로 정의한다.

그러나 해당 문서는 그 성격상 FIDO 프로토콜의 설계 원칙과 암호학적 안전성에 중점을 두고 있어, 실제 서비스 구현 과정에서 발생하는 보안 문제를 충분히 설명하기에는 한계가 존재한다. 특히 구현 단계에서 발생하는 취약점을 주로 프로토콜 관점에서만 다룸으로써, 이를 개발자가 이해하고 구현 수준에서 대응할 수 있는 형태로 환원하는 데에는 부족함이 있다.

대표적인 예로, 사용자 디바이스가 침해되어 애플리케이션의 무결성이 손상되는 상황을 들 수 있다. 보안 참조 문서에서는 이러한 위협을 FIDO 프로토콜의 보호 범위를 벗어난 영역으로 간주하여 구체적인 대응 방안을 제시하지 않는다. 그러나 실제 서비스 환경에서 FIDO 인증을 도입하는 개발자의 관점에서는, 해당 위협이 프로토콜의 범위 밖에 속한다는 이유만으로 이를 고려 대상에서 배제해서는 안된다. 오히려 모바일 애플리케이션 환경에서는 후킹(hooking), 리패키징(repackaging)과 같은 공격 기법이 빈번히 활용되므로, 애플리케이션 무결성 붕괴로 인한 인증 우회 가능성은 FIDO 인증의 실효성을 직접적으로 위협하는 요소로 작용한다.

또한 문서는 위협 모델에 대한 보안 조치를 제시하고 있으나, 이를 목표 지향적인 요구 사항의 형태로 기술할 뿐, 해당 요구 사항이 구현 과정의 어느 계층에서 어떠한 방식으로 위반될 수 있는지에 대한 구체적인 설명은 제공하지 않는다. 이로 인해 제시된 보안 조치는 선언적인 원칙으로 해석되기 쉽고, 실제 구현 요소에 직접적으로 대응시키기에는 어려움이 존재한다. 따라서 해당 문서는 실제 서비스 구현 환경에서 발생할 수 있는 구체적인 공격 시나리오를 사전에 식별하기 위한 실무적 지침으로 활용되기에는 한계를 지닌다.

아울러 기존 FIDO 관련 연구들은 주로 프로토콜의 암호학적 안전성을 검증하는 데 초점을 맞추어 왔다[8][9][10]. 그러나 실제 서비스 환경에서의 FIDO 인증 구현체는 다수의 구성 요소가 상호작용하는 종단 간 시스템으로 동작하며, 이 과정에서 발생하는 취약점은 프로토콜 명세 수준의 분석만으로는 충분히 포착되기 어렵다.

따라서 본 연구에서는 FIDO 프로토콜을 단일 구성 요소로 간주하지 않고, 클라이언트와 서버로 구성된 종단 간 시스템으로 구분하여 분석함으로써 각 단에서 발생할 수 있는 구현 취약점을 체계적으로 유형화한다. 이러한 접근은 프로토콜 설계의 보안성 평가에 초점을 맞춘 기존 연구와 달리, 구현 단계에서 발생하는 보안 간극을 규명하고 이를 해소하기 위한 구체적인 방안을 제시한다는 점에서 독자적인 기여를 갖는다.

III. 보안 취약점 분류

FIDO 프로토콜의 이론적 보안성이 실제 구현 단계에서의 안전성을 온전히 담보하지 못함에도 불구하고, 구현 과정에서 발생하는 보안 실패에 대한 체계적인 분류 연구는 여전히 미비하다. 이로 인해 실제 서비스 환경에서는 4장에서 다루는 사례와 같이 다양한 보안 취약점이 발생할 수 있다. 이에 본 장에서는 FIDO Security Reference에 제시된 취약점 분류 체계를 기반으로 하여, FIDO 인증 시스템을 단일 프로토콜이 아닌 클라이언트와 서버가 유기적으로 상호작용하는 종단 간 구현체로 바라보고, 실무적인 관점에 적합하도록 재구성 한다. 여기에 FIDO 프로토콜과 직접적인 연관이 없으나 구현 시 반드시 고려해야 하는 주요 취약점 몇 가지를 추가하여 다룸으로써 운영 환경의 현실적인 공격 가능성을 수용하고자 하였다. 또한 각 계층에서 발생 가능한 주요 취약점을 시나리오 기반으로 유형화함으로써, 이후 4장의 사례 분석과 5장의 실무 가이드라인 수립을 위한 논리적 토대를 마련하고자 한다.

3.1 클라이언트 측 취약점

3.1.1 SSL 인증서 검증 미흡으로 인한 중간자 공격

FIDO 표준의 암호학적 안전성은 전송 계층에서의 기밀성과 무결성이 보장될 경우에만 유효하다. 일반적으로 클라이언트와 서버 간 통신은 SSL을 통해 암호화된 상태로 이루어지지만, SSL 인증서 검증이 비활성화된 경우 공격자는 중간자 공격을 통해 FIDO 인증 과정을 도청하거나 변조할 수 있다.

가령, FIDO 인증이 수행되는 모바일 애플리케이션 환경에서 구현 오류가 존재하는 커스텀 TrustManager를 사용하는 상황을 가정한다. 공격자는 ARP 스푸핑(ARP spoofing), 이블 트윈 공격(evil twin attack), 그리고 라우터 하이재킹(router hijacking)과 같은 공격 기법을 이용하여 사용자 디바이스의 네트워크 트래픽을 가로챌 수 있는 환경을 구성한다. 이후 동일 네트워크상의 사용자가 모바일 애플리케이션에서 FIDO 인증을 수행할 경우, 공격자는 신뢰 당사자 서버로 전송되는 요청을 가로챈 뒤 이를 공격자가 대신 전송함으로써 사용자의 세션 토큰을 탈취할 수 있다.

이는 근본적으로는 전송 계층의 취약점이나, 개발자의 관점에서 보았을 때 클라이언트 측 구현에 의해 발생하는 문제이므로 본 연구에서는 이를 클라이언트 측 취약점으로 분류하는 것이 적절하다.

3.1.2 도메인 바인딩 검증 미흡으로 인한 피싱

FIDO 인증 체계에서는 신뢰 당사자를 식별하기 위한 고유한 값인 RPID(Relying Party IDentifier)와 도메인이 반드시 일치해야 한다. FIDO 프로토콜은 이러한 도메인 바인딩을 통해 피싱 공격을 근본적으로 차단한다. 그러나 클라이언트 측 구현에서 RPID 또는 도메인 검증을 부적절하게 수행하거나 전혀 수행하지 않는 경우, 도메인 바인딩이 성립하지 않으므로 피싱에 대한 보호를 더 이상 기대할 수 없다.

가령, FIDO 인증이 수행되는 모바일 애플리케이션에서 도메인 바인딩 검증이 이루어지지 않고, 동시에 딥링크(deep link) 취약점이 존재한다고 가정한다. 이 경우 공격자는 모바일 애플리케이션의 웹뷰(WebView)를 통해 공격자의 피싱 사이트로 이동하도록 유도하는 딥링크를 사용자에게 전송할 수 있다. 사용자가 해당 딥링크를 통해 공격자의 피싱 사이트에 접속하면, 공격자의 서버는 특정 서비스의 유효한 RPID를 제시하여 사용자의 인증기가 공격자가 생성한 챌린지에 서명하도록 유도한다. 공격자는 서명된 챌린지를 이용하여 해당 서비스의 인증 절차를 완료하고, 결과적으로 사용자의 세션을 발급받을 수 있다. 이러한 시나리오의 전체적인 흐름은 Fig. 2와 같다.

Fig. 2. Phishing Scenario due to Insufficient Domain Binding Verification

이 경우는 공격자가 피싱 공격을 수행할 수 있는 여지를 제공하였으므로 클라이언트 환경의 신뢰성을 확보하지 못했다고 판단할 수 있다.

3.1.3 취약한 로컬 저장소로 인한 자격 증명 핸들 노출

FIDO 인증 체계에서 개인 키는 인증기 내부의 보안 영역에서 보호되므로 일반적으로 외부로 노출되지 않는다. 그러나 인증 수행을 위해 필수적으로 요구되는 자격 증명 식별자와 키 핸들은 애플리케이션의 로컬 저장소에 보관되어야 한다[3]. 문제는 제한된 보안 저장소 용량을 극복하기 위해 특정 FIDO 구현체가 채택하고 있는 키 래핑(key wrapping) 방식에 있다. 이 방식에서 키 핸들은 단순한 식별자가 아니라, 인증기 고유의 마스터 키로 암호화된 개인 키 블롭(blob)이다. 개발자가 이러한 구조적 특성을 인지하지 못한 채 편의를 위해 키 핸들을 평문으로 SharedPreferences 또는 로컬 저장소에 저장할 경우, 공격자는 암호화된 상태의 개인 키를 탈취할 수 있다.

가령, FIDO 인증이 수행되는 모바일 애플리케이션이 인증기에서 반환된 자격 증명 식별자와 키 핸들을 SharedPreferences에 평문으로 저장한다고 가정한다. 공격자는 사용자의 디바이스에 악성 애플리케이션을 설치하거나 물리적 접근을 통해 해당값을 탈취할 수 있다. 이 경우 탈취된 키 핸들은 암호화된 개인 키 정보를 포함하고 있으므로 공격자는 개인키에 대한 복호화를 시도할 수 있다. 설령 복호화가 불가능하더라도, 공격자는 확보한 식별자를 이용하여 서버에 반복적으로 인증 요청을 전송함으로써 정상적인 인증 수행을 방해하는 서비스 거부 공격(denial of service)을 수행할 수 있다.

3.1.4 애플리케이션 무결성 붕괴로 인한 인증 우회

FIDO 인증의 높은 보안성은 애플리케이션이 FIDO 인증의 결과를 올바르게 활용한다는 전제를 필요로 한다. 즉, FIDO 인증 절차가 정상적으로 수행되었더라도, 인증 이후 공격자가 임의의 방법으로 인증 결과를 획득할 수 있다면 앞선 모든 인증 절차는 무의미해진다. 특히 모바일 애플리케이션 환경에서는 후킹과 같은 공격 기법을 통해 인증 절차를 비교적 쉽게 무력화할 수 있다. 이러한 위협은 FIDO 인증 프로토콜 자체의 결함은 아니지만, FIDO 인증을 통해 달성하고자 하는 보안 목표를 낮은 비용으로 무력화할 수 있다는 점에서 구현 단계에서 필수적으로 고려되어야 한다.

가령, 내부 중요 기능에 FIDO 인증을 통한 접근 제어를 도입한 모바일 애플리케이션이 존재한다고 가정한다. 또한 공격자가 사용자 디바이스를 탈취하여 물리적으로 조작할 수 있는 경우, 공격자는 Frida[11]와 같은 후킹 도구를 이용하여 보호된 중요 기능을 강제로 호출할 수 있다. 이를 통해 공격자는 어떠한 FIDO 인증 절차도 거치지 않고 중요 기능을 사용할 수 있게 된다. 이러한 시나리오의 전체적인 흐름은 Fig. 3과 같다.

Fig. 3. Integrity Compromise Scenario due to Hooking

3.1.5 서드파티 SDK 및 라이브러리 관리 미흡

FIDO 인증 절차의 모든 기능을 서비스 개발자가 직접 구현하는 경우는 드물며, 일반적으로 일부 기능은 서드파티 SDK(Software Development Kit) 또는 라이브러리를 활용하여 구현된다. 통상적으로 인증기 제어 및 기기 증명 검증과 같은 핵심 프로토콜 로직은 SDK가 담당하는 반면, 인증 요청의 생성, 사용자 검증 시점의 제어, 그리고 네트워크 보안 설정 등은 여전히 서비스 개발자가 직접 구현해야 하는 영역으로 남는다. SDK를 활용하는 것은 개발 편의성과 비용 절감 측면에서 효과적이며, 전문 보안솔루션 업체에 의해 개발된 경우 최소한의 보안성을 기대할 수 있다는 장점이 있다. 그러나 동시에 SDK 자체의 구현 결함으로 인해 보안 취약점이 발생할 가능성도 존재한다.

특히 서드파티 SDK는 여러 서비스에서 재사용되므로, SDK 내부에 취약점이 존재할 경우 해당 SDK를 사용하는 모든 서비스가 동시다발적으로 위험에 노출될 수 있다. 또한 SDK에서 발생한 취약점은 서비스 개발자가 자체적으로 발견하거나 신속히 패치하기 어렵다는 문제를 가진다. 가령, 특정 SDK에서 3장 1절 1항의 SSL 인증서 검증 미흡 취약점이 존재한다고 가정할 경우, 해당 SDK를 사용하는 다수의 서비스가 공격 대상이 되며, 공격자가 잠재적으로 탈취할 수 있는 세션 토큰의 규모 또한 영향을 받는 서비스 수에 비례하여 증가한다.

3.2 서버 측 취약점

3.2.1 인증 절차와 세션 발급의 불완전한 연계로 인한 세션 탈취

정상적인 인증 절차에서는 서버가 클라이언트로부터 전송된 전자서명의 유효성을 검증하고, 이를 근거로 세션 발급 여부를 결정한다. 이상적인 경우 이러한 일련의 과정은 클라이언트의 단일 HTTP 요청을 통해 수행되는 것이 모범 사례(best practice)이다. 인증 절차와 세션 발급이 별개의 요청으로 분리되어 수행될 경우, 서버는 두 요청간의 인과 관계를 증명할 수 있도록 엄격한 상태 관리를 수행해야 한다. 그러나 실제 구현 환경에서는 공격자가 예측하기 쉬운 단순한 식별자를 사용하는 등 두 요청 간의 연계가 미흡하게 처리되는 경우가 발생할 수 있다.

가령, FIDO 인증을 수행하는 웹서버가 서명 검증 API와 세션 발급 API를 분리하여 두 개의 요청을 통해 인증을 수행한다고 가정한다. 또한 세션 발급 시 서버가 선행된 서명 검증의 성공 여부를 클라이언트 요청의 파라미터 또는 쿠키에 의존하여 판단하도록 구현되어 있다면, 공격자는 프록시 도구를 이용하여 서명 검증 요청을 생략하고 세션 발급 API를 직접 호출한 후 파라미터를 변조한 요청을 전송함으로써 비인가된 세션을 발급받을 수 있다.

3.2.2 챌린지 신선성 검증 미흡으로 인한 재사용 공격

FIDO 프로토콜은 매 인증 시도마다 서버가 생성한 난수 기반의 챌린지를 클라이언트에 전달하고, 인증기가 이에 대한 전자서명을 생성하여 이를 다시 서버로 전송하도록 한다. 이 절차의 핵심은 서버가 인증 시도마다 서로 다른 챌린지를 발급하여, 생성되는 전자서명 값 또한 매번 상이하도록 강제하는 데 있다. 서버가 챌린지가 실제로 자신이 발급한 값인지, 그리고 이미 사용되었거나 유효기간이 만료되지는 않았는지를 검증하지 않는 경우, 공격자는 과거에 사용된 유효한 전자서명을 재사용하여 인증을 우회하는 재사용 공격을 수행할 수 있다.

가령, FIDO 인증을 수행하는 웹 서버가 클라이언트가 전송한 전자서명의 암호학적 유효성은 검증하나, 서명에 포함된 챌린지의 신선성 및 재사용 여부는 검증하지 않는다고 가정한다. 공격자는 공용 네트워크 환경에서 중간자 공격을 통해 사용자가 인증 시 전송한 전자서명 값을 확보한 뒤 이를 서버에 재전송한다. 이 경우 서버는 전자서명이 정상적인 개인키로 생성되었다는 사실만을 근거로 이를 정상 요청으로 오인하여 공격자에게 세션을 발급하게 된다.

3.2.3 인증기 카운터 값 검증 미흡으로 인한 인증기 복제

인증기는 각 인증 수행 시 내부적으로 증가하는 카운터 값을 포함하여 전자서명을 생성하며, 서버는 해당 값을 이전에 저장된 값과 비교함으로써 인증기 복제에 의한 재사용 공격을 탐지한다. 전자서명 내의 카운터 값이 서버에 저장된 값보다 작거나 같을 경우, 이는 인증기가 복제되었거나 무결성이 손상되었음을 의미하므로 세션을 발급해서는 안 된다. 공격자가 복제된 인증기를 이용하여 지속적으로 접근하는 것을 방지하기 위해 서버는 카운터 값이 이전 값보다 증가하였는지를 확인하는 검증 절차를 필수적으로 수행해야 한다. Fig. 4는 서버가 카운터 값을 정상적으로 검증하는 경우, 복제된 인증기를 이용한 공격 시도가 차단되는 전체적인 흐름을 보여준다.

Fig. 4. Counter Validation Mechanism for Preventing Authenticator Copying

가령, 공격자가 사용자의 보안 저장소를 탈취하여 비밀 키를 포함한 FIDO 인증에 필요한 모든 내부 데이터를 확보하였고, 동시에 서버가 카운터 값을 검증하지 않는다고 가정한다. 공격자가 이를 탈취한 시점에서는 사용자 인증기의 카운터 값과 공격자가 복제한 인증기의 카운터 값이 동일하다. 이후 사용자가 인증기를 이용하여 FIDO 인증을 수행하면 두 카운터 값은 더 이상 동일하지 않게 된다. 그러나 서버가 인증기 카운터 값을 검증하지 않는 경우, 공격자는 여전히 복제된 인증기를 통해 사용자의 계정으로 인증을 수행할 수 있다.

3.2.4 인증 정책 검증 미흡으로 인한 다운그레이드 공격

FIDO 프로토콜은 서비스에 높은 보안 수준이 요구되는 경우, 허용 가능한 인증 수단을 정책(policy)의 형태로 클라이언트와 서버에 전달하도록 설계되어 있다. 이러한 정책은 프로토콜 규격에 따라 UAF의 AAID(Authenticator Attestation IDentifier) 또는 FIDO2의 사용자 검증 플래그(User Verification flag, 이하 UV 플래그)의 형태로 구체화되어 전자서명에 포함된다. 서버가 이러한 정책의 준수 여부를 검증하지 않는 경우, 공격자는 클라이언트 측 애플리케이션을 변조하여 PIN이나 패턴과 같이 인증 강도가 낮은 수단으로 전자서명을 생성하는 다운그레이드 공격(downgrade attack)을 수행할 수 있다.

가령, 모바일 애플리케이션은 지문 인증을 통해 전자서명을 생성하지만, 서버 측에서 인증 정책에 대한 검증을 수행하지 않으며 애플리케이션 무결성 검증 또한 미흡한 상황을 가정한다. 공격자는사용자 디바이스를 탈취한 후 리패키징을 통해 애플리케이션의 내부 로직을 수정함으로써, 인증 시 지문 인증 대신 PIN 인증 모듈이 호출되도록 조작할 수 있다. 이 경우 공격자는 사용자의 생체 정보를 획득하지 않더라도, 상대적으로 인증 강도가 낮은 PIN 입력만으로 인증에 성공할 수 있다.

3.2.5 세션 바인딩 미흡으로 인한 세션 탈취

FIDO 인증은 사용자 편의성을 목적으로, 웹 브라우저에서의 로그인 요청을 사용자의 모바일 애플리케이션으로 전달하여 인증을 수행하는 대역 외(out-of-band) 인증 방식으로 널리 활용된다. 이러한 환경에서는 브라우저가 모바일 애플리케이션에서의 인증 요청이 완료될 때까지 폴링(polling)을 수행하는 구조를 가지며, 그 결과 3장 2절 1항에서 논의한 바와 같이 인증 절차의 시작과 세션 발급이 분리된 요청으로 처리되는 경우가 많다. 따라서 서버는 로그인을 요청한 클라이언트와 세션을 발급 받는 클라이언트가 논리적으로 동일함을 보장하기 위해, 인증 이전에 발급된 임시 세션 토큰과 인증 시작 시 발급된 트랜잭션 식별자(TranSaction IDentifier, 이하 TXID)를 매핑하는 세션 바인딩을 필수적으로 수행해야 한다.

가령, 사용자가 임시 세션 토큰을 발급받은 상태로 공용 네트워크 환경에서 대역 외 인증을 시도하고, 서버가 세션 바인딩을 엄격하게 검증하지 않는다고 가정한다. 사용자가 모바일 애플리케이션에서 인증을 완료한 후 TXID를 이용해 세션 발급 요청을 전송하면, 공격자는 해당 요청을 가로채거나 재전송할 수 있다. 서버가 임시 세션 토큰과 TXID의 매핑을 검증하지 않는 경우, 공격자는 사용자의 세션을 탈취할 수 있다.

3.2.6 세션 토큰 관리 미흡으로 인한 세션 탈취

FIDO 프로토콜이 보장하는 강력한 보안성은 사용자가 인증을 수행하는 시점에 한해 유효하다. 인증 절차가 완료된 이후 서버가 클라이언트에 부여하는 세션 토큰의 관리는 FIDO 프로토콜의 보호 범위를 벗어나며, 이후의 보안성은 전적으로 웹 애플리케이션의 세션 관리에 의존하게 된다. 따라서 인증 단계를 명세에 따라 정확히 구현하였더라도, 세션 토큰에 대한 보호 조치가 미흡할 경우 전체 시스템의 보안성은 그 수준에 맞추어 하향된다. 예를 들어 세션 쿠키를 보호하기 위한 속성이 적용되지 않은 경우, 공격자는 Cross-Site Scripting(이하 XSS)과 같은 공격 기법을 통해 세션 토큰을 탈취할 수 있다[12].

가령, FIDO 인증을 도입한 웹 서비스의 게시판에 저장형 XSS(stored XSS) 취약점이 존재하고, 세션 쿠키에 HttpOnly 속성이 적용되지 않았다고 가정한다. 공격자는 게시판에 세션 쿠키를 공격자의 서버로 전송하는 악성 자바스크립트가 포함된 게시글을 업로드한다. 이후 사용자가 정상적인 FIDO 인증을 거쳐 로그인한 상태로 해당 게시물을 열람하면, 브라우저에서 공격자가 삽입한 악성 자바스크립트가 실행되어 사용자의 세션 쿠키가 공격자에게 탈취될 수 있다.

IV. 공공 서비스 취약점 분석 결과

3장에서는 FIDO 인증 체계를 구성하는 클라이언트 측 및 서버 측에서 발생 가능한 구현 취약점을 시나리오 기반으로 유형화하였다. 본 장에서는 해당 분류 체계의 실효성을 검증하기 위하여, 본 논문의 저자가 직접 분석을 통해 발굴한 실제 취약점 사례를 대상으로 분석을 수행한다. 구체적으로, UAF 기반의 간편 인증을 도입한 정부24 서비스에서 확인된 클라이언트 측 취약점(KVE-2025-0352)과 서버 측 취약점(KVE-2025-0876)이 실제 환경에서 어떠한 형태로 발현되는지를 규명한다. 이를 통해 구현 단계의 결함이 FIDO 표준이 의도한 보안 목표를 어떻게 무력화할 수 있는지를 단계적으로 분석한 결과를 제시한다.

본 연구에서의 취약점 발굴은 공공 서비스에 존재하는 보안 취약점을 식별하고, 이에 대한 개선 방안을 제시함으로써 전반적인 보안성 향상에 기여하기 위한 목적으로 수행되었다. 또한 모든 분석 과정은 운영 서버의 가용성에 영향을 미치지 않도록 비침해적인 방식의 제한적인 개념 증명(proof of concept) 수준에서만 이루어졌으며, 본 장에서 언급된 모든 취약점은 관련 기관을 통해 보안 패치가 완료되었음을 밝힌다.

4.1 클라이언트 측 취약점

본 절에서는 정부24의 안드로이드 애플리케이션에서 발생한 KVE-2025-0352를 분석한다. 해당 애플리케이션에서 확인된 취약점의 유형은 3장 1절 1항에서 분류한 SSL 인증서 검증 미흡으로 인한 중간자 공격과 3장 1절 5항에서 분류한 서드 파티 SDK 및 라이브러리 관리 미흡에 해당한다. 이는 국제표준 취약점 분류 체계인 CWE 기준으로 CWE-295[13], CWE-297[14], 그리고 CWE-1395[15]로 분류할 수 있다. 본 연구에서는 해당 취약점이 주관적 판단이 아닌 국제적으로 공인된 보안 취약점 유형에 해당함을 명확히하고, 연구의 객관성을 확보함과 동시에 보다 개발자 친화적인 기준을 제시하기 위하여 CWE 분류 체계를 활용하였다.

일반적으로 SSL로 암호화된 트래픽을 복호화하여 중간자 공격을 수행하기 위해서는 공격자가 생성한 사설 인증서(private certificate)를 사용자의 디바이스에 설치하고, 이를 신뢰하도록 설정하여야 하며, 인증서에 포함된 도메인 정보 또한 실제 접속 주소와 일치하도록 보장되어야 한다. 그러나 애플리케이션을 역공학(reverse engineering)하여 소스 코드를 분석한 결과, SSL handshake 과정에서 필수 검증 절차를 우회하도록 명시적으로 설정된 코드와 모든 도메인에 대한 연결을 허용하는 코드가 식별되었다. 이로 인해 별도의 인증서 설치 없이도 요청이 평문으로 노출되고, 도메인 불일치 여부와 무관하게 연결이 허용되는 취약점이 존재함을 확인하였다. 해당 취약점의 원인이 되는 코드와 그로 인한 결과는 다음과 같다.

4.1.1 인증서 신뢰 체인 검증 비활성화

애플리케이션의 FIDO 등록 및 인증 로직을 분석한 결과, SSL 연결 수립 시 필수적으로 수행되어야 하는 인증서 신뢰 체인 검증을 명시적으로 비활성화하는 서드파티 SDK 코드가 존재하였다.

Fig. 5와 Fig. 6은 각각 FIDO 등록 및 인증 절차의 주요 진입점에 해당한다. Fig. 5에서 FIDORegistration 클래스는 등록 절차에 사용되는 mRegist 및 magicFIDOUtil 객체를 초기화하고, registerFIDO() 메서드를 통해 사용자명, 디바이스 정보, 운영체제 버전 등 등록 요청 생성에 필요한 정보를 수집하여 Hashtable에 적재하는 역할을 수행한다. Fig. 6에서 FIDOAuthentication 클래스의 startAuthentication() 메서드 또한 등록 과정과 유사하게 인증 요청 생성에 필요한 정보를 수집하여 패키징하는 구조를 가진다.

Fig. 5. FIDORegistration() Constructor Disabling SSL Verification

Fig. 6. startAuthentication() Method Disabling SSL Verification

분석 결과, FIDORegistration() 생성자와 startAuthentication() 메서드 모두에서 Fig. 5 및 Fig. 6의 ①과 같이 MagicFIDOUtil.setSSLEnable(false)가 명시적으로 호출되는 것을 확인하였다. MagicFIDOUtil.setSSLEnable(false)의 의미는 Fig. 7과 Fig. 8을 통해 구체적으로 확인할 수 있다. Fig. 7의 ①에 해당하는 MagicFIDOUtil 클래스의 setSSLEnable() 메서드는 전달받은 bool 값을 ②의 코드를 통해 SSLEnableFlag 클래스로 전달하는 래퍼(wrapper)의 역할만을 수행한다. 실질적인 보안 설정의 변경은 Fig. 8의 SSLEnableFlag 클래스에서 이루어지며, 해당 클래스는 애플리케이션 전역에서 참조되는 CHECK_SSLCERT 변수를 관리한다. 초기화 과정에서 MagicFIDOUtil.setSSLEnable(false)가 호출됨에 따라 CHECK_SSLCERT 값은 false로 설정되고, 이후③의 getSSLEnable() 메서드의 반환값 또한 false가 된다.

Fig. 7. MagicFIDOUtil Class Delegating SSL Configuration

Fig. 8. SSLEnableFlag Class Controlling Global SSL Verification

Fig. 9는 애플리케이션이 SSL handshake 과정에서 실제로 사용하는 커스텀 X509TrustManager 구현체를 나타낸다. Fig. 9의 checkServerTrusted() 메서드는 자바 표준 보안 인터페이스를 오버라이드(override)한 것으로, 인증서 유효성 및 신뢰 체인 검증을 수행하는 필수 로직이 런타임에서 false로 평가되는 if (SSLEnableFlag.getSSLEnable()) 조건문 내부에 구현되어 있다. 그 결과 해당 조건이 만족되지 않는 경우 제어 흐름이 ④로 이동하여 어떠한 예외도 발생하지 않은 채 메서드가 종료된다.

Fig. 9. Custom X509TrustManager Bypassing SSL Verification

X509TrustManager는 구조적으로 checkServerTrusted() 메서드가 예외 없이 정상 종료될 경우 인증서 검증이 성공한 것으로 간주한다. 따라서 공격자가 위조하거나 탈취한 인증서, 또는 프록시 도구가 동적으로 생성한 인증서를 제시하더라도 애플리케이션은 이를 신뢰하게 된다. 그 결과 공격자는 중간자 공격을 수행하여 FIDO 등록 및 인증 과정에서 전송되는 정보를 평문으로 감청하거나 변조할 수 있다. 이러한 취약점으로 인해 평문으로 노출되는 FIDO 등록 요청에는 Fig. 10, Fig. 11, 그리고 Fig. 12가 포함되며, FIDO 인증 요청 또한 구성 요소가 유사하므로 이에 대한 그림은 생략한다.

Fig. 10. HTTP Request 1 of FIDO Registration Exposed in Plaintext

Fig. 11. HTTP Request 2 of FIDO Registration Exposed in Plaintext

Fig. 12. HTTP Request 3 of FIDO Registration Exposed in Plaintext

공격자가 각 요청을 감청함으로써 수행할 수 있는 공격은 다음과 같다. 첫째, Fig. 10.을 통하여 사용자 및 디바이스의 고유 식별 정보를 확인할 수 있다. 요청 내 context 필드에는 userName, deviceId, deviceModel, 그리고 deviceOS 등의 정보가 포함되어 있다. 이들은 단독으로는 크게 가치가 있다고 보기 어려우나, 결합될 경우 특정 사용자를 고유하게 식별할 수 있는 지문(fingerprint)이 되어, 추후 사회공학적 공격의 기반으로서 활용될 수 있다. 둘째, Fig. 11의 요청 트래픽을 폐기(drop)한 후 공격자가 동일한 요청을 전송함으로써 세션 탈취를 수행할 수 있다. 공격자는 사용자가 전송한 인증 요청을 가로채 서버로 전달하지 않고 폐기한 뒤, 탈취한 요청을 자신이 그대로 전송함으로써 서버 가이를 정상적인 세션 내 요청으로 오인하도록 유도할 수 있다. 마지막으로 Fig. 12의 요청 정보를 활용하여 공격자 소유의 FIDO 장치를 무단으로 등록한 후, 영구적인 접근 권한을 획득하는 것도 가능하다. 공격자는 등록 요청 내의 pubKey와 AAID 필드를 자신이 소유한 디바이스의 정보로 교체하여 서버에 전송함으로써, 이후 자신의 개인 키를 사용해 정당한 사용자로 가장할 수 있다.

4.1.2 호스트명 검증 비활성화

이전 항에서 논한 인증서 신뢰 체인 검증 미흡 취약점 외에도, 애플리케이션 내에서 호스트명 검증을 비활성화하는 또 다른 서드파티 SDK 코드가 추가로 식별되었다. Fig. 13은 FIDO 등록 및 인증 과정에서 서버와의 HTTP 통신을 담당하는 Curl 클래스의 일부를 나타낸다. 해당 클래스의 createHttpsClient() 메서드 내부에서 SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER가 호출되는 것을 확인할 수 있으며, 이로 인해 SSLhandshake 과정에서 호스트명 검증이 수행되지 않는다. 즉, 공격자는 자신이 소유한 도메인에 대해 발급받은 유효한 인증서를 제시하는 것만으로도 통신을 지속할 수 있다. 따라서 공격자가 DNS spoofing과 같은 공격 기법을 통해 요청을 가로챌 경우, 호스트명 불일치로 인한 연결 차단 없이 중간자 공격을 수행하는 것이 가능하다.

Fig. 13. createHttpsClient() Method Disabling Hostname Verification

기술적인 관점에서 이러한 취약점은 앞서 논의한 인증서 신뢰 체인 검증 미흡 취약점에 비해 공격 성립 조건이 상대적으로 까다롭다. 모든 인증서 검증이 비활성화된 경우 공격자는 제약없이 어떠한 인증서라도 사용할 수 있으나, 호스트명 검증만이 비활성화된 경우에는 유효한 CA 서명을 포함한 인증서가 필수적으로 요구되기 때문이다.

4.2 서버 측 취약점

본 절에서는 정부24의 FIDO 인증 API에서 발생한 KVE-2025-0876을 분석한다. 해당 API는 4장 1절에서 분석한 정부24 모바일 애플리케이션의 지문 인식을 대역 외 인증 방식으로 활용하며, 웹브라우저에서 QR 코드 스캔을 통해 이를 호출하는 구조를 사용한다. 확인된 취약점의 유형은 3장 2절 1항에서 분류한 인증 절차와 세션 발급의 불완전한 연계로 인한 세션 탈취와 3장 2절 5항에서 분류한 세션 바인딩 미흡으로 인한 세션 탈취에 해당한다. 또한 해당 취약점은 CWE-304[16], CWE-807[17]로 분류할 수 있다.

FIDO 프로토콜은 접근 제어의 핵심 요소인 인증을 담당하므로, 서버 측 구현에서 오류가 발생할 경우 서비스 전반의 보안성에 중대한 영향을 미칠 수 있다. 특히 FIDO 인증 구현 과정에서 가장 주의가 요구되는 서버 측 취약점은 3장 2절 1항에서 논의한 인증 절차와 세션 발급의 연계 문제이다. 해당 취약점은 FIDO 프로토콜 자체의 범위에는 포함되지 않기 때문에 구현 과정에서 간과되는 경우가 많으나, 실제로는 완전한 인증 우회로 이어질 가능성을 내포하고 있다. 아울러 인증 절차에서 3장 2절 5항과 같이 세션 바인딩을 검증하지 않는 경우 또한 실무 환경에서 반복적으로 관찰된다. 이러한 취약점이 실제 서비스 환경에서 어떠한 형태로 발현되는지는 다음과 같다.

4.2.1 평문 식별자 반사를 통한 인증 우회

취약점이 존재하는 API에서는 모바일 애플리케이션에서 수행된 지문 인증 결과를 웹 브라우저로 전달하는 과정에서 자체 구현된 폴링 절차가 사용되고 있음이 확인되었다. 정상적인 FIDO 기반 대역 외 인증 구조에서는 서버가 인증 완료 시점에 공격자가 추측하기 어려운 임시 토큰이나 난수를 반환하고, 이를 기반으로 세션 발급이 이루어지도록 설계되어야 한다. 그러나 해당 서비스에서는 애플리케이션에서 인증이 성공한 경우 사용자명을 반환하고, 이를 이용해 세션 발급이 가능하도록 구현되어 있다.

Fig. 14는 이러한 취약점의 원인이 되는 클라이언트 측 코드를 나타낸다. checkFidoLoginStatus 함수에서 확인할 수 있듯이, 웹브라우저는 setInterval을 이용해 1초 간격으로 서버에 인증 상태를 질의한다. 애플리케이션에서 인증이 성공한 경우(resultCode === “100000”), 서버는 사용자명에 해당하는 loginId를 응답 데이터인 resultInfo에 포함하여 웹 브라우저로 반환한다. 이후 웹 브라우저는 서버로부터 수신한 userId를 별도의 암호화나 서명 없이 요청 본문에 포함시켜 다시서버로 전송한다. 문제의 핵심은 서버가 이러한 반사된 요청을 처리하는 방식에 있다. 서버는 로그인 요청을 수신하였을때, FIDO 표준에 따라 전자서명의 존재 여부를 검증하지 않고, 웹 브라우저가 전달한 userId가 데이터베이스에 존재하는 유효한 계정인지만을 확인한 후 세션을 발급한다.

Fig. 14. Client Side Logic Replaying userId

이로 인해 Fig. 15 및 Fig. 16과 같은 요청 및 응답이 발생한다. Fig. 15에서는 서버로 전송되는 값이 userId, lgnTypeCd, verifyType으로 구성되어 있으며, 해당 요청에 전자서명 값이 포함되지 않았음을 확인할 수 있다. Fig. 16에서는 “Login Successful” 메시지와 함께 세션 쿠키가 할당되는 것을 확인할 수 있다. 이는 서버가 userId의 존재 여부만을 기준으로 세션을 발급함을 의미한다.

이러한 구조를 악용할 경우 공격자는 다음과 같은 공격을 수행할 수 있다. 첫째, userId에 대한 무차별 대입 공격을 통해 다수의 사용자 세션을 획득할 가능성이 존재한다. 이 과정에서 별도의 인증 검증 절차가 요구되지 않으므로 공격 자동화 또한 용이하다. 둘째, 사용자명은 공개적인 소셜 네트워크 서비스를 포함한 여러 플랫폼에서 동일하게 사용되는 경우가 많아, 공격자가 사회공학적 기법을 통해 특정 사용자의 userId를 확보할 가능성 또한 배제할 수 없다. 셋째, 4장 1절 1항에서 분석한 취약점과 결합할 경우, 중간자 공격을 통해 사용자명을 획득한 뒤 이를 이용해 세션을 발급받는 공격도 가능하다. 이 경우 트래픽이 폐기되지 않으므로 사용자의 인증 절차에는 가시적인 이상이 발생하지 않으며, 공격자는 사용자가 이를 인지하지 못한 상태에서 세션을 탈취할 수 있다.

Fig. 15. HTTP Request Reflecting Plaintext userId

Fig. 16. HTTP Response Issuing JSESSIONID

결과적으로 이러한 구조는 서비스 사용자 전체를 대상으로 하는 대규모 계정 탈취로 확장될 수 있다. 특히 해당 취약점이 발견된 서비스가 방대한 개인정보를 통합 관리하는 국내 전자정부 서비스라는 점은 잠재적 위험의 범위를 크게 확장시킨다. 공격자는 민감한 신원 정보를 열람할 수 있을 뿐만 아니라, 공문서 부정 발급이나 허위 민원 신청과 같은 행정행위까지 수행할 가능성이 존재하며, 이는 정보 유출을 넘어 명의 도용이나 금융 사기와 같은 2차 피해로 이어질 수 있는 심각한 보안 공백을 시사한다.

4.2.2 세션 바인딩 부재

4장 2절 1항에서 기술한 공격 시나리오가 성립하는 주요 원인 중 하나는 세션 바인딩이 구현되어 있지 않다는 점에 있다. 설령 클라이언트가 userId를 반사하여 서버로 전송하고 서버가 이를 검증하지 않는 구조를 갖고 있더라도, 서버가 인증 시작 시 발급한 임시 식별자를 기반으로 요청간의 종속성을 검증하였다면 이러한 인증 우회는 쉽게 성립하기 어렵다.

정상적인 보안 아키텍처에서는 인증 절차가 시작되는 시점에 클라이언트에 고유한 임시 식별자를 부여하고, 인증 완료 후 세션 발급 시 해당 식별자의 유효성을 검증한다. 이와 같은 구조에서는 공격자가 외부에서 요청을 위조하더라도, 사용자의 브라우저에 할당된 임시 식별자를 보유하지 않는 한 서버가 이를 비정상적인 접근으로 판단하고 차단할 수 있다.

Fig. 15를 통해, 요청에서 임시 JSESSIONID를 포함한 모든 쿠키 값을 의도적으로 제거하였음에도 불구하고 서버가 요청을 정상 처리함을 확인할 수 있다. 이로 인해 공격자는 앞선 논리적 결함을 실질적인 인증 우회 취약점으로 악용할 수 있는 환경을 확보하게 된다.

V. FIDO 구현 가이드라인

앞선 4장의 사례 분석을 통해, 국가 단위의 대규모 인증 시스템에서도 구현 단계의 취약점이 서비스 전체의 신뢰성을 저해하는 치명적인 결함으로 이어질 수 있음을 실증하였다. 이에 본 장에서는 3장에서 정립한 구현 취약점 분류 체계를 바탕으로, FIDO 인증 기능을 서비스에 도입하는 개발자가 구현 단계에서 준수해야 할 필수 보안 통제 항목을 도출한다. 본 논문에서는 장황하게 가이드라인을 서술하는 방식을 피하고, 개발자의 인지적 부담을 최소화하여 현장에서 즉시 활용 가능하도록 Table 2의 체크리스트 형태로 집약하여 제시한다. 체크리스트의 각 항목은 3장에서 제시한 취약점 유형의 해결책에 해당한다. 가령, C-1은 3장 1절 1항의 취약점에 대한 해결책이며, S-1 및 S-2는 3장 2절 1항에 대응된다. 본 가이드라인을 참고하는 것만으로 FIDO 프로토콜 및 인증 시스템 전반의 모든 잠재적 취약점을 차단하기에는 한계가 있으나, 실무 운영 환경에서 보안 사고로 직결될 수 있는 주요 구현 결함을 적은 비용으로 예방하고 전반적인 보안 수준을 제고하는 데 기여할 수 있을 것으로 기대한다.

Table 2. Implementation Security Requirements Checklist for FIDO Integration

VI. 결론

본 연구는 FIDO 인증 체계를 클라이언트 측과 서버 측이 상호 의존적으로 결합된 종단 간 구현체로 정의하고, 실제 서비스 환경에서 발생 가능한 구현 취약점을 체계적으로 유형화하였다. 이는 실제 구현 단계에서 발생하는 보안 간극을 진단할 수 있는 기틀을 마련하였다는 점에서 독자적인 의의를 갖는다.

다만 본 연구에서 제시한 가이드라인은 FIDO 프로토콜이 전제하는 이론적 안전성이 유지된다는 가정하에서 유효하다. 즉, 본 연구의 목적은 FIDO 인증구현 실패로 인한 보안성 붕괴를 예방하기 위한 기준을 제시하는 데 있으며, 프로토콜 자체의 안전성을 보완하는 데까지는 이르지 못한다는 한계를 지닌다.

그럼에도 불구하고 본 연구는 정부24와 같은 대규모 공공 서비스에서도 FIDO 인증 구현 단계의 사각지대가 치명적인 보안 위협으로 작용할 수 있음을 실증적으로 보이고, 이를 완화하기 위한 실무적인 가이드라인을 도출하였다는 점에서 실질적인 기여를 제공한다.

향후 연구로는 본 연구에서 제시한 취약점 분류와 가이드라인을 기반으로 특정 산업 분야에 특화된 기술 백서를 작성하여 배포하거나, 다수의 서비스에 적용 가능한 자동화 도구를 개발하는 방향으로의 확장이 가능할 것이다.