KR20220116483A - 악성 프로그램 코드 주입으로부터의 보호를 위한 시스템 및 방법 - Google Patents

악성 프로그램 코드 주입으로부터의 보호를 위한 시스템 및 방법 Download PDF

Info

Publication number
KR20220116483A
KR20220116483A KR1020227023825A KR20227023825A KR20220116483A KR 20220116483 A KR20220116483 A KR 20220116483A KR 1020227023825 A KR1020227023825 A KR 1020227023825A KR 20227023825 A KR20227023825 A KR 20227023825A KR 20220116483 A KR20220116483 A KR 20220116483A
Authority
KR
South Korea
Prior art keywords
descriptors
code
authentication
client
transaction
Prior art date
Application number
KR1020227023825A
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 KR20220116483A publication Critical patent/KR20220116483A/ko

Links

Images

Classifications

    • 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/44—Program or device authentication
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/04—Inference or reasoning models
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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
    • 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/321—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 a third party or a trusted authority
    • 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
    • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
    • 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/3236—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 cryptographic hash functions
    • 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/3247—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 digital signatures
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2119—Authenticating web pages, e.g. with suspicious links

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Computational Linguistics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Biomedical Technology (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

악성 코드 주입으로부터 방어하기 위한 시스템, 장치, 방법, 및 기계 판독가능 매체가 설명된다. 예를 들어, 장치의 일 실시예는: 사용자 입력에 응답하여 인터넷 상의 웹 페이지에 액세스하는 애플리케이션을 실행하기 위한 프로세서 - 웹 페이지는 그와 연관된 하나 이상의 리소스 디스크립터들 및/또는 코드 디스크립터들을 가짐 -; 및 신뢰하는 엔티티에 접속함으로써, 적어도 부분적으로, 상기 리소스 디스크립터들 및/또는 코드 디스크립터들에 기초하여 상기 웹 페이지를 확인하기 위한 인증기 엔진을 포함하고, 신뢰하는 엔티티는 하나 이상의 리소스 디스크립터들과 연관된 하나 이상의 리소스 디스크립터 객체들 및/또는 하나 이상의 코드 디스크립터들과 연관된 하나 이상의 코드 디스크립터 객체들을 포함하는 암호화 어써션 상의 서명을 생성하도록 구성된다.

Description

악성 프로그램 코드 주입으로부터의 보호를 위한 시스템 및 방법
본 발명은 일반적으로 데이터 처리 시스템들의 분야에 관한 것이다. 더 구체적으로는, 본 발명은 자바스크립트 주입과 같은 악성 프로그램 코드 주입으로부터 보호하기 위한 시스템 및 방법에 관한 것이다.
도 1은 생체 측정 장치(biometric device)(100)를 갖는 예시적인 클라이언트(120)를 나타낸다. 정상적으로 동작될 때, 생체 측정 센서(102)는 사용자로부터 원(raw) 생체 측정 데이터를 판독하고(예를 들어, 사용자의 지문을 캡처하고, 사용자의 음성을 기록하고, 사용자의 사진을 촬영하는 것 등을 행하고), 특징 추출 모듈(103)은 (예를 들어, 지문의 소정 영역, 소정 얼굴 특징 등에 집중하는) 원 생체 측정 데이터의 지정된 특성을 추출한다. 매처 모듈(matcher module)(104)은 추출된 특징들(133)을 클라이언트(120) 상의 보안 저장소 내에 저장된 생체 측정 기준 데이터(110)와 비교하고, 추출된 특징들과 생체 측정 기준 데이터(110) 간의 유사성에 기초하여 점수를 산출한다. 생체 측정 기준 데이터(110)는 전형적으로 사용자가 지문, 음성 샘플, 이미지 또는 다른 생체 측정 데이터를 장치(100)에 등재하는 등재 프로세스(enrollment process)의 결과이다. 이어서, 애플리케이션(105)이 점수를 이용하여, 인증에 성공했는지(예를 들어, 점수가 소정의 지정된 임계치를 초과하는지)를 결정할 수 있다.
도 1에 도시된 시스템은 생체 측정 인증을 향해 지향되지만, 다양한 다른 또는 추가적인 인증 기술들이 예시적인 클라이언트(120) 상에서 채용될 수 있다. 예를 들어, 클라이언트측 인증기들은 사용자에 의해 입력되는 PIN 또는 다른 비밀 코드(예컨대, 패스워드)에 기초할 수 있고/있거나 사용자 존재(예컨대, 사용자가 존재를 검증하기 위해 누르는 버튼)에 기초하여 트리거될 수 있다.
생체 측정 센서들을 이용하여 네트워크를 통해 보안 사용자 인증을 제공하기 위한 시스템들이 설계되었다. 그러한 시스템들에서는, 원격 서버를 이용하여 사용자를 인증하기 위해, 애플리케이션에 의해 생성된 점수, 및/또는 다른 인증 데이터가 네트워크를 통해 전송될 수 있다. 예를 들어, 미국 특허 출원 제2011/0082801호("'801 출원")는 강한 인증(예를 들어, 신분 도용 및 피싱에 대한 보호), 보안 트랜잭션(예를 들어, 트랜잭션에 대한 "브라우저 내 멀웨어(malware in the browser)" 및 "중간자(man in the middle)" 공격에 대한 보호) 및 클라이언트 인증 토큰의 등재/관리(예를 들어, 지문 판독기, 얼굴 인식 장치, 스마트카드, 신뢰 플랫폼 모듈 등)를 제공하는 네트워크 상에서의 사용자 등록 및 인증을 위한 프레임워크를 설명한다.
본 출원의 양수인은 '801 출원에서 설명된 인증 프레임워크에 대한 다양한 개선사항들을 개발하였다. 이러한 개선사항들 중 일부가 본 양수인에게 양도되고 본 명세서에 참고로 포함되는 모두 1012년 12월 29일자로 출원된 하기 미국 특허 출원들("공계류 중인 출원들")의 세트에서 설명된다: 제13/730,761호, "Query System and Method to Determine Authentication Capabilities"; 제13/730,776호, "System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices"; 제13/730,780호, "System and Method for Processing Random Challenges Within an Authentication Framework"; 제13/730,791호, "System and Method for Implementing Privacy Classes Within an Authentication Framework"; 제13/730,795호, "System and Method for Implementing Transaction Signaling Within an Authentication Framework".
간단히, 공계류 중인 출원들은 사용자가 클라이언트 장치 상의 생체측정 장치들(예컨대, 지문 센서들)과 같은 인증 장치들(또는 인증기들)에 등재하는 인증 기술들을 설명한다. 사용자가 생체 측정 장치에 등재할 때, (예를 들어, 손가락 스와이핑, 사진 스냅핑, 음성 기록 등에 의해) 생체 측정 기준 데이터가 캡처된다. 사용자는 순차적으로 네트워크를 통해 하나 이상의 서버들에 인증 장치들(예컨대, 공동 계류중인 출원에 설명된 바와 같이 보안 트랜잭션 서비스들이 장착된 웹사이트들 또는 기타 신뢰자들)을 등록하고; 순차적으로 등록 프로세스 동안 교환된 데이터(예컨대, 인증 장치들에 발급된 암호화 키들)를 이용하여 서버들을 인증할 수 있다. 인증되면, 사용자는 웹사이트 또는 다른 신뢰자와의 하나 이상의 온라인 트랜잭션을 수행하도록 허용된다. 공계류 중인 출원들에서 설명되는 프레임워크에서, 사용자를 고유하게 식별하는 데 사용될 수 있는 지문 데이터 및 다른 데이터와 같은 민감한 정보는 사용자의 프라이버시를 보호하기 위해 사용자의 인증 장치 상에 국지적으로 유지될 수 있다.
아래의 도면들과 관련된 아래의 상세한 설명으로부터 본 발명의 더 양호한 이해가 얻어질 수 있다.
도 1은 생체 측정 인증 능력을 갖는 예시적인 클라이언트 장치를 나타낸다.
도 2a 및 도 2b는 보안 인증 시스템 아키텍처의 2개의 상이한 실시예를 나타낸다.
도 2c는 키들이 어떻게 인증 장치들 내에 등록될 수 있는지를 보여주는 트랜잭션 도면을 나타낸다.
도 3a 및 도 3b는 보안 디스플레이를 이용하는 보안 트랜잭션 확인을 위한 실시예들을 나타낸다.
도 4는 설정된 관계를 갖지 않는 장치와의 트랜잭션을 위해 인증을 수행하기 위한 본 발명의 일 실시예를 나타낸다.
도 5a 및 도 5b는 트랜잭션을 위해 인증을 수행하기 위한 2개의 상이한 실시예를 도시하는 트랜잭션 도면이다.
도 6은 본 발명의 일 실시예에서 사용되는 추가적인 아키텍처 특징을 도시한다.
도 7 및 도 8은 본 발명의 상이한 실시예들에서 사용되는 베어러 토큰(bearer token)들의 상이한 실시예들을 도시한다.
도 9는 예시적인 "오프라인" 및 "세미-오프라인" 인증 시나리오를 도시한다.
도 10은 클라이언트 및/또는 서버에 대한 예시적인 시스템 아키텍처를 도시한다.
도 11은 클라이언트 및/또는 서버에 대한 다른 예시적인 시스템 아키텍처를 도시한다.
도 12는 클라이언트와 서버 사이의 중간자 공격(MITM) 배열을 도시한다.
도 13은 클라이언트가 웹 페이지를 방문할 때 예시적인 상호작용들의 세트를 도시한다.
도 14는 웹 페이지 및 후속 자바스크립트 링크들에 관련된 통신을 캡처하는 MITM을 도시한다.
도 15는 인증 단계 동안 클라이언트와 서버 사이에 개재된 MITM을 도시한다.
도 16은 리소스 디스크립터들 및 코드 디스크립터들을 이용하여 클라이언트-서버 인증의 일 실시예를 도시한다.
아래에서는 진보된 인증 기술들 및 관련 응용들을 구현하기 위한 기기, 방법 및 기계 판독 가능 매체의 실시예들이 설명된다. 설명 전반에서, 설명의 목적으로, 본 발명의 완전한 이해를 제공하기 위해, 다수의 구체적 상세들이 설명된다. 그러나, 본 발명은 이러한 구체적 상세들 중 일부 없이도 실시될 수 있다는 것이 당업자에게 명백할 것이다. 다른 경우들에서, 본 발명의 기본 원리들을 불명확하게 하지 않기 위해 주지 구조들 및 장치들은 도시되지 않거나 블록도 형태로 도시된다.
하기에 논의되는 본 발명의 실시예들은 생체 측정 장치 또는 PIN 엔트리와 같은 인증 능력을 갖는 클라이언트 장치들을 포함한다. 이러한 장치들은 때때로 본 명세서에서 "토큰", "인증 장치" 또는 "인증기"로 지칭된다. 소정 실시예들이 얼굴 인식 하드웨어/소프트웨어(예를 들어, 사용자의 얼굴을 인식하고 사용자의 눈 움직임을 추적하기 위한 카메라 및 관련 소프트웨어)에 집중되지만, 일부 실시예들은 예를 들어 지문 센서, 음성 인식 하드웨어/소프트웨어(예를 들어, 사용자의 음성을 인식하기 위한 마이크 및 관련 소프트웨어) 및 광학 인식 능력(예를 들어, 사용자의 망막을 스캐닝하기 위한 광학 스캐너 및 관련 소프트웨어)을 비롯한 추가 생체 측정 장치들을 이용할 수 있다. 인증 능력은 신뢰 플랫폼 모듈(TPM) 및 스마트카드와 같은 비생체 측정 장치들도 포함할 수 있다.
모바일 생체 측정 구현에서, 생체 측정 장치는 신뢰자로부터 원격적일 수 있다. 본 명세서에서 사용되는 바와 같이, 용어 "원격"은 생체 측정 센서가 그것이 통신적으로 결합되는 컴퓨터의 보안 경계의 일부가 아니라는 것을 의미한다(예를 들어, 그것이 신뢰자의 컴퓨터와 동일한 물리적 울타리 안에 넣어지지 않는다). 예로서, 생체 측정 장치는 네트워크(예를 들어, 인터넷, 무선 네트워크 링크 등)를 통해 또는 USB 포트와 같은 주변장치 입력을 통해 신뢰자에 결합될 수 있다. 이러한 조건들하에서는, 신뢰자가 장치가 신뢰자에 의해 허가된 장치(예를 들어, 승인 가능한 레벨의 인증 및 무결성 보호를 제공하는 장치)인지 그리고/또는 해커가 생체 측정 장치를 손상시켰는지를 알기 위한 방법이 존재하지 않을 수 있다. 생체 측정 장치의 신뢰성은 장치의 특정 구현에 의존한다.
그러나, 하기에 논의되는 바와 같이, 사용자를 인증하는 데 이용되는 인증 기술들은 원격 서버들 및/또는 다른 데이터 처리 장치들과의 네트워크를 통한 통신과 같은 비위치 컴포넌트들을 포함할 수 있다. 더욱이, 본 명세서에서는 (ATM 및 소매 위치와 같은) 특정 실시예들이 설명되지만, 본 발명의 기본 원리들은 트랜잭션이 최종 사용자에 의해 국지적으로 또는 원격으로 개시되는 임의의 시스템의 상황 안에서 구현될 수 있다는 점에 유의해야 한다.
용어 "신뢰자"는 때때로 본 명세서에서 사용자 트랜잭션이 시도되는 엔티티(예를 들어, 사용자 트랜잭션을 수행하는 웹사이트 또는 온라인 서비스)뿐만 아니라, 본 명세서에서 설명되는 기본 인증 기술들을 수행할 수 있는 그러한 엔티티를 대신하여 구현되는 보안 트랜잭션 서버들도 지칭하는 데 사용된다. 원격 인증 능력들을 제공한 보안 트랜잭션 서버들은 신뢰자에 의해 소유되고/되거나 그의 제어하에 있을 수 있거나, 사업 협정의 일부로서 신뢰자에게 보안 트랜잭션 서비스들을 제공하는 제삼자의 제어하에 있을 수 있다.
용어 "서버"는 본 명세서에서 클라이언트로부터 네트워크를 통해 요청들을 수신하고, 그에 응답하여 하나 이상의 동작을 수행하고, 전형적으로 동작들의 결과들을 포함하는 응답을 클라이언트로 송신하는 하드웨어 플랫폼 상에서(또는 다수의 하드웨어 플랫폼에 걸쳐) 실행되는 소프트웨어를 지칭하는 데 사용된다. 서버는 클라이언트 요청들에 응답하여 네트워크 "서비스"를 클라이언트들로 제공하거나, 제공하는 것을 돕는다. 중요하게, 서버는 단일 컴퓨터(예를 들어, 서버 소프트웨어를 실행하기 위한 단일 하드웨어 장치)로 한정되지 않으며, 사실상 다수의 하드웨어 플랫폼에 걸쳐, 잠재적으로는 다수의 지리 위치에 분산될 수 있다.
본 명세서에 기술된 본 발명의 실시예는 보안 트랜잭션 장치를 통해 개시된 트랜잭션에 대해 사용자를 인증하기 위한 기술을 포함한다. 예로서, 트랜잭션은 인출, 이체 또는 다른 사용자 개시 동작일 수 있고, 트랜잭션 장치는 ATM(automatic teller machine), PoS(point-of-sale) 트랜잭션 장치, 또는 사용자 대신 트랜잭션을 실행할 수 있는 다른 장치일 수 있다. 트랜잭션은 예를 들어 장치를 갖춘 소매점 또는 다른 소매 위치에서 제품 또는 서비스를 구매하기 위해 지불을 완료하는 것, 장치를 통해 자금을 인출하는 것, 장치에 대해 유지 보수를 수행하는 것, 또는 사용자 인증이 필요한 임의의 다른 트랜잭션을 포함할 수 있다.
본 발명의 일 실시예는, 장치가 오프라인(즉, 백엔드 인증 서버에 접속되지 않음) 또는 세미-오프라인(즉, 백엔드 인증 서버에 단지 주기적으로 접속됨) 상태인 상황에서도, 사용자를 국지적으로 인증(즉, 사용자를 검증)하기 위한 기술을 제공한다. 일 실시예에서, 사용자의 클라이언트 장치는 (예를 들어, 신뢰자를 대신하여 운영되는) 백엔드 인증 서버에 의해 생성된 인증 요청을 캐싱하는 능력을 구비하며, 장치는 사용자의 클라이언트 장치로부터 장치로 송신된 인증 응답을 검증하는 데 필요한 데이터를 구비한다.
본 발명의 이러한 실시예의 상세를 논의하기 전에, 원격 사용자 인증 기술의 개요가 제공될 것이다. 이들 및 다른 원격 사용자 인증 기술은, 본 출원의 양수인에게 양도되고 본 명세서에 참고로 포함되는, 공계류 중인 출원에 설명되어 있다.
원격 사용자 인증 기술
도 2a 및 도 2b는 사용자를 원격으로 인증하기 위한 클라이언트측 및 서버측 컴포넌트들을 포함하는 시스템 아키텍처의 2개의 실시예를 나타낸다. 도 2a에 도시된 실시예는 웹사이트와 통신하기 위해 브라우저 플러그인 기반 아키텍처를 사용하는 반면, 도 2b에 도시된 실시예는 브라우저를 필요로 하지 않는다. 본 명세서에 설명된 다양한 인증 기술 및 관련 애플리케이션은 이들 시스템 아키텍처 중 어느 하나에서 구현될 수 있다. 예를 들어, 본 명세서에 설명된 클라이언트 장치 내의 인증 엔진은 인터페이스(202)를 포함하는 보안 트랜잭션 서비스(201)의 일부로서 구현될 수 있다. 그러나, 전술한 실시예는 도 2a 및 도 2b에 도시된 것 이외의 하드웨어 및 소프트웨어의 논리적 배열을 사용하여 구현될 수 있음에 유의하여야 한다.
도 2a를 참조하면, 도시된 실시예는 최종 사용자를 등재하고 인증하기 위한 하나 이상의 인증 장치(210 내지 212)가 구비된 클라이언트(200)를 포함한다. 상기에 언급된 바와 같이, 인증 장치(210 내지 212)는 지문 센서, 음성 인식 하드웨어/소프트웨어(예를 들어, 사용자의 음성을 인식하기 위한 마이크 및 관련 소프트웨어), 얼굴 인식 하드웨어/소프트웨어(예를 들어, 사용자의 얼굴을 인식하기 위한 카메라 및 관련 소프트웨어) 및 광학 인식 능력(예를 들어, 사용자의 망막 스캐닝을 위한 광학 스캐너 및 관련 소프트웨어)과 같은 생체 측정 장치, 및 신뢰 플랫폼 모듈(TPM) 및 스마트카드와 같은 비생체 측정 장치를 포함할 수 있다. 사용자는 보안 트랜잭션 서비스(201)가 보안 저장소(220)에 (인터페이스(202)를 통해) 생체 측정 템플릿 데이터로서 저장할 수 있는 생체 측정 데이터를 제공함으로써(예를 들어, 지문 장치에서 손가락을 스와이핑함) 생체 측정 장치를 등재할 수 있다.
보안 저장소(220)가 인증 장치(들)(210 내지 212)의 보안 경계 외부에 도시되어 있지만, 일 실시예에서, 각각의 인증 장치(210 내지 212)는 그 자신의 통합 보안 저장소를 가질 수 있다. 또한, 각각의 인증 장치(210 내지 212)는 생체 측정 기준 데이터 레코드를 암호로 보호할 수 있다(예를 들어, 저장소(220)를 안전하게 만들기 위해 대칭 키를 사용하여 이들을 봉인할 수 있다).
인증 장치들(210 내지 212)은 보안 트랜잭션 서비스(201)에 의해 노출되는 인터페이스(202)(예를 들어, 애플리케이션 프로그래밍 인터페이스 또는 API)를 통해 클라이언트에 통신적으로 결합된다. 보안 트랜잭션 서비스(201)는 네트워크를 통해 하나 이상의 보안 트랜잭션 서버(232, 233)와 통신하기 위한 그리고 웹 브라우저(204)의 상황 내에서 실행되는 보안 트랜잭션 플러그인(205)과 인터페이스하기 위한 보안 애플리케이션이다. 도시된 바와 같이, 인터페이스(202)는 장치 식별 코드(예를 들어, 인증기 증명 ID(AAID)), 사용자 식별 코드, 사용자 등재 데이터(예를 들어, 스캐닝된 지문 또는 다른 생체 측정 데이터), 및 본 명세서에서 설명되는 보안 인증 기술들을 수행하는 데 사용되는 키들과 같은, 인증 장치들(210 내지 212) 각각과 관련된 정보를 저장하는 클라이언트(200) 상의 보안 저장 장치(220)에 대한 보안 액세스도 제공할 수 있다. 예를 들어, 하기에 상세히 논의되는 바와 같이, 고유 키가 인증 장치들 각각 내에 저장되고, 후속하여 인터넷과 같은 네트워크를 통해 서버들(230)에 통신할 때 사용될 수 있다.
하기에 논의되는 바와 같이, 웹사이트들(231) 또는 다른 서버들과의 HTTP 또는 HTTPS 트랜잭션들과 같은 소정 타입의 네트워크 트랜잭션들이 보안 트랜잭션 플러그인(205)에 의해 지원된다. 일 실시예에서, 보안 트랜잭션 플러그인은 보안 기업 또는 웹 목적지(230)(아래에서 때때로 간단히 "서버(230)"로 지칭됨) 내의 웹 서버(231)에 의해 웹페이지의 HTML 코드 내에 삽입된 특정 HTML 태그들에 응답하여 개시된다. 그러한 태그의 검출에 응답하여, 보안 트랜잭션 플러그인(205)은 처리를 위해 트랜잭션들을 보안 트랜잭션 서비스(201)로 전송할 수 있다. 게다가, (예를 들어, 보안 키 교환과 같은) 소정 타입의 트랜잭션들을 위해, 보안 트랜잭션 서비스(201)는 구내(즉, 웹사이트와 같은 곳에 배치된) 트랜잭션 서버(232)와의 또는 구외 트랜잭션 서버(233)와의 직접 통신 채널을 개설할 수 있다.
보안 트랜잭션 서버들(232, 233)은 후술하는 보안 인증 트랜잭션들을 지원하는 데 필요한 사용자 데이터, 인증 장치 데이터, 키들 및 다른 보안 정보를 저장하기 위한 보안 트랜잭션 데이터베이스(240)에 결합된다. 그러나, 본 발명의 기본 원리들은 도 2a에 도시된 보안 기업 또는 웹 목적지(230) 내의 논리 컴포넌트들의 분리를 필요로 하지 않는다는 점에 유의해야 한다. 예를 들어, 웹사이트(231) 및 보안 트랜잭션 서버들(232, 233)은 단일 물리 서버 또는 개별 물리 서버들 내에 구현될 수 있다. 더욱이, 웹사이트(231) 및 트랜잭션 서버들(232, 233)은 후술하는 기능들을 수행하기 위해 하나 이상의 서버 상에서 실행되는 통합 소프트웨어 모듈 내에 구현될 수 있다.
전술한 바와 같이, 본 발명의 기본 원리들은 도 2a에 도시된 브라우저 기반 아키텍처로 한정되지 않는다. 도 2b는 독립 애플리케이션(254)이 보안 트랜잭션 서비스(201)에 의해 제공되는 기능을 이용하여 네트워크를 통해 사용자를 인증하는 대안 구현을 나타낸다. 일 실시예에서, 애플리케이션(254)은 아래에서 상세히 설명되는 사용자/클라이언트 인증 기술들을 수행하기 위해 보안 트랜잭션 서버들(232, 233)에 의존하는 하나 이상의 네트워크 서비스(251)와의 통신 세션들을 설정하도록 설계된다.
도 2a 및 도 2b에 도시된 실시예들 중 어느 하나에서, 보안 트랜잭션 서버들(232, 233)은 키들을 생성할 수 있고, 이어서 이 키들은 보안 트랜잭션 서비스(201)로 안전하게 송신되고, 보안 저장소(220) 내에 인증 장치들 내로 저장된다. 게다가, 보안 트랜잭션 서버들(232, 233)은 서버 측의 보안 트랜잭션 데이터베이스(240)를 관리한다.
도 2c는 인증 장치들을 등록하기 위한 일련의 트랜잭션들을 나타낸다. 상기에 언급된 바와 같이, 등록 동안, 인증 장치와 보안 트랜잭션 서버들(232, 233) 중 하나 사이에 키가 공유된다. 키는 클라이언트(200)의 보안 저장소(220) 및 보안 트랜잭션 서버들(232, 233)에 의해 사용되는 보안 트랜잭션 데이터베이스(220) 내에 저장된다. 일 실시예에서, 키는 보안 트랜잭션 서버들(232, 233) 중 하나에 의해 생성되는 대칭 키이다. 그러나, 하기에 논의되는 다른 실시예에서는, 비대칭 키들이 사용될 수 있다. 이 실시예에서, 공개 키는 보안 트랜잭션 서버들(232, 233)에 의해 저장될 수 있으며, 제2의 관련 비공개 키는 클라이언트 상의 보안 저장소(220) 내에 저장될 수 있다. 더욱이, 다른 실시예에서, 키(들)는 클라이언트(200) 상에서 (예를 들어, 보안 트랜잭션 서버들(232, 233)보다는 인증 장치 또는 인증 장치 인터페이스에 의해) 생성될 수 있다. 본 발명의 기본 원리들은 임의의 특정 타입의 키들 또는 키들을 생성하는 방식으로 한정되지 않는다.
동적 대칭 키 프로비저닝 프로토콜(DSKPP)과 같은 보안 키 프로비저닝 프로토콜을 이용하여, 보안 통신 채널을 통해 키를 클라이언트와 공유할 수 있다(예를 들어, Request for Comments(RFC) 6063 참조). 그러나, 본 발명의 기본 원리들은 임의의 특정 키 프로비저닝 프로토콜로 한정되지 않는다.
도 2c에 도시된 구체적 상세들로 돌아가서, 사용자 등재 또는 사용자 검증이 완료되면, 서버(230)는 장치 등록 동안 클라이언트에 의해 제공되어야 하는 랜덤 생성 챌린지(예를 들어, 암호 논스)를 생성한다. 랜덤 챌린지는 제한된 기간 동안 유효할 수 있다. 보안 트랜잭션 플러그인은 랜덤 챌린지를 검출하고 이를 보안 트랜잭션 서비스(201)로 전송한다. 이에 응답하여, 보안 트랜잭션 서비스는 서버(230)와의 대역외 세션(예를 들어, 대역외 트랜잭션)을 개시하고, 키 프로비저닝 프로토콜을 이용하여 서버(230)와 통신한다. 서버(230)는 사용자 이름을 이용하여, 사용자를 찾고, 랜덤 챌린지를 확인하고, 장치의 증명 코드(예를 들어, AAID)가 전송된 경우에 이를 확인하고, 사용자에 대해 보안 트랜잭션 데이터베이스(220) 내에 새로운 엔트리를 생성한다. 그는 또한 키 또는 공개/비공개 키 쌍을 생성하고, 키(들)를 데이터베이스(220)에 기록하고, 키 프로비저닝 프로토콜을 이용하여 키(들)를 다시 보안 트랜잭션 서비스(201)로 전송할 수 있다. 일단 완료되면, 인증 장치와 서버(230)는 대칭 키가 사용된 경우에는 동일 키를, 또는 비대칭 키들이 사용된 경우에는 상이한 키들을 공유한다.
도 3a는 브라우저 기반 구현을 위한 보안 트랜잭션 확인을 나타낸다. 브라우저 기반 구현이 도시되지만, 동일한 기본 원리들이 독립 애플리케이션 또는 모바일 장치 앱을 이용하여 구현될 수 있다.
보안 트랜잭션 확인은 소정 타입의 트랜잭션들(예를 들어, 금융 트랜잭션들)에 대해 더 강한 보안을 제공하도록 설계된다. 도시된 실시예에서, 사용자는 트랜잭션을 커미트하기 전에 각각의 트랜잭션을 확인한다. 도시된 기술들을 이용하여, 사용자는 그/그녀가 커미트하기를 원하는 것을 정확히 확인하고, 그래픽 사용자 인터페이스(GUI)의 윈도우(301) 내에 표시된 그/그녀가 보는 것을 정확하게 커미트한다. 다시 말해서, 이 실시예는 사용자가 확인하지 않은 트랜잭션을 커미트하기 위해 트랜잭션 텍스트가 "중간자"(MITM) 또는 "브라우저 내 사람"(man in the browser, MITB)에 의해 변경될 수 없는 것을 보증한다.
일 실시예에서, 보안 트랜잭션 플러그인(205)은 트랜잭션 상세사항들을 나타내기 위해 브라우저 상황에서 윈도우(301)를 표시한다. 보안 트랜잭션 서버(201)는 (예를 들어, 표시된 텍스트에 대해 해시/서명을 생성함으로써) 윈도우 내에 나타난 텍스트가 누군가에 의해 변조되고 있지 않다는 것을 주기적으로(예를 들어, 임의의 간격으로) 검증한다. 상이한 실시예에서, 인증 장치는 (예를 들어, GlobalPlatform's TrustedUI를 따르는 API를 제공하는) 신뢰되는 사용자 인터페이스를 갖는다.
아래의 예는 이 실시예의 동작을 강조하는 데 도움이 될 것이다. 사용자는 가맹점 사이트로부터 구매할 아이템들을 선택하고, "체크아웃"을 선택한다. 가맹점 사이트는 본 명세서에서 설명되는 본 발명의 실시예들 중 하나 이상을 구현하는 보안 트랜잭션 서버(232, 233)를 갖는 서비스 제공자(예를 들어, 페이팔(PayPal))에게 트랜잭션을 전송한다. 가맹점 사이트는 사용자를 인증하고, 트랜잭션을 완료한다.
보안 트랜잭션 서버(232, 233)는 트랜잭션 상세사항들(TD)을 수신하고, "보안 트랜잭션" 요청을 HTML 페이지 내에 넣어 클라이언트(200)로 전송한다. 보안 트랜잭션 요청은 트랜잭션 상세들 및 랜덤 챌린지를 포함한다. 보안 트랜잭션 플러그인(205)은 트랜잭션 확인 메시지를 위해 요청을 검출하고, 모든 데이터를 보안 트랜잭션 서비스(201)로 전송한다. 브라우저 또는 플러그인을 사용하지 않는 실시예에서, 정보는 보안 트랜잭션 서버들로부터 클라이언트(200) 상의 보안 트랜잭션 서비스로 직접 전송될 수 있다.
브라우저 기반 구현의 경우, 보안 트랜잭션 플러그인(205)은 (예를 들어, 브라우저 상황에서) 사용자에게 트랜잭션 상세들을 갖는 윈도우(301)를 표시하고, 사용자에게 트랜잭션을 확인하기 위한 인증을 제공할 것을 요청한다. 브라우저 또는 플러그인을 사용하지 않는 실시예에서, 보안 트랜잭션 서비스(201), 애플리케이션(254)(도 2b) 또는 인증 장치(210)는 윈도우(301)를 표시할 수 있다. 보안 트랜잭션 서비스(201)는 타이머를 시동하고, 사용자에게 표시되고 있는 윈도우(301)의 콘텐츠를 검증한다. 검증의 주기는 랜덤으로 선택될 수 있다. 보안 트랜잭션 서비스(201)는 사용자가 윈도우(301) 내의 유효한 트랜잭션 상세들을 확인하도록 보장한다(예를 들어, 상세들에 대한 해시를 생성하고, 올바른 콘텐츠의 해시에 대해 비교함으로써 콘텐츠가 정확하다는 것을 검증함). 그가 콘텐츠가 변조된 것을 검출하는 경우에 그는 확인 토큰/서명의 생성을 방지한다.
사용자가 (예를 들어, 지문 센서 상에서 손가락을 스와이핑함으로써) 유효 검증 데이터를 제공한 후, 인증 장치는 사용자를 검증하고, 트랜잭션 상세들 및 랜덤 챌린지를 이용하여 (때때로 "토큰"으로 지칭되는) 암호 서명을 생성한다(즉, 서명은 트랜잭션 상세들 및 논스에 대해 계산된다). 이것은 보안 트랜잭션 서버(232, 233)가 트랜잭션 상세들이 서버와 클라이언트 사이에서 변경되지 않았다는 것을 보증할 수 있게 한다. 보안 트랜잭션 서비스(201)는 생성된 서명 및 사용자 이름을 보안 트랜잭션 플러그인(205)으로 전송하고, 이 보안 트랜잭션 플러그인은 서명을 보안 트랜잭션 서버(232, 233)로 전송한다. 보안 트랜잭션 서버(232, 233)는 사용자 이름을 이용하여 사용자를 식별하고, 서명을 검증한다. 검증에 성공하면, 확인 메시지가 클라이언트로 전송되고, 트랜잭션이 처리된다.
본 발명의 일 실시예는 보안 트랜잭션 서버가 서버에 의해 승인된 인증 능력들을 지시하는 서버 정책을 클라이언트로 송신하는 조회 정책을 구현한다. 이어서, 클라이언트는 서버 정책을 분석하여, 그가 지원하고/하거나 사용자가 사용 소망을 지시한 인증 능력들의 서브세트를 식별한다. 이어서, 클라이언트는 제공된 정책과 매칭되는 인증 토큰들의 서브세트를 이용하여 사용자를 등록 및/또는 인증한다. 결과적으로, 클라이언트가 그의 인증 능력들(예를 들어, 그의 인증 장치들 모두)에 대한 포괄적인 정보 또는 클라이언트를 고유하게 식별하는 데 사용될 수 있는 다른 정보를 송신할 필요가 없기 때문에, 클라이언트의 프라이버시에 대한 영향이 더 낮다.
한정이 아니라 예로서, 클라이언트는, 몇 가지 예를 들자면, 지문 센서, 음성 인식 능력, 얼굴 인식 능력, 눈/광학 인식 능력, PIN 검증과 같은 다수의 사용자 검증 능력을 포함할 수 있다. 그러나, 프라이버시 이유로, 사용자는 모든 그의 능력들에 대한 상세들을 요청 서버에 누설하기를 원하지 않을 수 있다. 따라서, 본 명세서에서 설명되는 기술들을 이용하여, 보안 트랜잭션 서버는 그가 예를 들어 지문, 광학 또는 스마트카드 인증을 지원한다는 것을 지시하는 서버 정책을 클라이언트로 송신할 수 있다. 이어서, 클라이언트는 서버 정책을 그 자신의 인증 능력들에 대해 비교하고, 이용 가능한 인증 옵션들 중 하나 이상을 선택할 수 있다.
본 발명의 일 실시예는 보안 트랜잭션 서버 상에서의 트랜잭션 서명을 이용하여서, 클라이언트들과의 세션들을 유지하기 위해 서버 상에 어떠한 트랜잭션 상태도 유지될 필요가 없다. 구체적으로, 윈도우(301) 내에 표시된 트랜잭션 텍스트와 같은 트랜잭션 상세들이 서버에 의해 서명된 클라이언트로 전송될 수 있다. 이어서, 서버는 서명을 검증함으로써 클라이언트에 의해 수신된, 서명된 트랜잭션 응답들이 유효하다는 것을 검증할 수 있다. 서버는 트랜잭션 콘텐츠를 지속적으로 저장할 필요가 없는데, 그러한 지속 저장은 다수의 클라이언트를 위한 상당한 양의 저장 공간을 소비할 것이며, 서버에 대한 서비스 거부 타입 공격들의 가능성을 유발할 것이다.
웹사이트 또는 다른 네트워크 서비스(311)가 클라이언트(200)와의 트랜잭션을 개시하는 것을 나타내는 도 3b에 본 발명의 일 실시예가 도시된다. 예를 들어, 사용자는 웹사이트 상에서 구매할 아이템들을 선택했을 수 있고, 체크아웃 및 지불할 준비가 되었을 수 있다. 도시된 예에서, 웹사이트 또는 서비스(311)는 (본 명세서에서 설명되는 바와 같이) 서명들을 생성 및 검증하기 위한 서명 처리 논리(313) 및 (예를 들어, 전술한 인증 기술들을 이용하여) 클라이언트 인증을 수행하기 위한 인증 논리(314)를 포함하는 보안 트랜잭션 서버(312)로 트랜잭션을 넘긴다.
일 실시예에서, 보안 트랜잭션 서버(312)로부터 클라이언트(200)로 전송되는 인증 요청은 랜덤 챌린지, 예를 들어 (전술한 바와 같은) 암호 논스, 트랜잭션 상세들(예를 들어, 트랜잭션을 완료하도록 제공되는 특정 텍스트), 및 (보안 트랜잭션 서버만이 아는) 비공개 키를 이용하여 랜덤 챌린지 및 트랜잭션 상세들에 대해 서명 처리 논리(313)에 의해 생성되는 서명을 포함한다.
위의 정보가 클라이언트에 의해 수신되면, 사용자는 트랜잭션을 완료하기 위해 사용자 검증이 필요하다는 지시를 수신할 수 있다. 그에 응답하여, 사용자는 예를 들어 지문 스캐너를 가로질러 손가락을 스와이핑하거나, 사진을 촬영하거나, 마이크 내로 말하거나, 주어진 트랜잭션에 대해 허용되는 임의의 다른 타입의 인증을 수행할 수 있다. 일 실시예에서, 사용자가 인증 장치(210)에 의해 성공적으로 검증되면, 클라이언트는 다음 내용을 서버에 다시 전송한다: (1) 랜덤 챌린지 및 트랜잭션 텍스트(둘 모두 이전에 서버에 의해 클라이언트에 제공됨), (2) 사용자가 인증을 성공적으로 완료했음을 증명하는 인증 데이터, 및 (3) 서명.
이어서, 보안 트랜잭션 서버(312) 상의 인증 모듈(314)은 사용자가 올바르게 인증되었음을 확인할 수 있으며, 서명 처리 논리(313)는 비공개 키를 이용하여 랜덤 챌린지 및 트랜잭션 텍스트에 대한 서명을 재생성한다. 서명이 클라이언트에 의해 전송된 것과 매칭되는 경우, 서버는 트랜잭션 텍스트가 웹사이트 또는 서비스(311)로부터 처음에 수신되었던 것과 동일하다는 것을 검증할 수 있다. 보안 트랜잭션 서버(312)는 트랜잭션 텍스트(또는 다른 트랜잭션 데이터)를 보안 트랜잭션 데이터베이스(120) 내에 지속적으로 저장할 필요가 없기 때문에, 저장 및 처리 자원들이 보존된다.
오프라인 장치 또는 연결성이 제한된 장치에 대하여 클라이언트를 인증하기 위한 시스템 및 방법
언급된 바와 같이, 본 발명의 일 실시예는, 사용자 장치 및 장치가 오프라인(즉, 신뢰자의 백엔드 인증 서버에 접속되지 않음) 또는 세미-오프라인(즉, 사용자 장치는 신뢰자에 접속되지 않지만, 장치는 접속됨) 상태인 상황에서도, 사용자를 국지적으로 인증(즉, 사용자를 검증)하기 위한 기술을 포함한다. 도 4는 신뢰자(451)에 이전에 등록된 인증 장치를 갖는 클라이언트(400)가 트랜잭션을 완료하기 위해 트랜잭션 장치(450)와 보안 채널을 설정하는 하나의 그러한 배열을 도시한다. 한정이 아니라 예로서, 트랜잭션 장치는 ATM, 소매 위치의 PoS(point-of-sale) 트랜잭션 장치, IoT(Internet of Things) 장치, 또는 클라이언트(400)와의 채널을 설정하여 사용자로 하여금 트랜잭션을 수행하는 것을 가능하게 할 수 있는 임의의 다른 장치일 수 있다. 채널은, 한정이 아니라 예로서, 근거리장 통신(NFC) 및 블루투스(예를 들어, 블루투스 코어 사양 버전 4.0에 기재된 바와 같은 블루투스 저에너지(BTLE))를 포함하는 임의의 무선 통신 프로토콜을 사용하여 구현될 수 있다. 물론, 본 발명의 기본 원리는 임의의 특정 통신 표준으로 제한되지 않는다.
점선 화살표로 표시된 바와 같이, 클라이언트(400)와 신뢰자(451) 사이의 접속 및/또는 트랜잭션 장치(450)와 신뢰자(451) 사이의 접속은 산발적이거나 존재하지 않을 수 있다. 지불 영역에서의 실세계 응용은 종종 그러한 "오프라인" 사용 경우에 의존한다. 예를 들어, 클라이언트(400)(예를 들어, 스마트폰)를 갖는 사용자는 트랜잭션 시에 신뢰자(451)에 대한 접속성을 갖지 않을 수 있지만, 트랜잭션 장치(450)에 대해 인증함으로써 트랜잭션(예를 들어, 지불)을 허가하기를 원할 수 있다. 그러나, 본 발명의 일부 실시예들에서, 클라이언트(400) 및/또는 트랜잭션 장치(450)는 (본 명세서에서 설명되는 인증 또는 트랜잭션 확인 프로세스 동안 반드시 그런 것은 아니지만) 신뢰자(451)와 어떤 정보를 교환한다.
전통적으로, 사용자 검증은 장치(예를 들어, PoS 트랜잭션 장치 또는 ATM)에 의해 캡처될 개인 식별 번호(PIN)와 같은 비밀을 사용하여 구현되었다. 이어서, 장치는 비밀을 검증하기 위해 신뢰자에 대한 온라인 접속을 생성하거나 PIN의 검증을 사용자의 인증기(예를 들어, EMV 뱅킹 카드)에 요청할 것이다. 그러한 구현은 몇 가지 단점을 갖는다. 그것은 온라인 접속을 요구할 수 있으며, 이는 때로는 이용 가능할 수 있지만 항상 그런 것은 아니다. 그것은 또한 사용자가 숄더 서핑 및 다른 공격을 받는 잠재적 비신뢰 장치에 장기 유효 비밀을 입력할 것을 요구한다. 또한, 그것은 본질적으로 특정 사용자 검증 방법(예를 들어, 이 경우에서는 PIN)에 얽매인다. 마지막으로, 그것은 사용자가 PIN과 같은 비밀을 기억할 것을 요구하는데, 이는 사용자에게 불편할 수 있다.
본 명세서에서 설명되는 인증 기술은 사용자가 그/그녀 자신의 클라이언트의 인증 능력에 의존할 수 있게 하기 때문에 사용자 검증 방법 및 보안 면에서 상당히 더 많은 융통성을 제공한다. 특히, 일 실시예에서, 사용자의 클라이언트 상의 모바일 애플리케이션은 클라이언트가 신뢰자에 접속된 시간 동안 신뢰자에 의해 제공된 인증 요청을 캐싱한다. 인증 요청은 전술한 인증 요청과 동일한(또는 유사한) 정보(예를 들어, 인증기와 관련된 논스 및 공개 키)뿐만 아니라, 신뢰자에 의해 생성된 인증 요청(의 적어도 일부)에 대한 서명, 검증 키, 및 잠재적으로, 인증 요청이 유효하게 유지될 기간(또는 역으로 인증 요청이 실효될 시간)을 나타내는 타이밍 데이터를 포함하는 추가 정보도 포함할 수 있다. 일 실시예에서, 모바일 애플리케이션은 다수의 그러한 접속 요청(예를 들어, 각각의 트랜잭션 장치 또는 트랜잭션 장치 타입에 대해 하나씩)을 캐싱할 수 있다.
일 실시예에서, 캐싱된 인증 요청은 이어서 클라이언트/모바일 애플리케이션이 신뢰자와 접속할 수 없는 상황에서 트랜잭션 장치와의 트랜잭션을 위해 사용될 수 있다. 일 실시예에서, 모바일 앱은 serverData 및 트랜잭션 장치로부터 수신된 추가 데이터를 포함하는 캐싱된 인증 요청에 기초하여 인증 응답의 생성을 트리거한다. 이어서, 인증 응답은 트랜잭션 장치로 송신되고, 트랜잭션 장치는 이어서 (예를 들어, 트랜잭션 장치가 신뢰자와 접속되는 시간 동안) 신뢰자로부터 제공된 검증 키를 사용하여 인증 응답을 검증한다. 특히, 트랜잭션 장치는 신뢰자가 제공한 키를 사용하여 인증 응답에 포함된 serverData에 대한 서명을 검증할 수 있다. 일 실시예에서, 서명은 비공개 신뢰자 검증 키를 사용하여 신뢰자에 의해 생성되고, 트랜잭션 장치는 대응하는 공개 신뢰자 검증 키(신뢰자에 의해 트랜잭션 장치에 제공됨)를 사용하여 서명을 검증한다.
트랜잭션 장치가 인증 응답으로부터 추출된 serverData를 검증하면, 그것은 (예를 들어, 클라이언트가 신뢰자에 대해 직접 인증하고 있을 때, 전술한 신뢰자에 의한 검증과 동일하거나 유사한 방식으로) 클라이언트/모바일 앱에 의해 생성된 인증 응답을 검증하기 위해 인증 요청으로부터 추출된 공개 키(예를 들어, Uauth.pub)를 사용할 수 있다.
후술하는 대안적인 실시예에서, 신뢰자는 (클라이언트 장치 상의 모바일 앱을 통해서보다는) 트랜잭션 장치에 직접 인증 요청을 제공한다. 이 실시예에서, 트랜잭션 장치는 클라이언트 상의 모바일 앱으로부터 트랜잭션을 완료하라는 요청을 수신하자마자 신뢰자로부터 인증 요청을 요청할 수 있다. 그것이 인증 요청을 가지면, 그것은 (예컨대, 서명을 생성하고 이를 기존 서명과 비교함으로써) 전술한 바와 같이 요청 및 인증 응답을 확인할 수 있다.
도 5a는 클라이언트(400)가 인증 요청을 캐싱하는 실시예에서 클라이언트(400), 트랜잭션 장치(450) 및 신뢰자 간의 상호 작용을 나타내는 트랜잭션 도면이다. 이 실시예는 트랜잭션 장치(450)가 신뢰자와의 기존 접속을 가질 것을 요구하지 않기 때문에 때때로 "풀 오프라인" 실시예로 지칭된다.
501에서, 클라이언트는 신뢰자로부터 캐싱 가능 인증 요청을 요청한다. 502에서, 신뢰자는 캐싱 가능 인증 요청을 생성하고, 503에서 인증 요청이 클라이언트로 전송되고, 504에서 클라이언트가 인증 요청을 캐싱한다. 일 실시예에서, 인증 요청은 인증에 사용될 인증기와 연관된 공개 키(Uauth.pub), 및 공개 키 및 랜덤 논스에 대해 신뢰자 검증 키(RPVerifyKey)를 사용하여 생성된 서명을 포함한다. 비대칭 키가 사용되는 경우, 서명을 생성하기 위해 신뢰자에 의해 사용되는 RPVerifyKey는 신뢰자가 (잠재적으로, 사용자 인증 요청을 처리하기 훨씬 전에) 트랜잭션 장치에 제공한 대응하는 공개 RPVerifyKey를 갖는 비공개 키이다.
일 실시예에서, 인증 요청은 또한 인증 요청이 유효할 시간 길이(예를 들어, MaxCacheTime)를 나타내는 타이밍 정보를 포함한다. 이 실시예에서, 캐싱 가능 인증 요청에 대한 서명은 공개 인증 키, 논스 및 MaxCacheTime의 조합에 대해 생성될 수 있다(예를 들어, ServerData = Uauth.pub | MaxCacheTime | serverNonce | Sign(RPVerifyKey, Uauth.pub | MaxCacheTime | serverNonce)). 일 실시예에서, 인증 응답은 하나 초과의 인증 키(예를 들어, 사용자를 인증할 수 있는 각각의 인증기에 대해 하나씩)를 포함하고, 서명은 (예를 들어, 논스 및 MaxCacheTime과 함께) 이들 키 모두에 대해 생성될 수 있다.
언급된 바와 같이, 공개 RPVerifyKey는 트랜잭션 장치(450), 또는 인증 요청/응답의 오프라인 검증을 수행하도록 의도된 임의의 장치에 알려질 필요가 있다. 이러한 확장은 트랜잭션 장치가 신뢰자에 등록된 인증 키에 대해 어떠한 지식도 갖지 않기 때문에 요구된다(즉, 사용자 장치와 트랜잭션 장치 간에 설정된 관계가 존재하지 않음). 결과적으로, 신뢰자는 키(들)가 인증 응답 검증을 위해 사용되어야 하는 보안 방식으로 트랜잭션 장치(또는 다른 장치)와 통신해야 한다. 트랜잭션 장치는 (캐싱된 인증 요청이 얼마나 오랫동안 사용될 수 있는지에 대한 신뢰자의 정책을 준수하기 위해) MaxCacheTime을 검증하여 캐싱된 인증 요청이 여전히 유효한지를 결정할 것이다.
505에서, 클라이언트는 트랜잭션 장치에 대한 보안 접속을 설정하고 트랜잭션을 개시한다. 예를 들어, 트랜잭션 장치가 PoS 트랜잭션 장치인 경우, 트랜잭션은 직불 또는 신용 트랜잭션을 포함할 수 있다. 트랜잭션 장치가 ATM인 경우, 트랜잭션은 현금 인출 또는 유지 보수 작업을 포함할 수 있다. 본 발명의 기본 원리는 임의의 특정 타입의 트랜잭션 장치 또는 보안 접속으로 제한되지 않는다. 또한, 505에서, 클라이언트는 캐싱된 인증 요청을 트랜잭션 장치로 송신할 수 있다.
이에 응답하여, 506에서 트랜잭션 장치는 트랜잭션을 완료하기 위해 장치 식별 정보(예를 들어, 트랜잭션 장치 식별 코드), 랜덤 챌린지(논스), 및 옵션으로서, 정의된 신택스 내의 트랜잭션 텍스트를 송신할 수 있다. 이어서, 랜덤 챌린지/논스는 인증 응답에 암호로 결합될 것이다. 이러한 메커니즘은 장치로 하여금 사용자 검증이 신선하고 캐싱/재사용되지 않았음을 검증하는 것을 가능하게 한다.
전술한 바와 같은 트랜잭션 확인(예를 들어, 도 3a와 도 3b 및 관련 텍스트 참조)을 지원하기 위해, 트랜잭션 장치는 표준화되고 사람이 판독 가능한 트랜잭션 표현을 생성하도록 요구될 수 있다. 본 명세서에서 사용되는 바와 같은 "표준화"는 신뢰자(예를 들어, 아래의 동작 511에서 지시되는 바와 같은 최종 검증을 위함) 및/또는 트랜잭션 장치에 의해 파싱될 수 있는 포맷을 의미한다. 그것은 사람이 판독 가능할 필요가 있는데, 왜냐하면 트랜잭션 확인이 인증기가 그것을 클라이언트(400)의 보안 디스플레이 상에 표시할 것을 요구하기 때문이다. 그러한 인코딩의 예는 XSLT가 시각화에 사용되는 XML일 수 있다.
507에서, 인증 응답을 생성하기 위해, 사용자에게 특정 인증기를 사용하여 클라이언트에 대한 인증을 수행할 것(예를 들어, 지문 센서 상에서 손가락을 스와이핑하는 것, PIN 코드를 입력하는 것, 마이크 내로 말하는 것 등)을 지시하는 인증 사용자 인터페이스가 표시된다. 사용자가 인증을 제공하면, 클라이언트 상의 인증 엔진은 (예를 들어, 사용자로부터 수집한 인증 데이터를 인증기의 보안 저장소에 저장된 사용자 검증 기준 데이터와 비교하여) 사용자의 신원을 검증하고, 인증 장치와 연관된 비공개 키를 사용하여 랜덤 챌린지(및 또한 잠재적으로는 트랜잭션 장치 ID 및/또는 트랜잭션 텍스트)에 대한 서명을 암호화하고/하거나 생성한다. 이어서, 508에서 인증 응답이 트랜잭션 장치로 송신된다.
509에서, 트랜잭션 장치는 공개 RPVerifyKey를 사용하여 serverData(505에서 수신됨)에 대한 서명을 검증한다 - 그것이 이미 검증하지 않았다면 -. serverData가 검증되면, 그것은 인증을 수행하는 데 사용된 인증기와 연관된 공개 키(Uauth.pub)를 알게 된다. 그것은 이 키를 사용하여 인증 응답을 검증한다. 예를 들어, 그것은 공개 인증 키를 사용하여 논스 및 임의의 다른 관련 정보(예를 들어, 트랜잭션 텍스트, 트랜잭션 장치 ID 등)에 대해 생성된 서명을 해독하거나 검증할 수 있다. 트랜잭션 확인이 트랜잭션 장치에 의해 수행되면, 그것은 트랜잭션 텍스트에 대해 생성되고 508에서 인증 응답에 포함된 서명을 확인함으로써 클라이언트 상에 표시된 트랜잭션 텍스트를 검증할 수 있다. 암호로 보호된 serverData 구조를 갖는 대신에, 트랜잭션 장치는 또한 신뢰자에 대한 온라인 접속을 사용하여 비서명 serverData를 검증할 수 있다 - 이것이 이용 가능하다면(세미-오프라인 경우) -.
510에서, 각각 인증이 성공했는지 또는 실패했는지에 따라 성공 또는 실패 지시가 클라이언트로 전송된다. 성공적인 경우, 트랜잭션 장치는 트랜잭션(예를 들어, 구매를 완료하기 위한 계좌 차변 기입/대변 기입, 현금 지급, 관리 작업 수행 등)을 허가할 것이다. 그렇지 않은 경우, 그것은 트랜잭션을 허가하지 않고/않거나 추가 인증을 요청할 것이다.
신뢰자에 대한 접속이 존재하면, 511에서, 트랜잭션 장치는 (신뢰자가 트랜잭션 텍스트의 검증을 담당하는 엔티티라고 가정하여) 인증 응답을 신뢰자에게 그리고/또는 트랜잭션 텍스트를 송신할 수 있다. 트랜잭션의 레코드가 신뢰자에서 기록될 수 있고/있거나, 신뢰자는 트랜잭션 텍스트를 검증하고 트랜잭션을 확인할 수 있다(도시되지 않음).
도 5b는 트랜잭션 장치가 신뢰자와의 접속을 갖고 그로부터 인증 요청을 수신하는 실시예에서 클라이언트(400), 트랜잭션 장치(450) 및 신뢰자 간의 상호작용을 나타내는 트랜잭션 도면이다. 이 실시예는 때때로 "세미-오프라인" 실시예로 지칭되는데, 왜냐하면 클라이언트가 신뢰자에 대한 접속을 갖지 않지만 트랜잭션 장치(450)는 그러한 접속을 갖기 때문이다.
521에서, 클라이언트는 트랜잭션을 개시하여, 트랜잭션 장치와의 보안 접속(예를 들어, NFC, 블루투스 등)을 설정한다. 522에서, 트랜잭션 장치는 이에 응답하여 신뢰자로부터 인증 요청을 요청한다. 523에서, 신뢰자는 인증 요청을 생성하고, 524에서 인증 요청이 트랜잭션 장치로 전송된다. 도 5a에 도시된 실시예에서와 같이, 인증 요청은 인증에 사용될 클라이언트 상의 인증기와 연관된 공개 키(Uauth.pub), 및 공개 키 및 랜덤 논스에 대해 신뢰자 검증 키(RPVerifyKey)를 사용하여 생성된 서명을 포함할 수 있다. 비대칭 키가 사용되는 경우, 서명을 생성하기 위해 신뢰자에 의해 사용되는 RPVerifyKey는 신뢰자가 (잠재적으로, 사용자 인증 요청을 처리하기 훨씬 전에) 트랜잭션 장치에 제공하는 대응하는 공개 RPVerifyKey를 갖는 비공개 키이다. 암호로 보호된 serverData 구조를 갖는 대신에, 트랜잭션 장치는 또한 신뢰자에 대한 온라인 접속을 사용하여 비서명 serverData를 검증할 수 있다 - 이것이 이용 가능하다면(세미-오프라인 경우) -.
일 실시예에서, serverData는 또한 인증 요청이 유효할 시간 길이(예를 들어, MaxCacheTime)를 나타내는 타이밍 정보를 포함한다. 이 실시예에서, serverData에 대한 서명은 공개 인증 키, 논스 및 MaxCacheTime의 조합에 대해 생성될 수 있다(예를 들어, ServerData = Uauth.pub | MaxCacheTime | serverNonce | Sign(RPVerifyKey, Uauth.pub | MaxCacheTime | serverNonce)). 일 실시예에서, 인증 응답은 하나 초과의 인증 키(예를 들어, 각각의 인증기에 대해 하나씩)를 포함하고, 서명은 (예를 들어, 논스 및 MaxCacheTime과 함께) 이들 키 모두에 대해 생성될 수 있다.
일 실시예에서, 도 5b의 트랜잭션 도면의 나머지는 실질적으로 도 5a에 도시된 바와 같이 동작한다. 525에서, 트랜잭션 장치는 트랜잭션을 완료하기 위해 식별 정보(예를 들어, 트랜잭션 장치 식별 코드), 랜덤 챌린지(논스), 및 옵션으로서, 정의된 신택스 내의 트랜잭션 텍스트를 송신할 수 있다. 이어서, 랜덤 챌린지/논스는 인증 응답에 암호로 결합될 것이다. 이러한 메커니즘은 장치로 하여금 사용자 검증이 신선하고 캐싱되지 않았음을 검증하는 것을 가능하게 한다.
전술한 바와 같은 트랜잭션 확인(예를 들어, 도 3a와 도 3b 및 관련 텍스트 참조)을 지원하기 위해, 트랜잭션 장치는 표준화되고 사람이 판독 가능한 트랜잭션 표현을 생성하도록 요구될 수 있다. 본 명세서에서 사용되는 바와 같은 "표준화"는 신뢰자(예를 들어, 아래의 동작 511에서 지시되는 바와 같은 최종 검증을 위함) 및/또는 트랜잭션 장치에 의해 파싱될 수 있는 포맷을 의미한다. 그것은 사람이 판독 가능할 필요가 있는데, 왜냐하면 트랜잭션 확인이 인증기가 그것을 클라이언트(400)의 보안 디스플레이 상에 표시할 것을 요구하기 때문이다. 그러한 인코딩의 예는 XSLT가 시각화에 사용되는 XML일 수 있다.
526에서, 인증 응답을 생성하기 위해, 사용자에게 특정 인증기를 사용하여 클라이언트에 대한 인증을 수행할 것(예를 들어, 지문 센서 상에서 손가락을 스와이핑하는 것, PIN 코드를 입력하는 것, 마이크 내로 말하는 것 등)을 지시하는 인증 사용자 인터페이스가 표시된다. 사용자가 인증을 제공하면, 클라이언트 상의 인증 엔진은 (예를 들어, 사용자로부터 수집한 인증 데이터를 인증기의 보안 저장소에 저장된 사용자 검증 기준 데이터와 비교하여) 사용자의 신원을 검증하고, 인증 장치와 연관된 비공개 키를 사용하여 랜덤 챌린지(및 또한 잠재적으로는 트랜잭션 장치 ID 및/또는 트랜잭션 텍스트)에 대한 서명을 암호화하고/하거나 생성한다. 이어서, 527에서 인증 응답이 트랜잭션 장치로 송신된다.
528에서, 트랜잭션 장치는 공개 RPVerifyKey를 사용하여 serverData(524에서 수신됨)에 대한 서명을 검증한다 - 그것이 이미 검증하지 않았다면 -. serverData가 검증되면, 그것은 인증을 수행하는 데 사용된 인증기와 연관된 공개 키(Uauth.pub)를 알게 된다. 그것은 이 키를 사용하여 인증 응답을 검증한다. 예를 들어, 그것은 공개 인증 키를 사용하여 논스 및 임의의 다른 관련 정보(예를 들어, 트랜잭션 텍스트, 트랜잭션 장치 ID 등)에 대해 생성된 서명을 해독하거나 검증할 수 있다. 트랜잭션 확인이 트랜잭션 장치에 의해 수행되면, 그것은 트랜잭션 텍스트에 대해 생성되고 528에서 인증 응답에 포함된 서명을 확인함으로써 클라이언트 상에 표시된 트랜잭션 텍스트를 검증할 수 있다. 암호로 보호된 serverData 구조를 갖는 대신에, 트랜잭션 장치는 또한 신뢰자에 대한 온라인 접속을 사용하여 비서명 serverData를 검증할 수 있다 - 이것이 이용 가능하다면(세미-오프라인 경우) -.
529에서, 각각 인증이 성공했는지 또는 실패했는지에 따라 성공 또는 실패 지시가 클라이언트로 전송된다. 성공적인 경우, 트랜잭션 장치는 트랜잭션(예를 들어, 구매를 완료하기 위한 계좌 차변 기입/대변 기입, 현금 지급, 관리 작업 수행 등)을 허가할 것이다. 그렇지 않은 경우, 그것은 트랜잭션을 허가하지 않고/않거나 추가 인증을 요청할 것이다.
530에서, 트랜잭션 장치는 (신뢰자가 트랜잭션 텍스트의 검증을 담당하는 엔티티라고 가정하여) 인증 응답을 신뢰자에게 그리고/또는 트랜잭션 텍스트를 송신할 수 있다. 트랜잭션의 레코드가 신뢰자에서 기록될 수 있고/있거나, 신뢰자는 트랜잭션 텍스트를 검증하고 트랜잭션을 확인할 수 있다(도시되지 않음).
도 6에 도시된 바와 같이, 일 실시예에서, 모바일 앱(601)이 클라이언트 상에서 실행되어, (도 2b에 도시된 보안 트랜잭션 서비스(201) 및 인터페이스(202)일 수 있는) 인증 클라이언트(602)와 관련하여 본 명세서에 설명되는 동작들을 수행한다. 특히, 모바일 앱(601)은 전송 계층 보안(TLS) 또는 다른 보안 통신 프로토콜을 사용하여 트랜잭션 장치(450) 상에서 실행되는 웹 앱(611)에 대한 보안 채널을 개설할 수 있다. 트랜잭션 장치 상의 웹 서버(612)가 또한 (예를 들어, 인증 요청을 검색하고/하거나 상기에 논의된 바와 같이 신뢰자(451)에 업데이트를 제공하기 위해) 신뢰자(451)와 통신하기 위해 보안 채널을 개설할 수 있다. 인증 클라이언트(602)는 (상기에 상세히 논의된 바와 같이) 예를 들어 캐싱 가능 인증 요청을 검색하기 위해 신뢰자(451)와 직접 통신할 수 있다.
일 실시예에서, 인증 클라이언트(602)는 신뢰자에 의해 이용 가능하게 된 각각의 애플리케이션과 관련된 고유 코드인 "AppID"로 신뢰자 및 임의의 허가된 모바일 앱(601)을 식별할 수 있다. 일부 실시예들에서, 신뢰자가 다수의 온라인 서비스를 제공하는 경우, 사용자는 단일 신뢰자에 관한 다수의 AppID(신뢰자에 의해 제공되는 각각의 서비스에 대해 하나씩)를 가질 수 있다.
일 실시예에서, AppID에 의해 식별되는 임의의 애플리케이션은 신뢰자와 접속하기 위한 허용 가능한 메커니즘 및/또는 애플리케이션 타입을 식별하는 다수의 "패싯(facet)"을 가질 수 있다. 예를 들어, 특정 신뢰자는 웹 서비스를 통한 그리고 상이한 플랫폼 고유 모바일 앱(예를 들어, 안드로이드 앱, iOS 앱 등)을 통한 액세스를 허용할 수 있다. 이들 각각은 예시된 바와 같이 신뢰자에 의해 인증 엔진에 제공될 수 있는 상이한 "FacetID"를 사용하여 식별될 수 있다.
일 실시예에서, 호출 모바일 앱(601)은 그의 AppID를 인증 클라이언트(602)에 의해 노출된 API에 전달한다. 각각의 플랫폼 상에서, 인증 클라이언트(602)는 호출 앱(601)을 식별하고 그의 FacetID를 결정한다. 그것은 이어서 AppID를 분석하고, FacetID가 신뢰자(451)에 의해 제공된 TrustedApps 리스트에 포함되어 있는지를 체크한다.
일 실시예에서, 상기에 논의된 캐싱 가능 인증 요청은 도 7 및 도 8에 도시된 바와 같은 베어러 토큰을 사용하여 구현될 수 있다. 본 명세서에서 설명되는 본 발명의 실시예에서, 토큰 수신자(트랜잭션 장치(450))는 토큰 발행자(신뢰자)에 대한 다른 "온라인" 접속을 요구하지 않고서 토큰, 인증 응답 및 토큰의 인증 응답에 대한 결합을 검증할 수 있는 것이 필요하다.
두 가지 클래스의 베어러 토큰이 구별되어야 한다:
1. 토큰 발행과 토큰 검증 사이에 존재해야 하는 발행자(예를 들어, 신뢰자(451))에 대한 상이한 채널을 사용하여 수신자(예를 들어, 트랜잭션 장치(450))에 의해서만 검증될 수 있는 토큰. 이 토큰 클래스는 본 명세서에서 "비서명된 토큰"으로 지칭된다.
2. 예를 들어, 잠재적으로 특정 토큰이 발행되기 전에 토큰 발행자로부터 수신된 데이터를 이용하여 검증될 수 있는 디지털 서명을 포함하고 있기 때문에, 그의 암호화 구조로 인해 수신자에 의해 검증될 수 있는 토큰. 이 토큰 클래스는 본 명세서에서 "서명된 토큰"으로 지칭된다.
용어 "서명된 토큰 구조"는 본 명세서에서 Uauth.pub 키를 포함하는 서명된 토큰 및 토큰을 포함하는 서명된 구조 둘 모두를 지칭하기 위해 사용된다.
서명된 토큰을 인증 키에 결합
도 7에 도시된 바와 같이, 일 실시예에서, 서명된 토큰들을 인증 키에 결합하기 위하여, 토큰 발행자(예컨대, 신뢰자(451))는: (a) 인증 공개 키(Uauth.pub)(702)를 서명된(서명될) 토큰의 서명될 부분(to-be-signed portion)(701)에 추가하고; (b) 인증 응답의 서명될 부분 내에 그 서명된 토큰을 포함한다. 이렇게 함으로써, 토큰 수신자(예를 들어, 트랜잭션 장치(450))는 서명(703)(예를 들어, 상기에 논의된 공개 RPVerifyKey)을 확인함으로써 토큰을 검증할 수 있다. 검증에 성공하면, 그것은, 앞서 논의된 바와 같이, 공개 키(Uauth.pub)를 추출하고 이를 사용하여 인증 응답을 검증할 수 있다.
비서명된 토큰을 인증 키에 결합
도 8에 도시된 바와 같이, 비서명된 토큰(802)을 인증 키에 결합하기 위해, 일 실시예에서, 토큰 발행자(예를 들어, 신뢰자(451))는 (적어도) 원래의 토큰(802), 및 인증 공개 키(Uauth.pub)를 포함하는 서명될 데이터(801)를 커버하는 서명된 구조를 생성한다. 서명된 구조는 비공개 서명 키(예를 들어, 상기에 논의된 RPVerifyKey 쌍)와 관련된 공개 키를 사용하여 서명(803)을 확인함으로써 검증될 수 있다. 이 공개 서명 키는 토큰 수신자(예컨대, 트랜잭션 장치(450))와 공유될 필요가 있다. 공유는, 잠재적으로 첫 번째 서명된 구조가 생성되기 전에, 서명 키 쌍의 생성 후에 한 번 수행될 수 있다.
본 명세서에서 설명되는 기술들은 "풀-오프라인" 구현(즉, 트랜잭션 장치(450)가 트랜잭션 시에 신뢰자(451)에 접속하지 않음)뿐만 아니라 "세미-오프라인" 구현(즉, 트랜잭션 장치가 트랜잭션 시에 신뢰자(451)에 접속하지만, 클라이언트는 접속하지 않음) 둘 모두를 지원한다.
풀-오프라인 경우에서도, 트랜잭션 장치(450)는 여전히 호스트를 통해 때때로 신뢰자(451)에 접속될 것으로 예상된다. 예를 들어, 호스트는 트랜잭션 장치(450)에 저장된 모든 응답을 수집하여 그것들을 신뢰자로 전송할 수 있고, 또한 (필요하다면) 취소된 Uauth 키들(예를 들어, 마지막 접속 이후에 취소된 공개 인증 키들)의 리스트를 업데이트할 수 있다.
일부 실시예는 또한 순수(세션) 인증뿐만 아니라 트랜잭션 확인도 지원한다. 트랜잭션 확인의 경우에서도, 신뢰자(451)는, 트랜잭션 장치(450)가 인증 응답과 함께 트랜잭션 텍스트를 신뢰자(451)에 제출하면, 트랜잭션을 검증할 수 있다.
본 명세서에서 설명되는 기술들에 대한 몇 가지 상이한 사용 사례/응용이 존재한다. 예를 들어:
1. 지불. 사용자가 그의 인증기(예를 들어, 스마트폰)를 지불 서비스 제공자(PSP)에 등록하였다. 사용자는 PSP에 의해 허가된 PoS(Point-of-Sale) 장치를 사용하여 어떤 가맹점에서 지불을 인증하기를 원하지만, PoS는 PSP(예를 들어, 버스에 위치함)에 대한 신뢰성 있고 영구적인 온라인 접속을 갖지 않는다. 이 예에서, PoS는 트랜잭션 장치(450)로서 구현될 수 있고, PSP는 신뢰할 수 있고 영구적인 접속의 결여에도 불구하고 트랜잭션을 허용하기 위해 전술한 신뢰자(451)로서 구현될 수 있다.
2. 사물 인터넷. 회사가 (예를 들어, 공장, 건물 등에) 여러 개의 내장 장치를 설치하였다. 그러한 장치의 유지 관리는 계약 당사자가 고용한 기술자에 의해 수행된다. 유지 보수를 수행하기 위해, 기술자는 작업에 대한 그의 자격을 증명하기 위해 장치에 인증해야 한다. (현실적인 프레임 조건에 기초하여) 다음과 같은 가정을 한다:
a. 기술자는 (장치가 너무 많으므로) 그러한 장치들 각각에 등록을 수행할 수 없다.
b. 자격을 갖춘 기술자의 리스트를 장치들 각각에서 최신 상태로 유지하기에는 너무 많은 기술자 및 그러한 기술자의 너무 많은 변동이 존재한다.
c. 장치도 기술자의 컴퓨터도 유지 보수 시에 신뢰할 수 있는 네트워크 접속을 갖지 않는다.
전술한 기술을 사용하여, 회사는 모든 장치에 신뢰 앵커(예를 들어, 공개 RPVerifyKey)를 한 번(예를 들어, 설치 시에) 주입할 수 있다. 이어서, 각각의 기술자는 계약 당사자(예를 들어, 기술자의 고용주일 수 있는 신뢰자(451))에 등록한다. 위의 기술을 사용하여, 기술자는 각각의 장치에 대해 인증할 수 있을 것이다.
전술한 본 발명의 실시예들은, 인증 능력을 갖는 클라이언트가 신뢰자에 등록되고, 인증 동작이 이 클라이언트와, (a) 신뢰자를 대신하여 동작하고 (b) 트랜잭션 시에 오프라인 상태에 있는(즉, 클라이언트가 등록된 신뢰자의 원래의 서버에 대해 신뢰할 수 있는 네트워크 접속을 갖지 않는) 장치 사이에서 수행되는 임의의 시스템에서 구현될 수 있다. 그러한 경우에, 클라이언트는 캐싱 가능 인증 요청을 원래의 서버로부터 수신하여 이를 캐싱한다. 그것이 요구되면, 클라이언트는 인증 응답을 계산하여 이를 장치로 전송한다.
다른 실시예에서, 클라이언트는 (인증 요청 내에 수신된) 채널 결합 데이터를 암호 보호 방식으로 응답에 추가한다. 이렇게 함으로써, 신뢰자의 원래 서버는 요청이 (어떤 중간자가 아니라) 적법한 클라이언트에 의해 수신되었음을 검증할 수 있다.
일 실시예에서, 신뢰자는 승인된 Uauth.pub 키를 검색하기 위해 신뢰자 서버와 접촉해야 함이 없이 장치가 인증 또는 트랜잭션 확인 응답을 검증할 수 있게 하는 Uauth.pub 키와 같은 추가적인 인증 데이터를 응답에 추가한다. 다른 실시예에서, 신뢰자는 (서비스 거부 공격을 방지하기 위해) "캐싱 가능" 인증 요청을 발행하기 전에 클라이언트의 사용자가 성공적인 인증을 수행할 것을 요구한다. 일 실시예에서, 신뢰자는 클라이언트로 하여금 요청이 캐싱 가능할 필요가 있는지의 여부를 표시하도록 요구한다. 캐싱 가능하다면, 신뢰자는 응답에서 추가 인증 데이터(예를 들어, 상기에 논의된 MaxCacheTime)를 요구할 수 있다.
일 실시예에서, 트랜잭션 장치(450)와 같은 장치는 신뢰자에 대한 직접적인 네트워크 접속을 갖지 않고, 별도의 컴퓨터(때때로 본 명세서에서 "호스트"로 지칭됨)를 사용하여 신뢰자에 "동기화"된다. 이 호스트는 장치로부터 모든 수집된 인증 응답을 검색하여 이를 신뢰자에게 전송한다. 또한, 호스트는 또한 취소된 Uauth 키들의 리스트를 장치에 복사하여, 취소된 키들 중 하나가 인증 응답에서 사용되지 않는 것을 보장할 수 있다.
일 실시예에서, 트랜잭션 장치(450)와 같은 장치는 랜덤 값(예를 들어, 논스)을 클라이언트로 전송하고, 클라이언트는 이 랜덤 값을, 그것을 서명하기 전에 인증 응답에 확장으로서 암호 방식으로 추가한다. 이 서명된 랜덤 값은 장치에 대한 신선도 증거로서의 역할을 한다.
일 실시예에서, 클라이언트의 인증기는 현재 시간 Ta를, 그것을 서명하기 전에 인증 응답에 확장으로서 추가한다. 장치/트랜잭션 장치는 그 시간을 현재 시간 Td와 비교할 수 있고, Ta와 Td 사이의 차이가 승인 가능한 경우(예를 들어, 차이가 2분 미만(abs(Td-Ta)<2분)인 경우)에만 응답을 승인할 수 있다.
일 실시예에서, 신뢰자는 인증된(즉, 서명된) 만료 시간을 캐싱 가능 요청에 추가한다. 상기에 논의된 바와 같이, 장치/트랜잭션 장치는 만료 시간 전에 수신된 경우에만 응답을 유효한 것으로 승인할 것이다.
일 실시예에서, 신뢰자는 공개 키, 만료 시간, 최대 트랜잭션 값(예를 들어, SAML(Security Assertion Markup Language) 표명, OAuth 토큰, JWS(JSON Web Signature) 객체 등)과 같은(그러나 이로 제한되지 않는) 추가 정보를 포함하는 인증된(즉, 서명된) 데이터 블록(예를 들어, 상기에 언급된 "서명된 토큰 구조")을 캐싱 가능 요청에 추가한다. 장치/트랜잭션 장치는 서명된 데이터 블록이 긍정적으로 검증될 수 있고 콘텐츠가 승인 가능한 경우에만 응답을 유효한 것으로 승인할 수 있다.
일 실시예에서, 신뢰자는 캐싱 가능 인증 요청에 비서명된 토큰만을 추가하지만, 트랜잭션 장치는 트랜잭션 시에 신뢰자에 대한 온라인 접속을 갖는다. 트랜잭션 장치는 트랜잭션 시에 신뢰자에 대한 온라인 접속을 사용하여 비서명된 토큰의 진위를 검증한다.
도 9는 본 발명의 일 실시예에 따른 예시적인 "오프라인" 및 "세미-오프라인" 인증 시나리오를 도시한다. 이 실시예에서, 컴퓨팅 장치(910)를 갖는 사용자는 신뢰자(930)에 대한 설정된 관계를 가지며, 신뢰자에 대해 인증할 수 있다. 그러나, 일부 상황에서, 사용자는, 신뢰자(930)에 대한 설정된 관계를 갖지만 사용자의 컴퓨팅 장치(910)에 대한 설정된 관계를 반드시 갖지는 않는 장치(970)와의 트랜잭션(예를 들어, 트랜잭션 확인의 인증)을 수행하기를 원한다. 이 실시예와 관련하여, 트랜잭션은 접속(920) 및 접속(921)이 존재하지 않거나 관련 시간(예를 들어, 사용자의 컴퓨팅 장치(910)의 장치(970)에 대한 인증 또는 사용자의 컴퓨팅 장치(910)와 장치(970) 사이의 트랜잭션의 시간)에 안정되지 않을 경우에 "풀 오프라인"으로 지칭된다. 이 실시예와 관련하여, 트랜잭션은 사용자의 컴퓨팅 장치(910)와 신뢰자(930) 사이의 접속(920)이 안정적이지 않지만 장치(970)와 신뢰자(930) 사이의 접속(921)이 안정적이면 "세미-오프라인"이다. 이 실시예에서, 사용자의 컴퓨팅 장치(910)와 장치(970) 사이의 접속(922)은 관련 시간에 안정적일 것이 요구됨에 유의한다. 인증기가 사용자의 컴퓨팅 장치(910)에 접속될 것이 또한 예상된다. 접속(922)은 블루투스, 블루투스 저에너지(BTLE), 근거리장 통신(NFC), 와이파이, GSM(Global System for Mobile Communications), UTMS(Universal Mobile Telecommunications System), LTE(Long Term Evolution)(예를 들어, 4G LTE) 및 TCP/IP를 포함하지만 이로 제한되지 않는 임의 타입의 통신 채널/프로토콜을 이용하여 구현될 수 있다.
예시적인 데이터 처리 장치
도 10은 본 발명의 일부 실시예들에서 사용될 수 있는 예시적인 클라이언트들 및 서버들을 나타내는 블록도이다. 도 10은 컴퓨터 시스템의 다양한 컴포넌트들을 도시하지만, 이것은 컴포넌트들을 상호접속하는 임의의 특정 아키텍처 또는 방식을 나타내는 것을 의도하지 않는다는 것을 이해해야 하는데, 이는 그러한 상세들이 본 발명과 밀접한 관련이 없기 때문이다. 더 적은 컴포넌트들 또는 더 많은 컴포넌트들을 갖는 다른 컴퓨터 시스템들도 본 발명과 관련하여 사용될 수 있다는 것을 알 것이다.
도 10에 도시된 바와 같이, 데이터 처리 시스템의 형태인 컴퓨터 시스템(1000)은 처리 시스템(1020), 전원(1025), 메모리(1030) 및 비휘발성 메모리(1040)(예를 들어, 하드 드라이브, 플래시 메모리, 상변화 메모리(PCM) 등)와 결합되는 버스(들)(1050)를 포함한다. 버스(들)(1050)는 당업계에 주지된 바와 같은 다양한 브리지, 제어기 및/또는 어댑터를 통해 서로 접속될 수 있다. 처리 시스템(1020)은 메모리(1030) 및/또는 비휘발성 메모리(1040)로부터 명령어(들)를 검색하고, 명령어들을 실행하여 전술한 바와 같은 동작들을 수행할 수 있다. 버스(1050)는 위의 컴포넌트들을 함께 상호접속하고, 또한 그러한 컴포넌트들을 옵션인 도크(dock)(1060), 디스플레이 제어기 및 디스플레이 장치(1070), 입출력 장치들(1080)(예를 들어, 네트워크 인터페이스 카드(NIC), 커서 제어(예를 들어, 마우스, 터치스크린, 터치패드 등), 키보드 등) 및 옵션인 무선 송수신기(들)(1090)(예를 들어, 블루투스, 와이파이, 적외선 등)에 상호접속한다.
도 11은 본 발명의 일부 실시예들에서 사용될 수 있는 예시적인 데이터 처리 시스템을 나타내는 블록도이다. 예를 들어, 데이터 처리 시스템(190)은 핸드헬드 컴퓨터, 개인 휴대 단말기(PDA), 휴대 전화, 휴대용 게이밍 시스템, 휴대용 미디어 플레이어, 태블릿, 또는 휴대 전화, 미디어 플레이어 및/또는 게이밍 시스템을 포함할 수 있는 핸드헬드 컴퓨팅 장치일 수 있다. 다른 예로서, 데이터 처리 시스템(1100)은 네트워크 컴퓨터, 또는 다른 장치 내의 내장된 처리 장치일 수 있다.
본 발명의 일 실시예에 따르면, 데이터 처리 시스템(1100)의 예시적인 아키텍처는 전술한 모바일 장치들을 위해 사용될 수 있다. 데이터 처리 시스템(1100)은 하나 이상의 마이크로프로세서 및/또는 집적 회로 상의 시스템을 포함할 수 있는 처리 시스템(1120)을 포함한다. 처리 시스템(1120)은 메모리(1110), (하나 이상의 배터리를 포함하는) 전원(1125), 오디오 입출력(1140), 디스플레이 제어기 및 디스플레이 장치(1160), 옵션인 입출력(1150), 입력 장치(들)(1170) 및 무선 송수신기(들)(1130)와 결합된다. 도 11에 도시되지 않은 추가 컴포넌트들도 본 발명의 소정 실시예들에서 데이터 처리 시스템(1100)의 일부일 수 있으며, 본 발명의 소정 실시예들에서는 도 11에 도시된 것보다 적은 컴포넌트들이 사용될 수 있다는 것을 알 것이다. 게다가, 도 11에 도시되지 않은 하나 이상의 버스가 당업계에 주지된 바와 같은 다양한 컴포넌트들을 상호접속하는 데 사용될 수 있는 것을 알 것이다.
메모리(1110)는 데이터 처리 시스템(1100)에 의한 실행을 위해 데이터 및/또는 프로그램들을 저장할 수 있다. 오디오 입출력(1140)은 마이크 및/또는 스피커를 포함하여, 예를 들어 스피커 및 마이크를 통해 음악을 재생하고/하거나 전화 기능을 제공할 수 있다. 디스플레이 제어기 및 디스플레이 장치(1160)는 그래픽 사용자 인터페이스(GUI)를 포함할 수 있다. 무선(예를 들어, RF) 송수신기들(1130)(예를 들어, 와이파이 송수신기, 적외선 송수신기, 블루투스 송수신기, 무선 셀룰러 전화 송수신기 등)은 다른 데이터 처리 시스템들과 통신하는 데 사용될 수 있다. 하나 이상의 입력 장치(1170)는 사용자가 시스템에 입력을 제공하는 것을 가능하게 한다. 이러한 입력 장치들은 키패드, 키보드, 터치 패널, 멀티 터치 패널 등일 수 있다. 옵션인 다른 입출력(1150)은 도크에 대한 커넥터일 수 있다.
프로그램 코드 주입을 방지하기 위한 장치 및 방법
콘텐츠 보안 정책(Content Security Policy, CSP) 및 서브리소스 무결성(Subresource Integrity, SRI)과 같은 기존 웹 무결성 보호 방법들은 주요 하이퍼텍스트 마크업 언어(Hypertext Markup Language, HTML) 페이지에 의해 참조되는 외부 요소들의 무결성을 보호할 수 있다. 그러나, 그것들이 클라이언트에 의해 지원되고, 메인 HTML 페이지가 로딩 동안 중간자(MITM) 공격을 받지 않은 경우에만 작동된다. 공개 키 피닝, 인증서 투명성과 같은 기존 보호 기술들 및 심지어 토큰 바인딩도 이러한 공격으로부터 완전한 보호를 제공하지 않는다.
FIDO/웹 인증 응답을 제출할 때, 토큰 바인딩과 같은 기술이 필요하고, 서버가 생성된 인증된 세션이 인증기에 연결된 클라이언트에 의해 소유되지만 MITM 공격자와 같은 일부 제3자에 의해 소유되지 않음을 검증하게 한다.
악성 자바스크립트는 종종 중간자 공격의 결과로서 주입되는데, 브라우저는 특정 URL로부터 리소스를 페치하도록 시도하지만, 대신에 결국엔 악성 서버로부터 변형된 리소스를 페치하게 된다. 도 12는 MITM(1211)이 클라이언트/브라우저(1210)와 서버(1212) 사이의 통신을 가로채는 예를 도시한다.
브라우저들은 도메인 이름 서비스(DNS)를 이용하여 서버 이름들을 IP 어드레스들로 분해하고, 그것들은 전송 계층 보안(Transport Layer Security, TLS)을 이용하여 서버를 인증하고 클라이언트와 서버 사이에서 교환되는 트래픽을 암호화한다. 서버들은 클라이언트가 신뢰하는 TLS 인증 기관(CA)에서 발행된 TLS 서버 인증서를 이용하여 인증된다. 불행하게도, TLS CA는 때때로 악의적으로 인증서를 공격자에게 발행하며, 때때로 공격자는 신뢰자의 TLS 인증서 개인 키를 획득할 수 있다. 예를 들어, 도 12에서, MITM(1211)은 server.com에 대하여 악의적으로 발행된 인증서 또는 server.com으로부터 탈취한 인증서 및 개인 키를 사용할 수 있다.
공개 키 피닝은 악의적으로 발행된 TLS 서버 인증서로부터 보호하도록 설계되었지만, 대규모 채택을 방해하는 여러 불리한 점들을 갖는다. 인증서 투명성이 이러한 불리한 점들을 고치기 위하여 제안되었지만, 아직 널리 지원되지 않고 일부 약점들도 갖는다.
공개 키 피닝(PKP) 및 인증서 투명성(CT)에 대조적으로, 토큰 바인딩 접근법은 서버가 클라이언트가 올바른 엔티티와 통신하는지 여부를 학습할 수 있게 한다. PKP 및 CT의 경우, 서버는 클라이언트가 그 접근법에 대한 지원을 구현하는 것을 신뢰해야 한다. 불행하게도, 토큰 바인딩 혼자서는 MITM 보호를 효과적으로 제공하기에 충분하지 않다. 예를 들어, 통상적인 웹 페이지들은 잠재적으로 여러 소스들(예컨대 Google의 IMA SDK, Google Analytics 등)로부터의 자바스크립트 코드를 포함하고, 토큰 바인딩 데이터는 인증 응답을 수신할 때에만 확인된다. 접속 페이지에 액세스하는 것은 항상 어떠한 사용자 인증 없이도 가능하다.
FIDO 및 웹 인증은 웹 환경(및 기타 환경)에서 사용자를 인증하기 위한 단순하고 안전한 방법을 제공한다. 웹 인증 사양은 중간자(MITM) 공격자들이 보안/세션 토큰들을 유출 및 재생하는 것으로부터 강력한 보호를 추가하기 위하여 토큰 바인딩(RFC8471)에 대한 지원을 포함한다.
도 13은 통상적인 웹사이트 로딩 프로세스의 시퀀스를 도시한다. 서버(1311)에 대한 링크를 선택 시 클라이언트는 메인 HTML 파일을 로딩한다. 이어서 메인 자바스크립트 파일이 로딩된다. 이어서 클라이언트는 인증 응답을 전송하고 서버는 보호된 (예컨대, 성공적인 인증 후에만 액세스가능한 데이터) 콘텐츠를 반환한다.
실제로, 통상적인 웹 페이지들은 클라이언트(1310)에 의해 로딩될 둘 이상의 요소들로 구성된다. 웹 인증 어써션에 포함된 하나의 토큰 바인딩 데이터만이 있다 - 그것은 인증 응답을 송신할 때의 연결과 관련된다.
도 14에 표시된 바와 같이, 이는 메인 HTML 파일을 로딩할 때 또는 메인 JS 파일을 로딩할 때(둘 모두 미인증 클라이언트들에 이용가능함)의 MITM(1412) 공격은 웹 인증 응답에서 토큰 바인딩 데이터를 검증할 때 서버(1311)에 의해 검출되지 않을 것임을 의미한다. 결과적으로, 공격자들은 악성 자바스크립트 코드를 주입하고/하거나 잠재적 무결성 보호 정책들을 변조할 수 있다.
변조된 외부 객체들을 로딩하는 위험이 웹 앱 보안 커뮤니티에 의해 식별되었고, 이러한 유형들의 공격에 대한 2가지 메인 접근법들이 개발되었다.
한 가지 접근법인, 서브리소스 무결성(SRI)은 "무결성" 속성을 이용하여 HTML 코드 내의 외부 리소스들에 대한 예상 해시 값들의 명시를 허용한다. 메인 웹 페이지가 어떠한 변조 없이 로딩되었다는 가정 하에, 이 웹 페이지에 의해 요구되는 서브리소스들이 변조된 것들을 로딩하면 SRI는 브라우저가 거절하게 하고 잠재적으로 서버에 통지하게 한다. 오늘날 많은 브라우저들이 SRI를 지원한다. 불행하게도, 클라이언트(1310)가 서버(1311)에게 SRI에 대해 구현된 지원에 관하여 통지할 안전한 방법이 없고, 메인 HTML 페이지를 로딩할 때 클라이언트(1310)가 서버(1311)에게 수신된 SRI "무결성" 속성들에 관해 통지하기 위한 방법이 없다. 그 이유는 악성 자바스크립트가 항상 동일한 통지 호출을 트리거할 수 있다는 것이다. 결과적으로, MITM 공격자(1412)는 메인 HTML 페이지를 로딩할 때 SRI "무결성" 속성들을 변경할 수 있다.
다른 접근법은 HTTP 헤더에 명시된 콘텐츠 보안 정책(CSP)이고, 신뢰자들이 자바스크립트 코드와 같은, 외부 객체들에 대한 신뢰하는 소스들의 목록을 명시하게 할 수 있다. 이러한 코드의 해시 값은 또한 특정될 수 있다. 불행하게도, 정책 자체에 대한 MITM 공격으로부터 보호할 방법을 제공하지 않는다. 메인 HTML 파일의 로딩이 이미 MITM 공격을 받은 상태이면, 콘텐츠 보안 정책은 악의적으로 약화될 수 있다. CSP의 추가적인 약점들이 또한 드러났다.
CSP, SRI, 및 유사한 접근법들의 일반적인 단점은 서버(1311)가 (1) 클라이언트(1310)가 실제로 이러한 개념을 지원하고 컨텐츠를 검증했는지 및 (2) 페치된 (잠재적으로 MITM(1412)을 통해 페치된) 메인 웹 페이지가 실제로 올바른 무결성 보호 정책을 포함하고 있는지 알수 없다는 것이다.
주의할 점은 클라이언트가 완벽한 CSP 및 SRI 지원으로 메인 HTML 페이지를 로딩했을 때에도, 강력한 MITM 보호를 제공하기 위하여 웹 인증에서 여전히 토큰 바인딩 지원이 요구된다는 것이다. 도 15를 참조하면, MITM(1512)이 클라이언트(1310)로부터의 인증 응답의 전송을 노리는 경우, MITM(1512)은 인증된 세션을 소유할 것이다. 이러한 공격은 수정된 HTML 코드, 수정된 CSP 또는 SRI 정책들 또는 수정된 JS 코드 어느 것에도 의존하지 않을 것이다. DNS 오염(DNS poisoning) 및 탈취된 TLS 서버 인증서 개인 키에 대한 액세스(인증서 투명성 지원의 경우) 또는 서버의 도메인에 대하여 MITM(1412)에 악의적으로 발행된 TLS 서버 인증서에 대한 액세스(인증서 투명성 지원을 상실한 경우)가 충분하다. 불행하게도, 웹 브라우저에서의 토큰 바인딩 지원은 드물다. 결과적으로, 웹 애플리케이션으로 AAL3 (NIST 800-63)과 같은 인증 보증 레벨에 도달하는 것은 현재 비현실적이다.
높은 보안이 필요한 엔티티들에 추가적인 챌린지는 그것들이 통상적으로 컴퓨팅 환경을 가능한 많이 제어할 필요가 있다는 것이다. 이는 또한 (손상되지 않은) 클라이언트(1310)가 보안 수단을 구현하는지 그리고 그것들은 통상적으로 그것들이 의존하는 모든 당사자들과 계약적 관계를 원하는지 여부를 알 필요가 있음을 의미한다. 허용가능한 TLS CA들의 목록을 정의하는 각각의 TLS CA 또는 브라우저 벤더와 쌍방 계약에 서명하는 것은 다소 비현실적으로 보인다.
도 16을 참조하면, 이러한 제한들을 해결하기 위하여, 서버(1611)의 일 실시예는 클라이언트(1610) 상에서 실행되는 동적으로-로딩된 코드의 보안 특성들을 평가하기 위한 클라이언트 평가기(1650)를 포함한다. 일 실시예는 전술된 한계들을 해결하기 위하여 다음 대응책들을 구현한다. 먼저, 클라이언트 평가기(1650)는 클라이언트(1610)가 지원하는 무결성 보호 수단을 결정한다. 또한, 웹 페이지 평가기(1652)는 웹 페이지에 의해 부과된 무결성 보호 정책(예컨대 CSP 또는 SRI)을 결정하고, 또한 웹 페이지가 변조되었는지 여부를 결정하기 위하여 웹 페이지를 평가한다. 또한, 웹 페이지 평가기는 웹 페이지와 연관된 모든 외부 객체들의 해시 값들에 대한 액세스가 제공되고/되거나 웹 페이지와 연관된 모든 외부 객체들의 해시 값들을 결정할 수 있는데, 이는 CSP 및 SRI 지원을 상실한 경우에 관련된다.
일 실시예는 서버(1611)가 인증 응답이 인증기(1630)를 포함하는 클라이언트(1610)로부터 직접 수신되었는지 아니면 일부 MITM을 통해 간접적으로 수신되었는지 검증하게 할 수 있는 토큰 바인딩 지원을 구현한다. 클라이언트(1610) 및 서버(1611)의 상세사항들이 이제 본 발명의 실시예들에 따라 제공될 것이다.
I. 클라이언트(1610)
클라이언트(1610) 인증 엔진(1613)의 일 실시예는 웹 인증 데이터(WAD) 딕셔너리(1620)(예컨대, 기존 웹 인증 사양 내의 CollectedClientData 딕셔너리)로의 확장 또는 지원되는 무결성 보호 능력들(1620A)의 목록 및 연관된 버전 번호들(예컨대 CSP, SRI, 인증서투명성, 토큰 바인딩 등)을 포함하는 TokenBinding 확장을 포함한다. 또한, WAD 딕셔너리(1620)의 일 실시예는 웹 페이지의 로딩과 연관된 리소스 디스크립터들(1620B)의 목록을 포함하고, 각각의 리소스 디스크립터는 다음 요소들 중 하나 이상을 포함한다:
a. 대응하는 리소스를 처리하는 순서에 관련된 시퀀스 번호. 예를 들어, 1차 HTML 페이지는 시퀀스 번호 1을 가질 수 있고, 처리되는 제1 외부 리소스는 시퀀스 번호 2를 갖는 방식일 것이다.
b. 리소스가 로딩된 URL(예컨대 "https://www.rp. com/index.html", "https://panopticum.com/tracker.js" 등).
c. (예컨대, CSP 정책들의) HTTP 헤더에 포함된 잠재적 무결성 정책 명령들의 해시 값.
d. 리소스와 연관된 요소들의 유형(예컨대, 자바스크립트, HTML, 이미지, 웹 어셈블리 등).
e. 제1 바이트부터 마지막 바이트까지 포함하는, 클라이언트에 의해 연산되는 전체 요소/파일의 실제 해시.
f. (예컨대, SRI "무결성" 속성을 이용하여 명시되는) 요소들의 예상 해시.
g. 각각의 리소스 디스크립터(1620B)에 대하여, 잠재적으로 이 객체에서 자바스크립트/ 웹어셈블리 코드 프래그먼트당 엔트리 하나씩 코드 디스크립터들(1620C)의 목록이 또한 포함될 수 있고, 각각은 다음 요소들 중 하나 이상을 포함한다:
1. 클라이언트에 의해 연산되는 요소의 실제 해시(예컨대 <script> 태그와 </script> 태그 사이의 실제 코드의 해시, 또는 속성에 할당된 경우 코드의 전체 스트링),
2. 각각의 코드 프래그먼트와 연관된 태그(예컨대, 코드가 스크립트 태그들에 포함된 경우에는 "script", 코드가 이러한 태그들의 속성에 포함된 경우, "body", "frame", "img", "input" 등).
3. 명시된 경우, 태그의 관련된 "ID".
4. 코드가 이러한 속성에 명시된 경우, 관련 속성(예컨대, "onload" 속성, "onclick" 속성 등).
일 실시예에서, 그 웹 페이지의 상황에 로딩된 모든 코드가 인증 엔진(1613) 및 서버 측 인증 엔진(1650)에 의한 평가를 위해 포함된다. 예를 들어, "get" / "create" 호출 시 처리된(반드시 실행되는 것은 아님) 모든 HTML 요소들 및 코드 프래그먼트들이 포함될 수 있다. 때때로, 코드는 예컨대 사용자가 요소를 클릭할 때 동적으로 로딩된다. 일 구현예에서, 이러한 코드 프래그먼트들은 "get" / "create" 호출 시 그것들이 로딩된 경우에만 포함된다.
기존 자바스크립트 코드가 동적으로 새로운 자바스크립트 코드 요소들을 추가하는 경우에, 이렇게 동적으로 추가된 요소들은 또한 코드 디스크립터들(1620C)의 목록 내의 엔트리들로서 포함된다. 클라이언트 측 상의 동적으로 생성된 코드에 대한 이러한 코드 디스크립터들은 (리소스가 동적으로 생성되었고 원격 소스로부터 직접 로딩되지 않았기 때문에) 비어있는 URL을 갖는 전용 리소스 디스크립터에 관한 것이다.
II. 서버(1611)
도 16에 도시된 바와 같이, 서버(1611) 상의 인증 엔진(1650)은 무결성 보호 능력들(1620A), 리소스 디스크립터들(1620B), 및/또는 코드 디스크립터들(1620C)을 포함하는 확장된 WAD 딕셔너리(1620)의 임의의 부분을 이용하여 클라이언트를 인증할 수 있다. 무결성 보호 능력들(1620A)은 인증 엔진(1650)의 클라이언트 평가기 컴포넌트(1651)에 의해 평가될 수 있고, 리소스 디스크립터들(1620B) 및 코드 디스크립터들(1620C)은 웹 페이지 평가기 컴포넌트(1652)에 의해 평가될 수 있다. 예를 들어, 일 실시예에서, 웹 페이지 평가기(1652)는 예상 리소스 디스크립터들(1652B) 및 예상 코드 디스크립터들(1652C)에 관련된 데이터 세트를 유지한다. 서버(1611) 상의 인증 엔진(1650)은 이어서 클라이언트(1610)로부터 수신된 인증 데이터(예컨대, 리소스 디스크립터들(1620B) 및/또는 코드 디스크립터들(1620C)에 기초한 서명, 해시 값 등)를 예상 리소스 디스크립터들(1652B) 및 코드 디스크립터들(1652C)과 연관된 그것 자체의 데이터와 비교할 수 있다. 이 추가 보안 층에 관심이 있는 신뢰자들은 로딩된(자바스크립트) 코드의 정확성을 검증하기 위하여 상이한 접근법들을 구현할 수 있다.
서버(1611) 상의 인증 엔진(1650)이 "엄격한" 방식을 구현하는 경우, 모든 리소스 디스크립터들(1620B) 및 코드 디스크립터들(1620C)의 예상 엔트리들이 결정 및 비교된다. 자바스크립트 코드는 주어진 해시 값을 갖는 잘 정의된 수의 외부 파일들에 제한될 수 있다. 이 접근법은 높은 보안 요건들을 갖는 엔티티들에 의해 그리고 직진 방식으로 사양들을 구현하는 서버들에 의해 구현될 수 있다.
머신 러닝 접근법이 인증 엔진(1650)의 일 실시예에서 사용된다. 예를 들어, 머신 러닝 기반 인증 엔진(1650)은 무결성 보호 수단(1620A)의 지원을 확인, 이 수단과의 연관된 무결성 보호 정책 명령들의 무결성을 확인, 및/또는 처음 또는 매우 드물게 보이는 코드 디스크립터들(1620C)의 목록 내의 파일 이름 및 관련 해시 값의 쌍들(예컨대, 이는 스피어 피싱 공격을 나타낼 수 있음)을 확인할 수 있다. 이어서 이러한 상황들은 오늘날 안티바이러스 스캐너에 의한 바이러스 패턴들의 분석과 유사한 방식으로 처리될 수 있다 - 즉, 트랜잭션은 "고위험"으로서 표시되며, 이는 이어서 추가적인 보호 수단을 구현하도록 인증 엔진을 트리거하게 된다.
위 내용의 하나의 장점은 이 접근법이 이러한 보안 수준에 관심이 없는 신뢰자들을 처벌/손해를 가하지 않는다는 사실이다. 이 신뢰자들은 단순히 추가 데이터 요소들을 무시할 것이다. 이러한 실시예들은 또한 다른 URL들로부터 제3자 자바스크립트 코드를 로딩하는 것과 같은, 현재 웹 실행과 호환된다. 이러한 제3자들이 코드 서명을 추가하거나 또는 다른 방식으로 그들의 코드를 변경하도록 요구하지 않는다. 높은 보안 수준을 요구하는 신뢰자들은 상기 실시예들을 이용하고 엄격한 확인을 구현할 수 있다 - 이러한 보호 수준을 요구하는 애플리케이션들/웹 페이지들에 제한된다.
머신 러닝 기반 접근법에 관심이 있는 신뢰자들은 여전히 기존 제3자 자바스크립트 모듈들을 활용할 수 있다 - 이러한 에코시스템 파트너들이 추가적인 보안 수준들을 구현하는 것을 기대하지 않는다. 이러한 모듈들의 예상 해시 값들은 파일에 직접 포함될 필요는 없다(이와 같이 동적 생성을 요구할 것임). 대신에 인증 응답을 검증할 때 검증이 FIDO 서버에 의해 수행될 수 있다.
이러한 접근법은 또한 동적으로 생성된 HTML과 호환가능한데, 그 이유는 전체(잠재적으로 동적으로 생성된) HTML 객체의 검증이 필요하지 않기 때문이다. 수정되지 않은 자바스크립트가 실행되는 경우, 생성된 문서 객체 모델(DOM) 트리의 보안 관련 부분들은 자바스크립트에 의해 동적으로 검증될 수 있다.
상기 접근법은 또한 클라이언트(1610)의 인증기들(1613)의 암호화 서명 능력들을 활용한다. 이는 (클라이언트 자체는 서버로 다시 제공되는 임의의 정보도 인증하는 데 사용될 수 있는 암호화 비밀을 갖고 있지 않음에 따라) 어떤 웹 페이지가 클라이언트(1610)에 의해 로딩되고 렌더링되는지에 대하여 서버(1611)에 증명을 제공하는 방법이다.
이 접근법은 또한 개인 정보 친화적이다. 추가적인 데이터 요소들은 개인 정보나 사용자의 개인 식별 정보를 포함하지 않고; 로딩된 웹 페이지의 콘텐츠에 관련된 데이터만을 포함한다. 사용자 인증이 필요 없는 웹 페이지들은 추가적인 데이터 요소들을 참조하지 않을 것이고, 사용자 인증이 필요한 웹 페이지들은 로딩된 웹 페이지의 무결성을 검증하기 위하여 추가적인 데이터 요소들을 사용할 수 있다.
본 발명의 일 실시예는 접속 URL들의 세트가 주어지면 웹 페이지들을 규칙적으로 분석하고, 예상 코드 프래그먼트들 및 그것들의 해시 값들의 목록을 생성하고, 제안된 무결성 보호 정책(CSP)을 생성하는 툴을 포함한다.
일 구현예에서, 공지된 양호한 자바스크립트 URL들 및 해시 값들의 저장소는 초기에 저장소에 제공된다. 인터넷 상에서 나타나는 코드 프래그먼트들 및 값들은 "공지된 양호한" 상태를 유지하기 위하여 이 저장소와 동기화될 수 있다. 일 실시예는 규칙적으로 분석되는 웹 페이지들에 기초한 문서 객체 모델의 보안 관련 부분들을 검증하는 자바스크립트 코드를 포함한다.
일 실시예에서, JavaScript secureLoad 함수는 소프트웨어 개발 키트(SDK)의 형태로 제공된다. 이 secureLoad 함수는 파라미터로서 제공된 예상 해시 값에 대하여 로딩된 객체를 검증한다. 이러한 함수는 자바스크립트 함수를 이용하여 외부 리소스들(예컨대 이미지, 텍스트, JS, ...)을 동적으로 로딩하기 위한 보안 접근법을 단순화한다.
본 발명의 이러한 실시예들은 또한 클라이언트 장치가 안전하다고 가정될 수 있고 증명을 직접 지원하지 않는 다른 영역들로 확장될 수 있다. 클라이언트 장치는 또한 (FIDO 인증기 또는 TPM과 같은) 암호화 어써션을 생성할 수 있는 모듈/장치에 액세스한다고 가정되고, 잠재적으로 감염/수정될 수 있는 다양한 소스들로부터 로딩된 임의의 코드의 실행을 허용한다. 커스텀 코드의 실행을 지원하는 IoT 장치가 일례이다.
본 발명의 일 실시예는 웹 서버들 또는 기타 외부 엔티티들로부터 콘텐츠 및 프로그램 코드를 로딩하는 웹 브라우저 또는 기타 소프트웨어를 구비한 클라이언트를 포함한다. 클라이언트/브라우저는 암호화 연산시 하나 이상의 리소스 디스크립터(1620B) 및/또는 코드 디스크립터(1620C) 객체들을 포함하는 암호화 어써션(예컨대 FIDO 인증기)에 서명할 수 있는 신뢰하는 엔티티와 접속된다. 예를 들어, 일 실시예는 서명될 객체에 이러한 리소스 디스크립터(들) / 코드 디스크립터(들)의 암호화 해시 값을 포함한다.
또한, 일 실시예는 암호화 어써션을 검증하고, 암호화 어써션이 예상 리소스 디스크립터들로서 명시된 리소스 디스크립터들(1620B) 및/또는 코드 디스크립터들(1620C)만을 포함한다고 검증하는 FIDO 서버와 같은 서버 측 컴포넌트를 포함한다. 인증 엔진은 악성 리소스 디스크립터들 및/또는 코드 디스크립터들이 발견되었을 가능성을 나타내는 위험 점수를 반환할 수 있다.
일 실시예는 암호화 어써션을 검증하고, 암호화 어써션이 (예컨대 머신 러닝을 이용하여 "여러 차례"가 의미하는 것 및 "신뢰된 위치들"이 무엇인지 결정하기) 전에 서버가 이미 여러 차례 신뢰된 위치들로부터 참조했던 리소스 디스크립터(들) / 코드 디스크립터(들)만을 포함하는 것을 검증하는 인증 엔진(1650)(예컨대 FIDO 서버)과 같은, 서버 측 소프트웨어 컴포넌트를 포함한다. 소프트웨어 컴포넌트는 악성 리소스 디스크립터들 / 코드 디스크립터들이 발견되었을 가능성을 나타내는 위험 점수를 반환한다.
본 발명의 일 실시예는 어떤 리소스들 및 코드 프래그먼트들이 통상적으로 사용되고 있는지 학습하기 위하여 MITM 공격으로부터 보호되는 내부 채널(예컨대 접속에 사용되는 것들)을 통해 관련 웹 페이지들을 로딩하는 소프트웨어 툴을 포함한다. 이 소프트웨어 툴은 예상 리소스 디스크립터들 / 예상 코드 디스크립터들의 데이터베이스 및 평문의 관련 소스 코드를 서버 측 인증 엔진에 의해 사용될 수 있는 웹 사이트들에 자동으로 공급한다.
DOM 트리의 보안 관련 부분들이 공격자에 의해 수정되지 않았음을 검증하기 위하여 클라이언트에 의해 실행될 웹 사이트에 의해 포함될 수 있는 자바스크립트 함수(예컨대, "Buy Now" 버튼이 여전히 존재하는지 그리고 주어진 ID를 갖는 유일한 요소인지 여부, 트랜잭션의 콘텐츠를 보여주기 위한 요소들이 DOM 트리 내에 존재하는지 그리고 사용자에게 보이는지 여부, 동적으로 생성된 자바스크립트 코드가 구체적인 패턴을 따르는지 여부 등). 전술된 기술들 중 임의의 것이 자바스크립트 코드를 확인하는 데 사용될 수 있다.
일 실시예에서, 웹 상의 악의적으로 발견된 자바스크립트 코드의 리소스 디스크립터들 / 코드 디스크립터들을 악성 리소스 디스크립터들 / 코드 디스크립터들의 목록을 유지하는 중앙 서버에 업로드하는 서버 측 인증 엔진에서 피드백 기능이 구현된다.
일 구현예는 유사한(그러나 정확히 동일하지 않은) 코드 프래그먼트들(예컨대 개명된 일부 내부 변수들, 내부 순서 또는 구조의 약간의 변경 등)을 식별하도록 도울 수 있는 "패턴들"을 생성하기 위하여 악성 리소스 디스크립터들 / 코드 디스크립터들의 목록(예컨대, 전술된 바와 같이 수집됨)을 분석하는 소프트웨어 툴을 포함한다. 소프트웨어 툴은 리소스 디스크립터들 / 코드 디스크립터들의 목록을 분석하고, 이러한 코드가 하나 이상의 패턴들과 매칭되는지 검증하기 위하여 이 리소스 디스크립터들 / 코드 디스크립터들에 주어진 URL들로부터 관련된 소스 코드를 로딩할 수 있다.
일 실시예는 또한 이미지, 텍스트 또는 코드(예컨대 자바스크립트, 웹어셈블리, ... 등)와 같은 외부 리소스들의 안전한 로딩을 허용하는 소프트웨어 SDK를 포함한다. 이 SDK는 URL 및 그 리소스의 예상 해시 값을 수신한다. 대안적으로, 또는 추가적으로, SDK는 로딩될 외부 리소스들의 코드 서명을 검증하기 위하여 URL 및 트러스트 앵커(예컨대 코드 서명 인증서, 코드 서명 CA 인증서, 또는 루트 인증서)를 수신한다.
본 발명의 실시예들은 전술한 바와 같은 다양한 단계들을 포함할 수 있다. 단계들은 범용 또는 특수 목적 프로세서가 소정 단계들을 수행하게 하는 기계 실행 가능 명령어들로 구현될 수 있다. 대안적으로, 이러한 단계들은 단계들을 수행하기 위한 하드와이어드 로직을 포함하는 특정 하드웨어 컴포넌트들에 의해, 또는 프로그래밍된 컴퓨터 컴포넌트들과 맞춤형 하드웨어 컴포넌트들의 임의의 조합에 의해 수행될 수 있다.
본 발명의 요소들은 또한 기계 실행 가능 프로그램 코드를 저장하기 위한 기계 판독 가능 매체로서 제공될 수 있다. 기계 판독 가능 매체는 플로피 디스켓, 광 디스크, CD-ROM 및 광자기 디스크, ROM, RAM, EPROM, EEPROM, 자기 또는 광학 카드, 또는 전자 프로그램 코드를 저장하기에 적합한 다른 타입의 매체/기계 판독 가능 매체를 포함할 수 있지만 이에 한정되지 않는다.
위의 설명 전반에서는, 설명의 목적으로, 본 발명의 완전한 이해를 제공하기 위해 다수의 구체적 상세들이 설명되었다. 그러나, 본 발명은 이러한 구체적 상세사항들 중 일부 없이도 실시될 수 있다는 것이 당업자에게 명백할 것이다. 예를 들어, 본 명세서에서 설명되는 기능 모듈들 및 방법들은 소프트웨어, 하드웨어 또는 이들의 임의 조합으로서 구현될 수 있다는 것을 당업자가 손쉽게 알 수 있을 것이다. 더욱이, 본 명세서에서는 본 발명의 일부 실시예들이 모바일 컴퓨팅 환경의 상황 내에서 설명되지만, 본 발명의 기본 원리들은 모바일 컴퓨팅 구현으로 한정되지 않는다. 예를 들어 데스크탑 또는 워크스테이션 컴퓨터들을 비롯한 사실상 임의 타입의 클라이언트 또는 피어 데이터 처리 장치들이 일부 실시예들에서 사용될 수 있다. 따라서, 본 발명의 범주 및 사상은 아래의 청구범위의 관점에서 판단되어야 한다.
본 발명의 실시예들은 전술한 바와 같은 다양한 단계들을 포함할 수 있다. 단계들은 범용 또는 특수 목적 프로세서가 소정 단계들을 수행하게 하는 기계 실행 가능 명령어들로 구현될 수 있다. 대안적으로, 이러한 단계들은 단계들을 수행하기 위한 하드와이어드 로직을 포함하는 특정 하드웨어 컴포넌트들에 의해, 또는 프로그래밍된 컴퓨터 컴포넌트들과 맞춤형 하드웨어 컴포넌트들의 임의의 조합에 의해 수행될 수 있다.

Claims (21)

  1. 장치로서,
    사용자 입력에 응답하여 인터넷 상의 웹 페이지에 액세스하는 애플리케이션을 실행하기 위한 프로세서 - 상기 웹 페이지는 그와 연관된 하나 이상의 리소스 디스크립터들 및/또는 코드 디스크립터들을 가짐 -;
    신뢰하는 엔티티에 접속함으로써, 적어도 부분적으로, 상기 리소스 디스크립터들 및/또는 코드 디스크립터들에 기초하여 상기 웹 페이지를 확인하기 위한 인증 엔진을 포함하고,
    상기 신뢰하는 엔티티는 상기 하나 이상의 리소스 디스크립터들과 연관된 하나 이상의 리소스 디스크립터 객체들 및/또는 상기 하나 이상의 코드 디스크립터들과 연관된 하나 이상의 코드 디스크립터 객체들을 포함하는 암호화 어써션 상의 서명을 생성하도록 구성된, 장치.
  2. 제1항에 있어서, 상기 인증 엔진은 상기 암호화 어써션 상의 상기 서명을 이용하여 상기 웹 페이지를 확인하는, 장치.
  3. 제1항에 있어서, 상기 서명은 상기 하나 이상의 리소스 디스크립터들 및/또는 코드 디스크립터들의 암호화 해시 값을 포함하는, 장치.
  4. 제1항에 있어서, 상기 신뢰하는 엔티티는 상기 암호화 어써션이 예상 리소스 디스크립터들 및/또는 코드 디스크립터들로서 명시된 상기 하나 이상의 리소스 디스크립터들 및/또는 코드 디스크립터들만을 포함한다는 검증을 포함하는, 상기 암호화 어써션을 검증하기 위하여 서버 측 인증 엔진 상에서 실행되는 서버를 포함하는, 장치.
  5. 제4항에 있어서, 상기 서버 측 인증 엔진은 이에 응답하여 악성 리소스 디스크립터들 및/또는 코드 디스크립터들이 식별되었을 가능성을 나타내는 위험 점수(risk score)를 생성하는, 장치.
  6. 제5항에 있어서, 상기 서버 측 인증 엔진은 상기 암호화 어써션이 결정된 수의 이전 시간들에 결정된 신뢰된 위치들의 세트로부터 이전에 관찰된 리소스 디스크립터들 및/또는 코드 디스크립터들만을 포함한다는 것을 검증하기 위한 머신 러닝 엔진을 포함하고, 상기 머신 러닝 엔진은 상기 결정된 수의 이전 시간들 및 상기 결정된 신뢰된 위치들의 세트를 지속적으로 업데이트하기 위하여 머신 러닝을 수행하는, 장치.
  7. 제6항에 있어서, 상기 프로세서는 문서 객체 모델(document object model, DOM) 트리의 하나 이상의 보안 관련 부분들이 수정되지 않았음을 검증하기 위하여 상기 웹 페이지에 포함된 함수를 포함하는 프로그램 코드를 실행하고, 상기 프로그램 코드는 상기 서명을 이용하여 확인되는, 장치.
  8. 서버 장치로서,
    클라이언트로부터 인증 요청을 수신하기 위한 인터페이스; 및
    상기 클라이언트에 의해 수신된 웹 페이지의 하나 이상의 리소스 디스크립터들과 연관된 하나 이상의 리소스 디스크립터 객체들 및/또는 상기 웹 페이지의 상기 하나 이상의 코드 디스크립터들과 연관된 하나 이상의 코드 디스크립터 객체들을 포함하는 암호화 어써션 상의 서명을 생성하기 위한 인증기 엔진을 포함하고,
    상기 인증기 엔진은 상기 웹 페이지의 확인을 위해 상기 인터페이스를 통해 상기 클라이언트에 상기 서명을 전송하는, 서버 장치.
  9. 제8항에 있어서, 상기 인증기 엔진 또는 상기 클라이언트 상의 인증기 엔진는 상기 암호화 어써션 상의 상기 서명을 이용하여 상기 웹 페이지를 확인하는, 서버 장치.
  10. 제8항에 있어서, 상기 서명은 상기 하나 이상의 리소스 디스크립터들 및/또는 코드 디스크립터들의 암호화 해시 값을 포함하는, 서버 장치.
  11. 제8항에 있어서, 상기 인증 엔진은 상기 암호화 어써션이 예상 리소스 디스크립터들 및/또는 코드 디스크립터들로서 명시된 상기 하나 이상의 리소스 디스크립터들 및/또는 코드 디스크립터들만을 포함한다는 검증을 포함하는, 상기 암호화 어써션을 검증하도록 구성된, 서버 장치.
  12. 제11항에 있어서, 상기 인증 엔진은 이에 응답하여 악성 리소스 디스크립터들 및/또는 코드 디스크립터들이 식별되었을 가능성을 나타내는 위험 점수를 생성하는, 서버 장치.
  13. 제12항에 있어서, 상기 인증 엔진은 상기 암호화 어써션이 결정된 수의 이전 시간들에 결정된 신뢰된 위치들의 세트로부터 이전에 관찰된 리소스 디스크립터들 및/또는 코드 디스크립터들만을 포함한다는 것을 검증하기 위한 머신 러닝 엔진을 포함하고, 상기 머신 러닝 엔진은 상기 결정된 수의 이전 시간들 및 상기 결정된 신뢰된 위치들의 세트를 지속적으로 업데이트하기 위하여 머신 러닝을 수행하는, 서버 장치.
  14. 제13항에 있어서, 상기 클라이언트는 문서 객체 모델(DOM) 트리의 하나 이상의 보안 관련 부분들이 수정되지 않았음을 검증하기 위하여 상기 웹 페이지에 포함된 함수를 포함하는 프로그램 코드를 실행하기 위한 프로세서를 포함하고, 상기 프로그램 코드는 상기 서명을 이용하여 확인되는, 서버 장치.
  15. 방법으로서,
    클라이언트로부터 인증 요청을 수신하는 단계;
    상기 클라이언트에 의해 수신된 웹 페이지의 하나 이상의 리소스 디스크립터들과 연관된 하나 이상의 리소스 디스크립터 객체들 및/또는 상기 웹 페이지의 상기 하나 이상의 코드 디스크립터들과 연관된 하나 이상의 코드 디스크립터 객체들을 포함하는 암호화 어써션을 식별하는 단계;
    상기 암호화 어써션에 대한 서명을 생성하는 단계 - 상기 서명은 상기 웹 페이지를 확인하는 데 이용가능함 -; 및
    상기 웹 페이지의 확인을 위해 상기 클라이언트에 상기 서명을 전송하는 단계를 포함하는, 방법.
  16. 제15항에 있어서, 상기 인증기 엔진 또는 상기 클라이언트 상의 인증기 엔진는 상기 암호화 어써션 상의 상기 서명을 이용하여 상기 웹 페이지를 확인하는, 방법.
  17. 제15항에 있어서, 상기 서명은 상기 하나 이상의 리소스 디스크립터들 및/또는 코드 디스크립터들의 암호화 해시 값을 포함하는, 방법.
  18. 제15항에 있어서, 상기 인증 엔진은 상기 암호화 어써션이 예상 리소스 디스크립터들 및/또는 코드 디스크립터들로서 명시된 상기 하나 이상의 리소스 디스크립터들 및/또는 코드 디스크립터들만을 포함한다는 검증을 포함하는, 상기 암호화 어써션을 검증하도록 구성된, 방법.
  19. 제18항에 있어서, 상기 인증 엔진은 이에 응답하여 악성 리소스 디스크립터들 및/또는 코드 디스크립터들이 식별되었을 가능성을 나타내는 위험 점수를 생성하는, 방법.
  20. 제19항에 있어서, 상기 인증 엔진은 상기 암호화 어써션이 결정된 수의 이전 시간들에 결정된 신뢰된 위치들의 세트로부터 이전에 관찰된 리소스 디스크립터들 및/또는 코드 디스크립터들만을 포함한다는 것을 검증하기 위한 머신 러닝 엔진을 포함하고, 상기 머신 러닝 엔진은 상기 결정된 수의 이전 시간들 및 상기 결정된 신뢰된 위치들의 세트를 지속적으로 업데이트하기 위하여 머신 러닝을 수행하는, 방법.
  21. 제15항에 있어서, 상기 클라이언트는 문서 객체 모델(DOM) 트리의 하나 이상의 보안 관련 부분들이 수정되지 않았음을 검증하기 위하여 상기 웹 페이지에 포함된 함수를 포함하는 프로그램 코드를 실행하기 위한 프로세서를 포함하고, 상기 프로그램 코드는 상기 서명을 이용하여 확인되는, 방법.
KR1020227023825A 2019-12-18 2020-12-04 악성 프로그램 코드 주입으로부터의 보호를 위한 시스템 및 방법 KR20220116483A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/719,599 US20210194919A1 (en) 2019-12-18 2019-12-18 System and method for protection against malicious program code injection
US16/719,599 2019-12-18
PCT/US2020/063485 WO2021126568A1 (en) 2019-12-18 2020-12-04 System and method for protection against malicious program code injection

Publications (1)

Publication Number Publication Date
KR20220116483A true KR20220116483A (ko) 2022-08-23

Family

ID=76438972

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227023825A KR20220116483A (ko) 2019-12-18 2020-12-04 악성 프로그램 코드 주입으로부터의 보호를 위한 시스템 및 방법

Country Status (6)

Country Link
US (1) US20210194919A1 (ko)
EP (1) EP4078373A4 (ko)
JP (1) JP2023507568A (ko)
KR (1) KR20220116483A (ko)
CN (1) CN114830092A (ko)
WO (1) WO2021126568A1 (ko)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7958363B2 (en) * 2007-10-26 2011-06-07 Yahoo! Inc. Toolbar signature
US9300644B1 (en) * 2013-02-22 2016-03-29 Symantec Corporation Knowledge-based authentication based on tracked credential usage
US9621566B2 (en) * 2013-05-31 2017-04-11 Adi Labs Incorporated System and method for detecting phishing webpages
US9577999B1 (en) * 2014-05-02 2017-02-21 Nok Nok Labs, Inc. Enhanced security for registration of authentication devices
US9875347B2 (en) * 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US9935995B2 (en) * 2014-12-23 2018-04-03 Mcafee, Llc Embedded script security using script signature validation
US10678910B2 (en) * 2015-04-10 2020-06-09 Micro Focus Llc Modifying web page code to include code to protect output
WO2017049045A1 (en) * 2015-09-16 2017-03-23 RiskIQ, Inc. Using hash signatures of dom objects to identify website similarity
US10104113B1 (en) * 2016-05-26 2018-10-16 Area 1 Security, Inc. Using machine learning for classification of benign and malicious webpages
US11321400B2 (en) * 2019-07-16 2022-05-03 Innoplexus Ag System and method for crawling web-content
US11030087B2 (en) * 2019-08-02 2021-06-08 Jpmorgan Chase Bank, N.A. Systems and methods for automated invocation of accessibility validations in accessibility scripts

Also Published As

Publication number Publication date
CN114830092A (zh) 2022-07-29
JP2023507568A (ja) 2023-02-24
EP4078373A4 (en) 2024-01-03
EP4078373A1 (en) 2022-10-26
WO2021126568A1 (en) 2021-06-24
US20210194919A1 (en) 2021-06-24

Similar Documents

Publication Publication Date Title
KR102358546B1 (ko) 장치에 대해 클라이언트를 인증하기 위한 시스템 및 방법
KR102382474B1 (ko) 보안 전송 프로토콜을 사용하여 신뢰를 설정하기 위한 시스템 및 방법
KR102383021B1 (ko) 인증 장치의 등록을 위한 향상된 보안
US9836594B2 (en) Service channel authentication token
US9548997B2 (en) Service channel authentication processing hub
KR102439782B1 (ko) 호스팅된 인증 서비스를 구현하기 위한 시스템 및 방법
CN113474774A (zh) 用于认可新验证器的系统和方法
US11792024B2 (en) System and method for efficient challenge-response authentication
KR20110081104A (ko) 보안 트랜잭션 시스템 및 방법
KR20080033541A (ko) 확장된 일회용 암호 방법 및 장치
KR20170140215A (ko) 거래 시큐리티를 위한 방법 및 시스템
KR20220116483A (ko) 악성 프로그램 코드 주입으로부터의 보호를 위한 시스템 및 방법

Legal Events

Date Code Title Description
A201 Request for examination