KR20180080183A

KR20180080183A - 생체인식 프로토콜 표준을 위한 시스템 및 방법

Info

Publication number: KR20180080183A
Application number: KR1020187008119A
Authority: KR
Inventors: 스코트 스트레이트; 조나단 프란시스 매덜; 애섬 오스만; 아이오넛 듀미트란; 토마스 우드
Original assignee: 베리디움 아이피 리미티드
Priority date: 2015-08-21
Filing date: 2016-08-22
Publication date: 2018-07-11
Also published as: JP2018529299A; ES2881824T3; EP3338157A1; HK1255649A1; WO2017035085A1; EP3338157A4; WO2017035085A9; CA2996296C; EP3338157B1; CN108475309A; CN108475309B; AU2016311166B2; KR102549337B1; JP6906521B2; BR112018003390A2; PL3338157T3; CA2996296A1; AU2016311166A1; MX2018002190A

Abstract

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

Description

생체인식 프로토콜 표준을 위한 시스템 및 방법

본 발명은 일반적으로 보안에 관한 것으로, 보다 상세하게는 사용자를 식별 또는 인증하기 위한 시스템 및 방법에 관한 것이다.

모든 종류의 정보는 데이터 통신 네트워크를 통해 액세스할 수 있는 저장 장치와 같이 원격으로 계속 저장되고 액세스된다. 예를 들어, 많은 사람들과 회사는 금융 정보, 건강 및 의료 정보, 상품 및 서비스 정보, 구매 정보, 엔터테인먼트 정보, 인터넷 또는 기타 통신 네트워크를 통한 멀티미디어 정보를 저장하고 액세스한다. 정보에 접근하기 위하여, 사용자는 통화 이전(예를 들어, 구매, 이전, 판매 등)에 영향을 줄 수 있다. 일반적인 시나리오에서, 사용자는 정보에 대한 액세스(access)에 등록하고 그에 따라 사용자 이름과 암호를 제출하여 "로그인(log-in)"하고 정보에 액세스한다. 데이터/통신 네트워크에 저장된 이러한 정보 및 데이터에 대한 보안 액세스를 유지하는 것이 가장 중요한 관심사이다.

본 발명의 하나 이상의 구현예에서, 보안 통신은 사용자 컴퓨팅 장치와 서버 컴퓨팅 장치 사이에 제공된다. 등록 요청은 분산된 클라이언트 소프트웨어 애플리케이션을 처리하는 것으로 구성된 사용자 컴퓨팅 장치로부터 수신된다. 상기 등록 요청은 사용자 컴퓨팅 장치를 네트워크에 등록하는데 사용 가능하며, 사용자와 연관된 암호화된 부분적 초기 생체인식 벡터(partial initial biometric vector)를 포함한다. 암호화된 부분적 2차 생체인식 벡터를 포함하고 사용자 컴퓨팅 장치의 사용자와 연관되는 후속적으로 수신되는 인증 요청이 처리된다. 상기 암호화된 부분적 초기 생체인식 벡터와 상기 암호화된 부분적 2차 생체인식 벡터의 비교가 수행되며, 비교를 나타내는 값이 생성되고 사용자 컴퓨팅 장치로 전송된다. 상기 사용자 컴퓨팅 장치는 상기 값이 최소 임계값(minimum threshold)을 넘을 때 인증된다.

하나 이상의 구현예에서, 보안 통신은 사용자 컴퓨팅 장치와 서버 컴퓨팅 장치 사이에 제공된다. 분산된 클라이언트 소프트웨어 애플리케이션으로 구성된 사용자 컴퓨팅 장치로부터 수신된 등록 요청을 처리한다. 상기 등록 요청은 사용자 컴퓨팅 장치를 네트워크에 등록 시키는데 이용 가능하며, 사용자와 연관된 1차 생체인식 벡터의 제1부분을 포함한다. 1차 생체인식 벡터의 제1부분이 저장되고, 2차 생체인식 벡터 및 1차 생체인식 벡터의 제2부분을 포함하며 후속적으로 수신되는 인증 요청을 처리한다. 상기 제1부분 및 제2부분은 결합되고 2차 생체인식 벡터와 비교된다. 상기 비교를 나타내는 값이 생성되어 사용자 컴퓨팅 장치로 전송된다. 상기 사용자 컴퓨팅 장치는 상기 값이 최소 임계값을 넘을 때 인증된다.

하나 이상의 구현예에서, 상기 등록 요청 및 상기 인증 요청에 포함되는 인증서를 제공하며, 상기 인증 요청을 처리하는 단계는 인증서가 통용중이고 폐지되지 않았음을 결정하는 것을 포함한다.

하나 이상의 구현예에서, 능동적 모니터링을 제공하고 상기 인증서 리플레이(replay)를 포함하는, 인증서의 스푸핑을 방지하는 침입 탐지 시스템(intrusion detection system)을 제공한다.

하나 이상의 구현예에서, 상기 인증 요청을 처리하는 것은 단방향 암호(one-way encryption)의 기능으로서 암호화된 공간에서 적어도 하나의 매칭 작업을 수행하는 것을 포함한다. 상기 단방향 암호는 임의의 일회용 암호표(one-way pad)를 사용하여 수행할 수 있다.

하나 이상의 구현예에서, 디지털 자산(digital asset)에 액세스(access)하기 위한 하나 이상의 규칙에 의해 정의된 롤 개더링(role gathering)을 제공하며, 상기 서버 컴퓨팅 장치는 롤 개더링의 기능으로서 상기 사용자 컴퓨팅 장치에 의한, 디지털 자산에 대한 액세스를 제공하거나 거부한다. 액세스는 임의(discretionary) 액세스 제어 및 필수(mandatory) 액세스 제어 중 적어도 하나의 기능으로서 제공될 수 있다.

하나 이상의 구현예에서, 상기 서버 컴퓨팅 장치는 분산된 클라이언트 소프트웨어 애플리케이션으로 구성된 사용자 컴퓨팅 장치로부터 수신된 2차 등록 요청을 처리한다. 상기 2차 등록 요청은 네트워크에 상기 사용자 컴퓨팅 장치의 2차 사용자를 등록하는데 사용될 수 있고, 2차 등록 요청은 사용자 컴퓨팅 장치의 사용자와 관련된 2차 암호화된 부분적 초기 생체인식 벡터(initial biometric vector, IBV)를 포함한다. 상기 2차 등록 요청을 처리하는 것은 서버 컴퓨팅 장치에 의해 액세스 가능하거나 서버 컴퓨팅 장치의 일부인 비-일시적인 프로세서(on non-transitory processor) 판독 가능 매체(media) 상에 2차 암호화된 부분적 IBV를 저장하는 것을 포함한다.

하나 이상의 구현예에서, 상기 서버 컴퓨팅 디바이스는 사용자의 등록을 폐지할 수 있다.

본 발명의 하나 이상의 구현예에 따르면, 본 발명에서 일반적으로 생체인식 오픈 프로토콜 표준(Biometric Open Protocol Standard, BOPS)이라고 지칭되는 새로운 표준 세트(set)는, 집합적으로 또는 적어도 부분적으로 사용자 인증을 위한 프레임 워크(framework)를 포함한다. 하나 이상의 BOPS 구현예는 신원 선언(identity assertion), 롤 개더링(role gathering), 다중-레벨 액세스 제어(multi-level access control), 보증 및 감사(autditing)를 위한 하나 이상의 모듈을 제공할 수 있다.

본 발명의 다른 특징 및 이점은 첨부된 도면을 참조한 하기의 본 발명의 설명으로부터 명백해질 것이다.

본 명세서의 다른 양상들은 첨부된 도면과 관련하여 기재되는 다양한 실시예들의 상세한 설명을 검토하면 보다 용이하게 이해할 수 있다.
도 1은 본 발명의 하나 이상의 구현예를 갖는 복수의 장치 및 요소를 나타내는 블록 다이아그램이다.
도 2 내지 6은 BOPS 구현예와 관련하여 이들 사이의 장치 및 정보 흐름을 나타낸 것이다.
도 7a는 하나 이상의 구현예에 따라, 데이터 비밀보장에 특히 중점을 둔 등록 프로세스(Enrollment process)와 관련된 장치 및 단계를 나타낸 것이다.
도 7b는 본 발명에 따라 사용자 인터페이스(interface)에 제공된 관리 콘솔(administrative console)의 예를 나타낸 것이다.
도 8은 등록 프로세스와 관련하여 데이터의 액세스 및 교환을 포함하는 개관을 나타낸 것이다.
도 9는 본 발명의 하나 이상의 구현예에 따라 보안 아키텍처(architecture)의 구성 요소를 나타낸 것이다.
도 10a 및 10b는 본 발명의 하나 이상의 구현예에 따라 2개의 각각 다른 등록 프로세스와 관련된 장치 및 단계를 나타낸 것이다.
도 11은 본 발명에 따라 발생 프로세스(Genesis process)의 상이한 레벨과 관련하여 가능한 요구 사항 및 예시를 나타내는 블록 다이아그램이다.
도 12는 등록 및 인증 프로세스 과정 동안 초기 생체인식 벡터와 관련된 정보의 흐름 예를 나타낸 것이다.
도 13은 본 발명과 관련하여 구현된 시각적 암호기법(Visual Cryptography, VC)의 예를 나타낸 것이다.
도 14는 BOPS 구현예과와 관련하여 공유로 각각의 비트가 암호화되는 시각적 암호기법(Visual Cryptography Scheme, VCS)에서 2개의 공유(2, 2)의 예시적인 중첩을 나타낸 것이다.
도 15는 본 발명에 따라 역할 체계의 예를 나타낸 것이다.
도 16은 구현예에 따라, 리플레이(replay) 방지와 관련한 장치들 및 전송 흐름을 나타내는 블록 다이어그램이다.
도 17은 구현예에 따른 토큰(token)과 관련된 단계를 나타내는 고 레벨 흐름을 나타낸 것이다.
도 18은 다수-대-다수(many-to-many) 관계에서 발생 프로세스와 관련된 장치 및 특징의 예를 나타낸 것이다.
도 19a는 단일 클라이언트 장치에서 예시적 등록 프로세스를 시작하는 다수의 사용자를 묘사한 것이다.
도 19b는 다수의 사용자 계정에 관한 정보를 저장하는 클라이언트 장치로부터 인증 세션을 개시하는 사용자의 예를 나타낸 것이다.
도 19c는 사용자 계정의 폐지와 관련된 예시적 단계를 나타낸 것이다.
도 20a는 클라이언트 장치 및 BOPS 서버 사이의 클라이언트 인증서의 초기화, 검증 및 확인과 관련된 단계들을 나타내는 간략한 다이어그램이다.
도 20b는 제3자 및 BOPS 서버와 관련하여 클라이언트 인증서 등록의 예를 나타낸 것이다.
도 21은 본 발명의 구현예에 따라, QR 코드 인증 흐름의 예를 나타낸 것이다.

도 1은 예시적인 하드웨어 배치(arrangement)(100)를 나타내고, 하나 이상의 BOPS 구현예과와 관련된 데이터 통신을 나타낸다. 배치(100)는 본 명세서에 표시되고 기재된 기능을 지원하고 가능하게 하는 클라이언트 장치(예를 들어, 스마트 폰 또는 모바일 장치)(104), 서버 컴퓨팅 장치(본 발명에서는 일반적으로 "BOPS 서버"라 함)(102), 3차 부분 서버(third party server)(106) 및 복수의 컴퓨팅 장치를 포함할 수 있는 IDS(intrusion detection system, IDS)(112)과 같은 다수 컴퓨팅 장치를 설정하는 하나 이상의 소프트웨어 애플리케이션을 포함할 수 있다. 따라서, BOPS 서버(102)는 건강 상태 모니터링 장치(108) 및 분석 엔진 장치(Analytics engine device)(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); ID = 식별자(identifier); IDS = 침입 탐지 시스템(intrusion detection system); IBV = 초기 생체인식 벡터(initial biometric vector); IP = 인터넷 프로토콜(internet protocol); JSON = 자바스크립트 개체 표기(JavaScript object notation); LDAP = 경량 디렉토리 액세스 프로토콜(Lightweight Directory Access Protocol); MAC = 필수 액세스 제어(mandatory access control); MCA = 모바일 클라이언트 애플리케이션(Mobile Client Application); NSA = 미국 국가 안전국(National Security Agency(U.S.)); QR code = 빠른 응답 코드(Quick Response code); RDBMS = 관계형 데이터베이스 관리 시스템(relational database management system); REST = 표현 상태 전송(representational state transfer); SSL = 보안 소켓 계층(secure socket layer); TCSEC = 신뢰할 수 있는 컴퓨터 시스템 평가 기준(trusted computer system evaluation criteria); TLS = 전송 계층 보안(transport layer security); URL = 균일한 자원 식별자(uniformresource 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-tuple = 5개의 튜플 데이터 파라미터(Five tupledata parameters).

본 발명의 장점은 하나 이상의 각각의 BOPS 구현예가 기능적으로 제공하기 위한 구성 요소를 포함할 수 있고, 상대적으로 매우 짧은 기간에 현재 운영 환경과의 통합을 제공하는 것에 의하여, 기업의 기존 구성 요소와 함께 작동하거나 대체할 수 있다는 것이다. 따라서, 하나 이상의 각각의 BOPS 구현예는 민감하고 사적인 자원에 대한 액세스를 판정하는 것과 같은 연속적인 형태의 보호를 제공한다. 서비스-수준의 보안(Service-level security)은 개발중인 시스템 뿐 아니라 프로덕션 시스템에 대한 적절한 보안을 추가하는 “포인트-앤-컷(Point-and-cut)”의 형태로서 구현예를 제시하는 적어도 부분적으로 하나 이상의 애플리케이션 프로그래밍 인터페이스(API)의 기능으로서 허용된 목표를 달성하거나 초과하는 BOPS 구현예를 제공할 수 있다.

하나 이상의 BOPS 구현예는 본 발명에서 일반적으로 초기 생체인식 벡터(IBV)로 지칭되는 생체 벡터를 클라이언트 장치(104)로부터 하나 이상의 데이터 통신을 통해 수신할 수 있고, 상기 벡터를 알고리즘에 따라 증명서와 관련된 다수의 부분으로 분할할 수 있는 BOPS 서버(102)를 포함할 수 있다. 조각(pieces)의 수에 관계없이, 상기 IBV는 키리스(keyless) 방식을 포함하여 암호화 될 수 있고, 후속 생체인식 매칭 프로세스는 예를 들어, 선택적으로 예를 들어 관리 파라미터(administration parameter)에 의해 표시되는 것과 같이, 클라이언트 장치(104) 또는 상기 서버(102)에서 발생할 수 있다.

하나 이상의 BOPS 구현예는 퍼블릭 클라우드(예, 아마존 웹 서비스(AMAZON WEB SERVICES)) 또는 프라이빗 클라우드(private cloud)와 같은 다양한 온라인 환경에서 구현될 수 있다.

본 발명에 표시되고 기재된 장치 조직 아키텍처 및 기능에 따라, 사용자 인증은 인증 대신에, 그리고 상기 서버가 클라이언트 정보를 보유하지 않으며, 오히려 하나의 클라이언트를 다른 클라이언트로부터 구분할 수 있는 충분한 양의 정보를 유지하는 방법으로 제공될 수 있다. 하나 이상의 BOPS 구현예에 따른 상기 보안 고려 사항의 구성 요소는 신원 선언(identity assertion), 롤 개더링, 액세스 제어, 감사(audting) 및 보증을 포함할 수 있다. 그러므로, 하나 이상의 BOPS 구현예는 엔드-투-엔드(end-to-end) 생체인식 솔루션에서 상기 서버 측 구성 요소를 주로 고려한다.

신원 선언과 관련하여, 하나 이상의 BOPS 구현예는 자원의 지속적인 보호를 제공하고, 판단 및 기타 핵심 기능의 배치와 실행 가능성을 보장할 수 있다. 하나 이상의 BOPS 구현예는 사람의 생체인식에 직접적인 의존 없이, 명명된 사용자가 자신이 주장하는 사람인지 확인하는 데 도움이 되는 신원 선언을 더 도울 수 있다. 본 명세서에 표시되고 기재된 상기 표준(standards)은 사실상 임의의 신원 분석기(asserter) 또는 동일한 명명된 사용자와 관련된 다수의 상이한 분석기를 통합할 수 있는 상호 정보 교환이 가능한 표준(interoperable standards)을 포함한다. 상기 IDS(예를 들어, 클라이언트 장치(112)를 통한)의 애플리케이션은 자격 증명 세트를 스푸핑하는 것을 방지 및/또는 하나 이상의 악의적인 시도를 했거나 시도하고 있다고 판단되는 주체(subject) 또는 장치를 블랙리스트에 올리는 것을 돕기 위해 능동적인 모니터링을 제공할 수 있다.

추가적으로, 롤 개더링은, 예를 들어, 알려진 시스템에 의해 정의 및/또는 시행되는 규칙을 기반으로 하는 데이터 기밀성 및 권한 있는 액세스의 기능으로 지원된다. 예를 들어, 액세스의 특정 모드가 허용되는지 여부를 결정하기 위해, 각 역할과 연관된 특정 권한을 그룹의 분류와 비교될 수 있다. 개체 아키텍처는 액세스 제어로 정의할 수 있으며, 롤 개더링은 시스템 수준에서 또는 클라이언트/서버 호출을 통해 발생할 수 있다. 예를 들어, BOPS 서버(102)는 특별한 사용자를 특별한 장치(104)와 연관시키기 위해 롤 개더링 정보를 저장할 수 있다. 액세스 제어는 주어진 주체(subject)(예를 들어, 사람, 장치 또는 서비스(예; 소프트웨어 프로그램))가 주어진 개체(object)를 읽기, 쓰기, 실행 또는 삭제하는 것과 같은 액세스 및/또는 수행할 권한이 있는지를 결정하는, 컴퓨팅 장치에서 실행되는 하나 이상의 모듈의 구현예를 포함할 수 있다.

일반적으로 액세스 제어는 임의일 수 있고, 보다 세분화될 수 있는 필수 액세스 제어를 포함할 수도 있고 대안을 포함할 수도 있다. 예를 들어, 임의 액세스 제어는 명명된 사용자 및 명명된 개체(예 : 파일 및 프로그램)의 기능으로 하나 이상의 개체에 대한 액세스를 제어하는 것과 관련이 있다. 예를 들어, 판단 메커니즘(adjudication mechanism)은 역할-기반일 수 있고 사용자 및 관리자가 명명된 개인 및/또는 정의된 그룹에 대한 개체의 공유를 명시 및 제어할 수 있도록 한다. 임의 액세스 제어 메커니즘은, 하나 이상의 구현예에서, 상기 개체가 개체의 단일 또는 그룹을 통해 그룹 또는 개별 수준에서 무단 액세스로부터 보호된다는 것을 제공한다. 그러므로, 임의 액세스와 관련된 세분성은 개인에서 그룹까지 다양할 수 있다.

하나 이상의 BOPS 구현예는 각각의 구현예 내에서 제어되는 모든 주체 및 저장 개체(예를 들어, 프로세스, 파일, 세그먼트, 장치)에 대해 필수적인 액세스 제어 정책을 시행할 수 있다. 이러한 주체 및 개체는 계층적 분류 수준 및 비계층적 범주의 조합이 될 수 있는 민감도 라벨(sensitivity label)을 할당할 수 있다. 상기 라벨(label)은 필수 액세스 제어 결정을 위한 근거로 판단에 사용될 수 있다. 예를 들어, 클라이언트 장치(104)상에서 실행되는 소프트웨어는 상기 장치로 하여금 라벨을 유지하거나, 주체 및 개체의 라벨 부착을 강화하기 위해 데이터를 유지하는 BOPS 서버(102)를 갖는다. 상기 BOPS 서버(102)는 BOPS 구현예의 구성요소로서 신뢰된 저장소를 유지할 수 있다. 본 발명에서 사용되는 신뢰할 수 있는 저장소는, 일반적으로, 액세스 제어(DAC 또는 MAC)는 주체가 올바른 개체를 수신하도록 보장하고, 부인 방지(non-repudiation) 및 비밀을 보장하도록 데이터를 안전한 방식으로 저장하는 것을 의미한다.

다음은 하나 이상의 BOPS 구현예에서 지원되는 액세스 제어 규칙 및 옵션을 식별한다. 주체의 보안 수준에서의 계층적 분류가 객체 보안 수준의 계층적 분류보다 크거나 같을 경우에만 주체는 객체를 판독하는 액세스를 제공할 수 있다. 주체의 보안 수준에서 하나 이상의 비계층적 범주는 개체의 보안 수준에서 모든 비계층적 범주를 포함할 수 있다. 주체 보안 수준에서 계층적 분류는 개체 보안 수준에서 계층적 분류보다 적거나 같고, 주체 보안 수준에서 모든 비계층적 범주는 개체 보안 수준에서 비계층적 범주를 포함할 경우에 주체는 개체를 기록 및/또는 실행할 수 있다. 식별 및 인증 데이터는 사용자의 신원을 인증하고, 개인적인 사용자를 대신하여 행동하도록 생성될 수 있는 BOPS 구현예에 대하여, 외부 주체의 상기 보안 레벨 및 인증은 상기 사용자의 정리(clearance) 및 인증에 의해 지배되는 것을 확인하기 위해 BOPS 서버 장치(102)에 의해 이용 가능하다.

본 애플리케이션은 일반적으로 보증으로서 본 발명에 기재된 보안 모델이 작동 하는지를 감사 및 입증하는 것에 대비하는 하나 이상의 모듈의 기능을 포함하여 감사(audting)를 제공한다. BOPS 구현예 내의 컴퓨팅 장치가 손상되는 경우일 때, 그러한 모듈이 손상된 시스템(compromised system)이 감지되지 않은 상태로 작동하는 것을 제외한다. 예를 들어, BOPS 구현예에서, 감사(audting) 요구는 당업계에 공지된 바와 같이, 관점-지향 프로그래밍(aspect-oriented programming)의 기능을 포함하여, 주제/개체 레벨 또는 그룹 레벨에서 지원될 수 있다. 이는 호출이 감사(audting) 추적에 안전하게 기록될 가능성이 높아진다. 게다가, RESTful 웹 서비스 및 JSON(JavaScript Object Notation)의 인터페이스는 감사(audting) 추적을 읽는 메커니즘을 제공할 수 있다. 감사(audting)는 작업 당 주체, 작업 당 개체 또는 작업 당 그룹에서 발생할 수 있다. 예를 들어, 사용자 그룹은 특정 이름(예를 들어, "회계")에 의해 지정될 수 있고 일반 장부에 대한 모든 기록을 감사(audting)할 수 있다. 추가적으로, 개인, 예를 들어 최고 재무 책임자는 손익 계산서를 읽을 수 있는 감사(audting) 정보를 제공받을 수 있다.

하나 이상의 JUnit 테스트 스위트(suit)는 하나 이상의 BOPS 구현예에서 경계 조건 테스트하고 모니터링하기 위해 사용될 수 있으며, 여기에는 시스템 내의 경계 구성 요소 및 조건 테스트가 포함될 수 있다. 하나 이상의 BOPS 구현예에서 보안 조항은 적어도 부분적으로 API의 기능으로 충족될 수 있다. API의 사용은 관계형 데이터베이스 관리 시스템, 검색 엔진 또는 사실상 임의의 다른 아키텍처와 같은 근본적인 시스템을 따르는 BOPS 구현예를 식별 및/또는 커스터마이징(customizing)하는 것에 대하여 요구하지 못하게 한다. 각각의 BOPS 구현예에 의해 제공되는 기능은 개발시 시스템뿐 아니라 생산 시스템에도 적절한 보안을 추가하기 위한 "포인트-앤-컷(point-and-cut)"메커니즘을 제공할 수 있다. 따라서, 하나 이상의 BOPS 구현예의 아키텍처는 REST, JSON 및 SSL을 지원하여 통신 인터페이스를 제공하는 언어-중립적이다. 하나 이상의 구현예에서, 상기 아키텍처는 서브렛 사양(servlet specification), 열린 SSL, Java, JSON, REST 및 영구 저장소에 구축된다. 도구는 도 1에 나타난 바와 같이, 장치에 대한 최대 상호 운용성을 허용하는 개방형 표준을 준수할 수 있다.

하나 이상의 BOPS 구현예에서 신원 선언, 롤 개더링, 다중 레벨 액세스 제어, 감사(audting) 및 보증이 제공된다. 이들은 적어도 하나의 특별히 구성된 클라이언트 장치(104)(예를 들어, 스마트 폰 또는 모바일 장치), BOPS 서버(102) 및 장치(112)를 포함하는 침입 탐지 시스템(IDS)의 조합의 기능으로서 구현될 수 있다. 하나 이상의 구현예에서, 클라이언트 장치(104)는 애플리케이션을 실행하고, BOPS 서버(102)와 함께 보안 및 초기 통신 세션을 설정하기 위한 1회 양방향(two-way) SSL(secure-sockets layer)/TLS(transport layer security) 키(key)를 로딩한다. 발생(genesis)은 일반적으로 주어진 개체와 일련의 생체인식을 통합하는 과정의 처음 또는 초기 단계를 포함한다. 본 명세서에서 일반적으로 등록으로 지칭되는 다른 단계는 BOPS 구현예에서 사용자 및/또는 장치를 등록하는 것과 관련된 단계를 포함하며, 클라이언트 장치(104)에 대한 인증서를 발행하는 것, 클라이언트 인증서를 보호하는 것 및 클라이언트에 저장된 중요한 데이터를 보호하는 것을 포함할 수 있다.

하나 이상의 BOPS 구현예에서, 인프라스트럭처(infrastructure)는 데이터 암호화 및 보안 클라이언트/서버 통신을 처리하는 것을 제공한다. BOPS 인프라스트럭처는 발생(Genesis) 및 등록(Enrollment)의 디커플링 과정(decoupling processes)을 지원하고 이러한 과정을 다양한 등록 요소와 함께 조정할 수 있다. 이러한 종속성(dependencies)은 BOPS 서버(102) 인프라스트럭처를 식별하고, 다음을 포함할 수 있다: BOPS DNS; BOPS 트러스트저장소(TrustStore); BOPS 키 저장소(KeyStore); BOPS 주요 협상 프로토콜(Key Negotiation Protocol). 인증서 관리와 관련하여, BOPS 서버(102)의 호스트 이름에 대한 DNS 항목은 단-방향 SSL의 키 저장소에 키를 갖도록 구성할 수 있다. 하나 이상의 BOPS 구성에서 상기 트러스트저장소(TrustStore)는 모든 해당 인증서에 서명하기 위한 인증 권한을 정의하는 양-방향 SSL 메커니즘이다. 전송 수준에서 핸드 셰이크(handshake)를 수행하여 양방향 인증서와 트러스트 저장소를 통해 BOPS 신원이 발생할 수 있다. 상기 키 저장소는 키 저장소의 키를 통해 전송 수준 보안을 지원하며, 키 저장소의 키는 SSL/TLS에서 암호화를 위해 호스트를 식별하는데 사용할 수 있는 VERISIGN, GODADDY 또는 기타 권리와 같이 잘 정의되고 인식된 인증서 권리를 사용할 수 있다. 본 명세서에서 기재된 바와 같이, 하나 이상의 BOPS 구현예는 양방향 SSL 인증서를 잠금 해제하는 패스워드를 요청하기 위해 클라이언트 장치(104)에 대한 일회용 패스워드(one-time password, OTP) 과정을 사용한다. 이는 양방향 SSL 세션이 시작된 후에 클라이언트 장치(104) 및 서버(102)가 OTP를 동기화하여 키를 다시 전달하여 인증서의 잠금을 해제함으로써 수행될 수 있다.

하나 이상의 구현예에서, 몇몇 키 등록 요소는 클라이언트 장치(104)가 BOPS 서버(102)에 요청을 보낼 때 클라이언트 인증서 인증을 지원한다. 토큰(token)은, 예를 들어, 데이터 요소의 기능(예: "Common Name")과 같이 ID에 서버의 프로파일을 연결하는 식별자로 구성될 수 있다. 상기 OTP 과정에는 양방향 SSL(x.509) 인증서의 잠금을 해제하는 상기 서버로부터 암호를 요청하는 하나 이상의 메커니즘을 포함한다. 암호는 상기 서버 컴퓨팅 장치(102)와 상기 클라이언트 컴퓨팅 장치(104) 사이에 조정되는 사전 정의된 알고리즘에 의해 각각의 사용에 대해 변경될 수 있고, OTP에 사용되는 상기 채널은 상기 개인 인증서에 사용되는 상기 채널과 다른 것이 바람직하다. 예를 들어, 푸시 알림은 개별 인증서의 잠금을 해제하는 데 사용되는 암호를 보낼 수 있다. 다른 인증서는 사용하여 개별 인증서의 잠금을 해제하기 위한 암호를 얻을 수 있다. 좌우간, 인증서의 잠금을 해제하는 상기 메커니즘은 상기 클라이언트 장치(104)에서 그 암호를 저장하는 것을 포함하지 않을 수 있다.

예를 들어, 애플리케이션은 발생 및 등록을 위해 디폴트(default)(예, 사전 로딩된) 인증서를 사용한다. 후속 처리는 현재 OTP와 함께 디폴트 인증서를 사용할 수 있다. 그 결과(예, HTTP 반응)는 인증서의 잠금을 해제하기 위한 암호가 포함될 수 있다. 이에 상기 OTP가 클라이언트 및 서버에서 롤 포워드(roll forward)된다. 하나 이상의 BOPS 구현예에서 5- 튜플(5-tuple)은 리플레이 공격을 방지하는 데 사용되는 높은 엔트로피 값(high entropy value)이다. 상기 값은 등록시에 발생할 수 있고 클라이언트 장치(104)와 서버(102) 사이에서 추후 통신의 일부가 될 수 있다.

BOPS 구현예에서 클라이언트/서버 애플리케이션의 상호 작용은 3 단계 과정으로 고려될 수 있으며, 적어도 두 가지 가능한 변경이 초기 첫 번째 단계를 따를 수 있다. 이러한 경우에, BOPS 클라이언트/서버 애플리케이션 아키텍처(architecture)는 3 가지 구성 요소를 참조하여 기재하였다: 클라이언트 장치(104)상에서 실행되는 클라이언트 애플리케이션, BOPS 서버(102)상에서 실행되는 애플리케이션, 및 서버-측(server-side) 애플리케이션(이하, “App Server”라고 함). 도 2 내지 도 6에 나타난 바와 같이, SSL/TLS 연결이 애플리케이션 서버에서 종료할 수 있는 것으로서, 상기 서버-측 애플리케이션은 필수적으로 상기 BOPS 서버(102)를 통해 실행되는 것은 아니다. 또한, 각각의 BOPS 구현 배치는 암호화되지 않은 콘텐츠를 갖는 BOPS 시스템을 신뢰하는 애플리케이션을 요구하지 않는다. 도 2를 참조하면, 발생 과정 동안 상기 클라이언트 장치(104)는 상기 BOPS 서버(102)에 요청을 하고, 사용자 및 클라이언트-측 애플리케이션 소프트웨어를 인증한다. 그 후에, 상기 클라이언트 장치(104)는 BOPS 서버(102)에 의해 할당되고 특정 애플리케이션의 상기 클라이언트 신원에 특정한 인증서를 수신한다.

다음 단계(도 3)에서, 상기 클라이언트 장치/애플리케이션은 상기 애플리케이션 서버를 직접 호출한다. 상기 애플리케이션의 클라이언트와 서버 부분 사이의 상기 SSL/TLS 연결은 이러한 지점에서 시작되고 종료된다. 콘텐츠 교환은 바람직하게는 BOPS 서버(102) 또는 이 애플리케이션 엔티티(entity) 내에서 신뢰되지 않는 다른 사람들에 대해서 애플리케이션의 외부가 보이지 않는다. 클라이언트 세션 동안(도 4), 애플리케이션 서버(106)는 BOPS(102) 서버를 호출하여 식별 세부 사항을 획득하고 인증서가 이전에 취소되지 않았다는 것을 확인한다.

2차 변형에서(도 5에 부분적으로 나타냄), 상기 발생 단계(도 2 내지 도 3에 기재된 것을 포함)는 동일할 수 있다. 그 후에, 상기 BOPS 서버(102)는 신규 클라이언트(104)가 등록되고 할당된 것을 알리기 위해 상기 애플리케이션 서버(106) 구성 요소에 접속한다. 상기 2차 변형의 흐름은 최소한 두 가지 방식으로 첫 번째 변형의 흐름과 다르다: ID 세부 정보가 다르며 해지 확인이 클라이언트 세션에서 획득된다(그림 6). 제3 단계에서, 상기 클라이언트 장치(104)가 애플리케이션 서버(106)를 직접 호출할 때, 상기 애플리케이션 서버(106)는 상기 BOPS 서버(102)를 호출하여 사전에 인증서가 폐기되지 않았음을 확인한다.

예시적인 BOPS 구현예와 관련하여 본 발명에 나타나고 기재된 상기 특징들은 본 발명에서 제공된 액세스 제어 모듈에 의해 또는 이와 관련하여 사용될 수 있거나, 또는 기존 프레임 워크의 식별 주장 구성요소에 추가할 수 있다. 그러므로 상기 BOPS 구현예는 제작(production) 환경에서 최소한의 작업을 수행함으로써 신뢰할 수 있는 과정을 가능하게 하고, 그에 관해 종종 응용 프로그램 소프트웨어의 변경 요구 사항을 배제한다.

도 7a는 하나 이상의 BOPS 구현예에 따라, 예시적인 등록 과정 및 관련된 데이터 기밀성과 관련된 장치 및 단계(700)를 나타낸다. 본 발명의 애플리케이션에서 단방향 SSL/TLS를 기반으로 구축되는 양방향 SSL/TLS는 클라이언트 장치(104)에서 시작하는 통신을 제공한다. 상기 초기(예를 들어, 발생) 통신은 클라이언트(104)의 신원의 기원(origin)을 정의할 수 있고 상기 클라이언트 장치(104)가 세션-지향 신원 선언(session-oriented identity assertion)과 함께 후속 통신에 사용할 수 있는 BOPS-호환-양방향 인증서(BOPS-compliant two-way certificate)를 전달할 수 있다. 하나 이상의 구현예에서, 상기 클라이언트 애플리케이션은 후속 발생 작동을 허용하는 사전 로딩된 양방향 SSL/TLS 키를 가질 수 있다.

하나 이상의 구현예에 따라, BOPS 서버(102)는 클라이언트 장치(104)로부터 양방향 SSL/TLS 신원을 갖는 단방향 SSL/TLS 통신을 수신한다. 통신은 단방향 SSL/TLS와 양방향 SSL/TLS를 통해 수행된다. 하나 이상의 구현예에서, 상기 서버(102)는 신뢰되는 신원 정보를 취하고 각각의 신원을 대신하여 처리하기 위한 역할을 수집하는 것으로 데이터 저장소를 사용한다. 게다가, 감사(audting)는 신뢰할 수 있는 액세스의 지속적인 확인(verification) 및 검증(validation)을 위해 적절한 아티팩트(artifact)를 최대화한다. 상기 보증은 다단계 액세스 제어 메커니즘의 단순화 및 문서화 기능으로 발생할 수 있다.

하나 이상의 BOPS 구현예에서, 그래픽 사용자 인터페이스에서 관리 콘솔(administration console; 이하 “admin console”)은 등록 과정의 완료 다음에 제공되며, 이는 사용자, 그룹 및 역할의 동적 수정을 가능하게 하고, 본 발명에서 보다 상세하게 설명한다. 예시인 관리 콘솔은 도 7b에 나타나 있다.

도 7a를 참조하면, 토큰 요청(RESTful)은 클라이언트 장치(104)(1)로부터 전송되고 BOPS 서버(102)로부터 수신되고 검증(2)된다. 상기 BOPS 서버(102)의 호스트 명을 위한 DNS 엔트리(DNS entry)는 키 저장소(3)에 키를 갖도록 구성될 수 있고, 요청은 포맷되며(4A), m 토큰 반응은 양방향 SSL/TLS를 통한 클라이언트 장치(104)(4B)로 전송된다. 그 후에, 클라이언트 장치(104)(5)로부터 c 토큰(예를 들어, 5-튜플 및 타임스탬프(TimeStamp))이 전송되며, 요청 시 m 타임스탬프(TimeStamp)의 기능을 포함하여 검증된다(6, 7). 그 후에, 상기 누락된 5-튜플은 트러스트 스토어(Trust Store)에 대하여(vis-a′-vis) 결정되고(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 security request)이 클라이언트 장치(104)(22)로부터 전송되고, 이는 BOPS 서버(102)(23)에 의해 검증된다. 요청은 포맷되고(24), 사용자 지정 보안 반응(SHA512 토큰 포함)은 클라이언트 장치(104)로 전송된다(25).

하나 이상의 BOPS 구현예에서, 장치(112)를 통한 것을 포함하는 능동적 침입 탐지 시스템(active intrusion detection system)을 제공한다. 상기 능동적 침입 탐지 시스템은 무차별-대입 공격(brute-force attack), 서비스-거부-공격(denial-of-service)(예, 분산 또는 단일 서비스 거부 공격) 또는 기타 공격을 방지하는 데 효과적이다. BOPS 서버 장치(102)를 타협하기 위해 양방향 SSL/TLS 인증서 위장(impersonation), 세션 리플레이, 구축된 패킷(forged packet) 또는 다양한 우회(circumvention) 기술을 구축하려는 시도를 식별하고 추적하는 사용자 지정(custom) 규칙을 정의하고 적용할 수 있다.

하나 이상의 BOPS 구현예에서, 시각적 암호(visual cryptography)는 초기 생체인식 벡터(IBV)를 암호화하는 데 사용된다. 이 기술은 생체인식 매치(match)를 수행하는 특정 장치에서 배타적 논리합 연산(XOR operation)을 사용하는 것과 같이 IBV를 빠르게 재구성하는 이점을 제공한다. 예를 들어, Moni Naor와 Adi Shamir가 개발한 기술을 사용하여 비밀 공유 체계를 제공할 수 있다. 예시 작업에서, 벡터는 N 개의 공유로 나뉘며 초기 벡터를 재구성하는 것은 모든 N 개의 공유 부분이 필요하다. 각각의 장치는 BOPS 서버(102) 및 모바일 클라이언트 애플리케이션(104)을 포함하고, 등록된 벡터는 BOPS 서버(102)에 의해 액세스 가능한 BOPS 저장소(repository) 및 모바일 컴퓨팅 장치(104)상의 다른 하나에 저장되는 2 개의 공유 파트로 분할될 수 있다.

본 발명의 하나 이상의 구현예에서, 데이터 기밀성을 보장하기 위한 다른 형태의 암호화 및/또는 메커니즘이 사용될 수 있다. 예를 들어, 타원 곡선 암호(elliptic curvecryptography)는 시각적인 암호 대신에(또는 잠재적으로 추가적으로) 사용될 수 있다.

예시적인 생체인식을 인증하는 동안, 새롭게 획득된 벡터 및 등록된 벡터의 두 공유는 단일 위치(예를 들어, 모바일 컴퓨팅 장치 애플리케이션(104) 또는 BOPS 서버(102))에서 또는 다수의 위치에서 이용 가능할 수 있다. 어떤 경우에, 등록된 벡터 공유를 사용하여, 상기 초기 벡터를 메모리에 다시 구성할 수 있으므로 이에 대해 발생하는 인증을 지원한다. 도 8은 등록 과정과 관련하여 데이터의 액세스 및 교환을 포함하는 개요(overview)를 나타낸다. BOPS 서버(102)와 관련하여, 신원은 주체의 계정 및 장치의 기능으로서 제공된다. 상기 주체의 계정 및 장치는 해당 주체의 프로필 정보의 일부이다. 상기 프로필 정보는 클러스터 된 데이터 저장소에 저장된다. 매치(match)를 위해, 상기 IBV는 공유에서 가지고 가고, 환원( reconstituted)되고 해독(decrypted)된다. 매치 알고리즘이 유클리드(Euclidean) 매치 가능하지 않으면 상기 매치는 플레인텍스트(plaintext)로 발생하고, 그렇지 않을 경우에는 암호화된 도메인에서 상기 매치가 발생한다.

다른 구현예에서, 준동형(homomorphic) 암호가 이용되며, 이는 암호문(ciphertext)상에서 계산(computation)이 수행되도록 하고 암호화된 결과를 생성한다. 매치 작업은 암호화된 공간에서 수행할 수 있으므로, 프라이버시(privacy) 및 보안을 향상시킨다. 예를 들어, 단방향 암호화를 사용하여 암호화된 공간에서 매치가 발생할 수 있으므로, 높은 수준의 프라이버시를 제공하고, 효과적으로 원본 플레인텍스트 IBV를 얻을 수 있는 능력을 불가능하게 한다.

하나 이상의 구현예에서, 알고리즘은 두 가지 부분을 갖는 방식으로 단방향 암호화를 수행한다: 클라이언트의 한 부분 및 서버의 한 부분. 상기 매칭(matching)이 유클리드 거리(Euclidean distance)(예를 들어, 해밍 거리(Hamming distance))를 사용하는 경우, 당업계에 공지된 바와 같이, 암호화된 공간에서 매칭이 발생한다. 대안으로, 상기 매칭이 해밍 거리를 사용하지 않으면, 본 명세서에 기재된 바와 같이, 플레인텍스트 공간에서 매칭된다.

하나 이상의 구현예에서, 암호화된 공간에서 매칭을 허용하는 단방향 암호화를 수행하기 위해 임의의 일회용 암호표(random one-time pad, ROTP)가 사용된다. 대안으로, 시각적 암호기법(crptography)은 플레인텍스트에서 일치하는 경우에는 되돌릴 수 있는 암호로 사용된다. 예를 들어, 해밍 거리가 없는 경우에는 메모리에서 매치가 발생할 수 있도록 시각적 암호기법이 사용되어 플레인텍스트로 전환된다. 바람직하게는, 암호 및 해독은 두 가지 암호화 알고리즘 중 하나를 사용한다: 1. 비트 마스크(Bitmask) 또는 2. 매트릭스 변환. 이상적으로는, 모든 매치 알고리즘은 해밍 거리를 가질 것이므로, 상기 서버에 플레인텍스트 IBV가 없다.

하기는 2 개의 이진 벡터(binary vector)들 사이의 해밍 거리를 계산하는 함수로서 수행되는 홍채 인식과 관련된 알고리즘의 예이다. 예시 알고리즘에서, 하기와 같이 플레인텍스트로 변환하지 않고 생체인식의 암호화 된 반쪽에서 직접 매칭이 수행될 수 있다(^는 비트의 XOR 연산을 나타냄).

서버는 다음을 저장한다: 벡터^노이즈를 등록(Enrol vector^noise).

전화는 다음을 전송한다: 벡터^상기와 동일한 노이즈를 확인(Verify vector^the same noise).

서버에서 비교를 실시한다: (벡터^노이즈 등록)^(벡터^상기와 동일한 노이즈를 확인)((Enrol vector^noise)^(Verify vector^the same noise)).

XOR은 교환(commutative) 및 연상(associative)이므로, 다음과 같이 재정렬 할 수 있다:(벡터 등록^벡터 확인)^(노이즈^동일한 노이즈)((Enrol vector^Verify vector)^(noise^the same noise)).

XOR은 자기-역행렬(self-inverse)이므로(노이즈 = 같은 노이즈) = I((noise ^ the same noise) = I), 여기서 I는 XOR에 대한 항등 요소(identity element)인 0이다.

그러므로, 식은 다음과 같이 단순화된다: (벡터 등록^벡터 확인)^I =(벡터 등록^벡터 확인)((Enrol vector ^ Verify vector) ^ I =(Enrol vector ^ Verify vector)).

A와 B 사이의 해밍 거리는 A^B의 함수이다.

그러므로, 노이즈 벡터 간의 해밍 거리는 원래 벡터 간의 해밍 거리와 동일하다.

예시 구현예에서 등록시, 다음이 발생한다:

a). 등록 벡터(Enrolment vector):

00110011

b). 임의의 서열(벡터의 첫 번째 절반): 서버에 저장

01010101

c). 벡터의 두 번째 절반(계산된): 전화에 저장

01100110

확인 시 :

e). 확인 벡터: (이는 좋은 일치이기 때문에 등록과 검증 사이에서 마지막 비트만 변경되었음을 알림).

00110010

벡터의 두 번째 절반: 전화에 저장됨

01100110

f). 벡터의 첫 번째 절반에 대한 근사값을 계산(e 및 c에서):

01010100

매칭(matching)시:

g). "확인 첫 번째 절반(verification first half)"(f)를 서버에 보낸다.

h). 서버는 다음을 가진다:

등록 벡터 첫 번째 절반 b):

01010101

확인 벡터 첫 번째 절반 f):

01010100

b 및 f에서 변환된 모든 비트를 1로 플래그함:

00000001

상기 시스템은 등록과 검증 사이에서 마지막 비트만 변경되었음을 알 수 있으며, 이는 좋은 일치를 나타내나, 서버가 스크램블된 데이터만을 다루는 방법 및 서버에서 실제 벡터가 서버에 알려지지 않았음을 알 수 있으며, 벡터의 차이만 계산할 수 있다.

다른 구현예에서, 얼굴 인식(facial recognition)은 상기 벡터로부터 얼굴을 리버스-엔지니어링(reverse-engineered)할 수 없는 템플릿 벡터 사이에서 유클리드 거리를 계산함으로써 수행된다. 예를 들어, 신경망(neural network)을 사용하여 두 얼굴 이미지가 일치할 ?, 각 얼굴이 첫번?로 128 바이트 크기의 플로트 벡터(float vector)로 변환된다. 이 플로트 벡터의 표현은 임의적이며, 원래의 얼굴로 리버스-엔지니어링 할 수 없다. 얼굴을 비교하기 위해, 상기 두 벡터의 유클리드 거리를 계산한다. 상기 같은 사람으로부터 두 얼굴은 비슷한 벡터를 가져야하며, 다른 사람들의 얼굴은 유클리드 공간에서 더 멀리 떨어져 있어야한다. 상기 모바일 장치에서 확인 벡터를 계산할 수 있고, 저장된 등록 벡터와 매칭시키기 위해 원격 서버로 전송할 수 있다. 이에, 원래의 생체인식(예를 들어, 얼굴)은 결코 사용자의 장치를 남기지 않을 것이고, 모든 매칭은 서버상에서 계산될 수 있다.

또 다른 구현예에서, 지문 인식은 벡터로부터 상기 지문을 리버스-엔지니어링할 수 없는 템플릿 벡터들 사이의 유클리드 거리를 계산함으로써 수행된다. 유사하게, 전술한 바와 같이, 지문 일치를 위해 신경 네트워크가 적용될 수 있다.

이 경우에, 상기 지문을 장치에서 벡터로 변환하고 벡터를 전송함으로써, 상기 네트워크 출력 벡터로부터 원래의 지문 이미지를 재구성할 수 있는 방법을 제거할 수 있다.

하나 이상의 구현예에서, 암호 키(encryption key)는 신경망으로부터 상기 출력 벡터를 난독화하기 위해 사용되는 장치 상에서 랜덤하게 생성된다. 예를 들어, 암호화된 생체인식 벡터 = 암호 매트릭스 × 플레인텍스트 생체인식 벡터(Encrypted biometric vector = Encryption matrix × Plaintext biometric vector). 이 경우, 상기 암호 매트릭스 변환은 유클리드 거리가 보존된다는 특별한 특성을 가지므로, 상기 매트릭스는 엄격한 변환이어야 한다. 이 경우에, 상기 생체인식 벡터는 장치를 암호화되지 않은 포맷으로 두지 않고, 상기 서버는 두 개의 암호화된 생체인식을 비교하고 플레인텍스트를 알지 못한 채 유클리드 거리를 계산한다. 사용자가 새 장치에서 확인하려고 할 때, 상기 사용자는, 예를 들면 QR 코드와 같은 것을 통해, 암호 데이터를 새 장치로 전송할 수 있다. 이 요청은 이전 장치를 사용할 수 있어야 한다. 이전 장치를 분실했거나 사용할 수 없는 경우, 상기 기재된 바와 같이, 사용자가 다시 등록한다.

이에, 강화된 프라이버시는 분리되어 저장되고 암호화된 장치들 간에 저장되는 생체인식 벡터의 기능으로서 제공된다. 상기 생체인식 벡터의 어떤 부분도 디스크나 메모리에 플레인텍스트 형식으로 서버에 존재하지 않는다. 또한, 본 발명의 애플리케이션은 강화된 분석을 제공하는데, 그 이유는 각각의 인증 및 실패한 인증에 대한 "what if" 분석이 패싯(facets), 검색, 분석 등을 지원하는 관리 인터페이스를 통해 수행할 수 있기 때문이다.

도 9는 하나 이상의 BOPS 구현예에 따른 예시 보안 아키텍처(900)의 요소들을 나타낸다. 도 9에 나타나 바와 같이, BOPS 보안 클러스터(902)는 가상 사설망(virtual private networks, VPN)상에서 BOPS 인스턴스(instance)를 실행하도록 구성될 수 있다. 인증 기관 엔티티(Certificate Authorityentity), BOPS 키 저장소 및 BOPS 트러스트 저장소의 속성은 예를 들어, BOPS 인스턴스에 위치할 수 있다. 상기 BOPS 인스턴스는 DNS, OTP 라이브러리, 알림 서비스 키, 비즈니스 어댑터, BOPS 구성 속성을 나타내고/나타내거나 관련된 데이터를 포함할 수도 있다. 상기 로드 밸런서 클러스터(load balancer cluster)(904)는 BOPS 서비스, 분산된 워크로드의 신뢰성 및 가용성을 보장하는 하나 이상의 장치를 포함할 수 있다. 구성된 BOPS 로드 밸런서(904)는 처리량을 최대화하고, 응답 시간을 최소화하며, BOPS 아키텍처(900)에서 임의의 단일 자원의 과부하를 피하도록 작동할 수 있다.

계속해서 도 9를 참조하여, 지속 클러스터(persistance cluster)(906)는 하나 이상의 데이터베이스 보안 그룹을 포함할 수 있고 BOPS 데이터 클러스터의 자동-스케일링을 위해 구성될 수 있다. 인증 서비스는 대용량 데이터 개체(large date object)를 처리하고, 대용량 데이터 세트를 조절하므로, NoSQL 및 하나 이상의 수평 분할 데이터("샤드(shard)")와 같은 빅데이터(big date) 저장소 및 데이터는, 샤드를 사용하여 동시에 읽고 결과를 병합함으로써 성능을 향상시키기 위해 사용될 수 있다. 상기 데이터베이스 보안 아키텍처(900)는 BOPS 아키텍처를 구현하고 단일 위치에서 중요 데이터(sensitive data)의 중앙 집중식 저장(centralized storage)을 방지한다. 또한 도 9에는 IDS 장치(112)를 포함할 수 있는 모니터링 클러스터(908)가 나타나 있다.

도 10a 및 도 10b는 각각 하나 이상의 BOPS 구현예에 따라, 개별적 및 선택적 등록 프로세스(1000 및 1010)와 관련된 장치 및 단계를 나타낸다. 도 10A 및 도 10B에 나타난 구현예는 계정 또는 장치와 관련된 암호화된 생체인식 데이터를 저장하는 메커니즘, 모든 생체인식 데이터 변경에 대한 정보를 저장하는 메커니즘, 인증 서비스 및 해당 생체인식 라이브러리(예를 들어, FACE, 4F, IRIS)를 로드(load) 및 사용하는 메커니즘, 및 새로운 흐름(예를 들어, 등록 및 인증)을 지원하는 API 작동을 제공하는 메커니즘을 제공한다.

도 10a에 나타난 구현예에서, 인증 흐름을 위한 상기 방법이 상기 클라이언트(104) 측에서 발생하도록 구성된 경우에, 모바일 컴퓨팅 장치(104)상에서 실행되는 소프트웨어 애플리케이션("MCA")은 초기 생체인식 벡터(IBV)를 획득하는 것, 등록 프로세스 동안 암호화 분할 동작을 수행하고 서버 측에 더 낮은 CPU 로드(load)가 되도록 이 프로세스를 분배하는 것, BOPS 서버(102)에서 등록 요청(등록)을 수행하는 것, 및 암호 매치 동작을 수행하는 것을 가능하게 한다. 상기 BOPS 서버(102)는 예를 들어 등록 프로세스 동안에 상기 BOPS 빅데이터 저장소(1002)에서 상기 공유된 벡터와 함께 사용자 신원 데이터를 저장하도록 구성될 수 있다. 게다가, 상기 BOPS 서버(102)는 인증 흐름을 관리하고 인증 서비스 통신 요소(1004)를 통합할 수 있다.

인증 서비스(1006)는 하나 이상의 인증 알고리즘, 생체인식 엔진 라이브러리, 인증 엔진 버전화에 대한 지원을 제공하고, BOPS 서버(102)와 인증 엔진 사이의 통신을 표준화하여 동적으로 로딩한다. 인증 서비스는 인증 수행 시 생체인식 서비스를 래핑(wrapper)한다.

본 발명에 기재된 바와 같이, 플러그형 인증 서비스 및 그에 대응하는 생체인식 엔진을 위해 하나 이상의 메커니즘이 제공된다. 이에, BOPS 구현예는(예를 들어, 인증 서비스 및 생체인식 라이브러리의 위치를 통해) 구성 가능할 수 있고 시스템에서 이용 가능한 서비스 및 레지스터를 자동으로 로딩할 수 있다.

결과적으로, 시스템 수준에서 발음 서비스(enunciation services) 목록을 사용할 수 있다(예를 들어, 4F-엔진. FACE-엔진; IRIS-엔진; VOICE-엔진). 인증자(Authenticators) 목록은 FIDO 인증자 또는 BOPS 인증자가 포함된다.

본 발명은 하기의 특징을 지원함으로써 생체인식 통합 인증 서비스에 대한 개선점을 제공한다. 상기 BOPS 서버(102)에 의해 액세스 가능한 계정 또는 장치에서 암호화된 생체인식 데이터를 저장하기 위해 하나 이상의 메커니즘을 제공할 수 있다. 또한, 발생하는 생체인식 데이터 변화를 나타내는 정보를 저장하기 위한 메커니즘을 제공할 수 있다. 추가적으로, 생체인식(예를 들어, 얼굴, 4개의 손가락 및 홍채)을 포함하는 인증 서비스에 접근하고 이를 이용할 수 있는 "포괄적인(generic)" 메커니즘이 제공된다. 예를 들어, 이는 미국 특허 출원 번호 U.S. 14/201,462, 미국 특허 출원 번호 U.S. 14/201,499, 미국 특허 출원 번호 U.S. 14/988,833 및 미국 특허 출원 번호 U.S. 14/819,639에 개시되어 있다.

본 발명의 하나 이상의 구현예에서, 모바일 컴퓨팅 장치(104)는 등록 벡터를 획득하고, 등록 프로세스 동안 암호화 분할(cryptographic split) 동작을 수행한다. 이는 프로세스를 분산시키고 서버 측에서 CPU 로드를 낮춤으로서 컴퓨팅 기능을 향상시킨다. 또한, 모바일 장치(104)는 BOPS 서버(102)에 등록 요청(Registration(등록))을 수행할 수 있고 인증 흐름으로부터의 "생체인식 검증(Biometric Validation)"단계가 모바일상에서 발생하도록 구성될 때 암호 일치 동작을 수행할 수 있다.

본 발명의 하나 이상의 구현예에서, 상기 BOPS 서버(102)는, 예를 들어, 등록 프로세스 동안 APHAE SOLR 저장소(repository)와 같은 공유 벡터의 적어도 일부와 함께 사용자 신원 정보를 저장한다. 게다가, 상기 BOPS 서버(102)는 인증 정보 및 프로세스 흐름을 관리하고 적어도 하나의 생체인식 서비스 통신 요소를 통합하도록 구성될 수 있다.

본 발명에 따라 아키텍처에 제공된 다른 요소들은 하나 이상의 인증 서비스 및 하나 이상의 생체인식 엔진을 포함할 수 있다. 상기 인증 서비스는 하나 이상의 인증 서비스의 버전 관리를 지원하도록 구성되는 하나 이상의 라이브러리의 동적 로딩을 수행하기 위해, BOPS 서버(102)와 인증 서비스 간의 통신을 표준화하기 위해, 및 하나 이상의 BOPS 인스턴스가 자체적으로 확장할 수 있는 별도의 클라우드를 남기거나 존재하는 웹 애플리케이션 시스템 등과 같은 하나 이상의 배치 시나리오를 제공하기 위해 구성될 수 있다.

하나 이상의 구현예에서, 생체인식 엔진은 인터페이스의 주체인 관리되지 않는 생체인식 라이브러리를 포함하도록 구성되며, BOPS-구현 시스템(BOPS-implemented system)에 플러그되도록 각각 라이브러리에 의해 정의되고 구현된다. 필요하다면 상기 생체인식 엔진은 바람직하게는 엔진을 로딩하는 "로드(Load)" 방법, 자유 자원(예를 들어, 메모리, 임시 파일)에 대한 엔진을 로딩하지 않는 “언로딩로드(UnoladLoad)”방법, 상태 정보(예를 들어, INIT_FAILED, OK, ERROR, OUT_OF_MEMORY)를 제공하는 “GetStatus”방법, 등록과정 동안 요구된 벡터를 암호화하기 위한 “분할(Split)”방법, 벡터를 인증하는 “매칭(matching)” 방법(예를 들어, 초기 벡터의 공유 부분을 기반으로 한), 엔진의 “활성/레지스터(Activate/Register)”방법 및 엔진의 설명을 제공한다. 상기 기술은, 예를 들어, 생체인식 타입 식별자(Biometric Type Identifier), 이름 및 설명, 엔진 버전 및 생체인식 포맷을 포함할 수 있다. 이 정보를 사용하여, 본 발명의 애플리케이션과 관련된 하나 이상의 프로세스가 특정 생체인식 엔진을 자동으로 로딩 및 등록할 수 있다.

하나 이상의 구현예에서, 변경 가능(인증 서비스 위치)하고 사용 가능한 시스템 및 시스템에서 라이브러리를 자동으로 로딩하고 등록할 수 있는 플러그 가능한 인증 서비스를 위한 메커니즘을 지원한다. 인증 서비스에 의해 호출되는 각 생체인식 라이브러리는 이를 설명하는 상수 문자열(생체인식 유형), 각각의 버전, 이름 및 설명과 같은 정보를 제공할 수 있다. 추가적으로, 상기 한 쌍(BiometricType, BiometricVersion)과 같은 정보는 고유한 생체인식 엔진을 식별할 수 있다.

예시 인증 서비스 및 이들의 반응 및 낮은 레벨 생체인식 엔진은 공통적으로 분배된 미국 특허 출원 번호 U.S 14/201,462, 미국 특허 출원 번호 U.S 14/201,499, 미국 특허 출원 번호 U.S. 14/988,833 및 미국 특허 출원 번호 U.S 14/819,639에 나타나고 기재된 바와 같이, 예를 들어 4F, 얼굴, 홍채 및 음성을 포함하여 시스템 레벨에서 나열되고 이용 가능할 수 있다.

본 발명에서 기재된 바와 같이, 하나 이상의 BOPS 구현예에서 발생(Genesis) 및 등록(Enrollment) 프로세스는 효과적으로 분리되어 있으며, 이는 자동화된 처리를 위해 필요하지 않는 한 생체인식 벡터, 인증서 또는 다른 비밀 정보에 대한 BOPS 서버(102) 액세스 필요 없이 주체의 신원을 결정할 수 있게 한다. 이에, BOPS 솔루션은 "개방형(open)"으로 해석될 수 있으며 발생 및 등록에서 거의 모든 사용자 정의가 가능하다. 예를 들어, 발생(Gemesis)에는 ACTIVE DIRECTORY에 액세스하기 위한 사용자 이름과 암호, 유효한 이메일 또는 문자 메시지, 신원을 실제로 확인하기 위한 기관의 담당자 등을 포함할 수 있다. 예를 들어 배치(batch)에서 발생할 수 있는, 사용자 계정의 사전 등록(Pre-registration)은 비즈니스 요구 사항을 기반으로 할 수 있다. 또한, 발생 프로세스는 리스크 관리에 전적으로 의존할 수 있으며, 나아가, 다운스트림 프로세싱(downstream processing)을 결정할 수 있다. 예시적인 포스트-발생 프로세스(post-Genesis process) 동안에, 사용자는 각각 등록된 장치에 대해 고유한 클라이언트 인증서를 발급할 수 있는 생체인식을 등록한다. 추가적으로, 클라이언트 장치(104)와 서버 장치(102) 사이에 일회용 패스워드(예를 들어, "시드(seed)")가 설정될 수 있고, 리플레이 공격 방지를 위해 추가적인 시드 값이 사용될 수 있다.

본 발명에서는 단일 사용자가 다수의 장치를 가질 수 있고 및/또는 단일 장치가 많은 사용자를 가질 수 있다(즉, 단일 장치는 많은 생체인식을 가질 수 있음). 그러므로, 다수-대-다수 관계의 한 형태는 발생 및 등록 프로세스를 분리하는 기능으로 발생할 수 있다. 이에, 발생을 통해 식별된 주체는 많은 생체인식을 통해 여러번 등록할 수 있다. 하나 이상의 BOPS 구현예에서, 상기 등록 프로세스는 서버-생성(server-generated)될 수 있는 양방향 SSL/TLS(Secure Socket Layers/Transport Layer Security) 인증서를 사용한다. 인증서가 잘-정의된 주체에 적합하다는 것을 보증하므로, 이러한 생성(generation)은 발생 프로세스 후에 발생할 수 있다.

게다가, 하나 이상의 BOPS 구현예는 다른 보안 수준에 대한 유연성을 제공하는 프로비저닝(provisioning)의 다양한 수준을 가질 수 있다. 예를 들어, 높은-수준(high-level)의 발생은 담당자(officer)와 같은 누군가에 의해 물리적으로 검증이 된 사용자를 포함한다. 대안적으로, 낮은 수준은 사용자가 수신한 적합한(validating) 이메일과 함께 사용자 이름 및 비밀번호를 정의하는 것만 포함할 수 있다. 발생 및 검증 프로세스의 다양한 수준은 하나 이상의 개별 기관에 고유하거나 특별할 수 있는 하나 이상의 비즈니스 결정의 기능으로서 구현될 수 있다. 더 나아가, 후속 프로세스는 각각의 발생 수준에 따라 변경될 수 있다. 예를 들어, 높은 수준의 발생과 관련하여 시스템에 $100만의 전송을 허용하지만 낮은 수준의 발생과 관련하여 $100의 전송만 허용한다.

본 발명에 따라, 도 11은 가능한 요구 사항 및 발생의 다양한 레벨과 관련된 예(1100)를 나타내는 블록 다이어그램이다. 검증 프로세스에서 추가적인 요구 사항이 필요하기 때문에, 상기 각각의 보안 수준이 이에 부응하여 증가할 수 있다. 도 11의 예시 레벨에서, 구조적 고려 사항에 기초하여 1차 및 2차 레벨을 교환할 수 있다. 예를 들어, 비즈니스 방문자에게 Wi-Fi 액세스를 확인하고 제공하는 것이 목표인 경우, 모바일 장치를 통해 확인을 보낼 수 있으며, 본 발명에서는 낮은 확인 레벨로 고려된다.

등록 과정(Enrollment phase) 동안, 예를 들어 모바일 컴퓨팅 장치(104)상에서, 실행중인 모바일 애플리케이션은 각각의 빌트-인 능력(built-in capabilities)에 기초하여 생체인식을 등록한다. 예를 들어, 모바일 애플리케이션은 특정 통합(integration)을 위해 구축했고, 디폴트(default) 생체인식을 필요로 하는 애플리케이션은 애플리케이션에서 특별히 하드코드된(hardcoded) 모듈을 가질 수 있다.

하나 이상의 BOPS 구현예는 생체인식 인증 트랜잭션(transaction)의 속도를 해결하고 모바일 장치에서 가상화된 위협의 문제를 해결한다. 이러한 위협의 예시는 침입자(intruder)가 모바일 장치의 복사된 가상 이미지에서 코드를 디컴파일(decompile)하고, 이 소스 코드를 사용하여 인증 호출을 정지하고, 권한을 인증 및 허가하는 서버의 제어를 시도하는 것이다.

이러한 위험을 줄이기 위해, BOPS 구현예에서 상기 프로세스는 암호 키 없이 초기 생체인식 값(initial biometric value, IBV)을 암호화한 다음, 상기 IBV의 절반을 클라이언트 장치(104)에 저장하고 나머지 절반은 상기 서버(102)에 저장하거나 서버(102)에 의해 액세스 가능하게 한다. 상기 생체인식 매칭은 상기 서버(102)에서 발생할 수 있다. 도 12는 등록 및 인증 프로세스 동안 초기 생체인식 벡터("IBV")와 관련된 정보(1200)의 예시적인 흐름을 나타낸다. 도 12에 나타난 예시적인 흐름에서, 등록하는 동안에 상기 IBV는 캡쳐 및 분할되고, 상기 IBV의 일부분(예를 들어, 절반)이 상기 클라이언트 장치(104)에 저장된다. IBV의 일부분(예를 들어, 절반 또는 1/2)은 BOPS 서버(102)에 등록 요청으로 전송되고, 그 부분은, 예를 들어, 상기 BOPS 서버(102)에 의해 액세스 가능한 데이터 저장소에 저장된다. 그 후에, 등록 확인은 BOPS 서버(102)에 의해 전송된다.

계속해서 도 12를 참조하여, 후속 생체인식 인증 프로세스 동안 현재의 생체인식 벡터(current biometric vector, CBV)가 캡쳐되고, 남은 부분(2/2)을 포함하는 인증("Auth") 요청과 관련하여 상기 BOPS 서버(102)에 전송된다. 상기 BOPS 서버(102)는 인증 요청에서 IBV의 수신된 부분을 결합하고, 해독하기 위해 상기 IBV의 저장된 부분을 결합한다. 상기 수신된 CBV는 플레인텍스트 전체 IBV와 비교되고, 비교하는 동안의 결정의 기능으로서, 숫자(예를 들어, 플로팅 숫자(floating number))가 클라이언트 컴퓨팅 장치(104)로 반송된다. 일치하는 항목이 있으면, 상기 사용자를 인증된 것으로 등록할 수 있다. 추가적으로, 인증 프로세스의 결과는 상기 클라이언트 컴퓨팅 장치(104) 상에 디스플레이 될 수 있다.

그러므로, 도 12에 나타나고 본 발명에 기재된 단계들에 나타난 바와 같이, 본 발명에 따른 BOPS 구현예는 생체인식 인증 트랜잭션의 속도를 해결하고 클라이언트 장치상의 가상화된 위협과 관련된 문제들을 해결한다. 이러한 위협은, 예를 들어, 모바일 장치의, 복사된 가상 이미지에서 소프트웨어를 디컴파일한 다음, 상기 소스 코드를 사용하여 인증 호출을 중지하고, 인증 및 승인하는 서버를 제어를 시도한 후에 발생할 수 있다.

이러한 위험을 줄이기 위해, BOPS 구현예과와 관련된 특성은 암호 키 없이 상기 IBV를 암호화하고, 클라이언트 장치에 IBV의 일부(예: 절반)를 저장하고 서버 또는 이에 접근 가능한 장치에 일부(예: 나머지 절반)를 저장할 수 있다. 생체인식 매칭은 상기 서버에서 발생할 수 있다. 이러한 방식으로, 적어도 손상된 장치 또는 서버가 공격자에게 유용한 정보를 제공하지 않기 때문에 도난당한 장치는 인증을 우회할 수 없다.

하나 이상의 구현예에 따르면, 하기는 하나 이상의 BOPS 구현예에서 생체인식 인증에 대한 프로세스 동의를 설정하는 것을 제공한다. 생체인식 벡터는 최소한 클라이언트와 서버 사이에 분할되며, 인증에 대한 접근은 생체인식 애그노스틱(agnostic) 이다. 예를 들어, 얼굴 인식과 관련하여, 초기 생체인식 벡터의 크기는 약 20KB가 될 수 있으며, 이는 HTTP-요청 및 HTTP-응답의 업/다운에 의해 최소화될 수 있으므로 받아들여진다. 얼굴 인식과 관련하여 IBV를 위한 분할 알고리즘은 다음과 같을 수 있다: 0 비트는 흰색이고 1 비트는 검정색이다. 이에, BOPS 구현예는 시각적 암호(Visual Cryptography, VC)와 일치할 수 있다. 본 발명에 기재된 바와 같이, 본 발명은 사실상 임의의 생체인식과 함께 사용될 수 있고, IBV를 취하여 VC로 암호화하는 메커니즘을 제공한다. VC를 사용하면, 상기 매칭 항목이 플레인텍스트로 발생한다. 그 대신에 랜덤을 사용하면, 암호화된 도메인에서 상기 매칭이 일어난다.

도 12를 참조하면, 클라이언트 컴퓨팅 장치(104)를 동작시키는 사용자는 생체인식 등록(1)을 진행하고, 초기 생체인식 벡터(IBV)(2)를 캡쳐한다. (3) 단계에서, 상기 IBV는 암호화 및 분할되고, IBV의 2/2는 클라이언트 컴퓨팅 장치(104)(4) 상에 또는 클라이언트 컴퓨팅 장치(104)와 함께 국부적으로 저장되고, IBV의 1/2을 포함하는 등록 요청이 전송 계층(양방향 SSL/TLS를 통해)(5)을 통해 BOPS 서버(102)에 전송된다. 상기 1/2 IBV는 BOPS 빅데이터(6)와 같은 BOPS 서버(102)에 의해 저장되고, 등록 확인은 상기 BOPS 서버(102)로부터 클라이언트 컴퓨팅 장치(104)(7)로 다시 전송된다.

계속해서 도 12를 참조하면, 등록 후에, 클라이언트 컴퓨팅 장치(104)(8)에서 생체인식 인증이 발생하고, 현재 생체인식 벡터가 캡처된다(9). 그 후에, BOPS 서버(102)에 의해 수신되는 전송 계층(10)을 통해 인증 요청이 전송되고, 2/2 IBV와 결합되어 해독(11)에 사용된다. 그 후에, 상기 CBV는 플레인텍스트 IBV(12)와 비교되고 플로팅(floating) 숫자는 클라이언트(104)(14)로 다시 전송되고, 결과가 디스플레이 된다(15).

이제 도 13을 참조하면, 본 발명의 애플리케이션과 관련하여 구현되는 시각적 암호화(VC) 예시(1300)가 나타난다. VC는 키 관리에 대한 요구 사항 없이 IBV를 복원(reconstruction) 및 IBV를 분할하는 암호와 함께 우수한 시너지 효과를 제공한다. 도 13에 나타난 시각적 암호화 예시에서, 검정색은 1일 수 있고, 백색은 0일 수 있다. 이 예시에서, 상기 IBV는 00100110과 같다. 상기 솔루션이 불린(Boolean)이기 때문에 XOR 재구성을 사용할 수 있다. 원래의 생체인식 벡터 암호화 프로세스는 시각적인 암호화를 사용하여 수행할 수 있으며, 그 결과는 흰색 노이즈만 포함하는 시트(sheet)로 기록되는 두 개의 벡터가 될 수 있다. 모바일 저장 장치(예를 들어, 클라이언트 장치(104))는 시트들 중 하나를 포함하고 상기 서버 장치(102)는 다른 하나를 포함하거나 액세스한다. 상기 검증 프로세스는 원래의 생체인식 벡터가 완전히 재구성되도록 하는 간단한 불린 동작(Boolean operation)을 사용하여 상기 두 시트를 결합한다.

XOR 동작과 관련하여 IBV의 재구성 예시는 하기 표 1에 기재되어 있다.

표 1을 참조하고 예시 BOPS 구현예과와 관련하여, 상기 원래의 생체인식 벡터 암호 프로세스는 시각적 암호화를 사용하여 수행할 수 있으며, 이 암호화의 결과는 흰색 노이즈만 포함하는 시트로 표시된 두 벡터이다. 본 발명에서 기재된 바와 같이, 상기 클라이언트 장치(104)와 연관된 저장 장치는 시트들 중 하나를 포함하고 상기 서버 장치(102)와 관련된 저장 장치는 다른 하나를 포함한다. 상기 검증 프로세스는 간단한 불린 동작을 사용하여 상기 두 시트를 결합하고 원래의 생체인식 벡터가 완전히 재구성 되도록한다.

도 14는 각각의 비트가 예시적인 BOPS 구현예과와 관련하여 공유로 암호화되는 시각적 암호화 기법(Visual Cryptography Scheme, VCS)에서 2 개 공유(2,2)의 예시적인 중첩을 나타낸다. 도 14에 나타난 예시에서, 0 및 1 비트에 대한 공유의 선택은 랜덤 프로세스이다. 0 또는 1 비트를 인코딩 할 때, 값은 한개 공유에 대한 표에서 가져오고 다른 공유에 대한 표에서 인접한 값을 가져온다. 프로세스가 끝나면, 공유는 원래 비트에 대한 단서를 제공하지 않는다. 상기 두 공유(OR 또는 XOR을 사용하는)를 중첩하면 원래 비트의 값이 결정된다.

계속해서 도 14에 나타난 예를 참조하면, 2 개 공유(2,2)의 중첩은 각각의 비트가 공유로 암호화되는 시각적 암호화 기법(VCS)으로 나타난다. 0과 1 비트에 대한 공유의 선택은 랜덤 프로세스에서 구현 될 수 있음을 기록한다. 0 또는 1 비트를 인코딩 할 때, 값은 하나의 공유에 대한 표(예를 들어, 표 1)로부터 얻고 다른 공유에 대한 표 내의 인접 값을 얻는다. 프로세스가 끝나면, 공유는 원래 비트에 대한 단서를 제공하지 않는다. 그 후에, 예를 들어, OR 또는 XOR을 사용하는 두 공유를 중첩하여 원래 비트의 값을 결정한다. 이것은(2,2) VCS의 예시이다. VCS는 랜덤 프로세스 확률을 변경하여 두 개 이상의 공유로 확장할 수 있다. 랜덤 프로세스의 확률을 0.5에서 0.25로 변경하면 공유가 0.5 예시에서 2 비트 대신 4 비트를 갖는다. 추가적으로, 상기 랜덤 프로세스의 확률을 0.125로 변경하면 각 입력 비트에 대해 8 비트의 암호화가 발생한다.

매칭을 검출하는 것과 관련하여, 예시적인 BOPS 구현예에서 하나 이상의 모듈은 다수의 초기 생체인식 벡터를 사용한다. SSL/TLS를 통해 통신하는 두 가지 RESTful 웹 서비스 호출은 각각 생체인식에 하나씩 있다. 하나의 호출은 인증 세션의 현재 생체인식뿐만 아니라 IBV의 절반을 포함할 수 있으며, 일치의 강도를 나타내는 플로팅 지점(floating value) 값을 반환할 수 있다. 또 다른 호출은 한 번에 하나의 IBV(절반)와 현재 생체인식을 제공하고, 매칭의 강도를 나타내는 플로팅 지점 값을 반환할 수 있다. 두 번째 호출의 경우, 여러 차례 연속 호출이 가능하다: 예를 들어, 한 번에 하나의 IBV만 일치하는 것으로 결정.

예시 BOPS 구현예와 관련된 매칭 동의(matching agreement)마다 사이징 계산은 다음과 같을 수 있다: 얼굴 벡터 당 20kb; 초당 5 프레임; 10 초 동안 = 50 벡터; 50x20kb = 1000kb.

상기-식별된 구현예와 관련하여 로지스틱스(logistics)를 매칭시키는 예를 다음과 같이 설명한다. 매칭을 위해 상기 1000KB가 서버로 전송된다. 매칭되는 것이 없으면, 2차 100KB가 전송되고, 플로팅 지점 값이 결정될 때까지 지속된다. 하나 이상의 BOPS 구현예에서, 최소 임계값이 정의되고 상기 플로팅 지점 값은 적어도 최소 임계값 내에 있다. 예시적인 매칭 알고리즘에 따르면, 상기 현재 프레임은 서버에 대한 200 밀리초 플러스 125 밀리초 위/아래 시간을 필요로 한다. 그러므로 상기 프레임 전송은 트랜잭션 속도를 프레임 당 325 밀리초 플러스 매칭을 가져온다. 상기 매칭은 100 밀리초에서 상한값이 되면, 상기 프레임 전송은 대략 425 밀리초이다. 실패한 경우에는, 배치 프레임(batch frame)(예를 들어, 한번에 5 개)이 전송될 수 있고, 매칭이 다시 시도될 수 있다. 바람직하게는, 매칭은 초 단위보다 적은 시간내에 수행되고, 비록 덜 바람직한 경우라 할지라도, 매칭이 초 단위와 같이 더 길어질 수 있다.

본 발명에 나타나고 기재된 바와 같이, 본 발명의 유연하고 인증자(authenticator) 및 생체인식 특성은 기관이 인증을 위해 사용 가능하고 디폴트 생체인식으로서 정의될 수 있는 각각의 인증자 및 생체인식을 정의 할 수 있다. 다운 스트림 트랜잭션의 일부로서 생체인식 사양이 없으면, 상기 디폴트 생체인식은 기관 수준, 그룹 사용자 수준 또는 트랜잭션 수준과 같은 하나 이상의 사용자 인터페이스를 통해 구체화될 수 있다.

하나 이상의 구현예에서, 관리 콘솔은 그래픽 사용자 인터페이스로 구성될 수 있고 각 권한이 부여된 사용자가 액세스할 수 있다. 상기 관리 콘솔에는 그래픽 컨트롤이 포함될 수 있고, 그래픽 컨트롤을 선택하면 디폴트 생체인식 유형을 구성한다. 예를 들어, 기관, ACME 플럼빙(ACME Plumbing)은 특정 액세스의 경우 ACME의 모든 직원에 대해 상기 디폴트 생체인식에 얼굴을 사용하도록 지정한다. 그러므로, ACME 플럼빙은 다른 상황(context)에서 4개 손가락이 모든 고객을 위한 생체인식에 사용되는 것으로 지정할 수 있으며, 또 다른 상황에서는 $10,000의 초과하는 거래에 4개 손가락과 얼굴 모두를 사용하는 것으로 지정할 수 있다. 이러한 옵션은 ACME 플럼빙 관리자가 정의할 수 있는 관리 콘솔에 표시된다. 그러므로, 본 출원은 하나 이상의 생체인식의 유연하고 역동적인 적용을 제공한다.

인증과 관련하여, 생체인식을 위한 정보의 복수의 소스는 특정 기관 구성에 다음과 같은 것들이 사용될 수 있다. 예를 들어, 조건 엔진; 회원 프로필; 및 회원 정의(definition). 상기 조건 엔진은 시스템에 정의된 동적 규칙을 기반으로 할 수 있다. 예를 들어, $1K 이상의 거래는 적어도 두 가지 형태의 생체인식이 필요하다. 상기 구성원 프로필은 사용자 역할 및 해당 권한을 규정한다. 예를 들어, 구성원 프로필 "정보 보안-첫 번째 응답자"는 매 10 분마다 또는 모든 커밋 트랜잭션(commit transaction)과 같은 다른 조건마다 인증을 요구할 수 있다. 상기 구성원 정의는 기관/통합 레벨에서 디폴트 인증을 정의할 수 있다. 예를 들어, 4F, 얼굴, 홍체 등 4 가지 유형의 생체인식 시스템이 있고 특정 BOPS/엔터프라이스(Enterprise) 구현예의 경우 상기 디폴트 생체인식이 "얼굴(FACE)"인 경우 얼굴 인증을 기본값으로 사용 가능하고, 예를 들어, 그래픽 사용자 인터페이스를 통해 제공된 대시 보드에 제공되며 본 발명에서, 일반적으로 BOPS 관리자 대시보드(BOPS Admin Dashboard)로 언급된 것과 같이 제공될 수 있다. 게다가, 상기 기재된 바와 같은 각 조건은 우선 순위를 나타낼 수 있다. 예를 들어, 상기 구성원 정의는 가장 낮은 우선 순위로 고려될 수 있고, 상기 조건 엔진은 가장 높은 것으로 고려될 수 있다. 상기 가장 높은 우선 순위가 인증 방법이 된다.

하기는 본 발명에 따른 등록 프로세스와 관련된 예시적인 단계들을 나타낸다. 모바일 클라이언트 애플리케이션으로 구성된 모바일 컴퓨팅 장치(104)는 생체인식 벡터를 획득하고, 암호화를 수행한 다음 등록 API 호출을 한다. 특히, 생체인식을 획득한 후, BOPS 서버(102)에 대한 등록 호출은 서버(102)에 의한 액세스를 위해 저장되는 IBV의 절반을 포함한다. 상기 등록 프로세스는 기관 내에서 BOPS 구현예를 시작하는 데 사용될 수 있다. 본 발명에 기재된 많은 설명 및 도면은 클러스터로 표시되는 BOPS 구현예를 나타냄에도 불구하고, BOPS는 비즈니스 구성성분으로서 구성되는 것으로 고려된다. BOPS 관리자("BOPS 관리자(BOPS admin)")가 환경을 설정하기 전에, 기관은 BOPS 서버(102)로부터 각각의 API 키를 등록한다. 상기 개별적인 개발자는, 다양한 구현예에서, 상기 API 키를 적용할 수 있다.

등록 프로세스의 완료에 따라, 원래 사이트 관리자("원본 사이트 관리자(original site admin)")가 추가적인 사이트 관리자("사이트 관리자(site admin)")를 만들 수 있다. 다양한 사이트 관리자와 관련된 등록 정보는 기관과 관련된 각각의 API 키와 관련될 수 있다. 하나 이상의 구현예에서, 상기 API 등록은 다음의 두 도메인에 적용될 수 있다: 상기 등록된 원본 사이트 관리자; 및 등록 정보, 상기 기관 및 상기 사용 사례에 기반할 수 있는 상기 발급된(issued) API 키. 애플리케이션 시작을 동의한 후에, 상기 등록 프로세스가 완료된다. 그 후에, BOPS 관리자는 기관에 대한 원래의 사이트 관리자를 생성하고, 상기 원래의 사이트 관리자는 사이트 관리자를 생성할 수 있다(예를 들어, 도 15에 나타난 역할 계층 차트(roles hierarchy chart) 참조).

BOPS 서비스를 활용하는 개발 프로세스 전에 개발자는, 예를 들어, BOPS 관리 콘솔에 옵션을 사용하여 등록하는 것이 바람직하다. 애플리케이션 이름을 제공하고 개발자를 식별하기 위해 질문-중심 식별 메커니즘(question-oriented identification)을 사용함으로써, 새 계정을 만들 수 있고 API 키를 만들 수 있으며, 이는 상기 애플리케이션 이름으로 식별되고 상기 애플리케이션과 관련된다.

하나 이상의 BOPS 구현예서, 클라이언트 장치(104)상에서 작동하는 애플리케이션과 상기 BOPS 서버(102) 사이의 통신은 양방향 SSL/TLS의 최상위에 설정된다. 상기 발생(Genesis) 프로세스는 이러한 연결을 설정하고 사용자가 BOPS 서버(102)에 자신을 식별하는 방법을 지정하고, 상기 서버(102)가 양방향 SSL/TLS 통신을 설정하기 위해 개인 키를 생성할 수 있다. 보안 질문을 제공하는 것은 사용자가 자신을 식별할 수 있는 하나의 메커니즘이며, 이는 공리적 접근법(axiomatic approach)이며 “발생(Genesis)”단계 동안에 개인을 고유하게 설명하는 일련의 질문을 제공할 수 있다.

사용자 컴퓨팅 장치(104)에서 작동하는 상기 클라이언트 애플리케이션은 최종 사용자의 장치(104)를 식별하는 고유 식별자(identifier, ID)를 제공하는 역할을 한다. 상기 애플리케이션은 사용자 및 사용자 장치(104) 사이의 링크에 대해 BOPS 서버(102)에 통지하기 위한 장치(104) 및 관련된 API를 사용할 수 있다. 5- 튜플은 장치(104)를 식별하는데 사용될 수 있는 하나의 메커니즘이다.

하나 이상의 BOPS 구현예에서, 각각의 RESTful 호출 및/또는 공격 및 공격 벡터를 무력화시키는 시스템을 사용할 수 있는 행동이 지정된다. 추가적으로, 알려진 공격 및 알려지지 않은 공격으로부터 실시간으로 데이터를 보호하기 위한 요청 형식이 지정되며, IDS(예를 들어, 장치(112_를 통해)에 존재할 수 있다. 예를 들어, 액세스를 확인하기 위한 암호화 일회용 토큰에서 리플레이 완화(mitigation)를 사용할 수 있다. 이러한 경우에, 상기 IDS는 클라이언트(104)와 서버(102)가 서로를 인식하므로, 상기 서버(102)가 애플리케이션 계층에서 완전히 보호되는지를 확인하는 제3 티어(tier)이다.

도 16은 리플레이 방지와 관련한 장치들 및 전송 흐름을 나타내는 블록 다이어그램(1600)이다. 도 16에 나타난 바와 같이, 암호화 일회용 토큰은 애플리케이션 계층에서 리플레이, DDoS(destributed denial of service) 및 다른 공격을 포함하는 국제표준기관(International Standards Organization, ISO) 계층 7 사이버 공격(cyberattacks)으로부터 액세스를 확인하고 서버를 보호한다. 상기 토큰과 상기 IDS의 결합은 리플레이, DDoS 및 유사한 공격을 포함하는 ISO 계층 7 사이버 공격을 탐지하는 데 유용하다. 상기 토큰은 하나의 사용에 유효하며 보통 클라이언트(104)로부터 서버(102)로 전달된 다음, RESTful 호출을 사용하여 BOPS에 반환된다.

하나 이상의 BOPS 구현예에서의 전제는, DDoS 탐지를 위해 모든 토큰이 구별 되어야 한다는 것과, 클라이언트와 서버 사이에 사용되는 적어도 하나의 알고리즘은 시간이 다를 수 있으며, 액세스에서 액세스까지 뿐만 아니라 클라이언트에서 클라이언트까지 값이 달라야 한다는 것을 고려해야 한다는 것이다. 도 17은 예시적인 BOPS 구현예에 따른 토큰의 알고리즘과 관련된 단계들(1700)을 설명하는 높은 레벨 흐름을 나타낸 것이다. 한 단계(1702)에서, 상기 발생 단계 동안 웹, 모바일 또는 내장된(embedded) 장치(클라이언트 장치 104))는 토큰을 요청하기 위해 RESTful 호출을 발행한다. 그 다음, 상기 토큰은 클라이언트(104)에서 서버(102)로 암호화 된 메시지에 수신되고 내장된다(1704). 상기 서버(102)는 토큰을 수신하고 토큰을 IDS에 전달함으로써 메시지의 유효성을 검사하며(1706), 토큰이 유효한지를 확인하고 생성 시간과 현재 시간 간의 차이가 지정된 60 초 내에 있는지를 확인한다(1708).

도 18은 다수-대-다수 관계에 있는 발생/등록 및 사용자/장치의 제품을 나타낸다. 모바일 클라이언트(104)에는 각 계정과 링크된 신원(identity) 요소가 나타난다. 도 18의 서버 측에서, 상기 BOPS 서버(102)는 각각의 신원에 대한 연관성에서 신원 속성, 계정 및 장치와 관련된 것으로서 나타내었다. 높은 수준의 보증으로 데이터 암호화 및 클라이언트/서버 통신 보안을 수행하기 위해, 신원 정보는 사용자 계정(예를 들어, 도 18에 나타난 앨리스 또는 밥의 계정들)이 해당 신원에 대한 기능으로서 적절히 인증되는 보안 요소들과 관련되어 있다.

상기 발생 단계를 개시하기 위해, 상기 클라이언트 장치(104)는 하기 표 2에 나타낸 각각의 값 중 임의의 또는 모두를 지정함으로써 5 개의 튜플을 확립하도록 선택할 수 있다. 상기 IDS는 클라이언트로 설정되지 않은 임의의 다섯 가지 값을 결정할 수 있으며, RESTful 형식으로 클라이언트에 토큰을 반환할 수 있다. 상기 클라이언트(104) 및 서버(102)는 동일한 5 개의 튜플을 공유하며, 이는 차례로 SHA512 인코딩되고 IDS 또는 BOPS 서버(102)에 의해 비교되는 타임 스탬프(timestamp)를 계산하는데 사용된다. 상기 계산된 타임 스탬프는 5 개의 튜플을 기반으로 한 시간으로 되돌아가며, 각 호출마다 고유하다.

이에, 하나 이상의 구현예에서 상기 토큰의 모든 값은 비교를 위해 SHA512 합계로 변환되므로, 상기 토큰에는 타임스탬프 자체가 포함되지 않는다. 이는 상기 값을 블라인드 리플레이(Blind replay)을 방지하기 위해 매분마다 변경할 수 있다. 게다가, 상기 토큰의 분 범위(minute range)는 충분히 큰 엔트로피(48,771,072)를 허용하기 위해 3 회(60 회가 아닌)로 구성할 수 있으므로, 시행 착오 공격(trial and erreor attacks)을 예방할 수 있다.

추가적으로, 시맨틱 엔진(semantic engine)은, 보안 관리자가 어떠한 국제 표준에서도 벗어날 수 있는 공격 검출 및 방어를 위한 추가적인 사용자 지정(custom) 파라미터들을 생성할 수 있도록 구성될 수 있고, 다양한 종류의 공격에 대한 추가적인 체크와 균형을 제공할 수 있다.

하나 이상의 구현예에서, 리플레이 검출은 5 개 튜플로 이루어진다. 상기 표 1에 나타낸 것과 같은 값들은 상기 서버(102)에 제공될 수 있다. 대안적으로, 상기 서버(102)는 값을 임의적으로 선택할 수 있다. 리플레이에 따라, 허용 가능한 범위의 값 및 상기 엔트로피가 초기에 결정된다. 상기 발생 단계 동안에 다섯 개의 튜플 값이 지정되지 않으면. 상기 알고리즘은 하기의 값을 사용할 수 있다.

예시적인 구현예에 따르면, 역방향으로 회전하는 알고리즘을 실행한다. 해당 달이 현재 달보다 작거나 같으면, 해당 연도가 동일할 수 있다. 대안적으로, 상기 월이 현재 달보다 크면, 연도를 다시 회전해야 한다. 이 두 가지 경우는 상기 알고리즘을 설명한다.

예1의 현재 월이 8 월이고 월의 발생 값이 11 및 11> 8이기 때문에, 우리는 5의 범위에서 연도의 범위를 지정하면 그 해는 2011이 된다. 그 나머지 값은 실제 날짜 값보다 작은 발생의 배수이다.

동일한 현재 날짜 및 시간을 사용하는 두 번째 예와 관련하여 현재 달은 8 월이고 월의 발생 값은 4 및 4 <= 8이다. 상기 연도는 2015와 동등한 5의 간격으로 범위를 지정한다. 그러므로 상기 연도는 2015년이 되며 그 나머지 값은 실제 날짜 값보다 작은 발생의 배수이다

하나 이상의 BOPS 구현예에서, 데이터 프라이버시의 다양한 수준이 제공될 수 있고, 생체인식 정보를 재설정 및/또는 타협을 못하게 하기 위하여 각각 암호화된 생체인식 정보를 포함할 수 있다. 하나의 프라이버시 레벨은 모든 비-생체인식 데이터가 플레인텍스트에 저장(패시베이션)되는 것으로 정의할 수 있다. 이는 사용 패턴 및 인증 기록의 보고 및 분석을 단순화하고, 부인 방지, 위치, 날짜 및 패싯 검색(faceted search)과 같은 다른 요소를 포함할 수 있다. 예를 들어, 상대적으로 용이하게 2016년 6월에 클리블랜드에서 실패한 인증 시도 횟수를 볼 수 있으며, 개인 및 장치와 관련된 정보를 제공할 수 있다. 이 첫 번째 프라이버시 수준은 플레인텍스트 패시베이션 데이터(passivated data)에서 작동하는 정교한 도구의 기능으로 수행할 수 있다. 또 다른 및 높은 프라이버시 수준은 모든 비-생체인식 데이터가 암호화된 포맷에 저장되지만 클라이언트마다 별도의 독해 키가 필요하지 않은 것을 정의할 수 있다. 그러므로, 클라이언트 장치(104)는 동일한 해독 키를 사용하도록 구성될 수 있으며, 이는 내부자가 독해 키에 대한 액세스를 갖지 않거나, 또는 대부분 갖지 않을 수도 있다는 점에서 전술한 프라이버시의 첫 번째 수준보다 안전하다고 여겨진다. 그러나 더 높은 수준의 프라이버시는 모든 비-생체인식 데이터가 암호화된 형식으로 저장되고 해독 키가 각 신원별로 고유하다는 것을 요구할 수 있다. 이는 각 사용자의 데이터가 생체인식과 관련된 키로 암호화되므로, 프라이버시 및 분리가 향상된다. 높은 수준의 프라이버시에서, 예를 들어, 개인 식별 가능 정보(personally identifiable information, PII)를 포함하는 사용자 데이터는 클라이언트 장치(104) 상에서 메모리 내에서 일치가 발생하는 순간을 제외하고 항상 암호화된다. 하나 이상의 BOPS 구현예에서, 사용자는 트랜잭션을 허가하기 위해 인증하고 사용자 데이터(예를 들어, 로그인 자격 증명, 파일 등)를 해독하기 위해 인증한다. 게다가 휴면 데이터(예를 들어, 패시베이션된 데이터)는 모든 시간에서 상기 서버 컴퓨팅 장치(102) 및 상기 클라이언트 장치(104) 상에서 암호화 된다. 플레인텍스트 데이터는 바람직하게 매치 프로세스가 발생하고 있을 때 메모리에만 존재한다.

하나 이상의 BOPS 구현예에서, 개방형 플랫폼(open platform)은 발생 흐름에 대하여 사실상 허용 가능한 모든 사용자 정의를 제공한다. 발생의 몇 가지 예는 사용자 이름과 비밀번호를 사용하여 ACTIVE DIRECTORY에 대한 액세스, 유효한 이메일 또는 문자 메시지를 포함할 수 있거나, 운전 면허증, 출생 증명서, 여권, 사회 보장 번호 또는 다른 적절한 자격증과 같은 개인의 신원을 물리적으로 확인할 수 있다.

사용자 계정의 사전-등록(pre-registration)은 비즈니스 규칙을 구현하는 배치 프로세스에서 발생할 수 있으며 기관 정책 및 절차는 이러한 비즈니스 규칙에 기여할 수 있다. 비즈니스 규칙은 액세스 관리 플랫폼과 통합될 수 있고, 이는 특권 및 다른 속성들의 수준을 결정하는 그룹들 또는 디렉토리들로 사용자를 조직화 하여 역할 관리에서 몇몇 특정 요구들을 충족시킬 수 있을 것이다. 이는 개발자가 BOPS 서버(102)에 의해 액세스되는 멤버 정의의 입력으로서 적용될 수 있는 멤버 프로필(예를 들어, 사용자 프로필, 관리자 프로필 및 슈퍼 관리자 프로필)의 공식(formulation)을 구성하는 것을 허용하는 유연성을 제공한다. 본 발명에 따른 발생 프로세스는 위험 관리에 대한 완전한 의존성을 형성할 수 있고, 이에 다운 스트림 프로세싱을 결정할 수 있다.

도 19a는 단일 클라이언트 장치(104)에서 등록을 개시하는 다수의 사용자와 관련된 장치 및 단계(1900)를 나타낸다. 사용자와 장치(104) 사이의 관계는 "다수-대-다수(many-to-many)"(M : M)일 수 있다. 첫 번째 등록 단계(A1, 생체인식 등록 시작, A2 등록 요청(x, 509), A3 반환 등록 요구 사항, A4 계정 등록 요청(개발자 ID(dev ID), 사용자 ID(user ID) + 1/2 IBV), A5 반환 등록)를 추가할 수 있다. 이러한 단계는 두 번째 사용자(B1-B5)에 대해 반복할 수 있다. 발생(Genetics)과 등록(Enrollment)의 분리의 기능으로서 다수-대-다수 관계가 발생할 수 있다. 게다가, 발생을 통해 확인된 주체는 많은 생체인식으로 여러번 등록할 수 있다. 클라이언트/서버 통신을 개시하기 위하여, 사용자는 클라이언트 장치에서 그 또는 그녀의 생체인식 정보를 캡쳐하고, 이를 클라이언트 장치를 위해 발행된 독특한 클라이언트 인증서의 동작 등록 프로세스로 가져간다. 등록의 보안 부분이 완료되면, 사용자의 생체인식 정보 등록이 이루어져 등록 프로세스가 완료된다. 사용자는 많은 장치(클라이언트)를 가질 수 있고, 장치(클라이언트)는 많은 사용자를 가질 수 있다. 장치(클라이언트)는 많은 생체인식을 지원할 수 있다.

도 19b는 다수의 사용자 계정들에 관한 정보를 저장하는 클라이언트 장치(104)로부터 인증 세션을 개시하는 것, 예시적인 사용자 앨리스(Alice)와 관련된 장치들 및 단계들(1910)을 나타낸다. 도 19b에 나타난 예에서, 앨리스는 인증 세션을 시작하고(1), 클라이언트 장치(104)에서 작동하는 애플리케이션은 생체인식 인증을 요청한다(2). 생체인식 인증이 완료된 후(3), 클라이언트 장치(104)상에서 작동하는 애플리케이션은 장치(104)가 TLS를 통해 앨리스의 신원 속성을 전송하도록 구성한다(4) 그 후에, 상기 BOPS 서버(102)는 모든 등록 요소의 무결성(integrity)을 고려하여 인증 요청을 처리하고 그 결과를 반송한다(5).

도 19b에 나타난 예를 참조하면, 앨리스가 밥(Bob)의 계정을 사용하여 인증 세션을 실수로 개시하는 경우에도, 상기 클라이언트 장치(104)는 CBV가 등록과정 동안 생성된 IBV와 상이하기 때문에, 서버에 어떠한 요청도 전송하지 않고, 인증은 성공하지 못한다.

도 19c는 사용자 계정의 폐지와 관련된 예시적인 장치 및 단계(1920)를 나타낸다. 도 19c에 나타난 예에서, 3 명의 사용자(이브(Eve), 밥(Bob) 및 앨리스(Alice))와 관련된 정보가 나타나있다. 하나 이상의 폐지 규칙은 관리 그래픽 사용자 인터페이스로 구성된 관리자 콘솔을 통해, 사용자가 정의할 수 있다. 관리자와 관련된 역할(비슷한 생체인식 인증을 받을 수 있는 사람)은 규칙을 시행할 책임이 있다. 도 19c에 나타난 예에서, 앨리스의 계정은 활성 인증서를 가지고 있고, 밥의 계정은 전송 보안 레벨(Transport Security Level)에서 차단된 만료된 인증서를 가지고 있고, 이브의 계정은 BOPS 관리자에 의해 폐지되었다. 특히, 이브의 인증서가 BOPS 서버(102)(1)를 통해 폐지된 후에, 이브의 계정(2)과 연관된 클라이언트 장치(104)로부터 인증 요청을 수신한다. 상기 BOPS 서버(102)는 이브의 액세스가 차단되었음을 나타내는 메시지 또는 다른 적절한 컨텐츠를 제시한다(3). 밥의 인증서와 관련하여, 밥의 인증서가 만료된("TTL") 후, 90일 기간이 정의된다(4). 그 후에, 밥의 계정과 연관된 클라이언트 장치(104)로부터 인증 요구를 수신하고(5), 이브의 경우와 유사하게, 밥의 액세스가 차단되었다는 것을 나타내는 메시지 또는 다른 적절한 콘텐츠가 BOPS 서버(102)에 의해 클라이언트 장치(104)로 전송된다(6). 앨리스의 계정과 관련하여, 추가 90일(90-day period) 연장 기간을 제공하고(7), 앨리스의 계정과 연관된 클라이언트 장치(104)로부터 인증 요청을 수신한다(8). 상기 BOPS 서버(102)는 본 발명에 나타나고 기재된 것과 같이, 앨리스가 인증되었다는 인증 결과를 나타내는 메시지 또는 다른 적절한 컨텐츠를 제공한다(9).

본 명세서에 나타나고 기재된 모듈들과 관련하여 해결되는 문제들 중 하나는 리플레이 공격의 방지이다. 하나 이상의 구현예에서, DDoS 검색을 위해, 서버에 있는 프로필을 공통 이름(Common Name, CN) 필드의 신원과 연결하는 전형적인 식별자인 모든 토큰은 구별된다. 클라이언트(104)와 서버(102) 사이에서 알고리즘은 시간이 변할 수 있으며, 상기 값은 액세스에서 액세스까지 뿐만 아니라, 클라이언트(104)에서 클라이언트(104)까지 달라야 한다는 것을 의미한다.

하나 이상의 구현예에서, 인증 분포는 하기와 같이 작동한다. X.509 인증서는 클라이언트 장치(104) 상에 사전-로딩(pre-loadded)되며, 클라이언트 장치(104) 상에 설치된 어플리케이션 소프트웨어의 기능을 포함한다. 발생 프로세스 이전에, 상기 클라이언트(104)는 상기 튜플 중 임의의 것 또는 모든 것을 지정함으로써 5- 튜플 값을 확립한다(본 발명에 나타나고 기재된 바와 같이). 등록 프로세스 동안, 상기 클라이언트(104)는 BOPS 서버(102)로부터 토큰을 요청하는 RESTful 호출을 발행한다. 상기 토큰이 수신되면, 서버에 클라이언트의 암호화된 메시지가 내장된다. 상기 서버는 토큰을 수신하고 생성 시간과 현재 시간의 차이가 지정된 60 초 기간 내에 있는지 확인하여 메시지의 유효성을 검사한다. 상기 서버(102)는 5-튜플 값 중 어느 것이 누락되어 있는지를 판정하고 RESTful 포맷으로 클라이언트에 토큰을 반환한다. 상기 클라이언트(104) 및 서버(102)는 동일한 5-튜플 값을 공유하며, 이는 예를 들어 기능 분석으로서, SHA512가 인코딩되고 IDS에 의해 비교되는 타임 스탬프를 계산하는데 사용된다. 예를 들어, 본 발명에 기재된 바와 같이, 상기 계산된 타임 스탬프는 5- 튜플에 기반한 시간으로 역방향으로 이동하며, 각각의 호출마다 고유하다.

상기 애플리케이션은 유효성이 유지되는 클라이언트 인증서에 대한 시간을 설정할 수 있다(Time-to-Live 또는 TTL). 인증된 사용자의 해지된 인증서는 새 인증서로 조용히 교체될 수 있다. 그러므로, TTL은 사용자 인증을 지원하기 위해 IBV 및 CBV와 함께 작동하는 "벨트 및 서스펜더" 접근(approach)이다. 토큰 폐지는, 허가를 위한 특정 비즈니스의 니즈(needs)를 수행하기 위한 사용자의 역할 및 다른 요인들에 대해 또한 조건적일 수 있다. 예를 들어, 조건 y 및/또는 z를 충족시키지 못하는 경우와 같이, 금융 거래에 대한 인증 시도가 1 회 또는 x 회 실패한 후에 인증서를 차단할 수 있다.

도 20a는 클라이언트 장치(104)와 BOPS 서버(102) 사이의 클라이언트 인증서의 초기화, 검증 및 확인과 관련된 단계(2000)를 나타내는 간소화된 다이어그램이다. 클라이언트 서명 요청(client signing request, CSR)을 처리하는 것과 관련된 단계는 BOPS 서버(102)로 전송되는 클라이언트 장치(104) 상에 공식-개인 키 페어를 생성하는 단계, 공식 키 및 주체 명칭을 서명하는 단계(본 명세서에서 일반적으로 "소유 증명(Proof of possession)"을 수행하는 것으로 기재됨)를 포함할 수 있다. 본 발명에 기재된 대로, 상기 클라이언트는 양방향 SSL을 사용하여 등록 계정 요청을 보낸다. 증서의 주체 이름을 확인한 후에, BOPS 인증 기관(CA) 개인 키로 클라이언트 요청을 서명하고, OTP 메커니즘으로 클라이언트 인증서의 비밀번호를 생성한 후, 상기 BOPS 서버(102)는 클라이언트 인증서 비밀번호를 클라이언트 장치(104)로 반송한다. 상기 등록된 클라이언트는 인증서 서명을 확인하고 클라이언트 개인 키 및 서명된 인증서를 저장하지만 암호는 저장하지 않는 a. p12 컨테이너를 만든다. OTP 메커니즘은 각 클라이언트 요청마다 하나의 사용 비밀번호를 생성하기 때문에, 바람직하게는 비밀번호는 클라이언트 장치에 저장되지 않는다.

도 20b는 제3자 서버 및 BOPS 통합 예에서의 클라이언트 인증서 등록 프로세스(2010)를 나타낸다. 예를 들어, 도 20a에 나타난 바와 같이, 상기 CSR 프로세스는 광범위하게 설명되고 사용자 등록으로 시작한다. 도 20b에 나타난 예에서, "등록 사용자 계정"은 발생 및 등록과 관련된 단계를 기술하는데 사용되며, 계정이 신원 구성 요소를 나타내는 반면, 클라이언트 인증서는 신원 속성을 나타낸다.

도 20b에 나타난 예시적인 구현예에서, 사용자가 등록 프로세스를 시작하고 계정 등록 요청과 함께 그/그녀의 생체인식 정보를 BOPS 서버(102)에 전송한 후에, 키 페어/CSR 생성이 클라이언트(104)상에서 유발된다. 등록 프로파일 요청을 수신하면, 상기 BOPS 서버(102)는 액세스 관리 어댑터(제3자 기업에 의해 이용되는 액세스 관리 솔루션/플랫폼일 수 있음)에 덧붙여 보내고, 프로필 검증을 나타내는 도 20b에 나타나 바와 같이, 계정 로그인 확인 및 검증을 위해 제3자 서버로 연결된다. 상기 제3자 서버는 로그인 데이터의 유효성을 검증한 후에 인증 토큰을 제공한 다음, 인증 관리 어댑터에 검증 결과를 다시 전송하고, 이는 계정/프로필 등록을 완료하기 위해 인증 결과 및 인증 토큰을 BOPS 서버(102)로 되돌린다. 상기 BOPS 서버(102)는 인증 토큰을 암호화하고, 생체인식 데이터를 저장하고, BOPS CA와 함께 CSR을 서명하고, 암호화된 인증 토큰을 클라이언트 애플리케이션에 전송한다. 이는 구현예를 나타내고 생체인식 인증의 기능으로서 높은 수준의 검증을 위해, 저장소에 축적된 수십억 개의 계정을 이미 보유하고 있는 기업(예를 들어, 은행)과 통합된다.

하나 이상의 구현예에서, 빠른 응답 코드(QR 코드)는 본 발명에 나타나고 기재된 하나 이상의 모듈의 실행을 유도하는데 사용될 수 있다. 예를 들어, 비즈니스 파트너(예를 들어, 은행) 로그인 페이지는 각각의 세션 기회 식별자가 포함된 QR 코드 이미지를 표시하도록 구성할 수 있다. 클라이언트 컴퓨팅 장치(104)상에서 실행되는 MCA는 QR 코드를 스캔하기 위한 하나 또는 모듈(예를 들어, 인증 마법사)을 실행할 수 있고, 세션에 부착된 신호를 위해 세션을 등록하고, 본 발명에서 가르치는 것에 따라 상기 사용자의 생체인식으로 인증할 수 있다. 도 21은 예시적인 QR 코드 인증 흐름(2100)을 나타내며, 제3자 서버는 BOPS 서버(102)와 세션 기회를 등록하고, 이에 응답하여, 새로운 인증 세션을 위해 사용 가능한 정보는 BOPS 서버(102)에 의해 제3자 서버에 제공될 수 있고, QR 코드 내에 정보를 제공(예를 들어, 표시)할 수 있다. 상기 제3자 서버는 세션 상태 정보에 대한 하나 이상의 요청을 전송할 수 있다. 도 21에서 사용자("액터(actor)"로 지칭)는 QR 코드를 스캔하고 외부 제3자 서버에 통지할 수 있는 상기 BOPS 서버(102)에 세션을 등록한다. 본 발명에 나타나고 기재된 바와 같은 생체인식 인증에서, 제3자 서버를 포함하여 사용자 세션이 확립될 수 있다.

상기 기재된 내용은 단지 설명을 위해 제공되는 것으로서 제한적으로 이해되지 않는다. 본원에 나타나고 기재된 예시적인 실시예 및 애플리케이션을 따르지 않고 본 발명의 진정한 사상 및 범위를 벗어나지 않고, 하기 청구 범위 중 어느 하나 및 각각에 기재된 바와 같이, 본 명세서에 기재된 주제에 대해 다양한 수정 및 변경이 이루어질 수 있다.

Claims

하기 단계를 포함하는 사용자 컴퓨팅 장치와 서버 컴퓨팅 장치 사이에 보안 통신(secure communication)을 제공하는 방법:
상기 서버 컴퓨팅 장치에 의해, 분산된 클라이언트 소프트웨어 애플리케이션으로 구성된 사용자 컴퓨팅 장치로부터 수신되는 등록 요청을 처리하는 단계로서, 상기 등록 요청은 네트워크에 상기 사용자 컴퓨팅 장치를 등록 시키는데 이용 가능하며 상기 요청은 상기 사용자 컴퓨팅 장치의 사용자와 관련된 암호화된 부분적 초기 생체인식 벡터(initial biometric vector, IBV)를 포함하며, 상기 등록 요청을 처리하는 단계는 서버 컴퓨팅 장치에 의해 액세스 가능하거나 서버 컴퓨팅 장치의 일부인 비-일시적 프로세서 판독 가능 매체에 상기 암호화된 부분적 IBV를 저장하는 것을 포함하는 단계;
상기 서버 컴퓨팅 장치에 의해, 상기 사용자 컴퓨팅 장치로부터 그 다음으로 수신되고 암호화된 부분적 2차 생체인식 벡터를 포함하는 인증 요청과 상기 사용자 컴퓨팅 장치의 사용자와 관련된 인증 요청을 처리하는 단계로서, 상기 인증 요청을 처리하는 것은 하기 단계를 포함하는 단계:
상기 암호화된 부분적 초기 생체인식 벡터와 상기 암호화된 부분적 2차 생체인식 벡터의 비교를 알고리즘의 기능으로서 수행하는 단계; 및,
상기 비교를 나타내는 값을 생성하는 단계; 및
상기 비교를 나타내는 값을 상기 서버 컴퓨터 장치에 의해 상기 사용자 컴퓨팅 장치로 송신하는 단계로서, 상기 값이 최소 임계값을 넘는 경우 상기 사용자 컴퓨팅 장치는 인증되고 상기 값이 최소 임계값 아래인 경우 인증되지 않는 단계.
제1항에 있어서,
상기 서버 컴퓨팅 장치에 의해 상기 사용자 컴퓨팅 장치로, 상기 등록 요청 및 인증 요청에 포함되는 인증서를 제공하는 단계를 추가로 포함하고, 상기 인증 요청을 처리하는 단계는 인증서가 통용중이며 폐지되지 않은 것인지 결정하는 것을 포함하는 방법.
제2항에 있어서,
능동적 모니터링을 제공하고 인증서의 스푸핑(spoofing)을 방지하는 침입 탐지 시스템을 사용하는 단계를 추가로 포함하는 방법.
제3항에 있어서,
상기 방지된 스푸핑은 상기 인증서를 리플레이(replay)하는 것을 포함하는 방법.
제1항에 있어서,
상기 인증 요청을 처리하는 단계는 단방향 암호화의 기능으로서 암호화된 공간에서 적어도 하나의 매칭 작업을 수행하는 단계를 추가로 포함하는 방법.
제5항에 있어서,
상기 단방향 암호화는 임의의 일회용 암호표(one-time pad)를 사용하여 수행되는 방법.
제1항에 있어서, 하기 단계를 추가로 포함하는 방법:
상기 서버 컴퓨팅 장치에 의해, 디지털 자산에 액세스(access)하기 위한 하나 이상의 규칙에 의해 정의된 롤 개더링(role gathering)을 제공하는 단계; 및
상기 서버 컴퓨팅 장치에 의해, 상기 롤 개더링의 기능으로서 상기 사용자 컴퓨팅 장치에 의한 디지털 자산에 대한 액세스를 제공하거나 또는 거부하는 단계.
제7항에 있어서,
상기 액세스는 임의 액세스 제어(discretionary access control) 및 필수 액세스 제어(mandatory access control) 중 적어도 하나의 기능으로서 제공되는 방법.
제1항에 있어서, 하기 단계를 추가로 포함하는 방법:
상기 서버 컴퓨팅 장치에 의해, 분산된 클라이언트 소프트웨어 애플리케이션으로 구성된 상기 사용자 컴퓨팅 장치로부터 수신되는 2차 등록 요청을 처리하는 단계로서, 상기 2차 등록 요청은 네트워크에 상기 사용자 컴퓨팅 장치의 2차 사용자를 등록 시키는데 이용 가능하며 상기 2차 등록 요청은 상기 사용자 컴퓨팅 장치의 사용자와 관련된 2차 암호화된 부분적 초기 생체인식 벡터(initial biometric vector, IBV)를 포함하며, 상기 2차 등록 요청을 처리하는 단계는 상기 서버 컴퓨팅 장치에 액세스 가능하거나 상기 서버 컴퓨팅 장치의 일부인 비-일시적 프로세서 판독 가능 매체에 상기 2차 암호화된 부분적 IBV를 저장하는 단계.
제9항에 있어서, 하기 단계를 추가로 포함하는 방법:
상기 서버 컴퓨팅 장치에 의해, 사용자 컴퓨팅 장치와 연관된 1차 사용자의 등록을 폐지하는 단계.
사용자 컴퓨팅 장치와 신뢰되는 서버 사이에 보안 통신(secure communication)을 제공하는 시스템으로서,
하나 이상의 비-일시적인 프로세서 판독 가능 매체에 작동 가능하게 결합된 적어도 하나의 프로세서를 포함하며;
상기 하나 이상의 프로세서 판독 가능 매체는, 상기 적어도 하나의 프로세서가 하기의 동작들을 하는 것을 가능하게 하기 위한 명령어들을 포함하고:
상기 동작들은, 분산된 클라이언트 소프트웨어 애플리케이션으로 구성된 사용자 컴퓨팅 장치로부터 수신되는 등록 요청을 처리하는 것으로서, 상기 등록 요청은 네트워크에 상기 사용자 컴퓨팅 장치를 등록 시키는데 이용 가능하며 상기 요청은 상기 사용자 컴퓨팅 장치의 사용자와 관련된 암호화된 부분적 초기 생체인식 벡터(initial biometric vector, IBV)를 포함하며, 상기 등록 요청을 처리하는 단계는 서버 컴퓨팅 장치에 의해 액세스 가능하거나 서버 컴퓨팅 장치의 일부인 비-일시적 프로세서 판독 가능 매체에 상기 암호화된 부분적 IBV를 저장하는 것을 포함하는 것;
상기 사용자 컴퓨팅 장치로부터 그 다음으로 수신되고 암호화된 부분적 2차 생체인식 벡터를 포함하는 인증 요청과 상기 사용자 컴퓨팅 장치의 사용자와 관련된 인증 요청을 처리하는 것으로서, 상기 인증 요청을 처리하는 것은 하기 단계를 포함하는 것;
상기 암호화된 부분적인 초기 생체인식 벡터와 상기 암호화된 부분적인 2차 생체인식 벡터의 비교를 알고리즘의 기능으로서 수행하는 단계; 및,
상기 비교를 나타내는 값을 생성하는 단계; 및
상기 비교를 나타내는 값을 상기 사용자 컴퓨팅 장치로 송신하는 것으로서, 상기 값이 최소 임계값을 넘는 경우 상기 사용자 컴퓨팅 장치는 인증되고 상기 값이 최소 임계값 아래인 경우 인증되지 않는 것,을 포함하는 시스템.
제11항에 있어서,
상기 하나 이상의 비-일시적인 프로세서 판독 가능 매체는, 상기 적어도 하나의 프로세서가, 등록 요청 및 인증 요청에 포함되는 인증서를 사용자의 컴퓨팅 장치에 제공하는 것을 가능하게 하는 명령어를 추가로 포함하며, 상기 인증 요청을 처리하는 단계는 인증서가 통용중이며 폐지되지 않은 것인지 결정하는 것을 포함하는 시스템.
제11항에 있어서,
상기 하나 이상의 비-일시적인 프로세서 판독 가능 매체는, 상기 적어도 하나의 프로세서가, 능동적 모니터링을 제공하고 대체 인증서의 스푸핑(spoofing)을 방지하는 침입 탐지 시스템을 사용하는 것을 가능하게 하는 명령어를 추가로 포함하는 시스템.
제13항에 있어서,
상기 방지된 스푸핑은 대체 인증서를 리플레이(replay)하는 것을 포함하는 시스템.
제11항에 있어서,
상기 인증 요청을 처리하는 단계는 단방향 암호화의 기능으로서 암호화된 공간에서 적어도 하나의 매칭 작업을 수행하는 단계를 추가로 포함하는 시스템.
제15항에 있어서,
상기 단방향 암호화는 임의의 일회용 암호표(one-time pad)를 사용하여 수행되는 시스템.
제11항에 있어서,
상기 하나 이상의 비-일시적인 프로세서 판독 가능 매체는, 상기 적어도 하나의 프로세서가 하기 동작들을 가능하게 하기 위한 명령어를 추가로 포함하는 시스템:
디지털 자산에 액세스(access)하기 위한 하나 이상의 규칙에 의해 정의된 롤 개더링(role gathering)을 제공하는 것; 및
상기 롤 개더링의 기능으로서 상기 사용자 컴퓨팅 장치에 의한 디지털 자산에 대한 액세스를 제공하거나 또는 거부하는 것.
제17항에 있어서,
상기 액세스는 임의 액세스 제어(discretionary access control) 및 필수 액세스 제어(mandatory access control) 중 적어도 하나의 기능으로서 제공되는 시스템.
제11항에 있어서,
상기 하나 이상의 비-일시적인 프로세서 판독 가능 매체는, 상기 적어도 하나의 프로세서가 하기 동작을 가능하게 하기 위한 명령어를 추가로 포함하는 시스템:
분산된 클라이언트 소프트웨어 애플리케이션으로 구성된 상기 사용자 컴퓨팅 장치로부터 수신되는 2차 등록 요청을 처리하는 것으로서, 상기 2차 등록 요청은 네트워크에 상기 사용자 컴퓨팅 장치의 2차 사용자를 등록 시키는데 이용 가능하며 상기 2차 등록 요청은 상기 사용자 컴퓨팅 장치의 사용자와 관련된 2차 암호화된 부분적 초기 생체인식 벡터(initial biometric vector, IBV)를 포함하며, 상기 2차 등록 요청을 처리하는 것은 상기 서버 컴퓨팅 장치에 액세스 가능하거나 상기 서버 컴퓨팅 장치의 일부인 비-일시적 프로세서 판독 가능 매체에 상기 2차 암호화된 부분적 IBV를 저장하는 것.
하기 단계를 포함하는 사용자 컴퓨팅 장치와 서버 컴퓨팅 장치 사이에 보안 통신(secure communication)을 제공하는 방법:
상기 서버 컴퓨팅 장치에 의해, 분산된 클라이언트 소프트웨어 애플리케이션으로 구성된 사용자 컴퓨팅 장치로부터 수신되는 등록 요청을 처리하는 단계로서, 상기 등록 요청은 네트워크에 상기 사용자 컴퓨팅 장치를 등록 시키는데 이용 가능하며 상기 요청은 상기 사용자 컴퓨팅 장치의 사용자와 관련된 1차 생체인식 벡터의 제1부분을 포함하며, 상기 등록 요청을 처리하는 단계는 서버 컴퓨팅 장치에 의해 액세스 가능하거나 서버 컴퓨팅 장치의 일부인 비-일시적 프로세서 판독 가능 매체에 상기 1차 생체인식 벡터의 상기 제1부분을 저장하는 것을 포함하는 단계;
상기 서버 컴퓨팅 장치에 의해, 상기 사용자 컴퓨팅 장치로부터 그 다음으로 수신되고 1차 생체인식 벡터 이후 캡쳐(capture)된 2차 생체인식 벡터를 포함하는 인증 요청과 상기 사용자 컴퓨팅 장치의 사용자와 관련된 인증 요청을 처리하는 단계로서, 상기 인증 요청은 1차 생체인식 벡터의 제2부분을 추가로 포함하며, 상기 인증 요청을 처리하는 것은 하기 단계를 포함하는 것인 단계:
상기 1차 생체인식 벡터의 적어도 제1부분 및 제2부분을 결합하는 단계;
상기 결합된 제1부분 및 제2부분과 상기 2차 생체인식 벡터의 비교를 알고리즘의 기능으로서 수행하는 단계; 및,
상기 비교를 나타내는 값을 생성하는 단계; 및
상기 비교를 나타내는 값을 상기 서버 컴퓨터 장치에 의해 상기 사용자 컴퓨팅 장치로 송신하는 단계로서, 상기 값이 최소 임계값을 넘는 경우 상기 사용자 컴퓨팅 장치는 인증되고 상기 값이 최소 임계값 아래인 경우 인증되지 않는 단계.