CN113904840A - Hospital tamper-proof request verification system based on signature - Google Patents
Hospital tamper-proof request verification system based on signature Download PDFInfo
- Publication number
- CN113904840A CN113904840A CN202111165862.6A CN202111165862A CN113904840A CN 113904840 A CN113904840 A CN 113904840A CN 202111165862 A CN202111165862 A CN 202111165862A CN 113904840 A CN113904840 A CN 113904840A
- Authority
- CN
- China
- Prior art keywords
- request
- accesskey
- seqid
- string
- hospital
- 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
- 238000012795 verification Methods 0.000 title claims abstract description 28
- 230000001174 ascending effect Effects 0.000 claims abstract description 7
- 238000010200 validation analysis Methods 0.000 claims description 9
- 230000005540 biological transmission Effects 0.000 claims description 6
- 238000006243 chemical reaction Methods 0.000 claims description 2
- 238000000034 method Methods 0.000 description 6
- 238000012423 maintenance Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Abstract
The invention relates to the technical field of intelligent hospital request verification, and discloses a hospital tamper-proof request verification system based on signatures, which comprises: the system comprises an accessKey module distributed for a developer, wherein the accessKey module arranges non-null request parameters according to the ascending order of letters of request parameter names and splices the non-null request parameters into a string StringA by using a URL key value pair format; splicing accessSecret before and after the string stringA to obtain a string stringSignTemp; performing MD5 operation on the string stringSignTemp, and converting all characters of the obtained string into capitals to obtain a sign value; the request carries the parameter accessKey module and Sign, and only the legal identity accessKey and the correct signature Sign can pass the request. The invention solves the problem of authentication between two parties of a hospital erp system and a SaaS platform calling a request mutually, ensures the throughput of the request by efficiently identifying the opposite party as a legal request, prevents the set request interface from being tampered and re-attacked, ensures that the interface is not easy to exhaust and ensures that a generation algorithm is not easy to guess.
Description
Technical Field
The invention relates to the technical field of intelligent hospital request verification, in particular to a hospital tamper-proof request verification system based on signatures.
Background
In the mobile internet era, a mobile phone becomes an indispensable tool for everybody, the inquiry flow is optimized, the queuing waiting time of patients is reduced, the hospital management pressure is reduced, a smart hospital and an internet hospital almost become the first choice of domestic head hospitals, the smart hospital relies on the communication and payment functions provided by WeChat and Paibao ecology, a smart hospital platform is created by combining industrial characteristics, a solution is provided for users in registration, inquiry, prescription and payment, and the problem of industrial pain points such as long queuing time of users, more hospital resources occupation and the like is thoroughly solved.
The mutual calling requirement of the hospital erp system and the SaaS platform exists in part of functions, authentication (identifying the opposite party as a legal request) in the calling process is a very important step, how to ensure the throughput and the high efficiency of the request is an important consideration point, the prior art schemes are the authentication manually processed by developers, various implementation methods are different, the risk of bypassing the authentication exists, the QPS is low, the maintenance workload is large, and the like.
Disclosure of Invention
The invention aims to provide a signature-based hospital tamper-resistant request verification system, which can ensure the throughput of requests by efficiently identifying the opposite side as a legal request, and the set request interface achieves tamper resistance and heavy attack resistance.
The invention is realized in this way, the hospital tamper-proof request verification system based on signature includes:
the system comprises an accessKey module distributed for a developer, wherein the accessKey module arranges non-null request parameters according to the ascending order of letters of request parameter names and splices the non-null request parameters into a string StringA by using a URL key value pair format;
splicing accessSecret before and after the string stringA to obtain a string stringSignTemp;
performing MD5 operation on the string stringSignTemp, and converting all characters of the obtained string into capitals to obtain a sign value;
the request carries the parameter accessKey module and Sign, and only the legal identity accessKey and the correct signature Sign can pass the request.
Further, when requesting identity, the request verification system allocates an accessKey module and an accessSecret module for a developer, the accessKey module is used for identifying the developer and ensuring uniqueness, the accessSecret module is used for interface encryption and ensures that the interface encryption is not easy to exhaust, and a generation algorithm is not easy to guess.
Further, data transmission of the request verification system is based on https protocol transmission, and data leakage is avoided.
Further, on the accessKey module and Sign carrying parameters of the request, a scheme of timemap + seqId is used for carrying out server side verification on the parameters of the request, wherein the seqId refers to a unique random character string and is used for identifying each signed request.
Further, the seqId provides a unique identifier for each request and is stored, and the server can record all used seqids to prevent them from being used again.
Further, the timestamp is used for optimizing the storage of the seqId, a seqId set recorded in the server is tracked within a specified time, and when a new request enters, the server checks whether the timestamp carried by the seqId completes information feedback within the specified time.
Further, when the accessKey module arranges the non-null request parameters in ascending order according to the letters of the request parameter names, the parameter names include: the time map, the seqId and the accessKey information, wherein the time map is set time, the seqId is the identifier of the request, and the accessKey is the identifier of the developer.
Further, the string StringA specifies parameters to participate in signature verification for solving the verification of non-empty parameters, and requests the uniform conversion of parameter names into lower case.
Further, the server side checks whether the timestamp carried by the seqId completes information feedback within a specified time and returns http "error code 403" uniformly.
Compared with the prior art, the hospital tamper-resistant request verification system based on the signature has the following beneficial effects:
1. the problem of authentication between two parties of a hospital erp system and a SaaS platform calling a request is solved, the throughput of the request is ensured by efficiently identifying the opposite party as a legal request, the set request interface achieves tamper resistance and heavy attack resistance, the accessSecret is used for interface encryption, exhaustion is ensured to be difficult to exhaust, a generation algorithm is difficult to guess, meanwhile, the workload of scheme development and maintenance is greatly reduced, safety loopholes are few, and data are ensured not to be leaked based on an https protocol;
2. requesting parameter names through an accessKey module set as developer identification, converting the parameter names into character strings, finally outputting Sign values, respectively checking the accessKey module and Sign by using a timemap + seqId scheme, seqId being used for identifying each signed request, by providing a unique identifier for each request, the server can prevent the request from being used multiple times, i.e., record all used seqids to prevent them from being used a second time, use timemap to optimize the storage of seqids, meanwhile, tracking the seqId set recorded at the server, when a new request enters, firstly checking whether the carried timeframe is overtime, if the carried timeframe exceeds the time range, rejecting the request, then, inquiring the carried seqId, if the existing set exists, rejecting, otherwise, recording the seqId, and deletes the seqId with the timestamp in the set greater than the timestamp set, for the delete set, the expire of redis can be used, and the new seqId is added while its timeout expiration value is set.
Drawings
FIG. 1 is a block flow diagram of a signature-based hospital tamper-resistant request validation system according to the present invention;
FIG. 2 is a connection block diagram of the verification of a timemap + seqId scheme in the signature-based hospital tamper-resistant request verification system proposed by the present invention;
fig. 3 is a verification flow chart in the signature-based hospital tamper-resistant request verification system according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
The following describes the implementation of the present invention in detail with reference to specific embodiments.
Referring to fig. 1-3, a signature-based hospital tamper-resistant request verification system includes: an accessKey module distributed for developers, wherein the accessKey module arranges non-empty request parameters in ascending order according to letters of request parameter names, and the non-empty request parameters are spliced into a string A by using the format of URL key value pairs (namely key1 value1 and key2 value2 …);
splicing accessSecret before and after the string stringA to obtain a string stringSignTemp;
performing MD5 operation on the string stringSignTemp, and converting all characters of the obtained string into capitals to obtain a sign value;
the request carries the parameter accessKey module and Sign, only the legal identity accessKey and the correct signature Sign can pass, thus solving the problems of identity verification and parameter tampering, and even if the request parameter is hijacked, the legal request can not be forged because the accessSecret can not be obtained (only used for local encryption and does not participate in network transmission).
Specifically, the technical scheme solves the problem of authentication between two parties calling requests of a hospital erp system and a SaaS platform, ensures the throughput of the requests by efficiently identifying the other party as a legal request, prevents falsification and heavy attack of a set request interface, and ensures that the accessSecret is used for interface encryption, so that the method is not easy to exhaust, the generation algorithm is not easy to guess, the workload of scheme development and maintenance is greatly reduced, the security loophole is less, and the data is not leaked based on the https protocol;
the specific process is as follows:
accessKey＝im_client
seqId＝2132311111
timestamp＝1605778738980
accessSecret＝11013f851e7811ebb46b0242ac11001c
the current interface service parameters are as follows: { "biz 1": value1 "-," biz2 "-: value 2" }
A. stringA of the first acquisition should be:
accessKeyim_clientbiz1value1biz2value2seqId2132311111timestamp1605778738980
B. string StringSignTemp obtained in the second step
11013f851e7811ebb46b0242ac11001caccessKeyim_clientbiz1value1biz2value2seqId2132311111timestamp160577873898011013f851e7811ebb46b0242ac11001c
C. Then StringSignTemp is encrypted by md5 to obtain
AD6C3C7F9744D49D47545A51073379BF
D. Final request parameters:
{“biz1”:”value1”,”biz2”:”value2”,”accessKey”:”im_client”,”seqId”:”2132311111”,”timestamp”:”1605778738980”,”sign”:”AD6C3C7F9744D49D47545A51073379BF”}；
in this embodiment, when requesting identity, the request verification system allocates an accessKey module and an accessSecret module for a developer, the accessKey module is a developer identifier to ensure uniqueness, the accessSecret module is used for interface encryption to ensure that exhaustion is not easy, a generation algorithm is not easy to guess, data transmission of the request verification system is based on https protocol transmission, and data leakage is avoided.
In this embodiment, on the accessKey module and Sign carrying the parameter of the request, a server side check is performed on the use request parameter through a scheme of timetag + seqId, seqId refers to a unique random character string for identifying each signed request, seqId provides a unique identifier for each request and stores the unique identifier, the server side can record all used seqids to prevent the seqids from being used for the second time, timetag is used for optimizing the storage of seqId, a seqId set recorded in the server side is tracked in a specified time, when a new request enters, the server side checks whether the timetag carried by seqId completes information feedback in the specified time, and when the server side checks whether the timetag carried by seqId completes information feedback in the specified time as rejection, http "error code 403" is returned uniformly;
for example, assuming that a time difference of at most 20 minutes is allowed between the client and the server, and a seqId set recorded on the server is tracked, when a new request enters, first checking whether the carried timemap is within 20 minutes, if the time difference exceeds a time range, rejecting the carried seqId, and if an existing set exists, rejecting the carried seqId. Otherwise, the seqId is recorded and seqId with timestamp greater than 15 minutes in the set is deleted.
In this embodiment, when the accessKey module arranges the non-null request parameters in ascending order according to the letters of the request parameter names, the parameter names include: the method comprises the steps of obtaining timeframe, seqId and accessKey information, wherein the timeframe is set time, the seqId is a requested identifier, the accessKey is a developer identifier, the character string StringA is used for verifying non-empty parameters, designated parameters participate in verification, requested parameter names are uniformly converted into lower cases, the parameter names are requested through an accessKey module set as the developer identifier, the parameter names are converted into character strings through the parameter names, finally a Sign value is output, and the accessKey module and Sign are verified respectively by using a timeframe + seqId scheme.
In the above technical solution, the parameter name table 1 shows:
table 1: parameter name
When the technical scheme is used, a parameter name is requested through an accessKey module set as a developer identifier, the parameter name is converted into a character string, a Sign value is finally output, the accessKey module and Sign are respectively checked by utilizing a timemap + seqId scheme, seqId is used for identifying each signed request, a unique identifier is provided for each request, a server can prevent the requests from being used for multiple times, namely all used seqIds are recorded to prevent the requests from being used for the second time, storage of the seqIds is optimized by using the timemap, a seqId set recorded in the server is tracked, when a new request enters, whether the carried seqId is overtime is firstly checked, if the carried seqId exceeds a time range, refusal is carried, if an existing set exists, refusal is carried, otherwise, the seqId is recorded, the set seqId with a timestamp larger than the timemap in the set is deleted, and the exception of redis can be used for the deleted set, the method has the advantages that the seqId is added, the overtime failure time value of the seqId is set at the same time, the problem of authentication of two parties of a hospital erp system and a SaaS platform calling request each other is solved, the throughput of the request is guaranteed by efficiently identifying the opposite party as a legal request, the set request interface achieves the purposes of preventing falsification and heavy attack, the accessSecret is used for interface encryption, the difficulty in exhaustion is guaranteed, the generation algorithm is not easy to guess, meanwhile, the workload of scheme development and maintenance is greatly reduced, the security loophole is small, and the data is guaranteed not to be leaked based on the https protocol.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents and improvements made within the spirit and principle of the present invention are intended to be included within the scope of the present invention.
Claims (9)
1. A hospital tamper-resistant request verification system based on signatures, comprising:
the system comprises an accessKey module distributed for a developer, wherein the accessKey module arranges non-null request parameters according to the ascending order of letters of request parameter names and splices the non-null request parameters into a string StringA by using a URL key value pair format;
splicing accessSecret before and after the string stringA to obtain a string stringSignTemp;
performing MD5 operation on the string stringSignTemp, and converting all characters of the obtained string into capitals to obtain a sign value;
the request carries the parameter accessKey module and Sign, and only the legal identity accessKey and the correct signature Sign can pass the request.
2. The signature-based hospital tamper-resistant request validation system according to claim 1, wherein when requesting identity, the request validation system assigns an accessKey module and an accessSecret module to a developer, the accessKey module identifies the developer and ensures uniqueness, the accessSecret module is used for interface encryption and ensures that it is not easy to exhaust and a generation algorithm is not easy to guess.
3. The signature-based hospital tamper-resistant request-validation system according to claim 2, wherein the data transmission of the request-validation system is based on https protocol transport, ensuring that data is not leaked.
4. The signature-based hospital tamper-resistant request validation system according to claim 3, wherein on the request carrying parameters accessKey module and Sign, the using request parameters are subjected to server-side verification by a timemap + seqId scheme, wherein the seqId refers to a unique random string used to identify each signed request.
5. The signature-based hospital tamper-resistant request validation system according to claim 4, wherein said seqId provides a unique identifier for each request and is stored, and the server can record all used seqids to prevent them from being used twice.
6. The signature-based hospital tamper-resistant request verification system according to claim 5, wherein the timestamp is used to optimize the storage of the seqId, the seqId set recorded in the server is tracked within a specified time, and when a new request enters, the server checks whether the timestamp carried by the seqId completes information feedback within the specified time.
7. The signature-based hospital tamper-resistant request validation system of claim 6, wherein when the accessKey module arranges the non-empty request parameters in ascending alphabetical order of request parameter names, said parameter names include: the time map, the seqId and the accessKey information, wherein the time map is set time, the seqId is the identifier of the request, and the accessKey is the identifier of the developer.
8. The signature-based hospital tamper-resistant request validation system according to claim 7, wherein string stringA specifies parameters to participate in the signature verification for solving the check of non-null parameters, requesting uniform conversion of parameter names into lower case.
9. The hospital tamper-resistant request verification system based on signatures of claim 6, wherein the server checks whether the timestamp carried by seqId is rejected when the completion information feedback within the specified time, and then uniformly returns http "error code 403".
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111165862.6A CN113904840A (en) | 2021-09-30 | 2021-09-30 | Hospital tamper-proof request verification system based on signature |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111165862.6A CN113904840A (en) | 2021-09-30 | 2021-09-30 | Hospital tamper-proof request verification system based on signature |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113904840A true CN113904840A (en) | 2022-01-07 |
Family
ID=79190157
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111165862.6A Pending CN113904840A (en) | 2021-09-30 | 2021-09-30 | Hospital tamper-proof request verification system based on signature |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113904840A (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103973695A (en) * | 2014-05-16 | 2014-08-06 | 浪潮电子信息产业股份有限公司 | Signature algorithm for server validation |
| CN104935568A (en) * | 2015-04-20 | 2015-09-23 | 成都康赛信息技术有限公司 | Interface authentication signature method facing cloud platform |
| US20160292678A1 (en) * | 2014-01-02 | 2016-10-06 | Tencent Technology (Shenzhen) Company Limited | Signature verification method, apparatus, and system |
| CN106789997A (en) * | 2016-12-12 | 2017-05-31 | 中国传媒大学 | A kind of encryption method of anti-replay-attack |
| CN107453878A (en) * | 2017-08-11 | 2017-12-08 | 四川长虹电器股份有限公司 | A kind of method for supporting the anti-tamper anti-replays of REST API |
| CN107835080A (en) * | 2017-11-09 | 2018-03-23 | 成都国盛天丰网络科技有限公司 | A kind of distributed system method of data capture and data signature generation method |
| CN109714370A (en) * | 2019-03-07 | 2019-05-03 | 四川长虹电器股份有限公司 | A kind of implementation method based on http protocol end Yunan County full communication |
| CN110753023A (en) * | 2018-07-24 | 2020-02-04 | 阿里巴巴集团控股有限公司 | Equipment authentication method, equipment access method and device |
-
2021
- 2021-09-30 CN CN202111165862.6A patent/CN113904840A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160292678A1 (en) * | 2014-01-02 | 2016-10-06 | Tencent Technology (Shenzhen) Company Limited | Signature verification method, apparatus, and system |
| CN103973695A (en) * | 2014-05-16 | 2014-08-06 | 浪潮电子信息产业股份有限公司 | Signature algorithm for server validation |
| CN104935568A (en) * | 2015-04-20 | 2015-09-23 | 成都康赛信息技术有限公司 | Interface authentication signature method facing cloud platform |
| CN106789997A (en) * | 2016-12-12 | 2017-05-31 | 中国传媒大学 | A kind of encryption method of anti-replay-attack |
| CN107453878A (en) * | 2017-08-11 | 2017-12-08 | 四川长虹电器股份有限公司 | A kind of method for supporting the anti-tamper anti-replays of REST API |
| CN107835080A (en) * | 2017-11-09 | 2018-03-23 | 成都国盛天丰网络科技有限公司 | A kind of distributed system method of data capture and data signature generation method |
| CN110753023A (en) * | 2018-07-24 | 2020-02-04 | 阿里巴巴集团控股有限公司 | Equipment authentication method, equipment access method and device |
| CN109714370A (en) * | 2019-03-07 | 2019-05-03 | 四川长虹电器股份有限公司 | A kind of implementation method based on http protocol end Yunan County full communication |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110268678B (en) | PKI-based login method for authentication agent user and server using same | |
| WO2020134942A1 (en) | Identity verification method and system therefor | |
| CN108834144B (en) | Method and system for managing association of operator number and account | |
| CN110098932B (en) | Electronic document signing method based on safe electronic notarization technology | |
| US20050114447A1 (en) | Method and system for identity exchange and recognition for groups and group members | |
| CN110417790B (en) | Block chain real-name system queuing system and method | |
| CN104184713A (en) | Terminal identification method, machine identification code registration method, and corresponding system and equipment | |
| CN109245897B (en) | Node authentication method and device based on non-interactive zero-knowledge proof | |
| CN110602114B (en) | Block chain-based identity authentication method and device, storage medium and electronic equipment | |
| CN107832602B (en) | Unified electronic seal system based on identification | |
| CN108881309A (en) | Access method, device, electronic equipment and the readable storage medium storing program for executing of big data platform | |
| CN112000744A (en) | Signature method and related equipment | |
| CN110545274A (en) | Method, device and system for UMA service based on people and evidence integration | |
| CN112818325A (en) | Method for realizing API gateway independent authentication based on application | |
| CN108449348B (en) | Online authentication system and method supporting user identity privacy protection | |
| CN113129008B (en) | Data processing method, device, computer readable medium and electronic equipment | |
| CN112308542B (en) | Method and system for realizing intelligent and non-inductive data input | |
| CN112163870B (en) | Information management method based on block chain, analysis node and rework platform | |
| CN110995661B (en) | Network card platform | |
| CN112383401A (en) | User name generation method and system for providing identity authentication service | |
| CN111914231A (en) | Block chain-based identity authentication method, system, equipment and storage medium | |
| CN109150898B (en) | Method and apparatus for processing information | |
| CN115002141B (en) | File storage method and device based on block chain | |
| CN113904840A (en) | Hospital tamper-proof request verification system based on signature | |
| CN109492434A (en) | A kind of method for safely carrying out and system of electronics authority |
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 |