CN116158053A - 离线交互系统和方法 - Google Patents

离线交互系统和方法 Download PDF

Info

Publication number
CN116158053A
CN116158053A CN202180059805.1A CN202180059805A CN116158053A CN 116158053 A CN116158053 A CN 116158053A CN 202180059805 A CN202180059805 A CN 202180059805A CN 116158053 A CN116158053 A CN 116158053A
Authority
CN
China
Prior art keywords
amount
offline
credential
server computer
server
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202180059805.1A
Other languages
English (en)
Inventor
M·扎马尼
R·库马雷桑
M·克里斯托多雷斯库
C·谢菲尔德
B·普赖斯
W·顾
徐明华
S·拉古拉曼
M·萨阿德
M·奥兹达伊
M·M·米纳伊比多利
S·达斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
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 Visa International Service Association filed Critical Visa International Service Association
Publication of CN116158053A publication Critical patent/CN116158053A/zh
Pending legal-status Critical Current

Links

Images

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/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
    • H04L9/3255—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 using group based signatures, e.g. ring or threshold signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/3239—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 non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • 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
    • 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/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种方法包括第一装置从第二装置接收包括数额和第二装置凭证的交互请求消息。所述第一装置可使用对应于服务器计算机私钥的服务器计算机公钥来验证所述第二装置凭证。所述第一装置的安全元件中的可信应用程序可确定所述数额是否小于存储在所述安全元件中的离线数额。在所述数额小于所述离线数额的情况下，所述可信应用程序可基于所述数额而确定经更新离线数额。所述可信应用程序可生成包括所述数额和可信应用程序凭证的交互响应消息。接着，所述第一装置可向所述第二装置提供所述交互响应消息。

Description

离线交互系统和方法
相关申请交叉引用
本申请要求于2020年7月23日提交的第63/055,761号美国临时专利申请、于2020年10月9日提交的第63/090,104号美国临时专利申请以及于2020年12月14日提交的第63/125,305号美国临时专利申请的权益，所述美国临时专利申请出于所有目的以引用的方式整体并入。
背景技术
传统上，数字交互是通过基于账户的系统进行的，其中资金的所有权与用户身份相关联。数字交互系统通常基于作为对象存在的令牌，其中资金的所有权通过用户对私人密码密钥的访问来确定。然而，数字交互缺少实体(例如，非数字)交互中存在的许多方面。实物资金的核心特征之一是能够以点对点方式离线交互而不需要中介。这使得实物资金能够充当一种弹性交互系统，用户和资源提供商可以使用它进行交互，而不需要依赖于第三方。
对于访问装置无法连接到授权计算机以得到授权的情况，现有交互网络可以提供某种形式的离线数字交互。然而，此类方法是不安全的。例如，用户可能实际上没有必需的资金来执行交互。然而，直到交互完成之后并且资源提供商重新上线时，资源提供商才会知晓这一点。
实施例单独地和共同地解决了这些和其它问题。
发明内容
一个实施例涉及一种方法，包括：由第一装置从第二装置接收包括数额和第二装置凭证的交互请求消息；由所述第一装置使用对应于服务器私钥的服务器计算机公钥来验证所述第二装置凭证；由所述第一装置的安全元件中的可信应用程序确定所述数额是否小于存储在所述安全元件中的离线数额；在所述数额小于所述离线数额的情况下，由所述可信应用程序基于所述数额而确定经更新离线数额；由所述可信应用程序生成包括所述数额和可信应用程序凭证的交互响应消息；由所述可信应用程序使用可信应用程序私钥对所述交互响应消息进行签名以产生交互响应消息签名；以及由所述第一装置向所述第二装置提供包括所述交互响应消息签名的所述交互响应消息。
另一实施例涉及第一装置，包括：处理器；以及耦合到所述处理器的计算机可读介质，所述计算机可读介质包括代码，所述代码可由所述处理器执行以实施一种方法，所述方法包括：由所述第一装置从第二装置接收包括数额和第二装置凭证的交互请求消息；使用对应于用于对所述第二装置凭证进行签名的服务器私钥的服务器计算机公钥来验证所述第二装置凭证；由所述第一装置的安全元件中的可信应用程序确定所述数额是否小于存储在所述安全元件中的离线数额；在所述数额小于所述离线数额的情况下，由所述可信应用程序基于所述数额而确定经更新离线数额；由所述可信应用程序生成包括所述数额和可信应用程序凭证的交互响应消息；由所述可信应用程序使用可信应用程序私钥对所述交互响应消息进行签名以产生交互响应消息签名；以及由所述第一装置向所述第二装置提供包括所述交互响应消息签名的所述交互响应消息。
另一实施例涉及一种方法，包括：由第二装置生成包括数额和第二装置凭证的交互请求消息；由所述第二装置向第一装置提供所述交互请求消息，其中所述第一装置使用对应于服务器私钥的服务器计算机公钥来验证所述第二装置凭证，确定所述数额是否小于存储在所述第一装置上的安全元件中的离线数额，基于所述数额而确定经更新离线数额，生成包括所述数额和可信应用程序凭证的交互响应消息，使用可信应用程序私钥对所述交互响应消息进行签名以产生交互响应消息签名；由所述第二装置接收包括所述交互响应消息签名的所述交互响应消息；以及由所述第二装置暂时存储所述交互响应消息。
关于本公开的实施例的另外的细节可以在具体实施方式和附图中找到。
附图说明
图1示出根据实施例的交互处理系统的框图。
图2示出根据实施例的可为用户装置的第一装置的组件的框图。
图3绘示根据实施例的托管可信执行环境的装置的概述。
图4示出根据实施例的预交互处理方法。
图5示出根据实施例的交互处理方法。
图6绘示根据实施例的分级离线交互系统。
图7绘示根据实施例的与分级双层次模型集成的离线交互系统。
图8A-8C绘示根据实施例的离线交互系统中的链式交互。
图9A-9B绘示根据实施例的离线交互系统中的链式交互的聚集。
具体实施方式
在论述本公开的实施例之前，可以进一步详细描述一些术语。
“用户装置”可以是由用户操作的装置。用户装置的实例可以包括移动电话、智能手机、卡、个人数字助理(PDA)、膝上型计算机、台式计算机、服务器计算机、车辆(例如汽车)、精简客户端装置、平板式PC，等等。此外，用户装置可以是任何类型的可穿戴技术装置，例如手表、耳机、眼镜等。用户装置可包括能够处理用户输入的一个或多个处理器。用户装置还可以包括用于接收用户输入的一个或多个输入传感器。存在能够检测用户输入的各种输入传感器，例如，加速度计、相机、麦克风等。由输入传感器获得的用户输入可以来自多种数据输入类型，包括但不限于音频数据、视觉数据或生物特征数据。用户装置可以包括用户可以操作的任何电子装置，所述电子装置还可以提供与网络的远程通信能力。远程通信能力的实例包括使用移动电话(无线)网络、无线数据网络(例如，3G、4G或类似网络)、Wi-Fi、Wi-Max，或者可以提供对网络(例如互联网或专用网络)的访问的任何其它通信介质。
“用户”可以包括个人。在一些实施例中，用户可与一个或多个个人账户和/或移动装置相关联。在一些实施例中，用户也可以被称为持卡人、账户持有人或消费者。在一些实施例中，资源提供商可以是用户，并且可以操作用户装置。
“安全元件”可包括安全的元件。安全元件可包括密码安全的芯片上计算机或微处理器。安全元件可实行密码操作，并且可嵌入具有一种或多种物理安全措施的封装中。在一些实施例中，“安全元件”可包括可安全地执行功能的组件。安全元件可以是安全地存储数据的存储器，使得其访问受到保护。安全元件可包括处理器的安全区域上的可信执行环境。安全元件的实例是通用集成电路卡(UICC)。安全元件的另一实例是嵌入式安全元件，在更大的机械或电气系统中的嵌入式硬件组件。安全元件的另一实例是硬件安全模块(HSM)，它是一个物理计算装置，可保护和管理用于认证的密码密钥，并提供密码处理功能。
“可信执行环境”(TEE)可包括用于处理数据的安全区域。可信执行环境可以是存储在只读存储器(ROM)上的软件堆栈。可信执行环境可包括在安全元件内。可信执行环境软件堆栈可包括用于访问安全元件的一组资源，提供开发人员对底层安全元件的访问的可信操作系统(TOS)，以及在可信应用程序环境内实施特定于应用程序的功能性的一个或多个可信应用程序(TA)。
在一些实施例中，可信执行环境可以是隔离执行环境，其提供安全特征，例如隔离执行、利用可信执行环境执行的应用程序的完整性及其资产的机密性。可信执行环境可提供执行空间，所述执行空间为在装置上运行的可信应用程序提供比富操作系统更高的安全级别以及比单独的安全元件更多的功能性。
“可信应用程序”可包括在可信执行环境内实施的应用程序。可信应用程序可执行特定功能性。可信应用程序可与特定于应用程序的客户端应用程序(CA)配对，所述CA驻存在隔离的可信执行环境空间之外并通过经由可信操作系统与可信应用程序交互来提供面向用户的功能性。
“访问装置”可以是提供对远程系统的访问的任何合适的装置。访问装置还可以用于与协调计算机、通信网络或任何其它合适的系统通信。访问装置通常可以位于任何合适的位置处，例如位于商家所在位置处。访问装置可呈任何合适的形式。访问装置的一些实例包括POS或销售点装置(例如，POS终端)、蜂窝电话、个人数字助理(PDA)、个人计算机(PC)、平板PC、手持式专用读取器、机顶盒、电子收款机(ECR)、自动贩卖机、自动取款机(ATM)、虚拟收款机(VCR)、查询一体机、安全系统、访问系统等。访问装置可使用任何合适的接触或非接触操作模式，以发送或接收来自移动通信装置或者支付装置的数据或与移动通信装置或者支付装置相关联的数据。例如，访问装置可以具有读卡器，所述读卡器可以包括电触头、射频(RF)天线、光学扫描器、条形码读取器或磁条读取器以与例如支付卡之类的便携式装置交互。在一些实施例中，当用户装置由第一用户操作时，访问装置可以是由第二用户操作的用户装置。
“交互”可以包括互惠作用或影响。“交互”可以包括各方、各装置和/或各实体之间的通信、联系或交换。示例交互包括两方之间的交易和两个装置之间的数据交换。在其它实施例中，交互可以包括支付交易，在所述支付交易中，两个装置可以交互以促进支付。
“交互数据”可以包括与交互相关的数据和/或在交互期间记录的数据。在一些实施例中，交互数据可以是网络数据的交易数据。交易数据可以包括具有数据值的多个数据元素。
“凭证”可以包括权限、权利或享有特权的任何证据。例如，访问凭证可以包括对访问某些有形或无形资产(例如建筑物或文件)的许可。凭证的实例可以包括密码、通行码或机密消息。在另一个实例中，支付凭证可以包括与账户(例如，支付账户和/或与该账户相关联的支付装置)相关联和/或标识账户的任何合适信息。这种信息可以与账户直接相关，或者可以从与账户相关的信息中导出。账户信息的实例可以包括“账户标识符”，例如PAN(主账号或“账号”)、令牌、子令牌、礼品卡号码或代码、预付卡号码或代码、用户名称、截止日期、CVV(卡验证值)、dCVV(动态卡验证值)、CVV2(卡验证值2)、CVC3卡验证值，等等。PAN的实例是16位数字，例如“41470900 0000 1234”。在一些实施例中，凭证可以被视为敏感信息。
“数额”可包括某物的数量。数额可包括事物或多个事物在数目、大小、值或范围上的总数。
“离线数额”可包括离线时(即，当不存在与服务器计算机的直接通信时)可使用的某物的数量。离线数额可本地存储在用户装置上。例如，离线数额可存储在用户装置上的安全元件中。可在离线交互期间利用离线数额。例如，第一用户可选择在第一用户的装置未连接到服务器计算机或未与服务器计算机通信(例如，非在线)时向第二用户提供数额。第一装置可从存储在安全元件中的离线数额中扣除要提供的数额。
“在线数额”可包括在线时可使用的某物的数量。在线数额可存储在服务器计算机上。例如，与多个用户相关联的多个在线数额可存储在服务器计算机和/或由服务器计算机维护的数据库上。在一些实施例中，可在在线交互期间利用在线数额。在其它实施例中，来自服务器计算机上的在线数额中的数额可转移到用户装置上的离线数额。例如，服务器计算机可从与第一用户相关联的在线数额中扣除某一数额，接着在安全消息中向第一装置提供该数额。第一装置可将接收到的数额包括到存储在安全元件中的离线数额中。
“资源提供商”可以是可以提供例如商品、服务、信息和/或访问等资源的实体。资源提供商的实例包括商家、数据提供商、交通部门、政府实体、场地和住宅运营商等。
术语“验证”及其派生词可以指利用信息来确定潜在的主体在一组给定的情况下是否有效的过程。验证可以包括任何信息比较以确保某些数据或信息是正确的、有效的、准确的、合法的和/或信誉良好的。
术语“公钥/私钥对”可包括由实体生成的一对关联密码密钥。公钥可用于例如对要发送到实体的消息进行加密等功能，或用于对应该由实体作出的数字签名进行验证。私钥可用于例如对接收到的消息进行解密或应用数字签名等功能。公钥可由凭证授权中心进行授权，所述凭证授权中心可将公钥存储在数据库中并将其分配给请求公钥的任何其它实体。私钥可保持在安全存储介质中，且通常将仅为所述实体所知。然而，本文中描述的密码系统可具有用于恢复丢失的密钥并避免数据丢失的密钥恢复机制。公钥和私钥可以是任何适当格式，包括基于Rivest-Shamir-Adleman(RSA)或椭圆曲线密码学(ECC)的格式。
“数字签名”可包括一种类型的电子签名。数字签名可用数字码对文件进行加密，所述数字码可能难以复制。在一些实施例中，“数字签名”可以指基于公钥/私钥对应用算法的结果，所述算法允许签名方表明和验证方验证文件的真实性和完整性。签名方借助于私钥起作用，验证方借助于公钥起作用。这个过程证明发送方的真实性、已签名文件的完整性和所称的不可否认性原则，所述原则不允许否认已经签名的内容。凭证或包括签名方的数字签名的其它数据被称为是由签名方“签名的”。
“凭证”或“数字凭证”可包括电子文件和/或数据文件。在某些情况下，凭证或数字凭证可以是装置凭证。在一些实施例中，数字凭证可使用数字签名来将公钥与同身份相关联的数据绑定。数字凭证可用于证明公钥的所有权。凭证可包括一个或多个数据字段，例如身份的合法名称、凭证的序列号、凭证的起始有效日期和终止有效日期、凭证相关许可等。凭证可包含指示凭证有效的第一个日期的“起始有效”日期，以及指示凭证有效的最后日期的“终止有效”日期。凭证还可以包含凭证中包括数据字段的数据的散列。凭证可由凭证授权中心签名。
“凭证授权中心”(CA)可包括发行数字凭证的实体。凭证授权中心可使用凭证授权中心凭证来证明其身份，凭证授权中心凭证包括凭证授权中心的公钥。凭证授权中心凭证可用另一凭证授权中心的私钥进行签名，或可用同一凭证授权中心的私钥进行签名。后者被称为自签名凭证。凭证授权中心可维护由凭证授权中心发出的所有凭证的数据库。凭证授权中心可维护被撤销凭证的列表。凭证授权中心可由实体操作，所述实体例如处理网络实体、发行方、收单方、中央银行等。
“处理器”可以包括处理某事的装置。在一些实施例中，处理器可以包括任何合适的一个或多个数据计算装置。处理器可以包括一起工作以实现期望的功能的一个或多个微处理器。处理器可以包括CPU，所述CPU包括至少一个高速数据处理器，所述高速数据处理器足以执行用于执行用户和/或系统生成的请求的程序成分。CPU可以是微处理器，例如AMD的Athlon、Duron和/或Opteron；IBM和/或Motorola的PowerPC；IBM和Sony的Cell处理器；Intel的Celeron、Itanium、Pentium、Xeon和/或XScale；和/或类似的处理器。
“存储器”可以是可存储电子数据的任何合适的装置。合适的存储器可以包括存储指令的非瞬态计算机可读介质，所述指令能够由处理器执行以实施期望的方法。存储器的实例可以包括一个或多个存储器芯片、磁盘驱动器等。此类存储器可使用任何合适的电气、光学和/或磁性操作模式来操作。
“服务器计算机”可以包括功能强大的计算机或计算机集群。例如，服务器计算机可以是大型主机、小型计算机集群或作为一个单元运作的一组服务器。在一个示例中，服务器计算机可以是耦合到Web服务器的数据库服务器。服务器计算机可包括一个或多个计算设备，并且可使用各种计算结构、布置和编译中的任一种来服务来自一个或多个客户端计算机的请求。
I.引言
本文中描述了一种离线交互系统(OIS)，其允许用户执行与另一用户或资源提供商的数字交互，而双方暂时相对于交互中介(例如，网络处理计算机、凭证授权中心、传输计算机、授权实体计算机等；或在一些实施例中，因特网)离线。离线交互系统可用于通过点对点信道离线即时转移任何合适形式的数字货币，从而实现几乎无限的吞吐量和实时交互延迟。
各种实施例可确保在离线交互期间资金不能被二次花费(例如，用户不能多次利用数额)，因为不存在任何可信中介来防止重放攻击。实施例呈现离线交互系统协议，所述离线交互系统协议通过利用可信执行环境(TEE)生成的数字签名来防止二次花费，所述数字签名在用户装置(例如，智能手机、平板计算机等)上可用。虽然可信执行环境为离线装置带来主要的信任点，但离线交互系统可利用若干密码协议，以确保多个支持TEE的装置之间的安全资金交换，从而确保可靠且安全的交互处理系统。
本文中所描述的各种实施例提供一种离线交互系统，其允许用户(例如，客户)在两个用户暂时相对于中间装置离线时执行与另一用户(例如，资源提供商或第二用户)的数字交互。接下来，实施例构建离线交互系统协议，其允许使用与现有数字交互系统相比显著降低参与者的载入开销的公钥基础设施来对离线交互进行点对点授权。一旦预配好，离线交互系统数字钱包就可通过任何合适的通信信道安全地对交互消息进行签名并直接相互发送交互消息，而无需中介来授权和结算交互。接收离线交互系统数字钱包可将离线时接收到的经签名交互消息提交到授权实体计算机(例如，经由传输计算机、网络处理计算机和/或本文中所描述的任何其它装置)，同时保证结算这些交互以便从离线交互系统中提取资金。
A.各种实施例的概述
考虑两种装置：第一装置和第二装置，持有关于服务器计算机S的在线账户。各种实施例实现账户维护关于某一装置的用户在服务器计算机S处持有的金额的信息(例如，余额)。根据实施例的离线交互系统协议的一个目标是允许第一装置与第二装置交互以向服务器计算机S提供由x表示的从第一装置的账户到第二装置的账户的数额，而无需任一装置在交互期间与服务器计算机S通信。第一装置(例如，发送方装置)可包括安全元件DA，其可安全地存储数据并经由可信执行环境(TEE)执行代码。一些实施例可能不需要第二装置(例如，接收装置)包括具有可信执行环境的安全元件。在下文中，描述了可信执行环境模型和各种实施例的主要组成部分。接着，将描述用于设置装置和执行离线交互的离线交互系统协议。
可信执行环境可以是存储在安全元件内的只读存储器(ROM)上的软件堆栈。堆栈包括用于访问安全元件的一组资源，提供开发人员对底层安全元件的访问的可信操作系统，以及在可信执行环境内实施特定于应用程序的功能性的一个或多个可信应用程序(TA)(参见协议5)。可信应用程序可与特定于应用程序的客户端应用程序(CA)配对，所述CA驻存在隔离的可信执行环境空间之外并通过经由可信操作系统与可信应用程序交互来提供面向用户的功能性。
离线交互系统可包括服务器、发送方客户端应用程序、接收方客户端应用程序和可信应用程序。服务器可提供注册和设置用户装置以及管理用户账户的功能性。发送方客户端应用程序可部署在第一装置上。发送方客户端应用程序可提供用户界面，用以通过与可信应用程序交互来发出离线交互，并且与服务器计算机S交互以注册发送方客户端应用程序和可信执行环境。接收方客户端应用程序可部署在第二装置上。接收方客户端应用程序可提供用户界面，用以接收并验证离线交互，并且与服务器计算机S交互以注册客户端应用程序并声明离线交互。在一些实施例中，接收方客户端应用程序可能不与可信执行环境交互。在一些实施例中，装置可包括发送方客户端应用程序和接收方客户端应用程序。例如，如果第一装置从另一客户端(例如，装置C)请求资金，则第一装置可包括接收方客户端应用程序和发送方客户端应用程序。可信应用程序可部署在第一装置(例如，发送方装置)上。可信应用程序可包括在可信执行环境中。可信应用程序可提供特定于离线交互系统的功能性，用以安全地访问安全元件并管理客户端的离线数额。部署在第一装置上的可信应用程序可用TA表示。
1.设置协议
在各种实施例中，离线交互系统协议可让参与交互的两个客户端(例如，用户和/或资源提供商)在一次性在线设置期间向服务器计算机S进行注册，以建立非对称密码密钥，所述非对称密码密钥稍后可用于发出并验证离线交互。在线设置还允许第一装置与服务器计算机S和第一装置(DA)的制造商一起初始化可信执行环境。可信执行环境设置可包括三个阶段：(1)远程证明，允许制造商或服务器计算机S远程验证可信执行环境堆栈的有效性；(2)可信应用程序预配，允许制造商或服务器计算机S在TEE内部安全地部署可信应用程序；以及(3)可信应用程序注册，允许可信应用程序建立签名密钥对，向服务器计算机S注册签名密钥对，并获取证明签名密钥对的有效性的凭证。
2.存款协议
在各种实施例中，客户端A可能需要在第一装置在线时初始地将资金存入安全元件，使得第一装置稍后能够执行离线交互。例如，第一装置可请求服务器计算机S将存储在服务器计算机S处并与客户端A相关联的在线数额中的x数额的资金存入存储在可信应用程序TA中的离线数额。服务器计算机S用显示x是从客户端A的在线数额中扣除的数额的签名作出响应。客户端可信应用程序用服务器的公用验证密钥验证签名，并将x添加到存储在可信应用程序TA中的离线数额。
3.离线交互协议
离线交互可由接收方装置(例如，第二装置)发起，所述接收方装置将交互请求消息发送到第一装置。交互请求消息可包括第二装置的凭证。在接收到交互请求消息之后，第一装置调用可信应用程序TA来安全地从可信应用程序的TA的数额中扣除交互数额并创建包括交互数额和两个装置的凭证(例如，发送方凭证和接收方凭证)的经签名交互响应消息P。装置A将交互响应消息P发送到第二装置。在接收到交互响应消息P之后，第二装置验证第一装置的签名和凭证。接着，装置B可确保交互响应消息包含B的凭证(例如，接收方凭证)。如果每次验证都成功，则第二装置接受交互并且可存储交互响应消息P。
4.索赔协议
如果第二装置想要将从第一装置离线接收到的交互响应消息P中指示的交互数额添加到与第二装置相关联且存储在服务器计算机S处的在线数额，则第二装置可调用索赔协议。在索赔协议期间，第二装置将交互响应消息P发送到服务器计算机S。服务器计算机S验证交互响应消息P的有效性并检查交互响应消息P先前是否使用服务器计算机S存储的交互日志标记为已花费。如果所有验证都成功，则服务器计算机S可将交互响应消息P中指示的数额添加到B的在线数额，并将交互响应消息P添加到交互日志。
5.收款协议
在各种实施例中，第二装置可包括具有与第一装置的可信应用程序类似的可信应用程序TB设置的安全元件。在一些实施例中，第二装置可尝试使用先前在交互响应消息P中从第一装置接收到的数额进行离线交互，而无需在线。为此，第二装置可调用收集协议以将交互响应消息P中指示的数额添加到可信应用程序的TB的离线数额中。这可允许第二装置以与第一装置执行上述交互类似的方式离线地利用数额执行交互。
6.取款协议
在一些实施例中，第一装置可请求将资金从可信应用程序TA移动到存储在服务器计算机S处的在线数额。例如，第一装置可调用调用TA.Withdraw来从可信应用程序TA中扣除数额的取款协议，接着向第一装置提供用可信应用程序的TA的签名密钥进行签名的消息。接着，第一装置将经签名提取消息转发到服务器计算机S，所述服务器计算机在验证签名之后将数额添加到与第一装置相关联的在线数额。
7.针对重放和回滚的保护
为了防止恶意中介(例如，恶意凭证授权中心)重放在服务器计算机S与可信应用程序TA之间交换的消息以及在第一装置与第二装置之间的消息，每个装置可维持在一对装置之间的每轮通信之后递增的单调增加的计数器。在一些实施例中，服务器计算机S和可信应用程序TA可在其经签名消息中包括其计数器的最新值，使得接收方可根据其本地计数器来验证所有消息的唯一性和排序，所述本地计数器可在每次交换之后进行同步。在一些实施例中，第一装置和第二装置可在发送到其它装置的消息中包括计数器值。
B.离线交互系统
图1示出根据本公开的实施例的系统100。系统100包括第一装置102、服务器计算机104、第二装置106、多个装置108和凭证授权中心110。第一装置102可与服务器计算机104、第二装置以及多个装置108中的一个或多个装置可操作地通信。服务器计算机104可与凭证授权中心110可操作地通信。在一些实施例中，当离线时，第一装置102可经由短程通信信道(例如，蓝牙、近场通信等)与第二装置106通信。在一些实施例中，当在线时，第一装置102可经由远程通信信道(例如，通过空中通信等)与服务器计算机104通信。然而，应理解，实施例不限于此。
为了简化说明，图1中示出一定数量的组件。然而，应理解，本发明的实施例可以包括多于一个每种组件。此外，本发明的一些实施例可以包括比图1中所示的所有组件更少或更多的组件。
图1中的装置之间的消息可以使用安全通信协议来发送，所述安全通信协议例如但不限于：文件传输协议(FTP)、超文本传输协议(HTTP)、安全超文本传输协议(HTTPS)、SSL、ISO(例如，ISO 8583)等。通信网络可以包括以下中的任一个和/或组合：直接互连；互联网；局域网(LAN)；城域网(MAN)；作为互联网上节点的运行任务(OMNI)；安全定制连接；广域网(WAN)；无线网络(例如，采用例如但不限于无线应用协议(WAP)、I-模式等的协议)；等等。通信网络可以使用任何合适的通信协议以生成一个或多个安全通信信道。在一些实例中，通信信道可以包括安全通信信道，安全通信信道可以任何已知方式建立，例如通过使用相互认证和会话密钥，以及建立安全套接层(SSL)会话。
第一装置102可包括由用户(例如，电话)操作的用户装置。第一装置102可包括如本文中进一步详细描述的安全元件。用户可利用第一装置102执行与第二装置106的交互(例如，交易、数据传输等)。当第一装置102和第二装置106离线(例如，未连接到服务器计算机104)时，第一装置102可执行与第二装置106的交易。第二装置106可包括由资源提供商操作的资源提供商装置(例如，电话)。
服务器计算机104可包括远程计算机。服务器计算机104可向第一装置102提供离线数额以存储在第一装置102的安全元件中。例如，第一装置102可从服务器计算机104请求离线数额。在其它情况下，服务器计算机104可将离线数额推送到第一装置102。
第一装置102和第二装置106可执行离线交互。在一些实施例中，第一装置102可执行与多个装置108中的一个或多个装置的交互，所述装置可包括资源提供商装置和/或用户装置。多个装置108可包括任何合适数量的用户装置和/或资源提供商装置。
在一些实施例中，第二装置106从第一装置102接收离线数额。第二装置106接着执行与多个装置108中的某一装置的第二离线交易。
在其它实施例中，第二装置106从第一装置102接收离线数额。接着，第二装置106上线并连接到服务器计算机104。第二装置106请求收集与接收到的离线数额相等的数额。
凭证授权中心110可创建凭证并向服务器计算机104发出凭证。凭证授权中心110可包括一个或多个服务器计算机。在一些实施例中，凭证授权中心110能够向资源提供商装置、授权实体计算机、传输计算机、服务器计算机、网络处理计算机、用户装置等发出凭证。凭证授权中心110能够生成凭证授权中心密钥对。在一些实施例中，凭证授权中心110可与服务器计算机104操作性通信和/或可操作地耦合到所述服务器计算机，并且可代表服务器计算机104生成凭证。在一些实施例中，未示出的根凭证授权中心可向凭证授权中心110发出凭证。接着，凭证授权中心110可利用从根凭证授权中心获得的凭证向服务器计算机104发出凭证。
C.用户装置
图2示出根据实施例的第一装置的框图。示例性第一装置200可包括处理器204。处理器204可耦合到存储器202、网络接口206、计算机可读介质208以及可信执行环境210。计算机可读介质208可包括任何合适数量的模块。
存储器202可以用于存储数据和代码。存储器202可以在内部或在外部耦合到处理器204(例如，基于云的数据存储装置)，并且可以包括例如RAM、DRAM、ROM、闪存存储器或任何其它合适的存储器装置之类的易失性和/或非易失性存储器的任何组合。
计算机可读介质208可包括代码，所述代码可由处理器204执行用于执行方法，所述方法包括：从第二装置接收包括数额和第二装置凭证的交互请求消息；使用对应于用于对第二装置凭证进行签名的服务器私钥的服务器计算机公钥来验证第二装置凭证；由第一装置的安全元件中的可信应用程序确定数额是否小于存储在安全元件中的离线数额；在数额小于离线数额的情况下，由可信应用程序基于数额而确定经更新离线数额；由可信应用程序生成包括数额和可信应用程序凭证的交互响应消息；由可信应用程序使用可信应用程序私钥对交互响应消息进行签名；以及向第二装置提供交互响应消息。
网络接口206可包括可允许第一装置200与外部计算机通信的接口。网络接口206可使第一装置200能够与另一装置(例如，第二装置、服务器计算机等)之间进行数据传送。网络接口206的一些实例可以包括调制解调器、物理网络接口(例如以太网卡或其它网络接口卡(NIC))、虚拟网络接口、通信端口、个人计算机存储卡国际协会(PCMCIA)插槽和卡，等等。由网络接口206启用的无线协议可以包括Wi-FiTM。经由网络接口206传输的数据可以呈信号的形式，所述信号可以是电信号、电磁信号、光信号，或者能够由外部通信接口接收的任何其它信号(统称为“电子信号”或“电子消息”)。可以包括数据或指令的这些电子消息可以经由通信路径或信道在网络接口206与其它装置之间提供。如上所述，可以使用任何合适的通信路径或信道，例如电线或电缆、光纤、电话线、蜂窝链路、射频(RF)链路、WAN或LAN网络、互联网，或任何其它合适的介质。
可信执行环境210可包括在第一装置200上。可信执行环境210可位于第一装置200中包括的任何合适的安全硬件元件内。在一些实施例中，可信执行环境210可以是第一装置200中的安全软件模块。在一些实施例中，可信执行环境210可部分地位于安全元件内且部分地位于安全元件外部，其中每个部分提供不同能力。参考图3进一步描述可信执行环境210。
D.可信执行环境
可信执行环境可以是系统内具有其自身资源(例如，存储器、寄存器、外围设备和其自身的软件堆栈，例如OS、应用程序等)的硬件辅助执行环境。系统的其它部分无法直接访问可信执行环境的资源以及在可信执行环境内运行的进程。
图3绘示托管可信执行环境的用户装置的概述。系统的资源经由硬件方式分为两种执行环境：富操作系统执行环境(REE)和可信执行环境(TEE)。可信执行环境具有其自身的专用存储器、寄存器等，以及其自身的可信操作系统。在可信操作系统的基础上，可通过利用可信执行环境内部API来构建第三方可信应用程序。类似地，可在富操作系统的基础上构建客户端应用程序。在可信执行环境中运行的应用程序可访问富操作系统执行环境的资源，但在富操作系统执行环境中运行的应用程序无法访问可信执行环境的资源。如果客户端应用程序请求可信应用程序的服务，则驻存在富操作系统执行环境中的客户端应用程序只能经由可信执行环境客户端API来与可信应用程序通信。
根据运行可信执行环境的平台和/或用于实现系统中隔离的硬件，可信执行环境可能存在不同的变化。由于各种实施例可在移动装置上执行，因此提供在移动装置上运行的可信执行环境作为实例。然而，应注意，实施例不限于此。例如，可信执行环境可使用TrustZone架构(由Arm提供)。TrustZone架构通过利用一种允许计算核心仅用于可信执行环境的模式来增强计算核心，从而实现系统中隔离。物理核心被分成两个具有TrustZone的虚拟核心：一个虚拟核心仅用于可信执行环境，另一虚拟核心用于系统的其余部分。若要从一种环境切换到另一种环境，可使用系统调用。在可信执行环境内运行的应用程序可通过在可信执行环境中运行的OS进一步彼此隔离。
在于离线交互系统协议中注册使用可信执行环境功能性的装置之前，原始设备制造商(OEM)可证明装置内的可信执行环境设置正确。接着，实施例可确保可信执行环境预配有正确的应用程序。最后，如果证明和预配验证成功，则实施例可注册在装置中运行的可信应用程序的例子。
II.模型和问题定义
各种实施例可包括可通过经由通信网络交换消息而彼此通信的装置A、B、C等的群组。每个用户可与非负数值相关联，所述非负数值被称为指示装置所拥有的金额的数额(例如，第一装置的余额可表示为balA)。用户可与离线数额和在线数额相关联。离线数额可存储在用户装置上的安全元件中。在线数额可存储在服务器计算机或相关联数据库上。交互(例如，支付交易、数据传输等)可表示为形式(A→B,x)的元组(Tuple)，指示x数额从第一装置(例如，发送方装置)到第二装置(例如，接收方装置)的转移。在一些实施例中，交互可以是其间通过相应地更新装置的数额(例如，余额)(例如，balA＝balA-x and balB＝balB+x)来处理交互(A→B,x)的协议。如果交互时发送方的数额大于等于x，则交互可能是真实的。
交互系统P可包括客户端网络，其可通过指定授权中心(例如，被称为服务器计算机S)验证系统P内任何交互的真实性。离线交互系统可提供一种进一步使得任何一对客户端能够在两者与服务器计算机S断开连接(例如，离线)时彼此交互的机制。例如，客户端A与由OnBalA表示的在线数额和由offBalA表示的离线数额相关联。给定交互(A→B,x)，在线交互是确保onBalA＝onBalA-x且onBalB＝onBalB+x的协议。给定交互(A→B,x)，离线交互是确保offBalA＝offBalA-x且offBalB＝offBalB+x的协议。
根据各种实施例的离线交互系统可提供离线可验证性、绝对不可改变性、可赎回性和离线转移性的属性。离线可验证性属性可指示接收方装置能够在交互期间独立地验证任何交互的真实性而无需与服务器通信。绝对不可改变性可指示一旦完成交互，就立即保证接收方拥有所转移的资金。可赎回性属性可指示客户端A能够将任何数额y≤offBalA从其离线数额转换为其在线数额(例如，offBalA＝offBalA-y和offBalA＝offBalA+y，它们以原子方式执行)，反之亦然。离线转移性属性可指示装置可以花费装置离线接收到的资金而无需连接到服务器。
各种实施例可假设，尝试执行交互(例如，发送支付)的客户端可访问安全元件/硬件以存储数字数额和安全数据并安全地执行可信应用程序。可信应用程序可以是存储器的隔离区，包含代码和数据，受可信执行环境保护。装置可能需要访问可信执行环境才能作为离线交互期间的发送方装置。否则，如果装置是离线交互期间的接收装置，则不需要访问可信执行环境和/或安全元件。
对于根据各种实施例的威胁模型，使λ表示计算安全参数。实施例可假设，所有各方都经由安全且经认证的通信信道彼此通信。实施例考虑可破坏任何客户端的概率性、多项式时间对手，以便(1)防止协议实现其定义属性；以及(2)伪造金额，例如，通过二次花费客户端的金额或伪造新的金额。被破环客户端可通过任意篡改和/或拦截在服务器与客户端可信执行环境之间交换的消息来实现。实施例假设，未被破坏客户端会采用标准认证机制，例如口令、PIN和生物特征，来防止未经授权地访问客户端的装置以便未经批准就花费和/或扣除客户端的金额。各种实施例可假设服务器是完全可信的。
III.可信执行环境
可信执行环境(TEE)可以是存储在只读存储器上的软件堆栈。在一些实施例中，可信执行环境可包括在安全元件内。可信执行环境软件堆栈可包括用于访问安全元件的一组资源，提供开发人员对底层安全元件的访问的可信操作系统(TOS)，以及在可信应用程序环境内实施特定于应用程序的功能性的一个或多个可信应用程序(TA)。可信执行环境可提供执行空间，所述执行空间为在装置上运行的可信应用程序提供比富操作系统更高的安全级别以及比单独的安全元件更多的功能性。
A.远程证明
在远程证明中，远程方可尝试确保装置内的可信执行环境设置正确。这可通过只读存储器(ROM)和特定于装置的装置密钥对来确保。原始设备制造商可将ROM和装置密钥嵌入装置的硬件。
只读存储器可以是信任根以及安全启动过程的起点。例如，ROM包含发起启动过程的程序的二进制，并且此二进制包含用于启动过程中下一组成部分的验证密钥。在给装置供电后，CPU从ROM读取并执行初始化程序，所述程序验证并加载启动过程的下一组成部分(例如，下一组成部分验证下一组成部分等，直到加载整个可信执行环境软件堆栈)。如果任何签名检查失败，启动过程将停止。否则，可信执行环境堆栈正确加载(例如，在原始设备制造商提供装置之后，在可信执行环境内运行的任何软件都不会被修改)。
在这一过程结束时，可信操作系统可向远程方提供经加载二进制上的签名以及验证装置密钥。接着，远程方可将签名连同密钥一起呈现给原始设备制造商。由于原始设备制造商知晓可信执行环境堆栈的内容，因此其可验证签名，从而经由内部检查证明安全启动过程的正确性。
B.可信应用程序预配
在执行对装置的远程证明之后，可向装置预配可信应用程序。在这种情况下，预配可包括为装置中包括的可信执行环境加载一个或多个可信应用程序可信应用程序。在一些实施例中，存在两种执行安全预配的方式：(1)由原始设备制造商进行本地预配，以及(2)由远程方进行远程预配。
在本地预配中，原始设备制造商可将可信应用程序二进制加载到装置作为可信执行环境软件堆栈的一部分。接着，这些可信应用程序在安全启动过程期间被加载，且因此其真实性通过安全启动过程得到确保。在远程预配中，远程方希望在设置可信执行环境后，将可信应用程序远程加载到可信执行环境。为此，远程方首先利用可信执行环境(例如，通过使用验证装置密钥)建立安全信道，接着发送可信应用程序的二进制。在接收到二进制后，可信执行环境设置可信应用程序。另外，为了报告可信应用程序设置正确，可信执行环境可利用装置秘密密钥对二进制的散列进行签名，并将签名返回到远程方。
在一些实施例中，原始设备制造商可将远程预配仅限于一组经批准的开发人员。在这种情况下，原始设备制造商可将这些开发人员的验证密钥放入可信执行环境软件堆栈中，或者可在稍后的时间点将这些密钥发送到装置。接着，每当远程方发送程序(例如，可信应用程序)时，远程方都可以在其散列上提供签名。在这种情况下，只有当签名属于经批准的开发人员之一时，可信执行环境才会加载可信应用程序。
C.可信应用程序计算的真实性
在离线交互系统协议的过程中，服务器需要可信应用程序进行计算并接收所得输出。因此，将论述并评估作为远程方验证可信应用程序输出的真实性的问题。使可信应用程序利用装置秘密密钥对其输出进行签名可能不起作用，因为可能有多个可信应用程序驻存在可信执行环境内，因此共享装置秘密密钥。因此，实施例可利用用于可信应用程序的特定密钥对。将描述用于建立这种密钥对的方法。
首先，在本地预配的情况下，其中装置可随可信应用程序二进制一起提供，原始设备制造商还可将OIS密钥对嵌入安全存储区中，并使验证部分公开。在这种情况下，原始设备制造商还可以没有其它可信应用程序可访问这一秘密密钥的方式配置可信操作系统。然而，这需要对原始设备制造商的长期信任。例如，如果原始设备制造商受到损害，它将能够代表可信应用程序伪造签名。
更好的方式包括可信应用程序在开始运行之后生成其自身的密钥对。在这种情况下，问题变成安全地将验证部分发送到远程方。实施例可解决关于“远程方可如何确保验证密钥确实属于在正确可信应用程序环境中运行的可信应用程序”的技术问题。根据各种实施例，解决这一技术问题的方法是让可信操作系统利用装置秘密密钥验证可信应用程序的验证密钥。例如，可信应用程序有一种名为init的方法，所述方法通过设置一些变量、生成密钥对和返回验证密钥来初始化装置中的可信应用程序(参见协议5)。因此，可信操作系统的任务是证明验证密钥是可信应用程序的init方法的输出。
接着，认证可信应用程序验证密钥的流程如下：
1.可信应用程序通过运行init方法生成密钥对。
2.可信应用程序将所生成验证密钥返回可信操作系统以供进行验证。
3.可信操作系统在验证密钥和称验证密钥是通过可信应用程序的init方法生成的声明上生成签名。
更详细地，使Π、ΠT分别表示可信执行环境软件堆栈和可信应用程序的二进制。另外，使TA表示在A装置中运行的可信应用程序的例子。接着，上述步骤对应于，
1.TA.vk←TA.Init()
2.TA调用TOS.Authenticate(TA.vk,Init).
3.TOS.Authenticate(TA.vk,Init)执行以下方法：
a)如果TA.vk不属于TA，则中止；
b)返回
Figure BDA0004113700780000161
其中/>
Figure BDA0004113700780000162
作为简化符号，实施例使用
Figure BDA0004113700780000163
(参见协议4)，其指示Init方法的装置认证输出。在与远程方建立密钥对之后，可信应用程序可通过提供带TA.sk的签名来保证其输出的真实性，或在要交换多个消息的情况下通过与远程方建立安全会话来保证其输出的真实性。
D.可信应用程序注册
在可信执行环境经验证且可信应用程序(参见协议5)经由预配阶段进行设置之后，客户端的装置和可信应用程序例子可在客户端可执行交互之前向服务器进行注册。为此，可信应用程序可首先生成签名密钥对，接着将验证密钥发送到服务器，所述服务器通过利用服务器的秘密密钥对验证密钥进行签名来验证这一密钥并将其返回到装置。经签名验证密钥可位于凭证中，显示可信应用程序密钥是由真实可信执行环境生成的并且已向服务器进行注册。每当这一装置执行交互时，装置就发送凭证和其它交互信息，使得接收方可使用服务器的公钥(验证密钥)独立地验证交互的有效性。
可关于图4来描述根据各种实施例的预配方法。将在第一用户从服务器计算机请求用于执行离线交互的凭证的上下文中描述图4中所示的方法。
在步骤420处，在预配过程A期间，第一装置504可向服务器计算机502提供第一装置公钥以请求凭证。另外，第一装置504可向服务器计算机502提供可信应用程序(TA)公钥以请求凭证。
在步骤422处，在接收到第一装置公钥之后，服务器计算机502可利用服务器秘密密钥对第一装置公钥进行签名以形成第一装置凭证。服务器计算机502可利用服务器秘密密钥对可信应用程序公钥进行签名以形成可信应用程序凭证。
在步骤424处，服务器计算机502可接着向第一装置504提供凭证(例如，第一装置凭证)。随后，服务器计算机502可向第一装置504提供可信应用程序凭证。在一些实施例中，第一装置504可在一个消息中向服务器计算机502提供第一装置公钥和可信应用程序公钥，并接收包括第一装置凭证和可信应用程序凭证的一个响应。
类似地，在为第二装置506(图4中未示出，但可参见图5)进行预配期间，第二装置506可向服务器计算机502提供第二装置公钥。接着，服务器计算机502可利用服务器秘密密钥对第二装置公钥进行签名以形成凭证。接着，服务器计算机502可向第二装置506提供凭证(例如，第二装置凭证)。
E.可信执行环境内部API
根据本发明实施例的可信应用程序可包括可信存储API、密码API、时间API和算术API。可信存储API可为可信应用程序提供安全存储功能，用于通用数据以及密码密钥。例如，使用可信存储API，可信应用程序可记录其完整性和真实性得到保证的数据。可信存储API还提供了可信应用程序存储之间的隔离。密码API提供用于密码功能性的API，包括密钥生成(对称和非对称)、对称和非对称加密、摘要(digest)生成和密钥交换。时间API提供用于定时操作的API。可信应用程序可通过任意初始化来保持其内部计时器，或可在某个时间点简单地使其与外部可信时间源同步。算术API提供用于处理大数字和质域的API。可提供算术API以帮助开发人员扩展密码API。
下文表1描述在实施例中使用的某些术语。
表1：可信执行环境术语的汇总
Figure BDA0004113700780000181
IV.离线交互处理方法
A.用户装置设置
每个用户装置(无论是否支持TEE)都可参加一次性设置协议，以向服务器注册装置(例如，建立密码密钥和凭证)，并在装置支持可信执行环境的情况下初始化装置的可信执行环境堆栈。
在用户装置注册期间，用户装置可生成本地签名密钥对并将验证密钥提交给服务器。作为回报，服务器初始化客户端的账户信息并将凭证返回到用户装置。凭证可以是服务器在客户端验证密钥上的签名，使得用户装置可稍后向其它实体证明用户装置已向服务器注册。
B.可信应用程序注册
可(例如，向服务器计算机)注册用户装置上的可信应用程序。如本文中所描述，这可利用原始设备制造商来证明运行可信应用程序例子的可信执行环境是否真实。根据一些实施例，原始设备制造商将用户装置与可信应用程序二进制(例如，本地预配装置)一起提供。在一些实施例中，一个用户装置可在离线交互期间运行一个可信应用程序。
下表2描述了某些协议符号。
表2：协议符号
Figure BDA0004113700780000191
/>
Figure BDA0004113700780000201
在一些实施例中，在可信应用程序注册期间，服务器初始化协议4中iA表示的每个离线交互系统例子的计数器值。可信应用程序可维护内部变量(例如，计数器值或索引)(参见协议5中的T.i)，其与服务器计算机变量(例如，计数器值或索引)保持同步。计数器值或索引一起防止了服务器计算机侧和客户端侧(例如，用户装置侧)的二次花费。
协议3展示客户端设置协议。
协议3：客户端设置协议
Figure BDA0004113700780000202
C.可信应用程序
可向客户端应用程序提供可信应用程序所提供的方法。可信应用程序维护一些功能如下的变量。
变量T.bal是用户装置内维护的离线数额(例如，离线余额)。
变量T.log是从其它用户接收到的交互日志。交互日志可用于防止用户多次重放接收到的交互以递增离线数额。
变量T.i是服务器与用户装置之间同步的计数器值。计数器可用于防止二次花费攻击。另外，计数器值T.i可使每次交互是唯一的，使得每当用户装置接收到交互时，用户装置可确定发送方装置是否正重放先前的交互(例如，是否已接收到与同一计数器的交互)。
协议4展示可信应用程序注册协议。
协议4：可信应用程序注册协议
Figure BDA0004113700780000203
/>
Figure BDA0004113700780000211
协议5展示可信应用程序初始进程。
协议5：可信应用程序
Figure BDA0004113700780000212
协议6展示交互验证功能。
协议6：交互验证功能
Figure BDA0004113700780000221
/>
D.存入和提取数额
在存入方法期间，第一装置(例如，用户装置)可从如由服务器维护的与第一装置相关联的在线数额中扣除某一数额(例如，选定数额)，并将所述数额存入如由第一装置内的可信应用程序维护的离线数额(参见协议7)。取款协议的工作方式与存款协议类似，但数额的提供方向相反。例如，对于取款协议，第一装置从离线数额中提取一些数额，并将其转移到服务器以将所述数额添加到在线数额(参见协议8)。
参考图4，图4示出根据实施例的资金存入方法B。图4绘示第一装置504请求从服务器计算机502接收离线数额。
例如，在步骤430处，第一装置504可提供至少包括数额x的请求。第一装置504还可向服务器计算机502提供可信应用程序公钥。
在步骤432处，服务器计算机502可确定数额x是否超过在线数额。如果数额x超过在线数额，则服务器计算机502可终止所述进程。如果数额x未超过在线数额，则服务器计算机502可设置经更新在线数额，其等于在线数额与数额x的差(例如，在线数额–x)。在一些实施例中，服务器计算机502还可更新作为计数器值的整数值(也被称为索引值i)。每当服务器计算机502和第一装置504通信时，计数器值就可增加1(或其它预定量)，以防止重放攻击。
在步骤434处，服务器计算机502可生成包括存款经确认指示(例如，“depostconfirmed”)、数额x、服务器所生成的索引值i(例如，S.iA)和签名σ的响应消息并对所述响应消息进行签名。服务器计算机502可通过用服务器计算机私钥对响应消息中的数据进行签名来生成用于响应消息的签名。例如，服务器计算机502可通过计算Sign([TA.vk,x,S.iA],S.skS)来获得数字签名σ。
在步骤436处，在生成响应消息并对响应消息进行签名之后，服务器计算机502发送响应消息，其中包含要添加到第一装置504中的安全元件上的可信应用程序内的离线数额的数额。
在步骤438处，在接收到响应消息之后，第一装置504接着可向可信应用程序提供接收到的消息。例如，可信应用程序可使用与服务器计算机私钥相关联的服务器计算机公钥来验证签名。可信应用程序还可通过将数额添加到前一离线数额来更新离线数额。在一些实施例中，可信应用程序可使计数器值增加1(参见协议7)。
图4还示出根据实施例的离线数额提取方法C。在一些实施例中，离线数额提取方法可与离线数额存入方法类似。然而，与其将数额存入可信应用程序的离线数额，不如从可信应用程序的离线数额中提取某一数额并将其提供到服务器计算机502(参见协议8)。在一些实施例中，第一装置504的用户可选择将部分或全部离线数额转移到由服务器计算机502维护的在线数额。
例如，在接收到发起提取方法C的用户输入之后，在步骤440处，第一装置504可确定离线数额是否大于等于要转移到在线数额的选定数额。例如，用户可选择从离线数额中转移5美元到在线数额。第一装置504，具体地说可信应用程序，可确定离线数额是否大于等于5美元。如果离线数额小于选定数额，则第一装置504可终止所述方法并向用户通知这一确定。如果离线数额大于等于(例如，超过)离线数额，则第一装置504可在步骤442处继续进行提取方法C。
在步骤442处，第一装置504可向服务器计算机502提供提取请求消息。提取请求消息可包括数额(例如，要转移的数额)、由第一装置504和服务器计算机502两者本地维护的索引以及数字签名。例如，可信应用程序可执行TA.Withdraw(x)(参见表1)。可信应用程序可以任何合适的方式生成数字签名。例如，可信应用程序可用可信应用程序私钥对消息进行签名。可信应用程序私钥可对应于服务器计算机502先前为其发出可信应用程序凭证的可信应用程序公钥。
在步骤444处，在接收到提取请求消息之后，服务器计算机502可确定提取请求消息是否有效。例如，如果在提取请求消息中提供的索引值与服务器计算机502维护的索引值匹配，则服务器计算机502可确定提取请求消息有效。
如果提取请求消息上的数字签名有效，则服务器计算机502可确定提取请求消息有效。例如，服务器计算机502可使用SigVerify([x,i],σ,TA.vk)≠1来验证签名，如协议8所指示。换句话说，服务器计算机502可使用与用于创建签名的可信应用程序私钥相关联的可信应用程序公钥来验证签名。
在确定提取请求消息有效之后，服务器计算机502可更新在线余额以包括如提取请求消息中指示的数额(例如，所述数额从安全元件中提取并提供到服务器计算机502)。例如，服务器计算机502可执行S.onBalA←S.onBalA+x。
在一些实施例中，服务器计算机502可使索引递增预定数额(例如，1)。在下文步骤448处接收到提取响应消息之后，第一装置504也可在本地使索引递增相同的预定数额。
在步骤446处，服务器计算机502可生成包括提取是否经确认指示的提取响应消息。例如，如果任何上述验证失败，则服务器计算机502可生成包括提取未经确认指示(例如，“withdrawdenied”)的提取响应消息。如果上述验证成功，则服务器计算机502可生成包括提取经确认指示(例如，“withdrawconfirmed”)的提取响应消息。
在步骤448处，在生成提取响应消息之后，服务器计算机502可将包括提取是否经确认指示的提取响应消息发送到第一装置504。
协议7展示存款协议。
协议7：存款协议(在线至离线)
Figure BDA0004113700780000241
协议8展示取款协议。
协议8：取款协议(离线至在线)
Figure BDA0004113700780000242
E.离线交互消息传递
下文协议9展示关于图5进一步描述的离线交互协议。
协议9：离线交互协议
Figure BDA0004113700780000251
图5示出根据实施例的离线交互处理方法。第一装置504可执行与第二装置506的离线交互而无需与服务器计算机502通信。
在步骤520处，第二装置506可在交互期间从第一装置504请求数额。第二装置506可将第二装置凭证和数额发送到第一装置504。例如，在步骤520之前，第二装置506可生成包括第二装置凭证和到第一装置504的数额的交互请求消息。第一装置504的第一用户与第二装置506的第二用户之间的交互可以是交易，其中第一用户是用户，而第二用户是资源提供商。数额可以是确定和约定的数额。例如，可基于由第一用户选择并带到验货收款台(或其它合适的资源提供商位置)进行购买的多个资源而确定数额。
在步骤522处，在接收到交互请求消息后，第一装置504和/或第一装置504中的可信应用程序可验证第二装置凭证。例如，第一装置504可使用存储在第一装置504和/或可信应用程序处的服务器计算机公钥来验证第二装置凭证。例如，可信应用程序可在可信执行环境内验证第二装置凭证。
在步骤524处，在验证从第二装置506接收到的第二装置凭证有效之后，第一装置504的安全元件中的可信应用程序可确定如交互请求消息中指示的数额是否小于存储在安全元件中的离线数额。例如，交互请求消息中的数额可以是10美元。可信应用程序可确定离线数额是否大于等于所述数额。例如，离线数额可以是22美元。在这种情况下，可信应用程序可确定离线数额(22美元)大于交互请求消息中的数额(10美元)。如果交互请求消息中的数额大于离线数额，则可信应用程序可终止交互。在一些实施例中，可信应用程序和/或第一装置504可向第二装置506提供指示无法处理交互的交互响应消息。在一些实施例中，交互响应消息可进一步包括为何无法处理交互的指示(例如，资金不足等)。
在步骤526处，如果数额小于离线数额，则第一装置504中的可信应用程序可基于数额而确定经更新离线数额。例如，可信应用程序可使用所述数额更新离线数额。可信应用程序可将经更新离线数额确定为12美元。
在一些实施例中，可信应用程序还可验证如果可信应用程序先前已与第二装置506通信(如上文所描述)，则计数器值(或索引值)是正确值。如果这是第二装置506与第一装置504第一次交互，则索引值可能是0(或在一些实施例中可能从1开始)。当发送交互响应消息时，可信应用程序可使本地维护的索引值递增1。
在步骤528处，在更新离线数额之后，可信应用程序接着可生成交互响应消息(例如，支付消息)。交互响应消息可包括数额(例如，x)和第二装置凭证(例如，receiverCert)。在一些实施例中，交互响应消息可包括可信应用程序凭证(例如，T.cert)。在一些实施例中，交互响应消息可进一步包括第一装置凭证。交互响应消息还可包括计数器值(T.j)。
例如，可信应用程序可在交互响应消息P中设置以下值：
P.amount←x；
P.senderCert←T.cert；
P.receiverCert←receiverCert；
P.index←T.j；
在步骤530处，在可信应用程序生成交互响应消息之后，第一装置504中的可信应用程序可使用可信应用程序私钥对交互响应消息进行签名。
可信应用程序可使用与可信应用程序凭证中的可信应用程序公钥相关联的可信应用程序私钥对交互响应消息P进行签名。可信应用程序可如协议5所指示，通过执行以下操作来对交互响应消息P进行签名：输出P，其中P.sig←Sign([P.amount,P.senderCert,P.receiverCert,P.index],T.sk)。
在步骤532处，在对交互响应消息进行数字签名之后，第一装置504将包括签名的交互响应消息(例如，西格玛(σ))发送到第二装置506。
在步骤534处，在接收到交互响应消息之后，第二装置506可执行PayVerify进程(参见协议6)。例如，第二装置506可以验证接收到的第二装置凭证与第二装置凭证相同(例如，确定第一装置504未篡改第二装置凭证)。
在步骤536处，第二装置506可例如利用服务器计算机公钥验证接收到的可信应用程序凭证。
在步骤538处，第二装置506可使用可信应用程序凭证的可信应用程序公钥(例如，对应于用于创建签名的可信应用程序私钥)来验证交互响应消息的签名(例如，西格玛)。
在一些实施例中，在步骤540处，第二装置506可临时存储交互响应消息P。例如，如果第二装置506包括第二安全元件，则第二装置506可将交互响应消息P存储在第二安全元件中。
在一些实施例中，在步骤542A处，第二装置506可向服务器计算机502提供交互响应消息P。在其它实施例中，在步骤542B处，第二装置506可执行与第三装置508的第二交互。将在下一节中更详细地描述步骤542A和542B。
F.索赔和收款数额
在接收和验证交互响应消息P之后，第二装置506可以两种不同方式(例如，步骤542A或步骤542B)将交互响应消息中指示的数额(例如，P.amount)添加到与第二用户相关联的数额。在一些实施例中，如果第二装置506具有在第二安全元件中运行的第二可信应用程序，则第二装置506可执行收款方法(例如，TB.Collect(P))以将数额添加到第二离线数额。在其它实施例中，如果第二装置506不具有安全元件，则第二装置506可如协议10中所描述的与服务器计算机502执行索赔方法，并将数额添加到第二在线数额中。
在步骤542A处，在索赔方法期间，第二装置506可索赔在先前交互(例如，在步骤520-540过程中执行)期间从第一装置504提供到第二装置506的数额。当第二装置506在线时，第二装置506可向服务器计算机502提供离线接收到的离线交互响应消息P。第二装置506可通过任何合适的通信信道向服务器计算机502提供交互响应消息P。
在接收到交互响应消息后，服务器计算机502可验证交互响应消息中包括的可信应用程序凭证和第二装置凭证两者。服务器计算机502可将消息中包括的数额添加到与第二装置506相关联的在线数额。
在一些实施例中，服务器计算机502可将消息P添加到交互日志。例如，交互日志可包括来自先前交互的交互响应消息。如果交互响应消息已包括在交互日志中，则服务器计算机502可拒绝来自第二装置506的所提供交互响应消息。
在更新在线数额或拒绝交互响应消息之后，服务器计算机502接着将确认或拒绝响应消息发送到第二装置506。更多详细信息，请参见协议10。
协议10：索赔协议(离线至在线)
Figure BDA0004113700780000271
Figure BDA0004113700780000281
在其它实施例中，在步骤542B处，第二装置506可执行收款方法。如果第二装置506包括具第二可信应用程序的第二可信执行环境，则第二装置506可执行步骤542B。例如，在步骤542B处，在接收到交互响应消息P之后，第二装置506可向第二装置506的第二可信应用程序提供交互响应消息P。第二可信应用程序可验证交互响应消息，如本文中所描述。第二装置506的第二可信应用程序接着将数额添加到前一第二离线数额以获得经更新第二离线数额。
在将数额收款到离线数额之后，第二装置506可执行第二装置506与第三装置508之间的第二交互。第三装置508可由第三用户操作。第二装置506(例如，作为用户)与第三装置508(例如，作为资源提供商)之间的第二交互可类似于上文在步骤520-540过程中在第一装置504与第二装置506之间描述的第一交互。
例如，在第二交互期间，第二装置506可从第三装置508接收包括第二数额和第三装置凭证的第二交互请求消息。第二装置506可使用对应于用于对第三装置凭证进行签名的服务器私钥的服务器计算机公钥来验证第三装置凭证。第二装置506的第二安全元件中的第二可信应用程序可确定第二数额是否小于存储在第二安全元件中的第二离线数额。例如，第二离线数额可能先前已基于第一交互期间在交互响应消息(例如，在步骤532处接收到)中提供的数额而更新。如果第二数额小于第二离线数额，则第二装置506可基于第二数额而确定第二经更新离线数额。第二装置506可接着生成包括第二数额和第二装置凭证的第二交互响应消息，接着使用第二可信应用程序私钥对第二交互响应消息进行签名。接着，第二装置506可向第三装置508提供第二交互响应消息。接着，第三装置508可执行如本文中所描述的索赔方法或收款方法。
V.基于离线区块链的交互
在一些实施例中，智能合约可执行本文中描述为由服务器计算机执行的各种功能性。智能合约是计算机程序(例如，处理软件)，旨在根据合约或协议的条款自动执行、控制或记录与法律相关的事件和动作。智能合约的几个优点是减少了对可信中介的需求、仲裁和执行成本、欺诈损失，以及减少了恶意和意外异常。
如迄今为止所描述，实施例已利用可信服务器S来预配OPS TA和在线交互。在本节中，实施例可分离服务器S的这两项任务，并且可使用智能合约来实施在线交互部分。在某些情况下，整个服务器S并不是简单地被智能合约替代，因为在预配(例如，如协议4中所绘示)过程中，服务器S使用其签名密钥来授权每个OPS TA进行离线交互。由于存储在智能合约中的所有信息都是公开的，因此通常不可能以合约状态存储签名密钥。因此，实施例采用一种其中Deposit、Withdraw和Claim功能被委托给智能合约的设计。
因此，例如，在索赔方法期间(例如，在第二用户装置从第一用户装置接收到交互响应消息之后)，第二用户装置可向处理软件提供交互响应消息。处理软件可基于交互响应消息中包括的数额而更新与第一装置相关联的第一在线数额和与第二装置相关联的第二在线数额。
在一些实施例中，处理软件可以是智能合约，并且可在处理交互响应消息之后向第二用户装置提供纳入证明。在其它实施例中，处理软件可包括在服务器计算机中(如本文中详细描述)。
在TA注册(协议4)期间，当OPS TA向服务器S发送TARegister时，服务器S以[cert]作出响应。然而，当利用智能合约时，服务器S还可向智能合约发送OPS TA身份(例如，TA验证密钥)。另外，可以修改Withdraw和Claim方法，使得OPS TA现在可向智能合约而不是服务器S发送Withdraw和Claim。由于智能合约具有OPS TA的验证密钥，因此智能合约可简单地验证Withdraw和Claim以完成Withdraw和Claim。然而，存款验证更是一种微妙的进程，在本节的其余部分中进一步详细描述。
在Deposit协议期间，在从服务器S接收到DepositConfirmed消息后，如本文中所描述，OPS TA使用服务器S的验证密钥验证消息的正确性并更新消息的离线余额。由于智能合约无法对消息进行签名，因此实施例可转而实施区块链纳入证明，以说服OPS TA处理区块链上的任何事件。应注意，这些证明需要说服OPS TA存款交易被正确执行。
一个技术问题是，可能存在可能需要与智能合约和用户装置交互的不同类型的区块链纳入证明。例如，基于托管智能合约的分类账协议的底层架构，区块链纳入证明不同。这些分布式分类账可以大致分为两类：1)Nakamoto共识和2)Byzantine容错(BFT)共识。
工作量证明区块链等Nakamoto共识协议通常依赖于最长/最重的链来解决可能的派生。相比之下，例如Algorand和Hotstuff等BFT区块链，当签名者群组一致投票将区块包括在分类账中时，参与节点(例如，参与方)通常对区块作出决定。这一签名者群组可能包括参与方的子集或全部参与方。
A.NAKAMOTO型共识的纳入证明
原始比特币纸描述了一种有效纳入证明技术，被称为简化支付验证(SPV)，其中所述证明仅包括头链而不是整个分类账。因此，在比特币中，证明只需要每个区块80字节的信息，而不是每个区块1MB的信息。
尽管仅依赖于区块头减少了纳入证明的验证开销，但它仍然产生大量开销，特别是考虑到此开销随着区块数量线性增加的事实时。这已成为以太坊的主要问题，因为相比于比特币，其区块间隔短得多(15秒相比10分钟)并且区块头也大得多(508字节相比80字节)。
为了减少Nakamoto区块链的证明大小，引入了亚线性轻客户端的建议，并通常依赖于超级区块的概念，超级块解决比当前目标难题更难的PoW难题。引入基于超级区块的工作量证明的证明(PoPoW)并将其形式化为一种交互式证明机制。PoPoW允许证明者在对数时间和通信中以高概率说服验证者链包含足够的工作量。
为了克服这些挑战，Bunz等人提出了Fly-Client[B.Bunz、L.Kiffer、L.Luu和M.Zamani，“Flyclient：加密货币的超轻客户端(Flyclient:Super-light clients forcryptocurrencies)”，在2020年IEEE安全和隐私研讨会(SP)上。IEEE，2020年，第928-946页。]。FlyClient只需要下载对数数量的区块头来验证链的有效性。一旦链经过验证，客户端只需存储单个区块即可有效验证区块链上是否包括任何交易。FlyClient协议是一种非交互式PoPoW，但克服了基于超级区块的NIPoPoW协议的局限性。
因此，当存款被成功添加到区块链时，FlyClient和/或其它有效的Nakamoto型共识协议可用于从智能合约向用户装置提供纳入证明。
B.BFT型共识的纳入证明
基于BFT的分类账协议通常由节点(X)组成，其参与共识协议以个别地对每个区块作出决定。在许多基于BFT的分类账中，集合X几乎不会改变并且是先验已知的。然而，在一些BFT协议中，X可以可验证方式改变每个区块。
当谈到有效的纳入证明时，我们并未想到有任何工作解决了为BFT分类账存款提供有效纳入证明的技术问题。将描述第一技术解决方案，其中参与共识协议的节点集合是固定的。
为了生成纳入证明，X中的节点参与阈值签名验证密钥的一次性设置协议。一个此类实例是阈值签名，其中验证密钥(vk)是公用参数且签名密钥(sk)是在X中的所有节点当中共享的秘密密钥。接着，在设置阶段之后，X中的每个节点将接收其秘密密钥共享。接着，利用vk初始化OPS TA。一旦建立密钥，每次交互的纳入证明就可能是包括交互的区块上的阈值签名。因此，对于这些区块链，OPS TA可通过验证单个签名来验证是否包括Deposit消息。此外，这种纳入证明的大小最多是包括交易的区块的大小，这可通过使用Merkle树等技术进一步减小。
在一些实施例中，阈值签名可能不是必需的，并且实施例可使用标准签名，其中纳入证明将是X中节点子集的签名或来自节点子集的密码多重签名的列表。使用标准签名或多重签名的优点在于，可在不使用可信方的情况下实现其设置阶段。使用标准签名或多重签名的缺点在于证明大小增加。
在签名者集合快速变化的协议中，每个区块或一组区块可能由完全不同的签名者集合签名。因此，在这种情况下，利用一次性公用验证密钥初始化OPS TA的上述方法可能不起作用。
生成这些分类账的纳入证明的方法如下。对于任何此类分类账，利用第一节点集合的身份来初始化OPS TA。OPS TA可信任这一集合。接着，在集合X得到更新的每个后续区块中，现有集合授权具有签名或多重签名的列表的新集合。
在这种情况下，纳入证明是从创世(genesis)区块开始的整个授权链。这种纳入证明的大小较大。可通过检查点技术来解决这一技术问题。因此，每个节点只需要从最新的检查点下载授权链。
VI.威胁模型和安全分析
实施例可提供多个优点。例如，实施例提供一种安全离线交互系统，其允许装置安全地存储离线数额并在装置之间转移离线数额而无需与服务器通信。本文中所描述的对凭证和签名的使用提供了装置间的认证机制。
各种实施例解决了重放攻击的技术问题(例如，其中恶意方多次利用相同数据来获得某一结果，而所述结果仅应执行一次)。当装置离线通信(例如，无需服务器)时，实施例解决了重放攻击的技术问题。可在本文中所描述的各种消息中包括计数器值，以防止期间恶意用户尝试二次花费相同离线数额的重放攻击。
实施例提供数个额外优点。例如，包括有限因特网连接的用户可在本地彼此执行交互。
VII.具有余额恢复的OIS
从协议角度来看，前述离线交互系统(OIS)构造提供期望功能性，包括离线可验证性、绝对不可改变性、可赎回性和离线转移性。离线用户可能只需要在客户端设置、TA注册、存款、取款和索赔协议期间与服务器交互。应注意，存款、取款和索赔协议是依赖于用户的调用，因此不是强制性的。换句话说，如果支持TEE的两个用户A和B继续交换数额x的离线支付，则他们可(理论上)生成无限支付而无需一直与服务器交互。
但是，在某些情况下，由于不可预见的情况，可能需要与服务器的交互。例如，参考上文概述的情况，如果用户A丢失其装置(例如，智能手机)，则用户A将丢失其离线余额。因此，在用户A恢复其离线余额之前，用户A无法生成新的交互。这种情况似乎是合理的，因为智能手机有时会丢失或被偷。考虑到这一方面，实施例提供一系列有助于在装置丢失之后进行离线余额恢复的方法。本文中所描述的离线交互系统可包括或可不包括本节中描述的余额恢复实施例。
由于OIS的一个方面是限制服务器参与交互过程，因此任何恢复机制都可为服务器提供离线网络可见性。
在本节中，将描述用以恢复丢失其装置的某些方的在线余额的机制。首先，实施例探索余额恢复的局限性，并标识在没有额外假设的情况下余额恢复在技术上困难的几种情况。然后，实施例提供几种有助于在这些技术上困难情况下进行余额恢复的技术。
A.问题陈述
为了概述对余额恢复的需要，可使用简单的用例来描述技术问题。随后，实施例可列举来自这一用例的抽象概念，以检查可使用余额恢复的其它复杂例子。对于简单用例，假设两个用户，Alice和Bob(此后表示为A和B)，参与交互协议。A和B均具有支持TEE的智能手机，带OIS CA和OIS TA。我们进一步假设A具有由服务器维护的在线余额onBalA和由TA维护的离线余额offBalA(其中BalA＝onBalA+offBalA)。类似地，B具有由服务器S维护的在线余额onBalB和由TA维护的离线余额offBalB(其中BalB＝onBalB+offBalB)。A可调用Pay(x,receiverCert)以向B支付x数额，而B调用PayVerify(P,receiverCert)和Collect(P)以将x添加到用户B的账户。因此，从A的离线余额(offBalA＝offBalA-x)中扣除x。
支付后不久，A丢失其装置并联系S以恢复他们的离线余额。S不清楚A与B之间的支付。因此，服务器将要求A在其offBalA恢复到正确状态之前出示所有离线支付。因此，除非服务器可获得一些存储信息(在本例中，由B提供的Pay(x,receiverCert))，否则在此初始示例情况中恢复机制是不可能的。这意味着，B必须在线并与服务器同步，以促进余额恢复。然而，在对抗性环境中，B有可能选择保持离线并选择不合作，或者B由于某种原因(例如，没有互联网连接)而无法在线。此外，A也可能是恶意的并且提出了虚假恢复请求(例如，请求恢复而不报告Pay(x,receiverCert)，以获得offBalA而不是offBalA-x)。最后，另一种可能性是A和B同时丢失装置并向S生成并行恢复请求。在这种情况下，任何一方都无法提供任何证据来表明他们已发送或接收到支付，这使余额恢复在技术上更加困难。
B.余额恢复目标
对于解决前述技术问题的设计目标，实施例旨在使OPS服务器S能够保证用户在时间限制内的offBal恢复(例如，用户不用无限期地等待余额恢复)。另一目标是构建一种系统，其中恶意用户不能1)提出虚假恢复索赔，2)故意或不知情地禁止恢复过程，以及3)通过与其他恶意用户串通来影响诚实用户。另外，如果用户已进行了多次离线交互，则S可标识最大数量的(理想情况下是所有)此类交互，并将离线余额复到正确状态。余额恢复目标和威胁模型概述如下。
在一些实施例中，用户(例如，Alice)不能提出虚假索赔，因为如果他们提出虚假索赔，则有可能冒在虚假索赔检测时失去余额的风险。
(1)当S接收到发送方向接收方进行的所有离线交互时，余额恢复是可能的。部分余额恢复是指S接收到发送方向接收方进行的离线交互的子集。(2)如果发送方的装置丢失，则交互只能由交互接收方提供。
(3)接收方必须在线(联系S)以出示从发送方(丢失装置的一方)接收到的交互。(4)如果交互涉及具有n个支持TEE的装置的n个方，并且系统中的所有装置都丢失，则将余额恢复到正确状态是不可能的。
对于威胁模型，实施例可假设用户可尝试提出虚假恢复请求(例如，报告丢失装置而不出示发送到其他方的交互)。接收方可能(有意或无意)不在线并且不报告发送方接收到的离线交互。发送方和接收方都可能尝试串通起来欺骗服务器(例如，发送方进行支付、报告虚假恢复请求、与接收方串通起来不向服务器进行报告)。因此，接收方得到了支付款，发送方恢复的离线余额超过了他们的份额。这一情形可抽象化为多方交互协议，其中(n+m)个总用户当中有n个发送方、m个接收方和t个诚实用户。
C.序言
如上文所概述，服务器可获得离线交互网络的完整视图以执行余额恢复。另外，服务器可保证在特定时间限制内进行余额恢复。为此，服务器可利用期间预期所有用户会向服务器报告其离线交互的同步参数Δ。同步参数Δ可被视为期间服务器可理想地构建离线交互流的时期。同步参数Δ可以是预期用户同步(例如，登记)时间之间的时间长度。例如，同步参数Δ可以是12小时、1天、1周、2周等。
如果用户在Δ期间未与服务器同步，则他们所有的离线交互都可被丢弃。假设同步参数Δ是全局的，利用所有用户可用的全局时钟。在同步过程中，用户可从服务器获得同步参数Δ和/或对应于同步周期结束的时间戳(例如，在同步参数Δ指定的下一时期结束时)。在下文的协议11中，利用用户A的同步参数Δ正式指定和建模同步协议。
D.余额恢复的限制
1.两个方和一次交互的案例
为了帮助进行技术分析，可简化设计余额恢复机制的设置。考虑一种设置，其中存在A和B(例如，用户A和用户B)两个方，A最多向B进行一次支付。另外，可假设，双方均期望在支付结束时与服务器同步，并向服务器提供所有发送/接收到的支付的列表。也就是说，如果一方(例如，用户)不与服务器同步，则服务器可假设该方已损坏。可构建OIS协议的修改版本，如果OIS TA在指定时间内未与服务器同步，则使其无法运行。这是为了确保不与服务器同步的一方不再能够使用存储在装置上的离线余额，尤其是不能发送/接收任何进一步的支付。
鉴于上述情况，可能会发生三种不同的情况。
在第一情形中，假设只有一方丢失了装置，而另一方进行了同步，则服务器有可能由于从与服务器同步的一方接收到的所执行交互列表而知晓用户A是否向用户B进行支付。
在第二情形中，一方向服务器报告装置丢失，而另一方未进行同步。在这种情况下，服务器不知道是否发生了支付。服务器可能会断定未同步的一方已损坏。在这种设置中，服务器可就是否发生支付而言信任报告丢失装置的一方。幸运的是，由于对以下两个案例的案例分析，这一设置可行。
在案例1中，A报告装置丢失，而B不进行同步。在这种情况下，B已损坏(因为它们未进行同步)。如果A也损坏，则无论是否实际发生支付，我们都可能只是将金额从损坏的一方转移到另一方，尤其是对手拥有的总数额(以及系统的整体数额)将保持不变。应注意，如果支付值大于A的离线余额，则服务器可安全地假设从未发生过这一支付(因为OIS TA绝不会允许这种支付)。在A诚实的另一种情况下，服务器S信任A报告的内容。
在案例2中，A不进行同步，而B报告装置丢失。在这种情况下，A已损坏。如果B也损坏，则无论是否实际发生支付，我们都可能只是将金额从损坏的一方转移到另一方，尤其是对手拥有的总数额(以及系统的整体数额)将保持不变。应注意，如果支付值大于A的离线余额，则服务器可安全地假设从未发生过这一支付(因为OIS TA绝不会允许这种支付)。在B诚实的另一种情况下，S信任B报告的内容。
在第三情形中，双方都丢失了他们的装置(或声称已丢失了他们的装置或未进行同步)。在这种情况下，服务器将无法区分以下两种情况1)A诚实，而B已损坏，A未向B进行支付，以及2)A已损坏，而B诚实，A向B进行支付但向服务器声称没有向B进行支付。
在这两种情况下，A和B均报告装置丢失。在这两种情况下，A均声称自己没有向B进行支付。尽管两种情况的设置相同，但理想的结果却不同。在第一种情况下，服务器可理想地恢复双方离线之前的准确余额。另一方面，在第二种情况下，服务器可根据从A向B的支付来理想地调整余额。
情形三的一个技术问题是利用系统中的备份。情形三的补救措施可能涉及(诚实的)一方以某种方式向服务器证明支付是否发生。证明支付发生或未发生的唯一决定性方式是借助于安全装置生成的支付日志。实际上，有效支付无法被恶意生成，因为这涉及使用安全装置的签名密钥生成签名。因此，场景三的唯一补救措施是诚实的一方维护其安全装置生成的支付日志的备份，并将其提交给服务器。因此，即使诚实方丢失了他们的装置，也可提供支付日志的备份来说服服务器适当地更改A和B的离线余额。
然而，应注意，如果诚实方丢失了他们的装置并且不具有他们支付日志的备份，则无法得到能够准确恢复他们的离线余额的保证。尤其是，如果诚实方确实接收到支付，但却无法证明支付，则可能无法获得支付金额。如果另一方向服务器提交包含所述支付的付款日志，则服务器将能够恢复诚实方的余额。然而，由于另一方可能不提供支付日志或者可能提供甚至过期的支付日志，如果诚实方未保留其支付日志的备份，则无法得到恢复其离线余额的保证。
实施例可提供一种主动抑制各方不显示其最新支付日志的系统。如果一方未进行同步并显示其最新支付日志，则系统可通过使OIS TA变得不可操作来实现这一点。这是通过让服务器证明所提交日志来实现的，作为OPS TA知晓一方确实与服务器进行了同步并提交了最新支付日志的手段。因此，这对服务器有利，并会提交最新支付日志，从而可能有助于诚实方的余额恢复。
说明性实例可包括一个双方共同的案例，假设在Δc期间A向B支付了x并丢失了其装置的情况下。支付后，A丢失了其装置并通知服务器S。服务器S向A保证他们的offBalA将在Δn之后(完成下一时期之后)恢复。假设B诚实并根据协议11与服务器S进行同步，则服务器S将知晓A向B进行的支付，并将恢复正确的offBalA＝offBalA-x。如果B是恶意的，则服务器S将恢复A的offBalA＝offBalA+x。由于TB知晓Δc已过期，因此它将不允许B将x发送到新的接收方。最后，如果A是恶意的并声称已丢失装置，则其无法从恢复协议中获益。根据常见情况，提出了以下引理1。
引理1：发送方的余额将在向服务器S发送恢复请求[DeviceLost]时间的下一时期之后恢复。
下文的协议11说明了用户A的同步协议。在同步协议期间，A会(从OIS TA)提交支付日志，所述支付日志向服务器S提供在余额恢复中有用的支付证明。
在协议11的步骤1处，用户A向服务器S发送他们的离线支付TA.log，以及签名σ和请求时间tsync(可以是发出请求的时间的时间戳)。
在步骤2a处，服务器S验证签名并检查日志中的时间请求和所有支付是否在前一同步参数Δp与当前同步参数Δc之间。前一同步参数Δp是表示前一同步时期结束的时间的时间戳。当前同步参数Δc是表示当前同步时期结束的时间的时间戳。前一同步参数Δp与当前同步参数Δc之间的时间差是同步参数Δ。
在步骤2b处，如果签名有效并且日志中的时间请求和所有支付都在前一同步参数Δp与当前同步参数Δc之间，则服务器S将支付日志TA.log中的支付额添加到在线余额onBalA(例如，在步骤2bi处)并从发送方的离线余额中减去支付额(例如，在步骤2bii处)。
在步骤2c处，服务器S对下一同步参数Δn进行签名，从而创建签名σS。服务器S可使用服务器秘密密钥skS对下一同步参数Δn进行签名。
在步骤3处，服务器可将下一同步参数Δn和签名σS发送回用户(例如，在消息[Δn,σS]中)。
另外，每个TA都知晓付款日志TA.log必须进行同步直至Δc结束。如果TA在Δc之后看到非同步日志，则会拒绝生成新的交互。这种方法确保，如果恶意用户不与服务器S同步，则恶意用户装置无法向诚实用户发送“无效”支付。总而言之，根据这些设置，OIS确保1)所有支付接收方必须在前一时期与当前时期之间与服务器同步才能兑现他们的支付，2)如果用户不与服务器同步，则无法生成新的支付，以及3)由于同步，服务器S可跟踪在所述时期内进行的所有离线支付。
例如，在交互后的预定量的时间之后，第一用户装置可生成包括交互日志、时间和签名的同步消息。第一用户装置可将同步消息发送到对应于服务器计算机公钥的服务器。在接收到同步消息后，服务器可验证同步消息中的签名，接着验证时间介于上一时期结束时间与当前时期结束时间之间。服务器可接着针对交互日志中的每次交互，更新如由交互日志指示的第一用户装置的在线余额和另一用户装置的离线余额，生成包括时间和使用时间和服务器计算机私钥创建的签名的同步确认消息，并向第一用户装置提供同步确认消息。第一用户装置可从服务器接收同步确认消息，接着使用服务器计算机公钥验证同步确认消息的签名
协议11：同步协议
Figure BDA0004113700780000361
Figure BDA0004113700780000371
2.两个方和多次交互的案例
现在考虑一种设置，其中存在两个用户，用户A和用户B，用户A与用户B在某一阶段或时期内彼此之间进行任意数量的支付。可假设，两个用户(具体地说，用户的用户装置)都期望在每个阶段结束时与服务器进行同步，并列出与服务器进行发送和接收的所有支付。如果用户装置未与服务器进行同步，则可假设用户和/或用户装置已损坏。
本案例的分析与单笔支付的分析类似。基于在阶段结束时提交给服务器的支付日志，服务器得知所述阶段中发生的任意支付子集，并将能够恢复与这些支付一致的余额。例如，支付的子集可以是每个用户的支付的“单调”子集。也就是说，如果服务器得知用户在所述阶段中涉及的第8笔支付，则还得知用户在所述阶段中涉及到的支付1到i-1。注意，如果这与实际情况不同，则相应的OIS TA在任何情况下都会丢失或变得无法操作。这保证了没有金额可以被二次花费，也无法创建新的金额。如前所述，如果诚实的用户装置维护其支付日志的定期备份，则可发送所述备份以恢复其离线余额。如果没有维护其支付日志的定期备份，则可能无法进行操作，具体取决于其它用户装置的操作。
3.多于两个方的案例
此外，实施例考虑一种设置，其中存在多个方，每个方在某一阶段或时期内与其他用户进行任意数量的支付。可假设，所有用户装置都期望在每个阶段结束时与服务器进行同步，并列出与服务器进行发送和接收的所有支付。如果用户装置未与服务器进行同步，则可假设用户装置已损坏。
之前的许多分析也适用于本案例。然而，实施例可利用额外技术来增加诚实用户的余额恢复的机会。这些技术中的第一种是链式支付，其在此处进行了概述并在本文中进行了更详细的解释。链式支付可包括将个别支付相互链接起来。支付可以是复合支付，包含所考虑的支付以及在所述时期发生的若干其它支付的详细信息。使用链式支付，支付将进入网络中潜在的几个其它用户装置的日志，因此网络中诚实的用户装置在所述阶段结束时与服务器进行同步的可能性更高。这是一种启发式解决方案，并且可保证如果支付链的一部分(在支付链中的某笔支付完成后创建)中的某个用户装置与服务器进行同步，则在所述阶段结束时服务器会知道知晓所述支付。
因此，链式支付可为多方支付提供恢复方案。应注意，在当前时期Δc期间，用户装置B可与其它用户装置进行离线支付。现在假设用户装置A向用户装置B提供数额x，接着用户装置B向用户装置C提供(例如，转发)所述数额。进一步假设支付以用户装置Z结束。所有支付都可能在当前时期Δc内进行。如果用户装置B在Δc期间未与服务器S进行同步(即使处于未来无法生成任何支付的风险下)，则服务器S将不知晓用户装置A与用户装置B之间的任何支付，并且会错误地恢复offBalA＝offBalA+x。因此，双方OPS恢复协议可能无法推广为多方恢复协议。为了解决这一限制，实施例提供了两种方法，这两种方法将允许在多方设置中进行余额恢复，这将在下面进一步详细描述。
这一观察产生引理2，该引理指出，如果支付链由多个分支组成，并且所述分支上存在至少一个诚实用户，则服务器S将完全恢复所有中介直至诚实用户的离线余额。
E.链式支付
由实施例提供的用于辅助余额恢复的技术之一被称为链式支付。如前所述，用户装置可将每次支付与前一支付链接起来。
图8A-8C绘示根据实施例的离线交互系统中的链式交互。例如，用户装置A可向用户装置B支付xA，建模为
Figure BDA0004113700780000381
接着用户装置B向用户装置C支付xB，如图8A所示。第一支付可并入第二支付中。例如，前一支付/>
Figure BDA0004113700780000382
可并入到下一支付中以形成支付序列：/>
Figure BDA0004113700780000383
此支付序列将形成支付链，其中用户装置Z(例如，支付链末端的用户装置)将知晓支付链中涉及的所有用户装置，最终链接到用户装置A。如果链中的任何诚实用户装置与服务器进行同步，如图8B-8C所描绘，则服务器将知晓从用户装置A一直到与服务器进行同步的诚实用户装置的支付序列。这将允许服务器成功地得知涉及多个用户装置的所有支付，即使只有一个用户装置(可能未涉及这些支付)与服务器进行同步。
例如，图8B绘示用户装置C与服务器S进行同步。由于用户装置C与服务器S进行同步，因此服务器S得知由用户装置A和用户装置B执行的支付。服务器S可更新用户装置A的离线余额并相应地更新用户装置B的离线余额。
作为另一实例，图8B绘示用户装置Z与服务器S进行同步。由于用户装置Z与服务器S进行同步，因此服务器S得知由用户装置A、用户装置B、用户装置C和链中用户装置C与用户装置Z之间的任何用户装置执行的支付。服务器S可相应地更新链中每个用户装置的离线余额。
在更笼统的设置中，在某些情况下，系统不同部分的链可合并。图9A-9B绘示根据实施例的离线交互系统中的链式交互的聚集。在这种情况下，根据实施例的余额恢复机制提供的确切保证将取决于链如何交互。一般规则是，用户的支付链越多，链中某个诚实的用户装置与服务器进行同步并使服务器知悉所述支付的可能性就越高。
在图9A-9B中描绘了示例情形(为简洁起见，对于Pi，支付对象由Pi表示)。例如，图9A绘示用户装置X从用户装置A和用户装置C接收支付。另外，用户装置X向用户装置B、用户装置D和用户装置Y提供支付。用户装置Y可接收来自用户装置X的支付以及来自用户装置Z的支付。前述支付都可在单个时期内发生。在时期结束时，装置可与服务器S进行同步。例如，如图9B所示，如果只有用户装置Y与服务器S进行同步，则服务器S仍可接收到足够的关于所有支付被链接并提供到用户装置Y的数据。具体地说，服务器S可得知从用户装置A和用户装置C开始到用户装置X、接着到用户装置Y的支付链。服务器S还可得知从用户装置Z到用户装置Y的支付。因此，服务器S可更新用户装置A、用户装置X、用户装置C、用户装置Y和用户装置Z的离线余额。然而，在这种情况下，服务器S并未得知从用户装置X向用户装置B或用户装置D进行的支付。这是因为，这些支付没有链接到提供到用户装置Y的任何支付，所述用户装置Y是唯一与服务器S进行同步的用户装置。
下文的协议12展示使用户能够将其离线余额(例如，offBalA)恢复到正确状态的恢复协议。下文的协议13展示使用户能够将其离线余额恢复到正确状态的恢复协议。
可在第一用户丢失其用户装置的情况下执行协议12。例如，第一用户装置的用户可能失去对第一用户装置的拥有权。在步骤1处，用户可利用辅助装置来生成丢失装置余额恢复消息并将丢失装置余额恢复消息发送到服务器。辅助装置可以是任何合适装置(例如，计算机、膝上型计算机、电话等)。在步骤2处，在接收到丢失装置余额恢复消息后，服务器可将第一用户装置公钥添加到黑名单，等待直到当前时期结束以便其它用户装置与服务器进行同步，基于所述时期内装置的同步而更新第一用户装置的在线余额，并将第一用户装置的离线余额设置为零。
协议12：恢复协议
Figure BDA0004113700780000391
Figure BDA0004113700780000401
协议13：用于余额恢复支持的TA方法
Figure BDA0004113700780000402
F.抵押品
链式支付技术的一个局限性是每次支付的支付规模呈线性增长。如果获得授权的同步周期非常长(例如，以天为单位)，则支付规模可能会显著增加，从而增加安全存储区的存储惩罚。缓解这一问题的一种方法是只存储一定数量的支付，例如随机选择的支付。随机选择支付链也将保证不同的用户装置在进行同步时能够向服务器通知不同的支付，从而使对手更难隐藏支付。
解决这一技术问题的另一种方法是由被称为抵押品的实施例提供的技术。在此设置中，每个用户装置与服务器建立抵押品，使得抵押品价值始终大于可支付的离线余额。例如，如果用户装置A与服务器建立抵押品AC，则AC>offBalA。在同步协议期间，服务器还向可信应用程序提供抵押品价值。现在，当用户装置A进行离线交易时，TA会检查进行的所有离线支付的总和是否小于抵押品。如果用户装置A未与服务器进行同步，则服务器使用抵押品解决就用户装置A进行的支付而产生的任何争议。应注意，如果离线余额未恢复，这实际上与扣除offBalA相对应。这是因为TA现在无法支付超出抵押品价值的任何款项，并且获得更多可支付资金的唯一方式是与服务器进行同步，服务器将能够确定多少抵押品将恢复为可支付资金。这一过程可应用于图9A所示的支付链。如果用户装置Z是诚实用户装置，则从用户装置Y接收到支付，并且从用户装置A到用户装置Y的所有各方都已损坏且未与服务器进行同步，接着用户装置Z将与服务器进行同步并显示它已接收到来自用户装置Y的支付。服务器将使用这一了解来从用户装置Y的在线余额中扣除抵押品并兑现用户装置Z的支付。中介的所有其它支付被拒绝，并且用户装置A恢复其离线余额。应注意，与所有中介都获得离线支付的链式支付不同，在抵押品支付中，只有用户装置Y和用户装置Z能兑现它们的支付。
链式支付和抵押品的技术并非相互排斥，而是可相互结合使用，以实现与获得授权的同步周期(时期大小)、存储/通信限制、恢复模式等相关的权衡。
此外，可从博弈论方法的角度来观察这一系统。例如，假设一种情况，其中用户装置A从用户装置B购买x数额的咖啡，并且在支付之后还偷走用户装置B。现在，用户装置A和用户装置B均可向服务器(分别，恶意地和非恶意地)报告丢失装置。在这种情况下，服务器将永远无法恢复双方的真实离线余额，用户装置A将侥幸获得在向用户装置B支付之前的离线余额，并且还将消费了咖啡。
为了防止这种情况发生，实施例可引入这样的信念，即接收方可能具有与原始用户装置一起存储的备份。换句话说，在从用户装置A接收到支付之后，用户装置B的TA将在另一装置(例如，服务器、计算机、膝上型计算机等)上进行备份以充当证明。如果用户装置B向服务器S展示证明，则服务器S可对用户装置A施加严厉的惩罚。因此，这种备份的信念可迫使用户装置A诚实地行事，因为现在变成了以用户装置B可能有备份或可能没有备份为条件的猜谜游戏。因此，恶意用户装置A的成功概率从100％降低到仅50％。
VIII.另外的实施例
A.隐私维护离线交互系统
在本节中，论述了基本协议中的隐私泄漏。本文中提供对隐私泄漏的解决方案，例如通过使用群签名。例如，由于每个离线交互系统例子的验证密钥是唯一的，因此可能会发生隐私泄漏。因此，交互的接收方(参见协议9)可将每次交互绑定到特定的离线交互系统例子，且因此绑定到特定用户。这公开了某些信息，例如用户的交互频率、所支付数额等。对于客户端来说，解决这一技术问题的真正方法是为它们在每次新交易中的可信应用程序生成新的密钥对。然而，由于每个离线交互系统验证密钥都应由服务器来认证(参见协议4)，因此这会给客户端带来很大的开销。
对于本文中所描述的设置来说，对这一技术问题的技术解决方案是利用群签名方案(GSS)。例如，对于GSS，存在唯一的验证密钥，根据所述验证密钥可验证所有签名密钥，且因此可验证所有离线交互系统例子。鉴于此，不可能将交互的发送方绑定到验证密钥，这是因为所有交互都根据同一验证密钥进行验证。然后，利用群签名方案，基本协议可如下进行扩充，其中服务器扮演群组管理器的角色。
首先，服务器生成验证密钥和对应的秘密密钥共享。其次，服务器利用服务器秘密密钥对验证密钥进行签名，并使所得经签名验证密钥为公用的。再次，服务器在可信应用程序注册期间向用户装置分配秘密密钥共享。再者，每当可信应用程序执行交互时，就利用接收到的秘密密钥共享对交互进行签名。接着，交互中的接收装置可利用全局凭证的验证密钥来验证签名。
由于每个签名都是根据单个全局验证密钥进行验证的，因此接收装置无法将一个发送方装置与另一装置区分开来。在一些实施例中，群组管理器可公开发送方的身份，并且可从群组添加/删除成员。
B.分级离线交互系统
在现实世界中，某些国家可能会对离线交互系统生态系统发出一些限制。例如，各国可能希望凭证发行方接受该国中央银行的审查。为了使离线交互系统适用于这种设置，实施例可对可信应用程序凭证建立分级信任链，如图6所示。
图6绘示分级离线交互系统。例如，此处，商业银行A等特定服务可能会向客户端发出可信应用程序凭证，让它们在生态系统中进行登记。然而，离线交互系统运营所在国的法律可能要求每个凭证发行方都必须经过中央银行的审查。这可通过对可信应用程序凭证建立信任链来实现。也就是说，商业银行A发出的每个凭证都可以有一个签名链，一直到中央银行，中间有一些可能的中间实体。
如今的数字支付代表了金融机构运营的基于账户的借记和贷记账户系统，其中支付账户的所有权与用户的公共身份相关联。随着分布式分类账技术的出现，人们对一种新形式的基于令牌的数字支付越来越感兴趣，其中令牌本身就是金额，金额的所有权由用户对私人密码密钥的访问确定，所述私人密码密钥提供对用户数字钱包的访问。对这些钱包的访问通常由被称为钱包提供商的实体提供，这些实体提供对密码密钥的安全访问以及一些银行和其它金融功能。
由于人们对基于令牌的支付越来越感兴趣，因此设想有可能发出一种新型的中央银行金额，即中央银行数字货币(CBDC)。一种设计是以中央银行储备直接支持的密码令牌的形式发出这种新金额，以使消费者和企业能够以“数字现金”的形式发出支付。
然而，让中央银行履行发出和管理数字货币的所有职责，例如广泛创建和分布数字货币所需的繁重处理，是不切实际的。
在中央银行(CBDC)模型中，在途金额仍应由其可信发行方(例如，就CBDC而言，中央银行)承担责任，这意味着其价值始终由发行方保证，只要接收方能够容易地验证金额的真实性即可。这确保了：(1)金额是根据发行方设定的一组特定规则(也就是与现有金融体系平行的货币政策)正确发出的，以及(2)金额于在途过程中保持其价值(即，既没有被二次花费也没有被伪造)。
在数字世界中，这可以使用公钥密码术来实施，在公钥密码术中，在途金额携带数字签名，所述数字签名只能由中央银行直接生成或由中央银行的一名经认证代表间接生成。接着，金额的任何接收方都可通过对照中央银行的公钥和/或其可信代表的凭证验证签名来简单地对金额进行认证。与现金相比，公钥密码技术可能在安全性和合规性方面具有显著优点。
可存在通过经认证代表交付的双层分级可信基础设施，其允许中央银行将管理CBDC令牌数字凭证的复杂性外包给一组潜在受监管的、经许可的实体，这些实体通过实际源自中央银行的数字凭证的分级结构从中央银行获得其授权。这种分级信任设计类似于公钥基础设施(PKI)中的凭证授权中心(CA)的分级结构，它在实现信息通过因特网的安全传输方面发挥着至关重要的作用。
还可存在CBDC的可显著促进CBDC的安全发出和转移的PKI，中央银行作为根CA，其它金融机构(FI)作为授权钱包提供商安全地促进CBDC支付的中间CA。双层次模型的核心优点在于，它使凭证基础设施(层次1)与CBDC支付的关键延迟路径(层次2)解耦，从而允许银行和其它金融机构等钱包提供商安全地大规模处理CBDC支付，而不会对受高度保护的PKI节点施加任何开销。
作为CBDC双层次模型的概述，第一层次是基础设施，可包括根凭证授权中心。根凭证授权中心可以是中央银行。中央银行可授权其它实体(例如，银行、钱包提供商、金融科技公司等)成为第二层凭证授权中心。这些实体共同构成基础设施层次。这些实体可授权其它实体成为下一层凭证授权中心。任何层次中均可包括额外经授权和经认证参与者层。
成为支付层次的第二层次可包括钱包提供商(或银行等其它合适实体)和用户(例如，消费者和商家)。钱包提供商可向用户提供CBDC和/或密钥，所有这些都基于追溯到信任根的信任分级结构。
这些层次可展示不同任务是如何在不同的实体群组和层之间划分的。通过向除中央银行之外的其它实体分配凭证预配的责任，并通过使除中央银行之外的其它实体能够创建和分配CBDC，系统变得更加高效和可扩展。
较高层次中的每个实体都可认证较低层次中的另一实体。这可包括授权下层实体实行一个或多个动作(例如，创建或发出数字货币)以及提供凭证。凭证可包括下层实体的公钥、关于授权和权限的信息，以及使用上级实体的私钥的数字签名。因此，由下层实体进行数字签名(例如，具有下层实体的私钥)的任何内容可使用如凭证中所示的下层实体的公钥来验证，并且可基于凭证而得到信任(例如，由于存在上层实体的签名、由于上层实体的签名是可信的，和/或由于上层实体通过另一凭证被更上层实体认证)。换句话说，公钥基础设施(PKI)可用于在整个网络中分配信任，并且任何动作都可通过凭证验证为经授权。任何其它合适的PKI特征可并入到双层次分级基础设施中。
作为第一层次中CBDC创建步骤的实例，中央银行和/或其它凭证授权中心可创建CBDC。例如，可生成唯一可标识(例如，经由序列号)的数字令牌。所创建CDBC的记录可经由例如区块链等分布式分类账技术(DLT)得以存储。另外，中央银行可发出智能合约，所述智能合约可设置实体可创建和分配货币的规则和限制(例如，总数额、每月数额、每年数额、每周数额、CBDC可分配给谁等)。智能合约也可通过DLT存储，并且可约束DLT的管理方式。
将论述第二层次中CBDC分配的示例步骤。CBDC可提供给各种钱包提供商。接着，这些钱包提供商可向用户和用户账户发出CBDC，并且管理用户之间的交互和CBDC的交换。可经由一个或多个分布式分类账(例如，区块链)记录CBDC分派、分配和交换的任何合适步骤。
通过在整个系统中分布的可信凭证、在整个系统中分布的CBDC以及跟踪变化的分布式分类账，CBDC随后可用于交易。例如，当CBDC用于支付(或通过网络向下分配)时，支付发送方可对交易消息进行数字签名，指示特定令牌正发送到特定接收方。接收方和/或其它网络实体可基于DLT支付记录而验证发送方拥有令牌，因此发送方的数字签名(例如，使用其私钥)可以是令牌发送的可信且可兑现指示。支付消息可通过指示与接收方相关联的公钥来标识接收方。因此，接收方可能是在后续支付中使用给定令牌的唯一实体，因为接收方可能是拥有与支付消息中标识的接收公钥相对应的私钥的唯一实体。
中央银行(或其它信任根)可能对整个系统中的CBDC负有责任。例如，在一些实施例中，用户、钱包提供商或其它实体能够在中央银行将CBDC兑换为法定货币。
双层次模型可应用于其它几个系统并改进其它几个系统，例如通用支付渠道(UPC)、离线交互系统和区块链分片。
离线交互系统可在不连接到中间网络系统的同时实现用户对用户的数字支付。应用针对CBDC的双层次分级信任基础设施模型可改进OIS。例如，根据针对CBDC的分级信任基础设施发展“离线”能力可增强使用经授权硬件的点对点离线支付的安全性和实用性。通过将主要信任点带到根据此基础设施的离线装置，例如上述协议的离线协议可成为CBDC的潜在特征。作为数字现金的CBDC可即时在多个支付轨道和条件下移动，而无需在转移期间直接涉及任何中介。例如，如果支付的发送方和接收方与不同的钱包提供商有关系，则他们仍应能够通过可信硬件以点对点方式即时地相互交易，而无需与其钱包提供商通信。这实现了高吞吐量，因为在不可靠网络条件下仍可进行支付，并且通过避免与中介共享不必要的支付信息设计上保护了隐私。
因此，利用允许用户(例如，客户)以CBDC向另一用户(例如，商家)进行数字支付的离线支付系统，可为离线支付带来的技术挑战提供技术解决方案——保护系统免受金融犯罪的挑战，以及避免使买方、卖方或中央银行暴露于支付可能最终无法结算的风险的挑战。
作为与双层次模型集成的离线CBDC支付的实例，可发生离线交互，其中CBDC由一个用户发送到第二用户，如上文实例中所描述。
本文中所描述的离线交互系统可抽象化为分级离线交互系统设计中，其中不同OIS层的用户可通过其服务器形成的分级结构不间断地交换交互。为了针对这种设置定制离线交互系统设计，实施例可对可信应用程序凭证建立分级信任链。
图6示出分级OIS的图示。例如，此处，商业银行A等特定服务可能会向客户端发出OIS TA凭证，让它们在生态系统中进行登记。然而，OIS运营所在国的法律可能要求每个凭证发行方都必须经过中央银行的审查。这可通过对OIS TA凭证建立信任链来实现。也就是说，商业银行A发出的每个凭证都可以有一个签名链，一直到中央银行，中间有一些可能的中间实体。
对于分级OIS，最基本的变化涉及验证信任链中实体的签名。这允许用户验证链中涉及的所有服务器(直到根服务器)的真实性，并信任服务器提供的信息。除这一变化外，其它OIS功能将相对保持不变。然而，为了促进对信任链中服务器的签名验证，可采用以下方案：
聚合签名方案可插入到系统中，使得链端点可利用聚合签名方案将所有签名聚集为单个签名。为此，一个实例是Boneh-Lynn-Shacham(BLS)方案。此方案除了为信任链提供信任机制外，还可减少通信开销和验证时间。
将分级OIS与其它扩展组合可能会出现本文中解决的额外技术问题。例如，数额恢复(在下一节描述)需要服务器同步。在链式支付模型中，实施例可利用支付之间的链接机制并将其与聚合签名组合，以使分级OIS起作用。
将分级OIS与特定隐私设置策略(例如，完全动态)组合可能无法起作用。在这种情况下，只有半动态方案才能起作用。每个服务器都可维护自己的群组。这显示了客户端所属的群组(因为可能存在多个)。简单的解决方案是让信任链中的上层来维持所述群组。假设OEM为每个服务器生成装置，比如在中央银行的情况下，这可能也很简单。
实施例可与通用支付渠道(UPC)系统一起使用。UPC系统可以是用于处理接受不同加密货币的两个分布式分类账之间的跨分类账数字支付的系统。UPC由网络集线器(Network Hub)组成，所述网络集线器允许密码钱包提供商(作为银行)利用网络(例如，支付通信网络)建立抵押支付渠道，并以安全方式授权跨分类账支付。所述协议利用密码数字签名和智能合约来确保针对不可信钱包提供商的恶意活动的强大安全性，并允许经由链外支付渠道立即大规模授权交易。UPC可用于使用经由分级CBDC模型互连的多个集线器来处理跨CBDC交易，其中中央银行通过凭证授权中心的分级结构认证UPC集线器。
可利用链外CBDC支付，以及与双层次模型集成的通用支付渠道。第二层次中可包括额外的DLT系统。
区块链分片(或其它DLT系统)也可从CBDC中受益，因为CBDC由分级信任基础设施支持。区块链分片可包括链上和链外支付。
图7示出包括与其它系统集成的双层次基础设施的完整CBDC模型的实例，所述其它系统例如UPC渠道、离线支付系统、链外支付和一个或多个DLT。
各种实施例可包括一种方法，包括：由数字钱包提供商计算机从凭证授权中心计算机接收凭证，所述凭证包括与凭证授权中心计算机相关联的第一数字签名，所述第一数字签名可使用与凭证授权中心计算机相关联的第一公钥进行验证，所述凭证包括与数字钱包提供商计算机相关联的第二公钥，并且所述凭证指示数字钱包提供商计算机被授权创建或分配与中央银行相关联的数字货币；由数字钱包提供商计算机生成用于向用户提供数字货币的数字货币转移消息，所述数字货币转移消息指示数字货币的数额和与用户相关联的第三公钥；由数字钱包提供商计算机使用与第二公钥相关联的第二私钥生成用于数字货币转移消息的第二数字签名；以及由数字钱包提供商计算机将数字货币转移消息、第二数字签名和凭证发送到与用户相关联的用户装置，其中用户装置使用与凭证授权中心计算机相关联的第一公钥来验证凭证中包括的第一数字签名，并且其中用户装置使用与数字钱包提供商计算机相关联的第二公钥来验证第二数字签名。
根据一些实施例，凭证、第一公钥和第二公钥是公钥基础设施中的组成部分，其中信任根是中央银行，并且其中公钥基础设施分为两个层次，包括第一层次第二层次，第一层次包括发出凭证的第一组计算机，并且第二层次包括管理支付的第二组计算机。
根据一些实施例，凭证是第二凭证，其中与凭证授权中心计算机相关联的第一凭证指示凭证授权中心计算机被授权预配其它凭证，并且所述方法进一步包括：由数字钱包提供商计算机从凭证授权中心计算机接收信任根公钥索引和第一凭证，所述第一凭证包括第一公钥；由数字钱包提供商计算机获得由信任根公钥索引标识的信任根公钥；使用信任根公钥验证第一凭证；由数字钱包提供商计算机获得来自第一凭证的第一公钥；以及使用第一公钥验证第一数字签名。
根据一些实施例，所述方法进一步包括：由数字钱包提供商计算机基于信任根计算机提供的智能合约而确定数字钱包提供商计算机尚未超过数字货币生产限制；以及在生成数字货币转移消息之前，由数字钱包提供商计算机生成数字货币，所述数字货币包括至少一个数字令牌。
根据一些实施例，数字令牌是唯一的，并且可基于唯一的序列号标识。
根据一些实施例，所述方法进一步包括：在生成数字货币转移消息之前，由数字钱包提供商计算机从凭证授权中心计算机接收数字货币，所述数字货币包括至少一个数字令牌。
根据一些实施例，数字令牌由信任根计算机生成。
根据一些实施例，所述方法进一步包括：由数字钱包提供商计算机基于数字货币转移消息而更新区块链。
根据一些实施例，所述方法进一步包括：作为用户注册过程的一部分，由数字钱包提供商计算机为用户装置生成包括第三公钥的第二凭证；由数字钱包提供商计算机使用第二私钥生成凭证的第三数字签名；以及由数字钱包提供商计算机将第二凭证和第三数字签名发送到用户装置。
根据一些实施例，用户是第一用户并且用户装置是第一用户装置，其中第一用户装置生成指示数字货币被提供到第二用户的支付消息，其中第一用户装置使用与第三公钥相关联的第三私钥生成第三数字签名，并且其中第一用户装置将支付消息、第三数字签名发送到与第二用户相关联的第二用户装置。
本申请中描述的任何软件组件或功能可实施为使用例如Java、C、C++、C#、Objective-C、Swift的任何合适的计算机语言或例如Perl或Python的脚本语言使用例如常规的或面向对象的技术由处理器执行的软件代码。软件代码可作为一系列指令或命令存储在计算机可读介质上以供存储和/或发送，合适的介质包括随机存取存储器(RAM)、只读存储器(ROM)、磁性介质(例如硬盘驱动器或软盘)，或光学介质(例如光盘(CD)或DVD(数字通用盘))、闪存存储器等。计算机可读介质可以是此类存储装置或发送装置的任何组合。
以上描述是说明性的并且不是限制性的。在所属领域的技术人员阅读了本公开后，本发明的许多变化将变得显而易见。因此，本发明的范围不应参考以上描述来确定，而是应参考未决的权利要求以及其完整范围或等效物来确定。
在不偏离本发明的范围的情况下，任何实施例的一个或多个特征可以与任何其它实施例的一个或多个特征组合。
如本文中所使用，除非明确指示有相反的意思，否则使用“一个”、“一种”或“所述”旨在意指“至少一个”。

Claims (26)

1.一种方法，包括：
由第一装置从第二装置接收包括数额和第二装置凭证的交互请求消息；
由所述第一装置使用对应于服务器计算机私钥的服务器计算机公钥来验证所述第二装置凭证；
由所述第一装置的安全元件中的可信应用程序确定所述数额是否小于存储在所述安全元件中的离线数额；
在所述数额小于所述离线数额的情况下，由所述可信应用程序基于所述数额而确定经更新离线数额；
由所述可信应用程序生成包括所述数额和可信应用程序凭证的交互响应消息；
由所述可信应用程序使用可信应用程序私钥对所述交互响应消息进行签名以产生交互响应消息签名；以及
由所述第一装置向所述第二装置提供包括所述交互响应消息签名的所述交互响应消息。
2.根据权利要求1所述的方法，其中所述交互响应消息进一步包括所述第二装置凭证，并且其中所述第二装置验证在所述交互响应消息中接收到的所述第二装置凭证与在所述交互请求消息中提供的所述第二装置凭证匹配。
3.根据权利要求1所述的方法，其中所述交互响应消息进一步包括索引。
4.根据权利要求3所述的方法，其中所述索引是由所述第一装置和所述第二装置两者本地跟踪的计数器值。
5.根据权利要求1所述的方法，进一步包括：
在接收所述交互请求消息之前，由所述第一装置从与所述服务器计算机公钥相关联的服务器计算机接收第一装置凭证和所述可信应用程序凭证。
6.根据权利要求1所述的方法，进一步包括：
在接收所述交互请求消息之前，由所述第一装置从与所述服务器计算机公钥相关联的服务器计算机接收所述离线数额；以及
由所述第一装置将所述离线数额存储在所述安全元件中。
7.根据权利要求1所述的方法，其中所述第一装置在所述第一装置与所述第二装置之间的离线交互期间接收所述交互请求消息。
8.根据权利要求1所述的方法，其中所述离线数额安全地存储在所述安全元件中。
9.根据权利要求1所述的方法，其中在接收所述交互请求消息之前，由所述第一装置从与所述服务器计算机公钥相关联的服务器计算机接收第一装置凭证和所述可信应用程序凭证；并且
其中所述第一装置凭证是由中间凭证授权中心向所述第一装置发出的，其中所述中间凭证授权中心是与所述服务器计算机公钥相关联的所述服务器计算机，并且其中所述服务器计算机公钥是由根凭证授权中心在中间凭证中向所述中间凭证授权中心发出的。
10.根据权利要求9所述的方法，其中所述第一装置凭证、所述第二装置凭证和所述服务器计算机公钥是其中信任根是所述根凭证授权中心的公钥基础设施中的组成部分，并且其中所述公钥基础设施分成两个层次，所述两个层次包括第一层次和第二层次，所述第一层次包括发出凭证的第一组计算机，并且所述第二层次包括管理交互的第二组计算机，其中所述第二层次包括所述第一装置和所述第二装置。
11.根据权利要求1所述的方法，进一步包括：
在预定量的时间之后，由所述第一装置生成包括交互日志、时间和签名的同步消息；以及
由所述第一装置将所述同步消息发送到对应于所述服务器计算机公钥的服务器计算机。
12.根据权利要求11所述的方法，其中所述服务器计算机验证所述同步消息中的所述签名，验证所述时间介于上一时期结束时间与当前时期结束时间之间，并且其中所述服务器计算机针对所述交互日志中的每次交互，更新如由所述交互日志指示的所述第一装置的在线余额和另一用户装置的离线余额，生成同步确认消息和所述同步确认消息的使用所述服务器计算机私钥创建的签名，并向所述第一装置提供所述同步确认消息，其中所述方法进一步包括：
由所述第一装置从所述服务器接收所述同步确认消息；以及
由所述第一装置使用所述服务器计算机公钥验证所述同步确认消息的所述签名。
13.根据权利要求12所述的方法，其中所述第一装置的用户失去对所述第一装置的拥有权，并且其中所述用户利用辅助装置来实现生成丢失装置余额恢复消息并将所述丢失装置余额恢复消息发送到对应于所述服务器计算机公钥的所述服务器，其中所述服务器将第一装置公钥添加到黑名单中，等待直到当前时期结束，基于所述当前时期期间装置的同步而更新所述第一装置的所述在线余额，并将所述第一装置的离线余额设置为零。
14.一种第一装置，包括：
处理器；以及
耦合到所述处理器的计算机可读介质，所述计算机可读介质包括能由所述处理器执行以实施方法的代码，所述方法包括：
由所述第一装置从第二装置接收包括数额和第二装置凭证的交互请求消息；
使用对应于服务器私钥的服务器计算机公钥验证所述第二装置凭证；
由所述第一装置的安全元件中的可信应用程序确定所述数额是否小于存储在所述安全元件中的离线数额；
在所述数额小于所述离线数额的情况下，由所述可信应用程序基于所述数额而确定经更新离线数额；
由所述可信应用程序生成包括所述数额和可信应用程序凭证的交互响应消息；
由所述可信应用程序使用可信应用程序私钥对所述交互响应消息进行签名以产生交互响应消息签名；以及
由所述第一装置向所述第二装置提供包括所述交互响应消息签名的所述交互响应消息。
15.根据权利要求14所述的第一装置，进一步包括所述安全元件，所述安全元件包括所述可信应用程序。
16.根据权利要求14所述的第一装置，其中通过短程通信信道接收所述交互请求消息，并且通过所述短程通信信道提供所述交互响应消息。
17.根据权利要求14所述的第一装置，其中所述交互响应消息进一步包括所述第二装置凭证和索引。
18.根据权利要求14所述的第一装置，其中在向所述第二装置提供所述交互响应消息之后，所述第二装置基于所述交互响应消息中的所述数额而更新第二离线数额。
19.根据权利要求18所述的第一装置，其中所述第二装置在第二交互期间从第三装置接收包括第二数额和第三装置凭证的第二交互请求消息，并且使用与用于对所述第三装置凭证进行签名的所述服务器私钥相对应的所述服务器计算机公钥来验证所述第三装置凭证，并且其中所述第二装置的第二安全元件中的第二可信应用程序确定所述第二数额是否小于存储在所述第二安全元件中的所述第二离线数额，在所述第二数额小于存储在所述第二安全元件中的所述第二离线数额的情况下，基于所述第二数额而确定第二经更新离线数额，生成包括所述第二数额和所述第二装置凭证的第二交互响应消息，并使用第二可信应用程序私钥对所述第二交互响应消息进行签名，并且其中所述第二装置向所述第三装置提供所述第二交互响应消息。
20.根据权利要求14所述的第一装置，其中所述离线数额是由与所述服务器计算机公钥相关联的服务器计算机生成和发出的。
21.根据权利要求14所述的第一装置，其中所述方法进一步包括：
在预定量的时间之后，由所述第一装置生成包括交互日志、时间和签名的同步消息；
由所述第一装置向对应于所述服务器计算机公钥的服务器发送所述同步消息，其中所述服务器验证所述同步消息中的所述签名，验证所述时间介于上一时期结束时间与当前时期结束时间之间，并且其中所述服务器针对所述交互日志中的每次交互，更新如由所述交互日志指示的所述第一装置的在线余额和另一用户装置的离线余额，生成同步确认消息，所述同步确认消息包括所述签名确认消息的使用服务器计算机私钥创建的签名，并向所述第一装置提供所述同步确认消息；
由所述第一装置从所述服务器接收所述同步确认消息；以及
由所述第一装置使用所述服务器计算机公钥验证所述同步确认消息的所述签名。
22.一种方法，包括：
由第二装置生成包括数额和第二装置凭证的交互请求消息；
由所述第二装置向第一装置提供所述交互请求消息，其中所述第一装置使用对应于服务器计算机私钥的服务器计算机公钥来验证所述第二装置凭证，确定所述数额是否小于存储在所述第一装置上的安全元件中的离线数额，基于所述数额而确定经更新离线数额，生成包括所述数额和可信应用程序凭证的交互响应消息，并使用可信应用程序私钥对所述交互响应消息进行签名以产生交互响应消息签名；
由所述第二装置接收包括所述交互响应消息签名的所述交互响应消息；以及
由所述第二装置暂时存储所述交互响应消息。
23.根据权利要求22所述的方法，进一步包括：
由所述第二装置使用对应于所述服务器计算机私钥的所述服务器计算机公钥来验证所述可信应用程序凭证。
24.根据权利要求22所述的方法，进一步包括：
在临时存储所述交互响应消息之后，由所述第二装置向与所述服务器计算机公钥相关联的处理软件提供所述交互响应消息，其中所述处理软件基于所述交互响应消息中包括的所述数额而更新与所述第一装置相关联的第一在线数额和与所述第二装置相关联的第二在线数额。
25.根据权利要求24所述的方法，其中所述处理软件是智能合约。
26.根据权利要求24所述的方法，其中所述处理软件被包括在服务器计算机中。
CN202180059805.1A 2020-07-23 2021-07-21 离线交互系统和方法 Pending CN116158053A (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US202063055761P 2020-07-23 2020-07-23
US63/055,761 2020-07-23
US202063090104P 2020-10-09 2020-10-09
US63/090,104 2020-10-09
US202063125305P 2020-12-14 2020-12-14
US63/125,305 2020-12-14
PCT/US2021/042645 WO2022020523A1 (en) 2020-07-23 2021-07-21 Offline interaction system and method

Publications (1)

Publication Number Publication Date
CN116158053A true CN116158053A (zh) 2023-05-23

Family

ID=79729853

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180059805.1A Pending CN116158053A (zh) 2020-07-23 2021-07-21 离线交互系统和方法

Country Status (4)

Country Link
US (1) US20230344649A1 (zh)
EP (1) EP4186205A4 (zh)
CN (1) CN116158053A (zh)
WO (1) WO2022020523A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11556909B2 (en) 2019-08-16 2023-01-17 Visa International Service Association Universal payment channels
US20230188340A1 (en) * 2021-12-15 2023-06-15 Capital One Services, Llc Key recovery based on contactless card authentication
SE2250289A1 (en) * 2022-03-03 2023-09-04 Crunchfish Digital Cash Ab Preventing fraudulent use by cloning of a trusted application
WO2023177902A1 (en) * 2022-03-18 2023-09-21 Visa International Service Association Offline interaction blockchain system and method
WO2023214928A1 (en) * 2022-05-05 2023-11-09 Crunchfish Digital Cash Ab Traceable multi-hop offline digital payments
CN114900319B (zh) * 2022-06-13 2023-08-01 中国科学院软件研究所 一种区块链交易验证方法和系统
CN117375864A (zh) * 2022-06-30 2024-01-09 华为技术有限公司 远程证明方法、装置、系统、存储介质及计算机程序产品
CN115082067B (zh) * 2022-07-27 2022-11-25 北京大学 一种基于sm2的数字货币双离线支付方法及装置
CN115603943A (zh) * 2022-09-07 2023-01-13 支付宝（杭州）信息技术有限公司（Cn） 一种离线身份验证的方法、装置、存储介质及电子设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170076275A1 (en) * 2014-03-11 2017-03-16 Tracopay Limited Device and system for electronic fund transfer
US20150278795A1 (en) * 2014-03-26 2015-10-01 Google Inc. Secure offline payment system
CN106875186B (zh) * 2016-06-20 2020-07-24 阿里巴巴集团控股有限公司 一种离线支付方法和装置
CN108604345B (zh) * 2017-01-25 2020-09-25 华为技术有限公司 一种添加银行卡的方法及装置
US20180260795A1 (en) * 2017-03-13 2018-09-13 Mastercard International Incorporated Method and system for accessing locally stored digital funds
WO2019074326A1 (en) * 2017-10-12 2019-04-18 Samsung Electronics Co., Ltd. SECURE OFFLINE PAYMENT METHOD AND APPARATUS

Also Published As

Publication number Publication date
US20230344649A1 (en) 2023-10-26
EP4186205A1 (en) 2023-05-31
EP4186205A4 (en) 2024-01-24
WO2022020523A1 (en) 2022-01-27

Similar Documents

Publication Publication Date Title
CN116158053A (zh) 离线交互系统和方法
US10535065B2 (en) Secure payment transactions based on the public bankcard ledger
CN111523884B (zh) 用于在不带有安全元件的移动设备中生成高级存储密钥的方法及系统
WO2012123394A1 (en) Off-line transfer of electronic tokens between peer-devices
RU2741321C2 (ru) Криптографическая аутентификация и токенизированные транзакции
WO2002039391A2 (en) Returning of change in an electronic payment system
US10657523B2 (en) Reconciling electronic transactions
Christodorescu et al. Towards a two-tier hierarchical infrastructure: an offline payment system for central bank digital currencies
CN111062717B (zh) 一种数据转移处理方法、装置和计算机可读存储介质
EP3788535B1 (en) Techniques for performing secure operations
US20210272106A1 (en) Universal Payment Messaging Using Public Blockchains and Identity Platform
Singh et al. Performance comparison of executing fast transactions in bitcoin network using verifiable code execution
EP4278316A1 (en) Token-based off-chain interaction authorization
US11481766B2 (en) Method for payment authorization on offline mobile devices with irreversibility assurance
US20220353058A1 (en) Conditional offline interaction system and method
Park et al. OPERA: A Complete Offline and Anonymous Digital Cash Transaction System with a One-Time Readable Memory
US20230107197A1 (en) Blockchain based interaction processing
US11935065B2 (en) Systems and methods for implementing offline protocol in CBDC networks using collateral chain
US20240078522A1 (en) Interaction channel balancing
WO2023177902A1 (en) Offline interaction blockchain system and method
US11812260B2 (en) Secure offline mobile interactions
Yang et al. DOPS: A Practical Dual Offline Payment Scheme of CBDC for Mobile Devices
WO2023108127A1 (en) Universal payment channel system and method
GHOSH et al. DEVICE AND METHOD FOR ACCEPTING CENTRAL BANK DIGITAL CURRENCY (CBDC) IN PAYMENT NETWORKS
WO2024072915A1 (en) Native cryptocurrency payment system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination