CN109547400A - 通信方法、完整性验证方法和客户端的服务器注册方法 - Google Patents

通信方法、完整性验证方法和客户端的服务器注册方法 Download PDF

Info

Publication number
CN109547400A
CN109547400A CN201811070400.4A CN201811070400A CN109547400A CN 109547400 A CN109547400 A CN 109547400A CN 201811070400 A CN201811070400 A CN 201811070400A CN 109547400 A CN109547400 A CN 109547400A
Authority
CN
China
Prior art keywords
client
server
information
software configuration
certificate
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
CN201811070400.4A
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.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics 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
Priority claimed from KR1020180002141A external-priority patent/KR20190034048A/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of CN109547400A publication Critical patent/CN109547400A/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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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/3226—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 a predetermined code, e.g. password, passphrase or PIN
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明提供了通信方法、完整性验证方法和客户端的服务器注册方法。一种支持客户端与服务器之间的完整性验证的基于加密安全协议的通信方法，包括：所述服务器从所述客户端接收第一消息，所述第一消息包括对所述客户端的第一完整性验证的请求，以便开始传输层安全(TLS)连接的握手；所述服务器向所述客户端发送第二消息，所述第二消息包括对用于所述第一完整性验证的第一验证信息的请求；所述服务器从所述客户端接收所述第一验证信息，并通过使用所述第一验证信息进行来执行所述第一完整性验证；以及基于所述第一完整性验证的结果在客户端与服务器之间完成握手并执行数据通信。

Description

通信方法、完整性验证方法和客户端的服务器注册方法
相关申请的交叉引用
本申请要求于2017年9月22日在韩国知识产权局提交的韩国专利申请第10-2017-0122884号和于2018年1月8日提交的韩国专利申请第10-2018-0002141号的权益，通过引用将其全部内容并入本文。
技术领域
本发明构思涉及一种向服务器注册客户端的方法以及一种执行客户端与服务器之间的完整性验证的方法，并且更具体地涉及一种在客户端与服务器之间使用基于加密安全协议的通信向服务器注册客户端的方法，以及一种高效地执行客户端和/或服务器的完整性验证的方法。
背景技术
传输层安全(TLS)或安全套接层(SSL)是一种提供互联网的通信安全的加密安全协议。TLS和SSL协议可以使用非对称加密方案来进行认证和密钥交换，并且可以使用对称加密方案来进行保密。特别地，TLS协议可以是请求评议(RFC)5246和RFC 6176中定义的国际互联网工程任务组(IETF)标准协议。
在现有的传统的客户端-服务器计算系统中，当基于标准TLS协议在客户端与服务器之间执行通信时，不能同时一起执行客户端和服务器的完整性验证。因此，为了验证传统的客户端-服务器计算系统中的客户端和服务器的完整性，必须通过使用预定的消息认证码来执行单独的完整性验证。结果，由于无论何时执行单独的完整性验证，都需要使用客户端-服务器计算系统的射频(RF)资源，因此RF资源的使用效率不高。
另外，在传统的客户端-服务器计算系统中，仅当端节点设备(客户端)能够经由直接连接与服务器进行通信时，使用TLS协议的完整性验证方法才可能是适用的。但是，在许多情况下，客户端可能不直接连接到服务器。例如，当服务器经由无线保真(Wi-Fi)等连接到云时，由于客户端中的资源有限，所以客户端可能不支持Wi-Fi。因此，对于不可直接连接到服务器的客户端，服务器不能执行完整性验证。此外，在客户端与服务器未直接连接的情况下，客户端不能在服务器中进行注册。
因此，需要(或期望)一种能够更高效地利用RF资源的改进的完整性验证方法。还需要(或期望)一种能够对未与服务器直接连接的客户端进行注册和完整性验证的改进的注册和完整性验证方法。
发明内容
本发明构思提供了一种在客户端-服务器计算系统中将客户端安全地注册在服务器中的方法以及在客户端与服务器之间执行完整性验证的方法，以高效地利用客户端-服务器计算系统的射频(RF)资源。
本发明构思还提供了一种集线器设备，所述集线器设备可以支持不可直接连接到服务器的端节点设备的服务器注册和完整性验证。所述集线器设备可以具有与服务器的直接连接，并且可以与服务器和端节点设备(第一客户端)两者进行通信。集线器设备(第二客户端)可以使用第一客户端的证书或软件配置信息来代表第一客户端通过服务器执行完整性验证。
根据本发明构思的一些示例实施例，在客户端可以直接连接到服务器的情况下，提供了一种支持客户端与服务器之间的完整性验证的基于加密安全协议的通信方法，所述基于加密安全协议的通信方法包括：所述服务器从所述客户端接收包括对所述客户端的第一完整性验证的请求的第一消息，以便开始传输层安全连接的握手；所述服务器向所述客户端发送第二消息，所述第二消息包括对用于所述第一完整性验证的第一验证信息的请求；所述服务器从所述客户端接收所述第一验证信息，并通过所述第一验证信息来执行所述第一完整性验证；以及基于所述第一完整性验证的结果在所述客户端与所述服务器之间完成握手并执行数据通信。
根据本发明构思的一些示例实施例，在第一客户端不可直接连接到服务器的情况下，提供了一种通过使用基于加密安全协议的通信来执行第一客户端的完整性验证的完整性验证方法，所述完整性验证方法包括：经由网络连接到所述第一客户端的第二客户端向服务器发送包括对所述第一客户端的第一完整性验证的请求的第一消息，以便开始传输层安全连接的握手；所述第二客户端接收第二消息，所述第二消息包括对用于所述第一客户端的第一完整性验证的所述第一客户端的第一验证信息的请求；以及所述第二客户端向所述服务器发送所述第一客户端的第一验证信息。
根据本发明构思的一些示例实施例，在客户端可直接连接到服务器的情况下，提供了一种通过使用基于加密安全协议的通信的客户端的服务器注册方法，所述客户端的服务器注册方法包括：从所述客户端向服务器发送对所述客户端的注册请求，以便开始传输层安全连接的握手；所述客户端从所述服务器接收个人识别码信息；从所述客户端向所述服务器发送对个人识别码认证结果信息的请求，所述个人识别码认证结果信息指示所述个人识别码信息是否已被正确输入到所述服务器；在所述个人识别码信息被正确地输入到所述服务器时，所述客户端从所述服务器接收指示所述个人识别码信息已被正确输入到所述服务器的所述个人识别码认证结果信息；以及所述客户端从所述服务器接收包括所述客户端访问所述服务器的权限的访问令牌。
根据本发明构思的一些示例实施例，在第一客户端不可直接连接到服务器的情况下，提供了一种使用基于加密安全协议的通信的第一客户端的服务器注册方法，所述第一客户端的服务器注册方法包括：从第二客户端向服务器发送对所述第一客户端的注册请求，以便开始传输层安全连接的握手；所述第二客户端从所述服务器接收个人识别码信息，并且从所述第二客户端向所述第一客户端发送所接收的个人识别码信息；从所述第二客户端向所述服务器发送对个人识别码认证结果信息的请求，所述个人识别码认证结果信息指示所述个人识别码信息是否已被正确输入到所述服务器；在所述个人识别码信息被正确输入到所述服务器时，所述第二客户端从所述服务器接收指示所述个人识别码信息已被正确输入到所述服务器的所述个人识别码认证结果信息；以及所述第二客户端从所述服务器接收包括所述第一客户端访问所述服务器的权限的访问令牌，并且从所述第二客户端向所述第一客户端发送所接收的访问令牌。
根据本发明构思的一些示例实施例，提供了一种使用基于加密安全协议的通信的客户端的服务器注册方法，所述客户端的服务器注册方法包括：服务器从所述客户端接收对所述客户端的注册请求，以开始传输层安全连接的握手；所述服务器响应于所述注册请求，通过将个人识别码信息分配给所述客户端，来向所述客户端发送用于所述客户端的所述个人识别码信息；在所述个人识别码信息被正确地输入到所述服务器时，从所述服务器向所述客户端发送指示所述个人识别码信息已经被所述服务器认证了的个人识别码认证结果信息；以及从所述服务器向所述客户端发送包括所述客户端访问所述服务器的权限的访问令牌。在一些示例实施例中，客户端可以是与服务器具有直接连接的端节点设备(第一客户端)。在一些其他示例实施例中，客户端可以是代表不与服务器直接连接的第一客户端执行操作的集线器设备(第二客户端)。
附图说明
从以下结合附图进行的详细描述中，本发明构思的一些示例性实施例将得到更清楚地理解，在附图中：
图1A是根据一些示例实施例的客户端-服务器计算系统的示意性框图；
图1B是根据一些示例实施例的用于描述图1A的传输层安全(TLS)协议栈的示图；
图2是根据一些示例实施例的用于解释执行客户端的服务器注册的客户端-服务器计算系统的操作的流程图；
图3是根据一些其他示例实施例的用于解释执行客户端的服务器注册的客户端-服务器计算系统的操作的流程图；
图4是根据一些示例实施例的用于描述执行完整性验证的客户端-服务器计算系统的操作的流程图；
图5是根据一些示例实施例的用于描述图1B的握手协议的示图；
图6A是根据一些示例实施例的用于描述完整性验证所需的验证信息的示图；
图6B是根据一些示例实施例的用于描述图6A的软件配置类型的示图；
图6C和图6D是根据一些示例实施例的客户端或服务器计算设备的框图；
图7A是根据一些示例实施例的用于描述证书颁发方法的框图；
图7B是根据一些示例实施例的用于描述包括在证书中的完整性验证相关信息的示图；
图7C是用于描述完整性验证相关信息未被包括在证书中而是包括在安全存储区域中的示例实施例的客户端/服务器计算设备的框图；
图7D是根据一些示例实施例的生成软件配置值的方法的流程图；
图8A是根据一些示例实施例的用于描述当软件配置信息被包括在证书中时客户端与服务器之间的第一完整性验证操作的流程图；
图8B是根据一些示例实施例的用于描述当软件配置信息被包括在客户端的存储器的安全存储区域中时客户端与服务器之间的第一完整性验证操作的流程图；
图9是根据一些示例实施例的生成软件配置签名信息的方法的流程图；
图10是根据一些示例实施例的图8A的第一完整性验证操作S250的流程图；
图11是根据一些示例实施例的用于描述执行第二完整性验证的方法的流程图；
图12是根据一些示例实施例的用于描述在客户端与服务器之间的握手间隔中的验证操作的流程图；
图13是根据一些示例实施例的存储作为完整性验证操作的基础的命令的存储介质的框图；
图14是根据一些示例实施例的第一客户端和第二客户端-服务器计算系统的框图；
图15是根据一些示例实施例的执行客户端的服务器注册的第一客户端和第二客户端-服务器计算系统的操作的流程图；
图16是根据一些示例实施例的执行客户端的服务器注册的第一客户端和第二客户端-服务器计算系统的操作的流程图；
图17A图示了根据一些示例实施例的用于解释使用认证密钥的对称密钥方法的网络认证系统；
图17B图示了根据一些示例实施例的用于解释使用认证密钥的对称密钥方法的认证密钥生成协议；
图17C图示了根据一些示例实施例的用于解释使用认证密钥的对称密钥方法的认证消息生成协议；
图17D图示了根据一些示例实施例的用于解释使用认证密钥的对称密钥方法的认证消息验证协议；
图18是根据一些示例实施例的执行第一客户端的完整性验证的第一客户端和第二客户端-服务器计算系统的操作的流程图；
图19A是根据一些示例实施例的当证书包括软件配置信息(如图7B所示)时用于第一客户端的第一完整性验证操作的流程图；
图19B是根据一些示例实施例的当软件配置信息被存储在安全存储区域中(如图7C所示)时用于第一客户端的第一完整性验证操作的流程图；
图20是根据一些示例实施例的在第一客户端、第二客户端和服务器之间的握手间隔中的验证操作的流程图；以及
图21是应用了一些示例实施例的物联网(IoT)网络系统的示例的概念图。
具体实施方式
在下文中，将参照附图详细描述本发明构思的一些示例实施例。示例实施例可以参照可结合下面更详细讨论的单元和/或设备而实现的操作的动作和符号表示(例如，以流程图、流程示意图、数据流图、结构图、框图等的形式)来描述。虽然以特定方式对在特定块中指定的功能或操作进行了讨论，但是可以以不同于流程图、流程示意图等中指定的流程来执行该功能或操作。例如，示出为在两个连续块中串行执行的功能或操作实际上可以同时、同步执行或者在某些情况下以相反的顺序执行。
客户端-服务器结构可以使计算系统的各种角色、操作等能够分布到通过网络连接的多个独立的计算系统中。客户端可以是在客户端平台或客户端设备上执行的软件，服务器可以是在服务器平台或服务器设备上执行的软件。然而，本发明构思不限于此。客户端可以被定义为指示执行客户端相关的软件的物理硬件设备的术语，服务器可以被定义为指示执行服务器相关的软件的物理硬件设备的术语。
图1A是根据一些示例实施例的客户端-服务器计算系统100的示意性框图。
参照图1A，客户端-服务器计算系统100可以包括多个客户端(或多个客户端计算设备)120和多个服务器(或多个服务器计算设备)140，并且客户端120和服务器140可以通过网络160连接。
客户端-服务器计算系统100可以是物联网(IoT)网络系统。根据一些示例实施例，客户端120可以是IoT设备，服务器140可以是集线器设备(或接入点)或路由器。而且，客户端-服务器计算系统100可以是云计算安全系统。根据一些示例实施例，服务器140可以是提供云服务的云服务提供服务器，客户端120可以是使用云服务的设备。
客户端-服务器计算系统100可以对应于普遍存在的下列系统中的一个：传感器网络(USN)通信系统、机器类型通信(MTC)系统、面向机器的通信(MOC)系统、机器对机器(M2M)通信系统和设备到设备(D2D)通信系统。对于客户端120与服务器140之间的通信，客户端-服务器计算系统100可以使用诸如用户数据报协议(UDP)或传输控制协议(TCP)的传输协议、IPv6互联网路由协议和诸如约束应用协议(CoAP)、超文本传输协议(HTTP)、消息队列遥测传输(MQTT)或用于传感器网络(MQTT-SN)的MQTT等应用协议。
客户端120可以通过有线或无线接口与服务器140通信，或者可以通过有线或无线接口彼此通信。有线或无线接口可以包括可连接到以下网络的调制解调器通信接口：局域网(LAN)、诸如无线保真度(Wi-Fi)的无线局域网(WLAN)、诸如蓝牙、无线通用串行总线(无线USB)、ZigBee、近场通信(NFC)、射频识别(RFID)、电力线通信(PLC)的无线个人局域网(WPAN)或诸如第三代(3G)，第四代4G)或长期演进(LTE)的移动蜂窝网络。
例如，客户端120和服务器140可以执行数据通信以通过网络160发送和接收数据信号。具体地，客户端120和服务器140可以通过加密安全协议彼此连接。这可以防止第三方窃听客户端120与服务器140之间的通信(或者至少可以降低被传送的数据的暴露风险)，并且由此可以保证数据的完整性。用于客户端120与服务器140之间的通信的加密安全协议可以是安全套接层(SSL)协议或传输层安全(TLS)协议。以下描述将聚焦于使用TLS协议的客户端-服务器计算系统100，但这仅仅是非限制性示例，并且本发明构思的一些示例实施例不限于此。
客户端120可以包括应用处理器122和基带处理器124。基带处理器124可以包括用于在客户端120与服务器140之间执行基于TLS的通信的TLS协议栈126。应用处理器122可以基于TLS协议栈126来控制用于连接客户端120和服务器140的一系列操作。而且，应用处理器122可以提供较高层(例如，应用层和/或传输层)功能处理，基带处理器124可以提供较低层(例如，物理层和/或网络层)功能处理。
服务器140可以包括应用处理器142和基带处理器144。基带处理器144可以包括用于在服务器140与客户端120之间执行基于TLS的通信的TLS协议栈146。应用处理器142可以基于TLS协议栈146来控制用于连接服务器140和客户端120的一系列操作。而且，应用处理器142可以提供较高层功能处理，基带处理器144可以提供较低层功能处理。
图1B是根据一些示例实施例的用于描述图1A的TLS协议栈126和146中所包括的协议的示图。
参照1B，TLS协议栈TLS_PT_S可以包括握手协议PT1、密码变更协议PT2、警报协议PT3和记录协议PT4。TLS协议栈TLS_PT_S是国际互联网工程任务组(IETF)的标准协议，并且一些示例实施例可以符合IETF的标准协议。
客户端120和服务器140可以基于握手协议PT1为客户端120与服务器140之间的TLS连接执行握手。客户端120和服务器140可以彼此共享在握手间隔中对客户端120与服务器140之间发送和接收的数据、TLS版本信息等进行加密的方法。而且，客户端120和服务器140可以基于握手协议PT1来执行客户端120和服务器140的认证。
客户端120和服务器140可以通知彼此：将会基于密码变更协议PT2，通过应用作为客户端120与服务器140之间的握手的结果而确定的参数，来执行安全通信。客户端120和服务器140可以基于警报协议PT3向彼此报告在安全通信期间出现的错误。客户端120和服务器140可以基于记录协议PT4共享事务层，并且这可以指示在客户端120与服务器140之间连接有会话。客户端120和服务器140可以通过基于记录协议PT4的会话(或事务层)，在客户端120与服务器140之间发送和接收加密数据。
根据一些示例实施例，可以在握手协议PT1中定义用于客户端120和服务器140的完整性验证(ITV)操作。在客户端120与服务器140之间的握手间隔中，客户端120与服务器140可以基于握手协议PT1选择性地进行彼此的数据完整性验证。具体而言，客户端120可以在期间执行与服务器140的握手的间隔中，基于握手协议PT1来验证服务器140的完整性。同样，服务器140可以在期间执行与客户端120的握手的间隔中，基于握手协议PT1来验证客户端120的完整性。而且，在客户端120与服务器140之间的握手间隔中，客户端120和服务器140可以可选地基于握手协议PT1对彼此执行认证操作。然后，可以基于完整性验证结果和认证结果中的至少一个来连接客户端120与服务器140之间的会话。
根据一些示例实施例，由于在客户端120与服务器140之间的基于TLS的通信操作还可以在握手间隔中对客户端120和服务器140执行完整性验证，因此无需配置需要使用客户端-服务器计算系统100中的射频(RF)资源的单独间隔来执行完整性验证，从而与传统的客户端-服务器计算系统相比能够更高效地使用RF资源。而且，由于客户端120或服务器140的完整性验证结果可以在连接客户端120与服务器140之间的会话时被反映，所以客户端120与服务器140之间的通信安全相对于传统的客户端-服务器计算系统有所提升。
图2是根据一些示例实施例的执行客户端的服务器注册的客户端-服务器计算系统100的操作的流程图。
参照图2，客户端120和服务器140可以开始基于TLS的握手(S10)。换句话说，客户端120和服务器140可以基于TLS协议栈的握手协议来开始握手。
客户端120可以向服务器140发送用于客户端120的注册请求以开始TLS连接的握手(S20)。客户端120的注册可以指示在服务器140中注册客户端120以获得对服务器140的访问。
服务器140可以响应于从客户端120接收到的注册请求而向客户端120发送个人识别码(PIN)信息(S30)。如参照图3所描述的，服务器140可以在向客户端120发送PIN信息之前验证客户端120是否通过认证。
在从服务器140接收到PIN信息时，客户端120可以向服务器140发送PIN认证结果信息请求(S40)。PIN认证结果信息可以是指示PIN信息是否已被正确输入到服务器140的PIN输入状态信息。例如，当客户端120从服务器140接收到PIN信息时，客户端120可以经由客户端120中所包括的视觉显示设备和听觉显示设备中的至少一个的显示设备(未示出)来向客户端120的用户呈现PIN信息。用户在经由显示设备获取PIN信息之后可以向服务器140输入PIN信息。客户端120可以确定由用户输入到服务器140的PIN信息是否与发送到客户端120的PIN信息相匹配。当发送到客户端120的PIN信息与由用户输入的PIN信息相匹配时，可以由服务器140确定PIN信息已被用户正确输入。客户端120可以向服务器140发送PIN认证结果信息请求，以验证PIN信息是否已被正确输入。
PIN信息可以由用户输入到服务器140(S50)。当正确的PIN信息被输入时，服务器140可以向客户端120发送指示已经输入了正确的PIN信息的PIN认证结果信息(PIN输入状态信息)(S60)。客户端120可以通过接收指示已经输入了正确的PIN信息的PIN认证结果信息，来验证已经输入了正确的PIN信息。
客户端120可以响应于接收到PIN认证结果信息而向服务器140发送注册完成信号(S70)。当服务器140从客户端120接收到注册完成信号时，服务器140可以向客户端120发送包括客户端120访问服务器140的权限的访问令牌(S80)。之后，客户端120可以通过使用访问令牌来访问服务器140。
然后，客户端120和服务器140可以完成基于TLS的握手(S90)。
根据一些示例实施例，根据使用基于加密安全协议的通信的客户端的服务器注册方法，可以通过在握手间隔中将客户端120注册在服务器140中而安全地将客户端120注册在服务器140中。由于无需配置传统的客户端-服务器计算系统中所需的需要使用客户端-服务器计算系统100中的RF资源的单独间隔来执行完整性验证，所以与传统的客户端-服务器计算系统相比，使用根据图2的基于加密安全协议的通信的客户端的服务器注册方法能够更高效地使用RF资源。
图3是根据一些其他示例实施例的执行客户端120的服务器注册的客户端-服务器计算系统的操作的流程图。
参照图3，客户端120和服务器140可以开始基于TLS的握手(S10')。换句话说，客户端120和服务器140可以基于TLS协议栈的握手协议来开始握手。
客户端120可以向服务器140发送对客户端120的注册请求以开始TLS连接的握手，并且向服务器140发送客户端120的证书和证书签名信息以及注册请求(S20')。
服务器140可以通过使用客户端120的证书和证书签名信息来验证客户端120是否通过认证(S25')。例如，服务器140可以通过使用已经颁发了客户端120的证书的证书颁发机构的公钥来对客户端120的证书签名信息进行解密，并且通过将解密后的值与关于客户端120的证书的认证属性的信息进行比较来验证客户端120的证书。当客户端120的证书通过验证时，服务器140可以确定客户端120通过认证。
服务器140可以将PIN信息发送到客户端120，并且可以将PIN信息有效期与PIN信息一起发送到客户端120(S30')。PIN信息有效期可以指示PIN信息保持有效的时间间隔。PIN信息有效期可以包括数秒至数分钟的时间间隔。在这种情况下，PIN信息在PIN信息有效期内可能是有效的。然而，一些示例实施例不限于此。例如，服务器140可以向客户端120发送指示绝对有效期的PIN信息有效期。在这种情况下，直到PIN信息有效期结束，PIN信息都可以是有效的。另外，在操作S30'中，服务器140还可以向客户端120发送随机数据，以进一步提高安全性。
在从服务器140接收到PIN信息时，客户端120可以向服务器140发送PIN认证结果信息请求(S40')。PIN认证结果信息可以是指示PIN信息是否已经在PIN信息有效期内被正确地输入到服务器140的PIN输入状态信息。
PIN信息可以在PIN信息有效期内由用户输入到服务器140(S50')。当在PIN信息有效期内输入了正确的PIN信息时，服务器140可以向客户端120发送指示已经输入了正确的PIN信息的PIN认证结果信息(PIN输入状态信息)(S60')。客户端120可以通过接收指示已经输入了正确的PIN信息的PIN认证结果信息来验证已经输入了正确的PIN信息。
客户端120可以响应于接收到PIN认证结果信息而向服务器140发送注册完成信号(S70')。当服务器140从客户端120接收到注册完成信号时，服务器140可以向客户端120发送包括访问服务器140的权限的访问令牌以及用于标识客户端120的唯一标识符(ID)(S80')。之后，客户端120可以通过使用访问令牌和唯一ID来访问服务器140。
然后，客户端120和服务器140可以完成基于TLS的握手(S90')。
根据一些示例实施例的使用基于加密安全协议的通信的客户端的服务器注册方法，通过在握手间隔中将客户端120注册到服务器140中，可以将客户端120安全地注册在服务器140中。同样，由于无需配置传统的客户端-服务器计算系统中所需的需要使用客户端-服务器计算系统100中的RF资源的单独间隔来执行完整性验证，所以与传统的客户端-服务器计算系统相比，使用根据图3的基于加密安全协议的通信的客户端的服务器注册方法能够更高效地使用RF资源。
图4是根据一些示例实施例的用于描述执行完整性验证的客户端-服务器计算系统的操作的流程图。
参照图4，在操作S100中，客户端120和服务器140可以开始基于TLS的握手。也就是说，客户端120和服务器140可以基于TLS协议栈的握手协议来开始握手。在操作S110中，客户端120可以向服务器140发出第一完整性验证请求。第一完整性验证可以意味着客户端120的完整性验证。在操作S120中，服务器140可以响应于第一完整性验证请求而向客户端120请求第一完整性验证所需的第一验证信息。在操作S130中，客户端120可以响应于对第一验证信息的请求而向服务器140发送第一验证信息。根据一些示例实施例，第一验证信息可以包括客户端120的软件配置信息和由客户端120生成的软件配置签名信息，其细节将在下面进行描述。在操作S140中，服务器140可以通过使用从客户端120接收到的第一验证信息来执行客户端120的第一完整性验证。在操作S150中，客户端120和服务器140可以完成基于TLS的握手。在操作S160中，可以基于第一完整性验证的结果来连接客户端120与服务器140之间的会话。例如，当客户端120的完整性未被确认时，不连接客户端120与服务器140之间的会话，而仅当客户端120的完整性被确认时，才连接客户端120与服务器140之间的会话，从而实现加密的数据通信。另外，作为非限制性示例，当客户端120的完整性未被验证时，服务器140可以与用户的手机等进行通信以向用户通知客户端120已经被外部恶意软件攻击。恶意软件可以被称为恶意程序，并且作为非限制性示例的恶意软件可以包括计算机病毒、蠕虫病毒、特洛伊木马、间谍软件、餐具广告软件、恐吓软件、犯罪软件、其他恶意软件以及其他恶意程序中的至少一个。
然而，仅参照图4描述了服务器140验证客户端120的完整性的示例实施例，但是本发明构思的示例实施例不限于此。根据一些其他示例实施例，客户端120还可以验证服务器140的完整性，并且下面将描述其细节。
图5是根据一些示例实施例的用于描述图1B的握手协议的示图。
参照图5，握手协议PT1是用于客户端与服务器之间的握手方法的协议。握手协议PT1的内容可以以与握手协议PT1相对应的数据结构DS中的代码格式来定义。也就是说，客户端的应用处理器和服务器的应用处理器可以通过参照与握手协议PT1相对应的数据结构DS来执行客户端与服务器之间的握手。
与握手协议PT1相对应的数据结构DS可以包括扩展区域ER，可以在扩展区域ER中定义在握手间隔中另外执行的操作。根据一些示例实施例，可以在扩展区域ER中定义用于完整性验证的条目20。根据一些示例实施例，用于完整性验证的条目20可以包括与完整性验证请求有关的条目20a和与完整性验证信息有关的条目20b。具体地，客户端或服务器可以通过参照与完整性验证请求有关的条目20a来向对方请求完整性验证，并且客户端或服务器可以通过参照与完整性验证所需的验证信息有关的条目20b来生成验证信息并将验证信息发送给对方。也就是说，客户端和/或服务器可以通过参照在数据结构DS的扩展区域ER中定义的用于完整性验证的条目20，在客户端与服务器之间的握手间隔中执行完整性验证。通过这种方式，客户端和服务器可以根据IETF标准协议在握手间隔中进行完整性验证。
然而，在图5的扩展区域ER中定义的条目20a和20b可以是任意的。图5仅是非限制性示例，并且本发明构思的一些示例实施例不限于此。可以在扩展区域ER中定义用于验证客户端和/或服务器的完整性的各种其他条目。
图6A是根据一些示例实施例的用于描述完整性验证所需的验证信息VI的示图。图6B是根据一些示例实施例的用于描述图6A的软件配置类型SW_CT的示图。
参照图6A，用于执行完整性验证的验证信息VI可以包括软件配置信息SW_CI和软件配置签名信息SW_CSI。根据一些示例实施例，软件配置信息SW_CI可以包括软件配置类型信息SW_CT和与软件配置类型相对应的软件配置值SW_CV。软件配置类型信息SW_CT可以是用于指定要确认值在完整性验证时是否已经改变的对象的信息。例如，服务器可以通过确定与客户端的软件配置类型信息SW_CT相对应的软件配置值SW_CV是否已经改变来执行客户端的完整性验证。软件配置类型信息SW_CT可以指示为了完整性验证而预先设置的软件配置类型，并且软件配置类型可以具有不同的设置。
当客户端接收到软件配置签名信息SW_CSI的请求时，客户端可以响应于对软件配置签名信息SW_CSI的请求而生成软件配置签名信息SW_CSI。客户端可以在客户端内部的安全执行环境中生成软件配置签名信息SW_CSI。安全执行环境可以包括作为不可从外部访问的环境的可信执行环境(TEE)。将参照图9描述生成软件配置签名信息SW_CSI的方法。
参照图6B，软件配置类型信息SW_CT可以指示软件配置类型被设置为非配置类型(空)、进程映射类型(Process_map)、安全策略类型(Security_policy)、进程映射-安全策略类型(Process_map&Security_policy)以及用户定义的类型(User_define)中的一个。
图6C和图6D是根据一些示例实施例的客户端或服务器计算设备600的框图。
参照图6C，客户端或服务器计算设备600可以包括应用处理器620、具有TLS协议栈646的基带处理器640和存储器660。存储器660可以存储操作系统(OS)662，应用处理器620可以读取存储器660并且执行OS 662。根据一些示例实施例，由应用处理器620执行的OS662可以基于预定的(或期望的)安全策略来管理计算设备600的安全。安全策略可以包括关于系统配置文件的配置信息和关于存储器保护技术的配置信息。当软件配置类型信息SW_CT被指定为确认OS 662的安全策略的配置值是否已经为了完整性验证而改变的对象时，可以将软件配置类型信息SW_CT设置为安全策略类型(Security_policy)。
参照图6D，存储器660可以存储OS 662和多个应用664。进程映射可以包括关于计算设备600的存储器660上的代码区域的信息和关于系统执行文件(例如，与应用664有关的执行文件)的信息。当软件配置类型信息SW_CT被指定为确认过程映射图的配置值是否已经为了完整性验证而改变的对象时，可以将软件配置类型信息SW_CT设置为进程映射类型(Process_map)。
当软件配置类型信息SW_CT被指定为确认参照图6C描述的OS 662的安全策略的配置值以及过程映射图的配置值的混合值是否已经为了完整性验证而被改变的对象时，软件配置类型信息SW_CT可以被设置为进程映射-安全策略类型(Process_map&Security_policy)。此外，除了安全策略类型和进程映射类型之外，还可以通过使用由用户指定的软件配置值来验证完整性。在这种情况下，软件配置类型信息SW_CT可以被设置为用户定义的类型(User_define)。但是，图6B仅是非限制性示例，并且本发明构思的示例实施例不限于此。在一些其他示例实施例中，可以根据情况将软件配置类型信息SW_CT设置为各种其他类型。
图7A是用于描述根据一些示例实施例的证书颁发方法的框图。图7B是根据一些示例实施例的用于描述包括在证书30中的完整性验证相关信息的示图。图7C是用于描述完整性验证相关信息未被包括在证书中而是在安全存储区域368中的示例实施例的客户端/服务器计算设备300的框图。图7D是根据一些示例实施例的生成软件配置值的方法的流程图。
参照图7A，客户端/服务器计算设备300可以向证书机构(CA)380提供证书签名请求(CSR)。根据实施例，CSR可以包括客户端/服务器计算设备300的与完整性验证相关的软件配置类型信息，以及与软件配置类型信息相对应的软件配置值。在下文中，客户端/服务器计算设备300意味着客户端或服务器。CA 380可以响应于CSR而向客户端/服务器计算设备300提供证书。证书可以包括CSR中所包括的客户端/服务器计算设备300的软件配置类型信息和与软件配置类型信息相对应的软件配置值。也就是说，证书可以包括在客户端/服务器计算设备300向CA 380提供CSR时的客户端/服务器计算设备300的软件配置信息。
参照图7B，证书可以包括存储关于认证属性的信息的第一区域31a和存储通过使用预定的(或期望的)散列算法、签名算法和CA 380的私钥而由关于认证属性的信息生成的CA签名信息的第二区域31b。
第一区域31a可以包括：存储证书的版本号的信息区域32、存储由CA380分配的唯一号码的序列号信息区域33、存储用于生成CA签名信息的关于诸如安全散列算法(SHA)或数字签名算法(DSA)的加密算法的信息的签名算法信息区域34、证书颁发者标识符信息区域35，存储关于证书有效性批准开始时间和结束时间的信息的证书有效性指示符信息区域36、证书颁发目标(或对象)标识信息区域37，证书颁发目标(或对象)公钥信息区域38和扩展区域39。
根据一些示例实施例，扩展区域39可以存储用于客户端/服务器计算设备300的完整性验证的软件配置信息SW_CI。如上所述，软件配置信息SW_CI可以包括软件配置类型信息39a和对应于软件配置类型信息39a的软件配置值39b。
参照图7C，客户端/服务器计算设备300可以在客户端/服务器计算设备300向CA380提供CSR时(周期性或非周期性地)生成客户端/服务器计算设备300的软件配置信息SW_CI，并将所生成的软件配置信息SW_CI存储在存储器360的安全存储区域368中。安全存储区域368可以是仅可由授权用户访问的区域。也就是说，如图7B所示，客户端/服务器计算设备300可以通过使用包括软件配置信息SW_CI的证书来执行完整性验证。当软件配置信息SW_CI未被包括在证书中时，客户端/服务器计算设备300可以将软件配置信息SW_CI单独存储在安全存储区域368中，从安全存储区域368中读取软件配置信息SW_CI，并使用读取出的软件配置信息SW_CI来执行完整性验证。
参照图7D，当客户端/服务器计算设备300将软件配置信息SW_CI提供给CA 380时，或者当客户端/服务器计算设备300将软件配置信息SW_CI存储在安全存储区域368中时，客户端/服务器计算设备300可以按如下方式生成包括在软件配置信息SW_CI中的软件配置值。在操作S122中，客户端/服务器计算设备300可以读取与为完整性验证而设置的软件配置类型相对应的软件配置。例如，当进程映射类型被设置为软件配置类型时，客户端/服务器计算设备300可以读取关于存储器上的代码区域的信息和关于系统执行文件的信息。在操作S124中，客户端/服务器计算设备300可以可选地将预定的(或期望的)散列算法应用于软件配置的读取值。在操作S126中，客户端/服务器计算设备300可以通过使用所读取的值来生成软件配置值。
图8A是根据一些示例实施例的用于描述当软件配置信息SW_CI被包括在证书30中时在客户端300a与服务器300b之间的第一完整性验证操作的流程图。图8B是根据一些示例实施例的用于描述当软件配置信息SW_CI被包括在客户端300a的存储器360的安全存储区域368中时在客户端300a与服务器300b之间的第一完整性验证操作的流程图。
参照图8A，在操作S210中，客户端300a可以向服务器300b发送包括第一完整性验证请求的第一消息，来开始TLS连接的握手。第一完整性验证可以意味着客户端300a的完整性验证。在操作S220中，服务器300b可以向客户端300a发送包括用于第一完整性验证的对客户端证书的请求和对软件配置签名信息的请求的第二消息。在操作S230中，客户端300a可以响应于对软件配置签名信息的请求而生成软件配置签名信息。在操作S240中，客户端300a可以向服务器300b发送用于在服务器300b中的第一完整性验证的客户端证书和软件配置签名信息。在操作S250中，服务器300b可以通过使用从客户端300a接收的客户端证书和软件配置签名信息来执行第一完整性验证。
参照8B，在操作S210中，客户端300a可以向服务器300b发送包括第一完整性验证请求的第一消息，以开始TLS连接的握手。在操作S222中，服务器300b可以向客户端300a发送包括对用于第一完整性验证的软件配置信息和软件配置签名信息的请求的第二消息。在操作S230中，客户端300a可以响应于对软件配置签名信息的请求而生成软件配置签名信息。在操作S242中，客户端300a可以读取软件配置签名信息和存储在安全存储区域368中的软件配置信息，以在服务器300b中执行第一完整性验证，并将软件配置签名信息和软件配置信息发送到服务器300b。
在读取存储在安全存储区域368中的软件配置信息并将所读取的软件配置信息发送到服务器300b之前，客户端300a可以验证存储在安全存储区域368中的软件配置信息是否已被篡改。根据一些示例实施例，在将软件配置信息存储在安全存储区域368中时，客户端300a还可以将安全签名信息存储在安全存储区域368中。安全签名信息是通过使用密钥对软件配置信息进行加密而获得的信息，并且意味着用于验证存储在安全存储区域368中的软件配置信息是否已被篡改的信息。客户端300a读取存储在安全存储区域368中的软件配置信息和安全签名信息，对安全签名信息进行解密，并且通过将解密后的安全签名信息与读取到的软件配置信息进行比较来验证软件配置信息是否被篡改。客户端300a可以仅向服务器300b发送被验证为非篡改的软件配置信息。对存储在客户端300a的安全存储区域368中的软件配置信息是否被篡改进行验证的操作不限于客户端300a，并且还可以根据一些其他示例实施例由服务器300b执行。在操作S260中，服务器300b可以通过使用从客户端300a接收到的软件配置签名信息和软件配置信息来执行第一完整性验证。
图9是生成图8A的软件配置签名信息的方法的流程图。
参照图8A和图9，在操作S220之后的操作S232中，客户端300a可以从客户端300a的存储器360的安全存储区域368读取与包括在客户端证书中的软件配置类型信息相对应的当前软件配置。客户端300a的当前软件配置可以指示紧接在服务器300b对客户端300a执行完整性验证之前的客户端300a的软件配置状态。在操作S234中，客户端300a可以可选地将预定的(或期望的)散列算法应用于当前软件配置的读取值。在操作S236中，客户端300a可以通过使用读取值来生成当前软件配置值，并且通过使用客户端300a的私钥来对当前软件配置值进行加密以生成软件配置签名信息SW_CSI。客户端300a可以在其中的安全执行环境(例如，TEE)中生成软件配置签名信息SW_CSI。然后，该过程可以进行到操作S240。虽然对图9的操作S232的描述已经聚焦于客户端300a通过参照客户端证书来使用客户端证书的软件配置类型信息的操作，但这仅是非限制性示例，并且本发明构思的一些示例实施例不限于此。例如，根据一些其它示例实施例，客户端300a可以访问安全存储区域368并使用存储在安全存储区域368中的软件配置类型信息。
图10是根据一些示例实施例的图8A的第一完整性验证操作S250的流程图。
参照图8A和图10，在操作S240之后的操作S252中，服务器300b可以通过使用客户端证书的客户端公钥来对从客户端300a接收到的软件配置签名信息进行解密。在操作S254中，服务器300b可以通过将解密后的客户端300a的软件配置签名信息与包括在客户端证书中的客户端300a的软件配置值进行比较来验证客户端300a的完整性。例如，作为比较的结果，当解密后的客户端300a的软件配置签名信息与客户端300a的软件配置值一致时，服务器300b可以确认客户端300a的完整性。然后，该过程可以进行到图4的操作S150。
图11是根据一些示例实施例的用于描述执行第二完整性验证的方法的流程图。
参照图11，在操作S310中，客户端300a可以发送第一消息，以开始TLS连接的握手。在操作S320中，服务器300b可以向客户端300a发送包括第二完整性验证请求和用于第二完整性验证的第二验证信息的第二消息。第二完整性验证可以意味着服务器300b的完整性验证。根据一些示例实施例，服务器300b可以向客户端300a提供服务器证书和包括软件配置签名信息的第二验证信息。如上所述，服务器证书可以包括服务器300b的软件配置信息。根据一些其它示例实施例，服务器300b可以向客户端300a提供包括存储在服务器300b的存储器360的安全存储区域368中的服务器300b的软件配置信息和软件配置签名信息的第二验证信息。在操作S330中，客户端300a可以通过使用从服务器300b接收到的第二验证信息来执行服务器300b的第二完整性验证。
除了完整性验证执行者和对象改变了之外，第二验证信息可以以与图4的第一验证信息相同的方式生成，并且可以以与图4的第一完整性验证相同的方式执行第二完整性验证。将省略第二完整性验证的细节。
图12是根据一些示例实施例的用于描述在客户端420与服务器440之间的握手间隔中的验证操作的流程图。
客户端420和服务器440可以基于图1B中的握手协议PT1执行以下握手，以便连接用于安全数据通信的会话。参照图12，在操作S400中，客户端420可以将客户端问候(hello)消息发送到服务器440，以便开始基于TLS的握手。客户端问候消息可以包括以下信息中的至少一种：客户端420的TLS协议版本信息、过去已连接到服务器440的会话的ID字段信息、第一安全随机数据、客户端420中可支持的加密算法列表以及客户端420中可支持的压缩方法列表。在操作S402中，客户端420可以向服务器440发送包括客户端420的软件配置类型信息的第一完整性验证请求。根据一些示例实施例，客户端420可以向服务器440发送包括图6B所示的软件配置类型信息SW_CT的第一完整性验证请求。例如，当包括在第一完整性验证请求中的软件配置类型信息SW_CT被设置为非配置类型(空)时，服务器440可以不执行第一完整性验证。当包括在第一完整性验证请求中的软件配置类型信息SW_CT被设置为进程映射类型(Process_map)、安全策略类型(Security_policy)、进程映射-安全策略类型(Process_map&Security_policy)和用户定义的类型(User_define)中的一个时，服务器440可以通过使用与所设置的软件配置类型相对应的客户端420的软件配置值来执行第一完整性验证。客户端问候消息和第一完整性验证请求可以被定义为包括在由客户端420发送到服务器440的第一消息中。另外，根据一些示例实施例，根据IETF标准协议，客户端420请求第一完整性验证的操作可以是可选的。
在操作S410中，服务器440可以响应于客户端问候消息而向客户端420发送服务器问候消息。服务器问候消息可以包括以下信息中的至少一种：服务器440的TLS协议版本信息、过去连接到客户端420的会话的ID字段信息、由服务器440生成的第二安全随机数据、从客户端420中可支持的加密算法列表中选择的加密算法和从客户端420中可支持的压缩方法列表中选择的压缩方法。在操作S412中，服务器440可以响应于来自客户端420的客户端问候消息或第一完整性验证请求，而从客户端420请求客户端420的客户端证书和软件配置签名信息。然而，根据一些其它示例实施例，当不需要对客户端420执行完整性验证时，服务器440在操作S412中可以仅从客户端420请求客户端证书。在操作S414中，服务器440可以向客户端420发送包括服务器440的软件配置类型信息的第二完整性验证请求。根据一些示例实施例，服务器440可以向客户端420发送包括图6B所示的软件配置类型信息SW_CT的第二完整性验证请求。例如，当包括在第二完整性验证请求中的软件配置类型信息SW_CT被设置为非配置类型(空)时，客户端420可以不执行第二完整性验证。当包括在第二完整性验证请求中的软件配置类型信息SW_CT被设置为进程映射类型(Process_map)、安全策略类型(Security_policy)、进程映射-安全策略类型(Process_map&Security_policy)和用户定义的类型(User_define)时，客户端420可以通过使用与所设置的软件配置类型相对应的服务器440的软件配置值来执行第二完整性验证。在操作S416中，服务器440可以向客户端420发送服务器440的服务器证书和软件配置签名信息，使得客户端420执行第二完整性验证和/或服务器证书的验证。然而，根据一些其他示例实施例，当不需要执行服务器440的完整性验证时，在操作S416中服务器440可以仅将服务器证书发送到客户端420。在操作S420中，服务器440可以向客户端420提供指示响应于客户端问候消息的消息传输已经完成的服务器问候完成消息。服务器问候消息、对客户端证书和客户端的软件配置签名信息的请求、第二完整性验证请求、服务器证书、服务器440的软件配置签名信息以及服务器问候完成消息可以被定义为包括在由服务器440发送到客户端420的第二消息中。根据IETF标准协议，根据一些其他示例实施例，服务器440的操作S412、S414和S416可以是可选的。
在操作S430中，客户端420可以响应于操作S414的第二完整性验证请求，通过使用服务器440的服务器证书和软件配置签名信息来执行第二完整性验证。具体地，客户端420可以通过使用服务器440的软件配置签名信息和服务器证书中的服务器440的软件配置信息中包括的软件配置值来执行第二完整性验证。也就是说，客户端420可以通过使用服务器证书中包括的服务器公钥来对服务器440的软件配置签名信息进行解密，并且通过将解密后的服务器440的软件配置签名信息与服务器证书中包括的服务器440的软件配置值进行比较来验证服务器440的完整性。例如，作为比较的结果，当解密后的服务器440的软件配置签名信息与服务器证书中包括的服务器440的软件配置值一致时，客户端420可以确认服务器440的完整性(否则，服务器440的完整性未被确认)。
同样，在操作S432中，当从服务器440接收到服务器证书时，客户端420可以对服务器证书执行验证。根据一些示例实施例，客户端420可以通过使用颁发服务器证书的CA的公钥来对服务器证书的签名信息进行解密，并且通过将解密后的服务器证书的签名信息与服务器证书的认证属性进行比较来验证服务器证书。例如，作为比较的结果，当解密后的服务器证书的签名信息与服务器证书的认证属性一致时，客户端420可以验证服务器证书可信(否则，客户端420可以确定服务器证书已被篡改)。
然而，尽管在图12中示出了在操作S420之后执行操作S430和S432，但这仅仅是非限制性示例，并且本发明构思的一些示例实施例不限于此。例如，根据一些其他示例实施例，当可以执行第二完整性验证时，或者当可以执行服务器证书的验证时，可以立即执行操作S430和S432。此外，操作S430和S432的顺序可以由IETF标准协议(或TLS)来定义。
在操作S440中，客户端420可以将客户端420的客户端证书和软件配置签名信息发送到服务器440。然而，根据一些其它示例实施例，当不需要对客户端420执行完整性验证时，在操作S440中客户端420可以仅将客户端证书发送到服务器440。根据一些示例实施例，根据IETF标准协议，客户端420的操作S440可以是可选的。
在操作S450中，客户端420可以通过使用由客户端420生成的第一安全随机数据和由服务器440生成的第二安全随机数据来生成会话密钥，并将所生成的会话密钥发送到服务器440。在操作S452中，客户端420可以向服务器440发送指示通过使用会话密钥来对要向服务器440发送的消息进行加密的变更密码规范消息。在操作S454中，客户端420可以向服务器440发送指示用于握手的消息传输已完成的客户端完成消息。
在操作S460中，服务器440可以响应于操作S402的第一完整性验证请求，通过使用客户端420的客户端证书和软件配置签名信息来执行第一完整性验证。具体地，服务器440可以通过使用客户端420的软件配置签名信息和客户端证书中的客户端420的软件配置信息中所包括的软件配置值来执行第一完整性验证。即，服务器440可以通过使用客户端证书中所包括的客户端公钥来对客户端420的软件配置签名信息进行解密，并且通过将解密后的客户端420的软件配置签名信息与包括在客户端证书中的客户端420的软件配置值进行比较来验证客户端420的完整性。例如，作为比较的结果，当解密后的客户端420的软件配置签名信息与包括在客户端证书中的客户端420的软件配置值一致时，服务器440可以确认客户端420的完整性(否则，客户端420的完整性未被确认)。
同样，在操作S462中，当从客户端420接收到客户端证书时，服务器440可以对客户端证书执行验证。根据一些示例实施例，服务器440可以通过使用已经颁发了客户端证书的CA的公钥来对客户端证书的签名信息进行解密，并且通过将解密后的客户端证书的签名信息与客户端证书的认证属性进行比较来验证客户端证书。例如，作为比较的结果，当解密后的客户端证书的签名信息与客户端证书的认证属性一致时，服务器440可以验证客户端证书可信(否则，服务器440可以确定客户证书已被篡改)。
然而，尽管在图12中示出了在操作S454之后执行操作S460和S462，这仅是非限制性示例，并且本发明构思的一些示例实施例不限于此。例如，根据一些其他示例实施例，当可以执行第一完整性验证时，或者当可以执行客户端证书的验证时，可以立即执行操作S460和S462。此外，操作S460和S462的顺序可以由IETF标准协议(或TLS)来定义。
在操作S470中，服务器440可以向客户端420发送指示通过使用所接收的会话密钥来对要向客户端420发送的消息进行加密的变更密码规范消息。在操作S472中，服务器440可以向客户端420发送指示用于握手的消息传输已完成的服务器完成消息。
在操作S480中，可以基于完整性验证的结果和证书验证的结果中的至少一个来连接客户端420与服务器440之间的会话。根据一些示例实施例，当客户端420和服务器440中的至少一个的完整性没有被确认时，或者当确定客户端420和服务器440中的至少一个的证书被篡改时，可能不连接客户端420与服务器440之间的会话。
这样，根据本发明构思的一些示例实施例，与传统的客户端-服务器计算系统相比，可以通过在客户端420与服务器440之间的握手间隔中的完整性验证来进一步提高数据通信的安全性。
图13是根据一些示例实施例的存储作为完整性验证操作的基础的命令的存储介质的框图。
参照图13，客户端/服务器计算设备500可以包括应用处理器510和存储介质520。存储介质520可以存储可由应用处理器510读取的非暂时性信息。存储介质520可以存储可由应用处理器510执行的命令(CMD)。根据一些示例实施例，存储介质520可以包括存储用于为了TLS连接的目的而在握手间隔中执行完整性验证的命令的区域522。包括在客户端计算设备500中的应用处理器510可以读取存储在存储介质520的区域522中的命令，在TLS连接的握手间隔中从服务器计算设备接收服务器证书和软件配置签名信息，并且通过使用软件配置签名信息、包括在服务器证书中的公钥、服务器计算设备的软件配置类型信息以及服务器计算设备的软件配置值来执行服务器计算设备的完整性验证。
同样，包括在服务器计算设备500中的应用处理器510可以读取存储在存储介质520的区域522中的命令，在与客户端计算设备的TLS连接的握手间隔中从客户端计算设备接收客户端证书和软件配置签名信息，并且通过使用软件配置签名信息、包括在客户端证书中的公钥、客户端计算设备的软件配置类型信息以及客户端计算设备的软件配置值来执行客户端计算设备的完整性验证。
图14是根据一些示例实施例的用于示意性解释第一客户端和第二客户端-服务器计算系统1100的框图。
参照图14，第一客户端和第二客户端-服务器计算系统1100可以包括第一客户端1110、第二客户端1120和服务器1140。第一客户端1110和第二客户端1120均可以对应于图1中的客户端120，服务器1140可以对应于图1中的服务器140。特别地，图14中公开的第一客户端和第二客户端-服务器计算系统1100可以示出第一客户端1110不能够直接与服务器1140通信的情况。第一客户端1110不能够与服务器1140直接通信的情况可以变化。例如，当第一客户端1110由于资源限制而不支持无线保真(Wi-Fi)通信而服务器1140支持Wi-Fi通信时，第一客户端1110可能不能够直接与服务器1140通信。然而，一些示例实施例不限于此。根据一些其它示例实施例，在诸如网状网络的网络系统中，可能存在第一客户端1110与第二客户端1120之间的第一网络Network1能够被连接而第二客户端1120与服务器1140之间的第二网络Network2被断开的情况。
第一客户端1110可以经由第一网络Network1与第二客户端1120通信，第二客户端1120可以经由第二网络Network2与服务器1140通信。在上述第一客户端和第二客户端-服务器计算系统1100中，第二客户端1120和服务器1140可以执行参照图1至图13描述的客户端-服务器计算系统100中的服务器注册和完整性验证操作。然而，由于第一客户端1110和服务器1140不能直接相互通信，因此上面参照图1至图13描述的客户端-服务器计算系统100的服务器注册方法和完整性验证方法可能不可适用于第一客户端1110。
在这种情况下，经由第一网络Network1连接到第一客户端1110并经由第二网络Network2连接到服务器1140的第二客户端1120可以代表第一客户端1110支持服务器注册和完整性验证操作。参照图15至图20进行描述。
图15是用于解释根据一些示例实施例的执行第一客户端1110的服务器注册的第一客户端和第二客户端-服务器计算系统1100的操作的流程图。
参照图15，在开始基于TLS的握手之前，第一客户端1110和第二客户端1120可以通过使用各自的证书和关于各自证书的签名信息来执行相互认证操作(S1010)。该相互认证操作可以包括根据使用在第一客户端1110和第二客户端1120之间共享的认证密钥Key_Auth的对称密钥方法的认证消息验证协议的操作。将参照17A至图17D对使用认证密钥Key_Auth的对称密钥方法进行描述。
当第一客户端1110与第二客户端1120之间的相互认证操作正常完成时，第二客户端1120和服务器1140可以开始基于TLS的握手(S1020)。换句话说，第二客户端1120和服务器1140可以基于TLS协议栈的握手协议来开始握手。
第二客户端1120可以向服务器1140发送针对第一客户端1110的注册请求，以便开始TLS连接的握手(S1030)。第一客户端1110的注册可以指示第二客户端1120在服务器1140中注册第一客户端1110以使得第一客户端1110能够获得对服务器1140的访问。
服务器1140可以响应于从第二客户端1120接收到的针对第一客户端1110的注册请求，而将PIN信息发送到第二客户端1120(S1040)。如参照图16所描述的，服务器1140可以在将PIN信息发送到第二客户端1120之前验证第一客户端1110是否可信。
第二客户端1120可以将从服务器1140接收到的PIN信息发送给第一客户端1110(S1045)。
另外，第二客户端1120可以在从服务器1140接收到PIN信息时将PIN认证结果信息请求发送到服务器1140(S1050)。PIN认证结果信息可以是指示PIN信息是否已被正确输入到服务器1140的PIN输入状态信息。例如，当第一客户端1110从第二客户端1120接收到PIN信息时，第一客户端1110可以经由显示设备(包括第一客户端1110中所包括的视觉显示设备和听觉显示设备中的至少一个)将PIN信息提供给用户。用户可以将经由显示设备获得的PIN信息输入到服务器1140。第二客户端1120可以将PIN认证结果信息请求发送到服务器1140以验证PIN信息是否已被正确输入。
PIN信息可以由用户输入到服务器140(S1055)。当服务器140确定输入了正确的PIN信息时，服务器1140可以向第二客户端1120发送指示已经输入了正确的PIN信息的PIN认证结果信息(PIN输入状态信息)(S1060)。第二客户端1120可以通过接收指示已经输入了正确的PIN信息的PIN认证结果信息来验证已经输入了正确的PIN信息。
第二客户端1120可以响应于接收到PIN认证结果信息而将注册完成信号发送到服务器1140(S1070)。在从第二客户端1120接收到注册完成信号时，服务器1140可以向第二客户端1120发送包括第一客户端1110访问服务器1140的权限的访问令牌(S1080)。第二客户端1120可以将接收到的访问令牌发送到第一客户端1110(S1085)。之后，第一客户端1110可以通过使用访问令牌访问服务器1140。
然后，第二客户端1120和服务器1140可以完成基于TLS的握手(S1090)。
根据一些示例实施例，根据使用基于加密安全协议的通信的第一客户端1110的服务器注册方法，与传统的客户端-服务器计算系统相比，在握手间隔中不能直接连接到服务器1140的第一客户端1110可以经由第二客户端1120安全注册在服务器1140中。
图16是用于解释根据一些示例实施例的执行第一客户端1110的服务器注册的第一客户端和第二客户端-服务器计算系统1100的操作的流程图。
参照图16，第一客户端1110可以向第二客户端1120发送代表第一客户端1110向服务器1140注册的请求，以及对第二客户端1120的证书和证书签名信息的请求(S1011)。第二客户端1120也可以向第一客户端1110发送对第一客户端1110的证书和证书签名信息的请求以认证第一客户端1110(S1012)。
第二客户端1120可以响应于从第一客户端1110接收到的对证书和证书签名信息的请求，而将第二客户端1120的证书和证书签名信息发送给第一客户端1110(S1013)。第二客户端1120可以通过使用其私钥对其证书中所包括的认证属性进行加密来生成证书签名信息。
第一客户端1110可以响应于从第二客户端1120接收到的对证书和证书签名信息的请求，而将第一客户端1110的证书和证书签名信息发送给第二客户端1120(S1014)。第一客户端1110可以通过使用其私钥来对关于其证书中所包括的认证属性的信息进行加密来生成证书签名信息。另外，第一客户端1110可以将其生成的证书签名信息连同通过使用第一客户端1110的证书和证书签名信息并根据对称密钥方法的认证消息生成协议生成的认证消息一起发送给第二客户端1120。
第一客户端1110可以通过使用第二客户端1120的证书和证书签名信息来认证第二客户端1120(S1015)。例如，第一客户端1110可以通过使用第二客户端1120的公钥来对证书签名信息进行解密，并且通过将解密后的第二客户端1120的证书签名信息与关于第二客户端1120的证书的认证属性的信息进行比较来验证第二客户端1120的证书。当第二客户端1120的证书已被验证时，第一客户端1110可以确定第二客户端1120已被验证。
第二客户端1120可以通过使用第一客户端1110的证书和证书签名信息来认证第一客户端1110。例如，第二客户端1120可以通过使用采用认证密钥的对称密钥方法的认证消息验证协议来验证与认证消息一起被接收的第一客户端1110的证书和证书签名信息。此后，第二客户端1120可以通过使用包括在第一客户端1110的证书中的第一客户端1110的公钥来对证书签名信息进行解密，并且可以通过将解密后的第一客户端1110的证书签名信息与关于第一客户端1110的证书的认证属性的信息进行比较来验证第一客户端1110的证书。当认证消息和第一客户端1110的证书都被验证时，第二客户端1120可以确定第一客户端1110已经被验证。
此后，第一客户端1110和第二客户端1120均可以发送指示完成第一客户端1110与第二客户端1120之间的相互认证操作的认证完成消息(S1017)。
当第一客户端1110与第二客户端1120之间的相互认证操作正常完成时，第二客户端1120和服务器1140可以开始基于TLS的握手(S1020)。换句话说，第二客户端1120和服务器1140可以基于TLS协议栈的握手协议来开始握手。
第二客户端1120可以向服务器1140发送针对第一客户端1110的注册请求以及第一客户端1110的证书和证书签名信息以开始TLS连接的握手(S1030)。
服务器1140可以通过使用第一客户端1110的证书和证书签名信息来验证第一客户端1110是否可信(S1035)。例如，服务器1140可以通过使用已经颁发了第一客户端1110的证书的证书颁发机构的公钥来对第一客户端1110的证书签名信息进行解密，并且可以通过将解密后的第一客户端1110的证书签名信息与关于第一客户端1110的证书的认证属性的信息进行比较来验证第一客户端1110的证书。当第一客户端1110的证书被验证时，服务器1140可以确定第一客户端1110可信。
服务器1140可以将PIN信息连同PIN信息有效期一起发送到第二客户端1120。服务器1140还可以将随机数据发送到第二客户端1120，以进一步提高安全性。
第二客户端1120可以向第一客户端1110发送从服务器1140接收到的PIN信息以及PIN信息有效期和随机数据(S1045)。
另外，第二客户端1120可以在从服务器1140接收到PIN信息时和/或在向第一客户端1110发送PIN信息、PIN信息有效期和随机数据时，向服务器1140发送PIN认证结果信息请求(S1050)。PIN认证结果信息可以是指示在PIN信息有效期限内PIN信息是否已被正确输入到服务器1140的PIN输入状态信息。
PIN信息可以由用户输入到服务器1140(S1055)。当服务器1140确定在PIN信息有效期内输入了正确的PIN信息时，服务器1140可以向第二客户端1120发送指示已经输入了正确的PIN信息的PIN认证结果信息(PIN输入状态信息)(S1060)。第二客户端1120可以通过接收指示已经输入了正确的PIN信息的PIN认证结果信息来验证已经输入了正确的PIN信息。
第二客户端1120可以响应于接收到PIN认证结果信息而将注册完成信号发送到服务器1140(S1070)。在接收到来自第二客户端1120的注册完成信号时，服务器1140可以向第二客户端1120发送包括第一客户端1110访问服务器1140的权限的访问令牌以及用于标识第一客户端1110唯一标识符(Unique ID)(S1080)。第二客户端1120可以将接收到的访问令牌和唯一标识符(Unique ID)发送给第一客户端1110(S1085)。之后，第一客户端1110可以通过使用访问令牌和唯一标识符(Unique ID)来访问服务器1140。
然后，第二客户端1120和服务器1140可以完成基于TLS的握手(S1090)。
根据一些示例实施例，根据使用基于加密安全协议的通信的第一客户端1110的服务器注册方法，与传统的客户端-服务器计算系统相比，在握手间隔中不可直接连接到服务器1140的第一客户端1110可以经由第二客户端1120安全注册在服务器1140中。
图17A示出了根据一些示例实施例的用于解释使用认证密钥的对称密钥方法的网络认证系统1300。
参照17A，网络认证系统1300可以包括第一客户端1110、第二客户端1120和密钥管理系统(KMS)1320。第二客户端1120可以被称为集线器设备，第一客户端1110可以被称为端节点设备。然而，这仅仅是为了便于描述的非限制性示例，并且网络认证系统1300可以包括多个端节点设备(客户端)。
KMS 1320可以生成第一客户端1110的“佐料”(salt)、设备标识DEVICE ID，标识符IDENTIFIER和秘密密钥SECRET KEY。另外，KMS 1320可以通过使用“佐料”、设备标识DEVICEID、标识符IDENTIFIER和秘密密钥SECRET KEY，生成第一客户端1110的认证密钥KEY_AUTH。认证密钥KEY_AUTH的生成可以根据图17B所示的认证密钥生成协议来执行。“佐料”可以是具有由KMS 1320任意生成的特定位数的数据。KMS 1320可以将标识符IDENTIFIER和秘密密钥SECRET KEY发送给第二客户端1120，并且可以将“佐料”、设备标识DEVICE ID和秘密密钥SECRET KEY发送给第一客户端1110。因此，在一些示例实施例中，认证密钥KEY_AUTH可以预先存储在第一客户端1110中。
第二客户端1120可以包括可信执行环境(TEE)1122。例如，TEE 1122是可以驻留在第二客户端1120的应用处理器(未示出)中的安全区域。TEE 1122是与构成各种应用的信任基础并提供与设备完整性、密钥管理、加密操作、认证、授权、访问控制和隐私保护相关的功能的专用软件相结合的硬件体系结构。TEE 1122通过硬件与第二客户端1120的主操作系统(OS)分开，并确保敏感数据和可信应用的安全存储和处理。例如，TEE 1122可以保护密钥资源的完整性和机密性，并且管理和执行可信应用。在TEE 1122中运行的可信应用可以访问主处理器(CPU)和内存(未显示)，而硬件隔离则可以保护这些可信应用免受在主OS中运行的其他应用(例如不可信应用、用户安装的应用)的影响。TEE 1122内部的软件和加密隔离保护所包含的可信应用免受彼此的影响。
TEE 1122可以包括不可能从外部访问第二客户端1120的安全区域。第二客户端1120可以将与安全相关的信息存储在TEE 1122中。例如，TEE 1122可以存储从KMS 1320接收的标识符IDENTIFIER和秘密密钥SECRET KEY。由于不能从外部访问TEE 1122，所以诸如恶意软件的外部入侵者无法访问标识符IDENTIFIER和秘密密钥SECRET KEY。
第一客户端1110可以诸如以如下方式包括安全元件(SE)1112：嵌入式防篡改安全芯片、安全集成电路(IC)、专用集成电路(ASIC)、硬件安全模块(HSM)等的形式。SE 1112的专用软件支持诸如个人验证、设备验证、安全密钥和敏感数据存储、加密操作、编码和解码等的各种任务，并允许例如在设备、服务器和云之间安全地传输密钥和验证信息。SE 1112可以存储从KMS 1320接收到的认证密钥KEY_AUTH。由于SE 1112是第一客户端1110中具有增强的安全性的区域，因此不能从外部访问认证密钥KEY_AUTH。根据一些示例实施例，第一客户端1110可以将设备标识DEVICE ID和“佐料”与认证密钥KEY_AUTH分开存储(例如，存储在与SE 1112分离的存储器中)。
第一客户端1110可以向第二客户端1120发送验证标识VERIFY ID，并且可以向第二客户端1120发送用于认证第一客户端1110的认证消息AUTH MESSAGE。第一客户端1110可以通过使用设备标识DEVICE ID、“佐料”、认证密钥KEY_AUTH和验证标识VERIFY ID，生成认证消息AUTH MESSAGE。第一客户端1110生成认证消息AUTH MESSAGE的操作可以根据参照图17C描述的认证消息生成协议来执行。
第二客户端1120可以接收用于认证第一客户端111的认证消息AUTH MESSAGE。第二客户端1120可以通过使用先前接收的验证标识VERIFY ID和认证消息AUTH MESSAGE来认证第一客户端1110。第一客户端1110的认证可以根据参照图17D描述的认证消息验证协议来执行。
图17B图示了根据一些示例实施例的用于解释使用认证密钥KEY_AUTH的对称密钥方法的认证密钥KEY_AUTH生成协议。
认证密钥KEY_AUTH的生成可以由图17A中的第二客户端1120和KMS1320执行。在下文中，为了便于描述，假设图17B中的认证密钥生成协议由第二客户端1120执行。KMS 1320生成认证密钥KEY_AUTH的过程也可以理解为与下面描述的生成认证密钥KEY_AUTH的过程相同。
参照图17B，第二客户端1120可以通过使用散列函数HASH由标识符IDENTIFIER生成iHASH。第二客户端1120可以通过使用第一标签TAG1、iHASH和“佐料”SALT来生成第一数据块DB1。第二客户端1120可以通过使用第二标签TAG2和“佐料”SALT生成第二数据块DB2，并且通过使用散列函数HASH从第一数据块DB1生成散列数据块HD。第一标签TAG1和第二标签TAG2可以包括具有特定位数的任意数据。第二客户端1120可以通过使用XOR操作来从第二数据块DB2和散列数据块HD生成掩码数据块Masked DB。第二客户端1120可以通过使用加密操作ENC，从包括掩码数据块Masked DB、散列数据块HD和设备标识DEVICE ID的消息中生成认证密钥KEY_AUTH。加密操作ENC可以通过使用存储在第二客户端1120的TEE 1122中的秘密密钥SECRET KEY来执行。
因此，图17A中的第二客户端1120通过使用从第一客户端1110接收到的认证消息AUTH MESSAGE中所包括的“佐料”SALT和设备标识DEVICE ID以及所存储的标识符IDENTIFIER和秘密密钥SECRET KEY，来生成认证密钥KEY_AUTH。KMS 1320也可以通过使用“佐料”SALT、设备标识DEVICE ID、标识符IDENTIFIER和秘密密钥SECRET KEY来生成认证密钥KEY_AUTH。关于图17B所示的生成认证密钥KEY_AUTH的方法，通过使用各种数据来配置数据块的方法不限于图17B所示的顺序，配置数据块中的数据的顺序可以根据一些其他示例实施例而改变。
图17C图示了根据一些示例实施例的用于使用认证密钥KEY_AUTH解释对称密钥方法的认证消息AUTH MESSAGE生成协议。
生成认证消息AUTH MESSAGE可以由图17A中的第一客户端1110执行。
参照图17C，第一客户端1110可以预先从KMS 1320接收认证密钥KEY_AUTH，并将接收到的认证密钥KEY_AUTH存储在第一客户端1110的SE 1112(例如，安全芯片)中。认证密钥KEY_AUTH可以包括加密密钥KEY_ENC和消息认证码(MAC)密钥KEY_MAC。第一客户端1110可以基于验证标识VERIFY ID、时间戳TIME STAMP和验证信息VFY_INFO，通过使用加密密钥KEY_ENC来执行对称密钥方法的加密操作ENC以生成加密消息ENC MESSAGE。验证信息VFY_INFO可以包括要用于第一客户端1110的验证的各种验证信息。第一客户端1110可以基于“佐料”SALT、设备标识DEVICE ID和加密消息ENC MESSAGE，通过使用MAC密钥KEY_MAC来执行散列操作HASH，从而生成散列MAC(HMAC)。第一客户端1110可以通过使用“佐料”SALT、设备标识DEVICE ID、加密消息ENC MESSAGE和散列MAC(HMAC)来生成认证消息AUTH MESSAGE。
因此，图17A中的第一客户端1110可以通过使用“佐料”SALT、设备标识DEVICE ID、认证密钥KEY_AUTH和验证信息VFY_INFO来生成认证消息AUTH MESSAGE。关于图17C所示的生成认证消息AUTH MESSAGE的方法，通过使用各种数据来配置数据块的方法不限于图17C所示的顺序，并且配置数据块中的数据的顺序可以根据一些其它示例实施例而改变。
图17D图示了根据一些示例实施例的用于解释使用认证密钥KEY_AUTH的对称密钥方法的认证消息验证协议。
认证消息AUTH MESSAGE的验证可以由图17A中的第二客户端1120执行。为了便于描述，图17D中的阴影数据块可以表示接收到的数据，未着色的数据块可以表示内部生成的数据。
参照图17D，第二客户端1120可以通过使用接收到的认证消息AUTH MESSAGE中所包括的“佐料”SALT和设备标识DEVICE ID并根据图17B中的认证密钥KEY_AUTH生成协议，生成认证密钥KEY_AUTH。认证密钥KEY_AUTH可以包括加密密钥KEY_ENC和MAC密钥KEY_MAC。
第二客户端1120可以通过使用加密密钥KEY_ENC和对称密钥方法的解密操作DEC来对包括在接收到的认证消息AUTH MESSAGE中的加密消息ENC MESSAGE进行解密，从而获取验证标识VERIFY ID、时间戳TIME STAMP以及验证信息VFY_INFO。第二客户端1120可以将获取到的信息与单独接收到的验证标识VERIFY ID、时间戳TIME STAMP和验证信息VFY_INFO进行比较，从而对这些信息执行验证操作。
第二客户端1120可以通过使用MAC密钥KEY_MAC来对包括在所接收的认证消息AUTH MESSAGE中的“佐料”SALT、设备标识DEVICE ID和加密消息ENC MESSAGE执行散列操作HASH，从而生成散列MAC(HMAC)。第二客户端1120可以通过将所生成的散列MAC(HMAC)与接收到的散列MAC(HMAC)进行比较来对散列MAC(HMAC)执行验证操作。
当验证标识VERIFY ID、时间戳TIME STAMP、验证信息VFY_INFO和散列MAC(HMAC)都被第二客户端1120验证时，认证操作已正常完成。
第二客户端1120使用的认证消息验证协议可以用于执行第一客户端1110的设备认证，也可以用于对从第一客户端1110接收到的验证信息进行完整性验证操作。如上所述，第二客户端1120根据认证消息验证协议对第一客户端1110的验证信息进行完整性验证操作可以被称为客户端间的完整性验证操作。
根据参照图17A至图17D公开的使用认证密钥KEY_AUTH的对称密钥方法，第一客户端1110和第二客户端1120可以在不直接共享对称密钥的情况下间接地共享认证密钥KEY_AUTH，并且根据对称密钥方法的解密操作可以仅利用少量资源执行设备认证和/或完整性验证操作，这是因为对称密钥方法的解密操作需要比其他解密操作更少的计算量(例如，与非对称密钥方法的解密操作相比)。另外，因为用作对称密钥的认证密钥KEY_AUTH在设备之间间接共享而不直接共享，所以与传统的客户端-服务器计算系统相比，可以减少或防止对称密钥暴露给外部攻击者的风险。
图18是根据一些示例实施例的用于解释执行第一客户端1110的完整性验证的第一客户端和第二客户端-服务器计算系统1100的操作的流程图。
参照图18，第二客户端1120和服务器1140可以开始基于TLS的握手(S1100)。换句话说，第二客户端1120和服务器1140可以基于TLS协议栈的握手协议来开始握手。
第二客户端1120可以代表第一客户端1110请求服务器1140执行第一客户端1110的第一完整性验证(S1110)。响应于第一完整性验证请求，服务器1140可以向第二客户端1120请求用于第一完整性验证的第一验证信息(S1120)。
第二客户端1120可以响应于从服务器1140接收到的对第一验证信息的请求，而向第一客户端1110发送第一验证信息的请求(S1130)。
第一客户端1110可以响应于从第二客户端1120接收到的对第一验证信息的请求，而向第二客户端1120发送第一验证信息(S1140)。第一验证信息可以包括第一客户端1110的软件配置信息以及由第一客户端1110生成的软件配置签名信息。另外，第一客户端1110可以将根据使用第一验证信息和认证密钥KEY_AUTH的对称密钥方法的认证消息生成协议生成的认证消息AUTH MESSAGE连同第一验证信息一起发送给第二客户端1120。
第二客户端1120可以通过使用第一验证信息来执行完整性验证(S1150)。例如，第二客户端1120可以通过应用认证密钥KEY_AUTH并且通过使用接收到的第一验证信息和与第一验证信息一起接收的认证消息AUTH MESSAGE，根据对称密钥方法的认证消息验证协议来执行完整性验证操作。
第二客户端1120可以向服务器1140发送第一客户端1110的第一验证信息，第一客户端1110的完整性已经由第二客户端1120验证(S1160)。
服务器1140可以通过使用从第二客户端1120接收的第一验证信息来执行第一客户端1110的第一完整性验证(S1170)。之后，第二客户端1120和服务器1140可以完成基于TLS的握手(S1180)。
图19A是根据一些示例实施例的用于解释当证书30包括软件配置信息SW_CI(如图7B所示)时用于第一客户端1210的第一完整性验证操作的流程图。图19B是根据一些示例实施例的用于解释当软件配置信息SW_CI被存储在安全存储区域368中(如图7C所示)时用于第一客户端1210的第一完整性验证操作的流程图。
参照图19A，第二客户端1220可以向服务器1240发送包括用于第一客户端1210的第一完整性验证请求的第一消息，以开始TLS连接的握手(S1210)。
服务器1240可以向第二客户端1220发送包括对用于第一完整性验证的第一客户端1210的客户端证书和软件配置签名信息的请求的第二消息(S1220)。
响应于来自服务器1240的请求，第二客户端1220可以向第一客户端1210发送包括对第一客户端1210的客户端证书和软件配置签名信息的请求的第三消息(S1230)。
响应于来自第二客户端1220的请求，第一客户端1210可以生成软件配置签名信息(S1240)。例如，第一客户端1210可以在第一客户端1210的安全执行环境中(例如，以安全芯片的形式的安全元件内)生成软件配置签名信息。
第一客户端1210可以向第二客户端1220发送第一客户端1210的证书和软件配置签名信息(S1250)。另外，第一客户端1210可以将根据使用认证密钥KEY_AUTH的对称密钥方法的认证消息生成协议以及第一客户端1210的证书和软件配置签名信息生成的认证消息AUTH MESSAGE，连同证书和软件配置签名信息一起，发送给第二客户端1220。
第二客户端1220可以通过使用第一客户端1210的客户端证书和软件配置签名信息来执行完整性验证(S1260)。例如，第二客户端1220可以根据使用认证密钥KEY_AUTH的对称密钥方法的认证消息验证协议和接收到的认证消息AUTH MESSAGE，以及接收到的客户端证书和软件配置签名信息，来执行完整性验证操作。
第二客户端1220可以向服务器1240发送已经由第二客户端1220验证了完整性的第一客户端1210的客户端证书和软件配置签名信息(S1270)。
服务器1240可以通过使用第一客户端1210的客户端证书和软件配置签名信息来执行第一客户端1210的第一完整性验证(S1280)。
参照图19B，第二客户端1220可以向服务器1240发送包括用于第一客户端1210的第一完整性验证请求的第一消息，以开始TLS连接的握手(S1210)。
服务器1240可以向第二客户端1220发送包括对用于第一完整性验证的第一客户端1210的软件配置信息和软件配置签名信息的请求的第二消息(S1222)。
响应于来自服务器1240的请求，第二客户端1220可以向第一客户端1210发送包括对第一客户端1210的软件配置信息和软件配置签名信息的请求的第三消息(S1232)。
响应于来自第二客户端1220的请求，第一客户端1210可以生成软件配置签名信息(S1240)。例如，第一客户端1210可以在第一客户端1210的安全执行环境中(例如，以安全芯片的形式的安全元件内)生成软件配置签名信息。
第一客户端1210可以读取其软件配置签名信息和存储在其安全存储区域中的软件配置信息，并且可以将它们发送到第二客户端1220(S1252)。另外，第一客户端1210可以将第一客户端1210的软件配置信息和软件配置签名信息，连同根据使用认证密钥KEY_AUTH的对称密钥方法的认证消息生成协议并通过使用第一客户端1210的软件配置信息和软件配置签名信息而生成的认证消息AUTH MESSAGE一起发送到第二客户端1220。
第二客户端1220可以通过使用第一客户端1210的软件配置信息和软件配置签名信息来执行完整性验证(S1262)。例如，第二客户端1220可以根据使用认证密钥KEY_AUTH的对称密钥方法的认证消息验证协议和接收到的认证消息AUTH MESSAGE以及接收到的软件配置信息和软件配置签名信息，来执行完整性验证操作。
第二客户端1220可以向服务器1240发送已经由第二客户端1220验证了完整性的第一客户端1210的软件配置信息和软件配置签名信息(S1272)。
服务器1240可以通过使用从第二客户端1220接收的第一客户端1210的软件配置信息和软件配置签名信息来执行第一客户端1210的第一完整性验证(S1282)。
第一客户端1210可以通过读取存储在安全存储区域中的软件配置信息来验证在将软件配置信息发送到第二客户端1220之前，存储在安全存储区域中的软件配置信息是否已经被篡改。在一些示例实施例中，当第一客户端1210将软件配置信息存储在安全存储区域中时，第一客户端1210还可以将安全签名信息存储在安全存储区域中。安全签名信息可以是软件配置信息用特定密钥加密后的信息，并且可以指示验证存储在安全存储区域中的软件配置信息是否已经被篡改所必需的信息。第一客户端1210可以读取存储在安全存储区域中的软件配置信息和安全签名信息，对安全签名信息进行解密，并且通过将解密后的安全签名信息与读取到的软件配置信息进行比较来验证软件配置信息是否已经被篡改。第一客户端1210可以仅向第二客户端1220发送已经验证了完整性的软件配置信息(未被伪造和/或篡改)。
图20是用于解释根据一些示例实施例的在第一客户端1410、第二客户端1420和服务器1440之间的握手间隔中的验证操作的流程图。
图20主要描述其中的验证操作与图12的验证操作之间的不同之处。
第二客户端1420和服务器1440可以基于图1B的握手协议PT1执行以下握手，以进行用于安全数据通信的会话连接。
参照图20，第二客户端1420可以向服务器1440发送客户端问候消息以开始基于TLS的握手(S1400)。操作S1400可以与图12的操作S400基本相同。
第二客户端1420可以向服务器1440发送针对第一客户端1410的包括第一客户端1410的软件配置类型信息的第一完整性验证请求(S1402)。除了第二客户端1420代表第一客户端1410向服务器1440发送第一完整性验证请求之外，操作S1402可以与图12中的操作S402基本相同。
服务器1440可以响应于客户端问候消息而向第二客户端1420发送服务器问候消息(S1410)。操作S1410可以与图12的操作S410基本相同。
服务器1440可以响应于来自第二客户端1420的客户端问候消息和/或针对第一客户端1410的第一完整性验证请求，而向第二客户端1420发送针对第一客户端1410的客户端证书和第一客户端1410的软件配置签名信息的请求(S1412)。除了服务器1440请求第二客户端1420代表第一客户端1410发送第一客户端1410的客户端证书和第一客户端1410的软件配置签名信息之外，操作S1412可以与图12中的操作S412基本相同。
服务器1440可以向第二客户端1420发送包括服务器1440的软件配置类型信息的第二完整性验证请求(S1414)。操作S1414可以与图12的操作S414基本相同。
服务器1440可以向第二客户端1420发送服务器1440的服务器证书和软件配置签名信息，使得第二客户端1420执行第二完整性验证和/或服务器1440的服务器证书的验证(S1416)。操作S1416可以与图12的操作S416基本相同。
之后，服务器1440可以向第二客户端1420发送服务器问候完成消息，该消息指示响应于客户端问候消息的消息传输已经完成(S1420)。操作S1420可以与图12的操作S420基本相同。
响应于第二完整性验证请求(S1414)，第二客户端1420可以通过使用从服务器1440接收的服务器1440的服务器证书和软件配置签名信息来执行第二完整性验证(S1430)。操作S1430可以与图12的操作S430基本相同。
另外，当第二客户端1420从服务器1440接收到服务器证书时，第二客户端1420可以执行服务器1440的服务器证书的验证(S1432)。操作S1432可以与图12的操作S432基本相同。
第二客户端1420可以向第一客户端1410发送对第一客户端1410的客户端证书的请求(S1440)。在一些情况下，第二客户端1420可以预先存储第一客户端1410的客户端证书，使得操作S1440可以是根据一些示例实施例的可选操作。
另外，第二客户端1420可以向第一客户端1410发送对第一客户端1410的软件配置签名信息的请求(S1442)。
响应于对软件配置签名信息的请求(S1442)，第一客户端1410可以生成第一客户端1410的软件配置签名信息(S1450)。
第一客户端1410可以向第二客户端1420发送第一客户端1410的客户端证书(S1460)。在一些情况下，第二客户端1420可以预先存储第一客户端1410的客户端证书，使得操作S1440可以是根据一些示例实施例的可选操作。
第一客户端1410可以向第二客户端1420发送所生成的第一客户端1410的软件配置签名信息(S1462)。另外，第一客户端1410可以将第一客户端1410的客户端证书和/或软件配置签名信息连同根据使用认证密钥AUTH_KEY的对称密钥方法的认证消息生成协议而生成的认证消息AUTH MESSAGE一起发送给第二客户端1420。
第二客户端1420可以通过使用从第一客户端1410接收到的第一客户端1410的客户端证书和软件配置签名信息来执行完整性验证(S1470)。例如，第二客户端1420可以根据使用认证密钥KEY_AUTH的对称密钥方法的认证消息验证协议，通过使用接收到的认证消息AUTH MESSAGE以及接收到的第一客户端1410的客户端证书和软件配置签名信息，执行完整性验证操作。
第二客户端1420可以向服务器1440发送已经由第二客户端1420验证了完整性的第一客户端1410的客户端证书和第一客户端1410的软件配置签名信息(S1480)。除了第二客户端1420代表第一客户端1410向服务器1440发送第一客户端1410的客户端证书和第一客户端1410的软件配置签名信息之外，操作S1480可以与图4中的操作S450基本相同。
之后，第二客户端1420可以向服务器1440发送指示用于握手的消息传输已经完成的客户端完成消息(S1482)。操作S1482可以与图12中的操作S454基本相同。
响应于对第一客户端1410的第一完整性验证的请求(S1402)，服务器1440可以通过使用从第二客户端1420接收的第一客户端1410的客户端证书和第一客户端1410的软件配置签名信息来执行第一完整性验证(S1490)。操作S1490可以与图12的操作S460基本相同。
另外，当服务器1440从第二客户端1420接收到第一客户端1410的客户端证书时，服务器1440可以执行第一客户端1410的客户端证书的验证(S1492)。操作S1492可以与图12中的操作S462基本相同。
之后，服务器1440可以向第二客户端1420发送指示完成了用于握手的消息传输的服务器完成消息(S1495)。操作S1495可以与图12的操作S472基本相同。
图21是应用了一些示例实施例的物联网(IoT)网络系统2000的示例的概念图。
参照图21，IoT网络系统2000可以包括多个IoT设备2100、2120、2140和2160、接入点2200、网关2250、无线网络2300和服务器2400。IoT可以表示使用有线或无线通信的物体之间的网络。
IoT设备2100、2120、2140和2160可以根据IoT设备的特性来分组。例如，IoT设备可以被分组成家庭小配件组2100、家用电器/家具组2120、娱乐组2140、车辆组2160等。IoT设备2100、2120和2140可以通过接入点(或集线器设备)2200连接到通信网络或其他IoT设备。例如，接入点2200可以嵌入到单个IoT设备中。网关2250可以改变协议以将接入点2200连接到外部无线网络。IoT设备2100、2120和2140可以通过网关2250连接到外部通信网络。无线网络2300可以包括互联网和/或公共网络。IoT设备2100、2120、2140和2160可以连接到通过无线网络2300提供预定(或期望)服务的服务器2400，并且用户可以通过IoT设备2100、2120、2140和2160中的至少一个来使用服务。
IoT设备2100、2120和2140可以执行与接入点2200的基于加密安全协议的通信。根据一些示例实施例，IoT设备2100、2120和2140可以执行IoT设备2100、2120和2140与接入点2200之间的握手，以用于进行与接入点2200的基于TLS的数据通信的目的。根据本发明构思的一些示例实施例，IoT设备2100、2120和2140和/或接入点2200的完整性可以在IoT设备2100、2120和2140与接入点2200之间的握手间隔中进行验证。对于与接入点2200的基于加密安全协议的通信，IoT设备2100、2120和2140与接入点2200之间的会话可以根据完整性验证的结果来进行连接。而且，一些IoT设备2160(例如车辆)可以与服务器2400执行基于TLS的通信。在这种情况下，IoT设备2160和/或服务器2400的完整性可以在IoT设备2160与服务器2400之间的握手间隔中进行验证。
根据一个或更多个示例实施例的单元和/或设备可以使用硬件、硬件和软件的组合或者存储软件的存储介质来实现。硬件可以使用诸如但不限于以下处理电路来实现：一个或更多个处理器、一个或更多个中央处理单元(CPU)、一个或更多个控制器、一个或更多个算术逻辑单元(ALU)、一个或更多个数字信号处理器(DSP)、一个或更多个微计算机、一个或更多个现场可编程门阵列(FPGA)、一个或更多个单片系统(SoC)、一个或更多个可编程逻辑单元(PLU)、一个或更多个微处理器、一个或更多个专用集成电路(ASIC)或能够以定义的方式响应和执行指令的一个或多个任何其他设备。
软件可以包括计算机程序、程序代码、指令或其一些组合，用于独立地或共同地指示或配置硬件设备以按照期望进行操作。计算机程序和/或程序代码可以包括能够由一个或更多个硬件设备(诸如上面提到的硬件设备中的一个或更多个)实施的程序或计算机可读指令、软件组件、软件模块、数据文件、数据结构等。程序代码的示例包括由编译器生成的机器代码和使用解释器执行的更高级程序代码。
例如，当硬件设备是计算机处理设备(例如，一个或更多个处理器、CPU、控制器、ALU、DSP、微型计算机、微处理器等)时，计算机处理设备可以被配置为根据程序代码，通过执行算术、逻辑和输入/输出操作，来执行程序代码。一旦程序代码被加载到计算机处理设备中，计算机处理设备可以被编程为执行程序代码，从而将计算机处理设备变换成专用计算机处理设备。在更具体的示例中，当程序代码被加载到处理器中时，处理器被编程为执行程序代码以及执行与其相对应的操作，从而将处理器变换成专用处理器。在另一个示例中，硬件设备可以是被定制成专用处理电路(例如，ASIC)的集成电路。
诸如计算机处理设备之类的硬件设备可以运行操作系统(OS)以及在OS上运行的一个或更多个软件应用。计算机处理设备还可以响应于软件的执行而访问、存储、操作、处理和创建数据。为了简单起见，可以将一个或更多个示例实施例示例为一个计算机处理设备；然而，本领域技术人员将认识到，硬件设备可以包括多个处理元件和多种类型的处理元件。例如，硬件设备可以包括多个处理器或者一个处理器和一个控制器。另外，诸如并行处理器的其他处理配置也是可能的。
软件和/或数据可以被永久地或暂时地包含在任何类型的存储介质中，包括但不限于能够向硬件设备提供指令或数据或被硬件设备解释的任何机器、组件、物理或虚拟装置，或计算机存储介质或设备。该软件也可以分布在网络连接的计算机系统上，以使得软件以分布式方式被存储和执行。具体而言，例如，软件和数据可以由一个或更多个计算机可读记录介质来存储，所述计算机可读记录介质包括如本文所讨论的有形或非暂时性计算机可读存储介质。
根据一个或更多个示例实施例，存储介质还可以包括在单元和/或设备处的一个或更多个存储设备。一个或更多个存储设备可以是诸如随机存取存储器(RAM)、只读存储器(ROM)、永久的大容量存储设备(诸如磁盘驱动器)的有形或非暂时性计算机可读存储介质，和/或能够存储和记录数据的任何其他类似的数据存储机构。一个或更多个存储设备可以被配置为存储用于一个或更多个操作系统和/或用于实现本文所描述的示例实施例的计算机程序、程序代码、指令或其一些组合。计算机程序、程序代码、指令或其一些组合也可以使用驱动机构从单独的计算机可读存储介质加载到一个或更多个存储设备和/或一个或更多个计算机处理设备中。这种单独的计算机可读存储介质可以包括通用串行总线(USB)闪存驱动器、存储棒、蓝光/DVD/CD-ROM驱动器、存储卡和/或其它类似的计算机可读存储介质。计算机程序、程序代码、指令或其一些组合可以经由网络接口从远程数据存储设备而不是经由计算机可读存储介质加载到一个或更多个存储设备和/或一个或更多个计算机处理设备中。另外，计算机程序、程序代码、指令或其一些组合可以从被配置成传输和/或分发计算机程序、程序代码、指令或其一些组合的远程计算系统中加载到一个或更多个存储设备和/或一个或更多个处理器中。远程计算系统可以经由有线接口、空中接口和/或任何其它类似的介质来传输和/或分发计算机程序、程序代码、指令或其一些组合。
一个或更多个硬件设备、存储介质、计算机程序、程序代码、指令或其一些组合可以为了示例实施例的目的而被专门设计和构造，或者它们可以是为了示例实施例的目的而被改变和/或修改的已知设备。
虽然已经参照本发明的一些示例性实施例具体示出和描述了本发明构思，但将理解，可以在不脱离所附权利要求的精神和范围的情况下，对其进行形式和细节上的各种改变。

Claims (18)

1.一种支持客户端与服务器之间的完整性验证的基于加密安全协议的通信方法，所述基于加密安全协议的通信方法包括：
所述服务器从所述客户端接收包括对所述客户端的第一完整性验证的请求的第一消息，以便开始传输层安全连接的握手；
所述服务器向所述客户端发送第二消息，所述第二消息包括对用于所述第一完整性验证的第一验证信息的请求；
所述服务器从所述客户端接收所述第一验证信息，并通过使用所述第一验证信息来执行所述第一完整性验证；以及
基于所述第一完整性验证的结果在所述客户端与所述服务器之间完成握手并执行数据通信。
2.根据权利要求1所述的基于加密安全协议的通信方法，其中，所述第一消息还包括客户端问候消息，所述客户端问候消息包括以下信息中的至少一种：所述客户端的传输层安全协议版本信息、所述客户端的会话唯一标识符字段信息、第一安全随机数据、所述客户端中可支持的加密算法列表以及所述客户端中可支持的压缩方法列表。
3.根据权利要求2所述的基于加密安全协议的通信方法，其中，所述第二消息还包括服务器问候消息，所述服务器问候消息包括以下信息中的至少一种：所述服务器的传输层安全协议版本信息、所述服务器的会话唯一标识符字段信息、第二安全随机数据、从所述加密算法列表中选择的加密算法以及从所述压缩方法列表中选择的压缩方法。
4.根据权利要求1所述的基于加密安全协议的通信方法，其中对所述第一完整性验证的请求包括所述客户端的软件配置类型信息。
5.根据权利要求1所述的基于加密安全协议的通信方法，其中，所述第一验证信息包括客户端证书、所述客户端的软件配置类型信息以及所述客户端的软件配置值，并且
所述客户端的软件配置类型信息和所述客户端的软件配置值存储在所述客户端的安全存储区域中。
6.根据权利要求1所述的基于加密安全协议的通信方法，其中，所述第一验证信息包括客户端证书，并且
所述客户端证书包括第一公钥、所述客户端的软件配置类型信息以及所述客户端的软件配置值。
7.根据权利要求6所述的基于加密安全协议的通信方法，其中，所述第一验证信息还包括所述客户端的软件配置签名信息，
所述客户端响应于对所述第一验证信息的请求，通过使用与所述第一公钥相对应的第一私钥对所述客户端的当前软件配置值进行加密，来生成所述客户端的软件配置签名信息。
8.根据权利要求7所述的基于加密安全协议的通信方法，其中，执行所述第一完整性验证包括：所述服务器将通过使用所述第一公钥对所述客户端的软件配置签名信息进行解密而获得的值与所述客户端的软件配置值进行比较。
9.根据权利要求7所述的基于加密安全协议的通信方法，其中，所述客户端的软件配置值和所述客户端的当前软件配置值是通过使用散列算法生成的散列值。
10.根据权利要求6所述的基于加密安全协议的通信方法，其中，执行所述第一完整性验证还包括：所述服务器执行对所述客户端证书的验证。
11.根据权利要求6所述的基于加密安全协议的通信方法，其中，所述客户端的软件配置类型信息是指示以下类型之一的信息：非配置类型、所述客户端的进程映射类型、所述客户端的安全策略类型、进程映射-安全策略类型和用户定义的类型。
12.根据权利要求6所述的基于加密安全协议的通信方法，其中，所述客户端的软件配置类型信息和所述客户端的软件配置值被包括在所述客户端证书的扩展区域中。
13.根据权利要求1所述的基于加密安全协议的通信方法，其中所述第二消息还包括对所述服务器的第二完整性验证的请求和用于所述第二完整性验证的第二验证信息，并且
所述基于加密安全协议的通信方法还包括：所述客户端通过使用所述第二验证信息来执行所述第二完整性验证。
14.根据权利要求13所述的基于加密安全协议的通信方法，其中，所述第二验证信息包括服务器证书，并且
所述服务器证书包括第二公钥、所述服务器的软件配置类型信息以及所述服务器的软件配置值。
15.根据权利要求14所述的基于加密安全协议的通信方法，其中所述第二验证信息还包括所述服务器的软件配置签名信息，
所述服务器通过使用与所述第二公钥相对应的第二私钥对所述服务器的当前软件配置值进行加密，来生成所述服务器的软件配置签名信息。
16.根据权利要求15所述的基于加密安全协议的通信方法，其中，执行所述第二完整性验证包括：所述客户端将通过使用所述第二公钥对所述服务器的软件配置签名信息进行解密而获得的值与所述服务器的软件配置值进行比较。
17.根据权利要求14所述的基于加密安全协议的通信方法，其中，执行所述第二完整性验证还包括：所述客户端执行对所述服务器证书的验证。
18.根据权利要求1所述的基于加密安全协议的通信方法，其中所述加密安全协议是安全套接层/传输层安全协议。
CN201811070400.4A 2017-09-22 2018-09-13 通信方法、完整性验证方法和客户端的服务器注册方法 Pending CN109547400A (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20170122884 2017-09-22
KR10-2017-0122884 2017-09-22
KR1020180002141A KR20190034048A (ko) 2017-09-22 2018-01-08 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법 및 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트와 서버간 무결성 검증 방법
KR10-2018-0002141 2018-01-08

Publications (1)

Publication Number Publication Date
CN109547400A true CN109547400A (zh) 2019-03-29

Family

ID=65809244

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811070400.4A Pending CN109547400A (zh) 2017-09-22 2018-09-13 通信方法、完整性验证方法和客户端的服务器注册方法

Country Status (2)

Country Link
US (1) US10958664B2 (zh)
CN (1) CN109547400A (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111181940A (zh) * 2019-12-20 2020-05-19 国久大数据有限公司 数据校验方法及数据校验系统
CN111212095A (zh) * 2020-04-20 2020-05-29 国网电子商务有限公司 一种身份信息的认证方法、服务器、客户端及系统
CN111917694A (zh) * 2019-05-09 2020-11-10 中兴通讯股份有限公司 一种tls加密流量识别方法及装置
CN112104604A (zh) * 2020-08-07 2020-12-18 国电南瑞科技股份有限公司 基于电力物联管理平台的安全接入服务实现系统及方法
CN114124434A (zh) * 2021-09-26 2022-03-01 支付宝(杭州)信息技术有限公司 基于tee的网络通信方法、装置及系统
CN114301660A (zh) * 2021-12-27 2022-04-08 西安广和通无线软件有限公司 多服务器认证方法、装置、设备及存储介质
CN114782022A (zh) * 2022-05-11 2022-07-22 保利长大工程有限公司 基于身份认证的施工数字化监测方法、设备及存储介质

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11005971B2 (en) * 2018-08-02 2021-05-11 Paul Swengler System and method for user device authentication or identity validation without passwords or matching tokens
EP3656577A1 (en) * 2018-11-21 2020-05-27 Thales Dis France SA In-the-field patching of an operating system using a digital certificate extension
US11036887B2 (en) * 2018-12-11 2021-06-15 Micron Technology, Inc. Memory data security
US11190521B2 (en) * 2019-01-18 2021-11-30 Vmware, Inc. TLS policy enforcement at a tunnel gateway
US11283781B2 (en) * 2019-04-09 2022-03-22 Visa International Service Association Proximity interaction system including secure encryption scheme
CN113660271B (zh) * 2021-08-17 2022-11-25 安徽江淮汽车集团股份有限公司 一种车联网的安全认证方法及装置
KR102463051B1 (ko) * 2021-11-23 2022-11-03 펜타시큐리티시스템 주식회사 선박 네트워크 접근제어 방법 및 장치
CN114449512A (zh) * 2021-12-30 2022-05-06 武汉中海庭数据技术有限公司 一种车端安全通信方法及装置

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7418484B2 (en) * 2001-11-30 2008-08-26 Oracle International Corporation System and method for actively managing an enterprise of configurable components
KR100674566B1 (ko) 2004-01-29 2007-01-25 중앙대학교 산학협력단 공개키 기반구조를 이용한 원격 서버 관리방법
KR20050078837A (ko) 2004-02-03 2005-08-08 박세현 Pki를 이용한 보안 메신저툴
CN1703004B (zh) * 2005-02-28 2010-08-25 联想(北京)有限公司 一种实现网络接入认证的方法
US7434253B2 (en) 2005-07-14 2008-10-07 Microsoft Corporation User mapping information extension for protocols
KR101082917B1 (ko) 2009-09-14 2011-11-11 고려대학교 산학협력단 원격 컴퓨팅 환경에서 사용자 데이터의 무결성 검증 방법 및 그 시스템
US8856317B2 (en) 2010-07-15 2014-10-07 Cisco Technology, Inc. Secure data transfer in a virtual environment
JP5961638B2 (ja) 2011-02-17 2016-08-02 ターセーラ， インコーポレイテッド アプリケーション証明のためのシステムおよび方法
KR20140098872A (ko) 2013-01-31 2014-08-08 남궁용주 모바일 nfc단말기 웹 서비스를 위한 바이오인식과 tsm 기반의 보안 시스템 및 방법
US9602537B2 (en) 2013-03-15 2017-03-21 Vmware, Inc. Systems and methods for providing secure communication
EP3028210B1 (en) * 2013-08-02 2020-01-08 OLogN Technologies AG Secure server in a system with virtual machines
US10454689B1 (en) * 2015-08-27 2019-10-22 Amazon Technologies, Inc. Digital certificate management
KR101720630B1 (ko) 2015-08-31 2017-03-28 고려대학교 산학협력단 내부 공격에 안전한 id 기반의 양방향 인증 방법
US10462116B1 (en) * 2015-09-15 2019-10-29 Amazon Technologies, Inc. Detection of data exfiltration
KR101746102B1 (ko) 2016-04-28 2017-06-13 주식회사 센스톤 무결성 및 보안성이 강화된 사용자 인증방법
US10270762B2 (en) 2016-04-28 2019-04-23 SSenStone Inc. User authentication method for enhancing integrity and security

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111917694A (zh) * 2019-05-09 2020-11-10 中兴通讯股份有限公司 一种tls加密流量识别方法及装置
CN111181940A (zh) * 2019-12-20 2020-05-19 国久大数据有限公司 数据校验方法及数据校验系统
CN111212095A (zh) * 2020-04-20 2020-05-29 国网电子商务有限公司 一种身份信息的认证方法、服务器、客户端及系统
CN111212095B (zh) * 2020-04-20 2020-07-21 国网电子商务有限公司 一种身份信息的认证方法、服务器、客户端及系统
CN112104604A (zh) * 2020-08-07 2020-12-18 国电南瑞科技股份有限公司 基于电力物联管理平台的安全接入服务实现系统及方法
CN112104604B (zh) * 2020-08-07 2024-03-29 国电南瑞科技股份有限公司 基于电力物联管理平台的安全接入服务实现系统及方法
CN114124434A (zh) * 2021-09-26 2022-03-01 支付宝(杭州)信息技术有限公司 基于tee的网络通信方法、装置及系统
CN114301660A (zh) * 2021-12-27 2022-04-08 西安广和通无线软件有限公司 多服务器认证方法、装置、设备及存储介质
CN114782022A (zh) * 2022-05-11 2022-07-22 保利长大工程有限公司 基于身份认证的施工数字化监测方法、设备及存储介质
CN114782022B (zh) * 2022-05-11 2022-12-06 保利长大工程有限公司 基于身份认证的施工数字化监测方法、设备及存储介质

Also Published As

Publication number Publication date
US10958664B2 (en) 2021-03-23
US20190098016A1 (en) 2019-03-28

Similar Documents

Publication Publication Date Title
CN109547400A (zh) 通信方法、完整性验证方法和客户端的服务器注册方法
US11218323B2 (en) Method and system for producing a secure communication channel for terminals
CN111049660B (zh) 证书分发方法、系统、装置及设备、存储介质
EP3602991B1 (en) Mechanism for achieving mutual identity verification via one-way application-device channels
CN113545006B (zh) 远程授权访问锁定的数据存储设备
US8327143B2 (en) Techniques to provide access point authentication for wireless network
Echeverría et al. Establishing trusted identities in disconnected edge environments
WO2021190197A1 (zh) 生物支付设备的认证方法、装置、计算机设备和存储介质
US20210167963A1 (en) Decentralised Authentication
EP2728908A1 (en) Telecommunications chip card
CN113260992B (zh) 数据存储设备的多设备解锁
CN113556230B (zh) 数据安全传输方法、证书相关方法、服务端、系统及介质
KR20190034048A (ko) 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법 및 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트와 서버간 무결성 검증 방법
CN108809907A (zh) 一种证书请求消息发送方法、接收方法和装置
KR20190129478A (ko) Ssl/tls 기반의 네트워크 보안 장치 및 방법
US12022009B2 (en) Method and device for performing access control by using authentication certificate based on authority information
WO2017050152A1 (zh) 用于移动设备的密码安全系统及其密码安全输入方法
CN114175574A (zh) 无线安全协议
CN110912685B (zh) 建立受保护通信信道
KR102026375B1 (ko) 웨어러블 디바이스 통신 지원 장치 및 방법
CN114374522B (zh) 一种可信设备认证方法、装置、计算机设备及存储介质
Hamed et al. Secure Patient Authentication Scheme in the Healthcare System Using Symmetric Encryption.
US20240187221A1 (en) Agile cryptographic deployment service
KR101848300B1 (ko) IoT 디바이스의 통신 클라이언트의 동작 방법 및 상기 통신 클라이언트를 포함하는 IoT 디바이스
KR101834522B1 (ko) 데이터 확인 장치 및 이를 이용하여 데이터를 확인하는 방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20190329