Home » Posts tagged "rsa"

GCP 推出 Cloud HSM (beta)

這算是 Google Cloud Platform 在補產品線,讓那些有強制使用 HSM 的需求的應用 (通常是遇到一定要 FIPS 140-2 的規範) 可以搬上雲端:「Introducing Cloud HSM beta for hardware crypto key security」。

從圖片上可以看到 LiquidSecurity,應該是「LiquidSecurity® General Purpose HSM Adapters and Appliances」這個產品:

如同 AWSCloudHSM 服務,GCP 的 Cloud HSM 也是提供 FIPS 140-2 Level 3:

Cloud HSM allows you to host encryption keys and perform cryptographic operations in FIPS 140-2 Level 3 certified HSMs (shown below).

演算法上,支援 AESRSAECC (NIST 的 P-256 與 P-384):

In addition to symmetric key encryption using AES-256 keys, you can now create various types of asymmetric keys for decryption or signing operations, which means that you can now store your keys used for PKI or code signing in a Google Cloud managed keystore. Specifically, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 keys will be available for signing operations, while RSA 2048, RSA 3072, and RSA 4096 keys will also have the ability to decrypt blocks of data.

目前只支援 us-east1us-west1,另外價錢也比軟體服務版本的 Cloud KMS 貴不少:

Billable itemFor keys with protection level SOFTWAREFor keys with protection level HSM
Active AES-256 and RSA 2048 key versions$0.06 per month$1.00 per month
Active RSA 3072, RSA 4096 or Elliptic Curve key versions$0.06 per month$2.50 per month for the first 2,000
$1.00 per month thereafter
Destroyed key versionsFreeFree
Key operations: Cryptographic$0.03 per 10,000 operations$0.03 per 10,000 operations for AES-256 and RSA 2048 keys
$0.15 per 10,000 operations for RSA 3072, RSA 4096, and Elliptic Curve keys
Key operations: AdminFreeFree

不過一般情況應該不會得用 CloudHSM,先有個印象就好...

Meltdown 與 Spectre 都有用到的 FLUSH+RELOAD

MeltdownSpectre 攻擊裡都有用到的 FLUSH+RELOAD 技巧。這個技巧是出自於 2013 年的「Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack」。當時還因此對 GnuPG 發了一個 CVE-2013-4242

FLUSH+RELOAD 是希望透過 shared memory & cache 得到 side channel information,藉此突破安全機制。

論文裡面提到兩個攻擊模式,一種是在同一個 OS 裡面 (same-OS),另外一種是在同一台機器,但是是兩個不同的 VM (cross-VM)。攻擊的前提是要拿到與 GnuPG process 相同的 shared memory。兩個環境的作法都是透過 mmap() GnuPG 的執行檔以取得 shared memory。

在 same-OS 的情況下會使用同一個 process:

To achieve sharing, the spy mmaps the victim’s executable file into the spy’s virtual address space. As the Linux loader maps executable files into the process when executing them, the spy and the victim share the memory image of the mapped file.

在 cross-VM 的情況下會因為 hypervisor 會 dedup 而產生 shared memory:

For the cross-VM scenario we used two different hypervisors: VMware ESXi 5.1 on the HP machine and Centos 6.5 with KVM on the Dell machine. In each hypervisor we created two virtual machines, one for the victim and the other for the spy. The virtual machines run CentOS 6.5 Linux. In this scenario, the spy mmaps a copy of the victim’s executable file. Sharing is achieved through the page de-duplication mechanisms of the hypervisors.

接下來就能夠利用 cache 表演了。基本原理是「存取某一塊記憶體內容,然後計算花了多久取得,就能知道這次存取是從 L1、L2、L3 還是記憶體取得」。所以 FLUSH+RELOAD 就設計了三個步驟:

  • During the first phase, the monitored memory line is flushed from the cache hierarchy.
  • The spy, then, waits to allow the victim time to access the memory line before the third phase.
  • In the third phase, the spy reloads the memory line, measuring the time to load it.

先 flush 掉要觀察的記憶體位置 (用 clflush),然後等待一小段時間,接著掃記憶體區塊,透過時間得知有哪些被存取過 (就會比較快)。這邊跟 cache 架構有關,你不能想要偷看超過 cache 大小的量 (這樣會被 purge 出去),所以通常是盯著關鍵的部份就好。

接著是要搞 GnuPG,先看他在使用 RSA private key 計算的程式碼:



於是就能夠依照執行順序推敲出 RSA key 了,而實際測試的成果是這樣,在一次的 decrypt 或是 sign 就把 RSA key 還原的差不多了 (96.7%):

We demonstrate the efficacy of the FLUSH+RELOAD attack by using it to extract the private encryption keys from a victim program running GnuPG 1.4.13. We tested the attack both between two unrelated processes in a single operating system and between processes running in separate virtual machines. On average, the attack is able to recover 96.7% of the bits of the secret key by observing a single signature or decryption round.

知道了這個方法後,看 Meltdown 或是 Spectre 才會知道他們用 FLUSH+RELOAD 的原因... (因為在 Meltdown 與 Spectre 裡面就只有帶過去)

這次 PKCS #1 1.5 的 ROBOT 攻擊,Cisco 沒打算修...

1998 年就發現的 security issue 因為 workaround 也很複雜,所以不是每一家都修對方法,於是 19 年後又被爆破了。這次叫做 ROBOT:「1998 attack that messes with sites’ secret crypto keys is back in a big way」。


這次的攻擊在 client 端無法修正,只能在 server 端修正:

Do I need to update my browser?
No. This is an implementation bug in servers, there is nothing clients can do to prevent it.

如果 server 端無法盡快修正的話,想辦法避開 RSA encryption 可以躲開這個問題,而且因為現代瀏覽器都有非 RSA 的替代方案,這樣做應該都還有退路,可以維持連線的可能性:

Disable RSA encryption!
ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.

但使用 Cisco ACE 就哭了,因為 Cisco ACE 只支援 RSA encryption,而 Cisco 官方以產品線已經關閉,不再提供維護而沒有提供更新的計畫,所以就進入一個死胡同...

不過 Cisco 自己也還在用 Cisco ACE 就是了,不在意就不會痛的感覺 XD

I have a Cisco ACE device.
Cisco informed us that the ACE product line was discontinued several years ago and that they won't provide an update. Still, we found plenty of vulnerable hosts that use these devices.

These devices don't support any other cipher suites, therefore disabling RSA is not an option. To our knowledge it is not possible to use these devices for TLS connections in a secure way.

However, if you use these products you're in good company: As far as we can tell Cisco is using them to serve the cisco.com domain.

IBM 的 50 qubit quantum computer

IBM 在展示他們做到了什麼:「IBM makes 20 qubit quantum computing machine available as a cloud service」。

不過重點應該在目前已經拉出 50 qubit prototype 了:

The company also announced that IBM researchers had successfully built a 50 qubit prototype, which is the next milestone for quantum computing, but it’s unclear when we will see this commercially available.

18 個月從 5 qubit 到 20 qubit:

IBM has been offering quantum computing as a cloud service since last year when it came out with a 5 qubit version of the advanced computers. Today, the company announced that it’s releasing 20-qubit quantum computers, quite a leap in just 18 months. A qubit is a single unit of quantum information.

如果是以這樣的速度成長 (每 18 個月變成原來四倍),五年後就有機會殺 RSA 2048 bits 了?(大約需要 4000 個 qubit)

這比想像中快好多,難怪現在密碼學都在討論抵抗 quantum computer 的演算法...

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 上報告了...

Gmail 要開始導入 SMTP Strict Transport Security 了

SMTP MTA Strict Transport Security 算是 SMTP STARTTLS 裡的 HSTS 機制,而 Google 的人在 RSA Conference 上提出要開始用了:「SMTP STS Coming Soon to Gmail, Other Webmail Providers」。

Elie Bursztein, the head of Google’s anti-abuse research team, said at RSA Conference that SMTP STS will be a major impediment to man-in-the-middle attacks that rely on rogue certificates that are likely forged, stolen or otherwise untrusted. Google, Microsoft, Yahoo and Comcast are expected to adopt the standard this year, a draft of which was submitted to the IETF in March 2016.

補上去後對於 SMTP 的隱私保護就會更好了...

Let's Encrypt 支援 IDN

Let's Encrypt 宣佈支援 IDN:「Introducing Internationalized Domain Name (IDN) Support」,這代表可以申請的範圍變得更廣了:

This means that our users around the world can now get free Let’s Encrypt certificates for domains containing characters outside of the ASCII set, which is built primarily for the English language.

在「Upcoming Features」可以看到下一步應該是 ECDSA Intermediates?

Let’s Encrypt only signs end-entity certificates with RSA intermediates. We will add the ability to have end-entity certs signed by an ECDSA intermediate.


Google Chrome 引入 CECPQ1,開始測試 Post-Quantum Cryptography

Quantum Computer 對現有密碼學的衝擊很大,像是 RSA 演算法是基於「質因數分解」的難題而架構出來的系統,在 Quantum Computer 上存在有效率的演算法,也就是 Shor's algorithm

雖然 Quantum Computer 在技術上還沒辦法對現有演算法造成有效的攻擊,但已經有人提出新的演算法來對抗,而 Google 打算在 Google Chrome 裡面引入測試:「Experimenting with Post-Quantum Cryptography」。

Google 也特別說明了,他們不希望這個實驗最後變成 de-facto standard (借測轉出貨的概念),而是希望當作一個開頭,希望之後可以用更好的標準換掉:

We explicitly do not wish to make our selected post-quantum algorithm a de-facto standard. To this end we plan to discontinue this experiment within two years, hopefully by replacing it with something better.

密碼系統的 Monoculture

這篇文章講到最近密碼系統的現象:「On the Impending Crypto Monoculture」。

目前常在用的密碼系統包括了 RSA、DH、ECDH、ECDSA、SHA-2、AES 這些演算法,而最近這幾年大家在推廣使用的演算法都出自於同一個人手裡,Dan Bernstein,也就是 djb:

A major feature of these changes includes the dropping of traditional encryption algorithms and mechanisms like RSA, DH, ECDH/ECDSA, SHA-2, and AES, for a completely different set of mechanisms, including Curve25519 (designed by Dan Bernstein et al), EdDSA (Bernstein and colleagues), Poly1305 (Bernstein again) and ChaCha20 (by, you guessed it, Bernstein).

這些演算法或是定義,包括了 Curve25519、EdDSA、Poly1305、ChaCha20。而這篇文章試著說明造成這樣情況的背景以及原因,以及這樣會導致什麼問題。

當實際分析時會發現,檯面上沒幾個能用的演算法,而看起來能用的那幾個又有專利 (像是 OCB),不然就是看起來被 NSA 放了一些說明不了的參數 (像是 P-256 Curve)。

然後 djb 弄出來的演算法不只看起來乾淨許多,也直接用數學模型證明安全性。而且他的實作也很理論派,像是還蠻堅持要做到 constant time implementation 以避開各種 side channel attack。

就... 理論很強,又很實戰派的一個人啊,檯面上真的沒幾隻可以打的贏啊 XD

USD$75 解 RSA 512bits

Cryptology ePrint Archive 上面剛好是 2015 年編號 1000 號的論文:「Factoring as a Service」。透過 Amazon EC2 服務以及 CADO-NFS 的幫助,四小時內就可以解出 512bits RSA,而如同作者說的,雖然已經很不安全了,但在許多地方仍然被使用著:

The difficulty of integer factorization is fundamental to modern cryptographic security using RSA encryption and signatures. Although a 512-bit RSA modulus was first factored in 1999, 512-bit RSA remains surprisingly common in practice across many cryptographic protocols. Popular understanding of the difficulty of 512-bit factorization does not seem to have kept pace with developments in computing power. In this paper, we optimize the CADO-NFS and Msieve implementations of the number field sieve for use on the Amazon Elastic Compute Cloud platform, allowing a non-expert to factor 512-bit RSA public keys in under four hours for $75. We go on to survey the RSA key sizes used in popular protocols, finding hundreds or thousands of deployed 512-bit RSA keys in DNSSEC, HTTPS, IMAP, POP3, SMTP, DKIM, SSH, and PGP.

另外也有專案網站:「Factoring as a Service」,程式碼也有放上 GitHub:「Factoring as a Service」。