Symmetric and asymmetric encryption. Parsing encrypted data transfer between servers
If there are two machines and it is required to send the data in an encrypted form to one or the other side - a library in php, written by me a few months ago and finished last night - that is what I would like to share.
Let us agree that the machine that transmits encrypted data is always Machine A, and the machine that receives them has the symbol B.
The library solves two possible cases (if necessary, I will add functionality):
')
1) The case when there is a car (B) that needs data from machine A (for example, it needs to get the customer's name) and this data must be obtained safely. Those. The initiator of the transfer is machine B.
2) The case when there is a machine and it needs to transfer encrypted data to another machine (B). In this case, the initiator of the transfer is the first machine (A).
The library implements both options, for each of which there is a demo:
For the first case in the server_b_1 folder there is a script testGetDataFromA.php
For the second case in the server_a_1 folder there is a script testPushDataToB.php
The library for both cases is the same Encode.php, but for the first case some additional scripts are required, for the second case others, therefore, in order to avoid confusion, I have spread them functionally to the server_a_1 and server_b_1 folders (perhaps subsequent versions of the library will have a different structure). Thus, if both machines need to implement both the first transfer case and the second one, each such machine will have both folders.
Now about how both solutions are implemented:
The essence of both cases comes down to the fact that the machines exchange a symmetric key for transmitting the cipher text. For this exchange, asymmetric encryption is used, namely, one of the machines (X) generates a pair of keys (public and private) and transfers the public key to the second machine. The second machine generates a symmetric key with this public key and returns it to the first one, which decrypts it with its private key. The difference lies in the fact who is the initiator of the transfer - in case if the cipher text needs to receive one sequence of actions, if to transfer - another. The considered library also does additional checks that boil down to the fact that along with the symmetric key encrypted using a public key, data is transmitted that only both machines know and which can be changed once a year (or even transmitted in each transaction if anyone wants to play with code).
Before starting the implementation, I’ll point out that the symmetric key is encrypted using the Mcrypt php encryption functions as follows:
Work with asymmetric encryption occurs using php OpenSSL
So:
I will consider first the simplified diagrams of both the transmission cases indicated at the very beginning, and then in more detail.
1) The case when there is a car (B) that needs data from machine A (for example, it needs to get the customer's name) and this data must be obtained safely. Those. The initiator of the transfer is machine B.
A simplified algorithm for such a transfer is as follows:
Machine B generates a pair of keys (private and public) and makes a request to machine A, sending the public key (leaving the private key). Machine A generates a symmetric key, encrypts the secret information N required for transmission. After that, machine A returns a symmetric key encrypted with a public key, as well as secret information encrypted with a symmetric key N. Machine B decrypts the data with its private key. In the decrypted data, it receives a symmetric key and the data it encrypts. Using a symmetric key, it decrypts sensitive data.
There is no guarantee that machine A is our car, not Anatoly FSB. Therefore, the implementation of this algorithm by the library has been slightly modified by an additional check:
(Demo script - server_b_1 / testGetDataFromA.php)
On both machines, the secret key SIGNATURE_KEY is registered, which participates in the additional verification. Machine B generates a pair of keys (private and public), the key of the current connection and makes a request (http: //.../server_a_1/getDataToB.php) on machine A, sending the key of the current connection and the public key (leaving private). Machine A generates a symmetric key, encrypts the secret information N required for transmission. Also, additional data M is generated, which are md5 from the line containing SIGNATURE_KEY and the key of the current connection. After that, machine A returns a string encrypted with a public key from a symmetric key and additional data M, as well as secret information encrypted with a symmetric key N. Machine B decrypts the data with a symmetric key with its private key, generates a string with subjects M (since it can calculate md5 from the string containing SIGNATURE_KEY and the current connection key). If the additional data matches (which is just an additional check for each transaction, that machine A knows SIGNATURE_KEY, and therefore our machine), machine B extracts the symmetric key with which it decrypts secret information N.
2) The case when there is a machine and it needs to transfer encrypted data to another machine (B). In this case, the initiator of the transfer is the first machine (A).
A simplified algorithm for such a transfer is as follows:
Before transferring to machine B, machine A needs the public key of machine B to transfer information. To do this, it (machine A) first makes a request to obtain a public key to machine B. After receiving, machine A generates a symmetric key, encrypts the required information with it, and encrypts all of this with the received public key. The data is transmitted to the machine B, which decrypts the packet with its private key and a symmetric key decrypts the data.
There is no guarantee that we received the public key from machine B, and not from FSB-Schnick Petrov. Therefore, the implementation of this algorithm by the library is slightly modified by additional checks:
(Demo script - server_a_1 / testPushDataToB.php)
Both machines have a secret key SIGNATURE_KEY, which is involved in the additional verification. Machine A, generating md5 from the key of the current connection and SIGNATURE_KEY sends this data (along with the unencrypted key of the current connection) to machine B (http: //.../server_b_1/get_public_key.php), which generates the public key only if it turns out same md5 from its SIGNATURE_KEY and the received key of the current connection. This does not resolve the issue that the public key will be received from machine A, and not from FSB schnick Vasily, but guarantees machine B that it generates the public key for machine A (although the generation of the public key is generally arbitrary, but even here it is better to be safe). Together with the public key, md5 from SIGNATURE_KEY and the second key of the current connection are generated. The second key of the current connection is an arbitrary hash. The data of the public key, the second key of an arbitrary connection and the specified md5 are returned to machine A. After receiving the second key of an arbitrary connection, machine A, knowing SIGNATURE_KEY, generates a verification md5 and if it matches what the machine received - the public key is considered to be from machine B, and not from Basil.
Further, machine A (here the scheme is similar to the first case of data transfer) generates a symmetric key and an additional check, which is md5 from SIGNATURE_KEY and the key of the current connection. This data is encrypted with the public key from machine B. Then, the data along with the current connection key is sent to machine B (http: //.../server_b_1/pushDataFromA.php), which generates the current connection key and SIGNATURE_KEY md5 from this data , verifies with the received, which gives a guarantee that the data are not from the FSB-Schnick Nicholas. If everything is in order and the check is passed, a symmetric key is extracted using the private key, which is used to decrypt the message.
I would be glad if this information is useful to someone.
→ Code on the gita (ibid demo)
Let us agree that the machine that transmits encrypted data is always Machine A, and the machine that receives them has the symbol B.
The library solves two possible cases (if necessary, I will add functionality):
')
1) The case when there is a car (B) that needs data from machine A (for example, it needs to get the customer's name) and this data must be obtained safely. Those. The initiator of the transfer is machine B.
2) The case when there is a machine and it needs to transfer encrypted data to another machine (B). In this case, the initiator of the transfer is the first machine (A).
The library implements both options, for each of which there is a demo:
For the first case in the server_b_1 folder there is a script testGetDataFromA.php
For the second case in the server_a_1 folder there is a script testPushDataToB.php
The library for both cases is the same Encode.php, but for the first case some additional scripts are required, for the second case others, therefore, in order to avoid confusion, I have spread them functionally to the server_a_1 and server_b_1 folders (perhaps subsequent versions of the library will have a different structure). Thus, if both machines need to implement both the first transfer case and the second one, each such machine will have both folders.
Now about how both solutions are implemented:
The essence of both cases comes down to the fact that the machines exchange a symmetric key for transmitting the cipher text. For this exchange, asymmetric encryption is used, namely, one of the machines (X) generates a pair of keys (public and private) and transfers the public key to the second machine. The second machine generates a symmetric key with this public key and returns it to the first one, which decrypts it with its private key. The difference lies in the fact who is the initiator of the transfer - in case if the cipher text needs to receive one sequence of actions, if to transfer - another. The considered library also does additional checks that boil down to the fact that along with the symmetric key encrypted using a public key, data is transmitted that only both machines know and which can be changed once a year (or even transmitted in each transaction if anyone wants to play with code).
Before starting the implementation, I’ll point out that the symmetric key is encrypted using the Mcrypt php encryption functions as follows:
$encrypted_data = urlencode(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $sinc_key, $notice_text, MCRYPT_MODE_ECB))); $test_decrypted = trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256,$sinc_key, base64_decode(urldecode($encrypted_data)),MCRYPT_MODE_ECB)); Work with asymmetric encryption occurs using php OpenSSL
So:
I will consider first the simplified diagrams of both the transmission cases indicated at the very beginning, and then in more detail.
1) The case when there is a car (B) that needs data from machine A (for example, it needs to get the customer's name) and this data must be obtained safely. Those. The initiator of the transfer is machine B.
A simplified algorithm for such a transfer is as follows:
Machine B generates a pair of keys (private and public) and makes a request to machine A, sending the public key (leaving the private key). Machine A generates a symmetric key, encrypts the secret information N required for transmission. After that, machine A returns a symmetric key encrypted with a public key, as well as secret information encrypted with a symmetric key N. Machine B decrypts the data with its private key. In the decrypted data, it receives a symmetric key and the data it encrypts. Using a symmetric key, it decrypts sensitive data.
There is no guarantee that machine A is our car, not Anatoly FSB. Therefore, the implementation of this algorithm by the library has been slightly modified by an additional check:
(Demo script - server_b_1 / testGetDataFromA.php)
On both machines, the secret key SIGNATURE_KEY is registered, which participates in the additional verification. Machine B generates a pair of keys (private and public), the key of the current connection and makes a request (http: //.../server_a_1/getDataToB.php) on machine A, sending the key of the current connection and the public key (leaving private). Machine A generates a symmetric key, encrypts the secret information N required for transmission. Also, additional data M is generated, which are md5 from the line containing SIGNATURE_KEY and the key of the current connection. After that, machine A returns a string encrypted with a public key from a symmetric key and additional data M, as well as secret information encrypted with a symmetric key N. Machine B decrypts the data with a symmetric key with its private key, generates a string with subjects M (since it can calculate md5 from the string containing SIGNATURE_KEY and the current connection key). If the additional data matches (which is just an additional check for each transaction, that machine A knows SIGNATURE_KEY, and therefore our machine), machine B extracts the symmetric key with which it decrypts secret information N.
2) The case when there is a machine and it needs to transfer encrypted data to another machine (B). In this case, the initiator of the transfer is the first machine (A).
A simplified algorithm for such a transfer is as follows:
Before transferring to machine B, machine A needs the public key of machine B to transfer information. To do this, it (machine A) first makes a request to obtain a public key to machine B. After receiving, machine A generates a symmetric key, encrypts the required information with it, and encrypts all of this with the received public key. The data is transmitted to the machine B, which decrypts the packet with its private key and a symmetric key decrypts the data.
There is no guarantee that we received the public key from machine B, and not from FSB-Schnick Petrov. Therefore, the implementation of this algorithm by the library is slightly modified by additional checks:
(Demo script - server_a_1 / testPushDataToB.php)
Both machines have a secret key SIGNATURE_KEY, which is involved in the additional verification. Machine A, generating md5 from the key of the current connection and SIGNATURE_KEY sends this data (along with the unencrypted key of the current connection) to machine B (http: //.../server_b_1/get_public_key.php), which generates the public key only if it turns out same md5 from its SIGNATURE_KEY and the received key of the current connection. This does not resolve the issue that the public key will be received from machine A, and not from FSB schnick Vasily, but guarantees machine B that it generates the public key for machine A (although the generation of the public key is generally arbitrary, but even here it is better to be safe). Together with the public key, md5 from SIGNATURE_KEY and the second key of the current connection are generated. The second key of the current connection is an arbitrary hash. The data of the public key, the second key of an arbitrary connection and the specified md5 are returned to machine A. After receiving the second key of an arbitrary connection, machine A, knowing SIGNATURE_KEY, generates a verification md5 and if it matches what the machine received - the public key is considered to be from machine B, and not from Basil.
Further, machine A (here the scheme is similar to the first case of data transfer) generates a symmetric key and an additional check, which is md5 from SIGNATURE_KEY and the key of the current connection. This data is encrypted with the public key from machine B. Then, the data along with the current connection key is sent to machine B (http: //.../server_b_1/pushDataFromA.php), which generates the current connection key and SIGNATURE_KEY md5 from this data , verifies with the received, which gives a guarantee that the data are not from the FSB-Schnick Nicholas. If everything is in order and the check is passed, a symmetric key is extracted using the private key, which is used to decrypt the message.
I would be glad if this information is useful to someone.
→ Code on the gita (ibid demo)
Source: https://habr.com/ru/post/330792/
All Articles