device

軟體模擬 FIDO2 裝置

看到「Virtual FIDO」這個專案，用軟體模擬 FIDO2 裝置：

Virtual FIDO is a virtual USB device that implements the FIDO2/U2F protocol (like a YubiKey) to support 2FA and WebAuthN.

就安全性來說有點本末倒置，畢竟硬體確保了 secret 無法被軟體直接搬走，而這個軟體模擬的方式就沒辦法了，這個專案比較像是實驗示範性質...

翻了一下 Hacker News 上也有人提到這個問題：「Show HN: A virtual Yubikey device for 2FA/WebAuthN (github.com/bulwarkid)」，但也有提到「tpm-fido」這個專案，用 TPM 來保護：

tpm-fido is FIDO token implementation for Linux that protects the token keys by using your system's TPM. tpm-fido uses Linux's uhid facility to emulate a USB HID device so that it is properly detected by browsers.

這個至少有一點保護，但還是不像實體的 YubiKey 那樣會需要碰一下才認證。

Apple 在 iOS 16、iPadOS 16 與 macOS Ventura 上推出 Lockdown Mode

Apple 在 iOS 16、iPadOS 16 與 macOS Ventura 上推出了 Lockdown Mode：「Apple expands industry-leading commitment to protect users from highly targeted mercenary spyware」。

Lockdown Mode 主要是透過降低被攻擊的面積以提昇安全性，依照 Apple 的預想，主要是針對被政府單位盯上的族群：

Apple is previewing a groundbreaking security capability that offers specialized additional protection to users who may be at risk of highly targeted cyberattacks from private companies developing state-sponsored mercenary spyware.

在 Lockdown Mode 下目前列出來的限制：

Messages: Most message attachment types other than images are blocked. Some features, like link previews, are disabled.
Web browsing: Certain complex web technologies, like just-in-time (JIT) JavaScript compilation, are disabled unless the user excludes a trusted site from Lockdown Mode.
Apple services: Incoming invitations and service requests, including FaceTime calls, are blocked if the user has not previously sent the initiator a call or request.
Wired connections with a computer or accessory are blocked when iPhone is locked.
Configuration profiles cannot be installed, and the device cannot enroll into mobile device management (MDM), while Lockdown Mode is turned on.

列出來的這些的確都是之前 0-day 常被拿來打的東西，把攻擊面積縮小的確會有不少幫助。

這應該是業界第一個大咖跳進來做這個 (也就兩個大咖？)，第一次搞未必會完美，但算是個開始，後面應該會有更多的面積被考慮進去...

IdenTrust 願意再幫 Let's Encrypt 交叉簽三年

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrust 幫 Let's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期，而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證，造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。

文章出來過了一個多月後，剛剛看到 Let's Encrypt 發佈消息，IdenTrust 願意再交叉簽名三年：「Extending Android Device Compatibility for Let's Encrypt Certificates」，當時猜測發文是要讓 IdenTrust 表態，看起來目的達成了...

話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣，之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...

FBI 手上的 GrayKey 可以解 iPhone 11 Pro Max

在「FBI Successfully Unlocks iPhone 11 Pro in Ohio, Casting Doubt on Claims it Needs Apple's Help in Florida Mass Shooter Case」這邊看到的消息，看起來 FBI 手上的 GrayKey 可以解開 iPhone 11 Pro Max 了...

先前 GrayKey 只有舊型的可以解，像是之前揭露的 iPhone 5 或是 iPhone 7，現在看起來找到新的漏洞可以打穿新的版本，所以升級了：

Forbes has previously revealed a GrayKey brochure that showed it worked on older devices, and the two iPhones acquired by the FBI in the most recent Pensacola case are an ‌iPhone‌ 5 and an ‌iPhone‌ 7, which strongly suggests that investigators are already capable of unlocking them.

魔與道的競爭...

Canonical 推出的 Dqlite (High-Availability SQLite)

第一眼看到的時候直接有種不知道 Canonical 在幹什麼的感覺，翻完說明後大概知道可以用的地方，但還是覺得範圍有點小：「Dqlite - High-Availability SQLite」。

一種使用情境是，在 embedded system 上面同步資料的一種方案... 吧？例如網路連線的頻寬或是品質受限，無法順利傳到 Internet 端的伺服器上，所以希望在本地端就可以解決一些事情，但又不方便在本地端直接弄個 PostgreSQL 出來？

Dqlite is a fast, embedded, persistent SQL database with Raft consensus that is perfect for fault-tolerant IoT and Edge devices.

另外一個是用到了 C 實做的 Raft 協定：

Dqlite (“distributed SQLite”) extends SQLite across a cluster of machines, with automatic failover and high-availability to keep your application running. It uses C-Raft, an optimised Raft implementation in C, to gain high-performance transactional consensus and fault tolerance while preserving SQlite’s outstanding efficiency and tiny footprint.

讓 IoT 裝置參與 Raft 嗎... 好像只能說有趣... XD

OAuth 2.0 Device Authorization Grant

看到「OAuth 2.0 Device Authorization Grant」這個變成 PROPOSED STANDARD 了，看了一下歷史是 2015 年年底的時候被提出來的，記得在前公司的時候有用這個 (當時還是 draft) 做智慧型電視上的 OAuth 認證：

The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

因為這些裝置的輸入設備受限，照原來 OAuth 2.0 的方式授權，使用者體驗不會太好 (可以想像用遙控器登入 Google 或是 Facebook 帳號？)，所以設計了替代的方案，讓使用者可以用手機授權 (比較常見的是透過 QR code)，然後電視機再去取得 access token。

Apple 新的「Find My」帶來的隱私問題

這次 WWDC 推出的新功能，已經有人在討論機制與隱私問題了：「How does Apple (privately) find your offline devices?」。

前一代的「Find my iPhone」需要透過網路與 GPS 資料才能在系統上看到，這一代則是加上 BLE beacon，然後任何一台 iOS device 收到後就回傳回給蘋果：

Every active iPhone will continuously monitor for BLE beacon messages that might be coming from a lost device. When it picks up one of these signals, the participating phone tags the data with its own current GPS location; then it sends the whole package up to Apple’s servers.

幾個隱私問題在於，代傳的 iOS device 也會暴露位置資訊給蘋果，另外收到 BLE beacon 的 iOS device 本身是否可以解讀遺失機器的資訊？而商家看起來也可以利用這個方式主動發送攻擊而得知不少資料 (像是文章裡提到先前蘋果透過 randomize mac address 加強隱私的問題，這邊又多開了一個洞)，現在蘋果給的資訊還不夠清楚，需要真的逆向工程確認才知道...

利用 Sensor 校正資訊產生 Device Fingerprint 的隱私攻擊

看到「Fingerprinting iPhones」這篇提出的攻擊，標題雖然是提到 iPhone，但實際上攻擊包括了 Android 的手機：

You are affected by this fingerprinting attack if you are using any iOS devices with the iOS version below 12.2, including the latest iPhone XS, iPhone XS Max, and iPhone XR. You are also likely to be affected if you are using a Pixel 2/3 device, although we hypothesise the generated fingerprint has less entropy and is unlikely to be globally unique. A SensorID can be generated by both apps and mobile websites and requires no user interaction.

目前 iPhone 升級到 12.2 之後可以緩解這個問題，Android 看起來還不清楚...

攻擊的方式是透過手機在出場前會使用外部的校正工具，找出手機內 sensor 所偵測到的值與實際值的差異，然後把這些資訊燒到韌體裡，當呼叫 API 時就可以修正給出比較正確的值。

而因為這些校正資訊幾乎每一隻手機都不一樣，而且不會因為重裝而變更 (即使 factory reset)，加上還可以跨 app 與 web 追蹤，就成為這次攻擊的目標：

In the context of mobile devices, the main benefit of per-device calibration is that it allows more accurate attitude estimation.

資訊量其實相當大，透過 app 分析可以得到 67 bits entropy，透過網頁也有 42 bits entropy，而且不怎麼會變：

In general, it is difficult to create a unique fingerprint for iOS devices due to strict sandboxing and device homogeneity. However, we demonstrated that our approach can produce globally unique fingerprints for iOS devices from an installed app -- around 67 bits of entropy for the iPhone 6S. Calibration fingerprints generated by a website are less unique (~42 bits of entropy for the iPhone 6S), but they are orthogonal to existing fingerprinting techniques and together they are likely to form a globally unique fingerprint for iOS devices.

We have not observed any change in the SensorID of our test devices in the past half year. Our dataset includes devices running iOS 9/10/11/12. We have tested compass calibration, factory reset, and updating iOS (up until iOS 12.1); the SensorID always stays the same. We have also tried measuring the sensor data at different locations and under different temperatures; we confirm that these factors do not change the SensorID either.

目前提出來的解法是加入隨機值的噪音 (iOS 的作法)，不過作者有建議預設應該要關閉 js 存取 sensor 的權限：

To mitigate this calibration fingerprint attack, vendors can add uniformly distributed random noise to ADC outputs before calibration is applied. Alternatively, vendors could round the sensor outputs to the nearest multiple of the nominal gain. Please refer to our paper for more details. In addition, we recommend privacy-focused mobile browsers add an option to disable the access to motion sensors via JavaScript. This could help protect Android devices and iOS devices that no longer receive updates from Apple.

不過當初這群人怎麼會注意到的...

Dropbox 免費版限制三個裝置更新...

Dropbox 決定限制免費版的裝置數量，最多只能有三個裝置同步：「Dropbox adds three-device limit for free users」，對應的頁面是「Is there a limit to the number of devices I can link to my account?」。

既有的裝置不受限，但無法再增加：

If you're a Basic user and you linked more than three devices prior to March 2019, all of your previously linked devices will remain linked, but you can’t link additional devices.

另外一個選擇是付費版，最低是 1TB USD$9.99/month (年繳是 USD$99/year)。

看起來像是養肥了要殺，不過這個領域相關的技術應該是夠成熟，而且也不會用到什麼特別的功能，應該會去看看其他平台的情況，像是 Sync 與 pCloud。

其中 Sync 有免費版 (空間限制 5GB，付費版 500GB USD$49/year)，不過官方不支援 Linux，有人用 Wine 跑過，但據說穩定性與效能都不太好：「Sync.com in Linux」。

pCloud (500GB EUR$47.88/year) 也是剛剛提到在 Linux 上跑 Sync 的人後來測試的服務，官方有支援 Linux (看起來是透過 AppImage 包裝)，也許可以測試看看。

另外一個是自己一直都有在用的 Syncthing，不過設定同步的操作上只有 web interface，而且因為是信任架構，需要多台互相設定，沒那麼方便...

JavaScript Framework 不可避免的成本

看到「The Baseline Costs of JavaScript Frameworks」這篇文章在研究目前主流 JavaScript Framework 無法避免的成本到底有多高。

文章的結論是目前常見的 JavaScript Framework 其實都很肥重，在網路速度不快的地方得花不少時間下載，在非旗艦的手機上會需要花不少時間處理 (parse & compile)。

這是 gzip 後的大小：

這是 parse & compile 的時間：

這是下載時間 (扣除 latency 與 TLS connection 建立時間)：

並不是說不能用，但重點會在客群：

But it’s important to consider your audience. If you’re building for resource constrained devices — which you certainly are if your product targets a country like India — you could consider using a lighter framework such as Riot or Preact. Your users will thank you.

最後有建議如果只是要呈現資訊，不要用整套 JavaScript Framework，在有需要互動的地方另外寫就好了：

For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts.