Home » Posts tagged "ec"

把 JavaScript 關閉一個月後的其他感想

一個月前我決定把瀏覽器的 JavaScript 預設關掉:「把 Google Chrome 預設的 JavaScript 關閉,開白名單...」,包括後來「改用 Simple JavaScript Toggle 切換 Google Chrome 的 JavaScript」試著找出快速暫時性切換的方案。

跑了這一個月下來,就好處來說,在一個月前的文章就有提到了,到是遇到不少問題 (然後找到各種方法解掉)。

主要的問題是電子商務網站幾乎都不會動 (包括信用卡刷卡網站),尤其是刷卡階段常用 HTTP POST,沒辦法靠 Simple JavaScript Toggle 在失敗時切過去 (會被刷卡系統偵測到重複送出而擋下),必須設白名單避免問題。

另外是愈來愈多內容性質的網站再沒有 JavaScript 下就不會動,不過這種性質的網站在 Google Chrome 上可以靠 Readability 來解決,還順便把版面給搞定了,不算是什麼大問題。

應該會繼續用下去...

關於 Juniper ScreenOS 防火牆被放後門的研究

一樣是從 Bruce Schneier 那邊看到的:「Details about Juniper's Firewall Backdoor」,原始的研究連結在「Cryptology ePrint Archive: Report 2016/376」這邊。

ScreenOS 被放了兩個後門,一個是 SSH 的後門:

Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker.

另外一個是「Dual EC 的 Q 值」被放了後門,而「NIST 所制定的 Dual EC 的 Q 值」本身就是個後門,所以有人把這個後門又給換掉了:

The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator's output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.

第二個後門更發現嚴重的問題,Juniper 所宣稱的反制措施根本沒被執行到:

In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper's countermeasures against a Dual EC attack are never executed.

也因此團隊確認選定 Q 值的人可以輕易的成功攻擊 IPSec 流量:

Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.

NSA 付錢給 RSA 放後門的事件...

Edward Snowden 再次丟出 NSA 內部文件,表示 NSA 付錢給 RSA 在演算法裡面放後門:「Exclusive: Secret contract tied NSA and security industry pioneer」。

RSA 的回應則是完全不想提到這筆錢是做什麼用的:「RSA Response to Media Claims Regarding NSA Relationship」。

現在一般在猜測,這個後門應該就是 RSA BSAFE 的預設偽隨機數產生器 Dual_EC_DRBG

對於 Dual_EC_DRBG 的攻擊,2006 年的「Cryptanalysis of the Dual Elliptic Curve Pseudorandom Generator」就這樣寫:

Our experimental results and also empirical argument show that the DEC PRG is insecure. The attack does not imply solving the ECDLP for the corresponding elliptic curve. The attack is very efficient.

在 2007 年,Bruce Schneier 寫了一篇「Did NSA Put a Secret Backdoor in New Encryption Standard?」,提到這個弱點並沒有大到使得這個演算法不堪用,但看了總是不爽:

Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn't large enough to make the algorithm unusable -- and Appendix E of the NIST standard describes an optional work-around to avoid the issue -- but it's cause for concern. Cryptographers are a conservative bunch: We don't like to use algorithms that have even a whiff of a problem.

並且建議不要用 Dual_EC_DRBG:

My recommendation, if you're in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.

現在回頭看這件事情... hmmm...

1024bits 的 RSA 與 DH...

看到「Majority of Tor crypto keys could be broken by NSA, researcher says」,說明 NSA 曾經跟 IBM 訂作特殊晶片:

"Everyone seems to agree that if anything, the NSA can break 1024 RSA/DH keys," Graham wrote in a blog post published Friday. "Assuming no 'breakthroughs,' the NSA can spend $1 billion on custom chips that can break such a key in a few hours. We know the NSA builds custom chips, they've got fairly public deals with IBM foundries to build chips."

而目前大多數的 Tor 節點都是用 2.3.x 的版本 (使用 1024bits DHE),官方網站目前也是提供 2.3.x 下載,只有少數使用 2.4.x (使用 ECDHE),不過一時間找不到 ECDHE 用多長的 EC key,所以也不清楚抵抗能力到底到麼程度...

Archives