이 기법은 디스크의 로컬 passkey_enclave_state 파일에서 Chrome의 TPM(Trusted Platform Module)으로 래핑된 기기 식별 키를 추출한 후, 이 키를 정당한 Windows CNG API 호출을 통해 재사용(replay)하여 공격자가 제어하는 요청을 서명합니다. 이 과정을 통해 피해자 화면에 생체 인식이나 PIN 입력 창이 전혀 나타나지 않은 상태에서 유효한 WebAuthn 어설션(assertion)이 생성됩니다. 이 공격은 인증 데이터(Authenticator Data)의 User Verified(UV) 플래그를 서버 측에서 검증하지 않는 웹사이트(Relaying Party)에 대해서만 성공합니다 .
악용하는 점: 클라우드 인증기가 로컬에 저장된 기기 식별 키를 신뢰하는 점, 그리고 일부 웹사이트가 사용자 확인을 강제하지 않는 점.
이 기법은 로컬 passkey_enclave_state 파일을 삭제하거나 무효화하여 Chrome이 기기를 다시 온보딩(re-onboard)하도록 강제함으로써 사용자 확인(UV) 강제 조치를 무력화합니다. 재온보딩 과정에서 Chrome이 지연된 흐름(deferred flow)으로 사용자 확인(UV) 키를 일시적으로 생성하는데, 공격자는 이 짧은 시간 내에 자신의 UV 키를 등록합니다. Google의 클라우드 인증기는 새 키에 대한 증명(attestation)을 검증하지 않으므로, 이 키로 서명된 어설션은 UV 플래그가 1로 설정되어 전송됩니다. 이는 UV를 강제하는 사이트조차 우회할 수 있음을 의미합니다. 공격자는 자신의 기기에서 지속적이고 재사용 가능한 접근 권한을 얻습니다. 피해자의 기기가 더 이상 온라인 상태일 필요가 없습니다 .
악용하는 점: 기기 재온보딩 시 증명(attestation) 검증이 없다는 점, 그리고 격리 상태 파일(passkey_enclave_state)을 삭제하는 데 아무런 보호 장치가 없다는 점.
이 기법은 동일한 재온보딩 흐름을 유발한 후, Chrome의 프로세스 메모리를 덤프하여 보안 도메인 시크릿(Security Domain Secret, SDS) 을 복구합니다. SDS는 피해자 Google 계정에 동기화된 모든 패스키를 암호화하는 32바이트 대칭키입니다. 공격자는 SDS를 확보하면 기존 및 향후 동기화되는 모든 패스키의 개인 키를 복호화할 수 있어, 해당 패스키로 보호되는 모든 서비스에 대한 완전한 계정 장악(Total Account Takeover)이 가능합니다. Unit 42의 제보 이후 Google은 Chrome의 chrome://device-log/FIDO 출력에서 SDS가 평문으로 기록되던 문제를 제거했지만, 온보딩 흐름 중 Chrome 프로세스 메모리에 SDS가 평문으로 노출되는 문제는 여전히 남아 있습니다 .
악용하는 점: 온보딩 흐름 중 Chrome 프로세스 메모리에 SDS가 평문으로 존재한다는 점.
기본 Pass-ta-key 공격은 UV 플래그를 검증하지 않는 모든 웹사이트(Relaying Party)에 대해 작동합니다. Unit 42는 eBay가 이러한 검증을 수행하지 않는 사이트 중 하나임을 확인했으며, eBay는 이후 이 문제를 수정했습니다 . 연구원들은 "놀랍게도 많은" 웹사이트가 등록 시 userVerification: "required"를 요청하면서도, 반환된 UV 비트를 실제로 검증하지는 않는다고 지적했습니다 .
SDS는 사용자 Google 계정의 모든 동기화된 패스키를 위한 마스터키 역할을 하는 32바이트 비밀입니다. SDS가 유출되면 다음과 같은 일이 발생합니다:
Unit 42의 연구 결과와 관련 보도에 기반한 주요 대응 방안은 다음과 같습니다:
userVerification을 "preferred"가 아닌 "required"로 설정해야 합니다 .2026년 8월 3일 기준으로, 이 취약점들에는 아직 CVE 번호가 할당되지 않았습니다. Google은 Silver 또는 Golden 공격 경로를 직접 수정할 것인지에 대해 공식적으로 확인하지 않았습니다 .