如何竊取iPhone資料?
iOS資料保護機制簡介
2019-8-27 高田數位鑑識
iOS裝置的資料加密機制從A7處理器後(iPhone 5S後)，不管在硬體(導入Secure Enclave)與iOS(FBE啟用)上，功能皆有很大的提升。這篇文章會簡單的描述iOS Data Protection架構，讓鑑識人員有初步的了解Apple在資料安全性上設計的機制。也希望藉由這篇，可以探討以下幾個議題!
- 為什麼新版的iPhone不支援物理提取(64-bit iOS)。
- iOS如何快速重置裝置?
- AFU與BFU可以提取的差異?
- Data Protection使用的Class Key差異。
- 有密碼與無密碼的iTunes備份差異?
加密背景：檔案與硬碟加密
電腦加密機制比手機存在的時間更久遠。 實際上，1990年初電腦就有開始使用加密技術來保護資料不被竊取，但實際有廣泛使用要到2000年初，當作業系統有內建加密機制時才逐漸普及。
PC通常採用FDE(Full Disk Encryption)加密機制，一般開機時會要求使用者輸入一個密碼，如果正確才會解開加密的硬碟，進而進入到作業系統。早期iOS與Android皆採用FDE加密機制，主要是導入與開發成本相較於FBE(File Based Encryption)較低。FDE最大的問題是如果被竊取的電腦或手機為開機狀態，要破解並竊取已開機狀態的資料相對簡單，這也是為什麼在”iPhone資料保存與提取步驟分析“這篇文章上所描述，若查扣到數位裝置，必須第一時間開啟飛航模式並插上行動電源的主因。
FDE加密機制
Apple在iPhone 3GS/iOS 3/時已導入FDE架構，從硬體設計上採用獨立的AES處理器來進行加解密運算(AES有獨立DMA通道連接CPU與快閃記憶體)。
以下為FDE加密流程說明：
- 系統產生一個亂數的EMF key。
- 透過UID導出0x89B key，並使用該key對EMF key加密。
- 將加密的EMF key儲存在快閃記憶體的Block 1 (Effaceable Storage)。
- 整個File System使用EMF Key來進行加密保護。
圖一、iOS 3 FDE架構
FDE的好處是可以快速刪除資料，只要將EMF Key刪除整個File System就無法被解開。另外作業系統尚未啟動前，資料是無法被存取的；且若無法取得EMF Key，直接移除儲存晶片讀取出的資料也是亂碼。但壞處就是開機後，系統使用EMF Key解開File System資料就無額外的保護，即便上了螢幕鎖。
FBE加密機制
Apple已意識到了FDE先天在資料保護的不足，因此在iOS 7之後開始導入FBE，但一直到iOS 8後Apple才正式啟用FBE的Data Protection機制。新的FBE保護機制，採用多層金鑰加密架構，主要分為五大類型，每個類型另有自己的Class Key來控管存取權限：
- User Keybag
- Device Kaybag
- Backup Keybag
- Escrow Keybag
- iCloud Backup keybag
本文主要探討的是User、Backup與Device Keybag。User Keybag的金鑰是由硬體UID(AES 256-bit hardware key)與Passcode兩個組合而成(除了No Protection Class Key)，而Device Keybag的金鑰僅由UID衍生而成，而Backup Keybag則是兩個組合都有。User Keybag會依照各種檔案所需要的保護類型，由最上層的金鑰加密各個Class Key，再由不同的Class Key加密File Key。下圖為針對User Keybag的Class Key架構。
圖二、FBE架構
iOS Data Protection架構的User Keybag，有四種金鑰種類(Class Key)，這四種金鑰種類對應不同的檔案保護機制。而針對單一檔案的金鑰，則是有多少檔案就有多少對應的檔案金鑰(Per-File Key是採已加密後的形式存放在檔案的Metadata內，必須由對應的Class Key才可解開)。
圖三、金鑰種類
若把圖二、三展開，可看到較完整的「資料保護」多層金鑰加密架構，每部 iOS 裝置皆採如圖四的硬體加密技術。從圖四所示，主要從UID與Passcode衍生的金鑰是存放在Secure Enclave(安全隔離區)內。根據Apple的技術文章，UID是由工廠在生產個過程產生而出，Apple與工廠並不會記錄裝置的UID資料。而每一個iOS的UID都是獨立的。而透過UID，會衍生出多隻金鑰，其中兩隻金鑰、0x89B與0x835會用於Device Keybag上。0x89B功能同FDE，會透過EMF金鑰針對整個File System/Partition進行加密保護。而Passcode則是用戶自己產生，從iOS 9之後，預設的Passcode長度為6個數字，而0x835 Key與Passcode Key(從Passcode透過加密運算產生)會針對所有的Class Key進行加密(除了Class 4 Key外)。
圖四、iOS Data Protection詳細架構
當打開檔案時，因系統已使用EMF金鑰解開File System，故可以讀取該檔案的metadata資料(包含日期，時間，檔案名稱等)與檔案專屬的已加密狀態金鑰(per-file key)以及表示其保護類別(Class Key)的資訊。已加密的檔案專屬金鑰需使用相對應的類別金鑰(Class Key)來解開。從該架構可得知，若裝置上有1萬個檔案，就會有1萬個256bit檔案專屬檔案金鑰(per-file key)。所有過程會透過硬體 AES 引擎運算加解密，當從快閃記憶體中讀取檔案時，AES引擎會對檔案進行解密。所有封裝檔案金鑰的處理作業會在「安全隔離區」中進行。
截至今日為止，尚未發現有針對Secure Enclave Processor「安全隔離區處理器」的漏洞，若有就可取得金鑰，進而進行物理提取。離破解最接近的一次為2017年，有駭客成功將SEP Firmware提取出，但尚未有辦法成功解讀SEP裡面儲存的資訊。
User Keybag的Class Key類別
在 iOS 裝置上產生新檔案時，產生檔案的App會替該檔案指定一個類別(Class)。每個類別使用不同的規則來決定資料何時可供存取。在iOS內User Keybag一共有四個檔案保護類別：
- Complete Protection/完整保護
- Protected Unless Open/完整保護除非檔案尚未關閉
- Protected Until First User Authentication/完整保護直到首次使用者認證後
- No Protection/無保護
圖五、Class Key說明
Backup Keybag – iTunes備份與Class Key
有密碼保護與無密碼保護的iTunes備份最大的差異是在Keybag是否被UID Key加密的狀態下儲存於iTunes備份擋內。若iTunes備份檔沒有密碼保護，Keybag會被UID的金鑰加密後儲存於備份檔內(Keychain也是)，這代表這個備份檔案是無法恢復到其他的iOS裝置，僅能恢復到原有備份出來的裝置(因為每個iOS的UID皆不同)。若iTunes備份檔有密碼保護，則Keybag會用iTunes設定的密碼採PBKDF2加密函式反覆運算1千萬次來保護 Keybag ，因Keybag未與UID綁定，當升級新的iOS裝置時就必須採用密碼保護的iTunes備份檔才可進行資料移轉。
圖六、Backup Key說明
總結
了解iOS Data Protection架構後，Apple在行動裝置領域中對於隱私與資料安全保護明顯處於領先地位，當有新的漏洞，軟體更新皆在很短的時間內補上。而在iOS 13，Apple推出的CryptoKit可以讓APP開發者使用Secure Enclave加密功能，讓APP在資料交換過程可以有更高等級的加密保護。當然，這些功能對於鑑識人員在取證過程中將面臨更多的阻擾，在取證領域上將會是一場永無止盡的追趕賽事。
