패스키 & WebAuthn PRF를 이용한 종단간 암호화 (2025년)

WebAuthn과 패스키는 공개 키 암호 기술을 통해 피싱 방지 기능이 있는 비밀번호 없는 로그인을 제공하며 웹 인증에 혁명을 일으켰습니다. 하지만 그 기능은 로그인에만 국한되지 않습니다. 흥미로운 기능 중 하나는 WebAuthn 의사 난수 함수(Pseudo-Random Function, PRF) 확장입니다. 이 확장을 통해 웹 애플리케이션은 인증 중에 사용자의 패스키나 하드웨어 보안 키에서 직접 비밀 키를 파생시킬 수 있습니다. 이를 통해 별도의 비밀번호 없이 패스키만으로 종단간 암호화된 데이터에 접근하거나 보안 저장소를 해독할 수 있습니다. 이 글에서는 다음 질문에 답해보고자 합니다.

• 패스키 PRF 사용 사례: WebAuthn PRF 확장을 활용할 수 있는 흥미로운 사용 사례는 무엇일까요?
• PRF 확장 지원 현황: 현재 운영체제와 브라우저에서 WebAuthn PRF 확장의 실제 지원 현황은 어떤가요?

이 글에서는 WebAuthn PRF 확장을 분석하고, 기술 사양, 사용 사례, 구현 세부 정보, 보안 고려 사항 및 현재 브라우저와 운영체제의 지원 현황을 살펴봅니다. 저희는 2025년 생태계의 변화에 초점을 맞추고, 2023년에 Matthew Miller와 Levi Schuck이 제시한 기초 작업을 확장합니다. 이들의 이전 글들은 상세한 기술적 배경, 라이브 예제, 그리고 온라인 테스트(암호화 포함)를 제공합니다.

WebAuthn PRF 확장(PRF)은 WebAuthn 레벨 3 사양에 공식적으로 정의되어 있습니다. 핵심 목적은 신뢰 당사자(Relying Party)(웹 애플리케이션)가 인증 과정(navigator.credentials.get())에서 특정 WebAuthn 자격 증명(패스키)과 관련된 의사 난수 함수의 평가를 요청할 수 있도록 하는 것입니다.

PRF는 인증자(authenticator) 내부에 안전하게 보관되고 자격 증명에 연결된 비밀 키와 신뢰 당사자가 제공하는 하나 이상의 입력값을 사용하여, 결정론적이면서 암호학적으로 무작위처럼 보이는 출력을 생성합니다. 이 출력은 일반적으로 32바이트 문자열이며, 클라이언트 측 애플리케이션에서 WebAuthn 암호화를 위한 대칭 키 자료나 키 파생에 가장 유용하게 사용될 수 있습니다.

많은 인증자, 특히 FIDO2 보안 키는 클라이언트-인증자 프로토콜(Client-to-Authenticator-Protocol, CTAP2)에 정의된 hmac-secret 확장이라는 기본 기능을 구현합니다. 이 CTAP2 확장은 의사 난수 함수 역할을 하는 하드웨어 기반 HMAC(Hash-based Message Authentication Code) 기능에 대한 접근을 제공합니다. WebAuthn PRF 확장은 웹 애플리케이션이 브라우저의 WebAuthn API를 통해 이 hmac-secret 기능에 접근할 수 있는 표준화된 방법으로 작동합니다.

웹사이트가 인증자를 속여 로컬 OS 로그인과 같은 비웹용 HMAC을 생성하게 하는 잠재적인 충돌이나 보안 문제를 방지하기 위해, WebAuthn 사양은 중요한 단계를 의무화합니다. 웹사이트가 제공하는 입력(첫 번째 및 두 번째 솔트)은 기본 hmac-secret 함수에 전달되기 전에 먼저 특정 컨텍스트 문자열("WebAuthn PRF"와 널 바이트)로 해시 처리됩니다. 이는 PRF의 입력 공간을 효과적으로 분할하여, 웹에서 파생된 출력이 다른 컨텍스트에서 사용될 수 있는 출력과 구별되도록 보장합니다.

인증자에 바인딩된 키를 파생시키는 기능은 개발자에게 여러 가지 매력적인 사용 사례를 제공합니다.

1. 클라이언트 측 / 종단간 암호화(E2EE): 이것이 WebAuthn PRF 확장의 주된 동기입니다. 브라우저 기반 애플리케이션은 로그인 중에 자격 증명별로 고유한 암호화 키를 파생시킬 수 있습니다. 이 키는 WebCrypto API와 함께 사용하여 로컬이나 서버에 저장된 사용자 데이터를 암호화할 수 있습니다. 데이터는 저장 시 암호화된 상태로 유지되며, 사용자가 특정 패스키로 성공적으로 인증한 후에만 해독할 수 있어 개인 정보 보호와 데이터 보안을 강화합니다. 서비스 제공업체는 평문 데이터에 접근하지 않고도 사용자 데이터를 저장할 수 있습니다. 이는 PRF 확장이 없으면 비밀번호 형태의 추가적인 비밀 정보를 요청해야 하므로 비밀번호 없는 아키텍처와 모순되는 비밀번호 없는 세계의 애플리케이션에 특히 유용합니다.

2. 비밀번호 없는 저장소 해독: 비밀번호 관리자(예: Bitwarden, 1Password)나 보안 노트 앱(예: Notesnook, Reflect)과 같은 서비스는 PRF를 사용하여 기존의 마스터 비밀번호를 대체할 수 있습니다. 사용자가 패스키로 인증하면 PRF 확장이 저장소 해독 키를 파생시키고 저장소가 잠금 해제됩니다. 마스터 비밀번호가 전혀 필요 없습니다. Bitwarden은 이 기능 지원을 발표했습니다. 또한, Dashlane은 최근 WebAuthn PRF 확장을 채택하여 피싱 저항성을 강화하고 암호화된 저장소 접근에 대한 보안을 향상시켰습니다. 사용자는 패스키를 사용하여 인증하며, PRF가 저장소 해독 키를 안전하게 파생시켜 마스터 비밀번호의 필요성을 완전히 제거합니다.

3. 안전한 키 순환: WebAuthn PRF 확장은 인증 중에 두 개의 입력 "솔트"(첫 번째와 두 번째)를 제공할 수 있습니다. 이는 암호화 키 순환 체계를 용이하게 합니다. 서버는 첫 번째 솔트를 사용하여 "현재" 키를, 두 번째 솔트를 사용하여 "다음" 키를 요청할 수 있습니다. 시간이 지남에 따라 서버는 어떤 솔트가 현재 키에 해당하는지 업데이트하여 사용자 경험을 방해하지 않고 원활한 순환을 가능하게 합니다. 이는 규제 요건이나 내부 정책에 따라 모든 키를 특정 일정 내에 순환해야 하는 경우 특히 중요하며 보안을 강화합니다.

4. ID 지갑 및 비수탁형 시스템: PRF는 디지털 지갑 내의 ID 데이터를 보호하기 위한 키를 파생시키거나, 개인 키가 서버 측에 절대 노출되지 않는 비수탁형 시스템을 가능하게 할 수 있습니다.

사양은 정의되어 있지만, 실제 브라우저와 플랫폼 지원은 개발자에게 중요한 요소입니다. 지원은 계속 발전해 왔으며, 최근까지는 주로 Chromium 기반 브라우저에 국한되었습니다. CanIUse.com에 PRF 확장 자체에 대한 전용 항목이 없기 때문에 지원 현황을 추적하기 어려울 수 있습니다("webauthn"으로 검색하면 일반적인 API 지원은 표시되지만 특정 확장은 표시되지 않음). 정보는 종종 브라우저 릴리스 노트, 버그 추적기 및 상태 페이지에서 수집해야 합니다. WebAuthn PRF 확장을 성공적으로 사용하려면 기술 스택의 세 가지 개별 계층에 걸친 협력이 필요합니다. 기능이 작동하려면 각 수준에서 PRF 확장 지원이 있어야 합니다.

1. 인증자(The Authenticator): 자격 증명의 비밀 키를 안전하게 저장하고 실제 의사 난수 함수 계산(일반적으로 CTAP2 hmac-secret 기능 사용)을 수행하는 하드웨어(예: 보안 키) 또는 플랫폼 구성 요소(예: Windows Hello, iCloud 키체인 및 해당 하드웨어 모듈, 예: TPM 또는 Secure Enclave)입니다. 인증자에 이 기본적인 암호화 기능이 없으면 PRF는 작동할 수 없습니다.

2. 운영체제(The Operating System, OS): OS는 브라우저와 인증자 사이의 다리 역할을 합니다. 브라우저가 인증자(특히 플랫폼 인증자 및 USB/NFC/블루투스를 통해 연결된 인증자)를 발견하고, 통신하며, 작업을 요청하는 데 필요한 드라이버와 시스템 수준 API를 제공합니다. OS는 인증자의 PRF(hmac-secret) 기능을 인식하고 브라우저에 노출할 수 있어야 합니다. OS가 이 경로를 제공하지 않으면 브라우저는 이 기능에 접근할 수 없습니다.

3. 브라우저(The Browser): 웹 애플리케이션의 인터페이스로서, 브라우저는 WebAuthn JavaScript API를 구현하고, 특히 prf 확장을 인식하며, 웹 요청을 OS/인증자에 대한 적절한 명령으로 변환하고, 컨텍스트 문자열로 입력을 해싱하는 중요한 보안 단계를 처리하고, 결과를 올바르게 구문 분석하여 애플리케이션에 반환해야 합니다.

이 세 계층(인증자 기능, OS 노출 또는 브라우저 구현) 중 어느 하나라도 실패하거나 지원이 부족하면 PRF 확장이 작동하지 않습니다.

이 시퀀스 차트는 이러한 행위자들이 PRF 지원을 위해 어떻게 협력하는지를 간소화하여 보여줍니다.

작동하는 PRF 워크플로우는 WebAuthn ↔ CTAP 체인의 모든 계층이 협력해야 합니다.
명확성을 위해, 우리는 논의를 (1) 브라우저 + 운영체제 동작과 (2) 인증자 동작으로 구분합니다.

광범위한 PRF 지원을 향한 여정은 웹 표준 확장의 일반적인 과제를 보여줍니다. 구현은 종종 단계적으로 이루어지며, 플랫폼별 문제를 해결해야 합니다. 저희는 이 표를 계속 업데이트할 예정이지만, PRF 확장은 전체 호환성 체인이 적응해야 하는 최신 추가 기능 중 하나이므로 지속적인 조정이 예상된다는 점을 명심하세요.

아래에서는 운영체제별 지원 현황을 분석합니다.

Windows에서의 WebAuthn PRF 확장 지원은 제한적입니다. 네이티브 플랫폼 인증자(Windows Hello)에 현재 필요한 hmac-secret 기능이 없기 때문입니다. 따라서 PRF 기능은 외부 보안 키에 의존합니다.

macOS 15부터 플랫폼 인증자에 대한 PRF 지원이 추가되었습니다. Safari와 Chrome 모두 iCloud 키체인을 통해 PRF를 지원합니다. 플랫폼 인증자에 대한 Firefox 지원은 아직 보류 중입니다. 보안 키는 Chrome에서만 작동합니다.

iOS 및 iPadOS의 상태는 macOS와 유사하며, iCloud 키체인을 통해 PRF가 작동합니다. 그러나 중요한 주의 사항이 있습니다. iOS 18 초기 버전의 버그로 인해 데이터 손실이 발생할 수 있으며, 외부 보안 키에 대한 지원은 아직 구현되지 않았습니다.

Android는 현재 WebAuthn PRF 확장에 대해 가장 강력하고 광범위한 지원을 제공합니다. Google 비밀번호 관리자에 저장된 패스키는 기본적으로 PRF 지원을 포함하며, Firefox를 제외한 대부분의 주요 브라우저에서 작동합니다.

위 표에는 자사 패스키 제공업체 지원에 대한 가장 중요한 조합을 포함했습니다. 그러나 비밀번호 관리자를 타사 패스키 제공업체로 사용할 때는 해당 업체의 특정 기능을 별도로 고려해야 합니다. 예를 들어, 1Password는 Android 버전에서는 PRF를 지원하지만 iOS 버전에서는 지원하지 않습니다. 또한 Chrome 프로필을 인증자로 사용하는 경우 prf를 지원하지 않습니다. 인증자에 대한 자세한 내용은 아래를 참조하세요.

WebAuthn은 신뢰 당사자가 무엇을 요청할 수 있는지를 명시하지만, **클라이언트-인증자 프로토콜(CTAP)**은 인증자가 어떻게 동작해야 하는지를 정의합니다. 실제로 인증자는 네 가지 범주로 나뉩니다.

1. PRF 미지원: 구형 플랫폼 인증자(예: Windows Hello), hmac-secret 확장이 없는 레거시 보안 키 및 아직 prf 확장을 채택하지 않은 타사 제공업체.

2. 자격 증명 생성 시 PRF 플래그가 설정된 경우에만 PRF 지원: 일부 CTAP 2.0/2.1 보안 키는 hmac-secret을 노출하지만, 신뢰 당사자가 자격 증명을 처음 생성할 때 비밀을 초기화하기 위해 요청하지 않은 경우 PRF 평가를 거부합니다.

3. 생성 시 요청하지 않았더라도 인증 시 PRF 사용 가능: 차세대 하드웨어 토큰과 iCloud 및 Google 비밀번호 관리자는 hmac-secret 기능을 무조건적으로 노출합니다. 플래그 없이 생성된 자격 증명도 navigator.credentials.get() 중에 PRF와 함께 작동합니다.

4. 완전한 CTAP 2.2 준수 (PRF + 생성 시 첫 번째 PRF 값): 패스키를 동기화하는 플랫폼 인증자(예: iCloud 키체인 및 Google 비밀번호 관리자)는 요청 시 navigator.credentials.create() 중에 이미 첫 번째 PRF 출력을 반환하여 키 설정 흐름을 간소화할 수 있습니다.

인증자가 어떤 범주에 속하는지 아는 것은 백업, 마이그레이션 또는 키 설정 로직을 설계할 때 필수적입니다. 저희는 데모에 이러한 시나리오에 대한 테스트도 포함했습니다.

저희의 대화형 WebAuthn PRF 데모 애플리케이션을 사용하여 WebAuthn PRF 확장을 직접 경험해 볼 수 있습니다. 이 데모에서는 다음을 할 수 있습니다.

• PRF로 패스키를 등록하고 인증자가 이 강력한 확장을 지원하는지 확인합니다.
• 패스키를 사용하여 인증하고 PRF로 생성된 암호화 값을 실제로 확인합니다.

PRF 값을 직접 보는 것은 안전한 키 기반 작업을 위해 패스키를 사용하는 것의 실제적인 의미를 강조합니다. 이를 통해 PRF 확장에 대한 인증자 호환성을 직접 확인하고, PRF 파생 키가 비밀번호 없이 WebAuthn 종단간 암호화 및 보안 저장소 해독을 어떻게 지원하는지 관찰할 수 있습니다.

잠시 시간을 내어 데모를 사용해 보세요. 특정 환경의 PRF 기능을 이해하면 사용자에게 맞는 안전하고 비밀번호 없는 경험을 더 잘 계획하는 데 도움이 됩니다.

PRF의 힘을 테스트할 준비가 되셨나요? 위 이미지를 클릭하거나 이 링크를 따라 직접 체험을 시작하세요.

WebAuthn PRF 확장은 데이터 저장 또는 파생과 관련된 유일한 WebAuthn 확장이 아닙니다. 패스키 PRF는 다른 대안과 어떻게 비교될까요?

• PRF vs. credBlob / largeBlob:

  • credBlob: 자격 증명과 함께 작은(32바이트) 정적 블롭을 저장할 수 있으며, 생성 시에 가능합니다. 주로 비밀 정보를 위해 설계되지 않았으며, 특히 검색 불가능한 자격 증명에 대한 지원이 제한적입니다.

  • largeBlob: 검색 가능한 자격 증명과 함께 더 많은 데이터(약 1KB)를 저장할 수 있으며, 종종 인증서와 같은 보조 데이터를 위해 사용됩니다. 지원 또한 제한적입니다(iOS 17부터 iCloud 키체인에서 지원되지만 GPM에서는 지원되지 않음). Chrome 개발자들은 대부분의 사용 사례에서 largeBlob보다 PRF에 집중하는 것을 명시적으로 선호했지만, 향후 개발이 이루어질 수도 있습니다.

  • PRF: 반면, PRF는 정적 블롭을 저장하는 대신 하드웨어에 바인딩된 비밀을 사용하여 인증 중에 요청 시 비밀 키를 _파생_하도록 특별히 설계되었습니다. 일반적으로 패스키에 연결된 암호화 키를 파생시키는 가장 적절하고 안전한 표준 메커니즘으로 간주됩니다. 비밀 정보에 대한 블롭 논의에서 PRF의 표준화 및 구현 집중으로의 진화는 이 사용 사례에 대한 전용 솔루션으로서 PRF로 수렴되고 있음을 시사합니다.

• PRF vs. 비밀번호 파생 키 (예: PBKDF2): 전통적으로 클라이언트 측 암호화 키는 사용자 비밀번호에서 파생되었습니다. PRF는 상당한 이점을 제공합니다.

  • 더 강력한 소스: 키는 잠재적으로 약하거나 재사용된 비밀번호가 아닌, 인증자 내의 강력한 암호화 자료에서 파생됩니다.

  • 피싱 저항성: 파생은 피싱 저항성이 있는 WebAuthn 인증 흐름에 연결됩니다.

  • 비밀번호 없음: 비밀번호를 전혀 요구하지 않고 저장소 해독과 같은 사용 사례를 가능하게 합니다.

• PRF vs. 기타 WebAuthn 데이터: WebAuthn 응답의 다른 부분(예: 서명, authenticatorData 또는 공개 키)에서 키를 파생시키려는 시도는 근본적으로 안전하지 않고 잘못된 것입니다. 이러한 구성 요소는 공개적이거나, 비밀이 아니거나, 키 파생이 아닌 검증을 위해 설계되었습니다.

WebAuthn 자격 증명 또는 패스키에 직접 연결된 암호화 키 자료를 안전하게 파생시키려면, WebAuthn PRF 확장이 목적에 맞게 구축된 권장 표준 접근 방식입니다.

PRF 확장을 애플리케이션에 통합할 때 다음의 실용적인 지침을 고려하세요.

다음 권장 사항은 개발자가 현재 PRF 확장 지원 상태를 효과적으로 탐색하고 향후 개발을 계획하는 데 도움이 됩니다.

• PRF를 기회적으로 다루기: WebAuthn PRF 확장에 대한 지원은 현재 브라우저, 운영체제 및 인증자 전반에 걸쳐 상당히 다양합니다. 따라서 PRF 통합을 핵심 종속성보다는 향상 기능으로 취급하세요.

• PRF에 대한 중대한 의존 피하기: 미션 크리티컬한 기능에 PRF를 필수로 만들지 마세요. 현재 지원, 특히 macOS의 Safari 및 iOS와 같은 플랫폼에서의 지원은 여전히 일관성이 없고 불완전합니다.

• 패스키 분실 시나리오 대비: PRF 파생 키로 암호화된 데이터는 특정 패스키에만 독점적으로 바인딩된다는 점을 기억하세요. 패스키를 분실하면 암호화된 데이터에 영구적으로 접근할 수 없게 됩니다. 항상 강력한 백업 및 복구 메커니즘을 구현하세요.

• 2026년까지 더 넓은 지원 예상: PRF 확장 지원은 빠르게 성숙하고 있습니다. 2026년까지는 주요 브라우저, 운영체제 및 인증자, 특히 자사 패스키 제공업체 전반에서 일관된 가용성을 기대할 수 있습니다.

• Windows 생태계 모니터링: Windows Hello를 통한 플랫폼 인증자 지원은 현재 부재합니다. Windows 환경에서의 완전한 PRF 통합은 Microsoft의 채택 전략에 크게 의존하므로 이 생태계를 면밀히 관찰하세요.

이러한 지침을 따르면 개발자는 채택 단계 동안 호환성과 보안을 유지하면서 PRF를 원활하게 통합할 수 있습니다.

PRF가 전반적인 패스키 전략과 어떻게 조화를 이루는지 이해하면 불필요한 복잡성 없이 그 이점을 극대화하는 데 도움이 됩니다.

• 유연한 통합: 패스키 생성 시점에 PRF 활용 여부를 결정할 필요가 없습니다. 기존 패스키는 추가적인 자격 증명 관리 오버헤드 없이 나중에 PRF 사용 사례와 원활하게 통합될 수 있습니다.

• PRF 개조: PRF는 인증 단계(navigator.credentials.get())에서 작동하므로 이전에 생성된 패스키도 나중에 PRF 기반 워크플로우를 지원할 수 있습니다. 이를 통해 애플리케이션은 기존 인증 방법을 방해하지 않고 점진적으로 보안을 강화할 수 있습니다. 이 접근 방식은 iCloud 키체인 및 Google 비밀번호 관리자(GPM) 및 최신 보안 키에서 작동합니다. 구형 보안 키의 경우, 자격 증명 생성 시 요청된 경우에만 hmac-secret이 생성될 수 있습니다.

• 패스키 복잡성 고려 사항: 자격 증명 동기화, 교차 기기 인증 및 복구 프로세스와 같은 패스키 관리에 내재된 복잡성은 PRF를 사용할 때도 동일하게 적용됩니다. PRF 구현이 전반적인 패스키 인증 전략과 일관되게 조화를 이루도록 하여 간소화된 사용자 경험과 강력한 보안 제어를 유지하세요.

전체적인 패스키 전략의 일부로 PRF를 고려하면 더 안전하고 사용자 친화적인 인증 방식으로의 전환이 더 원활해집니다.

민감한 사용자 데이터를 처리하는 기업 서비스 제공업체에게 WebAuthn PRF를 패스키와 함께 활용하는 능력은 보안과 사용자 경험을 향상시킬 수 있는 가능성을 열어줍니다. 특히 개인 식별 정보(PII)의 클라이언트 측 암호화나 종단간 암호화가 필요한 애플리케이션을 보호하는 시나리오에서 그렇습니다. Corbado Connect는 주로 원활한 엔터프라이즈 패스키 통합을 위해 설계되었지만, SPC나 PRF와 같은 패스키 확장의 구현도 용이하게 할 수 있습니다.

Corbado가 PRF 통합을 고려하는 조직을 지원할 수 있는 방법은 다음과 같습니다.

• 암호화된 저장을 위한 PRF 촉진: 기업 환경에서는 민감한 정보를 안전하게 저장해야 하는 요구 사항이 있으며, 때로는 서버 측 PII 노출을 최소화하기 위해 클라이언트 측에 직접 저장해야 할 수도 있습니다. Corbado Connect는 패스키 인증 흐름(navigator.credentials.get()) 중에 PRF 값을 요청하도록 구성할 수 있어, 애플리케이션이 필요한 암호화 키를 파생시킬 수 있습니다.
• 유연한 저장 패턴: PRF 파생 키를 사용하여 암호화된 데이터는 보안 요구 사항 및 아키텍처에 따라 다양한 방식으로 저장될 수 있습니다.
  • 클라이언트 측: localStorage나 보안 쿠키와 같은 메커니즘을 사용하여 브라우저에 직접 저장됩니다. 평문 데이터는 해독 중에 클라이언트에서 일시적으로만 존재합니다.
  • Corbado 백엔드 (E2EE): Corbado는 일반적으로 고객 PII를 저장하지 않지만, PRF 메커니즘은 기술적으로 Corbado의 서버에 클라이언트 측에서 암호화된 데이터를 저장할 수 있게 합니다. Corbado는 이 데이터를 해독할 키를 소유하지 않으며, 해독은 성공적인 사용자 인증 후에도 여전히 클라이언트 측에서 발생합니다.
  • 클라이언트의 백엔드: 암호화된 데이터는 기업의 자체 백엔드 시스템으로 전송되어 저장될 수도 있으며, 여전히 클라이언트 측 암호화의 이점을 누릴 수 있습니다.
• 안전한 키 파생 흐름: Corbado Connect 구성 요소는 WebAuthn API와의 상호 작용을 관리합니다. PRF가 요청되면:
  1. 개별 패스키에 연결된 사용자별 PRF 출력이 인증자에 의해 생성됩니다.
  2. 이 출력은 클라이언트 측 애플리케이션에 안전하게 반환됩니다.
  3. 애플리케이션은 WebCrypto API(예: HKDF)를 통해 키 파생 함수(KDF)를 사용하여 PRF 출력에서 강력한 대칭 암호화 키를 파생시켜야 합니다.
  4. 이 대칭 키는 WebCrypto(예: AES-GCM)와 함께 대상 정보(예: PII)를 암호화하거나 해독하는 데 사용됩니다.
• 후속 로그인 시 원활한 해독: 사용자가 동일한 패스키를 사용하여 다시 인증하면, Corbado Connect가 동일한 PRF 요청을 시작합니다. 이는 동일한 PRF 출력을 생성하여 애플리케이션이 동일한 대칭 키를 다시 파생시키고 이전에 저장된 정보를 클라이언트 측에서 해독할 수 있게 합니다.
• PRF 채택 인텔리전스: PRF를 구현하려면 사용자의 환경(OS, 브라우저, 인증자)이 이를 지원하는지 알아야 합니다. Corbado Connect는 인증 중에 사용자의 장치 및 기능에 대한 신호를 수집합니다. 이 인텔리전스는 다음을 위해 사용될 수 있습니다.
  • PRF 의존적인 기능을 완전히 활성화하기 전에 사용자 기반 전반의 PRF 준비 상태를 결정합니다.
  • PRF를 기회적으로 구현하여 지원되는 사용자에게는 향상 기능으로 제공하고, 지원되지 않는 사용자에게는 재검증을 요청하거나 대체 방법을 사용하는 등의 폴백 메커니즘을 유지합니다.
• PII 가용성 간소화: PRF를 사용하여 검증된 PII(예: 검증 흐름을 통해 얻은 신원 속성)를 암호화하고 클라이언트 측에 저장함으로써, 애플리케이션은 패스키 로그인 후 후속 상호 작용이나 거래를 위해 이 데이터를 즉시 사용할 수 있게 하여 재검증이나 앱 기반 흐름에 비해 마찰을 크게 줄입니다.
• 맞춤형 E2EE 시스템 활성화: Corbado Connect는 표준 흐름을 위한 UI 구성 요소를 제공하지만, 기본 원칙을 통해 개발자는 PRF 기능을 민감한 애플리케이션에 더 깊이 통합할 수 있습니다. 이를 통해 프론트엔드 애플리케이션이 기존 또는 새로운 데이터에 대한 복잡한 암호화 작업을 위해 PRF 파생 키를 직접 활용하는 종단간 암호화 시스템을 구축할 수 있습니다. 당분간 이는 기회적으로만 가능하며 폴백 메커니즘은 해당 정보를 다른 방식으로 저장해야 합니다.

Corbado는 패스키 및 PRF 통합의 복잡성을 단순화하여 기업이 표준을 안전하고 효과적으로 활용하고, 진화하는 환경을 탐색하면서 클라이언트 측 PII 암호화와 같은 특정 사용 사례에 적응할 수 있도록 돕는 것을 목표로 합니다.

WebAuthn PRF 확장은 진정으로 비밀번호가 없고 종단간 암호화된 애플리케이션을 현실로 만드는 데 있어 중요한 진전을 의미합니다. 패스키를 활용하여 암호화 키를 안전하게 파생시킴으로써, 개인 정보 보호를 손상시키지 않으면서 원활하고 안전한 사용자 경험을 제공합니다.

이 글의 시작 부분에서 제기된 질문에 직접 답하자면 다음과 같습니다.

• 흥미로운 PRF 사용 사례: PRF는 종단간 암호화된 데이터 저장, 비밀번호 관리자를 위한 비밀번호 없는 저장소 해독, 안전한 암호화 키 순환 체계, 그리고 개인 키가 클라이언트 장치를 절대 떠나지 않도록 보장하여 사용자 개인 정보를 보호하는 안전한 ID 지갑 또는 비수탁형 시스템과 같은 매력적인 사용 사례를 가능하게 합니다.

• 현재 PRF 지원 현황 (2025년 6월): 지원은 여전히 단편적이고 진화하고 있습니다. Android는 브라우저와 인증자 전반에 걸쳐 강력한 지원을 제공하지만, macOS와 특히 iOS와 같은 플랫폼은 심각한 버그가 있는 CDA 소스로서 불안정합니다. Windows 지원은 주로 외부 보안 키에 국한되어 있으며, Windows Hello를 통한 네이티브 플랫폼 지원은 눈에 띄게 부재합니다.

PRF 확장을 고려하는 개발자는 빠른 개선을 기대하면서도, 현재의 한계를 원활하게 처리하는 탄력적인 애플리케이션을 구축하며 신중하게 진행해야 합니다. 주요 플랫폼과 인증자 생태계에서 더 넓은 채택이 이루어짐에 따라, PRF 기반의 비밀번호 없는 암호화의 미래는 밝아 보이며, 웹 인증에서 향상된 개인 정보 보호와 사용성을 약속합니다.