Drive encryption is becoming something more and more common in recent years. Since 2018, when GDPR became enforceable, drive encryption became a de facto standard for laptops and mobile devices, securing corporate data in case of eg. device theft.
Drive Badger supports 4 most important drive encryption schemes (see the below table). Obviously, to exfiltrate data from computer with encrypted drive, you need the encryption key (in most circumstances, either user password, or recovery key). Drive Badger automates storage and management of such keys - but it is up to you to obtain and configure them before the attack (eg. buy them from disgruntled IT employee).
Additionally, Drive Badger ensures operator safety by encrypting its persistent partition (the one on your USB drive, to which exfiltrated files are saved) using LUKS. In case of getting caught, there is no way to distinguish between Drive Badger and ordinary Kali Linux Live drive, or to prove the fact of data exfiltration, until someone knows the proper password.
Currently Drive Badger supports the following drive encryption schemes and key modes:
|Encryption scheme||Supported||Not supported|
|Apple FileVault||- user password|
|- recovery key|
|Bitlocker||- recovery key||- user password|
|- clear key||- PIN|
|- FVEK/VMK files|
|- TPM interaction|
|LUKS||- user password (all 8 keyslots)||- keyfile|
|VeraCrypt||- user password||- PIN|
Currently Drive Badger supports the following partition types and filesystems for each encryption scheme:
|Encryption scheme||Supported||Not supported|
|Apple FileVault||- APFS filesystem||- HFS+ filesystem|
|Bitlocker||- NTFS filesystem||- FAT filesystem|
|LUKS||- all filesystems|
|VeraCrypt||- system partitions||- non-system partitions|
|- FUSE-supported filesystems||- hidden partitions|
|- entire system drives|
|- TrueCrypt partitions|
Drive Badger uses 2 types of encryption keys:
Algorithm of mounting a new drive is very simple:
get-drive-encryption-keys.shscript), with keys assigned to given drive at the start, and removed from the rest of the list (in case if duplicated)
save-drive-encryption-key.shscript to assign it to the current drive
Such keys are stored in so called "keys directory" - which is simply a directory on persistent partition, that contains multiple files, one per hard drive serial number and encryption scheme, eg.
Most of such files contain exactly 1 key, which is valid for all encrypted partitions on the same drive. However in some rare scenarios, each partition can be encrypted with different key - then such files contain multiple keys, 1 per line.
Keys directory location and behaviour differs between Drive Badger and Mobile Badger modes:
In Drive Badger mode, keys directory location is pointed by script
/opt/drivebadger/internal/kali/get-keys-directory.sh - and it is relative to persistent partition mount point, and created automatically if not exists.
Sample file paths:
/run/live/persistence/sda3/.files/.keys/TNS5193TGS38SG.apfs /run/live/persistence/sda3/.files/.keys/NS11N546911301H05.bitlocker /run/live/persistence/sda3/.files/.keys/SanDisk_SD9SN8W2T00_19259H456424.veracrypt
SanDisk_SD9SN8W2T00_19259H456424 are drive serial numbers (depending on various hardware details, this string can contain just the serial number, or serial number prepended by full drive model).
Mobile Badger doesn't support target drive encryption, so for operator safety, there are some differences:
So the operator can decide, if he wants to keep drive keys on unencrypted target drive, or on (also unencrypted) internal SD card - whichever is easier or more convenient to hide/destroy in an emergency situation.
Unassigned keys, are the keys provided in configuration repositories, in
/opt/drivebadger/config/keys-*/*.keys files, or more exactly:
bitlocker.keysfiles for Bitlocker
veracrypt.keysfiles for VeraCrypt
luks.keysfiles for LUKS
filevault.keysfiles for Apple FileVault
There can be multiple such files - eg. one per department, building storey etc.
The whole encryption key management is divided into 6 scripts:
This script is responsible for loading all encryption keys, that should be checked for given partition. It gets:
It should just print keys on console, one per line. Standard order should be:
This script is the best place to implement some custom logic regarding order, in which keys should be checked.
This script simply saves given encryption key (when found for the first time) to a proper file in keys directory - so that such key will be found by
get-drive-encryption-keys.sh script next time.
This script has 2 separate locations:
/opt/drivebadger/internal/kali/get-keys-directory.sh- for Drive Badger
/opt/drivebadger/internal/mobile/get-keys-directory.sh- for Mobile Badger
It simply returns the keys directory (see above).
This script also has 2 separate locations:
/opt/drivebadger/internal/kali/show-key-stats.sh- for Drive Badger
/opt/drivebadger/internal/mobile/show-key-stats.sh- for Mobile Badger
It counts all configured keys and shows statistics. Sample output:
encryption mode | keys assigned to drives | repo keys unassigned | common | total repo keys | unique repo keys -------------------------------------------------------------------------------------------------------------- apfs | 1 | | | | bitlocker | 1 | 1643 | 1 | 1644 | 1644 luks | | 22 | | 22 | 22 veracrypt | 8 | 142 | 8 | 150 | 150
What can be seen in the following table: