KR20060034228A - 전자 상거래 트랜잭션에서의 고객 인증 시스템 및 방법 - Google Patents

전자 상거래 트랜잭션에서의 고객 인증 시스템 및 방법 Download PDF

Info

Publication number
KR20060034228A
KR20060034228A KR1020057023208A KR20057023208A KR20060034228A KR 20060034228 A KR20060034228 A KR 20060034228A KR 1020057023208 A KR1020057023208 A KR 1020057023208A KR 20057023208 A KR20057023208 A KR 20057023208A KR 20060034228 A KR20060034228 A KR 20060034228A
Authority
KR
South Korea
Prior art keywords
authentication
transaction
data
cardholder
integrated circuit
Prior art date
Application number
KR1020057023208A
Other languages
English (en)
Inventor
브루스 러더포드
알프레드 닥허
마크 와이즈먼
디디에르 쟝-마리 챨스 파이에
쟝-폴 에드몬드 란스
피크레트 아테스
존 완크뮬러
Original Assignee
마스터카드 인터내셔날, 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마스터카드 인터내셔날, 인코포레이티드 filed Critical 마스터카드 인터내셔날, 인코포레이티드
Publication of KR20060034228A publication Critical patent/KR20060034228A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1025—Identification of user by a PIN code

Abstract

고객(180)의 온라인 트랜잭션을 인증하기 위하여 3-D Secure 프로토콜에 기반을 둔 칩 인증 프로그램을 제공한다. 지불 카드 발급자 등의 발급자는 액세스 제어 서버 및 인증 요청 서버(12)를 조작하여, 개인용의 EMV 규격에 부합하는 스마트 카드에 의해 식별되는 개개의 고객에 의한 트랜잭션을 인증한다. 상호작용 지점(POI)에서 웹 페이지를 제시하기 위하여 발급자에 의해 직접 전달되는 트랜잭션 특정 정보와 고객의 스마트 카드(170)로부터의 정보에 기초하여 각각의 트랜잭션에 대한 상호작용 지점(POI)에서 인증 토큰이 생성된다. POI에서 생성되는 인증 토큰은 인증 요청 서버(120)에 의해 평가되어, 트랜잭션 POI에서의 카드 존재 및/또는 개개의 고객을 인증할 수 있다. 인증 값은 3-D Secure 프로토콜에 부합하는 범용의 카드 보유자 인증 필드에서 온라인으로 전달된다.

Description

전자 상거래 트랜잭션에서의 고객 인증 시스템 및 방법{CUSTOMER AUTHENTICATION IN E-COMMERCE TRANSACTIONS}
본 발명은 인터넷 등의 전자적인 개방 네트워크를 통해 당사자들에 의해 수행되는 트랜잭션을 인증하는 시스템 및 방법에 관한 것이다. 더 상세하게는, 본 발명은 고객이 요금을 신용 카드 또는 직불 카드로 지불하는 인터넷 트랜잭션의 인증에 관한 것이다.
관련 출원의 상호 참조
본 출원은 2003년 6월 4일에 출원된 미국 가특허 출원 제60/475,639호의 우선권을 주장하며, 이 가특허 출원의 전체 내용이 본 명세서에 참조로서 포함되는 것으로 한다.
전자 상거래(E-commerce)는 현재 널리 사용되고 있다. 인터넷 등의 전자 네트워크를 통해 트랜잭션("전자 거래" 또는 "거래"라고도 함)을 수행하는 것은, 판매업자(merchants)와 고객(customers) 모두에게 편리성, 저렴한 비용, 시장 선택이라는 일반적으로 잘 알려진 장점을 제공한다. 그러나, 인터넷의 익명성에 의해, 상업적 또는 소매 판매에 있어서 사기 및 오남용의 문제점이 유발되고 있다. 트랜잭션을 수행하는 판매업자는, 판매를 인증하고, 투명하게 하며, 확인하고, 부인방 지(non-repudiation)를 보증하며, 요금 지불을 보증하고, 익명성을 규제하기를 원하고 있다. 마찬가지로, 구매자도 판매의 인증, 판매의 무결성, 회수 불능의 판매(bad sale)에 대한 상환청구(recourse), 판매의 확인, 프라이버시, 및 익명성을 규제하기를 원하고 있다.
공동으로 발명되었으며 공동 소유하는 국제특허출원 WO03/073389호는 인터넷을 통해 수행되는 고객과 판매업자의 트랜잭션에서 고객을 인증하기 위한 네트워크 지불 시스템을 개시하고 있으며, 이 출원의 전체 내용은 본 명세서에 참조로서 포함되는 것으로 한다. 인터넷은 판매업자측 서버 및 고객 단말을 지불(결제) 서버에 연결시킨다. 고객은 ICC(Integrated Circuit Card: IC(집적회로) 카드)를 식별 장치로서 이용한다. ICC는 카드 판독기를 통해 고객 단말과 통신을 수행한다. ICC는 진행 중인 트랜잭션에 관한 정보에 따라 암호(암호문)를 생성한다. 이 정보는 고객 단말에 의해 생성되는 챌린지(질문) 메시지(challenge message)가 될 수 있다. 카드 판독기는 ICC에 의해 생성되는 암호문의 일부를 고유의 인증 토큰(authentication token)으로 변환하고, 이 토근을, 예컨대 인터넷을 통해 지불 서버에 전송하여 고객을 인증할 수 있다.
인터넷을 통해 구매한 상품 및/또는 서비스(용역)의 요금 지불을 위한 "스마트" 칩 카드에 의해 수행하는 다른 인터넷 지불 시스템이, 데이비스(Davis) 등이 발명한 미국특허 제6,282,522호에 개시되어 있다. ICC와 그외 다른 스마트 카드는 다양한 요금 지불 시스템 간에 상호 운용이 가능하도록, 공통의 산업 표준 규격[예를 들어, Europay International(유로패이), Master Card International(마스터카 드), 및 VISA International(비자카드)의 3사가 공동으로 개발한 IC 카드의 표준 규격인 EMV 표준 규격]에 기초할 수 있다.
카드 발급자 및 그외 다른 금융 기관들은 표준화된 국제 트랜잭션 프로토콜을 제공 또는 사용하여, 온라인 트랜잭션 성능을 향상시키고 전자 상거래의 성장을 가속화하고 있다. 카드 발급자 또는 발급 은행은, 일부 표준화된 프로토콜(예를 들어, Visa International이 개발한 3-D Secure(등록상표) Protocol)을 이용하여 트랜잭션을 인증할 수 있어서, 사기(fraud) 등의 부정행위 가능성을 감소시키고, 카드 보유자의 인증되지 않은 트랜잭션에 대한 환불청구(chargeback)를 감소시킬 수 있게 된다. 트랜잭션을 인증하는 것에 의하여, 발급자는 온라인 구매를 수행하는 동안 카드 보유자를 인증하는 노력에도, 사기 등의 부정행위가 발생하면, 그 부정행위에 대한 책임을 지게 된다. 판매업자에 대해서는, 발급자가 인증한 트랜잭션에 대해 지불을 행하는 카드 발급자 또는 발급 은행이 책임을 진다. 3-D Secure(등록상표) 프로토콜은, 인터넷과 관련된 트랜잭션 등의 원격 트랜잭션이 수행되는 동안, 판매업자와 거래하는 고객을 인증하기 위하여, 카드 발급자(예컨대, Visa 또는 MasterCard SecureCode(등록상표)에 의해 검증)에 의해 제공되는 인증 프로그램과 일치되며, 이 프로그램에 기반을 두고 있다. 3-D Secure(등록상표) 프로토콜은 기존의 SSL(Secure Socket layer) 암호화 기능을 이용하고, 온라인으로 쇼핑하는 동안, 카드 보유자의 발급자 인증을 통해 강화된 보안을 제공한다. 온라인 구매가 이루어지는 동안, 카드 보유자와 카드 발급자 사이에서 인증 세션(authentication session)을 구축(설정)하기 위하여, 판매업자를 참가시켜 메시지 를 교환하고, 정보를 전달하며, 참가자에게 질의하기 위하여, 인증 모듈인 MPI(Merchant Plug-in: 판매업자 플러그인)라고도 불리는 소프트웨어가 이용된다.
3-D Secure 프로토콜 서비스는 3-도메인 모델, 즉 발급자 도메인, 취득자 도메인, 및 상호운용 도메인에 기반을 두고 있다. 발급자는 이러한 프로토콜 서비스에서 카드 보유자의 등록(enrollment)을 관리하며, 온라인 트랜잭션이 수행되는 동안 카드 보유자를 인증하는 책임을 진다. 취득자(acquirer)는 인터넷 트랜잭션에 참가하는 판매업자가 취득자와의 협의하에서 행동하도록 하는 절차를 규정하고, 인증된 트랜잭션을 위한 백엔드 처리업무(back end processing)를 제공한다. 상호운용 도메인은 다른 두 개의 도메인과 공통의 프로토콜 및 공유 서비스 사이에서의 트랜잭션 교환을 용이하게 한다. 카드 보유자 및 이와 관련된 금융 기관은 "발급자 도메인"에 해당될 수 있으며, 판매업자 및 이와 관련된 금융 기관은 "취득자 도메인"이 될 수 있다. 발급 은행 및 획득 은행 또는 금융 기관과, 카드 발급자 기반시설 간의 통신은 "상호운용 도메인"에 해당될 수 있다. 3-D Secure에 부합하는 은행 및 판매업자와의 트랜잭션을 수행하는 동안, 트랜잭션을 수행하는 당사자가 기록된 실제의 카드 보유자인지 여부를 판정하기 위하여, 카드 보유자의 은행으로부터 별도의 인증 창 또는 팝업 스크린이 제공된다는 것을 제외하고는, 고객은 이전과 동일한 인터넷 쇼핑 경험을 가질 수 있다. 프로토콜에 기반을 둔 온라인 인터넷 구매 트랜잭션에 대한 트랜잭션 흐름은 다음과 같다.
(1) 고객이, 암호화된 SSL(Secure Sockets Layer) 접속을 통해, 판매업자의 웹 사이트에서 요금 지불 데이터를 일반적인 형식으로 기입한다.
(2) 판매업자가 MPI(Merchant Plug-in)를 통해 메시지를 디렉토리(Directory)에 전달하고, 고객이 3-D Secure 프로그램에 등록되어 있는지를 알아내도록 카드 발급자에게 질의한다.
(3) 카드 발급자는 카드 보유자가 등록되어 있는지 여부를 나타내는 메시지에 따라 디렉토리(Directory)에 응답하는데, 카드 보유자가 등록되어 있다면, 카드를 발급한 은행에 대하여 웹 어드레스를 제공한다. 이후, 메시지가 처리되고, 응답이 판매업자에게 제공된다.
(4) 판매업자는 카드 보유자의 장치를 통해 메시지를 발급 은행에 전달하여, 판매업자의 이름 및 트랜잭션의 거래량(금액) 등의 트랜잭션 세부항목이 확인을 위해 카드 보유자에게 제공될 수 있는, 카드 보유자와 카드 발급자 간의 인증 세션(authentication session)을 개시한다.
(5) 발급 은행은 판매업자의 이름, 금액, 개인용 보안 메시지, 및 인증 세부항목이 카드 보유자에 의해 입력가능한 응답 영역 등의 트랜잭션에 관련된 정보를 열거하는 카드 보유자에게, 인증 창을 제시(populate)한다.
(6) 고객은, 시스템을 구현하기 위하여 발급 은행이 선택하는 방법에 따라, 여러 가지 방법들 중 하나를 이용하여 트랜잭션을 승인한다. 인증 토큰을 생성하기 위하여, 고정된 패스워드 또는 PIN을 입력하는 것에서부터 스마트 카드 및 개인용 카드 판독기(PCR: Personal Card Reader)를 이용하는 것까지 선택이 가능하다.
(7) 인증이 타당하다면, 발급자는 트랜잭션이 성공적이었다는 것을 나타내는 메시지를 판매업자에게 전달한다. 또한, 발급자는 인증이 실패 또는 완료되지 않 았다는 것을 판매업자에게 통보한다.
전자적 트랜잭션에서 요금 지불을 위한 신용 카드 또는 직불 카드를 사용하는 고객을 인증하기 위한 솔루션을 개선하는 방법을 제공한다. 본 발명의 목적은, 상호작용 지점(POI: point-of-interaction)에서 카드 보유자를 인증함으로써 판매업자의 인터넷 판매 채널을 안전하게 하고, POI에서 카드와 카드 보유자가 모두 존재하고 있음을 나타내는 명시적인 증거를 생성하는 솔루션을 제공하는 것이다. 바람직한 솔루션은 3-D Secure 및 스마트 카드에 대한 EMV 표준 규격 등의 그외 다른 산업 표준 규격과 같은 공통의 프로토콜의 산업상의 구현과 호환될 수 있어야, 단순하고 고정적인 패스워드 또는 PIN을 능가하도록 인증을 향상시킬 수 있다.
본 발명에 의하면, 전자 상거래(e-commerce)에서 고객의 트랜잭션을 인증하기 위하여, 3-D Secure 프로토콜에 기반을 둔, 칩 인증 프로그램(CAP: Chip Authentication Program)이 제공된다. 기존의 전자 상거래 기반구조 및 기술의 최상위에 놓일 수 있는 CAP의 구현에 의해, EMV와 3-D Secure 기술의 무결점 통합(seamless integration)이 제공되어, 종래의 고정적인 패스워드 솔루션에 비해 보다 개선된 인증을 얻을 수 있다. CAP에 의한 구현은 온라인 판매업자에 대하여, 고객의 신원이 용이하게 검증되는 물리적인 판매시점관리(POS: point-of-sale) 트랜잭션을 굴뚝기업(brick-and-mortar) 소매상이 향유하는 보증과 유사한, 지불 카드 발급자로부터 국제적 지불 보증(global payment guarantees)을 수신하기 위한 메커니즘을 제공한다.
CAP에서, 발급자(예컨대, 지불용 카드 발급자)는 각각의 개별 트랜잭션에 기초하여 당사자에게 인증 서비스를 제공한다. 발급자는 프로그램에 등록되어 있는 고객에 의해 트랜잭션을 인증하기 위한 액세스 제어 서버(ACS: Access Control Server) 및 이와 관련된 인증 요청 서버(ARS: Authentication Request Server)를 조작한다. 고객 및 트랜잭션을 고유하게 식별하는 암호화된 정보에 기초하여 인증이 요청되는 각각의 트랜잭션에 대한 인증 토큰이 상호작용 지점(POI)에서 생성된다. 트랜잭션을 수행하는 고객은 토큰이 생성되는 상호작용 지점(POI)에서 개인 식별자로서, 집적 회로 칩(ICC) 카드에 내장된, EMV에 기반을 둔 인증 애플리케이션을 이용한다. 판매업자 또는 토큰에 포함시키기 위한 트랜잭션 전용의 정보가 발급자에 의해 POI에 직접 제공되는데, 예를 들면 POI에서 통상의 인터넷 브라우저의 웹 페이지를 제시함으로써 제공될 수 있다. CAP 구현에 의해, 개별적인 판매업자 전용의 소프트웨어를 POI(예컨대, 고객의 액세스 장치)에서 다운로드하거나 표시(예컨대, 애플릿(applet))할 필요가 없다는 장점을 가진다.
POI에서 생성되는 인증 토큰은 트랜잭션 POI에서의 고객 및/또는 카드의 존재를 인증하기 위하여 ARS에 의해 평가된다. 평가가 완료되면, ACS에 의해 AAV가 생성된다. 이 AAV는 3-D Secure 프로토콜과 일치하는 포맷으로 UCAF에서 전자 네트워크를 통해 전달된다.
바람직하게, 전자 네트워크상에서 고객 트랜잭션을 인증하기 위한 본 발명의 시스템은 네트워크 액세스 장치, 고객 식별용 데이터를 포함하며 고객에게 발행되는 집적 회로 칩, 액세스 장치에 연결가능하고(물리적으로, 전자적으로, 또는 카드 보유자의 수동 조작에 의해) 직접 회로 칩과 통신가능한 판독기, 전자 네트워크에 연결되어 트랜잭션의 인증을 요청하는 당사자와 통신할 수 있는 인증 요청 서버(ARS) 및 액세스 제어 서버(ACS)를 포함한다. ACS는 트랜잭션의 인증을 위한 고객의 액세스 장치와 직접 통신하도록(예컨대, 카드 보유자의 인증 페이지를 통해) 구성된다. 이러한 직접 통신에 의해, 요청 당사자(예컨대, 판매업자)로부터 고객의 액세스 장치에 인증 소프트웨어를 다운로드할 필요가 없게 된다. ARS는 요청 당사자로부터 트랜잭션 정보를 수신하고, 고객 액세스 장치를 통해 판독기와 트랜잭션 데이터를 송수신한다. 판독기는 트랜잭션 데이터를 처리하고, 이 트랜잭션 데이터에 기초한 값을 집적 회로 칩과 통신할 수 있다. 집적 회로 칩은 트랜잭션 데이터의 적어도 일부와 고객 식별용 데이터의 적어도 일부에 기초하여 이 칩에 대하여 암호문을 생성하기 위하여 인증 애플리케이션을 갖는다. 판독기는 생성된 암호문에 기초하여 인증 토큰을 생성하여 ARS와 통신할 수 있으며, ARS는 인증 토큰으로부터 고객 식별용 데이터를 평가하고, 이에 따라 인증 토큰의 유효 여부를 확인하도록 구성된다. 인증 토큰은 3-D Secure 프로토콜 메시지 포맷과 호환가능한 포맷으로 될 수 있다. 인증 토큰에 대한 평가가 성공적으로 완료되면, ACS는 AAV를 생성하는데, 이 AAV는 길이가 20 바이트인 UCAF에서 전자 네트워크를 통해 전송된다.
ARS는 먼저 암호문을 생성하기 위하여 칩에 의해 이용되는 데이터를 재구축하고, 다음으로 재구축된 데이터로부터 복제 또는 재생성된 암호문을 생성한 후, 인증 토큰을 이 복제 암호문과 매칭시킴으로써, 인증 토큰으로부터 고객 식별용 데이터를 평가한다.
바람직하게는, 네트워크 액세스 장치를 이용하여 전자 트랜잭션에 참가하는 고객의 원격 인증을 위한 본 발명의 방법은, 고객 식별용 데이터를 갖는 집적 회로 칩을 고객에게 제공하는 단계와, 고객의 네트워크 액세스 장치에 연결가능하고 칩과 통신하는 판독기를 제공하는 단계를 포함한다. 본 발명의 방법은 전자 네트워크에 연결가능하고 판독기와 데이터를 송수신하는 인증 요청 서버(ARS)를 이용하여, 트랜잭션 전용의 정보를 수신하고, 트랜잭션 전용의 데이터를 판독기와 주고 받는 단계와, 판독기를 이용하여, 트랜잭션 전용의 데이터를 칩과 주고 받고, 집적 회로 칩으로 하여금, 트랜잭션 전용의 데이터의 적어도 일부와 고객 식별용 데이터의 적어도 일부에 기초하여 암호문을 생성하는 단계와, 판독기를 이용하여 직접 회로 칩에 의해 생성되는 암호문의 적어도 일부에 기초하여 인증 토큰을 생성하는 단계를 추가로 포함한다. 본 발명의 방법은 ARS를 이용하여 인증 토큰의 유효 여부를 확인하는 단계와, UCAF 메시지에서 전자 네트워크를 통해 발급자에게 전송하기 위한 AAV를 생성하는 단계를 추가로 포함한다.
본 발명의 다른 특징, 특성 및 다양한 장점들에 대해서는 첨부 도면과 이하의 상세한 설명으로부터 더 명백해질 것이다.
본 발명의 다른 특징, 특성 및 다양한 장점들에 대해서는 첨부 도면과 이하의 상세한 설명으로부터 더 명백해질 것이다. 유사한 참조 부호는 전 명세서를 통해 유사한 구성요소를 나타낸다.
도 1 및 2는 본 발명의 원리에 따라, 칩 인증 프로그램 및 처리의 흐름에 대 한 예시적인 구현을 개략적으로 나타내는 도면이다.
도 3 및 4는 본 발명의 원리에 따라, 접속식 PCR 및 비접속식 PCR에 대한 챌린지 번호(challenge number)의 생성 및 PIN 검증에 포함되는 개인용 카드 판독기의 처리 및 데이터 흐름을 개략적으로 나타내는 도면이다.
도 5는 본 발명의 원리에 따라 8자리 챌린지의 예를 나타내는 도면이다.
도 6은 본 발명의 원리에 따라 IIPB 데이터 토큰의 예를 나타내는 도면이다.
도 7은 본 발명의 원리에 따라, 암호 비트 패턴을 이진수로서 처리하고, 기수 2 표기법으로부터 기수 10 표기법까지 수학적 변환을 수행하는 압축 처리의 예를 나타내는 도면이다.
도 8은 본 발명의 원리에 따라, 3-D Secure(등록 상표) 환경에서 예시적인 CAP(칩-인증 처리된) 트랜잭션에 포함되는 개체들 사이에서의 단계 또는 메시지 흐름을 (도 1 및 도 2와 관련하여)나타내는 도면이다.
도 9는 본 발명의 원리에 따라, IIPB 데이터 구조의 예를 나타내는 도면이다.
도 10은 본 발명의 원리에 따라, 3-D Secure와 호환 가능한 UCAF를 나타내는 도면이다.
도 11은 본 발명의 원리에 따라, 판매업자가 트랜잭션을 위한 카드 보유자 인증을 선택적으로 요청할 수 있는 전자 상거래 환경에서 고객의 온라인 구매에 포함되는 처리 단계를 (도 1 및 도 2와 관련하여)나타내는 도면이다.
도 12는 본 발명의 원리에 따라, ICC, PCR 및/또는 PC 장치의 기능이 하나의 편리한 물리적 패키지에 통합되는 통합 장치의 예를 개략적으로 나타내는 도면이다.
전 도면을 통하여, 특히 다르게 언급된 것을 제외하고는, 동일한 참조부호 및 문자는 도시 및 설명된 실시예의 유사한 특징, 요소, 성분 또는 일부분을 나타내는데 사용되고 있다.
본 발명은 전자 트랜잭션에서 원격 당사자를 인증하기 위한 솔루션을 제공한다. 특히, 본 발명의 시스템 및 방법은 전자 트랜잭션에 원격으로 참가하는 카드 보유자를 인증하는 것에 관한 것이다. 또한, 본 발명의 솔루션은 3-D Secure에 부합하는 전자 상거래 플랫폼 등의 산업상 표준 상거래 플랫폼으로 수행되는 전자 트랜잭션과 관련된 인증에 관한 것이며, 우편 주문 및 전화 주문 등의 비전자 상거래(non e-commerce) 환경 또는 인증 토큰이 발급자에 의해 이용되어 카드 보유자를 인증할 수 있는 모바일 장치와 관련된 인증에 관한 것이다.
하나의 솔루션으로서 "칩 인증 프로그램(CAP)"은 인증 주체로서의 카드 발급자 또는 발급 은행에 있어서 중요하다. 이 인증 주체는 프로그램에 등록된 고객을 인증하기 위한 액세스 제어 서버(ACS) 및 관련 인증 요청 서버(ARS)를 관리할 수 있다. CAP는 등록된 카드 보유자에게 발급되는 집적 회로 칩(ICC) 카드에 내장된 EMV에 기반을 둔 인증 애플리케이션을 이용한다. 카드 보유자는 온라인 트랜잭션을 수행하는 동안 EMV에 기반을 둔 인증 애플리케이션을 이용하여, 특정 트랜잭션에 대한 원격 인증(remote authentication)을 획득할 수 있다. 인증 애플리케이션 은 일대일로 대면하는 판매업자와 고객의 트랜잭션을 위해 설계된 칩 카드에서 다른 통상적인 EMV 요금 지불 애플리케이션과 개별적으로 또는 이러한 애플리케이션에 추가될 수 있다.
카드 보유자는 개인용 카드 판독기(PCR)와 관련하여 ICC를 이용할 수 있으며, 이에 의하여 일회용의 사용을 위한 동적 "보안 코드"(secure code) 또는 인증 토큰을 생성할 수 있다. 이를 위하여(예컨대, 보안 코드를 수신하기 위하여), 카드 보유자 인증 페이지가 생성되어, 카드 보유자의 인터넷 액세스 장치에 표시될 수 있다. 카드 보유자 인증 페이지는, 카드 보유자 장치에 대하여 다른 미리 설치된 소프트웨어 또는 추가의 소프트웨어에 대해서 전혀 필요로 하지 않으면서, 발급자의 액세스 제어 서버에 의해서만 제어될 수 있다. CAP는 카드 보유자를 인증하기 위한 다른 보안 솔루션에 대한 대체 수단으로서 또는 그 솔루션에 추가하여 구현될 수 있다. 다른 보안 솔루션으로는, 예컨대 고정된 패스워드를 통한 인증이 포함된다. CAP는 스마트 카드를 위한 어떤 표준 칩 기술을 이용해서도 구현이 가능하다. 그러나, 이러한 구현은 표준 EMV 칩 기술을 이용하는 것이 바람직하다.
CAP는 전자 상거래 요금 지불 및 발급자 서비스의 인증을 위한 신뢰 구조 메커니즘을 제공할 수 있다. CAP는 요금 지불 트랜잭션 인증을 위한 공통의 요금 지불 시스템 네트워크를 통해 통상적인 인증 경로를 이용할 수 있다. CAP의 한가지 버전은 판매업자, 취득자, 및 발급자 시스템 간의 종단간(end-to-end) 상호운용을 위한 3-D Secure 버전 1.0.2 하부 기반 구조와 호환 가능하다. 여기서, 판매업자, 취득자, 및 발급자 시스템은 모두 공동으로 협의한 산업 표준에 의해 3-D Secure 하부 기반 구조를 지원한다.
참조로서 본 명세서에 포함되는 국제특허출원 WO03/073389호에는, 발급자, 카드 보유자, 및 판매업자 사이에서 인증 데이터를 교환하기 위하여, 3-D Secure 기술이 아닌, 판매업자가 일련의 MasterCard에서 정의한 히든 HTML(Hypertext Markup Language) 필드를 이용하는 범용의 카드 보유자 인증 필드(UCAF: Universal Cardholder Authentication Field)에서, 발급자에의 전송을 위한 인증 토큰을 생성하는, 개인용 카드 판독기(PCR)를 이용하는 ICC 인증 프로그램에 대하여 개시되어 있다. 참조되는 출원에서 정의되는 동일한 용어, 두문자어, 및 약어가 본 명세서에서도 일반적으로 사용된다는 것을 이해할 수 있을 것이다. 본 발명의 이해를 돕기 위하여, 참조되는 출원의 전문 용어 리스트와 그외 다른 부분을 인용한다.
전문 용어
AAC Application Authentication Cryptogram (애플리케이션 인증 암호(문))
AAV Accountholder Authentication Value (계좌 보유자 인증값)
AC Authentication Cryptogram (인증 암호(문))
AFL Application File Locator (애플리케이션 파일 로케이터), ICC 내의 어디에 어떤 기록이 있는지를 식별한다.
AID Application Identifier (애플리케이션 식별자), ICC 내에서 소정의 애플리케이션을 식별하는 16진수 열.
AIP Application Interchange Profile (애플리케이션 상호교환 프로파일), 특정의 기능을 지원하기 위한 ICC의 능력을 나타낸다.
APDU Application Processing Data Unit (애플리케이션 처리 데이터 유닛), ICC와 일부 외부 애플리케이션 사이에서 전달되는 메시지.
ARQC Application Request Cryptogram (애플리케이션 요청 암호)
ATC Application Transaction Counter (애플리케이션 트랜잭션 카운터)
BCD Binary Coded Decimal (이진화 십진수)
Big-Endian (빅 엔디안), 최상위 바이트가 먼저 오고 다음에 각각의 연속하는 바이트가 연결되고 마지막으로 최하위 바이트가 기억되는 부호화 형식.
CAP Chip Authentication Programme (칩 인증 프로그램)
CDOL Card risk management Data Object List(카드 위험 관리 데이터 오브젝트 리스트)
CID Cryptogram Information Data (암호 정보 데이터)
CSN Card Sequence Number (카드 일련 번호)
CVC2 Card Verification Code (카드 검증 코드)
CVM Cardholder Verification Method (카드 보유자 검증 방법), 카드에 대하여 카드 보유자를 검증하기 위해 이용되는 방법.
DAC Dynamic Authentication Cryptogram (동적 인증 암호)
DOM Document Object Model (문서 객체 모델), 브라우저에 의해 제공되는 현재의 HTML 페이지의 플러그인(plug-in)에 대한 프로그램적인 방식.
HHD Hand held device (파지가능한 휴대형 장치), 예컨대 카드 판독기
EMV Europay Mastercard Visa (유로패이, 마스터카드, 및 비자카드의 3사가 공동으로 개발한 IC 카드의 표준 규격)
IA Interface Application (인터페이스 애플리케이션)
IAD Issuer Application Data (발급자 애플리케이션 데이터)
IAF Internet Authentication Flags (인터넷 인증 플래그), IIPD의 첫 번째 바이트
ICC Integrated Circuit Card (집적 회로 카드), 칩카드(Chipcard) 또는 스마트카드(Smartcard)라고도 함.
IIPB Issuer Internet Proprietary Bitmap (발급자 인터넷 고유 비트맵), AC의 유효 여부를 확인하기 위하여 발급자에게 전달되어야 하는 비트를 식별한다.
IIPD Issuer Internet Proprietary Data (발급자 인터넷 고유 데이터), 인터넷 관련 트랜잭션을 위한 암호 계산과 관련하여 발급자에 의해 이용되는 고유 데이터(proprietary data).
ITV Interactive Television (대화형 텔레비전)
LATC Lower(byte of) Application Transaction Counter (하위 바이트의 애플리케이션 트랜잭션 카운터)
Little-Endian (리틀 앤디안), 최하위 바이트가 먼저 오고 다음에 각각의 연속하는 바이트가 연결되고 마지막으로 최상위 바이트가 기억되는 부호화 형식.
MAC Message Authentication Code (메시지 인증 코드), 메시지 내의 데이터 아이템에 대하여 계산되는 암호 서명으로서, 이 메시지의 기원을 증명하고 이들 데이터 아이템이 변경되었는지 여부의 검출을 위한 것.
MCD Main Cardholder Device (메인 카드 보유자 장치), 브라우징 및/또는 주문 및/또는 요금 지불이 수행되는 장치.
Nibble (니블), 1 바이트의 절반, 즉 4 비트
PI APDU의 파라미터 1, ICC에 전달되는 커맨드를 효율적으로 구성한다.
PAN Primary Account Number (주요 계좌 번호)
PC Personal Computer (개인용 컴퓨터)
PCR Personal Card-Reader (개인용 카드 판독기)
Cardholder IA Cardholder Interface Application (카드 보유자 인터페이스 애플리케이션), 인증 요청자, 카드 보유자 및 PCR 사이에서 인터페이스를 행하며, MCD에서 구동되는 애플리케이션.
PDA Personal Digital Asistant (휴대 정보 단말기)
PDOL Processing Options Data Object List (처리 옵션 데이터 오브젝트 리스트), 단말기에 의해 이용 가능하고/지원 가능한 처리 옵션의 리스트.
PIN Personal Identification Number (개인 식별 번호)
SPA Secure Payment Application (안전한 지불 애플리케이션)
TLV Tag Length Value (태그 길이 값)
UCAF Universal Cardholder Authentication Field (범용 카드 보유자 인증 필드)
UN Unpredictable Number (예측 불가능한 숫자)
국제특허출원 WO03/073389호에 개시된 인증 체계는 범용 카드 보유자 인증 필드(UCAF)를 사용한다. 이 인증 체계는 다음의 요소, 즉 발급자를 규정한 Chip-UCAF의 사용이 가능한 인터페이스 애플리케이션, Chip-UCAF 계좌 소유자 인증 값(AAV: Accountholder Authentication Value) 생성, 카드 보유자 인증, 판매업자 프리젠테이션, UCAF에서의 AAV 데이터의 수집 및 처리, 인증 데이터 필드, 취득자 승인 및 UCAF에 포함된 것으로의 AAV 데이터의 처리, UCAF 인증 데이터 필드에서의 AAV 데이터의 보유를 지원하기 위한 은행 네트워크 개발, 및 UCAF 인증 데이터 필드에서 AAV 데이터의 인증 지원을 포함한다.
다음에 열거하는 개체들은 Chip-UCAF 인증 트랜잭션의 수명 주기에 포함된다.
카드 보유자(Cardholder) - 카드 보유자는 트랜잭션을 개시하며, 판매업자의 지불 웹 페이지, 카드 보유자의 인터페이스 애플리케이션 및 개인용 카드 판독기에 데이터를 입력시키는 책임을 진다.
판매업자(Merchant) - 판매업자는, 예를 들어 인터넷과 통신이 가능한 판매업자측 서버로부터, 인증 트랜잭션을 개시하는데 필요한 데이터를 제공하고, 이에 의하여 얻어진 UCAF 데이터를 수신하여, 이들의 취득자를 통해 승인을 받기 위해 카드 발급자에게 보낸다.
카드 보유자 인터페이스 애플리케이션(Cardholder Interface Application) - 카드 보유자의 IA는 판매업자에 의해 제공되는 관련 데이터를 검출하고, 카드 보유자와 직접 및 간접으로 카드 보유자를 통해 개인용 카드 판독기를 이용하여 상호작용을 행한다. 카드 보유자의 IA는 AAV 및 UCAF를 생성하고, 적절한 데이터를 가진 판매업자의 페이지를 제시한다.
개인용 카드 판독기(Personal Card-Reader) - PCR은 카드 보유자 및 ICC와 상호작용을 행하여, 발급자에게 간접적으로 전달되는 인증 토큰을 생성한다.
ICC - 칩 카드는 제출된 PIN 검증을 이용하여 카드 보유자를 인증하고, PCR에 의해 제공되는 데이터에 기초하여 적절한 암호문을 생성한다.
취득자(Acquirer) - 취득자는, 예컨대 취득자 서버에서 판매업자로부터 포맷화된 UCAF를 승인하고, 이것을 UCAF 데이터의 존재 및 이용의 인디케이터와 함께, 적절한 전기통신 네트워크를 통해 발급 은행에 제공한다.
마스터카드(Mastercard)가 취득자이다.
발급자(Issuer) - 카드 발급자는 Chip-UCAF 체계에 따라 서명된 카드 보유자에게 PCR을 분배한다. 발급자는 인터넷과 통신가능한 발급자측 서버 플랫폼을 유지한다. 본 발명에 의하면, 발급자측 서버는, 그 발급자의 규칙에 따라 취득자에 의한 인증 요청으로 전송된, UCAF에 부호화된 인증 토큰의 유효 여부를 확인한다.
국제특허출원 WO03/073389호에 의하면, UCAF(범용 카드 보유자 인증 필드)의 데이터 필드는 임의의 형태의 전기통신 네트워크를 통해 취득자로부터 발급자에게 인증 데이터의 통신을 허용하기 위하여, 디지털 메시지 내의 다목적의 데이터 전송 영역이다. 예를 들어, UCAF는 32개 문자의 필드(1개의 제어 바이트 및 23개의 데이터 바이트가 24 바이트로 되는, 64진법으로 부호화되는 32개의 문자)이며, 다양한 발급자의 보안 및 인증 요건을 지원하기 위해 구성가능한 유연한 데이터 구조를 구비해도 된다. 예를 들어, ISO 8583 데이터 요소 48, 서브요소 43은 UCAF를 포함하도록 지정되어도 된다. UCAF라고 하는 용어는 판매업자와 MCD의 사이에서 데이터를 전달하고 되돌려받기 위하여 규정되는 인터페이스, 즉 임의의 소정 채널에 대한 명세서 내의 필드명을 가리킨다. UCAF는 24 바이트의 사용자 인증 토큰을 포함할 수 있다. 이들 24 바이트는 카드 보유자 IA에 의해, 예컨대 64 진수로 부호화되어, 판매업자에게 되돌려주는 데이터의 32개의 아스키(ASCII) 문자를 제공하는 것이 바람직하다. 판매업자는 발급자에게 전달되는 인증 요청 메시지에서 UCAF를 제시할 수 있는 취득자와의 고유 통신으로, UCAF 데이터를 전달한다.
계좌 보유자 인증 값(AAV)은 UCAF 애플리케이션 특정 데이터의 일부, 예컨대 23 바이트로 주어진 항이다. 각각의 UCAF 애플리케이션은 AAV에 대한 적절한 구조를 판정하는 책임을 진다. 소정의 UCAF가 구현될 때마다 그 애플리케이션의 AAV 구조를 일정하게 이용하여야 한다. 즉, AAV 포맷은 주어진 UCAF 애플리케이션에 대해 표준화된다.
Chip-UCAF 카드 보유자 인증 체계를 이용하기 위하여, 카드 보유자는 적절한 ICC 지불 카드 및 개인 카드 판독기가 있어야 한다. PCR은 이들 카드 발급자에 의해 카드 보유자에게 제공될 것이며, 카드 발급자에 의해 카드 보유자가 PCR을 가지고 있으며 Chip-UCAF 카드 보유자 인증 체계에 "등록"되어 있다는 것을 기록할 것이다. 판매업자에 의해 제공되는 UCAF 트랜잭션 데이터는 표시하기 위하여 이용되며, 그 일부는 트랜잭션과 관련된 PCR 챌린지(질문)를 생성하는데 이용된다. 판매업자가 UCAF 응답 내에서 AAV 데이터에 대해 수행할 필요가 있는 추가의 처리는 없 다. 이것은 UCAF 제어 바이트 값이 Chip-UCAF에 대한 값으로 설정되는 것을 통해 판매업자에게 표시된다. 카드 보유자 인터페이스 애플리케이션(카드 보유자 IA)은 인증 취득자(판매업자), 카드 보유자 및 PCR 사이에서의 상호작용을 제공한다. 인터페이스 애플리케이션은 현재의 UCAF 체계의 보안 특징을 카드 보유자에게 제공한다. 인터페이스 애플리케이션은 트랜잭션 데이터를 카드 보유자에게 제공하고, PCR에 전달되는 챌린지를 생성하며, PCR 토큰 응답을 수신하고, UCAF를 포맷화하며, 주어진 채널에 대한 복귀 데이터를 제시할 책임을 진다. 카드 보유자 IA는 Chip-UCAF 트랜잭션이 효력을 갖도록 하기 위한 요건의 최소 세트를 갖는다.
본 발명에 의하면, UCAF의 이용이 가능한 취득자는 UCAF를 이용할 수 있는 판매업자와의 관계를 갖는다. 취득자는 이들 판매업자로 하여금 여분의 UCAF 데이터를 취득용 시스템에 전달하도록 하며, 이들 시스템으로 하여금 발급 은행에 대해 제공된 UCAF 데이터의 존재 및 전달을 식별하도록 한다. 발급자 호스트 또는 발급자 호스트로서 체계에 대하여 작용하는 일부 다른 요소는 UCAF 내의 데이터를 포함하여, 인증 네트워크 메시지에서 전달되는 데이터를 취하고, 인증 토큰의 유효 여부를 확인할 책임이 있다.
본 발명에 따라 3-D Secure 프로토콜에 부합하는 UCAF는 적어도 20 바이트 길이의 사용자 인증 토큰을 포함할 수 있다. 이러한 3-D Secure와 호환 가능한 UCAF의 구조에 대해서는 도 10에 도시되어 있다.
도 1 및 도 2는 본 발명의 CAP에 대한 개략적인 구현을 나타낸다. 카드 보유자에 추가하여, 다양한 시스템 성분 또는 관련자가 CAP 구현에 포함된다. 다양 한 시스템 성분은 물리적 또는 논리적 성분이 될 수 있으며, 인증 요청 서버, 카드 보유자의 PC 장치, 보안 코드 인증 애플리케이션(SCAA), 및 접속식 PCR 또는 비접속식 PCR을 포함한다. 이들 시스템 성분은, 예를 들어 유선 또는 무선 네트워크를 이용하여 통상적으로 연결 또는 구성될 수 있다.
인증 요청 서버는 논리적 개체로서, 인증 요청 서비스를 웹 서버 환경 내의 다른 개체/성분에, 그 개체/성분과 독립적으로, 제공하도록 구성될 수 있다. 이러한 인증 요청 서버는 상이한 전자 상거래 환경 및 필요에 용이하게 적응 및 전개시킬 수 있다. 인증 요청 서버가 카드 보유자를 인증하면, 인증 요청 서버는 긍정의 인증 결과 또는 부정의 인증 결과를 요청한 개체/성분에 되돌려줄 수 있다.
카드 보유자의 개인 컴퓨터 장치는 카드 보유자가 인증이 필요한 활동을 수행하는 임의의 컴퓨터 플랫폼 또는 액세스 장치가 될 수 있다. 컴퓨터 플랫폼은 PCR에 접속될 수 있는 PC 플랫폼이 될 수 있다. 또는, 컴퓨터 플랫폼은 예를 들어, PDA 또는 그외 다른 모바일 Wi-Fi 장치를 포함하는 인터넷에의 액세스가 가능한 임의의 장치가 될 수 있다. 카드 보유자에게 스마트 지불 카드(예컨대, ICC) 및 PCR이 지정될 수 있다. CAP의 바람직한 구현에 있어서, 카드 보유자는 자신의 PCR에 개인 식별 번호(PIN)를 입력한 후에 보안 코드가 생성되도록 하고, 인증 요청 서버에 제공하여 유효 여부가 확인된다.
PCR은 보안 코드를 생성하기 위하여 카드 보유자 및 ICC와 상호작용하도록 설계되는, 임의의 적절한 EMV에 부합하는 카드 판독 장치가 될 수 있다. 보안 코드를 생성하기 위하여, 통상적인 암호 기술(예컨대, 암호화 키 기술)이 이용될 수 있다. PCR은 제한적인 카드 보유자 상호작용이 가능하도록 디스플레이 및 키패드를 가질 수 있다. 적절한 PCR은, 예컨대 숫자 키패드와 디스플레이를 구비하는, 저비용의 파지식(휴대형) 스마트 카드 판독기가 될 수 있다. PCR은 카드 보유자의 개인용 컴퓨팅 장치에 물리적으로 접속될 필요가 없는 독립적인 장치가 될 수 있다. 이러한 경우, 카드 보유자는 PCR과 PC 장치 사이에서 모든 데이터를 수동으로 전송하여야 한다.
PCR은 또한 카드 보유자의 PC 장치에 물리적으로 접속 가능한 장치도 가능하다. 이 경우, 카드 보유자는 보안 코드가 카드 보유자의 접속된 컴퓨팅 장치에 대해 PCR에 의해 사용자 인터페이스로 자동으로 전달될 때의 인증 처리를 개시하기 위하여, PCR에 대하여 카드 보유자의 PIN만 입력하면 된다. 접속식 PCR은 PIN 엔트리 처리 동안 PIN의 통상적인 보안 또는 방어를 제공할 수 있다. PCR 상의 디스플레이는 PIN 유효 여부 확인 결과를 나타낼 수 있으며, 접속되지 않은 장치의 경우에는 카드 보유자에 의해 PC 또는 PDA에 입력해야 하는 "보안 코드"를 디스플레이할 수 있다. 접속식 판독기가 접속을 이용할 수 없는 경우에는 비접속식 판독기로서 작용할 수 있다. CAP 구현에 이용되는 PCR은 일반적인 설계가 가능하며, 이에 의하여 다양한 카드 구현을 지원할 수 있다. 카드 보유자에게는, PCR에 챌린지가 입력되었는지 여부가, 인증 요청 서버에 의해(PC 장치 디스플레이 인터페이스를 통해) 표시될 수 있다. 이러한 표시가 이루어지면, PCR은 카드 보유자로 하여금 챌린지를 입력할 수 있도록 하고, 그 챌린지를 보안 코드의 계산에 포함시킬 수 있다.
보안 코드 인증 애플리케이션(SCAA)은 표준 지불 애플리케이션과 함께, 다용도의 신용 카드, 직불 카드, 또는 그외 다른 카드(예컨대, ICC)에 설치될 수 있다. SCAA는 지불 애플리케이션의 별개의 경우가 될 수 있는데, 이 경우 발급자는 지불 및 원격 인증에 대한 별도의 보안 환경을 이용하는 옵션을 갖는다. 이 애플리케이션은 "1회용 패스코드"의 생성과, "트랜잭션 허가의 증명"의 생성을 모두 지원할 수 있다. 카드 발급자는 다른 서비스에 대한 SCAA의 이용을 선택적으로 고를 수 있다. SCAA는 PCR에게 다양한 카드 발급자에 의해 예상되는 보안 코드 포맷의 타입을 지시하는 포맷화 정보 또는 템플릿을 포함할 수 있다. 따라서, 단일의 PCR 설계가 광범위한 카드 타입을 지원하는데 이용될 수 있다.
바람직한 구현에 있어서, 카드 보유자의 개인용 컴퓨팅 장치, ICC, 및 PCR의 하나 이상의 기능은 인터넷에 엑세스하고 인증된 트랜잭션을 수행하도록 고객에 의해 이용될 수 있는 단일의 장치에 통합될 수 있다. 적절한 통합 장치는, 예컨대 ICC와 비접속식 PCR의 기능을 사용자 편의를 추구한 패키지(user-convenient package)에 통합하는, 디스플레이를 구비한 카드가 될 수 있다. 다른 적절한 통합 장치로서, ICC와 비접속식 PCR의 기능을 사용자 편의를 추구한 패키지에 통합하는 전자 열쇠(key fob)가 될 수 있다. PDA 또는 그외 다른 개인용 인터넷 액세스 장치는 카드 보유자에게 할당된 ICC 및 PCR의 기능을 수행하도록 구성될 수 있다. 도 12는 카드(230), 전자 열쇠(240), 및 PDA(250)를 나타내는 개략도이며, 이들 모두는 PCR 및 ICC 기능을 수행할 수 있는 회로를 포함한다. PDA(250)는 추가적으로 인터넷 액세스 장치로서 기능할 수 있다.
도 1은 온라인 인터넷 트랜잭션에 대한 카드 보유자(180)를 인증하는데 이용될 수 있는 예시적인 CAP 인증 처리(100)를 개략적으로 나타내는 도면이다.
온라인 트랜잭션을 시행하기 위하여, 카드 보유자(180)에게 개인용 ICC(170) 및 비접속식 PCR(160)이 발급될 수도 있다. ICC(170) 및 PCR(160)은 함께 통합되어 디스플레이를 갖는 집적 카드(도 12의 카드 230)가 될 수도 있음을 이해할 수 있을 것이다. 프로세스(100)는 외부 엔티티(110)에 의해 인증 요청 서버(120)에 발송된 인증 요청(150)에 응답하여 개시될 수도 있다. 프로세스(100)에서, 인증 요청 서버(120)는 카드 보유자의 PC 장치(140) 상에 디스플레이된 카드 인증 페이지(130)(예컨대, HTML 페이지)의 매체를 통해 카드 보유자(180)와 대화한다. 인증 요청 서버(120)는 HTML 페이지(130)를 생성하여, 이 페이지를 직접 제공할 수도 있다. 이와 달리, 전자 네트워크에 디스플레이되는 특별한 웹 서버 하부 기반구조 또는 기술에 따라서는 HTML 페이지(130)가 인증 요청자(엔티티 110)를 통해 제공될 수도 있다. 인증을 위한 요청(예컨대, 요청 150)은 HTML 질의(query)의 결과가 될 수도 있으며, 이 HTML 질의(query)의 결과는 HTML을 인증 요청 서버(120)에 의해 생성된 응답(예컨대, 결과 150')으로 처리할 수도 있다. 프로세스(100)에서, 인증을 위한 요청(150)은 다음의 정보 또는 데이터를 포함할 수도 있으며, 그렇지 않은 경우에는 다음의 정보 또는 데이터를 제공하도록 요구할 수도 있다:
ㆍ 개인 계좌 번호(PAN) - 인증 처리에서 사용될 카드의 PAN
ㆍ 카드 보유자의 개인 보증 메시지(PAM) - CAP 프로그램에 등록된 카드 보유자는 인증하도록 요청했을 때에 디스플레이될 옵션의 개인 보증 메시지를 제공하 도록 요구될 수도 있다.
ㆍ 트랜잭션 세부사항 - 인증이 요청되고 있는 트랜잭션의 세부사항은 웹 사이트의 판매업자에게 요금을 지불하기 위해서 또는 은행 계좌에 대한 접속을 획득하기 위해서 카드 보유자에게 디스플레이되어야 한다.
도 1에서의 정수 번호의 단계를 참조하여, 프로세스(100)의 단계 1에서, 인증 요청 또는 제어 서버(120)는 카드 보유자에 대한 디스플레이를 위해 카드 보유자 인증 페이지(130)를 생성한다. 카드 보유자 인증 페이지(130)는 카드 보유자의 PC 장치(140) 상에 디스플레이되는 HTML 페이지일 수도 있다. 카드 보유자 인증 페이지(30)는 요청 엔티티(110)에 의해 공급된 트랜잭션의 세부사항을 디스플레이할 수도 있다. 16 자리(digit)의 PAN은 X 표시(즉, "XXXX")의 3개의 그룹과, 이에 후속하는 최종의 4개의 실제 자리로 디스플레이될 수도 있으며, 이 4개의 실제 자리는 카드 보유자(180)로 하여금 인증을 위해 정확한 카드를 인식하거나 사용하는데 도움을 준다. 다음으로, 단계 2에서, 카드 보유자(180)는 원격 지불 또는 식별을 위해 보안 토큰, 즉 보안 코드에 대한 요청을 개시할 것이다. 카드 보유자는 자신의 ICC(170)가 PCR(160)에 의해 판독되도록 촉구될 것이다. 카드 보유자는 상이한 유형의 보안 코드를 요청하는 선택이 제공될 것이다(단계 2a). 상이한 유형의 보안 코드는 예컨대, 원격 지불을 위한 서명 인증 또는 은행 계좌 접속을 위한 식별 인증에 대응할 것이다. 제1 유형의 보안 코드의 경우에는, 카드 보유자(브루스, 알프레드, Pls. confirm)는 옵션으로 웹 페이지 상에 디스플레이된 챌린지를 PCR(160)에 입력하도록 촉구될 수도 있다. 챌린지가 제공되지 않는다면, 카드 보 유자는 PCR(160) 상의 임의의 적합하게 지정된 키 스트로크(예컨대, 진행 버튼)를 작동시킴으로써 처리될 수 있다. 또한, 서명되거나 인증되어야 하는 트랜잭션을 나타내는 인터넷 인증 플래그(IAF)를 갖는 ICC(170) 트랜잭션에 대하여, 트랜잭션 금액이 웹 페이지(130) 상에 디스플레이되어 카드 보유자(180)에게 보여질 수도 있다. 카드 보유자(180)는 내장 리스트로부터 트랜잭션의 통화를 선택하여 웹 페이지 상에 디스플레이된 금액을 입력하도록 촉구될 것이다. 이 입력 후, 카드 보유자는 PCR(160) 상의 적합하게 지정된 키 스트로크를 작동함으로써 다음 단계인 단계 3으로 진행할 것이다.
단계 3에서, 카드 보유자(180)는 카드 보유자 PIN을 입력하도록 촉구될 것이다. PIN이 정확하게 입력되지 않는다면, 카드 보유자는 PIN을 재입력하도록 촉구될 것이다. 카드 보유자(180)는 PIN을 정확하게 입력하기 위한 제한된 시도 횟수만이 허용될 수도 있다. 이 제한된 횟수는 ICC(170) 내의 내부 재시도 카운터에 설정되는 소정의 횟수가 될 수도 있다. 카드 보유자(180)가 허용된 시도 횟수 동안에 정확한 PIN을 입력할 수 없다면, 트랜잭션은 거부된다. 그 후, 카드 보유자(180)는 옵션으로 상이한 또는 대체 지불 수단을 제출하도록 요청될 수도 있다.
정확한 PIN이 입력된 후, 단계 4에서는 PCR(160)이 애플리케이션 암호를 생성하기 위해 카드(170)에 적합화된 EMV 트랜잭션 대화를 시행한다. 이 암호로는 EMV 표준 기술에서의 인증 요청 암호(ARQC)가 가능할 것이다. 일부 예에서, ICC(170)는 ARQC 대신에 애플리케이션 인증 암호(AAC)를 생성하도록 하는 내부 리스크 관리 루틴을 포함할 것이다. 모든 유형의 암호가 PCR(160)에 수용될 수도 있 을 것이다. 단계 5a에서, PCR(160)은 ARQC 또는 AAC를 카드 보유자(180)에 대한 디스플레이를 위한 숫자 보안 코드로 변환한다. 숫자 보안 코드는 예컨대 8 비트 길이로 될 것이다. 단계 5b에서, PCR(160)에 의해 발생된 보안 코드가 판독되어, 카드 보유자의 PC 장치(140) 상의 HTML 페이지(130)의 적합한 엔트리 필드에 카드 보유자(180)에 의해 수동으로 입력될 수도 있다. 단계 6에서, 보안 코드 엔트리를 갖는 HTML 페이지(130)는 카드 보유자(180)에 의해 승인 또는 검증을 위해 인증 요청 서버(120)에 제출될 것이다. 다음으로, 단계 7에서, 인증 요청 서버(120)는 카드 전용의 정적 및 동적 데이터를 복원 또는 갱신하기 위해 카드 보유자 데이터베이스(190)를 액세스할 것이다. 인증 요청 서버(120)에 의해 추적될 수도 있는 카드 전용 동적 데이터는 애플리케이션 트랜잭션 카운터(ATC)를 포함할 수도 있다. 최종적으로 알려진 ATC의 카피가 카드 보유자 데이베이스(190)에 유지되고, 보안 코드에서 리턴된 부분적 ATC(하위 비트)와 조합하여 완전한 ATC가 정확하게 재구성될 수 있다.
단계 8에서, 인증 요청 서버(120)는 ICC에 의한 암호의 생성에 사용된 입력 데이터를 재구성함으로써 보안 코드를 검증할 것이다. 재구성된 입력 데이터는 기지의 정적 데이터, PCR(160)에 의해 ICC(170)에 제출된(단계 4) 임의의 트랜잭션 특정 데이터, 및 카드 데이터베이스(190)로부터 복원된 데이터를 포함할 것이다. 단계 3에서 챌린지가 사용되지 않는 경우에, PCR(160)은 예측 불가능한 숫자를 위해 디폴트 널 값(default null value)을 사용하도록 구성될 것이다. 유사하게, 단계 3에서 금액 또는 통화값이 사용되지 않는다면, PCR(160)은 양측 변수에 대하여 0의 디폴트 값을 사용하도록 구성될 수도 있다. 재구성된 입력 데이터로부터, 애플리케이션 암호(ARQC 또는 AAC)가 재처리되어, 애플리케이션 요청 서버(120)에 의해 단계 6에서 수신된 보안 코드 내의 부분 애플리케이션 암호(AC)와 비교될 것이다. 재처리되어 수신된 AC가 일치한다면, ATC 값이 카드 데이터베이스(190)에서 갱신될 것이다.
프로세스 100의 최종 단계 195에서, 애플리케이션 요청 서버(120)는 인증 테스트의 결과를 요청 엔티티(110)에 제공한다.
도 2는 카드 보유자(180)가 접속식 PCR(160')을 발급받는 예에서 사용될 수 있는 또 다른 예의 인증 프로세스(200)를 개략적으로 도시하고 있다. 프로세스 200은 임의의 챌린지 및 금액/통화 데이터가 HTML 페이지(130) 내의 삽입된 소프트웨어 컴포넌트에 의해 PCR(160')에 직접적으로 또는 자동적으로 통신된다는 점을 제외하고는 프로세스 100과 전반적으로 유사하다. 마찬가지로, 카드 보유자(180)가 검증을 위해 자신의 PIN을 정확하게 입력(단계 3에서)한 후에 보안 코드가 적합한 데이터 필드에 자동적으로 입력될 수도 있다. 프로세스 100과 같이, 프로세스 200은 PCR(160')을 통해 카드 보유자에 대한 서명 또는 식별 조작의 선택을 제공할 수도 있다. 트랜잭션 금액이 카드 보유자에 의해 사인오프(서명 없이 비공식적으로 승인됨)되도록 요구되는 경우에, 프로세스 200은 PIN 엔트리를 인에이블시키기 전에 PCR(160')에 대한 금액을 디스플레이할 수도 있을 것이다. 인증 요청 서버(120)는 PCR(160)(도 1)에 의해 생성된 보안 코드의 처리와 동일한 방식으로 프로세스 200에 의해 생성된 보안 코드를 처리한다.
프로세스 100 및 200 모두에서, EMV 보안 구조는 CAP의 보안을 위한 토대가 된다. 보다 구체적으로, CAP는 1회용 보안 코드의 생성을 위한 카드 및 카드 보유자 존재의 증거(proof)를 형성하기 위해 ICC에 의한 암호, 즉 애플리케이션 암호(AC)의 생성에 의존한다. 카드 보유자에 의한 트랜잭션 승인의 증거는 챌린지의 사용에 기초한다. 트랜잭션 전용의 암호를 사용함으로써 실제 트랜잭션과 사기 트랙잭션의 반복된 제출에 대한 보호가 제공된다.
ICC(예컨대, ICC 170)는 표준 EMV 명령(예컨대, "GENERATE AC"(AC를 생성) 명령)에 응답하여 특정의 트랜잭션을 위한 암호를 생성하도록 프로그래밍된다. "GENERATE AC" 명령에 대하여 ICC(170)에 의해 생성된 응답은 다음의 데이터 엘레멘트, 즉 암호 정보 데이터(CID), 애플리케이션 트랜잭션 카운터(ATC), ICC(AC)에 의해 계산된 암호, 및 발급자 애플리케이션 데이터(IAD)를 포함할 것이다. 이들 데이터 엘레멘트는 특정 트랜잭션 고유의 데이터 및 비고유 데이터를 포함하며, 이들 데이터는 다른 소스로부터 획득될 수 있다. 트랜잭션 고유의 데이터는 추가의 처리를 위해 PCR에서 인터페이스 애플리케이션으로(예컨대, HTML 페이지(130)를 통해 코드 소스로서) 전송된다(암호 형태로). 다른 소스로부터 획득 가능한 데이터는 보안 코드에 포함될 필요가 없다. 이러한 비고유 데이터는, 특정 ICC에 고유한 동시에 발급자 호스트에 의해 알려진(또는 적어도 추론 가능한) 발급자의 소정 카드 체계에 대한 특정의 값을, 그 카드 보유자의 데이터베이스를 통해 갖는 것으로 가정될 수도 있다.
ICC(170)는 ICC의 응답의 어느 부분(즉, 어느 비트)이 인증 데이터 또는 암 호를 생성하기 위해 사용되어야 하는지를 결정하기 위해 PCR에 의해 사용되는 데이터 오브젝트 또는 매스크(예컨대, '0x9F56'의 태그를 갖는 발급자 인터넷 전용 비트맵(IIPB))를 포함할 수도 있다. 사용되는 비트의 수는 발급자에 의해 정의되거나 선택될 수도 있다. 비트의 수는 예컨대 비접속식 PCR(160)에서 PC 장치(140)를 이용하여 카드 보유자에 의해 수동으로 편리하게 전송될 수 있는 인간 공학적으로 고려된 제한된 수의 데이터 비트로 선택될 수도 있다. IIPB는 "IPPB 데이터 토큰"을 구하기 위해 PCR(160 또는 160')에 의해 비트-매스크로서 사용될 수도 있으며, 이 "IIPB 데이터 토큰"은 압축시에 인증 요청자에 전달되는 보안 코드 토큰을 형성한다.
도 9는 일례의 IPPB 구조(900)를 예시한다. IIPB(900)를 구성하는 비트는 GENERATE AC 응답으로부터의 비트가 보안 코드에의 포함을 위해 발급자에 의해 획득된다는 것을 나타내주는 전송 플래그로서 간주될 수도 있다. 이들 플래그는 PCR로부터 발송되어야 하는 비트에 비트 단위로 대응할 것이다(예컨대, CID 1바이트, ATC 2 바이트, AC 8 바이트, 및 IAD 32 바이트). IIPB(900)는 IAD가 정해지지 않는 보편적이지 않은 경우에는 약 11 바이트 길이로 구성될 수도 있다. IIPB(900)는 사용자의 애플리케이션 기술이 발급자 애플리케이션 데이터(IAD)에 이용 가능한 전체 32 바이트를 이용하는 경우에는 43 바이트 길이로 구성될 수도 있다. 그러므로, 데이터 엘레멘트 CID, ATC, AC 및 IAD의 연결에 대한 매스크로서 사용되는 IIPB(900)는 11 바이트와 43 바이트 사이의 길이를 갖는 구조로 될 수 있다. PCR(160 및 160') 모두는 IIPB(900)의 길이가 ICC(170)의 "Generate AC"(AC 생성) 응답으로 리턴된 데이터 항목의 길이와 일치하는지를 판정하기에 적합하게 구성될 수도 있다.
유효 IIPB 길이는 IIPB 데이터 토큰(요구된 비트 전송을 나타내기 위해 1로 설정되는 IIPB 내의 비트의 수에 의해 좌우되는) 내에 전송될 비트의 수, 즉 IIPB에 의해 정해진 바와 같은 비트의 수를 지칭한다. 일례의 CAP 구현에서, 보안 코드는 8-자리 10진수(즉, 67,108,863)로 전송될 수 있는 최대 비트 수인 26 비트를 초과하지 못한다. 유효 IIPB 길이는 따라서 토큰을 위해 8 자리 이상을 요구할 때에도 26비트를 초과할 수 없다.
ICC(170)는 오프라인 PIN 검증의 사용에 의해 카드 보유자 존재의 증거를 형성한다. EMV 표준 규격은 AC의 생성 전에 오프라인 PIN 검증이 수행되도록 요구한다. 그 결과, 유효 AC를 생성하기 위해서는 카드 보유자가 존재하고 있다는 것이 요구되며, 유효 암호가 존재한다는 것은 카드 보유자가 존재한다는 것을 입증하기에 충분하다. AC는 통상적으로 ARQC에 기초하지만, 카드의 내부 리스트 관리 루틴이 지불 트랜잭션을 거절하도록 결정하여야 한다면 AAC에 기초할 수도 있다.
카드 보유자에 의한 트랜잭션의 허용 또는 승인의 증거는 암호 및 보안 코드를 생성하기 위해 인증 요청 서버에 의해 제공된 데이터의 사용에 기초한다. 인증 요청 서버에 의해 제공된 데이터는 카드 보유자에 디스플레이된 트랜잭션 전용 챌린지로서 사용된다. 챌린지는 인증 요청 서버에만 알려진 정보로부터 전개되는 수치값이다. 이 수치값은 발급자가 관련하거나 속하는 것으로 간주할 수도 있는 어떠한 적합한 데이터(예컨대, 트랜잭션 금액 및 통화 코드)에도 기초할 수도 있다. 상이한 챌린지는 상이한 보안 코드를 생성할 것이며, 전용 보안 코드를 작성하기 위해 챌린지가 어떻게 사용될 수 있을지를 알아내는 예측 가능한 방식은 존재하지 않는다. 따라서, 트랜잭션 전용 챌린지를 사용함으로써, 발급자 및 인증 요청 서버에, 디스플레이된 챌린지가 PCR에 의해 생성된 암호에 포함되고 그 암호가 보안 코드에 포함되기 때문에 카드 보유자가 그 특정 트랜잭션을 승인하였다는 증거가, 제공된다.
실제 트랜잭션의 사기 재생 또는 재제출에 대한 보호를 위해, CAP의 구현은 그 특정 ICC를 위해 최종적으로 수신된 ATC에 대해 ICC로부터 수신된 애플리케이션 트랜잭션 센터(ATC)를 검사하도록 구성될 수도 있다. 이전에 수신된 ATC를 이용하는 트랜잭션은 재생이 거부될 것이다. 또한, AC가 ATC를 함수로 하여 변화하도록 ICC에 의해 생성된 AC가 계산될 수도 있다. 이것은 AC 계산을 위해 사용된 입력 데이터의 일부로서 ATC를 포함함으로써 달성될 것이다.
ICC에 의해 생성된 AC의 유일한 발췌 부분은 발급자에게 전송된다. 각각의 암호는 발급자 인터넷 전용 비트맵(IIPB)에 의해 특정된 바대로 발췌된다. 발급자는 예컨대 AC로부터의 16 비트가 PCR에 의해 리턴된 보안 코드에 포함되는 이러한 방식으로 IIPB를 정의할 수도 있다. 발췌된 암호의 감소된 크기 때문에, 발급자는 비정상적인 암호 검증 실패 횟수를 검출하기 위해 사기 검출 시스템을 실시할 수도 있다.
도 3 및 도 4는 각각 챌린지 번호를 생성하는데 수반되고 접속식 및 비접속 PCR에 대한 PIN 검증에 수반되는 일례의 PCR 처리 및 데이터 흐름을 도시하고 있 다. 접속식 PCR 및 비접속식 PCR의 사용에서의 주요 차이점은 사용자 편의성이다. 접속식 PCR의 경우에, PC 장치와 PCR 간의 링크는 이 둘 사이에서 테이터를 운반한다. 비접속 PCR의 경우에, 데이터는 이들 간의 전송을 위해 카드 보유자에 의해 수동으로 복제되어야만 한다. 도 5.3 및 3.4가 ICC에 발송된 정확한 명령 또는 PCR에서의 정확한 처리 단계의 구체적인 예시도는 아님을 이해할 것이다. 도시를 명료하게 하기 위해, 시스템을 예시하는데 도움을 주는 구성요소와, 그 데이터 구조와, 전반적인 처리 원리만이 개략적으로 도시되어 있다.
도 3에 도시된 정수 번호의 단계를 참조하면, 카드 보유자에게 디스플레이되는 PIN 검증에 대한 처리 단계의 시퀀스 및 대응하는 프롬프트가 다음과 같이 이루어질 것이다:
1. 카드 보유자는 자신의 카드를 삽입하도록 요청된다. 카드 보유자는 자신의 발급자 인증 인에이블 카드(ICC)를 개인용 카드 판독기에 삽입한다.
카드 삽입
비접속식 판독기를 이용하면, 카드를 삽입하는 동작은 PCR의 파워를 턴온시킬 수도 있거나, 또는 카드 보유자가 파워를 턴온시키기 위해 버튼을 누를 필요가 있을 것이다.
2. 카드 보유자가 요청된 PCR 기능의 유형을 선택하도록 요청된다.
[S]ign 또는 [I]d
3. 카드 보유자는 PCR 기능에 대한 자신의 선택을 특정 기능 키 또는 메뉴 시스템을 통해 행한다.
4. PCR은 적합한 보안 코드를 생성하는데 사용하기 위해 애플리케이션을 탐색하여 선택하도록 요청된 기능에 적합한 선택 리스트를 사용한다.
5. PCR 판독기는 IIPB 및 IAF를 포함하는 선택된 데이터 엘레멘트를 ICC로부터 판독한다.
카드 보유자가 서명 조작을 선택하였다면:
6. PCR은 챌린지를 입력하도록 카드 보유자에게 촉구한다.
챌린지의 생성은 발급자에 대하여 전용의 것이며, 챌린지는 EMV 트랜잭션 처리에서의 예측 불가능한 숫자(UN)를 위해 사용될 것이다.
챌린지
7. 카드 보유자는 자신의 챌린지를 PCR의 키보드 상에 입력하고, 챌린지 엔트리의 완료를 나타내기 위해 [Proceed] 키를 눌러야 한다.
Figure 112005070647980-PCT00001
인증 요청 서버가 챌린지를 요구하지 않는 곳에서, 카드 보유자는 어떠한 챌린지 자리수를 입력하지 않고서 단지 [Proceed] 버튼을 누를 수도 있을 것이다. PCR은 추후의 "GENERATE AC" 명령에 응답하여 UN에 대하여 널값(0)을 사용할 것이 다.
8. ICC 가 금액 및 통화가 암호에 포함되지 않는 것으로 나타내는 경우, PCR은 카드 보유자에 대한 통화의 표준 리스트를 디스플레이하여 선택하도록 한다:
1. EUR
2. USD
3. GBP
4. 기타
> 1 [Proceed]
9. 카드 보유자는 그 후 금액을 입력하도록 촉구된다.
> ????????.?? EUR
카드 보유자는 금액과 [Proceed]를 입력한다.
금액 및 통화가 암호에 포함되도록 요구하는 발급자는 LAF의 설정치에서의 이러한 요구를 나타낼 것이다. 금액 및 통화는 카드 보유자에 대하여 카드 보유자 인증 페이지 상에 디스플레이된다.
10. PCR은 자신의 PIN을 입력하도록 카드 보유자에 대한 프롬프트를 디스플레이한다.
enter PIN
11. 카드 보유자는 아래의 4-자리 PIN 예로 예시된 바와 같이 자신의 PIN 숫자를 입력하고, PIN 엔트리의 완료를 나타내기 위해 [Proceed] 키를 누른다:
Figure 112005070647980-PCT00002
12. PCR은 PIN을 검증을 위해 ICC에 제출한다.
에러 체크: ICC가 유효하지 않은 PIN 엔트리를 보고한다면, PCR은 남아있는 PIN 시도의 수를 카드 보유자에게 통보한다:
Bad PIN, 2 left
카드 보유자는 그 후 정확한 PIN을 입력하고, [Proceed] 키를 누르며, PCR은 유효한 PIN 엔트리를 보고한다.
Figure 112005070647980-PCT00003
접속식 판독기(도 3.4)를 이용한 PIN 검증 처리 310은 전반적으로 비접속식 판독기(도 5.3)를 이용한 PIN 검증 처리 300과 유사하다. 그러나, PIN 검증 처리310에서, 적합한 APDU 명령의 수신은 PIN 검증 처리 300에서와 같은 카드의 삽입 또는 판독기의 파워온이 아닌 트랜잭션 처리 흐름을 개시할 수도 있다. PIN 검증 처리 310은 또한 임의의 챌린지 데이터를 수신하는 방식에서 PIN 검증 처리 300과 상이할 것이다. 카드 보유자는 트랜잭션을 개시한 APDU에 어떠한 필요한 도전 데이터가 공급될 수 있기 때문에 챌린지를 입력하도록 요구되지 않는다.
양자의 PIN 검증 처리 300 및 310에서, PCR은 동일한 방식으로 보안 코드를 계산할 수도 있다. PIN 검증 처리 310에서, 계산된 보안 코드는 APDU 응답에서 리턴되도록 요구될 수도 있다. 이 조건은 인증 요청 서버가 응답을 처리할 때에 동일한 방식으로 접속식 PCR과 비접속식 PCR을 취급할 수 있도록 하게 한다.
CAP는 ICC 및 카드 보유자를 인증하기 위한 메카니즘으로서 애플리케이션 암호(AC)를 사용한다. EMV 명령인 "GENERATE AC"는 애플리케이션 요청 암호(ARQC)를 생성하도록 ICC를 요청하기 위해 사용된다. 이 명령에서 제공되어야 하는 데이터는 종래에는 CDOLI로서 식별된 EMV 데이터 엘레멘트에 의해 규정된다. 예측 불가능한 숫자(UN)는 "GENERATE AC" 명령에서 ICC에 전달된 데이터의 4-바이트(32-비트) 성분이다. 애플리케이션과는 반대로 ICC에 예측 불가능한 것은 번호(또는 데이터)이다. PCR에 전달된 챌린지는 암호 생성을 위한 예측 불가능한 숫자(UN)로서 사용된다. ICC에 발송될 때에 BCD(Binary Coded Decimal) 형태로 챌린지에 대해 최대 8 자리의 수가 사용될 수도 있다. 8 자리 미만의 어떠한 챌린지는 UN을 작성할 때에 최대 8 자리의 종래의 패딩(pading)의 사용(예컨대, 제로를 앞에 채움으로써)을 수반할 것이다. 도 5는 일례의 8-자리 챌린지를 도시하고 있다.
CAP 구현에서, PCR은 인터페이스 애플리케이션에 리턴되어야 하는 보안 코드 또는 토큰에 도달하기 위해 ICC에서부터 "GENERATE AC" 명령까지의 응답을 처리하도록 구성된다. PCR 내지 "GENERATE AC" 명령의 전체 응답은 너무 방대하여 발급자에게 발송되지 못할 것이다. 따라서, PCR은 IIPB 데이터 토큰을 생성하도록 데이터 추출 및 압축 처리를 수행하기 위해 IIPB를 사용하며, 이 IIPB 데이터 토큰은 PCR에서 인터페이스 애플리케이션으로 전송(암호화 후에)되는 데이터이다. 접속식 PCR은 이 데이터를 직접 인터페이스 애플리케이션에 전송할 수 있는 반면, 비접속식 PCR의 경우에는 카드 보유자가 이 데이터를 수동으로 전송하여야 한다.
IIPB에서의 비트를 '1'로 설정하는 것(예컨대, 도 9를 참조)은 응답 데이터 내의 해당 비트 위치가 '요구되어' 발송될 필요가 있다는 것을 나타낸다.
비트를 '0'으로 설정하는 것은 비트 설정치가 어떻게 되어야 하는지를 발급자가 알고 있거나 또는 유추할 수 있고, 그러므로 비트가 보안 코드의 일부로서 발송될 필요가 없다는 것을 나타낸다.
IIPB 데이터 토큰은 추출될 첫 번째 비트가 출력 데이터의 최종 바이트의 비트 1에 위치되고, 두 번째 비트가 비트 2에 위치되는 등의 방식으로 우측에서 좌측으로 채워진다. 전송할 더 이상의 비트가 없을 때까지 이러한 방식으로 채워지는 일례의 IIPB 데이터 토큰(3700)이 도 7에 도시되어 있다.
PCR에서 인터페이스 애플리케이션으로 전송되는 데이터(즉, 일례의 IIPB 데이터 토큰)가 제일 먼저 보안 코드로서 암호화된다. CAP 구현에서, PCR은 전송될 데이터의 비트 패턴을 나타내는 번호를 계산하기에 적합한 알고리즘으로 구성된다. 비접속식 판독기는 카드 보유자가 카드 보유자 인증 페이지에 의해 디스플레이된 적합한 필드에 이 번호를 입력할 수 있도록 이 번호, 즉 보안 코드를 디스플레이할 것이다.
요구된 비트를 디스플레이된 숫자로 변환하기 위해 사용된 PCR 암호화 알고리즘은 인증 요청 서버상에서 상호 사용 가능하고 가역 가능한 것이 바람직하다. 비트를 토큰으로 변화하기 위해 사용되는 동일한 알고리즘은 토큰을 비트로 변환하도록 반대로 될 수도 있다. 적합한 "압축" 기술은 비트 패턴을 이진수로 처리하는 과정과 도 6에 도시된 바와 같이 Base-2 에서 Base-10으로의 수학적인 변환을 수행하는 과정을 수반한다.
CAP의 구현은 판매업자, 획득자, 발급자 및 카드 보유자를 포함하는 트랜잭션 체인에서의 모든 관련자에 대한 서로 일치하거나 호환 가능한 3-D 보안 플랫폼, 시스템 및 방법이 되도록 설계된다. CAP는 발급자-정의 칩 인증 데이터의 사용을 표준화하는 장점을 갖는다. CAP 구현은 광범위한 카드 보유자 인증 체계 및 트랜잭션 채널을 지원하도록 신규의 그리고 기존의 3-D 보안 플랫폼, 시스템 및 방법에 표준 메시지 하부 기반구조를 활용할 수도 있다는 장점이 있다.
CAP 칩-인증 트랜잭션의 수명주기 동안에 이하의 물리적 또는 논리적 3-D 체계 엔티티가 수반될 수도 있다.
ㆍ 카드 보유자 - 카드 보유자는 트랜잭션을 개시하고, 데이터를 판매업자의 지불 웹 페이지, 개인용 카드 판독기 및 카드 보유자 인증 페이지에 입력할 책임이 있다. 카드 보유자는 PCR이 보안 코드 인증 애플리케이션(SCAA)을 이용하여 보안 코드를 생성하도록 하기 위해 자신의 PIN을 PCR에 입력하여야 한다.
ㆍ 판매업자 - 판매업자는 인증 트랜잭션을 개시하기 위해 필요 데이터를 공급하고, 그 결과의 인증 데이터를 수신하여 자신의 획득자를 경유하여 검증을 위해 발급자에게 포워딩한다. 판매업자는 정상적인 3-D 보안 처리를 작동한다.
ㆍ 카드 보유자 인증 페이지 - 카드 보유자 인증 페이지는 ACS의 웹 페이지 존재이다. 이 페이지는 ACS에 의해 제공된 관련 데이터 및 명령을 디스플레이하고, 카드 보유자와 대화한다. 카드 보유자 인증 페이지는 ACS에 의해 카드 보유자에게 리턴되며, 인터넷 브라우저의 일부(즉, "팝업" 윈도우)로서 실행된다. 이 페이지는, 3-D 보안의 마스터카드의 구현을 위한 표준 디스플레이 정보에 추가하여, 발급자에 의해 요구된 경우에 챌린지를 포함할 수도 있다.
ㆍ 개인용 카드 판독기 - 개인용 카드 판독기는 ACS를 통해 발급자에게 간접적으로 전달되는 보안 코드를 발생하기 위해 카드 보유자 및 ICC와 대화한다. 판독기의 유형 및 트랜잭션의 유형에 따라, 카드 보유자는 요구된 PIN을 입력하기 전에 발급자 생성 인증 팝업 윈도우 상에 디스플레이된 챌린지 및 가능하게는 금액/통화를 입력할 필요가 있을 것이다. 카드 보유자는 카드 보유자 인증 페이지 웹 페이지 상에 보안 코드(비접속식 PCR에 디스플레이된)를 입력하여야 한다(접속식 판독기에서는 PIN 엔트리 및 가능한 금액/통화 확인응답 이외에는 데이터 엔트리가 필요하지 않다).
ㆍ ICC - EMV에 부합하는 스마트 카드는 PIN 검증을 통해 카드 보유자를 인증하고, 개인용 카드 판독기에 의해 공급된 데이터에 기초하여 적합한 암호를 생성한다.
ㆍ 획득자 - 획득자는 판매업자로부터 트랜잭션 데이터를 수용하고, 이 데이터를 적합한 네트워크를 통해 발급자에게 포워딩한다. 획득자는 발급자로부터의 인증을 획득하기 위해 표준 또는 상호 협의된 프로세스를 따를 수도 있다.
ㆍ 발급자 - 발급자는 3D 보안을 위해 마스터카드 칩 인증 프로그램에 대해 서명한 카드 보유자에게 개인용 카드 판독기를 배포한다. 특히, 발급자는 그 발급자의 규칙에 따라 DCAF 필드에 전송된 인증 데이터(AAV)를, 획득자로부터의 인증 요청 내에서, 옵션으로 검증할 수도 있다.
ㆍ 액세스 제어 서버 - 발급자는 카드 보유자 인증 페이지를 제공하고 PCR로부터의 보안 코드를 수신하는(카드 보유자로부터 직접적으로 또는 간접적으로) 추가의 성능으로 3-D 보안에 대해 특정된 대로 액세스 제어 서버를 작동한다. ACS는 이하의 기능을 수행하는 인증 요청 서비스를 사용함으로써 보안 코드의 유효성을 검증한다:
- 칩(암호의 유형에 대한 표시자 및 ATC)에만 알려져 있는 데이터를 보안 코드로부터 추출
- 암호를 재생성
- 그 결과를 보안 코드 내의 부분 암호화 비교
ㆍ 등록 서버 - 등록 서버 및 등록 프로세스는 정상적인 3-D 보안 프로세스와 동일하다. PAN이 스마트 카드를 참조하고 칩이 정적 패스워드 대신에 보안 코드를 생성하기 위해 사용될 것이라는 것을 나타내기 위해 카드 보유자에 대한 조건이 존재할 수도 있다. 이것은 카드 보유자 결정 또는 발급자 결정이 되거나, 또는 구성 옵션이 될 수도 있다. 발급자는 보안 코드의 포맷과, 챌린지가 PCR 내의 카드 보유자 엔트리에 대하여 디스플레이되는지의 여부를 나타내 주어야만 한다. 이상적으로는, 이러한 결정의 대부분은 발급자가 선택할 수 있는 구성 옵션이 될 것이다.
ㆍ 디렉토리 서버 - 디렉토리 서버는 정상적인 3-D 보안 코드로 작동한다.
도 8은 예컨대 3-D 보안 버젼 1.0.2 환경일 수도 있는 3-D Secure™ 환경에서 일례의 CAP(칩-인증된) 트랜잭션에 수반된 단계 및 엔티티 간의 메시지 흐름(500)의 일부를 도시하고 있다. CAP는 카드/카드 보유자와 발급자의 액세스 제어 서버(ACS)(510) 간의 인증 메카니즘을 제공한다. 도시된 일례의 메시지 흐름은 트랜잭션을 수행하기 전에 카드 보유자(580)가 서비스를 위해 발급자에 등록되고, 스마트 카드 및 호환 가능한 PCR을 갖는 것으로 가정한다. 또한, 구입을 하고자 하는 카드 보유자(580)는 요구된 상품 또는 서비스를 선택하고, 판매업자의 웹 사이트 상의 "체크아웃" 프로세스를 개시한다. 판매업체는 카드 보유자(580)에게 카드 보유자의 지불 카드에 대한 세부사항을 제공하도록 이미 요청하였으며, 그 세부사항은 보호된 방식으로 판매업자의 웹 사이트 상에 카드 보유자(580)에 의해 입력되어 있다. CAP 기반 인증은 단계 8, 즉 보안 코드의 생성 및 입력에만 영향을 준다.
표준 3-D 보안 버젼 1.0.2 메시지 포맷 및 데이터 포맷은 메시지 흐름(500)의 전부에 대하여 사용될 수 있다. 특히, ACS(510)이 UCAF 내에 최대한 포함하기 위해 생성하여 판매업자에게 리턴하는 CAVV는 28개의 문자 길이를 가지며, 베이스 24 인코딩에서의 3-D 보안을 위해 정의된 20-바이트를 포함한다(예컨대, 도 10을 참조). CAP 인증 애플리케이션의 사용(SCAA)은 "인증 모드" 필드(값 '2')에 나타내질 수도 있다. AAV에 대한 동일한 포맷이 동적 보안 코드 CAP 조작에 그리고 통상의 3-D 보안 정적 패스워드 모드의 동작에 대하여 사용될 것이다.
도 8을 참조하면, 정수 번호의 단계 또는 메시지 흐름(500)은 다음과 같다:
1. 지불 세부사항 : 카드 보유자 - 판매업자(HTTP/POSTed Form)
항목을 검색하여 선택한 카드 보유자는 이 기술내용에서 특히 관심이 되는 판매업자에게 제공되는 지불 카드 세부 사항, 즉 엠보싱된 카드 번호(PAN)를 포함하는 공급 개인 세부사항을 '체크 아웃'한다.
2. VEReq(등록 요청을 검증) : 판매업자 - 디렉토리 서버(DS)(HTTPS/POST)
판매업자의 3-D 보안 처리 소프트웨어는 VEReq를 적합한 브랜드 디렉토리 서버에 발송하여 PAN이 발급자의 3-D 보안 프로그램에 등록되는지를 판정한다.
판매업자는 모든 지불을 위해 디렉토리 서버를 조사하는 것을 방지하기 위해 디렉토리 서버의 로컬 캐시를 매일 마다 유지하도록 권장될 것이다. 캐시는 프로그램에 참여하는 모든 적당한 브랜드 카드 범위를 포함할 것이다. 캐시 옵션을 사용함으로써 카드 보유자 PAN이 프로그램에 참여하기에 적당하지 않을 때에 이들 경우에 대하여 디렉토리를 호출하는 것이 방지될 것이다.
3. VEReq : 디렉토리 서버 - 액세스 제어 서버(ACS)(HTTPS/POST)
카드 범위에 기초하여, 디렉토리 서버는 VEReq를 적합한 ACS에 전달한다. ACS는 카드(카드 보유자 PAN)가 3-D 보안에 등록되는지의 여부를 판정한다.
4. VERes(등록 응답을 검증) : ACS - DS(HTTPS/POST에 대한 응답)
ACS는 특정 PAN이 시스템에 등록되는지의 여부에 대한 표식을 리턴하며, 등록되었다면, 인증을 수행하기 위해 카드 보유자의 브라우저를 수정하기 위해 사용될 URL이 ACS를 향하게 된다.
ACS는 해당 지불 카드를 식별하기 위해 PAReq로 카드 보유자에 의해 접촉될 때에 ACS에 의해 사용되는 고유의 계좌 식별자를 리턴하며, 이 계좌 식별자는 반드시 PAN이 아니어야 한다. 이 계좌 식별자는 키가 정확히 생성되어 보안 코드가 검증될 수 있도록 하기 위해 일대일로 사용된 실제 카드의 PAN과 부합하여야 한다.
5. VERes : DS - 판매업자(HTTPS/POST에 대한 응답)
DS는 그 응답을 판매업자에게 리턴한다.
6. PAReq(지불자 인증 요청) : 판매업자 - 카드 보유자(HTML 페이지)
판매업자의 3-D 보안 처리 소프트웨어가 PAReq를 구성하고, Base64가 PAReq를 인코드하여 HTML 폼 필드(PaReq)에 위치시킨다. 인증 후에 카드 보유자의 브라우저가 수정되어야만 하는 판매업자 URL이 HTML 폼 필드(TermUrl)에 위치되며, TermUrl을 통해 접촉할 때에 카드 보유자가 요구할 수도 있는 어떠한 판매업자 상태 데이터 또한 HTML 폼 필드(MD)에 위치된다. HTML 페이지는 그 후 카드 보유자의 지불 세부사항의 포스팅에 대한 응답으로서 카드 보유자에게 리턴된다. 이 폼을 위한 POST 어드레스는 VERes 마다의 ACS의 URL이다.
7. PAReq : 카드 보유자 - ACS(HIT/POST)
통상적으로 판매업자에 의해 리턴된 페이지는 추가의 소형 "팝업" 윈도우를 오픈할 수도 있으며, 이 팝업 윈도우는 판매업자에 의해 채워진 폼 데이터를 ACS에게 포스팅한다.
ACS는 카드 보유자 세부사항을 탐색하고, 이 특정 지불 카드에 대해 사용할 인증 메카니즘과, 칩 인증의 경우에는 인증을 위해 요구된 챌린지의 유형을 결정한 다.
8. 카드 보유자 인증 : ACS - 카드 보유자 - ACS(HTTPS/POST에 의해 후속된 HTML 페이지)
단계 8은 특정 발급자 및/또는 카드 보유자에 적합한 방식으로 시행될 것이다. CAP 구현에서, 인증 처리는 도 1 및 도 2와 부록 A를 참조하여 설명된 바와 같은 인증 요청 서버를 이용하여 실행될 것이다. ACS(510)는 하나 이상의 카드 보유자 인증 유형을 지원할 수도 있지만, 카드당 오직 하나의 방법이 허용될 것이다. ACS(510)는 카드/카드 보유자에 대하여 저장된 정보로부터 카드에 대하여 허용되는 방법을 결정할 수도 있다. ACS는 카드 보유자와의 인터페이스를 제어하며, 카드 보유자의 PCR의 사용을 감독한다. ACS 내의 구성 파라미터에 기초하여, 발급자는 "1회용 패스코드" 보안 코드를 구현할 수도 있고, "트랜잭션 수용" 보안 코드를 구현할 수도 있다. 이들 간의 차이점은 카드 보유자가 전용 트랜잭션을 수용하기 위해 카드 보유자의 PIN을 입력하기 전에 비접속식 PCR 상에 챌린지를 입력하여야 한다는 점이다. 이 단계는 1회용 패스코드를 사용하면 요구되지 않는다.
9. CAVY를 생성 : ACS
채용된 인증 메카니즘을 통한 성공적인 검증시, ACS는 구현된 3D 보안 아키텍쳐를 따라는 보안 지불 애플리케이션(SPA) AAV를 구성한다. 이 값은 판매업자에게의 리턴을 위해 PARes의 CAVV 서브필드에 위치될 것이다.
10. PARes(지불자 인증 요청) : ACS - 카드 보유자(HTML 페이지)
ACS는 AAV 및 메시지 서명을 포함한 PARes를 구성하며, Base64는 이것을 인 코딩하여 HTML 폼 필드(PaRes)에 위치시킨다. PAReq에 수신된 판매업자 데이터 또한 HTML 폼 필드(MD) 내의 판매업자에게 리턴된다. 이 페이지의 폼에 대한 POST 어드레스는 PAReq의 TermUrl 필드 마다의 판매업자의 URL이다.
11. PARes : 카드 보유자 - 판매업자(HTTPS/POST)
ACS에 의해 리턴된 페이지는 그 후 ACS에 의해 채워된 폼 데이터를 판매업자에게 포스팅하며, 여기서 판매업자의 3-D 보안 처리 소프트웨어는 ACS에 의해 생성된 메시지 서명을 검증할 것이다.
12. 인증 요청 : 판매업자 - 획득자(전용 커뮤니케이션)
판매업자는 자신의 획득자에 발송된 인증 요청에서 PARes에 수신된 AAV를, 표준 인증 요청 데이터와 함께 포함한다.
13. MT0100/0200 : 획득자 - 발급자(BankNet)
획득자는 인증 데이터를 추출하고, 이 인증 데이터를 인증 메시지 내의 UCAF 필드에 삽입하여 적합한 마스터카드 인증 네트워크에 발송한다.
14. SPA AAV를 검증 : 발급자
발급자는 소정 카드로 카드 보유자 인증이 발생하도록 보장하기 위해 인증 메시지의 UCAF 필드에 포함된 AAV 값을 검증할 것이다.
15. MT0110/0210 : 발급자 - 획득자(BankNet)
표준 인증 처리가 수행되며, 응답이 획득자에게 리턴된다.
16. 인증 응답 : 획득자 - 판매업자(전용)
판매업자는 자신의 획득자로부터 인증 응답을 수신한다.
17. 응답/수용 : 판매업자 - 카드 보유자(HTML)
판매업자는 카드 보유자의 지불이 수용되었는지의 여부에 관해 카드 보유자에 대한 표식을 리턴한다.
도 11은 CAP 구현을 이용하여 3-D 보안 환경에서의 고객의 온라인 구입에 수반될 수 있는 처리 단계의 일례의 시퀀스를 나타낸다. CAP 구현은 트랜잭션이 판매업자 및/또는 등록된 카드 보유자에 의해 요청된 카드 보유자 인증 서비스의 유무에 상관없이 시행될 수 있도록 기존의 전자 상거래 시스템에 부가되도록 설계될 것이다.
단계 2200에서, 고객은 예컨대 판매업자 웹 페이지 상의 구입 항목을 쇼핑하여 선택한다. 고객은 예컨대 이러한 용도를 위해 집적된 PDA(250)(도 12)를 이용할 것이다. 단계 2210에서, 판매업자는 고객이 고객에게 지불 정보를 촉구하며, 그 고객은 이에 대한 응답으로 카드 번호를 입력할 것이다. 단계 2230에서, 판매업자는 확인 요청을 디스플레이하고, 고객에게 제출 버튼을 클릭하도록 요구할 것이다. 단계 223에서, MPI는 카드 번호가 현금 카드 한도에 있는 것인지를 체크할 것이다. 단계 223에서 카드 번호가 현금 카드 한도 내에 있지 않다면, MPI는 카드 보유자가 CAP 프로그램에 등록되었는지를 확인하기 위해 VEReq를 생성하고, 그리고나서 검증을 대기할 것이다. 단계 224에서, 소정의 대기 시간 이내에 긍정의 검증 결과가 수신되지 않으면, MPI는 단계 2270으로 진행하여 승인되지 않은 인증 요청을 제출할 것이다. 또한, 단계 224에서, 소정의 대기 시간 이내에 긍정의 검증 결과가 수신되면, MPI는 단계 2250으로 진행하여 카드 보유자 인증을 요청하는 메시 지를 생성하여 발급자에게 발송한다.
단계 225에서, 이 요청에 대한 긍정의 응답이 소정 타임아웃 기간 내에 수신되지 않는다면, MPI는 단계 2270으로 진행하여 승인되지 않은 인증 요청을 제출할 것이다. 또한, 단계 225에서 이 요청에 대한 긍정의 응답이 타임아웃 기간 내에 수신된다면, 본 프로세스는 단계 226과 단계 227로 진행하여 각각 서명 검증이 획득되었는지의 여부와 카드 보유자 인증 처리가 성공적으로 완료(ACS에 의해)되었는지의 여부를 확인할 것이다. 이들 단계 중의 어느 하나라도 성공적이지 못하다면, MPI는 판매업자가 카드 보유자에게 지불 정보를 촉구하는 단계 2210으로 돌아갈 것이다. 이들 단계 모두가 성공적인 카드 보유자 인증 처리를 나타내면, 단계 228에서 MPI는 부정 또는 긍정일 수도 있고 다양한 사유 코드(reason code)를 갖는 인증 결과를 수신한다.
단계 228에서, MPI는 인증 결과를 문의하고, 그에 따라 UCAF 전송 필드 내의 UCAF 데이터를 이용하여 승인된 인증 요청을 제출하도록(단계 2260) 진행하거나, 또는 승인되지 않은 인증 요청을 제출하도록 단계 2270으로 진행할 것이다. 단계 228에서, MPI는 또한 그와 달리 단계 229로 진행하여 수신된 인증 결과 내의 사유 코드를 문의할 수도 있다. 사유에 대한 문의의 결과에 따라, MPI는 지불 정보에 대해 재촉구할 고객을 선별하거나(단계 2210), 또는 단계 2270으로 진행하여 승인되지 않은 인증 요청을 제출하도록 할 것이다. MPI는, 단계 2270 또는 단계 2260에서의 승인되지 않은 인증 요청 및 승인된 인증 요청을 각각 제출한 후에, 고객에 수용 페이지를 디스플레이하도록 진행할 것이다(단계 2280).
본 발명을 특정한 예의 실시예를 참조하여 설명하였지만, 본 발명의 기술적 사상으로부터 벗어남이 없이 예시된 실시예에 대한 다양한 변경, 대체 및 수정이 당업자에 의해 가능할 것이라는 점을 주지하기 바란다.

Claims (30)

  1. 전자 네트워크상에서 고객의 트랜잭션을 인증하는 시스템으로서,
    고객이 상기 전자 네트워크에 접근할 수 있도록 하는 액세스 장치;
    상기 고객에게 발급되며, 고객 식별용 데이터를 포함하고 있는 집적 회로 칩;
    상기 액세스 장치와 연결가능하며 상기 칩과 통신가능한 판독기; 및
    액세스 제어 서버(ACS)와 접속하여 상기 전자 네트워크에 연결되며, 상기 트랜잭션의 인증을 요청하는 당사자와 통신가능한 인증 요청 서버(ARS)
    를 포함하며,
    상기 ARS는, 상기 인증 요청 당사자로부터 상기 고객측의 액세스 장치로 인증 소프트웨어를 다운로드할 필요 없이, 상기 트랜잭션의 인증을 위한 상기 고객측 액세스 장치와 직접 통신하며,
    상기 ARS는, 상기 인증을 요청하는 당사자로부터 트랜잭션 정보를 수신하고, 상기 고객측의 액세스 장치를 통해 상기 판독기와 트랜잭션 데이터를 주고 받으며,
    상기 판독기는, 상기 트랜잭션 데이터를 수신하고, 상기 트랜잭션 데이터에 기초한 값을 상기 집적 회로 칩과 주고 받으며,
    상기 집적 회로 칩은 상기 트랜잭션 데이터의 적어도 일부와 상기 집적 회로 칩상의 상기 고객 식별용 데이터의 적어도 일부에 기초하여 암호를 생성하며,
    상기 판독기는 상기 ARS에 대한 암호에 기초하여 인증 토큰을 주고 받으며,
    상기 ARS는 상기 인증 토큰으로부터 상기 고객을 식별하기 위한 데이터를 평가하고, 상기 고객의 트랜잭션의 인증을 위한 인증 토큰의 유효 여부를 확인하도록 구성된 것을 특징으로 하는 인증 시스템.
  2. 제1항에 있어서,
    상기 판독기와 주고 받는 상기 트랜잭션 데이터는 상기 트랜잭션 정보에 기초한 챌린지를 포함하는 것을 특징으로 하는 인증 시스템.
  3. 제1항에 있어서,
    상기 인증 토큰은 3-D Secure 프로토콜 메시지 포맷과 호환 가능한 포맷을 갖는 것을 특징으로 하는 인증 시스템.
  4. 제1항에 있어서,
    상기 인증 토큰이, 상기 ARS에 의해 성공적으로 평가되면, ACS에 의해, 20 바이트 길이를 갖는 범용 카드 보유자 인증 필드(UCAF) 내에 담겨 전자 네트워크상에서 전송되는 계좌 보유자 인증 값(AAV)이 생성되는 것을 특징으로 하는 인증 시스템.
  5. 제1항에 있어서,
    상기 집적 회로 칩과 상기 판독기는 단일의 물리적인 패키지에 함께 설치되 는 것을 특징으로 하는 인증 시스템.
  6. 제1항에 있어서,
    상기 액세스 장치, 상기 집적 회로 칩, 및 상기 판독기는 단일의 물리적인 패키지에 함께 설치되는 것을 특징으로 하는 인증 시스템.
  7. 제1항에 있어서,
    상기 ARS는 상기 집적 회로 칩에 의해 이용되는 데이터를 재구축하고, 상기 재구축된 데이터로부터 복제 암호문을 생성하며, 상기 인증 토큰을 상기 복제 암호문과 매칭시킴으로써, 상기 인증 토큰으로부터 고객을 식별하기 위한 데이터를 평가하는 것을 특징으로 하는 인증 시스템.
  8. 제1항에 있어서,
    저장된 고객 정보를 검색하기 위하여, 상기 ARS에 의해 접근 가능한 카드 보유자 데이터베이스를 추가로 포함하는 것을 특징으로 하는 인증 시스템.
  9. 제1항에 있어서,
    상기 ARS는 상기 인증 요청 개체에 인증 결과를 송신하는 것을 특징으로 하는 인증 시스템.
  10. 제1항에 있어서,
    상기 ARS는 상기 집적 회로 칩으로부터 수신된 애플리케이션 트랜잭션 카운터의 이전 값에 대하여 상기 집적 회로 칩으로부터 수신한 상기 애플리케이션 카운터를 매칭시킴으로써, 상기 트랜잭션을 인증하는 것을 특징으로 하는 인증 시스템.
  11. 3-D Secure에 부합하는 전자 네트워크 환경에서 고객의 트랜잭션을 인증하는 시스템으로서,
    판매업자;
    발급자;
    상기 판매업자로부터 트랜잭션 특정의 데이터를 받아들이고, 이 데이터를 상기 발급자에게 전달하는 취득자;
    액세스 제어 서버(ACS)와 관련하여 상기 발급자에 의해 조작되는 인증 요청 서버(ARS);
    상기 ACS와 고객 사이에 인터페이스를 제공하는 카드 보유자 인증 페이지;
    상기 발급자에 의해 상기 고객에게 발급되며 고객 식별 데이터를 갖는 EMV 규격에 부합하는 집적 회로 칩 카드; 및
    상기 집적 회로 칩과 통신가능하고, 상기 카드 보유자 인증 페이지에 연결될 수 있는 판독기
    를 포함하며,
    상기 집적 회로 칩 카드와 상기 판독기는, 상기 고객 식별 데이터의 적어도 일부와 상기 카드 보유자 인증 페이지를 통해 상기 판독기에 의해 수신되는 상기 트랜잭션 특정 데이터의 적어도 일부의 암호문에 기초하여 인증 토큰을 생성하며,
    상기 ARS는 상기 인증 토큰을 평가하여 유효 여부를 확인하고,
    상기 인증 토큰의 유효 여부 확인에 의해, 20 바이트의 길이를 갖는 범용 카드 보유자 인증 필드(UCAF) 내의 전자 네트워크상에서 전송되는 AAV가 생성되는 것을 특징으로 하는 인증 시스템.
  12. 제11항에 있어서,
    상기 집적 회로 칩과 상기 판독기는 단일의 물리적인 패키지에 함께 설치되는 것을 특징으로 하는 인증 시스템.
  13. 제11항에 있어서,
    상기 카드 보유자 인증 페이지, 상기 집적 회로 칩, 및 상기 판독기는 단일의 물리적인 패키지에 함께 설치되는 것을 특징으로 하는 인증 시스템.
  14. 제11항에 있어서,
    집적 회로 칩 카드는 상기 판독기에 의해 발급되는 EMV 표준 커맨드에 따라 암호문을 생성하는 것을 특징으로 하는 인증 시스템.
  15. 제11항에 있어서,
    상기 집적 회로 칩 카드는 상기 판독기에 의해 상기 인증 토큰에 포함되는 상기 암호문의 특정 비트를 식별하기 위하여 상기 발급자에 의해 선택되는 비트맵 마스크를 포함하는 것을 특징으로 하는 인증 시스템.
  16. 제11항에 있어서,
    상기 집적 회로 칩(ICC)은, 상기 고객에 의해 개인용 식별 코드 엔트리의 검증을 수행한 후에, 상기 판독기에 의해 상기 인증 토큰을 생성하도록 프로그램된 것을 특징으로 하는 인증 시스템.
  17. 제11항에 있어서,
    상기 집적 회로 칩(ICC)은, 상기 고객이 트랜잭션 금액을 확인한 후에, 상기 판독기에 의해 상기 인증 토큰을 생성하도록 프로그램된 것을 특징으로 하는 인증 시스템.
  18. 제11항에 있어서,
    상기 ACS는 상기 카드 인증 페이지를, 데이터 및 명령의 통신을 위한 팝업 또는 인라인 웹 페이지로서 상기 카드 보유자에게 표시하는 것을 특징으로 하는 인증 시스템.
  19. 제11항에 있어서,
    상기 발급자는 상기 ARS를 이용함으로써 상기 인증 토큰의 유효 여부를 확인하는 것을 특징으로 하는 인증 시스템.
  20. 제11항에 있어서,
    상기 ARS는 상기 인증 토큰으로부터 상기 집적 회로 칩에만 기억시킨 데이터를 추출하고, 암호문을 재생성하며, 상기 재생성된 암호문을 상기 인증 토큰과 비교하는 것을 특징으로 하는 인증 시스템.
  21. 제11항에 있어서,
    인증된 트랜잭션 인증 요청 및 인증되지 않은 트랜잭션 인증 요청 모두를 상기 발급자에게 제공하기 위한 장치를 추가로 포함하는 것을 특징으로 하는 인증 시스템.
  22. 네트워크 액세스 장치를 이용하여 전자 트랜잭션에 참가하는 고객의 원격 인증을 수행하는 방법으로서,
    상기 고객에게 고객 식별용 데이터를 갖는 집적 회로 칩을 제공하는 단계;
    고객측의 상기 네트워크 액세스 장치에 연결가능하고 상기 집적 회로 칩과 통신가능한 판독기를 제공하는 단계;
    상기 전자 네트워크에 연결가능하고, 데이터를 상기 판독기에 전송할 수 있으며, 트랜잭션 특정 정보를 수신하고, 트랜잭션 특정 데이터를 상기 판독기에 전 송할 수 있는 인증 요청 서버(ARS)를 이용하는 단계;
    상기 판독기를 이용하여, 상기 트랜잭션 특정 데이터를 상기 집적 회로 칩에 전송하며, 상기 집적 회로 칩이 상기 트랜잭션 특정 데이터의 적어도 일부와 상기 고객 식별용 데이터의 적어도 일부에 기초하여 암호문을 생성하도록 지시하는 단계;
    상기 판독기를 이용하여, 상기 집적 회로 칩에 의해 생성된 상기 암호문의 적어도 일부에 기초하여 인증 토큰을 생성하는 단계;
    상기 ARS를 이용하여 상기 인증 토큰의 유효 여부를 확인하는 단계; 및
    상기 인증 토큰의 유효 여부의 확인에 의해 AAV를 생성하고, 범용 카드 보유자 인증 필드(UCAF) 내의 전자 네트워크를 통해 상기 AAV를 상기 발급자에게 전송하는 단계
    를 포함하는 것을 특징으로 하는 인증 방법.
  23. 제22항에 있어서,
    상기 판독기에 전송되는 상기 트랜잭션 특정 데이터는 상기 트랜잭션 특정 정보에 기초하는 챌린지를 포함하는 것을 특징으로 하는 인증 방법.
  24. 제22항에 있어서,
    상기 판독기를 이용하여 인증 토큰을 생성하는 단계는, 3-D Secure 프로토콜 메시지 포맷과 호환가능한 포맷으로 인증 토큰을 생성하는 단계를 포함하는 것을 특징으로 하는 인증 방법.
  25. 제22항에 있어서,
    상기 AAV는 20 바이트 길이를 갖는 범용 카드 보유자 인증 필드(UCAF) 내에 담겨 전자 네트워크상에서 전송되는 것을 특징으로 하는 인증 방법.
  26. 제22항에 있어서,
    상기 고객에게 집적 회로 칩을 제공하는 단계와 상기 판독기를 제공하는 단계는, 단일의 물리적인 패키지에 함께 설치되는 집적 회로 칩 및 판독기를 제공하는 단계를 포함하는 것을 특징으로 하는 인증 방법.
  27. 제22항에 있어서,
    상기 ARS를 이용하여 상기 인증 토큰의 유효 여부를 확인하는 단계는, 상기 암호문을 생성하기 위하여 상기 집적 회로 칩에 의해 이용되는 데이터를 재구축하고, 상기 재구축된 데이터로부터 복제 암호문을 생성하며, 상기 인증 토큰을 상기 복제 암호문과 매칭시킴으로써, 상기 인증 토큰 내의 고객 식별용 데이터를 평가하는 단계를 포함하는 것을 특징으로 하는 인증 방법.
  28. 제27항에 있어서,
    저장된 고객 정보를 검색하기 위하여, 상기 ARS에 의해 접근 가능한 카드 보 유자 데이터베이스를 액세스하는 단계를 추가로 포함하는 것을 특징으로 하는 인증 방법.
  29. 제27항에 있어서,
    상기 인증 토큰의 유효 여부를 확인한 결과를, 인증을 요청하는 당사자에게 전송하는 단계를 추가로 포함하는 것을 특징으로 하는 인증 방법.
  30. 제27항에 있어서,
    상기 ARS를 이용하여 상기 인증 토큰의 유효 여부를 확인하는 단계는, 상기 집적 회로 칩으로부터 수신된 애플리케이션 트랜잭션 카운터의 이전 값에 대하여 상기 집적 회로 칩으로부터 수신한 상기 애플리케이션 카운터를 매칭시킴으로써, 상기 트랜잭션을 인증하는 단계를 추가로 포함하는 것을 특징으로 하는 인증 방법.
KR1020057023208A 2003-06-04 2004-06-04 전자 상거래 트랜잭션에서의 고객 인증 시스템 및 방법 KR20060034228A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US47563903P 2003-06-04 2003-06-04
US60/475,639 2003-06-04

Publications (1)

Publication Number Publication Date
KR20060034228A true KR20060034228A (ko) 2006-04-21

Family

ID=33551554

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020057023208A KR20060034228A (ko) 2003-06-04 2004-06-04 전자 상거래 트랜잭션에서의 고객 인증 시스템 및 방법

Country Status (10)

Country Link
US (1) US9514458B2 (ko)
EP (1) EP1646976A4 (ko)
JP (1) JP2006527430A (ko)
KR (1) KR20060034228A (ko)
CN (1) CN1853189A (ko)
AU (1) AU2004252824B2 (ko)
BR (1) BRPI0411005A (ko)
CA (1) CA2528451A1 (ko)
MX (1) MXPA05012969A (ko)
WO (1) WO2005001618A2 (ko)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101460627B1 (ko) * 2007-02-20 2014-11-13 크립토매틱 엘티디 인증 디바이스 및 방법
KR20150014972A (ko) * 2012-05-24 2015-02-09 제이브이엘 벤쳐스, 엘엘씨 무접촉 프로토콜을 제공하기 위한 시스템들, 방법들, 및 컴퓨터 프로그램 제품들
KR101540417B1 (ko) * 2007-04-17 2015-07-29 비자 유에스에이 인코포레이티드 트랜잭션에 대한 당사자 인증 방법 및 시스템
WO2017209364A1 (ko) * 2016-05-31 2017-12-07 주식회사지니 생체 정보를 이용한 카드 결제 처리 시스템 및 그의 처리 방법
KR20200105706A (ko) * 2018-01-17 2020-09-08 가부시키가이샤 사이게임스 통신을 행하기 위한 시스템, 프로그램, 방법 및 서버
US11775959B2 (en) 2014-12-16 2023-10-03 Visa Europe Limited Transaction authorization

Families Citing this family (108)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7899753B1 (en) 2002-03-25 2011-03-01 Jpmorgan Chase Bank, N.A Systems and methods for time variable financial authentication
US10134202B2 (en) * 2004-11-17 2018-11-20 Paypal, Inc. Automatic address validation
AU2006207908B2 (en) 2005-01-28 2012-06-07 Cardinal Commerce Corporation System and method for conversion between internet and non-internet base transactions
US7533047B2 (en) * 2005-05-03 2009-05-12 International Business Machines Corporation Method and system for securing card payment transactions using a mobile communication device
EP1802155A1 (en) 2005-12-21 2007-06-27 Cronto Limited System and method for dynamic multifactor authentication
GB2435951A (en) * 2006-02-23 2007-09-12 Barclays Bank Plc System for PIN servicing
AT503263A2 (de) * 2006-02-27 2007-09-15 Bdc Edv Consulting Gmbh Vorrichtung zur erstellung digitaler signaturen
JP5294880B2 (ja) * 2006-03-02 2013-09-18 ヴィザ インターナショナル サーヴィス アソシエイション メール注文及び電話注文における二要素認証を実施するための方法及びシステム
CN100566254C (zh) * 2007-01-24 2009-12-02 北京飞天诚信科技有限公司 提高智能密钥设备安全性的方法和系统
US10210512B2 (en) * 2007-02-13 2019-02-19 Mastercard International Incorporated Transaction count synchronization in payment system
US8121956B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Cardless challenge systems and methods
US7849014B2 (en) * 2007-08-29 2010-12-07 American Express Travel Related Services Company, Inc. System and method for facilitating a financial transaction with a dynamically generated identifier
GR20070100592A (el) * 2007-09-27 2009-04-30 Νικος Παντελη Τσαγκαρης Συστηματα και μεθοδοι διεκπεραιωσης διαδικτυακων συναλλαγων με διαφανως προσφερομενη ασφαλεια
US9747598B2 (en) 2007-10-02 2017-08-29 Iii Holdings 1, Llc Dynamic security code push
US8794532B2 (en) * 2008-12-29 2014-08-05 Mastercard International Incorporated Methods and apparatus for use in association with identification token
US20090198618A1 (en) * 2008-01-15 2009-08-06 Yuen Wah Eva Chan Device and method for loading managing and using smartcard authentication token and digital certificates in e-commerce
US8255688B2 (en) 2008-01-23 2012-08-28 Mastercard International Incorporated Systems and methods for mutual authentication using one time codes
EP2274704B1 (en) * 2008-04-04 2016-06-08 International Business Machines Corporation Handling expired passwords
US8160064B2 (en) 2008-10-22 2012-04-17 Backchannelmedia Inc. Systems and methods for providing a network link between broadcast content and content located on a computer network
US9094721B2 (en) 2008-10-22 2015-07-28 Rakuten, Inc. Systems and methods for providing a network link between broadcast content and content located on a computer network
AU2009311303B2 (en) 2008-11-06 2015-09-10 Visa International Service Association Online challenge-response
EP2192540A1 (fr) * 2008-11-28 2010-06-02 Gemalto Canada Inc. Objet portable comportant un afficheur et application à la réalisation de transactions électroniques
CA2751554C (en) 2009-02-05 2015-07-21 Wwpass Corporation Centralized authentication system with safe private data storage and method
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US10846683B2 (en) 2009-05-15 2020-11-24 Visa International Service Association Integration of verification tokens with mobile communication devices
US8602293B2 (en) 2009-05-15 2013-12-10 Visa International Service Association Integration of verification tokens with portable computing devices
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad Integration of verification tokens with mobile communication devices
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
US9124566B2 (en) 2009-06-23 2015-09-01 Microsoft Technology Licensing, Llc Browser plug-in for secure credential submission
US20110035294A1 (en) * 2009-08-04 2011-02-10 Authernative, Inc. Multi-tier transaction processing method and payment system in m- and e- commerce
US9084071B2 (en) * 2009-09-10 2015-07-14 Michael-Anthony Lisboa Simple mobile registration mechanism enabling automatic registration via mobile devices
FR2950768A1 (fr) * 2009-09-30 2011-04-01 Xiring Sa Systeme et procede de transaction securisee en ligne
US10454693B2 (en) * 2009-09-30 2019-10-22 Visa International Service Association Mobile payment application architecture
US8332325B2 (en) * 2009-11-02 2012-12-11 Visa International Service Association Encryption switch processing
CA2780278A1 (en) * 2009-11-04 2011-05-12 Visa International Service Association Verification of portable consumer devices for 3-d secure services
EP2320395A1 (en) * 2009-11-05 2011-05-11 Multos International Pty Ltd. Method for providing data during an application selection process
CN101739771A (zh) * 2009-12-01 2010-06-16 孙伟 一种公交一卡通业务系统及其实现方法
US10255591B2 (en) * 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
EP3404601A1 (en) * 2010-01-19 2018-11-21 Visa International Service Association Token based transaction authentication
US10255601B2 (en) * 2010-02-25 2019-04-09 Visa International Service Association Multifactor authentication using a directory server
US20120143752A1 (en) 2010-08-12 2012-06-07 Mastercard International, Inc. Multi-commerce channel wallet for authenticated transactions
EP2617156B1 (en) * 2010-09-13 2019-07-03 CA, Inc. Methods, apparatus and systems for securing user-associated passwords used for identity authentication
US8746553B2 (en) 2010-09-27 2014-06-10 Mastercard International Incorporated Purchase Payment device updates using an authentication process
CN102469091B (zh) * 2010-11-18 2014-12-10 金蝶软件（中国）有限公司 一种页面验证码处理的方法、装置及终端
CN107967602A (zh) 2011-03-04 2018-04-27 维萨国际服务协会 支付能力结合至计算机的安全元件
EP2530868A1 (en) * 2011-05-31 2012-12-05 Gemalto SA Method for generating an anonymous routable unlinkable identification token
WO2013012671A1 (en) 2011-07-15 2013-01-24 Mastercard International, Inc. Methods and systems for payments assurance
DE102011108069A1 (de) * 2011-07-19 2013-01-24 Giesecke & Devrient Gmbh Verfahren zum Absichern einer Transaktion
CN102300182B (zh) * 2011-09-07 2013-08-14 飞天诚信科技股份有限公司 一种基于短信的身份验证方法、系统和装置
CN103797811B (zh) 2011-09-09 2017-12-12 乐天株式会社 用于消费者对交互式电视接触的控制的系统和方法
US10242368B1 (en) * 2011-10-17 2019-03-26 Capital One Services, Llc System and method for providing software-based contactless payment
US9767453B2 (en) 2012-02-23 2017-09-19 XRomb Inc. System and method for processing payment during an electronic commerce transaction
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US8856923B1 (en) * 2012-06-29 2014-10-07 Emc Corporation Similarity-based fraud detection in adaptive authentication systems
US10592978B1 (en) * 2012-06-29 2020-03-17 EMC IP Holding Company LLC Methods and apparatus for risk-based authentication between two servers on behalf of a user
RU2509359C1 (ru) * 2012-09-26 2014-03-10 Пэйче Лтд. Способ подтверждения платежа
WO2014087381A1 (en) * 2012-12-07 2014-06-12 Visa International Service Association A token generating component
US9741032B2 (en) * 2012-12-18 2017-08-22 Mcafee, Inc. Security broker
US10504111B2 (en) * 2012-12-21 2019-12-10 Intermec Ip Corp. Secure mobile device transactions
US20150026070A1 (en) * 2013-07-16 2015-01-22 Mastercard International Incorporated Systems and methods for correlating cardholder identity attributes on a payment card network to determine payment card fraud
EP2827291A1 (en) * 2013-07-19 2015-01-21 Gemalto SA Method for securing a validation step of an online transaction
CA2919199C (en) * 2013-07-24 2020-06-16 Visa International Service Association Systems and methods for communicating risk using token assurance data
US11004069B2 (en) * 2013-10-03 2021-05-11 Nxp B.V. Article and method for transaction irregularity detection
AU2014331673B2 (en) 2013-10-11 2018-05-17 Mastercard International Incorporated Network token system
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
CN115082065A (zh) 2013-12-19 2022-09-20 维萨国际服务协会 基于云的交易方法和系统
US10096027B2 (en) * 2014-03-12 2018-10-09 The Toronto-Dominion Bank System and method for authorizing a debit transaction without user authentication
CN103841111B (zh) * 2014-03-17 2017-11-14 北京京东尚科信息技术有限公司 一种防止数据重复提交的方法和服务器
US20150317630A1 (en) * 2014-04-30 2015-11-05 MasterCard Incorporated International Method and system for authentication token generation
EP3146747B1 (en) 2014-05-21 2020-07-01 Visa International Service Association Offline authentication
US10311434B2 (en) * 2014-05-29 2019-06-04 Paypal, Inc. Systems and methods for reporting compromised card accounts
US11023890B2 (en) 2014-06-05 2021-06-01 Visa International Service Association Identification and verification for provisioning mobile application
WO2016019163A1 (en) * 2014-07-30 2016-02-04 Visa International Service Association Authentication system with message conversion
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
TWI503693B (zh) * 2014-09-04 2015-10-11 Joe Chi Chen 全動態數位電子支付交易身份認證方法
WO2016089993A1 (en) 2014-12-03 2016-06-09 D Alisa Albert Proprietary token-based universal payment processing system
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
CN107438992B (zh) * 2015-04-10 2020-12-01 维萨国际服务协会 浏览器与密码的集成
RU2018114639A (ru) * 2015-09-21 2019-10-23 УанСпэн Интернэшнл ГмбХ Многопользовательский строгий аутентификационный маркер
GB2542617B (en) * 2015-09-28 2020-06-24 Touchtech Payments Ltd Transaction authentication platform
US20170103396A1 (en) * 2015-10-13 2017-04-13 Mastercard International Incorporated Adaptable messaging
US9800580B2 (en) 2015-11-16 2017-10-24 Mastercard International Incorporated Systems and methods for authenticating an online user using a secure authorization server
WO2017083961A1 (en) * 2015-11-19 2017-05-26 Securter Inc. Coordinator managed payments
EP3179431A1 (en) * 2015-12-11 2017-06-14 Mastercard International Incorporated User authentication for transactions
CN105528699A (zh) * 2015-12-24 2016-04-27 中国银行股份有限公司 一种金融芯片卡的芯片信息验证方法和装置
US10282726B2 (en) * 2016-03-03 2019-05-07 Visa International Service Association Systems and methods for domain restriction with remote authentication
US10607224B2 (en) * 2016-04-04 2020-03-31 Mastercard International Incorporated Systems and methods for secure authentication of transactions initiated at a client device
US20170344989A1 (en) * 2016-05-27 2017-11-30 Mastercard International Incorporated Systems and Methods for Use in Facilitating Interactions Between Merchants and Consumers
US20180047018A1 (en) * 2016-08-15 2018-02-15 Capital One Services, Llc Browser extension for field detection and automatic population and submission
CN110546668B (zh) * 2017-05-25 2023-11-24 阿泰克控股有限公司 卡的交易的动态认证方法及系统
US11080697B2 (en) * 2017-10-05 2021-08-03 Mastercard International Incorporated Systems and methods for use in authenticating users in connection with network transactions
US11108811B2 (en) * 2018-01-22 2021-08-31 Avaya Inc. Methods and devices for detecting denial of service attacks in secure interactions
US10581611B1 (en) * 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3062211A1 (en) * 2018-11-26 2020-05-26 Mir Limited Dynamic verification method and system for card transactions
US11392957B2 (en) * 2019-03-07 2022-07-19 Mastercard International Incorporated User verification for credential device
CN110264212B (zh) * 2019-05-24 2023-09-01 创新先进技术有限公司 一种风控方法、装置、电子设备及存储介质
SE1950814A1 (en) * 2019-06-28 2020-12-29 Assa Abloy Ab Cryptographic signing of a data item
US20210004793A1 (en) * 2019-07-03 2021-01-07 Visa International Service Association Mobile-OTP Based Authorisation of Transactions
EP3809350A1 (en) * 2019-10-18 2021-04-21 Mastercard International Incorporated Enchanced security in sensitive data transfer over a network
EP3809352A1 (en) 2019-10-18 2021-04-21 Mastercard International Incorporated Authentication for secure transactions in a multi-server environment
US20210241266A1 (en) * 2020-01-31 2021-08-05 Mastercard International Incorporated Enhancing 3d secure user authentication for online transactions
CA3170260A1 (en) * 2020-03-10 2021-09-16 Dartanyon Antwaun WILLIAMS A method of securing a payment card transaction
US11361315B2 (en) * 2020-05-13 2022-06-14 Capital One Services, Llc Systems and methods for card authorization
US20220138803A1 (en) * 2020-11-02 2022-05-05 Jpmorgan Chase Bank, N.A. Systems and methods for payment product verification and authorization using a customer identifier
US11843702B2 (en) 2020-11-20 2023-12-12 The Toronto-Dominion Bank System and method for secure distribution of resource transfer request data
US11653207B2 (en) * 2021-02-26 2023-05-16 Charter Communications Operating, Llc Automatic authentication of wireless devices

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5604801A (en) * 1995-02-03 1997-02-18 International Business Machines Corporation Public key data communications system under control of a portable security device
FR2733379B1 (fr) * 1995-04-20 1997-06-20 Gemplus Card Int Procede de generation de signatures electroniques, notamment pour cartes a puces
JPH0950465A (ja) * 1995-08-04 1997-02-18 Hitachi Ltd 電子ショッピング方法、電子ショッピングシステムおよび文書認証方法
US5859419A (en) * 1995-09-28 1999-01-12 Sol H. Wynn Programmable multiple company credit card system
US5768390A (en) * 1995-10-25 1998-06-16 International Business Machines Corporation Cryptographic system with masking
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
AU6758898A (en) * 1997-03-12 1998-09-29 Visa International Secure electronic commerce employing integrated circuit cards
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
DE19724901A1 (de) * 1997-06-12 1998-12-17 Siemens Nixdorf Inf Syst Mobilfunktelefon sowie solche mit gekoppeltem Rechner für Internet- bzw. Netzanwendungen und Verfahren zum Betreiben einer solchen Gerätekombination
US6453416B1 (en) * 1997-12-19 2002-09-17 Koninklijke Philips Electronics N.V. Secure proxy signing device and method of use
US6173400B1 (en) * 1998-07-31 2001-01-09 Sun Microsystems, Inc. Methods and systems for establishing a shared secret using an authentication token
FR2787273B1 (fr) 1998-12-14 2001-02-16 Sagem Procede de paiement securise
CA2259089C (en) * 1999-01-15 2013-03-12 Robert J. Lambert Method and apparatus for masking cryptographic operations
GB0006668D0 (en) 2000-03-21 2000-05-10 Ericsson Telefon Ab L M Encrypting and decrypting
EP1139200A3 (en) * 2000-03-23 2002-10-16 Tradecard Inc. Access code generating system including smart card and smart card reader
EP1278143A4 (en) * 2000-04-24 2006-09-06 Neotechkno Corp EXTERNAL DEVICE AND AUTHENTICATION SYSTEM
US7478434B1 (en) * 2000-05-31 2009-01-13 International Business Machines Corporation Authentication and authorization protocol for secure web-based access to a protected resource
AU2001256591A1 (en) * 2000-06-26 2002-01-08 Covadis Sa Computer keyboard unit for carrying out secure transactions in a communications network
GB2374498B (en) 2001-04-12 2004-02-18 Intercede Ltd Multi-stage authorisation system
US6990471B1 (en) * 2001-08-02 2006-01-24 Oracle International Corp. Method and apparatus for secure electronic commerce
JP3819269B2 (ja) * 2001-08-31 2006-09-06 株式会社損害保険ジャパン 電子カード利用認証システム
US20040019564A1 (en) * 2002-07-26 2004-01-29 Scott Goldthwaite System and method for payment transaction authentication
US20040044739A1 (en) * 2002-09-04 2004-03-04 Robert Ziegler System and methods for processing PIN-authenticated transactions

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101460627B1 (ko) * 2007-02-20 2014-11-13 크립토매틱 엘티디 인증 디바이스 및 방법
KR101540417B1 (ko) * 2007-04-17 2015-07-29 비자 유에스에이 인코포레이티드 트랜잭션에 대한 당사자 인증 방법 및 시스템
US9160741B2 (en) 2007-04-17 2015-10-13 Visa U.S.A. Inc. Remote authentication system
KR20150014972A (ko) * 2012-05-24 2015-02-09 제이브이엘 벤쳐스, 엘엘씨 무접촉 프로토콜을 제공하기 위한 시스템들, 방법들, 및 컴퓨터 프로그램 제품들
KR20180115353A (ko) * 2012-05-24 2018-10-22 구글 엘엘씨 무접촉 프로토콜을 제공하기 위한 시스템들, 방법들, 및 컴퓨터 프로그램 제품들
US10949832B2 (en) 2012-05-24 2021-03-16 Google Llc Systems, methods, and computer program products for providing a contactless protocol
US11775959B2 (en) 2014-12-16 2023-10-03 Visa Europe Limited Transaction authorization
WO2017209364A1 (ko) * 2016-05-31 2017-12-07 주식회사지니 생체 정보를 이용한 카드 결제 처리 시스템 및 그의 처리 방법
KR20200105706A (ko) * 2018-01-17 2020-09-08 가부시키가이샤 사이게임스 통신을 행하기 위한 시스템, 프로그램, 방법 및 서버

Also Published As

Publication number Publication date
US9514458B2 (en) 2016-12-06
AU2004252824A1 (en) 2005-01-06
CN1853189A (zh) 2006-10-25
JP2006527430A (ja) 2006-11-30
US20080154770A1 (en) 2008-06-26
WO2005001618A3 (en) 2005-03-10
EP1646976A2 (en) 2006-04-19
AU2004252824B2 (en) 2011-03-17
WO2005001618A2 (en) 2005-01-06
MXPA05012969A (es) 2006-03-17
BRPI0411005A (pt) 2006-07-04
CA2528451A1 (en) 2005-01-06
EP1646976A4 (en) 2008-02-27

Similar Documents

Publication Publication Date Title
US9514458B2 (en) Customer authentication in E-commerce transactions
JP4597529B2 (ja) 金融取引で使用するための認証の仕組みおよび方法
US20180075452A1 (en) Online payer authentication service
AU2001257280B2 (en) Online payer authentication service
US20020152180A1 (en) System and method for performing secure remote real-time financial transactions over a public communications infrastructure with strong authentication
US20020091646A1 (en) Method and system for verifying the identity of on-line credit card purchasers through a proxy transaction
AU2001257280A1 (en) Online payer authentication service

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid