생체 인증과 다이내믹 링킹에서의 지급인 인식

Corbado의 접근 방식은 피싱 방지 패스키(SCA)를 은행이 제어하는 디스플레이 및 서버 측 다이내믹 링킹과 결합하여 PSD2 RTS 제5조("보는 것이 서명하는 것")를 충족합니다.

• 핵심 구현(현재): 우리는 패스키 인증 직전과 인증 중에 Bison 은행이 제어하는 UI에 거래 금액과 수취인을 표시합니다. 우리 백엔드는 정규화된 거래 스냅샷(금액, 수취인, txnId)에 바인딩된 일회성 챌린지를 생성합니다. 응답은 해당 스냅샷과 일치하는 경우에만 수락되며, 어떤 변경이라도 있으면 무효화됩니다.

• 규제 입장: 패스키를 사용하더라도 원격 결제에는 다이내믹 링킹이 여전히 필수입니다(PSD2 제97조 2항, RTS 제5조). RTS는 다이내믹 링킹 "인증 코드"가 기기에서 계산될 것을 요구하지 않습니다. 디스플레이 무결성, 특정성, 변경 시 무효화가 강제된다면 서버 측 생성/검증이 허용됩니다(코드가 계산될 수 있는 위치에 대한 EBA Q&A 2020_5366 참조).

• 보안 및 감사 가능성: 하드웨어에 고정된 피싱 방지 패스키 서명을 특정 거래 데이터에 바인딩하면 조작 및 중계를 방지하고, 지급인 동의에 대한 강력하고 부인 방지 증거를 생성합니다. 지원되는 경우, 우리는 백엔드 모델을 변경하지 않고 표시된 세부 정보에 대한 암호화 증명을 추가하기 위해 **보안 결제 확인(SPC)**을 선택적으로 채택할 수 있습니다.

• SCA: 서로 다른 범주(지식/소유/생체)의 두 가지 독립적인 요소로, 적절한 완화 조치를 통해 공개/복제로부터 보호됩니다(RTS 제6-8조). 독립성이 요구되며(제9조), 다목적 기기에서 실행될 때 분리를 포함합니다(예: OS 수준 보호, 보안 하드웨어).
• 다이내믹 링킹(RTS 제5조):
  • (i) 지급인은 인증 중에 금액과 수취인을 인지해야 합니다.
  • (ii) 인증 코드는 해당 금액/수취인에 고유해야 합니다.
  • (iii) 어떤 변경이라도 코드를 무효화합니다.
  • (iv) 금액, 수취인, 코드의 기밀성/무결성은 종단 간 보호되어야 합니다. 이는 규제상의 "보는 것이 서명하는 것" 의도를 충족합니다.
• 함의: 강력한 사용자 인증만으로는 결제에 충분하지 않습니다. 승인은 특정 거래 데이터에 바인딩되어야 하며, 바인딩과 지급인에게 표시된 내용에 대한 감사 가능한 증거가 있어야 합니다(RTS 제5조 1항 a–d).

설명 — 피싱 대 인증: 패스키는 출처에 바인딩되므로 가짜 도메인은 유효한 서명을 이끌어낼 수 없습니다. 그러나 PSD2는 원격 결제에 대해 _인증_을 정확한 금액과 수취인에 바인딩하여 어떤 변경이라도 무효화하고 지급인에게 표시되는 내용의 무결성을 보호하기 위해 여전히 다이내믹 링킹을 요구합니다(RTS 제5조 1항 a–d). 다이내믹 링킹은 피싱뿐만 아니라 인증 무결성(MITM/MITB/TPP 대체 포함)을 다룹니다.

EBA 2019 의견서(EBA‑Op‑2019‑06)는 다이내믹 링킹이 인증을 금액과 수취인에 바인딩하고, 요소의 독립성을 요구하며, 고유한 기기 바인딩이 존재하는 경우 기기 바인딩 암호화 키를 소유로 인정한다는 점을 강화합니다. 또한 인증 중 지급인에게 표시되는 내용의 무결성을 강조합니다. EBA Opinion 2019

PSD2 이전에는 많은 은행이 SMS OTP나 인쇄된 TAN 목록에 의존했는데, 이는 종종 승인 단계에서 금액이나 수취인을 보여주지 않았습니다. 이 격차는 자격 증명이 도난당했을 때 고객을 속여 의도하지 않은 이체를 승인하도록 만들기 더 쉽게 만들었습니다. 다이내믹 링킹은 지급인이 인증 시점에 정확한 금액과 수취인을 인지하도록 보장하고, 인증 코드를 해당 세부 정보에 특정하여 변경 시 무효화함으로써 그 격차를 메우기 위해 도입되었습니다(RTS 제5조 1항 a–d). SMS가 흐름의 일부인 경우, 발급사는 인증의 모든 단계에서 금액/수취인 및 코드의 기밀성, 인증성, 무결성을 보장해야 합니다(Q&A 2018_4414; RTS 제5조 2항). 오늘날의 인앱 승인(예: "Face ID를 통해 John Smith에게 100달러를 승인하시겠습니까?")은 이 "보는 것이 서명하는 것" 원칙을 고객 친화적인 방식으로 구현합니다.

오늘날 모바일에서는 두 가지 패턴이 지배적입니다. 첫째, 푸시 알림은 고객을 앱으로 딥링크하여 거래 세부 정보를 검토하고 승인하도록 할 수 있습니다. 감독 당국은 제7조 통제가 무단 사용을 완화하고 복제를 방지하기 위해 마련되어 있고 전체 여정이 RTS를 준수하는 경우 푸시가 소유 요소의 증거로 사용될 수 있다고 밝혔습니다. 그럼에도 불구하고 사회 공학적 위험은 남아 있으며 UX에서 해결해야 합니다(Q&A 2019_4984; RTS 제7조).

둘째, 기기의 기본 생체 인증(PIN 대체 포함)을 사용한 승인은 개인 키 작업을 잠금 해제하기 위해 로컬에서 사용자 확인을 수행합니다. 개인 키는 보안 하드웨어 환경(Secure Enclave/TEE/TPM)에 있으며 챌린지에 서명합니다. 이는 SCA에 명확하게 매핑됩니다: 생체(생체)와 기기 바인딩 및 기기 바인딩 암호화 키로 입증된 소유(EBA-Op-2019-06, 25, 35-37 단락). 원격 결제의 경우, 코드는 금액 및 수취인과 동적으로 연결되어야 하며 해당 세부 정보는 사용자 확인 전에 지급인에게 표시되어야 합니다(RTS 제5조). 두 요소가 모두 한 기기에 있는 경우, 별도의 보안 실행 환경과 무결성 검사를 구현하여 하나가 손상되어도 다른 하나가 손상되지 않도록 해야 합니다(RTS 제9조 2-3항).

내부적으로 로컬 생체 인증은 은행에 직접 "인증"하지 않습니다. 대신 생체 인증(또는 PIN 대체)은 기기에서 사용자 확인을 수행하고 하드웨어 기반 보안 모듈에 저장된 내보낼 수 없는 개인 키에 대한 접근을 제어합니다. 지급인이 승인하면 기기는 해당 개인 키를 사용하여 은행이 제공한 챌린지에 대한 디지털 서명을 생성합니다. 은행이 해당 챌린지를 거래의 정규화된 스냅샷(금액, 수취인, 식별자)에서 파생하거나 연결하면, 결과 서명은 해당 세부 정보에 특정한 인증 코드 역할을 합니다. 어떤 변경이라도 저장된 스냅샷이 더 이상 일치하지 않거나, 향상된 설계에서는 챌린지 파생이 변경되기 때문에 코드를 무효화합니다. 지급인 인식 부분은 UX 요구사항으로 남습니다: 사용자 확인 직전에 은행이 제어하는 뷰에 금액과 수취인을 표시합니다. 이 모든 것이 함께 인식, 특정성/고유성 및 변경 시 무효화에 대한 RTS 제5조의 요구사항을 충족하며, 제7조 통제 및 기기 바인딩은 소유 요소를 입증합니다.

• 소유 (기기 바인딩 및 동기화 키): 패스키 개인 키는 보안 하드웨어(TEE/Secure Enclave/TPM)에 저장됩니다. 기기 바인딩 패스키는 내보낼 수 없으므로 고유한 기기 바인딩에 대한 EBA의 기대와 일치합니다(EBA‑Op‑2019‑06, 25, 35–37 단락). 동기화된 패스키도 기기 바인딩 및 복제 방지 통제가 효과적인 경우 각 인증 시 소유를 입증할 수 있습니다. 규제 당국은 요소와 기기 간의 신뢰할 수 있는 연결의 필요성을 강조했습니다(EBA‑Op‑2019‑06; RTS 제7조).
• 생체/지식 (사용자 확인): 생체(생체) 또는 기기 PIN(지식)을 통한 사용자 확인은 로컬에서 키를 활성화합니다. 소유와 결합하면 이는 요소 독립성을 갖춘 진정한 2단계 인증입니다. 하나가 침해되어도 다른 하나는 손상되지 않습니다.

다이내믹 링킹은 인증을 거래에 바인딩하는 것입니다. 은행의 질문은 이것입니다: 사용자가 패스키(예: OTP나 서명 장치 대신)를 통해 결제를 승인하도록 허용한다면, 이 승인이 의도된 금액과 수취인에 특정하며 재사용되거나 조작될 수 없음을 보장할 수 있는가?

패스키로 다이내믹 링킹을 구현하는 두 가지 옵션이 있습니다:

• 서버 측 연결 (표준): 백엔드가 정확한 금액 및 수취인과 연결하는 일회성 WebAuthn 챌린지를 생성합니다. 사용자는 은행 제어 뷰에서 "Y에게 X 유로"를 보고 패스키로 승인합니다. 응답은 해당 거래에 대해서만 수락됩니다. 어떤 변경이라도 있으면 무효화됩니다.
• 암호화 포함 (향상): 금액/수취인의 해시를 챌린지에 포함하여 서명이 거래 데이터를 확약하도록 합니다. 이는 RTS에서 요구하지는 않지만 백엔드 교체 시도조차 검증에 실패할 것이라는 확신을 더합니다.

명시적 규정 준수 참고: RTS는 다이내믹 링킹 "인증 코드"가 지급인의 기기에서 계산될 것을 요구하지 않습니다. PSP는 금액/수취인이 보호되고 어떤 변경이라도 코드를 무효화하는 한 서버에서 생성하고 검증할 수 있습니다(코드의 위치/시점에 대한 EBA Q&A 2020_5366 참조). 이것이 우리의 서버 측 다이내믹 링킹 (표준) 접근 방식입니다.

두 방법 모두 거래에 특정한 고유하고 재사용할 수 없는 "인증 코드"를 생성합니다. 주요 주의 사항은 지급인 인식입니다: WebAuthn 자체는 무엇이 표시되었는지 증명하지 않습니다. 디스플레이의 무결성은 은행이 제어하는 UI에서 와야 합니다.

RTS 제5조는 지급인이 인증 중에 금액과 수취인을 볼 것을 요구합니다. WebAuthn은 무엇이 표시되었는지 증명하지 않습니다. 이론적으로 앱이나 OS가 손상되면 사용자는 속을 수 있고, 인증자는 여전히 서명할 수 있습니다. 이 위험이 실제로는 어떻게 작용하며 왜 실제 보안 위험이 아니라 규정 해석의 문제인지 아래에서 자세히 분석하겠습니다.

우리가 시행하는 디스플레이 무결성 통제:

• 은행 제어 뷰는 금액 + 수취인을 렌더링합니다: 뷰가 가려지거나 초점이 맞지 않으면 패스키 호출을 차단합니다.
• 앱/웹에서의 오버레이/조작 탐지: 숨겨진 iframe에서 패스키 프롬프트 없음
• 기기 무결성/증명 게이팅: 루팅/탈옥/손상된 신호에 대해 거부 또는 단계적 강화
• 서버에 저장된 금액/수취인 스냅샷에 대한 원자적 승인: 매개변수 변경 시 새로운 챌린지 필요

암호화 포함에 대하여: WebAuthn "거래 표시" 확장 기능(SPC)은 오늘날 널리 지원되지 않습니다. 우리의 이식 가능한 기준은 서버 측 바인딩이며, 거래 스냅샷(예: H(금액 ‖ 수취인 ‖ txnId ‖ 논스))에서 챌린지를 파생하여 서명이 해당 값에 확약하도록 강화합니다.

두 패턴 모두 내보낼 수 없는 기기 키를 사용하는 공개 키 암호화를 사용하며, 서명 작업을 잠금 해제하기 위해 로컬 사용자 확인에 의존합니다. 두 경우 모두 은행은 사용자 확인 직전에 은행 제어 뷰에 금액과 수취인을 표시하여 지급인 인식을 보장하고, 인증 코드를 해당 세부 정보에 바인딩하여 변경 시 무효화함으로써 특정성을 보장합니다(RTS 제5조 1항 a-d). RTS는 기술 중립적이며 금액/수취인이 OS 생체 인증 모달 내에서 렌더링될 것을 요구하지 않습니다. 지급인에게 표시하고 코드를 바인딩할 것을 요구합니다(RTS 제5조). 두 SCA 요소가 한 기기에서 실행될 때, 제9조의 무결성 및 분리 요구사항이 동일하게 적용됩니다(RTS 제9조 2-3항). 마지막으로, 다이내믹 링킹 계산의 위치는 유연합니다: 무결성이 보존되고 변경 시 코드가 무효화된다면 서버 측에서 수행될 수 있습니다(Q&A 2020_5366). 이는 규제 당국이 이미 PKI를 사용한 로컬 생체 인증을 수용하는 것과 동일한 조건이므로, 동일한 지급인 인식 및 바인딩 통제로 구현된 패스키도 동등한 기준으로 수용되어야 합니다.

그렇다면, WebAuthn 표준에 따른 일반 패스키가 다이내믹 링킹의 _의도_를 충족하는가? 부분적으로 그렇습니다:

• MITM/네트워크 공격: 예. 출처 바인딩 및 챌린지별 서명은 조작 및 재전송을 방지합니다.
• 거래 무결성: 예. 서버 연관 또는 챌린지 해싱은 원래 금액/수취인만 검증되도록 보장합니다.
• 지급인 동의: 더 어렵습니다. 패스키에는 인증자 수준의 디스플레이가 없습니다. 손상된 기기에서의 UI 기만은 가능할 수 있습니다. 지급인 동의를 보장하기 위해 그 위에 무언가를 구축해야 합니다.

패스키에 다이내믹 링킹이 여전히 필요한 이유

• 법률: PSD2 제97조 2항 및 RTS 제5조는 모든 원격 결제 개시에 대해 다이내믹 링킹을 의무화합니다. 피싱 방지 방법에 대한 예외는 없습니다.
• 보안: 패스키는 교차 출처 피싱을 제거하지만, 그 자체로 지급인에게 무엇이 표시되었는지 증명하지는 않습니다. 다이내믹 링킹 + 디스플레이 무결성 통제는 사용자가 본 특정 금액/수취인이 은행이 실행하는 것과 일치하도록 보장하고, 어떤 변경이라도 승인을 무효화하도록 합니다.

요약하자면, 패스키는 거래 데이터에 엄격하게 바인딩되고 신뢰할 수 있는 디스플레이 메커니즘과 결합될 때 다이내믹 링킹을 충족할 수 있습니다. 남은 과제는 사용자가 실제로 무엇을 보았는지 증명하는 것입니다.

Corbado는 위에서 언급한 지급인 동의 고려사항을 명시적으로 다루는 다이내믹 링킹 준수 솔루션을 제공합니다.

// TODO: KARUNA의 목업 제공 및 설명 추가

프로세스 흐름:

• 은행 제어 디스플레이는 지급인에게 정확한 금액과 수취인을 보여줍니다. 이 뷰가 보이지 않으면 패스키 프롬프트가 표시되지 않습니다.
• 인증: 클라이언트는 정규화된 거래에 대해 일회성, 바인딩된 챌린지로 WebAuthn을 호출합니다. 인증자는 사용자 확인(생체 또는 기기 PIN)을 수행하고 챌린지 및 출처에 서명합니다.
• 서버 검증: 백엔드는 RP ID 해시 및 출처를 확인하고, 챌린지를 저장된 거래와 일치시키고, UV/플래그를 확인하고, 일회성 사용 및 만료를 강제하고, 저장된 금액/수취인 스냅샷을 비교합니다.
• 승인 및 감사: 그래야만 거래가 원자적으로 승인됩니다. 불일치/변경은 거부되고 새로운 인증이 필요합니다. 불변의 감사 기록이 유지됩니다(자격 증명 ID, authenticatorData, clientDataJSON, 서명, 챌린지 및 정규화된 금액/수취인), 선택적으로 조작 방지를 위해 해시 체인으로 연결됩니다.
• 기기 무결성 게이트: 기기 무결성 및 증명 신호를 평가합니다: 기기가 루팅/탈옥/손상된 경우 거부 또는 단계적 강화.
• 수취인 정규화: 친숙한 레이블(예: "ACME GmbH")을 표시하지만, 정규화된 수취인 식별자(예: IBAN/BIC 또는 기타 고유 체계)에 대해 바인딩하고 검증합니다.

기술적 세부사항:

• 백엔드: 정규화된 데이터(예: 정규화된 통화/소수점, 정규화된 IBAN/수혜자)로 거래 객체를 생성합니다. 이러한 값에 확약하는 단기 챌린지를 생성합니다(예: H(금액||수취인||txnId||논스)); 보류 상태로 저장하고 클라이언트에는 불투명 ID만 노출합니다.
• 클라이언트/인증자: 은행 제어 뷰에 지급인 세부 정보를 렌더링합니다; 보일 때만 WebAuthn(RP ID = Bison 도메인)을 호출합니다; 사용자 확인을 요구합니다; WebAuthn에 따라 인증자가 챌린지 + 출처에 서명합니다.
• 검증/완료: 서명, RP ID 해시, 출처/유형, UV 플래그를 검증합니다; 재전송 방지/만료; 불변의 금액/수취인 스냅샷을 비교합니다; 원자적으로 승인합니다; 감사 기록을 유지합니다.
• 스냅샷에서 챌린지 파생: challenge = H(금액 ‖ 정규화된 수취인 ‖ txnId ‖ 논스)

UX 정책:

• 금액/수취인에 대한 명확한 강조; 접근 가능한 확인/취소 제어; 짧은 시간 초과; 항상 새로운 챌린지를 사용하는 정상적인 재시도; 즉각적인 영수증(예: "Y에게 X 유로를 승인했습니다"). 디스플레이가 가려지면 패스키 프롬프트를 차단하고 서명 전에 매개변수가 변경되면 경고합니다.
• 오버레이/가려진 콘텐츠 감지: 거래 뷰가 보이지 않으면 절대 패스키 프롬프트를 표시하지 않습니다. 흐름 중간에 매개변수가 변경되면 거부하고 새로운 챌린지로 다시 시작합니다.

규정 준수 참고: 이 엔드투엔드 설계는 RTS 제5조를 충족합니다: 지급인 인식(은행 제어 디스플레이), 특정성 및 고유성(금액/수취인에 바인딩된 일회성 코드), 변경 시 무효화(엄격한 서버 검사), 및 모든 단계에서 금액/수취인 및 코드의 기밀성/무결성(RTS 제5조 1항 a-d, 5조 2항; SMS 무결성에 대한 Q&A 2018_4414 참조). 기기 바인딩 소유 및 적절한 보호를 갖춘 다목적 기기에서의 로컬 사용자 확인을 통해 요소 독립성(제7-9조)이 보존됩니다(RTS 제9조 2-3항).

참고:* 웹 흐름의 경우, Corbado는 Apple이 광범위하게 지원할 경우 선택적으로 [보안 결제 확인](https://www.w3.org/TR/payment-request-secure-payment-confirmation/)을 채택하여, 금액과 수취인을 암호화적으로 증명하는 신뢰할 수 있는 브라우저 중재 디스플레이를 추가할 것입니다.

우려: 피싱 공격 대응: 패스키는 설계상 피싱에 강합니다: 합법적인 출처에 바인딩되어 있고 공유 비밀이 없으므로 OTP와 달리 가짜 사이트에서 자격 증명을 수집할 수 없습니다. 유사한 도메인으로 트래픽을 프록시하는 공격자는 은행의 출처에 대한 유효한 서명을 얻을 수 없습니다. 다이내믹 링킹은 이 벡터에서 기여도가 적지만, 모든 승인이 의도된 금액과 수취인에 고유하도록 보장하기 위해 여전히 필수적입니다. 보완 조치(피싱 교육, 로그인과 결제 승인의 명확한 분리, 비정상적인 결제 컨텍스트에 대한 이상/위험 점수화)는 노출을 더욱 줄입니다.

우려: 사회 공학 / 승인된 푸시 결제(APP) 사기 대응: 어떤 인증자도 사용자가 거짓된 명목으로 결제를 승인하는 것을 완전히 막을 수는 없습니다(예: "안전 계좌" 사기). 다이내믹 링킹은 사용자가 수취인과 금액을 명시적으로 보도록 보장하고 동의에 대한 강력한 증거를 제공하지만, 확신에 찬 지급인을 막을 수는 없습니다. 보완 조치에는 상황에 맞는 경고(새로운 수취인, 첫 대규모 이체), 고위험 수취인에 대한 유예 기간 또는 지연 실행, 더 강력한 수취인 확인, 위험 신호에 대한 단계적 확인(추가 확인)이 포함됩니다. 결제 후 알림과 신속한 분쟁 채널은 피해를 감지하고 억제하는 데 도움이 됩니다. 우리는 실시간 상황에 맞는 경고(예: 새로운 수취인, 첫 대규모 이체), 고위험 수취인에 대한 유예 기간, 더 강력한 수취인 확인 및 결제 후 알림("Y에게 X 유로를 승인했습니다")을 추가하여 감지 및 대응 속도를 높입니다.

우려: 악성코드 또는 기기 손상 대응: 개인 키는 내보낼 수 없으며 각 서명에 대해 로컬 사용자 확인이 필요하므로 악성코드는 단순히 자격 증명을 유출할 수 없습니다. 현실적인 위험은 완전히 손상된 OS에서의 UI 기만입니다. 보안/검증된 UI(예: 보호된 확인), 기기 무결성 검사/증명 및 고위험 기기 차단, SPC 또는 사용 가능한 경우 확인 확장 기능과 같은 신뢰할 수 있는 확인으로 완화합니다. 손상 지표(오버레이 감지, 루팅/탈옥)가 나타나면 대역 외 재확인을 사용하거나 실행을 거부합니다. 완전히 소유된 기기에서는 완벽한 소비자 방법은 없지만, 이러한 통제는 창을 극적으로 좁힙니다.

우려: Man‑in‑the‑browser / 세션 하이재킹 대응: 악성 확장 프로그램이나 주입된 스크립트는 합법적인 출처에서 작업을 시작할 수 있습니다. 출처 바인딩 패스키는 교차 사이트 피싱을 막습니다. 다이내믹 링킹은 배후에서 금액/수취인을 편집하는 시도가 실패하도록 보장합니다. 우리는 CSP/조작 방지 통제를 통해 채널을 강화하고 각 확인에 대해 새로운 일회성 챌린지를 요구함으로써 이를 강화합니다.

우려: 내부자 위협 또는 서버 측 조작 대응: 인증 응답은 원래 금액/수취인과 고유하게 연결되어 있으므로 서버 측 대체 시도는 검증에 실패합니다. 감사/부인 방지를 위해 조작 방지, 불변의 연결 기록(챌린지, 자격 증명, 서명 및 정규화된 금액/수취인)을 유지합니다. 내부자 위험을 줄이기 위해 중요한 결제 처리 경로에 직무 분리 및 4안 통제를 적용합니다.

우려: 도난당한 기기 / 자격 증명 도난 대응: 단순한 기기 소유만으로는 불충분합니다: 각 서명에는 사용자 확인(생체/PIN)이 필요하며 OS 수준의 속도 제한 및 잠금 기능이 있습니다. 각 결제에는 새로운, 거래 특정 챌린지기 필요합니다; 일반 세션 토큰은 임의의 결제를 승인할 수 없습니다. 원격 기기 해지, 새 기기 사용 시 단계적 강화, 지리적 속도 확인 및 알림("Y에게 X 유로를 승인했습니다")과 같은 추가 기능은 남용을 더욱 제한합니다.

전반적으로: 패스키는 피싱 및 재전송 위험을 실질적으로 줄입니다. 다이내믹 링킹은 거래 무결성을 보장하고 승인을 금액/수취인에 바인딩하며 나머지 위협 시나리오에 걸쳐 정보에 입각한 동의에 대한 강력한 증거를 제공하는 데 필수적입니다.

질문 1: 패스키를 사용할 때 사용자가 실제로 금액과 수취인을 보고 동의했음을 어떻게 증명할 수 있나요? 응답: 이것은 본질적으로 부인 방지에 관한 질문입니다. PSD2 하에서 다이내믹 링킹은 사용자가 무엇을 승인하는지 인지하도록 보장하기 위한 것입니다. 우리의 프로세스는 강력한 증거를 제공합니다:

1. 은행 제어 디스플레이 및 서버 스냅샷: 우리는 은행이 제어하는 뷰에 금액과 수취인을 표시합니다. 패스키 승인은 이러한 세부 정보의 서버 측 스냅샷에 연결됩니다. 패스키 어설션은 해당 스냅샷에서 파생된 일회성 챌린지에 대해서만 수락됩니다. 어떤 변경이라도 새로운 챌린지를 요구하며 이전 것은 무효화됩니다.
2. 암호화 증거: 핵심 증거는 사용자의 기기에서 생성된 암호화 서명(인증 코드)입니다. 분쟁 발생 시, 우리는 사용자의 패스키가 "Y 수취인 ID에게 X 유로"와 고유하게 연결된 챌린지에 서명했음을 증명할 수 있습니다.
3. 조작 방지 감사: 우리 시스템은 패스키 응답을 특정 거래 데이터에 연결하는 조작 방지 감사 추적을 생성합니다. 이 로그는 세부 정보가 달랐다면 우리 시스템이 진행하지 않았을 것임을 보여줍니다.
4. 향후 개선 사항(SPC): 지원되는 경우, 우리는 **보안 결제 확인(SPC)**을 사용하여 사용자가 브라우저에 표시된 정확한 세부 정보를 확인했다는 더 강력한 암호화 증거를 추가할 수 있습니다.

질문 2: 기기나 OS가 손상되면 어떻게 되나요? 악성코드가 거래나 패스키 프로세스를 조작할 수 있나요? 응답: 기기 손상은 모든 디지털 뱅킹 시나리오에서 중요한 위협입니다. 운영 체제가 악의적이라면 사용자를 오도하거나 프로세스를 하이재킹하려고 시도할 수 있습니다. 그러나 이 최악의 경우에도 패스키는 몇 가지 핵심 보호 기능을 유지합니다. 개인 키는 악성코드에 의해 추출될 수 없습니다. 악성코드는 사용자의 생체/PIN 없이는 패스키 서명을 생성할 수 없으므로 은행에 사용자를 사칭할 수도 없습니다. 할 수 있는 최선은 사용자가 거짓된 명목으로 무언가를 인증하도록 유도하는 것입니다. 다이내믹 링킹은 무결성 검사를 요구함으로써 여기서 도움이 됩니다: 악성코드는 사후에 거래 세부 정보를 조용히 변경할 수 없습니다 – 만약 그렇게 한다면 서명이 검증되지 않을 것입니다. 가장 약한 지점은 디스플레이/UI입니다: 정교한 트로이 목마는 사용자가 보는 것을 변경할 수 있습니다(예: 기본 거래가 다른 수취인에게 가는 동안 "ACME Corp"를 표시). 이것은 특히 은행 앱이 보안 UI 프레임워크를 사용하는 경우 사소한 일이 아니지만, 상상할 수 있습니다. 그렇긴 하지만, 기기 손상 징후(비정상적인 행동, 알려진 악성코드 서명 등)를 감지하면 대역 외 검증으로 대체하거나 거래를 거부할 것입니다. 요약: 사용자의 기기가 공격자에게 완전히 소유된 경우 100% 해결책은 없습니다. 패스키 + 다이내믹 링킹은 공격 표면을 극적으로 줄입니다(공격자는 단순히 자격 증명을 프록시하거나 네트워크 데이터를 변경할 수 없으며, 실시간으로 사용자를 속여야 합니다). OS가 손상되더라도 다이내믹 링킹은 최소한 있어야 할 것과 승인된 것 사이의 불일치가 우리 백엔드에 의해 포착되도록 보장합니다.

질문 3: 패스키를 잠금 해제하는 데 생체 인증을 사용하면 이는 하나의 요소로 간주되나요, 아니면 두 개의 요소로 간주되나요? 우리는 2단계 인증 규칙을 준수하고 있나요? 응답: 생체 인증만으로는 SCA에 충분하지 않습니다 – 그것은 단지 하나의 생체 요소일 뿐입니다. 그러나 패스키 구현에서 생체 인증은 혼자가 아닙니다: 기기의 소유가 다른 요소입니다. 사용자의 생체 인증은 기기에 저장된 개인 키를 잠금 해제합니다. 소유와 생체는 두 개의 별개의 범주입니다. 이것은 많은 뱅킹 앱이 이미 SCA를 충족하는 방식과 유사합니다: 휴대폰을 가지고 있고(소유) 그리고 지문이나 얼굴을 사용하여 앱을 잠금 해제합니다(생체). EBA는 기기 바인딩과 생체 인증의 조합을 준수하는 SCA로 명시적으로 인정했습니다. 패스키 시나리오는 정확히 그 조합입니다. 사용자가 생체 인증 대신 PIN을 사용하여 패스키를 잠금 해제하기로 선택하면, 그것은 소유 + 지식이며, 이 또한 준수합니다. 우리는 모든 패스키 작업에 대해 사용자 확인을 강제하므로(사용자는 매번 생체/PIN을 제공해야 함), 기기를 가지고 있는 것만으로 충분한 상황은 없습니다. 따라서 패스키를 통한 모든 결제 인증은 PSD2 정의에 따른 2단계 이벤트입니다.

질문 4: 공격자가 패스키 인증을 재사용하거나 데이터를 조작하여 다이내믹 링킹을 우회할 수 있나요? 응답: 아니요. 이것이 패스키와 다이내믹 링킹이 강력하게 함께 작동하는 지점입니다. 모든 WebAuthn 인증은 우리가 거래별로 생성하는 챌린지에 연결되고 우리 도메인에 범위가 지정된 고유한 서명을 생성합니다. 공격자는 다른 거래에 대해 그 서명을 재사용할 수 없습니다. 서명 자체는 챌린지 논스를 통합하며 원래 발급된 것에 대해서만 유효합니다. 공격자가 네트워크 통신을 가로채더라도, 챌린지나 거래 컨텍스트가 더 이상 일치하지 않으므로 서명을 무효화하지 않고는 금액이나 수취인을 변경할 수 없습니다. 이것이 우리가 논의한 MITM 보호입니다. 또한 패스키 서명에는 출처 데이터가 포함됩니다 – 정확한 웹사이트/앱 출처로 전송되지 않으면 검증되지 않으므로 피싱이나 리디렉션은 작동하지 않습니다. 요컨대, 모든 조작 시도는 다이내믹 링킹 규칙에 따라 인증 코드를 무효화합니다. 이것은 실제로 일부 현재 OTP 기반 흐름보다 더 안전합니다. OTP 기반 흐름에서는 사용자가 때때로 일반 코드를 승인하고 요청이 조작될 위험이 있습니다. 패스키를 사용하면 사용자 인증을 특정 세션/거래에 암호화적으로 바인딩합니다.

질문 5: SCA에 대한 WebAuthn/패스키에 대한 알려진 규제 의견이 있나요? 규제 당국이 패스키를 준수하는 것으로 받아들일 것이라고 확신할 수 있나요? 응답: 현재로서는 EBA가 Q&A나 지침에서 WebAuthn이나 "패스키"라는 용어에 대해 명시적으로 의견을 발표하지 않았습니다. 그러나 그들이 제시한 원칙에 따르면 패스키는 허용 가능한 방법 내에 명확하게 들어맞습니다. EBA의 2019년 의견서는 본질적으로 FIDO2와 유사한 접근 방식을 예상했습니다: 소유에 대해, 그들은 **"공개/개인 키 교환"**과 적절한 기기 바인딩을 소유의 증거로 명시적으로 언급했습니다. WebAuthn 패스키는 정확히 그것입니다 – 공개/개인 키 쌍이며, 개인 절반은 기기에 안전하게 바인딩되어 있습니다. 그들은 또한 "기기에서 생성된 서명"을 유효한 소유 증명으로 인정했습니다. 따라서 그들이 패스키라는 용어를 사용하지는 않았지만, 그 방법은 그들의 예시에 포함됩니다. 우리는 또한 유럽의 주요 결제 업체들이 패스키 구현을 추진하고 있음을 관찰했습니다(예: PayPal). 이는 이것이 PSD2 준수라는 확신 수준을 나타냅니다. 이 예는 다이내믹 링킹 및 전반적인 요구사항이 충족된다면 패스키가 준수하는 SCA 흐름의 일부로 받아들여지고 있음을 보여줍니다.

질문 6: 패스키가 피싱에 강하다면 다이내믹 링킹이 여전히 필요한가요? 응답: 예. 패스키는 교차 출처 피싱을 제거하지만, PSD2는 여전히 원격 결제 개시에 대해 다이내믹 링킹을 의무화합니다. 다이내믹 링킹은 특정 금액과 수취인을 SCA 결과에 바인딩하고 어떤 변경이라도 무효화하여 피싱을 넘어서는 인증 무결성(예: MITM/MITB/TPP 대체)을 다룹니다.

Corbado의 솔루션은 다이내믹 링킹 및 PSD2를 준수합니다. 사전 인증 지급인 디스플레이, 금액과 수취인에 바인딩된 일회성 챌린지, 엄격한 서버 검증, 불변의 감사는 지급인 인식, 고유성/특정성, 변경 시 무효화, 무결성/기밀성에 대한 RTS 제5조 요구사항을 함께 충족합니다. 기기 바인딩 소유 및 UV(생체 또는 PIN)를 통해 요소 독립성이 보존되어 EBA 지침과 일치합니다.

오늘날의 OTP/SMS 방법에 비해 Corbado는 피싱 및 재전송에 대한 저항, 조용한 매개변수 조작 방지, 더 강력한 부인 방지 증거, 기기 내 UV를 통한 마찰 감소 등 실질적으로 더 나은 보안 및 사용자 결과를 제공합니다. 잔여 위험(예: 사회 공학, 손상된 기기)은 구체적인 통제로 완화되며 레거시 방법보다 좁습니다. 웹의 경우, Corbado는 플랫폼 지원(특히 Apple)이 광범위할 때 SPC를 채택하여 핵심 규정 준수 태세를 변경하지 않고 디스플레이의 암호화 증명을 추가할 수 있습니다.

요컨대, Corbado의 패스키 기반 거래 인증은 PSD2 다이내믹 링킹의 문자 그대로와 정신을 충족하며 레거시 접근 방식에 비해 사기 복원력과 감사 가능성을 향상시키면서 생태계가 성숙함에 따라 미래의 향상(SPC)에 대한 명확한 경로를 유지합니다.

실제로, 우리가 세 가지를 할 때 패스키는 다이내믹 링킹을 충족합니다: 사용자 확인 전에 지급인에게 금액과 수취인을 표시하고, 해당 정확한 세부 정보에 특정한 인증 코드를 생성하며, 어떤 변경이라도 코드를 무효화합니다(RTS 제5조 1항 a-d). 이는 규제 당국이 이미 로컬 생체 인증에 대해 수용하는 원칙을 반영하며, 패스키는 OS 네이티브이고 추가 앱 없이 웹과 앱 채널에서 작동한다는 편리함을 더합니다. 출처 바인딩과 결합하면 스푸핑된 요청을 표시하지 않습니다 — 원래 사이트나 앱의 합법적인 프롬프트만 사용자에게 나타납니다.