Login  |  繁體中文
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
FOSS Projects 專訪台科大「基於時脈偏移的裝置識別技術於雲端服務之研究」

專訪台科大「基於時脈偏移的裝置識別技術於雲端服務之研究」

今天來到臺灣科技大學採訪鄧惟中老師。他們團隊的專案是研究時脈偏移,「時脈偏移」(clock skew),也有人稱為時鐘偏斜。理想上,電路系統中的各部位的時鐘訊號應該保持同步,以確保整個系統的工作可以同步,但實際上訊號在傳遞的過程中會有些許的誤差,有可能是因為硬體設備的材料、連線長度、或是溫度…等等原因所造成,這樣的誤差就稱為時脈偏移。他們利用這樣的偏移發展出新的應用,現在就來看看他們是如何應用的吧!

1. 能和讀者們介紹一下什麼是「時脈偏移」嗎?

Clock skew 有兩個譯名,時脈偏移跟時鐘偏斜。為什麼會說是「偏斜」,從測量時畫出來的圖來看就會很清楚,它會呈斜線。Clock skew 這個名詞其實從傳統 IC 製造業的時候就一直有在用,早期 clock skew 是指在 VLSI (Very-large-scale integration,超大型積體電路) 中,它裡面有非常多的閘道,每個閘道會有一個 clock signal (定時器訊號),這個訊號傳到不同的閘道,雖然從振盪器出來的訊號是同一個,但由於佈線長短不一,不同閘道接收到 clock 訊號的時間卻產生了微小差異。但是 1990 年左右,由於網路的興盛,現在這個名詞比較常用在兩台以上已連線電腦,各自的時間隨著時間經過而愈差愈大的現象。舉例來說,有一個應用程式需要好幾個電腦時間要同步,但一開始校對到同步的時間,過了五小時、十小時以後,會發現有的機器時間就是快了一兩秒。時脈偏移的產生原因是電子鐘的石英振蕩器的振盪頻率不一致所致,而時脈偏移是無單位量(每秒差異多少秒,sec / sec 所以沒有單位)。根據過去的研究,很少找到時脈偏移在 1.0 ppm 以內的裝置。

最早接觸這個議題是 2005 年有一篇論文,一位名叫 Kohno 的學者,花了整整四天去做了 69 台電腦的測量。量出來之後他發現這 69 台電腦,其實在小數點下面第六位以後都不一樣。他就下了一個結論,任何一個裝置追究到 1 ppm 以內的話,能被觀察出與其他裝置的時間差異。後來大家就開始發想,是不是可以將這樣的差異當成是像指紋一樣辨識個別的機器呢?全世界數以億計的電腦,這一個 ppm 的差距換算成一年累積下來(假設頻率都沒有改變)大概是 31.5 秒。大家可以回想日常接觸到的時鐘,一整年都沒有校正它的話,它可能會快、或是慢多少?大略估計大約是一兩百 ppm,當然我們在過去的論文中也有看到比較特殊的例子,但較為少見。要把數以億計的電腦通通塞進約兩百 ppm 的區間,然後宣稱它們都是獨一無二的,當然是不太可能;但是要說它們都是相同的,也不對。如果能夠增加測量的精細度,例如測量到 0.1 ppm,將它們的差異性分別出來將會較為容易。

2. 時脈偏移能像機器的指紋一樣具有獨特性以供辨認嗎?例如說,同一批出廠的裝置,可能機板、SoC 等等都是同一批貨(甚至可能連製程的缺陷都是一樣的),這種情形下每一台裝置的偏移值也是獨一無二嗎?

時脈偏移在精確度到達 1 ppm 時,就可以發現其獨特性。同一批採購的電腦彼此的振盪頻率的確比較接近,但仍然有可能會誤差到 10 ppm。

3. 目前這個驗證方式的可靠性有多高?

我們這個計畫的目的是希望能夠把時脈偏移拿來做二次驗證, two-factor authentication 正式的中文譯名是「雙因數驗證」。這就像是 facebook 及 google 的兩步驟驗證,除了帳號密碼之外,還會鼓勵用戶註冊電話號碼或者是使用驗證器,以避免用戶的帳號遭到盜用。常見的帳戶驗證方式包括用電話號碼驗證的方式、或是防止機器人自動登入的圖片驗證。因此我們就想,這些驗證方式都需要使用者親自操作,如果我們可以直接判斷登錄該帳號密碼的設備是不是原先使用者註冊的裝置,而且是非侵入性的驗證,就不會增加使用者的不便。

2012 年的時候我們有一篇論文,提到我們曾經在自己的計算機中心做過測量試驗,這是一個量測 100 台電腦的實驗,其中 80 台是計中的電腦,扣除掉特別突出的幾個數據,大約 90 台的電腦分佈在 60 ppm 的範圍內。有一些設備跟其他設備的測量結果確實是滿接近的,計中電腦中有 8 台同一批採購的電腦彼此之間的差異不到 2 ppm,算是誤差最小的案例,但如果我們拉長測量的時間也許會有不一樣的結果。

4. 使用 TCP 有三方交握的延遲,使用 UDP 則有封包遺失的可能。因為延遲可能造成時脈偏移比較值產生誤差,所以選擇 UDP 嗎?對於封包遺失的處理方法為?

過去量測時脈偏移的時候,主要都是在傳統網路上,但現在我們要在行動裝置上使用,勢必是會經過雲端。我們實驗室是選擇 UDP,因為量測時脈偏移,傳輸延遲不是問題,抖動才是問題。相關學者都用 UDP 或 ICMP,因為太複雜的通訊協定反而提高抖動,另外傳統的做法只取接近最小延遲的點,所以 TCP 雖然會保證每一個封包一定會收到,但重送的封包是無用的,封包遺失就遺失了,抽樣資料不需要是連續的。

5. 從操作影片看來,驗證需要的時間似乎還不短。而且看起來是使用 Wi-Fi 連線,如果使用 3G/4G 連線是否會影響連線時間或是驗證的正確性?對於這方面是否有改善的計畫?

我們最早開始接觸這個議題是無線感測網路的時間同步通訊協定 FTSP,這個協定只要 8 個封包就可以達到 ppm 等級的量測。在執行這個計畫的過程中,我們觀察到一個有趣的現象:無線網路,特別是 3G 的時候,會發生一個情形,由於抽樣的時候會盡量挑延遲最小的點,而大部分的點延遲速度都是類似的,因此可以使用線性迴歸算出一條穩定的線,但如果有傳得特別快的樣本,反而會干擾到計算出來的斜率。現在我們有更進一步的改良,但還在驗證當中,將會在之後的結案報告裡分享給大家。

專案網址:




OSSF Newsletter : 第 248 期 專訪台科大「基於時脈偏移的裝置識別技術於雲端服務之研究」

Category: FOSS Projects