公鑰系統/數字簽名/數字證書工做原理入門

本文譯自：
[url]http://developer.netscape.com/tech/security/ssl/howitworks.html[/url]

這是一篇生動淺顯的文章，對了解公鑰系統的工做原理頗有幫助，CSDN上已有一篇譯文：

[url]http://www.csdn.net/Develop/article/27/27524.shtm[/url]
但本人認爲上文的關鍵地方不夠準確，欠通順。本譯文在上篇譯文的基礎上，關鍵的術語採用了通用譯法，少數地方採用了意譯，並且附有英文原文，有翻譯不當的地方你們能夠對照原文。
但願能對公鑰系統有興趣的朋友們有所幫助。

BTW：上面提到的全部對稱加密和非對稱加密，它們的加解密算法都是公開的，只要不知道密鑰，算法的設計者有信心使加密結果不會被輕易破解，這點與WAPI大相徑庭：） 。

如下是中英文對照的譯文：

Public key encryption is a technique that uses a pair of asymmetric 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.
公鑰加密是使用一對非對稱的密鑰加密或解密的技術。每一對密鑰由公鑰和私鑰組成。公鑰被普遍發佈。私鑰是隱密的，不公開。

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 asymmetry is the property that makes public key cryptography so useful.
用公鑰加密的數據只可以被私鑰解密。反過來，使用私鑰加密的數據只能用公鑰解密。這個非對稱的特性使得公鑰加密頗有用。

USING PUBLIC KEY CRYPTOGRAPHY 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.
驗證是一個核實身份的過程，以便一方能確認另外一方的確是其所聲稱的那個身份。在下列例子中包括甲和乙，公鑰加密會輕鬆地校驗身份。符號{數據} key意味着"數據"已經使用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 receives this message and decrypts it by using Bob's previously 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 would therefore be unable to properly encrypt the random message for Alice to check.
假如甲想校驗乙的身份。乙有一對密鑰，一個是公開的，另外一個是私有的。乙透露給甲他的公鑰。甲產生一個隨機信息發送給乙。

甲——〉乙：random message

乙使用他的私鑰加密信息，把加密後的信息返回甲。

乙——〉甲：{random-message}乙的私鑰

甲收到這個信息而後使用乙的前面公開的公鑰解密。他比較解密後的信息與他原先發給乙的信息。若是它們徹底一致，就會知道在與乙說話。任意一箇中間人不會知道乙的私鑰，也不能正確加密甲檢查的隨機信息。

BUT WAIT, THERE'S MORE
等一下，事情尚未完

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 could have done the encryption because only you have the private key).
用私鑰加密某些信息，而後發送給其餘人不是一個好主意，除非你清楚知道這個信息的含義。由於加密後的信息可能被用來對付你（記住，別人知道該信息是你加密的，由於只有你有加密用的私鑰）。

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 would have a hard time finding a different message that computed to the same digest value.

因此，取代直接加密甲發來的原始信息，乙建立一個信息摘要而且加密該摘要。信息摘要由任意信息運算而來，並具備如下有用的特性：

1. 從這個摘要值難以還原出原始信息。任何人即便假裝成乙，也不能從摘要值獲得原始信息；

2. 不一樣的信息很難計算出相同的摘要值；

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.
使用摘要，乙可以保護本身。他計算甲發出的任意信息的摘要，加密摘要值，而後發送加密的摘要值給甲。甲可以計算出相同的摘要值而且解密乙的信息，最終認證乙。
（譯者注：摘要（Digest）算法又稱爲散列(Hash)算法）

GETTING CLOSER
進一步的討論

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 to.

剛剛討論的技術稱爲數字簽名。乙直接在甲產生的信息上簽名，這樣作和加密甲產生的任意信息是一樣危險的。所以咱們的驗證協議還須要加一些技巧：某些或所有信息須要由乙產生：

甲——〉乙：你好，你是乙麼?
乙——〉甲：甲，我是乙 {摘要[甲，我是乙] } 乙的私鑰

使用這個協議，乙知道他發送給甲的信息的內容，他不介意在上面簽名。他先發送不加密的信息，"甲，我是乙"，而後發送該信息的加密後的摘要。甲能夠很是方便地核實乙就是乙，同時，乙尚未在他不想簽名的信息上簽名。

HANDING OUT PUBLIC KEYS
分發公鑰

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

那麼，乙怎樣以可信的方式提交他的公鑰呢？看看以下所示的驗證協議：

甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的公鑰
甲——〉乙：請證實
乙——〉甲：甲，我是乙 {摘要[甲，我是乙] } 乙的私鑰

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.
使用這個協議，任何人都可以成爲"乙"。只要你有一對公鑰和私鑰。你欺騙甲說你就是乙，只要提供你的公鑰，而不是乙的公鑰。而後，你發送用你的私鑰加密的信息，證實你的身份。甲並不能發覺你並非乙。

To solve this problem, the standards community has invented 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.

爲了解決這個問題，標準化組織發明了證書。一個證書有如下的內容：

       證書發行者的名稱
       被髮給證書的實體（也稱爲主題）
       主題的公鑰
       一些時間戳

證書使用發行者的私鑰加密。每個人都知道證書發行者的公鑰（就是說，每一個證書的發行者也擁有一個證書，以此類推）。證書是一個把公鑰與一個名稱綁定的標準方式。

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 receives Bob's first message, she can examine the certificate, check the signature (as above, 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.

經過使用證書技術，每一個人均可以檢查乙的證書，判斷其是否被僞造。假設乙控制好他的私鑰，而且他確實是獲得證書的乙，就萬事大吉了。下面是修訂後的協議：

甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的證書
甲——〉乙：請證實
乙——〉甲：甲，我是乙 {摘要[甲， 我是乙] } 乙的私鑰

如今當甲收到乙的第一個信息，他能檢查證書，覈查證書上的簽名（如上所述，使用摘要和公鑰解密），檢查證書中的主題（這裏是乙的姓名），肯定是乙。他就能相信公鑰就是乙的公鑰，而後要求乙證實本身的身份。乙經過前面描述過的過程，製做一個信息摘要，用一個簽名版本答覆甲。甲能夠經過使用從證書上獲得的公鑰檢驗乙的信息摘要，並對比結果。

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->A   ????

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.

假設有一個壞小子，咱們稱他爲H，他能夠這麼作：

甲——〉H：你好
H——〉甲：你好，我是乙，乙的證書
甲——〉H：請證實
H——〉甲：？？？

H不能知足甲的最後一個信息，他沒有乙的私鑰，所以他不能創建一個令甲相信是來自乙的信息。

EXCHANGING A SECRET
交換密鑰（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.

一旦甲已經驗證乙後，他就能夠作另外的事情了--發送給乙一個只有乙能夠解密、閱讀的（另外一個）密鑰：

甲——〉乙：{ secret }乙的公鑰

只有使用乙的私鑰才能解密上述信息，獲得secret（另外一個密鑰）。交換（額外的）密鑰是公鑰密碼術提供的另外一個強有力的手段。即便在甲和乙之間的通信被偵聽，只有乙才能獲得密鑰。

This technique strengthens Internet security by using the secret as another key, but this time it's a key to a symmetric 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 symmetric 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 could simply be a copy of secret.

使用secret做爲另外一個密鑰加強了網絡的安全性，可是如今這個密鑰將用於對稱加密算法的（例如DES、RC四、IDEA）。（譯者注：公鑰算法在加密大信息量時開銷比較大，因此在加密大信息量時通常採用對稱加密算法，常規通信使用公鑰系統是不堪重負的。因此本文在身份驗證後要利用公鑰系統的可靠×××換一個對稱加密的密鑰，之後的通信就採用對稱加密算法進行保護。）由於是甲在發送給乙以前產生的密鑰，因此甲知道這個密鑰。乙也知道密鑰，由於乙有私鑰，可以解密甲的信息。因爲他們都知道密鑰，他們就都可以初始化一個對稱加密算法，從開始發送（用對稱加密算法）加密後的信息。下面是修定後的協議：

甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的證書
甲——〉乙：請證實
乙——〉甲：甲，我是乙 {摘要[甲，我是乙] }乙的私鑰
甲——〉乙：你好乙，這裏是密鑰 {secret}乙的公鑰
乙——〉甲：{some message}secret-key

（對稱密鑰）secret-key是如何計算出來的，徹底由（雙方定義的）通信協議自已決定，固然能夠簡單地就把secret作爲secret-key。

YOU SAID WHAT?
你在說什麼？

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還有其餘花招。雖然不知道發現甲和乙已經交換的密鑰，但H能干擾他們的交談。若是***H在甲和乙（的通信鏈路的）中間，他能夠放過大部分信息，選擇破壞必定的信息（這是很是簡單的，由於他知道甲和乙通話採用的協議）：

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.

甲——〉H：你好
H——〉乙：你好

乙——〉H：嗨，我是乙，乙的證書
H——〉甲：嗨，我是乙，乙的證書

甲——〉H：請證實
H——〉乙：請證實

乙——〉H：甲，我是乙 {摘要[甲，我是乙] }乙的私鑰
H——〉甲：甲，我是乙 {摘要[甲，我是乙] }乙的私鑰

甲——〉H：你好，乙，這裏是密鑰 {secret} 乙的公鑰
H——〉乙：你好，乙，這裏是密鑰 {secret} 乙的公鑰

乙——〉H：{some message}secret-key
H——〉甲：Garble[{s ome message}secret-key ]

H忽略一些數據不修改，直到甲和乙交換密鑰。而後H干擾乙給甲的信息。在這時，甲已經信任乙，因此他可能相信已經被幹擾的信息而且盡力解密。須要注意的是，H不知道密鑰，他所能作的就是毀壞使用密鑰加密後的數據。基於協議，H可能不能產生一個有效的信息。但下一次呢？

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 invented 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.

爲了阻止這種破壞，甲和乙能夠在他們的協議中引入一個信息驗證碼（message authentication code，如下稱MAC）。MAC是根據密鑰和被傳輸的信息計算出的一段數據。前面描述的摘要算法的特性在生成MAC時正好能夠派上用場，用來抵禦H的***：

MAC= Digest[some message，secret ]

由於H不知道密鑰，他不能計算出正確的摘要值。即便H隨機干擾信息，只要數據量大，他成功的機會微乎其微。例如，使用MD5（一個RSA發明的好的加密摘要算法），甲和乙可以給他們的信息加上128位MAC值。H猜想正確的MAC的概率將近1/18，446，744，073，709，551， 616，約等於零。

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.

下面又一次修改後的協議：

甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的證書
甲——〉乙：請證實
乙——〉甲：甲，我是乙 {摘要[甲，我是乙] } 乙的私鑰
甲——〉乙：你好，乙，這是密鑰 {secret} 乙的公鑰
乙——〉甲：{some message，MAC}secret-key

如今H已經無技可施了。他能夠干擾任何信息，但MAC計算可以發現他的詭計。甲和乙可以發現僞造的MAC值而且中止交談。H再也不能假借乙通信。

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.
僅僅防範H的學舌式***是不夠的。若是H記錄下（甲和乙的）通信，雖然他不能明白（通信的）含義，可是他能夠重現（通信）。事實上，隱藏在甲和乙中間的H能夠作一些頗具威助的***。解決方案是在雙方通信中引入隨機因素。

 

 

本文轉自 [url]http://blog.csdn.net/horris/archive/2004/05/17/6351.aspx[/url]