CN113946815B - Authorization method for federal learning and privacy computation - Google Patents
Authorization method for federal learning and privacy computation Download PDFInfo
- Publication number
- CN113946815B CN113946815B CN202111224566.9A CN202111224566A CN113946815B CN 113946815 B CN113946815 B CN 113946815B CN 202111224566 A CN202111224566 A CN 202111224566A CN 113946815 B CN113946815 B CN 113946815B
- Authority
- CN
- China
- Prior art keywords
- verified
- authorization identifier
- authorizer
- authorization
- legal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
Abstract
The application relates to an authorization method for federal learning and privacy calculations. The method is applied to an authorized party and comprises the following steps: obtaining an authorization identifier of a process to be verified; determining whether the authorization identifier of the process to be verified is included in a legal authorization identifier list stored by the authorizer, wherein a new unique authorization identifier is allocated to the process to be verified when the process to be verified is started for the first time and each time the process to be verified is restarted, and the unique authorization identifier is not changed when the process to be verified is called; if yes, authorizing the process to be verified; if not, verifying whether the certificate of the process to be verified is legal or not, and adding the authorization identifier of the process to be verified into a legal authorization identifier list stored by the authorization party after judging that the certificate of the process to be verified is legal. Therefore, the authorization process is improved, and the problems that the process is difficult to sense and restart and the like are solved.
Description
Technical Field
The application relates to the technical field of data security and privacy protection, in particular to an authorization method for federal learning and privacy calculation.
Background
With the development of application fields such as artificial intelligence and big data mining analysis, the demand for data volume is more and more increased. For example, training artificial intelligence application models requires the use of large amounts of training data with appropriate data labels or feature values. High quality data often comes from application data generated and accumulated in business activities. However, application data is often distributed among different organizations and individuals, for example, transaction data is distributed among various financial institutions and medical diagnosis data is distributed among various medical institutions. Application data across industries and domains is also dispersed, for example, social attribute data and e-commerce transaction data in the internet domain are controlled by different entities. As the importance of data ownership, user privacy, data security, and the like are more emphasized, and as the laws and regulations put more strict constraints and requirements on data collection processing, organizations or individuals who grasp application data are often unwilling or do not have appropriate means to collaborate with each other, so that it is difficult for the application data grasped by each organization or individual to work together. This dilemma in data sharing and collaborative collaboration is referred to as data islanding. In order to solve the problem of cross-industry and cross-organization data cooperation, particularly the key problems of privacy protection and data security, a federal learning concept is provided. The federated learning refers to each participant who owns data, and under the premise that protected private data is not shared and the own data is not transmitted to the outside, the relevant information of the model is exchanged in an encryption mode, so that the collaborative optimization of the federated learning model is realized. The federated learning can be divided into horizontal federated learning with large overlap in the data feature space and small overlap in the sample space, vertical federated learning with small overlap in the data feature space and large overlap in the sample space, and federated migration learning with small overlap in both the data feature space and the sample space according to the distribution conditions of the data feature space and the sample space of the training data.
Privacy Computing (Privacy Computing) generally refers to a technique and system in which two or more parties jointly compute and each party performs joint machine learning and joint analysis on data by cooperation without revealing the respective data. The parties to the privacy calculations may be different departments of the same organization or different organizations. Under the privacy computation framework, the data cleartext of the participating party does not go out of the local, so that the data security is protected, and the cross-domain cooperation of multi-source data is realized. Privacy computing can be divided into data decentralized and data centralized. The data distributed privacy computation means that the original data is located in the server of each participant, and after the participants complete computation locally, the participants exchange the ciphertext data of the intermediate result with each other through the network. The data centralized privacy computation means that each participant transmits the ciphertext of the original data to the centralized computing environment, and after the centralized computing environment completes computation, the result is returned to the task initiator. In various business scenarios of federal learning and privacy computation, data interaction between different subsystems and data interaction between different participants in the same system are often involved, for this reason, security verification needs to be performed between multiple collaborative processes across systems or across platforms to ensure that the other party runs in a trusted execution environment, and the risk that the other party becomes non-trusted after the restart may occur in the business interaction process is considered, and the risk that the restart of the other party may not be perceived is also considered. Therefore, an authorization method for federal learning and privacy computation is needed, which not only can realize security authentication among multiple collaborative processes across systems or platforms, but also can solve the problems of process restart and difficulty in perception of opposite party restart by an authenticator.
Disclosure of Invention
In a first aspect, an embodiment of the present application provides an authorization method, where the method is applied to an authorizer, and includes: obtaining an authorization identifier of a process to be verified, wherein the process to be verified is allocated with a new unique authorization identifier when being started for the first time and restarted every time and is called without changing the unique authorization identifier; determining whether the authorization identifier of the process to be verified is included in a legal authorization identifier list stored by the authorizer; if so, authorizing the process to be verified; if not, verifying whether the certificate of the process to be verified is legal or not, and adding the authorization identifier of the process to be verified into a legal authorization identifier list stored by the authorization party after judging that the certificate of the process to be verified is legal.
The technical scheme described in the first aspect thus improves the authorization process and overcomes the difficulties of process restart being difficult to perceive.
According to a possible implementation manner of the technical solution of the first aspect, the embodiment of the present application further provides that the authorizer and the process to be authenticated belong to the same system, the same platform, or the same execution environment.
According to a possible implementation manner of the technical solution of the first aspect, an embodiment of the present application further provides that the authorizer is a scheduling process for task scheduling or a service processing process for executing a task, and the process to be verified is a message routing process for message delivery.
According to a possible implementation manner of the technical solution of the first aspect, the embodiment of the present application further provides that the process to be verified belongs to a centralized platform, and the authorizer belongs to a participant who participates in the federal learning task through the centralized platform.
According to a possible implementation manner of the technical solution of the first aspect, the embodiment of the present application further provides that the process to be verified is a message routing process deployed on the centralized platform and is used for message passing between the centralized platform and the authorized party.
According to a possible implementation manner of the technical solution of the first aspect, an embodiment of the present application further provides that the method further includes: and when the authorization identifier of the process to be verified is not included in the legal authorization identifier list stored by the authorizer and the certificate of the process to be verified is judged to be legal, judging whether the process to be verified is started for the first time, and if not, removing the previous authorization identifier corresponding to the process to be verified from the legal authorization identifier list stored by the authorizer.
According to a possible implementation manner of the technical solution of the first aspect, an embodiment of the present application further provides a method for determining whether the process to be verified is initially started, including: and judging whether a record of the process with the same name of the process to be verified exists or not according to a legal authorization identifier list stored by the authorizer, and if so, judging that the process to be verified is not started for the first time and the authorization identifier of the process with the same name is a previous authorization identifier corresponding to the process to be verified.
According to a possible implementation manner of the technical solution of the first aspect, an embodiment of the present application further provides that the method further includes: continuously sending a security verification request to the process to be verified according to a preset mode, wherein the security verification request requires to feed back the latest authorization identifier of the process to be verified; judging whether the process to be verified is credible or not according to a statistical result of a feedback failure event of a security verification request sent in a specific time period, if not, removing the latest authorization identifier of the process to be verified from a legal authorization identifier list stored by the authorizer, wherein the feedback failure event comprises no feedback or the latest authorization identifier of the process to be verified which is fed back is not included in the legal authorization identifier list stored by the authorizer.
According to a possible implementation manner of the technical solution of the first aspect, an embodiment of the present application further provides a method for determining whether the process to be authenticated is trusted according to a statistical result of a feedback failure event of a security authentication request sent in a specific time period, where the method includes: and when the feedback of the continuously sent safety verification requests for a specific number of times is a feedback failure event, judging that the process to be verified is not credible.
According to a possible implementation manner of the technical solution of the first aspect, an embodiment of the present application further provides that the continuously sending a security authentication request to the process to be authenticated according to a preset manner, including: and sending security verification requests to the process to be verified at intervals according to a preset time interval.
According to a possible implementation manner of the technical solution of the first aspect, the embodiment of the present application further provides that the authorizer sends a security authentication request to the process to be authenticated by sending a ping signal, and the process to be authenticated feeds back a latest authorization identifier of the process to be authenticated by sending a pong signal.
According to a possible implementation manner of the technical solution of the first aspect, an embodiment of the present application further provides a method for determining whether the process to be authenticated is trusted according to a statistical result of a feedback failure event of a security authentication request sent in a specific time period, where the method includes: and judging whether the process to be verified is credible or not according to the occurrence frequency and/or the occurrence frequency of the feedback failure event.
In a second aspect, an embodiment of the present application provides an authorization method, where the method is applied to an authorizer, and includes: obtaining an authorization identifier of a process to be verified, wherein the process to be verified is allocated with a new unique authorization identifier when being started for the first time and restarted every time and is called without changing the unique authorization identifier; determining whether the authorization identifier of the process to be verified is included in a legal authorization identifier list stored by the authorizer, wherein the authorizer updates the legal authorization identifier list stored by the authorizer by continuously asking for the latest authorization identifier of the process to be verified according to a preset mode; and if so, authorizing the process to be verified.
The technical scheme described in the second aspect thus improves the authorization process and overcomes the difficulties of process restart being difficult to perceive.
According to a possible implementation manner of the technical solution of the second aspect, the embodiment of the present application further provides that the authorizer and the process to be verified belong to the same trusted platform, the authorizer is a scheduling process for task scheduling or a service processing process for executing a task, and the process to be verified is a message routing process for message delivery.
According to a possible implementation manner of the technical solution of the second aspect, the embodiment of the present application further provides that the process to be verified belongs to a centralized platform, the authorized party belongs to a party participating in a federal learning task through the centralized platform, and the process to be verified is a message routing process deployed on the centralized platform and used for message passing between the centralized platform and the authorized party.
According to a possible implementation manner of the technical solution of the second aspect, the embodiment of the present application further provides that the method further includes: and when the authorization identifier of the process to be verified is judged not to be included in the legal authorization identifier list stored by the authorizer, verifying whether the certificate of the process to be verified is legal or not, and adding the authorization identifier of the process to be verified to the legal authorization identifier list stored by the authorizer after the certificate of the process to be verified is judged to be legal.
According to a possible implementation manner of the technical solution of the second aspect, the embodiment of the present application further provides that the method further includes: and when the authorization identifier of the process to be verified is not included in the legal authorization identifier list stored by the authorizer and the certificate of the process to be verified is judged to be legal, judging whether the process to be verified is started for the first time, and if not, removing the previous authorization identifier corresponding to the process to be verified from the legal authorization identifier list stored by the authorizer.
According to a possible implementation manner of the technical solution of the second aspect, an embodiment of the present application further provides a method for determining whether the process to be verified is started for the first time, including: and judging whether a record of the process with the same name of the process to be verified exists or not according to a legal authorization identifier list stored by the authorizer, and if so, judging that the process to be verified is not started for the first time and the authorization identifier of the process with the same name is a previous authorization identifier corresponding to the process to be verified.
According to a possible implementation manner of the technical solution of the second aspect, an embodiment of the present application further provides that the updating, by the authorizer, the list of valid authorization identifiers stored by the authorizer by continuously asking the process to be authenticated for the latest authorization identifier of the process to be authenticated according to a preset manner, where the updating includes: continuously sending a security verification request to the process to be verified according to a preset mode, wherein the security verification request requires to feed back the latest authorization identifier of the process to be verified; judging whether the process to be verified is credible or not according to a statistical result of a feedback failure event of a security verification request sent in a specific time period, if not, removing the latest authorization identifier of the process to be verified from a legal authorization identifier list stored by an authorizer, wherein the feedback failure event comprises no feedback or the latest authorization identifier of the process to be verified which is fed back is not included in the legal authorization identifier list stored by the authorizer.
According to a possible implementation manner of the technical solution of the second aspect, the embodiment of the present application further provides a method for determining whether the process to be authenticated is trusted according to a statistical result of a feedback failure event of the security authentication request sent in a specific time period, where the method includes: and when the feedback of the continuously sent safety verification requests for a specific number of times is a feedback failure event, judging that the process to be verified is not credible.
According to a possible implementation manner of the technical solution of the second aspect, the embodiment of the present application further provides that the authorizer sends a security authentication request to the process to be authenticated by sending a ping signal, and the process to be authenticated feeds back a latest authorization identifier of the process to be authenticated by sending a pong signal.
Drawings
In order to explain the technical solutions in the embodiments or background art of the present application, the drawings used in the embodiments or background art of the present application will be described below.
Fig. 1 shows a flow chart of an authorization method according to an implementation manner provided by an embodiment of the present application.
Fig. 2 shows a flow chart of an authorization method according to another implementation manner provided in an embodiment of the present application.
Fig. 3 shows a block diagram of an electronic device for an authorization method according to an embodiment of the present application.
Detailed Description
The embodiment of the application provides an authorization method for federal learning and privacy calculation in order to solve the problems that the safety certification among a plurality of collaborative processes across systems or platforms can be realized, the process restart and the difficulty of perception of the restart of an opposite side by a certification party can be solved, and the like. The method is applied to an authorized party and comprises the following steps: obtaining an authorization identifier of a process to be verified; determining whether the authorization identifier of the process to be verified is included in a legal authorization identifier list stored by the authorizer, wherein a new unique authorization identifier is allocated to the process to be verified when the process to be verified is started for the first time and each time the process to be verified is restarted, and the unique authorization identifier is not changed when the process to be verified is called; if so, authorizing the process to be verified; if not, verifying whether the certificate of the process to be verified is legal or not, and adding the authorization identifier of the process to be verified into a legal authorization identifier list stored by the authorization party after judging that the certificate of the process to be verified is legal. Therefore, the authorization process is improved, and the problems that the process is difficult to sense restart and the like are solved.
Embodiments of the application may be used in application scenarios including, but not limited to, multi-party security computing, federal learning related machine learning model training, data security, privacy protection, or other application scenarios applying a privacy computing framework or algorithm, etc.
The embodiments of the present application may be modified and improved according to specific application environments, and are not limited herein.
In order to make the technical field of the present application better understand, embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application.
Fig. 1 shows a flow chart of an authorization method according to an implementation manner provided by an embodiment of the present application. As shown in fig. 1, the authorization method 100 includes the following steps.
Step S102: and obtaining an authorization identifier of the process to be verified, wherein the process to be verified is allocated with a new unique authorization identifier when being started for the first time and restarted every time, and the unique authorization identifier is not changed when the process to be verified is called.
The authorization method 100 is applied to an authorizer, so that the authorizer obtains an authorization identifier of a process to be authenticated in step S102. The authorizer and the process to be authenticated may belong to the same system, for example, one service process in the same system authorizes another service process with reference to the authorization method 100; the authorizer and the process to be authenticated can belong to different subsystems of the same platform, for example, a subsystem for message relay authorizes a subsystem for trusted computing to obtain a message received by the former; the authorizer and the process to be authenticated can be located on different platforms or one party can be on a centralized computing platform and the other party can be on a participant, e.g., the authorizer represents the data provider and the process to be authenticated represents the data application, which needs to be authorized by the data provider to use the data of the data provider. Therefore, the authorization method 100 is implemented in an authorizer and is used by the authorizer to authorize a process to be authenticated, and the authorizer and the process to be authenticated may belong to different service processes of the same system, or belong to different subsystems of the same platform, or be located on different platforms, or one party is on a centralized computing platform and the other party is on a participant, or may represent an authorization process between any suitable two collaborators in various business application scenarios of federal learning and privacy computing, which is not specifically limited herein. Thus, the authorization method 100 is applicable to multiple collaborative processes across systems or platforms that require security authentication with each other to ensure that each other runs in a trusted execution environment. The different service processes of the same system or the respective processes of different subsystems or different processes not on the same platform may run in the untrusted execution environment and the trusted execution environment, respectively. When there is a need for service interaction, necessary security risks must be considered, for example, the process to be authenticated may be insecure and trusted, or the process to be authenticated may be secure and trusted but becomes insecure and trusted after a restart occurs during the service interaction.
In step S102, the embodiment of the present application provides that the process to be authenticated is assigned with a new unique authorization identifier at the time of initial startup and at the time of each restart, and the unique authorization identifier is not changed by invoking the process to be authenticated. Here, the Unique authorization Identifier may be generated by, for example, a Universal Unique Identifier (UUID) or a similar technique, such as generating a globally Unique string. The process to be authenticated must be satisfied that it is assigned a new unique authorization identifier, for example a newly generated globally unique string, both at its initial start and at each restart. This means that when the process to be authenticated encounters a restart event, a new unique authorization identification is inevitably assigned, and is inconsistent with a unique authorization identification assigned previously to the process to be authenticated; and also does not coincide with the authorized identification assigned by the other process. In step S102, a new unique authorization identifier is assigned to the process to be authenticated at the initial start and at each restart, and the unique authorization identifier is not changed when the process to be authenticated is invoked. In other words, the process to be verified is assigned a new unique authorization identifier at the initial start and at each restart, and the unique authorization identifier is not changed because the corresponding process to be verified is invoked. For a specific process, the specific process is assigned with a unique authorization identifier after being started for the first time, then the specific process is assigned with the unique authorization identifier again every time the specific process is restarted, and the unique authorization identifier assigned to the specific process each time is not repeated, so that the specific process is bound to have the unique authorization identifier which is different from the unique authorization identifier assigned after the specific process is started for the first time only by being restarted for one time; on the other hand, the specific process is called without being assigned with the unique authorization identifier again, so that the situations that the specific process is started and restarted for the first time and the situation that the specific process is called are treated differently. In some exemplary embodiments, the unique authorization identifier may be understood as a process ID, each process is assigned a unique process ID when it is first started or generated, and then each restart is assigned a new unique process ID or is treated as a newly generated process for process ID assignment. In addition, the unique authorization identifier is not changed when the process to be verified is called, that is, the unique authorization identifier or the process ID of the called process is not changed when a certain process is called, or the unique authorization identifier cannot be used for embodying the condition that the process is called, so that the two conditions that the process is started or restarted for the first time and the process is called can be distinguished. This is because a process being invoked will not generally change the condition of whether it is in a trusted execution environment, or whether the process being invoked will generally not affect whether the process is trusted and secure. For example, each process in the same platform generates a unique authorization identifier, such as a globally unique identification ID, as the process ID according to a UUID algorithm or similar algorithm when the process is initially generated and when the process is restarted. The process ID must satisfy the property of not repeating, that is, the process ID that does not repeat between every ever existing and existing process within the same platform. Thus, by the non-repetitive characteristic, it is possible to determine whether or not the original process corresponding to the process ID before the change has been killed by the change of the process ID. Because if a process is restarted, a new process ID is necessarily obtained, and the original process ID can only correspond to the original process before restarting.
Step S104: and determining whether the authorization identifier of the process to be verified is included in a legal authorization identifier list stored by the authorizer. If yes, go to step S106; if not, step S108 is performed.
In step S104, the authorized party stores a list of valid authorized identities that can be understood as a "white list", or a variable memory in which authorized identities that are considered to be valid are recorded. As mentioned above, the process to be authenticated must satisfy that it is assigned a new unique authorization identifier at the initial start and at each restart and that invoking a process does not cause the unique authorization identifier of the invoked process to change, so that the determination can be made by means of the authorization identifier of the process to be authenticated. If the authorization identifier of the process to be authenticated is in the valid authorization identifier list stored by the authorizer, which means that the authorization identifier of the process to be authenticated belongs to the "white list" or has a matching record on the variable storage, step S106 may be executed to perform authorization. The original authorization identifier of a certain process is assumed to be in the legal authorization identifier list stored by the authorizer, but the process is necessarily allocated with a new authorization identifier when the process is restarted later, and the new authorization identifier may not be in the legal authorization identifier list stored by the authorizer, so that the process is equivalently notified to the authorizer that the process is restarted, and the difficulty that the process is difficult to perceive that the process is restarted is overcome.
Step S106: and authorizing the process to be verified.
Step S108: and verifying whether the certificate of the process to be verified is legal or not, and adding the authorization identifier of the process to be verified into a legal authorization identifier list stored by the authorizer after judging that the certificate of the process to be verified is legal.
When the process to be verified is not in the list of valid authorization identifiers stored by the authorizer, the process to be verified may be restarted and assigned with a new authorization identifier, so that whether the restarted process to be verified is trusted can be further determined by the validity of the certificate, and the new authorization identifier is added to the list of valid authorization identifiers stored by the authorizer after the certificate is verified to be valid, so that the determination that the authorization identifier is included in the list of valid authorization identifiers stored by the authorizer can be made in step S104 when the process to be verified is authorized next time. Therefore, the authorization process is improved, and the problems that the process is difficult to sense and restart and the like are solved.
In some exemplary embodiments, in combination with the above steps S102 to S106, the unique authorization identifier may be understood as a process ID, each process is assigned a unique process ID when it is first started or generated, and the process is assigned a new unique process ID each time it is restarted and the process is invoked without causing a change in the process ID. In a possible implementation manner, the authorization method may represent a process of performing security authentication on an authenticated party, that is, a process to be verified, by an authenticator, that is, an authorizer. Specifically, the method comprises the following steps: the authenticator asks the authenticatee to provide the process ID of the authenticatee; the authenticator determines whether the process ID of the authenticated party is on the white list according to the white list of the local memory (namely, the legal authorization identification list stored by the authenticator), and if so, the authentication is passed; if not, verifying whether the certificate of the authenticated party is legal or not, wherein the certificate of the authenticated party can be sent to the authentication party together with the process ID of the authenticated party or can be sent additionally; if the certificate is legitimate, the process ID of the authenticated party is added to a whitelist of the local memory of the authenticating party. And the authenticator updates the authentication result of the authenticatee at intervals through a preset mechanism. For example, the authenticator sends a ping signal to the authenticatee at a preset interval or at a predetermined time, for example, every 5 seconds; if the authenticated party does not reply after continuously sending ping signals for N times (N is 3 or preset numbers), the authenticated party is determined to be not trusted and the process ID of the authenticated party is removed from the white list of the local memory of the authenticated party; if the authenticated party replies a pong signal in the period of continuously sending ping signals for N times, the pong signal must include the process ID to be verified of the authenticated party, comparing the process ID to be verified of the authenticated party with the original process ID corresponding to the authenticated party in a white list of a local memory of the authenticated party, and if the process ID is not consistent with the original process ID, indicating that the authenticated party is restarted or replaced; further judging whether the process ID to be verified of the authenticated party is in a white list of a local memory of the authenticated party, if so, considering that the authenticated party is still credible, and replacing the original process ID corresponding to the authenticated party by the process ID to be verified, namely matching with the characteristic of restarting and updating the process ID of the authenticated party so as to be beneficial to subsequent data interaction; if the process ID to be verified is not in the white list of the local memory of the authenticator, the authenticator is considered to be untrustworthy, and the original process ID corresponding to the authenticator is removed from the white list of the local memory of the authenticator, so that the certificate validity verification needs to be carried out again next time. Here, the authenticator and the authenticatee may be regarded as a participant outside the platform to perform remote authentication on the service process of the platform, may also be regarded as one service process in the platform to perform local authentication on another service process, and may also be regarded as one subsystem in the platform to perform local authentication on another subsystem.
In a possible implementation, the authorizer and the process to be authenticated belong to the same system, the same platform, or the same execution environment. For example, the authorizer is a scheduling process for task scheduling or a business processing process for executing tasks, and the process to be authenticated is a message routing process for message delivery. Thus, the authorization method 100 described above occurs between a scheduling process for task scheduling or a business processing process for executing a task and a message routing process for message passing, which can be understood as one service process performs local authentication on another service process within a platform.
In one possible embodiment, the process to be verified belongs to a centralized platform, and the authorizer belongs to a participant participating in a federal learning task through the centralized platform. Thus, the authorization method 100 described above occurs at a centralized platform and at the participants participating in the federal learning task through the centralized platform, and it can be understood that a participant (an authorizer) outside the platform remotely authenticates a service process (a process to be verified) of the platform. For example, the process to be authenticated is a message routing process deployed at the centralized platform and used for message passing between the centralized platform and the authorizer. That is, a participant remotely authenticates a message routing process of the centralized platform.
In one possible embodiment, the method further comprises: and when the authorization identifier of the process to be verified is not included in the legal authorization identifier list stored by the authorizer and the certificate of the process to be verified is judged to be legal, judging whether the process to be verified is started for the first time, and if not, removing the previous authorization identifier corresponding to the process to be verified from the legal authorization identifier list stored by the authorizer. By doing so, the legal authorized identification list stored by the authorized party can be updated in time and the previous authorized identification can be removed, thereby saving the storage space. And, judging whether the process to be verified is started for the first time, including: and judging whether a record of the process with the same name of the process to be verified exists or not according to a legal authorization identifier list stored by the authorizer, and if so, judging that the process to be verified is not started for the first time and the authorization identifier of the process with the same name is a previous authorization identifier corresponding to the process to be verified. That is, whether the process to be authenticated is the initial start may be determined by looking at the record of the process of the same name.
In one possible embodiment, the method further comprises: continuously sending a security verification request to the process to be verified according to a preset mode, wherein the security verification request requires to feed back the latest authorization identifier of the process to be verified; judging whether the process to be verified is credible or not according to a statistical result of a feedback failure event of a security verification request sent in a specific time period, if not, removing the latest authorization identifier of the process to be verified from a legal authorization identifier list stored by the authorizer, wherein the feedback failure event comprises no feedback or the latest authorization identifier of the process to be verified which is fed back is not included in the legal authorization identifier list stored by the authorizer. Therefore, whether the process to be verified is credible or not can be better judged by counting the feedback failure events meeting the specific requirements and then according to the statistical result in the specific time period. For example, determining whether the process to be authenticated is trusted according to a statistical result of a feedback failure event of the security authentication request sent within a specific time period includes: and when the feedback of the continuously sent safety verification requests for a specific number of times is a feedback failure event, judging that the process to be verified is not credible. Here, the specific number of times may be three times, five times, or any number of times. For another example, the continuously sending the security authentication request to the process to be authenticated according to a preset manner includes: and sending security verification requests to the process to be verified at intervals according to a preset time interval. Here, the preset time interval may be five seconds, ten seconds, or any number. In some exemplary embodiments, the authorizer sends a security authentication request to the process to be authenticated by sending a ping signal, and the process to be authenticated feeds back the latest authorization identifier of the process to be authenticated by sending a pong signal. In this manner, security verification can be conveniently accomplished by the ping signal and pong signal. In some exemplary embodiments, determining whether the process to be authenticated is trusted according to a statistical result of a feedback failure event of the security authentication request sent within a specific time period includes: and judging whether the process to be verified is credible or not according to the occurrence frequency and/or the occurrence frequency of the feedback failure event. Therefore, whether the process to be verified is credible or not can be better judged by combining the occurrence frequency and/or the occurrence frequency of the feedback failure event.
It should be understood that the authorization method 100 shown in fig. 1 may be implemented by a corresponding execution body or carrier. In some exemplary embodiments, a non-transitory computer readable storage medium stores computer instructions that, when executed by a processor, implement the authorization method 100 and any of the embodiments, implementations, or combinations thereof described above. In some exemplary embodiments, an electronic device includes: a processor; a memory for storing processor-executable instructions; wherein the processor implements the authorization method 100 by executing the executable instructions, as well as any of the embodiments, implementations, or combinations thereof described above.
Fig. 2 shows a flow chart of an authorization method according to another implementation manner provided in an embodiment of the present application. As shown in fig. 2, the authorization method 200 includes the following steps.
Step S202: and obtaining an authorization identifier of the process to be verified, wherein the process to be verified is allocated with a new unique authorization identifier when being started for the first time and restarted every time, and the unique authorization identifier is not changed when the process to be verified is called.
Step S204: and determining whether the authorization identifier of the process to be verified is included in a legal authorization identifier list stored by the authorizer, wherein the authorizer updates the legal authorization identifier list stored by the authorizer by continuously asking the process to be verified for the latest authorization identifier of the process to be verified according to a preset mode.
Step S206: and if so, authorizing the process to be verified.
In step S202, the embodiment of the present application provides that the process to be authenticated is assigned with a new unique authorization identifier at the time of initial startup and at the time of each restart, and the unique authorization identifier is not changed by invoking the process to be authenticated. Here, the unique authorization identifier may be generated by, for example, a UUID or similar technique, such as generating a globally unique string. The process to be authenticated must be satisfied that it is assigned a new unique authorization identifier, for example a newly generated globally unique string, both at its initial start and at each restart. This means that when the process to be authenticated encounters a restart event, it must be assigned a new unique authorization identifier that is inconsistent with the previously assigned unique authorization identifier. And the latest authorization identifier of the process to be verified is continuously requested to the process to be verified according to a preset mode to update the legal authorization identifier list stored by the authorization party, so that the verification efficiency is improved. Therefore, the authorization process is improved, and the problems that the process is difficult to sense and restart and the like are solved.
In a possible implementation manner, the authorizer and the process to be verified belong to the same trusted platform, the authorizer is a scheduling process for task scheduling or a business processing process for executing a task, and the process to be verified is a message routing process for message passing. The process to be verified belongs to a centralized platform, the authorizer belongs to a participant who participates in the federal learning task through the centralized platform, and the process to be verified is a message routing process deployed on the centralized platform and used for message transmission between the centralized platform and the authorizer.
In one possible embodiment, the method further comprises: and when the authorization identifier of the process to be verified is judged not to be included in the legal authorization identifier list stored by the authorizer, judging whether the certificate of the process to be verified is legal or not, and adding the authorization identifier of the process to be verified to the legal authorization identifier list stored by the authorizer after judging that the certificate of the process to be verified is legal. In some exemplary embodiments, the method further comprises: and when the authorization identifier of the process to be verified is not included in the legal authorization identifier list stored by the authorizer and the certificate of the process to be verified is judged to be legal, judging whether the process to be verified is started for the first time, and if not, removing the previous authorization identifier corresponding to the process to be verified from the legal authorization identifier list stored by the authorizer. Wherein, judging whether the process to be verified is started for the first time comprises: and judging whether a record of the process with the same name of the process to be verified exists or not according to a legal authorization identifier list stored by the authorizer, and if so, judging that the process to be verified is not started for the first time and the authorization identifier of the process with the same name is a previous authorization identifier corresponding to the process to be verified.
In a possible implementation manner, the updating, by the authorizer, the valid authorization identifier list stored by the authorizer by continuously asking the process to be authenticated for the latest authorization identifier of the process to be authenticated according to a preset manner includes: continuously sending a security verification request to the process to be verified according to a preset mode, wherein the security verification request requires to feed back the latest authorization identification of the process to be verified; judging whether the process to be verified is credible or not according to a statistical result of a feedback failure event of a security verification request sent in a specific time period, if not, removing the latest authorization identifier of the process to be verified from a legal authorization identifier list stored by an authorizer, wherein the feedback failure event comprises no feedback or the latest authorization identifier of the process to be verified which is fed back is not included in the legal authorization identifier list stored by the authorizer. The method for judging whether the process to be verified is credible according to the statistical result of the feedback failure event of the security verification request sent in the specific time period comprises the following steps: and when the feedback of the continuously sent safety verification requests for a specific number of times is a feedback failure event, judging that the process to be verified is not credible. In some exemplary embodiments, the authorizer sends a security authentication request to the process to be authenticated by sending a ping signal, and the process to be authenticated feeds back the latest authorization identifier of the process to be authenticated by sending a pong signal.
It should be understood that the authorization method 200 shown in fig. 2 may be implemented by a corresponding execution body or carrier. In some exemplary embodiments, a non-transitory computer readable storage medium stores computer instructions that, when executed by a processor, implement the authorization method 200 and any of the embodiments, implementations, or combinations thereof described above. In some example embodiments, an electronic device includes: a processor; a memory for storing processor-executable instructions; wherein the processor implements the authorization method 200 and any of the embodiments, implementations, or combinations thereof described above by executing the executable instructions.
In connection with fig. 1 and 2, the steps or details described above with respect to the authorization method 100 shown in fig. 1 or the authorization method 200 shown in fig. 2 may be in any possible combination or combination and possible replacement or variation.
With reference to fig. 1 and fig. 2, the authorization method 100 shown in fig. 1 or the authorization method 200 shown in fig. 2 described above implement robust stability of a local authentication state between cooperating processes, ensure security of private data, provide a secure and controllable inter-process communication flow, and provide a mechanism for continuous verification and update by using a ping signal and a pong signal, for example.
Referring to fig. 1 and 2, the authorization method 100 shown in fig. 1 or the authorization method 200 shown in fig. 2 may relate to a security authentication related technique, such as a participant performing remote authentication on a message routing process of the centralized platform or performing local authentication on one service process on another service process in the platform. Where remote authentication and local authentication may be based on SGX authentication techniques. SGX authentication is used between two enclaves to confirm that each other is in the same SGX environment, i.e. in the same machine. The SGX remote authentication is used to authenticate whether a target Enclave to interact with a process or Enclave is an Enclave running in the SGX environment, and is not a malicious forged process or a non-SGX related process. The SGX remote authentication is essentially a process of carrying out elliptic curve digital signature on a Quote structure and verifying a data signature. In contrast, SGX local authentication is used for one Enclave to confirm that another Enclave runs in the same machine. The local authentication is one-way, and one-time local authentication cannot finish mutual trust between two enclaves. One local authentication can only complete one Enclave trusting another. SGX local authentication is used in a scenario where two encrlaves need to communicate with each other, where an encrlave must confirm that the encrlave with which it communicates is running in the same SGX environment before it can initiate communication. For details regarding SGX remote authentication and SGX local authentication, any suitable encryption and decryption technique may be used, and is not specifically limited herein.
Fig. 3 shows a block diagram of an electronic device for an authorization method according to an embodiment of the present application. As shown in FIG. 3, electronic device 300 includes a main processor 302, an internal bus 304, a network interface 306, a main memory 308, and secondary processor 310 and secondary memory 312, as well as a secondary processor 320 and secondary memory 322. The main processor 302 is connected to the main memory 308, and the main memory 308 may be used to store computer instructions executable by the main processor 302, so that the authorization method 100 shown in fig. 1 or the authorization method 200 shown in fig. 2 may be implemented, including some or all of the steps, and including any possible combination or combination of the steps, and possible alternatives or variations thereof. The network interface 306 is used to provide network connectivity and to transmit and receive data over a network. The internal bus 304 is used to provide internal data interaction between the main processor 302, the network interface 306, the auxiliary processor 310, and the auxiliary processor 320. The secondary processor 310 is coupled to the secondary memory 312 and provides secondary computing power, and the secondary processor 320 is coupled to the secondary memory 322 and provides secondary computing power. The auxiliary processors 310 and 320 may provide the same or different auxiliary computing capabilities including, but not limited to, computing capabilities optimized for particular computing requirements such as parallel processing capabilities or tensor computing capabilities, computing capabilities optimized for particular algorithms or logic structures such as iterative computing capabilities or graph computing capabilities, and the like. The secondary processor 310 and the secondary processor 320 may include one or more processors of a particular type, such as a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or the like, so that customized functions and structures may be provided. In some exemplary embodiments, the electronic device 300 may not include an auxiliary processor, may include only one auxiliary processor, and may include any number of auxiliary processors and each have a corresponding customized function and structure, which are not specifically limited herein. The architecture of the two auxiliary processors shown in FIG. 3 is for illustration only and should not be construed as limiting. In addition, the main processor 302 may include a single-core or multi-core computing unit to provide the functions and operations necessary for embodiments of the present application. In addition, the main processor 302 and the auxiliary processors (such as the auxiliary processor 310 and the auxiliary processor 320 in fig. 3) may have different architectures, that is, the electronic device 300 may be a heterogeneous architecture based system, for example, the main processor 302 may be a general-purpose processor such as a CPU based on an instruction set operating system, and the auxiliary processor may be a graphics processor GPU suitable for parallelized computation or a dedicated accelerator suitable for neural network model-related operations. The auxiliary memory (e.g., auxiliary memory 312 and auxiliary memory 322 shown in fig. 3) may be used to implement customized functions and structures with the respective auxiliary processors. While main memory 308 is operative to store the necessary instructions, software, configurations, data, etc. to provide the functionality and operations necessary for embodiments of the subject application in conjunction with main processor 302. In some exemplary embodiments, the electronic device 300 may not include the auxiliary memory, may include only one auxiliary memory, and may further include any number of auxiliary memories, which is not specifically limited herein. The architecture of the two auxiliary memories shown in fig. 3 is illustrative only and should not be construed as limiting. Main memory 308, and possibly secondary memory, may include one or more of the following features: volatile, nonvolatile, dynamic, static, readable/writable, read-only, random-access, sequential-access, location-addressability, file-addressability, and content-addressability, and may include random-access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, a hard disk, a removable disk, a recordable and/or rewriteable Compact Disc (CD), a Digital Versatile Disc (DVD), a mass storage media device, or any other form of suitable storage media. The internal bus 304 may include any of a variety of different bus structures or combinations of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. It should be understood that the electronic device 300 shown in fig. 3, the illustrated configuration of which does not constitute a specific limitation on the apparatus or system involved, may in some exemplary embodiments include more or less components than the specific embodiments and figures, or combine certain components, or split certain components, or have a different arrangement of components.
The embodiments provided herein may be implemented in any one or combination of hardware, software, firmware, or solid state logic circuitry, and may be implemented in connection with signal processing, control, and/or application specific circuitry. Particular embodiments of the present application provide an apparatus or device that may include one or more processors (e.g., microprocessors, controllers, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), etc.) that process various computer-executable instructions to control the operation of the apparatus or device. Particular embodiments of the present application provide an apparatus or device that can include a system bus or data transfer system that couples the various components together. A system bus can include any of a variety of different bus structures or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. The devices or apparatuses provided in the embodiments of the present application may be provided separately, or may be part of a system, or may be part of other devices or apparatuses.
Particular embodiments provided herein may include or be combined with computer-readable storage media, such as one or more storage devices capable of providing non-transitory data storage. The computer-readable storage medium/storage device may be configured to store data, programmers and/or instructions that, when executed by a processor of an apparatus or device provided by embodiments of the present application, cause the apparatus or device to perform operations associated therewith. The computer-readable storage medium/storage device may include one or more of the following features: volatile, non-volatile, dynamic, static, read/write, read-only, random access, sequential access, location addressability, file addressability, and content addressability. In one or more exemplary embodiments, the computer-readable storage medium/storage device may be integrated into a device or apparatus provided in the embodiments of the present application or belong to a common system. The computer-readable storage medium/memory device may include optical, semiconductor, and/or magnetic memory devices, etc., and may also include Random Access Memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, a hard disk, a removable disk, a recordable and/or rewriteable Compact Disc (CD), a Digital Versatile Disc (DVD), a mass storage media device, or any other form of suitable storage media.
The above is an implementation manner of the embodiments of the present application, and it should be noted that the steps in the method described in the embodiments of the present application may be sequentially adjusted, combined, and deleted according to actual needs. In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments. It is to be understood that the embodiments of the present application and the structures shown in the drawings are not to be construed as particularly limiting the devices or systems concerned. In other embodiments of the present application, an apparatus or system may include more or fewer components than the specific embodiments and figures, or may combine certain components, or may separate certain components, or may have a different arrangement of components. Those skilled in the art will understand that various modifications and changes may be made in the arrangement, operation, and details of the methods and apparatus described in the specific embodiments without departing from the spirit and scope of the embodiments herein; without departing from the principles of embodiments of the present application, several improvements and modifications may be made, and such improvements and modifications are also considered to be within the scope of the present application.
Claims (13)
1. An authorization method, which is applied to an authorizer, comprising:
obtaining an authorization identifier of a process to be verified, wherein the process to be verified is allocated with a new unique authorization identifier when being started for the first time and restarted every time and is called without changing the unique authorization identifier;
determining whether the authorization identifier of the process to be verified is included in a legal authorization identifier list stored by the authorizer;
if so, authorizing the process to be verified;
if not, verifying whether the certificate of the process to be verified is legal and adding the authorization identifier of the process to be verified into a legal authorization identifier list stored by the authorization party after judging that the certificate of the verification process is legal,
the method further comprises the following steps: judging whether the process to be verified is started for the first time or not after judging that the authorization identifier of the process to be verified is not included in the legal authorization identifier list stored by the authorizer and judging that the certificate of the process to be verified is legal, if not, removing the previous authorization identifier corresponding to the process to be verified from the legal authorization identifier list stored by the authorizer,
the method further comprises the following steps: continuously sending a security verification request to the process to be verified according to a preset mode, wherein the security verification request requires to feed back the latest authorization identifier of the process to be verified; judging whether the process to be verified is credible or not according to the statistical result of the feedback failure event of the security verification request sent in a specific time period, if not, removing the latest authorization identifier of the process to be verified from a legal authorization identifier list stored by the authorizer, wherein the feedback failure event comprises no feedback or the latest authorization identifier of the process to be verified fed back is not included in the legal authorization identifier list stored by the authorizer, and the statistical result of the feedback failure event comprises the occurrence number and/or the occurrence frequency of the feedback failure event,
and when the feedback of the continuously sent security verification requests of a specific number of times is a feedback failure event, judging that the process to be verified is not credible.
2. The method of claim 1, wherein the authorizer and the process to be authenticated belong to the same system, the same platform, or the same execution environment.
3. The method according to claim 2, wherein the authorizer is a scheduling process for task scheduling or a traffic processing process for executing tasks, and the process to be authenticated is a message routing process for message passing.
4. The method of claim 1, wherein the process to be verified belongs to a centralized platform, and wherein the authorizer belongs to a participant participating in a federal learning task via the centralized platform.
5. The method of claim 4, wherein the process to be authenticated is a message routing process deployed on the centralized platform and used for message passing between the centralized platform and the authorized party.
6. The method of claim 1, wherein determining whether the process to be authenticated is a first boot comprises:
and judging whether a record of the process with the same name of the process to be verified exists or not according to a legal authorization identifier list stored by the authorizer, and if so, judging that the process to be verified is not started for the first time and the authorization identifier of the process with the same name is a previous authorization identifier corresponding to the process to be verified.
7. The method according to claim 1, wherein continuously sending a security authentication request to the process to be authenticated according to a preset manner comprises:
and sending security verification requests to the process to be verified at intervals according to a preset time interval.
8. The method according to claim 1, wherein the authorizer sends a security authentication request to the process to be authenticated by sending a ping signal, and the process to be authenticated feeds back a latest authorization identifier of the process to be authenticated by sending a pong signal.
9. An authorization method, which is applied to an authorizer, comprising:
obtaining an authorization identifier of a process to be verified, wherein the process to be verified is allocated with a new unique authorization identifier when being started for the first time and restarted every time and is called without changing the unique authorization identifier;
determining whether the authorization identifier of the process to be verified is included in a legal authorization identifier list stored by the authorizer, wherein the authorizer updates the legal authorization identifier list stored by the authorizer by continuously asking the process to be verified for the latest authorization identifier of the process to be verified according to a preset mode;
if so, authorizing the process to be verified,
the method further comprises the following steps: when the authorization identification of the process to be verified is judged not to be included in the legal authorization identification list stored by the authorizer, verifying whether the certificate of the process to be verified is legal or not and adding the authorization identification of the process to be verified to the legal authorization identification list stored by the authorizer after the certificate of the process to be verified is judged to be legal,
the method further comprises the following steps: judging whether the process to be verified is started for the first time or not after judging that the authorization identifier of the process to be verified is not included in the legal authorization identifier list stored by the authorizer and judging that the certificate of the process to be verified is legal, if not, removing the previous authorization identifier corresponding to the process to be verified from the legal authorization identifier list stored by the authorizer,
the method for updating the legal authorization identifier list stored by the authorization party by continuously asking the process to be verified for the latest authorization identifier of the process to be verified by the authorization party according to a preset mode comprises the following steps: continuously sending a security verification request to the process to be verified according to a preset mode, wherein the security verification request requires to feed back the latest authorization identifier of the process to be verified; judging whether the process to be verified is credible or not according to the statistical result of the feedback failure event of the security verification request sent in a specific time period, if not, removing the latest authorization identifier of the process to be verified from the legal authorization identifier list stored by the authorizer, wherein the feedback failure event comprises no feedback or the latest authorization identifier of the process to be verified which is fed back is not included in the legal authorization identifier list stored by the authorizer, and the statistical result of the feedback failure event comprises the occurrence frequency and/or occurrence frequency of the feedback failure event,
and when the feedback of the continuously sent security verification requests of a specific number of times is a feedback failure event, judging that the process to be verified is not credible.
10. The method according to claim 9, wherein the authorizer and the process to be verified belong to the same trusted platform, the authorizer is a scheduling process for task scheduling or a business process for executing a task, and the process to be verified is a message routing process for message passing.
11. The method of claim 10, wherein the process to be verified belongs to a centralized platform, wherein the authorized party belongs to a party participating in a federal learning task through the centralized platform, and wherein the process to be verified is a message routing process deployed on the centralized platform and used for message passing between the centralized platform and the authorized party.
12. The method of claim 10, wherein determining whether the process to be authenticated is a first boot comprises:
and judging whether a record of the process with the same name of the process to be verified exists or not according to a legal authorization identifier list stored by the authorization party, if so, judging that the process to be verified is not started for the first time and the authorization identifier of the process with the same name is a previous authorization identifier corresponding to the process to be verified.
13. The method according to claim 10, wherein the authorizer sends a security authentication request to the process to be authenticated by sending a ping signal, and the process to be authenticated feeds back the latest authorization identifier of the process to be authenticated by sending a pong signal.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111224566.9A CN113946815B (en) | 2021-10-21 | 2021-10-21 | Authorization method for federal learning and privacy computation |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111224566.9A CN113946815B (en) | 2021-10-21 | 2021-10-21 | Authorization method for federal learning and privacy computation |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113946815A CN113946815A (en) | 2022-01-18 |
| CN113946815B true CN113946815B (en) | 2022-08-26 |
Family
ID=79331729
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111224566.9A Active CN113946815B (en) | 2021-10-21 | 2021-10-21 | Authorization method for federal learning and privacy computation |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113946815B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111125677A (en) * | 2019-12-24 | 2020-05-08 | 苏州思必驰信息科技有限公司 | Equipment authorization method and system |
| CN113411311A (en) * | 2021-05-20 | 2021-09-17 | 联合汽车电子有限公司 | ECU (electronic control Unit) diagnosis authorization verification method, storage medium and system |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106599676A (en) * | 2016-12-22 | 2017-04-26 | 北京元心科技有限公司 | Trusted process identification method and device |
| CN109426591B (en) * | 2017-09-04 | 2021-01-01 | 武汉斗鱼网络科技有限公司 | Method and equipment for guarding multiple processes of windows single program |
| CN112073400A (en) * | 2020-08-28 | 2020-12-11 | 腾讯科技（深圳）有限公司 | Access control method, system and device and computing equipment |
| CN112800436B (en) * | 2021-04-07 | 2021-06-29 | 支付宝(杭州)信息技术有限公司 | Data authorization method and device and electronic equipment |
-
2021
- 2021-10-21 CN CN202111224566.9A patent/CN113946815B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111125677A (en) * | 2019-12-24 | 2020-05-08 | 苏州思必驰信息科技有限公司 | Equipment authorization method and system |
| CN113411311A (en) * | 2021-05-20 | 2021-09-17 | 联合汽车电子有限公司 | ECU (electronic control Unit) diagnosis authorization verification method, storage medium and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113946815A (en) | 2022-01-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111090876B (en) | Contract calling method and device | |
| US11651109B2 (en) | Permission management method, permission verification method, and related apparatus | |
| EP3499847B1 (en) | Efficient validation of transaction policy compliance in a distributed ledger system | |
| CN110490305B (en) | Machine learning model processing method based on block chain network and node | |
| CN110537355B (en) | Consensus based on secure blockchains | |
| Yavari et al. | An improved blockchain-based authentication protocol for IoT network management | |
| US11429967B2 (en) | Mechanism for efficient validation of finality proof in lightweight distributed ledger clients | |
| WO2018112946A1 (en) | Registration and authorization method, device and system | |
| CN112003858B (en) | Block chain-based platform docking method, electronic device and storage medium | |
| US10756896B2 (en) | Trustless account recovery | |
| Rahman et al. | Blockchain-based ai-enabled industry 4.0 cps protection against advanced persistent threat | |
| CN111292174A (en) | Tax payment information processing method and device and computer readable storage medium | |
| CN111294356A (en) | Block chain based method and system for organizing node uplink | |
| US20210241270A1 (en) | System and method of blockchain transaction verification | |
| CN110619222A (en) | Authorization processing method, device, system and medium based on block chain | |
| CN114239046A (en) | Data sharing method | |
| CN114978635A (en) | Cross-domain authentication method and device, and user registration method and device | |
| CN111585946B (en) | Cryptographic master profile control and transaction arbitration | |
| CN113946815B (en) | Authorization method for federal learning and privacy computation | |
| CN114065238B (en) | Data management method and device and electronic equipment | |
| CN113676494B (en) | Centralized data processing method and device | |
| CN113014540B (en) | Data processing method, device, equipment and storage medium | |
| CN112422534B (en) | Credit evaluation method and equipment for electronic certificate | |
| CN112231731A (en) | Loosely coupled blockchain transaction method and blockchain link point | |
| CN113761513A (en) | Data processing method, device, equipment and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |