分類: 技術

EME 小整理

這裡的 EME 是指 Encrypted Media Extensions, 顧名思義, 它解決加密的媒體 – 主要是視訊的播放的問題, 而且它是一個 extension, 用來擴充 web browser (瀏覽器) 的功能.  這樣一來就可以在 browser 上播有版權、加密過的電影, 而且無須綁定加解密的演算法.

話說, 我們不是用 Adobe Flash plugin 看了好多年的片子了嗎? 為何最近大家都紛紛棄 Flash 而去呢? 一般的看法 [2] 是微軟長久以來把持著桌機的平台和 IE 瀏覽器, 但並未好好支援網頁視訊這個產業, 所以早期的 Youtube 網站才會需要 Adobe Flash Player (其實是 plugin) 來彌補這個技術缺口. 當我們逐漸使用更多的 mobile device, 就應該使用更好的瀏覽器, 自然也就不需要 Adobe 了. 當然, Adobe 得罪 Steve Jobs 那件事應該也是關鍵的一擊.

根據 W3C 的規範, 播放網頁視訊 (HTML5 video) 需要瀏覽器支援 Media Source Extensions (MSE) [3] 技術. 應用程式 (app) 透過 Java script 把影片的 bit stream 送給平台上的解碼器 (decoder, 或者更廣泛的 media codec) 解碼. 再用播放器把解碼後的影片播出來. 

如果片源有 DRM (Digital rights management ) 加密, 就該 EME 上場了. 在 [4] 裡面有相當完整的描述. 正常來說, Media key 不會跟著片源一起送下來, 而是放在網路上的某個伺服器  (license key server). App 可以經由 CDM  (Content Decryption Module) 介面取回 key 來解密片源. 若是 key 會持續變動, 生命週期  (life time) 只在某一段期間  (session) 內, app 就要反覆透過 CDM 去跟 server 要不同的 key ID, 用於新的 session.

CDM 有時候不只涵蓋解密, 也可以順便解碼. 因此 [4] 說到, CDM 可以定義在 browser, OS, HW decoder, firmware decoder, 或是一個獨立的 module. 此外, 這篇文章還提到 common Encryption, clear key, 和 DASH. 有興趣的人可以讀一下 [4] 這篇.

 

[REF]

  1. https://en.wikipedia.org/wiki/Encrypted_Media_Extensions
  2. https://www.cnet.com/news/firefox-tiptoes-toward-a-world-without-adobe-flash/
  3. https://en.wikipedia.org/wiki/Media_Source_Extensions
  4. http://www.html5rocks.com/en/tutorials/eme/basics/
  5. Media/EME – MozillaWiki – Wiki – Mozilla

 

POSIX signal 小整理

做 SOC 軟體的人常常會收到 bug 的 log, 其中一個常見的類型就是 signal XXX, code YYY, fault address ZZZ. 例如:

Fatal signal 11 (SIGSEGV), code 2, fault addr 0x12345678 in tid 12345 (MyTask)

這個 log 是標準 C library 裡面的 signal.h 所定義的 [1].  參考 ref [2], 裡面有較完整的 code No. 說明, 而 ref [3] 有完整的 POSIX signal 定義和歷史沿革; Ref [4] 是把 Unix signal 做成一張表.

取常用的部分, 重新整理如下. 這些都是 core error, 所以會終止程序, 並且產生 core dump.

Signal

No.

Code

No.

Reason

SIGILL

4

ILL_ILLOPC

1

Illegal opcode.

ILL_ILLOPN

2

Illegal operand.

ILL_ILLADR

3

Illegal addressing mode.

ILL_ILLTRP

4

Illegal trap.

ILL_PRVOPC

5

Privileged opcode.

ILL_PRVREG

6

Privileged register.

ILL_COPROC

7

Coprocessor error.

ILL_BADSTK

8

Internal stack error.

SIGFPE

8

FPE_INTDIV

1

Integer divide by zero.

FPE_INTOVF

2

Integer overflow.

FPE_FLTDIV

3

Floating-point divide by zero.

FPE_FLTOVF

4

Floating-point overflow.

FPE_FLTUND

5

Floating-point underflow.

FPE_FLTRES

6

Floating-point inexact result.

FPE_FLTINV

7

Invalid floating-point operation.

FPE_FLTSUB

8

Subscript out of range.

SIGSEGV

11

SEGV_MAPERR

1

Address not mapped to object.

SEGV_ACCERR

2

Invalid permissions for mapped object.

SIGBUS

10

BUS_ADRALN

1

Invalid address alignment.

BUS_ADRERR

2

Nonexistent physical address.

BUS_OBJERR

3

Object-specific hardware error.

SIGTRAP

5

TRAP_BRKPT

1

Process breakpoint.

TRAP_TRACE

2

Process trace trap.

[REF]

  1. https://zh.wikipedia.org/wiki/Signal.h
  2. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html
  3. http://man7.org/linux/man-pages/man7/signal.7.html
  4. http://people.cs.pitt.edu/~alanjawi/cs449/code/shell/UnixSignals.htm

UPS 快買快裝記

上週六早上, 我一早起來 “拔草測風向", 收 email 看需不需要去加班? ….嗯, 好像一切都在控制之中, 還不錯! 正在得意之際, 9:10 am 那時忽然就停電了! 怎麼回事? 過了一會兒電就來了, 原來是跳電.

雖然只是小小的跳電, 我知道我的部落格主機掛了!  因為以前重灌怕了, 我已經在電腦採用 RAID 1 的設定. 即便如此, 每次不正常關機或是當機, 電腦一定會先說 BCD (Boot Configuration Data) error 開不起來. 這時候讓電腦有電, RAID 狀態就會從 normal 切到 verify, 它自救一段時間之後, 自然而然就恢復正常了. 不過若加上 check disk 這個步驟, 沒有半天的時間搞不定.

以前就曾想要買不斷電系統 (UPS = Uninterruptible Power Supply), 感覺這樣對電腦硬碟比較有保障. 但是畢竟幾年才會發生一次大颱風大地震, 對於突然停電的顧慮, 很容易地就被沖淡了. 這次有點不一樣, 完全不是什麼地震颱風, 充其量是下了一陣暴雨, 說不定只是有人偷接電….不過, 政府選前說不缺電, 選後說 “不保證不缺電", 萬一日後真的缺電了, 會不會變得常常跳電呢? 那是不是應該先買 UPS 概念股呢?

以前飛瑞做 UPS 很有名, 看一下股價適不適合吧!? 不查還好, 一查才發現它早就被併購下市了. 也罷! 我還是自己買一台 UPS 練功吧! 既然飛瑞被買了, 那家比較厲害呢? Google 的結果發現 APC 是世界第一大品牌, 那就是你了!

連飛瑞下市都不知道, 表示我的 database 已經完全不行了! 我發現在有多種規格, 主要是離線式 (off-line), 在線式 (on-line), 在線互動式 (line interleave)…等等選擇! 很快掃描完網路資訊後, 我認為這篇寫得最好 [1]. 雖然它 Google 排名不是很前面, 不過很專業地把我教懂了. “在線互動式" 聽起來很厲害, 但是在線式才是最好的選擇. 由於後者的成本較高, 退而求其次就是買在線互動式.

用簡單幾句話說明, 離線就是指 UPS 的電池平常離線, 外部斷電時才趕快切到電池供電, 在線就是電路永遠經過電池, 互動式就是用電路決定是否經過電池. 這個網站有圖可以看 [2].

再來要決定容量. 我在 1500VA, 1000VA, 700VA 三台當中瞄來瞄去, 不知道我的裝備到底需要幾瓦? 當初我可以買了號稱 900W 的電源供應器, 外加兩個磁碟櫃, 700W 好像不夠捏??? 不過, 等我買了中庸的 1000VA 回家, 它所附的軟體告訴我, 開部落格頂的狀況下頂多只要 120 W…哈!

APC-Watts-768x567

PC 怎麼讀到 UPS 的功耗呢? 主要是靠這根 USB 轉乙太網路的線. USB 端接到電腦, 乙太網路端接到 UPS, 再安裝廠商附的光碟片, 就可以用軟體設定各種使用情境.

bridge-port-1-768x557

以我的需求而言, 主要是希望若上班時間遇到停電, 電腦能夠被正常關機. 電池多大對我其實不重要. 馬上關機都可以, 其他都不用救了. 下圖顯示, 它可以在設定電池剩下幾分鐘電力的時候關機, 最多可選 8 分鐘, 最少是 5 分鐘. 我選多一點以免關不完…

power-off-plan-1-768x571

個人比較重視軟體, 其他硬體開箱事宜, 請看別人的開箱文就好 [3]. 周日凌晨兩點下定, 周一中午 UPS 到貨, 晚上 9 下班, 吃飽飯就趕快把它裝起來, 還順手就寫了這篇記錄, 所以名為"快買快裝". 原本用週日買是希望用到聯邦理財白金卡的 2% 回饋金, but 自從我用這張卡分 6 期繳所得稅之後, 也不算佔它多大便宜, 但現在它在線上購物時就一定刷不過了, 只能在店面用, 形同管制. 所以我還是沒用到它的 2% 回饋…

[REF]

1.  UPS 不斷電系統的基本介紹與採購建議教學

2. http://www.joysong.com.tw/03_11.asp

3. 不斷電系統 APC Back-UPS Pro 1000 體驗測試與介紹 (BR1000G開箱文)

WAI-ARIA 小註解

所謂 WAI-ARIA 是指 Web Accessibility Initiative’s Accessible Rich Internet Applications, 究竟何謂也？ＷAI 的部分指 “無障礙網頁倡議" 或是 “可訪問性倡議”.  就字面上來看, 就是一種讓網路使用變簡單的提案.

根據 [1],  W3C 在  WCAG 2.0 裡將無障礙定義為: “縱使使用者能力不一，也能輕易使用網頁所提供的資訊和服務。“ (Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible to people with disabilities. [2])

舉例來說, 網頁上放了一張圖, 那麼也要有文字說明. 如果使用顏色來區隔, 那麼也要有顏色以外的替代方案. 考慮到這些, 至少對於視障或是色盲的人上網比較方便. 同樣也有人行動不便, 那麼易於瀏覽或是輸入就對他們很重要.

WCAG 2.0 已經把可以用的招數分為 4 個 原則, 每個原則底下又有 guideline. 主要就是讓使用者可以容易感知, 操作, 了解, 並且穩固.
Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
Operable – User interface components and navigation must be operable.
Understandable – Information and the operation of user interface must be understandable.
Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

WCAG 2.0 將符合規範的程度 (Conformance Level) 分為 3 級: level A~ level AAA. 不過, 即使是到了最高級的 AAA, WCAG 2.0 也說不能保證沒問題. (“Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive – 認知 language and learning areas.")

至於 ARIA 有 1.0 和 1.1 [3] 兩個版本, 他們描述了如何具體實踐 WAI. 根據 [4], [5], ARIA 最明顯的實現方式在於加入 role 屬性 (landmark roles). 所謂的 role 就是角色, 在既有的 HTML 網頁當中, 額外描述這段 HTML 的功能. 例如: 

  • role=”banner”
  • role=”navigation” (e.g., a menu)
  • role=”main” (the main content of the page)
  • role=”complementary” (e.g., a sidebar)
  • role=”contentinfo” (meta data about the page, e.g., a copyright statement)
  • role=”search”
  • role=”form”
  • role=”application” (a web application with its own keyboard interface)

如果一個網頁中有兩個同樣的 role, 就要進一步用不同的 (aria-)label 來區隔.

  • <div role=”navigation” aria-label=”Main menu”>
  • <div role=”navigation” aria-label=”User menu”>

除了 role 之外, 另外一個特色是多了 state (狀態) 和 property (屬性). 重要的有下面這些:

state 的好處是, 讓使用者可以知道這個控制項的狀態, 例如 aria-checked 的狀態有 true, false, mixed 三種, 我們就知道 checkbox 點了沒有? 至於 propoerty 可以描述一個欄位允許的最大值, 最小值. 這的確也是很重要. State 和 property 的細節, 以及略過不提的其他特點等等, 可多參考中文的 [5], 這裡就先略過了.

最後來看一眼和我們工作有關的部分. 增加了 WAI-ARA 的支援之後, 它需要強大的底層支援, 如果要把文字敘述唸出來給視障的人聽, 系統就要具備文字轉語音 (TTS – Text to Speech) 的能力. 這些基礎建設相當於下圖 (來自[2]) 最右邊的方塊, 這個 Assistive Technology 就是系統要提供的了.

ARIA-Model-1-768x464

[REF]

  1. 建置 無障礙網頁 的小秘訣
  2. WCAG 2.0
  3. Accessible Rich Internet Applications (WAI-ARIA) 1.1
  4. ARIA Landmark Roles
  5. WAI-ARIA 介紹之二
  6. Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)

FDE 小破解

此處的 FDE 是指 Full Disk Encryption.

根據 [1] 這篇文章, 他在 Qualcomm 的系統中找到了 FED 的漏洞. 下面我把這篇文章的重點摘要出來, 細節就略過了.

首先我們都知道加密需要密碼, 因此好用的方式就是把硬體上的唯一密碼 (unique HW key) 和使用者輸入的密碼 (Passcode key) 做運算, 得到一個沒有人知道的新密碼. 下圖是 Apple iOS 用的方法. (KDF = key derivation function)

Apple’s FDE KDF

試想, 如果我把整個 FLASH (eMMC or SD Card) 裡面的資料都加密了. 那我換了密碼之後, 是否要把整個資料重新加密一遍? 當然不可能, 新的密碼只能用來加密 “File key", 而加密真正資料 (file contents) 的 key 是不變的.

Android 的做法也類似 [2].

Androids-FDE-1-768x487
Android FDE’s KDF
  1. 首先裝置隨機產生一個 16 byte 的 master key (Device Encryption Key – DEK), 然後準備一把鹽巴調味 (16 byte = 128 bit random-generated salt).
  2. 用 user password 加鹽巴 scrypt 出 32 byte (=256 bit) 的中間 key 1 (IK1 = intermediate key 1).
  3. 把 IK1 前面加一個 zero byte, 後面加 233 個 zero byte 墊成 256 bit (padded IK1) , 這是因為裝置上的 key (hardware-bound private key = HBK) 就是 256 byte.
  4. 用 HBK 去sign padded IK1. 產生 256 byte IK2.
  5. 用 IK2 加鹽巴 scrypt 出 32 byte IK3.
  6. 用 IK3 的前 16 byte 當 KEK (key encryption key), 後 16 byte 當 IV ( initialization vector).
  7. 把 DEK 用 AES-CBC 加密, 其中 KEK 和 IV 取材自上一步.

除了這些複雜的 key, iOS 和 Android 都有防止嘗試錯誤的軟體機制, 錯愈多次就要休息愈久. 所以破解方法就要用外部的硬體來做, 這也就是 Android 網頁上 [2] 所說的, 把產生 key 的方法複雜化, 以對抗 off the box 的破解. “In order to make the key resilient against off-box attacks, we extend this algorithm by signing the resultant key with a stored TEE key." 然而, 這樣還是被破了.

在 [1] 當中提到, 破壞的關鍵在於 key master module. 在 TEE (Trusted Execution Environment) 架構裡面, 有安全顧慮的動作, 都會由 REE (rich execution environment, non-secure world) 送到 TEE (secure world), 然後再把結果回傳 REE. Key master 本身長在 secure world, 理論上夠安全才對.

access-to-keymaster

不過, 畢竟 TEE 需要 SW 實作, 所以從 binary code 可以被反組譯, 再搭配公開的 data structure, 就可以找出 HMAC (Keyed-Hash Message Authentication Code) [7]. 下圖中間的 QSEE 就是 Qualcomm Secure Execution Environment. 破解的流程如下:

  • Enable the DACR (ARM 裡面的 Domain Access Control Register) in the TrustZone kernel to allow us to modify the code cave.
  • Write a small shellcode stub in the code cave which reads the keys from the KeyMaster application.
  • Hijack the “qsee_hmac" system-call and point it at our shellcode stub.
  • Call the KeyMaster’s key-generation command, causing it to trigger the poisoned system-call and exfiltrate the keys into the shared buffer.
  • Read the leaked keys from the shared buffer.

All-Android-System

作者認為 FDE 雖然已經被公認是安全可靠加密方式, 但是在 Android + QSEE 的組合之下, 還是被找到了漏洞. QSEE 使用 SHK (hardware key) 衍生的 key 來加密, 作者認為不如直接用 SHK 比較好, 因為 SHK 反而保證是 SW 不能讀取的. 不過在其他的使用案例, 這樣又會有別的問題 [1].

[REF]
1.  Extracting Qualcomm’s KeyMaster Keys – Breaking Android Full Disk Encryption
2.  https://source.android.com/security/encryption/
3.  Nikolay Elenkov’s blog, “Android Explorations"
4. Dan Guido’s superb post about the technical aspects of Apple v. FBI,
5. Matthew Green’s great overview on Apple’s FDE
6. iOS Security Guide
7. https://en.wikipedia.org/wiki/Hash-based_message_authentication_code