Home » Posts tagged "secure"

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

下一個版本的 Chrome (56) 將會對要求卡號或是密碼的 HTTP 站台標示「Not Secure」

如同之前在「Google Chrome 56 將會對 HTTP 網站標示「Not secure」」提到的規劃,Google Chrome 56 (也就是下一個版本) 將會對要求卡號或是密碼的站台標示「Not Secure」:「Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky」。

比較九月的 screenshot 與最近的 screenshot,從「Not secure」變成「Not Secure」了... 這是九月的:



Apple 打算把 iCloud 加密用的 Key 放到用戶端

在經過最近 FBIApple 的戰鬥中 (FBI–Apple encryption dispute),Apple 正規劃把 iCloud 加密所使用的 key 放到用戶端裝置上,而非放在伺服器端:「Apple to Hand iCloud Encryption Key Management to Account Holders」:

In effect, Apple is following the lead of secure cloud services such as SpiderOak which has been offering what it calls “Zero Knowledge” cloud storage. By that, SpiderOak retains no information about whatever is stored in its cloud service, nor the means of gaining access to it.

也就是加解密都放在 client 端處理,server 端只是 storage。

這類型最大的問題是 server 端沒辦法運用資料,但 iCloud 的確可以放掉這些功能 (搜尋之類的),純粹當 storage 使用,藉以讓使用者自己裝置保護。

而蘋果在使用者的裝置上把類似於 HSM 的系統做的頗強大... 不知道 Android 有沒有機會也跟進。(雖然我自己是用 Apple 家的東西...)

Mozilla 對非 HTTPS 站台的抵制

Mozilla Security Blog 上 Richard Barnes (Firefox Security Lead) 宣佈對非 HTTPS 站台的抵制政策。規劃在之後的 Firefox 新功能限定在 HTTPS 網站上:「Deprecating Non-Secure HTTP」。


  1. Setting a date after which all new features will be available only to secure websites
  2. Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.

在「Deprecating Non-Secure HTTP (PDF)」這邊有 FAQ 可以參考。

溫水煮青蛙:Windows 10 與 Secure Boot

Microsoft 的 Windows 10 更進一步限制了 Secure Boot 的選擇:「Linux’s worst-case scenario: Windows 10 makes Secure Boot mandatory, locks out other operating systems」。

之前是關閉,現在則是必須要 optional (包裝用語啦,意思是預設值打開,使用者可以進 UEFI console 關閉):

OEMs are still required to ship Secure Boot, but the previously mandatory disable switch is now optional

是個「溫水煮青蛙」的概念,如果這次沒擋下來,下一次 Microsoft 就會規定 OEM 出版只能在安裝在強制打開 Secure Boot 的機器上使用 (不能關閉)。

安全的 SSH (Secure Secure Shell)

Twitter 上看到「Secure Secure Shell」這篇文章,介紹要如何加強 OpenSSH

文章裡分成四個部份討論,從 Key exchange 開始,Authentication、Symmetric ciphers 以及 Message authentication codes。

先把已知有問題的技術都先拿掉 (像是 MD5RC4DES),然後有被 NSA 影響到的技術,而且有不錯的替代方案的也拿掉。

另外還介紹了 Tor hidden service 下的保護。