ARC (Authenticated Received Chain)

標題的 ARC 是指 Authenticated Received Chain,是前陣子在 Hacker News 上看到「Gmail accepts forged YouTube emails (john-millikin.com)」這篇才發現的東西,原文在「Gmail accepts forged YouTube emails」這邊。

作者發現 Gmail 收了從不是直接從 YouTube 發出來的信件:

主要的原因是,Gmail 除了使用標準的 SPFDKIM 判斷外,還吃上面提到的 ARC。

查了一下 ARC,標準是 RFC 8617,目前還是被標成 experimental,主打是解決 forwarding 的問題,看了一下作者群是 LinkedIn (Microsoft)、GoogleValimail

ARC 這東西與之前 Google 在強推的 AMP (然後被罰) 以及現在在推的 Signed HTTP Exchanges 都有相同的味道,無視 security & privacy concern 的東西...

GitHub 的 SSL (HTTPS) 也支援 PFS 與 AE 了...

GitHub 在 2013 年底的公告:「Introducing Forward Secrecy and Authenticated Encryption Ciphers」。

愈來愈多服務升級 & 調整 SSL (HTTPS) 的設定,支援 PFS (Perfect Forward Secrecy) 與 AE (Authenticated Encryption)。

PFS 要預防的事情我可以理解,但對 AE 的必要性不熟啊... 再去看看整個理論基礎與目的好了...

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史,其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章:「Encrypt-then-MAC」,當時 Colin Percival 寫的時候大家還是不能理解,但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD

SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題:對 128bits CBC mode system (像是 aes128-cbc),任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161,論文是「Plaintext Recovery Attacks Against SSH」)

TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠,不過到了 2011 年時才被拿出來示範,也就是 BEAST attack。(CVE-2011-3389,在 ekoparty Security Conference 上的「表演」:「BEAST: Surprising crypto attack against HTTPS」,連結1連結2)

OpenSSLGnuTLS 所實作的 DTLS 在 2011 年也被炸到,其中 OpenSSL 是 100% plaintext recovery,GnuTLS 是 4%。(CVE-2012-0390,論文是「Plaintext-Recovery Attacks Against Datagram TLS」)

而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法,而且被證明 Provable security:Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。

附帶一提,其中 Provable security 這個詞,並非表示「可被證明是安全的」,在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低:以 Encrypt-then-MAC 的例子來說,如果 Encrypt 的部份用 DES,或是 MAC 用 CRC32,那麼 Encrypt-then-MAC 並不會提供更強的安全性...

總而言之,MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode),而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式,有些有專利問題,有些演算法看起來就很複雜 (於是就容易出包),其中 Encrypt-then-MAC 看起來是個還不錯的方案...