Cavium (被 Marvell 併購) 在 Snowden leak 中被列為 SIGINT "enabled" vendor

標題可能會有點難懂,比較簡單的意思就是在 Snowden 當年 (2013) 洩漏的資料裡面發現了不太妙的東西,發現 Cavium (現在的 Marvell) 的 CPU 有可能被埋入後門,而他們家的產品被一堆廠商提供的「資安產品」使用。

出自 X (Twitter) 上面提到的:

這段出可以從 2022 年的「Communication in a world of pervasive surveillance」這份文件裡面找到,就在他寫的 page 71 (PDF 的 page 90) 的 note 21:

While working on documents in the Snowden archive the thesis author learned that an American fabless semiconductor CPU vendor named Cavium is listed as a successful SIGINT "enabled" CPU vendor. By chance this was the same CPU present in the thesis author’s Internet router (UniFi USG3). The entire Snowden archive should be open for academic researchers to better understand more of the history of such behavior.

Ubiquiti 直接中槍...

而另一方面,在 Hacker News 上的討論「Snowden leak: Cavium networking hardware may contain NSA backdoor (twitter.com/matthew_d_green)」就讓人頭更痛了,像是當初 Cavium 就有發過新聞稿提到他們是 AWS CloudHSM 的供應商:「Cavium's LiquidSecurity® HSM Enables Hybrid Cloud Users to Synchronize Keys Between AWS CloudHSM and Private Clouds」。

而使用者也確認有從 log 裡面看到看到 Cavium 的記錄:

Ayup. We use AWS CloudHSM to hold our private signing keys for deploying field upgrades to our hardware. And when we break the CI scripts I see Cavium in the AWS logs.

Now I gotta take this to our security team and figure out what to do.

居然是 CloudHSM 這種在架構上幾乎是放在 root of trust 上的東西...

把 SSH Key 放進 Secure Enclave 裡保護

看到 Secretive 這個專案,是利用蘋果的 Secure Enclave 機制,把 SSH private key 放進去在裡面進行運算,避免 private key 檔案被惡意程式讀取就洩漏出去了。

從 Secure Enclave 的介紹頁面可以看到這個需要有 T1 或是 T2 晶片才有 Secure Enclave 功能:

Mac computers that contain the T1 chip or the Apple T2 Security Chip

而從 Apple Silicon 這邊可以看到 Apple T1 chip 是 2016 年後的機種引入的:

The Apple T1 chip is an ARMv7 SoC (derived from the processor in S2 SiP) from Apple driving the System Management Controller (SMC) and Touch ID sensor of the 2016 and 2017 MacBook Pro with Touch Bar.

然後對於沒有 Secure Enclave 的古董機,可以透過有支援 smart card 的硬體掛上去,像是 YubiKey

For Macs without Secure Enclaves, you can configure a Smart Card (such as a YubiKey) and use it for signing as well.

照著他講的建議去翻了「YubiKey Smart Card Deployment Guide」這邊的資料,看起來 YubiKey 在 4 系列之後就有產品支援 Smart Card 了,不過要注意純 U2F 的版本沒支援。

AWS ACM 支援 Private CA

AWS ACM 推出了 Private CA 服務:「How to host and manage an entire private certificate infrastructure in AWS」。

以前需要 Private CA 的話,會找個地方丟 Root CA 的 key,然後有權限的人可以連到那台機器上跑 OpenSSL 指令生出對應的 SSL certificate,現在 AWS 則是利用 HSM 架構提供服務:

主要是因為 HSM 的關係,安全性會比較好... 另外也因為是 AWS 服務的關係,上面可以看到相關的記錄,相較於以前的作法安全不少。

Vault 出 1.0 版,整合雲上面的 HSM 服務

看到「HashiCorp Vault 1.0」這則消息,Vault 要出 1.0 不是什麼新聞,重點是他把跟 Cloud Auto Unseal 的功能放出來了:

In Vault 1.0, we are open sourcing Cloud Auto Unseal, allowing for all users of Vault to leverage cloud services such as AWS KMS, Azure Key Vault, and GCP CKMS to manage the unseal process for Vault.

可以看在 AWS 上的作法:「Auto-unseal using AWS KMS」。

這樣在雲上的服務可以再降低風險...

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 item For keys with protection level SOFTWARE For 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 versions Free Free
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: Admin Free Free

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

便宜的 HSM

當然速度就不用想太多了...

一個是 Yubico 推出的 YubiHSM 2:「YubiHSM 2 is here: Providing root of trust for servers and computing devices」。

另外一個是 Mozilla 在 2013 年提到的 CryptoStick,不過現在連過去看到的是 Nitrokey HSM:「Using CryptoStick as an HSM」。

兩個都是走 USB 1.1 Type A,運算效能都普普通通,感覺自己用比較合適?像是 GnuPG 加解密。拿給線上服務用的效能還是要夠好...

AWS CloudHSM 支援 FIPS 140-2 Level 3 了

AWS CloudHSM 推出了一些新功能:「AWS CloudHSM Update – Cost Effective Hardware Key Management at Cloud Scale for Sensitive & Regulated Workloads」。

其中比較特別的是從以前只支援 Level 2 變成支援 Level 3 了:

More Secure – CloudHSM Classic (the original model) supports the generation and use of keys that comply with FIPS 140-2 Level 2. We’re stepping that up a notch today with support for FIPS 140-2 Level 3, with security mechanisms that are designed to detect and respond to physical attempts to access or modify the HSM.

在維基百科裡面有提到 Level 2 與 Level 3 的要求:

Security Level 2 improves upon the physical security mechanisms of a Security Level 1 cryptographic module by requiring features that show evidence of tampering, including tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module, or pick-resistant locks on covers or doors to protect against unauthorized physical access.

In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper-detection/response circuitry that zeroes all plaintext CSPs when the removable covers/doors of the cryptographic module are opened.

主動式偵測以及銷毀算是 Level 3 比 Level 2 安全的地方。

另外就是計價方式的修正,先前有一筆固定的費用,現在變成完全照小時計費了:

Pay As You Go – CloudHSM is now offered under a pay-as-you-go model that is simpler and more cost-effective, with no up-front fees.

Etsy 如何用 Let's Encrypt 的 SSL certificate 做生意...

Etsy 的「How Etsy Manages HTTPS and SSL Certificates for Custom Domains on Pattern」這篇文章講了如何用 Let's Encrypt 實作 Custom Domain。

主要是因為 Let's Encrypt 在設計時就考慮到的 auto-renew 機制,可以全自動處理後續的動作。這使得接 Let's Encrypt 比起接其他家來得容易 (而且省掉許多費用與合約上要處理的問題)。

文章後半段則是討論另外一個問題:當你有上千把 private key (& certificate) 時要怎麼管理,以確保這些 private key 都夠安全。其中有提到未來打算要引入 HSM

One of our stretch goals is to look into deploying HSMs. If there are bugs in the underlying software, the integrity of the entire system could be compromised thus voiding any guarantees we try to keep. While bugs are inevitable, moving critical cryptographic functions into secure hardware will mitigate their impact.

由於不太可能是把所有的 private key 塞到 HSM 裡面,應該是用 HSM 管理加密後的 private key,可以想像一下整個系統又會多了好幾個元件將責任拆開...

Apple 打算把 iCloud 加密用的 Key 放到用戶端

在經過最近 FBIApple 的戰鬥中 (FBI–Apple encryption dispute),Apple 正規劃把 iCloud 加密所使用的 key 放到用戶端裝置上,而非放在伺服器端:「Apple to Hand iCloud Encryption Key Management to Account Holders」:

In effect, Apple is following the lead of secure cloud services such as SpiderOak which has been offering what it calls “Zero Knowledge” cloud storage. By that, SpiderOak retains no information about whatever is stored in its cloud service, nor the means of gaining access to it.

也就是加解密都放在 client 端處理,server 端只是 storage。

這類型最大的問題是 server 端沒辦法運用資料,但 iCloud 的確可以放掉這些功能 (搜尋之類的),純粹當 storage 使用,藉以讓使用者自己裝置保護。

而蘋果在使用者的裝置上把類似於 HSM 的系統做的頗強大... 不知道 Android 有沒有機會也跟進。(雖然我自己是用 Apple 家的東西...)

Amazon EC2 預定要推出的 Dedicated Hosts

Amazon EC2 愈定要推出新的購買方案:「Coming Soon – EC2 Dedicated Hosts」。

Dedicated Hosts 的租用是以整台主機為單位,以確保整台實體機器不會有其他人使用,對安全性的要求會比較好。這邊拿 c3.xlarge 來舉例,一次就是八台的費用:(這邊「八台」的數字是未定的,真正的數字要等正式公告上線後才知道)

Each host has room for a predefined number of instances of a particular type. For example, a specific host could have room for eight c3.xlarge instances (this is a number that I made up for this post). After you allocate the host, you can then launch up to eight c3.xlarge instances on it.

會有這樣的需求主要還是因為有些軟體還沒有適當的 cloud-based licensing (授權方式),當 BYOL 時 (Bring Your Own License),會需要能夠對實體機器有更多控制權:

We want to make sure that you can continue to derive value from these licenses after you migrate to AWS. In general, we call this model Bring Your Own License, or BYOL. In order to do this while adhering to the terms of the license, you are going to need to control the mapping of the EC2 instances to the underlying, physical servers.

另外這對於安全性理由也多了個解決方案,像是需要實體分離避開各種 side-channel attack。不過 AWS 之前就有提供其他的方法。

對於軟體有支援 CloudHSM 的,可以考慮直接使用這個解決方案,private key 直接放在 HSM 上,而且 AWS 有符合常見的安全標準。

而另外對於有跟美國政府簽約的數據需求,可以用 AWS GovCloud (US),讓一般人根本接觸不到。

對於一般單位的需求,也可以用 Dedicated Instances 來確保實體機器上只有單一客戶,而這也能買 Reserved Instances 確保使用權,以及對應的折扣。

所以這次 Dedicated Hosts 比較像是商業授權上的需求而產生出來的解決方案,而不是安全性需求...