這篇文章是我一邊學(xué)習(xí)證書驗(yàn)證一邊記錄的內(nèi)容，
稍微整理了下，共扯了三部分內(nèi)容：

HTTPS 簡(jiǎn)要原理；
數(shù)字證書的內(nèi)容、生成及驗(yàn)證；
iOS 上對(duì)證書鏈的驗(yàn)證。
HTTPS 概要
HTTPS 是運(yùn)行在 TLS/SSL 之上的 HTTP，與普通的 HTTP 相比，在數(shù)據(jù)傳輸?shù)陌踩陨嫌泻艽蟮奶嵘?br/> 要了解它安全性的巧妙之處，需要先簡(jiǎn)單地了解對(duì)稱加密和非對(duì)稱加密的區(qū)別：

對(duì)稱加密只有一個(gè)密鑰，加密和解密都用這個(gè)密鑰；
非對(duì)稱加密有公鑰和私鑰，私鑰加密后的內(nèi)容只有公鑰才能解密，公鑰加密的內(nèi)容只有私鑰才能解密。
為了提高安全性，我們常用的做法是使用對(duì)稱加密的手段加密數(shù)據(jù)。可是只使用對(duì)稱加密的話，雙方通信的開(kāi)始總會(huì)以明文的方式傳輸密鑰。那么從一開(kāi)始這個(gè)密鑰就泄露了，談不上什么安全。所以 TLS/SSL 在握手的階段，結(jié)合非對(duì)稱加密的手段，保證只有通信雙方才知道對(duì)稱加密的密鑰。大概的流程如下：

TSL:SSL_handshake.png
所以，HTTPS 實(shí)現(xiàn)傳輸安全的關(guān)鍵是：在 TLS/SSL 握手階段保證僅有通信雙方得到 Session Key！

數(shù)字證書的內(nèi)容
X.509 應(yīng)該是比較流行的 SSL 數(shù)字證書標(biāo)準(zhǔn)，包含（但不限于）以下的字段：

字段值說(shuō)明
對(duì)象名稱（Subject Name）用于識(shí)別該數(shù)字證書的信息
共有名稱（Common Name） 對(duì)于客戶證書，通常是相應(yīng)的域名
證書頒發(fā)者（Issuer Name）發(fā)布并簽署該證書的實(shí)體的信息
簽名算法（Signature Algorithm） 簽名所使用的算法
序列號(hào)（Serial Number）數(shù)字證書機(jī)構(gòu)（Certificate Authority， CA）給證書的唯一整數(shù)，一個(gè)數(shù)字證書一個(gè)序列號(hào)
生效期（Not Valid Before） (｀?ω?′)
失效期（Not Valid After）(╯°口°)╯(┴—┴
公鑰（Public Key）可公開(kāi)的密鑰
簽名（Signature） 通過(guò)簽名算法計(jì)算證書內(nèi)容后得到的數(shù)據(jù)，用于驗(yàn)證證書是否被篡改
除了上述所列的字段，還有很多拓展字段，在此不一一詳述。

下圖為 Wikipedia 的公鑰證書：

wikipedia_cer.png
數(shù)字證書的生成及驗(yàn)證
數(shù)字證書的生成是分層級(jí)的，下一級(jí)的證書需要其上一級(jí)證書的私鑰簽名。
所以后者是前者的證書頒發(fā)者，也就是說(shuō)上一級(jí)證書的 Subject Name 是其下一級(jí)證書的 Issuer Name。

在得到證書申請(qǐng)者的一些必要信息（對(duì)象名稱，公鑰私鑰）之后，證書頒發(fā)者通過(guò) SHA-256 哈希得到證書內(nèi)容的摘要，再用自己的私鑰給這份摘要加密，得到數(shù)字簽名。綜合已有的信息，生成分別包含公鑰和私鑰的兩個(gè)證書。

扯到這里，就有幾個(gè)問(wèn)題：

問(wèn)：如果說(shuō)發(fā)布一個(gè)數(shù)字證書必須要有上一級(jí)證書的私鑰加密，那么最頂端的證書——根證書怎么來(lái)的？

根證書是自簽名的，即用自己的私鑰簽名，不需要其他證書的私鑰來(lái)生成簽名。

問(wèn)：怎么驗(yàn)證證書是有沒(méi)被篡改？

當(dāng)客戶端走 HTTPS 訪問(wèn)站點(diǎn)時(shí)，服務(wù)器會(huì)返回整個(gè)證書鏈。以下圖的證書鏈為例：

chain_hierarchy.png
要驗(yàn)證 *.wikipedia.org 這個(gè)證書有沒(méi)被篡改，就要用到 GlobalSign Organization Validation CA - SHA256 - G2 提供的公鑰解密前者的簽名得到摘要 Digest1，我們的客戶端也計(jì)算前者證書的內(nèi)容得到摘要 Digest2。對(duì)比這兩個(gè)摘要就能知道前者是否被篡改。后者同理，使用 GlobalSign Root CA 提供的公鑰驗(yàn)證。當(dāng)驗(yàn)證到到受信任的根證書時(shí)，就能確定 *.wikipedia.org 這個(gè)證書是可信的。

問(wèn)：為什么上面那個(gè)根證書 GlobalSign Root CA 是受信任的？

數(shù)字證書認(rèn)證機(jī)構(gòu)（Certificate Authority, CA）簽署和管理的 CA 根證書，會(huì)被納入到你的瀏覽器和操作系統(tǒng)的可信證書列表中，并由這個(gè)列表判斷根證書是否可信。所以不要隨便導(dǎo)入奇奇怪怪的根證書到你的操作系統(tǒng)中。

問(wèn)：生成的數(shù)字證書（如 *.wikipedia.org）都可用來(lái)簽署新的證書嗎？

不一定。如下圖，拓展字段里面有個(gè)叫 Basic Constraints 的數(shù)據(jù)結(jié)構(gòu)，里面有個(gè)字段叫路徑長(zhǎng)度約束（Path Length Constraint），表明了該證書能繼續(xù)簽署 CA 子證書的深度，這里為0，說(shuō)明這個(gè) GlobalSign Organization Validation CA - SHA256 - G2 只能簽署客戶端證書，而客戶端證書不能用于簽署新的證書，CA 子證書才能這么做。

path_length_constraint.png
iOS 上對(duì)證書鏈的驗(yàn)證
在 Overriding TLS Chain Validation Correctly 中提到：

When a TLS certificate is verified, the operating system verifies its chain of trust. If that chain of trust contains only valid certificates and ends at a known (trusted) anchor certificate, then the certificate is considered valid.

所以在 iOS 中，證書是否有效的標(biāo)準(zhǔn)是：

信任鏈中如果只含有有效證書并且以可信錨點(diǎn)（trusted anchor）結(jié)尾，那么這個(gè)證書就被認(rèn)為是有效的。

其中可信錨點(diǎn)指的是系統(tǒng)隱式信任的證書，通常是包括在系統(tǒng)中的 CA 根證書。不過(guò)你也可以在驗(yàn)證證書鏈時(shí)，設(shè)置自定義的證書作為可信的錨點(diǎn)。

NSURLSession 實(shí)現(xiàn) HTTPS

具體到使用 NSURLSession 走 HTTPS 訪問(wèn)網(wǎng)站，-URLSession:didReceiveChallenge:completionHandler: 回調(diào)中會(huì)收到一個(gè) challenge，也就是質(zhì)詢，需要你提供認(rèn)證信息才能完成連接。這時(shí)候可以通過(guò) challenge.protectionSpace.authenticationMethod 取得保護(hù)空間要求我們認(rèn)證的方式，如果這個(gè)值是 NSURLAuthenticationMethodServerTrust 的話，我們就可以插手 TLS 握手中“驗(yàn)證數(shù)字證書有效性”這一步。

默認(rèn)的實(shí)現(xiàn)

系統(tǒng)的默認(rèn)實(shí)現(xiàn)（也即代理不實(shí)現(xiàn)這個(gè)方法）是驗(yàn)證這個(gè)信任鏈，結(jié)果是有效的話則根據(jù) serverTrust 創(chuàng)建 credential 用于同服務(wù)端確立 SSL 連接。否則會(huì)得到 “The certificate for this server is invalid...” 這樣的錯(cuò)誤而無(wú)法訪問(wèn)。

比如在訪問(wèn) https://www.google.com 的時(shí)候咧，我們不實(shí)現(xiàn)這個(gè)方法也能訪問(wèn)成功的。系統(tǒng)對(duì) Google 服務(wù)器返回來(lái)的證書鏈，從葉節(jié)點(diǎn)證書往根證書層層驗(yàn)證（有效期、簽名等等），遇到根證書時(shí)，發(fā)現(xiàn)作為可信錨點(diǎn)的它存在與可信證書列表中，那么驗(yàn)證就通過(guò)，允許與服務(wù)端建立連接。

google.png
而當(dāng)我們?cè)L問(wèn) https://www.12306.cn 時(shí)，就會(huì)出現(xiàn) "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “www.12306.cn” which could put your confidential information at risk." 的錯(cuò)誤。原因就是系統(tǒng)在驗(yàn)證到根證書時(shí)，發(fā)現(xiàn)它是自簽名、不可信的。

12306.png
自定義實(shí)現(xiàn)

如果我們要實(shí)現(xiàn)這個(gè)代理方法的話，需要提供 NSURLSessionAuthChallengeDisposition（處置方式）和 NSURLCredential（資格認(rèn)證）這兩個(gè)參數(shù)給 completionHandler 這個(gè) block：

復(fù)制代碼
1 -(void)URLSession:(NSURLSession *)session
2 didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
3 completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition,
4 NSURLCredential * _Nullable))completionHandler {
5
6 // 如果使用默認(rèn)的處置方式，那么 credential 就會(huì)被忽略
7 NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
8 NSURLCredential credential = nil;
9
10 if ([challenge.protectionSpace.authenticationMethod
11 isEqualToString:
12 NSURLAuthenticationMethodServerTrust]) {
13
14 / 調(diào)用自定義的驗(yàn)證過(guò)程 /
15 if ([self myCustomValidation:challenge]) {
16 credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
17 if (credential) {
18 disposition = NSURLSessionAuthChallengeUseCredential;
19 }
20 } else {
21 / 無(wú)效的話，取消 */
22 disposition = NSURLSessionAuthChallengeCancelAuthenticationChallenge
23 }
24 }
25 if (completionHandler) {
26 completionHandler(disposition, credential);
27 }
28 }
復(fù)制代碼
在 [self myCustomValidation:challenge] 調(diào)用自定義驗(yàn)證過(guò)程，結(jié)果是有效的話才創(chuàng)建 credential 確立連接。
自定義的驗(yàn)證過(guò)程，需要先拿出一個(gè) SecTrustRef 對(duì)象，它是一種執(zhí)行信任鏈驗(yàn)證的抽象實(shí)體，包含著驗(yàn)證策略（SecPolicyRef）以及一系列受信任的錨點(diǎn)證書，而我們能做的也是修改這兩樣?xùn)|西而已。

1 SecTrustRef trust = challenge.protectionSpace.serverTrust;

拿到 trust 對(duì)象之后，可以用下面這個(gè)函數(shù)對(duì)它進(jìn)行驗(yàn)證。

復(fù)制代碼
1 static BOOL serverTrustIsVaild(SecTrustRef trust) {
2 BOOL allowConnection = NO;
3
4 // 假設(shè)驗(yàn)證結(jié)果是無(wú)效的
5 SecTrustResultType trustResult = kSecTrustResultInvalid;
6
7 // 函數(shù)的內(nèi)部遞歸地從葉節(jié)點(diǎn)證書到根證書的驗(yàn)證
8 OSStatus statue = SecTrustEvaluate(trust, &trustResult);
9
10 if (statue == noErr) {
11 // kSecTrustResultUnspecified: 系統(tǒng)隱式地信任這個(gè)證書
12 // kSecTrustResultProceed: 用戶加入自己的信任錨點(diǎn)，顯式地告訴系統(tǒng)這個(gè)證書是值得信任的
13
14 allowConnection = (trustResult == kSecTrustResultProceed
15 || trustResult == kSecTrustResultUnspecified);
16 }
17 return allowConnection;
18 }
復(fù)制代碼
這個(gè)函數(shù)什么時(shí)候調(diào)用完全取決于你的需求，如果你不想對(duì)驗(yàn)證策略做修改而直接調(diào)用的話，那你居然還看到這里??？(╯‵□′)╯︵┻━┻

域名驗(yàn)證

可以通過(guò)以下的代碼獲得當(dāng)前的驗(yàn)證策略：

1 CFArrayRef policiesRef;

2 SecTrustCopyPolicies(trust, &policiesRef);

打印 policiesRef 后，你會(huì)發(fā)現(xiàn)默認(rèn)的驗(yàn)證策略就包含了域名驗(yàn)證，即“服務(wù)器證書上的域名和請(qǐng)求域名是否匹配”。如果你的一個(gè)證書需要用來(lái)連接不同域名的主機(jī)，或者你直接用 IP 地址去連接，那么你可以重設(shè)驗(yàn)證策略以忽略域名驗(yàn)證:

復(fù)制代碼
1 NSMutableArray *policies = [NSMutableArray array];
2
3 // BasicX509 不驗(yàn)證域名是否相同
4 SecPolicyRef policy = SecPolicyCreateBasicX509();
5 [policies addObject:(__bridge_transfer id)policy];
6 SecTrustSetPolicies(trust, (__bridge CFArrayRef)policies);
7
8
復(fù)制代碼
后再調(diào)用 serverTrustIsVaild() 驗(yàn)證。

但是如果不驗(yàn)證域名的話，安全性就會(huì)大打折扣。拿瀏覽器舉?：

試想你要傳輸報(bào)文到 https://www.real-website.com ，然而由于域名劫持，把你帶到了 https://www.real-website.cn 這個(gè)?網(wǎng)站，大概有以下兩種結(jié)果：

這個(gè)偽造網(wǎng)站的證書是非 CA 頒布的偽造證書的話，那么瀏覽器會(huì)提醒你這個(gè)證書不可信；
這個(gè)偽造網(wǎng)站也使用了 CA 頒布的證書，由于我們不做域名驗(yàn)證，你的瀏覽器不會(huì)有任何的警告。
你可能會(huì)問(wèn)：公鑰證書是每個(gè)人都能得到的，釣魚網(wǎng)站能不能返回真正的公鑰證書給我們呢？

我覺(jué)得是可以的，然而這并沒(méi)有什么卵用。沒(méi)有私鑰的釣魚服務(wù)器無(wú)法獲得第三個(gè)隨機(jī)數(shù)，無(wú)法生成 Session Key，也就不能對(duì)我們傳給它的數(shù)據(jù)進(jìn)行解密了。

自簽名的證書鏈驗(yàn)證

在 App 中想要防止上面提到的中間人公雞攻擊，比較好的做法是將公鑰證書打包進(jìn) App 中，然后在收到服務(wù)端證書鏈的時(shí)候，能夠有效地驗(yàn)證服務(wù)端是否可信，這也是驗(yàn)證自簽名的證書鏈所必須做的。

假設(shè)你的服務(wù)器返回：[你的自簽名的根證書] -- [你的二級(jí)證書] -- [你的客戶端證書]，系統(tǒng)是不信任這個(gè)三個(gè)證書的。
所以你在驗(yàn)證的時(shí)候需要將這三個(gè)的其中一個(gè)設(shè)置為錨點(diǎn)證書，當(dāng)然，多個(gè)也行。

比如將 [你的二級(jí)證書] 作為錨點(diǎn)后，SecTrustEvaluate() 函數(shù)只要驗(yàn)證到 [你的客戶端證書] 確實(shí)是由 [你的二級(jí)證書] 簽署的，那么驗(yàn)證結(jié)果為 kSecTrustResultUnspecified，表明了 [你的客戶端證書] 是可信的。下面是設(shè)置錨點(diǎn)證書的做法：

復(fù)制代碼
1 NSMutableArray certificates = [NSMutableArray array];
2
3 NSDate cerData = / 在 App Bundle 中你用來(lái)做錨點(diǎn)的證書數(shù)據(jù)，證書是 CER 編碼的，常見(jiàn)擴(kuò)展名有：cer, crt.../
4
5 SecCertificateRef cerRef = SecCertificateCreateWithData(NULL, (__bridge CFDataRef)cerData);
6
7 [certificates addObject:(__bridge_transfer id)cerRef];
8
9 // 設(shè)置錨點(diǎn)證書。
10 SecTrustSetAnchorCertificates(trust, (__bridge CFArrayRef)certificates);
復(fù)制代碼
只調(diào)用 SecTrustSetAnchorCertificates () 這個(gè)函數(shù)的話，那么就只有作為參數(shù)被傳入的證書作為錨點(diǎn)證書，連系統(tǒng)本身信任的 CA 證書不能作為錨點(diǎn)驗(yàn)證證書鏈。要想恢復(fù)系統(tǒng)中 CA 證書作為錨點(diǎn)的功能，還要再調(diào)用下面這個(gè)函數(shù)：

1 // true 代表僅被傳入的證書作為錨點(diǎn)，false 允許系統(tǒng) CA 證書也作為錨點(diǎn)

2 SecTrustSetAnchorCertificatesOnly(trust, false);

這樣，再調(diào)用 serverTrustIsVaild() 驗(yàn)證證書有效性就能成功了。

CA 證書鏈的驗(yàn)證

上面說(shuō)的是沒(méi)經(jīng)過(guò) CA 認(rèn)證的自簽證書的驗(yàn)證，而 CA 的證書鏈的驗(yàn)證方式也是一樣，不同點(diǎn)在不可信錨點(diǎn)的證書類型不一樣而已：前者的錨點(diǎn)是自簽的需要被打包進(jìn) App 用于驗(yàn)證，后者的錨點(diǎn)可能本來(lái)就存在系統(tǒng)之中了。不過(guò)我腦補(bǔ)了這么的一個(gè)坑：

假如我們使用的是 CA 根證書簽署的數(shù)字證書，而且只用這個(gè) CA 根證書作為錨點(diǎn)，在不驗(yàn)證域名的情況下，是不是就會(huì)在握手階段信任被同一個(gè) CA 根證書簽名的偽造證書呢？

參考閱讀
iOS安全系列之一：HTTPS

iOS安全系列之二：HTTPS進(jìn)階

Overriding TLS Chain Validation Correctly

HTTPS Server Trust Evaluation

上文有什么我理解得不正確、或表達(dá)不準(zhǔn)確的地方，煩請(qǐng)指教。?

文／StanOz（ 作者）
原文鏈接：http://www.jianshu.com/p/31bcddf44b8d
著作權(quán)歸作者所有，轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，并標(biāo)注“ 作者”。

其他：
公司的接口一般會(huì)兩種協(xié)議的，一種HTTP，一種HTTPS的，HTTP 只要請(qǐng)求，服務(wù)器就會(huì)響應(yīng)，如果我們不對(duì)請(qǐng)求和響應(yīng)做出加密處理，所有信息都是會(huì)被檢測(cè)劫持到的，是很不安全的，客戶端加密可以使用我這套工具類進(jìn)行處理：文章地址
但是不論在任何時(shí)候，都應(yīng)該將服務(wù)置于HTTPS上，因?yàn)樗梢员苊庵虚g人攻擊的問(wèn)題，還自帶了基于非對(duì)稱密鑰的加密通道！現(xiàn)實(shí)是這些年涌現(xiàn)了大量速成的移動(dòng)端開(kāi)發(fā)人員，這些人往往基礎(chǔ)很差，完全不了解加解密為何物，使用HTTPS后，可以省去教育他們各種加解密技術(shù)，生活輕松多了。

介紹下HTTPS交互原理
簡(jiǎn)答說(shuō)，HTTPS 就是 HTTP協(xié)議加了一層SSL協(xié)議的加密處理，SSL 證書就是遵守 SSL協(xié)議，由受信任的數(shù)字證書頒發(fā)機(jī)構(gòu)CA（如GlobalSign，wosign），在驗(yàn)證服務(wù)器身份后頒發(fā)，這是需要花錢滴，簽發(fā)后的證書作為公鑰一般放在服務(wù)器的根目錄下，便于客戶端請(qǐng)求返回給客戶端，私鑰在服務(wù)器的內(nèi)部中心保存，用于解密公鑰。

HTTPS 客戶端與服務(wù)器交互過(guò)程：

1、客戶端發(fā)送請(qǐng)求，服務(wù)器返回公鑰給客戶端；
2、客戶端生成對(duì)稱加密秘鑰，用公鑰對(duì)其進(jìn)行加密后，返回給服務(wù)器；
3、服務(wù)器收到后，利用私鑰解開(kāi)得到對(duì)稱加密秘鑰，保存；
4、之后的交互都使用對(duì)稱加密后的數(shù)據(jù)進(jìn)行交互。

談下證書
簡(jiǎn)單說(shuō)，證書有兩種，一種是正經(jīng)的：

CA頒發(fā)的證書

一種是不正經(jīng)的：

自己生成簽發(fā)的證書
介紹下我們需要做什么
如果遇到正經(jīng)的證書，我們直接用AFNetworking 直接請(qǐng)求就好了，AFNetworking 內(nèi)部幫我們封裝了HTTPS的請(qǐng)求方式，但是大部分公司接口都是不正經(jīng)的證書，這時(shí)需要我們做以下幾步：
1、將服務(wù)器的公鑰證書拖到Xcode中
2、修改驗(yàn)證模式

manager.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModePublicKey];
原理：
簡(jiǎn)單來(lái)說(shuō)，就是你本可以修改AFN這個(gè)設(shè)置來(lái)允許客戶端接收服務(wù)器的任何證書，但是這么做有個(gè)問(wèn)題，就是你無(wú)法驗(yàn)證證書是否是你的服務(wù)器后端的證書，給中間人攻擊，即通過(guò)重定向路由來(lái)分析偽造你的服務(wù)器端打開(kāi)了大門。

AFSecurityPolicy *securityPolicy = [AFSecurityPolicy defaultPolicy];
securityPolicy.allowInvalidCertificates = YES;
解決方法：AFNetworking是允許內(nèi)嵌證書的，通過(guò)內(nèi)嵌證書，AFNetworking就通過(guò)比對(duì)服務(wù)器端證書、內(nèi)嵌的證書、站點(diǎn)域名是否一致來(lái)驗(yàn)證連接的服務(wù)器是否正確。由于CA證書驗(yàn)證是通過(guò)站點(diǎn)域名進(jìn)行驗(yàn)證的，如果你的服務(wù)器后端有綁定的域名，這是最方便的。將你的服務(wù)器端證書，如果是pem格式的，用下面的命令轉(zhuǎn)成cer格式

openssl x509 -in <你的服務(wù)器證書>.pem -outform der -out server.cer
然后將生成的server.cer文件，如果有自建ca，再加上ca的cer格式證書，引入到app的bundle里，AFNetworking在

AFSecurityPolicy *securityPolicy = [AFSecurityPolicy AFSSLPinningModeCertificate];
或者

AFSecurityPolicy *securityPolicy = [AFSecurityPolicy AFSSLPinningModePublicKey];
情況下，會(huì)自動(dòng)掃描bundle中.cer的文件，并引入，這樣就可以通過(guò)自簽證書來(lái)驗(yàn)證服務(wù)器唯一性了。

AFSecurityPolicy分三種驗(yàn)證模式：

AFSSLPinningModeNone

這個(gè)模式表示不做SSL pinning，
只跟瀏覽器一樣在系統(tǒng)的信任機(jī)構(gòu)列表里驗(yàn)證服務(wù)端返回的證書。若證書是信任機(jī)構(gòu)簽發(fā)的就會(huì)通過(guò)，若是自己服務(wù)器生成的證書就不會(huì)通過(guò)。

AFSSLPinningModeCertificate

這個(gè)模式表示用證書綁定方式驗(yàn)證證書，需要客戶端保存有服務(wù)端的證書拷貝，這里驗(yàn)證分兩步，第一步驗(yàn)證證書的域名有效期等信息，第二步是對(duì)比服務(wù)端返回的證書跟客戶端返回的是否一致。

AFSSLPinningModePublicKey

這個(gè)模式同樣是用證書綁定方式驗(yàn)證，客戶端要有服務(wù)端的證書拷貝，
只是驗(yàn)證時(shí)只驗(yàn)證證書里的公鑰，不驗(yàn)證證書的有效期等信息。只要公鑰是正確的，就能保證通信不會(huì)被竊聽(tīng)，因?yàn)橹虚g人沒(méi)有私鑰，無(wú)法解開(kāi)通過(guò)公鑰加密的數(shù)據(jù)。

本頁(yè)內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過(guò)網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁(yè)中由涉嫌抄襲的內(nèi)容，請(qǐng)及時(shí)與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會(huì)在5工作日內(nèi)聯(lián)系您，一經(jīng)查實(shí)，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://caipiao93.cn/20465.html