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

SLIDE 1

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ž gmazyland@gmail.com gmazyland@gmail.com FOSDEM, Brussels FOSDEM, Brussels February 4, 2018 February 4, 2018

Centre for Research on Cryptography and Security

research.redhat.com crocs.fi.muni.cz

SLIDE 2

Agenda

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

SLIDE 3

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

SLIDE 4

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)

SLIDE 5

FDE encryption example

AES-XTS, IV is sector offset

plaintext ciphertext

SLIDE 6

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

SLIDE 7

Length-preserving encryption

no integrity, garbage-in, garbage-out

mangled ciphertext decrypted plaintext

SLIDE 8

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...

SLIDE 9

Another FDE trade-offs

Whole sector not pseudo-randomly changed
n 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)

SLIDE 10

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

SLIDE 11

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

SLIDE 12

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

SLIDE 13

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

SLIDE 14

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

SLIDE 15

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

SLIDE 16

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

SLIDE 17

Integritysetup example

# i n t e g r i t y s e t u p f

r

m a t / d e v / s d b [

I

c r c 3 2 c ] F

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

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

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

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

r

s : 3 2 7 6 8 s i z e : 2 6 4 3 9 2 s e c t

r

s m

d

e : r e a d / w r i t e j

u

r n a l s i z e : 8 3 8 4 1 6 b y t e s j

u

r n a l w a t e r m a r k : 5 % j

u

r n a l c

m

m i t t i m e : 1 m s # m k f s

t

x f s / d e v / m a p p e r / t e s t . . . .

SLIDE 18

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

SLIDE 19

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.

SLIDE 20

LUKS2 with integrity protection

# c r y p t s e t u p l u k s F

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

p
l

y 1 3 5 :

c

i p h e r c h a c h a 2

r

a n d

m
i

n t e g r i t y p

l

y 1 3 5 # c r y p t s e t u p

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 s d b 8 : 1 6 1 G └─t e s t _ d i f 2 5 3 : 9 5 2 M └─t e s t 2 5 3 : 1 9 5 2 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 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 : 5 1 2 b i t s k e y l

c

a t i

n

: k e y r i n g 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 s e c t

r

s i z e : 5 1 2 s i z e : 1 9 4 9 7 4 s e c t

r

s m

d

e : r e a d / w r i t e # c r y p t s e t u p c l

s

e t e s t N A M E M A J : M I N S I Z E s d b 8 : 1 6 1 G └─t e s t _ d i f 2 5 3 : 9 5 9 . 5 M └─t e s t 2 5 3 : 1 9 5 9 . 5 M t y p e : L U K S 2 c i p h e r : c h a c h a 2

r

a n d

m

k e y s i z e : 2 5 6 b i t s k e y l

c

a t i

n

: k e y r i n g i n t e g r i t y : p

l

y 1 3 5 d e v i c e : / d e v / s d b s e c t

r

s i z e : 5 1 2 s i z e : 1 9 6 5 6 4 s e c t

r

s m

d

e : r e a d / w r i t e

SLIDE 21

Performance (example: fio simulated)

SSD, 30% writes / 70% reads (very inefficient case)

SLIDE 22

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.

SLIDE 23

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 :-)

SLIDE 24

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

SLIDE 25

Thanks for your attention. Q & A ?

r use dm-crypt mailing list later

Centre for Research on Cryptography and Security