[go: up one dir, main page]

CN113497779A - 网络密钥交换协议使用证书认证的方法和通信设备 - Google Patents

网络密钥交换协议使用证书认证的方法和通信设备 Download PDF

Info

Publication number
CN113497779A
CN113497779A CN202010192532.5A CN202010192532A CN113497779A CN 113497779 A CN113497779 A CN 113497779A CN 202010192532 A CN202010192532 A CN 202010192532A CN 113497779 A CN113497779 A CN 113497779A
Authority
CN
China
Prior art keywords
certificate
ike
authentication
auth
signature
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
CN202010192532.5A
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202010192532.5A priority Critical patent/CN113497779A/zh
Priority to PCT/CN2021/081054 priority patent/WO2021185240A1/zh
Priority to EP21770833.8A priority patent/EP4109838B1/en
Publication of CN113497779A publication Critical patent/CN113497779A/zh
Priority to US17/946,542 priority patent/US12212662B2/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]

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)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了一种网络密钥交换协议IKE使用证书认证的方法，所述方法包括：第一设备解析证书，获取证书中的签名信息；所述第一设备根据所述证书中的签名信息，填充IKE身份验证AUTH消息中的AUTH负载字段，所述AUTH负载字段指示的签名信息与所述证书中的签名信息相匹配；所述第一设备向第二设备发送所述IKE AUTH消息。本申请提供的IKE使用证书认证的方法中，第一设备可以自动从证书中解析签名信息并根据签名信息填充IKE AUTH消息相关字段，简化了用户配置，提升了产品的易用性。

Description

网络密钥交换协议使用证书认证的方法和通信设备
技术领域
本申请涉及计算机领域，尤其涉及一种网络密钥交换协议使用证书认证的方法和通信设备。
背景技术
在使用网络密钥交换协议第二版(internet key exchange protocol version2，IKEv2)进行证书认证时，IKE消息中携带的签名信息需要用户进行配置。
一方面，用户的配置出错将导致认证无法完成。例如，用户需要配置的公钥算法为基于椭圆曲线的数字签名算法(elliptic curve digital signature algorithm，ECDSA)，但是用户配置成了RSA算法(Rivest–Shamir–Adleman algorithm，RSA)，由于配置错误，认证无法完成。再如，配置ECDSA算法时，由于拼写错误配置成“EDCSA”也将导致认证失败。
另一方面，不同厂商的设备的配置命令是不同的。当涉及对不同厂商的设备进行认证配置时，用户需要学习该厂商的设备的配置命令。例如，需要配置的公钥算法是RSA算法时，不同厂商的配置命令不同，例如：
A厂商设备的配置命令为：
authentication{local{rsa-sig|pre-share|ecdsa-sig}|remote{eap[query-identity]|rsa-sig|pre-share|ecdsa-sig}；
B厂商设备的配置命令为：
authentication-method(dsa-signatures|pre-shared-keys|rsa-signatures)；
C厂商设备的配置命令为：
authby＝pubkey|rsasig|psk|secret|xauthrsasig|xauthpsk|never；
华为的Eudemon设备的配置命令为：
authentication-method{pre-share|rsa-signature|digital-envelope}；
D厂商设备的配置命令为：
authentication-method{pre-share|rsa-sig}。
因此，现有的IKE认证对用户有较高的要求。
发明内容
本申请提供一种网络密钥交换协议(internet key exchange protocol，IKE)使用证书认证的方法和通信设备，第一设备可以自动解析证书，获取证书中的签名信息，并根据该签名信息填充IKE身份验证(authentication，AUTH)消息的相关字段，无需用户配置具体的签名信息。
第一方面，提供了一种IKE使用证书认证方法，该方法包括：第一设备解析证书，获取证书中的签名信息；该第一设备根据所述签名信息，填充IKE身份验证AUTH消息中的AUTH负载字段，该AUTH负载字段指示的签名信息与证书中的签名信息相匹配；第一设备向第二设备发送该IKE AUTH消息。其中，第一设备是认证的发起方，第二设备是认证的响应方，第一设备填充的IKE AUTH消息是IKE_AUTH请求消息。其中，AUTH负载字段指示了该第一设备在认证中支持的签名信息类型，并且AUTH负载字段的填充值与证书中的签名信息存在映射关系。
上述技术方案中，第一设备可以自动解析证书文件、获取证书中的签名信息并根据签名信息自动填充AUTH消息中的AUTH负载字段，无需用户配置AUTH负载字段中具体的签名信息，避免了用户配置错误。
在一种可能的实现方式中，证书中的签名信息包括：公钥算法。
在另一种可能的实现方式中，证书中的签名信息还包括：签名的填充方式、哈希算法和扩展算法中的至少一个。
在另一种可能的实现方式中，证书中的签名信息包括对象标识符，所述对象标识符是对所述证书中的签名信息的编码。
在上述技术方案中，第一设备解析证书后，可以从证书中获取多种形式的签名信息，提高了第一设备获取签名信息的灵活性。
在另一种可能的实现方式中，在第一设备解析证书，获取证书中的签名信息之前，该方法还包括：第一设备获取第一配置信息，该第一配置信息指示认证IKE使用证书认证的方法的类型。
在另一种可能的实现方式中，该IKE使用证书认证的方法的类型为通用的证书签名认证，或者，IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证；并且，在IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证的情况下，该第一配置信息还指示：所述通用的非对称秘钥算法认证的签名信息的来源。
在上述技术方案中，用户仅需要对第一配置信息进行设置，不需要配置具体的IKEAUTH消息中的签名信息，简化了用户配置，避免了配置错误。
在另一种可能的实现方式中，在第一设备根据证书中的签名信息填充IKE AUTH消息中的AUTH负载字段之前，该方法还包括：第一设备确定第一设备和第二设备均支持数字签名；在第一设备和第二设备均支持所述数字签名的情况下，采用数字签名方式填充AUTH负载字段，并且，AUTH负载字段中的算法标识字段的填充值为对象标识符的可辨别编码规则DER编码。
在上述技术方案中，第一设备可以根据证书中的签名信息以及第一设备和第二设备支持的签名填充方式自动地填充IKE AUTH消息中的AUTH负载字段，无需用户进行配置，提高了IKE AUTH消息的准确性，避免了用户的配置错误。
在另一种实现方式中，第一设备确定第一设备和第二设备均支持数字签名包括：第一设备获取第二配置信息，该第二配置信息指示第一设备支持数字签名；第一设备获取第二设备发送的IKE安全关联参数(security association，SA)消息，该IKE SA消息指示所述第二设备支持数字签名。其中，第二设备是认证的响应方，第二设备发送的IKE SA消息是初始协商(IKE_SA_INIT)响应消息。
第二方面，提供了一种IKE使用证书认证的方法，该方法包括：第一设备解析证书，获取证书中的签名信息；该第一设备根据证书中的签名信息，填充IKE身份验证AUTH消息中的AUTH负载字段，该AUTH负载字段指示的签名信息与证书的中的签名信息相匹配；第一设备向第二设备发送该IKE AUTH消息。其中，第一设备是认证的响应方，第二设备是认证的发起方，第一设备填充的IKE AUTH消息是IKE_AUTH响应消息。其中，AUTH负载字段指示了该第一设备在认证中支持的签名信息类型，并且AUTH负载字段的填充值与证书中的签名信息存在映射关系。
上述技术方案中，第一设备可以自动解析证书文件、获取证书中的签名信息并根据签名信息自动填充AUTH消息中的AUTH负载字段，无需用户配置AUTH负载字段中具体的签名信息，避免了用户配置错误。
在一种可能的实现方式中，证书中的签名信息包括：公钥算法。
在另一种可能的实现方式中，证书中的签名信息还包括：签名的填充方式、哈希算法和扩展算法中的至少一个。
在另一种可能的实现方式中，证书中的签名信息包括对象标识符，所述对象标识符是对所述证书中的签名信息的编码。
在上述技术方案中，第一设备解析证书后，可以从证书中获取多种形式的签名信息，提高了第一设备获取签名信息的灵活性。
在另一种可能的实现方式中，在第一设备解析证书，获取证书中的签名信息之前，该方法还包括：第一设备获取第一配置信息，该第一配置信息指示认证IKE使用证书认证的方法的类型。
在另一种可能的实现方式中，该IKE使用证书认证的方法的类型为通用的证书签名认证，或者，IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证；并且，在IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证的情况下，该第一配置信息还指示：所述通用的非对称秘钥算法认证的签名信息的来源。
在上述技术方案中，用户仅需要对第一配置信息进行设置，不需要配置具体的IKEAUTH消息中的签名信息，简化了用户配置，避免了配置错误。
在另一种可能的实现方式中，在第一设备根据证书中的签名信息填充IKE AUTH消息中的AUTH负载字段之前，该方法还包括：第一设备确定第一设备和第二设备均支持数字签名；在第一设备和第二设备均支持所述数字签名的情况下，采用数字签名方式填充AUTH负载字段，并且，AUTH负载字段中的算法标识字段的填充值为对象标识符的可辨别编码规则DER编码。
在上述技术方案中，第一设备可以根据证书中的签名信息以及第一设备和第二设备支持的签名填充方式自动地填充IKE AUTH消息中的AUTH负载字段，无需用户进行配置，提高了IKE AUTH消息的准确性，避免了用户的配置错误。
在另一种实现方式中，第一设备确定第一设备和第二设备均支持数字签名包括：第一设备获取第二配置信息，该第二配置信息指示第一设备支持数字签名；第一设备获取第二设备发送的IKE SA消息，该IKE SA消息指示所述第二设备支持数字签名。其中，第二设备是认证的发起方，第二设备发送的IKE SA消息是IKE_SA_INIT请求消息。
第三方面，提供了一种通信设备，该通信设备包括存储器，存储有程序；与存储器通信的处理器，该处理器运行所述程序，使得该设备执行以下操作：解析证书，获取证书中的签名信息；根据证书中的签名信息，填充IKE AUTH消息中的AUTH负载字段，该AUTH负载字段指示的签名信息与证书的中的签名信息相匹配；向第二设备发送所述IKE AUTH消息。其中，该通信设备是认证的发起方，第二设备是认证的响应方，该通信设备发送的IKE AUTH消息是IKE_AUTH请求消息。其中，AUTH负载字段指示了该第一设备在认证中支持的签名信息类型，并且AUTH负载字段的填充值与证书中的签名信息存在映射关系。
在在一种可能的实现方式中，证书中的签名信息包括：公钥算法。
在另一种可能的实现方式中，证书中的签名信息还包括：签名的填充方式、哈希算法和扩展算法中的至少一个。
在另一种可能的实现方式中，证书中的签名信息包括对象标识符，所述对象标识符是对所述证书中的签名信息的编码。
在上述技术方案中，该通信设备解析证书后，可以从证书中获取多种形式的签名信息，提高了通信设备获取签名信息的灵活性。
在另一种可能的实现方式中，该程序还包括执行以下操作的指令：在通信设备解析证书，获取证书中的签名信息之前，获取第一配置信息，该第一配置信息指示认证IKE使用证书认证的方法的类型。
在另一种可能的实现方式中，该IKE使用证书认证的方法的类型为通用的证书签名认证，或者，IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证；并且，在IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证的情况下，该第一配置信息还指示：所述通用的非对称秘钥算法认证的签名信息的来源。
在上述技术方案中，用户仅需要对第一配置信息进行设置，不需要配置具体的IKEAUTH消息中的签名信息，简化了用户配置，避免了配置错误。
在另一种可能的实现方式中，程序还包括执行以下操作的指令：在根据证书中的签名信息填充IKE AUTH消息中的AUTH负载字段之前，确定通信设备和第二设备均支持数字签名；在通信设备和第二设备均支持所述数字签名的情况下，采用数字签名方式填充AUTH负载字段，并且，AUTH负载字段中的算法标识字段的填充值为对象标识符的可辨别编码规则DER编码。
在上述技术方案中，通信设备可以根据证书中的签名信息以及通信设备和第二设备支持的签名填充方式自动地填充IKE AUTH消息中的AUTH负载字段，无需用户进行配置，提高了IKE AUTH消息的准确性，避免了用户的配置错误。
在另一种实现方式中，通信设备确定该通信设备和第二设备均支持数字签名包括：通信设备获取第二配置信息，该第二配置信息指示通信设备支持数字签名；通信设备获取第二设备发送的IKE SA消息，该IKE SA消息指示所述第二设备支持数字签名。其中，第二设备是认证的响应方，第二设备发送的IKE SA消息是IKE_SA_INIT响应消息。
第四方面，提供了一种通信设备，该通信设备包括存储器，存储有程序；与存储器通信的处理器，该处理器运行所述程序，使得该设备执行以下操作：解析证书，获取证书中的签名信息；根据证书中的签名信息，填充IKE AUTH消息中的AUTH负载字段，该AUTH负载字段指示的签名信息与证书的中的签名信息相同；向第二设备发送所述IKE AUTH消息。其中，该通信设备是认证的响应方，第二设备是认证的发起方，该通信设备发送的IKE AUTH消息是IKE_AUTH响应消息。其中，AUTH负载字段指示了该第一设备在认证中支持的签名信息类型，并且AUTH负载字段的填充值与证书中的签名信息存在映射关系。
在在一种可能的实现方式中，证书中的签名信息包括：公钥算法。
在另一种可能的实现方式中，证书中的签名信息还包括：签名的填充方式、哈希算法和扩展算法中的至少一个。
在另一种可能的实现方式中，证书中的签名信息包括对象标识符，所述对象标识符是对所述证书中的签名信息的编码。
在上述技术方案中，第一设备解析证书后，可以从证书中获取多种形式的签名信息，提高了第一设备获取签名信息的灵活性。
在另一种可能的实现方式中，该程序还包括执行以下操作的指令：在通信设备解析证书，获取证书中的签名信息之前，获取第一配置信息，该第一配置信息指示认证IKE使用证书认证的方法的类型。
在另一种可能的实现方式中，该IKE使用证书认证的方法的类型为通用的证书签名认证，或者，IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证；并且，在IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证的情况下，该第一配置信息还指示：所述通用的非对称秘钥算法认证的签名信息的来源。
在上述技术方案中，用户仅需要对第一配置信息进行设置，不需要配置具体的IKEAUTH消息中的签名信息，简化了用户配置，避免了配置错误。
在另一种可能的实现方式中，程序还包括执行以下操作的指令：在通信设备根据证书中的签名信息填充IKE AUTH消息中的AUTH负载字段之前，通信设备确定通信设备和第二设备均支持数字签名；在通信设备和第二设备均支持所述数字签名的情况下，采用数字签名方式填充AUTH负载字段，并且，AUTH负载字段中的算法标识字段的填充值为对象标识符的可辨别编码规则DER编码。
在上述技术方案中，通信设备可以根据证书中的签名信息以及通信设备和第二设备支持的签名填充方式自动地填充IKE AUTH消息中的AUTH负载字段，无需用户进行配置，提高了IKE AUTH消息的准确性，避免了用户的配置错误。
在另一种实现方式中，通信设备确定通信设备和第二设备均支持数字签名包括：通信设备获取第二配置信息，该第二配置信息指示通信设备支持数字签名；通信设备获取第二设备发送的IKE SA消息，该IKE SA消息指示所述第二设备支持数字签名。其中，第二设备是认证的响应方，第二设备发送的IKE SA消息是IKE_SA_INIT请求消息。
第五方面，提供一种芯片，该芯片包括处理器与数据接口，其中，处理器通过所述数据接口读取存储器上存储的指令，以执行第一方面或第一方面任意一种可能的实现方式中的方法。
第六方面，提供一种芯片，该芯片包括处理器与数据接口，其中，处理器通过所述数据接口读取存储器上存储的指令，以执行第二方面或第二方面任意一种可能的实现方式中的方法。
第七方面，提供了一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得计算机执行上述第一方面或第一方面任意一种可能的实现方式中的方法。
第八方面，提供了一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得计算机执行上述第二方面或第二方面任意一种可能的实现方式中的方法。
第九方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序代码，当该计算机程序代码在计算机上运行时，使得计算机执行上述第一方面或第一方面任意一种可能的实现方式中的方法。
第十方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序代码，当该计算机程序代码在计算机上运行时，使得计算机执行上述第二方面或第二方面任意一种可能的实现方式中的方法。
附图说明
图1是本申请实施例的一种网络场景示意图。
图2是IKEv2认证的消息交互过程示意图。
图3是本申请一实施例的网络密钥交换协议IKE使用证书认证的方法的流程示意图。
图4是本申请实施例一种用户参与IKE认证配置的示意图。
图5是本申请一实施例的AUTH负载字段填充的流程示意图。
图6是本申请另一实施例的IKE使用证书证书认证的方法的流程示意图。
图7是根据本申请实施例提供的通信设备的结构示意图。
图8是根据本申请实施例提供的通信设备的结构示意图。
图9是根据本申请实施例提供的通信设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部实施例。
本申请将围绕可包括多个设备、组件、模块等的系统来呈现各个方面、实施例或特征。应当理解和明白的是，各个系统可以包括另外的设备、组件、模块等，并且/或者可以并不包括结合附图讨论的所有设备、组件、模块等。此外，还可以使用这些方案的组合。
另外，在本申请实施例中，“示例的”、“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用示例的一词旨在以具体方式呈现概念。
本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。
在网络连接中，互联网安全协议(internet protocol security，IPSec)可以提供安全通信通道，通过加密通道保证连接的安全。网络秘钥交换协议(internet keyexchange protocol，IKE)可以协助IPSec进行安全性管理。IKE可以在进行IPSec处理的过程中对设备的身份进行鉴别，同时进行安全策略的协商和会话密钥的交换工作。本申请实施例的身份认证方法可以应用于各种网络场景。支持网络密钥交换协议第二版(internetkey exchange protocol version 2，IKEv2)进行身份认证，并且具有签名计算和验证证书的能力的设备，都可以使用本申请实施例的IKE使用证书认证的方法进行身份验证。
图1是本申请实施例的一种网络场景示意图。如图1所示，基站110通过交换设备120、路由器130、安全网关140接入一个安全网络。IPSec通道150通过加密保证了连接的安全。对于在该IPSec通道上的直接进行通信的两个设备，只要这两个设备支持IKEv2协议，并且具有签名计算和验证证书的能力，就可以使用本申请实施例提供的方法进行身份认证。
例如，基站110、交换设备120、路由器130都支持IKEv2协议并且具有签名计算和验证证书的能力。在这种情况下，基站110与交换设备120进行通信连接时，可以通过本申请实施例的IKE使用证书认证的方法进行安全性管理；交换设备120与路由器130进行通信连接时，也可以通过本申请实施例的IKE使用证书认证的方法进行安全性管理。
图2是IKEv2认证的消息交互过程示意图。如图2所示，IKEv2认证的过程包括两个阶段：
第一阶段
认证发起方(initiator)和响应(responder)方通过一对IKE安全关联参数(security association，SA)消息协商和交换认证所需的参数，其中发起方发送初始协商(IKE_SA_INIT)请求消息，响应方发送IKE_SA_INIT响应消息。
第二阶段
认证发起方和响应方通过一对IKE身份验证(authentication，AUTH)消息进行身份认证，其中发起方的IKE AUTH消息称为IKE_AUTH请求消息，响应方的IKE_AUTH消息称为IKE AUTH响应消息。
IKE认证的消息交互过程主要包括：发起方向响应方发送IKE_SA_INIT请求消息，响应方回复IKE_SA_INIT响应消息。发起方和响应方通过这两条消息协商和交换认证所需的参数。随后发起方向响应方发送IKE_AUTH请求消息，响应方回复IKE_AUTH响应消息，完成身份认证。
在现有的认证方式中，IKE AUTH消息中的签名信息需要用户进行配置。在进行IKE认证配置时，用户必须先查阅设备证书中的签名信息，并且准确记录下证书中的签名信息；其次，用户需要根据记录的证书中的签名信息对认证方法进行配置，并且需要保证用户配置的认证方法与证书中的签名算法一一对应。例如，如果证书中的签名信息指示的公钥算法为RSA算法(Rivest–Shamir–Adleman algorithm，RSA)，那么用户配置的认证方法必须与证书指示的RSA算法相匹配，即用户配置的算法也必须是RSA算法。另外，一些请求评论(request for comments，RFC)文件，例如RFC 7427对认证方法进行了扩展，新增了通用认证方法数字签名(digital signature)方式，因此，用户还需要确认对方是否支持数字签名方式。
在现有的认证方式下，用户参与了较复杂的配置过程。用户必须了解如何查询证书文件中的签名信息，理解算法类型的含义，并且能够熟练使用不同的签名信息类型所对应的IKE认证方法的配置选项，这些操作都对用户有较高的要求。此外，为了避免用户配置错误，对于基站、终端等边缘设备，还需要进行额外的防呆设计。
当前的认证方法配置比较复杂，如果出现新的证书类型、配置界面或者IKE协议实现，都需要新增修改，不利于扩展，而且会进一步增加使用难度。
本申请提供一种IKE使用证书认证的方法，设备可以自动从证书中解析出签名信息并将合适的信息填充到IKE消息的相应字段，简化了用户配置，进一步减少了人为配置的错误。而且，由于设备可以自动从证书中获取签名信息并填充到IKE消息的相应字段中，用户无需学习不同厂商设备的配置命令，提升了产品的易用性。此外，对于网络边缘设备等自动化要求较高的设备，本申请的认证方法还可以减少额外的防呆设计和配置约束。
下面结合图3至图6详细介绍本申请实施例的证书认证方法。
图3是本申请一实施例的IKE使用证书认证的方法的流程示意图。应理解，图3示出了IKE使用证书认证的方法的步骤或操作，但这些步骤或操作仅是示例，本申请实施例还可以执行其他操作或者图3中的各个操作的变形。
下面结合图3，以设备A为发起方、设备B为响应方为例，详细介绍本申请一实施例的证书认证方法。
S210，设备A获取用户配置的证书。设备A中可以存储至少一个证书文件，当设备A与不同的响应方设备进行认证时，可能需要不同的证书。例如，设备A作为认证发起方，设备B作为认证响应方进行认证时，设备A需要的证书文件是证书A。在步骤S210中，用户可以通过命令行(command，CMD)、人机语言(man-machine language，MML)命令或者应用程序接口(application programming inferface，API)、菜单选择等方式指示设备A此次证书认证对应的证书文件是证书A。
在一些实施例中，设备A中只存储了一个证书文件，设备A作为认证的发起方，将默认使用该证书文件与设备B进行认证，在这种情况下，用户可以不额外配置此次证书认证对应的证书文件。
在另一些实施例中，设备A中存储了至少一个证书文件，并且，第一计算机作为认证的发起方，默认使用上述至少一个证书文件中的证书A与设备B进行认证，在这种情况下，用户也可以不额外配置此次证书认证对应的证书文件。
如上所述，用户可以不对此次证书认证对应的证书进行配置。因此，在一些实施例中，设备A可以不获取用户配置的证书。在此情况下，该设备A可以默认在此次认证中使用的证书是该设备A内仅有的一个证书，或者该设备A可以默认在此次认证中使用的证书是至少一个证书文件中的证书A。换句话说，在一些情况下，可以不执行步骤S210。在此情况下，设备A可以确定此次认证使用的证书是该设备A内仅有的一个证书，或者设备A可以确定此次认证使用的证书是默认的证书A。
S220，设备A获取用户配置的认证选项。在这个步骤中，用户可以通过命令行、MML命令、API、菜单选择等方式配置设备A的认证选项。
在一个具体的实施方式中，用户配置的认证选项可以包括第一配置信息。该第一配置信息用于指示认证方法。该第一配置信息指示的认证方法可以为通用的证书签名认证或者通用的非对称秘钥算法认证。并且，如果该第一配置信息指示的认证方法为通用的非对称秘钥算法认证，该第一配置信息还可以指示通用的非对称秘钥算法的签名信息的来源。通用的非对称密钥算法的签名信息的来源可以是证书，还可以是除了证书文件以外的其他文件，或者其他协议。
例如，在第一配置信息的选项设计中，通用的证书签名认证选项接口可以命名为：IKE_CERT_SIG、或CERT_SIG。
例如，在第一配置信息的选项设计中，通用的非对称秘钥算法认证选项接口可以命名为：IKE_ASYM_ALG。并且，可以在选项中额外指定非对称秘钥算法认证的签名信息的来源。在一个具体的实施方式中，如果没有额外指定非对称秘钥算法认证的签名信息的来源，那么可以默认签名信息的来源是证书。
在一个具体的实施方式中，如果设备A获取的认证选项中不包括该第一配置信息，则该设备A可以默认认证方式为通用的证书签名认证。
在一个具体的实施方式中，用户配置的认证选项可以包括第二配置信息，该第二配置信息指示了设备A是否支持数字签名，例如，RFC 7427规定的数字签名。
例如，在第二配置信息的选项设计中，配置设备A是否支持数字签名方式的接口可以命名为：DIG_SIG。
在一些实施例中，如果设备A获取的认证选项中不包括该第二配置信息，那么可以默认设备A支持数字签名。
在另一些实施例中，如果设备A获取的认证选项中不包括该第二配置信息，那么可以默认设备A不支持数字签名。
图4是本申请实施例一种用户参与IKE认证配置的示意图。
如图4所示，用户通过CERT_SIG接口配置了第一配置信息，指示设备A认证方法为通用的证书签名认证。设备A默认支持数字签名，在这种情况下，用户可以不配置第二配置信息。
在另一些实施例中，用户通过IKE_ASYM_ALG接口配置第一配置信息，指示设备A认证方式为通用的非对称秘钥算法认证，并且指示签名信息来源于证书；用户通过DIG_SIG接口配置第二配置信息，指示设备A支持数字签名方式。
在另一些实施例中，设备A默认采用通用的证书签名认证，并且设备A默认支持数字签名，在这种情况下，用户可以不进行第一配置信息和第二配置信息的配置。
应理解，根据上述认证选项的配置方法，图4所示的用户配置以及上述用户配置的实施例仅仅是部分实施例，其他可能的配置组合在此不再详述。
还应理解，用户还可以对设备B进行如步骤S210和步骤S220所述的相似的配置操作，不再赘述。
在另一些实施例中，在设备A的认证方法是通用的证书签名认证情况下，设备A可以在IKE_AUTH请求消息第三个报文的证书(certificate，CERT)负载字段中携带证书文件。设备B可以根据CERT负载字段中的证书文件确定设备B也采用通用的证书签名认证方法。
如上所述，设备A获取的认证选项中可以不包括该第一配置信息和/或该第二配置信息。因此，在一些实施例中，该设备A也可以不获取用户配置的认证选项。在此情况下，该第一计算机可以默认使用的认证方式为通用的证书签名认证并且支持数字签名。换句话说，在一些情况下，可以不执行步骤S220。在此情况下，设备A可以确定认证方式为通用的证书签名认证并且支持数字签名。
如上所述，在本申请实施例中，步骤S210和步骤S220为可选步骤，在其他实施例中，可以存在S210和步骤S220的部分或全部步骤。例如，在步骤S230之前，可以存在步骤S210至步骤S220，或者可以仅存在步骤S210，或者可以仅存在步骤S220。
在上述实施例中，用户只需要对认证选择进行简单的认证选项的配置，不需要配置具体的签名信息。如上所述，在认证的过程中，用户可以通过简洁明了的菜单或者选项命令对认证的方式进行配置。例如，用户可以通过菜单选择的方式选择认证的方法是通用的证书签名认证；用户可以通过菜单选择的方式选择设备A是否支持数字签名。而现有的证书认证技术中，用户需要通过复杂的计算机指令逐一配置设备A在认证中需要的签名信息，在本申请的实施例中，用户既不需要通过复杂的命令对每一种签名信息进行配置，也不需要学习不同厂商的设备的不同的命令格式和配置方法。
步骤S230和步骤S240是设备A和设备B在IKEv2认证的第一阶段的消息交互过程，因理解，步骤S230中的IKE_SA_INIT请求消息和步骤S240中的IKE_SA_INIT响应消息中的各个字段的填充方式与现有技术相同，不再详述。
S230，设备A向设备B发送IKE_SA_INIT请求消息。
在一些实施例中，设备A除了可以在IKE SA请求消息中携带关于认证的参数以外，还可以携带确认设备B是否支持数字签名的信息。
例如，设备A获取的第二配置信息指示设备A支持数字签名，那么设备A在IKE_SA_INIT请求消息中携带SIGNATURE_HASH_ALGORITHMS信息，尝试确认设备B是否支持数字签名。
再如，设备A默认支持数字签名，那么设备A在IKE_SA_INIT请求消息中携带SIGNATURE_HASH_ALGORITHMS信息，尝试确认设备B是否支持数字签名。
再如，设备A默认不支持数字签名或者获取的第二配置信息指示设备A不支持数字签名认证，那么设备A在IKE SA请求消息中也可以不携带SIGNATURE_HASH_ALGORITHMS信息。
S240，设备A接收设备B发送的IKE_SA_INIT响应消息。
在一些实施例中，设备B除了可以在IKE_SA_INIT响应消息中携带关于认证的参数以外，还可以携带指示设备B是否支持数字签名的信息。
例如，设备B默认支持数字签名，那么设备B在IKE_SA_INIT响应消息的第二个报文中携带SIGNATURE_HASH_ALGORITHMS信息的通知(notification)，告知设备A该设备B支持数字签名。
再如，设备B默认不支持数字签名，那么设备B在IKE_SA_INIT响应消息第二个报文中不携带SIGNATURE_HASH_ALGORITHMS信息的通知，告知设备A该设备B不支持数字签名。
在一个具体的实施方式中，设备A可以根据IKE_SA_INIT响应消息的第二个报文中是否含有SIGNATURE_HASH_ALGORITHMS信息的通知确定设备B是否支持数字签名。
步骤S250和步骤S260是设备A和设备B在IKEv2认证的第二阶段的消息交互过程。
S250，设备A向设备B发送IKE_AUTH请求消息。
设备A在发送该IKE_AUTH请求消息之前，需要对IKE_AUTH请求消息中的AUTH负载(AUTH payload)字段进行填充。
如上所述，在一些实施例中，设备A可以获取用户配置的认证选项。在此情况下，该设备A可以根据获取到的认证选项，确定如何填充AUTH负载字段。
例如，如果该设备A获取到的认证选项中包括第一配置信息，并且第一配置信息指示的认证方式为通用的证书签名认证，那么设备A可以自动从证书中解析签名信息，并根据签名信息填充AUTH负载字段。
又如，如果该设备A获取到的认证选项中包括第一配置信息，并且该第一配置信息指示的认证方法为通用的非对称秘钥算法认证并且签名信息的来源为证书，那么设备A可以自动从证书中解析签名信息，并根据签名信息填充AUTH负载字段。
在另一些实施例中，如果用户配置的认证选项没有包括第一配置信息或者用户没有配置认证选项，那么设备A可以自动从证书中解析签名信息，并根据签名信息填充AUTH负载字段。
下面结合图5详细介绍AUTH负载字段的填充流程。
图5是本申请一实施例的AUTH负载字段填充的流程示意图。
S310，设备A解析证书，获取证书中的签名信息。具体来说，设备A可以直接利用软件解析证书文件中包含的签名信息，无需用户去查询证书中的签名信息。设备A可以从证书文件的多个包含签名信息的字段中解析出签名信息。
例如，RFC 5280对证书文件中秘钥算法等签名信息定义格式如下：
Figure BDA0002416426860000111
其中，Certificate表示证书文件；SEQUENCE表示将该证书中的内容按顺序组织起来，形成目标证书(Certificate)；tbsCertificate(to be signed certificate)表示该证书中待签名的证书内容，signatureAlgorithm表示该证书的签名算法，signatureValue表示该证书的签名值，并且该签名值是使用signatureAlgorithm中所示的签名算法对tbsCertificate中的内容进行签名计算得到的。
在signatureAlgorithm字段表示的签名算法中，具体还包括算法(algorithm)和其他可以定义的参数(parameters)。
例如，证书中的签名信息是RSA With SHA-1，那么证书中上述字段中signatureAlgorithm的内容应该是：
Figure BDA0002416426860000112
Figure BDA0002416426860000121
设备A解析上述signatureAlgorithm字段中的“IDENTIFIER”得到扩展算法是sha1WithRSAEncryption；解析上述signatureAlgorithm字段中的“HASHES”得到哈希算法是sha1；解析上述signatureAlgorithm字段中的“PUBLIC-KEYS”得到公钥算法是RSA；解析上述signatureAlgorithm字段的“sha1WithRSAEncryption OBJECT IDENTIFIER”得到对象标识符是“iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-1(1)5”。
此外，设备A还可以解析证书中的TBSCertificate字段中的Signature字段和subjectPublicKeyInfo字段得到上述签名信息，本申请的实施例对此不作限定。
S320，设备A根据证书中的签名信息，填充IKE_AUTH请求消息中的AUTH负载字段，并且，AUTH负载字段指示的签名信息与所述证书的中的签名信息相匹配。
具体来说，AUTH负载字段填充可以分为两种情况：非数字签名方式和数字签名方式。在非数字签名方式中，由于AUTH负载字段中身份验证方法(AUTH method)字段的填充值指示了AUTH负载中的签名信息，因此AUTH method字段的填充值需要与证书中的签名信息相匹配。在数字签名方式中，AUTH负载字段中算法标识(AlgorithmIdentifierASN.1object)字段的填充值指示了AUTH负载中的签名信息，因此AlgorithmIdentifierASN.1object字段的填充值需要与证书中的签名信息相匹配。
下面结合表1和表2，分别介绍非数字签名方式和数字签名方式下AUTH负载字段的填充方式。
表1是非数字签名方式下，AUTH负载字段的填充值与证书中的签名信息的映射关系。在一个具体的实施方式中，设备A可以根据证书的签名信息中包括的公钥算法、以及签名的填充方式、哈希算法和扩展算法中的至少一个确定AUTH method字段的填充值。
表1
Figure BDA0002416426860000122
Figure BDA0002416426860000131
其中，表1中的“-”表示在公钥算法为EdDSA的情况下，不需要哈希算法。表1中的“NA”表示AUTH method不可用(not available，NA)。
在一些实施例中，设备A可以根据公钥算法确定AUTH method的填充值。例如，当公钥算法为RSA算法时，设备A可以确定AUTH method的填充值为1。
在一些实施例中，设备A可以根据公钥算法和扩展算法确定AUTH method的填充值。例如，当公钥算法为ECDSA，并且扩展算法为ecdsa-with-sha256时，设备A可以确定AUTHmethod的填充值为9。
在一些实施例中，设备A可以根据公钥算法、哈希算法和签名填充方式确定AUTHmethod的填充值。例如，当公钥算法为ECDSA、哈希算法为sha384，并且签名填充方式为ECDSA时，设备A可以确定AUTH method的填充值为10。
在一些实施例中，设备A可以根据公钥算法、签名填充方式、哈希算法以及扩展算法确定Auth method的填充值。例如，当公钥算法是ECDSA、签名填充方式是ECDSA、哈希算法是SHA512，并且扩展算法是ecdsa-with-sha512时，设备A可以确定AUTH method的填充值是11。
在一个具体的实施方式中，当设备A确定设备A和设备B中至少有一个设备不支持数字签名时，设备A按照非数字签名方式填充AUTH负载字段。
例如，设备A获取用户配置的认证选项中的第二配置信息，确定设备A支持数字签名，并且设备A接收到来自设备B的IKE_SA_INIT响应消息中不含SIGNATURE_HASH_ALGORITHMS信息的通知。在这种情况下，设备A确定两个设备中至少有一个设备不支持数字签名，设备A按照非数字签名方式填充AUTH负载字段。
再如，设备A默认不支持数字签名，因此，设备A确定设备A和设备B中至少一个设备不支持数字签名，设备A按照非数字签名方式填充AUTH负载字段。
表2是数字签名方式下，AUTH负载字段的填充值与证书中的签名信息的映射关系。在一个具体的实施方式中，设备A可以根据证书的签名信息中包括的对象标识符确定AUTH负载字段中的AlgorithmIdentifier ASN.1object字段的填充值，其中证书的签名信息中包括的对象标识符是与证书的签名信息中的公钥算法、签名的填充方式、哈希算法和扩展算法相对应的编码。对象标识符是一种在公钥算法标准中广泛使用的方法，它可以指示证书中包含的签名信息。证书中的签名信息都有对应的对象标识符，例如，RFC 5280或者RFC5912等对证书中的签名信息和对象标识符的映射关系作出了规定。
示例性地，在数字签名方式下，AUTH负载字段中AUTH method字段的填充值均为14。AlgorithmIdentifier ASN.1object字段的填充值是证书中的对象标识符以及附带参数采用可辨别编码规则(distinguished encoding rules，DER)进行编码后的内容。
表2
Figure BDA0002416426860000141
其中，表2中的“-”表示在公钥算法为EdDSA的情况下，不需要哈希算法。
例如，在上述步骤S310的一个实施例中，当证书中的签名信息是RSA With sha-1时，解析证书文件中的signatureAlgorithm字段的“sha1WithRSAEncryption OBJECTIDENTIFIER”，可以得到用抽象语法编码1(abstract syntax notation one，ASN.1)表示的对象标识符是“iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-1(1)5”。该对象标识符的点分十进制编码表示为：“1.2.840.113549.1.1.5”。解码该对象标识符，可以得到证书中的签名信息是RSA With sha-1，并且，RFC 3279要求的附带参数是空参数。
如表2所示，当证书中的签名信息是RSA With sha-1时，AlgorithmIdentifierASN.1object字段的填充值是：300d 0609 2a86 4886 f70d 0101 0505 00。该填充值的每个字节都是十六进制数，各字节意义分别如下：
第1个字节“30”是标签(tag)，表示后面的内容是一个序列，按顺序依次是对象标识符以及附带参数的ASN.1编码；
第2个字节“0d”是长度，表示后面的内容长度是13个字节；
第3个字节“06”是标签，表示对象标识符；
第4个字节“09”是长度，表示后面的内容长度是9个字节；结合第三个字节，表示签名信息RSA With sha-1的对象标识符编码后长度是9个字节；
第5-13个字节“2a86 4886 f70d 0101 05”是签名信息RSA With sha-1的对象标识符的DER编码；
第14个字节“05”是标签，表示空值(NULL)，表示签名信息RSA With sha-1没有附带参数；
第15个字节“00”是长度，表示后面的内容长度是0字节，即参数内容为空，没有参数。
应理解，在表2中，对于每一种签名信息的对象标识符，都可以依据上述DER编码规则生成AlgorithmIdentifier ASN.1object字段的填充值。为了更简洁地展示AlgorithmIdentifier ASN.1object字段填充值与证书中的签名信息存在的映射关系，使用“……”符号对部分AlgorithmIdentifier ASN.1object字段填充值进行了省略。
在一个具体的实施方式中，当设备A确定设备A和设备B都支持数字签名时，设备A按照数字签名方式填充AUTH负载字段。
例如，设备A获取用户配置的认证选项中的第二配置信息，确定设备A支持数字签名，并且设备A接收到来自设备B的IKE_SA_INIT响应消息的第二个报文中包含SIGNATURE_HASH_ALGORITHMS信息的通知。在这种情况下，设备A确定两个设备都支持数字签名，设备A按照数字签名方式填充AUTH负载字段。
再如，设备A默认支持数字签名，并且设备A接收到来自设备B的IKE_SA_INIT响应消息的第二个报文中包含SIGNATURE_HASH_ALGORITHMS信息的通知。在这种情况下，设备A确定两个设备都支持数字签名，设备A按照数字签名方式填充AUTH负载字段。
应理解，在本申请实施例中，无论是非数字签名方式还是数字签名方式，除了AUTH负载字段中的AUTH method字段和AlgorithmIdentifier ASN.1object字段，IKE AUTH消息中其他字段的填充方式与现有的填充方式相同，在此不再赘述。
如上所述，在本申请一些实施的证书认证方法中，设备A可以获取用户配置的认证选项，确定从证书中解析签名信息。并且，设备A可以获取用户的配置信息确定AUTH负载的填充方式。在这种情况下，设备A可以自动地从证书中解析出签名信息，并且根据证书中的签名信息与AUTH负载的填充值的映射关系，自动地填充AUTH负载中的相应的字段。而现有的认证方法中，用户需要查询证书中的签名信息，再根据证书中的签名信息对AUTH负载的填充进行配置，并且要保证用户配置的AUTH负载的填充值对应的签名信息与证书中的签名信息相匹配，对用户要求较高。
S260，设备A接收设备B发送的IKE_AUTH响应消息。
在这一步骤中，与设备A相似，设备B也需要构造IKE AUTH消息。在该实施例中，设备B为认证的响应方，因此设备B需要构造IKE_AUTH响应消息，并且设备B发送的IKE_AUTH响应消息与设备A发送的IKE_AUTH请求消息具有相似的结构。因此，与设备A相似，设备B也可以根据上述步骤S250中的方法，填充该IKE_AUTH响应消息中的AUTH负载，在此不再赘述。
应理解，除了上述AUTH method字段和AlgorithmIdentifier ASN.1object字段，IKE AUTH响应消息中其他字段的填充方式与现有的填充方式相同。
设备A收到该IKE_AUTH响应消息后，检查响应消息中携带的签名信息是否与该响应消息中的证书文件的签名信息一致，如果不一致，则认为本次认证失败；如果一致，可以继续进行认证处理。
以上是以设备A作为发起方、设备B作为响应方为例的证书认证的过程。应理解，设备B也可以作为发起方，设备A也可以作为响应方，此时，设备A和设备B仍然可以通过与上述步骤相似的过程完成证书认证，在此不再赘述。
图6是本申请另一实施例的IKE使用证书认证的方法400的流程示意图。
S410，第一设备解析证书，获取证书中的签名信息。第一设备可以根据如上述图5所示的方法300中步骤S310所述的方法获取证书中的签名信息，不再赘述。
S420，第一设备根据证书中的签名信息，填充IKE AUTH消息中的AUTH负载字段。方法400可以用于实现方法200。当第一设备是认证的发起方时，第一设备相当于方法200中的设备A。相应的，第一设备填充的IKE AUTH消息相当于是方法200中的IKE_AUTH请求消息。因此，第一设备可以根据如上述方法200中步骤S250所述的方法填充IKE_AUTH请求消息中的AUTH负载字段。
当第一设备是认证的响应方时，第一设备相当于方法200中的设备B。相应的，第一设备填充的IKE AUTH消息相当于是方法200中的IKE_AUTH响应消息。因此，第一设备可以根据如上述方法200中步骤S260所述的方法填充IKE_AUTH响应消息中的AUTH负载字段。
S430，第一设备发送IKE AUTH消息。
当第一设备是认证的发起方时，第一设备相当于方法200中的设备A。此时，第一设备发送填充后的IKE_AUTH请求消息。
当第一设备是认证的响应方时，第一设备相当于方法200中的设备B。此时，第一设备发送填充后的IKE_AUTH响应消息。
本申请实施例的证书认证方法简化了用户配置的过程，避免了用户配置的错误。另外，由于不需要对具体的签名信息进行配置，不同厂商的设备可以采用相同或相似的配置接口，用户无需学习不同厂商的复杂的配置命令，提升了产品的易用性，降低了对用户的要求。
此外，在本申请实施例中，第一设备根据用户的配置信息采用通用的证书签名认证，或者采用非对称秘钥算法认证且确定签名信息的来源是证书后，第一设备可以自动从证书文件中获取签名信息。第一设备还可以根据从证书中获取的签名信息自动填充IKEAUTH消息中的AUTH负载字段，无需用户对AUTH负载字段的填充值进行配置，避免了用户配置错误，提高了IKE AUTH消息的准确性。
图7是根据本申请实施例提供的通信设备的结构示意图。该通信设备用于实现上述方法200或方法400。例如，通信设备可以为上述方法200中的设备A，设备B，也可以是方法400中的第一设备，也可以为可用于上述方法中的设备A，设备B或第一设备的部件(例如芯片或者电路)。如图7所示，通信设备700可以包括获取单元710、填充单元720和发送单元730。
获取单元710，用于解析证书，获取证书中的签名信息。
填充单元720，用于根据证书中的签名信息填充IKE AUTH消息中的AUTH负载字段，该AUTH负载字段中指示的签名信息和证书中的签名信息相同。
发送单元730，用于向第二设备发送该IKE AUTH消息。
一种可能的方式中，获取单元710和填充单元720可以由处理器实现，发送单元730可以由发送器实现。获取单元710、填充单元720、发送单元730的具体功能和有益效果可以参见上述方法中的描述，为了简洁，在此不再赘述。
图8是根据本申请实施例提供的通信设备的结构示意图。该通信设备用于实现上文所述的方法200或方法400。例如，通信设备可以为方法200中的设备B，执行上述方法200中设备B执行的操作，可以为上述方法400中的第二设备，也可以为可用于上述方法中的第二设备的部件(例如芯片或者电路)，执行第二设备执行的操作。如图8所示，通信设备800可以包括接收单元810和发送单元820。
接收单元810，用于接收第一设备发送的IKE AUTH消息。
发送单元820，用于向第一设备发送IKE SA消息，该IKE SA消息指示该通信设备支持数字签名。
一种可能的方式中，接收单元810可以由接收器实现，发送单元820可以由发送器实现。接收单元810和发送单元820的具体功能和有益效果可以参见上述方法中的描述，为了简洁，在此不再赘述。
图9是是根据本申请实施例提供的通信设备的结构示意图。如图9所示，通信设备900包括处理器910、存储器920、收发器930。处理器910可以用于对证书认证协议以及认证数据进行处理，以及对通信设备进行控制，执行软件程序，处理软件程序的数据等。存储器920主要用于存储软件程序和数据。收发器930用于接收其他设备(例如第二设备)发送的信息或者向其他设备发送信息。
为便于说明，图9中仅示出了一个存储器和处理器。在实际的通信设备产品中，可以存在一个或多个处理器和一个或多个存储器。存储器也可以称为存储介质或者存储设备等。存储器可以是独立于处理器设置，也可以是与处理器集成在一起，本申请实施例对此不做限制。
收发器也可以称为收发单元、收发机、收发装置等。处理单元也可以称为处理器，处理单板，处理模块、处理装置等。可以将收发器930中用于实现接收功能的器件视为接收单元，将收发器930中用于实现发送功能的器件视为发送单元，即收发器930包括接收单元和发送单元。接收单元有时也可以称为接收机、接收器、或接收电路等。发送单元有时也可以称为发射机、发射器或者发射电路等。
处理器910、存储器920和收发器930之间通过内部连接通路互相通信，传递控制和/或数据信号
上述本申请实施例揭示的方法可以应用于处理器910中，或者由处理器910实现。处理器910可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器910中的硬件的集成逻辑电路或者软件形式的指令完成。
本申请各实施例所述的处理器可以是通用处理器、数字信号处理器(digitalsignal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存取存储器(random access memory，RAM)、闪存、只读存储器(read-only memory，ROM)、可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的计算机可读存储介质中。该计算机可读存储介质位于存储器，处理器读取存储器中的指令，结合其硬件完成上述方法的步骤。
在一些实施例中，存储器920可以存储用于执行如图3和/或图5所示方法中设备A和/或第一设备执行的方法的指令。处理器910可以执行存储器920中存储的指令结合其他硬件(例如收发器930)完成相应方法中第一设备执行的步骤，具体工作过程和有益效果可以参见上述实施例中的描述。
在一些实施例中，存储器920可以存储用于执行如图3和/或图5所示方法中设备B和/或第二设备执行的方法的指令。处理器910可以执行存储器920中存储的指令结合其他硬件(例如收发器930)完成相应方法中第二设备执行的步骤，具体工作过程和有益效果可以参见上述实施例中的描述。
在一些实施例中，存储器920可以存储用于执行如图3所示方法中设备A和设备B执行的方法的指令。处理器910可以执行存储器920中存储的指令结合其他硬件(例如收发器930)完成相应方法中设备A执行的步骤或设备B执行的步骤，具体工作过程和有益效果可以参见上述所示实施例中的描述。
本申请实施例还提供一种芯片，该芯片包括收发单元和处理单元。其中，收发单元可以是输入输出电路、通信接口；处理单元为该芯片上集成的处理器或者微处理器或者集成电路。该芯片可以执行上述方法实施例中设备A和/或第一设备的方法。
本申请实施例还提供一种芯片，该芯片包括收发单元和处理单元。其中，收发单元可以是输入输出电路、通信接口；处理单元为该芯片上集成的处理器或者微处理器或者集成电路。该芯片可以执行上述实施例中设备B和/或第二设备执行的方法。
本申请实施例还提供一种计算机可读存储介质，其上存储有指令，该指令被执行时执行上述方法实施例中设备A和/或第一设备的方法。
作为本实施例的另一种形式，提供一种计算机可读存储介质，其上存储有指令，该指令被执行时执行上述方法实施例中设备B和/或第二设备的方法。
本申请实施例还提供一种包含指令的计算机程序产品，该指令被执行时执行上述方法实施例中设备A和/或第一设备的方法。
作为本实施例的另一种形式，提供一种包含指令的计算机程序产品，该指令被执行时执行上述方法实施例中设备B和/或第二设备的方法。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
本申请实施例中的方法，如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在计算机可读存储介质中，基于这样的理解，本申请的技术方案或技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。该存储介质至少包括：U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (17)

1.一种网络密钥交换协议IKE使用证书认证的方法，其特征在于，包括：
第一设备解析证书，获取证书中的签名信息；
所述第一设备根据所述证书中的签名信息，填充网络密钥交换协议IKE身份验证AUTH消息中的AUTH负载字段，所述AUTH负载字段指示的签名信息与所述证书中的签名信息相匹配；
所述第一设备向第二设备发送所述IKE AUTH消息。
2.根据权利要求1所述的方法，其特征在于，所述证书中的签名信息包括：公钥算法。
3.根据权利要求2所述的方法，其特征在于，所述证书中的签名信息还包括：签名的填充方式、哈希算法和扩展算法中的至少一个。
4.根据权利要求2或3所述的方法，其特征在于，所述证书中的签名信息包括对象标识符，所述对象标识符是对所述证书中的签名信息的编码。
5.根据权利要求1至4中任一项所述的方法，其特征在于，在所述第一设备解析证书，获取证书中的签名信息之前，所述方法还包括：
所述第一设备获取第一配置信息，所述第一配置信息指示IKE使用证书认证的方法的类型。
6.根据权利要求5所述的方法，其特征在于：
所述IKE使用证书认证的方法的类型为通用的证书签名认证；或者，
所述IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证；
在所述IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证的情况下，所述第一配置信息还指示：所述通用的非对称秘钥算法认证的签名信息的来源。
7.根据权利要求1至6中任一项所述的方法，其特征在于，在所述第一设备根据所述证书中的签名信息填充IKE AUTH消息中的AUTH负载字段之前，所述方法还包括：
所述第一设备确定所述第一设备和所述第二设备均支持数字签名；
在所述第一设备和所述第二设备均支持所述数字签名的情况下，采用数字签名方式填充所述AUTH负载字段，并且，所述AUTH负载字段中的算法标识字段的填充值为对象标识符的可辨别编码规则DER编码。
8.根据权利要求7所述的方法，其特征在于，所述第一设备确定所述第一设备和所述第二设备均支持数字签名包括：
所述第一设备获取第二配置信息，所述第二配置信息指示第一设备支持数字签名；
所述第一设备获取所述第二设备发送的IKE安全关联参数SA消息，所述IKE SA消息指示所述第二设备支持数字签名。
9.一种通信设备，其特征在于，所述通信设备包括：
存储器，存储有程序；
与所述存储器通信的处理器，所述处理器运行所述程序，使得所述设备执行以下操作：
解析证书，获取证书中的签名信息；
根据所述证书中的签名信息，填充网络密钥交换协议IKE身份验证AUTH消息中的AUTH负载字段，所述AUTH负载字段指示的签名信息与所述证书中的签名信息相匹配；
向第二设备发送所述IKE AUTH消息。
10.根据权利要求7所述的通信设备，其特征在于，所述证书中的签名信息包括：公钥算法。
11.根据权利要求8所述的通信设备，其特征在于，所述证书中的签名信息还包括：签名的填充方式、哈希算法和扩展算法中的至少一个。
12.根据权利要求7或8所述的通信设备，其特征在于，所述证书中的签名信息包括对象标识符，所述对象标识符是对所述证书中的签名信息的编码。
13.根据权利要求9至12中任一项所述的通信设备，其特征在于，所述程序还包括执行以下操作的指令：
在所述解析证书，获取证书中的签名信息之前，获取第一配置信息，所述第一配置信息指示IKE使用证书认证的方法的类型。
14.根据权利要求9所述的通信设备，其特征在于：
所述IKE使用证书认证的方法的类型为通用的证书签名认证；或者，
所述IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证；
在所述IKE使用证书认证的方法的类型为通用的非对称秘钥算法认证的情况下，所述第一配置信息还指示：所述通用的非对称秘钥算法认证的签名信息的来源。
15.根据权利要求9至14中任一项所述的通信设备，其特征在于，所述程序还包括执行以下操作的指令：
在所述根据所述证书中的签名信息填充IKE AUTH消息中的AUTH负载字段之前，确定所述通信设备和所述第二设备均支持数字签名；
在所述通信设备和所述第二设备均支持所述数字签名的情况下，采用数字签名方式填充所述AUTH负载字段，并且，所述AUTH负载字段中的算法标识字段的填充值为对象标识符的可辨别编码规则DER编码。
16.根据权利要求15所述的通信设备，其特征在于，所述确定所述通信设备和所述第二设备均支持数字签名包括：
获取第二配置信息，所述第二配置信息指示所述通信设备支持数字签名；
获取所述第二设备发送的IKE安全关联参数SA消息，所述IKE SA消息指示所述第二设备支持数字签名。
17.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储用于如权利要求1至8中任一项所述的方法的指令。
CN202010192532.5A 2020-03-18 2020-03-18 网络密钥交换协议使用证书认证的方法和通信设备 Pending CN113497779A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202010192532.5A CN113497779A (zh) 2020-03-18 2020-03-18 网络密钥交换协议使用证书认证的方法和通信设备
PCT/CN2021/081054 WO2021185240A1 (zh) 2020-03-18 2021-03-16 网络密钥交换协议使用证书认证的方法和通信设备
EP21770833.8A EP4109838B1 (en) 2020-03-18 2021-03-16 Internet key exchange protocol authentication method using certificate, and communication device
US17/946,542 US12212662B2 (en) 2020-03-18 2022-09-16 Method for internet key exchange protocol authentication using certificate and communication device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010192532.5A CN113497779A (zh) 2020-03-18 2020-03-18 网络密钥交换协议使用证书认证的方法和通信设备

Publications (1)

Publication Number Publication Date
CN113497779A true CN113497779A (zh) 2021-10-12

Family

ID=77770695

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010192532.5A Pending CN113497779A (zh) 2020-03-18 2020-03-18 网络密钥交换协议使用证书认证的方法和通信设备

Country Status (4)

Country Link
US (1) US12212662B2 (zh)
EP (1) EP4109838B1 (zh)
CN (1) CN113497779A (zh)
WO (1) WO2021185240A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024138618A1 (en) * 2022-12-30 2024-07-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for internet key exchange (ike) session management

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101212465A (zh) * 2006-12-26 2008-07-02 中兴通讯股份有限公司 因特网密钥交换协议第二版证书有效性验证的方法
US20080219224A1 (en) * 2004-12-28 2008-09-11 Holur Balaji System and Method for Providing Secure Mobility and Internet Protocol Security Related Services to a Mobile Node Roaming in a Foreign Network
CN101640614A (zh) * 2009-09-03 2010-02-03 成都市华为赛门铁克科技有限公司 一种配置ipsec安全策略的方法及装置
CN101677440A (zh) * 2008-09-18 2010-03-24 华为技术有限公司 一种接入点认证的方法、系统及安全网关
CN102026192A (zh) * 2009-09-21 2011-04-20 中兴通讯股份有限公司 一种移动回程网证书分发方法及系统
CN102413103A (zh) * 2010-09-20 2012-04-11 华为技术有限公司 一种消息验证方法、系统及设备
CN108259157A (zh) * 2016-12-29 2018-07-06 华为技术有限公司 一种ike协商中身份认证的方法及网络设备
CN109981534A (zh) * 2017-12-27 2019-07-05 华为技术有限公司 一种认证方法、设备及系统
CN110138562A (zh) * 2018-02-09 2019-08-16 腾讯科技（北京）有限公司 智能设备的证书签发方法、装置及系统

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060019635A1 (en) * 2004-06-29 2006-01-26 Nokia Corporation Enhanced use of a network access identifier in wlan
US8533473B2 (en) * 2005-03-04 2013-09-10 Oracle America, Inc. Method and apparatus for reducing bandwidth usage in secure transactions
WO2007063420A2 (en) * 2005-12-01 2007-06-07 Nokia Corporation Authentication in communications networks
CN102088699B (zh) * 2009-12-08 2014-04-09 中兴通讯股份有限公司 一种基于信任列表的系统及方法
US9667619B1 (en) * 2016-10-14 2017-05-30 Akamai Technologies, Inc. Systems and methods for utilizing client side authentication to select services available at a given port number
CN112514436B (zh) * 2018-08-02 2024-04-19 瑞典爱立信有限公司 发起器和响应器之间的安全的、被认证的通信
US11582045B2 (en) * 2020-06-02 2023-02-14 John A. Nix Combined digital signature algorithms for security against quantum computers
US12381745B2 (en) * 2021-06-29 2025-08-05 Amazon Technologies, Inc. Identity authority
US12192184B2 (en) * 2021-12-08 2025-01-07 John A. Nix Secure session resumption using post-quantum cryptography

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080219224A1 (en) * 2004-12-28 2008-09-11 Holur Balaji System and Method for Providing Secure Mobility and Internet Protocol Security Related Services to a Mobile Node Roaming in a Foreign Network
CN101212465A (zh) * 2006-12-26 2008-07-02 中兴通讯股份有限公司 因特网密钥交换协议第二版证书有效性验证的方法
CN101677440A (zh) * 2008-09-18 2010-03-24 华为技术有限公司 一种接入点认证的方法、系统及安全网关
CN101640614A (zh) * 2009-09-03 2010-02-03 成都市华为赛门铁克科技有限公司 一种配置ipsec安全策略的方法及装置
CN102026192A (zh) * 2009-09-21 2011-04-20 中兴通讯股份有限公司 一种移动回程网证书分发方法及系统
CN102413103A (zh) * 2010-09-20 2012-04-11 华为技术有限公司 一种消息验证方法、系统及设备
CN108259157A (zh) * 2016-12-29 2018-07-06 华为技术有限公司 一种ike协商中身份认证的方法及网络设备
CN109981534A (zh) * 2017-12-27 2019-07-05 华为技术有限公司 一种认证方法、设备及系统
CN110138562A (zh) * 2018-02-09 2019-08-16 腾讯科技（北京）有限公司 智能设备的证书签发方法、装置及系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024138618A1 (en) * 2022-12-30 2024-07-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for internet key exchange (ike) session management

Also Published As

Publication number Publication date
US20230023846A1 (en) 2023-01-26
WO2021185240A1 (zh) 2021-09-23
EP4109838A4 (en) 2023-07-19
EP4109838B1 (en) 2025-01-01
EP4109838A1 (en) 2022-12-28
US12212662B2 (en) 2025-01-28

Similar Documents

Publication Publication Date Title
US12047516B2 (en) Combined digital signature algorithms for security against quantum computers
US20220209944A1 (en) Secure Server Digital Signature Generation For Post-Quantum Cryptography Key Encapsulations
US12273721B2 (en) Method for securely connecting vehicle and Bluetooth key, and Bluetooth module and Bluetooth key
US11882509B2 (en) Virtual key binding method and system
CN107659406B (zh) 一种资源操作方法及装置
US8307202B2 (en) Methods and systems for using PKCS registration on mobile environment
WO2022067132A1 (en) System and methods for secure communication using post-quantum cryptography
CN113438071A (zh) 安全通信的方法及设备
KR101856682B1 (ko) 엔티티의 인증 방법 및 장치
CN109005032B (zh) 一种路由方法和装置
CN111654481B (zh) 一种身份认证方法、装置和存储介质
CN113872769B (zh) 基于puf的设备认证方法、装置、计算机设备及存储介质
CN116830525A (zh) 数据传输方法、装置、系统、电子设备及可读介质
Cooper et al. Fido device onboard specification 1.1
CN109391473B (zh) 一种电子签章的方法、装置及存储介质
CN119788436A (zh) 数据保护方法、设备以及存储介质
CN113497779A (zh) 网络密钥交换协议使用证书认证的方法和通信设备
CN112637855B (zh) 基于区块链的机卡绑定方法和服务器
CN111064571B (zh) 一种通信终端、服务器及动态更新预共享密钥的方法
US20250150262A1 (en) Early indication for changing cryptographic strenght during configuration
CN110875902A (zh) 通信方法、装置及系统
US20250260975A1 (en) Methods, devices and systems for repeating secure wireless connections
Cooper FIDO IoT spec
CN108241474A (zh) 一种打印控制方法及装置
CN116418666A (zh) 智能仪表的注册方法、装置、电子设备和存储介质

Legal Events

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