CN115859322A - Hospital transaction data encryption management system - Google Patents
Hospital transaction data encryption management system Download PDFInfo
- Publication number
- CN115859322A CN115859322A CN202211479682.XA CN202211479682A CN115859322A CN 115859322 A CN115859322 A CN 115859322A CN 202211479682 A CN202211479682 A CN 202211479682A CN 115859322 A CN115859322 A CN 115859322A
- Authority
- CN
- China
- Prior art keywords
- hospital
- encryption
- data
- user
- key module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Medical Treatment And Welfare Office Work (AREA)
Abstract
The invention discloses a hospital transaction data encryption management system, which relates to the technical field of transaction data encryption, and comprises an HS (public key module), a card management (private key module) and an MD5 encryption module, wherein the MD5 encryption module comprises a primary encryption part and a secondary MD5 salt addition encryption part, RSA encryption and decryption are carried out through public and private keys, MD5 salt addition encryption is carried out by utilizing different information of each hospital, data comparison is carried out, the legality is verified and the fee is deducted, and the hospital transaction data encryption management system has high safety coefficient, so that a packet is captured and the data is difficult to crack; even if the public key of the hospital is leaked, the legality and the irredifilability of the data can be ensured through the primary encryption of the MD5 and the secondary salt adding encryption of the MD5, and secondly, the public key and the private key of each hospital are independent, the salt values are different, so that the problem of one hospital does not occur, and other hospitals cannot be influenced.
Description
Technical Field
The invention relates to the technical field of transaction data encryption, in particular to a hospital transaction data encryption management system.
Background
In the existing scheme for verifying transaction data, MD5 encryption processing is performed on the transaction data, and then the encrypted data and plaintext data are sent to a verification end. At a verification end, a plaintext is encrypted according to rules, then the plaintext is compared with a ciphertext, if the comparison is successful, the transaction is considered to be legal, however, if the existing method is subjected to packet capturing, the transaction information of a user can be leaked, and secondly, due to the encryption characteristic of MD5, if an exhaustion method or other methods are used, some encrypted data added with a single can be cracked at a certain probability, so that the data can be tampered; finally, the encryption algorithm adopted by the method is single;
aiming at the problems, a secret key mode is adopted, RSA is used for encryption and decryption, meanwhile, in order to further enhance the safety of transaction, on the basis, salt adding encryption of MD5 is used, in addition, verification information of hospital account numbers is added in an encryption program, and related parameters of hospitals are also contained in transaction data, so that the disorder of hospital consumption attribution is prevented.
Disclosure of Invention
The invention aims to solve at least one technical problem in the prior art, and provides a hospital transaction data encryption management system which can solve the safety problem of card swiping and fee deduction of a user in a hospital, verify the legality and data attribution of data and ensure that the transaction is a normal user fee deduction problem.
In order to achieve the purpose, the invention provides the following technical scheme: the utility model provides a hospital transaction data encryption management system, includes HS (public key module), card pipe (private key module) and MD5 encryption module, MD5 encryption module includes first encryption and quadratic MD5 adds salt and encrypts two parts, carries out RSA encryption and decryption and utilizes the different information of every hospital to carry out MD5 and adds salt and encrypt through public, private key, then data comparison, verifies the legitimacy and deducts the expense.
Preferably, the hospital transaction data encryption management method comprises the following specific operation steps: the method comprises the following steps that S1, firstly, a set of public keys and private keys are provided for each hospital to prevent the secret key of a certain hospital from being leaked to cause damage to all hospitals, when the hospitals initiate deduction, users pay fees in cooperative hospitals or other places, and trade cleartexts are encrypted by a public key module (data is named temporarily A);
s2, performing primary MD5 encryption on the transaction data encrypted in the step S1 through an MD5 encryption module, performing salt adding encryption (data temporary name B) on the MD5 again, providing unique information for hospitals as salt (different for each hospital), and storing the data into a hospital server database, so that the encrypted information is not easy to crack and counterfeit;
s3, encrypting the account number provided for the hospital by using a public key module (data temporary name C);
s4, transmitting the data A, B and C in the steps S1, S2 and S3 to a private key module of the server through a webservice calling interface according to the interface specification;
s5, the private key module analyzes the data C, the analyzed value inquires a corresponding salt value (namely a special value provided for a hospital) in a database, whether the user is the private key is judged by judging whether decryption is available or not, if the decryption is successful, the next step is carried out, if the user cannot decrypt, the illegal request is obtained, the user jumps to the public key module, failure is displayed, and the reason of the user is prompted;
s6, after the steps S5 are successful, the server side carries out MD5 encryption on the transmitted data A, then according to the salt value inquired in the step S5, MD5 salt adding encryption is carried out on the data A, then the obtained ciphertext is compared with the transmitted data B, whether the numerical value is equal or not is judged, if the numerical value is correct, the data is considered to be legal and is not tampered, the next step is carried out, if the numerical value is not equal, the illegal request is obtained, the data jumps to a public key module, the failure is displayed, and the reason of a user is prompted;
s7, after the steps S6 are successful, the private key module is used for decrypting the transmitted encrypted transaction data, whether the terminal number and the hospital are in a binding relationship or not is verified, whether the terminal number and the hospital are the user or not is verified, if the terminal number and the hospital are the user, the next step is carried out, if the terminal number and the hospital are not the user, the user also thinks that the terminal number and the hospital are illegal transactions, the next step jumps to the public key module, failure is displayed, and the reason of the user is prompted;
s8, under the condition that all verification passes, whether a terminal number (namely the account state of the user, balance, repeated payment and the like) in the decrypted data belongs to an account number behind the data C or not is judged, if verification is equal, necessary verification is carried out according to the decrypted transaction data, business processing is carried out, the private key module replies success to the public key module, the public key module processes the transaction data after acquiring success information and reminds that the transaction is successful, if verification is unequal, an illegal request is obtained, the illegal request jumps to the public key module, failure is displayed, and the reason of the user is prompted.
Preferably, the salt value provided to the hospital in the step S2 can be updated regularly and actively pushed to the hospital in an encrypted form, so that the salt value in the hospital database changes continuously.
Preferably, after the interface is called in the step S4 to obtain the state of the order, the return status code of the data is detected, if the detection is successful, the next step is performed, if the detection is failed, and the user is reminded according to the reason of the failure.
Compared with the prior art, the invention has the beneficial effects that:
(1) The hospital transaction data encryption management system has high safety factor, and even if a packet is captured, the data is difficult to crack; even if the public key of the hospital is leaked, the data validity and the data irredifilability can be ensured through the primary encryption of MD5 and the secondary salt-adding encryption of MD5, and secondly, the public key and the private key of each hospital are independent pairs, the salt value is different, one hospital has problems, other hospitals cannot be influenced, and the data of the hospital A and the data of the hospital B can be prevented from being mixed because the related safety parameters are independent, and the relevance of the parameters in the plain text and the hospital account number is generated at a service end, so that the accuracy and the validity of the data are further strengthened.
Drawings
The invention is further illustrated with reference to the following figures and examples:
FIG. 1 is a flow chart of a hospital transaction data encryption management system according to the present invention;
FIG. 2 is a flow chart illustrating a call interface according to the present invention.
Detailed Description
Reference will now be made in detail to the present preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout.
In the description of the present invention, it should be understood that the orientation or positional relationship referred to in the description of the orientation, such as the upper, lower, front, rear, left, right, etc., is based on the orientation or positional relationship shown in the drawings, and is only for convenience of description and simplification of description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus, should not be construed as limiting the present invention.
In the description of the present invention, greater than, less than, exceeding, etc. are understood as excluding the present numbers, and the above, below, inside, etc. are understood as including the present numbers. If there is a description of first and second for the purpose of distinguishing technical features only, this is not to be understood as indicating or implying a relative importance or implicitly indicating the number of technical features indicated or implicitly indicating the precedence of technical features indicated.
In the description of the present invention, unless otherwise explicitly limited, terms such as arrangement, installation, connection and the like should be understood in a broad sense, and those skilled in the art can reasonably determine the specific meanings of the above terms in the present invention in combination with the specific contents of the technical solutions.
Referring to fig. 1-2, the present invention provides a technical solution: a hospital transaction data encryption management system comprises an HS (public key module), a card management (private key module) and an MD5 encryption module, wherein the MD5 encryption module comprises a primary encryption part and a secondary MD5 salt adding encryption part, RSA encryption and decryption are carried out through public and private keys, MD5 salt adding encryption is carried out by utilizing different information of each hospital, and then data comparison is carried out to verify the legality and carry out fee deduction.
Meanwhile, the scheme provides another technical scheme; a hospital transaction data encryption management method comprises the following specific operation steps:
s1, firstly, providing a set of public key and private key for each hospital to prevent the secret key of a certain hospital from being leaked to cause damage of all hospitals, paying by a user in a cooperative hospital or other places when the hospitals initiate deduction, and encrypting a transaction plaintext by using a public key module (data is named temporarily A);
s2, performing primary MD5 encryption on the transaction data encrypted in the step S1 through an MD5 encryption module, performing salt adding encryption (data temporary name B) on the MD5 again, providing unique information for hospitals as salt (different for each hospital), and storing the data into a hospital server database, so that the encrypted information is not easy to crack and counterfeit;
s2-1, the salt value provided for the hospital can be updated regularly and is actively pushed to the hospital in an encrypted form, so that the salt value in a hospital database is continuously changed, lawless persons are prevented from stealing user transaction information after cracking the salt value of the hospital, and the safety of the system is further improved;
s3, encrypting the account number provided for the hospital by using a public key module (data temporary name C);
s4, transmitting the data A, B and C in the steps S1, S2 and S3 to a private key module of the server through a webservice calling interface according to the interface specification;
s4-1, after the calling interface acquires the state of the order, detecting a return state code of the data, if the detection is successful, carrying out the next step, if the detection is failed, and reminding a user according to the failure reason;
s5, the private key module analyzes the data C, the analyzed value inquires a corresponding salt value (namely a special value provided for a hospital) in a database, whether the user is the private key is judged by judging whether decryption is available or not, if the decryption is successful, the next step is carried out, if the user cannot decrypt, the illegal request is obtained, the user jumps to the public key module, failure is displayed, and the reason of the user is prompted;
s6, after the steps S5 are successful, the server side carries out MD5 encryption on the transmitted data A, then according to the salt value inquired in the step S5, MD5 salt adding encryption is carried out on the data A, then the obtained ciphertext is compared with the transmitted data B, whether the numerical value is equal or not is judged, if the numerical value is correct, the data is considered to be legal and is not tampered, the next step is carried out, if the numerical value is not equal, the illegal request is obtained, the data jumps to a public key module, the failure is displayed, and the reason of a user is prompted;
s7, after the steps S6 are successful, the private key module is used for decrypting the transmitted encrypted transaction data, whether the terminal number and the hospital are in a binding relationship or not is verified, whether the terminal number and the hospital are the user or not is verified, if the terminal number and the hospital are the user, the next step is carried out, if the terminal number and the hospital are not the user, the user also thinks that the terminal number and the hospital are illegal transactions, the next step jumps to the public key module, failure is displayed, and the reason of the user is prompted;
and S8, under the condition that all verification passes, whether the terminal number in the decrypted data belongs to the account number behind the data C (namely the account state of the user, balance, repeated payment and the like) is verified, if the terminal number in the decrypted data is verified to be equal, necessary verification is carried out according to the decrypted transaction data, service processing is carried out, the private key module replies success information to the public key module, the public key module processes the transaction data after acquiring the success information and reminds the transaction to be successful, if the terminal number in the decrypted data is not verified to be equal, an illegal request is obtained, the illegal request jumps to the public key module, failure is displayed, and the reason of the user is prompted.
The embodiments of the present invention have been described in detail with reference to the accompanying drawings, but the present invention is not limited to the above embodiments, and various changes can be made within the knowledge of those skilled in the art without departing from the gist of the present invention.
Claims (4)
1. A hospital transaction data encryption management system is characterized in that: including HS (public key module), card pipe (private key module) and MD5 encryption module, MD5 encryption module includes two parts of first encryption and quadratic MD5 salt addition encryption, carries out RSA encryption and decryption and utilizes the different information of every hospital to carry out MD5 salt addition encryption through public, private key, then data comparison, verifies the legitimacy and deducts the expense.
2. The hospital transaction data encryption management method provided by claim 1 comprises the following specific operation steps: the method comprises the following steps that S1, firstly, a set of public keys and private keys are provided for each hospital to prevent the secret key of a certain hospital from being leaked to cause damage to all hospitals, when the hospitals initiate deduction, users pay fees in cooperative hospitals or other places, and trade cleartexts are encrypted by a public key module (data is named temporarily A);
s2, performing primary MD5 encryption on the transaction data encrypted in the step S1 through an MD5 encryption module, performing salt adding encryption (data temporary name B) on the MD5 again, providing unique information for hospitals as salt (different for each hospital), and storing the data into a hospital server database, so that the encrypted information is not easy to crack and counterfeit;
s3, encrypting the account number provided for the hospital by using a public key module (data temporary name C);
s4, transmitting the data A, B and C in the steps S1, S2 and S3 to a private key module of the server through a webservice calling interface according to the interface specification;
s5, the private key module analyzes the data C, the analyzed value inquires a corresponding salt value (namely a special value provided for a hospital) in a database, whether the user is the private key is judged by judging whether decryption is available or not, if the decryption is successful, the next step is carried out, if the user cannot decrypt, the illegal request is obtained, the user jumps to the public key module, failure is displayed, and the reason of the user is prompted;
s6, after the steps S5 are successful, the server side carries out MD5 encryption on the transmitted data A, then according to the salt value inquired in the step S5, MD5 salt adding encryption is carried out on the data A, then the obtained ciphertext is compared with the transmitted data B, whether the numerical value is equal or not is judged, if the numerical value is correct, the data is considered to be legal and is not tampered, the next step is carried out, if the numerical value is not equal, the illegal request is obtained, the data jumps to a public key module, the failure is displayed, and the reason of a user is prompted;
s7, after the steps S6 are successful, the private key module is used for decrypting the transmitted encrypted transaction data, whether the terminal number and the hospital are in a binding relationship or not is verified, whether the terminal number and the hospital are the user or not is verified, if the terminal number and the hospital are the user, the next step is carried out, if the terminal number and the hospital are not the user, the user also thinks that the terminal number and the hospital are illegal transactions, the next step jumps to the public key module, failure is displayed, and the reason of the user is prompted;
and S8, under the condition that all verification passes, whether a terminal number (namely the account state of the user, balance, repeated payment and the like) in the decrypted data belongs to the account number behind the data C or not is verified, if verification is equal, necessary verification is carried out according to the decrypted transaction data, service processing is carried out, the private key module replies success to the public key module, the public key module processes the transaction data after acquiring success information and reminds that the transaction is successful, if verification is unequal, an illegal request is obtained, the illegal request jumps to the public key module, failure is displayed, and the reason of the user is prompted.
3. The hospital transaction data encryption management method according to claim 2, characterized in that: the salt value provided for the hospital in the step S2 can be updated regularly and is actively pushed to the hospital in an encrypted form, so that the salt value in the hospital database is continuously changed.
4. The hospital transaction data encryption management method according to claim 2, characterized in that: and S4, after the calling interface acquires the state of the order, detecting a return state code of the data, if the detection is successful, carrying out the next step, if the detection is failed, and reminding the user according to the failure reason.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211479682.XA CN115859322A (en) | 2022-11-22 | 2022-11-22 | Hospital transaction data encryption management system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211479682.XA CN115859322A (en) | 2022-11-22 | 2022-11-22 | Hospital transaction data encryption management system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115859322A true CN115859322A (en) | 2023-03-28 |
Family
ID=85665631
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211479682.XA Pending CN115859322A (en) | 2022-11-22 | 2022-11-22 | Hospital transaction data encryption management system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115859322A (en) |
-
2022
- 2022-11-22 CN CN202211479682.XA patent/CN115859322A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9544142B2 (en) | Data authentication using plural electronic keys | |
| CA2418050C (en) | Linking public key of device to information during manufacture | |
| EP2291787B1 (en) | Techniques for ensuring authentication and integrity of communications | |
| US6314517B1 (en) | Method and system for notarizing digital signature data in a system employing cryptography based security | |
| US6983368B2 (en) | Linking public key of device to information during manufacture | |
| EP0588339B1 (en) | Method of settling charges by using IC cards | |
| US7249102B1 (en) | Original data circulation method, system, apparatus, and computer readable medium | |
| US7254705B2 (en) | Service providing system in which services are provided from service provider apparatus to service user apparatus via network | |
| JP2003521154A (en) | How to issue electronic identification information | |
| US7039808B1 (en) | Method for verifying a message signature | |
| JP2003216237A (en) | Remote monitoring system | |
| US7340773B2 (en) | Multi-stage authorisation system | |
| CN109274650A (en) | A kind of management system and method that electron image is had access to | |
| CN115242553B (en) | Data exchange method and system supporting safe multi-party calculation | |
| EP2461297B1 (en) | Personal identification number distribution device and method | |
| US20090025061A1 (en) | Conditional peer-to-peer trust in the absence of certificates pertaining to mutually trusted entities | |
| CN116976890A (en) | Multi-sign encryption transaction system of block chain | |
| CN116720839B (en) | Financial information management method based on blockchain technology and supervision system thereof | |
| CN113344561A (en) | Digital currency vehicle wallet payment secure encryption communication method and system | |
| CN111507727B (en) | Security control method for non-inductive payment | |
| CN112383577A (en) | Authorization method, device, system, equipment and storage medium | |
| CN107808284B (en) | Payment method based on POS machine system | |
| CN115859322A (en) | Hospital transaction data encryption management system | |
| JP2001147984A (en) | System and method for electronic voting | |
| CN112202549B (en) | Charging management method, charging terminal data processing method and charging management platform data processing method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |