A machine learning-based distributed digital identity internet of things device cross-domain authentication method

Abstract

The application provides a machine learning-based distributed digital identity Internet of Things equipment cross-domain authentication method, relates to the technical field of Internet of Things security and identity authentication, generates equipment authentication portraits through trust quantification evaluation, dynamically allocates path weights by using a neural network, adaptively converts credentials and keeps the cryptographic strength from being degraded, and finally establishes distributed trust through chain verification and back propagation. In this way, the cross-domain authentication delay and failure rate are effectively reduced, the risk of cryptographic strength degradation is avoided, and a dynamic and accumulative trust relationship is formed, thereby systematically solving the technical problems of incompatible credential formats, inefficient path selection and security strength attenuation in Internet of Things cross-domain authentication.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security and identity authentication technology, and more specifically, to a cross-domain authentication method for distributed digital identity IoT devices based on machine learning. Background Technology

[0002] With the large-scale deployment of Internet of Things (IoT) technology and its deep penetration into typical applications such as smart homes and the Industrial Internet, the demand for cross-domain interoperability of IoT devices is becoming increasingly urgent. Devices (such as smart locks, cameras, and sensors) from different manufacturers or management domains (called authentication domains) often use their own independently designed identity authentication protocols, encryption algorithms, and identity credential formats, resulting in the need for heterogeneous conversion of identities and permissions for cross-domain device linkage. Existing cross-domain authentication technologies can be mainly divided into three categories: authentication bridging schemes based on centralized proxies, which introduce a third-party trusted domain as an authentication anchor point to uniformly convert credentials from different domains; cross-domain single sign-on schemes based on federated identities (such as SAML and OAuth), which achieve mutual recognition of credentials through a pre-established trust alliance between domains; and decentralized identity (DID) schemes based on distributed ledgers, which register device identities on the blockchain and verify them on demand by different domains. The above technologies are feasible to a certain extent in conventional cross-domain scenarios, but they expose significant limitations when dealing with resource-constrained IoT devices (weak computing power, small memory, and battery power) and facing large-scale concurrent authentication requests. Specifically, centralized proxy schemes have single point of failure risks and authentication bottlenecks, federated identity schemes require each domain to complete complex security policy negotiations in advance and are difficult to adapt to dynamic topology changes, and DID schemes are unsuitable for real-time sensitive scenarios due to high on-chain verification latency and large device computing overhead.

[0003] Existing cross-domain authentication methods face three core challenges in addressing the practical cross-domain access of IoT devices. First, the heterogeneity of identity credential formats and cryptographic parameters (encryption algorithms, key lengths, hash bits, signature schemes) across authentication domains means that traditional fixed-mapping conversion methods are typically backward compatible with low-strength algorithms, leading to passive degradation of cryptographic strength during cross-domain authentication and weakening end-to-end security. Second, cross-domain authentication path selection often employs static routing or shortest-path algorithms based on hop count, lacking dynamic awareness of real-time load on authentication domains, historical authentication success rates, and the device's own trustworthiness. This easily causes authentication requests to congest along low-quality paths, resulting in high latency and high failure rates. Third, in existing chained verification schemes, intermediate domains typically only verify the predecessor signature without global consistency checks, and authentication results are not effectively fed back to each domain to accumulate trust evidence, making it difficult to form distributed dynamic trust relationships. In conclusion, the field of cross-domain authentication technology urgently needs a method that can be compatible with heterogeneous credential formats, dynamically select the optimal authentication path, maintain cryptographic strength without degradation, and establish distributed trust relationships. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a machine learning-based distributed digital identity IoT device cross-domain authentication method. This method can, to some extent, solve the problems of incompatible credential formats and inefficient authentication path selection when authentication requests are forwarded across multiple domains due to differences in identity credential formats among authentication domains and limitations in device computing power. This results in high cross-domain authentication failure rates and excessively long authentication delays.

[0005] According to one aspect of the present invention, a cross-domain authentication method for distributed digital identity IoT devices based on machine learning is provided, comprising: Receive cross-domain authentication requests from source domain IoT devices, extract device identity and target domain information from the requests, perform trust quantification assessment of device identity based on historical successful authentication records, and generate a device authentication profile containing trust scores. Based on the trust score and target domain information in the device authentication profile, the available authentication paths are dynamically weighted using a pre-trained inter-domain path prediction model, and the authentication path with the highest weight is selected as the preferred authentication path. The source domain identity credentials are adaptively converted according to the credential format requirements of each intermediate domain in the preferred authentication path, and the cryptographic strength of identity verification is maintained without degradation during the conversion process, forming a cross-domain credential chain that is compatible with multiple formats. The cross-domain credential chain enables chained verification and transmission between authentication domains. Once the target domain completes final identity verification, the authentication result is propagated back to the source domain, establishing a distributed cross-domain authentication trust relationship.

[0006] Furthermore, a trust level value is used to quantitatively evaluate the trustworthiness of the device identity identifier. The trust level value is calculated as follows: ; in, This represents the device trust level value. For consecutive successful authentications, Total number of authentications As a success rate weighted index, The time stability decay coefficient, The standard deviation of the certification time interval. This represents the average authentication time interval. This represents the actual number of resource access types. This represents the expected number of resource access types. This is a resource access matching index. This represents the number of abnormal events triggered. This represents the total number of events triggered. For historical continuity gain coefficient, This represents the current number of consecutive normal certification cycles. This is a continuous adjustment constant.

[0007] Furthermore, the inter-domain path prediction model receives device trust scores, source domain identifiers, and target domain identifiers as inputs, searches for all reachable path sequences based on the inter-domain connection matrix, and extracts the latency, success rate, and number of nodes parameters for each path. Then, it uses a pre-trained three-hidden-layer fully connected neural network to output latency weight coefficients, success rate weight coefficients, and number of nodes weight coefficients. Finally, it calculates the score for each path according to the path comprehensive weight scoring formula and selects the path with the highest score as the preferred authentication path.

[0008] Furthermore, the comprehensive weighted scoring formula for the path is shown in the following equation: ; in, The path is scored based on its overall weight. This is the time delay weighting coefficient. This is the success rate weighting coefficient. The weighting coefficient for the number of nodes. Total authentication latency for the path. For reference, the certification delay For the overall success rate of the path, This represents the number of certified nodes on the path. To minimize the number of nodes, This represents the maximum number of nodes.

[0009] Furthermore, the adaptive transformation that does not degrade cryptographic strength includes the following steps: The system reads the encryption algorithm and key length, hash algorithm and output length, and signature algorithm and key length used by the source domain credential, and queries the list of algorithms supported by each intermediate domain and their required security strength. For each algorithm type, it selects the algorithm parameters with the highest security strength that are supported by both the source and intermediate domains as the parameters after conversion. If the intermediate domain does not support an algorithm with a strength no lower than that of the source domain, it rejects the conversion and notifies the inter-domain path prediction model to reselect another path that does not include the intermediate domain. According to the preset inter-domain credential mapping rule base, it converts the identity identifier and permission fields in the source domain credential into the format required by the intermediate domain. It then uses the negotiated encryption algorithm, hash algorithm, and signature algorithm to re-encrypt the converted credential content, calculate the digest, and generate a digital signature.

[0010] Furthermore, the inter-domain credential mapping rule base is a data table structure containing four fields: algorithm type, key length, hash bit length, and signature length. The cryptographic parameters of the source domain credential and each intermediate domain credential are filled in respectively. Then, the numerical relationship between the source domain and each intermediate domain in the three dimensions of key length, hash bit length, and signature length is compared one by one. The comparison results are marked as three adjustment strategies: maintaining the source domain parameters, upgrading to the intermediate domain requirements, or downgrading. This forms a cryptographic strength comparison table containing specific numerical comparison results and explicit adjustment instructions.

[0011] Furthermore, the chained verification transmission includes: The cross-domain credential chain is sent to each intermediate domain in sequence according to the preferred authentication path. Each intermediate domain verifies the credential corresponding to its domain. After successful verification, the domain's private key is used to sign the verification information of the domain and the global characteristics of the current credential chain. The signature result is added to the verification record of the credential chain and then forwarded to the next domain. After receiving the credential chain, the target domain verifies the validity of the signatures of each intermediate domain in the verification record and the rationality of the time sequence. After the verification is successful, the final identity authentication is completed, and an authentication result data packet containing the authentication success flag, domain identifier, timestamp, global features of the credential chain, and the signature of the target domain is generated. The target domain propagates the authentication result data packet in reverse order of the verification record to each intermediate domain and the source domain. Each domain that receives the result data packet first verifies the consistency of the target domain signature and the global characteristics of the credential chain. After the verification is successful, the successful authentication record is stored in the local trust relationship database to realize a distributed cross-domain authentication trust relationship.

[0012] According to another aspect of the present invention, a machine learning-based distributed digital identity IoT device cross-domain authentication system is provided, comprising: The device trust assessment and profile generation module is used to receive cross-domain authentication requests, extract device identity and target domain information, perform quantified trust assessment of the device based on historical authentication records, and generate a device authentication profile containing trust scores. The dynamic path selection module is used to dynamically assign weights to available authentication paths based on the trust score and target domain information in the device authentication profile, and select the authentication path with the highest weight as the preferred authentication path. The credential adaptive conversion module is used to adaptively convert the source domain identity credentials according to the credential format requirements of each intermediate domain in the preferred authentication path, and maintain the cryptographic strength without degradation during the conversion process, forming a cross-domain credential chain that is compatible with multiple formats. The chain verification and trust propagation module is used to perform chain verification and transmission between authentication domains through cross-domain credential chains. After the final identity verification is completed in the target domain, the authentication result is propagated back to the source domain to establish a distributed cross-domain authentication trust relationship.

[0013] Compared with existing technologies, the distributed digital identity IoT device cross-domain authentication method based on machine learning provided by this invention receives cross-domain authentication requests and performs multi-dimensional trust quantification evaluation of devices based on historical successful authentication records to generate device authentication profiles. Then, it uses a pre-trained inter-domain path prediction neural network to dynamically allocate latency, success rate, and node number weight coefficients based on device trust scores and real-time network load, selecting the authentication path with the highest comprehensive weight as the preferred path. Subsequently, it performs adaptive credential conversion according to the credential format requirements of each intermediate domain in the preferred path, and maintains cryptographic strength without degradation during the conversion process by negotiating the highest security strength algorithm supported by both parties. Finally, it performs chain verification and transmission between authentication domains through a cross-domain credential chain and backpropagates the authentication results to each domain to update the local trust database. In this way, on the one hand, the trust-driven dynamic path selection effectively reduces the end-to-end latency of cross-domain authentication and improves the success rate. On the other hand, the strength-preserving credential conversion avoids the risk of cryptographic strength degradation caused by backward compatibility in traditional mapping schemes. At the same time, the chain verification and backpropagation mechanism enable each authentication domain to accumulate cross-domain authentication trust evidence and form a distributed dynamic trust relationship. This systematically solves the technical problems of incompatible credential formats, inefficient path selection, and security strength decay in cross-domain authentication of IoT devices. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a flowchart of a machine learning-based distributed digital identity IoT device cross-domain authentication method according to an embodiment of the present invention.

[0015] Figure 2 This diagram illustrates an application scenario of the machine learning-based distributed digital identity IoT device cross-domain authentication method according to an embodiment of the present invention.

[0016] Figure 3 This is a comparison chart in three dimensions between the machine learning-based distributed digital identity IoT device cross-domain authentication method according to an embodiment of the present invention and existing methods. Detailed Implementation

[0017] Hereinafter, exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments of the present invention. It should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0018] Figure 1 This is a flowchart illustrating a machine learning-based distributed digital identity IoT device cross-domain authentication method according to an embodiment of the present invention. Figure 1 and Figure 2 As shown, the cross-domain authentication method for distributed digital identity IoT devices based on machine learning includes: S1: Receive cross-domain authentication requests from source domain IoT devices, extract device identity and target domain information from the requests, perform trust quantification assessment of device identity based on historical successful authentication records, and generate a device authentication profile containing trust scores. When a source domain IoT device needs to access resources in another authentication domain, the device sends an authentication request data packet containing encrypted identity credentials to the cross-domain authentication system via a network interface. If the authentication system successfully receives the authentication request data packet, it performs protocol parsing on the data packet, extracting the device's globally unique identifier from the request header field, and extracting the domain identifier information of the target authentication domain and the description information of the resource to be accessed from the request payload. After the system completes the extraction of the device identifier and target domain information, it matches and verifies the extracted identifier against the device registry within the system to confirm the legitimacy of the device's identity. If the device identifier fails the registry verification, the cross-domain authentication request is directly rejected and a failure event is recorded, without further trust assessment; if the verification passes, the system continues to parse the target domain information to determine the target path and required authentication protocol type for cross-domain authentication.

[0019] Furthermore, the system queries the historical authentication record database to retrieve all historical authentication event records associated with the device's identity identifier. If historical records exist, the system analyzes the frequency of successful authentication, the frequency of failed authentication, the regularity of authentication time intervals, and the occurrence patterns of abnormal authentication attempts during the historical authentication process. By comprehensively evaluating the stability, consistency, and predictability of the device's authentication behavior, the system assigns a corresponding trust score to the device. If the device exhibits a consistently stable authentication success pattern and its authentication behavior conforms to normal usage patterns, a higher trust score is assigned; if the device exhibits frequent authentication failures or performs authentication attempts during abnormal time periods, the trust score is correspondingly lowered. After the trust quantification assessment is completed, the system combines the trust score with the device's identity identifier, device type information, and historical authentication behavior feature tags to construct a device authentication profile that includes the device's trust level, behavior pattern classification, and risk assessment identifier.

[0020] If the system completes the retrieval of historical authentication event records for the device, it statistically analyzes the success or failure status of each authentication request within the most recent authentication cycle, calculating the ratio of consecutive successful authentications to the total number of authentications to quantify stability characteristics. After the device authentication behavior stability assessment is completed, the system extracts the timestamp information of each authentication request, analyzes whether the time interval between two adjacent authentication requests remains within the expected range under normal device operation, and checks whether the time of the authentication request initiation matches the device's preset working hours. If the device authentication time intervals show a regular distribution and the authentication initiation time highly coincides with the device's working hours, the system analyzes the triggering event type of the device authentication requests, checking whether each authentication is triggered by a reasonable business need, and whether the resource access type carried in the authentication request matches the device's functional requirements. When the system confirms that all device authentication requests are triggered by legitimate business needs and the resource access type matches the device's expected function, it assigns a high trust value to the device. When abnormal authentication time intervals, unreasonable authentication triggering events, or resource access types exceeding the device's normal functional range are detected, the trust value is reduced.

[0021] The trust level value is calculated as follows: ; in, This represents the device trust level value. For consecutive successful authentications, Total number of authentications As a success rate weighted index, The time stability decay coefficient, The standard deviation of the certification time interval. This represents the average authentication time interval. This represents the actual number of resource access types. This represents the expected number of resource access types. This is a resource access matching index. This represents the number of abnormal events triggered. This represents the total number of events triggered. For historical continuity gain coefficient, This represents the current number of consecutive normal certification cycles. This is a continuous adjustment constant.

[0022] Furthermore, a data mapping table is created using the device identifier as the index key. The trust score is used as a numerical field to establish a one-to-one binding relationship with the corresponding device identifier. Simultaneously, the predefined device type encoding segment in the device identifier is parsed, and the specific device type (e.g., smart lock, smart camera, smart sensor) is determined based on the encoding segment value. Once the device type is determined, the system reads the specific value of the trust score and maps it to the corresponding trust level identifier according to a preset trust level grading rule: high trust score corresponds to high trust level identifier, medium trust score corresponds to medium trust level identifier, and low trust score corresponds to low trust level identifier. If the device trust level identifier is generated, the system calculates the variance of the time interval between adjacent authentication requests in the device's historical authentication records to determine time regularity, calculates the number of authentication requests per unit time to determine the authentication frequency type, and calculates the maximum number of consecutive authentication failures to identify the failure mode. Devices with small time interval variance are marked as stable, those with large variance are marked as intermittent, and those with long consecutive failure sequences are marked as abnormal. Once the behavior pattern labels are assigned, the system queries the pre-stored security risk level table based on the device type, and combines it with the specific abnormal event types recorded in the device's historical authentication, such as abnormal time period authentication or abnormal frequency authentication, to generate a risk assessment field that includes the device type risk level and specific abnormal event identifier. Finally, the device identity identifier, trust score, trust level identifier, behavior pattern label and risk assessment field are combined to form a structured device authentication profile data record.

[0023] For example, the device authentication profile data structure is organized in key-value pairs. Taking a smart lock device as an example, the data structure includes a device identifier field storing the value "IoT_Lock_001234567890", a device type field storing the value "smart lock", and a trust score field storing the specific trust quantification value. After the basic fields are filled, the device trust level field stores a "high trust level" label based on the trust score range, the behavior pattern classification field stores a "stable" label based on the time interval variance calculation result, and the authentication frequency feature field stores a "normal frequency" label based on the statistical result of the number of authentications per unit time. If the smart lock has had abnormal authentication attempts during the early morning hours in its historical authentication, the risk assessment identifier field includes two risk tags: "time anomaly risk" and "physical access sensitivity," and the abnormal event type field records a specific description of the abnormal behavior of "abnormal time period authentication." When all field data is completely stored, a complete device authentication profile data record containing eight core fields is formed. Each field contains a clear data type and specific stored content, providing a structured decision data source for subsequent authentication path selection.

[0024] S2: Based on the trust score and target domain information in the device authentication profile, the available authentication paths are dynamically weighted using a pre-trained inter-domain path prediction model, and the authentication path with the highest weight is selected as the preferred authentication path. The specific value of the trust score field and the target domain identifier in the target domain information field of the device authentication profile are read. The trust score is used as the first input parameter, the target domain identifier as the second input parameter, and the current source domain identifier as the third input parameter, all of which are passed to the pre-trained inter-domain path prediction model. After receiving the three input parameters, the model searches for the corresponding path record in the inter-domain connection matrix based on the source domain identifier and the target domain identifier, and extracts all reachable path sequences from the source domain to the target domain. Each path sequence contains a list of intermediate domain identifiers traversed by the path and the corresponding hop count information. If the reachable path sequence extraction is complete, the model queries the historical authentication statistics table for each domain node in each path sequence to obtain the average authentication processing latency, authentication success rate, and current queue length of pending authentication requests for each domain node. By accumulating the processing latency of all domain nodes on the path and dynamically correcting it in conjunction with the queue length, the total path latency prediction value is obtained; the overall path success rate is obtained by multiplying the success rates of each domain node.

[0025] Specifically, the model searches for the corresponding path record in the inter-domain connectivity matrix based on the source domain identifier and the target domain identifier, including: First, the model searches the domain identifier mapping table for the numerical index positions corresponding to the source and target domain identifiers, converting the source domain identifier into a row index and the target domain identifier into a column index. Once the index conversion is complete, the model accesses the pre-built inter-domain connectivity matrix, using the row and column indices to locate the corresponding cell and read the path record data structure stored in that cell. If the cell contains directly connected path information, the model extracts the directly connected path identifier and path attribute parameters. If the cell does not contain a directly connected path or requires finding a multi-hop path, the model uses a breadth-first search algorithm to search the inter-domain connectivity matrix for all reachable path sequences from the source domain row index to the target domain column index. During the path search, the model starts from the source domain index, sequentially checking the column indices in that row that show a connected state as intermediate domain candidates, and then continues searching towards the target domain index from each intermediate domain index until a complete path sequence is found or the maximum hop count limit is reached. If all reachable path sequences have been searched, the model sorts the found path records by path length and path identifier, forming a complete list of available path records from the source domain to the target domain.

[0026] Furthermore, for each available path, the model extracts the total delay prediction for that path. Overall success rate Number of authentication nodes on the path and the minimum number of nodes on the path. and maximum quantity (Obtained from statistics across all reachable paths). Device trust score. The source domain identifier, target domain identifier, and current network load characteristics (such as the average queue length of each domain node) are input into a pre-trained inter-domain path prediction neural network. The neural network has a three-hidden-layer fully connected structure. The input layer receives a normalized feature vector (including one-hot encoding of the source domain, one-hot encoding of the target domain, trust score, global average latency, average success rate, etc.), and the output layer outputs three dynamic weight coefficients: a latency weight coefficient... Success rate weighting coefficient Node Quantity Weighting Coefficient The network output layer has 3 neurons, no activation function, and yields the original logical value. The coefficients are then converted into non-negative dynamic weight coefficients that sum to 1 using the Softmax function.

[0027] When the neural network outputs , , Then, the model calculates the score for each available path according to the following path comprehensive weight scoring formula. , and select The longest path is the preferred authentication route: ; in, The path is scored based on its overall weight. This is the time delay weighting coefficient. This is the success rate weighting coefficient. The weighting coefficient for the number of nodes. Total authentication latency for the path. The reference authentication latency (which can be 1.2 times the maximum latency among all candidate paths, to ensure...) ), For the overall success rate of the path, This represents the number of certified nodes on the path. To minimize the number of nodes, This represents the maximum number of nodes.

[0028] It should be noted that the weight coefficients output by the neural network are not fixed piecewise functions, but rather automatically approximate the optimal strategy through end-to-end learning. To ensure robustness in unseen scenarios, the model can be further fine-tuned periodically through an online learning mechanism after training. When the device trust score is extremely high or extremely low, the neural network will automatically increase the corresponding weights (e.g., increase the weights for high trust). Increase when trust is low and This eliminates the need for manually setting boundary thresholds. Furthermore, for ease of interpretation and emergency intervention, the system retains an optional rule coverage mode: when the confidence level of the neural network output falls below a threshold, it reverts to segmented rules based on trust scores. , , (Calculated based on high / medium / low trust boundaries), this rule is consistent with the calculation formula in the embodiment.

[0029] It should be noted that constructing the inter-domain path prediction neural network requires extracting the source domain identifier, target domain identifier, device trust score, actual authentication path sequence used, historical latency and success rate of each domain node in the path, as well as authentication result status and authentication completion time from the historical authentication log database as the original training dataset. After the original training data is extracted, the system converts the source domain identifier and target domain identifier into dense vectors through one-hot encoding or embedding layers, and normalizes the device trust score and path performance parameters to form a fixed-dimensional feature vector. The design comprises an input layer, three fully connected hidden layers (128 neurons each, using ReLU activation and Dropout ratio 0.2 regularization), and an output layer (3 neurons, no activation function). During training, samples are constructed from historical authentication logs: each sample contains a feature vector. And the corresponding optimal path label (i.e., the path that best balances overall latency and success rate in actual authentication). For each candidate path i, first use the current network output... , , Calculate its overall score Then for all paths The probability distribution is obtained by applying Softmax. The loss function is a composite of weighted cross-entropy and measured path delay: ; in, The optimal path indication is in one-hot form. The actual authentication latency for the selected path. The desired delay threshold, This is a balancing factor. The network parameters are iteratively updated through backpropagation and the Adam optimizer, allowing the network to learn automatically: increasing the value when the input trust score is high. make Increase the latency, thus favoring low-latency paths during the inference phase; increase the latency when the trust score is low or the network load is high, causing queue growth. make The increased latency leads to a preference for lower-latency paths during the inference phase, resulting in the selection of more reliable but potentially more hop-intensive paths. Once trained, the model receives real-time source domain, target domain, device trust scores, and path performance parameters, outputting dynamic weight coefficients. , , This is used to calculate the weighted scoring formula and select the preferred certification pathway.

[0030] S3: Adaptively convert the source domain identity credentials according to the credential format requirements of each intermediate domain in the preferred authentication path, and maintain the cryptographic strength of identity verification without degradation during the conversion process, forming a cross-domain credential chain that is compatible with multiple formats. Once the system determines the preferred authentication path, it parses the path sequence of the preferred authentication path, extracts the domain identifier of each intermediate field in the path, and queries the corresponding voucher data structure definition in the voucher format mapping table based on the domain identifier, including specific technical parameters such as the length of the voucher header field, the encoding method of the identity identifier, the position of the permission field, and the type of digital signature algorithm.

[0031] Once the format parameters of each intermediate domain credential are obtained, the system reads the cryptographic parameters of the source domain credential, extracting the key length of the symmetric encryption algorithm, the key pair length of the asymmetric encryption algorithm, the number of bits in the hash algorithm output, and the digital signature algorithm type. It then establishes a comparison table of the cryptographic strength values ​​between the source credential and each intermediate domain credential format. After the cryptographic strength comparison is complete, the system begins format conversion for the first intermediate domain in the authentication path, checking if the key length requirement of this intermediate domain credential format is not less than that of the source credential. If the intermediate domain requires a lower key length, the key length of the source credential is maintained; if the intermediate domain requires a higher key length, a new key pair that meets the requirements is generated. If the key length adjustment is complete, the system re-encodes the identity identifier field in the source credential according to the encoding rules of the intermediate domain credential format, rearranges the permission information field according to the permission bitmap format of the intermediate domain, and maintains the validity period timestamp format consistent with the intermediate domain time standard. Once the credential content format conversion is complete, the system uses the adjusted key to digitally sign the intermediate domain format credential, generating an intermediate domain format credential containing the source domain authentication information. This conversion process is repeated until corresponding format credentials are generated for all intermediate domains in the authentication path. Once all format conversions are complete, the system concatenates the source domain credentials and the intermediate domain format credentials according to the authentication path order, adds an index field to each credential pointing to the next-hop domain credential, and forms a cross-domain credential chain data structure with a clear transmission relationship.

[0032] The process involves establishing a comparison table of cryptographic strength values ​​between the source credential and each intermediate domain credential format. This is achieved by creating a data table structure containing four fields: algorithm type, key length, hash bit length, and signature length. Corresponding data record rows are created for both the source domain credential and each intermediate domain credential. Once the data table structure is established, the system reads the encryption parameters of the source domain credential, filling in the symmetric encryption algorithm name (e.g., AES) in the algorithm type field, the corresponding key bit length in the key length field, the hash algorithm used (e.g., SHA) in the algorithm type field, the hash output bit length in the hash bit length field, the digital signature algorithm (e.g., RSA) in the algorithm type field, and the signature key length in the signature length field. If the source domain credential parameters are filled in, the system sequentially reads the credential format requirements for the first, second, and finally last intermediate domains along the authentication path, filling in the algorithm name and corresponding minimum parameter requirements for each intermediate domain into their respective data record rows according to the same field structure. Once the cryptographic parameters of all fields are filled into the data table, the system compares the key length field value of the source field credential record line with that of the first intermediate field record line, records the size relationship between the two, and repeats this comparison process until the source field and all intermediate fields are compared in terms of key length, hash bits, and signature length. The comparison results are marked as one of three adjustment strategies: maintain the source field parameters, upgrade to the intermediate field requirements, or downgrade. This forms a cryptographic strength comparison table containing specific numerical comparison results and explicit adjustment instructions.

[0033] Once the cryptographic strength comparison table is constructed, the system begins credential format conversion based on the adjustment strategy flags in the table. When a flag indicating that the source domain parameters should be preserved is encountered, the system directly uses the original cryptographic parameters of the source domain credential for format conversion, retaining the encryption algorithm type, key length, hash algorithm, and signature scheme of the source domain unchanged. When a flag indicating that the requirements for upgrading to intermediate domains are encountered, the system replaces the source domain parameters with the higher strength parameters required by the intermediate domain, regenerates the key pair using a longer key length, recalculates the credential digest using a stronger hash algorithm, and regenerates the digital signature using a more secure signature algorithm. If a flag indicating downgrading is encountered, the system refuses to perform the format conversion operation, skips the intermediate domain in the authentication path, or finds an alternative intermediate domain that supports higher cryptographic strength, ensuring that the cryptographic parameters at any stage of the entire conversion process are not lower than the original strength level of the source domain credential. Before each format conversion is performed, the system verifies whether the cryptographic parameters of the target format meet the non-downgrade requirement. Only when it is confirmed that the converted credential is no weaker than the source credential in terms of encryption strength, hash collision resistance, and signature non-repudiation will the actual format conversion operation be performed. This mechanism of step-by-step verification and conditional conversion ensures that the cryptographic strength of each credential node in the entire cross-domain credential chain remains above the security level of the source domain credential.

[0034] For example, if a smart lock device needs to authenticate across domains from domain A to domain C via an intermediate domain B, the system first reads the encryption algorithm and key length (e.g., AES-256), hash algorithm and output length (e.g., SHA-256), and signature algorithm and key length (e.g., RSA-2048) used by the credentials in the source domain A. Then, it queries the list of algorithms supported by the intermediate domain B and their required security strengths (e.g., supporting AES-128 / 192 / 256, SHA-160 / 256, RSA-1024 / 2048). After obtaining the algorithm parameters from both sides, the system negotiates for each algorithm type: selecting the algorithm parameters with the highest security strength supported by both the source domain A and the intermediate domain B as the converted parameters. For example, if source domain A uses AES-256 and intermediate domain B supports AES-256, then AES-256 will be maintained. If source domain A uses AES-128 and intermediate domain B supports AES-256, then it will be upgraded to AES-256 (it must be confirmed that the source domain device can generate compatible credentials; otherwise, the highest supported credential in the source domain will prevail). If source domain A uses AES-256 and intermediate domain B only supports AES-128 at most, then the conversion will be rejected because the "no downgrade" principle cannot be met, and S2 will be notified to reselect an alternative path that does not include domain B. The same applies to hash algorithms and signature algorithms, taking the highest common strength supported by both parties. After the parameters are negotiated, the system will convert the identity identifier in the credential of source domain A from the user ID format of domain A to the device ID format of domain B, and convert the permission field from the permission bitmap of domain A to the permission list format of domain B, according to the preset inter-domain credential mapping rule base (this rule base requires the administrator to pre-configure the identity identifier conversion mapping table between each domain, permission field conversion logic, etc.). If the conversion rule is missing, the conversion will be rejected and an exception will be recorded. After the conversion is complete, the credential content is re-encrypted using a negotiated encryption algorithm (such as AES-256), the new credential digest is calculated using a negotiated hash algorithm (such as SHA-256), and a digital signature is generated for the new credential using a negotiated signature algorithm (such as RSA-2048). This ensures that the cryptographic strength of the generated intermediate domain B credential is no less than that of the original credential in the source domain A and can be correctly parsed by domain B. Once the intermediate domain B format credential is generated, the system repeats the same process to convert the credential format from intermediate domain B to the target domain C, forming a cross-domain credential chain. If any intermediate domain fails to complete the strength-preserving conversion, the entire conversion fails, the system returns an error, and authentication terminates.

[0035] S4: Chain verification is performed between authentication domains through the cross-domain credential chain. After the target domain completes the final identity verification, the authentication result is propagated back to the source domain to establish a distributed cross-domain authentication trust relationship.

[0036] After the system generates a cross-domain credential chain, it reads the first intermediate domain identifier from the cross-domain credential chain data structure. Based on this identifier, it queries the domain address mapping table to obtain the network address of the first intermediate domain and sends the entire cross-domain credential chain to the verification service port of that intermediate domain via a secure transmission protocol (such as TLS 1.3). If the first intermediate domain receives the cross-domain credential chain, its verification module parses the data format of the credential chain, locates the corresponding intermediate domain format credential in the credential chain based on its own domain identifier, and extracts the digital signature field, identity identifier field, permission field, and validity period field of the credential. After the credential fields are extracted, the intermediate domain uses its own RSA public key to decrypt and verify the digital signature field, checks the matching of the decryption result with the hash value of the credential content, verifies whether the identity identifier exists in the domain's legitimate user database (or has a trust mapping relationship with the domain), whether the permission field value conforms to the domain's permission scope definition, and whether the validity period field includes the current time. If all the above verifications pass, the intermediate domain signs the verification record using its private key: it concatenates the domain identifier, the current UTC timestamp, the verification success status, and the current hash value of the entire credential chain to calculate a digest, generates a digital signature using its private key (such as RSA-2048 or ECC), and appends this signature, along with the domain identifier, timestamp, and verification status, to the verification record array of the credential chain. Subsequently, the intermediate domain reads the predefined next-hop domain identifier from the credential chain, looks up its network address through the domain address mapping table, and forwards the updated credential chain to the next-hop domain. This process is repeated until the credential chain reaches the target domain.

[0037] If any intermediate domain verification fails (e.g., signature mismatch, identity non-existent, insufficient permissions, or expiration), the intermediate domain creates a failure result data packet containing its own identifier, failure reason code, and current timestamp. After signing this packet with its own private key, it propagates it back to the source domain in reverse order of the forwarded path, simultaneously terminating the forwarding process. Upon receiving the failure result, the source domain notifies the S1 module to update the device's trust level (lowering the trust score) and triggers S2 to reselect an alternative path as needed.

[0038] Once the cross-domain credential chain successfully reaches the target domain, the target domain verification module first checks if the length of the credential chain verification record array is equal to the number of intermediate domains in the authentication path (i.e., the path hop count minus one). Then, it verifies the validity of the digital signature of each record entry in the array: for each record, the signature is verified using the public key of the corresponding intermediate domain, confirming the signature's match with the domain identifier, timestamp, verification status, and the current credential chain hash. Simultaneously, timestamp continuity is verified: the timestamp difference between adjacent records must not exceed a preset threshold (e.g., 10 seconds), and each timestamp must not be later than the current system time plus an allowed clock deviation (e.g., 1 second), and must not be earlier than the current time by more than the maximum validity period (e.g., 5 minutes). If the verification record array is complete and all signatures and timestamps are valid, the target domain extracts the source domain credentials from the credential chain to perform final identity authentication, including verifying the source domain's digital signature, checking the legitimacy of the source domain's identity, and access permissions to required resources. After successful final authentication, the target domain creates an authentication result data packet containing an authentication success flag, the target domain identifier, the source domain identifier, the authentication completion timestamp, the hash value of the entire cross-domain credential chain, and the target domain's digital signature.

[0039] For example, the structure of the result packet is: { result: "success", target_domain: "C", source_domain: "A", timestamp: UTC_now, chain_hash: H(credential_chain),signature: Sign_target(H(...))}.

[0040] Then, the target domain sends the authentication result data packets sequentially in reverse order of the credential chain verification record array (i.e., from the last intermediate domain to the first intermediate domain, and finally to the source domain). Each intermediate domain (or source domain) that receives the result data packet first verifies the signature in the data packet using the target domain's public key, checks whether the chain_hash in the result packet matches the locally stored credential chain hash, and whether the timestamp is valid. If the verification passes, the successful record of this cross-domain authentication is written to the trust relationship database table of this domain, with fields including: source domain identifier, target domain identifier, authentication success status, authentication completion timestamp, and path identifier used (optional), and the historical authentication statistics table of this domain is updated. If the signature verification fails or the hash does not match, the result packet is discarded and the exception event is recorded, and a retransmission request can be initiated to the target domain. If all intermediate domains and the source domain successfully record, the distributed cross-domain authentication trust relationship is established. Failure at any step will cause the entire authentication to fail and trigger the corresponding failure handling process (logging, updating device trust, notifying the administrator, etc.).

[0041] In summary, the cross-domain authentication method for distributed digital identity IoT devices based on machine learning, as described in this invention, is explained. It receives cross-domain authentication requests and performs multi-dimensional trust quantification assessment of the device based on historical successful authentication records to generate a device authentication profile. Then, it utilizes a pre-trained inter-domain path prediction neural network, combined with the device trust score and real-time network load, to dynamically allocate latency, success rate, and node quantity weight coefficients. The authentication path with the highest comprehensive weight is selected as the preferred path. Subsequently, adaptive credential conversion is performed according to the credential format requirements of each intermediate domain in the preferred path. During the conversion process, the cryptographic strength is maintained without degradation through negotiation of the highest security strength algorithm supported by both parties. Finally, a cross-domain credential chain is used for chain-based verification and transmission between authentication domains, and the authentication result is propagated back to each domain to update the local trust database. In this way, on the one hand, the trust-driven dynamic path selection effectively reduces the end-to-end latency of cross-domain authentication and improves the success rate. On the other hand, the strength-preserving credential conversion avoids the risk of cryptographic strength degradation caused by backward compatibility in traditional mapping schemes. At the same time, the chain verification and backpropagation mechanism enable each authentication domain to accumulate cross-domain authentication trust evidence and form a distributed dynamic trust relationship. This systematically solves the technical problems of incompatible credential formats, inefficient path selection, and security strength decay in cross-domain authentication of IoT devices.

[0042] In summary, it should be noted that... Figure 3 This chart compares the proposed method with existing methods across three dimensions: authentication latency, success rate, and cryptographic strength retention rate. The comparison examines the proposed method against three existing cross-domain authentication methods: static shortest path, federated identity authentication, and centralized proxy. The data shows that the proposed method achieves the highest latency performance normalization score (reflecting the lowest actual latency), a significantly higher authentication success rate (97%) than existing methods (72%–85%), and a cryptographic strength retention rate (100%) far superior to the strength attenuation (40%–60%) caused by backward compatibility issues in existing methods. This demonstrates that the proposed method has significant advantages in reducing authentication latency, improving success rate, and ensuring the security of cross-domain credential conversion.

[0043] Here, those skilled in the art will understand that the specific operations of each step in the above-described machine learning-based distributed digital identity IoT device cross-domain authentication system have been referenced above. Figures 1 to 3 The method for cross-domain authentication of distributed digital identity IoT devices based on machine learning has been described in detail, and therefore, its repeated description will be omitted.

[0044] In summary, the machine learning-based distributed digital identity IoT device cross-domain authentication system based on embodiments of the present invention is explained. It receives cross-domain authentication requests and performs multi-dimensional trust quantification assessment of devices based on historical successful authentication records to generate device authentication profiles. Then, it utilizes a pre-trained inter-domain path prediction neural network, combined with device trust scores and real-time network load, to dynamically allocate latency, success rate, and node quantity weight coefficients. The system selects the authentication path with the highest comprehensive weight as the preferred path. Subsequently, it performs adaptive credential conversion according to the credential format requirements of each intermediate domain in the preferred path, maintaining cryptographic strength without degradation during the conversion process through negotiation of the highest security strength algorithm supported by both parties. Finally, it performs chain-like verification and transmission between authentication domains through a cross-domain credential chain and propagates the authentication results back to each domain to update the local trust database. In this way, on the one hand, the trust-driven dynamic path selection effectively reduces the end-to-end latency of cross-domain authentication and improves the success rate. On the other hand, the strength-preserving credential conversion avoids the risk of cryptographic strength degradation caused by backward compatibility in traditional mapping schemes. At the same time, the chain verification and backpropagation mechanism enable each authentication domain to accumulate cross-domain authentication trust evidence and form a distributed dynamic trust relationship. This systematically solves the technical problems of incompatible credential formats, inefficient path selection, and security strength decay in cross-domain authentication of IoT devices.

Claims

1. A cross-domain authentication method for distributed digital identity IoT devices based on machine learning, characterized in that, include: Receive cross-domain authentication requests from source domain IoT devices, extract device identity and target domain information from the requests, perform trust quantification assessment of device identity based on historical successful authentication records, and generate a device authentication profile containing trust scores. Based on the trust score and target domain information in the device authentication profile, the available authentication paths are dynamically weighted using a pre-trained inter-domain path prediction model, and the authentication path with the highest weight is selected as the preferred authentication path. The source domain identity credentials are adaptively converted according to the credential format requirements of each intermediate domain in the preferred authentication path, and the cryptographic strength of identity verification is maintained without degradation during the conversion process, forming a cross-domain credential chain that is compatible with multiple formats. The cross-domain credential chain enables chained verification and transmission between authentication domains. Once the target domain completes final identity verification, the authentication result is propagated back to the source domain, establishing a distributed cross-domain authentication trust relationship.

2. The cross-domain authentication method for distributed digital identity IoT devices based on machine learning according to claim 1, characterized in that, The trust level of the device identity is quantitatively evaluated using a trust score, which is calculated as follows: ； in, This represents the device trust level value. For consecutive successful authentications, Total number of authentications As a success rate weighted index, The time stability decay coefficient, The standard deviation of the certification time interval. This represents the average authentication time interval. This represents the actual number of resource access types. This represents the expected number of resource access types. This is a resource access matching index. This represents the number of abnormal events triggered. This represents the total number of events triggered. For historical continuity gain coefficient, This represents the current number of consecutive normal certification cycles. This is a continuous adjustment constant.

3. The cross-domain authentication method for distributed digital identity IoT devices based on machine learning according to claim 2, characterized in that, The inter-domain path prediction model receives device trust scores, source domain identifiers, and target domain identifiers as inputs. Based on the inter-domain connection matrix, it searches for all reachable path sequences and extracts the latency, success rate, and number of nodes parameters for each path. Then, it uses a pre-trained three-hidden-layer fully connected neural network to output latency weight coefficients, success rate weight coefficients, and number of nodes weight coefficients. Finally, it calculates the score for each path according to the path comprehensive weight scoring formula and selects the path with the highest score as the preferred authentication path.

4. The cross-domain authentication method for distributed digital identity IoT devices based on machine learning according to claim 3, characterized in that, The formula for the comprehensive weighted scoring of the path is as follows: ； in, The path is scored based on its overall weight. This is the time delay weighting coefficient. This is the success rate weighting coefficient. The weighting coefficient for the number of nodes. Total path authentication latency, For reference, the certification delay, For the overall success rate of the path, This represents the number of certified nodes along the path. To minimize the number of nodes, This represents the maximum number of nodes.

5. The cross-domain authentication method for distributed digital identity IoT devices based on machine learning according to claim 4, characterized in that, The adaptive transformation that does not degrade cryptographic strength includes the following steps: The system reads the encryption algorithm and key length, hash algorithm and output length, and signature algorithm and key length used by the source domain credential, and queries the list of algorithms supported by each intermediate domain and their required security strength. For each algorithm type, it selects the algorithm parameters with the highest security strength that are supported by both the source and intermediate domains as the parameters after conversion. If the intermediate domain does not support an algorithm with a strength no lower than that of the source domain, it rejects the conversion and notifies the inter-domain path prediction model to reselect another path that does not include the intermediate domain. According to the preset inter-domain credential mapping rule base, it converts the identity identifier and permission fields in the source domain credential into the format required by the intermediate domain. It then uses the negotiated encryption algorithm, hash algorithm, and signature algorithm to re-encrypt the converted credential content, calculate the digest, and generate a digital signature.

6. The cross-domain authentication method for distributed digital identity IoT devices based on machine learning according to claim 5, characterized in that, The inter-domain credential mapping rule base is a data table structure containing four fields: algorithm type, key length, hash bit length, and signature length. The cryptographic parameters of the source domain credential and each intermediate domain credential are filled in respectively. Then, the numerical relationship between the source domain and each intermediate domain in the three dimensions of key length, hash bit length, and signature length is compared one by one. The comparison results are marked as three adjustment strategies: maintain the source domain parameters, upgrade to the intermediate domain requirements, or downgrade. This forms a cryptographic strength comparison table containing specific numerical comparison results and explicit adjustment instructions.

7. The cross-domain authentication method for distributed digital identity IoT devices based on machine learning according to claim 6, characterized in that, The chained verification transmission includes: The cross-domain credential chain is sent to each intermediate domain in sequence according to the preferred authentication path. Each intermediate domain verifies the credential corresponding to its domain. After successful verification, the domain's private key is used to sign the verification information of the domain and the global characteristics of the current credential chain. The signature result is added to the verification record of the credential chain and then forwarded to the next domain. After receiving the credential chain, the target domain verifies the validity of the signatures of each intermediate domain in the verification record and the rationality of the time sequence. After the verification is successful, the final identity authentication is completed, and an authentication result data packet containing the authentication success flag, domain identifier, timestamp, global features of the credential chain, and the signature of the target domain is generated. The target domain propagates the authentication result data packet in reverse order of the verification record to each intermediate domain and the source domain. Each domain that receives the result data packet first verifies the consistency of the target domain signature and the global characteristics of the credential chain. After the verification is successful, the successful authentication record is stored in the local trust relationship database to realize a distributed cross-domain authentication trust relationship.

8. A machine learning-based distributed digital identity IoT device cross-domain authentication system, characterized in that, include: The device trust assessment and profile generation module is used to receive cross-domain authentication requests, extract device identity and target domain information, perform quantified trust assessment of the device based on historical authentication records, and generate a device authentication profile containing trust scores. The dynamic path selection module is used to dynamically assign weights to available authentication paths based on the trust score and target domain information in the device authentication profile, and select the authentication path with the highest weight as the preferred authentication path. The credential adaptive conversion module is used to adaptively convert the source domain identity credentials according to the credential format requirements of each intermediate domain in the preferred authentication path, and maintain the cryptographic strength without degradation during the conversion process, forming a cross-domain credential chain that is compatible with multiple formats. The chain verification and trust propagation module is used to perform chain verification and transmission between authentication domains through cross-domain credential chains. After the final identity verification is completed in the target domain, the authentication result is propagated back to the source domain to establish a distributed cross-domain authentication trust relationship.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the cross-domain authentication method for distributed digital identity IoT devices based on machine learning, as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the cross-domain authentication method for distributed digital identity IoT devices based on machine learning, as described in any one of claims 1 to 7.

Images