Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — "패스키를 내보낼 수 있다"는 말의 실제 범위
두 개의 스펙, 두 개의 속도
CXP 워킹 드래프트가 스스로에 대해 하는 말
CXF가 실제로 실어 나르는 것 — 평문 개인키
그래서 기밀성은 누가 책임지나
실제로 배송된 것 — OS가 중개하는 같은 기기 내 전송
옮겨지지 않는 패스키들
아직 안 풀린 것 — 내보내기 거부와 락인
그래서 지금 무엇을 해야 하나
마치며
참고 자료

들어가며 — "패스키를 내보낼 수 있다"는 말의 실제 범위

2026년 6월, Android에 패스키 가져오기/내보내기가 들어왔습니다. 그 전해에는 iOS 26이 같은 걸 했습니다. 헤드라인만 보면 이야기는 끝난 것 같습니다 — 패스키는 이제 이식 가능하고, 락인 걱정은 해결됐다.

그런데 스펙 디렉터리를 직접 열어 보면 그림이 다릅니다. FIDO의 자격증명 교환은 하나가 아니라 두 개의 문서로 쪼개져 있고, 그 둘은 완성도가 자릿수로 다릅니다. 하나는 표준이 됐고, 다른 하나는 21개월째 워킹 드래프트입니다. 그리고 완성된 쪽은 미완성된 쪽에 보안을 의존합니다.

이 글은 그 비대칭이 실무에서 무엇을 의미하는지 정리합니다. 결론부터 말하면, 2026년 7월 현재 배송된 것은 "생태계를 넘나드는 패스키 이식성"이 아니라 "OS가 중개하는, 같은 기기 안에서의 앱 간 이전"입니다. 그 차이는 마케팅 문구에서는 사라지지만 아키텍처에서는 사라지지 않습니다.

두 개의 스펙, 두 개의 속도

FIDO Alliance의 스펙 디렉터리(fidoalliance.org/specs/cx/)를 그대로 읽으면 이렇습니다.

cxf-v1.0-wd-20240522.html          CXF 워킹 드래프트    2024-05-22
cxf-v1.0-wd-20241003.html          CXF 워킹 드래프트    2024-10-03
cxf-v1.0-rd-20250313.html          CXF 리뷰 드래프트    2025-03-13
cxf-v1.0-ps-20250814.html          CXF Proposed Standard 2025-08-14
cxf-v1.0-errata-20260309.html      CXF errata           2026-03-09
cxf-v1.0-ps-errata-20260309.html   CXF PS + errata 반영  2026-03-09

cxp-v1.0-wd-20240522.html          CXP 워킹 드래프트    2024-05-22
cxp-v1.0-wd-20241003.html          CXP 워킹 드래프트    2024-10-03
                                   ...여기서 끝

CXF(Credential Exchange Format) 는 무엇을 주고받는지 — 데이터 구조와 포맷 — 를 정의합니다. 워킹 드래프트에서 리뷰 드래프트를 거쳐 2025년 8월 14일 Proposed Standard가 됐고, 2026년 3월 9일 errata가 붙었습니다. 정상적인 표준화 궤적입니다.

CXP(Credential Exchange Protocol) 는 어떻게 주고받는지 — 두 제공자 사이의 실제 전송 프로토콜 — 를 정의합니다. 2024년 10월 3일 워킹 드래프트가 마지막입니다. 리뷰 드래프트도, Proposed Standard도 없습니다. 오늘(2026년 7월 16일) 기준으로 21개월째 그대로입니다.

참고로 2026년 3월 errata는 내용상 편집 수정입니다. Appendix A 예제 페이로드에서 규범 본문과 어긋난 채 남아 있던 hmacSecret 키를 hmacCredentials로 고치고, 빠져 있던 example-file 내용을 채운 것이 전부입니다. errata 문서 스스로 "The contents of example-file were missing and cfx example was updated"라고 적고 있습니다. 규범적 동작이 바뀐 게 아니니 "2026년에 CXF가 크게 개정됐다"고 읽으면 안 됩니다.

CXP 워킹 드래프트가 스스로에 대해 하는 말

CXP 워킹 드래프트의 "Status of This Document"를 그대로 옮기면 이렇습니다.

This is a Working Draft Specification and is not intended to be a basis for any
implementations as the Specification may change. This document is merely a FIDO
Alliance working group internal and member-confidential document. It has no
official standing of any kind and does not represent consensus of the FIDO Alliance.

No rights are granted to prepare derivative works of this Specification.

읽고 넘어가기 쉬운 보일러플레이트지만, 이게 패스키 이식성 이야기의 전송 절반이라는 걸 감안하면 문장 하나하나가 무겁습니다. "어떤 구현의 근거로도 삼으려는 의도가 없다", "FIDO Alliance 워킹그룹 내부의 회원 대외비 문서일 뿐이다", "어떤 종류의 공식적 지위도 없으며 FIDO Alliance의 합의를 대표하지 않는다".

문서의 미완성도는 목차에서도 드러납니다. CXP §5 "Implementation Requirements" — 이 스펙의 어떤 알고리즘과 기능이 구현 필수인지를 정의해야 할 절 — 은 "This section defines which algorithms and features of this specification are mandatory to implement. Applications using this specification can impose additional requirements upon implementations that they use."라는 두 문장만 있고 곧바로 §6 Security Considerations로 넘어갑니다. 필수 구현 알고리즘 집합이 비어 있습니다. 상호운용의 바닥이 아직 안 깔린 셈입니다.

프로토콜의 뼈대 자체는 있습니다. Diffie-Hellman 키 교환으로 두 제공자 사이에 보안 채널이나 데이터 페이로드를 만들고, HPKE 파라미터(mode는 base / psk / auth / auth-psk)를 협상하고, 아카이브는 DEFLATE를 씁니다. 흐름은 가져오는 쪽이 Export Request를 만들고 → 권한 부여 주체가 마이그레이션을 결정하고 → 내보내는 쪽이 자격증명 데이터를 암호화하고 → Export Response를 보내고 → 가져오는 쪽이 번들을 복호화하는 5단계입니다. 설계는 합리적입니다. 다만 "설계가 있다"와 "표준이다"는 다른 말입니다.

CXF가 실제로 실어 나르는 것 — 평문 개인키

여기서부터가 중요합니다. CXF 스펙의 Passkey 항목에서 key 멤버의 정의는 이렇습니다.

key
  The private key associated to this passkey instance.
  The value MUST be PKCS#8 ASN.1 DER formatted byte string which is then
  Base64url encoded.
  The value MUST give the same public key value that was provided by the
  original authenticator during registration.

스펙 Appendix A의 예제 페이로드를 보면 실감이 납니다. (아래는 CXF PS + errata 문서의 예제를 그대로 옮긴 것입니다.)

{
  "id": "akKA3Y0jQRuK7sKplB0Y9w",
  "title": "WebAuthn.io",
  "credentials": [
    {
      "type": "passkey",
      "credentialId": "Y3JlZGVudGlhbElkRXhhbXBsZQ",
      "rpId": "webauthn.io",
      "username": "johndoe",
      "userDisplayName": "John Doe",
      "userHandle": "cnEzaNHWcYK3coWZjvoaV1Hj9gnI12mKe2dL2HZVFlY",
      "key": "MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgARu_0sCt20EpgVxb4Puq3Ga5VVLpuTY75ngvZlyq3X6hRANCAASmdk1xLsK0oOlhxIPp0d1ZuS0sT9nf6BZtSelhqvLBW0fOL33l_bXgsr_STUHjCLn8l6gcRJwe7OQvbQubZ1dY"
    }
  ]
}

key 필드에 들어 있는 저 문자열이 P-256 개인키입니다. 래핑도, 암호화도, 패스프레이즈도 없습니다. 같은 예제에 비밀번호는 "value": "securepassword123"으로, TOTP 시드는 "secret": "JBSWY3DPEHPK3PXP"로 나란히 평문으로 들어 있습니다.

이건 버그가 아니라 설계입니다. CXF는 포맷일 뿐이고, 자기 §1.2 Scope에서 명시적으로 선을 긋습니다 — "This document outlines the data structures and format needed to exchange credentials and does not make any assumptions about the protocol used for the transfer, such as the protocol outlined by CXP." 전송에 대해 아무 가정도 하지 않는다는 뜻입니다. 즉 CXF 문서 하나만 놓고 보면, 그 결과물은 당신의 모든 개인키와 비밀번호와 TOTP 시드가 든 평문 JSON입니다.

그래서 기밀성은 누가 책임지나

CXF의 §5 Security Considerations는 이 질문에 이렇게 답합니다.

Note: [CXP] ensures that the credential exchange remains confidential between
the exporting provider and importing provider.

즉 CXF는 "기밀성은 CXP가 보장한다"고 말하고, CXP는 "나는 어떤 구현의 근거로도 삼으려는 의도가 없고 공식적 지위가 없다"고 말합니다. 완성된 스펙이 미완성 스펙에 보안을 위임하고 있는 구조입니다. 이게 이 글의 핵심입니다.

CXF는 이 공백을 인식하고 탈출구를 하나 열어 뒀습니다. 같은 §5.1이 이렇게 규정합니다 — orchestrating party(교환을 중개하는 주체)는 CXP를 구현하지 않고 CXF만 구현해도 된다(MAY). 대신 CXP를 구현하지 않는다면 개발자는 반드시(MUST) 해당 자격증명 교환의 보안 메커니즘을 문서화하고, 그 문서를 공개 웹사이트에 게시해야 합니다. 게시 문서에는 중개자가 데이터를 전달만 한다는 것, 데이터를 보존하거나 다른 용도로 쓰지 않는다는 것, 받은 데이터를 변조하지 않고 넘긴다는 것을 명시해야 합니다.

솔직하게 읽자면 이건 표준화된 암호 프로토콜을 각 벤더의 자체 문서화 약속으로 대체하는 것입니다. 없는 것보다는 낫지만, 상호운용 가능한 보안 보장과는 다릅니다. 검증 가능한 프로토콜 대신 "우리는 이렇게 합니다"라는 공개 선언을 받는 셈이니까요.

실제로 배송된 것 — OS가 중개하는 같은 기기 내 전송

그럼 Apple과 Google이 2026년에 실제로 내보낸 건 뭘까요. 여기서 위의 긴장이 어떻게 해소됐는지가 보입니다.

Apple. ASCredentialExportManager와 ASCredentialImportManager가 iOS 26.0, iPadOS 26.0, macOS 26.0, Mac Catalyst 26.0, visionOS 26.0에 들어갔습니다. Apple 개발자 문서를 그대로 읽으면 동작이 명확합니다.

The operating system acts as an intermediary to establish the identities of the
password manager apps involved and performs the exchange; this process doesn't
write any data to the file system.

OS가 중개자로서 양쪽 앱의 신원을 확인하고 교환을 직접 수행하며, 이 과정에서 파일 시스템에는 아무 데이터도 쓰지 않습니다. 앱은 익스텐션 plist에 SupportsCredentialExchange를 선언하고 SupportedCredentialExchangeVersions에 지원 버전을 배열로 적어야 하는데, Apple 문서에 따르면 현재 가능한 값은 1.0 하나뿐입니다.

이 설계를 보면 CXP가 왜 없어도 됐는지 알 수 있습니다. 같은 기기 안에서 OS가 신뢰된 중개자 역할을 하면, 두 제공자가 서로를 인증하고 채널을 협상할 필요가 없습니다. 평문 CXF 페이로드가 디스크에 떨어지지 않고 OS 경계 안에서만 움직이니까요. 다시 말해 Apple은 CXP를 구현한 게 아니라 CXP가 풀려던 문제를 우회한 것입니다. 플랫폼 통제권으로 프로토콜을 대체한 셈입니다.

Google. Google Play services v26.21(2026-06-01) 릴리스 노트의 Security & Privacy 항목은 이렇게 적혀 있습니다 — "[Phone] You can now import and export passwords and passkeys between Google Password Manager and third-party password managers with the Credential Exchange standard."

여기서 정확해야 합니다. Google의 공식 릴리스 노트는 "Credential Exchange standard"라고만 하고 CXP를 지목하지 않습니다. 일부 매체는 "Android가 CXP와 CXF를 지원한다"고 썼지만, 그건 2차 출처의 해석입니다. Google 자신의 문구는 그보다 모호하고, 태그도 [Phone]뿐입니다. 그리고 관련 SDK 아티팩트인 com.google.android.gms:play-services-identity-credentials는 Google의 Maven 저장소 기준으로 최신 버전이 여전히 16.0.0-alpha11입니다(마지막 갱신 2026-02-09). alpha01부터 alpha11까지 왔고, 아직 beta도 아닙니다.

정리하면 양쪽 다 실제로 배송한 것은 같은 기기 안에서 OS가 중개하는 앱 간 이전입니다. 기기를 건너뛰는 전송, 생태계를 건너뛰는 전송 — CXP가 담당해야 할 바로 그 부분 — 은 아직입니다.

옮겨지지 않는 패스키들

CXF에는 실무자가 놓치기 쉬운 규범적 제약이 둘 있습니다. 둘 다 "일부 패스키는 애초에 내보낼 수 없다"는 이야기입니다.

첫째, 서명 카운터가 0이 아닌 패스키. CXF 스펙 Passkey 절의 Note를 그대로 옮기면 이렇습니다.

Note: Passkeys using a non-zero signature counter MUST be excluded from the export
and the exporter SHOULD inform the user that such passkeys are excluded from the
export. Importers MUST set a zero value for the imported passkey signature counters
and MUST NOT increment them after the fact.

내보내는 쪽은 서명 카운터가 0이 아닌 패스키를 반드시 제외해야 하고(MUST), 가져오는 쪽은 가져온 패스키의 카운터를 0으로 두고 이후 증가시키면 안 됩니다(MUST NOT). 서명 카운터는 원래 인증자 복제를 탐지하려고 만든 장치인데, 이식성과는 원리적으로 충돌합니다. 복제를 탐지하는 메커니즘과 합법적으로 복제하는 기능은 같이 갈 수 없으니까요. 스펙은 이 충돌을 이식성 쪽으로 해결했고, 그 대가로 카운터를 쓰는 자격증명은 교환에서 빠집니다.

여기서 스펙을 정확히 읽어야 합니다. WebAuthn Level 3 §6.1.1에 따르면 RP는 저장해 둔 카운터와 새로 받은 signCount를 비교하되, 복제 의심 판정은 "둘 중 하나라도 0이 아니고(If either is non-zero), 새 값이 저장된 값보다 작거나 같을 때" 발동합니다. 즉 카운터가 계속 0인 패스키는 이 검사에 애초에 걸리지 않습니다. 스펙은 카운터를 구현하지 않는 인증자가 signCount를 0으로 고정한다는 것도 명시하고 있으니, 0은 스펙이 예상한 정상 값입니다.

그래서 정직하게 말하면, 가져오기로 들어온 패스키에서 일어나는 일은 "오탐으로 잠긴다"가 아니라 복제 탐지 신호를 그냥 잃는 것입니다. CXF는 이식성을 위해 클론 디텍션을 교환한 셈입니다. 다만 스펙보다 엄격한 로직 — 예컨대 "카운터는 항상 증가해야 한다"고 직접 구현한 경우 — 을 굴리고 있다면 이야기가 다릅니다. 그 로직은 스펙이 정상이라고 규정한 값에 걸려 정상 사용자를 막게 됩니다. 참고로 스펙은 카운터 불일치가 복제인지 오작동인지 경합 조건인지 구분해 주지 않는다고 명시하며, 대응은 각 RP의 위험 감수 수준에 맡깁니다.

둘째, 하드웨어 보안키. 이건 더 근본적입니다. FIDO Alliance의 공식 피드백 저장소(fido-alliance/credential-exchange-feedback)에 CTAP 구현자가 "하드웨어 인증자에 있는 자격증명을 다른 인증자로 옮기려면 어떤 표준을 봐야 하냐"고 물었습니다(이슈 #33, 2025-08-02). fido-alliance GitHub 조직 멤버의 답은 이랬습니다.

No certified FIDO hardware authenticator allows a credential to leave its secure
element, so what you're asking for does not exist, by design.

인증된 FIDO 하드웨어 인증자는 자격증명이 보안 요소를 떠나는 걸 허용하지 않으며, 이는 설계상 그렇다는 것입니다. 같은 스레드에서 그는 자격증명 교환이 CTAP과는 아무 관계가 없고, 대상은 "credential manager 사이의 마이그레이션"이라고 못 박았습니다.

두 제약을 합치면 그림이 선명해집니다. 자격증명 교환은 소프트웨어 자격증명 관리자끼리의 마이그레이션 도구입니다. YubiKey에 든 패스키를 옮기는 이야기가 아니고, 앞으로도 아닐 겁니다. 하드웨어 키를 쓰는 조직이 "이제 패스키가 이식 가능하다"는 헤드라인을 보고 백업 전략을 세우면 잘못된 전제 위에 세우는 겁니다. 하드웨어 키의 백업 전략은 여전히 "두 개 이상 등록하라"입니다.

아직 안 풀린 것 — 내보내기 거부와 락인

이식성 스펙이 정작 락인을 막느냐는 질문이 있습니다. 2025년 1월 21일에 열린 이슈 #24 "Risk of lock-in from export blocking"이 이 문제를 정면으로 제기합니다. 요지는 이렇습니다 — CXP는 제공자가 내보내기 요청을 거부하거나 선별 승인할 여지를 남기는 것으로 보이는데, 그러면 제공자 FOO가 가격을 올렸을 때 경쟁사 BAR로의 내보내기만 골라서 막을 수 있고, 사용자의 자격증명은 인질이 된다는 것입니다. 제기자는 이를 "permissionlessly exportable"(현재 제공자의 허락 없이 내보낼 수 있는 성질)이 스펙 범위에 들어가야 하는가의 문제로 정리했습니다.

주목할 만한 건 답변입니다. CXF 기여자로 이름이 올라 있는 FIDO 측 참여자가 2025년 3월에 "우려는 충분히 들었고 Alliance 내부에서 논의가 많았다"고 했고, 5월에는 이렇게 덧붙였습니다.

The general vibe is supportive and language has been added to this effect, though
it looks like we haven't done a public working draft in some time so I don't think
that's externally visible yet.

내부적으로는 관련 문구가 추가됐지만 공개 워킹 드래프트를 낸 지 오래돼서 외부에서는 아직 안 보인다는 겁니다. 그리고 2026년 7월 현재도 여전히 안 보입니다 — 공개된 최신 CXP는 그때나 지금이나 2024년 10월 3일 워킹 드래프트니까요. 이슈는 열린 채입니다.

이건 스펙 프로세스를 비난할 일은 아닙니다. 회원 대외비로 작업하는 건 FIDO의 오랜 방식이고, 표준은 원래 느립니다. 다만 실무자 입장에서 정직하게 말하자면, 락인 방지 문구가 실제로 어떻게 쓰였는지 우리는 읽을 수 없고, 읽을 수 없는 보장은 계획에 넣을 수 없습니다.

같은 이슈 스레드에서 나온 반론도 기록해 둘 만합니다. 한쪽은 "제3자 서비스를 쓰기로 한 이상 어떤 로그인 방식이든 마찬가지 아니냐"고 했고, 제기자는 Firefox 같은 로컬 오픈소스 소프트웨어는 업데이트가 내보내기를 막아도 구버전을 설치하거나 코드를 고칠 수 있지만 보안 요소에 든 자격증명은 제조사·운영자의 허락이 원리적으로 필요하다고 반박하며, 도메인 등록대행사와 ICANN의 관계를 유비로 들었습니다. 어느 쪽이 옳다고 여기서 판정할 생각은 없습니다. 다만 이 논쟁이 2025년 1월부터 미해결로 열려 있다는 사실 자체가, 이식성이 기술 문제이기 이전에 거버넌스 문제라는 걸 보여 줍니다.

그래서 지금 무엇을 해야 하나

실무 판단으로 옮기면 이렇습니다.

지금 기대해도 되는 것

같은 기기 안에서 자격증명 관리자를 바꾸는 시나리오. iOS/iPadOS/macOS/visionOS 26, 그리고 Android(Play services 26.21 이상, 현재 [Phone])에서 실제로 동작합니다.
CSV 내보내기를 대체하는 것. 이게 CXF의 진짜 성취입니다. CXP 스펙 서문 자체가 문제 정의로 CSV를 지목합니다 — 안전하지 않은 포맷, 표준 구조의 부재로 인한 마이그레이션 실패. 구조화된 JSON 스키마가 생긴 것만으로도 이 두 가지는 개선됩니다.
비밀번호·TOTP·기타 항목까지 함께 옮기는 것. CXF는 패스키 전용이 아니라 자격증명 관리자 안의 여러 항목 타입을 정의합니다.

아직 계획에 넣으면 안 되는 것

기기 간·생태계 간 전송. iPhone에서 Android로 패스키를 직접 넘기는 것은 CXP의 일이고, CXP는 아직 공개 워킹 드래프트입니다.
하드웨어 보안키의 마이그레이션이나 백업. 설계상 존재하지 않습니다. 두 개 이상 등록하는 것이 여전히 유일한 답입니다.
파일로 내보내 사용자가 직접 보관하는 백업. 현재 배송된 경로는 OS 중개 앱-대-앱이고, Apple 문서 기준으로 파일 시스템에 아무것도 쓰지 않습니다. 이슈 #24에서 한 참여자가 지적했듯 "내가 쥐고 있는 사본"을 원하는 요구와 현재 설계는 방향이 다릅니다.
제공자가 내보내기를 거부하지 않으리라는 보장. 공개된 스펙에는 아직 그 보장이 없습니다.

RP를 운영한다면 확인할 것

서명 카운터 로직이 스펙보다 엄격하지 않은지. WebAuthn의 복제 탐지는 값이 0이 아닐 때만 발동하므로 표준대로 구현했다면 가져온 패스키는 조용히 통과합니다. 하지만 "카운터는 반드시 증가해야 한다"를 직접 구현해 뒀다면 정상 사용자를 막습니다. 그리고 어느 쪽이든, 가져온 패스키에 대해서는 카운터 기반 복제 탐지가 더 이상 신호를 주지 않는다는 사실은 그대로입니다.
백업 상태(BE/BS) 플래그를 어떻게 쓰고 있는지. 이슈 #33 스레드에서 FIDO 측 답변이 짚었듯, BE/BS는 "공유 가능 여부"가 아니라 동기화 패스키인지 기기 귀속 패스키인지, 그리고 인증자가 현재 백업됐다고 믿는지를 신호할 뿐입니다. 이 플래그를 공유 여부로 해석하는 정책이 있다면 전제가 틀린 것입니다.
계정 복구 경로. 이식성이 좋아진다고 복구가 해결되지는 않습니다. 관리자를 바꿀 수 있게 된 것과 기기를 다 잃었을 때 돌아올 수 있는 것은 다른 문제이고, 후자는 여전히 각 RP의 숙제로 남아 있습니다.

마치며

정리하면 이렇습니다. 자격증명 교환은 두 개의 스펙이고, 완성도가 다릅니다. CXF는 무엇을 주고받을지를 정의했고 Proposed Standard가 됐습니다 — 실제 성취이고, CSV의 시대를 끝낼 물건입니다. CXP는 어떻게 주고받을지를 정의해야 하는데 2024년 10월 워킹 드래프트에서 멈춰 있고, 그 문서는 자기가 구현 근거가 아니며 공식적 지위가 없다고 스스로 적어 두었습니다. 그런데 CXF가 실어 나르는 페이로드에는 PKCS#8 평문 개인키가 들어 있고, CXF의 보안 고려사항은 기밀성을 CXP에 위임합니다.

플랫폼들은 이 공백을 프로토콜이 아니라 통제권으로 메웠습니다. OS가 중개자가 되어 같은 기기 안에서 교환을 수행하고 디스크에는 아무것도 쓰지 않습니다. 영리한 해법이고 실제로 동작하지만, 이건 "패스키가 이식 가능해졌다"가 아니라 "한 기기 안에서 관리자를 바꿀 수 있게 됐다"입니다. 그 사이의 거리가 정확히 CXP가 채워야 할 자리이고, 그 자리는 아직 비어 있습니다.

그러니 헤드라인이 아니라 스펙 디렉터리의 파일명을 보십시오. cxp-v1.0-wd-20241003.html — 저 날짜가 바뀌기 전까지, 생태계를 넘나드는 패스키 이식성은 로드맵이지 기능이 아닙니다.