AWS KMS 支援 ECDH

看到「Announcing AWS KMS Elliptic Curve Diffie-Hellman (ECDH) support」這篇的介紹,AWS KMS 支援 ECDH 了。

AWS 的文件「DeriveSharedSecret」這邊可以看到就是在不將 private key 暴露出來的情況下得到 ECDH 產生的 shared secret:

The private key in your KMS key pair never leaves AWS KMS unencrypted. DeriveSharedSecret returns the raw shared secret.

翻了一下其他兩個雲的 Cloud HSM 類服務,好像沒有看到 ECDH 的,不過如果是實際硬體 HSM 的話,Azure Dedicated HSM 似乎有支援,可以在 FAQ 這邊看到:

Dedicated HSM service provisions Thales Luna 7 HSM appliances.

Cryptography (ECDSA, ECDH, Ed25519, ECIES) with named, user-defined, and Brainpool curves, KCDSA

AWS KMS 畢竟是軟體基底的,要支援什麼演算法可以直接加...

lite-youtube-embed

繼續清 tab,在「YouTube embeds are heavy and it’s fixable (frontendmasters.com)」這邊看到的是提出改善 YouTube 的外嵌功能 (embed),因為 loading 太肥了。原文在「YouTube Embeds are Bananas Heavy and it’s Fixable」,裡面提到一個只有 YouTube 的 embed (iframe) 頁面就抓了 1.3MB 的資料:

On a page with literally nothing at all on it other than a YouTube Embed, we’re looking at:

32 requests
1.3 MB of data transfer
2.76s to load the page on my current WiFi connection

而「One YouTube Embed weighs almost 1.2 MB」這邊更提到了這邊的 resource 會線性疊加不會共用的:

The weight also grows linearly with every embed—resources are not shared: two embeds weigh 2.4 MB; three embeds weigh 3.6 MB (you get the idea).

測了一下 https://home.gslin.org/tmp/ytembed.html 這個,是 1.2MB transferred:

如果放兩個一樣的影片,也就是 https://home.gslin.org/tmp/ytembed2.html 的話,變成 2.4MB transferred:

所以不共用的部分的確超大,懷疑 iframe 之間不共用資源是不是跟 cache partition 的實作有關:「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」。

Anyway,所以作者提案用 lite-youtube-embed 這個套件改善:

Provide videos with a supercharged focus on visual performance. This custom element renders just like the real thing but approximately 224× faster.

不過這種事情你想得到,Google 也一定想得到,全篇只講 lite-youtube-embed 的好處一定哪邊有問題。

所以翻一下 Hacker News 上,在 id=40897582 這邊就有人提到缺點了,很明顯 lite-youtube-embed 的載入速度比較慢:

The author says they don't believe that a lighter version has been shown to reduce engagement.

I, on the other hand, fully believe that.

The recommended lite-youtube-embed project page has a demo of both lite and regular players [0], and the lite version takes noticeably longer to start playing the video.

Every additional millisecond of load time will reduce engagement, and here the difference is more on the order of hundreds of milliseconds or more.

[0] https://paulirish.github.io/lite-youtube-embed/

yeah,這樣就合理了。

即使 embed 吃超多資源,但因為 YouTube 是影音網站,主要的流量還是影音的部分,利用這個方法增加載入速度,在成本結構上面可以接受,而且還可以拿到更多瀏覽資料?

但對於網站端以及使用者端就不是什麼愉快的事情,所以網站端要不要用這個套件就是看各自的取捨了。

Akamai Shared Domains 加入 PSL (Public Suffix List)

Akamai 把自家的 shared domains 申請加入 PSL (Public Suffix List):「Adding Akamai Shared Domains to the Public Suffix List」。

提到 PSL,常被拿來舉例的應該就是 supercookie 了,也就是把 cookie 的有效網域設到 .com 或是 .org 這種 top level domain,這樣就可以跨很多站台追蹤使用者了 (所以被稱為 supercookie),而 PSL 則可以被拿來限制這些網域名稱。

而在 Akamai 的例子來說,edgekey.net 下面的使用者都會共用 cookie,對於安全與隱私的考量其實不太好。這次把這些網域加到 PSL 之後,變成 edgekey.net 這層無法設定 cookie,而 one.edgekey.nettwo.edgekey.net 各自有自己的 cookie namespace,這樣就好一些了...

順帶一提,除了瀏覽器會引入 PSL 來過濾外,使用者端可以靠 Privacy Badge 來過濾掉這類的 cookie,因為 Privacy Badge 會針對這類網域清掉 cookie 再送出 HTTP request。

Akamai 的文章裡面也有提到這件事情:

The PSL contains multi-party domain suffixes and is used by a wide range of client software (for example, web browsers) to implement policy decisions, such as to prevent cookies from being set on public or multi-party domains.

Slack 推出 Private Shared Channel,在兩個團體中間開 Private Channel

Slack 推出的新功能 Private Shared Channel:「Private shared channels are now available」,當然,這是付費功能 XD

Shared channels (beta) are currently only available for paid teams on Standard and Plus plans; Enterprise Grid support will be coming soon.

兩個都用 Slack 的團體可以開 Shared Channel,但之前只支援 Public Channel (參考「兩個都用 Slack 的公司可以直接在 Slack 上合作了」),現在則是支援 Private Channel 了。

可以兩個團體都是 Private:

也可以是單邊 Private,對另外一邊完全開放:

這個功能主要是用在 secret project 但又需要跟外部溝通的情況...

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

兩個都用 Slack 的公司可以直接在 Slack 上合作了

Slack 推出的新功能 Shared Channels:「Introducing Shared Channels: Where you can work with anyone in Slack」。

Shared Channels are a new kind of channel that connects two separate organizations, creating a common space for both sides to make use of Slack’s communication features and platform integrations when working together.

在截圖可以看到界面上,左半部會以 Shared Channels 顯示:

這邊也有提到 Shared Channels 需要透過管理員核准:

Accept the request: The other organization’s admin will receive a direct message from Slackbot, from which they can accept your request and add the channel to their workspace.

這樣就不用另外再開 guest 了...

2015 年的 Turing Award 由 Whitfield Diffie 與 Martin E. Hellman 獲得

紐約時報看到今年的 Turing AwardWhitfield DiffieMartin E. Hellman 獲得:「Cryptography Pioneers Win Turing Award」。在 Turing Award 官網上也可以看到對應的說明。

Diffie–Hellman key exchange 是全世界第一個 (1976 年) 在公開頻道上建立 shared secret 的演算法,直到現在都還廣泛的被使用,可以防禦被動式的監聽攻擊:

The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel.

現在這個演算法用在 PFS (Perfect forward secrecy),或稱為 FS (Forward secrecy),確保 public key 被破解前的連線記錄不會輕易被破解,於是更確保了資料的安全性:

a secure communication protocol is said to have forward secrecy if compromise of long-term keys does not compromise past session keys.

後來這個演算法也被延用到 Elliptic curve 上,也就是 ECDH,因為不使用 Z_{2^p}Z_p (field) 而是使用 Elliptic curve (group),而大幅降低了可被拿來攻擊的特性,而使得 key 的長度可以比 RSA 小很多。

上一個因密碼學拿到 Turing Award 的是 2012 年得獎的 Silvio MicaliShafi Goldwasser,他們所音發展出來的用以對密碼系統驗證的數學方法而得獎。

而更有名的應該是 2002 年 Ronald L. RivestAdi ShamirLeonard M. Adleman 因為 RSA 演算法而得獎的事情。

在愈來愈多新聞揭露安全與隱私問題後 (尤其是政府對人民的監控),密碼學愈來愈被重視。之前在密碼學領域做出重大貢獻的人也陸陸續續得獎...

ISP 架設 NAT 解決 IPv4 不夠的問題...

Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題:「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。

用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做),但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司,也可能是家庭) 發生 Private Network 相同而導致問題。

2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留,拿來給營運 CGNAT 的 ISP 使用:

NetRange:       100.64.0.0 - 100.127.255.255
CIDR:           100.64.0.0/10
OriginAS:
NetName:        SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:      NET-100-64-0-0-1
Parent:         NET-100-0-0-0-0
NetType:        IANA Special Use

在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換;如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情):

In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。

如果 CGNAT 上不能打洞,那麼很多應用就很苦了 (得靠 UDP hole punching 打洞,這還得在沒有 randomized NAT port 的情況下才打的通),不過非 P2P 的應用應該不會有問題...

會不會做一做之後就維持這個方式?IPv6 遙遙無期... XD