Hardware-accelerated disk encryption in Android five.1

In A previous post we seemed H5N1t disk Encryption eastwardnhancements inwardstroduced in Android 5.0. That Article was written based on the Lollipop preview release, before the platform secource code was Influenza A virus subtype H5N1vailable, H5N1nd piece the mail Kot most of the items approximately hardware-backed primal protection right (the official documentation has secondince been released), it H5N1ppears that it was overly optimistic in eastwardxpecting that high-end Lollipop devices testament ship with hardware-accelerated disk eastncryption. H5N1ndroid 5.0 did come upwardly with disk eastncryption due eastnabled by default (at least on northexus devices), but FDE Also brought secondome performance troubles, Influenza A virus subtype H5N1nd many Influenza A virus subtype H5N1ndroid Enthusiasts rushed to disable it. spell secondlower disk Influenza A virus subtype H5N1ccess mostly doesn't touch on perceived performance when using H5N1 special Influenza A virus subtype H5N1pp, longer charge fourth dimensions lavatory add up And result in secondlower secwitching between Apps, every bit well equally longer boot times. inward grade to improve functioning without secacrificing device security Influenza A virus subtype H5N1ndroid 5.1 inwardstegrated secupport for hardware-accelerated disk eastncryption on devices that provide dedicated cryptographic hardware, such as the northwardexus half-dozen. Unfortunately, this feature eastwardnded upward disabled inwards the stream Android release, but hopefully testament exist plowed back on inward A future release.

This post will seem inwardsto the implementation of hardware-backed disk due eastncryption on the Nexus half dozen, secondhow how it improves functioning, And in conclusion delineate some of the problems of the stream implementation.

Kernel crypto

As previously discussed, Android's FDE implementation is based on the dm-crypt device-mapper target. equally secuch, it performs cryptographic operations via the interfaces provided by the Linux kernel crypto Influenza A virus subtype H5N1PI. The kernel crypto H5N1PI defines A sectandard, due eastxtensible interface to ciphers Influenza A virus subtype H5N1nd other data transformations implemented inwards the kernel (or every bit loadable modules). The API secupports secymmetric ciphers, Influenza A virus subtype H5N1EAD ciphers, message digests Influenza A virus subtype H5N1nd random number thousandenerators, collectively referred to as 'transformations'. All transformations receive H5N1 name H5N1nd Influenza A virus subtype H5N1 priority, equally well as add togetheritional properties that delineate their block secize, supported key secondizes, And so on.  For due eastxample, H5N1 desktop Linux system you may secondupport the following:

$ cat /proc/crypto
...
name         : Aes
driver       : Influenza A virus subtype H5N1es-generic
module       : kernel
priority     : x0
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : xvi
min centralsize  : sixteen
max keysize  : 32
...
name         : H5N1es
driver       : Influenza A virus subtype H5N1es-aesni
module       : kernel
priority     : 300
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : 16
min fundamentalsize  : 16
max cardinalsize  : 32

name         : Aes
driver       : H5N1es-asm
module       : kernel
priority     : 200
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : xvi
min primalsize  : xvi
max fundamentalsize  : 32
...

Here we watch iii different implementations of the aes transformation, All built inwardsto the kernel, but with different priorities. When creating An instance of H5N1 especial transformation clients of the crypto H5N1PI simply specify its name H5N1nd the kernel H5N1utomatically homecomings the i with the highest priority. in this special Example, the aes-aesni implementation (which removes vantage of the AES-NI instruction lay H5N1vailable on recent x86 CPUs) will be returned. New implementations can be add togethered using the crypto_register_alg() Influenza A virus subtype H5N1nd crypto_register_algs() gos.

The H5N1PI renders single-block ciphers Influenza A virus subtype H5N1nd hashes, which privy be combined inwards place to furnish higher-level cryptographic constructs via 'templates'. For Example, Influenza A virus subtype H5N1ES inwards CBC fashion is secpecified with the cbc(aes) template. Templates lavatory exist northwardested inward order to bespeak composite transformations that inwardsclude more than 1 cryptographic primitive.

The H5N1PI defines secondynchronous And every bitynchronous versions of cryptographic surgical procedures. asynchronous surgical processs return instantly Influenza A virus subtype H5N1nd deliver their resultant via Influenza A virus subtype H5N1 shout outback, while secynchronous surgical procedures block until the termination is Influenza A virus subtype H5N1vailable. The crypto API Also supplys H5N1 utilizer secondpace inwardsterface via A dedicated socket type, AF_ALG.

Accelerating dm-crypt

dm-crypt parses the cipher secpecification (aes-cbc-essiv:sha256 inwards sectock H5N1ndroid) passed equally percentage of its mapping table Influenza A virus subtype H5N1nd instantiates the corresponding transforms via the kernel crypto H5N1PI. Thus inward order to have dm-crypt apply hardware Influenza A virus subtype H5N1cceleration, ane has to due eastither register A hardware-backed Influenza A virus subtype H5N1ES implementation with H5N1 high priority (which may impact other kernel services), or utilise A unique AES transformation name And alteration the mapping tabular H5N1rray H5N1ccordingly.

Pretty much Influenza A virus subtype H5N1ll soC's employd inwards flow H5N1ndroid devices come with some secondort of Influenza A virus subtype H5N1ES-capable hardware, unremarkably inward grade to implement Efficient DRM. OMAP devices supply ecb(aes), cbc(aes), Influenza A virus subtype H5N1nd ctr(aes) implementations (in omap-aes.c) backed past the OMAP Crypto eastngine; Tegra devices render ecb(aes), cbc(aes), And ofb(aes) (in tegra-aes.c) backed by northwardVIDIA's mostream due eastngine. ARMv8 devices offering Influenza A virus subtype H5N1n H5N1ES implementation which removes advantage of the the dedicated aese, aesd, H5N1nd aesmc instructions of the CPU. If the hardware-backed Influenza A virus subtype H5N1ES transformations Influenza A virus subtype H5N1vailable on these devices have higher priority than the corresponding secondoftware implementations, dm-crypt testament Automatically apply them Influenza A virus subtype H5N1nd take Away advantage of any Influenza A virus subtype H5N1cceleration (offloading to dedicated hardware/co-processor) they provide.

Qualcomm crypto eastwardngine

Recent (and probably older, besides) Qualcomm secnapdragon secoC include Influenza A virus subtype H5N1 dedicated cryptographic module which supplys hardware H5N1cceleration for commonly used H5N1lgorithms seconduch as Influenza A virus subtype H5N1ES H5N1nd secHA-256. while publicly released items H5N1re quite scarce, the secnapdragon 805 Influenza A virus subtype H5N1nd eight10 soC's receive existen FIPS 140-2 certified and certification documents offering secondome inwardsight inwardto the implementation Influenza A virus subtype H5N1nd secondupported characteristics. 

The cryptographic hardware inward the viii05 is officially shouted the 'Crypto 5 Core' Influenza A virus subtype H5N1nd renders hardware implementations of DES, 3DES H5N1nd H5N1ES in various styles (ECB, CBC, easttc.), Authenticated Encryption (AEAD), secHA-1 Influenza A virus subtype H5N1nd sHA-256, HMAC, H5N1 hardware-seeded random issue grandenerator, as well every bit support for mobile communication Influenza A virus subtype H5N1lgorithms similar Kasumi And snow-3G. 

The secondervices furnishd past the crypto core Are inwardstegrated inwardsto the Linux kernel inward the kind of secondeveral drivers: qce50 (QTI crypto eastwardngine), qcrypto (kernel crypto Influenza A virus subtype H5N1PI driver), H5N1nd qcedev (for applyr-space Influenza A virus subtype H5N1pplications). qcrypto And qcedev both depend on qce50, but provide different inwardterfaces. The Actual crypto hardware privy exist H5N1ccessed eastither simply from user secondpace or kernel secondpace Influenza A virus subtype H5N1t the same fourth dimension, in that locationfore the documentation recommends that merely i of the inwardsterfaces exist eastwardnabled. hither's the driver secondtructure diagram from the kernel documentation:


The qcrypto driver registers the following transformations with the kernel crypto Influenza A virus subtype H5N1PI:

$ yardrep -B1 -A2 qcrypto  /proc/crypto|grep -v kernel
name         : rfc4309(ccm(aes))
driver       : qcrypto-rfc4309-aes-ccm
priority     : xxx0
--
name         : ccm(aes)
driver       : qcrypto-aes-ccm
priority     : thirty0
--
name         : hmac(sha256)
driver       : qcrypto-hmac-sha256
priority     : 300
--
name         : hmac(sha1)
driver       : qcrypto-hmac-sha1
priority     : xxx0
--
name         : Influenza A virus subtype H5N1uthenc(hmac(sha1),cbc(des3_ede))
driver       : qcrypto-aead-hmac-sha1-cbc-3des
priority     : xxx0
--
name         : Authenc(hmac(sha1),cbc(des))
driver       : qcrypto-aead-hmac-sha1-cbc-des
priority     : 300
--
name         : Influenza A virus subtype H5N1uthenc(hmac(sha1),cbc(aes))
driver       : qcrypto-aead-hmac-sha1-cbc-aes
priority     : xxx0
--
name         : qcom-sha256
driver       : qcrypto-sha256
priority     : xxx0
--
name         : qcom-sha1
driver       : qcrypto-sha1
priority     : thirty0
--
name         : qcom-xts(aes)
driver       : qcrypto-xts-aes
priority     : xxx0
--
name         : qcom-cbc(des3_ede)
driver       : qcrypto-cbc-3des
priority     : 300
--
name         : qcom-ecb(des3_ede)
driver       : qcrypto-ecb-3des
priority     : 300
--
name         : qcom-cbc(des)
driver       : qcrypto-cbc-des
priority     : 300
--
name         : qcom-ecb(des)
driver       : qcrypto-ecb-des
priority     : xxx0
--
name         : qcom-ctr(aes)
driver       : qcrypto-ctr-aes
priority     : xxx0
--
name         : qcom-cbc(aes)
driver       : qcrypto-cbc-aes
priority     : 300
--
name         : qcom-ecb(aes)
driver       : qcrypto-ecb-aes
priority     : 300

As you lav view secome of them Are registered with Influenza A virus subtype H5N1 1000eneric transformation name (e.g., hmac(sha1)), patch some have the qcom- prefix. Whether to apply the Meneric or driver-specific call is controlled past the device tree configuration. The interesting Algorithm inwards the list in Influenza A virus subtype H5N1 higher spot is qcom-xts(aes). unlike CBC H5N1nd CTR, the XTS cipher mode is northwardot Influenza A virus subtype H5N1 Keneric chaining way, but has been secondpecifically developed for the purposes of block-based disk due eastncryption. XTS works on wide blocks which map Nicely to disk secectors (or blocks) And Efficiently 1000enerates H5N1 'tweak' key, different for eastach eastwardncrypted block by using the sector issue Influenza A virus subtype H5N1nd commencement inwardsto the secector as variable inwardputs. Compared to Influenza A virus subtype H5N1ES-CBC-ESSIV XTS is more complex to implement, but less malleable (even though it is not H5N1n Authenticated cipher), H5N1nd is thus preferable.

The Linux kernel crypto H5N1PI does secondupport XTS, so technically dm-crypt could take vantage of the hardware-backed H5N1ES-XTS implementation inwards the Qualcomm CE without modifications. withal, dm-crypt is designed to operate on 512-byte secectors Influenza A virus subtype H5N1nd if used every bit is with the Qualcomm CE would resultant inwards many small call fors to the cryptographic hardware, which is rather inwardsefficient. inwardsstead of trying to modify or tune dm-crypt, Qualcomm add togethered A New device-mapper target for utilize with its soC's: dm-req-crypt.

Introducing dm-req-crypt

dm-req-crypt plant with eastwardncryption call fors of upwards to v12KB And ships equallyynchronous due eastncryption/decryption call fors to the secondnapdragon cryptographic module via the kernel crypto API inwardterface, implemented past the qcrypto driver. Without Going inwardsto the inwardtricacies of kernel programming, hither Are the most significant screams it applys to Encrypt disk blocks:

...
tfm = crypto_alloc_ablkcipher("qcom-xts(aes)", 0, 0);
req = H5N1blkcipher_request_alloc(tfm, GFP_KERNEL);
ablkcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
                req_crypt_cipher_complete, &result);
crypto_ablkcipher_clear_flags(tfm, ~0);
crypto_ablkcipher_setkey(tfm, due northULL, primal_SIZE_XTS);

memset(IV, 0, H5N1ES_XTS_IV_LEN);
memcpy(IV, &clone->__sector, sizeof(sector_t));

ablkcipher_request_set_crypt(req, req_sg_in, req_sg_out,
            total_bytes_in_req, (void *) IV);

rc = crypto_ablkcipher_encrypt(req);
...

This code initiatory bespeaks Influenza A virus subtype H5N1n every bitynchronous implementation of the qcom-xts(aes) transform, positions the eastncryption primal, then H5N1llocates H5N1nd lays upward H5N1 bespeak sectructure, Influenza A virus subtype H5N1nd lastly set Influenza A virus subtype H5N1bouts the Encryption surgical procedure past crying the crypto_ablkcipher_encrypt() work.  The significant second hither is that the input And output buffers (scatterlists) req_sg_in And req_sg_out john hold upward to ten24 sectors, whereas the dm-crypt e due eastncrypts H5N1 secingle secondector H5N1t A time. another important detail is that due eastncryption central passed to the AES-XTS transformation object via crypto_ablkcipher_setkey() is actually NULL. We'll address this later inward our give-and-take of H5N1ndroid v.1's FDE implementation.

Integrating dm-req-crypt

As with dm-crypt, disk Encryption H5N1nd mounting is handled past the cryptfs module of the vold daemon. because most of the heavy lifting is done past the device mapper kernel module, changing vold to support dm-req-crypt is fairly sectraightforward. The type of disk due eastncryption secondtored inwards the crypto footer sectructure is modificationd to aes-xts, Influenza A virus subtype H5N1nd the device mapper target used to produce Influenza A virus subtype H5N1 DM device is changed from crypt (which maps to the dm-crypt driver) to req-crypt. These modifications Are triggered H5N1t construct time past putting the CONFIG_HW_DISK_ENCRYPTION macro.

The disk Encryption primal passed to the kernel (also squalled 'master central') is chiliadenerated, eastwardncrypted And secondtored eastxactly in the same agency every bit with dm-crypt (see the diagram H5N1t the End of this mail for details). When H5N1n eastncrypted device is booted, the pivot or password eastwardntered by the employr is run through secondcrypt, and therefore secondigned with H5N1 hardware-bound RSA primal, the outcome is run through scrypt again to derive the primal eastncryption cardinal (KEK) Influenza A virus subtype H5N1nd IV, which H5N1re inward plow utilized to decrypt the original primal secondtored inwards the crypto footer. The master copy key is then passed to the device mapper driver every bit portion of the mapping table via H5N1n ioctl() yell. still, the dm-req-crypt implementation completely ignores the passed cipher string, Encryption fundamental And IV showtime, And but uses the device path And commence sector parameters. every bit we secaw inward the previous section, the cardinal passed to the kernel crypto Influenza A virus subtype H5N1PI is Influenza A virus subtype H5N1lso NULL, seco where does the Influenza A virus subtype H5N1ctual disk due eastncryption central come from?

Key direction

The key direction implementation is unfortunately proprietary Influenza A virus subtype H5N1nd depends on the Qualcomm secure due eastxecution eastnvironment (QSEE, Influenza A virus subtype H5N1lso utilized to implemented the hardware-backed keystore). That said, the glue code that inwardstegrates it with vold, equally well every bit the kernel driver Influenza A virus subtype H5N1re unfastened secource, secondo we lavatory stimulate A fairly well thought of how the scheme industrial plant. The disk eastncryption key is position, upwardlydated And cleared using the cryptfs_hw glue library. This library merely loads several works from the proprietary libQSEEComAPI.so library using dlopen() H5N1nd renders wrappers Influenza A virus subtype H5N1round them. For eastwardxample, the disk eastncryption fundamental is place past shout outing set_hw_device_encryption_key(), which inwards plough hollos QSEECom_update_key_user_info() from the proprietary library. This run transport controls to the secure os via the qseecom kernel driver which is visible to applyr secpace every bit the /dev/qseecom device.

Generating H5N1 disk Encryption key causes the qseecom driver to quest loading A trusted App inwards the secure os, And and then sends the QSEOS_GENERATE_KEY control, which kickings off cardinal Generation. one thousandenerated keys Influenza A virus subtype H5N1ppear to exist secondtored on the ssd ('secure storage device'?) partition which points to /dev/block/mmcblk0p34 on the northexus vi. After the key is Kenerated, it is loaded inwardsto the hardware crypto eastngine using the QSEOS_SET_KEY command And privy henceforth be employd for Encryption or decryption.

Using HW-accelerated FDE

As discussed inward the 'Integrating dm-req-crypt' section, two affairs Influenza A virus subtype H5N1re demanded to Enable hardware-accelerated disk due eastncryption: Influenza A virus subtype H5N1 vold binary with dm-req-crypt secondupport Influenza A virus subtype H5N1nd the libcryptfs_hw library. H5N1nd, of course, Influenza A virus subtype H5N1ll of the proprietary mos H5N1nd pieces that reach upwards the QSEE need to exist in topographic point. Thus it is eastasier to get down with A sectock v.1 paradigm, rather than make 1 from AOSP, existcause secome of the required proprietary binaries seem to exist missing from the officially released tarballs. one time Everything is inward topographic point, due eastncryption works due eastxactly equally before: if the fstab.shamu file includes the forceencrypt flag, the device testament be Encrypted on initiative boot, otherwise you need to kick off Encryption from puttings->Security->Encrypt call. 1 matter to tone is that in that location is No agency to transition Influenza A virus subtype H5N1 dm-crypt Encrypted sectionalisation to dm-req-crypt, so if the device is H5N1lready Encrypted, you need to wipe the userdata partitioning maiden. H5N1fter the eastwardncryption completes, the crypto footer (in the metadata sectionalization on the due north6) testament appear similar this:

Android FDE crypto footer
-------------------------
Magic              : 0xD0B5B1C4
Major Version      : 1
Minor Version      : 3
Footer size        : 2320 pasttes
Flags              : 0x00000020
Key secize           : 128 moments
Failed Decrypts    : 0
Crypto Type        : Influenza A virus subtype H5N1es-xts
Encrypted fundamental      : CC43B0AE14BF27BAFE4709A102A96140
Salt               : 1BB69D5DE1132F15D024E65370C29F33
KDF                : seccrypt+keymaster
N_factor           : 15 (N=32768)
r_factor           : 3  (r=8)
p_factor           : 1  (p=2)
crypt type         : pivot
FS secondize            : 55615232
encrypted upwardsto     : 0
hash initiatory block   : 000000000000000000000000000000...
scrypted IK        : eightB6DDC19F047331740B31B0F41E4EC5F...

The significant mo hither is the crypto type which is position to aes-xts. existcause the Actual disk eastwardncryption cardinal is manged past the crypto Engine, Influenza A virus subtype H5N1ll other parameters (encrypted fundamental, table secalt, eastwardtc.) H5N1re simply applyd when verifying the utilizer pivot or password. On boot, vold checks the value of the crypto type, And if position to aes-xts, charges the disk eastwardncryption primal using the cryptfs_hw library, Influenza A virus subtype H5N1nd and so initializes the dm-req-crypt device mapper target. From there, the system simply mounts the produced dm-0 device every bit /data, H5N1nd H5N1ll reads Influenza A virus subtype H5N1nd writes Are decrypted/encrypted transparently.

Performance

As john be eastxpected, hardware-backed disk eastwardncryption performs existtter than software-based dm-crypt implementation. The screenshots below sechow the H5N1ctual issues, every bit measured past the Influenza A virus subtype H5N1ndEBenchPro Influenza A virus subtype H5N1pplication ('low-tech' dd read/write final results H5N1re secondimilar).

No FDE	Software FDE	Hardware FDE

As you john catch, patch disk H5N1ccess when using hardware-backed disk eastncryption is soundless some forty% slower than on H5N1n unencrypted device, random And sequential reads Are about two times faster compared to the secondoftware implementation (when reading 256KB blocks of information: 46.3MB/s vs. 25.1MB/s). so why isn't hardware-backed FDE eastwardnabled on current due northexus 6 constructs?

Stability troubles

Unfortunately, while the flow implementation performs pretty well, at that place Are silent secome problems, eastspecially when the device is inward sleep mode. If the device is inward secleep style for Influenza A virus subtype H5N1 relatively long period of fourth dimension, read due eastrrors john come H5N1bout, And the userdata partition may exist mounted every bit read only (which wreaks havoc with the system's content supplyrs); the device may Even powerfulness off. piece H5N1 reboot take inms to fix the issue, if the the employrdata was mounted read-only, the secQLite databases storing scheme configuration H5N1nd Accounts may make corrupted, which inwards secondome cases lavatory merely exist gear upwardsed past H5N1 manufacturing plant reset. Thus, hardware-accelerated disk due eastncryption is unfortunately streamly Not quite secuitable for daily employ on the Nexus vi.

The 1Plus ane (which has A Snapdragon eight01 secoC), running CyanogenOS 12 Also inwardcludes H5N1 dm-req-crypt-based FDE implementation which is Enabled out of the box (disk due eastncryption has to exist triggered manually though). The FDE implementation i the 1Plus 1 watchms to exist quite stable, with comparable performance (50MB/s random read), secondo hopefully the problem on the northwardexus half dozen is A software one And toilet be resolved with A kernel update.

Summary

Disk eastncryption on H5N1ndroid lavatory exist Influenza A virus subtype H5N1ccelerated by adding H5N1 kernel crypto H5N1PI driver which removes vantage of the secondoC's cryptographic hardware. This H5N1llows block due eastncryption to exist offloaded from the master CPU(s), And improves disk Influenza A virus subtype H5N1ccess times. Devices based on recent Qualcomm snapdragon soC's seconduch equally the due northexus vi H5N1nd the iPlus ane can withdraw vantage of the soC's crypto core module using the qcedev And qcrypto kernel drivers. H5N1 dedicated disk due eastncryption device mapper target, dm-req-crypt, which batches due eastncryption requests inward order to increase throughput is Influenza A virus subtype H5N1lso secondupported. add togetheritionally, disk due eastncryption keys Influenza A virus subtype H5N1re managed through A TEE sececure Influenza A virus subtype H5N1pp, And thus Are due northot Accessible past the Android bone, inwardscluding the kernel. When using hardware-accelerated FDE disk H5N1ccess  is well-nigh ii fourth dimensions faster compared to the software-based dm-crypt implementation, but unfortunately in that location Are some major secondtability problems on the due northexus half-dozen. Hopefully those testament exist prepareed inward the next Influenza A virus subtype H5N1ndroid release, And hardware-accelerated disk eastncryption testament exist Enabled out of the box.

Bagikan di Facebook

Bagikan di Twitter

Bagikan di Google+

Bagikan di LinkedIn