Information security protection method and device for cloud payment system, and medium

Abstract

The invention relates to an information security protection method of a cloud payment system. The method comprises the following steps: acquiring a to-be-transmitted request parameter, and encrypting the request parameter by using an encryption algorithm to generate encrypted request data; sending the encrypted request data to a server, and enabling the server to decrypt the encrypted request data and execute corresponding business processing; receiving encrypted response data from the server, wherein the encrypted response data is generated by encrypting the service processing result by the server by using an encryption algorithm; decrypting the encrypted response data by using an encryption algorithm to obtain an original response result; a key used by the encryption algorithm is stored in a configuration file of the client; receiving a confusion character string configured into the configuration file from the server, wherein the confusion character string is generated after the server performs confusion coding on the sensitive character string and adds an identification prefix in front of a confusion coding result; when the configuration file is read, an obfuscated character string containing the identification prefix is identified, and de-obfuscation is performed to restore the sensitive character string.

Description

Technical Field

[0001] The exemplary embodiments disclosed herein generally relate to the field of information security technology, and more specifically to an information security protection method for a cloud payment system. The exemplary embodiments disclosed herein also relate to an information security protection device and medium for a cloud payment system. Background Technology

[0002] With the rapid development of the digital economy and the continuous evolution of mobile internet technology, cloud payment services, as an important carrier of the modern financial service system, have achieved extensive integration with various third-party ecosystems such as e-commerce, social platforms, and lifestyle services. While this open and interconnected business model enhances the convenience and coverage of financial services, it also significantly expands the security threats faced by the system. Especially under the current increasingly stringent regulations on personal information protection, operating companies face the dual pressure of ensuring user data security and meeting regulatory compliance requirements.

[0003] In the actual operation of cloud payment systems, the protection of sensitive data has always been a key focus and challenge in security system construction. Security assessments of existing cloud payment systems reveal a widespread risk of sensitive data "exposure" in two crucial areas: interface data interaction and system configuration management. "Exposure" refers to the security vulnerability where sensitive data is stored, transmitted, or exposed in plaintext without authorization. This risk can occur in multiple scenarios, including data transmission, log recording, and configuration storage, and due to its concealed and dispersed nature, it is often difficult to effectively control using traditional security measures.

[0004] Currently, the industry has established some basic technical practices for protecting sensitive data in cloud payment systems. In log security management, rule-based content filtering and de-identification mechanisms are typically employed. This involves partially replacing or masking sensitive strings such as identified user identity information, account details, and payment vouchers to prevent complete plaintext information from being directly recorded in log files. Regarding configuration file protection, obfuscated naming or field replacement methods are used for high-risk sensitive data fields in configuration files to reduce readability. Furthermore, at the front-end code protection level, code compression and logic obfuscation techniques are commonly used. Renaming code identifiers and flattening control flow increase the difficulty of static analysis.

[0005] However, these existing technical solutions have revealed significant limitations in practical applications. First, log anonymization mechanisms have blind spots. Relying on a pre-defined sensitive data rule base, they are prone to rule mismatches when faced with newly added interface parameters or complex nested data structures during rapid business iterations, resulting in some sensitive data not being effectively protected. Second, obfuscating or replacing fields in configuration files does not change the fact that sensitive data is stored in plaintext. Without encrypted storage, it is essentially a low-security form of "mask-style evasion." Once the configuration file is illegally obtained, attackers can easily reconstruct the original content through reverse engineering. Finally, the primary design goal of front-end code obfuscation technology is to protect intellectual property, and its ability to prevent sensitive data leakage is inherently insufficient. Faced with increasingly advanced dynamic debugging tools and decompilation techniques, obfuscated code can still be gradually parsed, especially for sensitive data such as business keys hard-coded in client programs, where obfuscation technology struggles to provide effective protection.

[0006] These technical shortcomings make it difficult for existing protection solutions to systematically address the end-to-end protection needs of sensitive data in cloud payment scenarios. Therefore, there is an urgent need for an innovative solution that can achieve deep security hardening across all stages of data transmission, processing, and storage, fundamentally improving the overall security protection capabilities of cloud payment systems and effectively safeguarding user privacy and system compliance. Summary of the Invention

[0007] In view of this, this disclosure provides an information security protection method for a cloud payment system, which achieves end-to-end security protection of the cloud payment system through end-to-end two-way encryption and dynamic obfuscation technology. While ensuring the confidentiality of data transmission and eliminating plaintext traces of configuration files, it significantly improves the system's resistance to attacks in a non-intrusive manner.

[0008] To achieve the above objectives, in a first aspect of this disclosure, an information security protection method for a cloud payment system is provided, comprising: acquiring request parameters to be transmitted; encrypting the request parameters using an encryption algorithm to generate encrypted request data; sending the encrypted request data to a server, causing the server to decrypt the encrypted request data and execute corresponding business processing; receiving encrypted response data from the server, wherein the encrypted response data is generated by the server encrypting the business processing result using the encryption algorithm; decrypting the encrypted response data using the encryption algorithm to obtain the original response result; wherein the key used by the encryption algorithm is stored in a configuration file on the client; receiving an obfuscated string configured in the configuration file by the server, wherein the obfuscated string is generated by the server obfuscating sensitive strings in the original string and adding an identifier prefix before the obfuscated encoding result; and when reading the configuration file, identifying the obfuscated string containing the identifier prefix and performing deobfuscation processing to restore the sensitive string.

[0009] Optionally, sending the encrypted request data to the server, so that the server decrypts the encrypted request data and performs corresponding business processing, further includes: the server decrypts the received encrypted request data to obtain the original request parameters, performs business processing based on the original request parameters, generates response data, encrypts the response data using the encryption algorithm, generates encrypted response data, and sends it to the client.

[0010] Optionally, receiving the obfuscated string configured in the configuration file by the server, wherein the obfuscated string is generated by the server obfuscating sensitive strings in the original string and adding an identifier prefix before the obfuscated encoding result, further includes: the server identifying the sensitive strings to be protected in the original string, converting individual characters of the sensitive strings into character encoding values, converting the character encoding values ​​into hexadecimal strings of a first preset length, mapping individual characters in the first preset length hexadecimal strings to character combinations of a second preset length through a predefined character relationship table, adding a specific identifier prefix before the mapped second preset length character combinations, generating the obfuscated string and storing it in the configuration file.

[0011] Optionally, the character relationship table establishes a mapping relationship between hexadecimal characters and the second preset length of character combinations, wherein the second preset length of character combinations includes a specific character set and has no semantic features.

[0012] Optionally, the step of identifying the obfuscated string containing the identifier prefix and performing deobfuscation processing to restore the sensitive string when reading the configuration file further includes: reading the obfuscated string in the configuration file; in response to detecting that the obfuscated string contains the identifier prefix, removing the identifier prefix and extracting the subsequent character content; grouping the character content into character combinations according to a second preset length, and restoring each group of character combinations into corresponding hexadecimal characters using a predefined character relationship table; combining the restored hexadecimal characters into a hexadecimal string according to a first preset length, and converting the combined hexadecimal string into a character encoding value; and restoring the characters of the sensitive string according to the character encoding value.

[0013] Optionally, the encryption algorithm is a symmetric encryption algorithm, which adopts a block encryption mode to encrypt and decrypt the request parameters and the encrypted response data respectively. The encryption process includes block encryption and standardized encapsulation of the data.

[0014] Optionally, it also includes key management: setting key parameters on the configuration platform of the server; establishing a key synchronization mechanism between the server and the client so that the server and the client use the same key; periodically updating the key and completing the synchronized distribution of the key.

[0015] Optionally, the original string includes plaintext configuration information stored in the configuration file and plaintext configuration information input through the server's configuration platform.

[0016] In a second aspect, embodiments of this disclosure provide an electronic device, including a memory and a processor, wherein the memory stores a program that runs on the processor, and the processor executes the information security protection method of the cloud payment system as described in the first aspect when running the program.

[0017] In a third aspect, embodiments of this disclosure provide a computer-readable storage medium having computer instructions stored thereon, which, when executed, perform the information security protection method for the cloud payment system as described in the first aspect.

[0018] Compared with existing technologies, the information security protection method for the cloud payment system provided in this disclosure has at least the following beneficial effects: By employing encryption algorithms to implement end-to-end encryption of request parameters and response data, sensitive data is effectively prevented from being stolen or subjected to man-in-the-middle attacks during transmission. The simple and highly compatible encryption mode perfectly adapts to the high-frequency interface calls of cloud payment services, minimizing performance loss while providing security. The two-way encryption mechanism ensures the confidentiality of the entire communication link from client to server; even if data packets are intercepted using packet capture tools, plaintext business data cannot be directly read. Encrypted transmission also avoids the risk of sensitive data being recorded in plaintext in logs, eliminating information leakage at the source. The original strings of sensitive data in the configuration file are converted into character combinations without actual semantic meaning, completely eliminating plaintext traces in the configuration file. The obfuscated strings have a uniform character distribution and no semantic features, significantly increasing the difficulty of static analysis and effectively resisting reverse engineering attacks. The dynamic deobfuscation mechanism ensures that the business system can automatically restore configuration information at runtime, and the entire process is non-intrusive to business logic, maintaining the system's usability. The entire solution forms a multi-layered and in-depth security protection system, comprehensively improving the overall security protection level of the cloud payment system. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of this disclosure, the embodiments of this disclosure will be further explained and described with reference to the following drawings. These drawings are only used to more conveniently and specifically describe the embodiments of this disclosure and are not intended to limit this disclosure. In the drawings:

[0020] Figure 1 A flowchart illustrating an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown;

[0021] Figure 2 A flowchart of block 10 of a cloud payment system information security protection method according to one embodiment of the present disclosure is shown;

[0022] Figure 3 A flowchart of block 110 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown;

[0023] Figure 4 A flowchart of block 120 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown;

[0024] Figure 5 A flowchart of block 20 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown;

[0025] Figure 6A flowchart of block 210 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown;

[0026] Figure 7 A flowchart of block 220 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown;

[0027] Figure 8 A flowchart illustrating block 230 of an information security protection method for a cloud payment system according to an embodiment of the present disclosure is shown; and

[0028] Figure 9 A schematic diagram of the structure of the electronic device 900 in the embodiment of this application. Detailed Implementation

[0029] In the description of this disclosure, unless otherwise expressly specified and limited, the term "comprising" and similar terms shall be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" shall be understood as "at least partially based on". The term "one embodiment" or "the embodiment" shall be understood as "at least one embodiment". The term "some embodiments" shall be understood as "at least some embodiments". Other explicit and implicit definitions may also be included below.

[0030] This disclosure provides an information security protection method for a cloud payment system, establishing a complete end-to-end encrypted communication mechanism to ensure that sensitive data is encrypted throughout the transmission between the client and the server. Figure 1 This is a flowchart of an information security protection method for a cloud payment system according to one embodiment of this disclosure. Figure 1 As shown, the implementation method of the information security protection method of this cloud payment system can include two parts: interface communication encryption and decryption in box 10 and configuration file security governance in box 20. Figure 2 A flowchart of block 10 of a cloud payment system information security protection method according to one embodiment of the present disclosure is shown. Figure 2 As shown, the interface communication encryption and decryption in box 10 may include: in box 110, the client obtains the request parameters to be transmitted, encrypts the request parameters using an encryption algorithm, generates encrypted request data, and sends it to the server; in box 120, the server decrypts the encrypted request data and executes the corresponding business processing, encrypts the business processing result using an encryption algorithm to generate encrypted response data; in box 130, the client uses an encryption algorithm to decrypt the encrypted response data and obtain the original response result.

[0031] refer to Figure 3 , Figure 3A flowchart of block 110 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown. Figure 3 As shown in box 110, the client obtains the request parameters to be transmitted, encrypts the request parameters using an encryption algorithm, and sends the encrypted request data to the server. The specific steps are as follows:

[0032] In box 1101, the client obtains the request parameters to be transmitted from the business logic layer of the cloud payment system.

[0033] In this embodiment, in a cloud payment business scenario, when a user initiates a payment transaction or other operations involving sensitive data, the client first needs to obtain a complete set of request parameters from the business logic layer of the cloud payment system. This set of request parameters includes, but is not limited to, key information such as payment amount, user identity identifier, merchant number, transaction timestamp, and business type code.

[0034] In one embodiment, the client performs standardized preprocessing on request parameters, including: arranging the request parameters according to a predefined field order to eliminate potential security risks caused by inconsistent parameter order; simultaneously, performing encoding standardization on all string-type request parameters to ensure the use of a uniform character encoding format and avoid data processing errors caused by encoding differences; furthermore, performing format validation and range checks on numeric request parameters to ensure data validity and legality. This operation ensures the standardization and consistency of request parameter data before encryption.

[0035] In box 1102, an encryption algorithm is used to perform encryption processing on the request parameters to generate encrypted request data.

[0036] In one embodiment, after preprocessing the request parameters, the processed parameters are serialized according to an agreed data format to form a structured data block. This data block needs to meet the specific requirements of the encryption algorithm, including data length and format specifications. For the encryption algorithm selection, a securely verified symmetric encryption algorithm is used, such as the ECB (Electronic Codebook) mode of AES (Advanced Encryption Standard), which can perform efficient encryption operations on the data block. During encryption, the client uses a pre-securely distributed key to convert plaintext data into ciphertext data through block encryption. The encryption operation is performed in the client's local secure environment, ensuring that sensitive data in the plaintext data is not exposed in plaintext form in memory or on the transmission link.

[0037] In box 1103, send the encrypted request data to the server.

[0038] In one embodiment, after encryption, the client encapsulates the encrypted request data into a standard communication protocol data packet, such as HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure), and adds an encryption identifier field to the header of the encrypted request data to explicitly identify it as an encrypted payload. The encapsulated encrypted request data is then sent to the server via a secure channel. During transmission, even if the encrypted request data is intercepted by an intermediate node, an attacker cannot directly obtain meaningful sensitive data.

[0039] In this embodiment, the transmission status is monitored throughout the entire transmission process to ensure reliable delivery of the encrypted request data. If a network anomaly or transmission failure occurs, the client will initiate a retransmission mechanism to complete the reliable transmission of the encrypted request data while ensuring data security. This complete request parameter encryption process ensures that sensitive data is fully protected at the initiating end.

[0040] refer to Figure 4 , Figure 4 A flowchart of block 120 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown. Figure 4 As shown in box 120, the server decrypts the encrypted request data and executes the corresponding business processing. The encryption algorithm is used to encrypt the business processing result to generate encrypted response data, which can be specifically executed in the following steps:

[0041] In box 1201, after receiving the encrypted request data, the server identifies the encryption identifier in the header of the encrypted request data. After confirming that the data is encrypted, it extracts the encrypted request data and performs a decryption operation.

[0042] In box 1202, the server decrypts the received encrypted request data to obtain the original request parameters, performs business processing based on the original request parameters, and generates response data.

[0043] In one embodiment, the server identifies the encryption algorithm type and key by parsing the metadata information in the encrypted request data message, and then decrypts the received encrypted request data using a pre-configured key. During decryption, data integrity is verified to ensure that the ciphertext data has not been tampered with during transmission. After successful decryption, the server passes the obtained original request parameters to the business processing module for logical operations and data processing.

[0044] In one embodiment, the server executes corresponding business operations based on the decrypted original request parameters, including but not limited to payment transaction processing, account information query, and risk assessment analysis. During processing, detailed operation logs are recorded, and response data containing processing results, status codes, and business data is generated.

[0045] In box 1203, the server uses an encryption algorithm to encrypt the response data, generating encrypted response data.

[0046] In this embodiment, the server uses the same key and encryption algorithm as the client to encrypt and protect the generated response data.

[0047] In one embodiment, before the encryption operation, necessary security metadata, including encryption timestamps, data sequence numbers, and other auxiliary information, is added to the response data to enhance the traceability and security of the response data transmission.

[0048] In box 1204, the server sends the encrypted response data to the client and adds an encryption identifier to the header of the encrypted response data, indicating that the encrypted response data needs to be decrypted.

[0049] In box 130, the client uses an encryption algorithm to decrypt the encrypted response data and obtain the original response result. Specifically, after receiving the encrypted response data, the client identifies the encryption identifier and calls the decryption module. The decryption module uses the key stored in the local configuration file to decrypt the encrypted response data and obtain readable plaintext response data for use by the business layer.

[0050] In one embodiment, the key used by the client is stored in the client's configuration file, while the key used by the server is configured on the server's configuration platform.

[0051] In this embodiment, the client-side key employs a secure storage mechanism, being encrypted and stored in a configuration file, with access control policies implemented to prevent unauthorized access and use. The server-side key is centrally configured and managed on the cloud payment system's server-side configuration platform. This platform provides comprehensive key management functions, including the entire process of key generation, storage, distribution, updating, and destruction. It also includes an automated key synchronization mechanism, maintaining key consistency between the client and server through an encrypted secure channel to ensure the normal operation of encryption and decryption.

[0052] refer to Figure 5 , Figure 5 A flowchart of block 20 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown. Figure 5As shown, the security governance of the configuration file in Box 20 may include: in Box 210, the server performs obfuscation encoding on sensitive strings in the original string, and adds an identifier prefix before the obfuscation encoding result to generate an obfuscated string; in Box 220, when reading the configuration file, the obfuscated string containing the identifier prefix is ​​identified, and deobfuscation processing is performed to restore the sensitive string.

[0053] refer to Figure 6 , Figure 6 A flowchart of block 210 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown. Figure 6 As shown in box 210, the server performs obfuscation encoding on sensitive strings in the original string, and adds an identifier prefix to the obfuscated string to generate the obfuscated string. This can be specifically executed in the following steps:

[0054] In box 2101, the server identifies the sensitive strings to be protected in the original string.

[0055] In one embodiment, the original string includes plaintext configuration information stored in the configuration file and plaintext configuration information input through the server-side configuration platform.

[0056] In one embodiment, when initiating the obfuscation process, it is first necessary to identify and obtain the sensitive strings to be processed. These sensitive strings mainly originate from configuration parameters in JavaScript code, including but not limited to important information such as API interface addresses, database connection strings, keys, and authentication tokens. The server scans and parses the plaintext configuration information, identifies sensitive strings containing sensitive data, and extracts them into a secure processing area in memory for subsequent operations.

[0057] In box 2102, each character of the sensitive string is converted into a character encoding value, and then the character encoding value is converted into a hexadecimal string of a first preset length.

[0058] In one embodiment, each character of the sensitive string is converted to its corresponding UTF-16 encoded value. This step ensures full support for various global language character sets, including Chinese, English, numbers, and special symbols, and all possible configuration content. The choice of UTF-16 encoding guarantees a wide range of encoding options and consistent processing. After the encoding conversion is complete, these character encoded values ​​are uniformly converted into a hexadecimal string of a first preset length.

[0059] In box 2103, a single character in a hexadecimal string of a first preset length is mapped to a character combination of a second preset length using a predefined character relationship table.

[0060] In one embodiment, a predefined character relationship table establishes a mapping relationship between complete hexadecimal characters and character combinations of a second preset length. The second preset length of character combinations includes a specific character set and has no semantic features. The hexadecimal string is converted using the predefined character relationship table. The predefined character relationship table can be a custom YST-encoded character relationship table, and the second preset length can be three characters long. Specifically, it maps the hexadecimal character "0" to "yyy", "1" to "yys", "2" to "yst", ..., "f" to "sty". This specifically designed mapping rule ensures that each hexadecimal character uniquely corresponds to a three-character combination, and the mapping result has no readable semantics. Each character in the hexadecimal string is sequentially converted to its corresponding three-character combination.

[0061] In box 2104, a specific identifier prefix is ​​added before the second preset length character combination after mapping, generating an obfuscated string and storing it in the configuration file.

[0062] In one embodiment, after the mapping conversion is completed, a specific identifier prefix is ​​added to the obfuscated string result to identify it as an obfuscated encrypted string at runtime. This identifier prefix uses a designed, fixed string format with sufficient uniqueness and recognizability to clearly distinguish it from regular strings in the configuration file. The design of the identifier prefix considers various factors, including string length, the uniqueness of character combinations, and compatibility with business data, ensuring accurate identification during subsequent decoding. The addition of the identifier prefix provides a reliable basis for dynamic decoding at runtime.

[0063] In one embodiment, a complete obfuscated string with a specific identifier prefix is ​​written to the configuration file. During the writing process, the original structure and format of the configuration items in the configuration file are maintained, ensuring that other attributes and non-sensitive strings in the configuration file are unaffected; only sensitive strings are replaced with obfuscated strings in ciphertext form. Simultaneously, a detailed obfuscation processing log is recorded, including but not limited to the name of the processed configuration item, processing time, and the version of the character relation table used, providing a basis for subsequent troubleshooting. After all processing is completed, sensitive data in the configuration file exists in an unreadable obfuscated form, fundamentally eliminating the risk of plaintext leakage of sensitive data in the configuration file, while ensuring that the system can use this sensitive data normally during runtime through the corresponding deobfuscation mechanism.

[0064] refer to Figure 7 , Figure 7 A flowchart of block 220 of an information security protection method for a cloud payment system according to one embodiment of the present disclosure is shown. Figure 7As shown in box 220, when reading the configuration file, identifying obfuscated strings containing specific identifier prefixes and performing deobfuscation to restore sensitive strings can be specifically performed in the following steps:

[0065] In box 2201, read the string from the configuration file.

[0066] In one embodiment, during system initialization or runtime, string content is read from the client's configuration file. During the reading process, preliminary format validation is performed to check the basic structure and encoding standards of the string, ensuring data integrity and processability, and avoiding processing errors caused by data anomalies.

[0067] In box 2202, check if the string contains a specific identifier prefix. If so, it is identified as an obfuscated string, and box 2203 is executed; otherwise, box 2207 is executed, and the string is read and run directly as a normal string.

[0068] In one embodiment, after reading is complete, identifier recognition is performed, including a rapid scan and pattern matching of the string content to detect whether the string contains a specific identifier prefix. When a specific identifier prefix is ​​detected, a deobfuscation process is triggered. This detection process employs a precise pattern matching mechanism to ensure that only correctly obfuscated strings enter the subsequent deobfuscation process, while plaintext strings are directly passed to the business logic.

[0069] In box 2203, in response to detecting that the obfuscated string contains a specific identifier prefix, the identifier prefix is ​​removed and the subsequent character content is extracted.

[0070] In one embodiment, the identifier prefix at the beginning of the obfuscated string is removed, and the subsequent character content is retained as the core data for deobfuscation. This operation needs to follow a preset rule for the length of the identifier prefix to ensure that valid data is not accidentally deleted.

[0071] In box 2204, the character content is grouped according to the second preset length to generate character combinations, and each character combination is restored to the corresponding hexadecimal character through a predefined character relationship table.

[0072] In one embodiment, the second preset length can be three characters, and the character content can be a YST encoded sequence. The YST encoded sequence is processed according to a grouping rule of three consecutive characters as a processing unit to generate YST encoded character combinations. This grouping method corresponds completely to the encoding rules in the obfuscation stage. A predefined character relationship table is called to convert each character combination back to its corresponding hexadecimal character. This conversion process requires strict data verification to ensure that each character combination is within the valid range of the character relationship table.

[0073] In box 2205, the restored hexadecimal characters are combined according to the first preset length to generate a hexadecimal string, and each group of hexadecimal strings is converted into a character encoding value. The characters of the sensitive string are restored based on the character encoding value.

[0074] In one embodiment, the first preset length is set to four characters. The resulting hexadecimal characters are combined in groups of four, with each group of four hexadecimal characters corresponding to a UTF-16 encoded value. During the combination process, the integrity and validity of the hexadecimal characters are verified to ensure that the data format conforms to the UTF-16 encoding standard. For incomplete or abnormally formatted hexadecimal characters, an error handling mechanism is activated, detailed logs are recorded, and appropriate recovery measures are taken.

[0075] In one embodiment, each UTF-16 encoded value is converted to its corresponding Unicode character and combined in the original order to form the complete plaintext sensitive string. During the conversion process, the UTF-16 encoded values ​​are verified to ensure that all UTF-16 encoded values ​​are within the valid encoding range. After the sensitive string is restored, the obtained plaintext sensitive string is finally verified, including but not limited to checks on string length and character set compatibility, to ensure the accuracy and usability of the decoding result.

[0076] In box 2206, the restored sensitive string is injected into the client's business logic to complete the loading and execution of the configuration items.

[0077] In this embodiment, the entire deobfuscation process is completed in memory. After decryption, the sensitive data in the configuration file is directly used by the business logic without leaving any plaintext traces on disk, logs, or any persistent storage. This dynamic deobfuscation mechanism ensures both the security of the sensitive data in the configuration file during storage and the availability of the sensitive data in the configuration file during system runtime.

[0078] In one embodiment, the configuration file security governance in box 20 further includes box 230, whereby after the server-side configuration platform inputs plaintext configuration information, it stores the sensitive data in the configuration information in encrypted form in the client's configuration file.

[0079] refer to Figure 8 , Figure 8 A flowchart of block 230 of an information security protection method for a cloud payment system according to an embodiment of the present disclosure is shown. As shown in block 230, after the server-side configuration platform inputs plaintext configuration information, storing sensitive data in the configuration information in encrypted form in the client's configuration file can be specifically performed through the following steps:

[0080] In box 2301, the configuration platform on the server provides a configuration file editing interface, which allows operators to input or modify the contents of the configuration file in plain text.

[0081] This embodiment provides a visual configuration file editing interface, enhancing the existing configuration file management functions to offer developers and operations personnel an intuitive and convenient configuration file editing environment. The interface employs intelligent recognition technology to automatically distinguish between sensitive and ordinary configuration items using different visual identifiers. Sensitive data configuration items can be highlighted in the configuration interface with specific background colors, icons, or text prompts, enabling operators to clearly identify configuration file content requiring special protection. During the editing process, the format and security of the input content are verified in real time, and prompts are provided for non-compliant input to prevent security risks caused by configuration errors.

[0082] In box 2302, when the server detects that the operator has saved a configuration item containing sensitive data, it automatically triggers a string obfuscation process to convert the plaintext sensitive data in the configuration item into an obfuscated string and store it in the client's configuration file.

[0083] In one embodiment, when an operator modifies the configuration file in the configuration file editing interface and performs a save operation, the integrity of all configuration items is first verified to ensure that all necessary configuration items are filled in and comply with business rules. Subsequently, all configuration items marked as sensitive data are automatically identified, and a string obfuscation process is initiated for these sensitive data configuration items. This process is executed automatically in the backend of the cloud payment system, and the operator does not need to concern themselves with the specific encryption details. Based on the string obfuscation algorithm, the plaintext sensitive data configuration items are converted into obfuscated strings without actual semantic meaning, while retaining the structural information and metadata of the configuration items. At runtime, the client executes the deobfuscation process for the obfuscated strings, allowing the operator to use the sensitive data configuration items without needing to be aware of the details of the sensitive strings.

[0084] The mechanism in this embodiment implements the "what you see is not what you get" security design principle, which ensures the manageability of configuration items for sensitive data while eliminating the risk of plaintext exposure of sensitive data.

[0085] This disclosure provides an information security protection method for a cloud payment system. To comprehensively enhance the security protection capabilities of the cloud payment system, it is necessary to collaborate with the backend server of the cloud payment system to promote security hardening. End-to-end encryption is implemented for the request parameters and response data of the interface to prevent data from being stolen or attacked in the middle during transmission. The method also promotes the encrypted storage and dynamic loading and decryption mechanism of configuration files, so that the configuration items of sensitive data exist in encrypted form in the code and storage. When the code is executed, the data is decrypted and automatically injected into the business logic layer, ensuring that sensitive data is not exposed in plaintext. At the same time, it supports the development and maintenance experience of operators editing in plaintext and storing in encrypted form, thus balancing security and maintainability.

[0086] Example 2

[0087] The following is for reference. Figure 9 This document illustrates a structural diagram of an electronic device 900 suitable for implementing embodiments of the present application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may 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 illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.

[0088] like Figure 9 As shown, electronic device 900 may include processing device 910, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 920 or a program loaded from storage device 980 into random access memory (RAM) 930. Processing device 910 may be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processing device 910 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processing device 910 performs the various methods and processes described above.

[0089] The RAM 930 also stores various programs and data required for the operation of the electronic device 900. The processing device 910, ROM 920, and RAM 930 are interconnected via bus 940. The input / output (I / O) interface 950 is also connected to bus 940.

[0090] Typically, the following devices can be connected to I / O interface 950: input devices 960 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 970 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 980 including, for example, magnetic tapes, hard disks, etc.; and communication devices 990. Communication device 990 allows electronic device 900 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 9 An electronic device 900 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0091] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 990, or installed from a storage device 980, or installed from a ROM 920. When the computer program is executed by the processing device 910, it performs the functions defined in the methods of the embodiments of this application. Alternatively, in other embodiments, the processing device 910 may be configured by any other suitable means (e.g., by means of firmware) to perform the following methods: acquiring request parameters to be transmitted, encrypting the request parameters using an encryption algorithm to generate encrypted request data; sending the encrypted request data to a server, causing the server to decrypt the encrypted request data and perform corresponding business processing; receiving encrypted response data from the server, wherein the encrypted response data is generated by the server encrypting the business processing result using an encryption algorithm; decrypting the encrypted response data using an encryption algorithm to obtain the original response result; wherein the key used by the encryption algorithm is stored in the client's configuration file; receiving an obfuscated string configured in the configuration file by the server, wherein the obfuscated string is generated by the server obfuscating sensitive strings in the original string and adding an identifier prefix before the obfuscated encoding result; and when reading the configuration file, identifying the obfuscated string containing the identifier prefix and performing deobfuscation processing to restore the sensitive string.

[0092] Example 3

[0093] The computer-readable medium described in this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0094] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0095] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0096] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes these programs, the electronic device causes the following actions: It acquires request parameters to be transmitted, encrypts the request parameters using an encryption algorithm, and generates encrypted request data; it sends the encrypted request data to a server, causing the server to decrypt the encrypted request data and execute corresponding business processing; it receives encrypted response data from the server, wherein the encrypted response data is generated by the server encrypting the business processing result using an encryption algorithm; it decrypts the encrypted response data using an encryption algorithm to obtain the original response result; wherein the key used by the encryption algorithm is stored in the client's configuration file; it receives an obfuscated string configured in the configuration file by the server, wherein the obfuscated string is generated by the server obfuscating sensitive strings in the original string and adding an identifier prefix before the obfuscated encoding result; and when reading the configuration file, it identifies obfuscated strings containing the identifier prefix and performs deobfuscation processing to restore the sensitive strings.

[0097] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0099] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the modules themselves.

[0100] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof, etc.

[0101] 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.

[0102] 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.

[0103] 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).

[0104] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users 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., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0105] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is established by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem that addresses the management difficulties and weak business scalability inherent in traditional physical hosting and VPS services. Servers can also be servers for distributed systems or servers integrated with blockchain technology.

[0106] Artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies mainly include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0107] Cloud computing refers to a technology system that enables access to a shared pool of physical or virtual resources via a network. These resources can include servers, operating systems, networks, software, applications, and storage devices, and can be deployed and managed on demand and in a self-service manner. Cloud computing technology can provide efficient and powerful data processing capabilities for applications such as artificial intelligence and blockchain, as well as for model training.

[0108] The embodiments described above are some, but not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0109] In the description of the embodiments of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of this application is in use. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the electric vehicle or component referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the present invention. In addition, the terms "first," "second," and "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0110] In the description of the embodiments of this application, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0111] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the technical scope disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for information security protection of a cloud payment system, characterized in that, include: Obtain the request parameters to be transmitted, encrypt the request parameters using an encryption algorithm, and generate encrypted request data; The encrypted request data is sent to the server, which then decrypts the encrypted request data and performs the corresponding business processing. Receive encrypted response data from the server, wherein the encrypted response data is generated by the server encrypting the business processing result using the encryption algorithm; The encrypted response data is decrypted using the encryption algorithm to obtain the original response result; The encryption key used by the encryption algorithm is stored in the client's configuration file; Receive an obfuscated string configured in the configuration file by the server, wherein the obfuscated string is generated by the server obfuscating sensitive strings in the original string and adding an identifier prefix to the obfuscated string result; When reading the configuration file, the obfuscated string containing the identifier prefix is ​​identified, and deobfuscation is performed to restore the sensitive string.

2. The information security protection method for the cloud payment system according to claim 1, characterized in that, The step of sending the encrypted request data to the server, so that the server decrypts the encrypted request data and performs corresponding business processing, further includes: The server decrypts the received encrypted request data to obtain the original request parameters, performs business processing based on the original request parameters, generates response data, encrypts the response data using the encryption algorithm, generates encrypted response data, and sends it to the client.

3. The information security protection method for the cloud payment system according to claim 1, characterized in that, The receiving of the obfuscated string from the configuration file configured by the server, wherein the obfuscated string is generated by the server obfuscating sensitive strings in the original string and adding an identifier prefix to the obfuscated encoding result, further includes: The server identifies the sensitive strings to be protected in the original string, converts each character of the sensitive string into a character encoding value, converts the character encoding value into a hexadecimal string of a first preset length, maps each character in the first preset length hexadecimal string to a character combination of a second preset length using a predefined character relationship table, adds a specific identifier prefix before the mapped second preset length character combination, generates the obfuscated string, and stores it in the configuration file.

4. The information security protection method for the cloud payment system according to claim 3, characterized in that, The character relationship table establishes a mapping relationship between hexadecimal characters and the second preset length of character combinations, which includes a specific character set and has no semantic features.

5. The information security protection method for the cloud payment system according to claim 1, characterized in that, The step of identifying the obfuscated string containing the identifier prefix when reading the configuration file, and performing deobfuscation processing to restore the sensitive string, further includes: Read the obfuscated string from the configuration file; In response to detecting that the obfuscated string contains the identifier prefix, the identifier prefix is ​​removed, and the subsequent character content is extracted; The character content is grouped according to a second preset length to generate character combinations, and a single group of character combinations is restored to the corresponding hexadecimal character using a predefined character relationship table; The restored hexadecimal characters are combined according to a first preset length to generate a hexadecimal string, and the combined single hexadecimal string is converted into a character encoding value; The characters of the sensitive string are restored based on the character encoding value.

6. The information security protection method for the cloud payment system according to claim 1, characterized in that, The encryption algorithm is a symmetric encryption algorithm. The symmetric encryption algorithm adopts a block encryption mode to encrypt and decrypt the request parameters and the encrypted response data respectively. The encryption process includes block encryption and standardized encapsulation of the data.

7. The information security protection method for the cloud payment system according to claim 1, characterized in that, It also includes key management: Configure the key parameters on the server's configuration platform; Establish a key synchronization mechanism between the server and the client, so that the server and the client use the same key; The key is updated periodically, and the key is synchronously distributed.

8. The information security protection method for the cloud payment system according to claim 1 or 3, characterized in that, The raw string includes plaintext configuration information stored in the configuration file and plaintext configuration information input through the server's configuration platform.

9. An electronic device, characterized in that, The system includes a memory and a processor, wherein the memory stores a program that runs on the processor, and the processor executes the information security protection method for a cloud payment system according to any one of claims 1-8 when running the program.

10. A computer-readable storage medium storing computer instructions thereon, characterized in that, The computer instructions execute the information security protection method of the cloud payment system according to any one of claims 1-8.

Images