KR20230146596A - 디지털 보안 시스템 및 방법 - Google Patents

디지털 보안 시스템 및 방법 Download PDF

Info

Publication number
KR20230146596A
KR20230146596A KR1020237031362A KR20237031362A KR20230146596A KR 20230146596 A KR20230146596 A KR 20230146596A KR 1020237031362 A KR1020237031362 A KR 1020237031362A KR 20237031362 A KR20237031362 A KR 20237031362A KR 20230146596 A KR20230146596 A KR 20230146596A
Authority
KR
South Korea
Prior art keywords
puf
response
transaction
challenge
blockchain
Prior art date
Application number
KR1020237031362A
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 KR20230146596A publication Critical patent/KR20230146596A/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3278—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response using physically unclonable functions [PUF]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/107—License processing; Key processing
    • G06F21/1078—Logging; Metering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/73—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by creating or determining hardware identification, e.g. serial numbers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/86—Secure or tamper-resistant housings
    • G06F21/87—Secure or tamper-resistant housings by means of encapsulation, e.g. for integrated circuits
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101—Auditing as a secondary aspect
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • 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/12—Details relating to cryptographic hardware or logic circuitry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Mathematical Physics (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

본 명세서에 개시된 제1 양상에 따라, 디바이스가 제공되고, 디바이스는: PUF 모듈; 및 챌린지를 PUF 모듈에 입력하고 응답을 다시 수신하기 위한 비보안 채널의 적어도 일부를 제공하는 하나 이상의 외부 계층 구성요소를 포함한다. PUF 모듈의 내부 로직은 챌린지 및/또는 응답의 레코드를 로그 매체, 예컨대, 블록체인에 자동으로 로깅하도록 배열된 로깅 메커니즘을 포함한다. 제2 양상에 따라, 방법이 제공되고, 방법은: 블록체인 상에 레코딩되도록 제1 메시지를 전송하는 단계, 제1 메시지가 조작 없이 블록체인 상에 레코딩되었음을 체크하기 위한 질의를 제출하는 단계, 이에 대한 조건 하에서, 블록체인 상에 레코딩될 제2 메시징 트랜잭션을 전송하는 단계를 포함한다. 제1 및 제2 양상은 함께 또는 독립적으로 사용될 수 있다.

Description

디지털 보안 시스템 및 방법
본 개시의 일 양상은 PUF(physically unclonable functions)의 분야에 관한 것이다. 다른 양상은 블록체인을 통한 보안 통신에 관한 것이다.
PUF(physical unclonable function)는 결정론적이지만 예측 불가능한 물리적 현상을 포함하는 함수를 지칭하는 기술 용어이다. PUF는 때로는 또한 물리적 랜덤 함수로서 지칭된다. PUF는 "챌린지"로서 지칭된 입력을 수신하고 PUF에 의해 사용되는 챌린지 및 물리적 현상에 종속하여 대응하는 "응답"으로서 지칭되는 출력을 생성한다. PUF들은 때로는 강한 PUF 및 약한 PUF로 분류된다. 강한 PUF는 통상적으로 어떠한 임의적 챌린지의 값도 취할 수 있는 매우 다수의 상이한 챌린지들에 대한 개개의 응답을 생성할 수 있다. 약한 PUF는 단일 응답 또는 적은 수의 응답들에 대해서만 응답을 생성할 수 있다(통상적으로 챌린지는 어떠한 임의적 값도 취할 수 없음). 즉, 강한 PUF는 매우 다수의 챌린지-응답 쌍들(이는 큰 챌린지-응답 공간을 가짐)을 갖는 반면, 약한 PUF는 단일 챌린지-응답 쌍 또는 제한된 수의 챌린지-응답 쌍들(작은 또는 제한된 챌린지-응답 공간)을 갖는다. 일 정의에 따르면, 약한 PUF는 챌린지 비트의 수에 따라 선형적으로 증가하는 응답의 수, 또는 더 일반적으로 챌린지 비트의 수 또는 임의의 다른 파라미터에 따라 선형적으로 증가하지 않는 응답의 수를 갖는다(즉, 약한 PUF는 스케일링 업되는 자신의 챌린지-응답 공간을 가질 수 없고, 즉, 그는 기껏해야 선형적으로 스케일링된다).
강한 PUF의 알려진 예는 광학 PUF이다. 예컨대, 광학 PUF는 레이저, 광학 센서, 고체 광학 매체에 세팅된 기포들 또는 다른 이러한 인공물들을 갖는 고체 광학 매체를 포함할 수 있다. 레이저는 회절 또는 산란 패턴(이는 매체 내 기포들 또는 인공물의 효과임)을 생성하도록 제어 가능한 각도로 광학 매체를 통해 비친다. 센서는 이 패턴을 감지하도록 배열된다. 챌린지는 레이저의 각도이고, 응답은 감지된 패턴에 기초하여 생성된다.
약한 PUF의 예는 SRAM PUF이다. 이 경우에, 챌린지는 SRAM(static random access memory)을 켜는 것이다. 하나의 SRAM으로부터 다른 SRAM으로 약간의 제조 차이들로 인해, SRAM 셀들은 파워 업(power up)시에 0/1 상태들의 고유한 패턴에 빠지게 될 것이며, 이는 이에 따라 개별 SRAM의 특징적인 핑거프린트를 형성한다. PUF는 파워 업 시에 응답으로서 이를 출력하도록 구성된다.
PUF는 이를테면, (예컨대, 문서에 서명하거나 암호화하기 위한) 암호화 알고리즘들에 사용하기 위한 키를 생성하기 위한 수단으로 사용될 수 있다. PUF의 또 다른 애플리케이션은 PUF를 통합하는 디바이스 이를테면, 컴퓨터 디바이스의 식별을 위한 것이다. 주어진 챌린지에 대한 예상된 응답이 이전에 결정된 경우, 검증 당사자는 추후에 챌린지로 타겟 디바이스에 챌린지하여, 예상된 응답을 제공하는지를 체크하고, 그리하여 타겟 디바이스가 예상된 응답과 연관된 디바이스인지를 체크할 수 있다.
제한된 챌린지 응답 공간으로 인해, 약한 PUF에 대한 입력-출력(i/o) 인터페이스는 단 하나 또는 제한된 수의 당사자들로 제한되는 경향이 있다(예컨대, 단 하나 또는 제한된 수의 신뢰할 수 있는 당사자들에게만 PUF에 대한 액세스가 물리적으로 또는 합법적으로 승인될 수 있거나 PUF에 대한 인터페이스가 패스워드로 보호될 수 있거나 이런 식임). 즉, 문제의 당사자 또는 당사자들만이, 챌린지를 제출하는 데 필요한 PUF에 대한 입력 및 응답이 다시 수신되는 출력에 대한 액세스를 획득할 수 있다. 반면에 강한 PUF들의 경우, 강한 PUF에 대한 i/o 인터페이스는 다수의 또는 제한되지 않은 수의 당사자들에 ― 이들 전부가 반드시 알려지거나 신뢰할 수 있는 당사자들일 필요는 없음 ― 광범위하게 이용 가능하게 될 수 있다. 그 이유는, 챌린지 응답 공간이 충분히 커서, 적대자가 모든 챌린지-응답 쌍들을 열거(enumerate)하는 것이 불가능하기 때문이고, 이에 따라 적대자가 PUF에 자유롭게 액세스하는 능력은 약한 PUF들에 대해 해당했을 바와 같은 PUF의 열거(enumeration) 및 스푸핑(spoofing)을 허용함으로써 그의 보안을 손상시키지 않아야 한다.
상이한 기술 영역에서, 블록체인은 블록체인의 복제본이 분산 P2P(Peer-to-Peer) 네트워크(이하 "블록체인 네트워크"로서 지칭됨) 내 복수의 노드들 각각에서 유지되며 널리 공개되는 분산 데이터 구조의 형태를 지칭한다. 블록체인은 데이터의 블록들의 체인을 포함하며, 각각의 블록은 하나 이상의 트랜잭션들을 포함한다. 소위 "코인베이스 트랜잭션(coinbase transaction)들"이 아닌 각각의 트랜잭션은 시퀀스 내 이전 트랜잭션을 다시 가리키며, 이는 하나 이상의 블록들에 걸쳐 있어 하나 이상의 코인베이스 트랜잭션들로 되돌아갈 수 있다. 코인베이스 트랜잭션은 아래에서 추가로 논의된다. 블록체인 네트워크에 제출된 트랜잭션들은 새로운 블록들에 포함된다. 새로운 블록들은 복수의 노드들 각각이 "작업 증명"을 수행하기 위해 경쟁하는 것 즉, 블록체인의 새로운 블록에 포함되기를 기다리는, 순서화되고 유효성 검증된 보류중인 트랜잭션들의 정의된 세트의 표현에 기초하여 암호화 퍼즐을 해결하는 것을 수반하는 "채굴"로서 지칭되는 프로세스에 의해 생성된다. 블록체인은 일부 노드들에서 프루닝(prune)될 수 있으며 블록들의 공개는 단순 블록 헤더들의 공개를 통해 달성될 수 있다는 것이 주의되어야 한다.
블록체인의 트랜잭션들은 다음 목적들: 디지털 자산(예컨대, 다수의 디지털 토큰들)을 전달하는 것, 가상화된 원장 또는 레지스트리 내 엔트리들의 세트를 순서화하는 것, 타임스탬프 엔트리들을 수신 및 프로세싱하는 것, 그리고/또는 인덱스 포인터들을 시간-순서화하는 것 중 하나 이상을 위해 사용될 수 있다. 블록체인 위에 부가적인 기능성을 쌓기 위해 블록체인이 또한 활용될 수 있다. 예컨대, 블록체인 프로토콜들은 트랜잭션의 데이터에의 부가적인 사용자 데이터 또는 인덱스들의 저장을 허용할 수 있다. 단일 트랜잭션 내에 저장될 수 있는 최대 데이터 용량에 대해 미리 지정된 제한이 없고 이에 따라 점점 더 복잡한 데이터가 통합될 수 있다. 예컨대, 이는 블록체인에 전자 문서를 저장하거나, 오디오 또는 비디오 데이터를 저장하는 데 사용될 수 있다.
블록체인 네트워크의 노드들(종종 "채굴자들"로서 지칭됨)은 분산 트랜잭션 등록 및 검증 프로세스를 수행하며, 이는 나중에 보다 자세히 설명될 것이다. 요약하면, 이 프로세스 동안, 노드는 트랜잭션들을 유효성 검증하여 유효한 작업 증명 솔루션을 식별하려고 시도하는 블록 템플릿에 삽입한다. 유효한 솔루션이 발견되면, 새로운 블록이 네트워크의 다른 노드들로 전파되고, 이에 따라 각각의 노드가 블록체인 상에 새로운 블록을 레코딩하는 것을 가능하게 한다. 트랜잭션을 블록체인에 레코딩하기 위해, 사용자(예컨대, 블록체인 클라이언트 애플리케이션)는 트랜잭션을 전파될 네트워크의 노드들 중 하나로 전송한다. 트랜잭션을 수신하는 노드들은 유효성 검증된 트랜잭션을 새로운 블록에 통합하는 작업 증명 솔루션을 찾기 위해 경합할 수 있다. 각각의 노드는 트랜잭션이 유효하기 위한 하나 이상의 조건들을 포함하는 동일한 노드 프로토콜을 시행하도록 구성된다. 유효하지 않은 트랜잭션들은 블록들 내로 통합되거나 전파되지 않을 것이다. 트랜잭션이 유효성 검증되고 그리하여 블록체인 상에 수락된다고 가정하면, 트랜잭션(임의의 사용자 데이터 포함함)은 이에 따라 불변의 공개 레코드로서 블록체인 네트워크 내 노드들 각각에 등록되고 인덱싱된 상태로 유지된다.
최신 블록을 생성하기 위해 작업 증명 퍼즐을 성공적으로 해결한 노드는 통상적으로 디지털 자산의 금액, 즉 다수의 토큰들을 분배하는 "코인베이스 트랜잭션"이라 불리는 새로운 트랜잭션으로 보상을 받는다. 유효하지 않은 트랜잭션들의 검출 및 거절은 네트워크의 에이전트들로서 작용하는 경쟁 노드들의 액션에 의해 시행되며 불법 행위를 보고하고 차단하도록 장려된다. 광범위한 정보 공개는 사용자들이 노드들의 성능을 지속적으로 감사하도록 허용한다. 단순 블록 헤더들의 공개는 참가자들이 블록체인의 지속적인 무결성을 보장하도록 허용한다.
"출력 기반" 모델(때로는 UTXO 기반 모델로서 지칭됨)에서, 주어진 트랜잭션의 데이터 구조는 하나 이상의 입력들 및 하나 이상의 출력들을 포함한다. 임의의 지출 가능한 출력은 진행중인 트랜잭션 시퀀스로부터 도출 가능한 디지털 자산의 금액을 지정하는 요소를 포함한다. 지출 가능한 출력은 때로는 UTXO("미지출 트랜잭션 출력")로서 지칭된다. 출력은 출력의 향후 리딤션(redemption)을 위한 조건을 지정하는 잠금 스크립트를 더 포함할 수 있다. 잠금 스크립트는 디지털 토큰들 또는 자산들을 유효성 검증하고 이전하는 데 필요한 조건들을 정의하는 술어이다. (코인베이스 트랜잭션 이외의) 트랜잭션의 각각의 입력은 선행 트랜잭션의 이러한 출력에 대한 포인터(즉, 참조)를 포함하고, 가리키는 출력의 잠금 스크립트를 잠금해제하기 위한 잠금해제 스크립트를 더 포함할 수 있다. 따라서 트랜잭션들의 쌍을 고려하고, 이들을 제1 및 제2 트랜잭션(또는 "타겟" 트랜잭션)이라고 한다. 제1 트랜잭션은 출력을 잠금해제하는 하나 이상의 조건들을 정의하는 잠금 스크립트를 포함하고 디지털 자산의 금액을 지정하는 적어도 하나의 출력을 포함한다. 제2의 타겟 트랜잭션은 제1 트랜잭션의 출력에 대한 포인터를 포함하는 적어도 하나의 입력, 및 제1 트랜잭션의 출력을 잠금해제하기 위한 잠금해제 스크립트를 포함한다.
이러한 모델에서, 제2의 타겟 트랜잭션이 블록체인 네트워크에 전송되어 블록체인에서 전파 및 레코딩될 때, 각각의 노드에 적용되는 유효성에 대한 기준들 중 하나는, 잠금해제 스크립트가 제1 트랜잭션의 잠금 스크립트에 정의된 하나 이상의 조건들 전부 충족하는 것일 것이다. 다른 하나는 제1 트랜잭션의 출력이 다른 더 앞선 유효한 트랜잭션에 의해 이미 리딤되지 않았다는 것일 것이다. 이러한 조건들 중 임의의 것에 따라 유효하지 않은 타겟 트랜잭션을 발견한 임의의 노드는 이를 전파하지 않거나(유효한 트랜잭션으로서 전파하지 않으나, 어쩌면, 유효하지 않은 트랜잭션을 등록하기 위해 전파함) 블록체인에 레코딩될 새로운 블록에 이를 포함시키지 않을 것이다.
대안적인 유형의 트랜잭션 모델은 계정 기반 모델이다. 이 경우에 각각의 트랜잭션은 과거 트랜잭션들의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하기 보다는, 절대 계정 잔액을 참조함으로써 전달될 금액을 정의한다. 모든 계정들의 현재 상태는 블록체인과 별개로 노드들에 의해 저장되며 지속적으로 업데이트된다.
PUF는 EDR(event data recorder)(때때로 "블랙박스" 레코더로 또한 지칭됨)과 같은 디바이스에 임베딩될 수 있다. 예컨대, 이것은 특정 결과를 생성한 디바이스의 아이덴티티를 증명하기 위해 조사 또는 법정 재판 절차 동안 나중에 사용될 수 있다. 그러나, 디바이스가, 이를테면, 서비스 거부 공격(denial of service attack)에서 또는 조사 또는 재판 절차를 방해하기 위해 챌린지 또는 응답의 악의적인 조작에 취약할 수 있다는 잠재적인 문제가 있다. 예컨대, 디바이스에 입력되기 전에 챌린지를 변환하거나 디바이스에 의해 출력된 응답을 변환할 스크램블러는 디바이스의 입력 및/또는 출력에 배치될 수 있거나, 또는 멀웨어는 이러한 변환을 내부적으로 수행할 디바이스에 설치될 수 있다. 이러한 악의적인 조작이 발생하였는지에 대한 증명 수단을 제공하는 것이 바람직할 것이다.
본 명세서에 개시된 제1 양상에 따라, 디바이스가 제공되고, 디바이스는 PUF 모듈, 및 하나 이상의 외부 계층 구성요소를 포함한다. PUF 모듈은 PUF(physically unclonable function), 및 입력 챌린지를 수신하고 입력 챌린지의 결정론적 함수인 출력 응답을 출력하도록 배열되는 내부 PUF 인터페이스 로직을 포함하고, 결정론적 함수는 PUF를 포함한다. 하나 이상의 외부 계층 컴포넌트들은 입력 챌린지를 PUF 모듈의 내부 인터페이스 로직에 입력하고 내부 인터페이스 로직에 의해 출력된 출력 응답을 다시 수신하기 위한 비보안 채널의 적어도 일부를 제공한다. 외부 계층 구성요소 중 적어도 하나는 악의적인 프로세스에 의한 입력 챌린지 및/또는 출력 응답의 조작에 취약하지만, 내부 PUF 인터페이스 로직을 포함하는 PUF 모듈은 디바이스의 하우징 내에 캡슐화되고 하나 이상의 외부 계층 구성요소로부터 분리되고, 따라서 악의적인 프로세스에 의한 조작으로부터 보호된다. 내부 PUF 인터페이스 로직은 입력 챌린지 및/또는 출력 응답의 레코드를 로그 매체에 자동으로 로깅하도록 배열된 로깅 메커니즘을 포함한다.
실시예에서, 로그 매체는 디바이스의 로컬 메모리, 예컨대, 변조 방지 메모리, 일회 기록 메모리, 및/또는 인터페이스 로직에 임베딩된 메모리를 포함할 수 있다. 대안적으로, 로그 매체는 디바이스 외부의 공개적으로 액세스 가능한 매체, 예컨대, 블록체인을 포함할 수 있다.
PUF 디바이스가 체인 상에 레코드를 로깅할 때, 또는 임의의 다른 전송 당사자 또는 디바이스가 블록체인을 통해 수신자와 통신을 시도하려고 할 때 발생할 수 있는 또 다른 잠재적인 취약성은, 통신이 전송자와 블록체인 사이에서 인터셉트되고 조작될 수 있다는 것이다.
본 명세서에 개시된 제2 양상에 따라, 컴퓨터 구현 방법이 제공되고, 방법은, 제1 엔티티에 의해, a) 블록체인 상에 레코딩될 제1 메시징 트랜잭션을 전송하는 단계 ― 제1 메시징 트랜잭션은 제1 메시지, 및 제2 엔티티가 블록체인 상에서 제1 메시지를 식별할 수 있도록 제1 메시지를 제2 엔티티에 보내는 개개의 정보를 포함함 ― ; b) 제1 메시지가 조작 없이 블록체인 상에 레코딩되었음을 체크하기 위한 질의를 제출하는 단계; 및 c) 제1 메시지가 상기 질의에 따라 조작 없이 블록체인 상에 레코딩된 것으로 결정된다는 조건 하에, 블록체인 상에 레코딩될 제2 메시징 트랜잭션을 전송하는 단계 ― 제2 메시징 트랜잭션은 제2 메시지, 및 제2 엔티티가 블록체인 상에서 제1 메시지를 식별할 수 있도록 제2 메시지를 제2 엔티티에 보내는 개개의 정보를 포함함 ― 를 포함한다.
제1 및 제2 양상은 서로 함께 또는 독립적으로 사용될 수 있다.
본 개시내용의 실시예들의 이해를 보조하기 위해 그리고 그러한 실시예들이 어떻게 실행될 수 있는지를 보여주기 위하여, 단지 예로서 첨부 도면들에 대한 참조가 이루어진다.
도 1은 블록체인을 구현하기 위한 시스템의 개략적인 블록도이다.
도 2는 블록체인에 레코딩될 수 있는 트랜잭션들의 일부 예들을 개략적으로 예시한다.
도 3은 PUF의 챌린지 및 응답을 개략적으로 예시한다.
도 4는 PUF를 포함하는 시스템의 개략적인 블록도이다.
도 5a는 본 명세서에 개시된 실시예들에 따른 확장된 PUF의 개략적인 블록도이다.
도 5b는 비-확장 동작 모드에서 확장된 PUF의 개략적인 블록도이다.
도 6은 챌린지-응답 쌍들의 분배에서 신뢰할 수 있는 제3자 또는 공개 매체를 수반하는 시스템의 개략도이다.
도 7은 본 명세서에 개시된 실시예들에 따른 검증 프로세스의 개략적인 흐름도이다.
도 8a 내지 도 8c는 본 명세서에 개시된 실시예들에 따라, 마스터 챌린지로부터 챌린지들의 세트를 생성하는 방법들을 개략적으로 예시한다.
도 9는 체인 상에 응답 데이터를 레코딩하는 방법을 개략적으로 예시한다.
도 10은 임베딩된 PUF 모듈을 포함하는 디바이스의 개략적인 블록도이다.
도 11은 PUF 디바이스가 블록체인 상의 레코드를 로깅하는 것을 도시하는 개략적인 블록도이다.
도 12는 비보안 채널과 블록체인을 통한 통신을 도시하는 개략적인 블록도이다.
도 13은 비보안 채널을 수반하는 통신을 위한 보호를 제공하는 시스템의 개략적인 블록도이다.
사람과 기계 둘 모두를 위한 키 생성 시스템 및 프라이버시-보존 아이덴티티 시스템과 같은 시스템의 견고성은 PUF(physically unclonable function)를 수반함으로써 개선될 수 있다. 이들은 서로 또는 블록체인과 같은 공개 시스템과 상호작용하는 당사자 및/또는 자율 기계일 수 있다.
물리적 시스템에 기초하고 물리적 디바이스의 제조에서 랜덤이고, 결정 불가능하고 반복할 수 없는 변형의 가정에 의해 확보되는 이러한 기능은 인간 아이덴티티와 그들의 디바이스 사이에 확립된 링크를 강화하기 위해, 또는 더 나아가 디바이스 자체에 대한 위조 불가하고 고유한 아이덴티티를 확립하는 데 사용될 수 있다.
문헌에서, PUF는 약한 타입과 강한 타입으로 분류되고, 그들의 별개의 특성에 의해 분류된다. 아래의 일부 실시예에서, 이들 타입의 PUF 둘 모두의 이점을 갖는 실현 가능한 PUF 디바이스를 설명하기 위한 일반화된 확장된 PUF(ePUF) 프레임워크가 또한 제공되는데; 즉, ePUF는, 실현 가능하고 구현하기에 비용-효율적이면서, 애플리케이션에서 사용될 광범위한 챌린지-응답 쌍을 생성할 수 있다.
보다 일반적으로 PUF들 및 챌린지-응답 쌍들의 관리에 관한 다양한 양상들이 본 명세서에 개시된다. 이들 상이한 양상들은 개별적으로 또는 임의의 조합으로 사용될 수 있다. 이들은 예컨대, 다음을 포함한다:
I. PUF의 챌린지-응답 공간을 확장하기 위한 확장된 PUF;
II. ePU 디바이스들을 사용함으로써 사람 및/또는 디바이스 아이덴티티를 설정하기 위한 일 세트의 블록체인-불가지론적 프로토콜들;
III. 블록체인을 활용함으로써 이러한 아이덴티티 프로토콜들을 개선하기 위한 프레임워크;
IV. 챌린지-응답 쌍들의 경량 저장을 위한 기술;
V. PUF 기반 모듈에서 사용하기 위한 이벤트 로깅 시스템 및 방법; 및
VI. 디바이스들에 의한 검증 가능한 컴퓨테이션에 위한 그리고 단순화된 지불 검증(SPV) 프로세스들을 위한 KYC의 구현과 같은 다양한 문제들에 대한 ePUF 디바이스들의 일 세트의 신규 애플리케이션들.
1. PUF(PHYSICALLY UNCLONABLE FUNCTION)들 ― 서두들
PUF(physically unclonable function)들이라는 용어는 범용 랜덤 함수로서 작용하는 물리적 시스템들 및 디바이스들의 클래스를 지칭한다. 이러한 PUF들은 종종 마이크론 미만(sub-micron) 스케일에서 그의 물리적 특성들에 의해 고유하게 특성화되며, 이는 물리적 자극으로 이러한 특성들을 프로빙(probing)함으로써 각각의 PUF가 고유하게 식별 및 검증될 수 있음을 의미한다.
고레벨에서, PUF는 챌린지들을 응답들에 매핑하는 함수들로서 간주될 수 있는데: 그의 쌍들은 종종 챌린지-응답 쌍(challenge-response pair; CRP)들로서 지칭된다. 이러한 맵 F를 설명하기 위해, 다음과 같이 아래의 표기법이 사용될 수 있다:
여기서 C,R은 각각 챌린지들 및 응답들을 나타내고 는 PUF에 의해 생성될 수 있는 형태 (C,R)의 모든 챌린지-응답 쌍들의 세트이다.
PUF의 고유한 물리적 특성들은 통상적으로 실리콘 칩들과 같은 물리적 디바이스들의 제조 시에 내재된 랜덤 프로세스 변동들의 결과이다. 통상적으로, PUF에 대해 다음과 같은 가정이 이루어진다:
1. 임의의 형태의 분석에 의해 물리적 시스템의 파라미터들을 완전히 결정하는 것은 다루기 어렵고; 및
2. 물리적 시스템의 파라미터들은 PUF로서 사용되는 디바이스의 오리지널 제조자를 포함하여 어떠한 당사자에 의해서도 알려지지 않는다. 이 가정은 종종 제조자-저항(manufacturer-resistance)으로서 지칭된다.
이러한 가정들은, 임의적 챌린지들에 대한 예측 불가능하지만 결정론적인 응답을 생성하는데 PUF가 사용되도록 허용한다. 이 챌린지-응답 프로세스는 도 3에 예시된 바와 같이 물리적 흑색 박스처럼 PUF를 취급한다.
도 3은 물리적 흑색 박스로서 모델링된 PUF(302)를 도시한다. 제출 당사자(103S)는 PUF(302)에 대한 입력으로서 챌린지 C를 제출하고, 응답으로 PUF(302)는 대응하는 응답 R을 생성한다. 제출 당사자는, PUF(302) 자체가 구현되는 디바이스와 동일하거나 상이한 디바이스일 수 있는 제출 당사자의 컴퓨터 디바이스(미도시)와 같은 디바이스로부터 챌린지를 제출한다.
제출 당사자(103S)는 타겟 당사자 또는 디바이스의 아이덴티티에 링크된 예상된 응답들의 세트를 설정하기 위해 설정 페이즈(추후에 논의되는 예들)의 부분으로서 챌린지-응답(CR) 쌍들을 생성하는 당사자일 수 있다. 또는, 제출 당사자(103S)는 생성된 응답이 예상된 응답과 매칭된다는 것을 검증하고 이에 따라 PUF를 소유한 타겟 당사자 또는 PUF(302)를 포함하는 타겟 디바이스의 아이덴티티를 검증하기 위해 추후 검증 페이즈에서 챌린지를 제출하는 검증 당사자일 수 있다.
다른 예시적인 시나리오에서, 제출 당사자(103S)는 (예컨대, 블록체인 트랜잭션에 서명하기 위해) 블록체인 애플리케이션과 같은 암호화 애플리케이션에서 사용하기 위해 생성된 응답을 키로서 사용하거나 키를 생성하기 위한 시드로서 사용하고자 하는 당사자일 수 있다.
도 4는 PUF(302)에 대한 인터페이스의 예를 포함하는 시스템을 도시한다. 시스템은 프로세서(402) 및 PUF(302)를 포함한다. 인터페이스는, 메모리에 저장되고 프로세서(402) 상에서 실행되도록 배열된 인터페이스 로직(404)을 포함한다. 인터페이스 로직(404)이 저장되는 메모리는 하나 이상의 저장 매체들(예컨대, 자기 매체 이를테면, 자기 디스크 또는 테이프, 또는 전자 매체 이를테면, ROM, EPROM, EEPORM, 플래시 메모리, SRAM, DRAM 등)을 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다. 프로세서(402)는 하나 이상의 프로세싱 유닛들(예컨대, 범용 프로세서 이를테면, CPU, 또는 애플리케이션 특정 가속기 프로세서 이를테면, GPU, DSP 또는 암호화-프로세서)을 포함할 수 있다. 또한, 인터페이스 로직(404)이 전용 하드웨어 회로, 또는 구성 가능하거나 재구성 가능한 회로 이를테면, PGA 또는 FPGA에서 부분적으로 또는 전체적으로 구현될 수 있다는 것이 배제되지 않는다.
제출 당사자(103S)는 인터페이스 로직(404)을 통해 PUF(302)에 챌린지 C를 제출하기 위해 디바이스(미도시)를 사용한다. 제출 당사자(103S)에 의해 사용되는 디바이스는 예컨대, 프로세서(402)가 구현되는 외부 컴퓨터 디바이스 또는 동일한 컴퓨터 디바이스인 컴퓨터 디바이스일 수 있다. 그 후, PUF(302)는 대응하는 응답 R을 인터페이스 로직(404)을 통해 제출 당사자(302)의 디바이스로 다시 리턴한다. 추후에 더 자세히 논의되는 일부 실시예들에서, 인터페이스 로직(404)은 PUF(302)에 대한 액세스를 특정 당사자들, 예컨대, 패스워드, PIN 또는 바이오메트릭 정보와 같은 인식된 크리덴셜들을 제시할 수 있는 당사자들로만 제한하는 액세스 제어 로직(406)을 포함할 수 있다. 그리고/또는, 프로세서(402)를 포함하는 디바이스에 대한 물리적 인터페이스는 이를테면, 인가된 사람만 액세스할 수 있는 방 또는 콤플렉스(complex)에 위치되게 하거나 잠긴 상자 또는 캐비닛에 유지되게 함으로써 제한될 수 있다. 그러나 대안적인 시스템들에서, 인터페이스 로직(404)은 임의의 당사자가 챌린지들로 질의하는 데 이용 가능하도록 만들어질 수 있다.
PUF의 챌린지-응답 프로세스는 선택한 응답들로부터 이들 챌린지들을 추출함으로써 의사-랜덤 데이터 값들의 생성을 허용한다. 예컨대, PUF들은 암호화에 사용될 랜덤 반복 가능 데이터를 추출하기 위한 키-생성기들로서 사용될 수 있다. PUF(302)는 결정론적이고 반복 가능한 방식으로 작동하여서, PUF는 다수의 별개의 경우들에 동일한 챌린지가 주어지면 동일한 응답을 산출할 것이라는 것에 주의한다.
PUF들로서 사용될 수 있는 다수의 상이한 물리적 시스템들이 존재하고 이러한 시스템들을 사용하여 PUF들의 다수의 상이한 구현들이 존재한다. PUF의 예시적인 예는 기포들을 포함하는 광학 매체이며, 이는 레이저에 의해 프로빙될 때, (i) 레이저의 포지션 및 (ii) 광학 매체의 소규모 파라미터들에 의해 결정론적으로 결정되는 응답 회절 또는 '스페클(speckle)' 패턴을 생성한다.
1.1. PUF들의 클래스들
1.1.1 약한 PUF: 약한 PUF들은 작은 챌린지-응답 공간을 가짐으로써 특징화되고, 대부분은 CRP 공간의 크기가 | |=1이 되도록 단일 챌린지만을 갖는다. 일반적으로 약한 PUF에 대한 챌린지-응답 공간은 차수 O(n)로 간주되며, 여기서 n은 제어 불가능한 제조 변동들에 영향을 받는 PUF 내 구성요소들의 수이다.
약한 PUF들의 경우에, 통상적으로, PUF의 응답들에 대한 액세스가 제한된다고 또한 가정된다. 이는, 약한 PUF에 의해 서비스되는 소수의 CRP들로 인해, 적대자가 합당한 시간에 이러한 모든 쌍들을 열거할 수 있고 이에 따라 PUF의 거동을 에뮬레이트하거나 '스푸핑'할 수 있기 때문이다. 이 제한은 때로는, 약한 PUF들의 거동을 논의할 때 제한된 챌린지-응답 인터페이스로서 지칭된다.
이러한 특성들은 약한 PUF들을 키-생성기로서 암호화 애플리케이션에서 사용하기에 가장 자연스럽게 적합하게 만들며, 여기서 PUF에 의해 생성된 하나(또는 소수)의 CRP(들)는 암호화 동작들을 위해 이를테면, 온-디바이스 비-휘발성 메모리(NVM)를 암호화하기 위해 또는 HMAC 대칭 키로서 사용하기 위해 개인 키로서 사용될 수 있다. 이러한 경우들에서, PUF의 응답으로부터 도출된 키는 비밀로 유지되고, 수행된 암호화 프로세스의 보안 및 또한 PUF 그 자체의 보안 둘 모두를 위해 디바이스의 소유자에게만 알려져야 한다.
약한 PUF의 지배적인 그리고 널리 구현된 예는 SRAM PUF이며, 여기서 'SRAM'이라는 용어는 '정적 랜덤-액세스 메모리'를 지칭한다. SRAM PUF의 설계는 SRAM 칩들의 '파워-온(powered-on)' 상태에서의 변동을 활용하며, 이는 각각, 칩이 파워-온될 때 칩의 SRAM 셀이 '0' 또는 '1' 상태에 있는 변동들로 인해 고유한 핑거프린트를 갖는다.
이 경우에, PUF 구성은 (즉, SRAM 칩을 파워-온함으로써) PUF를 프로빙하기 위한 하나의 고정 모드 및 이에 따라 단 하나의 CRP만 존재하기 때문에 약한 것으로 간주된다. 이 경우에, 하나의 그리고 유일한 '챌린지'는 SRAM 칩에 전력을 공급하는 것이며, 응답은 파워-온 상태로부터 도출된 고유한 핑거프린트이다. 응답의 비밀성을 보장하기 위한 액세스 제어는 또한, SRAM PUF가 사용되는 디바이스 상의 적소의 기존 메모리 액세스 제어 정책 또는 메커니즘, 또는 디바이스 상에서 사용되는 대안적인 메커니즘들을 사용하여 구현될 수 있다.
이를테면, SRAM PUF의 경우에 일부 PUF 구현들의 특징은 PUF들에 의해 생성된 응답들에서 오류-정정을 사용하여, 동일한 챌린지가 조건-불변 및 시간-불변 방식으로 동일한 응답을 산출할 것을 보장한다는 것이다. 이러한 오류-정정 기술들의 세부사항은 당업자들에게 알려져 있다. 일부 경우들에서, 오류-정정 프로세스는 오류-정정을 용이하게 하기 위해 나중에 요청 시 생성되는 응답과 결합되는 헬퍼 데이터(helper data)의 소스를 제공하기 위해 PUF 디바이스들이 초기에 '등록'될 것을 요구할 수 있다.
1.1.2. 강한 PUF들: 약한 PUF들과 대조적으로, 강한 PUF들은 활용될 수 있는 가능한 챌린지-응답 쌍들(CR-쌍들 또는 CRP들)의 큰 공간을 가짐으로써 특징화된다. CRP들의 이 큰 공간은, 적대자가 다항 시간(polynomial time)에 강한 PUF의 도메인 내의 모든 챌린지-응답 쌍들을 열거하는 것이 실행 불가능한 것으로 간주된다는 것을 의미한다. 이 특성은 강한 PUF들이 일반적으로 보호되지 않는 챌린지-응답 인터페이스를 가질 수 있음을 의미하는데, 그 이유는 적대자가 PUF에 자유롭게 액세스하는 능력은 약한 PUF들에 해당했을 바와 같은 PUF의 열거 및 스푸핑을 허용함으로써 그의 보안을 손상시키지 않을 것이기 때문이다. 이 클래스의 PUF들은 또한 ΦF의 큰 서브세트를 알고 있는 적대자의 관점에서도, 예측 불가능한 응답들을 생성하는 것으로 여겨지고, 이는 강한 PUF들이 큰 도메인을 통해 암호화 해시 함수와 보다 유사하게 작동한다는 것을 의미한다.
그러나 챌린지 C가 제시될 때 강한 PUF에 의해 응답 R만이 제공되어야 하고 PUF의 내부 작동 또는 동작에 대한 어떠한 다른 정보도 프로세스에서 누출되어서는 안 된다는 제한이 강한 PUF들에 가해진다. 이 제한은 적대자가 PUF의 거동을 뒷받침하는 물리적 시스템을 특성화하려고 시도할 수 있는 다양한 분석 공격들을 완화하기 위한 것이다. 이들은 종종 문헌에서 모델링 공격들로서 지칭된다.
약한 PUF들과 유사하게, 일부 강한 PUF 구성들은 디바이스들에 의해 생성된 응답들의 정확성을 보장하기 위해 오류 정정 기술들에 의존할 수 있다.
강한 PUF들의 기존의 메인 애플리케이션들은 내재적 챌린지-응답 메커니즘을 사용하여 시스템 인증 및 식별을 용이하게 하는 것이다. 이러한 메커니즘들은 직접 두 당사자들 간의 공유 비밀들로서 CRP들의 생성을 수반하는 프로토콜들에 의존하며, 종종 적어도 한 당사자가 다른 당사자에 대한 인증 토큰들로서 사용되도록 CRP들의 테이블을 미리 생성(초기 설정)하도록 요구한다.
강한 PUF 구현의 가장 이른 예들 중 하나는 광학 PUF 시스템이었다. 이 구성에서, PUF는 입사광을 산란시키는 제조 변동들의 결과로서 랜덤으로 분포된 물리적 불완전성들을 포함하는 광학 매체를 포함한다.
이 PUF 구조는 광 산란 매체로 지향되는 레이저 빔에 의해 프로빙될 수 있다. 이 경우에, 입사 빔의 방향 및 편광은 챌린지를 형성하고, 관찰된 산란 패턴이 PUF 응답으로서 취해진다.
그러나 이 강한 PUF 구성은, 측정 디바이스가 PUF 디바이스의 나머지 부분과 별개이고 반도체 구성요소들과 직접 통합하기가 또한 어렵다는 사실로 인해, 구현하기 복잡하다. 이는 장치 그 자체와 연관된 비용들 및 일상적인 애플리케이션을 위한 장치의 유용성을 감소시키는 어레인지먼트의 휴대성의 결여에 추가된다.
이러한 이슈들 중 일부를 극복하는 APUF(Arbiter PUF)로서 알려진 전기 통합식 강한 PUF가 이후 제안되었다. 이 구조는 신호 다중화를 활용하고 전기 구성요소들에서의 런타임 지연을 활용한다. 다수의 다른 강한 PUF 구성들이 동시에 제안되었지만, 다수는 널리 사용하기 위한 실질적인 적합성이 부족하고, 다수는 보안 및 잠재적 공격 벡터들과 관하여 연관된 약점을 갖는다. 예컨대, 매우 문제가 있는 잠재적인 공격은 중간자 공격(man-in-the-middle attack)으로, 이를 통해 공격자는 평문으로 제출된 챌린지들을 가로채고 보증된 컴퓨테이션들을 스푸핑할 수 있다.
1.1.3. 제어된 PUF들: CPUF(controlled PUF)로서 알려진 PUF의 제3 클래스는 기존의 강한 PUF 구조들을 개선하지만 이들을 빌딩 블록으로서 사용한다. 이러한 PUF들은 강한 PUF를 사용하고 PUF에 대한 액세스를 제한하는 부가적인 제어 로직을 적용하며, 이는, 보통은 보호되지 않은 챌린지-응답 인터페이스를 가질 수 있는 비-제어(non-controlled) 강한 PUF로부터 제어된 PUF들 구별한다.
도 4에 도시된 바와 같이, 이제 더 큰 PUF 디바이스의 일부인 PUF에 적용된 제어 로직(406)은 PUF(302) 그 자체에 대한 액세스를 중재할 수 있다. 이는 제어 로직 구성요소(406)가 어느 챌린지들이 PUF에 제시될지를 제한할 수 있을 뿐만 아니라, 후속 응답들이 사용자에게 어떻게 드러날지를 제어할 수 있음을 의미한다.
CPUF 구성에서, 바람직하게는, 제어 로직 구성요소(406)는 강한 PUF 구성요소 내에 임베딩되거나 둘러싸여야 한다. CPUF의 일 정의에 따르면, PUF는 분리할 수 없는 방식으로 PUF에 물리적으로 링크된 알고리즘을 통해서만 액세스될 수 있는 경우(즉, 알고리즘을 우회하려는 시도는 PUF의 파괴로 이어질 것임) 제어되는 것으로 여겨진다. 이 임베딩은 제어 로직의 프로빙을 훨씬 더 어렵게 만들어야 한다.
이는 PUF 구성요소와 제어 로직 구성요소 간에 상호-유익한 관계를 설정할 것이어서, 서로 일 유형의 공격을 완화할 수 있다. 즉, PUF 디바이스 내의 제어 로직의 캡슐화 그 자체는, 물리적 또는 침입 공격들이 PUF 구성요소를 복구할 수 없을 정도로 손상시키고 그의 응답을 변경할 것이기 때문에 이들로부터 제어 로직을 보호하는 반면, 제어 로직은 CRP들 또는 PUF 그 자체의 기본이 되는 내부 물리적 시스템에 대한 다른 정보를 추출하기 위한 프로토콜 레벨 공격들로부터 PUF 구성요소를 자연스럽게 보호한다.
CPUF들의 애플리케이션들은 강한 PUF들과 거의 동일하지만, 보다 강력한 방식으로 달성될 수 있다. 특히, 보증된 컴퓨테이션들 및 실행 증명이 위에서 약술된 프로토콜들로 쉽게 달성될 수 있다.
강한 APUF(Arbiter PUF)의 설계를 확장한 CPUF의 초기 예는 제어 로직이 이미 설명한 방식으로 APUF 그 자체와 얽히도록 요구하여서, 제어 로직 및 APUF는 상이한 유형들의 공격으로부터 서로를 상호 보호한다. 제어된 APUF 설계는 시스템의 트랜지언트 응답을 통합함으로써 집적 회로(IC)로부터의 단일 정적 응답으로부터 CRP들의 큰 세트를 생성한다.
제어된 PUF의 다른 알려진 예는 PUF-FSM 구조이다. 이것은 APUF 구성요소 그 자체의 챌린지-응답 인터페이스에 대한 액세스를 제한하는 제어 로직으로서 작용하는 FSM(finite state machine)과 함께 강한 PUF(실제로는 APUF)를 포함한다.
1.2. 논의
1.2.1. 실용성: 표준 CMOS(complementary metal-oxide semiconductor) 구성요소와 통합할 수 있으면서도 실용적일 뿐만 아니라 경량인 강한 PUF들을 생성하는 것은 매우 난제라는 것이 본 문헌에서 인정된다. 반대로, SRAM PUF와 같은 약한 PUF들은 생산하기가 저렴하고 집적 회로 아키텍처들과 간단하게 결합될 수 있다.
1.2.2. PUF들에 대한 공격들: 제안되고 연구된 다수의 상이한 공격들이 존재하며, 여기서 상이한 공격들은 특정 PUF 구성들 또는 클래스들을 타겟팅할 수 있다. 가장 널리 알려진 공격 유형들 중 일부는 다음과 같이 나열된다.
· MITM 공격들 ― 이러한 공격들은 제어되지 않는 강한 PUF들과 같은 PUF들을 타겟팅하며, 여기서 특히 보증된 컴퓨테이션을 위해 사용되는 경우, 적대자가 PUF의 응답을 가장(impersonate)하거나 스푸핑하기 위해 평문으로 만들어진 챌린지들을 가로챌 수 있다.
· 모델링 공격들 ― 이러한 공격들은 APUF와 같은 다수의 강한 PUF 구성들에 대한 취약점을 입증하였다.
· 선택된 챌린지 공격들 ― 이러한 공격들은 또한 강한 PUF들에 영향을 미치고 부분적으로 CPUF 아키텍처들로 이동하는 동기가 된다.
해당 PUF 시스템의 보안을 약화시키는 익스플로잇(exploit)들을 허용하는 다양한 PUF 설계들이 가진 다른 이슈들 이를테면, 일부 경우들에서 고유성의 부족이 또한 존재한다.
1.2.3 보안 모델들: PUF 구성들의 보안 모델들은 그들의 CRP들이 발생하는 랜덤 프로세스 또는 제조 변동들이 제조자-저항성이고 분석 수단에 의해 PUF의 물리적 시스템을 특성화하는 것은 다루기 어렵다는 가정과 같은 일부 유사점들을 공유하는 경향이 있다. 그러나 3개의 메인 PUF 클래스들에 대한 보안 모델들에서 일부 차이들이 또한 존재한다.
· 약한 PUF들 ― 약한 PUF의 보안은 그의 CRP들이 비밀로 유지된다는 가정에 의존하고, 그렇지 않으면 디바이스는 열거되고 가장될 수 있다. 이는, 엔트로피의 소스를 제공하고 암호화 동작들을 위해 해당 엔트로피의 저장을 안전하게 하는데 약한 PUF가 사용될 수 있지만, 실제 CRP 응답 데이터 그 자체는 프로세스에서 공개적으로 드러나지 않는다는 것을 의미한다.
· 강한 PUF들 ― 강한 PUF의 보안은, 그의 CRP 공간이 챌린지 비트들의 수 면에서 지수적이 되는 경향이 있고, 이에 따라 전체 공간의 열거가 합리적인 시간프레임 내에 실행 불가능하다는 사실에 의존한다. 이는 약한 PUF들의 경우와 달리, 강한 PUF의 CRP 응답들이 디바이스에 의해 드러날 수 있음을 의미한다.
· 제어된 PUF들 ― 제어된 PUF의 보안은 프로토콜 레벨 공격들로부터 보호하는 제어 로직 및 물리적 공격들로부터 보호하는 PUF 그 자체의 결합에 의해 결정된다.
약한 PUF들과 차별되는 강한 PUF들의 두 가지 특성들은 다음과 같다. 첫째, 강한 PUF는 CRP들의 큰 세트를 갖는다. 이는, 강한 PUF는 큰 챌린지 공간 을 가지며, 여기서 약한 PUF는 통상적으로 그에 대해 사용 가능한 단 하나(또는 소수)의 챌린지(들)를 갖는다는 것을 의미한다. 또한 강한 PUF는 임의의 그리고 모든 알려진 CRP들에 대해 예측 불가능한 것으로 간주된다. 즉, 임의적 수의 CRP들에 대한 지식은 새로운 챌린지의 응답을 예측하는 데 어떠한 이점도 제공하지 않는다.
둘째, 강한 PUF는 보호되지 않은 챌린지-응답 인터페이스를 가질 수 있다. 주어진 강한 PUF는 챌린지-응답 인터페이스에 대한 액세스를 제한하기 위해 액세스-제어 로직을 요구하지 않는다고 가정된다. 이는, PUF에 대한 물리적 액세스를 갖는 임의의 당사자는 PUF 또는 그의 물리적 특성들에 대한 어떠한 부가적인 정보도 드러내지 않고 임의적으로 챌린지들을 적용하고 응답을 획득할 수 있음을 의미한다.
제어된 PUF는 보호된 챌린지-응답 인터페이스를 갖지만 강한 PUF와 같은 큰 챌린지-응답 공간도 갖는다.
2. 확장된 PUF(ePUF)
다음은 기본 PUF(302)의 주어진 챌린지-응답(CR) 쌍으로부터 다수의 2차 CR 쌍들을 생성함으로써 PUF의 CR 공간을 확장하기 위한 시스템 및 방법을 개시한다. 이는 본 명세서에서 "확장된 PUF" 또는 "ePUF"로서 지칭될 수 있다. 이 아이디어는 통상적인 강한 PUF 메커니즘(이를테면, 레이저, 광학 매체 및 센서를 요구하는 광학 PUF)의 복잡성 또는 비실용성 없이, 예컨대, 단 하나 또는 제한된 수의 내재적 CR 쌍들을 갖는 약한 PUF의 챌린지-응답 공간을 확장하는 데 사용될 수 있다. 그러나, 원칙적으로, 개시된 기술들은 약한, 강한, 제어된 또는 다른 것이든 간에, 임의의 기본 PUF의 CR 쌍들의 수를 확장하기 위해; 또는 난독화 또는 재사용성과 같은 다른 목적들을 위해 임의의 PUF의 CR 쌍을 변형하는데 보다 일반적으로 사용될 수 있다.
도 5a는 본 명세서에 개시된 실시예들에 따른 확장된 PUF(ePUF)(500)를 도시한다. ePUF(500)는 예컨대, 종래의 약한 PUF일 수 있는 성분 기본(constituent base) PUF(302)를 포함한다. ePUF(500)는 변환 함수(502), 예컨대, 암호화 해시 함수(예컨대, SHA256 등)와 같은 해시 함수를 더 포함한다. ePUF(500)는 또한 인터페이스 로직(404')을 포함하며, 이는 도 4와 관련하여 논의된 인터페이스 로직(404)과 유사할 수 있지만 부가적인 인터페이싱 기능을 갖는다. 인터페이스 로직(404') 및 변환 함수(502)는 소프트웨어, 예컨대, 메모리에 저장되고 (변환 함수(502) 및 인터페이스(404')의 부가적인 기능을 실행하지만, 도 4에 도시된 바와 같은) 프로세서(402) 상에서 실행되도록 배열된 임베딩된 펌웨어에서 구현될 수 있다. 인터페이스 기능(404') 및 변형 로직(504)이 저장되는 메모리는 하나 이상의 저장 매체들(예컨대, 자기 매체 이를테면, 자기 디스크 또는 테이프, 또는 전자 매체 이를테면, ROM, EPROM, EEPORM, 플래시 메모리, SRAM, DRAM, 퓨즈 래치들 등)을 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다. 인터페이스 기능(404') 및 변형 로직(504)이 실행되는 프로세서는 하나 이상의 프로세싱 유닛들(예컨대, 범용 프로세서 이를테면, CPU, 또는 애플리케이션 특정 가속기 프로세서 이를테면, GPU, DSP 또는 암호화-프로세서)을 포함할 수 있다. 또한, 인터페이스 로직(404') 및/또는 변환 함수(502)가 전용 하드웨어 회로, 또는 구성 가능하거나 재구성 가능한 회로 이를테면, PGA 또는 FPGA에서 부분적으로 또는 전체적으로 구현될 수 있다는 것이 배제되지 않는다.
인터페이스 로직(404')은 변환 함수(502)에 그리고 또한, 선택적으로 기본 PUF(302)에 동작 가능하게 커플링된다. 기본 PUF(302)는 변환 함수에 동작 가능하게 커플링된다. 인터페이스 로직(404')은, ePUF(500)가 구현된 동일한 디바이스 또는 외부 디바이스일 수 있는 제출 당사자(103S)의 디바이스(도 5a에 도시되지 않음), 예컨대, 컴퓨터 디바이스로부터 입력을 수신하고 그에 출력을 제공하도록 배열된다. 제출 당사자(103S)는 설정을 수행하고, 향후 참조를 위해 아이덴티티에 링크될 일 세트의 챌린지들 및 예상된 응답들을 생성하기 위해 ePUF(500)를 사용하는 당사자일 수 있고; 또는 생성된 응답이 이전에 설정된 예상된 응답과 매칭되는지를 검증하기 위해 나중에 PUF를 사용하는 검증 당사자(또는 검증 당사자에게 제공하기 위해 응답을 생성하는 챌린저)일 수 있다. 다른 예시적인 애플리케이션에서, 제출 당사자(103S)는 ePUF(500)를 사용하여 키를 생성하기 위한 시드로서 또는 키로서 사용하기 위한 응답을 생성할 수 있다. 예컨대, 이것은 메시지를 암호화하거나 서명하기 위한 예컨대, 블록체인 트랜잭션의 일부에 서명하기 위한 암호화 키로서 사용될 수 있다.
기본 PUF(302)는 입력으로서 "1차" 챌린지 Cw를 수신하는 것에 대응하여, 출력으로서 "1차" 응답 Rw를 생성하도록 동작 가능하다. "1차" 챌린지-응답(CR) 쌍은 본 명세서에서 기본이 되는 성분 PUF(302)의 기본 또는 "천연"(즉, 내재적) CR 쌍을 지칭한다. 일부 실시예들에서, 기본 PUF(302)는 약한 PUF와 유사하게 단일 챌린지 Cw에 대한 응답으로 단일 기본(즉, 1차) 응답 Cw만을 생성할 수 있을 수 있다.
동작에서, 인터페이스 로직(404')은 제출 당사자(103S)의 디바이스로부터 적어도 "2차" 챌린지 Ci를 포함하는 챌린지 데이터(챌린지 입력)를 수신한다. 또한, 1차(기본) 챌린지 Cw는 1차(기본) 응답 Rw를 생성하기 위해 기본 PUF(302)에 입력된다. 실시예들에서, 제출 당사자(103S)는 ePUF(500)에 대한 챌린지 데이터 입력에 기본 챌린지 Cw를 포함하도록 요구되고, 인터페이스 로직(404')은 기본 응답 Rw를 생성하기 위해 이를 기본 PUF(302)로 라우팅한다. 그러나, 다른 실시예들에서, 1차 챌린지 Cw가 메모리, 퓨즈 래치들 또는 전용 회로와 같은 내부 소스로부터 기본 PUF(302)로 입력되는 것이 배제되지 않는다. 어느 쪽이든, 변환 함수(502)는 입력으로서: a) 제출 당사자로부터 입력 챌린지 데이터에서 수신된 바와 같은 2차 챌린지 Ci, 및 b) 기본 PUF(302)에 의해 생성된 바와 같은 1차 응답 Rw를 수신하도록 배열된다. 변환 함수(502)는 이들의 조합을 변환 함수(502)에 입력된 Ci 및 Rw의 특정 조합에 대응하는 고유한 개개의 "2차" 응답 Ri에 결정론적으로 매핑하도록 구성된 함수이다. 2차 챌린지 응답 쌍들은, 이들이 부분적으로 1차 응답 Rw에 기초하여 생성되는 1차(기본) CR 쌍의 상단에 계층화(layered)된다는 의미에서 본 명세서에서 "2차"로 지칭될 수 있다. 이들은 또한 "확장된 계층" 또는 "보완적인" 챌린지들 및 응답들이라 칭해질 수 있다.
실시예들에서, 변환 함수(502)는 해시 함수, 예컨대, SHA 또는 DSA 해시 함수와 같은 암호화 해시 함수를 포함한다. 해시 함수가 사용될 수 있는 적어도 2개의 상이한 방식들이 존재한다. 첫 번째에서, 변환 함수(502)는 프리이미지(preimage)의 해시를 포함하고, 여기서 프리이미지는 수신된 2차 챌린지 Ci 및 생성된 1차 응답의 조합(예컨대, 컨케터네이션(concatenation))을 포함한다. 즉 Ri = H(Ci||Rw)이다. 또는, 보다 일반적으로 프리이미지는 다른 요소들도 및/또는 컨케터네이션 이외의 다른 형태의 조합도 포함할 수 있다.
제2의 대안적인 접근법에서, 변환 함수(502)는 프리이미지의 해시를 포함하고, 여기서 프리이미지는 수신된 2차 챌린지를 포함하고 해시 함수는 생성된 1차 응답으로 초기화된다. 즉 Ri = H(Ci)이며, 여기서 H는 Rw에 의해 초기화된다. 또는, 다시 더 일반적으로, H의 프리이미지는 적어도 Ci를 포함하는 한 다른 요소들을 물론 포함할 수 있다. Rw에 의해 초기화된다는 것은 해시 함수 H에 의해 정의된 출력들에 대한 프리이미지의 매핑 자체가 Rw에 의존할 것임을 의미한다. 반면에, 이전의 경우에, H에 의해 야기된 출력들에 대한 프리이미지의 매핑은 Rw에 의존하지 않고 오히려 프리이미지가 Rw에 의존한다. 즉, 이전 단락에서, 프리이미지는 Rw에 의존하고, 이 단락에서 H만이 Rw에 의존한다.
여전히 보다 일반적으로, 원칙적으로, ePUF(500)에 의해 수용될 도메인의 각각의 가능한 Ci에 대해, Ci 및 Rw의 조합을 Ri의 개개의 값에 결정론적으로 그리고 고유하게 매핑하는 한, 임의의 함수가 사용될 수 있다.
2차 챌린지 Ci는 다수의 상이한 가능한 값들 중 임의의 것을 취할 수 있고, 변환 함수(502)는 특정 수신된 2차 챌린지 Ci의 값 및 1차 응답 Rw의 값에 기초하여 이들을 2차 응답 Ri의 개개의 값들에 매핑할 것이다. 따라서 ePUF(502)는 주어진 1차(기본) CR 쌍의 CR 공간을 다수의 2차 CR 쌍들로 확장할 수 있다. 실시예들에서, Ci는 사용된 변수에 의해 지원되는 값들의 범위 내에서 어떠한 임의적 값도 취할 수 있다(예컨대, Ci가 32비트 정수인 경우, 이는 232개의 값들 중 임의의 것을 취할 수 있음).
일부 실시예들에서, ePUF(500)는 도 5b에 도시된 바와 같이 대안적인 동작 모드에서 동작할 수 있을 수 있다. 이 경우에, 인터페이스 로직(404')은 입력 챌린지 데이터가 1차 챌린저 Cw만을 포함함을 검출한다. 이에 응답하여, 이는 Cw의 수신된 값을 기본 PUF(302)로 라우팅하고 결과적인 1차 응답 Rw를 제출 당사자(103S)의 디바이스로 역으로 라우팅한다. 즉, 이 실시예에서 ePUF(500)는 또한 "레거시" 또는 "비-확장" 모드에서 동작할 수 있다.
선택적으로, 애플리케이션에 의존하여, 인터페이스 로직(404')은 이를테면, 인가된 당사자에 매핑되는 것으로 인식하는 크리덴셜들(예컨대, 패스워드, PIN 또는 바이오메트릭 입력)을 제시할 수 있는 당사자에게만 액세스를 승인함으로써 제한된 수의 가능한 제출 당사자(103S)에게만 액세스를 제한하는 액세스 제어 로직(406)을 포함할 수 있다. 이 경우에, ePUF(500)은 CPUF의 한 형태로서 간주될 수 있다. 대안적으로, ePUF(500)에 대한 물리적 인터페이스는 이를테면, ePUF(500)를 포함하는 디바이스를 제한된 세트의 당사자들만이 액세스가 허용되는 방 또는 댁내(premises)에 유지함으로써, 또는 그 디바이스를 잠긴 박스, 캐비닛 또는 방에 유지함으로써 법적으로 또는 물리적으로 보호될 수 있다. 이 경우에, ePUF(500)은 일종의 확장된 약한 PUF와 유사하게 간주될 수 있다.
PUF에 대한 인터페이스에 관한 이러한 물리적 제한들에 대한 대안으로 또는 추가로, 액세스는 또한 1차 챌린지에 대한 액세스를 제한함으로써 제한될 수 있다. 예컨대, 타겟 당사자(103T)("앨리스", 나중에 논의됨)는 Cw를 아는 유일한 당사자일 수 있다.
그러나 다른 대안으로서, 인터페이스 로직(404')에 대한 액세스는 제한되지 않을 수 있으며, 예컨대, 임의의 당사자가 인터넷을 통해 그에 대해 자유롭게 질의할 수 있다. 이 경우에, ePUF(500)는 약한 기본 PUF 메커니즘을 확장함으로써 생성된 일종의 강한 PUF(502)와 유사하게 간주될 수 있다.
도 5a에 도시된 어레인지먼트는 본 명세서에서 확장된 PUF(ePUF)로서 지칭되는 PUF 디바이스의 새로운 하이브리드 클래스를 제공하며, 이는 나중에 제시되는 것과 같은 다수의 애플리케이션들을 위한 프레임워크로서 일반적으로 사용될 수 있다.
ePUF는 다음의 3개 모듈들: 본질적으로 약한 PUF와 같은 기본 PUF(302); 암호화 해시 함수와 같은 변환 함수(502); 및 인터페이스 로직 모듈(404')을 함께 포함하는, 도 5a에 도시된 바와 같은 물리적 디바이스 또는 시스템으로서 정의될 수 있다. 논의된 바와 같이, ePUF(500)는 암호화 해시 함수와 같은 변환 함수(404')를 도입함으로써 정규 PUF(302)에 대해 '확장'될 수 있는데, 그 이유는, 이것이 기본 약한 PUF(302)에 대해 로부터, 약한 PUF의 물리적 시스템보다는 해시 함수의 선택에 의해 대신 경계가 정해지는 로 고유한 챌린지 공간 의 크기를 증가시키기 때문이다.
강한 PUF의 큰 CRP 공간과 약한 PUF의 실용성을 그 자체로 결합하는 시스템을 실현하는 아이디어는 이전에 탐구되었다. 강한 PUF의 캐릭터를 가진 시스템을 생성하기 위해 결합된 동작에서 다수의 FPGA-기반 약한 PUF를 사용하는 것이 알려져 있다. 여기서 의도는 부분적으로 기본 약한 PUF들의 CRP 공간을 '확장'하는 것이다. 그러나 이러한 성질의 기존 구성들은 실제로 제한된다. 위에서 언급된 FPGA 설계의 경우에, 시스템은 FPGA 상에 구축되어야 하며, 여전히 상대적으로 낮은 CRP 공간(~210)에 종속된다.
본 명세서에 개시된 ePUF 설계는, 기존의 약한 PUF(302)에 인터페이스 로직 구성요소(404') 및 암호화 해시 함수(또는 다른 그러한 변환 함수)(502)를 추가하기만 하면 된다는 점에서 극도로 경량으로 설계된다. 예컨대, SRAM PUF가 널리 사용되는 약한 PUF(302)로서 선택되는 경우, 2개의 나머지 모듈들(404', 502)의 추가는 상당한 오버헤드를 생성하지 않아야 하는데, 예컨대, 소프트웨어(예컨대, 펌웨어)에서 작은 알고리즘 또는 비교적 간단한 하드웨어 회로 조각으로 구현되어야 한다. 또한, ePUF(500)의 가능한 출력들의 공간은 선택된 해시 또는 변환 함수(502)의 범위로 확장되며, 이는 위의 공간보다 상당히 크다. 예컨대, SHA-256 해시 함수가 선택되는 경우, 가능한 출력들(그리고 이에 따라 CRP들)의 공간이 즉시 2256-1로 증가되고, 해시 함수 모듈 자체를 임베딩하는 것 이상으로 하드웨어 오버헤드를 스케일링할 필요가 없다.
도 5a는 ePUF(expanded PUF)(500)의 개략적 설계를 도시한다. 암호화 해시 함수가 사용되는 실시예들은 또한 ePUF(500)가 그의 CRP가 예측 불가능하다는 특성을 갖는다는 것을 의미하며, 이는 강한 PUF 시스템들에 대해서도 해당된다.
ePUF 디바이스의 제어 로직 요소(406)는 또한 이러한 구성에서 일반화될 수 있다. 제어 로직(406)은 예컨대, 애플리케이션에 적절한 경우, SRAM PUF와 유사한 물리적 보안으로서 간단하게 구현될 수 있다.
대안적으로, 제어 로직 모듈(406)은 CPUF들과 함께 사용되는 것과 유사한 소프트웨어 제어 모듈로서 구현될 수 있으며, 여기서 이는 실제로, PUF 디바이스 자체 내에 임베딩되어 이전에 논의된 캡슐화의 상호 보안 이익들을 제공한다. 그러나 여기에서 ePUF 설계가 특히 CPUF들의 설계와 차별되는 포인트는 제어 로직이 이러한 방식으로 구현되기 위해 어떠한 엄격한 요건도 없다는 것이다.
제어 모듈(406)에 대한 침입 공격이 반드시 ePUF 설계에서 약한 PUF 구성요소(302)의 거동을 변경한다고 가정할 필요는 없다. 대신, 이 요소의 구현은 사례별로 선택될 수 있다.
2.1. ePUF들에 대한 챌린지들 및 응답들
ePUF에 대응하는 챌린지-응답 쌍들 의 세트는 다음의 방식으로 정의될 수 있다:
여기서 (Cw,Rw)는 약한 PUF(302)의 기본 챌린지-및-응답에 대응하는 특권 CRP이고 맵 Fw는 약한 PUF의 고유한 물리적 특성들에 의해 정의된다. 쌍 (Cw,Rw)은 본 명세서에서 ePUF의 기본 또는 1차 쌍으로서 지칭될 수 있다. 반대로, 맵 F는 ePUF에 대해 선택된 암호화 해시 함수에 의해 정의된다. 도 5a-b는 ePUF(500)로부터 응답을 추출하는 것을 도시하며, 여기서(도 5b) 챌린지는 Cw만이고, (도 5a) 챌린지는 또한 Ci를 포함한다.
확장된 PUF의 일부 실시예들에서, 모든 챌린지들 는 기본 챌린지 Cw를 동반해야 하며, 기본 응답 Rw는 도 5a에 도시된 바와 같이 모든 다른 응답들 Ri를 생성하기 위한 프로세스에 통합된다.
ePUF를 사용하여 일반 CRP들을 생성하기 위해 도 5a에 묘사된 프로세스는 이 기본 비밀 쌍을 임의의 다른 임의적 챌린지 Ci에 적용하여 확장함으로써 기본 챌린지-응답 쌍(Cw,Rw)을 사용하도록 설계되었다. ePUF로부터 CRP들을 생성하는 데 사용되는 알고리즘이 결정론적 방식으로 기본 쌍(Cw,Rw)을 사용하는 경우 특정 용도로 맞춤화될 수 있다. getResponse( )로 표시된 이러한 알고리즘의 간단한 예는 다음과 같이 작성될 수 있다.
입력들:
1. 사용자/클라이언트로부터 를 획득함.
2. 인지를 체크?
i. 만약 그렇다면:
1. 를 획득하기 위해 로 약한 PUF 모듈을 프로빙함. 2. 로 세팅함.
ii. 만약 아니라면:
1. 를 및 구성요소들로 분리함.
2. 를 획득하기 위해 로 약한 PUF 모듈을 프로빙함.
3. 및 를 해시 함수 모듈로 전송함.
4. 를 컴퓨팅함
5. 로 세팅함
3. 를 리턴함
출력들:
함수 hash(Ci,Rw,H)는 암호화 해시 함수 H를 사용하여 해시 다이제스트를 컴퓨팅하는 데 사용되는 일반 함수이다. 함수 hash()는 다양한 방식들로 이를테면, 간단한 경우 단순히 를 컴퓨팅함으로써 구현될 수 있거나, 를 택싱 컴퓨팅(taxing computing)함으로써 구현될 수 있으며, 여기서 값 Rw는 해시 함수 H의 초기 벡터로 사용되었다. 어느 쪽이든, hash( )의 출력은 Ci 및 Rw 둘 모두에 의존한다.
도 5a 및 도 5b의 다이어그램들은 ePUF(500)에는 선택적으로 제어 로직 모듈(406)을 포함하는 인터페이스 로직(404')이 장비될 수 있음을 도시한다. 실시예들에서, 응답을 생성하는데 취할 수 있는 2개의 가능한 경로들이 있으며, 여기서 챌린지가 단순히 Cw일 때 도 5b의 경로가 사용되고, 챌린지가 Cw를 동반하는 새로운 값 Ci일 때 도 5a의 경로가 사용된다. 이는 결정론적이다.
개시된 ePUF 설계는 다음의 이점들 및/또는 다른 것들 중 임의의 것을 제공하기 위해 사용될 수 있다.
· 선택된 해시 함수의 도메인 및 범위에 의해 정의되는 큰 CRP 공간.
· PUF 자체로부터 제어 로직을 분리할 수 있는 유연성.
· 약한 PUF의 보안 프리미티브들.
이것은, 사용자는 CPUF 디바이스와 유사하게 ePUF 디바이스를 사용할 수 있지만, PUF에 대한 제어된 액세스는 (I) 약한 PUF의 기본 CRP(Cw,Rw)를 안전하게 저장하는 것, 그리고 (II) 의도된 사용자에게로만 PUF 디바이스에 대한 물리적 액세스를 제한하는 것 둘 모두를 포함한다. 이 모델에서, 기본 쌍(Cw,Rw)은 형태 (Ci,Ri)의 극도로 매우 다수의 다른 CRP들이 도출될 수 있는 마스터 키와 같이 작용하며, 여기서 Ci가 외부 또는 제3자에 의해 제출될 수 있다.
2.2. ePUF의 애플리케이션
ePUF 디바이스의 가능한 애플리케이션들(사용 사례들)은 크게 적어도 2개의 메인 카테고리로 분류될 수 있다:
1. 아이덴티티를 활동들 또는 컴퓨테이셔널 동작들에 링크하는 것; 및
2. 암호화 동작들을 위한 키-생성기로서 작용하는 것.
애플리케이션 1은 기존의 강한 PUF들에 의해 가장 일반적으로 구현되고, 2는 기존의 약한 PUF들에 의해 가장 일반적으로 구현된다. ePUF 구성이 각각의 특성들을 결합한다는 사실은 ePUF가 어느 하나의 애플리케이션에 동등하게 적합한 것으로 취급될 수 있음을 의미한다. 애플리케이션 1에서, 이점은 대부분의 강한 또는 제어된 PUF보다 일반적으로 ePUF를 사용하여 그러한 애플리케이션들을 실제로 훨씬 더 쉽게 구현할 수 있다는 것이다.
3. 아이덴티티 링키지 시스템
이 섹션에서, 사람 또는 기계 아이덴티티들을 PUF 디바이스들에 링크하기 위한 일반 프레임워크가 개시된다.
실시예들은 ePUF(expanded PUF)를 사용할 수 있다. 여기서 의도는, 다수의 상이한 사용 사례에 맞게 용도 변경될 수 있는 강력하면서도 매우 일반화되고 유연한 아이덴티티 시스템을 제공하는 PUF 아키텍처를 공식화하는 것이다. 이 구성에서 캡처하려는 특성들은 다음과 같다:
· 강한 PUF의 것에 필적하는 큰 CRP 공간;
· 약한 PUF의 것에 필적하는 실용성; 및
· CPUF의 것보다 유연한 제어 로직.
ePUF 설계는 다양한 아이덴티티-설정 프로토콜들에서 사용되는 PUF에 대한 기본 모델로서 사용될 수 있다. 실시예들은 프로세스에서 최종 사용자 또는 기계의 독립성을 허용할 수 있다. ePUF를 사용하도록 또한 용도 변경될 수 있는 기존 체계들이 설정 동안 PUF 디바이스에 직접 액세스하기 위해 신뢰할 수 있는 제3자에 의존하는 경우, ePUF-기반 제안된 시스템들은 PUF 디바이스의 최종 사용자가 아이덴티티를 대신 설정하고 설정 동안 제3자가 디바이스에 로컬로 또는 직접 액세스할 필요 없이 앞으로의 인증들에 참여하도록 허용할 수 있다.
일부 구현들은 공개 블록체인을 도입함으로써 이러한 아이덴티티-링키지 프로토콜들의 견고성을 개선하고 추가로 확장할 수 있다. 여기서 사용될 수 있는 2개의 개념들은, (A) 변조-방지(tamper-proof) CRP 관리 시스템으로서 블록체인의 사용, 및 (B) 아이덴티티-링키지 프로토콜들에 사용되는 요청-응답 메시지를 중재하고 효율적인 폐지 시스템을 제공하기 위한 타임-스탬핑 서비스로서 블록체인 네트워크의 사용이다.
도 6은 본 명세서에 개시된 실시예들에 따른 아이덴티티 링키지 및 검증을 위한 예시적인 시스템을 도시한다. 도 7은 대응하는 방법을 도시한다.
시스템은 PUF 모듈(603), 타겟 당사자(103T)의 컴퓨터 장비(102T) 및 응답 데이터 저장소(601)를 포함한다. PUF 모듈(603)은 도 5a 및 도 5b와 관련하여 이전에 설명된 바와 같은 ePUF(500)를 포함하거나, 대안적으로 도 3 및 도 4와 관련하여 이전에 설명된 바와 같이 종래의 PUF(302) 또는 PUF에 종래의 인터페이스 로직(404)을 더한 것만을 포함할 수 있다. 응답 데이터 저장소(601)는 제3자 컴퓨터 장비(602)의 일부일 수 있고 신뢰할 수 있는 제3자에 의해 관리되거나 대신, 블록체인과 같은 분산 피어-투-피어 저장 매체일 수 있다. 제3자 장비(602)는 예컨대, 하나 이상의 지리적 사이트들에 위치된 하나 이상의 서버 유닛들을 포함하는 서버 장비를 포함할 수 있다(클라우드 저장 기술은 그 자체로 당업계에 알려져 있음). 시스템은 검증 당사자(103V)의 컴퓨터 장비(102V)를 더 포함할 수 있거나, 일부 대안적인 경우들에서, 검증 당사자는 PUF 모듈(603), 타겟 당사자의 컴퓨터 장비(102T) 또는 제3자 컴퓨터 장비(602)와 직접 상호작용할 수 있다.
검증 당사자(103V), 타겟 당사자(103T) 또는 제3자인지 여부에 관계없이, 사용자 또는 당사자(103) 등의 액션에 대한 본 명세서에서의 임의의 참조는 당사자가 해당 당사자의 컴퓨터 장비(102)를 통해 행동할 가능성을 커버한다. 간결함을 위해, 이는 매번 명시적으로 언급될 필요는 없을 것이지만, 암묵적으로 커버하는 것으로 이해될 것이다. 이는, A) 액션은 컴퓨터 장비에 대한 당사자에 의한 수동 사용자 입력의 제어 하에 수행되거나 이에 의해 트리거되거나, 또는 B) 액션은 당사자를 대신하여 컴퓨터 장비에 의해 자동으로 수행되는 가능성들 둘 모두를 커버한다(당사자가 액션을 수행한다고 언급하는 것은 반드시 해당 당사자의 인간 사용자가 수동으로 해당 액션을 착수한다는 것을 의미하는 것이 아니라, 당사자의 장비가 그/그녀를 대신하여 자율적으로 해당 액션을 수행한다는 의미일 수 있음). 의심의 여지를 없애기 위해, 당사자는 단일 개별 사람 또는 그룹 또는 사람들 또는 조직 예컨대, 회사, 자선 단체, 정부 기관, 시립 또는 학술 기관들을 지칭할 수 있다는 것에 또한 주의한다.
타겟 당사자(103T)의 컴퓨터 장비(102T)는 (예컨대, 제3자 장비(602)에 대한 연결에 의해) 응답 데이터 저장소(601)에 동작 가능하게 연결될 수 있다. 검증 당사자(103V)의 컴퓨터 장비(102V)는 (예컨대, 제3자 장비(602)에 대한 연결에 의해) 응답 데이터 저장소(601)에 동작 가능하게 연결될 수 있다. 타겟 당사자(103T)의 컴퓨터 장비(102T)는 검증 당사자(103V)의 컴퓨터 장비(102V)에 동작 가능하게 연결될 수 있다. 이러한 연결들 중 임의의 것은 하나 이상의 네트워크들, 예컨대, 인터넷 또는 모바일 셀룰러 네트워크와 같은 하나 이상의 광역 네트워크들을 통해 형성될 수 있다. 실시예들에서, 이러한 연결들 중 임의의 것은 개개의 보안 채널을 통해 형성될 수 있는데, 예컨대, 해당 두 당사자들 간에 공유되는 공유 비밀에 기초하여 설정될 수 있다. 본 명세서에서 두 당사자들이 임의의 방식으로 이를테면, 챌린지를 전송하거나 응답 다시 수신하는 등을 함으로써 통신한다고 언급될 때마다, 이것은 이들 통신들이 각자의 컴퓨터 장비(102V, 102T; 102T, 602; 또는 102V, 602) 사이의 임의의 적합한 직접 또는 네트워크 연결을 통해 수행될 수 있는 가능성을 커버한다는 것이 이해될 것이다. 간결함을 위해, 이는 매번 명시적으로 언급될 필요는 없을 것이지만, 암묵적으로 커버되는 것으로 이해될 것이다.
타겟 당사자(103T)는 그의 아이덴티티가 PUF 모듈(603)에 기초하여 검증되는 당사자이거나, PUF 모듈(603)에 기초하여 검증될 디바이스를 소유하거나 달리 그 디바이스를 담당하거나 연관되는 당사자이다. 검증 당사자(103V)는 검증을 수행하는 당사자이다. 다수의 검증 당사자들(103V)(이들 각각은 개개의 컴퓨터 장비(102V)를 통해 행동할 수 있음)이 있을 수 있지만, 예시의 편의를 위해, 단 하나만이 도 6에서 도시된다. PUF 모듈(603)은 타겟 당사자(103T)의 소유일 수 있다. PUF 모듈(603)은 그의/그녀의 컴퓨터 장비(103T)에 통합되거나, 예컨대, 주변 장치로서 또는 로컬 네트워크를 통해 또는 조합으로 이에 연결될 수 있다(예컨대, 인터페이스 로직(404/404')은 컴퓨터 장비(103T) 상에서 구현될 수 있고 PUF(302)는 외부 주변 장치일 수 있음). 대안적으로, PUF 모듈(603)은 신뢰할 수 있는 제3자의 소유일 수 있다. 이는 예컨대, 주변 장치로서 또는 로컬 네트워크 또는 조합으로 제3자 컴퓨터 장비(602)에 통합되거나 이에 연결될 수 있다(예컨대, 인터페이스 로직(404/404')은 제3자 장비(602) 상에서 구현될 수 있고 PUF(302)는 외부 주변 장치일 수 있음).
일반적으로. 타겟 당사자(103T), 검증 당사자(103V) 또는 제3자 중 임의의 당사자는 도 3, 도 4 및 5와 관련하여 이전에 논의된 제출 당사자의 역할을 맡을 수 있다. 타겟 당사자(103T), 검증 당사자(103V) 또는 제3자 중 임의의 것은 제출 당사자의 역할을 맡을 수 있거나, 또는 PUF 모듈(603)을 사용하여, 하나 이상의 CR 쌍들의 세트를 설정하고 이를 나중의 검증 페이즈에서 사용하기 위해 타겟 당사자(103T)의 아이덴티티에 링크하는 설정 당사자의 역할을 맡을 수 있다. 일부 특정 예시적인 시나리오들은 나중에 보다 자세히 논의된다.
응답 데이터 저장소(601)는 설정 페이즈에서 PUF 모듈(603)에 의해 생성된 응답 데이터를 저장한다. 데이터 저장소(601)는 타겟 당사자(103T) 또는 타겟 당사자(103T)의 디바이스일 수 있는 타겟의 아이덴티티의 증거와 관련하여 이 응답 데이터를 저장한다. 검증 당사자(103V)는 응답 데이터 저장소(601)에 대한 액세스를 갖고 이를 사용하여 나중에 검증 페이즈 동안 타겟의 아이덴티티를 검증할 수 있다. 이를 행하기 위해, 검증 당사자(103V)는 설정 페이즈에서 사용된 챌린지들의 세트에 이전에 포함되었던 챌린지 Ci에 대한 응답 Ri를 생성하도록 타겟에 챌린지한다. 타겟이 응답 데이터 저장소(601)에 저장된 것에 따라 예상된 응답을 생성할 수 있는 경우, 이는 타겟이 PUF 모듈(603)을 소유하거나 제어하고 있다는 증거가 되고, 따라서 설정 페이즈에서 아이덴티티가 캡처된 동일한 당사자인 것으로 가정될 수 있다.
대안적인 변형에서, 응답 데이터 저장소(601)는 예컨대, 시드로서 응답을 사용하여 설정 페이즈에서 생성된 응답(들)에 기초하여 생성된 하나 이상의 개개의 공개-개인 키 쌍들의 하나 이상의 공개 키들을 저장할 수 있다. 타겟이 나중에 개인 키들 중 하나를 사용하여 메시지(예컨대, 문서 또는 블록체인 트랜잭션)에 서명하는 경우, 검증 당사자는 응답 데이터 저장소(601)로부터의 대응하는 공개 키를 사용하여 서명을 검증할 수 있다. 이러한 변형들에서 "응답 데이터"라는 용어는 반드시 응답 Ri의 명시적 값이나 증명이 아니라, 응답 Ri으로부터 도출된 데이터를 커버하기 위해 더 넓은 의미로 사용된다는 것에 주의한다.
응답 데이터 저장소(601)는 공개적으로 액세스 가능하거나, 액세스가 적어도 하나의 검증 당사자(103V)를 포함하는 하나 이상의 당사자들의 제한된 세트로만 제한될 수 있다. 이는 제3자 시스템(602) 상에 또는 피어-투-피어 방식으로 호스팅될 수 있거나, 대안적으로 이는 타겟 당사자(103T)의 컴퓨터 장비(102T) 또는 검증 당사자(103V)의 컴퓨터 장비(102V)에서 구현될 수 있다.
도 7을 참조하면, 방법은 설정 페이즈(702) 및 검증 페이즈(704)의 두 페이즈들을 포함한다. 설정 페이즈에서, 단계(710)에서, 설정 당사자로서 작용하는 타겟 당사자(103T) 또는 제3자 중 하나는 하나 이상의 챌린지들 Ci(i=1…n, 여기서 n>=1)의 세트를 PUF 모듈(603)에 제출한다. 이들은 ePUF(500)가 사용하는 경우에 2차 챌린지들이다. 타겟 당사자(103T)가 PUF 모듈(603)을 소유하고 설정을 수행하는 경우에, 챌린지 Ci는 타겟 당사자(103T)에 의해 생성되거나 제3자 시스템(602) 또는 검증 당사자(103V)로부터 수신될 수 있다. 제3자가 PUF 모듈(603)을 소유하고 설정을 수행하는 경우에, 챌린지들은 제3자 시스템(602)에 의해 생성되거나 타겟 당사자(103T) 또는 검증 당사자(103V)로부터 수신될 수 있다. 어느 쪽이든, 이에 응답하여, PUF 모듈(603)은 PUF(302/500)에 기초하여 응답들 Ri의 대응하는 세트를 생성한다. 이들은 ePUF(500)의 경우에 2차 응답들이다. 따라서 이 방법은 CR 쌍들 {Ci, Ri}의 세트를 생성한다.
실시예들에서, PUF 모듈(903)에 대한 액세스는 타겟 당사자(103T)(및 상이한 당사자인 경우, 설정 당사자)만이 응답들 Ri에 대한 액세스를 획득할 수 있도록 제한된다. 이는 패스워드, PIN, 바이오메트릭 데이터 등과 같은 인식된 크리덴셜들을 제시할 수 있는 당사자에게만 액세스를 승인할 수 있는 액세스 제어 로직(404 또는 404')에 의해 달성될 수 있다. 그리고/또는, PUF 모듈(603)에 대한 물리적 인터페이스에 대한 액세스는 이를테면, 잠긴 컨테이너, 캐비넷 또는 방에 PUF 모듈(603)을 유지함으로써 물리적으로 보호될 수 있거나; 또는 이는 이를테면, PUF 모듈(603)을 특정 직원만이 액세스를 허용받을 수 있는 방이나 단지에 저장함으로써 법적으로 보호될 수 있다. 다른 대안 또는 부가적인 제한으로서, ePUF(501)의 경우, 타겟 당사자(103T)(및 실시예들에서, 별개의 설정 당사자로서 작용하는 신뢰할 수 있는 제3자)만이 Cw를 알도록 1차 챌린지 Cw에 대한 지식이 제한될 수 있다.
단계(720)에서, 방법은 응답 데이터 저장소(601)에 응답 데이터를 저장하는 것을 포함한다. 실시예들에서, 저장된 응답 데이터는 생성된 CR 쌍들 {Ci, Ri}의 레코드를 포함한다. 각각의 CR 쌍의 레코드는 쌍의 대응하는 챌린지 Ci를 표시하는 방식으로 저장된 개개의 응답 Ri의 레코드를 포함한다. 실시예들에서, 각각의 응답 Ri의 저장된 레코드는 응답의 명시적 값, 즉 레코드들을 판독할 수 있는 검증 당사자(103V)에게 명시적으로 공개된 Ri의 실제 값을 포함한다. 값은 평문으로 저장될 수 있거나 검증 당사자가 값을 복호화할 수 있는 복호화 키를 갖는 경우 암호화될 수 있지만 그럼에도 불구하고, 저장된 값은 검증 당사자(103V)에게 명시적으로 공개된다는 의미에서 본 명세서에서의 목적을 위해 여전히 명시적 값인 것으로 언급된다. 대안적으로, 응답의 레코드는 Ri의 결정론적 변형을 포함하는 응답 Ri의 "증명"을 포함할 수 있다. 예는 해시 H(Ri) 또는 이중 해시 H2(Ri)의 값을 저장하는 것일 것이다. 이는 R'i에 적용된 동일한 변형(예컨대, H(R'i) 또는 H2(R'i))이 증명과 매칭되는지를 체크함으로써 응답 R'i의 값이 저장소에 레코딩된 것과 동일한지를 검증 당사자가 체크하는 것을 가능하게 한다. 이는 응답 Ri의 실제 값이 공개되지 않는다는 이점이 있다. 따라서 방법의 이 변형은 저장소(601)가 블록체인과 같은 공개 매체인 경우에 특히 유용할 수 있다. 그러나 암호화는 다른 가능성이 있을 것이다.
응답 데이터가 암호화된 형태로 저장되는 경우, 응답 데이터의 각각의 조각(예컨대, 각각의 CR 쌍)은 개별적으로 암호화될 수 있어, 각각이 복호화를 위해 상이한 개개의 복호화 키를 요구한다. 대안적으로, 응답 데이터의 서브세트들 또는 전체 세트들(예컨대, 주어진 타겟 당사자(103T)에 대한 모든 CR 쌍들)은 함께 암호화될 수 있어, 모두가 동일한 키를 가진 그룹으로서 함께 복호화 가능하다.
응답 데이터, 예컨대, CR 쌍들은 타겟의 아이덴티티의 증거와 관련하여 응답 데이터 저장소(601)에 저장된다. 예컨대, 타겟 당사자(103T)는 설정의 일부로서 여권과 같은 하나 이상의 조각들의 식별 정보들을 생성하도록 요구될 수 있다. 응답 데이터와 관련하여 응답 데이터 저장소(601)에 홀딩된 증거는 응답 데이터와 관련하여 명시적으로 저장되는 이 정보 그 자체의 사본을 (평문으로 또는 검증 당사자(103)에 대해 액세스 가능한 암호화된 형식으로) 포함할 수 있다. 대안적으로 응답 데이터 저장소(601)가 신뢰할 수 있는 제3자 또는 검증 당사자(103V) 자체에 의해 관리되는 경우, 응답 데이터가 특정 아이덴티티와 관련하여 응답 데이터 저장소(601)에 등록된다는 단순한 사실만으로도 충분한 증거로 간주될 수 있다(검증 당사자(103V)가 설정 시에 타겟 당사자의 식별 정보를 적절하게 체크한 설정 당사자 및 응답 데이터 저장소(601)를 관리하는 당사자 예컨대, 신뢰할 수 있는 제3자를 신뢰한다고 가정함).
검증 페이즈(704)에서, 단계(730)에서, 검증 당사자(103V)는 검증 동작에서 사용할 응답 데이터를 결정하기 위해 응답 데이터 저장소에 액세스한다. 실시예들에서, 복수의 잠재적 검증 당사자들(103V)이 존재하고, 각각에는 CR 쌍들 중 하나 이상의 상이한 개개의 서브세트를 할당된다. 즉, 응답 데이터 저장소(601)는 주어진 검증 당사자(103V)에게, 해당 당사자에게 할당된 CR 쌍(들)의 예상된 응답(들) Ri만을 공개할 것이다. 예컨대, 이 체계는 신뢰할 수 있는 제3자 시스템(602)에 의해 관리될 수 있다. 이러한 체계는 유리하게는 CR 쌍들을 분리한 채로 유지하여서, 하나의 검증 당사자(103V)는 타겟인 다른 검증 당사자인 척할 수 없게 한다. 그러나 저장소(601)에 대한 액세스가 주어진 모든 검증 당사자들(103V)이 신뢰할 수 있는 경우에, 이것이 필수적인 것은 아니다.
실시예들에서, 검증 당사자(103V)는 자신이 사용할 챌린지를 초기에 알지 못하며, 대응하는 응답 데이터(예컨대, 응답 또는 증명)와 함께 데이터 저장소(601)로부터 챌린지에 액세스함으로써 이를 결정한다. 대안적으로 검증 당사자(103V)는 자신이 사용하고자 하는 챌린지를 미리 알고 있고, 이를 사용하여 데이터 저장소(601)에서 어떤 응답 데이터가 이 챌린지에 매핑되는지를 룩업한다.
검증 당사자(03V)(또는 실제로 임의의 당사자)가 이를테면, 응답 데이터 및/또는 챌린지를 결정하기 위해 블록체인으로부터의 데이터에 액세스하는 시나리오에서, 블록체인에 액세스하는 것은 직접적으로, 블록체인 네트워크의 노드에 질의하거나, 또는 간접적으로, 블록체인 데이터에 대한 액세스를 추구하는 당사자들 대신에 질의들을 중재하거나 블록체인 데이터를 캐시(cache)하는 중간 서비스에 질의함으로써 수행될 수 있다. 예컨대, 검증자(103V)는 블록체인 네트워크(106)에 직접 연결되지 않은 다른 서비스 제공자로부터의 데이터에 액세스할 수 있지만, 응답 관련 데이터만을 제공하고 어쩌면, 머클(Merkle) 증명을 또한 제공할 수 있다.
단계(740)에서, 검증 당사자(103V)는 PUF 모듈(603)을 소유하거나 제어하는 타겟 당사자(103T)에게 챌린지(Ci)를 제출한다. 이는 단계(730)에서, 검증 당사자(103V)가 응답 데이터 저장소(601)로부터 액세스한 레코드들 중 하나에 대응하는 챌린지이다. 신뢰할 수 있는 제3자가 설정 시에 PUF 모듈(603)을 소유하고 있었던 시나리오들에서, PUF 모듈(603)은 설정 페이즈(702)과 검증 페이즈(704) 사이에서 신뢰할 수 있는 제3자로부터 타겟 당사자(103T)로 물리적으로 전달될 수 있다는 것에 주의한다.
제출된 챌린지 Ci에 대한 응답으로, PUF 모듈(603)은 타겟 당사자(103V)가 검증 당사자에게 리턴하는 대응하는 응답 Ri를 생성한다. 단계(750)에서, 검증 당사자는, 수신된 응답 Ri가 단계(730)에서 응답 데이터 저장소(601)로부터 액세스된 응답 데이터에 따라 예상되는 응답과 매칭되는지를 체크한다.
언급된 바와 같이, 설정 단계들(702)을 수행하는 당사자는 타겟 당사자(103T) 또는 응답 데이터(예컨대, CR-쌍들)를 저장하는 신뢰할 수 있는 제3자일 수 있다. 추가 변형들에서, 이러한 단계들은 신뢰할 수 있는 오라클(실시예들에서, 데이터 저장소(610)를 포함하는 제3자 컴퓨터 장비(602)를 실행하는 당사자 이외의 다른 제3자)과 같은 다른 조정 당사자에 의해 수행될 수 있다. 그러한 실시예들에서, 데이터 저장소(601)는 (상이한 제3자의) 제3자 시스템(602) 또는 블록체인과 같은 공개 피어-투-피어 매체일 수 있다. 그리고/또는, 또 다른 변형들에서, PUF 모듈(603)에 대한 입력들을 수행하는 당사자와 출력들을 수신하는 당사자 사이에 분리(separation)가 제공될 수 있다.
또한 언급된 바와 같이, 응답 Ri가 응답 데이터 저장소(601)에 레코딩되는 방식에 대해 적어도 두 가지 가능성들이 있다. 첫 번째는 단순히 Ri 자체의 실제 값을 명시적으로 저장하는 것이다. 이 경우에, 단계(750)는 단순히, 저장된 값(이는 설정(702)에서 설정됨)을 (검증 페이즈(704)에서) 제출된 챌린지 Ci에 대한 응답으로 이제 수신된 값 R'i(응답 Ri의 알려진 값)와 비교하는 것을 포함한다. 이들이 매칭되는 경우, 방법은 타겟 당사자(103T)의 아이덴티티가 검증된 것으로 선언되는 단계(760)로 분기한다. 그렇지 않으면, 방법은 타겟 당사자(103T)의 아이덴티티가 검증되지 않은 것으로 선언되는 단계(770)로 분기한다.
제2 가능성은 Ri의 증명만이 예컨대, 해시 또는 이중 해시가 응답 데이터 저장소(601)에 저장된다는 것이다. 이 경우에, 검증 당사자(103V)는 검증 페이즈(704)에서 자신이 타겟 당사자(103T)로부터 다시 수신한 응답 R'i에 대한 증명을 생성하는 데 사용된 것과 동일한 변환을 적용한다. 이것이 저장된 증명과 매칭하는 경우, 방법은 타겟 당사자(103T)의 아이덴티티가 검증된 것으로 선언되는 단계(760)로 분기한다. 그렇지 않으면, 방법은 타겟 당사자(103T)의 아이덴티티가 검증되지 않은 것으로 선언되는 단계(770)로 분기한다.
응답 데이터 저장소(601)에서, 대응하는 챌린지 Ci가 각각의 레코딩된 응답 Ri와 연관되는 것으로 표시되는 방식에 대해 적어도 두 가지 가능성들이 있다. 첫 번째는 단순히 각각의 CR 쌍 {Ci, Ri}의 명시적 값을 저장하는 것, 즉 Ri 및 Ci의 실제 값들을 (평문 또는 암호화되어) 저장하는 것이다. 대안적으로, 제2의 더 경량의 방식은 미리 결정된 결정론적 챌린지-도출 함수(f)에 따라 챌린지들(Ci)이 도출될 수 있는 마스터 챌린지(Cm)를 저장하는 것이다.
이는 도 8a에서 예시된다. 각각의 응답 Ri는 개개의 인덱스와 관련하여 저장된다. 함수 f는 응답 데이터 저장소(601)에 저장되거나 검증 당사자(103V)에 미리 알려진다. 어느 쪽이든, 검증 당사자(103V)는 응답들 Ri 중 적어도 하나의 응답의 인덱스 i에 대응하는 챌린지 Ci를 결정하기 위해 마스터 챌린지 Cm을 함수 f에 입력한다. 그 후, 검증 당사자(103V)는 타겟을 검증하기 위해 이 챌린지 Ci를 사용한다.
그러한 일부 실시예들에서, 함수 f는 또한 식별 정보(806)의 함수일 수 있으며, 이는 단일 조각의 식별 정보 또는 복수의 조각들의 식별 정보(802)(예컨대, 여권 정보, 어머니의 결혼 전 이름 및 지문 정보)의 조합(804)(예컨대, 컨케터네이션)일 수 있다. 이는 타겟 당사자(103T)의 식별 정보를 포함할 수 있다. 이는 특정 타겟 당사자(103T) 특유의 챌린지들의 세트 Ci를 가능하게 하며, 이는 예컨대, 동일한 제3자 시스템(602)이 상이한 타겟 당사자들에 대한 챌린지 세트들을 생성하는 데 사용되는 경우 고유성이 중요할 수 있으므로, 보안상의 이유들로 유리하다. 타겟 당사자(103T)의 여권 정보 또는 어머니의 결혼 전 이름과 같은 개인 식별 정보를 사용하는 것은, 개인 식별 정보가 그/그녀가 이미 알고 있거나 갖고 있는 것이고 비공개로 유지되는 경향이 있기 때문에 좋은 선택이다.
대안적으로 또는 부가적으로, 식별 정보(806)는 검증 당사자(103V)의 식별 정보를 포함할 수 있어서, f는 특정 검증 당사자(103V)의 아이덴티티의 함수이다. 이는 특정 검증 당사자(103V)에 하나 이상의 특정 챌린지들의 특정 서브세트를 할당하는 데 사용될 수 있어서, 상이한 검증 당사자들(103V)에는 검증(704)에서 사용할 상이한 챌린지들 Ci이 주어진다.
일부 실시예들에서, 마스터 챌린지 Cm이 어떻게 형성되는지에 관계없이, 챌린지들 Ci는 도 8b에 도시된 바와 같이 C1 = f(Cm), C2 = f(C1), 이러한 식이 되도록 체인 방식으로 마스터 챌린지 Cm에 매핑될 수 있다. 즉, 제1 챌린지 C1는 마스터 챌린지 Cm에 함수 f를 적용함으로써 결정되고, 그 후 제2 챌린지 C2는 동일한 함수 f를 제1 챌린지에 적용함으로써 결정되고 이러한 식이다. 예로서, f는 해시 함수를 포함할 수 있다.
다른 변형에서, 챌린지 Ci는 도 8c에 도시된 바와 같이 계층적 방식으로 마스터 챌린지 Cm에 매핑될 수 있다. 이는 나중에 더 자세히 논의될 것이다.
체인 접근법은 더 경량이고 f()가 루트 키 이외의 임의의 데이터를 요구하지 않는 경우 루트 정보로부터 복구하기가 또한 더 쉽다. 계층적 도출의 경우에, 트리의 인덱스들이 추가될 것이며, 이는 다음과 같은 간단한 체인에 대해 필요로 되지 않을 것이다: C_m, H(C_m), H(H(C_m))… , 예컨대, 여기서 f( )는 해시 함수일 뿐이다.
f()의 형태 또는 마스터 챌린지가 식별 정보 및/또는 다른 정보를 포함하는지에 관계없이, 실시예들에서, 마스터 챌린지 Cm는 설정(702) 동안 타겟 당사자(103T)로부터 제3자 시스템(602)에 의해 수신될 수 있다. 그 후, 제3자는 검증(704)에서 향후 사용을 위해 데이터 저장소(601)에 수신된 마스터 챌린지를 (예컨대, 로컬로 또는 체인 상에) 저장한다. 대안적으로, 제3자 시스템(602)은 타겟 당사자(103T)로부터 챌린지들의 세트 Ci를 수신하고, 예컨대, 함수 f()의 역을 적용함으로써 그로부터 마스터 챌린지 Cm을 도출한다. 이러한 접근법들의 변형들에서, 제3자 시스템(602)은 타겟 당사자(103T) 이외의 다른 곳으로부터, 예컨대, 오라클 또는 조정 당사자(미도시)로부터 식별 정보, 마스터 챌린지 또는 챌린지들의 세트를 수신할 수 있다. 이러한 접근법들의 조합이 또한 사용될 수 있다(예컨대, 하나의 조각의 식별 정보는 타겟 당사자로부터 수신되고 하나는 다른 곳으로부터 획득됨). 또는, 추가 대안들에서, 제3자는 관여되지 않고 타겟 당사자(103T)는 마스터 챌린지를 체인 상에(또는 일부 다른 피어-투-피어 공개 매체에) 스스로 저장한다.
도 7의 방법의 추가 변형들에서, 응답 데이터 저장소(601)에 저장된 응답 데이터는 설정 시에 생성된 CR 쌍(들)의 레코드를 포함하지 않을 수 있다. 대신에, 응답 데이터는 공개-개인 키 쌍의 공개 키 또는 이러한 공개 키들의 세트를 포함할 수 있으며, 여기서 하나 이상의 키 쌍들 각각은 설정 페이즈(702)으로부터의 개개의 PUF 응답 Ri에 기초하여 생성되었다. 예컨대, 응답 Ri는 공개-개인 키-쌍 생성 알고리즘에서 시드로 사용될 수 있다. 이러한 실시예들에서, 방법은, 단계(730)에서 검증 당사자가 저장된 공개 키들 중 하나에 액세스하고 단계(740)에서 검증 당사자(103V)가 타겟의 PUF 모듈(603)에 입력될 챌린지 Ci를 제출하지 않는 것을 제외하고는, 도 7에 제시된 바와 같이 진행한다. 대신, 검증 당사자(103V)는 타겟에 의해 (알려지게) 서명된 메시지(예컨대, 문서, 파일 또는 블록체인 트랜잭션의 일부)를 획득한다. 이 메시지는 타겟 당사자(103T)에 의해 그/그녀에게 전송될 수 있거나 검증 당사자(103V)가 블록체인 또는 웹사이트와 같은 공개 매체로부터 자율적으로 메시지에 액세스할 수 있다. 어느 쪽이든, 단계(750)에서, 체크는 (당업계에 그 자체로 잘 알려진 공개-개인 키 서명 검증 기술들에 기초하여) 메시지에 적용된 서명을 검증하기 위해 저장소(601)로부터 액세스된 공개 키를 사용하는 것을 포함한다.
다음은 이제 본 명세서에 개시된 실시예들에 따라 ePUF들 또는 PUF들에 대한 일부 예시적인 아이덴티티-설정 및 검증 프로토콜들을 보다 일반적으로 설명한다. 증명자 앨리스(타겟 당사자 103T) 및 검증자 밥(검증 당사자 103V)을 고려한다. PUF 아이덴티티 시스템에 적어도 3개의 상이한 챌린지 유형들이 존재한다. 예로서, 아래는 ePUF의 관점에서 설명될 것이지만, 보다 일반적으로 임의의 PUF 디바이스가 사용될 수 있다(PUF 모듈(603)을 포함하는 임의의 디바이스).
1. 원격 PUF 챌린지 ― 검증자는 밥에 의해 제출된 챌린지에 대한 앨리스로부터의 응답을 요청함으로써 원격으로 증명자에 챌린지한다. 이 모드는 검증자가 증명자의 PUF로부터 예상되는 응답(들)을 알고 있고, 또한 PUF가 합법적인 소유자에 의해 소유된다고 가정한다.
2. 로컬 PUF 챌린지 ― 검증자는 앨리스에 의해 제어되는 PUF 디바이스와 상호작용함으로써 로컬로 증명자에 챌린지한다. 이 모드는, 검증자가 증명자의 아이덴티티에 관한 어떤 것을 알고 있지만 그의 PUF의 거동에 대해서는 아무것도 모른다고 가정한다.
3. 암호화 챌린지 ― 검증자는 이를테면, 증명된 공개 키에 증명 가능하게 링크된 키로 메시지에 서명함으로써, 자신의 아이덴티티와 관련된 일부 암호화 요건들을 충족시키도록 증명자에 챌린지한다.
유형들 1 및 2의 경우, 챌린지는 증명자와 검증자 둘 모두의 관점들로부터 명시적으로 PUF 모듈(603)에 의존한다. 이러한 경우에 챌린지 및 이에 따른 대응하는 검증 프로세스는 본질적으로 PUF 디바이스(PUF 모듈(603)을 포함하는 디바이스, 예컨대, 앨리스의 컴퓨터 장비(102T))의 동작에 링크된다. 이 경우들에, PUF 디바이스들의 물리적 상태가 아이덴티티에 고유하게 바인딩될 수 있는 PUF 디바이스들의 특성이 사용되고, 이에 따라 PUF는 활용중인 아이덴티티 시스템에서 중심 역할을 한다.
'원격' 및 '로컬'이라는 용어들은 구체적으로 챌린지를 할 때 검증자와 증명자의 PUF 간의 상호작용을 지칭한다는 것에 주의한다. 이는 원격 챌린지 프로토콜이 미리 증명자와 검증자 간의 로컬 상호작용을 수반하는 설정 페이즈를 갖는 것을 배제하지 않는다.
그러나 경우 3에서, 챌린지 및 검증 프로세스는 증명자의 관점으로부터 PUF 디바이스와 관련되기만 하면 된다. 검증은 자신의 챌린지에 대한 응답을 생성하는 데 증명자에 의해 PUF가 사용되었는지 여부를 검증자가 아는 것에 의존하지 않는다. 이 경우에, 방법은 아이덴티티를 디바이스 자체에 링크하는데 있어 그의 유용성 보단, 단순히 앨리스에 대한 키-생성기로서 PUF의 유용성을 사용하는 것이다.
다음에서, 위에서 언급된 3개의 동작 모드들 각각에서 아이덴티티 시스템들에 대한 설정 및 검증, 및 선택적 업데이트 및 폐지 프로세스들에 대한 예시적인 구현들이 제공된다. 실시예들에서, 일반적으로 신뢰할 수 있는 제3자는 PUF 기반 아이덴티티 시스템과 관련된 프로세스들에 수반된다. 이는 그러한 아이덴티티 시스템들이 아이덴티티 및 관련 크리덴셜들에서 무결성 및 신뢰를 유의미하게 보장하기 위해 그러한 제3자를 요구하는 경향이 있기 때문이다. 이러한 시스템에서 개인의 아이덴티티가 설정되고 사용되는 경우, 해당 신뢰할 수 있는 제3자는 인증 기관, 정부 기관 또는 은행과 같은 금융 서비스 제공자일 수 있다.
아이덴티티가 기계 또는 비-인간 엔티티에 대해 설정되어야 하는 경우, 제3자는 디바이스 제조업체, 발행자, 규제 기관 또는 일부 다른 관련 액터일 수 있다. 이 경우는 특히 사물 인터넷(IoT) 또는 추가로, 사물 블록체인(BoT) 패러다임에 적합하며, 여기서 아이덴티티는 일부 목표를 달성하기 위해 공동으로 작업들 또는 계산들을 수행할 수 있는 디바이스들의 네트워크의 상이한 멤버들에 할당될 것이다.
3.1. 원격 PUF 시스템
3.1.1. 설정: 원격 PUF 챌린지들의 경우, 증명자에게 챌린지 C를 제출하는 검증자는 예상되는 응답 R을 미리 알고 있다고 가정한다. 이것은, 이 경우 설정 프로세스가 앨리스와 다른 당사자 간에 CRP들의 세트(즉, 적어도 하나)를 설정해야 하며, CRP들의 세트는 나중에 앨리스의 아이덴티티를 인증하는 데 사용될 수 있는, 이들 간의 공유 비밀을 도출하는 데 사용될 수 있다는 것을 의미한다.
이전에 언급된 바와 같이, 앨리스가 아이덴티티를 설정하도록 장비된 일반 제3자와 이 공유 비밀을 설정하고, 이 제3자가 나중에 앨리스와의 검증 프로세스에 참여하는 검증 당사자일 수도 있고 아닐 수도 있다고 가정한다. 검증 당사자가 아이덴티티-설정 제3자와 별개인 경우, 검증 당사자는 제3자로부터 공유 비밀(들)에 사용되는 관련 CRP 정보를 획득할 수 있다고 가정한다.
여기에서 설정 페이즈에 대해, 앨리스가 항상 PUF 디바이스에 대한 액세스를 갖는 유일한 당사자인지 또는 신뢰할 수 있는 제3자가 또한 설정 페이즈 동안에만 PUF 디바이스에 대한 액세스를 가질 수 있는지에 따라 카테고리화되는 2개의 별개의 옵션들이 존재한다.
경우 1: 앨리스는 PUF에 대한 단독 액세스를 가짐
1. ePUF 디바이스가 제조되어 앨리스에게 배포된다.
2. 앨리스는 신뢰할 수 있는 제3자에 접촉함으로써 자신의 아이덴티티를 자신의 ePUF 디바이스에 링크하도록 신청한다.
i. 제3자는 앨리스에 대한 식별 계정을 설정하고 그녀의 아이덴티티의 증명을 요청한다.
ii. 앨리스는 제3자에게 관련 식별 문서들 또는 크리덴셜들을 제공한다.
iii. 제3자는 앨리스의 아이덴티티를 검증한다.
3. 앨리스 및 제3자는 나머지 설정 프로세스를 위해 (예컨대, 표준 Diffie-Hellman 키 교환을 통해) 보안 통신 채널을 설정한다.
i. 앨리스 및 제3자는 공개 키들 PA, PT를 각각 교환한다.
ii. 앨리스 및 제3자는 와 같이 나머지 설정 통신들에 대해 임시 비밀을 독립적으로 설정한다.
iii. 앨리스 및 제3자는 S에 의해 보호되는 채널 예컨대, AES 암호화 채널을 통해 통신하기 시작한다.
4. 제3자는 앨리스에게 보안 채널을 통해 챌린지들의 세트 를 전송한다.
5. 앨리스는 ePUF 디바이스로부터 응답들 을 획득한다.
6. 앨리스는 보안 채널을 통해 제3자에게 응답들 을 전송한다.
7. 제3자는 앨리스의 아이덴티티 계정에 대해 응답 CRP 세트 를 저장한다.
경우 2: 제3자가 설정 동안 PUF에 액세스함
1. 제3자는 기본 쌍 및 해시 함수에 대한 지식을 갖는다. 예컨대, ePUF 디바이스가 제조되고 신뢰할 수 있는 제3자*에게 배포된다.
2. 제3자는 디바이스로부터 기본 CRP(Cw,Rw)를 획득한다.
3. 앨리스는 제3자에 접촉함으로써 아이덴티티-링크 ePUF 디바이스를 신청한다. 이는 보안되지 않은 통신 채널을 통해 행해질 수 있다.
i. 제3자는 앨리스에 대한 식별 계정을 설정하고 그녀의 아이덴티티의 증명을 요청한다.
ii. 앨리스는 제3자에게 관련 식별 문서들 또는 크리덴셜들을 제공한다.
iii. 제3자는 앨리스의 아이덴티티를 검증하고 ePUF 디바이스 및 그의 기본 쌍(Cw,Rw)을 앨리스의 계정에 할당한다. 공유 비밀은 이 CRP이거나 이 CRP의 도출물이다.
4. 제3자는 ePUF 디바이스를 앨리스에게 전송한다.
(*디바이스는 앨리스에게 먼저 배포되고 그 후 앨리스에 전송될 수 있다. 그러나 대부분의 경우, 디바이스가 제3자에게 직접 배포하는 것이 더 합리적일 것이다. 예컨대, 디바이스가 스마트 직불 카드인 경우, PUF 설정 후에, 카드는 제조업체로부터 발행 은행으로 그리고 그 후 발행 은행으로부터 고객인 앨리스에게 전달될 수 있다.)
설정 프로토콜은 검증 프로세스 동안 나중에 앨리스의 아이덴티티(또는 PUF-포함 디바이스)를 인증하는 데 사용되도록 앨리스와 신뢰할 수 있는 제3자 간의 공유 비밀(들)을 설정한다. 또한, 경우들은 이들 둘 모두가 앨리스와 신뢰할 수 있는 제3자 간의 보안 통신을 수반하는 것이 바람직하다는 점에서 유사하다.
다만, 두 경우들 간의 차이는 경우 1은 보안 통신 채널을 설정함으로써 보안 통신을 달성하는 반면, 경우 2는 물리적 보안을 통해 이를 달성한다는 점이다.
경우 1 및 2의 두 프로토콜들 사이에 주목해야 할 다른 차이는 경우 2에서, 신뢰할 수 있는 제3자가 PUF 없이 앨리스만큼 많은 CRP들을 도출할 수 있는 반면, 경우 1에서, 이 당사자는 고정된 수의 쌍들을 저장해야 한다는 것이다.
이는 PUF 디바이스로 사용자를 설정하기 위한 기존 프로토콜에 비해 경우 2의 이점인데, 그 이유는 경우 2는 신뢰할 수 있는 제3자가 임의적 수의 CRP들을 원격으로 생성할 수 있는 반면, 기존 프로토콜에서, 신뢰할 수 있는 제3자가 이를 행하기 위해서는 최종 사용자 또는 장치 제조업체와 협력할 필요가 있을 수 있기 때문이다. 엘리스가 보안 채널을 통해 밥에게 기본 쌍(Cw,Rw)을 전송하는 단계가 추가되는 경우(제3자가 악의적인 방식으로 기본 쌍을 사용하지 않는다고 신뢰함), 동일한 기술적 이점이 경우 1에서 달성될 수 있다.
설정 페이즈에서 보안 통신의 사용은 검증 프로세스와 같은 향후 통신들이 보안되지 않은 채널들을 통해 송신되도록 허용한다는 것에 주의한다. 이는 검증들이, 검증 시에 양 당사자들이 온라인 상태일 필요가 있는 것과 같은 기술적 제한들이 더 적게 발생하는 것을 허용한다는 이점을 갖고, 이 일회 설정 프로세스에서 부가적인 보안 통신 오버헤드만을 요구한다.
3.1.2. 검증: 원격 PUF 검증 모드에서, 설정 페이즈에 2개의 별개의 경우들이 있었다는 점을 기억하자 ― 이는 아래에 상세된 바와 같이 약간 상이한 원격 검증 프로토콜들에 반영된다.
경우 1: 앨리스는 PUF에 대한 단독 액세스를 가짐
1. 밥은 설정 동안 앨리스 및 제3자에 의해 설정된 세트 로부터 (C1,R1)과 같은 미사용 CRP를 획득한다.
i. 밥이 또한 신뢰할 수 있는 제3자인 경우, 밥은 세트로부터 요소를 단순히 리트리브(retrieve)한다.
ii. 밥이 신뢰할 수 있는 제3자가 아닌 경우, 밥은 앨리스에 대해 미사용 CRP를 요청함으로써 제3자와 통신한다.
2. 밥들은 챌린지 C1를 앨리스에게 전송한다.
3. 앨리스는 ePUF 디바이스로부터 후보 응답 을 획득하고 이를 밥에게 전송한다.
4. 밥은 인지를 검증한다.
i. 만약 그렇다면, 검증이 통과된다.
ii. 만약 아니라면, 검증은 실패한다.
5. 쌍 (C1,R1)은 후속적으로 신뢰할 수 있는 제3자에 의해 제거되어, 나머지 챌린지-응답 쌍들의 세트 를 남긴다.
단계 1.ii에서, CRP들의 단일 사용 성질은 임의적 밥이 특정 CRP를 사용하여 앨리스를 '가장'하는 것이 가능하지 않다는 것을 보장하는데, 그 이유는 신뢰할 수 있는 제3자는 각각의 주어진 상황에서 각각의 쌍의 사용을 간단히 모니터링할 수 있고 모든 각각의 인증 시도에 대해 새로운 CRP를 사용해야 하기 때문이라는 것에 주의한다.
경우 2: 제3자가 설정 동안 PUF에 액세스함
1. 밥은 검증을 위해 새로운 챌린지 C를 생성한다. 이는 랜덤으로, 또는 일부 다른 데이터(예컨대, 알려진 KYC 데이터, 바이오메트릭들, 이미지들)로부터 결정론적으로 수행될 수 있다.
2. 밥들은 챌린지 C를 앨리스에게 전송한다.
3. 앨리스는 ePUF 디바이스로부터 후보 응답 R'을 획득하고 이를 밥에게 전송한다.
4. 밥은 예상된 응답 R을 획득한다.
i. 밥이 신뢰할 수 있는 제3자인 경우, 밥은 *를 컴퓨팅함으로써 직접 응답을 계산할 수 있다.
ii. 밥이 신뢰할 수 있는 제3자가 아닌 경우, 밥은 C를 제3자에게 전송하고 응답 R을 요청한다.
5. 밥은 R'==R인지를 검증한다.
i. 만약 그렇다면, 검증이 통과된다.
ii. 만약 아니라면, 검증은 실패한다.
(*이는 제3자가 설정 프로토콜(경우 2) 동안 기본 쌍(Cw,Rw)을 획득 ― 이는 Rw가 그들에게 알려져 있음을 암시함 ― 했기 때문이다. 또한, 해시 함수 H는 모든 사람이 아니더라도 적어도 제3자에게 알려져 있다고 즉, SHA-256과 같은 공개 표준이라고 가정함.)
3.1.3. 업데이트: 검증(및 로그인과 같은 다른 유용한 프로토콜)에서 새로운 CRP들의 단일 사용 성질을 고려하여 앨리스 및 제3자가 새로운 CRP들을 설정하기 위한 프로세스를 지정하는 것이 또한 바람직할 수 있다.
경우 1: 앨리스는 PUF에 대한 단독 액세스를 가짐. 이 경우, 설정에서와 같이, 앨리스와 제3자 간에 챌린지들 및 응답들을 송신하기 위해 다른 보안 채널이 설정된다. 우리는 앨리스가 형태 S=H(Ri) 또는 이와 유사한 형태의 공유 비밀을 설정하기 위해 형태 (Ci,Ri)의 적어도 하나의 남은 CRP를 갖거나 DH 키 교환으로부터 이전 공유 비밀 에 대한 액세스를 갖는다고 가정한다.
1. 앨리스 및 제3자는 공유 비밀 S를 사용하여 보안 통신 채널을 설정한다. 이것은 다수의 방식들로 도출될 수 있으며, 프로토콜은 이에 대해 불가지론적이다.
2. 제3자는 앨리스에게 보안 채널을 통해 챌린지들의 세트 를 전송한다.
3. 앨리스는 ePUF 디바이스로부터 응답들 을 획득한다.
4. 앨리스는 보안 채널을 통해 제3자에게 응답들 을 전송한다.
5. 제3자는 앨리스의 아이덴티티 계정에 대해 응답 CRP 세트 를 저장한다.
적어도 단계들 2-5는 설정 단계들 4-7과 동일하다는 것에 주의한다.
채널을 통해 제3자(Cw, Rw)에게 알리는 앨리스에 대한 이전 코멘트를 또한 참조한다.
경우 2: 제3자가 설정 동안 PUF에 액세스함. 이 경우, 제3자는 간접적으로 임의적 수의 CRP들을 생성할 수 있는데, 그 이유는 이들이 기본 쌍(Cw,Rw) 및 해시 함수 H( ) 둘 모두에 대한 지식을 갖기 때문이다. 이는 이 경우 상호작용식 업데이트에 대한 어떠한 요건도 없음을 의미한다.
3.1.4. 폐지: 아이덴티티 시스템의 추가 부분은 특정 ePUF 디바이스가 폐지되어서 더 이상 아이덴티티 목적들로 사용되지 않는 것일 수 있다. 폐지 프로세스는 간단하고 (i) 사용자인 앨리스와 독립적으로 제3자에 의한 폐지, 또는 (ii) 폐지 요청으로서 전달된 앨리스에 의한 폐지로서 수행될 수 있다.
제1 경우는 ePUF들 또는 다른 것을 수반하는 어떠한 기술적 수단도 요구하지 않는다. 제2 경우는, ePUF 특유의 프로토콜 또는 솔루션을 요구하지 않는데, 그 이유는, 제1 경우에서 폐지에 대한 양호한 예는 앨리스가 ePUF를 포함하는 물리적 디바이스를 분실한 경우 또는 ePUF가 어떤 식으로든 손상된 경우이기 때문이다.
그러나 폐지 프로세스에서 ePUF를 선택적으로 활용하려는 경우 ― 여기서 앨리스는 여전히 디바이스의 물리적 제어를 가짐 ― , 앨리스의 요청은 이를테면, 각각의 경우 키로서 CRP 응답 또는 비밀을 사용하는 HMAC 또는 암호화된 메시지에 의해 그녀 및 제3자가 설정한 CRP들 중 하나(또는 그의 도출된 공유 비밀)를 사용하여 인증되도록 규정될 수 있다. 그러나 위에서 언급된 이유로, 이것은 어떻게든지 시스템의 엄격한 요건으로 간주되지 않는다.
3.2. 로컬 PUF 시스템
3.2.1. 설정: 로컬 PUF에 대해 사용될 수 있는 설정은 원격 PUF에 대한 설정과 정확히 동일하지만, 로컬 및 원격 경우들 간의 차이는 아래의 검증 단계가 수행되는 방법이다.
3.2.2. 검증: 이 시나리오에서, 검증이 로컬로 수행된다. 이는 검증 프로세스가 증명자(앨리스) 및 검증자(밥) 둘 모두가 동일한 물리적 위치에 있을 것을 요구한다는 것을 의미한다.
이 시나리오는 예컨대, 앨리스가 자신의 ePUF 디바이스를 사용하여 로컬로 조사와 상호작용하도록 법적으로 요구되는 (인간 아이덴티티에 대한) 법원 절차, 또는 시스템의 관리자가 로컬로 특정 디바이스의 응답을 명시적으로 체크하고자 할 수 있는 IoT 시스템의 분석이 수행되는 (디바이스 아이덴티티에 대한) 법원 절차와 관련이 잇을 수 있다. 이것은 또한 지불 시나리오들과 관련이 있을 수 있다.
이러한 프로세스가 적용 가능한 다른 시나리오들은 사고 후 차량에 대한 진단들을 포함할 수 있으며, 여기서 관계자들은 정확히 어떤 디지털 구성요소가 명령을 발행했는지 결정하고자 한다. 이 경우에, 입력 C는 일부 환경 또는 동적 조건들일 수 있으며, 응답 R은 디바이스에 의해 주어진 명령의 일부일 것이다.
아래에 약술된 로컬 PUF 검증 프로토콜과 이전 원격 PUF 검증 프로토콜의 차이는 검증자가 ePUF의 응답을 미리 알고 있음을 이 로컬 프로토콜이 가정하지 않는다는 것이다. 즉, 로컬 검증 프로세스 동안 생성된 응답은 검증자가 미리 사용 가능하지 않다.
그러나 이 시나리오에서, 검증 프로세스에 사용된 챌린지가 어떤 방식으로든 유의미할 가능성이 높다. 예컨대, 아이덴티티가 그의 임베딩된 ePUF 구성요소의 기본 쌍(Cw,Rw)으로 간주될 수 있는 기계를 고려한다. 검증 프로세스는, 주어진 입력 C로부터 출력 R을 이전에 산출한 것이 이 특정 디바이스였다는 것을 검증하기 위해 수행될 수 있다.
1. 밥은 해당 CRP(C,R)에 기초하여 ePUF 디바이스에 제출할 적절한 챌린지 C를 획득한다.
2. 밥은 ePUF 디바이스에 대한 액세스를 획득한다.
3. 밥은 ePUF 디바이스를 사용하여 후보 응답 을 생성한다.
4. 밥은 인지를 검증한다.
i. 만약 그렇다면, 검증이 통과된다.
ii. 만약 아니라면, 검증은 실패한다.
이러한 시나리오들에서, 밥은 후보 응답 R'을 미리 아는 것이 아니라 오히려, PUF 디바이스로부터 그가 지금 수신한 응답이 이전에 생성된 응답과 매칭된다고 검증하고 있다. 예컨대, 이것은 사람(앨리스) 또는 응답을 생성한 디바이스가 (예컨대, 법원에) 지금 존재하는 동일한 사람 또는 디바이스임을 검증하는 데 사용될 수 있다. 예컨대, 디지털 구성요소의 예에서, 이것은 일부 입력 챌린지 C에 기초한 R의 생성 시 명령을 발행하도록 구성되었을 것이다. 예컨대, 디바이스가 자율 주행 자동차이고 구성요소가 "앞차가 너무 가깝습니다"라는 데이터로부터 도출되거나 이를 포함하는 챌린지를 수신하는 경우, 응답 R이 생성되고, R은 구성요소를 트리거하여 브레이크들을 밟으라는 명령들을 발행한다. 따라서 후향적 진단 검증(etrospective diagnostic verification)에서, 검증자는 자동차가 느려졌다고 믿고, 해당 응답을 트리거하기 위해 조건들이 실제로 "앞차가 너무 가까웠다"는 것을 검증하고자 한다.
3.2.3. 업데이트: 업데이트된 CRP들을 생성하기 위한 프로세스는, 해당 시나리오의 핵심적인 차이가 검증에만 적용되므로, 원격 경우에 대해 제시된 것과 동일한 로직을 따를 수 있다.
3.2.4 폐지: 원격 폐지에 대해 설명된 동일 기술들이 또한 여기에서 유효하다.
3.3. 암호화 PUF 시스템
3.3.1 설정: 이 경우에, 앨리스는 표준 암호화 수단을 사용하지만, 프로세스에서 ePUF 디바이스를 사용하여 제3자와 아이덴티티를 설정한다.
이 시나리오에서, 제3자는 선택적으로 ePUF가 프로세스에서 사용되었다는 지식을 가질 수 있다. 마찬가지로, 이러한 방식으로 설정된 아이덴티티의 경우, 아이덴티티의 검증자는 ePUF 디바이스가 아이덴티티 검증 프로세스에 관여됨을 알 수도 있고 모를 수도 있다. 요컨대, 다음 프로토콜은 디바이스의 소유자인 앨리스가, ePUF 디바이스가 아이덴티티 시스템에 관여된다는 지식을 가지고 있다는 것만 규정한다.
1. ePUF 디바이스가 제조되어 앨리스에게 배포된다.
2. 앨리스는 신뢰할 수 있는 제3자에게 접촉함으로써 암호화 아이덴티티를 설정하도록 신청한다.
i. 제3자는 앨리스에 대한 식별 계정을 설정하고 그녀의 아이덴티티의 증명을 요청한다.
ii. 앨리스는 제3자에게 관련 식별 문서들 또는 크리덴셜들을 제공한다.
iii. 제3자는 앨리스의 아이덴티티를 검증한다.
3. 앨리스는 자신의 아이덴티티에 대한 암호화 링크를 설정하기 위한 예컨대, 자신의 CRP를 사용하여 보증된 비대칭 키 쌍을 설정하기 위한 암호화 방법을 선택한다.
i. 제3자는 앨리스로부터 공개 키 PA를 획득하며, 여기서 는 EC 키 쌍이다.
ii. 제3자는 앨리스가 개인 키 sA를 사용하여 메시지 m에 (예컨대, ECDSA를 통해) 서명하도록 요청한다.
iii. 앨리스는 ECDSA 서명 을 생성하여 제3자에게 전송한다.
iv. 제3자가 서명을 검증한다.
4. 서명이 유효한 경우, 제3자는 앨리스의 아이덴티티에 대해 키 PA를 보증한다.
단계 3은 사용자가 선택한 암호화 체계를 사용하는 것을 수반하지만, 프로세스에 수반된 관련 키는 앨리스에게만 알려진 CRP 응답의 도출물일 것이라고 가정한다. 위에서 선택된 예에서, 이는 개인 키 SA가 와 같이 특정 ePUF 응답 R로부터 도출될 것임을 의미한다.
3.3.2 검증: 암호화 경우에서, 이전에 상세된 암호화 설정 페이즈 동안 설정된 암호화 정보를 사용하여 아이덴티티 검증이 수행된다. 이 경우에, 보증된 EC 비대칭 키 쌍이 설정 동안 앨리스의 아이덴티티에 대해 설정되었고 우리는 검증을 위해 해당 키를 이제 사용하는 예를 든다.
그러나 아래의 프로토콜은, 적절한 경우 임의의 다른 체계들에 대한 기존 설정 및 검증 프로토콜들을 간단히 대체함으로써 그러한 암호화 체계에 대해 간단히 적응될 수 있다. 여기서 차이는 홀더 앨리스에 대한 악의적인 손상 위험을 감소시키는 설정 및 검증 프로세스를 위한 보안 키 생성기로서 ePUF 디바이스를 사용하는 것이다.
1. 밥은 아이덴티티-링크 정보 PA 예컨대, 보증된 키를 획득한다.
i. 밥이 신뢰할 수 있는 제3자인 경우, 그는 단순히 앨리스의 계정으로부터 PA를 리트리브한다.
ii. 밥이 신뢰할 수 있는 제3자가 아닌 경우, 그는 제3자와 통신하고 앨리스에 대한 보증된 공개 키를 요청한다.
2. 밥은 앨리스가 서명할 메시지를 선택하고, 앨리스에게 전송한다.
3. 앨리스는 메시지 m에 대해 서명을 생성한다.
i. 앨리스가 자신의 보증된 키로 서명하고자 하는 경우, 그녀는 서명 을 생성한다.
ii. 앨리스가 일회-사용 도출 키로 서명하고자 하는 경우, 그녀는 서명 를 생성하며, 여기서 및 d는 일부 일회-사용 데이터*이다.
4. 앨리스는 서명을 밥에게 전송한다. 이 지점에서, 앨리스는 또한, 밥이 아직 데이터 d를 알지 못하는 경우 이를 전송할 수 있다.
5. 밥은 PA(및 해당되는 경우, d)를 사용하여 공개 키에 대해 서명을 검증한다.
i. 서명 검증이 통과되는 경우, 아이덴티티 검증이 통과된다.
ii. 서명 검증이 실패하는 경우, 아이덴티티 검증이 실패한다.
(* 이 데이터는 인보이스 메시지, 바이오메트릭 퍼지-매칭 데이터와 같이 검증과 관련될 수 있다. 데이터 d는 밥 또는 앨리스에 의해 선택될 수 있다. 대안적으로, d는 예컨대, Diffie-Hellman 키 교환 및/또는 HMAC를 사용하여 도출된, 앨리스 및 밥에게 알려진 공유 비밀일 수 있다.)
위의 암호화 검증 프로세스는 아이덴티티가 EC 또는 PGP 키와 같은 유사한 암호화 프리미티브(cryptographic primitive)로 설정된 경우, 이전 섹션에서 설명된 바와 같이 독립적으로 설정된 아이덴티티에 또한 적용될 수 있다.
3.3.3. 업데이트: 여기에서 앨리스의 아이덴티티를 업데이트하는 프로세스는 키 생성에서 ePUF 디바이스의 사용에 의존하지 않고, 이에 따라 여기에서 임의의 특정 방법을 규정할 필요가 없다. 대신, PA와 같은 보증된 키를 업데이트하는 표준 방법들이 사용될 수 있다.
ePUF가 기존 프로세스(들)에 의해 요구되는 임의의 요구되는 서명 또는 다른 암호화 프로세스를 위한 키 생성에 수반될 것임이 간단히 가정될 수 있다.
3.3.4. 폐지: 유사하게, 여기에서 특정 폐지 프로토콜을 규정할 필요는 없지만, 표준 메커니즘에 따른다. 다시 한 번, ePUF가 적절한 암호화 동작들을 위한 키 생성기로서 백그라운드에서 수반될 것임이 가정될 수 있다.
3.4. 독립적 PUF 메커니즘
3.4.1 설정: ePUF 디바이스를 사용하여 아이덴티티를 설정하기 위한 독립적인 경우에서, 엔티티가 임의의 제3자와 독립적으로 인간 아이덴티티를 설정하거나 폐쇄된 시스템 내에서 디바이스 아이덴티티를 설정하고자 하는 시나리오를 고려한다. 이 프로세스에 수반된 유일한 당사자는 ePUF 디바이스의 '소유자'이자 이후 검증들 동안에서의 최종 증명자인 앨리스이다.
경우 1: 앨리스는 인간 아이덴티티를 설정함
1. 앨리스는 ePUF 디바이스를 획득한다.
2. 앨리스는 챌린지 C로 ePUF를 프로빙한다.
3. 앨리스는 ePUF로부터 응답 R을 획득한다.
4. 앨리스는 쌍 (C,R)을 사용하여 자신에 대한 아이덴티티를 설정한다.
i. 앨리스는 보증되지 않은 아이덴티티 키 PA를 설정하기 위해 암호화 설정을 사용할 수 있다.
ii. 앨리스는 자신의 아이덴티티에 대해 자신의 아이덴티티 키를 공개한다.
5. 앨리스는 응답의 이중 해시 와 같은 증명을 자신의 CRP에 공개하고자 할 수 있다.
앨리스가 그녀 자신에 대한 '자주적(self-sovereign)' 아이덴티티를 설정하는 이 경우는 그녀만이 제어하는 디바이스에 대해 고유하고 재현 가능한 디바이스 식별자를 제공하는 데 일정 정도 유용하다. 그러나 이러한 아이덴티티 시스템에서 신뢰할 수 있는 제3자의 결여는 검증자가 나중에 증명자의 아이덴티티와 증명자의 디바이스 사이의 링크를 신뢰해야 함을 의미한다. 이는 실세계에서 매우 제한된 애플리케이션들을 가질 수 있다.
경우 2: 앨리스는 디바이스에 대한 아이덴티티를 설정함
1. 앨리스는 ePUF 디바이스를 획득한다.
2. 앨리스는 챌린지 C로 ePUF를 프로빙한다.
3. 앨리스는 ePUF로부터 응답 R을 획득한다.
4. 앨리스는 (C,R) 쌍을 사용하여 그녀의 시스템 내 디바이스에 대한 아이덴티티를 설정한다.
i. 앨리스는 쌍 (C,R)을 자신의 디바이스에 매핑한다.
ii. 앨리스는 자신의 모든 디바이스들 및 CRP 매핑들의 데이터베이스를 유지한다.
5. 앨리스는 응답의 이중 해시 와 같은 증명을 자신의 CRP에 공개하고자 할 수 있다.
디바이스에 대한 '자주적' 아이덴티티를 생성하는 위의 경우에서, 관리자가 단순히 폐쇄된 시스템 내에서 상이한 디바이스들을 간단히 식별하려고 하는 폐쇄된 시스템 내에서 설계가 매우 유용할 수 있음을 알 수 있다. 이는 또한 나중에 다른 사람들에게 증명하는 데 유용할 수 있다. 그러나 설정 동안 신뢰할 수 있는 제3자의 결여는 시나리오에 의존하여, 디바이스들이 변경되지 않았음을 외부 검증자에게 확신시키는 데 있어 증명자를 여전히 제한한다.
경우 1 및 경우 2는 동일한 프로세스로 간주될 수 있지만 의도된 목적이 상이할 수 있다는 것에 주의한다. 따라서 경우 1 및 경우 2는, 인간 또는 기계에 대한 '자주적' 아이덴티티를 생성하기 위한 방법으로 함께 간주될 수 있으며, 여기서 후자의 경우, 시스템 관리자(이를테면, IoT 시스템에서, 앨리스)는 그녀 자신이 신뢰할 수 있는 엔티티이다. 둘 모두의 경우들에서, 앨리스가 신뢰할 수 있는 엔티티이다.
3.4.2 검증: 이 경우에 대한 검증 프로세스는 주어진 챌린지로 ePUF 디바이스를 프로빙하고 그의 응답을 검사하는 것만큼 간단하다. 외부 당사자들에 대한 더 복잡한 증명들 또는 증거가 이들에 대해 아이덴티티를 증명하기 위해 그 위에 구축될 수 있다.
3.4.3 업데이트: 이 경우에 대한 업데이트 프로세스는 관리자(이 경우 앨리스)가 향후 사용을 위해 부가적인 CRP들을 열거하는 설정 프로세스의 단순한 반복이다.
3.4.4. 폐지: 이 시나리오에서, 아이덴티티 폐지의 유일한 유형은, 이 프로세스에 수반되는 제3자가 없기 때문에 관리자(앨리스)가 독립적으로 아이덴티티를 폐지하고자 하는 경우이다. 이것은, 폐지가 앨리스가 ePUF 디바이스의 사용의 중단 및 그녀의 CRP들의 데이터베이스의 퍼징(purging) 만큼 간단할 수 있다.
이후 섹션에서, 블록체인 증명 및 증거에 의해 이 자주적 폐지가 보다 강력하게 만들어져서, 나중에 외부 당사자를 확신시킬 수 있는 방식들이 개시된다.
3.5. 아이덴티티-기반 CRP 관리
위의, 특히 원격 PUF 기반 아이덴티티 시스템에서, 설정 및 검증 프로토콜들에서 아이덴티티를 인증하는 데 사용되는 CRP들의 일회-사용 성질은 수반된 당사자들에게 CRP 관리 난제를 제시한다.
예컨대, 신뢰할 수 있는 제3자가 설정 동안 PUF 디바이스에 액세스하지 않는 경우, 향후 검증들을 위해 제3자가 저장하도록 다수의 CRP들이 열거되는 것이 바람직할 수 있다. 또한, ePUF 자체가 챌린지들 대 응답들의 결정론적 의사-랜덤 매핑으로서 작용하기 때문에, 응답들은 서로 관련이 없는 것처럼 보일 것이다. 따라서 신뢰할 수 있는 제3자가 그의 사용자들 또는 클라이언트들을 위해 CRP들의 세트들을 표로 작성하고 저장해야 하는 부담은 매우 다수의 사용자들에게 서비스를 제공해야 하는 경우 스케일링 이슈를 빠르게 제시할 것이다.
도 8a는 본 명세서에 개시된 실시예들에 따라 식별 데이터로부터 챌린지들의 결정론적 도출을 예시한다.
그러한 실시예들에 따르면, 신뢰할 수 있는 제3자에 대한 부담 이슈들을 해결하기 위해, CRP 관리는 주로 챌린지들 의 생성에서 다뤄진다. 여기에서 아이디어는 단일 마스터 챌린지, 또는 마스터 챌린지가 도출되는 마스터 데이터로부터 챌린지들이 결정론적으로(및 어쩌면, 또한 계층적으로) 도출되어야 한다는 것이다. 이 개념은 신뢰할 수 있는 제3자(또는 다른 관련 당사자)가, 비트코인 시나리오에서 '지갑 시드'로서 지칭되는 마스터 데이터만 사용하여 모든 관련 챌린지들을 복구하도록 허용하게 설계되었다는 점에서 일회-사용 비트코인 키들을 관리하기 위해 계층적 결정론적(HD) 지갑들을 사용하는 것과 유사하다.
이러한 일부 실시예들에서, 앨리스(타겟 당사자(103T))의 식별 데이터(806)는 이전 섹션들에서 제안된 것들과 같은 아이덴티티 시스템들에서 어떤 CRP들이 사용되는지를 결정하기 위해 매우 다양한 챌린지들을 생성하기 위한 마스터 데이터로서 사용된다. 식별 데이터 자체는 상이한 데이터 요소들(802)의 조합(804)을 포함할 수 있지만, 조합에서 그들은 바람직하게는 다음의 특성들을 갖는다:
·고유성 ― 식별 데이터는 그것이 관련된 엔티티에 대해 고유함; 및
·비밀성 ― 식별 데이터는 그것이 관련된 엔티티(또는 그의 소유자)에게만 알려짐.
식별 데이터의 성분들의 간단한 예들은 여권 번호, 국민 보험 번호, 이름, 생년월일 또는 보안 질문에 대한 답변들(예컨대, 어머니의 결혼 전 성) 또는 디바이스 식별의 경우 일련 번호들 및 제조 정보를 포함할 수 있다. 그러나 고유성을 보존하기 위해 퍼지-매직 기술(fuzzy-magic technique)들을 사용하여 추출될 수 있는 지문 또는 얼굴 인식 데이터와 같이 보다 진보된 기술 수단에 의해 획득된 데이터가 또한 사용될 수 있다는 것이 인식된다.
실시예들에서, 챌린지들의 세트가 도출되는 마스터 입력으로서 사용되는 '식별 데이터'는 위의 다중성을 포함할 수 있다. 이에 대한 하나의 이유는, 이전 섹션들에서 프로토콜들 중 일부가 제3자 및/또는 외부 검증 당사자와의 챌린지들의 공유에 의존한다는 것을 감안하면, 가능한 한 많은 신뢰할 수 있는 제3자들과 관련하여 정보가 비밀성을 유지하도록 보장하기 위함이다. 다수의 구성요소들을 포함하는 식별 데이터는 증명 당사자인 앨리스의 동의 없이, 임의의 제3자가 완전히 복제하는 것이 더 어려울 것이다.
식별 데이터를 사용하여 결정론적으로 CRP들을 생성하기 위한 메커니즘이 도 8a에서 도시된다. 식별 데이터의 성분 부분들은 컨케터네이션, 비트별 연산들(예컨대, XOR) 또는 임의의 다른 관련 조합 동작일 수 있는 프로세스 'A'(804)에 의해 먼저 결합되며, 이 동작은 원시 데이터를 난독화된 형식으로 변환함으로써 프라이버시를 보존하고자 할 수 있다는 것에 주의한다.
그 후, 식별 데이터는 해시 함수 또는 유사한 프로세스를 통해 마스터 챌린지 Cm으로 전환된다. 마지막으로, 마스터 챌린지는 도출 함수 f()를 사용하여 일회-사용 챌린지들의 시퀀스 을 결정론적으로 도출하는 데 사용된다. 실시예들에서, 도 8b에 도시된 바와 같이, 도출 함수 f()는 해시 함수 및 논스의 주입을 포함할 수 있어서, 각각의 연속적인 챌린지가 로서 생성되며, 여기서 i는 논스로서 역할을 한다.
프로세스 A, 식별 데이터로부터의 챌린지 Cm의 생성 및 도출 함수 f()는 모두 특정 구현의 필요에 의존하여 구성될 수 있다.
도 8c는 다른 특정 예, 즉 챌린지들의 계층적이고 결정론적인 도출을 도시한다(응답들은 도시되지 않음). 도 8b에 도시된 바와 같이 계층적 방식으로 마스터 Cm으로부터 단일-사용 챌린지 Ci를 도출하는 것이 바람직할 수 있다. 이 경우에, 이전 경우에서와 같이 특정 챌린지의 생성이 이전 챌린지들 전부에 의존할 필요가 없다는 사실에 의해 CRP 관리가 추가로 개선된다.
아이덴티티 데이터에 기초하여 챌린지들의 결정론적 도출의 사용은 아이덴티티 프로토콜들에서 증명자 앨리스 및 신뢰할 수 있는 제3자 둘 모두에 대한 저장 오버헤드를 감소시킨다. 어느 당사자든 식별 데이터(또는 그의 서브세트)만을 저장하고, 요구되는 경우 및 요구될 때, 필요한 챌린지를 재컴퓨팅하는 것이 가능하다.
또한, 앨리스는 트레이드 오프와 함께, 원하는 만큼 각각의 식별 서비스와 많은 정보를 공유하거나 보류하도록 선택함으로써 자신의 프라이버시를 맞춤화하는 옵션을 또한 갖고, 이는 그녀가 더 많은 데이터를 직접 저장할 수 있다는 것과 절충된다.
4. 예시적인 블록체인 시스템
다음은 본 개시내용의 특정 실시예들에서 사용될 수 있는 예시적인 블록체인 시스템을 설명한다. "앨리스" 및 "밥"은 두 당사자들에 대한 임의적 이름들일 뿐이며, 앨리스 및 밥은 선행 섹션이나 다음 섹션들에서와 같이 이 섹션에서 반드시 동일한 역할을 가질 필요는 없다.
일부 실시예들에서, PUF의 출력에 기초한 응답 데이터는 예컨대, 선행 섹션에서 논의된 바와 같이 체인 상에 저장될 수 있다. 체인 상에 저장된 응답 데이터는 실제 응답 자체, 또는 실제 응답의 변환 이를테면, 해시 또는 이중 해시(소위 증명 또는 해시-커밋) 또는 PUF 응답으로부터 도출된 공개-개인 키 쌍의 공개 키의 형태를 취할 수 있다. 온-체인 응답 데이터가 어떤 형태를 취하든지, 다른 검증 당사자가 아이덴티티의 증거로서 제시된 타겟 응답 또는 서명이 예상대로인지 체크하는 것을 가능하게 하는 것이다. 추가 실시예들에서, 블록체인은 챌린지-응답 쌍들을 업데이트 또는 폐지하는 것과 같이 이들을 관리하는 수단으로서 사용될 수 있다.
다음은 이러한 특징들을 구현하는 데 사용할 수 있는 블록체인 시스템의 예를 설명한다.
4.1. 예시적인 시스템 개요
도 1은 블록체인(150)을 구현하기 위한 예시적인 시스템(100)을 도시한다. 시스템(100)은 패킷-교환 네트워크(101), 통상적으로 인터넷과 같은 광역 인터네트워크를 포함할 수 있다. 패킷-교환 네트워크(101)는 패킷-교환 네트워크(101) 내에서 P2P(peer-to-peer) 네트워크(106)를 형성하도록 배열될 수 있는 복수의 블록체인 노드들(104)을 포함한다. 예시되지는 않았지만, 블록체인 노드들(104)은 거의 완전한 그래프로서 배열될 수 있다. 따라서, 각각의 블록체인 노드(104)는 다른 블록체인 노드들(104)에 고도로 연결된다.
각각의 블록체인 노드(104)는 피어들의 컴퓨터 장비를 포함하며, 노드들(104) 중 상이한 노드들은 상이한 피어에 속한다. 각각의 블록체인 노드(104)는 하나 이상의 프로세서들, 예컨대, 하나 이상의 CPU(central processing unit)들, 가속기 프로세서들, 애플리케이션 특정 프로세서 및/또는 FPGA(field programmable gate array)들, 및 다른 장비 이를테면, ASIC(application specific integrated circuit)들을 포함하는 프로세싱 장치를 포함한다. 각각의 노드는 또한 메모리, 즉 비-일시적 컴퓨터-판독 가능 매체 또는 매체들의 형태의 컴퓨터-판독 가능 저장소를 포함한다. 메모리는 하나 이상의 메모리 매체들, 예컨대, 하드 디스크와 같은 자기 매체; 솔리드 스테이트 드라이브(SSD), 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광학 디스크 드라이브와 같은 광학 매체를 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다.
블록체인(150)은 데이터의 블록들의 체인(151)을 포함하며, 여기서 블록체인(150)의 개개의 사본은 분산 또는 블록체인 네트워크(106) 내 복수의 블록체인 노드들(104) 각각에서 유지된다. 위에서 언급된 바와 같이, 블록체인(150)의 사본을 유지하는 것은 반드시 블록체인(150)을 전부 저장하는 것을 의미하지는 않는다. 대신, 블록체인(150)은 각각의 블록체인 노드(150)가 각각의 블록(151)의 블록 헤더(아래에서 논의됨)를 저장하는 한, 정리된 상태의 데이터일 수 있다. 체인의 각각의 블록(151)은 하나 이상의 트랜잭션들(152)을 포함하며, 여기서 이 맥락에서 트랜잭션은 일종의 데이터 구조를 지칭한다. 데이터 구조의 성질은 트랜잭션 모델 또는 체계(scheme)의 일부로서 사용되는 트랜잭션 프로토콜의 유형에 의존할 것이다. 주어진 블록체인은 전반에 걸쳐 하나의 특정 트랜잭션 프로토콜을 사용할 것이다. 하나의 공통 유형의 트랜잭션 프로토콜에서, 각각의 트랜잭션(152)의 데이터 구조는 적어도 하나의 입력 및 적어도 하나의 출력을 포함한다. 각각의 출력은 재산으로서 디지털 자산의 양을 표현하는 금액을 지정하며, 그의 예는 출력이 암호학적으로 잠겨 있는 사용자(103)이다(이는 잠금해제되고 그리하여 리딤(redeem) 또는 지출되기 위해 그 사용자의 서명 또는 다른 솔루션을 요구함). 각각의 입력은 선행 트랜잭션(152)의 출력을 뒤로 가리키고, 그리하여 트랜잭션들을 링크한다.
각각의 블록(151)은 또한 블록들(151)에 대한 순차적인 순서를 정의하기 위해 체인에서 이전에 생성된 블록(151)을 뒤로 가리키는 블록 포인터(155)를 포함한다. (코인베이스 트랜잭션 외의) 각각의 트랜잭션(152)은 트랜잭션들의 시퀀스들에 대한 순서를 정의하기 위해 이전 트랜잭션에 대한 역 포인터를 포함한다(트랜잭션들(152)의 시퀀스들은 분기가 허용됨을 주의함). 블록들의 체인(151)은 체인의 최초 블록이었던 제네시스(genesis) 블록(Gb)(153)까지 완전히 거슬러 올라간다. 체인(150) 초반의 하나 이상의 오리지널 트랜잭션들(152)은 선행 트랜잭션이 아닌 제네시스 블록(153)을 가리켰다.
블록체인 노드들(104) 각각은 트랜잭션들(152)을 다른 블록체인 노드들(104)로 포워딩하고 그리하여 트랜잭션들(152)이 네트워크(106) 전체에 전파되게 하도록 구성된다. 각각의 블록체인 노드(104)는 블록들(151)을 생성하고 동일한 블록체인(150)의 개개의 사본을 그들 개개의 메모리에 저장하도록 구성된다. 각각의 블록체인 노드(104)는 또한 블록(151)에 통합되기를 기다리는 트랜잭션들(152)의 순서화된 세트(또는 "풀")(154)를 유지한다. 순서화된 풀(154)은 종종 "멤풀(mempool)"로서 지칭된다. 본 명세서에서 이 용어는 임의의 특정 블록체인, 프로토콜 또는 모델에 제한되는 것으로 의도되지 않는다. 이는 노드(104)가 유효한 것으로 수락하고 노드(104)가 동일한 출력을 지출하려고 시도하는 임의의 다른 트랜잭션들을 수락하지 않을 의무가 있는 트랜잭션들의 순서화된 세트를 지칭한다.
주어진 현재 트랜잭션(152j)에서, 그(또는 각각의) 입력은 트랜잭션들의 시퀀스에서 선행 트랜잭션(152i)의 출력을 참조하는 포인터를 포함하여, 그러한 출력이 현재 트랜잭션(152j)에서 "지출"되거나 리딤됨을 지정한다. 일반적으로, 선행 트랜잭션은 순서화된 세트(154) 또는 임의의 블록(151)의 임의의 트랜잭션일 수 있다. 선행 트랜잭션(152i)은 현재 트랜잭션(152j)이 생성되거나 심지어 네트워크(106)로 전송될 때 반드시 존재할 필요는 없지만, 선행 트랜잭션(152i)은 현재 트랜잭션이 유효하기 위해 존재하고 유효성 검증될 필요가 있을 것이다. 따라서 본 명세서에서 "선행(preceding)"이라 함은 포인터들에 의해 링크된 논리적 시퀀스의 선행자를 지칭하며, 반드시 시간적 시퀀스의 전송 또는 생성 시간은 아니고, 따라서 트랜잭션들(152i, 152j)은 순서와 다르게(out-of-order)(고아 트랜잭션들에 대한 아래 논의 참조) 전송되거나 생성되는 것을 반드시 배제하지 않는다. 선행 트랜잭션(152i)은 앞선(antecedent) 트랜잭션 또는 선행자(predecessor) 트랜잭션으로 동등하게 칭해질 수 있다.
현재 트랜잭션(152j)의 입력은 또한 입력 인가, 예컨대, 선행 트랜잭션(152i)의 출력이 잠겨 있는 사용자(103a)의 서명을 포함한다. 차례로, 현재 트랜잭션(152j)의 출력은 새로운 사용자 또는 엔티티(103b)에 암호학적으로 잠길 수 있다. 따라서 현재 트랜잭션(152j)은 선행 트랜잭션(152i)의 입력에서 정의된 금액을 현재 트랜잭션(152j)의 출력에서 정의된 바와 같은 새로운 사용자 또는 엔티티(103b)에 전달할 수 있다. 일부 경우들에서 트랜잭션(152)은 다수의 사용자들 또는 엔티티들(이들 중 하나는 잔돈(change)을 주기 위해 오리지널 사용자 또는 엔티티들(103a)일 수 있음) 사이에서 입력 금액을 분할하기 위해 다수의 출력들을 가질 수 있다. 일부 경우에서 트랜잭션은 또한 하나 이상의 선행 트랜잭션들의 다수의 출력들로부터 금액들을 수집하고 현재 트랜잭션의 하나 이상의 출력들에 재분배하기 위해 다수의 입력들을 가질 수 있다.
비트코인과 같은 출력-기반 트랜잭션 프로토콜에 따르면, 개별 사용자 또는 조직과 같은 당사자(103)가 새로운 트랜잭션(152j)을 제정(enact)하기를 원할 때(수동으로 또는 당사자에 의해 사용되는 자동화된 프로세스에 의해) 제정 당사자는 자신의 컴퓨터 단말(102)로부터 수령인에게 새로운 트랜잭션을 전송한다. 제정 당사자 또는 수령인은 결국, 이 트랜잭션을 네트워크(106)의 블록체인 노드들(104) 중 하나 이상(이는 요즘에는, 통상적으로 서버들 또는 데이터 센터들이지만, 원칙적으로는 다른 사용자 단말들일 수 있음)에 전송할 것이다. 그것은 또한 새로운 트랜잭션(152j)을 제정하는 당사자(103)가 일부 예들에서는 수령인이 아니라, 블록체인 노드들(104) 중 하나 이상에 직접 트랜잭션을 전송할 수 있는 것이 배제되지 않는다. 트랜잭션을 수신한 블록체인 노드(104)는 블록체인 노드들(104) 각각에 적용되는 블록체인 노드 프로토콜에 따라 트랜잭션이 유효한지를 체크한다. 블록체인 노드 프로토콜은 통상적으로 블록체인 노드(104)가 새로운 트랜잭션(152j)의 암호화 서명이 예상되는 서명과 매칭되는지를 체크하도록 요구하며, 이는 트랜잭션들(152)의 순서화된 시퀀스에서 이전 트랜잭션(152i)에 의존한다. 이러한 출력-기반 블록체인 프로토콜에서, 이는 새로운 트랜잭션(152j)의 입력에 포함된 당사자(103)의 암호화 서명 또는 다른 인가가 새로운 트랜잭션이 할당하는 선행 트랜잭션(152i)의 출력에 정의된 조건과 매칭되는지를 체크하는 것을 포함하며, 여기에서 이 조건은 통상적으로 적어도 새로운 트랜잭션(152j)의 입력의 암호화 서명 또는 다른 인가가 새로운 트랜잭션의 입력이 링크되는 이전 트랜잭션(152i)의 출력을 잠금해제한다는 것을 체크하는 것을 포함한다. 조건은 선행 트랜잭션(152i)의 출력에 포함된 스크립트에 의해 적어도 부분적으로 정의될 수 있다. 대안적으로 이는 단순히 블록체인 노드 프로토콜만으로 고정되거나, 이들의 조합으로 인한 것일 수 있다. 어느 쪽이든, 새로운 트랜잭션(152j)이 유효한 경우, 블록체인 노드(104)는 이를 블록체인 네트워크(106) 내 하나 이상의 다른 블록체인 노드들(104)에 포워딩한다. 이러한 다른 블록체인 노드들(104)은 동일한 블록체인 노드 프로토콜에 따라 동일한 테스트를 적용하고, 이에 따라 새로운 트랜잭션(152j)을 하나 이상의 추가 노드들(104)로 포워딩하는 식이다. 이러한 방식으로, 새로운 트랜잭션은 블록체인 노드들(104)의 네트워크 전반에 걸쳐 전파된다.
출력-기반 모델에서, 주어진 출력(예컨대, UTXO)이 할당(예컨대, 지출)되는지 여부에 대한 정의는 그것이 블록체인 노드 프로토콜에 따라 다른 전방 트랜잭션(152j)의 입력에 의해 유효하게 리딤되었는지의 여부이다. 트랜잭션이 유효하기 위한 다른 조건은 리딤을 시도하는 선행 트랜잭션(152i)의 출력이 다른 트랜잭션에 의해 이미 리딤되지 않은 것이다. 재차, 유효하지 않은 경우, (무효로서 플래깅되고 경고를 위해 전파되지 않는 한) 트랜잭션(152j)은 블록체인(150)에 레코딩되거나 전파되지 않을 것이다. 이는 트랜잭터가 동일한 트랜잭션의 출력을 한번 초과로 할당하고자 시도하는 이중-지출을 경계한다. 반면, 계정-기반 모델은 계정 잔액을 유지함으로써 이중-지출을 경계한다. 재차, 트랜잭션들의 정의된 순서가 존재하기 때문에, 계정 잔액은 임의의 한 시간에 단일의 정의된 상태를 갖는다.
트랜잭션들을 유효성 검증하는 것 외에도, 블록체인 노드들(104)은 또한 일반적으로 "작업 증명"에 의해 지원되는 채굴로서 지칭되는 프로세스에서 트랜잭션들의 블록들을 생성하는 첫 번째가 되기 위해 경쟁한다. 블록체인 노드(104)에서, 새로운 트랜잭션들은 블록체인(150) 상에 레코딩된 블록(151)에 아직 나타나지 않은 유효한 트랜잭션들의 순서화된 풀(154)에 추가된다. 그 후, 블록체인 노드들은 암호화 퍼즐을 해결하도록 시도함으로써 트랜잭션들의 순서화된 세트(154)로부터 트랜잭션들(152)의 새로운 유효한 블록(151)을 조립하기 위해 경쟁한다. 통상적으로 이는 "논스(nonce)"가 계류중인 트랜잭션들(154)의 순서화된 풀의 표현과 컨케터네이팅되고(concatenated) 해시될 때, 해시의 출력이 미리 결정된 조건을 충족시키도록 논스 값을 검색하는 것을 포함한다. 예컨대, 미리 결정된 조건은 해시의 출력이 미리 정의된 특정 수의 선행 0들을 갖는 것일 수 있다. 이는 작업 증명 퍼즐의 단 하나의 특정 유형일 뿐이며 다른 유형들도 배제되지 않는다는 것에 주의한다. 해시 함수의 속성은 해시 함수가 그의 입력에 대해 예측 불가능한 출력을 갖는다는 것이다. 따라서 이 검색은 무차별 대입(brute force)에 의해서만 수행될 수 있고, 이에 따라 퍼즐을 해결하고자 하는 각각의 블록체인 노드(104)에서 상당한 양의 프로세싱 자원을 소비한다.
퍼즐을 해결하고자 하는 제1 블록체인 노드(104)는 이를 네트워크(106)에 발표하고, 그 솔루션을 증명으로서 제공하며, 이는 그 후 네트워크의 다른 블록체인 노드(104)들에 의해 쉽게 체크될 수 있다(해시에 대한 해가 주어지면, 그 해가 해시의 출력으로 하여금 조건을 충족시키게 한다는 것을 체크하는 것은 간단함). 제1 블록체인 노드(104)는 블록을 수락하고 이에 따라 프로토콜 규칙들을 시행하는 다른 노드들의 임계 컨센서스에 블록을 전파한다. 트랜잭션들의 순서화된 세트(154)는 그 후 블록체인 노드들(104) 각각에 의해 블록체인(150)에 새로운 블록(151)으로서 레코딩된다. 블록 포인터(155)가 또한 체인에서 이전에 생성된 블록(151n-1)을 뒤로 가리키는 새로운 블록(151n)에 할당된다. 예컨대, 작업 증명 솔루션을 생성하는 데 요구되는 해시 형태의 상당량의 노력은 블록체인 프로토콜의 규칙들에 따르려는 제1 노드(104)의 의도를 시그널링한다. 이러한 규칙들은 트랜잭션이 이전에 유효성 검증된 트랜잭션과 동일한 출력을 할당 ― 이는 이중 지출로서 달리 알려짐 ― 하는 경우 트랜잭션을 유효한 것으로 수락하지 않는 것을 포함한다. 일단 생성되면, 블록(151)은 블록체인 네트워크(106) 내 블록체인 노드들(104) 각각에서 인식 및 유지되기 때문에 수정될 수 없다. 블록 포인터(155)는 또한 블록들(151)에 순차적인 순서를 부과한다. 트랜잭션들(152)은 네트워크(106)의 각각의 블록체인 노드(104)에서 순서화된 블록들에 레코딩되기 때문에, 이는 이에 따라, 트랜잭션들의 변경 불가능한 공개 원장을 제공한다.
임의의 주어진 시간에 퍼즐을 해결하기 위해 경쟁하는 상이한 블록체인 노드들(104)은 솔루션을 검색하기 시작한 시기 또는 트랜잭션이 수신된 순서에 의존하여, 임의의 주어진 시간에 아직 공개되지 않은 트랜잭션들 풀(154)의 상이한 스냅샷들에 기초하여 퍼즐을 해결할 수 있다는 것에 주의한다. 누구든 각자의 퍼즐을 먼저 해결하는 사람은 어느 트랜잭션들(152)이 어떤 순서로 다음의 새로운 블록(151n)에 포함되는지를 정의하고, 공개되지 않은 트랜잭션들의 현재 풀(154)은 업데이트된다. 그 후 블록체인 노드들(104)은 공개되지 않은 트랜잭션들(154)의 새롭게 정의된 순서화된 풀로부터 블록을 생성하기 위해 계속 경쟁한다. 발생할 수 있는 임의의 "포크(fork)" ― 이는 2개의 블록체인 노드들(104)이 서로 매우 짧은 시간 내에 그의 퍼즐을 해결하여서, 블록체인에 대한 상충되는 뷰(view)가 노드들 사이에 전파되는 경우임 ― 를 해결하기 위한 프로토콜이 또한 존재한다. 요컨대, 가장 길게 성장하는 포크의 갈래가 확정적인 블록체인(150)이 된다. 동일한 트랜잭션들이 포크들 둘 모두에 나타날 것이므로, 이는 네트워크의 사용자들 또는 에이전트들에게 영향을 미치지 않아야 한다.
비트코인 블록체인(및 대부분의 다른 블록체인들)에 따르면, 새로운 블록(104)을 성공적으로 구성하는 노드에는 (하나의 에이전트 또는 사용자로부터 다른 에이전트 또는 사용자로 디지털 자산의 금액을 이전하는 에이전트-간 또는 사용자-간 트랜잭션과 대조적으로) 디지털 자산의 부가적인 정의된 양을 분배하는 새로운 특별한 종류의 트랜잭션들에서 디지털 자산의 부가적인 수락된 금액을 새롭게 할당하는 능력이 승인된다. 이 특별한 유형의 트랜잭션은 일반적으로 "코인베이스 트랜잭션"으로서 지칭되지만, "초기 트랜잭션" 또는 "생성 트랜잭션"이라고도 칭해질 수 있다. 그것은 통상적으로 새로운 블록(151n)의 제1 트랜잭션을 형성한다. 작업 증명은 나중에 이 특별한 트랜잭션이 리딤되도록 허용하는 프로토콜 규칙들을 따르도록 새로운 블록을 구성하는 노드의 의도를 시그널링한다. 블록체인 프로토콜 규칙은 이 특별한 트랜잭션이 리딤되기 전에 만기 기간 예컨대, 100개의 블록들을 요구할 수 있다. 종종 일반(비-생성) 트랜잭션(152)이 또한 그 트랜잭션이 공개된 블록(151n)을 생성한 블록체인 노드(104M)를 추가로 보상하기 위해, 그의 출력들 중 하나에 부가적인 트랜잭션 수수료를 지정할 것이다. 이 수수료는 일반적으로 "트랜잭션 수수료"로서 지칭되고 아래에서 논의된다.
트랜잭션 유효성 검증 및 공개와 관련된 자원들로 인해, 통상적으로 적어도 블록체인 노드들(104) 각각은 하나 이상의 물리적 서버 유닛들, 또는 심지어 전체 데이터 센터를 포함하는 서버의 형태를 취한다. 그러나 원칙적으로 임의의 주어진 블록체인 노드(104)는 사용자 단말 또는 함께 네트워킹된 사용자 단말들의 그룹의 형태를 취할 수 있다.
각각의 블록체인 노드(104)의 메모리는 블록체인 노드 프로토콜에 따라 각자의 역할 또는 역할들을 수행하고 트랜잭션들(152)을 처리하기 위해 블록체인 노드(104)의 프로세싱 장치 상에서 실행되도록 구성된 소프트웨어를 저장한다. 본 명세서에서 블록체인과 노드(104)에 기인한 임의의 액션은 각자의 컴퓨터 장비의 프로세싱 장치 상에서 실행되는 소프트웨어에 의해 수행될 수 있다는 것이 이해될 것이다. 노드 소프트웨어는 애플리케이션 계층, 또는 운영 체제 계층이나 프로토콜 계층과 같은 하위 계층 또는 이들의 임의의 조합에서 하나 이상의 애플리케이션들로 구현될 수 있다.
또한 네트워크(101)에는 소비 사용자들의 역할을 하는 복수의 당사자들(103) 각각의 컴퓨터 장비(102)가 연결되어 있다. 이러한 사용자들은 블록체인 네트워크(106)와 상호작용할 수 있지만 트랜잭션들을 유효성 검증하거나 블록들을 구성하는 데 참여하지 않는다. 이러한 사용자들 또는 에이전트들(103) 중 일부는 트랜잭션들에서 전송자들 및 수령인들로서 작용할 수 있다. 다른 사용자들은 반드시 전송자들 또는 수령인들로서 작용할 필요 없이 블록체인(150)과 상호작용할 수 있다. 예컨대, 일부 당사자들은 블록체인(150)의 사본을 저장하는 저장 엔티티들로서 작용할 수 있다(예컨대, 블록체인 노드(104)로부터 블록체인의 사본을 획득함).
당사자들(103) 중 일부 또는 전부는 상이한 네트워크, 예컨대, 블록체인 네트워크(106) 위에 오버레이된 네트워크의 부분으로서 연결될 수 있다. 블록체인 네트워크의 사용자들(종종 "클라이언트"로서 지칭됨)은 블록체인 네트워크(106)를 포함하는 시스템의 일부로서 언급될 수 있지만; 이러한 사용자들은 블록체인 노드들에서 요구되는 역할을 수행하지 않기 때문에 블록체인 노드들(104)이 아니다. 대신에, 각각의 당사자(103)는 블록체인 네트워크(106)와 상호작용할 수 있고 그리하여 블록체인 노드(106)에 연결(즉, 통신)함으로써 블록체인(150)을 활용할 수 있다. 제1 당사자(103a) 및 그/그녀의 개개의 컴퓨터 장비(102a) 및 제2 당사자(103b) 및 그/그녀의 개개의 컴퓨터 장비(102b)인 두 당사자들(103) 및 이들의 개개의 장비(102)가 예시 목적으로 도시된다. 훨씬 더 많은 이러한 당사자들(103) 및 이들의 개개의 컴퓨터 장비(102)가 존재하고 시스템(100)에 참여할 수 있지만, 편의상 그것들은 예시되지 않는다는 것이 이해될 것이다. 각각의 당사자(103)는 개인 또는 조직일 수 있다. 순전히 예시로서, 제1 당사자(103a)는 본 명세서에서 앨리스(Alice)로서 지칭되고 제2 당사자(103b)는 밥(Bob)으로서 지칭되지만, 이것이 제한적이지 않고 본 명세서에서 앨리스 또는 밥에 대한 임의의 참조는 각각 "제1 당사자" 및 "제2 당사자"로 대체될 수 있다는 것이 인지될 것이다.
각각의 당사자(103)의 컴퓨터 장비(102)는 하나 이상의 프로세서들, 예컨대, 하나 이상의 CPU들, GPU들, 다른 가속기 프로세서들, 애플리케이션 특정 프로세서들 및/또는 FPGA들을 포함하는 개개의 프로세싱 장치를 포함한다. 각각의 당사자(103)의 컴퓨터 장비(102)는 메모리, 즉 비-일시적 컴퓨터-판독 가능 매체 또는 매체들의 형태의 컴퓨터-판독 가능 저장소를 더 포함한다. 이 메모리는 하나 이상의 메모리 매체들, 예컨대, 하드 디스크와 같은 자기 매체; 솔리드 스테이트 SSD, 플래시 메모리 또는 EEPROM과 같은 전자 매체; 및/또는 광학 디스크 드라이브와 같은 광학 매체를 사용하는 하나 이상의 메모리 유닛들을 포함할 수 있다. 각각의 당사자(103)의 컴퓨터 장비(102) 상의 메모리는 프로세싱 장치 상에서 실행되도록 배열된 적어도 하나의 클라이언트 애플리케이션(105)의 개개의 인스턴스를 포함하는 소프트웨어를 저장한다. 본 명세서에서 주어진 당사자(103)에 기인한 임의의 액션은 개개의 컴퓨터 장비(102)의 프로세싱 장치 상에서 실행되는 소프트웨어를 사용하여 수행될 수 있다는 것이 이해될 것이다. 각각의 당사자(103)의 컴퓨터 장비(102)는 적어도 하나 사용자 단말, 예컨대, 데스크 톱 또는 랩톱 컴퓨터, 태블릿, 스마트폰, 또는 스마트워치와 같은 웨어러블 디바이스를 포함한다. 주어진 당사자(103)의 컴퓨터 장비(102)는 또한 사용자 단말을 통해 액세스되는 클라우드 컴퓨팅 자원들과 같은 하나 이상의 다른 네트워킹된 자원들을 포함할 수 있다.
예컨대, 서버로부터 다운로드되거나, 또는 이동식 저장 디바이스 이를테면, 이동식 SSD, 플래시 메모리 키, 이동식 EEPROM, 이동식 자기 디스크 드라이브, 자기 플로피 디스크 또는 테이프, 광학 디스크 이를테면, CD 또는 DVD ROM 또는 이동식 광학 드라이브 등 상에서 제공되는 클라이언트 애플리케이션(105)은 적절한 컴퓨터-판독 가능 저장 매체 또는 매체들 상에서 임의의 주어진 당사자(103)의 컴퓨터 장비(102)에 초기에 제공될 수 있다.
클라이언트 애플리케이션(105)은 적어도 "지갑" 기능을 포함한다. 이는 2개의 메인 기능성들을 갖는다. 이들 중 하나는 개개의 당사자(103)가 트랜잭션들(152)을 생성하고 인가(예컨대, 서명)하여 하나 이상의 비트코인 노드들(104)에 전송하여, 이어서 블록체인 노드들(104)의 네트워크 전반에 걸쳐 전파되고 그리하여 블록체인(150)에 포함되는 것을 가능하게 하는 것이다. 남은 하나는 개개의 당사자에게 자신이 현재 소유하고 있는 디지털 자산의 금액을 다시 보고하는 것이다. 출력-기반 시스템에서, 이 제2 기능성은 블록체인(150) 전반에 걸쳐 흩어져 있는 해당 당사자에 속하는 다양한 트랜잭션들(152)의 출력들에서 정의된 금액들을 대조하는 것을 포함한다.
참고: 다양한 클라이언트 기능성이 주어진 클라이언트 애플리케이션(105)에 통합되는 것으로서 설명될 수 있지만, 이는 반드시 제한적인 것은 아니며, 대신 본 명세서에서 설명된 클라이언트 기능성은 API를 통해 인터페이싱하거나 하나가 남은 하나에 플러그인하는 두 개 이상의 개별 애플리케이션들의 세트에서 구현될 수 있다. 보다 일반적으로, 클라이언트 기능성은 애플리케이션 계층 또는 운영 체제와 같은 하위 계층 또는 이들의 임의의 조합에서 구현될 수 있다. 다음은 클라이언트 애플리케이션(105)과 관련하여 설명될 것이지만, 이것이 제한적이지 않다는 것이 인지될 것이다.
각각의 컴퓨터 장비(102) 상의 클라이언트 애플리케이션 또는 소프트웨어(105)의 인스턴스는 네트워크(106)의 블록체인 노드들(104) 중 적어도 하나에 동작 가능하게 커플링된다. 이는 클라이언트(105)의 지갑 기능이 트랜잭션들(152)을 네트워크(106)로 전송하는 것을 가능하게 한다. 클라이언트(105)는 또한 개개의 당사자(103)가 수령인인 임의의 트랜잭션들에 대해 블록체인(150)에 질의하기 위해(또는 실시예들에서, 블록체인(150)은 그의 공개 가시성을 통해 부분적으로 트랜잭션들의 신뢰를 제공하는 공공 시설(public facility)이므로, 실제로 블록체인(150)에서 다른 당사자들의 트랜잭션을 검사하기 위해) 블록체인 노드들(104)에 접촉할 수 있다. 각각의 컴퓨터 장비(102) 상의 지갑 기능은 트랜잭션 프로토콜에 따라 트랜잭션들(152)을 공식화(formulate) 하고 전송하도록 구성된다. 위에서 제시된 바와 같이, 각각의 블록체인 노드(104)는 블록체인 노드 프로토콜에 따라 트랜잭션들(152)을 유효성 검증하고 트랜잭션들(152)을 포워딩하여 이들을 블록체인 네트워크(106) 전체에 전파하도록 구성된 소프트웨어를 실행한다. 트랜잭션 프로토콜 및 노드 프로토콜은 서로 대응하며, 주어진 트랜잭션 프로토콜은 주어진 트랜잭션 모델을 함께 구현하도록 주어진 노드 프로토콜을 따른다. 동일한 트랜잭션 프로토콜이 블록체인(150) 내 모든 트랜잭션들(152)에 사용된다. 동일한 노드 프로토콜이 네트워크(106) 내 모든 노드들(104)에 의해 사용된다.
주어진 당사자(103), 이를테면 앨리스가 블록체인(150)에 포함될 새로운 트랜잭션(152j)을 전송하기를 원할 때, 그녀는 (자신의 클라이언트 애플리케이션(105)의 지갑 기능을 사용하여) 관련 트랜잭션 프로토콜에 따라 새로운 트랜잭션을 공식화한다. 그 후, 그녀는 클라이언트 애플리케이션(105)으로부터 그녀가 연결되는 하나 이상의 블록체인 노드들(104)에 트랜잭션(152)을 전송한다. 예컨대, 이는 앨리스의 컴퓨터(102)에 가장 잘 연결된 블록체인과 노드(104)일 수 있다 임의의 주어진 블록체인 노드(104)가 새로운 트랜잭션(152j)을 수신할 때, 주어진 노드는 블록체인 노드 프로토콜 및 각자의 역할에 따라 이를 처리한다. 이는 새롭게 수신된 트랜잭션(152j)이 "유효"하기 위한 특정 조건을 충족시키는지를 먼저 체크하는 것을 포함하며, 그의 예들은 곧 보다 자세히 논의될 것이다. 일부 트랜잭션 프로토콜들에서, 유효성 검증을 위한 조건은 트랜잭션들(152)에 포함된 스크립트들에 의해 트랜잭션 단위로 구성 가능할 수 있다. 대안적으로, 조건은 단순히 노드 프로토콜의 내장 피처이거나, 스크립트 및 노드 프로토콜의 조합으로 정의될 수 있다.
새롭게 수신된 트랜잭션(152j)이 유효한 것으로 간주되기 때문에 테스트를 통과한다는 것을 조건으로(즉, 그것이 "유효성 검증"된다는 조건으로), 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(104)는 새로운 유효성 검증된 트랜잭션(152)을 그 블록체인 노드(104)에서 유지되는 블록체인들(154)의 순서화된 세트(154)에 추가할 것이다. 또한, 트랜잭션(152j)을 수신하는 임의의 블록체인 노드(104)는 유효성 검증된 트랜잭션(152)을 네트워크(106)의 하나 이상의 다른 블록체인 노드들(104)로 전방으로 전파시킬 것이다. 각각의 블록체인 노드(104)가 동일한 프로토콜을 적용하기 때문에, 트랜잭션(152j)이 유효하다고 가정하면, 이는 그것이 곧 전체 네트워크(106)에 걸쳐 전파될 것임을 의미한다.
일단 주어진 블록체인 노드(104)에서 유지되는 계류중인 트랜잭션(154)의 순서화된 풀에 허용되면, 블록체인 노드(104)는 새로운 트랜잭션(152)을 포함하여 154의 각자의 풀의 최신 버전 상에서 작업 증명 퍼즐을 해결하기 위해 경쟁하기 시작할 것이다(다른 블록체인 노드들(104)은 트랜잭션들의 상이한 풀(154)에 기초하여 퍼즐을 해결하려고 시도할 수 있지만 누구든 먼저 해결하는 사람은 최신 블록(151)에 포함된 트랜잭션들의 세트를 정의할 것임을 상기한다). 결국 블록체인 노드(104)는 앨리스의 트랜잭션(152j)을 포함하는 순서화된 풀(154)의 일부에 대한 퍼즐을 해결할 것이다. 새로운 트랜잭션(152j)을 포함하는 풀(154)에 대한 작업 증명이 완료되면, 이는 변경 불가능하게 블록체인(150)의 블록들(151) 중 하나의 부분이 된다. 각각의 트랜잭션(152)은 이전 트랜잭션에 대한 역 포인터를 포함하여서, 트랜잭션들의 순서가 또한 변경 불가능하게 레코딩된다.
상이한 블록체인 노드들(104)은 주어진 트랜잭션의 상이한 인스턴스들을 먼저 수신하고 이에 따라 하나의 인스턴스가 새로운 블록(151)에 공개되기 전에 어떤 인스턴스가 '유효'한지에 관한 상충되는 뷰들을 가질 수 있으며, 이 때 모든 블록체인 노드들(104)은 공개된 인스턴스가 유일한 유효 인스턴스라는 것에 동의한다. 블록체인 노드(104)가 하나의 인스턴스를 유효한 것으로 수락하고 그 후 제2 인스턴스가 블록체인(150)에 레코딩되었음을 발견하는 경우, 해당 블록체인 노드(104)는 이를 수락해야 하며 초기에 수락된 인스턴스(즉, 블록(151)에서 공개되지 않은 인스턴스)를 폐기(즉, 유효하지 않은 것으로 취급)할 것이다.
일부 블록체인 네트워크들에 의해 동작되는 트랜잭션 프로토콜의 대안적인 유형은 계정-기반 트랜잭션 모델의 일부로서 "계정-기반" 프로토콜로서 지칭될 수 있다. 계정-기반의 경우에, 각각의 트랜잭션은 과거 트랜잭션들의 시퀀스에서 선행 트랜잭션의 UTXO를 뒤로 참조하기 보다는, 절대 계정 잔액을 참조함으로써 전달될 금액을 정의한다. 모든 계정들의 현재 상태는 블록체인과 별개로 해당 네트워크의 노드들에 의해 저장되며 지속적으로 업데이트된다. 이러한 시스템에서, 트랜잭션들은 계정의 실행 중인 트랜잭션 집계(또한 "포지션"이라 불림)를 사용하여 순서화된다. 이 값은 그의 암호화 서명의 일부로 발신인에 의해 서명되고 트랜잭션 참조 계산의 부분으로서 해시된다. 게다가, 선택적 데이터 필드가 또한 트랜잭션에 서명할 수 있다. 이 데이터 필드는 예컨대, 이전 트랜잭션 ID가 데이터 필드에 포함된 경우 이전 트랜잭션을 뒤로 가리킬 수 있다.
4.2. UTXO-기반 모델
도 2는 예시적인 트랜잭션 프로토콜을 예시한다. 이는 UTXO-기반 프로토콜의 예이다. 트랜잭션(152)(약칭 "Tx")은 블록체인(150)의 기본 데이터 구조이다(각각의 블록(151)은 하나 이상의 트랜잭션들(152)을 포함함). 다음은 출력-기반 또는 "UTXO" 기반 프로토콜을 참조하여 설명될 것이다. 그러나 이것은 모든 가능한 실시예들로 제한되지 않는다. 예시적인 UTXO-기반 프로토콜이 비트코인을 참조하여 설명되지만, 다른 예시적인 블록체인 네트워크들 상에서 동일하게 구현될 수 있다는 것에 주의한다.
UTXO-기반 모델에서, 각각의 트랜잭션("Tx")(152)은 하나 이상의 입력들(202) 및 하나 이상의 출력들(203)을 포함하는 데이터 구조를 포함한다. 각각의 출력(203)은 (UTXO가 아직 리딤되지 않은 경우) 다른 새로운 트랜잭션의 입력(202)에 대한 소스로서 사용될 수 있는 미지출 트랜잭션 출력(unspent transaction output; UTXO)을 포함할 수 있다. UTXO는 디지털 자산의 금액을 지정하는 값을 포함한다. 이는 분산 원장 상의 세팅된 수의 토큰들을 표현한다. UTXO는 또한 다른 정보 중에서도, 그것이 발생한 트랜잭션의 트랜잭션 ID를 포함할 수 있다. 트랜잭션 데이터 구조는 또한 입력 필드(들)(202) 및 출력 필드(들)(203)의 크기의 표시자를 포함할 수 있는 헤더(201)를 포함할 수 있다. 헤더(201)는 또한 트랜잭션의 ID를 포함할 수 있다. 실시예들에서, 트랜잭션 ID는 (트랜잭션 ID 자체는 제외한) 트랜잭션 데이터의 해시이고 노드들(104)에게 제출된 원시 트랜잭션(152)의 헤더(201)에 저장된다.
앨리스(103a)가 해당 디지털 자산의 금액을 밥(103b)에게 전달하는 트랜잭션(152j)을 생성하기를 원한다고 하자. 도 2에서 앨리스의 새로운 트랜잭션(152j)은 "Tx1"로서 라벨이 지정된다. 이는 시퀀스의 선행 트랜잭션(152i)의 출력(203)에서 앨리스에게 잠긴 디지털 자산의 금액을 취하고, 이 중 적어도 일부를 밥에게 전달한다. 선행 트랜잭션(152i)은 도 2에서 "Tx0"로 라벨이 지정된다. Tx0 및 Tx1은 임의의 라벨일 뿐이다. 이들은, Tx0이 블록체인(151)의 최초 트랜잭션이거나, Tx1이 풀(154)에서 바로 다음 트랜잭션이라는 것을 반드시 의미하지는 않는다. Tx1은 앨리스에게 잠긴 미지출 출력(203)을 여전히 갖는 임의의 선행(즉, 앞선) 트랜잭션을 뒤로 가리킬 수 있다.
선행 트랜잭션(Tx0)은 앨리스가 자신의 새로운 트랜잭션(Tx1)을 생성할 때, 또는 적어도 그녀가 그것을 네트워크(106)에 전송할 때까지 이미 유효성 검증되고 블록체인(150)의 블록(151)에 포함되었을 수 있다. 이는 그 시간에 이미 블록들(151) 중 하나에 포함되었거나, 순서화된 세트(154)에서 여전히 대기 중일 수 있으며, 이 경우에 곧 새로운 블록(151)에 포함될 것이다. 대안적으로 Tx0 및 Tx1이 생성되고 네트워크(106)에 함께 전송될 수 있거나 또는 노드 프로토콜이 "고아" 트랜잭션들을 버퍼링하도록 허용하는 경우 Tx0는 Tx1 이후에도 전송될 수 있다. 트랜잭션들의 시퀀스의 맥락에서 본 명세서에서 사용된 바와 같은 "선행" 및 "후속"이라는 용어들은 (트랜잭션이 다른 트랜잭션을 뒤로 가리키고, 이와 같이 계속되는) 트랜잭션들에서 지정된 트랜잭션 포인터들에 의해 정의된 바와 같은 시퀀스에서의 트랜잭션들의 순서를 지칭한다. 이들은 "선행자(predecessor)" 및 "후행자(successor)", 또는 "앞선(antecedent)"과 "후위의(descendant)", "부모" 및 "자식" 등으로 동등하게 대체될 수 있다. 이는 그것들이 생성되고, 네트워크(106)로 전송되거나, 임의의 주어진 블록체인 노드(104)에 도달하는 순서를 반드시 의미하지는 않는다. 그럼에도 불구하고, 선행 트랜잭션(앞선 트랜잭션 또는 "부모")을 가리키는 후속 트랜잭션(후위의 트랜잭션 또는 "자식")은 부모 트랜잭션이 유효성 검증될 때까지 그리고 유효성 검증되지 않는 한 유효성 검증되지 않을 것이다. 그의 부모 이전에 블록체인과 노드(104)에 도달하는 자식은 고아로 간주된다. 이는 노드 프로토콜 및/또는 노드 거동에 의존하여 부모를 기다리기 위해 특정 시간 동안 버퍼링되거나 폐기될 수 있다.
선행 트랜잭션(Tx0)의 하나 이상의 출력들(203) 중 하나는, 본 명세서에서 UTXO0으로서 라벨이 지정되는 특정 UTXO를 포함한다. 각각의 UTXO는 UTXO에 의해 표현되는 디지털 자산의 금액을 지정하는 값 및 후속 트랜잭션이 유효성 검증되고 따라서 UTXO가 성공적으로 리딤되기 위하여 후속 트랜잭션의 입력(202)에서 잠금해제 스크립트에 의해 만족되어야 하는 조건을 정의하는 잠금 스크립트를 포함한다. 통상적으로, 잠금 스크립트는 특정 당사자(그것이 포함된 트랜잭션의 수혜자)에게로 금액을 잠근다. 즉, 잠금 스크립트는, 통상적으로 후속 트랜잭션의 입력의 잠금해제 스크립트가 선행 트랜잭션이 잠겨 있는 당사자의 암호화 서명을 포함하는 조건을 포함하는 잠금해제 조건을 정의한다.
잠금 스크립트(일명 scriptPubKey)는 노드 프로토콜에 의해 인식되는 도메인 특정 언어로 작성된 코드 조각이다. 이러한 언어의 특정 예는 블록체인 네트워크에 의해 사용되는 "스크립트(Script)"(대문자 S)라 불린다. 잠금 스크립트는 트랜잭션 출력(203)을 지출하는 데 어떤 정보가 필요한지, 예컨대, 앨리스의 서명 요건을 지정한다. 잠금해제 스크립트들은 트랜잭션들의 출력에서 나타난다. 잠금해제 스크립트(일명 scriptSig)는 잠금 스크립트 기준들을 충족시키는 데 필요한 정보를 제공하는 도메인 특정 언어로 작성된 코드 조각이다. 예컨대, 이는 밥의 서명을 포함할 수 있다. 잠금해제 스크립트들은 트랜잭션들의 입력(202)에 나타난다.
따라서 예시된 예에서, Tx0의 출력(203)의 UTXO0은 UTXO0가 리딤되기 위해(엄밀히, UTXO0을 리딤하고자 시도하는 후속 트랜잭션이 유효하기 위해) 앨리스의 서명 Sig PA를 요구하는 잠금 스크립트 [Checksig PA]를 포함한다. [Checksig PA]는 앨리스의 공개-개인 키 쌍으로부터의 공개 키 PA의 표현(예컨대, 해시)을 포함한다. Tx1의 입력(202)은 (예컨대, 실시예에서, 전체 트랜잭션 Tx0의 해시인 그의 트랜잭션 Id인 TxID0에 의해) Tx1을 뒤로 가리키는 포인터를 포함한다. Tx1의 입력(202)은 Tx0 내에서 UTXO0을 식별하는 인덱스를 포함하여, Tx0의 임의의 다른 가능한 출력들 사이에서 그것을 식별한다. Tx1의 입력(202)은 앨리스의 암호화 서명을 포함하는 잠금해제 스크립트 <Sig PA>를 더 포함하며, 이는 앨리스가 키 쌍으로부터 자신의 개인 키를 데이터의 미리 정의된 부분(때로는 암호화에서 "메시지"라 불림)에 적용함으로써 생성된다. 유효한 서명을 제공하기 위해 앨리스에 의해 서명될 필요가 있는 데이터(또는 "메시지")는 잠금 스크립트, 노드 프로토콜 또는 이들의 조합에 의해 정의될 수 있다.
새로운 트랜잭션 Tx1이 블록체인 노드(104)에 도달할 때, 노드는 노드 프로토콜을 적용한다. 이는 잠금해제 스크립트가 잠금 스크립트에 정의된 조건(이 조건은 하나 이상의 기준들을 포함할 수 있음)을 충족시키는지를 체크하기 위해 잠금 스크립트 및 잠금해제 스크립트를 함께 실행하는 것을 포함한다. 실시예들에서, 이는 2개의 스크립트들을 컨케터네이팅(concatenating)하는 것을 수반한다.
<Sig PA> <PA> || [Checksig PA]
여기에서 "||"는 컨케터네이션을 표현하고 "<...>"는 스택 상에 데이터를 배치하는 것을 의미하고, "[…]"는 잠금 스크립트(이 예에서, 스택-기반 언어)에 의해 구성된 함수이다. 동등하게, 스크립트들을 컨케터네이팅하는 대신, 스크립트들은 공통 스택을 사용하여 번갈아 실행될 수 있다. 어느 쪽이든, 함께 실행될 때, 스크립트들은 Tx0의 출력의 잠금 스크립트에 포함된 바와 같은 앨리스의 공개 키 PA를 사용하여, Tx1의 입력의 잠금해제 스크립트가 데이터의 예상되는 부분에 서명하는 앨리스의 서명을 포함한다는 것을 인증한다. 이 인증을 수행하기 위하여 데이터의 예상되는 부분 자체("메시지")가 또한 포함될 필요가 있다. 실시예들에서, 서명된 데이터는 Tx1 전체를 포함한다(이에 따라, 평문으로 데이터의 서명된 부분을 지정하는 별개의 요소가 포함될 필요가 없는데, 그 이유는 그것이 이미 본질적으로 존재하기 때문임).
공개-개인 암호화에 의한 인증의 세부사항들은 당업자에게 친숙할 것이다. 기본적으로, 앨리스가 자신의 개인 키를 사용하여 메시지에 서명한 경우, 앨리스의 공개 키 및 평문의 메시지를 감안하여, 노드(104)와 같은 다른 엔티티는 메시지가 앨리스에 의해 서명된 것임이 틀림없다는 것을 인증할 수 있다. 서명은 통상적으로 메시지를 해시하는 것, 해시에 서명하는 것, 그리고 이를 서명으로서 메시지에 태깅하고, 이에 따라 공개 키의 임의의 보유자(holder)가 서명을 인증하는 것을 가능하게 하는 것을 포함한다. 따라서 여기에서 특정 데이터 조각 또는 트랜잭션의 일부 등에 서명하는 것에 대한 임의의 참조는 실시예들에서 해당 데이터 조각 또는 트랜잭션 일부의 해시에 서명하는 것을 의미할 수 있다는 것에 주의한다.
Tx1의 잠금해제 스크립트가 Tx0의 잠금 스크립트에 지정된 하나 이상의 조건들을 충족시키는 경우(이에 따라, 보여진 예에서, 앨리스의 서명이 Tx1에서 제공되고 인증된 경우), 블록체인과 노드(104)는 Tx1이 유효한 것으로 간주한다. 이는 블록체인 노드(104)가 계류중인 트랜잭션들(154)의 순서화된 풀에 Tx1을 추가할 것임을 의미한다. 블록체인 노드(104F)는 또한 트랜잭션 Tx1을 네트워크(106) 내 하나 이상의 다른 블록체인 노드들(104)로 포워딩할 것이어서, 그 트랜잭션이 네트워크(106) 전반에 걸쳐 전파될 것이다. Tx1이 유효성 검증되고 블록체인(150)에 포함되면, 이는 지출된 것으로 Tx0으로부터의 UTXO0를 정의한다. Tx1은 그것이 미지출 트랜잭션 출력(203)을 지출하는 경우에만 유효할 수 있다는 것에 주의한다. 다른 트랜잭션(152)에 의해 이미 지출된 출력을 지출하려고 시도하는 경우, 다른 모든 조건들이 충족되는 경우조차도 Tx1은 유효하지 않을 것이다. 따라서 블록체인과 노드(104)는 또한 선행 트랜잭션 Tx0에서 참조된 UTXO가 이미 지출되었는지(즉, 다른 유효한 트랜잭션에 대한 유효한 입력을 이미 형성했는지)를 체크할 필요가 있다. 이는 트랜잭션들(152) 상에 정의된 순서를 부과하는 것이 블록체인(150)에 대해 중요한 하나의 이유이다. 실제로, 주어진 블록체인 노드(104)는 트랜잭션들(152)이 지출된 UTXO들(203)을 마킹하는 별개의 데이터베이스를 유지할 수 있지만, 궁극적으로 UTXO가 지출되었는지를 정의하는 것은 블록체인(150)의 다른 유효한 트랜잭션에 대한 유효한 입력이 이미 형성되었는지의 여부이다.
주어진 트랜잭션(152)의 모든 출력들(203)에서 지정된 총 금액이 모든 그의 입력들(202)에 의해 가리켜지는 총 금액보다 큰 경우, 이는 대부분의 트랜잭션 모델들에서 무효에 대한 다른 근거이다. 따라서 이러한 트랜잭션들은 전파되지도 않고 블록(151)에 포함되지 않을 것이다.
UTXO-기반 트랜잭션 모델에서, 주어진 UTXO는 전체로서 지출될 필요가 있다는 것에 주의한다. 다른 프랙션(fraction)이 지출되면서, 지출된 것으로 UTXO에서 정의된 금액의 프랙션을 "남겨둘" 수는 없다. 그러나 UTXO로부터의 금액은 다음 트랜잭션의 다수의 출력들 사이에서 분할될 수 있다. 예컨대, Tx0의 UTXO0에 정의된 금액은 Tx1의 다수의 UTXO들 사이에서 분할될 수 있다. 따라서 앨리스가 UTXO0에 정의된 모든 금액을 밥에게 주기를 원하지 않는 경우, 앨리스는 Tx1의 제2 출력에서 자신에게 잔돈을 주거나, 다른 당사자에게 지불하는데 나머지를 사용할 수 있다.
실제로, 앨리스는 또한 일반적으로 블록(151)에 그녀의 트랜잭션(104)을 성공적으로 포함시키는 비트코인 노드(104)에 대한 수수료를 포함할 필요가 있을 것이다. 앨리스가 그러한 수수료를 포함시키지 않는 경우, Tx0은 블록체인 노드들(104M)에 의해 거부될 수 있고, 이에 따라 기술적으로 유효하더라도, 전파되어 블록체인(150)에 포함되지 않을 수 있다(노드프로토콜은 블록체인 노드들(104)이 원하지 않는 경우 이들에게 트랜잭션들(152)을 수락하도록 강요하지 않음). 일부 프로토콜들에서, 트랜잭션 수수료는 자체의 별개의 출력(203)을 요구하지 않는다(즉, 별개의 UTXO가 필요하지 않음). 대신, 주어진 트랜잭션(152)의 입력(들)(202)에 의해 가리켜지는 총 금액과 출력(들)(203)에 지정된 총 금액 사이의 임의의 차이는 트랜잭션을 공개한 블록체인 노드(104)에게 자동으로 주어진다. 예컨대, UTXO0에 대한 포인터가 Tx1에 대한 유일한 입력이고 Tx1는 단 하나의 출력 UTXO1만을 갖는다고 하자. UTXO0에 지정된 디지털 자산의 금액이 UTXO1에 지정된 금액보다 큰 경우, 차이는 UTXO1을 포함하는 블록을 생성하기 위한 작업 증명 경쟁에서 승리한 노드(104)에 의해 할당될 수 있다. 그러나 대안적으로 또는 부가적으로, 트랜잭션 수수료가 트랜잭션(152)의 UTXO들(203) 중 자체 UTXO에서 명시적으로 지정될 수 있다는 것이 반드시 배제되는 것은 아니다.
앨리스 및 밥의 디지털 자산들은 블록체인(150)의 임의의 위치의 임의의 트랜잭션들(152)에서 그들에게 잠겨 있는 UTXO로 구성된다. 따라서 통상적으로, 주어진 당사자(103)의 자산들은 블록체인(150) 전반에 걸친 다양한 트랜잭션들(152)의 UTXO들에 걸쳐 흩어져 있다. 블록체인(150)의 어떤 위치에도 주어진 당사자(103)의 총 잔액을 정의하는 숫자는 전혀 없다. 클라이언트 애플리케이션(105)에서 지갑 기능의 역할은, 개개의 당사자에게 잠겨 있으며 다른 전방 트랜잭션에서 아직 지출되지 않은 모든 다양한 UTXO들의 값들을 함께 대조하는 것이다. 비트코인 노드들(104) 중 임의의 것에 저장된 블록체인(150)의 사본을 질의함으로써 이것이 수행될 수 있다.
스크립트 코드는 종종 도식적으로(즉, 정확한 언어를 사용하지 않음) 표현된다는 것에 주의한다. 예컨대, 특정 기능을 표현하기 위해 작업 코드(opcode)들이 사용될 수 있다. “OP_..."는 스크립트 언어의 특정 작업코드(opcode)를 지칭한다. 예로서, OP_RETURN은 잠금 스크립트의 선두에서 OP_FALSE가 앞에 있을 때 트랜잭션 내에 데이터를 저장하고 그리하여 데이터를 블록체인(150)에 변경 불가능하게 레코딩할 수 있는 트랜잭션의 지출 불가능한 출력을 생성하는 스크립트 언어의 작업코드이다. 예컨대, 데이터는 블록체인에 저장하고자 하는 문서를 포함할 수 있다.
통상적으로, 트랜잭션의 입력은 공개 키 PA에 대응하는 디지털 서명을 포함한다. 실시예들에서, 이는 타원 곡선 secp256k1을 사용하는 ECDSA에 기초한다. 디지털 서명은 특정 데이터 조각에 서명한다. 일부 실시예들에서, 주어진 트랜잭션에 대해, 서명은 트랜잭션 입력의 일부, 및 트랜잭션 출력들의 전부 또는 일부에 서명할 것이다. 서명되는 출력들의 특정 부분들은 SIGHASH 플래그에 의존한다. SIGHASH 플래그는 일반적으로 어느 출력들이 서명되는지를 선택하기 위해 서명의 끝에 포함된 4-바이트 코드이다(이에 따라, 서명 시에 고정됨).
잠금 스크립트는 때로는, 그것이 통상적으로 개개의 트랜잭션이 잠겨 있는 당사자의 공개 키를 포함한다는 사실을 지칭하는 "scriptPubKey"라 칭해진다. 잠금해제 스크립트는 때로는 그것이 통상적으로 대응하는 서명을 제공한다는 사실을 지칭하는 "scriptSig"라 칭해진다. 그러나, 보다 일반적으로, UTXO가 리딤되기 위한 조건이 서명을 인증하는 것을 포함하는 것이 블록체인(150)의 모든 애플리케이션들에서 필수적인 것은 아니다. 보다 일반적으로 스크립팅 언어는 임의의 하나 이상의 조건들을 정의하는 데 사용될 수 있다. 따라서 보다 일반적인 용어들 "잠금 스크립트" 및 "잠금해제 스크립트"가 선호될 수 있다.
4.3. 사이드 채널
도 1에 도시된 바와 같이, 앨리스 및 밥의 컴퓨터 장비(102a, 102b) 각각 상의 클라이언트 애플리케이션은 각각 부가적인 통신 기능성을 포함할 수 있다. 즉, 부가적인 기능성은 (어느 한 당사자 또는 제3자의 주도로) 앨리스(103a)가 밥(103b)과 별개의 사이드 채널(107)을 설정하는 것을 가능하게 한다. 사이드 채널(107)은 블록체인 네트워크와 별개로 데이터 교환을 가능하게 한다. 이러한 통신을 때로는 "오프-체인(off-chain)" 통신으로서 지칭된다. 예컨대, 이는 당사자들 중 하나가 네트워크(106)로 브로드캐스팅하기로 선택할 때까지, (아직) 트랜잭션이 블록체인 네트워크(106) 상에 등록되거나 체인(150)으로 진행됨 없이 앨리스와 밥 사이에서 트랜잭션(152)을 교환하는 데 사용될 수 있다. 이러한 방식으로 트랜잭션을 공유하는 것은 때로는 "트랜잭션 템플릿" 공유하는 것으로서 지칭된다. 트랜잭션 템플릿은 완전한 트랜잭션을 형성하기 위해 요구되는 하나 이상의 입력들 및/또는 출력들이 없을 수 있다. 대안적으로 또는 부가적으로, 사이드 채널(107)은 키들, 협상된 금액들 또는 조건들, 데이터 콘텐츠 등과 같은 임의의 다른 트랜잭션 관련 데이터를 교환하는 데 사용될 수 있다.
사이드 채널(107)은 블록체인 네트워크(106)와 동일한 패킷 교환 네트워크(101)를 통해 설정될 수 있다. 대안적으로 또는 부가적으로, 사이드 채널(301)은 상이한 네트워크 이를테면, 모바일 셀룰러 네트워크, 또는 로컬 영역 네트워크 이를테면, 로컬 무선 네트워크, 또는 심지어, 앨리스 및 밥의 디바이스들(102a, 102b) 사이의 직접 유선 또는 무선 링크를 통해 설정될 수 있다. 일반적으로, 본 명세서의 임의의 위치에서 지칭되는 바와 같은 사이드 채널(107)은 "오프-체인", 즉 블록체인 네트워크(106)와 별개로 데이터를 교환하기 위한 하나 이상의 네트워킹 기술들 또는 통신 매체들을 통한 임의의 하나 이상의 링크들을 포함할 수 있다. 하나 초과의 링크가 사용되는 경우, 오프-체인 링크들의 번들(bundle) 또는 모음은 전체적으로 사이드 채널(107)로서 지칭될 수 있다. 따라서 앨리스 및 밥이 사이드 채널(107)을 통해 특정 정보 조각들 또는 데이터 등을 교환한다고 하면, 이는 이러한 모든 데이터 조각들이 정확히 동일한 링크 또는 심지어 동일한 유형의 네트워크를 통해 전송되어야 한다는 것을 반드시 의미하는 것은 아니란 것에 주의한다.
사이드 채널(107)은 앨리스 및 밥과 같은 당사자들 사이의 안전한 개인 오프 체인 통신을 가능하게 하기 위해 알려진 보안 통신 기술들을 채용하는 보안 채널을 포함할 수 있다. 예컨대, 보안 채널은 보안 채널을 통해 통신하는 당사자들 간에 공유되는 공유 비밀에 기초할 수 있다. 이러한 채널은 예컨대, 검증 당사자(103V)와 타겟 당사자(103T) 사이에서 통신하기 위해 이를테면, 검증 당사자(103V)가 타겟 당사자에 의해 홀딩되는 PUF(302/500)에 챌린지를 제출하고 대응하는 응답을 다시 수신하는 것을 가능하게 하기 위해 사용될 수 있다.
5. 블록체인 기반 PUF 아이덴티티 증명
이전 섹션들에서 언급된 바와 같이, 응답의 레코드로서 역할을 하는 응답 데이터는 신뢰할 수 있는 제3자 시스템(602)을 사용하기 보다는, 공개 블록체인 상에 저장될 수 있다. 응답 데이터는 설정 시에 결정된 데이터이고, 타겟 당사자(103T)("앨리스")에 의한 타겟의 아이덴티티의 어서션(assertion)을 테스트하기 위해 검증 당사자(103V)("밥")에 의해 나중에 사용될 수 있다. 재차, 앨리스 및 밥은 임의적 레이블들일 뿐이며 여기서 앨리스 및 밥은 섹션 4(여기서 밥은 앨리스의 트랜잭션 출력을 지출함)에 주어진 블록체인 시스템의 일반적인 개요에서와 동일한 역할을 맡을 필요는 없다는 것에 주의한다.
이전에 논의된 바와 같이, 주어진 CR 쌍 {Ci, Ri}에 대한 응답 데이터(체인 상에 저장되든 아니면 다른 곳에 저장되든지 간에)는, 설정 페이즈(702)에서 결정되고 검증 당사자(103V)에 의한 향후 참조를 위해 저장되는 바와 같은 다음 중 임의의 것을 포함할 수 있다:
i) 챌린지 Ci 및/또는 응답 Ri의 명시적 값(평문 또는 암호화됨), 또는
ii) 개개의 응답 Ri에 대한 특정 챌린지 Ci가 도출될 수 있는 마스터 챌린지 Cm에 링크된 응답 Ri의 명시적 값, 또는
iii) 챌린지 Ci의 명시적 값과 함께 응답 Ri의 증명(예컨대, 해시 또는 이중 해시), 또는
iv) 개개의 응답 Ri에 대한 특정 챌린지가 도출될 수 있는 마스터 챌린지 Cm에 링크된 응답 Ri의 증명(예컨대, 해시 또는 이중 해시), 또는
v) 응답 Ri로부터 도출된 공개-개인 키 쌍의 공개 키.
도 9에 도시된 바와 같이, 어떤 형태를 취하든, 설정 페이즈(702)에서, 이러한 응답 데이터(901)는 블록체인(150) 상에 레코딩된 트랜잭션(152S)의 출력(203)에 저장될 수 있다. 이는 이하, 저장 트랜잭션으로서 지칭될 수 있다. 이는 예컨대, 위의 섹션 4에서 논의된 기술들을 사용하여 체인 상에 레코딩될 수 있고, 해당 섹션에서 앨리스가 반드시 타겟 당사자(103T)일 필요는 없고 해당 섹션에서 밥이 반드시 검증 당사자(103V)일 필요는 없음에 다시 한 번 주의하고 ― 실제로 현재 앨리스로서 지칭되는 타겟 당사자(103T)는 체인 상에 레코딩될 저장 트랜잭션(152S)을 공식화하고 전송하는 당사자일 수 있다. 다른 예로서, 신뢰할 수 있는 제3자는 설정 시에 생성된 응답 데이터(901)를 포함함으로써 타겟 당사자(103T)가 완료하고 그 후 체인 상에 레코딩되도록 포워딩하기 위한 저장 트랜잭션의 템플릿을 공식화할 수 있다. 타겟 부분(103T)은 블록체인 네트워크(106)를 통해 전파되도록 블록체인 노드들(104) 중 하나에 저장 트랜잭션(152S)을 직접 전송할 수 있거나, 신뢰할 수 있는 제3자와 같은 다른 당사자를 통해 이를 간접적으로 전송할 수 있다. 또 다른 예로서, 타겟 당사자(103T)는 신뢰할 수 있는 제3자가 저장 트랜잭션(152)으로 공식화하고 체인 상에 레코딩되도록 전송하기 위해, 신뢰할 수 있는 제3자에게 자신의 응답 데이터(901)를 전송할 수 있다.
응답 데이터(901)는 저장 트랜잭션(152S)의 지출 불가능한 출력에 저장될 수 있다. 예컨대, 이는, 스크립트 프로토콜을 사용하는 경우, OP_RETURN, 또는 OP_FALSE 및 그에 뒤따르는 OP_RETURN을 사용하여 지출 불가능하게 만들어질 수 있다(BTC 또는 BCH와 같은 일부 블록체인 프로토콜들에서, OP_RETURN의 임의의 포함은 출력을 지출 불가능하게 만드는 반면, BSV와 같은 다른 프로토콜들에서, OP_FALSE와 OP_RETURN 둘 모두가 출력을 지출 불가능하게 만드는 데 요구됨). BTC(Bitcoin), BTC(Bitcoin Cash) 및 BSV(Bitcoin Satoshi Vision)는 앞서 설명된 블록체인 시스템의 상이한 예시적인 구현들이다.
대안적으로, 응답 데이터(901)는 저장 트랜잭션(152S)의 지출 가능한 출력에 임베딩될 수 있다. 예컨대, 이는 OP_FALSE 없이 OP_RETURN을 포함함으로써 지출 가능하게 유지될 수 있다. 다른 예로서, OP_DROP 코드 바로 앞에 데이터를 포함함으로써 지출 가능한 잠금 스크립트에 그 데이터를 임베딩할 수 있다. 이는 BTC, BCH 및 BSV에 동일하게 적용될 것이다.
실시예들에서 주어진 타겟 당사자(103T)의 다수의 상이한 CR 쌍들 {Ci, Ri}의 세트의 응답 데이터(901)가 저장될 수 있다. 이들은 저장 트랜잭션(152)의 동일한 출력(203) 또는 상이한 출력들(203)에 저장될 수 있거나, 동일한 출력에 일부 및 상이한 출력에 일부의 조합으로 저장될 수 있다. 그들은 동일한 저장 트랜잭션(152S)에 저장될 수 있거나, 상이한 CR 쌍들의 응답 데이터(901)가 상이한 저장 트랜잭션들(152S)에 저장될 수 있거나, 동일한 트랜잭션에 일부 및 상이한 트랜잭션에 일부의 조합으로 저장될 수 있다.
온-체인 저장은 반드시 계정-기반 모델로 제한되는 것은 아니란 것에 주의한다. 대안적인 전개들에서, 응답 데이터(901)는 계정-기반 모델의 하나 이상의 트랜잭션들의 하나 이상의 스마트 계약들에 저장될 수 있다.
검증 페이즈(704)에서, 검증 당사자(103V)가 타겟의 아이덴티티를 검증하고자 할 때, 그/그녀는 저장 트랜잭션(152S)으로부터 특정 CR 쌍에 대응하는 응답 데이터(901)를 획득하기 위해 블록체인(150)에 액세스한다. 실시예들에서, 이것은 검증 당사자(103V)에게 특정 챌린지 Ci에 대응하는 응답 Ri 또는 해당 응답 Ri의 증명(예컨대, 해시 또는 이중 해시)을 제공한다. 검증 당사자(103V)는 또한 타겟 당사자(103V)에 챌린지 Ci를 제출하고, 이에 응답하여, 수신된 챌린지 Ci를 PUF 모듈(603)에 입력함으로써 타겟 당사자(103T)(또는 그들의 디바이스)가 생성하는 (알려진) 응답 R'i를 다시 수신한다. 그 후 검증 당사자(103V)는 리턴된 응답 R'i를 체인 상의 저장 트랜잭션(152S)으로부터 리트리브된 버전과 비교하거나, 증명에 사용된 수신된 응답에 동일한 변환(예컨대, H(R'i) 또는 H2(R'i))을 적용하고 이를 체인 상의 저장 트랜잭션(152S)으로부터 리트리브된 증명과 비교한다. 어느 쪽이든, 비교가 매칭을 제공하는 경우, 타겟은 검증된다.
검증 당사자(103V)는 블록체인 네트워크(106)의 노드들(104) 중 하나를 통해, 또는 대안적으로 블록체인에 응답 데이터(즉, 트랜잭션)가 포함되었다는 머클 증명을 또한 제공할 수 있는 임의의 외부 당사자로부터 응답 데이터를 획득함으로써 블록체인(150)에 액세스할 수 있다.
응답 데이터(901)가 블록체인(150)과 같은 공개 매체에 저장되는 실시예들에서, 실제 응답 값 Ri 자체가 공개적으로 또는 제한 없이 공개되지 않는 것이 바람직할 수 있다. 그렇지 않으면, 임의의 악의적인 당사자는 체인 상에서 Ri를 본 다음 Ci로 챌린지한 경우 타겟 당사자(103T)인 것처럼 가장할 수 있다. 이에 따라, 대신에 체인 상에 홀딩되는 응답 데이터(901)로서 Ri의 증명(예컨대, H(Ri) 또는 H2(Ri))만을 저장하거나, 아니면 Ri의 명시적 값을 암호화된 형태로 저장하는 것이 바람직할 수 있다. 또는, 일부 경우들에서, 증명이 암호화된 형태로 체인 상에 저장될 수 있다.
잠재적으로 다수의 검증 당사자들이 있는 경우에, Ri 또는 그의 증명을 암호화된 형태로 저장하는 것은 타겟 당사자(103T) 또는 신뢰할 수 있는 제3자가, 어떤 검증 당사자들(103V)이 CR 쌍들 중 어느 것에 대응하는 저장 데이터(901)를 획득할 수 있는지를 제어하는 것을 가능하게 한다. 이것은 특정 응답 데이터(901) 조각에 대한 복호화 키를 주어진 검증 당사자에게만 제공하고 다른 응답 데이터(901) 조각에 대한 복호화 키를 다른 검증 당사자에게만 제공함으로써 달성될 수 있다. 복호화 키들의 분배는 타겟 당사자(103T) 또는 신뢰할 수 있는 제3자에 의해 관리될 수 있다. 각각의 검증 당사자 또는 검증 당사자들의 서브세트에는 응답 데이터(901)(예컨대, CR 쌍) 조각들의 개개의 서브세트에 액세스하기 위한 하나 이상의 복호화 키들의 자체 서브세트가 제공된다. 바람직하게는 서브세트들은 서로 배타적이다. 그러나 다른 구현들에서, 서브세트들은 오버랩할 수 있다(예컨대, 동일한 조직 내의 상이한 그룹들은 CR 쌍의 오버랩하는 서브세트들에 대한 액세스를 가질 수 있음).
이에 대한 변형으로서, 응답 데이터(901)(예컨대, CR 쌍들)가 온-체인 대신 제3자 시스템(602)에 저장되는 경우, 복호화 키들을 분배하는 대신(또는 그에 더하여), 각각의 검증 당사자가 CR 쌍들(또는 더 일반적으로 응답 데이터)의 자체 서브세트에만 액세스할 수 있도록 보장하기 위한 다른 수단이 사용될 수 있다. 예컨대, 신뢰할 수 있는 제3자 시스템(602)은 각각의 검증 당사자에 대해 패스워드로 보호된 계정을 유지할 수 있으며, 그들은 자신의 챌린지(들)에 대한 액세스를 획득하도록 로그인하기 위해 패스워드로 보호되는 계정이 요구되고 이것은 자체 CR 쌍(들)에 대한 액세스만을 그들에게 제공한다.
이러한 방식들은 보안에 유리할 수 있다. 주어진 CR 쌍의 응답 Ri가 하나의 검증 당사자(103V)에게 공개되어야 하는 경우, 동일한 CR 쌍이 다른 검증 당사자(103V)에 대해 사용되지 않는 것이 바람직할 수 있다. 그렇지 않으면, 제1 검증 당사자(103V)는 그/그녀가 타겟 당사자(103T)인 다른 검증 당사자인 것처럼 가장하기 위해 지금-알려진 응답 Ri를 사용할 수 있다. 그러나 응답 데이터(901)에 대한 액세스를 갖는 모든 잠재적 검증 당사자들(103V)이 신뢰되는 경우, 이를 방지하기 위한 조치를 취하는 것이 필수적이진 않다.
추가 변형들에서, 체인 상에 저장된 응답 데이터(901)는 대응하는 응답 Ri에 기초하여(예컨대, 이를 시드로서 사용함) 설정 시 생성된 공개-개인 키 쌍의 공개 키인 타겟 당사자(103T)의 공개 키의 형태를 취할 수 있다. 이 경우에, 검증 당사자(103V)는 저장 트랜잭션(152S)으로부터 공개 키에 액세스하고 이를 사용하여 타겟 당사자(103T)에 의해 서명된 메시지를 대응하는 개인 키로 검증한다. 일부 경우들에서, 공개 키들은 암호화된 형태로 체인 상에 저장될 수 있어서, 상이한 검증 당사자들(103V)에 의한 사용을 위해 상이한 공개 키들이 할당될 수 있다.
도 9에 또한 도시된 바와 같이, 출력(예컨대, UTXO-기반) 모델을 사용하는 실시예들에서, 이것은 CR 쌍들(또는 그로부터 도출된 키들)을 관리하기 위한 효율적인 메커니즘을 제공하기 위해 이용될 수 있다. 여기에서 관리는 예컨대, 일단 CR 쌍 또는 키가 이미 소비된(검증 시에 사용된) 경우, CR 쌍 또는 키를 업데이트하거나 폐지하는 것을 포함할 수 있다.
이를 위해, 새로운 수정자 트랜잭션(152M)이 블록체인(150) 상에 레코딩된다. 이는 폐지되거나 업데이트될 응답 데이터(901)의 조각이 저장되는 저장 트랜잭션(152S)의 출력들(203) 중 하나를 가리키는 입력(202)을 갖는다. 이것은 "지출", "리딤" 또는 "할당"으로서 지칭될 수 있다(그러나 이것이 반드시 금전적 가치의 이전을 암시하는 것은 아니란 것에 주의함). 이것은 검증 당사자(103V)에 의해 인식되는 계층-2 프로토콜의 레벨에서 가리키는 저장 트랜잭션(152S) 또는 출력(203)의 응답 데이터(901)가 더 이상 사용되지 않는다는 것을 의미하는 것으로 이해된다. 수정자 트랜잭션(152M) 자체가 자체 출력들 중 하나에 응답 데이터(901')를 포함하는 경우, 이것은 새로운 응답 데이터(901')가 이전 응답 데이터(901)(예컨대, 새로운 CR 쌍)의 대체를 표현한다는 것을 표현하는 것으로 간주된다. 검증 당사자가 검증 동작에 사용할 응답 데이터를 찾기 위해 블록체인(150)에 액세스하는 경우, 검증 당사자는 교체된 버전이 아닌 업데이트된 버전(901')을 사용할 것이다. 반면에, 수정자 트랜잭션(152U)이 교체 응답 데이터(901)를 포함하지 않는 경우, 이는 자신이 가리키는 출력(203) 또는 저장 트랜잭션(152S) 내 응답 데이터(901)를 단순히 폐지하는 것으로 간주된다.
일부 실시예들에서, 응답 데이터(901)는 저장 트랜잭션(152S)의 지출 가능한 출력에 임베딩되고, 응답 데이터(901)(예컨대, CR 쌍)가 저장된 특정 출력(203)을 지출(즉, 할당 또는 리딤)함으로써 폐지되거나 업데이트될 수 있다. 이러한 일부 실시예들에서, 상이한 CR 쌍들에 대응하는 응답 데이터(901)의 상이한 조각들은 동일한 저장 트랜잭션(203)의 개별 출력들(203)에 저장되고 개별적으로 폐지되거나 업데이트될 수 있다.
다른 실시예들에서, 응답 데이터(901)는 저장 트랜잭션(152S)의 지출 불가능한 출력에 저장되고, 저장 트랜잭션(152S)의 상이한 지출 가능한 출력을 지출(즉, 할당 또는 리딤)함으로써 폐지되거나 업데이트될 수 있다. 이러한 일부 실시예들에서, 다수의 상이한 CR 쌍들(동일하거나 상이한 지출 불가능한 출력들에 저장됨)에 대응하는 저장 데이터(901)의 다수의 조각들은 동일한 트랜잭션(152S)의 동일한 지출 가능한 출력을 지출함으로써 폐지되거나 업데이트될 수 있다.
예시적인 사용 경우로서, CR 쌍에 대응하는 응답 데이터(901)의 조각의 레코드는 일단 소비되면, 즉 검증 시에 사용되면 폐지되거나 업데이트될 수 있다. 이는 응답 데이터(901)가 Ri의 명시적 레코드이든, 증명이든, 아니면 Ri로부터 도출된 공개 키든지 간에 적용될 수 있다. 어느 쪽이든, 이는 보안 이유들로 유리할 수 있어서, 이제 세상에 릴리스된 응답 데이터는 더 이상 재차 사용 가능하지 않다.
수정자 트랜잭션(152M)은 타겟 당사자(103T)에 의해 체인 상에 레코딩되도록 공식화 및 전송될 수 있다. 그것은 전파를 위해 블록체인 노드(104)에 직접 전송되거나 중간 당사자를 통해 노드(104)에 간접적으로 전송될 수 있다. 대안적으로, 신뢰할 수 있는 제3자는 타겟 당사자가 (예컨대, 대체 응답 데이터(901')에 서명 및/또는 이를 추가함으로써) 완료하기 위한 템플릿 트랜잭션을 전송하고 그 후 체인 상에 레코딩되도록 직접 또는 간접적으로 노드(104)로 포워딩할 수 있다. 다른 가능성으로서, 신뢰할 수 있는 제3자는 수정자 트랜잭션(152M)을 공식화할 수 있고(아마도, 타겟 부분(103T)으로부터 전송된 일부 데이터 또는 템플릿에 기초하여, 이는 예컨대, 대체 응답 데이터(901')를 포함함), 그 후 신뢰할 수 있는 제3자는 체인 상에 레코딩되도록 노드(104)로 수정자 트랜잭션(152M)을 포워딩할 수 있다. 이러한 모든 옵션들은 또한 저장 트랜잭션(152S)이 블록체인(150) 상에 레코딩되는 방식에도 적용될 수 있다는 것에 주의한다.
따라서, 위에서 논의된 다양한 개념들에 따르면, i) 아이덴티티(또는 공개 키와 같은 다른 관련된 정보)를 UTXO에 링크하고 이 UTXO의 지출 상태를 아이덴티티 크리덴셜들의 유효성에 대한 프록시로서 사용하고; 및 ii) 설정, 폐지, 업데이트 및 검증과 같은 효율적인 아이덴티티-관리 동작들을 수행하기 위해 트랜잭션들의 세트를 설정하기 위한 시스템이 제공된다. 모든 당사자들이 항상 서로 통신할 필요가 있기보단, 모든 당사자들이 블록체인을 참고하여 CRP들이 소비되거나 아이덴티티들이 폐지되는 때를 확인할 수 있으므로, 통신들의 수가 감소된다는 점에서 프로세스가 보다 효율적이다.
이러한 기술들은 예컨대, 검증에 사용되는 CRP 데이터를 처리하기 위해 제3자 KYC(know your customer) 제공자에 대한 의존도를 최소화함으로써 이전에 제시된 바와 같이 아이덴티티를 PUF 디바이스에 링크하기 위한 프레임워크를 확장하는 데 사용될 수 있다. 이 목표는 KYC 제공자의 역할 또는 기능들 중 상당한 일부를 공개 블록체인으로 부분적으로 대체함으로써 달성될 수 있고, 이를 통해 사용자는 임의의 제3자와 독립적으로, ePUF 디바이스와 관련된 그 자신의 아이덴티티 크리덴셜들을 인스턴스화할 수 있다.
아이덴티티 시스템에서 신뢰할 수 있는 제3자의 역할이 반드시 완전히 회피되는 것은 아니라, 어느 쪽이든, 아이덴티티 관리의 프로세스가 개선되어서, 프로세스에 대한 신뢰할 수 있는 제3자의 참여 및 이들에게 부과되는 관련 부담이 적어도 감소될 수 있다.
5.1. UTXO 세트에 대한 PUF 아이덴티티의 링크
이전 섹션들에서 논의된 것들과 같은 아이덴티티 시스템들 상에서 블록체인 사용이 개선될 수 있게 하는 제1 양상은 공개 블록체인의 미지출 트랜잭션 출력 세트(UTXO 세트)를 사용하여 PUF 아이덴티티와 관련된 CRP들을 관리하는 것이다.
이 섹션에서, CRP들을 UTXO 세트의 멤버들에 매핑하고 각각의 특정 CRP가 아이덴티티 검증 프로세스에서 소비되었는지에 관한 표시로서 '지출' 또는 '미지출' 상태로서 그의 상태를 사용하기 위한 2개의 별개의 예시적인 메커니즘들이 개시된다. 제1 메커니즘은 지출 가능한 UTXO들에 CRP 데이터를 임베딩하는 것을 수반하며, 제2 메커니즘은 CRP 데이터를 지출 가능한 UTXO들에 페어링하는 것을 수반한다. 어느 경우든, CRP들과 관련된 부가적인 데이터 또는 해당 아이덴티티가 또한 선택적으로 시스템에 포함될 수 있다.
5.1.1. 지출 가능한 UTXO들에의 임베딩: 제1 메커니즘은 CRP들을 지출 가능한 UTXO들에 바인딩하는 것이며, 이 지출 가능한 UTXO들은 조건들은 향후 입력들에 의해 충족될 수 있고 이에 따라 향후 지출 트랜잭션들에 의해 소비될 수 있는 스크립트들을 포함하는 트랜잭션 출력이다.
이러한 임베딩을 구현하기 위한 다수의 상이한 옵션들이 있지만, 우리의 목적을 위해, 이는 일반적으로 적어도 다음 잠금 스크립트로 구성될 것이다:
[Checksig P] OP_RETURN <Rep(C,R)>
여기서 [Checksig P]는 표준 P2PKH(pay-to-public-key-hash) 잠금 스크립트이고, Rep(C,R)은 특정 챌린지-응답 쌍(C,R)의 표현이다.
이 잠금 스크립트는 지출 트랜잭션에 대해 유효한 서명 Sig P를 제공함으로써 간단하게 잠금해제될 수 있으며, 여기서 서명은 공개 키 P에 대해 유효한 것으로 간주된다. 작업 코드 OP_RETURN을 뒤따르는 임의의 데이터는 지출 트랜잭션을 유효성 검증할 때 고려되지 않을 것이고 이에 따라, 이 데이터는 블록체인 유효성 검증기(blockchain validator)들과 관련하여 임의적이고 포맷이 지정되지 않은 것으로 취급될 수 있다는 것이 주의되어야 한다.
위 스크립트에서 OP_RETURN 코드를 뒤따르는 데이터는 챌린지-응답 쌍(C,R)의 표현 Rep(C,R)이다. 이 표현은 해당 사용 경우에 의존하여, 다양한 방식들로 이루어질 수 있다. 그러나 합리적인 예는 PUF를 소유한 증명자 앨리스에게만 알려진 키 k를 사용하여 CRP를 암호화하는 것일 것이다. 이 경우에, 우리는 다음 표현들 중 임의의 것을 가질 수 있다:
Rep() Encrypt,
Rep() Encrypt,
Rep() Encrypt.
이러한 표현들은 앨리스가 나중에 그녀의 UTXO에 포함된 챌린지, 응답 또는 CRP를 각각 리트리브하거나 증명하는 것을 허용할 것이다.
부가적인 스크립트 부담들: 향후 출력을 지출하는 입력 스크립트 상에 부가적인 조건들을 포함하도록 이전에 보여진 기본 잠금 스크립트를 확장하는 것이 가능하다. 이러한 추가 조건의 합리적인 예는 다음 스크립트일 것이다:
[Checksig ][Hash Puzzle ] OP_RETURN <Rep()>
여기서 [Hash Puzzle ]= OP_HASH160 <> OP_EQUAL이다. 다른 해시 함수 작업 코드들이 사용할 수 있다는 것에 주의한다. 이 수정된 스크립트는 이제 지출자가 공개 키 P에 대한 유효한 서명을 제공하는 것 외에도, 챌린지 R의 해시를 드러내도록 요구한다. 여기서의 아이디어는, 이것이 일부 시나리오들에서, 지출자가 문제 R의 챌린지와 결국 관련되는 정보 H(R)를 알고 있다는 지식 증명으로 사용될 수 있다는 것이다.
트랜잭션 모델들: 사용될 트랜잭션 잠금 스크립트들의 정확한 구조가 결정되면, CRP들을 저장, 증명 및 관리하는 방식으로서 이러한 스크립트들을 포함하는 트랜잭션들을 구조화하는 방법에 관한 선택이 이루어질 수 있다.
CRP들 및 연관된 잠금 스크립트들을 일대일 방식으로 UTXO들에 매핑하는 것이 본 명세서에 개시된다. 즉, 이러한 스크립트를 포함하는 모든 각각의 UTXO는 특정 PUF 디바이스와 관련된 정확히 하나의 CRP에 대응할 것이다.
그 후, 이러한 UTXO들을 트랜잭션들로 구성하는 방법에 대한 몇 가지 옵션들이 있다. 가장 가능성이 높은 가능한 옵션은 다음과 같다:
1. 트랜잭션당 하나의 CRP.
2. 트랜잭션당 하나의 CRP 세트.
3. 트랜잭션당 하나의 PUF.
제1 옵션은 이를테면, 유언(a will)을 업데이트하기 위해 매우 드물게 사용되는 PUF들의 경우와 같은 일부 경우들에서 적용 가능할 수 있으며, 다수의 CRP들이 서로 명확하게 링크되지 않는다는 이점을 갖는다. 이것은 하나의 CRP의 소비 및 드러냄(reveal)이 임의의 다른 것들과 독립적으로 드러날 수 있으므로 극도의 프라이버시가 요구되는 상황들에서 또한 유용할 수 있다.
아래 표 1의 트랜잭션은 제1 옵션의 예?諛탔? 구현이다. 트랜잭션은 단일 입력 및 출력만을 포함하고, 이에 따라 각각의 CRP는 상이한 트랜잭션에 포함될 것임을 알 수 있다. 그의 출력이 지출될 때, 감사 목적들을 위해서가 아니라, 아이덴티티 시스템에 대한 이 트랜잭션의 관련성이 사실상 종료된다.
표 1: 단일 트랜잭션에서 UTXO에 매핑된 단일 CRP.
다수의 CRP들이 단일 트랜잭션에서 개개의 UTXO에 각각 매핑되게 하는 제2 옵션은, CRP 소비의 예상된 빈도가 상당히 더 높은 은행 카드들과 같은 사용 경우에 대해 더 바람직할 수 있다. 아래 표 2의 트랜잭션은 이것이 달성될 수 있는 방법을 보여준다.
앨리스에 의해 생성되었을 가능성이 높은 입력 서명은 출력들의 전체 세트에 대해 서명하도록 만들어질 수 있다는 것에 주의한다. 이는 하나의 공개 키 PA로부터 다수의 UTXO들 및 이에 따라, 다수의 CRP들로의 일대다 링키지를 제공하는 동시에, 별개의 CRP들 자체에 대한 UTXO들의 일대일 매핑을 유지한다. 또한, 각각의 출력/CRP는 재사용을 회피하기 위해 그 자신의 연관된 공개 키(모두가 앨리스에 의해 소유됨)를 갖는다고 가정된다.
표 2: 단일 트랜잭션의 개개의 UTXO들에 매핑된 CRP들의 세트
위에 표시된 옵션은 또한 시간이 지남에 따라 CRP 세트들을 업데이트하는 실시예들과 잘 통합될 수 있으며, 여기서 업데이트된 세트가 생성될 때마다, 해당 세트에 대해 새로운 트랜잭션이 발행될 수 있다. 게다가, 병렬 독립적(즉, 온-체인으로 관련되지 않은) 트랜잭션들을 통해 동일한 PUF에 대해 동시에 다수의 상이한 CRP 세트들이 생성 및 발행될 수도 있다. 이것은 다수의 상이한 신뢰할 수 있는 제3자들(예컨대, 상이한 은행들)과 아이덴티티를 설정하는 데 유용할 수 있어서, 아이덴티티들 둘 모두는 독립적으로 설정되지만, 여전히 동일한 PUF에 의해 앵커링된다(anchored).
단일 트랜잭션이 단일 PUF를 표현하는 데 사용되는 제3 옵션은 단순히 업데이트들이 가능하지 않은 옵션 2의 보다 제한적인 버전이다. 이것은 PUF-포함 디바이스에 특정 '수명'이 부여된 경우에 대해 적용 가능할 수 있으며, 여기서 이는 사용자에게 새로운 디바이스로 발급받기 전에 미리 결정된 수의 인증들에 대해서만 사용될 수 있다.
5.1.2. 지출 가능한 UTXO들과의 페어링
지출 가능한 UTXO들 내에 CRP들을 임베딩하는 것에 대한 대안은 단순히 이러한 출력들과 CRP들을 페어링하는 것이다. 이 경우에, 디지털 인증서들에 대한 기존 작업과의 차이는 앨리스가 임의의 제3자와 독립적으로 아이덴티티를 증명하기를 원할 수 있을 때, 트랜잭션이 앨리스에 의해 구성되고 서명될 수 있다는 것이다.
표 3: CRP들에 매핑된 지출 가능한 UTXO들을 포함하는 트랜잭션.
위의 다이어그램에서 n개의 CRP들과 관련된 2n개의 출력들을 포함하는 예시적인 트랜잭션을 볼 수 있으며, 여기서 각각의 지출 가능한 출력은 CRP들 중 하나에 매핑될 수 있으며 CRP 표현 자체는 대응하는 지출 불가능한 출력(예컨대, OP_FALSE OP_RETURN)에 포함되었다. 또한, CRP들을 트랜잭션들 및 UTXO들로 구성하는 3개의 가능한 변형들이 여기에 유사하게 적용된다는 것이 주의되어야 한다.
5.1.3. 논의
CRP-관리의 이익들: CRP들을 UTXO들에 매핑하는 개념은 이전 섹션들로부터의 아이덴티티 프로토콜들의 사용자들에 대한 CRP 관리 및 처리를 상당히 개선할 수 있다. 이점은 블록체인 네트워크(106) 및 그로부터 신뢰할 수 있는 리트리벌을 용이하게 할 수 있는 서비스 제공자에 대한 CRP의 저장 및 룩업이 부분적으로 오프로딩될 수 있다는 것이다.
특정 PUF의 모든 '라이브' CRP들을 UTXO들에 매핑함으로써, 아이덴티티 시스템에서 주어진 PUF에 대해 현재 사용 가능한 CRP들에 관한 정확한 정보를 위해 UTXO 세트의 상태를 질의함으로써 CRP 업데이트 프로세스를 개선하는 것이 가능하다.
우리가 설명한 블록체인 및 UTXO-CRP 매핑 규약들을 활용하는 간단한 프로세스의 예는 다음과 같다:
1. 앨리스는 PUF 디바이스를 획득하고 로서 CRP들의 세트를 열거한다.
2. 앨리스는 표 2에 도시된 바와 같이 트랜잭션 를 생성하고 블록체인 네트워크에 브로드캐스팅한다.
3. 앨리스는 제3자에게 자신의 아이덴티티를 인증하도록 시간이 지남에 따라 다수의 CRP들을 소비한다.
4. 앨리스는 이제, 다음 주 동안 그녀의 예상되는 활동들을 커버하기에 충분한 CRP들을 갖는지를 체크하기를 원한다.
1. 앨리스는 의 어떤 UTXO들이 현재 미지출인지를 묻도록 블록체인 노드(104) 또는 SPV-유사 서비스 제공자에게 질의한다.
2. 블록체인 노드 또는 서비스 제공자는 아직 미지출인 트랜잭션 의 출력들의 수로 응답한다.
5. 리턴된 수가 충분하지 않은 경우, 앨리스는 신뢰할 수 있는 제3자와 아이덴티티 업데이트 프로세스를 생성하거나, 또는 독립적으로 설정된 아이덴티티에 대해 더 많은 CRP들을 단순히 열거할 수 있다. 그렇지 않으면, 앨리스는 어떠한 액션도 취하지 않는다.
임베딩 대 페어링: 지출 가능한 출력들 내에 CRP들을 임베딩할지 아니면 단순히 그들을 출력들과 페어링할지에 관한 선택은 앨리스에게 이러한 경우들을 구별하는 2개의 상이한 이익들 간의 선택을 제공한다.
CRP가 지출 가능한 출력들 내에 임베딩된 경우, 이것은 블록체인 네트워크(106)를 유지하는 블록체인 노드들(104)이 이러한 출력의 데이터를 쉽게 사용 가능하게 유지하도록 장려한다. 이는, 앨리스의 질의들에 대한 응답들이 더 빨라질 수 있다는 것을 의미하며, 더 중요한 것은 블록체인 노드들이 이러한 트랜잭션 출력들의 원시 데이터를 앨리스에게 다시 서빙할 수 있을 가능성이 매우 높다는 것이다.
이전에 논의된 바와 같이, CRP의 표현 Rep(C,R)이 포함되어서, 챌린지, 응답 또는 둘 모두의 원시(또는 난독화된) 데이터를 포함하게 되는 경우, 이는 앨리스가 블록체인 네트워크(106)로부터 관련 정보를 리트리브할 수 있을 것임을 의미한다. 이는 앨리스가, 로컬 저장소를 교체하고 블록체인(150)으로 더 경량 시스템을 동작시키도록 허용하는데, 그 이유는 지출 가능한 출력들에의 데이터의 임베딩은 그녀의 데이터가 아무튼, 높은 가용성을 가질 가능성을 증가시키기 때문이다.
대조적으로, CRP들이 지출 가능한 출력들과만 페어링되는 경우, 앨리스는 자신에 대해 얼마나 많은 CRP들이 이용 가능한지만을 결정할 수 있을 수 있지만, 반드시 비트코인 노드들로부터 표현 데이터 자체를 리트리브할 필요는 없다. 이는 앨리스가 자신의 CRP 세트를 로컬로 유지하지 않는 경우, 블록체인 노드 네트워크(106) 외부의 에이전트를 참고해야 함을 의미할 수 있다.
이중-해시들의 사용: 위의 예시적인 구현들에서, 이중 해시 H2(Data)는 일부 데이터의 온-체인 표현으로서 사용될 수 있음을 보여준다. 이러한 방식으로 이중-해시를 사용하는 이유는, 이것이 단일-해시가 온-체인에서도 드러내는 것을 허용하여, 원칙적으로 당사자가 결국 Data에 연결되는 H(Data)를 알고 있다는 지식 증명처럼 작용하기 때문이다.
이는 예컨대, 앨리스가 H(R)을 제공하는 제3자와 R의 실제 값을 공유한다는 점은 감안하면, 제3자에 의해 충족될 수 있는 지출 부담(spending encumbrance)으로서 앨리스에 의해 H2(R)가 온-체인으로 레코딩되는 PUF-아이덴티티 상황에서 유용할 수 있다.
다중-당사자 서명: 이 섹션에 자세히 설명된 트랜잭션들은 PUF 아이덴티티에 대한 앨리스의 증명을 보조하기 위해 다수의 상이한 당사자들로부터 더 많은 서명을 포함할 수 있다는 것이 또한 타당하다. 예컨대, 앨리스 아이덴티티에서 검증자의 신뢰를 향상시키기 위한 방법으로서 앨리스 및 제3자 아이덴티티 제공자 둘 모두가 CRP 트랜잭션들의 입력(들)에 서명하는 것이 바람직할 수 있다. 이는 상대-서명자(counter-signer)가 블록체인 트랜잭션들에 서명하는 데 사용되는 앨리스의 공개 키(들)를 증명할 수 있는 인증 기관인 경우 특히 적절하다. 다수의 서명들(예컨대, '다중-서명')만에 대한 대안으로서, 예컨대, 임계 서명들 또는 키-분할 기술들(예컨대, 샤미르 비밀 공유(Shamir Secret Sharing))을 통해 다수의 당사자들이 서명 프로세스에 포함될 수 있다.
5.2. 트랜잭션들을 이용한 효율적인 아이덴티티-관리
블록체인이 이전에 제시된 것들과 같은 PUF-기반 아이덴티티 시스템들과 함께 사용될 수 있는 부가적인 방식은 효율적인 수단으로서 PUF 디바이스에 의해 보호되는 아이덴티티 키 또는 토큰을 폐지하는 것이다.
디지털 인증서 관리에 대해 행해진 이전 작업에서, 인증서들을 온-체인으로 발행 및 폐지하는 것이 알려져 있으며, 대응하는 인증서 검증 프로세스가 이에 동반된다. 앨리스가 자신의 PUF-기반 아이덴티티를 온-체인으로 증명할 때 기꺼이 인증 기관과 협력하는 시나리오를 고려한다. 앨리스가 자신의 아이덴티티에 대한 인증서를 온-체인으로 등록하는 프로세스는 다음과 같다:
1. CA(인증 기관)는 앨리스의 아이덴티티를 검증한다.
2. CA는 인증서 트랜잭션을 생성한다. 이 트랜잭션에는 다음의 입력들 및 출력들을 갖는다:
a. 입력: 공개 키 및 CA의 서명을 포함하는 잠금해제 스크립트를 갖는 CA의 UTXO.
b. 출력 1: P2PKH 잠금 스크립트.
c. 출력 2: 앨리스의 공개 키를 포함하는 OP_RETURN 출력.
3. 트랜잭션이 브로드캐스팅되고, 일단 채굴되면, CA는 앨리스에게 트랜잭션 ID 를 제공한다.
이 프로세스는 앨리스 및 인증 기관이 CA에 의해 서명된 트랜잭션을 생성하기 위해 협력하는 것으로 끝나며, 이는 앨리스의 공개 키에 대한 인증서를 포함하는 하나의 지출 불가능한 출력, 및 CA가 인증서를 폐지하는 데 사용할 수 있는 인증서와 페어링된 지출 가능한 출력을 포함한다.
본 명세서에 개시된 실시예들은, 앞서 설명된 방법들 중 하나와 같은, PUF-기반 아이덴티티를 설정하는 방법 및 위의 디지털 인증서들에 대해 약술된 방법의 하이브리드를 사용한다. 여기에서 PUF 아이덴티티 시스템에 추가된 요소는, UTXO를 지출함으로써, 일반적인 신뢰할 수 있는 제3자(CA와 유사)가 CRP 또는 관련된 공개 키를 '폐지'할 수 있는 것이다.
신뢰할 수 있는 제3자가 앨리스의 공개 키에 대한 인증서를 폐지하는 경우는 앞서 논의된 암호화 아이덴티티 설정과 관련된다.
체인 상에 저장되거나 증명된 CR-쌍들(CRP들)의 경우, 본 명세서에 개시된 실시예들은 인증 프로세스에서 일단 CRP들이 사용되면 신뢰할 수 있는 제3자가 CRP들을 폐지하도록 허용하는 체계를 제공한다. 예시적인 방법은 다음과 같다:
1. 앨리스 및 신뢰할 수 있는 제3자는 (예컨대, 앞서 설명된 바와 같은) 아이덴티티 설정 프로토콜을 실행한다.
2. 앨리스 및 신뢰할 수 있는 제3자는 이제 블록체인을 사용하여 1에서 생성된 CRP들 또는 이제 1단계 후에 획득 가능한 CRP들을 관리하고자 한다:
a. 앨리스는 CRP들을 트랜잭션 출력들에 매핑하는 CRP 매핑 트랜잭션 TxID(CRP-Set)을 생성한다. 이는 아래 표 4에서 보여진다.
b. 앨리스 및 신뢰할 수 있는 제3자 둘 모두는 TxID(CRP-Set)에 서명한다.
3. CRP 매핑 트랜잭션 TxID(CRP-Set)은 브로드캐스팅되고 블록체인 블록에 공개된다.
표 4: 신뢰할 수 있는 제3자에 의한 CRP 폐지/소비를 허용하는 CRP 매핑 트랜잭션.
이 프로세스에서 생성된 매핑 트랜잭션은 위의 표 4에서 보여진다. 이는 앞서 표 2에서 보여진 CRP 매핑 트랜잭션과 매우 유사하지만, 신뢰할 수 있는 제3자 및 앨리스 둘 모두가 입력에 서명하고 CRP들에 매핑된 UTXO들 각각은 향후 트랜잭션에서 지출함으로써 신뢰할 수 있는 제3자에 의해 폐지될 수 있다는 차이가 있다.
이는 직접적인 통신 없이 CRP들의 폐지가 처리되도록 허용하고, TTP가 사용자를 대신하여 폐지를 수행할 수 있으며, 이는 시스템에서 앨리스의 부담을 추가로 감소시키고 그녀의 아이덴티티 관리가 훨씬 더 경량이 될 수 있기 때문에 유리하다.
6. 이벤트 로그
도 10은 임베딩된 PUF 모듈(603)을 갖는 디바이스(1000)의 예를 도시한다. 실시예에서, 이 PUF 모듈(603)은 PUF(302), 변환 함수(502) 및 인터페이스 로직(404')을 포함하는, 이전에 설명된 ePUF(500)를 포함할 수 있다. 대안적으로, 이는 단지 PUF(302) 및 인터페이스 로직(404')을 포함할 수 있다(그러나 변환 함수(502)는 아님). 디바이스(1000)는 하나 이상의 외부 계층 구성요소(1002)를 더 포함한다. 이들은 하나 이상의 하드웨어 및/또는 소프트웨어 구성요소를 포함할 수 있다. 외부 계층 구성요소(1002)는, 예컨대, 디바이스(1000)와 외부 소스 사이에서 통신하기 위한 외부 인터페이스를 포함할 수 있다. 외부 인터페이스는, 예컨대, 디바이스에 유선 연결을 형성하기 위한 포트, 또는 무선 연결을 형성하기 위한 무선 트랜시버를 포함할 수 있다. 게다가, 또는 대안적으로, 외부 계층 구성요소(1002)는, 예컨대, 디바이스의 애플리케이션 목적을 구현하기 위해 디바이스(1000)의 프로세서 상에서 실행되는 애플리케이션을 포함할 수 있다. 외부 계층 구성요소(1002)는 또한 고정 기능 하드웨어에서 구현된 하나 이상의 구성요소를 포함할 수 있다.
예로서, 디바이스(1000)는 때때로 블랙박스 레코더로 또한 지칭되는 EDR(event data recorder)의 형태를 취할 수 있다. 이것은, 예컨대, 자동차 또는 비행기와 같은 차량에서 사용하도록 설계된 EDR일 수 있다. 이 경우, 외부 계층 구성요소(1002)는 디바이스(1000)의 프로세서 상에서 실행되는 EDR 애플리케이션을 포함할 수 있다. 그러나, 이는 단지 하나의 예이고, 다른 실시예에서, 디바이스(1000)는 대신에, 아이덴티티를 증명하기 위한 범용 컴퓨터 디바이스, 또는 전용 PUF 디바이스와 같은 다른 형태를 취할 수 있다는 것이 인식될 것이다.
PUF 모듈(603)은 디바이스(1000)의 하우징(1001) 내에(즉, 내부에) 임베딩되고, 즉 하우징(1001)에 의해 완전히 캡슐화된다. PUF 모듈(603)은, 디바이스(1000)를 물리적으로 분해하지 않고, 인터페이스 로직(404')에 대한 입력을 통하는 것 이외에, PUF 모듈(603)의 거동에 영향을 주는 어떠한 액세스도 제공되지 않도록 물리적으로 구성된다. 일부 실시예에서, 하우징(1001)은, 적절한 키 또는 조합 없이 PUF 모듈(603)에 대한 액세스를 방지하는 물리적 잠금을 포함할 수 있다. 대안적으로, 하우징은 영구적으로 밀봉될 수 있다.
PUF 모듈(603)이 임베딩되는 하우징(1001)은 또한 PUF 모듈(603)과 동일한 하우징(1001) 내의 외부 계층 구성요소(1002) 중 하나 이상을 둘러쌀 수 있다. 외부 소스에 유선으로 연결하기 위한 포트와 같은 외부 인터페이스의 경우, 인터페이스는 하우징(1001)과 외부 사이의 물리적 인터페이스에 위치될 수 있다. 디바이스의 프로세서 상에서 실행되는 애플리케이션의 경우, 해당 프로세서는 하우징(1001)에 의해 캡슐화될 수 있지만, 외부 소스로부터 외부 입력을 수용하는 것을 포함하는 외부 인터페이스를 통해 액세스 가능할 수 있다.
대안적으로 또는 추가적으로, PUF 모듈(603)이 캡슐화된 하우징(1001)은 외부 계층 구성요소로부터 내부적으로 PUF 모듈(603)을 분리(segregate)하는 디바이스(1000) 내의 내부 케이싱을 포함할 수 있다. 그러나, 이것은, 곧 논의되는 다른 수단이 외부 계층 구성요소(1002)로부터 물리적으로 및/또는 논리적으로 PUF 모듈(603)을 분리하기 위해 취해질 수 있기 때문에 필수적이지는 않다.
PUF 모듈(603)의 인터페이스 로직(404')은 로깅 메커니즘(1004)을 포함하며, 이는 나중에 더 상세히 논의될 것이다. 인터페이스 로직(404')은 또한 앞서 논의된 바와 같이 액세스 제어 로직(406)을 선택적으로 포함할 수 있다. 어느 쪽이든, 로깅 메커니즘(1004) 및 임의의 액세스 제어 로직(406)을 포함하는 인터페이스 로직(404')은, 외부 계층 구성요소(1002) 중 임의의 것의 임의의 악의적인 조작이 PUF 모듈(603)의 내부 작업에 영향을 주지 않도록 외부 계층 구성요소(1002)로부터 분리되어 유지된다. 인터페이스 로직(404')은 펌웨어 또는 고정-기능 하드웨어 회로(즉, 전용 회로), 또는 펌웨어 및 고정-기능 하드웨어 회로의 조합으로 구현된다. 펌웨어의 경우에, 본 목적으로, 이것은 i) 영구 메모리(판독 전용 메모리, ROM)에 기록되거나; ii) 이를테면, 디바이스를 물리적으로 해체하지 않고서 해당 메모리에 대한 어떠한 외부 인터페이스 없이 하우징(1001)에 임베딩됨으로써 외부 액세스로부터 물리적으로 보호되는 메모리에 저장되거나, 또는 iii) 콘텐츠가 제한된 프로세스를 통해서만 업데이트될 수 있는 메모리에 저장되는 소프트웨어(컴퓨터 판독 가능 코드)를 의미한다. 예컨대, 후자의 경우에, 인터페이스 로직(404')의 하드웨어는, 운영자가 패스워드, PIN, 암호 키 또는 생체인식 정보와 같은 하나 이상의 요구되는 크리덴셜을 제시할 수 있는 경우에만 펌웨어가 저장된 메모리를 업데이트하기 위한 액세스를 허용하도록 하드웨어로 구성될 수 있다.
그러한 제한이 시행되는 한, 임의의 그러한 펌웨어가 저장되는 메모리는 하나 이상의 저장 매체(예컨대, 자기 디스크 또는 테이프와 같은 자기 매체, 또는 ROM, EPROM, EEPORM, 플래시 메모리, SRAM, DRAM 등과 같은 전자 매체)를 사용하는 하나 이상의 메모리 유닛들을 포함하는 임의의 적합한 형태를 취할 수 있다. 임의의 펌웨어가 실행되는 프로세서는 하나 이상의 프로세싱 유닛(예컨대, CPU와 같은 범용 프로세서, 또는 GPU, DSP 또는 암호 프로세서와 같은 애플리케이션 특정 또는 가속기 프로세서)을 포함할 수 있다. 다른 옵션은, 펌웨어가 (FPGA 경우에서 재구성하기 위해 제한된 액세스를 갖는) PGA 또는 FPGA와 같은 구성 가능 또는 재구성 가능 회로에서 구현될 수 있다는 것이다.
변환 함수(502)가 이용되는 실시예에서(ePUF(500)의 경우에서와 같이), 이것은 또한 하드웨어 또는 펌웨어로 구현될 수 있다. PUF 인터페이스 로직(404')에 대해 위에 주어진 구현에 대한 동일한 코멘트가 또한 변환 함수(502)에 적용된다.
외부 계층 구성요소(1002)가 애플리케이션을 포함하는 경우에, 애플리케이션이 저장되는 메모리는 또한, 하나 이상의 저장 매체(예컨대, 자기 디스크 또는 테이프와 같은 자기 매체, 또는 ROM, EPROM, EEPORM, 플래시 메모리, SRAM, DRAM 등과 같은 전자 매체)를 사용하는 하나 이상의 메모리 유닛을 포함하는 임의의 적합한 형태를 취할 수 있다. 애플리케이션이 실행되는 프로세서는 또한 하나 이상의 프로세싱 유닛(예컨대, CPU와 같은 범용 프로세서, 또는 GPU, DSP 또는 암호 프로세서와 같은 애플리케이션 특정 또는 가속기 프로세서)을 포함하는 임의의 적합한 형태를 취할 수 있다. 다른 옵션은, 외부 계층(102)의 애플리케이션 기능이 전용 하드웨어 회로에서, 또는 PGA 또는 FPGA와 같은 구성 가능하거나 또는 재구성 가능 회로에서 부분적으로 또는 전체적으로 구현될 수 있다는 것이다.
실시예에서, 외부 계층(1002)의 애플리케이션은 PUF 모듈(603)의 펌웨어와는 별개의 프로세서 상에서 실행된다. 외부 계층 프로세서 상에서 실행되는 소프트웨어는, 이를테면, 인터넷으로부터 업데이트를 다운로드하거나 유선 연결을 통해 업데이트를 설치함으로써, 외부 인터페이스를 통해 업데이트될 수 있다. 그러나, 펌웨어는 업데이트 가능하지 않을 수 있거나, 일부 실시예에서, 운영자가 요구된 크리덴셜(들)을 제시할 수 있는 경우에만 업데이트 가능할 수 있다. 다른 옵션은, 펌웨어가 애플리케이션과 동일한 프로세서 상에서 실행되지만 보안 프로세서의 특권 도메인에서 실행된다는 것이다(반면에 애플리케이션은 별개의 애플리케이션 도메인에서 실행됨). 예컨대, 인터페이스 로직(404')의 펌웨어는, 예컨대, ROM에 저장된 보안 커널의 일부로서 구현될 수 있다. 이 경우, 프로세서는, 부팅될 때, 애플리케이션 공간(애플리케이션 도메인)에서 실행되는 애플리케이션에 프로세서 사이클을 결국 위임할 수 있는 커널(특권 도메인)을 실행함으로써 시작하도록 구성되지만, 프로세서는 어떠한 애플리케이션 프로세스도 커널을 중단(override)시킬 수 없고 위임된 사이클의 수 후에 실행을 커널로 리턴하는 것을 자율적으로 방지할 수 없도록 하드웨어로 구성된다. 이러한 보안(특권) 도메인을 구현하기에 적절한 보안 프로세싱 기술의 세부사항들은 그 자체로 당업자에게 알려져 있을 것이다.
어떤 수단에 의해서 구현되든지 간에, 동작 시에, 인터페이스 로직(404')은 외부 계층(1002)으로부터 입력 챌린지를 수신한다. 예컨대, 이것은 애플리케이션으로부터, 또는 외부 인터페이스를 통해, 또는 외부 인터페이스 및 애플리케이션을 통해 입력 챌린지를 수신하는 것을 포함할 수 있다. 따라서 외부 계층(1002)은 입력 챌린지를 수신하기 위한 채널의 적어도 일부를 제공한다. 입력 챌린지의 소스는 외부 계층(1002)에서 실행되는 애플리케이션, 또는 외부 소스일 수 있다. 후자의 경우, 외부 소스는 로컬이어서 입력 챌린지를 디바이스(1000)의 외부 인터페이스에 직접 입력할 수 있거나; 또는 원격이어서 네트워크를 통해 입력 챌린지를 디바이스(1000)의 외부 인터페이스에 전송할 수 있다. 입력 챌린지의 소스는 인간 사용자, 또는 외부 컴퓨터 장비와 같은 다른 디바이스 또는 시스템일 수 있다.
인터페이스 로직(404')은 PUF 모듈(603)로 하여금 PUF(302)에 의존하여 출력 응답을 생성하게 한다. PUF 모듈(603)이 ePUF(500)의 형태를 취하는 경우, 이전에 논의된 바와 같이, 입력 챌린지는 2차 챌린지(Ci)이고 출력 응답은 2차 응답(Ri)이다. 이 경우, 인터페이스 로직(404')은 2차 챌린지(Ci)를 변환 함수(502)에 입력하고, 1차 챌린지(Cw)를 PUF(302)에 입력하여, 그로 하여금 1차 응답(Rw)을 PUF(302)에 제공하게 하고, PUF(302)는 2차 응답(Ri)을 생성한다. 추가의 세부사항에 대해서는 ePUF에 대한 이전 논의를 다시 참조한다.
그러나, 대안적인 실시예에서, PUF 모듈(603)은 ePUF(500)의 형태를 취할 필요는 없다. 예컨대, PUF 모듈(603)은 PUF(302) 및 인터페이스 로직(404')만을 포함할 수 있다. 이 경우, 인터페이스 로직(404')은, 변환 함수(502) 없이, 단순히 입력 챌린지를 PUF(302)에 직접 입력하고, 입력 챌린지의 직접 함수로서, PUF(302)로부터 출력 응답을 다시 수신한다.
어느 쪽이든 간에, 인터페이스 로직(404')은, 소스와 동일한 사용자, 디바이스 또는 시스템을 포함할 수 있는 목적지, 또는 상이한 목적지, 또는 둘 모두에 출력 챌린지를 리턴하도록 배열된다. 목적지는 외부 계층(1002) 내의 애플리케이션을 포함할 수 있다. 대안적으로 또는 추가적으로, 목적지는, 출력 응답이 외부 계층(1002)의 외부 인터페이스를 통해 또는 애플리케이션 및 외부 인터페이스를 통해 전송되는 외부 목적지를 포함할 수 있다. 외부 목적지의 경우, 목적지는 로컬(응답을 직접 수신함) 또는 원격(외부 네트워크를 통해 응답을 수신함)일 수 있다. 목적지가 로컬이든 원격이든 간에, 따라서, 외부 계층(1002)은 출력 응답이 목적지에 공급되는 채널의 적어도 일부를 제공한다. 외부 목적지의 경우, 목적지는 인간 사용자 또는 외부 컴퓨터 장비와 같은 다른 디바이스 또는 시스템(도시되지 않음)을 포함할 수 있다.
디바이스(1000)에 PUF 모듈(603)을 포함시키는 것은 디바이스(1000) 또는 디바이스를 소유한 당사자의 아이덴티티의 검증, 또는 디바이스에 의해 생성된 결과의 검증을 가능하게 한다.
예컨대, 이전의 신뢰할 수 있는 설정 페이즈(702)에서, 디바이스(1000)가 특정 챌린지(C)에 대한 자신의 응답(R)을 검증 당사자(103V) 또는 신뢰할 수 있는 제3 당사자 서비스(202) 중 어느 하나에 등록한 시나리오가 고려된다(예컨대, 이전의 논의를 참조). 나중에, 조사 또는 법정 재판 절차 등 동안에, 조사 동안 고려되고 있거나 재판 절차의 일부로서 제시되는 후보 디바이스가 신뢰할 수 있는 설정 페이즈에서 이전에 등록되었던 것과 동일한 디바이스(1000)인지 여부를 증명하는 것이 요구될 수 있다. 이를 위해, 검증 당사자(103V)(예컨대, 조사자, 변호사 또는 법원 공무원)는 설정 동안 사용된 동일한 챌린지(C)를 디바이스(1000)에 입력하고, 디바이스가 생성하는 후보 결과(R')가 설정 페이즈에서 원래 등록되었던 결과(R)와 동일한지 여부를 결정할 수 있다.
다른 시나리오에서, 이전 응답은 그 자체로 설정 페이즈의 일부로서 등록될 필요는 없다. 대신, 디바이스(1000)는 일부 이벤트의 시간에 결과를 생성하도록 구성될 수 있고, 그 시간으로부터의 PUF 모듈(603)의 응답(R)이 결과에 링크되거나 매핑될 수 있다. 예컨대, 결과는 외부 계층 구성요소(들)(1002)에 의해 모니터링되고 있는 시스템 또는 외부-층 구성요소(1002) 중 하나의 상태일 수 있거나 또는 이를 나타낼 수 있다. 예컨대, 디바이스(1000)가 EDR인 예에서, 결과는 자동차, 항공기 또는 선박 등의 온보드 컴퓨터(on-board computer)와 같은, 모니터링되고 있는 시스템에 의해 생성된 신호일 수 있다. 일부 이러한 실시예들에서, 응답(R)을 생성하기 위해 입력되는 챌린지(C)는 결과를 생성한 상황에 관련된 의미 있는 데이터의 조각일 수 있다. 예컨대, 챌린지는 차량 전방의 거리 센서와 같은 차량의 온보드 센서로부터의 신호일 수 있다. 대응하는 결과는 EDR 디바이스(1000)에 의해 모니터링되고 있는 온보드 컴퓨터에 의해 적용된 브레이크를 적용하라는 명령일 수 있다. 외부 계층(1002) 내의 EDR 애플리케이션은 결과를 응답(R)에 링크하거나 매핑하는 태그를 생성하고, 결과 및 태그를 EDR 애플리케이션의 메모리 위치에 레코딩하도록 구성된다. 태그는 구현에 의존하여, 다수의 가능한 방식으로 생성될 수 있다. 예컨대, 태그는 결과에 서명하기 위해 암호 키로서 R을 사용함으로써 생성된 암호 서명일 수 있거나, 이는 R 및 결과에 기초한 HMAC(hash-based message authentication code)일 수 있다. 디지털 서명 기법, HMAC 등의 세부사항은 그 자체로 당업계에 공지되어 있다.
나중에, 조사 또는 법정 절차 동안, 레코딩 결과가 특정 EDR(1000)에 의해 실제로 생성되었는지 여부를 증명하는 것이 요구될 수 있다. 이를 위해, 후보 챌린지(C')는 PUF 모듈(603)에 입력되어 대응하는 후보 응답(R')을 생성한다. 레코딩된 태그(예컨대, 서명 또는 HMAC)가 이제 생성된 R'에 기초하여 인증되면, 이것은 레코딩된 결과가 EDR에 의해 생성되었음을 입증한다.
예컨대, 자동차 사고와 같은 일부 사건에 수반되었던 앨리스의 차로부터의 EDR의 예가 고려된다. 챌린지(C)는, 예컨대, 자동차 전방의 거리 센서로부터의 판독치(reading)일 수 있다. 결과는 C에 기초하여 생성될 수 있다. 이 예에서, 판독치가 너무 낮기 때문에(전반에 너무 가까운 개체) 온보드 컴퓨터로부터 브레이크를 적용하기로 결정할 수 있다. C는 또한 PUF 모듈(603)(예컨대, ePUF)에 입력된다. PUF 모듈은 C 및 PUF(302)에 기초하여 응답(R)을 생성한다. R은 반드시 그 자체로 의미가 있는 것은 아니다. 그러나, 결과는, 예컨대, R로 결과에 서명함으로써 서명을 생성하거나 HMAC(result, R)를 컴퓨팅함으로써 R에 매핑된다. 더 일반적으로, 챌린지, 결과, 또는 둘 모두는 모니터링되는 시스템(자동차 또는 다른 차량의 온보드 컴퓨터이든지, 또는 임의의 종류의 EDR에 의해 모니터링될 수 있는 임의의 다른 시스템이든지 간에)의 측정, 조건 또는 다른 그러한 상태에 의존할 수 있다. 예컨대, 결과가 상태의 값에 의존하지 않는 임의의 경우에, 결과는 아니지만 챌린지는 상태에 의존할 수 있다. 이것의 하나의 예는, EDR에 의해 컴퓨팅된 결과가 (예컨대, 기본 데이터-레코드 목적으로) 단지 타임스탬프 또는 인덱스인 경우일 것이고, 이것이 측정 또는 상태의 값을 알 필요가 없고, 타임스탬프가 시스템 클록 또는 증분 카운터와 같은 것으로부터 도출될 수 있다는 것을 의미한다.
실시예에서, 외부 계층(1002) 내의 EDR 애플리케이션은 적어도 서명된 결과, 및 서명 또는 HMAC를 레코딩할 것이다. 일부 이러한 실시예에서, 이는, C가 결과를 야기했던 실세계 데이터를 나타내는 경우에, C를 또한 레코딩할 수 있다. 예컨대, 결과는 온보드 컴퓨터가 브레이크를 적용했다는 것일 수 있고, C는 자동차 전방 상의 거리 센서로부터의 신호일 수 있다. 나중에 자동차 충돌 조사 또는 법정 등에서, 밥은 EDR(1000)을 자신의 손에 쥐고 있으며 현재 증거로 제시되고 있는 레코딩된 결과가 사실상 앨리스의 EDR에 의해 생성되었다는 것을 입증하기를 원한다. 이를 위해, 그는 결과를 도출했을 후보 챌린지(C')를 외부 계층(1002)을 통해 PUF 모듈(603)에 입력(예컨대, 낮은 거리 판독치를 입력)하고, 응답(R')을 관찰한다. 레코딩된 서명 또는 HMAC가 이제 생성된 R'에 기초하여 인증되면, 이것은 레코딩된 결과가 앨리스의 EDR에 의해 생성되었다는 것을 입증한다. 따라서, PUF 모듈(603)은, 그가 이벤트 시에 존재했던 것과 실제로 동일한 EDR이었고, 그가 C 또는 외부 조건이 주어지면 특정 결과를 도출했다는 것을 체크하는 것을 가능하게 한다. C가 조건에 의존하지 않고, 결과만 의존하더라도, (C,R)을 사용하여 HMAC를 인증하는 것이 여전히 가능하며, 여기서 (C가 조건으로부터 도출되었는지 또는 조건에 의존되었는지 간에) R은 태그를 생성하는데 사용되는 키, 예컨대, HMAC 키 등이다. 이것은 자동차의 EDR에만 적용될 수 있는 것이 아니라, 더 일반적으로 어떠한 종류의 시스템을 모니터링하기 위한 어떠한 유형의 EDR에도 적용될 수 있다.
보다 일반적으로, 외부 계층(1002)에 의무적으로 레코딩될 필요가 있는 어떠한 하나의 특정한 것도 없다. 외부 계층(1002)은 선택적으로, 결과, 응답, 태그, 둘 다 또는 이들 중 모두를 출력할 수 있거나 이들 중 어느 것도 출력하지 않을 수 있다. 예컨대, 블랙박스 레코더는 동작 시에 반드시 어떤 것을 방출해야 하는 것은 아니며, 이는 나중에 조사될 때까지 단지 챌린지 또는 측정치 등을 취하는 '기록 전용' 시스템과 같은 역할을 한다.
어떠한 구현이든지 간에, 챌린지가 외부 계층 구성요소(1002)(예컨대, 애플리케이션 및/또는 외부 인터페이스) 중 적어도 하나를 통해 PUF 모듈(603)에 입력될 것이고; 대응하는 응답은, 어떤 스테이지에서 그것이 출력되든지 간에, 외부 계층 구성요소(1002) 중 적어도 하나를 통해 출력될 것이라는 점에서 잠재적인 문제가 있다. 이것은, 이후의 조사/절차 동안 및 임의의 초기 설정 페이즈에서 또는 결과가 원래 생성된 시간에 모두 해당된다. 언급된 바와 같이, 외부 계층 구성요소(들)는 입력 챌린지를 수신하고 출력 응답을 출력하기 위한 비보안 채널의 적어도 일부를 형성한다. 이것은, 소스 및/또는 목적지가 디바이스(1000)의 내부 또는 외부에 있는지에 관계없이 해당된다. 따라서 이러한 채널은 중간자(MiM) 서비스 거부(DoS) 공격에 대해 개방될 수도 있고, 심지어 앨리스 자신에 대한 조사를 방해하기 위해 조사 중인 당사자(앨리스)에 의한 악의적인 거동도 있을 수 있다. 예컨대, 누군가는 EDR의 외부 인터페이스에 스크램블러를 몰래 장착할 수 있거나, 이는 EDR 애플리케이션을 간섭하는 일부 멀웨어를 다운로드했을 수 있다. 이들 중 어느 하나는 입력 챌린지가 PUF 모듈(603)에 입력되기 전에 입력 챌린지의 값을 조작할 수 있거나, 또는 PUF(603)에 의해 출력된 후에 출력 응답의 값을 조작할 수 있다. 이것은 원래 이벤트 시에(예컨대, EDR이 앨리스의 차에 있던 동안) 또는 나중에 검증 시에(조사/재판 절차 동안에) 발생할 수 있다. 입력 챌린지의 소스 또는 출력 응답의 목적지가 디바이스(1000)로부터 외부일 뿐만 아니라 원격인 경우, MiM 공격에 대한 2개의 가능한 포인트, 즉, 소스와 챌린지를 수신하는 당사자 사이, 및 해당 당사자와 디바이스(1000) 사이에 존재한다.
그러한 공격 자체를 중지시키는 것은 가능하지 않을 수 있지만, 공격이 발생했다는 것을 검출할 수 있는 것이 바람직할 것이다.
이를 해결하기 위해, 본 개시에 따르면, PUF 모듈(603)의 인터페이스 로직(404')은 로깅 메커니즘(1004)을 포함한다. 이것은, 입력 챌린지(C)가 PUF 모듈(603)의 인터페이스 로직(404')에 입력되고 대응하는 출력 응답(R)이 생성될 때, 로그 매체(1006)에 C 및/또는 응답(R)의 레코드를 자동으로 로깅하도록 구성된다. 즉, 인터페이스 로직(404')에 대한 입력으로서의 입력 챌린지(C) 및/또는 인터페이스 로직(404')에 의해 출력된 출력 응답(R)이 로그에 레코딩된다
C 및/또는 R의 레코드는 평문 또는 암호화된 형태로 C 및/또는 R의 명시적 값을 포함할 수 있다. 대안적으로, C 및/또는 R의 레코드는 각각 C 및/또는 R의 값을 드러내지 않는 C 및/또는 R의 변환인 C 및/또는 R인 증명, 예컨대, C 및/또는 R의 해시 또는 이중 해시를 포함할 수 있다. 증명의 경우, 이것은 후보 챌린지(C') 및/또는 응답(R')이 후보 값에 동일한 변환을 적용함으로써 증명에 대해 체크되는 것을 허용한다. 선택적으로, 로그는 또한, 결과(R)를 그 시간에 생성된 결과(예컨대, 브레이크를 적용하라는 신호)에 매핑하는 태그를 포함할 수 있다. 예컨대, 실시예에서, 로그는 태그 및 R 자체를 포함할 수 있다.
PUF 모듈(603)은 디바이스(1000) 내에 임베딩된 자립형 모듈, 예컨대, EDR(블랙-박스)로서 구현된다. 내부 작업은 ROM로부터 실행되는 하드웨어 또는 펌웨어와 같은 보다 안전한 환경에서 및/또는 보안 도메인에서 구현되는, EDR의 내부 구성요소의 나머지로부터 분리된다. 따라서, 악의적인 당사자는 PUF 모듈(603) 자체 내에서 발생하는 어떠한 것도 조작할 수 없는데, 왜냐하면 이것이 제어 로직에 의해 중재되지만, 그것이 PUF 모듈(603)이 외부 계층(1002)을 조작함으로써 야기되는 변환된 정보 또는 외부 계층(1002)에 공급되는 정보를 공급받는 것을 중지시키지 않기 때문이다. PUF 모듈(603)의 내부 로직(1004)에 의한 CR 쌍의 로그는 그러한 공격을 증명하기 위한 수단을 제공한다.
로그 매체(1006)는, 도 10에 도시된 바와 같이, 인터페이스 로직(404')에 임베딩되거나 적어도 디바이스(1000) 내에 임베딩된 내부 메모리를 포함할 수 있다. 임의의 적절한 메모리 매체, 예컨대, EPROM, EEPROM, 플래시 메모리, SRAM, DRAM과 같은 전자 매체; 또는 심지어 자기 디스크 또는 테이프 등과 같은 자기 매체가 사용될 수 있다. 이러한 실시예에서, 메모리는 로깅 메커니즘(1006) 이외의 임의의 엔티티에 의해 메모리의 콘텐츠가 변경되는 것으로부터 보호되도록 배열된다. 이것은, 예컨대, WORM(write-once, read-many) 메모리; 또는 예컨대, 임의의 변조의 증거를 남기거나, 또는 단지 그의 콘텐츠가 인가된 당사자에 의해 변경되는 것을 허용하도록 설계된 변조 방지 메모리를 사용함으로써 수행될 수 있다(예컨대, 메모리는 패스워드, PIN, 키, 또는 생체인식 정보와 같은 인식된 크리덴셜 또는 크리덴셜들을 제시할 수 있는 당사자에게 기록 액세스만을 허용하도록 하드웨어로 구성될 수 있음). 대안적으로 또는 추가적으로, 로그(1006)의 메모리는, 이를테면, 디바이스(1000)의 외부 하우징(1001) 또는 심지어 디바이스(1000) 내의 PUF 모듈(603)의 내부 케이싱과 같은 하우징 내에 물리적으로 임베딩됨으로써, 변조로부터 물리적으로 보호될 수 있다. 일부 경우에, 하우징에는 물리적인 키 또는 개방을 위한 숫자 조합(combination)을 요구하는 물리적인 잠금이 설치될 수 있다.
또 다른 대안적인 또는 추가적인 옵션에서, 로그 매체(1006)는 공개 매체를 포함할 수 있다. 이것은 블록체인과 같은 변경 불가능한 공개 매체를 포함할 수 있다. 그러나, 심지어 변경 가능한 공용 매체, 예컨대, 웹 상의 공개는 일부 보안을 제공할 것인데, 왜냐하면 로그를 변경하려는 모든 시도가 공개적으로 보이게 될 것이기 때문이다. 이러한 실시예에서, 로깅 메커니즘(1004)이 공개 로그 매체(1006)에 로깅되고 있는 C 및/또는 R의 레코드를 업로드하는 것을 가능하게 하기 위해, 인터넷 또는 모바일 셀룰러 네트워크와 같은 네트워크에 대한 보안 인터페이스가 로깅 메커니즘(1004)에 장착된다.
로그 매체(1006)가 디바이스(1000) 또는 심지어 인터페이스 로직(404')의 외부에 있는 실시예에서, 바람직하게는, 디바이스(1000)와 매체(1006) 사이에서 C 및/또는 R의 레코드가 조작되는 것을 방지하기 위해(또는 적어도 그러한 것이 발생한다면 검출을 가능하게 하기 위해) 매체(1006)에 자신의 레코드를 전송하기 위한 보안 채널이 인터페이스 로직(404')에 제공된다. 이것은, 임의의 공지된 암호 서명 기술에 기초하여, 로깅 메커니즘(1004)의 레코드 및 키에 기초하여 생성된 암호 서명과 함께 패킷에 로깅되고 있는 레코드를 출력하도록 로깅 메커니즘(1004)을 배열함으로써 간단히 구현될 수 있다. 블록체인 트랜잭션(152)이 로깅 데이터를 동봉하는(예컨대, 로깅된 레코드를 트랜잭션의 출력에 넣고 서명을 입력에 포함시키는) 패킷으로서 사용되고 있다면, 블록체인 네트워크(106)는 이러한 종류의 공격에 대한 추가적인 보호를 제공하고, 블록체인 트랜잭션(152)이 그 입력 서명에 의해 서명된 메시지를 변경하는 임의의 방식으로 변경되었다면, 트랜잭션은 유효하지 않고, 체인 상에 포함되지 않을 것이다. 따라서 로그 데이터가 입력 서명에 의해 서명된 한, 공개 시에 로깅 데이터가 변조되지 않았다는 것을 보장하는 데 필요한 것은, 그가 (예컨대, 머클 증명을 제공함으로써) 체인 상에 포함된다는 것을 검증하는 것이 전부이다.
일부 실시예에서, 로그 매체(1006)는 로컬의 내부 메모리 및 공개 매체 둘 모두를 포함할 수 있다. 일부 이러한 실시예에서, 로깅 메커니즘(1004)은 출력 응답을 생성할 때 로컬 메모리에 CR 쌍(또는 로깅되고 있는 임의의 레코드)을 로깅할 뿐만 아니라, 일정 시간 기간 당 한번(예컨대, 얼마나 자주 사용되는지 및 로컬 메모리 크기에 의존하여 매 시간, 매일, 매주 등), 마지막 시간 기간에 로깅된 가장 최근의 CR 쌍의 배치(batch)를 공개 매체(예컨대, 블록체인)에 주기적으로 업로드하도록 구성될 수 있다. 선택적으로, 로깅 메커니즘(1004)은 배치를 공개 매체에 업로드할 때마다 로컬로 저장된 CR 쌍을 클리어할 수 있다. 이것은 검증 당사자(103V)가 로컬 로그를 검사함으로써 가능한 악의적인 거동을 실시간으로 검출하는 것을 가능하게 한다. 이것은 공격이 발생하자마자 공격을 검출할 수 있기 위해 바람직할 수 있다. 그러나 주기적으로 로그를 공개 매체에 저장하는 것은, 로컬 로그에 있는 모든 각각의 CR 쌍을 영구히 유지하지 않게 함으로써 로컬 메모리를 또한 절약한다. 또한, 이는 로컬 메모리에 대한 공격으로부터 보호하는 데 도움이 되고, 또한, 디바이스(1000)에 대한 검증 당사자의 연결이 끊어지더라도, 로그는 여전히 공개 매체 상에서 이용 가능할 것이다.
추가의 대안적인 또는 추가적인 실시예에서, 로깅된 레코드는, PUF 모듈(603)에 의해 수행되는 각각의 챌린지-응답 동작에 후속하여 실시간으로 블록체인에 기록될 수 있다. 이것은 내부 메모리의 로컬 로깅에 대한 대안으로서 또는 그에 부가하여 이루어질 수 있다. 이는 또한 레코드의 배치를 블록체인에 주기적으로 로깅하는 것에 대한 대안으로서, 또는 그에 부가하여, 이루어질 수 있다.
어떠한 수단이 구현되든지 간에, 로그 매체(1006)의 콘텐츠는 검증 페이즈 동안, 예컨대, 조사 또는 법정 재판 절차 동안 나중에 검증 당사자(103V)에 의해 판독되도록 이용 가능하게 된다.
로그를 사용하여 검출할 수 있는 적어도 2개의 가능한 공격이 존재한다. 첫 번째는 디바이스(1000)의 외부 계층(1002) 또는 소스와 외부 계층 사이의 C의 조작이다.
이에 대해 체크하는 하나의 방법은 검증 당사자(103V)(밥)가 조사 또는 재판 절차 동안 로그의 거동을 체크하여 외부 계층(1002)에서 멀웨어를 체크하는 것이다. 후보 챌린지(C')가 새로운 로그 엔트리(C")에서 즉시 변환되면, 검증 당사자(103V)는 디바이스가 현재 감염되어 신뢰할 수 없다는 것을 알고, 따라서 그의 증거는 사용될 수 없다.
또 다른 체크는, 후보 챌린지(C')가 과거 이벤트의 로그에 로깅된 입력 챌린지(C) 중 하나와 동일하다는 것을 검증 당사자(103V)(밥)가 체크하는 것이다. 만약 그렇다면 모든 것이 정상이지만, 그렇지 않다면, 이것은: 이벤트가 발생하지 않았거나, 입력 챌린지의 소스(예컨대, 자동차 예에서 거리 센서)가 손상되었거나, 입력 챌린지가 이벤트 당시에 변조되었음 중 어느 하나를 의미할 수 있다. 맥락 정보는 처음 2개의 가능성을 제거하는 데 사용될 수 있다. 예컨대, 증인은 이벤트(예컨대, 자동차 사고)가 발생했다고 증명할 수 있고, 기술적 검사는 입력 챌린지의 소스(예컨대, 자동차 거리 센서)가 여전히 작동 중임을 입증할 수 있다.
다른 가능한 공격은 디바이스의 외부 계층(1002)에서 또는 외부 계층(1002)과 목적지 사이에서 출력 응답의 조작이다. 이를 검출하기 위해, 나중에 조사/재판 절차 동안, 검증 당사자(103V)(밥)는 해당 결과와 관련하여 레코딩된 태그(예컨대, 서명 또는 HMAC)를 인증할 뿐만 아니라, 이벤트 당시로부터 로깅된 응답(R)이 현재 생성된 후보 응답(R')과 매칭한다는 것을 체크할 것이다. 그들이 매칭하지 않는다면, 이것은 약간의 간섭이 있었고 따라서 증거는 무시되어야 한다는 것을 의미한다(이는 레코딩된 결과가 앨리스의 EDR에 의해 생성되었거나 생성되지 않았다는 것 등을 어떤 식으로든 증명하지 않는다). 일반적인 아이덴티티 검증의 경우에 유사한 체크가 수행될 수 있다.
C 및/또는 R의 레코드가 명시적인 값 또는 증명, 예컨대, 값의 해시일 수 있다는 것이 다시 유의된다. 전자의 경우, 매치를 체크하는 것은 단순히 레코딩된 값이 후보 값과 동일하다는 것을 체크하는 것을 포함한다. 그러나, 증명의 경우, 매치를 체크하는 것은 후보 값에 먼저 동일한 변환(예컨대, 해시)을 적용하는 것, 및 그런 다음 변환된 후보 값이 레코딩된 증명과 매칭한다는 것을 체크하는 것을 포함한다.
6.1 로컬 PUF 시스템
예로서, 이벤트 로그는, 대응하는 검증 시나리오와 관련된 일 유형의 중간자 공격(man-in-the-middle attack)을 방지하기 위해 로컬 설정 경우(섹션 3.2 참조)에서 특정 애플리케이션을 찾을 수 있다. 챌린지(C)를 수신하고, 가능하게는 일부 컴퓨테이션을 수행하고, 컴퓨테이션의 결과 및 응답(R)을 포함할 수 있는 응답을 제공하도록 구성된 PUF 모듈(603), 예컨대, ePUF(500)가 고려된다.
이것의 좋은 예는, PUF 모듈 출력이 HMAC(hashed message authentication code)(result, R)를 포함하는 HMAC일 것이고, 여기서 응답(R)은 대칭 HMAC 키로서 사용되고 메시지는 수행된 컴퓨테이션의 결과이다.
그러나, 이와 같은 상황에서, 그리고 최종 검증이 검증기(103V)에 PUF 모듈(603)에 대한 물리적 액세스를 제공하는 것을 수반할 경우, PUF 모듈(603)이 또한 자신의 동작의 로그 또는 레코드를 생성하는 것이 유익할 수 있다. 그 이유는, (가령, IoT 디바이스 상의) PUF 모듈(603)과 원하는 챌린지(C)를 디바이스에 제출하는 합법적인 소유자 사이의 보안되지 않은 챌린지에 대해 MiM 공격을 수행하는 공격자가, 소유자 앨리스가 이것이 일어났다는 것을 인식하지 못하고, 이를 대안적인 챌린지(C')로 대체할 수 있기 때문이고, 이는 디바이스로 하여금 R 대신에 응답(R')을 산출하게 하고 잠재적으로 이를 계산에서 사용하게 할 것이다.
로깅 메커니즘(1004)은, 이러한 공격이 검증 동안 드러나는 방식으로 해당 공격을 완화시키기에 충분할 수 있다. 로그는 특정 PUF 모듈(603) 자체의 설계에 영향을 미칠 것인데, 이는, 도 10에 도시된 바와 같이, 로그를 생성하기 위한 프로세싱 요소 및 로그를 레코딩하기 위한 온-디바이스 저장소(1006)를 포함할 수 있기 때문이다
하나의 가능한 구현에서, 설계에서의 범용 프로세서는 로그를 생성하기 위해 필요한 로직뿐만 아니라 결과를 생성하기 위해 원하는 컴퓨테이션을 수행할 수 있다. 이제 이 설정은, 디바이스에 의해 수행된 모든 동작이 레코딩되고 검증 프로세스와 함께 사용되어 디바이스가 예기치 않게 거동했을 수 있는 이유를 조정할 수 있음을 의미한다.
이러한 '로컬 검증' 시나리오에서, 장래의 검증 시간에서, 검증기(103V)가 그 응답을 프로빙(probe)하기 위해 PUF 모듈(603) 디바이스에 대한 완전한 액세스를 가질 것이라고 가정된다는 것이 유의되어야 한다. 로깅 시스템을 특징으로 하는 이러한 대안적인 설정은, PUF 모듈(603)의 소유자가 검출할 수 없는 이력 중간자 공격을 검증기(103V)가 검출하는 것을 가능하게 하는 것이다. 또한, 예컨대, 폐쇄형 IoT 시스템의 경우, 검증자와 소유자가 동일한 당사자일 수 있음에 유의한다.
다음 섹션에서는, 실시예에서, 이러한 로깅 시스템이 구체적으로 로깅 프로세스에 공개 블록체인을 도입함으로써 어떻게 강화될 수 있는지를 살펴본다.
6.2 PUF 무결성을 위한 블록체인 기반 이벤트 로깅
PUF 기반 아이덴티티 시스템을 강화하기 위해 블록체인을 사용하기 위한 본 명세서에 개시된 다른 양상은 위에서 언급된 중간자 공격(man-in-the-middle attacks)의 더 강건한 완화를 제공하는 데 있으며, 여기서, 디바이스에 의해 수행된 동작을 레코딩하기 위해 PUF 디바이스에 내장된 로깅 시스템의 개념이 도입되었다.
이러한 추가적인 로그는, 수정된 챌린지(C')를 형성하기 위해 제출된 챌린지(C)를 수정함으로써 임의의 당사자, 앨리스, 밥, TTP, 또는 다른 것이 일부 형태의 중간자 공격(man-in-the-middle attack)을 수행하는 것을 중지시키기 위한 수단을 제공하도록 의도되고, 이는 PUF 디바이스(1000)에 의해 주어진 응답(R')이 예상된 정확한 응답(R)에 사실상 대응하지 않는다는 것을 의미한다.
로그는, 전송 중(즉, 통신 동안) 챌린지에 대한 임의의 수정이 검출될 것이라고 보장함으로써 이 문제를 완화한다. 그러나, 이것은, 로그가 위에서 약술된 조사 재구성 프로세스 동안 컨설팅되기 전에, 로그 자체가 변조되지 않았다는 가정에 기초한다.
따라서, 이러한 우려를 해결하기 위해, 실시예는, PUF 디바이스(1000)의 수명 동안 로그 자체의 세부사항을 변조 및 변경하는 악의적인 행위자에 의한 이러한 유형의 중간자 공격에 대한 보다 강건한 솔루션을 제공한다.
이를 달성하기 위해, 디바이스에 로깅된 데이터는 블록체인(150)에 제출된다. 바람직하게는, 이것은 도 11에 도시된 바와 같이 주기적으로, 그리고 가능하게는 2개의 다른 시간 척도에서 이루어져야 한다.
이러한 실시예에서, 로그의 콘텐츠는 프로세싱(i)의 시간에 먼저 제출될 수 있고, 이로써 PUF 디바이스에 의한 각각의 동작(또는 그에 의해 수신된 요청)이 디바이스를 트리거하여, 이 동작 또는 요청의 레코드를 포함하는 트랜잭션을 블록체인에 제출한다. 도 11에 도시된 바와 같이, 이것은, 예컨대, 결과의 HMAC의 형태로 행해질 수 있고, 이는 요청에서의 챌린지에 대한 PUF 자체의 관련 응답을 사용하여 키잉될(keyed) 수 있다. 대안적으로, 결과는 유사한 방식으로 암호화되어 블록체인에 기록될 수 있다.
추가로, 전체 로그는 (i) 온-디바이스 저장소가 소거(purge)될 수 있도록(디바이스의 저장 오버헤드를 감소시킴) 그리고 (ii) 메커니즘에 의한 더 이른 증명이 나중 시점에서의 로그의 상태와 비교될 수 있도록 블록체인에 주기적으로 기록될 수 있다. 유사하게, 이러한 로깅은 HMAC, 암호화 또는 유사한 수단을 통해 수행될 수 있고, 우리는 (i) 또는 (ii) 중 어느 것도 특정 레코드 방법으로 제한하지 않는다. 데이터는 하나 이상의 블록체인 트랜잭션에서 임의의 적절한 방식으로 레코딩될 수 있다.
로그에 레코딩된 결과를 실시간 및 주기적 체크포인트형 방식으로 미러링함으로써, 온-디바이스 로깅 시스템의 악의적인 변조로 인한 중간자 공격이 검출되지 않을 위험이 최소화될 수 있다. 또한, 제2 형태의 로깅(ii)의 주기성을 신중하게 선택함으로써, 시스템은 그러한 변조가 발생했을 수 있는 특정 시간-윈도우의 식별을 가능하게 해야 한다. 이러한 가정은 블록체인을 신뢰할 수 있는 타임 스탬핑 서버로서 사용하는 것에 명시적으로 의존한다.
7. 비보안 채널을 통한 보안 통신
위의 설명은, PUF 디바이스(603)가 블록체인(150) 상에 레코드를 안전하게 로깅할 수 있는 실시예를 포함하였다. 이러한 아이디어는, 전송자가 전송자와 블록체인(150) 사이에서 비보안 채널을 사용하고 있더라도, 임의의 전송 엔티티(PUF 디바이스 또는 다른 것이든 간에, 당사자 또는 디바이스)가 블록체인을 통해 수신자와 안전하게 통신하는 것을 허용하도록 확장될 수 있다. 이러한 맥락에서 비보안(또는 보안되지 않음)은 전송되는 메시지의 인터셉트 및 조작에 취약함을 의미한다.
잠재적인 문제가 도 12에 도시된다. 다음은, 그들 개개의 컴퓨터 장비(102a, 102b)를 사용하여 그들 개개의 방법을 수행하고 있다고 가정되는 전송 사용자 앨리스(103a) 및 수신자 사용자 밥(103b)을 참조하여 설명될 것이다. 그러나 보다 일반적으로, 동일한 교시가 임의의 송신 및 수신자 엔티티에 적용될 수 있으며, 이들 각각은 사용자 장비(102)를 사용하는 하나 이상의 사용자의 당사자일 수 있거나, 이는 대안적으로 자율 디바이스일 수 있다.
통신 매체로서 블록체인(150)을 통해 2개의 엔티티 간의 통신하는 것이 알려져 있다. 도 12에 도시된 바와 같이, 전송자 앨리스는, 대응하는 블록체인 네트워크(106)에 의해 블록체인(150) 상의 트랜잭션의 페이로드에 레코딩될 메시지(M)를 전송하여, 수신자 밥이 블록체인(150)으로부터 메시지를 판독할 수 있도록 한다. 예컨대, 메시지(M)는 잠금 스크립트에서 OP_RETURN 또는 OP_PUSHDATA 작업코드(opcode)를 사용함으로써 트랜잭션의 출력에 포함될 수 있다. 앨리스는 트랜잭션 자체를 공식화하고, 트랜잭션을 블록체인 네트워크(106)에 전송함으로써 메시지(M)를 전송할 수 있거나, 트랜잭션에서 메시지를 랩핑(wrap)하고 블록체인 네트워크(106)에 계속적으로 포워딩하는 일부 중간 엔티티에 메시지(M)를 전송할 수 있다.
어느 쪽이든 간에, 전송자 앨리스는, 예컨대, 암호화를 사용하지 않는 비보안 채널(1100)을 통해 블록체인 네트워크(106)를 향해 메시지(M)를 전송해야 할 수 있다. 이러한 채널은, 메시지(M)가 블록체인 네트워크(106)에 도달하기 전에, 이를 다른 메시지(M')로 변환하거나 교체함으로써 메시지(M)를 조작할 수 있는 악의적인 당사자에 의한 인터셉트에 취약할 수 있다. 채널(1100)이 암호화되더라도, 이것은 악의적인 당사자가 메시지를 조작하는 것을 반드시 방지하지는 않는다(비록 악의적인 당사자가 원래 메시지가 무엇을 의미하는지를 알 수 없을 것이고 의미 있는 대안적인 메시지(M')를 공식화할 수 없을지라도, 이것은, 당사자가, 예컨대, 서비스 거부 공격의 일부로서 여전히 무의미한 메시지(M')를 전송할 수 없었다는 것을 의미하지는 않는다).
도 13은, 조작이 발생했음을 앨리스가 검출하게 하고 그 경우 비보안 채널을 통해 더 이상의 추가의 메시지를 전송하는 것을 중지시키게 하는 메커니즘을 제공함으로써 이 잠재적인 문제를 해결하는 어레인지먼트를 도시한다.
앨리스는 밥에게 전송하기를 원하는 제1 메시지(Mi=1)를 포함하는 제1 트랜잭션 Tx(Mi=1)을 공식화함으로써 시작한다. 메시지(Mi)는, 이를테면, OP_RETURN 또는 OP_PUSHDATA와 함께 메시지를 출력의 잠금 스크립트에 포함시킴으로써, 예컨대, 출력 기반(예컨대, UTXO 기반) 모델에서 트랜잭션의 출력에 포함될 수 있다. 예컨대, 이는, 이를테면, OP_RETURN 및 OP_FALSE를 사용함으로써 지출 불가능한 출력에 포함될 수 있다. 트랜잭션은, 이를테면, 밥이 체인 상에서 식별할 수 있는 밥의 주소, 또는 밥이 모니터링하고 있는 플래그(F)를 체인 상에 포함시킴으로써 밥에게 전달된다. 앨리스는 또한 메시지를 포함하여 트랜잭션에 서명한다. 즉, 그녀는 앨리스의 키 및 적어도 메시지를 포함하는 트랜잭션의 일부의 함수로서 서명을 생성하고, 그 서명을 트랜잭션에 포함시킨다. 트랜잭션 페이로드를 포함하는 트랜잭션에 서명하는 방법은 그 자체로 당업계에 알려져 있다.
일단 형성되면, 앨리스는 블록체인(150) 상의 블록(151)에 레코딩될 제1 트랜잭션을 블록체인 네트워크(106)의 노드(104)에 전송한다. 그녀는 노드(104)로 직접 또는 하나 이상의 중간 당사자를 통해 트랜잭션을 전송할 수 있다. 어느 쪽이든 간에, 앨리스의 컴퓨터(102a)와 노드(104) 사이의 트랜잭션의 경로는 이전에 논의된 바와 같이, 하나 이상의 비보안 채널(1100)을 포함한다.
이러한 채널을 통한 첫 번째 메시지의 가능한 조작을 검출하기 위해, 앨리스는, 체인 상에 레코딩된 첫 번째 메시지를 포함하는 제1 트랜잭션이 예상된 바와 같은지 여부를 체크하기 위해 블록체인(150)에 질의한다. 그녀는 블록체인 네트워크(106)의 노드(104)에 직접 질의하거나, 질의를 신뢰할 수 있는 중간 서비스에 제출함으로써 이를 수행할 수 있다. 질의는 메시지의 사본, 트랜잭션 식별자 또는 트랜잭션 자체를 리턴할 수 있으며, 앨리스 또는 신뢰할 수 있는 서비스는 전송된 메시지, 트랜잭션 ID 또는 트랜잭션과 이들을 비교할 것이다. 대안적으로, 질의는 메시지, 트랜잭션 ID 또는 트랜잭션의 증명, 예컨대, 그의 머클 증명을 리턴할 수 있다. 다른 가능성으로서, 앨리스는 그녀 자신의 서명을 체크할 수 있다. 따라서, 어떤 수단에 의해 구현되든지 간에, 질의는 첫 번째 메시지가 앨리스가 전송한 형태로 체인 상에 레코딩되었는지 여부를 그녀가 체크하는 것을 가능하게 한다. 그렇지 않은 경우, 이것은 첫 번째 메시지가 인터셉트되어 조작되었음을 나타낸다.
첫 번째 메시지(M1)는, 전술한 바와 동일한 방식으로 앨리스가 블록체인(150)을 통해 밥에게 전송하고자 하는 일련의 메시지(Mi) 중 첫 번째일 수 있다. 그러나, 두 번째 메시지(M2)(또는 임의의 후속 메시지)의 송신은, 메시지가 앨리스와 블록체인(150) 사이에서 조작되지 않았다는 전술한 체크에 대한 조건부이다. 그렇지 않은 경우, 앨리스는 (적어도 보안 문제의 원인이 해결될 때까지) 두 번째 메시지(M2) 또는 후속 메시지를 전송하지 않을 것이다. 실시예에서, 질의 및 체크, 및 추가 메시지의 차단은 앨리스의 컴퓨터 장비(102a)에 의해 자동으로 구현되는 자동화된 단계일 수 있다. 앨리스는 또한, 밥이 첫 번째 메시지(M1)를 무시하는 것으로 알도록 검출된 조작을 밥에게 알릴 수 있다. 일부 실시예에서, 이 알림 단계는 또한 자동화될 수 있다.
체크가 부정의 결과를 리턴하면, 즉, 메시지가 상기 질의에 기초하여 조작되지 않은 것으로 결정되었다면, 앨리스는 두 번째 메시지(M2), 및 잠재적으로 추가 메시지(Mi=3, 4...) 등을 전송할 수 있다. 두 번째 메시지(M2)는 첫 번째 메시지가 제1 트랜잭션에서 전송되었던 방식을 약간 수정하여 동일한 방식으로 제2 트랜잭션(Tx(M2))에서 전송된다. 제2 트랜잭션(Tx(M2))은 반드시 제1 트랜잭션(Tx(M1))을 지출할 필요는 없고, 반드시 제1 트랜잭션에 의존하여 지출할 필요도 없다. 따라서, 출력-기반(예컨대, UTXO-기반) 트랜잭션 모델에서, 제2 트랜잭션은 반드시 제1 트랜잭션의 출력(또는 제1 트랜잭션과 제2 트랜잭션 사이의 지출 그래프에서의 임의의 트랜잭션의 출력)을 가리키는 입력을 가질 필요는 없다. 다시 말해서, 트랜잭션은 페이로드에서 메시지를 통신하는 데 사용되고 있고, 그 체크는, 예컨대, 제1의 출력을 지출하는 향후 지출 트랜잭션을 전송하기 전에, 앨리스가 그녀의 변화를 체크하는 것에 불과하지 않다.
반면에, 체크는, 즉, 상기 질의에 기초하여, 메시지가 조작된 것으로 결정되었다는 긍정의 결과를 리턴할 수 있다. 다시 말해서, 앨리스에게 돌아오는 응답이 나는 이러한 트랜잭션을 알지 못한다는 "아니오" 또는 나는 이러한 트랜잭션에 대한 머클 증명을 갖고 있지 않다는 "아니오" 형태를 갖는 실패 경로에서, 이것은, 앨리스의 트랜잭션이 인터셉트 및 변경되어 프로세스에서 트랜잭션이 무효화되어 체인에 포함될 수 없음을 의미한다. 이 경우, 앨리스는 두 번째 메시지(M2)를 전송하지 않는다(또는 적어도 동일한 채널을 통하지 않음). 실시예에서, 이것은 앨리스의 컴퓨터 장비(102a) 상에서 실행되는 소프트웨어(105a)에 의한 두 번째 메시지의 전송 상에 배치된 자동 블록일 수 있다.
따라서, 전송된 메시지의 메시지 무결성을 보장하기 위한 일 형태의 검증 알고리즘이 제공된다. 누군가 또는 일부 디바이스(A)가 메시지(M)를 다른 당사자(B)에게 전송하기를 원하지만 메시지가 인터셉트 및 변경될 수 있다고 걱정한다면, 그들은 이 알고리즘을 사용하여 메시지가 수정되지 않았다고 확신할 수 있다. 방법은 전송기와 수신기 둘 모두가 읽을 수 있는 메시지에 대한 앵커 포인트로서 블록체인을 사용하지만, 이는, A가 블록체인으로부터 읽을 수 있다면, 그는 메시지가 서명되는 순간부터 어떠한 메시지도 변경되지 않았다고 확신할 수 있다는 추가 속성을 갖는다. 요약하면, 알고리즘의 실시예는 다음과 같이, 또는 이와 유사하게 동작할 수 있다.
1. 당사자 A와 당사자 B는 비보안 채널을 통해 전송하고자 한다.
2. 당사자 A는 메시지를 생성하고, 블록체인 트랜잭션에 패키징하고, 트랜잭션에 서명한다.
3. 당사자 A는 트랜잭션을 블록체인 네트워크에 제출한다. 그들은 메시지가 수정되지 않았다는 증거에 대해 블록체인에 질의할 수 있다. 예컨대, 그들은 그들의 트랜잭션에 대한 머클 증명을 요청해야 할 수 있고, 이것은 밥이 올바른 메시지를 읽는다는 확실한 증거로서 작동한다. 이는 채굴자(노드)에서 신뢰 부재 시에 작동하는데, 왜냐하면 이것이 증명으로서 작업 증명을 사용하기 때문이다.
4. 당사자 A는 그들이 제출한 트랜잭션에 대해 머클 증명을 검증하려고 한다.
a. 성공하면, 당사자 A는 어떠한 변화도 없이 후속 메시지를 계속해서 전송한다.
b. 그렇지 않으면, 당사자 A는 (아마도 상이한 채굴자에게) 재제출/중단하고 이러한 식이고, 첫 번째 메시지가 성공적이지 않았음을 나타내는 새로운 메시지를 포함시킬 수 있다.
요컨대, 이것은 당사자 A가, 예컨대, 머클 증명의 유효성에 기초하여 통신 채널에서 어떻게 진행할지를 결정하는 방법(단계 4)을 제공한다.
실시예에서, 조작에 대한 동일한 체크가 제3 트랜잭션을 전송하기 위한 조건으로서, 제2 트랜잭션에 약간 수정하여 적용되고, 이러한 식일 수 있다.
실시예에서, 일련의 메시지(Mi=1,2,3,...)는, 예컨대, 동일한 전체 통신의 상이한 패킷인 의미있게 링크된 콘텐츠(예컨대, 기록된 문서, 비디오, 또는 사운드 파일 등)를 포함할 수 있다.
실시예에서, 메시지(Mi) 자체뿐만 아니라, 일련의 메시지의 각각의 트랜잭션은 또한 개개의 플래그(Fi)를 포함할 수 있다. 밥은 이것을 이용하여, 그가 블록체인(150)을 검사할 때 자신에게 의도된 메시지를 식별할 수 있다. 대안적으로 또는 추가적으로, 밥의 주소가 각각의 트랜잭션에 포함될 수 있다.
플래그(Fi)는 어떤 메시지가 일련의 메시지의 일부를 형성하는지, 및 일련의 메시지에서의 메시지의 위치를 식별하기 위해 밥에 의해 사용될 수 있다. 실시예에서, 플래그(Fi)는 인덱스 값(i)의 함수일 수 있고, 여기서 인덱스(i)는 일련의 메시지 내의 각각의 메시지의 위치를 인덱싱한다. 이것에 사용되는 함수는 앨리스와 밥 둘 모두에게 미리 알려진 미리 정해진 형태일 수 있다.
일부 이러한 실시예에서, 일련의 메시지를 통신하기 전에 초기 설정 페이즈에서, 앨리스 및 밥은 보안 측 채널(107)을 통해 일련의 메시지에서 첫 번째 플래그(F1)를 확립할 수 있다. 앨리스와 밥은 일시적인 보안 채널(107)을 설정하기 위한 자원 및 능력을 가질 수 있지만, 그들은 나중에 이를 계속 사용할 수 없을 수 있다. 예컨대, 보안 채널(107)은, 예컨대, 디피-헬먼 키 교환(Diffie-Hellman key exchange)을 요구하는 암호화된 채널일 수 있지만, 앨리스와 밥은 통신의 나중 시간에 이러한 채널을 사용할 수 없을 수 있다. 이것은, 예컨대, 어떤 당사자가 메시지를 통신할 때 저장소 또는 디바이스 능력에 대한 제한된 액세스를 가질 것인 경우에 유용할 수 있다. 예컨대, 아마도 밥은 '공공 설비를 사용하지 않고(off the grid)', 모든 전자 디바이스를 없애고 싶어 하지만, 여전히 인터넷 카페에 가서 플래그를 사용하여 블록체인을 가끔 체크할 수 있다. 그 혜택은 매우 강력한 프라이버시일 것이다. 또 다른 예는, 임의의 지점에서 어느 한 당사자가 오프라인일 필요가 있는 경우일 것이다. 블록체인은, 메시지가 전송될 때 수신자가 온라인이든 또는 아니든지 간에 통신을 허용함으로써 도움을 준다.
설정 페이즈는 앨리스가 첫 번째 플래그를 밥에 전송하는 것, 또는 밥이 첫 번째 플래그를 앨리스에 전송하는 것, 또는 앨리스와 밥이 상호 프로토콜(mutual protocol)에 따라 첫 번째 플래그를 협상하는 것을 포함할 수 있다. 공유된 비밀(shared secret)을 확립하기 위한 프로토콜은 그 자체로 당업계에 알려져 있다. 각각의 플래그(Fi)를 인덱스(i)와 관련시키는 기능은 또한 일련의 메시지에서 첫 번째 플래그(F1) 또는 선행 플래그(Fi-1)의 함수일 수 있다. 따라서, 보안 채널(107)은 초기 설정 페이즈에서 한 번만 사용될 필요가 있고, 이후에, 앨리스와 밥 둘 모두가 인덱스(i) 및 첫 번째 또는 선행 플래그에 각각의 연속적인 플래그(Fi)를 관련시키는 함수의 형태를 알고 있기 때문에, 앨리스와 밥은 대신에 블록체인(150)을 통해 안전하게 통신할 수 있고, 밥만이 어떤 메시지가 일련의 메시지의 일부를 형성하는지 및 메시지가 어떤 순서로 들어가는지를 결정할 수 있을 것이다.
플래그(F)가 사용되든지 아니든지 간에, 밥이 블록체인(150) 상에서 자신에게 의도된 메시지를 식별할 때, 그는 또한 앨리스의 공개 키를 사용하여 서명을 인증할 수 있다. 그러나, 서명이 단독으로 원하는 레벨의 보안을 반드시 제공할 필요는 없으며, 따라서 서명의 사용 이외에도, 제2 메시지를 보기 전에 체인에 질의하는 전술한 메커니즘이 유용할 수 있다는 것이 유의된다. 메시지가 조작되었다면, 많은 경우에, 이는 트랜잭션을 무효화시킬 것이고, 이는 결코 체인에 포함되지 않을 것이다. 그래서, 해당 경우에, 트랜잭션이 앨리스에 의해 만들어졌다는 것을 밥이 안다고 가정하면, 트랜잭션이 방금 나타나는 것을 밥이 아는 것은 그 메시지가 '그에게는’ 수정되지 않았다는 것을 알기에 충분하다. 서명과 앨리스의 공개 키를 트랜잭션(가능성이 가장 크게는 입력)에서 아는 것만으로는, 앨리스가 그것을 만들었다는 것을 확신하기에 불충할 것이지만, 그가 서명 자체를 유효성 검증한다면, 그는 확신할 수 있다. 그래서, 이러한 마지막 단계는, 단지 밥이 자신에 대한 메시지라고 생각하는 메시지의 기원이 앨리스로부터 왔다는 것을 알고 있다고 선언(assert)하는 것이다. 그러나, 악의적인 당사자는 앨리스의 트랜잭션을, 악의적인 당사자의 공개 키로 유효하게 서명된 다른 트랜잭션으로 대체할 수 있을 것이다. 그러한 트랜잭션은 블록체인 네트워크(106)에 의해 유효성 검증되고 체인 상에 레코딩될 것이다. 밥은 해당 트랜잭션에 포함된 공개 키에 기초하여 서명을 유효성 검증할 수 있지만, 해당 공개 키가 앨리스의 실제 아이덴티티와 링크되어 있다는 것을 그가 모른다면, 그는 메시지가 인터셉트되었는지를 여전히 모를 것이다. 즉, 앨리스의 공개 키가 확실하지 않다는 것은, 메시지가 인터셉트하지 않았다는 것을 확신할 수 없다는 것을 의미한다.
8. 결론
개시된 기술들의 다른 변형들 또는 사용 사례들은 본 명세서에서의 개시가 주어지면 당업자에게 명백해질 수 있다. 본 개시내용의 범위는 설명된 실시예에 의해 제한되는 것이 아니라 첨부된 청구들에 의해서만 제한된다.
예컨대, 위의 일부 실시예들은 비트코인 네트워크(106), 비트코인 블록체인(150) 및 비트코인 노드(104) 관점에서 설명되었다. 그러나 비트코인 블록체인은 블록체인(150)의 하나의 특정 예이며 위의 설명은 모든 블록체인에 일반적으로 적용될 수 있다는 것이 인지될 것이다. 즉, 본 발명은 결코 비트코인 블록체인으로 제한되지 않는다. 보다 일반적으로, 비트코인 네트워크(106), 비트코인 블록체인(150) 및 비트코인 노드(104)에 대한 위의 임의의 참조는 각각 블록체인 네트워크(106), 블록체인(150) 및 블록체인 노드(104)에 대한 참조로 대체될 수 있다. 블록체인, 블록체인 네트워크 및/또는 블록체인 노드는 위에서 설명된 바와 같이 비트코인 블록체인(150), 비트코인 네트워크(106) 및 비트코인 노드(104)의 설명된 성질들 중 일부 또는 전부를 공유할 수 있다.
본 발명의 바람직한 실시예들에서, 블록체인 네트워크(106)는 비트코인 네트워크이고 비트코인 노드들(104)은 블록체인(150)의 블록들(151)을 생성, 공개, 전파 및 저장하는 설명된 기능들 모두를 적어도 수행한다. 이러한 기능들의 전부는 아니지만 하나 또는 일부만을 수행하는 다른 네트워크 엔티티들(또는 네트워크 요소들)이 있을 수 있음을 배제되지 않는다. 즉, 네트워크 엔티티는 블록들을 생성 및 공개하지 않고 블록들을 전파 및/또는 저장하는 기능을 수행할 수 있다(이러한 엔티티들은 바람직한 비트코인 네트워크(106)의 노드들로 간주되지 않음을 상기한다).
본 발명의 다른 실시예들에서, 블록체인 네트워크(106)는 비트코인 네트워크가 아닐 수 있다. 이러한 실시예들에서, 노드가 블록체인(150)의 블록들(151)을 생성, 발행, 전파 및 저장하는 기능들 전부는 아니지만 적어도 하나 또는 일부를 수행할 수 있다는 것이 배제되지 않는다. 예컨대, 이러한 다른 블록체인 네트워크들에서, "노드"는 블록들(151)을 생성 및 공개하지만 해당 블록들(151)을 저장하고 그리고/또는 다른 노드에 전파하진 않도록 구성된 네트워크 엔티티를 지칭하는 데 사용될 수 있다.
보다 더 일반적으로, 위의 "비트코인 노드"(104)라는 용어에 대한 임의의 참조는 "네트워크 엔티티" 또는 "네트워크 요소"라는 용어로 대체될 수 있으며, 이러한 엔티티/요소는 블록들을 생성, 공개, 전파 및 저장하는 역할들의 일부 또는 전부를 수행하도록 구성된다. 이러한 네트워크 엔티티/요소의 기능들은 블록체인 노드(104)를 참조하여 위에서 설명된 동일 방식으로 하드웨어로 구현될 수 있다.
위의 실시예들은 단지 예로서만 설명되었다는 것이 인지될 것이다. 보다 일반적으로, 다음 스테이트먼트들 중 임의의 하나 이상에 따른 방법, 장치 또는 프로그램이 제공될 수 있다.
스테이트먼트 1. 디바이스로서, PUF(physically unclonable function), 및 입력 챌린지를 수신하고 입력 챌린지의 결정론적 함수인 출력 응답을 출력하도록 배열되는 내부 PUF 인터페이스 로직을 포함하는 PUF 모듈 ― 결정론적 함수는 PUF를 포함함 ― ; 및 입력 챌린지를 PUF 모듈의 내부 인터페이스 로직에 입력하고 내부 인터페이스 로직에 의해 출력된 출력 응답을 다시 수신하기 위한 비보안 채널의 적어도 일부를 제공하는 하나 이상의 외부 계층 구성요소를 포함하고, 외부 계층 구성요소 중 적어도 하나는 악의적인 프로세스에 의한 입력 챌린지 및/또는 출력 응답의 조작에 취약하지만, 내부 PUF 인터페이스 로직을 포함하는 PUF 모듈은 디바이스의 하우징 내에 캡슐화되고 하나 이상의 외부 계층 구성요소로부터 분리되고, 따라서 악의적인 프로세스에 의한 조작으로부터 보호되고; 그리고 내부 PUF 인터페이스 로직은 입력 챌린지 및/또는 출력 응답의 레코드를 로그 매체에 자동으로 로깅하도록 배열된 로깅 메커니즘을 포함한다.
스테이트먼트 2. 스테이트먼트 1의 디바이스에 있어서, 내부 인터페이스 로직은 디바이스의 프로세서 상에서 실행되는 펌웨어(firmware)에서 부분적으로 또는 전체적으로 구현된다.
스테이트먼트 3. 스테이트먼트 2의 디바이스에 있어서, 펌웨어는 ROM(read only memory)에 부분적으로 또는 전체적으로 저장된다.
스테이트먼트 4. 스테이트먼트 1 또는 2의 디바이스에 있어서, 펌웨어는 보안 커널에서 부분적으로 또는 전체적으로 구현된다.
스테이트먼트 5. 임의의 선행 스테이트먼트의 디바이스에 있어서, 내부 인터페이스 로직은 고정-기능 하드웨어 회로에서 구현된다.
스테이트먼트 6. 임의의 선행 스테이트먼트의 디바이스에 있어서, 적어도 하나의 외부 계층 구성요소는 디바이스 외부의 소스로부터 입력 챌린지를 수신하고 그리고/또는 디바이스 외부의 목적지로 출력 응답을 공급하기 위한 외부 인터페이스를 포함하고, 적어도 하나의 외부 계층 구성요소가 취약한 악의적인 프로세스는 소스와 외부 인터페이스 사이의 입력 챌린지 및/또는 출력 응답의 인터셉트 및 조작을 포함한다.
스테이트먼트 7. 스테이트먼트 6의 디바이스에 있어서, 소스는 디바이스에 로컬이고, 외부 인터페이스는 네트워크를 통한 전송 없이 입력 챌린지를 수신하도록 동작 가능하다.
스테이트먼트 8. 스테이트먼트 6의 디바이스에 있어서, 소스는 디바이스로부터 원격이고, 외부 인터페이스는 네트워크를 통해 소스로부터 입력 챌린지를 수신하도록 동작 가능하다.
스테이트먼트 9. 스테이트먼트 6 내지 8 중 어느 한 스테이트먼트의 디바이스에 있어서, 디바이스는 전용 PUF 디바이스를 포함한다.
스테이트먼트 10. 스테이트먼트 1 내지 8 중 어느 한 스테이트먼트의 디바이스에 있어서, 적어도 하나의 외부 계층 구성요소는 디바이스의 하우징 내의 프로세서 상에서 실행되는 애플리케이션을 포함하고, 애플리케이션은 입력 챌린지를 생성하도록 구성되고, 적어도 하나의 외부 계층 구성요소가 취약한 악의적인 프로세스는 입력 챌린지를 조작하기 위해 애플리케이션과 동일한 프로세서 상에서 실행되는 멀웨어를 포함한다.
스테이트먼트 11. 스테이트먼트 10의 디바이스에 있어서, 내부 인터페이스 로직은 애플리케이션과는 별개의 프로세서 상에서 실행되도록 배열된다.
스테이트먼트 12. 스테이트먼트 10의 디바이스에 있어서, 내부 인터페이스 로직은 애플리케이션과 동일한 프로세서 상에서 실행되지만, 보안 프로세서의 특권 도메인(privileged domain)에서 실행되도록 배열되는 반면, 애플리케이션은 애플리케이션 도메인에서 실행된다.
스테이트먼트 13. 스테이트먼트 10 내지 12 중 어느 한 스테이트먼트의 디바이스에 있어서, 디바이스는 EDR(event data recorder)을 포함하고, 애플리케이션은 EDR 애플리케이션을 포함한다.
스테이트먼트 14. 스테이트먼트 13의 디바이스에 있어서, 애플리케이션은 EDR이 모니터링하도록 구성된 시스템의 결과를 생성하도록 구성되고, EDR은 결과 및 출력 응답을 결과에 매핑하는 태그를 레코딩하도록 구성된다.
스테이트먼트 15. 스테이트먼트 14의 디바이스에 있어서, 태그는: 결과에 출력 응답을 서명함으로써 생성된 암호 서명; 또는 결과 및 출력 응답의 함수로서 생성된 HMAC(hash-based message authentication code)를 포함한다.
스테이트먼트 16. 스테이트먼트 14 또는 15의 디바이스에 있어서, 입력 챌린지는, 모니터링되는 시스템의 상태를 나타내는, 애플리케이션에 의해 사용되는 의미 있는 데이터를 포함한다.
스테이트먼트 17. 스테이트먼트 16의 디바이스에 있어서, 결과는 상기 데이터에 의존한다.
스테이트먼트 18. 스테이트먼트 13 내지 17 중 어느 한 스테이트먼트의 디바이스에 있어서, EDR은 차량을 위한 EDR이고, EDR이 모니터링하도록 구성되는 시스템은 차량의 시스템을 포함한다.
스테이트먼트 19. 임의의 선행 스테이트먼트의 디바이스에 있어서, 하나 이상의 외부 계층 구성요소는 PUF 모듈과 동일한 하우징에서 구현된다.
스테이트먼트 20. 임의의 선행 스테이트먼트의 디바이스에 있어서, PUF 모듈은 확장된 PUF 모듈을 포함하고 이로써 입력 챌린지는 2차 챌린지이고 출력 응답은 2차 응답이고; 그리고 내부 PUF 인터페이스 로직은 1차 응답을 생성하기 위해 챌린지를 PUF에 입력하고, 1차 응답 및 2차 챌린지의 결정론적 변환으로서 2차 응답을 결정하도록 구성된다.
스테이트먼트 21. 스테이트먼트 20의 디바이스에 있어서, 결정론적 변환은 해시 함수(hash function)를 포함한다.
스테이트먼트 22. 스테이트먼트 1 내지 19 중 어느 한 스테이트먼트의 디바이스에 있어서, 인터페이스 로직은 입력 챌린지를 PUF에 직접 입력하고 입력 응답의 함수로서 PUF로부터 직접 출력 응답을 수신하도록 구성된다.
스테이트먼트 23. 임의의 선행 스테이트먼트의 디바이스에 있어서, 로그 매체는 디바이스의 로컬 메모리를 포함한다.
스테이트먼트 24. 스테이트먼트 23의 디바이스에 있어서, 상기 로컬 메모리는 변조 방지 메모리(tamperproof memory), 일회 기록(write-once) 메모리이고, 그리고/또는 인터페이스 로직에 임베딩된다.
스테이트먼트 25. 임의의 선행 스테이트먼트의 디바이스에 있어서, PUF 인터페이스 로직이 레코드를 로깅하도록 구성되는 로그 매체는 디바이스 외부의 공개적으로 액세스 가능한 매체를 포함한다.
스테이트먼트 26. 스테이트먼트 25의 디바이스에 있어서, PUF 인터페이스 로직이 레코드를 로깅하도록 구성되는 공개적으로 액세스 가능한 매체는 블록체인을 포함한다.
스테이트먼트 27. 임의의 선행 스테이트먼트의 디바이스에 있어서, 내부 PUF 인터페이스 로직은, 개별 입력 챌린지의 입력에 응답하여, 레코드의 로깅을 실시간으로 수행하도록 구성된다.
스테이트먼트 28. 임의의 선행 스테이트먼트의 디바이스에 있어서, 내부 PUF 인터페이스 로직은, 주기적 시간 윈도우의 각각의 인스턴스 동안 수신된 임의의 입력 챌린지 및/또는 생성된 출력 응답을 주기적으로 로깅하도록 구성된다.
스테이트먼트 29. 스테이트먼트 28의 디바이스에 있어서, 적어도 스테이트먼트 23, 25 및 27에 종속할 때, 내부 PUF 인터페이스 로직은 개별 입력 챌린지의 입력에 응답하여 상기 로컬 메모리에 레코드를 실시간으로 로깅하고, 그리고 또한 공개적으로 액세스 가능한 매체에 대한 주기적 로깅을 수행하도록 구성된다.
스테이트먼트 30. 스테이트먼트 29의 디바이스에 있어서, 로깅 메커니즘은, 일단 공개적으로 액세스 가능한 매체에 로깅되면, 로컬 메모리로부터 로깅된 챌린지 및/또는 응답을 주기적으로 클리어하도록 추가로 구성된다.
스테이트먼트 31. 스테이트먼트 25 또는 이에 종속하는 임의의 후속 스테이트먼트의 디바이스에 있어서, 로깅 메커니즘은, 개별 입력 챌린지의 입력에 응답하여, 레코드를 공개적으로 액세스 가능한 매체에 실시간으로 로깅하도록 구성된다.
스테이트먼트 32. 임의의 선행 스테이트먼트의 디바이스에 있어서, 내부 PUF 인터페이스 로직은 적어도 입력 챌린지의 레코드를 로깅하도록 구성된다.
스테이트먼트 33. 임의의 선행 스테이트먼트의 디바이스에 있어서, 내부 PUF 인터페이스 로직은 적어도 출력 응답의 레코드를 로깅하도록 구성된다.
스테이트먼트 34. 임의의 선행 스테이트먼트의 디바이스에 있어서, 로깅 메커니즘은, 레코드를 포함하는 패킷의 적어도 일부에 적용된 로깅 메커니즘의 암호 키에 기초하여 생성된 서명을 더 포함하는 패킷으로, 레코드의 로깅을 위해, 레코드를 출력하도록 구성된다.
스테이트먼트 35. 스테이트먼트 34의 디바이스에 있어서, 적어도 스테이트먼트 26에 종속할 때, 패킷은 블록체인 트랜잭션을 포함하고, 레코드는 블록체인 트랜잭션의 출력에 포함되고, 서명은 트랜잭션의 입력에 포함된다.
스테이트먼트 36. 임의의 선행 스테이트먼트의 디바이스를 사용하는 방법으로서, 입력 챌린지 및/또는 출력 응답의 레코드가 상기 로그 매체에 로깅된 후, PUF 모듈로 하여금 후보 응답을 생성하게 하고 후보 응답을 외부 계층의 비보안 채널을 통해 리턴하게 하기 위해, 후보 챌린지를 비보안 채널을 통해 디바이스에 입력하는 단계; 로그 매체에 로깅된 원래 입력 챌린지의 레코드에 대해 후보 챌린지를 체크하고, 그리고/또는 로그 매체에 로깅된 원래 출력 응답의 레코드에 대해 후보 응답을 체크함으로써 조작의 증거를 체크하는 단계를 포함한다.
스테이트먼트 37. 스테이트먼트 36의 방법에 있어서, 상기 체크하는 단계는 적어도, 후보 챌린지가 로그 매체에 레코딩된 입력 챌린지의 레코드와 매칭한다는 것을 체크하는 단계를 포함한다.
스테이트먼트 38. 스테이트먼트 36 또는 스테이트먼트 37의 방법에 있어서, 내부 PUF 인터페이스 로직은 후보 응답의 레코드를 로깅하도록 추가로 구성되고, 상기 체크하는 단계는 적어도, 후보 응답의 로깅된 레코드가 디바이스에 대한 입력으로서 후보 응답과 매칭한다는 것을 체크하는 단계를 포함한다.
스테이트먼트 39. 스테이트먼트 35 내지 38 중 어느 한 스테이트먼트의 방법에 있어서, 상기 체크하는 단계는 적어도, 후보 응답이 로그 매체에 레코딩된 원래 출력 응답의 레코드와 매칭한다는 것을 체크하는 단계를 포함한다.
스테이트먼트 40. 스테이트먼트 36 내지 39 중 어느 한 스테이트먼트의 방법에 있어서, 방법은 스테이트먼트 14의 디바이스 또는 이에 종속하는 스테이트먼트의 임의의 디바이스를 사용하는 방법이고, 방법은: 후보 결과에 기초하여 태그를 검증함으로써 디바이스가 상기 결과를 생성한 디바이스임을 검증하는 단계를 포함한다.
스테이트먼트 41. 컴퓨터 장비로서, 하나 이상의 메모리 유닛을 포함하는 메모리; 및 하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고, 메모리는 프로세싱 장치에서 실행되도록 배열된 코드를 저장하고, 코드는 프로세싱 장치 상에 있을 때 스테이트먼트 36 내지 40 중 어느 한 스테이트먼트의 방법을 수행하도록 구성된다.
스테이트먼트 42. 컴퓨터 프로그램은 비일시적 컴퓨터 판독 가능 매체 상에서 구현되고, 하나 이상의 프로세서 상에서 실행될 때 스테이트먼트 36 내지 스테이트먼트 40 중 어느 하나의 방법을 수행하도록 구성된다.
스테이트먼트 43. 컴퓨터-구현 방법으로서, 제1 엔티티에 의해: 블록체인 상에 레코딩될 제1 메시징 트랜잭션을 전송하는 단계 ― 제1 메시징 트랜잭션은 제1 메시지, 및 제2 엔티티가 블록체인 상에서 제1 메시지를 식별할 수 있도록 제1 메시지를 제2 엔티티에 보내는 개개의 정보를 포함함 ― ; 제1 메시지가 조작 없이 블록체인 상에 레코딩되었음을 체크하기 위한 질의를 제출하는 단계; 및 제1 메시지가 상기 질의에 따라 조작 없이 블록체인 상에 레코딩된 것으로 결정된다는 조건 하에, 블록체인 상에 레코딩될 제2 메시징 트랜잭션을 전송하는 단계 ― 제2 메시징 트랜잭션은 제2 메시지, 및 제2 엔티티가 블록체인 상에서 제1 메시지를 식별할 수 있도록 제2 메시지를 제2 엔티티에 보내는 개개의 정보를 포함함 ― 를 포함한다.
스테이트먼트 44. 스테이트먼트 43의 방법에 있어서, 제1 메시징 트랜잭션은 제1 자금 트랜잭션의 출력을 가리키는 입력을 포함하고, 제2 메시징 트랜잭션은 제2 자금 트랜잭션의 출력을 가리키는 입력을 포함하고, 어떠한 입력도 제1 메시징 트랜잭션의 임의의 출력을 가리키지 않는다.
스테이트먼트 45. 스테이트먼트 43 또는 44의 방법에 있어서, 제1 메시지 및 제2 메시지는 2개 이상의 메시지의 시퀀스에서의 연속적인 메시지이고, 제1 메시지 및 제2 메시지 각각은 시퀀스 내에 연관된 인덱스를 갖고, 제1 메시지 및 제2 메시지 각각은 블록체인 상에 레코딩되도록 제1 엔티티에 의해 개개의 메시징 트랜잭션으로 전송되고, 각각의 메시징 트랜잭션은 제2 엔티티가 블록체인 상에서 메시지를 식별하는 것을 가능하게 하는 개개의 정보를 포함하고; 각각의 메시지 내의 개개의 정보는 i) 연관된 인덱스 및 ii) 시퀀스 내의 첫 번째 플래그 또는 선행 플래그의 함수인 플래그를 포함하고, 함수의 형태는 제1 엔티티 및 제2 엔티티 각각에 알려지고; 그리고 방법은 제1 엔티티 및 제2 엔티티가, 함수의 형태, 첫 번째 플래그 및 각각의 메시지의 인덱스에 기초하여, 제1 메시지에 대한 플래그에 동의하고, 이로써 제1 엔티티 및 제2 엔티티가 상기 메시지의 시퀀스를 사용하여 블록체인을 통해 후속적으로 통신하는 것을 가능하게 하는 초기 설정 페이즈를 포함한다.
스테이트먼트 46. 컴퓨터 장비는 하나 이상의 메모리 유닛을 포함하는 메모리; 및 하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고, 메모리는 프로세싱 장치 상에서 실행되도록 배열된 코드를 저장하고, 코드는 프로세싱 장치 상에서 실행될 때 스테이트먼트 43 내지 45 중 어느 한 스테이트먼트의 방법을 수행하도록 구성된다.
스테이트먼트 47. 컴퓨터 프로그램은 비일시적 컴퓨터 판독 가능 매체 상에서 구현되고, 하나 이상의 프로세서 상에서 실행될 때 스테이트먼트 43 내지 45 중 어느 한 스테이트먼트의 방법을 수행하도록 구성된다.

Claims (47)

  1. 디바이스로서,
    PUF(physically unclonable function), 및 입력 챌린지를 수신하고 상기 입력 챌린지의 결정론적 함수인 출력 응답을 출력하도록 배열되는 내부 PUF 인터페이스 로직을 포함하는 PUF 모듈 ― 상기 결정론적 함수는 상기 PUF를 포함함 ― ; 및
    상기 입력 챌린지를 상기 PUF 모듈의 상기 내부 인터페이스 로직에 입력하고 상기 내부 인터페이스 로직에 의해 출력된 상기 출력 응답을 다시 수신하기 위한 비보안 채널의 적어도 일부를 제공하는 하나 이상의 외부 계층 구성요소를 포함하고,
    상기 외부 계층 구성요소 중 적어도 하나는 악의적인 프로세스에 의한 상기 입력 챌린지 및/또는 상기 출력 응답의 조작에 취약하지만, 상기 내부 PUF 인터페이스 로직을 포함하는 상기 PUF 모듈은 상기 디바이스의 하우징 내에 캡슐화되고 상기 하나 이상의 외부 계층 구성요소로부터 분리되고, 따라서 상기 악의적인 프로세스에 의한 조작으로부터 보호되고; 그리고
    상기 내부 PUF 인터페이스 로직은 상기 입력 챌린지 및/또는 상기 출력 응답의 레코드를 로그 매체에 자동으로 로깅하도록 배열된 로깅 메커니즘을 포함하는,
    디바이스.
  2. 제1항에 있어서, 상기 내부 인터페이스 로직은 상기 디바이스의 프로세서 상에서 실행되는 펌웨어(firmware)에서 부분적으로 또는 전체적으로 구현되는,
    디바이스.
  3. 제2항에 있어서, 상기 펌웨어는 ROM(read only memory)에 부분적으로 또는 전체적으로 저장되는,
    디바이스.
  4. 제1항 또는 제2항에 있어서, 상기 펌웨어는 보안 커널에서 부분적으로 또는 전체적으로 구현되는,
    디바이스.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서, 상기 내부 인터페이스 로직은 고정-기능 하드웨어 회로에서 구현되는,
    디바이스.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 적어도 하나의 외부 계층 구성요소는 상기 디바이스 외부의 소스로부터 상기 입력 챌린지를 수신하고 그리고/또는 상기 디바이스 외부의 목적지로 상기 출력 응답을 공급하기 위한 외부 인터페이스를 포함하고, 상기 적어도 하나의 외부 계층 구성요소가 취약한 상기 악의적인 프로세스는 상기 소스와 상기 외부 인터페이스 사이의 상기 입력 챌린지 및/또는 상기 출력 응답의 인터셉트 및 조작을 포함하는,
    디바이스.
  7. 제6항에 있어서, 상기 소스는 상기 디바이스에 로컬이고, 상기 외부 인터페이스는 네트워크를 통한 전송 없이 상기 입력 챌린지를 수신하도록 동작 가능한,
    디바이스.
  8. 제6항에 있어서, 상기 소스는 상기 디바이스로부터 원격이고, 상기 외부 인터페이스는 네트워크를 통해 상기 소스로부터 상기 입력 챌린지를 수신하도록 동작 가능한,
    디바이스.
  9. 제6항 내지 제8항 중 어느 한 항에 있어서, 상기 디바이스는 전용 PUF 디바이스를 포함하는,
    디바이스.
  10. 제1항 내지 제8항 중 어느 한 항에 있어서, 상기 적어도 하나의 외부 계층 구성요소는 상기 디바이스의 상기 하우징 내의 프로세서 상에서 실행되는 애플리케이션을 포함하고, 상기 애플리케이션은 상기 입력 챌린지를 생성하도록 구성되고, 상기 적어도 하나의 외부 계층 구성요소가 취약한 상기 악의적인 프로세스는 상기 입력 챌린지를 조작하기 위해 상기 애플리케이션과 동일한 프로세서 상에서 실행되는 멀웨어를 포함하는,
    디바이스.
  11. 제10항에 있어서, 상기 내부 인터페이스 로직은 상기 애플리케이션과는 별개의 프로세서 상에서 실행되도록 배열되는,
    디바이스.
  12. 제10항에 있어서, 상기 내부 인터페이스 로직은 상기 애플리케이션과 동일한 프로세서 상에서 실행되지만, 보안 프로세서의 특권 도메인(privileged domain)에서 실행되도록 배열되는 반면, 상기 애플리케이션은 애플리케이션 도메인에서 실행되는,
    디바이스.
  13. 제10항 내지 제12항 중 어느 한 항에 있어서, 상기 디바이스는 EDR(event data recorder)을 포함하고, 상기 애플리케이션은 EDR 애플리케이션을 포함하는,
    디바이스.
  14. 제13항에 있어서, 상기 애플리케이션은 상기 EDR이 모니터링하도록 구성된 시스템의 결과를 생성하도록 구성되고, 상기 EDR은 상기 결과 및 상기 출력 응답을 상기 결과에 매핑하는 태그를 레코딩하도록 구성되는,
    디바이스.
  15. 제14항에 있어서, 상기 태그는: 상기 결과에 상기 출력 응답을 서명함으로써 생성된 암호 서명; 또는 상기 결과 및 상기 출력 응답의 함수로서 생성된 HMAC(hash-based message authentication code)를 포함하는,
    디바이스.
  16. 제14항 또는 제15항에 있어서, 상기 입력 챌린지는, 모니터링되는 상기 시스템의 상태를 나타내는, 상기 애플리케이션에 의해 사용되는 의미 있는 데이터를 포함하는,
    디바이스.
  17. 제16항에 있어서, 상기 결과는 상기 데이터에 의존하는,
    디바이스.
  18. 제13항 내지 제17항 중 어느 한 항에 있어서, 상기 EDR은 차량을 위한 EDR이고, 상기 EDR이 모니터링하도록 구성되는 상기 시스템은 상기 차량의 시스템을 포함하는,
    디바이스.
  19. 제1항 내지 제18항 중 어느 한 항에 있어서, 상기 하나 이상의 외부 계층 구성요소는 상기 PUF 모듈과 동일한 하우징에서 구현되는,
    디바이스.
  20. 제1항 내지 제19항 중 어느 한 항에 있어서, 상기 PUF 모듈은 확장된 PUF 모듈을 포함하고 이로써 상기 입력 챌린지는 2차 챌린지이고 상기 출력 응답은 2차 응답이고; 그리고 상기 내부 PUF 인터페이스 로직은 1차 응답을 생성하기 위해 챌린지를 상기 PUF에 입력하고, 상기 1차 응답 및 상기 2차 챌린지의 결정론적 변환으로서 상기 2차 응답을 결정하도록 구성되는,
    디바이스.
  21. 제20항에 있어서, 상기 결정론적 변환은 해시 함수(hash function)를 포함하는,
    디바이스.
  22. 제1항 내지 제19항 중 어느 한 항에 있어서, 상기 인터페이스 로직은 상기 입력 챌린지를 상기 PUF에 직접 입력하고 상기 입력 응답의 함수로서 상기 PUF로부터 직접 상기 출력 응답을 수신하도록 구성되는,
    디바이스.
  23. 제1항 내지 제22항 중 어느 한 항에 있어서, 상기 로그 매체는 상기 디바이스의 로컬 메모리를 포함하는,
    디바이스.
  24. 제23항에 있어서, 상기 로컬 메모리는 변조 방지 메모리(tamperproof memory), 일회 기록(write-once) 메모리이고, 그리고/또는 상기 인터페이스 로직에 임베딩되는,
    디바이스.
  25. 제1항 내지 제24항 중 어느 한 항에 있어서, 상기 PUF 인터페이스 로직이 상기 레코드를 로깅하도록 구성되는 상기 로그 매체는 상기 디바이스 외부의 공개적으로 액세스 가능한 매체를 포함하는,
    디바이스.
  26. 제25항에 있어서, 상기 PUF 인터페이스 로직이 상기 레코드를 로깅하도록 구성되는 상기 공개적으로 액세스 가능한 매체는 블록체인을 포함하는,
    디바이스.
  27. 제1항 내지 제26항 중 어느 한 항에 있어서, 상기 내부 PUF 인터페이스 로직은, 개별 입력 챌린지의 입력에 응답하여, 상기 레코드의 로깅을 실시간으로 수행하도록 구성되는,
    디바이스.
  28. 제1항 내지 제27항 중 어느 한 항에 있어서, 상기 내부 PUF 인터페이스 로직은, 주기적 시간 윈도우의 각각의 인스턴스 동안 수신된 임의의 입력 챌린지 및/또는 생성된 출력 응답을 주기적으로 로깅하도록 구성되는,
    디바이스.
  29. 제28항에 있어서, 적어도 제23항, 제25항 및 제27항에 종속할 때, 상기 내부 PUF 인터페이스 로직은 상기 개별 입력 챌린지의 입력에 응답하여 상기 로컬 메모리에 상기 레코드를 실시간으로 로깅하고, 그리고 또한 상기 공개적으로 액세스 가능한 매체에 대한 주기적 로깅을 수행하도록 구성되는,
    디바이스.
  30. 제29항에 있어서, 상기 로깅 메커니즘은, 일단 상기 공개적으로 액세스 가능한 매체에 로깅되면, 상기 로컬 메모리로부터 상기 로깅된 챌린지 및/또는 응답을 주기적으로 클리어하도록 추가로 구성되는,
    디바이스.
  31. 제25항 또는 제25항에 종속하는 임의의 후속항에 있어서, 상기 로깅 메커니즘은, 상기 개별 입력 챌린지의 입력에 응답하여, 상기 레코드를 상기 공개적으로 액세스 가능한 매체에 실시간으로 로깅하도록 구성되는,
    디바이스.
  32. 제1항 내지 제31항 중 어느 한 항에 있어서, 상기 내부 PUF 인터페이스 로직은 적어도 상기 입력 챌린지의 레코드를 로깅하도록 구성되는,
    디바이스.
  33. 제1항 내지 제32항 중 어느 한 항에 있어서, 상기 내부 PUF 인터페이스 로직은 적어도 상기 출력 응답의 레코드를 로깅하도록 구성되는,
    디바이스.
  34. 제1항 내지 제33항 중 어느 한 항에 있어서, 상기 로깅 메커니즘은, 상기 레코드를 포함하는 패킷의 적어도 일부에 적용된 상기 로깅 메커니즘의 암호 키에 기초하여 생성된 서명을 더 포함하는 상기 패킷으로, 상기 레코드의 로깅을 위해, 상기 레코드를 출력하도록 구성되는,
    디바이스.
  35. 제34항에 있어서, 적어도 제26항에 종속할 때, 상기 패킷은 블록체인 트랜잭션을 포함하고, 상기 레코드는 상기 블록체인 트랜잭션의 출력에 포함되고, 상기 서명은 상기 트랜잭션의 입력에 포함되는,
    디바이스.
  36. 제1항 내지 제35항 중 어느 한 항의 디바이스를 사용하는 방법으로서,
    입력 챌린지 및/또는 출력 응답의 레코드가 상기 로그 매체에 로깅된 후, PUF 모듈로 하여금 후보 응답을 생성하게 하고 상기 후보 응답을 외부 계층의 비보안 채널을 통해 리턴하게 하기 위해, 후보 챌린지를 상기 비보안 채널을 통해 디바이스에 입력하는 단계;
    상기 로그 매체에 로깅된 원래 입력 챌린지의 레코드에 대해 상기 후보 챌린지를 체크하고, 그리고/또는 상기 로그 매체에 로깅된 원래 출력 응답의 레코드에 대해 상기 후보 응답을 체크함으로써 조작의 증거를 체크하는 단계를 포함하는,
    방법.
  37. 제36항에 있어서, 상기 체크하는 단계는 적어도, 상기 후보 챌린지가 상기 로그 매체에 레코딩된 입력 챌린지의 레코드와 매칭한다는 것을 체크하는 단계를 포함하는,
    방법.
  38. 제36항 또는 제37항에 있어서, 상기 내부 PUF 인터페이스 로직은 상기 후보 응답의 레코드를 로깅하도록 추가로 구성되고, 상기 체크하는 단계는 적어도, 상기 후보 응답의 상기 로깅된 레코드가 상기 디바이스에 대한 입력으로서 상기 후보 응답과 매칭한다는 것을 체크하는 단계를 포함하는,
    방법.
  39. 제35항 내지 제38항 중 어느 한 항에 있어서, 상기 체크하는 단계는 적어도, 상기 후보 응답이 상기 로그 매체에 레코딩된 상기 원래 출력 응답의 레코드와 매칭한다는 것을 체크하는 단계를 포함하는,
    방법.
  40. 제36항 내지 제39항 중 어느 한 항에 있어서, 상기 방법은 제14항의 디바이스 또는 제14항에 종속하는 청구항의 임의의 디바이스를 사용하는 방법이고, 상기 방법은:
    후보 결과에 기초하여 태그를 검증함으로써 상기 디바이스가 상기 결과를 생성한 디바이스임을 검증하는 단계를 포함하는,
    방법.
  41. 컴퓨터 장비로서,
    하나 이상의 메모리 유닛을 포함하는 메모리; 및
    하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고, 상기 메모리는 상기 프로세싱 장치 상에서 실행되도록 배열된 코드를 저장하고, 상기 코드는 프로세싱 장치 상에 있을 때 제36항 내지 제40항 중 어느 한 항의 방법을 수행하도록 구성되는,
    컴퓨터 장비.
  42. 비일시적 컴퓨터 판독 가능 매체 상에서 구현되고, 하나 이상의 프로세서 상에서 실행될 때 제36항 내지 제40항 중 어느 한 항의 방법을 수행하도록 구성된 컴퓨터 프로그램.
  43. 컴퓨터-구현 방법으로서, 제1 엔티티에 의해:
    블록체인 상에 레코딩될 제1 메시징 트랜잭션을 전송하는 단계 ― 상기 제1 메시징 트랜잭션은 제1 메시지, 및 제2 엔티티가 상기 블록체인 상에서 상기 제1 메시지를 식별할 수 있도록 상기 제1 메시지를 상기 제2 엔티티에 보내는 개개의 정보를 포함함 ― ;
    상기 제1 메시지가 조작 없이 상기 블록체인 상에 레코딩되었음을 체크하기 위한 질의를 제출하는 단계; 및
    상기 제1 메시지가 상기 질의에 따라 조작 없이 상기 블록체인 상에 레코딩된 것으로 결정된다는 조건 하에, 상기 블록체인 상에 레코딩될 제2 메시징 트랜잭션을 전송하는 단계 ― 상기 제2 메시징 트랜잭션은 제2 메시지, 및 상기 제2 엔티티가 상기 블록체인 상에서 상기 제1 메시지를 식별할 수 있도록 상기 제2 메시지를 상기 제2 엔티티에 보내는 개개의 정보를 포함함 ― 를 포함하는,
    컴퓨터-구현 방법.
  44. 제43항에 있어서, 상기 제1 메시징 트랜잭션은 제1 자금 트랜잭션의 출력을 가리키는 입력을 포함하고, 상기 제2 메시징 트랜잭션은 제2 자금 트랜잭션의 출력을 가리키는 입력을 포함하고, 어떠한 입력도 상기 제1 메시징 트랜잭션의 임의의 출력을 가리키지 않는,
    컴퓨터-구현 방법.
  45. 제43항 또는 제44항에 있어서,
    상기 제1 메시지 및 상기 제2 메시지는 2개 이상의 메시지의 시퀀스에서의 연속적인 메시지이고, 상기 제1 메시지 및 상기 제2 메시지 각각은 상기 시퀀스 내에 연관된 인덱스를 갖고, 상기 제1 메시지 및 상기 제2 메시지 각각은 상기 블록체인 상에 레코딩되도록 상기 제1 엔티티에 의해 개개의 메시징 트랜잭션으로 전송되고, 각각의 메시징 트랜잭션은 상기 제2 엔티티가 상기 블록체인 상에서 상기 메시지를 식별하는 것을 가능하게 하는 개개의 정보를 포함하고;
    각각의 메시지 내의 상기 개개의 정보는 i) 상기 연관된 인덱스 및 ii) 상기 시퀀스 내의 첫 번째 플래그 또는 선행 플래그의 함수인 플래그를 포함하고, 상기 함수의 형태는 상기 제1 엔티티 및 상기 제2 엔티티 각각에 알려지고; 그리고
    상기 방법은 상기 제1 엔티티 및 상기 제2 엔티티가, 상기 함수의 형태, 상기 첫 번째 플래그 및 각각의 메시지의 인덱스에 기초하여, 상기 제1 메시지에 대한 상기 플래그에 동의하고, 이로써 상기 제1 엔티티 및 상기 제2 엔티티가 상기 메시지의 시퀀스를 사용하여 상기 블록체인을 통해 후속적으로 통신하는 것을 가능하게 하는 초기 설정 페이즈를 포함하는,
    컴퓨터-구현 방법.
  46. 컴퓨터 장비로서,
    하나 이상의 메모리 유닛을 포함하는 메모리; 및
    하나 이상의 프로세싱 유닛을 포함하는 프로세싱 장치를 포함하고, 상기 메모리는 상기 프로세싱 장치 상에서 실행되도록 배열된 코드를 저장하고, 상기 코드는 프로세싱 장치 상에 있을 때 제43항 내지 제45항 중 어느 한 항의 방법을 수행하도록 구성되는,
    컴퓨터 장비.
  47. 비일시적 컴퓨터 판독 가능 매체 상에서 구현되고, 하나 이상의 프로세서 상에서 실행될 때 제43항 내지 제45항 중 어느 한 항의 방법을 수행하도록 구성된 컴퓨터 프로그램.
KR1020237031362A 2021-02-18 2022-01-18 디지털 보안 시스템 및 방법 KR20230146596A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2102283.5 2021-02-18
GB2102283.5A GB2604104A (en) 2021-02-18 2021-02-18 Digital security systems and methods
PCT/EP2022/050955 WO2022175001A1 (en) 2021-02-18 2022-01-18 Puf and blockchain based iot event recorder and method

Publications (1)

Publication Number Publication Date
KR20230146596A true KR20230146596A (ko) 2023-10-19

Family

ID=75339284

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237031362A KR20230146596A (ko) 2021-02-18 2022-01-18 디지털 보안 시스템 및 방법

Country Status (7)

Country Link
EP (1) EP4295343A1 (ko)
JP (1) JP2024506738A (ko)
KR (1) KR20230146596A (ko)
CN (1) CN116897381A (ko)
GB (1) GB2604104A (ko)
TW (1) TW202234269A (ko)
WO (1) WO2022175001A1 (ko)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1221120A4 (en) * 1999-09-10 2009-07-15 David Solo SYSTEM AND METHOD FOR PROVIDING CERTIFICATE VALIDATIONS AND OTHER SERVICES
GB201721036D0 (en) * 2017-12-15 2018-01-31 Ttp Plc Physically unclonable function device
WO2020183035A1 (es) * 2019-03-11 2020-09-17 Signe,S.A. Método de autenticación inclonable para verificación de identidad digital basado en dispositivos con chips de funciones físicamente inclonables

Also Published As

Publication number Publication date
CN116897381A (zh) 2023-10-17
US20240137228A1 (en) 2024-04-25
JP2024506738A (ja) 2024-02-14
GB202102283D0 (en) 2021-04-07
GB2604104A (en) 2022-08-31
TW202234269A (zh) 2022-09-01
WO2022175001A1 (en) 2022-08-25
EP4295343A1 (en) 2023-12-27

Similar Documents

Publication Publication Date Title
US20230360047A1 (en) Verification system and method
KR20230073236A (ko) 인증 시스템 및 방법
US20230362019A1 (en) Physically unclonable functions storing response values on a data store
US20240015033A1 (en) Physically unclonable functions
US20240202718A1 (en) Blockchain based system and method
US20230379175A1 (en) Challenge-response protocol based on physically unclonable functions
US20230370288A1 (en) Physically unclonable functions storing response values on a blockchain
KR20230146596A (ko) 디지털 보안 시스템 및 방법
US20240235857A9 (en) Puf and blockchain based iot event recorder and method
KR20240005845A (ko) 지갑 애플리케이션 인스턴스화, puf 디바이스를 사용하여 블록체인 트랜잭션들에 서명하기 위한 키 도출