作者：Yimi Hu & Light @ PwnMonkeyLab
原文鏈接：https://mp.weixin.qq.com/s/OADymyp6GdW_FPetl8oPvA
簡介
通過之前幾篇對智能門鎖的分析和討論，是不是有種漸入佳境的感覺？從本篇開始，我們再換一個門鎖品牌進行研究，與各位讀者分享更多關于智能門鎖的安全研究案例。
此次要分析的產品是Loock Touch智能門鎖，由云丁科技公司出品。云丁科技是一家專注于研發和生產智能家居安全產品的公司，旗下有兩大品牌，分別是針對家用市場的“鹿客”和針對公寓市場的“云丁”。Loock Touch是鹿客品牌的主打產品之一，其架構與云丁品牌的D2、D3智能門鎖很相似，最新的鹿客旗艦產品是Loock Touch 2 Pro，其硬件架構與此前所有產品均不同，變化較大。
由于胖猴實驗室一直和云丁科技有良好的合作關系，所以接下來的幾篇的分析和討論中，我們只對分析方法和研究過程做討論，而不涉及任何有關漏洞的細節，這與此前的關于海康螢石智能網關的文章類似。
流程分析
在本專題第6篇中，我們分析了果加智能門鎖，在該分析中我們以BLE開鎖為分析切入點。云丁鹿客的Loock Touch門鎖同樣可以通過手機BLE直接開鎖，那么我們就從app的開鎖流程開始分析。
應用市場中下載到的云丁鹿客智能門鎖的配套app加了梆梆企業版的殼，脫殼之后可以看到該app打印出來的日志（脫殼不在本系列文章的討論范疇中，分析iOS版也是可以的）。我們操作手機開啟門鎖后，app的日志中有這樣幾條記錄吸引到了我們。
根據上圖中3個紅框中的記錄內容，我們可以推測開鎖過程是基于Challenge/Response模式進行認證的，具體過程如下：
（1）app與門鎖建立BLE連接后，當使用app開啟門鎖時，app會先下發一條通知指令，告知門鎖準備進入開鎖流程；
（2）隨后門鎖會向手機發送一組數字，稱之為Challenge；
（3）app對Challenge進行處理生成Response并發送給門鎖，門鎖驗證Response正確時，就會開鎖。
我們對比了多次開鎖時的app日志，發現每次開鎖時第（1）步發送的通知指令僅有一個字節內容不同，如下圖所示：
上圖中，我們對比了3條通知指令，發現僅有第7個字節不同，在app封裝數據包的代碼段中，可以確定這個字節的含義是seqID，即數據包的序列號。因此我們可以推測這一條通知指令的作用類似于TCP協議中的SYN數據包，僅起到握手的作用，而門鎖對手機的認證過程，主要是第（2）和第（3）步，那么接下來我們就分析一下app是如何處理Challenge并生成Response的。
Challenge的處理
3.1 處理流程分析
通過在代碼中搜索日志內容，我們可以確定，app收到Challenge數據后，會由下圖中的方法進行處理。
上圖中， handleCommand方法用于處理BLE返回數據，門鎖返回的Challenge就作為參數傳給了方法sendUnlockCommandNewProtocol，從參數和方法名稱來看，這就是處理Challenge數據、生成Response并發送回門鎖的方法。
進一步查看代碼，我們發現在sendUnlockCommandNewProtocol方法中，最終調用了下圖中的encryptBleKeyNewProtocol方法對Challenge數據進行處理，該方法返回后的數據，添加包頭后會被直接發送給門鎖。
上圖中，參數arg13即為Challenge數據，可以看到該方法中使用了AES EBC加密，密鑰是參數arg9，加密完成后使用密文又異或了一組固定數據。
經過以上分析我們可以推測，開鎖流程中，門鎖對手機的認證依賴于圖3-2中的AES EBC算法，即雙方使用相同的密鑰對Challenge進行加密和解密處理，僅當手機擁有正確的AES密鑰才能通過認證開啟門鎖。那么開鎖流程的安全性，就取決于門鎖與手機使用的密鑰是否安全了。
3.2 加密密鑰的獲取
圖3-2中，加密密鑰是參數arg9，通過對arg9的回溯可以確定，對Challenge進行加密的密鑰通過resetBleToken方法獲取，如下圖所示。
resetBleToken方法中發出了一個http請求，收到返回的BleToken并進行處理后，會對一些變量進行賦值。圖中的mBleKey是BleKeyInfo類型的變量，其token成員變量，就是3.1章節中Challenge數據的加密密鑰。下文中，我們將以BleKey來代稱這個加密密鑰。
由以上分析可以知道，BleKey是app從服務器上請求到的，這里就有兩種可能：
（1）每次app與門鎖建立通信時，都會請求一個Key并下發給門鎖；
（2）當app與門鎖建立通信時，如果沒有可用的BleKey，才會向服務器發送請求。
為了驗證以上推測，我們使用手機多次重復開啟門鎖，這樣使手機和門鎖反復建立通信，這時我們在app日志和抓取到的數據包中，都沒有發現這個請求以及相關內容，可以判斷app應該是本地保存了BleKey，而不需要從服務器獲得了。
我們可以通過清空app緩存的方式，刪除本地存儲的BleKey，刪除后app開鎖時的日志發生了一些變化，如下圖所示：
對比圖3-4和圖2-1中的日志內容，可以看到刪除BleKey后，在開啟門鎖時先執行了resetBleToken，這和我們的分析吻合。這里我們注意到，resetBleToken之后，還有另外一條日志sendBleKeyCommandNewProtocol，這里是向門鎖發送BleKey的方法，下面我們先繼續手機獲取BleKey這一過程的分析，手機向門鎖下發BleKey的過程將在3.4節中分析。
與此同時，我們在fiddler中也抓到的對應的http請求，如下圖所示。
app收到返回的BleToken后，會使用AES CBC算法，對上圖中紅框內的secret和token進行解密，相關代碼如下圖所示，
此時可以確定，app從服務器獲取到的BleKey同樣被AES CBC加密算法保存。通過圖3-6可以看到，其密鑰由方法getCryptSecret返回，與方法名稱對應，這個密鑰我們就稱之為CryptSecret，下一步我們就來分析CryptSecret的來源。
3.3 CryptSecret的獲取
BleKey解密時的密鑰通過getCryptSecret方法獲得。那么我們可以從這個方法入手，相關代碼的搜索結果如下圖所示。
上圖中，getCryptSecret方法返回的是this.mCryptSecret，而這個變量是通過setCryptSecret賦值的，setCryptSecret方法則是在getSecret方法中被調用。在getSecret方法中，可以看到CryptSecret是從云丁鹿客的服務器獲取到的，其url為”api/v1/crypt_secret”。同樣的，我們在fiddler里也可以抓到crypt_secret數據包，如下圖：
由于這里的信息有些敏感，所以我們做了打碼處理。
3.3 向門鎖下發BleKey
3.2節中說到sendBleKeyCommandNewProtocol函數負責向門鎖下發BleKey，該函數如下圖所示。
結合上圖與圖3-4的日志和圖3-5中reset_token請求的返回數據包，可以發現，手機向門鎖下發BleKey的流程非常簡單，就是對reset_token返回數據包中的totalData進行base64解碼，解碼后的二進制數據直接通過BLE通信發送給了門鎖，門鎖對totalData的處理我們將在后續文章中分析。
小結
經過第二、三章的分析，我們可以將Loock Touch門鎖的開鎖流程總結如下圖所示。
上圖中，開鎖流程可以分為兩個部分：
（1）虛線部分表示，當app沒有存儲可用的BleKey時，會向服務器請求CryptKey和BleToken兩組數據，以CryptSecret為密鑰，對BleToken中的數據進行AES CBC解密后，就可以得到BleKey。
（2）實線部分則是當app中有可用的BleKey時，會以BleKey為密鑰對Challenge進行AES EBC加密，密文異或一組固定數據后，作為Response的主要內容并發送給門鎖，當Response校驗成功后才會開啟門鎖。
本篇文章側重于云丁鹿客智能門鎖的app端的分析。至此我們對app的開鎖流程基本已經理清了：開鎖時，門鎖與app之間采用了Challenge/Response的方式進行身份校驗，app對Challenge數據進行處理時使用了AES EBC加密算法，密鑰我們稱之為BleKey；BleKey的獲取流程是：門鎖配套的app向服務器發送reset_token請求，并對返回內容進行AES CBC解密，這里解密密鑰稱之為CryptSecret；CryptSecret是app通過向服務器發送crypt_secret請求獲取到的。
此外，在第二章中提到，智能門鎖和門鎖配套的app中應該存儲著相同的BleKey，這樣才能完成認證過程。而智能門鎖中的BleKey也是由手機通過BLE通信下發的。通過本專題的前幾篇文章，我們知道某些情況下BLE通信會很容易被監聽，那么如何保護BleKey的下發過程是安全的呢？我們將在后續文章中分析這一過程。
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.jmbmsq.com/1542/
暫無評論