Linux Kernel Cryptographic API and Use Cases

©ARM 2017
Linux Kernel Cryptographic
API and use cases
Gilad Ben-Yossef
KernelTel-Aviv Meetup
Principal Software Engineer
Security IP - Systems & Software Group
15 March 2017

©ARM 20172
About me
 I’m Gilad Ben-Yossef
 I work on upstream Linux kernel cryptography and security in general and
Arm® TrustZone® CryptoCell® support in particular.
 I’m working in various forms on the Linux kernel and other Open Source
project for close to twenty years – i.e. I’m an old bugger… 
 I co-authored “Building Embedded Linux Systems” 2nd edition from O’Reilly.
 I’m a co-founder of HaMakor, an Israeli NPO for free and open source software
and of August Penguin.
 During my B.A. I once took a course in Cryptography but never finished it
because the home assignments were too time consuming – i.e. I am not a
cryptographer.

©ARM 20174
Agenda
Topic
19:15 About me
19:20 Alice, meet Bob - a (very) short introduction to cryptography
19:35 Here be Dragons - the Linux crypto API
21:00 Tea break
21:15 DM-Crypt and DM-Verity – protecting your file systems from the
scum of the universe
21:50 Q&A

AES SHA-1 SHA-2 SHA-3
SHA-256 MD5 DES 3DES
CBC OFB MAC HMAC
GMAC ECB CFB CTR RSA
DSA DH ECDH ECC FIPS
ECDSA EDDSA NIST NSA

©ARM 20176
Alice, meet Bob –
A (very) short introduction to Cryptography

©ARM 20177
Symmetric Encryption
EP C
K
DC P
K
C = E(k, P) P = D(k, C)
P: Plain text
C: Cipher text
K: Key
E: Encryption
D: Decryption
E is a function that takes a key and a block of plain text* and outputs a block of
random looking cipher text *.
D is the inverse function to D which takes the random looking cipher text* and the
same key as input and outputs the original plain text*.
*Which doesn’t have to be and often isn’t text but rather binary data.

©ARM 20178
Block Ciphers
P = P1 P2 … Pi … Pn
C = C1 C2 … Ci … Cn
P: Plain text
C: Cipher text
K: Key
E: Encryption
D: Decryption
Ek Ek Ek Ek
Break down message to blocks, encrypt each block using the key
Examples: DES, 3DES,AES

©ARM 20179
The problem with block ciphers
Identical plain text block yield identical cipher text blocks
Tux the Penguin, the Linux mascot. Created in 1996 by Larry Ewing with The GIMP.
"Permission to use and/or modify this image is granted provided you acknowledge me lewing@isc.tamu.edu and The GIMP if someone asks.”
ECB Tux taken from Wikipedia: https://commons.wikimedia.org/wiki/File:Tux_ecb.jpg

©ARM 201710
Modes of Operation
 Symmetric cryptographic functions E and D can be treated as black boxes.
 We can define different ways to use these black boxes to encrypt/decrypt our
messages.
 These are referred to as the Modes of Operation of the symmetric cipher –
how we choose to use it.
 We previously saw the most basic mode of operation called Electronic Code
Book mode, or ECB mode for short.
 Other modes of operations are defined that can, among other things, turn a
block cipher into a stream cipher, thus making it more secure.

©ARM 201711
Cipher Chaining
EK
P1
IV
C1
EK
P2
C2
EK
P2
C2
P: Plain text
C: Cipher text
K: Key
E: Encryption
D: Decryption
IV: InitialVector
This is the Cipher Block Chaining mode, or CBC mode for short:
Each cipher block is dependent on the key and the previous blocks.
Other operation modes include Output FeedBack, Cipher FeedBack and CounTeR modes.
C0 = IV
Ci = Ek(Pi  Ci-1)
Pi = Dk(Ci)  Ci-1

©ARM 201712
Cryptographic Hashes (Digests)
 The ideal cryptographic hash function is:
 Deterministic
 Quick to compute
 Infeasible to generate a message from its hash
value except by brute force
 A small change to a message changes the hash
value so extensively that the new hash value
appears uncorrelated with the old hash value
 Infeasible to find two different messages with
the same hash value
Examples: MD5, SHA1, SHA2, SHA3
“Regular” hash
function requirements
Source: Wikipedia

©ARM 201713
Message Authentication Codes
 Message Authentication Code, or MAC for short, is a method for generating a
value that is computed from a message and a secret (key) that can tells the
recipient:
 That the message has not be changed from the way it was originally sent
 That the sender knows the secret (key)
 For example, this can be a (bad!) MAC built on top of a cryptographic hash
function:
 Example MACs: CBC-MAC, HMAC, GMAC
MACk(M) = H(K || M)

©ARM 201714
Hash Based Message Authentication Codes
 Where
 H is a cryptographic hash function,
 K is the secret key,
 m is the message to be authenticated,
 K' is another secret key, derived from the original key K (by
padding K to the right with extra zeroes to the input block size
of the hash function, or by hashing K if it is longer than that
block size),
 || denotes concatenation,
 ⊕ denotes exclusive or (XOR),
 opad is the outer padding (0x5c5c5c…5c5c)
 ipad is the inner padding (0x363636…3636).
HMAC(K, m) = H((K’  opad) || H(K’  ipad) || m))
Source: Wikipedia

©ARM 201715
Authenticated Encryption
 Authenticated Encryption with Associated Data (AEAD)
is a form of encryption which simultaneously provides
confidentiality, integrity, and authenticity assurances on the
data; decryption is combined in single step with integrity
verification.
 These attributes are provided under a single, easy to use
programming interface.
 An example of an AEAD in common use is Galois/Counter
Mode, or GCM for short, shown in the picture above.
 GCM is considered a very efficient AEAD since it can produce both
the cipher text and the MAC in a single pass on the data.

©ARM 201716
Here be Dragons -
The Linux kernel Crypto API

©ARM 201717
Transformations
 A transformation is an algorithm that transforms data.
 A transformation can be a cipher (i.e. encryption and decryption), whether symmetric or
asymmetric, a hash, compression of data, IV generation and random number generation
 This is why handle to crypto API object is typically named “tfm”.
 A transformation implementation is a code module that registers with the
kernel that can provide a transformation.
 It can be just code running on the CPU, code that uses a special instruction as part of the
CPU or a driver to some piece of hardware off of the CPU.
 Multiple transformation implementation can exist that provide that same
transformation.
 E.g. in x86_64 there are at least implementation of AES: AES-NI, assembler implementation,
and plain C.

©ARM 201718
Templates
 A transformation can be self contained (.e.g AES or SHA-2) but it can also be a
template that works on another transformation:
 CTS(AES) is AES working in Counter operation mode.
 HMAC(SHA256) is SHA 256 being used as an HMAC.
 Templates can be cascaded
 E.g. RFC4106(GCM(AES))) is AES in GCM operation mode as used in IPsec.
 Templates can also express generic implementation augmentation.
 For example CRYPTD(AES) refers to code that runs an AES implementation in parallel inside
kernel threads on all the system CPUs in parallel.
 The same template works on multiple underlying transformations.
 E.g. CTS(AES) and CTS(3DES)

©ARM 201719
Priorities and true names
 There can be multiple transformation implementation, including template
implementation, which provided the exact same transformation
 E.g. aes-ni, aes-asm and aes-generic are three different AES implementation on x86_64
 When you use a generic name (e.g. aes) to refer to a transformation, the
Crypto API will provide you the implementation with the highest priority that
matches your request, based on priority value provided by the implementation
when they register with the Crypto API.
 As we will see ahead you can limit the Crypto API to ignore certain type of providers based
on their properties as we will see ahead.
 If you want to refer to a specific implementation, use its driver name to refer
to it.
 E.g.“aes-ni” forces the selection of the implementation that uses the AES-NI instruction.

©ARM 201720
/proc/crypto
gby@gby:~$ cat /proc/crypto | grep name
name : crc32
name : xts(aes)
name : lrw(aes)
name : __xts-aes-aesni
name : __lrw-aes-aesni
name : pcbc(aes)
name : rfc4106(gcm(aes))
name : __gcm-aes-aesni
name : ctr(aes)
name : __ctr-aes-aesni
name : cbc(aes)
name : __ecb-aes-aesni
name : ecb(aes)
name : __cbc-aes-aesni
name : __ecb-aes-aesni
name : __aes-aesni
name : aes
name : aes
name : crct10dif
name : crct10dif
name : crc32c
name : stdrng
name : lzo
name : aes
name : sha1
name : md5
We have 3 different implementations of AES
We can use AES in 6 different operation modes

©ARM 201721
/proc/crypto
gby@gby:~$ cat /proc/crypto
name : crc32
driver : crc32-pclmul
module : crc32_pclmul
priority : 200
refcnt : 1
selftest : passed
type : shash
blocksize : 1
digestsize : 4
name : xts(aes)
driver : xts-aes-aesni
module : aesni_intel
priority : 400
refcnt : 1
selftest : passed
type : ablkcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
geniv : <default>
Generic name Driver namePriority

©ARM 201722
Synchronous versus Asynchronous
 A transformation implementation may be either synchronous or asynchronous
 Synchronous implementations
 Run wholly on the CPU itself in a synchronous fashion (take CPU cycles during all the run)
 Access virtual memory using the CPU MMU mechanism
 Asynchronous implementations
 MAY be implemented using off-CPU resources (i.e. typically dedicated hardware), or not
 MAY access memory via DMA and not have access to MMU, or not.
 In fact, synchronous implementation are a sub group of asynchronous ones!
 E.g. cryptd(aes-ni) turns the synchronous aes-ni implementation into an asynchronous
implementation by running it on several cores in parallel.
 You can limit yourself to working only with synchronous implementations by
passing the CRYPTO_ALG_ASYNC ask flag to allocation calls.

©ARM 201723
Backlog
 Transformation implementations have a certain capacity for in flight requests
 i.e. descriptor ring space, hardware FIFO etc.
 If you pass the CRYPTO_TFM_REQ_MAY_BACKLOG flag to callback setting
API call, you will allow the implementation provider to queue up back log word
to a software queue if it doesn’t have enough capacity.
 If this happens, your callback function will be called twice:
 Once with err set to –EINPROGRESS to indicate it got queued off of the backlog.
 A second time when it is actually processed
 The kernel now has a generic implementation of this mechanism for
transformation providers can use to implement this.
 However, the author believes it is currently buggy and is working to fix it… 

©ARM 201724
API Typical Life Cycle
 Allocate a transformation object (tfm)
 Get properties of the transformation chosen by the kernel (e.g. digest size)
 Set global transformation properties (e.g. encryption key)
 Allocate a request object
 Set request specific parameters, such as GFP flags and callback function to call
when operation finish
 Initialize the request
 Feed data (e.g. buffers to encrypt or hash)
 Finalize (e.g. read final HMAC value)
 Free request object
 Free transformation object

©ARM 201725
API documentation and code examples
 No use copy & paste them here, so just go to:
 Documentation/crypto
or
 http://www.chronox.de/crypto-API/crypto/index.html

©ARM 201726
Pitfalls to look out for
 This call requests only synchronous implementations
tfm = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
 Yes, it’s totally backwards – the mask flag masks out the async. Implementations!
 If you see code that passes NULL as a callback like the following, it’s probably
used the mask flag (see above) to request only synchronous implementations:
ahash_request_set_callback(req, 0, NULL, NULL);
 Remember that operation may complete synchronously or asynchronously
based on the transformation provider discretion only and you need to handle
both cases!
 Don’t ignore the err parameter of the callback.
 Remember that ff you passed the CRYPTO_TFM_REQ_MAY_BACKLOG flag
when setting the callback, your callback may be called twice!
 Even the request init function might sometime complete asynchronously.

©ARM 201728
DM-Crypt
 dm-crypt is a transparent disk encryption subsystem in Linux
 It is part of the device mapper infrastructure, and uses cryptographic routines
from the kernel's Crypto API.
 dm-crypt was designed to support advanced modes of operation, such as XTS,
LRW and ESSIV, in order to avoid watermarking attacks.
 dm-crypt is implemented as a device mapper target and may be stacked on top
of other device mapper transformations.
 It can thus encrypt whole disks (including removable media), partitions, software RAID
volumes, logical volumes, as well as files.
 It appears as a block device, which can be used to back file systems, swap or as an LVM
physical volume.
 It is used by Android devices to implement Full Disk Encryption.

©ARM 201729
Simple dm-crypt setup example
# cryptsetup luksFormat fs3.img
# cryptsetup open --type luks fs3.img croot
# mke2fs /dev/mapper/croot
# mount -t ext2 /dev/mapper/croot /media
# umount /media/
# cryptsetup close croot
This examples uses AES in XTS operating mode to protect a loopback
mounted partition file.
Make sure to remember your chosen key or your data is lost!

©ARM 201730
DM-Verity
 Device-Mapper's "verity" target provides transparent integrity checking of block
devices using a cryptographic digest provided by the kernel crypto API.T
 This target is read-only.
 dm-verity helps prevent persistent rootkits that can hold onto root privileges
and compromise devices.
 The dm-verity feature lets you look at a block device, the underlying storage
layer of the file system, and determine if it matches its expected configuration.
 It does this using a cryptographic hash tree. For every block (typically 4k), there
is a SHA256 hash.
 Dm-verity can optionally FEC to protect against hash data corruptions.
 DM-Verity is used by Android devices.

©ARM 201731
How does DM-Verity work?
 Dm-verity uses a Merkle tree of storage blocks to protect the integrity of the
read only data on the storage device, in a way that the integrity can be
evaluated in a lazy fashion during runtime instead of pre-mount time.
 It needs a singular trusted root hash to achieve security

©ARM 201732
Simple dm-verity setup example
# veritysetup format filesystem.img signature.img
# veritysetup create vroot filesystem.img signature.img
ffa0a985fd78462d95c9b1ae7c9e49…5e3f13c10e4700058b8ed28
# mount -t ext2 /dev/mapper/vroot /media/
# umount /media
# veritysetup remove vroot
This examples uses SHA 256 to protect the integrity of the loopback
file system provided the root hash is secure.

The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited
(or its subsidiaries) in the US and/or elsewhere. All rights reserved. All other marks featured may be
trademarks of their respective owners.
Copyright © 2017 ARM Limited
©ARM 2017
Thank you for listening!
Questions?
@gilad
gilad@benyossef.com

Linux Kernel Cryptographic API and Use Cases

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Linux Kernel Cryptographic API and Use Cases (20)

More from Kernel TLV (15)

Recently uploaded (20)

Linux Kernel Cryptographic API and Use Cases