災防告警廣播小註解

Posted by on 2020 年 8 月 12 日 No comments

這篇的主題很難取, 因為可以用的名字太多了. 因為 COVID-19,  大家學到了細胞簡訊, 細胞廣播 [8], 類細胞簡訊等名詞, 它們都是用來傳遞重大災害的警示等等, 若搞不清他們的差異可以參考這篇 [1].

我主要想整理的是客戶可能需要的規格.

名詞 全名 Note
EAS [2] Emergency Alert Signaling radio and broadcast
WEA [9] Wireless Emergency Alerts wireless providers

EAS 是美國聯邦通信委員會 (FCC) [5] 所核准用的, 它的前前身和前身紀錄如下表. 最早用在國防用途, 後來轉為民生避難考量. 不意外最早只有廣播電台和電視需要支援.

名詞 全名 使用時間
EAS Emergency Alert Signaling 1997~now
EBS [6] or EANS Emergency Broadcast System
Emergency Action Notification System		 1963~1997
CONELRAD [7]   1951~1963

但是有了手機和網路之後, 防守的範圍就更廣了. 美國人依然喜歡改朝換代. WEA 也是格式的名稱, 所以此廣播的正式名稱應該是 CMAS.

名詞 全名 使用時間
WEA Emergency Broadcast System ~now
CMAS Commercial Mobile Alert System = WEA
PLAN Personal Localized Alerting Network  before

每個國家隊細胞廣播 (cell broadcast) [8] 的命名當然也不一樣. 不勝枚舉. 

名詞 全名 地區
EMA [3] Emergency Mobile Alerts 紐西蘭
WEA Wireless Emergency Alerts 美國
NL-Alert Netherlands Alert 荷蘭
EU-Alert EU Alert 歐盟

再來回頭講細胞廣播的格式. CAP [4] 是由 OASIS 所推出, 採 XML-based 的描述, 現在是 ITU-T X.3103 的標準. WEA 則是  Alliance for Telecommunications Industry Solutions (ATIS) 和 Telecommunications Industry Association (TIA) 所定的新規格, 特色包括能夠指定播放的區域. 多語言, 限時, 延時等等.

  • Flexible geographic targeting by using latitude/longitude “boxes” and other geospatial representations in three dimensions
  • Multilingual and multi-audience messaging
  • Phased and delayed effective times and expirations
  • Enhanced message update and cancellation features
  • Template support for framing complete and effective warning messages
  • Digital encryption and signature capability
  • Facility for digital images, audio, and video.
名詞 全名 Note
CAP Common Alerting Protocol 許多國家, 包括台灣
WEA Emergency Broadcast System 美國

[Note]

  1. https://www.bnext.com.tw/article/57390/what-is-pwc-warning-system
  2. https://en.wikipedia.org/wiki/Emergency_Alert_System
  3. https://en.wikipedia.org/wiki/Emergency_Mobile_Alert
  4. https://en.wikipedia.org/wiki/Common_Alerting_Protocol
  5. https://en.wikipedia.org/wiki/Federal_Communications_Commission
  6. https://en.wikipedia.org/wiki/Emergency_Broadcast_System
  7. https://en.wikipedia.org/wiki/CONELRAD
  8. https://en.wikipedia.org/wiki/Cell_Broadcast
  9. https://en.wikipedia.org/wiki/Wireless_Emergency_Alerts

Windows 10 打開 line in 的方法

Posted by on 2020 年 7 月 5 日 No comments

在 Windows 7 的時候, 我可以從 Realtek 的混音管理程式打開 line in (線路輸入) 的通道.  雖然它有個副作用是 line 進到混音後, 變成 line in 有一次聲音, 混音後又有一次聲音, 兩個聲音必須關掉一個.

但是用了 Windows 10 就有趣了, 明明麥克風的音量條都會動. 但是就是聽不到聲音從喇叭出來. 上網找到微軟客服的回答 [1], 但實在和中文版介面對不起來.

To enable sound for the line-in connection
1. Open Audio Devices and Sound Themes by clicking the Start button, clicking Control Panel, clicking Hardware and Sound, and then clicking Sound.
2. Click the Playback tab, click Speakers, and then click Properties.
3. Click the Levels tab, and then, under Line In, click the Mute button to enable sound for the line-in connection.

按照上面的流程, 第一步走到這裡. 然後它少講了要按右邊側欄的”聲音控制台”, 不然也看不到第二步講的東西. 

第二說三步說要點喇叭 (speaker) 的內容 (property). 但是我又迷失了.  我最後是在聲音控制台 –> 錄製中找到 line in 可以 unmute. 把這個選項打勾就可以聽到 line in 的聲音出現在喇叭了.

[Note]

  1. https://answers.microsoft.com/en-us/windows/forum/all/line-in-speakers-and-microphone-line-in-not/de6d462e-9970-48b3-8c3c-e70e66ccc01b

DTCP Order Format 小註解

Posted by on 2020 年 5 月 19 日 No comments

繼上次的 key format 之後, 又多了一個進階題叫做 order format. 根據 [1] 的 p. 20, 有 3 種 order formats. 價格也略有不同, 當然大客戶比較便宜 (large adopter) 是無庸置疑的. 為何 fomrat 3 比較貴呢?

根據定義, order format 1/3/5 的差異可以用 certificate (證書) / key 和 full / restricted 的排列組合來表現. 如下表, order foramt 3 的範圍最廣, license fee 也就最貴, Order format 1 居中, Order foramt 5 的範圍最小. 

Certificate\Key Full Restricted
Full Order Format 1/3/5 Order Format 1/3
Restricted Order Format 3 Order Format 3

根據 [1] 的 P.2, 證書和 key 的說明如下:

1.11 “Device Certificate” means a cryptographically encoded value which may be provided by
DTLA or its designee which authorizes a device to exchange certain Commercial Entertainment
Content.
1.12 “Device Keys” means cryptographic values which may be provided by DTLA or its designee
for use in devices, and include the “Private Device Key” and the “Public Device Key” and keys
associated with Restricted Authentication, all identified in the Specification.

DTCP 的 content 裡面包括一個 CCI (copy control information), CCI 裡面存放 EMI (encryption mode indicator) 來標記可以做甚麼樣的加密: copy free, copy never, copy once.

當 copy once 的 content 被 DTCP sink 處理的時候, 它的 EMI 若改記為 copy no more, 後續就可以只做 restricted authentication ([3] 的 P.891). 假如 content 被標記為 “copy never”, 就必須做 full authentication.

當需要做 full authentication 時, source 和 sink 要互相檢查對方的證書 (certificate), 然後做 key exchange. Restricted authentication 時, sink 只要向 source 證明他們的 secret key 都一樣. 

因此對於一個 recorder 來說, 它可能可以支援 full authentication certificate (計算能力夠強), 也可能只支援 restricted authetication certificate (計算能力弱). 為了降低計算需求, 採用 restricted authetication 比較方便.  但 key 為何又分為 full 和 restricted 呢? 這牽涉到 full authentication 下要選擇 order format 1 或是 5?

我們可以發現 restricted certificate 就不能選 full key, 但是 full certificate 可以選 restricted key. 我推測這是給予 full certificate 去選擇要把 copy once 減一成為 copy never (full key) 或是單純降為 copy no more (restricted key) 的權利.

客戶又問了 AP 和 AL 是 0 還是 1? 

AL flag (1 bit). Additional Localization flag. The AL flag is set to value of one to indicate that the associated device is capable of performing the additional localization test, otherwise shall be set to value of zero.

AP flag (1 bit). Authentication Proxy flag. A device certificate with an AP flag value of one is used by a DTCP bus bridge device, which receives a content stream using a sink function and retransmits that stream to another bus using a source function5.

首先看 Localization flag 是什麼? 根據 [4], 它在 DTCP + 1394 的規格也出現過. IEEE 1394 就是那個已經沒人在用的 DV 規格, 但 localization 的精神應該是一樣的. 基本上, 它要避免利用網路來遠端破解 DTCP, 所以要用網路封包的 round trip time 來檢查 sink 是否在很遠的地方. 如果我們要遠端 debug DTCP-IP 的 content, 我當然希望是 AL = 0. 但正常的產品給 AL = 1 即可.

什麼是 authentication proxy 呢? 顧名思義, 這是不是一個 DTCP 橋接器, 把左手的 DTCP 送給右手. 做為一個 recorder 來說, AP 應該要為 0. 因為不能把收進來的 DTCP-IP 不解就直接寫進 time shift buffer 等下次用. 既然 DTCP-IP 和 Time shift buffer 的 key 不能共用, AP = 0 就好.

[Note]

  1. http://www.dtcp.com/documents/licensing/dtla-adopter-agreement.pdf
  2. ITU-T_J.95Y1999.PDF
  3. Multimedia Encryption and Authentication Techniques and Applications
  4. https://www.dtcp.com/documents/dtcp/info-20070615-dtcp-v1sf-rev-1-p-0.pdf