CN116074039A - File secure transmission method and system based on HTTPS protocol - Google Patents
File secure transmission method and system based on HTTPS protocol Download PDFInfo
- Publication number
- CN116074039A CN116074039A CN202211510487.9A CN202211510487A CN116074039A CN 116074039 A CN116074039 A CN 116074039A CN 202211510487 A CN202211510487 A CN 202211510487A CN 116074039 A CN116074039 A CN 116074039A
- Authority
- CN
- China
- Prior art keywords
- file
- request
- module
- client
- server
- 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
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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- 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
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention provides a file secure transmission method and a system based on an HTTPS protocol, wherein the method comprises the following steps: step S1: the server and the client respectively carry out SM2 public-private key negotiation with the encryptor cluster; step S2: the client encapsulates the custom field in the HTTPS request header and sends the server; step S3: the server side verifies the client side request and verifies the identity legitimacy of the client side; step S4: the server constructs a file transmission HTTPS response message and sends the client; step S5: the client processes the file transfer response. The invention solves the problem of high cost of verifying the identity legitimacy of the client by the server in the file transmission process; the method and the device solve the problem of high cost of generating the HTTPS certificate for each client in the file transmission process.
Description
Technical Field
The invention relates to the technical field of network information, in particular to a file secure transmission method and system based on an HTTPS protocol.
Background
In the informatization construction process, file transmission is used in various industries and business scenes, and the file transmission refers to that one file or part of the file is transmitted from one computer system to another computer system, wherein FTP and HTTP are common file transmission protocols. HTTP is known as hypertext transfer protocol (HyperText Transfer Protocol), and HTTP uploading is more suitable for WEB applications and small file uploading (within 10M), not suitable for large file uploading, and has poor security, such as: communication uses plaintext (not encrypted), and content may be eavesdropped; verifying the identity of the communicating party and thus potentially encountering masquerading; the integrity of the message cannot be verified, so that the message may be tampered with. It is therefore important to ensure the security of file transfer.
Most of the prior terminal file transmission modes do not pay enough attention to the security of file transmission, most of the prior file transmission security mechanisms only encrypt or encode the upgrade file, the file transmission only relates to a server and a client, and the prior terminal file transmission modes lack perfect identity authentication mechanisms and also do not have precaution mechanisms for file information leakage, so that a perfect file transmission mode is particularly needed at present.
Patent document CN109428899a (application number: CN 201710719512.7) discloses a file secure transmission management method and system, the method comprising: the client is in communication connection with the server; inquiring server side information of files existing at a server side, and returning the client side; encrypting and compressing data information of the file according to the setting of the client, and sending the data information to the server; the server side decompresses and decrypts the file; the client sends an integrity request, and the server receives the integrity request, checks hash value information of the file and returns the client; and judging the integrity of file transmission. However, the patent document does not perform validity verification on the client identity information, the file information and the request information, and cannot be applied to a scene with high requirements on file transmission security.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to provide a file secure transmission method and system based on an HTTPS protocol.
The file secure transmission method based on the HTTPS protocol provided by the invention comprises the following steps:
step S1: the server and the client respectively carry out SM2 public-private key negotiation with the corresponding encryption machine clusters;
step S2: the client encapsulates the custom field in the HTTPS request header and sends the server;
step S3: the server side verifies the client side request and verifies the identity legitimacy of the client side;
step S4: the server constructs a file transmission HTTPS response message and sends the client;
step S5: the client processes the file transfer response.
Preferably, in said step S1:
step S1.1: the server and the server encryptor cluster A are deployed in the same intranet, and the client encryptor cluster B are deployed in the same intranet;
step S1.2: importing working keys into the encryptor cluster A and the encryptor cluster B;
step S1.3: the server generates a session key and sends the session key to the encryptor cluster A, and the encryptor cluster A generates an SM2 public key and a SM2 private key according to the working key and the session key;
step S1.4: the server sends the session key to the client, the client sends the session key to the encryptor cluster B, and the encryptor cluster B generates the same SM2 public key and private key.
Preferably, in said step S2:
the client encapsulates a custom field with identity information, file information, request information and signature information in the HTTPS request header and sends a server;
step S2.1: the client acquires original data comprising a request line, a user code UserID, a system time stamp TimeStamp and a file storage path FilePath, and sends preprocessed data SrcData to an encryptor cluster B;
step S2.2: the encryptor cluster B calculates the HASH abstract value of the data SrcData according to an SM3 algorithm, encrypts the abstract value by using an SM2 private key to generate a digital signature PkgSign and returns the digital signature PkgSign to the client;
step S2.3: the client performs Base64 coding on the digital Signature PkgSign, encapsulates a Signature algorithm (increases algorithm expandability) in the generated data, and acquires a Signature field value Signature;
step S2.4: adding custom header fields in the request header of HTTPS, including USER-ID field (filled with userID value), TIMESTAMP field (filled with TimeStamp value), FILE-PATH field (filled with FilePath value) and SIGNATURE field (filled with Signature value);
step S2.5: and adding file data in byte stream format in the HTTPS request body, and sending the packaged HTTPS request to the server.
Preferably, in said step S3:
step S3.1: after receiving the HTTPS request, the server analyzes the message, and acquires the request line and a newly added header field in the request header, including user code UserID, a system TimeStamp TimeStamp, a file storage path FilePath and a digital Signature;
step S3.2: verifying whether a request method and UserID, timeStamp, filePath in the RequestLine are legal or not, if so, discarding the request and recording a log;
step S3.3: verifying the file signature, preprocessing the original data of RequestLine, userID, timeStamp and FilePath, and transmitting the preprocessed data SrcData to the encryptor cluster A;
step S3.4: the encryptor cluster A calculates the abstract HashData of SrcData according to the SM3 algorithm, and returns the value to the server;
step S3.5: the server side decodes the field Signature of the head of the request by Base64, acquires decoded data PkgSign and sends the decoded data to the encryptor cluster A;
step S3.6: the encryptor cluster A decrypts PkgSign according to the negotiated SM2 public key, acquires decrypted data PkgData and returns to the server;
step S3.7: the server side judges whether the abstract value HashData is equal to the PkgData, if so, the identity authentication of the client side passes, otherwise, the server side fails, and the request is discarded and the log is recorded;
step S3.8: after passing the verification, different responses are made according to the request type.
Preferably, in said step S4:
step S4.1: judging the request type, and responding differently according to the request type:
query class: adding json format query information into the body of the request body, and returning standard HTTPS response information;
uploading: writing the body data of the request body into a local directory file, and returning standard HTTPS response information;
creation and deletion of classes: executing the corresponding file operation and then returning standard HTTPS response information;
download class: executing the step S4.2;
step S4.2: locally reading file Data to be downloaded, and generating an MD5 hash value MD5Data of the file Data;
step S4.3: base16 coding is carried out on the hash value MD5Data, and the coding value is filled into a custom header field DIGESET in a response header;
step S4.4: filling the file data into a response body and sending the file data to a client;
in the step S5:
step S5.1: receiving and analyzing the HTTPS response message, judging whether the response result is successful or not, exiting and recording a log if the response result is unsuccessful, and successfully executing the step S5.2;
step S5.2: judging the type of the response message, if the response message is the response message of file downloading, executing the step S5.3, otherwise, recording that the request is successful and ending;
step S5.3: acquiring a custom header field DIGESET value in the response header, and performing Base16 decoding on the DIGESET value to acquire data DigestData;
step S5.4: reading file Data FileData in a response body, and calculating MD5 hash value MD5Data of the FileData;
step S5.5: judging whether the DigestData value is equal to the MD5Data value, if so, downloading the file, if the integrity verification of the file is passed, and storing the file; otherwise, the verification fails.
The invention provides a file secure transmission system based on an HTTPS protocol, which comprises:
module M1: enabling the server and the client to respectively carry out SM2 public and private key negotiation with the corresponding encryption machine clusters;
module M2: the client encapsulates the custom field in the header of the HTTPS request header and sends the server;
module M3: the server side is enabled to check the client side request and verify the identity legitimacy of the client side;
module M4: enabling the server to construct a file transmission HTTPS response message and send the client;
module M5: causing the client to process the file transfer response.
Preferably, in said module M1:
module M1.1: the server and the server encryptor cluster A are deployed in the same intranet, and the client encryptor cluster B are deployed in the same intranet;
module M1.2: leading in working keys in the encryptor cluster A and the encryptor cluster B;
module M1.3: the server generates a session key and sends the session key to the encryptor cluster A, and the encryptor cluster A generates an SM2 public key and a SM2 private key according to the working key and the session key;
module M1.4: the server sends the session key to the client, and the client sends the session key to the encryptor cluster B, which generates the same SM2 public key and private key.
Preferably, in said module M2:
the client encapsulates the custom field with the identity information, the file information, the request information and the signature information in the header of the HTTPS request header and sends the custom field to the server;
module M2.1: the client acquires original data comprising a request line, a user code UserID, a system time stamp TimeStamp and a file storage path FilePath, and sends the preprocessed data SrcData to an encryptor cluster B;
module M2.2: the encryption machine cluster B calculates the HASH abstract value of the data SrcData according to an SM3 algorithm, encrypts the abstract value by using an SM2 private key to generate a digital signature PkgSign and returns the digital signature PkgSign to the client;
module M2.3: the client side performs Base64 coding on the digital Signature PkgSign, and encapsulates a Signature algorithm (increases algorithm expandability) in the generated data to obtain a Signature field value Signature;
module M2.4: adding custom header fields in the request header of HTTPS, including USER-ID field (filled with userID value), TIMESTAMP field (filled with TimeStamp value), FILE-PATH field (filled with FilePath value) and SIGNATURE field (filled with Signature value);
module M2.5: and adding file data in byte stream format in the HTTPS request body, and sending the packaged HTTPS request to the server.
Preferably, in said module M3:
module M3.1: after receiving HTTPS request, the server side analyzes the message to obtain request line and newly added header field in request header, including user code UserID, system time stamp TimeStamp, file storage path and digital Signature;
module M3.2: verifying whether a request method and UserID, timeStamp, filePath in the RequestLine are legal or not, if so, discarding the request and recording a log;
module M3.3: verifying the file signature, preprocessing the original data of RequestLine, userID, timeStamp and FilePath, and transmitting the preprocessed data SrcData to the encryptor cluster A;
module M3.4: the encryption machine cluster A calculates abstract HashData of SrcData according to an SM3 algorithm, and returns the value to the server;
module M3.5: the server side decodes the field Signature of the head of the request by Base64, acquires decoded data PkgSign and sends the decoded data to the encryptor cluster A;
module M3.6: decrypting the PkgSign by the encryptor cluster A according to the negotiated SM2 public key to obtain decrypted data PkgData and returning the decrypted data to the server;
module M3.7: enabling the server to judge whether the abstract value HashData is equal to the PkgData, if so, passing the identity authentication of the client, otherwise, failing, discarding the request and recording a log;
module M3.8: after passing the verification, different responses are made according to the request type.
Preferably, in said module M4:
module M4.1: judging the request type, and responding differently according to the request type:
query class: adding json format query information into the body of the request body, and returning standard HTTPS response information;
uploading: writing the body data of the request body into a local directory file, and returning standard HTTPS response information;
creation and deletion of classes: executing the corresponding file operation and then returning standard HTTPS response information;
download class: an execution module M4.2;
module M4.2: locally reading file Data to be downloaded, and generating an MD5 hash value MD5Data of the file Data;
module M4.3: base16 coding is carried out on the hash value MD5Data, and the coding value is filled into a custom header field DIGESET in a response header;
module M4.4: filling the file data into a response body and sending the file data to a client;
in the module M5:
module M5.1: receiving and analyzing an HTTPS response message, judging whether the response result is successful or not, exiting and recording a log if the response result is unsuccessful, and executing the module M5.2 successfully;
module M5.2: judging the type of the response message, if the response message is the response message of file downloading, executing the module M5.3, otherwise, recording that the request is successful and ending;
module M5.3: acquiring a custom header field DIGESET value in the response header, and performing Base16 decoding on the DIGESET value to acquire data DigestData;
module M5.4: reading file Data FileData in a response body, and calculating MD5 hash value MD5Data of the FileData;
module M5.5: judging whether the DigestData value is equal to the MD5Data value, if so, downloading the file, if the integrity verification of the file is passed, and storing the file; otherwise, the verification fails.
Compared with the prior art, the invention has the following beneficial effects:
1. the invention solves the problem of high cost of verifying the identity legitimacy of the client by the server in the file transmission process;
2. the invention adds the self-defined digital signature field in the header of the HTTPS standard message, fills the digital signature value generated by the encryption machine, and completes the identity verification of the client by the server, thereby solving the high cost problem of generating the HTTPS certificate for each client in the file transmission process.
3. The invention preprocesses the identity information of the client, the file information and the request information, and sends the preprocessed information to the encryptor cluster, the encryptor cluster generates a digital signature by using the preprocessed information and returns the digital signature to the client, and the client sends the file to the server through the HTTPS protocol according to the expandability of the HTTPS standard message header and the combination of the digital signature. The server completes signature verification of the digital signature through the encryptor, so that the validity verification of the client identity by the server is realized, and the safety is improved.
Drawings
Other features, objects and advantages of the present invention will become more apparent upon reading of the detailed description of non-limiting embodiments, given with reference to the accompanying drawings in which:
FIG. 1 is a HTTPS request message structure;
FIG. 2 is a HTTPS response message structure;
FIG. 3 is a basic network diagram of a system;
FIG. 4 is a flow chart of HTTPS request message construction;
FIG. 5 is a HTTPS authentication flow;
FIG. 6 is a HTTPS message response flow;
fig. 7 is a file integrity verification process.
Detailed Description
The present invention will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the present invention, but are not intended to limit the invention in any way. It should be noted that variations and modifications could be made by those skilled in the art without departing from the inventive concept. These are all within the scope of the present invention.
Example 1:
when a client server sends a file, preprocessing client identity information, file information and request information, sending the preprocessed information to an encryptor cluster, generating a digital signature by the encryptor cluster through the preprocessed information, and returning the digital signature to the client, wherein the client sends the file to a server through an HTTPS protocol according to the expandability of an HTTPS standard message header and the combination of the digital signature. The server side completes signature verification of the digital signature through the encryption machine, so that validity verification of the client side identity by the server side is realized, and the problem of high cost of the client side identity verification by the server side in the file transmission process is solved.
By adding a self-defined digital signature field in the header of the HTTPS standard message and filling the digital signature value generated by the encryptor, the server completes the authentication of the client, thereby solving the high cost problem of generating the HTTPS certificate for each client in the file transmission process.
According to the file secure transmission method based on the HTTPS protocol, as shown in figures 1-6, the method comprises the following steps:
step S1: the server and the client respectively carry out SM2 public-private key negotiation with the corresponding encryption machine clusters;
specifically, in the step S1:
step S1.1: the server and the server encryptor cluster A are deployed in the same intranet, and the client encryptor cluster B are deployed in the same intranet;
step S1.2: importing working keys into the encryptor cluster A and the encryptor cluster B;
step S1.3: the server generates a session key and sends the session key to the encryptor cluster A, and the encryptor cluster A generates an SM2 public key and a SM2 private key according to the working key and the session key;
step S1.4: the server sends the session key to the client, the client sends the session key to the encryptor cluster B, and the encryptor cluster B generates the same SM2 public key and private key.
Step S2: the client encapsulates the custom field in the HTTPS request header and sends the server;
specifically, in the step S2:
the client encapsulates a custom field with identity information, file information, request information and signature information in the HTTPS request header and sends a server;
step S2.1: the client acquires original data comprising a request line, a user code UserID, a system time stamp TimeStamp and a file storage path FilePath, and sends preprocessed data SrcData to an encryptor cluster B;
step S2.2: the encryptor cluster B calculates the HASH abstract value of the data SrcData according to an SM3 algorithm, encrypts the abstract value by using an SM2 private key to generate a digital signature PkgSign and returns the digital signature PkgSign to the client;
step S2.3: the client performs Base64 coding on the digital Signature PkgSign, encapsulates a Signature algorithm (increases algorithm expandability) in the generated data, and acquires a Signature field value Signature;
step S2.4: adding custom header fields in the request header of HTTPS, including USER-ID field (filled with userID value), TIMESTAMP field (filled with TimeStamp value), FILE-PATH field (filled with FilePath value) and SIGNATURE field (filled with Signature value);
step S2.5: and adding file data in byte stream format in the HTTPS request body, and sending the packaged HTTPS request to the server.
Step S3: the server side verifies the client side request and verifies the identity legitimacy of the client side;
specifically, in the step S3:
step S3.1: after receiving the HTTPS request, the server analyzes the message, and acquires the request line and a newly added header field in the request header, including user code UserID, a system TimeStamp TimeStamp, a file storage path FilePath and a digital Signature;
step S3.2: verifying whether a request method and UserID, timeStamp, filePath in the RequestLine are legal or not, if so, discarding the request and recording a log;
step S3.3: verifying the file signature, preprocessing the original data of RequestLine, userID, timeStamp and FilePath, and transmitting the preprocessed data SrcData to the encryptor cluster A;
step S3.4: the encryptor cluster A calculates the abstract HashData of SrcData according to the SM3 algorithm, and returns the value to the server;
step S3.5: the server side decodes the field Signature of the head of the request by Base64, acquires decoded data PkgSign and sends the decoded data to the encryptor cluster A;
step S3.6: the encryptor cluster A decrypts PkgSign according to the negotiated SM2 public key, acquires decrypted data PkgData and returns to the server;
step S3.7: the server side judges whether the abstract value HashData is equal to the PkgData, if so, the identity authentication of the client side passes, otherwise, the server side fails, and the request is discarded and the log is recorded;
step S3.8: after passing the verification, different responses are made according to the request type.
Step S4: the server constructs a file transmission HTTPS response message and sends the client;
specifically, in the step S4:
step S4.1: judging the request type, and responding differently according to the request type:
query class: adding json format query information into the body, and returning standard HTTPS response information;
uploading: writing body data into a local directory file, and returning standard HTTPS response information;
creation and deletion of classes: executing the corresponding file operation and then returning standard HTTPS response information;
download class: executing the step S4.2;
step S4.2: locally reading file Data to be downloaded, and generating an MD5 hash value MD5Data of the file Data;
step S4.3: base16 coding is carried out on the hash value MD5Data, and the coding value is filled into a custom header field DIGESET in a response header;
step S4.4: filling the file data into a response body and sending the file data to a client;
step S5: the client processes the file transfer response.
In the step S5:
step S5.1: receiving and analyzing the HTTPS response message, judging whether the response result is successful or not, exiting and recording a log if the response result is unsuccessful, and successfully executing the step S5.2;
step S5.2: judging the type of the response message, if the response message is the response message of file downloading, executing the step S5.3, otherwise, recording that the request is successful and ending;
step S5.3: acquiring a custom header field DIGESET value in the response header, and performing Base16 decoding on the DIGESET value to acquire data DigestData;
step S5.4: reading file Data FileData in a response body, and calculating MD5 hash value MD5Data of the FileData;
step S5.5: judging whether the DigestData value is equal to the MD5Data value, if so, downloading the file, if the integrity verification of the file is passed, and storing the file; otherwise, the verification fails.
Example 2:
example 2 is a preferable example of example 1 to more specifically explain the present invention.
The invention also provides a file secure transmission system based on the HTTPS protocol, which can be realized by executing the flow steps of the file secure transmission method based on the HTTPS protocol, namely, a person skilled in the art can understand the file secure transmission method based on the HTTPS protocol as a preferred implementation mode of the file secure transmission system based on the HTTPS protocol.
The invention provides a file secure transmission system based on an HTTPS protocol, which comprises:
module M1: enabling the server and the client to respectively carry out SM2 public and private key negotiation with the corresponding encryption machine clusters;
specifically, in the module M1:
module M1.1: the server and the server encryptor cluster A are deployed in the same intranet, and the client encryptor cluster B are deployed in the same intranet;
module M1.2: leading in working keys in the encryptor cluster A and the encryptor cluster B;
module M1.3: the server generates a session key and sends the session key to the encryptor cluster A, and the encryptor cluster A generates an SM2 public key and a SM2 private key according to the working key and the session key;
module M1.4: the server sends the session key to the client, and the client sends the session key to the encryptor cluster B, which generates the same SM2 public key and private key.
Module M2: the client encapsulates the custom field in the header of the HTTPS request header and sends the server;
specifically, in the module M2:
the client encapsulates the custom field with the identity information, the file information, the request information and the signature information in the header of the HTTPS request header and sends the custom field to the server;
module M2.1: the client acquires original data comprising a request line, a user code UserID, a system time stamp TimeStamp and a file storage path FilePath, and sends the preprocessed data SrcData to an encryptor cluster B;
module M2.2: the encryption machine cluster B calculates the HASH abstract value of the data SrcData according to an SM3 algorithm, encrypts the abstract value by using an SM2 private key to generate a digital signature PkgSign and returns the digital signature PkgSign to the client;
module M2.3: the client side performs Base64 coding on the digital Signature PkgSign, and encapsulates a Signature algorithm (increases algorithm expandability) in the generated data to obtain a Signature field value Signature;
module M2.4: adding custom header fields in the request header of HTTPS, including USER-ID field (filled with userID value), TIMESTAMP field (filled with TimeStamp value), FILE-PATH field (filled with FilePath value) and SIGNATURE field (filled with Signature value);
module M2.5: and adding file data in byte stream format in the HTTPS request body, and sending the packaged HTTPS request to the server.
Module M3: the server side is enabled to check the client side request and verify the identity legitimacy of the client side;
specifically, in the module M3:
module M3.1: after receiving HTTPS request, the server side analyzes the message to obtain request line and newly added header field in request header, including user code UserID, system time stamp TimeStamp, file storage path and digital Signature;
module M3.2: verifying whether a request method and UserID, timeStamp, filePath in the RequestLine are legal or not, if so, discarding the request and recording a log;
module M3.3: verifying the file signature, preprocessing the original data of RequestLine, userID, timeStamp and FilePath, and transmitting the preprocessed data SrcData to the encryptor cluster A;
module M3.4: the encryption machine cluster A calculates abstract HashData of SrcData according to an SM3 algorithm, and returns the value to the server;
module M3.5: the server side decodes the field Signature of the head of the request by Base64, acquires decoded data PkgSign and sends the decoded data to the encryptor cluster A;
module M3.6: decrypting the PkgSign by the encryptor cluster A according to the negotiated SM2 public key to obtain decrypted data PkgData and returning the decrypted data to the server;
module M3.7: enabling the server to judge whether the abstract value HashData is equal to the PkgData, if so, passing the identity authentication of the client, otherwise, failing, discarding the request and recording a log;
module M3.8: after passing the verification, different responses are made according to the request type.
Module M4: enabling the server to construct a file transmission HTTPS response message and send the client;
specifically, in the module M4:
module M4.1: judging the request type, and responding differently according to the request type:
query class: adding json format query information into the body, and returning standard HTTPS response information;
uploading: writing body data into a local directory file, and returning standard HTTPS response information;
creation and deletion of classes: executing the corresponding file operation and then returning standard HTTPS response information;
download class: an execution module M4.2;
module M4.2: locally reading file Data to be downloaded, and generating an MD5 hash value MD5Data of the file Data;
module M4.3: base16 coding is carried out on the hash value MD5Data, and the coding value is filled into a custom header field DIGESET in a response header;
module M4.4: filling the file data into a response body and sending the file data to a client;
module M5: causing the client to process the file transfer response.
In the module M5:
module M5.1: receiving and analyzing an HTTPS response message, judging whether the response result is successful or not, exiting and recording a log if the response result is unsuccessful, and executing the module M5.2 successfully;
module M5.2: judging the type of the response message, if the response message is the response message of file downloading, executing the module M5.3, otherwise, recording that the request is successful and ending;
module M5.3: acquiring a custom header field DIGESET value in the response header, and performing Base16 decoding on the DIGESET value to acquire data DigestData;
module M5.4: reading file Data FileData in a response body, and calculating MD5 hash value MD5Data of the FileData;
module M5.5: judging whether the DigestData value is equal to the MD5Data value, if so, downloading the file, if the integrity verification of the file is passed, and storing the file; otherwise, the verification fails.
Example 3:
example 3 is a preferable example of example 1 to more specifically explain the present invention.
Step 1, a server side encryptor cluster A and a client side encryptor cluster B carry out SM2 public and private key negotiation;
step 2, the client encapsulates the custom field with identity information, file information, request information and signature information in the HTTPS request header and sends the server;
step 3, the server performs verification and signature verification on the client request to verify the identity of the client;
step 4, the server constructs a file transmission HTTPS response message and sends the client;
and 5, the client processes the file transmission response.
The step 1 comprises the following steps:
step 1.1: the server and the encryptor cluster A are in the same intranet, and the client and the encryptor cluster B are in the same intranet (the system deployment refers to FIG. 3);
step 1.2: importing working keys into the encryptor cluster A and the encryptor cluster B;
step 1.3: the server generates a session key and sends the session key to the encryptor cluster A, and the encryptor cluster A generates an SM2 public key and a SM2 private key according to the working key and the session key;
step 1.4: the server sends the session key to the client, the client sends the session key to the encryptor cluster B, and the encryptor cluster B generates the same SM2 public key and private key;
step 1.5: and (5) ending.
The step 2 comprises the following steps (the flow is referred to as fig. 4):
step 2.1: the client acquires original data comprising a request line, a user code UserID, a system time stamp TimeStamp and a file storage path FilePath, and sends preprocessed data SrcData to an encryptor cluster B;
step 2.2: the encryptor cluster B calculates the HASH abstract value of SrcData according to an SM3 algorithm, encrypts the abstract value by using an SM2 private key to generate a digital signature PkgSign and returns the digital signature to the client;
step 2.3: the client performs Base64 coding on the digital Signature PkgSign, encapsulates a Signature algorithm (increases algorithm expandability) in the generated data, and obtains a final Signature field value Signature;
step 2.4: referring to FIG. 1, custom header fields are added to the request header of HTTPS, including a USER-ID field (filled with userID value), a TIMESTAMP field (filled with TimeStamp value), a FILE-PATH field (filled with FilePath value), and a SIGNATURE field (filled with Signature value);
step 2.5: and adding file data in byte stream format in the HTTPS request body, and sending the packaged HTTPS request to the server.
The step 3 comprises the following steps (the flow is referred to as fig. 5):
step 3.1: after receiving the HTTPS request, the server analyzes the message, and acquires the request line and a newly added header field in the request header, including user code UserID, a system TimeStamp TimeStamp, a file storage path FilePath and a digital Signature;
step 3.2: verifying whether a request method and UserID, timeStamp, filePath in the RequestLine are legal or not, if so, discarding the request and recording a log;
step 3.3: verifying the file signature, preprocessing the original data of RequestLine, userID, timeStamp and FilePath, and transmitting the preprocessed data SrcData to the encryptor cluster A;
step 3.4: the encryptor cluster A calculates the abstract HashData of SrcData according to the SM3 algorithm, and returns the value to the server;
step 3.5: the server side decodes the field Signature of the head of the request by Base64, acquires decoded data PkgSign and sends the decoded data to the encryptor cluster A;
step 3.6: the encryptor cluster A decrypts PkgSign according to the negotiated SM2 public key, acquires decrypted data PkgData and returns to the server;
step 3.7: the server side judges whether the abstract value HashData is equal to the PkgData, if so, the identity authentication of the client side passes, otherwise, the server side fails, and the request is discarded and the log is recorded;
step 3.8: after the verification is passed, different responses are made according to the request type (see step 4 for details), and the process is finished.
The step 4 comprises the following steps (the flow is referred to as fig. 6):
step 4.1: judging the request type, and making different responses according to the request type (query class: adding json format query information in a body, returning standard HTTPS response information; uploading class: writing body data into a local directory file, returning standard HTTPS response information; downloading class: executing step 4.2); creation and deletion of classes: executing the corresponding file operation and then returning standard HTTPS response information);
step 4.2: locally reading file Data to be downloaded, and generating an MD5 hash value MD5Data of the file Data;
step 4.3: base16 encoding the hash value MD5Data, and filling the encoded value into a custom header field DIGESET in a response header (refer to FIG. 2);
step 4.4: filling the file data into a response body and sending the file data to a client;
step 4.5: and (5) ending.
The step 5 comprises the following steps (the flow is referred to as fig. 7):
step 5.1: receiving and analyzing an HTTPS response message, judging whether the response result is successful or not, exiting and recording a log if the response result is unsuccessful, and successfully executing the step 5.2;
step 5.2: judging the type of the response message, if the response message is the response message of file downloading, executing the step 5.3, otherwise, recording that the request is successful and ending;
step 5.3: acquiring a custom header field DIGESET value in the response header, and performing Base16 decoding on the DIGESET value to acquire data DigestData;
step 5.4: reading file Data FileData in a response body, and calculating MD5 hash value MD5Data of the FileData;
step 5.5: judging whether the DigestData value is equal to the MD5Data value, if so, downloading the file, if the integrity verification of the file is passed, and storing the file; otherwise, the verification fails;
step 5.6: and (5) ending.
Those skilled in the art will appreciate that the systems, apparatus, and their respective modules provided herein may be implemented entirely by logic programming of method steps such that the systems, apparatus, and their respective modules are implemented as logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc., in addition to the systems, apparatus, and their respective modules being implemented as pure computer readable program code. Therefore, the system, the apparatus, and the respective modules thereof provided by the present invention may be regarded as one hardware component, and the modules included therein for implementing various programs may also be regarded as structures within the hardware component; modules for implementing various functions may also be regarded as being either software programs for implementing the methods or structures within hardware components.
The foregoing describes specific embodiments of the present invention. It is to be understood that the invention is not limited to the particular embodiments described above, and that various changes or modifications may be made by those skilled in the art within the scope of the appended claims without affecting the spirit of the invention. The embodiments of the present application and features in the embodiments may be combined with each other arbitrarily without conflict.
Claims (10)
1. The file secure transmission method based on the HTTPS protocol is characterized by comprising the following steps of:
step S1: the server and the client respectively carry out SM2 public-private key negotiation with the corresponding encryption machine clusters;
step S2: the client encapsulates the custom field in the HTTPS request header and sends the server;
step S3: the server side verifies the client side request and verifies the identity legitimacy of the client side;
step S4: the server constructs a file transmission HTTPS response message and sends the client;
step S5: the client processes the file transfer response.
2. The HTTPS protocol-based file secure transfer method according to claim 1, wherein in said step S1:
step S1.1: the server and the server encryptor cluster A are deployed in the same intranet, and the client encryptor cluster B are deployed in the same intranet;
step S1.2: importing working keys into the encryptor cluster A and the encryptor cluster B;
step S1.3: the server generates a session key and sends the session key to the encryptor cluster A, and the encryptor cluster A generates an SM2 public key and a SM2 private key according to the working key and the session key;
step S1.4: the server sends the session key to the client, the client sends the session key to the encryptor cluster B, and the encryptor cluster B generates the same SM2 public key and private key.
3. The HTTPS protocol-based file secure transfer method according to claim 1, wherein in said step S2:
the client encapsulates a custom field with identity information, file information, request information and signature information in the HTTPS request header and sends a server;
step S2.1: the client acquires original data comprising a request line, a user code UserID, a system time stamp TimeStamp and a file storage path FilePath, and sends preprocessed data SrcData to an encryptor cluster B;
step S2.2: the encryptor cluster B calculates the HASH abstract value of the data SrcData according to an SM3 algorithm, encrypts the abstract value by using an SM2 private key to generate a digital signature PkgSign and returns the digital signature PkgSign to the client;
step S2.3: the client performs Base64 coding on the digital Signature PkgSign, and encapsulates a Signature algorithm in the generated data to obtain a Signature field value Signature;
step S2.4: adding a custom header field in a request header of HTTPS, wherein the custom header field comprises a USER-ID field, a TIMESTAMP field, a FILE-PATH field and a SIGNATURE field;
step S2.5: and adding file data in byte stream format in the HTTPS request body, and sending the packaged HTTPS request to the server.
4. The HTTPS protocol-based file secure transfer method according to claim 1, wherein in said step S3:
step S3.1: after receiving the HTTPS request, the server analyzes the message, and acquires the request line and a newly added header field in the request header, including user code UserID, a system TimeStamp TimeStamp, a file storage path FilePath and a digital Signature;
step S3.2: verifying whether a request method and UserID, timeStamp, filePath in the RequestLine are legal or not, if so, discarding the request and recording a log;
step S3.3: verifying the file signature, preprocessing the original data of RequestLine, userID, timeStamp and FilePath, and transmitting the preprocessed data SrcData to the encryptor cluster A;
step S3.4: the encryptor cluster A calculates the abstract HashData of SrcData according to the SM3 algorithm, and returns the value to the server;
step S3.5: the server side decodes the field Signature of the head of the request by Base64, acquires decoded data PkgSign and sends the decoded data to the encryptor cluster A;
step S3.6: the encryptor cluster A decrypts PkgSign according to the negotiated SM2 public key, acquires decrypted data PkgData and returns to the server;
step S3.7: the server side judges whether the abstract value HashData is equal to the PkgData, if so, the identity authentication of the client side passes, otherwise, the server side fails, and the request is discarded and the log is recorded;
step S3.8: after passing the verification, different responses are made according to the request type.
5. The HTTPS protocol-based file secure transfer method of claim 1, wherein: in the step S4:
step S4.1: judging the request type, and responding differently according to the request type:
querying class: adding json format query information into the body of the request body, and returning standard HTTPS response information;
uploading: writing the body data of the request body into a local directory file, and returning standard HTTPS response information;
creation and deletion of classes: executing the corresponding file operation and then returning standard HTTPS response information;
download class: executing the step S4.2;
step S4.2: locally reading file Data to be downloaded, and generating an MD5 hash value MD5Data of the file Data;
step S4.3: base16 coding is carried out on the hash value MD5Data, and the coding value is filled into a custom header field DIGESET in a response header;
step S4.4: filling the file data into a response body and sending the file data to a client;
in the step S5:
step S5.1: receiving and analyzing the HTTPS response message, judging whether the response result is successful or not, exiting and recording a log if the response result is unsuccessful, and successfully executing the step S5.2;
step S5.2: judging the type of the response message, if the response message is the response message of file downloading, executing the step S5.3, otherwise, recording that the request is successful and ending;
step S5.3: acquiring a custom header field DIGESET value in the response header, and performing Base16 decoding on the DIGESET value to acquire data DigestData;
step S5.4: reading file Data FileData in a response body, and calculating MD5 hash value MD5Data of the FileData;
step S5.5: judging whether the DigestData value is equal to the MD5Data value, if so, downloading the file, if the integrity verification of the file is passed, and storing the file; otherwise, the verification fails.
6. A HTTPS protocol-based file secure transfer system comprising:
module M1: enabling the server and the client to respectively carry out SM2 public and private key negotiation with the corresponding encryption machine clusters;
module M2: the client encapsulates the custom field in the header of the HTTPS request header and sends the server;
module M3: the server side is enabled to check the client side request and verify the identity legitimacy of the client side;
module M4: enabling the server to construct a file transmission HTTPS response message and send the client;
module M5: causing the client to process the file transfer response.
7. The HTTPS protocol-based file secure transfer system of claim 6, wherein in said module M1:
module M1.1: the server and the server encryptor cluster A are deployed in the same intranet, and the client encryptor cluster B are deployed in the same intranet;
module M1.2: leading in working keys in the encryptor cluster A and the encryptor cluster B;
module M1.3: the server generates a session key and sends the session key to the encryptor cluster A, and the encryptor cluster A generates an SM2 public key and a SM2 private key according to the working key and the session key;
module M1.4: the server sends the session key to the client, and the client sends the session key to the encryptor cluster B, which generates the same SM2 public key and private key.
8. The HTTPS protocol-based file secure transfer system of claim 6, wherein in said module M2:
the client encapsulates the custom field with the identity information, the file information, the request information and the signature information in the header of the HTTPS request header and sends the custom field to the server;
module M2.1: the client acquires original data comprising a request line, a user code UserID, a system time stamp TimeStamp and a file storage path FilePath, and sends the preprocessed data SrcData to an encryptor cluster B;
module M2.2: the encryption machine cluster B calculates the HASH abstract value of the data SrcData according to an SM3 algorithm, encrypts the abstract value by using an SM2 private key to generate a digital signature PkgSign and returns the digital signature PkgSign to the client;
module M2.3: the client side performs Base64 coding on the digital Signature PkgSign, and encapsulates a Signature algorithm in the generated data to obtain a Signature field value Signature;
module M2.4: adding a custom header field in a request header of HTTPS, wherein the custom header field comprises a USER-ID field, a TIMESTAMP field, a FILE-PATH field and a SIGNATURE field;
module M2.5: and adding file data in byte stream format in the HTTPS request body, and sending the packaged HTTPS request to the server.
9. The HTTPS protocol-based file secure transfer system of claim 6, wherein in said module M3:
module M3.1: after receiving HTTPS request, the server side analyzes the message to obtain request line and newly added header field in request header, including user code UserID, system time stamp TimeStamp, file storage path and digital Signature;
module M3.2: verifying whether a request method and UserID, timeStamp, filePath in the RequestLine are legal or not, if so, discarding the request and recording a log;
module M3.3: verifying the file signature, preprocessing the original data of RequestLine, userID, timeStamp and FilePath, and transmitting the preprocessed data SrcData to the encryptor cluster A;
module M3.4: the encryption machine cluster A calculates abstract HashData of SrcData according to an SM3 algorithm, and returns the value to the server;
module M3.5: the server side decodes the field Signature of the head of the request by Base64, acquires decoded data PkgSign and sends the decoded data to the encryptor cluster A;
module M3.6: decrypting the PkgSign by the encryptor cluster A according to the negotiated SM2 public key to obtain decrypted data PkgData and returning the decrypted data to the server;
module M3.7: enabling the server to judge whether the abstract value HashData is equal to the PkgData, if so, passing the identity authentication of the client, otherwise, failing, discarding the request and recording a log;
module M3.8: after passing the verification, different responses are made according to the request type.
10. The HTTPS protocol-based file secure transfer system of claim 6, wherein: in the module M4:
module M4.1: judging the request type, and responding differently according to the request type:
query class: adding json format query information into the body of the request body, and returning standard HTTPS response information;
uploading: writing the body data of the request body into a local directory file, and returning standard HTTPS response information;
creation and deletion of classes: executing the corresponding file operation and then returning standard HTTPS response information;
download class: an execution module M4.2;
module M4.2: locally reading file Data to be downloaded, and generating an MD5 hash value MD5Data of the file Data;
module M4.3: base16 coding is carried out on the hash value MD5Data, and the coding value is filled into a custom header field DIGESET in a response header;
module M4.4: filling the file data into a response body and sending the file data to a client;
in the module M5:
module M5.1: receiving and analyzing an HTTPS response message, judging whether the response result is successful or not, exiting and recording a log if the response result is unsuccessful, and executing the module M5.2 successfully;
module M5.2: judging the type of the response message, if the response message is the response message of file downloading, executing the module M5.3, otherwise, recording that the request is successful and ending;
module M5.3: acquiring a custom header field DIGESET value in the response header, and performing Base16 decoding on the DIGESET value to acquire data DigestData;
module M5.4: reading file Data FileData in a response body, and calculating MD5 hash value MD5Data of the FileData;
module M5.5: judging whether the DigestData value is equal to the MD5Data value, if so, downloading the file, if the integrity verification of the file is passed, and storing the file; otherwise, the verification fails.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211510487.9A CN116074039A (en) | 2022-11-29 | 2022-11-29 | File secure transmission method and system based on HTTPS protocol |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211510487.9A CN116074039A (en) | 2022-11-29 | 2022-11-29 | File secure transmission method and system based on HTTPS protocol |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116074039A true CN116074039A (en) | 2023-05-05 |
Family
ID=86182905
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211510487.9A Pending CN116074039A (en) | 2022-11-29 | 2022-11-29 | File secure transmission method and system based on HTTPS protocol |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116074039A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117201043A (en) * | 2023-11-08 | 2023-12-08 | 北京中科网威信息技术有限公司 | File detection method and device and electronic equipment |
| CN117394987A (en) * | 2023-11-08 | 2024-01-12 | 广东知业科技有限公司 | Method and system for secure communication between edge computing and cloud service |
-
2022
- 2022-11-29 CN CN202211510487.9A patent/CN116074039A/en active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117201043A (en) * | 2023-11-08 | 2023-12-08 | 北京中科网威信息技术有限公司 | File detection method and device and electronic equipment |
| CN117394987A (en) * | 2023-11-08 | 2024-01-12 | 广东知业科技有限公司 | Method and system for secure communication between edge computing and cloud service |
| CN117201043B (en) * | 2023-11-08 | 2024-01-12 | 北京中科网威信息技术有限公司 | File detection method and device and electronic equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100581097C (en) | System and method for data transmission between two computers | |
| CN116074039A (en) | File secure transmission method and system based on HTTPS protocol | |
| CN111935712A (en) | Data transmission method, system and medium based on NB-IoT communication | |
| CN111884811B (en) | Block chain-based data evidence storing method and data evidence storing platform | |
| CN111181723B (en) | Method and device for offline security authentication between Internet of things devices | |
| CN113497778A (en) | Data transmission method and device | |
| CN112073467A (en) | Block chain-based data transmission method and device, storage medium and electronic equipment | |
| CN110958209A (en) | Bidirectional authentication method, system and terminal based on shared secret key | |
| CN115913672B (en) | Electronic file encryption transmission method, system, terminal equipment and computer medium | |
| CN112822228A (en) | Browser file encryption uploading method and system based on state cryptographic algorithm | |
| CN114338648A (en) | SFTP multi-terminal file secure transmission method and system based on state cryptographic algorithm | |
| TWI773161B (en) | Digital signature private key verification method | |
| CN114154181A (en) | Privacy calculation method based on distributed storage | |
| CN112583807A (en) | Verification method, verification device, electronic equipment and storage medium | |
| CN116743372A (en) | Quantum security protocol implementation method and system based on SSL protocol | |
| CN112804058A (en) | Conference data encryption and decryption method and device, storage medium and electronic equipment | |
| CN115412568A (en) | Distributed data transmission method, device and system | |
| CN114978769A (en) | Unidirectional lead-in device, method, medium, and apparatus | |
| CN112769783B (en) | Data transmission method, cloud server, receiving end and sending end | |
| CN112367329B (en) | Communication connection authentication method, device, computer equipment and storage medium | |
| CN115102768A (en) | Data processing method and device and computer equipment | |
| CN108235807B (en) | Software encryption terminal, payment terminal, software package encryption and decryption method and system | |
| CN110798431A (en) | Security parameter interaction method, device, equipment and system | |
| CN111130796B (en) | Secure online cloud storage method in instant messaging | |
| CN113872769B (en) | Device authentication method and device based on PUF, computer device and storage medium |
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 |