Introduction
LZ recently took a job in the company, to publish some services to the company's partners call. This kind of work LZ is described as pro, which has done countless service ends before. But unlike in the past, the service is posted on the Internet, so it can no longer be the same as the previous routine. The previous system interactions are between the corporate intranet, so there is no data security issue.
This time we had to consider the security of the data, so LZ recently began to study a variety of cryptographic algorithms bitter. Before and after a total of three days, LZ finally the encryption layer is done, although the LZ on the principle of various cryptographic algorithms are not known, but should also be enough. After all, LZ does not intend to make an absolutely secure system (in fact it is not possible), as long as it can prevent 90% of hackers.
Programme Development
At the beginning, the first thing to do is to make a plan, and the Application layer protocol uses HTTP, which is certain. For encryption, LZ want to go, basically there are two options.
The first is the traditional approach, the use of self-signed certificates, borrowed from the JDK and Web container SSL layer implementation, this method is more commonly used, but also more convenient.
The second is a manual programming approach, similar to writing a layer of SSL implementations. The principle is also very simple, the other side of the data encrypted to the LZ service side, LZ side after the decryption of how to deal with, after the end of the response to the data encryption to the client, the client after the decryption of how to deal with how to deal with.
After some experimentation and thought, LZ decided to adopt the second method. The main reason is that this approach is more flexible, the encryption scheme is the LZ can be arbitrarily changed (for example, one of the algorithms with another algorithm to replace). Another reason is that the things you write more easily control, if the encryption layer problems, LZ as PM can quickly locate the problem. The last reason is that it's easier to create clients in a variety of languages based on algorithms rather than Java class libraries.
Code Design
The plan is basically OK, and then the code is designed. Code design is divided into the client and the server side, as the client, LZ can provide a common cryptographic decryption component to the partner calls (such as Java Client, PHP client,. NET client, and so on). As a service side, the LZ only needs filters and custom views to complete the encryption and decryption work easily.
The client API is eventually written as follows:
Httpshelper.sendjsonandgetjson (Jsonobject JSON);
Httpshelper.sendjsonandgetjson (jsonobject json,int timeout);
The above is the client component announced two methods, the role of the method is very good understanding, LZ will not say much. In the implementation of the method, the LZ has helped the client to complete the encryption and decryption operations. Of course, the premise of using this client is to get the LZ grant authorization code.
The server needs a filter and a custom JSON view.
Securityfilter
Jsonview
Because LZ publishes restful-style services, the MVC framework used is spring MVC. The specific code for these two classes is not posted here, in short, the filter completes the request parameter decryption, the view completes the response result of the encryption.
SSL Layer Implementation
The above basically has completed the entire cryptographic decryption function design, the next task is to implement the implementation, in the end the encryption algorithm how to choose?
Before the LZ on the encryption and decryption algorithm is big small white, we know a MD5 algorithm, generally used for password encryption. This can be stumped LZ, but it doesn't matter, there are Baidu and Google, what can not be learned in a few days of things.
After some Baidu and Google,lz discovery algorithms are mainly divided into the following three kinds:
1, irreversible encryption algorithm, such as MD5 is such a, this algorithm is generally used for verification, such as verifying the user's password is correct.
2, symmetric encryption algorithm, the algorithm is reversible, both sides have the same key, using this key can encrypt and decrypt data, generally used for data encryption transmission. The feature is fast, but the security is lower relative to asymmetric encryption.
3, asymmetric encryption algorithm, the algorithm is still reversible, with different keys on both sides, a public key, called the private key, both sides can also encrypt and decrypt data, generally used for digital signature. The feature is slower, but the security is higher with respect to symmetric encryption.
Before LZ heard that the implementation of SSL is a mixture of several algorithms, which gives the LZ a great revelation. Since each algorithm has its advantages, why don't we mix it up?
So, LZ want to go (mainly on the bus and the toilet thinking), decided to use MD5 (irreversible encryption) +des (symmetric encryption) +rsa (asymmetric Encryption) encryption method, the encoding format can use BASE64. Look at the LZ demand, there are two main points.
1, the client needs LZ authorization, that is, LZ release service is not who want to tune.
2, the data is encrypted in the transmission process, and the security is equal to the security of the asymmetric encryption algorithm, but the performance is equal to the speed of symmetric encryption.
Let's take a look at the above algorithm implementation can meet the needs, the process is this.
1, assume that the LZ gives the client an authorization code, such as 123456. Then assume that the data that the client needs to pass now is {"name": "Xiaolongzuo"}. (both the request data and the response data are in JSON format)
2, the client needs to encrypt the 123456 MD5 first and then put it into the transfer data. That is, the transmitted data becomes {"name": "Xiaolongzuo", "Verifycode": "MD5 (123456)"}
3, the client generates a random key for DES (note that the symmetric key is randomly generated each time), assuming that the abcdef, the client uses the key to transmit DES encryption to the transmitted data, and RSA encryption of the random key, and eventually into a JSON. That is, the final transmission of the data will become {"Privatekey": "RSA (ABCDEF)", "Data": "Des ({" Name ":" Xiaolongzuo "," Verifycode ":" MD5 (123456) "})"}
4, the service side uses the opposite process to decrypt the data, and verifies that the decrypted authorization code MD5 (123456) exists and that the client is not authorized if it does not exist. When the server returns data, DES encryption of the data is still used abcdef.
Security Analysis : If the above data is intercepted by hackers, then the most important thing hackers do is to crack the RSA algorithm's private key (the private key only LZ has, the client component will be accompanied by the public key), this problem is relatively difficult to hear, specifically why, this is not the LZ need to consider, LZ has not this ability. Based on this premise, the LZ can be considered to transmit the data is still relatively safe.
Performance Analysis : Since our RSA encrypts only the shorter des private keys, the slow nature of asymmetric encryption does not affect us too much. Almost all of the transmitted data, we are using des for encryption, so at a speed of almost equal to the speed of symmetric encryption.
Summary
Because the source code is the company all, so LZ here inconvenient paste out, but the whole idea here has been elaborated very clear.
through this simple study, it is not difficult to find that with the purpose of learning is the most efficient learning. Imagine, if the LZ is just idle to do nothing, look at the encryption algorithm, I believe it will not be in such a short period of time to understand, and learn some basic methods of use. So it turns out that the best way to learn any knowledge is to use that knowledge to do something.
One-time SSL manual implementation--simple sweep of encryption algorithm