CN115225259A

CN115225259A - ID-PKC information processing method, device, node and storage medium

Info

Publication number: CN115225259A
Application number: CN202111203497.3A
Authority: CN
Inventors: 刘福文; 阎军智; 杨波; 粟栗; 何申
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Priority date: 2021-04-19
Filing date: 2021-10-15
Publication date: 2022-10-21
Also published as: WO2022222722A1

Abstract

The application discloses a public key signature (ID-PKC) information processing method, device, node and storage medium based on identification. The method comprises the following steps: the method comprises the steps that a first node acquires a first ID-PKC system public parameter and/or an Identification Revoke List (IRL); the status of the first ID-PKC system public parameter is valid; the first node is a billing node; writing the acquired first ID-PKC system common parameters and/or IRL into a federation chain based on a consensus mechanism.

Description

ID-PKC information processing method, device, node and storage medium

The present application is filed and claimed as priority based on the chinese patent application having an application number of 202110419392.5, application date of 2021, 19/04, which is hereby incorporated by reference in its entirety.

Technical Field

The present application relates to the field of network security technologies, and in particular, to an identifier-based Public Key cryptography (ID-PKC) information processing method, apparatus, node, and storage medium.

Background

In the ID-PKC system, a public key does not need to be transmitted by using a certificate, so that the dependence on the certificate and a certificate management system is avoided. In the ID-PKC system, the common parameters and/or the Identification Revocation List (IRL) of the ID-PKC system do not need to encrypt the transmission, but there is no change in the delivery, and therefore, in the related art, the security of the delivery of the common parameters and the IRL of the ID-PKC system is implemented by using a Transport Layer Security (TLS) protocol.

However, the establishment of the TLS security channel when using the TLS protocol requires the use of certificates, that is, the boot process of the ID-PKC system actually relies on a Public Key Infrastructure (PKI) -based Public Key Cryptography (PKI-PKC) system, which may introduce the drawbacks of the PKI-PKC system into the ID-PKC system.

Disclosure of Invention

In order to solve the related art problems, embodiments of the present application provide an ID-PKC information processing method, apparatus, node, and storage medium.

The technical scheme of the embodiment of the application is realized as follows:

an embodiment of the present application provides an ID-PKC information processing method, which is applied to a first node, and includes:

acquiring a first ID-PKC system public parameter and/or IRL; the status of the first ID-PKC system public parameter is valid; the first node is a billing node;

writing the acquired first ID-PKC system public parameters and/or IRL into a alliance chain based on a consensus mechanism.

In the above solution, the first ID-PKC system Public parameter is generated by a Public Parameter Server (PPS) of a Key Generation Center (KGC);

the first ID-PKC system common parameters comprise at least one of:

a domain name;

a blockchain name;

a system common parameter status;

a hashing algorithm for hiding the user identification.

In the above scheme, the domain name is a name defined by a Uniform Resource Identifier (URI) or a Uniform Resource Locator (URL), or is a self-defined name.

In the foregoing embodiment, the first ID-PKC system common parameters further include:

PPS name;

an Identity Management Server (IMS) name.

In the above scheme, the PPS name is a name defined according to a URI or URL, or a custom name.

In the above scheme, the name is defined according to a URI or URL, or is a self-defined name.

In the above solution, the IRL is generated by an Identity Management Server (IMS) of the KGC;

the IRL includes at least one of:

a domain name;

a blockchain name;

a set of lift pin identifications.

In the above scheme, the domain name is a name defined by a URI or URL, or a custom name.

In the foregoing solution, the IRL further includes:

IMS name.

In the above solution, the IMS name is a name defined according to a URI or URL, or a custom name.

In the above solution, the suspension pin identifier set includes at least one of:

whether the suspension pin identification is anonymous;

a lifting pin identification;

the reason for lifting the pin.

In the above scheme, the method further comprises:

acquiring a second ID-PKC system public parameter; the status of the second ID-PKC system public parameter is invalid; the second ID-PKC system common parameter is the same as the first ID-PKC system common parameter except the production time and the state;

writing the acquired public parameters of the second ID-PKC system into the alliance chain based on a consensus mechanism;

acquiring newly generated third ID-PKC system public parameters; the third ID-PKC system common parameter is updated by the first ID-PKC system common parameter; the status of the third ID-PKC system common parameter is valid;

and writing the acquired public parameters of the third ID-PKC system into the alliance chain based on a consensus mechanism.

The embodiment of the present application further provides an ID-PKC information processing method, which is applied to a second node, and includes:

acquiring a first request; the first request is used for requesting to acquire ID-PKC system public parameters;

inquiring corresponding ID-PKC system public parameters from the alliance chain;

and returning a response according to the query result.

In the above solution, when querying the corresponding public parameters of the ID-PKC system from the federation chain, the method includes:

starting the query from the newest block of the federation chain.

In the above scheme, the first request carries a domain name and a block chain name;

and querying corresponding ID-PKC system public parameters from a alliance chain corresponding to the block chain name by using the domain name carried by the first request.

In the above solution, the first request further carries a PPS name;

and inquiring corresponding ID-PKC system public parameters from a union chain corresponding to the block chain name by using the domain name and/or the PPS name carried by the first request.

In the above scheme, the returning a response according to the query result includes:

when the corresponding public parameters of the ID-PKC system are not inquired, returning error information;

alternatively, the first and second electrodes may be,

when the corresponding public parameter of the ID-PKC system is inquired and the state of the inquired public parameter of the ID-PKC system is invalid, returning error information;

alternatively, the first and second electrodes may be,

and when the corresponding ID-PKC system public parameter is inquired and the state of the inquired ID-PKC system public parameter is valid, returning the inquired ID-PKC system public parameter.

The embodiment of the present application further provides an ID-PKC information processing method, which is applied to a third node, and includes:

acquiring a second request; the second request is used for requesting to inquire whether the first identifier is already hoisted or not;

querying from the federation chain whether the first identity has been revoked; the alliance chain records IRL;

and returning a response according to the query result.

In the above scheme, the second request carries the first identifier and the name of the block chain; and querying a alliance chain corresponding to the block chain name by using the first identifier.

In the above scheme, the second request carries an operation result and a block chain name obtained after the operation is performed on the first identifier by using a hash function indicated by a public parameter of an ID-PKC system;

and querying the alliance chain corresponding to the block chain name by using the operation result.

when the first identification is inquired to be hoisted and pinned, returning first information; the first information indicates that the first identifier has been pinned;

alternatively, the first and second electrodes may be,

when the first identifier is not found, returning second information; the second information indicates that the first identity is valid.

An embodiment of the present application further provides an ID-PKC information processing apparatus, which is disposed on a first node, and includes:

a first obtaining unit, configured to obtain a first ID-PKC system common parameter and/or an IRL; the status of the first ID-PKC system public parameter is valid; the first node is a billing node;

a first processing unit, configured to write the obtained first ID-PKC system common parameters and/or IRL into a federation chain based on a consensus mechanism.

An embodiment of the present application further provides an ID-PKC information processing apparatus, including:

a second obtaining unit configured to obtain the first request; the first request is used for requesting to acquire ID-PKC system public parameters;

the second processing unit is used for inquiring corresponding ID-PKC system public parameters from the alliance chain; and returning a response according to the query result.

a third obtaining unit, configured to obtain the second request; the second request is used for requesting to inquire whether the first identifier is already hoisted or not;

a third processing unit, configured to query from the federation chain whether the first identity has been revoked; the federation chain records an IRL; and returning a response according to the query result.

An embodiment of the present application further provides a first node, including: a first communication interface and a first processor; wherein the content of the first and second substances,

the first communication interface is used for acquiring first ID-PKC system public parameters and/or IRL; the status of the first ID-PKC system public parameter is valid; the first node is a billing node;

a first processor, configured to write the obtained first ID-PKC system public parameters and/or IRL into the federation chain based on a consensus mechanism.

An embodiment of the present application further provides a second node, including: a second communication interface and a second processor; wherein the content of the first and second substances,

the second communication interface is used for acquiring a first request; the first request is used for requesting to acquire ID-PKC system public parameters;

the second processor is used for inquiring corresponding ID-PKC system public parameters from a alliance chain; and returning a response through the second communication interface according to the query result.

An embodiment of the present application further provides a third node, including: a third communication interface and a third processor; wherein the content of the first and second substances,

the third communication interface is used for acquiring a second request; the second request is used for requesting to inquire whether the first identifier is already hoisted or not;

the third processor, configured to query from a federation chain whether the first identity has been revoked; the alliance chain records IRL; and returning a response through the third communication interface according to the query result.

An embodiment of the present application further provides a first node, including: a first processor and a first memory for storing a computer program capable of running on the processor,

wherein the first processor is configured to execute the steps of any one of the methods at the first node side when running the computer program.

An embodiment of the present application further provides a second node, including: a second processor and a second memory for storing a computer program capable of running on the processor,

wherein the second processor is configured to execute the steps of any of the above-mentioned methods at the second node side when running the computer program.

An embodiment of the present application further provides a third node, including: a third processor and a third memory for storing a computer program capable of running on the processor,

wherein the third processor is configured to execute the steps of any one of the methods of the third node side when running the computer program.

An embodiment of the present application further provides a storage medium, where a computer program is stored, and when executed by a processor, the computer program implements the steps of any method on the first node side, or implements the steps of any method on the second node side, or implements the steps of any method on the third node side.

According to the ID-PKC information processing method, the device, the node and the storage medium provided by the embodiment of the application, the first node acquires public parameters and/or IRL of a first ID-PKC system; the status of the first ID-PKC system public parameter is valid; the first node is a billing node; writing the acquired first ID-PKC system public parameters and/or IRL into a alliance chain based on a consensus mechanism; the second node acquires the first request; the first request is used for requesting to acquire ID-PKC system public parameters; inquiring corresponding ID-PKC system public parameters from the alliance chain; and returning a response according to the query result; the third node acquires a second request; the second request is used for requesting to inquire whether the first identifier is already hoisted or not; querying from the federation chain whether the first identity has been revoked; the alliance chain records IRL; and returns a response according to the query result. According to the scheme provided by the embodiment of the application, the issuing of the public parameters of the ID-PKC system and the management of the identifier revocation are carried out based on the alliance chain, the parameters of the ID-PKC system and the IRL can be transmitted in a cross-domain mode by using the alliance chain, and the identifier revocation can be inquired in the cross-domain mode, so that the cross-domain safety communication can be realized by using the ID-PKC system without depending on the PKI-PKC system.

Drawings

FIG. 1 is a flowchart illustrating a method for processing ID-PKC information according to an embodiment of the present disclosure;

FIG. 2 is a flowchart illustrating a second method for processing ID-PKC information according to an embodiment of the present invention;

FIG. 3 is a flowchart illustrating a second method for processing ID-PKC information according to an embodiment of the present application;

FIG. 4 is a schematic structural diagram of a first ID-PKC information processing apparatus according to an embodiment of the present application;

FIG. 5 is a diagram illustrating a second ID-PKC information processing apparatus according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a third ID-PKC information processing apparatus according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a first node according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a second node according to the embodiment of the present application;

fig. 9 is a schematic structural diagram of a third node according to the embodiment of the present application.

Detailed Description

The present application is described in further detail below with reference to examples.

Prior to describing embodiments of the present application, a related art will be understood.

In a conventional certificate-based key system, verifiable propagation of a user identifier and a public key is realized through binding of the public key and the identifier in a certificate and signing by a trusted third party Certification Authority (CA). Although certificate-based key systems have been widely used, there are some drawbacks:

(1) The need to exchange certificates in secure applications;

(2) The validity of the certificate needs to be verified when the certificate is used;

(3) The issuance and management of certificates is very complex.

To address these aforementioned problems with certificate-Based key systems that rely on certificates and certificate management systems, such as the PKI-PKC system, israeli cryptologist Shamir proposed the ID-PKC system, also known as the Identity-Based cryptogram (ID-PKC) system, in 1984. In the ID-PKC system, the most important point is that a certificate is not used to transmit a public Key, but user identification information representing a user, such as a name, an Internet Protocol (IP) address, an email address, or a mobile phone number, is used as a public Key, and a private Key is calculated by a Key Generation Center (KGC) according to a system master Key and a user identification, so that the system does not rely on a certificate and a certificate management system (such as a PKI-PKC system), thereby greatly simplifying the complexity of managing the cryptosystem. While proposing the ID-PKC concept, shamir proposes an identity-based signature Algorithm (IBS) that employs the RSA algorithm. However, identity Based Encryption algorithms (IBE) have failed to find an effective solution for a long period of time. Until 2001, pairs on elliptic curves (pairing) proposed by d.boneh and m.franklin did not enable secure IBE systems. The current relatively efficient signature algorithm based on identification is The Elliptic Curve Certificateless signature based on Elliptic Curve used for The Encryption (ECCSI) scheme based on identification.

The ID-PKC system common parameters do not require encrypted transmissions, but no changes in delivery are required (i.e. integrity needs to be guaranteed), since the integrity of the common parameters is crucial for correct use of the ID-PKC system. It is relatively easier to initialize an ID-PKC system within a domain than across domains, and a user within a domain can securely (e.g., by an offline method) obtain the user's private key and the public parameters of the ID-PKC system. The security of the delivery of the private key and the public parameters of the user of the ID-PKC system may be achieved by using a Transport Layer Security (TLS) protocol, i.e. a TLS secure channel is established between the user and the KGC, and the public parameters of the ID-PKC system are delivered through the TLS secure channel.

On the other hand, there is a need for identity revocation in ID-PKC systems to prevent continued use of identities or credentials that are no longer valid or that have a security breach, such as service termination or private key disclosure. For revocation of an identity, the identity should be set to the revoked state. The identification of the lift pin constitutes the IRL and a reliable channel is also required for delivery of the IRL to the user. The IRL may be delivered over a TLS secure channel established between the user and the KGC.

However, the establishment of the TLS secure channel requires the use of certificates, which means that the boot process of the ID-PKC system is actually dependent on the PKI, contrary to the original design intent of the ID-PKC system. Furthermore, the multi-CA trust problem in certificate-based key systems is conducted to the ID-PKC system.

Based on this, in various embodiments of the present application, the issuing of ID-PKC system common parameters and the management of identity revocation are conducted based on a federation chain.

In the embodiment of the application, public parameters and/or IRL of the ID-PKC system are written into a alliance chain through an consensus mechanism of the alliance chain, the parameters and the IRL of the ID-PKC system can be transmitted across domains by using the alliance chain, and identification revoking can be inquired across domains, so that cross-domain secure communication can be realized by using the ID-PKC system without depending on a PKI system.

An embodiment of the present application provides an ID-PKC information processing method, which is applied to a first node, and as shown in fig. 1, the method includes:

step 101: acquiring a first ID-PKC system public parameter and/or IRL; the status of the first ID-PKC system public parameter is valid; the first node is a billing node;

step 102: writing the acquired first ID-PKC system common parameters and/or IRL into a federation chain based on a consensus mechanism.

Here, in practical application, the ID-PKC system common parameter may also be referred to as an ID-PKC system parameter or an ID-PKC parameter, and it should be noted that the ID-PKC system common parameter may also be named by other names as long as it has the same function or function as the ID-PKC system common parameter, and the embodiment of the present application is not limited thereto. Accordingly, the IRL may also use other names as long as it has a function or an action with the IRL, and this is not limited in the embodiments of the present application.

The federation chain is a block chain, which refers to a block chain that is managed by several mechanisms together. A plurality of preselected nodes are designated as accounting nodes in the alliance chain, generation of each block is jointly determined by all the preselected nodes through a consensus mechanism, and other access nodes can read information on the chain without inquiring about an accounting process. Federation chains use distributed ledgers and distributed consensus techniques to form data-based unions

An improved distributed database. As long as the information published on the chain is authentic.

In an embodiment of the present application, the mechanism may include a KGC of one domain. The KGC of a domain may correspond to one or more accounting nodes.

In practice, the first ID-PKC system common parameter may be generated by the KGC. Here, it should be noted that: the names of the agencies generating parameters common to the ID-PKC system are not limited in the embodiments of the present application.

Among these, KGC generally comprises the following three parts:

and a Private Key Generator (PKG) for generating a user Private Key according to the main password and the user identity which are stored in the ID-PKC system in a secure way. The private key is distributed to the user through a secure channel, providing confidentiality and integrity protection. Thus, only the user with the associated identity knows the private key.

The PPS is used for providing the user with the public parameters of the ID-PKC system and the strategy information describing the PKG operation. Since the integrity of the common parameters and policy information is critical to the proper operation of the ID-PKC system, the communication channel between the user and the PPS should be trusted. Here, in actual use, the communication channel between the user and the PPS is not necessarily confidential, because the common parameter and policy information are common information that anyone can acquire. Thus, the first ID-PKC system common parameters may be generated by the PPS of the KGC.

And the IMS is used for managing the identification of the user, including ensuring the uniqueness of the user identification in the management domain, maintaining the status (including validity and suspension) of the identification and issuing IRL. The communication channel between the user and the IMS should be trusted. Here, in actual use, the communication channel between the user and the IMS is not necessarily secret, because the identification revocation list is public information that anyone can obtain.

The ID-PKC system common parameters may contain many parameters, and in the embodiment of the present application, since the ID-PKC system common parameters are stored in the federation chain, the ID-PKC system common parameters need to contain parameters associated with the federation chain in addition to general parameters.

Based on this, in an embodiment, the first ID-PKC system common parameters comprise at least one of:

domain name (i.e., the name of the domain where KGC is located);

a blockchain name;

system common parameter status;

a hashing algorithm for hiding the user identification.

The domain name indicates a domain name of a KGC (global system for mobile communication) domain where a first ID-PKC system public parameter is generated; the block chain name can also be called a union chain name, and indicates the name of a union chain corresponding to the public parameter of the first ID-PKC system; the system public parameter status indicates a status of a first ID-PKC system public parameter, and is specifically valid; the hash algorithm for hiding the user identifier is used for anonymizing the identifier in the IRL.

Here, the ID-PKC system common parameter the first ID-PKC system common parameter may further include at least one of:

PPS name;

IMS name.

Wherein the PPS name indicates a name of the PPS. The IMS name indicates the name of the IMS.

In practical applications, according to an encoding method, such as the asn.1 method, the common parameters of the ID-PKC system can be described as follows:

wherein, the meanings of each field are as follows:

version is the version number of the public parameters of the ID-PKC system;

the domainName is the name of the domain where KGC is located, is used for KGC addressing, can be the name defined according to URI or URL, and can also be the name defined by the user in a self-defined way, namely a self-defined name;

ppsName: is the name of the PPS, which is used for PPS addressing, and it can be a name defined by URI or URL, or a name defined by the user in his own way, i.e. a custom name.

imsName is the name of IMS, used for IMS addressing, and can be a name defined by URI or URL, or a name defined by the user in a self-defined way, namely a self-defined name.

domainSerial: the field is an integer and represents a unique set of ID-PKC system common parameters that can be used on the domainName, that is, represents a set of ID-PKC system common parameters that can be used on the domain where the KGC indicated by the domainName is located;

validity field, which defines the lifetime of the ID-PKC system common parameters and is defined as follows:

id-pkcPublicParameters: is a structure containing common parameters corresponding to the ID-PKC algorithm supported by the ID-PKC system. The structure is defined as follows:

here, id-pkcAlgorithm: at least one ID-PKC algorithm supported by an ID-PKC system;

public parameter data: is a structure of Distinguishable Encoding Rule (DER) codes, containing the actual cryptographic parameters. The specific structure of this field depends on the algorithm.

ID-PKCIdentitType: an identity for defining the type of identity used within a domain, the manner in which this field is used being application dependent;

blockchainName: the ID-PKC system common parameters are published on the blockchain (i.e., federation chain), and this field is used to indicate the name of the blockchain;

hashAlgorithm: this field indicates a hashing algorithm for hiding the user identity for anonymization of the user identity in the IRL, which is defined as follows:

id-pkcParamStatus: the status for indicating the common parameters of the ID-PKC system may specifically have two statuses, which are: valid and invalid (also referred to as overhead), defined as follows:

id-pkcParamExtensions: it is a set of extensions that can be used to define other parameters that may be needed for a particular implementation. The structure of this field is defined as follows:

it should be noted that: the names of the above fields are not limited in the embodiments of the present application.

In practice, in step 102, the first node may form a block from the acquired first ID-PKC system common parameters based on the consensus mechanism, and then release the formed block to the federation chain. In a federation chain, blocks are linked into a federation chain in chronological order (e.g., the chronological order in which the ID-PKC system common parameters are generated).

Illustratively, the specific steps of writing the public parameters of the ID-PKC system into the alliance chain comprise:

step 1: the PPS of KGC of a domain generates ID-PKC system public parameters and marks their status as valid, i.e., the ID-PKCParamStatus field is set to valid.

And 2, step: one or more accounting nodes of the PPS of the KGC on the federation chain are together with accounting nodes of the PPS of the KGC of other domains, namely all accounting nodes on the federation chain, and the ID-PKC system public parameters generated by the PPS of the KGC are written into the federation chain by using a consensus mechanism.

Wherein, during practical application, KGC and the bill node probably meet together and establish, KGC and bill node also probably separately set up, under the condition of separately setting up, carry out the interaction through the escape way between KGC and the bill node.

Here, the uplink of the common parameters of the ID-PKC system is completed through steps 1 and 2.

In practical application, the information of the public parameters of the ID-PKC system may need to be updated, such as the change of the cryptographic algorithm. Because the message on the alliance chain can not be deleted, an ID-PKC system public parameter which is the same as the original ID-PKC system public parameter needs to be generated, the state of the ID-PKC system public parameter is marked as invalid, and the generated ID-PKC system public parameter is written into the alliance chain; then, a content updated ID-PKC system public parameter is generated, the state of the ID-PKC system public parameter is marked as valid, and the status is written into a alliance chain, so that the updating of the ID-PKC system public parameter is completed.

Based on this, in an embodiment, the method may further include:

acquiring newly generated third ID-PKC system public parameters; the third ID-PKC system common parameter is updated by the first ID-PKC system common parameter;

the status of the third ID-PKC system public parameter is valid;

and writing the acquired third ID-PKC system public parameters into the alliance chain based on a consensus mechanism.

Illustratively, the specific steps of the ID-PKC system public parameter update comprise:

step 1: the PPS generates an ID-PKC system public parameter (the other items except the state item and the generation time are different) which has the same content with the public parameter of the uplink ID-PKC system, namely generates a second ID-PKC system public parameter and marks the state as invalid;

step 2: the PPS uses a consensus mechanism at one or more accounting nodes on the alliance chain together with accounting nodes of other domains to write the ID-PKC system public parameters generated in the step 1 into the alliance chain;

and step 3: the PPS generates an ID-PKC system public parameter with updated information content, namely a third ID-PKC system public parameter, and marks the state of the third ID-PKC system public parameter as valid;

and 4, step 4: the PPS uses a consensus mechanism at one or several accounting nodes in the federation chain, together with accounting nodes in other domains, to write ID-PKC system parameters with updated information content into the federation chain.

In practical applications, the IRL may be generated by KGC. In particular, the IRL may be generated by the IMS of the KGC.

The IRL may contain many parameters, and in this embodiment, since the IRL is stored in the federation chain, the IRL needs to contain parameters associated with the federation chain in addition to general parameters.

Based on this, in one embodiment, the IRL includes at least one of:

a domain name;

a blockchain name;

a set of lift pin identifications.

The domain name indicates the name of the domain where KGC generating the IRL is located; the blockchain name may also be referred to as a federation chain name, indicating the name of the federation chain to which the IRL corresponds.

In an embodiment, the IRL may further include:

IMS name.

Wherein the IMS name indicates the name of the MIS.

In one embodiment, the set of lift pin identifiers comprises at least one of:

whether the suspension pin identification is anonymous;

a lifting pin identification;

and (4) hoisting the pin.

In practical applications, according to an encoding method, such as the asn.1 method, the IRL can be described as follows:

wherein the meaning of each field is as follows:

version: is the version number of the IRL;

issuer: to distinguish the issuer of the IRL;

irlNumbe: is the issuer number of the current IRL; it starts from 0, and for each complete IRL release (i.e. the IRL released by KGC at a certain point in time contains all the suspension pin identifiers), the number is increased by 1, which is optional;

deltaList, whether the present IRL is increment IRL (i.e. revoke identification increased from a certain time point to the previous time point), the list only contains identity information revoked since the complete IRL release of irlNumber index;

domainName: the name of the domain where KGC of the generated IRL is located is used for KGC addressing, and can be a name defined according to URI or URL, or a name defined by a user in a self-defined way, namely a self-defined name;

domainSerial: this field is an integer representing the unique set of IRLs that can be used on the domainName, i.e. representing the set of IRLs that can be used on the domain where the KGC indicated by the domainName is located;

thissupdate: indicating this IRL table generation time;

nextUpdate: indicating the next IRL generation time, optional;

blockchainName: IRL is published on blockchains (i.e., federation chains), this field being used to indicate the name of the blockchain;

revakedIenties: for indicating a set of lift pin identifications, comprising the following fields: anonymity, identity, revokeReason, revocationDate, irlEntryExtensions. These fields are illustrated below:

(1) andanonymity for explaining whether the revoke identifier needs to be anonymous, that is, whether the revoke identifier is anonymous, the field is described in detail as follows:

(2) The identity is used for explaining the revoking identification, and the field is specifically described as follows:

identity::＝ID-PKCIdentityInfo

ID-PKCIdentityInfo::＝CHOICE{

Hash(RovokedIdendity),

RovokedIdentity,

}

wherein, if the anonymity is YES, the ID-PKCIdenityInfo field corresponds to the hash value of the revoke identifier, otherwise, the ID-PKCIdenityInfo field corresponds to the revoke identifier;

(3) revakereason: for the reason of identifying the lift pin, this field is described as follows:

irlEntryExtensions: this field defines the possible revoke identification extensions.

In practical applications, in step 102, the first node may form the obtained IRL into a block based on a consensus mechanism, and then release the formed block into a federation chain. In a federation chain, blocks are linked into a federation chain in a temporal order (e.g., the temporal order in which IRLs are generated).

Illustratively, the specific step of writing the IRL number into the federation chain (i.e., publishing (also understood as issuing) the IRL on the federation) includes:

step 1: the IMS of KGC of a domain generates IRL;

step 2: one or several accounting nodes of the IMS in the federation chain together with the accounting nodes of the IMS in the federation chain of KGC of other domains, i.e. all accounting nodes in the federation chain, use a consensus mechanism to write the IRL into the federation chain.

After the ID-PKC system public parameters and IRL are written into the federation chain, the user may query the ID-PKC system public parameters and IRL.

Based on this, an embodiment of the present application further provides an ID-PKC information processing method, which is applied to a second node, as shown in fig. 2, and the method includes:

step 201: acquiring a first request; the first request is used for requesting to acquire public parameters of an ID-PKC system;

step 202: inquiring corresponding ID-PKC system public parameters from the alliance chain;

step 203: and returning a response according to the query result.

When the second node is actually applied, the second node may be an accounting node or an ordinary access node.

In practical application, when the public parameters of the ID-PKC system are written into a alliance chain, the public parameters can be called keywords (keys) by domain names; in addition, a plurality of alliance chains exist in the network, and during query, the alliance chain where the public parameters of the ID-PKC system to be queried are located needs to be found.

Based on this, in one embodiment, the first request carries a domain name and a blockchain name; correspondingly, the second node queries corresponding ID-PKC system public parameters from the alliance chain corresponding to the block chain name by using the domain name carried by the first request.

In practical application, when the ID-PKC system common parameter includes the PPS name, and the ID-PKC system common parameter is written in the federation chain, the domain name and/or the PPS name may be used as a key.

Based on this, in an embodiment, the first request further carries a PPS name;

On the federation chain, the blocks are linked in chronological order, so that the query can be started from the newest block on the federation chain.

When the domain name carried by the first request is not retrieved in the corresponding alliance chain, and it is indicated that the corresponding ID-PKC system public parameter is not queried, the second node returns error information, and at this time, the error information may indicate that the ID-PKC system public parameter to be queried does not exist.

When the corresponding public parameter of the ID-PKC system is inquired and the state of the inquired public parameter of the ID-PKC system is invalid, an error message is returned, and at the moment, the error message can indicate that the state of the public parameter of the ID-PKC system to be inquired is invalid.

Illustratively, the querying step of the ID-PKC system public parameters may include:

step 1: a user needs to obtain public parameters of an ID-PKC system, and firstly, a domainName field and/or a ppsName field are/is used for initiating query to a block chain of a alliance, namely, a first request is initiated; here, a user initiates a first request through an Application Programming Interface (API);

step 2: searching the latest block on a block chain (namely, searching from back to front at the end of the whole link), if the domain name field and/or the ppsName field to be searched is not searched on the block chain, terminating the search and returning called error information (namely, the ID-PKC system parameter does not exist) to the user, if the searched field chain is searched on the block chain, checking the obtained latest (namely, the corresponding domain Serial is the largest) ID-PKC system common parameter, and if the state is an invalid state, returning the called error information (namely, the ID-PKC system parameter exists but the state is invalid); and if the state of the latest ID-PKC system public parameter is a valid state, returning to the ID-PKC system public parameter which the user wants to acquire.

An embodiment of the present application further provides an ID-PKC information processing method, which is applied to a third node, and as shown in fig. 3, the method includes:

step 301: acquiring a second request; the second request is used for requesting to inquire whether the first identifier is already hoisted or not;

step 302: querying from the federation chain whether the first identity has been revoked; the alliance chain records IRL;

step 303: and returning a response according to the query result.

In practical application, the third node may be an accounting node or an ordinary access node.

In step 302, the third node queries in the IRL whether the first identity has been revoked.

In practical application, when the IRL is written into the federation chain, the domain name and/or the IMS name (when the IRL includes the IMS name) are/is taken as a key; in addition, there are multiple federation chains in the network, and during query, it is necessary to find the federation chain in which the IRL to be queried is located.

Based on this, in an embodiment, the second request carries the first identifier and a block chain name; and the third node utilizes the first identifier to query a federation chain corresponding to the blockchain name.

In practical application, the first identifier may be an anonymous identifier, that is, the first identifier is a hidden user identifier, and in order to query the anonymous identifier, an operation result of a hash algorithm performed on the first identifier may be used for querying.

Based on this, in an embodiment, the second request carries an operation result and a block chain name after the operation is performed on the first identifier by using a hash function indicated by a public parameter of an ID-PKC system;

when the first identification is not found, returning second information; the second information indicates that the first identity is valid.

Illustratively, the specific process of identifying a query may include:

step 1: the user uses the identifier to inquire the alliance chain, if the identifier is found, the identifier is abolished (namely, the identifier is abolished), a user message is returned to the user (namely, the identifier of the user is abolished), and if the identifier is not found, the step 2 is carried out; here, the user initiates a query request through the API;

step 2: the user uses the hash function indicated in the public parameter of the ID-PKC system to calculate the identifier to be inquired to obtain a calculation result, the calculation result is used for inquiring the alliance chain, if the value identical to the calculation result exists, the user identifier is indicated to be abolished, and a user message is returned to the user (namely, the user identifier is abolished); if the same value is not found, the user identification is valid, a user message is returned to the user (namely, the user identification is valid), and whether the anonymous identification is valid or not can be inquired on the alliance chain through the method.

In practical application, in step 302, when the third node is a normal node, the third node may address to a corresponding IMS according to an IMS name in the ID-PKC system public parameter (which may be an IMS belonging to the same domain as the third node, or an IMS belonging to a different domain from the third node), and then initiate a query request to the corresponding IMS to query whether the first identifier is revoked.

When the third node is the accounting node of the block chain name corresponding alliance chain, whether the first identification is revoked can be directly inquired.

As can be seen from the above description, in the embodiment of the present application, the KGC including the PKG, the PPS, and the IMS forms a federation chain with the user terminal. And after a PPS passes through the consensus process, writing corresponding ID-PKC system public parameters in the alliance chain. And after a consensus process, one IMS writes the IRL in the corresponding domain in the alliance chain. The user terminal cannot write data on the alliance chain, and can only read data from the alliance chain.

According to the ID-PKC information processing method provided by the embodiment of the application, a first node acquires a first ID-PKC system public parameter and/or an IRL; the status of the first ID-PKC system common parameter is valid; the first node is a billing node; writing the acquired first ID-PKC system public parameters and/or IRL into a alliance chain based on a consensus mechanism; the second node acquires the first request; the first request is used for requesting to acquire ID-PKC system public parameters; inquiring corresponding ID-PKC system public parameters from the alliance chain; and returning a response according to the query result; the third node acquires a second request; the second request is used for requesting to inquire whether the first identifier is already hoisted or not; querying from the federation chain whether the first identity has been revoked; the alliance chain records IRL; and returns a response according to the query result. According to the scheme provided by the embodiment of the application, the issuing of the public parameters of the ID-PKC system and the management of the identifier revocation are carried out based on the alliance chain, the parameters of the ID-PKC system and the IRL can be transmitted in a cross-domain mode by using the alliance chain, and the identifier revocation can be inquired in the cross-domain mode, so that the cross-domain safe communication can be realized by using the ID-PKC system without depending on a PKI system.

In order to implement the method according to the embodiment of the present application, an embodiment of the present application further provides an ID-PKC information processing apparatus, which is disposed on a first node, and as shown in fig. 4, the apparatus includes:

a first obtaining unit 401, configured to obtain a first ID-PKC system common parameter and/or an IRL; the status of the first ID-PKC system common parameter is valid; the first node is a billing node;

a first processing unit 402, configured to write the obtained first ID-PKC system common parameters and/or IRL into the federation chain based on the consensus mechanism.

In an embodiment, the first obtaining unit 401 is further configured to obtain a second ID-PKC system public parameter; the status of the second ID-PKC system public parameter is invalid; the second ID-PKC system common parameter is the same as the first ID-PKC system common parameter except the production time and the state;

the first processing unit 402 is further configured to write the obtained second ID-PKC system public parameter into the federation chain based on a consensus mechanism;

the first obtaining unit 401 is further configured to obtain a newly generated third ID-PKC system common parameter; the third ID-PKC system common parameter is updated by the first ID-PKC system common parameter; the status of the third ID-PKC system public parameter is valid;

the first processing unit 402 is further configured to write the obtained third ID-PKC system common parameters into the federation chain based on a consensus mechanism.

In practical application, the first obtaining unit 401 may be implemented by a communication interface in an ID-PKC information processing apparatus; the first processing unit 402 may be implemented by a communication interface in an ID-PKC information processing apparatus in combination with a processor.

In order to implement the method at the second node side in the embodiment of the present application, an embodiment of the present application further provides an ID-PKC information processing apparatus, which is disposed on the second node, and as shown in fig. 5, the apparatus includes:

a second obtaining unit 501, configured to obtain the first request; the first request is used for requesting to acquire ID-PKC system public parameters;

a second processing unit 502, configured to query a corresponding ID-PKC system public parameter from the federation chain; and returning a response according to the query result.

In an embodiment, when the second processing unit 502 queries the corresponding ID-PKC system common parameter from the federation chain, the query starts from the latest block of the federation chain.

In an embodiment, the first request carries a domain name and a blockchain name;

the second processing unit 502 is specifically configured to query, by using the domain name carried in the first request, a corresponding ID-PKC system public parameter from a federation chain corresponding to the block chain name.

In an embodiment, the first request further carries a PPS name;

In an embodiment, the second processing unit 502 is specifically configured to:

alternatively, the first and second electrodes may be,

In practical application, the second obtaining unit 501 may be implemented by a communication interface in an ID-PKC information processing apparatus; the second processing unit 502 may be implemented by a communication interface of the ID-PKC information processing apparatus in combination with a processor.

In order to implement the method on the third node side in this embodiment of the present application, an embodiment of the present application further provides an ID-PKC information processing apparatus, which is disposed on the third node, as shown in fig. 6, and includes:

a third obtaining unit 601, configured to obtain the second request; the second request is used for requesting to inquire whether the first identifier is already hoisted or not;

a third processing unit 602, configured to query from the federation chain whether the first identity has been revoked; the alliance chain records IRL; and returning a response according to the query result.

In an embodiment, the second request carries the first identifier and a blockchain name; the third processing unit 602 performs query on the federation chain corresponding to the blockchain name by using the first identifier.

In an embodiment, the second request carries an operation result and a block chain name obtained by operating the hash function indicated by the public parameter of the ID-PKC system on the first identifier;

the third processing unit 602 performs query on the alliance chain corresponding to the block chain name by using the operation result.

In an embodiment, the third processing unit 602 is specifically configured to:

when the first identification is inquired to be cancelled, returning first information; the first information indicates that the first identifier has been pinned;

alternatively, the first and second electrodes may be,

In practical application, the third obtaining unit 601 may be implemented by a communication interface in an ID-PKC information processing apparatus; the third processing unit 602 may be implemented by a communication interface in an ID-PKC information processing apparatus in combination with a processor.

It should be noted that: in the ID-PKC information processing apparatus provided in the above embodiment, when performing the ID-PKC information processing, only the division of the above program modules is exemplified, and in practical applications, the above processing may be distributed to be completed by different program modules according to needs, that is, the internal structure of the apparatus may be divided into different program modules to complete all or part of the above described processing. In addition, the ID-PKC information processing apparatus provided in the above embodiments and the ID-PKC information processing method embodiments belong to the same concept, and specific implementation procedures thereof are detailed in the method embodiments, and are not described herein again.

Based on the hardware implementation of the program module, and in order to implement the method of the control center side in the embodiment of the present application, an embodiment of the present application further provides a first node, as shown in fig. 7, where the first node 700 includes:

a first communication interface 701, which can perform information interaction with other nodes (such as other accounting nodes);

the first processor 702 is connected to the first communication interface 701 to implement information interaction with other nodes, and is configured to execute a method provided by one or more technical solutions at the first node side when running a computer program;

a first memory 703, said computer program being stored on said first memory 703.

Specifically, the first communication interface 701 is configured to obtain a first ID-PKC system common parameter and/or an IRL; the status of the first ID-PKC system public parameter is valid; the first node 700 is a billing node;

the first processor 702 is configured to write the obtained first ID-PKC system common parameters and/or IRL into a federation chain based on a consensus mechanism.

In an embodiment, the first communication interface 701 is further configured to obtain a second ID-PKC system public parameter; the status of the second ID-PKC system public parameter is invalid; the second ID-PKC system common parameter is the same as the first ID-PKC system common parameter except the production time and the state;

the first processor 702 is further configured to write the obtained second ID-PKC system public parameter into the federation chain based on a consensus mechanism;

the first communication interface 701 is further configured to obtain a newly generated third ID-PKC system public parameter; the third ID-PKC system common parameter is updated by the first ID-PKC system common parameter; the status of the third ID-PKC system public parameter is valid;

the first processor 702 is further configured to write the obtained third ID-PKC system common parameters into the federation chain based on a consensus mechanism.

It should be noted that: the specific processing procedure of the first processor 702 can be understood with reference to the above-described method.

Of course, in practice, the various components in the first node 700 are coupled together by a bus system 704. It is understood that the bus system 704 is used to enable connected communication between these components. The bus system 704 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are designated as bus system 704 in FIG. 7.

The first memory 703 in the embodiment of the present application is used to store various types of data to support the operation of the first node 700. Examples of such data include: any computer program for operating on the first node 700.

The method disclosed in the embodiments of the present application can be applied to the first processor 702, or implemented by the first processor 702. The first processor 702 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be implemented by integrated logic circuits of hardware or instructions in the form of software in the first processor 702. The first Processor 702 may be a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. The first processor 702 may implement or perform the methods, steps and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium located in the first memory 703, and the first processor 702 reads the information in the first memory 703 and completes the steps of the foregoing method in combination with its hardware.

In an exemplary embodiment, the first node 700 may be implemented by one or more Application Specific Integrated Circuits (ASICs), DSPs, programmable Logic Devices (PLDs), complex Programmable Logic Devices (CPLDs), field Programmable Gate Arrays (FPGAs), general purpose processors, controllers, micro Controllers (MCUs), microprocessors (microprocessors), or other electronic components for performing the aforementioned methods.

Based on the hardware implementation of the program module, and in order to implement the method at the second node side in the embodiment of the present application, an embodiment of the present application further provides a second node, as shown in fig. 8, where the second node 800 includes:

a second communication interface 801 capable of performing information interaction with other nodes, users, and the like;

a second processor 802, connected to the second communication interface 801, for implementing information interaction with other nodes and users, and when running a computer program, executing the method provided by one or more technical solutions at the second node side;

a second memory 803, said computer program being stored on said second memory 803.

Specifically, the second communication interface 801 is configured to obtain a first request; the first request is used for requesting to acquire public parameters of an ID-PKC system;

the second processor 802 is configured to query a corresponding ID-PKC system public parameter from a federation chain; and returning a response through the second communication interface according to the query result.

In one embodiment, when the second processor 802 queries the corresponding ID-PKC system common parameters from the federation chain, it starts querying from the latest block of the federation chain.

the second processor 802 is specifically configured to query, by using the domain name carried in the first request, a corresponding ID-PKC system public parameter from a federation chain corresponding to the block chain name.

In an embodiment, the first request further carries a PPS name;

the second processor 802 is specifically configured to query, by using the domain name and/or the PPS name carried in the first request, a corresponding ID-PKC system public parameter from a federation chain corresponding to the blockchain name.

In an embodiment, the second processor 802 is specifically configured to:

alternatively, the first and second electrodes may be,

It should be noted that: the specific processing procedure of the second processor 802 can be understood with reference to the above-described method.

Of course, in practice, the various components in the second node 800 are coupled together by a bus system 804. It is understood that the bus system 804 is used to enable communications among the components. The bus system 804 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are identified in FIG. 8 as the bus system 804.

The second memory 803 in the present embodiment is used to store various types of data to support the operation of the second node 800. Examples of such data include: any computer program for operating on the second node 800.

The method disclosed in the embodiment of the present application can be applied to the second processor 802, or implemented by the second processor 802. The second processor 802 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be implemented by integrated logic circuits of hardware or instructions in the form of software in the second processor 802. The second processor 802 described above may be a general purpose processor, DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or the like. The second processor 802 may implement or perform the methods, steps, and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium located in the second memory 803, and the second processor 802 reads the information in the second memory 803, and completes the steps of the foregoing method in conjunction with its hardware.

In an exemplary embodiment, the second node 800 may be implemented by one or more ASICs, DSPs, PLDs, CPLDs, FPGAs, general-purpose processors, controllers, MCUs, microprocessors, or other electronic components for performing the aforementioned methods.

Based on the hardware implementation of the program module, and in order to implement the method at the third node side in the embodiment of the present application, an embodiment of the present application further provides a third node, and as shown in fig. 9, the third node 900 includes:

a third communication interface 901 capable of performing information interaction with other nodes, users, and the like;

a third processor 902, connected to the third communication interface 901, for implementing information interaction with other nodes and users, and when running a computer program, executing a method provided by one or more technical solutions at the third node side;

a third memory 903, said computer program being stored on said third memory 903.

Specifically, the third communication interface 901 is configured to obtain a second request; the second request is used for requesting to inquire whether the first identifier is already hoisted or not;

the third processor 902, configured to query from the federation chain whether the first identity has been revoked; the alliance chain records IRL; and returning a response through the third communication interface according to the query result.

In an embodiment, the second request carries the first identifier and the blockchain name, and the third processor 902 performs query on the federation chain corresponding to the blockchain name by using the first identifier.

the third processor 902 uses the operation result to perform a query on the federation chain corresponding to the blockchain name.

In an embodiment, the third processor 902 is specifically configured to:

alternatively, the first and second electrodes may be,

It should be noted that: the specific processing of the third processor 902 can be understood with reference to the above-described method.

Of course, in practice, the various components in the third node 900 are coupled together by a bus system 904. It is understood that the bus system 904 is used to enable communications among the components. The bus system 904 includes a power bus, a control bus, and a status signal bus in addition to a data bus. But for clarity of illustration the various buses are labeled as bus system 904 in figure 9.

The third memory 903 in the embodiment of the present application is used to store various types of data to support the operation of the third node 900. Examples of such data include: any computer program for operating on the third node 900.

The method disclosed in the embodiment of the present application may be applied to the third processor 902, or implemented by the third processor 902. The third processor 902 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be implemented by an integrated logic circuit of hardware or an instruction in the form of software in the third processor 902. The third processor 902 described above may be a general purpose processor, DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or the like. The third processor 902 may implement or execute the methods, steps and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium located in the third memory 903, and the third processor 902 reads the information in the third memory 903 and performs the steps of the foregoing methods in combination with its hardware.

In an exemplary embodiment, the third node 900 may be implemented by one or more ASICs, DSPs, PLDs, CPLDs, FPGAs, general-purpose processors, controllers, MCUs, microprocessors, or other electronic components for performing the aforementioned methods.

It is to be understood that the memories (the first memory 703, the second memory 803, and the third memory 903) of the embodiments of the present application may be volatile memories or nonvolatile memories, and may include both volatile and nonvolatile memories. Among them, the nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a magnetic random access Memory (FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical Disc, or a Compact Disc Read-Only Memory (CD-ROM); the magnetic surface storage may be disk storage or tape storage. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of illustration and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), synchronous Static Random Access Memory (SSRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), enhanced Synchronous Dynamic Random Access Memory (ESDRAM), enhanced Synchronous Dynamic Random Access Memory (Enhanced DRAM), synchronous Dynamic Random Access Memory (SLDRAM), direct Memory (DRmb Access), and Random Access Memory (DRAM). The memories described in the embodiments of the present application are intended to comprise, without being limited to, these and any other suitable types of memory.

In an exemplary embodiment, the present application further provides a storage medium, specifically a computer-readable storage medium, for example, a first memory 703 storing a computer program, which is executable by a first processor 702 of a first node 700 to perform the steps of the first node-side method, and for example, a second memory 803 storing a computer program, which is executable by a second processor 802 of a second node 800 to perform the steps of the second node-side method; further for example, the third memory 903 is comprised to store a computer program which is executable by the third processor 902 of the third node 900 to perform the steps of the aforementioned third node side method. The computer readable storage medium may be Memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash Memory, magnetic surface Memory, optical disk, or CD-ROM.

It should be noted that: "first," "second," and the like are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.

The technical means described in the embodiments of the present application may be arbitrarily combined without conflict.

The above description is only a preferred embodiment of the present application, and is not intended to limit the scope of the present application.

Claims

1. A public cipher ID-PKC information processing method based on identification is applied to a first node and comprises the following steps:

acquiring a first ID-PKC system public parameter and/or an identification revoke list IRL; the status of the first ID-PKC system public parameter is valid; the first node is a billing node;

writing the acquired first ID-PKC system common parameters and/or IRL into a federation chain based on a consensus mechanism.

2. The method according to claim 1, wherein the first ID-PKC system public parameters are generated by a public parameter server of a key generation center KGC;

the first ID-PKC system common parameters comprise at least one of:

a domain name;

a blockchain name;

a system common parameter status;

a hashing algorithm for hiding the user identification.

3. The method of claim 2, wherein the domain name is a name defined by a Uniform Resource Identifier (URI) or a Uniform Resource Locator (URL), or is a custom name.

4. The method of claim 2, wherein the first ID-PKC system common parameters further comprise at least one of:

a public parameter server name;

the management server name is identified.

5. The method of claim 4, wherein the common parameter server name is a name defined by a URI or URL, or a custom name.

6. The method of claim 4, wherein the identity management server name is a name defined by a URI or URL, or a custom name.

7. The method according to claim 1, wherein the IRL is generated by an identity management server of the KGC;

the IRL includes at least one of:

a domain name;

a blockchain name;

a set of lift pin identifications.

8. The method of claim 7, wherein the domain name is referred to as a name defined by a URI or URL, or a custom name.

9. The method of claim 7, wherein the IRL further comprises:

the management server name is identified.

10. The method of claim 9, wherein the identity management server name is a name defined by a URI or URL, or a custom name.

11. The method of claim 7, wherein the set of pin identifiers comprises at least one of:

whether the revoke mark is anonymous;

lifting pin identification;

the reason for lifting the pin.

12. The method of any one of claims 1 to 11, further comprising:

acquiring newly generated third ID-PKC system public parameters; the third ID-PKC system common parameter is updated by the first ID-PKC system common parameter; the status of the third ID-PKC system public parameter is valid;

13. An ID-PKC information processing method applied to a second node includes:

and returning a response according to the query result.

14. The method according to claim 13, wherein the querying of corresponding ID-PKC system common parameters from a federation chain comprises:

starting the query from the newest block of the federation chain.

15. The method of claim 13, wherein the first request carries a domain name and a blockchain name;

and querying corresponding ID-PKC system public parameters from the alliance chain corresponding to the block chain name by using the domain name carried by the first request.

16. The method of claim 15, wherein the first request further carries a common parameter server name;

and querying corresponding ID-PKC system public parameters from a alliance chain corresponding to the block chain name by using the domain name and/or the public parameter server name carried by the first request.

17. The method according to any one of claims 13 to 16, wherein the returning a response according to the query result comprises:

alternatively, the first and second electrodes may be,

18. An ID-PKC information processing method, applied to a third node, includes:

and returning a response according to the query result.

19. The method of claim 18, wherein the second request carries the first identifier and a blockchain name; and querying a alliance chain corresponding to the block chain name by using the first identifier.

20. The method of claim 18, wherein the second request carries a result of the operation performed on the first identifier using a hash function indicated by a public parameter of an ID-PKC system and a blockchain name;

21. The method according to any one of claims 18 to 20, wherein the returning a response according to the query result comprises:

alternatively, the first and second electrodes may be,

22. An ID-PKC information processing apparatus provided at a first node, comprising:

a first processing unit, configured to write the obtained first ID-PKC system common parameters and/or IRL into the federation chain based on a consensus mechanism.

23. An ID-PKC information processing apparatus, comprising:

24. An ID-PKC information processing apparatus, comprising:

a third processing unit, configured to query from the federation chain whether the first identity has been revoked; the alliance chain records IRL; and returning a response according to the query result.

25. A first node, comprising: a first communication interface and a first processor; wherein the content of the first and second substances,

a first processor, configured to write the obtained first ID-PKC system common parameters and/or IRL into a federation chain based on a consensus mechanism.

26. A second node, comprising: a second communication interface and a second processor; wherein, the first and the second end of the pipe are connected with each other,

27. A third node, comprising: a third communication interface and a third processor; wherein the content of the first and second substances,

the third processor is used for inquiring whether the first identification is already cancelled from the alliance chain; the alliance chain records IRL; and returning a response through the third communication interface according to the query result.

28. A first node, comprising: a first processor and a first memory for storing a computer program capable of running on the processor,

wherein the first processor is adapted to perform the steps of the method of any one of claims 1 to 12 when running the computer program.

29. A second node, comprising: a second processor and a second memory for storing a computer program capable of running on the processor,

wherein the second processor is adapted to perform the steps of the method of any one of claims 13 to 17 when running the computer program.

30. A third node, comprising: a third processor and a third memory for storing a computer program capable of running on the processor,

wherein the third processor is adapted to perform the steps of the method of any of claims 18 to 21 when running the computer program.

31. A storage medium having stored thereon a computer program for performing the steps of the method of any one of claims 1 to 12, or for performing the steps of the method of any one of claims 13 to 17, or for performing the steps of the method of any one of claims 18 to 21, when the computer program is executed by a processor.