KR20080059617A - 사용자 인증 방법 및 디바이스 - Google Patents

사용자 인증 방법 및 디바이스 Download PDF

Info

Publication number
KR20080059617A
KR20080059617A KR1020087010512A KR20087010512A KR20080059617A KR 20080059617 A KR20080059617 A KR 20080059617A KR 1020087010512 A KR1020087010512 A KR 1020087010512A KR 20087010512 A KR20087010512 A KR 20087010512A KR 20080059617 A KR20080059617 A KR 20080059617A
Authority
KR
South Korea
Prior art keywords
server
authentication
communication terminal
key
personal identification
Prior art date
Application number
KR1020087010512A
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
Priority claimed from EP05405716A external-priority patent/EP1773018A1/en
Application filed by 프리바스피어 아게 filed Critical 프리바스피어 아게
Publication of KR20080059617A publication Critical patent/KR20080059617A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/305—Authentication, i.e. establishing the identity or authorisation of security principals by remotely controlling device operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • 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/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication

Abstract

전기통신 네트워크를 통해 서버(4)에 액세스하기 위해 통신 단말기(1)를 사용하는 사용자를 인증하기 위해, 사용자로부터 개인 식별 코드(personal identification code)를 수신한다. 상기 통신 단말기(1)와 상기 서버(4) 사이에 교환된(S1, S2, S3) 보안 세션 설정 프로토콜 메시지(secure session establishment protocol message)로부터, 데이터 세트를 생성한다(S4). 이 데이터 세트에 기초하여, 상기 개인 식별 코드를 사용하여 트랜잭션 인증 번호를 생성한다(S52). 상기 통신 단말기(1)로부터 상기 서버(4)에 상기 트랜잭션 인증 번호를 송신한다(S54). 상기 서버(4)에서, 수신된 상기 트랜잭션 인증 번호를 상기 통신 단말기(1)와 교환한 상기 보안 세션 설정 프로토콜 메시지에 기초하여 검증한다(S20). 상기 트랜잭션 인증 번호는 실시간 중간자 공격(man-in-the-middle attacks)에 대해 온라인 사용자를 보호하는 세션 인식(session aware) 사용자 인증을 가능하게 한다.

Description

사용자 인증 방법 및 디바이스 {METHOD AND DEVICES FOR USER AUTHENTICATION}
본 발명은 서버에 액세스하는 사용자를 인증하기 위한 사용자 인증 방법 및 디바이스에 관한 것이다. 구체적으로는, 본 발명은 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하기 위한 사용자 인증 방법, 컴퓨터 프로그램 제품, 및 컴퓨터화된 서버에 관한 것이다.
인터넷을 통한 로그인 방식에 대한 공격의 정교함이 급속하게 발달하고 있다. 은행과 같은 기관들은 이중 요소 인증 디바이스(two-factor authentication divice)를 롤아웃(roll out)하고 있고, 일부는 고비용이긴 하지만 고속의 질의 응답 인증 방식(challenge-response mechanism)을 포함하기도 한다. 중간자(Man-in-the-middle, MITM) 공격은 인터넷 뱅킹과 같은, 모든 SSL/TLS 기반 온라인 애플리케이션들에 대한 심각한 위협을 내포하고 있다. 이에 대한 일반적인 해결책은, 원래의 보안 소켓 계층(Secure Sockets Layer, SSL) 프로토콜(US 5,657,390)또는 전송 계층 보안(Transport Layer Security, TLS) 프로토콜 표준(Dierks, T., and C. Allen, "The TLS Protocol Version 1.0," Request for Comments 2246, January 1999)에 의해 요구되는 바와 같은, 상호 인증에 기초한 클라이언트 인증서(client- certificate)를 사용하는 것이다.
특허 US 4,405,829, US 4,720,860, US 4,885,778, 및 US 4,856,062는 일반적으로 SecurlD 토큰(token)으로 알려져 있는 인증 토큰 디바이스에 관한 것이다. 이 인증 토큰 디바이스는 강력한 사용자 인증을 제공하지만, 실시간으로 일어나는 중간자(MITM) 공격에 대비하여 보호하지는 못한다.
특허출원 US 2004/0064687에 개시된 것은 온라인 제3자, 즉 "ID 제공자 (Identity Provider)"에 의해 중간자(MITM) 공격을 방지하는 방법이다. 개시된 이 방법은 SSL/TLS 프로토콜들의 변경을 요구하지 않고, 롤아웃되는 완전한 공개키 기반 구조(full public key infrastructure, PKI)도 요구하지 않는다. 하지만, 이 방법은 클라이언트가 ID 제공자의 하드 코딩된 인증서(hard-coded certificate)를 포함하고 변경할 것을 요구한다.
특허출원 US 2002/107798 A1은 보안 디바이스에 대해 스마트 카드(smart card)를 인증하는 방법을 개시한다. 개시된 이 방법은, 칩 카드(chip card)가 프로토콜을 개시하기 이전에, 보안 디바이스 공개키(public key)를 소유하고 있고, (클라이언트) 애플리케이션이 이 공개키만을 사용하는 것으로 한정된다고 가정한다. 하지만, 이러한 가정들은 일반적으로 이루어질 수 없다.
본 발명의 목적은 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하기 위한 사용자 인증 방법 및 디바이스를 제공하는 것이다. 특히, 본 발명의 목적은 실시간으로 일어나는 중간자(MITM) 공격에 대비하여 보호하는 사용자 인증을 위한 사용자 인증 방법 및 디바이스를 제공하는 것이다. 본 발명의 다른 목적은, 보안 세션 설정 프로토콜(secure session establishment protocol)로 설정된 보안 세션을 사용하는 전기통신 네트워크를 통해 서버에 액세스하는 사용자를 인증하기 위한 사용자 인증 방법 및 디바이스를 제공하는 것이다.
본 발명에 따르면, 이 목적들은 독립항들의 특징에 의해 달성된다. 또, 추가적인 유리한 실시예들은 종속항들 및 상세한 설명에 따른다.
본 발명에 따르면, 전술한 목적들은 특히, 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하기 위해, 상기 사용자로부터 개인 식별 코드(personal identification code)를 수신하고; 상기 통신 단말기와 상기 서버 사이에 교환된 보안 세션 설정 프로토콜 메시지(secure session establishment protocol message)로부터, 데이터 세트를 생성하며; 상기 데이터 세트에 기초하여, 상기 개인 식별 코드를 사용하여 트랜잭션 인증 번호를 생성하고; 상기 통신 단말기로부터 상기 서버에 상기 트랜잭션 인증 번호를 송신하며; 상기 서버에서, 상기 통신 단말기와 교환한 상기 보안 세션 설정 프로토콜 메시지에 기초하여 상기 트랜잭션 인증 번호(요컨대 상기 사용자)를 검증한다. 예를 들면, 상기 데이터 세트는 상기 통신 단말기에서 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 해시값(hash value)으로서 생성된다. 여기에 기재된 트랜잭션 인증 번호는, 본 발명의 문맥에서 세션 인증 번호 또는 세션 인증 코드로서 사용되고; 일부 실시예에서, 트랜잭션 인증 번호는 디지털 데이터 세트, 즉 디지털 트랜잭션 인증 번호로 표현된다는 것을 강조한다. 상기 개인 식별 코드 및 상기 통신 단말기와 상기 서버 사이에 교환된 상기 보안 세션 설정 프로토콜 메시지에 기초한 상기 트랜잭션 인증 번호의 생성은 실시간 중간자 공격(man-in-the-middle attacks)에 대비하여 온라인 사용자를 효율적으로 보호하는 세션 인식(session aware) 사용자 인증을 가능하게 한다.
일 실시예에서, 상기 통신 단말기와 연관된 인증 모듈 및/또는 상기 통신 단말기에서, 상기 데이터 세트로부터 인증 베이스 번호가 생성되고, 상기 트랜잭션 인증 번호는 상기 개인 식별 코드를 사용하여, 상기 인증 베이스 번호로부터 생성된다. 예를 들면, 상기 인증 베이스 번호는 상기 통신 단말기와 연관된 인증 모듈에서 생성된다. 또한, 상기 서버에서, 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 인증 베이스 번호를 생성하고, 상기 서버에서 생성된 상기 인증 베이스 번호 및 상기 개인 식별 코드를 사용하여 상기 서버에서 상기 트랜잭션 인증 번호를 검증한다.
바람직한 일 실시예에서, 상기 인증 베이스 번호 및 상기 개인 식별 코드는, 상기 통신 단말기에 접속되어 있지 않은 질의/응답(challenge/response, C/R) 토큰 디바이스(token device)에 (사용자에 의해) 입력된다. 상기 트랜잭션 인증 번호는, 상기 인증 베이스 번호 및 상기 개인 식별 코드에 기초하여 토큰 응답값으로서 상기 질의/응답 토큰 디바이스에서 생성된다. 상기 트랜잭션 인증 번호, 즉 토큰 응답값은 상기 서버에 상기 트랜잭션 인증 번호를 전송하기 이전에, 상기 통신 단말기에 (사용자에 의해) 입력된다.
일 실시예에서, 상기 인증 베이스 번호는, 난수를 생성하고, 상기 난수의 숫자(digit)들에 의해 결정되는 선택된 숫자들을 상기 데이터 세트로부터 선택하며, 상기 선택된 숫자들 및 상기 난수의 숫자들로부터 상기 인증 베이스 번호를 구성함으로써 상기 데이터 세트에 의해 생성된다.
일 실시예에서, 상기 인증 모듈과 연관된 키 쌍(key pair) 중 개인키(private key)를 사용하여, 디지털 서명(digital signature)을 생성하고; 상기 인증 모듈에서, 상기 인증 모듈과 연관된 비밀 토큰키(secret token key)를 사용하여, 상기 데이터 세트로부터 인증 베이스 번호를 생성하며; 상기 인증 베이스 번호로부터 트랜잭션 인증 번호를 생성하고; 상기 개인 식별 코드는 상기 디지털 서명의 생성 또는 상기 트랜잭션 인증 번호의 생성에 사용되며; 상기 디지털 서명은 상기 통신 단말기로부터 상기 서버에 송신되고; 상기 서버에서, 상기 디지털 서명은 상기 키 쌍 중 공개키를 사용하여 검증되며; 상기 트랜잭션 인증 번호는 상기 통신 단말기로부터 상기 서버로 송신되며; 상기 서버에서, 상기 데이터 세트를 암호화하기 위한 상기 비밀 토큰키를 사용하여, 상기 통신 단말기로부터 수신된 상기 데이터 세트로부터 인증 베이스 번호를 생성하고; 상기 서버에서, 상기 트랜잭션 인증 번호를 상기 서버에서 생성된 상기 인증 베이스 번호를 사용하여 검증한다.
일 실시예에서, 상기 트랜잭션 인증 번호는 상기 인증 베이스 번호 및 상기 개인 식별 코드로부터 생성된다. 상기 트랜잭션 인증 번호 및 사용자 식별자는 상기 통신 단말기로부터 상기 서버에 송신된다. 상기 트랜잭션 인증 번호는 상기 서버에서 생성된 상기 인증 베이스 번호와 상기 사용자 식별자에 할당된 개인 식별 코드를 사용하여 상기 서버에서 검증된다.
일 실시예에서, 상기 인증 모듈은 상기 통신 단말기에 탈착 가능하게 접속될 수 있는 인증 토큰 디바이스로서 구현된다. 상기 데이터 세트는, 상기 통신 단말기로부터 상기 인증 모듈을 상기 통신 단말기에 접속하는 디바이스 인터페이스를 통해 상기 서버에 전송된다. 이용 가능하다면, 상기 키 쌍 및 상기 비밀 토큰키는 상기 인증 모듈에 저장되며, 상기 디지털 서명은 상기 인증 모듈로부터 상기 디바이스 인터페이스를 통해 상기 통신 단말기에 전송된다.
추가 실시예에서, 토큰 식별자는 상기 통신 단말기로부터 상기 서버에 상기 트랜잭션 인증 번호와 함께 송신되고, 상기 비밀 토큰키는 상기 토큰 식별자에 기초하여 상기 서버에서 결정된다. 마스터키(master key)는 상기 서버에 저장되고, 상기 비밀 토큰키는 상기 토큰 식별자를 암호화하기 위한 상기 마스터키를 사용하여 상기 토큰 식별자로부터 상기 서버에서 생성된다.
일 실시예에서, 상기 인증 베이스 번호는 상기 인증 모듈로부터 상기 통신 단말기에 전송된다. 상기 개인 식별 코드는 상기 사용자로부터 상기 통신 단말기에 수신되고, 상기 트랜잭션 인증 번호는 상기 인증 베이스 번호 및 상기 개인 식별 코드로부터 상기 통신 단말기에서 생성된다.
다른 실시예에서, 상기 개인 식별 코드는 상기 사용자로부터 상기 인증 모듈에서 수신된다. 상기 트랜잭션 인증 번호는 상기 인증 베이스 번호 및 상기 개인 식별 코드로부터 상기 인증 모듈에서 생성되며, 상기 트랜잭션 인증 번호는 상기 인증 모듈로부터 상기 통신 단말기에 전송된다.
추가 실시예에서, 상기 개인 식별 코드는 생체인식 식별자(biometric identifier)와 함께 상기 사용자로부터 수신된다. 상기 트랜잭션 인증 번호는, 상기 서버에서 생성된 상기 인증 베이스 번호와 상기 서버에 저장된 생체인식 식별자, 및 상기 사용자 식별자에 할당된 개인 식별 코드를 사용하여, 상기 서버에서 검증된다.
다른 실시예에서, 상기 인증 베이스 번호는 상기 인증 모듈에 의해 디스플레이된다. 상기 인증 베이스 번호는 상기 사용자에 의해, 상기 개인 식별 코드 및 상기 인증 모듈에 의해 디스플레이된 상기 인증 베이스 번호로부터 생성되고, 상기 사용자에 의해 상기 통신 단말기에 입력된다.
또 다른 실시예에서, 상기 서버에서의 상기 트랜잭션 인증 번호의 성공적인 검증 후에, 상기 서버에서, 상기 데이터 세트에 공개 함수(public function)를 적용하고 암호화를 위한 상기 비밀 토큰키를 사용하여, 상기 데이터 세트로부터 서버 인증 코드를 생성한다. 상기 서버 인증 코드는 상기 서버로부터 상기 통신 단말기에 송신된다. 상기 인증 모듈에서, 상기 데이터 세트에 상기 공개 함수를 적용하고 암호화를 위한 상기 비밀 토큰키를 사용하여, 상기 데이터 세트로부터 서버 인증 코드를 생성한다. 상기 인증 모듈은 상기 서버로부터의 상기 서버 인증 코드를 상기 인증 모듈에서 생성된 상기 서버 인증 코드에 기초하여 검증한다. 일 실시예에서, 상기 서버로부터 수신된 상기 서버 인증 코드 및 상기 인증 모듈에서 생성된 상기 서버 인증 코드는, 상기 사용자에 의한 시각적인 검증((visual verification)을 위해 상기 인증 모듈에 의해 디스플레이된다.
부가 실시예에서, 상기 사용자는 상기 인증 모듈에 대한 복수의 가능한 기관 범위(institution scope) 중 하나를 선택한다. 상기 사용자에 의해 선택된 상기 기관 범위는, 상기 인증 모듈이 상기 인증 베이스 번호를 생성하기 위해 한 세트의 복수의 비밀 토큰키 중 하나의 기관 특정(institution-specific) 비밀 토큰키를 사용하게 한다. 상기 서버는 특정한 기관과 연관되어 있고, 상기 인증 베이스 번호를 생성하기 위해 상기 기관 특정 비밀 토큰키를 사용한다. 상기 서버는 상기 트랜잭션 인증 번호를 검정하기 위해 기관 특정 개인 식별 코드를 사용한다.
상기 제안된 사용자 인증 방법은 어떻게든 동기화되어야 하는 클록을 필요로 하지 않는다. 그 대신에, 상기 트랜잭션 인증 번호의 전달(currency)을 보증하기 위해, 상기 통신 단말기와 상기 서버(예컨대, SSL/TLS) 사이에 교환된 보안 세션 설정 프로토콜 메시지(예컨대, 그 해시값)로부터 구한 임시값(nonce)들을 채용한다.
또한, 상기 제안된 방법의 보안은, 상기 사용자 식별자, 및 사용자가 특정의 전송 가능한 토큰을 사용하는 시간 동안에, 또한 상기 토큰 식별자가, 예를 들면 브라우저의 양식 사전 기입 특성(form-pre-fill-feature)에 의해, 상기 통신 단말기에 저장되어 있다면, 특별히 훼손되지 않는다. 특히, 상기 통신 단말기가 공유 워크스테이션이라면, 이것이 이 두 값을 습득하는 다른 상대방들 및 어쩌면 적들에게 인도할 수 있지만, 제안된 방법은 이것을 방지한다.
클라이언트 측(client-side) SSL/TSL를 구현하는 대부분의 유비쿼터스 베이스(ubiquitous base)는 변경되지 않아야 한다. 또한 대부분의 실시예의 경우, SSL/TSL 스택을 사용하는 웹 브라우저와 같은 클라이언트 애플리케이션은 변경되지 않아야 한다.
인증된 보안 세션 부트스트랩핑(bootstrapping)의 동작은, 문맹의 엔드 유저(end-user) 보호에 오늘날 널리 보급된 이중 요소 해결법(two-factor solutions)보다 더 복잡하지 않다.
중간자 증명(MITM-proof) 방법을 구현하기 위해, 엔드 유저 등록 또는 다른 고가의 프로세스들을 필요로 하지 않는다. 이중 요소 해결법을 실행하는 기관은, 엔드 유저가 사용하고 있는 디바이스만을 교체(하지만 그들이 사용하는 PIN 또는 패스워드는 변경되지 않고 그대로임)하거나, 디바이스에서 실행되는 알고리즘 또는 프로토콜을 수정(공지된 펌웨어 갱신과 유사함)하여, 제안된 방법과 함께 동작하도록 소유한 서버 기반 구조를 적응시켜야 한다.
본 발명의 다른 목적에 따르면, 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자에 대한, 개인 식별 코드를 변경하기 위해, 상기 사용자로부터 수신되는 것은 구(old) 개인 식별 코드와 신(new) 개인 식별 코드이며; 상기 통신 단말기와 상기 서버 사이에 교환된 보안 세션 설정 프로토콜 메시지로부터 데이터 세트를 생성하며; 상기 통신 단말기와 연관된 인증 모듈에서, 상기 인증 모듈과 연관된 비밀 토큰키를 사용하여, 상기 데이터 세트로부터 인증 베이스 번호를 생성하며; 상기 인증 베이스 번호, 상기 구 개인 식별 코드, 및 상기 신 개인 식별 코드로부터 ID(identification) 변경 코드를 생성하고; 상기 통신 단말기로부터 상기 서버에 상기 ID 변경 코드를 송신하며; 상기 서버에서, 상기 비밀 토큰키를 사용하여, 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 인증 베이스 번호를 생성하고; 상기 서버에서, 상기 구 개인 식별 코드 및 상기 서버에서 생성된 상기 인증 베이스 번호를 사용하여, 상기 ID 변경 코드로부터 상기 신 개인 식별 코드를 생성한다.
전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하는 다른 실시예에서, 상기 트랜잭션 인증 번호는 상기 통신 단말기와 연관된 인증 모듈에서, 상기 개인 식별 코드, 및 상기 통신 단말기와 상기 서버 사이에 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 키 암호 다이제스트 값(keyed cryptographic digest value)으로서 생성되고, 상기 서버와 비밀리 공유된 키로서 사용한다. 상기 키 암호 다이제스트 값은 상기 통신 단말기로부터 상기 서버에 상기 트랜잭션 인증 번호로서 송신된다. 상기 서버에서, 상기 서버에 저장된 개인 식별 코드를 사용하여 상기 키 암호 다이제스트 값을 생성한다. 그 후, 상기 서버에서, 상기 트랜잭션 인증 번호, 요컨대 상기 사용자의 진정성(authenticity)을, 상기 통신 단말기로부터 수신된 키 암호 다이제스트 값과 상기 서버에서 생성된 키 암호 다이제스트 값의 비교에 기초하여 검증한다. 예를 들면, 상기 인증 모듈과 연관된, 상기 개인 식별 코드 또는 비밀 토큰키를 키로서 사용한다. 상기 키 암호 다이제스트 값은 키 암호 다이제스트 함수, 즉 암호 해시 함수(cryptographic hash function)와 같은 의사 난수 함수(pseudo random function, PRF)을 사용하여 생성된다. 다른 실시예에서, 상기 데이터 세트로부터 룩업 인덱스(lookup index)가 생성되고, 코드 테이블(예컨대, 키 리스트)에서 결정되는 것은 상기 룩업 인덱스를 사용하여 선택된 코드이다. 상기 선택된 코드는 (해시) 키로서 사용되고, 상기 서버는, 저장된 코드 테이블로부터 선택된 코드를 상기 (해시) 코드로 사용하여 상기 키 암호 다이제스트 값을 생성한다. 하위 실시예에서, 상기 서버는 상기 통신 단말기에 의해 사용된 이전의 선택된 코드들에 대한 추적을 계속하고, 상기 서버는 선택된 코드가 상기 통신 단말기에 의해 이전에 사용되었던 것으로 판정한 경우에 상기 통신 단말기와의 세션 설정을 다시 개시한다
전기통신 네트워크를 통해 서버를 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하는 추가 실시예에서, 상기 트랜잭션 인증 번호는 상기 통신 단말기와 연관된 인증 모듈에서 공개키를 사용하여 상기 데이터 세트, 상기 개인 식별 코드, 및 임시값(nonce)을 암호화함으로써 암호(cryptogram)로서 생성된다. 상기 암호는 상기 통신 단말기로부터 상기 서버에 상기 트랜잭션 인증 번호로서 송신된다. 상기 서버에서, 개인 키를 사용하여 상기 암호를 해독함으로써 상기 데이터 세트 및 상기 개인 식별 코드를 결정한다. 그 후, 상기 서버에서, 상기 수신된 데이터 세트와 상기 보안 세션 설정 프로토콜 메시지로부터 생성된 데이터 세트의 비교, 그리고 상기 개인 식별 코드와 상기 서버에 저장된 개인 식별 코드의 비교에 기초하여, 해독된 트랜잭션 인증 번호, 요컨대 상기 사용자의 진정성을 검증한다.
일 실시예에서, 상기 데이터 세트로부터 룩업 인덱스를 생성하고, 코드 테이블(예컨대, 키 리스트)에서 결정되는 것은 상기 룩업 인덱스를 사용하여 선택된 코드이다. 상기 선택된 코드는 상기 암호의 생성 시에도 사용된다. 상기 서버는 상기 개인키를 사용하여, 상기 암호로부터 상기 선택된 코드를 결정한다. 상기 트랜잭션 인증 번호, 요컨대 상기 사용자의 진정성은 상기 선택된 코드와 상기 서버에 저장된 코드 테이블로부터 상기 서버에 의해 결정된 선택된 코드를 비교함으로써 검증된다. 하위 실시예에서, 상기 서버는 상기 통신 단말기에 의해 사용된 선택된 코드를 계속 추적하고, 상기 서버는 선택된 코드가 상기 통신 단말기에 의해 이전에 사용되었던 것으로 판정하는 경우에, 상기 통신 단말기와의 세션 설정을 다시 개시한다.
본 발명의 부가적인 목적에 따르면, 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하기 위해, 상기 통신 단말기와 상기 서버 사이에 교환된 보안 세션 설정 프로토콜 메시지로부터 데이터 세트를 생성하고; 상기 통신 단말기에서 상기 데이터 세트, 상기 개인 식별 코드, 및 하나 또는 두 개의 임시값으로부터 인증 암호를 생성한다. 암호화를 위해 미리 규정된 공개키를 사용한다. 이 키는 상기 서버 또는 복수 기관의 경우에 인증 서버 중 어느 하나에 속한다. 결과로서 생성된 암호는 일반 프로토콜 메시지 내에 불투명하게 상기 통신 단말기부터 상기 서버에 송신되며; 상기 서버에서, 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 데이터 세트를 생성하고; 상기 서버에서, 상기 암호를 대응하는 개인키를 사용하여 해독한다. 상기 서버의 데이터베이스로부터 검색되어 상기 암호가 해독된, 상기 개인 식별 코드는 상기 서버에서 계산된 개인 식별 코드와 비교되고, 상기 해독된 데이터 세트도 상기 서버에서 계산된 데이터 세트와 비교된다. 사용자가 상기 서버로부터 상기 사용자를 인증하기를 원한다면, 상기 제2 임시값도 또한 상기 암호로부터 해독되고 상기 사용자에게 다시 전송된다. 이 방법은 또한 개인 식별 코드를 변경하는데도 사용될 수 있다.
본 발명의 부가적인 목적에 따르면, 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하기 위해, 상기 통신 단말기와 상기 서버 사이에 교환된 보안 세션 설정 프로토콜 메시지로부터 데이터 세트를 생성하고; 상기 통신 단말기에서 상기 서버로부터 인덱스를 수신하거나 대역외(out-of-band)에 배포된 코드 테이블(예컨대, 키 리스트)로부터 단축키(short key)를 룩업하기 위해 인덱스를 생성한다. 상기 단축키 및 개인 식별 코드는 상기 통신 단말기에 입력되고, 인증자(authenticator)-이를 암호 또는 키 암호 다이제스트 값으로 하는-를 상기 데이터 세트, 상기 개인 식별 코드, 상기 단축키 및 최대 두 개의 임시값에 기초하여 생성한다. 상기 인증자는 상기 통신 단말기에서 상기 서버로 송신되고; 상기 서버에서, 상기 보안 세션 설정 프로토콜 메시지로부터 상기 데이터 세트를 생성하며; 상기 서버에서, 상기 서버에서 생성된 상기 데이터 세트, 상기 서버 데이터베이스 내의 상기 단축키 및 상기 개인 식별 코드를 사용하여, 키 암호 다이제스트 함수를 해독 또는 사용함으로써, 예컨대 암호 해싱에 의해 상기 서버에서 상기 인증자를 검증한다. 마찬가지로, 단축키는 또한 이미 설명한 다른 실시예들과 함께 사용될 수도 있다.
첨부도면을 참조하여, 예로서, 본 발명을 더욱 상세하게 설명한다.
도 1은 사용자 인증 모듈을 구비하고 전기통신 네트워크를 통해 인증 모듈들 을 가지는 통신 단말기에 접속되는, 컴퓨터화된 서버의 예시적인 구성을 개략적으로 나타낸 블록도이다.
도 2는 인증 모듈의 예시적인 구성을 개략적으로 나타낸 블록도이다.
도 3은 인증 토큰 디바이스로서의 인증 모듈의 예시적인 구성을 개략적으로 나타낸 블록도이다.
도 4는 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하기 위한 본 발명의 실시예에 따라 실행되는 일련의 단계에 대한 예를 나타내는 흐름도이다("통신 단말기에 PIN-U 입력 및 단말기에 TAN 생성(built)").
도 5는 사용자를 인증하기 위한 본 발명의 다른 실시예에 따라 실행되는 일련의 단계에 대한 예를 나타내는 흐름도이다("디바이스에 PIN-U 입력 및 디바이스에 TAN 생성").
도 6은 사용자를 인증하기 위한 본 발명의 또 다른 실시예에 따라 실행되는 일련의 단계에 대한 예를 나타내는 흐름도이다("사용자에 암기에 의해 TAN 생성").
도 7은 통신 단말기를 사용하는 사용자에 의해 전기통신 네트워크를 통해 액세스되는 서버를 인증하기 위한 본 발명의 실시예에 따라 실행되는 부가적인 일련의 단계에 대한 예를 나타낸 흐름도이다("디바이스에 대한 서버 인증 코드").
도 9는 서버를 인증하기 위한 본 발명의 다른 실시예에 따라 실행되는 부가적인 일련의 단계에 대한 예를 나타낸 흐름도이다("소트트 토큰 디바이스에 의한 서버 인증 코드").
도 10은 사용자를 인증하기 위한 본 발명의 추가 실시예에 따라 실행되는 부가적인 일련의 단계에 대한 예를 나타낸 흐름도이다("표준 디바이스 인터페이스에 기초한 질의 응답").
도 1에서, 도면부호 1은 전기통신 네트워크(3)를 통해 컴퓨터화된 서버(4)와 데이터를 교환하도록 구성된 통신 단말기(1)를 가리킨다. 통신 단말기(1)는, 고정(fixed) 개인용 컴퓨터(PC), 이동(mobile) 랩톱 컴퓨터, 이동 무선 전화기 및/또는 이동 개인 휴대용 정보 단말기(PDA)를 포함하지만 이것으로 한정되는 것은 아니다. 통신 단말기(1) 각각은 디스플레이(11)와, 키보드 및 포인팅 디바이스(pointing device), 예컨대 마우스, 트랙볼 등과 같은 데이터 입력 수단(12)을 가진다. 통신 단말기(1)는 SSL/TLS와 같은 보안 세션 설정 프로토콜로 설정된 보안 세션을 통해 서버(4)에 호스팅된 온라인 애플리케이션을 전기통신 네트워크(3)를 통해 액세스하기 위해, 클라이언트 애플리케이션, 바람직하게는 브라우저(예컨대, Microsoft Internet Explorer 또는 Mozilla Firefox)를 포함한다. 또한, 통신 단말기(1)는 인증 모듈(2)을 포함하며, 이에 대해서는 도 2 및 도 3을 참조하여 더욱 자세하게 후술한다.
전기통신 네트워크(3)는 고정 네트워크 및 무선 네트워크를 포함한다. 예를 들면, 전기통신 네트워크(3)는 근거리 통신망(local area network, LAN), 종합 정보 통신망(integrated services digital network, ISDN), 인터넷, GSM(Global System for Mobile communication, 유럽형 이동 통신 시스템), 범용 이동 통신 시 스템(universal mobile telecommunications system, UMTS) 또는 다른 지상 또는 위성 기반의 이동 무선 전화 시스템, 및/또는 무선 근거리 통신망(wireless local area network, WLAN)을 포함한다.
컴퓨터화된 서버(4)는, 각각이 하나 이상의 프로세서, 프로그램 및 데이터 메모리를 가지고, 또한 SSL/TLS와 같은 보안 세션 설정 프로토콜로 설정된 보안 세션을 통해 통신 단말기(1)에 접속 가능한 운영 체제 및 온라인 애플리케이션을 가지는 하나 이상의 컴퓨터를 포함한다. 예를 들면, 서버(4)는 Apche httpd 또는 Jakarta Tomcat 서버일 수 있다. 또한, 서버(4)는 사용자 인증 모듈(40) 및 데이터베이스(41)를 포함한다. 바람직하게는, 사용자 인증 모듈(40) 및 데이터베이스(41)는 프로그램된 소프트웨어 모듈로서 구현된다. 데이터베이스(41)는, 예를 들면 마스터키(MK)(42), 각각 사용자 식별자(ID_U)(43)를 포함하는 복수 세트의 사용자 데이터(400), 개인 식별 코드(PIN_U)(44), 및 가능한 한 대칭 비밀 토큰키(K_T)(45)를 포함할 수 있다. 개인 식별 코드(PIN_U)(44)는 사용자와 서버(4) 사이에 비밀리 공유되는 것이고, 생체인식 데이터(생체인식 식별자)를 포함할 수 있다. 또한 데이터베이스(41)는 공개키(k)(46)를 포함할 수 있다. 공개키(k)(46)를 포함하는 인증서는 또한 사용자 데이터 세트(400)의 사용자 특정 부분(user-specific part), 즉 특정한 사용자가 특정한 토큰을 사용하는 때에 사용자 식별자(ID_U)와 함께 임시로 할당될 수 있는 일련 번호(SN_T)일 수 있다. 사용자는 서버가 최종의 일련 번호(SN_T)-사용자 식별자(ID_U) 조합을 기억할 것인지 여부를 선택할 수 있을 것이다. 이렇게 함으로써 사용자가 여러 상이한 통신 단말기에 토 큰을 플러그인하는 경우에도 편의를 제공한다. 한편, 토큰을 분실한 경우에는 사용자 식별자(ID_U)를 그 토큰의 다음 사용자에게 노출할 수 있다- 인증의 우려는 없지만, 서버와 관련한 사용자의 프라이버시에 영향을 미친다.
도 2에 나타낸 바와 같이, 각각의 인증 모듈(2)은 수 개의 기능 모듈: 증명 모듈(certification module)(25), 인증 번호 생성기(26), 디스플레이 모듈(27) 및 가급적 서버 인증 모듈(28) 및/또는 선택 모듈(29)을 포함한다. 또한, 인증 모듈(2)은, 바람직하게는 무결성(integrity)이 보호되는 개인키(k^{-1})와 공개키(k)를 포함하는 비대칭키 쌍(k, k^{-1})(201)를 가지는 메모리 모듈을 포함할 수 있다. 식별을 위해, 인증 모듈(2)은 공지된 토큰 식별자(SN_T)와 연관될 수 있다. 바람직하게는, 인증 모듈(2)은 비개인적이고, PKSC#11 또는 MS-CAPI(Microsoft Cryptographic Application Programming Interface) 또는 다른 표준 디바이스 인터페이스와 호환된다. 일 실시예에서, 인증 모듈(2)은 토큰 식별자(203)를 구비하는 메모리 모듈을 포함할 수 있다. 토큰 식별자(203)는 또한, 예를 들면 브라우저의 형식 사전 기입 특징(form-pre-fill-feature)에 의해 통신 단말기(1)에 저장될 수도 있다. 또, 인증 모듈(2)은 비밀 토큰키(K_T)(202)를 가지는 보안 메모리 모듈 또는- 덜 바람직한 경우에- 마스터키(MK)(204)를 가지는 메모리 모듈 중 어느 하나를 포함한다. 키 쌍(k, k^{-1})은 모든 인증 모듈(2)에 대해 동일할 수 있고(토큰이 비개인적일 수 있는 이유임), 이에 반해 비밀 토큰키(K_T)는 인증 모듈(2)에 대해 고유하고 특정되어 있다. 비밀 토큰키(K_T)는 마스터키(MK)를 사용하여 토큰 식별자(SN_T)로부터 다음에 따라 생성될 수 있다:
K_T = E_{MK}(SN_T).
그 결과, 모든 비밀 토큰키를 집중 방식으로 저장할 필요는 없다. 대신에, 비밀 토큰키는 마스터키를 알고 있는 모든 사람에 의해 토큰 식별자로부터 동적으로 생성될 수 있다. 마스터키는 일반적으로 서버(4)에 의해 소유되고 유지된다. 마스터키, 아니 좀 더 정확히 말하면 비밀 토큰키는 이출 불가능한(non-exportable) 방식으로 변경 방지 키 스토어(tamper-proof key store)에 유지되어 있다. 또한 토큰 개인키(k^{-1})가 동일한 보안 스토리지에 의해 유지될 것을 추천하지만, 나중에 일반 대중에의 노출이 발행된 인증 모듈(2)의 집단 및 제안된 방법에 따른 그들의 기능을 위험에 빠뜨리지 않을 수 있다.
바람직하게는, 기능 모듈들은 프로그램된 소프트웨어 모듈들에 의해 구현된다. 이 소프트웨어 모듈들의 컴퓨터 프로그램 코드는 컴퓨터 프로그램 제품의 일부이고, 바람직하게는 통신 단말기(1)에 삽입될 수 있는 데이터 캐리어(data carrier)에, 통신 단말기(1)에 일체화된 메모리에, 또는 도 3에 나타낸 통신 단말기(1)에 접속된 인증 토큰 디바이스(20)에 일체화된 메모리 중 어느 하나의 컴퓨터로 판독 가능한 매체에 저장될 수 있다.
일 실시예에서, 인증 모듈(2)은 PKSC#11을 따르는 가급적 비개인적인 인증 토큰 디바이스(20)로서 구현된다. 인증 모듈(2)은 따라서 Cryptoki("PKCS #11: RSA Security Inc.에 의한 암호 토큰 인터페이스 표준(Cryptographic Token Interface Standard")) 또는 Microsoft CryptoAPI(http://msdn.microsoft.com/library/default.asp?url=library/en- us/seccrypto/security/cryptography_cryptoapi_and_capicom.asp)와 같은 표준 인터페이스를 통해, 보안 세션 설정 프로토콜, 예컨대 SSL/TLS 핸드세이크(handshake)에 참여하는 보안 하드웨어 토큰이다. 도 3에 나타낸 바와 같이, 인증 모듈(2)의 문맥에서 전술한 기능적인 모듈들 및 메모리 모듈들 외에, 인증 토큰 디바이스(20)는 디바이스 인터페이스(21), 데이터 입력 키(23) 또는 센서(24) 형태의 데이터 입력 수단, 및 가급적 디스플레이(22)를 포함한다. 선택적으로, 센서(24)는 생체인식 데이터(생체인식 식별자)를 입력하도록 구성되고, 예를 들면, 지문 판독기를 포함한다. 디바이스 인터페이스(21)는 인증 토큰 디바이스(20)를 통신 단말기(1)에 탈착 가능하게 접속하도록 구성된다. 디바이스 인터페이스(21)는 예컨대 USB(Universal Serial Bus) 인터페이스를 포함하는 접촉식(contact-based), 또는 예컨대 블루투스(Bluetooth) 또는 IrDA 인터페이스를 포함하는 비접촉식(contactless)이다. 인증 모듈(2)은 또한 오프라인 디바이스(C/R 또는 일회용 패스워드(one-time-password, OTP))와, 데이터 세트 또는 인증 베이스 번호로부터 무작위로 비트들을 선발하는 등의 기능들을 가지는 클라이언트 애플리케이션 소프트웨어를 구현하는 통신 단말기(1) 내의 일부 소프트웨어 모듈들 간에 분리될 수 있다.
이하에서, 도 4, 도 5, 도 6, 도 7, 도 8, 도 9, 및 도 10을 참조하여 제안된 사용자 인증 방법을 실행하는 가능한 시퀀스에 대해 설명하고, 또한 사용자 인증 모듈(40)과 기능 모듈들의 기능성(functionality)에 대해 설명한다. 기본적인 가정은, 사용자 기반 구조(user infrastructure)가 반드시 신뢰받은 컴퓨터 베이 스(trusted computer base)를 실행하고 있는 것은 아니라는 것이지만, 그럼에도 불구하고, 특히 SSL/TLS 구현이, 예컨대 실행 가능하고 정확하게 동작하는 Trojan에 의해 파괴되지 않는 것으로 가정되어야 한다. 하지만, 엔드 유저는, 예를 들면 SSL/TLS 보호 세션에서의 서버 인증서의 유효성(validity)을 확실히 검사할 수 있는, 정보 기술에 특별히 익숙한 것으로 기대되지 않는다. 마찬가지로, "UBS.COM"과 "U8S.COM"을 쉽게 구별할 수 있을 것으로 기대되지 않는다.
서버(4)에 의해 호스팅되는 온라인 애플리케이션을 액세스하기 위해, 사용자는 자신의 통신 단말기(1) 상의 클라이언트 애플리케이션에 적절히 지시한다. 보안 세션 설정 프로토콜, 예를 들면 SSL/TLS 핸드세이크 프로토콜의 일부로서, 서버(4)는 공개키 인증서를 사용하여 자신을 인증한다. 사용자가 이 인증서가 의도된 사이트에 정말로 속하는 것인지를 적절히 검증하지 않는 것으로 하지만 추가 처리하지는 않는 것으로 가정한다.
도 4에 나타낸 바와 같이, 단계 S1에서, 통신 단말기(1)는 예를 들면 SSL/TLS에 따라 서버(4)에 "ClientHello" 메시지를 송신함으로써, 보안 세션 설정 프로토콜에 따라 서버(4)와의 보안 세션 설정을 개시한다.
단계 S2에서, 보안 세션 설정 프로토콜에 따라, 서버(4)는, 예를 들면 SSL/TLS에 따라 통신 단말기(1)에 "SeverHello" 메시지를 송신함으로써, 단계 S1의 개시 메시지에 대해 응답한다.
단계 S3에서, 보안 세션 설정 프로토콜의 일부로서, 서버(4)는, 통신 단말기(1)에 인증 요청(certification request) 또는 "Finished" 메시지를, 예를 들면 SSL/TLS에 따라 "CertificateRequest" 또는 "Finished" 메시지를 송신한다.
단계 S4에서, 보안 세션 설정 프로토콜에 따라, 통신 단말기(1)의 데이터 세트 생성 모듈은 서버(4)와 교환한 이전의 보안 세션 설정 프로토콜 메시지에 기초하여 데이터 세트를 생성한다. 예를 들면, 데이터 세트 생성 모듈은 SSL/TLS에 따라 해시 함수를 적용함으로써 이전의 보안 세션 설정 프로토콜 메시지로부터 데이터 세트를 생성한다(교환된 보안 세션 설정 프로토콜 메시지는 여기에 명시적으로 열거한 것보다 더 많을 수 있다).
단계 S5에서, 단계 S4에서 생성된 데이터 세트(예컨대, 이하 해시(hash) 및 지명된(named) "해시"라고 함)를 인증 모듈(2) 또는 인증 토큰 디바이스(20)에 각각 전달한다. 통신 단말기(1)와 인증 모듈(2) 또는 인증 토큰 디바이스(20) 사이의 정보의 전달은 각각, 예를 들면 통신 단말기(1) 및/또는 인증 토큰 디바이스(20) 내의 공유 메모리 영역들을 사용하는 디바이스 인터페이스(21)를 통해 이루어질 수 있다.
단계 S6에서, 증명 모듈(25)은 단계 S5에서 수신된 데이터 세트를, 키 쌍(201)을 갖는 메모리 모듈로부터의 개인키(k^{-1})를 사용하여 암호화 방식으로 서명함으로써 전자 서명을 생성한다. 변형예에서, 공개 서명 유효키(public signature validation key)(k)(46)를 포함하는 서명에 결합되는 서명 인증서(signing certificate)는 사용된 특정 토큰의 일련 번호(SN_T)를 포함한다.
단계 S7에서, 단계 S6에서 생성된 전자 서명을 통신 단말기(1)에 전달한다.
단계 S8에서, 단계 S3에서 수신된 인증 요청에 대한 응답, 예를 들면 단계 S4에서 생성된 데이터 세트 및 단계 S6에서 생성된 전자 서명을 포함하는, SSL/TLS에 따른 "CertificateVerify" 메시지를 준비한다.
단계 S9에서, 통신 단말기(1)가 단계 S8에서 준비된 보안 세션 설정 프로토콜 메시지를 서버(4)로 송신한다.
단계 S10에서, 공개키(k)(46)를 사용하여, 서버(4)는 단계 S9에서 수신된 서명을 단계 S9에서 수신된 데이터 세트를 기초하여 검증한다. 인증 모듈(2)은 비개인적이기 때문에, 일반적으로 k^{-1}이 모든 토큰에 대해 동일하여, "CertificateVerify" 메시지는 클라이언트 애플리케이션을 실제로 인증하지 않는다. 대신에, "CertificateVerify" 메시지는 단지, 토큰이 서버에 대한 보안 세션을 설정하기 위해 클라이언트 애플리케이션에 의해 사용되고, 나중에 사용하기 위해 데이터 세트를 포착(capture)한다는 것을 확인한다. 단계 S4에서 생성된 데이터 세트가 "Finished" 메시지에 기초한 것이면, 단계 S5 - S9는 불필요하고, 단계 S10에서, 서버(4)는 단지 나중에 사용하기 위해 데이터 세트(해시)를 포착한다. "Finished" 메시지의 컨텐츠 또는 이미 암호화된 "Finished" 메시지를 조사할 수 있는 클라이언트 확장(extension) 또는 플러그인(plugin) 또는 외부의 "스니퍼(sniffer)"가 존재하는 경우에, 이 방법이 사용된다. 바람직하게는, 이러한 확장은 소규모이고, 플랫폼에 독립적이어서, 클라이언트 애플리케이션의 내부에 있거나 또는 제조 시의 클라이언트 애플리케이션 내에 일체화되기도 한다.
단계 S11에서, 인증 번호 생성기(26)는 인증 베이스 번호(N_T)를 단계 S5에서 수신된 데이터 세트(해시)로부터 생성한다. 인증 베이스 번호(N_T)는 인증 모 듈(2)과 연관된 비밀 토큰키(K_T)를 사용하여, 데이터 세트로부터 생성된다:
N_T = E_{K_T} (hash).
바람직하게는, 인증 베이스 번호(N_T)는 개인 식별 코드(PIN_U)의 규정된 길이로 단축된다(일 실시예에서는 절단에 의함).
단계 S12에서, 서버(4)의 사용자 인증 모듈(40)은 사용자 단말기로부터의 트랜잭션 인증 번호(TAN)를 요청한다. 단계 S6에서와 같이 토큰 특정 공개키 인증서 내에 공개키(46)가 있는 경우에, 사용자 식별자(ID_U)는 예를 들면 주어진 토큰(SN_T)과 함께 사용된 가장 최근의 사용자 식별자(ID_U)를 반영하는 요청과 함께 송신될 수 있다. 즉 토큰이 다른 사용자에 의해 사용되는 경우에, 사용자 식별자(ID_U)는 HTML 양식 필드(form field) 내에 이미 기입되어 있고 정정될 필요만 있기 때문에, 사용자에 의해 입력될 필요가 없다.
단계 S13에서, 단계 S11에서 생성된 인증 베이스 번호(N_T)를 통신 단말기(1)에 전달한다.
단계 S14에서, 통신 단말기(1)의 제어 모듈이 사용자에게 개인 식별 코드(PIN_U)를 요청하여 수신한다. 실시예에 따라서는, 데이터 입력 수단(12) 또는 생체인식 데이터(생체인식 식별자)용 센서, 예컨대 지문 판독기(예를 들면 상이한 손가락의 지문에 상이한 숫자 또는 문자(charater)를 할당한다)를 이용하여 개인 식별 코드(PIN_U)를 입력한다.
단계 S15에서, 통신 단말기(1)의 제어 모듈은, 예를 들면 사용자에게 투명한(transparent) 방식으로 의사 난사 함수(PRF)를 사용하여, 단계 S14에서 수신된 개인 식별 코드(PIN_U) 및 단계 S11에서 생성된 인증 베이스 번호(N_T)로부터 트랜잭션 인증 번호(TAN)를 생성한다:
TAN = PRF_{PIN_U}(N_T).
하위 실시예로서, 통신 단말기(1)에 의해 PIN을 수신할 수 있고, 단계 S15는 비개인적인 인증 토큰 디바이스(20)에서 실행될 수 있으며, 트랜잭션 인증 번호(TAN)는 그 후 통신 단말기(1)로 반송될 수 있다.
이 경우에, 하위 실시예로서, "CertificateVerify" 메시지를 생성하기 위한 단계들 및 트랜잭션 인증 번호(TAN)를 생성하기 위한 단계들은 상이하게 그룹화될 수 있다: 데이터 세트(해시)를 생성하기 위해 사용되는 함수 h가 암호화 해시 함수의 특성을 충족시키면, 예를 들어 HMAC 구성(Krawczyk, H., et al., "HMAC: Keyed-Hashing for Message Authentication," Request for Comments 2104, February 1997 참조)은 해시 함수 h를 구현하기 위해 사용될 수 있다: 개인 식별 코드(PIN_U)는 그후 데이터 세트(해시')의 CertificateVerify 계산에 대한 인수(argument)가 될 것이다. 이 실시예에서, 인증 베이스 번호(N_T')는 트랜잭션 인증 번호가 된다: TAN = N_T'. 이 실시예의 경우, 데이터 세트(해시')와, 해시 함수 h에 대한 하나의 입력, 즉 개인 식별 코드(PIN_U)를 제외한 모든 입력을 가지는 것에 의해, 개인 식별 코드(PIN_U)의 재구성을 실행할 수 없다는 것은 중요하다. HMAC는 이것을 실행하는 하나의 함수이다. HMAC는 또한 의사 랜덤 함수(PRF)에 사용될 수 있고 또 트랜잭션 인증 번호(TAN)를 생성하기 위해 사용될 수 있다:
TAN = HMAC_{PIN_U}(N_T) = h(K+opad||h(K+ipad||N_T)).
이 경우에, K는 몇몇의 고유하고 특정된 방식으로(예컨대, PKCS #5에 따라) 개인 식별 코드(PIN_U)로부터 구해진다. 부호 +는 모듈로 2 가산(addition module 2)를 가리키고, ||는 문자열 연결(string concatenation)을 가리킨다. opad 및 ipad는 상수값이다. 특히, 사용자가 트랜잭션 인증 번호(TAN)를 스스로 계산하지 않아도 되는 경우, 단지 십진수[0..9]만이 아니라 다른 알파벳이 바람직할 수 있다.
트랜잭션 인증 번호(TAN)는 정확히 하나의 보안(SSL/TLS) 세션에 대해 유효하다.
단계 S16에서, 단계 S12에서 수신된 요청에 대한 응답으로, 통신 단말기(1)는, 생성된 트랜잭션 인증 번호(TAN), 사용자에 의해 확인되거나 새롭게 입력된 사용자 식별자(ID_U), 그리고 k를 포함하는 토큰 인증서가 또한 토큰 식별자(SN_T)를 포함하지 않는 한 사용자에 의해 입력된 토큰 식별자(SN_T)를 서버(4)에 송신한다(단계 S6에서의 선택적인 경우처럼). 토큰 식별자(SN_T)는 토큰 식별자(203)를 가지는 메모리 모듈로부터 판독되거나, 예를 들면 브라우저와 연관된 통신 단말기(1) 내의 메모리로부터 판독된다.
단계 S17에서, 서버(4)의 사용자 인증 모듈(40)은 단계 S16에서 수신된 사용자 식별자(ID_U)에 할당되는 개인 식별 코드(PIN_U)(44)를 데이터베이스(40)에서 결정한다.
단계 S18에서, 인증 모듈(2)과 연관된 비밀 토큰키(K_T)를 사용하여, 사용자 인증 모듈(40)은 단계 S10에서 수신된 데이터 세트(해시)로부터 인증 베이스 번 호(N_T)를 생성한다. 일 실시예에서, 비밀 토큰키(K_T)는 마스터키(MK)(42)를 사용하여 단계 S16에서 수신된 토큰 식별자(SN_T)로부터 생성된다. 하지만, 비밀 토큰키(K_T)가 서버(4)에 저장되어 있다면, 마스터키(MK)를 사용하여 이를 다시 계산할 필요없이 완전히 임의로 선택할 수 있다. 토큰 식별자(SN_T)가, 예컨대 단계 S3과 단계 S9 사이의 "Client certificate"와 같은, 보안 세션 설정 프로토콜 중에 교환된 토큰의 클라이언트 인증서의 일부이면, 토큰 식별자(SN_T)는 단계 S16에서 통신 단말기(1)로부터 서버(4)에 송신되지 않는다.
단계 S19에서, 사용자 인증 모듈(40)은 단계 S17에서 결정된 개인 식별 코드(PIN_U)와 단계 S18에서 생성된 인증 베이스 번호(N_T)로부터 트랜잭션 인증 번호(TAN)를 생성한다.
단계 S20에서, 사용자 인증 모듈(40)은 단계 S16에서 수신된 트랜잭션 인증 번호를 단계 S19에서 생성된 트랜잭션 인증 번호와 비교함으로써 검증한다. 검증 결과가 긍정적이면, 통신 단말기(1)는 서버(4)에 대한 액세스를 제공받거나, 일 실시예에서, 서버(4)는 도 8을 참조하여 후술하는 단계 S41에서 계속된다.
도 5에 나타낸 바와 같이, 대안적인 실시예에서, 단계 S13, S14 및 S15를 포함하는 블록 A를, 단계 S21, S22, S23 및 S24를 포함하는 블록 B로 대체한다.
단계 S21에서, 인증 토큰 디바이스(20) 또는 인증 모듈(2) 각각의 데이터 입력 수단(23) 또는 센서(24)를 통해, 사용자로부터 개인 식별 코드(PIN_U)를 수신한다.
단계 S22에서, 증명 모듈(25)은 단계 S21에서 수신된 개인 식별 코드(PIN_U) 및 단계 S15의 문맥에서 전술한 바와 같이 단계 S11에서 생성된 인증 베이스 번호(N_T)로부터 트랜잭션 인증 번호(TAN)를 생성한다. 따라서, 단계 S15의 문맥에서 설명한 하위 실시예는 또한 도 5에 나타낸 실시예에도 적용한다.
단계 S23에서, 단계 S22에서 생성된 트랜잭션 인증 번호(TAN)를 통신 단말기(1)에 전달한다.
단계 S24에서, 통신 단말기(1)에서 트랜잭션 인증 번호(TAN)를 수신하고 가급적 디스플레이(11) 상에 디스플레이한다. 이어서, 통신 단말기(1)는 전술한 바와 같이 단계 S16에서 계속된다.
도 6에 나타낸 바와 같이, 대안적인 실시예에서, 단계 S13, S14 및 S15를 포함하는 블록 A를, 단계 S31 및 S32를 포함하는 블록 C로 대체한다.
단계 S31에서, 디스플레이 모듈(27)은 단계 S11에서 생성된 인증 베이스 번호(N_T)를 디스플레이(22) 상에 표시한다.
단계 S32에서, 통신 단말기(1)의 제어 모듈은 사용자로부터 트랜잭션 인증 번호(TAN)를 수신한다. 단계 S32에서 입력되는 트랜잭션 인증 번호는 사용자에 의해 디스플레이(22) 상에 표시된 인증 베이스 번호(N_T)와 사용자의 개인 식별 코드(PIN_U)를 조합함으로써 정해진다:
TAN = f(N_T, PIN_U).
일반적으로, 적절한 함수 f를 규정하는 것에는 많은 가능성이 있다. 인수들의 모듈로 10 가산을 사용하는 것이 제안되어 있다(Molva, R., and G. Tsudik, "Authentication Method with Impersonal Token Cards," Proceedings of IEEE Symposium on Research in Security and Privacy, IEEE Press, May 1993, 참조). 이 제안은 적당한 것이지만, 동일하게 잘 작용하는 다른 함수들이 많이 있다.
Swivel's PINsafe에 따른 다른 방법은, 예를 들면, 10 자릿수 길이의 인증 베이스 번호(N_T)를 표시하기 위한 것이고, 선발(picking)을 위해 숫자 PIN 내의 숫자들을 사용한다. 그 후에, 통신 단말기(1)는 전술한 바와 같이 단계 S16에서 계속된다.
도 7에 나타낸 실시예에서, 인증 모듈(2)은 통신 단말기(1) 내의 프로그램된 소프트웨어 모듈들에 의해 배타적으로 실행된다. 도 4에 나타낸 실시예와 비교하면, 도 7에 따른 실시예는 통신 단말기(1)와 이 통신 단말기(1) 외부의 인증 모듈(토큰 디바이스(20)) 사이에 교환하는 데이터가 없기 때문에, 단계 S5, S7, 및 S13을 포함하지 않는다. 소프트웨어 인터페이스들 또는 통신 단말기(1) 내의 공유된 메모리 영역들을 사용하여, 통신 단말기(1)와 인증 모듈(2) 사이에 정보를 교환한다. 그렇지 않으면, 도 4를 참조하여 전술한 바와 같이, 단계 S1 , S2, S3, S4, S6, S8, S9, S10, S11 , S12, S14, S16, S17, S18, S19 및 S20를 수행한다.
도 8에 나타낸 바와 같이, 단계 S41에서, 서버(4)는 단계 S9에서 수신된 데이터 세트(해시)로부터 서버 인증 코드를 생성한다. 이 서버 인증 코드(A_T)는 데이터 세트(해시)에 공개 함수 g를 적용하고 단계 S18에서 결정된 비밀 토큰키(K_T)를 암호화에 사용함으로써 생성된다:
A_T = E_{K_T}(g(hash)).
서버 인증 코드(A_T)의 구성은 인증 베이스 번호(N_T)의 구성과 동일하다. 그 유일한 차이점은 데이터 세트(해시)가 비밀 토큰키(K_T)를 사용하여 암호화되기 전에 공지된 함수 g로 처리된다는 것이다. 함수 g는 또한 복잡할 필요가 없다. 이것은 해시값의 보수 계산을 가능한 한 간단하게 할 수 있다. 서버 인증에 중요한 것은, 데이터 세트(해시)와 인증 베이스 번호(N_T)를 모두 볼 수 있는 상대편(adversary)이, 비밀 상태인 비밀 토큰키(K_T) 및 암호화 함수 E_(일 실시예에서 이것은 triple-DES와 같은 대칭 암호(symmetric cipher)일 수 있다)로 인해, 서버 인증 코드(A_T)를 구성할 수 없어야 한다는 것이다.
단계 S42에서, 단계 41에서 생성된 서버 인증 코드를 통신 단말기(1)에 송신한다.
단계 S43에서, 단계 42에서 수신된 서버 인증 코드가 통신 단말기(1)에 의해 디스플레이(11)에 디스플레이된다.
단계 S44에서, 서버 인증 모듈(28)은, 데이터 세트에 공개 함수 (g)를 적용하고 인증 모듈(2)과 연관된 비밀 토큰키(K_T)를 암호화에 사용함으로써, 단계 S5에서 수신된 데이터 세트(해시)로부터 서버 인증 코드를 생성한다.
단계 S45에서, 디스플레이 모듈(27)은 단계 S44에서 생성된 서버 인증 코드를 디스플레이(22) 상에 디스플레이한다.
단계 S46에서, 디스플레이(11) 상에 디스플레이된 서버 인증 코드를, 디스플레이(22) 상에 디스플레이된 서버 인증 코드와 비교함으로써 검증하는 사용자에 의해 서버(4)가 인증된다.
도 9에 나타낸 실시예에서, 인증 모듈(2)은 통신 단말기(1) 내의 프로그램된 소프트웨어 모듈들에 의해 배타적으로 실행된다. 도 8에 나타낸 실시예와 비교하면, 도 9에 따른 실시예에는, 단계 S47에서, 디스플레이 모듈(27)은 단계 S44에서 생성된 서버 인증 코드를 디스플레이(11) 상에 디스플레이한다. 또, 단계 S48에서, 디스플레이(11) 상의 서버 인증 코드를, 서버 인증 모듈(28)로부터의 서버 인증 코드와 비교함으로써 검증하는 사용자에 의해 서버(4)가 인증된다.
지금까지 제안된 인증 모듈(2)은 단일 기관(단일 개인 식별 코드를 사용함)에 대해 사용자를 인증하기 위해 사용될 수 있다. 추가 실시예에서, 인증 모듈(2)은 복수 기관을 가지는 애플리케이션용, 즉 복수 기관의 서버에 대해 사용자를 인증하기 위해 구성된다. 복수 기관 인증 모듈을 구현하기 위한 바람직한 방법은, 마스터키(MK)를 한 세트의 기관 특정(istitution-specific) 마스터키(MK_I)로 교체하고, 토큰키(K_T)를 한 세트의 기관 특정 토큰키(K_{IT})로 교체하는 것이며, 여기서 K_{IT}는 인증 모듈이 기관(I)과 공유하는 비밀 토큰키를 가리킨다. 각각의 서버(4)는 특정 기관과 연관되어 있고 인증 베이스 번호를 생성하기 위해 기관 특정 비밀 토큰키를 사용한다. 단일 기관을 설정하는 것과 마찬가지로, 비밀 토큰키(K_{IT})를 다음에 따라 동적으로 생성할 수 있다:
K_{IT} = E_{MK_I}(SN_T).
그 후, 이 키는 인증 베이스 번호 및 트랜잭션 인증 번호:
N_{IT} = E_{K_{IT}}(Hash),
및
TAN = f(N_{IT},PIN_{IU})
를 위한 기관 특정 값들을 생성하기 위해 사용된다.
그 후, 결과로서 생성된 트랜잭션 인증 번호(TAN)는 기관(I)(의 서버(4))를 인증하기 위해 사용자에 의해 사용될 수 있다. 개인 식별 코드(PIN_{IU})는 사용자에 특정된 것일 뿐 아니라 기관에 특정된 것이기도 하다. 따라서, 복수 기관 인증 모듈은, 저장된 한 세트의 복수 기관 특정 비밀 토큰키, 또는 복수 기관 특정 토큰 식별자 및 기관 특정 비밀 토큰키들을 동적으로 생성하기 위한 마스터키들의 저장된 세트들 중 어느 하나를 가짐으로써, 복수 기간 특정 비밀 토큰키들과 연관된다. 선택 모듈(29)은 사용자가 인증 모듈(2) 또는 인증 토큰 디바이스(20)에 대해 각각, 복수의 가능한 기관 범위 중에서 하나를 선택하도록 설계된다. 사용자에 의해 기관 범위가 설정되면, 인증 모듈(2)은 인증 베이스 번호를 생성하기 위해 하나의 각 기관 특정 비밀 토큰키를 사용한다. 예를 들면, 선택 모듈(29)은 사용자에게 지원되는 기관의 리스트를 디스플레이(22 또는 11)에 제시하고, 데이터 입력 수단(23 또는 12)을 통해 사용자의 선택을 수신한다. 대안적인 실시예에서, 데이터 입력 수단(23 또는 12)의 특정한 키들이 특정한 기관들에게 할당되어 있다.
인증 모듈(2)이 복수의 기관 특정 토큰키(K_{IT})가 아니라 단 하나만을 안전하게 보유하는 추가 실시예에서, 온라인 우선 발행 기관(online overarching issuing institution)(AS)이 추가된다. 이것은 인증 모듈(2)의 발행 그룹의 일부인 기관들의 세트에 대한 유연성을 향상시킨다. 인증 모듈(2)은 임시값(R_T)을 생성한다. 사용자는 인증 모듈(2)의 디스플레이로부터 두 개의 값을 복사하여야 한다, 즉, SN_T 대신에, 사용자 인증 단계 동안에 SSL/TLS 세션 설정을 성공한 후에 TAN_AS가 대신 생성되거나 입력되어야 한다:
TAN_I = f'(R_T, PIN_U_I)
TAN_AS = E_MK(R_T, Hash, ID_I),
여기서, ID_I는 "기관 XYZ"에 대해 "XYZ"와 같은, 단축 식별자 문자열이다.
기관(I)은 두 값을 모두 보며, 그 하나만으로는 어떤 것도 할 수 없다. 기관(I)은 TAN_AS를 발행 기관(AS)에 전달하고 임시값(R_T) 및 Hash를 반송으로 수신한다. 기관(I)과 발행 기관(AS) 사이의 접속은 상호 인증되고 기밀인 것으로 한다.
범죄 의도가 없다면, TAN_I는 발행 기관(AS)에 의해 결코 보여지지 않으며, 따라서 발행 기관(AS)이 PIN_U_I를 결정할 수 있는 위험은 없다. 하지만, 본 실시예에서는 전술한 바와 같이 강력한 암호 해시 함수인 f'만을 선택할 것을 추천한다.
마찬가지로, 이 방법은 각자의 사용자의 PIN을 습득하려는 시도로부터 기관(I_1 ... I_n)을 보호한다.
본 실시예는 새로운 기관의 추가를 크게 단순화한다. 실질적으로, 추가적인 ID_I_n 문자열을 인증 모듈(2)에 간단히 추가할 수 있다. 인증 모듈(2)에 위조(bogus) ID_I 문자열이 쇄도하면, 이것은 유용성에 관계되지만, 제안된 방법의 보안을 실제로 해치지는 않는다.
실시예에서, 인증 모듈(2) 또는 인증 토큰 디바이스(20) 각각은, "일회용 패스워드(one-time-password)"(OTP) 시스템(예컨대, Lamport형 일회용 패스워드(OTP) 들 (Lamport, L., "Password Authentication with Insecure Communication," Communications of the ACM, Vol. 24, 1981 , pp. 770-772 참조) 또는 SecurlD 토큰(http://www.rsasecurity.com/ 참조))을 보완하기 위해 사용된다. 이 경우에, 사용자는 단계 S15의 의사 랜덤 함수(PRF) 또는 f(PIN_U 대신)에 대한 입력으로서 일회용 패스워드(OTP)를 채용한다. 흔히, 일회용 패스워드(OTP)는 개인 식별 코드(PIN_U)를 포함한다. 다른 모든 것은 실질적으로 동일한 그대로이다. 프로토콜에 약간의 변화가 있으면, 이것은 RSA's SecurID와 같은, 이미 사용중인 이중 인자 보안 요소(two factor security element)를 가지는 소프트웨어 변형의 사용을 허용한다.
다른 실시예에서는, 인증 토큰 디바이스(20)를 활성화하기 전에 생체인식 인증 단계를 추가한다. 이것은 개별 프로세스에서 토큰이 개인화(personalize)되고 생체인식이 일치하는 경우에만 적어도 토큰의 "임시" 소유자에 대한 응대를 개시한다는 것을 의미한다.
추가 실시예에서, 사용자의 생체인식 특징(B_U)이 전술한 바와 같이 개인 식별 코드(PIN_U)를 입력하기 위해 사용되지 않으면, 생체인식 데이터는 인증 베이스 번호(N_T)의 계산에 포함된다. 또한, 본 실시예에서 서버는 개인 식별 코드(PIN_U)의 상부에 생체인식 특징(B_U)을 저장하므로, 인증 모듈(2)은 완전히 개인적으로 전송할 수 있는 상태로 유지된다.
N_T" = E_{K_T}(Hash, B_U)
도 4, 도 5, 도 6, 도 7, 도 8 및 도 9에 나타낸 상이한 시퀀스의 단계들이 본 발명의 범위를 벗어나지 않는다는 것을 밝힌다.
개인 식별 코드를 변경하는 실시예
엔드 유저의 교육 관점으로부터, 단순한 행동 지침을 가지는 것이 중요하다. 설명된 모든 실시예에 대해, 이 지침은 확실히 "당신의 현재 또는 새로운 개인 식별 코드를 웹 브라우즈에 결코 입력하지 마라!"가 될 것이다. 도 5에서와 같은 개인 식별 코드를 입력하기 위한 모듈과 같은, 부가적인 하드웨어를 포함하는 실시예들에 대해, 이 지침은 심지어 "당신의 메인 키보드로 스크린에 PIN을 결코 입력하지 마라!"가 될 것이다. 하지만, 바람직하게는, 사용자는 주기적으로 그리고 자발적으로 자신의 개인 식별 코드(PIN_U)를 변경할 수 있어야 한다.
예를 들면, 개인 식별 코드(PIN_U)를 변경하기 위해, 실질적으로 전술한 같이 동일한 단계들을 수행하는, 다른 보안 세션이 설정된다. 구체적으로는, 도 4, 도 5 또는 도 7에 나타낸 바와 같이, 단계 S1 내지 S10에 이어, 단계 S11에서 인증 베이스 번호(N_T)를 생성한다.
개인 식별 코드(PIN_U)의 변경과 관련한 사용자 또는 서버 명령어들에 응답하여, 단계 S14 또는 단계 S21 각각에서, 구(old) 개인 식별 코드(PINold_U) 및 신(new) 개인 식별 코드(PINnew_U)를 통신 단말기(1), 인증 토큰 디바이스(20), 또는 인증 모듈(2) 각각에서 사용자로부터 수신한다. 바람직하게는, 타이핑 오류를 방지하기 위해, 신 개인 식별 코드(PINnew_U)는 이중 입력을 통해 확인된다.
단계 S15 또는 S22 각각에서, 트랜잭션 인증 번호(TAN)를 생성하는 것이 아 니라, ID 변경 코드(PCC)를 생성한다. 본래, ID 변경 코드(PCC)를 계산하기 위해 사용되는 의사 랜덤 함수(PRF)는 개인 식별 코드를 복원 가능하게 만들어야 한다. 예를 들면, 배타적 논리합(exclusive-or, XOR) 함수가 이 특징을 가진다.
ID 변경 코드(PCC)는 그 후 적절하게 선택된 함수 f0에 대해 PCC = f0(N_T, PINold_U, PINnew_U)에 따라 계산된다. 예를 들면, f가 디지트 방식(digit- wise) 모듈로 10 가산을 나타내면, f0는 다음과 같이 규정될 수 있다:
f0 (N_T, PINold_U, PINnew_U) = f(f(N_T, PINold_U), PINnew_U).
예를 들어, N_T = 123, PINold_U = 345, 그리고 PINnew_U = 781이면, f(N_T, PINold_U) = 468이고 f(f(N_T, PINold_U), PINnew_U) = 149이다.
그 후, 단계 S16, S23, S24에서, 트랜잭션 인증 번호(TAN)가 아니라 ID 변경 코드(PCC)를 서버(4)에 전달한다. 단계 S17 및 S18을 전술한 바와 같이 수행한다. 단계 S19 및 S20에서, 그 결과 트랜잭션 인증 번호(TAN)를 검증하는 것이 아니라, 서버(4)는 사용자에 의해 제출된 ID 변경 코드(PCC)로부터 신 개인 식별 코드(PINnew_U)를 얻고, 진행중인 세션이 정당한 사용자에 의해 방치된 상태인 경우에, 개인 식별 코드(PIN_U)를 변경한 사용자가, 예를 들면 잠금 상태가 아닌 단말기를 부정 이용하는 누군가가 아닌 정말로 정당한 사용자였음을 (구 개인 식별 코드(PINold_U)의 검증을 통해) 보증한다. f0에 대해 주어진 예에서, 서비스의 거부를 초래할 수 있는 맹목적인 치환 공격(blind permutation attack)에 대비한 방어책이 없다. 그러나, 일반적으로 주된 세션 설정 프로토콜(SSL/TLS)의 문맥에서, 보완 메시지 무결성 보호가 이 공격을 방지할 것이다.
다른 실시예에서는, 개인 식별 코드(PIN_U)의 변경은 세 개의 보안 세션 설정으로 구현된다.
제1번, 사용자가 구 개인 식별 코드(PINold_U)를 다시 제공하여야 하는 경우; 제2번, 사용자가 신 개인 식별 코드(PINnew_U)를 제공하는 경우; 및 제3번, 사용자가 타이핑 오류를 방지하기 위하여 신 개인 식별 코드(PINnew_U)를 다시 제공하는 경우이다.
PIN 변경이 서버에서 개시된 경우, 이 프로토콜의 상태를 알리기 위해, 서버는 http://www.rfc.net/rfc2246.html#s7.4.4. - 세 단계 각각에 대해 상이한 기관(authority)임-에 약술되어 있는 바와 같이 의사 "DistinguishedName certificate_authorities"를 광고할 수 있다. 마찬가지로, 토큰은 네 개의 상이한 인증서를, 즉 하나는 정규(regular) 인증을 위해, 그리고 세 개는 본 실시예를 위해 가져야할 것이다.
다르게는, 인증 베이스 번호(N_T)를 계산하는 경우, 인증 토큰 디바이스(20) 또는 인증 모듈(2)은 각각, 단계 식별자를 포함한다. 따라서, 인증 토큰 디바이스(20) 또는 인증 모듈(2) 각각에 필요한, 상이한 인증서의 수를 감소시킬 수 있다.
개인 식별 코드의 변경이 클라이언트에서 개시된 경우, 서버는 두 개의 CA를 제공하여야 하는데, 하나는 정규 인증을 위한 것이고, 하나는 개인 식별 코드의 변경의 단계 1을 위한 것이다.
무암호화 ( encryption - free ) 인증 모듈을 가지는 실시예
다른 실시예에서, 인증 토큰 모듈(20) 또는 인증 모듈(2)은 각각, 암호화를 위해 구성될 필요는 없다.
이 실시예에서, 인증 베이스 번호(N_T)는 비밀인 토큰키(K_T)를 사용하는 HMAC와 같은 암호 해시 함수에 의해 계산된다. 이것은 약간 적은 계산 오버헤드로 동일한 보안을 제공한다. 공유된 비밀 및 보안 스토리지에 대한 요구가 본 실시예를 주장한다. 예를 들면, 단계 S15의 문맥에서 설명한 하위 실시예에서 약술한 바와 같이, 암호 해시(CH)를 단계 S11에서 사용된 암호화 대신에 사용할 수 있다:
N_T = CH_{K_T}(hash).
이것은 또한 단계 S41 또는 S44에서와 같은 다른 용도의 암호화에 적용된다.
다른 트랜잭션 인증 번호(TAN)을 가지는 실시예들
이 실시예에서, 개인 식별 코드(PIN_U)는 단계 S4 후에, 단계 S14 또는 S21의 문맥에서 앞서 설명한 바와 같이(도 4), 입력된다. 그 후, 키 암호 다이제스트 값, 예컨대 암호 해시가 개인 식별 코드로부터 그리고 통신 단말기(1)와 서버(4) 사이에 교환된 보안 세션 설정 프로토콜 메시지로부터 생성된다. 보안 목적이 아닌 프로토콜의 흐름에서, 이 단계에서 일련 번호(SN_T)를 포함하는 것도 유용할 수 있다. 키 암호 다이제스트 값은 키 암호 다이제스트 함수, 예컨대 서버(4)와 비밀 공유된 (해시)키로서 사용하는 이른바 "키 해시 함수"로 생성된다. 실시예에 따라 서, (해시)키로서 사용되는 것은, 토큰키(K_T), 개인 식별 코드(PIN_U), 또는 보안 세션 설정 프로토콜에서 세션키를 설정하기 위한 근거로서 사용된 프리 마스터 시크릿(pre-master-secret)이다. 구체적으로는, 개인 식별 코드(PIN_U)가 잘 선택된 비밀이면, 개인 식별 코드(PIN_U)는 (해시)키로서 사용될 수 있다. 이로써, 인증 토큰 디바이스(20)는 자신의 비밀 토큰키(K_T) 또는 개인 서명키(k-1) 또는 이 모두를 가지는 것으로부터 면제되어, 인증 모듈(2) 또는 인증 토큰 디바이스(20)는 각각, "신뢰받는 관찰자"일 뿐이다. 서버(4)는, 인증된 SSL 세션 내에서 "많은 현금을 xyz에게 송금하라"와 같은, 임의의 애플리케이션 레벨 명령어가 들어오는지 여부를 즉시 검출할 수 있다.
예를 들면, 단계 S5에서, 통신 단말기(1)에 의해 서버(4)와 교환된 보안 세션 설정 프로토콜 메시지로부터 생성된 데이터 세트(해시)와, 개인 식별 코드(PIN_U)를 인증 모듈(2) 또는 인증 토큰 디바이스(20)에 각각 전달한다. 단계 S6에서, 증명 모듈(25)이 데이터 세트(해시) 및 개인 식별 코드(PIN_U)로부터 암호 해시를 생성한다. 단계 S6에서의 전자 서명의 생성은 선택적이다. 단계 S7에서, (전자 서명이 있거나 없는) 암호 해시를 통신 단말기(1)에 전달한다. 이 하위 실시예에서, 또한 개인 식별 코드(PIN_U)는 단계 S6에서 사용자에 의해 인증 토큰 디바이스(20)에 입력될 수 있을 뿐이다.
다르게는, 암호 해시는 단계 S4에서 개인 식별 코드(PIN_U)로부터 그리고 통신 단말기(1)와 서버(4) 사이에 교환된 보안 세션 설정 프로토콜 메시지로부터 생성된다. 그 결과, 단계 S4에서 모든 필요한 단계가 수행되기 때문에, 단계 S5 내 지 S7은 생략된다.
단계 S8에서, 통신 단말기(1)는 단계 S3에서 수신된 인증 요청, 예를 들면 SSL/TLS에 따른 "CertificateVerify" 메시지에 대해, 단계 S6 또는 S4에서 각각 생성된 암호 해시 및 사용자에 의해 확인되거나 새로이 입력된 사용자 식별자(ID_U)를 포함하는, 응답을 준비한다.
단계 S10에서, 서버(4)는, 서버(4)에 저장된 사용자의 개인 식별 코드를 사용하여 암호 해시를 생성하고, 서버(4)에서 생성된 암호 해시와 단계 S9에서 통신 단말기(1)로부터 수신된 암호 해시의 비교에 기초하여 사용자의 진정성(authenticity)을 검증한다. 검증 결과가 긍정적이면, 통신 단말기(1)는 예를 들면 서버(4)에 대한 액세스를 제공받는다. 이와 같이, 암호 해시는 전술한 트랜잭션 인증 번호에 대한 대안 데이터 요소로서 생성, 교환 및 검증된다.
서버(4)가 사용자에게 인증받아야 하는 경우, 서버(4)는 단계 S41에서 계속된다. 하지만, 추가적인 하위 실시예에서, 서버 인증 코드(A_T)는 단계 S4-S6 후에 즉시 디스플레이된다.
외부 질의/응답 디바이스를 가지는 실시예들
본 바람직한 실시예에서, 인증 모듈(2)은 도 7 및 도 10에 나타낸 바와 같이, 통신 단말기(1) 내의 프로그램된 소프트웨어 모듈들에 의해 배타적으로 구현된다. 단계 S1, S2, S3, S4, S6, S8, S9, S10, 및 S11은, 도 4를 참조하여 앞서 설명한 바와 같이 필수적으로 실행된다. 단계 S11의 일부로서, 인증 베이스 번 호(N_T)를 디스플레이(11) 상에 표시한다. 하위 실시예에서, 인증 모듈(2)은 신뢰받는 관찰자로서만 작용하고, 인증 베이스 번호(N_T)는 프로토콜 메시지로부터, 예컨대 정규 CerticateVerify 메시지로부터 생성된 데이터 세트의 단축 파생물(short derivative)(예컨대, 6 또는 8자리)이다. 실질적으로, 인증 베이스 번호(N_T)는 부당 이용 가능한 방식으로는 중간자(MITM)에 의해 결정될 수 없는 기타 세션 관련 식별자일 수 있으며, 예를 들면 세션키 및 서버 공개키의 단축 다이제스트는 중간자(MITM) 공격을 방지하는 보안 세션 식별자인 인증 베이스 번호(N_T)를 계산하는 다른 방식일 수 있다. 외부에서 관찰 가능한 핸드세이크 메시지의 전체 시퀀스, 또는 "finished" 메시지나 암호화된 "Finished" 메시지의 해시는, 이 세션 관련 식별자(각각 N_T 또는 N_T")를 구성하기 위한 다른 후보들이고, 더욱 자세한 것은 후술한다. 이 실시예에서, 세션 관련 식별자(N_T)를 구축하기 위해 비밀 토큰키(K_T)를 구비하는 것은 따라서 선택적이다. 마찬가지로, 개인 서명키(k-1)도 선택적일 수 있다.
그 후, 도 10에 나타낸 바와 같이, 단계 S51에서, 사용자는 (클라이언트 측에서 생성된 질의인) 인증 베이스 번호(N_T) 및 (예컨대, 코드 또는 생체인식 데이터인) 자신의 개인 식별 코드(PIN_U)를 통신 단말기(1)에 접속되어 있지 않은 종래의 C/R 토큰 디바이스(5)에 입력한다. 단계 S52에서, 단계 S51에서 입력된 값들에 반응하여, C/R 토큰 디바이스(5)는 자신의 로직에 기초하여 토큰 응답값을 생성하여 디스플레이한다. 단계 S53에서, 단계 S14 및 S15 대신에, 사용자는 C/R 토큰 디바이스(5)로부터의 토큰 응답값을 트랜잭션 인증 번호로서 통신 단말기(1)에 입 력한다.
단계 S54에서, 단계 S12에서 수신된 요청에 응답하여, 통신 단말기(1)는 트랜잭션 인증 번호(TAN)로서 이전에 입력된 토큰 응답값을 서버(4)에 송신한다.
실질적으로, 단계 S17 내지 S20은 도 4 또는 도 7을 참조하여 앞서 설명한 바와 같이 서버(4)에 의해 각각 수행되지만; C/R 토큰 디바이스(5)의 로직에 대응하여, 서버(4)는 트랜잭션 인증 번호(TAN)로서 토큰 응답값을 생성하고 검증한다. 트랜잭션 인증 번호, 즉 토큰 응답값의 검증 결과가 긍정적이면, 통신 단말기(1)는 서버(4)에 대한 액세스를 제공받거나, 또는 일 실시예에서, 도 8 또는 도 9에 각각 나타낸 바와 같이, 서버(4)는 단계 S41에서 계속된다.
예를 들면, C/R 토큰 디바이스(5)는 수백만 개의 은행카드 및 신용카드에 쓰이고 있는 EMV 칩들(Europay International, MasterCard International 및 Visa International)에 기초한다(http://www.emvco.com 참조). EMV 칩들에 의해 생성된 일부 토큰 응답값은 개인 식별 코드(PIN_U)를 포함하지 않는다. 마스터카드 칩 인증 프로그램(MasterCard Chip Authentication Program, CAP)에 따른 카드 ICC는, 이전의 토큰키(K_T)와 유사한 역할을 하는 키를 서버(발행자)와 공유한다. 개인 식별 코드(PIN_U) 및 질의(인증 베이스 번호(N_T))을 정확하게 입력한 후에, 암호(일반적으로 3DES를 가짐)는 그 중에서 다른 것(예컨대, CVV), 질의(challenge), 및 정확한 개인 식별 코드(PIN_U)가 제공되었다는 권위 있는 확인(autoritative confirmation)을 포함하도록 생성될 것이다. 일반적으로, 숫자 키패드와 접속되어 있지 않은 판독기는 인증 베이스 번호(N_T)와 개인 식별 코드(PIN_U)를 입력하기 위해 사용되고, 토큰 응답값은 접속되어 있지 않은 판독기의 디스플레이 상에 디스플레이된다. 인증 베이스 번호(N_T''')가 4자리 또는 6자리로 단축되어 있는 경우, 예를 들면 중간자(MITM)가, 서버와 중간자(MITM) 사이에 공개된 첫 번째의 부정 세션(primary fraudulent session)과 충돌하는 단말기 상의 클라이언트와 두 번째의 부정 세션(secondary fraudulent session)을 설정할 수 있는 가능성이 상당히 증가한다. 여기서, 짧은 데이터 세트(해시)가 인증 베이스 번호(N_T''')에 대한 입력에 의존한다. 중간자(MITM)는 어느 당사자에게도 무충돌에 대한 추측(non-colliding guess)을 알리지 않고, 충돌이 발견되었는지 여부를 대개는 오프라인으로 검증할 수 있을 것이다. 이러한 공격을 방지하기 위해, "단축(shortening)" 알고리즘은 중간자(MITM)에게 완전히 공지된 단순한 해싱 함수 또는 단방향 다이제스트 함수이어서는 안되며, 추가적인 특징이 있어야 한다. 기본적으로, "세션 인식"의 오프라인 추측은, C/R 토큰 디바이스(5)를 사용하는 경우에 임의의 타입의 공격을 위해 개인 식별 코드(PIN_U)를 오프라인 추측할 때 중간자(MITM)에게 매력적이지 않을 것이 요구된다. 이것은 단축된 해시들에서의 충돌의 발견이 더 이상 오프라인에서 검증 가능하여서는 안 되고, 온라인 기관(online autority), 즉 추측 횟수를 제한하는 서버로의 교체를 요구하여야 한다는 것을 의미한다.
사용자보다 높은 엔트로피(entropy)를 가져서 패스워드로서 기억하는 것으로 예상될 수 있는, C/R 토큰 디바이스(5)의 대칭키는 암호화를 통해 중간자(MITM)에게 의사 랜덤 선택기를 숨기기 위해 사용된다. 이것은 중간자(MITM)로 하여금 거의 불가능한, 완전한 36 바이트 길이의 해시(데이터 세트)에 대한 충돌을 발견하게 한다.
따라서, 일 실시예에서, 단계 S11의 일부로서, 클라이언트 측에서, 예컨대 클라이언트 애플리케이션(예컨대, 브라우저)의 일부인 인증 모듈(2)이 짧은 난수, 예컨대 4자리 숫자를 생성하고, "임의 선발 숫자(random picking digit)"라고 한다. 이 난수는 프로토콜 메시지들로부터 생성된 데이터 세트로부터, 예를 들면 TLS 핸드세이크의 "CertificateVerify" 또는 "Finished" 메시지의 36 바이트 해시로부터 임의의 비트를 선발하는데 사용되며, 임의의 비트는 예를 들면 다른 4자리 숫자를 나타낸다. 그 후, 후자의 4 자릿수와 "임의 선발 숫자"는, 예를 들면 8자리의 단축된 인증 베이스 번호(N_T''')로서 디스플레이(11) 상에 사용자에게 표시된다. 단계 S51에서, 도 10을 참조하여 전술한 바와 같이, 사용자는 (클라이언트 측에서 생성된 질의인) 이 인증 베이스 번호(N_T''') 및 자신의 개인 식별 코드(PIN_U)를 C/R 토큰 디바이스(5)에 입력한다. 단계 S52 내지 S54는, 도 10의 문맥에서 전술한 바와 같이 그대로이다.
중간자(MITM)에게 알려져 있지 않은 "임의 선발 숫자"를 위해, C/R 토큰 디바이스(5) 상의 알고리즘은 "임의 선발 숫자"를 암호화된 형태로 서버(4)에 전송하도록 개조된다. 이것은, 트랜잭션 인증 번호로서 C/R 토큰 디바이스(5)에 의해 생성된 토큰 응답값이 암호화된 형태의 "임의 선발 숫자"를 포함한다는 것을 의미한다. 그 결과, 서버(4)는 수신한 응답으로부터 "임의 선발 숫자"를 복원하도록 구성된다. 3DES(또는 예컨대 블록 길이가 64 비트인 다른 암호 방식)을 예로 들면, 응답은 64비트이다. 예를 들면, 응답의 경우, 32자의 영숫자 문자 세트가 허용되 므로, 응답의 길이는 13자가 될 것이다. 그 결과, 사용자는 13자의 영숫자 문자를 C/R 토큰 디바이스(5)로부터 클라이언트 애플리케이션에, 예컨대 브라우저 양식 필드에 복사하여야 할 것이다. 사용자가 일반적으로 19자리의 신용 카드 번호(CVV 포함)를 타이핑하는 것에 비추어서, 질의를 위한 8자리 숫자에 더해 응답을 위한 13자를 타이핑하는 것은 유용성의 견지에서 만족스러운 것으로 생각된다. 이 방법의 보안은 질의 및 응답의 길이에 비례하여 증가 또는 감소한다.
서버 측에서, 비밀 토큰키(K_T)를 사용하여 "임의 선발 숫자"를 해독한 다음, 데이터 세트(해시)로부터 단축된 입력을 선발하기 위해 사용하여 단축된 인증 베이스 번호(N_T''')를 계산하도록 단계 S18를 변경한다. 다른 모든 것은 이전 그대로이다.
추가적인 실시예로서, 인증 베이스 번호(N_T)는, 사용자가 키보드에 타이핑하는 것이 아니라, 예를 들면 http://axsionics.ch에 기재되어 있는 것처럼 그래픽 깜박임(graphical flickering)과 같은 다른 수단을 통해 디바이스에 입력된다. 중요한 향상은, 일반적으로 서버에 의해 전적으로 생성되는 깜박임 질의(flickering-challenge)를 몇몇 클라이트 측에서 생성된 보안 세션 식별자에 의해 수정하여야 한다는 것이다. 이 깜박임 방법의 구현은, 브라우저(java, 자바) 플러그인, Flash(플래시) 또는 javascipt(자바스크립트)와 같은, 일부 클라이언트 측의 능동 구성요소(active component)를 가지는 것이 바람직하므로, 일부 실시예에서, 능동 구성요소는 예를 들면 서버의 공개키 및 세션키 또는 다른 타입의 보안 세션 식별자의 다이제스트를 검색하기 위해 사용될 수 있고, 또 깜박이는 이미지 생성, 즉 관련된 프로토콜의 질의에 능동 구성요소를 포함하기 위해 사용될 수 있다. 이 능동 구성요소는 서명되는 것이 바람직한데, 그렇지 않으면 중간자(MITM)가 클라이언트 통신 단말기(1)에서 진정하게 생성된 인증 베이스 번호(N_T) 대신에 중간자(MITM)의 인증 베이스 번호(N_T)를 제공할 수 있는 이것의 변경된 버전을 쉽게 삽입할 것이기 때문이다.
추가적인 하위 실시예에서("핸드세이크 동안에 클라이언트 인증서를 인증하지 않음"), 통신 단말기(1)의 클라이언트 애플리케이션 소프트웨어 모듈, 예를 들면 브라우저는, 보안 세션 설정 프로토콜 스택에 대한 판독 전용 액세스를 통해 또는 심지어 프로토콜 메시지를 "아웃사이더(outsider)"로서 감지(sniff)/포착(capture)할 수 있도록 함으로써, 중간자(MITM)의 공격을 방지하는, 보안 세션 식별자로서 인증 베이스 번호(N_Tiv)를 계산하도록 구성된 인증 번호 생성기(26)를 구비한다. 이와 같이, 이 하위 실시예에서는, 클라이언트 인증서 인증을 수행할 필요가 없고, 즉 일방적인 보안 세션을 위한 단계 S3 내지 S10를 수행할 필요가 없고, MS-CAPI 또는 PKCS11와 같은 토큰 디바이스 드라이버도 더 이상 필요없다.
앞서 언급한 인증 번호 생성기(26)는, 단계 S11에서, 아래에 약술하는 바와 같이, 중간자(MITM) 공격을 방지하는, 보안 세션 식별자로서 인증 베이스 번호(N_Tiv)를 생성하도록 구성되어 있다:
a) 통신 단말기(1)와 서버(4) 사이에 교환된 보안 세션 설정 프로토콜 메시지에 기초한, 데이터 세트(해시)에 기초하여, 중간자(MITM)에 의해 알려질 수 없 는(예컨대, 암호화되기 이전의 입력으로서 프리마스터 시크릿(premaster-secret)을 가지는 것에 기인함) 인증 베이스 번호(N_Tiv)를 생성한다; 또는
b) 본 실시예서는 클라이언트 애플리케이션에서의 비밀 토큰키(K_T)에 대한 요구를 방지해야 하기는 하나, 알려진 입력 데이터 및 비밀키로부터 인증 베이스 번호(N_Tiv)를 생성한다; 또는
c) 중간자(MITM)에게도 모두 알려져 있는 입력 데이터에 기초하여 인증 베이스 번호(N_Tiv)를 생성하지만, 보안 세션 설정 프로토콜에 대한 논리적 접속에 의해, 중간자(MITM)에 대한 저지를 보증한다. 본 실시예에서는 서버의 공개키와 신규성(freshness)을 보증하는 어떤 것(임시값 또는 타임스탬프(timestamp))을 사용하는 것으로 충분할 것이다. 예를 들면, 암호화된 프리마스터 시크릿의 해시, 즉 중간자(MITM)에 의해 관찰 가능한 메시지는 그러한 임시값으로서 사용될 수 있다. 이 경우에, C/R 토큰 디바이스의 로직이 질의를 알고 응답을 관찰함으로써, 중간자(MITM)가 (오프라인) PIN 추측 공격을 개시할 수 없다는 것을 보증하는 것이 중요하다.
예를 들면, 인증 번호 생성기(26)는 클라이언트 애플리케이션에서 이 중간자(MITM) 방지 보안 인증 베이스 번호(N_Tiv)(질의)를 디스플레이하도록 구성된다. 예를 들면, 인증 번호 생성기(26)는 사용자가 규정된 영역에서, 예컨대 브라우저의 하부 오른쪽에서 질의를 볼 수 있도록 해주며, 사용자가 마우스의 포인터를 이 영 역 위로, 예컨대 브라우저의 고정 디스플레이 영역(lock displayed) 위로 이동한 때 볼 수 있도록 해준다.
전술한 바와 같이, 사용자는 인증 베이스 번호(N_Tiv)(질의로서) 및 자신의 개인 식별 코드(PIN_U)를 C/R 토큰 디바이스에 입력하며, 본 방법은 전술한 바와 같이 속행한다.
비밀키는 없지만 클라이언트 측에 임시값을 가지는 실시예들
Request for Comments 2246에 약술되어 있는 바와 같이, PKCS1 부호화된 서명 대신에 임의의 응답을 가지는 CertificateVerify 메시지의 구조를 오버로딩(overloading)할 가능성이 있다. 이것은 토큰이 비밀 토큰키(K_T)를 더 이상 필요로 하지 않을 가능성을 제공한다. 본 실시예에서, 전술한 "대안 트랜잭션 인증 번호(TAN)}를 가지는 실시예들"과 유사하게, 단계 S6에서, 인증 모듈(2) 또는 인증 토큰 디바이스(20)는 각각, 해시(데이터 세트), 개인 식별 코드(PIN_U), 및 추가로 공개키(k_S)("한 번 사용되는 번호"인 임시값)를 가지는 한 개 또는 두 개의 정당한 난수 임시값(N-Tt)(및 N_Ta)을 암호화함으로써 암호를 생성한다. 공개키(k_S)는, 이번에는, 중간자(MITM)가 자신의 키(k_MITM)를 사용하여 시스템을 속이는 것을 방지하기 위해, 인증 모듈(2) 또는 인증 토큰 디바이스(20) 각각에 미리 설치되어야 한다. 공개키(k_S)는 서버(4) 또는 복수 기관의 경우(인증 서버가 공개키(k_AS)와 연관되어 있음)에 인증 서버(AS) 중 어느 하나에 속한다. 선택적으로, 암호의 입력값은 공개키(k_(A)S)로 암호화되기 이전에 비밀키(k-1)로 서명된다. 마찬가지로, 하부 실시예의 단계 S15에 따라, 암호화 이전에 암호 해시 함수(HMAC)를 적용할 수 있다.
단계 S7-S9에서, "전자 서명"을 송신하는 대신에, 대부분의 "보안 세션 설정 프로토콜"에 의한 요구에 따라, 이 암호는 프로토콜 명세(protocol specification)에 의해 부가된 어떠한 제한도 없는, 비구조화 데이터(unstructured data)로서 송신된다. 구현 시에, 다른 프로토콜 부분들은 또한 인증 토큰 디바이스(20)에서 실행되고 통신 단말기(1)의 클라이언트 애플리케이션에서 실행되지 않는 경우- 예를 들면 세션키의 생성- "ClientKeyExchange"와 같은 다른 프로토콜 메시지들은 암호를 송신하기 위해 사용될 수 있었다.
단계 S10에서, 서버(4)는 암호를 해독한다. 이것은 서버에 임시값(N_Tt), 개인 식별 코드(PIN_U), 및 어쩌면 임시값(N_Ta)을 제공할 것이다. 임시값(N_Tt)은 PIN 추측 공격을 방지하기 위해 방지제(salt)로서 부가되는, "사용 후 버리는(throw-away)" 임시값이다.
단계 S10에서, 서버(4)는 또한 단계 S4의 문맥에서 설명한 바와 같이 "해시"를 생성한다. 단계 S11-S17은 필요 없다.
단계 S18-S20에서, 인증 모듈(40)은 인증 베이스 번호(N_T) 및 트랜잭션 인증 번호(TAN)를 더 이상 생성하지 않고, 해시와, 단계 S10에서 해독된 개인 식별 코드(PIN_U)를 단순히 비교한다. 암호부터 얻은 해시는 서버(4)에서 생성된 해시와 비교되고, 개인 식별 코드(PIN_U)는 데이터베이스(41)에 저장된 개인 식별 코 드(PIN_U)와 비교된다. 단계 S6에서 암호 해시 함수가 사용되면, 먼저 이 값들도 비교 이전에 서버 측에서 암호 방식으로 해싱(hashing)되어야 할 필요가 있다. 다른 모든 것은 그대로 동일하다. 암호 또는 암호 해시는 각각, 전술한 트랜잭션 인증 번호(TAN)에 대한 대안 데이터 요소로서 생성, 교환 및 검증된다.
또한 서버(4)가 사용자에 대해 서버(4)를 인증하여야 하면, 단계 S41 내지 S43의 계산 대신에, 서버(4)는 단순히 암호로부터 해독된 임시값(N_Ta)을 사용자에게 디스플레이한다. 단계 S44 내지 S46의 비교는 그대로 동일하고; 계산은 필요 없으며, 디스플레이(22) 상에 임시값(N_Ta)을 단순히 디스플레이한다.
또한 이 실시예에 대한 부가사항으로서, 개인 식별 코드(PIN_U)를 변경하기 위한 프로토콜이 구현될 수 있다. 새로운 개인 식별 코드(PIN_U)는 단순히 단계 S6의 암호에 대한 다른 입력이다.
보안 세션 설정 프로토콜 표준이 그 프로토콜 필드들에 대해 고정된 필드 길이를 명시하지 않는다는 사실에도 불구하고, 일부 클라이언트 애플리케이션의 구현예는 예를 들면 "Certificate Verify" 메시지에 대해, 할당되는 메모리를 엄격하게 제한할 수 있다. 이러한 경우에, 타원 곡선 암호 작성법(elliptic curve cryptography)과 같은, 공간 최적화 공개키 암호 작성법(space optimizing public key cryptography)에 대한 집중이 요구된다.
또한 본 실시예의 하위 실시예는 사용자에 의해 개인 식별 코드(PIN_U)가 계산된다. 이를 위해, 단계 S6에서, 개인 식별 코드(PIN_U)는 생략된다. 임시값(N_Tt)은 단계 S31에서 설명한 바와 같이 사용자에게 디스플레이되며, 트랜잭션 인증 번호(TAN)는 단계 S32에서 설명한 바와 같이 계산된다. 전술한 바와 같이 인증 베이스 번호(N_T)와 개인 식별 코드(PIN_U)로부터 트랜잭션 인증 번호(TAN)를 생성하는 다른 변형예들이 인증 베이스 번호(N_T)에 대해 비슷하게 적용될 수 있다.
짧은, (가급적 일회용의) 비밀키를 가지는 실시예들
스크래치 리스트(scratch-list) 또는 인덱싱된 스크래치 리스트(예를 들면, "iTAN", "인덱싱된 스크래치 리스트", "Access Card(액세스 카드)")와 같은 코드(또는 키) 테이블은 금융 기관에 의해 널리 사용되지만, 이들은 중간자 공격에 취약하다. 위의 "비밀키는 없지만 클라이언트 측의 임시값을 가지는 실시예들"은 "이중 요소" 인증의 레벨을 달성하도록 확장될 수 있다.
단계 S6a(도 4, 5, 6, 및 7에서는 단계 S6으로 나타냄): 액세스 카드가 예를 들어 100개의 엔트리, 즉 일반적으로 4-6개의 숫자로 이루어진 짧은 "키"들(K_SSU)을 가지고 있으면, 단계 S4에서 생성된 데이터 세트(이전 핸드세이크 메시지의 해시)는 액세스 카드의 키 테이블에 대한 룩업 인덱스로서 사용될 수 있을 때까지 압축된다.
단계 S6b에서(도 4, 5, 6, 및 7에서는 단계 S6으로 나타냄), 압축된 값-일반적으로 문자 2개의 길이임-이 인덱스(예를 들면 인증 모듈(2) 또는 인증 토큰 디바이스(20)에 의해)로서 디스플레이된다. 룩업 인덱스를 클라이언트 애플리케이션에 전달하는 다른 방법도 있으며, 예를 들면 "숨겨진 채널(hidden channel)"인 앞서 언급한 ""DistinguishedName certificate_authorities" 리스트는, 인증 모듈(2) 또는 인증 토큰 디바이스(20) 각각이, 단계 S6b에서 디스플레이하는 인덱스가 무엇인지를 알도록 하는 다른 방법을 나타낼 수 있다.
단계 S6c에서(도 4, 5, 6, 및 7에서는 단계 S6으로 나타냄), 단계 S6에서 이전에 입력된 값들 외에, 또한 세션에서 얻은(session-derived) 룩업 인덱스에 의해 검색된 키(K_SSU)가 입력된다. 임시값(N_Tt)의 고도의 무작위성(randomness)으로 인해, 키(K_SSU)는 몇 번 사용될 수 있다. 클라이언트 애플리케이션이 보안 세션 설정 프로토콜 메시지 내의 일반 메시지(특히, CertificateVerify 메시지)보다 긴 암호의 전송을 허용하지 않으면, "트랜잭션 인증 번호(TAN)가 없는 실시예들"에 기초한 또 다른 실시예가 존재하며, 상기한 내용들은 다음의 단계들에 의해 확장된다:
단계 S6a은 전술한 바와 같이 그대로이다. 임시값(N_Tt)의 무작위성을 이용할 수 없기 때문에, 키(K_SSU)는 한 번만 사용될 수 있다. 단계 S6b'(단계 S6b를 대체함)에서, 서버(4)는 지금까지 사용된 모든 룩업을 기록한다. 충돌이 존재하면, 서버(4)에 의해 핸드세이크가 다시 트리거된다. 이것은 미사용 인덱스에 도달될 때까지 반복된다. 이 경우에 "DistinguishedName certificate_authorities" 법이 더욱 효율적일 수 있다. 일정한 레벨 사용한 후, 새로운 액세스 카드가 대역외(out-of-band)에 배포된다.
단계 S6c'에서(단계 S6c를 대체함), 암호 해시는 임시값을 가지지 않고 비밀키(K_T) 대신에 생성되며, 키(K_SSU)가 사용된다. 그런 다음, 그 후의 단계들은 단계 S15까지 그대로이다. 단계 S15에서, 키(K_SSU)는 짧기 때문에, 암호 해시 함수는, 유효 암호 해시 N_SSU = CH_{K_SSU}(hash, PIN_U)를 한 쌍의 개인 식별 코드(PIN_U)와 키(K_SSU)에 의해 취득할 수 없을 뿐 아니라, 많은 쌍의 개인 식별 코드(PIN_U)와 키(K_SSU)-최대 개인 식별 코드(PIN_U)와 키(K_SSU) 모두의 조합된 "키공간(key-space)"의 크기-에 의해서도 취득할 수 없도록 하는 것이 중요하다. 이로써, 공격자는 추측 공격에서 정확한 개인 식별 코드(PIN_U)를 찾아냈는지를 알지 못할 것이지만, 항상 자신의 추측을 확인하기 위해 서버(4)에 암호 해시(N_SSU)를 제공하여야 할 것이다. 또한, 해시의 길이는 일반적으로 40 바이트이므로, 추측 사전(guessing dictionary)은 이 조합된 키- 세션을 인증에 결합하는 상부에 있음, 여기서 이 해시는 "방지제(salt)"로서 사용됨-보다 훨씬 더 길어야 한다. 추측 공격이 일반적인 서버 측의 로그인 타임아웃보다 더 오래 걸리도록, 이 키공간이 충분한 엔트로피를 가지면, 이것은 저가의 해결책(low-end solution)으로서 사용될 수 있다.
개인 식별 코드(PIN_U)에 대한 키 로깅(logging) 공격을 방지하기 위해, 개인 식별 코드(PIN_U)와 키(K_SSU)를 개별로 단말기에 입력하는 대신에, 그 조합을 대신 입력할 수 있다.
마찬가지로, 키(K_SSU)는 또한 트랜잭션 인증 번호(TAN)들에 기초하여 전술한 주요 실시예 및 다른 실시예와 함께 사용될 수 있다.

Claims (47)

  1. 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자를 인증하는 사용자 인증 방법으로서,
    상기 사용자로부터 개인 식별 코드(personal identification code)를 수신하는 단계;
    상기 통신 단말기와 상기 서버 사이에 교환된 보안 세션 설정 프로토콜 메시지(secure session establishment protocol message)로부터, 데이터 세트를 생성하는 단계;
    상기 개인 식별 코드를 사용하여, 상기 데이터 세트에 기초하여 트랜잭션 인증 번호를 생성하는 단계;
    상기 통신 단말기로부터 상기 서버에 상기 트랜잭션 인증 번호를 송신하는 단계;
    상기 서버에서, 상기 통신 단말기와 교환된 상기 보안 세션 설정 프로토콜 메시지에 기초하여 상기 트랜잭션 인증 번호를 검증하는 단계
    를 포함하는 사용자 인증 방법.
  2. 제1항에 있어서,
    상기 통신 단말기와 연관된 인증 모듈에서, 상기 데이터 세트로부터 인증 베이스 번호를 생성하는 단계로서, 상기 트랜잭션 인증 번호는 상기 개인 식별 코드 를 사용하여 상기 인증 베이스 번호로부터 생성되는, 상기 인증 모듈에서 인증 베이스 번호를 생성하는 단계; 및
    상기 서버에서, 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 인증 베이스 번호를 생성하는 단계
    를 더 포함하고,
    상기 트랜잭션 인증 번호는, 상기 서버에서 생성된 상기 인증 베이스 번호를 사용하여, 상기 서버에서 검증되는, 사용자 인증 방법.
  3. 제2항에 있어서,
    상기 통신 단말기에 접속되어 있지 않은 질의/응답(challenge/response, C/R) 토큰 디바이스(token device)에, 상기 인증 베이스 번호 및 상기 개인 식별 코드를 입력하는 단계; 및
    상기 서버에 상기 트랜잭션 인증 번호를 송신하기 이전에, 상기 통신 단말기에 상기 트랜잭션 인증 번호를 입력하는 단계
    를 더 포함하고,
    상기 트랜잭션 인증 번호는, 상기 인증 베이스 번호 및 상기 개인 식별 코드에 기초하여 토큰 응답값으로서 상기 질의/응답 토큰 디바이스에서 생성되는, 사용자 인증 방법.
  4. 제2항 또는 제3항에 있어서,
    상기 데이터 세트로부터 상기 인증 베이스 번호를 생성하는 단계는,
    난수를 생성하는 단계,
    상기 난수의 숫자(digit)들에 의해 결정되는 선택된 숫자들을 상기 데이터 세트로부터 선택하는 단계, 및
    상기 선택된 숫자들 및 상기 난수의 숫자들로부터 상기 인증 베이스 번호를 구성하는 단계
    를 포함하는, 사용자 인증 방법.
  5. 제1항에 있어서,
    상기 트랜잭션 인증 번호는, 상기 통신 단말기와 연관된 인증 모듈에서, 상기 개인 식별 코드 및 상기 통신 단말기와 상기 서버 사이에 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 키 암호 다이제스트 값(keyed cryptographic digest value)으로서 생성되고, 상기 서버와 비밀리 공유된 키로서 사용하며,
    상기 방법은, 상기 서버에서, 상기 서버에 저장된 개인 식별 코드를 사용하여 상기 키 암호 다이제스트 값을 생성하는 단계를 더 포함하고;
    상기 트랜잭션 인증 번호는, 상기 통신 단말기로부터 수신된 키 암호 다이제스트 값과 상기 서버에서 생성된 키 암호 다이제스트 값의 비교에 기초하여 상기 서버에서 검증되는, 사용자 인증 방법.
  6. 제5항에 있어서,
    상기 개인 식별 코드와 상기 인증 모듈과 연관된 비밀 토큰키 중 하나를 키로서 사용하는, 사용자 인증 방법.
  7. 제5항에 있어서,
    상기 데이터 세트로부터 룩업 인덱스(lookup index)를 생성하는 단계; 및
    상기 룩업 인덱스를 사용하여, 코드 테이블에서 선택되는 코드를 결정하는 단계를 더 포함하며,
    상기 선택된 코드는 키로서 사용되고,
    상기 서버는, 상기 서버에 저장되어 있는 코드 테이블로부터 선택되는 코드를 상기 키로 사용하여 상기 키 암호 다이제스트 값을 생성하는, 사용자 인증 방법.
  8. 제7항에 있어서,
    상기 서버는 상기 통신 단말기에 의해 사용된 선택된 코드들에 대한 추적을 계속하고;
    상기 서버는, 선택된 코드가 상기 통신 단말기에 의해 이전에 사용되었던 것으로 판정한 경우에, 상기 통신 단말기와의 세션 설정을 다시 개시하는, 사용자 인증 방법.
  9. 제1항에 있어서,
    상기 트랜잭션 인증 번호는, 상기 통신 단말기와 연관된 인증 모듈에서, 공개키를 사용하여, 상기 데이터 세트, 상기 개인 식별 코드, 및 하나 이상의 임시값(nonce)을 암호화함으로써 암호(cryptogram)로서 생성되며;
    상기 방법은, 상기 서버에서, 개인키를 사용하여, 상기 암호를 해독함으로써 수신된 데이터 세트와 수신된 개인 식별 코드를 결정하는 단계를 더 포함하고;
    상기 트랜잭션 인증 번호는, 상기 서버에서, 상기 수신된 데이터 세트와 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 생성된 데이터 세트의 비교, 그리고 상기 수신된 개인 식별 코드와 상기 서버에 저장되어 있는 개인 식별 코드의 비교에 기초하여 검증되는, 사용자 인증 방법.
  10. 제9항에 있어서,
    상기 데이터 세트로부터 룩업 인덱스를 생성하는 단계; 및
    상기 룩업 인덱스를 사용하여 코드 테이블에서 선택되는 코드를 결정하는 단계를 더 포함하고,
    상기 선택된 코드는 상기 암호의 생성 시에 사용되며;
    상기 서버는 상기 개인키를 사용하여, 상기 암호로부터 상기 수신된 선택된 코드를 결정하고;
    상기 트랜잭션 인증 번호를 검증하는 단계는, 상기 수신된 선택된 코드와 상기 서버에 저장되어 있는 코드 테이블로부터 상기 서버에 의해 결정된 선택된 코드를 비교하는 단계를 포함하는, 사용자 인증 방법.
  11. 제10항에 있어서,
    상기 서버는 상기 통신 단말기에 의해 사용된 선택된 코드들에 대한 추적을 계속하고;
    상기 서버는, 선택된 코드가 상기 통신 단말기에 의해 이전에 사용되었던 것으로 판정한 경우에, 상기 통신 단말기와의 세션 설정을 다시 개시하는, 사용자 인증 방법.
  12. 제1항에 있어서,
    상기 트랜잭션 인증 번호와 사용자 식별자는 상기 통신 단말기로부터 상기 서버에 송신되고;
    상기 트랜잭션 인증 번호는 상기 사용자 식별자에 할당된 상기 개인 식별 코드를 사용하여 상기 서버에서 검증되는, 사용자 인증 방법.
  13. 제12항에 있어서,
    상기 개인 식별 코드는 생체인식 식별자(biometric identifier)와 함께 상기 사용자로부터 수신되고;
    상기 트랜잭션 인증 번호는, 상기 서버에 저장되어 있는 생체인식 식별자를 사용하여, 상기 서버에서 검증되는, 사용자 인증 방법.
  14. 제1항에 있어서,
    상기 통신 단말기와 연관된 인증 모듈에서, 상기 인증 모듈과 연관된 키 쌍(key pair) 중 개인키(private key)를 사용하여, 상기 데이터 세트로부터 디지털 서명(digital signature)을 생성하는 단계;
    상기 통신 단말기로부터 상기 서버에 상기 디지털 서명을 송신하는 단계; 및
    상기 서버에서, 상기 키 쌍 중 공개키(public key)를 사용하여 상기 디지털 서명을 검증하는 단계를 더 포함하는 사용자 인증 방법.
  15. 제2항에 있어서,
    상기 인증 베이스 번호는, 상기 통신 단말기와 연관된 인증 모듈에서 상기 데이터 세트로부터 생성되고; 또
    상기 인증 베이스 번호는, 상기 서버에서 비밀 토큰키(secret token key)를 사용하여, 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 생성되는, 사용자 인증 방법.
  16. 제15항에 있어서,
    상기 데이터 세트는, 상기 인증 모듈을 상기 통신 단말기에 접속하는 디바이스 인터페이스를 통해, 상기 통신 단말기로부터 상기 인증 모듈에 전송되며;
    상기 비밀 토큰키는 상기 인증 모듈에 저장되는, 사용자 인증 방법.
  17. 제16항에 있어서,
    토큰 식별자가 상기 통신 단말기로부터 상기 서버에 상기 트랜잭션 인증 번호와 함께 송신되고;
    상기 비밀 토큰키는 상기 토큰 식별자에 기초하여 상기 서버에서 결정되는, 사용자 인증 방법.
  18. 제17항에 있어서,
    마스터키가 상기 서버에 저장되어 있으며;
    상기 비밀 토큰키는, 상기 서버에서, 상기 토큰 식별자를 암호화하기 위한 상기 마스터키를 사용하여 상기 토큰 식별자로부터 생성되는, 사용자 인증 방법.
  19. 제15항에 있어서,
    상기 사용자는, 상기 인증 모듈에 대한 복수의 가능한 기관 범위(institution scope) 중 하나를 선택하고;
    상기 사용자에 의해 선택된 상기 기관 범위는, 상기 인증 모듈이 상기 인증 베이스 번호를 생성하기 위하여 복수의 비밀 토큰키의 세트 중에서 하나의 기관 특정(institution-specific) 비밀 토큰키를 사용하게 하며;
    상기 서버는, 특정한 기관과 연관되어 있고, 상기 인증 베이스 번호를 생성하기 위해 상기 기관 특정 비밀 토큰키를 사용하고;
    상기 서버는, 상기 트랜잭션 인증 번호를 검정하기 위해 기관 특정 개인 식 별 코드를 사용하는, 사용자 인증 방법.
  20. 제2항에 있어서,
    상기 인증 베이스 번호는 상기 통신 단말기와 연관된 상기 인증 모듈에 의해 디스플레이되고;
    상기 개인 식별 코드와 상기 인증 모듈에 의해 디스플레이된 상기 인증 베이스 번호로부터 상기 사용자에 의해 생성된 상기 인증 베이스 번호는, 상기 사용자로부터 상기 통신 단말기에 수신되는, 사용자 인증 방법.
  21. 제1항에 있어서,
    상기 서버에서 상기 트랜잭션 인증 번호의 성공적인 검증 후에, 상기 서버에서, 상기 데이터 세트에 공개 함수(public function)를 적용하고 암호화를 위해 비밀 토큰키를 사용하여, 상기 데이터 세트로부터 서버 인증 코드를 생성하고;
    상기 서버 인증 코드는 상기 서버로부터 상기 통신 단말기에 송신되며;
    상기 서버로부터 수신된 상기 서버 인증 코드는 상기 통신 단말기에 의해 디스플레이되고;
    상기 통신 단말기와 연관된 인증 모듈에서, 상기 데이터 세트에 상기 공개 함수를 적용하고 암호화를 위해 상기 비밀 토큰키를 사용하여, 상기 데이터 세트로부터 서버 인증 코드를 생성하며;
    상기 인증 모듈에서 생성된 상기 서버 인증 코드는, 상기 통신 단말기에 의 해 디스플레이된 상기 서버 인증 코드와 함께 시각적인 검증(visual verification)을 위해 상기 인증 모듈에 의해 디스플레이되는, 사용자 인증 방법.
  22. 통신 단말기가,
    사용자로부터 개인 식별 코드를 수신하고;
    상기 통신 단말기와 서버 사이에 교환되는 보안 세션 설정 프로토콜 메시지로부터, 데이터 세트를 생성하며;
    상기 개인 식별 코드를 사용하여, 상기 데이터 세트에 기초한 트랜잭션 인증 번호를 생성하고;
    검증을 위해 상기 서버에 상기 트랜잭션 인증 번호를 송신하도록,
    상기 통신 단말기의 하나 이상의 프로세서를 제어하는 컴퓨터 프로그램 코드 수단을 포함하는 컴퓨터 프로그램 제품.
  23. 제22항에 있어서,
    상기 통신 단말기가,
    상기 데이터 세트로부터 인증 베이스 번호를 생성하고;
    상기 개인 식별 코드를 사용하여, 상기 인증 베이스 번호로부터 상기 트랜잭션 인증 번호를 생성하도록,
    상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  24. 제23항에 있어서,
    상기 통신 단말기가,
    난수를 생성하고;
    상기 난수의 숫자들에 의해 결정되는 선택된 숫자들을 상기 데이터 세트로부터 선택하며;
    상기 선택된 숫자들 및 상기 난수의 숫자들로부터 상기 인증 베이스 번호를 구성하도록,
    상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  25. 제22항에 있어서,
    상기 통신 단말기가,
    상기 개인 식별 코드 및 상기 통신 단말기와 상기 서버 사이에 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 키 암호 다이제스트 값으로서 상기 트랜잭션 인증 번호를 생성하고, 상기 서버와 비밀리 공유되는 키로서 사용하도록, 상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  26. 제25항에 있어서,
    상기 통신 단말기가, 상기 개인 식별 코드와 비밀 토큰키 중 하나를 상기 키 로서 사용하도록, 상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  27. 제25항에 있어서,
    상기 통신 단말기가,
    상기 데이터 세트로부터 룩업 인덱스를 생성하고;
    상기 룩업 인덱스를 사용하여 코드 테이블에서 선택된 코드를 결정하며;
    상기 선택된 코드를 상기 키로서 사용하도록,
    상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  28. 제22항에 있어서,
    상기 통신 단말기가, 공개키를 사용하여, 상기 데이터 세트, 상기 개인 식별 코드, 및 하나 이상의 임시값을 암호화함으로써, 암호로서 상기 트랜잭션 인증 번호를 생성하도록, 상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  29. 제28항에 있어서,
    상기 통신 단말기가,
    상기 데이터 세트로부터 룩업 인덱스를 생성하고;
    상기 룩업 인덱스를 사용하여 코드 테이블에서 선택된 코드를 결정하며;
    상기 선택된 코드는 상기 암호의 생성 시에 사용하도록,
    상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  30. 제22항에 있어서,
    상기 통신 단말기가, 상기 통신 단말기의 센서를 통해 상기 사용자로부터 생체인식 식별자를 수신하고, 상기 생체인식 식별자를 개인 식별 코드로 사용하도록, 상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  31. 제23항에 있어서,
    상기 통신 단말기가, 복수의 가능한 기관 범위 중 하나를 선택하기 위한 명령어를 수신하고, 복수의 비밀 토큰키의 세트 중에서 하나의 기관 특정 비밀 토큰키를 사용하여 상기 인증 베이스 번호를 생성하도록, 상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  32. 제22항에 있어서,
    상기 통신 단말기가, 상기 서버로부터 서버 인증 코드를 수신하고; 상기 데이터 세트에 공개 함수를 적용하고 암호화를 위해 비밀 토큰키를 사용하여, 상기 데이터 세트로부터 서버 인증 코드를 생성하며, 생성된 상기 서버 인증 코드에 기초하여 상기 서버로부터 수신된 서버 인증 코드를 검증하도록, 상기 프로세서를 제어하는 컴퓨터 프로그램 수단을 더 포함하는 컴퓨터 프로그램 제품.
  33. 전기통신 네트워크를 통해 통신 단말기와 데이터를 교환하도록 구성된 컴퓨터화된 서버로서,
    사용자 인증 모듈을 포함하고,
    상기 사용자 인증 모듈은,
    상기 통신 단말기로부터, 상기 통신 단말기의 사용자로부터 수신된 개인 식별 코드 및 상기 통신 단말기와 상기 서버 사이에 교환된 보안 세션 설정 프로토콜 메시지로부터 생성된 데이터 세트에 기초하는, 트랜잭션 인증 번호를 수신하고;
    상기 통신 단말기와 교환된 상기 보안 세션 설정 프로토콜 메시지에 기초하여 수신된 상기 트랜잭션 인증 번호를 검증하도록, 구성되는
    서버.
  34. 제33항에 있어서,
    상기 사용자 인증 모듈은, 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 인증 베이스 번호를 생성하고, 생성된 상기 인증 베이스 번호 및 상기 개인 식별 코드를 사용하여 수신된 상기 트랜잭션 인증 번호를 검증하도록 구성되는, 서 버.
  35. 제34항에 있어서,
    상기 사용자 인증 모듈은, 난수를 생성하고, 상기 난수의 숫자들에 의해 결정되는 선택되는 숫자들을 상기 데이터 세트로부터 선택하며, 상기 선택된 숫자들 및 상기 난수의 숫자들로부터 상기 인증 베이스 번호를 구성함으로써, 상기 인증 베이스 번호를 생성하도록 구성되는, 서버.
  36. 제33항에 있어서,
    상기 사용자 인증 모듈은,
    상기 서버에 저장된 개인 식별 코드를 사용하여, 상기 개인 식별 코드 및 상기 통신 단말기와 상기 서버 사이에 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 키 암호 다이제스트 값으로서 트랜잭션 인증 번호를 생성하고, 상기 통신 단말기와 비밀리 공유되는 키로서 사용하며;
    수신된 상기 트랜잭션 인증 번호와 상기 서버에서 생성된 상기 키 암호 다이제트 값의 비교에 기초하여 수신된 상기 트랜잭션 인증 번호를 검증하도록 구성되는, 서버.
  37. 제36항에 있어서,
    상기 사용자 인증 모듈은, 상기 키 암호 다이제스트 값을 생성하는데, 상기 개인 식별 코드와 사용자와 연관된 비밀 토큰키 중 하나를 상기 키로서 사용하도록 구성되는, 서버.
  38. 제36항에 있어서,
    상기 사용자 인증 모듈은, 상기 키 암호 다이제스트 값을 생성하는데, 상기 서버에 저장된 코드 테이블로부터 선택된 코드를 상기 키로서 사용하도록 구성되는, 서버.
  39. 제33항에 있어서,
    상기 사용자 인증 모듈은,
    공개키를 사용하여, 상기 데이터 세트, 상기 개인 식별 코드, 및 하나 이상의 임시값을 암호화함으로써 암호로서 트랜잭션 인증 번호를 생성하고;
    개인키를 사용하여, 상기 통신 단말기로부터 수신된 암호를 해독함으로써 수신된 데이터 세트 및 수신된 개인 식별 코드를 결정하며;
    상기 수신된 데이터 세트와 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 상기 서버에서 생성된 데이터 세트의 비교, 및 상기 수신된 개인 식별 코드와 상기 서버에 저장된 개인 식별 코드의 비교에 기초하여, 수신된 상기 트랜잭션 인증 번호를 검증하도록 구성되는, 서버.
  40. 제39항에 있어서,
    상기 사용자 인증 모듈은,
    상기 개인키를 사용하여, 상기 통신 단말기로부터 수신된 상기 암호로부터 수신된 선택된 코드를 결정하고;
    상기 트랜잭션 인증 번호를 검증할 때, 상기 수신된 선택된 코드를 상기 서버에 저장된 코드 테이블로부터 결정된 선택된 코드와 비교하도록 구성되는, 서버.
  41. 제38항 또는 제40항에서,
    상기 사용자 인증 모듈은, 상기 통신 단말기에 대하여 사용된 선택된 코드들에 대한 추적을 계속하고, 선택된 코드가 상기 통신 단말기에 의해 이전에 사용되었던 경우에, 상기 통신 단말기와의 세션 설정을 다시 개시하도록 구성되는, 서버.
  42. 제33항에 있어서,
    상기 사용자 인증 모듈은,
    상기 사용자의 생체인식 식별자를 포함하는 개인 식별 코드를 수신하고;
    상기 서버에 저장된 생체인식 식별자를 사용하여 상기 트랜잭션 인증 번호를 검증하도록 구성되는, 서버.
  43. 제34항에 있어서,
    상기 사용자 인증 모듈은, 비밀 토큰키를 사용하여, 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 상기 인증 베이스 번호를 생성하도록 구성되는, 서버.
  44. 제43항에 있어서,
    상기 사용자 인증 모듈은, 상기 통신 단말기로부터 상기 트랜잭션 인증 번호와 함께 토큰 식별자를 수신하고, 상기 토큰 식별자에 기초하여 상기 비밀 토큰키를 결정하도록 구성되는, 서버.
  45. 제43항에 있어서,
    저장된 마스터키를 더 포함하고,
    상기 사용자 인증 모듈은, 상기 토큰 식별자를 암호화하기 위해, 상기 마스터키를 사용하여 상기 토큰 식별자로부터 상기 비밀 토큰키를 생성하도록 구성되는, 서버.
  46. 제33항에 있어서,
    상기 사용자 인증 모듈은, 상기 트랜잭션 인증 번호의 성공적인 검증 후에, 상기 데이터 세트에 공개 함수를 적용하고 암호화를 위해 상기 비밀 토큰키를 사용하여, 상기 데이터 세트로부터 서버 인증 코드를 생성하고, 상기 서버 인증 코드를 상기 통신 단말기에 송신하도록 구성되는, 서버.
  47. 전기통신 네트워크를 통해 서버에 액세스하기 위해 통신 단말기를 사용하는 사용자에 의해 개인 식별 코드를 변경하는 개인 식별 코드의 변경 방법으로서,
    상기 사용자로부터 구 개인 식별 코드를 수신하는 단계;
    상기 사용자로부터 신 개인 식별 코드를 수신하는 단계;
    상기 통신 단말기와 상기 서버 사이에 교환된 보안 세션 설정 프로토콜 메시지로부터 데이터 세트를 생성하는 단계;
    상기 통신 단말기와 연관된 인증 모듈에서, 상기 인증 모듈과 연관된 비밀 토큰키를 사용하여, 상기 데이터 세트로부터 인증 베이스 번호를 생성하는 단계;
    상기 인증 베이스 번호, 상기 구 개인 식별 코드, 및 상기 신 개인 식별 코드로부터 ID(identification) 변경 코드를 생성하는 단계;
    상기 통신 단말기로부터 상기 서버에 상기 ID 식별 코드를 송신하는 단계;
    상기 서버에서, 상기 비밀 토큰키를 사용하여, 교환된 상기 보안 세션 설정 프로토콜 메시지로부터 인증 베이스 번호를 생성하는 단계; 및
    상기 서버에서, 상기 구 개인 식별 코드와 상기 서버에서 생성된 상기 인증 베이스 번호를 사용하여, 상기 ID 변경 코드로부터 상기 신 개인 식별 코드를 취득하는 단계
    포함하는 개인 식별 코드의 변경 방법.
KR1020087010512A 2005-10-05 2006-10-05 사용자 인증 방법 및 디바이스 KR20080059617A (ko)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US72346905P 2005-10-05 2005-10-05
US60/723,469 2005-10-05
EP05405693 2005-12-08
EP05405693.2 2005-12-08
EP05405716A EP1773018A1 (en) 2005-10-05 2005-12-21 Method and devices for user authentication
EP05405716.1 2005-12-21

Publications (1)

Publication Number Publication Date
KR20080059617A true KR20080059617A (ko) 2008-06-30

Family

ID=37682848

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020087010512A KR20080059617A (ko) 2005-10-05 2006-10-05 사용자 인증 방법 및 디바이스

Country Status (6)

Country Link
US (1) US20080212771A1 (ko)
EP (1) EP1941698B1 (ko)
JP (1) JP2009510955A (ko)
KR (1) KR20080059617A (ko)
AT (1) ATE527797T1 (ko)
WO (1) WO2007038896A2 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170077170A (ko) * 2014-10-24 2017-07-05 비자 유럽 리미티드 트랜잭션 메시징

Families Citing this family (114)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8909557B2 (en) * 2002-02-28 2014-12-09 Mastercard International Incorporated Authentication arrangement and method for use with financial transaction
GB0204620D0 (en) * 2002-02-28 2002-04-10 Europay Internat N V Chip authentication programme
JP2007018050A (ja) * 2005-07-05 2007-01-25 Sony Ericsson Mobilecommunications Japan Inc 携帯端末装置、暗証番号認証プログラム、及び暗証番号認証方法
WO2007027958A1 (en) * 2005-08-29 2007-03-08 Junaid Islam ARCHITECTURE FOR MOBILE IPv6 APPLICATIONS OVER IPv4
US8811369B2 (en) 2006-01-11 2014-08-19 Qualcomm Incorporated Methods and apparatus for supporting multiple communications modes of operation
KR101089526B1 (ko) 2006-01-11 2011-12-05 퀄컴 인코포레이티드 피어-투-피어 통신 시스템에서 파라미터 선택
US7941835B2 (en) * 2006-01-13 2011-05-10 Authenticor Identity Protection Services, Inc. Multi-mode credential authorization
US8249965B2 (en) * 2006-03-30 2012-08-21 Obopay, Inc. Member-supported mobile payment system
US8532021B2 (en) 2006-03-30 2013-09-10 Obopay, Inc. Data communications over voice channel with mobile consumer communications devices
US20070244811A1 (en) * 2006-03-30 2007-10-18 Obopay Inc. Mobile Client Application for Mobile Payments
EP2407918A1 (en) * 2006-03-30 2012-01-18 Obopay Inc. Mobile person-to-person payment system
US20070255662A1 (en) * 2006-03-30 2007-11-01 Obopay Inc. Authenticating Wireless Person-to-Person Money Transfers
US7751339B2 (en) 2006-05-19 2010-07-06 Cisco Technology, Inc. Method and apparatus for simply configuring a subscriber appliance for performing a service controlled by a separate service provider
CN101512576A (zh) * 2006-09-15 2009-08-19 康法特公司 用于确保电子交易的真实性的方法和计算机系统
WO2008035450A1 (fr) * 2006-09-20 2008-03-27 Secured Communications, Inc. Authentification par un identifiant ponctuel
US20090287601A1 (en) * 2008-03-14 2009-11-19 Obopay, Inc. Network-Based Viral Payment System
US9118665B2 (en) 2007-04-18 2015-08-25 Imation Corp. Authentication system and method
JP2009016952A (ja) * 2007-06-29 2009-01-22 Toshiba Corp 電子機器および通信システム
JP4392672B2 (ja) * 2007-08-01 2010-01-06 Ｎｅｃシステムテクノロジー株式会社 ソフトウェア無線通信装置、及びソフトウェア更新方法、並びに、ソフトウェア無線通信システム
US8213902B2 (en) * 2007-08-02 2012-07-03 Red Hat, Inc. Smart card accessible over a personal area network
US20110101093A1 (en) * 2007-08-19 2011-05-05 Yubico Ab Device and method for generating dynamic credit card data
US10778417B2 (en) 2007-09-27 2020-09-15 Clevx, Llc Self-encrypting module with embedded wireless user authentication
US10783232B2 (en) 2007-09-27 2020-09-22 Clevx, Llc Management system for self-encrypting managed devices with embedded wireless user authentication
TWI537732B (zh) * 2007-09-27 2016-06-11 克萊夫公司 加密之資料保全系統
US10181055B2 (en) 2007-09-27 2019-01-15 Clevx, Llc Data security system with encryption
US11190936B2 (en) 2007-09-27 2021-11-30 Clevx, Llc Wireless authentication system
EP2073153A1 (fr) * 2007-12-18 2009-06-24 Gemplus Procédé pour autoriser une communication avec un dispositif électronique portable, telle qu'un accès à une zone mémoire, dispositif et système électroniques correspondants
WO2009079734A1 (en) 2007-12-20 2009-07-02 Bce Inc. Contact-less tag with signature, and applications thereof
US20090210712A1 (en) * 2008-02-19 2009-08-20 Nicolas Fort Method for server-side detection of man-in-the-middle attacks
US9443068B2 (en) * 2008-02-20 2016-09-13 Micheal Bleahen System and method for preventing unauthorized access to information
US8756660B2 (en) * 2008-04-17 2014-06-17 Microsoft Corporation Enabling two-factor authentication for terminal services
US8595501B2 (en) 2008-05-09 2013-11-26 Qualcomm Incorporated Network helper for authentication between a token and verifiers
DE102008055707A1 (de) * 2008-11-03 2010-05-06 P1 Privat Gmbh Verfahren zur asynchronen Kommunikation über eine Internet-Plattform, sowie Internet-Plattform
WO2010063091A2 (en) 2008-11-04 2010-06-10 Securekey Technologies Inc. System and methods for online authentication
WO2010069033A1 (en) * 2008-12-18 2010-06-24 Bce Inc Validation method and system for use in securing nomadic electronic transactions
CA2729231C (en) * 2008-12-18 2019-01-15 Bce Inc. Processing of communication device signatures for use in securing nomadic electronic transactions
US9548978B2 (en) 2009-02-03 2017-01-17 Inbay Technologies Inc. Method and system for authorizing secure electronic transactions using a security device
US9166975B2 (en) 2012-02-16 2015-10-20 Inbay Technologies Inc. System and method for secure remote access to a service on a server computer
US8739252B2 (en) 2009-02-03 2014-05-27 Inbay Technologies Inc. System and method for secure remote access
US9736149B2 (en) 2009-02-03 2017-08-15 Inbay Technologies Inc. Method and system for establishing trusted communication using a security device
US9521142B2 (en) 2009-02-03 2016-12-13 Inbay Technologies Inc. System and method for generating passwords using key inputs and contextual inputs
US8468582B2 (en) * 2009-02-03 2013-06-18 Inbay Technologies Inc. Method and system for securing electronic transactions
US8510811B2 (en) * 2009-02-03 2013-08-13 InBay Technologies, Inc. Network transaction verification and authentication
US8973111B2 (en) 2009-02-03 2015-03-03 Inbay Technologies Inc. Method and system for securing electronic transactions
US9608988B2 (en) 2009-02-03 2017-03-28 Inbay Technologies Inc. Method and system for authorizing secure electronic transactions using a security device having a quick response code scanner
US9485254B2 (en) 2009-02-03 2016-11-01 Inbay Technologies Inc. Method and system for authenticating a security device
US20100205448A1 (en) * 2009-02-11 2010-08-12 Tolga Tarhan Devices, systems and methods for secure verification of user identity
WO2010094125A1 (en) 2009-02-19 2010-08-26 Securekey Technologies Inc. System and methods for online authentication
US8756661B2 (en) * 2009-08-24 2014-06-17 Ufp Identity, Inc. Dynamic user authentication for access to online services
CN102036242B (zh) * 2009-09-29 2014-11-05 中兴通讯股份有限公司 一种移动通讯网络中的接入认证方法和系统
DE102010013202A1 (de) 2010-03-29 2011-09-29 Giesecke & Devrient Gmbh Verfahren zum sicheren Übertragen einer Anwendung von einem Server in eine Lesegeräteinheit
CA2795594C (en) * 2010-04-08 2019-03-05 Securekey Technologies Inc. Credential provision and proof system
WO2011150405A2 (en) * 2010-05-28 2011-12-01 Suridx, Inc. Wireless encrypted control of physical access systems
US8855698B2 (en) * 2010-06-23 2014-10-07 Cisco Technology, Inc. Method and apparatus for dynamically adding participants into an existing talk group
US20120054491A1 (en) * 2010-08-31 2012-03-01 Peter John Tippett Re-authentication in client-server communications
US20120191977A1 (en) * 2011-01-25 2012-07-26 Merquery Financial Systems, Llc Secure transaction facilitator
CN102347942B (zh) * 2011-07-01 2016-09-28 飞天诚信科技股份有限公司 一种基于图像采集的信息安全方法及系统
US8868921B2 (en) * 2011-07-20 2014-10-21 Daon Holdings Limited Methods and systems for authenticating users over networks
US20130085944A1 (en) * 2011-09-29 2013-04-04 Pacid Technologies, Llc System and method for application security
KR20130085492A (ko) * 2011-12-09 2013-07-30 한국전자통신연구원 일회용 ｉｄ를 이용한 인증 시스템 및 방법
WO2013144416A1 (en) * 2012-03-29 2013-10-03 Nokia Corporation Wireless memory device authentication
TWI566564B (zh) * 2012-04-25 2017-01-11 Samton International Development Technology Co Ltd Virtual reality authentication circuit, system and electronic consumption method
DE102012208834A1 (de) * 2012-05-25 2013-11-28 Siemens Aktiengesellschaft Authentisierung eines Produktes gegenüber einem Authentisierer
US8639619B1 (en) 2012-07-13 2014-01-28 Scvngr, Inc. Secure payment method and system
US20140279554A1 (en) * 2013-03-12 2014-09-18 Seth Priebatsch Distributed authenticity verification for consumer payment transactions
GB2512138B (en) * 2013-03-22 2015-03-25 F Secure Corp Secured online transactions
CN104113411B (zh) * 2013-04-22 2017-09-29 中国银联股份有限公司 一种ic卡脱机pin验证方法以及ic卡脱机验证系统
CN103268436A (zh) * 2013-04-24 2013-08-28 徐明亮 移动支付中一种基于触摸屏的图形化密码验证方法与系统
US8770478B2 (en) 2013-07-11 2014-07-08 Scvngr, Inc. Payment processing with automatic no-touch mode selection
RU2583710C2 (ru) 2013-07-23 2016-05-10 Закрытое акционерное общество "Лаборатория Касперского" Система и способ обеспечения конфиденциальности информации, используемой во время операций аутентификации и авторизации, при использовании доверенного устройства
GB2514428B (en) 2013-08-19 2016-01-13 Visa Europe Ltd Enabling access to data
CN105474241A (zh) * 2013-08-21 2016-04-06 维萨国际服务协会 用于对电子货币进行转账的方法和系统
CN103607284B (zh) * 2013-12-05 2017-04-19 李笑来 身份认证方法及设备、服务器
US10230532B2 (en) * 2013-12-17 2019-03-12 Agency For Science, Technology And Research Entity authentication in network
US10959093B2 (en) 2014-05-08 2021-03-23 Visa International Service Association Method and system for provisioning access data to mobile device
US10070310B2 (en) 2014-05-08 2018-09-04 Visa International Service Association Method and system for provisioning access data to mobile device
CN104021328B (zh) * 2014-06-24 2018-02-06 上海众人网络安全技术有限公司 基于光感技术的钓鱼网站鉴别方法及系统
CN109951435B (zh) * 2014-08-04 2021-03-30 创新先进技术有限公司 一种设备标识提供方法及装置和风险控制方法及装置
WO2016032975A1 (en) 2014-08-28 2016-03-03 Cryptography Research, Inc. Generating a device identification key from a base key for authentication with a network
CN105574041B (zh) 2014-10-16 2020-07-21 阿里巴巴集团控股有限公司 一种数据重组方法和装置
US11399019B2 (en) 2014-10-24 2022-07-26 Netflix, Inc. Failure recovery mechanism to re-establish secured communications
US10050955B2 (en) * 2014-10-24 2018-08-14 Netflix, Inc. Efficient start-up for secured connections and related services
US11533297B2 (en) 2014-10-24 2022-12-20 Netflix, Inc. Secure communication channel with token renewal mechanism
US9628445B2 (en) * 2014-10-31 2017-04-18 Ncr Corporation Trusted device control messages
CN105630345B (zh) 2014-11-06 2019-02-19 阿里巴巴集团控股有限公司 一种控制显示方向的方法和设备
US11037139B1 (en) * 2015-03-19 2021-06-15 Wells Fargo Bank, N.A. Systems and methods for smart card mobile device authentication
US11188919B1 (en) 2015-03-27 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for contactless smart card authentication
US9984238B1 (en) 2015-03-30 2018-05-29 Amazon Technologies, Inc. Intelligent storage devices with cryptographic functionality
US10720001B1 (en) * 2015-04-02 2020-07-21 Mark Y. Grosberg System and method for verified admission through access controlled locations
WO2016178780A1 (en) * 2015-05-07 2016-11-10 Visa International Service Association Method and system for provisioning access data to mobile device
ES2803250T3 (es) * 2015-05-07 2021-01-25 Visa Int Service Ass Método y sistema de aprovisionamiento de datos de acceso a dispositivos móviles
CN106341233A (zh) 2015-07-08 2017-01-18 阿里巴巴集团控股有限公司 客户端登录服务器端的鉴权方法、装置、系统及电子设备
JP5951094B1 (ja) * 2015-09-07 2016-07-13 ヤフー株式会社 生成装置、端末装置、生成方法、生成プログラム及び認証処理システム
CN106656913A (zh) 2015-10-28 2017-05-10 珠海金山办公软件有限公司 一种数字验证码的生成方法及装置
US10218698B2 (en) * 2015-10-29 2019-02-26 Verizon Patent And Licensing Inc. Using a mobile device number (MDN) service in multifactor authentication
CN105391549B (zh) * 2015-12-10 2018-10-12 四川长虹电器股份有限公司 客户端与服务器之间通信动态密钥实现方法
EP3182396A1 (en) * 2015-12-15 2017-06-21 Thomson Licensing Devices and methods for encryption and decryption of graphical 3d objects
US11113688B1 (en) 2016-04-22 2021-09-07 Wells Fargo Bank, N.A. Systems and methods for mobile wallet provisioning
DE102016007832A1 (de) * 2016-06-27 2017-12-28 Giesecke+Devrient Mobile Security Gmbh Effizientes Authentifizieren
BR112018077461A2 (pt) * 2016-07-29 2019-04-02 Visa International Service Association método, e, computador servidor.
US10171465B2 (en) * 2016-09-29 2019-01-01 Helene E. Schmidt Network authorization system and method using rapidly changing network keys
US20180123782A1 (en) * 2016-10-27 2018-05-03 Motorola Solutions, Inc. Method for secret origination service to distribute a shared secret
US10841302B2 (en) * 2017-05-24 2020-11-17 Lg Electronics Inc. Method and apparatus for authenticating UE between heterogeneous networks in wireless communication system
US10742646B2 (en) * 2018-05-10 2020-08-11 Visa International Service Association Provisioning transferable access tokens
US11089010B2 (en) * 2019-08-14 2021-08-10 Taklane Method for transmitting digital information
US11941608B1 (en) 2019-09-18 2024-03-26 Wells Fargo Bank, N.A. Systems and methods for a transaction card having a customer-specific URL
US11652813B2 (en) 2019-10-04 2023-05-16 Mastercard International Incorporated Systems and methods for real-time identity verification using a token code
US11449636B2 (en) 2019-10-04 2022-09-20 Mastercard International Incorporated Systems and methods for secure provisioning of data using secure tokens
US11165586B1 (en) * 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11558380B2 (en) * 2020-11-19 2023-01-17 Paypal, Inc. Defending multi-factor authentication against phishing
US11423392B1 (en) 2020-12-01 2022-08-23 Wells Fargo Bank, N.A. Systems and methods for information verification using a contactless card
CN114760061B (zh) * 2020-12-29 2023-09-05 深信服科技股份有限公司 数据上传的方法、装置、设备及存储介质
US20220217136A1 (en) * 2021-01-04 2022-07-07 Bank Of America Corporation Identity verification through multisystem cooperation
CN115118439B (zh) * 2022-08-29 2023-01-20 北京智芯微电子科技有限公司 终端数字身份的校验方法及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0670818B2 (ja) * 1984-09-07 1994-09-07 カシオ計算機株式会社 照合カード及びその認証方法
US5177789A (en) * 1991-10-09 1993-01-05 Digital Equipment Corporation Pocket-sized computer access security device
FR2771533B1 (fr) * 1997-11-21 2003-01-31 Taib Thierry Baillie Carte de securite pour paiement securise par carte de credit
FR2810139B1 (fr) * 2000-06-08 2002-08-23 Bull Cp8 Procede de securisation de la phase de pre-initialisation d'un systeme embarque a puce electronique, notamment d'une carte a puce, et systeme embarque mettant en oeuvre le procede
AU2002345935A1 (en) * 2001-06-26 2003-03-03 Enterprises Solutions, Inc. Transaction verification system and method
US7249261B2 (en) * 2001-10-16 2007-07-24 Activcard Ireland Limited Method for securely supporting password change
CN1252598C (zh) * 2002-09-03 2006-04-19 国际商业机器公司 提供身份相关的信息和防止中间人的攻击的方法和系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170077170A (ko) * 2014-10-24 2017-07-05 비자 유럽 리미티드 트랜잭션 메시징

Also Published As

Publication number Publication date
JP2009510955A (ja) 2009-03-12
WO2007038896A3 (en) 2007-06-14
ATE527797T1 (de) 2011-10-15
EP1941698A2 (en) 2008-07-09
US20080212771A1 (en) 2008-09-04
EP1941698B1 (en) 2011-10-05
WO2007038896A2 (en) 2007-04-12

Similar Documents

Publication Publication Date Title
EP1941698B1 (en) Method and devices for user authentication
US9900163B2 (en) Facilitating secure online transactions
EP1773018A1 (en) Method and devices for user authentication
Hiltgen et al. Secure internet banking authentication
US9160732B2 (en) System and methods for online authentication
US8689290B2 (en) System and method for securing a credential via user and server verification
US20060294023A1 (en) System and method for secure online transactions using portable secure network devices
EP1933252A1 (en) Dynamic OTP Token
US20110099379A1 (en) Augmented single factor split key asymmetric cryptography-key generation and distributor
US20020166048A1 (en) Use and generation of a session key in a secure socket layer connection
CN101278538A (zh) 用于用户认证的方法和设备
WO2001084761A1 (en) Method for securing communications between a terminal and an additional user equipment
ES2758706T3 (es) Métodos y sistemas para la transmisión segura de información de identificación a través de redes públicas
AU2007300707B2 (en) System and method for facilitating secure online transactions
TWI383327B (zh) The use of wafer financial card in the ATM system cardholder authentication methods, systems and computer systems
Rifa-Pous A secure mobile-based authentication system for e-banking
Xu et al. OTP bidirectional authentication scheme based on MAC address
Mishra et al. Cryptanalysis and Improvement of Jiang et al.'s Smart Card Based Remote User Authentication Scheme
Molla Mobile user authentication system (MUAS) for e-commerce applications.
Pikrammenos et al. Authentication Mechanism Enhancement Utilising Secure Repository for Password Less Handshake
KR20190142459A (ko) P2p 인증을 위한 거래연동 otp 발생기
AU2002259074B2 (en) Use and generation of a session key in a secure socket layer connection
Alenius et al. Online Banking Security
AU2002259074A1 (en) Use and generation of a session key in a secure socket layer connection
NO327337B1 (no) En anordning og en metode for sterk brukerautentisering og kryptering av brukerdata i private virtuelle nettverk

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