Alliance website management system

Abstract

The alliance website management system proposed in the embodiment of the present application includes multiple root certificate authorities, which are associated with multiple website servers. Each root certificate authority stores an institution cross-signed certificate, which is generated based on a virtual root private key of a shared virtual root, and each network device stores a virtual root public key of the shared virtual root; an encryption device, which is at least used to store the virtual root private key; when the network device accesses and logs in to a target website, the network device is used to send an access request and a virtual root public key of the target website to the website server corresponding to the target website, and the website server is used to obtain the institution cross-signed certificate of the corresponding root certificate authority, and perform access qualification verification based on the institution cross-signed certificate, the access request and the virtual root public key, and send access permission information to the network device after the access qualification verification passes, thereby greatly improving the reliability and security of the network device in accessing the website.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to an alliance website management system. Background Art

[0002] Public key infrastructure is a system that uses public key cryptography to achieve secure communication and digital signatures. In a public key infrastructure, there are usually multiple layers of certificate authorities that are linked layer by layer, and these certificate authorities manage the certificate resources of all certificate authorities that are linked to them in the lower layers.

[0003] In the related art, when a network device accesses a website, it uses the relevant certificate resources for verification, and only after the verification is passed is the network device allowed to access the website, thereby ensuring the security of the website access. However, the upper-level certificate authority is usually set up in different regions and managed by the management object of the region. When using the original method to access the website, there are problems such as the different regions between the network device and the upper-level certificate authority, the network and human interference, etc., which make the certificate resources used by the network device invalid, thereby failing to perform normal website access. Summary of the invention

[0004] The embodiment of the present application provides an alliance website management system that can effectively improve the reliability of website access by network devices.

[0005] To achieve the above-mentioned purpose, a first aspect of an embodiment of the present application proposes an alliance website management system, the system comprising:

[0006] A plurality of root certificate authorities, each of which is associated with a plurality of website servers, each of which stores an institution cross-signed certificate, the institution cross-signed certificate is generated based on a virtual root private key of a common virtual root, and each network device stores a virtual root public key of the common virtual root;

[0007] An encryption device, the encryption device being used at least to store the virtual root private key;

[0008] When a network device logs in to access a target website, the network device is used to send an access request for the target website and the virtual root public key to a website server corresponding to the target website. The website server is used to obtain the corresponding cross-signed certificate of the root certificate authority, and perform an access qualification check based on the cross-signed certificate, the access request and the virtual root public key, and send access permission information to the network device after the access qualification check passes.

[0009] In some embodiments, the cross-signature certificate of the root certificate authority is generated by the encryption device, and when the encryption device generates the cross-signature certificate, the steps include:

[0010] Obtaining an initial root certificate of the root certificate authority;

[0011] The initial root certificate is signed using the virtual root private key, and the institution cross-signature certificate is obtained based on the signed initial root certificate.

[0012] In some embodiments, the system further comprises a plurality of regional management devices, the regional management devices being used to store at least a symmetric encryption subkey, and the encryption device, when executing the step of signing the initial root certificate using the virtual root private key, executes the steps comprising:

[0013] Acquire symmetric encryption subkeys inputted by a plurality of the regional management devices, and obtain a symmetric encryption key by combining all the symmetric encryption subkeys;

[0014] Encrypting the virtual root private key based on the symmetric encryption key to obtain an encrypted virtual root private key;

[0015] The initial root certificate is signed using the encrypted virtual root private key.

[0016] In some embodiments, the system is further provided with a key generation device, the symmetric encryption subkey is generated by the key generation device, and when the key generation device generates the symmetric encryption subkey, the steps performed include:

[0017] generating the symmetric encryption key;

[0018] The symmetric encryption key is divided to obtain a plurality of symmetric encryption subkeys, and each of the symmetric encryption subkeys is sent to the regional management device for storage.

[0019] In some embodiments, when the key generation device performs the step of splitting the symmetric encryption key to obtain the plurality of symmetric encryption subkeys, the steps include:

[0020] Get the number of devices managed by all the devices in the region;

[0021] The symmetric encryption key is evenly divided based on the number of devices to obtain the symmetric encryption sub-keys that are consistent with the number of devices.

[0022] In some embodiments, when the key generation device performs the steps of splitting the symmetric encryption key to obtain a plurality of symmetric encryption subkeys and sending each of the symmetric encryption subkeys to the regional management device for storage, the steps include:

[0023] Obtaining the resource proportion value and importance weight of the region to which each of the regional management devices belongs;

[0024] Based on the product of the resource proportion value and the importance weight, a partition weight value corresponding to each of the regional management devices is obtained, and all the partition weight values ​​are accumulated to obtain a total partition weight value;

[0025] Obtaining a division value for each of the area management devices based on a ratio of a division weight value corresponding to each of the area management devices to the total value of the division weights;

[0026] The symmetric encryption key is divided one by one using the division values ​​to obtain the symmetric encryption subkeys, and the symmetric encryption subkeys are sent to the corresponding regional management device for storage.

[0027] In some embodiments, when the key generation device performs the steps of dividing the symmetric encryption key by using the division values ​​one by one to obtain the symmetric encryption subkeys, and sending the symmetric encryption subkeys to the corresponding regional management device for storage, the steps include:

[0028] Randomly generate a sequence corresponding to the number of devices;

[0029] Based on the sequential sequence, the symmetric encryption key is divided one by one using the division values ​​to obtain the symmetric encryption sub-keys, and the symmetric encryption sub-keys are sent to the corresponding regional management device for storage.

[0030] In some embodiments, after generating the symmetric encryption subkey, the key generation device further performs the following steps:

[0031] Get the preset key update cycle time;

[0032] Based on the preset key update cycle time, periodically generate and update the symmetric encryption key;

[0033] The updated symmetric encryption key is divided into multiple updated symmetric encryption subkeys, and each of the updated symmetric encryption subkeys is sent to the regional management device for storage as a new symmetric encryption subkey.

[0034] In some embodiments, after generating the symmetric encryption subkey, the key generation device further performs the following steps:

[0035] When the number of regional management devices changes, an updated symmetric encryption key is generated;

[0036] The updated symmetric encryption key is divided into multiple updated symmetric encryption subkeys, and each of the updated symmetric encryption subkeys is sent to the regional management device for storage as a new symmetric encryption subkey.

[0037] In some embodiments, when the target website server performs the access qualification verification according to the institution cross-signed certificate, the access request and the virtual root public key, the steps include:

[0038] Based on the access request, obtain the institution cross-signature certificate from its own certificate chain;

[0039] The institution cross-signature certificate and the virtual root public key are subjected to certificate verification, and a qualification verification result of the access qualification verification is obtained according to the certificate verification result.

[0040] The alliance website management system proposed in the embodiment of the present application includes multiple root certificate authorities, which are associated with multiple website servers. Each root certificate authority stores an institution cross-signed certificate, which is generated based on a virtual root private key of a shared virtual root, and each network device stores a virtual root public key of the shared virtual root; an encryption device, which is at least used to store the virtual root private key; when the network device accesses and logs in to a target website, the network device is used to send an access request and a virtual root public key of the target website to the website server corresponding to the target website, and the website server is used to obtain the institution cross-signed certificate of the corresponding root certificate authority, and perform access qualification verification based on the institution cross-signed certificate, the access request and the virtual root public key, and send access permission information to the network device after the access qualification verification passes. The embodiment of the present application utilizes the cross-signed certificates of multiple root certificate authorities to jointly use a virtual root private key of a common virtual root that does not change, and the network device stores the virtual root public key of the common virtual root. Therefore, when the network device visits the target website, combined with the association between the virtual root public key and the virtual root private key, the website server can use the cross-signed certificate and the virtual root public key sent by the network device to perform qualification verification, thereby avoiding the possibility that the qualification verification of the network device is invalid due to certificate changes, thereby greatly improving the reliability of the network device in accessing the website; in addition, the virtual root private key is stored using an encryption device, which greatly improves the security of certificate management in the alliance website management system.

[0041] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 It is a structural diagram of a website public key infrastructure provided by an embodiment of the present application.

[0043] Figure 2 It is a structural diagram of an alliance website management system provided by another embodiment of the present application.

[0044] Figure 3 This is a flowchart of cross-signature of an encryption device generation mechanism provided by another embodiment of the present application.

[0045] Figure 4 It is a schematic diagram of an alliance website management system provided with a regional management device provided in another embodiment of the present application.

[0046] Figure 5 yes Figure 3 Flow chart of step 302 in FIG.

[0047] Figure 6 This is a flowchart of a key generation device generating a symmetric encryption sub-key provided by another embodiment of the present application.

[0048] Figure 7 yes Figure 6 Flowchart of step 602 in FIG.

[0049] Figure 8 yes Figure 6 Another flow chart of step 602 in FIG.

[0050] Fig. 9 yes Figure 8 Flowchart of step 804 in FIG.

[0051] Fig.10 This is a flowchart of a key generation device periodically updating a symmetric encryption subkey provided by another embodiment of the present application.

[0052] Fig.11 This is a flowchart of a key generation device providing another embodiment of the present application that updates a symmetric encryption subkey when a regional management device changes. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0054] It should be noted that although the functional modules are divided in the device schematic and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0056] First, some nouns involved in this application are analyzed:

[0057] Web Public Key Infrastructure (WebPKI) is a system that uses public key cryptography to achieve secure communication and digital signatures. It provides a trust model that allows users to be sure that the person they are communicating with is trustworthy and that the content of the communication will not be tampered with.

[0058] Reference Figure 1 , is a schematic diagram of the structure of a website public key infrastructure provided by an embodiment of the present application. Figure 1 As shown in , in the related art, it is usually composed of multiple certificate authorities associated layer by layer, including a root certificate authority at the top layer, multiple upper certificate authorities associated with the root certificate authority, and multiple lower certificate authorities associated with the upper certificate authority, and each lower certificate authority is associated with multiple website servers for performing resource certificate authorization on these website servers so that these website servers can manage multiple resource websites. It can be understood that the embodiment of the present application is illustrated with only three layers of certificate authorities, and in actual applications, there are usually more certificate authority architectures than three layers.

[0059] When any network device accesses a resource website managed by a website server, the network device usually uses the pre-acquired agency certificate of the certificate authority corresponding to the website server as login verification information. Then, when the website server receives the access request and agency certificate of the network device, it will perform verification based on the agency certificate and allow the network device to access the resource website after the verification is passed, thereby ensuring the security of website access.

[0060] However, if Figure 1As shown in the website public key infrastructure, generally speaking, the root certificate authority and the upper certificate authority are usually set up in different regions and managed by the management object of the region. When network devices in different regions need to access resource websites indirectly managed by the upper certificate authority in the region, there are trust issues due to the different regions between the network devices and the upper certificate authority, network and human interference, etc., as described below.

[0061] 1) Risk of root CA stopping issuing certificates (isolation and blindness risk): When the certificate resource registration used by a website server in a certain region depends on the root certificate authority in another region, once the root certificate authority in the other region does not issue a resource certificate to the website server due to distrust between the two regions, or due to network problems between the two regions, the resource website managed by the website server will not be able to be used normally.

[0062] 2) Risk of root CA revoking issued certificates (risk of disappearance): When the certificate resource registration used by a website server in a certain region depends on the root certificate authority in another region, once the root certificate authority in the other region cancels the resource certificate originally issued to the website server due to distrust between the two regions, the encryption services of all domain name websites of the website server will disappear, and the encryption services between the corresponding domain name websites and users will be interrupted, causing the entire network system to be paralyzed.

[0063] 3) Risk of certificate tampering (hijacking): When the certificate resource registration used by a website server in a certain region relies on a root certificate authority in another region, when the root certificate authority in another region is attacked or performs malicious operations or issues certificates containing false information, it is easy for the resource website held by the website server to be attacked or even hijacked.

[0064] 4) Information security risk: When the certificate resource registration used by a website server in a certain region depends on the root certificate authority in another region, the daily traffic network service information of the website server in that region (such as website access information of network devices) will be mastered by the root certificate authority in another region. If the relationship between the two regions is unreliable, it will cause serious information security leakage risks.

[0065] In reality, in the current website public key infrastructure, many root certificate authorities are usually set up in a few regions, and then the root certificate authorities in a few regions are directly or indirectly associated with website servers in most regions. When there is distrust or conflict between regions, the above four situations will easily occur, making the reliability of network devices for website access low.

[0066] In order to effectively improve the reliability of website access by network devices, the embodiment of the present application utilizes a virtual root private key of a common virtual root that does not change and is commonly used in the cross-signed certificates of multiple root certificate authorities, and the network device stores the virtual root public key of the common virtual root. Therefore, when the network device accesses the target website, combined with the association between the virtual root public key and the virtual root private key, the website server can use the cross-signed certificate and the virtual root public key sent by the network device to perform qualification verification, thereby avoiding the possibility that the qualification verification of the network device is invalid due to certificate changes, thereby greatly improving the reliability of website access by network devices; in addition, the use of encryption devices to save the virtual root private key greatly improves the security of certificate management in the alliance website management system.

[0067] The following will further describe the alliance website management system provided by the embodiment of the present application. Figure 2 As shown in FIG. 1 , it is a schematic diagram of the structure of an alliance website management system provided by an embodiment of the present application. Figure 2 As shown in, the embodiments of the present application are in the original Figure 1 In addition to the website public key infrastructure architecture shown in the figure, a new root certificate alliance is also built. Among them, multiple root certificate authorities (which can be Figure 1 The upper certificate authority or root certificate authority or even a certificate authority at a certain level in the middle as shown in the figure forms an institution alliance, and then all the root certificate authorities in the alliance follow a common virtual root. Each root certificate authority is directly or indirectly associated with multiple website servers in the region to which it belongs, and authorizes resources for these website servers so that these website servers can manage multiple resource websites. It can be understood that, Figure 2 The alliance website management system shown only uses the root certificate authority directly associated with the website server as a simplified example. In actual applications, the root certificate authority is usually associated with the certificate authority of the next layer, and the certificate authority of the next layer is associated with the certificate authority of the next layer until it is associated with the website server. This does not affect the implementation of the present application scheme.

[0068] The shared virtual root is an asymmetric private key, which includes a mutually associated virtual root private key and a virtual root public key. In the alliance website management system, the cross-signed certificate held by each root certificate authority is generated based on the virtual root private key; then, based on the cross-signed certificate, the certificate chain of the website server associated with each root certificate authority is also added with the cross-signed certificate, that is, the certificate chains of all website servers in the alliance website management system contain relevant information of the virtual root private key. The network devices in the alliance website management system store the virtual root public key. The virtual root private key and the virtual root public key are usually unchanged.

[0069] Therefore, when the network device logs in to the target website, the network device will send the target website's access request and the virtual root public key it holds to the website server corresponding to the target website. Then, after receiving the access request and virtual root public key sent by the network device, the website server obtains the cross-signed certificate of the root certificate authority in its own certificate chain, and then further performs the resource inspection process according to the access request, that is, the access qualification inspection is performed using the association relationship between the virtual root private key information and the virtual root public key in the cross-signed certificate, and after the access qualification inspection is passed, the network device is sent access permission information so that the network device can access the target website. Therefore, the key to the resource verification link is placed on the association relationship between the virtual root public key and the virtual root private key, so as to avoid the possibility that the qualification verification of the network device is invalid due to changes in the relevant root institution certificate or the certificate chain of the website server, thereby greatly improving the effective reliability of the website access by the network device in the alliance website management system.

[0070] The alliance website management system provided by the embodiment of the present application is essentially that all regions where the root certificate authorities are located share the same CA root (i.e., virtual root private key). The massive website servers associated with all the root certificate authorities only need to update the certificate chain once, and at the same time, the browser side of the network devices in these regions can import the common virtual root public key to perform reliable website access. After a new region (i.e., the corresponding new root certificate authority) joins the alliance, the virtual root private key can be directly used to cross-sign and endorse the new root certificate authority, and the massive website servers associated with other root certificate authorities do not need to update the certificate chain again. The essence of this solution is to establish a virtual root private key that is commonly trusted by multiple root certificate authorities in the alliance through cross-signature. Since other root certificate authorities outside the alliance do not use the virtual root private key to cross-sign certificates, other network devices outside the alliance cannot access the websites in the alliance. And under this setting, every time the relevant certificates are updated, it is not necessary for all website servers in the alliance to update the websites under their roots, thereby improving the update efficiency.

[0071] In addition, an encryption device is set up in the alliance website management system, and the virtual root private key is stored in the encryption device. Other devices or users cannot access the information in the encryption device, that is, all devices (including the root certificate authority) cannot obtain the plain text of the virtual root private key, thereby ensuring the security of the virtual root private key, and further improving the security and reliability of certificate resource management in the alliance website management system.

[0072] It is understandable that the encryption device is a hardware password management device equipped with a processor. It can be placed in the area where all root certificate authorities in the alliance website management system belong, and the processor of the encryption device is equipped with a fixed execution process and a security program that is not controlled by the outside world, so as to ensure its security and confidentiality.

[0073] In some embodiments, in order to further improve the management security of the alliance website management system, each institution cross-signature certificate is generated in the processor of the encryption device. Figure 3 When the encryption device generates the cross-signature of each institution, the execution steps include the following steps 301 to 302.

[0074] Step 301: Obtain the initial root certificate of the root certificate authority.

[0075] Step 302: Sign the initial root certificate using the virtual root private key, and obtain an institution cross-signature certificate based on the signed initial root certificate.

[0076] Steps 301 to 302 are described in detail below.

[0077] In some embodiments, the encryption device first obtains the initial root certificate generated by each root certificate authority itself, and then further signs the initial root certificate using a private virtual root private key, thereby using the signed initial root certificate as the cross-signature certificate of the root certificate authority.

[0078] In order to further improve the security and confidentiality of the virtual root private key, in the alliance website management system, a regional management device is set up in each region where the root certificate authority belongs to manage all the root certificate authorities in the region. Figure 4 , is a schematic diagram of an alliance website management system provided with a regional management device provided in an embodiment of the present application. Figure 4 As shown in , there may be multiple root certificate authorities in the same region (such as root certificate authority 1 and root certificate authority 2 in region A), but there is only one region management device in a region (such as only region management device A in region A).

[0079] Among them, multiple regional management devices in the alliance website management system store symmetric encryption subkeys. It can be understood that in the alliance website management system provided by this application, each region may be equipped with a regional management device, or multiple regions may share one regional management device; and all regional management devices may hold a symmetric encryption subkey, or some regional management devices may hold a symmetric encryption subkey, while other regional management devices may not hold a symmetric encryption subkey, which does not affect the implementation of this application.

[0080] In order to further improve the security and confidentiality of the virtual root private key, the encryption device also needs to encrypt the virtual root private key before signing the initial root certificate. Figure 5 When the encryption device uses the virtual root private key to sign the initial root certificate, the execution steps include the following steps 501 to 503.

[0081] Step 501: Acquire symmetric encryption subkeys input by multiple regional management devices, and obtain a symmetric encryption key based on the combination of all symmetric encryption subkeys.

[0082] Step 502: Encrypt the virtual root private key based on the symmetric encryption key to obtain an encrypted virtual root private key.

[0083] Step 503: Use the encrypted virtual root private key to sign the initial root certificate.

[0084] Steps 501 to 502 are described in detail below.

[0085] In some embodiments, when the encryption device signs the initial root certificate of any root certificate authority, it will first obtain multiple symmetric encryption subkeys input by multiple regional management devices, and then combine these symmetric encryption subkeys to obtain a complete symmetric encryption key that can be used to encrypt the virtual root private key.

[0086] Next, the virtual root private key is encrypted with a symmetric encryption key using a relevant symmetric encryption algorithm (such as 3DES algorithm, AES algorithm, Twofish algorithm, etc.) to obtain an encrypted virtual root private key. The encrypted virtual root private key is then used to sign the initial root certificate of the root certificate authority to obtain the root certificate authority's cross-signature.

[0087] Through the above steps 501 to 502, before signing the initial root certificate, the virtual root private key is first encrypted using the encrypted virtual root private key obtained by combining the symmetric encryption subkeys managed by multiple regional management devices, thereby greatly improving the security and confidentiality of the virtual root private key; and the symmetric encryption key is divided into multiple symmetric encryption subkeys and stored confidentially by each regional management device, so that a single regional management device cannot obtain the complete symmetric encryption key, and thus cannot recover the virtual root private key from the signed institutional cross-signed certificate, thereby further improving the security and confidentiality of the virtual root private key.

[0088] In addition, in order to further improve the security and confidentiality of symmetric encryption keys, a key generation device specifically used to generate symmetric encryption subkeys is also set up in the alliance website management system. Similar to the encryption device, the key generation device is also a hardware password management device equipped with a processor. Other devices or users cannot access the data information in the key generation device.

[0089] Reference Figure 6 When the key generation device generates a symmetric encryption sub-key, the execution steps include the following steps 601 to 602.

[0090] Step 601: Generate a symmetric encryption key.

[0091] Step 602: Split the symmetric encryption key to obtain multiple symmetric encryption subkeys, and send each symmetric encryption subkey to the regional management device for storage.

[0092] Steps 601 to 602 are described in detail below.

[0093] In some embodiments, firstly, a symmetric encryption key with a matching length is randomly generated according to the length of the virtual root private key. Then, the symmetric encryption key is divided into multiple symmetric encryption subkeys using some conventional splitting methods (such as using random splitting schemes to randomly split into n parts, or other schemes can be used, which are not limited in this application), and then each symmetric encryption subkey is sent to multiple regional management devices for storage management, thereby effectively improving the security and confidentiality of the symmetric encryption key.

[0094] It is understandable that the number of symmetric encryption subkeys may be less than the number of all regional management devices, in which case only some of the regional management devices hold the symmetric encryption subkeys. In this case, the regional management devices storing the symmetric encryption subkeys may be changed at a fixed update cycle.

[0095] In another case, the key generation device may also generate symmetric encryption sub-keys that are consistent with the number of devices of all regional management devices, which will be further described in detail below.

[0096] Reference Figure 7 When the key generation device splits the symmetric encryption key to obtain multiple symmetric encryption sub-keys, the execution steps include the following steps 701 to 702.

[0097] Step 701: Obtain the number of devices managed by all regions.

[0098] Step 702: Evenly divide the symmetric encryption key based on the number of devices to obtain symmetric encryption sub-keys consistent with the number of devices.

[0099] Steps 701 to 702 are described in detail below.

[0100] In some embodiments, after generating the symmetric encryption key, the key generation device may generate multiple symmetric encryption subkeys in the form of equal division. Specifically, the key generation device first determines the number of devices of all regional management devices in the alliance website management system, and then evenly divides the generated symmetric encryption key according to the number of devices to obtain symmetric encryption subkeys of the number of devices, and then sends these symmetric encryption subkeys to each regional management device one by one for storage. This effectively improves the randomness of the symmetric encryption subkeys assigned to each regional management device, thereby improving the security and confidentiality of the symmetric encryption key.

[0101] In addition, the symmetric encryption keys can also be divided based on the resource usage in each region, as shown below.

[0102] Reference Figure 8 When the key generation device splits the symmetric encryption key to obtain multiple symmetric encryption sub-keys, and sends each symmetric encryption sub-key to the key management device of the regional organization for storage, the execution steps include the following steps 801 to 804.

[0103] Step 801: Obtain the resource proportion and importance weight of the region to which each regional management device belongs.

[0104] Step 802: Based on the product of the resource proportion value and the importance weight, the partition weight value corresponding to each regional management device is obtained, and all the partition weight values ​​are accumulated to obtain the total partition weight value.

[0105] Step 803: Obtain the division value of each regional management device based on the ratio of the division weight value corresponding to each regional management device to the total division weight value.

[0106] Step 804: Use the partition values ​​to split the symmetric encryption key one by one to obtain symmetric encryption sub-keys, and send the symmetric encryption sub-keys to the corresponding regional management device for storage.

[0107] Steps 801 to 804 are described in detail below.

[0108] In some embodiments, the region to which each regional management device belongs is first obtained. The resource share of and importance weights , where the resource proportion value indicates the proportion of the allocated resource management value of all website servers in the region to the total resource value in the alliance website management system; the importance weight is a weight value pre-set for each region based on the importance of the region.

[0109] Next, for each region , based on resource proportion value and importance weights The product of , get the division weight value corresponding to each regional management device , and add up all the partition weights to get the total partition weight ,in The number of devices that manage devices for all regions.

[0110] Then, based on the division weight value corresponding to each region management device Total value of partition weight The ratio of the values ​​obtained is the division value of each regional organization , and then use the partition values ​​to split the symmetric encryption key one by one to obtain the symmetric encryption sub-key corresponding to the regional management device, and send the symmetric encryption sub-key to the corresponding regional management device for storage.

[0111] Through the above steps 801 to 804, the symmetric encryption keys are divided using the resource proportion values ​​and importance weights corresponding to the regions to which each regional management device belongs, so as to obtain symmetric encryption sub-key sizes suitable for the importance of each region, so that symmetric encryption sub-keys with a larger proportion can be stored in regional management devices in important regions to reduce the risk of leakage by regional management devices in unimportant regions, thereby greatly improving the security and confidentiality of the symmetric encryption keys, and further improving the security of the alliance website management system provided by the present application.

[0112] It is understandable that the symmetric encryption key is a long string of random numbers. When the key generation device splits the symmetric encryption key, it directly splits the long string of numbers into several parts, each of which is a symmetric encryption subkey. For example, the symmetric encryption key is 8 characters [12345678]. After the symmetric encryption key is split, three symmetric encryption subkeys

[123]

[45]

[678] are formed, and it can also be divided into three symmetric encryption subkeys

[12]

[456]

[798] . The order of the division can be randomly generated or customized.

[0113] In order to further improve the security of symmetric encryption keys, the order of division is randomly generated. Fig. 9 When the key generation device uses the division values ​​to split the symmetric encryption key one by one to obtain the symmetric encryption sub-key, and sends the symmetric encryption sub-key to the corresponding regional management device for storage, the execution steps include the following steps 901 to 902.

[0114] Step 901: Randomly generate a sequence corresponding to the number of devices.

[0115] Step 902: Based on the sequential sequence, the symmetric encryption key is divided one by one using the division values ​​to obtain the symmetric encryption sub-keys, and the symmetric encryption sub-keys are sent to the corresponding regional management device for storage.

[0116] Steps 901 to 902 are described in detail below.

[0117] In some embodiments, when the partition value of each regional management device is obtained, a sequence corresponding to the number of devices of all regional management devices is randomly generated, and the sequence is a random scramble of all integers from 1 to the number of devices, such as [5, 3, 1, ..., I]. Then, according to the order of elements in the sequence, the partition value of each regional management device is used to split the symmetric encryption key one by one to obtain the symmetric encryption subkey, and the symmetric encryption subkey is sent to the corresponding regional management device for storage.

[0118] Through the above steps 901 to 902, the randomness of the position of the symmetric encryption subkey assigned to each regional management device in the symmetric encryption key is further improved by using a randomly generated sequential sequence, thereby improving the security and confidentiality of the symmetric encryption key.

[0119] Reference Fig.10 After the key generation device generates the symmetric encryption sub-key, the execution steps also include the following steps 1001 to 1002.

[0120] Step 1001: Obtain a preset key update cycle time.

[0121] Step 1002: Based on a preset key update cycle time, periodically generate and update a symmetric encryption key.

[0122] Step 1003: Split the updated symmetric encryption key into multiple updated symmetric encryption subkeys, and send each updated symmetric encryption subkey to the regional management device for storage as a new symmetric encryption subkey.

[0123] Steps 1001 to 1003 are described in detail below.

[0124] In some embodiments, in order to further improve the security and confidentiality of the virtual root private key, a preset key update cycle time is set in advance, and then the key generation device periodically generates an updated symmetric encryption key according to the preset key update cycle time, and divides the updated symmetric encryption key into multiple updated symmetric encryption sub-keys, and sends each updated symmetric encryption sub-key to the regional management device for storage as a new symmetric encryption sub-key.

[0125] Reference Fig.11 After the key generation device generates the symmetric encryption sub-key, the execution steps also include the following steps 1101 to 1102.

[0126] Step 1101: When the number of regional management devices changes, an updated symmetric encryption key is generated.

[0127] Step 1102: Split the updated symmetric encryption key into multiple updated symmetric encryption subkeys, and send each updated symmetric encryption subkey to the regional management device for storage as a new symmetric encryption subkey.

[0128] Steps 1101 to 1102 are described in detail below.

[0129] In some embodiments, in order to further improve the security and confidentiality of the virtual root private key, in the alliance website management system, when a region withdraws from the alliance, or a new region joins the alliance, that is, when the regional management device changes, the key generation device will also generate an updated symmetric encryption key, and split the updated symmetric encryption key to obtain multiple updated symmetric encryption sub-keys, and send each updated symmetric encryption sub-key to the regional management device as a new symmetric encryption sub-key for storage.

[0130] The alliance website management system proposed in the embodiment of the present application includes multiple root certificate authorities, which are associated with multiple website servers. Each root certificate authority stores an institution cross-signed certificate, which is generated based on a virtual root private key of a shared virtual root, and each network device stores a virtual root public key of the shared virtual root; an encryption device, which is at least used to store the virtual root private key; when the network device accesses and logs in to a target website, the network device is used to send an access request and a virtual root public key of the target website to the website server corresponding to the target website, and the website server is used to obtain the institution cross-signed certificate of the corresponding root certificate authority, and perform access qualification verification based on the institution cross-signed certificate, the access request and the virtual root public key, and send access permission information to the network device after the access qualification verification passes. The embodiment of the present application utilizes the cross-signed certificates of multiple root certificate authorities to jointly use a virtual root private key of a common virtual root that does not change, and the network device stores the virtual root public key of the common virtual root. Therefore, when the network device visits the target website, combined with the association between the virtual root public key and the virtual root private key, the website server can use the cross-signed certificate and the virtual root public key sent by the network device to perform qualification verification, thereby avoiding the possibility that the qualification verification of the network device is invalid due to certificate changes, thereby greatly improving the reliability of the network device in accessing the website; in addition, the virtual root private key is stored using an encryption device, which greatly improves the security of certificate management in the alliance website management system.

[0131] The embodiments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0132] Those skilled in the art will appreciate that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0133] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0134] Those skilled in the art will appreciate that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0135] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0136] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0137] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the above units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. The mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0138] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0139] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0140] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including multiple instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store programs.

[0141] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but the scope of the rights of the present invention is not limited thereto. Any modification, equivalent substitution and improvement made by a person skilled in the art without departing from the scope and essence of the present invention should be within the scope of the rights of the present invention.

Claims

1. An alliance website management system, characterized in that: The system comprises: A plurality of root certificate authorities, each of which is associated with a plurality of website servers, each of which stores an institution cross-signed certificate, the institution cross-signed certificate is generated based on a virtual root private key of a common virtual root, and each network device stores a virtual root public key of the common virtual root; An encryption device, the encryption device being used at least to store the virtual root private key; When the network device performs access login to the target website, the network device is used to send the access request of the target website and the virtual root public key to the website server corresponding to the target website, and the website server is used to obtain the agency cross-signature certificate of the corresponding root certificate authority, and perform access qualification verification according to the agency cross-signature certificate, the access request and the virtual root public key, and send access permission information to the network device after the access qualification verification passes; The cross-signature certificate of the root certificate authority is generated by the encryption device. When the encryption device generates the cross-signature certificate, the steps include: Obtaining an initial root certificate of the root certificate authority; Signing the initial root certificate using the virtual root private key, and obtaining the institution cross-signature certificate based on the signed initial root certificate; The system further comprises a plurality of regional management devices, wherein the regional management devices are at least used to store symmetric encryption subkeys. When the encryption device executes the step of signing the initial root certificate by using the virtual root private key, the execution steps include: Acquire symmetric encryption subkeys inputted by a plurality of the regional management devices, and obtain a symmetric encryption key by combining all the symmetric encryption subkeys; Encrypting the virtual root private key based on the symmetric encryption key to obtain an encrypted virtual root private key; The initial root certificate is signed using the encrypted virtual root private key.

2. The alliance website management system according to claim 1, characterized in that: The system is further provided with a key generation device, the symmetric encryption subkey is generated by the key generation device, and when the key generation device generates the symmetric encryption subkey, the steps performed include: generating the symmetric encryption key; The symmetric encryption key is divided to obtain a plurality of symmetric encryption subkeys, and each of the symmetric encryption subkeys is sent to the regional management device for storage.

3. The alliance website management system according to claim 2, characterized in that: When the key generation device performs the step of splitting the symmetric encryption key to obtain a plurality of the symmetric encryption subkeys, the steps include: Get the number of devices managed by all the devices in the region; The symmetric encryption key is evenly divided based on the number of devices to obtain the symmetric encryption sub-keys that are consistent with the number of devices.

4. The alliance website management system according to claim 2, characterized in that: When the key generation device performs the step of splitting the symmetric encryption key to obtain a plurality of symmetric encryption subkeys, and sending each of the symmetric encryption subkeys to the regional management device for storage, the steps include: Obtaining the resource proportion value and importance weight of the region to which each of the regional management devices belongs; Based on the product of the resource proportion value and the importance weight, a partition weight value corresponding to each of the regional management devices is obtained, and all the partition weight values ​​are accumulated to obtain a total partition weight value; Obtaining a division value for each of the area management devices based on a ratio of a division weight value corresponding to each of the area management devices to the total value of the division weights; The symmetric encryption key is divided one by one using the division values ​​to obtain the symmetric encryption subkeys, and the symmetric encryption subkeys are sent to the corresponding regional management device for storage.

5. The alliance website management system according to claim 4, characterized in that: When the key generation device performs the steps of dividing the symmetric encryption key by using the division values ​​one by one to obtain the symmetric encryption subkeys, and sending the symmetric encryption subkeys to the corresponding regional management device for storage, the steps include: Randomly generate a sequence corresponding to the number of devices; Based on the sequential sequence, the symmetric encryption key is divided one by one using the division values ​​to obtain the symmetric encryption sub-keys, and the symmetric encryption sub-keys are sent to the corresponding regional management device for storage.

6. The alliance website management system according to claim 2, characterized in that: After the key generation device generates the symmetric encryption subkey, the steps further include: Get the preset key update cycle time; Based on the preset key update cycle time, periodically generate and update the symmetric encryption key; The updated symmetric encryption key is divided into multiple updated symmetric encryption subkeys, and each of the updated symmetric encryption subkeys is sent to the regional management device for storage as a new symmetric encryption subkey.

7. The alliance website management system according to claim 2, characterized in that: After the key generation device generates the symmetric encryption subkey, the steps further include: When the number of regional management devices changes, an updated symmetric encryption key is generated; The updated symmetric encryption key is divided into multiple updated symmetric encryption subkeys, and each of the updated symmetric encryption subkeys is sent to the regional management device for storage as a new symmetric encryption subkey.

8. The alliance website management system according to claim 1, characterized in that: When the target website server performs the access qualification verification according to the institution cross-signature certificate, the access request and the virtual root public key, the execution steps include: Based on the access request, obtain the institution cross-signature certificate from its own certificate chain; The institution cross-signature certificate and the virtual root public key are subjected to certificate verification, and a qualification verification result of the access qualification verification is obtained according to the certificate verification result.

Images