Number card credibility authentication and anti-fraud system based on block chain and AI

Abstract

The invention relates to the technical field of communication security and information, and particularly provides a number card credible authentication and anti-fraud system based on a block chain and AI, comprising a credible certificate storage layer which adopts a block chain technology and is used for safely storing and verifying identity certificate data and user behavior log data related to a number card; the dynamic analysis layer adopts an artificial intelligence technology and is used for constructing a user behavior graph based on the data stored in the credible evidence storage layer and carrying out fraud risk analysis; the decision execution layer is used for executing real-time risk disposal operation through a preset rule or an intelligent contract based on the risk analysis result of the dynamic analysis layer; wherein the credible evidence storage layer, the dynamic analysis layer and the decision execution layer work cooperatively to realize credible authentication of a number card and identification and disposal of fraudulent behaviors. According to the invention, the data privacy security is further guaranteed.

Description

Technical Field

[0001] This invention relates to the technical field of communication security and information, and in particular to a trusted SIM card authentication and anti-fraud system based on blockchain and AI. Background Technology

[0002] Existing technologies in the field of SIM card authentication and anti-fraud mainly adopt centralized database verification methods, relying on the user identity database built by operators, such as HLR (Home Location Register) / HSS (Home Subscriber Server), and using manual review of account opening materials. They usually combine SMS verification code and ID card number verification as a dual authentication mechanism to ensure authentication security.

[0003] Current technology relies on a centralized database authentication process. When a user applies for a SIM card, the operator compares the submitted identity information, such as ID number and name, with data in the HLR / HSS database for verification. Simultaneously, a verification code is sent to the user's mobile phone. The user must enter the received verification code into a designated location within a specified time to complete the initial identity verification. Human reviewers conduct a secondary review of the application materials to confirm their authenticity, completeness, and compliance with relevant regulations. Only after passing this manual review will the SIM card application proceed to the next stage. However, data silos exist between different operators, with user data remaining independent and unable to share fraud information. This means that when a SIM card is involved in fraudulent activities, such as being used for scams or malicious overdue payments, the fraud record is only stored within the original operator, inaccessible to other operators. When a user switches operators and reapplies for a SIM card, the new operator is unable to know if the user has a fraud history and cannot take preventative measures. Furthermore, the inability to share secondary SIM card history across different operators means that these secondary SIM cards may be used again for fraudulent activities, increasing the overall security risk of the communication environment.

[0004] Current verification methods relying on centralized databases are susceptible to data tampering, with the "black SIM card" problem being a prime example. Criminals may illegally alter user information in the database, allowing unregistered or fraudulently registered SIM cards to flood the market, posing a serious threat to communication security and social order. Furthermore, the lack of effective data-sharing mechanisms among operators results in inefficient cross-agency collaboration and hinders the formation of a unified anti-fraud effort. Faced with increasingly sophisticated fraud methods, current technologies cannot share information or coordinate responses in a timely manner, making it difficult to quickly identify and prevent fraudulent activities, thus harming both user rights and operator interests.

[0005] To address the shortcomings of existing technologies, this invention provides a trusted SIM card authentication and anti-fraud system based on blockchain and AI. Summary of the Invention

[0006] To achieve the above objectives, the present invention adopts the following technical solution: One aspect of the present invention provides a trusted authentication and anti-fraud system for SIM cards based on blockchain and AI, comprising: The trusted evidence storage layer uses blockchain technology to securely store and verify identity credential data and user behavior log data related to the SIM card; The dynamic analysis layer employs artificial intelligence technology to construct user behavior graphs based on the data stored in the trusted evidence storage layer and to perform fraud risk analysis; and The decision execution layer is used to execute real-time risk management operations based on the risk analysis results of the dynamic analysis layer, through preset rules or smart contracts. The trusted evidence storage layer, dynamic analysis layer, and decision execution layer work together to achieve trusted authentication of SIM cards and the identification and handling of fraudulent activities.

[0007] In one optional implementation, the trusted evidence storage layer adopts an improved consortium blockchain architecture, wherein the nodes of the consortium blockchain architecture include at least regulatory agency nodes, operator nodes, and / or service provider nodes.

[0008] In one optional implementation, the trusted evidence storage layer further includes an identity chain and a behavior chain, forming a dual-chain collaborative storage system; The identity chain is mainly used to store tamper-proof user identity credential data and key status information of the SIM card lifecycle; The behavior chain is mainly used to store frequently generated user behavior log data; The identity chain and behavior chain are linked and can access each other's data through a cross-chain anchoring mechanism.

[0009] In one optional implementation, the cross-chain anchoring mechanism includes: embedding the hash value of the relevant identity record on the corresponding identity chain in the block header of the behavior chain, or realizing address mapping and data verification between the two chains through smart contracts.

[0010] In one optional implementation, the identity credential data includes at least user real-name authentication information, biometric template hash, SIM card account opening information, SIM card status change records, and black card identification markers; the key status information of the SIM card lifecycle includes at least registration, activation, suspension, cancellation, transfer, and reactivation status.

[0011] In one optional implementation, the user behavior log data includes at least call logs, SMS logs, network access logs, App usage behavior, location information, device information, and SIM card insertion / removal and power on / off hardware status events. The identity chain uses PBFT (Practical Byzantine Fault Tolerance) or its improved algorithm as a consensus mechanism to ensure strong consistency and high security of identity data; the behavior chain adopts a consensus mechanism that balances efficiency and security, based on DPoS (Delegated Proof-of-Stake) or an improved PoW (Proof-of-Work) algorithm.

[0012] In one optional implementation, the federated learning is used to perform joint modeling by multiple institutions while protecting the data privacy of each participant; each participant trains local GNN model parameters using its private data locally, shares model parameter updates or gradient information, and performs global model aggregation and updates through a federated aggregation server.

[0013] In one optional implementation, the graph neural network is used to construct a user behavior graph, wherein the nodes of the user behavior graph include at least user nodes, SIM card nodes, device nodes, application nodes and / or location nodes, and the edges represent the association relationships and characteristic attributes of interactive behaviors between the nodes.

[0014] In one optional implementation, the dynamic analysis layer can capture users' long-term behavioral patterns, short-term behavioral anomalies, and associations with known fraudulent nodes through the user behavior graph, and is particularly used to identify the historical behavioral characteristics of secondary accounts.

[0015] In one optional implementation, the dynamic analysis layer further includes a model management module for periodically or in real-time updating the federated learning model and / or graph neural network model based on new fraud samples and feedback data to adapt to constantly changing fraud methods.

[0016] In one optional implementation, the decision execution layer includes edge computing nodes and smart contracts deployed on a blockchain; The edge computing node is used to receive the risk analysis results of the dynamic analysis layer and perform rapid pre-judgment and preliminary handling locally; The smart contract is used to solidify risk management rules and automatically execute corresponding management operations when preset trigger conditions are met.

[0017] In one optional implementation, the dynamic analysis layer deploys a lightweight graph neural network model on the edge computing node for rapid risk scoring of real-time collected user behavior data, with the risk scoring response time being less than 200 milliseconds.

[0018] In one optional implementation, the lightweight graph neural network model is obtained by performing model compression, parameter pruning, and / or knowledge distillation on the basic graph neural network model to adapt to the computing resources and low latency requirements of edge computing nodes.

[0019] In one optional implementation, the smart contract is linked with the edge computing node. When the risk score output by the lightweight GNN model of the edge computing node exceeds a preset threshold, the smart contract is triggered to perform corresponding risk handling operations. The risk handling operations include, but are not limited to: denial of service, suspension of SIM card function, requesting additional identity verification, marking abnormal accounts and notifying relevant parties.

[0020] In one optional implementation, the SIM card trusted authentication includes: verifying the existence, integrity, and validity of the identity credential data corresponding to the SIM card on the identity chain, and determining the consistency between the current usage behavior of the SIM card and historical trusted behavior patterns by analyzing the behavior log data on the behavior chain.

[0021] In one optional implementation, a cross-chain data access interface is also included, allowing authorized third-party applications or organizations to query or verify specific data in the trusted evidence storage layer, provided that privacy protection and data security regulations are met. Before being written into the identity chain, the identity credential data must undergo multi-signature verification by at least one authoritative institution node or multiple operator nodes to ensure its authenticity.

[0022] In one optional implementation, the behavior log data is solidified using chained hashing and timestamps when written to the behavior chain, and can be efficiently batch verified through a Merkle tree structure.

[0023] In one alternative implementation, during the federated learning process, the local data of each participant does not leave its own data center, and only the model parameters or encrypted gradient information are transmitted between federated aggregation servers. The transmission process is protected by secure multi-party computation or homomorphic encryption technology. The weights of the edges in the user behavior graph are dynamically adjusted according to the frequency, duration, type, and risk level of the corresponding interaction behavior. The graph neural network learns these dynamic weights to improve the accuracy of fraud risk prediction.

[0024] In one optional implementation, the decision execution layer further includes a feedback learning module, used to feed back the results of risk handling operations and subsequent user behavior feedback data to the dynamic analysis layer in order to optimize the user behavior graph and risk analysis model; For secondary accounts, the system traces the historically bound user identities and historical behavior logs recorded in the behavior chain through the identity chain, and combines the identity and behavioral characteristics of the currently bound user to analyze potential association risks and fraud tendencies through the graph neural network.

[0025] In one optional implementation, the trusted evidence storage layer also supports encrypted storage of critical data, wherein sensitive user identity information is encrypted using a verifiable encryption scheme, and can only be decrypted or verified by an authorized party using a specific key or zero-knowledge proof.

[0026] Effects of the invention: 1. Data Security and Immutability: Utilizing blockchain technology, once data is uploaded to the chain, no organization (including system administrators) can modify or delete the records. Taking the identity chain and behavior chain as examples, the identity chain stores immutable identity verification results, while the behavior chain records SIM card usage data in real time. Through the blockchain's consensus mechanism and encryption algorithms, the integrity and immutability of the data are ensured, effectively avoiding the risks of data tampering such as "black cards," providing a solid data security foundation for SIM card authentication and anti-fraud.

[0027] 2. Low-cost storage and efficient management: In terms of data storage, only key hashes are recorded on the blockchain, while the original data is stored in the IPFS distributed storage system. This approach ensures both data traceability and integrity while balancing storage costs. For example, core identity information such as ID card hashes and biometric templates are stored through IPFS, with only the content hash recorded on the blockchain, significantly reducing the storage burden on the blockchain while ensuring data security and accessibility.

[0028] 3. Cross-institutional collaboration and transparency: Based on a consortium blockchain architecture, all participants (such as operators, public security departments, and the Ministry of Industry and Information Technology) can verify the same facts, breaking down data silos between operators. In SIM card authentication and anti-fraud processes, all parties can share information, improving collaboration efficiency. For example, in cross-border roaming fraud interception scenarios, the home operator node can decrypt and verify the original call detail records off-chain, and all operator nodes can synchronize information in real time via the Gossip protocol, achieving network-wide collaborative interception of fraudulent activities.

[0029] 4. Precise Risk Identification and Real-time Handling: Integrating AI technology, the system constructs user behavior graphs through federated learning and graph neural networks, enabling dynamic analysis and precise risk identification of user behavior. The system can collect user communication behavior data in real time, such as call count, movement speed, and device fingerprints, and perform real-time inference through edge AI models to output risk scores. Based on the risk scores, smart contracts can trigger corresponding actions in real time, such as mandatory two-factor authentication or network disconnection. The average time from smart contract invocation to instruction taking effect is less than 800ms on 4G networks and less than 200ms on 5G networks, effectively preventing fraudulent activities.

[0030] 5. Multi-scenario Application and Scalability: The application scenarios of this system are not limited to traditional SIM card authentication, but also extend to generalized scenarios such as IoT device authentication, including batch account opening authentication for IoT cards. Simultaneously, the system supports collaborative decision-making for authentication and anti-fraud, achieving functional expansion and upgrades through smart contract arbitration. Compared to traditional systems with only single identity verification functions, this invention has stronger adaptability and scalability.

[0031] 6. Enhanced Privacy Protection Mechanism: Employing a tiered encryption strategy and federated learning technology, user data privacy is protected. Biometric data uses homomorphic encryption, decryptable only by judicial authorities; device information uses AES-256 encryption, visible only to operator nodes; behavior logs are shared after group signing and anonymization. During federated learning, the data holder performs data preprocessing and encryption calculations locally, avoiding plaintext data exposure and ensuring the original data remains within the domain, further guaranteeing data privacy and security. Attached Figure Description

[0032] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a framework diagram of the blockchain and AI-based trusted authentication and anti-fraud system for SIM cards provided in Embodiment 1 of the present invention; Figure 2 This is a block diagram of the electronic device provided in Embodiment 4 of the present invention; Figure 3 This is a block diagram of a computer-readable storage medium provided in Embodiment 4 of the present invention. Detailed Implementation

[0033] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0034] Hereinafter, the terms "first," "second," etc., are used for descriptive convenience only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0035] In this invention, unless otherwise explicitly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed mechanical connection, a detachable mechanical connection, or an integral part; or, "connection" can be a direct connection or an indirect connection through an intermediate medium. Furthermore, unless otherwise explicitly specified and limited, the term "coupling" should be interpreted broadly. For example, "coupling" can be a direct electrical connection, such as physical contact and electrical conduction between two components; it can also be understood as an electrical connection between different components in a circuit structure through physical lines capable of transmitting electrical signals, such as copper foil or wires on a printed circuit board (PCB), to transmit electrical signals; or, "coupling" can be an indirect electrical connection between two components through an intermediate medium; or, "coupling" can be an electrical connection between two components in a non-contact manner, such as an electrical connection between two components using capacitive coupling to transmit electrical signals.

[0036] In this embodiment of the invention, directional terms such as "up," "down," "left," and "right" may be defined relative to the orientation of the components shown in the accompanying drawings. It should be understood that these directional terms can be relative concepts, used for relative description and clarification, and can change accordingly depending on the orientation of the components in the accompanying drawings.

[0037] Example 1: like Figure 1 As shown, this embodiment of the invention provides a trusted authentication and anti-fraud system for SIM cards based on blockchain and AI, comprising: The trusted evidence storage layer uses blockchain technology to securely store and verify identity credential data and user behavior log data related to the SIM card; The dynamic analysis layer employs artificial intelligence technology to construct user behavior graphs based on the data stored in the trusted evidence storage layer and to perform fraud risk analysis; and The decision execution layer is used to execute real-time risk management operations based on the risk analysis results of the dynamic analysis layer, through preset rules or smart contracts. The trusted evidence storage layer, dynamic analysis layer, and decision execution layer work together to achieve trusted authentication of SIM cards and the identification and handling of fraudulent activities.

[0038] The trusted evidence storage layer adopts an improved consortium blockchain architecture, wherein the nodes of the consortium blockchain architecture include at least regulatory agency nodes, operator nodes, and / or service provider nodes.

[0039] Specifically, the trusted evidence storage layer further includes an identity chain and a behavior chain, forming a dual-chain collaborative storage system; The identity chain is mainly used to store tamper-proof user identity credential data and key status information of the SIM card lifecycle; The behavior chain is mainly used to store frequently generated user behavior log data; The identity chain and behavior chain are linked and can access each other's data through a cross-chain anchoring mechanism.

[0040] Specifically, the cross-chain anchoring mechanism includes: embedding the hash value of the relevant identity record on the corresponding identity chain in the block header of the behavior chain, or realizing address mapping and data verification between the two chains through smart contracts.

[0041] Specifically, the identity credential data includes at least user real-name authentication information, biometric template hash, SIM card account opening information, SIM card status change records, and black card identification markers; the key status information of the SIM card lifecycle includes at least registration, activation, suspension, cancellation, transfer, and reactivation status.

[0042] Specifically, the user behavior log data includes at least call records, SMS records, network access records, App usage behavior, location information, device information, and SIM card insertion / removal and power on / off hardware status events; The identity chain uses PBFT (Practical Byzantine Fault Tolerance) or its improved algorithm as a consensus mechanism to ensure strong consistency and high security of identity data; the behavior chain adopts a consensus mechanism that balances efficiency and security, based on DPoS (Delegated Proof-of-Stake) or an improved PoW (Proof-of-Work) algorithm.

[0043] Specifically, the federated learning is used to conduct joint modeling by multiple institutions while protecting the data privacy of each participant; each participant uses its private data to train local GNN model parameters, shares model parameter updates or gradient information, and performs global model aggregation and updates through a federated aggregation server.

[0044] Specifically, the graph neural network is used to construct a user behavior graph, the nodes of which include at least user nodes, SIM card nodes, device nodes, application nodes and / or location nodes, and the edges represent the association relationships and characteristic attributes of interactive behaviors between the nodes.

[0045] Specifically, the dynamic analysis layer, through the user behavior graph, can capture users' long-term behavior patterns, short-term behavioral anomalies, and associations with known fraudulent nodes, and is particularly useful for identifying the historical behavioral characteristics of secondary accounts.

[0046] Specifically, the dynamic analysis layer also includes a model management module, which is used to update the federated learning model and / or graph neural network model periodically or in real time based on new fraud samples and feedback data to adapt to constantly changing fraud methods.

[0047] Specifically, the decision execution layer includes edge computing nodes and smart contracts deployed on the blockchain; The edge computing node is used to receive the risk analysis results of the dynamic analysis layer and perform rapid pre-judgment and preliminary handling locally; The smart contract is used to solidify risk management rules and automatically execute corresponding management operations when preset trigger conditions are met.

[0048] Specifically, the dynamic analysis layer deploys a lightweight graph neural network model on the edge computing node to perform rapid risk scoring on real-time collected user behavior data, with a response time of less than 200 milliseconds.

[0049] Specifically, the lightweight graph neural network model is obtained by performing model compression, parameter pruning, and / or knowledge distillation on the basic graph neural network model to adapt to the computing resources and low latency requirements of edge computing nodes.

[0050] Specifically, the smart contract works in conjunction with the edge computing node. When the risk score output by the lightweight GNN model of the edge computing node exceeds a preset threshold, the smart contract is triggered to perform corresponding risk handling operations. These risk handling operations include, but are not limited to: denial of service, suspension of SIM card function, requesting additional identity verification, marking abnormal accounts and notifying relevant parties.

[0051] Specifically, the SIM card trusted authentication includes: verifying the existence, integrity, and validity of the identity credential data corresponding to the SIM card on the identity chain, and determining the consistency between the current usage behavior of the SIM card and historical trusted behavior patterns by analyzing the behavior log data on the behavior chain.

[0052] Specifically, it also includes a cross-chain data access interface, which allows authorized third-party applications or organizations to query or verify specific data in the trusted evidence storage layer, provided that privacy protection and data security regulations are met. Before being written into the identity chain, the identity credential data must undergo multi-signature verification by at least one authoritative institution node or multiple operator nodes to ensure its authenticity.

[0053] Specifically, when the behavior log data is written into the behavior chain, it is solidified using chained hashing and timestamps, and can be efficiently batch verified through a Merkle tree structure.

[0054] Specifically, during the federated learning process, the local data of each participant does not leave its own data center. Only the model parameters or encrypted gradient information are transmitted between federated aggregation servers, and the transmission process is protected by secure multi-party computation or homomorphic encryption technology. The weights of the edges in the user behavior graph are dynamically adjusted according to the frequency, duration, type, and risk level of the corresponding interaction behavior. The graph neural network learns these dynamic weights to improve the accuracy of fraud risk prediction.

[0055] Specifically, the decision execution layer also includes a feedback learning module, which is used to feed back the results of risk handling operations and subsequent user behavior feedback data to the dynamic analysis layer in order to optimize the user behavior graph and risk analysis model; For secondary accounts, the system traces the historically bound user identities and historical behavior logs recorded in the behavior chain through the identity chain, and combines the identity and behavioral characteristics of the currently bound user to analyze potential association risks and fraud tendencies through the graph neural network.

[0056] Specifically, the trusted evidence storage layer also supports encrypted storage of key data, wherein sensitive user identity information adopts a verifiable encryption scheme, which can only be decrypted or verified by the authorized party through a specific key or zero-knowledge proof.

[0057] In the above embodiments, the system of the present invention mainly includes three modules: a trusted evidence storage layer, a dynamic analysis layer, and a decision execution layer, as shown in the table below.

[0058]

[0059] The implementation schemes of the trusted evidence storage layer include: Dual-chain collaborative storage system: Identity Chain (Authority Chain): Serving as the foundational trust anchor, it stores immutable identity verification results; it adopts the Hyperledger Fabric consortium blockchain framework and is jointly maintained by authoritative nodes such as operators, public security departments, and the Ministry of Industry and Information Technology.

[0060] The underlying framework of the identity chain is developed based on Hyperledger Fabric 2.5, and the node setup includes: Authoritative verification nodes (assuming 21 fixed nodes): telecom operators (10), public security departments (5), Ministry of Industry and Information Technology (3), People's Bank of China (2), Supreme People's Court (1).

[0061] Observation nodes: Other government departments and authorized enterprises can query data but do not have the right to produce blocks.

[0062] The channel design includes: a main channel (identity_main) for storing core identity credentials; and category channels (identity_[type]), such as identity_telcom and identity_bank, for isolating data by industry.

[0063] Data storage: Core identity information (such as ID card hashes and biometric templates) is stored in a distributed manner via IPFS, with only the content hashes uploaded to the blockchain; each identity record is associated with a digital identity credential (DID) in the W3C standard format. A data sharding strategy is adopted to divide the biometric data into three parts, which are stored on nodes in different geographical regions.

[0064] Consensus Mechanism: PoA (Proof-of-Authority) consensus is used, with 21 verifier nodes pre-defined. New block generation requires signature confirmation from at least 2 / 3 of the nodes; block confirmation time is controlled within 2 seconds. Improvements to PoA include: the 21 verifier nodes take turns producing blocks in a pre-defined order (switching every 2 seconds); the dynamic signature threshold is automatically adjusted based on network conditions (2 / 3 under normal conditions, reduced to 1 / 2 under high latency); nodes that fail to sign three consecutive times will have their eligibility temporarily frozen.

[0065] Behavior Chain (High-Frequency Chain): Records real-time card usage behavior data; based on an Ethereum EVM-compatible chain, it supports high-throughput writes.

[0066] Data structure optimization: A main chain + side chain structure is adopted. The main chain stores summaries, and the side chains store detailed logs. The main chain is an Ethereum EVM-compatible chain based on Quorum, with a block size of 8MB and a block interval of 1 second. The side chain network consists of 12 regionally divided side chains, using the Plasma framework for asset pegging, and submitting a state root to the main chain every 30 minutes. MerklePatriciaTree is used to compress and store time-series data such as call logs and data usage.

[0067] Consensus Mechanism: An improved DPoS mechanism, with operator nodes taking turns producing blocks; introducing BFT fault tolerance, tolerating no more than 1 / 3 malicious nodes. The improved DPoS process includes: node election, where each operator nominates 3 block-producing nodes who participate in voting by staking CMT tokens. Block production rounds: 21 blocks per round (each elected node produces 1 block), with the node order reshuffled after each round. BFT Fault Tolerance: Adopting the IBFT 2.0 protocol, the view switching timeout is 4 seconds, and the maximum fault-tolerant nodes are f = (N-1) / 3.

[0068] Cross-chain secure interaction design: Anchoring mechanism: The identity chain generates a snapshot hash every 10 blocks and writes it to the behavior chain smart contract; key operations on the behavior chain (such as blacklist updates) require verification of the credential status on the identity chain.

[0069] The anchoring mechanism implementation includes: Two-way anchoring scheme: Identity Chain → Behavior Chain, SPV proof is generated every 10 blocks and verified through the ChainRelay contract; Behavior Chain → Identity Chain, daily snapshot hashes are confirmed by 5 / 8 multi-signature witnesses. Verification process: Identity Chain block headers are synchronized to the Behavior Chain's HeaderStore contract, the existence of specific transactions is verified through MerkleProof, and zero-knowledge proof verification is performed using the ZoKrates toolchain. Data synchronization process: 1) When a new authentication record is added to the Identity Chain, a cross-chain event is triggered; 2) An oracle node obtains the Identity Chain block header information; 3) The authenticity of the data is verified through zero-knowledge proofs (such as zk-SNARKs); 4) The verified identity state is synchronized to the Behavior Chain's smart contract.

[0070] Privacy protection achieved: Hierarchical encryption strategy

[0071] Key operation examples: When a user opens an account: 1) The operator's node collects the user's facial recognition and ID card information; 2) The public security department's on-chain node is called for verification; 3) After successful verification, an identity credential NFT is generated, containing the following information: { "cardID":"0x3a1b...", "issuer":"China Mobile", "expiry":1735689600, "credential":"ipfs: / / QmXy..." } Write the credential hash into the identity chain and store the original data in IPFS; When recording behavior: 1) The base station edge node detects the call behavior; 2) A log containing timestamp, base station ID, and device fingerprint is generated; 3) The behavior chain is submitted after being signed with the node's private key; 4) The smart contract verifies the validity of the signature and then packages it into a block.

[0072] Federated learning implementation schemes include: Participant's local training phase: Operators A and B, as data holders, execute the following in their respective data centers: Data preprocessing: Features are extracted from the local user behavior database (call logs, traffic logs, etc.); standardization (e.g., Z-score normalization) is performed, and training batches are divided. The data preprocessing process includes: feature extraction; call behavior features include time dimension (number of calls per hour, standard deviation of call duration, percentage of nighttime calls (22:00-6:00); relationship dimension (contact dispersion (Shannon entropy), percentage of calls made by the top 5 contacts); pattern features (autocorrelation coefficient of call interval). Traffic usage features include burst traffic detection, identifying abnormal traffic peaks using the CUSUM algorithm; periodic analysis: extracting daily / weekly periodic components using Fourier transform. Standardization: robust standardization using (x-median) / IQR (interquartile range); categorical variable encoding using TargetEncoding (mean-based encoding based on y). Batch division strategy: time-sensitive partitioning to ensure records of the same user are in the same batch; balanced sampling; and oversampling of fraudulent samples (SMOTE algorithm).

[0073] Encrypted computation: Use homomorphic encryption libraries (such as Microsoft SEAL) to encrypt training data; compute model gradients in the encrypted state to avoid exposing plaintext data.

[0074] Privacy handling: Differential privacy noise (Laplace noise with ε=0.5) is added to the gradient; digital signatures are generated (ECDSA algorithm) to ensure gradient integrity.

[0075] Secure gradient transfer: Transmission protocol: Operator A sends an encrypted gradient packet to the coordinating node via a TLS 1.3 channel, containing: { "participant_id":"CMCC_Node_01", "encrypted_grads":"7x8a...", / / Encrypted gradient tensor "data_volume":125000, / / Data volume for this training session "signature":"0x3a2b..." / / Digital signature of the gradient } Operator B executes the same process synchronously, and all gradients remain in encrypted state during transmission.

[0076] Transport protocol stack design

[0077] Transmission guarantee mechanism: Reliability guarantee: fragmented transmission, with large gradient fragments in 1MB chunks; Resume interrupted transmission: record the SHA-256 digest of the transmitted fragments.

[0078] Integrity verification: The receiver reconstructs the complete gradient packet, verifies the ECDSA signature, and cross-verifies the data_volume and the number of gradient samples.

[0079] Coordinating node aggregation calculation: Secure aggregation: Verifies the identity certificates of each participant (based on blockchain DID). The blockchain DID verification process is as follows: This process describes the authentication procedure when participating direction coordination nodes submit gradient data. The specific steps are as follows: Gradient submission phase: After completing local model training, participating parties (such as operator A) package the encrypted gradient data with digital signatures to form a gradient packet. The digital signature is generated by encrypting the hash value of the gradient data using the participant's private key, ensuring data integrity and authenticity.

[0080] DID Document Query Phase: After receiving the gradient packet, the coordinating node first extracts the decentralized identifier of each participant. It then queries the complete document corresponding to that DID by accessing the identity chain on the blockchain. The DID document returned by the identity chain contains the participant's public key information, credential status (valid / revoked), and related metadata.

[0081] Signature Verification Phase: The coordinating node uses the public key obtained from the DID document to decrypt the digital signature in the gradient packet, obtaining the original hash value. Simultaneously, the coordinating node locally calculates the hash value of the received gradient data. The two hash values ​​are compared: if they match, it means that the gradient data has not been tampered with during transmission; the submitter indeed holds the private key bound to the DID. If they do not match, it indicates that the data may have been tampered with or the identity may have been forged.

[0082] Credential Status Check: The coordinating node simultaneously verifies whether the DID credential is valid and whether it has been revoked (CRL). This step prevents revoked participants from continuing to participate in federated learning.

[0083] Response feedback phase: When all verifications pass, the coordinating node sends an ACK (acknowledgment response) to the participants, indicating that the gradient data has been received and will enter the aggregation process. If any verification fails (signature mismatch / credential invalidation, etc.), the coordinating node sends a NACK (rejection response) with a specific error code (e.g., 0x01 - invalid signature, 0x02 - credential revoked).

[0084] Key safety features of this process: Two-way authentication: verifies the identity of the participants and also ensures that the coordinating node is a legitimate node (through TLS two-way certificates).

[0085] Real-time revocation checks: Verify the latest credential status with every submission, instead of relying on the cache.

[0086] Anti-replay attack: The gradient packet contains a timestamp and a random number to prevent attackers from repeatedly sending old data packets.

[0087] This verification process achieves decentralized identity management through the blockchain DID system, which protects the privacy of participants (without exposing their real identities) and ensures the security of the federated learning system.

[0088] Decrypting gradients using Secure Multi-Party Computation (SMPC): Decryption requires collaboration from at least 3 coordinating nodes (Shamir secret sharing scheme); performing federated averaging (FedAvg); generating next-generation global model parameters; quantizing and compressing the aggregation results (FP32→INT8); and attaching joint signatures from coordinating nodes.

[0089] The following is a detailed design of the gradient decryption and federated learning scheme based on Secure Multi-Party Computation (SMPC): Shamir Secret Sharing Initialization; Parameter settings: Total number of coordinating nodes is n (n≥5), threshold t=3 (i.e., at least 3 nodes need to cooperate to decrypt). Choose a large prime number p, satisfying p> maximum gradient value (to ensure the safety of finite field operations).

[0090] Secret Division: The central server treats the gradient value G as a secret s and randomly generates t. The first-degree polynomial f(x) = s + a1x + a2x² + +at 1xt 1, where ai is a random coefficient.

[0091] Calculate n shares and distribute them to n coordinating nodes C1, C2, ..., Cn.

[0092] Multi-party collaborative decryption process; Share collection: At least t=3 coordinating nodes (such as Ci, Cj, Ck) exchange their respective shares si, sj, sk through a secure channel.

[0093] Lagrange interpolation recovery: The original gradient is calculated using the Lagrange interpolation formula.

[0094] Federal Average (FedAvg) is implemented; Gradient aggregation; Weighted average: Each coordinating node collects the gradients {g1, g2, ..., gm} uploaded by the participants (clients) and calculates weights based on the amount of data each client has. In a distributed training environment, each client (participant) independently calculates the model gradient based on its local dataset. Assuming there are m participants, and each client i has a local data volume of di (e.g., the number of samples), after the coordinating node (e.g., the server) collects the gradients {g1, g2, ..., gm} uploaded by all clients, it needs to assign weights wi to each client. The weight calculation formula is: This formula, through a normalization operation, ensures that the sum of all weights satisfies... This ensures the numerical stability of gradient aggregation. Meanwhile, the weight wi directly reflects the proportion of client i's data volume in the global dataset; clients with larger data volumes contribute more to the aggregation result.

[0095] Gradient aggregation: Based on the calculated weights, the coordinating nodes perform a weighted average aggregation operation to generate a globally updated gradient (Gavg). The aggregation formula is as follows: This formula achieves the fusion of training results from data of different scales by multiplying the gradient gi of each client with its corresponding weight wi and then summing the results.

[0096] Security aggregation optimization: Homomorphic encryption: The client uses Paillier homomorphic encryption to encrypt the gradient gi before uploading it. The coordinating node directly performs a weighted average on the ciphertext, and finally the central server decrypts it to obtain Gavg.

[0097] Differential privacy: To add noise to the aggregated forward gradient, the noise source is a Laplace distribution. The gradient after adding noise is represented as follows:

[0098] Here, Δf represents sensitivity, which measures the maximum impact of a single data point in the dataset on the final computation result (such as the gradient). Privacy budget is a parameter that controls the strength of privacy protection. The smaller the value, the greater the added noise and the higher the degree of privacy protection, but at the same time, it will increase the perturbation of the original gradient information, which may affect the performance of the model.

[0099] Model parameter quantization and compression (FP32→INT8); Linear quantization algorithm: Parameter mapping: In the process of converting a 32-bit floating-point number to an 8-bit integer, the range of the floating-point number is mapped to the range of the 8-bit integer [-128, 127]. First, the scaling factor S needs to be calculated, and its formula is as follows: Here, xmax and xmin represent the maximum and minimum values ​​in the original set of 32-bit floating-point numbers, respectively. Next, the zero-point offset Z is introduced, which is calculated as follows: This zero-point offset is used to adjust the quantized integer, making the quantization process more accurate. For each 32-bit floating-point number x, the formula q = round(Sx) + Z is used to map it to an 8-bit integer q. Here, the round function represents rounding the calculation result. In this way, the original 32-bit floating-point number x is converted into an 8-bit integer q, thus realizing the quantization process.

[0100] Dequantization: The process of restoring the quantized 8-bit integer q to its original floating-point form (or approximately the original floating-point form) is called dequantization. The formula for dequantization is x′=S.(q Using the previously calculated scaling factor S and zero offset Z, the quantized 8-bit integer q is processed. By subtracting the zero offset Z from q and then multiplying by the scaling factor S, we can convert the 8-bit integer q back to a form close to the original 32-bit floating-point number x, thus ensuring that the model can perform calculations and predictions based on reasonable data during inference.

[0101] Optimization strategy, adaptive threshold: Calculate xmin and xmax for each channel of the model weights to improve quantization accuracy. Training-aware quantization: Insert pseudo-quantization nodes during model training to allow the model to adapt to quantization errors.

[0102] Coordinating nodes jointly sign; Threshold signature scheme: Key generation: The threshold cryptography student generates a collective private key sk and divides it into n shares sk1, sk2, ..., skn, with each coordinating node holding one copy.

[0103] Signature generation: At least t=3 coordinating nodes collaborate to generate a signature σ for the quantized model parameters PINT8: each node calculates a partial signature σi. The partial signatures are merged to obtain the complete signature σ=Combine(σi,σj,σk).

[0104] In the verification process, other nodes use the collective public key pk to verify the validity of the signature σ, ensuring that the model parameters have not been tampered with.

[0105] Model weight distribution: The distribution process is as follows: The coordinating node broadcasts the encrypted global model through a Content Delivery Network (CDN); upon receiving the model, each operator verifies the signature chain (coordinating node → participant certificates); decrypts and loads the weights locally; evaluates the model performance on a local validation set and feeds back the metrics to the coordinating node. The following is a detailed design of the CDN-based encrypted model weight distribution and verification scheme: Model encryption and CDN distribution architecture: Encryption strategy: Hybrid encryption. The central server uses the operator's public key (obtained from the blockchain DID document) to perform AES symmetric encryption on the global model parameter P, generating ciphertext C = AESk(P). The symmetric key k is then encrypted using the operator's public key PK operator(k): K = RSAPK operator(k). The final distributed content is (C, K, signature chain).

[0106] CDN distribution optimization: Sharding and caching: Model parameters are divided into multiple blocks C1, C2, ..., Cn and cached through CDN edge nodes to improve download speed. HTTP / 3 and QUIC protocols are used to ensure transmission reliability and support resuming interrupted downloads.

[0107] Intelligent routing: CDN dynamically selects the optimal node for content distribution based on the operator's geographical location and network conditions.

[0108] Signature chain verification process: Three-level verification mechanism: Coordinating Node Signature Verification: The operator verifies whether the model parameters distributed by the CDN have the joint signature of the coordinating node σ, and the coordinating node uses the collective public key PK for collective verification.

[0109] Certificate chain verification: Obtain the participant's DID document from the blockchain and verify the certificate path: RootCA → Operator CA → Coordinator node certificate → Model signature; Timestamp verification: Check the model distribution timestamp T to ensure it is within the validity period (to prevent replay attacks).

[0110] Local decryption and model loading: The decryption process involves the operator using the private key SK to decrypt K and obtain the symmetric key k: k = RSASK operator(K).

[0111] Decrypt the ciphertext C using k: P = AESk(C).

[0112] Model loading optimization, quantization-aware loading: dequantize the INT8 quantized model parameters into FP32 format, and combine the scaling factor and zero offset of training-aware quantization.

[0113] Incremental update: Only the changed parts of the model are downloaded and updated (differences are identified through hash verification), reducing the amount of data transferred.

[0114] Local validation and performance feedback, multi-dimensional evaluation metrics: Model quality: Calculate metrics such as accuracy, F1 score, and AUC on the local validation set. Robustness: Test model performance under adversarial examples (such as FGSM attacks) and calculate robust accuracy. Privacy leakage risk: Use Membership Inference Attack to assess the risk of training data leakage.

[0115] Feedback mechanism and secure aggregation reporting: Operators encrypt evaluation metrics and report them through secure multi-party computation to prevent metric leakage. After the coordination nodes aggregate the feedback, differential privacy is used to generate a global performance report.

[0116] Closed-loop optimization mechanism: Dynamic parameter tuning: The coordinating node adjusts the training strategy for the next round based on the F1-score feedback from each participant. The implementation of the dynamic parameter tuning strategy includes: feedback metric collection and analysis, the coordinating node maintaining the participant performance table {Participant_ID:{F1-score,Local_Epochs,Upload_Frequency}}, and collecting the F1-score of each participant on the local validation set after each round of federated learning.

[0117] The adaptive parameter adjustment algorithm is as follows: Initialization and Data Preparation: When the algorithm starts running, the coordinating node collects the F1 scores obtained by each participant on the local validation set, as well as information such as the number of local training epochs and gradient upload frequency of the current participant. This data is then organized into a specific data structure for subsequent processing. Performance Range Judgment and Parameter Adjustment: For each participant, the algorithm executes different parameter adjustment strategies based on the range of its F1 score. F1 score less than 0.7: This indicates that the model's performance on that participant is poor. In this case, the algorithm increases its local training epochs by 2 epochs each time, but to avoid overtraining leading to resource waste and model overfitting, the upper limit of the local training epochs is set to 10 epochs. F1 score greater than 0.9: This means that the model's performance on that participant is excellent. To reduce unnecessary communication overhead, the algorithm reduces its gradient upload frequency by half each time, but to ensure timely model updates, the lower limit of the gradient upload frequency is set to upload every epoch. F1 score between 0.7 (inclusive) and 0.9 (inclusive): This represents that the model's performance is at a moderate level. The algorithm fine-tunes the learning rate: if the F1 score is less than 0.85, the learning rate is multiplied by 0.95 to decrease it; if the F1 score is greater than or equal to 0.85, the learning rate is multiplied by 1.05 to increase it. Generating an updated parameter set: The algorithm generates corresponding updated parameters for each participant and compiles these parameters into a set. This set contains the parameters that each participant needs to update and their corresponding values. Parameter distribution and application: The coordinating node encrypts the set containing the updated parameters and embeds it into the model distribution content for the next round. After receiving and decrypting the model distribution content, each participant automatically updates its local training configuration based on the information in the updated parameter set, thus making the adjusted parameters effective in subsequent training processes.

[0118] Anomaly Handling: When an anomaly in gradient is detected (such as a sudden increase of 10 times in norm): Freeze the model update permissions of the participant, trigger the blockchain smart contract to record the suspicious event, and require manual review to restore the participant's eligibility.

[0119] The implementation of key algorithms includes: Graph neural network modeling; Node definition: Each SIM card, as a node in the graph, contains the following characteristics: node_features={ 'static': [Network access duration, package type, credit score], #from blockchain identity chain 'dynamic': [Call frequency and data usage trend in the past 7 days] #Updated in real time from the behavior chain } Edge relation definition: Call relationship edge: caller → called party, weight = call duration × intimacy coefficient (calculated through frequent pattern mining). Device association edge: Different SIM cards logged in from the same device, weight = device credibility score.

[0120] Input layer: Each node (SIM card) carries a 16-dimensional feature vector (which may include: network access duration, plan type, recent call count, etc.). Edges represent the calling and called relationships. For example, in edge_index, [0→1] indicates that node 0 is calling node 1. Graph Convolutional Layer (GCNConv): Map node features from 16 dimensions to 32 dimensions; Aggregate information about each node and its direct neighbors (first-order neighborhood). Mathematical operations: (where A^ is the adjacency matrix with self-connections, and W is the learnable weights); Attention layer (GATv2Conv): An attention mechanism is introduced based on 32-dimensional features; Calculate dynamic weights for each edge (e.g., edges that identify high-frequency calls are more important). Output 64-dimensional high-order features to capture complex interaction patterns; Forward propagation process of data stream: Initial feature input: Assume there are 4 cards (nodes 0-3), and each node has an initial feature of 16 dimensions; Graph convolution operation: Processing node 1: Aggregate the features of nodes 0 and 2 (because it is called by 0 and also by 2); Filter negative values ​​using the ReLU activation function: ReLU(x) = max(0,x) Attention calculation: Calculate the attention score for each edge (example):

[0121] Final output: Each node obtains a 64-dimensional feature vector, which includes: its own attribute encoding; a weighted summary of neighbor information; and key features of the interaction pattern.

[0122] Federated learning parameter aggregation: Gradient preparation phase: Each participant locally computes encrypted gradients. Cross-institutional transmission: A three-phase commit protocol ensures consistency. Participant → Coordinating Node: Submits gradient hash commitment; Coordinating Node → Participant: Confirm Receipt; Participant → Coordinating Node: Sends the real encrypted gradient; Robust aggregation: Filter out outlier gradients exceeding μ±3σ; use geometric median aggregation for the remaining gradients.

[0123] The following is a detailed design of the federated learning parameter aggregation scheme: Gradient preparation phase; Local gradient calculation: Each participant (such as the operator) trains the model locally using its own data and calculates the gradient of the model parameters. The gradient represents the direction and magnitude of the model parameter updates and is a core piece of information that needs to be shared in federated learning.

[0124] Gradient encryption: To protect data privacy, the participants encrypt the calculated gradients. Encryption methods can employ homomorphic encryption (such as Paillier encryption) or differential privacy techniques to ensure that the gradients do not leak the original data information during transmission and aggregation.

[0125] Preprocessing optimization: Before encryption, participants may quantize and compress the gradient (e.g., FP32→INT8) or add noise to further reduce communication overhead and improve privacy protection.

[0126] Cross-agency transmission; In the gradient hash commitment phase, hash generation occurs when participants calculate the hash value of the cryptographic gradient (e.g., SHA-256). This hash value is unique and can be used to verify data integrity. Commitment occurs when participants send the gradient hash value (not the actual gradient) to the coordinating node as a "commitment" indicating the gradient content they will subsequently send.

[0127] During the acceptance and confirmation phase, the coordinating node verifies the hash commitments received from all participants, checking the hash format and timestamp validity to ensure the commitments are legitimate. The coordinating node then sends an acceptance confirmation (ACK) to all participants, indicating its readiness to receive the actual gradient data.

[0128] During the actual gradient transmission phase, secure channel transmission: Participants send the actual encrypted gradient to the coordinating node via a secure encrypted channel (such as TLS 1.3). Hash consistency verification: After receiving the encrypted gradient, the coordinating node recalculates its hash value and compares it with the previously received commitment to ensure that the data has not been tampered with. If they do not match, the data is rejected.

[0129] The dynamic weight aggregation algorithm employs multi-dimensional weight calculation: the coordinating node assigns dynamic weights to each participant based on multiple dimensions of metrics, including: Data quality weight: based on the participant's F1 score on their local validation set; a higher F1 score indicates better model performance on that participant's data, resulting in a larger weight. Data volume weight: weights are assigned based on the proportion of samples provided by the participant to the total; larger data volumes result in higher weights. Communication reliability weight: considering historical transmission success rates and latency, participants with stable transmission and low latency receive higher weights.

[0130] Overall weight calculation: The weights of the above multiple dimensions are multiplied and normalized to obtain the final dynamic weight. For example, if a participant has a high F1 score, a large amount of data, but high communication latency, its overall weight may be at an intermediate level.

[0131] Weighted aggregation execution: The coordinating node uses dynamic weights to perform weighted aggregation of the cryptographic gradients of each participant. If homomorphic encryption is used, the aggregation can be performed directly on the ciphertext, ensuring privacy.

[0132] Robust aggregation: Anomaly Gradient Filtering: Before robust aggregation begins, the gradient data uploaded by all participants must be analyzed. The mean (μ) and standard deviation (σ) of all gradients in each dimension are calculated. The mean represents the central tendency of all gradients in that dimension, while the standard deviation reflects the dispersion of these gradients in that dimension. For each gradient in each dimension, the degree of difference from the mean is calculated, i.e., the Z-score. If the absolute value of the Z-score for a gradient in any dimension is greater than 3, it means that this gradient differs too much from the overall data in that dimension, and is considered an anomaly gradient. All such anomaly gradients are filtered out of the dataset, retaining only those gradients that are relatively normal in all dimensions for subsequent aggregation calculations.

[0133] Geometric Median Aggregation of Residual Gradients: After outlier filtering, the remaining gradient data is considered relatively reliable. Next, these remaining gradients are processed using geometric median aggregation. The goal of geometric median calculation is to find a vector (i.e., the aggregated gradient) that minimizes the sum of distances to all remaining gradient vectors. The specific calculation process is as follows: First, an initial vector is randomly selected as the estimated geometric median. Then, this estimate is iteratively updated. In each iteration, the distance from each remaining gradient vector to the current estimate is calculated, and the weight of each gradient vector is calculated based on these distances (the smaller the distance, the larger the weight). Then, all remaining gradient vectors are weighted and summed according to these weights to obtain a new estimate. This process is repeated until the difference between the new estimate and the previous estimate is less than a pre-set small threshold. The resulting estimate is the geometric median of these remaining gradients, which is the final result of this robust aggregation. This geometric median will be used to update the global model of federated learning, making the model more stable and accurate, and reducing the negative impact of outlier gradients on model training.

[0134] Real-time feature engineering Key feature calculation

[0135] Feature storage optimization Hot feature: Redis cluster storage, supports queries with a latency of <10ms; Cold features: Stored in HBase, and SQL queries are performed using Phoenix; Feature version control: Each update generates a feature snapshot hash and adds it to the blockchain; Decision-making and execution level: Data reporting phase: Base station edge nodes collect encrypted user communication behavior data in real time, including: number of calls within 5 minutes, movement speed (based on base station handover), hardware-level device hash and encryption method, etc.

[0136] Security requirements: Data signing is performed using the security chip built into the SIM card; transmission is via a TLS 1.3 encrypted channel.

[0137] Edge AI model (lightweight GNN) processing logic: Data Decryption: Input is decrypted within the Trusted Execution Environment (TEE), specifically including: TEE Environment Initialization: During edge computing node deployment, the Trusted Execution Environment (TEE) is pre-initialized and configured. Dedicated secure boot firmware is loaded to verify the integrity and security of the TEE, ensuring it is protected against external malicious attacks. Simultaneously, strict access control policies are set, allowing only authorized edge AI model processes to access the decryption function within the TEE. Key Management: To ensure the security of data decryption, a multi-layered key management system is adopted. During system initialization, a master key is generated by a key generation center, and an encrypted copy of the master key is stored in the secure storage area of ​​the edge computing node through a secure key distribution mechanism. When data decryption is required, the edge computing node uses a local trusted hardware module (such as a Trusted Platform Module (TPM)) combined with a specific key derivation algorithm to derive a session key from the master key for decrypting the current data. The session key is destroyed immediately after use to prevent the risk of key leakage. Data Verification and Decryption Process: Before sending encrypted data into the TEE for decryption, the data integrity is verified. The Message Authentication Code (MAC) technology is used to verify the MAC value attached to the encrypted data, ensuring that the data has not been tampered with during transmission. If the MAC verification passes, the TEE uses the session key to decrypt the encrypted data. The decrypted data is temporarily stored in a secure buffer within the TEE and is promptly cleared after subsequent processing to prevent sensitive data from remaining in memory for extended periods.

[0138] Real-time Inference: Input behavioral features into a pre-trained fraud detection model; output a risk score (0-100 linear scale). Specifically: Model Optimization and Loading: To meet the performance requirements of real-time inference, a lightweight graph neural network (GNN) fraud detection model is specifically optimized. Model pruning techniques are used to remove redundant connections and parameters, reducing the model's computational load and storage requirements. Simultaneously, quantization techniques are used to convert model parameters from high-precision data types (e.g., FP32) to low-precision data types (e.g., INT8), improving the model's inference speed while ensuring acceptable accuracy loss. Upon startup of the edge computing node, the optimized model is loaded from local storage or a remote model server into memory and preheated to ensure a rapid response when data is received.

[0139] Feature Preprocessing and Input: Real-time feature preprocessing is performed before inputting behavioral features into the pre-trained fraud detection model. Appropriate normalization and encoding methods are used for different types of behavioral features. For example, for numerical features such as call counts, Z-score normalization is used to map them to a specific interval, enhancing the model's convergence speed and stability; for categorical features such as device fingerprints, one-hot encoding or hash encoding is used to ensure effective model recognition. The preprocessed behavioral features are then organized and arranged according to the model input requirements, forming a suitable tensor structure before being input into the model.

[0140] Inference Process and Acceleration: During model inference, the hardware acceleration capabilities of edge computing nodes, such as GPUs or dedicated AI accelerators (e.g., NPUs), are utilized to accelerate the model's computation. For graph convolution operations in GNN models, optimized algorithms and parallel computing techniques are employed to fully utilize hardware resources and improve computational efficiency. Simultaneously, considering the model's structural characteristics, a caching mechanism is used to store intermediate computation results, avoiding redundant calculations and further enhancing inference speed. After inference is complete, the raw risk score output by the model undergoes post-processing, such as using the sigmoid function to map the score to a linear scale range of 0-100, making it more intuitively reflect the degree of risk.

[0141] Evidence package generation: This includes hashes of key features used for scoring, specifically key feature extraction and hash calculation. Based on a predefined list of key features, key features for generating the evidence package are extracted from the decrypted data and the model inference process. For example, for call behavior data, features such as call duration, call interval, and the relationship between the calling and called numbers are extracted; for device information, features such as device type, device ID, and device login time are extracted. For each key feature, a secure hash algorithm (such as SHA-256) is used to calculate its hash value. To ensure the consistency and verifiability of the hash calculation, the hash calculation process is standardized, including strict regulations on the encoding format of the feature data and the parameter settings of the hash algorithm.

[0142] Evidence Package Assembly and Signing: The calculated key feature hash values ​​are assembled according to a specific format to form an evidence package. The evidence package can use lightweight data formats such as JSON or CBOR for easy storage and transmission. After assembly, the evidence package is digitally signed using the private key of the edge computing node to ensure its integrity and authenticity. The Elliptic Curve Digital Signature Algorithm (ECDSA) can be used for the digital signature, offering high security and computational efficiency. The signed evidence package can be stored in a local cache and uploaded to the blockchain or other storage media for later use.

[0143] Blockchain decision-making stage: Executor: Smart Contract (on-chain); Triggering Conditions: Receiving a risk score (containing a digital signature) from an AI model; Verifying the legitimacy of the data source (through Validator node verification). Specific implementation includes: Risk Score Reception and Preliminary Verification: The smart contract continuously listens to a specific message channel on the blockchain, dedicated to receiving risk scores from AI models. Upon receiving risk score data, it first performs preliminary verification of the data format to ensure it conforms to a preset structure and includes necessary fields such as the card identifier, risk score value, and digital signature. Next, using a built-in signature verification algorithm, combined with the public key corresponding to the AI ​​model (stored in a trusted location on the blockchain), it verifies the validity of the digital signature, preliminarily determining whether the risk score originates from a legitimate AI model. Validator Node Verification Enhancement: The Validator node, as a crucial verifier of the data source's legitimacy, maintains a list of authorized AI model nodes. When the smart contract receives a risk score, it sends a verification request to the Validator node, including the risk score data and related metadata. Upon receiving the request, the Validator node not only verifies whether the AI ​​model node is on the authorized list but also checks the node's recent operating status and reputation record. For model nodes with low credibility or exhibiting abnormal behavior, the Validator node will refuse validation. Furthermore, the Validator node employs a multi-signature mechanism, requiring multiple Validator nodes to jointly sign and confirm the legitimacy of the data source before validation can pass, thus enhancing the reliability and security of the validation process.

[0144] Contract Logic: If the risk score is greater than or equal to 90, the core network disconnection interface is invoked; if the risk score is greater than or equal to 70, secondary authentication is triggered. Implementation Details: Risk Level Assessment and Threshold Adjustment: In addition to the existing 70 and 90 thresholds, the smart contract introduces a dynamic threshold adjustment mechanism. Based on historical risk data, the current network environment, and trends in fraudulent behavior, the risk threshold is adjusted periodically or in real-time. For example, during periods of high fraud activity, the threshold for triggering action is appropriately lowered; when the network environment is stable and the fraud risk is low, the threshold is raised to balance security protection and user experience. Simultaneously, the risk score is further subdivided into multiple levels, such as low risk (0-59 points), low-to-medium risk (60-69 points), medium risk (70-89 points), high risk (90-99 points), and extremely high risk (100 points), allowing for more refined handling strategies for different levels. Core Network Interface Call and Secondary Authentication Process Optimization: When the risk score reaches the corresponding threshold and triggers action, the interaction process between the smart contract and the core network system is optimized. When invoking the core network disconnection interface, the smart contract first sends a pre-disconnection notification to the core network, including detailed data such as SIM card information and risk scores. This allows the core network to prepare in advance and ensures the disconnection operation is executed quickly and accurately. For cases triggering two-factor authentication, the smart contract deeply integrates with the authentication service contract. Based on the user's historical behavior data and current risk status, it intelligently selects an appropriate two-factor authentication method, such as SMS verification code, facial recognition, or fingerprint recognition, improving authentication accuracy and user acceptance. Simultaneously, during the two-factor authentication process, a reasonable number of retries and time intervals are set to avoid causing excessive inconvenience to users.

[0145] On-chain data includes: risk scores and timestamps; Merkle proofs of action taken; and AI model version hashes (ensuring traceability). Specific implementations include: Risk score and timestamp processing: When risk scores and timestamps are uploaded to the blockchain, a more precise time recording method is used, accurate to the millisecond level, ensuring the accuracy and uniqueness of the time. Simultaneously, to prevent timestamp tampering, a trusted time source provided by a blockchain timestamp server is used for calibration. For risk scores, in addition to recording the score value itself, the calculation process and related parameters, such as model version and feature data, are also recorded for subsequent detailed analysis and traceability. Merkle proof generation and verification optimization: When generating Merkle proofs for action taken, the smart contract hashes all key data involved in the action and constructs a Merkle tree. The Merkle tree construction process uses an optimized algorithm to improve computational efficiency. Furthermore, the Merkle proof includes more auxiliary information, such as the root hash of the Merkle tree, the position and number of leaf nodes, etc., facilitating rapid verification by other nodes. When verifying Merkle proofs, blockchain nodes can quickly determine the authenticity and legality of actions by verifying the integrity and consistency of the Merkle tree. AI model version hash management: To ensure the traceability of AI model versions, smart contracts establish an AI model version management database, recording detailed information for each version, including version number, release date, model architecture, training data, etc. When recording the AI ​​model version hash, not only the hash value is recorded, but it is also associated with the corresponding model version information. In subsequent traceability requests, the hash value can be used to quickly retrieve detailed version information of the model, understand the characteristics and performance of the model at different stages, and provide a basis for analyzing the accuracy and reliability of risk scoring.

[0146] Operator Implementation Phase: Executor: Operator core network system Action type:

[0147] Execution delay: Average time from smart contract call to instruction taking effect: 4G network: <800ms; 5G network: <200ms; User feedback: Network outage scenario: The terminal receives the RRCConnectionRelease signaling; the duration is set according to the risk level (e.g., 24 hours for high-risk freeze).

[0148] Secondary authentication scenario: Triggers a system-level authentication pop-up (covering all application layers); after 3 consecutive failures, it automatically escalates to network disconnection.

[0149] The data storage structure of the smart contract includes: a risk score mapping table, key: SIM card address (e.g., the blockchain account address corresponding to a mobile phone number), value: the real-time risk score of the SIM card (uint type, range 0-100); visibility: public allows public querying on the chain; The verification node list stores the addresses of edge computing nodes authorized to submit scores, preventing unauthorized nodes from tampering with risky data. The implementation process of smart contracts includes: Submitting a risk score (submitScore) includes: Permission verification: The caller must be a pre-registered verification node (checked via isValidator); Data update: Write the risk score of the designated card (cardID) into the blockchain state; Event broadcast: Triggers the ScoreUpdated event to notify all nodes across the network of the score change; The `executeAction` function is used to perform actions such as forced network disconnection and two-factor authentication. The tiered strategies are as follows:

[0150] Automation features: Triggered by blockchain transactions, ensuring that the processing actions are immutable; interfacing with the operator's system off-chain (oracle support required).

[0151] Safety and compliance design: Access control: Only whitelisted nodes (such as edge servers deployed on the base station side) are allowed to submit scores; prevent malicious forgery of risky data.

[0152] Data is immutable: once a score is recorded on the blockchain, it can only be updated through new, legitimate transactions; historical records are permanently traceable. Regulatory compliance: All actions are recorded on the blockchain to meet the audit requirements of the Cybersecurity Law; high-risk operations (such as network outages) require multi-node signature confirmation.

[0153] S1. The user submits their ID card information and undergoes a liveness detection.

[0154] The operator node verifies the user's submitted ID information and liveness detection results. If the verification is successful, a user biometric hash is generated, the relevant information is written into the identity chain, and an NFT certificate is issued to the user.

[0155] S2, Behavioral Dynamics Modeling, specifically includes: Key features (such as time, location, and device information) are extracted from Call Detail Records (CDRs). After analysis and processing, three core features are output: time entropy value, which quantifies the degree of anomaly in call time distribution; geographic movement speed, which detects rapid location changes that do not conform to physical laws; and device fingerprint, which generates a unique identifier for the device to identify device tampering. Based on these core features, potential fraudulent activities (such as abnormal calls and device forgery) can be identified.

[0156] The calculation logic for time entropy is to calculate Shannon entropy by counting the number of calls per hour, and then determine whether there is an anomaly based on the entropy value: For normal users, call time is usually concentrated during the day, and the entropy value is low (e.g., 1.2). For fraudulent behavior: robot calls may be evenly distributed, and the entropy value is high (e.g., 3.5).

[0157] The calculation logic for geographic movement speed is to calculate the maximum distance (in kilometers) between consecutive call locations. If the movement distance exceeds 500 kilometers within 5 minutes, it may be a fake base station or SIM card cloning. The speed is then calculated in conjunction with the time difference (total_time) (e.g., 2000 km / h is abnormal).

[0158] The device fingerprint generation logic uses fuzzy hashing (the same device generates the same value, and similar devices generate different values). Multiple SIM cards for the same device → identical fingerprints → may indicate a SIM card pool device; frequent fingerprint changes → may indicate malware tampering.

[0159] S3, cross-chain risk decision-making, allows authorized nodes to vote on the fraud risk of designated card IDs. If the risk score exceeds a threshold, a network-wide ban is triggered, including: Permission verification: The caller address msg.sender must be in the predefined authorizedNodes whitelist. Transactions that fail verification will be automatically rolled back (the consumed gas will not be refunded).

[0160] Only edge computing nodes deployed by operators are allowed to participate in voting to prevent malicious addresses from launching false accusations.

[0161] Risk score query: The real-time risk score (0-100) calculated by the off-chain AI model can be queried through the oracle contract AIOracle.

[0162] Scoring criteria: ≥90 points: Confirmed as fraud (e.g., fake base station activity); 70-89 points: High risk, manual review required; <70 points: Normal user; Threshold determination and execution: Event broadcast: If the risk score is greater than the threshold, a FraudAlert event is triggered, which includes: the address of the offending card (cardID) and the timestamp of the ban (block time on the blockchain).

[0163] Status Update: Mark the card number as banned in the blacklist mapping table; Effective across the entire network: All nodes synchronize their blacklist status; other contracts can check the ban status via blacklist[cardID].

[0164] Example 2 Bulk account opening and authentication for IoT cards: Step 1: Enterprise users upload a device list and a video verifying the legal representative's identity. Security requirements include: the video must include live actions such as blinking and head shaking; the device list must be SHA-256 signed to prevent tampering. Specifically, enterprise users initiate an account opening application on the IoT SIM card batch account opening platform, uploading a device list and a video verifying the legal representative's identity. During video capture, the system prompts the legal representative to perform live actions such as blinking and head shaking to ensure the authentication is genuine and prevent deception using photos or videos. The device list is provided in spreadsheet format, containing key information such as the device's IMEI number. Before uploading, enterprise users use encryption software to SHA-256 sign the device list, generating a signature file. During the upload process, the platform uses a TLS 1.3 encrypted channel to transmit data, preventing data theft or tampering during network transmission. After upload, the platform verifies the integrity of the uploaded video and device list to ensure data integrity and accuracy.

[0165] Step 2: Automated Verification Legal Representative Identity Verification: This involves extracting facial features from video footage and using OCR information from the ID card; then comparing the data using the API provided by the State Administration for Industry and Commerce. Specifically, after receiving data uploaded by the enterprise user, the platform first processes the legal representative authentication video. Using advanced video analytics, it extracts the legal representative's facial features from the video and simultaneously uses OCR (Optical Character Recognition) technology to recognize the text information on the ID card. The extracted facial features and ID card OCR information are then integrated and compared using the API provided by the State Administration for Industry and Commerce. During the comparison process, the platform verifies whether the legal representative's name, ID card number, facial features, and other information match the records in the State Administration for Industry and Commerce's database. If the comparison results are inconsistent or valid data cannot be obtained, the platform will promptly notify the enterprise user to resubmit the authentication information and record this anomaly.

[0166] Device white list verification: Connect to the GSMATAC database (Global IMEI Number Segment Registry), and the verification logic requires 100% matching to pass. Specifically, for the IMEI numbers in the device list, the platform connects to the GSMATAC database (Global IMEI Number Segment Registry) for verification. The verification logic strictly requires that the IMEI numbers in the device list must match 100% with the records in the database to be considered passed. During the data interaction process, a secure data transmission channel is established between the platform and the GSMATAC database to ensure the confidentiality and integrity of the data. If there are devices with unmatched IMEI numbers or inconsistent information, the platform will mark these devices and inform the enterprise users of the specific reasons for non-pass, and require the enterprise users to verify the device information and resubmit.

[0167] Step 3: Smart contract generation. The contract functions include basic attributes, permission management, key methods, etc. Specifically, if both the legal person identity verification and the device white list verification are passed, the platform will automatically trigger the smart contract generation process. The smart contract is developed based on blockchain technology and is written in programming languages such as Solidity. The contract has rich functions. The basic attributes include basic information such as contract name, version number, creation time, etc.; permission management clearly defines the operation permissions of different participants. For example, enterprise users have the permission to query the account opening status of IoT cards and manage the already opened devices, while platform administrators have higher management permissions, such as reviewing and handling abnormal account opening situations, etc.; the key methods cover core operations such as account opening, activation, and cancellation of IoT cards. After generating the smart contract, the platform will deploy the contract to the blockchain network and return the contract address and management permissions to the enterprise users. Enterprise users can monitor and manage the account opening process of IoT cards in real time through the blockchain browser or the management interface provided by the platform according to the returned contract address and management permissions.

[0168] Example 3 Cross-border roaming fraud interception: Step 1: AI real-time detection. The input data sources include: international roaming signaling (CAMEL protocol / 5GNchf interface), IMSI, current location, called number, call start time, etc.

[0169] Analyze the call detail record (CDR) through predefined rules and output a risk score. The predefined rules are as follows:

[0170] A sliding window counting algorithm is used to count the number of calls. Within each minute's sliding window, if the number of calls exceeds 5 and each call duration is less than 60 seconds, the high-frequency short call rule is triggered. The international call status of the new SIM card is determined by comparing the activation timestamp with the base station's country code. If the activation time is less than 1 hour and the country of origin differs from the country of destination, the international call rule for the new SIM card is triggered. For called numbers, the Shannon entropy algorithm is used to calculate their distribution. If the entropy value of the called number is less than 0.3, it indicates that the called number distribution is extremely concentrated, and the destination clustering rule is triggered. To improve computational efficiency, parallel computing technology can be used to analyze and process a large number of call records simultaneously.

[0171] Risk scoring calculation includes: traversing all call records and evaluating each record according to predefined rules. Each rule returns a matching score from 0 to 100 based on the degree of matching. For example, for international call rules for new cards, a higher matching score, such as 80, is returned if the activation time is less than 30 minutes and the country of origin is different from the country of origin; a lower score, such as 50, is returned if the activation time is between 30 minutes and 1 hour. The final risk score is the highest matching score among all rules, which comprehensively assesses the risk level of the call. During the scoring process, machine learning algorithms can be introduced to dynamically adjust the rule scores, optimizing the rule weights and scoring criteria based on historical fraud data and actual interception results, thereby improving the accuracy of risk scoring.

[0172] Output risk scores and evidence packages.

[0173] The output risk score ranges from 0 to 100, with an initial threshold of 90 points, dynamically adjusted based on actual operational conditions and risk profile. The calculation process and results of the risk score are recorded in local logs for subsequent querying and analysis. Simultaneously, an evidence package containing hashes of key features is generated. These key features include the call's IMSI, called number, call duration, and location information. Hash algorithms such as SHA-256 are used to calculate fixed-length hash values ​​for these key features, ensuring the integrity and immutability of the evidence package. The evidence package is stored along with the risk score and submitted to subsequent processing stages when necessary.

[0174] Step 2: Blockchain consensus verification, including: Edge nodes submit encrypted AI evidence to the blockchain. Specifically, after completing real-time AI detection, the edge nodes encrypt the generated risk score and evidence package. Encryption algorithms such as AES-256 are used, combined with the edge node's private key, to ensure data security during transmission. The encrypted data is then submitted to the blockchain through the blockchain network's interface. During submission, digital signature technology is used to authenticate the data source, preventing data tampering or forgery. The edge nodes package the encrypted data, signature, and related metadata (such as timestamps and device identifiers) into a transaction and broadcast it to the blockchain network.

[0175] Off-chain, the home operator node (e.g., China Mobile) decrypts and verifies the original call detail records (CDRs) and checks for risks associated with international settlement account balances. Specifically, after receiving encrypted data from the blockchain, the home operator node (e.g., China Mobile) decrypts it off-chain using the corresponding private key. After decryption, it verifies the original CDRs, checking their authenticity and completeness, including verifying the call time, location, and duration against the actual situation. Simultaneously, it checks for risks associated with international settlement account balances. If abnormal transactions or insufficient balances are found in the user's international settlement account, the risk assessment for that call is increased. During the verification process, if any questions or anomalies are found in the data, the home operator node sends a query request to the edge node, requesting further verification of the data.

[0176] Fraud is confirmed through private key signing. Specifically, after verification, if the home operator node confirms a fraud risk in the call, it will sign the risk confirmation information using its private key. The signature information includes key content such as the risk score, evidence package digest, and verification result. The signed information is then submitted to the blockchain again as valid proof of fraud confirmation. Other operator nodes can verify the authenticity and validity of the signature by verifying the home operator node's public key. The Elliptic Curve Digital Signature Algorithm (ECDSA) is used during the signing process to ensure the security and non-repudiation of the signature.

[0177] Step 3: Execute synchronously across the entire network, including: Real-time synchronization: The Gossip protocol is used to propagate fraudulent information among operator nodes. Once the originating operator node confirms the fraud and signs it, it broadcasts the fraudulent information as a message across the blockchain network. Other operator nodes receive the message and verify and process it. The Gossip protocol ensures that information can be propagated quickly and reliably to all nodes. Each node, upon receiving a message, stores it in its local message queue and processes it according to message priority and timeliness. To improve synchronization efficiency, a layered synchronization mechanism can be used, dividing operator nodes into different layers. Higher-level nodes are responsible for aggregating and forwarding information, while lower-level nodes are responsible for receiving and processing specific fraudulent information.

[0178] Execution Feedback: The international gateway bureau intercepts the call upon receiving the first SYN packet and sends a fraud alert SMS to the user (supporting multiple languages). Upon receiving fraudulent information, the international gateway bureau intercepts the call upon receiving the first SYN packet, preventing the fraudulent call from proceeding. Simultaneously, a fraud alert SMS is sent to the user; the SMS content supports multiple languages, selecting the appropriate language version based on the user's location and language settings. The alert SMS includes fraud risk warnings, call details, and information on actions the user can take. During the interception process, the international gateway bureau records detailed interception information, including interception time, intercepted number, and risk score, and feeds this information back to the home operator node for subsequent statistical analysis.

[0179] Example 4: Figure 2 A block diagram of an exemplary electronic device suitable for implementing embodiments of the present invention is shown.

[0180] The electronic device may include a central processing unit / microprocessor / main control chip, etc. 4; and a storage medium 5, coupled to the central processing unit / microprocessor / main control chip, etc. 4, and storing computer-executable instructions therein for performing the steps of various methods of embodiments of the present invention when executed by the processor.

[0181] The central processing unit / microprocessor / main control chip, etc., can include, but are not limited to, one or more processors or microprocessors.

[0182] Storage medium 5 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, EPROM memory, EEPROM memory, registers, computer storage media (e.g., hard disk, floppy disk, solid-state drive, removable disk, CD-ROM, DVD-ROM, Blu-ray disc, etc.).

[0183] In addition, the electronic device may also include (but is not limited to) a data bus 6, an input / output bus / external bus / device bus 7, a display 8, and input / output devices 9 (e.g., keyboard, mouse, speaker, etc.).

[0184] The central processing unit / microprocessor / main control chip, etc. 4 can communicate with external devices (8, 9, etc.) via I / O bus 7 through wired or wireless network (not shown).

[0185] The storage medium 5 may also store at least one computer-executable instruction for performing the steps of various functions and / or methods in the embodiments described herein when the central processing unit / microprocessor / main control chip, etc., 4 is running.

[0186] In one embodiment, the at least one computer-executable instruction may also be compiled into or comprise a software product, wherein one or more computer-executable instructions are executed by a processor to perform the steps of the various functions and / or methods in the embodiments described herein.

[0187] Figure 3 A schematic diagram of a computer-readable storage medium according to an embodiment of the present invention is shown.

[0188] like Figure 3 As shown, the non-transitory computer-readable storage medium 11 stores instructions, such as computer-readable instructions 10. When the computer-readable instructions 10 are executed by a processor, the various methods described above can be performed. The non-transitory computer-readable storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-transitory non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. For example, the non-transitory computer-readable storage medium 11 can be connected to a computing device such as a computer, and then, when the computing device executes the computer-readable instructions 10 stored on the computer-readable storage medium 11, the various methods described above can be performed.

[0189] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0191] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0192] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for executing all or part of the steps of the methods of the various embodiments of this invention through a computer device (which may be a personal computer, server, or network device, etc.). The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0193] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A trusted authentication and anti-fraud system for SIM cards based on blockchain and AI, characterized in that, Include: The trusted evidence storage layer uses blockchain technology to securely store and verify identity credential data and user behavior log data related to the SIM card; The dynamic analysis layer employs artificial intelligence technology to construct user behavior graphs based on the data stored in the trusted evidence storage layer and to perform fraud risk analysis. as well as The decision execution layer is used to execute real-time risk management operations based on the risk analysis results of the dynamic analysis layer, through preset rules or smart contracts. The trusted evidence storage layer, dynamic analysis layer, and decision execution layer work together to achieve trusted authentication of SIM cards and the identification and handling of fraudulent activities.

2. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 1, characterized in that, The trusted evidence storage layer adopts an improved consortium blockchain architecture, wherein the nodes of the consortium blockchain architecture include at least regulatory agency nodes, operator nodes, and / or service provider nodes.

3. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 1, characterized in that, The trusted evidence storage layer further includes an identity chain and a behavior chain, forming a dual-chain collaborative storage system; The identity chain is mainly used to store tamper-proof user identity credential data and key status information of the SIM card lifecycle; The behavior chain is mainly used to store frequently generated user behavior log data; The identity chain and behavior chain are linked and can access each other's data through a cross-chain anchoring mechanism.

4. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 3, characterized in that, The cross-chain anchoring mechanism includes: embedding the hash value of the relevant identity record on the corresponding identity chain in the block header of the behavior chain, or realizing address mapping and data verification between the two chains through smart contracts.

5. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 4, characterized in that, The identity credential data includes at least user real-name authentication information, biometric template hash, SIM card account opening information, SIM card status change records, and black card identification markers; the key status information of the SIM card lifecycle includes at least registration, activation, suspension, cancellation, transfer, and reactivation status.

6. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 5, characterized in that, The user behavior log data includes at least call records, SMS records, network access records, App usage behavior, location information, device information, and hardware status events such as SIM card insertion / removal and power on / off. The identity chain uses PBFT (Practical Byzantine Fault Tolerance) or its improved algorithm as a consensus mechanism to ensure strong consistency and high security of identity data; the behavior chain adopts a consensus mechanism that balances efficiency and security, based on DPoS (Delegated Proof-of-Stake) or an improved PoW (Proof-of-Work) algorithm.

7. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 6, characterized in that, The identity chain includes federated learning, which is used to perform joint modeling by multiple institutions while protecting the data privacy of each participant. Each participant trains local GNN model parameters using its private data, shares model parameter updates or gradient information, and performs global model aggregation and updates through a federated aggregation server.

8. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 1, characterized in that, The dynamic analysis layer includes a graph neural network, which is used to construct a user behavior graph. The nodes of the user behavior graph include at least user nodes, SIM card nodes, device nodes, application nodes and / or location nodes, and the edges represent the association relationships and characteristic attributes of interactive behaviors between the nodes.

9. A SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 1, characterized in that, The dynamic analysis layer, through the user behavior graph, can capture users' long-term behavior patterns, short-term behavioral anomalies, and associations with known fraud nodes, and is particularly useful for identifying the historical behavioral characteristics of secondary accounts.

10. A SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 7, characterized in that, The dynamic analysis layer also includes a model management module, which is used to update the federated learning model and / or graph neural network model periodically or in real time based on new fraud samples and feedback data to adapt to constantly changing fraud methods.

11. A SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 6, characterized in that, The decision execution layer includes edge computing nodes and smart contracts deployed on the blockchain; The edge computing node is used to receive the risk analysis results of the dynamic analysis layer and perform rapid pre-judgment and preliminary handling locally; The smart contract is used to solidify risk management rules and automatically execute corresponding management operations when preset trigger conditions are met.

12. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 11, characterized in that, The dynamic analysis layer deploys a lightweight graph neural network model on the edge computing node to perform rapid risk scoring on real-time collected user behavior data. The response time of the risk scoring is less than 200 milliseconds.

13. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 12, characterized in that, The lightweight graph neural network model is obtained by performing model compression, parameter pruning, and / or knowledge distillation on the basic graph neural network model to adapt to the computing resources and low latency requirements of edge computing nodes.

14. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 13, characterized in that, The smart contract is linked with the edge computing node. When the risk score output by the lightweight GNN model of the edge computing node exceeds a preset threshold, the smart contract is triggered to perform corresponding risk handling operations. The risk handling operations include, but are not limited to: denial of service, suspension of SIM card function, requesting additional identity verification, marking abnormal accounts and notifying relevant parties.

15. A trusted authentication and anti-fraud system for SIM cards based on blockchain and AI as described in claim 14, characterized in that, The SIM card trusted authentication includes: verifying the existence, integrity, and validity of the identity credential data corresponding to the SIM card on the identity chain, and determining the consistency between the current usage behavior of the SIM card and the historical trusted behavior pattern by analyzing the behavior log data on the behavior chain.

16. The SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 15, characterized in that, It also includes a cross-chain data access interface, which allows authorized third-party applications or organizations to query or verify specific data in the trusted evidence storage layer, provided that privacy protection and data security regulations are met. Before being written into the identity chain, the identity credential data must undergo multi-signature verification by at least one authoritative institution node or multiple operator nodes to ensure its authenticity.

17. A trusted authentication and anti-fraud system for SIM cards based on blockchain and AI as described in claim 16, characterized in that, When the behavior log data is written into the behavior chain, it is solidified using chained hashing and timestamps, and can be efficiently batch verified using a Merkle tree structure.

18. A trusted authentication and anti-fraud system for SIM cards based on blockchain and AI as described in claim 17, characterized in that, During federated learning, the local data of each participant does not leave its own data center. Only model parameters or encrypted gradient information are transmitted between federated aggregation servers, and the transmission process is protected by secure multi-party computation or homomorphic encryption technology. The weights of the edges in the user behavior graph are dynamically adjusted according to the frequency, duration, type, and risk level of the corresponding interaction behavior. The graph neural network learns these dynamic weights to improve the accuracy of fraud risk prediction.

19. A trusted authentication and anti-fraud system for SIM cards based on blockchain and AI as described in claim 18, characterized in that, The decision execution layer also includes a feedback learning module, which is used to feed back the results of risk handling operations and subsequent user behavior feedback data to the dynamic analysis layer in order to optimize the user behavior graph and risk analysis model. For secondary accounts, the system traces the historically bound user identities and historical behavior logs recorded in the behavior chain through the identity chain, and combines the identity and behavioral characteristics of the currently bound user to analyze potential association risks and fraud tendencies through the graph neural network.

20. A SIM card trusted authentication and anti-fraud system based on blockchain and AI as described in claim 1, characterized in that, The trusted evidence storage layer also supports encrypted storage of critical data, where sensitive user identity information is encrypted using a verifiable encryption scheme, which can only be decrypted or verified by the authorized party using a specific key or zero-knowledge proof.

Images