A cross-end bridge communication large-load layered security processing method and system

Abstract

This application provides a method and system for layered security processing of large payloads in cross-terminal bridging communication. For high-payload scenarios, the method obtains the security level corresponding to the original message and the security policy matching that level. It then parses the original message according to the security policy and encrypts sensitive fields to obtain encrypted data. The publicly accessible large fields are structured and compressed to obtain a lightweight representation. This lightweight representation, along with common business fields in the original message, constitutes plaintext data, reducing the amount of data in the message occupied by publicly accessible large fields. A payload digest is then generated based on this plaintext data and the encrypted data. A signature value for the original message is then generated based on the payload digest. Finally, a secure message is generated based on the payload digest and the signature value and sent to the receiving end container. This reduces the processing resources required for bridging message encryption and effectively saves encryption time, thus helping to reduce message latency.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method and system for layered security processing of large payloads in cross-terminal bridging communication. Background Technology

[0002] Bridged communication (often abbreviated as JSbridge in the industry) refers to a communication method that enables communication between native containers and web page containers, breaking down the isolation between the two runtime environments. The web page container typically refers to the H5 page container running within WebView (a view component), while the native container refers to the native code based on the operating system, such as iOS, Android, or HarmonyOS.

[0003] To ensure the security of bridging communication, related technologies either employ a low-security processing scheme that only performs simple serialization, which poses a risk of leakage of sensitive information in bridging communication, or they adopt a high-security processing scheme that fully packages and encrypts each message. For short message scenarios, the high-security processing scheme can effectively protect information security. However, for scenarios involving large payloads such as transmitting audio, video, images, and long text, the high-security processing scheme will significantly increase the processing resource overhead and message latency required for bridging communication encryption. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method and system for layered security processing of large payloads in cross-end bridging communication, which performs targeted encryption on large payloads in cross-end bridging communication, thereby shortening the time required for encryption of large payload bridging communication and saving the processing resources required for encryption of large payload bridging communication.

[0005] In a first aspect, embodiments of this application provide a method for layered security processing of high-payload cross-end bridging communication, wherein the method includes: Obtain the original message generated by the sending container, and determine the security level of the original message and the security policy that matches the security level; The original message is parsed according to the security policy, and sensitive fields, general business fields, public fields and public large fields are extracted from the original message. The public large fields are public data whose data length is greater than the set data length threshold, and the public fields are public data whose data length is less than or equal to the data length threshold. The sensitive fields are encrypted to generate encrypted data, and the public large fields are structured and compressed to obtain a lightweight representation of the public large fields. The lightweight representation, together with the general business fields and the public fields, is the plaintext data in the original message. A payload digest is generated based on the encrypted area data and the plaintext area data, and a signature value of the original message is generated based on the payload digest. A security message is generated based on the payload digest and the signature value, and the security message is sent to the receiving container. Secondly, embodiments of this application provide a cross-end bridging communication high-payload layered security processing system, wherein the system includes: a transmitting end container and a receiving end container, wherein: The sending container is used for: Determine the security level of the original message and the security policy that matches the security level; parse the original message according to the security policy, and extract sensitive fields, general business fields, public fields and public large fields from the original message. The public large fields are public data whose data length is greater than a set data length threshold, and the public fields are public data whose data length is less than or equal to the data length threshold. The sensitive fields are encrypted to generate encrypted data, and the public large fields are structured and compressed to obtain a lightweight representation of the public large fields. The lightweight representation, together with the general business fields and the public fields, is the plaintext data in the original message. A payload digest is generated based on the encrypted area data and the plaintext area data, and a signature value of the original message is generated based on the payload digest. A security message is generated based on the payload digest and the signature value, and the security message is sent to the receiving container; The receiving container is used to receive the security message and verify the source and time validity of the security message. If both verifications pass, the security message is decrypted and the local digest corresponding to the original logical payload view of the security message is reconstructed. If the local digest is consistent with the payload digest, the security message is allowed to enter.

[0006] Thirdly, embodiments of this application provide an electronic device, wherein the electronic device includes: a processor; and a memory storing a program; wherein the program includes instructions, which, when executed by the processor, cause the processor to perform the cross-end bridging communication high-load layered security processing method described in the first aspect.

[0007] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the cross-end bridging communication high-load layered security processing method described in the first aspect.

[0008] The beneficial effects of this application are: This application provides a method and system for layered security processing of large payloads in cross-terminal bridging communication. For scenarios involving large payloads such as audio, video, images, and long text, the embodiments of this application are adopted. By obtaining the security level corresponding to the original message and the security policy matching the security level, the original message is parsed according to the security policy, and sensitive fields in the original message are encrypted to obtain encrypted data. The publicly accessible large fields are structurally compressed to obtain a lightweight representation. This lightweight representation, together with the common business fields in the original message, constitutes the plaintext data. This reduces the amount of data in the message occupied by the publicly accessible large fields. Then, a payload digest is generated based on the plaintext data and the encrypted data. A signature value of the original message is then generated based on the payload digest. Finally, a secure message is generated based on the payload digest and the signature value and sent to the receiving end container. This significantly reduces the processing resources required for bridging message encryption and effectively saves the encryption time required for bridging messages, helping to reduce message latency. Attached Figure Description

[0009] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This paper illustrates a flowchart of a high-load hierarchical security processing method for cross-end bridging communication provided in an embodiment of this application. Figure 2 This paper illustrates another flowchart of the cross-end bridging communication high-load layered security processing method provided in an embodiment of this application; Figure 3 This illustration shows a schematic diagram of the device structure of a cross-end bridging communication high-load hierarchical security processing device provided in an embodiment of this application; Figure 4 This paper illustrates another flowchart of the cross-end bridging communication high-load layered security processing method provided in an embodiment of this application; Figure 5 This paper illustrates a schematic diagram of a system architecture for a cross-end bridging communication high-load hierarchical security processing system provided in an embodiment of this application. Figure 6 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of this application is shown. Detailed Implementation

[0010] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0011] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0012] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0013] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0014] Before providing a detailed description of the cross-end bridging communication high-load layered security processing method and system provided in this application, the following technical terms are explained: Bridged messages: Instructions, parameters, or result objects passed between the native container and the web page container.

[0015] Risk level: Security levels for messages based on their sensitivity to business requirements.

[0016] Selective encryption: Encrypting only sensitive fields while preserving the plaintext transmission of the main public fields.

[0017] Payload digest: A digest value generated from the key content of the message, used to replace the full payload in the signature.

[0018] Reconstructing the signature verification: The receiving end first recovers the original logical payload that is consistent with the sending end, and then performs the signature verification.

[0019] Firstly, this application provides a method for cross-terminal bridging communication with high-payload hierarchical security processing. This method is applicable to any electronic device equipped with cross-terminal bridging communication with high-payload hierarchical security processing capabilities, including but not limited to personal mobile terminals, computers, or servers. Figure 1 As shown, the method includes the following steps: S11. Obtain the original message generated by the sending container, and determine the security level of the original message and the security policy matching the security level. S12. Parse the original message according to the security policy, and extract the sensitive fields, general business fields, public fields and public large fields from the original message. The public large fields are public data whose data length is greater than the set data length threshold. S13. Encrypt the sensitive fields to generate encrypted area data, and perform structured compression on the public large fields to obtain a lightweight representation of the public large fields. The lightweight representation, together with the general business fields and the public fields, is the plaintext area data in the original message. S14. Generate a payload digest based on the encrypted area data and the plaintext area data, and generate a signature value for the original message based on the payload digest; S15. Generate a security message based on the payload digest and the signature value, and send the security message to the receiving container.

[0020] The following will provide a detailed explanation of steps S11 to S15 with specific examples: In this application, cross-terminal bridging communication refers to bridging communication between a sending container and a receiving container, and does not belong to end-to-end communication across devices. The sending and receiving containers reside within the same electronic device. It can be understood that the cross-terminal bridging communication high-payload layered security processing method provided in this application is applied to an application processor within the electronic device. Different threads of the application processor execute message encryption for the corresponding sending container and message decryption for the receiving container. Specifically, if the sending end is a web page container, the receiving end is a native container; if the sending end is a native container, then the receiving end is a web page container. The web page container runs in an H5 or J5 environment within a WebView, while the native container runs in the native threads of iOS, Android, or HarmonyOS.

[0021] For example, when a user opens a bank's app on their phone, the WebView embedded in the app loads an H5 page. This H5 page calls the phone's native capabilities (taking photos, facial recognition, and payment). The phone's native container can send the results of taking photos, facial recognition, and payment back to the H5 page. It can be seen that the bridging communication between the sending and receiving ends never leaves the phone.

[0022] The method provided in this application is mainly applied to the CPU in electronic devices. Different threads within the CPU serve the sending and receiving ends respectively. For example, the CPU's native main thread handles the relevant logic processing on the native container side, while a thread started by the WebView's JS engine on the CPU handles the relevant logic processing on the webpage container side. Specifically, the encryption processing of bridged messages is executed by the CPU's thread on the sending end container, and the decryption processing of bridged messages is executed by the CPU's thread on the receiving end container.

[0023] Although both the sending and receiving ends are located on the same electronic device, malicious H5 pages can generate malicious bridging calls, leading to the risk of WebView sandbox escape. Furthermore, there are risks such as attackers simulating JavaScript calls to native interfaces, resulting in certain security risks associated with bridging messages. Therefore, secure handling of bridging messages is essential. This application provides a layered security handling method for high-payload bridging communication, which, through methods such as... Figure 2 The overall processing flow shown performs layered security processing on the original messages in the bridged communication to protect the sensitive fields carried in the original messages, while reducing the CPU processing resource consumption of exposed large fields.

[0024] in, Figure 2 The overall CPU processing flow is divided into the following logical functional modules: message classification module, security level mapping module, plaintext and encrypted area splitting module, payload generation module, signature module, selective encryption module, secure message encapsulation module, cross-end sending module, receiving verification module, decryption and original view reconstruction module, and digest comparison and signature verification module.

[0025] Among them, the message classification module, security level mapping module, plaintext area and encrypted area splitting module, payload generation module, signature module, selective encryption module, secure message encapsulation module, and cross-end sending module are various functional modules in the sending end container. As the name suggests, the message classification module is used to classify the original bridging messages of the sending end and determine whether they are ordinary messages or messages that need to be encrypted.

[0026] Furthermore, the security level mapping module determines the security level of the original message and the corresponding security policy, while the plaintext and encrypted area splitting module is used to split the data in the encrypted area (sensitive fields) from the data in the plaintext areas (public large fields and general business fields).

[0027] The payload digest generation module is used to generate corresponding payload digests based on plaintext data and encrypted data. The signature module is used to generate the signature value of the original message; The selective encryption module is used to encrypt data that needs to be encrypted according to the security policy; The secure message encapsulation module is used to generate a corresponding secure message by combining the encrypted data and plaintext data after encryption with the payload digest and signature value, and then send it to the receiving container through the cross-end sending module.

[0028] The receiving verification module, the decryption and original view reconstruction module, and the digest comparison and signature verification module are located in the receiving container. The receiving verification module verifies the received security message. After successful verification, the message is sent to the decryption and original view reconstruction module for decryption and to construct the original logical digest view of the original message corresponding to the security message. Then, the digest comparison and signature verification module compares the logical digest view of the security message with the original logical digest view of the original message and verifies the signature value carried in the security message. Finally, if the original logical digest view comparison and signature value verification are successful, the payload information corresponding to the original message is allowed to enter the business execution unit of the receiving container, and the business execution unit executes the corresponding business instructions according to the payload information.

[0029] In this embodiment, the original message is a message sent by the sender that has not yet undergone encryption security processing. This original message includes information such as method identifier, source identifier, timestamp, auxiliary information, and business payload. For example, the following is the original bridging message for a payment scenario initiated by a webpage container of an H5 order business to the native container: { "method": "submitOrder", "sourceId": "webview_main_001", "timestamp": 1231456789, "_meta": { "appVersion": "2.1.0", "platform": "android" }, "params": { "orderId": "ORD20260121001", "totalAmount": 299.00, "currency": "CNY", "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "idCard": "440304******1234", "contactName": "Zhang San", "contactPhone": "13800138000", InvoiceTitle: "Shenzhen [Company Name] Technology Co., Ltd." "contractText": "A very long electronic contract, exceeding 100,000 words...", "productImages": [ "https: / / img.xxx.com / p1.png", "https: / / img.xxx.com / p2.png" ], "deliveryAddress": "xx Subdistrict, Nanshan District, Shenzhen City, Guangdong Province" } } It is understood that the original message includes the fields shown in Table 1 below: Table 1. A schematic table of raw message fields

[0030] Based on the meanings of different fields in the original message, the fields carried in the original message can be divided into: sensitive fields, general business fields, public fields, and public large fields. The general business fields are used to describe call control in bridged communication. The public fields, general business fields, and public large fields are all fields in the entire original message except for the sensitive fields, which require encryption. These public fields, general business fields, and public large fields together constitute the plaintext data in the original message. The difference between public fields and public large fields lies in their data length. Public large fields are public data with a data length greater than a set data length threshold, while public fields are public data with a data length less than or equal to the data length threshold.

[0031] It is understood that, compared to traditional bridging security processing systems, this application differentiates the processing of raw messages based on different security levels. The core principle is to employ different security strategies for processing raw messages with varying security levels. As one implementation method, the overall flow of the method provided in this application is as follows: Figure 3As shown, the process involves receiving a message to be sent, identifying its risk level, and mapping a security policy based on that risk level. It then determines whether sensitive fields in the original message need encryption. If encryption is required, the sensitive fields are extracted and added to the encryption area to generate ciphertext; otherwise, all fields remain in plaintext. Extensive public fields can be retained in the plaintext area. A payload digest is generated according to digest rules, and a signature is generated based on the key fields and the digest. The encapsulated secure message is then sent. Finally, the receiving container verifies the timestamp and source, reconstructs the original payload view, recalculates the digest, and verifies the signature. Finally, it checks if the signature verification passes. If it does, the business logic corresponding to the original message is executed; otherwise, the business logic corresponding to the original message is rejected.

[0032] In some possible embodiments, step S11 is performed through the following steps: The security policy corresponding to the original message is determined based on the method identifier, business sensitivity level, and payload characteristics carried in the original message. The security policy includes: signature rules, encryption rules, and digest rules.

[0033] The method identifier is a string that uniquely represents the business semantics of this bridging call. As a necessary component of the original message, it is fundamental control information that ensures the security and correctness of cross-terminal bridging communication. In one implementation, the method identifier is represented by the "method" field in the original message. This "method" field indicates the business type of the current interaction between the sending and receiving containers. For example, if the "method" field in the original message corresponds to "login," it indicates that the current bridging communication interaction is for logging in.

[0034] It is understood that the functions of the method identifier in this application include: business routing function: instructing the receiving container to call the corresponding business logic processing unit; security policy routing function: serving as one of the core inputs for security level determination, used to map to the corresponding security processing policy, i.e., different business types have different security levels and corresponding security policies; integrity protection function: the method identifier participates in the construction of the logical payload view and the calculation of the payload digest, which can help prevent messages from being tampered with to other business interfaces; anti-obfuscation attack function: by incorporating the method identifier into the signature input, it avoids the malicious reuse of signatures between different types of interfaces.

[0035] The business sensitivity level describes the sensitivity of the services communicated between the two containers at the bridging ends. Higher sensitivity corresponds to a higher business sensitivity level. Similarly, a higher business sensitivity level corresponds to a higher security policy level. As one implementation method, this business sensitivity level is manually set; that is, business personnel can set the corresponding business sensitivity level in the original message so that a matching security policy can be quickly determined based on this level when parsing the original message.

[0036] As another implementation, the business sensitivity level is automatically determined based on the original message. Specifically, the business sensitivity level can be automatically determined based on the business semantics carried by the original message through predefined security rules. For example, a predefined security rule engine can automatically map the corresponding business sensitivity level based on the objectively existing method identifiers and sensitive fields in the original message. The entire process requires no manual intervention, and the determination result directly drives the execution of security policies.

[0037] The payload features can be extracted from the business payload in the original message. Specifically, payload feature extraction is automatically performed by the payload analysis engine at the sending end, and this process does not parse the plaintext content of sensitive fields. Specifically, the payload analysis engine performs a depth-first traversal of the business payload portion of the original message, extracting structured features including the presence of large fields, maximum field length, total payload size, total number of fields, whether it contains file or multimedia resource fields, maximum nesting depth, number of array fields, and maximum array length, without reading sensitive field values. For example, the payload analysis engine can extract features based on the fields corresponding to the business payload as shown in Table 1 above, obtaining the following payload features: { "hasLargeField": true, "maxFieldLength": 100000, "totalSize": 107520, "fieldCount": 11, "hasImage": true, "hasFile": false, "arrayCount": 1, "maxArrayLen": 2, "maxDepth": 1 } The process involves first determining the security level of the original message based on its method identifier, business sensitivity level, and payload characteristics. Then, a corresponding security policy is determined based on this security level. Specifically, the basic security level of the original message is determined by the method identifier, further refined based on the business sensitivity level, and finally adjusted based on the payload characteristics to obtain the final target security level. This method yields a more accurate target security level that better reflects the payload characteristics of the original message.

[0038] Specifically, when revising the basic security level based on the business sensitivity level, if the basic security level is lower than the security level corresponding to the business sensitivity level, then the revised basic security level will be based on the security level corresponding to the business sensitivity level. Similarly, when adjusting the revised basic security level based on load characteristics, the final target security level can be determined by whether the security level corresponding to the load characteristics is higher than the security level corresponding to the business sensitivity level. If it is higher, the security level corresponding to the load characteristics will be taken as the final target security level; otherwise, the security level corresponding to the business sensitivity level will be taken as the final target security level.

[0039] Different security levels correspond to different security policies, which specifically include: signature rules, encryption rules, and digest rules. Signature rules are used to generate the signature value of the original message, encryption rules are used to encrypt sensitive fields, and digest rules are used to generate a payload digest of the original message. The complexity of the rules varies with different security levels; higher security levels correspond to higher rule complexity. The encryption rules, signature rules, and digest rules are all common data encryption algorithms, data signature generation algorithms, and data digest generation algorithms used in bridging communication. For example, commonly used data encryption algorithms include: AES (Advanced Encryption Standard), SM4 (ShangMi4 Block Cipher Algorithm), 3DES (Triple Data Encryption Algorithm), etc. Commonly used data signature algorithms include: RSA (Rivest-Shamir-Adleman Digital Signature) signature algorithm, RSASA-PKCS1 (RSA Signature Scheme with Appendix - Public-Key Cryptography Standards), etc. Commonly used data digest algorithms include: MD5 (Message-Digest Algorithm 5), SHA-1 (Secure Hash Algorithm 1), SHA-2 (Secure Hash Algorithm 2), etc.

[0040] Specifically, the security policy includes the following information: risk level, whether to verify the source, whether to verify the timestamp, whether to enable signatures, and whether to enable field encryption. Among these, verifying the source determines whether the origin of the original data is verified; verifying the timestamp determines whether the timestamp of the original data is verified; enabling signatures determines whether a signature value is generated when the original data is processed securely; and enabling field encryption determines whether sensitive fields are encrypted.

[0041] Based on this, in some possible embodiments, step S13 can be implemented through the following steps: The sensitive fields are encrypted according to the encryption algorithm in the encryption rules to generate the encrypted area data.

[0042] The encryption algorithm specified in the security policy is used to encrypt sensitive fields, generating encrypted data and a corresponding key. This allows the receiving end to decrypt the received security message using the corresponding decryption algorithm to obtain the actual content of the encrypted data carried within the security message.

[0043] In some possible embodiments, after performing structured compression of the public large field in step S13 to obtain a lightweight representation of the public large field, the metadata of the public large field can be extracted as the lightweight representation of the public large field. For example, metadata such as the field name, total data length, data type identifier, and content termination feature fragments of the public large field can be extracted, and then concatenated into a vector. This vector is the lightweight representation of the public large field. For instance, for the image URL field, only the field name, total URL length, and URL prefix identifier are retained, and then these are concatenated into a vector. This vector is the lightweight representation of the image URL public large field.

[0044] As another implementation, the publicly disclosed large field can be structurally compressed using the following steps to obtain a lightweight representation of the publicly disclosed large field: Calculate the byte length of the public large field, calculate the one-way hash value of the entire content of the public large field, and determine the one-way hash value as the field hash of the public large field; When the byte length is greater than a preset byte length threshold, the public large field is divided into blocks of a fixed size, and a hash value is calculated for each field block to obtain a block digest set for each field block. The lightweight representation is obtained by combining the byte length, the field hash, and the block digest set.

[0045] The process involves calculating the byte length of the publicly available large field using the UTF-8 encoding standard, then using a hash algorithm to calculate the hash value of the entire content of the publicly available large field, thus obtaining the field hash. The publicly available large field is then divided into blocks of a fixed size, such as 256KB, resulting in each block. A hash algorithm is then used to calculate the hash value for each block, yielding the hash value corresponding to each field block. Finally, a streaming approach is used to read the content of each field block sequentially, calling the SHA-256 algorithm to calculate the hash value for each block. Only the storage space for a single block of data needs to be reserved in memory. After each block digest is calculated, it is stored in an array in the order of the blocks, ultimately resulting in a block digest set containing 10 block hash values.

[0046] Then, the byte length and field hash are assembled, or the byte length, field hash, and block digest set are assembled to obtain a lightweight representation of each public large field.

[0047] In this embodiment, streaming computation can be combined with the calculation process of field hash: when reading data block by block, the operation context of the overall field hash is updated synchronously, and only one data traversal is needed to obtain the field hash and the block digest set at the same time, avoiding the IO and computing power overhead caused by repeated data reading.

[0048] As another implementation, key fields can be extracted from the publicly disclosed large fields and identified as the lightweight representation.

[0049] It is understandable that for some extremely long publicly available large fields, such as long texts or batches of structured data (such as Excel spreadsheets), key fields can be extracted from the publicly available large fields first. A vector can then be obtained by concatenating these key fields; this vector is the lightweight representation of the publicly available large field. The key fields are the minimum necessary fields in the publicly available large field that characterize its identity and size. This implementation method is suitable for batch processing of large fields in lists and sets. By extracting the total number of entries, the first / last data identifier, and key field statistics, it replaces the full set of entry data as a lightweight representation, thus maintaining the structural integrity of the data while significantly reducing the amount of computational input.

[0050] The generation of the payload summary in step S14 can be achieved through the following steps: The payload digest is generated based on the encrypted area data and the plaintext area data according to the digest rules.

[0051] In this embodiment, the payload digest is a cryptographic one-way hash value generated from the key business content of the message. The encrypted and plaintext data in the original message are uniformly compressed into a fixed-length digest value using a data digest algorithm within the digest rules. Thus, this digest value represents a unified original logical payload view of the original message at the business level. This original logical payload view contains all public fields, sensitive fields, and the original plaintext value from the original message. However, since the sensitive fields are already encrypted, the receiving container can decrypt the sensitive fields and then reassemble the public fields of the plaintext area with the decrypted sensitive fields according to the rules to restore an original logical payload view completely consistent with that of the sending container.

[0052] Specifically, the payload summary can be generated through the following steps: First, for all fields in the original logical payload view, differentiated input processing is performed according to field category. This ensures that small-volume fields retain their complete plaintext, while large-volume public fields are replaced with lightweight representations to reduce the amount of data to be processed. Specifically, for public fields (such as page identifiers, method parameters, and other short text fields): the original plaintext value is directly retained and included in the digest calculation input. For sensitive fields (such as identity credentials, payment tokens, privacy data, etc.): the original plaintext value is directly retained (plaintext before encryption at the sending end, and plaintext after decryption at the receiving end) and included in the digest calculation input to ensure that tampering with sensitive fields can be detected. For large public fields (such as Base64 images, long and rich text, batch structured data, etc.): the complete original content is not used in the calculation; it is replaced with the aforementioned lightweight representation (including byte length, field hash, and extra-large fields exceeding the threshold include a block digest set). This compresses large field inputs at the KB / MB level into lightweight features of only a few hundred bytes, significantly reducing the computational power and memory overhead of subsequent hash calculations while retaining integrity verification capabilities.

[0053] Secondly, all input elements to be computed undergo uniform normalization processing to eliminate hash value deviations caused by format differences, ensuring that the binary sequences of inputs at both ends are completely consistent. Specific rules include: unified character encoding: all strings are uniformly converted to UTF-8 encoding to avoid different hash values ​​caused by encoding differences; fixed field order: all input elements are arranged according to preset fixed rules (such as lexicographical order of field names, or the order of fields defined by the protocol) to avoid digest differences caused by random field order; format normalization: redundant whitespace characters, newlines, and indentation are removed; uniform precision for numeric types (such as timestamps being uniformly set to millisecond-level integers); uniform standard format for Boolean values; and unified serialization format: if structured concatenation is used, compact JSON, fixed delimiter concatenation, and other non-redundant formats are uniformly used to ensure that the serialization results at both ends are consistent at the byte level.

[0054] Finally, a final digest is generated through one-way hashing. For example, a preset cryptographic one-way hashing algorithm (SHA-256 and SHA-384 are commonly used in industry, while SM3 is used for compliance scenarios) is employed. The hash operation is performed on the normalized complete input sequence, outputting a fixed-length binary or hexadecimal string, which is the final payload digest. The operation process supports streaming computation: for ultra-large payloads containing multiple large fields, the normalized input elements can be updated to the hash operation context sequentially according to the field order, without needing to load all data into memory. This further adapts to the memory-constrained runtime environments of mobile WebView and native devices. In this way, the inconsistency between the sending and receiving ends caused by differences in partition structure and ciphertext / plaintext can be fundamentally avoided, specifically addressing the issue of signature verification misjudgment caused by inconsistent signature input in existing solutions.

[0055] Specifically, when generating the signature value of the original message in step S15, the following steps can be taken: The signature value is generated by combining the message identifier, method identifier, source identifier, timestamp information, and payload digest carried in the original message according to the signature rules.

[0056] In this application, a data signature algorithm is used to generate the signature value. The input to this data signature algorithm includes the message identifier, method identifier, source identifier, timestamp information, and the generated payload digest from the original message. Since any field within the payload (including sensitive fields, publicly accessible ordinary fields, and publicly accessible large fields) will be altered, the payload digest will change, thereby indirectly assisting in the integrity verification of all business data. By ensuring the integrity of all business data through this payload digest, and given that the payload digest is generated based on a lightweight representation of publicly accessible large fields, the size of the signature input can be controlled within a fixed small range.

[0057] The message identifier is a unique ID used to distinguish different call requests and prevent replay attacks. The method identifier indicates the name of the native capability method used in this bridge call, clearly defining the call intent. The source identifier is the identity identifier of the sending container (such as the H5 page domain name or application package name), used to verify the legitimacy of the message source. The timestamp is the timestamp of the message sending (usually in milliseconds), used to verify the timeliness of the message and intercept expired replay messages.

[0058] The corresponding signature value can be generated by following these steps: First, the signature input elements are pre-confirmed. Specifically, before performing the signature operation, it is necessary to confirm that all four key fields of the message header have been generated and their values ​​conform to the protocol specifications, and that the payload digest has been calculated based on the original logical payload view (i.e., the digest calculated by the sender based on the complete plaintext business payload after field splitting and before encryption execution, rather than the digest of partitioned transmission data or ciphertext data).

[0059] Secondly, the signature input should be standardized and assembled. Specifically, to completely eliminate format differences between the sending and receiving ends and avoid misjudgments during signature verification, input elements can be assembled and normalized according to preset standardization rules. For example, they can be sorted by fixed fields: all input fields should be arranged strictly in a preset order (e.g., protocol definition order: message identifier → method identifier → source identifier → timestamp → payload digest), or uniformly arranged in lexicographical order of field names to eliminate digest differences caused by random field order; at the same time, the format needs to be uniformly normalized. For example, all strings should be uniformly converted to UTF-8 encoding; timestamps should be uniformly formatted as millisecond-level integers to remove precision differences; hexadecimal format payload digests should be uniformly lowercase (or uppercase); all redundant whitespace characters, newlines, and indentation should be removed to avoid serialization redundancy; and then concatenated into the signature original: all normalized fields should be concatenated in order into a complete string (or binary sequence) as the final signature original. The concatenation process can use fixed delimiters (such as &, |) or compact key-value pair format to ensure that the concatenation results at both the sending and receiving ends are completely consistent at the byte level.

[0060] Furthermore, the original signature text undergoes preprocessing. Specifically, the assembled original signature text is first subjected to a hash operation using a cryptographic one-way hash algorithm (consistent with the payload digest algorithm, such as SM3 or SHA-256) to obtain a fixed-length signature text digest. This adapts to the input length requirements of asymmetric signature algorithms, most of which only support fixed-length inputs; thus further compressing the input size for signature computation, improving signature calculation efficiency, and preventing the direct exposure of the original signature text, thereby enhancing security.

[0061] Finally, the signature operation is performed. For example, an asymmetric signature algorithm can be used, employing the asymmetric private key held by the sender to perform a digital signature operation on the preprocessed signature digest, generating the final signature value. Specifically, the SM2 elliptic curve digital signature algorithm is used for compliant scenarios, the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithm is used for general internet scenarios, and the RSA algorithm (an asymmetric encryption algorithm, with RSASA-PSS padding mode recommended) is used for traditional compatible scenarios. Finally, the signature result is converted to Base64 encoding or a hexadecimal string for easy transmission and parsing within the message envelope.

[0062] Further, step S15 is executed to generate a secure message based on the payload digest and signature value. Specifically, the generated signature value can be written into a dedicated signature field of the secure message envelope, and encapsulated together with other fields to form a complete secure message. This secure message envelope synchronously includes: key header fields, a plaintext area (public ordinary fields + public large plaintext fields), an encrypted area (encrypted sensitive fields), a payload digest, and a signature value. After the secure message envelope is encapsulated, the secure message is transmitted from the sending container to the receiving container via the JSBridge bridge communication channel.

[0063] In some possible embodiments, after the receiving container receives the security message, the method further includes: The receiving container verifies the source and time validity of the security message. If both verifications pass, the security message is decrypted, and the local digest corresponding to the original logical payload view of the security message is reconstructed. If the local digest is consistent with the payload digest, the security message is allowed to enter.

[0064] It is understood that in this application, the receiving container needs to verify the security message before allowing it to enter subsequent business processes. The security verification process of the receiving container includes three steps: reconstruction of the original logical payload view, local digest recalculation, and standardized signature verification input, to thoroughly ensure the consistency of signature benchmarks between the sending and receiving ends and resolve the pain point of signature verification misjudgment. The specific processes of these three steps are as follows: The receiving container first verifies the validity of the message source identifier and the timeliness of the timestamp, blocking messages from illegal sources and expired replays without performing subsequent high-overhead calculations. Then, it decrypts the sensitive fields in the encrypted area to obtain the plaintext, and reassembles the public ordinary fields and public large fields in the plaintext area with the decrypted sensitive fields according to preset rules to restore the original business-level logical payload view that is completely consistent with the sending end.

[0065] Furthermore, the local payload digest is recalculated on the reconstructed original logical payload according to the exact same rules as the sending container (the same large field lightweight representation rules, the same field order, the same normalization rules, and the same hash algorithm).

[0066] Furthermore, the key fields of the received message header, together with the locally calculated payload digest, are assembled into the original signature verification text according to the same sorting, normalization rules, and splicing method as the sender.

[0067] It is understandable that the receiving container in this application does not directly use the payload digest carried in the message to assemble the signature verification input, but uses the locally reconstructed and calculated digest to ensure a strong binding between the signature and the business payload. In this way, if the payload is tampered with, the local digest will inevitably change, and the signature verification will fail directly, which can effectively avoid the security risk of the digest and signature being tampered with at the same time.

[0068] Finally, using the sender's public key, a signature verification operation is performed on the assembled verification text and the received signature value to determine if the signature is valid. If valid, the process is allowed to proceed to the next business step; otherwise, it is rejected.

[0069] Thus, unlike traditional schemes that directly sign the entire message body, this application indirectly carries the integrity of the entire data through a payload digest. The signature input size is fixed and extremely small, completely unaffected by the size of the business payload. Signature performance is significantly improved under high-load scenarios, and security strength is not degraded. Secondly, in this application, the calculation basis for signature and verification is unified as the original logical payload at the business layer, rather than the partitioned plaintext / ciphertext structure at the transmission layer. This fundamentally solves the problem of misjudgment of signature verification caused by the inconsistency of signature input structures at the sending and receiving ends after field splitting and selective encryption. Finally, in this application, the signature serves as the final fallback security check, forming a layered verification system with the preceding "byte length verification → block digest verification → fast payload digest comparison". The lightweight preceding verification can directly intercept most tampered messages, avoiding the execution of high-overhead signature verification calculations, and further improving the overall processing efficiency of large-load messages.

[0070] Based on the method provided in the first aspect, and in the second aspect, this application provides a cross-end bridging communication high-payload hierarchical security processing system, wherein, as... Figure 4 As shown, the system 40 includes: a transmitting container 401 and a receiving container 402, wherein: Sender container 401 is used for: Determine the security level of the original message and the security policy that matches the security level; parse the original message according to the security policy, and extract sensitive fields, general business fields, public fields and public large fields from the original message, wherein the public large fields are public data whose data volume is greater than a set volume threshold; The sensitive fields are encrypted to generate encrypted data, and the public large fields are structured and compressed to obtain a lightweight representation of the public large fields. The lightweight representation, together with the general business fields and the public fields, is the plaintext data in the original message. A payload digest is generated based on the encrypted area data and the plaintext area data, and a signature value of the original message is generated based on the payload digest. A security message is generated based on the payload digest and the signature value, and the security message is sent to the receiving container; The receiving container 402 is used to receive the security message and verify the source and time validity of the security message respectively. If both verifications pass, the security message is decrypted and the local digest corresponding to the original logical payload view of the security message is reconstructed. If the local digest is consistent with the payload digest, the security message is allowed to enter.

[0071] As one implementation method, it can be as follows Figure 5 As shown, in addition to the sending container and the receiving container, the system may also include: a classification and policy module, an encryption module, a digest and signature module, and a verification module. The sending container sends the original bridging message to the classification and policy module. The classification and policy module identifies the risk level of the message based on its business type, field sensitivity, and payload size, maps the corresponding security processing rules (including whether to enable encryption, whether to enable signature, field splitting rules, digest algorithm, signature algorithm, etc.), and returns the security level and field splitting policy to the sending end as the basis for subsequent processing.

[0072] According to the splitting strategy, the sending end splits the message payload into sensitive fields and public fields (including large public fields), and sends the sensitive fields to the encryption module so that the encryption module can encrypt the sensitive areas. The encryption module only performs encryption operations on the sensitive fields to generate the encrypted area; the public fields (including large public fields) are preserved in plaintext form as the plaintext area; the encryption module returns the encrypted area and the plaintext area to the sending end.

[0073] The sender submits message payload information to the digest signing module, requesting the generation and signing of a payload digest. The digest signing module first generates a payload digest based on the original logical payload view (plaintext of sensitive fields and plaintext of public fields) according to preset rules. Public large fields are represented in a lightweight form instead of their full content for calculation. Then, the message header key fields (message identifier, method identifier, source identifier, timestamp) are combined with the payload digest, and a digital signature operation is performed using the sender's private key to generate a signature value. The digest signature module returns the payload digest and signature value as the signature result to the sender.

[0074] The sending end encapsulates the message header, plaintext area, encrypted area, payload digest, and signature value into a standardized secure message envelope; and sends the secure message to the receiving end through the JSBridge cross-end channel.

[0075] After receiving a security message, the receiving end forwards the security message to the verification module to perform the first layer of verification. The verification module first verifies the legality of the message's source identifier (confirming that the message comes from a trusted sender) and the timeliness of the timestamp (intercepting expired messages and replaying attack messages). This step is a lightweight verification with low computational overhead, which can intercept most illegal messages in advance and avoid subsequent high-overhead computation.

[0076] Furthermore, after the pre-verification passes, the verification module decrypts the sensitive fields in the encrypted area, restoring the plaintext of the sensitive fields. The decrypted plaintext of the sensitive fields is then reconstructed with the public fields in the plaintext area according to preset rules, reconstructing the original logical payload view that is completely identical to that of the sender. Based on the reconstructed original logical payload, the verification module also needs to recalculate the local payload digest according to the exact same rules as the sender (the same large-field lightweight representation rules, the same digest algorithm, and the same field order). The message header key fields are combined with the locally calculated payload digest, and a signature verification operation is performed using the sender's public key (which can use alt logical branches for signature verification) to verify the legality of the signature and the integrity of the data.

[0077] If the signature verification passes, the verification module returns a verification result to the receiving end. The receiving end determines that the message source is trustworthy, the content is complete and has not been tampered with, and allows the execution of business instructions to complete this bridging call. If the signature verification fails, the verification module returns a verification failure result. The receiving end determines that the message is illegal (tampered with, source forged, etc.), refuses to execute the business instruction, discards the message and returns an error.

[0078] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this application comply with relevant laws and regulations and do not violate public order and good morals.

[0079] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0080] Thirdly, exemplary embodiments of this application also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of this application.

[0081] An exemplary embodiment of this application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0082] An exemplary embodiment of this application also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of this application.

[0083] refer to Figure 6 The present invention describes a structural block diagram of an electronic device 600 that can serve as a server or client of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0084] like Figure 6 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM 602) or a computer program loaded from a storage unit 608 into a random access memory (RAM 603). The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output interface (I / O interface 605) is also connected to the bus 604.

[0085] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, output unit 607, storage unit 608, and communication unit 609. Input unit 606 can be any type of device capable of inputting information to electronic device 600. Input unit 606 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 607 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 608 may include, but is not limited to, disks and optical discs. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0086] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above. For example, in some embodiments, the aforementioned cross-end bridging communication high-payload hierarchical security processing method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. In some embodiments, the computing unit 601 can be configured to perform the aforementioned cross-end bridging communication high-payload hierarchical security processing method by any other suitable means (e.g., by means of firmware).

[0087] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0088] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0089] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0090] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0091] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0092] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A method for hierarchical security handling of high-load cross-terminal bridging communication, characterized in that, The method includes: Obtain the original message generated by the sending container, and determine the security level of the original message and the security policy that matches the security level; The original message is parsed according to the security policy, and sensitive fields, general business fields, public fields and public large fields are extracted from the original message. The public large fields are public data whose data length is greater than the set data length threshold, and the public fields are public data whose data length is less than or equal to the data length threshold. The sensitive fields are encrypted to generate encrypted data, and the public large fields are structured and compressed to obtain a lightweight representation of the public large fields. The lightweight representation, together with the general business fields and the public fields, is the plaintext data in the original message. A payload digest is generated based on the encrypted area data and the plaintext area data, and a signature value of the original message is generated based on the payload digest. A security message is generated based on the payload digest and the signature value, and the security message is sent to the receiving container.

2. The method according to claim 1, characterized in that, The structured compression of the publicly disclosed large fields includes: Extract the key fields from the publicly available large fields, and determine the key fields as the lightweight representation.

3. The method according to claim 1, characterized in that, The step of obtaining the original message generated by the sending container and determining the security level of the original message and the security policy matching the security level includes: The security policy corresponding to the original message is determined based on the method identifier, business sensitivity level, and payload characteristics carried in the original message. The security policy includes: signature rules, encryption rules, and digest rules.

4. The method according to claim 3, characterized in that, If the encryption rule is to perform encryption processing, the step of encrypting the sensitive field to generate encrypted area data includes: The sensitive fields are encrypted according to the encryption algorithm in the encryption rules to generate the encrypted area data.

5. The method according to claim 3, characterized in that, The process of generating a payload digest based on the encrypted area data and the plaintext area data includes: The payload digest is generated based on the encrypted area data and the plaintext area data according to the digest rules.

6. The method according to claim 3, characterized in that, The step of generating the signature value of the original message based on the payload digest includes: The signature value is generated by combining the message identifier, method identifier, source identifier, timestamp information, and payload digest carried in the original message according to the signature rules.

7. The method according to claim 1, characterized in that, After receiving the security message, the method further includes: The receiving container verifies the source and time validity of the security message. If both verifications pass, the security message is decrypted, and the local digest corresponding to the original logical payload view of the security message is reconstructed. If the local digest is consistent with the payload digest, the security message is allowed to enter.

8. A cross-terminal bridging communication high-load hierarchical security processing system, characterized in that, The system includes: a sending container and a receiving container, wherein: The sending container is used for: Determine the security level of the original message and the security policy that matches the security level; parse the original message according to the security policy, and extract sensitive fields, general business fields, public fields and public large fields from the original message. The public large fields are public data whose data length is greater than a set data length threshold, and the public fields are public data whose data length is less than or equal to the data length threshold. The sensitive fields are encrypted to generate encrypted data, and the public large fields are structured and compressed to obtain a lightweight representation of the public large fields. The lightweight representation, together with the general business fields and the public fields, is the plaintext data in the original message. A payload digest is generated based on the encrypted area data and the plaintext area data, and a signature value of the original message is generated based on the payload digest. A security message is generated based on the payload digest and the signature value, and the security message is sent to the receiving container; The receiving container is used to receive the security message and verify the source and time validity of the security message. If both verifications pass, the security message is decrypted and the local digest corresponding to the original logical payload view of the security message is reconstructed. If the local digest is consistent with the payload digest, the security message is allowed to enter.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing a program; wherein the program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images