U2F設備安全測試
在上一篇文章中,我對U2F設備的各種安全密鑰進行了一個很粗淺的安全介紹,這其中就包括了:基本功能,物理特徵等,如果你感興趣可以點此了解詳情。在今天的這篇文章中,我會從一個更低級別的特徵來測試U2F設備的安全性。
安全密鑰用的是FIDO U2F規範,U2F (Universal 2nd Factor) 是 Yubico, Yahoo 和 Google 聯合開發的基於物理設備的雙因素認證協議,目前已經完成標準化,從屬於 FIDO (Fast Identity Online) 聯盟名下。另外,FIDO U2F規範借鑒了智能卡ISO7816-4規範中的許多標準。FIDO U2F儘可能對每種可能的傳輸(USB,NFC或藍牙)都進行規範,已確定它們在傳輸時是如何封裝U2F消息的,例如,USB介面會如何封裝U2F消息。 目前FIDO正在對目前的標準進行修訂,以應對未來可能的情況,不過目前所有的安全密鑰標準都實現了基本的安全功能。簡而言之,U2F包含三大部分:註冊,驗證和檢查。
註冊時U2F設備會創建一個新的密鑰對,更準確地說,註冊時伺服器會產生一個32位元組的Challenge數據和一個32位元組的應用id。
註冊請求消息有兩部分,如下圖所示:
challenge parameter[32 bytes], challenge parameter是對客戶端數據進行SHA-256運算得到的哈希值,另外Challenge是一個隨機數。Client Data是一個由FIDO客戶端準備的JSON數據結構。
application parameter[32 bytes],application parameter是請求註冊的應用id的SHA-256結果。而對於瀏覽器,應用id是登錄頁面的起始地址中的URL的哈希值。
U2F設備的密鑰對
U2F設備產生的密鑰對是伺服器關聯的,一對密鑰對應一個伺服器,而不是一個U2F設備對應一個伺服器。在註冊的時候,伺服器給U2F設備傳入伺服器相關信息,U2F設備產生一對密鑰對,將此密鑰對和伺服器相關信息相關聯,給此密鑰對分配一個key handle,將其和公鑰傳給伺服器,伺服器將註冊的賬戶信息,公鑰,key handle全部關聯在一起並保存。
當用戶需要使用U2F驗證操作時,伺服器產生Challenge數據,使用U2F設備做簽名,此時伺服器將key Handle和伺服器信息通過瀏覽器傳給U2F設備,U2F設備使用Key Handle,尋找對應的密鑰對,如果密鑰對存在,檢驗密鑰對應的伺服器信息是否和傳入的伺服器信息匹配,如果不匹配,說明伺服器是偽造或者不正確的。如果正確,U2F設備等待用戶按鍵確認,用戶按鍵後,U2F設備對Challenge數據做簽名,應用id返回給伺服器,伺服器驗證應用id,如果簽名正確,說明此公鑰對應的唯一私鑰是正確的,表明用戶擁有合法的U2F設備,如果簽名不正確,說明此用戶正在偽造身份登錄。
U2F設備安全特性
然而一個比較有趣的地方是,U2F設備不帶無窮大的安全存儲空間。在實際研究過程中,我發現key handle實際上是一個加密的私鑰,即用令牌卸載存儲的私有密鑰。然而,從理論上講,key handle可能只是一個整數,用於對令牌內的存儲密鑰進行索引。所以為了保證安全性,私鑰的保護很重要。U2F協議允許一個廉價的設備,同時保證此設備不會泄露私鑰。Key handle可以不是U2F設備上一個私鑰的索引,相反,Key Handle可以用來存儲私鑰和伺服器相關信息,這些信息可以被加密保存到一個Key Handle中(例如使用aes加密私鑰和伺服器數據)。
鑒於此,在新修訂的FIDO U2F規範中,有許多關鍵的安全規範還是應該保留下來,比如:
1.Key Handle應加密,以防止在那裡找到ECDSA私鑰。n2.一個安全密鑰的Key Handle不能與另一個安全密鑰一起使用,即使是相同的類型。n3.如果一個安全密鑰被要求生成數百個密鑰對,那麼它們都應該是不同的。n4.所有的簽名都應該有唯一的隨機數,否則就可能出現安全漏洞,讓人提取你的私鑰。n5.應該對應用id進行檢查。n
但除此之外,還有其他一些安全性需要進行測試:
1.Key Handle是否是U2F令牌產生的,如果U2F令牌發現key handle不是自己創建的,直接進行錯誤返回,如果是,U2F令牌必須返回一個認證響應。n2.簽名是否被正確編碼了?U2F設備的簽名採用的是ASN.1編碼。n3.USB協議傳輸的是64位元組數據包,最後的填充位元組應全部為零,而不是隨機的內存位元組。n
給了這麼多理論的安全建議,但最終還是要理論結合實踐,下面就讓我們看看目前市場上的U2F設備是如何進行密鑰管理的。
Yubico
Yubico的產品目前還處於比較領先的位置,產品還暫時沒有發現什麼漏洞,必定U2F的標準就是Yubico牽頭制定的。
Vasco公司的SecureClick
Vasco公司的SecureClick也是一款很不錯的產品,具體介紹點此https://github.com/hillbrad/U2FReviews#secureclick。這是一個藍牙低功耗(BLE)令牌,這意味著它可以與Android和iOS設備配合使用。對於非移動設備,它包括一個USB-A BLE加密狗。 SecureClick使用Chrome擴展來配置和配對跨平台的加密狗。加密狗看起來像一個普通的USB設備,但區別就是它能從令牌中檢測到到一個BLE信號,此時它會「斷開」,並進行重新連接,以執行U2F操作。一旦需要用戶註冊或認證的操作完成,則令牌就會自動斷電,並且加密狗再次斷開並重新恢復到原始USB設備的狀態。
如果你正在使用Linux,那配置的udev(設備管理器)就可以正常顯示令牌供應商的ID和產品ID的訪問許可權,不過由於供應商ID和產品ID是不同的,所以令牌無法正常工作, Chrome擴展程序也很混亂。還有一個問題就是BLE令牌設備的電池經常會因電量耗盡而停止工作。
飛天誠信的ePass
ePass系列是由飛天誠信公司推出USB Key,主要是用作基於公鑰體系的數字證書和私鑰的安全載體,大小如同房間鑰匙,形狀和市面上的U盤相像,可以穿在鑰匙環上隨身攜帶。目前飛天誠信已獲FIDO UAF認證,成為國內唯一一家擁有U2F和UAF雙證的企業
ASN.1 DER被設計為可辨別的編碼,即對於給定值,應該進行唯一的排列,這樣所有其他表示都是無效的。因此,數字應該被最小化編碼,沒有前導零。
不過ePass並不具備這樣的安全密鑰,因為從9個前導零位開始的數字在開始時都有一個無效的零位元組。可以推測,從17個零位開始的數字在開始時都有兩個無效的零位元組,但是我沒有足夠的時間來尋找具體的案例。不過我可以推測這種安全密鑰生成的256個簽名中,只有一個屬於無效編碼。
此外,Key Handle的最後八個位元組似乎是多餘的,也就是說,你可以將它們更改為你喜歡的任何值,至於是否能起到安全密鑰就不一定了。其實這倒不是什麼問題,真正的問題是,它們是否會被使用?另外,USB數據包中的填充數據不為零,不過這只是顯然了傳輸緩衝區的以前內容,並不會泄露什麼敏感數據。
Thetis
不知是什麼原因,我無法在此設備上測試一些安全特性,比如Key Handle的可變性,應用id是否經過了檢查等。對Key Handle的可變性檢查的響應是無效的,根據FIDO U2F規範,檢查響應的返回狀態為0x9000 (「NO_ERROR」),但其實返回狀態應該為0x6985或0x6a80。之後,它開始拒絕所有的含有0x6a80的Key Handle(包括有效的)的響應。
該設備具有與飛天誠信的ePass相同的非最小簽名編碼問題,此外,如果你按鍵的速度太快,這個安全密鑰就會陷入混亂並拒絕一些status 0x6ffe請求。另外,USB填充位元組也不為零。
U2F Zero
1KiB ping消息崩潰此設備(即它停止響應USB消息,需要拔下並重新插入)。測試一個損壞的鑰匙柄也會崩潰,因此我無法運行許多測試。
一個1KiB的 ping消息即會讓U2F Zero崩潰,並停止響應任何USB消息,如果要重新運行就要拔下來重新插入。另外測試一個崩潰的Key Handle也會崩潰,所以最後我只能放棄對其的安全性測試。
KEY-ID/HyperFIDO
Key-ID和HyperFIDO設備,具有相同的固件,它們具有與ePass相同的非最小編碼問題,除此之外,還存在ASN.1缺陷。在ASN.1 DER中,如果一個數字的最高有效位被設置,那該數字就是負數。如果不是負數,則需要一個零填充位元組。當測試最高有效位時安全密鑰會檢查第一個位元組是否是> 0x80,但按照規範應該檢查第一個位元組是否是>= 0x80。這樣檢查的結果就是有時會產生含有負數的簽名,使得檢查無效。
另外,USB填充位元組不是零,而且還包括了不屬於請求或響應的一部分數據。雖然這些數據不太可能有什麼實質的影響,但它們是從哪裡來的呢?這個確實是個有待研究的問題。
還有就是封裝的密鑰也有一些問題。首先,位元組16到31是設備和應用id的函數,因此,在不同的帳戶使用時,給定站點可以被動地識別到相同的標記。位元組48至79未經身份驗證,並且在更改時,除了簽名錯誤之外,所有內容仍然有效,這表明這些位元組就是加密的私鑰或生成它的加密種子。最後,雖然位元組32到47不能被任意操作,但是可以用來自不同的key handle的替換相同的位元組,這就會導致簽名錯誤。
本文翻譯自:https://www.imperialviolet.org/2017/10/08/securitykeytest.html ,如若轉載,請註明原文地址: http://www.4hou.com/tools/7935.html 更多內容請關注「嘶吼專業版」——Pro4hou
推薦閱讀:
※滲透測試中的Bypass技巧(一)
※用Python玩玩反彙編
TAG:信息安全 |