Amazon Detective:用 Machine Learning 分析可能的安全問題

也是這次 AWS re:Invent 發表的服務,透過 Machine Learning 分析可能的安全問題:「Introducing Amazon Detective」。

透過現有的各種 log 建立模型分析:

Amazon Detective can analyze trillions of events from multiple data sources such as Virtual Private Cloud (VPC) Flow Logs, AWS CloudTrail, and Amazon GuardDuty, and automatically creates a unified, interactive view of your resources, users, and the interactions between them over time.

依照 log 的量算錢的,然後 preview 階段不收費,所以有興趣的人可以開起來跑看看?

iOS 上的 Yubico Authenticator App 正式支援 NFC

Yubico 宣佈 iOS 版的 app (Yubico Authenticator) 正式支援 NFC 了:「Yubico Authenticator App for iOS Now Supports NFC」,先前在九月時的說明告知了 iOS 13 的 API 允許透過 NFC 讀與寫 (先前只能讀):「iOS 上的 Yubikey」。

作業系統的要求就如前面提到的需要 iOS 13+,而硬體上需要 iPhone 7 之後的機種,之後看看市場上的反應...

AWS 提供 Machine Learning 能力的自動 Code Review 服務

AWS 推出了 Code Review 服務 Amazon CodeGuru,使用 machine learning 提供建議:「AWS announces Amazon CodeGuru for automated code reviews and application performance recommendations」。

從界面就可以看出來同時支援 GitHub 與自家的 CodeCommit,看起來可以給不少建議,但網站上沒有提到 security 這塊,本來以為產品的定位不在這邊:

不過 FAQ 裡還是有提到常見的 security issue:

Q: What type of issues are detected by Amazon CodeGuru Reviewer?

Amazon CodeGuru Reviewer checks for concurrency issues, potential race conditions, un-sanitized inputs, inappropriate handling of sensitive data such as credentials, resource leaks, and also detects race conditions in concurrent code.

然後 FAQ 裡提到目前只支援 Java:

Amazon CodeGuru Reviewer currently supports Java code stored in GitHub and AWS CodeCommit repositories.

服務的價位是使用行數計算,不過那個 per month 沒看懂是什麼意思:

Code scan (pull requests)$0.75 per 100 lines of code scanned per month

另外推出的 Amazon CodeGuru Profiler 則是 APM 類的東西,這塊目前市場上產品也很多,看起來也要被 AWS 進來蹂躪...

RSA-240 (十進位 240 位數) 成功分解

在「RSA-240 Factored」這邊看到的,RSA-240 前幾天被解開了:

RSA-240 = 124620366781718784065835044608106590434820374651678805754818788883289666801188210855036039570272508747509864768438458621054865537970253930571891217684318286362846948405301614416430468066875699415246993185704183030512549594371372159029236099 = 509435952285839914555051023580843714132648382024111473186660296521821206469746700620316443478873837606252372049619334517 * 244624208838318150567813139024002896653802092578931401452041221336558477095178155258218897735030590669041302045908071447

有效長度是 795 bits,相較於十年前解出來的 RSA-768 (768 bits) 又多了「一些」。看了一下,算法上沒有太多突破,主要是硬體的發展與軟體的最佳化有進展...

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 吧?當時在寫小工具的時候發現的...

Sandboxie 決定開源

Sandboxie 目前是 Sophos 旗下的產品,主要的功能是在 Windows 下產生一個獨立的環境 (沙箱) 執行某些應用程式,而這些應用程式的變更雖然會被記錄起來,但不會影響到系統本體,所以先前也買了一套起來拿來跑一些程式...

剛剛看到消息提到 Sandboxie 決定要 open source:

Sophos is excited to announce that we are making Sandboxie a free tool, with plans to transition it to an open source tool.

然後目前看起來還在整理程式碼,在整理完之前會直接先解放目前的版本,讓所有功能都免費使用:

Until the open source transition is completed we have decided to make all restricted features of Sandboxie completely free.

不過沒看懂 open source 的原因...

Windows 10 想要拿掉 WEP 與 TKIP...

OSnew 上看到「Windows 10 to disallow WEP encryption」這個消息,裡面題到了 Windows 10 打算要幹掉無線網路的 WEP 支援。裡面是引用了「Windows 10 features we’re no longer developing」這則消息,可以看到除了 WEP 以外,還有 TKIP 也打算拔掉:

Since the 1903 release, a warning message has appeared when connecting to Wi-Fi networks secured with WEP or TKIP (which are not as secure as those using WPA2 or WPA3). In a future release, any connection to a Wi-Fi network using these old ciphers will be disallowed. Wi-Fi routers should be updated to use AES ciphers, available with WPA2 or WPA3.

之前去日本的時候還是有不少飯店用 WEP 啊,看起來總算有動力要淘汰了...

Google 與 Cloudflare 測試 Post-Quantum 演算法的成果

這幾年量子電腦的進展不斷有突破,雖然到對於攻擊現有的密碼學看起來還有一段時間,但總是得先開始研究對量子電腦有抵抗性的演算法...

其中 Google Chrome 的團隊與 Cloudflare 的團隊手上都有夠大的產品,兩個團隊合作測試的結果在學界與業界都還蠻重視的:「Real-world measurements of structured-lattices and supersingular isogenies in TLS」、「The TLS Post-Quantum Experiment」。

Google Chrome 這邊是使用了 Canary 與 Dev 兩個 channel,有控制組與兩個新的演算法:

Google Chrome installs, on Dev and Canary channels, and on all platforms except iOS, were randomly assigned to one of three groups: control (30%), CECPQ2 (30%), or CECPQ2b (30%). (A random ten percent of installs did not take part in the experiment so the numbers only add up to 90.)

這兩個演算法有優點也有缺點。一個是 key 比較小,但運算起來比較慢 (SIKE,CECPQ2b);另外一個是 key 比較大,但是運算比較快 (HRSS,CECPQ2):

For our experiment, we chose two algorithms: isogeny-based SIKE and lattice-based HRSS. The former has short key sizes (~330 bytes) but has a high computational cost; the latter has larger key sizes (~1100 bytes), but is a few orders of magnitude faster.

We enabled both CECPQ2 (HRSS + X25519) and CECPQ2b (SIKE/p434 + X25519) key-agreement algorithms on all TLS-terminating edge servers.

感覺還是會繼續嘗試,因為這兩個演算法的缺點都還是有點致命...