【密碼學】 目標最安全的端對端加密

記得十多年前台灣有個社交平台叫做『無名小站』。它是那個年代的FB、IG、抖音。年輕人喜歡在上面分享生活、祕密，甚至是私密照片。

即使是現在，你用「無名」、「流出」兩個關鍵字仍然可以找到一堆結果。在無名小站分享私密照片給朋友，需要將相簿設為私密，並且設定一組密碼，然後將密碼交給朋友。只有知道密碼的朋友可以閱讀私密訊息或是私房照片。

然而，除了密碼被惡意"友人"亂傳密碼，當年也是跨站腳本攻擊（XSS）的黃金成長期，各路駭客發明了各種攻擊手法偷取密碼，這對於一般大眾而言根本防不勝防。結果密碼外洩事件頻傳，無數的私密照片外流。

當時的我很意外，大家為什麼就這麼相信這個平台？就算沒有駭客攻擊你的私密資訊、就算沒有人亂傳你的密碼，你就不會擔心這個平台的工程師會不會進後台查閱你的私密資訊？

這類服務通常在使用者協議裡面寫：我們絕對不會偷看你的資料。不然就是寫：我們不保證你的資料不會被我們偷看，使用本服務表示接受我們偷看，不要用我們的服務是你的事。若你接受後者，那只能說是你自願或是沒注意使用者協議。然而，就算是前者的協議...你難道真的百分之百相信他嗎？你可曾想過，資料放在人家那，他看不看你怎麼監督？

在資訊安全越來越受重視的現在，就算有白紙黑字的合約，對資訊從業人員來說仍然不夠。因為我們所處理的資料可能十分重要，重要到人家違約了也有賺頭。

人們對資訊系統的期待是必須做到讓人想違約也違不了。

加密是保護祕密的主要的手段。

我們在使用許多服務時，服務提供商經常會說他們的連線經過加密，只有通訊的雙方可以讀懂內容。比如現在各位在「方格子」閱讀的時候，是否有注意到網址是https開頭？最早的協議，大多是http。而https多出來的s指的是「Secure」也就是安全的意思。哪裡安全？直白的說就是加密啦。https的通訊表示你閱讀網站的內容時，只有你和該網站之間能讀懂內容。任何在中途看到訊息封包的人都只會看到一組加了密的亂碼（嚴格來說，只有內容加密，收/送方的地址沒有加密，不然送訊息的郵差是無法送信的喔XD）。

各位可能感受不到為什麼讀方格子的廢文也要加密（好啦，只有我的比較廢）。其實，加密這個動作也可以確保完整性，也就是說能保證內容不會被人竄改。打個比方，假如您在讀小弟的廢文時封包經過駭客的網站設備（比如在宿舍用學校的網路，訊息會先到學校的機房，才到你的宿舍房間，而駭客躲在學校機房作怪）。此時這位駭客突然駭性大發，把封包的內容改成了非常有營養的《論語》。那麼看到《論語》的你，不就會覺得小弟的文章都非常極品？又比如你在使用某個網路銀行轉帳。駭客截獲你的訊息後，把收款帳號改成自己的帳號，接著再把訊息還給網路銀行。若是網路銀行無法偵測出竄改行為的話，錢錢就進了駭客的口袋。

前幾年發生了一個事件，讓我們發現光是加密還不夠用。那就是美國的FBI以反恐為名義，要求Apple破解疑似恐怖份子的iPhone。雖然是正義之名，但是Apple沒有接受。理由大致就兩個方向。首先，Apple一直打著重視使用者隱私的招牌（與Google和FB分庭抗禮），如果幫FBI的話就自打嘴巴了；另一方面，如果Apple能幫FBI解開的話，也等於承認Apple在自己的產品裡裝了後門（或許也真的沒有）。總而言之，Apple沒幫這個忙。但是美國可沒放過Apple，甚至想用公權力要求Apple必須要在手機裡加裝後門以備政府單位的不時之需。美國的這個法令應該是沒有生效。至少台面上是沒有。Apple領教到國家機器的可怕，為了避免政府死纏爛打，便設計出自己真的無法破解的技術來讓政府死了心。

不止是Apple有這方面的挑戰。一般網路服務業者也有。

上面提到我們已經用https來保護通訊的內容了。然而，這門技術說穿了就是在收發的兩端協議出一把會議金鑰（session key）。而這個協議很大的呈度是依賴server端的金鑰。若是哪天國家機器要求業者交出server端的金鑰。那麼就算https的通訊內容加了密，在政府面前也是赤裸裸的。

在小說《1984》裡有一位監控著全民的『老大哥』。我本身沒有看過這部小說，但故事中那句『老大哥在看著你』不正是嚮往自由的我們的夢靨？

為了要避免金鑰失竊或是被『老大哥』拿去用。資訊科學家設計了『前向安全』（Forward Secrecy）的技術以確保金鑰失竊前的訊息不會被解回來。原理很簡單，就是在協議金鑰時加入一次性使用的數值，這個數值用完就丟，也不記錄。只要這個數值搞不回來，就算拿到了server端的金鑰也極難算出當初的那把會議金鑰。當然，金鑰遺失後後的資訊就會被老大哥偷看了；不過我們通常都假定老大哥想看的是過去發送過的訊息。要保護後續的資訊，只要在金鑰交出去後跟大眾說明金鑰遺失了或是說明它在老大哥的手上，然後大眾要不要繼續用就是大眾自己的事了。

如此，我們算是設計了完美的私密溝通管道，解決了所有外部偷看的風險。是時候回到內部的風險了。

上面提到的技術可以接近完美的保護client-server架構的服務。但是現在的應用很複雜。Server有時只扮演中間人的角色，而你真正要溝通的對象是另一位使用者。是的，比如LINE、WhatsApp、Messager等應用，你想要溝通祕密的對象不是LINE也不是FB，而是他們的另一位用戶。

服務供應商(比如上述LINE或FB)一定會用加密通道保護你傳送的訊息，避免外面不相關的人士偷看。但供應商也在這個系統裡，雖然是通訊雙方的外人，卻是實現服務的局內人。

這時又回到了老問題。你是否擔心供應商偷看你和你的交談對象的訊息？他們當然說不會，但你怎麼確認？如何自保？

本篇的主角登場了。我們的救星就是端對端加密。

端對端加密的英文是end-to-end encryption。其中End指的是終端設備。講白了就是你的手機或電腦。它做的就是提供一個加密技術，讓訊息即使在多方傳輸，也只有通訊的兩個終端能解。其原理就是讓兩個終端自己去協議一把會議金鑰。

超完美對吧？但是資訊科學家很龜毛，他們幫我們問了兩個問題：

話先說在前頭。小弟沒有業配。

通訊應用裡的Telegram和Signal有為他們的服務回答這個問題。他們將自己的程式碼公開在網路上，讓有興趣研究的人們可以逕自確認。

雖然你會懷疑放上去的程式和實際使用的程式可能不同。但驗證這點對研究人員來說太容易了。只要將實際的程式反編譯，弄回程式碼再比對就好。當然，研究人員夠屌的話也可以在沒有程式碼的情況下直接確認，只不過反編譯回來的程式在沒有引導的情況下會比較難閱讀，要花更多時間確認。

接下來，第二個問題是：如何確保我們使用的端對端加密沒有被入侵？如果攻擊者(或甚至是服務供應商自己)擋在收送兩端的中間，仍然有機會入侵這個通道。中間人攻擊是一種通用的攻擊概念。當攻擊者作為中間人的時候，他很可能能取得兩端的信任，從而不知不覺的偷聽。

比如A要透過E和B通訊。A原本設想，只要和B建立一個具備端對端加密的連線就一切ok了。然而E收到訊息時，沒有讓A與B建立端對端連線，反而是讓A與自己(E)建立端對端連線。然後E再假裝成A，去和B建立端對端連線。如此一來，A以為的A to B實際上是A to E to B。而A與B可能渾然不知。

想避免這個問題，必須要讓A和B能驗證這個通道的加密金鑰有用對方生成的參數來建立！

先回過頭去談https。https怎麼避免中間人攻擊呢？答案是我們的瀏覽器會去效驗Server端使用的金鑰是否經過合法的機構認證。而合法機構的認證資訊早在你的手機出場時，或電腦安裝完作業系統時就預先裝上了。各位可以搜尋「憑證」、「Android」或「憑證」、「Windows 11」(或任何作業系統)來查詢怎麼檢示預裝的認證資訊。

https這招對瀏覽器來說已經很足夠了。但是像Telegram這類應用，似乎只讓A的app與B的app相互驗證還是不能滿足質疑者。他們會說：app亂驗怎麼辦？或是：app也參與了偷聽怎麼辦？

為此，Telegram除了前面提到的將程式碼公開外，又設計了一個機制讓使用者(A與B)能自己完成驗證。

下圖是Telegram的Secret Chat語音通話畫面。右上角那些怪怪圖示可不是放火氣大的。它們其實是從會議金鑰轉換出來的圖示。

當A與B通話時，他們可以先在對話中確認彼此螢幕上的圖示是否一致，甚至可以在確認時自帶暗語，比如上面的例子A可能跟B說「強國、海豚、水行俠、耳機」。若是發現圖示不同就表示會議金鑰不一致，通話的管道被人換過了金鑰！而我會提到用暗語的原因是現在有語音合成的技術，如果駭客直的很高端，他有可能遮掉A向B確認圖示的語音，然後換上自己合成的語音來欺A與B。若是通訊的雙方有互通的暗語，就等於和雙方的大腦協議了一把金鑰，能用來做進一步的保護。

現在的人們愈來愈重視自己的隱私，端對端加密的需求應該會愈來愈多。然而，這門技術卻沒有成為標準配備。

有一位網友整理了歐美常見的通訊軟體的隱私保護設計。你可以看到即使是大廠(Google、FB之流)也被他列得滿江紅。為什麼會這個樣子呢？因為法令對隱私保護的要求非常低標。端對端加密不是必須要提供的功能，所以就算不實作也不會被處罰。更何況...以陰謀論的角度來看，或許大廠和政府因為某些理由而壓根不希望有太完美的端對端加密。像是中國就直接ban掉了Telegram和Signal。

雖然法令不要求，但是上面提到的Telegram靠著端對端加密的噱頭衝上了許多國家前幾名的下載量。因此從市場層面來看這門技術還是有機會成為趨勢。而當它成為標配時，我想大廠也是順手就做出來了吧XD