SGX-SSD: A Policy-based Versioning SSD with Intel SGX
†Sogang University, Republic of Korea, ‡Korea University, Republic of Korea
Jinwoo Ahn†, Seungjin Lee†, Jinhoon Lee†, Yungwoo Ko†,Donghyun Min†, Junghee Lee‡, Youngjae Kim†
2
Motivation: Malware’s Data Tampering Attack
Victim Server
OS Kernel
Local Backup
Remote BackupEthernet
Problem: Ring-0 level rootkit malware’s data tampering attack
§ It enhances the privilege of victim, and compromises software-based backup system.
§ It finds and destroys victim's local or remote backup data.
Backup System
Ransomware
3
Motivation: Malware’s Data Tampering AttackExisting Solution: Versioning SSD [BVSSD, Systor 12], [Project Almanac, Eurosys 19]§ Versioning SSD implements versioning system in SSD firmware.§ SSD firmware is isolated from host server.§ Even if OS is compromised, it is impossible to destroy backup data.
Versioning System
BVSSD / Project AlmanacVictim Server
OS Kernel
Backup System
Ransomware
Backup data is safe from malware!
4
Motivation: Integrity vulnerability of Versioning SSDVersioning SSD preserves all file data for a fixed retention time(RT).§ Space overhead extremely increases as all files are backed up regardless of the importance.§ To free up space, Versioning SSD aggressively erases old backup data in a way that limits RT.
secure.txttemp.txt
3/3
V1
Files are created
V1
Integrity vulnerability occurs when:
Malware Dwell Time (DT) > Versioning SSD Retention Time (RT)
3/4
V1 V2
Malware encrypts files
V1 V2
3/7
V1 V2
V1 is removed
V1 V2
3/11
Recovery failed
V2V2
RT : 3 daysDT : 7 days
Versioning SSD
Dwell Time: A period that the malware stays
undetected in victim system
5
0 7 30 60 150 300 1000 20005
10
15
20
25
Dwell
Tim
e Di
st.(%
)
Dwell Time (days)
22%18%
11%14%
9%
15%
7%RT: 3-56 days 1%
Motivation: Integrity vulnerability of Versioning SSDMalware's average DT is longer than the RT of Versioning SSDs.§ Project Almanac provides 3-56 days of RT depending on the workload’s write intensity.§ However, more than 50% of malware has a DT of 60 days or more.
Existing Versioning SSD is vulnerable
from at least 50% of malware’s attack.
6
Motivation: Keeping deeper history for important filesSGX-SSD: Policy-based per-file versioning SSD§ Each file version is maintained according to policy set by users.§ We defined 3 types of policy a user can set.§ SGX-SSD minimizes the space consumption for versions to keep deeper history for important files.
foo.txt RT: 3days
secure.txtRT: 365 days
temp.txtRT: 0 day
Retention Time
foo.txt #V : 5
secure.txt#V : INF
temp.txt#V : 0
Number of Versions
foo.txt BC : 30day
secure.txtBC : 1day
temp.txtBC : NULL
Backup Cycle
7
Motivation: Keeping deeper history for important filesSGX-SSD guarantees integrity from malware with long DT.§ Malware DT: 7days, RT of secure.txt: 30days, RT of temp.txt: 0day
3/3
Files are created
secure.txt
V1
temp.txt
V1
3/4
Malware encrypts files
V1 V2
V1 V2
temp.txt
secure.txt
3/11
Recovery Success
V2
V1 V2
secure.txt
temp.txt
SGX- SSD
8
Design Challenge: SGX-SSD
Challenge 1: Secure Host Interface on Compromised OS§ How can the policy request entered by a user be safely delivered to the SSD?
User I/O Device
Host Server
SGX-SSD
OS KernelPolicy Policy
Challenge 2: Per-file versioning management by SSD§ How can SSD recognize the file semantics corresponding to each block?
SGX-SSD
write(LBA, size)temp.txtRT 0day
secure.txtRT 30 days
App File System
File Data
Data ?
9
Summary
§ We defined the integrity vulnerability of the existing Versioning SSD.
§ To solve this, we proposed a per-file versioning implementation in SSD firmware.§ By solving the aforementioned two challenges, the integrity of the file can be selectively
guaranteed even if the OS is compromised.§ Detail of SGX-SSD can be found at [https://arxiv.org/abs/2004.13354].