Home » Posts tagged "key"

Netflix 用 CloudTrail 記錄找出 AWS key 外洩的小工具

在「aws-credential-compromise-detection – Detecting Credential Compromise in AWS」這邊看到可以抓漏的專案 Netflix-Skunkworks/aws-credential-compromise-detection

透過分析 CloudTrail 記錄找出有哪些可疑的 AWS key 被外部使用,看起來預設值會過濾掉 Private IP range 以及 100.64.0.0/10 (設給給 CGNAT 使用的網段)。

不過 Netflix-Skunkworks 的定位是什麼啊,裡面好像有不少有趣的東西...

Cloudflare 的 Workers KV

Cloudflare 推出了 Workers KV 服務:「Building With Workers KV, a Fast Distributed Key-Value Store」。

是個 key-value 結構服務 (全球性,eventually consistent,約 10 秒的同步時間),key 的限制是 2KB,value 是 64KB,一個 namespace 最多 10 億筆資料。

讀取可以到 100k+ read/s,但寫入是 1 write/s/key,可以看出來主要是為了讀取資料而設計的。

現有的 worker ($5/month) 會送一些量,包括 1GB 的空間與一千萬次的讀取:

Your $5 monthly Workers compute minimum includes 1 GB of KV storage and up to 10 million KV reads. If you use less than the 10 million included Worker requests now, you can use KV without paying a single cent more.

超過的部份另外再收:

Beyond the minimums, Workers KV is billed at $0.50 per GB-month of additional storage and $0.50 per million additional KV reads.

這樣好像整個 blog 的基本功能都可以直接在上面跑了... 而搜尋靠外部服務,圖片與影音也可以靠外部空間協助?

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,先有個印象就好...

B2 的 Application Key

來講個 Backblaze 放出來一陣子的功能:「What’s New In B2: Application Keys + Java SDK」。

B2 的價位很便宜 (單位成本比 S3 低不少),加上前 10 GB 屬於 free tier 不收費,拿來丟一些資料還蠻方便的。

以往的 B2 在 API 操作只提供一把 master key,安全性上需要很小心,只要被攻陷就直接打穿了,現在則是提供 application key 操作,但不像 AWSIAM 那樣可以在一個 key 上設很多權限。B2 提供的架構很簡單,只能針對一個 bucket 設定權限。這應該是解決 B2 最常見的情境?也就是需要在各機器上分別備份...

另外摸索了一陣子後才確認用法,在文章的 comment 有提到:

You use the ApplicationKeyID with the ApplicationKey, and not the account ID, per the b2_authorize_account documentation.

In a sense, the master key is a special case of this: the AccountID is the ‘key ID’ for the master key.

也就是產生 application key 的時候會給你 secret key 以外,也會給你另外一組 key id,要用這兩個傳入呼叫 API,所有的操作都會受到限制。

關於備份的工具,大家蠻常用 rclone 的,主要是因為他可以加密再丟上去,讓 Backblaze 沒辦法直接存取內容。而 rclone 在 Ubuntu 18.04 可以 apt 直接裝,先前的版本則需要透過 snap 裝 (實在不愛 snap...),不過看起來還需要新版才會支援 application key。

過陣子來把現有的 master key 換一換...

保護 TLS 的 Hostname

看到「Encrypted Server Name Indication for TLS 1.3」這個,由 FastlyCloudflareApple 的人聯手推出的 draft,想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key,然後使用者用這把 public key 保護 hostname 的部分...

而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護,這樣讓 ISP 沒有任何資訊可以看到 hostname,把暴露的資訊再降低...

來繼續關注這個技術...

Ethereum Smart Contracts 裡的 PRNG

現代密碼學的安全性有很大一塊是基於亂數產生器 (RNG) 非常難被預測。如果這個前提不成立的話,利用亂數產生器產生出來的各種資訊都會被預測出來 (尤其是 Private Key)。

但真正的 RNG 需要靠硬體支援,而且產生速度很慢,一般都會使用 PRNG (Pseudorandom number generator) 產生。也就是「看起來」很亂的亂數產生器。

PRNG 通常是指在統計學上通過許多測試,像是在多種測試都是 Discrete uniform distribution,不需要防止有惡意人,可以從產生出的 PRNG 的值而推導出後續結果的用途。

在「Predicting Random Numbers in Ethereum Smart Contracts」這篇裡面,作者列出了一堆實做 Ethereum Smart Contracts 卻誤用 PRNG 的行為。

文章裡提到的問題都是因為 PRNG 拿著可被預測的資訊當作 entropy source (e.g. seed),而且提出來的範例都是拿 block 本身或衍生的資訊 (像是 block 的 hash) 來用:

  • PRNGs using block variables as a source of entropy
  • PRNGs based on a blockhash of some past block
  • PRNGs based on a blockhash of a past block combined with a seed deemed private
  • PRNGs prone to front-running

然後列了大量的程式碼當例子,建議有需要接觸的人看過一次,或是有時間的人都值得看這些負面範例... XDDD

不過作者在文章裡面也給了一堆有問題的方法,像是從外部網站取得亂數之類的 XDDD

正確的方法是使用 CSPRNG (Cryptographically secure pseudorandom number generator),這是專門設計給密碼學用的 PRNG。

CSPRNG 有幾種方法可以取得:

  • 在大多數的程式語言內都有對應的 library 可以用,另外在比較近代的瀏覽器內 (如果問 IE 的話,是 11+),可以透過 RandomSource.getRandomValues() 得到。
  • 如果打算自己搞底層而需要直接取得 CSPRNG 的產出,在 Unix-like 的環境下可以透過 /dev/urandom 取得,在 Microsoft Windows 下則可以透過 CryptGenRandom 取得。

別學作者那邊奇怪方法啊 XDDD

AWS KMS 可以在 VPC 內直接存取了

AWS Key Management Service 宣布支援 AWS PrivateLink Endpoint 了:「How to Connect Directly to AWS Key Management Service from Amazon VPC by Using an AWS PrivateLink Endpoint」。先前需要透過 Internet 流量存取 (透過 NAT、Proxy 之類的服務),現在則是可以接到 VPC 內直接用了:

Previously, applications running inside a VPC required internet access to connect to AWS KMS. This meant managing internet connectivity through internet gateways, Network Address Translation (NAT) devices, or firewall proxies.

With support for Amazon VPC endpoints, you can now keep all traffic between your VPC and AWS KMS within the AWS network and avoid management of internet connectivity.

KMS 需要 Internet 也是之前設計架構時比較痛的地方,現在總算是有個方向可以減少痛處了...

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 裡面就只有帶過去)

Etsy 介紹的 Cache Smearing

Etsy 的 engineering blog 上提到了他們怎麼設計 cache 機制:「How Etsy caches: hashing, Ketama, and cache smearing」。

使用 consistent hash 已經是基本款了,文章裡花了一些篇幅介紹為什麼要用 consistent hash。

後半段則是有了 consistent hash 後會遇到的問題,也就是講 hot key 怎麼處理:有些資料非常熱 (常常被存取),就算用 consistent hash 也還是有可能搞爆單一機器。

他們做了幾件事情,第一件事情是設計 cache smearing 機制,把單一資料加上 random key,使得不同的 key 會打散到不同的機器上:

Let’s take an example of a hot key popular_user_data. This key is read often (since the user is popular) and is hashed to pool member 3. Cache smearing appends a random number in a small range (say, [0, 8)) to the key before each read or write. For instance, successive reads might look up popular_user_data3, popular_user_data1, and popular_user_data6. Because the keys are different, they will be hashed to different hosts. One or more may still be on pool member 3, but not all of them will be, sharing the load among the pool.

第二件事情則是監控哪些 key 比較熱門:

We’ve seen this problem many times over the years, using mctop, memkeys, and our distributed tracing tools to track down hot keys.

第三件事情是維護 hot key 的清單 (不是每個 key 都會上 cache smearing):

We manually add cache smearing to only our hottest keys, leaving keys that are less read-heavy efficiently stored on a single host.

是個當規模大到單一 hot key 會讓單台伺服器撐不住時的 workaround...

Archives