기기 종속 패스키 vs. 동기화 패스키 (SCA 및 패스키 1부)

개요: 패스키를 활용한 강력한 고객 인증 (SCA)#

• PSD2 및 SCA 요구 사항 분석
• SCA 요구 사항이 패스키에 미치는 의미
• PSD3 / PSR이 패스키에 미치는 영향

1. 서론: 기기 종속 패스키 vs. 동기화 패스키#

이전 패스키 PSD2 관련 블로그 게시물에서, 우리는 Revolut 및 Finom과 같은 핀테크 기업들이 이미 패스키를 도입하여 뱅킹의 디지털 보안을 어떻게 개선하고 있는지 논의했습니다.

패스키는 크게 두 가지 형태로 제공됩니다. **동기화 패스키(synced passkeys)**와 **기기 종속 패스키(device-bound passkeys)**입니다. 동기화 패스키는 사용자가 여러 기기에서 원활하게 인증할 수 있도록 지원하는 반면, 기기 종속 패스키는 하드웨어 보안 키나 로컬 인증자와 같은 패스키 기기에 엄격하게 연결됩니다.

이 4개의 블로그 게시물 시리즈를 통해, 다양한 유형의 패스키(기기 종속 vs. 동기화)가 SCA 및 PSD2 요구 사항을 어떻게 준수하는지 심층적으로 분석하고자 합니다.

이 시리즈의 첫 번째 파트에서는 기기 종속 패스키와 동기화 패스키의 차이점을 이해하는 데 중점을 둡니다.

두 번째 파트에서는 PSD2와 강력한 고객 인증(SCA)이 무엇을 의미하는지 역사적 발전 과정을 포함하여 이해하기 쉽게 설명합니다.

세 번째 파트에서는 다양한 유형의 패스키가 어떻게 SCA를 준수하는지, 그리고 이것이 패스키 도입을 고려하는 은행, 핀테크 및 금융 기관에 어떤 의미를 갖는지 보여줍니다.

마지막 네 번째 파트에서는 향후 PSD3 및 PSR이 SCA와 패스키에 미칠 영향을 결론지으며 마무리합니다.

2. 강력한 고객 인증, PSD2 및 패스키#

지난 블로그 게시물이 발행된 후, PSD2 프레임워크 하의 SCA와 관련하여 패스키에 대한 당사의 입장을 묻는 후속 질문을 많이 받았습니다. 패스키의 적용뿐만 아니라 패스키가 **RTS(규제 기술 표준)**와 어떻게 부합하는지에 대한 관심이 높습니다. 또한 이해관계자들은 패스키 사용에 대한 **유럽은행감독청(EBA)**을 포함한 규제 당국의 잠재적 해석 및 지침에 대해 궁금해하고 있습니다.

이를 인식하여, 당사는 패스키가 PSD2 지침, SCA에 대한 RTS 내에 어떻게 통합될 수 있는지 심층적으로 살펴보고, 이 기술의 사용에 대한 당사의 입장을 명확히 하고자 합니다. 또한 기존 EBA 질문 및 답변을 탐색하여 규제 당국과 EBA가 패스키를 어떻게 인식할 수 있는지 조명할 것입니다. 이러한 검토는 동기화 패스키와 기기 종속 패스키 간의 차이점뿐만 아니라, 보안 및 사용자 경험 모두를 향상시키는 실질적인 적용 사례까지 다룰 것입니다.

이러한 뉘앙스를 이해함으로써, 이해관계자들은 PSD2의 엄격한 요구 사항을 준수할 뿐만 아니라 최신 인증 기술을 활용하여 디지털 거래를 안전하게 보호하는 정보에 입각한 결정을 내릴 수 있습니다. 이번 논의의 목적은 디지털 환경의 발전에 맞춰 보안 조치가 뒤처지지 않도록 인증 프로세스에 패스키를 통합하는 방향을 더욱 밝히는 것입니다.

물론 PSD2의 규제를 받는 모든 기관은 규제 목표를 달성하는 방법에 대해 자체적인 결정을 내려야 합니다. 각 구현마다 고유한 복잡성이 존재하기 때문입니다. 이러한 개별적 접근 방식은 규제 프레임워크가 통일된 표준을 제공하더라도, 각 조직의 고유한 운영 환경, 기술 역량, 사용자 기반에 따라 실제 적용 방식은 크게 달라질 수 있음을 인정하는 것입니다.

따라서 당사의 통찰력은 지침과 정보를 제공하는 것을 목표로 하지만 절대적인 규정은 아닙니다. 각 기관은 보안 및 인증 프로토콜에 패스키를 통합할 때 구체적인 상황과 과제를 고려해야 합니다.

3. 기기 종속 패스키에서 동기화 패스키로의 변화#

기기 종속 패스키와 동기화 패스키의 차이를 이해하기 위해 생태계가 어떻게 발전해 왔는지 간략히 살펴보겠습니다.

3.1 기기 종속 패스키(단일 기기 패스키)란 무엇인가요?#

기술적인 세부 사항을 살펴보기 전에 먼저 기기 종속 패스키의 역사와 발전 과정을 살펴봅니다.

3.1.1 기기 종속 패스키의 역사#

역사적으로 WebAuthn(패스키의 기반이 되는 표준) 내의 인증 메커니즘은 YubiKey와 같은 하드웨어 보안 키라는 물리적 기기와 밀접하게 결합되어 있었습니다. 패스키가 널리 보급되기 전에는 단일 인증자에 종속된 FIDO2 자격 증명이 보안의 황금 표준(gold standard)으로 여겨졌습니다. 이러한 자격 증명은 자격 증명이 상주하는 기기에 연결됩니다. 이 종속의 의미는 컸습니다. 즉, 원래의 하드웨어 외부로는 자격 증명을 전송하거나 사용할 수 없었습니다.

이 방식은 단일 기기로 인증 프로세스를 국한하여 보안을 강화했지만, 특히 비기술적인 일반 소비자들 사이에서 광범위한 채택을 저해하는 실질적인 한계에 불가피하게 직면했습니다. 사용자는 모든 로그인 시도마다 자신의 인증 기기를 소지해야 했으며, 이는 사용자의 이동성을 제한할 뿐만 아니라 기기를 분실, 손상 또는 즉시 접근할 수 없는 상황에 대한 우려를 낳았습니다.

또한, 소비자들이 추가 하드웨어에 투자하는 것에 대한 거부감도 있었습니다. 역사적으로 일반 소비자들의 전용 보안 키 소유 및 사용률은 매우 낮았습니다. 보안 이점 향상에도 불구하고 인증 목적으로 전문 하드웨어를 구매한다는 전망은 B2C 사용자 대다수의 공감을 얻지 못했으며, 이들은 동시에 주로 광범위한 피싱 캠페인이나 크리덴셜 스터핑(credential stuffing) 공격의 대상이 됩니다.

3.1.2 기기 종속 패스키의 기술적 세부 사항#

기기 종속 패스키는 검색 가능(discoverable) 및 검색 불가(non-discoverable) 자격 증명으로 특정하게 분류된다는 특징이 있으며, 이러한 구분은 주로 검색 가능성을 정의합니다. 그러나 기기 종속 키를 구별하는 핵심 요소는 WebAuthn 자격 증명 속성, 특히 isBackupEligible 및 isBackupSynchronized 플래그에 요약되어 있습니다. 기기 종속 패스키의 경우 이 두 필드가 모두 0으로 설정되어 자격 증명이 기기 간 백업 또는 동기화 대상이 아님을 나타냅니다. 이러한 특성은 자격 증명이 생성된 물리적 기기와의 본질적인 연결을 강조하여 해당 자격 증명이 특정 하드웨어에 묶인 채 그곳에서만 사용될 수 있도록 보장합니다.

실제 기기 종속 자격 증명의 주목할 만한 예는 Windows 생태계에서 관찰됩니다. Windows 10 및 Windows 11의 Windows Hello 자격 증명은 기기 종속성을 유지합니다. 즉, Windows Hello 자체는 아직 기기 간 패스키를 동기화하지 않습니다. 하지만 Microsoft는 (Edge 142부터) Microsoft Edge에 패스키 저장 및 동기화 기능을 도입하여 중요한 첫걸음을 내디뎠습니다. Microsoft Password Manager를 통한 이 브라우저 수준 동기화는 Google Password Manager가 Windows의 Chrome 브라우저에서 패스키 동기화를 활성화하는 방식과 유사하게, Edge를 사용할 때 Windows 기기 간 패스키 동기화를 가능하게 합니다. 이는 Windows 패스키 기능에서 중요한 발전을 의미하지만, Windows Hello 플랫폼 인증자가 아닌 Edge 브라우저에 한정된 기능입니다. Windows Hello 패스키는 기기 종속성을 유지하지만, 이러한 Edge 통합은 Windows 상의 동기화 패스키를 향한 실용적인 경로를 제공하며 추후 플랫폼 인증자 자체가 동기화를 지원하도록 진화할 수 있습니다.

반면, Google은 검색 불가 패스키(non-discoverable passkeys)에 대한 명확한 입장을 밝히며 기존의 검색 불가 패스키가 향후 구현에서도 동기화되지 않은 상태로 유지될 수 있음을 시사했습니다. 이 결정은 검색 불가 자격 증명이 특정 보안 컨텍스트 내에서 엄격하게 기기에 종속된 상태로 남아야 하며, 검색 불가 특성으로 인해 패스키로 사용할 수 없다는 더 넓은 원칙과 일치합니다.

이와 대조적으로, macOS와 iOS에서 Apple이 취한 접근 방식은 크게 다릅니다. Windows 및 Google의 검색 불가 키에서 관찰되는 고정형 기기 종속 전략과 달리, Apple의 생태계는 특히 iOS에서 동기화 패스키만 허용하는 방향으로 훨씬 더 강하게 기울어져 있어 WebAuthn을 통한 기기 종속 패스키 생성을 불가능하게 만듭니다.

주요 플랫폼 전반에 걸친 전략의 세분화는 보안, 편의성, 사용자 접근성 간의 균형을 고려할 때 WebAuthn 자격 증명을 관리하는 다양한 접근 방식을 보여줍니다. 기기 종속 패스키가 의도한 기기 외부로 자격 증명이 이동되거나 악용되지 않도록 보장하여 높은 수준의 보안을 제공하는 반면, 업계는 사용자 경험과 이동성을 저하시키지 않으면서도 보안 표준을 유지하는 솔루션을 모색하며 지속적으로 진화하고 있습니다.

3.2 동기화 패스키(다중 기기 패스키)란 무엇인가요?#

여기서도 기술적 세부 사항을 분석하기 전에 동기화 패스키의 역사적 발전 과정을 살펴봅니다. 간혹 동기화 패스키는 **동기화 가능한 패스키(syncable passkeys)**로 불리기도 합니다.

3.2.1 동기화 패스키의 역사#

2021년 중후반에 WebAuthn Level 2 및 CTAP 2.1 사양이 공개된 후, WebAuthn 워킹 그룹은 WebAuthn 표준이 비밀번호를 대체하고 채택률을 높이는 능력을 저해하는 주요 장애물을 극복하기 위한 중요한 업계 이니셔티브를 시작했습니다. 이 이니셔티브는 두 가지 중요한 영역에 초점을 맞췄습니다. 추가 하드웨어 보안 기기에 대한 요구 사항을 제거하는 것과, 기존 표준과의 완벽한 하위 호환성을 유지하면서 인증자를 잃을 위험을 완화하는 것이었습니다.

3.2.1.1 플랫폼 인증자를 안전한 하드웨어 모듈로 활용#

새로운 하드웨어의 필요성을 제거하는 첫 번째 과제는 최신 소비자 기기(예: Touch ID, Face ID, Windows Hello)에 내장된 플랫폼 인증자를 활용함으로써 해결되었습니다.

최신 기기에는 Android의 Trusted Execution Environment(TEE), iOS 및 macOS의 Secure Enclave, Windows 기기의 Trusted Platform Module(TPM)과 같은 특수 보안 모듈이 점점 더 많이 장착되고 있습니다. 이러한 통합 보안 키 저장소는 패스키의 강력한 기반 역할을 하여 효과적으로 내장형 "보안 키"로 작동합니다. 이 접근 방식을 통해 이전에는 외부 하드웨어 보안 키(예: YubiKeys)를 통해서만 달성할 수 있었고 기술에 정통한 개인이나 규제가 심한 산업 분야의 조직으로 주로 제한되었던 공개 키 암호화(public key cryptography) 수준 보안의 광범위한 채택이 가능해졌습니다.

TEE, Secure Enclave 또는 TPM의 기능을 활용하여 WebAuthn 프로토콜은 강력한 암호학적 사용자 인증 메커니즘을 제공할 수 있게 되었습니다. 이제 추가적이고 특수한 하드웨어 없이도 정교한 인증 방법이 사용자 친화적으로 일반 대중에게 제공될 수 있게 되었습니다.

이러한 발전은 디지털 보안 접근 방식에서 매우 강력한 진전으로, 광범위한 채택을 주도하는 사용자 중심 보안 솔루션의 중요한 역할을 강조합니다. 동기화 패스키를 최적화된 패스키 생성 및 패스키 로그인 흐름과 결합하는 조직은 가장 높은 채택률을 보여줍니다. 최신 기기의 보안 기능을 사용함으로써, 이 산업 노력은 외부 하드웨어의 필요성을 제거하는 초기 장애물을 성공적으로 해결했습니다.

이러한 개발은 공개 키 암호화의 광범위한 적용이 다양한 사용 사례에 직접적으로 적용되는 동시에 사용자의 인증을 단순화하는 디지털 인증 생태계의 새로운 시대에 중요한 발판이 되었습니다.

3.2.1.2 패스키의 클라우드 동기화#

휴대전화와 기기 내에 저장된 패스키 분실에 따른 위험을 해결하기 위해, 업계 이니셔티브는 클라우드로 검색 가능 자격 증명을 동기화하는 기능을 지원하는 데 주력했습니다. 이 접근 방식은 자격 증명을 엄격한 기기 종속 형태에서 다중 기기 형태로 전환했으며, 더 정확하게는 Apple 기기의 iCloud 또는 Android 기기의 Google과 같은 클라우드 공급자의 사용자 계정에 종속시켰습니다.

이러한 실용적인 솔루션은 사용자가 전화를 분실하거나 교체하더라도 이전에 설정한 자격 증명이 영구적으로 손실되지 않음을 의미했습니다. 대신 사용자의 클라우드 계정에서 이러한 자격 증명을 검색하여 새 기기에 동기화할 수 있었습니다. 이러한 전환은 물리적 인증자 분실과 관련된 불편함과 보안 위험을 크게 감소시켰습니다.

클라우드 동기화를 활용하여 이제 패스키는 사용자의 기기 간에 원활하게 전환되며 사용 중인 특정 기기에 관계없이 무결성과 보안을 유지할 수 있습니다. 예를 들어, 사용자가 새 기기에서 웹사이트에 로그인할 때 클라우드 계정에 있는 자격 증명이 인증을 위해 자동 제안될 수 있습니다. 필요한 경우 이러한 자격 증명은 새 기기로 전송되어 여러 플랫폼 및 기기 전반에서 일관되고 안전한 인증 경험을 유지할 수 있습니다.

클라우드 동기화 계정 종속 자격 증명으로의 전환은 디지털 보안에 대한 실용적인 접근 방식을 나타냅니다. 이는 분실, 손상, 업그레이드 등 최신 기기 사용의 현실과 기기 교체가 흔히 일어난다는 점을 인지합니다. 자격 증명을 사용자의 클라우드 계정(Apple의 iCloud이든 Google의 클라우드 서비스이든)에 바인딩함으로써, 이 솔루션은 기기 분실과 관련된 위험을 완화할 뿐만 아니라 다수의 기기에서 자신의 디지털 ID를 관리하고 복구하는 사용자의 능력을 향상시킵니다.

이러한 개발은 사실상 WebAuthn의 강력한 암호화 인증 메커니즘의 적용 범위를 넓혀 현실 세계의 사용자 시나리오에 더욱 잘 적응하도록 만듭니다. 또한 강력한 인증이 기술적 배경을 가진 사람이나 규제가 심한 산업에 속한 사람뿐만 아니라 여러 대의 기기를 들고 디지털 세계를 탐색하는 일반 사용자들도 접근하고 관리할 수 있도록 보장합니다.

3.2.2 동기화 패스키의 기술적 세부 사항#

동기화 패스키는 검색 가능 자격 증명(discoverable credentials) 또는 상주 키(resident keys)라고도 합니다. 이들은 isBackupEligible과 isBackedUp이라는 두 가지 중요한 속성 값을 통해 기기 종속 키와 구별됩니다. 동기화 패스키의 경우 isBackupEligible 플래그가 1로 설정되어 해당 자격 증명이 백업 대상임을 나타냅니다. 클라우드로 성공적으로 동기화되면 isBackedUp 플래그 또한 1로 설정되어 자격 증명이 제대로 동기화되었음을 확인합니다. 동기화 상태는 기기 사용 및 관리의 동적인 특성을 반영하여 시간이 지남에 따라 변할 수 있다는 점에 유의하는 것이 중요합니다.

플랫폼이 "requireResidentKey" 매개변수를 required 또는 preferred로 설정하여 상주 키를 요청할 때, 클라우드 서비스를 지원하는 플랫폼은 자동으로 동기화 패스키를 생성합니다. 이 과정은 사용자가 여러 기기에서 자격 증명에 접근할 수 있도록 보장합니다. Windows의 경우 동기화 패스키는 현재 Microsoft Edge/Microsoft Password Manager를 통해 제공되며(브라우저 수준 동기화), Windows Hello 플랫폼 인증자 자격 증명은 기기 종속으로 남습니다. 패스키 관리 기능이 있는 서드파티 비밀번호 관리자(예: Dashlane, KeePassXC, 1Password)도 플랫폼 간 동기화를 제공합니다. 동기화 패스키가 사용되는 시나리오에서는 isBackupEligible과 isBackedUp 플래그가 1로 설정되어 백업 자격 및 성공적인 동기화를 나타냅니다.

또한 현재는 패스키가 저장된 특정 인증자를 식별하는 것이 여전히 가능하지만, 대다수의 이러한 자격 증명에 대한 증명(attestation)이 없다는 것은 암호학적으로 그 출처를 검증할 수 없음을 의미합니다. 이 측면은 WebAuthn의 표준 메커니즘만으로는 동기화 패스키의 보안 혈통(security pedigree)을 완벽히 보장하는 데 잠재적 한계가 있음을 부각시킵니다.

동기화 패스키의 이러한 발전은 본질적으로 클라우드 기반 동기화 프레임워크에 통합됨으로써 검색 가능 자격 증명의 범위를 넓힙니다. 이러한 키를 백업 가능하게 만들고 사용자의 기기 전반에 걸친 동기화를 보장함으로써 WebAuthn은 디지털 인증의 두 가지 주요 과제인, 기기 분실로 인한 액세스 권한 상실 위험과 다수의 기기 종속 자격 증명 관리에 따르는 불편함을 해결합니다.

3.3 더 큰 이익을 위해 희생된 WebAuthn 자격 증명의 단일 기기 종속성#

기기 종속 패스키에서 동기화 패스키로의 전환은 고급 보안 조치의 필요성, 수반되는 법적 문제, 그리고 소비자 친화적이면서도 안전한 타협점을 중심으로 WebAuthn 워킹 그룹 내에서 중요한 논의의 시작점이 되었습니다.

동기화 패스키 채택은 클라우드 동기화와 원활한 다중 기기 기능 같은 특징을 통해 사용자 편의성과 보안을 향상시킨다는 약속으로 환영받았습니다. 하지만 강화된 요구 사항이 있는 환경에서의 보안 및 컴플라이언스 영향에 관해 일부 신뢰 당사자(Relying Parties, RP)에게 어느 정도 불편함을 초래했습니다. 토론의 핵심은 동기화 패스키라도 특정 기기와의 연결이 유지되도록 보장하는 메커니즘의 필요성이었으며, 이 개념은 민감한 트랜잭션을 다루거나 엄격한 규제 표준에 따라 운영되는 신뢰 당사자에게 매우 중요합니다.

패스키를 채택할 수 없거나 채택하기 꺼려하는 RP에게 중요한 애플리케이션에서 자격 증명을 특정 기기에 확실하게 바인딩할 수단이 부재하다는 점은 큰 과제를 제기했습니다. 이러한 메커니즘은 일부 RP에게 대단히 중요하게 여겨졌습니다. 이런 기기 종속 기능의 부재는, 명시적으로 선언되지 않았을지라도 확실히 기대되었던 바로서 그들의 관점에서는 심각한 놀라움이자 신뢰의 위반으로 받아들여졌습니다.

결과적으로 이해관계의 조화가 이뤄져야 하지만, 당분간은 패스키 확산이라는 대의(greater good)가 우선시되어야 한다는 결론이 도출되었습니다. 토론 과정에서 devicePubKey 확장(extension)이 이러한 우려를 해결할 수 있는 한 가지 방법으로 간주되었으나, 추후 훨씬 광범위한 접근 방식을 취하는 supplementalPubKeys로 대체되어 현재의 WebAuthn Level 3 초안에 반영되었습니다. 하지만 안타깝게도 이 접근 방식 또한 2024년 8월에 중단되었습니다.

3.4 두 세계의 장점 결합: 패스키와 supplementalPubKeys 확장 [2024년 8월부로 중단]#

supplementalPubKeys 확장을 통한 타협안이 어떻게 형성되었으며 기술적으로 무엇을 의미하는지 분석해 보겠습니다.

3.4.1 devicePubKey에서 supplementalPubKeys 확장으로#

devicePubKey 확장 프로그램에서 supplementalPubKeys 확장 프로그램으로의 전환에 대한 논의는 WebAuthn 사양의 역동적인 특성을 강조합니다. 초기에 devicePubKey는 기기에 종속된 공개 키를 통해 보안을 강화하는 역할을 했지만 나중에 WebAuthn Level 3 Editor's Working Draft의 supplementalPubKeys 제안으로 대체되었습니다. 이 새로운 확장 프로그램은 인증 프로세스를 강화하기 위해 여러 키를 허용함으로써 보다 포괄적인 솔루션을 제공합니다.

토론의 핵심은 강화된 보안 조치와 다양한 기기 및 플랫폼 전반의 패스키에 대한 광범위한 채택 및 실질적 효용의 균형을 맞추는 데 있었습니다. supplementalPubKeys 확장 프로그램은 엄격한 인증을 가능하게 하여 이러한 우선순위의 결합을 나타냅니다. 예를 들어 증명 구문(attestation statements)이 있는 추가 "하위 키(sub-keys)"를 허용하여 특정 인증 표준을 요구하는 규정을 수용합니다. 이러한 키는 인증 요구 사항 준수를 알리며, 잠재적으로 특정한 상황에서는 (패스키를 포함하더라도) 추가 로그인 시도 과제의 필요성을 줄여 줍니다.

WebAuthn 초안에서 직접 발췌한 예:

"이전에 사용자 계정에서 확인되지 않은 특정 지리적 위치 신호가 있고 계정에 관찰된 일반적인 사용 시간을 벗어난 로그인 요청이 웹 사이트에 나타난다고 가정합니다. 다중 기기 자격 증명의 단독 증명이 있더라도 요청을 허용하지 않을 만큼 위험도가 높다고 판단될 수 있습니다. 그러나 기기 종속적이고 이 사용자에 대해 잘 설정된 추가 키의 서명도 함께 제시할 수 있다면 균형이 기울어질 수 있습니다."

토론 과정에서 이 확장은 매우 높은 보안 요구 사항을 갖는 RP(예: 정부 부문)만을 위한 것이라는 점이 강조되었습니다.

피드백을 통합하고 특정 사용 사례(규제된 금융 거래 및 다중 기기 자격 증명 환경에서의 기기 종속 신호 필요성 포함)를 해결함으로써 WebAuthn 커뮤니티는 보안과 상호 운용성 문제를 모두 해결하고자 했습니다. 따라서 supplementalPubKeys 확장 프로그램은 패스키의 광범위한 채택에 필수적인 원활한 사용자 경험과 광범위한 호환성을 지원하면서도 견고한 보안 기능을 제공하기 위한 접근 방식입니다. 이는 지난 2년 동안 이미 볼 수 있었던 패스키 구현을 방해하지 않는 완전히 선택적인 확장 프로그램입니다.

더 포괄적이고 유연한 프레임워크를 향한 이러한 발전은 엄격한 사용 사례에 이르기까지 웹 인증 방법을 개선하려는 WebAuthn 커뮤니티의 노력을 강조합니다.

3.4.2 supplementalPubKeys의 기술적 세부 사항#

WebAuthn에 도입된 supplementalPubKeys 확장은 기본 자격 증명과 함께 추가 키 쌍의 사용을 허용합니다.

원본 GitHub 이슈에서 발췌

이 이미지는 원본 GitHub 이슈에서 발췌한 supplementalPubKey의 개념을 보여줍니다(pk = passkey, pspk = provider supplemental key, dspk = device supplemental key).

작동 방식 및 목적에 대한 분석은 다음과 같습니다:

supplementalPubKey의 목적 및 기능

• 중앙 집중식 패스키 유지: 중앙 집중식 패스키 한 개가 주 사용자 인증 수단으로 유지되고 추가 키가 추가적인 보안 계층과 보증을 제공한다는 점을 기억하는 것이 중요합니다. 이 구조는 여러 기기 전반에 걸친 단일 핵심 패스키의 간단함과 효율성을 유지하여 원활한 사용자 경험을 보장합니다. 동시에 추가 키는 인증 컨텍스트를 강화하여 보안 환경이나 특정 인증 표준의 준수에 대한 추가적인 신호를 신뢰 당사자(RP)에게 제공합니다. 이러한 보조 키는 독립형 인증 방법이 아니라 기본 패스키를 보강하여 기기 무결성에 대한 증거로 기본 패스키의 신뢰성을 강화합니다.
• 기기 종속 키(Device-Bound Keys): 특정 기기에 종속되어 있습니다. 인증 요청이 이전에 인증된 신뢰할 수 있는 기기에서 온 것이라는 보증을 제공할 수 있습니다. 어떤 환경에서도 동기화되지 않습니다.
• 공급자 종속 키(Provider-Bound Keys): 공급자 범위를 갖는 키로 인증 공급자의 정책이나 공급자의 특정 증명에 기반한 추가적인 보증을 제공할 수 있습니다. 예를 들어, 사용자가 더 높은 수준의 인증(예: 2FA)을 마친 후에만 공급자가 발급할 수 있습니다.
• 다중 공개 키(Multiple Public Keys): 기기 종속 공개 키 하나만 허용했던 전신인 devicePubKey 확장 프로그램과 달리 supplementalPubKeys는 하나 또는 두 가지의 추가 키 유형을 포함할 수 있도록 합니다. 이 키들은 다양한 목적과 범위, 즉 기기 종속 및 공급자 종속 범위를 포괄할 수 있습니다.

supplementalPubKey의 사용 사례 및 예시

1. 보안 강화(Enhanced Security): 웹 사이트(신뢰 당사자)가 인증에 대해 특정한 강화된 보안 표준을 고수해야 하는 상황에서 추가 키를 사용해 이러한 요구 사항을 충족할 수 있습니다. 이러한 추가 키를 이전에 사이트에서 보고 확인했다면, 이전 신호를 통해 기기 지속성을 확인할 수 있으므로 사용자는 추가적인 로그인 검증 과제를 생략할 수 있습니다.
2. 위험 관리(Risk Management): 새로운 지역이나 이상한 시간에 발생한 것처럼 위험해 보이는 로그인 요청의 경우, 사용자 계정에 사용 이력이 있는 기기 종속 보조 키가 있으면 인지된 위험이 낮아져 자칫 차단될 수 있었던 요청의 진행이 허용될 수 있습니다.

supplementalPubKey의 기술적 측면

• 고유 자격 증명 ID 없음(No Own Credential ID): 추가 키는 사용자 자격 증명이 아니며 별도의 자격 증명 ID를 갖지 않습니다.
• 증명 구문(Attestation Statements): 추가 키에는 선택 사항으로 증명을 포함할 수 있습니다. 증명은 추가 키의 범위와 보안 수준을 이해하는 데 매우 중요합니다. 하드웨어 종속 키가 제공하는 보호 수준 또는 기타 유형의 추가 키에 대한 정책을 나타낼 수 있습니다.
• 신뢰 당사자 구현(Implementation for Relying Parties): 신뢰 당사자는 인증 프로세스의 일부로 이러한 보조 키를 요청할 수 있습니다. 그러나 여러 키와 증명 구문을 다루는 것은 복잡하기 때문에 이 확장은 은행이나 엄격한 규제 요건 하에 운영되는 서비스와 같은 특정 보안 요구 사항을 갖춘 단체에 가장 적합합니다.

2024년 4월 기준으로 supplementalPubKeys 확장 프로그램은 주요 브라우저에서 채택되지 않았으며, WebAuthn Level 3 사양은 여전히 개발 중이고 변경될 수 있다는 점을 유념해야 합니다. 현재로서는 Editor's Draft(편집자 초안)에만 있기 때문에 이 기능이 사양의 최종 버전 안에 포함될지, 그리고 향후 구현 및 채택의 가능성이 어떠할지는 불확실합니다.

3.4.3 2024년 8월 supplementalPubKeys 중단#

2024년 8월 기준으로 supplementalPubKeys 확장 프로그램이 공식적으로 중단되었습니다. WebAuthn 워킹 그룹은 지원 부족을 이유로 이 기능을 제거하기로 결정했습니다. 이 확장의 중단은 또한 새로운 방향을 제시합니다. 현재 FIDO Alliance는 엄격한 보안 요구 사항을 가진 **신뢰 당사자(Relying Parties)**를 지원하기 위한 다른 접근 방식을 개발하고 있습니다. 다가오는 이 새로운 솔루션은 supplementalPubKeys의 중단으로 생긴 격차를 메우고, 엄격한 보안 표준이 핵심인 시나리오에서 인증 프로세스를 더욱 강화할 수 있는 새로운 방법을 제공할 것으로 기대됩니다.

중단과 관련된 더 자세한 내용은 공식 WebAuthn GitHub 풀 리퀘스트(pull request)에서 확인할 수 있습니다.

4. Corbado가 실무에서 기기 종속 패스키와 동기화 패스키의 차이를 다루는 방법#

기기 종속 패스키와 동기화 패스키의 차이를 이해하는 것이 필수적이지만, 은행들은 이러한 차이를 규모에 맞게 실무에 적용할 도구도 필요합니다. Corbado의 플랫폼은 패스키 유형을 자동으로 분류하고 각 유형에 올바른 SCA 처리를 적용하는 기기 신뢰도(device trust intelligence) 인텔리전스를 제공합니다.

패스키 유형 전반의 기기 신뢰도 가시성#

Corbado의 기기 신뢰도 대시보드는 프로덕션 환경에서 기기 종속 패스키와 동기화 패스키가 어떻게 다른 성능을 보이는지 보여줍니다. 기기 종속 패스키는 스텝업(step-up) 요구 없이 더 높은 성공률(99.1%)을 달성하는 반면 기기 신뢰도 신호가 포함된 동기화 패스키는 새로운 기기에서 낮은 스텝업 비율을 보이며 98.4%에 도달합니다.

대시보드는 또한 기기 분류를 추적합니다. 일반적인 뱅킹 배포의 92%는 한 사용자 전용인 기기로 파악되며 두 명의 사용자가 공유하는 기기는 7%, 공유/키오스크 기기는 0.8%로 나타납니다. 이러한 분류는 직접 SCA 준수 결정을 위한 기반이 됩니다.

다양한 패스키 시나리오를 위한 정책 기반 제어#

모든 패스키를 똑같이 취급하는 대신 Corbado의 신뢰 정책(trust policies)은 은행이 패스키 유형, 기기 상태 및 신뢰 수준에 따라 다양한 규칙을 적용할 수 있게 합니다. 이미 알려진 기기에서의 기기 종속 패스키는 마찰 없는(frictionless) 인증을 거치게 되며 새로운 기기에서의 동기화 패스키는 스텝업 검증을 트리거합니다. 이것이 바로 PSD2의 SCA 프레임워크가 요구하는 섬세한 접근 방식입니다.

이는 은행이 고도 보안 시나리오를 위해 기기 종속 패스키가 제공하는 엄격한 기기 통제를 유지하면서도 보다 나은 사용자 경험을 제공하고자 동기화 패스키를 자신 있게 배포할 수 있음을 의미합니다. 이러한 모든 설정은 별도의 인증 흐름이 아닌 정책 구성을 통해 관리됩니다.

Corbado 소개

Corbado는 대규모로 consumer authentication을 운영하는 CIAM 팀을 위한 Passkey Intelligence Platform입니다. IDP 로그와 일반 analytics 도구가 보여주지 못하는 것을 볼 수 있게 해드립니다: 어떤 디바이스, OS 버전, 브라우저, credential manager가 passkey를 지원하는지, 왜 등록이 로그인으로 이어지지 않는지, WebAuthn 플로우가 어디서 실패하는지, OS나 브라우저 업데이트가 언제 조용히 로그인을 망가뜨리는지 — Okta, Auth0, Ping, Cognito 또는 자체 IDP를 교체하지 않고도 전부 파악할 수 있습니다. 두 가지 제품: Corbado Observe는 passkey 및 다른 모든 로그인 방식에 대한 observability를 더합니다. Corbado Connect는 analytics가 내장된 managed passkey를 제공합니다 (기존 IDP와 함께). VicRoads는 Corbado로 500만+ 사용자에게 passkey를 운영하고 있습니다 (passkey 활성화율 +80%). Passkey 전문가와 상담하기 →

자주 묻는 질문 (FAQ)#

기기 종속 패스키는 보안을 어떻게 강화하나요?#

기기 종속 패스키는 생성된 기기에 엄격하게 연결된 WebAuthn 자격 증명입니다. 동기화 패스키와 달리 단일 기기에 남아 있으므로 특정 사용 사례에서 본질적으로 더 안전합니다:

• 자격 증명 도난 불가: 개인 키가 기기 외부로 유출되지 않으므로 공격자가 자격 증명을 가로챌 수 없습니다.
• 무단 접근 방지: 패스키가 생성된 특정 기기에서만 인증이 수행됩니다.
• 클라우드 의존성 제로: 클라우드 데이터 유출이나 계정 탈취와 관련된 위험을 제거합니다.
• 높은 수준의 보안 준수: 금융 서비스(AAL3) 같은 규제 산업의 엄격한 기기 종속 인증 요구 사항을 충족합니다.

주요 단점은 제한적인 휴대성입니다. 기기를 분실하면 사용자가 다른 기기에 새로운 패스키를 등록하지 않는 한 복구할 수 없습니다.

동기화 패스키가 도입된 이유는 무엇이며 어떤 이점이 있나요?#

동기화 패스키(다중 기기 패스키)는 기기 종속 패스키의 사용성 문제, 특히 휴대성 부족과 기기 분실 시 잠재적인 계정 잠김 문제를 해결하기 위해 도입되었습니다. 주요 이점은 다음과 같습니다:

• 다중 기기 인증: 각 기기에 대해 수동으로 새 패스키를 등록할 필요 없이 여러 기기에서 계정에 접근할 수 있습니다.
• 액세스 권한 상실 위험 없음: 자격 증명이 클라우드(예: iCloud 키체인, Google Password Manager)에 백업되므로 기기를 분실해도 복구할 수 있습니다.
• UX 개선: 자격 증명을 수동으로 전송하거나 재생성해야 하는 불편함을 제거하여 마찰을 줄입니다.
• 추가 하드웨어 불필요: 하드웨어 보안 키와 달리 동기화 패스키는 내장된 기기 보안 모듈을 활용합니다.
• 클라우드 편의성과 결합된 강력한 보안: 종단 간(End-to-end) 암호화 덕분에 개인 키가 암호화되지 않은 상태로는 결코 기기 외부로 유출되지 않습니다.

5. 결론#

4개 파트로 구성된 시리즈의 첫 번째 파트에서는 기기 종속 패스키와 동기화 패스키의 역사적 및 기술적 차이를 분석했습니다. 이 차이점을 이해하면 PSD2 및 SCA의 요구 사항을 적절하게 적용하는 데 도움이 될 것입니다. 또한 계속 발전하고 있는 WebAuthn Level 3 Standard의 최근 변경 사항을 살펴보며 미래에 어떤 변화가 있을지 전망해 보았습니다.

시리즈의 나머지 파트에 대한 링크는 다음과 같습니다:

• 2부 "PSD2 및 SCA 요구 사항 분석 (SCA 및 패스키 2부)"
• 3부 "SCA 요구 사항이 패스키에 미치는 의미 (SCA 및 패스키 3부)"
• 4부 "PSD3 / PSR이 패스키에 미치는 영향 (SCA 및 패스키 4부)"