WO2022001225A1 - 身份凭据的申请方法、身份认证的方法、设备及装置 - Google Patents

身份凭据的申请方法、身份认证的方法、设备及装置 Download PDF

Info

Publication number
WO2022001225A1
WO2022001225A1 PCT/CN2021/082654 CN2021082654W WO2022001225A1 WO 2022001225 A1 WO2022001225 A1 WO 2022001225A1 CN 2021082654 W CN2021082654 W CN 2021082654W WO 2022001225 A1 WO2022001225 A1 WO 2022001225A1
Authority
WO
WIPO (PCT)
Prior art keywords
identity
identity credential
application
credential
information
Prior art date
Application number
PCT/CN2021/082654
Other languages
English (en)
French (fr)
Inventor
潘适然
方习文
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2022001225A1 publication Critical patent/WO2022001225A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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
    • 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
    • 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
    • H04L63/0435—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 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • 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/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords

Definitions

  • the present application relates to the field of communication technologies, and more particularly, to a method for applying for an identity credential, a method, device and apparatus for identity authentication.
  • the device's identity credentials are typically obtained from a trusted third party prior to authentication. For example, after the application device generates a public-private key pair for identifying the device identity, it sends the public key and other information of the device to a third party for the third party to issue identity credentials.
  • the registration process of identity credentials involves the storage and use of keys.
  • third parties request registration of identities.
  • Credential devices have certain requirements, such as sufficient resources or a secure environment, to ensure that the information sent by the application device to the third party has not been tampered with and reduce the risk of identity credentials being stolen or tampered with during storage and use.
  • IoT Internet of things
  • Some devices can log in to their accounts independently, and some devices can be bound by accounts.
  • Each terminal device can be authenticated and trusted to be interconnected based on an account, and it is not necessarily required that the device has a secure environment. How such a device registers identity credentials from a third party to complete authentication with other devices is an urgent problem to be solved.
  • the present application provides an identity credential application method, an identity authentication method, equipment and apparatus, which can ensure the security of the device registration identity credential process and can improve the coverage of authentication equipment.
  • a method for applying for an identity credential including: a first device sending a first message to a second device, the first message including application information for an identity credential of the first device; the first device Receive a second message sent by the second device, where the second message includes processed identity credential application information, wherein the processed identity credential application information is the identity credential application information of the first device that is processed by the obtained after being signed by the private key of the second device, or obtained after being encrypted by a symmetric key; the first device sends a third message to the third-party device, and the third message includes the processed identity credential application information , which is used to request the third-party device to register the identity credential of the first device, wherein the third-party device and the second device trust each other.
  • the identity credential application information of the first device is signed or encrypted by the second device, so as to ensure the security and integrity of the information sent by the first device to the third-party device.
  • the third-party device can issue an identity credential to the first device after passing the verification of the identity credential application information of the first device.
  • the second device which has a trust relationship with the issuing device, applies for the identity credentials of other devices that have a trust foundation with the second device. Insufficient, the risk of being unable to prove the integrity of identity credentials to third-party devices improves the security of device identity credential registration.
  • the mutual trust between the second device and the third-party device may be understood as the fact that the second device has registered an identity credential at the third-party device, and has established a trusted relationship with the third-party device.
  • the first device is a device without a security environment or a device with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • the second message further includes: device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the device identity information of the second device can be used to identify the second device as a signature for the identity credential application information of the first device, that is, it can identify that the second device acts as an agent for the first device to apply for an identity credential.
  • the usage policy of the identity credential of the first device can be used to notify the first device of the valid information and authentication information of its identity credential, where the valid information includes, for example, the validity period of the identity credential, the number of valid authentication times, etc. Equipment approval or certification.
  • the identity credential application information of the first device includes at least one of the following information: a device identification of the first device; a device identity public of the first device key; the account identifier of the account logged in by the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device identity private key of the second device.
  • the registration service private key of the second device and the registration service public key corresponding to the private key are a pair of public and private keys, which are used to ensure the security of the process of registering the identity credential of the second device.
  • the private key of the registration service of the second device may be preset on the production line of the second device, or obtained through an application.
  • the registration service public key is stored in the third-party device.
  • “the registration service private key of the second device” is only used to indicate that the second device has the registration service private key, and does not limit the one-to-one correspondence between the second device and the registration service private key.
  • the device identity private key of the second device and the device identity public key corresponding to the private key are a pair of public and private keys, which are generated by the second device.
  • the device identity public-private key pair of the second device is used to identify and prove the device identity of the second device.
  • the symmetric key is preset in the second device, or sent to the second device by a third-party device after establishing a trust relationship with the second device of.
  • the third message further includes device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • a method for applying for an identity credential including: a second device receives a first message sent by a first device, the first message including application information for an identity credential of the first device; the second The device signs the identity credential application information of the first device using the private key of the second device, or encrypts the identity credential application information of the first device with a symmetric key, and obtains the processed identity credential application information; the second device sends a second message to the first device, the second message includes the processed identity credential application information, and the processed identity credential application information is used by the first device A request is made to a third-party device to register the identity credential of the first device, wherein the second device and the third-party device trust each other.
  • the first device generates the application identity credential through the agent of the second device. Since the second device and the third-party device are mutually trustworthy, they can prove the integrity of the identity credential application information to the third-party device, which improves the equipment performance. Security of identity credential registration.
  • the first device is a device without a security environment or with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • the second message further includes: device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the identity credential application information of the first device includes at least one of the following information: the device identification of the first device; the device authentication public information of the first device key; the account identifier of the account logged in by the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device identity private key of the second device.
  • the symmetric key is pre-installed in the second device, or sent by a third-party device to the second device after establishing a trust relationship with the second device.
  • the method further includes: the second device generates an identity credential proxy application record, and the identity credential proxy application record is used to indicate that the second device is the first device Proxy application for identity credentials.
  • the identity credential proxy application record is used to instruct the second device to sign the identity credential application information of the first device, or to instruct the second device to encrypt the identity credential application information of the first device.
  • the method further includes: the second device determines a usage policy of the identity credential of the first device, where the usage policy is used to indicate the validity of the first identity credential information.
  • the method further includes: receiving, by the second device, an identity authentication request sent by the first device, where the identity authentication request includes the identity credential of the first device and all the device identification of the first device; the second device determines, according to the device identification of the first device, that the identity credential of the first device is that the second device applies for the first device as an agent; the second device The device determines whether the identity credential of the first device complies with the usage policy according to the usage policy corresponding to the identity credential of the first device; if the identity credential of the first device complies with the usage policy, the The second device performs validity and integrity verification on the identity credential of the first device.
  • the first device and the second device may perform identity authentication based on the identity credential.
  • the second device determines that the identity credential of the first device is an agent application of the second device and complies with the corresponding usage policy, the second device can verify the validity and integrity of the identity credential of the first device.
  • the use policy of the identity credential of the first device includes valid information and authentication information of the identity credential of the first device.
  • the method further includes: determining whether the identity credential of the first device needs to be updated according to the usage policy.
  • the second device determines, according to the device identification of the first device, that the identity credential of the first device is that the second device is the agent of the first device
  • the application includes: the second device inquires, according to the device identification of the first device, an identity credential proxy application record corresponding to the first device, where the identity credential proxy application record is used to indicate that the second device is The identity credential application information of the first device is signed, or the second device is instructed to encrypt the identity credential application information of the first device; determining the first device according to the identity credential proxy application record The identity credential applies for the second device proxy.
  • a method for applying for an identity credential comprising: a second device receiving a first message sent by a first device, the first message including application information for an identity credential of the first device; the second device The device signs the identity credential application information of the first device using the private key of the second device, or encrypts the identity credential application information of the first device with a symmetric key, and obtains the processed identity credential application information; the second device sends a third message to the third-party device, where the third message includes the processed identity credential application information, which is used to request the third-party device to register the identity credential of the first device , wherein the second device and the third-party device trust each other.
  • the identity credential application information of the first device is signed by the private key of the second device, or encrypted by the second device, and the second device and the third-party device are mutually trusted devices.
  • the signature or encryption of the identity credential application information of the first device by the second device can be used to prove the integrity of the information sent by the first device for registering the identity credential, which improves the security of the identity credential registration process.
  • the method further includes: receiving, by the second device, a fourth message sent by the third-party device, where the fourth message includes the identity credential of the first device;
  • the second device sends a fifth message to the first device, the fifth message including the identity credential of the first device.
  • the first device is a device without a security environment or a device with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • the third message further includes: device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the identity credential application information of the first device includes at least one of the following information: the device identification of the first device; the device authentication public information of the first device key; the account identifier of the account logged in by the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device identity private key of the second device.
  • the symmetric key is pre-installed in the second device, or sent to the second device by a third-party device after establishing a trust relationship with the second device.
  • the method further includes: the second device generates an identity credential proxy application record, and the identity credential proxy application record is used to indicate that the second device is the first device Proxy application for identity credentials.
  • the identity credential proxy application record is used to instruct the second device to sign the identity credential application information of the first device, or to instruct the second device to encrypt the identity credential application information of the first device.
  • the method further includes: the second device determines a usage policy of the identity credential of the first device, where the usage policy is used to indicate the validity of the first identity credential information.
  • the method further includes: receiving, by the second device, an identity authentication request sent by the first device, where the identity authentication request includes the identity credential of the first device and all the device identification of the first device; the second device determines, according to the device identification of the first device, that the identity credential of the first device is that the second device applies for the first device as an agent; the second device The device determines whether the identity credential of the first device complies with the usage policy according to the usage policy corresponding to the identity credential of the first device; if the identity credential of the first device complies with the usage policy, the The second device performs validity and integrity verification on the identity credential of the first device.
  • the first device and the second device may perform identity authentication based on the identity credential.
  • the second device determines that the identity credential of the first device is an agent application of the second device and complies with the corresponding usage policy, the second device can verify the validity and integrity of the identity credential of the first device.
  • the use policy of the identity credential of the first device includes valid information and authentication information of the identity credential of the first device.
  • the method further includes: determining whether the identity credential of the first device needs to be updated according to the usage policy.
  • the second device determines, according to the device identification of the first device, that the identity credential of the first device is that the second device is the agent of the first device
  • the application includes: the second device inquires, according to the device identification of the first device, an identity credential proxy application record corresponding to the first device, where the identity credential proxy application record is used to indicate that the second device is The identity credential application information of the first device is signed, or the second device is instructed to encrypt the identity credential application information of the first device; determining the first device according to the identity credential proxy application record The identity credential applies for the second device proxy.
  • a method for applying for an identity credential comprising: a first device sending a first message to a second device, where the first message includes application information for an identity credential of the first device, which is used to request a third party
  • the device requests to register the identity credential of the first device, wherein the second device and the third-party device trust each other; the first device receives a fifth message sent by the second device, and the fifth message includes The identity credential of the first device, wherein the identity credential of the first device is sent to the second device after the third-party device verifies the processed identity credential application information, and the processed identity credential
  • the application information is obtained after the identity credential application information of the first device is signed by the private key of the second device, or obtained after being encrypted by a symmetric key.
  • the first device is a device without a security environment or a device with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • the identity credential application information of the first device includes at least one of the following information: the device identification of the first device; the device authentication public information of the first device key; the account identifier of the account logged in by the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device authentication private key of the second device.
  • the symmetric key is preset in the second device, or sent by a third-party device to the second device after establishing a trust relationship with the second device Two devices.
  • a fifth aspect provides a method for applying for an identity credential, comprising: a third-party device receiving a third message, the third message including processed identity credential application information, wherein the processed identity credential application information is the first
  • the identity credential application information of a device is obtained after being signed by the private key of the second device, or obtained after being encrypted by a symmetric key, the third-party device and the second device trust each other; the third-party device uses the same The public key corresponding to the private key of the second device or the symmetric key verifies the processed identity credential application information; after the verification is passed, the third-party device issues an identity credential for the first device.
  • the third-party device uses The public key corresponding to the private key of the second device verifies the processed identity credential application information. If the processed identity credential application information is obtained by the second device using a symmetric key to symmetrically encrypt the identity credential application information of the first device, correspondingly, the third-party device uses the same encryption process as the encryption process. The symmetric key decrypts the processed identity credential application information.
  • the third-party device receiving the third message includes: the third-party device receiving the third message from the first device; or, the third-party device receiving the third message A device receives the third message from the second device.
  • the first device is a device without a security environment or a device with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • the third message further includes device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the identity credential application information of the first device includes at least one of the following information: the device identification of the first device; the device authentication public information of the first device key; the account identifier of the account logged in by the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device identity private key of the second device.
  • an identity authentication method comprising: a second device receiving an identity authentication request sent by a first device, where the identity authentication request includes an identity credential of the first device and the first device.
  • a device identifier of a device the second device determines, according to the device identifier of the first device, that the identity credential of the first device is that the second device applies for the first device as an agent; the second device determines according to the device identifier of the first device.
  • the usage policy corresponding to the identity credential of the first device determines whether the identity credential of the first device conforms to the usage policy; if the identity credential of the first device conforms to the usage policy, the second device The device performs validity and integrity verification on the identity credential of the first device.
  • the second device is used as an agent to apply for the identity credential of the first device, and the application device establishes a one-to-one trust relationship with the agent device, which can realize mutual authentication between devices, and at the same time reduce the export of authentication keys and batch copying to malicious devices. risk and improve safety.
  • the usage policy corresponding to the identity credential of the first device is used to indicate valid information of the identity credential of the first device. Determining whether the identity credential of the first device complies with the usage policy according to the usage policy corresponding to the identity credential of the first device can be understood as determining whether the identity credential of the first device is valid according to the usage policy, such as whether it is within the validity period, has Valid authentication times, etc. Correspondingly, when the identity credential of the first device does not conform to the usage policy, the identity credential of the first device may be considered invalid.
  • the method further includes: determining whether the identity credential of the first device needs to be updated according to the usage policy.
  • the second device determines, according to the device identification of the first device, that the identity credential of the first device is that the second device is the agent of the first device
  • the application includes: the second device inquires, according to the device identification of the first device, an identity credential proxy application record corresponding to the first device, where the identity credential proxy application record is used to indicate that the second device is The identity credential application information of the first device is signed, or the second device is instructed to encrypt the identity credential application information of the first device; determining the first device according to the identity credential proxy application record The identity credential applies for the second device proxy.
  • a seventh aspect provides an identity authentication method, comprising: a fourth device receiving an identity authentication request sent by a first device, where the identity authentication request includes an identity credential of the first device, wherein the The identity credential of the first device is an agent application of the second device, and the identity credential of the first device includes information of the second device; the fourth device determines the relationship with the first device according to the identity credential of the first device.
  • the device performs identity authentication, wherein the fourth device and the second device trust each other.
  • the fourth device is a device that has registered an identity credential.
  • the mutual trust between the fourth device and the second device can be understood as the fact that the fourth device and the second device have already performed identity authentication, or the identity credentials of the fourth device and the second device are issued by the same device, for example, a third-party device in the embodiment of this application. .
  • the information of the second device includes a device identity of the second device or an identity credential of the second device.
  • an identity authentication method comprising: a fourth device receiving an identity authentication request sent by a first device, the identity authentication request including an identity credential of the first device, wherein the The identity credential of the first device is issued by a third-party device; the fourth device performs identity authentication with the first device according to the identity credential of the first device, wherein the fourth device and the third-party device trust each other .
  • the identity credential of the first device is an agent application for the second device.
  • the identity credential of the first device includes information of the second device.
  • the information of the second device includes a device identity of the second device or an identity credential of the second device.
  • a device comprising a module or unit for performing the method in the above-mentioned first aspect or any possible implementation manner of the first aspect, or including a module or unit for performing the above-mentioned fourth aspect or the fourth aspect
  • a module or unit of a method in any possible implementation may be a hardware circuit, or software, or a hardware circuit combined with software implementation.
  • the device provided by the embodiment of the present application includes a module for executing the above method or step or operation or function executed by the first device.
  • a device comprising a module or unit for performing the method in the second aspect or any of the possible implementation manners of the second aspect, or a device for performing the third aspect or the third aspect.
  • the module or unit may be a hardware circuit, or software, or a hardware circuit combined with software implementation.
  • the device provided by the embodiment of the present application includes a module for performing the above method or step or operation or function performed by the second device.
  • a device including a module or a unit for executing the method in the fifth aspect or any of the possible implementation manners of the fifth aspect.
  • the device provided by the embodiment of the present application includes a module for performing the above-mentioned method or step or operation or function performed by the third-party device.
  • a device including a module or a unit for performing the method in any one of possible implementation manners of the sixth aspect to the eighth aspect or the sixth aspect to the eighth aspect.
  • a thirteenth aspect provides a communication device, the communication device includes: at least one processor and a communication interface, the communication interface is used for the communication device to perform information interaction with other communication devices, when a program instruction is in the When executed in at least one processor, the communication apparatus is made to implement the function of the first device above.
  • the communication interface may be a transceiver, circuit, bus, module, pin or other type of communication interface.
  • the communication device further includes a memory, and the memory is used for storing instructions and data, and when the processor executes the instructions stored in the memory, the first aspect or any one of the first aspects can be implemented.
  • a fourteenth aspect provides a communication device, the communication device comprising: at least one processor and a communication interface, the communication interface is used for the communication device to perform information interaction with other communication devices, when a program instruction is in the When executed in at least one processor, the communication apparatus is made to implement the function of the second device above.
  • the communication interface may be a transceiver, circuit, bus, module, pin or other type of communication interface.
  • the communication device further includes a memory, the memory is used to store instructions and data, and when the processor executes the instructions stored in the memory, it can implement the second aspect or any one of the possibilities of the second aspect.
  • the method described in the implementation manner of the third aspect, or the method described in any possible implementation manner of the third aspect or the third aspect is implemented.
  • a fifteenth aspect provides a communication device, the communication device includes: at least one processor and a communication interface, the communication interface is used for the communication device to perform information interaction with other communication devices, when a program instruction is in the When executed in at least one processor, the communication apparatus is made to implement the function of the third-party device above.
  • the communication interface may be a transceiver, circuit, bus, module, pin or other type of communication interface.
  • the communication device further includes a memory, the memory is used for storing instructions and data, and when the processor executes the instructions stored in the memory, it can implement the fifth aspect or any one of the fifth aspects.
  • the memory is used for storing instructions and data, and when the processor executes the instructions stored in the memory, it can implement the fifth aspect or any one of the fifth aspects. The method described in the implementation of .
  • a sixteenth aspect provides a communication device, the communication device comprising: at least one processor and a communication interface, the communication interface is used for the communication device to perform information interaction with other communication devices, when a program instruction is in the When executed in at least one processor, the communication apparatus is made to realize the function of the above fourth device, or to realize the function of the second device in the above sixth aspect.
  • the communication interface may be a transceiver, circuit, bus, module, pin or other type of communication interface.
  • the communication device further includes a memory, where the memory is used to store instructions and data, and when the processor executes the instructions stored in the memory, the above-mentioned sixth aspect to the eighth aspect or the sixth aspect to the The method described in any possible implementation manner of the eighth aspect.
  • a seventeenth aspect provides a chip system, where the chip system includes a processor for the first device to implement the functions involved in the first aspect or any possible implementation manner of the first aspect, or for The first device implements the functions involved in the fourth aspect or any possible implementation manner of the fourth aspect, or is used for the first device to implement the sixth aspect or any possible implementation manner of the sixth aspect.
  • the functions involved for example, generating, receiving, sending, or processing data and/or information involved in the above methods.
  • the chip system further includes a memory for storing necessary program instructions and data of the first device.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • An eighteenth aspect provides a chip system, where the chip system includes a processor, for the second device to implement the functions involved in the second aspect or any possible implementation manner of the second aspect, or for The terminal device implements the functions involved in the third aspect or any possible implementation manner of the third aspect, for example, generating, receiving, sending, or processing the data and/or information involved in the aforementioned method.
  • the chip system further includes a memory for storing necessary program instructions and data of the network device.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • a nineteenth aspect provides a chip system
  • the chip system includes a processor for a third-party device to implement the functions involved in the fifth aspect or any possible implementation manner of the fifth aspect, for example, generating , receive, send, or process data and/or information involved in the above methods.
  • the chip system further includes a memory for storing necessary program instructions and data of the network device.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • a chip system in a twentieth aspect, includes a processor, and is used by the fourth device to implement any possible implementation manner of the seventh aspect to the eighth aspect or the seventh aspect to the eighth aspect
  • the functions involved for example, generating, receiving, sending, or processing data and/or information involved in the above methods.
  • the chip system further includes a memory for storing necessary program instructions and data of the network device.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • a twenty-first aspect provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program runs on a computer, the computer is made to execute the first aspect or the first aspect above.
  • the method described in any of the possible implementations of the aspect, or the computer is made to execute the method described in the fourth aspect or any of the possible implementations of the fourth aspect.
  • a twenty-second aspect provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program runs on a computer, the computer causes the computer to execute the second aspect or the first
  • the method described in any of the possible implementations of the second aspect, or the computer is made to execute the method described in the third aspect or any of the possible implementations of the third aspect.
  • a twenty-third aspect provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program runs on a computer, the computer causes the computer to execute the fifth aspect or the first The method described in any one possible implementation manner of the five aspects.
  • a twenty-fourth aspect provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program runs on a computer, the computer is made to execute the sixth aspect or the sixth aspect above.
  • a twenty-fifth aspect provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program runs on a computer, the computer is made to execute the seventh aspect or the first The method described in any of the possible implementations of the seventh aspect, or the computer is made to execute the method described in the eighth aspect or any of the possible implementations of the eighth aspect.
  • a twenty-sixth aspect provides a computer program product comprising instructions that, when the computer program product runs on a computer, cause the computer to execute the method described in the first aspect or any possible implementation manner of the first aspect , or cause the computer to execute the method described in the fourth aspect or any possible implementation manner of the fourth aspect.
  • a twenty-seventh aspect provides a computer program product containing instructions, which, when the computer program product is run on a computer, causes the computer to execute the method described in the second aspect or any possible implementation manner of the second aspect , or cause the computer to execute the method described in the third aspect or any possible implementation manner of the third aspect.
  • a twenty-eighth aspect provides a computer program product comprising instructions, which, when the computer program product is run on a computer, causes the computer to execute the method described in the fifth aspect or any possible implementation manner of the fifth aspect .
  • a twenty-ninth aspect provides a computer program product comprising instructions, which, when the computer program product is run on a computer, causes the computer to execute the method described in the sixth aspect or any possible implementation manner of the sixth aspect .
  • a thirtieth aspect provides a computer program product comprising instructions, which, when the computer program product is run on a computer, causes the computer to execute the method described in the seventh aspect or any possible implementation manner of the seventh aspect, Or cause the computer to execute the method described in the eighth aspect or any of the possible implementation manners of the eighth aspect.
  • a thirty-first aspect provides a system including the device described in the ninth aspect, the device described in the tenth aspect, and the device described in the eleventh aspect; or the communication system includes the communication device described in the thirteenth aspect, The communication device described in the fourteenth aspect and the communication device described in the fifteenth aspect.
  • FIG. 1 is a schematic diagram of an application scenario of an embodiment of the present application.
  • FIG. 2 is a schematic flowchart of an application method for an identity credential provided by an embodiment of the present application
  • FIG. 3 is a schematic flowchart of a method for applying for an identity credential provided by another embodiment of the present application.
  • FIG. 4 is a schematic flowchart of an application method for an identity credential provided by another embodiment of the present application.
  • FIG. 5 is a schematic flowchart of an identity authentication method provided by an embodiment of the present application.
  • FIG. 6 is a schematic flowchart of an identity authentication method provided by another embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of a first device provided by an embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • FIG. 9 is a schematic structural diagram of a second device provided by an embodiment of the present application.
  • FIG. 10 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of a third-party device provided by an embodiment of the present application.
  • FIG. 12 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of a second device provided by an embodiment of the present application.
  • FIG. 14 is a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • FIG. 15 is a schematic structural diagram of a first device provided by an embodiment of the present application.
  • 16 is a schematic structural diagram of a second device provided by an embodiment of the present application.
  • FIG. 17 is a schematic structural diagram of a fourth device provided by an embodiment of the present application.
  • Public key cryptography also known as asymmetric cryptography, is a type of cryptographic algorithm that requires two separate keys, one of which is a secret private key (private key) and the other is a public key (public key). The two parts of the public and private keys are mathematically linked.
  • the public key is used to encrypt plaintext or verify digital signatures; the private key is used to decrypt ciphertext or create digital signatures.
  • digital signature A mathematical scheme used to demonstrate the authenticity of a digital message or document. A valid digital signature allows the recipient to determine that the message was created by a known sender (authentication), and the sender cannot deny that the message was signed (non-repudiation). At the same time verifying the digital signature also confirms that the message has not been altered in transit (integrity).
  • Certificate and certificate authority (certificate authority, CA):
  • the certificate authority CA center is the entity that issues digital certificates.
  • a digital certificate certifies ownership of a public key through the specified subject of the certificate. This allows other (relying parties) to rely on signatures or assertions about the private key corresponding to the authentication public key.
  • a CA is a trusted third party, trusted by the subject (owner) of the certificate and the party that relies on the certificate.
  • Many public key infrastructure (PKI) schemes use CAs.
  • the sender performs HASH operation on the original text to be transmitted to obtain a digital digest; 2) The sender uses its own private key to encrypt the digital digest, and the encrypted digital digest is the signature 3) The sender sends the original text and the digital signature to the receiver; 4) The receiver uses the sender's public key to decrypt the signature to obtain a digital digest; 5) The receiver uses the same method as the sender to calculate the digest value of the original text, and compares it with The digital digests obtained by decryption are compared, and the two are completely consistent, which proves that the original text has not been tampered with during the transmission process.
  • Symmetric encryption also known as private key encryption, refers to an encryption algorithm that uses the same key for encryption and decryption.
  • the sender processes the plaintext and the encryption key together with a special encryption algorithm to turn it into a complex encrypted ciphertext and sends it to the receiver.
  • the receiving end After the receiving end receives the ciphertext, it needs to decrypt the ciphertext using the used encryption key and the inverse algorithm of the same algorithm, so as to restore it to readable plaintext.
  • the sender and receiver agree on an encryption key prior to secure communication.
  • Identity authentication Also known as “verification” and “authentication”, it refers to the confirmation of the user's identity through certain means.
  • GSM global system of mobile communication
  • CDMA code division multiple access
  • WCDMA wideband code Wideband code division multiple access
  • GPRS general packet radio service
  • long term evolution long term evolution
  • LTE long term evolution
  • FDD frequency division duplex
  • TDD LTE time division duplex
  • UMTS universal mobile telecommunication system
  • WiMAX worldwide interoperability for microwave access
  • 5G fifth generation
  • 5G mobile communication system
  • NR new radio
  • NB-IoT narrowband internet of things
  • eMTC enhanced machine-type communication
  • LTE-machine-to-machine LTE-M
  • future sixth-generation mobile communication systems etc.
  • FIG. 1 shows a schematic diagram of an application scenario of an embodiment of the present application.
  • the application scenario may include a third-party device 110 and multiple devices 120 that can communicate with each other, wherein the third-party device 110 can issue identity credentials (eg, digital certificates for the multiple devices 120 that can communicate with each other) or public key credentials, which are used to identify the device identity), so that a secure and trusted session channel can be established between the multiple devices 120 that can communicate with each other, and distributed capabilities can be provided for mutual data transmission.
  • identity credentials eg, digital certificates for the multiple devices 120 that can communicate with each other
  • public key credentials which are used to identify the device identity
  • the third-party device 110 is a device trusted by the plurality of devices 120 that can communicate with each other.
  • the third-party device 110 may be a cloud server, and can issue identity credentials for multiple devices 120 that log in or bind cloud service accounts.
  • the third-party device 110 may be a common server, such as an application server, a website server, a database server, an email server, etc., and can issue identity credentials for multiple devices 120 that log in to the same account or log in to an associated account.
  • the multiple devices 120 that can communicate with each other can authenticate the identity of the peer before communication based on the identity credentials issued by the third-party device 110, and then establish a secure and reliable session channel based on the authenticated identity after the authentication is completed.
  • the above-mentioned process of issuing identity credentials for multiple devices 120 by the third-party device 110 is the process of establishing the trusted identity of the devices.
  • a trusted identity such as the cloud service account identity, application account identity, website account identity, email account identity, and associated account identity mentioned above.
  • the following takes the trust basis of the trusted identity as the cloud service account identity as an example to exemplarily describe the process of establishing the trusted identity of the device and the identity authentication process between the devices.
  • the figure exemplarily shows that the multiple devices 120 that can communicate with each other include two devices, that is, a device 121 and a device 122 , wherein both the device 121 and the device 122 can log in to the same cloud service account.
  • the third-party device 110 may be a cloud server, which may be used for identity credential management. Taking the device 121 as an example, in the cloud service scenario, after the device 121 logs in to the account, it can apply to the third-party device 110 for an identity credential for identifying the identity of the device (ie, the device 121 ).
  • the identity credential includes the device identity public key corresponding to the identity credential of the device 121, and the device 121 saves the device identity private key corresponding to the identity credential.
  • the device 122 logs in to the same account, it can also apply to the third-party device 110 for an identity credential for identifying the identity of the device 122, and the identity credential is also signed by the private key of the third-party device 110.
  • the device identity public key corresponding to the identity credential of the device 122 is included, and the device 122 stores the device identity private key corresponding to the identity credential. As shown by the dotted line in Figure 1, it represents the process of registering identity credentials for the device.
  • both parties need to authenticate the identity of the other party.
  • Device 121 and device 122 exchange their respective identity credentials, and use the public key corresponding to the private key used by the third-party device 110 for signing to verify the other party's identity. Integrity and legitimacy of identity credentials.
  • the device 121 and the device 122 negotiate based on the device identity private key corresponding to the identity credential of the device and the device identity public key corresponding to the identity credential of the opposite end to establish a session key, and then a secure session channel can be established.
  • the solid line in Figure 1 is used to represent the process of identity authentication between devices.
  • the third-party device 110 in this embodiment of the present application may be a terminal device or a server, which can be trusted by some other devices, and can issue identity credentials for it.
  • the third-party device 110 may be a cloud server, an application server (eg, a dedicated application server, a distributed application server, a peer-to-peer application server, etc.), a communication server (eg, a mail server, a fax server, a file transfer protocol, FTP) server, etc.), website server, database server, etc., and can also be a workgroup-level server, a department-level server, an enterprise-level server, and the like.
  • the device 120 for applying for a registration identity credential in this embodiment of the present application may refer to a user equipment (user equipment, UE), an access terminal, a terminal, a subscriber unit, a subscriber station, a mobile station, a mobile station, a remote station, a remote terminal, and a mobile device , user terminal, wireless network equipment, user agent or user equipment.
  • UE user equipment
  • the device 120 may also be a cellular phone (cellular phone), a cordless phone, a session initiation protocol (SIP) phone, a smart phone (smart phone), a wireless local loop (WLL) station, a personal digital processor ( personal digital assistant, PDA), handheld devices with wireless communication capabilities, computing devices or other devices connected to wireless modems, in-vehicle devices, wearable devices, drone devices or the Internet of Things, terminals in the Internet of Vehicles, and future networks Any form of terminal, relay user equipment, or a terminal in a public land mobile network (public land mobile network, PLMN) that evolves in the future, etc., are not limited in this embodiment of the present application.
  • PLMN public land mobile network
  • the third-party device 110 may also be referred to as an issuing device, and the device 120 that applies for a registration identity credential from the issuing device may be referred to as an application device.
  • the applicant device needs to provide its own device identity public key to the issuing device, and save the device identity private key corresponding to the device identity public key.
  • the prior art provides two methods of registering identity credentials.
  • One way is that after the application device submits the identity credential application information (for example, including the application device's device information, public key information, account information, etc.) to the issuing device, the issuing device can issue the identity credential for the application device.
  • the private key in the public-private key pair used to ensure the security of the registration process is preset on the application device, and the application device uses the private key to sign the identity credential application information before submitting it to the issuing device.
  • the device verifies the identity credential application information using the public key corresponding to the private key that applies for the device signature, and issues an identity credential to the application device after passing.
  • the former has no restrictions on the device that initiates the identity credential registration request, and the issuing device does not verify whether the identity credential application information comes from a legitimate device, so for some devices with limited resources (such as low security storage performance, no security environment) In other words, it cannot guarantee that the identity credential application information submitted to the issuing device is authentic. In this way, the registration process of applying for the device can be infinitely copied to other malicious devices, so that the malicious device can complete the registration of the identity credential when it has the application information for the identity credential.
  • the latter limits the scope of devices for registering identity credentials to devices with a secure environment, which improves the security of the registration process of identity credentials, but this method requires the private key to be preset on the application device to ensure the security of the registration process.
  • the embodiments of the present application provide a method for applying for an identity credential, which can improve the security of the process of registering an identity credential of a device, and can improve the coverage of the authentication device.
  • the first device is a device that requests to register an identity credential, and may also be referred to as an application device in this embodiment of the present application.
  • the first device is a resource-constrained device or a device without a secure environment (or referred to as a non-secure environment device).
  • the resource limitation of the first device can be understood as the fact that the first device cannot apply for registration identity credentials by itself, for example, the first device has low security storage performance, or cannot actively prove its identity, or cannot prove that the information it sends to the other party is true.
  • the first device has no security environment. It can be understood that the first device cannot provide sufficient security protection during the life cycle of the public key password corresponding to the device identity credential.
  • the first device After the first device generates the device identity public and private key pair, the first device registers the identity During the credential process, it cannot guarantee that the information sent to the other party (such as public key information, device information, etc.) will not be tampered with, or in the process of maintaining the identity credential, it cannot guarantee that the identity credential will not be stolen, or when the first device is in contact with other There is no guarantee that the identity credentials will not be tampered with when devices exchange identity credentials for authentication, etc.
  • the identity credential such as public key information, device information, etc.
  • the second device is a device that has registered an identity credential, that is, a device that has established a trusted relationship, and may also be referred to as a proxy device in this embodiment of the present application.
  • the second device may be a device with sufficient resources or a device with a secure environment (or referred to as a device in a secure environment), or may be a device with limited resources or a non-secure environment.
  • the sufficient resources of the second device can be understood as the fact that the second device can directly apply to the issuing device for registration identity credentials, for example, the second device has high security storage performance, or can prove its identity, or can prove the information sent to the other party. reality.
  • the fact that the second device has a security environment can be understood as the fact that the second device can provide sufficient security protection during the life cycle of the public key password corresponding to the device identity credential.
  • the credential process it can ensure that the information sent to the other party will not be tampered with, or in the process of maintaining the identity credential, it can ensure that the identity credential will not be stolen, or when the second device exchanges the identity credential with other devices for identity authentication It can guarantee that identity credentials will not be tampered with, etc.
  • the understanding of the resource-limited or non-secure environment of the second device is similar to the above-mentioned first device resource-limited or non-secure environment. For details, reference may be made to the above description, which is not repeated for brevity.
  • the second device is a device that has been issued an identity credential by a third-party device.
  • a third-party device is a device trusted by other devices (such as the subject (owner) of the identity credential and a party relying on the identity credential) and capable of issuing the device identity credential, which may also be referred to as an issuing device in this embodiment of the present application.
  • the issuing device needs to verify whether the registration application comes from a legitimate device, that is, to verify whether the identity credential application information uploaded by the application device has integrity protection.
  • the device 122 can be the first device, requesting to register the identity credential; the device 121 can be the second device, which has already registered the identity credential; the third-party device 110 is the third-party device, which is used to issue the identity Credentials.
  • the first device 122 and the second device 121 may authenticate and communicate with each other based on accounts.
  • the first device 122 and the second device 121 may be devices that log in to the same account, or the second device 121 may be a device that logs in to the account.
  • the first device 122 is the device to which the account is bound.
  • the first device 122 may or may not be connected to the network, which is not limited in this embodiment of the present application.
  • Device identity public key cryptography also known as device identity public-private key pair, is generally used in the authentication process between devices to prove device identity.
  • the device identity public-private key pair includes the device identity public key and the device identity private key.
  • the device identity private key is kept privately by the device itself and cannot be disclosed, while the device identity public key can be included in the device identity credentials.
  • each device Before registering identity credentials, each device can generate its own device identity public-private key pair, and needs to submit the device identity public key to the issuing device for issuing identity credentials.
  • the embodiments of the present application relate to the device identity public-private key pair of two devices, which are respectively the device identity public-private key pair of the first device generated by the first device and the device identity public-private key pair of the second device generated by the second device.
  • the public key cryptography of the third-party device also called the public-private key pair of the third-party device, includes the private key of the third-party device and the public key of the third-party device.
  • the private key of the third-party device is kept privately by the third-party device, and is generally used to create a digital signature when issuing identity credentials for other devices; the public key of the third-party device can be located in the device with the identity credentials issued by the third-party device, and is generally used for Verify identity credentials when authenticating between devices.
  • the registration service public key password also known as the registration service public-private key pair, is used to protect the integrity of the application information submitted by the application device in the identity credential registration process to ensure the security of the registration identity credential process.
  • Registration service public key cryptography includes registration service public key and registration service private key, where registration service public key is pre-installed in the device that issues identity credentials (such as a third-party device), and registration service private key is pre-installed in devices that require registration identity credentials (eg second device).
  • identity credentials such as a third-party device
  • registration service private key is pre-installed in devices that require registration identity credentials (eg second device).
  • FIG. 2 shows a schematic flowchart of a method for applying for an identity credential provided by an embodiment of the present application.
  • the method 200 in FIG. 2 can be performed by a first device such as the device 122 in FIG. 1 , a second device such as the device 121 in FIG. 1 , and a third-party device such as the third-party device 110 in FIG. Step S260.
  • step S210 the first device sends a first message to the second device.
  • the first message includes identity credential application information of the first device, and the identity credential application information of the first device can be used to apply for an identity credential of the first device.
  • the identity credential application information of the first device may include at least one of the following information: the device identification of the first device, the device identification public key of the first device, the account identification of the account logged in by the first device, the first device identification The account login credentials of the account logged in to the device.
  • the device identifier of the first device may be a device address (eg, an IP address) of the first device, a device ID, a device label (label), and the like.
  • the device identity public key of the first device and the device identity private key corresponding to the public key are a pair of public and private keys, and are generated by the first device.
  • the private key of the device identity of the first device is stored confidentially by the first device, and the public key of the device identity of the first device needs to be provided to the device that issued the identity credential.
  • the device identity public-private key pair of the first device is used to prove the device identity of the first device.
  • the account identifier of the account logged in the first device may be an account index (user ID, UID), an account name, a subscriber identity module (SIM) number associated with the UID, other application account IDs associated with the UID, and the like.
  • the account identifier may be obtained after the first device logs in to the account or binds the account.
  • the account login credentials of the account logged in by the first device can be obtained after the first device logs in to the account or binds the account.
  • the account login credentials can prove that the first device is logged in or bound to the account, and is used to prove the validity of the first device login account. .
  • the first device may directly send the information in the identity credential application information of the first device to the second device.
  • the first device may splicing pieces of information in the identity credential application information of the first device before sending it to the second device.
  • the first device may encrypt various pieces of information in the identity credential application information of the first device before sending it to the second device. For example, in a scenario where the first device and the second device log into the same account, the first device may use the account login credentials to symmetrically encrypt other information, and correspondingly, the second device may use the account login credentials to decrypt.
  • step S220 the second device signs the identity credential application information of the first device using the private key of the second device, or encrypts the identity credential application information of the first device with a symmetric key, to obtain processed identity credential application information .
  • the private key of the second device may be the registration service private key of the second device, or the device identity private key of the second device.
  • the registration service private key of the second device and the registration service public key corresponding to the private key are a public-private key pair, which are used to ensure the security of the process of registering the identity credential of the second device.
  • the private key of the registration service of the second device may be preset on the production line of the second device, or obtained through an application.
  • the registration service public key is stored in the third-party device.
  • the third-party device that issues identity credentials, there may be only one pair of registration service private key and registration service public key.
  • the third-party device stores the registration service public key, and the device that registers the identity credentials stores the registration service private key. If multiple devices can apply for registration identity credentials from a third-party device, the multiple devices can store the same registration service private key.
  • the registration service private key of the second device is only used to indicate that the second device has the registration service private key, and does not limit the one-to-one correspondence between the second device and the registration service private key.
  • the device identity private key of the second device and the device identity public key corresponding to the private key are a pair of public and private keys, which are generated by the second device.
  • the private key of the device identity of the second device is kept secret by the second device, and the public key of the device identity of the second device needs to be provided to the device that issued the identity credential during the process of registering the identity credential. Therefore, the device identity public key of the second device can be included in the identity credential of the second device, and can also be stored in the third-party device that issued the identity credential.
  • the device identity public-private key pair of the second device is used to identify and prove the device identity of the second device.
  • the symmetric key used by the second device for encryption may be preset in the second device, or may be sent by the third-party device to the second device after the second device establishes a trusted relationship with the third-party device. of. It should be understood that the establishment of a trusted relationship between the second device and the third-party device can be understood as the second device completes the registration process of the identity credential of the second device, and the third-party device issues the identity credential for the second device.
  • the second device may save part or all of the information in the identity credential application information of the first device, for example, save the device identification of the first device, the device identity public key of the first device, the first device At least one item of information from the account identifier of the logged-in account, the account login credentials of the logged-in account of the first device, and the like.
  • the second device may generate and save a signed or encrypted record for the identity credential information of the first device, and in some embodiments, the record may also be referred to as an identity credential proxy application record.
  • the second device may generate an identification ID, which is used to identify the proxy application record this time.
  • the proxy application record may include part or all of the information in the identity credential application information of the first device, which is used to indicate that the second device has applied for an identity credential as a proxy for the first device. That is, the proxy application record is used to instruct the second device to sign the identity credential application information of the first device, or to instruct the second device to encrypt the identity credential application information of the first device.
  • the second device may generate a usage policy corresponding to the identity credential of the first device, and the usage policy may be used to indicate valid information of the identity credential of the first device.
  • the usage policy may include at least one of the following information: the validity period of the identity credential of the first device, the number of valid authentication times of the identity credential of the first device, the authentication correspondence of the identity credential of the first device, and the like.
  • the authentication corresponding relationship of the identity credential of the first device may include any of the following: the first device can only perform identity authentication with the second device, that is, the proxy device; the first device can perform identity authentication with any device; the first device can perform identity authentication with any device; The second device and the fourth device mutually trusted with the second device perform identity authentication; the first device can perform identity authentication with the second device and the fourth device mutually trusted with the third-party device; the first device can perform identity authentication with the second device, The device mutually trusted with the second device and the device mutually trusted with the third-party device perform identity authentication.
  • the algorithm used for the second device signature may be an RSA algorithm, a digital signature algorithm (DSA), an elliptic curve digital signature algorithm (elliptic curve DSA, ECDSA), etc., which are not limited in the embodiments of the present application.
  • DSA digital signature algorithm
  • ECDSA elliptic curve digital signature algorithm
  • the encryption algorithm used by the second device may be a data encryption standard (DES) algorithm, a triple data encryption standard (TDEA) algorithm, an international data encryption algorithm (IDEA), a Blowfish algorithm , RC5 algorithm, etc., which are not limited in this embodiment of the present application.
  • DES data encryption standard
  • TDEA triple data encryption standard
  • IDEA international data encryption algorithm
  • Blowfish algorithm Blowfish algorithm
  • RC5 RC5 algorithm
  • step S230 the second device sends a second message to the first device.
  • the second message includes the processed identity credential application information obtained in step S220.
  • the second message may further include device identity information of the second device.
  • the device identity information of the second device can be used to sign or encrypt the identity credential application information for identifying the second device as the first device, that is, it can identify the second device as an agent for the first device to apply for an identity credential. It should be understood that when the second device signs or encrypts the identity credential application information of the first device, it can be used to prove to the issuing device that the registration information of the first device has not been tampered with during the submission process. Since the second device has registered the identity credential, the second device and the third-party device are mutually trusted. In the embodiment of this application, "the second device acts as an agent for the first device to apply for an identity credential" can be understood as the third-party device issuing an identity credential for the first device based on the trust of the second device.
  • the device identity information of the second device may include at least one of the following information: the device identification of the second device, the device identification public key of the second device, the account identification of the account logged in the second device, the account logged in the second device account login credentials, etc.
  • the second message may further include a usage policy of the identity credential of the first device.
  • the usage policy generated by the second device in step S220 is used to notify the first device of the valid information and authentication information of its identity credential, wherein the valid information includes, for example, the validity period of the identity credential, the number of valid authentication times, etc. Examples include which devices the identity credential can be recognized or authenticated by.
  • the second device may save a usage policy corresponding to the identity credential of the first device, so as to confirm whether the identity credential of the first device is valid, or determine whether the identity credential of the first device is valid or not when authenticating with the first device. The device is authenticated.
  • whether the identity credential of the first device is valid can be understood as whether the identity credential of the first device conforms to the usage policy corresponding to the identity credential of the first device, for example, the identity credential of the first device. Whether it is within the validity period, whether the identity credential of the first device has valid authentication times, etc. In other words, whether the identity credential of the first device is valid in the embodiments of the present application refers to whether the identity credential of the first device still satisfies the corresponding usage policy, that is, whether the first device can also conduct communication with other devices based on the identity credential. Authentication.
  • the second device may sign the above-mentioned device identity information of the second device and/or the usage policy of the identity credential of the first device, etc., and then send it to the first device.
  • the second device there are multiple ways for the second device to sign the information in the second message.
  • the second device may respectively sign the identity credential application information of the first device, the device identity information of the second device, the usage policy of the identity credential of the first device, and the like.
  • the second device may sign the identity credential application information of the first device and the device identity information of the second device, and may or may not sign the usage policy of the identity credential of the first device.
  • the second device may sign the identity credential application information of the first device, the device identity information of the second device, and the usage policy of the identity credential of the first device once.
  • the second message may further include the identity credential application information of the first device sent by the first device in step S210. That is, in step S230, the second device sends the original text of the identity credential application information of the first device together with the signed identity credential application information to the first device.
  • the manner in which the second device encrypts the information in the second message is similar to that of signing, except that the signature behavior is replaced by encryption, which will not be repeated here.
  • step S240 the first device sends a third message to the third-party device.
  • the third message includes the processed identity credential application information obtained in step S230, where the processed identity credential application information is used to request the third-party device to register the identity credential of the first device.
  • the second device and the third-party device trust each other, that is, the second device has registered an identity credential in the third-party device.
  • the third message may further include the device identity information of the second device and/or the usage policy of the identity credential of the first device received by the first device in step S230.
  • the third message further includes the identity credential application information of the first device before the signature.
  • the identity credential application information of the first device in the third message may be sent by the first device to the second device in step S210, or may be sent by the second device to the first device in step S230.
  • the first device can sign the original text of the identity credential application information of the first device and the second device after signing.
  • the identity credential application information is sent to the third-party device. If the second message in step S230 includes the original text of the identity credential application information of the first device, then in step S240, the first device may directly forward the second message sent by the second device to the third-party device.
  • step S250 the third-party device verifies the processed identity credential application information using the public key or symmetric key corresponding to the private key of the second device.
  • the third-party device verifies the processed identity credential application information using the registration service public key. If the second device uses the device identity private key to sign the identity credential application information of the first device, in this step, the third-party device uses the device identity public key to verify the signature of the processed identity credential application information. If the second device uses the symmetric key to encrypt the identity credential application information of the first device, in this step, the third-party device uses the same key to decrypt the processed identity credential application information.
  • the second device and the third-party device can use one of the device identity public-private key pair and the registration service public-private key pair by default for signature and verification.
  • the second device may indicate in the third message which private key the third-party device uses to sign, so as to instruct the third-party device to use the corresponding public key to verify the signature.
  • including the device identifier of the second device in the third message may indicate that the second device uses the device identity private key for signing
  • not including the device identifier of the second device in the third message may indicate that the second device uses the registration service private key for signing. sign.
  • the second device and the third-party device may perform encryption and decryption in a symmetric encryption manner by default.
  • the integrity protection of the identity credential application information uploaded by the first device can be implemented.
  • the second device uses the device identity private key to sign, it can not only realize the integrity protection of the identity credential application information uploaded by the first device, but also enable the third-party device to determine whether the signature is created by the device that has registered the identity credential.
  • the second device uses a symmetric key for encryption, integrity protection of the identity credential application information uploaded by the first device can be implemented.
  • the signature of the identity credential application information of the first device by the second device may be used to prove the integrity of the information sent by the first device for registering the identity credential, thereby improving the security of the identity credential registration process.
  • the third-party device can verify whether the signature on the identity credential application information of the first device is a legal signature of the second device that has registered the identity credential, and can also verify the integrity of the signature data.
  • the third-party device can use its own symmetric key to decrypt the processed identity credential application information. If the decryption is successful, it means that the encryption key used by the second device is used for decryption with the third-party device. the same key.
  • the third-party device can also verify whether the account login credentials of the first device are valid. , for example, verifying whether the account login status of the first device is valid, etc.
  • step S260 after the processed identity credential application information is verified and passed, the third-party device issues an identity credential for the first device.
  • the identity credential of the first device may include identity credential application information of the first device.
  • the identity credential application information of the first device may be the same as the identity credential application information sent by the first device to the second device in step S210, or may include part of the information, such as the device identity public key of the first device, the device of the first device identification, etc.
  • the identity credential of the first device may also include other information, such as the information of the second device that applies for the identity credential as an agent for the first device, the purpose and source information of the identity credential of the first device, and the identity credential of the first device is a temporary identity Credential information, or the use policy of the identity credential of the first device (for example, the validity period, the number of valid authentication times, whether it can only be mutually authenticated with the second device) information, and the like.
  • the first device receives the identity credential sent by the third-party device, and can use the public key corresponding to the private key used to sign the identity credential by the third-party device to verify the identity credential. Save identity credentials issued by third-party devices.
  • the second device is preset with a registration service private key, a symmetric key, or an identity credential has been registered at the third-party device, so the second device and the third-party device are mutually trusted.
  • the first device cannot directly register the identity credential on the third-party device due to limited resources or no security environment. Since the device identity credential involves the storage and use of the key, considering the security protection of the key life cycle, the third-party issuing device has certain requirements for the device that registers the identity credential, and it is necessary to verify that the registration application comes from a legitimate device, and the uploaded application The information needs to be integrity protected, especially the public key bound to the device identity has not been tampered with.
  • the embodiment of the present application provides a method for applying for an identity credential by proxy, that is, signing or encrypting the identity credential application information of the first device through the second device, so as to ensure the security and integrity of the information sent by the first device to the third-party device sex.
  • the third-party device can issue an identity credential to the first device after passing the verification of the identity credential application information of the first device.
  • the second device which has a trust relationship with the issuing device, applies for the identity credentials of other devices that have a trust foundation with the second device. Insufficient, the risk of being unable to prove the integrity of identity credentials to third-party devices improves the security of device identity credential registration.
  • Other devices that have a foundation of trust with the second device although they cannot register identity credentials themselves, can request the second device to apply as an agent, which can increase the number of devices that can register identity credentials and improve the coverage of authentication devices.
  • the second device and the third-party device trust each other, because the second device needs to complete the registration of the identity credential of the first device before the agent applies for the identity credential of the first device.
  • the identity credential of the second device may be applied by the second device autonomously, or may be applied by another device as an agent.
  • the application process is similar to the above steps S210 to S260. The following only briefly introduces the process of the second device independently applying for the identity credential, that is, the preprocessing stage of the application method for the identity credential provided by the embodiment of the present application.
  • the second device is preset with a registration service private key for ensuring the security of the registration process
  • the third-party device is preset with a public key corresponding to the registration service private key.
  • the second device signs the identity credential application information using the registration service private key, and sends the signed identity credential application information to the third-party device.
  • the identity credential application information of the second device is similar in content to the identity credential application information of the first device in the foregoing step S210, except that the specific information is used to describe the second device.
  • the identity credential application information of the second device includes information such as the device identification of the second device, the device identity public key of the second device, and the like.
  • the third-party device verifies the received identity credential application information using the registration service public key, and after verifying the integrity of the registration request, can issue an identity credential for the second device.
  • the third-party device can store related information of the second device, such as the device identification of the second device, the device identity public key of the second device, etc., and maintain the related information.
  • the private key of the third-party device is preset in the third-party device
  • the public key of the third-party device is preset in the second device
  • the third-party device signs the identity credential of the second device
  • the second device receives the identity credential
  • Use the public key of the third-party device to verify the signature of the identity credential, and the identity credential can be saved after the verification is passed. In this way, the process of registering the identity credential by the second device is completed.
  • the public key of the third-party device may be pre-installed in the second device during the production line, may also be sent to the second device through broadcast, or may be obtained through an application program, which is not limited in this embodiment of the present application. It should be understood that a device that issues an identity credential by a third-party device needs to obtain the public key of the third-party device through the above several methods, so as to verify the signature of the identity credential.
  • the third-party device when the third-party device issues the identity credential to the second device, the third-party device may also send a symmetric key to the second device, so that the second device can apply for the identity credential as an agent for other devices.
  • the second device can also use a preset symmetric key to encrypt the identity credential application information, and correspondingly, the third-party device uses the same key as the encryption key to decrypt, and then decrypts the decryption key.
  • the obtained information is verified, and if the verification is passed, an identity credential is issued for the second device.
  • the process of encrypting the second device and decrypting the third-party device is the same as that in the prior art, and will not be described in detail here.
  • FIG. 3 shows a schematic flowchart of another method for applying for an identity credential provided by an embodiment of the present application.
  • the method 300 in FIG. 3 can be performed by the first device, the second device and the third-party device, and the method 300 includes steps S310 to S360.
  • step S310 the first device sends a first message to the second device.
  • the first message includes identity credential application information of the first device, and the identity credential application information of the first device can be used to apply for an identity credential of the first device.
  • Step S310 is similar to step S210 in the method 200 , and the specific reference is made to the above description, which is not repeated here.
  • step S320 the second device signs the identity credential application information of the first device using the private key of the second device, or encrypts the identity credential application information of the first device with a symmetric key, to obtain a processed identity credential application information.
  • Step S320 is similar to step S220 in the method 200 , and the specific reference is made to the above description, which is not repeated here.
  • step S330 the second device sends a third message to the third-party device.
  • the third message includes the processed identity credential application information obtained in step S320, where the processed identity credential application information is used to request the third-party device to register the identity credential of the first device.
  • the second device and the third-party device trust each other.
  • the third message may also include device identity information of the second device.
  • the device identity information of the second device may include at least one of the following information: the device identification of the second device, the device identification public key of the second device, the account identification of the account logged in the second device, the account logged in the second device account login credentials, etc.
  • the third message may further include the identity credential usage policy of the first device, such as the validity period of the identity credential of the first device, the number of valid authentication times of the identity credential, and which devices the identity credential can be recognized or authenticated.
  • the identity credential usage policy of the first device such as the validity period of the identity credential of the first device, the number of valid authentication times of the identity credential, and which devices the identity credential can be recognized or authenticated.
  • the second device may save a usage policy corresponding to the identity credential of the first device, so as to confirm whether the identity credential of the first device complies with the usage policy when authenticating with the first device, or determine whether Authenticate with the first device.
  • the third message may further include the identity credential of the first device sent by the first device in step S310 Application Information. That is, in step S330, the second device sends the original identity credential application information of the first device and the identity credential application information signed by the private key of the second device to the third-party device together to apply for the identity credential as an agent for the first device.
  • step S340 the third-party device verifies the processed identity credential application information using the public key or symmetric key corresponding to the private key of the second device.
  • step S250 This step is similar to step S250 in the method 200 , and reference may be made to the above description for details, which will not be repeated here.
  • step S350 the third-party device sends a fourth message to the second device.
  • the fourth message includes the identity credential of the first device.
  • the identity credential of the first device may include identity credential application information of the first device.
  • the identity credential application information of the first device may be the same as the identity credential application information sent by the first device to the second device in step S310, or may include part of the information, such as the device identity public key of the first device, the device of the first device identification, etc.
  • the identity credential of the first device may also include other information, such as the information of the second device that applies for the identity credential as an agent for the first device, the purpose and source information of the identity credential of the first device, and the identity credential of the first device is a temporary identity Credential information, or the use policy of the identity credential of the first device (for example, the validity period, the number of valid authentication times, whether it can only be mutually authenticated with the second device) information, and the like.
  • step S360 the second device sends a fifth message to the first device.
  • the fifth message includes the identity credential of the first device obtained in step S340.
  • the second device forwards the identity credential issued by the third-party device for the first device to the first device.
  • method 300 is that in method 200, after the second device processes the identity credential application information, the first device initiates a registration request to the third-party device, and accordingly, the identity credential issued by the third-party device Send directly to the first device; and method 300 is that after the second device processes the identity credential application information, the second device initiates a registration request to the third-party device, and accordingly, the identity credential issued by the third-party device is first sent to the second device. , and then forwarded by the second device to the first device.
  • the method 300 may further include step S370, the second device saves the identity credential of the first device.
  • the identity credential of the first device may be included in the identity credential proxy application record.
  • step S370 may be performed after step S350, or may be performed after step S360, which is not limited in this embodiment of the present application.
  • the identity credential application information of the first device is signed or encrypted by the second device, so as to ensure the security and integrity of the information sent by the first device to the third-party device.
  • the third-party device can issue an identity credential to the first device after passing the verification of the identity credential application information of the first device.
  • the second device which has a trust relationship with the issuing device, applies for the identity credentials of other devices that have a foundation of trust with the second device, which can prove to the issuing device that the registration process of the device identity credentials has not been tampered with, and can ensure the security of the device identity credential registration.
  • Other devices that have a foundation of trust with the second device, although they cannot register identity credentials themselves, can request the second device to apply as an agent, which can increase the number of devices that can register identity credentials and improve the coverage of authentication devices.
  • the method for applying for an identity credential provided by an embodiment of the present application is described in more detail below with reference to FIG. 4 as an example and not a limitation.
  • the embodiments of the present application are described by taking the trust basis of the first device and the second device as the cloud service account identity, and the second device as an example of signing the application information for the identity credential of the first device.
  • the embodiments of the present application provide The method can also be applied to the scenario where the first device and the second device establish a trusted identity based on other trust foundations.
  • the method 400 shown in FIG. 4 includes steps S401 to S412.
  • the second device Before executing the method for applying for an identity credential provided by this embodiment of the present application, the second device needs to register the identity credential first. Specifically, after the second device logs in to the cloud service account, it can obtain the account ID and login credentials, and generate a device ID public-private key pair. The second device initiates an identity credential registration request, and sends identity credential application information to the device that issued the identity credential (ie, a third-party device). The third-party device issues identity credentials after verifying the integrity of the registration request. When the first device wants to register an identity credential, the following steps are performed.
  • step S401 the first device (ie, the application device) logs in to the cloud service account, and obtains the account identifier and account login credentials.
  • the account identifier acquired by the first device may be, for example, an account index UID, an account name, a SIM number associated with the UID, an ID of another application account associated with the UID, and the like.
  • step S402 the first device generates a device identity public and private key pair of the device.
  • the first device generates a public-private key pair for identifying the identity of the first device, that is, a public-private key pair of the device identity of the first device.
  • step S403 the first device generates an identity credential application request.
  • the identity credential application request may be carried in the first message in the above method 200 or method 300 .
  • the first device may generate the identity credential application request based on information such as the account identifier, the account login credential, the device identifier of the first device, and the device identity public key of the first device.
  • the first device may directly generate an identity credential application request without processing the above information, or splicing the above information to generate an identity credential application request, or encrypting the above information to generate an identity credential application request, which is not limited in this embodiment of the present application.
  • the difference between the first device and the second device in the embodiment of the present application is that the second device is preset with a registration service private key used to ensure the security of the registration process, so that the second device can register the identity credential with the second device.
  • the device's identity credential request request is signed, thereby ensuring the integrity of the information sent to the issuing device.
  • the first device does not have the registration service private key preset in the first device. Therefore, in this embodiment of the present application, an application request for the identity credential of the first device is sent to the second device that has registered the identity credential.
  • the application request for the identity credential of the first device is signed by the private key of the second device, thereby ensuring the integrity of the information in the process of requesting to register the identity credential of the first device.
  • the second device has registered the identity credential with the issuing device, so the second device and the issuing device trust each other.
  • step S404 the first device sends the generated identity credential application request to the second device.
  • step S405a the second device uses the private key of the device to sign the identity credential application request of the first device.
  • the second device may also add device information and the like of the second device to the request for applying for the identity credential of the first device. Therefore, step S405a can also be replaced with step S405b, in which the second device uses the private key of the device to sign the identity credential application request of the first device and the device information of the device.
  • the second device adds device information of the second device in the identity credential application request of the first device, which can be used to indicate whether the first device can only perform mutual authentication with the second device after acquiring the identity credential.
  • the second device may also add information such as a usage policy of the identity credential of the first device in the identity credential application request of the first device.
  • step S406 the second device generates an identity credential proxy application record.
  • the second device may generate a record identifier for identifying the proxy application for the identity credential this time, and save the relevant information of the application device, for example, in the application request for the identity credential of the first device obtained in step S404. information.
  • this step is an optional step. If the one-to-one authentication relationship between the proxy device and the application device is not limited, the second device may not save a record of signing the identity credential application request of the first device. However, it should be understood that the second device performs this step, and the authentication relationship of the one-to-one correspondence between the proxy device and the application device may not be limited.
  • step S407 the second device sends the signed identity credential application request to the first device.
  • the signed identity credential application request in this step may only be different in whether the private key of the second device is used for signing, but it may also exist in the signature data.
  • the second device may add the device information of the second device to the identity credential application request before signing before signing.
  • the information sent by the second device to the first device may be specifically determined according to steps S405a to S406.
  • the signed identity credential application request may be carried in the second message in the above method 200 .
  • step S408 the first device sends the signed identity credential application request and the unsigned identity credential application request to the third-party device (ie, the issuing device).
  • the third-party device ie, the issuing device.
  • the first device sends the signature and the original text separately, which can facilitate the third-party device to verify the signature.
  • the second device may also send the original text and the signature to the third-party device in the form of JWT, which is not limited in this embodiment of the present application.
  • the signed identity credential application request and the unsigned identity credential application request may be carried in the third message in the above method 200 .
  • step S409 the third-party device performs signature verification, which mainly includes verifying the validity of the signature, verifying the integrity of the signature data, and verifying the validity of the account login status of the first device.
  • the third-party device verifies the validity of the signature, which can be understood as the third-party device verifies whether the signature of the signed identity credential application request sent by the first device is the device that has registered the identity credential (that is, the second device). device) legal signature.
  • the second device has registered the identity credential of the second device on the third-party device, and the third-party device stores information such as the device identifier of the second device and the device identity public key of the second device.
  • the third-party device can use the stored device identity public key of the second device to verify the signature; if the second device uses the registered If the service private key is used to sign, the third-party device can use the registration service public key to verify the signature.
  • the second device may have unregistered identity credentials, but since the second device has the registration service private key, it can also be considered that the third-party device and the second device trust each other of.
  • the third-party device verifies the integrity of the signature data, which can be understood as the third-party device judging whether the data in the signature of the second device is consistent with the original text uploaded by the first device, and whether it has been tampered with.
  • the third-party device verifies the validity of the account login status of the first device. It can be understood that the third-party device needs to determine whether the first device has logged into the cloud service account, that is, to determine the validity of the account login of the first device. .
  • step S410 after signature verification, the third-party device uses the private key of the device to issue the identity credential of the first device.
  • the third-party device can use the private key of the third-party device to sign the identity credential application information and other related information of the first device, and issue it to the first device as an identity credential.
  • the identity credential application information of the first device may include part or all of the information in the identity credential application request submitted by the first device to the third-party device, such as the account identifier, the device identifier of the first device, the Device identity public key, etc.
  • Other relevant information in this embodiment of the present application may include information related to the proxy device, such as the device identifier of the second device, the device identity public key of the second device, and the identity credential used to indicate that the first device is the proxy application for the second device information, usage and source information for representing the identity credential of the first device, usage policy information for representing the identity credential of the first device (for example, the validity period of the identity credential, the number of valid authentication times of the identity credential, etc.), etc.
  • information related to the proxy device such as the device identifier of the second device, the device identity public key of the second device, and the identity credential used to indicate that the first device is the proxy application for the second device information, usage and source information for representing the identity credential of the first device, usage policy information for representing the identity credential of the first device (for example, the validity period of the identity credential, the number of valid authentication times of the identity credential, etc.), etc.
  • step S411 the third-party device issues an identity credential of the first device to the first device.
  • step S412 the first device verifies the identity credential issued by the third-party device, and saves the identity credential after the verification is passed.
  • the process of verifying the identity credential by the first device is to use the public key corresponding to the private key used by the third-party device to sign the identity credential to verify the identity credential to verify the legitimacy and validity of the identity credential. completeness.
  • the first device has limited resources or no security environment, and cannot apply for the registration identity credential by itself, while the second device has a sufficient security environment and can ensure the security of the process of registering the identity credential. Therefore, when the first device requests to communicate with the second device that has logged into the same cloud service account, the second device at the opposite end of the communication can issue an application request for the identity credential of the first device, that is, through the second device in the first device's The identity credential application request is signed to prove the integrity of the application information reported by the first device to the third-party device.
  • the second device can maintain the identity credential proxy application record locally, and after the first device obtains the identity credential issued by the third-party device, the second device can use the identity credential and the locally maintained proxy record to verify that the resources are limited or not.
  • the method 400 may further include step S413a, where the second device generates a usage policy of the identity credential of the first device.
  • step S413a the second device generates a usage policy of the identity credential of the first device.
  • the usage policy is used to indicate the valid information and authentication information of the identity credential of the first device, such as the validity period of the identity credential used, the number of valid authentications, whether it is in a one-to-one authentication relationship with the second device, and the like.
  • the use policy of the identity credential of the first device may also be generated by a third-party device, that is, step S413a may be replaced by step S413b.
  • step S413a may be replaced by step S413b.
  • This embodiment of the present application does not specifically limit the execution sequence of step S413b, and the third-party device may execute step S401 after step S411 and before step S411.
  • the first device may also send the identity credential issued by the third-party device to the second device, and accordingly, the second device may store the identity credential of the first device, and use It is used for subsequent device authentication.
  • the third-party device may also directly send the identity credential of the first device to the first device and the second device.
  • the registration process of the identity credential is directly ended.
  • the third-party device may send a registration failure or registration rejection message to the first device in step S411.
  • This embodiment of the present application does not specifically limit the execution order of the steps in the method 400. In some embodiments, some steps may be executed simultaneously or in reverse order, which may be determined according to the actual situation.
  • the method 400 in FIG. 4 is described by taking the process signed by the second device and the first device itself initiates the registration identity credential to the third-party device as an example.
  • the process of the credential process is similar and will not be described in detail here.
  • the first device After acquiring the identity credential, the first device can communicate with other devices based on the identity credential.
  • the first device can perform identity authentication with multiple devices, that is, the first device can communicate with any device that has a trust basis with the first device. For example, when the identity credential of the first device does not include the relevant information of the proxy device, other devices can perform identity authentication with the first device by default.
  • the first device may only perform identity authentication with the device that applies for the identity credential as an agent.
  • the identity credential of the first device includes relevant information of the proxy device, and other non-proxy devices may determine not to perform identity authentication with the first device according to the relevant information of the proxy device.
  • the proxy device can only authenticate the device for which the proxy has applied for identity credentials
  • the application device can only authenticate with the device for which the proxy device has applied for identity credentials.
  • the proxy device and the application device are in a one-to-one correspondence
  • the identity credential applied by the proxy device for the proxy device of the application device can only be used for the identity authentication between the application device and the proxy device, and Cannot be used for authentication with other devices.
  • the first device may separately request each device to apply for an identity credential for its proxy.
  • the identity credentials that multiple devices apply for the agent of the first device may be the same or different, which are not limited in this embodiment of the present application.
  • the device that applies for the identity credential as a proxy for the first device can save the proxy application record and/or the device identification of the first device and other information, and through these information, it can be determined whether the identity credential has been applied for the first device proxy, so as to determine whether it can communicate with the first device.
  • the device is authenticated.
  • the first device may perform identity authentication with the device that the proxy device applies for the identity credential and the device that is mutually trusted by the proxy device.
  • the identity credential of the first device includes relevant information of the proxy device, and other devices having a trust relationship with the proxy device can determine to perform identity authentication with the first device according to the relevant information of the proxy device. That is, other devices mutually trusted with the proxy device can perform identity authentication with the first device based on the trust in the proxy device.
  • mutual trust between other devices and the proxy device may be understood as that the other device and the proxy device have already performed identity authentication, or that the other device and the proxy device have identity credentials issued by the same third-party device.
  • the first device may perform identity authentication with the device that applies for the identity credential as an agent and the device that is mutually trusted with the device that issues the identity credential.
  • the identity credential of the first device includes the relevant information of the issuing device, and other devices that mutually trust the issuing device can determine that the identity credential is issued by a third-party device according to the identity credential of the first device, so as to determine that the first device has a Authentication. That is, other devices mutually trusted with the issuing device may perform identity authentication with the first device based on the trust in the issuing device.
  • the first device may perform identity authentication with a device that applies for an identity credential by an agent, a device that is mutually trusted with the agent device, and a device that is mutually trusted with the issuing device.
  • the identity credential of the first device includes the relevant information of the issuing device and the relevant information of the proxy device.
  • Other devices that trust each other with the issuing device can perform identity authentication with the first device based on the trust in the issuing device, and other devices can authenticate with the proxy device.
  • the mutually trusted devices may perform identity authentication with the first device based on trust in the proxy device.
  • the identity credentials of the first device are at risk of being stolen, when the identity credentials of the first device are copied to other malicious devices, these devices can communicate with legitimate devices based on the identity credentials. Authentication is performed and a session is established, so there is a security risk.
  • the proxy device and the application device are in a one-to-one correspondence, the authentication status of the application device can be controlled by the proxy device, thereby improving security.
  • the application device can perform identity authentication with at least one of the proxy device, the device that is mutually trusted with the proxy device, and the device that is mutually trusted with the issuing device, can control the authentication status of the application device, improve security, and also The coverage of authentication with the first device can be increased.
  • FIG. 5 shows a schematic flowchart of an identity authentication method provided by an embodiment of the present application.
  • the method 500 in FIG. 5 is mainly performed by the second device, and the second device may be, for example, the device 121 in FIG. 1 , that is, the device that applies for the identity credential as an agent for the first device above.
  • the method 500 may include steps S510 to S540.
  • step S510 the first device sends an identity authentication request to the second device.
  • the identity authentication request includes the identity credential of the first device and the device identification of the first device.
  • the device identification of the first device may include at least one of the following information: a device address, a device ID, and a device tag of the first device.
  • step S520 the second device determines, according to the device identification of the first device, that the identity credential of the first device is an agent application for the first device by the second device.
  • a specific implementation of this step may be: the second device queries the identity credential proxy application record corresponding to the first device according to the device identification of the first device; The record determines that the identity credential of the first device is an agent application of the second device for the first device.
  • the identity credential proxy application record is generated and saved when the second device registers the identity credential for the first device proxy, and is used to instruct the second device to apply for the identity credential for the first device proxy.
  • the proxy application record may include the device identifier of the first device, the device identity public key of the first device, the identity credential of the first device, and other information related to the identity of the first device.
  • step S530 the second device determines whether the identity credential of the first device conforms to the usage policy according to the usage policy corresponding to the identity credential of the first device.
  • the first device and the second device are in a one-to-one correspondence.
  • the first device needs to persistently store the identity credential and the private key corresponding to the identity credential within a certain period of time, so that when the first device initiates authentication, it does not need to repeatedly connect to the third-party server for application, and also considering that the resources of the first device are limited and
  • the second device may specify a usage policy of the identity credential of the first device when applying for the identity credential of the first device to indicate the valid information of the identity credential of the first device.
  • the second device determines whether the identity credential of the first device is valid (that is, whether it complies with the usage policy) according to the usage policy.
  • a device re-agent to apply for identity credentials, or refuses to authenticate with the first device.
  • step S540 if the identity credential of the first device complies with the usage policy, the second device performs validity and integrity verification on the identity credential of the first device.
  • the second device can use the public key of the device that issued the identity credential to verify the identity credential, so as to verify whether the identity credential was issued by the issuing device and whether the information was tampered with during the transmission of the identity authentication request.
  • the second device and the first device can perform session key negotiation.
  • This step is the same as the key negotiation process in the inter-device authentication process in the prior art, and is only briefly introduced below. Specifically, after the second device passes the identity credential verification of the first device, it sends its own identity credential to the first device, and the first device also verifies the identity credential of the second device using the public key of the issuing device. After the signature verification is passed, the first device and the second device perform key negotiation and establish a session key, and then a secure session channel can be established based on the session key for communication.
  • the method 500 further includes: the second device inquires, according to the device identification of the first device, a usage policy of the identity credential of the first device, where the usage policy is used to indicate valid information of the identity credential; according to the usage The policy determines whether the identity credentials of the first device need to be updated.
  • the identity credential of the first device is applied for by the second device agent, so a usage policy can be determined for the identity credential of the first device, and the usage policy can indicate the validity period of the identity credential of the first device or the number of valid authentication times .
  • the second device can determine whether the identity credential of the first device needs to be updated or whether the proxy application needs to be re-applied according to the usage policy, so as to improve the security of the identity credential maintenance process of the first device.
  • the identity authentication request sent by the first device to the second device includes the identity credential of the first device.
  • the device's identity credential includes device identity information of the second device.
  • the second device determines, according to the device identity information of the second device, that the identity credential of the first device is an agent application for the first device by the second device.
  • Steps S530 and S540 are as described above. That is to say, the second device can determine that it has applied for an identity credential for the first device agent according to the device identity information of the second device included in the identity credential of the first device.
  • the first device may perform identity authentication with the fourth device based on the identity credential applied by the second device as an agent.
  • the fourth device can be mutually trusted with the second device, or mutually trusted with the device that issued the identity credential.
  • the method 500 includes steps S501, S502a, and S503.
  • step S501 the first device sends an identity authentication request to the fourth device, where the identity authentication request includes the identity credential of the first device.
  • the identity credential of the first device includes device identity information of the second device.
  • step S502a the fourth device determines, according to the identity credential of the first device, that the identity credential of the first device is an agent application for the first device by the second device.
  • step S503 the fourth device determines whether to perform identity authentication with the first device according to a usage policy corresponding to the identity credential of the first device. Or in this step, the fourth device may determine to perform identity authentication with the first device.
  • the method 500 includes steps S501, S502b, and S503.
  • step S501 the first device sends an identity authentication request to the fourth device, where the identity authentication request includes the identity credential of the first device.
  • the identity credential of the first device includes the information of the issuing device, that is, the third-party device.
  • step S502b the fourth device determines, according to the identity credential of the first device, that the identity credential of the first device is issued to a third-party device.
  • the fourth device determines whether to perform identity authentication with the first device according to a usage policy corresponding to the identity credential of the first device. Or in this step, the fourth device may determine to perform identity authentication with the first device.
  • the first device sends an identity authentication request to the second device, and the identity credential in the identity authentication request includes device identity information of the second device.
  • the second device may determine, according to the device identity information of the second device, that the identity credential is an agent application of the second device, and the second device may determine to perform identity authentication with the first device.
  • the identity authentication method provided by the embodiment of the present application is described in more detail below with reference to FIG. 6 as an example and not a limitation.
  • the embodiments of this application are described by taking the trust basis of the first device and the second device as the cloud service account identity and the first device requesting identity authentication from the second device as an example, but as described above, the methods provided in the embodiments of this application can also be It is applied to the scenario where the first device and the second device establish a trusted identity based on other trust foundations.
  • the method 600 shown in FIG. 6 includes steps S601 to S609.
  • step S601 the first device sends an identity authentication request to the second device.
  • the first device and the second device log into the same cloud service account, and the first device initiates the same account authentication with the second device.
  • the identity authentication request is used to request identity authentication with the second device, and at the same time, the identity authentication request also requests the identity credential of the second device.
  • the identity authentication request includes the device identity of the first device and the identity credential of the first device.
  • step S602 after receiving the identity authentication request, the second device queries whether there is an identity credential proxy application record corresponding to the device identity according to the device identity of the first device.
  • the second device needs to confirm whether it has applied for an identity credential as an agent for the first device.
  • the proxy device signs the application information for the identity credential of the applicant device, that is, when the proxy device registers the identity credential as the proxy device for the application device, the proxy device can save the relevant information of the applied device, such as device identification, device identity public key and other information and generate identity credential proxy application records.
  • the relevant information of the applied device such as device identification, device identity public key and other information and generate identity credential proxy application records.
  • the application device ie, the first device
  • the proxy device ie, the second device
  • the second device needs to confirm whether it has applied for an identity credential as a proxy for the first device.
  • step S603 if there is an identity credential proxy application record, the second device determines whether the identity credential conforms to the usage policy according to a usage policy corresponding to the identity credential of the first device.
  • the usage policy of the identity credential of the first device is used to indicate valid information of the identity credential of the first device. For details, refer to the above related description, which is not repeated here for brevity.
  • the second device may consider that it has not applied for an identity credential as an agent for the first device, and the second device and the first device can perform identity authentication according to the existing process.
  • step S604 if the identity credential of the first device complies with the usage policy, the second device verifies the validity and integrity of the identity credential of the first device.
  • the second device may refuse to perform identity authentication with the first device, or the second device is the first device.
  • the device re-agent to request identity credentials.
  • step S605 after the verification is passed, the second device establishes a session key based on the device identity private key of the second device and the device identity public key of the first device.
  • step S606 the second device queries the use policy of the identity credential of the first device, and determines whether the identity credential of the first device needs to be updated before the next authentication.
  • the second device can update the locally maintained identity credential proxy application record according to the current authentication information, and determine the valid information of the identity credential of the first device, and determine whether to re-apply for the identity credential before the next identity authentication.
  • the second device may notify the first device that its identity credential is about to become invalid, and after this identity authentication process, the first device needs to re-proxy to apply for the identity credential.
  • step S607 the second device returns the identity credential of the second device to the first device.
  • the second device may notify the first device of the relevant information in this step.
  • step S608 after receiving the identity credential of the second device, the first device performs validity and integrity verification on the identity credential of the second device, and establishes a session key.
  • step S609 the first device and the second device complete identity authentication, and the devices can communicate.
  • the first device after the first device obtains the identity credential applied by the second device as an agent, it can also perform identity authentication with any other device with a trust basis, such as logging in to the same account, and the authentication process can be the same as the existing one. The process is the same and will not be repeated here.
  • the second device is used as an agent to apply for the identity credential of the first device, and the application device establishes a one-to-one trust relationship with the agent device, which can realize mutual authentication of the belonging accounts, and at the same time reduce the export and batch copying of authentication keys to malicious devices. risks of.
  • the second device performs identity authentication, different authentication and update policies can be matched by distinguishing whether the opposite end is a device that applies for identity credentials through a proxy or a device that does not apply for identity credentials through a proxy.
  • the process of applying for an identity credential and performing identity authentication by the first device through the agent of the second device is still described by taking the trust basis of the first device and the second device as cloud service account identities as an example.
  • the first device is referred to as an application device and the second device is referred to as an agent device in the following.
  • the whole process is mainly divided into three stages, which are described as follows.
  • the proxy device After the proxy device (such as the above-mentioned second device) logs in to the cloud service account, it obtains the account ID (user ID) and the account login credentials (Servicetoken), wherein the account ID is denoted as UID, and the account login credentials obtained by the proxy device are denoted as ST_A,
  • the account login information of the proxy device includes the account identifier UID and the account login credentials, so it can be recorded as (UID, ST_A).
  • the proxy device generates a device identity public and private key pair, denoted as (pk_A, sk_A).
  • the proxy device obtains the device ID of the device, which is recorded as deviceID_A.
  • the proxy device generates an identity credential application request according to the public key, device ID, and account ID in the device identity public-private key pair, which is recorded as
  • the agent device signs the identity credential application request ApplyInfo using the registration service private key (referred to as sk_register) preset in the production line, and obtains the signed identity credential application request, recorded as
  • the agent device uploads the identity credential application request ApplyInfo obtained in 4), the signed identity credential application request SignRegInfo and account login information (UID, ST_A) obtained in 5) to the issuing device.
  • the issuing device uses the preset device registration global public key (that is, the public key corresponding to the private key of the registration service, denoted as pk_register) to verify the validity of the signed identity credential application request SignRegInfo (that is, the validity and integrity of the signature). ); verify the validity of the account login information based on the account login information (UID, ST_A).
  • the issuing device issues the identity credential information, and the identity credential information of the proxy device is signed by the private key of the issuing device (denoted as sk_server), denoted as
  • DeviceAuthToken_A Sign(sk_server,UID
  • the proxy device stores the identity credential DeviceAuthToken_A signed by the issued device private key and the corresponding device identity private key sk_A.
  • the application device After the application device (for example, the above-mentioned first device) logs into the cloud service account, it obtains the account identification UID and the account login credentials, wherein the account login credentials obtained by the application device are recorded as ST_B.
  • the account login information of the application device includes the account identification UID and the account login credentials, so it can be recorded as (UID, ST_B).
  • the application device generates a proxy identity credential application request according to the public key, device ID, and account ID in the device ID public-private key pair, which is recorded as
  • RequestProxyInfo (UID
  • the application device signs the proxy identity credential application request RequestProxyInfo with the account login credential ST_B of the device, and obtains the proxy identity credential application request signed by the application device, which is recorded as
  • the application device sends the request for proxy identity credential before the signature of the application device obtained in 4) RequestProxyInfo and the request for proxy identity credential after the signature of the application device obtained in 5) SignRequestProxyInfo to the proxy device.
  • ProxyID an identifier that identifies this proxy application, to identify the device for this proxy application, and the proxy identity credential application request before the proxy device signature is recorded as
  • ProxyInfo (RequestProxyInfo
  • the proxy device uses the device identity private key sk_A of the device to issue the proxy identity credential application request before the proxy device signature, and obtain the proxy identity credential application request signed by the proxy device, record it as
  • the proxy device maintains the proxy application record generated in 7), that is, maintains the information of the proxy application identifier and the device identifier (ProxyID-deviceID_B) of the application device.
  • the proxy device determines and stores the use policy of the identity credential of the application device according to the security.
  • the proxy device returns the proxy identity credential application request ProxyInfo before the proxy device's signature, the proxy identity credential application request SignProxyInfo after the proxy device's signature, and the proxy device's device ID_A to the application device.
  • the application device uploads the proxy identity credential application request RequestProxyInfo obtained in 4) to the issuing device, the proxy identity credential application request SignProxyInfo signed by the proxy device received in 10), and the device ID_A, account number of the proxy device received in 10). Login information (UID, ST_B).
  • the issuing device issues the identity credential information, and the identity credential information of the application device is signed by the private key of the issuing device (denoted as sk_server), and the identity credential issued to the application device is obtained, denoted as
  • DeviceAuthToken_B Sign(sk_server,UID
  • the application device stores the identity credential DeviceAuthToken_B signed by the issued device private key and the corresponding device identity private key sk_B.
  • the application device sends the device identification deviceID_B of the application device, the device identity public key pk_B of the application device, and the identity credential DeviceAuthToken_B of the application device to the proxy device, which are used to request authentication.
  • Proxy application Query whether there is a proxy application record ProxyID locally according to the device identification UDID_B of the application device as an index. If there is, use the public key (referred to as pk_server) corresponding to the private key used to issue the device signature identity credential to verify the identity of the applicant device Integrity of credentials DeviceAuthToken_B.
  • pk_server public key
  • the proxy device After the identity credential verification is passed, the proxy device performs key negotiation based on the device identity public key pk_B of the applicant device and establishes a session key.
  • the proxy device sends the device identification deviceID_A of the proxy device, the device identity public key pk_A of the proxy device, and the identity credential DeviceAuthToken_A of the proxy device to the application device.
  • the applicant device verifies the integrity of the identity credential DeviceAuthToken_A of the proxy device using the public key (referred to as pk_server) corresponding to the private key used to issue the device signature identity credential.
  • pk_server public key
  • the application device After the identity credential verification is passed, the application device performs key negotiation based on the device identity public key pk_A of the proxy device and establishes a session key.
  • FIG. 7 is a schematic structural diagram of a first device provided by an embodiment of the present application.
  • the first device 700 in FIG. 7 may be a specific example of the device 122 in FIG. 1 .
  • the first device shown in FIG. 7 may be used to execute the method 200 shown in FIG. 2 , and may specifically implement the embodiment shown in FIG. 4 . To avoid redundancy, the description will not be repeated.
  • the first device 700 shown in FIG. 7 includes a sending module 710 and a receiving module 720 .
  • the sending module 710 is configured to send a first message to the second device, where the first message includes the identity credential application information of the first device.
  • a receiving module 720 configured to receive a second message sent by the second device, where the second message includes processed identity credential application information, wherein the processed identity credential application information is the identity of the first device
  • the credential application information is obtained after being signed by the private key of the second device, or obtained after being encrypted by a symmetric key.
  • the sending module 710 is further configured to send a third message to the third-party device, where the third message includes the processed identity credential application information, and the processed identity credential application information is used to send to the third-party device.
  • a device requests registration of the identity credentials of the first device, wherein the third-party device and the second device are mutually trusted.
  • the second message further includes: device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the identity credential application information of the first device includes at least one of the following information: a device identifier of the first device; a device identity public key of the first device; an account logged in by the first device The account identifier of the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device identity private key of the second device.
  • the third message further includes device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the first device is a device without a security environment or with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • the first device shown in FIG. 7 may be used to execute the method 300 in FIG. 3 , and the description will not be repeated to avoid redundancy.
  • the first device 700 shown in FIG. 7 includes a sending module 710 and a receiving module 720 .
  • the sending module 710 is configured to send a first message to the second device, where the first message includes the identity credential application information of the first device, and is used to request a third-party device to register the identity credential of the first device, wherein The second device and the third-party device trust each other.
  • a receiving module 720 configured to receive a fifth message sent by the second device, where the fifth message includes the identity credential of the first device, wherein the identity credential of the first device is verified by the third-party device
  • the processed identity credential application information is sent to the second device, the processed identity credential application information is obtained after the identity credential application information of the first device is signed by the private key of the second device , or encrypted with a symmetric key.
  • the identity credential application information of the first device includes at least one of the following information: a device identification of the first device; a device authentication public key of the first device; an account logged in by the first device The account identifier of the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device authentication private key of the second device.
  • the first device is a device without a security environment or with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • FIG. 8 is a schematic structural diagram of a communication apparatus provided by an embodiment of the present application.
  • the communication apparatus 800 in FIG. 8 may be a specific example of the device 122 in FIG. 1 .
  • the communication apparatus shown in FIG. 8 can be used for executing the method 200 in FIG. 2 or for executing the method 300 in FIG. 3 , and the description is not repeated to avoid redundancy.
  • the communication device may be the above-mentioned first device, or may be a device in the first device, or a device that can be matched and used with the first device.
  • the communication device may be a chip system.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • the communication apparatus 800 includes at least one processor 820, which is configured to implement the method provided by the embodiment of the present application. For details, refer to the detailed description in the method example, which is not repeated here.
  • Communication apparatus 800 may also include at least one memory 810 for storing program instructions and/or data.
  • Memory 810 and processor 820 are coupled.
  • the coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, which may be in electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • Processor 810 may cooperate with memory 820 .
  • Processor 810 may execute program instructions stored in memory 820 . At least one of the at least one memory may be included in the processor.
  • the communication apparatus 800 may also include a communication interface 830 for communicating with other devices through a transmission medium, so that the devices used in the communication apparatus 800 may communicate with other devices.
  • the communication interface may be a transceiver, circuit, bus, module, pin or other type of communication interface.
  • the communication apparatus 800 is a first device, and the other device is a second device or a third-party device.
  • the processor 820 uses the communication interface 830 to send and receive data, and is configured to implement the method executed by the first device in the embodiment corresponding to FIG. 2 or FIG. 3 .
  • the specific connection medium between the processor 820 and the memory 810 of the communication interface 830 is not limited in this embodiment of the present application.
  • the memory 810, the processor 820, and the communication interface 830 are connected through a bus 840 in FIG. 8 .
  • FIG. 9 is a schematic structural diagram of a second device provided by an embodiment of the present application.
  • the second device 900 in FIG. 9 may be a specific example of the device 121 in FIG. 1 .
  • the second device shown in FIG. 9 may be used to execute the method 200 shown in FIG. 2 , and may specifically implement the embodiment shown in FIG. 4 , and the description will not be repeated to avoid redundancy.
  • the second device 900 shown in FIG. 9 includes a receiving module 910 , a processing module 920 and a sending module 930 .
  • the receiving module 910 is configured to receive a first message sent by a first device, where the first message includes identity credential application information of the first device.
  • a processing module 920 configured to use the private key of the second device to sign the identity credential application information of the first device, or use a symmetric key to encrypt the identity credential application information of the first device, and obtain processing After the identity credential application information.
  • a sending module 930 configured to send a second message to the first device, where the second message includes the processed identity credential application information, and the processed identity credential application information is used to request registration from a third-party device The identity credential of the first device, wherein the second device and the third-party device trust each other.
  • the second message further includes: device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the identity credential application information of the first device includes at least one of the following information: a device identification of the first device; a device authentication public key of the first device; an account logged in by the first device The account identifier of the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device identity private key of the second device.
  • processing module 920 is further configured to generate an identity credential proxy application record, where the identity credential proxy application record is used to instruct the second device to sign the identity credential application information of the first device.
  • the processing module 920 is further configured to determine a usage policy of the identity credential of the first device, where the usage policy is used to indicate valid information of the first identity credential.
  • the first device is a device without a security environment or with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • the first device shown in FIG. 9 may be used to execute the method 300 in FIG. 3 , and the description will not be repeated to avoid redundancy.
  • the second device 900 shown in FIG. 9 includes a receiving module 910 , a processing module 920 and a sending module 930 .
  • the receiving module 910 is configured to receive a first message sent by a first device, where the first message includes identity credential application information of the first device.
  • a processing module 920 configured to use the private key of the second device to sign the identity credential application information of the first device, or use a symmetric key to encrypt the identity credential application information of the first device, and obtain processing After the identity credential application information.
  • a sending module 930 configured to send a third message to a third-party device, where the third message includes the processed identity credential application information, and is used to request the third-party device to register the identity credential of the first device, The second device and the third-party device trust each other.
  • the receiving module 910 is further configured to receive a fourth message sent by the third-party device, where the fourth message includes the identity credential of the first device.
  • the sending module 930 is further configured to send a fifth message to the first device, where the fifth message includes the identity credential of the first device.
  • the third message further includes: device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the identity credential application information of the first device includes at least one of the following information: a device identification of the first device; a device authentication public key of the first device; an account logged in by the first device The account identifier of the first device; the account login credentials of the account logged in by the first device.
  • the private key of the second device is the registration service private key of the second device, or the device identity private key of the second device.
  • processing module 920 is further configured to generate an identity credential proxy application record, where the identity credential proxy application record is used to instruct the second device to proxy an identity credential application for the first device.
  • the processing module 920 is further configured to determine a usage policy of the identity credential of the first device, where the usage policy is used to indicate valid information of the first identity credential.
  • the first device is a device without a security environment or with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • FIG. 10 is a schematic structural diagram of a communication apparatus provided by an embodiment of the present application.
  • the communication apparatus 1000 in FIG. 10 may be a specific example of the device 121 in FIG. 1 .
  • the communication apparatus shown in FIG. 10 can be used for executing the method 200 in FIG. 2 or for executing the method 300 in FIG. 3 , and the description is not repeated to avoid redundancy.
  • the communication device may be the above-mentioned second device, or a device in the second device, or a device that can be matched and used with the second device.
  • the communication device may be a chip system.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • the communication apparatus 1000 includes at least one processor 1020, which is configured to implement the method provided by the embodiment of the present application. For details, refer to the detailed description in the method example, which is not repeated here.
  • the function of the processor 1020 is the same as that of the processing module 920 .
  • Communication apparatus 1000 may also include at least one memory 1010 for storing program instructions and/or data.
  • Memory 1010 and processor 1020 are coupled.
  • the coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, which may be in electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the processor 1010 may cooperate with the memory 1020 .
  • Processor 1010 may execute program instructions stored in memory 1020 . At least one of the at least one memory may be included in the processor.
  • the communication apparatus 1000 may further include a communication interface 1030 for communicating with other devices through a transmission medium, so that the devices used in the communication apparatus 1000 may communicate with other devices.
  • the communication interface may be a transceiver, circuit, bus, module, pin or other type of communication interface.
  • the communication apparatus 1000 is the second device, and the other device is the first device or a third-party device.
  • the processor 1020 uses the communication interface 1030 to send and receive data, and is configured to implement the method executed by the second device in the embodiment corresponding to FIG. 2 or FIG. 3 .
  • the specific connection medium between the processor 1020 and the memory 1010 of the communication interface 1030 is not limited in this embodiment of the present application.
  • the memory 1010 , the processor 1020 , and the communication interface 1030 are connected through a bus 1040 .
  • FIG. 11 is a schematic structural diagram of a third-party device provided by an embodiment of the present application.
  • the third-party device 1100 in FIG. 11 may be a specific example of the third-party device 110 in FIG. 1 .
  • the third-party device shown in FIG. 11 may be used to execute the method 200 in FIG. 2 or the method 300 in FIG. 3 , and may specifically implement the embodiment shown in FIG. 4 . To avoid redundancy, no The description is repeated.
  • the third-party device 1100 shown in FIG. 11 includes a receiving module 1110 , a processing module 1120 and a sending module 1130 .
  • the receiving module 1110 is configured to receive a third message, where the third message includes the processed identity credential application information, wherein the processed identity credential application information is the identity credential application information of the first device that has been privately processed by the second device.
  • the third-party device and the second device trust each other, obtained after the key is signed, or obtained after being encrypted by the symmetric key.
  • the processing module 1120 is configured to use the public key corresponding to the private key of the second device or the symmetric key to verify the processed identity credential application information.
  • the processing module 1120 is further configured to issue an identity credential for the first device after the verification is passed.
  • the sending module 1130 is configured to send the identity credential of the first device.
  • the receiving module 1110 is specifically configured to receive the third message from the first device; or, the third-party device to receive the third message from the second device.
  • the third message further includes device identity information of the second device, and/or a usage policy of the identity credential of the first device.
  • the first device is a device without a security environment or with limited security protection resources
  • the second device is a device with a security environment or sufficient security protection resources.
  • FIG. 12 is a schematic structural diagram of a communication apparatus provided by an embodiment of the present application.
  • the communication apparatus 1200 in FIG. 12 may be a specific example of the third-party device 110 in FIG. 1 .
  • the communication apparatus shown in FIG. 12 can be used for executing the method 200 in FIG. 2 or for executing the method 300 in FIG. 3 , and the description is not repeated to avoid redundancy.
  • the communication device may be the above-mentioned third-party device, or may be a device in a third-party device, or a device that can be matched and used with the third-party device.
  • the communication device may be a chip system.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • the communication apparatus 1200 includes at least one processor 1220, which is configured to implement the method provided by the embodiment of the present application. For details, refer to the detailed description in the method example, which is not repeated here.
  • the function of the processor 1220 is the same as that of the processing module 1120 .
  • Communication apparatus 1200 may also include at least one memory 1220 for storing program instructions and/or data.
  • Memory 1220 and processor 1220 are coupled.
  • the coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, which may be in electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the processor 1220 may cooperate with the memory 1220.
  • the processor 1220 may execute program instructions stored in the memory 1220 . At least one of the at least one memory may be included in the processor.
  • the communication apparatus 1200 may also include a communication interface 1230 for communicating with other devices through a transmission medium, so that the devices used in the communication apparatus 1200 may communicate with other devices.
  • the communication interface may be a transceiver, circuit, bus, module, pin or other type of communication interface.
  • the communication apparatus 1200 is a third-party device, and the other device is the first device or the second device.
  • the processor 1220 uses the communication interface 1230 to send and receive data, and is used to implement the method executed by the third-party device in the embodiment corresponding to FIG. 2 or FIG. 3 .
  • the specific connection medium between the processor 1220 and the memory 1220 of the communication interface 1230 is not limited in the embodiments of the present application.
  • the memory 1220 , the processor 1220 , and the communication interface 1230 are connected through a bus 1240 .
  • FIG. 13 is a schematic structural diagram of a second device provided by an embodiment of the present application.
  • the second device 1300 in FIG. 13 may be a specific example of the device 121 in FIG. 1 .
  • the second device shown in FIG. 13 may be used to execute the method 500 shown in FIG. 5 , and may specifically implement the embodiment shown in FIG. 6 , and the description will not be repeated to avoid redundancy.
  • the second device 1300 shown in FIG. 13 includes a receiving module 1310 and a processing module 1320 .
  • the receiving module 1310 is configured to receive an identity authentication request sent by a first device, where the identity authentication request includes an identity credential of the first device and a device identity of the first device.
  • the processing module 1320 is configured to determine, according to the device identification of the first device, that the identity credential of the first device is an agent application for the first device by the second device.
  • the processing module 1320 is further configured to determine whether the identity credential of the first device conforms to the usage policy according to the usage policy corresponding to the identity credential of the first device.
  • the processing module 1320 is further configured to, when the identity credential of the first device complies with the usage policy, the second device to perform legality and integrity verification on the identity credential of the first device.
  • processing module 1320 is further configured to determine whether the identity credential of the first device needs to be updated according to the usage policy.
  • the processing module 1320 is specifically configured to query the identity credential proxy application record corresponding to the first device according to the device identification of the first device, where the identity credential proxy application record is used to indicate the second device.
  • the device signs the identity credential application information of the first device, or instructs the second device to encrypt the identity credential application information of the first device; determine the first device according to the identity credential proxy application record.
  • the identity credential of a device is an agent application for the second device.
  • FIG. 14 is a schematic structural diagram of a communication apparatus provided by an embodiment of the present application.
  • the communication apparatus 1400 in FIG. 14 may be a specific example of the second device 121 in FIG. 1 .
  • the communication apparatus shown in FIG. 14 can be used to execute the method 500 in FIG. 5 or the method 600 in FIG. 6 , and the description is not repeated to avoid redundancy.
  • the communication device may be the above-mentioned second device, or a device in the second device, or a device that can be matched and used with the second device.
  • the communication device may be a chip system.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • the communication apparatus 1400 includes at least one processor 1420, which is configured to implement the method provided by the embodiments of the present application. For details, refer to the detailed description in the method example, which is not repeated here.
  • the function of the processor 1420 is the same as that of the processing module 1320 .
  • Communication apparatus 1400 may also include at least one memory 1410 for storing program instructions and/or data.
  • Memory 1410 and processor 1420 are coupled.
  • the coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, which may be in electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • Processor 1410 may cooperate with memory 1420.
  • Processor 1410 may execute program instructions stored in memory 1420 . At least one of the at least one memory may be included in the processor.
  • the communication apparatus 1400 may also include a communication interface 1430 for communicating with other devices through a transmission medium, so that the devices used in the communication apparatus 1400 may communicate with other devices.
  • the communication interface may be a transceiver, circuit, bus, module, pin or other type of communication interface.
  • the communication apparatus 1400 is the second device, and the other device is the first device or the second device.
  • the processor 1420 uses the communication interface 1430 to send and receive data, and is configured to implement the method executed by the second device in the embodiment corresponding to FIG. 2 or FIG. 3 .
  • the specific connection medium between the processor 1420 and the memory 1414 of the above-mentioned communication interface 1430 is not limited in this embodiment of the present application.
  • the memory 1410 , the processor 1420 , and the communication interface 1430 are connected through a bus 1440 .
  • FIG. 15 is a schematic structural diagram of a first device provided by an embodiment of the present application
  • FIG. 16 is a schematic structural diagram of a second device provided by an embodiment of the present application.
  • the devices shown in FIG. 15 and FIG. 16 may specifically implement the embodiment shown in FIG. 4 or the embodiment shown in FIG. 6 , and the description will not be repeated to avoid redundancy.
  • the first device 1500 shown in FIG. 15 includes a first application module 1510 , a first storage module 1520 and a first authentication module 1530 .
  • the first application module 1510 is configured to perform relevant steps and operations of applying for the identity credential of the first device.
  • the first storage module 1520 is configured to store the device private key and identity credentials of the first device.
  • the first authentication module 1530 is configured to perform the steps and operations of performing identity authentication with other devices.
  • each module of the first device In the stage of applying for an identity credential, the operations performed by each module of the first device are as follows.
  • the first application module 1510 is specifically configured to obtain an account identifier and an account login credential. For example, step S401 in the method 400 is performed.
  • the first application module 1510 is specifically configured to request the first storage module 1520 to generate a device identity public-private key pair of the first device.
  • the first storage module 1520 is specifically configured to generate a device identity public and private key pair of the first device, and return it to the first application module 1510 device identity public key.
  • step S402 in the method 400 is performed.
  • the first application module 1510 is specifically configured to generate an identity credential application request and send it to the proxy device.
  • step S403 in the method 400 is performed.
  • the first application module 1510 is specifically configured to send the identity credential application request signed by the second device to the third-party device.
  • step S408 in the method 400 is performed.
  • the first application module 1510 is specifically configured to receive an identity credential issued by a third-party device, and verify the identity credential. For example, step S412 in the method 400 is performed.
  • the first storage module 1520 is specifically configured to store the identity credentials issued by the third-party device.
  • each module of the first device In the identity authentication stage, the operations performed by each module of the first device are as follows.
  • the first authentication module 1530 is specifically configured to request the identity credential from the first storage module 1520, initiate a device authentication request, and send the device identification and identity credential of the device. For example, step S601 in the method 600 is performed.
  • the first authentication module 1530 is specifically configured to request the first storage module 1520 to verify the identity credential of the second device.
  • the first storage module 1520 is specifically configured to verify the validity and integrity of the identity credential of the second device. For example, step S608 in the method 600 is performed.
  • the second device 1600 shown in FIG. 16 includes a second application module 1610 , a second storage module 1620 and a second authentication module 1630 .
  • the second application module 1610 is configured to perform the relevant steps and operations of applying for the identity credential of the second device and applying for the identity credential of the first device by proxy.
  • the second application module 1610 includes a local credential application sub-module 1611 and a proxy credential application sub-module 1622 .
  • the local credential application sub-module 1611 may be configured to perform the step of applying for the identity credential of the local device, for example, to perform the operation performed by the second device in the preprocessing stage in the method embodiment.
  • the proxy credential application sub-module 1622 is configured to perform the step of proxying for an identity credential application of another device, for example, performing an operation performed by the second device in the stage of proxying an identity credential application in the method embodiment.
  • the second storage module 1620 is configured to store the device private key and identity credential of the second device, and the identity credential of the first device.
  • the second storage module 1620 includes a proxy application issuing submodule 1621, and a proxy credential storage submodule 1622.
  • the proxy application issuing sub-module 1621 is used to store the device identity private key of the local device, and is used to sign the proxy identity credential application information.
  • the proxy credential storage sub-module 1622 is used to store proxy credentials.
  • the second authentication module 1630 is configured to perform the steps and operations of performing identity authentication with other devices.
  • the second authentication module 1630 includes a non-native proxy credential authentication sub-module 1631 , a native proxy credential update policy sub-module 1632 and a native proxy credential authentication sub-module 1633 .
  • the non-native proxy credential authentication sub-module 1631 is used to perform the operation of identity authentication with the non-native proxy credential device.
  • the native proxy credential authentication sub-module 1633 is used to perform the operation of authentication with the device of the native proxy credential.
  • the local proxy credential update policy submodule 1632 is used to perform operations such as updating and reapplying for the local proxy credential.
  • a device with non-local proxy credentials refers to a device whose identity credential is not applied for by a local proxy
  • a device with local proxy credentials refers to a device whose identity credentials are applied for by a local proxy
  • the second authentication module 1630 includes a key generation module, a key management module, an encryption/decryption/sign verification module, and a key verification module.
  • each module of the first device In the stage of applying for an identity credential, the operations performed by each module of the first device are as follows.
  • the proxy application issuance sub-module 1621 is specifically configured to use the private key of the second device to sign the identity credential application information of the first device (and the device identity information of the second device). For example, step S405a or step S405b in the method 400 is performed.
  • the proxy application issuance sub-module 1621 is specifically configured to generate a usage policy corresponding to the identity credential of the first device. For example, step S413a in the method 400 is performed.
  • the proxy credential application sub-module 1622 is specifically configured to return the signed identity credential application request to the first device.
  • step S407 in the method 400 is performed.
  • the proxy application issuance sub-module 1621 is specifically configured to store the identity credentials of the proxy device.
  • each module of the first device In the identity authentication stage, the operations performed by each module of the first device are as follows.
  • the local proxy credential authentication sub-module 1633 is specifically configured to request the proxy credential storage sub-module 1622 to query the identity credential proxy application record of the first device. For example, step S520 in the method 600 is performed.
  • the local proxy credential update policy submodule 1632 is specifically configured to determine whether the identity credential of the first device needs to be updated.
  • each module in the first device 1500 may be similar to each module in the second device 1600 .
  • FIG. 17 is a schematic structural diagram of a fourth device provided by an embodiment of the present application.
  • the device shown in FIG. 17 may specifically implement the embodiment shown in FIG. 5 , and the description is not repeated to avoid redundancy.
  • the fourth device 1700 shown in FIG. 17 includes a fourth application module 1710 , a fourth storage module 1720 and a fourth authentication module 1730 .
  • the fourth application module 1710 is configured to perform relevant steps and operations of applying for the identity credential of the fourth device.
  • the fourth storage module 1720 is configured to store the device private key and identity credentials of the fourth device.
  • the fourth authentication module 1730 is configured to perform the steps and operations of performing identity authentication with other devices.
  • the fourth authentication module 1730 includes a non-proxy credential authentication sub-module 1731 and a proxy credential authentication sub-module 1732 .
  • the non-proxy credential authentication sub-module 1731 is used to perform the operation of identity authentication with the non-proxy credential device.
  • the proxy credential authentication sub-module 1732 is used to perform the operation of authentication with the device of the proxy credential.
  • the device with non-proxy credentials refers to that the identity credential is independently applied for
  • the device with proxy credentials refers to that the identity credential is applied for by another device as a proxy.
  • each module of the fourth device In the identity credential application stage, the operations performed by each module of the fourth device are similar to the process of the second device applying for its own identity credential, which can be referred to the above description and will not be repeated here.
  • each module of the fourth device In the identity authentication stage, the operations performed by each module of the fourth device are as follows.
  • the proxy credential authentication sub-module 1732 is specifically configured to determine that the identity credential of the first device is a proxy application for the first device by the second device, and determine whether to perform identity authentication with the first device according to a usage policy corresponding to the identity credential of the first device. For example, steps S502a, S502b or S503 in the method 500 are performed.
  • the fourth application module 1710 may further include a local credential application sub-module, a proxy credential application sub-module, and the like.
  • the fourth authentication module 1730 may further include a native proxy credential authentication sub-module, a native proxy credential update policy sub-module, and the like.
  • the fourth storage module 1720 may include a proxy application issuance submodule, a proxy credential storage submodule, and the like.
  • the disclosed system, apparatus and method may be implemented in other manners.
  • the apparatus embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented.
  • the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.
  • the functions, if implemented in the form of software functional units and sold or used as independent products, may be stored in a computer-readable storage medium.
  • the technical solution of the present application can be embodied in the form of a software product in essence, or the part that contributes to the prior art or the part of the technical solution.
  • the computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program codes .

Landscapes

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

Abstract

本申请提供了一种身份凭据的申请方法、身份认证的方法、设备及装置，该方法包括第一设备向第二设备发送第一消息，该第一消息包括该第一设备的身份凭据申请信息；该第一设备接收该第二设备发送的第二消息，该第二消息包括处理后的身份凭据申请信息，其中该处理后的身份凭据申请信息是该第一设备的身份凭据申请信息经该第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的；该第一设备向第三方设备发送第三消息，该第三消息包括该处理后的身份凭据申请信息，用于向该第三方设备请求注册该第一设备的身份凭据，其中该第三方设备与该第二设备相互信任。上述技术方案能够保证设备注册身份凭据过程的安全性，提升认证设备覆盖面。

Description

身份凭据的申请方法、身份认证的方法、设备及装置
本申请要求于2020年06月30日提交中国专利局、申请号为202010611975.3、申请名称为“身份凭据的申请方法、身份认证的方法、设备及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，并且更具体地，涉及一种身份凭据的申请方法、身份认证的方法、设备及装置。
背景技术
两个设备之间进行通信时，通信双方需要交换各自的身份凭据以完成身份认证。设备的身份凭据一般在认证前从可信的第三方获取。例如申请设备生成用于标识设备身份的公私钥对后，将其中的公钥和设备的其他信息发送给第三方，用于第三方签发身份凭据。
身份凭据的注册过程涉及密钥的存储和使用，为了消减身份凭据注册流程被复制到其他恶意设备上的风险，以及确保身份凭据在设备侧可以被安全存储、使用等，第三方对请求注册身份凭据的设备具有一定要求，例如需要资源充足或具有安全环境等，以确保申请设备发送给第三方的信息没有被篡改，减少身份凭据在保存和使用过程中被盗取或篡改的风险。
但并非所有设备都具备向第三方证明注册信息完整性保护的能力，例如对于物联网(internet of things，IoT)设备来说，有的设备可以自主登录账号，有的设备可以被账号绑定，各终端设备可以基于账号进行认证并可信互联，并不一定要求设备具有安全环境。而这样的设备如何从第三方注册身份凭据以完成与其他设备进行身份认证是一个亟待解决的问题。
发明内容
本申请提供一种身份凭据的申请方法、身份认证的方法、设备及装置，能够保证设备注册身份凭据过程的安全性，并且能够提升认证设备覆盖面。
第一方面，提供了一种身份凭据的申请方法，包括：第一设备向第二设备发送第一消息，所述第一消息包括所述第一设备的身份凭据申请信息；所述第一设备接收所述第二设备发送的第二消息，所述第二消息包括处理后的身份凭据申请信息，其中所述处理后的身份凭据申请信息是所述第一设备的身份凭据申请信息经所述第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的；所述第一设备向第三方设备发送第三消息，所述第三消息包括所述处理后的身份凭据申请信息，用于向所述第三方设备请求注册所述第一设备的身份凭据，其中所述第三方设备与所述第二设备相互信任。
本申请实施例提供的技术方案中，通过第二设备对第一设备的身份凭据申请信息进行 签名或加密，以确保第一设备向第三方设备发送信息的安全性和完整性。第三方设备基于与第二设备的信任关系，在对第一设备的身份凭据申请信息的验证通过后即可为第一设备颁发身份凭据。这样由与签发设备具有信任关系的第二设备代理申请其他与第二设备具有信任基础的设备的身份凭据，能够向签发设备证明设备身份凭据注册流程没有被篡改，消减了第一设备因安全能力不足，无法向第三方设备证明身份凭据完整性的风险，提升了设备身份凭据注册的安全性。
另外一些与第二设备具有信任基础的设备，虽然自己不能注册身份凭据，但是可以请求第二设备代理申请，可以增加能够注册身份凭据的设备数量，提升认证设备的覆盖面。
本申请实施例中，第二设备与第三方设备相互信任可以理解为第二设备在第三方设备处已注册身份凭据，与第三方设备已经建立可信关系。
结合第一方面，在一种可能的实现方式中，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
结合第一方面，在一种可能的实现方式中，所述第二消息还包括：所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
第二设备的设备身份信息可用于标识第二设备为第一设备的身份凭据申请信息签名，即可以标识第二设备为第一设备代理申请身份凭据。
第一设备的身份凭据的使用策略可用于通知第一设备其身份凭据的有效信息和认证信息等，其中有效信息例如包括身份凭据的有效期、有效认证次数等，认证信息例如包括身份凭据可以被哪些设备认可或认证。
结合第一方面，在一种可能的实现方式中，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备身份公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
结合第一方面，在一种可能的实现方式中，所述第二设备的私钥为所述第二设备的注册服务私钥，或者为所述第二设备的设备身份私钥。
第二设备的注册服务私钥和与该私钥对应的注册服务公钥为一对公私钥对，用于保证第二设备注册身份凭据的流程的安全性。第二设备的注册服务私钥可以是第二设备在产线预置的，或者通过应用程序获取的。注册服务公钥则保存于第三方设备中。这里“第二设备的注册服务私钥”仅用于表示第二设备具备注册服务私钥，不限定第二设备与注册服务私钥为一一对应关系。
该第二设备的设备身份私钥和与该私钥对应的设备身份公钥为一对公私钥对，由第二设备生成。第二设备的设备身份公私钥对用于标识和证明第二设备的设备身份。
结合第一方面，在一种可能的实现方式中，所述对称密钥为预置于第二设备中的，或者为第三方设备在与第二设备建立信任关系后发送给所述第二设备的。
结合第一方面，在一种可能的实现方式中，所述第三消息还包括所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
第二方面，提供了一种身份凭据的申请方法，包括：第二设备接收第一设备发送的第一消息，所述第一消息包括所述第一设备的身份凭据申请信息；所述第二设备使用所述第二设备的私钥对所述第一设备的身份凭据申请信息进行签名，或者使用对称密钥对所述第一设备的身份凭据申请信息进行加密，得到处理后的身份凭据申请信息；所述第二设备向 所述第一设备发送第二消息，所述第二消息包括所述处理后的身份凭据申请信息，所述处理后的身份凭据申请信息用于所述第一设备向第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任。
本申请提供的技术方案中，第一设备通过有第二设备代理生成申请身份凭据，由于第二设备与第三方设备相互可信，可以向第三方设备证明身份凭据申请信息完整性，提升了设备身份凭据注册的安全性。
结合第二方面，在一种可能的实现方式中，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
结合第二方面，在一种可能的实现方式中，所述第二消息还包括：所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
结合第二方面，在一种可能的实现方式中，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备认证公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
结合第二方面，在一种可能的实现方式中，所述第二设备的私钥为所述第二设备的注册服务私钥，或者为所述第二设备的设备身份私钥。
结合第二方面，在一种可能的实现方式中，所述对称密钥为预置于所述第二设备中的，或者为第三方设备在与第二设备建立信任关系后发送给所述第二设备的。
结合第二方面，在一种可能的实现方式中，还包括：所述第二设备生成身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备代理申请身份凭据。
本申请中，所述身份凭据代理申请记录用于指示第二设备为第一设备的身份凭据申请信息进行了签名，或者指示第二设备为第一设备的身份凭据申请信息进行了加密。
结合第二方面，在一种可能的实现方式中，还包括：所述第二设备确定所述第一设备的身份凭据的使用策略，所述使用策略用于指示所述第一身份凭据的有效信息。
结合第二方面，在一种可能的实现方式中，还包括：所述第二设备接收所述第一设备发送的身份认证请求，所述身份认证请求包括所述第一设备的身份凭据和所述第一设备的设备标识；所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请；所述第二设备根据所述第一设备的身份凭据对应的使用策略确定所述第一设备的身份凭据是否符合所述使用策略；在所述第一设备的身份凭据符合所述使用策略的情况下，所述第二设备对所述第一设备的身份凭据进行合法性和完整性校验。
本申请实施例中，第二设备为第一设备代理申请到身份凭据之后，第一设备与第二设备可以基于身份凭据进行身份认证。当第二设备确定第一设备的身份凭据为第二设备代理申请，并符合对应使用策略，则第二设备可以对第一设备的身份凭据进行合法性和完整性校验。
可选地，第一设备的身份凭据的使用策略包括所述第一设备的身份凭据的有效信息和认证信息。
结合第二方面，在一种可能的实现方式中，还包括：根据所述使用策略确定是否需要更新所述第一设备的身份凭据。
结合第二方面，在一种可能的实现方式中，所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请，包括：所述第二设备根据所述第一设备的设备标识查询到与所述第一设备对应的身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备的身份凭据申请信息进行了签名，或者指示所述第二设备为所述第一设备的身份凭据申请信息进行了加密；根据所述身份凭据代理申请记录确定所述第一设备的身份凭据为所述第二设备代理申请。
第三方面，提供了一种身份凭据的申请方法，包括：第二设备接收第一设备发送的第一消息，所述第一消息包括所述第一设备的身份凭据申请信息；所述第二设备使用所述第二设备的私钥对所述第一设备的身份凭据申请信息进行签名，或者使用对称密钥对所述第一设备的身份凭据申请信息进行加密，得到处理后的身份凭据申请信息；所述第二设备向第三方设备发送第三消息，所述第三消息包括所述处理后的身份凭据申请信息，用于向所述第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任。
本申请的技术方案中，由于第一设备的身份凭据申请信息经过的第二设备的私钥签名，或者经第二设备加密，并且第二设备与第三方设备为相互信任的设备。第二设备对第一设备的身份凭据申请信息的签名或加密可以用于证明第一设备发送的用于注册身份凭据的信息的完整性，提升了身份凭据注册过程的安全性。
结合第三方面，在一种可能的实现方式中，还包括：所述第二设备接收所述第三方设备发送的第四消息，所述第四消息包括所述第一设备的身份凭据；所述第二设备向所述第一设备发送第五消息，所述第五消息包括所述第一设备的身份凭据。
结合第三方面，在一种可能的实现方式中，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
结合第三方面，在一种可能的实现方式中，所述第三消息还包括：所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
结合第三方面，在一种可能的实现方式中，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备认证公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
结合第三方面，在一种可能的实现方式中，所述第二设备的私钥为所述第二设备的注册服务私钥，或者所述第二设备的设备身份私钥。
结合第三方面，在一种可能的实现方式中，所述对称密钥为预置于所述第二设备中的，或者为第三方设备在与第二设备建立信任关系后发送给所述第二设备的。
结合第三方面，在一种可能的实现方式中，还包括：所述第二设备生成身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备代理申请身份凭据。
本申请中，所述身份凭据代理申请记录用于指示第二设备为第一设备的身份凭据申请信息进行了签名，或者指示第二设备为第一设备的身份凭据申请信息进行了加密。
结合第三方面，在一种可能的实现方式中，还包括：所述第二设备确定所述第一设备的身份凭据的使用策略，所述使用策略用于指示所述第一身份凭据的有效信息。
结合第三方面，在一种可能的实现方式中，还包括：所述第二设备接收所述第一设备 发送的身份认证请求，所述身份认证请求包括所述第一设备的身份凭据和所述第一设备的设备标识；所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请；所述第二设备根据所述第一设备的身份凭据对应的使用策略确定所述第一设备的身份凭据是否符合所述使用策略；在所述第一设备的身份凭据符合所述使用策略的情况下，所述第二设备对所述第一设备的身份凭据进行合法性和完整性校验。
本申请实施例中，第二设备为第一设备代理申请到身份凭据之后，第一设备与第二设备可以基于身份凭据进行身份认证。当第二设备确定第一设备的身份凭据为第二设备代理申请，并符合对应使用策略，则第二设备可以对第一设备的身份凭据进行合法性和完整性校验。
可选地，第一设备的身份凭据的使用策略包括所述第一设备的身份凭据的有效信息和认证信息。
结合第三方面，在一种可能的实现方式中，还包括：根据所述使用策略确定是否需要更新所述第一设备的身份凭据。
结合第三方面，在一种可能的实现方式中，所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请，包括：所述第二设备根据所述第一设备的设备标识查询到与所述第一设备对应的身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备的身份凭据申请信息进行了签名，或者指示所述第二设备为所述第一设备的身份凭据申请信息进行了加密；根据所述身份凭据代理申请记录确定所述第一设备的身份凭据为所述第二设备代理申请。
第四方面，提供了一种身份凭据的申请方法，包括：第一设备向第二设备发送第一消息，所述第一消息包括所述第一设备的身份凭据申请信息，用于向第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任；所述第一设备接收所述第二设备发送的第五消息，所述第五消息包括所述第一设备的身份凭据，其中所述第一设备的身份凭据是在所述第三方设备验证处理后的身份凭据申请信息后发送给所述第二设备的，所述处理后的身份凭据申请信息是所述第一设备的身份凭据申请信息经所述第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的。
结合第四方面，在一种可能的实现方式中，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
结合第四方面，在一种可能的实现方式中，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备认证公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
结合第四方面，在一种可能的实现方式中，所述第二设备的私钥为所述第二设备的注册服务私钥，或者所述第二设备的设备认证私钥。
结合第四方面，在一种可能的实现方式中，所述对称密钥为预置于所述第二设备中的，或者为第三方设备在与第二设备建立信任关系后发送给所述第二设备的。
第五方面，提供了一种身份凭据的申请方法，包括：第三方设备接收第三消息，所述第三消息包括处理后的身份凭据申请信息，其中所述处理后的身份凭据申请信息是第一设备的身份凭据申请信息经第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到 的，所述第三方设备与所述第二设备相互信任；所述第三方设备使用与所述第二设备的私钥对应的公钥或所述对称密钥对所述处理后的身份凭据申请信息进行验证；验证通过后，所述第三方设备为所述第一设备签发身份凭据。
应理解，本申请实施例中，若所述处理后的身份凭据申请信息是第一设备的身份凭据申请信息经第二设备的私钥签名之后得到的，则相应地，所述第三方设备使用与所述第二设备的私钥对应的公钥对所述处理后的身份凭据申请信息进行验签。若所述处理后的身份凭据申请信息是第二设备使用对称密钥对所述第一设备的身份凭据申请信息进行对称加密之后得到的，则相应地，所述第三方设备使用与加密过程相同的对称密钥对所述处理后的身份凭据申请信息进行解密。
结合第五方面，在一种可能的实现方式中，所述第三方设备接收第三消息，包括：所述第三方设备从所述第一设备接收所述第三消息；或者，所述第三方设备从所述第二设备接收所述第三消息。
结合第五方面，在一种可能的实现方式中，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
结合第五方面，在一种可能的实现方式中，所述第三消息还包括所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
结合第五方面，在一种可能的实现方式中，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备认证公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
结合第五方面，在一种可能的实现方式中，所述第二设备的私钥为所述第二设备的注册服务私钥，或者所述第二设备的设备身份私钥。
第六方面，提供了一种身份认证的方法，其特征在于，包括：第二设备接收第一设备发送的身份认证请求，所述身份认证请求包括所述第一设备的身份凭据和所述第一设备的设备标识；所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请；所述第二设备根据所述第一设备的身份凭据对应的使用策略确定所述第一设备的身份凭据是否符合所述使用策略；在所述第一设备的身份凭据符合所述使用策略的情况下，所述第二设备对所述第一设备的身份凭据进行合法性和完整性校验。
本申请实施例借助第二设备代理申请第一设备的身份凭据，申请设备与代理设备建立一对一信任关系，可以实现设备间的相互认证，同时消减认证密钥被导出、批量复制到恶意设备的风险，提高安全性。
本申请实施例中，所述第一设备的身份凭据对应的使用策略用于指示所述第一设备的身份凭据的有效信息。根据第一设备的身份凭据对应的使用策略确定第一设备的身份凭据是否符合所述使用策略，可以理解为根据该使用策略确定第一设备的身份凭据是否有效，例如是否在有效期内、是否具备有效认证次数等。相应地，在第一设备的身份凭据不符合该使用策略时，可以认为第一设备的身份凭据失效。
结合第六方面，在一种可能的实现方式中，所述方法还包括：根据所述使用策略确定是否需要更新所述第一设备的身份凭据。
结合第六方面，在一种可能的实现方式中，所述第二设备根据所述第一设备的设备标 识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请，包括：所述第二设备根据所述第一设备的设备标识查询到与所述第一设备对应的身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备的身份凭据申请信息进行了签名，或者指示所述第二设备为所述第一设备的身份凭据申请信息进行了加密；根据所述身份凭据代理申请记录确定所述第一设备的身份凭据为所述第二设备代理申请。
第七方面，提供了一种身份认证的方法，其特征在于，包括：第四设备接收第一设备发送的身份认证请求，所述身份认证请求包括所述第一设备的身份凭据，其中所述第一设备的身份凭据为第二设备代理申请，所述第一设备的身份凭据包括所述第二设备的信息；所述第四设备根据所述第一设备的身份凭据确定与所述第一设备进行身份认证，其中所述第四设备与所述第二设备相互信任。
本申请中，第四设备为已经注册身份凭据的设备。第四设备与第二设备相互信任可以理解为第四设备与第二设备已经进行过身份认证，或者第四设备与第二设备的身份凭据为同一设备例如本申请实施例中的第三方设备颁发。
结合第七方面，在一种可能的实现方式中，第二设备的信息包括第二设备的设备身份标识或第二设备的身份凭据。
第八方面，提供了一种身份认证的方法，其特征在于，包括：第四设备接收第一设备发送的身份认证请求，所述身份认证请求包括所述第一设备的身份凭据，其中所述第一设备的身份凭据为第三方设备颁发；所述第四设备根据所述第一设备的身份凭据与所述第一设备进行身份认证，其中所述第四设备与所述第三方设备相互信任。
结合第八方面，在一种可能的实现方式中，所述第一设备的身份凭据为第二设备代理申请。
结合第八方面，在一种可能的实现方式中，所述第一设备的身份凭据包括第二设备的信息。
可选地，第二设备的信息包括第二设备的设备身份标识或第二设备的身份凭据。
第九方面，提供了一种设备，包括用于执行上述第一方面或第一方面中任一种可能实现方式中方法的模块或单元，或者包括用于执行上述第四方面或第四方面中任一种可能实现方式中方法的模块或单元。该模块或单元可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。
也就是说，本申请实施例提供的设备包括用于执行上文中的由第一设备执行的方法或步骤或操作或功能的模块。
第十方面，提供了一种设备，包括用于执行上述第二方面或第二方面中任一种可能实现方式中方法的模块或单元，或者包括用于执行上述第三方面或第三方面中任一种可能实现方式中方法的模块或单元。该模块或单元可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。
也就是说，本申请实施例提供的设备包括用于执行上文中的由第二设备执行的方法或步骤或操作或功能的模块。
第十一方面，提供了一种设备，包括用于执行上述第五方面或第五方面中任一种可能实现方式中方法的模块或单元。
也就是说，本申请实施例提供的设备包括用于执行上文中的由第三方设备执行的方法 或步骤或操作或功能的模块。
第十二方面，提供了一种设备，包括用于执行上述第六方面至第八方面或第六方面至第八方面中任一种可能实现方式中方法的模块或单元。
第十三方面，提供了一种通信装置，所述通信装置包括：至少一个处理器和通信接口，所述通信接口用于所述通信装置与其他通信装置进行信息交互，当程序指令在所述至少一个处理器中执行时，使得所述通信装置实现上文中的第一设备的功能。
可选地，所述通信接口可以为收发器、电路、总线、模块、管脚或其它类型通信接口。
可选地，该通信装置还包括存储器，所述存储器用于存储指令和数据，所述处理器执行所述存储器中存储的指令时，可以实现上述第一方面或第一方面的任一种可能的实现方式中描述的方法，或者实现上述第四方面或第四方面的任一种可能的实现方式中描述的方法，或者实现上述第六方面或第六方面的任一种可能的实现方式中描述的方法。
第十四方面，提供了一种通信装置，所述通信装置包括：至少一个处理器和通信接口，所述通信接口用于所述通信装置与其他通信装置进行信息交互，当程序指令在所述至少一个处理器中执行时，使得所述通信装置实现上文中的第二设备的功能。
可选地，所述通信接口可以为收发器、电路、总线、模块、管脚或其它类型通信接口。
可选地，该通信装置还包括存储器，所述存储器用于存储指令和数据，所述处理器执行所述存储器中存储的指令时，可以实现上述第二方面或第二方面的任一种可能的实现方式中描述的方法，或者实现上述第三方面或第三方面的任一种可能的实现方式中描述的方法。
第十五方面，提供了一种通信装置，所述通信装置包括：至少一个处理器和通信接口，所述通信接口用于所述通信装置与其他通信装置进行信息交互，当程序指令在所述至少一个处理器中执行时，使得所述通信装置实现上文中的第三方设备的功能。
可选地，所述通信接口可以为收发器、电路、总线、模块、管脚或其它类型通信接口。
可选地，该通信装置还包括存储器，所述存储器用于存储指令和数据，所述处理器执行所述存储器中存储的指令时，可以实现上述第五方面或第五方面的任一种可能的实现方式中描述的方法。
第十六方面，提供了一种通信装置，所述通信装置包括：至少一个处理器和通信接口，所述通信接口用于所述通信装置与其他通信装置进行信息交互，当程序指令在所述至少一个处理器中执行时，使得所述通信装置实现上文中的第四设备的功能，或实现上文中的第六方面中的第二设备的功能。
可选地，所述通信接口可以为收发器、电路、总线、模块、管脚或其它类型通信接口。
可选地，该通信装置还包括存储器，所述存储器用于存储指令和数据，所述处理器执行所述存储器中存储的指令时，可以实现上述第六方面至第八方面或第六方面至第八方面中任一种可能实现方式中描述的方法。
第十七方面，提供了一种芯片系统，该芯片系统包括处理器，用于第一设备实现上述第一方面或第一方面的任一种可能的实现方式中所涉及的功能，或者用于第一设备实现上述第四方面或第四方面的任一种可能的实现方式中所涉及的功能，或者用于第一设备实现上述第六方面或第六方面的任一种可能的实现方式中所涉及的功能，例如，生成，接收，发送，或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统 还包括存储器，所述存储器，用于保存第一设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第十八方面，提供了一种芯片系统，该芯片系统包括处理器，用于第二设备实现上述第二方面或第二方面的任一种可能的实现方式中所涉及的功能，或者用于终端设备实现上述第三方面或第三方面的任一种可能的实现方式中所涉及的功能，例如，生成，接收，发送，或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存网络设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第十九方面，提供了一种芯片系统，该芯片系统包括处理器，用于第三方设备实现上述第五方面或第五方面的任一种可能的实现方式中所涉及的功能，例如，生成，接收，发送，或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存网络设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第二十方面，提供了一种芯片系统，该芯片系统包括处理器，用于第四设备实现上述第七方面至第八方面或第七方面至第八方面的任一种可能的实现方式中所涉及的功能，例如，生成，接收，发送，或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存网络设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第二十一方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行上述第一方面或第一方面的任一种可能的实现方式所述的方法，或者使得计算机执行上述第四方面或第四方面的任一种可能的实现方式所述的方法。
第二十二方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行上述第二方面或第二方面的任一种可能的实现方式所述的方法，或者使得计算机执行上述第三方面或第三方面的任一种可能的实现方式所述的方法。
第二十三方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行上述第五方面或第五方面的任一种可能的实现方式所述的方法。
第二十四方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行上述第六方面或第六方面的任一种可能的实现方式所述的方法。
第二十五方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行上述第七方面或第七方面的任一种可能的实现方式所述的方法，或者使得计算机执行上述第八方面或第八方面的任一种可能的实现方式所述的方法。
第二十六方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面或第一方面的任一种可能的实现方式所述的方法，或者使得计算机执行上述第四方面或第四方面的任一种可能的实现方式所述的方法。
第二十七方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第二方面或第二方面的任一种可能的实现方式所述的方法，或者使得计算机执行上述第三方面或第三方面的任一种可能的实现方式所述的方法。
第二十八方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第五方面或第五方面的任一种可能的实现方式所述的方法。
第二十九方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第六方面或第六方面的任一种可能的实现方式所述的方法。
第三十方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第七方面或第七方面的任一种可能的实现方式所述的方法，或者使得计算机执行上述第八方面或第八方面的任一种可能的实现方式所述的方法。
第三十一方面，提供一种系统，包括上述第九方面描述的设备、第十方面描述的设备和第十一方面描述的设备；或者该通信系统包括上述第十三方面描述的通信装置、第十四方面描述的通信装置和第十五方面描述的通信装置。
附图说明
图1是本申请实施例的一种应用场景的示意图；
图2是本申请一个实施例提供的身份凭据的申请方法的示意性流程图；
图3是本申请另一个实施例提供的身份凭据的申请方法的示意性流程图；
图4是本申请又一个实施例提供的身份凭据的申请方法的示意性流程图；
图5是本申请一个实施例提供的身份认证方法的示意性流程图；
图6是本申请另一个实施例提供的身份认证方法的示意性流程图；
图7是本申请一个实施例提供的第一设备的示意性结构图；
图8是本申请一个实施例提供的一种通信装置的示意性结构图；
图9是本申请一个实施例提供的第二设备的示意性结构图；
图10是本申请一个实施例提供的一种通信装置的示意性结构图；
图11是本申请一个实施例提供的第三方设备的示意性结构图；
图12是本申请一个实施例提供的一种通信装置的示意性结构图；
图13是本申请一个实施例提供的第二设备的示意性结构图；
图14是本申请一个实施例提供的一种通信装置的示意性结构图；
图15是本申请一个实施例提供的第一设备的示意性结构图；
图16是本申请一个实施例提供的第二设备的示意性结构图；
图17是本申请一个实施例提供的第四设备的示意性结构图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。为方便理解，下面首先介绍本申请中涉及的相关概念。
公钥密码(public key cryptography)：也称为非对称密码，是一类密码算法，需要两 个单独的密钥，其中之一是保密的私有密钥(私钥)，另一个是公开密钥(公钥)。公私钥这两个部分在数学上是联系在一起的。公钥用于加密明文或验证数字签名；而私钥用于解密密文或创建数字签名。
数字签名(digital signature)：用于演示数字消息或文档的真实性的数学方案。有效的数字签名可以让接收者判定该消息是由已知的发送者(认证)创建的，发送方不能否认对消息签过名(不可否认性)。同时验证数字签名还可以确认消息在传输(完整性)中未被更改。
证书(certificate)和证书授权(certificate authority，CA)：在密码学中，证书授权CA中心是颁发数字证书的实体。数字证书通过证书的指定主题证明公钥的所有权。这允许其他(依赖方)依赖签名或关于对应于认证公钥的私钥的断言。在这种信任关系模型中，CA是受信任的第三方，由证书的主体(所有者)和依赖证书的一方信任。许多公钥基础设施(public key infrastructure，PKI)方案都采用CA。
签名和验签的主要过程：1)发送端对需要传输的原文做哈希(HASH)运算，得到数字摘要；2)发送端使用自己的私钥加密数字摘要，被加密的数字摘要即为签名；3)发送端将原文和数字签名发送给接收端；4)接收端使用发送端的公钥解密签名，得到数字摘要；5)接收端使用与发送端相同的方法对原文计算摘要值，并与解密得到的数字摘要进行对比，二者完全一致，证明原文在传输过程中没有被篡改过。
对称加密，也称私钥加密，指加密和解密使用相同密钥的加密算法。在对称加密算法中，发送端将明文和加密密钥一起经过特殊加密算法处理后，使其变成复杂的加密密文发送给接收端。接收端收到密文后，需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，从而恢复为可读的明文。一般发送端和接收端在安全通信之前商定加密密钥。
身份认证(identity authentication)：又称“验证”、“鉴权”，是指通过一定的手段，完成对用户身份的确认。
本申请实施例的技术方案可以应用于各种通信系统，包括但不限于：全球移动通讯(global system of mobile communication，GSM)系统、码分多址(code division multiple access，CDMA)系统、宽带码分多址(wideband code division multiple access，WCDMA)系统、通用分组无线业务(general packet radio service，GPRS)、长期演进(long term evolution，LTE)系统、LTE频分双工(frequency division duplex，FDD)系统、LTE时分双工(time division duplex，TDD)、通用移动通信系统(universal mobile telecommunication system，UMTS)、全球互联微波接入(worldwide interoperability for microwave access，WiMAX)通信系统、第五代(5th-generation，5G)移动通信系统(也称新空口(new radio，NR)系统)、窄带物联网(narrow band internet of things，NB-IoT)系统、增强型机器类型通信(enhanced machine-type communication，eMTC)系统或LTE机器到机器(LTE-machine-to-machine，LTE-M)系统以及未来的第六代移动通信系统等。
图1示出了本申请实施例的一种应用场景的示意图。如图1所示，该应用场景中可以包括第三方设备110和多个可以相互通信的设备120，其中该第三方设备110可以为该多个可以相互通信的设备120签发身份凭据(例如数字证书或公钥凭据，用于标识设备身份)，以使该多个可以相互通信的设备120之间能够建立安全可信的会话通道，相互传输数据提供分布式能力等。
该第三方设备110为被该多个可以相互通信的设备120所信任的设备。例如在云服务场景中该第三方设备110可以为云服务器，能够为登录或绑定云服务账号的多个设备120签发身份凭据。又如第三方设备110可以为普通的服务器，例如应用服务器、网站服务器、数据库服务器、邮件服务器等，能够为登录同一账号或者登录关联账号的多个设备120签发身份凭据。该多个可以相互通信的设备120基于第三方设备110签发的身份凭据可以在通信之前认证对端的身份，然后在认证完成后基于认证过的身份建立安全可信的会话通道。
上述第三方设备110为多个设备120签发身份凭据的过程，也就是设备可信身份建立的过程。可信身份建立的信任基础有多种，例如上述提到的云服务账号身份、应用账号身份、网站账号身份、邮件账号身份、关联账号身份等。为方便理解，下面以可信身份的信任基础为云服务账号身份为例，示例性描述设备可信身份的建立过程和设备间的身份认证过程。
参考图1，图中示例性的示出了该多个可以相互通信的设备120包括两个设备，即设备121和设备122，其中设备121和设备122都可以登录同一个云服务账号。第三方设备110可以为云服务器，可用于进行身份凭据管理。以设备121为例，在云服务场景中，设备121登录账号后，可以向第三方设备110申请一张用于标识本设备(即设备121)身份的身份凭据，该身份凭据经第三方设备110的私钥签过名，该身份凭据中包括与设备121的身份凭据对应的设备身份公钥，设备121则保存与身份凭据对应的设备身份私钥。类似地，设备122登录同一个账号后，也可以向第三方设备110申请一张用于标识设备122身份的身份凭据，该身份凭据也经第三方设备110的私钥签过名，身份凭据中包括与设备122的身份凭据对应的设备身份公钥，设备122则保存与身份凭据对应的设备身份私钥。如图1中的虚线所示，即表示设备注册身份凭据的过程。
当设备121与设备122之间进行通信时，通信双方需要认证对端的身份，设备121与设备122交换各自的身份凭据，并使用与第三方设备110签名所用的私钥对应的公钥验证对方的身份凭据的完整性和合法性。验证通过后，设备121和设备122基于与本设备的身份凭据对应的设备身份私钥和与对端的身份凭据对应的设备身份公钥进行协商，建立会话密钥，接下来就可以建立安全会话通道。如图1中的实线所示，即用于表示设备间进行身份认证的过程。
本申请实施例中的第三方设备110可以为终端设备或服务器，能够受其他一些设备的信任，并能够为其颁发身份凭据。例如第三方设备110可以是云服务器、应用服务器(例如专用的应用服务器、分布式应用服务器、对等的应用服务器等)、通信服务器(例如邮件服务器、传真服务器、文件传输协议(file transfer protocol，FTP)服务器等)、网站服务器、数据库服务器等，还可以是工作组级服务器、部门级服务器、企业级服务器等。
本申请实施例中的申请注册身份凭据的设备120可以指用户设备(user equipment，UE)、接入终端、终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、无线网络设备、用户代理或用户装置。设备120还可以是蜂窝电话(cellular phone)、无绳电话、会话启动协议(session initiation protocol，SIP)电话、智能电话(smart phone)、无线本地环路(wireless localloop，WLL)站、个人数字处理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调 器的其它设备、车载设备、可穿戴设备、无人机设备或物联网、车联网中的终端以及未来网络中的任意形态的终端、中继用户设备或者未来演进的公用陆地移动通信网络(public land mobile network，PLMN)中的终端等，本申请实施例对此并不限定。
基于一定信任基础的多个设备120可以向同一个第三方设备110申请注册身份凭据。本申请实施例中第三方设备110也可以称为签发设备，而向签发设备申请注册身份凭据的设备120可以称为申请设备。在注册身份凭据的过程中，申请设备需要向签发设备提供自身的设备身份公钥，并保存与设备身份公钥对应的设备身份私钥。
目前，现有技术提供两种注册身份凭据的方法。一种方式是申请设备向签发设备提交身份凭据申请信息(例如包括申请设备的设备信息、公钥信息、账号信息等)后，签发设备就可以为申请设备颁发身份凭据。另一种方式是申请设备上预置有用于保证注册流程安全性的公私钥对中的私钥，申请设备使用该私钥对身份凭据申请信息进行签名后再提交给签发设备，相应地，签发设备使用与申请设备签名的私钥对应的公钥对身份凭据申请信息进行验证，通过后为申请设备颁发身份凭据。
前者对发起身份凭据注册请求的设备没有限制，签发设备也没有对身份凭据申请信息是否来自于合法的设备进行验证，这样对于一些资源受限(例如安全存储性能低、不具备安全环境)的设备来说，其不能保证提交给签发设备的身份凭据申请信息是真实的。这样申请设备的注册过程可以被无限复制到其他恶意设备上，导致恶意设备在具有身份凭据申请信息的情况下就可以完成身份凭据的注册。后者将注册身份凭据的设备范围限定在具有安全环境的设备上，提高了身份凭据的注册流程的安全性，但这种方式需要在申请设备上预置用于保证注册流程安全性的私钥，在签发设备上预置对应的公钥。这种方式对申请设备的要求过高，很多设备难以实现产线预置逻辑，导致能够进行认证通信的设备覆盖面小，不能适应目前各种设备的发展。
因此，本申请实施例提供一种身份凭据的申请方法，能够提高设备注册身份凭据过程的安全性，并且能够提升认证设备覆盖面。
本申请实施例涉及多个实现不同功能的设备，为方便理解本申请，现说明如下。
第一设备为请求注册身份凭据的设备，在本申请实施例中也可以称为申请设备。第一设备为资源受限的设备或者无安全环境的设备(或称非安全环境设备)。第一设备资源受限可以理解为第一设备不能自己申请注册身份凭据，例如第一设备安全存储性能低，或者不能主动证明自己身份，或者不能证明自己发送给对方的信息是真实的。第一设备无安全环境可以理解为第一设备不能在设备身份凭据对应的公钥密码的生命周期内提供足够的安全保护，例如第一设备生成设备身份公私钥对后，第一设备在注册身份凭据过程中不能保证自己发送给对方的信息(例如公钥信息、设备信息等)不被篡改，或者在维护身份凭据的过程中不能保证身份凭据不被盗取，或者在第一设备在与其他设备交换身份凭据以进行身份认证时不能保证身份凭据不会被篡改等。
第二设备为已经注册过身份凭据的设备，即已经建立过可信关系的设备，在本申请实施例中也可以称为代理设备。第二设备可以为资源充分的设备或有安全环境的设备(或称安全环境设备)，也可以是资源受限或非安全环境设备。其中第二设备资源充足可以理解为第二设备能够自己直接向签发设备申请注册身份凭据，例如第二设备的安全存储性能较高，或者能够证明自己的身份，或者能够证明自己发送给对方的信息真实。第二设备有安 全环境可以理解为第二设备在设备身份凭据对应的公钥密码的生命周期内能够提供足够的安全保护，例如第二设备生成设备身份公私钥对后，第二设备在注册身份凭据过程中能够保证自己发送给对方的信息不会被篡改，或者在维护身份凭据的过程中能够保证身份凭据不会被盗取，或者在第二设备与其他设备交换身份凭据以进行身份认证时能够保证身份凭据不会被篡改等。第二设备资源受限或无安全环境的理解与上述第一设备资源受限或无安全环境类似，具体可参考上文描述，为简洁，不再赘述。换言之，本申请实施例中，第二设备为已经被第三方设备颁发过身份凭据的设备。
第三方设备为受其他设备(例如身份凭据的主体(所有者)和依赖身份凭据的一方)信任的、能够颁发设备身份凭据的设备，在本申请实施例中也可以称为签发设备。本申请实施例中签发设备在颁发身份凭据过程中，需要验证注册申请是否来自于合法的设备，即验证申请设备上传的身份凭据申请信息是否具有完整性保护。
以图1中的应用场景为例，设备122可以为第一设备，请求注册身份凭据；设备121可以为第二设备，已经注册过身份凭据；第三方设备110为第三方设备，用于签发身份凭据。作为示例而非限定，第一设备122与第二设备121可基于账号相互认证和通信，例如第一设备122和第二设备121可以为登录同一账号的设备，或者第二设备121为登录账号的设备，第一设备122为绑定账号的设备。本申请实施例中第一设备122可以连接网络，也可以不连接网络，本申请实施例不做限定。
本申请实施例涉及多个公钥密码(即公私钥对)，为方便理解本申请，现说明如下。
设备身份公钥密码，也称设备身份公私钥对，一般用于设备间认证过程，以证明设备身份。设备身份公私钥对包括设备身份公钥和设备身份私钥，其中设备身份私钥由设备本身私密保存，不可公开，而设备身份公钥可包括在设备的身份凭据中。每个设备在注册身份凭据前，都可以生成自己的设备身份公私钥对，并且需要将设备身份公钥提交给签发设备，用于签发身份凭据。本申请实施例涉及两个设备的设备身份公私钥对，分别为第一设备生成的第一设备的设备身份公私钥对，和第二设备生成的第二设备的设备身份公私钥对。
第三方设备的公钥密码，也称第三方设备的公私钥对，包括第三方设备的私钥和第三方设备的公钥。第三方设备的私钥由第三方设备私密保存，一般用于为其他设备颁发身份凭据时创建数字签名；第三方设备的公钥可位于具有第三方设备颁发的身份凭据的设备中，一般用于在设备间认证时校验身份凭据。
注册服务公钥密码，也称注册服务公私钥对，用于在身份凭据注册流程中对申请设备提交的申请信息进行完整性保护，以保证注册身份凭据流程的安全性。注册服务公钥密码包括注册服务公钥和注册服务私钥，其中注册服务公钥预置于颁发身份凭据的设备(例如第三方设备)中，注册服务私钥预置于需要注册身份凭据的设备(例如第二设备)中。本申请实施例中，由于第一设备资源受限或没有安全环境，以下以第一设备没有预置注册服务私钥为例进行描述。
图2示出了本申请实施例提供的一种身份凭据的申请方法的示意性流程图。图2中的方法200可由第一设备例如图1中的设备122、第二设备例如图1中的设备121和第三方设备例如图1中的第三方设备110执行，该方法200包括步骤S210至步骤S260。
在步骤S210，第一设备向第二设备发送第一消息。
该第一消息中包括第一设备的身份凭据申请信息，该第一设备的身份凭据申请信息可用于申请第一设备的身份凭据。
可选地，该第一设备的身份凭据申请信息可以包括以下信息的至少一种：第一设备的设备标识，第一设备的设备身份公钥，第一设备所登录账号的账号标识，第一设备所登录账号的账号登录凭据。
第一设备的设备标识可以为第一设备的设备地址(例如IP地址)、设备ID、设备标签(label)等。
第一设备的设备身份公钥和与公钥对应的设备身份私钥是一对公私钥对，由第一设备生成。第一设备的设备身份私钥由第一设备保密存储，第一设备的设备身份公钥则需要提供给签发身份凭据的设备。第一设备的设备身份公私钥对用于证明第一设备的设备身份。
第一设备所登录账号的账号标识可以是账号索引(user ID，UID)、账户名、UID所关联的用户识别卡(subscriber identity module，SIM)号码、UID所关联的其他应用账号ID等。账号标识可以在第一设备登录账号或绑定账号后获得。
第一设备所登录账号的账号登录凭据在第一设备登录账号或绑定账号后可以获得，账号登录凭据可以证明第一设备登录或绑定了账号，用于证明第一设备登录账号的有效性。
本申请实施例中，第一设备的身份凭据申请信息的发送方式有多种。
在一个示例中，第一设备可以将该第一设备的身份凭据申请信息中的各项信息可以直接发送给第二设备。
在另一示例中，第一设备可以将第一设备的身份凭据申请信息中的各项信息进行拼接后再发送给第二设备。
在又一个示例中，第一设备可以将第一设备的身份凭据申请信息中的各项信息加密后再发送给第二设备。例如在第一设备和第二设备登录同一账号的场景中，第一设备可以使用账号登录凭据对其他信息进行对称加密，相应地，第二设备可以使用账号登录凭据进行解密。
在步骤S220，第二设备使用第二设备的私钥对第一设备的身份凭据申请信息进行签名，或者使用对称密钥对第一设备身份凭据申请信息进行加密，得到处理后的身份凭据申请信息。
可选地，该第二设备的私钥可以为第二设备的注册服务私钥，或者为第二设备的设备身份私钥。
该第二设备的注册服务私钥和与该私钥对应的注册服务公钥为一对公私钥对，用于保证第二设备注册身份凭据的流程的安全性。第二设备的注册服务私钥可以是第二设备在产线预置的，或者通过应用程序获取的。注册服务公钥则保存于第三方设备中。
应理解，对于同一个颁发身份凭据的第三方设备，注册服务私钥和注册服务公钥可以只有一对，第三方设备保存注册服务公钥，注册身份凭据的设备保存注册服务私钥。如果多个设备可以向第三方设备申请注册身份凭据，则该多个设备可以保存有相同的注册服务私钥。这里“第二设备的注册服务私钥”仅用于表示第二设备具备注册服务私钥，不限定第二设备与注册服务私钥为一一对应关系。
该第二设备的设备身份私钥和与该私钥对应的设备身份公钥为一对公私钥对，由第二设备生成。第二设备的设备身份私钥由第二设备保密保存，第二设备的设备身份公钥则在 注册身份凭据的过程中需要提供给签发身份凭据的设备。因此第二设备的设备身份公钥可包含于第二设备的身份凭据中，还可以保存于签发身份凭据的第三方设备中。第二设备的设备身份公私钥对用于标识和证明第二设备的设备身份。
可选地，第二设备用来加密的对称密钥可以是预置于第二设备中的，也可以是在第二设备与第三方设备建立可信关系后由第三方设备发送给第二设备的。应理解，第二设备与第三方设备建立可信关系可以理解为第二设备完成了第二设备的身份凭据的注册流程，第三方设备为第二设备颁发了身份凭据。
可选地，在该步骤中，第二设备可以保存第一设备的身份凭据申请信息中的部分或全部信息，例如保存第一设备的设备标识、第一设备的设备身份公钥、第一设备所登录账号的账号标识、第一设备所登录账号的账号登录凭据等中的至少一项信息。
可选地，在该步骤中，第二设备可以生成为第一设备的身份凭据信息进行签名或加密的记录并保存，在一些实施例中，该记录也可以称为身份凭据代理申请记录。例如第二设备可以生成标识ID，用于标识此次代理申请记录。该代理申请记录可以包括第一设备的身份凭据申请信息中的部分或全部信息，用于指示第二设备为第一设备代理申请了身份凭据。即该代理申请记录用于指示第二设备为第一设备的身份凭据申请信息进行了签名，或者指示第二设备为第一设备的身份凭据申请信息进行了加密。
可选地，在该步骤中，第二设备可以生成第一设备的身份凭据对应的使用策略，该使用策略可以用于指示第一设备的身份凭据的有效信息。该使用策略可以包括以下信息的至少一项：第一设备的身份凭据的有效期，第一设备的身份凭据的有效认证次数，第一设备的身份凭据的认证对应关系等。其中第一设备的身份凭据的认证对应关系可以包括以下任意一种：第一设备只能与第二设备即代理设备进行身份认证；第一设备可以与任意设备进行身份认证；第一设备可以与第二设备、与第二设备相互信任的第四设备进行身份认证；第一设备可以与第二设备、与第三方设备相互信任的第四设备进行身份认证；第一设备可以与第二设备、与第二设备相互信任的设备、与第三方设备相互信任的设备进行身份认证。
第二设备签名使用的算法可以为RSA算法、数字签名算法(digital signature algorithm，DSA)、椭圆曲线数字签名算法(elliptic curves DSA，ECDSA)等，本申请实施例对此不做限定。
第二设备使用的加密算法可以为数据加密标准(data encryption standard，DES)算法、三重数据加密算法(Triple data encryption standard，TDEA)算法、国际数据加密算法(international data encryption algorithm，IDEA)、Blowfish算法、RC5算法等，本申请实施例对此不做限定。
在步骤S230，第二设备向第一设备发送第二消息。
该第二消息中包括步骤S220中得到的处理后的身份凭据申请信息。
可选地，第二消息中还可以包括第二设备的设备身份信息。第二设备的设备身份信息可用于标识第二设备为第一设备的身份凭据申请信息签名或加密，即可以标识第二设备为第一设备代理申请身份凭据。应理解，第二设备在第一设备的身份凭据申请信息上签名或加密，就可用于向签发设备证明第一设备的注册信息在提交过程中没有被篡改过。由于第二设备已注册过身份凭据，因而第二设备与第三方设备是相互信任的。本申请实施例中的“第二设备为第一设备代理申请身份凭据”可以理解为第三方设备是基于对第二设备的信 任，为第一设备签发身份凭据。
该第二设备的设备身份信息可以包括以下信息中的至少一种：第二设备的设备标识，第二设备的设备身份公钥，第二设备所登录账号的账号标识，第二设备所登录账号的账号登录凭据等。
可选地，第二消息中还可以包括第一设备的身份凭据的使用策略。例如步骤S220中第二设备所生成的使用策略，该使用策略用以通知第一设备其身份凭据的有效信息和认证信息等，其中有效信息例如包括身份凭据的有效期、有效认证次数等，认证信息例如包括身份凭据可以被哪些设备认可或认证。
在一些实施例中，第二设备可以保存该第一设备的身份凭据对应的使用策略，以用于和第一设备进行认证时，确认第一设备的身份凭据是否有效，或者确定是否与第一设备进行认证。
需要说明的是，本申请实施例中，第一设备的身份凭据是否有效，可以理解为第一设备的身份凭据是否符合上述第一设备的身份凭据对应的使用策略，例如第一设备的身份凭据是否在有效期内、第一设备的身份凭据是否具备有效认证次数等。换言之，本申请实施例中所述的第一设备的身份凭据是否有效指的是第一设备的身份凭据是否还满足对应的使用策略，即第一设备是否还可以基于该身份凭据与其他设备进行身份认证。
应理解，第二设备可以对上述第二设备的设备身份信息和/或第一设备的身份凭据的使用策略等进行签名，然后再发送给第一设备。
本申请实施例中，第二设备对第二消息中的信息进行签名的方式有多种。
作为一个示例，第二设备可以对第一设备的身份凭据申请信息、第二设备的设备身份信息、第一设备的身份凭据的使用策略等分别进行签名。
作为另一个示例，第二设备可以对第一设备的身份凭据申请信息和第二设备的设备身份信息进行签名，对第一设备的身份凭据的使用策略可以签名，也可以不签名。
作为又一个示例，第二设备可以对第一设备的身份凭据申请信息、第二设备的设备身份信息、第一设备的身份凭据的使用策略进行一次签名。
可选地，第二消息中还可以包括在步骤S210中第一设备发送的第一设备的身份凭据申请信息。即在步骤S230中第二设备将第一设备的身份凭据申请信息原文以及签名后的身份凭据申请信息一同再发送给第一设备。
应理解，如果采用加密方式，则第二设备对第二消息中的信息进行加密的方式与进行签名类似，只是将签名行为替换为加密，在此不再赘述。
在步骤S240，第一设备向第三方设备发送第三消息。
该第三消息包括步骤S230中得到的处理后的身份凭据申请信息，该处理后的身份凭据申请信息用于向第三方设备请求注册第一设备的身份凭据。本申请实施例中，第二设备与第三方设备相互信任，即第二设备已经在第三方设备注册了身份凭据。
可选地，该第三消息中还可以包括步骤S230中第一设备接收的第二设备的设备身份信息和/或第一设备的身份凭据的使用策略。
在一些实施例中，当采用签名方式时，该第三消息中还包括签名前的第一设备的身份凭据申请信息。这里可以理解为是第三方设备在验签时需要用到的原文。该第三消息中的第一设备的身份凭据申请信息可以是步骤S210中第一设备发送给第二设备的，也可以是 步骤S230中第二设备发送给第一设备的。换句话说，若步骤S230中的第二消息中不包括第一设备的身份凭据申请信息原文，则在步骤S240中第一设备可以将第一设备的身份凭据申请信息原文和第二设备签名后的身份凭据申请信息发送给第三方设备。若步骤S230中的第二消息中包括第一设备的身份凭据申请信息原文，则在步骤S240中第一设备可以直接向第三方设备转发第二设备发送的第二消息。
在步骤S250，第三方设备使用与第二设备的私钥对应的公钥或对称密钥对处理后的身份凭据申请信息进行验证。
应理解，若第二设备使用注册服务私钥对第一设备的身份凭据申请信息进行签名，则在该步骤中，第三方设备使用注册服务公钥对处理后的身份凭据申请信息进行验签。若第二设备使用设备身份私钥对第一设备的身份凭据申请信息进行签名，则在该步骤中，第三方设备使用设备身份公钥对处理后的身份凭据申请信息进行验签。若第二设备使用对称密钥对第一设备的身份凭据申请信息进行加密，则在该步骤中，第三方设备使用相同的密钥对处理后的身份凭据申请信息进行解密。
第二设备与第三方设备可以默认采用设备身份公私钥对和注册服务公私钥对中的一种进行签名和验签。或者第二设备可以在第三消息中指示第三方设备采用了哪种私钥进行了签名，从而指示第三方设备使用对应的公钥进行验签。例如第三消息中包括第二设备的设备标识可以指示第二设备使用了设备身份私钥进行签名，第三消息中不包括第二设备的设备标识可以指示第二设备使用了注册服务私钥进行签名。应理解，本领域技术人员可以根据实际需要选择合适的方式做指示，本申请实施例不做具体限定。在一些实施例中，第二设备与第三方设备可以默认采用对称加密的方式进行加密和解密。
当第二设备使用注册服务私钥进行签名时，可以实现第一设备上传的身份凭据申请信息的完整性保护。当第二设备使用设备身份私钥进行签名时，不仅可以实现第一设备上传的身份凭据申请信息的完整性保护，还可以使第三方设备确定签名是否是已注册身份凭据的设备所创建。当第二设备使用对称密钥进行加密，可以实现第一设备上传的身份凭据申请信息的完整性保护。
由于第一设备的身份凭据申请信息经过的第二设备的私钥签名，或者使用了对称密钥进行加密，并且第二设备具有注册服务私钥或者已经在第三方设备上注册了身份凭据，所以第二设备与第三方设备为相互信任的设备。本申请实施例中第二设备对第一设备的身份凭据申请信息的签名可以用于证明第一设备发送的用于注册身份凭据的信息的完整性，提升了身份凭据注册过程的安全性。
相应地，在该步骤中，第三方设备可以校验第一设备的身份凭据申请信息上的签名是否为已注册身份凭据的第二设备的合法签名，还可以校验签名数据的完整性。或者，在采用加密方式的情况下，第三方设备可以使用自身保存的对称密钥对处理后的身份凭据申请信息进行解密，解密成功则说明第二设备加密使用的密钥与第三方设备解密使用的密钥相同。
在第一设备与第二设备的信任基础为账号身份时，例如第一设备与第二设备登录同一个账号，或者登录关联账号，第三方设备还可以校验第一设备的账号登录凭据是否有效，例如校验第一设备的账号登录状态是否有效等。
在步骤S260，对处理后的身份凭据申请信息验证通过后，第三方设备为第一设备签 发身份凭据。
第一设备的身份凭据中可以包括第一设备的身份凭据申请信息。其中第一设备的身份凭据申请信息可以与步骤S210中第一设备发送给第二设备的身份凭据申请信息相同，也可以包括其中部分信息例如第一设备的设备身份公钥、第一设备的设备标识等。
第一设备的身份凭据中还可以包括其他一些信息，例如为第一设备代理申请身份凭据的第二设备信息，第一设备的身份凭据的用途和来源信息，第一设备的身份凭据为临时身份凭据的信息，或者第一设备的身份凭据的使用策略(例如有效期、有效认证次数、是否仅能与第二设备相互认证)信息等。
相应地，在步骤S260之后，第一设备接收到第三方设备发送的身份凭据，可以使用第三方设备对身份凭据进行签名的私钥所对应的公钥对身份凭据进行验签，验证通过后可以将第三方设备签发的身份凭据保存。
本申请实施例中第二设备预置有注册服务私钥、对称密钥或者已经在第三方设备处注册身份凭据，因此第二设备与第三方设备是相互信任的。第一设备由于资源受限或没有安全环境，不能够直接在第三方设备上注册身份凭据。由于设备身份凭据涉及密钥的存储、使用等，考虑密钥生命周期的安全保护，第三方签发设备对注册身份凭据的设备具有一定要求，需要验证注册申请来自合法的设备，且其上传的申请信息需有完整性保护，特别是与设备身份绑定的公钥没有被篡改。本申请实施例提供了一种代理申请身份凭据的方法，即通过第二设备对第一设备的身份凭据申请信息进行签名或加密，以确保第一设备向第三方设备发送信息的安全性和完整性。第三方设备基于与第二设备的信任关系，在对第一设备的身份凭据申请信息的验证通过后即可为第一设备颁发身份凭据。这样由与签发设备具有信任关系的第二设备代理申请其他与第二设备具有信任基础的设备的身份凭据，能够向签发设备证明设备身份凭据注册流程没有被篡改，消减了第一设备因安全能力不足，无法向第三方设备证明身份凭据完整性的风险，提升了设备身份凭据注册的安全性。另外一些与第二设备具有信任基础的设备，虽然自己不能注册身份凭据，但是可以请求第二设备代理申请，可以增加能够注册身份凭据的设备数量，提升认证设备的覆盖面。
上文提到，第二设备与第三方设备是相互信任的，这是因为第二设备在代理申请第一设备的身份凭据之前，需要完成本设备身份凭据的注册。本申请实施例中，第二设备的身份凭据可以为第二设备自主申请，也可以为由其他设备代理申请。当第二设备的身份凭据为其他设备代理申请时，申请过程与上述步骤S210至步骤S260类似。下面仅简要介绍一下第二设备自主申请身份凭据的过程，即本申请实施例提供的身份凭据的申请方法的预处理阶段。
第二设备中预置有用于保证注册流程安全性的注册服务私钥，第三方设备则预置有与注册服务私钥对应的公钥。在申请注册凭据时，第二设备使用注册服务私钥对身份凭据申请信息进行签名，并将签名后的身份凭据申请信息发送给第三方设备。第二设备的身份凭据申请信息与上述步骤S210中第一设备的身份凭据申请信息内容类似，只是具体信息用于描述第二设备。例如第二设备的身份凭据申请信息包括第二设备的设备标识、第二设备的设备身份公钥等信息。第三方设备使用注册服务公钥对接收到的身份凭据申请信息进行验签，验证注册请求的完整性后，即可以为第二设备签发身份凭据。同时，第三方设备可以存储第二设备的相关信息，例如第二设备的设备标识、第二设备的设备身份公钥等，并 维护相关信息。第三方设备中预置有第三方设备的私钥，第二设备中预置有第三方设备的公钥，第三方设备对第二设备的身份凭据做了签名，第二设备接收到身份凭据后使用第三方设备的公钥对身份凭据的签名进行验签，验签通过即可保存身份凭据。这样第二设备注册身份凭据的过程完成。
应理解，第三方设备的公钥可以在产线时预置于第二设备中，也可以通过广播发送给第二设备，还可以通过应用程序获取，本申请实施例不做限定。应理解，由第三方设备签发身份凭据的设备均需要通过上述几种方式获取到第三方设备的公钥，以用于验证身份凭据的签名。
可选地，在第三方设备为第二设备颁发身份凭据时，第三方设备还可以向第二设备发送对称密钥，以用于第二设备为其他设备代理申请身份凭据。
可选地，在预处理阶段，第二设备也可以使用预置的对称密钥对身份凭据申请信息进行加密，相应地，第三方设备使用与加密密钥相同的密钥进行解密，然后对解密出来的信息进行验证，若验证通过，则为第二设备颁发身份凭据。其中第二设备加密与第三方设备解密的过程与现有技术相同，在此不再详述。
图3示出了本申请实施例提供的另一种身份凭据的申请方法的示意性流程图。图3中的方法300可由第一设备、第二设备和第三方设备执行，该方法300包括步骤S310至步骤S360。
在步骤S310，第一设备向第二设备发送第一消息。该第一消息中包括第一设备的身份凭据申请信息，该第一设备的身份凭据申请信息可用于申请第一设备的身份凭据。
步骤S310与方法200中的步骤S210类似，具体参考上文描述，在此不再赘述。
在步骤S320，第二设备使用第二设备的私钥对第一设备的身份凭据申请信息进行签名，或者使用对称密钥对第一设备的身份凭据申请信息进行加密，得到处理后的身份凭据申请信息。
步骤S320与方法200中的步骤S220类似，具体参考上文描述，在此不再赘述。
在步骤S330，第二设备向第三方设备发送第三消息。
该第三消息包括步骤S320中得到的处理后的身份凭据申请信息，该处理后的身份凭据申请信息用于向第三方设备请求注册第一设备的身份凭据。第二设备与第三方设备相互信任。
该第三消息中还可以包括第二设备的设备身份信息。
该第二设备的设备身份信息可以包括以下信息中的至少一种：第二设备的设备标识，第二设备的设备身份公钥，第二设备所登录账号的账号标识，第二设备所登录账号的账号登录凭据等。
可选地，第三消息中还可以包括第一设备的身份凭据使用策略，例如第一设备的身份凭据的有效期、身份凭据的有效认证次数、身份凭据可以被哪些设备认可或认证等。
在一些实施例中，第二设备可以保存该第一设备的身份凭据对应的使用策略，以用于和第一设备进行认证时，确认第一设备的身份凭据是否符合该使用策略，或者确定是否与第一设备进行认证。
在该步骤中，在使用第二设备的私钥对第一设备的身份凭据申请信息进行签名的情况下，第三消息中还可以包括在步骤S310中第一设备发送的第一设备的身份凭据申请信息。 即在步骤S330中第二设备将第一设备的身份凭据申请信息原文以及经第二设备的私钥签名后的身份凭据申请信息一同发送给第三方设备，以为第一设备代理申请身份凭据。
应理解，步骤S310中第三消息所包括的信息以及信息的签名或加密方式与方法200的步骤S240中第三消息类似，具体可参考相关描述，在此不再赘述。
在步骤S340，第三方设备使用与第二设备的私钥对应的公钥或对称密钥对处理后的身份凭据申请信息进行验证。
该步骤与方法200中的步骤S250类似，具体可参考上文描述，在此不再赘述。
在步骤S350，第三方设备向第二设备发送第四消息。
该第四消息中包括第一设备的身份凭据。
第一设备的身份凭据中可以包括第一设备的身份凭据申请信息。其中第一设备的身份凭据申请信息可以与步骤S310中第一设备发送给第二设备的身份凭据申请信息相同，也可以包括其中部分信息例如第一设备的设备身份公钥、第一设备的设备标识等。
第一设备的身份凭据中还可以包括其他一些信息，例如为第一设备代理申请身份凭据的第二设备信息，第一设备的身份凭据的用途和来源信息，第一设备的身份凭据为临时身份凭据的信息，或者第一设备的身份凭据的使用策略(例如有效期、有效认证次数、是否仅能与第二设备相互认证)信息等。
在步骤S360，第二设备向第一设备发送第五消息。
该第五消息包括步骤S340中得到的第一设备的身份凭据。换言之，在该步骤中，第二设备将第三方设备为第一设备签发的身份凭据转发给第一设备。
简单来说，方法300与方法200不同之处在于，方法200是在第二设备对身份凭据申请信息处理后由第一设备向第三方设备发起注册请求，相应地，第三方设备签发的身份凭据直接发送给第一设备；而方法300是在第二设备对身份凭据申请信息处理后由第二设备向第三方设备发起注册请求，相应地，第三方设备签发的身份凭据先发送给第二设备，再由第二设备转发给第一设备。
在一些实施例中，方法300还可以包括步骤S370，第二设备保存该第一设备的身份凭据。该第一设备的身份凭据可以包含于身份凭据代理申请记录中。
应理解，步骤S370可以在步骤S350之后执行，也可以在步骤S360之后执行，本申请实施例不做限定。
本申请实施例提供的身份凭据的申请方法中，通过第二设备对第一设备的身份凭据申请信息进行签名或加密，以确保第一设备向第三方设备发送信息的安全性和完整性。第三方设备基于与第二设备的信任关系，在对第一设备的身份凭据申请信息的验证通过后即可为第一设备颁发身份凭据。这样由与签发设备具有信任关系的第二设备代理申请其他与第二设备具有信任基础的设备的身份凭据，能够向签发设备证明设备身份凭据注册流程没有被篡改，能够保证设备身份凭据注册的安全性。另外一些与第二设备具有信任基础的设备，虽然自己不能注册身份凭据，但是可以请求第二设备代理申请，可以增加能够注册身份凭据的设备数量，提升认证设备的覆盖面。
为更好地理解本申请，作为示例而非限定，下面结合附图4更加详细地描述本申请实施例提供的身份凭据的申请方法。本申请实施例以第一设备和第二设备的信任基础为云服务账号身份、第二设备为第一设备的身份凭据申请信息进行签名为例进行说明，但如上所 述，本申请实施例提供的方法同样可以应用于第一设备与第二设备基于其他信任基础建立可信身份的场景。图4所示的方法400包括步骤S401至步骤S412。
在执行本申请实施例提供的身份凭据的申请方法之前，第二设备需要先注册身份凭据。具体地，第二设备登录云服务账号后，可以获取到账号标识和登录凭据，并生成设备身份公私钥对。第二设备发起身份凭据注册请求，向签发身份凭据的设备(即第三方设备)发送身份凭据申请信息。第三方设备验证完注册请求完整性后签发身份凭据。在第一设备想要注册身份凭据时，执行如下步骤。
在步骤S401，第一设备(即申请设备)登录云服务账号，并获取账号标识和账号登录凭据。
这里第一设备获取的账号标识例如可以是账号索引UID、账户名、UID所关联的SIM号码、UID所关联的其他应用账号ID等。
在步骤S402，第一设备生成本设备的设备身份公私钥对。
在该步骤中，第一设备生成用于标识第一设备身份的公私钥对，即第一设备的设备身份公私钥对。
在步骤S403，第一设备生成身份凭据申请请求。该身份凭据申请请求可以承载于上述方法200或方法300中的第一消息中。
在该步骤中，第一设备可以基于账号标识、账号登录凭据、第一设备的设备标识以及第一设备的设备身份公钥等信息生成该身份凭据申请请求。例如，第一设备可以将上述信息不做处理直接生成身份凭据申请请求，或者将上述信息进行拼接生成身份凭据申请请求，或者将上述进行加密生成身份凭据申请请求，本申请实施例不做限定。
本申请实施例中第一设备与第二设备不同的是，第二设备预置有用于保证注册流程安全性的注册服务私钥，这样第二设备在注册身份凭据的过程中，可以对第二设备的身份凭据申请请求进行签名，从而可以保证发送给签发设备的信息的完整性。但第一设备由于资源受限或没有安全环境，第一设备中没有预置上述注册服务私钥，因此本申请实施例将第一设备的身份凭据申请请求发送给已经注册身份凭据的第二设备，通过第二设备的私钥对第一设备的身份凭据的申请请求进行签名，从而保证请求注册第一设备的身份凭据的过程中的信息的完整性。第二设备已经在签发设备处注册了身份凭据，因而第二设备与签发设备相互信任。
在步骤S404，第一设备将生成的身份凭据申请请求发送给第二设备。
在步骤S405a，第二设备使用本设备的私钥对第一设备的身份凭据申请请求进行签名。
可选地，第二设备也可以在第一设备的身份凭据申请请求中添加第二设备的设备信息等。因此，步骤S405a也可以替换为步骤S405b，第二设备使用本设备的私钥对第一设备的身份凭据申请请求和和本设备的设备信息进行签名。
本申请实施例中，第二设备在第一设备的身份凭据申请请求中添加第二设备的设备信息，可用于指示第一设备在获取身份凭据后是否只能与该第二设备进行相互认证。
可选地，第二设备还可以在第一设备的身份凭据申请请求添加第一设备身份凭据的使用策略等信息。
在步骤S406，第二设备生成身份凭据代理申请记录。
示例性的，在该步骤中第二设备可以生成用于标识此次代理申请身份凭据的记录标 识，并保存申请设备的相关信息，例如步骤S404中获取的第一设备的身份凭据申请请求中的信息。
应理解，该步骤为可选步骤，若不限定代理设备与申请设备的一一对应的认证关系，则第二设备也可以不保存为第一设备的身份凭据申请请求进行签名的记录。但应理解，第二设备执行了该步骤，也可以不限定代理设备与申请设备的一一对应的认证关系。
在步骤S407，第二设备将签名后的身份凭据申请请求发送给第一设备。
应理解，该步骤中签名后的身份凭据申请请求相比签名前的身份凭据申请请求而言，可以只是在是否使用了第二设备的私钥进行签名存在区别，但也可以在签名数据上存在区别，例如第二设备可以在签名前的身份凭据申请请求中增加第二设备的设备信息后再进行签名。该步骤中第二设备向第一设备发送的信息具体可以根据步骤S405a至步骤S406相应确定。该步骤中，签名后的身份凭据申请请求可以承载于上述方法200中的第二消息中。
在步骤S408，第一设备将签名后的身份凭据申请请求和签名前的身份凭据申请请求发送给第三方设备(即签发设备)。
本申请实施例中第一设备将签名和原文分开发送，可以方便第三方设备进行验签。在其他一些实施例中，第二设备也可以将原文和签名以JWT形式发送给第三方设备，本申请实施例不做限定。该步骤中，签名后的身份凭据申请请求和签名前的身份凭据申请请求可以承载于上述方法200中的第三消息中。
在步骤S409，第三方设备进行验签，主要包括校验签名的合法性，校验签名数据的完整性，校验第一设备的账号登录状态的有效性。
本申请实施例中，第三方设备校验签名的合法性，可以理解为第三方设备校验第一设备发送的签名后的身份凭据申请请求的签名是否为已注册身份凭据的设备(即第二设备)的合法签名。具体地，在步骤S401之前，第二设备已经在第三方设备上注册了第二设备的身份凭据，第三方设备上保存有第二设备的设备标识和第二设备的设备身份公钥等信息。本申请实施例中，若第二设备使用了第二设备的设备身份私钥进行签名，则第三方设备可以使用保存的第二设备的设备身份公钥进行验签；若第二设备使用了注册服务私钥进行签名，则第三方设备可以使用注册服务公钥进行验签。在第二设备使用注册服务私钥进行签名的情况下，第二设备可以是还未注册身份凭据，但由于第二设备具有注册服务私钥，也可以认为第三方设备与第二设备是相互信任的。
本申请实施例中，第三方设备校验签名数据的完整性，可以理解为第三方设备判断第二设备签名中的数据与第一设备上传的原文是否一致，是否被篡改。
本申请实施例中，第三方设备校验第一设备的账号登录状态的有效性，可以理解为第三方设备需要判断第一设备是否登录了云服务账号，即判断第一设备的账号登录合法性。
在步骤S410，经过验签后，第三方设备使用本设备的私钥签发第一设备的身份凭据。
具体地，第三方设备可以使用第三方设备的私钥对第一设备的身份凭据申请信息及其他相关信息进行签名，作为身份凭据下发给第一设备。本申请实施例中第一设备的身份凭据申请信息可以包括第一设备向第三方设备提交的身份凭据申请请求中的部分或全部信息，例如账号标识、第一设备的设备标识、第一设备的设备身份公钥等。本申请实施例中的其他相关信息可以包括与代理设备有关的信息，例如第二设备的设备标识、第二设备的设备身份公钥、用于表示第一设备的身份凭据为第二设备代理申请的信息、用于表示第一 设备的身份凭据的用途和来源信息、用于表示第一设备的身份凭据的使用策略信息(例如身份凭据有效期、身份凭据的有效认证次数等)等。
在步骤S411，第三方设备向第一设备签发第一设备的身份凭据。
在步骤S412，第一设备对第三方设备下发的身份凭据进行验签，验签通过后保存身份凭据。
该步骤中，第一设备对身份凭据进行验签的过程，即是用与第三方设备对身份凭据进行签名时使用的私钥对应的公钥对身份凭据进行验证，验证身份凭据的合法性和完整性。
本申请实施例中，第一设备的资源有限或没有安全环境，不能自己申请注册身份凭据，而第二设备具有足够的安全环境，能够保证注册身份凭据流程的安全性。因此，当第一设备请求与登录了相同云服务账号的第二设备通信时，可以由通信对端的第二设备代理签发第一设备的身份凭据申请请求，即通过第二设备在第一设备的身份凭据申请请求上签名，以向第三方设备证明第一设备上报申请信息的完整性。这样既能够保证第一设备在注册身份凭据流程的安全性，还可以使一些能够登陆账号但是没有安全环境或资源受限的设备注册身份凭据，提升了认证设备覆盖面。另外，第二设备可以在本地维护身份凭据代理申请记录，在第一设备获取到第三方设备颁发的身份凭据后，第二设备可以通过该身份凭据与本地维护的代理记录认证资源受限或没有安全环境设备所属的账号。
本申请实施例中，方法400还可包括步骤S413a，第二设备生成第一设备的身份凭据的使用策略。本申请实施例对步骤S413a的执行顺序不做具体限定，第二设备可以在步骤S404之后、步骤S407之前执行。
该使用策略用于指示第一设备的身份凭据的有效信息和认证信息等，例如该身份凭据使用的有效期、有效认证次数、是否与第二设备为一一认证关系等。
当然，在其他一些实施例中，第一设备的身份凭据的使用策略也可以由第三方设备生成，即步骤S413a可以替换为步骤S413b。本申请实施例对步骤S413b的执行顺序不做具体限定，第三方设备可以在步骤S401之后、步骤S411之前执行。
可选地，在一些实施例中，在步骤S411之后，第一设备还可以把第三方设备签发的身份凭据发送给第二设备，相应地，第二设备可以存储第一设备的身份凭据，用于后续设备间认证用。
可选地，在一些实施例中，在步骤S411，第三方设备还可以直接把第一设备的身份凭据发送给第一设备和第二设备。
本申请实施例中，在步骤S409中若校验未通过，则直接结束身份凭据的注册过程。第三方设备可以在步骤S411中向第一设备发送注册失败或者拒绝注册的消息。
本申请实施例对方法400中的步骤执行顺序不做具体限定，在一些实施例中，部分步骤可以同时执行，或者颠倒顺序执行，具体可以根据实际相应确定。
应理解，图4中的方法400是以由第二设备签名、第一设备自己向第三方设备发起注册身份凭据的流程为例进行说明，对于由第二设备签名并且由第二设备发起注册身份凭据流程的过程，其过程类似，在此不再详述。
在获取到身份凭据之后，第一设备可以基于身份凭据与其他设备进行通信。
在一些实施例中，第一设备可以与多个设备进行身份认证，即第一设备可以和任意一个与第一设备具有信任基础的设备进行通信。例如在第一设备的身份凭据中不包括代理设 备的相关信息时，其他设备默认可以与第一设备进行身份认证。
在另一些实施例中，第一设备可以只与代理申请身份凭据的设备进行身份认证。例如在第一设备的身份凭据中包括了代理设备的相关信息，其他非代理设备根据代理设备的相关信息可以确定不与第一设备进行身份认证。当代理设备与申请设备为一一对应关系时，代理设备只能认证代理申请过身份凭据的设备，申请设备只能与为其代理申请过身份凭据的设备进行认证。应理解，本申请实施例中“代理设备与申请设备为一一对应关系”可以理解为代理设备为申请设备代理申请的身份凭据只能用于申请设备与该代理设备之间的身份认证，而不能用于与其他设备之间的身份认证。
可选地，若第一设备想要与多个设备进行身份认证，则第一设备可以分别请求每个设备为其代理申请身份凭据。多个设备为第一设备代理申请的身份凭据可以是相同的，也可以是不同的，本申请实施例不做限定。为第一设备代理申请身份凭据的设备可以保存代理申请记录和/或第一设备的设备标识等信息，通过这些信息可以确定是否为第一设备代理申请过身份凭据，从而确定是否可以与第一设备进行身份认证。
在另一些实施例中，第一设备可以与代理申请身份凭据的设备以及与代理设备相互信任的设备进行身份认证。例如在第一设备的身份凭据中包括了代理设备的相关信息，其他与代理设备具有信任关系的设备根据代理设备的相关信息可以确定与第一设备进行身份认证。也就是说，其他与代理设备相互信任的设备可以基于对代理设备的信任而与第一设备进行身份认证。应理解，本申请实施例中，其他设备与代理设备相互信任可以理解为其他设备与代理设备已经进行了身份认证，或者其他设备与代理设备由同一第三方设备颁发的身份凭据等。
在另一些实施例中，第一设备可以与代理申请身份凭据的设备以及与签发身份凭据的设备相互信任的设备进行身份认证。例如在第一设备的身份凭据中包括了签发设备的相关信息，其他与签发设备相互信任的设备根据第一设备的身份凭据可以确定该身份凭据由第三方设备颁发，从而确定与第一设备进行身份认证。也就是说，其他与签发设备相互信任的设备可以基于对签发设备的信任而与第一设备进行身份认证。
在另一些实施例中，第一设备可以与代理申请身份凭据的设备、与代理设备相互信任的设备、与签发设备相互信任的设备进行身份认证。例如在第一设备的身份凭据中包括了签发设备的相关信息和代理设备的相关信息，其他与签发设备相互信任的设备可以基于对签发设备的信任与第一设备进行身份认证，其他与代理设备相互信任的设备可以基于对代理设备的信任与第一设备进行身份认证。
由于第一设备资源受限或没有安全环境，因为第一设备的身份凭据存在被窃取的风险，当第一设备的身份凭据被复制到其他恶意设备上时，这些设备可以和合法设备基于身份凭据进行身份认证，建立会话，因而存在安全风险。本申请实施例中，当代理设备与申请设备为一一对应关系时，可以通过代理设备来控制申请设备的认证情况，从而提高安全性。在另一些实施例中，申请设备可以与代理设备、与代理设备相互信任的设备、与签发设备相互信任的设备中的至少一个进行身份认证，可以控制申请设备的认证情况，提高安全性，还可以提升与第一设备进行认证的覆盖面。
图5示出了本申请实施例提供的一种身份认证的方法的示意性流程图。图5的方法500主要由第二设备执行，第二设备例如可以是图1中的设备121，即上文中为第一设备 代理申请身份凭据的设备。
作为一个示例，第二设备与第一设备的认证关系为一一对应，即第一设备只与为其代理申请身份凭据的设备进行身份认证，则该方法500可以包括步骤S510至步骤S540。
在步骤S510，第一设备向第二设备发送身份认证请求。
该身份认证请求包括第一设备的身份凭据和第一设备的设备标识。
可选地，第一设备的设备标识可以包括以下信息至少一种：第一设备的设备地址、设备ID、设备标签。
在步骤S520，第二设备根据第一设备的设备标识确定第一设备的身份凭据为第二设备为第一设备代理申请。
可选地，作为示例而非限定，该步骤的一个具体实现方式可以为：第二设备根据第一设备的设备标识查询到与第一设备对应的身份凭据代理申请记录；根据该身份凭据代理申请记录确定第一设备的身份凭据为第二设备为第一设备代理申请。
该身份凭据代理申请记录是在第二设备为第一设备代理注册身份凭据时生成并保存的，用于指示第二设备为第一设备代理申请身份凭据。具体地，该代理申请记录可以包括第一设备的设备标识、第一设备的设备身份公钥、第一设备的身份凭据以及其他与第一设备身份相关的信息等。
在步骤S530，第二设备根据第一设备的身份凭据对应的使用策略确定第一设备的身份凭据是否符合该使用策略。
本申请实施例中第一设备与第二设备为一一对应的关系。考虑到第一设备需要在一定时间内持久化存储身份凭据以及身份凭据对应的私钥，以在第一设备发起认证时无需重复连接第三方服务器进行申请，同时考虑到第一设备的资源有限和安全环境不足的情况，第二设备在为第一设备代理申请身份凭据时可以指定第一设备的身份凭据的使用策略，以指示第一设备的身份凭据的有效信息。在第一设备与第二设备认证过程中，第二设备根据使用策略确定第一设备的身份凭据是否有效(即是否符合使用策略)，若有效则可以继续执行下一步，若无效则可以为第一设备重新代理申请身份凭据，或者拒绝与第一设备进行身份认证。
在步骤S540，在第一设备的身份凭据符合该使用策略的情况下，第二设备对第一设备的身份凭据进行合法性和完整性校验。
该步骤中，具体地，第二设备可以使用签发身份凭据的设备的公钥对身份凭据进行验签，从而校验身份凭据是否为签发设备颁发以及在传送身份认证请求过程中信息是否被篡改。
校验通过后，第二设备与第一设备则可以进行会话密钥协商。
该步骤与现有技术中设备间认证过程中的密钥协商过程相同，下面仅做简要介绍。具体地，第二设备对第一设备的身份凭据校验通过后，将自己的身份凭据发送给第一设备，第一设备同样使用签发设备的公钥对第二设备的身份凭据进行验签。验签通过后第一设备与第二设备进行密钥协商，并建立会话密钥，之后便可以基于会话密钥建立安全的会话通道进行通信。
在一些实施例中，该方法500还包括：第二设备根据第一设备的设备标识查询第一设备的身份凭据的使用策略，该使用策略用于指示所述身份凭据的有效信息；根据该使用策 略确定是否需要更新第一设备的身份凭据。
本申请实施例中，第一设备的身份凭据是第二设备代理申请的，因而可以对第一设备的身份凭据确定使用策略，该使用策略可以指示第一设备的身份凭据的有效期或者有效认证次数。这样第二设备根据该使用策略可以确定第一设备的身份凭据是否需要更新或者是否需要重新进行代理申请等，以提升第一设备的身份凭据维护过程的安全性。
作为另一个示例，第二设备与第一设备的认证关系为一一对应时，上述步骤S510中，第一设备向第二设备发送的身份认证请求中包括第一设备的身份凭据，该第一设备的身份凭据包括第二设备的设备身份信息。在步骤S520中，第二设备根据第二设备的设备身份信息确定第一设备的身份凭据为第二设备为第一设备代理申请。步骤S530和步骤S540如上所述。也就是说，第二设备可以根据第一设备的身份凭据中包括的第二设备的设备身份信息可以确定自己为第一设备代理申请了身份凭据。
作为又一个示例，第一设备可以基于第二设备代理申请的身份凭据与第四设备进行身份认证。其中该第四设备可以与第二设备相互信任，或者与签发身份凭据的设备相互信任。
例如，第四设备为与第二设备相互信任的设备，则方法500包括步骤S501、S502a、S503。在步骤S501，第一设备向第四设备发送身份认证请求，该身份认证请求中包括第一设备的身份凭据。本申请实施例中第一设备的身份凭据包括第二设备的设备身份信息。在步骤S502a，第四设备根据第一设备的身份凭据确定第一设备的身份凭据为第二设备为第一设备代理申请。由于第四设备与第二设备相互信任，因此在步骤S503中，第四设备根据第一设备的身份凭据对应的使用策略确定是否与第一设备进行身份认证。或者在该步骤中，第四设备可以确定与第一设备进行身份认证。
再如，第四设备为与第三方设备相互信任的设备，则方法500包括步骤S501、S502b、S503。在步骤S501，第一设备向第四设备发送身份认证请求，该身份认证请求中包括第一设备的身份凭据。本申请实施例中第一设备的身份凭据中包括签发设备即第三方设备的信息。在步骤S502b，第四设备根据第一设备的身份凭据确定第一设备的身份凭据为第三方设备颁发。由于第四设备与第三方设备相互信任，因此在步骤S503中，第四设备根据第一设备的身份凭据对应的使用策略确定是否与第一设备进行身份认证。或者在该步骤中，第四设备可以确定与第一设备进行身份认证。
作为又一个示例，不论第一设备与第二设备是否为一一对应关系，第一设备向第二设备发送身份认证请求，该身份认证请求中的身份凭据包括第二设备的设备身份信息。第二设备可以根据第二设备的设备身份信息确定该身份凭据为第二设备代理申请，则第二设备可以确定与第一设备进行身份认证。
为更好地理解本申请，作为示例而非限定，下面结合附图6更加详细地描述本申请实施例提供的身份认证方法。本申请实施例以第一设备和第二设备的信任基础为云服务账号身份、第一设备向第二设备请求身份认证为例进行说明，但如上所述，本申请实施例提供的方法同样可以应用于第一设备与第二设备基于其他信任基础建立可信身份的场景。图6所示的方法600包括步骤S601至步骤S609。
在步骤S601，第一设备向第二设备发送身份认证请求。
第一设备与第二设备登录同一云服务账号，第一设备发起与第二设备的同账号认证。
该身份认证请求用于请求与第二设备进行身份认证，同时该身份认证请求还请求第二 设备的身份凭据。该身份认证请求中包括第一设备的设备标识和第一设备的身份凭据。
在步骤S602，第二设备接收到身份认证请求后，根据第一设备的设备标识查询是否存在与该设备标识对应的身份凭据代理申请记录。
该步骤中第二设备需要确认是否为第一设备代理申请过身份凭据。如身份凭据的申请方法中所述，代理设备为申请设备的身份凭据申请信息签名后，即代理设备为申请设备代理注册身份凭据时，代理设备可以保存申请的设备的相关信息例如设备标识、设备身份公钥等信息并生成身份凭据代理申请记录。具体内容可参考图2至图4中的相关描述，为简洁，在此不再赘述。
本申请实施例中以申请设备(即第一设备)只可以与代理设备(即第二设备)进行身份认证为例进行说明，因而第二设备需要确认是否为第一设备代理申请过身份凭据。
在步骤S603，若存在身份凭据代理申请记录，第二设备根据第一设备的身份凭据对应的使用策略确定该身份凭据是否符合该使用策略。
第一设备的身份凭据的使用策略用于指示第一设备的身份凭据的有效信息，具体内容可以参考上文相关描述，为简洁，在此不再赘述。
相应地，若不存在身份凭据代理申请记录，第二设备可以认为没有为第一设备代理申请过身份凭据，第二设备与第一设备可以按照现有流程进行身份认证。
在步骤S604，在第一设备的身份凭据符合使用策略的情况下，第二设备对第一设备的身份凭据进行合法性和完整校验。
相应地，若第一设备的身份凭据不符合使用策略即失效的情况下，例如超过有效期限或者超过有效认证次数，第二设备可以拒绝与第一设备进行身份认证，或者第二设备为第一设备重新代理申请身份凭据。
在步骤S605，验证通过后，第二设备基于第二设备的设备身份私钥与第一设备的设备身份公钥，建立会话密钥。
在步骤S606，第二设备查询第一设备的身份凭据的使用策略，确定下次认证前是否需要更新第一设备的身份凭据。
在该步骤中，第二设备可以根据本次认证信息更新本地维护的身份凭据代理申请记录，并确定第一设备的身份凭据的有效信息，确定下次身份认证前是否需要重新申请身份凭据。或者第二设备可以通知第一设备其身份凭据即将失效，本次身份认证过程后需要为第一设备重新代理申请身份凭据。
在步骤S607，第二设备向第一设备返回第二设备的身份凭据。
可选地，若在步骤S606中确定第一设备需要更新身份凭据或者有效期到期，则在该步骤中第二设备可以将相关信息通知给第一设备。
在步骤S608，第一设备接收到第二设备的身份凭据后，对第二设备的身份凭据进行合法性和完整性校验，建立会话密钥。
在步骤S609，第一设备与第二设备完成身份认证，设备间可以进行通信。
需要说明的是，本申请实施例中第一设备获取到第二设备代理申请的身份凭据后，也可以与其他任意具有信任基础例如登录同一账号的设备进行身份认证，其认证过程可以与现有流程相同，不再赘述。
本申请实施例借助第二设备代理申请第一设备的身份凭据，申请设备与代理设备建立 一对一信任关系，可以实现所属帐号的相互认证，同时消减认证密钥被导出、批量复制到恶意设备的风险。另外，第二设备进行身份认证时，区分对端是代理申请身份凭据的设备还是非代理申请身份凭据的设备，可以匹配不同的认证和更新策略。
进一步地，为更好地理解本申请实施例，以下列举一个更为具体的非限制性的例子，描述第一设备通过第二设备代理申请身份凭据以及进行身份认证的过程。本申请实施例仍以第一设备和第二设备的信任基础为云服务账号身份为例进行说明。为方便理解，以下将第一设备称为申请设备，将第二设备称为代理设备。整个过程主要分为三个阶段，说明如下。
一、预处理阶段
1)代理设备(例如上述第二设备)登录云服务账号后，获取账号标识(user ID)和账号登录凭据(Servicetoken)，其中账号标识记做UID，代理设备获得的账号登录凭据记做ST_A，代理设备的账号登录信息包括账号标识UID和账号登录凭据，因而可以记做(UID,ST_A)。
2)代理设备生成设备身份公私钥对，记做(pk_A,sk_A)。
3)代理设备获取本设备的设备标识，记做deviceID_A。
4)代理设备根据设备身份公私钥对中的公钥、设备标识、账号标识，生成身份凭据申请请求，记做
ApplyInfo＝(UID|deviceID_A|pk_A)。
5)代理设备使用产线预置的注册服务私钥(记做sk_register)对身份凭据申请请求ApplyInfo进行签名，获得签名后的身份凭据申请请求，记做
SignRegInfo＝Sign(sk_register,ApplyInfo)。
6)代理设备向签发设备上传4)中得到的身份凭据申请请求ApplyInfo、5)中得到的签名后的身份凭据申请请求SignRegInfo、账号登录信息(UID,ST_A)。
7)签发设备使用预置的设备注册全局公钥(即与注册服务私钥对应的公钥，记做pk_register)验证签名后的身份凭据申请请求SignRegInfo的有效性(即签名的合法性和完整性)；基于账号登录信息(UID,ST_A)验证账号登录信息的有效性。
8)验证成功后，签发设备下发身份凭据信息，代理设备的身份凭据信息由签发设备的私钥(记做sk_server)签名，记做
DeviceAuthToken_A＝Sign(sk_server,UID|deviceID_A|pk_A)
9)签发设备维护代理设备的身份凭据信息deviceID_A和对应的设备身份公钥pk_A的记录，用以标识该代理设备已注册凭据。
10)代理设备存储经签发设备私钥签名的身份凭据DeviceAuthToken_A和对应的设备身份私钥sk_A。
二、身份凭据代理申请阶段
1)申请设备(例如上述第一设备)登录云服务账号后，获取账号标识UID和账号登录凭据，其中申请设备获得的账号登录凭据记做ST_B。申请设备的账号登录信息包括账号标识UID和账号登录凭据，因而可以记做(UID,ST_B)。
2)申请设备生成设备身份公私钥对，记做(pk_B,sk_B)。
3)申请设备获取本设备的设备标识，记做deviceID_B。
4)申请设备根据设备身份公私钥对中的公钥、设备标识、账号标识，生成代理身份凭据申请请求，记做
RequestProxyInfo＝(UID|deviceID_B|pk_B)。
5)申请设备使用本设备的账号登录凭据ST_B对代理身份凭据申请请求RequestProxyInfo进行签名，得到申请设备签名后的代理身份凭据申请请求，记做
SignRequestProxyInfo＝Sign(ST_B,RequestProxyInfo)。
6)申请设备向代理设备发送4)中得到的申请设备签名前的代理身份凭据申请请求RequestProxyInfo和5)中得到的申请设备签名后的代理身份凭据申请请求SignRequestProxyInfo。
7)代理设备生成标识本次代理申请的标识(记做ProxyID)，用以标识本设备进行此次代理申请，代理设备签名前的代理身份凭据申请请求记做
ProxyInfo＝(RequestProxyInfo|SignRequestProxyInfo|deviceID_A|ProxyID)
代理设备使用本设备的设备身份私钥sk_A签发代理设备签名前的代理身份凭据申请请求，得到代理设备签名后的代理身份凭据申请请求，记做
SignProxyInfo＝Sign(sk_A,RequestProxyInfo|SignRequestProxyInfo|deviceID_A|ProxyID)
8)代理设备维护7)中生成的代理申请记录，即维护代理申请标识和申请设备的设备标识(ProxyID-deviceID_B)的信息。
9)代理设备根据安全性确定并存储申请设备的身份凭据的使用策略。
10)代理设备向申请设备返回代理设备签名前的代理身份凭据申请请求ProxyInfo、代理设备签名后的代理身份凭据申请请求SignProxyInfo、代理设备的设备标识deviceID_A。
11)申请设备向签发设备上传4)中得到的代理身份凭据申请请求RequestProxyInfo、10)中接收的代理设备签名后的代理身份凭据申请请求SignProxyInfo、10)中接收的代理设备的设备标识deviceID_A、账号登录信息(UID,ST_B)。
12)签发设备进行以下校验：
验证申请设备账号登录信息的有效性，即(UID,ST_B)是否有效；
验证代理设备签名后的代理身份凭据申请请求SignProxyInfo的有效性，根据代理设备的设备标识deviceID_A索引对应的设备身份公钥pk_A，验证申请设备上传申请信息的完整性；
使用账号登录凭据ST_B对代理身份凭据申请请求RequestProxyInfo计算，得到SignRequestProxyInfo’，进一步计算SignProxyInfo’，判断与判断与11)中上传的SignProxyInfo是否一致。
13)验证成功后，签发设备下发身份凭据信息，申请设备的身份凭据信息由签发设备的私钥(记做sk_server)签名，得到签发给申请设备的身份凭据，记做
DeviceAuthToken_B＝Sign(sk_server,UID|deviceID_B|pk_B|ProxyID)
14)申请设备存储经签发设备私钥签名的身份凭据DeviceAuthToken_B和对应的设备身份私钥sk_B。
三、身份认证阶段
1)申请设备向代理设备发送申请设备的设备标识deviceID_B、申请设备的设备身份公钥pk_B、申请设备的身份凭据DeviceAuthToken_B，用于请求认证身份。
2)代理申请根据申请设备的设备标识UDID_B为索引查询本地是否存在代理申请记录ProxyID，若存在则使用签发设备签名身份凭据用的私钥所对应的公钥(记做pk_server)验证申请设备的身份凭据DeviceAuthToken_B的完整性。
3)身份凭据验证通过后代理设备基于申请设备的设备身份公钥pk_B进行密钥协商并建立会话密钥。
4)代理设备认证后查询申请设备的身份凭据是否需要根据使用策略进行更新。
5)代理设备向申请设备发送代理设备的设备标识deviceID_A、代理设备的设备身份公钥pk_A、代理设备设备的身份凭据DeviceAuthToken_A。
6)申请设备使用签发设备签名身份凭据用的私钥所对应的公钥(记做pk_server)验证代理设备的身份凭据DeviceAuthToken_A的完整性。
7)身份凭据验证通过后申请设备基于代理设备的设备身份公钥pk_A进行密钥协商并建立会话密钥。
上文结合图1至图6详细的描述了本申请实施例的方法实施例，下面结合图7至图17，详细描述本申请实施例的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
图7是本申请实施例提供的第一设备的示意性结构图。图7中的第一设备700可以是图1中的设备122的一个具体的例子。在一个实施例中，图7所示的第一设备可以用于执行图2中的方法200，并且可以具体实现图4所示的实施例，为避免冗余，不再重复描述。
图7所示的第一设备700包括发送模块710和接收模块720。
发送模块710，用于向第二设备发送第一消息，所述第一消息包括所述第一设备的身份凭据申请信息。
接收模块720，用于接收所述第二设备发送的第二消息，所述第二消息包括处理后的身份凭据申请信息，其中所述处理后的身份凭据申请信息是所述第一设备的身份凭据申请信息经所述第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的。
所述发送模块710还用于，向第三方设备发送第三消息，所述第三消息包括所述处理后的身份凭据申请信息，所述处理后的身份凭据申请信息用于向所述第三方设备请求注册所述第一设备的身份凭据，其中所述第三方设备与所述第二设备相互信任。
可选地，所述第二消息还包括：所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
可选地，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备身份公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
可选地，所述第二设备的私钥为所述第二设备的注册服务私钥，或者为所述第二设备的设备身份私钥。
可选地，所述第三消息还包括所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
可选地，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有 安全环境或安全保护资源充分的设备。
在另一个实施例中，图7所示的第一设备可以用于执行图3中的方法300，为避免冗余，不再重复描述。
图7所示的第一设备700包括发送模块710和接收模块720。
发送模块710，用于向第二设备发送第一消息，所述第一消息包括所述第一设备的身份凭据申请信息，用于向第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任。
接收模块720，用于接收所述第二设备发送的第五消息，所述第五消息包括所述第一设备的身份凭据，其中所述第一设备的身份凭据是在所述第三方设备验证处理后的身份凭据申请信息后发送给所述第二设备的，所述处理后的身份凭据申请信息是所述第一设备的身份凭据申请信息经所述第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的。
可选地，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备认证公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
可选地，所述第二设备的私钥为所述第二设备的注册服务私钥，或者所述第二设备的设备认证私钥。
可选地，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
图8是本申请实施例提供的通信装置的示意性结构图。图8中的通信装置800可以是图1中的设备122一个具体的例子。图8所示的通信装置可以用于执行图2中的方法200或用于执行图3中的方法300，为避免冗余，不再重复描述。
该通信装置可以是上文中的第一设备，也可以是第一设备中的装置，或者是能够和第一设备匹配使用的装置。其中，该通信装置可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。通信装置800包括至少一个处理器820，用于实现本申请实施例提供的方法，具体参见方法示例中的详细描述，此处不做赘述。
通信装置800还可以包括至少一个存储器810，用于存储程序指令和/或数据。存储器810和处理器820耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器810可能和存储器820协同操作。处理器810可能执行存储器820中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
通信装置800还可以包括通信接口830，用于通过传输介质和其它设备进行通信，从而用于通信装置800中的装置可以和其它设备进行通信。示例性的，通信接口可以是收发器、电路、总线、模块、管脚或其它类型的通信接口。示例性地，通信装置800是第一设备，该其它设备是为第二设备或第三方设备。处理器820利用通信接口830收发数据，并用于实现图2或图3对应的实施例中所述第一设备所执行的方法。
本申请实施例中不限定上述通信接口830处理器820以及存储器810之间的具体连接介质。本申请实施例在图8中以存储器810、处理器820以及通信接口830之间通过总线 840连接。
图9是本申请实施例提供的第二设备的示意性结构图。图9中的第二设备900可以是图1中的设备121的一个具体的例子。在一个实施例中，图9所示的第二设备可以用于执行图2中的方法200，并且可以具体实现图4所示的实施例，为避免冗余，不再重复描述。
图9所示的第二设备900包括接收模块910、处理模块920和发送模块930。
接收模块910，用于接收第一设备发送的第一消息，所述第一消息包括所述第一设备的身份凭据申请信息。
处理模块920，用于使用所述第二设备的私钥对所述第一设备的身份凭据申请信息进行签名，或者使用对称密钥对所述第一设备的身份凭据申请信息进行加密，得到处理后的身份凭据申请信息。
发送模块930，用于向所述第一设备发送第二消息，所述第二消息包括所述处理后的身份凭据申请信息，所述处理后的身份凭据申请信息用于向第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任。
可选地，所述第二消息还包括：所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
可选地，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备认证公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
可选地，所述第二设备的私钥为所述第二设备的注册服务私钥，或者为所述第二设备的设备身份私钥。
可选地，所述处理模块920还用于，生成身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备的身份凭据申请信息进行了签名。
可选地，所述处理模块920还用于，确定所述第一设备的身份凭据的使用策略，所述使用策略用于指示所述第一身份凭据的有效信息。
可选地，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
在另一个实施例中，图9所示的第一设备可以用于执行图3中的方法300，为避免冗余，不再重复描述。
图9所示的第二设备900包括接收模块910、处理模块920和发送模块930。
接收模块910，用于接收第一设备发送的第一消息，所述第一消息包括所述第一设备的身份凭据申请信息。
处理模块920，用于使用所述第二设备的私钥对所述第一设备的身份凭据申请信息进行签名，或者使用对称密钥对所述第一设备的身份凭据申请信息进行加密，得到处理后的身份凭据申请信息。
发送模块930，用于向第三方设备发送第三消息，所述第三消息包括所述处理后的身份凭据申请信息，用于向所述第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任。
可选地，接收模块910还用于，接收所述第三方设备发送的第四消息，所述第四消息包括所述第一设备的身份凭据。
可选地，发送模块930还用于，向所述第一设备发送第五消息，所述第五消息包括所述第一设备的身份凭据。
可选地，所述第三消息还包括：所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
可选地，所述第一设备的身份凭据申请信息包括以下信息的至少一种：所述第一设备的设备标识；所述第一设备的设备认证公钥；所述第一设备所登录账号的账号标识；所述第一设备所登录账号的账号登录凭据。
可选地，所述第二设备的私钥为所述第二设备的注册服务私钥，或者所述第二设备的设备身份私钥。
可选地，处理模块920还用于，生成身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备代理申请身份凭据。
可选地，处理模块920还用于，确定所述第一设备的身份凭据的使用策略，所述使用策略用于指示所述第一身份凭据的有效信息。
可选地，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
图10是本申请实施例提供的通信装置的示意性结构图。图10中的通信装置1000可以是图1中的设备121一个具体的例子。图10所示的通信装置可以用于执行图2中的方法200或用于执行图3中的方法300，为避免冗余，不再重复描述。
该通信装置可以是上文中的第二设备，也可以是第二设备中的装置，或者是能够和第二设备匹配使用的装置。其中，该通信装置可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。通信装置1000包括至少一个处理器1020，用于实现本申请实施例提供的方法，具体参见方法示例中的详细描述，此处不做赘述。可选地，处理器1020的功能同处理模块920的功能。
通信装置1000还可以包括至少一个存储器1010，用于存储程序指令和/或数据。存储器1010和处理器1020耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1010可能和存储器1020协同操作。处理器1010可能执行存储器1020中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
通信装置1000还可以包括通信接口1030，用于通过传输介质和其它设备进行通信，从而用于通信装置1000中的装置可以和其它设备进行通信。示例性的，通信接口可以是收发器、电路、总线、模块、管脚或其它类型的通信接口。示例性地，通信装置1000是第二设备，该其它设备是为第一设备或第三方设备。处理器1020利用通信接口1030收发数据，并用于实现图2或图3对应的实施例中所述第二设备所执行的方法。
本申请实施例中不限定上述通信接口1030处理器1020以及存储器1010之间的具体连接介质。本申请实施例在图10中以存储器1010、处理器1020以及通信接口1030之间通过总线1040连接。
图11是本申请实施例提供的第三方设备的示意性结构图。图11中的第三方设备1100可以是图1中的第三方设备110的一个具体的例子。在一个实施例中，图11所示的第三方设备可以用于执行图2中的方法200或者图3中的方法300，并且可以具体实现图4所 示的实施例，为避免冗余，不再重复描述。
图11所示的第三方设备1100包括接收模块1110、处理模块1120和发送模块1130。
接收模块1110，用于接收第三消息，所述第三消息包括处理后的身份凭据申请信息，其中所述处理后的身份凭据申请信息是第一设备的身份凭据申请信息经第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的，所述第三方设备与所述第二设备相互信任。
处理模块1120，用于使用与所述第二设备的私钥对应的公钥或所述对称密钥对所述处理后的身份凭据申请信息进行验证。
处理模块1120，还用于验证通过后，为所述第一设备签发身份凭据。
发送模块1130，用于发送第一设备的身份凭据。
可选地，接收模块1110具体用于，从所述第一设备接收所述第三消息；或者，所述第三方设备从所述第二设备接收所述第三消息。
可选地，所述第三消息还包括所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
可选地，所述第一设备为无安全环境或安全保护资源有限的设备，所述第二设备为有安全环境或安全保护资源充分的设备。
图12是本申请实施例提供的通信装置的示意性结构图。图12中的通信装置1200可以是图1中的第三方设备110一个具体的例子。图12所示的通信装置可以用于执行图2中的方法200或用于执行图3中的方法300，为避免冗余，不再重复描述。
该通信装置可以是上文中的第三方设备，也可以是第三方设备中的装置，或者是能够和第三方设备匹配使用的装置。其中，该通信装置可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。通信装置1200包括至少一个处理器1220，用于实现本申请实施例提供的方法，具体参见方法示例中的详细描述，此处不做赘述。可选地，处理器1220的功能同处理模块1120的功能。
通信装置1200还可以包括至少一个存储器1220，用于存储程序指令和/或数据。存储器1220和处理器1220耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1220可能和存储器1220协同操作。处理器1220可能执行存储器1220中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
通信装置1200还可以包括通信接口1230，用于通过传输介质和其它设备进行通信，从而用于通信装置1200中的装置可以和其它设备进行通信。示例性的，通信接口可以是收发器、电路、总线、模块、管脚或其它类型的通信接口。示例性地，通信装置1200是第三方设备，该其它设备是为第一设备或第二设备。处理器1220利用通信接口1230收发数据，并用于实现图2或图3对应的实施例中所述第三方设备所执行的方法。
本申请实施例中不限定上述通信接口1230处理器1220以及存储器1220之间的具体连接介质。本申请实施例在图12中以存储器1220、处理器1220以及通信接口1230之间通过总线1240连接。
图13是本申请实施例提供的第二设备的示意性结构图。图13中的第二设备1300可以是图1中的设备121的一个具体的例子。在一个实施例中，图13所示的第二设备可以 用于执行图5中的方法500，并且可以具体实现图6所示的实施例，为避免冗余，不再重复描述。
图13所示的第二设备1300包括接收模块1310和处理模块1320。
接收模块1310，用于接收第一设备发送的身份认证请求，所述身份认证请求包括所述第一设备的身份凭据和所述第一设备的设备标识。
处理模块1320，用于根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请。
处理模块1320，还用于根据所述第一设备的身份凭据对应的使用策略确定所述第一设备的身份凭据是否符合所述使用策略。
处理模块1320，还用于在所述第一设备的身份凭据符合所述使用策略的情况下，所述第二设备对所述第一设备的身份凭据进行合法性和完整性校验。
可选地，处理模块1320，还用于根据所述使用策略确定是否需要更新所述第一设备的身份凭据。
可选地，处理模块1320具体用于，根据所述第一设备的设备标识查询到与所述第一设备对应的身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备的身份凭据申请信息进行了签名，或者指示所述第二设备为所述第一设备的身份凭据申请信息进行了加密；根据所述身份凭据代理申请记录确定所述第一设备的身份凭据为所述第二设备代理申请。
图14是本申请实施例提供的通信装置的示意性结构图。图14中的通信装置1400可以是图1中的第二设备121一个具体的例子。图14所示的通信装置可以用于执行图5中的方法500或用于执行图6中的方法600，为避免冗余，不再重复描述。
该通信装置可以是上文中的第二设备，也可以是第二设备中的装置，或者是能够和第二设备匹配使用的装置。其中，该通信装置可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。通信装置1400包括至少一个处理器1420，用于实现本申请实施例提供的方法，具体参见方法示例中的详细描述，此处不做赘述。可选地，处理器1420的功能同处理模块1320的功能。
通信装置1400还可以包括至少一个存储器1410，用于存储程序指令和/或数据。存储器1410和处理器1420耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1410可能和存储器1420协同操作。处理器1410可能执行存储器1420中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
通信装置1400还可以包括通信接口1430，用于通过传输介质和其它设备进行通信，从而用于通信装置1400中的装置可以和其它设备进行通信。示例性的，通信接口可以是收发器、电路、总线、模块、管脚或其它类型的通信接口。示例性地，通信装置1400是第二设备，该其它设备是为第一设备或第二设备。处理器1420利用通信接口1430收发数据，并用于实现图2或图3对应的实施例中所述第二设备所执行的方法。
本申请实施例中不限定上述通信接口1430处理器1420以及存储器1414之间的具体连接介质。本申请实施例在图14中以存储器1410、处理器1420以及通信接口1430之间通过总线1440连接。
为更好地理解本申请实施例，以下结合图15和图16列举一个更为具体的非限制性的例子。图15是本申请实施例提供的第一设备的示意性结构图，图16是本申请实施例提供的第二设备的示意性结构图。图15和图16所示的设备可以具体实现图4所示的实施例，或图6所示的实施例，为避免冗余，不再重复描述。
图15所示的第一设备1500包括第一申请模块1510、第一存储模块1520以及第一认证模块1530。
第一申请模块1510，用于执行申请第一设备的身份凭据的相关步骤和操作。
第一存储模块1520，用于存储第一设备的设备私钥和身份凭据。
第一认证模块1530，用于执行与其他设备进行身份认证的步骤和操作。
在申请身份凭据阶段，第一设备的各个模块所执行的操作如下。
可选地，第一申请模块1510具体用于，获取账号标识和账号登录凭据。例如执行方法400中的步骤S401。
可选地，第一申请模块1510具体用于，请求第一存储模块1520生成第一设备的设备身份公私钥对。
可选地，第一存储模块1520具体用于，生成第一设备的设备身份公私钥对，并返给第一申请模块1510设备身份公钥。例如执行方法400中的步骤S402。
可选地，第一申请模块1510具体用于，生成身份凭据申请请求，并发送给代理设备。例如执行方法400中的步骤S403。
可选地，第一申请模块1510具体用于，将第二设备签名后的身份凭据申请请求发送给第三方设备。例如执行方法400中的步骤S408。
可选地，第一申请模块1510具体用于，接收第三方设备签发的身份凭据，对身份凭据进行验签。例如执行方法400中的步骤S412。
可选地，第一存储模块1520具体用于，存储第三方设备颁发的身份凭据。
在身份认证阶段，第一设备的各个模块所执行的操作如下。
第一认证模块1530具体用于，向第一存储模块1520请求身份凭据，并发起设备认证请求，发送本设备的设备标识和身份凭据。例如执行方法600中的步骤S601。
第一认证模块1530具体用于，向第一存储模块1520请求验证第二设备的身份凭据。
第一存储模块1520具体用于，对第二设备的身份凭据进行合法性和完整性校验。例如执行方法600中的步骤S608。
图16所示的第二设备1600包括第二申请模块1610、第二存储模块1620以及第二认证模块1630。
第二申请模块1610，用于执行申请第二设备的身份凭据以及代理申请第一设备的身份凭据的相关步骤和操作。
第二申请模块1610包括本机凭据申请子模块1611和代理凭据申请子模块1622。其中本机凭据申请子模块1611可用于执行申请本机设备的身份凭据的步骤，例如执行方法实施例中预处理阶段第二设备所执行的操作。代理凭据申请子模块1622用于执行代理申请其他设备的身份凭据的步骤，例如执行方法实施例中代理申请身份凭据阶段时第二设备所执行的操作。
第二存储模块1620，用于存储第二设备的设备私钥和身份凭据，以及第一设备的身 份凭据。
第二存储模块1620包括代理申请签发子模块1621,和代理凭据存储子模块1622。其中代理申请签发子模块1621用于存储本机设备的设备身份私钥，用于为代理身份凭据申请信息进行签名。代理凭据存储子模块1622用于存储代理凭据。
第二认证模块1630，用于执行与其他设备进行身份认证的步骤和操作。
第二认证模块1630包括非本机代理凭据认证子模块1631、本机代理凭据更新策略子模块1632和本机代理凭据认证子模块1633。其中非本机代理凭据认证子模块1631用于执行与非本机代理凭据的设备之间身份认证的操作。本机代理凭据认证子模块1633用于执行与本机代理凭据的设备之间身份认证的操作。本机代理凭据更新策略子模块1632用于执行对本机代理凭据的更新和重新申请等操作。本申请实施例中，非本机代理凭据的设备指的是身份凭据不是本机代理申请的设备，本机代理凭据的设备指的是身份凭据由本机代理申请的设备。
在一些实施例中，第二认证模块1630包括密钥生成模块、密钥管理模块、加解密/验签模块及密钥校验模块。
在申请身份凭据阶段，第一设备的各个模块所执行的操作如下。
可选地，代理申请签发子模块1621具体用于，使用第二设备的私钥对第一设备的身份凭据申请信息(和第二设备的设备身份信息)进行签名。例如执行方法400中的步骤S405a或步骤S405b。
可选地，代理申请签发子模块1621具体用于，生成第一设备的身份凭据对应的使用策略。例如执行方法400中的步骤S413a。
可选地，代理凭据申请子模块1622具体用于，将签名后的身份凭据申请请求返回给第一设备。例如执行方法400中的步骤S407。
可选地，代理申请签发子模块1621具体用于，存储被代理的设备的身份凭据。
在身份认证阶段，第一设备的各个模块所执行的操作如下。
可选地，本机代理凭据认证子模块1633具体用于，向代理凭据存储子模块1622请求查询第一设备的身份凭据代理申请记录。例如执行方法600中的步骤S520。
可选地，本机代理凭据更新策略子模块1632具体用于，确定第一设备的身份凭据是否需要更新。
可选地，若第一设备1500在获得身份凭据后也能够为其他设备代理申请身份凭据，第一设备1500中的各个模块可以与第二设备1600的各个模块类似。
为更好地理解本申请实施例，以下结合图17列举一个更为具体的非限制性的例子。图17是本申请实施例提供的第四设备的示意性结构图，图17所示的设备可以具体实现图5所示的实施例，为避免冗余，不再重复描述。
图17所示的第四设备1700包括第四申请模块1710、第四存储模块1720以及第四认证模块1730。
第四申请模块1710，用于执行申请第四设备的身份凭据的相关步骤和操作。
第四存储模块1720，用于存储第四设备的设备私钥和身份凭据。
第四认证模块1730，用于执行与其他设备进行身份认证的步骤和操作。
第四认证模块1730包括非代理凭据认证子模块1731和代理凭据认证子模块1732。 其中非代理凭据认证子模块1731用于执行与非代理凭据的设备之间身份认证的操作。代理凭据认证子模块1732用于执行与代理凭据的设备之间身份认证的操作。本申请实施例中，非代理凭据的设备指的是身份凭据是自主申请的，代理凭据的设备指的是身份凭据由其他设备代理申请的。
在身份凭据申请阶段，第四设备的各个模块所执行的操作与第二设备申请自身身份凭据过程类似，可参考上文描述，不再赘述。
在身份认证阶段，第四设备的各个模块所执行的操作如下。
代理凭据认证子模块1732，具体用于确定第一设备的身份凭据为第二设备为第一设备代理申请，以及根据第一设备的身份凭据对应的使用策略确定是否与第一设备进行身份认证。例如执行方法500中的步骤S502a、S502b或步骤S503等。
可选地，若第四设备1700能够为其他设备代理申请身份凭据，则第四申请模块1710还可以包括本机凭据申请子模块和代理凭据申请子模块等。第四认证模块1730还可以包括本机代理凭据认证子模块、本机代理凭据更新策略子模块等。第四存储模块1720可以包括代理申请签发子模块、代理凭据存储子模块等。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (30)

  1. 一种身份凭据的申请方法，其特征在于，包括：
    第一设备向第二设备发送第一消息，所述第一消息包括所述第一设备的身份凭据申请信息；
    所述第一设备接收所述第二设备发送的第二消息，所述第二消息包括处理后的身份凭据申请信息，其中所述处理后的身份凭据申请信息是所述第一设备的身份凭据申请信息经所述第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的；
    所述第一设备向第三方设备发送第三消息，所述第三消息包括所述处理后的身份凭据申请信息，用于向所述第三方设备请求注册所述第一设备的身份凭据，其中所述第三方设备与所述第二设备相互信任。
  2. 根据权利要求1所述的申请方法，其特征在于，所述第二消息还包括所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
  3. 根据权利要求1或2所述的申请方法，其特征在于，所述第一设备的身份凭据申请信息包括以下信息的至少一种：
    所述第一设备的设备标识；
    所述第一设备的设备身份公钥；
    所述第一设备所登录账号的账号标识；
    所述第一设备所登录账号的账号登录凭据。
  4. 根据权利要求1至3中任一项所述的申请方法，其特征在于，所述第二设备的私钥为所述第二设备的注册服务私钥，或者为所述第二设备的设备身份私钥。
  5. 根据权利要求1至4中任一项所述的申请方法，其特征在于，所述第三消息还包括所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
  6. 一种身份凭据的申请方法，其特征在于，包括：
    第二设备接收第一设备发送的第一消息，所述第一消息包括所述第一设备的身份凭据申请信息；
    所述第二设备使用所述第二设备的私钥对所述第一设备的身份凭据申请信息进行签名，或者使用对称密钥对所述第一设备的身份凭据申请信息进行加密，得到处理后的身份凭据申请信息；
    所述第二设备向所述第一设备发送第二消息，所述第二消息包括所述处理后的身份凭据申请信息，所述处理后的身份凭据申请信息用于所述第一设备向第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任。
  7. 根据权利要求6所述的申请方法，其特征在于，所述第二消息还包括：
    所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
  8. 根据权利要求6或7所述的申请方法，其特征在于，所述第一设备的身份凭据申请信息包括以下信息的至少一种：
    所述第一设备的设备标识；
    所述第一设备的设备认证公钥；
    所述第一设备所登录账号的账号标识；
    所述第一设备所登录账号的账号登录凭据。
  9. 根据权利要求6至8中任一项所述的申请方法，其特征在于，所述第二设备的私钥为所述第二设备的注册服务私钥，或者为所述第二设备的设备身份私钥。
  10. 根据权利要求6至9中任一项所述的申请方法，其特征在于，还包括：
    所述第二设备生成身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备代理申请身份凭据。
  11. 根据权利要求6至10中任一项所述的申请方法，其特征在于，还包括：
    所述第二设备接收所述第一设备发送的身份认证请求，所述身份认证请求包括所述第一设备的身份凭据和所述第一设备的设备标识；
    所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请；
    所述第二设备根据所述第一设备的身份凭据对应的使用策略确定所述第一设备的身份凭据是否符合所述使用策略；
    在所述第一设备的身份凭据符合所述使用策略的情况下，所述第二设备对所述第一设备的身份凭据进行合法性和完整性校验。
  12. 根据权利要求11所述的申请方法，其特征在于，所述方法还包括：
    根据所述使用策略确定是否需要更新所述第一设备的身份凭据。
  13. 根据权利要求11或12所述的申请方法，其特征在于，所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请，包括：
    所述第二设备根据所述第一设备的设备标识查询到与所述第一设备对应的身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备的身份凭据申请信息进行了签名，或者指示所述第二设备为所述第一设备的身份凭据申请信息进行了加密；
    根据所述身份凭据代理申请记录确定所述第一设备的身份凭据为所述第二设备代理申请。
  14. 一种身份凭据的申请方法，其特征在于，包括：
    第二设备接收第一设备发送的第一消息，所述第一消息包括所述第一设备的身份凭据申请信息；
    所述第二设备使用所述第二设备的私钥对所述第一设备的身份凭据申请信息进行签名，或者使用对称密钥对所述第一设备的身份凭据申请信息进行加密，得到处理后的身份凭据申请信息；
    所述第二设备向第三方设备发送第三消息，所述第三消息包括所述处理后的身份凭据申请信息，用于向所述第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任。
  15. 根据权利要求14所述的申请方法，其特征在于，还包括：
    所述第二设备接收所述第三方设备发送的第四消息，所述第四消息包括所述第一设备的身份凭据；
    所述第二设备向所述第一设备发送第五消息，所述第五消息包括所述第一设备的身份凭据。
  16. 根据权利要求14或15所述的申请方法，其特征在于，所述第三消息还包括：
    所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
  17. 根据权利要求14至16中任一项所述的申请方法，其特征在于，所述第一设备的身份凭据申请信息包括以下信息的至少一种：
    所述第一设备的设备标识；
    所述第一设备的设备认证公钥；
    所述第一设备所登录账号的账号标识；
    所述第一设备所登录账号的账号登录凭据。
  18. 根据权利要求14至17中任一项所述的申请方法，其特征在于，所述第二设备的私钥为所述第二设备的注册服务私钥，或者所述第二设备的设备身份私钥。
  19. 根据权利要求14至18中任一项所述的申请方法，其特征在于，还包括：
    所述第二设备生成身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备代理申请身份凭据。
  20. 一种身份凭据的申请方法，其特征在于，包括：
    第一设备向第二设备发送第一消息，所述第一消息包括所述第一设备的身份凭据申请信息，用于向第三方设备请求注册所述第一设备的身份凭据，其中所述第二设备与所述第三方设备相互信任；
    所述第一设备接收所述第二设备发送的第五消息，所述第五消息包括所述第一设备的身份凭据，其中所述第一设备的身份凭据是在所述第三方设备验证处理后的身份凭据申请信息后发送给所述第二设备的，所述处理后的身份凭据申请信息是所述第一设备的身份凭据申请信息经所述第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的。
  21. 根据权利要求20所述的申请方法，其特征在于，所述第一设备的身份凭据申请信息包括以下信息的至少一种：
    所述第一设备的设备标识；
    所述第一设备的设备认证公钥；
    所述第一设备所登录账号的账号标识；
    所述第一设备所登录账号的账号登录凭据。
  22. 一种身份凭据的申请方法，其特征在于，包括：
    第三方设备接收第三消息，所述第三消息包括处理后的身份凭据申请信息，其中所述处理后的身份凭据申请信息是第一设备的身份凭据申请信息经第二设备的私钥签名之后得到的，或者经对称密钥加密之后得到的，所述第三方设备与所述第二设备相互信任；
    所述第三方设备使用与所述第二设备的私钥对应的公钥或所述对称密钥对所述处理后的身份凭据申请信息进行验证；
    验证通过后，所述第三方设备为所述第一设备签发身份凭据。
  23. 根据权利要求22所述的申请方法，其特征在于，所述第三方设备接收第三消息，包括：
    所述第三方设备从所述第一设备接收所述第三消息；或者，
    所述第三方设备从所述第二设备接收所述第三消息。
  24. 根据权利要求22或23所述的申请方法，其特征在于，所述第三消息还包括所述第二设备的设备身份信息，和/或，所述第一设备的身份凭据的使用策略。
  25. 根据权利要求22至24中任一项所述的申请方法，其特征在于，所述第一设备的身份凭据申请信息包括以下信息的至少一种：
    所述第一设备的设备标识；
    所述第一设备的设备认证公钥；
    所述第一设备所登录账号的账号标识；
    所述第一设备所登录账号的账号登录凭据。
  26. 一种身份认证的方法，其特征在于，包括：
    第二设备接收第一设备发送的身份认证请求，所述身份认证请求包括所述第一设备的身份凭据和所述第一设备的设备标识；
    所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请；
    所述第二设备根据所述第一设备的身份凭据对应的使用策略确定所述第一设备的身份凭据是否符合所述使用策略；
    在所述第一设备的身份凭据符合所述使用策略的情况下，所述第二设备对所述第一设备的身份凭据进行合法性和完整性校验。
  27. 根据权利要求26所述的方法，其特征在于，所述方法还包括：
    根据所述使用策略确定是否需要更新所述第一设备的身份凭据。
  28. 根据权利要求26或27所述的方法，其特征在于，所述第二设备根据所述第一设备的设备标识确定所述第一设备的身份凭据为所述第二设备为所述第一设备代理申请，包括：
    所述第二设备根据所述第一设备的设备标识查询到与所述第一设备对应的身份凭据代理申请记录，所述身份凭据代理申请记录用于指示所述第二设备为所述第一设备的身份凭据申请信息进行了签名，或者指示所述第二设备为所述第一设备的身份凭据申请信息进行了加密；
    根据所述身份凭据代理申请记录确定所述第一设备的身份凭据为所述第二设备代理申请。
  29. 一种设备，其特征在于，包括用于执行如权利要求1至5、20、21中任一项所述的申请方法的模块；或者用于执行如权利要求6至13、14至19中任一项所述的申请方法的模块；或者用于执行如权利要求22至25中任一项所述的申请方法的模块。
  30. 一种通信装置，其特征在于，所述通信装置包括：至少一个处理器和通信接口，所述通信接口用于所述通信装置与其他通信装置进行信息交互，当程序指令在所述至少一个处理器中执行时，使得所述通信装置实现如权利要求1至28中任一项所述的方法中在如下任一装置上的功能：所述第一设备、所述第二设备和所述第三方设备。
PCT/CN2021/082654 2020-06-30 2021-03-24 身份凭据的申请方法、身份认证的方法、设备及装置 WO2022001225A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010611975.3 2020-06-30
CN202010611975.3A CN113872765B (zh) 2020-06-30 2020-06-30 身份凭据的申请方法、身份认证的方法、设备及装置

Publications (1)

Publication Number Publication Date
WO2022001225A1 true WO2022001225A1 (zh) 2022-01-06

Family

ID=78981199

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/082654 WO2022001225A1 (zh) 2020-06-30 2021-03-24 身份凭据的申请方法、身份认证的方法、设备及装置

Country Status (2)

Country Link
CN (1) CN113872765B (zh)
WO (1) WO2022001225A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114189483A (zh) * 2022-02-14 2022-03-15 北京安盟信息技术股份有限公司 一种云环境下多用户密码服务流量按需控制方法及系统
US20230104103A1 (en) * 2021-10-01 2023-04-06 American Express Travel Related Services Company, Inc. Custodial systems for non-fungible tokens

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103905401A (zh) * 2012-12-27 2014-07-02 中国移动通信集团公司 一种身份认证方法和设备
CN107302544A (zh) * 2017-08-15 2017-10-27 迈普通信技术股份有限公司 证书申请方法、无线接入控制设备及无线接入点设备
CN109150507A (zh) * 2017-06-19 2019-01-04 上海中兴软件有限责任公司 一种设备凭证分发方法和系统、用户设备及管理实体
CN110351726A (zh) * 2018-04-03 2019-10-18 华为技术有限公司 终端认证的方法及装置
US20200021624A1 (en) * 2018-07-10 2020-01-16 AnKang HENTE Technology Co., Ltd Secure communication method of ims system based on key file

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030115154A1 (en) * 2001-12-18 2003-06-19 Anderson Anne H. System and method for facilitating operator authentication
US8732475B2 (en) * 2011-08-17 2014-05-20 Comcast Cable Communication, Llc Authentication and binding of multiple devices
JP6299047B2 (ja) * 2014-05-08 2018-03-28 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 証明取得方法及び装置
CN107360002B (zh) * 2017-08-15 2020-02-07 武汉信安珞珈科技有限公司 一种数字证书的申请方法
CN109429226B (zh) * 2017-09-05 2021-08-06 中国移动通信有限公司研究院 一种临时用户凭证的生成方法、用户卡、终端及网络设备
CN114039734B (zh) * 2018-03-16 2023-03-24 腾讯科技（深圳）有限公司 设备重置方法和装置
CN109981677B (zh) * 2019-04-08 2021-02-12 北京深思数盾科技股份有限公司 一种授信管理方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103905401A (zh) * 2012-12-27 2014-07-02 中国移动通信集团公司 一种身份认证方法和设备
CN109150507A (zh) * 2017-06-19 2019-01-04 上海中兴软件有限责任公司 一种设备凭证分发方法和系统、用户设备及管理实体
CN107302544A (zh) * 2017-08-15 2017-10-27 迈普通信技术股份有限公司 证书申请方法、无线接入控制设备及无线接入点设备
CN110351726A (zh) * 2018-04-03 2019-10-18 华为技术有限公司 终端认证的方法及装置
US20200021624A1 (en) * 2018-07-10 2020-01-16 AnKang HENTE Technology Co., Ltd Secure communication method of ims system based on key file

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230104103A1 (en) * 2021-10-01 2023-04-06 American Express Travel Related Services Company, Inc. Custodial systems for non-fungible tokens
CN114189483A (zh) * 2022-02-14 2022-03-15 北京安盟信息技术股份有限公司 一种云环境下多用户密码服务流量按需控制方法及系统
CN114189483B (zh) * 2022-02-14 2022-05-17 北京安盟信息技术股份有限公司 一种云环境下多用户密码服务流量按需控制方法及系统

Also Published As

Publication number Publication date
CN113872765B (zh) 2023-02-03
CN113872765A (zh) 2021-12-31

Similar Documents

Publication Publication Date Title
US11296877B2 (en) Discovery method and apparatus based on service-based architecture
US10638321B2 (en) Wireless network connection method and apparatus, and storage medium
CA2986223C (en) Method and apparatus for initial certificate enrollment in a wireless communication system
CN108650227B (zh) 基于数据报安全传输协议的握手方法及系统
US20200195445A1 (en) Registration method and apparatus based on service-based architecture
KR101009330B1 (ko) 모바일 네트워크를 기반으로 하는 엔드 투 엔드 통신에서의 인증을 위한 방법, 시스템 및 인증 센터
CN109302412B (zh) 基于CPK的VoIP通信处理方法、终端、服务器及存储介质
KR102469979B1 (ko) 제1 애플리케이션과 제2 애플리케이션 사이의 상호 대칭 인증을 위한 방법
JP2013017197A (ja) 相互認証のための方法および装置
CN107396350B (zh) 基于sdn-5g网络架构的sdn组件间安全保护方法
US11228450B2 (en) Method and apparatus for performing multi-party secure computing based-on issuing certificate
JP2020533853A (ja) デジタル証明書を管理するための方法および装置
WO2022001225A1 (zh) 身份凭据的申请方法、身份认证的方法、设备及装置
He et al. An accountable, privacy-preserving, and efficient authentication framework for wireless access networks
CN108259486B (zh) 基于证书的端到端密钥交换方法
CN114553426B (zh) 签名验证方法、密钥管理平台、安全终端及电子设备
CN110752934B (zh) 拓扑结构下网络身份交互认证的方法
WO2009129683A1 (zh) 微波接入全球互操作系统的接入鉴权方法、装置及系统
CN117729056B (zh) 一种设备身份认证方法和系统
Santos et al. A federated lightweight authentication protocol for the internet of things
WO2023221891A1 (zh) 安全通信的方法与装置
WO2022135386A1 (zh) 一种身份鉴别方法和装置
WO2022178890A1 (zh) 一种密钥的传输方法和装置
CN116848822A (zh) 用于提供针对通信的安全水平的方法和设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21831494

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21831494

Country of ref document: EP

Kind code of ref document: A1