Open API Security Considerations

Very elementary simple idea, first of all to write down.

There needs to be a young, smart young talent to argue:

1, whether to use HTTPS, these will not be necessary.

2, rigorous: whether there are loopholes, so that security depends on which elements, to what extent to ensure.

3, Necessity: whether there are redundant links.

4, Performance: pressure, pay attention to monitor the CPU.

The following is the text.

One, management 1, all the keys are generated and issued by us.
2. We need to store:
(1) Our own private key, public key.
(2) Other people's public key.
(3) Correspondence between all public keys and entities (e.g., an organization, someone in an organization, ourselves, etc.).
3. The issued private key is passed to the other party by a secure method (U disk copy?). ）。 Protect the privacy of your partner's public key and mapping relationships to the fullest.
Second, the process

1. Identity authentication process:

(1) Do not need the account, password God horse.

(2) Request initiation Process:

The user's number in our system is set to UUID.

Step 1, the other side to generate a seed, set to seed, you need to ensure that seed random .

Step 2, encrypted with our public key, has the result set to TOKEN1.

Step 3, with the user's own private key encryption, the result is set to Token2.

Users send Uuid,seed,token1 and token2 to us.

(3) Verification process:

Step 1: Use your private key to decrypt token1 and get seed.

Step 2: Obtain the public key via the UUID, decrypt the token2 with this public key, and get seed.

Step 3: Is the same as the seed obtained for step 1 and step 2. If the same, the transfer succeeds.

Step 4: After verification succeeds, the token is encrypted with the user's public key and sent to the user. Our server holds tokens for 20 minutes.

2. Send data to us

(1) Sending process:

Data is set.

Step 1: Use our public key to encrypt data, get ciphertext C1 (need to verify the efficiency).

Step 2: Milvensen into a digital digest, set to Z1.

Step 3: Encrypt the digest with the user's own private key, and get the ciphertext Z2.

Step 4: Encrypt the C2 and tokens with our public key and get the ciphertext C3.

Step 5: Send C1 and C3 to us.

(2) Receiving process:

Step 1: Decrypt the data, Z2, and tokens with our own private key.

Step 2: Get the user's public key through token, Z2 decryption get Z1.

Step 3: Generate a digital digest of data, set to Z1 '.

Step 4: Compare Z1 ' and Z1, if same, accept data.

3. Feedback data to each other:

BlaBla

Appendix: Literacy

(The following content is transferred from the Internet, the original link ... Err... Close the web ... ）

The public and private keys are commonly known as asymmetric encryption, which is improved from the previous symmetric encryption (using user name and password). Explain the principle in e-mail.
The purpose of using public and private keys is to implement secure e-mail, which must be accomplished as follows:
1. The content I send to you must be encrypted and cannot be seen by others during the transmission of the message.
2. Must ensure that I sent the mail, not someone impersonating me.
To achieve such a goal, both people who must send the message have a public and private key.
Public key, is for everyone to use, you can be published by e-mail, can be downloaded through the website, the public key is actually used to encrypt/stamp use. The private key, is his own, must be very careful to save, preferably with a password, the private key is used to decrypt/seal, first of all the key ownership, the private key only personal ownership. The function of public key and private key is: the content encrypted with public key can only be decrypted with private key, and the content encrypted with private key can only be decrypted with public key.
For example, I want to send you an encrypted message. First, I have to have your public key, and you have to have my public key.
First of all, I use your public key to encrypt this message, so that the message is not seen by others, and ensure that the message is not modified during the transfer process. After you receive the email, you can decrypt it with your private key and you can see the content.
Second, I use my private key to encrypt this message, sent to your hand, you can use my public key decryption. Because the private key is only in my hand, this ensures that this email is sent to me.
When A->b data, a will use B's public key encryption, so as to ensure that only B can unlock, otherwise the general public can unlock the encrypted message, is to the confidentiality of information. Verification is the use of the mechanism of the signing of the seal, A transmission of information to everyone, will be the signature of their own private key, so that all the people who receive the message can use a's public key for verification, you can confirm that the message was sent by a.

Open API Security Considerations