Digital token authentication method based on Profinet protocol

Abstract

The invention discloses a digital token authentication method based on a Profinet protocol, and the method comprises the steps: when an RPC client needs to initiate an RPC request to an RPC server, an authentication request block is carried in a first RPC request message, the authentication request block comprises authentication information of a user, the authentication information comprises a user name, a password and an authentication attribute, and after the RPC server receives the RPC request, the authentication information is sent to the RPC server; the user name and the password in the authentication request block are verified, and after verification is passed, the RPC server carries an authentication response block in an RPC response message for response; according to the method, a security authentication method and a signature and verification method of the security token for the RPC server record data access channel are realized, meanwhile, a traditional Profinet protocol is compatible, and an RPC service supporting a security token function or a traditional RPC service without authentication control and access control can be provided according to specific security level requirements, so that the security of the RPC server record data access channel is ensured, and the security of the RPC server record data access channel is ensured. And two modes of long-acting tokens and limited tokens are supported, and flexible token timeliness is provided for different service requirements.

Description

Technical Field

[0001] The invention belongs to the technical field of network communication, and in particular relates to a digital token authentication method based on the Profinet protocol. Background Art

[0002] PROFINET is an industrial Ethernet standard designed to provide high-speed and reliable network communication for industrial automation. It is developed and maintained by the PROFIBUS & PROFINET International (PI) organization. PROFINET integrates real-time communication and is suitable for a wide range of applications in factory automation and process automation. In the PROFINET network, the participating devices are divided into four roles: IO controller (IO controller, referred to as IOC), IO device (IO Device, referred to as IOD), IO monitor (IO Suppervisior, referred to as IOS), and Negnieering Station (NS). The relationship between the four is as follows: Figure 1 ES sends the online configuration to IOC through the upper computer software. IOC establishes an IO application relationship with IOD through the RPC protocol, referred to as IOCAR (IOApplicationRelationship). In the application relationship, three communication relationships between the master station and the slave station are established, which are divided into IOCR, record CR, and AlarmCR, representing IO communication relationship, record data communication relationship, and alarm communication relationship, respectively, and use RTC, RPC, and RTA protocols for interaction.

[0003] The defect of PROFINET communication relationship is that it only matches the configuration information and there is no security authentication mechanism. Figure 2 As shown, first, IOC sends a DCPidentify request broadcast message according to the station name configuration of the host computer in ES. After IOD receives the discovery request message, it responds with DCPidentify. After IOC compares the device information in the response message with the ES configuration information, it starts the CM process through the RPC protocol, establishes the IOCAR communication relationship, and performs parameter configuration read and write operations on the IOD slave station. When the ApplRedy flag is completed, IOC and IOD start to interact with RTC synchronous real-time periodic data. If an alarm occurs in IOD, it is reported through the RTA asynchronous real-time channel. In the above process, IOD did not check the identity information of the RPC, RTC, and RTA initiators, which means that permission control cannot be performed, and non-administrators can also read and write device information through RPC, manipulate process data through RTC, and send and receive alarm information through RTA. This poses a security risk, especially as IOT gradually moves towards integration. Summary of the invention

[0004] The purpose of the present invention is to provide a method for digital token authentication based on the Profinet protocol, which realizes security authentication between the RPC client and the RPC server by extending specific functional blocks in the Profinet protocol stack, thereby improving the security and reliability of the industrial automation network environment to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention adopts the following technical solution: a method for digital token authentication based on the Profinet protocol, the method comprising the following steps: a) When the RPC client needs to initiate an RPC request to the RPC server, the authentication request block is carried in the first RPC request message; b) the authentication request block contains the user's authentication information, including user name, password and authentication attributes; c) After receiving the RPC request, the RPC server verifies the username and password in the authentication request block; d) After verification, the RPC server responds with an authentication response block in the RPC response message.

[0006] Preferably, the block type of the authentication request block is 0x011B, and the block length thereof includes the basic part plus the character string length of the user name and the password.

[0007] Preferably, the authentication request block comprises authentication attributes for indicating expected token attributes.

[0008] Preferably, the method further comprises the steps of: e) The RPC server generates and returns an authentication response block, which contains the authentication status and the generated user token.

[0009] Preferably, the user token is generated based on the information in the authentication request and a specified algorithm, and has timeliness control.

[0010] Preferably, the method further comprises the steps of: f) For the authentication request block in the RPC request, the RPC server decides whether to generate a long-term token or a limited-term token based on the long-term tag in the authentication request.

[0011] Preferably, for long-term tokens, the RPC server also needs to detect the connection status with the RPC client.

[0012] Preferably, the method further comprises the steps of: g) For limited-time tokens, the RPC server must also monitor the validity period of the token and destroy the corresponding authentication information digest when it expires.

[0013] Preferably, the method further comprises the steps of: h) After the token is generated, the RPC server uses the specified encryption algorithm to sign the authentication information summary based on the token type and the information in the authentication request to generate a user token.

[0014] Preferably, the method further comprises the steps of: i) The RPC server decides whether to execute the authentication request and response process based on whether the security token function is enabled.

[0015] Technical effects and advantages of the present invention: Compared with the prior art, the digital token authentication method based on the Profinet protocol proposed by the present invention has the following advantages: In the present invention, when the RPC client needs to initiate an RPC request to the RPC server, the authentication request block is carried in the first RPC request message. After receiving the RPC request, the RPC server verifies the user name and password in the authentication request block. After the verification is passed, the RPC server carries the authentication response block in the RPC response message for response; a security authentication method for recording data access channels on the RPC server, a signature and verification method for security tokens are implemented; at the same time, the present invention is compatible with the traditional Profinet protocol, and can provide RPC services that support security token functions or traditional RPC services without authentication control and access control according to specific security level requirements; it also supports two modes, long-term tokens and limited-term tokens, and provides flexible token validity for different business needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a relationship diagram of IO controller, IO device, IO monitor and engineer station in the prior art; Figure 2 It is a PROFINET communication relationship diagram in the prior art; Figure 3 A flowchart of digital token authentication of the present invention; Figure 4 This is the Token checking sub-flow chart of the present invention; Figure 5 This is the Auth check sub-flow chart of the present invention; Figure 6 Generate a sub-flow chart for the Token of the present invention; Figure 7 This is the Token aging sub-flow chart of the present invention. DETAILED DESCRIPTION

[0017] The following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments. The specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0018] The present invention provides a method for digital token authentication based on the Profinet protocol, the method comprising the following steps: a) When the RPC client needs to initiate an RPC request to the RPC server, the authentication request block is carried in the first RPC request message; further, the BlockType of the authentication request block is set to 0x011B, which is within the reserved interval specified in the IEC61158-6-10 standard. This block contains the user's authentication information, such as user name, password, and authentication attributes. When the RPC client attempts to establish a connection with the RPC server, the authentication request block is carried in the first RPC request message. After receiving the request, the RPC server verifies the user name and password, and decides whether to grant authentication based on the authentication attributes.

[0019] b) The authentication request block contains the user's authentication information, including a user name, a password and authentication attributes; further, the block type of the authentication request block is 0x011B, and its block length includes the basic part plus the string length of the user name and password; in addition, the authentication request block contains authentication attributes for indicating the expected token attributes.

[0020] c) After receiving the RPC request, the RPC server verifies the username and password in the authentication request block; d) After verification, the RPC server responds with an authentication response block in the RPC response message. Specifically, the authentication response block is sent by the RPC server to the RPC client after the authentication request is passed, and contains the authentication status and the generated user token. If the authentication is successful, the "Status" field in the authentication response block is set to "1", and the currently used encryption algorithm type and user token "UserToken" are filled in.

[0021] Among them, Status indicates the user token authentication status. In the authentication request message, this field is fixed to 0. In the authentication response message, it is usually displayed as the return value of the authentication request. After the authentication is successful, this field is filled with "1"; after the authentication fails, this field is filled with "0".

[0022] e) The RPC server generates and returns an authentication response block, which includes the authentication status and the generated user token; further, the generation of the user token is based on the information in the authentication request and the specified algorithm, and has timeliness control.

[0023] f) For the authentication request block in the RPC request, the RPC server decides whether to generate a long-term token or a limited-term token based on the long-term tag in the authentication request; further, for the long-term token, the RPC server also needs to detect the connection status with the RPC client.

[0024] g) For limited-time tokens, the RPC server must also monitor the validity period of the token and destroy the corresponding authentication information digest when it expires.

[0025] h) After the token is generated, the RPC server uses the specified encryption algorithm to sign the authentication information summary based on the token type and the information in the authentication request to generate a user token.

[0026] i) The RPC server decides whether to execute the authentication request and response process based on whether the security token function is enabled. Furthermore, the RPC server generates a security token after the authentication request is passed. The process of generating a token includes checking the storage capacity of the hash table, determining whether it is a long-term token, and checking whether the operation type of the RPC message is connect(0). If all conditions are met, the RPC server will create an authentication information summary "AuthInfoEntry", record the client information, and generate a user token "UserToken" through a specified encryption algorithm.

[0027] In addition, to maintain the validity of the token, the system periodically checks whether the generated token has expired or is invalid. Long-term tokens will check the connection status with the client. If the connection is interrupted, the token is considered invalid. For limited-term tokens, it checks whether the current time exceeds the set expiration timestamp. If the token expires, the relevant authentication information summary is destroyed.

[0028] The present invention enhances the security of data access recorded by the RPC server by introducing a security token mechanism. At the same time, it is compatible with the traditional Profinet protocol, and it can be selected whether to enable the security token function according to actual needs. It supports long-term tokens and limited-term tokens to meet the needs of different business scenarios. In addition, the present invention supports multiple signature algorithms, which enhances the flexibility and security of the system. It effectively solves the problem of lack of security authentication mechanism in the prior art. By extending specific functional blocks in the Profinet protocol stack, security authentication between the RPC client and the RPC server is realized, and the security and reliability of the industrial automation network environment are improved.

[0029] The following will be described in detail with reference to the accompanying drawings: like Figure 3 As shown, the main process of digital token authentication is: 1) The main process first executes the Token check sub-process, which will check the "User Token Data" block and return true or false.

[0030] 2) If the token check is passed, it returns true and the token verification is successful.

[0031] 3) If the Token check sub-process fails, it returns false, and the next process continues to enter the Auth check sub-process, which will check the authentication request information and return true or false.

[0032] 4) If the Auth check passes, it returns true, and the next process enters the Token generation sub-process, which will generate a new "UserToken" based on the client authentication information and return true or false.

[0033] 5) Auth check fails, returns false, authentication failed.

[0034] 6) Token is generated successfully, returns true, and authentication is successful.

[0035] 7) Token generation fails, returns false, and authentication fails.

[0036] 8) Indication of successful authentication result: "PNIOStatus" returns "SUCCESS" and the four-tuple should be set to "[0x0, 0x0, 0x0, 0x0]", indicating that the authentication is successful and the user RPC operation "PROFINETIOServiceReqPDU" will be allowed to execute. If other errors occur during the processing, the newly generated error information will overwrite the "PNIOStatus" four-tuple and perform an RPC message response.

[0037] 9) Authentication failure result description: the user RPC operation "PROFINETIOServiceReqPDU" will not be executed, the RPC message will be directly responded, "PNIOStatus" returns "ERROR", and the four-tuple will be returned according to the error handling results of different sub-process stages.

[0038] like Figure 4 As shown, the Token check sub-process is: 1) Check whether the RPC message carries the "UserTokenData" block.

[0039] 2) Carry the "UserTokenData" block, return true, and extract the "UserToken" for hash table lookup.

[0040] 3) The "UserTokenData" block is not carried, the output is false, and the "PNIOStatus" quadruple is set to "[ErrorCode, 0x81, 0x1B, 0x0]", indicating that the user token does not exist. The "ErrorCode" is determined by the specific RPC request message type and uses the error code defined in the corresponding standard.

[0041] 4) If the hash table search is successful, the result is true and the "UserToken" is checked to see if it has timed out.

[0042] 5) Hash table lookup fails, the output is false, and the "PNIOStatus" quadruple is set to "[ErrorCode, 0x81, 0x1B, 0x0]", indicating that the user token does not exist.

[0043] 6) "UserToken" has timed out, returns true, outputs false, and the "PNIOStatus" quadruple is set to "[ErrorCode, 0x81, 0x1B, 0x1]", indicating that the user token has expired.

[0044] 7) "UserToken" has not timed out, returns false, outputs true, and the "PNIOStatus" quad is set to "[0x0, 0x0, 0x0, 0x0]".

[0045] 8) Output "true" result description, the "PNIOStatus" quad is filled according to the above processing results.

[0046] 9) Output "false" result description, "PNIOStatus" quad is filled according to the above processing results.

[0047] like Figure 5 As shown, the Auth check sub-process is: 1) Check whether the RPC message carries the "AuthenticationReq" block.

[0048] 2) If the "AuthenticationReq" block is carried, it returns true, and the server extracts the "UserName" data to find the local user information. UserName is the plain text string of the user name in the authentication request block, which is used for user search during the authentication process and must be less than 32 bytes in length.

[0049] 3) If the "AuthenticationReq" block is not carried, the output is false and the "PNIOStatus" tuple should be set to "[ErrorCode, 0x81, 0x1A, 0x0]", indicating a user information error.

[0050] 4) If the user name is successfully searched, the system returns true and extracts the "Password" in the "AuthenticationReq" block to verify the user password. Password is the plain text password string in the authentication request block, which is used for password verification during the authentication process and must be less than 32 bytes in length.

[0051] 5) User name lookup fails, and the output is false. The "PNIOStatus" quadruple should be set to "[ErrorCode, 0x81, 0x1A, 0x0]", indicating that the user information is wrong.

[0052] 6) If the user password verification succeeds, the output is true and the “PNIOStatus” quadruple should be set to “[0x0, 0x0, 0x0, 0x0]”.

[0053] 7) If the user password verification fails, the output is false and the "PNIOStatus" quadruple should be set to "[ErrorCode, 0x81, 0x1A, 0x0]", indicating that the user information is wrong.

[0054] 8) Output "false" result description, the "PNIOStatus" 4-tuple is filled according to the above processing results, the "Status" field in the authentication response block "AuthenticationResp" should be set to "0", the "UserTokenLength" field should be set to "0", and the "UserToken" field is not carried.

[0055] 9) The output of "true" result indicates that the "PNIOStatus" tuple should be set to "[0x0, 0x0, 0x0, 0x0]", and the authentication response block "AuthenticationResp" will be filled in the Token generation subprocess.

[0056] like Figure 6 As shown, the Token generation sub-process is: 1) Check whether the number of hash nodes stored in the RPC server hash table has reached the storage capacity limit.

[0057] 2) If the capacity check passes, return true to determine whether the authentication requests a long-term token and whether the "longterm" bit in the authentication request block "AuthenticationReq" is set to "0x1".

[0058] 3) If the capacity check fails, the output is false and the "PNIOStatus" quadruple should be set to "[ErrorCode, 0x81, 0x1A, 0x2]", indicating an insufficient token capacity error.

[0059] 4) If "longterm" is "0x1", it returns true and applies for a long-term token. It is necessary to determine whether it is a "conncet" type message and whether the "Operation" field of the RPC message operation type is "0".

[0060] 5) If "longterm" is "0x0", it returns false, applies for a normal token, creates an authentication information summary "AuthInfoEntry", records the RPC client information, including the user name information "UserName", the RPC client MAC address information "hostMac", records the creation timestamp "bornTime", and records the expiration timestamp "expireTime".

[0061] 6) If the RPC message operation type is connect(0), it returns true, creates the master information summary "AuthInfoEntry", and records the client information.

[0062] 7) If the RPC message operation type is not "connect(0)", the output is false, and the "PNIOStatus" tuple should be set to "[ErrorCode, 0x81, 0x1A, 0x1]", indicating an authentication attribute error.

[0063] 8) After the master station information summary "AuthInfoEntry" is created, the corresponding encryption algorithm library function is called through the "algorithm" encryption algorithm type to sign the "AuthInfoEntry" and generate a fixed-digit hexadecimal signature "UserToken". The Hash subscript is obtained after calculation through the Hash algorithm, stored in the Hash table, and the output is true. The "PNIOStatus" quadruple should be set to "[0x0, 0x0, 0x0, 0x0]". Among them, algorithm represents the signature algorithm used in the user token generation process. In the authentication request message, it represents the signature algorithm expected by the client. After receiving it, the server will compare it according to the security policy. If the requested signature algorithm is in the support list, the expected signature algorithm is used for signing, and this field is filled in the response message; if the expected signature algorithm is not supported, the default signature algorithm HMAC-SHA256 is used for signing, and this field is filled in the response message. Two mainstream signature algorithms are supported, namely HMAC-SHA1 and HMAC-SHA256. Both are highly secure message authentication methods that can generate hexadecimal signature data of fixed length and are widely used in network security and data protection fields to perform message integrity verification and identity authentication.

[0064] The key "EKey" of the HMAC-SHA1 and HMAC-SHA256 signature algorithms is controlled by the RPC server. The signature token can only be verified on the RPC server. The key "EKey" is not published. The user token "UserToken" is signed using the authentication information summary "authInfoEntry" structure. The signature calculation formula is as follows.

[0065] HMAC_SHA1 formula: UserToken = HMAC_SHA1(EKey, authInfoEntry); HMAC_SHA256 formula: UserToken = HMAC_SHA256(EKey, authInfoEntry).

[0066] 9) Output "false" indicates that the "PNIOStatus" 4-tuple is filled in according to the above processing results, the "Status" field in the authentication response block "AuthenticationResp" should be set to "0", the "UserTokenLength" field should be set to "0", and the "UserToken" field is not carried.

[0067] 10) The output "true" indicates that the "PNIOStatus" quadruple should be set to "[0x0, 0x0, 0x0, 0x0]", the "Status" field in the authentication response block "AuthenticationResp" should be set to "1", the "algorithm" field is filled with the current encryption algorithm, the "UserToken" field is filled, and the "UserTokenLength" field is the actual byte length of "UserToken".

[0068] userInfoEntry structure: "userInfoEntry" represents the authentication information summary. This structure is generated after the authentication is passed and stores user information. It serves as the data source for generating the user token "UserToken". It contains user identification information, the master station MAC address, the information summary generation time and the expiration time, as shown in Table 1.

[0069]

[0070] Host connection disconnected: "Host connection" means the RPC connection established between the IO slave (device) and the IO master (controller). The above text indicates that in the token aging process, if the token is detected as a long-term token, the long-term token will be aged and destroyed according to the fact that the RPC connection between the IO slave (device) and the IO master (controller) is disconnected.

[0071] like Figure 7 As shown, the Token aging sub-process is: 1) The fixed cycle of the timer is 5 seconds, and the timer should start to trigger after the device is started.

[0072] 2) Timer input, traverse the Hash table and extract the "UserTokenEntry" instance.

[0073] 3) The "UserTokenEntry" instance is extracted successfully, and the "longterm" flag in the instance is checked to see if it is set. Longterm indicates whether the user token is a long-term token. Long-term tokens are not subject to the Token aging process. Long-term tokens are destroyed only when the RPC connection is actively or passively disconnected. Ordinary tokens are subject to the Token aging process. If the token expires, it will be destroyed. The token life cycle "keepTime" is controlled by the RPC server. The default is 300 seconds. The administrator can control it according to different scenarios. The allowed configuration range is 60 seconds to 43200 seconds.

[0074] In the authentication request message, this field indicates whether the client expects to use a long-term token. The server will check after receiving the authentication request. If the attribute is "1" and the RPC message type is connect, the server generates a long-term token and fills this field with "1" in the authentication response message. If the RPC message type is other types, the server generates a common token and fills this field with "0" in the authentication response message. If the attribute is "0" in the authentication request message, the server does not determine the RPC message type, generates a common token, and fills this field with "0" in the response message.

[0075] 4) If the instance extraction fails, it means that the hash table has been traversed, the token aging of this cycle has been completed, the timer exits, and waits for the next cycle timer input.

[0076] 5) Check that the "longterm" flag is set, extract the "UserTokenEntry" information, and check whether the connection between this end and the RPC client "hostMac" AR is interrupted.

[0077] 6) Check that the "longterm" flag is not set and check whether the "expireTime" in the "UserTokenEntry" information has expired.

[0078] 7) Check that the connection between this end and the RPC client "hostMac" AR has been disconnected, determine that the long-term token "UserToken" has expired, and destroy the "UserTokenEntry" instance.

[0079] 8) Check that the local end and the RPC client "hostMac" AR connection are not interrupted, determine that the long-term token "UserToken" has expired, and extract the next "UserTokenEntry" instance.

[0080] 9) Check that the current device time is greater than the "expireTime" timestamp in the "UserTokenEntry" information, determine that the "UserTokenEntry" information has expired, and immediately destroy the UserTokenEntry instance.

[0081] 10) Check that the current device time is less than or equal to the expireTime timestamp in the UserTokenEntry information, determine that the "UserTokenEntry" information has not expired, and extract the next UserTokenEntry instance.

[0082] 11) The timer process ends when the device stops.

[0083] Terminology Note: IO Controller: (Input Output Controller) Input and output controller is the main device or master station (such as PLC, industrial computer, etc.) responsible for communicating with IO devices. It controls IO devices and processes data related to them.

[0084] IO Device: (Input Output Device) Input and output devices refer to slave devices or slave stations that interact with IO controllers (such as sensors, distributed input and output IO, servo drives, etc.). These devices are the most basic acquisition or execution units, supplying or consuming data.

[0085] Eng: (Engineering Message) Engineering station message refers to the configuration or diagnostic communication between the engineering station and the main station.

[0086] IO AR: (Input Output Application Relationship) is used to describe the communication relationship between the IO controller and the device. During the connection establishment process, the IO controller and the device will determine the input and output communication relationship, alarm communication relationship and record data communication relationship between the two, and define the characteristics and process of communication.

[0087] Sup / Imp AR: (Supervisor Implicit Application Relationship) monitor implicit application relationship, the application relationship between IO monitoring devices and devices, used for implicit communication for device diagnosis or data monitoring purposes.

[0088] IO Supervisor: (Input Output Supervisor) An input and output monitor used to monitor the status and diagnostic information of IO devices (such as human-computer interaction screens, display terminals, etc.).

[0089] Engineering Station: Engineering Station refers to a set of industrial application software tools used to configure, automate programming, monitor and maintain automation systems or a computer with the above software installed.

[0090] Finally, it should be noted that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for digital token authentication based on Profinet protocol, characterized in that: The method comprises the following steps: a) When the RPC client needs to initiate an RPC request to the RPC server, the authentication request block is carried in the first RPC request message; b) the authentication request block contains the user's authentication information, including user name, password and authentication attributes; c) After receiving the RPC request, the RPC server verifies the username and password in the authentication request block; d) After verification, the RPC server responds with an authentication response block in the RPC response message.

2. A method for digital token authentication based on Profinet protocol according to claim 1, characterized in that: The block type of the authentication request block is 0x011B, and its block length includes the basic part plus the character string length of the user name and password.

3. A method for digital token authentication based on Profinet protocol according to claim 1, characterized in that: The authentication request block contains authentication attributes for indicating the expected token attributes.

4. The method for digital token authentication based on Profinet protocol according to claim 1, characterized in that: Also includes the steps: The RPC server generates and returns an authentication response block, which contains the authentication status and the generated user token.

5. A method for digital token authentication based on Profinet protocol according to claim 4, characterized in that: The generation of the user token is based on the information in the authentication request and the specified algorithm, and has timeliness control.

6. A method for digital token authentication based on Profinet protocol according to claim 4, characterized in that: Also includes the steps: For the authentication request block in the RPC request, the RPC server decides whether to generate a long-term token or a limited-term token based on the long-term tag in the authentication request.

7. A method for digital token authentication based on Profinet protocol according to claim 6, characterized in that: For long-term tokens, the RPC server also needs to detect the connection status with the RPC client.

8. A method for digital token authentication based on Profinet protocol according to claim 6, characterized in that: Also includes the steps: For limited-time tokens, the RPC server also needs to monitor the validity period of the token and destroy the corresponding authentication information digest when it expires.

9. A method for digital token authentication based on Profinet protocol according to claim 8, characterized in that: Also includes the steps: After the token is generated, the RPC server uses the specified encryption algorithm to sign the authentication information summary based on the token type and the information in the authentication request to generate a user token.

10. A method for digital token authentication based on Profinet protocol according to claim 9, characterized in that: Also includes the steps: The RPC server decides whether to execute the authentication request and response process based on whether the security token function is enabled.

Images