Hospital transaction data encryption management system
By combining RSA encryption/decryption and MD5 salting encryption with public and private key module verification, the problem of transaction data being easily cracked and tampered with is solved, and a hospital transaction data encryption management system with high security and data legitimacy is realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HENAN YUANFENG TECH NETWORK CO LTD
- Filing Date
- 2022-11-22
- Publication Date
- 2026-06-26
AI Technical Summary
In existing technologies, the encryption methods for transaction data are easily cracked, leading to the leakage of user information and the tampering of transaction data. Furthermore, the encryption algorithms are limited and cannot effectively prevent data ownership from becoming disordered.
The system employs RSA encryption and decryption combined with MD5 encryption, utilizing the unique information of each hospital for MD5 salting encryption, and verifies the data through public and private key modules to ensure data legitimacy and ownership.
It improves the security and legality of transaction data, prevents data from being cracked and tampered with, ensures the security and independence of each hospital, and prevents data confusion.
Smart Images
Figure CN115859322B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of transaction data encryption technology, and in particular to a hospital transaction data encryption management system. Background Technology
[0002] Many existing solutions for verifying transaction data involve encrypting the transaction data using MD5 and then sending the encrypted data along with the plaintext data to the verification end. At the verification end, the plaintext is encrypted according to rules and compared with the ciphertext. If the comparison is successful, the transaction is considered legitimate. However, this method has several drawbacks. First, if the transaction is intercepted, the user's transaction information could be leaked. Second, due to the encryption properties of MD5, brute-force methods or other techniques can potentially crack some encrypted transaction data, allowing for data tampering. Finally, this method uses a relatively simple encryption algorithm.
[0003] To address the above issues, a key-based approach is adopted, using RSA for encryption and decryption. To further enhance transaction security, MD5 salting encryption is also used on top of this. Additionally, hospital account verification information is added to the encryption process, and relevant hospital parameters are included in the transaction data to prevent confusion regarding hospital spending attribution. Summary of the Invention
[0004] The purpose of this invention is to at least solve one of the technical problems existing in the prior art, and to provide a hospital transaction data encryption management system that can solve the security problem when users swipe their cards and pay at the hospital, verify the legality and ownership of the data, and ensure that the transaction is a normal user payment.
[0005] To achieve the above objectives, the present invention provides the following technical solution: a hospital transaction data encryption management system, comprising an HS (public key module), a card management (private key module), and an MD5 encryption module. The MD5 encryption module comprises two parts: initial encryption and secondary MD5 salting encryption. RSA encryption and decryption are performed using public and private keys, and MD5 salting encryption is performed using different information from each hospital. Then, data comparison is performed to verify legality and deduct fees.
[0006] Preferably, a hospital transaction data encryption management method has the following specific operation steps: S1, First, a set of public and private keys is provided for each hospital to prevent the leakage of a certain hospital's key, which would cause damage to all hospitals. When a hospital initiates a deduction, the user pays at the same time at a cooperating hospital or other places, and the plaintext of the transaction is encrypted using the public key module (the data is temporarily named A).
[0007] S2. Then, the transaction data encrypted in step S1 is first encrypted with MD5 by the MD5 encryption module, and then salted and encrypted again with MD5 (the data is temporarily named B). The unique information provided to the hospital is used as the salt (different for each hospital), and these data are stored in the hospital's server database. This makes the encrypted information difficult to crack and difficult to forge.
[0008] S3. The account provided to the hospital will be encrypted using a public key module (the data will be temporarily named C);
[0009] S4. According to the interface specifications, the three data points A, B, and C from steps S1, S2, and S3 are transmitted to the private key module of the server via a web service call interface.
[0010] S5. The private key module parses the transmitted data C. The parsed value is used to query the corresponding salt value (i.e., the special value provided to the hospital) in the database. The module determines whether the user is the correct user by whether the data can be decrypted. If the decryption is successful, the next step is performed. If the data cannot be decrypted, it is considered an illegal request, and the system will redirect to the public key module and display a failure message, indicating the reason to the user.
[0011] After steps S6 and S5 are successful, the server performs MD5 encryption on the transmitted data A. Then, based on the salt value obtained in step S5, it performs MD5 encryption on data A again with added salt. The resulting ciphertext is then compared with the transmitted data B to determine if the values are equal. If they are correct, the data is considered legitimate and has not been tampered with, and the next step is initiated. If the values are not equal, it is considered an illegal request, and the server redirects to the public key module, displays a failure message, and prompts the user with the reason.
[0012] After steps S7 and S6 are successful, the encrypted transaction data transmitted is decrypted using the private key module. The terminal number and hospital are then verified to determine if they are bound to the user. If they are bound, the process proceeds to the next step. If they are not bound, the transaction is considered invalid, and the system redirects to the public key module, displays a failure message, and prompts the user with the reason.
[0013] S8. If all verifications pass, the terminal number in the decrypted data (i.e., the user's account status, balance, whether there is duplicate payment, etc.) will be checked to see if it belongs to the account after data C. If the verification is equal, the necessary verification will be performed based on the decrypted transaction data, and business processing will be carried out. The private key module will reply with a success message to the public key module. After receiving the success message, the public key module will process the transaction data and notify the user of the successful transaction. If the verification is not equal, it is an illegal request, and the user will be redirected to the public key module, where a failure message will be displayed, and the user will be prompted with the reason.
[0014] Preferably, the salt value provided to the hospital in step S2 can be updated periodically and actively pushed to the hospital in encrypted form, so that the salt value in the hospital database is constantly changing.
[0015] Preferably, in step S4, after the interface obtains the order status, it checks the return status code of the data. If the check is successful, it proceeds to the next step; if the check fails, it alerts the user based on the reason for the failure.
[0016] Compared with the prior art, the beneficial effects of the present invention are:
[0017] (1) The hospital's transaction data encryption management system has a high security level. Even if the packet is captured, it is difficult to crack the data. Even if the hospital's public key is leaked, the data can be ensured to be legal and immutable through the first MD5 encryption and the second MD5 salt encryption. Secondly, each hospital's public key and private key are an independent pair with different salt values. If one hospital has a problem, it will not affect other hospitals. Since the relevant security parameters are independent, it can also prevent the data of Hospital A from being confused with the data of Hospital B. The correlation between the parameters in plaintext and the hospital account is generated on the server side, which further strengthens the accuracy and legality of the data. Attached Figure Description
[0018] The present invention will be further described below with reference to the accompanying drawings and embodiments:
[0019] Figure 1 This is a flowchart of a hospital transaction data encryption management system according to the present invention;
[0020] Figure 2 This is a schematic diagram of the process of calling the interface of the present invention. Detailed Implementation
[0021] This section will describe in detail specific embodiments of the present invention. Preferred embodiments of the present invention are shown in the accompanying drawings. The purpose of the drawings is to supplement the textual description with graphics, so that people can intuitively and vividly understand each technical feature and overall technical solution of the present invention, but they should not be construed as limiting the scope of protection of the present invention.
[0022] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.
[0023] In the description of this invention, terms such as greater than, less than, and exceeding are understood to exclude the stated number, while terms such as above, below, and within are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.
[0024] In the description of this invention, unless otherwise explicitly defined, terms such as "set up," "install," and "connect" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.
[0025] Please see Figure 1-2 This invention provides a technical solution: a hospital transaction data encryption management system, including HS (public key module), card management (private key module) and MD5 encryption module. The MD5 encryption module includes two parts: initial encryption and secondary MD5 salting encryption. It uses public and private keys to perform RSA encryption and decryption and uses different information from each hospital to perform MD5 salting encryption. Then, the data is compared to verify the legality and deduct the fee.
[0026] This solution also provides another technical solution: a method for encrypted management of hospital transaction data, the specific operation steps of which are as follows:
[0027] S1. First, a set of public and private keys is provided for each hospital to prevent the leakage of a hospital's key from causing damage to all hospitals. When a hospital initiates a deduction, the user pays at the same time at a cooperating hospital or other places, and the plaintext of the transaction is encrypted using the public key module (the data is temporarily named A).
[0028] S2. Then, the transaction data encrypted in step S1 is first encrypted with MD5 by the MD5 encryption module, and then salted and encrypted again with MD5 (the data is temporarily named B). The unique information provided to the hospital is used as the salt (different for each hospital), and these data are stored in the hospital's server database. This makes the encrypted information difficult to crack and difficult to forge.
[0029] S2-1. The salt value provided to the hospital can be updated periodically and actively pushed to the hospital in encrypted form. In this way, the salt value in the hospital database is constantly changing, which prevents criminals from stealing user transaction information after cracking the hospital's salt value, and further improves the security of the system.
[0030] S3. The account provided to the hospital will be encrypted using a public key module (the data will be temporarily named C);
[0031] S4. According to the interface specifications, the three data points A, B, and C from steps S1, S2, and S3 are transmitted to the private key module of the server via a web service call interface.
[0032] S4-1. After the API call obtains the order status, it checks the return status code of the data. If the check is successful, proceed to the next step. If the check fails, notify the user according to the reason for the failure.
[0033] S5. The private key module parses the transmitted data C. The parsed value is used to query the corresponding salt value (i.e., the special value provided to the hospital) in the database. The module determines whether the user is the correct user by whether the data can be decrypted. If the decryption is successful, the next step is performed. If the data cannot be decrypted, it is considered an illegal request, and the system will redirect to the public key module and display a failure message, indicating the reason to the user.
[0034] After steps S6 and S5 are successful, the server performs MD5 encryption on the transmitted data A. Then, based on the salt value obtained in step S5, it performs MD5 encryption on data A again with added salt. The resulting ciphertext is then compared with the transmitted data B to determine if the values are equal. If they are correct, the data is considered legitimate and has not been tampered with, and the next step is initiated. If the values are not equal, it is considered an illegal request, and the server redirects to the public key module, displays a failure message, and prompts the user with the reason.
[0035] After steps S7 and S6 are successful, the encrypted transaction data transmitted is decrypted using the private key module. The terminal number and hospital are then verified to determine if they are bound to the user. If they are bound, the process proceeds to the next step. If they are not bound, the transaction is considered invalid, and the system redirects to the public key module, displays a failure message, and prompts the user with the reason.
[0036] S8. If all verifications pass, the terminal number in the decrypted data will be checked to see if it belongs to the account after data C (i.e., the user's account status, balance, whether there is duplicate payment, etc.). If the verification is equal, the necessary verification will be performed based on the decrypted transaction data, and business processing will be carried out. The private key module will reply with a success message to the public key module. After receiving the success message, the public key module will process the transaction data and notify the user of the successful transaction. If the verification is not equal, it is an illegal request, and the user will be redirected to the public key module, where a failure message will be displayed, and the user will be prompted with the reason.
[0037] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.
Claims
1. A method for encrypted management of hospital transaction data, characterized in that: The specific steps are as follows: S1. First, a set of public and private keys is provided to each hospital to prevent the leakage of a hospital's key from causing damage to all hospitals. When a hospital initiates a deduction, the user pays at the same time at a cooperating hospital or other places. The plaintext of the transaction is encrypted using the public key module to obtain data A. S2. Then, the encrypted transaction data in step S1 is first encrypted with MD5 by the MD5 encryption module, and then salted and encrypted again to obtain data B. Then, different unique information is provided to each hospital as salt, and these data are stored in the hospital's server database. This makes the encrypted information difficult to crack and difficult to forge. S3. Encrypt the account provided to the hospital using a public key module to obtain data C; S4. According to the interface specifications, the three data points A, B, and C from steps S1, S2, and S3 are transmitted to the private key module of the server via a web service call interface. S5. The private key module parses the transmitted data C. The parsed value is used to query the corresponding salt value in the database, which is the special value provided to the hospital. The module determines whether the user is the correct user by whether the data can be decrypted. If the decryption is successful, the next step is performed. If the data cannot be decrypted, it is considered an illegal request, and the system will redirect to the public key module and display a failure message with the reason for the failure to the user. After steps S6 and S5 are successful, the server performs MD5 encryption on the transmitted data A. Then, based on the salt value obtained in step S5, it performs MD5 encryption on data A again with added salt. The resulting ciphertext is then compared with the transmitted data B to determine if the values are equal. If they are correct, the data is considered legitimate and has not been tampered with, and the next step is initiated. If the values are not equal, it is considered an illegal request, and the server redirects to the public key module, displays a failure message, and prompts the user with the reason. After steps S7 and S6 are successful, the encrypted transaction data transmitted is decrypted using the private key module. The terminal number and hospital are then verified to determine if they are bound to the user. If they are bound, the next step is performed. If they are not bound, the transaction is considered invalid, and the user is redirected to the public key module. The failure message is displayed, and the user is prompted with the reason. The terminal number includes the user's account status, balance, and whether there is a duplicate payment. S8. If all verifications pass, the terminal number in the decrypted data will be checked to see if it belongs to the account decrypted from data C. If the verification is equal, the necessary verification will be performed based on the decrypted transaction data, and business processing will be carried out. The private key module will reply with a success message to the public key module. After receiving the success message, the public key module will process the transaction data and notify the user of the successful transaction. If the verification is not equal, it is considered an illegal request, and the user will be redirected to the public key module, where a failure message will be displayed, and the user will be prompted with the reason.
2. The method for encrypted management of hospital transaction data according to claim 1, characterized in that: In step S2, the salt value provided to the hospital is updated periodically and actively pushed to the hospital in encrypted form, so that the salt value in the hospital database is constantly changing.
3. The method for encrypted management of hospital transaction data according to claim 2, characterized in that: In step S4, after the API call obtains the order status, it checks the return status code of the data. If the check is successful, it proceeds to the next step; if the check fails, it alerts the user based on the reason for the failure.
4. A hospital transaction data encryption management system, implemented based on the hospital transaction data encryption management method according to any one of claims 1-3, characterized in that: It includes an HS public key module, a card management private key module, and an MD5 encryption module. The MD5 encryption module consists of two parts: initial encryption and secondary MD5 salting encryption. It uses public and private keys to perform RSA encryption and decryption, and uses different information from each hospital to perform MD5 salting encryption. Then, the data is compared to verify the legality and deduct the fee.