Digital financial data sharing method
By employing tiered encryption of fields and a dynamic access token mechanism, the problems of inflexible authorization and insufficient security of key management in traditional digital financial data sharing are solved, achieving precise authorization and end-to-end security for data sharing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-07
- Publication Date
- 2026-03-17
AI Technical Summary
Traditional digital financial data sharing methods ignore the differences in sensitivity of fields within a dataset, resulting in a lack of flexibility in the authorization mechanism and problems of over-authorization and under-authorization. At the same time, key management has security risks and is vulnerable to man-in-the-middle attacks and data leakage.
By employing field hierarchies and encryption processing, encrypted data of different security levels is generated, and a mechanism that separates dynamic access tokens and decryption private keys ensures the security and flexibility of data sharing.
It achieves precise authorization and end-to-end security for data sharing, ensuring absolute data security during transmission, preventing key leakage and data misuse, and constructing a security closed loop.
Smart Images
Figure CN121690850A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of digital finance, and in particular to a method for sharing digital financial data. Background Technology
[0002] Traditional data sharing methods in the digital finance field typically encrypt the entire dataset as a whole and impose uniform access control. This approach ignores the differences in sensitivity among different fields within the dataset, resulting in a lack of flexibility in the authorization mechanism: on the one hand, some users may be granted permissions beyond their actual needs, leading to over-authorization and increasing the risk of data misuse; on the other hand, to protect highly sensitive fields, some low-risk data may not be reasonably shared, resulting in insufficient authorization.
[0003] Furthermore, existing methods have significant security vulnerabilities in the key management stage. Common practices include directly transmitting the decryption key or storing the valid key on the client side for extended periods. This makes the key vulnerable to man-in-the-middle attacks during transmission or at risk of leakage during storage, further threatening the confidentiality and integrity of the data.
[0004] Application content
[0005] This application aims to at least partially address one of the technical problems in the related art.
[0006] To achieve the above objectives, this application proposes a method for sharing digital financial data, comprising the following steps:
[0007] S1: The data provider performs field classification and encryption processing on the digital financial data to be shared. When the weight coefficient 1 × field leakage risk value + weight coefficient 2 × data association importance value + weight coefficient 3 × compliance requirement level ≥ preset security level threshold, the field is determined to be of the corresponding security level, and asymmetric encryption is performed on each security level data to generate ciphertext data of different security levels.
[0008] S2: In response to the data sharing request, the data provider configures a sharing policy that includes authorization fields, validity period and usage restrictions, generates a unique policy identifier through a hash algorithm, binds the identifier to the policy information, and generates a dynamic access token bound to the policy.
[0009] S3: The data receiver sends a data access request to the data provider's authorization server, carrying the dynamic access token.
[0010] S4: The authorization server verifies the validity of the token through logical AND operation: verifying the integrity of the token signature, the legality of the policy identifier, and the fact that the token has not been revoked. After all verifications are passed, the server determines whether the data security level belongs to the security level set allowed by the authorization policy based on the security level set matching logic. If they match, the server obtains the decryption private key of the corresponding data security level and performs asymmetric encryption on the decryption private key using the public key of the data receiver before sending it to the data receiver.
[0011] S5: The data receiver obtains the encrypted data, and sequentially uses its own private key to decrypt the encrypted key packet, and then uses the decryption private key to decrypt the encrypted data to obtain the authorized plaintext data.
[0012] Furthermore, the steps of field classification and encryption processing are as follows: based on the sensitivity of the data fields, sensitive fields are initially screened through multi-condition logic or operations, the conditions including fields involving financial transactions, fields associated with personal identity information, or fields affecting risk assessment results; multiple data security levels are defined through weighted calculation, where the sensitivity score is the weighted sum of leakage loss value, compliance risk value, and access frequency; an independent asymmetric encryption key pair, including a public key and a private key, is generated for each data security level; the public key of each security level is used to perform asymmetric encryption on the data of the corresponding field to generate ciphertext data of the corresponding security level.
[0013] Furthermore, the dynamic access token embeds the hash value or policy identifier of the sharing policy, and ensures through a logical NOT operation that the token itself does not have the ability to decrypt data, and only serves as a credential for authorization verification.
[0014] Furthermore, the decryption private key issued by the authorization server to the data recipient is a temporary key package encrypted with the data recipient's public key, and this process is dynamically and on demand through condition-triggered logic: the key package generation and encryption issuance process is triggered only when the token verification is successful, the data access request field belongs to the authorization field set, and the current time is within the policy validity period.
[0015] Furthermore, it also includes policy update and token revocation steps: the data provider actively updates or revokes the sharing policy through the policy status update operation, marking the policy status as invalid; through logical mapping operation, all dynamic access tokens corresponding to the policy are bound to the invalid status, causing the tokens to become invalid immediately; during subsequent verification, the authorization server, through logical judgment operation, rejects the key distribution request if the policy status associated with the token is invalid.
[0016] Furthermore, when verifying a token, the authorization server checks its validity period and usage count using a logical AND operation: the current time does not exceed the token's expiration time, and the number of times it has been used is less than the maximum allowed number of times; if either condition is not met, the verification fails.
[0017] The beneficial effects of the digital financial data sharing method proposed in this application are as follows:
[0018] 1. By comprehensively calculating the risk of field leakage, the importance of association, and compliance requirements, a precise security level is assigned to each field. Based on this, different encryption strategies with different security levels and different keys are implemented, fundamentally achieving a balance between data security and data sharing, allowing the sharing of the minimum necessary data units while meeting security requirements.
[0019] 2. Following the principle of separating keys and tokens, after successful verification, the authorization server dynamically encrypts the decryption private key with the data recipient's public key and then distributes it, ensuring that even if the token is leaked, attackers cannot decrypt the data. At the same time, it guarantees the absolute security of the key during transmission, thus constructing an end-to-end security closed loop from authorization to decryption. Attached Figure Description
[0020] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:
[0021] Figure 1 This is a flowchart illustrating the steps of a digital financial data sharing method according to this application;
[0022] Figure 2 This is a flowchart illustrating the decryption private key distribution process for a digital financial data sharing method described in this application. Detailed Implementation
[0023] To make the technical means, inventive features, objectives, and effects of this application easier to understand, the application is further described below with reference to specific illustrations. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.
[0024] The present application will now be described in further detail with reference to the accompanying drawings.
[0025] like Figure 1 As shown in the figure, a digital financial data sharing method according to an embodiment of this application includes the following steps:
[0026] S1: The data provider performs field classification and encryption processing on the digital financial data to be shared. When the weight coefficient 1 × field leakage risk value + weight coefficient 2 × data association importance value + weight coefficient 3 × compliance requirement level ≥ preset security level threshold, the field is determined to be of the corresponding security level, and asymmetric encryption is performed on each security level data to generate ciphertext data of different security levels.
[0027] Specifically, when data providers classify fields in digital financial data, they employ a multi-dimensional sensitivity assessment model. This model constructs a weighted assessment formula by quantifying the direct losses that field leakage may cause (leakage risk value), the criticality of the field in the business chain (association importance value), and the protection level explicitly stipulated by laws and regulations (compliance requirement level). When the weighted composite score exceeds a preset threshold, the system automatically classifies the field to the corresponding security level. For data of different security levels, asymmetric encryption algorithms are used for separate encryption processing to ensure the independence and isolation of data at each security level, generating ciphertext data corresponding to the security level. This hierarchical encryption mechanism not only achieves refined control of data protection but also lays the foundation for subsequent differentiated authorization.
[0028] S2: In response to the data sharing request, the data provider configures a sharing policy that includes authorization fields, validity period and usage restrictions, generates a unique policy identifier through a hash algorithm, binds the identifier to the policy information, and generates a dynamic access token bound to the policy.
[0029] Specifically, a collision-resistant hash algorithm is used to perform one-way hash calculation on the policy content, generating a unique policy fingerprint. This fingerprint is strongly associated with the policy information through key-value mapping and embedded in a dynamic access token. The token serves as the core credential for subsequent access verification, ensuring both the verifiability of the policy integrity and preventing tampering with the token content through digital signatures.
[0030] S3: The data recipient sends a data access request to the data provider's authorization server, carrying a dynamic access token.
[0031] Specifically, the dynamic access token, serving as a unified credential for identity authentication and permission assertion, is submitted to the data provider's authorized service endpoint via a secure transmission channel. This step standardizes access requests, abstracting complex permission verification into a single token verification interface, thus reducing system coupling.
[0032] S4: The authorization server verifies the validity of the token through logical AND operation: verifying the integrity of the token signature, the legality of the policy identifier, and the fact that the token has not been revoked. After all verifications are passed, the server determines whether the data security level belongs to the security level set allowed by the authorization policy based on the security level set matching logic. If they match, the server obtains the decryption private key for the corresponding data security level and performs asymmetric encryption on the decryption private key using the data receiver's public key before sending it to the data receiver.
[0033] Specifically, the system first verifies the token's integrity via digital signature to ensure it hasn't been tampered with during transmission; second, it verifies the policy identifier's legitimacy to confirm the policy exists in the valid policy library; and finally, it queries the token's revocation status to prevent the unauthorized use of revoked tokens. After all three verifications pass, the system executes a security level matching algorithm to determine the inclusion relationship between the requested data's security level and the set of security levels allowed by the policy. If a match is successful, the system retrieves the corresponding decryption private key from the security key library and encrypts it using the data recipient's public key, forming a temporary key transmission packet.
[0034] S5: The data receiver obtains the encrypted data, and then uses its own private key to decrypt the encrypted key packet, and then uses the decryption private key to decrypt the encrypted data to obtain the authorized plaintext data.
[0035] Specifically, the system first uses its own private key to decrypt the received key packet, restoring the original data decryption private key; then, it uses this private key to decrypt the ciphertext data, ultimately obtaining the authorized plaintext data. This layered decryption mechanism follows the security principle of obtaining the key first, then decrypting, ensuring both the security of key transmission and that only the legitimate recipient can ultimately access the data content, thus achieving end-to-end data protection.
[0036] In one embodiment of this application, the steps of field classification and encryption processing are as follows: based on the sensitivity of the data fields, sensitive fields are initially screened through multi-condition logic or operations, the conditions including fields involving financial transactions, fields associated with personal identity information, or fields affecting risk assessment results; multiple data security levels are defined through weighted calculation, where the sensitivity score is the weighted sum of leakage loss value, compliance risk value, and access frequency; an independent asymmetric encryption key pair, including a public key and a private key, is generated for each data security level; the public key of each security level is used to perform asymmetric encryption on the data of the corresponding field to generate ciphertext data of the corresponding security level.
[0037] It should be noted that in the specific implementation of field classification and encryption processing, the system adopts a two-level screening mechanism: first, potential sensitive fields are quickly identified through logical OR operations, with screening conditions covering core elements of financial business; then, the sensitivity of fields is quantified through a weighted evaluation model, with weight configuration reflecting the relative importance of each dimension in risk assessment. Each security level independently generates an asymmetric key pair to establish an encrypted isolation zone, ensuring cryptographic isolation of data at different security levels.
[0038] In one embodiment of this application, the dynamic access token embeds the hash value or policy identifier of the sharing policy, and ensures through a logical NOT operation that the token itself does not have the ability to decrypt data, and only serves as a credential for authorization verification.
[0039] It should be noted that the design of the dynamic access token follows the principle of separating credentials from capabilities. The policy hash value embedded in the token serves as the unique digital fingerprint of the policy. Through logical NOT operations, it is ensured that the token only performs the function of identity verification and does not have any direct data decryption capabilities. This mechanism prevents the risk of data leakage caused by token leakage.
[0040] In one embodiment of this application, such as Figure 2 As shown, the decryption private key issued by the authorization server to the data recipient is a temporary key package encrypted with the data recipient's public key. This process is dynamically executed on demand through conditional triggering logic: the key package generation and encryption issuance process is triggered only when the token verification is successful, the data access request field belongs to the authorization field set, and the current time is within the policy validity period.
[0041] It should be noted that the key distribution process employs a condition-triggered mechanism, constructing multiple security barriers through logical AND operations. The system dynamically generates and encrypts the transmission key packet only when all three conditions—token validity, field authorization, and time validity—are simultaneously met. This on-demand distribution model ensures real-time access while minimizing the exposure of keys.
[0042] In one embodiment of this application, a policy update and token revocation step is also included: the data provider actively updates or revokes the sharing policy through a policy status update operation, marking the policy status as invalid; through a logical mapping operation, all dynamic access tokens corresponding to the policy are bound to the invalid status, causing the tokens to become invalid immediately; during subsequent verification, the authorization server, through a logical judgment operation, rejects the key distribution request if the policy status associated with the token is invalid.
[0043] It should be noted that the policy update and token revocation mechanism achieves immediate invalidation through status marking and logical mapping. When the policy status is updated to invalid, the system marks all associated tokens as invalid through key-value mapping. During the verification process, the authorization server queries the status and immediately refuses service to invalid tokens, thus constructing an efficient permission revoke channel.
[0044] In one embodiment of this application, when verifying a token, the authorization server checks its validity period and usage count using a logical AND operation: the current time does not exceed the token's expiration time, and the number of times it has been used is less than the maximum allowed number of times; if either condition is not met, the verification fails.
[0045] It should be noted that token validity verification employs a composite condition check, simultaneously verifying time validity and usage count through a logical AND operation. The system compares the current time with the token's expiration time in real time and monitors whether the number of uses has exceeded the limit. Failure to meet any condition triggers verification failure, ensuring the accuracy and reliability of access control.
[0046] The present application and its embodiments have been described above. This description is not restrictive, and the accompanying drawings are only one embodiment of the present application. The actual structure is not limited to this. In conclusion, if a person skilled in the art is inspired by this description and designs a similar structure and embodiment without departing from the spirit of the present application, such design should fall within the protection scope of the present application.
Claims
1. A digital financial data sharing method, characterized in that, Comprise the following steps: S1: The data provider classifies and encrypts the digital financial data to be shared by field, and determines the field as the corresponding secret level when the weight coefficient one × field leakage risk value + weight coefficient two × data correlation importance value + weight coefficient three × compliance requirement level ≥ preset secret level threshold, and executes asymmetric encryption for each secret level data to generate ciphertext data of different data secret levels; S2: In response to a data sharing request, the data provider configures a sharing policy containing authorized fields, validity period and usage restrictions, generates a unique policy identifier through a hash algorithm, and binds the identifier with the policy information to generate a dynamic access token bound with the policy; S3: The data receiver initiates a data access request to the authorization server of the data provider with the dynamic access token; S4: The authorization server verifies the validity of the token through logical AND operation: verifies the token signature integrity, policy identifier legality and token non-revoked state, and after all verification passes, judges whether the data secret level belongs to the secret level set allowed by the authorized policy based on the secret level set matching logic, if matched, obtains the decryption private key of the corresponding data secret level, and executes asymmetric encryption on the decryption private key using the public key of the data receiver and then issues it to the data receiver; S5: The data receiver obtains the ciphertext data, and in turn uses its own private key to decrypt the encrypted key package and then uses the decryption private key to decrypt the ciphertext data to obtain the authorized plaintext data.
2. The digital financial data sharing method of claim 1, wherein, The steps of the field classification and encryption processing are: According to the sensitivity of the data field, sensitive fields are preliminarily screened through multi-condition logical OR operation, and the conditions include fields involving fund transactions, fields associated with personal identity information or fields affecting risk assessment results; A plurality of data secret levels are defined by weighted calculation, wherein the sensitivity score is the weighted sum of leakage loss value, compliance risk value and access frequency, and an independent asymmetric encryption key pair including public key and private key is generated for each data secret level; The public key of each secret level is used to perform asymmetric encryption on the data of the corresponding field to generate ciphertext data of the corresponding secret level.
3. The method of claim 1, wherein, The dynamic access token embeds the hash value or policy identifier of the sharing policy, and through logical NOT operation, ensures that the token itself does not have the ability to decrypt data, and only serves as an authorization verification credential.
4. The digital financial data sharing method of claim 1, wherein, The decryption private key issued by the authorization server to the data receiver is a temporary key package encrypted by the public key of the data receiver, and this process is dynamically and on-demand executed through conditional trigger logic: only when the token verification passes, the data access request field belongs to the authorized field set, and the current time is within the policy validity period, the key package generation and encryption issuance process is triggered.
5. The method of claim 1, wherein, It also includes the steps of policy update and token revocation: The data provider actively updates or revokes the sharing policy through policy state update operation, and marks the policy state as invalid; Through logical mapping operation, all dynamic access tokens corresponding to the policy are bound with the invalid state, causing the tokens to be invalidated immediately; In subsequent verification, the authorization server judges through logical operation, if the token associated policy state is invalid, the key distribution request is rejected.
6. The method of claim 1, wherein, The authorization server verifies the token by logical AND operation of its validity period and usage times: the current time does not exceed the token expiration time, and the usage times are less than the maximum allowed usage times; if any condition is not met, the verification fails.