Data integrity protection Data integrity protection with cryptsetup - PowerPoint PPT Presentation

Centre for Research on Cryptography and Security research.redhat.com crocs.fi.muni.cz Data integrity protection Data integrity protection with cryptsetup tools with cryptsetup tools What is the Linux dm-integrity module and What is the Linux dm-integrity module and why we extended dm-crypt to use authenticated encryption. why we extended dm-crypt to use authenticated encryption. Milan Brož Milan Brož FOSDEM, Brussels FOSDEM, Brussels gmazyland@gmail.com gmazyland@gmail.com February 4, 2018 February 4, 2018

Agenda ● Data integrity protection and disk encryption? ● dm-integrity and dm-crypt Linux kernel modules ● dm-integrity standalone mode ● dm-crypt authenticated encryption ● LUKS2

Full Disk Encryption (FDE) ● Disk sector level ● Sectors accessed independently ● 4k sector size today ● Data-at-rest protection ● Confidentiality ● Length-preserving encryption ● plaintext size = ciphertext size ● No data integrity protection

FDE images with Tux ... not only kind of glitch-art :-) ● Visualization of real on-disk encrypted data ● Generated with dm-crypt & cryptsetup ● BMP image (no check-sums)

FDE encryption example AES-XTS, IV is sector offset plaintext ciphertext

Wrongly used modes, IVs, nonces ciphertext patterns ECB mode XTS, constant IV

Length-preserving encryption no integrity, garbage-in, garbage-out mangled ciphertext decrypted plaintext

FDE threat model? ● Stolen device, disk in repair, ... ● Length-preserving, confidentiality only ● Data never used again ● Our model: Returned device ● Silent data corruption ● Implanted data without owner knowledge ● Could this happen? ● Lost disk returns to owner ● Devices traveling separately...

Another FDE trade-offs ● Whole sector not pseudo-randomly changed on every write. ● Granularity of ciphertext change ● Same plaintext = same ciphertext (in the same sector) ● Could we have randomized IVs? ● Replay attacks ● Revert to old valid content ● Need trusted store for root hash (Merkle tree)

Encryption block granularity (each following block is inverted here) AES block, 16B 4k disk sector

XTS Encryption block trade-off Every 64 byte re-written, ciphertext diff. The same byte was written :-) AES-XTS, IV is sec# AES-XTS, IV random

What is missing? ● Confidentiality + data integrity protection => authenticated encryption (AEAD) ● Ciphertext change granularity => randomized IV (or wide encryption modes) ● Pseudo-random change on every write => randomized IV ● Additional metadata per-sector

FDE with data integrity protection ● FreeBSD GELI – different approach ● Our requirements ● No special HW ● Commercial of-the-shelf SSDs ● Configurable per-sector metadata ● Use native sector size ● Reliable recovery on power fail ● Algorithm agnostic ● Free code & algorithms, no patents

Separation of storage and crypto ● dm-integrity ● Emulates per-sector metadata ● Optionally standalone mode (CRC32) ● dm-crypt ● Authenticated encryption ● Randomized IV ● Tags and IVs stored in per-sector metadata ● cryptsetup ● LUKS2 on-disk format ● User friendly activation

dm-integrity on-disk layout ● Superblock (SB) – persistent parameters ● Journal area ● Can be deactivated (write performance penalty) ● Metadata per 4k sector (packed) ● 32bits metadata (CRC32) – 0.1% of storage ● 256bits metadata (SHA256) – 0.78% of storage

dm-integrity standalone mode ● Non-cryptographic data check-sums ● Detects silent data corruption ● CRC32 or hash ● Per-sector check-sum ● Reads (validate) / Writes (update) ● No encryption of data ● Integritysetup tool

Integritysetup example # i n t e g r i t y s e t u p f o r m a t / d e v / s d b [ - I c r c 3 2 c ] F o r m a t t e d w i t h t a g s i z e 4 , i n t e r n a l i n t e g r i t y c r c 3 2 c . W i p i n g d e v i c e t o i n i t i a l i z e i n t e g r i t y c h e c k s u m . # i n t e g r i t y s e t u p o p e n / d e v / s d b t e s t [ - I c r c 3 2 c ] # i n t e g r i t y s e t u p s t a t u s t e s t t y p e : I N T E G R I T Y t a g s i z e : 4 i n t e g r i t y : c r c 3 2 c d e v i c e : / d e v / s d b s e c t o r s i z e : 5 1 2 b y t e s i n t e r l e a v e s e c t o r s : 3 2 7 6 8 s i z e : 2 0 6 4 3 9 2 s e c t o r s m o d e : r e a d / w r i t e j o u r n a l s i z e : 8 3 8 0 4 1 6 b y t e s j o u r n a l w a t e r m a r k : 5 0 % j o u r n a l c o m m i t t i m e : 1 0 0 0 0 m s # m k f s - t x f s / d e v / m a p p e r / t e s t . . . .

dm-crypt authenticated encryption ● Authenticated request ● Position must be authenticated ● Misplaced sector ● Random IV (nonce) ● On every write from RNG ● Collision probability negligible (!) ● No protection to replay attacks

Authenticated algorithms ● No perfect algorithm in kernel for FDE! ● Length-preserving modes + HMAC (too slow) ● Authenticated modes ● AES-GCM (96-bit nonce – collision is fatal) ● ChaCha20-Poly1305 (RFC7539, 96-bit nonce) ● Future: CAESAR (crypto competition finalists) ● AEGIS performs well ● Reason it remains experimental feature.

LUKS2 with integrity protection # c r y p t s e t u p l u k s F o r m a t - - t y p e l u k s 2 / d e v / s d b $ P A R A M S $ P A R A M S A E S - X T S + H M A C : - - c i p h e r a e s - x t s - p l a i n 6 4 - - i n t e g r i t y h m a c - s h a 2 5 6 $ P A R A M S C h a C h a 2 0 - p o l y 1 3 0 5 : - - c i p h e r c h a c h a 2 0 - r a n d o m - - i n t e g r i t y p o l y 1 3 0 5 # c r y p t s e t u p o p e n / d e v / s d b t e s t # l s b l k / d e v / s d b N A M E M A J : M I N S I Z E N A M E M A J : M I N S I Z E s d b 8 : 1 6 1 G s d b 8 : 1 6 1 G └─ t └─ t e s t _ d i f 2 5 3 : 0 9 5 2 M e s t _ d i f 2 5 3 : 0 9 5 9 . 5 M └─ t └─ t e s t 2 5 3 : 1 9 5 2 M e s t 2 5 3 : 1 9 5 9 . 5 M c r y p t s e t u p s t a t u s t e s t # t y p e : L U K S 2 t y p e : L U K S 2 c i p h e r : c h a c h a 2 0 - r a n d o m c i p h e r : a e s - x t s - p l a i n 6 4 k e y s i z e : 2 5 6 b i t s k e y s i z e : 5 1 2 b i t s k e y l o c a t i o n : k e y r i n g k e y l o c a t i o n : k e y r i n g i n t e g r i t y : p o l y 1 3 0 5 i n t e g r i t y : h m a c ( s h a 2 5 6 ) i n t e g r i t y k e y s i z e : 2 5 6 b i t s d e v i c e : / d e v / s d b d e v i c e : / d e v / s d b s e c t o r s i z e : 5 1 2 s e c t o r s i z e : 5 1 2 s i z e : 1 9 6 5 0 6 4 s e c t o r s s i z e : 1 9 4 9 7 0 4 s e c t o r s m o d e : r e a d / w r i t e m o d e : r e a d / w r i t e # c r y p t s e t u p c l o s e t e s t

Performance (example: fio simulated) ● SSD, 30% writes / 70% reads (very inefficient case)

Summary ● Try it ● cryptsetup 2.0.x, Linux kernel 4.12+ ● We need new AEAD algorithms ● Integrity protection on higher layer better? ● dm-integrity in future? ● Replaced by persistent memory ● Variable sector with inline metadata.

LUKS2 (in cryptsetup2) ● LUKS is a key management ● LUKS2 is on-disk format for LUKS extensions ● Metadata replicated (not keyslots) ● JSON metadata ● Argon2 key derivation function ● Kernel keyring ● Cryptsetup does not handle HW tokens directly. => token concept (metadata + external program) ● LUKS1 supported forever :-)

LUKS2 & tokens ● Token – metadata object in header => How to get a passphrase for a keyslot. 1) Keyring token (internal) ● External app for HW (TPM, Smartcard, ...) ● Passphrase in kernel keyring ● Cryptsetup activation is automatic 2) External token types ● LUKS2 stores metadata ● External app uses libcryptsetup to activation ● Tokens ignored by cryptsetup

Centre for Research on Cryptography and Security research.redhat.com crocs.fi.muni.cz Thanks for your attention. Q & A ? or use dm-crypt mailing list later Milan Brož Milan Brož FOSDEM, Brussels FOSDEM, Brussels gmazyland@gmail.com gmazyland@gmail.com February 4, 2018 February 4, 2018