Apr 20, 2022
9 min read
由於在 crypto subsystem 中預期多個 crypto request 可以同時向同一個 crypto engine 發出請求 ，因此 crypto engine driver 必須實作對應機制，使其有能力能應付此情況。此外，結合在前一節有提到 crypto subsystem 的 asynchronous crypto API 流程，較常見的實作方式就是 crypto queue 搭配 worker，額外開一個 kernel thread 來與 crypto engine 進行溝通，並讓 crypto request 按照 FIFO 順序處理，而本文主要針對此設計方式，說明整個運作流程和細節。
Overview
條件 假設 hardware crypto engine 一次只能處理一個 request，將 request 根據需求設置好 register 之後，啟動 crypto engine 進行運算，運算完結果後才能換下一個 request。 當運算出結果後，crypto engine 會舉起 status interrupt，通知外部已運算完成。 多個 Request 有可能同時對 hardware crypto engine 發出請求。 一個完整的 crypto request 流程包含三個 API call: Init → Update → Final， Final 結果回傳後，則此 crypto request 將會被釋放，不再使用。 想法 建立一個全域的 crypto request list，將進來的 request 依序排到 list 當中。 建立一個 worker (kernel thread) 和對應的 work queue 來與 hardware crypto engine 進行溝通。worker 的任務除了從 crypto request list 中取出 request 來處理之外，也可能會包含 crypto engine 的初始化和資源釋放等工作。 註冊 interrupt handler，當 status interrupt 舉起時，呼叫 user 自定義的 completion callback function 來完成最後的流程。如果當前是執行最後的 final API call 且 request 有自定義的 resource 需要被釋放，則會在呼叫完 callback function 後執行。 實作 Linux kernel version: v5.17.3
Feb 26, 2022
9 min read
在 crypto subsystem 中，crypto API 分成 asynchronous (異步) 和 synchronous (同步) 兩種機制。
最早版本的 crypto API 其實只有 synchronous crypto API，但隨著要處理的資料量增加，運算和資料傳輸時間也可能大幅拉長，此時 synchronous crypto API 有可能讓處理流程陷入較長時間的等待，因此後來引入了 asynchronous crypto API，供使用者依據自己的使用場景來選擇適合的機制。
而 asynchronous 與 synchronous crypto API 在命名設計上有所區別，asynchronous 會在前綴多加一個 a 字，反之 synchronous 則是 s 字，以 hash 為例：
Feb 15, 2022
11 min read
介紹由應用層所發出的 crypto(cryptography) request，透過 system call 將 request 傳送到 Linux kernel 端，並經由 crypto subsystem 將 request 轉發給硬體算法引擎 (hardware crypto engine) 的流程。
Overview Crypto subsystem 是 Linux 系統中負責處理 crypto request 的子系統，除了包含流程控制機制之外，另一個重要特色就是提供演算法實作的抽象層，讓各家廠商能夠依據需求去客製化實作方式。其中一個常見例子就是廠商在硬體架構中加入用以加速特定演算法運算效率的硬體算法引擎，並且透過 crypto subsystem 將驅動硬體算法引擎的流程整合進 Linux 系統中，供其他 kernel module 或是應用層使用。
以下以 openSSL library 如何將 crypto request 傳送到 kernel crypto subsystem 為例子：
Jan 28, 2022
9 min read
Trusted Firmware 是 ARM 基於自家具有 TrustZone 功能的處理器所實作的開源程式，其主要目的是讓相關廠商可以更快速地將 TrustZone 架構性的整合到產品當中，此外同時也是廠商要取得 ARM PSA certification 認證的參考資源。由於近年來資安議題逐漸受到重視，愈來愈多客戶開始尋找結合硬體實現的安全方案，因此就有這個機會了解一下 Trusted Firmware 軟體架構及其中的 secure boot 流程。Trusted Firmware 包含了幾個專案，這篇文章是以其中的 Trusted Firmware-M(Arm v7-M & v8-M) 為例，如果是 A 系列的處理器則有 Trusted Firmware-A 可供參考。
Overview 首先先來看 Trusted Firmware-M 的架構：
image resource: developer.arm.com
最主要的概念是透過硬體控制 (記憶體位置區間、權限控管等）的方式，將原先的執行環境切割成 secure processing enviroment(SPE) 和 non secure processing enviroment(NSPE) 兩個執行環境。SPE 主要是提供需要安全保護的服務，例如韌體更新、加解密；而 NSPE 則是一般使用者執行應用程式的環境。如果在 NSPE 中執行的應用程式使用到 secure 層級的服務，則需要透過特定 API 來呼叫（這個概念類似作業系統的 user-space 和 kernel-space 會透過 system call 來溝通），這樣可以限制 NSPE 的操作權限，避免重要機密資源外洩。
Jan 15, 2021
9 min read
閒聊 這篇算是接續上次 Meetup 分享會的內容，由於有人提出 password manager 的相關疑問，覺得會不會因為使用 password manager 導致所有隱私資料被看光。與其猜測，不如來看看他們所提出的 security 方案，這篇以 1password 為例，整理其中 security white paper 所提到的保存資料方式，來檢視是不是能夠防止資料被盜取。
Master Password / Secret Key / Vault 在說明 security model 之前，要先了解幾個基本的要素：
Master password (your password) Secret key (account + 26 bytes random data) Vault (sensitive data)
Dec 23, 2020
3 min read
閒聊 12 月份完成好幾項目標，其中一項就是催生 GDG Hsinchu 12 月份的 Meetup 線下聚會。這次活動跟著 Google 在 12 月時舉辦的 Chrome Dev Summit 2020 一同推出，取自 CDS 中的部分 SMS-OTP 內容，並結合既有的 password-based authentication 與未來有可能普及的 FIDO 2 認證機制，整理出一份 Web Authentication Security 的技術分享。其中對我來說，比較有趣的地方在於理解機制的實現原理，包含資料溝通和驗證，以及可能會產生的安全問題。其實標準規範對於開發者來說相當重要，透過分析 protocol 的行為，可以讓開發者在開發整合性功能的時候，更清楚這些 library 要在什麼時機點使用，以及為什麼要使用這些 functions，這也是我每次進行技術分享時，最希望能夠帶給與會者的內容。
image resource: developer.arm.com
