量子通信技術困境之四：缺失身份認證機製，難以扺禦“中間人攻擊”

量子通信技術困境之四：缺失身份認證機製，難以扺禦“中間人攻擊”

作者：徐令予

網絡名言：“你永遠不知道網絡的對麵是一個人還是一條狗!”

因此要安全通信，首先你得知道對方是誰，其次才是對話內容的保密，否則就等於主動送上秘密，這是常識。

量子通信一直宣稱在分發密鑰中可以保證絕對的私密性，今天就信他們一回，讓我們看看所謂“絕對私密的量子通信”放在真實的通信場境中倒底又是怎麽回事。在量子通信開始時如果甲乙雙方的真實身份無法確認，攻擊者在通信線路中間對甲方冒充乙方，同時對乙方冒充甲方。甲方與攻擊者之間、攻擊者與乙方之間照樣可以順利分發得到二個密鑰，然後甲方把通信內容加密後傳送給了攻擊者，攻擊者用第一個密鑰解密獲得了全部通信內容，然後再把通信內容用第二個密鑰加密後傳送給乙方，乙方用密鑰解密得到通信內容。甲乙雙方還以為依靠量子通信完成了絕對安全的通信，誰知攻擊者在暗處偷笑:量子通信傳遞的秘密“盡入吾彀中矣。”

以上就是典型的“中間人攻擊”實例，由此可知，通信的安全性有著比私密性更高更強的要求，它不僅要求通信雙方傳送的內容不能被任何第三者知道，還要確認收發方各自的真實身份，還必須確認通信內容的完整性和不可篡改性，另外還要保證通信的穩定性和可靠性。

密碼學界通常會用 “CIA ” 來概括通信安全的三要素：Confidentiality 私密性，Integrity 完整性，Availability 可利用性。保護通信安全僅有私密性是遠遠不夠的，脫離通信的完整性和不可篡改性，高談闊論通信的安全性毫無意義。

怎樣才能保證通信的完整性和不可篡改性呢？讓我們看看傳統密碼係統是如何工作的。

• 發信者Bob首次生成公鑰和私鑰，通過互聯網把公鑰上傳到一個公共服務器上；
• Bob對需要送出的文件執行哈希算法，得到哈希值（又稱摘要）；
• Bob使用加密算法生成數字簽名，加密算法的輸入有兩個，一個是私鑰，另一個是被簽署文件的哈希值，輸出的一個字符串就是數字簽名；
• Bob把文件和數字簽名一起通過互聯網遞送給Alice。
• 收信者Alice收到文件和數字簽名，並從公共服務器下載Bob的公鑰；
• Alice使用Bob的公鑰對數字簽名執行解密算法，得到原文的哈希值；
• Alice對收到的文件執行相同的哈希算法得到新的哈希值；
• Alice對比二個哈希值，如果它們完全相同就證明文件確是Bob發出，而且文件傳遞過程中沒有被篡改過[1]。

以上就是Bob把帶有數字簽名的文件傳遞給Alice的全過程。但是這裏存在一個明顯的安全漏洞，因為Alice無法確認下載的公鑰是否真的來自Bob，這就為“中間人攻擊”提供了可能。假設在Bob的文件還沒有到達Alice之前，黑客刪除Bob的文件，然後用他的私鑰簽署一個假文件發送給Alice，黑客又在公共服務器上用他自己的公鑰替換Bob的公鑰。Alice下載了黑客的公鑰，用黑客公鑰驗證黑客的簽名當然不會有問題，她自認為文件就是Bob發出的，其實上當受騙了。這裏的關鍵就在於Alice無法確認收到的公鑰是否確實屬於Bob，數字簽名的本身無法保證文件發送者與公鑰的所有者是同一個人。

要避免中間人攻擊，可以使用數字證書，它的作用就是認證所有人和公鑰的關係。數字證書是一個由可信的第三方發出的一個數字文件，用來證明所有人身份以及所有人擁有某個公鑰。

典型的數字證書中至少包含以下四項內容：第一項是發證機構(CA)的名稱；第二項是所有人姓名，例如Bob；第三項是所有人的公鑰，以及公鑰的有效時期；第四項就是CA的數字簽名。

數字簽名是CA發出的，而CA是有公信力的機構，他們的公鑰是全網皆知。數字證書上同時帶有所有人信息和公鑰，並有CA的數字簽名，隻要用CA的公鑰即可確定證書是否被篡改過。所以隻要信任CA ，就可以信任所有人和公鑰之間的綁定關係。

數字證書就是第三方機構發行的證書，它用自己的信用為數字證書做了背書，主要作用就是證明你的公鑰的確是屬於你的，而公鑰其實就是我們在數字世界的身份，所以說數字證書的作用實際上就是證明你是你自己。

Bob有了自己的數字證書後，當他向網上的公共服務器傳送公鑰時會附上證書。Alice收到證書之後，使用CA的公鑰對證書上CA的數字簽名解密就可鑒定數字證書的完整性和不可篡改性。換言之，Alice有了數字證書就可以確認收到的公鑰是否屬於Bob的，接下來她可以放心使用Bob的公鑰去驗證Bob送來文件上的數字簽名。隻要數字簽名沒問題，就能證明Bob送來的文件是完整而且未被篡改過。

為了加深對數字證書的理解，我們將對HTTPS工作原理作詳細的剖析。HTTPS就是安全的HTTP的意思，這是用在瀏覽器和服務器之間通信的協議。使用HTTPS後，瀏覽器跟服務器之間所有的通信內容都是加密過的。這個過程中的主角就是SSL證書，SSL證書就是用於HTTPS場境中的一種數字證書，它也是由可信的第三方CA 來頒發。隻不過 SSL驗證的不是個人的身份，而是用來驗證服務器身份和它持有的公鑰，目的就是建立瀏覽器和服務器之間的信任。

比如瀏覽器現在要訪問百度服務器。瀏覽器首先要獲取百度服務器的公鑰，為了保證傳遞過來的公鑰確實屬於百度的服務器並且沒有被篡改過，百度需要先去CA機構申請SSL證書，並把它放到自己的服務器上。當瀏覽器中輸入百度的網址，百度服務器會首先給瀏覽器發送SSL證書。因為所有瀏覽器中都內置了全球各大CA機構的公鑰，可以立即驗證SSL上CA的數字簽名。如果證書沒有問題，瀏覽器就可以斷定證書中攜帶過來的公鑰就是百度的。這時候瀏覽器會生成一個隨機數作為對稱加密用的密鑰，然後用百度的公鑰加密後將密文發送給百度服務器。百度服務器收到密文後用自己的私鑰解密得到密鑰。通過這個過程，百度服務器與瀏覽器之間就擁有了共享的密鑰，接下來就可以用對稱加密方式跟瀏覽器通信了。

從上麵分析可知，數字證書其實就是數字簽名的一個特殊應用，它通過具有公信力的第三方的數字簽名把公鑰和公鑰所有人的身份捆綁在一起。通過數字證書和數字簽名的結合使用方能保證文件傳送過程中的不可扺賴性和不可篡改性，徹底杜絕“中間人攻擊”，無此就談不上什麽通信安全。

加密通信和數字簽名用的都是公鑰加密技術。加密通信是用公鑰進行加密，而用私鑰進行解密；而數字簽名剛好相反，是采用私鑰加密，公鑰解密。數字簽名過程跟加密通信有著一定的對稱性，這種對稱性透著一種邏輯的美感。

公鑰加密技術由於巧妙地運用了“公鑰”和“私鑰”這樣一對密鑰，為通信過程中的身份認證和數字簽名提供了靈活有效的解決方案，而使用一個共享密鑰的對稱加密技術是完全無能為力的。雖然理論上對稱加密技術在某些特定場合也可提供身份認證的功能，但是在今天的互聯網通信環境中，使用對稱加密技術作身份認證和數字簽名是不可想像的。

所謂的量子通信(QKD)隻能分發一個共享密鑰，它其實隻是對稱加密技術中的一個子功能，因此QKD完全不具備為互聯網提供切實有效的身份認證和數字簽名的能力。量子通信用物理原理依靠硬件偏麵追求通信的私密性，誤以為通信的私密性就等於通信的安全性（其實QKD在私密性方麵也是有爭議的[2]），從一開始就走入了歧途把自己帶入了深坑中。

因為量子通信缺失身份認證和數字簽名功能，所以量子通信在密鑰分發時為了防禦“中間人”攻擊，在它的量子通道和傳統檢驗通道上都必須依賴傳統密碼的身份認證功能。被吹噓得神乎其神的量子通信其實更像是泥菩薩過河—自身難保，量子通信連自身的安全都難保，竟然奢談為高端客戶提供絕對通信安全，實在令人啼笑皆非。

更可悲的是量子通信這個泥菩薩要過河，傳統密碼技術恐怕也救不了它。因為量子通信QKD分發密鑰是一個時間很長的連續過程，而“中間人攻擊”可能隨時隨地發生，在這種狀況下，無論用何種方法作嚴格的身份認證都是不可完成的任務[3][4]。

2020年3月24日，隸屬於英國情報部門的國家網絡安全中心(NCSC)發布了一份白皮書[5]。該白皮書明確否定了量子通信QKD的實用價值，否定的理由就在“身份認證”這個關鍵問題上，原文照譯如下。

“鑒於QKD在傳統加密密鑰協商機製上需要添置特殊硬件，而且又需要進行額外的身份認證，因此NCSC不讚成在任何政府或軍事機構中使用QKD，並告誡不要在重要的商業通信網絡依賴於QKD，尤其是在關鍵的國家基礎設施領域。”

不愧是老謀深算大英帝國情報機構，他們對密碼係統的評估獨具慧眼值得引起業界高度重視。如果說，QKD的成碼率低效率太差、不能與互聯網兼容、可信中繼站存在嚴重安全隱患這三大技術困境就像三座高不可攀的大山[6]，那麽缺失身份認證機製無法扺禦“中間人攻擊”就是一條深不可測的鴻溝，它們都是量子通信工程化道路上難以逾越的技術障礙。

這裏需要特別強調，QKD所麵臨的這四大技術困境是被物理原理所決定了的，單靠工程技術的進步是極難取得實質性的改變。殘酷的現實是，目前想解決這四大技術困境連紙上方案都沒有，量子通信的工程化不具備最起碼的可行性，盲目建成的量子通信工程項目就不可能有任何經濟效益，幾年來量子通信工程的實踐已經證明了這一切。總之，理論很美妙現實很骨感，美麗的花朵不一定結果的。

[1]本文為了把數字簽名的原理說清楚，文件以明文方式直接傳遞。在許多應用場景中需要對文件加密後傳遞，但是數字簽名的原理和方法是相同的，隻需添加以下幾個步驟即可：

• Bob隨機產生一個加密密鑰，並用此密鑰對要發送的文件進行對稱加密，形成密文； 
• Bob用Alice的公鑰對剛才隨機產生的加密密鑰進行加密，將加密後的密鑰連同密文一起傳送給Alice；
• Alice收到Bob傳送來的密文和加密過的密鑰，先用自己的私鑰對加密的密鑰進行解密，得到Bob隨機產生的加密密鑰；
• Alice然後用隨機密鑰對收到的密文進行解密，得到文件的明文格式，然後將隨機密鑰拋棄；

[2] 量子通信神話之一：量子通信在理論上是無條件安全的

https://zhuanlan.zhihu.com/p/87875706

[3]Actually the agent authentication problem against man-in-the-middle attack has not been dealt with seriously in QKD as far as I know. It is not so simple because one needs re-authentication during protocol execution. How does one get the shared secret key bits for such authentication in an ongoing process? The "practical" QKD people throw in lots of shared key bits, from PRNG also. （摘自 Prof. Horace Yuen 的電子郵件）

[4] In QKD case, if the final key length is of 10^4 bits, they have to carry the QKD process 8x10^6 times. While the 8x10^6 rounds of QKD, Eve can fully obtain the One-Time Pad keys of 10GB. Since these key strings are not IID, it is not independent from segments for the authentication key refreshment as well as the OTP key to hide error-correction in the next round - hence, in the end, the authentication key may be obtained by Eve in such a long process. （摘自 日本三重大學 Takehisa Iwakoshi 教授的電子郵件）

[5]否決量子通信工程 英國情報部門再發白皮書

https://www.ncsc.gov.uk/whitepaper/quantum-security-technologies

[6]量子通信三大技術困境

https://zhuanlan.zhihu.com/p/85323744

https://zhuanlan.zhihu.com/p/85930732

https://zhuanlan.zhihu.com/p/86896032