KR20220038115A - 바이오메트릭 프로토콜 표준을 위한 시스템 및 방법 - Google Patents

바이오메트릭 프로토콜 표준을 위한 시스템 및 방법 Download PDF

Info

Publication number
KR20220038115A
KR20220038115A KR1020227005661A KR20227005661A KR20220038115A KR 20220038115 A KR20220038115 A KR 20220038115A KR 1020227005661 A KR1020227005661 A KR 1020227005661A KR 20227005661 A KR20227005661 A KR 20227005661A KR 20220038115 A KR20220038115 A KR 20220038115A
Authority
KR
South Korea
Prior art keywords
vector
biometric
server
bops
user
Prior art date
Application number
KR1020227005661A
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 US16/520,191 external-priority patent/US11329980B2/en
Application filed by 베라디움 아이피 리미티드 filed Critical 베라디움 아이피 리미티드
Publication of KR20220038115A publication Critical patent/KR20220038115A/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/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • 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/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • 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/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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
    • H04L9/3239—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 involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H04L2209/38—

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Biomedical Technology (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioethics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Collating Specific Patterns (AREA)
  • Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)
  • Storage Device Security (AREA)

Abstract

사용자 컴퓨팅 장치와 서버 컴퓨팅 장치 간에 보안 통신이 제공된다. 등록 요청은 분산 클라이언트 소프트웨어 애플리케이션을 통해 구성되고 처리되는 사용자 컴퓨팅 장치로부터 수신된다. 등록 요청은 네트워크에 사용자 컴퓨팅 장치를 등록하는 데 사용가능하며 사용자와 관련된 암호화된 부분 초기 바이오메트릭 벡터를 포함한다. 암호화된 부분 제2 바이오메트릭 벡터를 포함하고 사용자 컴퓨팅 장치의 사용자와 관련된 나중에 수신되는 인증 요청이 처리된다. 암호화된 부분 초기 바이오메트릭 벡터와 암호화된 부분 제2 바이오메트릭 벡터의 비교가 수행되고, 비교를 나타내는 값이 생성되어 사용자 컴퓨팅 장치로 전송된다. 값이 최소 임계값 이상인 경우 사용자 컴퓨팅 장치가 인증된다.

Description

바이오메트릭 프로토콜 표준을 위한 시스템 및 방법
이 특허출원은 2015년 8월 21일에 출원된 명칭 “바이오메트릭 프로토콜 표준을 위한 시스템 및 방법”의 미국 특허출원번호 62/208,328에 우선권을 주장하고 2015년 10월 14일에 출원된 미국 특허출원번호 62/241,392에 대해 우선권을 주장하는 2016년 8월 22일에 출원되어 현재 미국 특허번호 9,838,388인 미국 특허출원 번호 15/243,411에 기초 및 우선권을 주장하는 2017년 11월 1일에 출원된 명칭 “바이오메트릭 프로토콜 표준을 위한 시스템 및 방법”의 미국 특허출원 번호 15/800,748에 기초 및 우선권을 주장하는 일부 계속 출원이고, 이 출원은 2017년 5월 11일에 출원되어 현재 미국 특허번호 10,255,040인 미국 특허출원번호 15/592,542에 우선권을 주장하는, 2019년 4월 8일에 출원된 미국 특허출원번호 16/378,044의 일부 계속출원이며, 이들 각각은 그것의 각자의 전체가 본 명세서에 설명된 것처럼 참조에 의해 여기에 포함된다.
본 발명은 일반적으로 보안에 관한 것으로, 보다 구체적으로는 사용자를 식별하거나 인증하기 위한 시스템 및 방법에 관한 것이다.
모든 종류의 정보는 데이터 통신 네트워크를 통해 엑세스 가능한 저장 장치 상에서와 같이 원격으로 저장되고 엑세스되는 것을 계속한다. 예를 들어, 많은 사람과 회사는 인터넷이나 다른 통신 네트워크를 통해 금융 정보, 건강 및 의료 정보, 상품 및 서비스 정보, 구매 정보, 엔터테인먼트 정보, 멀티미디어 정보를 저장하고 엑세스한다. 정보에 엑세스하는 것뿐만 아니라, 사용자는 금지된 신원을 이용하여 금전 이체(예를 들어, 구매, 양도, 판매 등)에 참여할 수 있다. 일반적인 시나리오에서, 사용자는 정보에 엑세스하기 위해 등록하고, 그 후에 "로그인"을 위해 사용자 이름과 패스워드를 제출하고 정보에 엑세스한다. 데이터/통신 네트워크에 저장된 이와 같은 정보 및 데이터로의(및 로부터의) 엑세스를 보호하는 것은 중요한 관심사로 남아있다.
또한, 대부분의 사용자 인증 방법 및 신원 증명 시스템은 중앙 집중식 데이터베이스에 의존한다. 이러한 정보 저장소는 보안 관점에서 단일의 위태한 지점을 나타낸다. 이 시스템이 손상되면 사용자의 디지털 신원에 직접적인 위협을 제기한다.
따라서, 기술 분야에서 필요한 것은 이러한 사용자 신원 시스템에 내재된 보안 취약성을 극복하는 시스템, 방법 및 컴퓨터 실행 접근법이다.
여기에 설명된 시스템, 방법 및 컴퓨터 제품은 사용자 신원의 단일 손상 지점이 없는 사용자 인증에 관한 것이다.
예를 들어, 인증 시스템에 신원을 등록하는 컴퓨터 실행 방법이 제공된다. 방법은 데이터 통신 네트워크를 통해 모바일 컴퓨팅 장치로부터, 초기 바이오메트릭 벡터(IBV)의 적어도 하나의 암호화된 암호화 공유 및 시드를 이용하여 수학적으로 생성된 제1 공개 키/개인 키 쌍의 공개 키를 수신하는 단계를 포함하고, 상기 적어도 하나의 암호화된 암호화 공유는 상기 제1 공개 키/개인 키 쌍의 개인 키를 이용하여 암호화 된다. 설명된 방법은 또한 적어도 인가 시스템 서명을 포함하는 제1 신원 데이터 세트를 생성하는 것 - 여기서 서명은 디지털 서명, 제1 공개 키/개인 키 쌍의 공개 키 및 적어도 하나의 암호화된 암호화 공유임, 그리고 적어도 하나의 원격 저장 위치에 상기 제1 신원 데이터 세트를 저장하는 것의 단계를 포함한다. 하나 이상의 추가 구현에서, 설명된 방법은 제1 신원 데이터 세트와 관련된 신원 기준 값을 생성하는 것의 단계를 포함하며, 여기서 신원 기준 값은 제1 신원 데이터 세트의 저장 위치를 결정하고 생성된 제1 신원 데이터 세트와 암호로 관련된다. 추가 예로서, 설명된 방법은 또한 각자의 노드에 저장된 복수의 원장 각각에 적어도 신원 기준 값을 포함하는 트랜잭션 레코드를 배포하는 단계 및 모바일 컴퓨팅 장치에 적어도 신원 기준 값을 제공하는 단계를 포함한다.
본 출원의 하나 이상의 추가 구현에서, 리소스 제공자에 대한 액세스를 사용자에게 제공하기 위한 시스템은 메모리를 가지고 데이터 통신 네트워크를 통해 모바일 컴퓨팅 장치로부터 제1 신원 데이터 세트와 관련된 적어도 신원 기준 값을 수신하도록 하나 이상의 모듈에 의해 구성된 프로세서를 포함하고, 여기서 상기 신원 기준 값은 상기 제1 신원 데이터 세트의 저장 위치를 결정하고 상기 제1 신원 데이터 세트와 암호로 관련되며, 상기 제1 신원 데이터 세트는 적어도 인가 시스템 특정 데이터 값, 시드를 이용하여 수학적으로 생성된 등록 공개 키/개인 키 쌍의 공개 키 및 액세스를 요청하는 사용자의 초기 바이오메트릭 벡터의 적어도 하나의 원격 암호화된 암호화 공유를 포함한다. 시스템의 프로세서는 인가 시스템 서명 값을 수신하도록 추가로 구성되며, 여기서 서명은 디지털 서명 및 등록 공개/개인 키 쌍의 공개 키이다. 수신된 데이터를 사용하여, 시스템은 각자의 노드에 저장된 복수의 원장에서 적어도 신원 기준 값을 포함하는 트랜잭션 레코드를 찾아내고 찾아낸 트랜잭션 레코드로부터 상응하는 제1 신원 데이터 세트의 저장 위치를 결정하도록 구성된다. 특정 구현에서, 시스템은 또한 암호로 관련된 제1 신원 데이터 세트에 액세스하고 제1 신원 데이터 세트의 인가 시스템 서명 값 및 등록 공개 키를 검증하도록 구성된 프로세서를 포함한다. 추가 구현에서, 시스템의 프로세서는 모바일 컴퓨팅 장치로부터 현재의 바이오메트릭 벡터 및 로컬 암호화된 바이오메트릭 암호화 공유를 수신하고 등록 공개 키/개인 키 쌍의 공개 키를 이용하여 수신된 로컬 암호화된 암호화 공유 및 원격 암호화된 암호화 공유를 복호화하도록 구성된다. 여기서, 설명된 시스템의 프로세서는 복호화된 로컬 암호화 공유와 복호화되어 저장된 암호화 공유를 결합하여 결합된 암호화 벡터를 형성하고 결합된 암호화 벡터를 현재의 바이오메트릭 벡터와 비교할 수 있다. 결합된 암호화 벡터가 현재의 바이오메트릭 벡터에 매치하는 경우, 설명된 시스템의 프로세서는 리소스 제공자가 리소스에 대한 액세스를 사용자에게 제공하도록 할 수 있다.
본 출원의 하나 이상의 구현에서, 사용자 컴퓨팅 장치와 서버 컴퓨팅 장치 사이에 보안 통신이 제공된다. 등록 요청은 분산 클라이언트 소프트웨어 애플리케이션으로 구성된 사용자 컴퓨팅 장치로부터 수신되어 처리된다. 등록 요청은 네트워크에 사용자 컴퓨팅 장치를 등록하는 데 사용 가능하고 사용자와 관련된 암호화된 부분 초기 바이오메트릭 벡터를 포함한다. 암호화된 부분 제2 바이오메트릭 벡터를 포함하고 사용자 컴퓨팅 장치의 사용자와 관련된 나중에 수신되는 인증 요청이 처리된다. 암호화된 부분 초기 바이오메트릭 벡터와 암호화된 부분 제2 바이오메트릭 벡터의 비교가 수행되고, 비교를 나타내는 값이 생성되고 사용자 컴퓨팅 장치에 전송된다. 값이 최소 임계값 이상인 경우 사용자 컴퓨팅 장치가 인증된다.
하나 이상의 구현에서, 사용자 컴퓨팅 장치와 서버 컴퓨팅 장치 사이에 보안 통신이 제공된다. 분산 클라이언트 소프트웨어 애플리케이션으로 구성된 사용자 컴퓨팅 장치로부터 수신된 등록 요청이 처리된다. 등록 요청은 네트워크에 사용자 컴퓨팅 장치를 등록하는 데 사용 가능하고 사용자와 관련된 제1 바이오메트릭 벡터의 제1 부분을 포함한다. 제1 바이오메트릭 벡터의 제1 부분이 저장되고, 제2 바이오메트릭 벡터 및 제1 바이오메트릭 벡터의 제2 부분을 포함하는 나중에 수신되는 인증 요청이 처리된다. 제1 및 제2 부분은 결합되고 제2 바이오메트릭 벡터와 비교된다. 비교를 나타내는 값이 생성되고 사용자 컴퓨팅 장치로 전송된다. 값이 최소 임계값 이상인 경우 사용자 컴퓨팅 장치가 인증된다.
하나 이상의 구현에서, 등록 요청 및 인증 요청에 포함된 인증서가 제공되며, 여기서 인증 요청을 처리하는 것은 인증서가 현재의 것이고 폐지되지 않았음을 결정하는 단계를 포함한다.
하나 이상의 구현에서, 능동적 모니터링을 제공하고 인증서를 리플레이하는 것을 포함하는, 인증서의 스푸핑을 방지하는 침입 탐지 시스템이 제공된다.
하나 이상의 구현에서, 인증 요청을 처리하는 단계는 단방향 암호화의 기능으로 암호화된 공간에서 적어도 하나의 매치 동작을 수행하는 단계를 포함한다. 단방향 암호화는 무작위의 단방향 패드(pad)를 사용하여 수행될 수 있다.
하나 이상의 구현에서, 역할 수집은 디지털 자산에 대한 액세스를 위한 하나 이상의 규칙에 의해 제공 및 정의되며, 서버 컴퓨팅 장치는 역할 수집의 기능으로 사용자 컴퓨팅 장치에 의한 디지털 자산에 대한 액세스를 제공하거나 거부한다. 엑세스는 임의적 접근 제어 및 강제적 접근 제어 중 적어도 하나의 기능으로 제공될 수 있다.
하나 이상의 구현에서, 서버 컴퓨팅 장치는 분산 클라이언트 소프트웨어 애플리케이션으로 구성된 사용자 컴퓨팅 장치로부터 수신된 제2 등록 요청을 처리한다. 제2 등록 요청은 사용자 컴퓨팅 장치의 제2 사용자를 네트워크에 등록하는데 사용 가능하고 제2 등록 요청은 사용자 컴퓨팅 장치의 사용자와 관련된 제2 암호화된 부분 초기 바이오메트릭 벡터("IBV")를 포함한다. 제2 등록 요청을 처리하는 단계는 서버 컴퓨팅 장치에 의해 액세스 가능하거나 서버 컴퓨팅 장치의 일부인 비일시적 프로세서 판독 가능 매체에 제2 암호화된 부분 IBV를 저장하는 단계를 포함한다.
하나 이상의 구현에서, 서버 컴퓨팅 장치는 사용자의 등록을 폐지할 수 있다.
본 발명의 다른 특징 및 이점은 첨부 도면을 참조하는 본 발명의 다음 설명으로부터 명백해질 것이다.
첨부 도면과 함께 취해질 때 아래에 설명된 그것의 다양한 실시예의 상세한 설명을 검토하면, 본 개시의 추가 양태는 더욱 쉽게 이해될 것이며, 그 중:
도 1은 본 출원의 하나 이상의 구현을 가지는 복수의 디바이스 및 컴포넌트를 도시하는 블록도이다.
도 2 내지 도 6은 BOPS 구현의 예와 관련하여 장치들 및 그 사이의 정보 흐름을 도시한다.
도 7a는 하나 이상의 구현에 따른, 데이터 기밀성에 특히 중점을 둔 예시적인 등록 프로세스와 관련된 장치 및 단계를 도시한다.
도 7b는 본 출원에 따라 사용자 인터페이스에 제공되는 예시적인 관리 콘솔을 도시한다.
도 8은 등록 프로세스와 관련하여 데이터의 액세스 및 교환을 포함하는 개요를 도시한다.
도 9는 본 출원의 하나 이상의 구현에 따른 보안 아키텍처의 컴포넌트를 도시한다.
도 10a 및 10b는 본 출원의 하나 이상의 구현에 따른, 2개의 각자의 그리고 대안의 등록 프로세스와 관련된 장치 및 단계를 도시한다.
도 11은 본 출원에 따른 생성 프로세스의 상이한 레벨과 관련된 가능한 요건 및 예를 도시하는 블록도이다.
도 12는 등록 및 인증 프로세스 동안 초기 바이오메트릭 벡터와 관련된 정보의 예시적인 흐름을 도시한다.
도 13은 본 출원과 관련하여 구현되는 시각적 암호화(VC) 예를 도시한다.
도 14는 예시적인 BOPS 구현과 관련하여 각각의 비트가 공유들로 암호화되는 시각적 암호화 방식(VCS)에서 2개의 공유(2,2)의 예시적인 중첩을 도시한다.
도 15는 본 출원에 따른 역할 계층 구조의 예를 도시한다.
도 16은 예시적인 구현에 따른, 리플레이 방지와 관련된 장치 및 전송 플로우를 나타내는 블록도이다.
도 17은 예시적인 구현에 따른 토큰과 관련된 단계를 예시하는 상위 레벨 흐름이다.
도 18은 다대다 관계의 생성 프로세스와 관련된 예시적인 장치 및 특징을 도시한다.
도 19a는 단일 클라이언트 장치 상에서 예시적인 등록 프로세스를 시작하는 다수의 사용자를 묘사한다.
도 19b는 다중 사용자 계정에 관한 정보를 저장하는 클라이언트 장치로부터 인증 세션을 시작하는 하나의 예시적인 사용자를 도시한다.
도 19c는 사용자 계정의 폐지와 관련된 예시적인 단계를 도시한다.
도 20a는 클라이언트 장치와 BOPS 서버 사이의 클라이언트 인증서의 초기화, 검증 및 확인과 관련된 단계를 나타내는 단순화된 도면이다.
도 20b는 제3자 서버 및 BOPS 서버와 관련된 예시적인 클라이언트 인증서 등록을 도시한다.
도 21은 본 출원의 예시적인 구현에 따른 예시적인 QR 코드 인증 플로우를 도시한다.
도 22는 분산 원장 및 신원 허브를 사용하는 인증 프로세스와 관련된 예시적인 장치 및 특징을 도시한다.
도 23은 등록 및 리소스 액세스 프로세스에서 사용자와 인증 제공자 사이의 장치 및 연결을 묘사한 블록도이다.
도 24는 인증 목적을 위한 정보를 저장하는 클라이언트 디바이스로부터 인증 세션을 시작하는 사용자의 일례를 나타내는 흐름도이다.
도 25는 사용자를 신원 제공자에 등록하는 것과 관련된 단계를 보여주는 단순화된 다이어그램이다.
도 26은 인증 검증자를 사용하여 리소스에 대한 액세스를 얻는 사용자의 일례를 나타내는 흐름도이다.
도 27a는 신원 검증자로 사용자 신원을 검증하는 것과 관련된 단계를 나타내는 단순화된 도면이다.
도 27b는 도 27a의 단순화된 다이어그램의 변형으로서, 신원 검증자로 사용자 신원을 검증하는 것과 관련된 단계를 설명한다.
도 28은 신원 검증자로 사용자 신원을 검증하는 것과 관련된 단계를 보여주는 대안의 단순화된 도면이다.
도 29는 여기에 설명된 신원 검증자 시스템으로 사용자 신원을 검증하는 것의 일 구현과 관련된 단계를 나타내는 흐름도이다.
개요 및 소개를 위해, 여기에 설명된 시스템, 방법, 프로세스 및 컴퓨터 제품은 분산 원장(예를 들어, 블록체인)을 이용하여 신원(identities)의 디지털 표현을 위한 분산된 바이오메트릭 자격 증명 저장소를 지향하고 활용한다. 현재 사용자 신원확인(identification)의 기술 분야에서, 사용자는 중앙집권화된 데이터베이스로, 신용 이력과 같은 개인 정보, 출생 증명서(certificate)와 같은 자격 증명(credentials), 또는 지문 템플릿(template)과 같은 바이오메트릭 데이터를 제3자에게 양도하도록 강요된다. 전통적인 신원 증명 시스템을 대체함으로써 여러 프로젝트에서 구현되고 있는 개인의 그리고 안전한 신원 관리를 위한 새로운 분산형 생태계이다. 다양한 네트워크(예를 들어, 인터넷)에서 신원확인의 사용에 내제된 이 문제를 극복하기 위해, 여기에는 최종 사용자가 네트워크를 통한 교환을 설정하거나 참여할 때 전통적인 중앙 집중식 기관이 아닌 사용자 신원 데이터에 대한 제어를 설정할 수 있게 하는 다양한 접근법이 설명된다.
본 특허 출원의 하나 이상의 구현에 따르면, 일반적으로 바이오메트릭 공개 프로토콜 표준(Biometric Open Protocol Standards, BOPS)으로 여기에 언급되는 새로운 표준의 세트가 제공되고, 사용자 제어 인증(authentication) 시스템과 결합하면 사용자의 신원확인(identification) 정보가 중앙 집중식 권한이 아닌 사용자에 의해 보호되는 사용자를 인증(authenticate)하기 위한 프레임워크를 허용한다. 하나 이상의 BOPS 구현은 신원 주장(identity assertion), 역할 수집, 다중 레벨 액세스 제어, 보증 및 감사를 위한 하나 이상의 모듈을 제공할 수 있다.
도 1은 예시적인 하드웨어 장치(100)를 도시하고 하나 이상의 BOPS 구현과 관련된 데이터 통신을 표시한다. 장치(100)는 클라이언트 장치(104)(예를 들어, 스마트폰 또는 모바일 장치), 서버 컴퓨팅 장치(102)(여기서, 일반적으로 "BOPS 서버"로 언급되는), 제3자 서버(106) 및 복수의 컴퓨팅 장치(112)를 포함할 수 있는 침입 탐지 시스템(intrusion detection system, IDS)과 같은, 여기에 도시되고 설명되는 기능을 지원하고 가능하게 하기 위한, 다중 컴퓨팅 장치를 구성하는 하나 이상의 소프트웨어 애플리케이션을 포함할 수 있다. 또한, BOPS 서버(102)는 건강 모니터링 장치(108) 및 분석 엔진 장치(110)와 통신하거나 연결될 수 있다. 장치(108) 및 장치(110) 모두 BOPS 서버(102)의 일부로서 구성될 수 있거나 개별적인 장치일 수 있다.
다음은 여기에서 언급되는 약어 및 두문자어의 비제한적인 목록이다: admin = 관리자(administrator); AOP = 관점 지향 프로그래밍(aspect oriented programming); API = 응용 프로그래밍 인터페이스(application programming interface); AWS = 아마존 웹 서비스(Amazon Web Services); app a = 클라이언트 애플리케이션(client application); BOPS = 바이오메트릭 개방형 프로토콜 표준(biometric open protocol standard); CPU = 중앙 처리 장치(central processing unit); CBV = 현재의 바이오메트릭 식별자(Current Biometric Identifier); CSRF = 사이트 간 요청 위조(cross-site request forgery); HSM = 하드웨어 보안 모듈(hardware security module), ID = 식별자(identifier); IDS = 침입 탐지 시스템(intrusion detection system); IBV = 초기 바이오메트릭 벡터(initial biometric vector); IP = 인터넷 프로토콜(); JSON = JavaScript 객체 표기법(JavaScript object notation); LDAP = 경량 디렉토리 액세스 프로토콜(Lightweight Directory Access Protocol); MAC =강제적 액세스 제어(mandatory access control); MCA = 모바일 클라이언트 애플리케이션(Mobile Client Application); NSA = 국가안보국(National Security Agency)(미국); QR 코드 = 빠른 응답 코드(Quick Response code); RDBMS = 관계형 데이터베이스 관리 시스템(relational database management system); REST = 표현 상태 이전(representational state transfer); SSL = 보안 소켓 계층(secure socket layer); TCSEC = 신뢰할 수 있는 컴퓨터 시스템 평가 기준(trusted computer system evaluation criteria); TEE= 신뢰할 수 있는 실행 환경(trusted execution environment); TPM = 신뢰할 수 있는 플랫폼 모듈(trusted platform module), TLS = 전송 계층 보안(transport layer security); URL = 통합 자원 식별자(uniform resource identifier); XNTP = 확장된 네트워크 시간 프로토콜(extended network time protocol); XOR = "배타적 OR" 이진 연산(“Exclusive OR” binary operation); 1:M = 일대다(One-to-Many); 4F = 4개의 손가락(Four fingers), 독점적인 바이오메트릭 기술(a proprietary biometric technology); 5-튜플(5-tuple) = 5개의 튜플 데이터 파라미터(Five tuple data parameters).
본 출원의 장점은 하나 이상의 각자의 BOPS 구현이 기능을 제공하는 구성요소를 포함할 수 있고 기업의 기존 구성요소와 함께 또는 대체하여 작동할 수 있고, 그렇게 함으로써 비교적 매우 짧은 기간에 현재 운영 환경과의 통합을 제공한다는 것이다. 또한, 하나 이상의 각자의 BOPS 구현은 민감하고 사적인 리소스에 대한 엑세스를 판정하는 것과 같이, 지속적인 형식(form) 보호를 제공한다. 서비스-레벨 보안은 허용된 목표를 충족하거나 초과하는 BOPS 구현에서, 생산 시스템뿐만 아니라 개발중인 시스템에 적절한 보안을 더하기 위한 “포인트 앤 컷(point-and-cut)” 메커니즘의 형식으로 구현을 지원하는 하나 이상의 응용 프로그래밍 인터페이스(API)의 기능으로 적어도 부분적으로 제공될 수 있다.
하나 이상의 BOPS 구현은 클라이언트 장치(104)로부터 하나 이상의 데이터 통신 네트워크를 통해 여기서 일반적으로 초기 바이오메트릭 벡터(IBV)로 지칭되는 바이오메트릭 벡터를 수신할 수 있고, 알고리즘에 따라 벡터를 신원확인(identification)과 관련된 복수의 부분으로 나누는 BOPS 서버(102)를 포함할 수 있다. 조각의 수와 무관하게, IBV는 키가 없는 방식을 포함하여 암호화될 수 있고, 차후의 바이오메트릭 매치 프로세스는, 예를 들어 관리 파라미터에 의해 표시된 바와 같이, 클라이언트 장치(104) 또는 서버(102)에서 선택적으로 발생할 수 있다.
하나 이상의 BOPS 구현은 공용 클라우드(예를 들어 아마존 웹 서비스)상에서 또는 사설 클라우드에서와 같은 다양한 온라인 환경에서 구현될 수 있다.
여기에 도시되고 설명된 장치 조직 구조 및 기능에 따라, 사용자 인증(authentication)은 허가(authorization) 대신에 그리고 서버가 클라이언트 정보를 보유하지는 않지만 한 클라이언트를 다른 클라이언트로부터 인식할 수 있게 하기 위한 충분한 양의 정보를 유지하는 방식으로 제공될 수 있다. 하나 이상의 BOPS 구현에 따른 보안 고려 사항의 구성 요소는 신원(identity) 주장, 역할 수집, 액세스 제어, 감사 및 보증을 포함할 수 있다. 따라서 하나 이상의 BOPS 구현은 단대단(end-to-end) 바이오메트릭 솔루션에서의 서버 측 구성 요소를 크게 고려한다.
신원(identity) 주장과 관련하여, 하나 이상의 BOPS 구현은 리소스의 지속적인 보호를 제공하고, 판정 및 다른 주요 기능의 배치 및 실행 가능성을 보장할 수 있다. 하나 이상의 BOPS 구현은 인간의 바이오메트릭에 직접 의존하는 것 없이, 명명된 사용자들이 그들이 주장하는 사람인지를 확인하는 데 도움이 되도록 신원 주장(identity assertion)을 추가로 지원할 수 있다. 여기에 도시되고 설명된 표준은 실질적으로 임의의 신원 주장자 또는 동일하게 명명된 사용자와 관련된 다수의 다른 주장자들을 통합할 수 있는 공동 사용이 가능한 표준을 포함한다. IDS의 애플리케이션(예를 들어, 클라이언트 장치(112)를 통한)은 자격 증명(credential)의 세트를 스푸핑(spoofing)하는 것을 방지하고/하거나 하나 이상의 악의적인 시도를 만드는 것을 만들었거나 시도하고 있는 것으로 결정된 주체 또는 장치를 블랙리스트에 올리기 위한 능동적 모니터링을 제공할 수 있다.
또한, 역할 수집은 예를 들어 알려진 시스템에 의해 정의 및/또는 시행되는 규칙을 기반으로 하는 데이터 비밀 보호 및 권한 있는 엑세스의 기능으로 지원된다. 예를 들어, 엑세스의 특정한 모드가 허용되는지 여부를 판단하기 위해, 각자의 역할과 관련된 특정한 권한(privilege)을 그룹의 분류와 비교할 수 있다. 객체의 구조는 엑세스 제어에 의해 정의될 수 있으며, 역할 수집은 시스템 레벨에서 또는 클라이언트/서버 호출을 통해 발생할 수 있다. 예를 들어, BOPS 서버(102)는 고유한 사용자를 고유한 장치(104)와 관련시키기 위해 역할 수집 정보를 저장할 수 있다. 액세스 제어는 주어진 주체(예를 들어, 사람, 장치 또는 서비스(예를 들어, 소프트웨어 프로그램))가 엑세스하고/엑세스하거나 주어진 객체를 읽거나, 쓰거나, 실행하거나, 또는 삭제하는 것과 같은 액션을 취할 권한이 있는지를 결정하는, 컴퓨팅 장치에서 실행되는 하나 이상의 모듈을 구현하는 것을 포함할 수 있다.
일반적으로, 엑세스 제어는 임의적일 수 있으며, 더 세분화될 수 있는 강제적 엑세스 제어를 또한, 또는 대안으로, 포함할 수 있다. 임의적 엑세스 제어는, 예를 들어, 하나 이상의 객체에 대한 엑세스를 제어하는 것을 명명된 사용자 및 명명된 객체(예를 들어, 파일 및 프로그램)의 기능으로 간주한다. 판정 메커니즘은, 예를 들어, 역할 기반이고 사용자와 관리자가 명명된 개인에 의한 및/또는 개인의 정의된 그룹에 의한 객체의 공유를 지정하고 제어하도록 할 수 있다. 임의의 엑세스 제어 메커니즘은, 하나 이상의 구현에서, 객체가 단일의 또는 개체의 그룹에 걸쳐 그룹 또는 개인의 레벨에서 권한이 없는 엑세스로부터 보호되는 것을 제공한다. 따라서 임의의 엑세스와 관련된 세분성은 개인에서 그룹에까지 미칠 수 있다.
하나 이상의 BOPS 구현은 각자의 구현 내에서의 제어 하에 모든 주체 및 스토리지 객체(예를 들어, 프로세스, 파일, 세그먼트, 장치)에 대해 강제적 엑세스 제어 정책을 시행할 수 있다. 이 주체 및 객체에, 계층적 분류 레벨 및 비계층적 카테고리의 조합일 수 있는, 민감도 레이블이 할당될 수 있다. 레이블은 강제적 엑세스 제어 결정의 기초로써 판정에서 사용 가능하다. 예를 들어, 클라이언트 장치(104)에서 실행되는 소프트웨어는 주체 및 객체의 레이블링에 대한 준수를 강제하기 위하여 장치가 레이블을 유지하도록 하거나 BOPS 서버(102)가 데이터를 유지하도록 한다. BOPS 서버(102)는 BOPS 구현의 구성요소로서 신뢰되는 저장소를 유지할 수 있다. 여기에 사용된 신뢰되는 저장소는, 일반적으로, 엑세스 제어(DAC 또는 MAC)가 주체가 정확한 객체를 수신하는 것을 보장하고 부인 방지 및 기밀성을 추가로 보장하는 그런 안전한 방식으로 데이터를 저장하는 것을 말한다.
다음은 하나 이상의 예시적인 BOPS 구현에서 지원되는 엑세스 제어 규칙 및 옵션을 알아본다. 주체의 보안 레벨에서의 계층적 분류가 객체의 보안 레벨에서의 계층적 분류 이상인 경우에만 객체를 읽는 엑세스가 주체에게 제공될 수 있다. 주체의 보안 레벨에서의 하나 이상의 비계층적 카테고리는 객체의 보안 레벨에서의 모든 비계층적 카테고리를 포함할 수 있다. 주체는 주체의 보안 레벨에서의 계층적 분류가 객체의 보안 레벨의 계층적 분류보다 작거나 같고 주체의 보안 레벨에서의 모든 비계층적 카테고리가 객체의 보안 레벨에서의 비계층적 카테고리에 포함되는 경우에만 객체에 쓰고/쓰거나 객체를 실행할 수 있다. 신원확인(Identification) 및 인증(authentication) 데이터는, 사용자의 신원을 인증하고 개개의 사용자를 대신하여 작동하도록 만들어질 수 있는 BOPS 구현의 외부에 있는 주체의 보안 레벨 및 허가(authorization)가 그 사용자의 승인(clearance) 및 허가(authorization)에 의해 지배되는 것을 보장하기 위하여, BOPS 서버 장치(102)에 의해 사용 가능하다.
본 출원은 여기에서 일반적으로 보증(assurance)으로 지칭되는 보안 모델이 작동하는지를 감사하고 검증하는 것을 제공하는 하나 이상의 모듈의 기능을 포함하여, 책임성을 증가시키기 위해 동작한다. 혹시라도 BOPS 구현 내의 컴퓨팅 장치가 손상되는 것이 일어난다면, 이와 같은 모듈(들)은 손상된 시스템이 감지되지 않고 작동하는 것을 방지한다. 예를 들어, BOPS 구현에서 감사 요청은 해당 기술분야에서 알려진 바와 같이 관점 지향 프로그래밍(aspect-oriented programming)의 기능을 포함하여 주체/객체 레벨에서 또는 그룹 레벨에서 지원될 수 있다. 이는 호출이 감사 추적(audit trail)에 안전하게 기록될 가능성을 증가시킨다. 또한 RESTful 웹 서비스와 JSON(JavaScript Object Notation)의 인터페이스는 감사 추적을 읽는 메커니즘을 제공할 수 있다. 감사는 작업당 주체, 작업당 객체 또는 작업당 그룹에서 발생할 수 있다. 예를 들어, 사용자의 그룹은 특정 이름(예를 들어 "회계")으로 지정될 수 있으며 총계정원장(general ledger)에 대한 모든 쓰기를 감사할 수 있다. 또한 개인, 예를 들어 최고 재무 책임자는, 손익 계산서의 읽기를 위한 감사 정보를 제공받을 수 있다.
JUnit 테스트 모음의 하나 이상은, 시스템 내의 경계 구성 요소 및 조건을 테스트하는 것을 포함할 수 있는, 경계 조건을 테스트하고 모니터링하기 위한 하나 이상의 BOPS 구현에서 사용될 수 있다. 하나 이상의 BOPS 구현에서, 보안 조항은 API(들)의 기능으로 적어도 부분적으로 충족될 수 있다. API의 사용은 관계형 데이터베이스 관리 시스템(relational database management system), 검색 엔진 또는 사실상 임의의 다른 아키텍쳐와 같은 기본적 시스템을 준수하도록 BOPS 구현을 식별 및/또는 커스터마이징할 필요를 막는다. 각자의 BOPS 구현에서 제공되는 기능은 생산 시스템 뿐만 아니라 개발 시스템에 적절한 보안을 추가하는 "포인트 앤 컷(point-and-cut)" 메커니즘을 제공할 수 있다. 또한, 하나 이상의 BOPS 구현의 아키텍처는 예를 들어 REST, JSON 및 SSL을 지원하여 통신 인터페이스를 제공하는 언어-중립(language-neutral )이다. 하나 이상의 구현에서, 아키텍처는 서블릿 사양, 개방형 SSL, Java, JSON, REST 및 지속하는 저장소에 구축된다. 툴은 개방형 표준을 준수하여 그림 1에 도시된 것과 같이 장치에 대한 최대의 상호 운용성을 허용할 수 있다.
하나 이상의 BOPS 구현에서 신원 주장, 역할 수집, 다중 레벨 엑세스 제어, 감사 및 보증이 제공된다. 이들은 적어도 하나의 특별히 구성된 클라이언트 장치(104)(예를 들어, 스마트폰 또는 모바일 장치), BOPS 서버(102), 및 장치(들)(112)를 포함하는 침입 탐지 시스템(intrusion detection system, IDS)의 조합의 기능으로서 구현될 수 있다. 하나 이상의 구현에서, 클라이언트 장치(104)는 애플리케이션을 실행하고 BOPS 서버(102)와의 안전하고 초기의 통신 세션을 설정하기 위해 일회용의, 양방향 보안 소켓 계층 (secure sockets layer, SSL)/전송 계층 보안(transport layer security, TLS) 키를 로드한다. 일회용 키는, 최소한 기능적으로는, 신원 확인 단계(여기서, 일반적으로 "생성(Genesis)"이라 함) 중에 생성 및/또는 제공되는 주체의 양방향 SSL/TLS 키로 대체된다. 생성(Genesis)은, 일반적으로, 일련의 바이오메트릭들을 주어진 주체와 융합하는 프로세스에서의 처음의 또는 이른 단계를 포함한다. 여기서 일반적으로 등록(Enrollment)이라 지칭하는 다른 단계는 BOPS 구현에서 사용자 및/또는 장치를 등록하는 것과 관련된 단계를 포함하고, 클라이언트 장치(104)에 대한 인증서(certificate)를 발급하고, 클라이언트 인증서를 보호하고, 클라이언트에 저장된 민감한 데이터를 보호하는 것을 포함할 수 있다.
하나 이상의 BOPS 구현에서, 데이터 암호화 및 보안 클라이언트/서버 통신을 처리하는 인프라(infrastructure)가 제공된다. BOPS 인프라는 생성(Genesis) 및 등록(Enrollment)의 프로세스를 디커플링 하고 이러한 프로세스를 다양한 등록 요소와 함께 조정하는 것을 지원할 수 있다. 이러한 종속성은 BOPS 서버(102) 인프라를 식별하고 다음을 포함할 수 있다: BOPS DNS; BOPS 신뢰 저장소(TrustStore); BOPS 키 저장소; 및 BOPS 키 협상 프로토콜. 인증서 관리와 관련하여, BOPS 서버(102)의 호스트네임에 대한 DNS 엔트리는 단방향 SSL에 대한 키 저장소에서 키를 가지도록 구성될 수 있다. 하나 이상의 BOPS 구성에서 신뢰 저장소(TrustStore)는 모든 해당 인증서에 서명하기 위한 인증 기관을 정의하는 양방향 SSL 메커니즘이다. 전송 레벨에서, BOPS 신원(identity)은 핸드셰이크(handshake)를 수행함으로써 양방향 인증서와 신뢰 저장소를 통해 발생할 수 있다. 키 저장소는 키 저장소의 키를 통해 전송 레벨 보안을 지원하고, 키 저장소의 키는 SSL/TLS 상에서 암호화를 위해 호스트를 식별하는데 사용될 수 있는, VERISIGN, GODADDY 또는 다른 기관과 같은, 잘 정의되고 알려진 인증 기관을 사용할 수 있다. 여기에서 언급된 바와 같이, 하나 이상의 BOPS 구현은 클라이언트 장치(104)가 양방향 SSL 인증서를 잠금 해제하는 패스워드를 요청하기 위해 일회용 비밀번호(OTP) 프로세스를 이용한다. 이것은 양방향 SSL 세션이 시작된 후 인증서를 잠금 해제하기 위해 키를 다시 패스하도록 OTP를 동기화하는 클라이언트 장치(104) 및 서버(102)에 의해 수행될 수 있다.
하나 이상의 구현에서, 수 개의 키 등록 요소는 클라이언트 장치(104)가 BOPS 서버(102)에 요청을 보낼 때 클라이언트 인증서(certificate) 인증(authentication)을 지원한다. 예를 들어 토큰은 데이터 요소의 기능과 같이, 서버 상의 프로파일을 신원에 연결하는 식별자로 구성될 수 있다(예를 들어 "통상의 이름"). OTP 프로세스는 양방향 SSL(x.509) 인증서를 잠금 해제하는 서버로부터 패스워드를 요청하는 하나 이상의 메커니즘을 포함한다. 패스워드는 서버 컴퓨팅 디바이스(102)와 클라이언트 컴퓨팅 디바이스(104) 사이에서 조정되는 미리 정의된 알고리즘에 의해 각각의 사용에 대해 변경될 수 있으며, OTP에 사용되는 채널은 바람직하게는 개별적인 인증서에 사용되는 채널과 다르다. 예를 들어, 푸시 알림은 개별 인증서를 잠금 해제하는 데 사용되는 패스워드를 보낼 수 있다. 다른 인증서는 개별 인증서를 잠금 해제하기 위한 패스워드를 얻기 위해 사용될 수 있다. 어떤 경우에도, 인증서를 잠금 해제하는 메커니즘은 클라이언트 장치(104) 상에서의 그 패스워드의 저장을 수반하지 않을 수 있다.
예를 들어, 애플리케이션은 생성(Genesis) 및 등록(Enrollment)에 대해 디폴트(예를 들어, 사전 로드) 인증서를 이용한다. 차후의 처리는 현재의 OTP와 함께 디폴트 인증서를 사용할 수 있다. 결과(예를 들어, HTTP 응답)는 인증서를 잠금 해제하기 위한 패스워드를 포함할 수 있다. 그리고 나서 OTP는 클라이언트와 서버에 롤포워드(roll forward)될 수 있다. 하나 이상의 BOPS 구현에서, 5-튜플(5-tuple)은 리플레이 공격(replay attack)을 방지하는 데 사용되는 높은 엔트로피 값이다. 값은 등록에서 발생하고 클라이언트 장치(104)와 서버(102) 간의 향후의 통신의 일부가 될 수 있다.
BOPS 구현에서 클라이언트/서버 애플리케이션의 상호 작용은 3단계 프로세스로 고려될 수 있으며, 적어도 두 개의 가능한 변형이 초기의 첫 번째 단계를 따를 수 있다. 그러한 경우, BOPS 클라이언트/서버 애플리케이션 아키텍처는 3가지 구성요소(클라이언트 장치(104) 상에서 실행되는 클라이언트 애플리케이션, BOPS 서버(102) 상에서 실행되는 애플리케이션, 및 서버측 애플리케이션(도면에서 “앱 서버”라 지칭되는))를 참조하여 여기서 설명된다. 도 2 내지 6에 도시된 예에서, SSL/TLS 연결이 애플리케이션 서버에서 종료될 수 있기 때문에, 서버측 애플리케이션은 필수적으로 BOPS 서버(102)를 통해 실행되는 것은 아니다. 또한, 각자의 BOPS 구현 배치는 애플리케이션이 암호화되지 않은 콘텐츠로 BOPS 시스템을 신뢰하도록 요구하지 않는다. 도 2를 참조하면, 생성 프로세스 동안 클라이언트 장치(104)는 BOPS 서버(102)에 대한 호출을 만들고 사용자 및 클라이언트측 애플리케이션 소프트웨어를 인증한다. 그 후, 클라이언트 장치(104)는 BOPS 서버(102)에 의해 할당되고 특정 애플리케이션의 클라이언트 신원에 특정하는 인증서를 수신한다.
다음 단계(도 3) 동안, 클라이언트 장치/애플리케이션은 애플리케이션 서버를 직접 호출한다. 클라이언트와 애플리케이션의 서버 부분 간의 SSL/TLS 연결은 이 지점에서 시작하고 종료한다. 콘텐츠 교환은 바람직하게는 BOPS 서버(102)에 대한 애플리케이션 또는 이 애플리케이션 엔티티 내에서 신뢰되지 않는 다른 것의 외부에서 볼 수 없다. 클라이언트 세션(도 4) 동안, 애플리케이션 서버(106)는 식원확인(identification) 세부사항을 얻기 위해 BOPS 서버(102)를 호출하고 인증서가 이전에 폐지되지 않았는지 확인한다.
두 번째 변형(도 5에 부분적으로 표시된)에서, 생성 단계(도 2 내지 3에서 설명된 것을 포함하는)는 동일할 수 있다. 그 후, BOPS 서버(102)는 새로운 클라이언트(104)가 등록 및 할당되었음을 통지하기 위해 애플리케이션 서버(106) 구성요소에 접속한다. 두 번째 변형의 플로우는 적어도 두 가지 방법(신원 세부사항이 다르고, 폐지(revocation) 확인이 클라이언트 세션에서 입수된다(도 6))에서 첫 번째 변형의 플로우와 다르다. 세번째 단계에서, 클라이언트 장치(104)가 애플리케이션 서버(106)를 직접 호출할 때, 애플리케이션 서버(106)는 인증서가 이전에 폐지되지 않았음을 확인하기 위해 BOPS 서버(102)를 호출한다.
예시적인 BOPS 구현과 관련하여 여기에 도시되고 설명된 특징은 여기에서 제공된 엑세스 제어 모듈에 의해 또는 관련하여 사용될 수 있거나, 기존의 프레임워크의 신원 주장 요소에 추가될 수 있다. 따라서 BOPS 구현은 생산 환경에서 최소한의 작업만 수행하여 신뢰되는 처리를 가능하게 하고, 그렇게 함으로써 종종 애플리케이션 소프트웨어의 변경의 요구를 배제할 수 있다.
도 7a는 하나 이상의 BOPS 구현에 따른, 예시적인 등록 프로세스 및 관련 데이터 기밀성과 관련된 장치 및 단계(700)를 도시한다. 본 출원은 양방향 SSL/TLS에서의 단방향 SSL/TLS 위에 구축되고, 양방향 SSL/TLS는 클라이언트 장치(104)에서 시작하는 통신을 제공한다. 초기(예를 들어, 생성)의 통신은 클라이언트(104)의 신원의 출처를 정의할 수 있고 클라이언트 장치(104)가 세션-지향 신원 주장과 함께, 차후의 통신에 사용할 수 있는 BOPS-컴플라이언트 양방향 인증서를 전달할 수 있다. 하나 이상의 구현에서, 클라이언트 애플리케이션은 차후의 생성(Genesis) 동작을 허용하는 사전 로드된 양방향 SSL/TLS 키를 가질 수 있다.
하나 이상의 구현에 따르면, BOPS 서버(102)는 클라이언트 장치(104)로부터 양방향 SSL/TLS 신원으로 단방향 SSL/TLS 통신을 수신한다. 통신은 단방향 SSL/TLS 및 양방향 SSL/TLS 둘 다를 통해 수행된다. 하나 이상의 구현에서, 서버(102)는 신뢰되는 신원 정보를 취하고 각자의 신원을 대신하여 처리하기 위한 역할을 수집하기 위해 데이터 저장소를 사용한다. 또한 감사는 신뢰되는 엑세스의 지속적인 검증(verification) 및 확인(validation)을 위해 적절한 인공물(artifact)을 최대화한다. 보증(assurance)은 다중레벨 엑세스 제어 메커니즘의 단순화 및 문서화의 기능으로 발생할 수 있다. 하나 이상의 BOPS 구현에서, 그래픽 사용자 인터페이스의 관리 콘솔(administration console)(이하, admin console)은 사용자, 그룹 및 역할의 동적 수정을 허용하고 여기에 더 자세히 설명된 등록 프로세스의 완료에 뒤를 이어 제공된다. 예시적인 관리 콘솔이 도 7B에 도시된다.
도 7a를 참조하면, 토큰 요청(RESTful)이 클라이언트 장치(104)로부터 전송되고(1) BOPS 서버(102)로부터 수신되어 검증된다(2). BOPS 서버(102)의 호스트 네임에 대한 DNS 엔트리는 키 저장소에서 키를 갖도록 구성될 수 있으며(3), 요청은 형식화되고(4A) m개의 토큰 응답이 양방향 SSL/TLS를 통해 클라이언트 장치(104)로 전송된다(4B). 그 후, c개의 토큰(예를 들어, 5-튜플 및 타임스탬프)이 클라이언트 장치(104)로부터 전송되며(5), 이는 요청에서 m개의 타임스탬프의 기능을 포함하여 검증된다(6, 7). 그 후, 누락된 5-튜플렛은 신뢰 저장소에 대하여 결정되고(8) 요청이 형식화되고(9) SHA512 토큰이 클라이언트 장치(104)로 전송된다(10).
계속해서 도 7a를 참조하면, SHA512 토큰을 포함하는 등록 요청이 클라이언트 장치(104)로부터 전송되고(11) BOPS 서버(102)에 의한 검증을 위해 수신되며(12) 클라이언트 서명 요청은 일회용 패스워드를 계산하고 키 저장소에 대한 토큰 수를 확인하고(14) 클라이언트 인증서 패스워드를 외부 알림 서비스로 푸시하는 것(15)을 포함하여, 인증을 잠금 해제하기 위해 처리된다(13). 또한, 12의 검증 단계는 분석과 관련된 단계로 분기되고, 장치 정보(16), 프로파일 정보(17) 및 바이오메트릭(18)(여기에 도시되고 설명되는)을 결정하는 단계를 포함한다.
또한 클라이언트 장치의 인증서 패스워드에 더하여 형식화된 요청(2) 및 SHA512 토큰(21)이 클라이언트 장치(104)로 다시 전송된다(19). 그 후, SHA512 토큰을 포함하는 맞춤형(custom) 보안 요청이 클라이언트 장치(104)로부터 전송되고(22), 맞춤형(custom) 보안 요청은 BOPS 서버(102)에 의해 검증된다(23). 요청이 형식화되고(24) 맞춤형 보안 응답(SHA512 토큰을 포함하는)이 클라이언트 장치(104)에 전송된다(25).
하나 이상의 BOPS 구현에서, 장치(112)를 통하는 것을 포함하여, 능동적 침입 탐지 시스템이 제공된다. 능동적 침입 탐지 시스템은 무차별 대입 공격(brute-force attack), 서비스 거부(denial-of-service)(예를 들어, 분산 또는 단일의 서비스 거부) 또는 기타 공격을 방지하는 데 효과적이다. BOPS 서버 장치(102)를 손상시키는 노력으로 양방향 SSL/TLS 인증서 사칭, 세션 리플레이(session replay), 위조 패킷 또는 다양한 우회 기술을 위조하려는 시도를 식별하고 추적하는 맞춤형 규칙이 정의되고 시행될 수 있다.
하나 이상의 BOPS 구현에서, 시각적 암호화(visual cryptography)는 초기 바이오메트릭 벡터(IBV)를 암호화하는 데 사용된다. 이 기술은 바이오메트릭 매치를 수행하는 특정 장치에서 XOR 연산을 사용하는 것과 같이 IBV의 빠른 재구성의 이점을 제공한다. 예를 들어, 비밀 분산법(secret sharing scheme)를 제공하는, Moni Naor와 Adi Shamir에 의해 개발된 기술이 사용될 수 있다. 예시적인 동작에서, 벡터는 N개의 공유로 분할되고 초기 벡터를 재구성하는 것은 모든 N개의 공유 부분을 필요로 한다. 각자의 장치는 BOPS 서버(102) 및 모바일 클라이언트 애플리케이션(104)을 포함하고, 등록된 벡터는 BOPS 서버(102)에 의해 엑세스 가능한 BOPS 저장소에 저장되는 하나와 모바일 컴퓨팅 장치(104) 상의 다른 하나를 가지는 2개의 공유 부분으로 분할될 수 있다.
본 출원의 하나 이상의 구현에서, 데이터 기밀성을 보장하기 위한 다른 형태의 암호화 및/또는 메커니즘이 사용될 수 있다. 예를 들어, 타원 곡선 암호화(elliptic curve cryptography)는 시각적 암호화 대신(또는 어쩌면 추가적으로) 사용될 수 있다.
예시적인 바이오메트릭 인증 동작 동안, 새로 획득된 벡터 및 등록된 벡터의 두 공유는 단일 위치(예를 들어, 모바일 컴퓨팅 장치 애플리케이션(104) 또는 BOPS 서버(102))에서, 또는 여러 위치에서 이용가능할 수 있다. 어느 경우에든, 등록된 벡터 공유를 사용하여 초기의 벡터가 메모리에서 재구성됨으로써 그것에 대해 발생하는 인증을 지원할 수 있다. 도 8은 등록 프로세스와 관련된 데이터의 엑세스 및 교환을 포함하는, 개요를 설명한다. BOPS 서버(102)와 관련하여, 신원은 주체의 계정 및 장치의 기능으로 제공된다. 주체의 계정과 장치는 주어진 주체에 대한 프로파일 정보의 일부이다. 프로파일 정보는 클러스터링된 데이터 저장소에 저장된다. 매치(match)를 위해, IBV는 공유되고, 재구성되고 복호된다. 매치 알고리즘이 유클리드 매치가 가능하지 않은 경우, 매치는 평문으로 발생하고, 그렇지 않으면 매치가 암호화된 도메인에서 발생한다.
대안적인 구현에서, 계산이 암호문에 대해 수행되고 이렇게 하여 암호화된 결과를 생성하게 하는, 동형 암호화(homomorphic encryption)가 사용된다. 매치 동작은 암호화된 공간에서 할 수 있고, 그렇게 함으로써 프라이버시 및 보안을 향상시킨다. 예를 들어, 매치가 단방향 암호화를 사용하는 암호화된 공간에서 발생할 수 있고, 그렇게 함으로써 높은 레벨의 프라이버시를 제공하고, 본래의 평문 IBV를 획득하는 능력을 효과적으로 배제한다.
하나 이상의 구현에서, 알고리즘은 그것이 두 부분(클라이언트를 위한 하나 및 서버를 위한 하나)을 가지는 것과 같은 방법으로 단방향 암호화를 수행한다. 기술 분야에서 알려진 바와 같이, 매치가 유클리드 거리(예를 들어, 해밍 거리)를 사용하는 경우, 암호화된 공간에서 매치가 발생한다. 그 대신에, 매치가 해밍 거리를 사용하지 않는 경우, 여기에서 설명되는, 평문 공간에서 매칭을 한다.
하나 이상의 구현에서, ROTP(random one-time pad)는 암호화된 공간에서 매치를 허용하는 단방향 암호화를 수행하는 데 사용된다. 그 대신에, 평문에서 매치하는 경우 시각적 암호화는 가역의 암호(reversible cipher)에 사용된다. 예를 들어, 해밍 거리를 가지지 않는 경우, 시각적 암호화는 메모리에서 매치가 발생하기 위하여 평문으로 반환하는데 사용된다. 바람직하게, 암호화 및 복호화는 두 개의 암호화 알고리즘(1.비트마스크(Bitmask) 또는 2.매트릭스 변환(Matrix transformation)) 중 하나를 사용한다. 이상적으로, 모든 매치 알고리즘은 해밍 거리를 가질 것이고 그러므로 서버는 평문 IBV를 가지지 않는다.
다음은 두 이진 벡터 간의 해밍 거리를 계산하는 함수로 수행되는 홍채 인식과 관련된 예시적인 알고리즘이다. 예시적인 알고리즘에서, 매치는 다음과 같이 그들을 평문으로 변환하는 것 없이 바이오메트릭의 암호화된 절반들에 대해 직접 수행될 수 있다 (^는 비트의 XOR 연산을 나타냄):
서버는 저장한다: 등록 벡터(Enrol vector) ^ 노이즈.
전화는 전송한다: 검증 벡터(Verify vector) ^ 동일한 노이즈.
비교는 서버에서 수행된다: (등록 벡터 ^ 노이즈) ^ (검증 벡터 ^ 동일한 노이즈).
XOR은 가환성이며 결합성이고, 따라서 이것은 (등록 벡터 ^ 검증 벡터) ^ (노이즈 ^ 동일한 노이즈)로 재배열될 수 있다.
XOR은 자기 역(self-inverse)이고, 따라서 (노이즈 ^ 동일한 노이즈) = I 이고, 여기서 I 는 XOR에 대한 식원 요소이며, 0이다.
따라서, 표현식은 (등록 벡터 ^ 검증 벡터) ^ I = (등록 벡터 ^ 검증 벡터)로 단순화된다.
A와 B 사이의 해밍 거리는 A^B의 함수이다.
따라서, 노이즈가 있는 벡터들 사이의 해밍 거리는 본래의 벡터들 사이의 해밍 거리와 동일하다.
예시적인 구현에서 등록 시, 다음이 발생한다:
a). 등록 벡터(Enrolment vector):
00110011
b). 랜덤 시퀀스(벡터의 전반부): 서버에 저장
01010101
c). 벡터의 후반부(계산됨): 전화에 저장
01100110
검증 시:
e). 검증 벡터(verification vector): (이것이 잘 매치하기 때문에 등록과 검증 사이에 마지막 비트만 변경되었음을 알 수 있다.)
00110010
벡터의 후반부: 전화에 저장됨
01100110
f). 벡터의 전반부에 대한 근사값을 계산한다(e 및 c로부터):
01010100
매칭 시:
g). 이 "검증 전반부"(f)를 서버로 보낸다.
h). 서버는 지금 가진다:
등록 벡터 전반부 b):
01010101
검증 벡터 전반부 f):
01010100
b와 f 사이에서 변경된 모든 비트를 1로 플래그(flag):
00000001
시스템은 좋은 매치를 나타내는 등록과 검증 사이에 마지막 비트만 변경되었음을 알 수 있지만, 서버가 어떻게 스크램블된 데이터만 처리했는지 그리고 실제 벡터가 서버에서 알려지지 않았으며 벡터의 차이만 계산될 수 있음을 알 수 있다.
대안적인 구현에서, 얼굴 인식은 템플릿 벡터들 사이의 유클리드 거리를 계산함으로써 수행되며, 여기서 얼굴은 벡터로부터 리버스 엔지니어링될 수 없다. 예를 들어 뉴럴 네트워크를 사용하여 두 개의 얼굴 이미지가 매치되면, 각각의 얼굴이 먼저 128바이트 크기의 부동 벡터(float vector)로 변환된다. 이 부동 벡터의 표현은 임의적이며 본래의 얼굴로 다시 리버스 엔지니어링될 수 없다. 얼굴을 비교하기 위해, 두 벡터의 유클리드 거리가 계산된다. 같은 사람의 두 얼굴은 유사한 벡터를 가져야 하고 다른 사람의 얼굴은 유클리드 공간에서 더 멀어져야 한다. 검증 벡터(verification vector)는 모바일 장치에서 계산되고 저장된 등록 벡터와 매치시키기 위해 원격 서버로 전송될 수 있다. 따라서 본래의 바이오메트릭(예를 들어, 얼굴)은 사용자의 장치를 떠나지 않을 것이고, 모든 매치는 서버에서 계산될 수 있다.
또 다른 구현에서, 지문 인식은 템플릿 벡터 사이의 유클리드 거리를 계산함으로써 수행되고, 여기서 지문은 벡터로부터 리버스 엔지니어링 될 수 없다. 앞서 설명한 것과 유사하게, 뉴럴 네트워크는 지문 매치에 적용될 수 있다. 이 경우, 지문은 장치에서 벡터로 변환될 수 있고 벡터가 전송될 수 있고, 그렇게 함으로써 네트워크 출력 벡터로부터 본래의 지문 이미지를 재구성하는 방법이 제거된다.
하나 이상의 구현에서, 암호화 키는 뉴럴 네트워크로부터 출력 벡터를 난독화하는데 사용되는 장치에서 무작위로 생성된다. 예를 들어, 암호화된 바이오메트릭 벡터 = 암호화 행렬 × 평문 바이오메트릭 벡터이다. 이 경우, 암호화 행렬 변환은 유클리드 거리가 보존되는 특수한 속성을 가지고, 따라서 행렬은 강체 변환(rigid transformation)이어야 한다. 이러한 경우, 바이오메트릭 벡터는 암호화되지 않은 형식에서 장치를 떠나지 않고, 서버는 평문을 아는 것 없이 두 개의 암호화된 바이오메트릭을 비교하고 유클리드 거리를 계산한다. 사용자가 새로운 장치에서 검증하기를 원하는 경우, 사용자는 QR 코드를 통하는 것과 같이, 암호화 데이터를 새로운 장치에 전송할 수 있다. 이것은 이전 장치를 사용할 수 있음을 요구한다. 이전 장치를 분실했거나 그렇지 않으면 사용할 수 없는 경우, 여기에 도시되고 설명된 바와 같이, 사용자는 다시 등록한다.
따라서, 바이오메트릭 벡터가 장치 간에 분할되고 암호화되어 저장되는 기능에 따라 향상된 프라이버시가 제공된다. 바이오메트릭 벡터의 어떤 부분도 디스크나 메모리에 평문 형식으로 서버에 존재하지 않는다. 또한, 각자의 인증 및 실패한 인증에 대해 "이러면 어떨까(what if)" 분석을 하기를 바라는 사용자가 패싯(facet), 검색, 분석 등을 지원하는 관리 인터페이스를 통해 그렇게 할 수 있기 때문에, 본 출원은 향상된 분석을 제공한다.
도 9는 하나 이상의 BOPS 구현에 따른 예시적인 보안 아키텍처(900)의 컴포넌트를 도시한다. 도 9에 도시된 바와 같이, BOPS 보안 클러스터(902)는 가상 사설망(VPN)에서 BOPS 인스턴스를 실행하도록 구성될 수 있다. 인증 기관 엔티티, BOPS 키저장소(KeyStore) 및 BOPS 신뢰 저장소(TrustStore)의 핵심 속성은, 예를 들어 BOPS 인스턴스에서 찾아질 수 있다. BOPS 인스턴스는 또한 DNS, OTP 라이브러리, 알림 서비스 키, 비즈니스 어댑터, BOPS 구성 속성과 연관되는 및/또는 이들을 나타내는 데이터를 포함할 수 있다. 로드 밸런서 클러스터(904)는 BOPS 서비스, 분산된 워크로드의 신뢰성 및 가용성을 보장하는 하나 이상의 장치를 포함할 수 있다. 구성된 BOPS 로드 밸런서(904)는 처리량을 최대화하고 응답 시간을 최소화하고, BOPS 아키텍처(900)에서 임의의 단일 리소스의 과부하를 방지하도록 동작할 수 있다.
계속해서 도 9를 참조하면, 지속성 클러스터(906)는 하나 이상의 데이터베이스 보안 그룹을 포함할 수 있고 BOPS 데이터 클러스터의 자동 스케일링을 위해 구성될 수 있다. 인증(authentication) 서비스가 큰 데이터 객체를 다루고, 큰 데이터 세트를 처리하기 때문에, NoSQL과 같은 빅 데이터 저장소와 데이터의 데이터의 하나 이상의 수평의 분할들("조각들(shards)")은 조각들(shards)에서 동시에 읽고 결과를 병합하여 성능을 향상시키는데 사용될 수 있다. 데이터베이스 보안 아키텍처(900)는 BOPS 아키텍처를 구현하고 단일 위치에서의 민감한 데이터의 중앙 집중식 저장을 방지한다. 또한 도 9에는 IDS 장치(112)를 포함할 수 있는 모니터링 클러스터(908)가 도시되어 있다.
도 10a 및 10b는 하나 이상의 BOPS 구현에 따른, 각자의 그리고 대안의 등록 프로세스(1000, 1010)와 각자 관련되는 장치 및 단계를 도시한다. 10A 및 10B에서 도시된 구현은 계정 또는 장치와 관련된 암호화된 바이오메트릭 데이터를 저장하고, 모든 바이오메트릭 데이터 변경에 대한 정보를 저장하고, 인증 서비스와 그들의 상응하는 바이오메트릭 라이브러리(예를 들어, FACE, 4F, IRIS)를 로드 및 사용하고, 새로운 플로우(예: 등록 및 인증)을 지원하는 API 작업을 제공하는 메커니즘을 제공한다.
도 10a에 도시된 구현에서, 모바일 컴퓨팅 장치(104) 상에서 실행되는 소프트웨어 애플리케이션("MCA")은, 인증 플로우를 위한 방법이 클라이언트(104) 측에서 발생하도록 구성되는 경우, 등록 프로세스 중 암호화 분할 동작을 수행하고 서버 측에서 CPU 부하를 낮추기 위한 이 프로세스를 배포하기 위하여, BOPS 서버(102)에 등록 요청(등록)을 수행하기 위하여, 그리고 암호화 매치 동작을 수행하기 위하여, 초기 바이오메트릭 벡터(IBV)의 획득을 제공한다. BOPS 서버(102)는 등록 프로세스 동안, 예를 들어 BOPS 빅 데이터 저장소(1002)에 공유된 벡터와 함께 사용자 신원 데이터를 저장하도록 구성될 수 있다. 또한, BOPS 서버(102)는 인증 플로우를 관리하고 인증 서비스 통신 구성요소(1004)를 통합할 수 있다. 인증 서비스(1006)는 하나 이상의 인증 알고리즘, 바이오메트릭 엔진 라이브러리를 동적으로 로드하고, 인증 엔진 버저닝(versioning)에 대한 지원을 제공하고, BOPS 서버(102)와 하나 이상의 바이오메트릭 엔진 간의 통신을 정규화하고, 인증 엔진 버저닝(versioning)에 대한 지원을 제공하고, BOPS 서버(102)와 인증 엔진들 사이의 통신을 정규화할 수 있다. 인증 서비스는 인증을 수행할 때 바이오메트릭 서비스에 대한 래퍼(wrapper)로써 기능한다.
여기에 설명된 바와 같이, 플러그형 인증 서비스 및 그들의 상응하는 바이오메트릭 엔진이 하나 이상의 메커니즘에 제공된다. 따라서 BOPS 구현은 구성 가능할 수 있고(예를 들어, 인증 서비스 및 바이오메트릭 라이브러리의 위치를 통해) 사용 가능한 서비스를 자동으로 로드하고 시스템에 등록할 수 있다.
결과적으로 시스템 레벨에서 발음(enunciation) 서비스의 리스트가, 예를 들어, 4F-엔진, FACE-엔진, IRIS-엔진, 음성-엔진이 이용 가능하다. 인증자의 리스트는 FIDO 인증자 또는 BOPS 인증자를 포함한다.
본 출원은 다음의 기능을 지원함으로써 바이오메트릭 통합 인증 서비스를 개선하는 것을 제공한다. 하나 이상의 메커니즘이 BOPS 서버(102)에 의해 엑세스 가능한 계정 또는 장치에 암호화된 바이오메트릭 데이터를 저장하기 위해 제공될 수 있다. 또한 메커니즘은, 발생하는 바이오메트릭 데이터 변경을 나타내는 정보를 저장하기 위해 제공될 수 있다. 또한 "일반적인(generic)" 메커니즘이, (예를 들어, 부여된 미국 특허출원번호 14/201,462, 미국 특허출원번호 14/201,499, 미국 특허출원번호 14/988,833 및 미국 특허출원번호 14/819,639에 일반적으로 표시 및 설명된 것과 같은, 얼굴, 네 손가락, 홍채 바이오메트릭 인증과 관련하는) 포함하는 인증 서비스를 엑세스하고 사용하기 위해 제공될 수 있다.
본 출원의 하나 이상의 구현에서, 모바일 컴퓨팅 장치(104)는 등록 벡터를 획득하고, 등록 프로세스 동안 암호화 분할 동작을 수행한다. 이것은 프로세스를 분산시키고 서버 측의 CPU 부하를 낮추어 컴퓨팅 기능을 향상시킨다. 또한, 모바일 장치(104)는 BOPS 서버(102)에 대한 등록 요청(등록)을 수행하고 인증 플로우의 "바이오메트릭 확인(Validation)" 단계가 모바일에서 발생하도록 구성되는 경우 암호화 매치 동작을 수행할 수 있다.
본 출원의 하나 이상의 구현에서, BOPS 서버(102)는 등록 프로세스 동안, 예를 들어 APACHE SOLR 저장소에 공유된 벡터의 적어도 일부와 함께 사용자 신원 정보를 저장한다. 게다가, BOPS 서버(102)는 인증 정보 및 프로세스 플로우를 관리하고 적어도 하나의 바이오메트릭 서비스 통신 구성요소를 통합하도록 구성될 수 있다.
본 출원에 따른 아키텍처에서 제공되는 다른 구성요소는 하나 이상의 인증 서비스 및 하나 이상의 바이오메트릭 엔진을 포함할 수 있다. 인증 서비스(들)는 하나 이상의 인증 서비스의 버저닝(versioning)을 지원하고, BOPS 서버(102)와 인증 서비스 간의 통신을 정규화하고, 하나 이상의 BOPS 인스턴스가 혼자 스케일할 수 있는 분리된 클라우드를 남기거나 분리된 클라우드인 웹 애플리케이션 머신과 같은 하나 이상의 배치 시나리오를 제공하도록 구성된 하나 이상의 라이브러리의 동적 로딩을 수행하도록 구성될 수 있다.
하나 이상의 구현에서, 바이오메트릭 엔진은 인터페이스의 주체이고 BOPS 구현 시스템에 플러그되는 각각의 각자의 라이브러리에 의해 정의 및 구현되는 관리되지 않는 바이오메트릭 라이브러리를 포함하도록 구성된다. 바이오메트릭 엔진은 필요에 따라 엔진을 로드하는 "Load" 방법, 리소스(예: 메모리, 임시 파일)를 해방시키 위하여 엔진을 언로드(unload)하는 "UnloadLoad" 방법, 상태 정보(예를 들어, INIT_FAILED, OK, ERROR, OUT_OF_MEMORY)를 제공하기 위한 "GetStatus", 등록 중에 획득된 벡터를 암호화하는 " 분할(Split)" 방법, 예를 들어 초기 벡터의 공유 부분에 기초하여 벡터를 인증하는 “매치(Match)” 방법, "활성화/등록(Activate/Register)" 방법 및 엔진의 설명을 가급적 제공한다. 설명은, 예를 들어, 바이오메트릭 유형 식별자(Identifier), 이름 및 설명, 엔진 버전 및 바이오메트릭 형식을 포함할 수 있다. 이 정보를 사용하여, 본 출원과 관련된 하나 이상의 프로세스는 특정 바이오메트릭 엔진을 자동으로 로드하고 등록할 수 있다.
하나 이상의 구현에서, 시스템을 구성 가능하게 하고(인증 서비스 위치) 이용 가능한 라이브러리를 자동으로 로드하고 시스템에 등록할 수 있도록 하는 플러그형 인증 서비스에 대한 메커니즘이 지원된다. 인증 서비스에 의해 호출되는 각각의 바이오메트릭 라이브러리는 그 자신을 설명하기 위해 상수 문자열(바이오메트릭 유형), 각자의 버전, 이름 및 설명과 같은 정보를 제공할 수 있다. 또한 쌍(바이오메트릭유형, 바이오메트릭버전)과 같은 정보는 고유한 바이오메트릭 엔진을 식별할 수 있다.
예시적인 인증 서비스와 그들의 상응하고 낮은 레벨의 바이오메트릭 엔진이, 예를 들어, 부여된 미국 특허출원번호 14/201,462, 미국 특허출원번호 14/201,499, 미국 특허출원번호 14/988,833 및 미국 특허출원번호 14/819,639에 일반적으로 표시 및 설명된 것과 같은, 4F, 얼굴, 홍채 및 음성을 포함하여, 시스템 레벨에서 나열되고 이용 가능할 수 있다.
여기에서 언급한 바와 같이, 하나 이상의 BOPS 구현에서 생성(Genesis) 및 등록 프로세스는 BOPS 서버(102)가 바이오메트릭 벡터, 인증서 또는 그 외 자동화된 절차에 필요한 다른 기밀의 정보에 엑세스하는 직접적인 요구 없이 주체의 신원을 결정할 수 있도록 효과적으로 디커플된다. 따라서 BOPS 솔루션은 "개방형"으로 해석될 수 있으며 생성(Genesis) 및 등록(Enrollment)에서 사실상 임의의 커스터마이제이션(customization)을 가능하게 한다. 예를 들어, 생성(Genesis)은 액티브 디렉토리에 엑세스하기 위한 사용자이름 및 패스워드, 검증하는(validating) 이메일 또는 텍스트 메시지, 또는 신원을 물리적으로 검증하는(verifying) 기관의 직원을 이용하는 것을 포함할 수 있다. 예를 들어 일괄적으로 발생할 수 있는 사용자 계정의 사전 등록은 비즈니스 요구에 기반할 수 있다. 또한 생성(Genesis) 프로세스는 위험 관리에 대한 완전한 종속성을 형성할 수 있고 더 나아가 다운스트림 처리를 결정할 수 있다. 생성 프로세스 후의 예시 중에, 사용자는 각자의 등록된 장치에 대하여 발급되는 고유의 클라이언트 인증서를 포함할 수 있는, 그의 또는 그녀의 바이오메트릭을 등록한다. 추가적으로, 일회용 패스워드(예를 들어, "시드(seed)")는 클라이언트 장치(104)와 서버 장치(102) 사이에 설정될 수 있고, 추가적인 시드 값은 리플레이 공격(replay attack) 방지를 위해 사용될 수 있다.
단일 사용자가 많은 장치를 가질 수 있고/있거나 단일 장치가 많은 사용자를 가질 수 있다(즉, 단일 장치가 많은 바이오메트릭을 가질 수 있다)는 것이 여기에서 인식된다. 이와 같이, 다대다(many-to-many) 관계의 형태가 생성(Genesis) 및 등록(Enrollment) 프로세스를 분리하는 기능으로 발생할 수 있다. 따라서 식별된 주체는, 생성(Genesis)을 통해, 많은 바이오메트릭을 여러 번 등록할 수 있다. 하나 이상의 BOPS 구현에서, 등록 프로세스는 서버에서 생성할 수 있는 양방향 SSL/TLS(보안 소켓 계층(Secure Socket Layers)/전송 계층 보안(Transport Layer Security)) 인증서를 사용한다. 이러한 생성은 생성(Genesis) 프로세스 후에 발생할 수 있고, 이렇게 하여 인증서가 명확한 주체에 대하여 적절한 것을 보장한다.
또한 하나 이상의 BOPS 구현은 다른 보안 레벨에 대한 유연성을 제공하는, 다양한 레벨의 프로비저닝을 가질 수 있다. 예를 들어, 상위 레벨의 생성(Genesis)은 사용자가 직원과 같은 누군가의 앞에서 물리적으로 검증되는(validated) 것을 포함한다. 대안으로 낮은 레벨은 단지 사용자에 의해 수신된 검증 이메일과 함께 사용자이름 및 패스워드를 정의하는 것을 포함할 수 있다. 다양한 레벨의 생성(Genesis) 및 검증 프로세스는 하나 이상의 각자의 조직에 고유하거나 특유할 수 있는 하나 이상의 비즈니스 결정의 기능으로 구현될 수 있다. 또한, 차후의 처리는 각자의 생성(Genesis) 레벨에 기초하여 변경될 수 있다. 예를 들어, 시스템은 높은 레벨의 생성(Genesis)과 관련하여 $1000,000의 이체를 허용하지만 더 낮은 레벨의 생성(Genesis)과 관련하여 $100의 이체만을 허용한다.
도 11은 본 출원에 따른, 생성의 상이한 레벨과 관련된 가능한 요건 및 예(1100)를도시하는 블록도이다. 검증 프로세스에 추가적인 요구가 필요하기 때문에, 각자의 보안 레벨은 상응하여 증가할 수 있다. 도 11의 예시적인 레벨에서, 첫 번째 및 두 번째 레벨은 조직의 고려 사항에 따라 교체될 수 있다. 예를 들어, 목표가 비즈니스 방문자를 검증(verify)하고 Wi-Fi 엑세스를 주는 것인 경우, 검증(verification)은 모바일 장치를 통해 전송되고 여기서는 낮은 검증 레벨로 고려될 수 있다.
등록 단계 동안, 예를 들어 모바일 컴퓨팅 장치(104) 상에서 실행되는 모바일 애플리케이션은 각자의 내장된 능력에 기초하여 바이오메트릭을 등록한다. 예를 들어, 특정한 통합을 위해 구축되고 기본 바이오메트릭을 요구하는 모바일 애플리케이션은 애플리케이션에 그와 같이 특별히 하드코딩된 모듈을 가질 수 있다.
하나 이상의 BOPS 구현은 바이오메트릭 인증 트랜잭션의 속도를 해결하고 모바일 장치의 가상화된 위협의 문제를 해결한다. 이러한 위협의 예는 침입자가 모바일 장치의 복사된 가상 이미지 상의 코드를 디컴파일하고 이 소스 코드를 사용하여 인증 호출을 중지하고 허가를 인증하고 승인하는 서버의 제어를 얻는 것을 시도하는 것이다.
이러한 위험을 완화하기 위해, BOPS 구현의 프로세스는 암호화 키 없이 초기 바이오메트릭 값(IBV)을 암호화하고, 그리고 나서 IBV의 절반이 클라이언트 장치(104)에 저장되고 나머지 절반이 서버(102)에 저장되거나 그렇지 않으면 서버(102)에 의해 액세스 가능할 수 있다. 바이오메트릭 매치는 서버(102)에서 발생할 수 있다. 도 12는 등록 및 인증 프로세스 동안 초기 바이오메트릭 벡터("IBV")와 관련된 정보(1200)의 예시적인 플로우를 도시한다. 도 12에 도시된 예시적인 플로우에서, 등록 동안 IBV는 캡처 및 분할되고, IBV의 일부(예: 절반)가 클라이언트 장치(104)에 저장된다. IBV의 일부(예를 들어, 절반 또는 1/2)는 등록 요청에서 BOPS 서버(102)로 전송되고, 상기 일부는 예를 들어 BOPS 서버(102)에 의해 액세스 가능한 데이터 저장소에 저장된다. 그 후, BOPS 서버(102)에 의해 등록의 확인이 전송된다.
계속해서 도 12를 참조하면, 현재의 바이오메트릭 벡터("CBV")가 차후의 바이오메트릭 인증 프로세스 동안 캡처되고, 나머지 일부(2/2)를 포함하는 인증(“Auth”) 요청과 관련되어 BOPS 서버(102)에 전송된다. BOPS 서버(102)는 인증 요청에서 수신된 IBV의 일부를 결합하고, 복호화하기 위해 IBV의 저장된 일부를 그것에 결합하도록 구성된다. 수신된 CBV는 평문 전체의 IBV와 비교되고, 비교하는 동안의 결정의 기능으로서 숫자(예를 들어, 부동 숫자)가 클라이언트 컴퓨팅 장치(104)로 반환된다. 일치하는 경우, 사용자가 인증된 것으로 등록될 수 있다. 추가적으로, 인증 프로세스의 결과는 클라이언트 컴퓨팅 장치(104) 상에 표시될 수 있다.
따라서, 그리고 도 12에 도시되고 여기서 설명된 단계에서 예시된 바와 같이, 본 출원에 따른 BOPS 구현은 바이오메트릭 인증 트랜잭션의 속도를 해결하고 클라이언트 장치 상의 가상화된 위협과 관련된 문제를 해결한다. 이러한 위협은, 예를 들어 침입자가 예를 들어 모바일 장치의 복사된 가상 이미지에서 소프트웨어를 디컴파일하고 소스 코드를 사용하여 인증 호출을 중지하고, 허가를 인증하고 승인하는 서버의 제어를 얻는 것을 시도한 후에 발생할 수 있다.
이러한 위험을 완화하기 위해 BOPS 구현과 관련된 특징은 암호화 키 없이 IBV를 암호화하고, IBV의 일부(예를 들어, 절반)를 클라이언트 장치 상에 그리고 일부(예를 들어, 다른 절반)를 서버 또는 이를 통해 엑세스 가능한 장치에 저장하도록 동작할 수 있다. 바이오메트릭 매치는 서버 상에서 발생한다. 이러한 방식으로, 적어도 부분적으로 위태롭게 된 장치나 서버가 공격자에게 유용한 정보를 제공하지 않기 때문에, 도난 당한 장치는 인증을 우회할 수 없다.
하나 이상의 구현에 따르면, 다음은 하나 이상의 BOPS 구현에서 바이오메트릭 인증에 대한 처리 동의를 설정하는 것을 제공한다. 바이오메트릭 벡터는 적어도 클라이언트와 서버 간에 분할되며, 인증에 대한 접근법은 바이오메트릭 애그노스틱(agnostic)이다. 예를 들어, 그리고 얼굴 인식과 관련하여, 초기 바이오메트릭 벡터의 크기는 HTTP 요청 및 HTTP 응답의 업/다운으로 최소화될 수 있고 그러므로 허용되는, 약 20KB일 수 있다. 얼굴 인식과 관련된 IBV에 대한 분할 알고리즘은 다음과 같다: 0비트는 흰색이고 1비트는 검정색이다. 따라서 BOPS 구현은 시각적 암호화(Visual Cryptography, VC)에 해당할 수 있다. 여기에서 언급한 바와 같이, 본 출원은 사실상 어느 바이오메트릭과 함께라도 사용 가능하며, IBV를 얻고 VC로 암호화하는 메커니즘을 제공한다. VC로, 매치가 평문에서 발생한다. 대안적으로, 무작위로, 매치가 암호화된 도메인에서 발생한다.
도 12를 구체적으로 참조하면, 사용자 운영 클라이언트 컴퓨팅 장치(104)는 바이오메트릭 등록을 진행하고(1) 초기 바이오메트릭 벡터(IBV)를 캡처한다(2). 단계 (3)에서, IBV는 암호화 및 분할되고, IBV의 2/2는 클라이언트 컴퓨팅 장치(104) 상에 또는 함께 로컬로 저장되고(4), 전송 계층을 통해(2-way SSL/TLS를 통해) BOPS 서버(102)로 전송되는 IBV의 1/2을 포함하는 등록 요청이 전송된다(5). 1/2 IBV는 BOPS 빅 데이터와 같은 것에 BOPS 서버(102)에 의해 저장되고(6) 등록의 확인은 BOPS 서버(102)로부터 클라이언트 컴퓨팅 장치(104)로 다시 전송된다(7).
계속해서 도 12를 참조하면, 등록에 이어, 클라이언트 컴퓨팅 장치(104)에서 바이오메트릭 인증이 발생하고(8), 현재의 바이오메트릭 벡터가 캡처된다(9). 그 후, 인증 요청은 BOPS 서버(102)에 의해 수신되는 전송 계층을 통해 전송되고(10), 2/2의 IBV와 결합되고 복호화에 사용된다(11). 그 후, CBV는 평문 IBV와 비교되고(12) 부동 숫자는 클라이언트(104)로 다시 전송되고(14), 결과가 표시된다(15).
이제 도 13을 참조하면, 본 출원과 관련하여 구현되는 시각적 암호화(VC)의 예(1300)가 도시된다. VC는 키 관리에 대한 요구 없이 암호화, IBV를 분할하는 것 및 IBV의 복원과 좋은 시너지를 제공한다. 도 13에 도시된 시각적 암호화의 예에서, 검은색은 1과 같을 수 있고 흰색은 0과 같을 수 있다. 예에서, IBV는 00100110과 같다. 해법이 불(Boolean)이기 때문에 XOR 복원이 사용 가능하다. 본래의 바이오메트릭 벡터 암호화 프로세스는 시각적 암호화를 사용하여 발생할 수 있으며, 결과는 백색 노이즈만 포함하는 시트로 기록된 두 개의 벡터일 수 있다. 모바일 저장소(예를 들어, 클라이언트 장치(104))는 시트들 중 하나를 포함하고 서버 장치(102)는 다른 시트를 포함하거나 엑세스한다. 검증 프로세스는 간단한 불(Boolean) 연산을 이용하여 두 개의 시트를 결합하고 그 결과 본래의 바이오메트릭 벡터가 완전히 복원된다.
XOR 연산과 관련된 IBV의 예시적인 복원(reconstruction)은 아래 표 1에서 보여진다.
Figure pct00001
표 1을 참조하고 예시적인 BOPS 구현과 관련하여, 본래의 바이오메트릭 벡터 암호화 프로세스는 시각적 암호화를 사용하여 발생할 수 있으며, 이 암호화의 결과는 백색 노이즈만 포함하는 시트로 표시된 두개의 벡터이다. 여기서 언급된 바와 같이, 클라이언트 장치(104)와 관련된 저장소는 시트 중 하나를 포함하고 서버 장치(102)와 관련된 저장소는 다른 하나를 포함한다. 검증 프로세스는 간단한 불(Boolean) 연산을 이용하여 두 시트를 결합하고 그 결과 본래의 바이오메트릭 벡터가 완전히 복원된다.
도 14는 예시적인 BOPS 구현과 관련하여 각각의 비트가 공유들로 암호화되는 시각적 암호화 방식(Visual Cryptography Scheme, VCS)에서 2개의 공유(2,2)의 예시적인 중첩을 도시한다. 도 14에 도시된 예에서, 0 및 1 비트에 대한 공유의 선택은 무작위 프로세스이다. 0 또는 1비트를 인코딩할 때, 값은 한 공유에 대해서 표로부터 가져와지고 다른 공유에 대해서 표에서의 인접한 값이 가져와진다. 프로세스가 끝나면, 공유들 중 어느 것도 본래의(original) 비트에 대한 어느 단서도 제공하지 않는다. 두 개의 공유(share)를 중첩하는 것(OR 또는 XOR을 이용하여)이 본래의 비트의 값을 결정한다.
계속해서 도 14에 도시된 예를 참조하면, 두 개의 공유(2,2)의 중첩이 각각의 비트가 공유들로 암호화되는 시각적 암호화 방식(Visual Cryptography Scheme, VCS)에서 보여진다. 0과 1비트에 대한 공유들의 선택은 무작위 프로세스로 구현될 수 있음에 주목한다. 0 또는 1비트를 인코딩할 때, 값은 한 공유에 대한 표(예를 들어, 표 1)로부터 가져와지고 다른 공유에 대해서 표에서의 인접한 값이 가져와진다. 프로세스가 끝나면, 공유들 중 어느 것도 본래의 비트에 대한 어느 단서도 제공하지 않는다. 그 후, 예를 들어 OR 또는 XOR을 사용하여 두 개의 공유를 중첩하는 것이 본래의 비트의 값을 결정한다. 이것은 (2,2) VCS에 대한 예이다. VCS는 무작위 프로세스 확률을 변경함으로써 2개 이상의 공유로 확장할 수 있다. 무작위 프로세스의 확률을 0.5에서 0.25로 변경하는 것은 0.5의 예에서 내놓는 2개의 비트 대신에 공유가 4개의 비트를 가지는 것을 야기한다. 또한 무작위 프로세스의 확률을 0.125로 변경하는 것은 각각의 입력 비트에 대한 8비트의 암호화를 야기한다.
매치를 탐지하는 것과 관련하여, 예시적인 BOPS 구현에서의 하나 이상의 모듈은 다중 초기 바이오메트릭 벡터를 사용한다. 그리고 나서 각각의 바이오메트릭에 대해 하나씩, SSL/TLS를 통해 통신하는 두 개의 RESTful 웹 서비스 호출이 있다. 하나의 호출은 인증 세션의 현재의 바이오메트릭에 더하여, IBV들의 절반들을 포함할 수 있으며, 매치의 강도를 나타내는 부동 소수점 값을 반환할 수 있다. 다른 호출은 한 번에 하나의 IBV(절반)와 현재의 바이오메트릭을 제공하고, 매치의 강도를 나타내는 부동 소수점 값을 반환할 수 있다. 두 번째 호출의 경우, 여러 개의 연속 호출(예를 들어, 매치를 결정하기 위해 한번에 하나의 IBV)이 있을 수 있다.
예시적인 BOPS 구현과 관련하여 매치 합의 당 크기 계산은 다음과 같을 수 있다: 얼굴 벡터당 20kb, 초당 5프레임; 10초 동안 = 50개 벡터; 50x20kb=1000kb.
위에서 확인된 구현과 관련된 매치 실행 계획의 예가 다음과 같이 설명된다. 매치를 위해 1,000KB가 서버로 전송된다. 매치가 없으면, 부동 소수점 값이 결정될 때까지 두 번째 100KB가 전송되는 등등이다. 하나 이상의 BOPS 구현에서, 최소의 임계값이 정의되고 부동 소수점 값은 적어도 최소의 임계값 내에 있다. 매치 알고리즘의 예에 따르면 현재 프레임은 200밀리쎄건드 더하기 서버에 대한 125밀리쎄건드의 업/다운 시간을 요구한다. 따라서 프레임당 325밀리쎄건드의 트랜잭션 속도를 가지는 프레임 전송은, 매치를 더한다. 매치가 100밀리쎄컨드에서 상한인 경우, 프레임 전송은 대략 425밀리쎄컨드이다. 실패하더라도, 프레임의 뱃치(batch)(예를 들어 한번에 다섯 개)는 전송될 수 있고 매치는 다시 시도될 수 있다. 바람직하게는, 매치는 1초 미만의 시간 내에 수행되지만, 특정한 덜 유리한 케이스에는, 매치가 몇 초와 같이 더 오래 걸릴 수 있다.
여기에 도시되고 설명된 바와 같이, 본 출원의 유연함 및 인증자 및 바이오메트릭 애그노스틱 특성은 기관이 인증에 대하여 사용 가능하고 기본 바이오메트릭으로 정의될 수 있는 각자의 인증자 및 바이오메트릭을 정의할 수 있게 한다. 다운스트림 트랜잭션의 부분으로써 바이오메트릭의 사양이 없으면, 기본 바이오메트릭은 기관의 레벨, 그룹 사용자 레벨 또는 트랜잭션 레벨과 같이, 하나 이상의 사용자 인터페이스를 통해 지정할 수 있다.
하나 이상의 구현에서, 관리 콘솔은 그래픽 사용자 인터페이스로 구성될 수 있고 각자의 인증된 사용자가 엑세스가능 할 수 있다. 관리 콘솔은 선택 시 기본 바이오메트릭 유형으로 구성되는 것을 야기하는 그래픽 제어를 포함할 수 있다. 예를 들어, ACME Plumbing이라는 기관은, 특정한 엑세스에 대하여 ACME의 모든 직원에 대한 기본 바이오메트릭에 얼굴이 사용되도록 지정한다. 또한, ACME Plumbing은 다른 상황에서 4개의 손가락이 모든 고객에 대한 바이오메트릭에 사용되도록 지정하고, 또 다른 상황에서 $10,000를 초과하는 모든 직원 트랜잭션에 대하여 4개의 손가락과 얼굴이 둘 다 사용되도록 추가로 지정한다. 이러한 옵션은 ACME Plumbing 관리자가 정의할 수 있도록 관리 콘솔에 표시된다. 따라서, 본 출원은 하나 이상의 바이오메트릭의 유연하고 동적인 애플리케이션을 제공한다.
인증과 관련하여, 예를 들어 조건 엔진, 회원 프로파일 및 회원 정의와 같이, 바이오메트릭에 대한 정보의 복수의 소스는 특정한 기관 셋업에 사용될 수 있다. 조건 엔진은 시스템에 정의된 동적 규칙에 기반할 수 있다. 예를 들어, $1,000 이상의 임의의 트랜잭션은 적어도 두 가지 형태의 바이오메트릭 검증을 요구한다. 회원 프로파일은 사용자 역할 및 상응하는 권한을 정의한다. 예를 들어, 회원 프로파일 "정보 보안 -- 최초 응답자"는 10분마다 인증을 요구하거나 모든 자행하는 트랜잭션과 같은 다른 조건을 요구할 수 있다. 회원 정의는 조직의/통합 레벨에서 기본 인증을 정의할 수 있다. 예를 들어, 시스템에서 이용 가능한 4가지 유형의 바이오메트릭(4F, 얼굴, 홍채)이 있고 특정 BOPS/Enterprise 구현에 대하여 기본 바이오메트릭이 "얼굴"인 경우, 얼굴 인증이 기본으로 이용 가능하고 예를 들어 그래픽 유저 인터페이스를 통하여 제공되고 여기서 일반적으로 BOPS 관리 대시보드로 지칭되는 대시보드에서 이와 같이 제공될 수 있다. 또한, 위에서 설명된 것과 같은 각자의 조건은 우선순위를 나타낼 수 있다. 예를 들어, 회원 정의는 가장 낮은 우선순위로 고려될 수 있고 조건 엔진은 가장 높은 것으로 고려될 수 있다. 가장 높은 우선 순위는 인증 방법(들)이 된다.
다음은 본 출원에 따른 등록 프로세스와 관련된 예시적인 단계를 나타낸다. 모바일 클라이언트 애플리케이션으로 구성된 모바일 컴퓨팅 장치(104)는 바이오메트릭 벡터를 획득하고, 암호화를 수행하고 그리고 나서 등록 API 호출을 수행한다. 특히, 바이오메트릭을 획득한 후, BOPS 서버(102)에 대한 등록 호출은 서버(102)에 의한 엑세스를 위해 저장되는 IBV의 절반을 포함한다. 등록 프로세스는 기관 내에서 BOPS 구현을 시작하는데 사용될 수 있다. 여기에 표시된 많은 설명과 도면이 클러스터로 나타나는 BOPS 구현을 표현함에도 불구하고, BOPS가 비즈니스 구성 요소로 구성될 수 있음이 고려된다. BOPS 관리자("BOPS admin")가 환경을 설정하기 전에, 기관은 BOPS 서버(102)에서 각자의 API 키를 등록한다. 개별적인 개발자 또한 다양한 구현에서 API 키를 신청할 수 있다.
등록 프로세스가 완료되면, 본래의 사이트 관리자(“original site admin”)는 추가적인 사이트 관리자(“site admins”)를 만들 수 있다. 관련된 다양한 사이트 관리자를 포함하는 등록 정보는, 기관과 관련된 각자의 API 키에 관련될 수 있다. 하나 이상의 구현에서, API 등록은 2개의 도메인(등록된 본래의 사이트 관리자; 그리고 등록 정보, 기관 및 사용 사례에 기반할 수 있는 발급된 API 키)과 관련될 수 있다. 애플리케이션 시작이 동의 된 후, 등록 절차가 완료된다. 그 후, BOPS 관리자는 기관에 대한 본래의 사이트 관리자를 생성하고, 본래의 사이트 관리자는 사이트 관리자를 생성할 수 있다(예를 들어, 도 15에 도시된 역할 계층 차트를 참조하라).
BOPS 서비스를 활용하는 개발 프로세스 이전에 개발자는 예를 들어 BOPS 관리 콘솔의 옵션을 가급적 사용하여 등록한다. 애플리케이션 이름을 제공하고 개발자를 식별하기 위한 질문 지향적 신원확인(identification) 메커니즘을 사용하여, 새로운 계정이 설정되고, 애플리케이션 이름으로 식별되고 애플리케이션과 관련되는 API 키가 생성될 수 있다.
하나 이상의 BOPS 구현에서, 클라이언트 장치(104) 상에서 동작하는 애플리케이션과 BOPS 서버(102) 사이의 통신은 양방향 SSL/TLS 위에 설정된다. 생성(Genesis) 프로세스는 이와 같은 연결을 설정하고 서버(102)가 양방향 SSL/TLS 통신을 설정하기 위한 개인 키를 생성할 수 있도록, 사용자가 BOPS 서버(102)에 대해 그들 자신을 식별하는 방법을 지정한다. 비밀 질문을 제공하는 것은, 자명한 접근법이고 각자의 당사자(예를 들어, 공급 업체)가 "생성" 단계 동안 개인을 고유하게 설명하는 일련의 질문을 제공할 수 있는, 사용자들이 그들 자신을 식별하는 하나의 메커니즘이다.
사용자 컴퓨팅 장치(104) 상에서 동작하는 클라이언트 애플리케이션은 최종 사용자의 장치(104)를 식별하는 고유 식별자(identifier, ID)를 제공할 책임이 있다. 애플리케이션은 장치(104) 및 관련된 API를 사용하여 사용자와 사용자의 장치(104) 간의 링크에 대해 BOPS 서버(102)에 알릴 수 있다. 5-튜플은 장치(104)를 식별하는 데 사용될 수 있는 하나의 그러한 메커니즘이다.
하나 이상의 BOPS 구현에서, 시스템이 공격 및 공격 벡터를 물리치는데 사용 가능한 각자의 RESTful 호출 및/또는 동작이 지정된다. 또한, 알려진 및 알려지지 않은 공격으로부터 실시간으로 데이터를 보호하기 위한 요청의 형식이 지정되고, IDS에(예를 들어, 장치(112)를 통해) 존재할 수 있다. 예를 들어, 리플레이 완화(replay mitigation)는 엑세스를 검증(validate)하기 위해 암호화 일회성 토큰에서 사용될 수 있다. 그러한 경우에, IDS는 클라이언트(104)와 서버(102)가 서로를 알고 있음을 검증하는(verify) 세번째 계층(tier)이며, 따라서 서버(102)가 애플리케이션 계층에서 완전히 보호되도록 보장한다.
도 16은 리플레이(replay) 방지와 관련된 장치 및 전송 플로우를 예시하는 블록도(1600)이다. 도 16에 도시된 바와 같이, 암호화 일회성 토큰은 액세스를 엑세스를 검증하고(validate) 리플레이(replay), DDoS(distributed denial of service) 및 기타 공격을 포함하는 국제 표준화 기구(International Standards Organization, ISO) 계층 7 사이버 공격으로부터 애플리케이션 계층에서 서버(102)를 보호한다. 토큰과 IDS의 조합은 리플레이(replay), DDoS(distributed denial of service) 및 유사한 공격을 포함하는 국제 표준화 기구(International Standards Organization, ISO) 계층 7 사이버 공격을 탐지하는데 유용하다. 토큰은 한 번의 사용 동안 유효하고(valid) 보통 클라이언트(104)로부터 서버(102)로 전달되고, 그리고 나서 RESTful 호출을 사용하여 BOPS로 반환된다.
하나 이상의 BOPS 구현에서 전제는 DDoS 탐지를 위해 모든 토큰이 구별되어야 하고, 클라이언트와 서버 간에 사용되는 적어도 하나의 알고리즘은 시간이 다를 수 있음을 고려하고, 값은 클라이언트에 대한 클라이언트에 더하여 엑세스에 대한 엑세스와 달라야 한다는 것이다. 도 17은 예시적인 BOPS 구현에 따른 토큰의 알고리즘과 관련된 단계(1700)를 예시하는 상위 레벨 플로우다. 단계 1702에서, 생성 단계 동안 웹, 모바일 또는 임베디드 장치(클라이언트 장치(104))는 토큰을 요청하기 위해 RESTful 호출을 발행한다. 그리고 나서 토큰은 수신되고 클라이언트(104)로부터 서버(102)로의 암호화된 메시지에 내장된다(1704). 서버(102)는 토큰을 수신하고 IDS에 토큰을 전달하여 메시지의 유효성(validity)을 확인하고(1706), 그리고 나서 IDS는 토큰이 유효(valid)한지 검증하고 생성 시간과 현재 시간 간의 차이가 지정된 60초 기간에 포함되는지를 확인한다(1708).
도 18은 다대다(many-to-many) 관계의 생성/등록과 사용자/장치의 산물을 예시한다. 모바일 클라이언트(104) 상에는, 각 계정과 연결된 신원 요소가 도시된다. 도 18의 서버 측에서, BOPS 서버(102)는 각각의 신원과 관련된 신원 속성, 계정 및 장치와 관련하여 도시된다. 높은 레벨의 보증으로 데이터 암호화 및 보안 클라이언트/서버 통신을 수행하기 위해, 신원 정보는 사용자 계정(예를 들어, 도 18에 도시된 Alice 또는 Bob의 계정)이 그들의 상응하는 신원의 기능으로 적절하게 인증되는 보안 요소와 연결된다.
생성 단계를 시작하기 위해, 클라이언트 장치(104)는 아래의 표 2에 도시된 각자의 값 중 일부 또는 전부를 지정함으로써 5개의 튜플을 설정하도록 선택할 수 있다. IDS는 클라이언트에 의해 설정되지 않은 5개의 값 중 어느 것을 결정할 수 있으며 토큰을 RESTful 형식으로 클라이언트에 반환할 수 있다. 클라이언트(104)와 서버(102)는 동일한 5개의 튜플을 공유하고, 그리고 나서 이는 차례로 IDS 또는 BOPS 서버(102)에 의해 인코딩되고 비교되는 SHA512인 타임스탬프를 계산하는데 사용된다. 계산된 타임스탬프는 5개 튜플을 기반으로 하는 시간으로 뒤로 이동하며 각각의 호출에 대해 고유하다.
따라서, 하나 이상의 구현에서 토큰의 모든 값은 비교를 위해 SHA512 합(sum)으로 변환되기 때문에, 토큰은 타임스탬프 자체를 포함하지 않는다. 이것은 블라인드 리플레이를 방지하기 위해 값이 각각의 분 값 간격으로 변경되는 것을 허용한다. 또한 토큰의 분 범위는 충분히 큰 엔트로피(48,771,072)를 허용하고 그 때문에 시행착오 공격을 방지하도록 3(60이 아님)으로 구성될 수 있다.
또한 시맨틱(semantic) 엔진은 보안 관리자가, 임의의 국제 표준을 벗어나고 매우 다양한 공격에 대해 추가적인 확인과 균형을 제공할 수 있는, 공격 탐지 및 방지를 위한 추가 사용자 지정 파라미터를 생성하는 것을 허용하도록 구성될 수 있다.
하나 이상의 구현에서, 리플레이 탐지는 5개 튜플에서 작동한다. 위의 표 1에 나타낸 것과 같은 값은 서버(102)에 제공될 수 있다. 대안적으로, 서버(102)는 값을 무작위로 선택할 수 있다. 리플레이에 따라, 허용 가능한 값의 범위와 엔트로피가 초기에 결정된다. 생성(Genesis) 단계 동안 5개 튜플의 값이 지정되지 않은 경우, 알고리즘은 다음의 값을 사용할 수 있다.
값 엔트로피
0년부터 현재 연도 (2016) 2017
0-11월 12
0-27일 28
0-23 시간 24
0-2분 (분 엔트로피는 3이므로 동시 공격의 수를 제한하는 3분 동안만 값이 동일하다) 3
총 엔트로피 = 2016*12*28*24*3 = 48,771,072
예시적인 구현에 따르면, 뒤로 회전하는 알고리즘이 실행된다. 각자의 월이 현재의 월보다 작거나 같으면 연도는 같을 수 있다. 대안으로, 월이 현재의 월보다 크면, 연도를 뒤로 로테이션 해야 한다. 이 두 개의 케이스는 알고리즘을 보여준다.
Figure pct00002
예 1의 현재 월은 8(8월)이고 월에 대한 생성(Genesis) 값은 11이고, 11 > 8이므로, 그리고 나서 우리는 연(year)을 5의 간격으로 범위를 좁히고 연(year)은 2011이 된다. 나머지 값은 실제 날짜의 값보다 작은 생성(Genesis)의 배수이다.
동일한 현재 날짜와 시간을 사용하는 두 번째 예와 관련하여, 현재 월은 8(August)이고 월에 대한 생성(Genesis) 값은 4이고 4 <= 8이다. 연(year)은 2015년에 동등한 5의 간격으로 범위가 좁아진다. 따라서 연(year)은 2015가 되고 나머지 값은 실제 날짜 값보다 작은 생성(Genesis)의 배수이다.
하나 이상의 BOPS 구현에서, 다양한 레벨의 데이터 프라이버시가 제공될 수 있고, 각각은 누군가가 바이오메트릭 정보를 재설정 및/또는 손상하는 것을 방지하기 위해 암호화된 바이오메트릭 정보를 포함할 수 있다. 하나의 프라이버시 레벨은 모든 비-바이오메트릭 데이터가 평문으로 저장(부동태화)되도록 정의할수 있다. 이것은 사용 패턴 및 인증 기록의 보고 및 분석을 단순화하고, 부인 방지, 위치, 날짜 및 패싯(faceted) 검색과 같은 기타 요소를 포함할 수 있다. 예를 들어, 비교적 쉽게 하나는 2016년 6월동안 클리브랜드에서 실패한 인증 시도 횟수를 볼 수 있으며, 개인 및 장치와 관련된 정보가 제공될 수 있다. 이 첫 번째 프라이버시 레벨은 평문 부동태화(passivated) 데이터에서 동작하는 정교한 툴의 기능으로 달성될 수 있다. 다른 그리고 더 높은 레벨의 프라이버시는 모든 비-바이오메트릭 데이터가 암호화된 형식으로 저장되지만 클라이언트별로 별개의 복호화 키를 요구하지 않는다고 정의할 수 있다. 따라서, 클라이언트 장치(104)는 동일한 복호화 키를 사용하도록 구성될 수 있으며, 이는 내부자가 복호화 키에 대한 엑세스 권한을 가질 수 없거나 거의 가지고 있지 않다는 점에서 앞서 설명된 첫 번째 레벨의 프라이버시보다 더 안전한 것으로 고려된다. 그렇지만 더 높은 레벨의 프라이버시는 모든 비-바이오메트릭 데이터가 암호화된 형식으로 저장되고 복호화 키는 각각의 신원 별로 고유한 것을 요구할 수 있다. 각각의 사용자의 데이터가 바이오메트릭과 관련된 키로 암호화 되기 때문에, 이것은 향상된 프라이버시 및 분리를 제공한다. 높은 레벨의 프라이버시에서, 예를 들어 개인 식별가능 정보(personally identifiable information, PII)를 포함하는 사용자 데이터는 아마도 메모리 내에서 매치가 발생하는 순간을 제외하고, 클라이언트 장치(104)에서 항상 암호화되는 것으로 여기서 예상된다. 하나 이상의 BOPS 구현에서, 사용자는 트랜잭션을 허가(authorize)하기 위해 인증(authenticate)하고 사용자 데이터(예를 들어, 로그인 자격 증명, 파일 등)를 복호화 하기 위해 인증한다. 게다가, 저장 데이터(data at rest) (예를 들어, 부동태화 데이터)는 항상 서버 컴퓨팅 장치(102) 상에서 및 클라이언트 장치(104) 상에서 암호화된다. 평문 데이터는 바람직하게 매치 프로세스가 발생할 때 메모리에만 존재한다.
하나 이상의 BOPS 구현에서 생성(Genesis) 플로우에 대한 실질적으로 임의의 커스터마이제이션이 가능하게 하는 개방형 플랫폼이 제공된다. 생성(Genesis)의 몇몇의 예는 액티브 디렉토리에 대한 사용자 이름 및 패스워드 엑세스, 검증하는 이메일 또는 텍스트 메시지를 포함할 수 있거나, 개인의 신원은 운전 면허증, 출생 증명서, 여권, 사회 보장 번호 또는 기타 적절한 자격 증명의 기능과 같이 물리적으로 검증될 수 있다.
사용자 계정의 사전 등록은 비즈니스 규칙을 구현하는 배치(batch) 프로세스에서 발생할 수 있으며, 기관의 정책 및 절차는 이러한 비즈니스 규칙에 기여할 수 있다. 비즈니스 규칙은, 사용자를 그룹 또는 디렉토리로 조직하여 역할 관리의 일부 특정 요구에 맞는 권한 및 기타 속성의 레벨을 결정하는 엑세스 관리 플랫폼과 통합될 수 있다. 이것은 개발자가 BOPS 서버(102)에 의해 엑세스되는 회원 정의의 입력으로 적용될 수 있는 회원 프로파일(예를 들어, 사용자 프로파일, 관리자 프로파일, 매니저 프로파일 및 최고 관리자 프로파일)의 공식을 구성할 수 있도록 하는 유연성을 제공한다. 본 출원에 따른 생성(Genesis) 프로세스는 위험 관리에 대한 완전한 종속을 형성할 수 있으며, 따라서 다운스트림 처리를 결정할 수 있다.
도 19a는 단일 클라이언트 장치(104)에서 등록을 개시하는 다수의 사용자와 관련된 장치 및 단계(1900)를 도시한다. 사용자와 장치(104) 사이의 관계는 "다대다(many-to-many)"(M:M)일 수 있다. 첫 번째 등록 단계가 추가될 수 있다(A1, 바이오메트릭 등록(Enrollment) 시작, A2 등록(Enrollment)을 요청(x, 509), A3 등록(Enrollment) 요구를 반환, A4 계정 등록(Registration)을 요청(dev ID, 사용자 ID + ½ IBV), A5 등록(Registration)을 반환). 이 단계는 두 번째 사용자(B1-B5)에 대해 반복될 수 있다. 다대다 관계는 생성과 등록의 분리의 기능으로 발생할 수 있다. 또한, 생성을 통해 식별된 주체는 많은 바이오메트릭으로 여러 번 등록할 수 있다. 클라이언트/서버 통신을 시작하기 위해 사용자는 클라이언트 장치에 대해 발급된 고유한 클라이언트 인증서의 모션 등록 프로세스를 시행하는 클라이언트 장치에서 그의 또는 그녀의 바이오메트릭을 캡처한다. 등록의 보안 부분이 완료되면, 등록 프로세스를 끝내는 사용자의 바이오메트릭 정보의 등록이 마련된다. 사용자는 많은 장치(클라이언트)를 가질 수 있고, 장치(클라이언트)는 많은 사용자를 가질 수 있다. 장치(클라이언트)는 많은 바이오메트릭을 지원할 수 있다.
도 19b는 다중 사용자 계정에 관한 정보를 저장하는 클라이언트 장치(104)로부터 인증 세션을 시작하는 하나의 예시적인 사용자 Alice와 관련된 장치 및 단계(1910)를 도시한다. 도 19b에 도시된 예에서, Alice는 인증 세션을 시작하고(1), 클라이언트 장치(104)에서 동작하는 애플리케이션은 바이오메트릭 인증을 요청한다(2). 바이오메트릭 인증이 완료된 후(3), 클라이언트 장치(104)에서 동작하는 애플리케이션은 TLS를 통해 Alice의 신원 속성을 전송하도록 장치(104)를 구성한다(4). 이후, BOPS 서버(102)는 모든 등록 요소의 무결성을 고려하여 인증 요청을 처리하고 결과를 반환한다(5).
도 19b에 도시된 예를 참고하면, Alice가 실수로 Bob의 계정을 사용하여 인증 세션을 시작하더라도, 클라이언트 장치(104)는 CBV가 등록 중에 생성된 IBV와 다르고 인증이 성공하지 못하기 때문에 서버에 임의의 요청을 렌더링하지 않는다.
도 19c는 사용자의 계정의 폐지와 관련된 예시적인 장치 및 단계(1920)를 도시한다. 도 19c에 도시된 예에서, 3명의 사용자(Eve, Bob 및 Alice)와 관련된 정보가 도시된다. 하나 이상의 폐지 규칙은, 관리상의 그래픽 사용자 인터페이스(GUI)로 구성된 관리 콘솔을 통하는 것과 같이, 사용자에 의해 정의될 수 있다. 관리자(유사하게 바이오메트릭으로 인증받을 수 있는 사람)와 관련된 역할은 규칙을 실행하는 것에 책임이 있을 수 있다. 그림 19C에 도시된 예에서, Alice의 계정은 활성화 인증서를 가지고, Bob의 계정은 전송 보안 레벨에서 차단되는 만료된 인증서를 가지고, Eve의 계정은 BOPS 관리자에 의해 폐지되었다. 보다 구체적으로, Eve의 인증서가 BOPS 서버(102)를 통해 폐지된 후(1), Eve의 계정과 연관된 클라이언트 장치(104)로부터 인증 요청이 수신된다(2). BOPS 서버(102)는 Eve의 엑세스가 차단되었음을 나타내는 메시지 또는 다른 적절한 콘텐츠를 반환한다(3). Bob의 인증서와 관련하여, 90일의 기간이 정의되며, 그 이후에 Bob의 인증서는 만료된다("TTL")(4). 그 후, Bob의 계정과 관련된 클라이언트 장치(104)로부터 인증 요청이 수신되고(5), Eve의 경우와 유사하게, Bob의 엑세스가 차단되었음을 나타내는 메시지 또는 다른 적절한 콘텐츠가 BOPS 서버(102)에 의해 클라이언트 장치(104)로 전송된다(6). Alice의 계정과 관련하여 추가적인 90일 기간의 연장 기간이 제공되고(7), Alice의 계정과 관련된 클라이언트 장치(104)로부터 인증 요청이 수신된다(8). BOPS 서버(102)는 Alice가 인증되었다는, 여기에 도시되고 설명된 것과 같은 인증 결과를 나타내는 메시지 또는 다른 적절한 콘텐츠를 반환한다(9).
여기에 도시되고 설명된 모듈과 관련하여 해결된 문제 중 하나는 리플레이 공격의 방지이다. 하나 이상의 구현에서, DDoS 탐지의 경우, 전형적으로 서버 상에서의 프로파일을 일반 이름(Common Name, CN) 필드에서의 신원에 연결하는 식별자인 모든 토큰은 구별된다. 클라이언트(104)와 서버(102) 사이의 알고리즘은 시간이 다를 수 있음을 고려하고, 값은 클라이언트(104)로부터 클라이언트(104)에 더하여, 엑세스로부터 엑세스와 달라야 한다.
하나 이상의 구현에서, 인증서 배포는 다음과 같이 작동한다. X.509 인증서는 클라이언트 장치(104)에 설치된 애플리케이션 소프트웨어의 기능을 포함하여, 클라이언트 장치(104)에 미리 로드된다. 생성 프로세스 이전에, 클라이언트(104)는 (여기에 도시되고 설명된 바와 같이) 튜플 중 일부 또는 전부를 지정함으로써 5-튜플 값을 설정한다. 등록 프로세스 동안, 클라이언트(104)는 BOPS 서버(102)로부터 토큰을 요청하기 위해 RESTful 호출을 발행한다. 토큰이 수신되면, 그것은 서버에 대한 클라이언트의 암호화된 메시지에 내장된다. 서버는 토큰을 수신하고 생성 시간과 현재 시간의 차이가 지정된 60초 기간의 범위에 포함되는지 확인하여 메시지의 유효성을 확인한다. 서버(102)는 5-튜플 값 중 어느 값이 누락되었는지 결정하고 토큰을 RESTful 형식으로 클라이언트에 반환한다. 클라이언트(104)와 서버(102)는 동일한 5-튜플 값을 공유하고, 그리고 나서 이는 예를 들어 기능 분석과 같이 IDS에 의해 차례로 인코딩되고 비교되는 SHA512인 타임 스탬프를 계산하는데 사용된다. 예를 들어, 그리고 여기에 설명된 바와 같이, 계산된 타임스탬프는 5-튜플을 기반으로 하는 시간으로 뒤로 이동하며 각각의 호출에 대해 고유하다.
본 출원은 클라이언트 인증서가 유효하게 남아 있는 시간(Time-to-Live 또는 TTL)의 길이를 구성할 수 있다. 인증된 사용자의 폐지된 인증서는 새로운 인증서로 조용히 대체될 수 있다. 따라서 TTL은 사용자 인증을 지원하기 위해 IBV 및 CBV와 함께 작동하는 "벨트 및 멜빵" 접근 방식이다. 토큰 폐지는 허가(authorization)에 대한 특정 비즈니스 요구 사항을 제공하기 위해 사용자 역할 및 다른 요인에 조건부일 수 있다. 예를 들어, 조건 y 및/또는 z가 충족되지 않는 경우와 같이, 1회 또는 x회의 실패되는 인증이 금융 트랜잭션에 대하여 시도한 후, 인증서가 차단될 수 있다.
도 20A는 클라이언트 장치(104)와 BOPS 서버(102) 사이의 클라이언트 인증서의 초기화, 검증 및 확인과 관련된 단계(2000)를 보여주는 단순화된 도식이다. 클라이언트 서명 요청(client signing request, CSR)을 처리하는 것과 관련된 단계는 클라이언트 장치(104)에서 공개-개인 키 쌍을 생성하고, BOPS 서버(102)로 전송되는 공개 키 및 주체 이름에 서명하는 것 (여기에서 일반적으로 "소유의 증명(Proof of possession)"을 수행하는 것으로 지칭됨)을 포함할 수 있다. 여기에서 언급한 바와 같이, 클라이언트는 양방향 SSL을 사용하여 계정 등록 요청을 전송한다. 인증서의 주체 이름을 확인하고, BOPS 인증 기관(Certificate Authority, CA) 개인 키로 클라이언트 요청에 서명하고, OTP 메커니즘으로 클라이언트 인증서의 패스워드를 생성한 후, BOPS 서버(102)는 클라이언트 인증서 패스워드를 클라이언트 장치(104)에 반환한다. 등록된 클라이언트는 인증서 서명을 확인하고 .p12 컨테이너를 생성하여 클라이언트 개인 키와 서명된 인증서를 저장하지만, 비밀번호는 저장하지 않는다. OTP 메커니즘이 각각의 클라이언트 요청에 대해 1회용 패스워드를 생성하기 때문에, 패스워드는 가급적 클라이언트 장치에 저장되지 않는다.
도 20b는 제3자 서버 및 BOPS 통합 예에서 클라이언트 인증서 등록 프로세스(2010)를 도시한다. 예를 들어, 도 20a에 도시된 바와 같은 CSR 프로세스는, 광범위하게 보여지며, 사용자 등록으로 시작한다. 그림 20B에 도시된 예에서 "사용자 계정 등록"은 생성 및 등록과 관련된 단계를 설명하는 데 사용되며, 계정은 신원(identity) 구성 요소를 나타내는 반면, 클라이언트 인증서는 신원(identity) 속성을 나타낸다.
도 20b에 도시된 예시적인 구현에서, 사용자가 등록 프로세스를 시작하고 계정 등록 요청과 함께 그의/그녀의 바이오메트릭 정보를 BOPS 서버(102)에 보낸 후, 키 쌍/CSR 생성이 클라이언트(104)에서 트리거된다. 프로파일 등록 요청이 수신되면, BOPS 서버(102)는 프로파일 확인(validation)을 나타내는 도 20b에 도시된 바와 같은 엑세스 관리 어댑터(제3자 기업에서 활용되는 엑세스 관리 솔루션/플랫폼일 수 있는)에 그것을 추가적으로 보내고, 그리고 나서 계정 로그인 검증(verification) 및 확인(validation)을 위해 제3자 서버에 추가로 전송한다. 제3자 서버는 로그인 데이터를 검증(validate)한 후 인증 토큰을 제공하고, 그리고 나서 계정/프로파일 등록을 완료하는 BOPS 서버(102)로 인증 결과와 인증 토큰을 다시 반환하는 엑세스 관리 어댑터로 인증 결과를 다시 반환한다. BOPS 서버(102)는 인증 토큰을 암호화하고, 바이오메트릭 데이터를 저장하고, BOPS CA로 CSR에 서명하고, 암호화된 인증 토큰을 클라이언트 애플리케이션에 전송한다. 이는 바이오메트릭 인증의 기능으로 더 높은 수준의 검증을 위해, 그것의 저장소에 축적된 수십억 개의 계정을 이미 가지는 기업(예를 들어, 은행)과 통합된 예시적인 구현을 나타낸다.
하나 이상의 구현에서, 빠른 응답 코드(QR 코드)는 여기에 도시되고 설명된 하나 이상의 모듈의 실행을 트리거하는 데 사용될 수 있다. 예를 들어, 비즈니스 파트너(예를 들어, 은행) 로그인 페이지는 각자의 세션 기회 식별자를 포함하는 QR 코드 이미지를 표시하도록 구성될 수 있다. 클라이언트 컴퓨팅 장치(104)에서 실행되는 MCA는 QR 코드를 스캔하고, 그것이 세션에 연결되었다는 신호를 위해 세션을 등록하고, 여기서 가르치는 것에 따라 사용자의 바이오메트릭으로 인증하는 하나 이상의 모듈(예를 들어, 인증 마법사)을 실행할 수 있다. 도 21은 제3자 서버가 BOPS 서버(102)에 세션 기회를 등록하고, 응답하여, 새로운 인증 세션에 사용 가능한 정보가 BOPS 서버(102)에 의해 제3자 서버로 제공될 수 있고, 정보가 QR 코드 내에서 제공(예를 들어, 표시)될 수 있는 예시적인 QR 코드 인증 플로우(2100)을 도시한다. 제3자 서버는 세션 상태 정보에 대한 하나 이상의 요청을 전송할 수 있다. 도 21에서 사용자("액터"로 지정됨)는 QR 코드를 스캔하고 외부의 제3자 서버에 통지할 수 있는 BOPS 서버(102)로 세션을 등록한다. 여기에 도시되고 설명된 바와 같이, 바이오메트릭 인증 시 제3자 서버를 포함하여 사용자 세션이 설정될 수 있다.
여기에서 설명되고 상세해진 BOPS 서버의 하나 이상의 추가 구현에서, BOPS 서버는 주장의 권한 기반 발행을 제공하고 인증 동안 제3자 신원 제공자에 대한 필요를 제거하는 보안 사용자 신원 모델을 구현하는데 사용된다. 설명된 사용자 신원 모델은 블록체인 기술을 활용하여 제3자에 민감한 바이오메트릭 데이터를 신뢰할 필요 없이 검증 가능한 자격 증명(credential)의 교환을 보장한다. 예를 들어, 도 14를 참조하여 설명된 다중 암호화 공유(그리고 잠재적으로 대안의 오프 체인 스토리지(예를 들어, 휴대용 하드 디스크 드라이브, 모바일 장치 스토리지, IPFS, Dropbox, Google 드라이브, AWS 등)에 걸쳐 분산된 그것의 중복되는 공유)는 BOPS 서버에서 검색된다. 이러한 암호화 공유는 사용자의 검증 가능한 자격 증명이 검증 시스템의 일부로 사용되도록 BOPS 서버에 제공된다. 적어도 두 개의 신원 기술(DID 및 BOPS)의 조합은 독립된, 플랫폼 애그노스틱(agnostic)의, 사용자의 존재의 검증을 허용한다. 여기에서 등록 및 인증 프로세스에서 바이오메트릭 기반 프로토콜을 통합함으로써, 사용자는 디지털 신원을 실 세계의 물리적 존재에 연결하도록 보장된다. 또한 사용자는 이 디지털 신원을 완전히 통제할 수 있다. 사용자는 이 디지털 존재에 더 많은 데이터를 추가하거나, 다른 사람에게 추가 정보를 추가하도록 요청하거나, 상황에 의존하여 일부 또는 모든 데이터를 드러낼 수 있다. 또한 사용자는 다른 사람과 데이터를 공유하는 것에 대한 그들의 동의를 기록하고 그러한 공유를 쉽게 가능하게 할 수 있다. 따라서 여기에 설명된 디지털 신원은 지속적이고, 휴대용이며, 그것의 유용성을 위해 임의의 단일한 제3자 허가(authorization) 또는 확인(validation)에 의존하지 않는다.
특히 도 22 내지 도 25를 참조하면, 보안 사용자 식별 모델은 BOPS 표준을 사용하여 바이오메트릭 자격증명을 안전하게 교환하기 위한 프로세스 또는 방법으로서 구현된다. 이제 도 22를 참조하면, 여기에서 논의되는 바이오메트릭 오픈 프로토콜 표준(Biometric Open Protocol Standard, BOPS)는 사용자에게 그들의 인증 및 신원 데이터의 저장 및 사용에 대한 제어를 제공하기 위해 분산형 보안 사용자 신원 모델에서 구현된다.
간단히 말해서, 필수 기술 분야에서 보통 레벨의 기술을 소유한 사람들은 설명된 BOPS 프로토콜이 온-디바이스(예를 들어, FIDO UAF 호환), 서버 측 또는 원격 저장소와 분산 인증 프로세스를 활용하여 인증에 대한 사용자 제어를 허용하는 다중 배포 모델의 조합으로 확장될 수 있음을 이해할 것이다. 앞의 설명은 오직 설명의 편의를 위한 것이며 BOPS 표준과 하나 이상의 분산 원장 기술을 통합하여 사용할 수 있는 추가 접근 방식을 제한하려는 의도가 아니다. 실제로, 하나의 특정 구성에서, BOPS 표준은 오프 디바이스 바이오메트릭 자격 증명이 인증 챌린지 및 다른 네트워크 기반 신원 검증에 참여하는데 사용되는 것을 허용한다. 그러나, 하나 이상의 추가 구현에서, 인증에 사용되는 바이오메트릭 데이터는 BOPS 서버에 의해 분산된 저장 위치에 배포될 뿐만 아니라 바이오메트릭 데이터가 안전하고 변조 방지된다는 암호화 기반 보증을 제공하기 위하여 블록체인 기술을 사용하여 하나 이상의 분산 원장에 지속된다.
계속해서 도 22를 참조하여 도시된 바와 같이, 최종 사용자(또는 간단히 "사용자")와 같은 사용자(2200)는, 사용자의 각자의 신원확인(identification) 및/또는 신원(identity) 데이터에 대한 제어를 유지하는 어떤 사람이다. 하나의 비제한적인 예에서, 사용자(2200)는 학생, 직원, 고객 및 기타이다. 그러나, 대안적인 구성에서, 사용자(2200)는 사용자 각자의 신원확인(identification) 및/또는 신원(identity) 데이터에 대한 제어를 유지하기 위해 소지자(예를 들어, BOPS 서버(102))를 지정할 수 있다. 예를 들어, 소지자는 사용자(2200)로부터 그들을 대신하여 식원 확인(identification) 기반 트랜잭션에 참여하는 허가를 가진 하나 이상의 서비스, 회사 또는 기관일 수 있다. 하나 이상의 구현에서, 허용된 소지자는 웹 서비스, 모바일 앱, 또는 사용자의 개인 장치(예를 들어, 클라이언트 장치)에 설치되거나 그로부터 액세스 가능한 기본 애플리케이션을 포함한다. 여기에서 사용된 바와 같이, 소지자는 일반적으로 분산 식원확인(identification) 정보를 수신하고, 저장된 분산 신원(identity) 정보에 액세스하고/하거나 리소스에 대한 액세스의 대가로 이러한 분산 신원(identity) 정보를 리소스 액세스 제공자에게 제공하는 임의의 엔티티를 나타낸다. 하나의 특정 구현에서, 이전에 설명된 BOPS 서버(102)는 다양한 사용자(2200)를 위한 소지자로서 기능하도록 구성된다.
액세스 제어 플랫폼 또는 신원 인가자에 등록을 바라는 각각의 사용자(2200)는, 등록 프로세스의 일부로 다양한 전기의(biographic) 및/ 바이오메트릭 데이터를 제공한다. 따라서 수집된 전기의 및 바이오메트릭 데이터는 사용자의 신원의 디지털 표현으로 생각될 수 있다. 하나의 특정 구현에서, 이러한 전기의 및 바이오메트릭 정보의 수집은 휴대용 파일 또는 데이터 구조로서 캡슐화되거나 패키징된다. 하나의 비제한적인 구현에서, DID 문서(2204)는 그러한 전기의 및 바이오메트릭 정보에 대한 휴대용 컨테이너 또는 파일로서 기능한다. 하나 이상의 구현에서, DID 문서(2204)는 사용자의 신원을 확인하기 바라는 원격 인증 시스템과 상호작용하는데 필요한 적어도 메타데이터를 포함하는 데이터 파일, 컨테이너, 코드 또는 디지털 문서이다. 또 다른 예에서, DID 문서(2204)는 단일 JSON 객체이다. 또 다른 구현에서, DID 문서(2204)는 RFC7159 사양을 준수하는 JSON 객체이다. 하나 이상의 비제한적인 구현에서, 여기에 설명된 DID 문서(2204)는 인증(authentication) 및 허가(authorization) 정보를 포함할 수 있다. 특정 구성에서, DID 문서(2204)는 개인 식별가능 정보(personally identifiable information, PII)를 포함하지 않는다.
여기에 설명된 시스템, 방법 및 컴퓨터 제품의 특정 구성에서, 검증 가능한 자격 증명은 블록체인 외부에 저장되고 다른 개인 정보 또는 자격 증명에 더하여 적어도 하나 이상의 인증(authentication) 데이터 세트 또는 값을 포함한다. 특정 구성에서, 인증(authentication) 데이터 세트는 인증 시스템에 대해 사용자를 인증하는 데 사용될 수 있는 메커니즘 집합(예를 들어, 공개 키, 바이오메트릭 템플릿 또는 바이오메트릭 데이터의 암호화된 공유 조차도)을 포함한다. 또한, 한 구성에서, DID 문서(2204)에 포함된 인증 데이터 세트는 DID 문서(2204)를 수정할 수 있는 엔티티를 설명하는 허가(authorization) 정보를 포함한다. 예를 들어, 사용자가 사용자의 DID 문서(2204)를 변경할 수 있는 허가를 소지자에게 부여한 경우, DID 문서(2204) 자체는 이러한 허가된 사용자를 나타내는 데이터를 포함할 수 있다. 또한 허가(authorization) 데이터는 서비스 제공자와 같은 엔티티와 신뢰되는 상호 작용을 시작하는 데 사용되는 서비스 말단의 집합을 포함할 수 있다.
도 22에 추가로 도시된 바와 같이, 발행자(2206)는 DID 문서(2204)를 생성하는 엔티티이다. 예를 들어, 발행자(2206)는 신원 모델에 등록하기 위한 사용자(2200)로부터의 요청에 응답하여 DID 문서(2204)를 생성하도록 그것의 코드 실행에 의해 구성되는 서버 또는 프로세서이다. 일 구현에서, 발행자(2206)는 장래의 등록자에 대한 정보(예를 들어, 전기의 및 바이오메트릭 정보)를 수신하고 그 수신된 정보를 DID 문서(2204)로 변환한다. 그러나, 도 25에 도시된 바와 같이, 발행자(2206) 그 자체가 DID 문서(2204)를 생성하는 프로세서를 소지자 시스템 또는 BOPS 서버(102)와 같은 서버에 위임할 수 있다.
임의의 엔티티는 소지자를 포함하는 발행자(2206)일 수 있는 반면에, 발행자(2206)의 일부 추가적인 예는 기업, 정부, 비영리 단체 및/또는 개인을 포함할 수 있다. 하나 이상의 구성에서 발행자(2206)는 생성된 DID 식별자(2202) 및/또는 DID 문서(2204)를 소지자에게 전송한다. 추가 구현에서, 발행자(2206)는 생성된 DID 문서(2204)를 신원 허브(2208)로 전송한다.
계속해서 도 22를 참조하면, 검증 가능한(verifiable) 자격 증명(credential)이 생성되었으며, 그것은 추후 사용을 위해 안전한 위치에 저장된다. 예를 들어, 검증 가능한 자격증명은 하나 이상의 신원 허브 및 저장소(2208)에 저장된다. 여기서 신원 허브 및 저장소(2208)는 검증 가능한 자격증명이 저장되고 검색되는 안전한 개인 데이터 저장소이다. 예를 들어, 신원 허브 및 저장소(2208)는 검증 가능한 자격 증명을 저장, 수정 또는 검색하기 위해 사용자(2200), 소지자(102) 또는 발행자(2206)가 엑세스 가능한 하나 이상의 로컬 또는 원격 액세스 데이터 저장 장치이다. 마찬가지로, 신원 허브 및 저장소(2208)는 메시지 및 데이터를 하나 이상의 검사자(2210)에 중계하거나 전송한다. 하나 이상의 구현에서, 신원 허브(2208)는 데이터베이스 또는 저장 시스템, 단층 파일 체계(flat file system), 관계형 데이터베이스, 또는 사용자(2200) 또는 소지자(102)에 의해 액세스 가능한 대량의 저장 설비로 구성된다. 예를 들어 신원 허브는 Dropbox, Google 드라이브, AWS, Storj 및 기타 유사한 "클라우드" 기반 스토리지 설비를 포함할 수 있다.
추가적인 방식에서, 발행자(2206)(또는 소지자(102))는 또한 DID 문서(2204)에 대한 참조를 제공하는 분산 식별자(decentralized identifier, DID)(2202)를 생성한다. 여기서 DID 식별자(2202)는 검증 가능한 자격 증명(verifiable credential )에 의해 참조되는 개인 정보에 대한 직접 액세스를 제3자에게 제공하는 것 없이 DID 문서(2204)의 검색 또는 액세스를 허용하는 고유 식별자이다. 하나의 비제한적인 구현에서, DID 식별자(2202)는 DID 문서(2204) 내에 포함된 사용자의 신원 정보를 적어도 부분적으로 암호로 해싱한 결과인 고유 비트, 숫자, 값, 문자열(string) 또는 시퀀스로 구성된다. 추가적인 구현에서, DID 식별자(2202)는 텍스트 문자열, 숫자 시퀀스, 영숫자 또는 16진수 시퀀스 또는 이들의 임의의 조합이다. 또한, 이러한 조합은 하나 이상의 데이터 파일, 모듈 또는 코드 조각으로 구현될 수 있다. 또 다른 추가 구성에서, DID 식별자(2202)는 RFC3986을 준수하는 URI 체계이다. 예를 들어, DID 식별자(2202)는 선택적인 경로 및/또는 파편(fragment)이 뒤따르는 고유한 열 시퀀스로 구성된다. 예를 들어, 발행자(2206)는 DID 문서(2202)에 저장된 인증(authentication) 정보를 해싱하여 DID 식별자(2202)를 생성한다. 대안적인 구성에서, DID 식별자(2202)는 DID 문서(2204)의 콘텐츠의 해시된 값 및 DID 문서(2204)의 저장 위치에 대응하는 고유한 값이다.
DID 식별자(2202)가 생성되면, DID를 포함하는 트랜잭션 레코드가 하나 이상의 분산 원장(2212)에 트랜잭션으로 추가된다. DID 문서(2204)와는 달리, 따라서 DID 식별자(2202) 그 자체는 신원 허브(2208)에 저장되지 않는다. 대신, DID 식별자(2202)는 분산 원장 또는 블록체인에 트랜잭션으로 저장된다. DID 식별자(2202)를 트랜잭션으로 분산 원장에 저장하는 것은 DID 문서(2204)의 불변의 인덱스에 더하여 DID 식별자(2202) 생성 시 DID 문서(2204)의 내용의 불변의 기록으로 기능한다. DID 문서(2204)와 DID 식별자(2202)는 암호로 연결되기 때문에, DID 식별자(2202)는 트랜잭션 레코드로 분산 원장(2212)에 추가될 때, 발행자(2206), 소지자/사용자(2200), 그리고 사용자의 신원을 검증하기를 바라는 임의의 제3자(예를 들어, 검사자(2210)) 간의 허용된 교환의 감사 추적을 제공한다.
분산 원장 기술, 구현 또는 사양의 임의의 특정 구현 또는 구성에 제한되지 않고, "블록체인"이라는 용어의 사용은 근본적인 신원 데이터에 대한 변조 또는 수정을 방지하기 위해 공개적으로 검증 가능하고 안전한 구성으로 디지털 트랜잭션을 추적하고 저장하는 공개적으로 투명하고 분산된 원장을 제공하는 하나 이상의 기술을 지칭한다. 하나의 특정 구현에서, 블록체인 또는 분산 원장(2212)은 지속적으로 증가하는 데이터 레코드의 리스트를 유지하도록 구성된 공개 원장으로 조직되는 데이터베이스이다. 여기에서, 원장에 대한 엔트리는 해시를 사용하는 것을 통하여 데이터 레코드를 기록하고 연결하여 블록체인을 형성한다. 예를 들어, 새로운 트랜잭션(예를 들어, 새로운 DID 식별자(2202))이 블록체인에 추가될 때마다 새로운 블록은 이전 블록의 해시를 포함한다. 이러한 방식으로, 각각의 추가적인 블록은 전체 블록체인의 유효성(validity)에 대한 추가적인 보안을 생성한다. 각각의 블록은 트랜잭션이 생성 및/또는 기록될 때 트랜잭션의 순서와 타이밍을 기록하고 확인한다. 따라서, 특정 구현에서, DID 식별자(2202)는 블록체인 상의 트랜잭션으로서 저장된다. 특정 구현에서, 소지자 또는 발행자는 사용자(또는 소지자)가 인증 플랫폼에 등록하기 위한 정보를 제공했다는 통지를 수신하면 DID 식별자(2202)를 생성한다.
사용자(2200)가 보호된 리소스에 액세스하려는 경우, 검사자/검증자(2210)(이러한 보호된 리소스에 대한 액세스를 제어하는)는 사용자(2202)에게 보호된 리소스에 대한 액세스를 제공하기 위해 사용자 또는 사용자를 나타내는 소지자에 DID(2202) 형태의 주장을 요청한다. 검증자(2210)는 사용자의 신원을 지원하기 위해 제공된 자격 증명(예를 들어, DID 식별자(2202) 및 DID 문서(2204))이 목적에 부합하는지 검증하고 블록체인(2212)에서 DID 식별자(2202)의 유효성(validity)을 확인한다. 비제한적인 예로서, 검증자(2210)는 고용주, 보안 요원 및 웹사이트에 의해 유지 및 제공되는 시스템 및 서버를 포함할 수 있다.
이제 도 23을 참조하면, 여기에 설명된 시스템, 방법 및 컴퓨터 구현 제품의 하나 이상의 특정 구현에서, 하나 이상의 BOPS 서버(102)는 (이전에 설명된 바와 같이) 바이오메트릭 공유의 소지자로서 작동하고 서비스 제공자에 사용자를 등록하도록 구성된다. 도 23 및 24의 흐름도에 더하여 도 25의 블록도를 참조하면, 사용자(2202)는 발행자(2206)에 등록한다. 여기서, 사용자(브라우저 사용자 에이전트를 통해)는, 하나 이상의 등록 모듈(2301)에 의해 구성되어 발행자(2206)로서 작동하는 서비스 제공자에 사용자의 바이오메트릭 정보를 등록하는, 사용자 장치(2300) 또는 그것의 소프트웨어 애플리케이션(예를 들어 MCA)에 의해 유발된다. 특정 구현에서, 사용자 디바이스(2300)는 단계(2103)에 도시된 바와 같이 사용자의 초기 바이오메트릭 벡터(IBV)(예를 들어, 일부 바이오메트릭 데이터)를 캡처하도록 IBV 모듈(2303)에 의해 구성된다.
추가 구현에서, 캡처된 바이오메트릭 벡터(IBV)는 단계 2105에 도시된 바와 같이 사용자 장치(2300)에 여전히 로컬(local)인 동안 적어도 2개의 공유로 암호화된다. 예를 들어, 사용자 디바이스(2300)는 IBV를 2개 이상의 공유로 시각적으로 암호화하도록 암호화 모듈(2305)에 의해 구성된다. 여기서, 암호화된 IBV의 암호화된 공유 중 적어도 하나는 단계 2107에 도시된 바와 같이 로컬 모바일 장치 상에 보유된다. 하나 이상의 구현에서, 시각적 암호화 및 샤미르 비밀 공유와 같은 알고리즘은 더 많은 수의 공유를 생성하기 위해 사용자 장치(2300)에 의해 활용된다. 하나의 비제한적인 구성에서, 사용자 장치(2300)는 사용자 장치(2300)의 하나 이상의 로컬 메모리 장치가 나중에 검색하기 위해 암호화된 공유를 저장하게 하는 암호화된 공유 저장 모듈(2307)에 의해 구성된다.
도 23에서 계속하면, 사용자 장치(2300)는 공개 및 개인 키를 생성하기 위해 키 생성 모듈(2309)에 의해 추가로 구성된다. 여기서, 도 24의 단계 2109에 도시된 바와 같이, 사용자 장치는 공개 키를 IBV의 적어도 하나의 공유와 관련시킨다. 단계 2111에 도시된 바와 같이, 공개 키 및 공개 키와 관련된 암호화된 공유는 사용자 장치(2300)로부터 발행 서버(2600A)로 전송된다.
관련 기술 분야의 보통 레벨의 기술을 소유한 사람들은 IBV의 적어도 하나의 추가적인 암호화된 공유가 RDBMS 또는 지속성 클러스터(예: Apache SOLR) 말미 중 하나에 저장될 수 있음을 인식할 것인 반면, 단계 2013에서와 같이 대신 발행 서버(2600A)는 발행자 서명 데이터와 함께 암호화된 공유 및 공개 키를 BOPS 서버(102)에 전송한다. 여기서, 발행자 서명 데이터는 발행자 서버(2600A)가 암호화된 공유 및 공개 키의 소스임을 식별하는 임의의 해시, 코드, 암호화 값 또는 데이터 세트일 수 있다. 예를 들어, 발행자 서명 데이터 그 자체는 공개 키 또는 발행자가 개인 키의 소지자인 공개 키/개인 키 쌍일 수 있다.
이전에 상세히 설명된 바와 같이, BOPS 서버(102)는 발행자 데이터에 더하여 암호화된 공유 및 공개 등록 암호화 키 둘 다를 사용하여 DID 문서(2204)를 생성한다. 예를 들어, BOPS 서버(102)는 단계 2115에 도시된 바와 같이 발행자 서명, 등록 공개 키 및/또는 암호화된 공유를 사용하여 DID 문서(2204)를 생성하도록 DID 생성 모듈(2401)에 의해 구성된다. 마찬가지로, DID 생성 모듈(2401)은 DID 문서(2204)와 함께 사용하기 위한 DID 식별자(2202)를 생성하도록 추가로 구성된다. 예를 들어, DID 문서의 내용과 위치는 고유한 DID 식별자(2202) 값을 생성하는 데 사용된다. 이러한 값은 DID 문서(2204)의 해시 또는 내용의 일부 또는 전부는 물론, 근원적인 DID 문서(2204)를 식별하거나 검색하는 데 필요한 특정 저장 위치, 파일 참조, 인덱스 번호 또는 다른 데이터를 나타낼 수 있다.
단계 2117과 관련하여 도시된 바와 같이, BOPS 서버(102)는 DID 문서를 신원 허브(2208)에 저장하도록 DID 저장 모듈(2403)에 의해 구성된다. 예를 들어, BOPS 서버(102)는 클라우드 기반 저장 저장소(2208)에 액세스하고 DID 문서(2204)를 하나 이상의 휴대용 저장 형식으로 저장하기 위해 하나 이상의 API에 의해 구성된다.
추가로, BOPS 서버(102)는 지속성을 위해 생성된 DID 식별자(2202)를 선택된 블록체인(2212)에 추가하도록 DID 지속성 모듈(2405)에 의해 추가로 구성된다. 이러한 방식으로, DID 식별자(2202)는 DID 문서(2204)를 결정하기 위한 블록체인 애그노스틱의 방법을 제공한다. DID 지속성 모듈(2405)은 기존의 블록체인 또는 분산 원장에 추가할 트랜잭션 블록을 생성하도록 BOPS 서버(102)의 프로세서를 구성한다. 대안으로, 그러한 원장이 존재하지 않는 경우, DID 지속성 모듈은 분산 원장의 생성을 야기하고 원장에 새로운 트랜잭션을 추가한다. 필수 기술 분야의 보통 레벨의 기술을 소유한 사람은 트랜잭션 블록 해싱과 같은 추가 기능이 인식되고 이해된다는 것을 인식한다.
하나의 방식에서, 단계 2117에서와 같이 BOPS 서버(102)가 관련된 DID를 블록체인(2212)에 등록한 후, 모바일 장치(2300)는 사용자의 등록의 성공(또는 실패)을 통지받는다. 단계 2119에 도시된 바와 같이, 사용자를 서비스 제공자에 성공적으로 등록하면, 사용자는 사용자의 DID 문서(2204)에 해당하는 DID 식별자(2202)를 수신할 것이다.
설명된 사용자 등록 시스템의 추가 구현으로 돌아가서, 도 25는 사용자(2200)와 등록 서비스 제공자(2600) 사이의 프롬프트(prompt) 및 데이터의 교환을 상세히 설명한다. 예를 들어, 사용자(2200)는 모바일 앱 클라이언트(2300)를 사용하여 등록 프로세스를 시작한다. 모바일 앱 클라이언트(2300)는 사용자(2200)로부터 IBV를 요청한다. 예를 들어, 모바일 앱 클라이언트(2300)는 모바일 컴퓨팅 플랫폼의 하나 이상의 이미징 장치가 서비스 제공자에 등록하는 사용자(2200)의 하나 이상의 이미지를 획득하는 것을 야기한다. 도 25에 추가로 도시된 바와 같이, 바이오메트릭 벡터는 암호화 공유로 변환될 수 있다. 도 25의 구현에서 도시된 바와 같이, 바이오메트릭 공유는 모바일 클라이언트 애플리케이션(2300)을 사용하여 변환된다. IBV에서 생성된 공유들 중, 공유들 중 하나는 모바일 애플리케이션에 로컬로 저장된다. 또한, 모바일 클라이언트 앱(2300)이 공개/개인 등록 키 쌍을 제공하는 경우, 개인 키는 모바일 클라이언트 상에 로컬로 저장되지 않은 암호화 공유를 암호화하는 데 사용된다.
암호화된 공유 및 등록 키 쌍의 및 공개 키는 등록을 위해 서비스 제공자(2600)로 전송된다. 여기에서, 도 25의 구현과 관련하여 도시된 바와 같이, 서비스 제공자(2600)는 (서비스 제공자(2600)로부터의 공개 키와 같은) 발행자 서명을 제공한다. 발행자 서명, 등록 공개 키 및 암호화된 공유는 BOPS 서버(102)로 전달된다. BOPS 서버(102)는 등록을 원하는 사용자를 위한 소지자로서 기능한다. BOPS 서버(102)는 발행자 서명, 암호화된 공유 및 공개 키를 사용하여 DID 문서(2204)를 생성한다. 일단 생성되면, DID 문서(2204)는 지정되고 준수하는 블록체인(2212)에 첨부되는 DID 식별자(2202)를 생성하기 위한 기반의 역할을 한다. DID 식별자(2202)가 생성되고 상응하는 DID 문서가 블록체인에 저장되면, DID 식별자(2202)가 모바일 클라이언트 애플리케이션(2300)으로 다시 전달되어 사용자는 암호화된 IBV 공유의 절반과 DID 식별자(2202)의 사본의 소유를 유지한다.
바이오메트릭 공유를 포함하여 블록체인에 다면적인 데이터를 저장하는 것이 가능한 반면, 현재 설명된 접근법은 임의의 개인 식별가능 정보를 분산 원장 또는 블록체인(2212)에 저장하지 않는다는 것이 인식될 것이다. DID 문서(2204)에 포함된 바이오메트릭 공유는 신원 허브 또는 개인 저장소 제공자(2208)를 통해 "오프체인"으로 지속되고, 암호로 줄지어진 DID 식별자(2202)의 형태로, 그것들의 "오프체인" 데이터 세트에 대한 참조만이 공공 원장 시스템 내에 배치된다. 이와 같이, 도 24 내지 25에 제공된 등록 프로세스에서 생성된 암호화된 바이오메트릭 공유는 여전히 암호화된 봉투(envelope) 안에 있지만, 암호화된 공유에 대한 참조는 관련된 DID 식별자(2202)를 통해 블록체인을 통해 지금 이용 가능하다. 따라서, DID 식별자(2202)는 검증자(verifier)와 관련하여 동일한 BOPS 서버(102)(도 23에 도시된 바와 같이) 또는 다른 BOPS 서버를 이용하는 인증(authentication) 주장의 일부로서 사용될 수 있다. 여기서, 이러한 검증(verification)은 DID 식별자(2202)의 트랜잭션 레코드가 블록체인(2212)에서 엑세스될 때 저장된 DID 문서(2204)의 임의의 변경이 명백하게 될 것이기 때문에 가능하다.
도 26, 27A 및 27B로 돌아가면, 소지자가 DID 문서(2204) 및 DID 식별자(2202)를 그들의 개인 신원과 관련시키고 사용자에게 DID 식별자(2202)를 제공하면, 이러한 정보는 검증자 서버(2600B)에 의해 제어되는 보호된 리소스에 대한 액세스를 얻는 데 사용될 수 있다.
특정 구현에서, BOPS 서버(102)는 사용자의 데이터 저장소(2208)와 검증 서버(2600B) 사이의 인터페이스를 제공한다. 그러나, 추가 구성에서, 동일하거나 유사한 기능을 가지는 다른 BOPS 서버가 제공되어, 도 23 및 도 24에 따른 발행 서버(2600A)에 의해 실행되는 등록 기능이 검증 서버(2600B)에 의해 실행되는 기능보다 다른 서버에 의해 실행되도록 한다.
도 26에 도시된 비제한적인 예에서, 사용자(2200)는 모바일 클라이언트 애플리케이션(MCA)(2300)을 사용하여 웹 사이트(예를 들어, 서비스 제공자) 상의 리소스(예를 들어, 콘텐츠 또는 데이터)에 대한 액세스를 추구한다. 이 구성에서 사용자(2200)는 이미 도 24 내지 25에서 제공된 BOPS 중개 등록 플랫폼을 사용하여 설정되고 등록되었다. 여기서, 사용자의 특정 DID 식별자(2202)는 소지자/발행자(도 23 내지 25에서와 같이)에 의해 블록체인에서 생성 및 지속되며 등록에서 생성된 공개 키는(단계 2109에서와 같이) DID 문서(2204)에 저장된다.
사용자 요청의 일부로서, 사용자는 DID 식별자(2202)와 2109단계에서 생성된 공개 키를 서비스 제공자(검증자)에게 보낸다. 추가적인 구현에서, 사용자 요청은 또한 발행자 서명을 포함한다. 서비스 제공자(검증자)(2600)는 블록체인을 통해 DID 식별자(2202)를 결정하고 상응하는 DID 문서(2204)를 가지고 오라는(fetch) 요청과 함께 이 데이터를 BOPS 서버(102)에 전달한다. 예를 들어, BOPS 서버(102)는 DID 식별자(2202), 발행 데이터 및 공개 키를 검증 서버(2600B)로부터 수신한다.
URI가 URN 및 URL을 통해 웹 리소스를 고유하게 특징짓는 것과 마찬가지로, DID 식별자(2202)는 하나 이상의 블록체인 생태계를 사용하여 관련 DID 문서(2204)를 특징짓는다. 여기서, BOPS 서버(102)는 소지자(BOPS 서버(102))가 상응하는 DID 문서(2204)를 찾을 수 있도록 하는 주어진 DID 식별자(2202)에 대한 해석기(resolver)로서 작동한다. 예를 들어, BOPS 서버(102)는 하나 이상의 블록체인에서 수신된 DID를 찾아보고 저장된 트랜잭션 정보를 사용하여 단계 2606에서와 같이 "오프체인" 저장소에서 관련된 검증 가능한 자격 증명을 식별하는 DID 결정 모듈(2407)에 의해 구성된다.
언급된 바와 같이, 하나 이상의 구성에서, DID 식별자(2202) 및 그것의 상응하는 DID 문서(2204)는 암호로 서로에게 연관된다. 따라서 DID 문서(2204)에서의 임의의 변경은 DID 식별자(2202)가 더 이상 DID 문서(2204)와 암호로 매치하지 않는 것을 야기할 것이다. 이 관계를 이용하여, BOPS 서버(102)는 DID 식별자(2202)를 사용하여 DID 문서(2204)를 평가(예를 들어, 결정(resolve))하고 주장 확인(validation) 모듈(2409)을 사용한 DID 식별자(2202)의 발행 이후에 DID 문서(2204) 콘텐츠가 변경되지 않았는지 검증(verify)하도록 구성된다. 예를 들어, 새로운 DID 식별자(2202)가 검색된 DID 문서(2204)에 대해 생성된다. 사용자로부터 수신된 DID 식별자(2202)가 새롭게 생성된 DID 식별자와 매치하지 않는 경우, 인증(authentication) 프로세스가 종료된다.
BOPS 서버(102)가 DID 문서(2204)에 액세스하면, DID 문서(2204) 그 자체는 그 안에 포함된 데이터 값이 검증 서버(2600B)에 의해 전송된 주장과 매치하는지를 결정하기 위해 추가로 평가된다. 예를 들어, BOPS 서버(102)는 DID 문서(2204)에 저장된 발행자 서명을 검증 서버(2600)를 거쳐 사용자 장치(2300)로부터 전송된 발행자 서명과 비교하도록 주장 확인 모듈(claim validation module)(2409)에 의해 구성된다. 추가 구성에서, 주장 확인 모듈(2409)은 또한 DID 문서(2204) 내에 포함된 공개 키를 사용자 장치(2300)에 의해 전송된 액세스 요청에서 제공된 공개 키와 비교하도록 BOPS 서버(102)를 구성한다. 데이터가 DID 문서(2204) 데이터에 대해 검증(validate)될 수 없는 경우, 프로세스가 중지되고 허가(authorization )가 부여되지 않는다.
대안적으로, DID 문서(2204)가 유효한 주장인 경우, 예를 들어 DID 식별자(2202)와 DID 문서가 암호로 매치될 수 있고 DID 문서(2204)의 내용이 발행자 및 사용자 장치(2300)에 의해 전송된 암호화 서명과 매치하기 때문에, BOPS는 서버(102)는 사용자가 인증될 수 있는지를 결정하기 위해 검증(verification) 모듈(2411)에 의해 구성된다.
예를 들어, BOPS 서버(102)는 DID 문서에서 제공되는 저장된 암호화된 공유와 비교하기 위해 바이오메트릭 데이터 세트를 사용자 장치(2300)로부터 요청하도록 검증 모듈(2411)에 의해 구성된다. 예를 들어, BOPS 서버는 단계 2610에서와 같이 사용자의 후보 바이오메트릭 벡터(CBV)에 대한 요청을 사용자 장치(2300)로 전송한다. 여기서, CBV는 IBV를 생성(단계 2013에서와 같이)하는데 사용되는 바이오메트릭 식별자와 동일한 유형의 바이오메트릭 벡터이다. 예를 들어, IBV가 얼굴 인식 데이터와 음성 인식 데이터를 포함하는 경우, 사용자로부터 요청된 CBV 또한 얼굴 인식와 음성 인식 데이터 둘 다를 포함할 것이다. CVB 요청 모듈(2704)에 의해 구성된 사용자 장치(2300)는 액세스 요청 사용자(2200)로부터 CBV를 캡처하고 CVB 및 로컬로 저장된 암호화된 공유를 BOPS 서버(102)에 직접 전송한다.
사용자(2200)로부터 로컬로 저장된 암호화된 공유 및 CBV를 수신하면, BOPS 서버(102)는 단계 2114에서와 같이 수신된 암호화 공유 및 DID 문서(2204)에 저장된 암호화된 공유를 복호화하도록 복호화 모듈(2413)에 의해 구성된다. 추가 구현에서, 복호화 공유들은 본래의 IBV를 재생성하기 위해 결합된다. 여기에서, IBV는 CBV와 비교된다. 예를 들어, BOPS 서버(102)는 CBV의 동일한 데이터에 대해 IBV의 픽셀, 벡터 또는 다른 데이터를 비교하도록 비교 모듈(2415)에 의해 구성된다.
단계 2116에 도시된 바와 같이, CBV의 값이 IBV에 매치하는 경우(또는 IBV의 미리 결정된 임계값 내에 있는 경우), 매치는 결정되고, 액세스 검증 통지가 검증 서버(2600B)로 전송된다.
검증 서버(2600B)에 의해 수신되면, 검증 서버(2600B)는 사용자 장치(2300)가 서비스 제공자(서비스 제공자)에 의해 제공되는 리소스에 액세스하는 것을 허용한다. 사용자(2200)가 검증되면, 복호화된 공유, IBV, CBV 및 공개 키는 BOPS 서버(102)의 메모리에서 제거된다.
도 27a 내지 도 27b에서와 같이, 리소스 액세스 시스템의 특정 구성이 설명된다. 여기서, 사용자(2200)는 MCA(2300)를 사용하여 서비스 제공자(2600)로부터의 리소스(예를 들어, 뱅킹 정보, 소셜 미디어 계정 등)에 엑세스한다. 액세스를 요청하기 위해, MCA(사용자(2200)를 대신하여 작동하는)는 사용자의 등록 공개 키, DID 식별자(2202) 및 발행자 서명을 보낸다. 여기서 발행자 서명은, 일 구현에서, 도 24 및 25에서 제공된 등록 프로세스 동안 발행자(2600)로부터 획득된 공개 키이다. 이러한 사용자 자격 증명을 수신하면 서비스 제공자는 사용자(2200)에 대한 소지자로서 기능하는 BOPS 서버(102)와의 세션을 생성한다.
여기서, BOPS 서버(102)는 DID 문서(2204)의 위치를 결정하기 위해 DID 식별자(2202)를 사용한다. 하나의 추가 구현에서, BOPS 서버(102)는 먼저 블록체인 상의 트랜잭션 레코드를 평가함으로써 DID 식별자의 유효성을 검증한다. 도 27A 및 27B에 도시된 바와 같이, DID 문서(2204)의 위치가 결정되면, DID 문서(2204)는 액세스되고 BOPS 서버(102)로 반환된다. 마찬가지로, 신원 허브(2208)에 저장된 검증된 자격 증명(credential)이 액세스되어 BOPS 서버(102)에 반환된다. 하나 이상의 구성에서, 검증된 자격 증명은 사용자 등록 신원의 암호화된 공유(2/2)이다. DID 문서(2204)에 저장된 발행자 서명이 평가되고 검증된다. 또한, 사용자의 공급된 공개 키는 DID 문서 2204에 저장된 공개 키와 비교되고 검증된다.
도 27a 내지 도 27b에서 제공되는 구성을 계속하면, BOPS 서버(102)는 암호화된 IBV 공유 및 서명된 챌린지의 로컬 사본에 대한 요청을 MCA(2300)에 전송한다. 여기에서, 서명된 챌린지는 현재의 바이오메트릭 벡터에 대한 것일 수 있다. 예를 들어, MCA(2300)가 BOPS 서버(102)로부터 요청을 수신하면, MCA는 바이오메트릭 식별자를 획득하고 등록 키 쌍의 개인 키로 바이오메트릭 식별자를 암호화하기 위해 사용자를 유도한다. 암호화된 바이오메트릭 식별자, 암호화된 공유 및 서명된 챌린지
도 27a 내지 도 27b에 추가로 도시된 바와 같이, 서명된 챌린지는 BOPS 서버(102)에 의해 검증되고 MCA로부터 수신된 암호화된 공유는 등록 공개 키를 사용하여 복호화된다. 일단 복호화되면, IBV 공유들이 복호화되고 결합되어 IBV를 재편성(reform)한다. 재편성된 IBV는 현재의 바이오메트릭 식별자와 비교된다. 현재의 사용자와 등록된 사용자가 동일하게 매치하는 경우, 리소스에 대한 엑세스가 사용자에게 제공된다.
도 28로 넘어가면, 하나 이상의 구성에서, 사용자는 원격으로 인증된다. 여기서, 새로운 서비스 제공자(예를 들어, 검증자로 작동하는)는 원격 인증 모듈(2417)로 구성된 하나 이상의 BOPS 서버(102)를 사용하여 비록 이 사용자가 새로운 서비스 제공자에 등록되지 않았을지라도 사용자(2200)를 인증한다. 이 구성에서 BOPS 서버는 소지자로써 작동한다. 도 28의 워크 플로우와 관련하여 도시된 바와 같이, 인증은 오직 사용자(2200)와 검증 서버(2600)만을 이용하여 효과적으로 실행될 수 있다. 이 구성은 기존의 싱글 사인온(Single Sign-On, SSO) 시스템에서 신원 주장을 중개하기 위해 제3자 신원 제공자(identity provider, IdPs)에 의존하는 SAML 또는 OAuth와 같은, 다른 "첫 번째 인스턴스" 인증과 대조되며 다른 "첫 번째 인스턴스" 인증에 대한 개선이다. 여기서, 제공되는 요소의 구성은 블록체인 기술의 사용을 통하여 인증 데이터에 대한 통제를 가지는 사용자가 새로운 서비스 제공자와 나중에 사용하기 위한 하나 이상의 유효한 기관(즉, 발행자)에서 발급된 자격 증명을 얻어내는 것을 지원한다.
하나 이상의 추가 구성에서, 사용자(예를 들어, 사용자(2200))는 사용자가 이전에 등록하지 않은 보호되는 리소스에 대한 액세스를 요청할 때 사용자의 신원을 로컬로 인증할 수 있다. 예를 들어, 소지자는 인증 중에 사용자를 대신하여 암호화된 바이오메트릭 공유와 같은 발행된 주장에 액세스할 수 있지만 바이오메트릭 인증은 로컬에서 수행되는 것을 요구한다. 도시된 바와 같이, BOPS 서버(102)의 로컬 구성 모드는 바이오메트릭 공유들의 결합이 모바일 장치(2300)에서 발생하는 것을 허용한다. 도 28과 관련하여 특히 상세하게 도시된 바와 같이, DID 문서(2204)에 또는 DID 문서(2204)와 함께 저장된 바이오메트릭 공유의 일부는 상응하는 DID 문서(2204)로부터 참조하는 DID 신원확인(identification)(2202)을 결정함으로써 검색된다. 그러나, 도 24의 워크 플로우와 달리, 여기서 액세스된 바이오메트릭 공유는 서비스 제공자 및 상응하는 BOPS 서버(102)에 의해 클라이언트로 전송된다. 하나의 특정 구현에서, 서비스 제공자 및 BOPS 서버를 통해 사용자에게 전송된 바이오메트릭 공유는 서비스 제공자 및 BOPS 서버에 대해 불투명(opaque)하다. 그러나 서버에는, 암호화된 두 번째 공유의 HMAC 때문에, 모바일 장치의 상응하는 공유(DID 문서(2204)로부터 전송된 바이오메트릭 공유의)가 매치에 사용된다는 것을 알기 위한 충분한 정보가 제공된다. 등록된 공유는 장치로 전송되지 않지만 공유들 둘 다는 BOPS 로컬 구성 모드에 따라 로컬로 유지된다는 것이 이해되어야 한다. 모바일 장치는, 그것이 공유를 사용하여 HMAC를 계산하고 서버로 그것을 보내기 때문에, DID에 대해 등록된 공유와 관련된 개인 키를 보유해야 한다. 서버는 HMAC 키를 DID 문서로부터의 불투명한 암호화된 공유와 비교하고 보호된 리소스에 대한 액세스를 제공할 수 있다.
여기에 설명된 시스템, 플랫폼 및 접근 방식의 추가 구현에서, 바이오메트릭 입력 레코드를 복수의 분산 원장에 저장된 바이오메트릭 레코드와 매치시키기 위한 컴퓨터 실행 방법이 제공된다. 여기에서 바이오메트릭 식별자 또는 DID 문서(2204)는 블록체인에 직접 저장된다(DID(2202)를 통한 참조와는 달리). 도 29에 도시된 바와 같은 하나의 특정 구현에서, 초기 바이오메트릭 벡터는 단계 2902에서와 같이 뉴럴 네트워크에 제공된다. 뉴럴 네트워크는 단계 2904에서와 같이 초기 바이오메트릭 벡터를 유클리드 측정 가능한 특징 벡터로 변환하도록 구성된다. 단계 2906으로 이동하여, 유클리드 측정 가능한 특징 벡터는 제1 공개 키/개인 키 쌍의 개인 키를 사용하여 디지털 서명된다. 서명된 유클리드 측정 가능한 특징 벡터는 단계 2908에서와 같이 제1 공개 키/개인 키 쌍의 공개 키를 사용하여 암호화된다.
추가적인 방식에서, 암호화된 유클리드 측정 가능한 특징 벡터는 단계 2910과 관련하여 도시된 바와 같이 BOPS 서버(102)를 거쳐 복수의 원장(예를 들어, 하나 이상의 식별된 블록체인) 사이에 배포된다. 여기서, 유클리드 측정 가능한 특징 벡터는 적어도 제1 공개 키/개인 키 쌍의 공개 키와 함께 블록체인(2212)의 각자의 노드에 저장된다.
각자의 분산 원장(블록체인)의 각각의 노드는 제1 공개 키/개인 키 쌍의 공개 키를 사용하여 유클리드 측정 가능한 특징 벡터를 복호화하고 유클리드 측정 가능한 특징 벡터를 검증(validate)한다. 추가로, 각각의 노드는 유클리드 측정 가능한 특징 벡터를 노드 각자의 원장(2212)에 추가(append)하도록 추가로 구성된다.
설명된 방법은 데이터 통신 네트워크를 통해 모바일 컴퓨팅 장치(2300)로부터 단계 2912에 도시된 바와 같이 암호화된 바이오메트릭 입력 레코드를 나타내는 현재의 바이오메트릭 벡터를 수신하는 단계를 더 포함한다. 수신된 현재의 바이오메트릭 벡터는, 단계 2914에 도시된 바와 같이, 뉴럴 네트워크에 제공되며, 여기서 뉴럴 네트워크는 현재의 바이오메트릭 벡터를 현재의 유클리드 측정 가능한 특징 벡터로 변환한다.
하나의 구성에서, 현재의 유클리드 측정 가능한 특징 벡터는 단계 2916에서와 같이 서명되고 제2 공개 키/개인 키 쌍의 개인 키를 사용하여 단계 2918에서와 같이 암호화된다. 서명된 그리고 암호화된 현재의 유클리드 측정 가능한 특징 벡터는 2920단계에서와 같이 제2 공개 키/개인 키 쌍의 공개 키와 함께 각자의 노드에 저장된 복수의 원장(2212) 사이에 분배된다.
더 자세히 설명하면, 복수의 분산 원장의 각자의 노드의 각각은 단계 2922에서와 같이 제2 공개 키/개인 키 쌍의 공개 키를 사용하여 현재의 유클리드 측정 가능한 특징 벡터를 복호화하고 현재의 유클리드 측정 가능한 특징 벡터를 검증(validate)하도록 구성된다. 또한, 각각의 각자의 노드는 현재의 유클리드 측정 가능한 특징 벡터를 사용하여 원장에 저장된 유클리드 측정 가능한 특징 벡터 중 적어도 일부의 검색을 수행하도록 추가로 구성된다. 예를 들어, 단계 2924에 도시된 바와 같이, 바이오메트릭 입력 레코드는 현재의 유클리드 측정 가능한 특징 벡터와 원장의 일부에서의 각자의 유클리드 측정 가능한 특징 벡터의 각각의 계산 사이에서 계산된 절대 거리의 함수로 적어도 하나의 바이오메트릭 레코드에 매치된다.
여기에서 사용된 "프로세서" 또는 "컴퓨터"는 주어진 명령 세트를 실행하기 위해 소프트웨어 형태의 코드로 구성된 하나 이상의 전자 장치(예를 들어, 반도체 기반 마이크로컨트롤러)를 나타낸다. 예를 들어, 평가 서버(102), 데이터베이스(들)(108) 및 원격 액세스 장치(104)는 상업적으로 이용 가능한 또는 맞춤형 운영 체제, 예를 들어 MICROSOFT WINDOWS, APPLE OSX, UNIX 또는 Linux 기반 운영 체제 구현을 실행하는 하나 이상의 처리 또는 컴퓨팅 요소를 포함한다. 다른 구현에서, 평가 서버(102), 데이터베이스(들)(108) 및 원격 액세스 장치(104) 각각은 맞춤형 또는 비표준 하드웨어, 펌웨어 또는 소프트웨어 구성을 포함한다. 예를 들어, 프로세서 또는 컴퓨터는 마이크로 컴퓨팅 요소 모음, 컴퓨터 온 칩, 필드 프로그래밍 가능 게이트 어레이, 그래픽 처리 장치, 홈 엔터테인먼트 콘솔, 미디어 플레이어, 셋톱 박스, 프로토타이핑 장치 또는 "취미(hobby)" 컴퓨팅 요소 중 하나 이상을 포함할 수 있다. 이와 같은 설명된 컴퓨팅 요소는 마이크로컨트롤러 구조를 형성하기 위해 하나 이상의 메모리 저장 장치(메모리들)에 직접 또는 간접적으로 연결된다. 메모리는 하나 이상의 소프트웨어 모듈에 추가로 프로세서용 운영 체제를 저장하도록 작동하는 영구 또는 비영구 저장 장치이다. 하나 이상의 실시예에 따르면, 메모리는 ROM(Read Only Memory), RAM(Random Access Memory), EEPROM(Electrically Erasable Programmable Read-Only Memory), PCM(Phase Change Memory), SIMM(Single In-line Memory), DIMM(Dual In-line Memory) 또는 기타 메모리 유형과 같은, 하나 이상의 휘발성 및 비휘발성 메모리를 포함한다. 이러한 메모리는 제거 가능한 미디어 카드 또는 모듈을 사용하는 것과 같이 기술분야의 통상의 기술자에게 알려진 바와 같이 고정되거나 제거될 수 있다. 객체 지향 데이터베이스, 하이브리드 관계형 객체 데이터베이스, HADOOP 또는 MONGODB와 같은 키-값 데이터 저장소, 추가로 기술분야의 통상의 기술자에게 잘 알려진 데이터의 구조 및 검색을 위한 다른 시스템. 데이터베이스(108)는 콘텐츠 평가 서버(102)에 로컬인 프로세서가 데이터베이스(108) 내에서 데이터를 검색하고 저장할 수 있게 하는데 필요한 하드웨어 및 소프트웨어를 포함한다.
컴퓨터 메모리는 또한 영구 메모리 장치와 유사한 방식으로 데이터의 장기 저장을 제공하는 자기 또는 광 디스크 드라이브 또는 플래시 메모리와 같은 보조 컴퓨터 메모리를 포함할 수 있다. 하나 이상의 실시예에서, 프로세서의 메모리는 필요할 때 애플리케이션 프로그램 및 데이터 파일의 저장을 제공한다.
설명된 프로세서 또는 컴퓨터는 JavaScript, PHP, Ruby, Scala, Erlang, C, C++, Objective C, Swift, C#, Java, Assembly, Go, Python, Perl, R, Visual Basic, Lisp, TensorFlow for ML, mClust, 또는 Julia 또는 기타 객체 지향, 기능 또는 기타 패러다임 기반 프로그래밍 언어의 표준 집합, 하위 집합, 상위 집합 또는 확장 집합과 같은 표준, 사용자 지정, 독점 또는 수정된 프로그래밍 언어로 작성된 코드를 실행하도록 구성된다.
하나의 특정 구현에서, 프로세서 컴퓨터는 휴대폰, 태블릿 컴퓨터, 워크스테이션, 데스크톱 컴퓨터 또는 기타 컴퓨팅 요소와 같이 직접적으로 또는 통신 연결을 통해 하나 이상의 원격 액세스 장치와 통신하고 데이터를 교환하도록 구성되는 서버, 컴퓨팅 클러스터, 클라우드 플랫폼 또는 컴퓨팅 어레이 중 하나 이상으로서 구현된다.
예시된 구현에서 제공되는 바와 같이, 컴퓨터 및 프로세서는 하나 이상의 원격 데이터 저장 위치(예: 데이터베이스)로부터 쿼리된 전자 데이터를 수락하고 미리 결정된 또는 동적 규칙에 따라 쿼리되거나 액세스된 데이터를 평가하도록 내부에서 실행되는 코드에 의해 구성된다. 데이터베이스(들)의 물리적 구조는 solid-state memory(예를 들어, ROM), 하드 디스크 드라이브 시스템, RAID, 디스크 어레이, SAN(storage area networks), NAS(network attached storage) 및/또는 컴퓨터 데이터를 저장하기 위한 임의의 다른 적절한 시스템으로 구현될 수 있다. 또한, 데이터베이스는 데이터베이스 캐시 및/또는 웹 캐시를 포함하는 캐시를 포함할 수 있다. 프로그래밍 방식으로, 데이터베이스는 당업자에게 잘 알려진 데이터의 구조 및 검색을 위한 다른 시스템에 더하여, 플랫 파일 데이터 저장소, 관계형 데이터베이스, 객체 지향 데이터베이스, 하이브리드 관계형 객체 데이터베이스, HADOOP 또는 MONGODB와 같은 키-값 데이터 저장소를 포함할 수 있다. 데이터베이스는 이러한 서버에 로컬인 프로세서가 데이터베이스 또는 데이터베이스 내에서 데이터를 검색하고 저장할 수 있도록 하는 데 필요한 하드웨어 및 소프트웨어를 포함한다.
여기서 사용되는 바와 같이, 원격 액세스 장치는 전자 메시지, 데이터 패키지, 스트림 또는 파일과 같은 데이터를 네트워크를 통해 하나 이상의 로컬 또는 원격 컴퓨터 또는 프로세서(예를 들어 서버)로 교환하는 데 사용된다. 일 구현에서, 원격 액세스 장치(들)는 내부 로컬 네트워크를 통해 서버에 직접 연결된다. 또는 원격 액세스 장치는 먼저 인터넷에 연결하여 서버에 연결하는 적절한 소프트웨어 및 하드웨어로 구성된다. 본 명세서에 사용된 바와 같이, 원격 액세스 장치는 네트워크에 연결하고 데이터를 수신하도록 하드웨어 또는 소프트웨어 모듈에 의해 구성된 범용 또는 단일 목적 컴퓨팅 장치이다. 예를 들어, 원격 액세스 장치는 콘텐츠 하나 이상의 컴퓨터 또는 프로세서와 데이터를 교환하도록 하나 이상의 코드 모듈에 의해 구성된 개인용 통신 장치(스마트폰, 태블릿 컴퓨터 등)일 수 있다. 원격 액세스 장치는 CDMA, GSM, 이더넷, Wi-Fi, 블루투스, USB, 직렬 통신 프로토콜 및 하드웨어와 같은, 그러나 제한되지 않는 유선 또는 무선 통신 수단을 활용하여 구성되어 하나 이상의 액세스 포인트, 교환기, 네트워크 노드 또는 네트워크 라우터에 연결한다. 특정 구성에서 원격 액세스 장치는 또한, 하드웨어 및 소프트웨어 모듈을 통해, 로컬 또는 원격 네트워크를 통해 또는 인터넷을 통해 표준 또는 맞춤형 통신 프로토콜 및 설정(예를 들어, TCP/IP 등)을 사용하여 더 많은 원격 서버, 컴퓨터, 주변 장치 또는 기타 하드웨어에 연결하도록 구성된다.
일 구현에서, 원격 액세스 장치, 프로세서 및 컴퓨터는 상업적으로 이용 가능한 또는 맞춤형 운영 체제, 예를 들어 MICROSOFT WINDOWS, APPLE OSX, UNIX 또는 Linux 기반 운영 체제 구현을 실행한다. 다른 구현에서, 원격 액세스 장치, 프로세서 및 컴퓨터는 맞춤형 또는 비표준 하드웨어, 펌웨어 또는 소프트웨어 구성이다. 원격 액세스 장치, 프로세서 및 컴퓨터는 USB, 디지털 입/출력 핀, eSATA, 병렬 포트, 직렬 포트, 방화벽, Wi-Fi, Bluetooth 또는 다른 통신 인터페이스를 사용하여 하나 이상의 원격 네트워크와 통신할 수 있다.
이 명세서는 많은 특정 구현 및 세부 사항을 포함하지만, 이는 구성, 배열, 구현 또는 실시예의 범위 또는 청구될 수 있는 것의 범위에 대한 제한으로 해석되어서는 안 되며, 오히려 특정 구현 또는 하나 이상의 특정 실시예에 특정할 수 있는 기능의 설명일 수 있다. 별도의 구현과 관련하여 본 명세서에 설명된 특정 기능은 또한 단일 구성 또는 배열로 조합하여 구현될 수도 있다. 반대로, 단일 구현의 맥락에서 설명된 다양한 특징은 또한 다중 구성 또는 별도의 배열로 또는 임의의 적절한 하위 조합으로 구현될 수 있다. 더욱이, 특징이 특정 조합으로 작동하는 것으로 위에서 설명될 수 있고 심지어 초기에 그렇게 청구될 수도 있지만, 청구된 조합의 하나 이상의 특징이 어떤 경우에는 조합에서 제거될 수 있고 청구된 조합은 하위 조합 또는 하위 조합의 변형으로 지시될 수 있다.
유사하게, 동작이 특정 순서로 도면에 도시되어 있지만, 이는 바람직한 결과를 달성하기 위해 그러한 작업이 도시된 특정 순서로 또는 순차적인 순서로 수행되거나 도시된 모든 작업이 수행될 것을 요구하는 것으로 이해되어서는 안 된다. 특정 상황에서는 멀티태스킹과 병렬 처리가 유리할 수 있다. 더욱이, 위에서 설명된 실시예에서 다양한 시스템 구성요소의 분리는 모든 실시예에서 그러한 분리를 요구하는 것으로 이해되어서는 안 되며, 설명된 프로그램 구성요소 및 시스템은 일반적으로 단일 소프트웨어 제품에 함께 통합되거나 여러 소프트웨어 제품으로 패키지될 수 있음을 이해해야 한다.
여기서 사용된 용어는 특정 실시예들을 설명하기 위한 것이며, 본 발명을 제한하고자 하는 것은 아니다. 여기서 사용된 단수 형태 "a", "an" 및 "the"는 문맥 상 다르게 지시하지 않는 한 복수 형태를 포함하도록 의도된다. 본 출원에서 사용되는 "포함한다" 및/또는 "포함하는"이라는 용어는 명시된 특징, 정수, 단계, 동작, 엘리먼트 및/또는 컴포넌트들의 존재를 나타내지 만, 하나 이상의 다른 특징, 정수, 단계, 동작, 엘리먼트, 컴포넌트들 및/또는 이들의 그룹들의 존재 또는 추가를 배제하지 않는다는 것이 추가로 이해될 것이다.
특허 청구 범위를 변경하기 위해 특허 청구 범위에서 "제 1", "제 2", "제 3 등"과 같은 서수 용어를 사용하는 것은 그 자체로 방법의 동작이 수행되는 임의의 우선 순위, 선행 또는 하나의 청구항 엘리먼트의 다른 것에 대한 순서 또는 시간적 순서를 의미하는 것이 아니라 청구항 엘리먼트를 구별하기 위해 특정 이름을 가진 하나의 청구항 엘리먼트를 동일한 이름을 가진 (그러나 서수 용어를 사용하는) 다른 엘리먼트와 구별하기 위한 단지 라벨로서 사용된다는 것에 유의하여야 한다. 또한, 본원에서 사용되는 표현 및 용어는 설명을 위한 것이며 제한으로 간주되어서는 안 된다. 본 출원에서”포함하는", "포함하는" 또는 "갖는", "함유하는", "수반하는” 및 그 변형은 그 이후에 열거 된 항목 및 그 등가물뿐만 아니라 추가 항목을 포함한다.
본 명세서에서 설명된 주제의 특정 실시예가 설명되었다. 다른 실시예는 다음 청구항의 범위 내에 있다. 예를 들어, 청구항들에 언급된 동작은 다른 순서로 수행될 수 있으며 여전히 바람직한 결과를 얻을 수 있다. 일례로서, 첨부 도면에 도시된 프로세스는 바람직한 결과를 달성하기 위해 도시된 특정 순서 또는 순차적인 순서를 반드시 필요로 하지는 않는다. 특정 실시예에서, 멀티태스킹 및 병렬 처리가 유리할 수 있다.
다양한 시스템을 나타내는 알려진 등록 상표에 대한 간행물 및 참조는 본 출원 전체에 걸쳐 인용되며, 그 개시 내용은 참조에 의해 여기에 통합된다. 위의 출판물이나 문서의 인용은 전술한 것이 관련 선행 기술임을 인정하기 위한 것이 아니며 이러한 출판물이나 문서의 내용이나 날짜에 대한 어떤 승인을 구성하지도 않는다. 발행 및 계류 중인 특허 및 특허 출원을 포함하여 여기에 인용된 모든 참조는 각 개별 간행물 및 참고 문헌이 참조로 포함되도록 구체적이고 개별적으로 표시된 것과 동일한 정도로 참조로 포함된다.
본 발명이 그의 바람직한 실시예를 참조하여 구체적으로 도시되고 설명되었지만, 본 발명의 사상 및 범위를 벗어나지 않으면서 형태 및 세부사항의 다양한 변경이 이루어질 수 있다는 것이 당업자에 의해 이해될 것이다. 이와 같이, 본 발명은 위에 나타난 논의에 의해 정의되지 않고, 오히려 다음의 요점, 그 요점에서 인용된 각각의 특징, 및 그러한 특징의 등가물에 의해 정의된다.

Claims (20)

  1. 인증 시스템에 신원을 등록하는 컴퓨터 실행 방법에 있어서,
    데이터 통신 네트워크를 통해 모바일 컴퓨팅 장치로부터, 초기 바이오메트릭 벡터(IBV)의 적어도 하나의 암호화된 암호화 공유 및 시드를 이용하여 수학적으로 생성된 제1 공개 키/개인 키 쌍의 공개 키를 수신하는 단계 - 상기 적어도 하나의 암호화된 암호화 공유는 상기 제1 공개 키/개인 키 쌍의 개인 키를 이용하여 암호화 됨;
    적어도 인가 시스템 서명, 상기 제1 공개 키/개인 키 쌍의 공개 키 및 적어도 하나의 암호화된 암호화 공유를 포함하는 제1 신원 데이터 세트를 생성하는 단계;
    적어도 하나의 원격 저장 위치에 상기 제1 신원 데이터 세트를 저장하는 단계;
    제1 신원 데이터 세트와 관련된 신원 기준 값을 생성하는 단계 - 여기서 상기 신원 기준 값은 상기 제1 신원 데이터 세트의 저장 위치를 결정하고 상기 생성된 제1 신원 데이터 세트와 암호로 관련됨;
    각자의 노드에 저장된 복수의 원장들 각각에, 적어도 상기 신원 기준 값을 포함하는 트랜잭션 레코드를 배포하는 단계;
    적어도 상기 신원 기준 값을, 상기 모바일 컴퓨팅 장치에 제공하는 단계;를 포함하는 방법.
  2. 제1항에 있어서, 상기 수신된 IBV의 암호화된 공유는, 상기 초기 바이오메트릭 벡터를 뉴럴 네트워크에 제공하고 - 상기 뉴럴 네트워크는 상기 초기 바이오메트릭 벡터를 유클리드 측정 가능한 특징 벡터로 변환함, 상기 제1 공개 키/개인 키 쌍의 개인 키를 이용하여 상기 유클리드 측정 가능한 특징 벡터를 암호화 함으로써 생성되는 방법.
  3. 제1항에 있어서, 상기 IBV는 샤미르 비밀 공유 스키마 알고리즘을 이용하여 시각적으로 암호화되는 방법.
  4. 리소스 제공자에 대한 액세스를 사용자에게 제공하기 위한 시스템에 있어서,
    메모리를 가지고 하나 이상의 모듈로 구성되는 프로세서;를 포함하고,
    상기 하나 이상의 모듈은,
    데이터 통신 네트워크를 통해 모바일 컴퓨팅 장치로부터, 적어도,
    제1 신원 데이터 세트와 연관된 신원 기준 값 - 여기서 상기 신원 기준 값은 상기 제1 신원 데이터 세트의 저장 위치를 결정하고 상기 제1 신원 데이터 세트와 암호로 관련되며, 상기 제1 신원 데이터 세트는 적어도 인가 시스템 특정 데이터 값, 시드를 이용하여 수학적으로 생성된 등록 공개 키/개인 키 쌍의 공개 키 및 액세스를 요청하는 사용자의 초기 바이오메트릭 벡터의 적어도 하나의 원격 암호화된 암호화 공유를 포함함;
    인가 시스템 서명 값;
    상기 등록 공개/개인 키 쌍의 공개 키;를 수신하고,
    각자의 노드에 저장된 복수의 원장에서 적어도 상기 신원 기준 값을 포함하는 트랜잭션 레코드를 찾아내고,
    상기 찾아낸 트랜잭션 레코드로부터, 상응하는 제1 신원 데이터 세트의 저장 위치를 결정하고;
    상기 암호로 관련된 제1 신원 데이터 세트에 액세스하고;
    상기 인가 시스템 서명 값 및 상기 제1 신원 데이터 세트의 등록 공개 키를 검증하고;
    모바일 컴퓨팅 장치로부터, 현재의 바이오메트릭 벡터 및 로컬 암호화된 바이오메트릭 암호화 공유를 수신하고;
    상기 등록 공개 키/개인 키 쌍의 공개 키를 이용하여 상기 수신된 로컬 암호화된 암호화 공유 및 원격 암호화된 암호화 공유를 복호화하고;
    상기 복호화된 로컬 암호화 공유와 상기 복호화되어 저장된 암호화 공유를 결합하여 결합된 암호화 벡터를 형성하고;
    상기 결합된 암호화 벡터를 상기 현재의 바이오메트릭 벡터와 비교하고;
    여기서 상기 결합된 암호화 벡터는 상기 현재의 바이오메트릭 벡터에 매치하여 상기 리소스 제공자가 상기 사용자에게 상기 리소스에 대한 엑세스를 제공하도록 하는 시스템.
  5. 제4항에 있어서, 상기 결합된 암호화 벡터를 상기 현재의 바이오메트릭 벡터와 비교하는 것은,
    결합된 암호화 벡터 및 상기 현재의 바이오메트릭 벡터를 뉴럴 네트워크에 제공하는 것을 포함하고, 상기 뉴럴 네트워크는 상기 결합된 암호화 벡터 및 상기 현재의 바이오메트릭 벡터를 각자의 유클리드 측정 가능한 특징 벡터로 변환하는 시스템.
  6. 제5항에 있어서, 상기 결합된 암호화 벡터는 상기 결합된 암호화 벡터의 각자의 유클리드 측정 가능한 특징 벡터와 상기 현재의 바이오메트릭 벡터의 각자의 유클리드 측정 가능한 특징 벡터의 각각의 연산 사이에서 계산된 절대 거리의 함수로 상기 현재의 바이오메트릭 벡터와 매칭되는 시스템.
  7. 제5항에 있어서, 상기 프로세서는,
    상기 유클리드 측정 가능한 특징 벡터를 분류하고; 및/또는
    상기 현재의 유클리드 측정 가능한 특징 벡터를 분류하도록 더 구성되고,
    상기 분류는 하나 이상의 거리 함수를 이용하여 적어도 부분적으로 수행되는 시스템.
  8. 제7항에 있어서, 상기 유클리드 측정 가능한 특징 및/또는 상기 현재의 유클리드 측정 가능한 특징 벡터를 분류하는 것은 부동 소수점 값들을 반환하고, 프로베니우스 알고리즘이 각각의 부동 소수점과 그것의 평균 사이의 절대 거리를 계산하는 데 활용되는 시스템.
  9. 제7항에 있어서, 검색은 오더 로그(n) 시간에 수행되는 시스템.
  10. 제7항에 있어서, 상기 프로세서는,
    프로베니우스 알고리즘을 이용하여 상기 유클리드 측정 가능한 바이오메트릭 벡터를 분류하고,
    상기 분류된 유클리드 측정 가능한 바이오메트릭 벡터의 계층을 오더 로그(n) 시간으로 트래버스하고,
    각자의 유클리드 측정 가능한 바이오메트릭 벡터가 현재의 유클리드 측정 가능한 특징 벡터임을 식별하도록 더 구성되는 시스템.
  11. 제5항에 있어서, 상기 프로세서는,
    각각의 각자의 유클리드 측정 가능한 바이오메트릭 벡터에 대하여, 복수의 부동 소수점 값을 식별하고,
    비트맵을 이용하여 모든 벡터에 존재하지 않는 복수의 값 중 어느 것을 절대 거리 계산으로부터 제거하도록 더 구성되는 시스템.
  12. 제5항에 있어서, 상기 프로세서는,
    각각의 각자의 유클리드 측정 가능한 바이오메트릭 벡터에 대하여, 복수의 부동 소수점 값을 식별하고,
    상기 부동 소수점 값의 각자가 나타나는 벡터의 수에 기초하여 중요성의 슬라이딩 스케일을 정의하도록 더 구성되는 시스템.
  13. 제5항에 있어서, 상기 뉴럴 네트워크는 정류기(ReLU) 및 풀링 노드와 함께, 다양한 컨볼루션 계층으로 구성되는 시스템.
  14. 제5항에 있어서, 상기 뉴럴 네트워크는 풀링을 비선형 다운샘플링의 형태로 사용하도록 구성되고,
    추가로, 하나 이상의 풀링 노드는 나타난 유클리드 측정 가능한 특징 벡터의 공간 크기를 점진적으로 감소시켜 상기 뉴럴 네트워크에서 파라미터 및 계산의 양을 감소시키는 시스템.
  15. 제14항에 있어서, 상기 프로세서는,
    복수의 저장된 유클리드 측정 가능한 특징 벡터의 각각에 대하여, 평균 얼굴 벡터와 상기 각자의 유클리드 측정 가능한 특징 벡터 사이의 상대 위치 차이를 계산하고,
    상기 상대 위치 차이를 제곱하고,
    상기 값을 합산하고,
    상기 제곱근을 산출하도록 더 구성되는 시스템.
  16. 제5항에 있어서, 상기 뉴럴 네트워크의 성능은, 출력 볼륨의 공간의 크기로 주어지는 다수의 계층이 입력 볼륨 크기 W, 계층 뉴런의 커널 필드 크기 K, 계층과 함께 적용된 스트라이드(stride) S, 및 경계에 사용된 제로 패딩(zero padding )의 양 P의 함수로 계산되는, 비용 함수의 함수로 결정되는 시스템.
  17. 제5항에 있어서, 상기 뉴럴 네트워크는 상기 초기 바이오메트릭 벡터, 상기 현재의 바이오메트릭 벡터를 각각의 각자의 계층에 대한 행렬 곱의 함수로 변환하고, 유클리드 비용 함수에 기반한 유클리드 거리 알고리즘을 이용하는 시스템.
  18. 바이오메트릭 입력 레코드를 복수의 분산 원장에 저장된 바이오메트릭 레코드와 매칭시키기 위한 컴퓨터 실행 방법에 있어서,
    초기 바이오메트릭 벡터를 뉴럴 네트워크에 제공하는 단계 - 상기 뉴럴 네트워크는 상기 초기 바이오메트릭 벡터를 유클리드 측정 가능한 특징 벡터로 변환함;
    제1 공개 키/개인 키 쌍의 개인 키를 이용하여 상기 유클리드 측정 가능한 특징 벡터에 디지털 서명하는 단계;
    상기 제1 공개 키/개인 키 쌍의 공개 키를 이용하여 상기 유클리드 측정 가능한 특징 벡터를 암호화하는 단계;
    각자의 노드에 저장된 복수의 원장에, 적어도 상기 암호화된 유클리드 측정 가능한 특징 벡터 및 상기 제1 공개 키/개인 키 쌍의 공개 키를 배포하는 단계 - 여기서 각각의 각자의 노드는, 상기 제1 공개 키/개인 키 쌍의 공개 키를 이용하여 상기 유클리드 측정 가능한 특징 벡터를 복호화하고, 상기 유클리드 측정 가능한 특징 벡터를 검증하고, 상기 유클리드 측정 가능한 특징 벡터를 노드 각자의 원장에 추가함;
    데이터 통신 네트워크를 통해 모바일 컴퓨팅 장치로부터, 암호화된 바이오메트릭 입력 레코드를 나타내는 현재의 바이오메트릭 벡터를 수신하는 단계;
    상기 현재의 바이오메트릭 벡터를 뉴럴 네트워크에 제공하는 단계 - 상기 뉴럴 네트워크는 상기 현재의 바이오메트릭 벡터를 현재의 유클리드 측정 가능한 특징 벡터로 변환함;
    제2 공개 키/개인 키 쌍의 개인 키를 이용하여 상기 현재의 유클리드 측정 가능한 특징 벡터에 디지털 서명하는 단계;
    상기 제2 공개 키/개인 키 쌍의 공개 키를 이용하여 상기 현재의 유클리드 측정 가능한 특징 벡터를 암호화하는 단계;
    각자의 노드에 저장된 복수의 원장에, 적어도 상기 현재의 유클리드 측정 가능한 특징 벡터 및 상기 제2 공개 키/개인 키 쌍의 공개 키를 배포하는 단계 - 여기서 각각의 각자의 노드는, 상기 제2 공개 키/개인 키 쌍의 공개 키를 이용하여 상기 현재의 유클리드 측정 가능한 특징 벡터를 복호화하고, 상기 현재의 유클리드 측정 가능한 특징 벡터를 검증하고, 상기 현재의 유클리드 측정 가능한 특징 벡터를 이용하여 원장에 저장된 유클리드 측정 가능한 특징 벡터의 적어도 일부의 검색을 수행함;를 포함하고,
    여기서 상기 바이오메트릭 입력 레코드는 상기 현재의 유클리드 측정 가능한 특징 벡터와 원장의 일부에서 각자의 유클리드 측정 가능한 특징 벡터의 각각의 연산 사이에서 계산된 절대 거리의 함수로 적어도 하나의 바이오메트릭 레코드와 매칭되는 방법.
  19. 제18항에 있어서, 상기 유클리드 측정 가능한 특징 벡터는 상기 제1 공개 키/개인 키 쌍의 개인 키를 이용하여 상기 유클리드 측정 가능한 특징 벡터를 복호화하고, 각각의 노드에서의 유클리드 측정 가능한 특징 벡터와 상기 복호화된 유클리드 측정 가능한 특징 벡터를 비교하여 발생하는 유클리드 측정 가능한 특징 벡터의 변화 없음을 검증하는 함수로 검증되는 방법.
  20. 제18항에 있어서, 상기 유클리드 측정 가능한 특징 벡터에 서명하는 단계는,
    상기 유클리드 측정 가능한 특징 벡터와 관련된 해시 값을 생성하는 단계; 및
    상기 제1 공개 키/개인 키 쌍의 개인 키를 이용하여 상기 해시 값을 암호화하는 단계;를 포함하고,
    상기 해시 값은 상기 제1 공개 키/개인 키 쌍의 공개 키를 이용하여 각각의 각자의 노드에 의해 복호화되고, 상기 제1 공개 키/개인 키 쌍의 개인 키를 이용하여 복호화되는 해시 값과 비교되는 방법.
KR1020227005661A 2019-07-23 2020-07-22 바이오메트릭 프로토콜 표준을 위한 시스템 및 방법 KR20220038115A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/520,191 2019-07-23
US16/520,191 US11329980B2 (en) 2015-08-21 2019-07-23 System and method for biometric protocol standards
PCT/US2020/043001 WO2021016311A1 (en) 2019-07-23 2020-07-22 System and method for biometric protocol standards

Publications (1)

Publication Number Publication Date
KR20220038115A true KR20220038115A (ko) 2022-03-25

Family

ID=74194266

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227005661A KR20220038115A (ko) 2019-07-23 2020-07-22 바이오메트릭 프로토콜 표준을 위한 시스템 및 방법

Country Status (9)

Country Link
EP (1) EP4004674A4 (ko)
JP (1) JP2022541919A (ko)
KR (1) KR20220038115A (ko)
CN (1) CN114175079A (ko)
AU (1) AU2020316421A1 (ko)
BR (1) BR112022000940A2 (ko)
CA (1) CA3146366A1 (ko)
MX (1) MX2022000866A (ko)
WO (1) WO2021016311A1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11790334B1 (en) * 2022-06-03 2023-10-17 Block, Inc. Blockchain supported resource transfer communication protocol
CN117237115B (zh) * 2023-11-15 2024-02-23 四川绿豆芽信息技术有限公司 一种碳排放交易的加密方法及系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8165303B1 (en) * 2007-05-03 2012-04-24 Adobe Systems Incorporated Method and apparatus for public key cryptography
US9485096B2 (en) * 2013-02-06 2016-11-01 Apurva Shrivastava Encryption / decryption of data with non-persistent, non-shared passkey
US9838388B2 (en) * 2014-08-26 2017-12-05 Veridium Ip Limited System and method for biometric protocol standards
WO2017035085A1 (en) * 2015-08-21 2017-03-02 Veridium Ip Limited System and method for biometric protocol standards
US10255040B2 (en) * 2017-05-11 2019-04-09 Veridium Ip Limited System and method for biometric identification
US9985964B2 (en) * 2016-03-28 2018-05-29 Black Gold Coin, Inc. Systems and methods for providing block chain-based multifactor personal identity verification
US10296764B1 (en) * 2016-11-18 2019-05-21 Amazon Technologies, Inc. Verifiable cryptographically secured ledgers for human resource systems
US10592685B2 (en) * 2017-04-27 2020-03-17 Google Llc Encrypted search cloud service with cryptographic sharing

Also Published As

Publication number Publication date
CA3146366A1 (en) 2021-01-28
EP4004674A1 (en) 2022-06-01
BR112022000940A2 (pt) 2022-03-08
WO2021016311A1 (en) 2021-01-28
JP2022541919A (ja) 2022-09-28
AU2020316421A1 (en) 2022-02-24
EP4004674A4 (en) 2024-01-24
MX2022000866A (es) 2022-02-10
CN114175079A (zh) 2022-03-11

Similar Documents

Publication Publication Date Title
US11329980B2 (en) System and method for biometric protocol standards
US10536454B2 (en) System and method for biometric protocol standards
US11496310B2 (en) Methods and systems for universal storage and access to user-owned credentials for trans-institutional digital authentication
US11244316B2 (en) Biometric token for blockchain
Bhatia et al. Data security in mobile cloud computing paradigm: a survey, taxonomy and open research issues
KR102549337B1 (ko) 생체인식 프로토콜 표준을 위한 시스템 및 방법
US20210385219A1 (en) Method and system for data security within independent computer systems and digital networks
BR112016015458B1 (pt) Sistema e método para padrões de protocolo biométrico
US20220405765A1 (en) Know your customer (kyc) and anti-money laundering (aml) verification in a multi-decentralized private blockchains network
KR20220038115A (ko) 바이오메트릭 프로토콜 표준을 위한 시스템 및 방법
Othman et al. A protocol for decentralized biometric-based self-sovereign identity ecosystem
Othman et al. The Horcrux Protocol: A Distributed Mobile Biometric Self-sovereign Identity Protocol
US20240121098A1 (en) Scalable Authentication System with Synthesized Signed Challenge
Singh A secure and reliable authentication mechanism for users of microsoft cardspace framework
Dietz Improving user authentication on the web: Protected login, strong sessions, and identity federation
Albahdal Toward secure, trusted, and privacy-enhanced biometrics in the cloud
Binu Secure authentication framework for cloud
Agha et al. SSO BASED FINGERPRINT AUTHENTICATION OF CLOUD SERVICES FOR ORGANIZATIONS

Legal Events

Date Code Title Description
A201 Request for examination