Amazon EFS 也能加密了

Amazon EFS 也支援使用 KMS 加密了,這對於一些要求「落地要加密」的 certification 方便不少:「New – Encryption of Data at Rest for Amazon Elastic File System (EFS)」。

不過東京還沒有 EFS 啊... (繼續敲碗)

Telegram 使用 CDN 加速下載

Telegram 說明他們將會使用 CDN 加速:「More Speed and Security!」。

資料在 CDN 的節點上是加密的,金鑰需要透過 Telegram 的 key server 提供:

While these caching nodes are only used to temporarily store public media (imagine Telegram versions of superpopular YouTube hits), all data that goes through them is encrypted with a key unknown to the caching nodes. In other words, we treat these CDN caching nodes just like we treat your internet provider – they only ever get encrypted junk they can't decipher.

但這表示 Telegram 本身有能力解開這些資料?不知道這邊講的是什麼行為...

使用者如果選擇願意公開的話當然沒問題,但這種情況下也不需要 CDN 加密;而當使用者不願意公開時,應該是期望 Telegram 也無法解開這些資料?再來看看到底是怎麼樣的功能要上 CDN?

AES-GCM-SIV

在「AES-GCM-SIV: Specification and Analysis」這邊看到 AES-GCM-SIV 的作者自己投稿上去的資料,是個已經被放進 BoringSSL 並且在 QUIC 上使用的演算法:

We remark that AES-GCM-SIV is already integrated into Google's BoringSSL library \cite{BoringSSL}, and its deployment for ticket encryption in QUIC \cite{QUIC} is underway.

在 RFC 上的說明解釋了這個演算法的目的是希望當 nonce 沒有被正確實作時仍然可以有比 AES-GCM 強的保護:

This memo specifies two authenticated encryption algorithms that are nonce misuse-resistant - that is that they do not fail catastrophically if a nonce is repeated.

在 128 bits 的情況下,加密的速度大約是 AES-GCM 的 2/3 (在都有硬體加速的情況下),但解密的速度則與 AES-GCM 相當:

For encryption, it is slower than AES-GCM, because achieving nonce-misuse resistance requires, by definition, two (serialized) passes over the data. Nevertheless, optimized implementations run GCM-SIV (for 128-bit keys) at less than one cycle per byte on modern processors (roughly 2/3 of the speed of nonce-respecting AES-GCM). On the other hand, GCM-SIV decryption runs at almost the same speed as AES-GCM.

不過這就是 trade-off 了,如果 nonce 有正確被實作的話,其實不需要這個...

Amazon Redshift 可以讀 S3 裡被 KMS 加密過的資料了

清資料時發現支援了:「Amazon Redshift now supports encrypting unloaded data using Amazon S3 server-side encryption with AWS KMS keys」:

The Amazon Redshift UNLOAD command now supports Amazon S3 server-side encryption using an AWS KMS key.

這樣資料丟上 Amazon S3 時可以透過 AWS KMS 加密保存,而 Amazon Redshift 可以透過 KMS 直接拉出來,處理起來會方便不少...

不過 Amazon Athena 好像還是沒辦法?

Google Cloud Platform 提供 Cloud Key Management Service

GCP 提供 Cloud Key Management Service (目前是 beta),將對 key 的處理 (像是加解密) 變成服務的一部分。

費用的部份,比較大的量應該會在「Key use operations (Encrypt/ Decrypt)」這塊?每一萬次收 USD$0.03。

自己建會有一堆稽核問題要處理,有人建起來後直接用,拔責任直接拆開的確是比較方便...

前陣子在 Black Hat 上發表的 HEIST 攻擊 (對 HTTPS 的攻擊)

又是一個對 HTTPS 的攻擊:「HEIST attack on SSL/TLS can grab personal info, Black Hat」、「New attack steals SSNs, e-mail addresses, and more from HTTPS pages」。

一樣是 Compression 產生的 side-channel attack,只是這次是結合 TCP window size 的攻擊。投影片可以在「HTTP Encrypted Information can be Stolen through TCP-windows (PDF)」這邊看到。

這次的攻擊只需要在瀏覽器上插入 HTTP 產生 HTTPS 的流量,然後從旁邊看 HTTPS 連線的 TCP packet 就可以了,而且對 HTTP/2 也很有效:

而且很不幸的,目前沒有太好的解法,因為所有的攻擊手法都是照著使用者無法發現的路徑進行的 @_@

對於使用者,大量使用 HTTPS (像是 HTTPS Everywhere 這樣的套件),能夠降低政府單位與 ISP 將 javascript 插入 HTTP 連線,產生 HTTPS 的行為。

而對於網站端來說,全站都隨機產生不同長度的 HTTP header 可能是個增加破解難度的方式 (而且不會太難做,可以透過 apache module 或是 nginx module 做到),但還是可以被統計方法再推算出來。

不知道有沒有辦法只對 HTTPS 開 javascript,雖然攻擊者還是可以用 <img> 攻擊...

也許以後 HTTP/3 之類的協定會有一區是不壓縮只加密的,避開這類 compression-based attack @_@

CIA 老大告訴參議員,在加密系統裡放後門是可行的,因為沒有公司可以逃離美國魔掌

如同標題講的,CIA 老大 John Brennan 告訴參議員,因為實務上不存在「Non-US encryption」,所以強制任何要進入美國的企業使用美版帶有後門的加密系統是可行的:「Non-US encryption is 'theoretical,' claims CIA chief in backdoor debate」。

CIA director John Brennan told US senators they shouldn't worry about mandatory encryption backdoors hurting American businesses.

And that's because, according to Brennan, there's no one else for people to turn to: if they don't want to use US-based technology because it's been forced to use weakened cryptography, they'll be out of luck because non-American solutions are simply "theoretical."

這位腦袋已經壞掉了啊,你知道有個叫做 China,拼做 C-h-i-n-a 的經濟體系嗎... 然後中美共用同一套有後門的加密系統瞬間就會被一堆人打槍,如果真的發生,還有個歐盟... 而且這些事情只是促進以色列的安全系統加速脫離美國掌控啊?以色列才是目前資安的超級強國啊...

這世界上有太多已經不是掌握在美國的東西了啊...

Google 刻意讓 Allo 不安全的方法

兩篇文章與一則 tweet 剛好可以一起看。

兩篇文章分別是「Don't Use Allo」講 Google Allo 預設沒有加密的問題,與「How Technology Hijacks People’s Minds — from a Magician and Google’s Design Ethicist」講如何設計產品來改變人的行為。

在市場上的領先者 Whatsapp 已經啟用預設 end-to-end encryption 後,Google Allo 之所以不是預設加密的原因,是基於這樣的設計方法,因為 Google 並不想要加密:

Businesses naturally want to make the choices they want you to make easier, and the choices they don’t want you to make harder. Magicians do the same thing. You make it easier for a spectator to pick the thing you want them to pick, and harder to pick the thing you don’t.

而這則 tweet 剛好解釋了這個方法背後幾個可能的利害關係,大公司受到政府單位的施壓而妥協:

剛剛好都是最近的文章,整起來剛剛好...

Amazon Fire 會把加密系統弄回來

FBIApple 的戰爭開打後,愈來愈多安全與隱私問題被重新拿出來檢驗,而 Amazon 也決定將 2015 年拔掉的加密功能搬回 Fire OS 裡:「Amazon Reverses Course, Encryption Returning for Fire Devices」:

Amazon.com Inc. will restore encryption as a security option on its tablets and other devices that use the Fire operating system, following a customer backlash driven by increased sensitivity about data protection as Apple Inc. grapples with the FBI over access to a terrorist’s iPhone.

預定是今年春天加回來:

Amazon reversed course late Friday night, saying in an e-mail that it would restore encryption as an option on Fire devices with a software update “this spring,“ without being more specific.

愈來愈多公司與產品都認定加密是「基本功能」,無論你有沒有接觸到敏感資料。

百度被抓到蒐集個資後還是要蒐集...

在「Thousands of apps running Baidu code collect, leak personal data - research」這篇裡,加拿大的研究團隊 Citizen Lab 發現百度的 Android SDK 使用非加密傳輸這些個資:

The unencrypted information that has been collected includes a user's location, search terms and website visits, JeffreyKnockel, chief researcher at Citizen Lab, told Reuters ahead of publication of the research on Wednesday.

百度說他們會修正加密問題,但還是要蒐集:

[,] and Baidu told Reuters it would be fixing the encryption holes in its kits, but would still collect data for commercial use, some of which it said it shares with third parties.

霸氣!不愧是百度!即使被抓到後還是要蒐集 XDDD