TW202223793A

TW202223793A - 驗證系統及方法

Info

Publication number: TW202223793A
Application number: TW110132694A
Authority: TW
Inventors: 傑克Ｏ戴維斯; 克瑞格Ｓ萊特
Original assignee: 瑞士商區塊鏈授權股份有限公司
Priority date: 2020-09-30
Filing date: 2021-09-02
Publication date: 2022-06-16
Also published as: GB2599404A; EP4168909A1; JP2023545951A; WO2022069136A1; CN116324772A; US20230360047A1; GB202015498D0; KR20230078692A

Abstract

本案提供一種授權一目標方向一驗證方之一支付的電腦實施方法。該方法包含藉由該驗證方進行以下操作：執行一支付驗證以驗證該目標方之一資金源；以及執行一身分驗證以驗證該目標方之一身分。該身分驗證包含存取關聯地結合該目標方之該身分儲存於一資料存放區中的回應資料，該資料存放區實施於一受信任第三方之第三方電腦裝備中或實施於一同級間公佈媒體上，其中該回應資料包含a)對一質詢之一回應的一所儲存例項，或b)包含該回應之一變換的一認證。在該支付驗證及該身分驗證二者之輸出均為真的條件下授權該支付。

Description

驗證系統及方法

發明領域

本揭露內容係關於一種用於基於例如來自實體不可仿製之功能(PUF)的質詢及回應之系統執行驗證的程序。

發明背景

實體不可仿製之功能(PUF)為一個技術術語，其係指包含判定性但不可預測之實體現象的功能。PUF有時亦被稱作實體隨機功能。PUF接收被稱作「質詢」之輸入且取決於質詢及由PUF使用之實體現象而產生被稱作對應「回應」之輸出。PUF有時被分類成強及弱PUF。強PUF能夠針對大量不同質詢產生各別回應，通常能夠採用質詢之任何任意值。弱PUF可針對僅單個回應或少數回應而產生回應(通常，質詢無法採用任何任意值)。換言之，強PUF具有大量質詢-回應對(其具有大的質詢-回應空間)，而弱PUF具有單個質詢-回應對或有限數目個質詢-回應對(小或有限的質詢-回應空間)。根據一種定義，弱PUF之回應數目與質詢位元之數目呈線性關係，或更一般而言，回應數目之增長不會超過其他參數之線性增長。

強PUF之已知實例為光學PUF。舉例而言，光學PUF可包含雷射、光學感測器及固體光學介質，該固體光學介質中設置有氣泡或其他此類人工製品。雷射以可控角度照射穿過光學介質以產生繞射或散射圖案(其為介質中之氣泡或人工製品的效應)。感測器經配置以感測此圖案。質詢為雷射之角度，且回應係基於感測到之圖案而產生。

弱PUF之實例為SRAM PUF。在此狀況下，質詢為接通靜態隨機存取記憶體(SRAM)。歸因於一個SRAM與另一個之間的微小製造差異，SRAM胞元接著在通電時將恰好進入0/1之獨特型樣，因此形成個別SRAM之特性指紋(fingerprint)。PUF經組配以在通電時輸出此特性指紋作為回應。

PUF可用作產生諸如供用於密碼編譯演算法(例如，用於對文件進行簽名或加密)中之金鑰的手段。PUF之另一應用為識別裝置，諸如併有PUF之電腦裝置。若先前已判定對給定質詢之預期回應，則驗證方稍後可用該質詢來質詢目標裝置且檢查其是否給出預期回應，且藉此檢查目標裝置是否為與預期回應相關聯之裝置。

因為質詢回應空間有限，至弱PUF之輸入-輸出(i/o)介面往往會僅限於一方或限於數方(例如，僅一方或有限數目個受信任方可在實體上或法律上被授予對PUF之存取權，或至PUF之介面可受密碼保護，或其類似者)。亦即，僅所討論之一或多方可存取提交質詢所需的至PUF之輸入及供收回回應之輸出。另一方面，對於強PUF，至強PUF之i/o介面可廣泛地用於大量或無限數目方，並非該等方中之全部皆必須為已知或受信任方。原因在於質詢回應空間足夠大以使得敵手無法列舉所有的質詢-回應對，且因此敵手自由存取PUF之能力不應由於允許列舉及欺騙PUF而損害其安全性，如弱PUF之狀況。

在不同的技術領域中，區塊鏈係指一種形式之分散式資料結構，由此在分散式同級間(P2P)網路(在下文被稱作「區塊鏈網路」)中之多個節點中之各者處維護區塊鏈之複本且廣泛地公佈該等複本。該區塊鏈包含資料區塊鏈，其中各區塊包含一或多個交易。除所謂的「比特幣基地(coinbase)交易」以外，各交易亦指回至序列中之先前交易，該序列可橫跨一或多個區塊，追溯至一或多個coinbase交易。下文進一步論述coinbase交易。經提交至區塊鏈網路之交易包括於新區塊中。新區塊係藉由常常被稱作「挖掘(mining)」之程序創建，該程序涉及多個節點中之各者競爭以執行「工作量證明」，亦即，基於等待包括於區塊鏈之新區塊中的有序及經驗核未決交易之所定義集合的表示而解決密碼編譯難題。應注意，可在一些節點處修剪區塊鏈，且可經由僅公佈區塊標頭來達成區塊之公佈。

區塊鏈中之交易可用於以下目的中之一或多者：傳送數位資產(亦即，數個數位代幣)；對虛擬化分類帳或註冊表中之一組條目進行排序；接收及處理時戳條目；及/或按時間對指標索引進行排序。亦可利用區塊鏈以便對區塊鏈之上的額外功能性分層。舉例而言，區塊鏈協定可允許將額外使用者資料或資料之索引儲存於交易中。對於可儲存於單個交易內之最大資料容量不存在預先指定之限制，且因此可併有愈來愈複雜之資料。舉例而言，此可用於將電子文件或音訊或視訊資料儲存於區塊鏈中。

區塊鏈網路之節點(其常常被稱作「挖掘者」)執行稍後將更詳細描述之分散式交易註冊及驗證程序。總之，在此程序期間，節點驗核交易且將其插入至區塊範本中，針對該區塊範本，該等交易嘗試識別有效的工作量證明解決方案。一旦發現了有效的解決方案，便將新區塊傳播至網路之其他節點，因此使得各節點能夠在區塊鏈上記錄新區塊。為了將交易記錄於區塊鏈中，使用者(例如，區塊鏈用戶端應用程式)將交易發送至網路之一個節點以傳播。接收交易之節點可競相尋找將經驗核交易併入至新區塊中之工作量證明解決方案。各節點經組配以實行同一節點協定，其將包括交易有效之一或多個條件。無效交易將不傳播亦不併入至區塊中。假設交易經驗核且藉此經接受至區塊鏈上，則交易(包括任何使用者資料)將因此在區塊鏈網路中之各節點處作為不可變的公共記錄進行註冊及編索引。

成功地解決工作量證明難題以創建最新區塊之節點通常獲得被稱為「coinbase交易」之新交易的獎勵，該新交易分發一定金額之數位資產，亦即，數個代幣(token)。對無效交易之偵測及拒絕係藉由競爭節點之動作實行，該等競爭節點充當網路之代理且經激勵以報告且阻止不法行為。資訊之廣泛公佈允許使用者連續地稽核節點之效能。僅公佈區塊標頭允許參與者確保區塊鏈之持續完整性。

在「基於輸出」之模型(有時被稱作基於UTXO之模型)中，給定交易之資料結構包含一或多個輸入及一或多個輸出。任何可支出輸出皆包含一元素，該元素指定可自進行中之交易序列導出的數位資產之金額。可支出輸出有時被稱作UTXO (「未支出交易輸出」)。該輸出可進一步包含鎖定指令碼，該鎖定指令碼指定未來兌換該輸出之條件。鎖定指令碼係定義驗核及轉移數位代幣或資產所必需之條件的述詞。交易(除coinbase交易以外)之各輸入包含指向先前交易中之此輸出的指標(亦即，參考)，且可進一步包含用於解除鎖定所指向輸出之鎖定指令碼的解除鎖定指令碼。因此，考慮一對交易，將其稱為第一交易及第二交易(或「目標」交易)。第一交易包含至少一個輸出，該至少一個輸出指定數位資產之金額且包含定義解除鎖定該輸出之一或多個條件的鎖定指令碼。第二目標交易包含至少一個輸入，該至少一個輸入包含指向第一交易之輸出的指標及用於解除鎖定第一交易之輸出的解除鎖定指令碼。

在此模型中，當第二目標交易經發送至區塊鏈網路以在區塊鏈中傳播及記錄時，在各節點處應用之有效性準則中之一者將為解除鎖定指令碼符合定義於第一交易之鎖定指令碼中的所有一或多個條件。另一準則將為第一交易之輸出尚未由另一較早有效交易兌換。根據此等條件中之任一者發現目標交易無效的任何節點皆將不會傳播該目標交易(作為有效交易，但可能會註冊無效交易)，亦不將該目標交易包括於新區塊中以記錄於區塊鏈中。

交易模型之替代類型為基於帳戶之模型。在此狀況下，各交易皆不會藉由返回參考過去交易序列中之先前交易之UTXO來定義待轉移的金額，而是參考絕對帳戶餘額。所有帳戶之當前狀態由與區塊鏈分離之節點儲存，且不斷更新。

發明概要

根據本文中所揭示之一個態樣，提供一種授權目標方向驗證方之支付的電腦實施方法，該方法包含藉由驗證方進行以下操作：執行支付驗證以驗證目標方之資金源且在目標通過支付驗證之條件下輸出真之結果；以及執行身分驗證以驗證目標方之身分。該身分驗證包含：存取關聯地結合目標方之身分儲存於資料存放區中之回應資料，該資料存放區實施於受信任第三方之第三方電腦裝備中或實施於同級間公佈媒體上，其中該回應資料包含a)對質詢之回應的所儲存例項，或b)包含回應之變換的認證；將包含質詢之請求發送至目標方且作為回應，接收回回應之另一例項；以及執行比較且在匹配之條件下輸出真之結果，該比較包含a)比較回應之所儲存例項與回應之另一例項，或b)比較認證與應用於回應之另一例項的相同變換。在支付驗證及身分驗證二者之輸出均為真的條件下授權支付。

較佳實施例之詳細說明

用於人類及機器二者之諸如金鑰產生系統及隱私保護身分系統的系統之穩健性可藉由涉及實體不可仿製之功能(PUF)來改善。此等可為彼此互動或與諸如區塊鏈之公共系統的多方及/或自主機器。

基於實體系統且藉由假設實體裝置之製造中的隨機、不可判定且不可重複之變化來保護的此等功能可用於強化在人類身分與其裝置之間建立的連結或另外為裝置自身建立不可偽造的唯一身分。

在文獻中，將PUF歸類成弱類型及強類型，根據其相異屬性進行歸類。根據下文的一個態樣，提供一種通用延伸PUF (ePUF)架構，其用於描述具有二種此等類型之PUF之益處的實用PUF裝置；亦即，ePUF可產生待用於應用中之大量質詢-回應對，同時保持實用且具成本效益的實施。

更一般而言，本文中揭示與PUF以及質詢-回應對之管理相關的各種態樣。可個別地或以任何組合使用此等不同態樣。此等態樣包括例如： I. 用於擴展PUF之質詢-回應空間的擴展PUF； II. 用於藉由使用ePUF裝置建立人類及/或裝置身分之一組區塊鏈不可知協定； III. 用於藉由利用區塊鏈來改善此等身分協定之架構； IV. 用於質詢-回應對之輕量級儲存的技術；以及 V. ePUF裝置對多種問題之一組新穎應用，諸如實施KYC以用於簡化付款驗證(SPV)程序及用於裝置之可驗證運算。 1. 實體不可仿製之功能(PUF)- 預備知識

實體不可仿製之功能(PUF)一詞係指充當通用隨機功能之一類實體系統及裝置。此等PUF之唯一特徵在於其實體屬性，常常為亞微米級，其意謂各者可藉由用實體刺激探測彼等屬性來唯一地識別及驗證。在高層級處，吾人可將PUF視為將質詢映射至回應之功能；質詢及回應之對常常被稱作質詢 - 回應對(CRP)。吾人可使用以下記法來將此映射

描述為：

其中

分別指示質詢及回應，且

為可由PUF產生之形式

的所有質詢-回應對之集合。

PUF之唯一實體屬性通常為在製造諸如矽晶片之實體裝置中所固有的隨機程序變化之結果。關於PUF，通常假設： 1. 難以藉由任何形式之分析來完全判定實體系統之參數；以及 2. 實體系統之參數不為任何方所知，包括用作PUF之裝置的原始製造商。此假設常常被稱作 製造商阻力。

此等假設允許使用PUF以產生對任意質詢之不可預測但判定性的回應。此質詢-回應程序將PUF視為實體黑箱，如圖3中所說明。

圖3展示模型化為實體黑箱之PUF 302。提交方103S將質詢C作為輸入提交至PUF 302，且作為回應，PUF 302產生對應回應R。提交方提交來自諸如提交方之電腦裝置(未圖示)之裝置的質詢，該裝置可為與實施PUF 302自身之裝置相同或不同的裝置。

提交方103S可為作為設置階段(稍後論述之實例)之部分而產生質詢-回應(CR)對以建立連結至目標方或裝置之身分的預期回應之集合的一方。或者，提交方103S可為驗證方，該驗證方在稍後驗證階段中提交質詢以便驗證所產生之回應匹配預期回應，因此驗證包含PUF 302之目標裝置或擁有PUF之目標方的身分。

在另一實例情境中，提交方103S可為希望使用所產生之回應作為金鑰或作為用於產生金鑰之種子以供用於諸如區塊鏈應用之密碼編譯應用中(例如，用於對區塊鏈交易進行簽名)的一方。

圖4展示包含至PUF 302之介面之實例的系統。該系統包含處理器402及PUF 302。該介面包含介面邏輯404，該介面邏輯儲存於記憶體中且經配置以在處理器402上運行。上面儲存介面邏輯404之記憶體可包含使用一或多個儲存媒體(例如，磁性媒體，諸如磁碟或磁帶；或電子媒體，諸如ROM、EPROM、EEPORM、快閃記憶體、SRAM、DRAM等)之一或多個記憶體單元。處理器402可包含一或多個處理單元(例如，通用處理器，諸如CPU；或特殊應用或加速器處理器，諸如GPU、DSP或密碼處理器)。亦不排除介面邏輯404可替代地部分或完全實施於專用硬體電路系統或諸如PGA或FPGA之可組配或可重組配電路系統中。

提交方103S使用裝置(未圖示)經由介面邏輯404將質詢C提交至PUF 302。由提交方103S使用之裝置可例如為電腦裝置，其為外部電腦裝置或供實施處理器402之同一電腦裝置。PUF 302接著經由介面邏輯404將對應回應R傳回至提交方302之裝置。在稍後更詳細論述之一些實施例中，介面邏輯404可包含存取控制邏輯406，該存取控制邏輯將對PUF 302之存取僅限於某些方，例如可呈現諸如密碼、PIN或生物特徵資訊之經辨識憑證的彼等方。及/或至包含處理器402之裝置的實體介面可受限制，諸如藉由位於僅經授權人員能夠進入之房間或綜合設施中或保存在上鎖的盒子或櫃子中。然而，在替代系統中，介面邏輯404可供任何方用於使用質詢進行查詢。

PUF之質詢-回應程序允許藉由自所選擇回應提取此等質詢來產生偽隨機資料值。舉例而言，PUF可用作金鑰產生器以提取待用於密碼編譯中之隨機可重複資料。應注意，PUF 302以判定性且可重複的方式起作用，使得當在多個分離的場合給出相同質詢時，PUF將產生相同回應。

存在可用作PUF之數個不同實體系統，且存在使用此等系統之PUF的許多不同實施。PUF之說明性實例為含有氣泡之光學介質，其在由雷射探測時產生回應繞射或「斑點」圖案，該圖案由(i)雷射之位置及(ii)光學介質之小尺度參數以判定性方式判定。 1.1. PUF 之類別

1.1.1 弱 PUF ：弱PUF之特徵在於具有小的質詢-回應空間，且許多PUF僅具有單個質詢使得CRP空間之大小為

。一般而言，弱PUF之質詢-回應空間被視為

階，其中

為PUF中經受不可控製造變化之組件的數目。

在弱PUF之狀況下，通常亦假設對PUF之回應的存取受限制。此係因為：由於弱PUF服務之CRP的數目較少，敵手可在合理時間內列舉所有此類對且可因此模仿或「欺騙」PUF之行為。當論述弱PUF之行為時，此限制有時被稱作 受限質詢 - 回應介面。

此等屬性使得弱PUF最適合於在密碼編譯應用中用作金鑰產生器，其中由PUF產生之一個(或幾個) CRP可用作用於密碼編譯操作之秘密金鑰，諸如用於對裝置上非依電性記憶體(NVM)進行加密，或供用作HMAC對稱金鑰。在此類狀況下，自PUF之回應導出的金鑰必須保密且僅為裝置之擁有者所知，以確保所執行之密碼編譯程序以及PUF自身的安全性。

弱PUF之突出且廣泛實施之實例為 SRAM PUF，其中「SRAM」一詞係指「靜態隨機存取記憶體」。SRAM PUF之設計利用SRAM晶片之「加電」狀態的變化，由於當對晶片加電時晶片中之SRAM胞元處於「0」或「1」狀態的變化，該等晶片各自具有唯一指紋。

在此狀況下，PUF構造被視為弱的，此係因為存在探測PUF (亦即，藉由對SRAM晶片加電)之一個固定模式，且因此僅存在單個CRP。在此狀況下，唯一的「質詢」向SRAM晶片供應電力，且回應為自其加電狀態導出的唯一指紋。為了確保回應之秘密性，亦可使用在使用SRAM PUF之裝置上現有的記憶體存取控制策略或機制或用於裝置上之替代機制來實施存取控制。

諸如在SRAM PUF之狀況下，一些PUF實施之特徵為在由PUF產生之回應中使用錯誤校正以確保相同質詢將以條件及時間不變的方式產生相同回應。熟習此項技術者已知此類錯誤校正技術之細節。在一些狀況下，錯誤校正程序可能需要最初「註冊」PUF裝置，以提供輔助資料源，該輔助資料源與稍後按需求產生之回應組合以促進錯誤校正。

1.1.2. 強 PUF ：相比於弱PUF，強PUF之特徵在於具有可利用之可能質詢-回應對(CR對或CRP)之大空間。CRP之此大空間意謂敵手在多項式時間內列舉強PUF域內之所有質詢-回應對被視為不可行的。此屬性意謂強PUF一般可具有不受保護的質詢-回應介面，此係因為敵手自由存取PUF之能力將不會由於允許列舉及欺騙PUF而損害其安全性，如弱PUF之狀況。甚至自知曉Φ _F之大子集的敵手之視角，此類別之PUF亦據稱為產生不可預測的回應，此意謂強PUF之作用更類似於具有大域之密碼編譯雜湊函數。

然而，存在對強PUF之限制：當呈現有質詢C時，PUF應僅給出回應R，且在程序中不應洩漏關於PUF之內部工作或操作的其他資訊。此限制係為了緩解各種分析攻擊，由此敵手可試圖特性化支援PUF之行為的實體系統。此等在文獻中常常被稱作模型化攻擊。

類似於弱PUF，一些強PUF構造可依賴於錯誤校正技術以確保由裝置產生之回應的準確度。

強PUF之主要現有應用為使用固有的質詢-回應機制來促進系統鑑認及識別。此等機制依賴於涉及直接在二方之間創建CRP作為共用秘密的協定，且常常需要至少一方事先產生CRP之表(初始設置)以用作另一方之鑑認符記。

強PUF實施之最早實例中之一者為光學PUF系統。在此構造中，PUF包含光學介質，該光學介質含有由於製造變化而產生的隨機分佈之實體缺陷，該等缺陷使入射光散射。

此PUF構造能夠由導向光學散射介質之雷射光束探測。在此狀況下，入射光束之方向及偏振形成質詢，且觀察到之散射圖案被視為PUF回應。

然而，此強PUF構造實施起來複雜，此係因為量測裝置與PUF裝置之其餘部分分離且亦難以直接與半導體組件整合。除與設備自身相關聯之成本及配置之便攜性缺乏以外，此亦降低其在日常應用中之實用性。

此後已提議被稱為仲裁PUF (APUF)之電氣整合強PUF，其克服此等問題中之一些。此構造利用信號多工且利用電氣組件中之執行階段延遲。已並行地提議許多其他強PUF構造，但許多構造缺乏廣泛使用之實際適用性，且許多構造具有關於安全性及潛在攻擊向量之相關聯弱點。舉例而言，高度有問題的潛在攻擊為中間人攻擊，由此攻擊者可攔截以明文提交之質詢且欺騙經證實運算。

1.1.3. 受控 PUF ：被稱為受控PUF (CPUF)之第三類別之PUF改善現有的強PUF構造，但使用其作為建置區塊。此等PUF採用強PUF且應用限制對PUF之存取的額外控制邏輯，此將其與原本可能具有不受保護之質詢-回應介面的非受控強PUF區分開。

如圖4中所展示，應用於現為較大PUF裝置之部分之PUF的控制邏輯406可調節對PUF 302自身之存取。此意謂控制邏輯組件406可限制向PUF呈現哪些質詢以及控制如何向使用者揭露後續回應。

在CPUF構造中，控制邏輯組件406較佳應嵌入於強PUF組件內或由該組件包封。根據CPUF之一種定義，若可僅經由以不可分離的方式實體地連結至PUF的演算法存取，則據稱PUF受控制(亦即，嘗試避開演算法將導致破壞PUF)。此嵌入會使得控制邏輯之探測變得顯著更困難。

此將在PUF組件與控制邏輯組件之間建立互益的關係，使得各組件減輕對另一組件之一種類型的攻擊。亦即，將控制邏輯封裝於PUF裝置自身內會保護控制邏輯免受實體或侵入性攻擊，此係因為此等攻擊將會不可挽回地損壞PUF組件且更改其回應，而控制邏輯自然會保護PUF組件免受協定層級攻擊以提取CRP或關於PUF自身底層之內部實體系統的其他資訊。

CPUF之應用與強PUF幾乎相同，但可用更穩健的方式達成。特定而言，藉由上文所概述之協定，可易於達成經證實運算及執行證明。

延伸強仲裁PUF (APUF)之設計的CPUF之早期實例需要控制邏輯以已描述之方式與APUF自身交織在一起，使得控制邏輯及APUF相互保護彼此以免受不同類型之攻擊。受控APUF設計藉由併有系統之瞬態回應而自來自積體電路(IC)之單個靜態回應產生大的CRP集合。

受控PUF之另一已知實例為PUF-FSM構造。此構造包含強PUF (實際上為APUF)結合有限狀態機(FSM)，該有限狀態機充當限制對APUF組件自身之質詢-回應介面之存取的控制邏輯。 1.2. 論述

1.2.1.實用性：在文獻中已確認，產生既實用又輕量，同時亦可與標準互補金屬氧化物半導體(CMOS)組件整合的強PUF為極具挑戰性的。相比之下，諸如SRAM PUF之弱PUF生產起來低廉且可與積體電路架構輕鬆組合。

1.2.2. 對 PUF 之攻擊 ：存在已提議及研究之數個不同攻擊，其中不同攻擊可能針對特定PUF構造或類別。如下列出大部分廣泛已知之攻擊類型中的一些。 ● MITM攻擊-此等攻擊針對為不受控強PUF之PUF，其中敵手可攔截以明文提交之質詢以冒名頂替或欺騙PUF之回應，尤其在用於經證實運算時。 ● 模型化攻擊-此等攻擊已證明為諸如APUF之許多強PUF構造的漏洞。 ● 所選質詢攻擊-此等攻擊亦影響強PUF且為轉向CPUF架構之部分動機。

各種PUF設計亦存在其他問題，諸如在一些狀況下缺乏唯一性，此導致損害所討論之PUF系統之安全性的惡意探索。

1.2.3 安全模型 ：PUF構造之安全模型往往會共用一些類似性，諸如假設供產生其CRP之隨機程序或製造變化為製造商抗拒的且難以藉由分析手段來特性化PUF之實體系統。然而，用於三個主要PUF類別之安全模型亦存在一些差異。 ● 弱 PUF-弱PUF之安全性依賴於其CRP保密之假設，否則裝置可被列舉及冒名頂替。此意謂弱PUF可用於提供熵源及用於密碼編譯操作之彼熵的安全儲存，但實際的CRP回應資料自身不會在程序中公開揭露。 ● 強 PUF-強PUF之安全性取決於如下事實：其CRP空間在質詢位元之數目上往往呈指數，且因此在合理的時間範圍內列舉整個空間為不可行的。此意謂強PUF之CRP回應可由裝置揭露，此不同於弱PUF之狀況。 ● 受控 PUF-受控PUF之安全性由保護免受協定層級攻擊之控制邏輯與保護免受實體攻擊之PUF自身的組合判定。

強PUF之將其與弱PUF區分開的二個屬性如下。首先，強PUF具有大的CRP集合。此意謂強PUF具有大的質詢空間

，其中弱PUF通常僅具有可用於其的一個(或幾個)質詢。此外，強PUF被視為相對於任何及所有已知CRP為不可預測的。換言之，知曉任意數目個CRP在預測新質詢之回應上沒有優點。

其次，強PUF可具有不受保護的質詢-回應介面。假設給定強PUF不需要存取控制邏輯來限制對質詢-回應介面之存取。此意謂對PUF進行實體存取之任何方可應用質詢且任意地獲得回應，而無需揭露關於PUF或其實體屬性之任何額外資訊。

受控PUF具有受保護的質詢-回應介面，但亦具有大的質詢-回應空間，如強PUF。 2. 擴展 PUF (ePUF)

下文揭示用於藉由自基礎PUF 302之給定質詢-回應(CR)對產生多個次要CR對來擴展PUF之CR空間的系統及方法。此在本文中可被稱作「擴展PUF」或「ePUF」。此種想法可例如用於擴展僅具有一個或有限數目個固有CR對之弱PUF的質詢-回應空間，而無典型的強PUF機制(諸如，需要雷射、光學介質及感測器之光學PUF)之複雜性或不切實際性。然而，原則上，所揭示之技術更一般地可用於擴展任何基礎PUF (無論係弱的、強的、受控的或其他)之CR對的數目；或出於諸如混淆或可重用性之其他目的而變換任何PUF之CR對。

圖5A展示根據本文中所揭示之實施例的擴展PUF (ePUF) 500。ePUF 500包含組成基礎PUF 302，其可例如為習知的弱PUF。ePUF 500進一步包含變換函數502，例如雜湊函數，諸如密碼編譯雜湊函數(例如，SHA256等)。ePUF 500亦包含介面邏輯404'，該介面邏輯可類似於關於圖4所論述之介面邏輯404，但具有額外介接功能性。介面邏輯404'及變換函數502可實施於例如嵌入式韌體之軟體中，該軟體儲存於記憶體中且經配置以在處理器402 (諸如圖4中所展示，但運行介面404'及變換函數502之額外功能性)上運行。上面儲存介面功能404'及變換邏輯504之記憶體可包含使用一或多個儲存媒體(例如，磁性媒體，諸如磁碟或磁帶；或電子媒體，諸如ROM、EPROM、EEPORM、快閃記憶體、SRAM、DRAM、熔絲鎖存器等)之一或多個記憶體單元。運行介面功能及變換邏輯之處理器可包含一或多個處理單元(例如，通用處理器，諸如CPU；或特殊應用或加速器處理器，諸如GPU、DSP或密碼處理器)。亦不排除介面邏輯404'及/或變換函數502可替代地部分或完全實施於專用硬體電路系統或諸如PGA或FPGA之可組配或可重組配電路系統中。

介面邏輯404'操作性地耦接至變換函數502且任擇地亦耦接至基礎PUF 302。基礎PUF 302操作性地耦接至變換函數。介面邏輯404'經配置以自提交方103S (未展示於圖5A中)之例如電腦裝置的裝置接收輸入且將輸出提供至該裝置，該裝置可為在上面實施ePUF 500之相同裝置或外部裝置。提交方103S可為使用ePUF 500執行設置，產生質詢及預期回應之集合以連結至身分以供未來參考之一方；或可為稍後使用PUF以驗證所產生之回應是否匹配先前建立之預期回應的驗證方(或質詢產生回應以提供至驗證方)。在另一實例應用中，提交方103S可使用ePUF 500產生回應，以供用作金鑰或用作產生金鑰之種子。例如，此可用作密碼編譯金鑰以對訊息進行加密或簽名，例如對區塊鏈交易之一部分進行簽名。

基礎PUF 302可操作以產生「主要」回應Rw作為輸出，此對應於接收「主要」質詢Cw作為輸入。本文中之「主要」質詢-回應(CR)對係指基礎組成PUF 302之基礎或「原生」(亦即，固有)CR對。在一些實施例中，基礎PUF 302可能夠回應於單個質詢Cw而僅產生單個基礎(亦即，主要)回應Cw，如弱PUF。

在操作中，介面邏輯404'自提交方103S之裝置接收至少包含「次要」質詢Ci的質詢資料(質詢輸入)。此外，將主要(基礎)質詢Cw輸入至基礎PUF 302，以便產生主要(基礎)回應Rw。在實施例中，需要提交方103S將基礎質詢Cw包括於輸入至ePUF 500之質詢資料中，且介面邏輯404'將此基礎質詢投送至基礎PUF 302以便產生主要回應Rw。然而，在其他實施例中，不排除自諸如記憶體、熔絲鎖存器或專用電路系統之內部源將主要質詢Cw輸入至基礎PUF 302。無論如何，變換函數502皆經配置以接收以下各者作為輸入：a)如在來自提交方之輸入質詢資料中接收的次要質詢Ci；以及b)如由基礎PUF 302產生之主要回應Rw。變換函數502為經組配以將此等之組合以判定性方式映射至唯一的各別「次要」回應Ri上，該回應對應於輸入至變換函數502之Ci及Rw之特定組合。在次要質詢回應對係在主要(基礎)CR對之上分層、部分地基於主要回應Rw而產生的意義上，該等次要質詢回應對在本文中可被稱作「次要」的。其亦可被稱為「擴展層」或「補充」質詢及回應。

在實施例中，變換函數502包含雜湊函數，例如密碼編譯雜湊函數，諸如SHA或DSA雜湊函數。存在可使用雜湊函數之至少二種不同方式。首先，變換函數502包含原像之雜湊，其中該原像包含接收到之次要質詢Ci與所產生之主要回應的組合(例如，串接)。亦即，Ri = H(Ci||Rw)。或更一般而言，原像亦可包含其他元素，及/或除串接以外的另一形式之組合。

在第二替代方法中，變換函數502包含原像之雜湊，其中該原像包含接收到之次要質詢，且雜湊函數係用所產生之主要回應初始化。亦即，Ri = H(Ci)，其中H由Rw初始化。或再次更一般而言，H之原像亦包含其他元素，只要其至少包含Ci即可。由Rw初始化意謂原像至由雜湊函數H定義之輸出的映射自身將取決於Rw。而在先前狀況下，由H引起的原像至輸出之映射不取決於Rw，而是原像取決於Rw。亦即，在先前段落中，原像取決於Rw，且在此段落中，僅H取決於Rw。

仍更一般而言，原則上，可使用任何函數，只要對於待由ePUF 500容納之域中的各可能Ci，該函數以判定性方式且唯一地將Ci與Rw之組合映射至Ri之各別值上即可。

次要質詢Ci可採用數個不同可能值中之任一者，且變換函數502將會基於接收到之特定次要質詢Ci之值及主要回應Rw之值而及將組合映射至次要回應Ri之各別值。因此，ePUF 502能夠將給定主要(基礎)CR對之CR空間擴展至多個次要CR對。在實施例中，Ci可採用在由所使用之變數支援的值範圍內之任何任意值(例如，若變數為32位元整數，則其可採用2^32個值中之任一者)。

在一些實施例中，ePUF 500可能夠在替代操作模式中操作，如圖5B中所展示。在此狀況下，介面邏輯404'偵測到輸入質詢資料僅包含主要質詢Cw。作為回應，其將接收到之值Cw投送至基礎PUF 302，且將所得主要回應Rw投送回至提交方103S之裝置。換言之，在此實施例中，ePUF 500亦能夠在「傳統」或「非擴展」模式中操作。

任擇地，取決於應用，介面邏輯404'可包含存取控制邏輯406，該存取控制邏輯將存取限於僅有限數目個可能的提交方103S，諸如藉由僅向能夠呈現其辨識為映射至經授權方之憑證(例如，密碼、PIN或生物特徵輸入)的一方授予存取權。在此狀況下，ePUF 500可被視為一種形式之CPUF。替代地，至ePUF 500之實體介面可在法律上或實體上受保護，諸如藉由將包含ePUF 500之裝置保存於僅准許有限之一組合作方進入的房間或場所中或保存於上鎖的盒子、櫃子或房間中。在此狀況下，ePUF 500可被視為一種擴展的弱PUF。

替代對至PUF之介面的此類實體限制或除此類實體限制以外，存取亦可藉由限制對主要質詢之存取來限制。例如，目標方103T (稍後論述之「愛麗絲(Alice)」)可為唯一知曉Cw之一方。

然而，作為另一替代例，對介面邏輯404'之存取可能不受限制，例如任何方可經由網際網路自由地查詢介面邏輯。在此狀況下，ePUF 500可被視為藉由擴展弱基礎PUF機制創建之一種強PUF 502。

圖5A中所展示之配置提供在本文中被稱作擴展 PUF (ePUF)之新混合類別的PUF裝置，其通常可用作用於諸如稍後呈現之數個應用的架構。

ePUF可定義為實體裝置或系統，如圖5A中所展示，其結合地包含以下三個模組：基礎PUF 302，諸如固有弱PUF；變換函數502，諸如密碼編譯雜湊函數；以及介面邏輯模組404'。如所論述，ePUF 500可藉由引入諸如密碼編譯雜湊函數之變換函數404'而相對於常規PUF 302進行「擴展」，此係因為其將唯一質詢空間

之大小自用於基礎弱PUF 302之

增加至

，後者替代地由雜湊函數之選擇而非弱PUF之實體系統定界。

先前已探索實現將強PUF之大CRP空間與弱PUF自身之實用性組合的系統之想法。已知在組合操作中使用多個基於FPGA之弱PUF以產生具有強PUF之特性的系統。此處的意圖部分地為「擴展」基礎弱PUF之CRP空間。然而，此性質之現有構造在實踐中受限制。在上文所提及之FPGA設計的狀況下，系統必須建置於FPGA上且仍受制於相對較小的CRP空間(

)。

本文中所揭示之ePUF設計經設計為極輕量級的，此係因為其僅需要將介面邏輯組件404'及密碼編譯雜湊函數(或其他此類變換函數) 502添加至現有的弱PUF 302。舉例而言，若選擇SRAM PUF作為廣泛使用之弱PUF 302，則添加二個剩餘模組404'、502不應產生顯著的額外負荷，例如實施為軟體(例如，韌體)中之小型演算法或相對簡單之硬體電路系統片件。此外，ePUF 500之可能輸出的空間經擴展至所選擇之雜湊或變換函數502的範圍，該範圍顯著大於上述範圍。舉例而言，若選擇SHA-256雜湊函數，則可能輸出(及因此，CRP)之空間立即增加至

，且不需要比嵌入雜湊函數模組自身更進一步地縮放硬體額外負荷。

圖5A展示擴展PUF (ePUF) 500之示意性設計。使用 密碼編譯雜湊函數之實施例亦意謂ePUF 500具有其CRP不可預測之屬性，此亦為強PUF系統之狀況。

ePUF裝置之控制邏輯元件406亦可在此構造中通用。若此例如適合於應用，則控制邏輯406可簡單地實施為實體安全性，類似於SRAM PUF。

替代地，控制邏輯模組406可實施為軟體控制模組，該軟體控制模組類似於與CPUF一起使用之軟體控制模組，其中該軟體控制模組實際上嵌入於PUF裝置自身內以提供先前所論述之封裝的相互安全益處。然而，此處，將ePUF設計與CPUF之設計區分開的一點尤其在於不存在對以此方式實施之控制邏輯的嚴格要求。

不必假設對控制模組406之侵入性攻擊必然會更改ePUF設計中之弱PUF組件302的行為。實情為，可在逐狀況基礎上選擇此元件之實施。 2.1. 針對 ePUF 之 質詢及回應

可用以下方式定義對應於ePUF之質詢-回應對的集合

：

其中

為對應於弱PUF 302之基礎質詢及回應的特權CRP且其中映射

由弱PUF之唯一實體屬性定義。對

在本文中可被稱作ePUF之 基礎或主要對。相反地，映射

由針對ePUF選擇之密碼編譯雜湊函數定義。圖5A至圖5B展示自ePUF 500提取回應，其中(圖5B)質詢僅為Cw且(圖5A)質詢亦包含Ci。

在擴展PUF之一些實施例中，所有質詢

必須伴有基礎質詢

，且基礎回應

併入用於產生所有其他回應

之程序中，如圖5A中所展示。

圖5A中所描繪之用於使用ePUF產生通用CRP的程序經設計以藉由擴展此基礎秘密配對來使用基礎質詢-回應對

，該擴展係藉由將此基礎秘密配對應用於任何其他任意質詢

來進行。用於自ePUF產生CRP之演算法可針對特定用途進行定製，其限制條件為該演算法以判定性方式利用基礎對

。可如下編寫指示為

之此演算法的簡單實例。

輸入： 質詢1. 自使用者/用戶端獲得質詢。 2. 檢查

？ i. 若是： 1. 用

探測弱PUF模組以獲得

2. 設定

ii. 若否： 1. 將質詢分成

及

分量。 2. 用

探測弱PUF模組以獲得

3. 將

及

發送至雜湊函數模組。 4. 運算

5. 設定

3. 傳回回應 輸出： 回應

函數

為用於使用密碼編譯雜湊函數

運算雜湊摘要之通用函數。可用數種方式實施函數

，諸如藉由在簡單狀況下簡單地運算

，或其可藉由繁重運算

來實施，其中已使用值

作為雜湊函數

之初始向量。無論如何，

之輸出取決於

及

二者。

圖5A及圖5B中之圖式展示ePUF 500可配備有介面邏輯404'，該介面邏輯任擇地包含 控制邏輯模組406。在實施例中，在產生回應時採用二個可能路徑，其中在質詢僅為

時使用圖5B之路徑，且在質詢為伴有

之新值

時使用圖5A之路徑。此為判定性的。

所揭示之ePUF設計可用於提供以下優點及/或其他優點中之任一者。 ● 大CRP空間，其由所選擇之雜湊函數的域及範圍界定。 ● 將控制邏輯與PUF自身分離的靈活性。 ● 弱PUF之安全原語。

此意謂使用者可使用類似於CPUF裝置之ePUF裝置，但其中對PUF之受控存取包括以下二者：(I)安全地儲存弱PUF之基礎CRP

；以及(II)僅將對PUF裝置之實體存取限於預期使用者。在此模型中，基礎對

起主金鑰之作用，形式

之極大量其他CRP可自該主金鑰導出，且其中

可藉由外部或第三方提交。 2.2. ePUF 之應用

ePUF裝置之可能應用(使用案例)可廣泛地分類為至少二個主要類別： 1. 將身分連結至活動或運算操作；以及 2. 充當用於密碼編譯操作之金鑰產生器。

應用(1)最常由現有的強PUF實施，且(2)最常由現有的弱PUF實施。ePUF構造組合各者之屬性的事實意謂可將ePUF視為同樣適合於任一應用。在應用(1)中，一個優點在於，實務上，與大多數強或受控PUF相比，通常使用ePUF可更容易地實施此類應用。 3. 身分連結系統

在此章節中，揭示一種用於將人類或機器身分連結至PUF裝置之通用架構。

實施例可使用擴展 PUF (ePUF)。此處的意圖為制訂提供穩健但高度通用且靈活之身分系統的PUF架構，該系統可重用於許多不同的使用案例。吾人旨在在此構造中俘獲的屬性為： ● 與強PUF之空間相當的大CRP空間； ● 與弱PUF之實用性相當的實用性；以及 ● 比CPUF之控制邏輯更靈活的控制邏輯。

ePUF設計可用作在一系列身分建立協定中使用之PUF的基礎模型。實施例可允許程序中之終端使用者或機器的獨立性。在亦可重用於使用ePUF之現有方案依賴於受信任第三方以在設置期間直接存取PUF裝置的情況下，基於ePUF之所提議系統可允許PUF裝置之終端使用者替代地建立身分且參與後續鑑認而無需第三方在設置期間在本端或直接存取裝置。

一些實施可藉由引入公共區塊鏈來改善此等身分連結協定之穩健性且進一步延伸該等協定。此處可使用的二個概念為(A)使用區塊鏈作為防篡改CRP管理系統；以及(B)使用區塊鏈網路作為時間戳服務，用於調節在身分連結協定中使用的請求-回應訊息且提供高效撤銷系統。

圖6展示根據本文中所揭示之實施例的用於身分連結及驗證之實例系統。圖7展示對應方法。

該系統包含PUF模組603、目標方103T之電腦裝備102T，及回應資料存放區601。PUF模組603包含如前述關於圖5A及圖5B所描述之ePUF 500，或替代地，其可僅包含習知PUF 302或PUF加上習知介面邏輯404，如前述關於圖3及圖4所描述。回應資料存放區601可為第三方電腦裝備602之部分且由受信任第三方進行系統管理，或可替代地為分散式同級間儲存媒體，諸如區塊鏈。第三方裝備602可例如包含伺服器裝備，該伺服器裝備包含位於一或多個地理位置處之一或多個伺服器單元(雲端儲存技術自身為此項技術中已知的)。該系統可進一步包含驗證方103V之電腦裝備102V，或在一些替代狀況下，驗證方可與PUF模組603、目標方之電腦裝備102T或第三方電腦裝備602直接互動。

本文中對使用者或一方103或其類似者(無論為驗證方103V、目標方103T抑或第三方)之動作的任何提及皆涵蓋該方經由彼方之電腦裝備102進行動作的可能性。為了簡明起見，將不必每次皆明確地陳述此可能性，但應理解為隱含地涵蓋。此涵蓋以下二種可能性：A)該動作係藉由該方輸入至電腦裝備之手動使用者輸入觸發或在該手動使用者輸入之控制下執行，或B)該動作係藉由代表該方之電腦裝備自動地執行(說明：一方執行動作未必意謂彼方之人類使用者手動地發起彼動作，而是可意謂該方之裝備代表其自主地執行彼動作)。為避免疑問，亦應注意，一方可指單個個人或團體或人員或組織，例如公司、慈善機構、政府機構或市政或學術機構。

目標方103T之電腦裝備102T可操作性地連接至回應資料存放區601 (例如，藉由至第三方裝備602之連接)。驗證方103V之電腦裝備102V可操作性地連接至回應資料存放區601 (例如，藉由至第三方裝備602之連接)。目標方103T之電腦裝備102T可操作性地連接至驗證方103V之電腦裝備102V。此等連接中之任一者可經由一或多個網路形成，例如一或多個廣域網路，諸如網際網路或行動蜂巢式網路。在實施例中，此等連接中之任一者可經由例如基於共用秘密建立之各別安全通道形成，該共用秘密在所討論的二方之間共用。本文中無論在何處據稱二方以任何方式通訊，諸如藉由發送質詢或接收回應等，皆應理解，此涵蓋此等通訊可經由其各別電腦裝備(102V、102T；102T、602；或102V、602)之間的任何合適的直接或網路連接執行的可能性。為了簡明起見，不必每次皆明確地陳述此情形，但應理解為隱含地涵蓋。

目標方103T為身分待基於PUF模組603驗證或擁有或以其他方式負責或關聯待基於PUF模組603驗證之裝置的一方。驗證方103V為待執行驗證之一方。可存在多個驗證方103V (其中之各者可經由各別電腦裝備102V起作用)，但為了易於說明，圖6中僅展示一個驗證方。PUF模組603可為目標方103T所擁有。其可併入至目標方之電腦裝備103T中，或連接至該電腦裝備，例如作為周邊裝置或經由區域網路，或組合(例如，介面邏輯404/404'可實施於電腦裝備103T上且PUF 302可為外部周邊裝置)。替代地，PUF模組603可為受信任第三方所擁有。其可併入第三方電腦裝備602中或連接至第三方電腦裝備，例如作為周邊裝置或經由區域網路，或組合(例如，介面邏輯404/404'可實施於第三方裝備602上且PUF 302可為外部周邊裝置)。

一般而言，目標方103T、驗證方103V或第三方中之任一者可擔任先前關於圖3、圖4及圖5所論述之提交方的角色。目標方103T、驗證方103V或第三方中之任一者可擔任提交方之角色，或可擔任設置方之角色，該設置方使用PUF模組603來建立一或多個CR對之集合且將該等對連結至目標方103T之身分以供用於稍後驗證階段中。稍後更詳細地論述一些特定實例情境。

回應資料存放區601儲存由PUF模組603在設置階段中產生之回應資料。資料存放區601關聯地結合目標之身分證據儲存此回應資料，該目標可為目標方103T或目標方103T之裝置。驗證方103V可存取回應資料存放區601且可稍後在驗證階段期間使用此來驗證目標之身分。為進行此操作，驗證方103V對目標進行質詢以產生對先前包括於在設置階段中使用之質詢集合中的質詢Ci之回應Ri。若該目標可根據儲存於回應資料存放區601中之內容產生預期回應，則此證明該目標擁有或控制PUF模組603，且因此可假設為身分係在設置階段中俘獲的同一方。

在替代變體中，回應資料存放區601可儲存基於例如使用回應作為種子在設置階段中產生之回應而產生的一或多個各別公開-私密金鑰對中之一或多個公開金鑰。若該目標稍後使用私密金鑰中之一者對訊息(例如，文件或區塊鏈交易)進行簽名，則驗證方可使用來自回應資料存放區601之對應公開金鑰來驗證簽名。應注意，在此等變體中，「回應資料」一詞係在更廣泛的意義上使用以涵蓋自回應Ri導出的資料，未必為回應Ri之明確值或認證。

回應資料存放區601可為可公開存取的，或存取可僅限於包括至少一個驗證方103V之一或多方的有限集合。該回應資料存放區可在第三方系統602上或以同級間方式代管，或替代地，其可實施於目標方103T之電腦裝備102T或驗證方103V之電腦裝備102V中。

參看圖7，該方法包含二個階段：設置階段702及驗證階段704。在設置階段中，在步驟710處，充當設置方之目標方103T或第三方中之一者將一或多個質詢Ci (i=1…n，其中n＞=1)之集合提交至PUF模組603中。在使用ePUF 500之狀況下，此等質詢為次要質詢。在目標方103T擁有PUF模組603且正執行設置之狀況下，質詢Ci可由目標方103T產生或自第三方系統602或驗證方103V接收。在第三方擁有PUF模組603且正執行設置之狀況下，質詢可由第三方系統602產生或自目標方103T或驗證方103V接收。無論如何，作為回應，PUF模組603基於PUF 302/500而產生回應Ri之對應集合。在ePUF 500之狀況下，此等回應為次要回應。因此，該方法產生CR對{Ci, Ri}之集合。

在實施例中，對PUF模組903之存取受限制，使得僅目標方103T (及若為不同方，則設定方)可存取回應Ri。此可藉由存取控制邏輯404或404'來達成，該存取控制邏輯可僅向可呈現諸如密碼、PIN、生物特徵資料等之經辨識憑證的一方授予存取。及/或對至PUF模組603之實體介面的存取可在實體上受保護，諸如藉由將其保存於上鎖的容器、櫃子或房間中；或其可在法律上受保護，諸如藉由將PUF模組603儲存於僅准許某些人員進入之房間或綜合設施中。作為另一替代例或額外限制，在ePUF 501之狀況下，可限制對主要質詢Cw之瞭解，使得僅目標方103T (及在實施例中，充當分離的設置方之受信任第三方)知曉Cw。

在步驟720處，該方法包含將回應資料儲存於回應資料存放區601中。在實施例中，所儲存回應資料包含所產生CR對{Ci, Ri}之記錄。各CR對之記錄包含以指示該對之對應質詢Ci的方式儲存的各別回應Ri之記錄。在實施例中，各回應Ri之所儲存記錄包含向可讀取記錄之驗證方103V明確地揭示的回應之明確值，亦即，Ri之實際值。該值可以明文儲存，或若驗證方具有用於解密該值之解密金鑰，則可經加密，但儘管如此，仍出於本文中之目的而據稱所儲存值為明確值，此係因為向驗證方103V明確地揭示所儲存值。替代地，回應之記錄可包含回應Ri之「認證」，包含Ri之判定性變換。實例將為儲存雜湊H(Ri)或雙雜湊H ²(Ri)之值。此使得驗證方能夠藉由檢查應用於回應R'i之相同變換(例如，H(R'i)或H2(R'i))是否匹配認證來檢查回應R'i之值是否與記錄於存放區中之彼值相同。此具有不揭示回應Ri之實際值的益處。因此，在存放區601為諸如區塊鏈之公佈媒體的情況下，該方法之此變體可特別有用。然而，加密將為另一種可能性。

在回應資料以加密形式儲存之情況下，則可個別地加密各回應資料片段(例如，各CR對)，其各自需要不同的各別解密金鑰來解密。替代地，回應資料之子集或整個集合(例如，用於給定目標方103T之所有CR對)可一起加密，所有對可作為群組利用同一金鑰一起解碼。

例如CR對之回應資料係關聯地結合目標身分之證據儲存於回應資料存放區601中。舉例而言，作為設置之部分，可能需要目標方103T產生一或多個識別資訊片段，諸如護照。關聯地結合回應資料而保存於回應資料存放區601中之證據可包含關聯地結合回應資料明確地儲存(以明文或以驗證方103可存取之加密形式)之此資訊自身的複本。替代地，若回應資料存放區601由受信任第三方或驗證方103V自身進行系統管理，則回應資料關聯地結合特定身分暫存於回應資料存放區601中之純粹事實可被視為充分的證據(假設驗證方103V信任設置方及系統管理回應資料存放區601之一方，例如受信任第三方，以在設置時已適當地檢查了目標方之識別資訊)。

在驗證階段704中，在步驟730處，驗證方103V存取回應資料存放區以判定待用於驗證操作中之回應資料。在實施例中，存在多個潛在的驗證方103V，且各驗證方皆經分配一或多個CR對之不同各別子集。亦即，回應資料存放區601將僅向給定驗證方103V揭示分配給彼方之CR對的預期回應Ri。例如，此方案可由受信任第三方系統602進行系統管理。此方案有利地保持CR對分離，使得一個驗證方103V無法假裝另一方為目標。然而，若被准予存取存放區601之所有驗證方103V受信任，則此並非必需的。

在實施例中，驗證方103V最初不知曉其將使用的質詢且藉由自資料存放區601存取該質詢連同對應回應資料(例如，回應或認證)來判定此質詢。替代地，驗證方103V預先知曉其欲使用哪一質詢，且使用此質詢在資料存放區601中查找哪一回應資料映射至此質詢。

在驗證方103V (或實際上，任何方)自區塊鏈存取資料以便判定回應資料及/或質詢之情境中，接著可直接地藉由查詢區塊鏈網路之節點或間接地藉由查詢中間服務來執行區塊鏈存取，該中間服務快取區塊鏈資料或代表試圖存取區塊鏈資料之各方調節查詢。例如，驗證者103V可自未直接連接至區塊鏈網路106之另一服務提供者存取資料，但可能僅給出回應相關資料且可能亦給出默克爾(Merkle)證明。

在步驟740處，驗證方103V將質詢Ci提交至擁有或控制PUF模組603之目標方103T。此質詢為對應於驗證方103V在步驟730中自回應資料存放區601存取之記錄中之一者的質詢。應注意，在受信任第三方在設置時擁有PUF模組603之情境中，PUF模組603可在設置階段702與驗證階段704之間自受信任第三方實體地傳遞至目標方103T。

回應於所提交質詢Ci，PUF模組603產生對應回應Ri，目標方103V將該對應回應傳回至驗證方。在步驟750處，驗證方檢查接收到之回應Ri是否與根據在步驟730處自回應資料存放區601存取之回應資料而預期的回應一致。

如所提及，執行設置步驟702之一方可為目標方103T或儲存回應資料(例如，CR對)之受信任第三方。在其他變體中，此等步驟可由諸如受信任oracle之另一協調方執行(除在實施例中運行包含資料存放區610之第三方電腦裝備602之一方以外的另一第三方)。在此等實施例中，資料存放區601可為(不同第三方之)第三方系統602或諸如區塊鏈之公共同級間媒體。及/或在另外其他變體中，可提供執行對PUF模組603之輸入的一方與接收輸出的一方之間的分離。

亦如所提及，將回應Ri記錄於回應資料存放區601中之方式存在至少二種可能性。此第一可能性為簡單地明確儲存Ri自身之實際值。在此狀況下，步驟750簡單地包含比較所儲存值(其在設置702處建立)與現回應於所提交質詢Ci而接收(在驗證階段704中)之值R'i (回應Ri之聲稱值)。若其匹配，則方法分支至步驟760，其中宣告目標方103T之身分經驗證。否則，方法分支至步驟770，其中宣告目標方103T之身分未經驗證。

第二可能性為僅將Ri之認證儲存於回應資料存放區601中，例如雜湊或雙雜湊。在此狀況下，驗證方103V將用於產生認證之相同變換應用於其在驗證階段704中自目標方103T收回之回應R'i。若此回應匹配所儲存認證，則方法分支至步驟760，其中宣告目標方103T之身分經驗證。否則，方法分支至步驟770，其中宣告目標方103T之身分未經驗證。

在回應資料存放區601中，將對應質詢Ci指示為與各記錄回應Ri相關聯之方式存在至少二種可能性。第一種可能性為簡單地儲存各CR對{Ci, Ri}之明確值，亦即，儲存Ri及Ci之實際值(以明文或經加密)。替代地，根據本文中所揭示之實施例，第二種更輕量級方式為儲存主質詢Cm，質詢Ci可根據預定的判定性質詢導出函數f而自該主質詢導出。

此說明於圖8A中。各回應Ri係關聯地結合各別索引而儲存。函數f儲存於回應資料存放區601中或為驗證方103V預先已知的。無論如何，驗證方103V將主質詢Cm輸入至函數f中以判定對應於回應Ri中之至少一者之索引i的質詢Ci。驗證方103V接著使用此質詢Ci來驗證目標。

在一些此等實施例中，函數f亦可為識別資訊806之函數，該識別資訊可為單個識別資訊片段或識別資訊802 (例如，護照資訊、母親之本姓及指紋資訊)之多個片段的組合804 (例如，串接)。此可包含目標方103T之識別資訊。此使得質詢Ci之集合能夠特定於特定目標方103T，此出於安全原因為有利的，此係因為唯一性例如在同一第三方系統602用於為不同目標方產生質詢集合之情況下可為重要的。使用目標方103T之諸如護照資訊或母親之本姓的個人識別資訊為良好選項，此係因為該個人識別資訊為目標方已知曉之資訊且往往保密。

替代地或另外，識別資訊806可包含驗證方103V之識別資訊，使得f為特定驗證方103V之身分的函數。此可用於將一或多個特定質詢之特定子集分配給特定驗證方103V，使得不同驗證方103V被給予不同質詢Ci以供用於驗證704中。

在一些實施例中，無關於如何形成主質詢Cm，可將質詢Ci以鏈接方式映射至主質詢Cm，使得C1 = f(Cm)，C2 = f(C1)，等等，如圖8B中所展示。換言之，藉由將函數f應用於主質詢Cm來判定第一質詢C1，且接著藉由將同一函數f應用於第一質詢來判定第二質詢C2，等等。作為實例，f可包含雜湊函數。

在另一變體中，可將質詢Ci以階層方式映射至主質詢Cm，如圖8C中所展示。稍後將更詳細地論述此情形。

若f()不需要除根金鑰以外的任何資料，則鏈接方法為更輕量級的且亦更容易自根資訊恢復。在階層式導出之狀況下，將添加樹中之索引，此對於如下的簡單鏈為不需要的：C_m、H(C_m)、H(H(C_m))……，例如其中f()僅為雜湊函數。

無關於f()之形式或主質詢是否包含識別資訊及/或其他資訊，在實施例中，主質詢Cm可由第三方系統602在設置702期間自目標方103T接收。第三方接著將接收到之主質詢儲存於資料存放區601中(例如，在本端或在鏈上)以供未來在驗證704中使用。替代地，第三方系統602自目標方103T接收質詢Ci之集合，且自其導出主質詢Cm，例如藉由應用函數f()之反函數。在此等方法之變體中，第三方系統602可自除目標方103T以外之別處，例如自oracle或協調方(未圖示)接收識別資訊、主質詢或質詢集合。亦可使用此等方法之組合(例如，自目標方接收一個識別資訊片段，且自別處接收一個識別資訊片段)。或在其他替代例中，不涉及第三方，且目標方103自身將主質詢儲存於鏈上(或某一其他同級間公佈媒體中)。

在圖7之方法的其他變體中，儲存於回應資料存放區601中之回應資料可能不包含在設置時產生之CR對的記錄。實情為，回應資料可包含公開-私密金鑰對中之公開金鑰或此類公開金鑰之集合，其中一或多個金鑰對中之各者係基於來自設置階段702之各別PUF回應Ri而產生。例如，回應Ri可用作公開-私密金鑰對產生演算法中之種子。在此等實施例中，該方法如圖7中所闡明進行，除了在步驟730處，驗證方存取所儲存公開金鑰中之一者且在步驟740處，驗證方103V不提交待輸入至目標之PUF模組603的質詢Ci。實情為，驗證方103V獲得(聲稱)由目標籤名之訊息(例如，文件、檔案，或區塊鏈交易之部分)。此訊息可藉由目標方103T發送至驗證方，或驗證方103V可自諸如區塊鏈或網站之公佈媒體自主地存取此訊息。無論如何，在步驟750處，檢查包含使用自存放區601存取之公開金鑰來驗證應用於訊息之簽名(基於已知的公開-私密金鑰簽名驗證技術，其本身在此項技術中為眾所周知的)。

下文現根據本文中所揭示之實施例更一般地描述ePUF或PUF之一些實例身分建立及驗證協定。考慮證明者愛麗絲(目標方103T)及驗證者鮑勃(Bob)(驗證方103V)。PUF身分系統中存在至少三個不同質詢類型。作為實例，下文將關於ePUF進行描述，但更一般而言，可使用任何PUF裝置(包含PUF模組603之任何裝置)。

1. 遠端 PUF 質詢-藉由向愛麗絲請求對由鮑勃提交之質詢的回應，驗證者在遠端對證明者進行質詢。此模式假設驗證者知曉來自證明者之PUF的預期回應，以及PUF由合法所有者擁有。

2. 本端 PUF 質詢-藉由與由愛麗絲控制之PUF裝置互動，驗證者在本端對證明者進行質詢。此模式假設驗證者知曉關於證明者之身分的一些資訊，但不知曉其PUF之行為。

3. 密碼編譯質詢-驗證者對證明者進行質詢以滿足與其身分相關之一些密碼編譯要求，諸如藉由用可證明地連結至已證實公開金鑰之金鑰對訊息進行簽名。

在類型1及2之狀況下，自證明者及驗證者二者之視角，質詢明確地取決於PUF模組603。在此等狀況下，質詢及因此對應驗證程序本質上連結至PUF裝置(包含PUF模組603之裝置，例如愛麗絲之電腦裝備102T)之操作。在此等狀況下，吾人使用PUF裝置之屬性，即其實體狀態可唯一地繫結至身分，且PUF因此在所利用的身分系統中起核心作用。

應注意，「遠端」及「本端」二個詞特定地係指在進行質詢時驗證者與證明者之PUF之間的互動。此並不排除遠端質詢協定具有涉及證明者與驗證者之間的事先本端互動的設置階段。

然而，在狀況3下，自證明者之視角，質詢及驗證程序僅需要與PUF裝置相關。驗證不取決於驗證者知曉PUF是否已由證明者用於產生對其質詢之回應。在此狀況下，該方法簡單地使用PUF作為愛麗絲之金鑰產生器的效應，而非其用於將身分連結至裝置自身之效用。

在下文中，提供在上文所提及之三個操作模式中之各者中的身分系統之設置及驗證以及任擇的更新及撤銷程序之實例實施。在實施例中，在與基於PUF之身分系統相關的程序中涉及通用受信任第三方。此係因為此類身分系統往往需要此第三方，以便有意義地確保身分及相關憑證之完整性及信任。在待在此系統中建立及使用個人身分之狀況下，所討論之受信任第三方可為憑證頒發機構、政府代理或金融服務提供者，諸如銀行。

在待針對機器或非人類實體建立身分之狀況下，第三方可為裝置製造商、發行者、監管機構或某一其他相關參與者。此狀況特別適合於 物聯網 (IoT)或進一步適合於 物區塊鏈 (BoT)範例，其中將身分指派給可協作地執行任務或計算以達成某一目標之裝置的網路之不同成員。 3.1. 遠端 PUF 系統

3.1.1. 設置：在遠端PUF質詢之狀況下，假設將質詢

提交至證明者之驗證者事先知曉預期回應

。此意謂設置程序在此狀況下必須在愛麗絲與另一方之間建立CRP之集合(亦即，至少一個)，其可用於導出愛麗絲與另一方之間的共用秘密，該共用秘密可用於稍後鑑認愛麗絲之身分。

假設愛麗絲與經裝備以建立身分之通用第三方建立此共用秘密，如前述所提及，且此第三方可能為或可能不為稍後與愛麗絲一起參與驗證程序的驗證方。在驗證方相異於身分建立第三方之狀況下，假設驗證方可自第三方獲得用於共用秘密之相關CRP資訊。

此處的設置階段存在二個相異選項，該等選項係根據愛麗絲是否始終為存取PUF裝置之唯一一方或受信任第三方是否僅在設置階段期間亦可存取PUF裝置進行分類。

狀況 1 ： 愛麗絲具有對 PUF 之唯一存取權1. ePUF裝置經製造且分發給愛麗絲。 2. 愛麗絲藉由聯繫受信任第三方來申請將其身分連結至其ePUF裝置。 i. 第三方為愛麗絲建立識別帳戶且請求其身分之證明。 ii. 愛麗絲向第三方供應相關識別文件或憑證。 iii. 第三方驗證愛麗絲之身分。 3. 愛麗絲及第三方為設置程序之其餘部分建立安全通訊通道(例如，經由標準的迪菲-赫爾曼(Diffie-Hellman)金鑰交換)： i. 愛麗絲及第三方分別交換公開金鑰

。 ii. 愛麗絲及第三方獨立地為剩餘設置通訊建立暫時秘密，如

。 iii. 愛麗絲及第三方開始經由例如AES加密通道之通道通訊，該通道由

保護。 4. 第三方經由安全通道向愛麗絲發送質詢

之集合。 5. 愛麗絲自ePUF裝置獲得回應

。 6. 愛麗絲經由安全通道向第三方發送回應

。 7. 第三方根據愛麗絲之身分帳戶儲存回應CRP集合

。

狀況 2 ： 第三方在設置期間存取 PUF1. 第三方知曉基礎對及雜湊函數。例如，ePUF裝置經製造且分發給受信任第三方*。 2. 第三方自裝置獲得基礎CRP

。 3. 愛麗絲藉由聯繫第三方來申請身分連結之ePUF裝置。此可經由不安全的通訊通道完成。 i. 第三方為愛麗絲建立識別帳戶且請求其身分之證明。 ii. 愛麗絲向第三方供應相關識別文件或憑證。 iii. 第三方驗證愛麗絲之身分且將ePUF裝置及其基礎對

指派給愛麗絲之帳戶。共用秘密為此CRP或其導出項。 4. 第三方將ePUF裝置發送至愛麗絲。

(*該裝置可首先分發給愛麗絲，且接著由愛麗絲發送。然而，在大多數狀況下，將裝置直接分發給第三方將更有意義。例如，若裝置為智慧型轉帳卡，則該卡可自製造商發送至發卡行，且接著在PUF設置之後自發卡行發送至客戶愛麗絲。)

設置協定在愛麗絲與受信任第三方之間建立共用秘密，該共用秘密待用於稍後在驗證程序期間鑑認愛麗絲之身分(或含PUF裝置)。該等狀況的相似之處亦在於其二者較佳涉及愛麗絲與受信任第三方之間的安全通訊。

然而，二種狀況之間的相異之處在於，狀況1藉由建立安全通訊通道來達成安全通訊，而狀況2藉助於實體安全性來達成安全通訊。

分別在狀況1及2下之二個協定之間應注意的另一差異在於，在狀況2下，受信任第三方可在無PUF之情況下導出與愛麗絲一樣多的CRP，而在狀況1下，此方必須儲存固定數目個對。

此為狀況2優於用於使用PUF裝置設置使用者之現有協定的優點，此係因為其允許受信任第三方在遠端產生任意數目個CRP，而在現有協定中，受信任第三方可能需要與終端使用者或裝置製造商協作來實現此。在狀況1下，若添加愛麗絲經由安全通道將基礎對

發送至鮑勃之步驟(相信第三方不會以惡意方式使用基礎對)，則可達成相同技術優點。

應注意，在設置階段中使用安全通訊允許經由不安全通道傳輸未來通訊，諸如驗證程序。此具有以下益處：允許在具有較少技術限制之情況下進行驗證，諸如在驗證時需要二方均在線上，且僅在此一次性設置程序中需要額外的安全通訊額外負荷。

3.1.2. 驗證：在遠端PUF驗證之模式中，前已述及，在設置階段中存在二個相異狀況，該等狀況反映於略有不同的遠端驗證協定中，如下文所詳述。

狀況 1 ： 愛麗絲具有對PUF 之唯一存取權1. 鮑勃自藉由愛麗絲及第三方在設置期間建立的集合

獲得未使用的CRP，諸如

。 i. 若鮑勃亦為受信任第三方，則其簡單地自集合擷取元素。 ii. 若鮑勃並非受信任第三方，則其藉由為愛麗絲請求未使用的CRP來與第三方通訊。 2. 鮑勃將質詢

發送至愛麗絲。 3. 愛麗絲自其ePUF裝置獲得候選回應

且將其發送至鮑勃。 4. 鮑勃驗證是否

： i. 若是，則驗證通過。 ii. 若否，則驗證未通過。 5. 隨後藉由受信任第三方移除對

，留下剩餘質詢-回應對之集合

。

應注意，在步驟1.ii中，CRP之一次性性質確保任意鮑勃不可能使用特定CRP來「冒名頂替」愛麗絲，此係因為受信任第三方可簡單地監控各對在各給定情形中之使用且每次鑑認嘗試應使用新CRP。

狀況 2 ： 第三方在設置期間存取 PUF1. 鮑勃為驗證產生新質詢

。此可隨機地或自一些其他資料(例如，已知KYC資料、生物特徵、影像)以判定性方式進行。 2. 鮑勃將質詢

發送至愛麗絲。 3. 愛麗絲自其ePUF裝置獲得候選回應

且將其發送至鮑勃。 4. 鮑勃獲得預期回應

。 i. 若鮑勃為受信任第三方，則其能夠直接藉由運算

來計算回應*。 ii. 若鮑勃並非受信任第三方，則其將

發送至第三方且請求回應

。 5. 鮑勃驗證是否

： i. 若是，則驗證通過。 ii. 若否，則驗證未通過。

(*此係因為第三方在設置協定(狀況2)期間獲得基礎對

，此暗示

為其已知的。亦假設，雜湊函數

至少為第三方(若並非所有人)已知的，亦即，其為公共標準，諸如SHA-256)。

3.1.3. 更新：亦可能需要指定在給定新CRP在驗證(及其他適用協定，諸如登入)中之一次性性質的情況下供愛麗絲及第三方建立新CRP的程序。

狀況 1 ： 愛麗絲具有對 PUF 之唯一存取權。在此狀況下，建立另一安全通道以在愛麗絲與第三方之間傳輸質詢及回應，如在設置中。吾人假設愛麗絲具有形式

之至少一個剩餘CRP，以建立形式

或類似形式之共用秘密，或可自DH金鑰交換存取先前共用秘密

。 1. 愛麗絲及第三方使用共用秘密

建立安全通訊通道。可用許多方式導出此共用秘密，協定對此為不可知的。 2. 第三方經由安全通道向愛麗絲發送質詢

之集合。 3. 愛麗絲自ePUF裝置獲得回應

。 4. 愛麗絲經由安全通道向第三方發送回應

。 5. 第三方根據愛麗絲之身分帳戶儲存回應CRP集合

。應注意，步驟2至5至少與設置步驟4至7相同。

亦參見關於愛麗絲經由通道告知第三方(Cw, Rw)之先前評論。

狀況 2 ： 第三方在設置期間存取 PUF 。在此狀況下，第三方可間接地產生任意數目個CRP，此係因為其知曉基礎對

及雜湊函數

二者。此意謂在此狀況下不要求互動式更新。

3.1.4. 撤銷：身分系統之另一部分可用於待撤銷之特定ePUF裝置，使得其不再用於身分目的。撤銷程序為簡單的，且可作為(i)藉由第三方獨立於使用者愛麗絲進行的撤銷或(ii)藉由愛麗絲作為撤銷請求傳送之撤銷來執行。

第一種狀況不需要涉及ePUF或其他的任何技術手段。第二種狀況不需要特定於ePUF之協定或解決方案，此係因為在第一種狀況下需要撤銷之很好的實例為愛麗絲已失去含有ePUF之實體裝置或該裝置已在某種程序上受到了損害。

然而，若需要任擇地在撤銷程序中利用ePUF，其中愛麗絲仍具有對裝置之實體控制權，則可規定使用其及第三方已建立的CRP中之一者(或其導出的共用秘密)來鑑認愛麗絲之請求，諸如在各狀況下藉助於HMAC或加密訊息使用CRP回應或秘密作為金鑰。然而，出於上文所提及的原因，此無論如何不被視為系統之嚴格要求。 3.2. 本端 PUF 系統

3.2.1. 設置：可用於本端PUF之設置與用於遠端PUF之設置完全相同，但本端狀況與遠端狀況之間的差異為下文如何進行驗證步驟。

3.2.2. 驗證：在此情境中，在本端執行驗證。此意謂驗證程序需要證明者(愛麗絲)及驗證者(鮑勃)二者在同一實體位置中。

此情境可例如與法庭訴訟(針對人類身分)相關，其中在法律上要求愛麗絲使用其ePUF裝置在本端與調查互動，或其中待執行對IoT系統之分析(針對裝置身分)，其中系統之系統管理員可能希望在本端明確地檢查特定裝置之回應。其亦可能與付款情境相關。

此程序適用的其他情境可包括在碰撞之後對載具進行診斷，其中當局希望準確地判定哪一數位組件發出了指令。在此狀況下，輸入

可為一些環境或動力學條件，且回應

將為由裝置給出之指令的部分。

下文所概述之本端PUF驗證協定與先前遠端PUF驗證協定之間的相異之處在於，此本端協定並不假設驗證者事先已知曉ePUF之回應。換言之，在本端驗證程序期間產生的回應事先不可用於驗證者。

然而，在此情境中，用於驗證程序中之質詢可能在某種程度上為有意義的。舉例而言，考慮一台機器，其身分可被視為其嵌入式ePUF組件之基礎對

。可執行驗證程序以驗證此特定裝置先前自給定輸入

產生輸出

。

1. 鮑勃基於所討論之CRP

獲得相關質詢

以提交至ePUF裝置。 2. 鮑勃能夠存取ePUF裝置。 3. 鮑勃使用ePUF裝置產生候選回應

。 4. 鮑勃驗證是否

： i. 若是，則驗證通過。 ii. 若否，則驗證未通過。

在此等情境中，鮑勃事先不知曉候選回應R'，而是驗證其現自PUF裝置接收到之回應是否匹配先前產生之回應。舉例而言，此可用於驗證(例如，在法庭上)主導產生回應之人員(愛麗絲)或裝置為現存在(例如，在法庭上)之相同人員或裝置。例如，在數位組件之實例中，此數位組件將已經組配以在基於某一輸入質詢C產生R時發出指令。例如，若裝置為自動駕駛汽車且組件接收自資料「前方的汽車太近」導出或包含該資料的質詢，則產生回應R，且R觸發組件以發出應用制動器之指令。因此，在回溯性診斷驗證中，驗證者認為汽車減速且希望驗證條件實際上為「前方的汽車太近」以觸發彼回應。

3.2.3. 更新：用於產生經更新CRP之程序可遵循與針對遠端狀況提出的相同邏輯，此係因為彼情境中之關鍵差異僅適用於驗證。

3.2.4 撤銷：針對遠端撤銷所描述的相同技術在此處亦有效。 3.3. 密碼編譯 PUF 系統

3.3.1 設置：在此狀況下，愛麗絲使用標準的密碼編譯手段與第三方建立身分，但在程序中使用ePUF裝置。

在此情境中，第三方可任擇地知曉ePUF已用於程序中。類似地，對於以此方式建立之身分，身分驗證者可能知曉或可能不知曉在身分驗證程序中涉及ePUF裝置。簡言之，以下協定僅規定裝置所有者愛麗絲知曉在身分系統中涉及ePUF裝置。

1. ePUF裝置經製造且分發給愛麗絲。 2. 愛麗絲藉由聯繫受信任第三方來申請建立密碼編譯身分。 i. 第三方為愛麗絲建立識別帳戶且請求其身分之證明。 ii. 愛麗絲向第三方供應相關識別文件或憑證。 iii. 第三方驗證愛麗絲之身分。 3. 愛麗絲選擇一種密碼編譯方法來建立與其身分之密碼編譯連結，例如使用其CRP建立經證實之不對稱金鑰對。 i. 第三方自愛麗絲獲得公開金鑰

，其中

為EC金鑰對。 ii. 第三方請求愛麗絲使用私密金鑰

對訊息

進行簽名(例如，經由ECDSA)。 iii. 愛麗絲產生ECDSA簽名

且發送至第三方。 iv. 第三方驗證簽名。 4. 若簽名有效，則第三方根據愛麗絲之身分來證實金鑰

。

步驟3涉及使用使用者選擇之密碼編譯方案，但吾人假設在程序中涉及的相關金鑰將為僅愛麗絲知曉之CRP回應的導出項。在上文選擇之實例中，此意謂私密金鑰

將自特定ePUF回應

導出，諸如

。

3.3.2 驗證：在密碼編譯狀況下，使用在先前詳述之密碼編譯設置階段期間建立的密碼編譯資訊來執行身分驗證。在此狀況下，吾人採用以下實例：在設置期間根據愛麗絲之身分建立經證實之EC不對稱金鑰對，且吾人現使用彼金鑰用於驗證。

然而，以下協定可簡單地藉由在適當時將現有的設置及驗證協定替換為任何其他密碼編譯方案而簡單地適用於彼等方案。此處的差異在於，使用ePUF裝置作為設置及驗證程序之安全金鑰產生器，此降低了持有者愛麗絲遭受惡意損害的風險。

1. 鮑勃獲得身分連結資訊

，例如經證實之金鑰。 i. 若鮑勃為受信任第三方，則其簡單地自愛麗絲之帳戶擷取

。 ii. 若鮑勃並非受信任第三方，則其與第三方通訊且為愛麗絲請求經證實之公開金鑰。 2. 鮑勃選擇供愛麗絲進行簽名之訊息

且發送至愛麗絲。 3. 愛麗絲在訊息

上產生簽名。 i. 若愛麗絲希望使用其經證實之金鑰進行簽名，則其產生簽名

。 ii. 若愛麗絲希望用一次性導出金鑰進行簽名，則其產生簽名

，其中

且

為一些一次性資料*。 4. 愛麗絲將簽名發送至鮑勃。此時，若鮑勃尚未知曉資料d，則愛麗絲亦可發送該資料。 5. 鮑勃使用

(及

，若適用)根據公開金鑰驗證簽名。 i. 若簽名驗證通過，則身分驗證通過。 ii. 若簽名驗證未通過，則身分驗證未通過。

(*此資料可與驗證相關，諸如發票訊息或生物特徵模糊匹配資料。資料

可由鮑勃或愛麗絲選擇。替代地，

可為愛麗絲及鮑勃已知的共用秘密，例如使用Diffie-Hellman金鑰交換及/或HMAC導出。)

若使用諸如EC或PGP金鑰之類似密碼編譯原語建立身分，則上述密碼編譯驗證程序亦可應用於獨立地建立之身分，如描述於先前章節中。

3.3.3. 更新：更新愛麗絲之身分的程序在此處不取決於ePUF裝置在金鑰產生中的使用，且因而在此處不必規定任何特定方法。實情為，可使用用於更新諸如

之經證實金鑰的標準方法。

可簡單地假設，將在用於任何所需簽名之金鑰產生或現有程序所需之其他密碼編譯程序中涉及ePUF。

3.3.4. 撤銷：類似地，此處不必規定特定撤銷協定，但遵從標準機制。再次，可假設ePUF將作為用於相關密碼編譯操作之金鑰產生器在背景涉及。 3.4. 獨立 PUF 機制

3.4.1 設置：在使用ePUF裝置建立身分之獨立狀況下，考慮實體希望獨立於任何第三方建立人類身分或在封閉系統內建立裝置身分的情境。在此程序中所涉及之唯一一方為愛麗絲，其為ePUF裝置之「所有者」及稍後驗證期間的最終證明者。

狀況 1 ： 愛麗絲建立人類身分1. 愛麗絲獲得ePUF裝置。 2. 愛麗絲用質詢

探測ePUF。 3. 愛麗絲自ePUF獲得回應

。 4. 愛麗絲使用對

為自身建立身分： i. 愛麗絲可使用密碼編譯設置來建立未證實之身分金鑰

。 ii. 愛麗絲根據其身分公佈其身分金鑰。 5. 愛麗絲可能希望向其CRP公佈認證，諸如回應之雙雜湊

。

愛麗絲為其自身建立「自主權」身分之此狀況在一定程度上有助於為僅其控制之裝置提供唯一且可再現之裝置識別符。然而，在此身分系統中缺乏受信任第三方意謂驗證者稍後必須信任證明者身分與證明者裝置之間的連結。此在真實世界中之應用可能非常有限。

狀況 2 ： 愛麗絲為裝置建立身分1. 愛麗絲獲得ePUF裝置。 2. 愛麗絲用質詢

探測ePUF。 3. 愛麗絲自ePUF獲得回應

。 4. 愛麗絲使用對

為其系統內之裝置建立身分： i. 愛麗絲將對

映射至其裝置。 ii. 愛麗絲保存所有其裝置及CRP映射之資料庫。 5. 愛麗絲可能希望向其CRP公佈認證，諸如回應之雙雜湊

。

在吾人為裝置建立「自主權」身分之以上狀況下，可見設計在封閉系統內可能非常有用，其中系統管理者僅希望識別彼系統內的不同裝置。此對於隨後向其他人認證亦可能有用。然而，取決於情境，在設置期間缺乏受信任第三方仍限制證明者說服外部驗證者裝置尚未改變。

應注意，狀況1及狀況2可被視為相同程序，但具有不同預期目的。因此，狀況1及狀況2可一起被視為一種用於為人類或機器產生「自主權」身分之方法，其中在後一狀況下，系統管理員(諸如，IoT系統中之愛麗絲)自身為受信任實體。在二種狀況下，愛麗絲為受信任實體。

3.4.2 驗證：用於此狀況之驗證程序與用給定質詢探測ePUF裝置及檢測其回應一樣簡單。除此之外，亦可能需要為外部方建置更複雜證明或證據以向其證明身分。

3.4.3 更新：用於此狀況之更新程序僅為設置程序之重複，其中系統管理員(在此狀況下，愛麗絲)列舉額外CRP以供轉遞使用。

3.4.4. 撤銷：在此情境中，身分撤銷之唯一類型為系統管理員(愛麗絲)希望獨立地撤銷身分之狀況，此係因為在此程序中不涉及第三方。此意謂撤銷可與愛麗絲停止使用ePUF裝置及清除其CRP資料庫一樣簡單。

在稍後章節中，揭示可藉由區塊鏈認證及證據使此自主權撤銷更穩健的方式，使得其稍後可說服外部方。 3.5. 基於身分之 CRP 管理

在上文中，尤其為基於遠端PUF之身分系統，在設置及驗證協定中用於鑑認身分的CRP之一次性性質給所涉及方帶來CRP管理挑戰。

舉例而言，在受信任第三方在設置期間不存取PUF裝置之狀況下，可能需要列舉許多CRP

供第三方儲存以備未來驗證。此外，因為ePUF自身充當質詢至回應之判定性偽隨機映射，所以回應將看起來相互不相關。因此，若受信任第三方必須服務大量使用者，則受信任第三方為其使用者或用戶端列表顯示及儲存CRP集合的負擔將很快呈現縮放問題。

圖8A說明根據本文中所揭示之實施例的自識別資料判定性地導出質詢。

根據此等實施例，為了解決受信任第三方之負擔的問題，主要在產生質詢

時處置CRP管理。此處的想法為應自單個主質詢或供導出主質詢之主資料以判定性方式(且可能亦階層方式)導出質詢。此概念類似於使用階層式判定性(HD)電子錢包來管理一次性比特幣金鑰，此係因為其經設計以允許受信任第三方(或另一相關方)僅使用主資料恢復所有相關質詢，該主資料在比特幣情境中被稱為「電子錢包種子」。

在一些此等實施例中，愛麗絲(目標方103T)之識別資料806用作主資料以用於產生大量質詢，以判定哪些CRP用於身分系統中，諸如在先前章節中所提議的彼等系統。識別資料自身可包含不同資料元素802之組合804，但在組合時，其較佳具有以下屬性： ● 唯一性-識別資料對於其所屬的實體為唯一的；以及 ● 秘密性-識別資料僅為其所屬的實體(或其所有者)所知。

識別資料之組成部分的簡單實例可包括護照號碼、國家保險號碼、名稱、出生日期或對安全問題(例如，母親之本姓)之回答，或在裝置識別之狀況下的序號及製造資訊。然而，據感知，亦可使用藉由更先進的技術手段獲得的資料，諸如指紋或面部辨識資料，該資料可使用模糊魔術(fuzzy-magic)技術來提取以保持唯一性。

在實施例中，用作供導出質詢集合之主輸入的「識別資料」可包含多個上述資料。此操作之一個原因為確保資訊對儘可能多的受信任第三方保密，此係因為先前章節中之一些協定依賴於與第三方及/或外部驗證方共用質詢。在未經證明方愛麗絲同意之情況下，包含多個組成部分之識別資料對於任何第三方而言皆將更難完全複製。

用於使用識別資料以判定性方式產生CRP之機制展示於圖8A中。識別資料之組成部分首先藉由程序「A」 (804)組合，該程序可為串接、逐位元運算(例如，互斥或(XOR))或任何其他相關組合操作，其中應注意，此操作可試圖藉由將原始資料轉換成混淆形式來保護隱私。

識別資料接著藉助於雜湊函數或類似程序轉變為主質詢

。最終，主質詢用於使用導出函數

以判定性方式導出一次性質詢序列

。在實施例中，如圖8B中所展示，導出函數f()可包含雜湊函數及臨時亂數之注入，使得將各連續質詢產生為

，其中

充當臨時亂數。

程序A、質詢

自識別資料之產生及導出函數

皆可取決於特定實施之需要而組配。

圖8C展示另一特定實例，亦即，質詢(未描畫之回應)之階層式及判定性導出。可能需要以階層方式自主

導出一次性質詢

，如圖8B中所展示。在此狀況下，CRP管理得到進一步改善，此係因為特定質詢之產生不需要取決於所有先前質詢，如在先前狀況中。

質詢基於身體資料之判定性導出的使用減少了身分協定中證明者愛麗絲及受信任第三方二者之儲存額外負荷。任一方皆可能僅儲存識別資料(或識別資料之子集)，且在需要時重新運算必要質詢。

此外，愛麗絲亦可具有藉由視需要選擇隱瞞或與各識別服務共用儘可能多的資訊來定製其隱私的選項，但代價為其自身可儲存更多資料。 4. 實例區塊鏈系統

下文描述可在本揭露內容之某些實施例中使用的實例區塊鏈系統。應注意，「愛麗絲」及「鮑勃」僅為雙方之任意名稱，且愛麗絲及鮑勃在此章節中未必承擔與在先前章節或以下章節中相同的角色。

在一些實施例中，基於PUF之輸出的回應資料可儲存於鏈上，例如，如在先前章節中所論述。儲存於鏈上之回應資料可採用實際回應自身或其變換之形式，諸如雜湊或雙雜湊(所謂的認證或雜湊承諾)，或自PUF回應導出之公開-私密金鑰對中的公開金鑰。無論鏈上回應資料採用何種形式，其皆使得另一驗證方能夠檢查呈現為身分證據之目標回應或簽名是否符合預期。在其他實施例中，區塊鏈可用作管理質詢-回應對的手段，諸如更新或撤銷該等質詢-回應對。

下文描述可用於實施此等特徵之區塊鏈系統的實例。 4.1. 實例系統綜述

圖1展示用於實施區塊鏈150之實例系統100。系統100可包含封包交換網路101，其通常為諸如網際網路之廣域網際網路。封包交換網路101包含多個區塊鏈節點104，該等區塊鏈節點可經配置以在封包交換網路101內形成同級間(P2P)網路106。雖然未說明，但區塊鏈節點104可經配置為接近完整的圖。各區塊鏈節點104因此高度連接至其他區塊鏈節點104。

各區塊鏈節點104包含同級者之電腦裝備，其中節點104中之不同節點屬於不同同級者。各區塊鏈節點104包含：處理設備，其包含一或多個處理器，例如一或多個中央處理單元(CPU)、加速器處理器、特殊應用處理器及/或場可規劃閘陣列(FPGA)；以及其他裝備，諸如特殊應用積體電路(ASIC)。各節點亦包含記憶體，亦即，呈一或多個非暫時性電腦可讀媒體之形式的電腦可讀儲存器。記憶體可包含一或多個記憶體單元，其使用一或多個記憶體媒體，例如，諸如硬碟之磁性媒體；諸如固態驅動機(SSD)、快閃記憶體或EEPROM之電子媒體；及/或諸如光碟驅動機之光學媒體。

區塊鏈150包含資料區塊鏈151，其中在分散式或區塊鏈網路106中之多個區塊鏈節點104中之各者處維護區塊鏈150之各別複本。如上文所提及，維護區塊鏈150之複本未必意謂儲存整個區塊鏈150。實情為，只要各區塊鏈節點150儲存各區塊151之區塊標頭(下文所論述)，即可修剪區塊鏈150之資料。該鏈中之各區塊151包含一或多個交易152，其中在此上下文中之交易係指一種資料結構。該資料結構之性質將取決於用作交易模型或方案之部分的交易協定之類型。給定區塊鏈將始終使用一個特定交易協定。在一種常見類型之交易協定中，各交易152之資料結構包含至少一個輸入及至少一個輸出。各輸出指定表示作為財產之數位資產之數量的金額，其實例為輸出以密碼編譯方式被鎖定至的使用者103 (需要彼使用者之簽名或其他解決方案以便解除鎖定且藉此兌換或支出)。各輸入均指回至先前交易152之輸出，藉此連結交易。

各區塊151亦包含區塊指標155，該區塊指標指回至該鏈中之先前創建區塊151以便界定區塊151之順序次序。各交易152 (除了coinbase交易以外)包含指回至先前交易之指標，以便界定交易序列之次序(注意：允許交易152之序列進行分支)。區塊151之鏈一直追溯至起源區塊(Gb) 153，該起源區塊為該鏈中之第一區塊。鏈150中早期之一或多個原始交易152指向起源區塊153，而非先前交易。

區塊鏈節點104中之各者經組配以將交易152轉遞至其他區塊鏈節點104，且藉此使交易152在整個網路106中傳播。各區塊鏈節點104經組配以創建區塊151，且將同一區塊鏈150之各別複本儲存於其各別記憶體中。各區塊鏈節點104亦維護等待併入至區塊151中之交易152的有序集合(或「集區」) 154。有序集區154常常被稱作「記憶體集區」。本文中之此術語不意欲限於任何特定區塊鏈、協定或模型。該術語係指節點104已接受為有效的交易之有序集合，且對於該有序集合，節點104不必接受嘗試支出相同輸出之任何其他交易。

在給定的目前交易152j中，該(或各)輸入包含參考交易序列中之先前交易152i之輸出的指標，指定此輸出待在目前交易152j中兌換或「支出」。一般而言，先前交易可為有序集合154或任何區塊151中之任何交易。在目前交易152j經創建或甚至發送至網路106時，先前交易152i不一定存在，但先前交易152i將需要存在且經驗核以使目前交易有效。因此，本文中的「先前」係指藉由指標連結之邏輯序列中的前置者，未必為時間序列中之創建或發送時間，且因此，其未必排除無序地創建或發送交易152i、152j (參見下文關於孤立交易之論述)。先前交易152i同樣可被稱為前期或前置交易。

目前交易152j之輸入亦包含輸入授權，例如前述交易152i之輸出被鎖定至的使用者103a之簽名。又，目前交易152j之輸出可用密碼編譯方式鎖定至新使用者或實體103b。目前交易152j因此可將先前交易152i之輸入中所定義的金額轉移至如目前交易152j之輸出中定義的新使用者或實體103b。在一些狀況下，交易152可具有多個輸出以在多個使用者或實體(多個使用者或實體中之一者可為原始使用者或實體103a以便提供找零)間劃分輸入金額。在一些狀況下，交易亦可具有多個輸入以將來自一或多個先前交易之多個輸出的金額搜集在一起，且重新分發給當前交易之一或多個輸出。

根據基於輸出之交易協定，諸如比特幣，當諸如個別使用者或組織之一方103希望制定新交易152j (手動地或藉由該方所使用之自動化程序)時，則制定方將新交易自其電腦終端機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之輸出尚未由另一交易兌換。再次，若並非有效的，則不在區塊鏈150中傳播(除非經標記為無效，且經傳播以用於警示)或記錄交易152j。此防止雙重支出，由此交易者試圖將同一交易之輸出指派多於一次。另一方面，基於帳戶之模型藉由維持帳戶餘額來防止雙重支出。因為同樣存在所定義之交易次序，所以帳戶餘額在任一時間皆具有單個所定義狀態。

除了驗核交易以外，區塊鏈節點104亦競相率先在通常被稱作挖掘之程序中創建交易區塊，該程序由「工作量證明」支援。在區塊鏈節點104處，將新交易添加至有效交易之有序集區154，該等有效交易尚未出現在記錄於區塊鏈150上之區塊151中。區塊鏈節點接著競相藉由嘗試解決密碼編譯難題自交易之有序集合154組裝交易152之新有效區塊151。通常，此包含搜尋「臨時亂數」值，使得當臨時亂數與未決交易之有序集區154的表示串接且經雜湊時，雜湊之輸出接著符合預定條件。例如，預定條件可為雜湊之輸出具有某一預定數目個前導零。應注意，此僅為一個特定類型之工作量證明難題，且不排除其他類型。雜湊函數之屬性為其輸出相對於其輸入為不可預測的。因此，此搜尋可僅藉由蠻力執行，因此在正試圖解決難題之各區塊鏈節點104處消耗大量處理資源。

解決難題之第一區塊鏈節點104向網路106宣佈此點，從而提供解決方案作為證明，該解決方案接著可由網路中之其他區塊鏈節點104容易地檢查(一旦給定雜湊之解決方案，即直接檢查其是否使得雜湊之輸出符合條件)。第一區塊鏈節點104將區塊傳播至接受該區塊且因此實行協定規則之其他節點的臨限共識。交易之有序集合154接著藉由區塊鏈節點104中之各者而記錄為區塊鏈150中之新區塊151。區塊指標155亦經指派給新區塊151n，該指標指回至鏈中之先前創建區塊151n-1。創建工作量證明解決方案所需之例如呈雜湊形式的大量工作發信第一節點104遵循區塊鏈協定之規則的意圖。此等規則包括若交易指派與先前驗核之交易相同的輸出，則不接受該交易為有效的，否則被稱為雙重支出。一旦經創建，區塊151便無法被修改，此係因為在區塊鏈網路106中之區塊鏈節點104中之各者處辨識及維護該區塊。區塊指標155亦向區塊151強加順序次序。由於交易152記錄於網路106中之各區塊鏈節點104處的有序區塊中，因此，此提供交易的不可變公共分類帳。

應注意，在任何給定時間競相解決難題之不同區塊鏈節點104可基於在任何給定時間尚待公佈之交易的集區154的不同快照而如此操作，此取決於該等節點何時開始搜尋解決方案或接收該等交易之次序。不論誰首先解決其各別難題皆定義哪些交易152且以哪一次序包括於下一新區塊151n中，且更新未公佈交易之當前集區154。區塊鏈節點104接著繼續競相自未公佈交易之新定義有序集區154創建區塊，等等。亦存在用於解決可能出現的任何「分叉」之協定，分叉為二個區塊鏈節點104彼此在極短的時間內解決其難題之情況，使得區塊鏈的衝突觀點在節點104之間傳播。簡言之，無論分叉之哪個支叉生長得最長，皆成為決定性區塊鏈150。應注意，此不應影響網路之使用者或代理，此係因為相同交易將出現在二個分叉中。

根據比特幣區塊鏈(及大部分其他區塊鏈)，成功地建構新區塊之節點104被授予在新特殊種類之交易中新指派額外所接受金額之數位資產的能力，該新特殊種類之交易分發額外所定義數量之數位資產(相較於代理間或使用者間交易，其將一定金額之數位資產自一個代理或使用者轉移至另一代理或使用者)。此特殊類型之交易通常被稱作「coinbase交易」，但亦可被稱為「起始交易」或「產生交易」。其通常形成新區塊151n之第一交易。工作量證明發信建構新區塊之節點遵循協定規則的意圖，從而允許稍後兌換此特殊交易。在可兌換此特殊交易之前，區塊鏈協定規則可能需要成熟期，例如100個區塊。常常，常規(非產生)交易152亦將在其輸出中之一者中指定額外交易費用，以進一步獎勵創建了公佈彼交易之區塊151n的區塊鏈節點104。此費用通常被稱作「交易費用」，且在下文論述。

由於交易驗核及公佈中所涉及之資源，區塊鏈節點104中之至少各者通常採用伺服器之形式，該伺服器包含一或多個實體伺服器單元或甚至整個資料中心。然而，原則上，任何給定區塊鏈節點104可採用使用者終端機或經網路連接在一起之使用者終端機之群組的形式。

各區塊鏈節點104之記憶體儲存軟體，該軟體經組配以在區塊鏈節點104之處理設備上運行以便根據區塊鏈節點協定執行其各別的一或多個角色且處置交易152。應理解，本文中歸於區塊鏈節點104之任何動作可由在各別電腦裝備之處理設備上運行的軟體執行。節點軟體可以一或多個應用程式實施於應用層或諸如作業系統層或協定層之下部層或此等層之任何組合處。

充當消費使用者之角色的多方103中之各者的電腦裝備102亦連接至網路101。此等使用者可與區塊鏈網路106互動，但不參與驗核交易或建構區塊。此等使用者或代理103中之一些可在交易中充當發送者及接收者。其他使用者可與區塊鏈150互動，而未必充當發送者或接收者。舉例而言，一些方可充當儲存實體，其儲存區塊鏈150之複本(例如，已自區塊鏈節點104獲得區塊鏈之複本)。

多方103中之一些或全部可作為不同網路(例如，覆疊於區塊鏈網路106之上的網路)之部分而連接。區塊鏈網路之使用者(常常被稱作「用戶端」)可據稱為包括區塊鏈網路106之系統的部分；然而，此等使用者並非區塊鏈節點104，此係因為其不執行區塊鏈節點所需的角色。實情為，各方103可與區塊鏈網路106互動，且藉此，藉由連接至區塊鏈節點106 (亦即，與該區塊鏈節點通訊)而利用區塊鏈150。出於說明之目的展示二方103及其各別裝備102：第一方103a及其各別電腦裝備102a，以及第二方103b及其各別電腦裝備102b。應理解，更多此類方103及其各別電腦裝備102可存在且參與系統100，但為方便起見不對其加以說明。各方103可為個人或組織。僅作為說明，第一方103a在本文中被稱作愛麗絲，且第二方103b被稱作鮑勃，但應瞭解，此不具限制性，且在本文中對愛麗絲或鮑勃之任何提及皆可分別用「第一方」及「第二方」替換。

各方103之電腦裝備102包含各別處理設備，該處理設備包含一或多個處理器，例如一或多個CPU、GPU、其他加速器處理器、特殊應用處理器及/或FPGA。各方103之電腦裝備102進一步包含記憶體，亦即，呈一或多個非暫時性電腦可讀媒體之形式的電腦可讀儲存器。此記憶體可包含一或多個記憶體單元，其使用一或多個記憶體媒體，例如，諸如硬碟之磁性媒體；諸如SSD、快閃記憶體或EEPROM之電子媒體；及/或諸如光碟驅動機之光學媒體。各方103之電腦裝備102上的記憶體儲存軟體，該軟體包含經配置以在處理設備上運行之至少一個用戶端應用程式105的各別執行個體。應理解，可使用在各別電腦裝備102之處理設備上運行的軟體來執行本文中歸於給定方103之任何動作。各方103之電腦裝備102包含至少一個使用者終端機，例如桌上型或膝上型電腦、平板電腦、智慧型手機或諸如智慧型手錶之可穿戴式裝置。給定方103之電腦裝備102亦可包含一或多個其他網路連接資源，諸如經由使用者終端機存取之雲端運算資源。

用戶端應用程式105最初可在合適的一或多個電腦可讀儲存媒體上經提供至任何給定方103之電腦裝備102，例如自伺服器下載，或經提供於抽取式儲存裝置上，該抽取式儲存裝置諸如抽取式SSD、快閃記憶體金鑰、抽取式EEPROM、抽取式磁碟驅動機、磁性軟碟或磁帶、諸如CD或DVD ROM之光碟或抽取式光碟機等。

用戶端應用程式105包含至少一「電子錢包」功能。此具有二個主要功能性。此等功能性中之一者為使得各別方103能夠創建、授權(例如，簽名)及發送交易152至一或多個比特幣節點104，以接著在區塊鏈節點104之整個網路中傳播且藉此包括於區塊鏈150中。另一功能性為將其當前擁有之數位資產的金額報告給各別方。在基於輸出之系統中，此第二功能性包含核對散佈在整個區塊鏈150中屬於所討論的一方之各種交易152之輸出中所定義的金額。

應注意：雖然各種用戶端功能性可描述為整合至給定用戶端應用程式105中，但此未必為限制性的，且實情為，本文中所描述之任何用戶端功能性可替代地實施於二個或多於二個相異應用程式之套件中，例如經由API介接，或一個應用程式為另一應用程式之外掛程式。更一般而言，用戶端功能性可實施於應用層或諸如作業系統之下部層或此等層之任何組合處。下文將關於用戶端應用程式105進行描述，但應瞭解，此並非限制性的。

各電腦裝備102上之用戶端應用程式或軟體105的執行個體操作性地耦接至網路106之區塊鏈節點104中之至少一者。此使得用戶端105之電子錢包功能能夠將交易152發送至網路106。用戶端105亦能夠聯繫區塊鏈節點104以便查詢區塊鏈150以詢問各別方103為接收者之任何交易(或實際上檢測區塊鏈150中之其他方的交易，此係因為在實施例中，區塊鏈150為公共設施，其部分地經由其公共可見性而在交易中提供信任)。各電腦裝備102上之電子錢包功能經組配以根據交易協定來制訂及發送交易152。如上文所闡述，各區塊鏈節點104運行軟體，該軟體經組配以根據區塊鏈節點協定來驗核交易152，且轉遞交易152以便在整個區塊鏈網路106中傳播該等交易。交易協定及節點協定彼此對應，且給定交易協定與給定節點協定相配，其一起實施給定交易模型。相同交易協定用於區塊鏈150中之所有交易152。相同節點協定由網路106中之所有節點104使用。

當給定方103，比如Alice，希望發送新交易152j以包括於區塊鏈150中時，其接著根據相關交易協定來制訂新交易(使用其用戶端應用程式105中之電子錢包功能)。其接著將交易152自用戶端應用程式105發送至其連接至的一或多個區塊鏈節點104。例如，此可為最佳地連接至愛麗絲之電腦102的區塊鏈節點104。當任何給定區塊鏈節點104接收新交易152j時，該區塊鏈節點根據區塊鏈節點協定及其各別角色來處置該新交易。此包含首先檢查新接收交易152j是否符合「有效」的某一條件，稍後將更詳細地論述該條件之實例。在一些交易協定中，可藉由包括於交易152中之指令碼基於各交易來組配驗核條件。替代地，該條件可簡單地為節點協定之內置特徵，或可由指令碼及節點協定之組合來定義。

若新接收交易152j通過被視為有效的測試(亦即，若其「經驗核」)，則接收交易152j之任何區塊鏈節點104將添加新經驗核交易152至在彼區塊鏈節點104處維護的交易之有序集合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將一個例項接受為有效的且接著發現第二例項已記錄於區塊鏈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的來源(若尚未兌換該UTXO)。UTXO包括指定數位資產之金額的值。此表示分散式分類帳上之代幣的設定數目。UTXO亦可含有其所來自的交易之交易ID以及其他資訊。交易資料結構亦可包含標頭201，該標頭可包含輸入欄位202及輸出欄位203之大小的指示符。標頭201亦可包括交易之ID。在實施例中，交易ID為交易資料(不包括交易ID自身)之雜湊，且儲存於提交至節點104之原始交易152的標頭201中。

假設愛麗絲103a希望創建將所討論的一定金額之數位資產轉移至鮑勃103b的交易152j。在圖2中，愛麗絲之新交易152j經標示為「 Tx ₁ 」。該交易獲取在序列中之先前交易152i之輸出203中鎖定至愛麗絲的一定金額之數位資產且將此數位資產中之至少一些轉移至鮑勃。先前交易152i在圖2中經標示為「 Tx ₀ 」。 Tx ₀ 及 Tx ₁ 僅為任意標籤。其未必意謂 Tx ₀ 為區塊鏈151中之第一交易，亦不意謂 Tx ₁ 為集區154中緊接著的下一交易。 Tx ₁ 可指回至仍具有鎖定至愛麗絲之未支出輸出203的任何先前(亦即，前期)交易。

在愛麗絲創建其新交易 Tx ₁ 時，或至少至其將新交易發送至網路106時，先前交易 Tx ₀ 可能已經驗核且包括於區塊鏈150之區塊151中。該交易彼時可能已包括於區塊151中之一者中，或其可能仍在有序集合154中等待，在此狀況下，該交易將很快包括於新區塊151中。替代地，可創建 Tx ₀ 及 Tx ₁ 且將其一起發送至網路106，或若節點協定允許緩衝「孤立」交易，則 Tx ₀ 甚至可在 Tx ₁ 之後發送。如本文中所使用之「先前」及「後續」二個詞在交易序列之上下文中係指如由交易中指定之交易指標所定義的序列中之交易的次序(哪一交易指回至哪一其他交易，等等)。該等術語同樣地可用「前置」及「後置」或「前期」及「後期」、「親代」及「子代」等來替換。其未必暗示該等交易經創建、發送至網路106或到達任何給定區塊鏈節點104之次序。然而，直至且除非親代交易經驗核，否則將不驗核指向先前交易(前期交易或「親代」)之後續交易(後期交易或「子代」)。在其親代之前到達區塊鏈節點104之子代被視為孤立的。取決於節點協定及/或節點行為，子級可被捨棄或緩衝一段時間以等待親代。

先前交易 Tx ₀ 之一或多個輸出203中之一者包含特定UTXO，其在此處標示為 UTXO ₀ 。各UTXO包含指定由UTXO表示之一定金額之數位資產的值；以及鎖定指令碼，其定義後續交易之輸入202中之解除鎖定指令碼必須符合的條件，以便驗核後續交易且因此成功地兌換UTXO。通常，鎖定指令碼將金額鎖定至特定方(包括該金額之交易的受益人)。亦即，鎖定指令碼定義解鎖條件，通常包含如下條件：後續交易之輸入中的解鎖指令碼包含先前交易經鎖定至的一方之密碼編譯簽名。

鎖定指令碼(亦稱為scriptPubKey)為以節點協定所辨識之網域特定語言編寫的一段程式碼。此語言之特定實例被稱為「指令碼(Script)」(S為大寫)，其由區塊鏈網路使用。鎖定指令碼指定需要何資訊來支出交易輸出203，例如愛麗絲之簽名的要求。解鎖指令碼出現在交易之輸出中。解鎖指令碼(亦稱為scriptSig)為用網域特定語言編寫的一段程式碼，其提供滿足鎖定指令碼準則所需的資訊。舉例而言，其可含有鮑勃之簽名。解除鎖定指令碼出現在交易之輸入202中。

因此，在所說明之實例中， Tx ₀ 之輸出203中的 UTXO ₀ 包含鎖定指令碼[Checksig P _A ]，該鎖定指令碼需要愛麗絲之簽名Sig P _A 以便兌換 UTXO ₀ (嚴格來說，以便使嘗試兌換 UTXO ₀ 之後續交易有效)。[Checksig P _A ]含有來自愛麗絲之公用-私密金鑰對中之公開金鑰 P _A 的表示(亦即，雜湊)。 Tx ₁ 之輸入202包含指回至 Tx ₁ 之指標(例如，藉助於其交易ID TxID ₀ ，其在實施例中為整個交易 Tx ₀ 之雜湊)。 Tx ₁ 之輸入202包含識別 Tx ₀ 內之 UTXO ₀ 的索引，以在 Tx ₀ 之任何其他可能輸出中識別 UTXO ₀ 。 Tx ₁ 之輸入202進一步包含解除鎖定指令碼＜Sig P _A ＞，其包含愛麗絲之密碼編譯簽名，該密碼編譯簽名係藉由愛麗絲將其來自金鑰對之私密金鑰應用於資料(在密碼學中有時被稱為「訊息」)之預定義部分而創建。需要由愛麗絲簽名以提供有效簽名之資料(或「訊息」)可由鎖定指令碼或由節點協定或由此等之組合來定義。

當新交易 Tx ₁ 到達區塊鏈節點104時，該節點應用節點協定。此包含一起運行鎖定指令碼及解除鎖定指令碼以檢查解除鎖定指令碼是否符合鎖定指令碼中所定義之條件(其中此條件可包含一或多個準則)。在實施例中，此涉及串接二個指令碼：＜Sig P _A ＞＜ P _A ＞ || [Checksig P _A ] 其中「||」表示串接，且「＜…＞」意謂將資料置放於堆疊上，且「[…]」為鎖定指令碼所包含之函式(在此實例中為基於堆疊之語言)。等效地，指令碼可使用共同堆疊一個接一個地運行，而非串接指令碼。無論如何，當一起運行時，指令碼使用如包括於 Tx ₀ 之輸出中之鎖定指令碼中的愛麗絲之公開金鑰 P _A ，以鑑認 Tx ₁ 之輸入中的解除鎖定指令碼含有對資料之預期部分進行簽名的愛麗絲之簽名。亦需要包括資料自身(「訊息」)之預期部分，以便執行此鑑認。在實施例中，經簽名資料包含整個 Tx ₁ (因此不需要包括分離的元素來以明文指定資料之經簽名部分，此係因為其已固有地存在)。

藉由公開-私密密碼學進行鑑認之細節將為熟習此項技術者所熟悉的。基本上，若愛麗絲已使用其私密金鑰對訊息進行簽名，則在以明文給出愛麗絲之公開金鑰及訊息的情況下，諸如節點104之另一實體能夠鑑認該訊息必須已由愛麗絲簽名。簽名通常包含對訊息進行雜湊、對雜湊進行簽名及將此標示至訊息上作為簽名，因此使得公開金鑰之任何持有者能夠鑑認該簽名。因此，應注意，本文中對特定資料片段或交易之部分或其類似者之簽名的任何提及在實施例中可意謂對彼資料片段或交易之部分的雜湊進行簽名。

若 Tx ₁ 中之解除鎖定指令碼符合 Tx ₀ 之鎖定指令碼中所指定的一或多個條件(因此在所展示之實例中，若愛麗絲之簽名經提供於 Tx ₁ 中且經鑑認)，則區塊鏈節點104將 Tx ₁ 視為有效的。此意謂區塊鏈節點104將添加 Tx ₁ 至未決交易之有序集區154。區塊鏈節點104將亦轉遞交易 Tx ₁ 至網路106中之一或多個其他區塊鏈節點104，使得該交易將在整個網路106中傳播。一旦 Tx ₁ 已經驗核且包括於區塊鏈150中，則此將來自 Tx ₀ 之 UTXO ₀ 定義為已支出。應注意， Tx ₁ 可僅在其支出未支出交易輸出203之情況下為有效的。若其嘗試支出已由另一交易152支出之輸出，則 Tx ₁ 將為無效的，即使符合所有其他條件亦如此。因此，區塊鏈節點104亦需要檢查是否已支出先前交易 Tx ₀ 中所提及之UTXO (亦即，其是否已形成另一有效交易之有效輸入)。此為區塊鏈150將所定義次序強加於交易152上很重要的一個原因。實務上，給定區塊鏈節點104可維護分離的資料庫，其標記已支出哪些交易152中之哪些UTXO 203，但最終定義是否已支出UTXO的係其是否已形成區塊鏈150中之另一有效交易的有效輸入。

若給定交易152之所有輸出203中所指定的總金額大於由所有其輸入202所指向之總金額，則此為大多數交易模型中無效之另一基礎。因此，此類交易將不被傳播，亦不包括於區塊151中。

應注意，在基於UTXO之交易模型中，需要將給定UTXO作為整體支出。其不能「留下」在UTXO中定義為支出之一小部分金額，同時支出另一小部分。然而，來自UTXO之金額可在下一交易之多個輸出之間劃分。例如， Tx ₀ 中之 UTXO ₀ 中所定義的金額可在 Tx ₁ 中之多個UTXO之間劃分。因此，若愛麗絲不想將 UTXO ₀ 中所定義之所有金額皆給予鮑勃，則其可使用剩餘金額在 Tx ₁ 之第二輸出中給自身找零，或付款給另一當事方。

實務上，愛麗絲通常亦將需要包括比特幣節點104之費用，該比特幣節點成功地將愛麗絲之交易104包括於區塊151中。若愛麗絲不包括此費用，則區塊鏈節點104可拒絕 Tx ₀ ，且因此儘管技術上有效，但 Tx ₀ 可能不會被傳播且包括於區塊鏈150中(若區塊鏈節點104不想接受交易152，則節點協定不會強迫區塊鏈節點接受)。在一些協定中，交易費用不需要其自身的分離輸出203 (亦即，不需要分離的UTXO)。實情為，由給定交易152之輸入202所指向的總金額與給定交易之輸出203中所指定的總金額之間的任何差額被自動地給予公佈該交易之區塊鏈節點104。例如，假設指向 UTXO ₀ 之指標為 Tx ₁ 之唯一輸入，且 Tx ₁ 僅具有一個輸出 UTXO ₁ 。若 UTXO ₀ 中所指定之數位資產的金額大於 UTXO ₁ 中所指定之金額，則差額可由贏得工作量證明競賽之節點104指派以創建含有 UTXO ₁ 之區塊。然而，替代地或另外，未必排除可在交易152之其自身的UTXO 203中之一者中明確地指定交易費用。

愛麗絲及鮑勃之數位資產由在區塊鏈150中任何位置處之任何交易152中鎖定至愛麗絲及鮑勃的UTXO組成。因此，給定方103之資產通常遍及整個區塊鏈150中之各種交易152的UTXO而散佈。區塊鏈150中之任何位置處皆未儲存定義給定方103之總餘額的一個數字。用戶端應用程式105中之電子錢包功能的作用為將鎖定至各別方且尚未在另一後續交易中支出之所有各種UTXO的值一起核對。其可藉由查詢如儲存於比特幣節點104中之任一者處的區塊鏈150之複本來實現此。

應注意，常常示意性地表示指令碼(亦即，不使用確切語言)。舉例而言，吾人可使用操作碼(作業碼)來表示特定函式。「OP_…」係指指令碼語言之特定作業碼。作為實例，OP_RETURN為指令碼語言之作業碼，當在鎖定指令碼之開頭加上OP_FALSE時，該作業碼創建交易之不可支出輸出，該輸出可儲存交易內之資料，且藉此將資料不可變地記錄於區塊鏈150中。例如，資料可包含需要儲存於區塊鏈中之文件。

通常，交易之輸入含有對應於公開金鑰 P _A 之數位簽名。在實施例中，此係基於使用橢圓曲線secp256k1之ECDSA。數位簽名對特定資料片段進行簽名。在一些實施例中，對於給定交易，簽名將對交易輸入之部分及交易輸出中之一些或全部進行簽名。數位簽名所簽名之輸出之特定部分取決於SIGHASH旗標。SIGHASH旗標通常為4位元組碼，其被包括在簽名之末尾，以選擇對哪些輸出進行簽名(且因此在簽名時固定)。

鎖定指令碼有時被稱為「scriptPubKey」，此係因為其通常包含各別交易被鎖定至的一方之公開金鑰。解除鎖定指令碼有時被稱為「scriptSig」，此係因為其通常供應對應簽名。然而，更一般而言，在區塊鏈150之所有應用中，兌換UTXO之條件不一定包含鑑認簽名。更一般而言，指令碼處理語言可用於定義任何一或多個條件。因此，「鎖定指令碼」及「解除鎖定指令碼」二個更一般的詞可為較佳的。 4.3. 旁側通道

如圖1中所展示，愛麗絲及鮑勃之電腦裝備102a、120b中之各者上的用戶端應用程式可分別包含額外通訊功能性。此額外功能性使得愛麗絲103a能夠與鮑勃103b建立分離的旁側通道107 (在任一方或第三方之推動下)。旁側通道107使得能夠與區塊鏈網路分離地進行資料交換。此通訊有時被稱作「離鏈」通訊。舉例而言，此可用於在愛麗絲與鮑勃之間交換交易152，而無需(尚未)將交易註冊至區塊鏈網路106上或使其進入鏈150，直至多方中之一者選擇將其廣播至網路106。以此方式共用交易有時被稱作共用「交易範本」。交易範本可能缺乏形成完整交易所需之一或多個輸入及/或輸出。替代地或另外，旁側通道107可用於交換任何其他交易相關資料，諸如金鑰、協商的金額或條款、資料內容等。

可經由與區塊鏈網路106相同之封包交換網路101建立旁側通道107。替代地或另外，可經由諸如行動蜂巢式網路之不同網路或諸如區域無線網路之區域網路或甚至愛麗絲之裝置102a與鮑勃之裝置102b之間的直接有線或無線鏈路來建立旁側通道301。通常，在本文中任何位置處被提及之旁側通道107可包含經由一或多個網路連接技術或通訊媒體之任何一或多個鏈路，以用於「離鏈」(亦即，與區塊鏈網路106分離地)交換資料。在使用多於一個鏈路的情況下，離鏈鏈路之集束或集合可作為整體被稱作旁側通道107。因此，應注意，若據稱愛麗絲及鮑勃經由旁側通道107交換某些資訊或資料片段或其類似者，則此未必暗示必須經由完全相同的鏈路或甚至相同類型之網路來發送所有此等資料片段。

旁側通道107可包含安全通道，該安全通道使用已知的安全通訊技術以使得能夠進行諸如愛麗絲及鮑勃之多方之間的安全、私密的鏈外通訊。舉例而言，該安全通道可基於在經由安全通道通訊之多方之間共用的共用秘密。可使用此通道以例如在驗證方103V與目標方103T之間通訊，以便使得驗證方103V能夠將質詢提交至由目標方持有的PUF 302/500，且收回對應回應。 5. 基於區塊鏈之 PUF 身分認證

如前述章節中所提及，充當回應記錄之回應資料可儲存於公共區塊鏈上而非使用受信任第三方系統602。回應資料為在設置時判定之資料，且稍後可由驗證方103V (「鮑勃」)使用以測試目標方103T (「愛麗絲」)對目標身分的認證。再次應注意，愛麗絲及鮑勃僅為任意標籤，且愛麗絲及鮑勃在此處之角色未必與在章節4中給出之區塊鏈系統之一般綜述中相同(其中鮑勃支出了愛麗絲之交易的輸出)。

如前述所論述，給定CR對{Ci, Ri}之回應資料(儲存於鏈上抑或別處)可包含如在設置階段702中判定且儲存以供驗證方103V未來參考的以下各者中之任一者： i) 質詢Ci及/或回應Ri之明確值(以明文或加密形式)，或 ii) 連結至主質詢Cm之回應Ri的明確值，自該主質詢可導出各別回應Ri之特定質詢Ci，或 iii) 回應Ri之認證(例如，雜湊或雙雜湊)連同質詢Ci之明確值，或 iv) 連結至主質詢Cm之回應Ri的認證(例如，雜湊或雙雜湊)，自該主質詢可導出各別回應Ri之特定質詢，或 v) 自回應Ri導出之公開-私密金鑰對中的公開金鑰。

如圖9中所展示，無論採用何種形式，在設置階段702中，此回應資料901皆可儲存於記錄於區塊鏈150上之交易152S的輸出203中。此在下文中可被稱作儲存交易。其可例如使用上文在章節4中所論述之技術記錄於鏈上，再次應注意，彼章節中之愛麗絲未必為目標方103T，且彼章節中之鮑勃未必為驗證方103V-實際上，目標方103T，現被稱作愛麗絲，可為制訂及發出待記錄於鏈上之儲存交易152S的一方。作為另一實例，受信任第三方可藉由包括在設置時產生之回應資料901來制訂供目標方103T完成之儲存交易之範本，且接著轉遞以記錄於鏈上。目標部分103T可將儲存交易152S直接發送至區塊鏈節點104中之一者以經由區塊鏈網路106傳播，或可經由諸如受信任第三方之另一方間接地發送儲存交易。作為又一實例，目標方103T可將其回應資料901發送至受信任第三方以供受信任第三方制訂成儲存交易152且發出以記錄於鏈上。

回應資料901可儲存於儲存交易152S之不可支出輸出中。例如，若使用指令碼協定，則可藉助於OP_RETURN或OP_FALSE接著OP_RETURN使此輸出不可支出(在如BTC或BCH之一些區塊鏈協定中，OP_RETURN之任何包括使輸出不可支出，而在如BSV之其他協定中，需要OP_FALSE及OP_RETURN二者以使輸出不可支出)。BTC (比特幣)、BTC (比特幣現金)及比特幣中本聰願景(Bitcoin Satoshi Vision；BSV)為較早所描述之區塊鏈系統的不同實例實施。

替代地，回應資料901可嵌入於儲存交易152S之不可支出輸出中。例如，此輸出可藉由包括OP_RETURN而不包括OP_FALSE來保持可支出。作為另一實例，吾人可藉由緊接在OP_DROP程式碼之前包括資料來將資料嵌入於可支出鎖定指令碼中。此將同樣適用於BTC、BCH及BSV。

在實施例中，可儲存給定目標方103T之多個不同CR對{Ci, Ri}之集合的回應資料901。此等資料可儲存於儲存交易152之相同輸出203或不同輸出203中，或相同輸出中之一些及不同輸出中之一些的組合中。其可儲存於相同儲存交易152S中，或不同CR對之回應資料901可儲存於不同儲存交易152S中，或相同交易中之一些及不同交易中之一些的組合中。

應注意，鏈上儲存未必限於基於帳戶之模型。在替代部署中，回應資料901可儲存於基於帳戶之模型的一或多個交易之一或多個智慧型合約中。

在驗證階段704中，當驗證方103V希望驗證目標之身分時，其接著存取區塊鏈150，以便自儲存交易152S獲得對應於一個特定CR對之回應資料901。在實施例中，此向驗證方103V給予對應於特定質詢Ci之回應Ri或彼回應Ri之認證(例如，雜湊或雙雜湊)。驗證方103V亦將質詢Ci提交至目標方103V，且作為回應，收回目標方103T (或其裝置)藉由將接收到之質詢Ci輸入至PUF模組603而產生的(聲稱)回應R'i。驗證方103V接著比較傳回之回應R'i與自鏈上之儲存交易152S擷取的版本，或將相同轉變(例如，H(R'i)或H ²(R'i))應用於接收到之用於認證的回應，且比較此與自鏈上之儲存交易152S擷取的認證。無論如何，若比較給出匹配，則目標經驗證。

驗證方103V可經由區塊鏈網路106之節點104中之一者或替代地藉由自任何外部方獲得回應資料來存取區塊鏈150，該外部方亦可提供在區塊鏈中包括彼資料(亦即，交易)之默克爾證明。

在回應資料901儲存於諸如區塊鏈150之公佈媒體上的實施例中，可能需要實際回應值Ri自身未被公開地或無限制地揭示。否則，任何惡意方皆可查看鏈上之Ri，且接著在受到Ci質詢時假裝為目標方103T。實情為，因此，可較佳僅儲存Ri之認證(例如，H(Ri)或H ²(Ri))作為保存於鏈上之回應資料901，或儲存Ri之明確值但以加密形式儲存。或在一些狀況下，認證可以加密形式儲存於鏈上。

在潛在地存在多個驗證方之狀況下，以加密形式儲存Ri或其認證使得目標方103T或受信任第三方能夠控制哪些驗證方103V能夠獲得對應於CR對中之哪一者的儲存資料901。此可藉由僅將用於回應資料901之某一片段的解密金鑰給予給定驗證方及僅將用於回應資料901之另一片段的解密金鑰給予另一驗證方金鑰來達成。解密金鑰之分發可藉由目標方103T或受信任第三方來系統管理。各驗證方或驗證方子集被給予其自身的一或多個解密金鑰之子集，以用於存取回應資料901 (例如，CR對)之片段的各別子集。較佳地，該等子集彼此排斥。然而，在其他實施中，該等子集可重疊(例如，同一組織內的不同群組可存取CR對之重疊子集)。

作為此情況之變體，若回應資料901 (例如，CR對)儲存於第三方系統602中而非鏈上，則替代(或以及)分發解密金鑰，可使用其他手段來確保各驗證方僅存取其自身的CR對(或更一般而言，回應資料)之子集。例如，受信任第三方系統602可針對各驗證方而維護密碼保護帳戶，需要驗證方登入該帳戶以存取其質詢且該帳戶僅允許驗證方存取其自身的CR對。

此類方案可能有利於安全。若待向一個驗證方103V揭示給定CR對之回應Ri，則可能需要同一CR對不用於另一驗證方103V。否則，第一驗證方103V可使用現已知的回應Ri來向另一驗證方假裝其為目標方103T。然而，若信任可存取回應資料901之所有潛在驗證方103V，則採用步驟來防止此情形並非必需的。

在其他變體中，儲存於鏈上之回應資料901可採用目標方103T之公開金鑰的形式，該公開金鑰為在設置時基於對應回應Ri (例如，將其用作種子)產生之公開-私密金鑰對中的公開金鑰。在此狀況下，驗證方103V自儲存交易152S存取公開金鑰，且使用該公開金鑰驗證由目標方103T用對應私密金鑰進行簽名的訊息。在一些狀況下，公開金鑰可以加密形式儲存於鏈上，使得可分配不同公開金鑰以供不同驗證方103V使用。

亦如圖9中所展示，在使用輸出(例如，基於UTXO之)模型的實施例中，接著可利用此輸出模型來提供用於管理CR對(或自其導出之金鑰)之高效機制。此處，管理可包含例如一旦已取用CR對或金鑰(用於驗證中)，便更新或撤銷該CR對或金鑰。

為進行此操作，將新的修改者交易152M記錄於區塊鏈150上。其具有指向儲存交易152S之輸出203中之一者的輸入202，在該輸出中儲存待撤銷或更新之回應資料901的片段。此可被稱作「支出」、「兌換」或「指派」彼輸出(但應注意，此未必暗示貨幣價值之轉移)。此在由驗證方103V辨識之第2層協定之層級理解為意謂不再使用所指向之儲存交易152S或輸出203中的回應資料901。若修改者交易152M自身在其自身輸出中之一者中含有回應資料901'，則此被視為表示：新回應資料901'表示先前回應資料901之替換(例如，新CR對)。若驗證方存取區塊鏈150以尋找供用於驗證操作中之回應資料，則其將使用經更新版本901'而非替換版本。另一方面，若修改者交易152U不含替換回應資料901，則簡單地撤銷其所指向的儲存交易152S或輸出203中之回應資料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。替代地，受信任第三方可發送範本交易以供目標方完成(例如，藉由簽名及/或添加替換回應資料901')且接著直接地或間接地轉遞至節點104上以記錄於鏈上。作為另一種可能性，受信任第三方可制訂修改者交易152M (可能基於範本或自目標部分103T發送之一些資料，例如包含替換回應資料901')，且接著受信任第三方可將修改者交易152M發送至節點104以記錄於鏈上。應注意，所有此等選項亦可適用於儲存交易152S記錄於區塊鏈150上之方式。

根據上文所論述之各種概念，因此提供一種用於進行以下操作之系統：i)將身分(或其他相關資訊，諸如公開金鑰)連結至UTXO，且使用此UTXO之支出狀態作為用於身分憑證之有效性的代理；以及ii)建立一組交易以執行高效身分管理操作，諸如設置、撤銷、更新及驗證。程序更高效，因為通訊之數目減少了，此係因為所有各方可諮詢區塊鏈以查看CRP何時被取用或身分被撤銷，而非所有各方皆需要一直彼此通訊。

如前述所呈現，此類技術可例如用於藉由最小化對用於處置用於驗證中之CRP資料的第三方KYC (瞭解你的客戶)提供者之依賴來擴展用於將身分連結至PUF裝置的架構。此目標可藉由用公共區塊鏈部分地替換KYC提供者之角色，或確切而言替換一些功能來達成，由此使用者可獨立於任何第三方而例項化其自身的與ePUF裝置相關之身分憑證。

受信任第三方在身分系統中之角色未必被完全回避，但無論如何，可改善身分管理之程序使得至少減少受信任第三方在程序中的涉及以及其相關負擔。 5.1. 將 PUF 身分連結至 UTXO 集合

區塊鏈之使用可改善身分系統(諸如，在先前章節中所論述之彼等系統)之第一態樣係藉由使用公共區塊鏈之 未支出交易輸出集合 (UTXO 集合 )來管理與PUF身分相關之CRP。

在此章節中，揭示二個相異的實例機制，其用於將CRP映射至UTXO集合之成員且使用如「支出」或「未支出」狀態之其狀態作為各特定CRP是否已在身分驗證程序中取用的指示。第一機制涉及將CRP資料嵌入可支出UTXO中，且第二機制涉及將其與可支出UTXO 配對。在任一狀況下，與CRP或所討論身分相關之額外資料亦可任擇地包括於系統中。

5.1.1. 嵌入可支出 UTXO 中：第一機制為將CRP繫結至可支出UTXO，其為含有條件可由未來輸入滿足之指令碼且因此可由未來支出交易取用的交易輸出。存在用於實施此嵌入之許多不同選項，但出於吾人的目的，此一般將至少由以下鎖定指令碼組成： [Checksig

] OP_RETURN ＜Rep(

)＞其中[Checksig

]為標準的付款公開金鑰雜湊(P2PKH)鎖定指令碼，且Rep(

)為特定質詢-回應對

之表示。

此鎖定指令碼可簡單地藉由在支出交易上提供有效簽名

來解除鎖定，其中該簽名被視為對公開金鑰

有效。應注意，在驗核支出交易時，將不會考慮在作業碼OP_RETURN之後的任何資料，且因此相對於區塊鏈驗核者，此資料可被視為任意且無格式的。

以上指令碼中在OP_RETURN程式碼之後的資料為質詢-回應對

之表示Rep(

)。取決於所討論之使用案例，可以各種方式進行此表示。然而，合理實例將為使用僅擁有PUF之證明者愛麗絲已知的金鑰

來加密CRP。在此狀況下，吾人可具有以下表示中之任一者： Rep(

)

Encrypt

， Rep(

)

Encrypt

， Rep(

)

Encrypt

。

此等表示將允許愛麗絲稍後分別擷取或證明包括於其UTXO中的質詢、回應或CRP。

額外指令碼負擔 ：可擴展先前所展示之基本鎖定指令碼以便在未來支出輸出之輸入指令碼上包括額外條件。此額外條件之合理實例將為以下指令碼： [Checksig

][Hash Puzzle

] OP_RETURN ＜Rep(

)＞其中[Hash Puzzle

]= OP_HASH160 ＜

＞ OP_EQUAL。應注意，可使用其他雜湊函數作業碼。除提供公開金鑰

之有效簽名以外，此經修改指令碼現亦需要支出者揭露質詢

之雜湊。此處的想法為：在一些情境中，此可用作支出者知曉又與所討論之質詢

相關之資訊

的知識證明。

交易模型 ：鑒於已決定待使用之交易鎖定指令碼的確切結構，可接著作出關於如何將含有此等指令碼之交易結構化為認證儲存、認證及管理CRP之方式的選擇。

本文中揭示以一對一方式將CRP及相關聯鎖定指令碼映射至UTXO。換言之，含有此指令碼之各UTXO將對應於與特定PUF裝置相關之恰好一個CRP。

接著存在關於如何將此等UTXO組織至交易中之幾個選項。最可能的選項如下： 1. 每交易一個CRP。 2. 每交易一個CRP集合。 3. 每交易一個PUF。

第一選項在一些狀況下可適用，諸如適用於極不頻繁使用之PUF，諸如用於更新意願(will)，且具有多個CRP彼此並不明顯地連結的益處。此在需要極端隱私之情形中亦可能有用，此係因為一個CRP之取用及揭露可獨立於任何其他者而揭露。

下表1中之交易為第一選項之實例實施。可見，該交易僅包含單個輸入及輸出，且因此各CRP將含於不同交易中。當支出其輸出時，除用於稽核目的以外，此交易與身分系統之相關性亦被有效地終止。


輸入	輸出
輸出點	指令碼	值	指令碼
		BSV	[Checksig ] OP_RETURN ＜Rep( )＞

表1：單個CRP映射至單個交易中之UTXO。

對於CRP取用之預期頻率顯著較高的使用案例，諸如銀行卡，可能更需要許多CRP各自映射至單個交易中之各別UTXO的第二選項。下表2中之交易展示可如何達成此選項。

應注意，有可能已由愛麗絲產生之輸入簽名可對整個輸出集合進行簽名。此提供自一個公開金鑰

至許多UTXO及因此許多CRP之一對多連結，同時維持UTXO至相異CRP自身之一對一映射。亦假設各輸出/CRP具有其自身的相關聯公開金鑰(全部由愛麗絲擁有)以避免重複使用。


輸入	輸出
輸出點	指令碼	值	指令碼
		BSV	[Checksig ] OP_RETURN ＜Rep( )＞
	BSV	[Checksig ] OP_RETURN ＜Rep( )＞
BSV	[Checksig ] OP_RETURN ＜Rep( )＞
...
BSV	[Checksig ] OP_RETURN ＜Rep( )＞

表2：CRP集合映射至單個交易之各別UTXO

上文所展示之選項亦可與隨時間更新CRP集之實施例良好地整合，其中每次產生經更新集合時，皆可針對彼集合發出新交易。此外，吾人亦可經由並列的獨立(亦即，鏈上不相關)交易針對同一PUF同時產生及發出多個不同CRP集合。此對與多個不同受信任第三方(例如，不同銀行)建立身分可為有用的，使得該等身分皆經獨立地建立但仍由同一PUF錨定。

第三選項，其中單個交易用於表示單個PUF，僅為選項2之更具限制性的版本，其中更新為不可能的。此可適用於含PUF裝置被給予特定「壽命」之狀況，其中在向使用者發放新裝置之前，該含PUF裝置可僅用於預定數目次鑑認。 5.1.2. 與可支出 UTXO 配對

將CRP嵌入可支出UTXO內之替代例為簡單地將其與此等輸出配對。在此狀況下，與現有數位憑證工作的差異在於，交易可由愛麗絲建構及簽名，此係因為其可能希望獨立於任何第三方對身分進行認證。


輸入	輸出
輸出點	指令碼	值	指令碼
		BSV	OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
	0 BSV	OP_0 OP_RETURN ＜Rep( )＞
BSV	OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
0 BSV	OP_0 OP_RETURN ＜Rep( )＞
...
BSV	OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
0 BSV	OP_0 OP_RETURN ＜Rep( )＞

表3：含有映射至CRP之可支出UTXO的交易。

在上圖中可見含有與

個CRP相關之

個輸出的實例交易，由此各可支出輸出可映射至CRP中之一者，且CRP表示自身已包括於對應的不可支出輸出(例如，OP_FALSE OP_RETURN)中。亦應注意，此處類似地應用將CRP組織至交易及UTXO中之三個可能變體。 5.1.3. 論述

CRP 管理之益處：將CRP映射至UTXO之概念可顯著改善先前章節之身分協定之使用者的CRP管理及處置。優點為：吾人可將CRP之儲存及查找部分地卸載至區塊鏈網路106及可促進自其之可靠擷取的服務提供者。

藉由將特定PUF之所有「即時」 CRP映射至UTXO，可藉由查詢UTXO集合之狀態以獲得關於當前可用於身分系統中之給定PUF之CRP的準確資訊來改善CRP更新程序。

利用吾人已描述之區塊鏈及UTXO-CRP映射慣例的簡單程序之實例如下： 1. 愛麗絲獲得PUF裝置且將CRP集合列舉為

。 2. 愛麗絲產生如表2中所展示之交易

且廣播至區塊鏈網路。 3. 愛麗絲隨時間取用多個CRP以向第三方鑑認其身分。 4. 愛麗絲現希望檢查其是否具有足夠的CRP來涵蓋其接下來一週的預期活動： 1. 愛麗絲查詢區塊鏈節點104或類似SPV之服務提供者，詢問

之哪些UTXO當前未支出。 2. 區塊鏈節點或服務提供者以交易

之仍未支出的輸出之數目作為回應。 5. 若傳回數目不足，則愛麗絲可與其受信任第三方產生身分更新程序，或簡單地為獨立建立身分列舉更多CRP。否則，愛麗絲不採取動作。

嵌入對比配對 ：將CRP嵌入可支出輸出內抑或簡單地將其與輸出配對的選擇使愛麗絲在區分此等狀況之二個不同益處之間進行選擇。

若CRP嵌入於可支出輸出內，則此激勵區塊鏈節點104，該等區塊鏈節點維護區塊鏈網路106以使得容易獲得此等輸出之資料。此意謂對愛麗絲之查詢的回應可更快，且更重要地，區塊鏈節點更有可能將此等交易輸出之原始資料伺服回給愛麗絲。

若如前述所論述，包括CRP之表示Rep(

)使得其含有質詢、回應或其二者之原始(或混淆)資料，則此意謂愛麗絲將能夠自區塊鏈網路106擷取相關資訊。此允許愛麗絲替換本端儲存，且使用區塊鏈150操作更 輕量級系統，此係因為將資料嵌入可支出輸出中增加了其資料無論如何皆將具有高 可用性的可能性。

相比之下，若CRP僅與可支出輸出配對，則愛麗絲可僅能夠判定多少CRP可用於其，但未必自比特幣節點擷取表示資料自身。此可意謂若愛麗絲不在本端維護其CRP集合，則其必須諮詢在區塊鏈節點網路106之外的代理。

使用雙雜湊 ：在上文的實例實施中，展示雙雜湊

可用作一些

之鏈上表示。以此方式使用雙雜湊之原因在於，其允許亦在鏈上揭露單雜湊，原則上就像一方知曉

的知識證明，該知識證明又連接至

。

此例如在PUF身分情形中可能有用，其中

由愛麗絲在鏈上記錄為可由提供

之第三方滿足的支出負擔，只要愛麗絲已與其共用

之實際值即可。

多方簽名 ：此章節中詳述之交易可包括來自多個不同方之更多簽名以輔助愛麗絲認證PUF身分，此亦為合理的。舉例而言，可能需要愛麗絲及第三方身分提供者二者對CRP交易之輸入進行簽名，作為改善驗證者對愛麗絲身分之信任的方法。此在會簽者為可認證愛麗絲用於對區塊鏈交易進行簽名之公開金鑰的憑證授權機構的情況下尤其相關。作為僅多個簽名(亦即，「多簽名」)之替代例，多方可例如藉助於臨限簽名或金鑰劃分技術(例如，Shamir秘密共用)而包括於簽名程序中。 5.2. 使用交易之高效身分管理

可結合基於PUF之身分系統(諸如，先前呈現之彼等系統)使用區塊鏈的額外方式係作為撤銷由PUF裝置保護之身分金鑰或符記的高效手段。

在先前的數位憑證管理工作中，已知在鏈上發出及撤銷憑證，且此操作伴隨有對應的憑證驗證程序。考慮當愛麗絲在鏈上認證其基於PUF之身分時很樂意與憑證授權機構協作的情境。愛麗絲為其身分在鏈上註冊憑證之程序如下： 1. 憑證授權機構(CA)驗證愛麗絲之身分。 2. CA創建憑證交易。此交易具有以下輸入及輸出： a. 輸入：CA之UTXO，其具有含有CA之簽名及公開金鑰的解除鎖定指令碼。 b. 輸出1：P2PKH鎖定指令碼。 c. 輸出2：含有愛麗絲之公開金鑰的OP_RETURN輸出。 3. 交易經廣播，且一旦交易被挖掘，CA便向愛麗絲提供交易ID

。

此程序最終導致愛麗絲及憑證授權機構協作以產生由CA簽名之交易，該交易含有包括愛麗絲之公開金鑰上之憑證的一個不可支出輸出及CA可用於撤銷憑證之與憑證配對的可支出輸出。

本文中所揭示之實施例使用上文針對數位憑證所概述之方法與建立基於PUF之身分之方法(諸如，較早所描述之方法中之一者)的混合。此處添加至PUF身分系統之元素使得通用的受信任第三方(類似於CA)能夠藉由支出UTXO來「撤銷」CRP或相關公開金鑰。

受信任第三方撤銷愛麗絲之公開金鑰上之憑證的狀況係關於較早所論述之密碼編譯身分建立。

在鏈上儲存或認證CR對(CRP)之狀況下，本文中所揭示之實施例提供一旦CRP用於鑑認程序中便允許受信任第三方將其撤銷之方案。實例方法如下： 1. 愛麗絲及受信任第三方執行身分設置協定(例如，如較早所描述)。 2. 愛麗絲及受信任第三方現希望使用區塊鏈來管理在1中產生或現可在步驟1之後獲得的CRP： a. 愛麗絲創建將CRP映射至交易輸出之CRP映射交易

。此展示於下表4中。 b. 愛麗絲及受信任第三方二者對

進行簽名 3. CRP映射交易

在區塊鏈區塊中廣播及公佈。

表4： 允許受信任第三方進行 CRP 撤銷 / 取用之 CRP 映射交易

在此程序中創建之映射交易展示於上表4中。此與先前在表2中所展示之CRP映射交易非常類似，其中差異在於受信任第三方及愛麗絲二者對輸入進行簽名，且映射至CRP之UTXO中之各者可藉由受信任第三方在未來交易中支出來撤銷。

此為有利的，此係因為其允許在無直接通訊之情況下處置CRP之撤銷，且TTP可代表使用者執行撤銷，此進一步減少愛麗絲在系統中之負擔且允許其身分管理變得甚至更輕量級。 6. 具有身分驗證之支付驗證系統

實施例可組合本文中所揭示之識別驗證方案中之任一者與支付驗證方案，例如基於區塊鏈之支付驗證方案，諸如簡化支付驗證(SPV)。若二者之輸出為「真」，亦即，目標方之身分及其資金源經驗證，則整個程序之輸出為真且使得支付在其條件下能夠繼續進行。

此可用於例如提供遵從性系統，諸如知曉您的客戶(KYC)系統。在實施例中，所揭示之機制提供隱私保護KYC系統。

在實施例中，組合之支付及身分驗證機制可與例如銷售點終端機或系統合併，以便在進行支付時驗證客戶之身分。下文的實施例將可在此類系統之內容背景中描述，但此並非限制性的且更一般而言，所揭示技術中之任一者可應用於任何系統中以用於進行支付，例如基於網路之支付。

下文將依據作為支付驗證程序之SPV進行例示。然而，此可由用於驗證目標方之資金源的任何程序替換，例如基於非區塊鏈之系統，諸如Worldpay或Visa。另外，雖然產生CR對之構件可為包含PUF或ePUF 500之PUF模組603，但在任何實施例中，更一般而言，此可由基於質詢產生回應之任何構件替換。

簡化支付驗證 (SPV)之概念在2008年首次在比特幣白皮書中被引入，且此後特別在 銷售點 (POS)系統之內容背景中進一步詳述。

圖10中所概述之協定表明在客戶-商家支付互動期間可如何在POS處使用SPV機制以允許商家首先檢查客戶之現有資金的完整性，且稍後確認自客戶向商家之支付已成功。

所說明之POS程序類似於商家銷售點處之現有(亦即，非區塊鏈)支付處理。商家對客戶進行質詢以產生支付，且商家利用支付網路或系統(例如，Visa、Worldpay)以驗證支付在高度確定之情況下有效。

在傳統POS處，此情形藉由商家維持至支付網路之連接及使用此連接且在進行支付時確認客戶在POS處之支付來促進。然而，在非區塊鏈狀況下，自商家之視角，此情形實際上具有雙重目的： 1. 驗證支付；以及 2. 履行遵從義務。

第一點已被涵蓋，但第二點亦可能相關。當客戶在POS系統處進行支付且經由商家POS終端機(或例如網站)連接至支付網路時，此互動亦充當商家履行其遵從金融法規之義務的方式，金融法規諸如 知曉您的客戶 (KYC)及 反洗錢 (AML)法規。

此遵從性態樣可能無法代表商家起作用，且自客戶之視角，遵從性之發生可能並不明顯。然而，吾人可假設連接至支付網路之客戶的動作等同於將其身分帶入支付互動，此又向商家保證可滿足在高於特定價值臨限值之交易中涉及身分的要求。若監管機構或執法人員要求以在需要時完成必要遵從性檢查，則可稍後使用身分之此包括(亦即，與銀行帳戶之連結)。

傳統支付，且特別係商業客戶-商家流程之彼等支付的此第二態樣在基於區塊鏈之模型中顯著不同，且未必由先前詳述之現有SPV互動涵蓋。

根據本文中所揭示之實施例的基於區塊鏈之隱私模型(「新隱私模型」)展示於圖11B中(身分1102-＞防火牆1150-＞交易1104-＞公眾1110)。藉助於比較，如剛剛所論述之現有支付的隱私模型(「傳統隱私模型」)展示於圖11A中(身分1102-＞交易1104-＞受信任第三方1106-＞對方1108-＞防火牆1150-＞公眾1110)。此等情境中之差異為：「身分」組件在支付程序中與其他參與者隔離。

當重新查看圖10中之SPV模型時可見此情形，其中在SPV中不要求在客戶與商家之間交換識別資訊且不需要將此資訊記錄於區塊鏈150自身上。此意謂SPV不滿足由傳統支付系統隱含地達成之法規遵從性的態樣(2)，SPV僅處置支付自身之現場驗證。

本揭露內容之實施例因此藉由在銷售點處結合現有SPV程序實施基於PUF之身分符記系統來提供此問題之解決方案。

所揭示解決方案為使客戶愛麗絲擁有啟用PUF之裝置，諸如銀行卡，其亦兼作離線SPV電子錢包。愛麗絲能夠使用在先前章節中所概述之方法中之一者來使用啟用PUF之銀行卡與身分提供者(亦即，受信任第三方)建立其身分，且隨後使用在愛麗絲與身分提供者之間共用的CRP來執行在支付互動期間由商家調節之身分檢查。 6.1 設置

考慮愛麗絲希望與身分提供者(例如，操作第三方系統602之第三方)建立基於PUF之的情境，該身分提供者可藉助於任意標籤在本文中命名為伊恩(Ian)。

預期愛麗絲將在未來進行涉及許多不同商家之許多支付，由此支付將不會在伊恩在場之情況下進行。因此，在實施例中，愛麗絲及伊恩執行意欲用於許多未來遠端驗證之PUF身分設置程序，此意謂較早章節中之設置模型中之任一者皆可適用。

為簡單起見，可選擇僅愛麗絲可在設置期間存取PUF模組302 (或其他此類回應質詢-回應功能)之變體。此處重複此協定之細節： 1. ePUF裝置經製造且分發給愛麗絲。 2. 愛麗絲藉由聯繫伊恩來申請將其身分連結至其ePUF裝置。 i. 伊恩為愛麗絲建立識別帳戶且請求其身分之證明。 ii. 愛麗絲向伊恩供應相關識別文件或憑證。 iii. 伊恩驗證愛麗絲之身分。 3. 愛麗絲及伊恩經由標準的迪菲-赫爾曼(Diffie-Hellman)金鑰交換為設置程序之其餘部分建立安全通訊通道(例如，如在較早章節中所論述)。 4. 伊恩經由安全通道向愛麗絲發送質詢

之集合。 5. 愛麗絲自ePUF裝置獲得回應

。 6. 愛麗絲經由安全通道向伊恩發送回應

。 7. 伊恩根據愛麗絲之身分帳戶儲存回應CRP集合

。

此設置足以使愛麗絲使用其卡進行至多

次購買(亦即，支付互動)，其中將在各互動期間取用最少一個一次性CRP。應注意，若替代地使用替代設置，由此第三方持有模組603 (或其他此類質詢-回應功能)，則伊恩及愛麗絲事先將不會共用

個CRP，而是伊恩可繼續獨立地產生CRP且在支付互動時將質詢提交至愛麗絲。 6.2 支付互動

考慮愛麗絲希望在命名為鮑勃之商家的POS處進行購買的稍後時間點。

為了初始化下方的支付(步驟0)，鮑勃根據來自圖10之現有SPV模型向愛麗絲發出SPV支付請求。支付互動接著分成二個並行分支：(i)現有SPV支付互動，及(ii)下文所詳述之KYC遵從協定。此程序亦在圖12中可視，該圖僅展示分支2之編號程序。 0. 鮑勃向愛麗絲發出SPV支付請求。並行地執行以下分支。

分支 1 ：1. 執行圖17之現有SPV機制。 2. 若程序成功完成，則傳回TRUE，否則傳回FALSE。

分支 2 ：1. 鮑勃向愛麗絲之身分提供者伊恩請求CRP*。 2. 伊恩向鮑勃提供未使用的CRP

。 3. 鮑勃向愛麗絲呈現質詢

且詢問其裝置之回應**。 4. 愛麗絲將質詢

傳遞至其PUF且產生候選回應

。 5. 愛麗絲將候選回應

發送至鮑勃。 6. 鮑勃檢查回應匹配且若

，則傳回TRUE，否則傳回FALSE。 7. 若(且僅當)二個分支均傳回TRUE，則將支付提交至比特幣網路。

*可存在鮑勃基於愛麗絲給予鮑勃之資訊而判定愛麗絲之身分提供者為何者(假設存在許多可能性)的步驟。此可作為步驟0之部分而包括，其中愛麗絲將用此對步驟0作出回應。

**此可藉由(例如)卡終端機來實施。其中愛麗絲將其卡置於終端機中以作出回應。替代地，其可為NFC或僅為自鮑勃之POS終端機發送至愛麗絲之裝置(例如，含有PUF之行動電話)的訊息。

應注意：此程序不限於PUF模組602之程序，且更一般而言，C,R對可抽象化為任何種類之鑑認符記。然而，PUF使得此程序更穩健，此係因為PUF之作用類似於單向功能(更容易儲存，可即時運算回應)且不必將數位金鑰儲存於記憶體中。

自遵從性視角，上文所概述之機制允許商家履行其在支付互動內的義務。此意謂商家可確信，藉由與身分提供者通訊及與標準SPV檢查程序並行地執行識別驗證程序，商家已 主動地參與例如所需的KYC及AML預防措施。

上述協定達成促進區塊鏈交易之KYC/AML遵從性同時保護終端使用者愛麗絲之隱私的目標。商家鮑勃僅必須在上述遵從程序期間處理CRP資料

，而無需洩漏關於愛麗絲自身的任何識別資訊。此外，各CRP為一次性的，使得鮑勃對特定CRP之知曉不會損害關於愛麗絲之任何資訊，以便在不同支付互動期間進行未來身分驗證。

若此協定與基於區塊鏈之CRP管理系統組合，則在愛麗絲丟失對其PUF之實體控制(例如，失去PUF)的情況下，此亦允許在鏈上立即撤銷CRP。此意謂KYC有助於保護愛麗絲在其失去其裝置/卡之情況下免受欺詐，且使其以及商家受益。此處，區塊鏈及其同級間網路藉由確保CRP之撤銷可經由網路極快地傳播來提高程序之速度。

作為另一替代或額外擴展，愛麗絲用於向鮑勃進行支付之支出交易可在彼交易之酬載中包括符記，該符記證明身分驗證程序已通過。 7. 結論

一旦給定本文中之揭露內容，所揭示技術之其他變體或使用案例對於熟習此項技術者可變得顯而易見。本揭露內容之範圍不受所描述實施例限制而僅受隨附申請專利範圍限制。

舉例而言，上文的一些實施例已關於比特幣網路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。一種授權目標方向驗證方之支付的電腦實施方法，該方法包含藉由驗證方進行以下操作：執行支付驗證以驗證目標方之資金源且在目標通過支付驗證之條件下輸出真之結果；以及執行身分驗證以驗證目標方之身分。該身分驗證包含：存取關聯地結合目標方之身分儲存於資料存放區中之回應資料，該資料存放區實施於受信任第三方之第三方電腦裝備中或實施於同級間公佈媒體上，其中該回應資料包含a)對質詢之回應的所儲存例項，或b)包含回應之變換的認證；將包含質詢之請求發送至目標方且作為回應，接收回回應之另一例項；以及執行比較且在匹配之條件下輸出真之結果，該比較包含a)比較回應之所儲存例項與回應之另一例項，或b)比較認證與應用於回應之另一例項的相同變換。在支付驗證及身分驗證二者之輸出均為真的條件下授權支付。

陳述項2。如陳述項1之方法，其中回應為已藉由除驗證方以外之一方在該方法之前的設置階段中將質詢輸入至包含實體不可仿製之功能PUF之PUF模組中的結果，該模組使用PUF取決於預定質詢而產生所儲存回應。

陳述項3。如陳述項2之方法，其中PUF模組包含PUF及判定性變換函數，且經組配以藉由以下操作產生回應：將基礎輸入輸入至PUF中以產生對應基礎輸出；以及輸入質詢且結合所產生基礎輸出而輸入至變換函數中以便產生回應，該變換函數為質詢及所產生基礎輸出之函數。

陳述項4。如陳述項22或3之方法，其中執行設置之該方為目標方。

陳述項5。如前述陳述項中任一項之方法，其中該請求及接收回係經由安全通道執行，該安全通道係基於在驗證方與目標方之間共用的共用秘密進行保護。

陳述項6。如前述陳述項中任一項之方法，其中資料存放區實施於第三方電腦裝備中。

陳述項7。如陳述項6之方法，其中該第三方電腦裝備包含伺服器裝備，該伺服器裝備包含一或多個地理站點處之一或多個伺服器單元。

陳述項8。如陳述項6或7之方法，其中執行設置之該方為受信任第三方。

陳述項9。如陳述項6至8中任一項之方法，其中回應資料係經由安全通道自第三方電腦裝備之資料存放區存取，該安全通道係基於在驗證方與受信任第三方之間共用的共用秘密進行保護。

陳述項10。如陳述項6至9中任一項之方法，其中該方法包含自受信任第三方接收質詢及回應資料，由驗證方發送之該請求包含如自受信任第三方接收之質詢。

陳述項11。如陳述項10之方法，其中質詢係經由安全通道自第三方電腦裝備之資料存放區接收，該安全通道係基於在驗證方與受信任第三方之間共用的共用秘密進行保護。

陳述項12。如陳述項1至5中任一項之方法，其中該資料存放區實施於同級間公佈媒體中。

陳述項13。如陳述項12之方法，其中該同級間公佈媒體為區塊鏈。

陳述項14。如陳述項13之方法，其中該方法包含自區塊鏈存取質詢及回應資料，直接地自區塊鏈網路之節點存取或間接地經由一或多個中間服務提供者存取，其中由驗證方發送之該請求包含如自區塊鏈接收存取之質詢。

陳述項15。如陳述項13或14之方法，其中回應資料儲存於記錄在區塊鏈上之儲存交易的輸出中，且身分驗證進一步包含檢查回應資料尚未由已記錄於區塊鏈上之另一交易撤銷，該另一交易具有指向儲存交易之輸出的輸入；其中身分驗證之輸出結果進一步取決於根據該檢查尚未撤銷之回應資料。

陳述項16。如陳述項15之方法，其中回應資料儲存於儲存交易之可支出輸出中，且該檢查包含檢查另一交易之輸入不會藉由指向同一可支出輸出而撤銷回應資料。

陳述項17。如陳述項15之方法，其中回應資料儲存於儲存交易之不可支出輸出中，且該檢查包含檢查另一交易之輸入不會藉由指向同一儲存交易之可支出輸出而撤銷回應資料。

陳述項18。如前述陳述項中任一項之方法，其中資金源包含記錄於區塊鏈上之一或多個資金交易，待授權之支付包含指向資金交易之支出交易。

陳述項19。如陳述項18之方法，其包含在支付驗證及身分驗證二者之結果均為真的條件下提供待包括於支出交易之酬載中的符記，該符記證明身分驗證之結果。

陳述項20。如陳述項18或19之方法，其中支付驗證包含簡化支付驗證SPV程序。

陳述項21。如前述陳述項中任一項之方法，其中該方法係自銷售點終端機執行。

陳述項22。一種電腦裝備，其包含：記憶體，其包含一或多個記憶體單元；以及處理設備，其包含一或多個處理單元，其中該記憶體儲存經配置以在處理設備上運行之程式碼，該程式碼經組配以便在處於處理設備上時執行如前述陳述項中任一項之方法。

陳述項23。一種電腦程式，其體現於非暫時性電腦可讀媒體上且經組配以便在運行於一或多個處理器上時執行如陳述項1至21中任一項之方法。

100:系統 101:封包交換網路 102a,102b:電腦設備/裝置 102V,102T:電腦設備 103:使用者/驗證方/代理 103S:提交方 103T:目標方 103V:驗證方 103a:原始使用者/實體/愛麗絲/第一方 103b:新使用者/實體/鮑勃/第二方 104:第一區塊鏈節點/比特幣節點 105:用戶端應用程式/軟體 106:區塊鏈節點網路/同級間(P2P)網路/比特幣網路 150:區塊鏈 151:資料區塊 151n-1:先前創建區塊 151n:新區塊 152:先前交易/原始交易 152i:先前交易 152j:目前交易/新接收交易/新驗核交易 152S:儲存交易 152M:修改者交易 153:起源區塊(Gb) 154:有序集合/有序集區 155:區塊指標 201:標頭 202:輸入/輸入欄位 203:輸出欄位/未支出交易輸出 302:弱PUF組件/組成基礎PUF/弱PUF 402:處理器 404:介面邏輯 404':介面邏輯/介面邏輯組件/介面功能/介面邏輯模組 406:存取控制邏輯/控制邏輯模組/控制邏輯組件/存取控制元件 500:擴展PUF (ePUF) 502:變換函數 601:回應資料存放區 602:第三方電腦設備/受信任第三方系統 603:PUF模組 702:設置階段/設置 704:驗證階段/驗證 710,720,730,740,750,760,770:步驟 802:資料元素/識別資訊 804:組合 806:識別資訊/識別資料 901:儲存資料/回應資料 901':回應資料/更更新版本 1102:身分 1104:交易 1106:受信任第三方 1108:對方 1110:公眾 1150:防火牆 C:質詢 Ci:次要質詢 Cm:主要質詢 Cw:主要質詢/基礎質詢 R:回應 Ri:次要回應 Rw:主要回應/基礎回應

為了輔助理解本揭露內容之實施例且展示此等實施例可如何付諸實施，僅作為實例參看附圖，在附圖中：圖1為用於實施區塊鏈之系統的示意性方塊圖，圖2示意性地說明可記錄於區塊鏈中之交易的一些實例，圖3示意性地說明PUF之質詢及回應，圖4為包含PUF之系統的示意性方塊圖，圖5A為根據本文中所揭示之實施例的擴展PUF之示意性方塊圖，圖5B為在非擴展操作模式中之擴展PUF的示意性方塊圖，圖6為在分發質詢-回應對時涉及受信任第三方或公佈媒體的系統之示意性說明，以及圖7為根據本文中所揭示之實施例的驗證程序之示意性流程圖，圖8A至圖8C示意性地說明根據本文中所揭示之實施例的自主質詢產生質詢集合之方法，圖9示意性地說明將回應資料記錄於鏈上之方法, 圖10示意性地說明在愛麗絲(客戶)與鮑勃(商家)之間進行的商業SPV程序流程，圖11A為傳統隱私模型之示意性方塊圖，且圖11B為根據本文中所揭示之實施例的隱私模型之示意性方塊圖，以及圖12示意性地說明根據本文中所揭示之實施例的與SPV流程一起之支付互動(編號)的「遵從性」分支。

1102:身分

1104:交易

1110:公眾

1150:防火牆

Claims

一種授權一目標方向一驗證方之一支付的電腦實施方法，該方法包含藉由該驗證方進行以下操作：執行一支付驗證以驗證該目標方之一資金源且在目標通過該支付驗證之條件下輸出真之一結果；執行一身分驗證以驗證該目標方之一身分，該身分驗證包含： -存取關聯地結合該目標方之該身分儲存於一資料存放區中的回應資料，該資料存放區實施於一受信任第三方之第三方電腦裝備中或實施於一同級間公佈媒體上，其中該回應資料包含a)對一質詢之一回應的一所儲存例項，或b)包含該回應之一變換的一認證； -將包含該質詢之一請求發送至該目標方且作為回應，接收回該回應之另一例項；以及 -執行一比較且在一匹配之條件下輸出真之一結果，該比較包含a)比較該回應之該所儲存例項與該回應之該另一例項，或b)比較該認證與應用於該回應之該另一例項的相同變換；其中在該支付驗證及該身分驗證二者之該等輸出均為真的條件下授權該支付。
如請求項1之方法，其中該回應為已藉由除該驗證方以外之一方在該方法之前的一設置階段中將該質詢輸入至包含一實體不可仿製之功能PUF之一PUF模組中的一結果，該模組使用該PUF取決於預定質詢而產生所儲存回應。
如請求項2之方法，其中該PUF模組包含一PUF及一判定性變換函數，且經組配以藉由以下操作產生該回應： -將一基礎輸入輸入至該PUF中以產生一對應基礎輸出；以及 -輸入該質詢且結合所產生基礎輸出而輸入至該變換函數中以便產生該回應，該變換函數為該質詢及該所產生基礎輸出之一函數。
如請求項2或3之方法，其中執行設置之該方為該目標方。
如前述請求項1至4中任一項之方法，其中該請求及該接收回係經由一安全通道執行，該安全通道係基於在該驗證方與該目標方之間共用的一共用秘密進行保護。
如前述請求項1至5中任一項之方法，其中該資料存放區實施於該第三方電腦裝備中。
如請求項6之方法，其中該第三方電腦裝備包含伺服器裝備，該伺服器裝備包含一或多個地理站點處之一或多個伺服器單元。
如請求項6或7之方法，其中執行該設置之該方為該受信任第三方。
如請求項6至8中任一項之方法，其中該回應資料係經由一安全通道自該第三方電腦裝備之該資料存放區存取，該安全通道係基於在該驗證方與該受信任第三方之間共用的一共用秘密進行保護。
如請求項6至9中任一項之方法，其中該方法包含自該受信任第三方接收該質詢及該回應資料，由該驗證方發送之該請求包含如自該受信任第三方接收之該質詢。
如請求項10之方法，其中該質詢係經由一安全通道自該第三方電腦裝備之該資料存放區接收，該安全通道係基於在該驗證方與該受信任第三方之間共用的一共用秘密進行保護。
如請求項1至5中任一項之方法，其中該資料存放區實施於該同級間公佈媒體中。
如請求項12之方法，其中該同級間公佈媒體為一區塊鏈。
如請求項13之方法，其中該方法包含自該區塊鏈存取該質詢及該回應資料，直接地自一區塊鏈網路之一節點存取或間接地經由一或多個中間服務提供者存取，其中由該驗證方發送之該請求包含如自該區塊鏈接收存取之該質詢。
如請求項13或14之方法，其中該回應資料儲存於記錄在該區塊鏈上之一儲存交易的一輸出中，且該身分驗證進一步包含檢查該回應資料尚未由已記錄於該區塊鏈上之另一交易撤銷，該另一交易具有指向該儲存交易之一輸出的一輸入；其中該身分驗證之輸出結果進一步取決於根據該檢查尚未撤銷之該回應資料。
如請求項15之方法，其中該回應資料儲存於該儲存交易之一可支出輸出中，且該檢查包含檢查另一交易之該輸入不會藉由指向同一可支出輸出而撤銷該回應資料。
如請求項15之方法，其中該回應資料儲存於該儲存交易之一不可支出輸出中，且該檢查包含檢查另一交易之該輸入不會藉由指向同一儲存交易之一可支出輸出而撤銷該回應資料。
如前述請求項1至17中任一項之方法，其中該資金源包含記錄於一區塊鏈上之一或多個資金交易，待授權之該支付包含指向該資金交易之一支出交易。
如請求項18之方法，其包含在該支付驗證及該身分驗證二者之該等結果均為真的條件下提供待包括於該支出交易之一酬載中的一符記，該符記證明該身分驗證之該結果。
如請求項18或19之方法，其中該支付驗證包含一簡化支付驗證SPV程序。
如前述請求項1至20中任一項之方法，其中該方法係自一銷售點終端機執行。
一種電腦裝備，其包含：記憶體，其包含一或多個記憶體單元；以及處理設備，其包含一或多個處理單元，其中該記憶體儲存經配置以在該處理設備上運行之程式碼，該程式碼經組配以便在處於該處理設備上時執行如前述請求項1至21中任一項之方法。
一種電腦程式，其體現於一非暫時性電腦可讀媒體上且經組配以便在運行於一或多個處理器上時執行如請求項1至21中任一項之方法。