Amazon EC2 支援 NitroTPM 與 UEFI Secure Boot

也是在清 RSS reader 的時候翻到的公告,在兩個禮拜前 AWS 宣佈 Amazon EC2 支援 NitroTPMUEFI Secure Boot:「Amazon EC2 Now Supports NitroTPM and UEFI Secure Boot」。

NitroTPM 相容於 TPM 2.0 的界面,所以有支援 TPM 2.0 的軟體都可以利用 (像是 Windows 11):

Nitro Trusted Platform Module (NitroTPM) is a virtual device that is provided by the AWS Nitro System and conforms to the TPM 2.0 specification.

之前在研究 LUKS 的時候也有看到 TPM 相關的資料:

Linux Unified Key Setup (LUKS) or dm-verity on Linux are examples of OS-level applications that can leverage NitroTPM too.

然後支援的平台有些限制,只有 IntelAMD 的平台有支援,而且還要扣掉 Xen、Mac 以及 bare metal 的機種:

At the moment, we support all Intel and AMD instance types that supports UEFI boot mode. Graviton1, Graviton2, Xen-based, Mac, and bare-metal instances are not supported.

ARM 那邊有自己的一套,不太玩 TPM 大概可以理解,Xen 大概是不想支援 (停止開發新功能之類的原因),Mac 可能是 Apple 的硬體限制,最後的 bare metal 是因為沒辦法虛擬化?

然後這個功能不另外收費,看起來幾乎是全球性一次更新:

There is no additional cost for using NitroTPM. It is available today in all AWS Regions, including the AWS GovCloud (US) Regions, except in China.

Linux 打算合併 /dev/random 與 /dev/urandom 遇到的問題

Hacker News 上看到「Problems emerge for a unified /dev/*random (lwn.net)」的,原文是「Problems emerge for a unified /dev/*random」(付費內容,但是可以透過 Hacker News 上的連結直接看)。

標題提到的兩個 device 的性質會需要一些背景知識,可以參考維基百科上面「/dev/random」這篇的說明,兩個都是 CSPRNG,主要的分別在於 /dev/urandom 通常不會 block:

The /dev/urandom device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot.

/dev/random 不保證不會 block,有可能會因為 entropy 不夠而卡住:

/dev/random typically blocked if there was less entropy available than requested; more recently (see below, different OS's differ) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently.

然後順便講一下,因為這是 crypto 相關的設計修改,加上是 kernel level 的界面,安全性以及相容性都會是很在意的點,而 Hacker News 上的討論裡面很多是不太在意這些的,你會看到很多「很有趣」的想法在上面討論 XDDD

回到原來的文章,Jason A. Donenfeld (Linux kernel 裡 RNG maintainer 之一,不過近期比較知名的事情還是 WireGuard 的發明人) 最近不斷的在改善 Linux kernel 裡面這塊架構,這次打算直接拿 /dev/random 換掉 /dev/urandom:「Uniting the Linux random-number devices」。

不過換完後 Google 的 Guenter Roeck 就在抱怨在 QEMU 環境裡面炸掉了:

This patch (or a later version of it) made it into mainline and causes a large number of qemu boot test failures for various architectures (arm, m68k, microblaze, sparc32, xtensa are the ones I observed). Common denominator is that boot hangs at "Saving random seed:". A sample bisect log is attached. Reverting this patch fixes the problem.

他透過 git bisect 找到發生問題的 commit,另外從卡住的訊息也可以大概猜到在虛擬機下 entropy 不太夠。

另外從他們三個 (加上 Linus) 在 mailing list 上面討論的訊息可以看到不少交流:「Re: [PATCH v1] random: block in /dev/urandom」,包括嘗試「餵」entropy 進 /dev/urandom 的 code...

後續看起來還會有一些嘗試,但短期內看起來應該還是會先分開...

OpenSSH 的 scp 改用 SFTP 協定

在「By default, scp(1) now uses SFTP protocol」這邊看到的,OpenSSH 的 scp 改用 SFTP 協定了,原因也有附在文章裡:

SFTP offers more predictable filename handling and does not require expansion of glob(3) patterns via the shell on the remote side.

要注意這是 BC-break change,有些之前會動的 case 在改用 SFTP 後會爛掉,但這算是前進了一大步,scp 因為 spec 的關係很難維護安全性。

在「Deprecating scp」這邊也有提到相關的問題,另外也給出了一些範例。

Mac OS 7/8/9 上的 SSH client

Hacker News 首頁上看到「Ssheven: A modern SSH client for Mac OS 7-9 (github.com/cy384)」這個,為了 Mac OS 7/8/9 (PowerPC 平台) 實做 SSH client。

翻了一下程式碼,看起來是透過 libssh2 實做加解密的部份,依照 libssh2 的官網,支援的演算法雖然不是超級新,但看起來還算可以 (至少有目前還算安全的演算法可以用):

Hacker News 上有看到一些老機器跑出來玩 XD

tikwidd 8 hours ago

So far it's working well on my LC III (68030 with 36mb ram)!
I'm writing this comment from the LC III using w3m over ssh :)

Kaspersky Password Manager 的漏洞

Hacker News Daily 上看到「Kaspersky Password Manager: All your passwords are belong to us」這篇,講 Kaspersky Password Manager (KPM) 嚴重的安全漏洞,另外在 Hacker News 上的討論「Kaspersky Password Manager: All your passwords are belong to us (ledger.com)」也有提到一些有趣的東西。

標題的 All your passwords are belong to us 是出自「All your base are belong to us」這個梗的變形。

這包安全問題主要的原因是因為 KPM 沒有使用 CSPRNG,而且也沒有正確 seed,所以極為容易被猜出密碼本身。

KPM 的 Web 版使用了 Math.random(),在各家瀏覽器主要是用 xorshift128+ 實做 Math.random(),作者沒有針對這塊再花時間研究,但很明顯的 Math.random() 不是個 CSPRNG:

The underlying PRNG used by Chrome, Firefox and Safari for Math.random() is xorshift128+. It is very fast, but not suitable to generate cryptographic material. The security consequences in KPM has not been studied, but we advised Kaspersky to replace it with window.crypto.getRandomValues(), as recommended by the Mozilla documentation page previously mentioned.

Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.

而桌機版則是用了 MT19937,理論上取得 624 bytes 的輸出後就可以重建整個 PRNG 的內部狀態 (於是就可以預測後續的 output),但這代表你要知道其他網站的密碼,這點其實有點困難。

但作者發現 KPM 在產生 MT19937 的 seed 只跟時間有關,超級容易被預測:

So the seed used to generate every password is the current system time, in seconds. It means every instance of Kaspersky Password Manager in the world will generate the exact same password at a given second.

於是可以直接暴力解出所有的可能性:

The consequences are obviously bad: every password could be bruteforced. For example, there are 315619200 seconds between 2010 and 2021, so KPM could generate at most 315619200 passwords for a given charset. Bruteforcing them takes a few minutes.

Hacker News 上有不少陰謀論的討論,像是:

Getting some DUAL_EC prng vibes.

Insert Kaspersky owned by Russia intelligence conspiracy here...

另外 Kaspersky 跟俄羅斯軍方的關係也是很知名,這些東西大概要到十來年後才會知道...

Firefox 83 推出 HTTPS-Only Mode

MozillaFirefox 83 推出了 HTTPS-Only Mode:「Firefox 83 introduces HTTPS-Only Mode」。

就如同名稱的說明,這個模式只會允許 HTTPS 的連線,主要的設計方式是把「開 HTTP 連線」當作一種特殊權限,就像 notification 之類的權限一樣:

When you enable HTTPS-Only Mode:

  • Firefox attempts to establish fully secure connections to every website, and
  • Firefox asks for your permission before connecting to a website that doesn’t support secure connections.

使用者會先在設定裡面開啟這個全域設定:

開了以後如果想要連 HTTP 網站,就會遇到阻擋:

這個功能真的不賴,馬上想到 Tor BrowserTails 應該都會改用這個,畢竟 Tor 的 HTTP 出口常常被搞...

我自己類似的保護措施是把 HTTP 頁面執行 JavaScript 的能力全部關掉,像是這樣 (這邊是 Brave 瀏覽器,是個基於 Chromium 的 fork):

然後對於需要 JavaScript 的 HTTP 頁面,我是透過「Simple JavaScript Toggle」暫時授權。

這樣至少在無法確認 integrity 的情況下不會執行 js,減少可被攻擊的面積...

把 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 的版本沒支援。

Ptt 公告使用安全連線

Ptt 官方公告,建議使用安全連線:「[公告] 請使用安全的連線方式連線本站」。

目前 Ptt 有三種方式可以連線,第一種是 Telnet,這是最古老,支援度最廣泛,但沒有加密的協定。

第二種是 SSH,算是蠻早就支援的安全協定 (至少是 2006,依照「[問題] SSH連接是否變換方式了﹖」這篇),屬於 Trust on first use 的方式,不過在有 DNSSEC 的情況下可以搭配 SSHFP record 避免第一次連線的信任問題。

最後一種登入方式也是安全協定,透過 2011 年定義出來的 WebSocket 連線,這個方法在 Let's Encrypt 盛行後可以透過瀏覽器內的 CA 驗證連線的安全性。

可以理解 SSH 吃的資源比較多,不過在 Linux command line 下好像還沒有什麼比較堪用的 WebSocket 指令可以連線... 而且我記得 Ptt 的 WebSockets 還是使用 BIG5 吧?當時在寫小工具的時候發現的...

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

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