In Wallet We Trust: Bypassing the Digital Wallets Payment Security for Free Shopping

Abstract

디지털 지갑은 스마트 기기를 통한 비접촉 지불을 안전하고 편리한 방법을 제공하는 새로운 지불 기술 형식이다.

이 논문의 연구는 인증, 권한부여, 엑세스 제어 보안 기능에 초점을 맞춰서 디지털 지갑을 통해 이루어지는 금용 보안을 연구한다.

디지털 지불 생태계가 여러 공격받기 쉬운 분산된 권한 위임을 지원한다는걸 발견했다.

우선 공격자는 지갑과 은행사이의 인증 방법 약정 절차를 악용해서 피해자의 은행카드를 그들의 지갑에 추가한다.

둘째로 지갑과 은행간의 무조건의 신뢰를 악용해서 지불인증을 우회한다.

셋째로 다양한 지불방법을 통해 트랩도어를 만들고 지불에 대한 엑세스 제어 정책을 위반한다.

이러한 공격은 도난 신고와 잠금(결제 금지라던지)가 신고되었어도 공격자가 피해자의 카드로 임의의 금액을 마음대로 결제할 수 있는 심각함을 의미한다.

이 찾은 내용을 notably Chase, AMEX, Bank of America등 미국의 은행과 ApplePay, GPay, and PayPal)에 대해서 실제로 검증했다.

이 결과를 당사자들에게 알렸고 이를 해결하기 위한 대책을 제안한다.

Introduction

디지털 지갑이 미래에 주요 결제 수단이 될 것이다.

표를 보면 Recurring(반복)의 경우 카드 정지를 신청해도 사용 가능하다.

디지털 지갑은 업계와 사용자 모두에게 잘 받아들여져 널리 채택되었는데 디지털 지갑 앱과 연결된 도난당한 실제 카드 등에 대한 체계적인 보안 분석은 초기 단계다.

디지털 지갑에는 신용카드 번호 및 은행 계좌 세부정보 등 민감정보가 있어서 신원 도용 및 금용사기로 이어진다.

디지털 지불 생태계는 카드 소유자, 디지털 지갑, 상인,point-of-sale (POS) 단말기- , 은행 5개의 엔티티로 이루져있다.

금용거래를 원활하게 하기 위해 특정 작업을 다른 엔티티에 위임해서 신뢰를 만듬 - 은행은 디지털 지갑에게 사용자 인증과 카드 소유자임을 검증하는 일을 위임함

POS와 단말기 사이에서의 결제 프로토콜의 보안은 과거에 조사되었다. 그러나 디지털 결제 생태계에서 다양한 엔티티를 포함하는 프로토콜은 시스템 복잡성, 공식 문서 부족, 폐쇄형 소스 지갑 구현으로 거의 관심을 받지 못했다. 이러한 사실로 카드 도난 및 잠금 신고를 했을 때 디지털 결제가 어떻게 처리되는지 연구하게 동기를 부여했다.

4개의 질문에 대한 연구

RQ1. 디지털 지갑에 카드를 추가하는데 디지털 지갑과 은행에서 적용하는 보안 조치의 효과는?

RQ2. 공격자는 어떻게 숨친 카드를 디지털 지갑을 통해서 결제할 수 있는가?

RQ3. 카드 잠금과 도난 신고 및 카드 교체가 도난 카드의 악의적인 결제를 막는데 충분한가?

RQ4. 공격자는 어떻게 도난 카드의 접근 제어 제한을 우회할 수 있는가?

디지털 지갑 지불을 관찰함으로 평가를 수행

1. 다양한 이벤트 - 카드 잠금, 은행에 카드 분실 신고
2. 임의의 금액 - 작은 금액 vs 큰 금액 결제
3. 다양한 방법 - 온라인, 매장, 상인 앱(판매자 앱)
4. 고유한 방법 - 실제 카드 vs 디지털 지갑
5. 결제 방법 - 1회성 vs 반복성표1✓ : 거래 허용
6. ✗ : 거래 금지
7. 미국 메이저 은행 카드 잠금 정책
8. | Card Issuer Banks | Physical Card | Wallet (one-time) | Wallet (Recurring) | | --- | --- | --- | --- | | AMEX | ✗ | ✓ | ✓ | | Chase | ✗ | ✓ | ✓ | | Discover | ✗ | ✓ | ✓ | | US Bank | ✗ | ✗ | ✓ | | Citibank | ✗ | ✗ | ✓ | | BoAmerica | ✗ | ✗ | ✓ |

디지털 지갑을 통한 결제에 대한 분산 권한의 취약점 확인에 대한 연구가 목적 - 공격자가 디지털 결제 생태계의 다양한 요소의 신뢰 관계를 악용하여 핵심 보안 기능을 우회할 수 있음을 보여줌 - 아래 표2 참조

표 2: 디지털 결제 생태계의 분산된 권한에 대한 주요 연구 결과 요약

기능 취약점 공격 근본 원인 제안된 해결책

인증 우회	MFA 대신 KBA 기반 인증 사용	도난당한 카드를 지갑에 추가	인증 방법 선택을 지갑에 위임	MFA 기반 푸시 인증 방식 채택
카드 소유자 확인 우회	PIN 및 서명 대신 기기 내 지갑 인증 사용	자신의 기기와 지갑으로 거래 승인	지갑 기반 확인에 대한 무조건적 신뢰	지속적인 인증 및 토큰 업데이트
접근 제어 위반	정기 결제에 대한 제한 없음	임의 금액의 일회성 결제	접근 제어 제한을 우회하기 위한 '트랩 도어' 생성	결제 메타데이터 확인

디지털 지갑을 사용해서 결제하려면 카드를 추가해야 하는데 CARD ADD 절차는 은행에서 사용자 인증을 일으킨다. 인증되면 온라인 및 매장에서 사용가능

인증 프로세서의 일부로 지식 기만 인증(KBA), 다중 요소 인증(MFA) 과 같은 인증 방법에 은행과 지갑 모두 동의해야 한다.

지갑은 지원되는 방법을 선호하는 순서대로 은행에 보낸다. 은행은 비교적 안전한 인증보다 지갑이 선호하는 방법을 선택한다. 그로인해 CARD ADD 절차에 가장 안전하지 않은 방법(추측하기 쉬운 우편번호 기반 KBA)을 사용하게 되는데 그로인해 공격자는 이 취약점을 이용해서 피해자의 카드를 지갑에 추가한다. — addressing RQ1

피해자가 카드를 분실하면 카드를 lock하거나 은행에 신고를 한다. 은행은 물리적 카드로 결제를 하지 못하도록 막는다. 그러나 디지털 지갑의 결제는 막지 않음(표 1 참고) 왜? 카드 소지자가 인증되면 은행과 지갑은 무조건적인 신뢰를 구축하기 때문. 지갑의 지문인식, 얼굴확인 같은 생체 인식이 결제 인증 절차의 부분인 카드 소지자 확인 부분을 대체한다. 공격자는 이 취약점을 이용해서 은행의 결제 인증을 우회한다. — answering RQ2

구독 기반 서비스에 대해 정기 결제를 설정할 수 있다. 정기 결제는 일회성 결제와 달리 고정 금액을 판매자에게 지불하는데 이러한 결제의 경우 은행에서 판매자에게 계약 ID(contract ID)를 발급하고 이 ID는 정기 거래에 사용된다. 이 논문에 따르면 1회성 결제에 적용되는 엑세스 제어 제한이 정기 결제에는 없다는걸 찾았다. 이러한 선택은 카드 발급 은행에서 명시적으로 설계한 것이다. 표1을 보면 1회성 거래 제한이 모든 은행에 적용된 건 아니다. 이 설계가 1회성 지불에 대한 엑세스 제어 제한을 위반할 함정 문을 열 수 있다고 주장한다. 공격자는 지갑에서 피해자의 카드를 사용해서 구독에 등록할 수 있지만 한번만 사용한다(구독 서비스로 위장해서 한번만 결제한다). 이를 악용해서 호텔 예약, 자동차 렌트 같은 비구독 서비스를 받을 수 있다. — answering RQ3

추가 설명 : 지갑에서는 정기 결제로 등록이 되어있어서 은행에서는 이를 승인하는데 호텔 예약 같은건 1회성이니까 한번만 결제 된다는 것임. 그래서 정기 구독으로 위장해서 결제 한다는 것

2섹션에서는 사용자 인증, 카드 소지사 검증, 엑세스 제어를 포함한 디지털 결제의 보안 절차에 대한 기술적 배경 제공

3섹션에서는 악의적인 사용자가 악용할 수 있는 은행에서 제공하는 다양한 디지털 지갑 관련 기능을 설명

4섹션에서는 지갑을 통한 디지털 결제를 둘러싼 보안 절차에 대한 방법론과 공격에 대한 논의

5섹션에서는 결제 라이프사이클 전반에 걸쳐 사용자 인증 및 거래 승인 절차를 개선하기 위한 대책을 제안

6섹션에서는 디지털 결제와 EMV 표준을 활용한 이전 연구를 살펴봄

7섹션에서는 연구의 결과 결론지음

2 Background on Security Provisioning in Digital Payments Ecosystem

그림 1

위 그림은 생태계 내의 주요 엔티티와 다양한 거래 시나리오에서의 상호 작용을 보여준다.

디지털 지갑은 매장 내 거래와 온라인 거래 2가지의 거래를 지원한다. 이를 1회성 결제라고 한다.

매장내 거래일 경우 은행의 결제 네트워크에 연결된 POS 단말기를 사용하고 온라인 거래의 경우 판매자의 전자 상거래 웹사이트에서 이루어진다.

1회성 결제 외에도 구독같이 정기 결제를 위해 판매자와 온라인 거래를 설정할 수 있다.

EMV 프로토콜은 Europay, Mastercard, Visa에서 만든 프로토콜로 전 세계적으로 증가하는 디지털 결제 수요를 수용할 수 있는 안전하고 신뢰할 수 있는 프로토콜을 만드는 것을 목표로 한다.

EMV 프로토콜은 디지털 지갑을 현대 결제 시스템의 핵심으로 삼는다. 지갑 중심 시스템은 신원 도용 및 사기 방지를 위해 카드 정보를 판매자에게 숨긴다. 예시로 카드를 디지털 지갑에 추가하면 은행은 기본계좌번호(PAN primary account number)를 대신할 결제 토큰을 발행한다. 지갑으로 결제할 경우 계좌번호가 아닌 토큰을 사용하여 원래 카드를 보호하고 지갑에서 지문 인식 등과 같이 스마트폰의 생체 인식 보안 기능 뒤에서 자체적으로 보안을 유지한다. 그로인해 판매자 및 은행 간의 안전한 통신은 지갑에 달려있다.

2.1 User Authentication in Wallet

카드 소유자가 지갑에 카드를 추가하면 카드 발급사 은행은 인증을 지갑에 의존한다. 카드 소유자가 지갑과 직접 상호작용 하기 때문에 (그림 1의 A1처럼) 은행은 지갑의 기능에 맞는 인증방법을 택하는데 일반적으로 KBA(knowledge-based authentication 지식 기반 인증), MFA(multi-factor authentication 다중 요소 인증) 2가지를 사용한다.

KBA는 내가 아는 것을 기반으로 작동하는데 생년월일, SSN(social security number 미국의 주민록번호)의 뒤에 4자리 등을 요구하는데 청구 주소와 우편번호를 가장 많이 사용한다.

OTP(one-time password)를 사용하는 2FA(Two-factor authentication)는 일반적인 MFA방법이다. 이 방식은 사용자가 가지고 있는 것을 바탕으로 작동하는데 자용자가 기기와 계정을 소유하고 있음을 확인한다. MFA 방법의 구체적인 구현은 지갑 서비스 제공자에 따라 다른데 SMS 또는 이메일로 OTP를 제공한다

사용자 인증 후 PAN(primary account number 기본 계좌 번호)에 연결된 토큰을 만들고 관리하기 위해 TSP(token service provider)를 사용한다. 그리고 그 토큰을 지갑과 공유한다.(그림1 A2).지갑은 PAN를 저장하지 않고 모든 거래에 이 토큰을 사용하여 카드 및 사용자의 데이터 보안을 강화한다.

2.2 Cardholder Verification

CV(Cardholder verification 카드 소유자 검증)은 거래 승인의 핵심 부분 - 합법적인 카드 소유자만 POS 단말기로 거래할 수 있도록 보장한다.POS 단말기는 모든 유형의 카드와 지갑에 적용 가능한 여러 카드 소지자 검증 방법(cardholder verification methods CVMs)을 지원한다. 이 확인 방법에는 서명, 오프라인 일반 텍스트 PIN 또는 암호화 PIN, 온라인 PIN, 오프라인 일반 텍스트 PIN과 서명, 오프라인 암호화된 PIN 및 서명, 소비자 기기 CVM(consumer device CVM CDCVM)이 포함된다.

CVCDM에서 카드 소유자는 패스코드, 패턴, 생체인식 ID를 사용하여 스마트폰에서 지갑 기반 거래를 확인한다. 이는 “당신이 가전 것”(something you have)원칙과 일치하여 스마트폰에 인증된 지갑 앱에 있는 모든 사용자가 PIN이나 서명과 같은 추가 식별 없이 결제를 완료 할 수 있게 해준다.

그럼에도 불구하고 사용자는 여전히 자신의 기기 소유권을 확인해야 한다. 이를 확인하기 위해 사용자는 스마트폰과 지갑 앱의 잠금을 해제하고(그림1 I1) POS 단말기는 잠금 해제된 지갑에서 토큰을 읽는다(그림1 I2). POS는 토큰과 거래 세부 정보를 은행에 전달하여 거래를 완료한다(그림1 I3).

2.3 Access Control

거래가 승인 요청을 위해 은행에 도착하면 은행은 카드 소지자의 자격을 확인하기 위해 검증 프로세스를 시행한다. 은행은 거래 유형, 금액, 시간, 카드 상태와 같은 기준에 따라 거래를 평가하기 위해 접근 제어 서비스 사용한다. 은행의 접근 제어 서비는 과거 거래와 비교해서 사기를 탐지한다. 이를 통해서 카드 소지자의 일반적인 지출 행동과 일치하는지 비정상 적이지 않은지 확인한다.

은행은 다양한 유형의 결제에 다른 접근 제어 정책을 채택한다.

1회성 결제(온라인 및 오프라인)일 경우 결제할 금액을 충분히 가지고 있는지 확인한다. 그러나 반복결제(월 구독)의 경우 추가 조건이 붙는데 신용계좌가 연결되어 있어야 한다(그림1 R1). 직불카드는 반복결제를 허용하지 않는다.

은행은 생태계 내의 개체마다 다양한 수준의 신뢰를 부여하는데 사기 위험이 높은 상황에서는 신뢰할 수 있는 출처에서만 거래를 허용하게 한다. 예를 들어 카드 소유자가 카드 도난으로 카드를 잠글경우 은행은 디지털 지갑을 통한 결제는 허용(그림1 R2-R3 및 I2-I3)하지만 물지적 카드로 이루어진 오프라인 및 온라인 거래는 차단한다. 특정 접근 제어 정책은 은행에 다라 다른다 — 표1을 참고

3 Features or Vulnerabilities?

디지털 지갑은 기존 거래 방식보다 더 안전한 것으로 간주된다. 지갑의 기기 기반 생체 보안 메커니즘은 은행이 사용자 인증과 카드 소유가 확인을 더 쉽게 할 수 있게 도와준다. 이런 메커니즘으로 인해 물리적 카드로는 제공할 수 없는 결제 기능을 제공하는데 은행이 지갑의 보안 메커니즘을 신뢰하기 때문이다.

표3

기능 의도된 이유 취약점 악용 가능성

여러 기기 및 사용자를 통한 지갑에서의 카드 접근	지갑을 통해 어디서든 카드에 접근할 수 있음	공격자가 도난당한 카드를 자신의 지갑에 추가하여 합법적인 사용자로 가장함	약한 KBA 인증을 통해 도난당한 카드를 지갑에 추가
카드 소유자 확인 대신 지갑 확인 방법 사용	지갑은 항상 합법적인 사용자에게 소유됨	공격자는 자신의 지갑을 통해 본인 인증을 거침	도난당한 카드를 PIN 및 서명 없이 사용하여 거래
중단 없는 정기 결제	정기 결제가 늦어지지 않도록 항상 허용	가맹점이 일회성 거래를 정기 결제로 잘못 표시	잘못된 라벨링으로 카드 잠금 제한 우회

1. 여러 기기 및 사용자를 통한 지갑에서의 카드 접근 — 이 기능은 하나의 카드를 여러 디바이스에 등록할 수 있다.

1번과 같은 기능을 구현하기 위해 은행은 카드 소유자와 디바이스 또는 지갑 소유자가 동일 인물이라고 가정한다. 이 가정을 기반으로 은행과 지갑은 종종 약한 인증 방식을 섵액하는데 이 기능으로 인해 취약점으로 변질된다.

1. 카드 소유자 확인 대신 지갑 확인 방법 사용 — 은행이 지갑 사용자에 대해서 따로 카드 소유자라는 확인 절차를 하지 않고 기기 내 생체 보안 방법을 사용하여 거래를 승인하게 한다. 이 방식을 사용하면 공격자가 자신이 카드의 주인이라고 주장하는 취약점을 초래한다.
2. 정기 결제에 대한 접근 제어가 적용되지 않음 — 표1 에서 본것처럼 카드를 잠그더라도 정기 결제는 허용하는데 공격자가 이 기능을 이용하여 1회성 결제를 정기결제로 속여서 거래 승인 제한을 우회할 수 있다.

은행도 이러한 취약점을 인지하는지 물어보니 인지하고 있다고 한다.

위협 모델

상정한 공격자 : 디지털 지갑 사용자, 피해자 : 주요 미국 은행에서 발급한 신용 카드를 소유한 카드 소유자

공격자는 은행과 지갑 간의 통신을 방해할 수 없는 수동적 공격자라 가정한다. 또한 공격자는 도난 또는 분실된 카드를 확보 할 수 있으며 피해자는 아직 신고하지 않은 상태라고 가정한다. 피해자는 카드 도난 및 분실을 인지하고 은행에 신고하기 까지 시간적 공백이 발생하는데 공격자는 이 시간을 사용할 수 있다.

스텔스 공격자는 탐지되지 않고도 활동할 수 있음

은행에 탐지되지 않기 위해 가짜 신분증, 가짜 핸드폰 등을 사용해서 추적되지 않도록 할 수 있다고 가정

Insecurities in Decentralized Authority for the Digital Payment Ecosystem

방법론

3가지 방법을 통해서 취약점을 식별

1. 토큰 수명 주기 관리 이벤트를 식별하고 디지털 결제 와 관련된 절차를 조사했다. PAN과 토큰 간의 연결이 관리되는 방식을 정의, 특히 카드 추가, 카드 손실, 토큰 속성 업데이트 ,기기 손실, 다양한 유형의 결제에 대한 토큰 제공 등 중요 이벤트에 주목
2. 첫 번째 단계에서 식별한 결제 절차를 분석했다. EMV® 사양과 디지털 지갑 문서를 참고하여 참여하는 주체와 그들간 주고 받는 데이터를 연구했다. 이 절차들이 의도한 기능을 이해한 후 잠재적 결함과 취약점을 식별했다. (i) 주체들 간의 신뢰 가정, (ii) PAN을 사용하는 절차와 토큰을 사용하는 절차간의 차이점, (iii) 부적절하거나 일관성 없는 보안 정책, (iv) 보안 정책 시행의 결함등을 포함했다. 인증, 승인, 접근, 제어와 같이 중요한 결제 절차에 대한 고수분 보안 정책을 분석했다.
3. 두 번째 단계에서 발견한 취약점을 실제로 공격 가능한지 평가했다. 주요 미국 은행의 정책을 조사하여 카드소유자가 (i) 카드를 잠그거나, (ii) 카드를 분실했다고 신고하고 대체 카드를 요청한 경우에서의 결제 처리 방법을 확인했다. 이 단계는 은행 정책이 사양의 EMV 취약점을 보완하지 못하는 경우 공격자가 이를 악용해 공격할 수 있음을 보여준다.

주요 연구 결과 개요

은행이 일부 절차의 통제권을 디지털 지갑에 위임하고 있고 추가적인 기능을 제공하기 위해서 더 약한 보안 메커니즘을 선택하는 경우가 많다는 점을 확인했다. 그로 인해 공격자가 인증, 승인, 접근 제어 절차의 취약점을 악용해서 여러가지 공격을 할 수 있었다. 표2 참고

공격자는 약한 인증을 악용하여 도난당한 카드를 자신의 지갑에 추가

공격자가 은행이 더 약한 인증 절차를 선택하도록 유도해서 인증을 위회할 수 있다. 그로인해 카드를 자신의 디바이스에 추가할 수 있다.

공격자는 토큰을 통해 대체 카드가 발급된 후에도 결제를 계속 진행할 수 있음

인증을 한 후에는 토큰을 이용해서 결제 승인을 하는데 카드를 잠그거나 대체 카드 발급이 된 후에도 만료되거나 업데이트를 하지 않아 도난 당한 카드로 결제를 계속 할 수 있다. 카드가 잠기거나 도난 신고 된다면 1회성 결제만 제한된다는 점을 알고 있다. 어떻게 제한하나 확인한 결과 전체 거래 데이터 (예: 구매 유형, 시간, 금액 등)을 검증하는게 아닌 거래 레이블(1회성 vs 정기)만 비교해서 제한한다는걸 알게 되었다. 이를 이용해서 1회성 결제를 정기 결제 레이블로 바꿔서 접근 제어 정책을 우회할 수 있다.

카드 잠금 시 취약점의 시간적 의존성은 없는가?

카드를 언제 잠그는가는 상관이 없다. 카드를 잠그기 전에 카드를 추가한다면 상관이 없다. 이 취약점은 확인 시간과 사용 시간의 차이(TOCTOU time-of-check to time-of-use)로 발생하는 것이 아닌 은행 정책에 뿌리를 두고 있기 때문이다.

이 공격으로 인해 발생하는 재정적 비용은 누가 부담하는가?

피해자가 피해를 인지할 때 까지 은행, 지갑 제공업체, 가맹점 모두 피해를 인지하지 못했다. 가맹점이 은행보다 더 많은 책임을 지고 손실을 부답한다.

4.1 Trust in Digital Wallets Weakens User Authentication

디지털 지갑은 카드 소유자와 은행을 연결하는 엔티티로 은행의 사용자 인증 절차와 토큰 수명 주기 관리를 용이하게 한다. 이러한 이유로 은행이 지갑에 대한 신뢰를 구축하고 이로 인해 (i) 지갑이 인증 방법을 선택하게 하고 (ii) 사용자의 재인증 없이 대체 카드를 자동으로 업데이트 합니다.

4.1.1 지갑 주도의 인증 방법 선택

은행은 지갑이 사용자 인증 방법을 선택할 수 있게 하는데 지갑은 지원되는 방법 목록(청구 주소, OTP, 전화)을 사용자에게 제시하여 인증을 수행한다. 이는 최종 사용자가 지갑에 카드를 추가하는데 사용할 인증 방법을 선택하는 최종 결정을 내리게 하는데 이러한 인증 위임으로 인해 은행이 약한 인증 절차를 수락하도록 지시할 수 있다.

1번째 이슈 — 은행이 디지털 지갑에게 인증을 위임하면 공격자가 훔친 카드를 자신의 지갑에 추가하고 결제를 할 수 있다.

그림 2: 디지털 지갑의 인증 절차; 공격자는 KBA 및 MFA 기반 인증의 취약점을 악용하여 피해자의 카드를 지갑에 추가합니다. 인증 절차는 두 단계로 구성됩니다. a) 지갑과 은행 간의 핸드셰이크, b) 은행에서 위임한 지갑의 사용자 인증. 빨간색으로 강조 표시된 절차의 취약점을 통해 공격자는 카드를 추가할 수 있습니다.

공격 세부 사항

그림 2는 공격자가 인증 절차를 우회해서 자신의 지갑에 피해자의 카드를 추가하는 시나리오로 피해자가 카드를 분실 했지만 아직 잠그지 않은 상태이다. 공격자는 이 시기에 지갑에 기본 계좌 번호(PAN)을 입력하고 카드 추가 절차를 진행한다(1번). 은행과 지갑 사이의 인증 절차를 트리거하며 먼저 사용할 인증 방법을 선택하기 위한 핸드셰이크가 일어난다(2~4번)

은행은 CapablilityEnquiry(3번)요청을 보내 지갑이 지원하는 인증 방법을 확인한다. 지갑은 CapablilityyInformation(4번) 메시지로 자신의 지원 방법 목록을 선호도 순서로 응답한다. 은행은 지원 방법 목록은 수신하면 지갑에서 가장 높은 선호도의 인증 방법을 선택한다.

지갑은 피해자의 PAN을 포함해서 AUTHENTICATE(5번)을 은행에 요청한다. 은행이 이 요청을 받으면 PAN을 확인하고 인증 응답을 생성한다. 단순화를 위해서 지식 기반 인증(KBA)와 다중 요소 인증(MFA)를 고려한다. KAB인증을 선택하면 KbaEscalationChallenge(6a번)을 MFA인증을 사용한다면 MfaEscalationChallenge(6b번)를 사용해서 응답한다.

KBA에서 지갑은 은행에게서 KbaEscalationChallenge(6a)를 보낸다. 그러면 사용자는 청구서 우편주소, 생년월일 등 신원을 확인 할 수 있는 요청을 받는다(7a번). 사용자가 정보를 입력하면 지갑은 ValidKbaChallengeRequest(8a→9a번) 메시지를 은행으로 전송해서 사용자의 신원을 확인하고 인증을 완료한다.

MFA에서는 은행이 MfaEscalationChallenge(6b번)을 지갑에 전송하면 지갑은 사용자에게 SMS, Emali, OTP등 원하는 선택지를 제공한다(7b번). 사용자가 OTP를 선택하면 지갑은 OTP를 받아 은행에 인증을 완료하는 ValidateOtpChallengeRequest(9b번) 메시지를 전송한다. 통화 기반 인증은 KBA와 유사하게 사용자의 신원 확인을 위해서 은행에 생년월일, SSN의 마지막 4자리를 요구한다.

사용자가 인증되면 토큰 서비스 제공자(TSP token service provider)를 사용하여 (PAN에 대한 프록시 ID)토큰을 생성하고 PANid라 불리는 토큰과 관련된 PAN의 마지막 4자리와 함께 토큰을 지갑과 공유한다.(10번). 지갑이 사용자에게 카드 등록 성공 알림을 보낸다(11번)

주요 내용

은행이 아니라 최종 사용자가 인증 방법을 선택한다는게 문제다. 은행이 MFA를 사용하다도록 강제해도 공격자가 은행이 KBA 방식으로 인증 할 수 있게 만들 수 있는데 “전화 인증” 옵션을 통해서 할 수 있다. 전화 인증은 자동 응답 시스템을 이용해서 카드를 추가 하는데 이 때 피해자의 생년월일 및 피해자의 카드와 관련된 SSN의 마지막 4자리를 요청한다.

KBA가 MFA보다 보안성이 떨어진다는 것은 입증 되었는데 고객에게 사용 편의성을 우선시 해서 KBA 기반 인증을 사용한다. 공격자가 공개적으로 이용 가능한 데이터베이스에서 KBA 인증에 필요한 정보를 얻을 수 있다. 우편번호, 생년월일은 특히 소셜 미디어 시대에 공개 정보로 취급된다. 그래서 공격자는 이를 이용해서 공격자가 피해자의 카드를 지갑에 추가할 수 있다.

경험적 평가

피해자의 도난 카드를 공격자 지갑에 추가하는 것에 대한 평가를 진행했다. Bank of America(visa 카드), Chase 은행(master 카드) 2개의 신용카드를 실험으로 사용했고 공격자는 이 카드를 훔친다. 공격자의 제어 안에 있고 루트되지 않은 안드로이드기기(PayPal, GPay 지갑)와 애플기기(ApplePay)를 사용했다. 또한 공격자는 피해자와 공통 정보를 공유하지 않는다는 가정을 했다.

PayPal, GPay는 청구서 주소를 이용한 KBA인증을 사용한다는 것(그림3 a)과 ApplePay는 2가지 다른 방법을 사용한다는 것을 발견했다(그림3 b, c)

그림 3: 다양한 지갑에서 사용되는 인증 방법. BoA 신용카드는 (a) Paypal 지갑에 KBA를 사용하고, (b) ApplePay에 여러 MFA 방법(예: 이메일, SMS 또는 전화)을 인증 방법으로 사용합니다. 반면, Chase 은행 신용카드의 경우 (c) ApplePay는 SMS 기반 MFA만 제공합니다. 이러한 실험은 지갑(예: Apple Pay) 내에서뿐만 아니라 지갑 앱(예: Apple Pay 및 Paypal)에서도 사용자를 인증하는 데 일관성이 없다는 점을 강조합니다.

 

ApplePay는 Bank of America의 visa 신용 카드의 경우 SMS OTP, email OTP, 자동 전화 3가지의 MFA방법을 제공하고(그림3 b) CHas의 master 신용 카드의 경우 SMS OTP방법의 MFA를 제공한다(그림3 c).

Yellow Pages나 SearchBug 같은 인기 있는 온라인 데이터 데이스를 사용해서 피해자의 SSN 마지막 4자리나 생년월일등을 알아낼 수 있다. 또한 SMS 기반의 OTP의 취약점을 보여주는 과거 연구도 있다. 이러한 연구에 의존하여 MFA 기반 인증 절차를 통해 카드를 추가 할 수 있다는 것을 강조한다.

인증 방법에 대한 선택 위임이 일관되지 않는다는 것을 발견했다. 하나의 은행 카드가 다른 지갑에서 다른 방법으로 인증될 수 있다(그림3 a vs b). 인증 방법은 공격자와 피해자가 사용하는 지갑 공급자에 따라서 달라지지 않는다. 예를 들어 피해자가 PayPal지갑에 카드를 이미 추가 했어도 공격자가 PayPal에 카드를 추가해서 사용할 수 있다.

근본 원인

위 실험처럼 더 강력한 보안을 제공하는 방법을 제공하지 않고 사용자 친화적을 위해서 KBA를 사용하고 KBA와 다를바 없는 MFA의 전화인증을 사용한다. 이로 인해 도난카드를 훔쳐 거래 할 수 있다.

얻은 교훈

인증 권환을 위임하는 방식은 효율적이고 확장 가능하지만 보안을 약화시킨다. 이는 중요한 결정이 디지털 지불 생태계의 제3자에게 위임될 때 분명해진다. 은행이 모든 지갑에 대해 완벽하고 균일한 인증 정책 시행이 부족하다는 것을 알았다.

4.1.2 Card Replacement in Wallet Without User Authentication

은행은 유저 인증 후에 지갑과 신뢰 체인을 유지한다. 소비자 기기가 도난 당하거나 결제 가격 증명이 삭제되는 경우 처럼 연결된 카드의 상태가 변경되면 은행은 지갑에 직접 카드 관련 업데이트를 보낸다. 이러한 업데이트는 LifecycleUpdate 요청을 통해 연결된 지갑으로 전달된다. 이 작업은 사용자에게 알리지 않고 업데이트를 수락하기 위한 재인증을 요구하지 않는다. 그래서 공격자의 지갑도 업데이트를 받는다.

2번째 이슈 — 카드 교체의 경우 토큰이 취소되지 않아서 공격자는 인증 없이 이전에 추가한 카드를 계속 사용할 수 있다.

공격 세부 사항

사용자 재인증 없이 토큰 업데이트를 제공하기 위해 분실된 카드 시나리오를 고려한다.

그림 4: 사용자가 카드 분실을 보고한 경우 카드를 교체하기 위한 PANReplacement 절차. 은행은 새로운 PAN을 발급하고 사용자 인증 없이 모든 관련 지갑에서 새로운 PANid를 업데이트합니다. 녹색 메시지는 신뢰할 수 있는(피해자의) 지갑과의 통신을 나타내는 반면, 빨간색 메시지는 공격자가 사용한 악성 지갑을 나타냅니다.

 

사용자가 카드 분실을 보고하면 은행은 분실된 카드를 막고 새로운 PAN과 함께 새로운 카드를 발급한다. 이 때 연관된 토큰을 업데이트 하지 않고 기존에 있던 토큰과 토큰 서비스 제공자(TSP)의 새 PAN과 연결한다. 은행은 LifecycleUpdate를 발생 하고 새로운 PANid를 분실된 카드와 연결된 모든 지갑에 보낸다(그림4 2a, 2b). 지갑은 새로 받은 PANid로 기존의 PANid를 교체한다. 이 시점에서 동일한 기존 토큰은 지갑과 TSP에서 새 PANid와 연결된다. LifecycleUpdate은 사용자가 교체 업데이트를 받아야 하는지에 대한 인증 없이 새 카드를 지갑에 자동으로 추가한다(그림4 3a, 3b). 사용자가 카드 추가 절차를 진행할 것이 아니기 때문에 은행은 교체 카드를 추가하기 위한 EscalationChallenge 절차를 트리거하지 않는다.

주요 요점

한번의 사용자 인증은 가드 분실 후 교체 카드를 지갑에 추가하는 인증을 우회한다. 자동 카드 교체는 카드를 수동으로 추가 하지 않아도 되어 사용자에게 편리하지만 보안을 약화시킨다. 그로 인해 도난당한 피해자의 카드를 지갑에 추가하면 피해자가 카드를 교체 받아도 피해자의 카드가 계속 사용될 수 있다.

경험적 평가

그림5

미국의 두개의 메이저 은행 American Express(AMEX)의 신용카드와 Chase Visa의 신용카드와 직불카드를 사용해서 결함이 있는 PAN 교체 정책을 검증했다. 실험에서 3개의 카드 모두 피해자와 공격자의 지(ApplePay, PayPal, and GPay)에 추가했다. 공격자가 카드를 추가하면 피해자가 은행에 카드 분실을 신고 하고 새 카드 발급을 신청했다. 은행은 분실 카드를 바로 막고 새 카드를 우편으로 보낸다.

공격자 지갑에서 두 가지의 다른 결과가 나왔다. 첫 번째 : Chase Visa 와 AMEX의 신용 카드의 경우 공격자의 지갑은 은행에서 저장된 토큰과 새 PANid와 연결하는 무음 업데이트를 받았다. 두 번째 : Chase Visa의 직불 카드의 경우 ApplyPay에서 더 이상 사용 할 수 없다는 알림을 받았다.(그림5 a)

피해자가 은행에 도난 신고 후에도 카드를 계속 사용할 수 있는지 확인하기 위해서 실험을 계속 진행했다. 공격자는 피해자가 새로운 카드를 받기도 전에 어떠한 방해도 없이 그 카드를 계속 사용할 수 있었다. 이 실험의 특이한 관찰 결과는 지갑이 새로운 PANid를 표시하더라고 이전의 PANid를 계속 사용한다는 것이다(그림5 b). 지갑을 통해 이루어진 결제에 대한 상인 영수증에 이전 PANid가 표시되는 것을 확인했다.

근본 원인

은행이 지갑에 무조건적인 신뢰를 구축한 것이 문제다. 이 신뢰로 은행은 심각한 상황에서 지갑의 접근을 제한하는 토큰 취소 메커니즘을 구현하지 않았다. 그래서 토큰은 PANid와 바인딩 될 때 일정하게 유지된다. 카드 교체 이벤트 동안 은행은 토큰 업데이트 없이 PANid를 교체한다. 은행은 업데이트를 받는 지갑이 카드 소유자인지 아닌지 확인하지 못한다. 이로 인해 은행에서 새 교체 카드를 받더라도 공격자가 카드를 사용할 수 있어 피해자에게 영향을 미친다.

얻은 교훈

은행의 지갑에 대한 무조건적인 신뢰는 사용자 인증을 넘어 확장된다. 카드 분실 같은 심각한 상황동안 은행은 토큰을 취소하지 않고 지갑을 계속 사용하기 위해 사용자 확인을 요구하지 않는다. 그로인해 공격자의 지갑이 합법적인 사용자 지갑처럼 동일한 업데이트를 받는다.

4.2 Unrestricted Transaction Authorization on Wallets

디지털 지갑은 물리적 카드와 다르고 더 안전하기 때문에 은행은 이 2가지의 거래 승인 방법을 사용한다. 물리적 카드는 PIN과 서명을 사용한다. 지갑은 장치 카드 소유자 검증(CDCVM)이라고 잘 알려진 기기 내의 보안 방법(얼굴 인식, 지문 인식)을 사용해서 사용자를 검증한다. 지갑은 사용자에게 거래 승인을 완료하기 위해 기기 장치 감금을 해제하라고 한다. 이는 은행이 기존의 카드 소유자 검증을 수행하는 대신 장치 내 인증(CDCVM)에 의존한다는 것이다. 공격자는 카드 소유자 검증을 우회해서 카드를 지갑에 추가하여 장치 내 인증을 통해 거래를 할 수 있다.(4.1.1참고)

이슈3 — 기기의 검증 방법은 지갑 주인과 카드 소유자 두개의 사항을 검증하지 못한다. 그로인해 공격자는 카드 소유자 검증 프로세스를 우회할 수 있다.

공격 세부 정보

그림6

그림 6에서 보이는 것처럼 공격자는 우선 단말기 위에 지갑 앱이 있는 기기를 탭한다. 단말기는 READ RECORD 명령을 보내 토큰 데이터를 요청한다(그림6 1). 지갑은 카드 소유자 인증 방법 목록인 CVMList에서 토큰과 CDCVM기능으로 응답한다(그림6 2). 단말기는 CDCVM을 완료하도록 요청한다(그림 6 3). 지갑은 유저가 지문, 얼굴 인식 또는 기기 PIN으로 잠금을 해제하도록 한다(그림6 4). 사용자가 기기 잠금을 해제하면 CDCVM 확인을 전송한다(그림6 5,6). 마지막으로 단기는 승인을 위해 CVMRules과 TSL을 은행에 전달하고 거래를 완료한다.

주요 요점

은행은 POS 단말기가 카드 소지자 검증을 하도록 요구하지 않기 때문에 단말기는 CVMRules에 CVM요구되지 않음(0xXX011111)플래그를 세팅한다. 또한 POS에 의해 거래를 검증하기 않기 때문에 단말기 검증 결과(TVR terminal verification results)에 카드 소지자 검증이 성공하지 못했다(B3 = 0x1XXXXXXX)는 플래그를 설정한다. 한편 지갑은 은행이 지갑의 구매를 허가했음을 나타내는 토큰을 단말기로 전송한다. 단말기는 결제를 진행하고 거래 상태 정보에 (TSI transaction status information)B3를 카드 소유자 검증이 수행되었다(B1 = 0xX1XXXXXX)는 플래그로 업데이트 한다. 이 플래그는 지갑에서 카드 소유자 검증을 수행했다고 나타내지만 실제로는 기기 소유자의 검증을 수행한 것이다.

경험적 평가

디지털 지갑을 통한 매장 내 구매에 대한 여러가지 실험을 수행하여 공격했다. 피해자의 AMEX와 Chase Visa 신용카드가 공격자에 의해 도난당한 것으로 가정한다. 공격자가 지갑에 카드를 추가하고 두 카드 모두 잠근다. 은행은 잠긴 카드에 대한 결제를 중시한다고 약속한다. 카드를 잠그니 Chase은행에서 다음과 같은 메세지를 받았다. “너의 카드 또는 너의 카드 번호로 이루어진 신규 구매, 현금 선급 및 잔액 이체 서비스를 즉시 차단한다”. 그 다음 공격자는 판매자 매장(월마트, 및 타겟 매장에서 실험)을 방문해서 지갑(ApplePay, GPay)에 저장된 피해자의 카드를 사용하여 거래를 한다. 가맹점의 POS는 거래를 승인하고 카드가 잠겼음에도 불구하고 피해자는 해당 금액을 청구 받는다. 이러한 결함은 1달러 미만부터 500달러 이상까지 다양한 금액에서 지속된다는 것을 확인했다(표4 참고). 이 실험을 여러번 반복했고 카드가 잠기고 최대 1주일을 기다렸는데 공격 결과는 동일했다.

은행 금액($) 실물 카드 거래 디지털 지갑 거래

AMEX	≤ 1	✗	✓
	≥ 500	✗	✓
체이스 (비자)	≤ 1	✗	✓
	≥ 500	✗	✓
Discover	≤ 1	✗	✓
	≥ 500	✗	✓
Bank of America (비자)	≤ 1	✗	✗
	≥ 500	✗	✗
Citi (마스터카드)	≤ 1	✗	✗
	≥ 500	✗	✗
BoA (비자)	≤ 1	✗	✗
	≥ 500	✗	✗

근본 원인

기기 내 검증은 합벅적 사용자가 카드를 지갑에 추가했고 카드 소유자와 지갑 소유자가 같은 사람이라는 가정을 전제한다.이로 인해 은행은 지갑ID와 유저ID를 상호 교환 가능하게 사용한다. 결과적으로 은행은 권한이 없는 사용자가 접근 할 수 없는 카드 소유자와 사용자에 대한 인증 방법을 제거한다. 반면 물리적 카드는 카드 소유자 검증을 위해 PIN과 서명이 필요하다. 또한 은행은 POS 단말기가 결제를 승인하지 전에 카드 소유자를 검증할 수 있도록 하는 단계를 추가하지 않는다. 이로 인해 CVM 필요없음은 디지털 지갑을 통해 지불이 이루어질 때 ‘성공적인’검증으로 변한다.

얻은 교훈

기기 검증을 통해 카드 소유자 검증을 수행하는 것은 편리하고 구현하기 쉽다. 그러나 기기 사용자와 카드 소유자가 동일 인물일 것이라는 잘못된 가정에 근거한다. 공격자가 자신의 지갑을 사용해서 피해자의 카드에 요금을 청부하고 결제 승인에 필요한 카드 소유자 인증을 우회할 수 있다.

4.3 Bypassing Access Control Policies through Recurring Transactions

지금까지 디지털 지갑을 통한 일회성 거래에 대한 인증 및 카드 소지자 검증의 취약점에 대해 이야기했다. Netflix 서비스 같은 구독 기간 서비스에 대한 반복 결제에서도 결함을 발견했다. 이는 일회성 결제와는 3가지 측면에서 다른다. (i)상인이 시작한다. (ii)주기적으로 실행된다. (iii) 거래 금액은 모든 주기적 거래에서 동일하다. 은행은 일회성 거래와 반복 결제를 다르게 취급하는데 이는 카드 소지자가 결제를 놓칠 경우 판매자로부터 불이익을 받기 때문이다. 카드 소유자의 연체 결제를 보호하는 것에 목적을 두고 있기 때문에 카드를 잠그거나 분실되어도 지갑에서 반복 지불을 처리한다. 이러한 반복 결제의 특수 처리로 인해 공격자는 잠긴 카드로 일회성 거래를 진행하지만 판매자가 이를 반복 결제로 분류하는 결함이 생긴다. 이런식으로 공격자는 잠금/분실 된카드에 일회성 결제 제한을 우회할 수 있다.(표1 참조)

이슈 4 — 공격자는 상인을 속여 일회성 거래를 반복으로 분류하고 은행의 접근 제어 제한을 우회할 수 있다.

공격 세부 정보

절차는 사용자가 디지털 지갑을 통해 판매자와 반복 결제 계약을 설정하는 것부터 시작한다. 이 때 지갑은 대리인 역활로 계약 세부 정보(결제 주기)와 판매자 정보를 은행에 보낸다. 요청을 받으면 은행은 지갑을 검증하고 판매자 토큰인 merchantID와 contractID를 판매자에게 제공한다. 이런식으로 은행은 판매자에게 반복 거래를 게시할 권한을 부여하여 판매자와의 신뢰를 구축한다. 은행은 추가 접근 제어를 검사하지 않고 등록된 merchantID와 contractID로 시작된 결제를 처리한다. 은행이 반복 거래를 처리하는 방식을 분석해보자 (그림 7 참조)

그림7

우선 공격자는 디지털 지갑을 사용해서 온라인 판매자에게 도난 당한 카드를 등록한다. 지갑은 REGISTER 요청을 토큰과 함께 판매자에게 보낸다(그림7 1). REGISTER 요청을 받으면 판매자는 AUTHENTICAT 요청을 merchantID와 지갑 토큰과 함께 은행에 보낸다.(그림7 2) 은행은 토큰을 확인하고 향후 거래를 지원하기 위해 판매자와 반복 결제 계약을 설정한다. 은행은 contractID를 생성하여 AUTHENTICATE 수락 메시지(그림7 3)에서 판매자와 공유한다. 판매자가 contractID를 수신하면 REGISTER 성공 메시지를 지갑에게 보내(그림7 4)등록은 완료한다. 판매자는 고객의 저장된 결제수단에서 발생하는 거래를 반복 거래로 처리한다(그림7 5). 비록 일회성 결제 이지만 판매자는 반복 이라고 표시한다(라벨 붙인다). 공격자는 이 결함을 사용하여 카드가 잠겨 있는 경우 일회성 거래에 대한 제한을 우회한다. 구매를 완료하기 위해서 판매자는 준비된 거래 세부 정보와 함께 AUTHORIZE 요청을 은행에 보낸다(그림7 6). 반복 거래를 승인하기 전에 은행의 접근 제어 모듈은 카드 소지자 없음 및 카드 정보 저장됨 플래그를 검증하여 그 거래가 사용자를 대신하여 판매자에 의해 시작되었는지 확인한다. 은행은 판매자의 PAN과 결제 계약을 검색하고 합의된 계약과 거래를 확인한다. 마지막으로 은행은 승인을 완료하고 판매자에게 AUTHORIZE 수락 메시지를 보낸다(그림7 7). 판매자는 지갑에게 PURCHASE 성공 메시지를 보낸다.(그림7 8)

주요 요점

은행이 판매자가 모든 거래를 ‘반복’으로 분류 할 수 있도록 허용하기로 한 결정은 사용성과 보안 간의 균형이다. 이 설계는 사용자가 물리적 카드를 잠금 후에도 서비스를 계속 사용할 수 있도록 하지만 일쇠성 거래에도 접근 제어 우회 취약성을 낳는다. 은행은 보안 모듈(접급 제어 및 사기 탐지 도구)을 사용해서 사용자의 기대하지 못한 거래를 필터링 한다. 그러나 이러한 도구들은 일회성 거래와 반복 거래를 구별할 수 없으며(특히 흔행에 이미 등록된 경우) 거래의 특성을 확인하지 못한다. 결과적으로 공격자는 일회성 거래에 대한 접근 제어 정책을 우회할 수 있고 카드 소유자가 카드를 잠근 경우에도 언제든지 원하는 금액으로 구매할 수 있다.

물리적 카드와 지갑을 통한 반복 거래는 어떻게 다른가? 피해자가 카드를 카드를 잠그거나 교체해도 새로운 반복 결제를 할 수 있다는 걸 강조한다. 물리적 카드의 경우 이전에 설정된 반복 결제만 처리되고 카드가 잠기면 새로운 반복 거래를 할 수 없다. 은행의 지갑에 대한 무한적인 무조건적 신뢰는 잠긴 카드데 대한 접근 제어 정책을 우회할 수 있는 트랩도어를 여는 것이다.

경험적 평가

잠긴 카드에서 일회성 거래를 하는 또 다른 방법을 보여준다. 공격자는 잠긴 카드에 의해 설정된 접근 제어 제한을 우회 할 수 있다. 이 실험에서 Citibans Mastercard를 사용한다(Cibibank의 카드는 잠긴 카드에 대해 일회성 거래를 허용하지 않는다). 공격자는 피해자의 카드를 훔쳐 지갑에 추가한다. 공격자가 Truo.com 사이트에 접속해서 신규 고객으로 등록하고 지갑을 지불 방법으로 설정한다. Truo는 지불 방법 세부 정보를 카드를 발급한 은행에 유저를 등록하고 반복 거래를 설정한다. 카드를 등록하고 렌터카 여행을 예약하고 지갑에 추가된 피해자의 카드를 사용해서 전액을 지불한다. 카드가 잠겨있지만 Truo는 반복 결제 라벨을 붙여 일회성 결제를 보낸다. 이는 은행에서 받은 이메일 영수증에서 확인했다.(그림 8 참조)

그림 8

이 취약점은 Truo에만 연관된 것이 아니다 apple.com에서도 진행했다. 위 실험대로 진행한 결과 25달러짜리 apple 기프트 카드와 179달러짜리 airpods를 성공적으로 구매했다. 은행이 접근 제어 정책의 일부로 반복 거래의 메타데이터를 확인하지 않는다는 결론을 내렸다.

근본 원인

은행의 접근 제어 정책은 등록된 결제 유형을 제한하도록 설계되지 않았다. 이런 결제는 완전히 신뢰되었고 반복 결제 계약(결제 금액, 주기)에 대해 검증되지 않았다. 은행은 판매자가 지정한 레이블을 대조검증 하기 위해 서비스와 제품 유형을 구분하지 않는다. 결과적으로 일회성 거래로 정의된 이러한 결제는 반복으로 라벨링되면 접근 제어 제한을 우회 할 수 있다. 반복 거래 시간은 피해자가 카드를 잠근 시간과 비교 검증되지 않는다. 카드가 잠겨 있음에도 반복 결제를 설정하는 것을 은행의 접근 제어는 이를 막을 수 없다. 이러한 설계 선택은 접근 제어 위반 위약성을 초래한다.

얻은 교훈

은행은 사용자와 판매자 간의 계약 존중을 위해 잠긴 카드에 대한 반복 결제를 허용한다. 사용자를 대신해서 적시에 결제함으로 구독 기반 서비스의 연속성을 허용한다. 한자기 유형의 결제를 다른 결제보다 특별 취급하는 것은 보안 공격에 취약하다. 공격자는 판매자를 속여 일회성 결제를 반복 결제로 라벨붙여 은행의 접근 제어 제한을 우회할 수 있다.

5 Proposed Countermeasures

네 가지 이슈에 대한 문제를 해결하기 위한 솔루션을 제공한다. 제공하는 솔루션은 기본적인 설계 결함과 은행의 정책 구현을 수정하여 논의된 문제와 유사한 다른 문제를 해결하는 것을 목표로 한다. 은행과 지갑에 솔루션을 제안했지만 주로 전용 지갑 앱과 접근 불가능한 은행 백엔드 시스템 때문에 받아들여지지 않았다. 솔루현을 구현한다면 어떻게 보일지 그림 9로 설명했다.

그림 9

기존 OTP 방법대신 push MFA 채택

기본 인증 방법은 취약한 것으로 증명된 레거시 솔루선에 의존한다. 은행이 푸시 알림(Bank App, Duo Mobile, Microsoft Authenticator)또는 패스 코드(Google Authenticator) 기반 솔루션(그림9 a)과 같은 최첨단 MFA 메커니즘을 사용해야 한다고 제안한다. 은행이 지갑의 기능과 선호도와 기능에 의존하지 보다는 지갑이 지원하는 인증 방법들 중 가장 강한 인증 방법을 사용해야 한다고 제안한다. 비슷하게 지갑은 사용자의 편의성보다 보안을 우선시해야한다. 이 솔루션은 이슈 1과 이슈2와의 전제 조건과 관련된 취약성, 피해자의 카드를 지갑에 추가하는 이슈3을 해결한다. 이 솔루션은 Duo, Google Authenticator, Microsoft Authenticator와 같은 타사 인증 서비스 공급자와 통합이 필요한다.

토큰 관리에서 지속적인 인증

지갑이 인증되고 지불 토큰이 발급되면 은행은 만료되지 않는 토큰을 무기한으로 사용한다. 이는 카드 분실, 기기 분실, 카드 삭제와 같은 중요한 이벤트가 발생하더라도 만료되거나 변경되지 않는 지갑에 대한 무조건적인 신뢰를 구축한다. 우리는 은행이 지속적인 인증 프로토콜을 채택하고 특히 카드 분실과 같은 중요한 이벤트 발생후에 지갑을 재인증하도록 토큰을 새로 만들것을 제안한다.(그림 9 b) 이 솔루션은 이슈1과 이슈4를 직접적으로 제거하고 이슈3을 간접적으로 제거한다. 공격자가 무조건 신뢰 정책 하에 따라 지갑을 사용할 수 있으므로 재인증을 통해 손상된 지갑이(이슈3) 매장 내 지불을 중단할 수 있다. 이 솔루션은 기존 인증 절차를 사용하여 주기적 업데이트를 포함함으로 은행 백엔드에서 상당한 변경이 필요하지 않다.

일회성 거래와 반복적