devices may be stolen physically. • Lost • Physical devices may be lost by accidents. • Safety when sold • No secrets are left inside. Otherwise, devices need to be physically destroyed! • Multi-tenancy • The storage device may be reused by others.
protect data at rest • At which level should data be encrypted? • Block device (Full-Disk-Encryption, FDE) • File (File-Based-Encryption, FBE) • Android once adopted FDE, but later changed to FBE • because FDE requires user-interaction before OS boot • https://source.android.com/security/encryption
of data is encrypted • Safest and simple to use. • Public cloud vendors provides FDE by default • Azure Data Encryption-at-Rest • Encryption at Rest in Google Cloud Platform • dm-crypt, a Linux kernel module, is commonly used for FDE • Data are encrypted transparently in kernel. • Hardware acceleration (AES-NI) is used when available.
we use AES-256-XTS-PLAIN64 • AES is the fastest block cipher thanks to AES-NI • XTS is safe enough as long as a data unit does not exceed 220 blocks, which is the case for dm-crypt. • Sat-san wrote a blog article analyzing performance: • https://blog.cybozu.io/entry/2019/03/08/170000
much as possible • Data-Encryption-Key (DEK) • AES key for dm-crypt • encrypted with KEK. • Key-Encryption-Key (KEK) • can be a one-time pad to encrypt DEKs. • stored securely in vaults or encrypted further with passwords.
can store data with encryption. These are called Self-Encrypting Drives (SED). • However, SEDs often poorly implement encryptions: • Self-Encrypting SSDs Vulnerable to Attack, Microsoft Warns • Personally, I do not buy them. • Higher price, lower security.
security • disposability by crypto-shredding • Full-Disk-Encryption (FDE) is simple and secure • but sometimes File-Based-Encryption (FBE) wins. • Protect KEKs securely with TPM, (software) vaults, etc. • Do not buy Self-Encrypting Drives (SED)