Gmail 宣佈支援 MTA-STS

Gmail 宣佈支援 MTA-STS:「Gmail making email more secure with MTA-STS standard」。這邊提到的 MTA-STS 是透過某些設定,讓 SMTP 送信時強制使用 TLS 的機制,可以參考「SMTP 的強加密連線機制」這篇。

可以看到有 TXT,也有 .well-known 檔案:

;; ANSWER SECTION:
_mta-sts.gmail.com.     300     IN      TXT     "v=STSv1; id=20171114T070707;"

$ curl https://mta-sts.gmail.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

如果要自己設定的話可以參考 Google 提供的「About MTA-STS and TLS Reporting」這篇,不過目前中文版文件還沒有更新,請切到英文版...

最近很紅的密碼...

前幾天在 Twitter 看到,剛剛在 Hacker News Daily 上的整理又看到:

老外在研究的時候發現這個密碼看起來夠長 (12 個字),而且也還算安全 (有英文與數字,看起來無意義),但卻發現被大量重複使用,而不只是單一帳號在用,就很好奇發生這是什麼東西...

對於台灣人來說應該是很熟悉了,這是注音輸入法的「我的密碼」:


出自維基百科的「File:Keyboard layout Zhuyin.svg

非拼音類的輸入法應該都會產生一樣的困惑...

保護 Linux 的檢查清單...

trimstray/the-practical-linux-hardening-guide 這邊看到保護 Linux 系統的方式,列成清單:

This guide details the planning and the tools involved in creating a secure Linux production systems - work in progress.

從實體的開始講,然後 BIOS,再來是 OS 層,接下來是基本服務,再來到應用程式,一般人做的到的該涵蓋的都有涵蓋到了...

不過在一般情況下要全部都完成不太可能 (通常是人太懶),但可以當清單掃一輪挑著做,加強系統的安全性...

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

Qubes OS 4.0 推出

也是個放在 tab 上一陣子的連結,Qubes OS 推出了 4.0 版:「Qubes OS 4.0 has been released!」。這個作業系統的副標蠻有趣的,不是「絕對安全的作業系統」,而是用了 「reasonably」這樣的描述:

A reasonably secure operating system

主要是透過虛擬機隔離,但實做了常見會因為虛擬機而被擋下的功能,像是讓你可以直接剪下貼上。而界面上也是儘量做成無縫,像是這張 screenshot 就可以看到三個環境,但儘量給出視窗的感覺,而非 VM 的感覺:

有機會重灌的時候再說好了,系統轉移好累... Orz

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

便宜的 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,可以想像一下整個系統又會多了好幾個元件將責任拆開...