KR20220069020A - 전송 계층 보안 및 기타 컨텍스트에서의 데이터 검증을 위한 분산 기술 - Google Patents

전송 계층 보안 및 기타 컨텍스트에서의 데이터 검증을 위한 분산 기술 Download PDF

Info

Publication number
KR20220069020A
KR20220069020A KR1020227010610A KR20227010610A KR20220069020A KR 20220069020 A KR20220069020 A KR 20220069020A KR 1020227010610 A KR1020227010610 A KR 1020227010610A KR 20227010610 A KR20227010610 A KR 20227010610A KR 20220069020 A KR20220069020 A KR 20220069020A
Authority
KR
South Korea
Prior art keywords
client device
verifier
server
secure session
session
Prior art date
Application number
KR1020227010610A
Other languages
English (en)
Inventor
판 장
사이 크리쉬나 디팍 마람
하재슬린 말바이
스티븐 골드페더
아리 쥴스
Original Assignee
코넬 유니버시티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 코넬 유니버시티 filed Critical 코넬 유니버시티
Publication of KR20220069020A publication Critical patent/KR20220069020A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Abstract

일 실시예에서, 검증자 디바이스는 하나 이상의 네트워크를 통해 클라이언트 디바이스 및 서버 디바이스와 통신하도록 구성된다. 검증자 디바이스는 검증자 디바이스 및 클라이언트 디바이스가 서버 디바이스와의 보안 세션의 세션 키의 각 공유분들을 획득하는 클라이언트 디바이스 및 서버 디바이스와의 3자간 핸드셰이크 프로토콜에 참여한다. 검증자 디바이스는 클라이언트 디바이스로부터 서버 디바이스와의 보안 세션에 관한 커미트먼트를 수신하고, 커미트먼트의 수신에 응답하여, 클라이언트 디바이스가 이전에 액세스 가능하지 않았던 보안 세션에 관한 추가적인 정보를 클라이언트 디바이스에 배포한다. 검증자 디바이스는 커미트먼트 및 추가적인 정보에 적어도 부분적으로 기초하여, 보안 세션의 일부로서 서버 디바이스로부터 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증한다.

Description

전송 계층 보안 및 기타 컨텍스트에서의 데이터 검증을 위한 분산 기술
관련 출원(들) 교차 참조
본 출원은 2019년 8월 30일자로 출원되고 명칭이 "DECO: Decentralized Oracles for TLS"인 미국 특허 가출원 제62/894,052호의 우선권을 주장하며, 이는 전문이 본원에 참조로 원용된다.
정부 지원 성명
본 발명은 미 국립 과학 재단(National Science Foundation, NSF)의 승인 번호 CNS-1514163, CNS-1564102, CNS-1704615 및 CNS-1933655, 및 미 육군 연구소(Army Research Office, ARO) 승인 번호 W911NF161-0145 하의 미국 정부 지원으로 이루어졌다. 미국 정부는 본 발명에 대한 특정 권리들을 갖는다.
기술분야
본 기술분야는 일반적으로 정보 보안에 관한 것으로, 예를 들어, 데이터가 특정 소스로부터 온 것임을 증명하거나 그 외 전송 계층 보안(TLS)의 컨텍스트 및 다른 컨텍스트들에서 획득된 데이터의 정확성을 검증하기 위한 기술들을 포함한다.
TLS의 광범위한 전개로 인해, 사용자들은 종단간 기밀성 및 무결성을 갖는 채널들을 통해 개인 데이터에 액세스할 수 있다. 그러나, 사용자들이 할 수 없는 것은 이러한 데이터의 출처, 즉, 이것이 특정 웹사이트로부터 진정으로 비롯된 것이라는 것을 제3자에게 증명하는 것이다. 기존의 접근법들은 바람직하지 않은 신뢰 가정을 도입하거나 서버측 수정을 요구한다. 그 결과, 사용자의 개인 데이터의 값은 그 기점에 고정된다.
예시적인 실시예들은 TLS를 위한 그리고 데이터가 특정 소스로부터 온 것임을 증명하는 것이 필요하거나 그 외 요구되는 다수의 다른 애플리케이션들에서의 분산형 오라클을 제공한다.
예를 들어, 일부 실시예들은 사용자들로 하여금 데이터 자체를 비밀로 유지하면서, TLS를 통해 액세스된 데이터 조각이 특정 웹사이트로부터 온 것임을 증명하고, 선택적으로 영지식(zero-knowledge)으로 이러한 데이터에 대한 명제들을 증명할 수 있게 하는 분산형 오라클 - 본원에서 예시적으로 DECO로서 지칭됨 - 을 제공함으로써 기존의 접근법들의 상술된 단점들을 극복한다. 이에 따라, DECO는 데이터를 중앙 집중형 웹 서비스 사일로들로부터 해제시켜, 다양한 애플리케이션들이 액세스 가능하게 만들 수 있다. 바람직하게는 DECO는 예시적인 실시예들에서 신뢰 하드웨어 또는 서버측 수정 없이 작동한다.
일 실시예에서, 장치는 프로세서 및 프로세서에 결합된 메모리를 포함하는 검증자 디바이스를 포함한다. 검증자 디바이스는 하나 이상의 네트워크를 통해 클라이언트 디바이스 및 서버 디바이스와 통신하도록 구성된다. 검증자 디바이스는 검증자 디바이스 및 클라이언트 디바이스가 서버 디바이스와의 보안 세션의 세션 키의 각 공유분들을 획득하는 클라이언트 디바이스 및 서버 디바이스와의 3자간 핸드셰이크 프로토콜에 참여한다. 검증자 디바이스는 클라이언트 디바이스로부터 서버 디바이스와의 보안 세션에 관한 커미트먼트를 수신하고, 커미트먼트의 수신에 응답하여, 클라이언트 디바이스가 이전에 액세스 가능하지 않았던 보안 세션에 관한 추가적인 정보를 클라이언트 디바이스에 배포한다. 검증자 디바이스는 커미트먼트 및 추가적인 정보에 적어도 부분적으로 기초하여, 보안 세션의 일부로서 서버 디바이스로부터 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증한다.
전술한 배열들은 단지 예들일 뿐이고, 다수의 대안적인 배열들이 가능한 것으로 이해되어야 한다.
본 발명의 이러한 및 다른 실시예들은 시스템들, 방법들, 장치들, 처리 디바이스들, 집적 회로들, 및 소프트웨어 프로그램 코드가 내장된 프로세서 판독 가능 저장 매체를 포함하지만, 이에 제한되지는 않는다.
도 1은 예시적인 실시예에서 TLS에 대한 분산형 오라클을 구현하는 정보 처리 시스템을 도시한다.
도 2는 예시적인 실시예에서의TLS에 대한 분산형 오라클을 구현하기 위한 프로세스의 흐름도이다.
도 3은 예시적인 실시예에서 분산형 오라클 기능의 일례를 도시한다.
도 4는 예시적인 실시예에서 서버 디바이스, 증명자 디바이스 및 검증자 디바이스를 포함하는 분산형 오라클 구현에서의 디바이스 상호작용의 다수의 단계들을 도시한다.
도 5는 예시적인 실시예에서 선택적 개방 및 컨텍스트 무결성 공격들을 실증하기 위해 사용되는 입출금 내역 정보를 포함하는 예시적인 데이터를 도시한다.
도 6은 예시적인 실시예에서 분산형 오라클 프로토콜의 하나의 가능한 구현의 상세도를 도시한다.
도 7은 예시적인 실시예에서 분산형 오라클을 구현하는 데 이용되는 3자간 핸드쉐이크 프로토콜의 상세한 예를 도시한다.
도 8은 예시적인 실시예에서 키 공유분들을 설정할 때 증명자 디바이스와 검증자 디바이스 사이에서 수행되는 프로토콜을 도시한다.
도 9 및 도 10은 예시적인 실시예들에서 분산형 오라클의 구현과 관련하여 이용되는 프로토콜들의 추가적인 예들을 도시한다.
도 11은 두 당사자들을 수반하여 당사자들 중 한 당사자가 분산형 오라클을 이용하여 스마트 계약에 제공되는 정보를 획득하는 스마트 계약 실시예를 도시한다.
도 12 및 도 13은 예시적인 실시예들에서 하나 이상의 분산형 오라클의 각 노출 및 수정 모드들을 사용하여 처리되는 예시적인 데이터를 도시한다.
도 14는 예시적인 실시예에서 고유 키 문법들의 이단 파싱을 위한 의사코드를 도시한다.
본 발명의 실시예들은 예를 들어, 컴퓨터 네트워크들 또는 네트워크들, 클라이언트들, 서버들, 처리 디바이스들 및 기타 컴포넌트들의 다른 배열들을 포함하는 정보 처리 시스템들의 형태로 구현될 수 있다. 그러한 시스템들의 예시적인 실시예들이 여기서 상세하게 설명될 것이다. 그러나, 본 발명의 실시예들은 광범위한 기타 유형의 정보 처리 시스템들 및 관련 네트워크들, 클라이언트들, 서버들, 처리 디바이스들 또는 기타 컴포넌트들에 보다 일반적으로 적용 가능하다는 것을 이해해야 한다. 따라서, 용어 "정보 처리 시스템"은 여기서 사용될 때 이러한 그리고 다른 배열들을 포함하도록 광범위하게 해석되도록 의도된다.
도 1은 예시적인 실시예에서 TLS에 대한 분산형 오라클을 구현하는 정보 처리 시스템(100)을 도시한다. 시스템(100)은 네트워크(105)를 통해 통신하도록 구성된 복수의 클라이언트 디바이스들(102-1, 102-2, . . . 102-N)과 검증기 디바이스(104)를 포함한다. 클라이언트 디바이스들(102) 중 소정의 클라이언트 디바이스는 예를 들어, 랩톱 컴퓨터, 태블릿 컴퓨터 또는 데스크톱 개인용 컴퓨터, 모바일 전화 또는 또 다른 유형의 컴퓨터 또는 처리 디바이스, 뿐만 아니라 이러한 다수의 디바이스들의 조합들을 포함할 수 있다. 검증자 디바이스(104)는 유사하게 적어도 하나의 프로세서 및 적어도 하나의 프로세서에 결합된 적어도 하나의 메모리를 각각 포함하는 다양한 유형들의 처리 디바이스들을 포함할 수 있다.
네트워크(105)는 실례로 예를 들어, 글로벌 컴퓨터 네트워크, 이를테면 인터넷, 광역 네트워크(WAN), 근거리 네트워크(LAN), 위성 네트워크, 전화 또는 케이블 네트워크, 셀룰러 네트워크, 이를테면 3G, 4G 또는 5G 네트워크, 무선 프로토콜을 사용하여 구현되는 무선 네트워크, 이를테면 블루투스, WiFi 또는 WiMAX, 또는 이러한 그리고 다른 유형들의 통신 네트워크들의 다양한 부분들 또는 조합들을 포함할 수 있다.
시스템(100)은 각 보호 데이터 소스들(108)과 연관된 복수의 TLS 서버들(106)을 더 포함한다. TLS 서버들(106)은 예시적으로 자신들의 각 보호 데이터 소스들(108)에 대한 액세스를 제어하도록 구성된다. 보호 데이터 소스들(108)의 적어도 서브세트는 예시적으로 각 HTTPS 가능 웹사이트들을 포함하며, 여기서 HTTPS는 하이퍼텍스트 송신 프로토콜(HTTP)의 확장인 하이퍼텍스트 송신 프로토콜 보안을 나타낸다. 다양한 추가적인 또는 대안적인 데이터 소스들이 다른 실시예들에서 사용될 수 있는 것으로 이해될 것이다. 시스템(100)의 보호 데이터 소스들(108)은 TLS 서버들(106) 중 적어도 하나를 통해 HTTPS를 통해 안전하게 액세스될 수 있다는 점에서 보호된다. 다른 데이터 소스들은 이러한 특정 방식으로 액세스 가능할 필요는 없고/없거나, 추가적인 또는 대안적인 액세스 제어 메커니즘들을 구현할 수 있고/있거나, 다른 유형들의 보안 프로토콜들을 사용하여 공개적으로 액세스 가능할 수 있다.
또한, 본원에서의 예시적인 실시예들은 TLS 서버들(106)과 같은 특정 유형들의 하나 이상의 서버를 이용하지만, 다른 유형들의 보안 프로토콜들이 다른 실시예들에서 사용될 수 있고, 다른 유형의 서버 디바이스들에서 구현될 수 있는 것으로 이해되어야 한다. 이에 따라, "서버 디바이스"라는 용어는 본원에서 사용될 때 광범위하게 해석되도록 의도되고, 어떠한 방식으로든 TLS 서버들로 제한되는 것으로 간주되어서는 안 된다.
클라이언트 디바이스들(102)은 일부 실시예들에서 검증자 디바이스(104) 또는 시스템(100)의 다른 영지식 증명(zero knowledge proof, ZKP) 오라클 노드들(110)에 대한 각 증명자 디바이스들로서 동작한다. 이에 따라, 검증자 디바이스(104)는 시스템(100)의 ZKP 오라클 노드로서 간주될 수 있다. 따라서, 소정의 "검증자 디바이스"는 그 용어가 본원에서 광범위하게 사용될 때 예를 들어, 시스템(100)과 같은 분산형 오라클 시스템의 오라클 노드들의 세트 중 특정 오라클 노드를 포함할 수 있다.
시스템(100) 내의 특정 수들, 유형들 및 배열들의 디바이스들 및 다른 컴포넌트들은 단지 예시적인 예로서 제시되고, 다른 실시예들에서 달라질 수 있다. 예를 들어, 본 실시예에서 단일의 검증자 디바이스(104)만이 도시되지만, 다른 실시예들은 다른 ZKP 오라클 노드들(110)이 각 검증자 디바이스들로서 동작하는 배열에서와 같이, 다수의 검증자 디바이스들을 포함할 수 있다. 또한, TLS 서버들(106) 중 하나 이상은 각각 보호 데이터 소스들(108) 중 다수의 데이터 소스들에 대한 액세스를 제어하도록 구성될 수 있다. 다른 많은 분산형 오라클 배열들도 가능하다.
검증자 디바이스(104)는 3자간 핸드셰이크 모듈(112), 포스트-핸드셰이크 상호작용 모듈(114), 및 증명 검증 모듈(116)을 포함한다. 이러한 모듈들은 아래에서 더 상세히 설명될 바와 같이, 분산형 오라클 프로토콜 - 본원에서 DECO 프로토콜로서도 지칭됨 - 의 별개의 각 프로토콜들을 구현한다.
검증자 디바이스(104)는 본 실시예에서 프로세서(120), 메모리(122) 및 네트워크 인터페이스(124)를 더 포함한다. 프로세서(120)는 도면에 도시된 간략화된 예시적인 상호연결들을 통해 메모리(122) 및 네트워크 인터페이스(124)에 동작가능하게 결합되는 것으로 가정된다.
프로세서(120)는 예를 들어, 마이크로 프로세서, 주문형 반도체(ASIC), 필드 프로그래머블 게이트 어레이(FPGA), 중앙 처리 장치(CPU), 그래픽 처리 장치(GPU), 산술 논리 장치(ALU), 디지털 신호 프로세서(DSP) 또는 다른 유사한 처리 디바이스 컴포넌트, 뿐만 아니라 다른 유형들 및 배열들의 처리 회로부를, 임의의 조합으로 포함할 수 있다. 본원에 개시된 바와 같은 소정의 처리 디바이스에 의해 제공되는 분산형 오라클의 기능의 적어도 일부분은 이러한 회로부를 사용하여 구현될 수 있다.
메모리(122)는 처리 디바이스의 기능의 부분들을 구현 시 프로세서(120)에 의한 실행을 위한 소프트웨어 프로그램 코드를 저장한다. 예를 들어, 모듈들(112, 114 및 116)의 기능의 적어도 부분들은 메모리(122)에 저장된 프로그램 코드를 사용하여 구현될 수 있다.
대응하는 프로세서에 의한 실행을 위한 상기한 프로그램 코드를 저장하는 소정의 상기한 메모리는 본원에서 프로그램 코드가 내장된 프로세서 판독 가능 저장 매체로서 보다 일반적으로 지칭되는 것의 일례이고, 예를 들어, 전자 메모리, 이를테면 SRAM, DRAM 또는 다른 유형들의 랜덤 액세스 메모리, 판독 전용 메모리(ROM), 플래시 메모리, 자기 메모리, 광학 메모리 또는 다른 유형들의 저장 디바이스들을 임의의 조합으로 포함할 수 있다.
이러한 프로세서 판독 가능 저장 매체를 포함하는 제조품들이 본 발명의 실시예들인 것으로 고려된다. 용어 "제조품"은 본원에서 사용될 때 일시적인 전파 신호들을 배제하는 것으로 이해되어야 한다.
프로세서 판독 가능 저장 매체를 포함하는 다른 유형들의 컴퓨터 프로그램 제품들이 다른 실시예들에서 구현될 수 있다.
또한, 본 발명의 실시예들은 클라이언트 디바이스들(102), 검증자 디바이스(104), TLS 서버들(106) 및 다른 ZKP 오라클 노드들(110) 중 하나 이상과 연관된 처리 동작들을 구현하도록 구성된 처리 회로부를 포함하는 집적 회로들의 형태로 구현될 수 있다.
네트워크 인터페이스(124)는 검증자 디바이스(104)가 네트워크(105)를 통해 다른 시스템 요소들과 통신할 수 있게 하도록 구성되고, 하나 이상의 종래의 송수신기를 포함할 수 있다.
동작 시, 검증자 디바이스(104)는 예시적인 실시예들에서 클라이언트 디바이스(102-1)와 같은 클라이언트 디바이스들(102) 중 소정의 클라이언트 디바이스, 및 TLS 서버들(106) 중 소정의 서버와의 3자간 핸드셰이크 프로토콜에 참여하도록 구성된다. 이러한 참여는 예시적으로 검증 디바이스(104)의 3자간 핸드셰이크 모듈(112)에 의해 제어된다. 3자간 핸드셰이크 프로토콜의 실행과 관련하여, 검증자 디바이스(104) 및 클라이언트 디바이스(102-1)는 소정의 TLS 서버와의 보안 세션의 세션 키의 각 공유분들을 획득한다. 보안 세션은 예시적으로 TLS 세션을 포함한다.
검증자 디바이스(104)는 클라이언트 디바이스(102-1)로부터 소정의 TLS 서버와의 보안 세션에 관한 커미트먼트를 수신한다. 커미트먼트의 수신에 응답하여, 검증자 디바이스(104)는 클라이언트 디바이스(102-1)가 이전에 액세스 가능하지 않았던 보안 세션에 관한 추가적인 정보를 클라이언트 디바이스(102-1)에 배포한다. 커미트먼트에 관한 이러한 동작들은 예시적으로 포스트-핸드셰이크 상호작용 모듈(114)의 제어 하에서 수행된다.
검증자 디바이스(104)는 커미트먼트 및 추가적인 정보에 적어도 부분적으로 기초하여, 보안 세션의 일부로서 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증한다. 이러한 검증은 예시적으로 검증 모듈(116)의 제어 하에서 수행된다.
일부 실시예들에서, 검증자 디바이스(104)는 또한, 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성의 검증에 응답하여 하나 이상의 자동화된 동작을 개시하도록 구성된다. 예를 들어, 검증자 디바이스(104)는 검증 정보 또는 다른 관련 정보를 클라이언트 디바이스(102-1)에 반환할 수 있다.
예로서, 보안 세션에 관한 커미트먼트는 보안 세션의 일부로서 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 응답 데이터를 질의하기 위한 커미트먼트를 포함할 수 있다.
또 다른 예로서, 보안 세션에 관한 커미트먼트는 검증자 디바이스(104)가 이전에 액세스 가능하지 않았지만 3자간 핸드셰이크 프로토콜과 관련하여 클라이언트 디바이스(102-1)에 의해 설정된 증명자 키에 대한 커미트먼트를 포함할 수 있다. 다른 유형들의 커미트먼트가 다른 실시예들에서 사용될 수 있다.
커미트먼트의 수신에 응답하여 클라이언트 디바이스(102-1)에 배포된 추가적인 정보는 일부 실시예들에서 클라이언트 디바이스(102-1)가 이전에 액세스 가능하지 않았지만 3자간 핸드셰이크 프로토콜과 관련하여 검증자 디바이스(104)에 의해 설정된 검증자 키를 포함한다.
다른 실시예들에서, 검증자 디바이스(104)는 또한, 클라이언트 디바이스(102-1)와 소정의 TLS 서버 사이의 상호작용들과 관련하여 클라이언트 디바이스(102-1)에 대한 프록시로서 동작하여, 프록시로서 동작하는 검증자 디바이스(104)를 통해 보안 세션의 일부로서 클라이언트 디바이스(102-1) 및 소정의 TLS 서버 사이에서 교환되는 암호문들을 검증자 디바이스(104)가 자동으로 획득하도록 구성된다. 이러한 실시예는 본원에서 "프록시 모드" 배열로서 지칭된다.
검증자 디바이스(104)는 일부 실시예들에서 또한, 보안 세션의 일부로서 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 데이터를 특징짓는 하나 이상의 명제를 클라이언트 디바이스로(102-1)부터 수신하도록 구성된다.
예를 들어, 하나 이상의 명제 중 소정의 명제는 예시적으로 보안 세션의 일부로서 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 질의 응답 데이터의 선택적으로 드러나는 서브스트링을 포함한다.
또 다른 예로서, 하나 이상의 명제 중 소정의 명제는 예시적으로 보안 세션의 일부로서 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 질의 응답 데이터가 클라이언트 디바이스(102-1)에 의해 검증자 디바이스(104)에 발신될 소정의 명제의 생성과 관련하여 클라이언트 디바이스(102-1)에 의해 후속하여 파싱될 감소된 데이터를 생성하기 위해 클라이언트 디바이스(102-1)에 의해 전처리되는 다단 파싱 프로토콜의 이용을 통해 컨텍스트 무결성을 제공하도록 구성된다.
보안 세션의 일부로서 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 데이터를 특징짓는 매우 다양한 다른 유형들의 명제들이 다른 실시예들에서 사용될 수 있다.
일부 실시예들에서, 3자간 핸드셰이크 프로토콜과 관련하여, 클라이언트 디바이스(102-1) 및 검증자 디바이스(104)는 소정의 TLS 서버와 하나 이상의 공유 세션 키를 공동으로 설정하며, 클라이언트 디바이스(102-1)는 하나 이상의 공유 세션 키 중 소정의 공유 세션 키의 제1 공유분을 갖고, 검증자 디바이스(104)는 소정의 공유 세션 키의 제2 공유분을 가지며, 소정의 TLS 서버는 제1 공유분과 제2 공유분을 조합한 복합 세션 키를 갖는다.
추가적으로 또는 대안적으로, 3자간 핸드셰이크 프로토콜과 관련하여, 클라이언트 디바이스(102-1)는 검증자 디바이스(104)에 액세스 가능하지 않은 암호화 키를 소정의 TLS 서버로부터 수신한다.
일부 실시예들에서, 검증자 디바이스(104) 및 클라이언트 디바이스(102-1)는 소정의 TLS 서버와의 보안 세션의 세션 키의 자신들의 각 공유분들을 사용하여, 소정의 TLS 서버가 데이터를 클라이언트 디바이스(102-1)에 발신할 것을 요청하기 위해 클라이언트 디바이스(102-1)에 의해 소정의 TLS 서버에 제공되는 질의를 생성하도록 협력한다.
검증자 디바이스(104) 및 클라이언트 디바이스(102-1)는 유사하게 소정의 TLS 서버와의 보안 세션의 세션 키의 자신들의 각 공유분들을 사용하여, 질의에 응답하여 소정의 TLS 서버에 의해 클라이언트 디바이스(102-1)에 제공되는 응답을 검증하도록 협력할 수 있다.
일부 실시예들에서, 3자간 핸드셰이크 프로토콜과 관련하여, 클라이언트 디바이스(102-1) 및 검증자 디바이스(104)는 각 증명자 및 검증자 키들을 설정한다. 이러한 실시예에서, 보안 세션의 일부로서 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하는 것은 예시적으로 클라이언트 디바이스(102-1)에 의해 검증자 디바이스(104)에 제공되는 증명을 검증하는 것을 포힘한다. 증명은 예시적으로 (i) 3자간 핸드셰이크 프로토콜과 관련하여 클라이언트 디바이스(102-1)에 의해 설정된 증명자 키, (ii) 3자간 핸드세이크 프로토콜과 관련하여 검증 디바이스에 의해 설정된 검증자 키, 및 (iii) 클라이언트 디바이스(102-1)의 개인 정보, 이를테면 패스워크 또는 패스코드에 적어도 부분적으로 기초하여 클라이언트 디바이스(102-1)에 의해 생성된다.
일부 실시예에서, 보안 세션의 일부로서 소정의 TLS 서버로부터 클라이언트 디바이스(102-1)에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하는 것은 예시적으로 보안 세션의 적어도 하나의 암호문의 적어도 일부분으로부터 도출되는 데이터를 획득하는 것, 및 클라이언트 디바이스(102-1)에 의해 해당 데이터의 적어도 하나의 특성의 정확성을 검증하는 것을 포함한다. "암호문"이라는 용어는 이러한 컨텍스트 및 본원에서의 다른 곳에서 사용될 때 광범위하게 해석되도록 의도되고, 임의의 특정 암호 프로토콜의 사용을 요구하는 것으로 간주되어서는 안 된다.
도 1에 도시된 컴포넌트들 및 다른 시스템 요소들의 특정 배열 및 상술된 바와 같은 이들의 연관된 처리 동작들은 단지 예시적인 예로서 제시되고, 다수의 대안적인 실시예들이 가능한 것으로 이해되어야 한다.
예를 들어, 시스템(100) 내의 검증자 디바이스(104)가 예시적으로 메모리에 결합된 프로세서를 포함하는 단일 처리 디바이스로서 도시되지만, 검증자 디바이스는 다른 실시예들에서 검증자 디바이스(104)의 기능이 다수의 별개의 처리 디바이스들에 걸쳐 분배되는 분산형 검증자 디바이스를 포함할 수 있다. 이러한 실시예들에서, 본원에 개시된 다양한 프로토콜들에서의 검증자의 역할은 다수 당사자 프로토콜을 실행하는 다수의 별개의 당사자들 - 각 이러한 당사자는 분산형 검증자 디바이스의 다수의 처리 디바이스들 중 상이한 처리 디바이스와 연관됨 - 에 걸쳐 분산될 수 있다. 이에 따라, "디바이스"라는 용어는 본원에서 사용될 때 메모리에 결합된 프로세서를 포함하는 적어도 하나의 처리 디바이스, 및 이에 따라 분산형 검증자 디바이스의 경우에서와 같이 다수의 이러한 처리 디바이스들을 망라하도록 광범위하게 해석되도록 의도된다.
도 2는 예시적으로 TLS 서버들(106) 중 하나에 의해 제어되는 데이터에 대한 증명자로서 클라이언트 디바이스들(102) 중 하나와 상호작용하는 검증자 디바이스(104)에 의해 적어도 부분적으로 구현되는 예시적인 프로세스를 도시한다. 이러한 특정 프로세스는 단지 예일 뿐이고, 추가적인 또는 대안적인 프로세스들이 다른 실시예들에서 적어도 부분적으로 증명자, 검증자 및 서버 엔티티들에 의해 수행될 수 있는 것으로 이해되어야 한다.
본 실시예에서, 프로세스는 예시적으로 단계들(200 내지 208)을 포함한다. 상술한 바와 같이, 이러한 단계들의 적어도 일부분은 적어도 부분적으로 검증자 디바이스(104)가 클라이언트 디바이스들(102) 중 하나와 상호작용하고 또한 TLS 서버들(106) 중 하나를 수반함으로써 수행되는 것으로 가정된다. 이러한 컴포넌트들은 또한 도 2 프로세스의 컨텍스트에서 각각 검증자, 증명자 및 서버로서 지칭된다.
단계(200)에서, 검증자는 클라이언트 - 클라이언트가 증명자로서의 역할을 함 - 및 서버와의 3자간 핸드셰이크 프로토콜에 참가한다.
단계(202)에서, 3자간 핸드셰이크 프로토콜과 관련하여, 검증자 및 증명자는 서버와의 보안 세션의 세션 키의 각 공유분들을 획득한다.
단계(204)에서, 검증자는 서버와의 보안 세션에 관한 커미트먼트를 증명자로부터 수신한다.
단계(206)에서, 커미트먼트의 수신에 응답하여, 검증자는 증명자가 이전에 액세스 가능하지 않았던 보안 세션에 관한 추가적인 정보를 증명자에 배포한다.
단계(208)에서, 검증자는 커미트먼트 및 추가적인 정보에 적어도 부분적으로 기초하여, 보안 세션의 일부로서 서버로부터 증명자에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증한다.
많은 다른 기술들이 본원에 개시된 바와 같은 분산형 오라클의 구현과 관련하여 사용될 수 있다.
이에 따라, 도 2의 흐름도와 관련하여 설명된 특정 처리 동작들 및 다른 기능은 단지 예시적인 예로서 제시되고, 어떠한 방식으로도 본 발명의 범위를 제한하는 것으로 해석되지 않아야 한다. 대안적인 실시예들은 검증자 디바이스들, 증명자 디바이스들 및 서버 디바이스들을 수반하는 다른 유형들의 처리 동작들을 사용할 수 있다. 예를 들어, 프로세스 단계들의 순서가 다른 실시예들에서 변경될 수 있거나, 또는 특정 단계들이 직렬이 아니라 서로 동시에 수행될 수 있다. 또한, 프로세스의 다수의 인스턴스들은 각 증명자, 검증자 및 서버 디바이스들의 상이한 세트들에 대해 시스템(100) 내에서 서로 병렬로 수행될 수 있다. 이에 따라, 시스템(100)은 본원에 개시된 기술들을 사용하여 다수의 분산형 오라클을 동시에 구현할 수 있다.
이제 예시적인 실시예들의 추가적인 양태들이 도 3 내지 도 14를 참조하여 설명될 것이다.
TLS의 광범위한 전개는 사용자들이 종단간 기밀성 및 무결성을 갖는 채널들을 통해 개인 데이터에 액세스할 수 있게 한다. 그러나, 종래의 관행 하에서 사용자들이 용이하게 할 수 없는 것은 이러한 데이터의 출처, 즉, 이것이 특정 웹사이트로부터 진정으로 비롯된 것이라는 것을 제3자에게 증명하는 것이다. 기존의 접근법들은 바람직하지 않은 신뢰 가정을 도입하거나 서버측 수정을 요구한다.
그 결과, 사용자들의 개인 데이터는 그 기점에 고정된다. 사용자들은 현재의 데이터 보유자로부터의 도움 및 허가 없이 그들의 데이터를 무결성 보호 방식으로 다른 애플리케이션들로 내보낼 수 없다.
본원에서의 예시적인 실시예는 이러한 그리고 다른 문제들을 해결하기 위해 DECO(분산형 오라클에 대한 약어)로서 지칭되는 기법들을 제공한다. DECO는 사용자가 데이터 자체를 비밀로 유지하면서, TLS를 통해 액세스된 데이터 조각이 특정 웹사이트로부터 온 것임을 증명하고, 선택적으로 영지식으로 이러한 데이터에 대한 명제들을 증명할 수 있게 한다. 바람직하게는, DECO는 예시적인 실시예들에서 신뢰 하드웨어 또는 서버측 수정 필요 없이 구현될 수 있다.
DECO는 데이터를 중앙 집중형 웹 서비스 사일로들로부터 해제시켜, 다양한 애플리케이션들이 액세스 가능하게 만들 수 있다. DECO의 능력을 실증하기 위해, 스마트 계약을 사용하는 개인 금융 상품, 레거시 자격 증명을 익명 자격 증명으로 변환하는 수단, 및 가격 차별에 대해 검증 가능한 주장 없이 달성하기 어려운 세 가지 적용예들을 구현한다.
본원에서 DECO에 대한 이렇나 그리고 다른 언급들은 예시적인 실시예들을 지칭하고, 이러한 실시예들의 특정 특징들, 기능, 이점들 및 다른 세부사항들은 임의의 방식으로 제한하는 것으로서 해석되지 않아야 하는 것으로 이해되어야 한다. 대안적인 실시예들은 TLS 및 다른 컨텍스트들에서 데이터 소스들을 검증하기 위한 추가적인 또는 대안적인 기법들을 구현할 수 있다.
상술한 바와 같이, TLS는 사용자들이 기밀의 무결성 보호 채널들을 통해 웹 데이터에 액세스할 수 있게 하는 강력하고 널리 전개된 프로토콜이다. 그러나, TLS는 심각한 제한을 갖는다: 이는 사용자가 자신이 진정으로 특정 웹사이트로부터 온 것으로 액세스한 데이터 조각을 제3자에게 증명할 수 있게 하지 않는다. 그 결과, 데이터 사용이 종종, GDPR과 같은 최근의 규제에 의해 인정되는 권리인, 사용자들에 의한 데이터 휴대성을 축소시키면서, 그 기점으로 제한된다.
구체적으로, 사용자가 TLS를 통해 데이터에 온라인으로 액세스할 때, 사용자는 현재의 데이터 보유자로부터의 도움(이로 인한 허가) 없이 데이터를 안전하게 내보낼 수 없다. 이에 따라, 많은 양의 개인 데이터가 의도적으로 또는 비의도적으로 "딥 웹" - 공개적으로 액세스 가능하지 않은 웹의 부분 - 에 고정된다.
이 문제를 더 잘 이해하기 위해, Alice가 Bob에게 자신이 18세 이상임을 증명하기를 원하는 일례를 고려한다. 현재, 연령 검증 서비스들은 통상적으로 사용자들이 ID들 및 상세한 개인 정보를 업로드할 것을 요구하며, 이는 프라이버시 우려를 일으킨다. 그러나, 회사 급여 레코드들 또는 DMV 웹사이트들과 같은 다양한 웹사이트들은 원칙적으로 검증된 생일을 저장하고 제공한다. Alice는 이러한 사이트로부터의 자신의 생일의 스크린샷을 발신할 수 있지만, 이는 쉽게 위조된다. 그리고 스크린샷이 어떻게든 진정한 것으로 증명될 수 있다 하더라도, 이는 정보를 누설할 것이다 - 그녀가 단지 18세 이상임이 아니라, 그녀의 정확한 생일을 드러낼 것이다.
스마트 계약들, 오라클에 대한 온라인 데이터의 출처를 증명하기 위해 초기에 제안된 것은 출처 및 무결성이 보증된 다른 시스템들에 TLS 보호 데이터를 내보내기 위한 단계이다. 그러나, 기존의 방식들은 심각한 기술적 한계들을 갖는다. 이것들은 단지 중요도가 떨어져 더 이상 사용되지 않고 앞으로는 사라지게 될(deprecated) TLS 버전들로만 동작하고, 오라클(예를 들어, TLSNotary)로부터의 프라이버시를 제공하지 않거나, 또는 다양한 공격들이 최근에 출현한 신뢰 하드웨어(예를 들어, Town Crier)에 의존한다. 또 다른 부류의 오라클 방식들은 서버측 협력을 가정하여, 서버들이 TLS 확장을 설치하거나 애플리케이션 계층 로직을 변경할 것을 요구한다. 서버 촉진 오라클 방식들은 두 가지 근본적인 문제들을 겪는다. 첫째, 이것들은 레거시 호환성을 파괴하여, 광범위한 채택에 상당한 장벽을 야기한다. 더욱이, 이러한 솔루션들은 웹 서버들이 어느 데이터가 내보내질 수 있는지를 결정하기 위한 단독 재량권을 갖고 있고 원하는대로 내보내기 시도들을 검열할 수 있기 때문에, 조건부 내보내기 가능성만을 제공한다. 사용자들이 액세스 권한을 갖는 임의의 데이터를 내보낼 수 있게 하는 메커니즘은 현재 실현 불가능한 애플리케이션들의 전체 호스트를 활성화할 것이다.
상기한 문제들을 해결하기 위해, 본원에 개시된 예시적인 실시예들은 TLS에 대한 분산형 오라클인 DECO로서 지칭되는 배열을 제공한다. 웹사이트별 지원을 요구하는 오라클 방식들과 달리, DECO는 예시적으로 소스-애그노스틱(source-agnostic)이고 표준 TLS를 실행하는 임의의 웹사이트를 지원한다. 웹사이트들의 참여에 의존하는 솔루션들과 달리, DECO는 서버측 협력은 필요로 하지 않는다. 이에 따라, DECO의 단일 인스턴스는 누군가가 임의의 웹사이트에 대한 오라클이 될 수 있게 할 수 있다.
DECO는 스마트 계약들과 같이 인터넷에 액세스할 수 없는 것들을 포함하는 광범위한 애플리케이션들에 대한 진위 및 프라이버시를 보장하며 풍부한 인터넷 데이터를 액세스 가능하게 만든다. DECO는 개인 데이터 전달을 제3자에게 전달하거나 공개 배포를 위한 옵션으로 제공함으로써 오늘날의 웹 데이터 보급 모델을 근본적으로 바꿀 수 있다. 이러한 기술적 능력은 잠재적인 미래의 법적 및 규제 문제들을 강조하지만, 또한 매력적인 새로운 서비스들의 생성 및 전달을 예상한다. 중요하게는, DECO는 일부 대안적인 접근법들과 달리, 신뢰 하드웨어를 필요로 하지 않는다.
일부 실시예들에서, 상위 레벨에서, 증명자는 데이터 조각(D)을 커밋하고, TLS 서버(S)로부터 온 D 및 선택적으로 D에 대한 명제(πD)를 검증한다. 연령을 증명하는 예를 다시 참조하면, 명제(πD)는 "D = y/m/d는 Alice의 생일이고 현재 날짜이다 - D는 적어도 18세이다"라는 술어일 수 있다.
형식에 구애되지 않고, DECO는 진위를 달성한다 - 검증자는 D에 대한 주장된 명제가 참이고, D가 실제로 TLS 서버(S)로부터 획득되는 경우에만 확신한다. 또한, DECO는 검증자가 S로부터 얻어지는 일부 D에 대해 명제(πD)가 유효하다는 것만 학습한다는 점에서 프라이버시를 제공한다.
DECO를 레거시 TLS 호환 프리미티브들을 사용하면서, 요구되는 보안 및 실용적인 성능을 갖게 설계하는 것은 몇 가지 중요한 기술적 문제들을 야기한다. 하나의 문제는 TLS가 클라이언트(예를 들어, DECO에서의 증명자)와 웹 서버에 의해 공유되는 대칭 암호화 및 인증 키들을 생성한다는 사실로부터 기인한다. 이에 따라, 클라이언트는 유효한 인증 키들을 데이터에 서명한다는 의미에서, 임의의 TLS 세션 데이터를 위조할 수 있다.
이러한 문제를 해결하기 위해, DECO는 증명자, 검증자, 및 웹 서버 사이에 새로운 3자간 핸드셰이크 프로토콜을 도입하여, TLS 세션 데이터 조각(D)에 대해 검증자에게 증명자가 위조 불가능한 커미트먼트를 생성한다. 검증자는 D가 진정으로 TLS 서버로부터 온 것인지를 검사할 수 있다. 증명자의 관점에서, 3자간 핸드셰이크는 악의적인 검증자의 존재 시 TLS의 보안을 보존한다.
효율적인 선택적 개방. D에 대해 커밋한, 증명자는 커미트먼트에 대한 명제들을 증명한다. 이론적으로 임의의 명제들이 지원될 수 있지만, 본원은 가장 인기 있는 애플리케이션들일 가능성이 있는 것에 대해 최적화한다 - 검증자에 대한 응답의 서브스트링들만을 드러낸다. 본원은 이러한 명제들을 선택적 개방이라고 칭한다. 세분화된 선택적 개방은 사용자들이 민감한 정보를 숨길 수 있게 하고, 후속 증명들에 대한 입력 길이를 감소시킨다.
나이브 솔루션은 일반적인 영지식 증명들(ZKPs)을 사용하여 TLS 레코드들의 고가의 검증 가능한 복호화를 수반할 것이지만, 본원에서의 예시적인 실시예들은 TLS 레코드 구조를 활용함으로써 수 십 배의 효율성 개선을 달성한다. 예를 들어, TLS 레코드의 검증 가능한 복호화의 직접 구현은 영지식에서 1024 AES 호출의 회로의 정확한 실행을 제공하는 것을 수반할 것인 반면, CBC-HMAC의 MAC-then-encrypt 구조를 활용함으로써, 본원에서의 예시적인 실시예들은 단지 3 AES 호출로 동일한 것을 실현할 수 있다.
컨텍스트 무결성. 선택적 개방은 증명자가 서버의 응답(D)의 서브스트링(D')만을 드러낼 수 있게 한다. 그러나, 서브스트링은 이것이 언제 나타나는지에 따라 상이한 것들을 의미할 수 있고, 악의적인 증명자는 컨텍스트를 벗어나 이용함으로써 속일 수 있다. 이에 따라, D'가 D에서 나타날 뿐만 아니라, 예상 컨텍스트에서 나타나는 것, 즉 D'이 D에 대해 컨텍스트 무결성을 갖는 것을 증명할 필요가 있다. (이는 프라이버시 이론에서 "컨텍스트 무결성"과 상이하다는 점에 유의한다.)
컨텍스트 무결성 공격들은 세션 컨텐츠가 구조화되고 파싱될 수 있는 경우 저지될 수 있다. 다행히도, 대부분의 웹 데이터는(예를 들어, JSON(JavaScript Object Notation) 또는 HTML(Hypertext Markup Language)에서) 이러한 형태를 취한다. 일반적인 솔루션은 전체 세션을 파싱하고 드러난 부분이 파싱 트리의 필요한 분기에 속한다는 것을 증명하는 것이다. 그러나, 웹 데이터가 일반적으로 만족하는 특정 제약들 하에서, 전체 세션을 파싱하는 것은 필요하지 않다. 본원에 개시된 일부 실시예들은 증명자가 세션 컨텐츠를 전처리하고, 보통 훨씬 더 작은 결과만을 파싱하는 신규한 2단 파싱 방식을 제공한다. 본원은 프로그래밍 언어 이론에서 사용되는 바와 같은 프로그램들의 등가의 정의로부터 도출하여, 2단 파싱 방식들의 보안에 대한 추론을 위한 대한 형식적 프레임워크를 구축한다. 본원에 개시된 예시적인 실시예들은 특정 문법들에 대한 몇 가지 실제적인 실현예들을 제공한다. 본원의 정의들 및 구성은들 다른 오라클에도 일반화된다. 예를 들어, 이는 일반적인 버전의 컨텐츠 은닉 공격을 방지할 수 있다.
예시적인 실시예들의 구현 및 평가와 관련하여, 본원은 완전한 종단간 시스템으로서 DECO를 설계 및 구현하였다. 본 시스템의 능력을 실증하기 위해, 본원은 1) 스마트 계약을 사용하는 기밀성 보존 금융 상품; 2) 레거시 자격 증명을 익명 자격 증명으로 변환하는 수단; 및 3) 가격 차별에 대해 검증 가능한 주장의 세 가지 적용예들을 구현하였다.
이러한 적용예들을 이용한 본원의 실험들은 DECO가 매우 효율적임을 보여준다. 예를 들어, WAN 설정에서 TLS 1.2에 대해, 온라인 시간은 3자간 핸드셰이크를 수행하는 데 2.85s이고, 2PC 질의 실행에 2.52s이다. 상술된 적용예들에 대한 영지식 증명들을 생성하기 위해서는 약 3s 내지 13s가 걸린다. 더 상세한 사항들이 본원의 다른 곳에서 제공된다.
아래에서 상세히 설명될 예시적인 실시예들과 관련하여 개시된 바와 같은 DECO는 바람직하게는 증명 가능하게 안전한 분산형 오라클 방식을 제공한다. DECO는 일부 실시예들에서 신뢰 하드웨어 또는 서버측 수정을 필요로 하지 않는 최신 TLS 버전들에 대한 오라클 방식을 제공한다.
본원은 또한 DECO를 사용하여 영지식에서 효율적으로 증명될 수 있는 TLS 레코드들에 대한 광범위한 부류의 명제들을 아래에서 상세히 설명한다. 이러한 명제들은 사용자들이 세션 데이터 커미트먼트의 서브스트링들만을 개방할 수 있게 한다. 최적화는 일반적인 ZKP들에 비해 상당한 효율 개선을 달성한다.
컨텍스트 무결성 공격들 및 완화와 관련하여, 본원은 프라이버시 보호 오라클에 보편적인 새로운 부류의 컨텍스트 무결성 공격들을 식별하고, 본원은 신규한 효율적인 2단 파싱 방식을 수반하는 본원의 완화 접근법을 설명한다.
전송 계층 보안(TLS)
이제, 본원은 예시적인 실시예들에서 DECO가 구축되는 TLS 핸드셰이크 및 레코드 프로토콜들에 대한 일부 배경을 제공한다.
TLS는 두 개의 통신 애플리케이션들 사이에 프라이버시 및 데이터 무결성을 제공하는 프로토콜 군이다. 개략적으로 말하면, 이는 두 개의 프로토콜들, 즉 비대칭 암호화를 사용하여, 다음 프로토콜에 대한 공유된 클라이언트 및 서버 키들을 설정하여 세션을 셋업하는 핸드셰이크 프로토콜, 데이터가 대칭 암호화를 사용하는 기밀성 및 무결성 보호로 송신되는 레코드 프로토콜로 구성된다.
핸드셰이크. 핸드셰이크 프로토콜에서, 서버 및 클라이언트는 먼저 암호 알고리즘 세트(암호 스위트(cipher suite)로서도 알려짐)에 합의한다. 그 후, 이들은 서로 인증하고(클라이언트 인증 옵션), 최종적으로 후속 레코드 프로토콜에 사용될 공유 비밀을 안전하게 연산한다.
DECO는 예시적인 실시예들에서 일회성 비밀(ECDHE)과의 타원 곡선 디피-헬만(Diffie-Hellman, DH) 키 교환을 이용하지만, 이는 제한이 아닌 예로서이다.
레코드 프로토콜. TLS에서 애플리케이션 계층 데이터(예를 들어, HTTP 메시지들)를 송신하기 위해, 레코드 프로토콜은 먼저 애플리케이션 데이터(D)를 고정된 크기의 평문 레코드들(D = D1, ..., Dn)로 단편화한다. 각 레코드는 일반적으로 다수의 블록들(예를 들어, 128 비트)에 패딩된다. 그 후, 레코드 프로토콜은 선택적으로 데이터를 압축하고, MAC을 적용하며, 결과를 암호화하며, 송신한다. 수신된 데이터는 복호화되고, 검증되고, 압축 해제되고, 재조립된 후, 보다 상위 레벨 프로토콜들로 전달된다. 특정 암호화 동작들은 협상된 암호 스위트에 의존한다. DECO는 두 개의 통상적으로 사용되는 모드들, 즉 CBC-HMAC 및 GCM - CBC-HMAC는 암호 블록 체이닝 - 해시 기반 메시지 인증 코드를 나타내고, GCM은 갈르아/카운터 모드(Galois/Counter Mode)를 나타냄 - 에서 고급 암호화 표준(Advanced Encryption Standard, AES) 암호를 지원한다. TLS의 이러한 그리고 다른 양태들에 관한 추가적인 세부사항들은 예를 들어, T. Dierks 및 E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, 2008에서 찾아볼 수 있으며, 이는 본원에 참조로 원용된다. 다시, 다른 프로토콜들이 다른 실시예들에서 사용될 수 있다.
TLS 1.2와 1.3 간의 차이. 본원에서의 일부 실시예들에서, 본원은 TLS 1.2에 초점을 맞추고, 이후에 본원 기법들을 TLS 1.3으로 어떻게 일반화하는지를 설명한다. 여기서, 본원은 이러한 두 가지 TLS 버전들 간의 주요 차이점들을 간단히 설명한다. TLS 1.3은 레거시 비-AEAD 암호들에 대한 지원을 제거한다. 핸드셰이크 플로우가 또한 재구성되었다. ServerHello 이후의 모든 핸드셰이크 메시지들은 이제 암호화된다. 마지막으로, 상이한 키 유도 함수가 사용된다. 추가적인 세부사항들은 E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, 2018에서 찾아볼 수 있으며, 이는 본원에 참조로 원용된다.
다자간 연산
각각 몇몇 비밀들(
Figure pct00001
)을 보유하는 n 당사자들의 그룹(P1, ..., Pn)을 고려한다. 안전한 다자간 연산(multi-party computation, MPC)은 그들이 f의 출력 이외의 어떠한 정보도 누설하지 않고 - 즉, Pi가
Figure pct00002
에 대해 아무것도 학습하지 않음 - f(si, .... sn)을 공동으로 연산할 수 있게 한다. MPC 프로토콜들에 대한 보안은 일반적으로 t 플레이어들을 손상시키고 최선(honest) 플레이어의 개인 정보를 학습하려고 시도하는 상대 당사자를 고려한다. 2자간 연산(two-party computation, 2PC)은 n = 2 및 t = 1의 특수한 경우를 지칭한다.
2PC 프로토콜들에 대한 두 가지 일반적인 접근법들이 있다. 가블드(garbled) 회로 프로토콜들은 f를 비트 단위 연산들에 가장 적합한 접근법인 부울 회로(boolean circuit)로서 인코딩한다(예를 들어, SHA-256). 다른 프로토콜들은 임계 비밀(threshold secret) 공유를 활용하고 산술 연산들에 가장 적합하다. 본원이 일부 실시예들에서 2PC를 사용하여 연산하는 함수들은 비트 단위 산술 연산들 양자를 포함한다. 이들을 두 컴포넌트들로 분리하고, 비트 단위 연산들에 대해 최적화된 가블드 회로 프로토콜 및 산술 연산들에 대해 비밀 공유 기반 MtA 프로토콜을 사용한다. 예시적인 실시예들에서 사용되는 예시적인 최적화된 가블드 회로 프로토콜에 관한 추가적인 세부사항들은 ACM CCS, 2017의 Xiao Wang, Samuel Ranellucci, 및 Jonathan Katz 저, "Authenticated Garbling and Efficient Maliciously Secure Two-Party Computation"에서 찾아볼 수 있으며, 이는 본원에 참조로 원용된다. 예시적인 실시예들에서 사용되는 예시적인 비밀 공유 기반 MtA 프로토콜에 관한 추가적인 세부사항들은 ACM CCS, 2018의 Rosario Gennaro 및 Steven Goldfeder 저, "Fast multiparty threshold ECDSA with fast trustless setup"에서 찾아볼 수 있으며, 이는 본원에 참조로 원용된다. 이들은 단지 예들이고, 다른 유형들의 프로토콜들이 다른 실시예들에서 사용될 수 있다.
이제, 본원은 DECO의 예시적인 실시예들에 의해 해결되고 이의 아키텍처의 상위 레벨 개요를 제시하는 문제를 진술한다.
문제 진술: 분산형 오라클
본원에서의 예시적인 실시예들은 "오라클", 즉, 온라인 데이터의 출처 및 속성을 증명할 수 있는 엔티티들을 구축하는 프로토콜을 제공한다. 그 목적은 증명자(P)가 데이터 자체를 비밀로 유지하면서, 데이터 조각이 특정 웹사이트(S)로부터 온 것임을 검증자(V)에 증명하고, 선택적으로 영지식으로 이러한 데이터에 대한 명제들을 증명할 수 있게 하는 것이다. 데이터에 액세스하려면 P로부터의 개인 입력(예를 들어, 패스워드)이 필요할 수 있고, 이러한 개인 정보는 V에게도 비밀로 유지되어야 한다.
본원은 예시적인 실시예에서 인터넷 상의 널리 전개된 보안 프로토콜 스위트인 TLS를 실행하는 서버들에 초점을 맞춘다. 그러나, TLS 단독으로는 데이터 출처를 증명하지 못한다. TLS가 인증을 위해 공개 키 서명을 사용하지만, 이는 각 세션의 시작 시 설정된 공유 세션 키를 사용하여, 교환 메시지의 무결성 및 기밀성을 보호하기 위해 대칭 키 프리미티브들을 사용한다. 이로 인해, 이러한 대칭 키를 알고 있는 P는 제3자에게 암호학적으로 인증된 TLS 데이터에 대한 명제들을 증명할 수 없다.
웹 서버 자체는 예를 들어, 데이터에 간단히 서명함으로써, 오라클의 역할을 가정할 수 있다. 그러나, 서버 촉진 오라클은 높은 채택 비용을 초래할 뿐만 아니라, 또한 사용자들을 불리하게 만든다: 웹 서버가 오라클 능력에 대해 임의의 제약들을 부과할 수 있다. 본원은 데이터를 제공하는 웹 서버와 같은 단일의 중앙 제어점에 의존할 필요 없이, 누구라도 자신이 액세스할 수 있는 임의의 데이터의 증명을 증명할 수 있는 방식에 관심이 있다.
본원은 예시적인 실시예들에서 본원에서 신뢰 하드웨어 또는 웹 서버들로부터의 협력에 의존하지 않는 "분산형 오라클"로서 지칭하는 것을 도입함으로써 이러한 그리고 다른 문제들을 해결한다. 그 문제는 이전의 오라클보다 훨씬 더 문제가 되는데, 이는 데이터에 대한 임의의 술어들에 대한 증명들을 지원함으로써 이러한 이전의 접근법들을 넘어서는 동시에, 서버들에 그들의 코드를 수정하거나 새로운 소프트웨어를 전개하거나 예측 시장의 사용을 요구하는 솔루션들을 배제하기 때문이다.
스마트 계약들에 대한 인증된 데이터 피드들. 본원에 개시된 예시적인 실시예들의 중요한 적용은 인증된 데이터 피드(authenticated data feed, ADF)들, 즉, 스마트 계약들에 대해, 검증 가능한 출처 및 정확성을 갖는 데이터를 구성하는 것이다. 매우 다양한 다른 적용예들이 바람직하게는 본원에 개시된 기법들에 의해 지원된다.
ADF들의 컨텍스트에서, 스마트 계약들은 2PC 프로토콜들에 참여할 수 없기 때문에, 이들은 자신들을 대신하여 참여하기 위해 오라클 노드들에 의존해야 한다. 이에 따라, 일부 실시예들에서, 본원은 독립적으로 동작되는 오라클의 세트가 스마트 계약들에 이용 가능한 분산형 오라클 네트워크에서의 DECO를 전개한다. DECO를 실행하는 오라클은 프라이버시가 아니라 무결성을 위해서만 신뢰된다는 점에 유의한다. 스마트 계약들은 또한, 다수의 오라클을 질의하고 예를 들어, 과반수 합의를 요구함으로써 무결성 실패에 대비할 수 있다. 본원은 모든 오라클이 손상되더라도 DECO의 프라이버시가 보존된다는 것을 강조한다. 이에 따라, DECO는 사용자들이 오라클로부터 개인 데이터를 은닉하면서 개인 데이터로부터 도출된 ADF들을 스마트 계약들에 제공할 수 있게 한다.
표기법 및 정의들
일부 실시예들에서, 본원은 증명자를 나타내기 위해 P, 검증자를 나타내기 위해 V, 그리고 TLS 서버를 나타내기 위해 S를 사용한다. 본원은 벡터들을 나타내기 위해 볼드체의 문자들(예를 들어, M)을 사용하고, M에서의 제i 요소를 나타내기 위해 Mi를 사용한다.
본원은 도 3에 나타낸 바와 같은 이상적인 기능(F오라클)을 사용하여 오라클의 필수적인 속성들을 모델링한다. F오라클의 병렬 실행들을 분리하기 위해, 모든 메시지들에 sid로 나타내어지는 고유 세션 id가 태그된다. 추가적인 또는 대안적인 오라클 속성들이 다른 실시예들에서 사용될 수 있다.
도 3에 도시된 바와 같이, F오라클은 본 실시예에서 P로부터 비밀 파라미터(θs)(예를 들어, 패스워드), 질의 템플릿(Query) 및 V로부터 명제(Stmt)를 수용한다. 질의 템플릿은 P'의 비밀(θs)을 취하고 완전한 질의를 리턴하는 함수이며, 이는 V에 의해 특정된 공개 파라미터들을 포함한다. 예시적인 질의 템플릿은 Query(θs) = "API 키를 갖는 2020년 1월 1일의 GOOG의 주가 = θs”일 것이다. 증명자(P)는 이후에 서버로 발신될 질의가 비밀을 드러내지 않고, 잘 형성된다는 것, 즉 템플릿으로부터 구축된다는 것을 증명할 수 있다. 명제(Stmt)는 V가 서버의 응답에 대해 평가하기를 원하는 함수이다. 이전의 예에 따르면, 응답(R)은 숫자이므로, 다음 명제는 이를 임계치와 비교할 것이다: Stmt(R) = "R > $1,000".
P가 질의 템플릿 및 명제를 확인 응답한 후("ok" 및 θs를 발송함으로써), F오라클은 템플릿으로부터 구축된 질의를 사용하여 S로부터 응답(R)을 검색한다. 본원은 최선 서버를 가정하며, 이에 따라 R은 진실이 된다. F오라클은 Stm(R) 및 데이터 소스를 V에 발신한다.
본원은 어떠한 서버측 수정 또는 협력을 필요로 하지 않는, 즉, S가 수정되지 않은 TLS 프로토콜을 따르는 분산형 오라클에 관심이 있다. 보다 구체적으로, TLS에 대한 분산형 오라클 프로토콜은 가능하게는 애플리케이션 계층 프로토콜과 함께, 1) Prot이 F오라클을 실현하고 2) Prots가 표준 TLS이도록 하는 3자간 프로토콜(Prot = Prots, ProtP, ProtV)이다.
적대적 모델 및 보안 속성들. 예시적인 실시예들에서, 본원은 악의적인 정적 네트워크 적대자 A를 고려한다. 변질된 당사자들은 프로토콜로부터 임의로 벗어날 수 있고, 자신들의 상태들을 A에 드러낸다. 네트워크 적대자로서, A는 TLS가 길이를 은닉하는 것이 아니기 때문에 F오라클로부터 메시지 길이를 학습한다. 본원은 P 및 V가 S에 의해 실행되는 애플리케이션 계층 프로토콜에 따라 적절한 질의(예를 들어, 이는 대부분의 애플리케이션들에 대해 멱등적(idempotent)이어야 함) 및 명제를 선택하고 합의한다는 것을 가정한다.
소정의 질의(Q)에 대해, 서버의 최선 응답을 S(Q)로 나타낸다. 본원은 P 또는 V 중 어느 하나가 변질될 때 보안이 유지될 것을 요구한다. 기능(F오라클)은 다음의 보안 보장 사항들을 반영한다:
ㆍ증명자 무결성: 악의적인 P는 컨텐츠 출처를 위조할 수도 없고, S가 무효한 질의들을 수용하게 하거나 유효한 질의들에 부정확하게 응답하게 할 수도 없다. 구체적으로, 검증자가 (Query, Stmt)를 입력하고 (b, S)를 출력한다면, P는 TLS 세션에서 Q=Query(θs)를 S에 발신하여, b = Stmt(R)이 되는 응답 R = S(Q)을 수신했을 것이다.
ㆍ검증자 무결성: 악의적인 V는 P가 부정확한 응답들을 수신하게 할 수 없다. 구체적으로, P가 (Q, R)을 출력한다면, R은 P에 의해 제출된 질의 Q에 대한 서버의 응답, 즉, R = S(Q)이어야 한다.
ㆍ프라이버시: 악의적인 V는 단지 공개 정보 (Query, S) 및 Stmt(R)의 평가만을 학습한다.
스트로만 프로토콜(Strawman Protocol)
본원은 예시적인 실시예들에서 두 개의 널리 사용되는 대표적인 TLS 암호 스위트들: CBC-HMAC 및 AES-GCM에 초점을 맞춘다. 본 기법은 또한 다른 암호들(예를 들어, Chacha20-Poly1305 등)로 일반화된다. 본원은 특정 실시예들을 설명하기 위해 먼저 CBC-HMAC를 사용하고, 이후에 AES-GCM에 대한 기법들을 설명한다.
TLS는 각 통신 방향에 대해 별개의 키들을 사용한다. 명시적으로 특정되지 않는 한, 본원은 둘을 구별하지 않고 및 을 사용하여 양 방향들에 대한 세션 키들을 나타낸다.
DECO의 예시적인 실시예들을 제시함에 있어서, 스트로만 프로토콜로 시작하여 전체 프로토콜까지 증분적으로 구축된다.
(P, V) 사이에서 F오라클을 실현하는 스트로만 프로토콜은 다음과 같다. P가 서버(S)에 질의하고, 서버로 발신되고 서버로부터 수신되는 모든 메시지들을 각각
Figure pct00003
및
Figure pct00004
로 레코딩한다.
Figure pct00005
및 (
Figure pct00006
및
Figure pct00007
)를 세션 키들이라고 한다.
그 후, 그녀는 영지식으로 1) 각
Figure pct00008
가
Figure pct00009
, 평문 레코드 및 MAC 태그로 복호화하고; 2) Ri에 대한 각 MAC 태그(σi)가
Figure pct00010
에 대해 검증하며; 3) 요구되는 명제가 응답 상에서 b로 평가됨, 즉, b = Stmt(R)임을 증명한다. 표준 표기법을 사용하여, P는 다음을 연산한다
Figure pct00011
Figure pct00012
.
그녀는 또한 증명(pq)에서 유사하게 Q가 Q = Query(θs)로서 잘 형성됨을 증명하고 (pq, pr,
Figure pct00013
,
Figure pct00014
, b)를 V에 발신한다.
Figure pct00015
이 TLS 세션의 진정한 트랜스크립트라는 것을 고려하면, 증명자 무결성 속성은 유지될 것으로 보인다. 직관적으로, CBC-HMAC 암호문들은 기본 평문에 바인딩함에 따라,
Figure pct00016
은 세션 데이터에 대한 보안 커미트먼트로서 취급될 수 있다. 즉, 소정의
Figure pct00017
은 고유 메시지에 대해서만 개방될(즉, 복호화되고 MAC 검사됨) 수 있다. 바인딩 속성은 P가 서버와의 원래 세션 이외의 상이한 메시지에 대한
Figure pct00018
개방을 방지한다.
불행하게도, 이러한 직관에는 결함이 있다. 스트로만 프로토콜은
Figure pct00019
의 진위를 보장할 수 없기 때문에 완전히 실패한다. 증명자(P)는 세션 키들을 갖고, 이에 따라 그녀는
Figure pct00020
에 임의의 메시지들의 암호화를 포함시킬 수 있다.
더욱이, P가 구축할 필요가 있는 영지식 증명은 전체 트랜스크립트를 복호화하고 해싱하는 것을 수반하며, 이는 엄청나게 비용이 많이 들 수 있다. 프로토콜이 실제적이기 위해서는 비용을 상당히 감소시킬 필요가 있다.
DECO의 개요
상술된 스트로맨 접근법의 임계적인 실패는 P가 세션에 대해 커밋하기 전에 그녀가 세션 키를 학습한다는 것이다. DECO의 예시적인 실시예들에서, MAC 키는 그녀가 커밋한 후까지 P로부터 보류된다.
P와 서버(S) 사이의 TLS 세션은 여전히 기밀성 및 무결성을 제공해야 한다. 더욱이, 프로토콜은 성능을 TLS의 요건들 아래로 저하시키지 않아야 한다(예를 들어, 타임아웃을 트리거함).
도 4는 예시적인 실시예에서 서버 디바이스, 증명자 디바이스 및 검증자 디바이스를 포함하는 예시적인 DECO 구현을 도시한다. DECO는 이 실시예에서 3 단계프로토콜로서 구현된다. 제1 단계는 증명자(P), 검증자(V), 및 TLS 서버(S)가 P와 V 사이에서 비밀 공유되는 세션 키들을 설정하는 신규한 3자간 핸드셰이크 프로토콜이다. 핸드셰그이크 후는 P가 표준 TLS 프로토콜에 따르지만 V로부터의 도움을 받아 서버에 액세스하는 질의 실행 단계이다. P가 질의 및 응답에 대해 커밋한 후에, V는 그녀의 키 공유분을 드러낸다. 마지막으로, P는 증명 생성 단계에서 응답에 대한 명제들을 증명한다.
3자간 핸드셰이크. 본질적으로, P와 V는 공동으로 TLS 클라이언트로서 동작한다. 이들은 공유 세션 키를 S와 비밀 공유 형태로 협상한다. 본원은 DECO의 나머지와 같이, 이 단계는 서버측 수정을 필요로 하지 않고, S에 완전히 투명하다는 것을 강조한다.
CBC-HMAC 암호 스위트에 대해, 3자간 핸드셰이크의 마지막에, P와 V는 각각
Figure pct00021
및
Figure pct00022
을 수신하는 한편, S는
Figure pct00023
을 수신한다. 표준 핸드셰이크와 같이, P와 S 양자는 암호화 키(
Figure pct00024
)를 획득한다.
3자간 핸드셰이크는 전술한 세션 데이터 커미트먼트를 다음과 같이 위조 불가능하게 만들 수 있다. 세션의 마지막에, P가 먼저 이전과 같이
Figure pct00025
으로 세션에 대해 커밋한 다음, V가 그녀의 공유분(
Figure pct00026
)을 드러낸다. V의 관점에서, 3자간 핸드셰이크 프로토콜은 잠재적인 악의적인 증명자의 영향에도 불구하고, (각 방향에 대한) 새로운 MAC 키가 모든 세션에 사용되고, 그녀가 커밋할 때까지 키들이 P에 알려지지 않음을 보장한다. MAC 키에 대한 지식 없이는, P는 세션 데이터에 대해 커밋하기 전에 이를 위조하거나 변경할 수 없다. 이에 따라, DECO에서의 세션 데이터 커미트먼트의 위조 불가능성은 TLS에서 사용되는 MAC 방식의 위조 불가능성으로 감소된다.
GCM과 같은 다른 암호 스위트도 유사하게 지원될 수 있다. GCM에서, (각 방향에 대한) 단일 키가 암호화 및 MAC 양자에 사용된다. 핸드셰이크 프로토콜은 유사하게 P와 V 간에 키를 비밀 공유한다. GCM에 대한 핸드셰이크 프로토콜은 본원에서의 다른 곳에서 더 상세히 설명된다.
질의 실행. 세션 키들은 언급된 바와 같이 비밀 공유되기 때문에, P와 V는 질의를 암호화하는 TLS 메시지를 구성하기 위해 대화형 프로토콜을 실행한다. 그 후, P가 표준 TLS 클라이언트로서 S에 메시지를 발신한다. CBC-HMAC에 대해, 이들은 질의의 MAC 태그를 연산하는 한편, GCM에 대해, 이들은 인증된 암호화를 수행한다. 질의는 P에 비공개이고, V에 누설되지 않아야 한다는 점에 유의한다. 일반적인 2PC는 대량 질의들에 대해 비용이 많이 들 수 있으므로, 본원은 대신에 본원에서의 다른 곳에서 설명되는 바와 같이, 일반적인 솔루션들보다 훨씬 더 효율적인 맞춤형 2PC 프로토콜들을 도입한다.
전술된 바와 같이, P는 V의 키 공유분을 수신하기 전에 세션 데이터(
Figure pct00027
)에 대해 커밋하여, 커미트먼트를 위조 불가능하게 만든다. 그 후, P는 이제 설명될 바와 같이, 응답의 무결성을 검증할 수 있고, 이에 대한 명제들을 증명할 수 있다.
증명 생성. 위조 불가능한 커미트먼트들에 의해, P가 커미트먼트(
Figure pct00028
)를 완전히 개방한다면(즉, 암호화 키를 드러낸다면), V는 복호화에 대한 MAC들을 검사함으로써
Figure pct00029
의 진위를 용이하게 검증할 수 있다.
그러나,
Figure pct00030
에 대한 암호화 키를 드러내는 것은 프라이버시를 침해할 것이다: 이는 P와 S 사이에서 교환되는 모든 세션 데이터를 드러낼 것이다. 이론적으로, 대신 P는 영지식으로(즉, 암호화 키를 드러내지 않고)
Figure pct00031
을 통해 임의의 명제(Stmt)를 증명할 수 있다. 그러나, 일반적인 영지식 증명 기법들은 Stmt의 많은 자연적인 선택에 대해 엄청나게 비용이 많이 든다.
대신에, DECO는 광의의 일반적인 부류의 명제 - 즉 본원에서 TLS 세션 트랜스크립트의 "선택적 개방"이라고 지칭되는 것 - 에 대한 효율적인 증명을 지원하기 위한 두 가지 기법들을 도입한다. 선택적인 개방은 서브스트링을
Figure pct00032
에 드러내거나 또는 서브스트링을 수정, 즉, 삭제하고, 서브스트링을
Figure pct00033
에 은폐하는 것을 포함한다.
도 5는 증명자로서 동작하는 사용자 Bob에 대한 단순화된 JSON 입출금 내역서를 예시적인 예로서 도시한다. 이 예는 선택적 개방 및 컨텍스트 무결성 공격들을 나타내기 위해 사용될 것이다. Bob(P)이 자신의 예금 계좌 잔액을 드러내기를 원한다고 가정한다. 그의 TLS 세션에 대한 복호화 키를 드러내는 것은 바람직하지 않을 것이다: 이는 또한 그의 거래내역들을 포함하여, 전체 명제들을 드러낼 것이다. 대신에, 본원에 개시된 기법들을 사용하여, Bob은 라인 5-7에서의 서브스트링만을 효율적으로 드러낼 수 있다. 대안적으로, 그가 그의 적금 계좌 잔액을 드러내지 않으려고 하는 경우, 그는 라인 7 이후의 그의 거래내역들을 수정할 수 있다.
두 가지 선택적인 개방 모드들, 즉 서브스트링을 드러내는 모드 및 서브트링들을 수정하는 모드는 유용한 프라이버시 보호 메커니즘들이다. 이들은 또한 후속 영지식 증명을 위한 전처리로서 기능할 수 있다. 예를 들어, Bob은 실제 잔액을 드러내지 않고, $1000보다 많은 잔액을 갖는 계좌를 가지고 있다는 것을 증명하기를 원할 수 있다. 그 후, 그는 자신의 예금 계좌 잔액을 포함하는 서브스트링에 대한 술어("잔액 > $1000")를 영지식으로 증명할 것이다.
그러나, 선택적인 개방 단독으로는 많은 적용예들에 충분하지 않다. 이는 서브스트링의 컨텍스트가 이의 의미에 영향을 미치기 때문이다. 본원에서 컨텍스트 무결성이라고 부르지 않고, P는 주장을 증명하는 것으로 잘못 보이는 서브스트링을 속여 V에 드러낼 수 있다. 예를 들어, Bob은 $1000를 초과하는 잔액을 갖지 않을 수 있다. 그러나, 그의 입출금 내역을 열람한 후, 동일한 TLS 세션에서 서브스트링 "잔액": $5000으로 고객 서비스에 대한 메시지를 게시하고, 그 후 자신의 계류중인 메시지를(반사 공격의 형태로) 열람할 수 있다. 그 후, 그는 이러한 서브스트링을 V에 드러내 속일 수 있다.
예를 들어, V에 대한 증명자 공급 입력들에 대한 다양한 위생처리 휴리스틱스(sanitization heuristics), 예를 들어, 세션 트랜스크립트를 줄이는 것은 몇몇 이러한 공격들을 잠재적으로 방지할 수 있지만, 다른 형태들의 웹 애플리케이션 입력 위생처리와 같이, 취약하고 공격하기 쉽다.
대신에, 본원은 세션 데이터가 명시적으로 그러나 기밀하게 파싱되는 엄격한 기법들을 도입한다. 본원은 이 기법을 "영지식 2단 파싱"이라 칭한다. 이 기법에 따라, P는 제1 단에서
Figure pct00034
을 로컬로 파싱하고, 그 후 결과적인 서브스트링에 대한 제약들에 대한 명제를 영지식으로 V에 증명한다. 예를 들어, 본원의 입출금 예에서, 은행 제공 키-값 저장소들이 항상 구별된 문자(λ)로 이스케이프된다면, Bob은 λr가 선행되는 서브스트링 "잔액": $5000을 로컬 파싱을 통해 추출하고 이를 V에 드러냄으로써 정확한 잔액을 증명할 수 있다. 매우 일반적인 부류의 웹 API 문법들(고유 키들)에 대해, 이러한 2단 접근법은 더 일반적인 기법들보다 훨씬 더 효율적인 증명을 산출하는 것으로 제시될 수 있다.
도 6은 위에서 소개된 DECO 프로토콜의 더 상세한 예시적인 구현을 도시한다. 이 실시예에서, DECO 프로토콜은 3자간 핸드셰이크 단계, 이어서 질의 실행 단계에 대한 2PC 프로토콜, 및 증명 생성 단계를 포함한다. 이들 단계들 각각은 아래에서 더 상세히 설명될 것이다. 본원에 개시된 다른 실시예들과 같이, 이 실시예의 특정 상세는 단지 예로서 제시되며, 어떠한 방식으로도 제한적인 것으로서 해석되어서는 안 된다는 것을 이해해야 한다. 당업자들은 추가적인 또는 대안적인 기법들이 사용될 수 있다는 것을 인식할 것이다.
3자간 핸드셰이크
일부 실시예들에서, 3자간 핸드셰이크(3P-HS)의 목적은 증명자(
Figure pct00035
)와 검증자(
Figure pct00036
) 사이에서 서버(
Figure pct00037
)와의 TLS 세션에서 사용되는 세션 키를
Figure pct00038
에 완전히 투명한 방식으로 비밀 공유하는 것이다. 우선, 설명을 위해 CBC-HMAC에 초점을 맞추고, GCM을 지원하기 위해 프로토콜을 적응시킨다.
도 7은 예시적인 실시예에서 3자간 핸드셰이크 프로토콜의 형식적 사양을 도시한다.
도 8은 일부 실시예들에서 3자간 핸드셰이크 프로토콜의 일부인 예시적인 ECtF 프로토콜을 도시한다.
다시, 이들 프로토콜들의 특정 세부사항들은 단지 예들이며, 어떠한 방식으로도 제한되지 않는다. 예를 들어, 증명자, 검증자 및 서버를 포함하는 다양한 다른 유형의 3자간 핸드셰이크 프로토콜이 다른 실시예들에서 사용될 수 있다. 이에 따라, 본원에서 사용되는 용어 "3자간 핸드셰이크 프로토콜"은 광범위하게 해석되도록 의도된다.
표준 TLS 핸드셰이크에서와 같이, 3P-HS는 두 개의 단계들: 먼저,
Figure pct00039
와
Figure pct00040
는 TLS 호환 가능 키 교환 프로토콜을 통해 서버와 공유되는 비밀(
Figure pct00041
)의 부가 공유들을 연산하는 단계를 포함한다. 다른 기술들이 공유들을 연산하고, 두 번째로
Figure pct00042
와
Figure pct00043
는 TLS-PRF를
Figure pct00044
의 그들의 공유분들을 입력들로서 안전하게 평가함으로써 비밀 공유 세션 키들을 도출하기 위해 사용될 수 있지만, ECDHE가 추천되고 여기서 집중된다. 아래에서는 이해를 위해 공식적인 사양이 요구되지 않도록 텍스트 설명을 제공한다.
단계 1: 키 교환.
Figure pct00045
는 이의 생성기에서 ECDHE 및
Figure pct00046
에 사용되는 EC 그룹을 나타낸다고 한다.
증명자(
Figure pct00047
)는 정규 TLS 핸드셰이크 요청 및 랜덤 넌스(
Figure pct00048
)를 (ClientHello 메시지에서)
Figure pct00049
에 발신함으로써 핸드셰이크를 개시한다. (Server-Hello 및 ServerKeyExchange 메시지들에서)
Figure pct00050
로부터 인증서, 서버 넌스(
Figure pct00051
), 및 서명된 일시적 DH 공개 키(
Figure pct00052
)를 수신 시,
Figure pct00053
는 인증서 및 서명을 검사하고 이들을
Figure pct00054
로 포워딩한다. 동일한 검사를 수행한 후,
Figure pct00055
는 비밀(
Figure pct00056
)을 샘플링하고, DH 공개 키(
Figure pct00057
)의 일부를
Figure pct00058
에게 송신하며, 이는 또 다른 비밀(
Figure pct00059
)을 샘플링하고, 조합된 DH 공용 키(
Figure pct00060
)를
Figure pct00061
에게 송신한다.
서버(
Figure pct00062
)는 표준 TLS를 실행하므로,
Figure pct00063
는 DH 비밀을
Figure pct00064
로서 연산하고 (그리고
Figure pct00065
가)
Figure pct00066
의 그의 공유분을
Figure pct00067
(및
Figure pct00068
)로서 연산할 것이다.
Figure pct00069
이며, 여기서 +는
Figure pct00070
의 그룹 연산임에 유의한다. 이산 로그 문제가 선택된 그룹에서 하드하다고 가정하면,
Figure pct00071
는 어느 당사자에게도 알려지지 않는다.
단계 2: 키 유도. 이제,
Figure pct00072
와
Figure pct00073
가 (EC 포인트들의 형태로)
Figure pct00074
의 부가 공유분들(additive shares)을 설정하였고, 이들은
Figure pct00075
의
Figure pct00076
좌표로 키잉된 TLS-PRF를 평가함으로써 세션 키들을 도출하도록 진행한다.
여기서의 기술적 과제는 2PC에서의 비트단위 연산(즉, TLS-PRF)과 산술 연산(예를 들어,
Figure pct00077
에서의 덧셈)을 조화시키는 것이다. 부울러 회로는 큰 분야에서의 산술에 적합하지 않다는 것이 잘 알려져 있다. 구체적인 추정으로서,
Figure pct00078
좌표만을 초래하는 EC 포인트 가산은 4개의 감산, 하나의 모듈러 반전, 및 2개의 모듈러 승산을 수반한다. 고도로 최적화된 회로들에 기초한 AND 복잡도의 추정은 감산들, 승산들, 및 모듈러 감소들에 대해서만 900,000 이상의 AND 게이트들을 초래하며 - 심지어 반전을 포함하지 않고, 이는 회로 내부에서 확장된 유클리드 알고리즘을 실행하는 것을 요구할 것이다.
부울 회로 내에 EC 포인트들을 추가하는 엄청난 비용으로 인해,
Figure pct00079
와
Figure pct00080
는 도 8에 제시된 ECtF 프로토콜을 사용하여,
Figure pct00081
에서의 EC 포인트의 부가 공유분들을
Figure pct00082
에서의 이의
Figure pct00083
좌표의 부가 공유분들로 변환한다. 그 후, 부울 회로는
Figure pct00084
Figure pct00085
에서의 단지 두 개의 숫자를 추가하는 것을 수반하며, 이는 단지 ~3|p| AND 게이트, 즉 본원 구현의 ~768 AND 게이트로 행해질 수 있으며, 여기서 p는 256 비트이다.
ECtF를 사용한 공유분 변환.
Figure pct00086
에서의 ECtF 프로토콜은
Figure pct00087
에서의 공유분들로 변환한다. ECtF 프로토콜에 대한 입력들은
Figure pct00088
로 나타내어지는 두 개의 EC 포인트들(
Figure pct00089
)이다.
Figure pct00090
이며, 여기서
Figure pct00091
는 EC 그룹 연산이라고 가정하면, 프로토콜의 출력은
Figure pct00092
이며
Figure pct00093
이 된다. 구체적으로, 본원은 곡선에 대해,
Figure pct00094
, 여기서
Figure pct00095
임을 고려한다.
Figure pct00096
의 공유분들은 유사하게 연산될 수 있지만, TLS가 단지
Figure pct00097
만을 사용하기 때문에 이를 생략한다.
ECtF는 곱셈-덧셈(Multiplicative-to-Additive, MtA) 공유 변환 프로토콜을 빌딩 블록으로서 사용한다. 본원은 각각 입력 a 및 b를 갖는 Alice와 Bob 사이의 MtA의 실행을 나타내기 위해
Figure pct00098
를 사용한다. 실행의 마지막에, Alice 및 Bob은 α 및 β를 수신하며 a·b=α+β가 된다. 프로토콜은 통신 복잡도를 증가시키지 않고 벡터 입력들을 핸들링하도록 일반화될 수 있다. 즉, 벡터들(
Figure pct00099
)에 대해,
Figure pct00100
라면,
Figure pct00101
이다.
이제 ECtF의 프로토콜을 설명한다. ECtF는 두 개의 주요 성분을 갖는다.
Figure pct00102
를 α의 2/2 공유, 즉 당사자(i)가
Figure pct00103
에 대해
Figure pct00104
를 가지면서,
Figure pct00105
인 것을 나타낸다. 제1 성분은 공유분 반전이다: [α]가 주어지면, [α-1]를 연산한다. 이는 다음과 같이 수행될 수 있다: 당사자(i)는 랜덤 값(
Figure pct00106
)을 샘플링하고 MtA를 실행하여
Figure pct00107
를 연산한다.
Figure pct00108
임에 유의한다. 당사자(i)는
Figure pct00109
임을 게시하고, 이에 따라 양 당사자들이
Figure pct00110
를 학습한다. 최종적으로, 당사자(i)는
Figure pct00111
를 출력한다.
Figure pct00112
이기 때문에, 프로토콜은
Figure pct00113
의 정확한 공유분을 연산한다. 더욱이, 프로토콜은 MtA가 안전하다고 가정하면 어느 당사자에게도
Figure pct00114
를 누설하지 않는다. 사실상, 당사자(i)는 뷰는
Figure pct00115
로 구성되며, 이는
Figure pct00116
가 균일하게 랜덤하기 때문에 불균일하게 랜덤하다.
제2 성분은 공유분 곱셈이다:
Figure pct00117
가 주어지면,
Figure pct00118
를 연산한다.
Figure pct00119
는 MtA를 사용하여 다음과 같이 연산될 수 있다: 당사자들은 MtA를 실행하여
Figure pct00120
이 되도록
Figure pct00121
를 연산한다. 그 후, 당사자(i)는
Figure pct00122
를 출력한다. 프로토콜의 보안 및 정확성은 상기와 유사하게 적용될 수 있다.
TLS-PRF의 보안 평가. ECtF로, TLS에서
Figure pct00123
의
Figure pct00124
좌표의 공유분, 소위 프리마스터 비밀을 연산한다면, P 및 V는 세션 키들을 유도하기 위해 2PC에서 TLS-PRF를 평가한다. 공지된 SHA-256 회로를 사용하여, 본원은 TLS 핸드셰이크 회로를 핸드-최적화하여, 779,213의 총 AND 복잡도를 갖는 회로를 생성한다.
GCM을 지원하기 위한 적응. GCM에 대해, 단일 키(각 방향에 대해)가 암호화 및 MAC 모두에 대해 사용된다. TLS 1.2에서 GCM을 지원하기 위해 프로토콜을 적응시키는 것은 간단하다. 제1 단계는 동일하게 유지되는 반면, 제2 단계의 출력은 GCM 키가 더 짧기 때문에 절단될 필요가 있다.
TLS 1.3에 적응. TLS(1.3)를 지원하기 위해, 3P-HS 프로토콜은 새로운 핸드셰이크 흐름 및 상이한 키 유도 회로에 적응되어야 한다. 특히, ServerHello 이후의 모든 핸드셰이크 메시지들은 이제 암호화된다. 나이브 전략은 2PC에서 이들을 복호화하는 것이고, 이는 인증서가 일반적으로 크기 때문에 비용이 많이 들 것이다. 그러나, TLS(1.3)의 키 독립성 특성으로 인해, 본원의 다른 곳에서 설명된 바와 같이, TLS(1.2)에 대한 것과 유사한 복잡도의 3P-HS 프로토콜을 구성할 수 있다.
질의 실행
핸드셰이크 후에, 증명자(P)는 표준 TLS 클라이언트로서, 그러나 검증자(V)로부터의 도움을 받아 서버(S)에 자신의 질의(Q)를 송신한다. 특히, 세션 키들이 비밀 공유되기 때문에, 두 당사자들은 Q를 암호화하는 TLS 레코드들을 구성하기 위해 2PC 프로토콜을 상호작용하고 실행할 필요가 있다. 비록 일반적인 2PC가 이론적으로 충분할지라도, 큰 질의들에 대해서는 비용이 많이 들 것이다. 대신에, 본원은 규모가 더 효율적인 커스텀 2PC 프로토콜을 도입한다.
본원은 먼저 P가 임의의 응답을 수신하기 전에 S에 모든 질의들을 발신하는 원-라운드 세션들에 포커스를 맞춘다. 예를 들어, HTTP GET을 통해 검색된 컨텐츠의 출처를 증명하는 DECO의 대부분의 적용예들은 원-라운드이다. 멀티-라운드 세션들을 지원하기 위해 DECO를 확장하는 것은 본원에서의 다른 곳에서 설명된다.
CBC-HMAC. P 및 V는 암호화 키를 보유하는 동안 MAC 키의 공유분들을 보유하고 보유하는 것을 상기한다. 잠재적으로 P에 비공개인 Q를 암호화하는 TLS 레코드들을 구성하기 위해, 두 당사자들은 먼저 2PC 프로토콜을 실행하여 Q의 HMAC 태그(τ)를 연산한 후, P가
Figure pct00125
를 로컬로 암호화하고 암호문을 S에 발신한다.
H를 SHA-256이라고 한다. 키(k)를 갖는 메시지(m)의 HMAC는
Figure pct00126
용어 ipad 및 opad는 HMAC 알고리즘에서 이용되는 각 "내부" 및 "외부" 값을 나타낸다. 직접적인 2PC 구현은 내부 해시를 연산하기 위해 2PC에서 전체 질의를 해싱하는 것을 요구하기 때문에, 큰 질의들에 대해 비용이 많이 들 것이다. 이는 내부 해시의 연산을 P에 로컬로(즉, 2PC 없이) 만듦으로써 예시적인 실시예에서 바람직하게 회피된다. P가
Figure pct00127
를 안다면, 그는 내부 해시를 연산할 수 있다. 그러나, 본원은 그가 그 후 k를 학습하고 MAC들을 위조할 수 있으므로, 단순히
Figure pct00128
를 P에 제공한다.
본원의 최적화는 SHA-256에서 Merkle-Damgard 구조를 이용한다. m1 및 m2를 두 개의 정확한 크기의 블록이라고 가정한다. 그 후,
Figure pct00129
가
Figure pct00130
로서 연산되며, 여기서 fH는 H의 단방향 압축 함수를 나타내고, IV는 초기 벡터를 나타낸다.
도 9는 CBC-HMAC에 대한 포스트-핸드셰이크 프로토콜들을 도시한다.
3자간 핸드셰이크 후, P 및 V는 간단한 2PC 프로토콜을 실행하여
Figure pct00131
를 연산하고, 이를 P에 공개한다. 메시지(
Figure pct00132
)의 내부 해시를 연산하기 위해, P는
Figure pct00133
를
Figure pct00134
로서 사용한다.
Figure pct00135
배포는
Figure pct00136
가 일방향인 것으로 가정됨에 따라,
Figure pct00137
을 드러내지 않는다. 그 후,
Figure pct00138
를 연산하기 위해, 내부 해시 상의 2PC 내의 외부 해시, 훨씬 더 짧은 메시지를 연산하는 것이 포함된다. 이에 따라, 일반적인 2PC를 갖는 각 레코드에서 256개의 SHA-2 블록까지와는 대조적으로, 질의 길이에 관계없이 2PC 연산량을 몇 개의 블록으로 감소시키도록 관리한다.
AES-GCM. GCM에 대해, P 및 V는 Q의 인증된 암호화를 수행한다. 2PC-AES는 최적화된 회로로 간단하지만, 큰 질의에 대한 태그를 연산하는 것은 각 레코드에 대해 큰 필드에서 긴 다항식을 평가하는 것을 포함하기 때문에 비용이 많이 든다. 본 발명의 최적화된 프로토콜은 본원의 다른 곳에서 더 상세히 설명되는 바와 같이, 사전연산을 통해 다항식 평가를 로컬로 만든다. 2PC-GCM은 태그 생성뿐만 아니라 AES 암호화를 포함하기 때문에, CBC-HMAC보다 더 높은 연산 비용 및 레이턴시를 초래한다.
본원에 개시된 다른 실시예들은 추가 신뢰 가정들과 함께 포스트-핸드셰이크 2PC 프로토콜들을 완전히 회피하는 프록시 모드 프로토콜로서 지칭되는 매우 효율적인 대안적인 프로토콜을 이용한다.
도 6에 도시된 전체 DECO 프로토콜에 도시된 바와 같이, 서버에 질의하고 응답을 수신한 후,
Figure pct00139
는 암호문을
Figure pct00140
에 송신함으로써 세션에 커밋하고,
Figure pct00141
의 MAC 키 공유분을 수신한다. 그 후,
Figure pct00142
가 응답의 무결성을 검증할 수 있고, 이에 대한 명제를 증명할 수 있다. 도 6은 CBC-HMAC에 대한 전체 DECO 프로토콜을 특정한다. GCM에 대한 DECO 프로토콜은 유사하고 본원의 다른 곳에서 설명된다.
명료함을 위해, 이상적인 기능(
Figure pct00143
)에서 영지식 증명의 상세를 제외한다.
Figure pct00144
로부터 ("증명",
Figure pct00145
) - 여기서
Figure pct00146
및
Figure pct00147
는 각각 비공개 및 공개 증인들임 - 를 수신 시,
Figure pct00148
는
Figure pct00149
및 관계(
Figure pct00150
(아래에서 정의됨))를
Figure pct00151
에 발신한다. 구체적으로, CBC-HMAC에 대해,
Figure pct00152
는
Figure pct00153
및
Figure pct00154
과 같이 정의된다. 관계(
Figure pct00155
)는 필요충분조건으로 (1)
Figure pct00156
가 키(
Figure pct00157
) 하에서
Figure pct00158
(및
Figure pct00159
)의 CBC-HMAC 암호문이라면; (2)
Figure pct00160
라면; 그리고 (3)
Figure pct00161
라면 1을 출력한다. 그렇지 않다면, 이는 0을 출력한다.
보안 2PC 및 ZKP들에 대한 기능들을 가정하면, 도 6에 제시된 바와 같은
Figure pct00162
가 악의적인 적대자들에 대해 도 3의
Figure pct00163
을 UC 보안적으로 실현하는 것이 제시될 수 있다.
보다 구체적으로, 이산 로그 문제가 3자간 핸드셰이크에서 사용되는 그룹에서 하드하고, (SHA-256의 압축 함수)가 랜덤 오라클이라고 가정하면,
Figure pct00164
는
Figure pct00165
-하이브리드 세계에서 악의적인 정적 적대자에 대해 중단과 함께
Figure pct00166
을 UC 보안적으로 실현한다.
GCM에 대한 프로토콜은 유사한 흐름을 갖는다. 3자간 핸드셰이크 및 질의 구성 프로토콜들의 GCM 변형들은 위에서 설명되었다.
도 10은 GCM 변형에서 태그를 검증하고 레코드를 복호화하기 위한 2PC 프로토콜을 도시한다. 이들은 또한 GCM에 대한 포스트-핸드셰이크 프로토콜로서 지칭된다.
CBC-HMAC와 달리, GCM은 커밋하고 있지 않다: 키(
Figure pct00167
)로 암호화된 소정의 암호문(
Figure pct00168
)에 대해,
Figure pct00169
에 대한 지식은 무결성 검사를 통과하면서
Figure pct00170
를 상이한 평문으로 복호화하는
Figure pct00171
를 효율적으로 찾을 수 있다. 이러한 공격을 방지하기 위해, 본원은 P가 V의 키 공유분을 학습하기 전에 자신의 키 공유분(
Figure pct00172
)에 대해 커밋해야 한다. 증명 생성 단계에서,
Figure pct00173
에 대한 명제들을 증명하는 것 외에,
Figure pct00174
및
Figure pct00175
을 복호화하기 위해 사용되는 세션 키들이
Figure pct00176
에 대한 커미트먼트에 대해 유효하다는 것을 증명할 필요가 있다. GCM 변종의 보안의 증명은 CBC-HMAC에 대한 것과 유사하다.
증명 생성
증명자(
Figure pct00177
)가 TLS 세션의 암호문(
Figure pct00178
)을 커밋하고 평문(
Figure pct00179
)이 특정 속성을 만족하는 것을
Figure pct00180
에 증명한다는 것을 상기하자. 일반성의 손실 없이, 본원은
Figure pct00181
및
Figure pct00182
를 단지 하나의 TLS 레코드를 포함한다고 가정하고, 이후 암호문 레코드 및 평문 레코드를 호출한다. 다중-레코드 세션들은 각 레코드에 대한 프로토콜을 반복함으로써 처리될 수 있다.
단지
Figure pct00183
의 증명만을 제공하는 것은 용이하다: 단지 암호화 키들을 드러낸다. 그러나, 이는 프라이버시를 희생시킨다. 대안적으로,
Figure pct00184
는 일반적인 영지식 기술들을 사용하여
Figure pct00185
에 관한 임의의 명제를 증명할 수 있다. 그러나, 이러한 증거는 보통 비용이 많이 든다.
다음의 설명에서, 본원은 예를 들어 애플리케이션에 대해 최적화된 두 부류의 명제를 제시한다: 그 출처("선택적 개방")를 제공하면서 응답의 서브스트링만을 드러내는 것, 또는 드러난 서브스트링을("두 단계 파싱에 의한 컨텍스트 무결성")에 의해 예상되는 컨텍스트에서 보이는 것을 더 증명하는 것.
선택적 개방. 예시적인 실시예들은 본원에서 "선택적 개방"으로 지칭되는 것을 구현하며,
Figure pct00186
가 평문 내의 서브스트링들을 효율적으로 드러내거나 교정할 수 있게 하는 기술들을 구현한다. 평문 레코드가 청크들(
Figure pct00187
)로 구성된다고 가정한다(청킹의 상세들은 아래에서 논의됨). 선택적 개방은
Figure pct00188
가
Figure pct00189
의 나머지를 드러내지 않으면서
Figure pct00190
의 제i 청크가
Figure pct00191
라는 것을 증명할 수 있게 하며; 본원은 이를 노출 모드라고 한다. 이는 또한
Figure pct00192
가
Figure pct00193
과 동일하지만 청크가 제거된 것임을 증명할 수 있다. 본원은 이 리닥 모드를 호출한다. 양 모드는 간단하지만, 실제적인 프라이버시 목적에 유용하다. 선택적 오프닝의 입도는 이제 논의하는 암호 스위트에 의존한다.
CBC-HMAC. 증명 생성을 위해, P는 암호화 및 MAC 키들(
Figure pct00194
및
Figure pct00195
) 양자를 보유하는 한편, V는 MAC 키(
Figure pct00196
)만을 갖는다는 것을 상기하자. 본원의 성능 분석은 SHA-256 및 AES-128을 갖는 암호 스위트를 가정하며, 이는 본원의 구현에 매칭하지만, 기술들은 다른 파라미터들에 적용가능하다. MAC-then-암호화가 사용된다는 것을 상기한다: 평문 레코드(
Figure pct00197
)는 최대 1024개의 AES 데이터 블록들 및 3개의 MAC 태그(
Figure pct00198
) 블록들을 포함하며, 이는
Figure pct00199
로서 나타내며, 여기서
Figure pct00200
이다.
Figure pct00201
은
Figure pct00202
의 CBC 암호화이어서, 동일한 수의 블록들:
Figure pct00203
(여기서
Figure pct00204
)로 구성된다.
TLS 레코드 노출.
Figure pct00205
노출 없이
Figure pct00206
이
Figure pct00207
을 암호화하는 것을 증명하는 나이브 방법은 ZKP에서 각 AES 블록의 정확한 암호화를 증명하는 것이다. 그러나, 이는 ZKP에서 AES의 1027 호출까지 요구되어, 비실용적인 성능을 초래한다.
MAC-then-encrypt 구조를 탐색하면, ZKP에서 AES의 3개의 호출만을 사용하여 동일하게 수행될 수 있다. 이는 예시적으로
Figure pct00208
의 마지막 몇 개의 블록들이 태그(
Figure pct00209
)를 암호화하고 평문을 직접 드러내는 것을 증명하는 것을 수반한다. 구체적으로,
Figure pct00210
는
Figure pct00211
를 연산하고,
Figure pct00212
를
Figure pct00213
에 발신한다. 그 후,
Figure pct00214
는
Figure pct00215
을 통해
Figure pct00216
를 검증하고 MAC 태그를 검사한다(
Figure pct00217
가 MAC 키를 알고 있다는 것에 유의한다). 이의 보안은 HMAC에서 기본 해시 함수의 충돌 저항성에 의존하는데, 즉,
Figure pct00218
는 동일한 태그(
Figure pct00219
)로는
Figure pct00220
을 찾을 수 없다.
수정된 블록들을 이용한 레코드 노출. 제i 블록이 P가 수정하기를 원하는 민감한 정보를 포함한다고 가정한다. 직접적인 전략은 다음을 연산함으로써,
Figure pct00221
로 암호화되는 평문의 프리픽스 및 서픽스를 형성하기 위해
Figure pct00222
및
Figure pct00223
임을 증명하는 것이다
Figure pct00224
.
이는 ZKP에서 3개의 AES 및 256개의 SHA-256 압축을 포함하기 때문에 비용이 많이 든다.
SHA-256의 Merkle-Damgard 구조를 활용하면, 여러 최적화가 가능하다. f는 SHA-256의 압축 함수를 나타내고, si-1는 f를 B i-에 적용한 후의 상태를 나타낸다고 한다. 첫째, si-1 및 si 양자가 드러날 수 없을 때(예를 들어, B i가 API 키들과 같은 고엔트로피 데이터를 포함할 때), 상기한 목표는 ZKP에서 단지 1 SHA-256을 사용하여 달성될 수 있다. 그러기 위해, P는
Figure pct00225
를 연산하고
Figure pct00226
를
Figure pct00227
에게 발신하며, 그 후, 이는 1) B i-로부터 이를 재연산함으로써 si-1를 검사하고; 2) π를 검증하며; si 및 B i+로부터 이를 재연산함으로써 MAC 태그(σ)를 검사한다. Bi를 고엔트로피라고 가정하면, si-1 및 si를 드러내는 것은 f가 일방향이기 때문에 Bi를 누설하지 않는다.
한편, si-1 및 si 양자가 V에 드러날 수 없을 때(예를 들어, Bi에 대한 맹공이 실행가능할 때), 본원은 블록(Bi)을 포함하는 레코드의 프리픽스(또는 서픽스)를 P가 수정하게 함으로써 비용을 여전히 감소시킬 수 있다. 그 후 발생되는 비용은 ZKP에서 256-i SHA-2 해시들이다. 추가적인 세부 사항들은 본원의 다른 곳에서 제공된다. 일반적으로, ZKP 비용은 레코드 크기에 비례하므로, TLS 단편화도 비용을 일정한 팩터만큼 낮출 수 있다.
서픽스 수정. 서픽스(B i+)가 수정되어야 할 때, P는
Figure pct00228
를 연산하고 si는 f를
Figure pct00229
에 적용한 후의 상태이다. P는
Figure pct00230
를 V에 발신한다. 그 후, 검증자는 1) f를
Figure pct00231
에 적용함으로써 si-1를 검사하고, 2) π를 검증한다. 기본적으로, 이의 보안은 f의 역상 저항성(pre-image resistance)으로부터 비롯된다. 더욱이, V는
Figure pct00232
가 V에 비밀로 유지되기 때문에 수정된 서픽스를 알지 못한다. 총 비용은 ZKP에서 3 AES 및 256-i SHA-2 해시들이다.
프리픽스 수정. P는 다음의 두 가지 ZKP들: 1)
Figure pct00233
: 2)
Figure pct00234
를 연산한다. P는
Figure pct00235
를 V에 발신한다. 검증자는 1) π1을 사용하여 si-1이 정확한지를 검사한 후, 내부 해시(ih)를 획득하기 위해
Figure pct00236
를 연산하고, 2) 연산된 ih를 사용하여 π2가 검증된다. 발생되는 비용은 ZKP에서 3AES 및 256-i SHA-2 해시이다.
프리픽스/서픽스를 재실행하는 것은 단지 드러난 부분이 임의의 개인 사용자 데이터를 포함하지 않는 경우에만 의미가 있다는 점에 유의한다. 그렇지 않으면, P는 모든 민감한 블록들을 포함하는 가장 작은 서브스트링을 찾고 상기와 유사한 프리픽스/서픽스를 정정해야 할 것이다.
GCM. CBC-HMAC와 달리, 블록을 드러내는 것은 GCM에서 매우 효율적이다. 첫째, P는 V가 암호문의 무결성을 검증할 수 있도록 하기 위해, ZK에서의 정확성의 증명과 함께
Figure pct00237
및
Figure pct00238
을 드러내고, 그 후, 제i 블록을 드러내기 위해, P는 정확한 증명과 함께 카운터의 암호화
Figure pct00239
를 드러낸다. V는 제i 블록을
Figure pct00240
로서 복호화한다. IV는 세션에 대한 공개 초기 벡터이고,
Figure pct00241
를 I 시간(inc의 정확한 포맷은 중요하지 않음)에 대한 증분 IV를 나타낸다. TLS 레코드를 드러내기 위해, P는 각 블록에 대해 프로토콜을 반복한다. 다시, 추가적인 세부사항은 본원의 다른 곳에서 제공된다.
요약하면, CBC-HMAC는 DECO에서 TLS 기록-레벨에서 효율적인 선택적 노출 및 블록 레벨에서의 재작용을 가능하게 하는 반면, GCM은 블록 레벨에서 효율적인 노출을 가능하게 한다. 선택적 개방은 또한 후속 영지식 증명을 위해 입력 길이를 감소시키기 위한 사전-처리로서 기능할 수 있다.
2 단계 파싱에 의한 컨텍스트 무결성. 많은 애플리케이션들에 대해, 검증자(V)는 드러난 서브스트링이 올바른 컨텍스트에서 나타나는 것을 검증할 필요가 있을 수 있다. 본원은 이 속성을 "컨텍스트 무결성"이라고 한다. 다음에서, 본원은 V가 컨텍스트들을 특정하기 위한 기법 및 P가 컨텍스트 무결성을 효율적으로 증명하기 위한 기법을 제시한다.
설명의 편의를 위해, 아래의 본 설명은 노출 모드에 초기에 초점을 맞추고, 즉, P가 서버의 응답의 감산을 v에 드러낸다. 이어서, 재실행 모드가 설명될 것이다.
컨텍스트들의 상세. 컨텍스트들을 특정하기 위한 본원의 기법들은 소정의 서버(S)로 그리고 이로부터 발신되는 TLS 보호 데이터가 P와 V 양자에게 알려진 잘 정의된 컨텍스트 프리 문법(
Figure pct00242
)을 갖는 것으로 가정한다. 표기법을 약간 남용하면, 본원은
Figure pct00243
를 문법 및 이것이 특정하는 언어 양자를 나타낸다. 이에 따라, R∈
Figure pct00244
는 스트링 R이
Figure pct00245
에 의해 제공되는 언어로 됨을 나타낸다. 본원은
Figure pct00246
가 모호하지 않다, 즉, 모든 R∈
Figure pct00247
가 관련된 고유 파스 트리(TR)를 갖는다고 가정한다. JSON 및 HTML은 이들 요건들을 만족시키는 널리 사용되는 두 언어의 예들이고, 본원은 여기서 이에 초점을 맞춘다.
그 후, P가 S로부터의 일부 응답(R)의 서브스트링(Ropen)을 제시할 때, 본원은 Ropen이 V에 의해 예상되는 특정 방식으로 생성되는 경우 컨텍스트 무결성을 갖는다고 말한다. 구체적으로, V가 R에서 유효한 서브스트링(Ropen)을 볼 것으로 예상할 수 있는 위치들의 세트(S)를 특정한다. 본원의 정의에서, S는
Figure pct00248
에 의해 정의된 파스 트리에서의 루트로부터 내부 노드들까지의 경로들의 세트이다. 이에 따라, s∈S - 이를 본원은 허용가능한 경로라고 칭함 - 는 비종단들의 시퀀스이다. ρR은 TR(
Figure pct00249
의 R의 파스 트리)의 루트를 나타낸다고 한다. 본원은 TR이 리프들이 스트링(Ropen)을 산출하는(즉, 연접하여 형성하는) 서브트리를 갖는 경우 스트링(Ropen)이 (R, S)에 대해 컨텍스트 무결성을 갖고, ρR로부터 상기의 서브트리의 루트까지의 경로가(s∈S) 존재한고 말한다.
형식적으로, 본원은 술어(
Figure pct00250
)의 관점에서 컨텍스트 무결성을 정의한다. 보다 구체적으로, TLS 응답들, R∈
Figure pct00251
, R의 서브스트링(Ropen), 허용가능한 경로들의 집합(S)에 대한 문법(
Figure pct00252
)이 주어지면, 본원은 필요충분조건으로
Figure pct00253
로부터
Figure pct00254
까지의 경로(s∈S)를 갖는 TR의 서브트리(
Figure pct00255
)가 존재하고
Figure pct00256
이 Ropen을 산출한다면
Figure pct00257
: (S, R, Ropen) 참이 되도록 부울 함수로서 컨텍스트 함수(
Figure pct00258
)를 정의한다. Ropen은
Figure pct00259
(S, R, Ropen) = 참인 경우 (R,S)에 대해 컨텍스트 무결성을 갖는다고 말한다.
다시 도 5의 예를 참조하면, 그 예에 따른 JSON 스트링(J)을 고려한다. JSON은 (개략적으로) 다음의 규칙들을 포함한다:
시작 → 오브젝트 오브젝트 → { 쌍들 }
쌍 → "키" : 값 쌍들 → 쌍 | 쌍, 쌍들
키 → 문자들 값 → 문자들 | 객체
이 예에서, V는 ρ예금과 키 "예금 a/c" 쌍의 값에 의해 주어지는 오브젝트에서 ρ잔액과 키 "잔액" 쌍의 유도를 학습하는 것에 관심이 있었다. 이들 비종단들 각각은 파스 트리(TJ)에서의 노드에 대한 라벨이다. TJ의 루트 시작으부터 ρ예금까지의 경로는 시작 → 오브젝트 → 쌍들*(여기서, 쌍들*은 0 또는 그 이상의 쌍들의 시퀀스를 나타냄) → ρ예금 형태의 노드 시퀀스를 순회할 것을 요구한다. 이에 따라, S는 이러한 시퀀스들의 세트이고, Ropen은 스트링 "예금 a/c":{잔액":$2000}이다.
2단 파싱. 일반적으로, Ropen이 컨텍스트 무결성, 즉,
Figure pct00260
(S, R, Ropen) = 참을 갖는다는 것을 증명하는 것은 R을 직접 드러내지 않고 비용이 많이 들 수 있다는 것을 증명하는데, 이는 연산
Figure pct00261
가 잠재적으로 긴 스트링 R에 대해 TR을 연산하는 것을 요구할 수 있기 때문이다. 그러나, 본원은 TLS 보호 데이터가 일반적으로 만족한다는 특정 가정 하에서 P와 V가 합의한 변환(Trans)을 적용하여 P가 R을 전처리하고 Ropen이 R'(일반적으로 훨씬 짧은 문자열) 및 S'(S 및 Trans를 기반으로 V로 지정된 허용 가능한 경로 세트)와 관련하여 컨텍스트 무결성을 가지고 있음을 증명함으로써 오버헤드의 많은 부분을 제거할 수 있음을 관찰했다.
이러한 관찰에 기초하여, 본원은 Ropen을 효율적으로 연산하고
Figure pct00262
(S, R, Ropen) = 참을 증명하기 위한 2단 파싱 방식을 도입한다. P 및 V가
Figure pct00263
, 웹 서버에 의해 사용되는 문법, 및 변환(Trans)에 합의한다고 가정한다.
Figure pct00264
'는 모든 R∈
Figure pct00265
에 대한 스트링들(Trans(R))의 문법이라고 한다. Trans에 기초하여, V는 허용가능한 경로들(S') 및 제약 검사 함수(
Figure pct00266
)를 특정한다. 제1 단에서, P: (1) (
Figure pct00267
(S, R, Ropen) = 참이 되도록) R을 파싱함으로써 R의 서브스트링(Ropen)을 연산하고, (2) 또 다른 스트링 R'= Trans(R)을 연산한다. 제2 단에서, P는 영지식으로 (1)
Figure pct00268
(R, R') = 참이고, (2)
Figure pct00269
(S', R', Ropen) = 참임을 V에 증명한다. 공개 파라미터
Figure pct00270
,
Figure pct00271
', S, S', Trans,
Figure pct00272
에 추가하여, 검증자는 R에 대한 커미트먼트만을 보고, 마지막으로 Ropen을 보게 된다.
이 프로토콜은 실제 파싱을 검증 불가능한 연산으로 연기함으로써 영지식 연산을 상당히 덜 비싸게 한다. 즉,
Figure pct00273
(S', R', Ropen) 및
Figure pct00274
(R, R')의 연산은
Figure pct00275
(S, R, Ropen)의 연산보다 훨씬 더 효율적일 수 있다.
2단 파싱에 대한 정확성 조건을 아래에 주어진 동작 의미 규칙으로 형식화한다. 여기서, <f, σ>는 입력 σ에 함수 f를 적용하는 것을 나타내고,
Figure pct00276
는 전제 P가 참이면 결론 C가 참인 것을 나타낸다.
문법(
Figure pct00277
), 컨텍스트 함수 및 허용 가능한 경로들(
Figure pct00278
(S', ·, ·)), 변환(Trans)을 고려하면, 문법
Figure pct00279
' ={R': R' = Trans(
Figure pct00280
), R∈
Figure pct00281
은 컨텍스트 함수와 허용가능한 경로(
Figure pct00282
(S', ·, ·)) 및 함수(
Figure pct00283
)를 가지며, 본원은 (
Figure pct00284
, S')가 모든 (R, R'', Ropen)에 대해 R∈
Figure pct00285
이도록 S에 대해 정확하다고 하며, 부울 b는 다음의 규칙을 유지한다:
Figure pct00286
아래에서, 본원은 DECO 애플리케이션들에서 사용하기에 적합한 예시적인 문법에 초점을 맞추고, 2단 파싱 방식들의 구체적인 구성들을 제시한다.
키-값 문법들. JSON과 같은 광범위한 부류의 데이터 포맷은 키-값 쌍의 개념을 갖는다. 이에 따라, 이들은 DECO의 일부 실시양태에서 초점을 맞춘다.
키-값 문법(
Figure pct00287
)은 "쌍 → 시작 키 중간 값 종료"라는 규칙에 따라 키-값들 쌍을 생성하며, 여기서 시작, 중간 및 종료는 경계들이다. 이러한 문법들에 대해, 최적화들의 어레이는 컨텍스트를 제공하기 위한 복잡성을 크게 감소시킬 수 있다. 본원은 본 명세서의 다른 곳에서 제공되는 다른 세부사항과 함께, 이하의 몇몇 이러한 최적화를 논의한다.
전역 고유 키에 대한 노출. 키-값 문법(
Figure pct00288
), 경로들(S)의 세트에 대해, R∈
Figure pct00289
에 대해, 컨텍스트 무결성을 충족시키는 서브스트링(Ropen)이 Ropen이 전역적으로 고유한 키(K)를 갖는 키-값 쌍으로서 파싱되는 것을 요구한다면, Ropen은 단순히 R의 하위스트링일 필요가 있고 쌍으로서 정확하게 파싱될 필요가 있다. 구체적으로, Trans(R)은 원하는 키를 포함하는 R의 서브스트링(R'), 즉 "시작 K 중간 값 종료" 형태의 서브스트링을 출력하고, P는 Ropen = R'을 출력할 수 있다.
Figure pct00290
'는 규칙
Figure pct00291
*쌍에 의해 정의될 수 있으며, 여기서
Figure pct00292
는
Figure pct00293
'에 대한 생산 규칙에서의 시작 기호이다. 그 후, (1)
Figure pct00294
(R,R')는 R'가 R의 서브스트링인지를 검사하고, (2) S' = {
Figure pct00295
}에 대해,
Figure pct00296
(S',R',Ropen)는 (a) R'∈
Figure pct00297
' 및 (b) Ropen = R'임을 검사한다. 전역적으로 고유한 키들은 연령에 대한 응답을 선택적으로 오픈할 때와 같이 본 명세서의 일부 애플리케이션들에서 발생한다.
키-값 문법들의 수정. 지금까지, 본원의 2단계 파싱에 대한 설명은 P가 R의 서브스트링(Ropen)을 V에 드러내고 Ropen이 V에 의해 특정된 허용가능한 경로들의 세트에 대해 컨텍스트 무결성을 갖는다는 것을 증명하는 노출 모드를 가정한다. 수정 모드에서, 프로세스는 유사하나, Ropen을 분명하게 드러내는 대신, P는 전술된 기법들을 사용하여 Rope에 대한 커미트먼트를 생성하고 R을 드러내며, Ropen은 예를 들어, 이의 위치를 더미 문자로 대체함으로써 제거된다.
적용예들
본원에 개시된 DECO는 임의의 오라클 기반 적용예에 사용될 수 있다. 이의 범용성을 나타내기 위해, 본원은 이의 다양한 능력들을 활용하는 세 가지 예시적인 적용예들을 구현하고 평가했다: 1) 스마트 계약들에 의해 실현되는 기밀 금융 수단; 2) 레거시 크리덴셜들을 익명 크리덴셜들로 변환하는 것; 및 3) 프라이버시 보호 가격 차별 보고.
기밀 금융 상품. 파생 금융 상품들은 가장 일반적으로 인용된 스마트 계약 적용예들 중에 있으며, 인증된 데이터 피드들(예를 들어, 주식 가격들)에 대한 필요성을 예시한다. 예를 들어, 스마트 계약에서 구현하기 쉬운 하나의 대중적인 금융 수단은 바이너리 옵션이다. 이는 지정된 미래 시간, 예를 들어, 가까운 날 D의 가격 P*, 소정의 목표 자산 N의 가격이 동일하거나 이를 초과할 것인지, 즉, P*≥P인 것인지에 대해 베팅하는 두 당사자들 사이의 계약이다. 이 바이너리 옵션을 구현하는 스마트 계약은 오라클 O를 호출하여 결과를 결정할 수 있다.
원칙적으로, O는 체인 상의 이진 옵션에 대한 기본 자산 N 및 목표 가격 P를 은닉할 수 있다. 이는 단순히 옵션 상세 체인을 수락하고, 결과 Stmt := P*≥?P를 특정하는 비트만을 보고한다. 이 접근법은 Mixicle로서 지칭된다.
기본 Mixicle 구성의 한계는 O 자체가 금융 수단의 세부 사항을 학습한다는 것이다. DECO 이전에, 신뢰 실행 환경(trusted execution environments; TEE)들을 사용하는 오라클 서비스들만이 O로부터 질의들을 은닉할 수 있다. 이제 DECO가 금융 수단의 세부 사항, 즉 N 또는 P를 학습하지 않고 이진 옵션의 실행을 어떻게 지원할 수 있는지를 보여준다. ≥? 또는 ≤?는 무작위화될 수 있다. 또한, 당첨자 및 분실자 신원들 및 지불 금액들이 은닉될 수 있다. 다른 메타데이터, 예를 들어 정확한 결제 시간을 은닉하기 위해 추가적인 단계들이 취해질 수 있다.
이 예시적인 적용예에서, 옵션 승자는 P의 역할을 하고, O - 이는 V의 역할을 함 - 로부터 Stmt의 서명된 결과를 획득한다. 이제 본원은 프로토콜 및 이의 구현을 설명한다.
{skO,pkO}가 오라클의 키 쌍을 나타낸다고 하자. 이 실시예에서, 이진 옵션은 자산명 N, 임계 가격 P, 및 결제 날짜 D에 의해 특정된다. 본원은 메시지(M)의 커미트먼트를 CM = com(M, rM)이며 증인이 rM인 것으로 나타낸다.
도 11은 기밀 이진 옵션을 실행하는 두 당사자 Alice 및 Bob을 나타낸다. Alice는 주가 API에 액세스하기 위해 DECO를 사용하며, 그녀가 승리한 것을 확신(O)한다. 요청 및 응답의 예들은 우측에 도시되고, 도면의 이 부분에서 음영 텍스트는 수정될 민감한 정보이다.
도 11에 도시된 이진 옵션 프로세스는 다음의 단계들을 포함한다:
1) 셋업: Alice 및 Bob은 이진 옵션 {N, P, D}에 합의하고, 식별자 IDSC를 갖는 스마트 계약(SC)을 생성한다. 계약은 pkO, 당사자들의 어드레스들, 및 양 당사자들에게 알려진 증거들을 갖는 옵션 {CN,CP,CD}에 대한 커미트먼트들을 포함한다. 이들은 또한 공개 파라미터들 θP(예를 들어, 자산 가격들을 검색하기 위한 URL)에 합의한다.
2) 결제: Alice가 베팅에서 승리한다고 가정한다. 지불금을 청구하기 위해, 그녀는 DECO를 사용하여 검색된 현재 자산 가격이 그녀의 위치와 매칭한다는 ZKP를 생성한다. Alice 및 O는 DECO 프로토콜(O가 검증자로서 동작함)을 실행하여 θP(목표 URL)로부터 자산 가격을 검색한다. 본원은 응답이 (N*, P*, D*)를 포함하는 것으로 가정한다. 기점 θP를 증명하기 위한 DECO에서의 ZKP에 추가하여, Alice는 하기 명제를 증명한다:
Figure pct00298
Figure pct00299
.
성공적인 증명 검증 시에, 오라클은 계약 ID, S = Sig(skO,IDSC)와 서명된 명제를 반환한다.
3) 지불: Alice는 서명된 명제(S)를 계약에 제공하며, 이는 서명을 검증하고 승자에 지불한다.
Alice 및 Bob은 무결성을 위해 O를 신뢰할 필요가 있지만, 프라이버시를 위해서는 신뢰할 필요가 없다. 이들은 본 명세서의 다른 곳에서 설명된 바와 같이, 다수의 오라클을 사용함으로써 무결성 실패에 대해 더 헤지할 수 있다. 오라클에 대한 신뢰의 분산은 표준적이고 이미 전개된 기술이다. 모든 오라클이 악의적인 경우에도 DECO가 프라이버시를 보장한다는 것을 강조한다.
전술한 바와 같이, 도 11은 주가 API의 요청 및 응답을 도시한다. 사용자(P)는 또한 정확한 API 엔드포인트에 대한 액세스를 확신하기 위해 오라클(V)에 대한 HTTP GET 요청의 충분한 부분을 드러낼 필요가 있다. GET 요청은 몇몇 파라미터들 - API 엔드포인트와 같이 드러나는 몇몇 파라미터들, 및 주식 이름 및 개인 API 키와 같은 민감한 세부사항들을 갖는 다른 파라미터들을 포함한다.
Figure pct00300
는 여기에 공개된 기술을 사용하여 민감한 파라미터들을 삭제하고 V에게 나머지를 드러낸다. API 키는 V가 민감한 파라옴을 학습하는 것을 방지하기에 충분한 엔트로피를 제공한다. 추가적인 주의 없이, 부정행위(P)는 GET 요청의 의미론(semantics)을 변경할 수 있고, 여분의 파라미터들을 재작용함으로써 부정행위를 은닉할 수 있다. 이것이 발생하지 않음을 보장하기 위해, P는 구분자 "&" 및 분리자 "="가 수정된 텍스트에서 나타나지 않음을 증명할 필요가 있다.
Figure pct00301
및 R은 각각 응답 암호문 및 평문을 나타낸다고 한다. 옵션을 결제하기 위해, P는 V에게 R이 이전에 설명된 2단 파싱 방식을 사용하여 그 옵션에서 승리했다는 증거를 포함한다는 것을 증명한다. 제1 단계에서, P는 R을 국부적으로 파싱하고 V를 확신할 수 있는 R의 가장 작은 서브스트링을 식별한다. 제1 단에서, P는 R을 로컬로 파싱하고 V를 확신할 수 있는 R의 최소 스트링을 식별한다. 도 11 실시예에서, 주가 Rprice = "05.price":"1157.7500" 서픽스들을 수반한다. 제2 단에서, P는 ZK에서, 1) Rprice는
Figure pct00302
의 복호화의 서브스트링이고; 2) Rprice는 "05"로 시작하고; 3) 후속 문자들은 부동 소수점 수 P*를 형성하고 P*≥P이며, 4) com(P, rP)=Cp를 형성하도록 (Rprice,P,rP)의 지식을 증명한다.
이 2 단계 파싱은 키들이 고유하고 키 "05. price"가 가격이 뒤따른다고 가정하면 안전하고, 전술한 바와 같이, 이 응답의 문법을 고유 키들을 갖는 키-값 문법으로 만든다. 유사하게, P는 R에 포함된 주식 이름 및 날짜가 커미트먼트들과 일치한다는 것을 증명한다. CBC-HMAC 암호 스위트를 이용하여, 영지식 증명 회로는 전체 레코드(408 바이트)를 재작용하는 것, 커미트먼트들을 연산하는 것, 및 스트링 프로세싱을 수반한다.
HTTP GET 요청들(및 HTML)은 특별한 제한을 가진다: 키와 값(즉, 중간) 사이의 경계 및 키-값 쌍의 시작(즉, 시작)은 키 또는 값의 절대 서브스트링들이다. 이는 단일 연속 키 또는 값 이상을 교정하기 위해, P는 {중간, 시작}에서 문자들을 교정해야 한다는 것을 의미한다. 이에 따라, 본원은 (1)|R|=|R'|; 및 (2)
Figure pct00303
∈|R'|, R'[i] = D
Figure pct00304
R[i]
Figure pct00305
{중간, 시작} 또는 R[i] = R'[i] 중 어느 하나인지를 검사하는
Figure pct00306
(R, R')를 갖는다(D는 제자리 수정을 수행하기 위해 사용되는 더미 문자이다).
Figure pct00307
를 검사하는 것은 불필요하다.
레거시 크리덴셜 대 익명 크리덴셜: 연령 증명. 사용자 크리덴셜들은 종종 서비스 제공자의 환경 외부에서 액세스가능하지 않다. 일부 제공자들은 OAuth 토큰들을 통해 제3자간 API 액세스를 제공하지만, 이러한 토큰들은 사용자 식별자들을 나타낸다. DECO는 기존 시스템들에서 크리덴셜들을 보유하는 사용자들이 자신들에 관한 명제들을 익명으로 제3자들(검증자들)에게 증명할 수 있게 한다(이들은 "레거시 크리덴셜들"이라고 함). 이에 따라, 일부 실시예들에서 DECO는 사용자들이 서버측 지원 또는 신뢰 하드웨어 없이 임의의 웹 기반 레거시 크리덴셜을 익명 크리덴셜로 변환할 수 있게 한다.
도 12는 학생이 대학 웹사이트에 저장된 인구학적 크리덴셜을 사용하여 그녀/그의 연령이 18세를 넘음을 증명하는 본 출원의 예를 도시한다. 학생은 이러한 연령의 증거를 임의의 제3자, 예컨대 운전자의 라이센스를 발행하는 상태 또는 의료 시험에 대한 합의를 구하는 병원에 제공할 수 있다. AES-GCM 암호 스위트(cipher suite) 및 고유 키들에 기초한 최적화들을 갖는 2단 파싱을 사용하여 이 예를 구현한다.
도 12의 예에서, 대학 웹사이트에 저장된 학생의 인구통계학적 세부사항은 그 중에서도 이름, 생일, 학진 ID를 포함한다. 강조된 텍스트는 학생 나이를 포함한다. 레비얼 모드는 2단 파싱과 함께 사용된다. 증명자는 생일을 포함하는 6-7개의 AES 블록을 파싱하고, 그의 연령이 검증자에 대한 ZK에서 18세를 넘음을 증명한다. 다른 예와 같이, 생일을 둘러싼 고유한 HTML 태그로 인해, 이는 또한 고유한 키를 갖는 키-값 문법이다. 이진 옵션 애플리케이션과 유사하게, 이 예는 날짜 및 연산 연령을 파싱하기 위해 추가적인 스트링 프로세싱을 요구한다.
가격 차별화. 가격 차별화 상이한 구매자들에게 상이한 가격으로 동일한 제품 또는 서비스를 판매하는 것을 지칭한다. 유비쿼터스 소비자 추적은 온라인 쇼핑 및 예약 웹사이트들이 정교한 가격 식별, 예를 들어 고객 우편 번호들에 기초하여 가격들을 조정하는 것을 이용할 수 있게 한다. 가격 식별은 경제적 효율로 이어질 수 있고, 이에 따라 기존의 법률 하에서 광범위하게 허용된다.
그러나, 미국에서, FTC는 경쟁적 상해를 초래하는 경우 가격 식별을 금지하는 반면, GDPR과 같은 유럽에서의 새로운 프라이버시에 포커스가 맞춰진 법칙들은 실무의 합법성에 신중하게 집중하고 있다. 어떤 경우에도 소비자들은 일반적으로 가격 판별을 싫어한다. 그러나, 현재, 사용자들이 온라인 가격 판별을 보고하기 위한 신뢰할만한 방법은 없다.
도 13은 본 출원의 예를 도시하며, DECO는 구매자가 상품의 광고된 가격이 임계치보다 높다는 것을 증명함으로써 인지된 가격 차별에 대해 검증가능한 청구를 할 수 있게 하면서, 이름 및 주소와 같은 민감한 정보를 숨긴다. 본원은 TLS 세션을 위해 AES-GCM 암호 스위트를 사용하여 이 예를 구현하고, 필요한 순서 세부사항 및 요청 URL을 포함하는 24개의 AES 블록을 드러낸다.
도 13에 도시된 바와 같이, 쇼핑 웹사이트(예를 들어, 아마존) 상의 HTML 내의 주문 인보이스 페이지의 부분들은 구매자의 이름 및 주소와 같은 개인 세부사항들을 포함한다. 구매자는 제3자(검증자)에게 특정 날짜에 특정 제품의 청구 가격을 확신하기를 원한다. 이 예에서, 본원은 주문 송장 페이지의 상위 부분에서 필요한 텍스트를 드러내기 위해 AES-GCM 암호스위트 및 Reveal 모드를 사용하는 반면, 음영이 있는 구매자 이름, 주소 및 도시를 포함하는 하위 부분에서의 음영의 민감한 텍스트는 숨겨진다. 응답으로부터 드러난 AES 블록의 수는 20이다(긴 제품명으로 인해). 또한, 요청으로부터의 4개의 AES 블록은 정확한 종단점이 액세스되었음을 증명하기 위해 드러난다. 컨텍스트 무결성은 예를 들어, 아이템 가격 근처의 스트링 "<tr>전체 주문:" 주위의 고유 스트링을 전체 응답에서 단 한번만 나타냄으로써 보장된다.
구현 및 평가
이제 DECO 및 3개의 응용에 대한 구현 세부사항 및 평가 결과를 설명한다.
3-부분 핸드셰이크 및 질의 실행. 본원은 TLS 1.2에 대한 3자간 핸드셰이크 프로토콜(3P-HS)을 구현하고, C++ 코드의 약 4700 라인들에서 실행 프로토콜들(2PC-HMAC 및 2PC-GCM)을 질의한다. 본 발명자들은 779,213의 총 및 복잡도를 갖는 핸드-최적화된 TLS-PRF 회로를 구축하였다. 또한, 공지된 AES 회로의 변형을 사용하였다. 본원의 구현은 Paillier cryptosystem에 대한 Relic 및 악의적으로 안전한 2PC 프로토콜에 대한 EMP 툴킷을 사용한다.
본원은 3자간 핸드셰이크 및 2PC-HMAC 프로토콜을 대중적인 TLS 구현인 mbedTLS와 통합하여 종단간 시스템을 구축한다. 2PC-GCM은 더 많은 공학 노력으로 유사하게 TLS에 통합될 수 있다. 본 발명자들은 2PC-GCM의 성능을 개별적으로 평가하였다. 집적의 성능 영향은 무시할 수 있어야 한다. 본원은 TLS 1.3에 대해 3P-HS를 구현하지 않았으나, 회로 복잡도가 유사하기 때문에 성능은 TLS 1.2에 대한 성능과 비슷해야 한다고 믿어진다.
LAN 및 WAN 설정 모두에서 DECO의 성능을 평가하였다. 증명자 및 검증자 모두는 8 vCPU 코어들 및 16GB의 RAM을 갖는 c5.2xlarge AWS 노드 상에서 실행된다. 본원은 LAN 세팅에 대해 동일한 영역(그러나 상이한 가용성 구역들)에 2개의 노드들을 위치시켰지만, WAN 세팅에서 2개의 별개의 데이터 센터들(오하이오 및 오레곤에서)에 위치시켰다. LAN 및 WAN 내의 2개의 노드 사이의 왕복 시간은 각각 약 1ms 및 67ms이고, 대역폭은 약 1Gbps이다.
아래의 표 1은 TLS 세션 동안 DECO 프로토콜들의 런타임을 요약한다. 평균(괄호안)의 평균 및 표준 오차를 연산하기 위해 50개의 샘플을 사용하였다. 사용된 MPC 프로토콜은 성능을 개선하기 위해 오프라인 전처리에 의존한다. 오프라인 단계는 입력- 및 타겟-독립적이기 때문에, 이는 TLS 세션 이전에 행해질 수 있다. 온라인 단계만이 임계 경로 상에 있다.
Figure pct00308
표 1: 3P-HS의 실행 시간 및 질의 실행 프로토콜들. 모든 시간은 밀리초 단위이다.
표 1에 도시된 바와 같이, DECO 프로토콜은 LAN 설정에서 매우 효율적이다. 3자간 핸드셰이크를 완료하는데 0.37초가 걸린다. 질의 실행을 위해, 2PC-HMAC는 레코드 크기에 관계없이 2PC에서 하나의 SHA-2 평가만을 포함하기 때문에 효율적이다(레코드 당 0.13s). 2PC-GCM은 일반적으로 더 비싸고, 전체 질의에 대해 2 PC-AES를 포함하기 때문에, 비용은 질의 길이에 의존한다. 본원은 HTTP GET 요청에서 보이는 전형적인 크기인 256B 내지 2KB 범위의 질의로 그 성능을 평가하였다. LAN 설정에서, 성능은 효율적이고 2PC-HMAC에 필적한다.
WAN 설정에서, MPC가 많은 라운드의 통신을 포함하기 때문에 런타임은 네트워크 레이턴시에 의해 지배된다. 그럼에도 불구하고, DECO가 본원이 고려하는 대부분의 애플리케이션들에 대해 단지 주기적인 사용만을 볼 가능성이 있다는 점을 고려하면, 성능은 여전히 수용가능하다.
증명 생성. 본원은 libsnark에서 표준 증명 시스템으로 영지식 증명을 인스턴스화하였다. 본원은 효율적으로 증명가능한 명제 템플릿들을 고안하였지만, DECO의 사용자들은 이들을 이들의 특정 적용예들에 적응시킬 필요가 있다. SNARK 컴파일러들은 개발자들에게 하위 레벨 세부 사항들을 감추면서 상위 레벨 언어로 이러한 적응을 가능하게 한다. 본원은 xjsnark 및 이의 자바와 같은 상위 레벨 언어를 사용하여 명제 템플릿들 및 libsnark 호환 회로들을 구축하였다.
libsnark를 선택하는데 있어서의 본원의 근거는 상대적으로 성숙한 툴링 서포트이다. libsnark에 의해 생성된 증명은 일정한 크기이고 검증하는데 매우 효율적이며, 그 단점은 회로당 신뢰 설정이다. 더 많은 노력으로, DECO는 신뢰성 있는 셋업을 필요로 하지 않지만 큰 증거 및 검증 시간을 갖는 예를 들어, Bulletproof를 사용하도록 구성될 수 있다.
본원은 각 예에 대한 5개의 성능 메트릭, 즉, 증명자 시간(프러프를 생성하기 위한 시간), 검증자 시간(증명을 검증하기 위한시간) 증명 크기, 회로에서의 산술 제약의 수, 및 증명 생성 동안의 피크 메모리 사용을 측정한다.
하기 표 2는 결과를 요약한다. 평균 및 그 표준 오차를 연산하기 위해 50개의 샘플을 사용하였다. 효율적인 명제 템플릿 및 2-단계 파싱의 사용을 통해, DECO는 매우 실용적인 증명자 성능을 달성한다. libsnark는 낮은 검증 오버헤드를 위해 최적화되기 때문에, 검증자 시간은 무시할 수 있다. 제약들의 수(및 증명자 시간)는 여분의 스트링 파싱 루틴들로 인해 이진 옵션 애플리케이션에 대해 가장 높다. 피크 메모리 사용을 감소시키기 위해 각 애플리케이션에서 다수의 증명을 사용한다. 가장 복잡한 애플리케이션에 대해, 메모리 사용은 1.78GB이다. libsnark 증명은 일정한 크기 287B이므로, 도시된 증명 크기는 그 배수이다.
Figure pct00309
표 2: 적용예들에 대한 DECO의 증명 생성 단계에서 ZKP들을 생성하고 검증하는 비용
종단간 성능. DECO 종단간 성능은 이용가능한 TLS 암호 스위트들, 비공개 데이터의 크기, 및 애플리케이션 특정 증명의 복잡도에 따른다. 여기서, 본원은 본원이 구현한 세 가지 중 가장 복잡한 적용예 - 이진 옵션 - 의 종단간 성능을 제시한다. 프로토콜을 종료하는 데 약 13.77s가 소요되며, 이는 위조 불가능한 커미트먼트를 생성하는 데 소요되는 시간(0.50s), 2단 파싱의 제1 단을 실행하는 데 소요되는 시간(0.30s), 영지식 증명을 생성하는 데 소요되는 시간(12.97s)을 포함한다. 이러한 숫자들은 LAN 설정에서 연산된 것이며; WAN 설정에서, MPC 프로토콜들은 시간이 더 많이 소요되며(5.37s) 종단간 시간을 18.64s까지 늘린다.
이와 비교하여, Town Crier는 TEE를 사용하여 유사한 적용예를 약 0.6s 내ㅇ에, 즉, DECO보다 약 20x 빠르게 실행하지만, 신뢰 가정들이 추가된다. DECO는 대부분의 적용예들에 대해 단지 주기적으로 사용될 가능성이 있기 때문에, 암호 강도 보안 보장을 달성하는 데 있어서의 이의 오버헤드는 합리적인 것으로 보인다.
법 및 규정 준수 문제들
사용자들이 웹사이트들로부터 이들의 데이터를 이미 검색할 수 있지만, DECO는 사용자들이 이들의 명백한 승인 또는 심지어 인식 없이 무결성 증명들을 갖는 데이터를 내보내는 것을 허용한다. 이제, 결과적인 법적 및 컴플라이언스 고려사항들을 간략하게 논의한다.
그러나, 중요하게는 DECO 사용자들은 무결성 보장으로 제3자에게 데이터를 일방적으로 내보낼 수 없지만, 이러한 목적을 위한 검증자들로서 오라클에 의존한다. DECO가 사용자 데이터를 비공개로 유지하는 동안, 오라클은 사용자가 액세스하는 데이터의 어떤 웹사이트들 및 유형들을 학습한다. 이에 따라, 오라클은 적절한 데이터 사용, 예를 들어 저작권 침해를 초래할 수 있는 트랜잭션들을 거부하는 것을 시행할 수 있다.
사용자들 및 오라클 양자는 이들이 액세스하는 데이터에 대한 법적 책임을 갖는다. 그러나, CFAA(Computer Fraud and Abuse Act)에 대한 최근의 판례법은 웹 스크래핑(web scraping)의 범죄로부터의 변화를 보여주고, 연방 법원은 웹사이트의 서비스 약관을 위반하는 것은 그 자체로 범죄 행위가 아니라고 판결했다. 대신, 웹사이트 서비스 약관, 예를 들어, "클릭 랩(click wrap)" 약관을 위반하는 사용자들 및 오라클은 대신에 민사 처벌을 받을 수 있다. 소정의 사이트의 서비스 약관에 대한 DECO 준수는 사이트별 및 애플리케이션별 문제이다.
오라클은 스마트 계약 및 다른 생태계 내에서 신뢰할 수 있는 기업으로 자리 매김하도록 장려된다. 본원은 평판이 좋은 오라클이 사용자에게 그들이 발행한 특정 증명의 메뉴와 그들이 허용하는 타켓 웹사이트를 제공할 것으로 기대하며, 이러한 옵션을 검토하여 보안을 최대화하고 책임을 최소화하고 타켓 서버에 알리거나 협력할 수 있을 것으로 기대한다.
부정확한(및 잠재적으로 뒤엎어질 수 있는) 데이터를 기반으로 한 부정확한 증명의 법적, 성능 및 규정 준수 영향도 중요하다. 그러나, 오늘날 인터넷 서비스는 복잡한 다중 사이트 데이터 종속성을 가지므로, 이러한 문제는 DECO에만 국한되지 않는다. 오라클 서비스는 정확성을 보장하기 위해 이미 여러 데이터 소스에 의존하고 있다. 일반적으로 오라클 서비스는 궁극적으로 온라인 검사 및 해지 기능, 다양한 보안 계층을 포함하여 인증서에 대한 것과 같은 인프라스트럭처를 생성할 수 있다.
본 명세서에 개시된 예시적인 실시예들에서의 DECO는 신뢰된 하드웨어 또는 서버측 수정들을 요구하지 않는 현대 TLS 버전들에 대한 프라이버시 보호, 비집중형 오라클 스킴이다. DECO는 증명자가 TLS 세션에 대한 위조 불가능한 커미트먼트를 생성하고 세션 컨텐츠에 대한 명제를 효율적으로 증명할 수 있게 한다. 일부 실시예들은 새로운 2단 파싱 방식을 이용하여, 프라이버시 보호 오라클에 보편적인 컨텍스트 무결성 공격들을 완화시킨다. DECO는 중앙 집중형 웹 서비스 사일로로부터 데이터를 해제시킬 수 있고, 이는 다양한 애플리케이션에 액세스할 수 있게 한다. DECO의 실용성은 3개의 예시적인 애플리케이션과 함께 완전히 기능적인 구현을 통해 본 명세서에서 증명된다.
GCM에 대한 프로토콜 상세
GCM은 추가 데이터(AEAD) 암호를 갖는 인증된 암호화이다. 암호화를 위해, GCM 암호는 입력으로서 투플(tuple)(k,IV,M,A): 비밀 키, 초기 벡터, 다수의 AES 블록의 평문, 및 무결성 보호에 포함될 추가 데이터를 취하고; 이는 암호문 C를 출력하고 태그 T를 출력한다. 해독은 프로세스를 역으로 수행한다. 해독 암호는 입력(k,IV,C,A,T)으로서 취하며, 먼저 재연산된 태그를 T와 비교함으로써 암호문의 무결성을 검사한 다음, 평문을 출력한다.
암호문은 카운터 모드에서 연산된다:
Figure pct00310
, 여기서
Figure pct00311
는 i 시간에 대해 IV를 증분시키는 것을 나타낸다.
태그 Tag(k,IV,C,A)는 다음과 같이 연산된다. 벡터
Figure pct00312
이 주어지면, 연관된 GHASH 다항식
Figure pct00313
는
Figure pct00314
에서 곱셈이 행해짐)로 정의된다. 일반성의 손실 없이,
Figure pct00315
및
Figure pct00316
가 적절하게 패딩된다고 가정하자. lA 및 lC가 이들의 길이를 나타낸다고 하자. GCM 태그는
Figure pct00317
(1)
여기서 h는 AES(k,0)이다.
GCM이 TLS에서 사용될 때, 각 평문 레코드 D는 다음과 같이 암호화된다. 고유 넌스(n)가 선택되고, 추가 데이터(K)가 시퀀수 수, 버전, 및 D의 길이의 연쇄으로서 연산된다. GCM 암호화는 페이로드 레코드를
Figure pct00318
로서 생성하기 위해 호출된다.
GCM에 관한 추가적인 세부사항은 예를 들어, Morris J Dworkin, SP 800-38d, "Recommendation for block cipher modes of operation: Galois/counter mode (GCM) 및 GMAC," Technical Report, 2007에서 찾아볼 수 있으며, 이는 본 명세서에 참조로 포함된다.
질의 실행
태그 생성/검증. GCM 태그를 연산 또는 검증하는 것은 2PC에서 상기 식 (1)을 평가하는 것을 수반한다. 문제는 식 (1)은 산술 연산(예를 들어,
Figure pct00319
에서의 다항식 평가)뿐만 아니라 이진 연산(예를 들어, AES) 양자를 수반한다는 것이다. 이진 회로에서 큰 필드에서 곱셈을 수행하는 것은 비용이 많이 드는 반면,
Figure pct00320
에서 AES(GF(28)에서 정의됨)를 연산하는 것은 높은 오버헤드를 초래한다. 연산이 어떻게든 2개의 회로들로 분리될 수 있을지라도, 각 레코드에 대해
Figure pct00321
에서 대략 1,000 곱셈들을 취하는 다항식만을 평가하는 것은 과도하게 비싸다.
본 프로토콜은 다항식 평가에 대한 필요성을 제거한다. 실제2PC 프로토콜은 이진 연산만을 수반하므로 단일 회로에서 행해질 수 있다. 또한, 기록당 연산은 2PC-AES의 단 하나의 호출로 감소된다.
이는 세션의 시작에서 전처리 단계에서 (2PC 프로토콜에서) {hi}의 공유를 연산함으로써 달성된다. 프리프로세싱의 오버헤드는 동일한 h가 후속하는 모든 레코드들에 대해 사용되기 때문에 세션에 대해 최적화된다. {hi}의 공유분들과 함께, P 및 V는 다항식 평가의 공유분들
Figure pct00322
을 로컬로 계산할 수 있다. 이들은 또한 Tag(k, IV,
Figure pct00323
,
Figure pct00324
)의 공유분을 얻기 위해 2PC에서 AES(K, IV)를 연산한다. 전체적으로, 각 레코드에 대한 태그를 검사하기 위해 2PC-AES의 단 하나의 호출만이 필요하다.
V는 절대 동일한 IV에 한 번보다 많이 응답하지 않고; 그렇지 않으면, P가 h를 학습할 것이라는 것이 중요하다. 각 응답에서, V는
Figure pct00325
의 형태로 그녀의 공유분들 {
Figure pct00326
}의 블라인드된 선형 조합을 나타낸다. {
Figure pct00327
}의 단일의 언블라인딩된 선형 조합이 P가 h에 대해 해결하도록 허용하기 때문에, 값이 블라인딩되는 것이 중요하다. 따라서, V가 동일한 IV에 두 번 응답하는 경우, (
Figure pct00328
에서) 두 개의 응답들을 더함으로써 블라인딩이 제거될 수 있다:
Figure pct00329
. 이는 GCM의 넌스 고유성 요건으로부터 이어진다.
레코드를 암호화/복호화하는 단계. 태그들이 적절하게 검사되면, 레코드들의 해독은 간단하다. P 및 V는 단순히 2PC-AES를 갖는 inc'(IV)의 AES 암호화를 연산한다. V는 암호화될 카운터가 이전에 IV로서 사용되지 않았는지를 검사해야 한다는 점에 주목하기가 미묘하다. 그렇지 않으면, P는 위에서 설명된 것과 같은 방식으로 P에 대해 h를 학습할 것이다.
증명 생성
블록을 철회한다. P는 AES 블록 Bi가 암호화된 레코드
Figure pct00330
내의 i번째 블록이라는 V를 확신하기를 원한다. 증명 전략은 다음과 같다: 1) AES 블록 Bi가 암호문 블록
Figure pct00331
로 암호화한다는 것을 증명하고, 2) 태그가 정확하다는 것을 증명한다. 정확한 암호화를 제공하는 것은 ZKP에서 단지 1개의 AES를 요구한다. 나이브하게 행해졌고, 정확한 태그를 증명하는 것은 ZKP에서 차수 512 및 2 AES 블록 암호화들의 GHASH 다항식을 평가하는 것을 초래한다.
P가 2개의 암호화된 메시지 AES(k,IV) 및 AES (k,0) 내지 V를 드러내도록 하여 V가 태그를 검증하도록 함으로써 훨씬 더 효율적인 증명을 달성하는 것을 관리한다(수학식 1 참조). P는 ZK에서의 암호화의 정확성을 증명하기만 하면 되고, 사용된 키는 커미트먼트에 대응하며, 2개의 AES 및 1개의 SHA-2를 요구한다(P는 키의 해시를 드러냄으로써 kP에 커밋한다). 이에 따라, 총 비용은 ZKP에서 3 AES 및 1 SHA-2이다.
TLS 레코드 노출. 증명 기술은 상기 경우에서의 간단한 확장이다. P는 전체 레코드(rec)를 나타내고 모든 AES 블록의 정확한 AES 암호화를 증명하여, ZKP에서 총 514 AES 및 1 SHA-2를 초래한다.
블록을 제외한 TLS 레코드 노출. 상기 경우와 유사하게, P는 1을 제외한 레코드 내의 모든 블록의 암호화를 증명하여, ZKP 내의 총 513 AES 및 1 SHA-2를 초래한다.
프로토콜 확장
TLS 1.3에 적응. TLS(1.3)를 지원하기 위해, 3P-HS 프로토콜은 새로운 핸드셰이크 흐름 및 상이한 키 유도 회로에 적응되어야 한다. 특히, ServerHello 이후의 모든 핸드셰이크 메시지는 이제 암호화된다. 나이브 전략은 2PC에서 이들을 해독하는 것이고, 이는 인증서가 일반적으로 크기 때문에 비용이 많이 들 것이다. 그러나, TLS 1.3의 키 독립 특성으로 인해, P 및 V는 최종 세션 키들의 비밀성에 영향을 주지 않고 핸드셰이크 암호화 키들을 안전하게 드러낼 수 있다. 핸드셰이크 무결성은 완료 메시지가 또 다른 독립적인 키를 이용하여 핸드셰이크를 인증하기 때문에 보존된다.
이에 따라, 최적화된 3P-HS는 다음과 같이 작동한다. P 및 V는 이전과 동일하게 ECDHE를 수행한다. 그 후, 이들은 2PC-HKDF를 실행함으로써 핸드셰이크 및 애플리케이션 키를 도출하고, 핸드셰이크 키를 P로 드러내어, P가 핸드세이크 메시지를 국부적으로(즉, 2PC 없이) 복호화할 수 있게 한다. 2PC 회로는 SHA-256의 대략 30개의 호출을 수반하며, 총 약 70k 및 게이트가 TLS 1.2에 대한 것과 비슷하다. 마지막으로, CBC-HMAC는 TLS 1.3에 의해 지원되지 않기 때문에, DECO는 GCM 모드에서만 사용될 수 있다.
질의 구성은 선택적이다. 질의들에 대한 응답들을 바인딩하는 애플리케이션들에 대해, 예를 들어, 주식 티커가 상기 견적과 함께 포함될 때, 2PC 질의 구성 프로토콜들은 완전히 회피될 수 있다. TLS는 각 통신 방향에 대해 별개의 키들을 사용하기 때문에, P가 V와 상호작용하지 않고 서버에 질의할 수 있도록 핸드셰이크 후에 클라이언트 대 서버 키들이 P에 드러날 수 있다.
다중 라운드 세션 지원. DECO는 P가 이전 응답들에 따라 추가 질의들을 송신하는 멀티-라운드 세션들을 지원하도록 확장될 수 있다. 각 라운드 후에, MAC 검증 및 생성이 대칭이기 때문에, P는 착신 응답들의 MAC 태그들을 검증하기 위해 상기와 유사한 2PC 프로토콜들을 실행한다. 그러나, P가 MAC 검증을 포기하여 태그를 위조하는 것을 방지하기 위해 추가적인 커미트먼트가 요구된다.
TLS에서, 상이한 MAC 키들이 서버 대 클라이언트 및 클라이언트 대 서버 통신을 위해 사용된다. 멀티-라운드 세션들을 지원하기 위해, P 및 V는 2PC를 구동하여 전자에 대한 태그들을 검증하고, 후자에 대한 새로운 메시지들 상에 태그들을 생성한다. 본 명세서의 이전 설명은 MAC 태그를 생성(및 검증)하기 위한 프로토콜을 특정하였다. 이제, 다중-라운드 세션들에 대한 추가적인 보안 고려사항들을 논의한다.
서버 대 클라이언트 메시지에 대한 태그를 검사할 때, 본원은 P가 서버로부터 원래가 아닌 메시지에 태그를 위조할 수 없음을 보장해야 한다. P가 메시지 M 상의 태그 T를 검증하기를 원한다고 가정하자. 우리는 P가 T에 우선 커밋한 다음, P 및 V는 2PC 프로토콜을 실행하여 메시지 M 상에서 태그 T'를 연산한다. P는 V에 커미트먼트를 개방할 것이 요청되고 T ≠ T'인 경우, V는 프로토콜을 중단한다. P는 MAC 키를 알지 못하기 때문에, P는 서버로부터가 아닌 메시지에 대한 태그를 연산하고 커밋할 수 없다.
클라이언트 대 서버 메시지들에 대한 태그들을 생성할 때, V는 MAC 태그들이 TLS에 의해 요구되는 바와 같이, 증가하는 시퀀스 번호들을 갖는 메시지들 상에서 생성되게 한다. 이는 또한 악의적인 P가 동일한 시퀀스 번호를 갖는 2개의 메시지들을 생성하는 것을 방지하는데, 이는 V가 어느 것이 서버로 송신되었는지를 구별하는 방법이 없기 때문이다.
대안적인 DECO 프로토콜: 프록시 모드. 표 1에 도시된 바와 같이, DECO의 HMAC 모드는 매우 효율적이고, 2PC에서 HMAC 태그를 생성 및 검증하는 런타임은 레코드 크기에 독립적이다. GCM 모드는 전처리를 갖는 작은 요청에 효율적이지만, 큰 레코드에 대해서는 비용이 많이 들 수 있다. 본원은 이제 사후-핸드셰이크 2PC 프로토콜을 완전히 회피하는 매우 효율적인 대안을 제시한다.
이러한 대안에서, 검증자(V)는 증명자(P)와 TLS 서버(S) 사이의 프록시로서 작용하는데, 즉, P는 메시지를 V를 통해 S로/로부터 발신/수신한다. DECO 프로토콜의 수정된 흐름은 다음과 같다: 3자간 핸드셰이크 후, P는 그녀의 키 공유
Figure pct00332
를 커밋하고 V는
Figure pct00333
를 P에게 드러낸다. 따라서 P는 이제 전체 세션 키
Figure pct00334
를 갖는다. P가 서버와의 세션을 계속하기 위해
Figure pct00335
를 사용하기 때문에, V는 프록시 트래픽을 기록한다. 세션이 종료된 후, P는 이전과 동일하게 기록된 세션에 대한 명제를 증명한다.
이러한 실시예에서, 3자간 핸드셰이크는 불편함을 제공한다. CBC-HMAC와 달리, GCM은 위탁되지 않는다: 주어진 암호문 및 키 k로 암호화된 태그(C,T)에 대해, 동일한 태그를 연산하면서 C를 상이한 평문으로 복호화하는 k' ≠ k를 발견할 수 있는데, 이는 GCM MAC가 충돌 방지되지 않기 때문이다. 이러한 공격을 방지하기 위해, 상기 프로토콜은 세션 키를 학습하기 전에 P가 자신의 키 공유분에 커밋할 것을 요구한다.
이제 프록시 모드 프로토콜에 관한 보안 속성들 및 네트워크 가정들이 설명될 것이다. 검증자 무결성 및 프라이버시 속성들은 (가정에 의해) 악의적인 V가 TLS의 무결성 및 프라이버시를 깨뜨릴 수 없기 때문에 분명하다.
그러나, 증명자 무결성을 위해, 프록시가 세션 전체에 걸쳐 S에 신뢰성 있게 접속할 수 있다고 가정할 필요가 있다. 먼저, 프록시가 실제로 S와 연결되어 있는지 확인할 수 있다고 가정한다. 더욱이, 프록시와 S 사이에 송신된 메시지들은 세션 키들을 알고 이에 따라 세션 컨텐트를 수정할 수 있는 P에 의해 변조될 수 없다고 가정한다.
3자간 핸드셰이크 동안, V는 (표준 TLS에서) 새로운 넌스를 통해 서버의 서명을 검사함으로써 서버의 아이덴티티를 확인할 수 있다는 점에 유의한다. 그러나, 핸드셰이크 후에, V는 IP 어드레스들과 같은 네트워크-계층 표시자들에 의존해야 한다. 실제로, V는 이에 따라 정확한 최신 DNS 기록들을 가져야 하고, V와 서버(예를 들어, 이들의 ISP 및 백본 네트워크) 사이의 네트워크는 예를 들어, BGP(Border Gateway Protocol) 공격들을 통해, 트래픽 주입에 대해 적절하게 보안되어야 한다. 도청은 일반적으로 예시적인 실시예에서 문제가 되지 않는다.
이러한 가정은 BGP 공격이 실제로 장착되기 어렵기 때문에 유사한 프록시 설정에서 다른 시스템에 의해 포함된다. 본원은 검증자 노드들을 지리적으로 분산시킴으로써 트래픽 인터셉션에 대해 본원의 프로토콜을 더 향상시킬 수 있다. 더욱이, 다양한 알려진 검출 기술들이 검증자들에 의해 전개될 수 있다. 종종 BGP 공격들은 사실 이후에 문서화되며, 이에 따라, 적용가능할 때, DECO의 애플리케이션들은 영향을 받은 세션들의 노출을 지원하기 위해 강화될 수 있다(예를 들어, DECO가 아이덴티티 시스템에서 크리덴셜들을 발행하기 위해 사용될 때).
이러한 대안적인 프로토콜은 상이한 성능-보안 트레이드오프를 나타낸다. 이는 핸드셰이크 후에 집중적인 암호화가 발생하지 않기 때문에 매우 효율적이지만, 네트워크에 대한 추가적인 가정들을 요구하고 이에 따라 더 약한 네트워크 적대자만을 저항한다.
키-값 문법 및 2단 파싱
예비 및 표기법. 본원은 컨텍스트 프리 문법(context-free grammar: CFG)을
Figure pct00336
=(V,Σ,P,S)로 표시하며, 여기서 V는 비종단 심볼의 세트이고, Σ는 종단 심볼의 세트이며,
Figure pct00337
은 프로덕션 또는 규칙의 세트이고 S∈V는 시작 심볼이다. 세트를 마이너스로 나타내기 위해 '-'를 사용하고 범위를 나타내기 위하여 '..'를 사용하여 표준 표기로 CFG들에 대한 생산 규칙들을 정의한다. 스트링 w에 대해, 파서는 w에 대한 파스 트리를 구성함으로써 w∈
Figure pct00338
인지를 결정한다. 파스 트리는 의미 체계를 추출하는 데 사용할 수 있는 일련의 생산 규칙을 나타낸다.
키-값 문법들. 이들은 키-값 쌍들의 개념을 갖는 문법들이다. 이들 문법은 대부분의 API 호출 및 응답이 사실상 키-값 문법이기 때문에 DECO에 특히 흥미롭다.
Figure pct00339
는 문법(H)이 존재하는 경우 키-값 문법(key-value grammar)이라고 하며, 주어진 s∈
Figure pct00340
, s∈H, 및 H는 다음의 규칙에 의해 정의될 수 있다:
S → 오브젝트
오브젝트 → noPairsString 개방 쌍들 폐쇄
쌍 → 시작 키 중간 값 종료
쌍들 → 쌍 쌍들 | ""
키 → 문자들
값 → 문자들 | 오브젝트
문자들 → 문자 문자들 | ""
문자 → 유니코드-이스케이프됨 | 이스케이프 이스케이프됨 | addedChars
특수 → startSpecial | middleSpecial | endSpecial
시작 → unescaped startSpecial
중간 → unescaped middleSpecial
종료 → unescaped endSpecial
이스케이프됨 → 특수 | 디스케이프 | ...
상기에서, S는 시작 비종단이고(H에서 문장을 나타냄), 비커미널들은 키-값 쌍들의 세트의 개방 및 폐쇄를 구분하고, 시작, 중간, 종료는 키-값 쌍의 시작, 키와 값 사이의 분리 및 쌍의 끝을 각각 구분하는 특수 스트링들이다.
특수 문자들, 즉 문법을 파싱할 때 특수 의미를 갖는 문자들을 파싱할 때의 모호성을 제거하기 위해, 특수 비종단 이스케이프가 사용된다. 예를 들어, JSON에서, 키들은 '화이트스페이스 더블 시세들(whitespace double quotes)'(")이 선행하고 더블 시세들이 후행할 때 파싱된다. 키 또는 가치 표현 자체가 이중 시세를 포함해야 하는 경우, 이들은 백슬래시(＼)에 의해 선행되어야 하며, 즉, 이스케이프되어야 한다. 상기 규칙들에서, 특수 문자들 이전에 시작되지 않은 비종단은 이들이 특수 문자들로서 파싱될 수 있다는 것을 의미한다. 이에 따라, 앞으로 이동하면, 키-값 쌍의 생성이 명확하다고 가정할 수 있다. 이에 따라, 키-값 문법(
Figure pct00341
) 내의 스트링(R)의 서브스트링(R')이 쌍으로서 파싱하면, R'은 R의 파싱 트리 내의 쌍에 대응해야 한다.
상기 키-값 문법에서, 중간은 빈 스트링을 도출할 수 없는데, 즉, 비빈 스트링은 값들로부터 키들을 파싱하는 것을 허용하기 위해 중간을 마킹해야 한다. 그러나, 시작 및 종료 중 하나는 빈 유도를 가질 수 있는데, 그 이유는 이들이 단지 한 쌍에서의 값 사이의 분리를 다음에서의 키로부터 구분하기 때문이다. 마지막으로, 일부 실시예들에서 키-값 문법들에 대한 2단 파싱에서, 선택적으로 오픈된 스트링(Ropen)이 쌍에 대응한다는 요건을 갖는 허용가능한 경로들만을 고려한다는 점에 유의한다.
로컬 고유 키에 대한 2 단계 파싱. 많은 키-값 문법들은 범위 내에서 키 고유성을 강화한다. 예를 들어, JSON에서, 오브젝트들에 걸쳐 중복된 키들이 존재할 수 있지만, 키들이 JSOn 오브젝트 내에서 고유한 것으로 가정될 수 있다. 이러한 문법들에 대한 2-단계 파싱은 서브스트링을 파싱하는 것으로 감소될 수 있다. 구체적으로, 트랜스는 R로부터 연속적인 서브스트링 R'을 추출하여, 한 쌍의 범위가 R' 내에서도 정확하게 결정될 수 있다. 예를 들어, JSON에서,
Figure pct00342
(R,R')가 R의 프리픽스인 경우에만 참으로 리턴하면, R'를 JSON으로서 파싱하는 것만이, Ropen을 산출하는 서브-트리를 생성하기까지, 스트링 Ropen이 R에서의 정확한 컨텍스트에 대응하는지 여부를 결정하기에 충분하다.
고유 키 갖는 문법. 키-값 문법(
Figure pct00343
)이 주어지면, 본원은
Figure pct00344
로 표시된 키들의 고유성을 검사하는 기능을 정의한다. 스트링 s∈
Figure pct00345
및 다른 스트링 k가 주어지면, 시작 k 중간으로서 파싱될 수 있는 s의 최대 하나의 서브스트링이 존재하는 경우에만
Figure pct00346
(s,k)=참이다. s∈
Figure pct00347
는 s의 임의의 파스 트리에서, 노드 키 및 유도 k를 갖는 최대 하나의 분기가 존재한다는 것을 의미하기 때문에, 파서
Figure pct00348
는 그 입력이 문법
Figure pct00349
에 있다면 참을 반환하는 함수라고 한다. 본원은 모든 s∈
Figure pct00350
에 대해 그리고 가능한 키 값들 k에 대해
Figure pct00351
(s,k)=참인 경우, 즉, 모든 스트링들 R, C에 대해 다음과 같은 경우,
Figure pct00352
가 고유한 키들을 갖는 키-값 문법이라고 한다:
Figure pct00353
.
고유 키 문법들에 대한 구체적 2단 파싱. U를 위에서 주어진 바와 같은 고유-키 문법이라고 한다. U가 LL(1)이라고 가정한다. 이는 예를 들어 이전에 설명된 관심 문법들의 경우이다. 일반적인 LL(1) 파싱 알고리즘은 공지되어 있다.
본원은 세트 T에 대한 컨텍스트 함수 CTXU를 개시하여, T가 U에서의 스트링들에 대한 쌍에 대한 허용 가능한 경로들을 포함하게 됨을 개시한다. 또한, CTXU가 보조 제한, 키 k(P의 지정된 키 출력 Ropen)를 입력으로서 취하도록 허용한다. 투플(T,k)은 S 및 CTXU(S, ·, ·) CTXU,S로서 나타내어진다.
P는 규칙 SP → 쌍에 의해 주어진 문법이라고 하고, 여기서 쌍은 U에 대한 생성 규칙에서 비종단이고 SP는 P에서의 시작 심볼이다. 본원은 파서P, k를 스트링 s가 P에 있는지 여부를 결정하고 만약 그렇다면, s에서의 키가 k와 동일한지 여부를 결정하는 함수로서 정의한다. 입력, R, Ropen, CTXU,S에 대해: (a) 파서P, k를 실행함으로써 Ropen이 키(k)를 갖는 유효한 키-값 쌍인지 (b) 파서 R에 LL(1) 파싱 알고리즘을 실행함으로써 R에서의 키-값 쌍으로서 파싱하는지를 검사한다.
도 14는 함수 CTXU,S가 키-값 문법(U)에서 스트링(R)을 파싱하고 특정 키-값 쌍(Ropen)의 생성을 검색하기 위한 예시적인 의사코드를 도시한다. 여기서, PTable, U에 대한 LL(1) 파스-테이블은 CTXU,S로 하드 코딩된다.
긴 스트링(R)에 대한 CTXU,S의 고가의 연산을 피하기 위해, R의 서브스트링(R')을 추출하기 위해 변환(Trans)를 도입하여, 필요 조건에 따라 R'=Ropen이 된다.
스트링(s,t)에 대해, t가 s의 서브스트링이면 참으로 복귀하는 함수 서브스트링을 정의하고, s=t이면 참으로 복귀하는 함수(s,t)를 정의한다. consU,P를 다음과 같은 규칙으로 정의한다.
Figure pct00354
그리고 S'={SP}. 이는 CTXP((R',Ropen)일 때는 언제든 S, R', Ropen = 참임 그리고 다음 규칙을 의미한다.
Figure pct00355
는 모든 스트링들 S, R', Ropen에 대해 유지된다.
Figure pct00356
가 S에 대해 정확한 것으로 제시될 수 있다. 특히, R'가 R의 서브스트링이면, 키-값 쌍 Ropen은 파서P에 의해 파싱되고, 동일한 쌍은 U의 서브스터링이어야 한다. U에서의 키들의 전역적 고유성에 기인하여, 단지 하나의 그러한 쌍 Ropen이 존재하고
Figure pct00357
는 참이어야 한다.
본 명세서의 다른 곳에서 설명된 것과 같이, 상기 추가적인 프로토콜 상세들은 단지 예시적인 예로서 제시되며, 어떠한 방식으로도 제한하려는 의도는 아니다. 다른 실시예들은 본 명세서에 개시된 바와 같이 분산된 오라클을 구현하는데 있어서 대안적인 프로토콜 장치들을 이용할 수 있다.
전술한 바와 같이, 본 명세서에 개시된 바와 같은 분산형 오라클의 예시적인 실시예들은 매우 다양한 상이한 애플리케이션들에서 구현될 수 있다.
예를 들어, DECO는 사용자가 자신의 개인 데이터를 제어하고 판매하는 개인 데이터 시장을 구현하는데 사용될 수 있다. 웹 서비스는 사용자 데이터를 수익화하는 것으로부터 이익을 얻는다는 것은 잘 알려져 있다. 본 명세서에 개시된 기술을 사용하여 구현되는 개인 데이터 마켓플레이스는 사용자가 오픈 마켓플레스에서 이들의 데이터를 판매할 수 있게 함으로써 이 데이터 모노폴리를 방해할 수 있다. DECO는 구매자들이 웹사이트들로부터의 데이터의 기원 및 무결성을 검증할 수 있게 하기 때문에 예시적인 실시예들에서 개인 데이터 시장에 대한 핵심 인에이블러이다. DECO는 또한 판매자가 사생활 보호를 위해 데이터, 예를 들어 민감한 정보를 재실행하는 것을 사전 처리하는 것을 허용하면서 판매자가 치명적인 것을 방지한다. 일부 구현들은 가격 판별에 대해 검증가능한 청구항들을 제공하기 위해 DECO를 이용한다.
다른 예로서, DECO는 재정적 해결의 증거를 제공하기 위해 사용될 수 있다. DECO를 갖는 이러한 유형의 장치의 보다 특정한 예시로서, Alice는 Bob에게 특정 은행과의 그녀의 균형이 $5000보다 크다는 것을 증명할 수 있다. 이러한 간단한 증명은 Alice의 재정적 해결뿐만 아니라 계좌를 여는 그녀의 능력을 보여준다(예를 들어, 은행이 대여방 세탁(AML) 스크리닝을 수행할 때, Alice는 임의의 제재 목록 상에 있지 않음). 중요하게는 DECO는 그녀의 잔액이 $5,000보다 높다는 사실만을 드러냄으로써 Alice의 프라이버시를 보호하고, 그녀의 실제 잔액 또는 신원을 드러낸다.
다른 예로서, DECO는 계정 소유권의 증명을 제공하는데 사용될 수 있다. 이러한 구성의 일 예시에서, DECO와 함께, 익명으로 계정들, 예를 들어, 이메일 계정, 소셜 미디어 계정 등의 소유권을 증명할 수 있다. 예를 들어, Alice는 계정 이름이 무엇인지를 드러내지 않고 @example. org로 끝나는 이메일 계정을 그녀가 소유하고 있다는 것을 Bob에게 판명할 수 있다. 이는 예를 들어, 휘슬블로잉(whistleblowing), 익명의 불만 등에 유용한 특정 조직과의 Alice의 제휴를 증명한다.
본원에 개시된 바와 같은 분산형 오라클의 애플리케이션들의 추가적인 예들은 크리덴셜 복구 및 분산형 아이덴티티를 포함한다. 전자의 예시로서, DECO는 OAUTH의 사용을 회피하는 프라이버시-보호 방식으로, 사용자가 특정 웹 리소스, 예를 들어 페이스북 계정에 대한 액세스를 갖는 것을 증명하는 것을 가능하게 할 수 있다. 이는 사용자가 예를 들어 키 복구를 위해 자신의 신원을 증명하기 위해 기존의 서비스를 이용할 수 있게 한다. 후자의 예시로서, DECO는 또한 사용자에게 프라이버시-보호 방식으로, 제3자간 제공자에 의해 표명된 바와 같은 특정 특징들을 갖는 것(예를 들어, 그녀가 18에 걸쳐 있는 것)을 증명하는 것을 가능하게 할 수 있다. 이는 본 명세서에서 익명의 나이 증명(연령 증명)라고도 하는 일례이다. 이러한 증명은 분산형 아이덴티티 시스템에서 크리덴셜을 구성하기 위해 사용될 수 있다.
전술한 분산형 오라클 애플리케이션들은 단지 예일 뿐이고, 어떠한 방식으로든 제한하는 것으로 해석되어서는 안 된다. 본원에 개시된 바와 같은 분산형 오라클의 이러한 그리고 다른 예시적인 애플리케이션들의 구현에 관한 추가적인 세부사항들은 본원에서의 다른 곳에서 찾아볼 수 있다.
본원에 개시된 바와 같은 하나 이상의 분산형 오라클을 구현하도록 구성된 정보 처리 시스템의 다양한 요소들 간의 통신은 하나 이상의 네트워크를 통해 발생하는 것으로 가정된다. 소정의 이러한 네트워크는 실례로 예를 들어, 글로벌 컴퓨터 네트워크, 이를테면 인터넷, WAN, LAN, 위성 네트워크, 전화 또는 케이블 네트워크, 셀룰러 네트워크, 이를테면 3G, 4G 또는 5G 네트워크, 무선 프로토콜을 사용하여 구현되는 무선 네트워크, 이를테면 블루투스, WiFi 또는 WiMAX, 또는 이러한 그리고 다른 유형들의 통신 네트워크들의 다양한 부분들 또는 조합들을 포함할 수 있다.
본원에 개시된 바와 같은 분산형 오라클의 기능의 적어도 일부분을 구현하는 소정의 처리 디바이스는 프로세서, 메모리 및 네트워크 인터페이스와 같은 컴포넌트들을 포함할 수 있다. 프로세서는 메모리 및 네트워크 인터페이스에 동작 가능하게 결합되는 것으로 가정된다. 메모리는 처리 디바이스의 기능의 부분들을 구현할 때 프로세서에 의해 실행되는 소프트웨어 프로그램 코드를 저장한다.
본원에서 도 1 내지 도 14와 관련하여 도시되고 설명된 특정 배열들은 단지 예시적인 예로서만 제시되고, 많은 대안적인 실시 예가 가능한 것으로 이해되어야 한다. 따라서 본원에 개시된 다양한 실시예들은 어떠한 방식으로도 제한하는 것으로 해석되어서는 안 된다. 분산형 오라클을 구현하기 위한 많은 대안적인 배열들이 다른 실시예들에서 이용될 수 있다. 예를 들어, 당업자들은 대안적인 처리 동작들 및 관련 시스템 엔티티 구성들이 다른 실시예들에서 사용될 수 있음을 인식할 것이다. 따라서, 다른 실시예들은 예시적인 실시예들의 엔티티들에 비해, 추가적인 또는 대안적인 시스템 엔티티들을 포함할 수 있다. 또한, 특정 시스템 및 디바이스 구성들 및 연관된 분산형 오라클은 다른 실시예들에서 변경될 수 있다.
또한, 상술된 정보 처리 시스템 배열들은 단지 예시적인 것이고, 다른 실시예들에서는 대안적인 시스템 배열들이 사용될 수 있다는 점에 유의해야 한다.
본원에서 설명된 바와 같은 정보 처리 시스템에서의 소정의 클라이언트, 서버, 프로세서 또는 다른 컴포넌트는 실례로 메모리에 결합되는 프로세서를 포함하는 대응하는 처리 디바이스를 이용하여 구성된다. 프로세서는 처리 동작들 및 기타 기능의 성능을 제어하기 위해 메모리에 저장된 소프트웨어 프로그램 코드를 실행한다. 처리 디바이스는 또한 하나 이상의 네트워크를 통한 통신을 지원하는 네트워크 인터페이스를 포함한다.
프로세서는 예를 들어, 마이크로 프로세서, ASIC, FPGA, CPU, GPU, ALU, DSP, 또는 다른 유사한 처리 디바이스 컴포넌트뿐만 아니라, 다른 유형들 및 배열들의 처리 회로부를 임의의 조합으로 포함할 수 있다. 예를 들어, 본원에 개시된 바와 같은 소정의 처리 디바이스에 의해 제공되는 분산형 오라클의 기능의 적어도 일부분은 이러한 회로부를 사용하여 구현될 수 있다.
메모리는 처리 디바이스의 기능의 부분들을 구현할 때 프로세서에 의해 실행되는 소프트웨어 프로그램 코드를 저장한다. 대응하는 프로세서에 의한 실행을 위한 이러한 프로그램 코드를 저장하는 소정의 이러한 메모리는 프로그램 코드가 내장된 프로세서 판독 가능 저장 매체로서 본원에서 보다 일반적으로 지칭되는 것의 일례이고, 예를 들어, 전자 메모리, 이를테면, SRAM, DRAM 또는 다른 유형들의 RAM, ROM, 플래시 메모리, 자기 메모리, 광학 메모리, 또는 다른 유형들의 저장 디바이스들을 임의의 조합으로 포함할 수 있다.
이러한 프로세서 판독 가능 저장 매체를 포함하는 제조품들은 본 발명의 실시예들인 것으로 고려된다. 용어 "제조품"은 본원에서 사용될 때 일시적인 전파 신호들을 배제하는 것으로 이해되어야 한다.
프로세서 판독 가능 저장 매체를 포함하는 다른 유형들의 컴퓨터 프로그램 제품들이 다른 실시예들에서 구현될 수 있다.
또한, 본 발명의 실시예들은 분산형 오라클뿐만 아니라 다른 관련 기능과 연관된 처리 동작들을 구현하도록 구성된 처리 회로부를 포함하는 집적 회로들의 형태로 구현될 수 있다.
소정의 실시예에서의 처리 디바이스들은 예를 들어, 랩톱, 태블릿 또는 데스크톱 개인용 컴퓨터, 모바일 전화, 또는 다른 유형들의 컴퓨터들 또는 통신 디바이스들을 임의의 조합으로 포함할 수 있다. 예를 들어, 컴퓨터 또는 모바일 전화는 본원에 개시된 바와 같은 분산 오라클과 연관된 기능의 적어도 부분들을 구현하기 위한 처리 디바이스로서 이용될 수 있다. 각 시스템 엔티티들과 연관된 처리 디바이스들을 포함하는 정보 처리 시스템의 다양한 요소들 사이의 이러한 그리고 다른 통신은 하나 이상의 네트워크를 통해 발생할 수 있다.
본원에 개시된 정보 처리 시스템은 하나 이상의 처리 플랫폼, 또는 이들의 부분들을 사용하여 구현될 수 있다.
예를 들어, 정보 처리 시스템의 적어도 일부분을 구현하기 위해 사용될 수 있는 처리 플랫폼의 하나의 예시적인 실시예는 물리적인 인프라스트럭처 상에서 실행되는 하이퍼바이저를 사용하여 구현되는 가상 기계들을 포함하는 클라우드 인프라스트럭처를 포함한다. 이러한 가상 기계들은 하나 이상의 네트워크를 통해 서로 통신하는 각 처리 디바이스들을 포함할 수 있다.
이러한 실시예의 클라우드 인프라스트럭처는 하이퍼바이저의 제어 하에 가상 기계들 각각 상에서 실행되는 하나 이상의 애플리케이션 세트를 더 포함할 수 있다. 또한 적어도 하나의 기본 물리적 기계를 사용하여 각각 가상 기계 세트를 제공하는 다수의 하이퍼바이저들을 사용할 수도 있다. 정보 처리 시스템의 다양한 컴포넌트들의 다수의 인스턴스들을 구성하는 데에는 하나 이상의 하이퍼바이저에 의해 제공되는 다양한 가상 기계 세트들이 이용될 수 있다.
본원에 개시된 바와 같은 정보 처리 시스템의 적어도 일부분을 구현하는 데 사용될 수 있는 처리 플랫폼의 다른 예시적인 실시예는 적어도 하나의 네트워크를 통해 서로 통신하는 복수의 처리 디바이스들을 포함한다. 처리 플랫폼의 각 처리 디바이스는 메모리에 결합된 프로세서를 포함하는 것으로 가정된다.
다시, 이러한 특정 처리 플랫폼들은 예로서만 제시되고, 정보 처리 시스템은 추가적인 또는 대안적인 처리 플랫폼들, 뿐만 아니라 많은 별개의 처리 플랫폼을 임의의 조합으로 포함할 수 있으며, 이러한 각 플랫폼은 하나 이상의 컴퓨터, 서버, 저장 디바이스 또는 다른 처리 디바이스를 포함한다.
예를 들어, 본 발명의 실시예들을 구현하기 위해 사용되는 다른 처리 플랫폼들은 가상 기계들을 포함하는 가상화 인프라스트럭처 대신에 또는 추가로 상이한 유형들의 가상화 인프라스트럭처를 포함할 수 있다. 따라서, 일부 실시예들에서, 시스템 컴포넌트들은 클라우드 인프라스트럭처 또는 리눅스 제어 그룹들 또는 다른 유사한 메커니즘들에 기초하여 운영 체제 레벨 가상화를 사용하여 구현되는 도커 컨테이너들 또는 다른 유형들의 리눅드 컨테이너들을 이용하는 가상화 인프라스트럭처를 포함하는 다른 유형의 가상화 인프라스트럭처에서 적어도 부분적으로 실행될 수 있다.
따라서, 다른 실시예들에서 추가적인 또는 대안적인 요소들의 상이한 배열들이 사용될 수 있는 것으로 이해해야 한다. 이러한 요소들의 적어도 서브 세트는 공통 처리 플랫폼 상에서 총괄하여 구현될 수 있거나, 이러한 각 요소가 별도의 처리 플랫폼 상에서 구현될 수 있다.
또한, 정보 처리 시스템에서 컴퓨터들, 서버들, 저장 디바이스들 또는 다른 컴포넌트들의 다양한 배열들이 가능하다. 이러한 컴포넌트들은 임의의 유형의 네트워크 또는 다른 통신 매체를 통해 정보 처리 시스템의 다른 요소들과 통신할 수 있다.
전술한 바와 같이, 본원에 개시된 바와 같은 시스템의 컴포넌트들은 메모리에 저장되고 처리 디바이스의 프로세서에 의해 실행되는 하나 이상의 소프트웨어 프로그램의 형태로 적어도 부분적으로 구현될 수 있다. 예를 들어, 시스템의 분산형 오라클 엔티티들 또는 관련 컴포넌트들과 연관된 특정 기능은 적어도 부분적으로 소프트웨어의 형태로 구현될 수 있다.
본원에서 설명된 정보 처리 시스템들의 특정 구성들은 단지 예시일 뿐이고, 다른 실시예들에서 이러한 소정의 시스템은 이러한 시스템의 종래의 구현에서 공통적으로 발견되는 유형의 하나 이상의 요소를 포함하여 구체적으로 도시된 것들에 추가하여 또는 대신 다른 요소들을 포함할 수 있다.
예를 들어, 일부 실시예들에서, 정보 처리 시스템은 개시된 기법들을 이용하여 다른 컨텍스트들에서 추가적인 또는 대안적인 기능을 제공하도록 구성될 수 있다.
이에 따라, TLS에 대한 분산형 오라클을 제공하는 것의 컨텍스트에서 본원에서의 일부 실시예들에서 나타내어진 기법들은 다른 컨텍스트들에서 사용하기 위해 간단한 방식으로 개조될 수 있다. 따라서, 본 발명의 예시적인 실시예들은 TLS 또는 이의 연관된 처리 컨텍스트들로 제한되는 것으로서 간주되어서는 안 된다.
또한, 본원에서 설명된 실시예들에서 사용된 특정 프로세스 단계들은 단지 예시적인 것이고, 다른 실시예들은 상이한 유형들 및 배열들의 처리 동작들을 이용할 수 있는 것으로 이해되어야 한다. 예를 들어, 예시적인 실시예들에서 연속적으로 수행되는 것으로서 도시된 특정 프로세스 단계들은 다른 실시예들에서 적어도 부분적으로 서로 병렬로 수행될 수 있다.
본원에서 설명된 바와 같은 본 발명의 실시 예들은 단지 예시를 위한 것이라는 점이 다시 강조되어야 한다. 본 발명의 다른 실시예들은 본원에서 설명된 특정 예시적인 실시예들에서 이용되는 것들과 상이한 다양한 유형들 및 배열들의 정보 처리 시스템들, 네트워크들 및 디바이스들을 이용하여 그리고 많은 대안적인 처리 컨텍스트들에서 구현될 수 있다. 또한, 특정 실시예들을 설명하는 컨텍스트에서 본원에서 이루어진 특정 가정들은 다른 실시 예들에 적용될 필요는 없다. 이러한 그리고 많은 기타 대안적인 실시예들이 당업자들에게 용이하게 명백할 것이다.

Claims (25)

  1. 장치로서,
    메모리에 결합된 프로세서를 포함하는 검증자 디바이스를 포함하며;
    상기 검증자 디바이스는 하나 이상의 네트워크를 통해 클라이언트 디바이스 및 서버 디바이스와 통신하도록 구성되고;
    상기 검증자 디바이스는 또한:
    상기 검증자 디바이스 및 상기 클라이언트 디바이스가 상기 서버 디바이스와의 보안 세션의 세션 키의 각 공유분들을 획득하는 상기 클라이언트 디바이스 및 상기 서버 디바이스와의 3자간 핸드셰이크 프로토콜에 참여하도록;
    상기 클라이언트 디바이스로부터 상기 서버 디바이스와의 상기 보안 세션에 관한 커미트먼트(commitment)를 수신하도록;
    상기 커미트먼트의 수신에 응답하여, 상기 클라이언트 디바이스가 이전에 액세스 가능하지 않았던 상기 보안 세션에 관한 추가적인 정보를 상기 클라이언트 디바이스에 배포하도록; 그리고
    상기 커미트먼트 및 상기 추가적인 정보에 적어도 부분적으로 기초하여, 상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하게 하도록 구성된 것인, 장치.
  2. 제1항에 있어서,
    상기 검증자 디바이스는 또한, 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 상기 데이터의 상기 적어도 하나의 특성의 상기 정확성의 상기 검증에 응답하여 하나 이상의 자동화된 동작을 개시하도록 구성된 것인, 장치.
  3. 제1항에 있어서,
    상기 검증자 디바이스는 분산형 오라클 시스템의 오라클 노드 세트 중 특정 오라클 노드를 포함하는 것인, 장치.
  4. 제1항에 있어서,
    상기 검증자 디바이스는 상기 검증자 디바이스의 기능이 다수의 별개의 프로세싱 디바이스들에 걸쳐 분산되는 분산형 검증자 디바이스를 포함하는 것인, 장치.
  5. 제1항에 있어서,
    상기 서버 디바이스는 전송 계층 보안(transport layer security, TLS) 가능 서버 디바이스를 포함하고, 상기 보안 세션은 TLS 세션을 포함하는 것인, 장치.
  6. 제1항에 있어서,
    상기 보안 세션에 관한 상기 커미트먼트는 상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 응답 데이터를 질의하기 위한 커미트먼트를 포함하는 것인, 장치.
  7. 제1항에 있어서,
    상기 보안 세션에 관한 상기 커미트먼트는 상기 검증자 디바이스가 이전에 액세스 가능하지 않았지만 상기 3자간 핸드셰이크 프로토콜과 관련하여 상기 클라이언트 디바이스에 의해 설정된 증명자 키에 대한 커미트먼트를 포함하는 것인, 장치.
  8. 제1항에 있어서,
    상기 커미트먼트의 수신에 응답하여 상기 클라이언트 디바이스에 배포된 상기 추가적인 정보는 상기 클라이언트 디바이스가 이전에 액세스 가능하지 않았지만 상기 3자간 핸드셰이크 프로토콜과 관련하여 상기 검증자 디바이스에 의해 설정된 검증자 키를 포함하는 것인, 장치.
  9. 제1항에 있어서,
    상기 검증자 디바이스는 또한, 상기 클라이언트 디바이스와 상기 서버 디바이스 사이의 상호작용들과 관련하여 상기 클라이언트 디바이스에 대한 프록시로서 동작하여, 상기 프록시로서 동작하는 상기 검증자 디바이스를 통해 상기 보안 세션의 일부로서 상기 클라이언트 디바이스 및 상기 서버 디바이스 사이에서 교환되는 암호문들을 상기 검증자 디바이스가 자동으로 획득하도록 구성되는 것인, 장치.
  10. 제1항에 있어서,
    상기 검증자 디바이스는 또한, 상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 데이터를 특징짓는 하나 이상의 명제(statement)를 상기 클라이언트 디바이스로부터 수신하도록 구성된 것인, 장치.
  11. 제10항에 있어서,
    상기 하나 이상의 명제 중 소정의 명제는 상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 질의 응답 데이터의 선택적으로 노출되는 서브스트링을 포함하는 것인, 장치.
  12. 제10항에 있어서,
    상기 하나 이상의 명제 중 소정의 명제는 상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 질의 응답 데이터가 상기 클라이언트 디바이스에 의해 상기 검증자 디바이스에 발신될 상기 소정의 명제의 생성과 관련하여 상기 클라이언트 디바이스에 의해 후속하여 파싱될 감소된 데이터를 생성하기 위해 상기 클라이언트 디바이스에 의해 전처리되는 다단 파싱 프로토콜의 이용을 통해 컨텍스트 무결성을 제공하도록 구성된 것인, 장치.
  13. 제1항에 있어서,
    상기 3자간 핸드셰이크 프로토콜과 관련하여, 상기 클라이언트 디바이스 및 상기 검증자 디바이스는 상기 서버 디바이스와 하나 이상의 공유 세션 키를 공동으로 설정하며, 상기 클라이언트 디바이스는 상기 하나 이상의 공유 세션 키 중 소정의 공유 세션 키의 제1 공유분을 갖고, 상기 검증자 디바이스는 상기 소정의 공유 세션 키의 제2 공유분을 가지며, 상기 서버 디바이스는 상기 제1 공유분과 제2 공유분을 조합한 복합 세션 키를 갖는 것인, 장치.
  14. 제1항에 있어서,
    상기 3자간 핸드셰이크 프로토콜과 관련하여, 상기 클라이언트 디바이스는 상기 검증자 디바이스가 액세스 가능하지 않은 암호화 키를 상기 서버 디바이스로부터 수신하는 것인, 장치.
  15. 제1항에 있어서,
    상기 검증자 디바이스 및 상기 클라이언트 디바이스는 상기 서버 디바이스와의 상기 보안 세션의 상기 세션 키의 자신들의 각 공유분들을 사용하여, 상기 서버 디바이스가 상기 데이터를 상기 클라이언트 디바이스에 발신할 것을 요청하기 위해 상기 클라이언트 디바이스에 의해 상기 서버 디바이스에 제공되는 질의를 생성하도록 협력하는 것인, 장치.
  16. 제15항에 있어서,
    상기 검증자 디바이스 및 상기 클라이언트 디바이스는 상기 서버 디바이스와의 상기 보안 세션의 상기 세션 키의 자신들의 각 공유분들을 사용하여, 상기 질의에 응답하여 상기 서버 디바이스에 의해 상기 클라이언트 디바이스에 제공되는 응답을 검증하도록 협력하는 것인, 장치.
  17. 제1항에 있어서,
    상기 3자간 핸드셰이크 프로토콜과 관련하여, 상기 클라이언트 디바이스 및 상기 검증자 디바이스는 각 증명자 및 검증자 키들을 설정하는 것인, 장치.
  18. 제17항에 있어서,
    상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하는 것은 클라이언트 디바이스에 의해 상기 검증 디바이스에 제공된 증명을 검증하는 것을 포함하며, 상기 증명은 (i) 상기 3자간 핸드셰이크 프로토콜과 관련하여 상기 클라이언트 디바이스에 의해 설정된 상기 증명자 키, (ii) 상기 3자간 핸드세이크 프로토콜과 관련하여 상기 검증 디바이스에 의해 설정된 상기 검증자 키, 및 (iii) 상기 클라이언트 디바이스의 비밀 정보에 적어도 부분적으로 기초하여 상기 클라이언트 디바이스에 의해 생성되는 것인, 장치.
  19. 제1항에 있어서,
    상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하는 것은:
    상기 보안 세션의 적어도 하나의 암호문의 적어도 일부분으로부터 도출되는 데이터를 획득하는 것; 및
    상기 클라이언트 디바이스에 의해 해당 데이터의 적어도 하나의 특성의 정확성을 검증하는 것을 포함하는 것인, 장치.
  20. 하나 이상의 네트워크를 통해 클라이언트 디바이스 및 서버 디바이스와 통신하도록 구성된 검증자 디바이스에 의해 수행되는 방법으로서,
    상기 검증자 디바이스 및 상기 클라이언트 디바이스가 상기 서버 디바이스와의 보안 세션의 세션 키의 각 공유분들을 획득하는 상기 클라이언트 디바이스 및 상기 서버 디바이스와의 3자간 핸드셰이크 프로토콜에 참여하는 단계;
    상기 클라이언트 디바이스로부터 상기 서버 디바이스와의 상기 보안 세션에 관한 커미트먼트를 수신하는 단계;
    상기 커미트먼트의 수신에 응답하여, 상기 클라이언트 디바이스가 이전에 액세스 가능하지 않았던 상기 보안 세션에 관한 추가적인 정보를 상기 클라이언트 디바이스에 배포하는 단계; 및
    상기 커미트먼트 및 상기 추가적인 정보에 적어도 부분적으로 기초하여, 상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하는 단계를 포함하며;
    상기 방법을 수행하는 상기 검증자 디바이스는 메모리에 결합된 프로세서를 포함하는 것인, 방법.
  21. 제20항에 있어서,
    상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하는 단계는:
    상기 보안 세션의 적어도 하나의 암호문의 적어도 일부분으로부터 도출되는 데이터를 획득하는 단계; 및
    상기 클라이언트 디바이스에 의해 해당 데이터의 적어도 하나의 특성의 정확성을 검증하는 단계를 포함하는 것인, 방법.
  22. 제20항에 있어서,
    상기 검증자 디바이스는 또한, 상기 클라이언트 디바이스와 상기 서버 디바이스 사이의 상호작용들과 관련하여 상기 클라이언트 디바이스에 대한 프록시로서 동작하여, 상기 프록시로서 동작하는 상기 검증자 디바이스를 통해 상기 보안 세션의 일부로서 상기 클라이언트 디바이스 및 상기 서버 디바이스 사이에서 교환되는 암호문들을 상기 검증자 디바이스가 자동으로 획득하도록 구성되는 것인, 방법.
  23. 하나 이상의 소프트웨어 프로그램의 프로그램 코드를 저장하고 있는 비일시적 프로세서 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품으로서, 상기 프로그램 코드는 하나 이상의 네트워크를 통해 클라이언트 디바이스 및 서버 디바이스와 통신하도록 구성되며 메모리에 결합된 프로세서를 포함하는 검증자 디바이스에 의해 실행될 때, 상기 검증자 디바이스로 하여금:
    상기 검증자 디바이스 및 상기 클라이언트 디바이스가 상기 서버 디바이스와의 보안 세션의 세션 키의 각 공유분들을 획득하는 상기 클라이언트 디바이스 및 상기 서버 디바이스와의 3자간 핸드셰이크 프로토콜에 참여하도록;
    상기 클라이언트 디바이스로부터 상기 서버 디바이스와의 상기 보안 세션에 관한 커미트먼트를 수신하도록;
    상기 커미트먼트의 수신에 응답하여, 상기 클라이언트 디바이스가 이전에 액세스 가능하지 않았던 상기 보안 세션에 관한 추가적인 정보를 상기 클라이언트 디바이스에 배포하도록; 그리고
    상기 커미트먼트 및 상기 추가적인 정보에 적어도 부분적으로 기초하여, 상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하게 하도록 구성된 것인, 컴퓨터 프로그램 제품.
  24. 제23항에 있어서,
    상기 보안 세션의 일부로서 상기 서버 디바이스로부터 상기 클라이언트 디바이스에 의해 획득되는 데이터의 적어도 하나의 특성의 정확성을 검증하는 것은:
    상기 보안 세션의 적어도 하나의 암호문의 적어도 일부분으로부터 도출되는 데이터를 획득하는 것; 및
    상기 클라이언트 디바이스에 의해 해당 데이터의 적어도 하나의 특성의 정확성을 검증하는 것을 포함하는 것인, 컴퓨터 프로그램 제품.
  25. 제23항에 있어서,
    상기 검증자 디바이스는 또한, 상기 클라이언트 디바이스와 상기 서버 디바이스 사이의 상호작용들과 관련하여 상기 클라이언트 디바이스에 대한 프록시로서 동작하여, 상기 프록시로서 동작하는 상기 검증자 디바이스를 통해 상기 보안 세션의 일부로서 상기 클라이언트 디바이스 및 상기 서버 디바이스 사이에서 교환되는 암호문들을 상기 검증자 디바이스가 자동으로 획득하도록 구성되는 것인, 컴퓨터 프로그램 제품.
KR1020227010610A 2019-08-30 2020-08-28 전송 계층 보안 및 기타 컨텍스트에서의 데이터 검증을 위한 분산 기술 KR20220069020A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962894052P 2019-08-30 2019-08-30
US62/894,052 2019-08-30
PCT/US2020/048344 WO2021041771A1 (en) 2019-08-30 2020-08-28 Decentralized techniques for verification of data in transport layer security and other contexts

Publications (1)

Publication Number Publication Date
KR20220069020A true KR20220069020A (ko) 2022-05-26

Family

ID=74686039

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227010610A KR20220069020A (ko) 2019-08-30 2020-08-28 전송 계층 보안 및 기타 컨텍스트에서의 데이터 검증을 위한 분산 기술

Country Status (7)

Country Link
US (1) US11997107B2 (ko)
EP (1) EP4022840A4 (ko)
JP (1) JP2022546470A (ko)
KR (1) KR20220069020A (ko)
CN (1) CN114946152A (ko)
AU (1) AU2020336124A1 (ko)
WO (1) WO2021041771A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL279405B2 (en) * 2020-12-13 2024-01-01 Google Llc Using a secure multi-participant calculation to improve the integrity of the content selection process
EP4054116A1 (en) * 2021-03-05 2022-09-07 Siemens Aktiengesellschaft Ecosystem exchanging information about esg data of a product related entity
JP2022158677A (ja) * 2021-04-02 2022-10-17 株式会社野村総合研究所 マルチパーティ計算で行われるゼロ知識証明のための装置およびシステム
CN114154990B (zh) * 2021-12-08 2022-09-20 北京汇收钱科技股份有限公司 一种基于在线支付的大数据防攻击方法及存储介质
KR102429325B1 (ko) * 2022-05-02 2022-08-04 에스엠테크놀러지(주) 병렬형 인증서 검증 시스템 및 그 동작 방법
CN115622686B (zh) * 2022-12-19 2023-03-21 豪符密码检测技术(成都)有限责任公司 一种安全多方计算的检测方法

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784463A (en) 1996-12-04 1998-07-21 V-One Corporation Token distribution, registration, and dynamic configuration of user entitlement for an application level security system and method
US7962413B2 (en) * 1998-08-13 2011-06-14 International Business Machines Corporation End-user system of preventing unauthorized rerecording of multimedia content
US7197639B1 (en) 1999-02-05 2007-03-27 Rsa Security Inc. Cryptographic countermeasures against connection depletion attacks
US6976090B2 (en) 2000-04-20 2005-12-13 Actona Technologies Ltd. Differentiated content and application delivery via internet
WO2006119184A2 (en) * 2005-05-04 2006-11-09 Tricipher, Inc. Protecting one-time-passwords against man-in-the-middle attacks
US8214635B2 (en) * 2006-11-28 2012-07-03 Cisco Technology, Inc. Transparent proxy of encrypted sessions
WO2008137939A2 (en) * 2007-05-07 2008-11-13 Archivas, Inc. Method for data privacy in a fixed content distributed data storage
FR2992509B1 (fr) * 2012-06-21 2017-05-26 Commissariat Energie Atomique Dispositif et procede pour generer une cle de session
EP3084667A4 (en) 2013-12-19 2017-07-26 Intel Corporation Policy-based trusted inspection of rights managed content
US20150288667A1 (en) * 2014-04-08 2015-10-08 Samsung Electronics Co., Ltd. Apparatus for sharing a session key between devices and method thereof
WO2015173434A1 (en) * 2014-05-16 2015-11-19 Nec Europe Ltd. Method for proving retrievability of information
US9584517B1 (en) 2014-09-03 2017-02-28 Amazon Technologies, Inc. Transforms within secure execution environments
US10567434B1 (en) * 2014-09-10 2020-02-18 Amazon Technologies, Inc. Communication channel security enhancements
US10425234B2 (en) * 2015-08-27 2019-09-24 Cavium, Llc Systems and methods for perfect forward secrecy (PFS) traffic monitoring via a hardware security module
US10425386B2 (en) * 2016-05-11 2019-09-24 Oracle International Corporation Policy enforcement point for a multi-tenant identity and data security management cloud service
US10574692B2 (en) * 2016-05-30 2020-02-25 Christopher Nathan Tyrwhitt Drake Mutual authentication security system with detection and mitigation of active man-in-the-middle browser attacks, phishing, and malware and other security improvements
US11829998B2 (en) 2016-06-07 2023-11-28 Cornell University Authenticated data feed for blockchains
US11165862B2 (en) * 2017-10-24 2021-11-02 0Chain, LLC Systems and methods of blockchain platform for distributed applications
US10659228B2 (en) * 2018-06-28 2020-05-19 Nxp B.V. Method for establishing a secure communication session in a communications system
US11270403B2 (en) * 2018-07-30 2022-03-08 Hewlett Packard Enterprise Development Lp Systems and methods of obtaining verifiable image of entity by embedding secured representation of entity's distributed ledger address in image
US11070363B1 (en) * 2018-12-21 2021-07-20 Mcafee, Llc Sharing cryptographic session keys among a cluster of network security platforms monitoring network traffic flows

Also Published As

Publication number Publication date
JP2022546470A (ja) 2022-11-04
US11997107B2 (en) 2024-05-28
WO2021041771A1 (en) 2021-03-04
AU2020336124A1 (en) 2022-04-07
CN114946152A (zh) 2022-08-26
EP4022840A1 (en) 2022-07-06
US20220377084A1 (en) 2022-11-24
EP4022840A4 (en) 2023-09-20

Similar Documents

Publication Publication Date Title
Zhang et al. Deco: Liberating web data using decentralized oracles for tls
TWI831760B (zh) 用以基於證明驗證認證鏈外資料之系統及方法
US11997107B2 (en) Decentralized techniques for verification of data in transport layer security and other contexts
US10523707B2 (en) Secure transport channel using multiple cipher suites
US20220318907A1 (en) Systems and methods for generating secure, encrypted communications across distributed computer networks for authorizing use of cryptography-based digital repositories in order to perform blockchain operations in decentralized applications
US11212102B2 (en) System and method for an electronic identity brokerage
Cervesato et al. Breaking and fixing public-key Kerberos
US10979403B1 (en) Cryptographic configuration enforcement
WO2020258837A1 (zh) 解锁方法、实现解锁的设备及计算机可读介质
US9450758B1 (en) Virtual requests
Jarecki et al. Two-factor authentication with end-to-end password security
US11159498B1 (en) Information security proxy service
US10963593B1 (en) Secure data storage using multiple factors
Chen et al. Data privacy in trigger-action systems
KR20120091618A (ko) 연쇄 해시에 의한 전자서명 시스템 및 방법
CN104992329A (zh) 一种安全下发交易报文的方法
Bray Implementing Cryptography Using Python
Miculan et al. Automated verification of Telegram’s MTProto 2.0 in the symbolic model
Diaz et al. On securing online registration protocols: Formal verification of a new proposal
Emmanuel et al. Mobile Banking in Developing Countries: Secure Framework for Delivery of SMS-banking Services
Maram Protocols for Bootstrapping and Secure Management of Decentralized Identities
Hirschi Automated Verification of Privacy in Security Protocols: Back and Forth Between Theory & Practice
Balfanz et al. Fido uaf protocol specification v1. 0
Srinivas et al. FIDO UAF architectural overview
US20230188364A1 (en) Partial payload encryption with integrity protection

Legal Events

Date Code Title Description
A201 Request for examination