CN105721480A - 基于fido硬件的用户操作方法及系统 - Google Patents

基于fido硬件的用户操作方法及系统 Download PDF

Info

Publication number
CN105721480A
CN105721480A CN201610119317.6A CN201610119317A CN105721480A CN 105721480 A CN105721480 A CN 105721480A CN 201610119317 A CN201610119317 A CN 201610119317A CN 105721480 A CN105721480 A CN 105721480A
Authority
CN
China
Prior art keywords
data
server
mobile phone
phone terminal
module
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
CN201610119317.6A
Other languages
English (en)
Inventor
尚春明
熊巧玲
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.)
Beijing Jiuzhou Yunteng Technology Co Ltd
Original Assignee
Beijing Jiuzhou Yunteng Technology Co Ltd
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 Beijing Jiuzhou Yunteng Technology Co Ltd filed Critical Beijing Jiuzhou Yunteng Technology Co Ltd
Priority to CN201610119317.6A priority Critical patent/CN105721480A/zh
Publication of CN105721480A publication Critical patent/CN105721480A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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
    • 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/3249—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 RSA or related signature schemes, e.g. Rabin scheme

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明提供了基于FIDO硬件的用户操作方法及系统，涉及互联网领域。本发明实施例提供的基于FIDO硬件的用户操作方法，通过在现有网络架构不需要大量修改的前提下，增加了与原有网络架构中的结构相配合的新网络结构，并按照FIDO协议的工作方式调整了工作方式，使得原有网络架构与新网络结构相配合，以实现采用FIDO协议的方式进行通讯，即达到了去密码化的目的，又使得原有的网络架构不需要过多调整，节约了资源。

Description

基于FIDO硬件的用户操作方法及系统
技术领域
本发明涉及互联网领域，具体而言，涉及基于FIDO硬件的用户操作方法及系统。
背景技术
FIDO(FastIdentityOnline)联盟，即线上快速身份验证联盟。FIDO联盟为于2012年7月成立的行业协会，其宗旨为通过去密码化，满足市场多应用需求和应付网上验证要求。该协议为在线与数码验证方面的首个开放行业标准，可提高安全性、保护隐私及简化用户体验。
FIDO技术在注册和认证方面有着良好的安全性和应用前景，尤其是在基于密码访问所开发的互联网应用经常出现泄密问题的情况下，FIDO技术的应用前景更进一步被看好。FIDO技术的基础在于FIDO联盟所创立的标准，能够起到去密码化的目的。如google等大型公司已经开始支持FIDOU2F认证技术。
如一般技术一样，如果服务提供方需要使用一种新的技术，更具体来说是使用一种新的通讯协议、通讯标准，其首先需要改进的是其网络架构和原始代码。通常网络架构可以广义的分为两端，即用户端和网络端。在使用新技术的时候，网络提供方首先需要调整网络端的代码，再修改下载到用户端中软件的代码，使网络端和用户端能够配合的进行数据交互，以完成用户的互联网使用需求。通讯协议代码是最基础，最原始的代码，是保证网络服务能够正常使用的基础，并且不同的通讯协议相差又较大。因此，在进行代码修改的时候，通常是通讯协议代码的通篇修改。通常，网络架构并不必然需要进行调整，如果修改前后的两个通讯协议相差不大，则不需要进行调整。
一般来说，进行技术推广的主要阻力便是使用习惯和代码修改。使用习惯指的是用户的操作方式，一般来说通讯协议的修改并不会影响用户的体验，其影响的只是用户端与网络端的数据交互过程，并不涉及用户的操作。而代码修改则会很影响服务提供者选择使用FIDO通讯协议的，这是因为通讯协议是基础协议，对通讯协议的修改工作量会非常大，尤其当期望使用FIDO通讯协议的厂商增多时，会有大量的厂商花费时间在通讯协议的修改上。
由此可见，现行基于FIDO通讯协议的通讯方式的适用度并不高。
发明内容
本发明的目的在于提供基于FIDO硬件的用户操作方法及系统，以提高基于FIDO硬件来使用FIDO通讯协议的便捷程度。
第一方面，本发明实施例提供了基于FIDO硬件的用户操作方法，包括：
手机端第一模块生成初步操作请求，并向通过第一服务器向第二服务器发送所述初步操作请求；
第二服务器验证所述第一服务器是否具有访问权限，若是，则根据所述初步操作请求生成原始操作数据；
第二服务器通过第一服务器向手机端第一模块发送所述原始操作数据；
手机端第二模块按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据；
若手机端第二模块接收到所述新操作数据的确认信息，则手机端第一模块向第一服务器发起完成操作请求，所述完成操作请求中携带有所述确认信息；
所述第一服务器将所述完成操作请求和预先生成的第一服务器验证信息发送至第二服务器；
所述第二服务器分别对所述验证信息和所述完成操作请求进行核对，若所述核对通过，则将所述确认信息中的数据进行关联，并存储在本地，且通过第一服务器向所述手机端第一模块发出操作成功信息。
第二方面，本发明实施例还提供了基于FIDO硬件的用户操作系统，包括：
手机端第一模块，用于生成初步操作请求，并向通过第一服务器向第二服务器发送所述初步操作请求；
第二服务器，用于验证所述第一服务器是否具有访问权限，若是，则根据所述初步操作请求生成原始操作数据；
第二服务器，还用于通过第一服务器向手机端第一模块发送所述原始操作数据；
手机端第二模块，用于按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据；
若手机端第二模块接收到所述新操作数据的确认信息，则手机端第一模块，还用于向第一服务器发起完成操作请求，所述完成操作请求中携带有所述确认信息；
所述第一服务器，还用于将所述完成操作请求和预先生成的第一服务器验证信息发送至第二服务器；
所述第二服务器，还用于分别对所述验证信息和所述完成操作请求进行核对，若所述核对通过，则将所述确认信息中的数据进行关联，并存储在本地，且通过第一服务器向所述手机端第一模块发出操作成功信息。
本发明实施例提供的基于FIDO硬件的用户操作方法，采用在现有网络架构的基础上，增加辅助结构方式，与现有技术中的如果服务提供者需要使用FIDO协议进行数据交互的时候，则需要将其所控制的网络架构中每个设备的源代码均进行调整，耗费成本过大相比，其通过在现有网络架构不需要大量修改的前提下，增加了与原有网络架构中的结构相配合的新网络结构，并按照FIDO协议的工作方式调整了工作方式，使得原有网络架构与新网络结构相配合，以实现采用FIDO协议的方式进行通讯，即达到了去密码化的目的，又使得原有的网络架构不需要过多调整，节约了资源。
为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本发明实施例所提供的基于FIDO硬件的用户操作方法的基本流程图；
图2示出了本发明实施例所提供的基于FIDO硬件的用户操作方法的网络架构图；
图3示出了本发明实施例所提供的基于FIDO硬件的用户操作系统的模块框架示意图。
具体实施方式
下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
随着网络技术的发展，网络供应商所提供的而网络服务也越来越多，如微信、迅雷等等。网络服务的网络框架通常可以由两端组成，也就是网络供应商所控制的网络端(通常也被称为服务器)和由用户所控制的终端(如手机)。在进行网络服务的时候，通常是由用户控制终端向网络端发起请求，网络端再适应性的进行反馈。终端和网络端能够进行工作的主要原因是：终端和网络端内已经存储有由编程人员所编写的代码，当接收到请求的时候，会调用相应的代码来处理该请求，进而实现一系列的处理，或者控制。也就是这些代码是终端和网络端实现功能(服务)的基础。当功能需要改变、进行更新，或者是通讯协议需要改变的时候，首先改变的是代码本身，如果有不同的服务供应商的通讯协议需要改动，则需要将每个网络端和终端的代码进行修改。当需要修改代码的网络端和终端增多时，是很耗费人力物力的。
尤其针对通讯协议的修改，本身并未对服务内容(功能)进行修改，只是提高了安全性或者其他性能，用户甚至感受不到通讯协议有了修改。但对于修改代码的人员来将，则需要将每个网络端和终端中的代码进行更新。随着FIDO技术的出现，为了达到去密码化目的的商家越来越多，但修改商家所控制的网络端和对应终端的代码就成为首个问题。为了降低修改代码的工作量，本申请提供了基于FIDO硬件的用户操作方法和系统，下面先对该方法进行说明。
如图1所示，基于FIDO硬件的用户操作方法包括如下步骤：
S101，手机端第一模块生成初步操作请求，并向通过第一服务器向第二服务器发送初步操作请求；
S102，第二服务器验证第一服务器是否具有访问权限，若是，则根据初步操作请求生成原始操作数据；
S103，第二服务器通过第一服务器向手机端第一模块发送原始操作数据；
S104，手机端第二模块按照标准U2F注册方式对原始操作数据中的认证数据进行查验，若查验通过，则根据原始操作数据生成新操作数据；
S105，若手机端第二模块接收到新操作数据的确认信息，则手机端第一模块向第一服务器发起完成操作请求，完成操作请求中携带有确认信息；
S106，第一服务器将完成操作请求和预先生成的第一服务器验证信息发送至第二服务器；
S107，第二服务器分别对验证信息和完成操作请求进行核对，若核对通过，则将确认信息中的数据进行关联，并存储在本地，且通过第一服务器向手机端第一模块发出操作成功信息。
需要说明的是，手机端第一模块是用户所操作的手机原本便存在的模块。在相关技术中，网络服务供应商所控制的第一服务器，与第一服务器直接进行交互的便是手机端第一模块。而手机端第二模块则是向手机端第一模块提供FIDO通讯协议服务的模块，该模块是在原有手机端第一模块的基础上新增加的。也就是，网络供应商在将原有的网络服务修改为基于FIDO通讯协议的网络服务时，通过新增加手机端第二模块的方式，能够在不改变原手机端第一模块内代码的前提下，帮助网络供应商实现使用FIDO通讯协议进行网络服务。相类似的，第二服务器也是新加载的与第一服务器相配合的服务器，第二服务器同样是帮助网络供应商实现使用FIDO通讯协议进行网络服务的网络结构。一般情况下，手机端第一模块和手机端第二模块是同时存在于一个手机中的，而第一服务器和第二服务器可以是合并在一起，也可以是相互分离的状态。FIDO通讯协议的提供方主要是提供了手机端第二通讯模块和第二服务器，由于FIDO通讯协议的基本通讯策略是相同的，因此在第二通讯模块和第二服务器中可以预先设定好代码，以使二者能够分别与对应的手机端第一模块和第一服务器进行配合。
步骤S101所执行的动作与传统技术较为类似，即手机端第一模块根据用户的操作生成一个初步操作请求(如注册请求、认证请求、交易请求、下载请求等)。第一服务器是有网络服务供应商所控制的，通常第一服务器在接收到初步操作请求后还会进行权限的判断、认证等操作，但相关技术中，这部分技术较为成熟，此处不再赘述，只描述为第一服务器向第二服务器发送初步操作请求(通常，第一服务器向第二服务器发送初步操作请求时，还会进行一定量的验证、认证等操作，均成功后才会执行该步骤)。
步骤S102，第二服务器是FIDO通讯协议提供方所控制的服务器，该服务器需要先对第一服务器的权限进行验证，当验证通过后，再根据初步操作请求生成原始操作数据。操作的内容不同，生成的原始操作数据也不同，如初步操作请求是关于注册的，则原始操作数据也是关于注册的。并且，生成的原始操作数据需要向第一服务器发送，再由第一服务器发送给手机端第一模块。
由于手机端第一模块没有处理FIDO通讯协议的代码，因此，只能由手机端第一模块将原始操作数据转交给手机端第二模块进行处理。因此，步骤S104，由手机端第二模块按照标准U2F注册方式对原始操作数据中的认证数据进行查验，并在查验通过后，根据原始操作数据生成新操作数据，进而执行步骤S105。实际操作中，除了手机端第一模块、手机端第二模块、第一服务器和第二服务器以外，还应当设置专门由用户进行操作的二次认证设备，该二次认证设备的存在形式如可进行显示的手环、手表等等，这是FIDOU2F协议中必须存在的一个独立结构，该二次认证设备辅助完成了步骤S104中的查验过程和步骤S104与步骤S105之间的生成新操作数据的确认信息的过程。简单而言，步骤S104的查验过程是将原始操作数据中的认证数据逐个发给二次认证设备，由二次认证设备中的代码进行校验。生成新操作数据的确认信息前，先由手机端第二模块将新操作数据发送给二次认证设备，二测认证设备在收到该新操作数据之后进行显示，以提示用户，用户此时如果认为新操作数据是正确的，则会按下二次认证设备上指定的按钮。然后，二次认证设备便会生成新操作数据的确认信息，并将该确认信息发送给手机端第二模块。
步骤S105中，手机端第一模块向第一服务器发起完成操作请求，完成操作请求中携带有确认信息，进而，步骤S106，由第一服务器将该完成操作请求和关于第一服务器的验证信息(如第一服务器的编码等)发送给第二服务器。
最终第二服务器需要分贝对验证信息和完成操作请求进行核对，通常首先核对的是验证信息，再核对的是完成操作请求。如果这两次核对均通过就将确认信息中的数据进行关联，并存储在本地，且通过第一服务器向手机端第一模块发出操作成功信息。
下面对两个细节方案进行说明。
一、本申请除了通过上述方法能够简化网络服务提供商修改代码的作业量，还可以在原有FIDO通讯协议不过多调整的前提下，增加交易确认的过程。对应交易确认过程，主要体现在如下步骤中：
若所述初步操作请求是初步交易确认请求，则步骤S104，所述步骤手机端第二模块按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据包括如下子步骤：
手机端第二模块按照标准U2F注册方式对所述原始操作数据中的每个认证数据进行验算；
若每个验算均通过，则手机端第二模块将所述原始操作数据中经过所述验算的认证数据和所述原始操作数据中所携带的金额数据进行打包，以生成所述新操作数据。
也就是在原始操作数据中携带金额数据，实际上，金额数据是用户向用户端第一模块输入的，用户端第一模块也将金额数据写在了初步操作请求中，后续步骤中的数据交互，也一直携带了该金额数据。并且在对认证数据进行查验的时候，是逐个对认证数据进行的查验。只有当每次查验均成功之后，才会执行打包的动作。
当然，为了保证安全性，还可以使用一些计算方法将金额数据进行保密处理。如在步骤所述手机端第二模块将所述原始操作数据中经过所述验算的认证数据和所述原始操作数据中所携带的金额数据进行打包前，还包括：
所述手机端第二模块使用哈希算法将所述原始操作数据中所携带的金额数据进行计算。
具体的，步骤所述手机端第二模块使用哈希算法将所述原始操作数据中所携带的金额数据进行计算，包括如下子步骤：
所述手机端第二模块使用哈希算法将所述原始操作数据中所携带的金额数据和随机数进行整体哈希计算，以生成哈希代码；
使用未经过所述哈希计算的金额数据替换所述哈希代码中预定位置的编码。
进而金额数据还可以是以明文的形式发送给了第二认证设备，此处的明文指的是未进行哈希计算，但实际上，在发送前，通常还是会使用通讯加密算法进行一次加密的。
更具体的，金额数据和随机数所形成的代码通常是32字节。其中包括8字节的金额+24字节的challenge(随机数)，通常前8字节是金额，后24字节是随机数。首先，整个32字节经过Hash处理，将处理后的32字节Hash值，前8字节重新替换成8字节交易金额数据，之后再发送给硬件设备。
二、需要对硬件设备(二次认证设备)所参与的工作流程进行说明。
即，步骤S104，所述手机端第二模块按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据包括如下子步骤：
即，按照如下方式进行所述查验：
所述手机端第二模块将所述原始操作数据中的首个认证数据打包成checkOnly指令，并将所述checkOnly指令发送至用户携带的硬件设备；
所述硬件设备按照标准U2F注册方式校验接收到的checkOnly指令，若校验通过，则向所述手机端第二模块返回校验成功信息；
所述手机端第二模块若接收到校验成功信息，则将下一个认证数据打包成checkOnly指令，并将所述checkOnly指令发送至用户携带的硬件设备，并重复执行步骤所述硬件设备按照标准U2F注册方式校验接收到的checkOnly指令，直至手机端第二模块接收到全部认证数据的校验成功信息时，所述查验通过。
也就是查验的过程实质上是将认证数据逐条发送给二次认证设备，二次认证设备接收到认证数据之后显示，以提示用户需要对显示内容进行确认，如果用户认为无误，则会按下二次认证设备上的确认按键，进而使二次认证设备校验成功信息，并将该信息发送给手机端第二模块。
除了对认证数据进行查验，还需要对新操作数据进行确认，也就是本申请所提供的方法，还包括如下步骤：
所述硬件设备根据所述新操作数据进行显示；
若接收到按键确认指令，则所述硬件设备根据所述新操作数据，使用ECDSA算法生成的密钥对，所述密钥对包括公钥和私钥；
所述硬件设备使用所述私钥对所述新操作数据中的SHA2(ClientData)+SHA2(appId)进行签名，以生成签名值；
所述硬件设备将所述公钥、所述硬件设备的标识和所述签名值打包形成所述确认信息；
所述硬件设备将所述确认信息发送至所述手机端第二模块。
其中，ECDSA为椭圆曲线数字签名算法，SHA2(ClientData)+SHA2(appId)为操作数据的哈希结果。
确认信息中的公钥、所述硬件设备的标识和所述签名值均是在后续步骤中需要使用到的，这也是FIDO协议中需要的标准参数。
下面以三个具体的实例，来说明本申请所提供的基于FIDO硬件的用户操作方法。
首先对实例中(和附图中)出现的英文名词和符号进行释义，具体参见下表：
实例1，基于FIDO硬件的用户注册方法。如图2所示，示出了该种方法的网络框架图。图2中，RPClient对应手机端第一模块，FIDOU2FClientSDK对应手机端第二模块，RP对应第一服务器，IDsManager对应第二服务器。其中，手机端第一模块和第一服务器是网络供应商未使用FIDO协议前便具有的设备，手机端第二模块和第二服务器是FIDO协议提供方式所提供的设备，也就是手机端第二模块是网络服务提供方确认使用FIDO协议后，在用户手机中新增加的模块。第二服务器是用来辅助第一服务器，使其具备FIDO协议功能的服务器。从图2中可以直接看出，第二服务器是由两部分组成的，分别是FIDOServer模块和Server4A模块，这两个模块均属于第二服务器的内部结构。
此种方法的前提条件如下：
1，RPClient已在其对应的服务端，注册了用户名、密码，且能正常使用；此处的服务端是指，RPClient是服务商原来已有的服务器，处理自己业务逻辑的服务器(如QQ服务器)；
2，RP集成了RPServerSDK，并在4AServer注册，表示信任4AServer提供的服务，注册成功后，4AServer会颁发给RP一个secretkey(唯一)和AppId(唯一)；
A、RP携带secretkey+AppId向4AServer发送请求，请求颁发token；
B、4AServer响应请求，给RP颁发token，此token在一定单位时间内持续有效；
以后4AServer会根据这个token，验证RP是否有权限访问FIDOU2FServer；
3，FIDOU2FServer具有注册关联，认证，交易确认，验签等功能。
认证过程如下：
首先进行的开始注册请求的流程，步骤1-10.
1，用户登录RP后，点击“注册U2F设备”，RPClient则向RP发起注册设备的Http请求，请求中包括：OAuthAccessToken的Header，Header里面又包括：Authorization：bearer+accesstoken(此次是以使用OAuth协议实现为例进行说明的，如果RP根据其业务需要，使用了其它协议，同样也可以实现这注册、认证和交易确认的流程，例如RP使用Basic协议，那请求中可以直接包含用户名，不需要提取)，请求注册硬件设备；
2，RP收到请求后，携带4AServer颁发的token(b步骤所获得)，向FIDOU2FServer发起开始注册U2F设备Http请求，请求中包括：通过accesstoken换取的用户名username，和RP应用唯一标识AppId，请求注册硬件设备；
3，FIDOU2FServer收到请求后，把token转交给4AServer验证，询问RP是否有权限访问FIDOU2FServer，即是否有之前从4AServer获取的token；本步骤目前仅仅是转交，无其它附加操作，只转交是因为使用了FIDOU2F的协议，必须符合FIDOU2FServer规范；可以根据业务需要进一步扩展；
4，4AServer根据请求的token验证该RP是否有访问FIDOU2FServer的权限，如果返回False(未通过验证)，直接失败处理；否则返回True(通过验证)，通知FIDOU2FServer，RP合法，可以访问FIDOU2FServer，开始注册请求；
5，FIDOU2FServer从4AServer收到RP合法的响应后，产生注册数据，并通过Http响应返还给RP；
注册数据和标准协议一致，包括：
其中具体字段包括：
注册请求数据：
RegistrationData
dictionaryRegisterRequest{
DOMStringversion；U2F版本号
DOMStringchallenge；随机数
DOMStringappId；应用唯一标识
}；
如果提交的用户名已经在服务器注册，服务器还需要额外附加认证数据列表(否则为空)：
SignData
dictionarySignRequest{
DOMStringversion；U2F版本号
DOMStringchallenge；随机数
DOMStringkeyHandle；硬件设备唯一标识
DOMStringappId；应用唯一标识
}；
6，RP将接收到的注册数据通过Http响应返还给RPClient；
7，因为RPClient是没有能力处理U2F注册数据的，处理U2F能力集成在FIDOU2FClientSDK里面，所以RPClient将收到的数据通过相应的API调用，继续传递给FIDOU2FClientSDK，SDK收到注册数据，并给U2F硬件设备发送获取版本命令，用于检查U2F设备支持的U2F协议版本是否匹配；
8，FIDOU2FClientSDK检查U2F设备支持的U2F协议版本，如果得到的版本号匹配，通过开始注册请求返回的认证数据列表(即第5步返回的认证数据列表)做checkOnly，即顺序从认证数据列表中选取第一条认证数据，打包成checkOnly指令，发送给硬件设备(二次认证设备)，硬件设备检查本条指令中的KeyHandle是否是自身生成的，并将反馈结果发送给FIDOU2FClientSDK(是或否的反馈)；FIDOU2FClientSDK收到硬件“是”的反馈，则表示该设备已经被此用户注册过，则设备拒绝本次注册，并在客户端提示用户设备已注册；如果是“否”的反馈，则从认证数据列表中选取下一条认证数据，打包成checkOnly指令，并发送给硬件设备检查，直到所有的认证数据检查完成，如果都是“否”的反馈，则表示该用户还未注册过此设备，SDK根据原注册数据，生成新的注册数据，并根据新的注册数据生成注册请求指令，通过蓝牙或NFC等通讯协议，向U2F发送硬件设备注册请求指令，硬件设备收到后，将会提示用户进行确认；
新的注册数据包括：
SHA2(ClientData)+SHA2(appId)
ClientData{
DOMStringtype；类型为注册类型
DOMStringchallenge；原challenge
DOMStringorigin；原appId
}
9，用户通过按键方式确认后，U2F设备根据注册请求指令，产生一对根据ECDSA算法生成的密钥对，用私钥对SHA2(ClientData)+SHA2(appId)做签名得到签名值，根据自定义的规则生成keyhandle，将上述数据签名，并同时根据厂商公钥生成X509证书。打包之后返回的设备的注册响应数据：新生成的公钥+用户设备唯一标识keyhandle+X509证书+签名值。FIDOU2FClientSDK将U2F设备返回的注册响应数据Base64编码后，与第⑧步生成的客户端数据ClientData数据结构包装成JSON格式发送给FIDOU2FClientSDK；
U2F设备返回的注册响应数据包括：
dictionaryRegisterResponse{
DOMStringregistrationData；注册数据
DOMStringclientData；客户端数据
}；
10，FIDOU2FClientSDK将JSON格式的数据(注册响应数据)交给RPClient，至此，开始注册请求已经完成。
之后，需要进行完成注册请求的流程，步骤10-16。
11，RPClient获得FIDOU2FClientSDK返回的注册响应数据之后，直接向RP发起完成注册设备的Http请求，请求中包括：OAuthAccessToken的Header，Header里面又包括：Authorization：bearer+accesstoken，请求完成注册硬件设备；
12，RP收到请求后，携带4AServer颁发的token(b步骤)，向FIDOU2FServer发起完成注册U2F设备的Http请求，请求中包括：通过accesstoken换取的用户名username，和RP应用唯一标识AppId，请求完成注册硬件设备；
13，FIDOU2FServer收到请求后，把token转交给4AServer验证，询问RP是否有权限访问FIDOU2FServer，即是否有之前从4AServer获取的token；本步骤目前仅仅是转交，无其它附加操作，只转交是因为使用了FIDOU2F的协议，必须符合FIDOU2FServer规范；未来可以根据业务需要进一步扩展；
14，4AServer根据请求的token验证是否有访问FIDOU2FServer的权限，如果返回False(未通过验证)，直接失败处理；否则返回True(通过验证)，通知FIDOU2FServer，RP合法，可以访问FIDOU2FServer，完成注册请求；
15，FIDOU2FServer根据从注册响应里面提取相应的信息后，验证证书有效性，组织U2F设备被签名的数据(SHA2(ClientData)+SHA2(appId))，使用对应的公钥将它和注册响应中的签名值做验签操作，验签成功，服务器将账户信息和公钥，用户设备唯一标识等信息关联在一起，并通知客户端注册成功。如果验证失败返回错误数据；
16，RP向RPClient发送Http响应，注册成功，至此完成注册过程。
有两点需要说明，
1.开始注册请求和完成注册请求的区别：
开始注册请求：是请求U2FServer生成注册数据(主要是里面的challenge)；
完成注册请求：是将U2FServer生成的注册数据经过签名，提交给U2FServer验证设备，验证成功则关联注册信息。
2.反复向4AServer发起验证请求的原因：
要反复向4AServer发起验证请求的原因，是将FIDOU2F服务，做成了云平台的方式，方便了其它第三方应用集成FIDOU2F服务，且只有有访问权限的应用，才能使用云平台(第二服务器)，保证了服务的安全性。
下面对认证流程进行说明，同样，请参照图2：
前提条件：用户已经成功注册硬件认证设备。
认证流程共分为两个步骤：
第一步：开始认证请求流程；
第二步：完成认证请求流程。
开始认证请求流程：(图中1-10)
该步骤与注册流程基本完全一致，区别在于：将数据从ClientSDK发送到U2F设备时的数据格式不一样。U2F设备处理数据的方法也相应进行了调整。具体步骤如下：
1，RPClient向RP发起http请求，请求中包括：当前登录的用户名(用户帐户唯一标识)username(此处不论RP使用什么协议，都会提交给RP用户名)，请求二次认证；
2，RP收到http请求后，携带4AServer颁发的token(b步骤)，向FIDOU2FServer发起开始认证的Http请求，请求中包括：用户名username，应用唯一标识AppId，请求二次认证；
3，FIDOU2FServer收到请求后，把token转交给4AServer验证，询问RP是否有权限访问FIDOU2FServer，即是否有之前从4AServer获取的token；本步骤目前仅仅是转交，无其它附加操作，只转交是因为使用了FIDOU2F的协议，必须符合FIDOU2FServer规范；未来可以根据业务需要进一步扩展；
4，4AServer根据请求的token验证是否有访问FIDOU2FServer的权限，如果返回False(未通过验证)，直接失败处理；否则返回True(通过验证)，通知FIDOU2FServer，RP合法，可以访问FIDOU2FServer，进行二次认证；
5，FIDOU2FServer从4AServer收到RP合法的响应后，产生认证数据，并将Http响应提交给RP；
认证数据和标准协议一致，包括：
认证数据：
SignData
dictionarySignRequest{
DOMStringversion；U2F版本号
DOMStringchallenge；随机数
DOMStringkeyHandle；硬件设备唯一标识
DOMStringappId；应用唯一标识
}；
6，RP将接收到的认证数据通过Http响应返还给RPClient；
7，因为RPClient是没有能力处理U2F认证数据的，处理能力集成在FIDOClientSDK里面，所以RPClient将收到的数据通过相应的API调用，继续传递给FIDOU2FClientSDK，SDK收到认证数据，并给U2F设备发送获取版本命令，用于检查U2F设备支持的U2F协议版本是否匹配；
8，FIDOU2FClientSDK检查U2F设备支持的U2F协议版本，如果得到的版本号匹配，通过开始认证请求返回的认证数据列表(即第5步返回的认证数据列表)做checkOnly，即顺序从认证数据列表中选取第一条认证数据，打包成checkOnly指令，发送给硬件设备，硬件设备检查本条指令中的keyHandle是否是自身生成的，并将反馈结果发送给FIDOU2FClientSDK(是或否的反馈)；如果是“否”的反馈，则从认证数据列表中选取下一条认证数据，打包成checkOnly指令，并发送给硬件设备检查，直到所有的认证数据检查完成，如果都是“否”的反馈，则表示该用户还未注册过此设备，则设备拒绝本次认证，并通知用户此设备为非法设备，不能进行二次认证；如果FIDOU2FClientSDK收到硬件“是”的反馈，表示该设备已经被此用户注册过，则停止checkOnly并允许二次认证，SDK根据原认证数据，生成新的认证数据，同时通过蓝牙或NFC等通讯协议，将新的认证数据打包发送给硬件设备，硬件设备收到后，将会提示用户进行二次认证确认；
新的认证数据为：
SHA2(ClientData)+SHA2(app_id)+KeyHandle.
ClientData{
DOMStringtype；类型为认证类型
DOMStringchallenge；原challenge
DOMStringorigin；原appId
DOMStringorJwKeycid_pubkey；公钥
}
9，用户通过按键方式确认后，U2F设备用私钥对SHA2(ClientData)+SHA2(appId)做签名得到签名值，根据自定义的规则生成keyhandle，将上述数据签名，并同时根据厂商公钥生成X509证书。打包之后返回的设备的认证响应数据：新生成的公钥+用户设备唯一标识keyhandle+X509证书+签名值。FIDOU2FClientSDK将U2F设备返回的认证响应数据Base64编码后，与第⑧步生成的客户端数据ClientData数据结构包装成JSON格式；
U2F设备返回的数据包括：
dictionarySignResponse{
DOMStringkeyHandle；硬件设备唯一标识
DOMStringsignatureData；签名数据
DOMStringclientData；客户端数据
}；
10，FIDOU2FClientSDK将JSON格式的数据交给RPClient，至此，开始认证请求已经完成。
完成认证请求流程：(图中11-16)
11，RPClient将从FIDOU2FClientSDK收到的数据(客户端数据clientData，签名数据signatureData，用户设备唯一标识keyHandle)提交给RP，请求处理；
12，RP收到http请求后，携带4AServer颁发的token(b步骤)，向FIDOU2FServer发起开始认证的Http请求，请求二次认证；
13，FIDOU2FServer收到请求后，把token转交给4AServer验证，询问RP是否有权限访问FIDOU2FServer，即是否有之前从4AServer获取的token；本步骤目前仅仅是转交，无其它附加操作，只转交是因为使用了FIDOU2F的协议，必须符合FIDOU2FServer规范；未来可以根据业务需要进一步扩展；
14，4AServer根据请求的token验证是否有访问FIDOU2FServer的权限，如果返回False(未通过验证)，直接失败处理；否则返回True(通过验证)，通知FIDOU2FServer，RP合法，可以访问FIDOU2FServer，进行二次认证；
15，FIDOU2FServer根据从认证响应里面提取相应的信息后，验证证书有效性，提取U2F设备被签名的数据(SHA2(ClientData)+SHA2(appId))，使用传递过来的对应公钥将它和认证响应中的签名值做验签操作，验签成功，服务器将账户信息和公钥，用户设备唯一标识等信息关联在一起，并通知客户端认证成功(验证失败返回错误数据)；
16，RP向RPClient发送二次认证成功的消息，至此完成二次认证过程。
下面对交易确认流程进行说明：
交易确认流程共分为两个步骤：
第一步：开始交易确认请求；
第二步：完成交易确认请求。
开始交易确认请求：(图中1-10)
交易确认功能是基于FIDOU2F协议扩展而来，标准FIDOU2F协议不支持交易确认功能。
该步骤与完成认证流程相同，区别在于处理的随机数challenge不一致，随机数challenge做了些变动，原来challenge共32字节，现在challenge前8字节保存金额，后24字节保存challenge。具体实现方法是ChallengeHash之后生成的字串，前8位会被重新替换为金额，形成新的字串。之后U2FServer也会使用这个新字串，附加原有的其它相关信息，生成相应的签名数据。
1，RPClient向RP发起开始交易确认的Http请求，请求中包括：当前登录的用户名(用户帐户唯一标识)username，应用唯一标识AppId，交易金额money，请求交易确认；
2，RP收到请求后，携带4AServer颁发的token(b步骤)，向FIDOU2FServer发起请求，请求中包括：用户名username，应用唯一标识AppId，交易金额money，请求交易确认；
3，FIDOU2FServer收到请求后，把token转交给4AServer验证，询问RP是否有权限访问FIDOU2FServer，即是否有之前从4AServer获取的token；本步骤目前仅仅是转交，无其它附加操作，只转交是因为使用了FIDOU2F的协议，必须符合FIDOU2FServer规范；未来可以根据业务需要进一步扩展；
4，4AServer根据请求的token验证是否有访问FIDOU2FServer的权限，如果返回False(未通过验证)，直接失败处理；否则返回True(通过验证)，通知FIDOU2FServer，RP合法，可以访问FIDOU2FServer，进行交易确认；
5，FIDOU2FServer收到可以交易确认的响应后，产生交易确认数据，发送给RP；
交易确认数据和认证数据一致，区别在于：随机数challenge做了些变动，原来challenge共32字节，现在challenge前8字节保存金额，后24字节保存challenge
交易确认数据包括：
SignData
dictionarySignRequest{
DOMStringversion；U2F版本号
DOMStringchallenge；随机数
DOMStringkeyHandle；硬件设备唯一标识
DOMStringappId；应用唯一标识
}；
6，RP将接收到的数据通过Http响应提交给RPClient；
7，因为RPClient是没有能力处理U2F注册数据的，处理能力都集成在FIDOClientSDK里面了，所以RPClient将收到的数据通过相应的API调用，传递给FIDOU2FClientSDK，SDK收到注册数据，并给U2F设备发送获取版本命令，用于检查U2F设备支持的U2F协议版本是否匹配；
8，FIDOU2FClientSDK检查U2F设备支持的U2F协议版本，如果得到的版本号匹配，通过开始注册请求返回的认证数据列表(即第2步返回的认证数据列表)做checkOnly，即顺序从认证数据列表中选取第一条认证数据，打包成checkOnly指令，发送给硬件设备，硬件设备检查本条指令中的keyHandle是否是自身生成的，并将反馈结果发送给FIDOU2FClientSDK(是或否的反馈)；如果是“否”的反馈，则从认证数据列表中选取下一条认证数据，打包成checkOnly指令，并发送给硬件设备检查，直到所有的认证数据检查完成，如果都是“否”的反馈，则表示该用户还未注册过此设备，则设备拒绝本次交易确认，并通知用户此设备为非法设备，不能进行交易确认；如果FIDOU2FClientSDK收到硬件“是”的反馈，表示该设备已经被此用户注册过，则停止checkOnly并允许交易确认，FIDOU2FClientSDK通过蓝牙或NFC等通讯协议，将请求交易确认的数据重新打包，将8字节的金额+24字节的部分challenge，整个32字节经过Hash处理，将处理后的32字节Hash值，前8字节重新替换成8字节交易金额数据，再发送给硬件设备，硬件设备将会在硬件上显示交易金额，并提示用户进行交易确认；
交易确认数据为：
SHA2(ClientData)+SHA2(app_id)+KeyHandle.
ClientData{
DOMStringtype；类型为认证类型
DOMStringchallenge；处理过的challenge
DOMStringorigin；原appId
DOMStringorJwKeycid_pubkey；公钥
}
9，用户通过按键方式确认后，U2F设备用私钥对SHA2(ClientData)+SHA2(appId)做签名得到签名值，根据自定义的规则生成keyhandle，将上述数据签名，并同时根据厂商公钥生成X509证书。打包之后返回的设备的注册响应数据：新生成的公钥+用户设备唯一标识keyhandle+X509证书+签名值。FIDOU2FClientSDK将U2F设备返回的数据Base64编码后与第⑧步生成的ClientData数据结构包装成JSON格式；
10，FIDOU2FClientSDK将JSON格式的数据交给RPClient，至此，开始交易请求已经完成。
完成交易确认请求：(图中11-16)
11，RPClient将从FIDOU2FClientSDK收到的数据(客户端数据clientData，签名数据signatureData，用户设备唯一标示keyHandle)提交给RP，请求处理；
12，RP收到请求后，携带4AServer颁发的token(b步骤)，向FIDOU2FServer发起请求，请求交易确认；
13，FIDOU2FServer收到请求后，把token转交给4AServer验证，询问RP是否有权限访问FIDOU2FServer，即是否有之前从4AServer获取的token；本步骤目前仅仅是转交，无其它附加操作，只转交是因为使用了FIDOU2F的协议，必须符合FIDOU2FServer规范；未来可以根据业务需要进一步扩展；
14，4AServer根据请求的token验证是否有访问FIDOU2FServer的权限，如果返回False(未通过验证)，直接失败处理；否则返回True(通过验证)，通知FIDOU2FServer，RP合法，可以访问FIDOU2FServer，进行交易确认；
15，FIDOU2FServer根据从交易确认响应里面提取相应的信息后，验证证书有效性，提取U2F设备被签名的数据(SHA2(ClientData)+SHA2(appId))，同时需要把前面存储的32位challenge(前8字节为金额的特殊challenge，同第5步)调出来，hash后形成新的32字节的新字符串，与此同时，把新字符串前8字节替换成交易金额数字，组装成一个新的ClientData,连同其它相关数据，使用传递的对应公钥将它和交易确认响应中的签名值做验签操作，验签成功，服务器将账户信息和公钥，用户设备唯一标识等信息关联在一起，并通知客户交易成功；验证失败返回错误数据；
16，RP向RPClient发送交易确认成功的消息，至此完成交易确认过程。
整体来看本申请所提供的方法，特别是针对交易确认流程的方法，能够在不降低U2F协议安全性的同时，让U2F实现交易确认。具体理由进行如下说明。
综述：
实现交易确认，需要遵循以下几条准则：
a、交易确认的安全等级应大于或等于认证的安全等级(因为涉及到用户资金安全，所以交易确认的安全等级肯定是要高于或至少等于认证的安全等级，而交易确认的签名、验签方式与认证一样，流程也与认证一样，因此交易确认的安全等级等于认证的安全等级)；
b、一方面，硬件设备应当支持为用户显示金额，这样才能让用户感知到此次交易的实际金额；
c、而且也应当和认证一样，让用户在设备上进行确认操作之后(交易确认第9步，硬件设备一般是带触点按键的，按下按键或者触点进行确认，没有按键的一般是拔插一下设备进行确认)，交易才能真正的被进行。
标准U2F分析：
标准U2F协议考虑范围是简化密码，二次认证。因此和交易确认相关的安全是没有在协议范围内的。U2F是不能离开硬件设备的，因此交易确认也必须让用户和相应的硬件设备交互。
根据综述中的b准则,首先U2F协议无法告知硬件设备交易的金额(因为传输的具体数据中，无任何金额字段)。其次，交易确认也不在标准U2F协议规范内。
本申请所提供的方法中，所使用的网络架构解决方案分析：
U2F协议中，U2F服务器会产生一条非常关键的数据:challenge。标准的协议中它是32字节的随机数。为U2F扩展交易确认时，云平台从challenge入手，将它前8字节替换成交易的金额。
因此，交易确认时，challenge变为"8+24"位(前8位为金额，后24位为随机数)。将这"8+24"位challenge下发到U2FSDK后，SDK会将它Hash成32字节的Hash值。而Hash值的前8位显然已经不再是challenge中的金额了。下一步便是将"8+24"位challenge的前8位金额替换掉Hash值的前8位，这样Hash值也变成"8+24"为Hash值(前8位是金额)。SDK随后将Hash值发送到硬件设备中，这样硬件设备便可以获得交易的金额了(当然单位是元)。硬件设备(也应该在标准协议上扩展显示金额的功能，但属于现有技术，因此略过)将金额进行显示之后，将本次SDK发送的指令当做认证指令处理即可。
随后完成交易确认的数据被发送到U2FServer，U2FServer根据SDK中Hash规则生成Hash值，对完成交易确认的数据验证签名即可。验证通过则进行交易，否则失败。
结论：
交易确认的变化在于challenge和它的Hash值，而硬件设备对交易确认指令的签名过程等均是采用认证时的签名过程，U2F服务器验证签名的过程也和认证时一样。可以说交易确认的安全性和认证是一样的。
同时扩展的硬件设备能够显示交易的金额，用户交互也和认证时一样，满足综述中的所有准则。因此，本申请所提供的方法能够在U2F协议规范的安全范围内，支持交易确认！
challenge的作用说明：
在标准U2F协议中，当用户需要使用U2F硬件设备做认证操作时，服务器产生challenge(挑战数据)，并将其和其它认证数据(前文认证流程第5步认证数据)一起通过Http请求发送给客户端。客户端收到认证数据后，向U2F设备发送获取版本命令，用于检查U2F设备支持的U2F协议版本是否匹配；客户端检查U2F设备支持的U2F协议版本，如果得到的版本号匹配，通过开始认证请求返回的认证数据列表(即第5步返回的认证数据列表)做checkOnly，当U2F设备允许二次认证时，客户端根据原认证数据，生成新的认证数据(新的认证数据中的challenge是原challenge)，同时通过蓝牙或NFC等通讯协议，将新的认证数据打包发送给U2F设备。U2F设备收到后，验证认证数据成功后，将会提示用户进行二次认证确认(见上文认证流程第8步)。
用户按键确认后，U2F设备通过对应的私钥对challenge做签名(见上文认证流程第9步)，客户端收到签名值等数据后，将其返回给服务器，服务器验证签名值，如果签名正确，说明用户拥有合法U2F设备(见上文认证流程第15步)，完成进行二次认证。
结论：challenge在认证流程中，U2F并不关心challenge数据的具体内容是什么(否则也不会使用随机数)，只是做签名和验签使用。
在交易确认流程中，challenge仍是32位，并没有减少，"8+24"位(前8位为金额，后24位为随机数)整个看做是challenge，而整个交易确认流程其实与认证流程一致，流程中对challenge的处理方式与标准U2F协议一致，因此不会降低安全性或其它性能。
与基于FIDO硬件的用户操作方法相对应的，本申请还提供了基于FIDO硬件的用户操作系统，如图3所示，包括如下结构：
手机端第一模块301，用于生成初步操作请求，并向通过第一服务器303向第二服务器304发送所述初步操作请求；
第二服务器304，用于验证所述第一服务器303是否具有访问权限，若是，则根据所述初步操作请求生成原始操作数据；
第二服务器304，还用于通过第一服务器303向手机端第一模块301发送所述原始操作数据；
手机端第二模块302，用于按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据；
若手机端第二模块302接收到所述新操作数据的确认信息，则手机端第一模块301，还用于向第一服务器303发起完成操作请求，所述完成操作请求中携带有所述确认信息；
所述第一服务器303，还用于将所述完成操作请求和预先生成的第一服务器303验证信息发送至第二服务器304；
所述第二服务器304，还用于分别对所述验证信息和所述完成操作请求进行核对，若所述核对通过，则将所述确认信息中的数据进行关联，并存储在本地，且通过第一服务器303向所述手机端第一模块301发出操作成功信息。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.基于FIDO硬件的用户操作方法，其特征在于，包括：
手机端第一模块生成初步操作请求，并向通过第一服务器向第二服务器发送所述初步操作请求；
第二服务器验证所述第一服务器是否具有访问权限，若是，则根据所述初步操作请求生成原始操作数据；
第二服务器通过第一服务器向手机端第一模块发送所述原始操作数据；
手机端第二模块按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据；
若手机端第二模块接收到所述新操作数据的确认信息，则手机端第一模块向第一服务器发起完成操作请求，所述完成操作请求中携带有所述确认信息；
所述第一服务器将所述完成操作请求和预先生成的第一服务器验证信息发送至第二服务器；
所述第二服务器分别对所述验证信息和所述完成操作请求进行核对，若所述核对通过，则将所述确认信息中的数据进行关联，并存储在本地，且通过第一服务器向所述手机端第一模块发出操作成功信息。
2.根据权利要求1所述的基于FIDO硬件的用户操作方法，其特征在于，所述初步操作请求是以下多种中的一种：初步注册请求、初步认证请求和初步交易确认请求。
3.根据权利要求2所述的基于FIDO硬件的用户操作方法，其特征在于，若所述初步操作请求是初步交易确认请求，则所述步骤手机端第二模块按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据包括：
手机端第二模块按照标准U2F注册方式对所述原始操作数据中的每个认证数据进行验算；
若每个验算均通过，则手机端第二模块将所述原始操作数据中经过所述验算的认证数据和所述原始操作数据中所携带的金额数据进行打包，以生成所述新操作数据。
4.根据权利要求3所述的基于FIDO硬件的用户操作方法，其特征在于，在所述手机端第二模块将所述原始操作数据中经过所述验算的认证数据和所述原始操作数据中所携带的金额数据进行打包前，还包括：
所述手机端第二模块使用哈希算法将所述原始操作数据中所携带的金额数据进行计算。
5.根据权利要求4所述的基于FIDO硬件的用户操作方法，其特征在于，所述手机端第二模块使用哈希算法将所述原始操作数据中所携带的金额数据进行计算包括：
所述手机端第二模块使用哈希算法将所述原始操作数据中所携带的金额数据和随机数进行整体哈希计算，以生成哈希代码；
使用未经过所述哈希计算的金额数据替换所述哈希代码中预定位置的编码。
6.根据权利要求1所述的基于FIDO硬件的用户操作方法，其特征在于，还包括：
若所述核对未通过，则将未通过核对的信息发送至第一服务器。
7.根据权利要求1所述的基于FIDO硬件的用户操作方法，其特征在于，
步骤所述手机端第二模块按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据包括：
按照如下方式进行所述查验：
所述手机端第二模块将所述原始操作数据中的首个认证数据打包成checkOnly指令，并将所述checkOnly指令发送至用户携带的硬件设备；
所述硬件设备按照标准U2F注册方式校验接收到的checkOnly指令，若校验通过，则向所述手机端第二模块返回校验成功信息；
所述手机端第二模块若接收到校验成功信息，则将下一个认证数据打包成checkOnly指令，并将所述checkOnly指令发送至用户携带的硬件设备，并重复执行步骤所述硬件设备按照标准U2F注册方式校验接收到的checkOnly指令，直至手机端第二模块接收到全部认证数据的校验成功信息时，所述查验通过。
8.根据权利要求7所述的基于FIDO硬件的用户操作方法，其特征在于，还包括：
所述硬件设备根据所述新操作数据进行显示；
若接收到按键确认指令，则所述硬件设备根据所述新操作数据，使用ECDSA算法生成的密钥对，所述密钥对包括公钥和私钥；
所述硬件设备使用所述私钥对所述新操作数据中的哈希计算结果进行签名，以生成签名值；
所述硬件设备将所述公钥、所述硬件设备的标识和所述签名值打包形成所述确认信息；
所述硬件设备将所述确认信息发送至所述手机端第二模块。
9.基于FIDO硬件的用户操作系统，其特征在于，包括：
手机端第一模块，用于生成初步操作请求，并向通过第一服务器向第二服务器发送所述初步操作请求；
第二服务器，用于验证所述第一服务器是否具有访问权限，若是，则根据所述初步操作请求生成原始操作数据；
第二服务器，还用于通过第一服务器向手机端第一模块发送所述原始操作数据；
手机端第二模块，用于按照标准U2F注册方式对所述原始操作数据中的认证数据进行查验，若查验通过，则根据所述原始操作数据生成新操作数据；
若手机端第二模块接收到所述新操作数据的确认信息，则手机端第一模块，还用于向第一服务器发起完成操作请求，所述完成操作请求中携带有所述确认信息；
所述第一服务器，还用于将所述完成操作请求和预先生成的第一服务器验证信息发送至第二服务器；
所述第二服务器，还用于分别对所述验证信息和所述完成操作请求进行核对，若所述核对通过，则将所述确认信息中的数据进行关联，并存储在本地，且通过第一服务器向所述手机端第一模块发出操作成功信息。
10.根据权利要求9所述的基于FIDO硬件的用户操作系统，其特征在于，所述初步操作请求是以下多种中的一种：初步注册请求、初步认证请求和初步交易确认请求。
CN201610119317.6A 2016-03-02 2016-03-02 基于fido硬件的用户操作方法及系统 Pending CN105721480A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610119317.6A CN105721480A (zh) 2016-03-02 2016-03-02 基于fido硬件的用户操作方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610119317.6A CN105721480A (zh) 2016-03-02 2016-03-02 基于fido硬件的用户操作方法及系统

Publications (1)

Publication Number Publication Date
CN105721480A true CN105721480A (zh) 2016-06-29

Family

ID=56156340

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610119317.6A Pending CN105721480A (zh) 2016-03-02 2016-03-02 基于fido硬件的用户操作方法及系统

Country Status (1)

Country Link
CN (1) CN105721480A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107196922A (zh) * 2017-05-03 2017-09-22 国民认证科技（北京）有限公司 身份认证方法、用户设备和服务器
CN108712409A (zh) * 2018-05-09 2018-10-26 梧州市兴能农业科技有限公司 一种基于私有区块链的电子账单交易系统
CN109302286A (zh) * 2018-10-26 2019-02-01 江苏恒宝智能系统技术有限公司 一种Fido设备密钥索引的生成方法
CN110889698A (zh) * 2018-09-07 2020-03-17 深圳市文鼎创数据科技有限公司 一种命令处理方法、电子设备及存储介质
WO2022142456A1 (zh) * 2020-12-28 2022-07-07 飞天诚信科技股份有限公司 一种密钥设备的工作方法及密钥设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103856332A (zh) * 2014-03-22 2014-06-11 中国科学院信息工程研究所 一种多屏多因子便捷web身份认证的一对多账号映射绑定的实现方法
CN104283886A (zh) * 2014-10-14 2015-01-14 中国科学院信息工程研究所 一种基于智能终端本地认证的web安全访问的实现方法
US20150269369A1 (en) * 2014-03-19 2015-09-24 BluInk Ltd. Methods and systems for data entry
CN105144656A (zh) * 2013-04-26 2015-12-09 交互数字专利控股公司 用于实现要求的认证确保级别的多因素认证

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105144656A (zh) * 2013-04-26 2015-12-09 交互数字专利控股公司 用于实现要求的认证确保级别的多因素认证
US20150269369A1 (en) * 2014-03-19 2015-09-24 BluInk Ltd. Methods and systems for data entry
CN103856332A (zh) * 2014-03-22 2014-06-11 中国科学院信息工程研究所 一种多屏多因子便捷web身份认证的一对多账号映射绑定的实现方法
CN104283886A (zh) * 2014-10-14 2015-01-14 中国科学院信息工程研究所 一种基于智能终端本地认证的web安全访问的实现方法

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
FIDO联盟: "《FIDO Technical Glossary》", 《HTTPS://WWW.FIDOALLIANCE.ORG》 *
FIDO联盟: "《FIDO U2F Raw Message Formats》", 《HTTPS://WWW.FIDOALLIANCE.ORG》 *
FIDO联盟: "《FIDO UAF Architectural Overview》", 《HTTPS://WWW.FIDOALLIANCE.ORG》 *
FIDO联盟: "《The FIDO Alliance Whitepaper on FIDO 1.0 Final Specifications》", 《HTTPS://WWW.FIDOALLIANCE.ORG》 *
王耀龙: "《基于FIDO架构在线指纹识别系统客户端的设计与实现》", 《中国优秀硕士学位论文全文数据库信息科技辑》 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107196922A (zh) * 2017-05-03 2017-09-22 国民认证科技（北京）有限公司 身份认证方法、用户设备和服务器
CN107196922B (zh) * 2017-05-03 2020-08-04 国民认证科技（北京）有限公司 身份认证方法、用户设备和服务器
CN108712409A (zh) * 2018-05-09 2018-10-26 梧州市兴能农业科技有限公司 一种基于私有区块链的电子账单交易系统
CN110889698A (zh) * 2018-09-07 2020-03-17 深圳市文鼎创数据科技有限公司 一种命令处理方法、电子设备及存储介质
CN110889698B (zh) * 2018-09-07 2023-07-07 深圳市文鼎创数据科技有限公司 一种命令处理方法、电子设备及存储介质
CN109302286A (zh) * 2018-10-26 2019-02-01 江苏恒宝智能系统技术有限公司 一种Fido设备密钥索引的生成方法
WO2022142456A1 (zh) * 2020-12-28 2022-07-07 飞天诚信科技股份有限公司 一种密钥设备的工作方法及密钥设备

Similar Documents

Publication Publication Date Title
US11218323B2 (en) Method and system for producing a secure communication channel for terminals
KR101883156B1 (ko) 인증 시스템 및 방법과 이를 수행하기 위한 사용자 단말, 인증 서버 및 서비스 서버
EP3230917B1 (en) System and method for enabling secure authentication
US10045210B2 (en) Method, server and system for authentication of a person
CN111131416B (zh) 业务服务的提供方法和装置、存储介质、电子装置
KR101744747B1 (ko) 휴대 단말기, 단말기 및 보안쿠키를 이용한 인증 방법
CN105721480A (zh) 基于fido硬件的用户操作方法及系统
US20180025332A1 (en) Transaction facilitation
CN108199847B (zh) 数字安全处理方法、计算机设备及存储介质
CN113541970B (zh) 分布式标识符的使用方法和分布式标识符使用系统
US20150067799A1 (en) Electronic password generating method, electronic password generating apparatus and electronic password authentication system
CN105812334A (zh) 一种网络认证方法
JP6407232B2 (ja) ログイン認証システム、ログイン認証システムにおけるサービスプロバイダ及び認証サーバ、ログイン認証システムにおけるサービスプロバイダ、認証サーバ、コンピュータ及び携帯端末のためのログイン認証方法及びプログラム
CN104835038A (zh) 一种联网支付装置及方法
CN108768655B (zh) 动态口令生成方法和系统
EP3063920B1 (en) Method for setting up, via an intermediate entity, a secure session between a first and a second entity, and corresponding entities and computer program products
CN112150158A (zh) 一种区块链交易交付验证方法及装置
JP2024510461A (ja) 接続回復力のある多要素認証
CN114553445A (zh) 设备方法、装置、电子设备及可读存储介质
JP4692922B2 (ja) ローカル端末、リモート端末、アプリケーションアクセス制御システム、その動作方法及び動作プログラム
KR101675880B1 (ko) Ｕｓｉｍ을 이용하는 ｏｔｐ 인증을 제공하는 인증 서비스 장치 및 이를 위한 방법
JP2015176167A (ja) ユーザ識別情報を安全に検証するためのネットワーク認証方法
US11985254B2 (en) Threshold multi-party computation with must-have member
KR102547682B1 (ko) Puf기반 otp를 이용하여 사용자 인증을 지원하는 서버 및 그 동작 방법
US20240235821A1 (en) Systems and methods for configuring a networked system to perform threshold multi-party computation

Legal Events

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