Public key system/Digital Signature/Digital Certificate Working Principle

Encryption and decryption use the same key algorithm, called symmetric encryption algorithm. encryption and decryption use different keys, called asymmetric encryption algorithms. The public key system is an asymmetric encryption algorithm. For symmetric encryption, symmetric keys must be protected. For public key algorithms, private keys must be protected.
Public key encryption algorithms and derived digital signatures and digital certificates are widely used in Internet communication, such as SSL/TLS in HTTPS protocol, for example, the Windows XP device driver ,.. Net GAC Assembly requires a digital signature. Microsoft has provided cryptograph APIs since Windows 98/NT4, supporting symmetric encryption algorithms such as des, RC2, RC4, and idea, asymmetric encryption algorithms such as RSA public key systems, and MD5, Sha, digest algorithms such as MAC (Digest, also known as hash and hash.
Translated from:
Http://developer.netscape.com/tech/security/ssl/howitworks.html
This is a vivid and simple article, which is helpful for understanding the working principle of the public key system. csdn has an article:
Http://www.csdn.net/Develop/article/27/27524.shtm
However, I believe that the above key points are not accurate enough and are not fluent. On the basis of the previous translation, the key terms use the general translation method. In a few cases, free translation is used and the original English text is included. If there is any improper translation, you can compare the original text.
I hope that my friends who are interested in the public key system will be helpful.
BTW: the encryption and decryption algorithms of all symmetric and asymmetric encryption mentioned above are public. If you do not know the key, the algorithm designer is confident that the encryption results will not be easily cracked, this is quite different from WAPI :).
The following are Chinese and English translations:
Public key encryption is a technique that uses a pair of asypolicric keys for encryption and decryption. each pair of keys consists of a public key and a private key. the Public Key is made public by distributing it widely. the private key is never distributed; it is always kept secret.
Public key encryption uses an asymmetric key encryption or decryption technique. Each key pair consists of a public key and a private key. Public Keys are widely released. The private key is private and not public.
Data that is encrypted with the public key can be decrypted only with the private key. conversely, data encrypted with the private key can be decrypted only with the public key. this asypolicry is the property that makes public key cryptography so useful.
Data Encrypted with the public key can only be decrypted by the private key. In turn, data encrypted with the private key can only be decrypted with the public key. This asymmetric feature makes public key encryption very useful.
Using public key cryptography for authentication
Use public key encryption for authentication
Authentication is the process of verifying identity so that one entity can be sure that another entity is who it claims to be. in the following example involving Alice and Bob, public key cryptography is easily used to verify identity. the notation {something} key means that something has been encrypted or decrypted using key.
Authentication is an identity verification process so that one party can confirm that the other party is indeed the identity it claims. In the following examples, public key encryption can easily verify the identity of A and B. The symbol {data} key indicates that "data" has been encrypted or decrypted using the key.
Suppose Alice wants to authenticate Bob. bob has a pair of keys, one public and one private. bob discloses to Alice his public key (the way he does this is discussed later ). alice then generates a random message and sends it to Bob:
A-> B random-message
Bob uses his private key to encrypt the message and returns the encrypted version to Alice:
B-> A {random-message} bobs-private-Key
Alice has es this message and decrypts it by using Bob's previusly published public key. she compares the decrypted message with the one she originally sent to Bob; if they match, she knows she's talking to Bob. an imposter presumably wouldn't know Bob's private key and wocould therefore be unable to properly encrypt the random message for Alice to check.
Assume that a wants to verify B's identity. B has a pair of keys. One is public and the other is private. The Public Key disclosed by Party B to Party. A generates a random message and sends it to B.
A --> B: Random message
B uses his private key to encrypt the information and returns the encrypted information to.
B --> A: {random-message} B's private key
A receives this information and decrypts it using the public key published earlier by B. He compares the decrypted information with the information he sent to B. If they are exactly the same, they will know that they are talking to Party B. No man-in-the-middle knows the private key of Party B, and cannot properly encrypt random information of Party A's check.
But wait, there's more
Wait, the process is not complete.
Unless you know exactly what you are encrypting, it is never a good idea to encrypt something with your private key and then send it to somebody else. this is because the encrypted value can be used against you (Remember, only you cocould have done the encryption because only you have the private key ).
It is not a good idea to encrypt some information with the private key and then send it to others unless you know the meaning of the information clearly. Because the encrypted information may be used to deal with you (Remember, others know that this information is encrypted, because only you have the private key for encryption ).
So, instead of encrypting the original message sent by Alice, Bob constructs a message digest and encrypts that. A message digest is derived from the random message in a way that has the following useful properties:
The digest is difficult to reverse. Someone trying to impersonate Bob couldn't get the original message back from the Digest.
An impersonator wowould have a hard time finding a different message that computed to the same digest value.
Therefore, instead of directly encrypting the original information sent by a, B creates an information digest and encrypts it. Information summarization is calculated based on any information and has the following useful features:
1. It is difficult to restore the original information from this summary value. No one, even if disguised as B, can go from the summary to the original information;
2. It is difficult to calculate the same digest value for different information;
By using a digest, Bob can protect himself. he computes the digest of the random message sent by Alice and then encrypts the result. he sends the encrypted digest back to Alice. alice can compute the same digest and authenticate Bob by decrypting Bob's message and comparing values.
Abstract: B can protect himself. He calculates the digest of any information sent by a, encrypts the digest value, and then sends the encrypted digest value to. A can calculate the same digest value and decrypt the information of B, and finally authenticate B.
The Digest algorithm is also called the hash algorithm)
Getting closer
Further discussion
The technique just described is known as a digital signature. bob has signed a message generated by Alice, and in doing so he has taken a step that is just about as dangerous as encrypting a random value originated by Alice. consequently, our authentication protocol needs one more twist: Some (or all) of the data needs to be originated by Bob.
A-> B Hello, are you Bob?
B-> A Alice, this is Bob {digest [Alice, this is Bob]} bobs-private-Key
When he uses this protocol, Bob knows what message he is sending to Alice, and he doesn't mind signing it. he sends the unencrypted version of the message first, "Alice, this is Bob. "Then he sends the digested-encrypted version second. alice can easily verify that Bob is Bob, and Bob hasn't signed anything he doesn't want.
The technology just discussed is called digital signature. B directly signs the information produced by A. This is as dangerous as encrypting any information produced by. Therefore, we also need to add some tips for the verification protocol: some or all of the information needs to be produced by B:
A --> B: Hello, are you B?
B --> A: A. I am B {abstract [A, I am B]} B's private key
Using this agreement, Party B knows the content of the information he sent to Party A, and he does not mind signing it. He first sends the unencrypted information, "a, I am B", and then sends the encrypted Summary of the information. A can easily verify that B is B. At the same time, B has not signed the information he does not want to sign.
Handing out public keys
Distribution Public Key
How does Bob hand out his public key in a trustworthy way? Let's say the authentication protocol looks like this:
A-> B Hello
B-> A Hi, I'm Bob, Bobs-Public-Key
A-> B prove it
B-> A Alice, this is Bob {digest [Alice, this is Bob]} bobs-private-Key
Then, how does B submit his public key in a trusted manner? See the following verification protocols:
A --> B: Hello
B --> A: Hi, I'm the public key of B and B.
A --> B: Please prove
B --> A: A. I am B {abstract [A, I am B]} B's private key
With this protocol, anybody can be Bob. all you need is a public and private key. you lie to Alice and say you are Bob, and then you provide your public key instead of Bob's. then you prove it by encrypting something with the private key you have, and Alice can't tell you're not Bob.
By using this agreement, anyone can become "B ". As long as you have a pair of public and private keys. If you say that you are B, you only need to provide your public key instead of B's public key. Then, you send the Information encrypted with your private key to prove your identity. A cannot find that you are not B.
To solve this problem, the standards community has specified Ted an object called a certificate. A certificate has the following content:
The certificate issuer's name
The entity for whom the certificate is being issued (aka the subject)
The public key of the subject
Some time stamps
The certificate is signed using the Certificate Issuer's private key. everybody knows the Certificate Issuer's public key (that is, the certificate issuer has a certificate, and so on ...). certificates are a standard way of binding a public key to a name.
To solve this problem, the Organization for Standardization invented the certificate. A certificate has the following content:
Name of the Certificate Issuer
Entity (also known as topic) that is issued to the certificate)
Public Key of the topic
Timestamp
The certificate is encrypted with the issuer's private key. Everyone knows the public key of the certificate issuer (that is, each certificate issuer also has a certificate, and so on ). A certificate is a standard method of binding a public key to a name.
By using this certificate technology, everybody can examine Bob's certificate to see whether it's been forged. assuming that Bob keeps tight control of his private key and that it really is Bob who gets the certificate, then all is well. here is the Amended Protocol:
A-> B Hello
B-> A Hi, I'm Bob, Bobs-Certificate
A-> B prove it
B-> A Alice, this is Bob {digest [Alice, this is Bob]} bobs-private-Key
Now when Alice has es Bob's first message, she can examine the certificate, check the signature (as abve, using a digest and Public Key decryption ), and then check the subject (that is, Bob's name) and see that it is indeed Bob. she can then trust that the public key is Bob's public key and request Bob to prove his identity. bob goes through the same process as before, making a message digest of his design and then responding to Alice with a signed version of it. alice can verify Bob's message digest by using the public key taken from the certificate and checking the result.
By using the certificate technology, everyone can check the certificate of Party B to determine whether it is forged. Let us assume that Party B controls his private key and he does get the certificate. The revised agreement is as follows:
A --> B: Hello
B --> A: Hi, I'm a certificate from B and B.
A --> B: Please prove
B --> A: A. I am B {abstract [A, I am B]} B's private key
Now when a receives the first message from B, he can check the certificate and verify the signature on the certificate (as described above, decrypt it using the digest and public key ), check the topic in the certificate (here is the name of B) and confirm it is B. He can believe that the public key is B's public key, and then ask B to prove his identity. B uses the process described earlier to generate an information digest and use a signature version to reply to. A can use the public key obtained from the certificate to verify the information digest of B and compare the results.
A bad guy-let's call him mallet-can do the following:
A-> M hello
M-> A Hi, I'm Bob, Bobs-Certificate
A-> M prove it
M-> ????
But mallet can't satisfy Alice in the final message. Mallet doesn't have Bob's private key, so he can't construct a message that Alice will believe came from Bob.
Suppose there is a bad boy. We call him H. He can do this:
A --> H: Hello
H --> A: Hello, I'm a certificate from B and B.
A --> H: prove it
H --> :???
H cannot satisfy Party A's last message. He does not have Party B's private key. Therefore, he cannot establish a message that makes Party A believe to be from Party B.
Exchanging a secret
Exchange key (secret)
Once Alice has authenticated Bob, she can do another thing-she can send Bob a message that only Bob can decode:
A-> B {secret} bobs-Public-Key
The only way to find the secret is by decrypting the above message with Bob's private key. exchanging a secret is another powerful way of using public key cryptography. even if the communication between Alice and Bob is being observed, nobody but Bob can get the secret.
Once Party A has verified Party B, he can do another thing-send a key to Party B that only Party B can decrypt and read:
A --> B: {secret} B's public key
Only the private key of Party B can decrypt the above information and obtain the secret (another key ). Exchange (additional) keys are another powerful means provided by public key cryptography. Only Party B can obtain the key even if communication between Party A and Party B is listened on.
This technique strengthens Internet security by using the secret as another key, but this time it's a key to a cipher cryptographic algorithm (such as des, RC4, or idea ). alice knows the secret because she generated it before sending it to Bob. bob knows the secret because Bob has the private key and can decrypt Alice's message. because they both know the secret, they can both initialize a cipher Ric Cipher Algorithm and then start sending messages encrypted with it. here is a revised protocol:
A-> B Hello
B-> A Hi, I'm Bob, Bobs-Certificate
A-> B prove it
B-> A Alice, this is Bob {digest [Alice, this is Bob]} bobs-private-Key
A-> B OK Bob, here is a secret {secret} bobs-Public-Key
B-> A some message} secret-key
How secret-key is computed is up to the protocol being defined, but it cocould simply be a copy of secret.
Using secret as another key enhances network security, but now this key will be used for symmetric encryption algorithms (such as des, RC4, and idea ). (Note: The Public Key algorithm has a large overhead in encrypting large amounts of information. Therefore, symmetric encryption algorithms are generally used in encrypting large amounts of information. The public key system is overwhelmed by conventional communication. Therefore, after identity verification, we need to exchange a symmetric encryption key using the reliability of the public key system. In the future, communication will adopt symmetric encryption algorithms for protection .) Because it is a key generated before Party A sends it to Party B, Party A knows this key. B Also knows the key. Because B has a private key, it can decrypt the information of. Since they all know the key, they are able to initialize a symmetric encryption algorithm, starting from sending (using symmetric encryption algorithms) encrypted information. The following is the revised Protocol:
A --> B: Hello
B --> A: Hi, I'm a certificate from B and B.
A --> B: Please prove
B --> A: A. I am B {abstract [A, I am B]} B's private key
A --> B: Hello, B. Here is the public key of key {secret} B.
B --> A: {some message} secret-key
(Symmetric key) How the secret-key is calculated is completely determined by the communication protocol (defined by both parties). Of course, you can simply use the secret as the secret-key.
You said what?
What are you talking about?
Mallet's bag contains a few more tricks. although mallet can't discover the secret that Alice and Bob have exchanged, he can interfere in their conversation by damaging it. for example, if mallet is sitting between Alice and Bob, he can choose to pass most information back and forth unchanged but mangle certain messages (easy for him to do because he knows the protocol that Alice and Bob are speaking ):
H. There are other tricks. Although I do not know the keys exchanged between Party A and Party B, h can interfere with their conversation. If the hacker H is in the middle of the communication link between Party A and Party B, he can spare most of the information and choose to destroy certain information (this is very simple, because he knows the protocol used for communication between Party A and Party B ):
A-> M hello
M-> B Hello
B-> m Hi, I'm Bob, Bobs-Certificate
M-> A Hi, I'm Bob, Bobs-Certificate
A-> M prove it
M-> B prove it
B-> M Alice, this is Bob {digest [Alice, this is Bob]} bobs-private-Key
M-> A Alice, this is Bob {digest [Alice, this is Bob]} bobs-private-Key
A-> m OK Bob, here is a secret {secret} bobs-Public-Key
M-> B OK Bob, here is a secret {secret} bobs-Public-Key
B-> m {some message} secret-key
M-> A garble [{some message} secret-key]
Mallet passes the data through without modification Until Alice and Bob share a secret. then mallet gets in the way by garbling Bob's message to Alice. by this point Alice trusts Bob, so she may believe the garbled message and try to act on it. note that mallet doesn' t know the secret-all he can do is damage the data encrypted with the secret key. depending on the Protocol, mallet may not produce a valid message. then again, he may get lucky.
A --> H: Hello
H --> B: Hello
B --> H: Hi, I'm a certificate from B and B.
H --> A: Hi, I'm a certificate from B and B.
A --> H: prove it
H --> B: Please verify
B --> H: A. I am B {abstract [A, I am B]} B's private key
H --> A: A. I am B {abstract [A, I am B]} B's private key
A --> H: Hello, B. Here is the public key of key {secret} B.
H --> B: Hello, B. Here is the public key of key {secret} B.
B --> H: {some message} secret-key
H --> A: garble [{s ome message} secret-key]
H ignore some data and do not modify it until a and B exchange keys. Then, H interferes with the information given to Party. At this time, Party A has already trusted party B, so he may have believed the information that has been disturbed and tried his best to decrypt it. Note that H does not know the key. All he can do is destroy the data encrypted with the key. Based on the Protocol, h may not generate a valid message. But next time?
To prevent this kind of damage, Alice and Bob can introduce a message authentication code (MAC) into their protocol. a mac is a piece of data that is computed by using a secret and some transmitted data. the Digest algorithm described above has just the right properties for building a Mac function that can defend against mallet:
Mac: = digest [some message, secret]
Because mallet doesn't know the secret, he can't compute the right value for the Digest. even if mallet randomly garbles messages, his chance of success is small if the digest data is large. for example, by using MD5 (a good cryptographic Digest algorithm published ted by RSA), Alice and Bob can send 128-bit MAC values with their messages. the odds of mallet's guessing the right mac are approximately 1 in 18,446,744,073,709,551,616-for all practical purposes, never.
To prevent such damages, Party A and Party B can introduce a message authentication code (MAC) in their protocol ). Mac is a piece of data calculated based on the key and transmitted information. The features of the digest algorithm described above can be used to defend against H attacks when Mac is generated:
MAC = digest [some message, secret]
Because H does not know the key, he cannot calculate the correct digest value. Even if H randomly interferes with the information, as long as the data volume is large, there is little chance of success. For example, using MD5 (a good encryption Digest algorithm invented by RSA), A and B can add 128-bit MAC values to their information. H. I guess the chance of a correct Mac is nearly 1/18, 446,744,073,709,551,616, or about zero.
Here is the sample protocol, revised yet again:
A-> B Hello
B-> A Hi, I'm Bob, Bobs-Certificate
A-> B prove it
B-> A Alice, this is Bob {digest [Alice, this is Bob]} bobs-private-Key
A-> B OK Bob, here is a secret {secret} bobs-Public-Key
B-> A {some message, Mac} secret-key
Mallet is in trouble now. he can garble messages all he wants, but the Mac computations will reveal him for the fraud he is. alice or Bob can discover the bogus MAC value and stop talking. mallet can no longer put words in Bob's mouth.
The modified protocol is as follows:
A --> B: Hello
B --> A: Hi, I'm a certificate from B and B.
A --> B: Please prove
B --> A: A. I am B {abstract [A, I am B]} B's private key
A --> B: Hello, B. This is the public key of key {secret} B.
B --> A: {some message, Mac} secret-key
Now H has no technical support. He can interfere with any information, but Mac computing can find his tricks. A and B can detect FAKE MAC values and stop talking. H can no longer communicate with Party B.
When was that said?
Last but not least to protect against is mallet the parrot. if mallet is recording conversations, he may not understand them but he can replay them. in fact, mallet can do some really nasty things sitting between Alice and Bob. the solution is to introduce random elements from both sides of the conversation.
It is not enough to prevent the heap attack. If H records the communication between Party A and Party B, although he cannot understand the meaning of the communication, he can reproduce the communication ). In fact, H, which is hidden in the middle of Party A and Party B, can perform some powerful attacks. The solution is to introduce random factors in the communication between the two parties.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/lovingprince/archive/2007/11/09/1876084.aspx