Financial Industry Key system introduction (transfer)

Financial Industry Key system introduction (transfer) financial industry because of the sensitive data, so data encryption also pay attention. There are very few articles on key and encryption, which are distributed in the hands of banks and companies. There are no articles on this part on the Internet. This article gives a more in-depth introduction to the financial industry's keys, including what is a master key, a transmission key, and why we need them. This article adopts the method of tracing back-to-source, and strives to let those who are interested know what they are, and at the same time know what they are, rather than vaguely knowing several concepts and terms. This article is intended for those who are not very familiar with the key system in the financial industry. If you are familiar with the key, you do not have to read it carefully. Okay, let's say it's just plain. We know that a lot of data in the financial industry needs to be transmitted over the network, from the front-end to the host, from the self-help terminal to the front-end, etc. The data is uploaded over the network, we can easily think of security issues. If the data is stolen or intercepted, how can we save money in the bank. This problem was taken into consideration by our predecessors when the computer emerged, so many different encryption and decryption Technologies emerged. Let alone this. Let's assume that we designed ourselves to solve the problem of data theft. Suppose we have a piece of data, which is the ATM withdrawal message, including a person's magnetic card number, password, and withdrawal amount. Now we need to transfer the data from an ATM machine to the front-end machine for processing, the data is confidential. If the data is stolen, you can use the card number and password to remove the money from your account. First, we can think of using a dedicated internal bank network, and people outside of the bank cannot access the network. It is obviously not feasible to think about this, because first, it cannot ensure that outsiders cannot access the internal network of the Bank, and second, it is impossible for bank personnel to commit crimes. Next, we can easily think that, since it is very unlikely that the data will not be stolen, why don't we change our thinking and the data cannot be stolen? If I process the data, even if you steal data, it is useless garbled code. Isn't the problem solved. This idea is close to the current practice. When the front-end machine receives the data, it must be a reverse processing of the data, that is, it can obtain the plaintext data after the data is processed in the opposite way as the ATM side. Let's further think about the situation where, for some reason, the withdrawal amount in the message is changed, which will lead to the inconsistency between the money from the ATM and the money recorded in the pre-deduction, it seems that we must add a verification mechanism. When the front-end machine receives a packet sent by the ATM, it can confirm that the data in the packet has not been changed during network transmission. How to implement it? In the simplest way, like serial communication on a computer, the system returns 0 or 1 for each bit of communication data and places 0 or 1 behind the communication data, when a parity bit is added, each of the received data is equal to or equal to 0 or 1, and then the last bit of the received data is consistent with the calculated value. This method is too simple. It is of no use for the packets from the ATM to the front-end server mentioned above, however, we can change the algorithm for every bit of data into a complex one. Because the DES algorithm has been out for many years and has been widely used in the financial industry, why not use the DES algorithm to solve the above problems. We should understand the DES algorithm (here referred to as single des), that is, to process 64-bit data with a 64-bit (8-byte) Key to obtain the encrypted 64-bit data. Then we use a key to carry out the DES algorithm on the preceding message to obtain the encrypted 64-bit data, put it at the end of the message, and send it together with the message to the front-end machine. After receiving the message, the front-end Machine, similarly, the key is used to decrypt the data (excluding the last 64-bit encrypted data) to obtain 64-bit data. The data is compared with the last 64-bit data of the packets sent from the ATM, if the two data items are the same, the packets have not been changed in the middle. Furthermore, because des can only encrypt 64-bit data and a packet can be more than 64-bit, what should we do? Only 64bit encryption starting with the packet? This is obviously not enough. In this way, we can first encrypt the packet with 64bit, then encrypt the second 64bit of the packet, and so on. However, this is a problem, because each 64bit will get encrypted data of the same length, I cannot put the data behind the packet, and the length of the packet will not be doubled. In another way, we first encrypt the first 64-bit packet, get the 64-bit encrypted data data1, then take the encrypted data1 and the second 64-bit packet for bitwise OR, get 64-Bit Data data2 with the same length. I use the key to encrypt data2, get the encrypted data data3, and then use the data of data3 and the third 64-bit data of the packet for bitwise OR, and so on. In the end, a 64bit data will be obtained, and the data will be placed at the end of the packet and sent to the front-end server. In this way, the length of the packet will only increase by 64bit. This algorithm is called the MAC Algorithm. (Now you know how the Mac domain in pos came from ?!) Now we know what Mac algorithm is and why it is needed. Let's look at another term that is often mentioned. When talking about the Mac algorithm, we will notice that a key is mentioned in the DES encryption algorithm. The key used for Mac computing is often called Mackey, there are also work keys and process keys. We continue to handle the problem of network data transmission between the ATM and the frontend. The MAC Algorithm mentioned above processes the transmitted packets, ensuring that data is not tampered with intentionally or unintentionally during network transmission, if it is still a withdrawal message mentioned above, I will not change the content of the message if I want to commit a crime. I only intercept the content of the message because the content contains the card number and password, they are all in plain text. It is easy to see which content is the card number and what content is the password. With the card number and password, I can easily do it. Find a card reader to quickly create a magnetic card, and then I can get the money with this card. I don't need to modify the message, in this way, even if the front-end server passes the Mac verification of the packets, it only ensures that the packets have not been changed and does not provide substantial help to prevent committing crimes. It is easy to think that I have added an encryption. This time, I used des to encrypt the entire deposit message, converted all the plain text into a ciphertext, and then sent it to the front-end server. Even if you intercept a message, it is useless. You do not have the des key to decrypt it. Only the front-end server knows the key. This is a good idea. It does prevent the risk of card numbers and passwords being known. This is also a common practice, but we need to make some improvements to this practice. First, we need to know that it takes time to encrypt and decrypt data with DES, especially when hard encryption is used (What is hard encryption next. Let's think about it. Is it necessary for the entire deposit message to encrypt each data, such as the serial number and ATM number in the message, which makes no sense for them to encrypt them, it doesn't make sense to encrypt the withdrawal amount. If you get 500 yuan, but you change the number of messages to 100, the host only deducts 100 yuan from your account, and you earn 400 yuan in white. This may sound quite cost-effective, but it is actually not feasible, because it will lead to a short account, the bank will certainly check the account, according to the number of hardware records recorded by the ATM and the host fee deduction amount, I will certainly find out what you have discovered. It is obvious that no one is so stupid. Let's consider what information in a message needs to be encrypted. Currently, the general practice is to encrypt only the account and password (or only the password, if other content is not encrypted, the plain text will be in plain text, which is no big deal. There is a term for account and password encryption. We may have heard of pinblock, a pin block, which is a ciphertext data block after DES encryption for accounts and passwords. Since the DES algorithm is used to encrypt accounts and passwords, there must be a key for encryption, so we will call this key Pinkey, which is the key specifically used to encrypt accounts and passwords. As for how to encrypt and form the final ciphertext pinblock, there are many standards, such as ibm3624, ANSI, ISO, Diebold and other standards. In fact, they are similar in that they are used to pre-process the passwords in packets, using Pinkey for DES encryption, the main difference is how to pre-process it. For example, some passwords are supplemented with F and 16 bits are supplemented, which is similar to this preprocessing. Here we should understand Pinkey and pinblock. Pinkey and Mackey are used to re-process the packets. Basically, the report is secure. If we know more about the DES algorithm, we will know that if we want to decrypt the encrypted ciphertext, we must know the key, so the key must be kept confidential. How to keep the key confidential? As we mentioned above, both Mac and pin block are calculated directly using the plaintext key, so this key is easily stolen, for example, if someone installs a hacker program on the machine and detects that you are using the key to encrypt data, the plaintext key is obtained. This sounds quite mysterious, but it is possible, especially for online banking. In this case, we need to encrypt the Pinkey and Mackey itself, so don't let people know. How to Implement the DES algorithm is also a good example. I will find another key to encrypt the Pinkey and Mackey, so that you will not see the plaintext OF THE Pinkey and Mackey. In this case, the key used to encrypt Pinkey and Mackey is called the masterkey, that is, the master key, which is used to encrypt the keys of other keys. However, please wait. What should I do with the masterkey? It's plain text. Find another key to encrypt the masterkey. No matter how many lines are processed, the final key must be in plain text. In this case, the security problem has not yet been solved. Since this cannot be done, we need to change our mindset. Think carefully about how to deal with the masterkey in plain text. Hackers can only steal what is on my software. If I put the masterkey in the hardware, hackers are not able to get the masterkey from my hardware. Of course, it is not ruled out that at least 99.9% of hackers are incapable of doing this. So we can solve the problem. Just put the masterkey in the hardware (usually in the keyboard encryption module. Well, at this point, we are not afraid of someone getting the key information in the message, and it is finally safe. Recently, some people have mentioned "hard encryption". What is the purpose of this? Didn't I solve the encryption problem above? What should I do with this concept? It seems that I still haven't considered it in some places. I keep thinking about how to encrypt a plaintext password into a password. In this case, you need to consider how the plaintext password is formed. Isn't it formed by pressing the number on the keyboard. In the past, my software was like this. Every time I press the keyboard, I will save the number in the program. After the four or six passwords are pressed, then they are combined and sent to the Pinkey for encryption. If the hacker program directly obtains the key information, then he does not need to crack the password encrypted with Pinkey in the message, and simply obtains the password I entered, I tried my best to encrypt the password, which makes no sense at all. What should I do? If I solidify the program for obtaining keys into the encrypted hardware (usually on the keyboard), the keys do not pass through the software on the upper layer and are directly processed in the hardware, after the buttons are pressed, the hardware directly sends the processed key information to the upper-layer software. At this time, it is ciphertext, which is equivalent to moving the processing of the previous pinblock calculation to the hardware, then the hacker cannot get my buttons. This kind of processing is now called hard encryption. With EMV and 3DES algorithms, it becomes increasingly popular. It seems that self-help terminals do not support hard encryption, and even EMV is mandatory. Based on this idea of hard encryption, the emergence of an encryption device called a encryptor has emerged. A encryptor is a hardware device with key management functions. In the current financial transaction platform, all keys except the top-level keys exist in the form of ciphertext, and the top-level keys are often managed in segments, it is impossible for a person to know all the top-level keys, which are often stored in the encryptor. This ensures the high security of the entire key system. Recently, it is often mentioned that 3DES is a term. Why should we propose the 3DES concept? I mentioned the specific 3 DES algorithm in an article. In fact, 3DES is introduced because the original single DES algorithm is likely to be cracked as the speed of computer hardware increases, therefore, the algorithm is improved to 3DES. But for our understanding of the key and encryption mechanisms in the financial industry, all algorithms are the same. The difference between different algorithms is simply how to shift and transform data. For the consideration of ATM transaction security, the system uses pin encryption and Mac verification to ensure the legitimacy and integrity of the system transaction data. The Pin block is generated and the pin encryption is implemented, mac verification can be performed on the encrypted ATM keyboard. 1. work key (WK) PIN key: encrypted transmission of the cardholder's password (TPK, zpk, PVK) 2.mac key: used for transaction message identification, ensure data integrity (Tak, Zak) 3.com key: used for communication encryption/decryption (Tek, Zek) of transaction packets 4. key Exchange key (KEK) Zone master key: zmk 5. terminal master key: Used to exchange work keys (TMK) between hosts and financial terminals 6. local Master Key: used to encrypt and store keys of other key systems is the key to ensure the transaction security of the entire system. Level 3 key management system: lmk (local master key) top-level key, used to encrypt TMK, zmk TMK (terminal Master Key), zmk (regional master key) exchange key, used to encrypt pin key, Mac key, com key work key, mac key, com key pin key is used to encrypt the password, Mac key is used to verify the message, and COM key is used for communication encryption