ROCA:Infineon Technologies 的 RSA 實做問題

最近的另外一個大包,不過這包是 Infineon Technologies 在實做 RSA 算法時的問題,倒不是 RSA 算法本身有問題。之所以會「大」是因為有太多人用了:「ROCA: Vulnerable RSA generation (CVE-2017-15361)」。

起因於 Infineon Technologies 在產生 key 時的組合有限,於是要猜測的 keyspace 小很多。

以研究者的估算,可以看出 CPU year 都被大幅減少了,都是屬於「可行」的範圍:

The time complexity and cost for the selected key lengths (Intel E5-2650 v3@3GHz Q2/2014):

512 bit RSA keys - 2 CPU hours (the cost of $0.06);
1024 bit RSA keys – 97 CPU days (the cost of $40-$80);
2048 bit RSA keys – 140.8 CPU years, (the cost of $20,000 - $40,000).

而且這邊是用 CPU year 估算,如果考慮 FPGA 加速計算,應該會短更多...

另外從發現到公開的時間線也拉得很長,可以看到中間一直在找解決方案:

2nd of November 2017 - Presentation of all details at the ACM CCS conference (to come)
16th of October 2017 - The initial version of the public disclosure published
May to October 2017 - Cooperation with the manufacturer and other affected parties to help evaluate and mitigate the vulnerability
1st of February - The vulnerability disclosed to Infineon Technologies AG
End of January - The vulnerability found

過一陣子就會去 conference 上報告了...

伊朗透過 BGP 管制網路的手段影響其他國家網路...

Dyn (之前被 DDoS 打爆,過一陣子被 Oracle 買去的那個 Dyn) 的這篇「Iran Leaks Censorship via BGP Hijacks」講到他們偵測到伊朗透過 BGP hijack 管制網站的問題。

前陣子伊朗透過 private ASN 放了 99.192.226.0/24 出來,影響到其他國家:

Last week, Iranian state telecom announced a BGP hijack of address space (99.192.226.0/24) hosting numerous pornographic websites.

由於這段 IP address 在 internet 上是以 99.192.128.0/17 在放,就因為 /24 優先權比較高而被蓋過去影響到全世界...

然後過了幾天,開始攻擊蘋果的 iTunes 服務,不過這次是以 /32 放出來。由於大多數收的最小單位是 /24,這次的影響沒有上次大:

In addition, TIC announced BGP hijacks for 20 individual IPs associated with Apple’s iTunes service. These too were carried by Omantel to the outside world, albeit with a smaller footprint due to the fact that BGP routes for /32’s typically don’t propagate very far.

這看得出來 routing 在 internet 上還是非常脆弱...

信用卡的先天缺陷造成盜刷問題

在「Guessing Credit Card Security Details」這邊看到的攻擊手法,基本上無解,除非信用卡的網路交易也全面改成使用晶片...

手法其實很簡單,就是先算出一個合法的卡號,然後分兩階段攻擊取得資訊:

  • 先去找數家只需要「卡號 + 日期」的網站,用暴力法踹出日期 (假設五年就是 60 次)。
  • 再去找數十家需要「卡號 + 日期 + CVV2」的網站,用暴力法踹出 CVV2 (1000 次)。

所以 1060 次就擺平了... 就算所有網站都需要 CVV2,也是 60000 次的嘗試而已 (找數千個網站來踹),算是完全可行的方案。而目前只能靠 workaround 來防止,像是需要多輸入姓名與地址之類的資訊來擋...

Libgcrypt 與 GnuPG 的安全性問題

在「Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316]」這邊看到這個歷史悠久的 bug:

Felix Dörre and Vladimir Klebanov from the Karlsruhe Institute of Technology found a bug in the mixing functions of Libgcrypt's random number generator: An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt versions.

就這樣的行為,對於自己用的機器應該是還好... 不過得到 4640 bits 後就可以預測接下來的 160 bits,這個 RNG 有點囧 @_@

官方目前是認為應該還好:

A first analysis on the impact of this bug in GnuPG shows that existing RSA keys are not weakened. For DSA and Elgamal keys it is also unlikely that the private key can be predicted from other public information. This needs more research and I would suggest _not to_ overhasty revoke keys.

不過如果你有絕對的安全需求的話還是可以考慮 revoke 再重新生一把...

Google 對國際電話號碼格式常見誤解的說明

Google 對於國際電話號碼格式常見誤解的說明:「Falsehoods Programmers Believe About Phone Numbers」。

先看最後一個:

15. Phone numbers are always written in ASCII
In Egypt, it is common for phone numbers to be written in native digits.

電話號碼不是 ASCII 可以搞定的喔!!!然後你就可以理解沒什麼是不可能的 XDDD

這個系統是靠各種 backward compatible workaround 堆出來的,你覺得的假設通通會被推範 XDDD

四位數密碼的分佈

分析信用卡四位數密碼的分佈:「PIN number analysis」。

透過已經外洩的資料分析:

Obviously, I don’t have access to a credit card PIN number database. Instead I’m going to use a proxy. I’m going to use data condensed from released/exposed/discovered password tables and security breaches.

19xx 那邊特別高,拉出來看可以看到分佈:(很像是出生年 XDDD)

相同的 abab (前兩碼與後兩碼相同) 也可以看出特別高,而 aaaa (四碼都一樣) 的特別亮:

當不只四碼時,也有一些數據:

另外是特別高的 1004 的原因:

Many people also asked the significance of 1004 in the four character PIN table. This comes from Korean speakers. When spoken, "1004" is cheonsa (cheon = 1000, sa=4).

"Cheonsa" also happens to be the Korean word for Angel.

V8 Engine 的 Math.random() 在新版被重寫了...

先前在「V8 的 Math.random() 亂度不足的問題」提到 Math.random() 因為使用 MWC1616 (Fast random number generation using 128 bit multimedia extension registers on Pentium class machines) 而不夠亂的問題。

這個問題在新版 V8 Engine 提出改善了:「There's Math.random(), and then there's Math.random()」。

Untitled drawing

新實作的方法是 xorshift128+,擁有極長的 period length:

This has been pointed out to us, and having understood the problem and after some research, we decided to reimplement Math.random based on an algorithm called xorshift128+. It uses 128 bits of internal state, has a period length of 2128 - 1, and passes all tests from the TestU01 suite.

將會在 Google Chrome 49 (目前是 47) 引入:

The new implementation landed in V8 4.9.41.0 within a few days of us becoming aware of the issue. It will become available with Chrome 49. Both Firefox and Safari switched to xorshift128+ as well.

同時還是再次提醒,這不是 CSPRNG,要用在密碼學相關應用還是要用專門的 library 來產生 pseudo random number:

Make no mistake however: even though xorshift128+ is a huge improvement over MWC1616, it still is not cryptographically secure.

V8 的 Math.random() 亂度不足的問題

在「TIFU by using Math.random()」這篇看到作者踩到地雷,於是在討論 V8 EngineMath.random() 的亂度不足。

其實這個問提早在 2012 年就有人在 StackOverflow 上詢問:「Why is Google Chrome's Math.random number generator not *that* random?」,而且也回答得很清楚。

而 Mozilla 這邊在 2006 年也被提出了類似的問題:「Bug 322529 - Upgrade Math.random() to a better algorithm, such as Mersenne Twister」。

文章中間花了許多篇幅講 PRNG 的介紹,以及 cycle length 的說明,重點其實在結論的部份。

主要是因為 V8 Engine 的 Math.random() 實作的是 MWC1616 演算法 (Fast random number generation using 128 bit multimedia extension registers on Pentium class machines),而這個演算法用起來也綁手綁腳:

If you’re only using the most significant 16 bits it has a very short effective cycle length (less than 2³⁰).

有兩個方向可以改善 (不衝突的方向),一個是使用 CSPRNG (保證有極長的 cycle length),另外一個請求 V8 Engine 把 Math.random() 的演算法換掉,像是 MT19937 這類 cycle length 超級長的演算法。

不知道後續有沒有機會改善...