Digital-certificate generation method and apparatus, digital-certificate verification method and apparatus, and communication connection method and apparatus

Abstract

Provided in the present description are a digital-certificate generation method and apparatus, a digital-certificate verification method and apparatus, and a communication connection method and apparatus. The digital-certificate generation method comprises: determining a root certificate of each member party in a mutual-trust consortium; each member party digitally signing other member parties, so as to obtain a cross-signed certificate of any two member parties; each member party digitally signing a terminal device of the member party, so as to obtain a device certificate; and issuing the root certificate, the cross-signed certificate and the device certificate of the member party to a corresponding terminal device. By means of using a three-level certificate chain, the mutual trust and mutual authentication crossing member party devices can be implemented. Moreover, the certificate chain provides dual authentication of member-party identities and device identities, thereby improving information security. In addition, a trust relationship can be established as long as the certificate chain of either party is complete and passes verification, such that the participation of a third-party trust authorization center is not necessary for consortium members in decentralized consortium architecture, thereby reducing maintenance costs.

Description

Digital certificate generation and verification method, communication connection method and device Technical Field

[0001] This specification relates to the field of communication technology, specifically to a digital certificate generation and verification method, a communication connection method, and an apparatus. Background Technology

[0002] Networkless communication technology refers to communication without relying on external networks (such as cellular networks, the Internet, etc.). That is, point-to-point communication between two devices without the need for base stations or routers to provide a network. Networkless communication can achieve communication distances of up to hundreds of meters or even several kilometers, and has great application prospects.

[0003] Currently, wireless communication technology lacks a unified protocol standard. Each manufacturer's wireless communication technology is developed based on proprietary protocols, requiring both ends to be devices of the same brand to support it, which greatly limits the application of wireless communication technology. To achieve wireless communication between devices of different brands, establishing trust between the communicating parties is a prerequisite for ensuring communication security. Summary of the Invention

[0004] To address the trust establishment issue between cross-brand devices, this specification provides a digital certificate generation method and apparatus, a digital certificate verification method and apparatus, a communication connection method and apparatus, a communication system, an electronic device, a storage medium, and a computer program product.

[0005] In a first aspect, this disclosure provides a digital certificate generation method, including:

[0006] The root certificate of each member in the mutual trust alliance is determined, and each member digitally signs the other members to obtain a mutual signature certificate between any two members.

[0007] Each member party digitally signs the terminal devices belonging to that member party to obtain a device certificate, and distributes and stores the root certificate, mutual signature certificate, and device certificates of its subordinate terminal devices to the corresponding terminal devices.

[0008] In some implementations, the root certificate, mutual signature certificate, and device certificates of the subordinate terminal devices corresponding to the member party are distributed and stored in the corresponding terminal devices, including:

[0009] The member's server distributes and stores the member's root certificate, mutual signature certificate, and device certificates of its subordinate terminal devices in the corresponding terminal devices.

[0010] Secondly, this specification provides a digital certificate verification method applied to a first device, which is a first member of a mutual trust alliance. The method includes:

[0011] If the first device stores a mutual signature certificate between the first member party and the second member party, the first device certificate of the first device and the first digital certificate of the first member party issued by the second member party are sent to the second device so that the second device can verify the first device certificate and the first digital certificate based on the stored root certificate.

[0012] Receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party;

[0013] In response to the successful verification of both the first device and the second device, it is determined that the first device and the second device are mutually trusted devices; wherein, the second device belongs to the second member party in the mutual trust alliance, and the mutual signature certificate between the first member party and the second member party includes the first digital certificate and the second digital certificate.

[0014] In some implementations, receiving a second device certificate from a second device and verifying the second device certificate based on a second digital certificate issued by a first member party includes:

[0015] Receive the second device certificate sent by the second device, and verify the second digital certificate using the stored root certificate to determine the public key of the second member party;

[0016] The second member's public key is used to verify the signature of the second device certificate.

[0017] Thirdly, this specification provides a digital certificate verification method applied to a second device, which is a first member of a mutual trust alliance. The method includes:

[0018] The device receives the first device certificate sent by the first device and the first digital certificate of the first member party issued by the second member party, wherein the first device belongs to the first member party in the mutual trust alliance;

[0019] The root certificate of the storage is used to verify the signature of the first device certificate and the first digital certificate.

[0020] Send the second device certificate of the second device to the first device so that the first device can verify the second device certificate based on the stored second digital certificate, the second digital certificate representing the certificate of the second member party issued by the first member party;

[0021] In response to the successful verification of both the first device and the second device, it is determined that the first device and the second device are mutually trusted devices.

[0022] In some implementations, the signature verification of the first device certificate and the first digital certificate is performed based on the stored root certificate, including:

[0023] The first digital certificate is verified using the stored root certificate to determine the public key of the first member party;

[0024] The first device certificate is verified using the public key of the first member party.

[0025] Fourthly, this specification provides a communication connection method applied to a first device, which is a first member of a mutual trust alliance. The method includes:

[0026] Send a connection request to the second device, and if the second device responds to the connection request, perform certificate verification with the second device, where the second device is a second member of the mutual trust alliance;

[0027] If the certificate verification with the second device is successful, a communication connection is established with the second device.

[0028] In some implementations, sending a connection request to the second device includes:

[0029] Obtain the first identification code and the first random string of the first device, and perform an obfuscation operation based on the first identification code and the first random string to obtain the first digest;

[0030] The connection request is sent to the second device, the connection request including at least a portion of the characters of the first digest and the first random string.

[0031] In some implementations, the connection request may also include a portion of the characters of the first identity code.

[0032] In some implementations, the process of performing certificate verification with the second device includes:

[0033] If the first device stores a mutual signature certificate between the first member party and the second member party, the first device certificate of the first device and the first digital certificate of the first member party issued by the second member party are sent to the second device so that the second device can verify the first device certificate and the first digital certificate based on the stored root certificate.

[0034] Receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party;

[0035] In response to the successful verification of both the first device and the second device, the mutual verification of certificates is confirmed to be successful, wherein the mutual verification certificate between the first member party and the second member party includes the first digital certificate and the second digital certificate.

[0036] In some implementations, receiving a second device certificate from a second device and verifying the second device certificate based on a second digital certificate issued by a first member party includes:

[0037] Receive the second device certificate sent by the second device, and verify the second digital certificate using the stored root certificate to determine the public key of the second member party;

[0038] The second member's public key is used to verify the signature of the second device certificate.

[0039] In some implementations, the process of performing certificate verification with the second device includes:

[0040] Send a third digital certificate of the first member party issued by the trust center of the mutual trust alliance to the second device, so that the second device can verify the third digital certificate based on the root certificate of the trust center stored therein;

[0041] Receive the fourth digital certificate of the second member party issued by the trust center sent by the second device, and verify the signature of the fourth digital certificate based on the root certificate of the trust center stored in the system;

[0042] In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

[0043] In some implementations, establishing a communication connection with the second device after successful certificate verification includes:

[0044] If the certificate verification with the second device is successful, the first identity code is sent to the second device so that the second device can verify the device identity of the first device based on the first identity code;

[0045] Receive the second identity code sent by the second device, and verify the device identity of the second device based on the second identity code;

[0046] If the device identities of both the first device and the second device are verified, a communication connection is established with the second device.

[0047] Fifthly, this specification provides a communication connection method for a second device, which is a second member of a mutual trust alliance. The method includes:

[0048] The system receives a connection request from a first device and initiates certificate verification with the first device based on the connection request. The first device is the first member of the mutual trust alliance.

[0049] If the certificate verification with the first device is successful, a communication connection is established with the first device.

[0050] In some implementations, the connection request includes at least some characters of a first digest and a first random string, wherein the first digest is generated by obfuscating the first identification code of the first device and the first random string;

[0051] Initiating certificate verification with the first device based on the connection request includes:

[0052] Obtain the identity identifiers in the whitelist, and generate a second digest by performing an obfuscation operation between each identity identifier in the whitelist and the first random string;

[0053] The second digest is matched with the first digest, or a portion of the characters in the second digest is matched with the corresponding characters in the first digest. If the match is successful, a certificate verification with the first device is initiated.

[0054] In some implementations, the connection request further includes partial characters of the first identity code; obtaining identity identifiers within a whitelist, and generating a second digest by performing an obfuscation operation between each identity identifier in the whitelist and the first random string, including:

[0055] Obtain the identity identifiers in the whitelist, and use a portion of the characters of the first identity identifier code to filter each identity identifier in the whitelist to obtain candidate identity identifiers corresponding to a portion of the characters of the first identity identifier code;

[0056] A second digest is generated by obfuscating each candidate identity in the whitelist with the first random string.

[0057] In some implementations, the process of performing certificate verification with the first device includes:

[0058] Receive the first device certificate of the first device sent by the first device, and the first digital certificate of the first member party issued by the second member party;

[0059] The root certificate of the storage is used to verify the signature of the first device certificate and the first digital certificate.

[0060] Send the second device certificate of the second device to the first device so that the first device can verify the second device certificate based on the stored second digital certificate, the second digital certificate representing the certificate of the second member party issued by the first member party;

[0061] In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

[0062] In some implementations, the signature verification of the first device certificate and the first digital certificate is performed based on the stored root certificate, including:

[0063] The first digital certificate is verified using the stored root certificate to determine the public key of the first member party;

[0064] The first device certificate is verified using the public key of the first member party.

[0065] In some implementations, the process of performing certificate verification with the first device includes:

[0066] Receive a third digital certificate from a first member party issued by the trust center of the mutual trust alliance, sent by the first device, and verify the third digital certificate based on the root certificate of the trust center stored in the device.

[0067] Send a fourth digital certificate of the second member party issued by the trust center to the first device, so that the first device can verify the fourth digital certificate based on the root certificate of the trust center stored therein;

[0068] In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

[0069] In some implementations, establishing a communication connection with the first device after successful certificate verification with the first device includes:

[0070] If the certificate verification with the first device is successful, a second identity code is sent to the first device so that the first device can verify the device identity of the second device based on the second identity code;

[0071] Receive the first identification code sent by the first device, and verify the device identity of the first device based on the first identification code;

[0072] If the device identities of both the first device and the second device are verified, a communication connection is established with the second device.

[0073] In some implementations, the communication connection between the first device and the second device includes: Bluetooth communication connection, WiFi communication connection, LoRa communication connection, or UWB communication connection.

[0074] Sixthly, this specification provides a digital certificate verification device applied to a first device, which is a first member of a mutual trust alliance. The device includes:

[0075] The first sending module is configured to send the first device certificate of the first device and the first digital certificate of the first member party issued by the second member party to the second device when the first device stores the mutual signature certificate of the first member party and the second member party, so that the second device can verify the first device certificate and the first digital certificate based on the stored root certificate.

[0076] The first verification module is configured to receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party; in response to the successful verification of both the first device and the second device, the first device and the second device are determined to be mutually trusted devices; wherein, the second device belongs to the second member party in the mutual trust alliance, and the mutual signature certificate between the first member party and the second member party includes the first digital certificate and the second digital certificate.

[0077] Seventhly, this specification provides a digital certificate verification device applied to a second device, the second device being a first member of a mutual trust alliance, the device comprising:

[0078] The first receiving module is configured to receive the first device certificate of the first device sent by the first device, and the first digital certificate of the first member party issued by the second member party, wherein the first device belongs to the first member party in the mutual trust alliance;

[0079] The second signature verification module is configured to verify the signatures of the first device certificate and the first digital certificate based on the stored root certificate.

[0080] The second sending module is configured to send the second device certificate of the second device to the first device, so that the first device verifies the second device certificate based on the stored second digital certificate, the second digital certificate representing the certificate of the second member issued by the first member; in response to both the first device and the second device passing the verification, the first device and the second device are determined to be mutually trusted devices.

[0081] Eighthly, embodiments of this specification provide a communication connection device applied to a first device, the first device being a first member of a mutual trust alliance, the device comprising:

[0082] The request sending module is configured to send a connection request to the second device, and, if the second device responds to the connection request, perform certificate verification with the second device, wherein the second device is a second member of the mutual trust alliance;

[0083] The communication establishment module is configured to establish a communication connection with the second device after the certificate mutual verification with the second device is successful.

[0084] Ninthly, embodiments of this specification provide a communication connection device applied to a second device, the second device being a second member of a mutual trust alliance, the device comprising:

[0085] The request receiving module is configured to receive a connection request sent by a first device and initiate certificate verification with the first device based on the connection request. The first device is the first member of the mutual trust alliance.

[0086] The communication establishment module is configured to establish a communication connection with the first device if the certificate verification with the first device is successful.

[0087] In a tenth aspect, embodiments of this specification provide a communication system including multiple member parties, the communication system being used to implement the digital certificate generation method described in any of the above embodiments.

[0088] Eleventhly, embodiments of this specification provide an electronic device, including:

[0089] processor;

[0090] The memory stores computer instructions that cause the processor to perform the method described in any of the above embodiments.

[0091] In a twelfth aspect, embodiments of this specification provide a storage medium storing computer instructions for implementing the methods described in any of the above embodiments.

[0092] In a thirteenth aspect, embodiments of this specification provide a computer program product for implementing the methods described in any of the above embodiments.

[0093] The digital certificate generation method described in this specification includes determining the root certificate of each member in a mutual trust alliance, with each member digitally signing other members to obtain a mutual signature certificate between any two members, and each member digitally signing the terminal device of that member to obtain a device certificate. The member's root certificate, mutual signature certificate, and device certificate are then distributed to the corresponding terminal device. This three-level certificate chain enables mutual trust and recognition between member devices. Furthermore, the certificate chain provides dual authentication of both member and device identities, improving information security. A trust relationship can be established as long as one party's certificate chain is complete and verified. The decentralized alliance architecture eliminates the need for a third-party trust center, reducing maintenance costs. Attached Figure Description

[0094] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0095] Figure 1 is an architecture diagram of a trusted alliance in some embodiments of this specification.

[0096] Figure 2 is an architecture diagram of a trusted alliance in some embodiments of this specification.

[0097] Figure 3 is an architecture diagram of a trusted alliance in some embodiments of this specification.

[0098] Figure 4 is a flowchart of a digital certificate generation method in some embodiments of this specification.

[0099] Figure 5 is a schematic diagram of the certificate chain stored in the electronic device in some embodiments of this specification.

[0100] Figure 6 is a schematic diagram of the digital certificate verification method in some embodiments of this specification.

[0101] Figure 7 is a flowchart of a communication connection method in some embodiments of this specification.

[0102] Figure 8 is a flowchart of a communication connection method in some embodiments of this specification.

[0103] Figure 9 is a schematic diagram of certificate mutual verification in some embodiments of this specification.

[0104] Figure 10 is a flowchart of a communication connection method in some embodiments of this specification.

[0105] Figure 11 is a structural block diagram of a digital certificate generation device in some embodiments of this specification.

[0106] Figure 12 is a structural block diagram of a digital certificate verification device in some embodiments of this specification.

[0107] Figure 13 is a structural block diagram of the communication connection device in some embodiments of this specification.

[0108] Figure 14 is a structural block diagram of a communication connection device in some embodiments of this specification.

[0109] Figure 15 is a structural block diagram of an electronic device in some embodiments of this specification. Detailed Implementation

[0110] The technical solutions of this disclosure will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure. Furthermore, the technical features involved in the different embodiments of this disclosure described below can be combined with each other as long as they do not conflict with each other.

[0111] Wireless communication refers to communication technologies that do not rely on external networks (such as cellular networks or the Internet). In other words, it involves point-to-point communication between two devices without the need for third-party equipment (such as base stations or wireless routers) to provide a network. Wireless communication can achieve communication distances of hundreds of meters or even several kilometers, and has enormous application potential.

[0112] For example, in scenarios without base station signals, such as in the wild or at sea, or in situations where base station signals are interrupted due to natural disasters such as floods or earthquakes, wireless communication can provide basic communication between mobile terminals and between mobile terminals and other terminals (such as cars), enabling short-range emergency calls or voice calls. Another example is when traveling abroad; wireless communication allows users to stay in touch with family and friends without incurring roaming charges. Furthermore, for small-scale social and entertainment activities, wireless communication can provide users with walkie-talkie-style calling capabilities, increasing fun and user experience.

[0113] Currently, major manufacturers are conducting research and development on wireless communication, enabling kilometer-level text / voice transmission, two-way voice calls, and even multi-person voice group chats without cellular networks. However, each brand's wireless communication technology is developed based on proprietary protocols, lacking a unified protocol standard within the industry. Wireless communication is only supported when both communicating devices are from the same brand. For example, due to different communication protocols, a phone from brand A can only establish wireless communication connections with other phones from the same brand, and cannot establish wireless communication across brands (such as with a phone from brand B). This limits the application and development of wireless communication, and the development of various proprietary protocols also wastes resources and hinders resource integration.

[0114] To enable wireless communication between devices from different brands, establishing trust between the communicating parties is a prerequisite for ensuring communication security. For example, if a device from brand A initiates a wireless communication request to a device from brand B, how can device B identify that brand A is a trusted brand, and that the requesting device is certified by brand A and not an unauthorized entity? These are issues that must be addressed.

[0115] In order to unify standards and promote the development of wireless communication technology, the industry is committed to establishing a wireless communication mutual trust alliance. Members of the alliance are mutually trusting members, and devices from different members can trust each other.

[0116] Figure 1 illustrates the architecture of a mutual trust alliance according to some embodiments of this specification. Referring to Figure 1, the mutual trust alliance comprises n members: Member 1, Member 2, ..., Member n. Each member refers to a brand manufacturer joining the alliance; for example, Member 1 corresponds to Manufacturer 1, Member 2 corresponds to Manufacturer 2, and so on. The members of the mutual trust alliance can change dynamically; that is, non-alliance members can join the mutual trust alliance as new members, and alliance members can also leave the alliance and cease to be members. This specification does not impose any restrictions on this.

[0117] Taking member 1 as an example, assuming member 1 is mobile phone brand manufacturer M, the corresponding server Server 1 represents the server owned by brand manufacturer M. Server Server 1 can be a server cluster or a cloud platform server, and the server architecture can be centralized or distributed; this specification does not impose any restrictions on this. Clients interacting with server Server 1 refer to terminal devices under brand manufacturer M, such as devices a1, a2, a3, etc., which can be the same or different models of mobile phones manufactured by brand manufacturer M. These terminal devices can access brand manufacturer M's server Server 1 via wireless network. The same logic applies to other members. For example, taking member 2 as an example, server Server 2 is the server owned by member 2, and devices b1, b2, b3 represent terminal devices under member 2; this specification will not elaborate further on this.

[0118] In cross-device wireless communication scenarios, taking communication between device a1 and device b2 as an example, device a1 is a device produced by member party 1, and device a2 is a device produced by member party 2. The establishment of trust between the two is a prerequisite for communication security.

[0119] In some implementations, as shown in Figure 2, a trusted third-party CA (Certificate Authority) can be created or nominated by the alliance members, i.e., the CA center shown in Figure 2. The CA center is a recognized trusted authority among the members and is the fundamental guarantee for digital signatures. The digital certificate issued by the CA center can prove the identity of a member and the legitimacy of its public key.

[0120] Therefore, a CA center can issue digital certificates to each member in the alliance. For example, the CA center issues digital certificate Crt-1 to member 1, digital certificate Crt-2 to member 2, and so on. Each member has a digital certificate issued by the CA center. The digital certificate can prove the legitimacy of the member's identity, that is, the member is a trusted member in the alliance.

[0121] After receiving the issued digital certificate, member parties can distribute the digital certificate to their subordinate terminal devices through the server. For example, member party 1 can distribute digital certificate Crt-1 to device a1 through server Server 1, and member party 2 can distribute digital certificate Crt-2 to device b2 through server Server 2. Devices a1 and b2 store the digital certificates locally. Simultaneously, each member party issues device certificates to its subordinate devices; for example, member party 1 issues device certificate Crt-a1 to device a1, and member party 2 issues device certificate Crt-b2 to device b2.

[0122] When device a1 and device b2 request a communication connection, both need to verify the validity of each other's digital certificates. To verify the digital certificate issued by the CA (Certificate Authority), the CA's public key is used for signature verification. To prove the validity of the CA's public key, the CA can generate a root certificate. The root certificate is at the top of the certificate chain and the starting point of the trust chain, representing the highest trusted certificate in the trusted association. The CA's root certificate is securely distributed or pre-installed on each member device.

[0123] During the signature verification process between device a1 and device b2, device a1 can send digital certificate Crt-1 to device b2. Device b2 uses the root certificate of the CA center to verify digital certificate Crt-1. If the verification passes, it indicates that member party 1, to which device a1 belongs, is a legitimate member of the alliance. Simultaneously, device b2 can send digital certificate Crt-2 to device a1. Device a1 uses the root certificate of the CA center to verify digital certificate Crt-2. If the verification passes, it indicates that member party 2, as described by device b2, is a legitimate member of the alliance. If either party fails to verify the signature, it means that one party is an illegitimate party, and a connection cannot be established. The certificate mutual verification process will be described in the implementation details later in this specification and will not be elaborated here.

[0124] As can be seen, the implementation shown in Figure 2 can establish trust between devices from different brands. However, this implementation requires the participation of an additional third-party organization (i.e., a CA center). The CA center needs to be maintained by all members, which is very costly. Moreover, the alliance members are equal and symmetrical in status. This centralized trust method requires an additional and independent organizational structure, which is not conducive to maintenance.

[0125] Based on this, some embodiments of this specification provide a decentralized mutual trust alliance and a method for generating and verifying digital certificates. No third party is required. Each member in the alliance is a root CA authority, which greatly reduces the trust risk between members in centralized trust. Furthermore, through certificate mutual signing and verification, even if one of the communicating parties lacks a trusted certificate for the other party, a mutual trust relationship can be established through the other party's complete certificate chain.

[0126] Figure 3 shows the system architecture of a mutual trust alliance according to some embodiments of this specification. Figure 4 shows a flowchart of a digital certificate generation method according to some embodiments of this specification. Figure 5 shows a schematic diagram of a certificate chain stored in a terminal device according to some embodiments of this specification. The following description is based on Figures 3 to 5.

[0127] As shown in Figure 4, in some embodiments, the digital certificate generation method exemplified in this specification includes:

[0128] S410. Determine the root certificate for each member in the mutual trust alliance.

[0129] Referring to Figure 3, in the embodiments described in this specification, each member party in the mutual trust alliance is a root CA authority. A root certificate refers to the highest-trusted certificate corresponding to each member party. The root certificate serves as the top of the three-layer certificate chain in this specification and is also the starting point of the trust chain. In the example in Figure 3, there are n member parties, and each member party generates one root certificate, resulting in a total of n root certificates.

[0130] S420. Each member party digitally signs the other members party's documents to obtain mutual signatures between any two members party.

[0131] In the implementation method described in this specification, each of the n member parties needs to perform certificate mutual signing with the other (n-1) member parties, so that any two member parties among the n member parties can obtain a total of n*(n-1) digital certificates by mutually issuing certificates to each other.

[0132] Taking mutual signing between member 1 and member 2 as an example, member 1 uses its private key to digitally sign member 2's public key, obtaining digital certificate x. Digital certificate x represents the digital certificate of member 2 issued by member 1. Similarly, member 2 uses its private key to digitally sign member 1's public key, obtaining digital certificate y. Digital certificate y represents the digital certificate of member 1 issued by member 2.

[0133] In other words, the mutual signature certificate between member 1 and member 2 includes: member 2's digital certificate x issued by member 1, and member 1's digital certificate y issued by member 2. The same applies to any other two members in the mutual trust alliance, so that n members can obtain n*(n-1) digital certificates through mutual signature.

[0134] It is understandable that mutual signature certificates between members indicate that members trust other members. For example, a digital certificate x issued by member 1 to member 2 indicates that member 1 recognizes member 2 as a trusted member in the mutual trust alliance.

[0135] S430. Each member party obtains a device certificate by digitally signing the terminal devices belonging to that member party.

[0136] As mentioned above, mutual signature certificates between members only prove mutual trust and recognition between alliance members. For device-level communication, device authentication is also essential, that is, verifying whether a device is the one it claims to belong to a certain alliance member.

[0137] Therefore, each member needs to digitally sign its subordinate terminal devices to obtain a device certificate. For example, taking member 1's device a1 as an example, member 1 uses its private key to digitally sign device a1's public key to obtain device a1's device certificate. This device certificate indicates that device a1 originates from member 1, thus proving the device's legitimacy. The same principle applies to the devices of other member parties; each member digitally signs its subordinate terminal devices to obtain a device certificate for each terminal device.

[0138] S440: Distribute and store the root certificate, mutual signature certificate, and device certificate of the subordinate terminal devices of the member party in the corresponding terminal devices.

[0139] In the embodiments described in this specification, the mutual verification of terminal device certificates includes a three-level certificate chain. The top-level certificate is the root certificate of the member party, which is the beginning of the trust chain. The second-level certificate is the mutual signature certificate between the member party and other member parties, which is used to verify the legitimacy of the member party's identity. The third-level certificate is the device certificate issued by the member party, which is used to verify the legitimacy of the device's identity.

[0140] Referring to Figure 3, taking device a1 of member party 1 as an example, the certificates stored in device a1 include: root certificate 1 of the member party to which device a1 belongs (i.e. member party 1), device certificate Crt-a1 of device a1, and mutual signature certificates between member party 1 and other member parties.

[0141] As shown in Figure 5, the mutual signature certificates between Member 1 and other Member 1 include digital certificates x issued by Member 1 to the other (n-1) Member 1 and digital certificates y issued by the other (n-1) Member 1, for a total of 2(n-1) digital certificates.

[0142] Therefore, when storing data, device a1 can partition and store the mutual signature certificates of member party 1 and each other member party. For example, in the example in Figure 5, device a1 can divide the trust zone of each member party. Taking the trust zone of member party 2 as an example, this trust zone is used to store the digital certificate x1 of member party 2 issued by member party 1 and the digital certificate y1 of member party 1 issued by member party 2. The other trust zones are similar.

[0143] In this embodiment, referring to the system architecture shown in Figure 3, each client device can receive and store the aforementioned certificate chain from the server. For example, when a new member joins the alliance, the members issue certificates through the aforementioned methods and steps. Then, each member distributes the updated certificate chain to its subordinate terminal devices via the server, allowing the terminal devices to update their historically stored certificate chains based on the most trusted certificate chain. The same procedure applies when a member leaves the alliance, and will not be elaborated upon here.

[0144] It is worth noting that when a new member joins the alliance, the mutual signing of certificates between the new member (g) and other members takes time. If the certificate on member g's terminal device is not updated in time, member g's terminal device may lack trust in other members. However, in the implementation method of this specification, through a three-level certificate verification method, even if one member lacks trust in another member, as long as one party's certificate chain is complete and the verification passes, mutual trust can still be correctly established.

[0145] Figure 6 shows a flowchart of a digital certificate verification method in some embodiments of this specification. The process and principle of the digital certificate verification method are explained below with reference to Figure 6.

[0146] In the example shown in Figure 6, the devices of the two parties verifying the signature are device P (first member) and device Q (second member). Device P belongs to the first member party, and device Q belongs to the second member party. Due to reasons such as untimely certificate updates for device Q, device Q lacks trust in the first member party; that is, device Q does not store mutual signature certificates with the first member party. However, device P stores trust in the second member party; specifically, device P stores the second digital certificate x1 issued by the first member party and the first digital certificate y1 issued by the second member party.

[0147] In addition, in the example diagram below, the thick solid line with arrows indicates the direction of data transmission, the dashed line with arrows indicates the source of data, and the thin solid line with arrows indicates the verification action. The certificate mutual verification process between the first device P and the second device Q will be explained below with reference to Figure 6.

[0148] For the data transmission direction from the first device P to the second device Q, the first device P sends the stored first device certificate Crt-P and the first digital certificate y1 to the second device Q.

[0149] It can be understood that the first digital certificate y1 represents a certificate issued by the second member party to the first member party. Therefore, the second device Q can verify the signature using the stored root certificate Crt-2 of the second member party. Specifically, the second device Q can use the public key of the second member party carried in the root certificate Crt-2 to verify the signature of the first digital certificate y1. If the verification is successful, it indicates that the first member party is a trusted consortium member of the second member party. Furthermore, by verifying the signature of the first digital certificate y1, the legitimacy of the first member party's public key can be verified. If the signature verification of the first digital certificate y1 is successful, it proves that the public key of the first member party it carries is trustworthy.

[0150] Then, the second device Q can use the public key of the first member party to continue signing and verifying the device certificate Crt-P of the first device P. It can be understood that the device certificate Crt-P of the first device P is issued by the first member party, therefore, it can be verified using the trusted public key of the first member party. If the verification passes, it indicates that the first device P is a device recognized by the first member party, thus forming a complete 3-level certificate chain verification: the root certificate of the top-level second member party is used to verify the second-level digital certificates between members, proving that the member party is a trusted member party; then, the public key of the trusted member party is used to verify the third-level device certificate, proving that the other device is a trusted device of that trusted member party.

[0151] Through the above process, the authentication of the first device P by the second device Q is completed, that is, the second device Q determines that the first device P is a trusted device.

[0152] For data transmission from the second device Q to the first device P, since the second device Q lacks trust in the first member, it can only transmit its own second device certificate Crt-Q to the first device P. The first device P stores a first digital certificate x1, which represents the digital certificate of the second member issued by the first member. The first digital certificate x1 is trusted by the first device and carries the public key of the second member, thus it can be used to verify the signature of the second device certificate Crt-Q. The first device Prt-1 can use the public key of the second member carried in the first digital certificate x1 to verify the second device certificate. If the verification is successful, it indicates that the second device Q is the device of the second member. Simultaneously, since the first device P itself stores a trust zone for the second member, if the device authentication of the second device Q is successful, the entire certificate chain of the second device Q can also be considered successfully verified.

[0153] As can be seen from the above, the method implemented in this specification can achieve mutual trust and recognition between member devices by using a three-level certificate chain. Moreover, the certificate chain provides dual authentication of the member and device identities, which greatly improves information security.

[0154] In addition, when the two devices verify each other's identities, even if one party lacks trust in the other, as long as one party's certificate chain is complete and verified, a trust relationship can still be correctly established, which plays a beneficial role in promoting the development of the Internet Alliance.

[0155] For example, in one exemplary scenario, the second device Q cannot communicate with the server because it has entered an uninhabited area, and its certificate cannot be updated in time, resulting in it not storing trust information about the first member. In this scenario, using the certificate verification method implemented in this specification, as long as the first device P stores trust information about the second member of the second device Q, the two devices can still correctly establish a trust relationship, thereby achieving a connection without network communication.

[0156] Furthermore, the implementation method described in this specification eliminates the need for a third-party trust center among alliance members; each member acts as a root CA, enjoying equal and symmetrical status and rights. Moreover, the decentralized alliance architecture eliminates the need for creating and maintaining additional third-party institutions, reducing costs and promoting the development of trusted alliances.

[0157] Furthermore, it is understandable that if both devices store trust information about each other's members, then mutual identity verification can be completed simply by both parties performing the same signature verification process. For example, referring to Figure 6, assuming that the second device Q also stores trust information about the first member, then the second device Q can send its second device certificate Crt-Q and first digital certificate x1 to the first device P. The first device P can then perform the same signature verification operation as the second device Q described above, which will not be elaborated further in this specification.

[0158] In some embodiments, this specification provides a communication connection method for establishing a network-free communication connection between devices of the aforementioned alliance members, wherein the two ends of the communication connection are devices of different members, that is, to realize a cross-brand network-free communication connection.

[0159] Figure 7 shows an interactive flowchart of a communication connection method according to some embodiments of this specification. In the example in Figure 7, the two communicating parties are a first device P and a second device Q. The first device P belongs to the first member of the mutual trust alliance, and the second device Q belongs to the second member of the mutual trust alliance.

[0160] As shown in Figure 7, in some embodiments, the communication connection method exemplified in this specification includes:

[0161] S710, The first device sends a connection request to the second device.

[0162] First device P sends a connection request for offline communication to second device Q.

[0163] S720, the second device responds to the connection request.

[0164] After receiving a connection request from the first device P, the second device Q indicates that the first device P requests to establish a communication connection with the second device Q. The second device Q can return a response to the first device P, indicating that the connection can be established.

[0165] It is worth noting that in some embodiments, the second device Q can perform an initial coarse screening of the identity of the first device P. Therefore, the connection request sent by the first device can carry identification information that can identify itself, such as a digital digest generated based on the identity. Then, the second device Q can identify the identification information carried in the connection request. Only if the identification is successful can the subsequent process proceed; if the identification fails, the connection is terminated. However, it is understood that this process is optional and not mandatory, and the embodiments described below will explain this in detail.

[0166] S730, the first device and the second device perform certificate mutual verification.

[0167] The process of mutual verification of certificates between the first device P and the second device Q can be implemented by referring to the process of any of the aforementioned implementation methods.

[0168] S740. If the certificate mutual verification is successful, establish a communication connection.

[0169] As can be seen from the foregoing, if the certificates of the first device P and the second device Q are successfully verified, it means that both the first device P and the second device Q are trusted members of the alliance, thus enabling the establishment of a wireless communication connection and subsequent communication.

[0170] It is worth noting that in some implementations, after certificate verification is successful, the device identity can be further verified. Device identity refers to whether the user to whom the device belongs is an authorized user. It is understood that member parties may generate many devices, but individual users do not wish to establish communication connections with unknown or unfamiliar users. Therefore, further verification and identification of device identity is possible, allowing connection establishment only if device identity verification is successful. However, this process is optional, not mandatory, and the implementation methods described below will explain this in detail.

[0171] As can be seen from the above, the embodiments in this specification can realize cross-brand wireless communication between alliance member devices, and improve the security of communication connections through certificate mutual signing and verification.

[0172] As mentioned earlier, in some scenarios, individual users may not want unknown or unfamiliar devices to connect to their devices. Therefore, during the connection process between the first device and the second device, identity authentication of the first device can be added to further improve information security.

[0173] For example, in some implementations, the terminal device can provide a whitelist for the user. Devices on the whitelist are trusted devices and can establish offline communication connections, while devices not on the whitelist cannot establish offline communication connections.

[0174] The whitelist is used to record the identity codes of trusted devices. The identity code can be any character that can uniquely identify a user, such as a phone number or IEMI (International Mobile Equipment Identity). Users can set the identity codes in the whitelist themselves, such as adding, modifying, or deleting them.

[0175] In one example, the whitelist uses the address book as an example, and the identity code uses the phone number as an example. That is, for a certain terminal device, the other party is only allowed to connect if the other party is a user's device recorded in its address book. Conversely, if the other party is not a user's device recorded in its address book, it means that the other party is an unfamiliar device, and the other party is not allowed to connect.

[0176] Figure 8 illustrates the process of a first device P and a second device Q sending and verifying a connection request in some embodiments of this specification, which will be described below with reference to Figure 8.

[0177] As shown in Figure 8, in some embodiments, the communication connection method exemplified in this specification includes:

[0178] S810, the first device obtains its own first identity code and first random string.

[0179] S820, The first device performs an obfuscation operation based on the first identification code and the first random string to obtain the first digest.

[0180] In some embodiments of this specification, the connection request generated by the first device P includes a first digest and a first random string.

[0181] In data encryption, a digital digest is a short, fixed-length data representation generated by processing original data using a specific algorithm. A digital digest uniquely identifies the content of the original data; when the original data changes, the digital digest also changes accordingly; moreover, the digital digest is irreversible, meaning the original data cannot be derived from it.

[0182] As mentioned above, the first identification code of the first device P refers to the unique identification code that identifies the first device P. For example, in one example, the mobile phone number of the first device P is used as the first identification code.

[0183] The first random string, also called the salt, is a string of characters randomly generated during hashing. It changes dynamically, meaning the first random string is different for each connection request. The purpose of adding a first random string is to improve information security. For example, if the first digest is generated solely based on the phone number of device P, without a first random string, an attacker could potentially crack device P's phone number by iterating through all available phone numbers. By introducing a dynamically changing first random string, the difficulty of cracking is increased, thus improving data security.

[0184] In this embodiment of the specification, after obtaining a first identification code and a first random string, the first device P assembles the two to obtain original data, and then performs a confusion operation on the original data to generate a first digest. The confusion operation is the process of converting the original data into a fixed-length digital digest using a hash function. The confusion algorithm can be, for example, a hash function.

[0185] S830, the first device sends a first digest and a first random string to the second device.

[0186] The first device P sends the first digest and the first random string to the second device Q.

[0187] S840: The second device obtains the identity identifiers in the whitelist and generates a second digest by performing an obfuscation operation on each identity identifier and the first random string.

[0188] S850: The second device uses the second digest to match the first digest, and if the match is successful, initiates certificate verification with the first device.

[0189] After receiving the first digest and the first random string, the second device Q, as mentioned above, maintains a whitelist. Only devices recorded in the whitelist can establish a communication connection. Therefore, the second device Q can iterate through each identity in the whitelist and perform the same obfuscation operation as the first device P on each identity to obtain the second digest corresponding to each identity.

[0190] For example, in one scenario, the whitelist might be the address book of a second device Q, where the identifiers are phone numbers. Taking one phone number, W, as an example, the second device Q can assemble the original data based on the phone number W and a received first random string. Then, it performs the same obfuscation operation as the first device P on the original data to obtain the second digest. By iterating through the entire whitelist, the second digest corresponding to each phone number in the whitelist can be obtained.

[0191] Based on the foregoing explanation of the obfuscation algorithm, it can be understood that when the original data is the same, the generated digests will also be the same. Therefore, if the phone number of the first device P exists in the address book of the second device Q, then at least one second digest in the whitelist will match the first digest. Conversely, if the phone number of the first device P is not in the address book of the second device Q, then no second digest will match the first digest.

[0192] Based on this, the second device Q can use each second digest to match the first digest. If the match is successful, it proves that the first device P may be a device in the whitelist, and then the subsequent certificate verification process can be executed.

[0193] It is worth noting that the mapping relationship based on the hash algorithm can be understood. There is a very small probability that different original data will be mapped to the same hash value during hash mapping. Therefore, the identity verification here is not absolutely accurate. As a coarse screening of identity before certificate mutual verification, there is no need to require high-precision identity verification results. It is only necessary to be able to filter out most of the data.

[0194] Therefore, considering that some users have a large number of phone numbers stored in their address books, such as thousands, traversing the entire address book by a second device would be very inefficient. Thus, in some implementations, the computational load on the second device can be reduced and authentication efficiency improved by decreasing the amount of first digest data and / or increasing the index.

[0195] For example, in one scenario, after generating the first digest, device P can choose not to send the complete first digest, but only a portion of it, such as the last two or four characters. This significantly reduces the amount of data transmitted and improves data communication efficiency. For instance, in BLE (Bluetooth Low Energy) communication, sending only a portion of the first digest improves Bluetooth transmission efficiency. For device Q, upon receiving a portion of the first digest, it iterates through its entire address book to obtain the second digest. It only needs to compare the characters at the same positions in the second digest, without needing to compare the entire digest, greatly improving data matching efficiency and shortening authentication time. Once a second digest matches successfully, the subsequent certificate verification process can begin.

[0196] For example, in another instance, when the first device P sends the first digest and the first random string, it can simultaneously carry a portion of the plaintext of the phone number, such as the last two or four digits. Since only a portion of the characters are carried, the risk of phone number leakage is very low. For the second device Q, when it receives the connection request from the first device P, it matches the portion of the phone number carried (such as the last two digits) with the corresponding characters in the phone numbers recorded in its address book. This allows it to quickly filter out matching candidate identities from the address book. Then, it only needs to perform the aforementioned authentication process on these candidate identities, greatly reducing the amount of data and improving computational efficiency.

[0197] Of course, those skilled in the art will understand that the two implementation methods for improving computational efficiency described above can be implemented in one or in combination, and this specification does not limit this.

[0198] In some implementations, the method for mutual verification of certificates between the first device P and the second device Q can be referred to the certificate verification process shown in Figures 3 to 6 above. The specific method will not be described in detail in this specification.

[0199] In these implementations, a three-tier certificate chain enables mutual trust and recognition between member devices. Furthermore, the certificate chain provides dual authentication of both member and device identities, significantly enhancing information security. During device identity verification, even if one party lacks trust in the other, a trust relationship can still be correctly established as long as one party's certificate chain is complete and verified. This positively contributes to the development of interconnection alliances. Moreover, no third-party trust center is required; each member is a root CA with equal and symmetrical status and rights. This decentralized alliance architecture eliminates the need for creating and maintaining third-party institutions, reducing costs and promoting the development of trusted alliances.

[0200] In other implementations, the certificate verification process between the first device P and the second device Q can also adopt, for example, the system architecture shown in Figure 2. That is, the mutual trust alliance issues trust certificates through a trusted third-party CA (i.e., CA center), which is the trust center. The CA center issues digital certificates to each member party in the alliance, and the terminal device stores the root certificate of the CA center and the digital certificate of the member party to which the terminal device belongs, issued by the CA center.

[0201] Figure 9 illustrates the certificate verification process between the first device P and the second device Q under the alliance architecture shown in Figure 2. The following explanation is based on Figure 9.

[0202] Referring to Figure 9, both the first device P and the second device Q store the CA center root certificate. The CA center root certificate is the highest-trust certificate generated by the trust center (i.e., the CA center). The CA center root certificate is securely distributed or pre-installed into each member device. The first device certificate Crt-P is the device certificate of the first device P issued by the first member party, and the second device certificate Crt-Q is the device certificate of the second device Q issued by the second member party. The third digital certificate z1 is the digital certificate of the first member party issued by the CA center, and the fourth digital certificate z2 is the digital certificate of the second member party issued by the CA center.

[0203] When the first device P and the second device Q verify each other's certificates, the first device P can send its stored first device certificate Crt-P and third digital certificate z1 to the second device Q. The second device Q can use the public key of the CA center carried in its stored CA center root certificate to verify the signature of the third digital certificate z1. If the verification is successful, it indicates that the first member is a trusted member of the consortium. Furthermore, by verifying the signature of the third digital certificate z1, the legitimacy of the first member's public key can be verified, and if the signature verification of the third digital certificate z1 is successful, it proves that the public key of the first member carried by it is trustworthy. Then, the second device Q can use the public key of the first member to continue to verify the signature of the first device P's device certificate Crt-P. It can be understood that the first device P's device certificate Crt-P is issued by the first member, so it can be verified using the trusted public key of the first member. If the verification is successful, it indicates that the first device P is a device recognized by the first member, thus forming a complete certificate chain verification.

[0204] Similarly, the second device Q can send its stored second device certificate Crt-Q and fourth digital certificate z2 to the first device P. The first device P can use the public key of the CA center carried in its stored CA center root certificate to verify the signature of the fourth digital certificate z2. If the verification is successful, it indicates that the second member is a trusted member of the consortium. Furthermore, by verifying the signature of the fourth digital certificate z2, the legitimacy of the second member's public key can be verified, and if the signature verification of the fourth digital certificate z2 is successful, it proves that the public key of the second member it carries is trustworthy. Then, the first device P can use the public key of the second member to continue verifying the signature of the second device Q's second device certificate Crt-Q. It can be understood that the device certificate Crt-Q of the second device Q is issued by the second member, therefore, it can be verified using the trusted public key of the second member. If the verification is successful, it indicates that the second device Q is a device recognized by the first member, thus forming a complete certificate chain verification.

[0205] If both certificate chains are verified successfully, the certificates of the first device P and the second device Q are confirmed to be mutually verified. If either one fails to verify, the verification is confirmed to have failed and the connection establishment is interrupted.

[0206] As can be seen from the aforementioned embodiment in Figure 8, the identity verification before certificate mutual verification is a coarse screening of device identity and cannot guarantee that the identity verification is completely accurate. Therefore, after the certificate mutual verification is successful, the first device P and the second device Q can send each other identity identification codes for precise identity verification, which will be explained below with reference to Figure 10.

[0207] As shown in Figure 10, some embodiments of the communication connection method described in this specification include:

[0208] S101. If the certificates of the first device and the second device are mutually verified, the first device sends a first identification code to the second device, and the second device sends a second identification code to the first device.

[0209] As mentioned above, the identification code is a string used to uniquely identify the device. For example, in one example, the first identification code is the mobile phone number of the first device P, and the second identification code is the mobile phone number of the second device Q.

[0210] In the embodiments described in this specification, the first device P can send its mobile phone number to the second device Q, and at the same time, the second device Q sends its mobile phone number to the first device P, thus completing the exchange and transmission of identity codes.

[0211] It is worth noting that, considering the security of exchanging mobile phone numbers between the first device P and the second device Q, the channel security can be checked before exchanging identity codes. If the transmission channel is determined to be secure, the identity codes can be exchanged according to the above process. If a risk is detected in the channel, the key can be renegotiated based on ECIES (Elliptic Curve Integrate Encrypt Scheme). Based on the established trust relationship, the renegotiated key is used to encrypt subsequent communication. Those skilled in the art will understand and fully implement this, and it will not be elaborated further in this specification.

[0212] S102, the first device verifies the second identity code sent by the second device, and the second device verifies the first identity code sent by the first device.

[0213] S103. Data communication is performed after both the first and second devices have been verified.

[0214] Once a device receives an identity code sent by the other party, it can verify the other party's identity based on the identity code.

[0215] For example, in one instance, during certificate verification, both devices send each other a digital digest and a salt for generating the digital digest. The digital digest is generated based on the device's own identity code. When verifying the identity code, a new digital digest can be generated by assembling the received identity code with the salt. This digital digest is then compared with the digital digest received during the certificate verification process. If they match, the identity verification is confirmed to be successful.

[0216] For example, in another instance, after receiving the identity code sent by the other device, the device can match the identity code with the identity codes in its own whitelist. If they match, the authentication is considered successful.

[0217] Of course, those skilled in the art will understand that there are many other ways for the first device P and the second device Q to authenticate each other, and they are not limited to the examples mentioned above. This specification cannot exhaustively list them all, so they will not be elaborated further.

[0218] In the embodiments described in this specification, if the device identities of both the first device P and the second device Q are verified, a network-free communication connection can be established between the first device P and the second device Q, and subsequent communication processes can be executed. This specification will not elaborate further.

[0219] In some implementations, the offline communication connection between the first device P and the second device Q includes, but is not limited to, Bluetooth communication connection, WiFi communication connection, LoRa communication connection, UWB (Ultra Wide Band) communication connection, etc.

[0220] As can be seen from the above, in the embodiments of this specification, the three-layer verification of device identity screening, certificate mutual verification, and identity verification is used when establishing a communication connection, which not only improves the security of the communication connection, but also improves the verification efficiency of the communication connection and saves resources.

[0221] In some embodiments, this specification provides a digital certificate verification device applied to a first device, which is a first member of a mutual trust alliance. Referring to Figure 11, the device includes:

[0222] The first sending module is configured to send the first device certificate of the first device and the first digital certificate of the first member party issued by the second member party to the second device when the first device stores the mutual signature certificate of the first member party and the second member party, so that the second device can verify the first device certificate and the first digital certificate based on the stored root certificate.

[0223] The first verification module is configured to receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party; in response to the successful verification of both the first device and the second device, the first device and the second device are determined to be mutually trusted devices; wherein, the second device belongs to the second member party in the mutual trust alliance, and the mutual signature certificate between the first member party and the second member party includes the first digital certificate and the second digital certificate.

[0224] In some implementations, the first signature verification module is configured as follows:

[0225] Receive the second device certificate sent by the second device, and verify the second digital certificate using the stored root certificate to obtain the public key of the second member party;

[0226] The second member's public key is used to verify the signature of the second device certificate.

[0227] In some embodiments, this specification provides a digital certificate verification device applied to a second device, which is a first member in a mutual trust alliance. Referring to Figure 12, the device includes:

[0228] The first receiving module is configured to receive the first device certificate of the first device sent by the first device, and the first digital certificate of the first member party issued by the second member party, wherein the first device belongs to the first member party in the mutual trust alliance;

[0229] The second signature verification module is configured to verify the signatures of the first device certificate and the first digital certificate based on the stored root certificate.

[0230] The second sending module is configured to send the second device certificate of the second device to the first device, so that the first device verifies the second device certificate based on the stored second digital certificate, the second digital certificate representing the certificate of the second member issued by the first member; in response to both the first device and the second device passing the verification, the first device and the second device are determined to be mutually trusted devices.

[0231] In some implementations, the second signature verification module is configured as follows:

[0232] The first digital certificate is verified using the stored root certificate to obtain the public key of the first member party;

[0233] The first device certificate is verified using the public key of the first member party.

[0234] In some embodiments, this specification provides a communication connection device applied to a first device, which is a first member in a mutual trust alliance. Referring to Figure 13, the device includes:

[0235] The request sending module is configured to send a connection request to the second device, and, if the second device responds to the connection request, perform certificate verification with the second device, wherein the second device is a second member of the mutual trust alliance;

[0236] The communication establishment module is configured to establish a communication connection with the second device after the certificate mutual verification with the second device is successful.

[0237] In some implementations, the request sending module is configured to:

[0238] Obtain the first identification code and the first random string of the first device, and perform an obfuscation operation based on the first identification code and the first random string to obtain the first digest;

[0239] The connection request is sent to the second device, the connection request including at least a portion of the characters of the first digest and the first random string.

[0240] In some implementations, the connection request may also include a portion of the characters of the first identity code.

[0241] In some implementations, the request sending module is configured to:

[0242] If the first device stores a mutual signature certificate between the first member party and the second member party, the first device certificate of the first device and the first digital certificate of the first member party issued by the second member party are sent to the second device so that the second device can verify the first device certificate and the first digital certificate based on the stored root certificate.

[0243] Receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party;

[0244] In response to the successful verification of both the first device and the second device, the mutual verification of certificates is confirmed to be successful, wherein the mutual verification certificate between the first member party and the second member party includes the first digital certificate and the second digital certificate.

[0245] In some implementations, the request sending module is configured to:

[0246] Receive the second device certificate sent by the second device, and verify the second digital certificate using the stored root certificate to obtain the public key of the second member party;

[0247] The second member's public key is used to verify the signature of the second device certificate.

[0248] In some implementations, the request sending module is configured to:

[0249] Send a third digital certificate of the first member party issued by the trust center of the mutual trust alliance to the second device, so that the second device can verify the third digital certificate based on the root certificate of the trust center stored therein;

[0250] Receive the fourth digital certificate of the second member party issued by the trust center sent by the second device, and verify the signature of the fourth digital certificate based on the root certificate of the trust center stored in the system;

[0251] In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

[0252] In some implementations, the communication establishment module is configured to:

[0253] If the certificate verification with the second device is successful, the first identity code is sent to the second device so that the second device can verify the device identity of the first device based on the first identity code;

[0254] Receive the second identity code sent by the second device, and verify the device identity of the second device based on the second identity code;

[0255] If the device identities of both the first device and the second device are verified, a communication connection is established with the second device.

[0256] In some embodiments, this specification provides a communication connection device applied to a second device, which is a second member in a mutual trust alliance. Referring to Figure 14, the device includes:

[0257] The request receiving module is configured to receive a connection request sent by a first device and initiate certificate verification with the first device based on the connection request. The first device is the first member of the mutual trust alliance.

[0258] The communication establishment module is configured to establish a communication connection with the first device if the certificate verification with the first device is successful.

[0259] In some implementations, the connection request includes at least a portion of a first digest and a first random string, the first digest being generated by obfuscating the first identification code of the first device and the first random string; the request receiving module is configured to:

[0260] Obtain the identity identifiers in the whitelist, and generate a second digest by performing an obfuscation operation between each identity identifier in the whitelist and the first random string;

[0261] The second digest is matched with the first digest, or a portion of the characters in the second digest is matched with the corresponding characters in the first digest. If the match is successful, a certificate verification with the first device is initiated.

[0262] In some implementations, the connection request further includes partial characters of the first identification code; the request receiving module is configured to:

[0263] Obtain the identity identifiers in the whitelist, and use a portion of the characters of the first identity identifier code to filter each identity identifier in the whitelist to obtain candidate identity identifiers corresponding to a portion of the characters of the first identity identifier code;

[0264] A second digest is generated by obfuscating each candidate identity in the whitelist with the first random string.

[0265] In some implementations, the request receiving module is configured to:

[0266] Receive the first device certificate of the first device sent by the first device, and the first digital certificate of the first member party issued by the second member party;

[0267] The root certificate of the storage is used to verify the signature of the first device certificate and the first digital certificate.

[0268] Send the second device certificate of the second device to the first device so that the first device can verify the second device certificate based on the stored second digital certificate, the second digital certificate representing the certificate of the second member party issued by the first member party;

[0269] In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

[0270] In some implementations, the request receiving module is configured to:

[0271] The first digital certificate is verified using the stored root certificate to obtain the public key of the first member party;

[0272] The first device certificate is verified using the public key of the first member party.

[0273] In some implementations, the request receiving module is configured to:

[0274] Receive a third digital certificate from a first member party issued by the trust center of the mutual trust alliance, sent by the first device, and verify the third digital certificate based on the root certificate of the trust center stored in the device.

[0275] Send a fourth digital certificate of the second member party issued by the trust center to the first device, so that the first device can verify the fourth digital certificate based on the root certificate of the trust center stored therein;

[0276] In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

[0277] In some implementations, the communication establishment module is configured to:

[0278] If the certificate verification with the first device is successful, a second identity code is sent to the first device so that the first device can verify the device identity of the second device based on the second identity code;

[0279] Receive the first identification code sent by the first device, and verify the device identity of the first device based on the first identification code;

[0280] If the device identities of both the first device and the second device are verified, a communication connection is established with the second device.

[0281] In some implementations, the communication connection between the first device and the second device includes: Bluetooth communication connection, WiFi communication connection, LoRa communication connection, or UWB communication connection.

[0282] In some embodiments, this specification provides a communication system including multiple member parties, said communication system being used to implement the digital certificate generation method described in any of the above embodiments. The communication system in the embodiments of this specification can refer to the trusted alliance system shown in Figure 2 or Figure 3 above, and will not be described again therein.

[0283] In some embodiments, this specification provides an electronic device, which may be a device from the aforementioned Trusted Alliance, comprising:

[0284] processor;

[0285] The memory stores computer instructions that cause the processor to perform the method described in any of the above embodiments.

[0286] In some embodiments, this specification provides a storage medium storing computer instructions for implementing the methods described in any of the above embodiments.

[0287] In some embodiments, this specification provides a computer program product for implementing the methods described in any of the above embodiments.

[0288] Figure 15 shows a structural block diagram of an electronic device according to some embodiments of the present disclosure. The electronic devices according to some embodiments of the present disclosure will be described below with reference to Figure 15.

[0289] Referring to FIG15, the electronic device 1800 may include one or more of the following components: processing component 1802, memory 1804, power supply component 1806, multimedia component 1808, audio component 1810, input / output (I / O) interface 1812, sensor component 1816, and communication component 1818.

[0290] Processing component 1802 typically controls the overall operation of electronic device 1800, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 1802 may include one or more processors 1820 to execute instructions. Furthermore, processing component 1802 may include one or more modules to facilitate interaction between processing component 1802 and other components. For example, processing component 1802 may include a multimedia module to facilitate interaction between multimedia component 1808 and processing component 1802. As another example, processing component 1802 may read executable instructions from memory to implement relevant functions of the electronic device.

[0291] Memory 1804 is configured to store various types of data to support the operation of electronic device 1800. Examples of this data include instructions for any application or method operating on electronic device 1800, contact data, phonebook data, messages, pictures, videos, etc. Memory 1804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0292] Power supply component 1806 provides power to various components of electronic device 1800. Power supply component 1806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 1800.

[0293] The multimedia component 1808 includes a display screen that provides an output interface between the electronic device 1800 and the user. In some embodiments, the multimedia component 1808 includes a front-facing camera and / or a rear-facing camera. When the electronic device 1800 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera can receive external multimedia data. Each front-facing camera and rear-facing camera can be a fixed optical lens system or have focal length and optical zoom capabilities.

[0294] Audio component 1810 is configured to output and / or input audio signals. For example, audio component 1810 includes a microphone (MIC) configured to receive external audio signals when electronic device 1800 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 1804 or transmitted via communication component 1818. In some embodiments, audio component 1810 also includes a speaker for outputting audio signals.

[0295] I / O interface 1812 provides an interface between processing component 1802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0296] Sensor assembly 1816 includes one or more sensors for providing state assessments of various aspects of electronic device 1800. For example, sensor assembly 1816 may detect the on / off state of electronic device 1800, the relative positioning of components such as the display and keypad of electronic device 1800, changes in position of electronic device 1800 or a component of electronic device 1800, the presence or absence of user contact with electronic device 1800, the orientation or acceleration / deceleration of electronic device 1800, and temperature changes of electronic device 1800. Sensor assembly 1816 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1816 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1816 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0297] Communication component 1818 is configured to facilitate wired or wireless communication between electronic device 1800 and other devices. Electronic device 1800 can access wireless networks based on communication standards, such as Wi-Fi, 2G, 3G, 4G, 5G, or 6G, or combinations thereof. In one exemplary embodiment, communication component 1818 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 1818 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0298] In an exemplary embodiment, the electronic device 1800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components.

[0299] Obviously, the above embodiments are merely examples for clear illustration and are not intended to limit the embodiments. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all embodiments here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this disclosure.

Claims

1. A method for generating a digital certificate, characterized in that, include: The root certificate of each member in the mutual trust alliance is determined, and each member digitally signs the other members to obtain a mutual signature certificate between any two members. Each member party digitally signs the terminal devices belonging to that member party to obtain a device certificate, and distributes and stores the root certificate, mutual signature certificate, and device certificates of its subordinate terminal devices to the corresponding terminal devices.

2. The method according to claim 1, characterized in that, The root certificate, mutual signature certificate, and device certificates of the subordinate terminal devices of the member party are distributed and stored in the corresponding terminal devices, including: The member's server distributes and stores the member's root certificate, mutual signature certificate, and device certificates of its subordinate terminal devices in the corresponding terminal devices.

3. A digital certificate verification method, characterized in that, Applied to a first device, which is a first member of a mutual trust alliance, the method includes: If the first device stores a mutual signature certificate between the first member party and the second member party, the first device certificate of the first device and the first digital certificate of the first member party issued by the second member party are sent to the second device so that the second device can verify the first device certificate and the first digital certificate based on the stored root certificate. Receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party; In response to the successful verification of both the first device and the second device, it is determined that the first device and the second device are mutually trusted devices; wherein, the second device belongs to the second member party in the mutual trust alliance, and the mutual signature certificate between the first member party and the second member party includes the first digital certificate and the second digital certificate.

4. The method according to claim 3, characterized in that, Receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party, including: Receive the second device certificate sent by the second device, and verify the second digital certificate using the stored root certificate to determine the public key of the second member party; The second member's public key is used to verify the signature of the second device certificate.

5. A digital certificate verification method, characterized in that, Applied to a second device, which is a first member of a mutual trust alliance, the method includes: The device receives the first device certificate sent by the first device and the first digital certificate of the first member party issued by the second member party, wherein the first device belongs to the first member party in the mutual trust alliance; The root certificate of the storage is used to verify the signature of the first device certificate and the first digital certificate. Send the second device certificate of the second device to the first device so that the first device can verify the second device certificate based on the stored second digital certificate, the second digital certificate representing the certificate of the second member party issued by the first member party; In response to the successful verification of both the first device and the second device, it is determined that the first device and the second device are mutually trusted devices.

6. The method according to claim 5, characterized in that, Verification of the first device certificate and the first digital certificate based on the stored root certificate includes: The first digital certificate is verified using the stored root certificate to determine the public key of the first member party; The first device certificate is verified using the public key of the first member party.

7. A communication connection method, characterized in that, Applied to a first device, which is a first member of a mutual trust alliance, the method includes: Send a connection request to the second device, and if the second device responds to the connection request, perform certificate verification with the second device, where the second device is a second member of the mutual trust alliance; If the certificate verification with the second device is successful, a communication connection is established with the second device.

8. The method according to claim 7, characterized in that, Send a connection request to the second device, including: Obtain the first identification code and the first random string of the first device, and perform an obfuscation operation based on the first identification code and the first random string to obtain the first digest; The connection request is sent to the second device, the connection request including at least a portion of the characters of the first digest and the first random string.

9. The method according to claim 8, characterized in that, The connection request also includes a portion of the characters from the first identity code.

10. The method according to claim 7, characterized in that, The process of verifying certificates with the second device includes: If the first device stores a mutual signature certificate between the first member party and the second member party, the first device certificate of the first device and the first digital certificate of the first member party issued by the second member party are sent to the second device so that the second device can verify the first device certificate and the first digital certificate based on the stored root certificate. Receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party; In response to the successful verification of both the first device and the second device, the mutual verification of certificates is confirmed to be successful, wherein the mutual verification certificate between the first member party and the second member party includes the first digital certificate and the second digital certificate.

11. The method according to claim 10, characterized in that, Receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party, including: Receive the second device certificate sent by the second device, and verify the second digital certificate using the stored root certificate to determine the public key of the second member party; The second member's public key is used to verify the signature of the second device certificate.

12. The method according to claim 7, characterized in that, The process of verifying certificates with the second device includes: Send a third digital certificate of the first member party issued by the trust center of the mutual trust alliance to the second device, so that the second device can verify the third digital certificate based on the root certificate of the trust center stored therein; Receive the fourth digital certificate of the second member party issued by the trust center sent by the second device, and verify the signature of the fourth digital certificate based on the root certificate of the trust center stored in the system; In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

13. The method according to claim 7, characterized in that, If the certificate verification with the second device is successful, a communication connection is established with the second device, including: If the certificate verification with the second device is successful, the first identity code is sent to the second device so that the second device can verify the device identity of the first device based on the first identity code; Receive the second identity code sent by the second device, and verify the device identity of the second device based on the second identity code; If the device identities of both the first device and the second device are verified, a communication connection is established with the second device.

14. A communication connection method, characterized in that, Applied to a second device, which is a second member of a mutual trust alliance, the method includes: The system receives a connection request from a first device and initiates certificate verification with the first device based on the connection request. The first device is the first member of the mutual trust alliance. If the certificate verification with the first device is successful, a communication connection is established with the first device.

15. The method according to claim 14, characterized in that, The connection request includes at least some characters of a first digest and a first random string, wherein the first digest is generated by obfuscating the first identification code of the first device and the first random string; Initiating certificate verification with the first device based on the connection request includes: Obtain the identity identifiers in the whitelist, and generate a second digest by performing an obfuscation operation between each identity identifier in the whitelist and the first random string; The second digest is matched with the first digest, or a portion of the characters in the second digest is matched with the corresponding characters in the first digest. If the match is successful, a certificate verification with the first device is initiated.

16. The method according to claim 15, characterized in that, The connection request also includes a portion of the first identity code; obtaining identity identifiers from the whitelist, and generating a second digest by obfuscating each identity identifier in the whitelist with the first random string, including: Obtain the identity identifiers in the whitelist, and use a portion of the characters of the first identity identifier code to filter each identity identifier in the whitelist to obtain candidate identity identifiers corresponding to a portion of the characters of the first identity identifier code; A second digest is generated by obfuscating each candidate identity in the whitelist with the first random string.

17. The method according to claim 14, characterized in that, The process of verifying certificates with the first device includes: Receive the first device certificate of the first device sent by the first device, and the first digital certificate of the first member party issued by the second member party; The root certificate of the storage is used to verify the signature of the first device certificate and the first digital certificate. Send the second device certificate of the second device to the first device so that the first device can verify the second device certificate based on the stored second digital certificate, the second digital certificate representing the certificate of the second member party issued by the first member party; In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

18. The method according to claim 17, characterized in that, Verification of the first device certificate and the first digital certificate based on the stored root certificate includes: The first digital certificate is verified using the stored root certificate to determine the public key of the first member party; The first device certificate is verified using the public key of the first member party.

19. The method according to claim 14, characterized in that, The process of verifying certificates with the first device includes: Receive a third digital certificate from a first member party issued by the trust center of the mutual trust alliance, sent by the first device, and verify the third digital certificate based on the root certificate of the trust center stored in the device. Send a fourth digital certificate of the second member party issued by the trust center to the first device, so that the first device can verify the fourth digital certificate based on the root certificate of the trust center stored therein; In response to the successful verification of both the first device and the second device, the certificate mutual verification is confirmed to be successful.

20. The method according to claim 14, characterized in that, If the certificate verification with the first device is successful, a communication connection is established with the first device, including: If the certificate verification with the first device is successful, a second identity code is sent to the first device so that the first device can verify the device identity of the second device based on the second identity code; Receive the first identification code sent by the first device, and verify the device identity of the first device based on the first identification code; If the device identities of both the first device and the second device are verified, a communication connection is established with the second device.

21. The method according to any one of claims 14 to 20, characterized in that, The communication connection between the first device and the second device includes: Bluetooth communication connection, WiFi communication connection, LoRa communication connection or UWB communication connection.

22. A digital certificate verification device, characterized in that, Applied to a first device, which is a first member of a mutual trust alliance, the device includes: The first sending module is configured to send the first device certificate of the first device and the first digital certificate of the first member party issued by the second member party to the second device when the first device stores the mutual signature certificate of the first member party and the second member party, so that the second device can verify the first device certificate and the first digital certificate based on the stored root certificate. The first verification module is configured to receive the second device certificate sent by the second device, and verify the second device certificate based on the second digital certificate of the second member party issued by the first member party; in response to the successful verification of both the first device and the second device, the first device and the second device are determined to be mutually trusted devices; wherein, the second device belongs to the second member party in the mutual trust alliance, and the mutual signature certificate between the first member party and the second member party includes the first digital certificate and the second digital certificate.

23. A digital certificate verification device, characterized in that, Applied to a second device, which is a first member of the mutual trust alliance, the device includes: The first receiving module is configured to receive the first device certificate of the first device sent by the first device, and the first digital certificate of the first member party issued by the second member party, wherein the first device belongs to the first member party in the mutual trust alliance; The second signature verification module is configured to verify the signatures of the first device certificate and the first digital certificate based on the stored root certificate. The second sending module is configured to send the second device certificate of the second device to the first device, so that the first device verifies the second device certificate based on the stored second digital certificate, the second digital certificate representing the certificate of the second member issued by the first member; in response to both the first device and the second device passing the verification, the first device and the second device are determined to be mutually trusted devices.

24. A communication connection device, characterized in that, Applied to a first device, which is a first member of a mutual trust alliance, the device includes: The request sending module is configured to send a connection request to the second device, and, if the second device responds to the connection request, perform certificate verification with the second device, wherein the second device is a second member of the mutual trust alliance; The communication establishment module is configured to establish a communication connection with the second device after the certificate mutual verification with the second device is successful.

25. A communication connection device, characterized in that, Applied to a second device, which is a second member of the mutual trust alliance, the device includes: The request receiving module is configured to receive a connection request sent by a first device and initiate certificate verification with the first device based on the connection request. The first device is the first member of the mutual trust alliance. The communication establishment module is configured to establish a communication connection with the first device if the certificate verification with the first device is successful.

26. A communication system, characterized in that, The communication system includes multiple member parties and is used to implement the digital certificate generation method as described in claim 1 or 2.

27. An electronic device, characterized in that, include: processor; A memory storing computer instructions for causing a processor to perform the method according to any one of claims 3 to 21.

28. A storage medium, characterized in that, The device stores computer instructions for implementing the method according to any one of claims 3 to 21.

29. A computer program product, characterized in that, The computer program product is used to implement the method according to any one of claims 3 to 21.

Images