IT技術互動交流平臺

讀《圖解密碼技術》:密鑰、隨機數和應用技術

作者:佚名  發布日期:2016-07-25 22:33:18

最后一篇了,如果還沒看過前兩篇的,最好先翻回去看看,因為這最后一篇的內容是建立在前兩篇的基礎之上的。本篇的內容包括密鑰、隨機數、PGP、SSL/TLS,最后再講講密碼技術的現狀和局限性,以及簡單介紹一下量子密碼和量子計算機。
密鑰
在使用對稱密碼、公鑰密碼、消息認證碼、數字簽名等密碼技術時,都需要密鑰。密鑰長度一般不能太短,太短意味著密鑰空間太小,那么,進行暴力破解就很容易。
DES的密鑰長度為56比特(7字節),密鑰空間為2^56,在現有的計算能力下,還是比較容易被暴力破解的。三重DES的DES-EDE3的密 鑰長度為168比特(21字節),是DES的密鑰長度的三倍多,但是密鑰空間可不是三倍這么簡單,DES-EDE3的密鑰空間為2^168,整整是DES 密鑰空間的2^112倍,這么大的密鑰空間,以現有的計算能力,還無法在現實的時間里被暴力破解。AES的密鑰長度則可以從128、192和256比特中 進行選擇,三者的密鑰空間也是不小的。
密鑰和明文其實是等價的,因為對攻擊者來說,得到密鑰就等價于得到明文。
各種不同的密鑰
從前兩篇文章我們就知道,密鑰分很多種類,這里我們做一下整理。
在對稱密碼中,加密和解密使用的是相同的 共享密鑰 。而在公鑰密碼中,加密用的是 公鑰 ,解密用的則是 私鑰 ,相對應的公鑰和私鑰組為 密鑰對 。消息認證碼使用的也是共享密鑰。而數字簽名使用的和公鑰密碼一樣是密鑰對,用私鑰簽名,用公鑰驗證簽名。混合密碼系統中還使用了一次性密鑰,稱為 會話密鑰 。而相對于每次通信都更換的會話密鑰,一直被重復使用的密碼則稱為 主密鑰 。用于加密內容的密鑰稱為CEK (Contents Encrypting Key,內容加密密鑰);相對地,用于加密密鑰的密鑰則稱為 KEK (Key Encrypting Key,密鑰加密密鑰)。CEK 和 KEK 的用法可以如下圖所示:

在很多情況下,會話密鑰都是被作為 CEK 使用的,而主密鑰則是被作為 KEK 使用的。
密鑰的管理
生成密鑰最好的方法就是使用真正的隨機數,因為密鑰需要具備不可預測性。不過,一般我們都是使用偽隨機數生成器來生成密鑰。另外,密碼學用途的偽隨機數生成器必須是專門針對密碼學用途而設計的。畢竟,生成偽隨機數的算法很多,但有些并不具備不可預測性。
有時我們也會使用容易記住的 口令 (password 或 passphrase)來生成密鑰。passphrase 指的是一種由多個單詞組成的較長的 passwrod,在此將兩者統稱為口令。嚴格來說,很少直接用口令來作為密鑰使用,一般都是將口令輸入單向散列函數,然后將得到的散列值作為密鑰使用。 而在使用口令生成密鑰時,為了防止字典攻擊,需要在口令上面附加一串稱為 鹽 (salt)的隨機數,然后再將其輸入單向散列函數。這種方法稱為“基于口令的密碼”(Password Based Encryption, PBE)。關于 PBE 稍后再詳細介紹。
對于共享密鑰,就會存在密鑰配送問題。在密碼篇就提到幾種解決方案: 事先共享密鑰 、 使用密鑰分配中心 、 使用公鑰密碼 、 Diffie-Hellman密鑰交換 。關于Diffie-Hellman密鑰交換的原理,之前的文章沒講,在本篇稍后會詳細介紹。
為了提高通信的機密性,還可以采用 密鑰更新 (key updating)的方法。這種方法就是在使用共享密鑰進行通信的過程中,定期改變密鑰。例如,在更新密鑰時,發送者和接收者使用單向散列函數計算當前密鑰的散列值,并將這個散列值用作新的密鑰。簡單說,就是 用當前密鑰的散列值作為下一個密鑰 。
除了只使用一次的會話密鑰,其他密鑰基本都需要考慮 保存密鑰 的問題。尤其對于共享密鑰來說,很多應用都需要將密鑰保存在客戶端,例如移動App,要么將密鑰硬編碼在代碼里,或者保存在文件中,但無論哪種方式,應用一旦被反編譯,密鑰就存在泄漏的風險。以防密鑰被盜,可以使用 將密鑰加密后保存 的方法。但要將密鑰加密,必然需要另一個密鑰,即 KEK。那么,KEK 又如何保存?這問題還真不好解決。不過,對密鑰進行加密的方法卻可以 減少需要保管的密鑰數量 。比如,假設平臺系統接入了10萬個應用,每個應用都有一個自己的密鑰,即系統需要保管10萬個密鑰。那么,用 KEK 對這10萬個密鑰進行加密,這樣的話只要保管這一個 KEK 就可以了。即是說,不需要確保多個密鑰(CEK)的機密性,而只需要確保一個密鑰(KEK)的機密性就可以了。這和認證機構的層級化非常相似。在后者中, 我們不需要信任多個認證機構,而只需要信任一個根 CA 就可以了。
Diffie-Hellman密鑰交換
通過Diffie-Hellman密鑰交換算法,通信雙方僅通過交換一些可以公開的信息就能夠生成出共享的秘密數字,而這一秘密數字就可以被用作 對稱密碼的密鑰。雖然這種方法名字叫“密鑰交換”,但實際上雙方并沒有真正交換密鑰,而是通過計算生成出了一個相同的共享密鑰。因此,這種方法也稱為** Diffie-Hellman密鑰協商**。
Diffie-Hellman密鑰交換的步驟如下:

Alice 向 Bob 發送兩個質數 P 和 G
P 必須是一個非常大的質數,而 G 則是一個和 P 相關的數,稱為 生成元 (generator)。G 可以是一個較小的數字。
Alice 生成一個隨機數 A
A 是一個 1 ~ P-2 之間的整數。這個數是一個只有 Alice 知道的秘密數字。
Bob 生成一個隨機數 B
B 也是一個 1 ~ P-2 之間的整數。這個數是一個只有 Bob 才知道的秘密數字。
Alice 將 G^A mod P 計算結果的數發送給 Bob
Bob 將 G^B mod P 計算結果的數發送給 Alice
Alice 用 Bob 發過來的數計算 A 次方并求 mod P
這個數就是共享密鑰。Alice 計算的密鑰 = (G^B mod P)^A mod P = G^(A*B) mod P
Bob 用 Alice 發過來的數計算 B 次方并求 mod P
Bob 計算的密鑰 = (G^A mod P)^B mod P = G^(A*B) mod P = Alice 計算的密鑰。可見兩方計算的密鑰是相等的。

關于第1步提到的生成元是什么呢?先來看一張表,假設 P = 13:

其中,2、6、7、11都是13的生成元。這幾個數有什么性質呢?從上表可以發現,這幾個數的乘方結果中都出現了1~12的全部整數。也就是 說,P 的生成元的乘方結果與 1 ~ P-1 中的數字是一一對應的。正是因為具有這樣一一對應的關系,Alice 才能夠從 1 ~ P-2 的范圍中隨機選擇一個數字(之所以不能選擇 P-1,是因為 G^(P-1) mod P 的值一定是等于1的)。
最后,需要清楚,針對Diffie-Hellman密鑰交換是可以發動中間人攻擊的。而為了防止中間人攻擊,可以使用數字簽名、證書等方法來應對。
基于口令的密碼(PBE)
基于口令的密碼(Password Based Encryption,PBE)就是一種根據口令生成密鑰并用該密鑰進行加密的方法。
PBE 的加密可以用下圖來表示:

主要有三個步驟:
生成 KEK
首先,通過偽隨機數生成器生成一個被稱為 鹽 (salt)的隨機數。然后,將鹽和口令一起輸入單向散列函數,輸出的結果就是 KEK。鹽是一種用于防御字典攻擊的機制。
生成會話密鑰并加密
會話密鑰 CEK 也是通過偽隨機數生成器來生成,生成之后使用 KEK 對其進行加密,然后將加密后的會話密鑰和鹽一起保存在安全的地方。
加密消息
最后,使用 CEK 對消息進行加密。
而 PBE 解密的過程則如下圖:

解密主要也是有三個步驟:
重建KEK
將之前保存下來的鹽和口令一起輸入單向散列函數,得到的散列值就是 KEK 了。
解密會話密鑰
再將之前保存下來的已加密的會話密鑰用 KEK 進行解密,就能得到會話密鑰 CEK 了。
解密消息
最后,用已解密的 CEK 對密文進行解密即可。
另外,在生成 KEK 時,通過多次使用單向散列函數可以提高安全性。
隨機數
有哪些場景使用到隨機數呢?主要可能有以下這些:
生成密鑰
生成密鑰對
生成初始化向量(IV)
生成nonce
生成鹽
隨機數的性質主要分為三類:
隨機性 :不存在統計學偏差,是完全雜亂的數列。
不可預測性 :不能從過去的數列推測出下一個出現的數。
不可重現性 :除非將數列本身保存下來,否則不能重現相同的數列。
上面三個性質中,越往下就越嚴格。具備隨機性,不代表一定具備不可預測性。具備不可預測性的數列,則一定具備隨機性。具備不可重現性的數列,也一定具備不可預測性和隨機性。在書中,將這三個性質的隨機數按順序分別命名為“弱偽隨機數”、“強偽隨機數”和“真隨機數”。
偽隨機數生成器
隨機數可以通過硬件來生成,也可以通過軟件來生成。通過硬件生成的隨機數列一般都是真隨機數,是從不可重現的物理現象中獲取信息而生成數列的,比如周圍的溫度和聲音的變化、用戶移動鼠標的位置信息、鍵盤輸入的時間間隔、放射線測量儀的輸出值等。像這樣的硬件設備稱為 隨機數生成器 (Random Number Generator,RNG)。而生成隨機數的軟件則稱為 偽隨機數生成器 (Pseudo Random Number Generator,PRNG)。因為僅靠軟件無法生成真隨機數,因為要加上一個“偽”字。
偽隨機數生成器具有“內部狀態”,并根據外部輸入的“種子”來生成偽隨機數列,如下圖:

偽隨機數生成器的 內部狀態 ,是指偽隨機數生成器所管理的內存中的數值。這個數值在每次生成隨機數后都會改變。而 種子 是用來初始化內部狀態的。偽隨機數生成器是公開的,但種子是需要保密的,這就好像密碼算法是公開的,但密鑰是保密的。
具體的偽隨機數生成器
具體的偽隨機數生成器有很多,書中介紹了五種:雜亂的方法、線性同余法、單向散列函數法、密碼法、ANSI X9.17。
雜亂的方法
雜亂的方法就是使用雜亂無章的算法來生成隨機數,但這種方法其實并不可取。一是因為復雜算法所生成的數列大多數具有很短的周期(即短數列的不斷重復);二是因為如果程序員不能夠理解算法的詳細內容,那么就無法判斷所生成的隨機數是否具備不可預測性。
線性同余法
線性同余法就是將當前的偽隨機數值乘以 A 再加上 C,然后將除以 M 得到的余數作為下一個偽隨機數。其中,A、C、M都是常量,且 A 和 C 需要小于 M。C 語言的庫函數 rand,以及Java 的 Random 類,都采用了線性同余法。線性同余法并不具備不可預測性,因此不可以用于密碼技術。

單向散列函數法
使用單向散列函數可以編寫出具備不可預測性的偽隨機數列(即強偽隨機數)的偽隨機數生成器。單向散列函數的單向性是支撐偽隨機數生成器不可預測性的基礎。

密碼法
也可以使用密碼來編寫能夠生成強偽隨機數的偽隨機數生成器。既可以使用 AES 等對稱密碼,也可以使用 RSA 等公鑰密碼。密碼的機密性是支撐偽隨機數生成器不可預測性的基礎。

 


ANSI X9.17
ANSI X9.17 偽隨機數生成器的結構則有點復雜,PGP 密碼軟件就使用了這種方法。

PGP
PGP 將多種密碼技術進行了完美的組合,其具備了現代密碼軟件所必需的幾乎全部功能,包括但不限于:對稱密碼、公鑰密碼、數字簽名、單向散列函數、證書、壓縮、大文件的拆分和拼合、鑰匙串管理等。
生成密鑰對
要在 PGP 中進行加密和數字簽名,需要先生成自己的密鑰對。下圖展示了從命令行生成密鑰的過程,其中,粗體為用戶輸入的內容:

加密和解密
使用 PGP 進行加密的過程如下圖所示:

而解密的過程則如下:

PGP 的私鑰是保存在用戶的鑰匙串中的。另外,私鑰都是以加密狀態保存的,并在保存時使用了基于口令的密碼(PBE)。
生成和驗證數字簽名
生成數字簽名的過程如下圖:

而驗證簽名的過程則如下圖:

生成數字簽名并加密以及解密并驗證數字簽名
如何將密碼和數字簽名進行組合,下面兩張圖是整本書最復雜的,但它只不過是將之前講解的內容組合起來了而已。
下圖是生成數字簽名并加密的過程:

而下圖則是解密并驗證數字簽名的過程:

信任網
如何確認公鑰的合法性?前面介紹的證書是一種方法。對公鑰的信任是建立在對認證機構的信任的基礎之上的。不過,PGP 卻沒有使用認證機構,而是采用了一種叫做 信任網 (也稱為 信任圈 或 好友圈 )的方法。信任網的要點是“不依賴認證機構,而是建立每個人之間的信任關系”。換言之,就是能夠自己決定要信任哪些公鑰。
PGP 當初的設計目的是在連國家都不可信的情況下依然能夠使用,因此它并不關心有沒有可信的認證機構,而是采用了“由用戶自己來決定信任誰”這樣的設計。
需要注意,“公鑰是否合法”與“所有者是否可信”是兩個不同的問題,因為盡管公鑰合法,其所有者也可以是不可信的。例如,Alice認為從Bob 那獲得的公鑰是合法的,因為這個公鑰是Bob當面交給Alice的。但是Alice不信任Bob在數字簽名上的判斷能力,即便Bob對其他的公鑰進行了數 字簽名,Alice也會懷疑Bob是否真的進行了本人確認。
在 PGP 中,信任級別可以分為四種:絕對信任、完全信任、有限信任和不信任。
SSL/TLS
SSL/TLS也是綜合運用了對稱密碼、公鑰密碼、消息認證碼、數字簽名、偽隨機數生成器等密碼技術。而我們知道SSL/TLS最廣泛的應用就是 套接在HTTP上,但實際上,SSL/TLS還可以套接在其他網絡協議之上的,例如,SMTP 和 POP3 之類的電子郵件協議。因為現在廣泛使用的是TLS協議,因此下文只以TLS協議為主。
TLS安全協議可分為兩層: TLS記錄協議 和 TLS握手協議 。TLS記錄協議在TLS握手協議的下層,負責數據封裝、壓縮、加密等功能。而TLS握手協議則用于在實際的數據傳輸開始前,通信雙方進行身份認證、協商 加密算法、交換密鑰等。TLS握手協議又分為4個子協議:握手協議、密碼規格變更協議、警告協議和應用數據協議。TLS協議的層次結構如下圖:

TLS記錄協議
TLS記錄協議的處理過程如下圖:

首先,消息被分割成多個片段,然后分別對每個片段進行壓縮。壓縮算法需要與通信對象協商決定。接下來,經過壓縮的片段會被加上消息認證碼,這就 可以保證完整性,并進行數據的認證。同時,為了防止重放攻擊,在計算消息認證碼時,還加上了片段的編號。單向散列函數的算法,以及消息認證碼所使用的密鑰 都需要與通信對象協商決定。再接下來,就是加密了。加密使用CBC模式,CBC模式的初始化向量(IV)通過主密碼生成,而對稱密碼的算法和共享密鑰也是 需要與通信對象協商決定。最后,密文再加上數據類型、版本號、壓縮后的長度組成的報頭就是最終的報文數據。其中,數據類型為TLS握手協議中的4個子協議 之一。

 

TLS握手協議
TLS握手協議可分為4個子協議,其中, 握手協議 是最復雜的一個子協議,其過程如下圖:

1. ClientHello(客戶端->服務器)
客戶端向服務器發送ClientHello消息,消息內容主要包括:可用的版本號、當前時間、客戶端隨機數、會話ID、可用的密碼套件清單、可用的壓縮方式清單。
2. ServerHello(服務器->客戶端)
對于客戶端發送的ClientHello消息,服務器會返回一個ServerHello消息,消息內容主要包括:使用的版本號、當前時間、服務器隨機數、會話ID、使用的密碼套件、使用的壓縮方式。這一步確定了通信中使用的“版本號”、“密碼套件”和“壓縮方式”。
3. Certificate(服務器->客戶端)
服務器再向客戶端發送Certificate消息,主要是 證書清單 。首先發送的是服務器的證書,然后會按順序發送對服務器證書簽名的認證機構的證書。
4. ServerKeyExchange(服務器->客戶端)
當Certificate消息不足以滿足需求時,服務器會向客戶端發送ServerKeyExchange消息。具體所發送的消息內容會根據所使用的密碼套件而有所不同。
5. CertificateRequest(服務器->客戶端)
CertificateRequest消息用于服務器向客戶端請求證書,這是為了進行 客戶端認證 。消息內容還包括:服務器能夠理解的證書類型清單和認證機構名稱清單。當不使用客戶端認證時,不會發送CertificateRequest消息。
6. ServerHelloDone(服務器->客戶端)
服務器發送ServerHelloDone消息則表示從ServerHello消息開始的一系列消息的結束。
7. Certificate(客戶端->服務器)
當服務器發送了CertificateRequest消息時,則客戶端會發送Certificate消息,將自己的證書同消息一起發送給服務器。如果服務器沒有發送CertificateRequest消息,客戶端則不會發送Certificate消息。
8. ClientKeyExchange(客戶端->服務器)
客戶端發送ClientKeyExchange消息。當密碼套件中保護RSA時,會隨消息一起發送 經過加密的預備主密碼 。當密碼套件中包含Diffie-Hellman密鑰交換時,會隨消息一起發送 Diffie-Hellman的公開值 。預備主密碼是由客戶端生成的隨機數,之后會被用作生成主密碼的種子。根據預備主密碼,服務器和客戶端會計算出相同的 主密碼 ,然后再根據主密碼生成:對稱密碼的密鑰、消息認證碼的密鑰、對稱密碼的CBC模式中使用的初始化向量(IV)。
9. CertificateVerify(客戶端->服務器)
客戶端只有在服務器發送CertificateRequest消息時才會發送CertificateVerify消息。這個消息的目的是向服務 器證明自己的確持有客戶端證書的私鑰。為了實現這一目的,客戶端會計算“主密碼”和“握手協議中傳送的消息”的散列值,并加上自己的數字簽名后發送給服務 器。
10. ChangeCipherSpec(客戶端->服務器)
客戶端發送ChangeCipherSpec消息表示要切換密碼。實際上,這不是握手協議的消息,而是密碼規格變更協議的消息。在 ChangeCipherSpec消息之前,客戶端和服務器之間以及交換了所有關于密碼套件的信息,因此在收到這一消息時,客戶端和服務器會同時切換密 碼。在這一消息之后,TLS記錄協議就開始使用雙方協商決定的密碼通信方式了。
11. Finished(客戶端->服務器)
客戶端發送Finished消息表示握手協議到此結束。這個消息其實是使用切換后的密碼套件來發送的。實際負責加密操作的是TLS記錄協議。
12. ChangeCipherSpec(服務器->客戶端)
這次輪到服務器發送ChangeCipherSpec消息了,表明服務器要切換密碼了。
13. Finished(服務器->客戶端)
服務器也同樣發送Finished消息表明握手協議到此結束。這個消息同樣使用切換后的密碼套件來發送。實際負責加密操作的也是TLS記錄協議。
14. 切換至應用數據協議
在此之后,客戶端和服務器會使用應用數據協議和TLS記錄協議進行密碼通信。
從結果來看,握手協議完成了下列操作:
客戶端獲得了服務器的合法公鑰,完成了服務器認證。
服務器獲得了客戶端的合法公鑰,完成了客戶端認證(當需要客戶端認證時)。
客戶端和服務器生成了密碼通信中使用的共享密鑰。
客戶端和服務器生成了消息認證碼中使用的共享密鑰。
除了握手協議,其他3各子協議都很簡單。 密碼規格變更協議 用于密碼切換的同步。簡單地說,就跟向對方喊“1、2、3!”差不多。當協議中途發生錯誤時,就會通過警告協議傳達給對方。 警告協議 負責在發生錯誤時將錯誤傳達給對方。如果沒有發生錯誤,則會使用應用數據協議來進行通信。 應用數據協議 用于和通信對象之間傳送應用數據。當TLS套接在HTTP時,HTTP的請求和相應就會通過TLS的應用數據協議和TLS記錄協議來進行傳送。
密碼技術與現實社會
前面講到的6種基本的密碼技術可整理成下圖:

書中多次使用了 框架 這個說法。框架的特點就是能夠對其中作為組成元素的技術進行替換,就像更好零件一樣。例如,消息認證碼算法HMAC的設計就允許對單向散列函數的算法進行 替換。在PGP中,對稱密碼、公鑰密碼、單向散列函數等都是可以替換的。在SSL/TLS中,客戶端和服務器可以通過握手協議進行通信,并當場決定所使用 的密碼套件。使用框架能夠提高密碼技術系統的重用性,也能夠提高系統的強度。通過將單獨的密碼技術像零件一樣組合起來,并根據需要進行替換,能夠實現更長 期的、更高的安全性。
另外,所有密碼技術其實也可以看成是一種“壓縮技術”,如下表所示:

 


量子密碼和量子計算機
量子密碼是基于量子理論的通信技術,是一種讓通信本身不可竊聽的技術,也可以理解為是一種利用光子的量子特性來實現通信的方法。最早的量子密碼中,利用了兩個事實:
1. 從原理上說,無法準確測出光子的偏振方向
根據這一事實,可以讓竊聽者得到的內容變得不正確。
2. 測量行為本身會導致光子的狀態發送改變
根據這一事實,接收者可以判斷出通信是否被竊聽。
而 量子計算機 則有著超強的計算能力。如果有了量子計算機,那現有的所有密碼都能夠瞬間被暴力破解。根據量子理論,粒子可同時具有多種狀態。如果使用具有多種狀態的粒子 進行計算,則可以同時完成多種狀態的計算。如果用1個粒子能夠計算0和1兩種狀態,那么用128個這樣的粒子就可以同時計算2^128中狀態。換句話說, 就是一臺超級并行計算機。
如果量子密碼比量子計算機先進入實用領域,則可以使用量子密碼來實現一次性密碼本,從而產生完美的密碼技術。由于一次性密碼本在原理上是無法破譯 的,因此即使用量子計算機也無法破譯量子密碼。然而,如果量子計算機比量子密碼先進入實用領域,則實用目前的密碼技術所產生的密文將會全部被破譯。
只有完美的密碼,沒有完美的人
就算量子密碼進入實用領域,也不能實現完美的安全。因為在安全問題中,密碼技術能夠覆蓋的范圍是非常有限的。在確保系統的整體安全方面,人是一個特別巨大的弱點。
為了配送對稱密碼的密鑰,我們需要使用公鑰密碼,而為了對公鑰進行認證,我們又需要認證機構的公鑰。以此類推,無窮無盡,我們必須在某個節點上找到一個公鑰是自己能夠完全信任的,也就是必須要有一個信任的種子。
通過密碼技術,我們可以提高機密性,也能夠讓認證變得更加容易,但是這并不意味著我們可以實現完美的機密性和完美的認證。
就算通過人的指紋、聲紋、面容識別等生物識別認證也并不是完美的認證。要進行生物識別認證,就必須在某個時間點上將生物信息轉換為比特序列,而實際的認證則是通過轉換后的比特序列來完成的。因此,如果這些比特序列被竊取,就會和鑰匙被偷產生相同的后果。
另外,“防御必須天衣無縫,攻擊只需突破一點”。為了保衛系統安全,我們必須應對各種可能的攻擊,而且這種防御必須24小時連續工作。另一方面,要攻擊一個系統,則只要找到一種有效的攻擊方法,而且只需利用防御方一瞬間的破綻就可以完成了。
寫在最后
其實,在實際應用中,安全問題所涉及的技術,遠比這本書里所講到的密碼技術多得多,也復雜得多。例如,App的加殼保護、OAuth認證等。在實 際的應用中,還需要考慮更多,比如,安全性和性能之間需要平衡。雖然,懂得了這些密碼技術,并不意味著就能設計出非常安全的系統。但是,如果不懂這些密碼 技術,那就更難以設計出安全的系統。
 

延伸閱讀:

Tag標簽: 隨機數   密鑰   應用技術  
  • 專題推薦

About IT165 - 廣告服務 - 隱私聲明 - 版權申明 - 免責條款 - 網站地圖 - 網友投稿 - 聯系方式
本站內容來自于互聯網,僅供用于網絡技術學習,學習中請遵循相關法律法規
香港最快开奖现场直播结果