A secure FTP method, system, and apparatus based on elliptic curve and hash fusion

Abstract

The application relates to a secure FTP method, system and device based on an elliptic curve and hash fusion, and relates to the technical field of computer network security. The client and the server in FTP are two parties for transmitting files. The FTP method of the application comprises the following steps: the client and the server determine a session key corresponding to a current FTP session based on a current FTP session identifier for key negotiation; when transmitting a file, a sender performs block encryption on a to-be-transmitted file based on the session key to obtain a plurality of encrypted data blocks and constructs a corresponding hash chain, and the sender transmits the encrypted data blocks and the hash chain to a receiver; and the receiver decrypts the received encrypted data blocks based on the session key and the hash chain to obtain a transmission file. The application realizes efficient and secure transmission of a file on a resource-limited device by combining an encryption algorithm and a hash function, and effectively solves the problems of the existing FTP protocol in terms of security and performance on the resource-limited device.

Description

Technical Field

[0001] This invention relates to the field of computer network security technology, and in particular to a secure FTP method, system, and apparatus based on elliptic curve and hash fusion. Background Technology

[0002] With the continuous iteration and development of digital technologies, cybersecurity has become a critical challenge for businesses and individuals in today's digital age. The widespread application of emerging technologies such as cloud computing, big data, and the Internet of Things has led to an explosive growth in data transmission and storage. Cyberattack methods are constantly evolving, including data breaches, malware infections, and online fraud, which not only cause huge economic losses but may also threaten national security and social stability. Therefore, ensuring the security of data transmission is of paramount importance.

[0003] The traditional File Transfer Protocol (FTP) is one of the earliest standard protocols for file sharing on the Internet, widely used in various network environments, such as critical infrastructure like power and energy sectors. However, because its initial design focused primarily on file transfer efficiency, FTP suffers from serious security flaws. First, FTP uses plaintext transmission; usernames, passwords, and file contents are transmitted in plaintext over the network, making them vulnerable to interception and theft by man-in-the-middle attacks. Second, FTP lacks an effective data integrity verification mechanism, failing to ensure data integrity during transmission. Furthermore, while some improved FTP protocols, such as SFTP, provide encrypted transmission through SSH tunneling, they rely on traditional public-key encryption algorithms like RSA, resulting in high computational overhead. In critical infrastructure sectors like power and energy, resource constraints lead to poor performance, failing to meet the demands for efficient and secure file transfer in practical applications. Moreover, since the construction of power and energy infrastructure spans decades, any sweeping upgrades could have far-reaching consequences. Therefore, how to improve file transfer security while maintaining high performance under resource constraints in power and energy infrastructure is an urgent problem to solve. Summary of the Invention

[0004] Based on the above analysis, the present invention aims to disclose a secure FTP method, system, and apparatus based on the fusion of elliptic curve cryptography and hash functions. By combining elliptic curve cryptography and hash functions, it achieves efficient and secure file transfer on resource-constrained devices, effectively solving the problems of security and performance deficiencies of existing FTP protocols on resource-constrained devices.

[0005] On one hand, this invention provides a secure FTP method based on elliptic curve and hash fusion, where the client and server are the two parties involved in FTP file transfer. The FTP method specifically includes the following steps:

[0006] The client and server negotiate a key based on the current FTP session identifier to determine the session key corresponding to the current FTP session.

[0007] When transmitting a file, the sender uses the session key to encrypt the file to be transmitted into blocks to obtain multiple encrypted data blocks and constructs a corresponding hash chain. The sender then transmits the encrypted data blocks and hash chain to the receiver.

[0008] The receiver decrypts the received encrypted data block based on the session key and the hash chain to obtain the transmitted file.

[0009] Furthermore, the session key includes a master control key and a file key for the file to be transferred;

[0010] The client and server negotiate a key based on the current FTP session identifier to determine the session key corresponding to the current FTP session, including:

[0011] The server calculates the shared key based on the client's public key and the server's private key;

[0012] The server generates a master key based on the shared key and the current FTP session identifier; it generates a file key and a token based on the shared key, the current FTP session identifier, and the identifier of the FTP file to be transferred; and it encrypts the file key based on the shared key to obtain the encrypted file key.

[0013] The server sends the server public key, the encrypted file key, and the token to the client;

[0014] The client verifies the token based on the shared key, the current FTP session identifier, and the identifier of the FTP file to be transferred;

[0015] After successful token verification, the client calculates a shared key based on the client's private key and the server's public key; it then decrypts the encrypted file key using the shared key to obtain the file key, and calculates the master key based on the shared key and the current FTP session identifier.

[0016] Furthermore, the sender, based on the session key, performs block encryption on the file to be transmitted to obtain multiple encrypted data blocks and constructs corresponding hash chains, including:

[0017] The sender derives the data authentication key, data encryption key, initialization vector key, and hash chain key from the file key in the session key;

[0018] The sender divides the file to be transmitted into blocks, obtains a unique initial vector for each data block based on the initial vector key, and encrypts each data block based on the unique initial vector and the data encryption key to obtain the corresponding encrypted data block.

[0019] The sender calculates the hash value of each data block based on the data authentication key, and generates a forward hash chain and a backward hash chain based on the hash chain key and the hash value of each data block.

[0020] Furthermore, the process of transmitting the encrypted data block and hash chain from the sender to the receiver includes:

[0021] The sender transmits the sequence number, unique initialization vector, encrypted data block, forward hash chain, backward hash chain, and authentication tag corresponding to each data block to the receiver.

[0022] Furthermore, the process of transmitting the encrypted data block and hash chain from the sender to the receiver also includes:

[0023] The sender derives the breakpoint resume key based on the file key in the session key;

[0024] When a resumed download occurs, the client generates a resumed download session token based on the resumed download key, the current FTP session identifier, and the FTP file identifier of the resumed download.

[0025] The client sends the resume transmission session token and the sequence number of the last successfully transmitted encrypted data block to the server.

[0026] The server verifies the validity of the breakpoint resume session token. Once the verification is successful, the sender continues to transmit data blocks to the receiver based on the sequence number corresponding to the last successfully transmitted encrypted data block.

[0027] Furthermore, the recipient decrypts the received encrypted data block based on the session key and the hash chain to obtain the transmitted file, including:

[0028] The receiver derives the data authentication key, data encryption key, initialization vector key, and hash chain key from the file key in the session key;

[0029] The receiver decrypts each encrypted data block based on the data encryption key and initial vector key in the session key to obtain each data block;

[0030] The receiver calculates the hash value corresponding to each data block based on the data authentication key, and generates a forward hash chain and a backward hash chain based on the hash chain key and the hash value of each data block. The receiver then compares these forward hash chains and backward hash chains with the received forward hash chains to verify the integrity of the data.

[0031] The receiver obtains the transmitted file based on the verified data blocks.

[0032] Furthermore, the server calculates the shared key based on the client's public key and the server's private key, including:

[0033] The client generates a public-private key pair based on SM2 elliptic curves and sends the client's public key to the server;

[0034] The server generates a public-private key pair based on the same SM2 elliptic curve as the client.

[0035] The server generates a shared key based on the client's public key and the server's private key.

[0036] Furthermore, the data authentication key, data encryption key, hash chain key, initialization vector key, and breakpoint resume key are derived from the file key in the session key using the SM3 algorithm.

[0037] On the other hand, the present invention also provides a secure FTP system based on elliptic curve and hash fusion, including an FTP server and an FTP client.

[0038] The server and client are each equipped with a key management module, which is used to realize key negotiation between the client and the server. The key negotiation includes determining the session key corresponding to the current FTP session based on the current FTP session identifier.

[0039] File management modules are deployed on both the server and client sides for encrypting and decrypting files. The file management module deployed on the sender is used to encrypt the file to be transmitted in blocks based on the session key, obtaining multiple encrypted data blocks and constructing corresponding hash chains. During transmission, the sender transmits the encrypted data blocks and hash chains to the receiver. The file management module deployed on the receiver is used to decrypt the received encrypted data blocks based on the session key and the hash chain to obtain the transmitted file.

[0040] A user management module is deployed on the server to manage client users accessing the server;

[0041] An audit and monitoring module is deployed on the server to record the operation logs of the key management module, file management module, and user management module.

[0042] Furthermore, the present invention also provides a secure FTP device based on elliptic curve and hash fusion, including a memory and a processor:

[0043] Memory for storing all machine-readable instructions executable by the processor;

[0044] A processor, used to implement the secure FTP transfer method when executing machine-readable instructions.

[0045] The present invention can achieve at least one of the following beneficial effects:

[0046] By combining elliptic curve cryptography and hash functions, this invention achieves efficient key negotiation and data encryption during FTP transmission, effectively preventing data leakage and tampering. Simultaneously, a bidirectional hash chain technique is introduced to verify data integrity, ensuring the authenticity and reliability of data transmitted via FTP. The low computational complexity of the elliptic curve algorithm enables the method to run quickly and efficiently even on resource-constrained devices, improving the overall transmission efficiency and security of the FTP process.

[0047] By binding session keys to FTP session IDs and the attributes of the files being transferred, and supporting secure key recovery during resumeable downloads, the efficiency problem of renegotiation of keys after interruption in traditional FTP is solved. A timestamp- and HMAC-based authentication token mechanism effectively prevents replay attacks and man-in-the-middle attacks.

[0048] This invention achieves secure and efficient key negotiation through elliptic curve algorithms and ensures high-performance data transmission using symmetric encryption algorithms, making it particularly suitable for large file transfers in resource-constrained environments. It also supports multiple standard elliptic curves and has good compatibility.

[0049] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0050] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0051] Figure 1 This is a flowchart of the method of the present invention;

[0052] Figure 2 This describes the key negotiation process between the client and the server in this embodiment of the invention.

[0053] Figure 3 This refers to the key derivation relationship in an embodiment of the present invention;

[0054] Figure 4 This describes the encryption and decryption processes during file transmission in an embodiment of the present invention. Detailed Implementation

[0055] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0056] Method Implementation Examples

[0057] One embodiment of the present invention discloses a secure FTP method based on elliptic curve and hash fusion, in which the client and server are the two parties involved in FTP file transfer; that is, the client can act as the sender to transfer files to the server, which is the receiver; the client can also act as the receiver to receive files sent by the server. Figure 1 As shown, the specific steps include S1 to S3.

[0058] Step S1: The client and server perform key negotiation based on the current FTP session identifier to determine the session key corresponding to the current FTP session (the key negotiation process is as follows). Figure 2 (As shown). The session key includes the master control key and the file key for the file to be transferred. Step S1 is performed before file transfer and includes steps S11 to S16.

[0059] S11. The server calculates the shared key based on the client's public key and the server's private key. Specifically, this includes:

[0060] S11-1. The client generates a public-private key pair based on the SM2 elliptic curve and sends the client's public key to the server.

[0061] S11-2, The server generates a public-private key pair based on the same SM2 elliptic curve as the client;

[0062] S11-3. The server generates a shared key based on the client's public key and the server's private key.

[0063] Furthermore, in S11-1, before the client generates the client public-private key pair, the client first configures the elliptic curve to be used and determines the corresponding elliptic curve parameters.

[0064] Furthermore, the rules for selecting elliptic curve parameters include:

[0065] Elliptic curves employ Weierstrass equations over the prime field: ;

[0066] Elliptic curve parameters , , The selection must meet the following conditions:

[0067] 1. The curve is non-singular: ;

[0068] 2. The order n of the base point G is a large prime number, and n > 2^255;

[0069] 3. The curve embedding degree k is sufficiently large (k > 20) to avoid MOV attacks;

[0070] 4. Curve order #E(Fp) = h·n, where h is a small integer (usually h≤8), called the cofactor;

[0071] 5. p is a safe prime number, and p ≈ 2^m (m is the safety level, such as 256, 384).

[0072] 6. The choice of and b should avoid special structures to prevent specific attacks (such as Semaev summation polynomials attacks); among them, if the parameters (a, b, domain characteristics, group order, etc.) in the elliptic curve equation deviate from the security assumption of "complete randomness", thus allowing attackers to simplify ECDLP by using certain algebraic, geometric or number theory properties, it is called a special structure.

[0073] Preferably, the elliptic curve parameters should be verified through the following:

[0074] ①. Meet the conditions 1-6 above;

[0075] ②. The base point G does indeed lie on the curve: y_G² ≡ x_G³ + a·x_G + b (mod p);

[0076] ③. The base point order n satisfies n·G = O (point at infinity); where n is the number of points on the elliptic curve;

[0077] ④. Check for any known backdoors or vulnerabilities.

[0078] Specifically, when a = -3, the choice of b should satisfy:

[0079] (1) b is a random number in the p domain, and b ≠ 0;

[0080] (2) The binary representation of b should have a high Hamming weight (approximately p / 2 bits).

[0081] (3) The value of b is not a special pattern (special patterns include all 0s, all 1s, repeating patterns, etc.).

[0082] Furthermore, in one embodiment of the present invention, the selected parameters are as follows:

[0083] a = -3;

[0084] b= 5FBFF498AA938CE739B8E022FBAFEF40563F6E6A3472FC2A5

[0085] 4C0DE9AEAA81M1;

[0086] p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFFFFFFFFFD;

[0087] The order n is the number of points on the elliptic curve;

[0088] Base point , is a specific point on the elliptic curve.

[0089] Furthermore, in S11-1, when the client generates the client public-private key pair, it randomly selects an integer. As the client's private key, where 1 < <n。

[0090] Furthermore, the client calculates its public key using the dot product operation of the elliptic curve. = .here It refers to the client's public key, ClientPub. It refers to the client's private key, ClientPri.

[0091] The client sends its public key, ClientPub, to the server via the FTP control channel.

[0092] Furthermore, in step S11-2, after receiving the client's public key, the server selects the same elliptic curve and randomly selects an integer. As the server's private key ServerPri, it satisfies 1 < < n; the server calculates based on elliptic curves. = ServerPub serves as the server's public key.

[0093] Furthermore, in step S11-3, the server generates a shared key K based on the client's public key and the server's private key using the SM2 algorithm:

[0094] K = × = × ( × G) = ( × ) × G.

[0095] S12. The server generates a master control key based on the shared key and the current FTP session identifier; it generates a file key and a token based on the shared key, the current FTP session identifier, and the identifier of the FTP file to be transferred, and encrypts the file key based on the shared key to obtain the encrypted file key.

[0096] Specifically, the server generates the master key SK_main based on the shared key and the current FTP session identifier. The generation process is as follows:

[0097] SK_main = KDF_SM3(K || FTP_Session_ID || timestamp, 32);

[0098] Wherein, KDF_SM3 is the key derivation function based on SM3, FTP_Session_ID is the current FTP session identifier, timestamp is the timestamp with a precision of milliseconds; 32 indicates that the generated master key is 32 bytes long.

[0099] Furthermore, the server derives the control command encryption key based on the master control key, the process of which is as follows:

[0100] SK'_CONTROL = KDF_SM3(SK_main, "control-enc", 32);

[0101] Here, "control-enc" is the tag, and 32 indicates the key length of 32 bytes.

[0102] SK'_CONTROL is used to encrypt FTP control commands in the control channel. The encryption process is as follows:

[0103] CMD'=SM4_GCM_Encrypt(SK'_CONTROL,FTP_Session_ID || CMD || timestamp );

[0104] In this context, SM4_GCM_Encryp represents the Chinese national cryptographic SM4 algorithm, CMD is the FTP control command, and CMD' is the ciphertext of the control command.

[0105] Specifically, the server generates a file key based on the shared key, the current FTP session identifier, and the identifier of the FTP file to be transferred. The generation process is as follows:

[0106] SK_file = KDF_SM3(K || FTP_Session_ID || File_ID || File_Size || timestamp, 32);

[0107] Where File_ID is the identifier of the FTP file to be transferred, and File_Size is the file size.

[0108] Furthermore, the server uses the shared key K and the file key to perform SM4-GCM encryption to obtain the encrypted file key C_SK. IV = Random(12) is defined as a 12-byte random initialization vector. The generation process of the encrypted file key C_SK is as follows:

[0109] C_SK = SM4_GCM_Encrypt(K, IV, SK_file, Additional_Data);

[0110] The Additional Authentication Data includes FTP_Session_ID and File_ID.

[0111] Specifically, the server generates a token based on the shared key, the current FTP session identifier, and the identifier of the FTP file to be transferred.

[0112] token = HMAC-SM3(K, FTP_Session_ID || File_ID || timestamp).

[0113] S13. The server sends the server public key, the encrypted file key, and the token to the client.

[0114] Specifically, the server will use its public key ServerPub, i.e., Q. s The encrypted file key C_SK, initialization vector IV, timestamp, and token are sent to the client.

[0115] S14. The client verifies the token based on the shared key, the current FTP session identifier, and the identifier of the FTP file to be transferred.

[0116] Specifically, when the client receives the server public key ClientPub, the encrypted file key C_SK, the initialization vector IV, the timestamp, and the token sent by the server, it first verifies the validity of the timestamp, that is, checks whether the difference between the timestamp and the client's current time is within a preset threshold. If the difference exceeds the threshold, the key negotiation process is terminated.

[0117] Furthermore, the client calculates token'== HMAC-SM3(K', FTP_Session_ID || File_ID || timestamp) based on the shared key, the current FTP session identifier, and the identifier of the FTP file to be transferred;

[0118] Verify that the token' is the same as the received token. If it is the same, the verification is successful; otherwise, terminate the key negotiation process.

[0119] S15. After the token verification is successful, the client calculates a shared key based on the client's private key and the server's public key; decrypts the encrypted file key based on the shared key to obtain the file key; and calculates the master key based on the shared key and the current FTP session identifier.

[0120] Specifically, the client calculates the shared key K' based on the client's private key and the server's public key. The calculation process is as follows:

[0121] K' = SM2_ECDH(ClientPri, ServerPub),

[0122] That is, K' = × = × ( × G) = ( × ) × G=K.

[0123] Furthermore, the file key is obtained by decrypting the encrypted file key C_SK based on the shared key K', i.e., K:

[0124] SK_file = SM4_GCM_Decrypt(K', C_SK, IV, Additional_Data);

[0125] The master key is calculated based on the shared key K' (K), the current FTP session identifier, and the received timestamp:

[0126] SK_main' = KDF_SM3(K' || FTP_Session_ID || timestamp, 32).

[0127] Furthermore, the client derives the control command encryption key based on the master key, the process of which is as follows:

[0128] SK'_CONTROL = KDF_SM3(SK_main', "control-enc", 32).

[0129] The client encrypts the command based on the control command encryption key and sends it to the server through the FTP control channel. The encryption process is the same as the encryption process for encrypting the FTP control command described in step S12.

[0130] At this point, the key negotiation process between the server and the client is complete, and the session key corresponding to the current FTP session is determined, including the master key SK_main and the file key SK_file for the file to be transferred.

[0131] Step S2: When transmitting a file, the sender uses the session key to encrypt the file to be transmitted in blocks to obtain multiple encrypted data blocks and constructs a corresponding hash chain. The sender then transmits the encrypted data blocks and hash chain to the receiver.

[0132] It should be noted that both the FTP client and server can act as senders and receivers when transferring files. Furthermore, before file transfer, the client and server exchange control commands via the FTP control channel to initiate the transfer. Specifically, the command sender (usually the client) encrypts the command using a control command encryption key derived from the master key, and the command receiver (usually the server) decrypts the command using the same encryption key. The decryption process is as follows:

[0133] CMD=SM4_GCM_Decrypt(SK′_CONTROL, IV, CMD′, FTP_Session_ID ∥timestamp), where IV is generated by the command sender (or agreed upon by both parties) and sent to the command receiver along with CMD′.

[0134] Furthermore, before transmitting the file, the sender uses a hash function to calculate the hash value of the file to be transmitted and sends it to the receiver as an initial commitment.

[0135] Furthermore, when transferring files, step S2 specifically includes S21 to S24.

[0136] S21. The sender derives the data authentication key, data encryption key, initialization vector key, and hash chain key (e.g., based on the file key in the session key) from the file key. Figure 3 (This is a diagram illustrating the key derivation relationship.)

[0137] Specifically, it is derived from the file key:

[0138] Data authentication key SK'_AUTH = KDF_SM3(SK_file, "data-auth", 32);

[0139] Data encryption key SK'_KEY = KDF_SM3(SK_file, "data-enc", 32);

[0140] Initialization vector key SK'_IV = KDF_SM3(SK_file, "iv-gen", 12);

[0141] The hash chain key SK'_CHAIN ​​= KDF_SM3(SK_file, "hash-chain", 32);

[0142] Among them, "data-auth", "data-enc", "iv-gen", and "hash-chain" are the corresponding tag parameters used to distinguish keys for different purposes and ensure key isolation.

[0143] S22. The sender divides the file to be transmitted into blocks, obtains a unique initial vector for each data block based on the initial vector key, and encrypts each data block based on the unique initial vector and the data encryption key to obtain the corresponding encrypted data block.

[0144] Specifically, the client pre-sets an appropriate block size S based on the file type, size, and system processing capabilities, such as 1MB or 4KB.

[0145] Furthermore, starting from the beginning of the file, the file data is divided sequentially according to the block size S, resulting in multiple data blocks. ... Where n is the total number of blocks, the calculation formula is: L represents the total number of bytes in the file.

[0146] Furthermore, each data block is encrypted separately based on the data encryption key:

[0147] ;

[0148] Where i is the data block number; Represents a data block; Let i be the initial vector corresponding to data block i; This is additional information corresponding to data block i.

[0149] Specifically, a unique initial vector is obtained for each data block based on its sequence number and initial vector key.

[0150] ;

[0151] in, is the index number of data block i.

[0152] S23. The sender calculates the hash value of each data block based on the data authentication key, and generates a forward hash chain and a backward hash chain based on the hash chain key and the hash value of each data block.

[0153] Specifically, the hash value of each data block The calculation process is as follows:

[0154] ;

[0155] in, Meta-information of the data block (such as size, sequence number, timestamp, etc.).

[0156] Furthermore, a forward hash chain is generated based on the hash chain key and the hash values ​​of each data block. and backward hash chain :

[0157] ;

[0158] ;

[0159] in The initial seed, where This is the final seed.

[0160] S24. The sender transmits the encrypted data block and hash chain to the receiver.

[0161] Specifically, the sender transmits the sequence number, unique initialization vector, encrypted data block, forward hash chain, backward hash chain, and authentication tag corresponding to each data block to the receiver.

[0162] The structure of the transmitted data is as follows:

[0163] { | Encrypted data | Forward Hash Back hash | Authentication Tag};

[0164] The authentication tag is the hash value corresponding to each data block. .

[0165] Furthermore, step S2 also includes step S25.

[0166] Step S25: When a breakpoint resumes, the client and server verify the breakpoint resume command session token and execute the breakpoint resume after successful verification.

[0167] Specifically, step S25 includes:

[0168] The client derives the breakpoint resume key based on the file key in the session key;

[0169] When a resumed download occurs, the client generates a resumed download session token based on the resumed download key, the current FTP session identifier, and the FTP file identifier of the resumed download.

[0170] The client sends the resume transmission session token and the sequence number of the last successfully transmitted encrypted data block to the server.

[0171] The server verifies the validity of the breakpoint resume session token. Once the verification is successful, the sender continues to transmit data blocks to the receiver based on the sequence number corresponding to the last successfully transmitted encrypted data block.

[0172] The process of generating the breakpoint resume key is as follows:

[0173] SK'_RESUME = KDF_SM3(SK_file, "resume", 32).

[0174] Wherein, KDF_SM3 is the key derivation function based on SM3, FTP_Session_ID is the current FTP session identifier, "resume" is the label; 32 indicates that the generated master key is 32 bytes long.

[0175] The process of generating the breakpoint resume session token is as follows:

[0176] Session_Token = HMAC-SHA256(SK'_RESUME, FTP_Session_ID || File_ID ||timestamp);

[0177] HMAC-SHA256 is a hash-based message authentication code-secure hash algorithm, a security mechanism used to verify message integrity and authenticity. It combines a hash function (SHA-256) and a key to generate a short, fixed-length value.

[0178] The server verifies the validity of the breakpoint resume session token by including:

[0179] The server derives a breakpoint resume key based on the file transfer key;

[0180] Generate Session_Token based on the breakpoint resume key, the current FTP session identifier, and the FTP file identifier for breakpoint resume.

[0181] Compare Session_Token' with Session_Token. If they are the same, the verification is successful; otherwise, the verification fails.

[0182] Step S3: The receiver decrypts the received encrypted data block based on the session key determined by key negotiation and the hash chain to obtain the transmission file.

[0183] Step S3 specifically includes S31 to S34.

[0184] S31. The receiver derives the data authentication key SK'_AUTH, the data encryption key SK'_KEY, the initialization vector key SK'_IV, and the hash chain key SK'_CHAIN ​​from the file key in the session key determined by key negotiation.

[0185] The specific process is the same as step S21, and will not be repeated here.

[0186] S32. The receiver decrypts each encrypted data block based on the data encryption key SK'_KEY and the initial vector key SK'_IV in the session key to obtain each data block and the corresponding authentication tag.

[0187] Specifically, the receiver obtains the unique initialization vector corresponding to each data block based on the initialization vector key SK'_IV. :

[0188] ;

[0189] The receiver decrypts the received encrypted data block based on the unique initialization vector and the data encryption key. : ;

[0190] in, It is the original data block obtained after decryption; Use the data encryption key; It is a unique initial vector; This is additional information corresponding to data block i, used to verify the integrity of the data during decryption.

[0191] S33. The receiver calculates the hash value corresponding to each data block based on the data authentication key, and generates a forward hash chain and a backward hash chain based on the hash chain key and the hash value of each data block. The receiver compares the forward hash chain and the backward hash chain with the received forward hash chain to verify the integrity of the data.

[0192] Specifically, the receiver calculates the hash value corresponding to each data block based on the data authentication key SK'_AUTH. The specific process is the same as step S23:

[0193] .

[0194] And then, along with the authentication tag obtained from decryption, which is the hash value corresponding to each data block, the authentication tag is obtained. The data is compared; if the labels match, the data has not been tampered with; otherwise, the data block is discarded.

[0195] Furthermore, if the tags match, a forward hash chain is generated based on the hash chain key and the hash values ​​of each data block. and backward hash chain :

[0196] ;

[0197] ;

[0198] and the received forward hash chain Backward hash chain To verify the integrity of the data, such as... Figure 4 This diagram illustrates the encryption and decryption of data during file transfer.

[0199] It should be noted that the forward hash chain and backward hash chain generated based on the hash chain key and the hash value of each data block are compared with the received forward hash chain and backward hash chain to verify the integrity of the data. That is, the integrity of the data is verified by using a bidirectional hash chain, which ensures that the integrity of the data is effectively verified even in the case of non-continuous transmission such as interrupted transmission.

[0200] S34. The receiver obtains the transmitted file based on the verified data blocks.

[0201] Specifically, the receiver assembles the verified data blocks into a complete file in sequence, and verifies that the final seed of the last data block is consistent with the initial commitment described in step S2. If the result is that the complete file has not been tampered with, the transmission is successful; otherwise, the file transmission fails and the complete file is discarded.

[0202] This embodiment combines elliptic curve cryptography and hash functions to achieve efficient key negotiation and data encryption during FTP transmission, effectively preventing data leakage and tampering. Simultaneously, a bidirectional hash chain technique is introduced to verify data integrity, ensuring the authenticity and reliability of data transmitted via FTP. The low computational complexity of the elliptic curve algorithm enables the method to run quickly and efficiently even on resource-constrained devices, improving the overall transmission efficiency and security of the FTP transmission process.

[0203] By binding session keys to FTP session IDs and the attributes of the files being transferred, and supporting secure key recovery during resumeable downloads, the efficiency problem of renegotiation of keys after interruption in traditional FTP is solved. A timestamp- and HMAC-based authentication token mechanism effectively prevents replay attacks and man-in-the-middle attacks.

[0204] This invention achieves secure and efficient key negotiation through elliptic curve algorithms and ensures high-performance data transmission using symmetric encryption algorithms, making it particularly suitable for large file transfers in resource-constrained environments. It also supports multiple standard elliptic curves and has good compatibility.

[0205] System Implementation Examples

[0206] Another specific embodiment of the present invention discloses a secure FTP system based on elliptic curve and hash fusion, including an FTP server and an FTP client, wherein:

[0207] The server and client are each equipped with a key management module, which is used to realize key negotiation between the client and the server. The key negotiation includes determining the session key corresponding to the current FTP session based on the current FTP session identifier.

[0208] File management modules are deployed on both the server and client sides for encrypting and decrypting files. The file management module deployed on the sender is used to encrypt the file to be transmitted in blocks based on the session key, obtaining multiple encrypted data blocks and constructing corresponding hash chains. During transmission, the sender transmits the encrypted data blocks and hash chains to the receiver. The file management module deployed on the receiver is used to decrypt the received encrypted data blocks based on the session key and the hash chain to obtain the transmitted file.

[0209] A user management module is deployed on the server to manage client users accessing the server;

[0210] An audit and monitoring module is deployed on the server to record the operation logs of the key management module, file management module, and user management module.

[0211] This embodiment discloses a secure FTP system based on elliptic curve and hash fusion, which can be applied to scenarios where power and energy infrastructure resources are limited, improving the security of file transfer while maintaining high-performance transmission.

[0212] Device Examples

[0213] This embodiment discloses a secure FTP device based on elliptic curve and hash fusion, the device including a memory and a processor:

[0214] Memory for storing all machine-readable instructions executable by the processor;

[0215] A processor, configured to implement the secure FTP method described in the method embodiments when executing machine-readable instructions.

[0216] Compared to existing technologies, this embodiment provides a secure FTP device based on elliptic curve and hash fusion. The beneficial effects provided by the device and the method and system embodiments are basically the same, and will not be described in detail here.

[0217] It should be noted that the above embodiments are based on the same inventive concept, and any parts not described repeatedly can be referenced from each other.

[0218] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A secure FTP method based on elliptic curve and hash fusion, the client and server are two parties for FTP transmission file, characterized in that, The method comprises the following steps: The client and the server determine the session key corresponding to the current FTP session based on the current FTP session identification through key negotiation, comprising: the server calculates a shared key based on the client public key and the server private key; the server generates a master key based on the shared key and the current FTP session identification; the server generates a file key and a token based on the shared key, the current FTP session identification and the FTP file identification to be transmitted, and encrypts the file key based on the shared key to obtain an encrypted file key; the server sends the server public key, the encrypted file key and the token to the client; the client verifies the token based on the shared key, the current FTP session identification and the FTP file identification to be transmitted; after the token is verified, the client calculates the shared key based on the client private key and the server public key; the client decrypts the encrypted file key based on the shared key to obtain the file key, and calculates the master key based on the shared key and the current FTP session identification; the session key comprises the master key and the file key of the file to be transmitted; When transmitting the file, the sender encrypts the file to be transmitted based on the session key to obtain a plurality of encrypted data blocks and constructs a corresponding hash chain, and transmits the encrypted data blocks and the hash chain to the receiver; the sender encrypts the file to be transmitted based on the session key to obtain a plurality of encrypted data blocks and construct a corresponding hash chain, comprising: the sender derives a data authentication key, a data encryption key, an initial vector key and a hash chain key based on the file key in the session key; the sender divides the file to be transmitted into blocks, obtains a unique initial vector corresponding to each data block based on the initial vector key, and encrypts each data block based on the unique initial vector and the data encryption key to obtain a corresponding encrypted data block; the sender calculates the hash value of each data block based on the data authentication key, and generates a forward hash chain and a backward hash chain based on the hash chain key and the hash value of each data block; the sender transmits the serial number, the unique initial vector, the encrypted data block, the forward hash chain, the backward hash chain and the authentication tag corresponding to each data block to the receiver; the sender derives a breakpoint resume key based on the file key in the session key; when breakpoint resume occurs, the client generates a breakpoint resume session token based on the breakpoint resume key, the current FTP session identification and the FTP file identification for breakpoint resume; the client sends the breakpoint resume session token and the serial number corresponding to the last successfully transmitted encrypted data block to the server; the server verifies the validity of the breakpoint resume session token, and after verification, the sender continues to transmit the data block to the receiver based on the serial number corresponding to the last successfully transmitted encrypted data block; The receiver decrypts the received encrypted data blocks based on the session key and the hash chain to obtain the transmission file.

2. The secure FTP method of claim 1, wherein, The receiver decrypts the received encrypted data blocks based on the session key and the hash chain to obtain the transmission file, comprising: The receiver derives a data authentication key, a data encryption key, an initial vector key, and a hash chain key based on a file key in the session key; The receiver decrypts each encrypted data block based on the data encryption key and the initial vector key in the session key to obtain each data block; The receiver calculates a hash value corresponding to each data block based on the data authentication key, and generates a forward hash chain and a backward hash chain based on the hash chain key and the hash values of the data blocks, and compares the generated forward hash chain and backward hash chain with received forward hash chain and backward hash chain to verify the integrity of the data; The receiver obtains the transmission file based on the data blocks that pass the verification.

3. The secure FTP method of claim 2, wherein, The server calculates a shared key based on the client public key and the server private key, including: The client generates a client public-private key pair based on an SM2 elliptic curve, and sends the client public key to the server; The server generates a server public-private key pair based on the same SM2 elliptic curve as the client; The server generates a shared key based on the client public key and the server private key.

4. The secure FTP method of claim 3, wherein, The SM3 algorithm is used to derive a data authentication key, a data encryption key, a hash chain key, an initial vector key, and a breakpoint resume key based on the file key in the session key.

5. A secure FTP system based on elliptic curve and hash fusion, comprising an FTP server and an FTP client, characterized in that, The server and the client each have a key management module deployed thereon, which is used to implement key negotiation between the client and the server, and the key negotiation includes key negotiation based on a current FTP session identifier to determine a session key corresponding to the current FTP session, including: the server calculates a shared key based on the client public key and the server private key; the server generates a master key based on the shared key and the current FTP session identifier; the server generates a file key and a token based on the shared key, the current FTP session identifier, and an FTP file identifier to be transmitted, and encrypts the file key based on the shared key to obtain an encrypted file key; the server sends the server public key, the encrypted file key, and the token to the client; the client verifies the token based on the shared key, the current FTP session identifier, and the FTP file identifier to be transmitted; the client calculates a shared key based on the client private key and the server public key after the token verification passes; the client decrypts the encrypted file key based on the shared key to obtain the file key, and calculates a master key based on the shared key and the current FTP session identifier; the session key includes the master key and the file key of the file to be transmitted. A file management module is deployed on the server and the client respectively for encrypting and decrypting files; the file management module deployed on the sender is used to encrypt a file to be transmitted based on the session key to obtain a plurality of encrypted data blocks and construct a corresponding hash chain; when transmitting, the sender transmits the encrypted data blocks and the hash chain to the receiver; the file management module deployed on the receiver is used to decrypt the received encrypted data blocks based on the session key and the hash chain to obtain the transmitted file; the process of encrypting the file to be transmitted based on the session key to obtain a plurality of encrypted data blocks and construct a corresponding hash chain includes: the sender derives a data authentication key, a data encryption key, an initial vector key and a hash chain key based on a file key in the session key; the sender divides the file to be transmitted into blocks, obtains a unique initial vector corresponding to each data block based on the initial vector key, and encrypts each data block based on the unique initial vector and the data encryption key to obtain a corresponding encrypted data block; the sender calculates the hash value of each data block based on the data authentication key, and generates a forward hash chain and a backward hash chain based on the hash chain key and the hash value of each data block; the process of transmitting the encrypted data blocks and the hash chain to the receiver by the sender includes: the sender transmits the serial number, the unique initial vector, the encrypted data block, the forward hash chain, the backward hash chain and the authentication tag corresponding to each data block to the receiver; the sender derives a breakpoint resume key based on the file key in the session key; when breakpoint resume occurs, the client generates a breakpoint resume session token based on the breakpoint resume key, a current FTP session identifier and an FTP file identifier for breakpoint resume; the client sends the breakpoint resume session token and the serial number corresponding to the last successfully transmitted encrypted data block to the server; the server verifies the validity of the breakpoint resume session token, and after verification, the sender continues to transmit data blocks to the receiver based on the serial number corresponding to the last successfully transmitted encrypted data block. A user management module is deployed on the server for managing client users accessing the server. An audit monitoring module is deployed on the server for recording operation logs of the key management module, the file management module and the user management module.

6. A secure FTP device based on elliptic curve and hash fusion, characterized by, The device includes a memory and a processor: The memory is used to store machine readable instructions executable by the processor; The processor is used to execute the machine readable instructions to implement the secure FTP method according to any one of claims 1-4.

Images