KR20210077703A - 협업성 위험 인식 인증 - Google Patents
협업성 위험 인식 인증 Download PDFInfo
- Publication number
- KR20210077703A KR20210077703A KR1020217013746A KR20217013746A KR20210077703A KR 20210077703 A KR20210077703 A KR 20210077703A KR 1020217013746 A KR1020217013746 A KR 1020217013746A KR 20217013746 A KR20217013746 A KR 20217013746A KR 20210077703 A KR20210077703 A KR 20210077703A
- Authority
- KR
- South Korea
- Prior art keywords
- authentication
- token
- assurance level
- share
- user
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/105—Multiple levels of security
-
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
-
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2103—Challenge-response
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2111—Location-sensitive, e.g. geographical location, GPS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
개시자 장치는 관찰자 요청을 하나 이상의 인증 장치에 전송할 수 있다. 그 다음, 하나 이상의 인증 장치는, 보증 레벨의 범위로부터 보증 레벨을 결정할 수 있고, 상기 보증 레벨에 대응하는 토큰 공유를 결정할 수 있다. 그 다음, 개시자 장치는, 하나 이상의 인증 장치로부터, 상기 보증 레벨에 대응하는 토큰 공유를 포함한 적어도 하나의 관찰자 응답을 수신할 수 있다. 개시자 장치는, 토큰 공유 세트를 사용하여 인증 토큰을 생성할 수 있다. 그 다음, 개시자 장치는 인증 토큰을 인증 서버에 송신할 수 있되, 인증 서버는 인증 토큰을 검증한다.
Description
우선권 주장
본원은, 2018년 11월 15일에 출원된 미국 특허출원번호 제62/768,002호의 출원일의 혜택을 주장하는 국제 특허 출원이며, 모든 목적상 본원에 참조로 그 전체가 포함된다.
다중-인자 인증(MFA)은, 여러 개의 증거를 사용하여 사용자의 신원을 확인함으로써 인증 보안을 강화하는 방법으로서, 일반적으로 "아는 것, 갖는 것, 누구인가"으로 분류된다. MFA 체계가 많으나 2-인자 인증(2FA) 체계가 가장 인기 있고, 이 경우 사용자는 정확한 비밀 번호를 소유할 필요가 있을 뿐만 아니라, 일부 사전 확립된 채널(예, 짧은 메시지 서비스(SMS), 스마트 폰 푸시 통지, 이메일)을 통해 인증 서버로부터 전송된 챌린지 코드의 보유를 확인하거나, 사전 확립된 메커니즘(예, 하드웨어 토큰, 앱)을 통해 생성될 필요가 있다.
불행하게도, MFA를 두 개에서 세 개 이상의 인자로 확장하면, 보안이 개선되는 경우에도 현재 더 많은 인자를 처리하는 데 더 많은 사용자 상호 작용을 필요로 하기 때문에, 유용성에 영향을 미친다. 보안과 유용성 간의 이러한 트레이드오프는 오늘날 인증 접근법의 불행한 속성이다.
본 개시의 구현예는 이런 다른 문제점을 개별적으로 또는 총괄하여 해결한다.
본 개시의 구현예는 협업성 위험 인식 인증을 구현하는 방법, 장치 및 시스템을 제공한다.
본 개시의 일부 구현예에서, 개시자 장치는 관찰자 요청을 하나 이상의 인증 장치에 전송할 수 있다. 그 다음, 하나 이상의 인증 장치는, 보증 레벨의 범위로부터 보증 레벨을 결정할 수 있고, 상기 보증 레벨에 대응하는 토큰 공유를 결정할 수 있다. 그 다음, 개시자 장치는, 하나 이상의 인증 장치로부터, 상기 보증 레벨에 대응하는 토큰 공유를 포함한 적어도 하나의 관찰자 응답을 수신할 수 있다. 개시자 장치는, 토큰 공유 세트를 사용하여 인증 토큰을 생성할 수 있다. 그 다음, 개시자 장치는 인증 토큰을 인증 서버에 송신할 수 있되, 인증 서버는 인증 토큰을 검증한다.
본 개시의 다른 구현예에서, 인증 장치는 개시자 장치로부터 관찰자 요청을 수신할 수 있다. 그 다음, 인증 장치는 신뢰도 점수에 기초하여 개시자 장치와 연관된 제1 보증 레벨을 결정할 수 있다. 제1 보증 레벨은 보증 레벨의 범위로부터 결정될 수 있다. 그 다음, 인증 장치는, 제1 보증 레벨에 대응하는 토큰 공유를 수득한 다음에, 제1 보증 레벨에 대한 토큰 공유를 개시자 장치에 송신할 수 있다.
이들 및 기타 구현예를 아래에서 더욱 상세하게 설명한다. 예를 들어, 다른 구현예는 본원에서 설명되는 방법과 연관된 시스템, 장치, 및 컴퓨터 판독가능 매체에 관한 것이다.
본 개시의 구현예의 본질 및 이점의 더 나은 이해는, 다음의 상세한 설명 및 첨부 도면을 참조하여 얻어질 수 있다.
도 1은 다른 MFA 및 2FA 체계에 대한 본 개시의 구현예의 비교를 나타낸다.
도 2는, 본 개시의 구현예에 따라 협업성 위험 인식 인증 시스템을 예시한 블록 다이어그램을 나타낸다.
도 3은 본 개시의 구현예에 따른 하이-레벨 아키텍처를 나타낸다.
도 4는 본 개시의 구현예에 따라, 개시자 장치에 의해 수신된 토큰 공유를 나타낸다.
도 5는 본 개시의 구현예에 따라, 개시자 장치를 예시한 블록 다이어그램을 나타낸다.
도 6은 본 개시의 구현예에 따라, 인증 장치를 예시한 블록 다이어그램을 나타낸다.
도 7은 본 개시의 구현예에 따른 장치의 분류 예시를 나타낸다.
도 8은 본 개시의 구현예에 따라, 인증 방법을 예시한 흐름도를 나타낸다.
도 9는 본 개시의 구현예에 따른 장치의 수명 주기 예시를 나타낸다.
도 10은 본 개시의 구현예에 따라, 인증 토큰 생성 방법을 예시한 흐름도를 나타낸다.
도 11은 본 개시의 구현예에 따라, 관찰자 응답 생성 방법을 예시한 흐름도를 나타낸다.
도 12는 본 개시의 구현예, 다른 MFA 및 2FA 체계 사이의 유용성과 배치 가능성을 비교한 표를 나타낸다.
도 13은 본 개시의 구현예, 다른 MFA 및 2FA 체계 사이의 보안성을 비교한 표를 나타낸다.
도 14는 본 개시의 구현예에 따른 보안성 개선의 그래프를 나타낸다.
도 15는 본 개시의 구현예에 따른 내부 고발자 수의 효과 그래프를 나타낸다.
도 16은 본 개시의 구현예에 따라 신뢰도 측정계 정확도의 효과 그래프를 나타낸다.
도 17은 본 개시의 구현예에 따라 신뢰도 전파의 효과 그래프를 나타낸다.
도 18은 일부 구현예에 따른 컴퓨터 시스템을 예시한 블록 다이어그램을 나타낸다.
도 2는, 본 개시의 구현예에 따라 협업성 위험 인식 인증 시스템을 예시한 블록 다이어그램을 나타낸다.
도 3은 본 개시의 구현예에 따른 하이-레벨 아키텍처를 나타낸다.
도 4는 본 개시의 구현예에 따라, 개시자 장치에 의해 수신된 토큰 공유를 나타낸다.
도 5는 본 개시의 구현예에 따라, 개시자 장치를 예시한 블록 다이어그램을 나타낸다.
도 6은 본 개시의 구현예에 따라, 인증 장치를 예시한 블록 다이어그램을 나타낸다.
도 7은 본 개시의 구현예에 따른 장치의 분류 예시를 나타낸다.
도 8은 본 개시의 구현예에 따라, 인증 방법을 예시한 흐름도를 나타낸다.
도 9는 본 개시의 구현예에 따른 장치의 수명 주기 예시를 나타낸다.
도 10은 본 개시의 구현예에 따라, 인증 토큰 생성 방법을 예시한 흐름도를 나타낸다.
도 11은 본 개시의 구현예에 따라, 관찰자 응답 생성 방법을 예시한 흐름도를 나타낸다.
도 12는 본 개시의 구현예, 다른 MFA 및 2FA 체계 사이의 유용성과 배치 가능성을 비교한 표를 나타낸다.
도 13은 본 개시의 구현예, 다른 MFA 및 2FA 체계 사이의 보안성을 비교한 표를 나타낸다.
도 14는 본 개시의 구현예에 따른 보안성 개선의 그래프를 나타낸다.
도 15는 본 개시의 구현예에 따른 내부 고발자 수의 효과 그래프를 나타낸다.
도 16은 본 개시의 구현예에 따라 신뢰도 측정계 정확도의 효과 그래프를 나타낸다.
도 17은 본 개시의 구현예에 따라 신뢰도 전파의 효과 그래프를 나타낸다.
도 18은 일부 구현예에 따른 컴퓨터 시스템을 예시한 블록 다이어그램을 나타낸다.
용어
본 개시의 구현예를 설명하기 전에, 일부 용어의 설명은 본 개시의 구현예를 이해하는 데 도움이 될 수 있다.
용어 "서버 컴퓨터"는 강력한 컴퓨터 또는 컴퓨터들의 클러스터를 포함할 수 있다. 예를 들어, 서버 컴퓨터는, 큰 메인프레임, 미니컴퓨터 클러스터, 또는 한 유닛으로서 기능하는 컴퓨터의 그룹일 수 있다. 일례로, 서버 컴퓨터는 웹 서버에 연결된 데이터베이스 서버일 수 있다. 서버 컴퓨터는, 데이터베이스에 결합될 수 있고, 하나 이상의 다른 컴퓨터로부터의 요청을 서비스하기 위한 임의의 하드웨어, 소프트웨어, 기타 로직, 또는 이들의 조합을 포함할 수 있다. 용어 "컴퓨터 시스템"은, 일반적으로 하나 이상의 데이터베이스에 결합될 수 있는 하나 이상의 서버 컴퓨터를 포함한 시스템을 지칭할 수 있다.
"메모리"는, 전자 데이터를 저장할 수 있는 임의의 적합한 장치(들)일 수 있다. 적합한 메모리는, 원하는 방법을 구현하도록 프로세서에 의해 실행될 수 있는 명령어를 저장하는 비일시적 컴퓨터 판독가능 매체를 포함할 수 있다. 메모리의 예로는, 하나 이상의 메모리 칩, 디스크 드라이브 등을 포함할 수 있다. 이러한 메모리는, 임의의 적합한 전기 작동 모드, 광학 작동 모드, 및/또는 자기 작동 모드를 사용하여 작동할 수 있다.
"프로세서"는 임의의 적합한 데이터 연산 장치(들)를 포함할 수 있다. 프로세서는, 원하는 기능을 달성하도록 함께 동작하는 하나 이상의 마이크로프로세서를 포함할 수 있다. 프로세서는, 사용자 및/또는 시스템 생성 요청을 실행하기 위한 프로그램 구성요소를 실행하는 데 적절한 적어도 하나의 고속 데이터 프로세서를 포함한 CPU를 포함할 수 있다. CPU는, AMD의 Athlon, Duron 및/또는 Opteron; IBM 및/또는 Motorola의 PowerPC; IBM과 Sony의 Cell 프로세서; Intel의 Celeron, Itanium, Pentium, Xeon, 및/또는 XScale; 및/또는 기타 프로세서(들)의 마이크로프로세서일 수 있다.
용어 "암호화 키" (또는 단지 "키")는 암호화 또는 복호화에 사용되는 것을 지칭할 수 있다. 암호화 키는, 예를 들어 두 개의 큰 솟수 번호의 곱을 지칭할 수 있다. 암호화 키는 RSA(Rivest, Shamir, Adleman) 또는 AES(Advanced Encryption Standard)와 같은 암호화 시스템에서 사용될 수 있으며, 일반텍스트를 암호화하고 암호텍스트 출력을 생성하는 데 사용될 수 있고, 암호텍스트를 해독하고 일반텍스트 출력을 생성할 수 있다. 암호화 키는, 암호화 및 복호화에 동일한 키가 사용될 수 있는 경우 대칭적이거나, 암호화 및 복호화에 사용되는 상이한 키가 사용될 수 있는 경우 비대칭적일 수 있다.
"일반텍스트"라는 용어는 일반 형태인 텍스트를 포함할 수 있다. 예를 들어, 이는 "안녕, 어떻게 지내?"라는 문구와 같이, 사람이나 컴퓨터에 의해 읽을 수 있는 텍스트를 의미할 수 있다. 또한 비암호화된 형태의 텍스트를 지칭할 수 있다. 수 또는 기타 기호는 또한 일반텍스트일 수 있다.
"암호텍스트"라는 용어는 암호화된 형태인 텍스트를 포함할 수 있다. 예를 들어, 이는 사람 또는 컴퓨터에 의해 판독되기 전에, 해독되어야 하는 텍스트를 지칭할 수 있다. 암호텍스트는 RSA 또는 AES 같이 임의 수의 암호화 알고리즘 또는 암호화 시스템에 의해 생성될 수 있다.
"사용자 장치"는 사용자에 의해 작동되는 장치일 수 있다. 사용자 장치의 예는, 모바일 폰, 스마트 폰, 개인용 휴대 정보 단말기(PDA), 랩톱 컴퓨터, 데스크톱 컴퓨터, 서버 컴퓨터, 음성-제어 어시스턴트, 차량(예, 자동차), 신-클라이언트 장치, 태블릿 PC 등일 수 있다. 추가적으로, 사용자 장치는 임의 유형의 웨어러블 기술 장치, 예컨대 시계, 이어폰, 안경 등일 수 있다. 사용자 장치는, 사용자 입력을 프로세싱할 수 있는 하나 이상의 프로세서를 포함할 수 있다. 사용자 장치는 또한 사용자 입력을 수신하기 위한 하나 이상의 입력 센서를 포함할 수 있다. 당업계에 알려져 있듯이, 가속도계, 카메라, 마이크로폰 등의 사용자 입력을 감지할 수 있는 다양한 입력 센서가 존재한다. 입력 센서에 의해 얻어진 사용자 입력은, 오디오 데이터, 비주얼 데이터, 또는 생체 측정 데이터 등의 다양한 데이터 입력 유형으로부터 온 것일 수도 있지만, 이에 한정되지 않는다. 사용자 장치는, 사용자에 의해 작동될 수도 있는 임의의 전자 장치를 포함할 수도 있으며, 이는 또한 네트워크에 원격 통신 능력을 제공할 수도 있다. 원격 통신 능력으로, 모바일 폰(무선) 네트워크, 무선 데이터 네트워크(예, 3G, 4G 또는 유사 네트워크), Wi-Fi, Wi-Max, 또는 인터넷 또는 사설 네트워크와 같은 네트워크에 대한 액세스를 제공할 수 있는 임의의 다른 통신 매체를 예로 들 수 있다.
일부 구현예에서, 사용자 장치는 다양한 기능을 수행할 수 있고, 프로세스에서 상이한 역할로 작동할 수 있다. 예를 들어, 사용자 장치는 개시자 장치 및/또는 인증 장치일 수 있다. 일례로, 사용자는, 사용자 장치, 개시자 장치, 및 두 개의 인증 장치를 포함한, 네 개의 장치를 가질 수 있다.
"개시자 장치"는 프로세스를 개시할 수 있는 장치를 포함할 수 있다. 일부 구현예에서, 개시자는 다른 장치와 협업함으로써 토큰 생성을 개시하는 장치를 포함할 수 있다. 개시자 장치는 사용자 장치일 수 있다.
"인증 장치"는 인증이 가능한 장치를 포함할 수 있다. 일부 구현예에서, 인증 장치는, 인증 토큰을 계산하기 위해 개시자 장치와 협업하는 데 동의한 장치일 수 있다. 인증 장치는 사용자 장치일 수 있다.
"내부 고발자"는 악성 장치에 알려주는 실체 및/또는 장치를 포함할 수 있다. 일부 구현예에서, 내부 고발자는, 악의적인 활동을 직접 관찰할 수 있고 악의적인 활동에 대해 블라인드될 수 있는 다른 장치로 악의적인 활동에 관한 정보를 퍼뜨릴 수 있는 장치를 포함할 수 있다.
"인증 서버"는 인증이 가능한 서버를 포함할 수 있다. 인증 서버는, 인증 가능한 실체를 포함할 수 있는 인증자에 의해 작동될 수 있다. 일부 구현예에서, 인증자는, 토큰을 검증함으로써 서비스를 제공하고 서비스에 대한 사용자를 인증하는 실체를 포함할 수 있다.
"신뢰도 점수"는 신뢰 수준의 값을 포함할 수 있다. 예를 들어, 신뢰도 점수는, 장치가 이웃하는 장치(즉, 직접 통신 범위의 장치)에 부여하는 신뢰 수준을 나타낼 수 있다. 신뢰도 점수는, 다른 장치 및/또는 인지된 위치의 관찰된 거동에 기초할 수 있다. 각각의 장치는 장치의 모든 이웃에 대한 신뢰도 점수의 벡터를 유지할 수 있다. 신뢰도 점수는 하나의 특정 상호 작용을 나타내지 않을 수 있지만, 장치가 어떻게 "정상"이고 "신뢰성"있게 거동하고/거동하거나 이렇게 구성되는가를 나타내는 것일 수 있다.
"보증 레벨"이라는 용어는, 어떤 것에 대해 실체가 갖는 신뢰도가 얼마인지 측정하거나 표시하는 것을 의미할 수 있다. 예를 들어, 보증 레벨은 각 인증에 대해 계산되는 값일 수 있다. 보증 레벨은, 개시자 장치의 신뢰 수준, 인증 시간 및 위치, 장치의 인증 이력, 장치에 대한 사용자 선호도, 및/또는 개시자 장치의 위치에 따라 달라질 수 있다. 일부 구현예에서, 보증 레벨은 특정 인증 정책 요건을 충족하는 것에 대응할 수 있다.
"장치 거동"은 장치의 거동을 포함할 수 있다. 일부 구현예에서, 실시간 장치 거동은 제2 장치 및/또는 실체에 의해 관찰될 수 있다. 장치 거동은, 패킷 수, 패킷 크기, 소스, 대상, 결제 참여 또는 종료 결정, 근접성 등과 같은 기능을 포함할 수 있다.
"인증 거동"은 인증 동안에 장치 거동을 포함할 수 있다. 일부 구현예에서, 인증 거동은 과거 인증 동안의 거동을 포함할 수 있다. 각각의 장치는, 그 이웃이 수행한 인증 거동을 포함한 인증 이력을 일정 시간 동안 저장할 수 있다. 인증 거동은, 인증 시간 및 인증 위치와 같은 특징부를 포함할 수 있다. 일반적으로, 많은 특징부가 많은 양의 스토리지를 사용할 수 있지만, 일부 구현예에서, 장치는 인증 이력에 저장된 데이터의 양을 제한하기 위해 각 개시자로부터의 관찰자 요청의 타임스탬프를 저장할 수 있다.
"임계 암호화"는, 비밀 키에 대한 노출을 감소시키기 위해 임계 방식으로 사용될 수 있는, 암호화 체계를 포함할 수 있다. 비밀 키를 하나의 장치에 저장하는 것보다, 비밀 키를 여러 장치 사이에 분산시킬 수 있어 암호화 작업을 수행하는 데 적어도 하나의 임계 수의 비밀 키가 필요하도록 한다. 예를 들어, 공개 키 서명 체계에 대한 복호화 키는 5개의 장치 사이에 분산시킴으로써 보호될 수 있다. 임계값이 2로 설정되는 경우에, 복호화 키를 사용하여 임의의 암호텍스트를 복호화하기 위해 적어도 2개의 장치가 필요하다.
"비밀"은, 암호화 프로세스의 일부로서 숨겨진 값 또는 대상을 포함할 수 있다. 암호화 프로세스의 보안은, 단지 몇몇 당사자에게만 알려진 비밀에만 의존할 수 있다. 예를 들어, 비밀은 암호화 키일 수 있다. 비밀을 노출하면, 의도한 당사자 이외의 당사자가 메시지를 암호화하거나 해독할 수 있다.
"공유 비밀"은 다중 당사자 간에 공유된 비밀 값 또는 대상을 포함할 수 있다. 예를 들어, 공유 비밀은, 다중 당사자 각각이 암호화 키의 일부를 보유하도록 분할된 암호화 키일 수 있다. 예를 들어, 128 비트 암호화 키는 여덟 당사자 사이에서 분할되어 각 당사자는 16 비트 암호화 키를 보유할 수 있다.
"비밀 공유분"은 공유 비밀로부터 파생된 값을 포함할 수 있다. 예로서 비밀 공유분은 비밀 값의 처음 12비트일 수 있다. 비밀 공유분은 또한 수를 갖는 이진 배타적-OR 비밀 값일 수 있다. 비밀 공유분은 일부 경우에 비밀을 재현하기 위해 여러 다른 비밀 공유분과 조합될 수 있다. 일부 구현예에서, 비밀 공유분은 토큰 공유일 수 있다. 인증 토큰은 토큰 공유분(들)을 사용하여 획득할 수 있다.
상세한 설명
현재의 인증 기술은 보안 대 유용성의 트레이드 오프에 직면한다. 예를 들어, 2 인자 인증은 모든 라운드에서 사용자 상호 작용을 요구하는 비용으로 보안을 개선하는 하나의 방법이다. 대부분의 2FA 방법은, 사용자의 전화기에 속박되어 전화기를 사용할 수 없는 경우에는 실패한다. 본 개시의 구현예는, 사용자가 소유하는 장치를 이용할 수 있는, 원활하고 위험 인식적인 인증 방법을 가능하게 한다.
본 개시의 구현예는, 임계값 메시지 인증 코드(MAC)를 사용하여 유용성을 유지하면서 증가된 보안을 제공한다. 구현예는 또한, 사용자 지식 및/또는 상호 작용을 필요로 하기 보다는 사용자 장치의 지식을 이용할 수 있다. 본 개시의 구현예를 사용하여, 인증 토큰은, 사용자가 소유한 다수의 장치가 협업해서 생성될 수 있다. 인증 토큰은 인증 서버에 대한 인증 토큰의 신뢰성을 표시하는 위험 인자를 수반할 수 있다. 구현예는 1) 위험 인자를 결정하기 위한 장치용 신뢰도 측정계 시스템 및 2) 단일 실패 지점이 없도록 보증하기 위한 임계값 암호화를 이용할 수 있다. 일부 구현예는 장치에 대한 임의의 보안 요소 또는 물리적 보안을 가정하지 않는다.
다음 섹션은, 협업성 위험-인식 인증을 수행하기 위해 사용된 방법과 시스템을 보다 상세하게 설명한다. 섹션 I은 인증 보안의 현재 문제점에 대한 구현예를 소개한다. 섹션 II는 본 개시의 구현예에 따른 설계의 개요를 제공하고, 위협 모델, 장점 및 접근법을 포함한다. 섹션 III은 관련 작업을 설명한다. 섹션 IV는 협업성 위험-인식 인증을 수행하는 시스템에 대해 설명한다. 섹션 V는 협업성 위험-인식 인증 방법을 설명한다. 섹션 VI은 보안 분석을 제공한다. 섹션 VII는 본 개시의 구현예의 평가를 제공한다. 섹션 VIII은 본 개시의 구현예에 따른 협업성 위험-인식 인증의 예시적인 응용을 설명한다. 섹션 IX는 결론을 포함한다. 섹션 X는 일부 구현예에 따른 컴퓨터 시스템을 설명한다. 섹션 XI는 참고문헌을 제공한다.
I.
소개
사물 인터넷(IoT)의 가용성과 채택은, 사용자가 하나 이상의 장치를 소유하고 있으며 일상 활동 중에 종종 여러 장치를 갖고 있음을 의미한다. 최근 2018년 연구[23]에서 사용자(미국 내)는 평균 4.4개의 장치를 소유하고 있으며, 전체 35.9%가 여섯 개 이상의 장치를 보유하고 있다(2017년 23.4%에서 증가함). 이들 장치는 스마트 폰, 노트북, 태블릿, 스마트 TV, 게임 콘솔, 음성 제어 어시스턴트, 커넥티드 카, e-리더, 활동/피트니스 추적기, 스마트 워치에서 스마트 홈 장치(냉장고, 온도 조절기, 카메라)까지 다양하다. 일반적으로 매일 사용되는 장치는, 사용자의 (디지털) ID에 증거를 협업해서 제공하기에 충분한 사용자 정보를 갖고 있다. 또한, 다중 장치는 단일 고장 지점을 제거하여 중복성을 허용한다. 구현예는, 사용자 장치를 이용해 사용자를 식별하기 위한, 마찰 없는 신규 방법을 제공한다. 다른 MFA 및 2FA 체계에 대해 협업성 위험 인지 인증(CoRA)으로서 집합적 지칭되는 다양한 구현예의 시각적 비교가 도 1에 나타나 있다.
도 1은 다른 MFA 및 2FA 체계에 대한 본 개시의 구현예의 비교를 나타낸다. 인자의 수를 늘리면 보안성을 잠재적으로 개선할 수 있지만, 이는 오늘날의 기술에 대한 유용성에 영향을 미칠 수 있다. 예를 들어, 비밀번호 전용 인증 시스템은 사용하기 쉽지만 안전하지는 않다. 안전한 비밀번호는 기억하기 어렵고, 따라서 유용성 측면에서 순위가 낮다. Yubikey는 유용성을 더 많이 제공하나, 단일 고장 지점의 단점을 갖는다. 본 개시의 구현예는, 상당한 유용성의 원활한 인증과 상당한 보안성의 MFA 간의 갭을 가교한다.
원활한 인증은 장치 간의 성공적인 근접성 확립 후, 다양한 장치가 서로 통신하여 필요한 정보(ID의 증거)를 교환함으로써 MFA의 유용성 문제를 해결한다. 따라서, 사용자가 하나의 장치로부터 다른 장치로 챌린지 코드를 전달하는 대신에, 서로 매우 근접한 장치는 프로세스를 자동화한다. 기존의 원활한 인증 체계는 두 가지 인자에 중점을 두고 주요 장치(예, 노트북)를 모바일 장치(예, 스마트 폰[6], 스마트 워치[20])와 페어링하여 2FA 보안을 제공한다. 이들 원활한 2FA 체제를 채택하는 데 있어서 주요 장애물은, 보안성과 가용성이다. 모바일 장치 또는 모바일 장치 자체에 대한 사전 확립된 채널이 침해되는 경우에, 체계의 보안성은 비밀번호 전용 인증의 보안 수준으로 약화된다. 한편, 모바일 장치가 없거나, 전력이 없거나, 달리 이용할 수 없는 경우에, 원활한 2FA 체계를 진행할 수 없다.
본 개시의 구현예는, 사용자가 종종 다수의 장치(예, IoT 장치)를 갖고 있다는 사실을 이용할 수 있다. 또한, IoT 장치는 네트워크로 연결되어 있고, 직접 또는 허브를 통해 인터넷에 연결할 수 있다. 결과적으로, 사용자의 IoT 장치 모음은 정보를 교환하고, 컨텍스트를 측정하고, 사용자를 함께 인증하여, 원활한 MFA를 배치하기 위한 이상적인 플랫폼을 생성한다. 이를 위해, 본 개시의 구현예는, 가능한 한 많은 인자가 인증 프로세스에 참여하고 상당히 보증된 ID를 생성할 수 있게 한다.
원활한 MFA 인증자 역할을 할 수 있는 많은 장치를 보유하면, 적어도 세 가지의 문제가 발생한다. 첫째, 모든 장치가 항상 이용 가능할 수 없으므로, CoRA는 일부 인자를 없앨 수 있고 생성된 ID에서 이러한 부재를 반영할 수 있다. 둘째, 일부 장치는 (물리적으로 또는 가상으로) 침해될 것으로 가정될 수 있으므로, 일부 구현예에서, 장치는 임의의 개별 장치에 모든 비밀을 저장하지 않을 수 있다. 셋째, 일부 침해가 예상되므로, 구현예는, 이렇게 침해된 장치가 인증 프로세스에 참여하는 것을 배제할 수 있다.
또 다른 문제는 사용자 프라이버시 문제이다. 전술한 바와 같이, 장치의 혼선 및 침해가 인증 프로세스의 정확성 및 보안에 영향을 미치지만, 이러한 컨텍스트에서의 프라이버시는, 인증 서버의 각 인스턴스 동안에 사용자에 대해 인증 서버가 학습하는 정보의 양을 지칭한다. 일부 구현예에서, 인증 서버는, 높은 보증성의 ID를 확립하는 데 필요한 것 이상의 임의의 정보를 학습할 수 없다. 특히, IoT 맥락에서, 사용자는 인증 동안에 사용된 장치 세트, 예를 들어 장치 위치, 장치 상태 등을 비공개로 유지하고자 할 수 있다. 이렇게 하면 인증 체계를 복잡하게 한다. 실제로, 프라이버시에 관심이 없는 경우에, 모든 장치가 인증 서버에 대해 암호화 증거(예, 서버와 공유된 비밀 키에 기초하여 장치 당 하나의 MAC)를 전달하는 단순한 체계가, 프라이버시 침입 MFA 체계에 전적으로 충분할 것이다. 이러한 미처리 체계는, 사용자가 어느 시점에 어떤 장치를 사용하는지에 대한 정보를 지속적으로 서버에 제공한다. 이러한 프라이버시 우려를 제거하기 위한 본 개시의 구현예.
구현예는 사용자 프라이버시를 보호하면서 이들 문제점을 해결할 수 있다. 인증 토큰과 함께 제공될 수 있는 보증 레벨을 제외하고, 장치 또는 사용자에 대한 다른 정보는 인증 서버로 전송되지 않는다. 일부 구현예에서, 장치는 근접 검사를 사용하여 근처에 있는 피어 장치를 식별하고, 이들 근위 피어 중 어느 것이 신뢰할 수 있는지 결정하기 위해 이상 감지를 적용하고, 위탁 장치와 함께 일련의 임계값 MAC 체계에 참여하고, 최종적으로, 참여하는 장치의 수(암호화 임계값으로서 표현됨), 이들 장치 간에 공유된 신뢰도(보증 레벨로 표현됨), 인증 요청 자체에 대한 정보(계정의 사용자 이름, 필요한 인증 레벨, 등)를 캡처하는 인증 토큰을 연산할 수 있다. 따라서, 본 개시의 구현예에 따른 프라이버시 보존 인증 체계는, 임의의 수의 인자로 확장하고, 위험 정보를 제공하고, 원활한 인증의 유용성을 유지한다.
구현예는 다음의 개선을 제공할 수 있으며, 이는 본원에서 더 상세히 논의될 것이다. 위험 인식 임계값 암호화 체계는, 섹션 IV.B에 설명된 바와 같이, 장치로 하여금, 다른 장치에서 갖는 신뢰도에 기초하여 분산 암호화 프로토콜에 참여할지 여부를 결정시킬 수 있다. 섹션 IV에서, 위험 인식 임계값 암호화 체계에 추가하여 다중 수준의 위험 인식 인증 방법을 구축하는 방법이 나타나 있다. 섹션 VI 및 VII에서, 다양한 물리적 및 가상 공격자의 존재 시, 인증에 대한 "위탁 장치의 웹" 접근 방식이 어떻게 수행되는지에 대한 평가를 수행한다.
또한, 관련 작업은 섹션 III에서 논의된다. 본 개시의 구현예의 예시적인 응용은 섹션 VIII에서 논의된다.
II.
설계
본 개시의 구현예에 따른 시스템은, 동일한 사용자가 소유하고/소유하거나 작동하는 다른 사용자 장치의 도움으로, 임의의 사용자 장치를 통해 사용자가 원격 서버(예, 인증 서버)에 인증하도록 허용할 수 있다. 동일한 사용자가 소유한 여러 개의 사용자 장치를 사용하여 인증 작업에 기여함으로써, 보안성과 가용성을 동시에 증가시킨다. 이 섹션에서는 CoRA 다중 장치 인증 체계의 위협 모델, 목표 및 접근 방법에 대해 설명한다.
CoRA의 목적을 위해, 사용자는 연산, 보안, 감지 및 생체 인식 입력에 관하여 다양한 능력을 갖는 사용자 장치 N 개를 소유할 수 있다. 인증 작업을 수행하기 위해 임의의 시간에 
인 수의 사용자 장치가 사용자에게 이용 가능할 수 있다. 예를 들어, 사용자는 다섯 개의 장치, 노트북, 스마트 워치, 스마트 폰, 스마트 카, 및 스마트 냉장고를 소유할 수 있지만, 여행 중에는 이들 중 두 개만 보유한다(예, 시계 및 전화기).
A.위협 모델
공격자는, 사용자의 장치를 훔치고 물리적인 통제력을 확보하거나, 장치의 소프트웨어 또는 하드웨어의 취약점을 악용하여 이를 손상시켜 사용자의 장치에 대한 제어력을 얻을 수 있음을 가정할 수 있다. 공격자가 사용자 장치를 제어하는 경우에, 사용자 장치의 데이터 및 코드에 대한 완전한 액세스 권한이 있다고 가정할 수 있다. 다시 말해, 이들은 자신의 통제 하에 있는 사용자 장치(들)가 인증 작업에 참여하는 것을 거부하거나, 부정확한 데이터로 참여하거나, 가짜 인증 요청을 트리거하는 등을 할 수 있다. 단순화를 위해, 공격자가 제어하는 장치는 악성 장치로 지칭되는 반면에, 비악성 장치는 정직한 장치로 지칭된다.
공격자는, 사용자가 인증 작업을 개시하지 않고서 원격 서버에 피해자 사용자로 인증할 수 있는 경우라면 성공적일 수 있다. 그러나, 협박 및 사회 공학적 공격 하의 인증은, 본원에서 논의되지 않을 것이다.
(MFA 체계의 경우와 같이) 사용자의 비밀번호가 침해된 것으로 가정할 수 있으며, 비밀번호 외에 인증에 사용할 수 있는 다수의 이차적 인자를 보호하는 목표에 초점을 맞출 수 있다. 공격자는 비밀번호에 대한 지식을 보유하고 있으며, 사용자 장치의 침해된 하위 집합을 제어하는 원격 공격자 또는 사용자 장치 간의 통신 채널을 제어하는 로컬 공격자이다. 공격자가 사용자의 모든 장치를 제어하지 않는다고 가정할 수 있고, 그렇지 않으면 공격자가 비밀번호를 알고 모든 장치를 제어하기 때문에 공격자는 사용자와 구별할 수 없다.
B.장점
본 개시의 구현예는 몇 가지 장점을 제공한다. 예를 들어, 구현예는 보안 강화, 개선된 유용성, 장치 침해에 대한 복원력, 및 프라이버시 강화를 제공한다. 이들 장점은 본원에서 더 상세히 설명된다.
1. 보안 강화
보안 강화는 공격자가 성공하기 위한 기준이 더 높다는 것을 의미하고, 구현예에 따라, 공격자가 인증 서버에 대한 사용자로서 성공적으로 인증하기 위해 많은 사용자 장치를 제어해야 한다는 것을 의미한다. 즉, 사용자가 소유한 사용자 장치의 수가 증가함에 따라 CoRA 인증의 보안 보장이 더 강력해질 수 있다. 인증에 사용할 수 있는 장치의 수를 엄격하게 늘리면 보안 강화가 아니라 오히려 공격 표면이 증가하기 때문에(즉, 공격자가 이차적 인자를 침해하기로 결정하는 경우에 선택할 사용자 장치가 더 많아짐) 이를 감소함에 주목하기 바란다. 즉, 인증을 위해 이용 가능한 장치의 수가 증가하면, 인증에 필요한 장치의 수가 증가하는 것과 연결될 수 있다. 이 특성은 고정 임계값인 다음 방정식을 이용해 표시되며, 여기서 k는 고정 임계값이고, p는 고정된 침해 확률이며, n은 다수의 사용자 장치이다. 이항 분포의 경우, 보안은 고정 임계값 k, 고정 침해 확률 p(하나의 장치에 대해), 및 장치 수 n의 증가(장치 침해가 IID(독립적이고 동일하게 분포됨)라고 가정함)에 대해 감소한다.
2. 개선된 유용성
개선된 유용성은, 사용자가 기존 체계보다 적은 수의 비밀을 기억해야 하며 인증에 필요한 상호 작용은 인증 작업을 개시하는 것으로 제한됨을 의미한다. 이는, 사용자가 별도의 사용자 장치(2FA 채널)에서 수신한 코드를 수동으로 입력해야 하는, 대화형 2FA 방식의 임의의 접근법을 최소한 배제한다.
3. 장치 침해에 대한 복원력
보안 및 유용성에 더하여, 일부 구현예에서, 인증 체계는 인증에 사용된 사용자 장치(들)가 악성일 수 있다는 사실을 설명할 수 있다. 인증 서버는 인증 증명 외에 위험 정보를 수신할 수 있다. 이는, 이진법 결과(사용자가 완전히 인증되었거나 그렇지 않음)를 제공하는, 대부분의 기존 인증 체계와 대조적이다.
4. 프라이버시
인증 작업의 위험을 제거하는 일반적인 방법은 사용자, 사용자의 장치(들) 및 그들의 환경에 대한 데이터를 최대한 많이 수집하고, 이 데이터를 인증 서버로 전송하고, 일부 형태의 이상 감지를 사용하여 이차 스텝-업 인증을 트리거하고, 사용자가 자신의 ID를 증명하기 위해 추가로 해야 하는 인용을 찾는 것이다. 감소된 유용성에 더하여, 컨텍스트 데이터에 기초한 스텝-업 인증은, 본 개시의 구현예에 대한 프라이버시 목표를 위반한다. 한 가지 목표는, 인증 서버로 전송되는 정보의 양을 최소화하여 사용자 개인정보를 보호하는 것이다.
프라이버시 목표는, 각 인증 작동과 관련하여 정의될 수 있다. 인증 서버는, 작동에 참여한 사용자 장치의 수 및 그것과 관련된 위험 평가를 학습할 수 있지만, 어떤 사용자 장치가 참여했는지, 그리고 그들의 컨텍스트(예, 위치 등)에 관한 것은 무엇인지는 알 수 없다. 중요한 차이점은, 프라이버시 목표가 인증 작업에는 적용되나 시스템에서 사용자 장치를 추가하고 제거하는 작업에는 적용되지 않는 점이다. 사용자는 인증 서버에 자신이 소유한 모든 사용자 장치의 목록을 노출시키는 것에 문제가 없다고 가정할 수 있어서, 인증 서버는 그 서버와 접촉하는 임의의 사용자 장치를 주어진 사용자에게 속하는 것으로 식별할 수 있다.
C. 접근 방법
본 개시의 구현예에서, 인증 서버는 사용자에게 속하는 것으로 알려진 사용자 장치의 목록을 유지할 수 있으며, 이는 등록된 사용자 장치의 세트로서 지칭될 수 있다. 각각의 사용자 장치는 인증 서버를 이용해 등록될 수 있고, 암호화 비밀을 인증 서버와 공유할 수 있다. 또한, 각각의 사용자 장치는 임계 암호화 체계의 하나 이상의 인스턴스에 대한 암호화 키 공유분을 수신할 수 있다. (예를 들어, 수명 종료 또는 도난으로 인해) 사용자 장치가 제거되는 경우에, 인증 서버 및 나머지 사용자 장치는 새로운 암호화 키를 생성하고 공유할 수 있다. 사용자 장치는, 등록된 세트 내의 모든 피어 사용자 장치에 대한 신뢰도 점수를 유지할 수 있고; 신뢰도 점수는 사용자 장치 쌍 간의 상호 작용 이력에 대한 이상 감지를 사용하여 연산될 수 있다. 따라서, 사용자 장치는, 동일한 사용자에 속하는지 상호 검증할 수 있고, 암호텍스트를 공동으로 연산하기 위한 임계값 암호화 체계에 참여할 수 있고, 임의의 주어진 순간에 자신의 등록된 피어 사용자 장치 중 어느 것을 신뢰할 수 있는지 스스로 결정할 수 있다.
사용자가, 예를 들어 웹 브라우저에 비밀번호를 입력함으로써, 인증 서버에 대한 인증을 시도하는 경우에, 웹 브라우저는 로컬 통신 체계(예, WebAuthn[24])를 통해 등록된 사용자 장치 중 하나에 연결할 수 있다. 인증 작업 지속 기간 동안에 개시자 장치로서 지칭되는 이러한 사용자 장치는, 근접한 모든 다른 등록된 사용자 장치를 발견할 수 있다. 로컬로 이용 가능한 사용자 장치는, 개시자 장치와 함께, 본 사용자 장치의 세트를 형성할 수 있다.
이 시점에서, 개시자 장치는 인증 토큰의 공동 연산을 위해 모든 본 사용자 장치에 대한 요청을 개시할 수 있다. 요청을 수신한 각 사용자 장치는, 개시자 장치에 대한 자신의 신뢰도 점수 및 다른 현재 사용자 장치에 대한 자신의 신뢰도 점수에 따라, 이러한 공동 연산에 참여할지 여부를 결정할 수 있다. 예를 들어, 총 다섯 개의 사용자 장치(개시자 장치 포함)가 존재하지만 개시자 장치가 두 개의 다른 사용자 장치에 의해 신뢰받는 경우에, 세 개의 사용자 장치는 인증 토큰을 공동으로 연산할 수 있다. 인증 토큰은 연산에 참여한 사용자 장치의 수를 반영할 수 있다.
일단 개시자 장치 및 참여 사용자 장치가 인증 토큰을 연산하면, 개시자 장치는 인증 토큰을 웹 브라우저에 제공할 수 있고, 이는 인증 토큰을 인증 서버에 전송할 수 있다. 이제, 인증 서버는 사용자의 ID에 대한 여러 개의 증거를 갖는다: 브라우저에 입력된 비밀번호, 개시자 장치의 장치 ID, 및 참여 사용자 장치의 수를 정의하는 인증 토큰. 그 다음, 이들 아이템은, 요청을 처리하고, 결제 트랜잭션을 진행하고, 보안 시스템 및/또는 위치에 대한 액세스를 허용하는 등과 같은 인증 결정을 내리는 데 사용된다.
III.
관련 작업
다음으로, 다양한 관련 작업과 각각의 단점에 대해 논의된다. Corner 등[5]이 처음 도입한 제로 상호작용 인증(ZIA)은, 사용자에게 짧은 범위로 노트북과 통신하는 추가 장치를 착용하도록 요청하여 그 근접성을 입증함으로써, 원활한 방법으로 인증 보안을 개선하는 것을 목표로 하였다. 스마트 폰이 등장하면서, 스마트 폰에서 사용 가능한 리소스와 센서를 사용함으로써, ZIA를 위한 원거리의 바운딩 기법에 초점을 맞춘 풍부한 작품이 탄생하였다. 거리의 바운딩 작업에 대한 요약이 본 섹션에 기술될 것이다.
Halevi 등[9]은, 오디오 및 광 데이터와 같은 주변 센서에 기초해서 안전한 근접 감지 체계를 제안한다. PhoneAuth[6]은 2FA에 대한 근접성을 입증하기 위해 휴대폰과 노트북 간의 블루투스 통신을 사용한다. 구조용 드론[17]은 순수한 주변 물리적 감지 접근법을 제공하여, 재생 공격을 방지하기 위한 증명기와 검증기의 근접성을 보장한다. Marforio 등[12]은 일부 전화기에서 사용 가능한 위탁 환경에 의존하는 위치 기반 검증 접근법을 제안한다. Sound-Proof[11]는 휴대폰과 노트북에서 동시에 오디오를 녹음하고 휴대폰에서 두 장치를 비교하여 사용자 장치의 근접성을 입증한다. Sounds-Proof는 원활하고 브라우저와 호환되며 효과적이지만, 휴대폰이 침해되지 않은 경우에만 보안이 유지된다[19]. Listening watch[20]는 두 장치에서 레코딩 역할과 비교 역할을 구분할 것을 제안하며, 또한 서버가 보낸 코드에 대해 오디오를 더욱 특정하게 만든다. 이 작업은 근-원거리 공격에 대해 방어하지만, 여전히 전화 또는 전화와 웹 서버 간의 통신 링크를 손상시키는 데 취약하다. 휴대폰의 수락 또는 거부 메시지가 시계의 응답에 구속되지 않기 때문에, 손상된 휴대폰은 단순히 노트북(브라우저)과 같은 위치에 있는지 확인할 수 있다.
위의 원활한 2FA 기여는 유용성을 개선하지만, 모두 하나의 정보 출처와 하나의 장치에 의존하며, 이는 보안성과 신뢰성을 개선하기 위해 분산 시스템(예, CoRA)으로 대체할 수 있다. 특히, 다른 사용자 장치가 인증 참여를 거부하는 경우에, CoRA는, 개시자 장치가 레벨 1보다 더 나은 토큰을 연산하는 것을 암호화적으로 불가능하게 한다. 또한, 이전 작업은, 모든 전화기가 항상 그런 것은 아닌 보안적인 환경을 갖는다고 명시적으로 또는 암시적으로 가정한다. 비밀의 비밀 공유를 통해, CoRA는, 사용자 장치가 대부분의 IoT 장치의 경우일 수 있는 보안 요소를 갖지 않는 경우에도, 2FA를 개시하기에 충분한 연산력을 갖는 임의의 인접 사용자 장치를 선택할 수 있는 유연성을 허용한다.
[13]의 원활한 인증 시스템은, 또한 사용자를 인증하기 위해 다수의 장치 및 임계값 RSA 서명의 사용을 제안한다. 본 개시의 구현예는 몇 가지 예시적인 방식으로 그들의 접근법 이상으로 개선되고 향상된다: (i) 구현예는 (AES를 사용하는) 임계 MAC의 사용을 가능하게 하여 보다 효율적이고 널리 이용 가능한 구현을 생성한다; (ii) 구현예는 각각이 상이한 비밀 공유 키에 연결된 다수의 보증 레벨을 도입한다; 및 (iii) 구현예는 새로운 사용자 장치와 레벨을 시스템에 추가하기 위한 메커니즘을 제공하며, 이는 각 암호화 인스턴스화에 대한 키 생성 및 공유의 신중한 조절을 필요로 한다.
Truong 등[22; 21]은 여러 채널을 조사하여 근접성을 안전하게 검증하고, 공격자가 동시에 여러 채널을 침해할 수 없는 경우에 여러 소스를 융합하는 것이 보안을 개선할 수 있다라고 결론을 짓는다. 구현예는, 하드웨어와 소프트웨어가 다양하고 동시에 모든 것을 침해하기가 더 어려운 다수의 사용자 장치를 사용함으로써, 이러한 공격자를 방어할 수 있다.
IV.
시스템 아키텍처
예시는 이제 구현예의 아키텍처 및 주요 구성요소를 상세히 기술한다. 먼저, 두 가지 유형의 암호화 체계에 대한 정의가 논의될 것이다. 그 다음, 본 개시의 구현예의 시스템뿐만 아니라 하이-레벨 아키텍처가 설명될 것이다. 개시자 장치 및 인증 장치에 대한 설명이 따른다. 마지막으로, 장치 분류에 대해 논의할 것이다.
A. 정의
두 가지 유형의 암호화 체계, 즉 메시지 인증 코드(MAC)와 디지털 서명이 논의될 것이다. 둘 모두는 명시된 발신자로부터 온 메시지를 확인하는 데 사용된다. MAC는 디지털 서명의 대칭 키(동일한 키 또는 하나의 키) 유사체로서 볼 수 있다. MAC 체계에서, 비밀 키가 메시지를 인증하는 데 사용될 수 있다. 인증된 메시지를 검증하려면 동일한 비밀 키도 필요하다. 반면 디지털 서명 체계에는 서명 키와 검증 키의 두 가지 키가 있다. 이름에서 알 수 있듯이, 서명 키는 메시지에 서명하는 데 사용되는 반면에, 검증 키는 서명이 유효한지 확인하는 데 사용된다. 보안 MAC 체계는, 비밀 키에 대한 지식이 있는 경우에만 메시지를 인증할 수 있음을 보장할 수 있다. 디지털 서명은 유사한 보증을 제공할 수 있다: 서명 키에 대한 지식이 있는 경우에만 메시지에 서명할 수 있다.
MAC 및 디지털 서명 둘 다 임계값 설정에서 연구되었다. Naor 등 [14]은 1999년에 분산형 유사-랜덤 함수(PRF)의 개념을 도입했다. PRF는, 인증된 메시지가 랜덤 문자열처럼 보이는, MAC의 일종이다. 이들은 두 가지 상이한 방식으로 분산 PRF를 구성하였으며, 먼저 결정적 Diffie-Hellman(DDH) 가정이 있는 것으로 여겨지는 순환 그룹에 기초하고 난 다음에 임의의 표준 PRF에 기초하여 구성하였다. 이들 구성은 매우 상이한 특성을 갖고, 섹션 IV.B에서 상세히 논의될 것이다. 디지털 서명 체계는 문헌에서 보다 집중적으로 연구되었다. 디지털 서명 체계(DSS), RSA, Boneh-Lynn-Shacham(BLS), 타원 곡선 디지털 서명 알고리즘(ECDSA) 등과 같은 다양한 표준 서명 체계의 임계값 버전이 제안되었다. RSA [16] 및 BLS [3]의 임계값 버전은 섹션 IV.B에 보다 자세히 기술된다.
본 개시의 구현예는, 이들의 서명 생성 프로세스가 대화형이 아니기 때문에 이들 두 가지 체계를 사용할 수 있다. 메시지가 주어지면, 각각의 사용자 장치는 서명 키의 공유를 사용하여 메시지에 부분 서명을 생성할 수 있다. 그런 다음, 이들 부분 서명은 임의의 적절한 장치(예, 개시자 장치)에 의해 조합될 수 있고, 사용자 장치와의 추가 상호 작용이 필요하지 않으며, 사용자 장치는 서로 통신할 필요가 없을 수 있다.
이제 비-대화형 임계값 인증 체계에서의 알고리즘이 설명될 것이다. 일반적인 정의는, 보다 일반적인 용어를 사용하여 임계 MAC 및 서명 모두에 대해 형태화될 것이다. 구체적으로, 단어 토큰(즉, 인증 토큰)은, MAC의 경우엔 인증된 메시지 대신에 사용되고, 임계값 서명의 경우엔 서명 대신에 사용된다. 비밀 키는 임계값 서명 체계의 서명 키를 지칭할 수 있다. 아래의 설정 알고리즘이 별도의 검증 키를 생성하지만, MAC의 경우엔 비밀 키와 동일한 것으로 이해된다.
임계값 서명에 대한 비-대화형 체계는 네 개의 알고리즘으로 구성될 수 있다: 1) 설정, 2) GenPartTok, 3) 결합, 및 4) 검증. 설정은 사용자 장치 갯수 n 및 임계값 t를 입력으로 취할 수 있고, 검증 키 및 비밀 키의 n 공유 목록을 출력할 수 있다. GenPartTok은 메시지, 및 비밀 키 공유 중 하나를 입력으로서 취할 수 있고, 부분 토큰을 출력할 수 있다. 결합은 적어도 t의 부분 토큰을 입력으로서 취할 수 있고, 이들을 조합하여 전체 토큰을 생성할 수 있다. 마지막으로, 검증은 검증 키와 전체 토큰을 입력으로 가져올 수 있고, 토큰이 유효한 경우에 1을 출력할 수 있다.
다음으로, 임계값 체계의 수준을 논의한다. 임계값 MAC 체계가 3의 임계값을 갖는 경우, 메시지를 적절히 인증하기 위해 적어도 3개의 사용자 장치가 필요하다. 이는 본원에서 고려되는 설정과 같은 특정 상황에서, 예컨대 사용자가 하루 중 특정 시간에 자신의 모든 사용자 장치 중에 1 또는 2개의 사용자 장치를 사용할 수 있는 상황에서는 너무 제한적일 수 있다. 따라서, 임계값 체계를 보다 유연하게 만들기 위해, 레벨의 개념을 정의할 수 있다. 임계 암호화를 사용하는 시스템은 다수의 레벨을 가질 수 있으며, 각각의 레벨은 상이한 임계값과 연관된다. 더 낮은 레벨은 더 낮은 임계값에 대응하고, (더 적은 수의 사용자 장치가 존재해야 하기 때문에) 더 낮은 보증을 제공할 수 있다. 반면, 높은 레벨은 더 많은 사용자 장치를 포함할 수 있고 더 높은 보증을 제공할 수 있다.
구현 관점에서, 각 레벨은 해당 임계값으로 인스턴스화된 임계값 체계의 별도의 인스턴스(즉, 별도의 키 공유, 검증 키 등)일 수 있다. 일부 구현예에서, 시스템 설계자는 요건의 면밀한 연구에 기초하여 각 레벨에 대한 레벨 수 및 임계값을 선택할 수 있다. 다른 구현예에서, 시스템을 사용하는 애플리케이션은 상이한 레벨을 해석하는 방법을 결정할 수 있다. 예를 들어, 결제 애플리케이션은 MAC 레벨이 1로 제시되는 경우에 최대 $5의 이체를 허용할 수 있다. 다른 예시로서, 데이터 전송 애플리케이션은 MAC의 보증 레벨로 태그된 데이터의 전송을 허용할 수 있다.
B. 인증을 위한 임계값 MAC
4개의 상이한 임계값 인증 메커니즘이 논의될 것이다. 1) 임의의 유사 랜덤 함수에 기초한 임계값 메시지 인증 코드(MAC) [14]. 본 개시의 구현예는 AES를 사용할 수 있다. 2) 순환 그룹의 DDH 가정의 경직도에 기초한 임계 MAC [14]. 3) Shoup에 기인한 RSA의 임계 버전 [16]. 4) Gap-Diffie-Hellman의 경직도에 기초한 BLS 서명의 임계 버전 [3].
본 개시의 구현예는 AES-MAC, DDH-MAC, RSA-Sig 및 BLS-Sig를 각각 이들에 대한 약어로 사용할 수 있다. 이들 체계 각각은 그들의 장단점을 갖지만, 본원에 설명된 바와 같이, AES-MAC는 본 개시의 구현예에 가장 적합하다.
토큰 공유뿐만 아니라 인증 토큰도 인증 메커니즘에 이용될 수 있다. 토큰 공유는 인증 토큰의 일부일 수 있다. 토큰 공유는 키 공유로부터 결정될 수 있다. 각각의 사용자 장치는 키 공유를 저장할 수 있으며, 사용자 장치가 토큰 공유를 결정하는 데 이를 사용할 수 있다. 일부 구현예에서, 각각의 사용자 장치는 하나 이상의 키 공유를 저장할 수 있다. 각각의 저장된 키 공유는 보증 레벨에 대응할 수 있으므로, 키 공유로부터 유래된 토큰 공유는 또한 보증 레벨에 대응할 수 있다. 일부 구현예에서, 토큰 공유는, 서명될 데이터 및 키 공유로부터 유래된, 인증 토큰의 일부일 수 있다.
제1 인증 메커니즘은 AES-MAC일 수 있다. Naor 등 [14]은, 임의의 유사-랜덤 함수(PRF)에 기초한 단순 임계 MAC 구성을 제안하였다. PRF는, 키에 대한 지식 없이는 출력을 예측할 수 없는 키 기능일 수 있다. f를 PRF로, n을 총 장치 수로, t를 임계값이라 하자. n개의 장치 세트는 n-t+1 크기의 하위 집합으로 분할될 수 있고, PRF 키는 이들 중 하나와 연관될 수 있다. U를 전체 
키의 전체 모음이라고 하자. U는 마스터 비밀일 수 있다. 장치는 장치에 속한 모든 하위 집합에 대해 키를 받을 수 있으므로, 모든 장치에서 
키를 얻을 수 있다. 즉, 장치의 키 공유는 
PRF 키의 세트에 의해 정의될 수 있다.
메시지 m에 대한 MAC은 
에 대한 모든 fk(m)의 XOR이도록 정의될 수 있다. MAC을 계산하기 위해, m은 n 개의 장치중 임의의 t개에 전송될 수 있다. S를 t개의 장치 세트라 하자. S의 각 장치는 m에 대해 f를, 그가 갖는 각 PRF 키로 평가할 수 있고, 모든 평가를 다시 전송할 수 있다. 크기 n-t+1의 모든 하위 집합은 S와 교차할 수 있으므로 
에 대해 k를 갖는 적어도 하나의 장치가 S에 있을 수 있다. 따라서, 반송된 평가에서, 중복되는 것을 제거하고 나머지는 XOR하여 MAC를 얻을 수 있다.
이제 t-1 개의 장치의 하위 집합 S'을 생각하자. S'와 교차하지 않는 크기 n-t+1의 하위 집합이 적어도 하나 있을 수 있다. 따라서 U에 적어도 하나의 키, 가령 S'의 어떤 장치도 알지 못하는 k*가 있다. 결과적으로 S'은 fk(m)의 출력을 예측할 수 없으므로 m에 대한 MAC를 계산하지 못한다. 장치는 AES를 사용하여 상기 구성에서 PRF f를 인스턴스화할 수 있다. 이는 128 비트의 고정 블록 크기를 가질 수 있는데, 즉 입력과 출력은 128 비트이다. 키 크기는, 예를 들어 원하는 보안 수준에 따라 128, 192 또는 256 비트일 수 있다.
제2 인증 메커니즘은 DDH-MAC일 수 있다. Naor 등은 결정적 Diffie-Hellman(DDH) 문제의 경직도에 기초하여 또 다른 임계 MAC 구성을 제안하였다. p를 큰 솟수로 하고, Zp를 p보다 작은 음이 아닌 정수의 세트라 한다. G를 p 차수의 그룹이라 하고, 여기서 DDH는, 유한 필드에 대해 타원-곡선 그룹과 같이 경직된 것으로 널리 여겨진다. Zp로부터의 랜덤 숫자 s를 마스터 비밀로 선택하고 Shamir 비밀 공유 체계[25]를 사용하여 각 장치에 대해 하나의 공유인 n개의 공유 s1,...,sn으로 나눌 수 있다. 이 공유 체계는, 사용 가능한 공유 수가 t보다 적은 경우에 s를 복구할 수 없는 속성이 있다. 메시지 m에서 부분 MAC를 계산하기 위해, 장치는 m을 해시하여 그룹 요소 h를 얻고 h를 si(G에서의 지수)로 높인다. 부분 평가는, t 지수화를 포함한 Lagrange 보간을 사용하여 조합될 수 있다. 최종 MAC는 hs일 수 있다.
제3 인증 메커니즘은 RSA-Sig일 수 있다. Shoup [16]은 첫 번째 비-대화형 임계값 RSA 서명을 제공하였다. 그의 계획은 일반 RSA와 동일한 방식으로 설정된다. 비밀 키는, Shamir 비밀 공유를 사용하여 이전 체계와 동일한 방식으로 장치 간에 분산된다. 부분 서명을 연산하는 것은 하나의 모듈식 지수화를 수반하는 반면, 부분 값을 조합하는 것은 t+2의 지수화를 필요로 한다.
제4 인증 메커니즘은 BLS-Sig일 수 있다. Boldyreva [3]는 BLS 서명 임계값을 설정하는 간단한 방법을 제안했다. 구성은 상기 DDH-MAC와 매우 유사하지만, 보안은 이제 Gap Diffie-Hellman 문제의 경직도에 의존한다. 마스터 비밀 s의 경우, 검증 키는 gs이고, 여기서 g는 G의 생성기이다. m에 대한 σ 서명을 검증하기 위해, (h, g s , σ)가 유효한 DDH-투플인지, 즉 σ=hs 유무인지 확인할 수 있고, 여기서 h는 m의 해시이다.
이들 체계는 계산 오버헤드(토큰 공유 생성 및 공유 결합용), 스토리지 및 통신 오버헤드(키 공유용, 토큰 공유용 및 토큰용) 및 보안 속성(신규 장치 추가 용이성, 인증 서버 침해에 대한 보안)을 기반으로 비교된다. 이들 각 메트릭은 체계의 보안 파라미터에 따라 달라진다. 128 비트 보안의 경우에, NIST [2]와 ECRYPT-CSA [32]는 AES용 128 비트, RSA용 3072 비트, 그리고 ECC(타원 곡선 암호화)용 256 비트를 추천하고, 이는 DDH-MAC 및 BLS-Sig에 사용될 수 있다. 인구의 대부분이 6개 이하의 장치를 가지고 있기 때문에 최대 6개의 장치를 가정할 것이다 [23]. DDH-MAC와 BLS-Sig 둘 모두는 솟수 차수의 타원형-곡선 그룹으로 인스턴스화될 수 있다. 구체적으로, 곡선 secp256k1 [26]이 사용된다. 아래의 표 1은 4개의 체계의 평가에 대한 요약을 제공한다. 표 1에서, 검증기 침해에 대한 yes 값은 인증 서버가 침해되었을 경우에 체계가 안전하지 않음을 의미한다. 또한, 2.9 GHz Intel Core i7 프로세서 및 16 GB의 메모리를 갖는 MacBook Pro 노트북에서 임계값 MAC 및 서명 연산 시간의 비교를 측정하였다.
표 1 (* AES-MAC에 대한 공유 조합 작업은, 중복 제거 및 XOR만을 수반하므로, 다른 인증 메커니즘과 비교하면 소요 시간은 무시할만하다.)
고정 레벨에 대한 다음 메트릭에 대해 네 개의 체계를 평가할 수 있다. 1) 키 공유 크기: 이는 각 사용자 장치에 지속적으로 저장해야 하는 비밀 데이터의 양이다. 2) 토큰 공유 크기: 이는 각 사용자 장치가 개시자 장치로 보낼 데이터의 양이다. 3) 전체 토큰의 크기: 이는 개시자 장치가 검증기(즉, 인증 서버)에게 보낼 데이터의 양이다. 4) 부분 토큰을 연산하는 데 걸리는 시간: 이는 토큰 공유를 연산하는 데 각 사용자 장치가 소비하는 시간이다. 5) 부분 토큰을 조합하는 시간: 이는 개시자 장치가 토큰 공유를 조합하여 전체 토큰(즉, 인증 토큰)을 연산하는 데 소비하는 시간이다. 6) 장치 추가: 이 메트릭은 신규 사용자 장치를 간단하고 확장 가능한 방식으로 추가하고 키 공유를 제공하는 방법을 설명한다. 7) 검증기 침해에 대한 보안.
다음으로, 임계값 인증 메커니즘에 대해 상기 7개의 메트릭이 논의될 것이다.
키 공유. RSA용 키 공유 크기는 3072 비트일 수 있고, DDH-MAC 및 BLS-Sig용 키공유 크기는 256 비트일 수 있다. AES-MAC용 키 공유 크기는 AES 키 크기의 
배일 수 있고, 최대 1280 비트일 수 있다. 따라서 최악의 경우에도 AES-MAC는 ECC에 기반한 체계보다 약간 더 비싸고, RSA-Sig보다 더 낫다.
토큰 공유. 토큰 공유 크기는 모든 임계값 인증 체계에 대한 키 공유 크기와 유사할 수 있다(포인트 압축은 ECC에 사용될 수 있음[27], AES 블록 크기는 128 비트일 수 있음).
전체 토큰. 전체 토큰 크기는 DDH-MAC, RSA-Sig 및 BLS-Sig에 대한 토큰 공유 크기와 유사하지만, AES-MAC ― 128비트에 대해서는 훨씬 작은데, 그 이유는 최종 토큰은 AES 출력의 XOR이기 때문이다.
토큰 공유를 생성. AES는 최대 
개의 AES 평가가 필요할 수 있지만(이는 최대 10개임), AES 평가는 RSA 또는 ECC에서의 지수화보다 수천 배 더 빠를 수 있다.
공유를 생성. AES-MAC에서 장치는 자기가 갖는 모든 PRF 키에 대해 PRF를 평가한다. 따라서, 
AES 평가를 수행한다. n≤6 에서, l 의 최대값은 t = 3 또는 4에서 10일 수 있다. 반면, 다른 모든 체계는 토큰 공유 생성을 위한 지수화를 필요로 한다. RSA-Sig는 복합 차수의 정수군으로 지수화가 필요하고, DDH-MAC 및 BLS-Sig는 (본원에 설명된 인스턴스화 하에) 타원형-곡선 그룹으로 지수화가 필요하며, 이는 AES 평가보다 100배 이상 느리다. 따라서, AES-MAC가 AES를 10회 평가하더라도, 토큰 공유 생성은 다른 체계보다 훨씬 더 빠를 것이다.
공유를 조합. AES-MAC의 경우 공유를 조합하는 것이 간단하다: 중복 공유를 제거하고 나머지 공유를 XOR하는 반면에, DDH-MAC, RSA-Sig 및 BLS-Sig는 임계값의 크기에 선형적인 지수화가 필요하다. 예를 들어, 장치는 토큰 공유 세트로부터 중복된 토큰 공유를 제거한 다음에, 토큰 공유 세트로부터 남은 토큰 공유를 XOR하여 인증 토큰을 결정할 수 있다. 구체적으로, DDH-MAC 및 BLS-Sig는 t 지수화가 필요 없고 RSA-Sig는 t + 2가 필요하다. 이들 세 가지 체계는 다른 그룹 연산도 하지만 지수화가 지배적이다. 따라서, AES-MAC는 이러한 양태에서 다른 체계를 상당히 능가한다. t = 3은 위의 표 1에서 조합 시간을 보고하기 위해 사용된다. t = 3을 선택할 수 있고, 그 이유는 3이 중간 임계 값이기 때문이다; 이는 AES-MAC에 대한 최악의 시나리오이다; 그리고 다른 체계는 더 높은 임계 값에서만 더 나쁘게 수행될 것이다.
장치 추가. 신규 사용자 장치를 추가하려면, 마스터 비밀의 공유를 생성해야 한다. 대칭 키 인증(MAC)의 경우, 검증기는 마스터 비밀을 갖고 신규 사용자 장치를 추가하는 데 도움을 줄 수 있다. 반면, 비대칭 인증(서명)의 경우, 등록된 사용자 장치 자체는 신규 사용자 장치가 마스터 비밀의 공유를 얻는 데 도움이 될 것이다. 이를 위해서는, 안전한 다자간 계산과 같은 고급 툴을 사용해야 한다. 적어도 t개의 사용자 장치는 동시에 온라인 상태여야 하며 여러 라운드에 걸쳐 서로 통신해야 한다 [30].
검증기 침해. 대칭 인증은 새로운 사용자 장치를 쉽게 추가할 수 있게 하지만, 이는 구현을 검증기 침해에 취약하게 만들 수 있다. 예를 들어, 인증 서버가 악의적인 당사자에 의해 침해되는 경우에 검증기 침해가 발생할 수 있다.
C. 비밀 공유분
일부 구현예에서, 토큰 공유는 비밀 공유 시스템에 기초하거나 이로부터 유래될 수 있다. 비밀 공유 시스템은 m/n 비밀 공유 시스템일 수 있다. 이러한 시스템에서, 총 비밀 공유분 수 n 중 m 개의 비밀 공유분(즉 토큰 공유분) 모음이, 공유 암호(즉, 인증 토큰)를 생성하거나 재생성하는 데 충분할 수 있다. 이들 비밀 공유분은 공유 비밀(또는 "비밀"), 예컨대 키 공유분에서 파생될 수 있으며 사용자 장치 네트워크의 다른 장치에서 숨겨질 수 있다.
비밀 공유 방법 하나는 Shamir의 비밀 공유이다. Shamir의 비밀 공유를 이용하면, 공유 비밀은 다항식 P(x)의 계수, 보통 0차 계수 P(O)로서 암호화된다. 다항식의 자유도(계수의 수보다 하나 미만, 또는 다항식에서 가장 큰 차수항)는 값 m-1과 같다. 다항식의 계수는 무작위로 또는 다른 적합한 방법을 통해 생성될 수 있다. n 개 지원 장치 각각은 그 비밀 공유분으로서 다항식의 하나 이상의 샘플링된 값이 주어질 수 있다. 예를 들어, 5개의 장치 그룹에서 첫 번째 장치는 P(1)과 P(2)를 구비할 수 있고, 두 번째는 P(3)와 P(4) 등등 그리고 다섯 번째 장치는 P(9) 및 P(10)를 구비한다. 이는 적절한 보안 프로비저닝 시스템을 사용하여 수행될 수 있다. 예를 들어, 위탁 외부 서버는 사용자 장치 네트워크의 각 지원 장치와 Diffie-Hellman 키 교환을 수행할 수 있다. 그런 다음 위탁 외부 서버가 비밀 공유분을 그들의 해당 장치에 송신할 수 있다.
m 이 n 미만인 경우, m 개 비밀 공유분이 주어진 다항식 P(x) 를 재구성하는 것이 가능하다. 이것은, m 개 고유점이 m-1 자유도의 다항식을 유일하게 정의하는 사실의 결과이다. Lagrange 다항식의 사용과 같은 다항식 보간 형태를 통해 다항식을 재구성할 수 있다.
다항식을 일단 구성하면, P(O) 값은 암호화 프로세스의 일부로서 결정되고 사용될 수 있다. 예를 들어, P(O) 값은 암호화 장치에 의해 암호화 키로 사용될 수 있다. 대안적으로, 비밀 공유분과 공유 비밀은 그 값이 위장되도록 보다 복잡한 작업의 일부로서 사용될 수 있다. P(O)가 재구성되는 대신에, P(O)로부터 파생되거나 연관된 값이 재구성될 수 있다. 또한, 생성된 값은 일반적으로 암호화 임시값과 연관되며, 1회 무작위로 생성된 값이다. 이러한 방식으로 공유 비밀은 숨긴 채로 남지만, 이로부터 파생된 값을 암호화 및 복호화 장치에 의해 일관되게 생성될 수 있다. 따라서, 상기 값은 대칭 암호화 키로서 사용될 수 있거나 대칭 암호화 키를 도출하는 데 사용될 수 있고, 암호화 장치로 하여금 인증 암호를 생성시키고 복호화 장치로 하여금 이를 해독시킨다.
Shamir의 비밀 공유는, 비밀 공유분을 분배하는 데 사용되는 많은 방법 중 하나로서 공유 비밀이 재구성될 수 있다. 다른 많은 방법이 있으며, 상기 설명은 비제한적인 예로서 의도된다. 추가의 세부 사항은 PCT 출원 번호 PCT/US2018/025089를 참조하며, 이는 그 전체가 모든 목적을 위해 참조로서 본원에 포함된다.
D. 시스템 개요
도 2는 본 개시의 일부 구현예에 따른 다수의 구성 요소를 포함한 시스템(200)의 블록 다이어그램을 나타낸다. 시스템(200)은, 제1 인증 장치(210) 내지 제N 인증 장치(212), 개시자 장치(220), 사용자 장치(230), 및 인증 서버(240)를 포함한다.
제1 인증 장치(210)는 제N 인증 장치(212)와 동작 가능하게 통신할 수 있다. 일부 구현예에서, 임의의 적절한 수, 예를 들어 3, 4, 5, 10 등의 인증 장치가 있을 수 있다. 각각의 인증 장치는 서로 통신 가능하게 작동할 수 있다.
개시자 장치(220)는, 사용자 장치(230)뿐만 아니라 각 인증 장치(예, 제1 인증 장치(210) 내지 제N 인증 장치(212))와 통신 가능하게 작동할 수 있다. 일부 구현예에서, 개시자 장치(220)는 인증 서버(240)와 통신 가능하게 작동할 수 있다. 사용자 장치(230)는, 인증 서버(240)뿐만 아니라 개시자 장치(220)와도 통신 가능하게 작동할 수 있다.
도 2에 나타낸 실체, 제공자, 네트워크, 및 장치 간의 메시지는, 이에 한정되지는 않지만, FTP(File Transfer Protocol); HTTP(HyperText Transfer Protocol); HTTPS(Secure Hypertext Transfer Protocol), SSL(Secure Socket Layer), ISO(예, ISO 8583) 및/또는 기타 등등과 같은, 보안 통신 프로토콜을 사용한 통신 네트워크를 사용하여 전송될 수 있다. 통신 네트워크는 임의의 적절한 통신 매체를 포함할 수 있다. 통신 네트워크는, 직접적인 상호 접속; 인터넷; 근거리 통신망(LAN); 대도시 지역 네트워크(MAN); 인터넷 상의 노드로서의 운영 임무(OMNI); 보안 커스텀 접속(secured custom connection); 광역 네트워크(WAN); 무선 네트워크(예, 한정되는 것은 아니지만, 무선 애플리케이션 프로토콜(WAP), I-모드 및/또는 이와 유사한 것들과 같은 프로토콜을 채용); 및/또는 이와 유사한 것들 중 하나 및/또는 이들의 조합일 수 있다.
제1 인증 장치(210), 제N 인증 장치(212), 개시자 장치(220), 및 사용자 장치(230)는, 이들이 사용자에 의해 소유 및/또는 작동되기 때문에, 모두 사용자 장치일 수 있다. 이들 장치(즉, 제1 인증 장치(210), 제N 인증 장치(212), 개시자 장치(220), 및 사용자 장치(230))는 노트북, 데스크톱 컴퓨터, 음성 제어 어시스턴트, 스마트 폰, 스마트 워치, 스마트 카, 스마트 TV, 비디오 게임 콘솔 등과 같은 전자 장치를 포함할 수 있다. 일부 구현예에서, 사용자 장치(230)는 개시자 장치(220)일 수 있다.
일례로, 사용자 장치(230)는, 사용자가 인증 서버(240)와 통신하도록 작동할 수 있는, 노트북 컴퓨터일 수 있다. 개시자 장치(220)는, 개시자 장치(220)와 통신(예, 블루투스 통신)할 수 있는 사용자의 스마트 폰일 수 있다. 제1 인증 장치(210) 및 제N 인증 장치(212)는, 각각 스마트 TV 및 음성 제어 어시스턴트일 수 있다.
인증 서버(240)는 서버 컴퓨터일 수 있다. 단계 1에서, 인증 서버(240)는, 사용자 이름 및 암호와 같은 크리덴셜을 사용자 장치(230)로부터 수신하도록 구성될 수 있다. 단계 2에서, 인증 서버(240)는 또한, 챌린지 요청을 생성하고 사용자 장치(230)에 송신하도록 구성될 수 있다. 일부 구현예에서, 챌린지 요청은 크리덴셜 이상으로 사용자에 대한 추가 인증을 요청할 수 있다. 단계 7에서, 인증 서버(240)는 인증 토큰을 수신하고 검증하도록 구성될 수도 있다.
사용자 장치(230)는, 사용자로부터 크리덴셜을 수신한 다음에, 단계 1에서, 크리덴셜을 인증 서버(240)에 송신하도록 구성될 수 있다. 사용자 장치(230)는, 단계 2에서, 인증 서버(240)로부터의 챌린지 요청을 수신하고, 단계 3에서, 챌린지 요청을 개시자 장치(220)에 전달하도록 구성될 수도 있다.
단계 3에서, 개시자 장치(220)는 챌린지 요청을 수신할 뿐만 아니라 관찰자 요청을 생성하도록 구성될 수 있다. 일부 구현예에서, 관찰자 요청은 토큰 공유에 대한 요청을 포함할 수 있다. 단계 4에서, 개시자 장치(220)는, 관찰자 요청을 하나 이상의 인증 장치(즉, 제1 인증 장치(210) 및 제N 인증 장치(212))에 전송할 수 있다. 개시자 장치(220)는 또한 단계 5에서, 하나 이상의 인증 장치로부터 토큰 공유 및 보증 레벨을 포함한 적어도 하나의 관찰자 응답을 수신하도록 구성될 수 있다. 일반적으로, 개시자 장치(220)는 하나 이상의 인증 장치 각각으로부터 관찰자 응답을 수신할 수 있다. 그러나, 개시자 장치(220)는, 접속 손실, 인증 장치 전력 손실 등과 같은 임의의 이유로 인해 인증 장치로부터 관찰자 응답을 수신하지 못할 수 있다. 각각의 관찰자 응답은, 하나 이상의 토큰 공유를 포함할 수 있으며, 여기서 각각의 토큰 공유는 고유한 보증 레벨에 대응한다. 예를 들어, 관찰자 응답은 세 개의 토큰 공유를 포함할 수 있으며, 세 개의 토큰 공유 각각은 상이한 보증 레벨에 대응한다.
개시자 장치(220)는, 최고 보증 레벨을 결정하도록 추가로 구성될 수 있고, 최고 보증 레벨에 대해 수신된 토큰 공유로부터 인증 토큰을 생성할 수 있다. 개시자 장치(220)는, 또한 단계 6 및 단계 7에서, 사용자 장치(230)를 통해 인증 서버(240)에 인증 토큰을 송신하도록 구성될 수 있다. 일부 구현예에서, 개시자 장치(220)는 인증 토큰을 인증 서버(240)에 직접 송신하도록 구성될 수 있다.
제1 인증 장치(210)는, 단계 4에서, 개시자 장치(220)로부터 관찰자 요청을 수신하도록 구성될 수 있다. 제1 인증 장치(210)는 또한 신뢰도 점수에 기초하여 개시자 장치와 연관된 보증 레벨을 결정하도록 구성될 수 있다. 제1 인증 장치(210)는, 또한 제1 보증 레벨보다 낮은 보증 레벨이 존재하는 경우에 낮은 보증 레벨에 대응하는 임의의 다른 토큰 공유(들) 및 제1 보증 레벨에 대응하는 토큰 공유를 획득하도록 구성될 수 있고, 그 다음 단계 5에서, 토큰 공유(들)를 개시자 장치(220)에 송신한다.
제N 인증 장치(212)는 제1 인증 장치와 유사할 수 있다. 일부 구현예에서, 제N 인증 장치(212)는 제1 인증 장치(210)와 유사한 기능을 수행하도록 구성될 수 있다.
E. 사용 예시
도 3은 본 개시의 구현예를 구현하기 위한 예시적인 장치 세트를 나타낸다. 도 3은 다수의 구성 요소를 포함하는 시스템(300)을 나타낸다. 시스템(300)은 스마트 워치(310), 음성 제어 어시스턴트(320), 스마트 TV(330), 스마트 폰(340), 노트북(350), 및 인증 서버(360)를 포함한다. 스마트 워치(310), 음성 제어 어시스턴트(320), 및 스마트 TV(330)는 인증 장치일 수 있다. 스마트 폰(340)은 개시자 장치일 수 있다. 노트북(350)은 사용자 장치일 수 있다.
사용자는 자신의 크리덴셜(예, 사용자 이름 및 암호)을 노트북(350)의 브라우저에 입력할 수 있다. 단계 1에서, 노트북(350)은 크리덴셜을 인증 서버(360)에 송신할 수 있다. 인증 서버(360)는 크리덴셜이 유효한지 여부를 결정할 수 있다. 인증 서버(360)가 크리덴셜을 검증할 수 있는 경우에, 단계 2에서, 인증 서버(360)는 MFA 챌린지(즉, 챌린지 요청)를 노트북(350)에 송신할 수 있다.
단계 3에서, 챌린지 요청을 수신한 이후에, 노트북(350)은 챌린지 요청을 스마트 폰(340)(또는 현재 임의의 다른 사용자 장치)에 전송할 수 있다. 단계 4에서, 스마트 폰(340)은, (관찰자 요청을 송신하는 데 사용되는 통신 채널에 의존할 수 있는, 예를 들어 10피트, 20피트, 50피트, 200피트 등) 가까운 사용자 장치에 관찰자 요청 메시지를 송신함으로써, 하나 이상의 인증 장치와의 통신을 개시할 수 있다. 사용자 장치(예, 스마트 워치(310), 음성 제어 어시스턴트(320), 및 스마트 TV(330))가 스마트 폰(340)을 신뢰하고(신뢰도 점수를 사용하여 결정됨) 또한 스마트 폰(340)이 근접해 있음을 결정하는 경우에, 인증 장치는 챌린지에 대한 MAC(예, 인증 토큰)을 생성하기 위해 스마트 폰(340)과 협업할 수 있다. 단계 5에서, 스마트워치(310), 음성 제어 어시스턴트(320), 및 스마트 TV(330)는 토큰 공유를 스마트 폰(340)에 송신할 수 있다.
스마트 폰(340)이 인증 토큰을 생성한 후에, 단계 6에서, 스마트 폰(340)은 인증 토큰뿐만 아니라 해당 보증 레벨을 랩톱 컴퓨터(350) 및/또는 인증 서버(360)에 송신할 수 있다. 인증 토큰을 수신하면, 인증 서버(360)는 인증 토큰을 검증할 수 있고, 사용자가 인증될 수 있는지 여부를 결정할 수 있다.
도 4는 개시자 장치(400)에 의해 수신된 토큰 공유를 나타낸다. 개시자 장치(400)는 스마트 폰(340)일 수 있다. 스마트 폰(340)은, 인증 장치 1, 인증 장치 2, 및 인증 장치 3으로 각각 라벨링된, 스마트 워치(310), 음성 제어 어시스턴트(320), 및 스마트 TV(330)와 같은 인증 장치로부터 토큰 공유를 수신할 수 있다. 스마트 폰(340)이 수신하는 각각의 토큰 공유는, 보증 레벨과 연관될 수 있다. 나타낸 토큰 공유는, 예를 들어 메모리 또는 다른 적절한 저장 구성 요소에 저장될 수 있다.
전술한 도 3의 단계 5 동안에, 스마트 폰(340)은 인증 장치로부터 토큰 공유를 수신할 수 있다. 스마트 폰(340)에 의해 수신된 토큰 공유는 도 4에 도시되어 있다. 스마트 폰(340)은, 보증 레벨 4, 보증 레벨 3, 보증 레벨 2, 및 보증 레벨 1 각각에 대응하는 토큰 공유를 포함한 4개의 토큰 공유를 인증 장치 1로부터 수신할 수 있다. 스마트 폰(340)은, 보증 레벨 3, 보증 레벨 2, 및 보증 레벨 1의 각각에 대응하는 토큰 공유를 포함한 3개의 토큰 공유를 인증 장치 2로부터 수신할 수 있다. 스마트 폰(340)은, 또한 보증 레벨 2에 대응하는 토큰 공유 및 보증 레벨 1에 대응하는 토큰 공유를 포함한, 두 개의 토큰 공유를 인증 장치 3으로부터 수신할 수 있다.
특정 보증 레벨에 대한 인증 토큰을 결정하기 위해, 스마트 폰(340)은, 특정 보증 레벨에 대응하는 토큰 공유의 적어도 임계 수가 있는지 여부를 결정할 수 있다. 예를 들어, 보증 레벨 4에 대응하는 토큰 공유의 임계 수는 6과 같을 수 있고, 보증 레벨 3에 대응하는 토큰 공유의 임계 수는 5와 같을 수 있고, 보증 레벨 2에 대응하는 토큰 공유의 임계 수는 3과 같을 수 있고, 보증 레벨 1에 대응하는 토큰 공유의 임계 수는 1과 같을 수 있다. 각각의 보증 레벨은, 임의의 적절한 토큰 공유 임계 수에 대응할 수 있다.
스마트 폰(340)은, 보증 레벨 4를 위해 적어도 6개의 토큰 공유를 보유하지 않는 것으로 결정할 수 있다. 그 다음, 스마트 폰(340)은 보증 레벨 3을 위해 적어도 5개의 토큰 공유를 보유하지 않는 것으로 결정할 수 있다. 그 다음, 스마트 폰(340)은 보증 레벨 2를 위해 적어도 3개의 토큰 공유를 보유하는지 결정할 수 있다. 그 다음, 스마트 폰(340)은 본원에 기술된 임의의 적절한 방법을 사용하여 보증 레벨 2에 대응하는 3개의 토큰 공유를 조합할 수 있다. 이 예시에서, 토큰 공유의 임계 수가 설명되지만, 본원에서 더 상세히 설명되는 바와 같이, 토큰 공유의 양이 결정되고 토큰 공유의 임계 양과 비교될 수 있는 것으로 이해된다.
F. 개시자 장치
도 5는 본 개시의 구현예에 따라, 개시자 장치(500)를 나타낸다. 예시적인 개시자 장치(500)는 프로세서(502)를 포함할 수 있다. 프로세서(502)는 메모리(504), 출력 요소(506), 입력 요소(508), 네트워크 인터페이스(510), 및 컴퓨터 판독가능 매체(512)에 결합될 수 있다. 컴퓨터 판독가능 매체(512)는, 보증 레벨 모듈(512A) 및 인증 토큰 모듈(512B)을 포함할 수 있다. 일부 구현예에서, 컴퓨터 판독가능 매체(512)는 또한 신뢰도 점수 모듈을 포함할 수 있으며, 이는 이하에서 더욱 상세히 설명되는 신뢰도 점수 모듈(612A)과 유사할 수 있다.
메모리(504)는, 데이터, 정보 및/또는 코드를 저장할 수 있는 임의의 적절한 메모리일 수 있다. 메모리(504)는 키 공유, 토큰 공유, 및/또는 신뢰도 점수(들)를 저장할 수 있다. 메모리(504)는 보안 메모리일 수 있다. 키 공유, 토큰 공유, 및 신뢰도 점수(들)는 본원에 설명된 임의의 적절한 방법을 사용하여, 예를 들어 보증 레벨 모듈(512A), 인증 토큰 모듈(512B), 및 신뢰도 점수 모듈을 각각 사용하여 결정될 수 있다.
하나 이상의 출력 요소(506)는, 데이터를 출력할 수 있는 임의의 적절한 장치(들)를 포함할 수 있다. 출력 요소(506)의 예시는 디스플레이 스크린, 스피커, 및 데이터 전송 장치를 포함할 수 있다.
하나 이상의 입력 요소(508)는, 개시자 장치(500)로 데이터를 입력할 수 있는 임의의 적절한 장치(들)를 포함할 수 있다. 입력 장치의 예는 버튼, 터치스크린, 터치 패드, 마이크로폰 등을 포함한다.
컴퓨터 판독가능 매체(512)는 프로세서(502)에 의해 다음 방법을 구현하기 위해 실행 가능한 코드를 포함할 수 있고, 상기 방법은, 개시자 장치에 의해, 하나 이상의 인증 장치로 관찰자 요청을 전송하되 상기 하나 이상의 인증 장치는 보증 레벨의 범위로부터 보증 레벨을 결정하고 상기 보증 레벨에 대응하는 토큰 공유를 결정하는 단계; 상기 개시자 장치에 의해, 상기 하나 이상의 인증 장치로부터 상기 보증 레벨에 대응하는 상기 토큰 공유를 포함한 적어도 하나의 관찰자 응답을 수신하는 단계; 상기 개시자 장치에 의해, 토큰 공유 세트를 사용하는 인증 토큰을 생성하는 단계; 및 상기 개시자 장치에 의해, 상기 인증 토큰을 인증 서버로 전송하되, 상기 인증 서버는 상기 인증 토큰을 검증하는 단계를 포함한다.
보증 레벨 모듈(512A)은, 보증 레벨을 결정하기 위해 프로세서(502)에 의해 실행 가능한 코드 또는 소프트웨어를 포함할 수 있다. 예를 들어, 보증 레벨 모듈(512A)은 신뢰도 점수(들), 인증 시간, 인증 위치, 인증 이력, 사용자 선호도, 토큰 공유(들) 등에 기초하여 보증 레벨을 결정할 수 있다. 보증 레벨 모듈(512A)은 보장 레벨 범위의 최고 보장 레벨을 결정할 수 있다. 보증 레벨의 범위는, 인증 장치(들)로부터 수신되는 토큰 공유 세트에 연관될 수 있다. 보증 레벨 모듈은, 적어도 토큰 공유의 임계 수를 포함하는, 최고 보증 레벨을 결정할 수 있다.
일부 구현예에서, 보증 레벨 모듈(512A)은, 미리 결정된 제1 양을 임계량과 비교함으로써, 토큰 공유의 적어도 임계량을 포함한 토큰 공유 세트와 연관된 보증 레벨 범위의 제1 보증 레벨을 결정할 수 있다. 토큰 공유의 제1 양은, 토큰 공유 세트의 가중치를 합산함으로써 결정될 수 있다. 일부 구현예에서, 가중치에 대해 값이 높을수록, 토큰 공유가 더 안전함을 나타낼 수 있다.
각각의 토큰 공유는, 보증 레벨과 연관될 수 있다. 일부 구현예에서, 개시자 장치(500)는, 토큰 공유와 보증 레벨을 포함한, 데이터 아이템을 수신할 수 있다. 데이터 아이템은, 두 개의 데이터 필드, 즉 토큰 공유를 포함한 제1 데이터 필드, 및 대응하는 보증 레벨을 포함한 제2 데이터 필드를 포함할 수 있다.
예를 들어, 보증 레벨의 범위는 5개의 보증 레벨(예, 보증 레벨 1, 보증 레벨 2 및 보증 레벨 3)을 포함할 수 있다. 보증 레벨 모듈(512A)은, 개시자 장치(500)가 토큰 공유 세트에서 7개의 토큰 공유를 보유하는지 결정할 수 있다. 5개의 토큰 공유는, 보증 레벨 3에서 하나의 토큰 공유, 보증 레벨 2에서 세 개의 토큰 공유, 및 보증 레벨 1에서 세 개의 토큰 공유를 포함할 수 있다. 보증 레벨 3을 위한 토큰 공유의 임계 수가 두 개의 토큰 공유와 동일한 경우에, 보증 레벨 모듈(512A)은, 개시자 장치(500)가 보증 레벨 3에서 인증 토큰을 생성하기에 충분한 토큰 공유를 보증 레벨 3에서 갖지 않는다고 결정할 수 있다. 그 다음, 보증 레벨 모듈(512A)은 다음 보증 레벨(예, 보증 레벨 2)을 평가할 수 있다. 보증 레벨 3을 위한 토큰 공유의 임계 수가 두 개의 토큰 공유와 동일한 경우에, 보증 레벨 모듈(512A)은, 개시자 장치(500)가 보증 레벨 2에서 인증 토큰을 생성하기에 충분한 토큰 공유를 보증 레벨 2에서 소유하는지 결정할 수 있다. 보증 레벨 모듈(512A)은 최고 보증 레벨이 보증 레벨 2라고 결정할 수 있다.
인증 토큰 모듈(512B)은, 인증 토큰을 생성하기 위해 프로세서(502)에 의해 실행 가능한 코드 또는 소프트웨어를 포함할 수 있다. 인증 토큰 모듈(512B)은, 최고 보증 레벨과 연관된 하나 이상의 인증 장치로부터 수신된 토큰 공유 세트를 사용하여, 인증 토큰을 생성할 수 있다.
네트워크 인터페이스(510)는, 개시자 장치(500)를 외부 컴퓨터와 통신시킬 수 있는 인터페이스를 포함할 수 있다. 네트워크 인터페이스(510)는, 개시자 장치(500)가 다른 장치(예, 사용자 장치, 인증 장치, 인증 서버 등)와 데이터를 통신할 수 있게 한다. 네트워크 인터페이스(510)의 일부 예시는 모뎀, (이더넷 카드 또는 다른 네트워크 인터페이스 카드(NIC)와 같은) 물리적 네트워크 인터페이스, 가상 네트워크 인터페이스, 통신 포트, PCMCIA(Personal Computer Memory Card International Association) 슬롯 및 카드 등을 포함할 수 있다. 네트워크 인터페이스(510)에 의해 사용 가능한 무선 프로토콜은 Wi-FiTM를 포함할 수 있다. 네트워크 인터페이스(510)를 통해 전송되는 데이터는, 외부 통신 인터페이스에 의해 수신될 수 있는 전기, 전자기, 광학 신호의 형태, 또는 임의의 다른 신호일 수 있다("전자 신호" 또는 "전자 메시지"로 총칭함). 데이터 또는 명령어를 포함할 수 있는 이들 전자 메시지는, 통신 경로 또는 채널을 통해 네트워크 인터페이스(510)와 다른 장치 사이에 제공될 수 있다. 전술한 바와 같이, 예를 들어 와이어 또는 케이블, 광섬유, 전화선, 셀룰러 링크, 무선 주파수(RF) 링크, WAN 또는 LAN 네트워크, 인터넷, 또는 임의의 다른 적절한 매체와 같은 임의의 적절한 통신 경로 또는 채널이 사용될 수 있다.
G. 인증 장치
도 6은 본 개시의 구현예에 따른 인증 장치(600)를 나타낸다. 예시적인 인증 장치(600)는 프로세서(602)를 포함할 수 있다. 프로세서(602)는 메모리(604), 출력 요소(606), 입력 요소(608), 네트워크 인터페이스(610), 및 컴퓨터 판독가능 매체(612)에 결합될 수 있다. 컴퓨터 판독가능 매체(612)는, 신뢰도 점수 모듈(612A), 보증 레벨 모듈(612B), 및 토큰 공유 모듈(612C)을 포함할 수 있다.
메모리(604)는, 데이터, 정보 및/또는 코드를 저장할 수 있는 임의의 적절한 메모리일 수 있다. 메모리(604)는 키 공유, 토큰 공유, 및/또는 신뢰도 점수를 저장할 수 있다. 메모리(604)는 보안 메모리일 수 있다.
하나 이상의 출력 요소(606)는 하나 이상의 출력 요소(506)와 유사할 수 있고, 하나 이상의 입력 요소(608)는 하나 이상의 입력 요소(508)와 유사할 수 있고, 네트워크 인터페이스(510)는 네트워크 인터페이스(510)와 유사할 수 있고 본원에서 반복되지 않을 것이다.
컴퓨터 판독가능 매체(612)는 프로세서(602)에 의해 다음 방법을 구현하기 위해 실행 가능한 코드를 포함할 수 있고, 상기 방법은, 인증 장치에 의해, 개시자 장치로부터 관찰자 요청을 수신하는 단계; 상기 인증 장치에 의해, 신뢰도 점수에 기초하여 상기 개시자 장치와 연관된 제1 보증 레벨을 결정하되, 상기 제1 보증 레벨은 보증 레벨의 범위로부터 결정되는 단계; 상기 인증 장치에 의해, 상기 제1 보증 레벨에 대응하는 토큰 공유를 획득하는 단계; 및 상기 인증 장치에 의해, 상기 개시자 장치로 상기 제1 보증 레벨에 대한 토큰 공유를 전송하는 단계를 포함한다.
신뢰도 점수 모듈(612A)은, 신뢰도 점수를 결정하기 위해, 프로세서(602)에 의해 실행 가능한 코드 또는 소프트웨어를 포함할 수 있다. 신뢰도 점수 모듈(612A)은, 인증 장치(600)에 의해 로컬로 관찰된 특징부, 다른 장치로부터 수신된 데이터, 및/또는 다른 장치에 의해 수신된 신뢰도 점수에 기초하여 (인증 장치(600)의) 신뢰도 점수를 결정할 수 있다. 예를 들어, 인증 장치(600)는, 데이터 전송 속도(예, 1초, 2초, 5초 등과 같은 시간의 윈도우에 걸친 kb/s), 데이터 수신 속도, 데이터 패킷의 평균 크기, 소스 주소, 도메인 이름 시스템(DNS) 정보, IP 주소, 호스트 이름, 신호 강도 데이터, Wi-Fi 연결 데이터 등을 포함할 수 있는, 네트워크 데이터와 같은 데이터를 다른 장치로부터 수신할 수 있다. 신뢰도 점수 모듈(612A)은, 또한 데이터 및/또는 특징부, 예컨대 결제 이력(예, 장치가 결제를 수행하는 빈도, 가맹점 정보, 결제 금액, 등), 장치 구성(예, 소프트웨어 버전, 보안 요소 데이터, 등). 이전 암호화 임계값 데이터(예, 과거에 성공 및/또는 실패한 상호작용의 기록, 장치가 인증에 참여하는 빈도에 대한 기록, 등). 및 시스템의 다른 장치로부터 수신된 신뢰도 점수에 기초해서, 신뢰도 점수를 결정할 수 있다. 일부 구현예에서, 신뢰도 점수 모듈(612A)은, 의사 결정 트리, 신경망 및 회귀(예, 로지스틱 또는 선형)와 같은 머신 러닝 알고리즘을 사용하여, 신뢰도 점수를 결정할 수 있다. 예를 들어, 결정 트리는, 전술한 네트워크 데이터뿐만 아니라 임의의 다른 적절한 데이터에 기초하여 결정을 결정할 수 있다. 일부 구현예에서, 전송 속도와 같은 일부 특징부는, 신뢰도 점수를 결정하는 경우에 IP 주소와 같은 다른 특징부보다 머신 러닝 모델에서 더 가중치 부여될 수 있다.
네트워크 데이터는 신뢰도 점수에 영향을 줄 수 있다. 예를 들어, 개시자 장치가 평균 전송 속도보다 훨씬 더 높다고 네트워크 데이터가 표시하는 경우에(예, 개시자 장치 장치가 다른 장치보다 3-10배 더 많은 데이터를 송신하는 경우에), 신뢰도 점수 모듈(612A)은, 개시자 장치에 대한 낮은 신뢰도 점수를 결정할 수 있다(즉, 신뢰성이 더 낮음). 다른 예시로서, 개시자 장치가 낮은 데이터 수신 속도를 갖는 것으로 네트워크 데이터가 표시하는 경우에, 신뢰도 점수 모듈(612A)은 더 낮은 신뢰도 점수를 결정할 수 있고, 이는 개시자 장치가 다른 장치로부터 메시지를 수신하지 않기 때문이다. 예를 들어, 이는, 다른 장치가 개시자 장치를 신뢰하지 않음을 나타낼 수 있다.
또한, 개시자 장치가 평균 데이터 패킷 크기와 대략 동일한 크기의 데이터 패킷을 전송하고 있음을 네트워크 데이터가 나타내는 경우에, 신뢰도 점수 모듈(612A)은 개시자 장치에 대한 더 높은 신뢰도 점수를 결정할 수 있다(즉, 더 신뢰성이 높음).
또 다른 예시로서, 신뢰도 점수 모듈(612A)은, 개시자 장치가 IP 주소, 호스트 이름, 도메인 이름 시스템 정보, 및/또는 블랙리스트에 포함된 소스 주소를 갖는 경우에 낮은 신뢰도 점수를 결정할 수 있다. 신뢰도 점수 모듈(612A)은, 예를 들어 개시자 장치의 IP 주소를, 저장된 블랙리스트에 포함된 복수의 IP 주소와 비교할 수 있다. 개시자의 IP 주소가 저장된 블랙리스트에 포함된 IP 주소와 일치하는 경우에, 신뢰도 점수 모듈(612A)은 개시자 장치에 대한 낮은 신뢰도 점수(예, 0)를 결정할 수 있다.
신뢰도 점수 모듈(612A)은 신호 강도 데이터에 기초하여 신뢰도 점수를 결정할 수 있다. 예를 들어, 신호 강도 데이터가, 인증 장치(600)와 개시자 장치 사이의 낮은 신호 강도를 나타내는 경우에, 신뢰도 점수 모듈(612A)은 낮은 신뢰도 점수를 결정할 수 있다. 반대로, 신호 강도 데이터가 두 개의 장치 사이의 강한 신호를 나타내는 경우에, 신뢰도 점수 모듈은 더 높은 신뢰도 점수를 결정할 수 있다. 또한, 일부 구현예에서, 인증 장치(600)가 개시자 장치를 Wi-Fi 연결을 통해 연결될 수 있음을 네트워크 데이터가 나타내는 경우, 신뢰도 점수 모듈(612A)은 더 높은 신뢰도 점수를 결정할 수 있다. 일부 구현예에서, 신뢰도 점수 모듈(612A)은 본원에 설명된 방법의 조합을 사용하여 신뢰도 점수를 결정할 수 있다.
예를 들어, 일부 구현예에서, 신뢰도 점수 모듈(612A)은 [7, 15]에 설명된 바와 같이 분산된 침입 감지 기법을 사용하여 신뢰도 점수를 결정할 수 있다.
일부 구현예에서, 신뢰도 점수 모듈(612A)은 하나 이상의 신뢰도 점수를 결정할 수 있으며, 여기서 각각의 신뢰도 점수는 네트워크 내의 상이한 장치(예, 사용자 장치)에 대응한다. 일례로, 하나 이상의 신뢰도 점수는 [10]에 설명된 바와 같이 Eigen-Trust에 의해 확립된 일시적 신뢰도에 기초한다.
신뢰도 점수 모듈(612A)은 신뢰도 점수(들)를 출력할 수 있다. 신뢰도 점수(들)는 보증 레벨 모듈(612B)에 대한 입력으로서 사용될 수 있으며, 인증 장치(600)는, 인증 장치(600)가 인증 프로세스 동안에 참여할, 보증 레벨을 결정할 수 있다.
보증 레벨 모듈(612B)은, 보증 레벨을 결정하기 위해 프로세서(602)에 의해 실행 가능한 코드 또는 소프트웨어를 포함할 수 있다. 보증 레벨 모듈(612B)은 보증 레벨 모듈(512A)과 유사할 수 있다. 예를 들어, 보증 레벨 모듈(612B)은 신뢰도 점수(들), 인증 시간, 인증 위치, 인증 이력, 사용자 선호도, 등에 기초하여 보증 레벨을 결정할 수 있다. 보증 레벨 모듈(612B)은 신뢰도 점수에 기초하여 제1 보증 레벨을 결정할 수 있다. 제1 보증 레벨은, 인증 장치(600)가 참여하기로 결정한 최고 보증 레벨일 수 있다. 신뢰도 점수는 개시자 장치와 연관된 신뢰도 점수일 수 있다. 제1 보증 레벨은 본원에서 설명된 바와 같은 보증 레벨의 범위로부터 결정될 수 있다.
일부 구현예에서, 보증 레벨은, 인증 장치(600)의 관점에서 개시자의 신뢰도 점수뿐만 아니라 개시자 장치의 근접성(즉, 이로부터의 거리)에 기초하여 결정될 수 있다. 근접성은 근접성 데이터에 포함될 수 있다. 예를 들어, 개시자 장치가 인증 장치(600)로부터 먼 곳(예, 다른 나라)에 위치한다는 것을 IP 주소(또는 GPS 위치와 같은 다른 적절한 데이터 아이템)가 나타냄을 인증 장치(600)가 결정하는 경우에, (예를 들어, 동일한 우편번호, 도시, 건물 등에서) 개시자 장치가 인접하다고 인증 장치(600)가 결정하는 경우보다 보증 레벨이 더 낮을 수 있다.
다른 구현예에서, 보증 레벨 모듈(612B)은 개시자 장치의 신뢰도 점수에 기초하여 보증 레벨을 결정할 수 있다. 예시적인 예로서, 보증 레벨 모듈(612B)은 신뢰도 점수 모듈(612A)로부터 신뢰도 점수를 검색할 수 있다. 예를 들어, 신뢰도 점수는 1-100의 가능한 범위의 90의 값일 수 있다. 신뢰도 점수 90은 상당히 신뢰받는 장치에 해당할 수 있다. 보증 레벨 모듈(612B)은, 90의 신뢰도 점수에 대응하는 보증 레벨이 사전 변환 표로부터 결정된 보증 레벨 1일 수 있음을 결정할 수 있다. 예를 들어, 80-100의 신뢰도 점수는 보증 레벨 1에 해당할 수 있고, 50-80의 신뢰도 점수는 보증 레벨 2에 해당할 수 있고, 0-50의 신뢰도 점수는 보증 레벨 3에 해당할 수 있다. 그러나, 보증 레벨 모듈(612B)은 소정의 변환 표를 사용하기 보다는 해당 레벨을 계산할 수 있음을 이해해야 한다.
보증 레벨 모듈(612B)은 제1 보증 레벨을 출력할 수 있다. 인증 장치(600)는, 토큰 공유 모듈(612C)에 제1 보증 레벨을 입력할 수 있고, 여기서 인증 장치(600)는 제1 보증 레벨에 대응하는 토큰 공유를 결정할 수 있다.
토큰 공유 모듈(612C)은, 토큰 공유를 얻기 위해 프로세서(602)에 의해 실행 가능한 코드 또는 소프트웨어를 포함할 수 있다. 일부 구현예에서, 토큰 공유 모듈(612C)은 보안 메모리로부터 토큰 공유(들)를 검색할 수 있다. 토큰 공유 모듈(612C)은, 결정된 제1 보증 레벨에 대한 토큰 공유 및 제1 보증 레벨보다 낮은 보증 레벨이 존재하는 경우에 낮은 보증 레벨에 대응하는 임의의 다른 토큰 공유(들)를 획득할 수 있다.
예를 들어, 토큰 공유 모듈(612C)은 키 공유에 기초하여 토큰 공유를 결정할 수 있다. 토큰 공유 모듈(612C)은, 이전에 결정된 보증 레벨(예, 보증 레벨 2)과 연관되고 메모리(604)에 저장된, 키 공유를 식별할 수 있다. 토큰 공유 모듈(612C)은 임의의 적절한 방식으로 키 공유에 기초하여 토큰 공유를 결정할 수 있다. 예를 들어, 토큰 공유는 키 공유의 미리 결정된 자릿수일 수 있다. 추가 예시로서, 토큰 공유는, 키 공유를 이용해 장치 식별자와 같은 저장된 값을 XOR함으로써 결정될 수 있다.
일부 구현예에서, 토큰 공유 모듈(612C)은, 키 공유(예, 비밀 키 공유)와 인증 데이터(즉, 장치를 인증하는 데 사용됨)를 사용함으로써, 토큰 공유를 결정할 수 있다. 토큰 공유 모듈(612C)은, 당업자에게 공지된 임계 MAC 또는 서명 접근법을 사용하여 토큰 공유를 연산할 수 있다. 예를 들어, 토큰 공유 모듈(612C)은 AES-MAC, DDH-MAC, RSA-sig, 또는 BLS-sig를 사용하여 토큰 공유를 결정할 수 있다.
H. 장치 분류
도 7은 본 개시의 구현예에 따른 장치의 분류를 나타낸다. 도 7은, 등록된 장치(710), 현재 장치(720), 인증에 사용되는 장치(730), 및 위탁 장치(740)를 포함한다. 도 7은, 현재 장치(720), 인증에 사용되는 장치(730), 및 위탁 장치(740) 모두가 등록된 장치(710) 내에 있음을 나타낸다. 장치가 등록되지 않은 경우에, 장치는 인증 프로세스에 참여하지 않을 수 있고, 현재 신뢰받는 것으로 간주되지 않을 수 있다.
일부 구현예에서, 제1 장치는, 제2 장치가 위탁 장치(740)인 것으로 결정한다. 제1 장치는 제2 장치에 대응하는 신뢰도 점수를 결정할 수 있다. 신뢰도 점수가 미리 결정된 신뢰 임계값보다 높은 경우에, 제1 장치는, 제2 장치가 위탁 장치(740)인 것으로 결정할 수 있다. 예를 들어, 제1 장치는 제2 장치에 대응하는 신뢰도 점수를 7의 값과 동일한 것으로 결정할 수 있다. 미리 결정된 신뢰 임계값이 2의 값과 동일하면, 제1 장치는, 제2 장치가 위탁 장치(740)로 간주될 수 있음을 결정할 수 있다. 그러나, 제1 장치가, 신뢰도 점수가 1의 값과 동일한 것으로 결정하면, 제1 장치는 제2 장치를 신뢰하지 않는 것으로 결정할 수 있다.
등록된 장치(710)인 장치는, 현재 장치(720) 및/또는 위탁 장치(740)에 포함될 수 있다. 장치가 등록되고, 존재하고, 신뢰받는 경우에, 장치는 인증(730)에 사용된 장치에 포함될 수 있다.
V.
방법
다음으로, 본 개시의 구현예에 따른 방법이 논의될 것이다. 제1 다양한 인증 메커니즘이 논의될 것이다. 그 다음, 신뢰도 점수 결정과 사용을 설명할 것이다. 그 다음, 본 개시의 구현예에 따른 인증 방법이 장치의 등록 및 제거와 함께 논의될 것이다.
A. 신뢰도-점수 결정
본 개시의 구현예는, 인증 프로세스에 참여하기 전에 의사 결정 단계를 추가함으로써 임계 암호화를 개선할 수 있다. 각각의 사용자 장치는, (사용자 장치에 의해 결정된 바와 같이) 개시자 장치의 신뢰도 점수를 확인할 수 있고, 예를 들어 MAC에 기여함으로써 임계 인증 절차에 참여할지 여부 및 참여할 레벨을 결정할 수 있다. 개시자 장치의 신뢰도 점수는 1) 참여 장치(즉, 인증 장치)에 의해 로컬로 관찰된 특징부 및 2) 네트워크로부터 수신된 점수에 기초한다. 일부 구현예에서, 신뢰도 점수는 신뢰도 측정계에 의해 결정될 수 있다.
각각의 사용자 장치는 네트워크 데이터에 기초하여 신뢰도 점수를 결정할 수 있다. 분산 침입 감지 및 보다 구체적으로는 IoT 장치에 대한 침입 감지에 대한 다양한 연구가 있고, [15; 7]을 참조하기 바란다. 본 개시의 구현예는, 신뢰도 측정계를 구축하기 위해 경량 이상 감지의 고급 기술을 이용할 수 있다. 각각의 사용자 장치는, 피어 사용자 장치에 대해 수집한 정보에 기초하여, 피어 사용자 장치에 대한 의견(즉, 신뢰도 점수)을 개발할 수 있다. SVELTE는 네트워크 트래픽을 수동적으로 관찰하여 네트워크 공격을 감지할 수 있는 사물 인터넷의 실시간 침입 감지[15]이다. 이 연구는, 그들의 침입 감지가 IoT 장치에서 작동할 수 있을 정도로 가볍다는 것을 보여 준다. 패킷 크기, 대상, 소스, 초 당 수신된 바이트 수, 인증 요청 수, 요청 시간, 인증 요청 파라미터와 같은 특징부는, 악의적인 활동을 찾고 장치의 인접 영역에 대한 정확한 신뢰도 점수를 인식하는 정확도를 개선할 수 있다. 분산된 침입 감지 및 보다 구체적으로는 IoT 장치에 대한 침입 감지의 다른 예시를 [34, 26, 15, 7, 31, 29]에서 찾을 수 있다.
아래 표 2는 IoT 시스템을 위해 설계된 4가지 이상 감지 체계를 나열한다. SVELTE[15]는 IoT 장치에서 실행하기에 충분히 가벼운 침입 감지 프로세스를 보여주며, 위에 설명되어 있다. Doshi 등의 최근 연구[7]는 DDoS 공격을 높은 정확도로 그러나 중앙 집중식으로 감지한다. ProFiot [29]는 센서 데이터를 분석하여 장치 침해를 감지한다. IoT-IDM [31]은, 트래픽을 모니터링하고 분석하기 위해 하나의 장치를 사용하여 중앙 집중식으로 네트워크 트래픽을 분석함으로써 장치의 악성 활동을 감지한다. 본 개시의 구현예의 경우, 네트워크 기반 분산형 침입 감지 체계가 가장 잘 작동하므로, SVELTE[15]가 가장 적합한 옵션임을 알게 된다.
표 2 (IoT 이상 감지 방법의 비교)
각각의 사용자 장치는 네트워크에서 신뢰도 점수를 서로 전파할 수 있다. 각각의 사용자 장치는, 피어 사용자 장치에 의해 광고된 데이터(예, 신뢰도 점수, 네트워크 데이터 등)를 사용하여 로컬 신뢰도 점수를 조절할 수 있다. 조절은 [10]에 설명된 바와 같이, Eigen-Trust가 확립한 일시적 신뢰도의 아이디어에 기초할 수 있다. 사용자 장치는, 사용자 장치가 신뢰하는 피어 사용자 장치의 의견을 신뢰할 수 있다. nodej에서의 nodei의 신뢰도 점수(Tij로 표시, 가중치 평균은 가중치가 그 이웃에서의 nodei의 신뢰도인 경우에 사용됨)를 계산하면:
B. 인증
도 8은 본 개시의 구현예에 따라, 인증 방법을 예시한 흐름도를 나타낸다. 도 8에 나타낸 방법은, 보안 웹사이트에 액세스하기 위한 인증을 수행하는 사용자의 컨텍스트에서 설명될 것이다. 그러나, 본 개시는 인증이 수행되는 다른 상황(예, 더 많거나 적은 사용자 장치, 결제 트랜잭션을 위한 사용자 인증, 위치에 대한 액세스, 및/또는 보안 데이터에 대한 액세스 등)에 적용될 수 있음을 이해해야 한다. 단계는 특정 순서로 예시되지만, 본 개시의 구현예는 상이한 순서로 단계를 갖는 방법을 포함할 수 있음을 이해할 것이다. 또한, 단계는 생략되거나 추가될 수 있고 여전히 본 개시의 구현예 내에 있을 수 있다.
단계 1에서, 사용자는 사용자 장치(802)에 크리덴셜을 입력할 수 있다. 크리덴셜은, 예를 들어, 사용자 이름 및 암호를 포함할 수 있다. 사용자는, 임의의 적절한 방식으로 크리덴셜을 사용자 장치(802)에 입력할 수 있다. 예를 들어, 일부 구현예에서, 사용자는 웹 사이트의 텍스트 및/또는 데이터 필드에 크리덴셜을 입력할 수 있다. 사용자는 이전에 웹사이트에 가입하거나 등록했을 수 있다. 다른 구현예에서, 사용자는, 사용자 장치(802)일 수 있는 음성 제어 어시스턴트에 명령을 말할 수 있다. 사용자 장치(802)는 크리덴셜을 포함한 명령을 기록할 수 있다.
임의의 경우에, 사용자로부터 크리덴셜을 수신한 이후에, 사용자 장치(802)는 크리덴셜을 인증 서버(804)에 전송할 수 있다. 예를 들어, 사용자가 크리덴셜을 사용자 장치(802)의 웹페이지에 입력한 경우, 사용자 장치(802)는 인증 서버(804)일 수 있는, 웹 페이지에 연관된 백엔드 서버에 크리덴셜을 전송할 수 있다. 크리덴셜은, 본원에 설명된 임의의 적절한 통신 채널을 통해 인증 서버(804)에 송신될 수 있다.
사용자 장치(802)로부터 크리덴셜을 수신한 이후에, 인증 서버(804)는 크리덴셜이 유효한지 여부를 결정할 수 있다. 일부 구현예에서, 크리덴셜은, 이전에 저장된 크리덴셜과 비교하여 이들이 일치하는지 여부를 결정할 수 있다. 다른 구현예에서, 인증 서버(804)는, 크리덴셜의 저장된 해시와 비교하기 위해 크리덴셜의 해시를 생성할 수 있다. 예를 들어, 인증 서버(804)는, 수신된 크리덴셜이 유효한지 여부를 결정하는 데 사용될 수 있는 해시된 암호 및/또는 달리 암호화된 크리덴셜을 저장하는, 데이터베이스에 결합될 수 있다. 일부 구현예에서, 유효한 크리덴셜은 정품 크리덴셜로 지칭될 것이다.
인증 서버(804)가 크리덴셜이 유효하지 않다고 결정하면, 인증 서버(804)는 크리덴셜이 유효하지 않음을 사용자 장치(802)에 통지할 수 있다. 일부 구현예에서, 사용자 장치(802)는 사용자에게 크리덴셜을 재입력하도록 프롬프팅할 수 있다.
단계 2에서, 인증 서버(804)가 크리덴셜이 유효한 것으로 결정하면, 인증 서버(804)는 챌린지 요청을 사용자 장치(802)에 송신할 수 있다. 챌린지 요청은, 사용자 장치(802)로부터의 인증 토큰 요청을 포함할 수 있다. 일부 구현예에서, 인증 서버(804)는 챌린지 요청을 개시자 장치(806)에 송신할 수 있다.
단계 3에서, 챌린지 요청을 수신한 이후에, 사용자 장치(802)는 개시자 장치(806)와 접촉할 수 있다. 일부 구현예에서, 개시자 장치(806)는 사용자 장치(802)에 근접할 수 있다. 예를 들어, 개시자 장치(806)는 사용자 장치(802)의 통신 범위(예, 블루투스 범위)에 있을 수 있다. 다른 구현예에서, 개시자 장치(806)는 등록된 장치일 수 있는데, 이는 사용자가 이전에 인증 서버(804)를 이용해 개시자 장치(806)를 등록하였음을 의미한다.
일부 구현예에서, 개시자 장치(806)는 내부 트리거에 기초하여 관찰자 요청의 생성을 개시할 수 있다. 예를 들어, 개시자 장치(806)가 관찰자 요청을 전송하도록 프롬프팅하는 챌린지 요청을 수신하는 대신에, 개시자 장치(806)는 사용자 입력에 기초하여 관찰자 요청을 전송하는 것을 결정할 수 있다. 사용자는, 예를 들어 개시자 장치(806)가 보안 크리덴셜을 인증 서버(804)와 통신하도록 선택할 수 있다. 개시자 장치(806)는, 본원에서 설명하는 바와 같이, 관찰자 요청을 전송하는 것을 결정할 수 있고 이어서 인증 토큰을 결정할 수 있다. 그 다음, 개시자 장치(806)는 인증 토큰과 함께 보안 크리덴셜을 인증 서버(804)에 송신할 수 있다.
단계 4에서, 개시자 장치(806)는 인증 장치(808)를 포함한 하나 이상의 인증 장치(즉, 관찰자(들))에 관찰자 요청을 전송할 수 있다. 일부 구현예에서, 개시자 장치(806)는 통신 범위에서 각 인증 장치와 통신할 수 있다. 통신 범위는 사용되는 통신 채널의 유형에 기초해서 달라질 수 있는데, 예를 들어 개시자 장치(806)는 최대 약 100 미터의 통신 범위를 가질 수 있는 블루투스를 통해 하나 이상의 인증 장치에 관찰자 요청을 송신할 수 있다. 일부 구현예에서, 예를 들어 대략 1 내지 10개의 장치 범위 내에 있는, 개시자 장치 장치(806)와 통신하는 임의의 적절한 수의 인증 장치가 있다.
다음 단계는 하나 이상의 인증 장치에 의해 수행될 수 있다. 인증 장치(808)는, 관찰자 요청을 수신한 이후에 개시자 장치(806)와 연관된 신뢰도 점수를 결정할 수 있다. 다른 구현예에서, 인증 장치(808)는 주기적으로 개시자 장치(806)와 연관된 신뢰도 점수를 결정할 수 있고, 관찰자 요청이 수신되는 경우에 가장 최근의 신뢰도 점수를 평가할 수 있다. 예를 들어, 인증 장치(808)는 매 5분 마다, 한 시간에 두 번, 한 시간마다, 인증 후 및/또는 인증 전, 2 시간마다, 하루에 한 번 등 신뢰도 점수를 결정할 수 있다. 하나 이상의 인증 장치는, 본원에 설명된 임의의 적절한 방식으로 신뢰도 점수를 결정할 수 있다.
단계 5에서, 인증 장치(808)는 인증에 참여할 보증 레벨을 결정할 수 있다. 예를 들어, 각각의 인증 장치는 신뢰도 점수에 기초하여 개시자 장치(806)와 연관된 제1 보증 레벨을 결정할 수 있다. 제1 보증 레벨은 보증 레벨의 범위로부터 결정될 수 있다. 예로서, 인증 장치(808)는 개시자 장치(806)와 연관된 5 중 5의 신뢰도 점수를 저장할 수 있다. 신뢰도 점수가 가능한 최고 점수이기 때문에, 인증 장치(808)는, 세 개의 보증 레벨이 있는 경우에, 가장 최고 보증 레벨에서, 예를 들어 보증 레벨 3(다른 가능한 보증 레벨은 레벨 1 및 레벨 2)에서 인증에 참여하는 것을 결정할 수 있다.
단계 6에서, 인증 장치(808)는, 그 다음 제1 보증 레벨보다 낮은 보증 레벨이 존재하는 경우에 낮은 보증 레벨에 대응하는 임의의 다른 토큰 공유(들) 및 제1 보증 레벨에 대응하는 토큰 공유를 획득할 수 있다. 예를 들어, 인증 장치(808)는 보증 레벨 3에 대응하는 토큰 공유를 획득할 수 있다. 인증 장치(808)는 또한, 보증 레벨 1 및 보증 레벨 2에 대응할 수 있는, 낮은 보증 레벨에 대응하는 다른 토큰 공유(들)를 획득할 수 있다. 따라서, 인증 장치(808)는 이 경우 세 개의 별개 토큰 공유를 결정할 수 있다. 일부 구현예에서, 각각의 상이한 보증 레벨에서의 토큰 공유는, 상이한 키 공유로부터 초래될 수 있기 때문에 서로 호환되지 않을 수 있다. 일부 구현예에서, 인증 장치(808)는 보안 메모리로부터 토큰 공유를 획득할 수 있다.
일부 구현예에서, 인증 장치(808)는 저장된 키 공유(들)를 사용하여 토큰 공유를 결정할 수 있다. 예를 들어, 인증 장치(808)는, 각 보증 레벨에 대응하는 키 공유와 같은 공유 암호를 저장할 수 있다. 세 개의 보증 레벨이 있는 경우, 인증 장치(808)는 세 개의 키 공유를 저장할 수 있다. 일부 구현예에서, 특정 보증 레벨에서의 키 공유는, 하나 이상의 인증 장치 및 개시자 장치 사이에서 공유된 암호화 키의 일부일 수 있다. 예를 들어, 128 비트 암호화 키는 8 장치 사이에서 분할되어 각 장치는 16 비트 암호화 키(즉, 키 공유)를 보유할 수 있다.
예를 들어, 일부 구현예에서, 인증 장치(808)는 제1 보증 레벨에 대응하는 토큰 공유 및 더 낮은 보증 레벨에 대응하는 임의의 다른 토큰 공유(들)를 획득할 수 있다. 인증 장치(808)는, 제1 보증 레벨에 대응하는 제1 키 공유 및 임의의 다른 토큰 공유(들)에 대응하는 임의의 다른 키 공유(들)를 검색함으로써 토큰 공유 및 다른 토큰 공유(들)를 획득할 수 있다. 인증 장치(808)는 그 다음 제1 보증 수준에 대응하는 토큰 공유를 제1 키 공유로부터 유도할 수 있다. 인증 장치(808)는 그 다음 더 낮은 보증 수준에 대응하는 임의의 다른 토큰 공유(들)를 임의의 다른 키 공유(들)로부터 유도할 수 있다.
인증 장치(808)는, 키 공유를 사용하여 보증 레벨에 대한 토큰 공유를 유도할 수 있다. 일부 구현예에서, 토큰 공유는 키 공유의 사전 결정된 비트 수일 수 있다. 다른 구현예에서, 토큰 공유는 키 공유로 XOR된 비밀 값과 동일할 수 있다.
단계 7에서, 인증 장치(808)를 포함한 하나 이상의 인증 장치는, 개시자 장치(806)에 관찰자 응답을 송신할 수 있다. 관찰자 응답은, 제1 보증 레벨보다 낮은 보증 레벨이 존재하는 경우에 각각의 낮은 보증 레벨에 대한 다른 토큰 공유(들)뿐만 아니라 제1 보증 레벨에 대한 토큰 공유를 포함할 수 있다. 개시자 장치(806)는 하나 이상의 인증 장치로부터, 보증 레벨에 대응하는 토큰 공유를 포함한 적어도 하나의 관찰자 응답을 수신할 수 있다. 일부 구현예에서, 개시자 장치(806)는, 보증 레벨뿐만 아니라 보증 레벨에 대응하는 토큰 공유를 포함한 관찰자 응답을 수신할 수 있다. 개시자 장치(806)에 의해 수신된 토큰 공유는, 토큰 공유의 세트로서 지칭될 수 있다.
예를 들어, 일부 구현예에서, 하나 이상의 인증 장치는, 보증 레벨에 대응하는 토큰 공유를 포함한 적어도 하나의 관찰자 응답을 생성할 수 있다. 하나 이상의 인증 장치는, 또한 적어도 하나의 관찰자 응답에 보증 레벨을 포함할 수 있다. 이러한 방식으로, 하나 이상의 인증 장치는, 토큰 공유 및 보증 레벨을 개시자 장치(806)에 제공할 수 있다.
다른 구현예에서, 관찰자 요청은, 하나 이상의 요청된 보증 레벨을 지정할 수 있다. 예를 들어, 개시자 장치(806)는, 하나 이상의 인증 장치로부터 수신하도록 요청하는, 보증 레벨의 범위를 포함할 수 있다. 상기 하나 이상의 요청된 보증 레벨은, 임의의 수의 보증 레벨(예, 보증 레벨 1-3, 5-10, 7 등)을 포함할 수 있다. 하나 이상의 인증 장치는, 보증 레벨에 대응하는 토큰 공유를 포함한 적어도 하나의 관찰자 응답을 개시자 장치(806)로 전송할 수 있다. 관찰자 응답에 포함된 토큰 공유의 보증 레벨은, 요청된 증 레벨 중 하나일 수 있다. 예를 들어, 하나 이상의 인증 장치는, 일부 구현예에서, 개시자 장치(806)가 하나 이상의 요청된 보증 레벨 중 요청된 보증 레벨(들)에 응답 공유를 분명히 맵핑할 수 있기 때문에, 보증 레벨 자체를 관찰자 응답 메시지에 포함할 필요가 없을 수 있다.
단계 8에서, 보증 레벨(들)에 대응하는 토큰 공유(들)를 수신한 이후에, 개시자 장치(806)는, 적어도 토큰 공유의 임계 수를 포함한 토큰 공유의 세트에 연관된 보증 레벨 범위 중 최고 보증 레벨을 결정할 수 있다. 즉, 개시자 장치(806)가 수신한 각각의 토큰 공유는, 보증 레벨과 연관될 수 있다. 예를 들어, 토큰 공유는 목록 내의 개시자에게 전송될 수 있고, 목록 내의 제1 항목은 레벨 1에 대응할 수 있고, 제2 항목은 레벨 2 등에 대응할 수 있다. 개시자 장치(806)는, 각 보증 레벨에 대한 토큰 공유의 임계 수를 결정할 수 있다. 예를 들어, 보증 레벨 1은 1개의 토큰 공유와 동일한 토큰 공유의 임계 수와 연관될 수 있는 반면에, 보증 레벨 2는 3개의 토큰 공유와 동일한 토큰 공유의 임계 수와 연관될 수 있다. 보증 레벨은, 임의의 적절한 임계 수의 토큰 공유를 가질 수 있고 사전에 결정될 수 있다. 개시자 장치(806)는, 토큰 공유의 세트에 연관된 최고 보증 레벨을 결정할 수 있다. 일부 구현예에서, 토큰 공유의 임계 수는 각각의 보증 레벨에 대해 사전에 결정될 수 있다.
예를 들어, 토큰 공유 세트는 세 개의 인증 장치로부터 수신된 토큰 공유를 포함할 수 있다. 제1 인증 장치로부터의 토큰 공유는, 세 개의 토큰 공유를 포함할 수 있고, 하나의 토큰 공유는 보증 레벨 1, 보증 레벨 2, 및 보증 레벨 3에 각각 대응한다. 제2 인증 장치로부터의 토큰 공유는, 두 개의 토큰 공유를 포함할 수 있고, 하나의 토큰 공유는 보증 레벨 1에 대응하고, 하나의 토큰 공유는 보증 레벨 2에 대응한다. 제3 인증 장치로부터의 토큰 공유는, 두 개의 토큰 공유를 포함할 수 있고, 하나의 토큰 공유는 보증 레벨 1에 대응하고, 하나의 토큰 공유는 보증 레벨 2에 대응한다. 개시자 장치(806)는, 개시자 장치(806)가 최고 보증 레벨(즉, 보증 레벨 2)에 대응하는 토큰 공유의 최소 임계 수(즉, 3개의 토큰 공유)를 수신했기 때문에, 최고 보증 레벨이 보증 레벨 2임을 결정할 수 있다. 개시자 장치(806)는, 개시자 장치(806)가 보증 레벨 3에 대응하는 1개의 토큰 공유만을 수신했기 때문에, 최고 보증 레벨이 보장 레벨 3이 아님을 결정할 수 있다. 이는, 보증 레벨 3에서 필요한 토큰 공유의 임계 수(즉, 5개의 토큰 공유)를 충족시키지 못한다.
또한, 일부 구현예에서, 개시자 장치(806)는, 낮은 보증 레벨이 존재하는 경우에 임의의 다른 토큰 공유(들)뿐만 아니라, 개시자 장치(806)가 참여하기로 결정한 최고 보증 레벨에 대응하는 개시자 토큰 공유를 획득할 수 있다. 개시자 장치(806)는, 개시자 토큰 공유를 토큰 공유 세트에 포함할 수 있다.
그 다음, 개시자 장치(806)는, 최고 보증 레벨과 연관된 토큰 공유 세트를 사용하여, 인증 토큰을 생성할 수 있다. 예를 들어, 최고 보증 레벨이 보증 레벨 2이고, 개시자 장치(806)가 보증 레벨 2와 연관된 토큰 공유의 적어도 하나의 임계 수를 수신한 경우에, 개시자 장치(806)는 보증 레벨 2에 대응하는 인증 토큰을 생성할 수 있다. 인증 토큰은 본원에 설명된 임의의 적절한 방식으로 생성될 수 있다.
단계 9에서, 인증 토큰을 생성한 후에, 개시자 장치(806)는 인증 토큰을 인증 서버(804)에 전송할 수 있다. 일부 구현예에서, 개시자 장치(806)는 또한 보증 레벨을 인증 서버(804)에 전송할 수 있다.
다른 구현예에서, 개시자 장치(806)는, 인증 토큰을 인증 서버(804)에 전달할 수 있는 사용자 장치(802)로, 인증 토큰을 전송할 수 있다.
인증 토큰을 수신한 이후에, 인증 서버(804)는 인증 토큰을 검증할 수 있다. 인증 서버(804)는, 사용자를 인증하기 위해 기존 레코드에 대해 이 정보를 검증할 수 있다. 다른 구현예에서, 인증 서버(804)는, 적절한 암호화 키를 사용하여 인증 토큰을 해독할 수 있다. 일단 인증 서버(804)가 인증 토큰을 올바른 암호화 키로 성공적으로 해독하면, 인증 서버(804)는, 예상 값 및/또는 데이터를, 인증 토큰을 해독하여 얻은 값 및/또는 데이터와 비교할 수 있다.
일부 구현예에서, 인증 서버(804)는 또한 보증 레벨을 수신할 수 있다. 그런 다음, 인증 서버(804)는 보증 레벨에 기초하여 인증 레벨을 결정할 수 있다. 예를 들어, 더 높은 보증 레벨의 경우, 인증 서버(804)는 더 높은 인증 레벨에서 사용자를 인증할 수 있다.
일부 구현예에서, 인증 서버(804) 및 개시자 장치(806)는, 보증 레벨 범위의 어느 보증 레벨이 개시자 장치(806)가 인증 서버(804)에 의해 인증될 수 있는 최소 보증 레벨인지를 상호 결정하기 위해, 추가로 통신할 수 있다. 예를 들어, 개시자 장치(806)는 두 개의 인증 토큰(예, 보증 레벨 1에 대응하는 제1 인증 토큰 및 보증 레벨 2에 대응하는 제2 인증 토큰)을 인증 서버(804)에 제공할 수 있다. 인증 서버(804)는, 인증 토큰을 수신하면, 최고 레벨의 인증 토큰(예, 보증 레벨 2)을 인증에 필요할 수 있는 임계 레벨(예, 보증 레벨 3)과 비교할 수 있다. 최고 보증 레벨이 임계 레벨을 초과하지 않는(예를 들어, 이하) 것으로 결정한 후에, 인증 서버(804)는 관찰자 요청, 관찰자 응답, 인증 장치, 토큰 공유, 및/또는 인증 프로세스와 관련된 임의의 다른 적절한 정보에 관한 추가 세부사항을 요청할 수 있다. 예를 들어, 인증 서버(804)는, 개시자 장치(806)에 토큰 공유를 제공하는 인증 장치의 수를 요청할 수 있다. 이 예시에서, 개시자 장치(806)는 "두 개의 장치"로 응답할 수 있다. 그 다음, 인증 서버(804)는, 두 개의 인증 장치가 보증 레벨 2에 대응하는 인증 토큰을 생성하는 데 필요한 인증 장치의 최소 수였음을 결정할 수 있고, 따라서 각 인증 장치는 개시자 장치(806)를 보증 레벨 2로 신뢰한다. 인증 장치의 수에 기초하여, 인증 서버는 개시자 장치(806)가 인증될 수 있는지 여부를 결정할 수 있다. 다른 예시로서, 개시자 장치(806)가 "이십 개의 장치"로 응답하는 경우에, 인증 서버(804)는, 토큰 공유를 제공하지 않았던 인증 장치의 수에 대해 토큰 공유즐 제공했던 인증 장치의 수의 비율이 낮다고 결정할 수 있다. 그 다음, 인증 서버(804)는 개시자 장치(806)가 인증될 수 없음을 결정할 수 있다.
아래에서, 관찰자 요청 및 인증 토큰 생성을 위한 유사코드는, 인증 장치로부터 토큰 공유를 요청할 뿐만 아니라 수신된 토큰 공유를 조합하는 개시자 장치(806)의 세부사항을 추가로 설명한다. 인증 장치의 작업은 관찰자 응답에서 설명된다.
1. 관찰자 요청 및 인증 토큰 생성
관찰자 요청: 인증 토큰을 만들기 위해, 노드는 피어 노드로 토큰을 만들 때 노드와 협업하는 요청을 전송할 수 있다. 데이터 항목 "token_shares"는 하나의 관찰자 장치로부터 수신된 토큰 공유의 목록일 수 있다. 데이터 항목 "all_shares"는 "token_shares"의 목록(즉, 공유 목록의 목록)일 수 있다. 데이터 항목(예, "token_share")의 목록(즉, 어레이)의 색인은 보증 레벨일 수 있다. 예를 들어, 각 응답으로부터의 제1 토큰 공유는 보증 레벨 1에 대응할 수 있고, 각 응답으로부터의 제2 토큰 공유는 보증 레벨 2에 대응할 수 있다.
관찰자 요청: 인증 토큰을 만들기 위해, 노드는 피어 노드로 토큰을 만들 때 노드와 협업하는 요청을 전송할 수 있다. 데이터 항목 "token_shares"는 하나의 관찰자 장치로부터 수신된 토큰 공유의 목록일 수 있다. 데이터 항목 "all_shares"는 "token_shares"의 목록(즉, 공유 목록의 목록)일 수 있다. 데이터 항목(예, "token_share")의 목록(즉, 어레이)의 색인은 보증 레벨일 수 있다. 예를 들어, 각 응답으로부터의 제1 토큰 공유는 보증 레벨 1에 대응할 수 있고, 각 응답으로부터의 제2 토큰 공유는 보증 레벨 2에 대응할 수 있다.
1: procedure WitnessRequest
2:
for device 
registered_Devices do
3:
sendMsg(device;WITNESS REQUEST)
4:
wait(1Second)
5:
for token_shares 
all_shares do
6:
if length(token_shares) 
THRESHOLD then
7:
token 
combine(token shares)
8:
token.list+ = token
9:
assuranceLevel 
maxLevel(token_list)
10:
token 
token_list[assuranceLevel] 
11:
sendMsg(authenticator;< token; assuranceLevel >)
12: procedure MessageRecieved(message) 
이 프로시저는 관찰자 노드로부터 수신된 메시지를 처리한다.
13:
level 
0
14:for token_share 
message do
15:
level++
16:
all_shares[level]+ = token_share
상기 프로세스에서, 인증 토큰은 각 보증 레벨에 대해 생성될 수 있다. 다수의 인증 토큰이 생성될 수 있고, 그 다음 최고 보증 레벨이 생성될 수 있고, 따라서 최고 레벨의 토큰 공유로부터의 인증 토큰이 결정될 수 있다. (어느 이유에서든) 최고 레벨의 인증 토큰이 인증 서버(804)에 의해 거부되는 경우에, 개시자 장치(806)가 단순히 목록(예, "token_list")에서 다음 인증 토큰을 보낼 수 있기 때문에, 최고 수준의 보증 레벨을 결정하기 전에 각 보증 레벨에 대한 인증 토큰을 생성하는 것이 유익할 수 있다. 그러나, 다른 구현예에서, 개시자 장치(806)는 최고 보증 레벨 토큰을 결정할 수 있고, 그 다음 최고 보증 레벨과 연관된 토큰 공유 세트로부터 결정된 인증 토큰을 제공할 수 있음을 이해해야 한다.
2. 관찰자 응답
관찰자 응답: 인증 장치는 토큰 공유로 개시자 장치에 응답할 수 있다.
1:procedure Witness Response
2:
AL AssuranceLevel 
(TS initiator )
3:
for level ≤ AL do
4:
token share 
thresholdSignature(level)
5:
token_share_list+ = token share
6:
sendMsg(initiator; token_share_list)
C.다양한 장치 상태
도 9는 본 개시의 구현예에 따른 장치의 수명 주기를 나타낸다. 도 9는 장치의 수명 주기의 다양한 단계를 나타낸다. 단계는 미등록(902), 등록(904), 현재(906), 위탁(908) 그리고 현재 및 위탁(910)을 포함할 수 있다. 상이한 방법은 한 단계와 다른 단계 사이의 연결을 보여준다. 예를 들어, 미등록 장치(902)는 Register() 방법을 사용하여 등록(904)될 수 있다. 장치는 임의의 적절한 방법(예, 블루투스, 사운드 등)을 사용하여 다른 장치가 존재하는 것으로 결정할 수 있다. 예를 들어, 장치는 섹션 III에 설명된 바와 같은 근접성 감지 방법을 수행할 수 있다. 장치는 임의의 적절한 방법을 사용하여 다른 장치에 대한 신뢰도 점수를 결정할 수 있다. 예를 들어, 신뢰도(즉, 신뢰도 점수)는 상대적일 수 있고, 제1 장치가 제2 장치를 얼마나 신뢰하는지를 나타낼 수 있다. 신규 장치(예, 제2 장치)에 대한 신뢰도 점수는 100%로 설정될 수 있고(장치가 처음 며칠 동안 안전하다고 가정할 때), 제1 장치는 제2 장치가 비정상적인 역할을 하는 것으로 보일 때(예를 들어, 1시간에 수백 개의 인증을 시도하는 경우) 제2 장치의 신뢰도 점수를 낮출 수 있다.
1. 등록
신규 사용자 장치의 등록은, 사용자 이름 및 암호와 같은 사용자 크리덴셜 및 본원에 설명된 인증 프로세스를 통해, 사용자를 인증함으로써 수행될 수 있다. 그러나, 하나의 차이점은 신규 사용자 장치의 등록이 더 민감할 수 있기 때문에, 구현예는 사용자 참여 및 승인을 요청할 수 있다는 것이다. 예를 들어, 사용자는 신규 사용자 장치의 등록을 확인하도록 프롬프트될 수 있다.
신규 사용자 장치는 이미 등록된 사용자 장치의 승인을 사용해 등록할 수 있지만, 모든 사용자 장치를 항상 사용할 수 있는 것은 아니며, 항상 가까이에 있는 것은 아니다. 따라서, 본 개시의 구현예는 정상적인 등록 프로세스를 허용할 수 있다. 신규 사용자 장치의 추가를 입증할 수 있는 사용자 장치가 더 많을수록(즉, 높은 보증 레벨에 대응하는 키 공유를 제공할수록), 새로운 사용자 장치가 수신할 수 있는 키 공유는 더 많다. 예를 들어, 인증 장치가 신규 사용자 장치에 대한 낮은 신뢰도 점수를 갖고 낮은 보증 레벨 토큰 공유를 제공하는 경우에, 신규 사용자 장치는 저 보증 레벨 토큰 공유에 대응하는 키 공유가 (인증 서버 또는 다른 적절한 장치에 의해) 발급될 수 있다. 이러한 방식으로, 사용자의 암호 및/또는 다른 크리덴셜이 침해되는 경우에, 공격자는 필요한 만큼의 신규 사용자 장치를 추가할 수 있다. 낮은 보증 레벨에 대응하는 토큰 공유만 수신하는 신규 사용자 장치는, 높은 보증 레벨에서 인증을 수행하기 위해 많은 신규 사용자 장치를 추가하는 공격자로부터 방어한다.
이미 등록된 일부 사용자 장치가 주어지면, 다음 단계는 신규 사용자 장치를 추가하는 방법에 대해 설명한다. 1) 사용자는 자신의 사용자 이름과 암호를 사용하여 사용자 장치 관리 포털에 로그인할 수 있고 2) 동일한 네트워크에서 그 인접 장치(즉, 피어 사용자 장치)를 찾기 위해 검색 알고리즘을 실행할 수 있고 3) 본원에서 설명된 바와 같이 개시자 장치 역할을 할 수 있으며, 등록을 위해 인근 사용자 장치가 인증 장치이도록 연결할 수 있다. 4) 이미 등록된 사용자 장치 각각은, 사용자가 확인해야 하는 "신규 사용자 장치에 대한 허가 요청" 팝업을 나타낼 수 있다. 사용자의 확인을 수신하는 등록된 사용자 장치는 토큰 공유를 생성하고 토큰 공유를 신규 사용자 장치에 송신할 수 있다. 일부 구현예에서, 등록된 사용자 장치는 토큰 공유(들)를 등록 서버, 인증 서버, 및/또는 다른 적절한 장치에 송신할 수 있다. 5) 등록 서버로 전송된 레벨 토큰의 경우, 신규 사용자 장치는 해당 보증 레벨에 대응하는 키 공유를 수신할 수 있다.
일부 구현예에서, 신규 사용자 장치를 추가하면 임계값을 증가시킬 수 있으므로, 이미 등록된 다른 사용자 장치 각각은 새로운 키 공유로 전송될 수 있다.
2. 장치의 제거
사용자 장치를 제거함(즉, Remove() 방법을 수행함)에 있어서, 모든 사용자 장치(즉, 근접하거나 원격임)는 등록된 사용자 장치의 목록에서 해당 사용자 장치를 제거하도록 통지받을 수 있다. 사용자 장치는 또한, 제거된 사용자 장치와 연관된 신뢰도 점수를 0(zero)으로 설정할 수도 있다. 사용자가 사용자 장치를 제거하는 경우에, 제거된 사용자 장치는 깨끗하게 제거될 수 있으므로, 임의의 키 공유가 메모리로부터 제거될 수 있다. 그러나, 제거된 사용자 장치가 도난당한 경우에, 모든 레벨에 대한 키 공유는 인증자 측(즉, 인증 서버에 의해) 및 사용자 장치에서도 업데이트될 수 있다. 모든 사용자 장치에 대한 키를 업데이트하는 것이 효과적이지 않을 수 있지만, 이 작업은 자주 발생하지 않는다.
D.예시적인 방법
1. 개시자 장치
도 10은 본 개시의 구현예에 따라, 인증 토큰 생성 방법을 예시한 흐름도를 나타낸다. 도 10에 나타낸 방법은, 인증 서버에 의한 인증용 토큰 공유를 요청하는 관찰자 요청을 전송하는 개시자 장치의 맥락에서 설명될 것이다.
단계(1002)에서, 개시자 장치는 관찰자 요청을 하나 이상의 인증 장치에 전송할 수 있다. 예를 들어, 개시자 장치는, 블루투스 통신 채널 범위 내의 임의의 적절한 수의 인증 장치로 관찰자 요청을 전송할 수 있다. 관찰자 요청은 토큰 공유에 대한 요청을 포함할 수 있다.
일부 구현예에서, 관찰자 요청을 전송하기 전에, 개시자 장치는 인증 서버로부터 챌린지 요청을 수신할 수 있다. 챌린지 요청은, 인증 서버에 크리덴셜을 제공하는 개시자 장치에 응답할 수 있다. 챌린지 요청은, 인증용 추가 챌린지일 수 있다. 일부 구현예에서, 챌린지 요청은, 인증 서버가 개시자 장치를 인증할 보증 레벨을 표시할 수 있다. 예를 들어, 챌린지 요청은 보증 레벨 3을 나타낼 수 있다. 인증 서버는, 보증 레벨 3에 대응하는 인증 토큰을 수신한 후에 개시자 장치를 인증할 수 있다. 일부 구현예에서, 챌린지 요청은 인증 서버로부터 사용자 장치를 통해 개시자 장치로 송신될 수 있다.
다른 구현예에서, 관찰자 요청을 전송하기 전에, 예를 들어 사용자 입력, 내부 타이머, 및 이상 감지 중 적어도 하나에 기초하여 내부적으로 관찰자 요청을 결정할 수 있다. 예를 들어, 사용자는, 개시자 장치에서 인증을 수행하는 옵션을 선택할 수 있다. 개시자 장치는, 사용자 입력을 수신하면, 인증 토큰을 결정하기 위해 관찰자 요청을 전송하는 것을 결정할 수 있다.
다른 예시로서, 개시자 장치는 내부 타이머에 기초하여 관찰자 요청을 전송하도록 결정할 수 있다. 개시자 장치는, 예를 들어, 5시간, 3일, 8주, 6개월 등 이후에 인증 프로세스를 개시하도록 결정할 수 있다.
다른 예시로서, 개시자 장치는 이상 감지에 기초하여 관찰자 요청을 결정할 수 있다. 개시자 장치는, 예를 들어 네트워크 데이터를 모니터링할 수 있다. 개시자 장치는, 네트워크 데이터를 임의의 적절한 이상 감지 임계값과 비교하여 이상이 있는지 여부를 결정할 수 있다. 개시자 장치가 이상이 있다고 결정하는 경우, 개시자 장치는 인증 시 인증 서버로부터의 챌린지 요청을 기다리는 대신에, 선제적 인증 조치로서 관찰자 요청을 전송할 수 있다. 예를 들어, 네트워크 데이터에 큰 이상이 있는 경우(예를 들어, 네트워크 트래픽의 상당한 증가), 인증 서버는 비정상적인 이벤트 동안에 추가적인 보안을 제공하기 위한 챌린지 요청을 생성할 수 있다. 비정상적인 이벤트의 관점에서, 개시자 장치는 관찰자 요청을 선제적으로 생성하고 인증 서버와 인증하기 위한 인증 토큰을 생성할 수 있다.
관찰자 요청을 수신한 후, 하나 이상의 인증 장치의 각각의 인증 장치는 보증 레벨의 범위로부터 보증 레벨을 결정할 수 있다. 각각의 인증 장치는 또한 보증 레벨에 대응하는 토큰 공유를 결정할 수 있다. 보증 레벨 및 토큰 공유의 결정은 적어도 도 11에 더 상세하게 설명되어 있다.
단계(1004)에서, 개시자 장치는 그 다음 하나 이상의 인증 장치로부터, 보증 레벨에 대응하는 토큰 공유를 포함한 적어도 하나의 관찰자 응답을 수신할 수 있다. 개시자 장치는 임의의 적절한 수의 관찰자 응답을 수신할 수 있다. 예를 들어, 다섯 개의 인증 장치가 있는 경우, 개시자 장치는 하나, 둘, 셋, 넷 또는 다섯 개의 관찰자 응답을 수신할 수 있다. 개시자 장치는, 보증 레벨에 대응하는 각각의 수신된 토큰 공유를 토큰 공유 세트 내에 포함할 수 있다. 보증 레벨의 범위의 각 보증 레벨은, 토큰 공유의 각 세트에 대응할 수 있다.
일부 구현예에서, 적어도 하나의 관찰자 응답은 보증 레벨을 추가로 포함할 수 있다. 예를 들어, 하나 이상의 인증 장치는, 각각 개시자 장치로 전송된 관찰자 응답에서 토큰 공유와 보증 레벨을 제공할 수 있다.
다른 구현예에서, 관찰자 요청은 하나 이상의 요청된 보증 레벨을 지정할 수 있다. 예를 들어, 개시자 장치는, 단계(1002)에서, 하나 이상의 요청된 보증 레벨(예, 보증 레벨 2, 3, 10, 2-4 등)을 지정할 수 있는 관찰자 요청을 전송할 수 있다. 하나 이상의 요청된 보증 레벨은, 토큰 공유에 대응하는 보증 레벨을 포함할 수 있다. 예를 들어, 인증 장치는, 하나 이상의 요청된 보증 레벨에 의해 지정된 바와 같이, 보증 레벨에 대응하는 토큰 공유를 포함할 수 있다.
개시자 장치는, 적어도 토큰 공유의 임계 수를 포함한 토큰 공유의 세트에 연관된 보증 레벨 범위의 제1 보증 레벨을 결정할 수 있다. 예를 들어, 제1 보증 레벨은, 개시자 장치 장치가 적어도 토큰 공유의 임계 수를 보유한, 최고 보증 레벨일 수 있다. 토큰 공유의 임계 수는, 임의의 적절한 임계값을 포함할 수 있고 미리 결정될 수 있다. 예를 들어, 보증 레벨 번호 1은 5개 공유분의 토큰 공유의 임계 수와 연관될 수 있는 반면에, 보증 레벨 번호 3은 4개 공유분의 토큰 공유의 임계 수와 연관될 수 있다.
일부 구현예에서, 개시자 장치는 각각의 보증 레벨에 대한 개시자 토큰 공유를 저장할 수 있다. 개시자 장치는, 예를 들어, 제1 보증 레벨과 제1 보증 레벨을 결정하는 경우에 더 낮은 보증 레벨이 존재할 시 임의의 다른 토큰 공유(들)에 대응하는 개시자 토큰 공유를 획득할 수 있다.
다른 구현예에서, 개시자 장치는 제1 보증 레벨을 결정하기 전에 토큰 공유 세트의 제1 양을 결정할 수 있다. 제1 양은 임의의 적절한 방식으로 결정될 수 있다. 예를 들어, 일부 구현예에서, 각각의 토큰 공유는 가중치와 연관될 수 있다. 가중치는 원래 인증 장치의 보안 수준을 나타낼 수 있다. 가중치에 대해 값이 높을수록, 토큰 공유가 더 안전함을 나타낼 수 있다. 토큰 공유의 제1 양은, 토큰 공유 세트의 가중치를 합산함으로써 결정될 수 있다.
각각의 토큰 공유와 연관된 가중치는, 예를 들어 인증 장치의 특성에 기초하여 결정될 수 있다. 토큰 공유와 연관된 가중치에 영향을 미칠 수 있는 인증 장치의 특성은, 인증 장치가 자신의 토큰 공유(들)(예, 부정조작 방지 용기, 핀 보호 용기 등)를 보호하는 방법을 포함할 수 있지만, 이에 제한되지 않는다.
제1 양을 결정한 후, 개시자 장치는, 제1 양을 임계량과 비교함으로써 토큰 공유의 적어도 임계량을 포함한 토큰 공유 세트와 연관된 보증 레벨 범위의 제1 보증 레벨을 결정할 수 있다. 이러한 방식으로, 보증 레벨은 토큰 공유의 수로부터 결정될 수 있을 뿐만 아니라, 이들 토큰 공유의 각각이 어떻게 보호되고 유지되는지에 기초하여 결정될 수 있다. 인증 장치가 충분히 안전하지 않은 경우에(예를 들어, 특정 토큰 공유가 더 높은 레벨의 보증을 청구하는 데 사용되지 않을 수 있는 경우에), 토큰 공유 중 일부는 바람직하지 않을 수 있다.
단계(1006)에서, 적어도 하나의 관찰자 응답을 수신한 이후, 개시자 장치는 토큰 공유 세트를 사용하여 인증 토큰을 생성할 수 있다. 개시자 장치는, 본원에 설명된 임의의 적절한 방식으로 인증 토큰을 생성할 수 있다. 예를 들어, 개시자 장치는 토큰 공유 세트로부터 중복된 토큰 공유를 제거한 다음에, 토큰 공유 세트로부터 남은 토큰 공유를 XOR하여 인증 토큰을 결정할 수 있다.
일부 구현예에서, 개시자 장치는, 제1 보증 레벨과 낮은 보증 레벨이 존재하는 경우에 임의의 낮은 보증 레벨에 대응하는 하나 이상의 인증 토큰을 생성할 수 있다. 예를 들어, 개시자 장치는 보증 레벨 번호 1에 대응하는 6개의 토큰 공유, 보증 레벨 번호 2에 대응하는 5개의 토큰 공유, 및 보증 레벨 번호 3에 대응하는 2개의 토큰 공유를 수신할 수 있다. 각각의 보증 레벨은, 토큰 공유의 임계 수에 대응할 수 있거나, 일부 구현예에서, 레벨에 대한 인증 토큰을 생성하는 데 사용될 수 있는 토큰 공유의 임계 양에 대응할 수 있다. 예를 들어, 보증 레벨 번호 1은 5의 임계값에 대응할 수 있고, 보증 레벨 번호 2는 4의 임계값에 대응할 수 있고, 보증 레벨 번호 3은 3의 임계값에 대응할 수 있다. 개시자 장치는, 보증 레벨 번호 2에 대한 하나의 인증 토큰 및 보증 레벨 번호 1에 대한 제2 인증 토큰을 생성할 수 있다.
단계(1008)에서, 인증 토큰을 생성한 후에, 개시자 장치는 인증 토큰을 인증 서버에 전송할 수 있다. 인증 토큰을 수신한 이후에, 인증 서버는 인증 토큰을 검증할 수 있다.
일부 구현예에서, 개시자 장치는 또한 보증 레벨을 인증 서버에 송신할 수 있다. 예를 들어, 개시자 장치는, 보증 레벨(예, 보증 레벨 번호 3) 및 보증 레벨에 대응하는 인증 토큰을 포함하는 메시지를 인증 서버에 송신할 수 있다.
다른 구현예에서, 개시자 장치는 하나 이상의 인증 토큰을 생성한 후에 하나 이상의 인증 토큰을 송신할 수 있다. 예를 들어, 개시자 장치는, 하나 이상의 인증 토큰 및 하나 이상의 인증 토큰에 각각 대응하는 하나 이상의 보증 레벨을 포함한 목록 또는 다른 적절한 데이터 아이템을 인증 서버에 송신할 수 있다.
2. 인증 장치
도 11은 본 개시의 구현예에 따라, 관찰자 응답 생성 방법을 예시한 흐름도를 나타낸다. 도 11에 나타낸 방법은, 인증 프로세스 동안에 개시자 장치로부터의 관찰자 요청에 응답한 인증 장치의 맥락에서 설명될 것이다. 도 11을 참조하여 설명된 방법은, 인증 장치에 의해 수행되는 것으로 설명될 것이다. 그러나, 도 11의 방법은 하나 이상의 인증 장치 중 각 인증 장치에 의해 수행될 수 있음을 이해해야 한다.
단계(1102) 이전에, 개시자 장치는 본원에서 상세히 설명되는 바와 같이, 관찰자 요청을 생성하고 전송할 수 있다. 단계(1102)에서, 인증 장치는 관찰자 요청을 수신할 수 있다.
단계(1104)에서, 관찰자 응답을 수신한 이후에 인증 장치는, 본원에서 상세히 설명되는 바와 같이, 신뢰도 점수에 기초하여 개시자 장치와 연관된 제1 보증 레벨을 결정할 수 있다. 제1 보증 레벨은 보증 레벨의 범위로부터 결정될 수 있다.
일부 구현예에서, 인증 장치는 적어도 네트워크 데이터에 기초하여 개시자 장치와 연관된 신뢰도 점수를 결정할 수 있다. 네트워크 데이터는, 예를 들어 전송 속도, 데이터 수신 속도, 데이터 패킷의 평균 크기, 소스 주소, 도메인 이름 시스템 정보, IP 주소, 호스트 이름, 신호 강도 데이터, 및 Wi-Fi 연결 데이터를 포함할 수 있다. 인증 장치는, 예를 들어 과거 이력의 전형적인 전송 속도와 상기 전송 속도 간의 차이, 과거 이력의 전형적인 데이터 수신 속도와 상기 데이터 수신 속도 간의 차이, 및/또는 과거 이력의 전형적인 데이터 패킷의 평균 크기와 상기 데이터 패킷의 평균 크기 간의 차이에 기초하여 신뢰도 점수를 결정할 수 있다.
다른 구현예에서, 신뢰도 점수는 로컬 신뢰도 점수(즉, 인증 장치에 대한 로컬)일 수 있다. 인증 장치는, 하나 이상의 추가 인증 장치로부터 하나 이상의 원격 신뢰도 점수를 수신할 수 있다. 원격 신뢰도 점수를 수신한 후, 인증 장치는, 본원에서 설명하는 바와 같이, 로컬 신뢰도 점수 및 하나 이상의 원격 신뢰도 점수의 가중 평균을 사용하여 신뢰도 점수를 결정할 수 있다.
또 다른 구현예에서, 인증 장치는 개시자 장치의 유형에 기초하여 신뢰도 점수를 결정할 수 있다. 예를 들어, 인증 장치는, 사용자가 잠재적으로 안전하지 않은 위치에 가져갈 수 있는 모바일 폰인 개시자 장치보다는, 사용자의 집에 남아있을 수 있는 데스크톱 컴퓨터인 개시자 장치가 더 신뢰할 수 있다.
단계(1106)에서, 제1 보증 레벨을 결정한 후에, 인증 장치는 제1 보증 레벨에 대응하는 토큰 공유를 획득할 수 있다. 일부 구현예에서, 인증 장치는, 또한, 제1 보증 레벨보다 낮은 보증 레벨이 존재하는 경웨, 더 낮은 보증 레벨에 대응하는 임의의 다른 토큰 공유(들)를 획득할 수 있다. 예를 들어, 제1 보증 레벨은 보증 레벨 번호 3일 수 있다. 인증 장치는 보증 레벨 번호 3에 대응하는 토큰 공유뿐만 아니라 보증 레벨 번호 2 및 보증 레벨 1에 대응하는 토큰 공유를 획득할 수 있다.
일부 구현예에서, 제1 보증 레벨에 대응하는 토큰 공유 및 더 낮은 보증 레벨에 대응하는 임의의 다른 토큰 공유(들)를 획득하는 것은, 제1 보증 레벨에 대응하는 제1 키 공유뿐만 아니라 임의의 다른 토큰 공유(들)에 대응하는 임의의 다른 키 공유(들)를 검색하는 것을 포함할 수 있다. 인증 장치는, 본원에 설명된 바와 같이 임의의 적절한 메모리로부터 키 공유를 검색할 수 있다. 인증 장치는, 그 다음 제1 보증 수준에 대응하는 토큰 공유를 제1 키 공유로부터 유도할 수 있다. 또한, 인증 장치는 본원에 설명된 대로 임의의 다른 키 공유(들)로부터 더 낮은 보증 레벨에 대응하는 임의의 다른 토큰 공유(들)을 유도할 수 있다. 일부 구현예에서, 제1 키 공유, 및 임의의 다른 키 공유(들)는 개시자 장치, 및 인증 장치를 포함한 하나 이상의 인증 장치 사이에서 공유된 암호화 키의 분획일 수 있다.
단계(1108)에서, 토큰 공유(들)를 획득한 이후에, 인증 장치는 제1 보증 레벨에 대한 토큰 공유를 관찰자 응답에서 개시자 장치에 송신할 수 있다. 일부 구현예에서, 인증 장치는 또한 각각의 낮은 보증 레벨에 대한 다른 토큰 공유(들)를 관찰자 응답에서 개시자 장치에 송신할 수 있다.
VI.
보안 분석
다음으로, 다중-인자 인증(MFA)으로서 본 개시의 구현예에 대한 보안 분석은, 제1 인자(즉, 암호)가 침해되고 공격자가 제2 인자를 공격함으로써 악의적으로 인증하는 것을 목표로 하는 경우에 논의될 것이다.
1) 등록된 사용자 장치가 없는 원격 공격자, 2) 컨텍스를 조작하는 적대자, 3) 침해된 사용자 장치를 이용한 원격 공격자, 4) 도난된 등록 사용자 장치를 이용한 공격자, 5) 내부 공격자를 포함한, 여러 가지 상황을 논의할 것이다.
A. 등록된 사용자 장치가 없는 원격 공격자
미등록 및 알려지지 않은 장치를 사용하는 공격자는 단순히 본 개시의 구현예를 개시하지 못하고, 모든 보증 레벨의 인증 토큰을 연산하지 못하는데, 그 이유는 1) 공격자가 키 및/또는 키 공유가 없고 2) 키 공유가 있는 사용자 장치는, 사용자 장치가 이전에 알려지지 않은 장치를 보지 않았서 공격자를 신뢰하지 않기 때문이다.
B. 컨텍스트를 조작하는 적대자
원활한 2FA 체계의 주요 목표 중 하나는, 사용자가 자체적으로 인증하는 것이 제2 장치(인자)를 소유/운영하는 것임을 입증하는 것이다. 이러한 목표를 달성하기 위한 하나의 방법은, 사용자의 제1 및 제2 장치의 근접성을 입증하는 것이다. 근접성을 입증하기 위해 다양한 채널을 사용했다. 블루투스(일반적인 라디오), 소리, 온도 및 광. 환경 및 이들 채널에 의해 관찰된 것을 조작할 수 있는 공격이 있으며[18], 이를 컨텍스트 조작 공격자라고도 합니다.
본 개시의 구현예는 다수의 사용자 장치가 협업함으로써 이들 공격을 방어하므로, 타겟 공격을 조율하고 확장하는 것을 더욱 어렵게 한다. 예를 들어, 모든 참여 사용자 장치를 동시에 (예를 들어, 사용자 장치 간에 모든 온도 측정을 유사하게 만들도록) 데우기 위해 드라이어를 사용하는 것이 더 이상 가능하지 않으며, 근접성 시험을 속인다.
C. 침해된 사용자 장치를 이용한 원격 공격자
이미 등록된 사용자 장치가 침해를 당하면 그 자체로 레벨 1(최저 보증 레벨)의 토큰이 생성될 수 있다. 그러나, 네트워크 내의 나머지 사용자 장치는 침해된 동작을 점진적으로 감지하고 신뢰도 점수를 0으로 낮출 수 있으며, 침해된 장치와 협업하지 않을 것이다. 본 개시의 구현예는 신뢰도 점수의 정상적인 저하를 가능하게 한다. 인증 시, 인증 장치는 인증 시간, 유래, 및 인증 파라미터(예, 결제 금액, 사용자 이름)를 입력한 다음 그들의 로컬 신뢰도 점수를 업데이트할 수 있다. 비정상적인 인증 요청이 감지되고 신뢰도 점수를 조절할 수 있다. 일부 구현예에서, 이는 모든 인증 정보가 이용 가능한 서버 측에 남겨질 수 있다. 또한, 인증 서버는 완전한 분석을 수행하기 위해 사용자 장치보다 더 많은 연산 능력 및 대역폭을 갖는다.
D. 도난된 등록 사용자 장치를 이용한 공격자
도난된 등록 사용자 장치를 이용한 공격자의 상황에서, 공격자가 할 수 있는 최상의 방법은 레벨 1의 토큰을 생성하는 것이고, 그 이유는 도난된 등록 장치가 인증 토큰을 생성하기에 충분한(즉, 하나의) 공유를 가지고 있기 때문이다. 그러나, 나머지 사용자 장치는 개시자 장치의 근접성을 검증할 수 없기 때문에, 이 인증에 대한 " 관찰자"가 될 것이다.
E. 내부 공격자
공격자가 사용자의 암호를 알고 있을 뿐만 아니라 사용자 장치에 매우 근접해 있는 경우(예, 사용자 집에 침입), 공격자는 성공 가능성이 높다. 본 개시의 한가지 방식의 구현예는, 특정 개시자 장치의 요청 시간에 임의의 이상을 감지함으로써 이러한 공격에 대해 방어할 수 있다.
예를 들어, 하루 중 사용자에 의해 수행되는 대부분의 결제는, 사용자의 전화기를 개시자 장치로서 사용함으로써 수행된다. 음성 제어 어시스턴트가 처음으로 인증 프로세스를 개시하는 경우, 비정상적인 것으로 감지될 수 있다. 사용자 장치는 토큰 생성에 참여하지 않기로 결정할 수 있다. 신뢰도 점수가 이상을 감지하지 못하는 경우에, 공격을 감지하기 위해 인증 서버의 사기 감지 서비스에 맡길 수 있다.
VII.
평가
다음으로, 본 개시의 구현예의 평가를 수행할 것이다. 본 개시의 구현예의 보안 및 유용성은, 사용자가 소유한 사용자 장치의 수, 보증 레벨의 수, 및 임계값 MAC 생성에 대한 임계값 설정에 의해 조절될 수 있다. 먼저, 아래 두 가지 사용 사례에서 두 가지 파라미터 세트를 고려한다. 그 다음, 본 개시의 구현예를 이전 작업과 비교할 것이다. 그 후, 구현예의 비교 분석은 Bonneau 등의 프레임워크에 제공되어 있다[4].
제1 사용 사례는 5개의 사용자 장치, 1개의 보증 레벨, 및 1의 임계값을 포함할 수 있다. 이는 5개의 등록된 사용자 장치 중 어느 하나가 인증에 사용될 수 있는 단순한 경우인데, 이는 1개의 보증 레벨이 있고 임의의 1개의 장치가 제1 보증 레벨에 대한 토큰을 생성하는데 도움을 줄 수 있기 때문이다. 이 사용 사례의 보안은, 하나의 장치를 사용하여 원활한 2FA 보안과 비슷하다. 하나의 장치가 손상되는 경우, 인증이 침해될 수 있다. 그러나, 5개의 사용자 장치 중 하나가 근처에 있고 이용 가능할 가능성이 더 높기 때문에, 유용성은 더 높을 수 있다.
제2 사용 사례는 5개의 사용자 장치, 1개의 보증 레벨, 및 5의 임계값을 포함할 수 있다. 이 경우에, 사용자는 인증 토큰을 협업 연산하기 위해 신뢰할 수 있는 방식으로 정상적인 환경에서 5개의 사용자 장치 모두를 인접하게 가질 필요가 있다. 공격자가 5개의 사용자 장치를 모두 침해 및/또는 훔쳐야 하기 때문에, 이 사례의 보안은 다른 원활한 2FA 체계보다 높을 수 있다. 유용성은, 대화형 2FA보다 높을 수 있지만, 5개의 사용자 장치 중 하나를 이용할 수 없는 경우에 유용성은 원활한 2FA보다 낮을 수 있다.
A. 비교 분석
Bonneau 등[4]의 프레임워크는 본 개시의 구현예의 보안, 유용성 및 배치 가능성을 평가하는 데 사용된다.
1. 유용성
이전의 2FA 체계의 평가와 일관되게, 일부 구현예는 사용자 이름 및 암호와 같은 크리덴셜을 기억할 필요가 있기 때문에, 사용자용 확장형 및 기억력에 있어서는 쉽지 않을 수 있다. 그러나, 구현예는 암호 없는 인증에 사용될 수 있고, 그러한 컨텍스트에서, 이는 처음 두 개의 유용성 요건을 만족시킬 것이다. 일부 구현예는, 사용자 주위에서 사용자 장치를 기회를 보면서 이용할 수 있기 때문에 사용자에게 임의의 사용자 장치를 휴대할 것을 요구하지 않는다. 또한, 다른 사용자 장치를 이용할 수 없는 경우에, 구현예는 대화형 2FA로 되돌아갈 수 있다. 이전의 원활한 2FA 방법과 비교하면, 구현예는 하나의 특정 사용자 장치에 의존하지 않기 때문에, 이 카테고리에서 더 높은 점수를 받는다. 다른 모든 2FA 체계와 유사하게, 구현예는 물리적으로 쉽지 않으며, 사용자가 암호를 입력해야 하기 때문에 오류가 발생할 수 있고 실수를 할 수 있다.
2. 배치 가능성
액세스 가능한 관점에서, 본 개시의 구현예는 다른 원활한 2FA 체계와 유사할 수 있다. 구현예는 사용자 당 무시할 만한 비용을 가질 수 있다. 그러나, 구현예가 임계 MAC를 사용하고 위험 정보를 제공하기 때문에, 인증 서버는 CoRA 변경에 따라 업데이트될 수 있다. 일부 구현예는, 선택된 근접성 점검 방법이 브라우저와 호환 가능하기만 하면, 브라우저와 호환될 수 있다. CoRA가 암호 없는 인증 체계로 사용되고 노트북에서 사용되는 경우에, 브라우저와 호환되지 않는다(적어도 현재 구현에 기반함). CoRA는 액세스 가능하며, 특히 사용자가 사용할 수 있는 스마트 장치와 함께 작동할 수 있기 때문에 사용자 당 비용을 무시할 수 있다.
3. 보안
본 개시의 구현예에 따라, 시스템은, 각각의 인증에 대한 신규 토큰을 생성하고 하나의 사용자 장치가 전체 키를 저장하지 않기 때문에, 내부 관찰에 대한 복원 탄력성을 갖는다. CoRA는, 여러 인증 서버에 동일한 정보를 송신하지 않기 때문에 그 자체로는 링크할 수 없고 프라이버시 수준이 매우 높을 수 있습다. 본 개시의 구현예는, Shrestha 등의 논문에 나타낸 공격에 기초하여 컨텍스트 조작에 대한 복원 탄력성을 갖는 신규 보안 메트릭을 또한 갖는다. [18]. Google 2SV(2-단계 검증) 및 암호는 이러한 공격의 영향을 받지 않고, phoneAuth는 Bluetooth 공격에 의해 침해될 수 있으며, soundproof는 소리 조작에 취약하다[19]. 본 개시의 구현예는, 시스템이 다양성을 가질 수 있어서, 예를 들어 각각의 사용자 장치가 근접 검증을 위한 상이한 채널을 가질 수 있기 때문에, 컨텍스트 조작 공격에 대해 더욱 안전하다.
B. 정확성 평가
정확성 평가는, 네트워크 토폴로지(예, 연결성, 노드 수), TM의 정확성, 감지 지연, 전파 지연, 공격자 수, 공격자 유형 등과 같은 사기 비율 파라미터를 포함할 수 있는 메트릭을 사용하여, 수행될 수 있다. 일부 구현예에서, 공격자는, 정보 유출 및 서비스 공격 거부에 관한 네트워크 거동과 관련하여 악의적일 수 있다. 다른 구현예에서, 공격자는, 다른 장치에 대한 잘못된 신뢰도 점수를 광고하지만 다른 모든 양태에서 양성으로 작용하는 신뢰도 측정계와 관련하여 악의적일 수 있다. 또 다른 구현예에서, 공격자는, 올바른 토큰 공유 대신에 부정확한 정보를 전송하지만 다른 모든 양태에서 양성으로 작용함으로써, 연산을 방해하는 임계 암호화에 대해 악의적일 수 있다.
도 12는 본 개시의 구현예, 다른 MFA 및 2FA 체계 사이의 유용성과 배치 가능성을 비교한 표를 나타낸다. 도 13은 본 개시의 구현예, 다른 MFA 및 2FA 체계 사이의 보안성을 비교한 표를 나타낸다.
도 14는, 악성 개시자 장치를 포착하기 위해 모든 노드(즉, 사용자 장치)에 필요한 신뢰도 측정계의 라운드 수를 보여준다. 본 개시의 일부 구현예는, 오늘날의 비밀 공유 체계에 의해 제공되지 않는 속성인, 인증 수준의 정상적인 저하를 허용한다. 이 실험에서, 네트워크는 모두 연결된 10개의 노드, 및 자신을 인증하려고 시도하는 하나의 침해된 노드를 갖는다. 네트워크는 악성 노드의 악성 동작을 직접 관찰할 수 있고 0.90의 정확도로 이상 감지기를 실행할 수 있는 4개의 노드가 있다. 신뢰도 정보는 네트워크를 통해 이동할 수 있다. 5 라운드 후, 모든 노드는 악성 노드와 연관된 신뢰도 점수를 업데이트할 수 있다. 이 시점에서 각 노드는, 인증에서 악성 노드에 도움이 될 정도로 악성 노드를 신뢰하지 않는다. 악의적인 노드가 할 수 있는 최상의 것은, 보증 레벨 1에서 자신을 인증하는 것이다.
도 15는, 네트워크 내의 모든 노드가 악성 노드의 비정상적인 거동을 직접 포착할 수 있는 경우에 대해, 네트워크에 하나의 내부 고발자(예, 라우터만이 비정상적인 거동을 관찰함)가 있는 2개의 극단적인 경우를 보여줌으로써, 시스템 내의 내부 고발자 수의 효과를 나타낸다. 모든 노드가 악의적인 거동을 관찰하기 위해 직접 연결되지 않은 네트워크의 경우에, 느린 감지를 보상하기 위해 실행 중인 신뢰도 측정계의 빈도가 더 높아야 한다.
도 16은, 침해된 노드가 감지될 수 있는 속도에 대한 신뢰도 측정계의 정확성의 효과를 보여준다. 이 예시에서, 4개의 내부 고발자 노드가 있다. 정확도는 0.65에서 1로 변경된다. 신뢰도 점수는 정확도에 따라 업데이트된다. 결과는, 정밀도가 낮은 신뢰도 측정계를 사용하더라도 약 20 라운드 후에 악성 노드가 격리되는 역할을 한다는 것을 보여준다. 애플리케이션 설정의 경우, 신뢰도 측정계의 정확도가 낮으면, 신뢰도 측정계를 더 자주 실행하여 공격자를 포착할 가능성을 높일 수 있다.
신뢰도 점수를 다른 노드로 전파함으로써, 네트워크의 모든 노드가 신뢰도 뷰에서 수렴될 수 있다. 모든 노드가 악성 노드의 악성 거동을 직접 관찰할 수 없는 상황에서, 내부 고발자는 네트워크의 나머지 부분에 정보를 전파할 수 있다. 각 장치가 자체적인 로컬 관찰에만 작용하는 경우에, 악성 노드는 항상 노드의 수에서 내부 고발자의 수를 뺀 수의 레벨에서 토큰을 협업 생성할 수 있다.
이 지점은 도 17에 도시되어 있는데, 여기서 단지 4개의 내부고발자가 있고 나머지 노드는 개시자의 악성 거동에 대해 블라인드된다.
C.성능 측정
아래의 표 3은, 세 개의 IoT 장치, 시계, 스마트 온도 조절기, 및 홈 어시스턴트 장치의 예시, 및 이들 장치 각각의 리소스를 제공한다. 이들 각 장치는 적어도 1GHz CPU, Wi-Fi 연결 및 CoRA를 수행하기에 충분한 메모리를 갖는다. 표 3은, 모든 스마트 홈 장치가 리소스 제한형이 아님을 보여준다.
단일 코어, 1 GHz 장치의 경우에, 임계 MAC 토큰을 연산하는 데 약 124:8 ms가 소요된다. 이 수치는 오늘날 대화형 2FA 시스템의 25초 지연과 비교했을 때 무시할 만한 수준이다.
표 3 (스마트 홈 장치 및 리소스 예시)
본 개시의 구현예에 따라, 인증 시, 두 개의 작동은, 관찰자 장치 상의 토큰 공유 생성 및 개시자 상의 토큰 공유 조합을 포함할 수 있다. 여섯 개의 등록된 장치를 가정하면, 세 개의 장치가 보증 레벨 2에 참여하는 경우, 모든 레벨에 대한 토큰 공유를 생성하는 데 약 32 ms가 걸릴 수 있고, 최상의 레벨을 찾고 공유를 결합하는 데 약 7.5 ms가 걸릴 수 있다(표 4 참조). 이 테스트는 2.36 GHz CPU를 갖춘 스마트 폰에서 수행하였다.
현대의 IoT 장치는 스마트 폰과 동등하게 작동할 수 있을 정도로 충분히 강력하다. 예를 들어, Nest 온도 조절 장치, Huawei 시계 2 및 Google Home과 같은 장치는 모두 1+GHz CPU와 0.2-4 RAM을 갖는다. 단일 코어, 1 GHz 장치의 경우에, 임계 MAC 토큰을 연산하는 데 약 124.8 ms가 평균적으로 소요된다. 이 수치는 통신 및 임계 MAC 연산을 포함한다. 이 수치는 오늘날 대화형 2FA 시스템의 25초 지연과 비교했을 때 무시할 만한 수준이다[33]. 표 4는, 보증 레벨 2(10개에 걸친 평균 실험)에서 스마트 폰 상에서 측정된 임계 MAC 작동의 성능을 보여준다.
표 4 (임계 MAC 작동의 성능, 10개의 실험에 걸쳐 보증 레벨 2에서 스마트 폰 상에서 측정됨)
VIII.
응용 분야
이 섹션은 다음과 같은 세 가지 특정 애플리케이션에 대해 본 개시의 구현예에 따라 다중 레벨 및 위험 인식 인증 시스템을 갖는 것의 장점에 대해 논의한다: 1) 높은 보증성으로 등록; 2) 사용자가 인증 토큰의 보증 레벨에 기초하여 돈을 사용할 수 있는 결제 시스템; 및 3) 토큰 보증 레벨에 기초하여 사용자에게 읽기 또는 쓰기 권한이 주어진 로그인 메커니즘.
A. 등록 대 인증
여러 보증 레벨을 갖는 한 가지 애플리케이션은, 일상 작업에 대한 유용성을 늘리는 것보다 더 민감한 작업에 더 높은 보안성을 필요로 한다. 장치 등록은 한 번이지만 매우 민감한 작업으로, 가장 높은 보증 레벨과 가장 높은 임계값이 필요하다.
B. CoRA 및 3D 보안
다른 애플리케이션은, 결제 트랜잭션을 진행할 수 있도록 사용자 인증하는 것을 포함할 수 있다. 카드 부재 상황은, 결제 사기의 60%~70%를 차지한다[28](즉, 공격자에 의한 미인가된 트랜잭션을 감지하지 못함). 온라인 트랜잭션 사기에 대한 한 가지 해결책은, 2FA를 사용하는 것, 보다 구체적으로3D Secure를 사용하는 것이다[8]. 3D Secure는 사용자를 인증에 참여시켜 올바른 사용자가 참여하도록 하기 때문에 현재 버전에서 원활하지 않을 수 있고. 즉, 사용자 불만족 및 잠재적 구매 포기로 인한 비용 때문에 보안을 향상시킨다. 본 개시의 구현예는, 유사한 수준의 보안을 유지하면서 원활한 MFA를 가능하게 한다.
다음으로, CoRA에 대한 구체적인 사용 사례를 설명한다. 등록된 스마트 장치가 여섯 개인 사용자는, 온라인 결제를 시도할 수 있다. 사용자가 자신의 크리덴셜(예, 신용카드 정보)을 입력한 후, 사용자 장치 중 하나(예, 노트북)가 근처 사용자 장치와 통신하고 "관찰"을 요청할 수 있다. 본원에서 설명된 바와 같이, 보증 레벨 3의 토큰이 사용자 장치에 의해 생성되면, 사용자는 자신의 신용 한도에 따른 결제를 쓰기 위한 액세스 권한이 부여될 것이다. 레벨 2의 토큰은 최대 $100의 결제를 허용할 수 있다. 레벨 1의 토큰은 최대 20의 사용을 허용할 수 있다.
C. 민감한 웹사이트에 대한 CoRA 로그인
다른 예시로서, 본 개시의 구현예는 민감한 웹사이트, 데이터 및/또는 위치에 액세스하기 위한 사용자 인증을 허용할 수 있다. 예를 들어, 사용자가 집에 있고(예를 들어, 집 안, 방 안 등)에 다수의 사용자 장치를 갖는 경우에, 레벨 3의 토큰이 생성될 수 있으며, 이는 사용자에게 민감한 웹사이트, 예를 들어 은행 계정에 대한 완전한 액세스를 제공할 수 있다. 사용자가 두 개의 사용자 장치를 근접하게 갖는 경우에, 사용자에게는 자신의 금액을 결제하고 동일한 은행에 있는 자신의 계좌 간에 돈을 이체하기 위한 액세스 권한이 주어질 수 있다. 레벨 1의 토큰의 경우에, 사용자에게 10개의 최근 트랜잭션을 볼 수 있는 액세스 권한을 부여할 수 있지만, 계정과 상호 작용시키지는 않는다. 어느 시점에서든, 사용자는 대화형 2FA를 통해 완전한 액세스를 달성할 수 있다.
IX.
결론
본 개시의 구현예는 임계 암호화 및 이상 감지를 사용함으로써 협업성 인증 메커니즘을 제공한다. 구현예는, 애플리케이션 계층이 보안 및 유용성에 대한 균형을 선택할 수 있는, 분산형 MFA 체계를 가능하게 한다. 사용자 장치에 의해 협업 생성된 인증 토큰은, 액세스 제어로 인증 서버를 지원하고 사용자에게 적절한 수준의 특권을 부여할 수 있는, 보증 레벨을 수반할 수 있다. 본 개시의 구현예는 MFA에 참여하는 장치의 수를 증가시킴으로써 보안을 개선하였다. 구현예는, 사용자 장치가 보증 레벨을 제외하고 인증 서버에 추가 정보를 전송하지 않는다는 의미에서, 사용자 프라이버시를 유지할 수 있다.
X.
컴퓨터 시스템
본원에서 언급된 컴퓨터 시스템은 임의의 적절한 수의 서브시스템을 이용할 수 있다. 이러한 서브시스템의 예는 도 18의 컴퓨터 장치(1800) 내에 나타나 있다. 일부 구현예에서, 컴퓨터 시스템은 단일 컴퓨터 장치를 포함하고, 여기서 서브시스템은 컴퓨터 장치의 구성 요소일 수 있다. 다른 구현예에서, 컴퓨터 시스템은 내부 구성 요소와 함께 다중 컴퓨터 장치를 포함할 수 있고, 각각은 서브시스템이다.
도 18에 나타낸 서브시스템은 시스템 버스(1805)를 통해 상호 연결된다. 프린터(1804), 키보드(1808), 저장 장치(들)(1809), 디스플레이이 어댑터(1811)에 결합되는 모니터(1806), 및 기타 장치와 같은 추가 서브시스템이 나타나 있다. I/O 제어기(1801)에 결합하는 주변 장치와 입력/출력(I/O) 장치는, 입력/출력(I/O) 포트(1007)와 같이 당업계에 공지된 임의의 수의 수단(예, USB, FireWire®)에 의해 컴퓨터 시스템에 연결될 수 있다. 예를 들어, I/O 포트(1807) 또는 외부 인터페이스(1810)(예, 이더넷, 와이파이 등)는 인터넷, 마우스 입력 장치, 또는 스캐너 등의 광대역 네트워크에 컴퓨터 시스템(1800)을 연결하기 위해 사용될 수 있다. 시스템 버스(1805)를 통한 상호 연결은, 중앙 프로세서(1803)로 하여금 각 서브시스템과 통신시키고 시스템 메모리(1802) 또는 저장 장치(들)(1809)(예, 하드 드라이브 또는 광 디스크와 같은 고정형 디스크)로부터의 명령어 실행뿐만 아니라, 서브시스템 간의 정보 교환을 제어시킨다. 시스템 메모리(1802) 및/또는 저장 장치(들)(1809)는 컴퓨터 판독가능 매체를 구현할 수도 있다. 본원에서 언급된 임의의 데이터는 하나의 구성 요소로부터 다른 구성요소로 출력될 수 있고, 사용자에게 출력될 수 있다.
컴퓨터 시스템은, 예를 들어, 외부 인터페이스(1810)에 의해 또는 내부 인터페이스에 의해 함께 접속된 복수의 동일한 구성 요소 또는 서브시스템을 포함할 수 있다. 일부 구현예에서, 컴퓨터 시스템, 서브시스템, 또는 장치는 네트워크를 통해 통신할 수 있다. 이러한 경우, 하나의 컴퓨터는 클라이언트로서 간주될 수 있고 다른 컴퓨터는 서버로서 간주될 수 있으며, 각 컴퓨터는 동일한 컴퓨터 시스템의 일부일 수 있다. 클라이언트와 서버 각각은, 여러 시스템, 서브시스템, 또는 구성 요소를 포함할 수 있다.
설명된 임의 구현예는, 하드웨어(예를 들어, 주문형 집적 회로 또는 필드 프로그래머블 게이트 어레이)를 사용하고/사용하거나 일반적으로 프로그래밍 가능한 프로세서를 갖는 컴퓨터 소프트웨어를 사용하는 제어 로직의 형태로 모듈 방식으로 또는 통합 방식으로 구현될 수 있다는 점을 이해해야 한다. 본원에서 사용되는 바와 같이, 프로세서는, 단일 회로 기판 상의 또는 네트워크화된, 싱글 코어 프로세서, 동일한 집적 칩 상의 멀티 코어 프로세서, 또는 다수의 처리 유닛을 포함한다. 당업자는, 본원에 제공되는 교시와 개시 내용에 기초하여, 하드웨어 및/또는 하드웨어와 소프트웨어의 조합을 이용하여 설명된 구현예를 구현하기 위한 다른 방식 및/또는 방법을 알고 이해할 것이다.
본원에서 설명된 임의의 소프트웨어 구성요소 또는 기능은, 예를 들어, Java, C, C++, C#, Objective-C, Swift 등의 임의의 적절한 컴퓨터 언어, 또는 예를 들어 종래의 또는 객체 지향 기술을 사용하는 Perl 또는 Python 등의 스크립팅 언어를 사용하는 프로세서에 의해 실행되는 소프트웨어 코드로서 구현될 수 있다. 소프트웨어 코드는, 저장 및/또는 전송을 위해 컴퓨터 판독가능 매체 상에 일련의 명령어 또는 커맨드로서 저장될 수 있으며, 적절한 매체는, 랜덤 액세스 메모리(RAM), 읽기 전용 메모리(ROM), 하드 드라이브 또는 플로피 디스크와 같은 자기 매체, 또는 콤팩트 디스크(CD) 또는 DVD(디지털 다기능디스크)와 같은 광 매체, 플래시 메모리 등을 포함한다. 컴퓨터 판독가능 매체는 이러한 저장 장치 또는 전송 장치의 임의의 조합일 수 있다.
이러한 프로그램은 또한, 인터넷 프로토콜을 포함한 다양한 프로토콜을 따르는 유선, 광, 및/또는 무선 네트워크를 통한 송신에 적합한 캐리어 신호를 사용하여 인코딩되고 송신될 수 있다. 이와 같이, 일부 구현예에 따른 컴퓨터 판독가능 매체는 이러한 프로그램으로 인코딩된 데이터 신호를 사용하여 생성될 수 있다. 프로그램 코드로 인코딩된 컴퓨터 판독가능 매체는, 호환 장치와 함께 패키징될 수 있고 또는 (예를 들어, 인터넷 다운로드를 통해) 다른 장치들과는 별도로 제공될 수 있다. 이러한 임의의 컴퓨터 판독가능 매체는, 단일 컴퓨터 제품(예를 들어, 하드 드라이브, CD, 또는 전체 컴퓨터 시스템) 상에 또는 내부에 상주할 수 있으며, 시스템 또는 네트워크 내의 상이한 컴퓨터 제품들 상에 또는 내부에 존재할 수 있다. 컴퓨터 시스템은, 본원에 언급된 결과들 중 임의의 결과를 사용자에게 제공하기 위한 모니터, 프린터, 또는 다른 적합한 디스플레이를 포함할 수 있다.
본원에서 설명되는 방법은, 단계를 수행하도록 구성될 수 있는 하나 이상의 프로세서를 포함한 컴퓨터 시스템으로 완전히 또는 부분적으로 수행될 수 있다. 따라서, 구현예는 본원에 설명된 임의의 방법의 단계를 수행하도록 구성된 컴퓨터 시스템에 관한 것일 수 있고, 각각의 단계 또는 각각의 단계 그룹을 수행하는 상이한 구성 요소를 잠재적으로 갖는다. 번호가 매겨진 단계로서 제시되지만, 본원에서 방법 단계는 동일한 시간에 또는 다른 순서로 수행될 수 있다. 또한, 이들 단계의 일부는 다른 방법으로부터의 다른 단계의 부분과 함께 사용될 수도 있다. 또한, 단계의 전부 또는 일부는 선택적일 수 있다. 또한, 임의의 방법의 임의의 단계는 모듈, 회로, 또는 이들 단계를 수행하기 위한 다른 수단으로 수행될 수 있다.
구체적 구현예의 특정 상세 내용은 구현예의 사상 및 범주를 벗어나지 않으면 임의의 적합한 방식으로 조합될 수도 있다. 그러나, 다른 구현예는 각각의 개별 양태 또는 이들 각각의 양태의 특정 조합에 관한 것일 수 있다. 예시적인 구현예의 전술은 예시 및 설명의 목적으로 제시되었다. 설명된 정확한 형태로 구현예를 제한하거나 하나도 빠뜨리는 것이 없도록 의도하는 것은 아니고, 상술한 교시 관점에서 많은 개조 및 변형이 가능하다. 구현예는 구현 원리 및 실제 응용을 가장 잘 설명하기 위해 선택되고 설명됨으로써, 당업자는 다양한 구현예 및 특정 용도에 맞는 이들 구현예에 대한 다양한 구현과 다양한 변형을 최대한 활용할 수 있게 한다.
단수("일", "하나", "특정한 하나")의 인용은 특정하게 반대로 나타내지 않는다면 "하나 이상"을 의미하는 것으로 의도된다. "또는"의 사용은 "포괄적인 또는"을 의미하기 위해 의도되며, 구체적으로 언급하지 않는 한 "독점적인 또는"을 의미하지 않는다.
본원에 언급한 모든 특허, 특허 출원, 간행물, 및 설명은 모든 목적을 위해 그 전체 내용이 참조로 포함된다. 어느 것도 종래 기술인 것으로 인정되지는 않는다.
XI.
참고문헌
1.
Algorithms, key size and protocols report, h2020-ict-2014 project 645421, ecrypt csa, 2018
2.
Barker, E., NIST special publication 800-57 part 1, revision 4, 2016
3.
Boldyreva, A., Threshold signatures, multisignatures and blind signatures based on the gap-diffiehellman-group signature scheme, in Proceedings of the 6th International Workshop on Theory and Practice in Public Key Cryptography: Public Key Cryptography (London, UK, UK, 2003), PKC '03, Springer-Verlag, pp. 31-46
4.
Bonneau, J. et al., The quest to replace passwords: A framework for comparative evaluation of web authentication schemes, in Security and Privacy (SP), 2012 IEEE Symposium on (2012), IEEE, pp. 553-567
5.
Corner, M. D., and Noble, B. D., Zero-interaction authentication, in Proceedings of the 8th annual international conference on Mobile computing and networking (2002), ACM, pp. 1-11
6.
Czeskis, A. et al., Strengthening user authentication through opportunistic cryptographic identity assertions, in Proceedings of the 2012 ACM conference on Computer and communications security (2012), ACM, pp. 404-414
7.
Doshi, R. et al., Machine learning DDoS detection for consumer internet of things devices, arXiv preprint arXiv:1804.04159 (2018).
8.
EMVCo. 3d secure v2.0, 2017.
9.
Halevi, T. et al., Secure proximity detection for nfc devices based on ambient sensor data, in European Symposium on Research in Computer Security (2012), Springer, pp. 379-396
10.
Kamvar, S. D. et al., The eigentrust algorithm for reputation management in p2p networks, in Proceedings of the 12th international conference on World Wide Web (2003), ACM, pp. 640-651
11.
Karapanos, N. et al., Sound-Proof: Usable two-factor authentication based on ambient sound, in USENIX Security Symposium (2015), pp. 483-498
12.
Marforio, C. et al., Smartphones as practical and secure location verification tokens for payments, in NDSS (2014)
13.
Mustafa, M. A. et al., Frictionless authentication system: Security & privacy analysis and potential solutions. arXiv preprint arXiv:1802.07231 (2018)
14.
Naor, M. et al., Distributed pseudo-random functions and kdcs, in Proceedings of the 17th International Conference on Theory and Application of Cryptographic Techniques (Berlin, Heidelberg, 1999), EUROCRYPT'99, Springer-Verlag, pp. 327-346
15.
Raza, S. et al., Real-time intrusion detection in the internet of things, Ad hoc networks 11, 8 (2013), 2661-2674
16.
Shoup, V., Practical threshold signatures, in Proceedings of the 19th International Conference on Theory and Application of Cryptographic Techniques (Berlin, Heidelberg, 2000), EUROCRYPT'00, Springer-Verlag, pp. 207-220
17.
Shrestha, B. et al., Drone to the rescue: Relay-resilient authentication using ambient multi-sensing, in International Conference on Financial Cryptography and Data Security (2014), Springer, pp. 349-364
18.
Shrestha, B. et al., Contextual proximity detection in the face of context-manipulating adversaries, arXiv preprint arXiv:1511.00905 (2015)
19.
Shrestha, B. et al., The sounds of the phones: dangers of zero-effort second factor login based on ambient audio, in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (2016), ACM, pp. 908-919
20.
Shrestha, P., and Saxena, No., Listening watch: Wearable two-factor authentication using speech signals resilient to near-far attacks, in Proceedings of the 11th ACM Conference on Security & Privacy in Wireless and Mobile Networks (2018), ACM, pp. 99-110
21.
Truong, H. et al., Comparing and fusing different sensor modalities for relay attack resistance in zero-interaction authentication, in Pervasive Computing and Communications (PerCom), 2014 IEEE International Conference on (2014), IEEE, pp. 163-171
22.
Truong, H. et al., Using contextual co-presence to strengthen zero-interaction authentication: Design, integration and usability, Pervasive and Mobile Computing 16 (2015), 187-204
23.
Visa, AND Pymnts.com. How will we pay - A week in the life of a connected consumer. Available online at www.pymnts.com/news/payments-innovation/2018/pymnts-visa-study-on-how-connected-devices-and-voice-change-how-and-who-consumers-pay/last accessed November 1, 2018), Oct. 2018
24.
World Wide Web Consortium (W3C). Webauthn. www.w3.org/TR/webauthn 4
25.
Shamir, A., How to share a secret. Communications of the ACM 22, 11 (1979), 612-613.
26.
Al-Garadi, M. A., et al., A survey of machine and deep learning methods for internet of things (iot) security. arXiv preprint arXiv:1807.11023 (2018).
26.
CERTICOM RESEARCH. Sec 2: Recommended Elliptic Curve Domain Parameters. Available online at www.secg.org/sec2-v2.pdf, 2010.
27.
IETF. Compact representation of an elliptic curve point. Available online at www.tools.ietf.org/id/draft-jivsov-ecc-compact-05.html, 2014.
28.
Juniper Research., Online payment fraud whitepaper. Available online at www.experian.com/assets/decision-analytics/white-papers/juniper-research-online-payment-fraud-wp-2016.pdf, 2016.
29.
Lee, S.-Y., et al., Profiot: Abnormal behavior profiling (abp) of iot devices based on a machine learning approach. In 2017 27th International Telecommunication Networks and Applications Conference (ITNAC) (2017), IEEE, pp. 1-6.
30.
Maurer, U. Secure multi-party computation made simple. Discrete Applied Mathematics 154, 2 (2006), 370 - 381. Coding and Cryptography.
31.
Nobakht, M., et al., A host-based intrusion detection and mitigation framework for smart home iot using openflow. In Availability, Reliability and Security (ARES), 2016 11th International Conference on (2016), IEEE, pp. 147-156.
32.
Smart, N. P., Algorithms, Key Size and Protocols Report, H2020-ICT-2014 Project 645421, ECRYPT CSA. Available online at www.ecrypt.eu.org/csa/documents/D5.4- FinalAlgKeySizeProt.pdf, 2018.
33.
Weir, C. S., et al., User perceptions of security, convenience and usability for ebanking authentication tokens. Computers & Security 28, 1-2 (2009), 47-62.
34.
Zarpelao, B. B., et al., A survey of intrusion detection in internet of things. Journal of Network and Computer Applications 84 (2017), 25-37.
Claims (33)
- 방법으로서,
개시자 장치에 의해, 하나 이상의 인증 장치들로 관찰자 요청을 전송 (broadcast)하되, 상기 하나 이상의 인증 장치들은 보증 레벨들의 범위로부터 보증 레벨을 결정하고 상기 보증 레벨에 대응하는 토큰 공유를 결정하는 단계;
상기 개시자 장치에 의해, 상기 하나 이상의 인증 장치들로부터, 상기 보증 레벨에 대응하는 토큰 공유를 포함한 적어도 하나의 관찰자 응답을 수신하는 단계;
상기 개시자 장치에 의해, 토큰 공유들의 세트를 사용하여 인증 토큰을 생성하는 단계; 및
상기 개시자 장치에 의해, 상기 인증 토큰을 인증 서버에 송신하되, 상기 인증 서버는 상기 인증 토큰을 검증하는 단계를 포함하는, 방법. - 제1항에 있어서, 상기 적어도 하나의 관찰자 응답은 상기 보증 레벨을 추가로 포함하는, 방법.
- 제1항에 있어서, 상기 관찰자 요청은 하나 이상의 요청된 보증 레벨들을 명시하고, 상기 하나 이상의 요청된 보증 레벨들은 상기 토큰 공유에 대응하는 보증 레벨을 포함하는, 방법.
- 제1항에 있어서, 상기 토큰 공유들의 세트는 제1 보증 레벨과 연관되고, 상기 방법은,
상기 토큰 공유들의 세트의 제1 양을 결정하는 단계; 및
상기 개시자 장치에 의해, 적어도 토큰 공유들의 임계량을 포함한 상기 토큰 공유들의 세트와 연관된 상기 보증 레벨들의 범위의 제1 보증 레벨을, 상기 제1 양과 상기 임계량을 비교하여 결정하는 단계를 추가로 포함하는, 방법. - 제4항에 있어서, 상기 토큰 공유들의 제1 양은 상기 토큰 공유들의 세트의 가중치들을 합하여 결정되며, 가중치에 대해 값이 높을수록 상기 토큰 공유는 더욱 보안성이 있음을 나타내는, 방법.
- 제4항에 있어서,
상기 개시자 장치에 의해, 상기 제1 보증 레벨에 대응하는 개시자 토큰 공유와 더 낮은 보증 레벨이 존재하는 경우에 임의의 다른 토큰 공유(들)를 획득하는 단계를 추가로 포함하는, 방법. - 제4항에 있어서, 상기 토큰 공유들의 임계량은 상기 제1 보증 레벨에 대해 미리 결정되는, 방법.
- 제4항에 있어서, 상기 제1 보증 레벨은, 상기 개시자 장치가 적어도 상기 토큰 공유들의 임계량을 유지하는, 최고 보증 레벨인, 방법.
- 제4항에 있어서, 상기 보증 레벨은 하나 이상의 보증 레벨들이고, 상기 토큰 공유는 상기 하나 이상의 보증 레벨들에 대응하는 하나 이상의 토큰 공유들이고, 상기 제1 보증 레벨은 하나 이상의 토큰 공유들의 세트들과 각각 연관된 하나 이상의 제1 보증 레벨들을 포함하고, 상기 인증 토큰은 하나 이상의 인증 토큰들인, 방법.
- 제4항에 있어서,
상기 개시자 장치에 의해, 상기 제1 보증 레벨을 상기 인증 서버에 송신하는 단계를 추가로 포함하는, 방법. - 제1항에 있어서, 상기 관찰자 요청을 전송하기 전에, 상기 방법은,
상기 개시자 장치에 의해, 상기 인증 서버로부터 챌린지 요청을 수신하는 단계를 추가로 포함하는, 방법. - 제11항에 있어서, 상기 인증 서버는 사용자 장치로부터 정품 크리덴셜들을 수신한 후에 상기 챌린지 요청을 생성하는, 방법.
- 제11항에 있어서, 상기 챌린지 요청은 사용자 장치를 통해 상기 인증 서버로부터 수신되는, 방법.
- 제13항에 있어서, 상기 인증 토큰은 상기 사용자 장치를 통해 상기 인증 서버로 송신되는, 방법.
- 제1항에 있어서, 상기 하나 이상의 인증 장치들은 상기 개시자 장치의 통신 범위에 있는, 방법.
- 제1항에 있어서, 상기 인증 토큰을 생성하는 단계는,
상기 개시자 장치에 의해, 상기 토큰 공유들의 세트로부터 중복된 토큰 공유를 제거하는 단계; 및
상기 개시자 장치에 의해, 상기 인증 토큰을 결정하기 위해 상기 토큰 공유들의 세트로부터 잔여 토큰 공유들을 XOR하는 단계를 추가로 포함하는, 방법. - 제1항에 있어서, 상기 관찰자 요청은 블루투스 통신 채널을 통해 전송되는, 방법.
- 제1항에 있어서, 상기 관찰자 요청을 전송하기 전에, 상기 방법은,
상기 개시자 장치에 의해, 사용자 입력, 내부 타이머, 및 이상 감지 중 적어도 하나에 기초하여 상기 관찰자 요청을 결정하는 단계를 추가로 포함하는, 방법. - 방법으로서,
인증 장치에 의해, 개시자 장치 장치로부터, 관찰자 요청을 수신하는 단계;
상기 인증 장치에 의해, 신뢰도 점수에 기초해서 상기 개시자 장치와 연관된 제1 보증 레벨을 결정하되, 상기 제1 보증 레벨은 보증 레벨들의 범위로부터 결정되는 단계;
상기 인증 장치에 의해, 상기 제1 보증 레벨에 대응하는 토큰 공유를 획득하는 단계; 및
상기 인증 장치에 의해, 상기 제1 보증 레벨에 대한 토큰 공유를 상기 개시자 장치로 송신하는 단계를 포함하는, 방법. - 제19항에 있어서, 상기 토큰 공유를 획득하는 단계는,
상기 인증 장치에 의해, 상기 제1 보증 레벨보다 낮은 보증 레벨들이 존재하는 경우에 더 낮은 보증 레벨들에 상응하는 임의의 다른 토큰 공유(들)를 획득하는 단계를 추가로 포함하는, 방법. - 제19항에 있어서, 상기 토큰 공유를 송신하는 단계는,
상기 인증 장치에 의해, 각각의 더 낮은 보증 레벨에 대해 상기 다른 토큰 공유(들)를 송신하는 단계를 추가로 포함하는, 방법. - 제19항에 있어서, 상기 개시자 장치는, 상기 인증 장치를 포함한 근접 인증 장치로부터 수신된 토큰 공유들의 임계량과 연관된, 최고 보증 레벨을 결정하는, 방법.
- 제19항에 있어서,
상기 인증 장치에 의해, 적어도 네트워크 데이터에 기초하여 상기 개시자 장치와 연관된 신뢰도 점수를 결정하는 단계를 추가로 포함하는, 방법. - 제23항에 있어서, 상기 네트워크 데이터는 전송 속도, 데이터 수신 속도, 데이터 패킷들의 평균 크기, 소스 주소, 도메인 이름 시스템 정보, IP 주소, 호스트 이름, 신호 세기 데이터, 및 Wi-Fi 연결 데이터를 포함하는, 방법.
- 제24항에 있어서, 상기 신뢰도 점수는 과거 이력의 전형적인 전송 속도와 상기 전송 속도 간의 차이, 과거 이력의 전형적인 데이터 수신 속도와 상기 데이터 수신 속도 간의 차이, 및 과거 이력의 전형적인 데이터 패킷의 평균 크기와 상기 데이터 패킷의 평균 크기 간의 차이 중 적어도 하나에 기초하여 결정되는, 방법.
- 제23항에 있어서, 상기 신뢰도 점수는 로컬 신뢰도 점수이고, 상기 신뢰도 점수를 결정하는 단계는,
상기 인증 장치에 의해, 하나 이상의 추가 인증 장치들로부터 하나 이상의 원격 신뢰도 점수들을 수신하는 단계; 및
상기 인증 장치에 의해, 상기 로컬 신뢰도 점수와 상기 하나 이상의 원격 신뢰도 점수들의 가중 평균을 사용하여, 상기 신뢰도 점수를 결정하는 단계를 추가로 포함하는, 방법. - 제21항에 있어서, 상기 제1 보증 레벨에 대응하는 토큰 공유 및 더 낮은 보증 레벨들에 대응하는 임의의 다른 토큰 공유(들)를 획득하는 단계는,
상기 인증 장치에 의해, 상기 제1 보증 레벨에 대응하는 제1 키 공유 및 상기 임의의 다른 토큰 공유(들)에 대응하는 임의의 다른 키 공유(들)를 검색하는 단계;
상기 인증 장치에 의해, 상기 제1 보증 레벨에 대응하는 토큰 공유를 상기 제1 키 공유로부터 유도하는 단계; 및
상기 인증 장치에 의해, 상기 더 낮은 보증 레벨들에 대응하는 임의의 다른 토큰 공유(들)를 상기 임의의 다른 키 공유(들)로부터 유도하는 단계를 추가로 포함하는, 방법. - 제27항에 있어서, 상기 제1 키 공유 및 상기 임의의 다른 키 공유(들)는 상기 개시자 장치, 및 상기 인증 장치를 포함한 하나 이상의 인증 장치들 사이에서 공유된 암호화 키의 분획 (fraction)들인, 방법.
- 제1항 내지 제28항 중 어느 한 항의 방법의 작동들을 수행하도록 컴퓨터 시스템을 제어하기 위한 복수의 명령어를 저장한 컴퓨터 판독가능 매체를 포함하는 컴퓨터 제품.
- 시스템으로서,
제29항의 컴퓨터 제품; 및
상기 컴퓨터 판독가능 매체에 저장된 명령어를 실행하기 위한 하나 이상의 프로세서들을 포함하는, 시스템. - 제1항 내지 제28항 중 어느 한 항의 방법을 수행하기 위한 수단을 포함하는 시스템.
- 제1항 내지 제28항 중 어느 한 항의 방법을 수행하도록 구성되는 시스템.
- 제1항 내지 제28항 중 어느 한 항의 방법의 단계들을 각각 수행하는 모듈들을 포함한 시스템.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201862768002P | 2018-11-15 | 2018-11-15 | |
| US62/768,002 | 2018-11-15 | ||
| PCT/US2019/048991 WO2020101787A1 (en) | 2018-11-15 | 2019-08-30 | Collaborative risk aware authentication |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20210077703A true KR20210077703A (ko) | 2021-06-25 |
Family
ID=70731651
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020217013746A KR20210077703A (ko) | 2018-11-15 | 2019-08-30 | 협업성 위험 인식 인증 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US11895113B2 (ko) |
| EP (1) | EP3881517A4 (ko) |
| KR (1) | KR20210077703A (ko) |
| CN (1) | CN112970236B (ko) |
| SG (1) | SG11202104780XA (ko) |
| WO (1) | WO2020101787A1 (ko) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2022059099A (ja) * | 2019-02-25 | 2022-04-13 | ソニーグループ株式会社 | 情報処理装置、情報処理方法、及び、プログラム |
| GB2592364A (en) * | 2020-02-22 | 2021-09-01 | Mccabe Liam | Wireless network security system and method |
| EP3897019A1 (en) * | 2020-04-17 | 2021-10-20 | Secure Thingz Limited | A provisioning control apparatus, system and method |
| US11392684B2 (en) * | 2020-07-09 | 2022-07-19 | Bank Of America Corporation | Authentication of user activities based on establishing communication links between network devices |
| US11641665B2 (en) | 2020-09-09 | 2023-05-02 | Self Financial, Inc. | Resource utilization retrieval and modification |
| US11475010B2 (en) | 2020-09-09 | 2022-10-18 | Self Financial, Inc. | Asynchronous database caching |
| US11470037B2 (en) | 2020-09-09 | 2022-10-11 | Self Financial, Inc. | Navigation pathway generation |
| US20220075877A1 (en) * | 2020-09-09 | 2022-03-10 | Self Financial, Inc. | Interface and system for updating isolated repositories |
| US20220123950A1 (en) * | 2020-10-15 | 2022-04-21 | Cisco Technology, Inc. | Multi-party cloud authenticator |
| US11824866B2 (en) * | 2021-02-05 | 2023-11-21 | Cisco Technology, Inc. | Peripheral landscape and context monitoring for user-identify verification |
| US11677552B2 (en) * | 2021-09-09 | 2023-06-13 | Coinbase Il Rd Ltd. | Method for preventing misuse of a cryptographic key |
| WO2023073041A1 (en) * | 2021-10-26 | 2023-05-04 | Assa Abloy Ab | Hardware integrity control of an electronic device |
| US20230188527A1 (en) * | 2021-12-15 | 2023-06-15 | Juniper Networks, Inc. | Use of sentiment analysis to assess trust in a network |
| US11695772B1 (en) * | 2022-05-03 | 2023-07-04 | Capital One Services, Llc | System and method for enabling multiple auxiliary use of an access token of a user by another entity to facilitate an action of the user |
| CN114978730B (zh) * | 2022-05-27 | 2023-09-15 | 深圳铸泰科技有限公司 | 一种感知态势处物联网安全检测方法及存储介质 |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1708528A1 (en) * | 2005-03-31 | 2006-10-04 | BRITISH TELECOMMUNICATIONS public limited company | Location based authentication |
| JP5207965B2 (ja) * | 2005-05-06 | 2013-06-12 | ベリサイン・インコーポレイテッド | トークン共有システムおよび方法 |
| CA3045817A1 (en) * | 2010-01-12 | 2011-07-21 | Visa International Service Association | Anytime validation for verification tokens |
| US8504831B2 (en) * | 2010-12-07 | 2013-08-06 | At&T Intellectual Property I, L.P. | Systems, methods, and computer program products for user authentication |
| EP2786362A2 (en) * | 2011-12-01 | 2014-10-08 | Integrita Computing Systems India Private Limited | A method of generation and transmission of secure tokens based on tokens generated by trng and split into shares and the system thereof |
| EP2645664A1 (en) * | 2012-03-30 | 2013-10-02 | Stopic, Bojan | Authentication system and method for operating an authentication system |
| TW201417598A (zh) | 2012-07-13 | 2014-05-01 | Interdigital Patent Holdings | 安全性關聯特性 |
| US9148284B2 (en) * | 2014-01-14 | 2015-09-29 | Bjoern Pirrwitz | Identification and/or authentication method |
| EP3140798A4 (en) * | 2014-05-05 | 2017-12-20 | Visa International Service Association | System and method for token domain control |
| US10050955B2 (en) * | 2014-10-24 | 2018-08-14 | Netflix, Inc. | Efficient start-up for secured connections and related services |
| US10083295B2 (en) * | 2014-12-23 | 2018-09-25 | Mcafee, Llc | System and method to combine multiple reputations |
| CN107925668B (zh) * | 2015-07-02 | 2021-08-03 | 康维达无线有限责任公司 | 资源驱动的动态授权框架 |
| CN105071938B (zh) * | 2015-07-14 | 2018-08-21 | 中国科学技术大学 | 一种基于门限秘密共享的组认证方法 |
| US20170149828A1 (en) * | 2015-11-24 | 2017-05-25 | International Business Machines Corporation | Trust level modifier |
| US11301550B2 (en) * | 2016-09-07 | 2022-04-12 | Cylance Inc. | Computer user authentication using machine learning |
| US10548013B2 (en) * | 2017-03-06 | 2020-01-28 | International Business Machines Corporation | Security of shared credentials in crowdsourced wireless networks |
| US20180317085A1 (en) * | 2017-05-01 | 2018-11-01 | Avaya Inc. | Device authentication |
| US20190280863A1 (en) * | 2018-03-06 | 2019-09-12 | BizOne Ltd. | Recovery of secret data in a distributed system |
| US11038895B2 (en) * | 2018-09-28 | 2021-06-15 | Intel Corporation | Trust management mechanisms |
-
2019
- 2019-08-30 EP EP19885336.8A patent/EP3881517A4/en active Pending
- 2019-08-30 SG SG11202104780XA patent/SG11202104780XA/en unknown
- 2019-08-30 KR KR1020217013746A patent/KR20210077703A/ko not_active Application Discontinuation
- 2019-08-30 CN CN201980073561.5A patent/CN112970236B/zh active Active
- 2019-08-30 US US17/291,090 patent/US11895113B2/en active Active
- 2019-08-30 WO PCT/US2019/048991 patent/WO2020101787A1/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| EP3881517A1 (en) | 2021-09-22 |
| WO2020101787A1 (en) | 2020-05-22 |
| US20210409405A1 (en) | 2021-12-30 |
| CN112970236B (zh) | 2023-07-04 |
| EP3881517A4 (en) | 2022-01-12 |
| SG11202104780XA (en) | 2021-06-29 |
| CN112970236A (zh) | 2021-06-15 |
| US11895113B2 (en) | 2024-02-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11895113B2 (en) | Collaborative risk aware authentication | |
| Williams et al. | A survey on security in internet of things with a focus on the impact of emerging technologies | |
| Hong | P2P networking based internet of things (IoT) sensor node authentication by Blockchain | |
| Rathore et al. | Real-time secure communication for Smart City in high-speed Big Data environment | |
| CN112425136B (zh) | 采用多方计算(mpc)的物联网安全性 | |
| Wang et al. | A smart card based efficient and secured multi-server authentication scheme | |
| US20230033988A1 (en) | Consensus-based online authentication | |
| Nyangaresi | A formally validated authentication algorithm for secure message forwarding in smart home networks | |
| Khan et al. | Trust-based lightweight security protocol for device to device multihop cellular communication (TLwS) | |
| Sami et al. | A comprehensive review of hashing algorithm optimization for IoT devices | |
| Ahsan et al. | IoT devices, user authentication, and data management in a secure, validated manner through the blockchain system | |
| Rana et al. | Privacy-preserving key agreement protocol for fog computing supported internet of things environment | |
| Soleymani et al. | Truth: Trust and authentication scheme in 5g-iiot | |
| Aiash | A formal analysis of authentication protocols for mobile devices in next generation networks | |
| Dou et al. | CLAS: A novel communications latency based authentication scheme | |
| Sankar et al. | A Secure Third-Party Auditing Scheme Based on Blockchain Technology in Cloud Storage | |
| Ramkumar et al. | A distributed method of key issue and revocation of mobile ad hoc networks using curve fitting | |
| Gautam et al. | A probably secure biometric‐based authentication and key agreement scheme for Internet of Drones | |
| Nagaraju et al. | An effective mutual authentication scheme for provisioning reliable cloud computing services | |
| Rajamanickam et al. | EAPIOD: ECC based authentication protocol for insider attack protection in IoD scenario | |
| Hemavathi et al. | Ds2an: Deep stacked sparse autoencoder for secure and fast authentication in hetnets | |
| Abi-Char et al. | A secure and lightweight authenticated key agreement protocol for distributed IoT applications | |
| Salajegheh et al. | CoRA: Collaborative Risk-aware Authentication | |
| Mutaher et al. | ZKPAUTH: an authentication scheme based zero-knowledge proof for software defined network | |
| Mosemann | Assessing Security Risks with the Internet of Things |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E902 | Notification of reason for refusal |