^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) .. UBIFS Authentication
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) .. sigma star gmbh
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) .. 2018
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) UBIFS Authentication Support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) UBIFS utilizes the fscrypt framework to provide confidentiality for file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) contents and file names. This prevents attacks where an attacker is able to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) read contents of the filesystem on a single point in time. A classic example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) is a lost smartphone where the attacker is unable to read personal data stored
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) on the device without the filesystem decryption key.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) At the current state, UBIFS encryption however does not prevent attacks where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) the attacker is able to modify the filesystem contents and the user uses the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) device afterwards. In such a scenario an attacker can modify filesystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) contents arbitrarily without the user noticing. One example is to modify a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) binary to perform a malicious action when executed [DMC-CBC-ATTACK]. Since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) most of the filesystem metadata of UBIFS is stored in plain, this makes it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) fairly easy to swap files and replace their contents.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) Other full disk encryption systems like dm-crypt cover all filesystem metadata,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) which makes such kinds of attacks more complicated, but not impossible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) Especially, if the attacker is given access to the device multiple points in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) time. For dm-crypt and other filesystems that build upon the Linux block IO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) layer, the dm-integrity or dm-verity subsystems [DM-INTEGRITY, DM-VERITY]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) can be used to get full data authentication at the block layer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) These can also be combined with dm-crypt [CRYPTSETUP2].
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) This document describes an approach to get file contents _and_ full metadata
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) authentication for UBIFS. Since UBIFS uses fscrypt for file contents and file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) name encryption, the authentication system could be tied into fscrypt such that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) existing features like key derivation can be utilized. It should however also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) be possible to use UBIFS authentication without using encryption.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) MTD, UBI & UBIFS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) ----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) On Linux, the MTD (Memory Technology Devices) subsystem provides a uniform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) interface to access raw flash devices. One of the more prominent subsystems that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) work on top of MTD is UBI (Unsorted Block Images). It provides volume management
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) for flash devices and is thus somewhat similar to LVM for block devices. In
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) addition, it deals with flash-specific wear-leveling and transparent I/O error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) handling. UBI offers logical erase blocks (LEBs) to the layers on top of it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) and maps them transparently to physical erase blocks (PEBs) on the flash.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) UBIFS is a filesystem for raw flash which operates on top of UBI. Thus, wear
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) leveling and some flash specifics are left to UBI, while UBIFS focuses on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) scalability, performance and recoverability.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) +------------+ +*******+ +-----------+ +-----+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) | | * UBIFS * | UBI-BLOCK | | ... |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) | JFFS/JFFS2 | +*******+ +-----------+ +-----+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) | | +-----------------------------+ +-----------+ +-----+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) | | | UBI | | MTD-BLOCK | | ... |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) +------------+ +-----------------------------+ +-----------+ +-----+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) +------------------------------------------------------------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) | MEMORY TECHNOLOGY DEVICES (MTD) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) +------------------------------------------------------------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) +-----------------------------+ +--------------------------+ +-----+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) | NAND DRIVERS | | NOR DRIVERS | | ... |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) +-----------------------------+ +--------------------------+ +-----+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) Figure 1: Linux kernel subsystems for dealing with raw flash
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) Internally, UBIFS maintains multiple data structures which are persisted on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) the flash:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) - *Index*: an on-flash B+ tree where the leaf nodes contain filesystem data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) - *Journal*: an additional data structure to collect FS changes before updating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) the on-flash index and reduce flash wear.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) - *Tree Node Cache (TNC)*: an in-memory B+ tree that reflects the current FS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) state to avoid frequent flash reads. It is basically the in-memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) representation of the index, but contains additional attributes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) - *LEB property tree (LPT)*: an on-flash B+ tree for free space accounting per
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) UBI LEB.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) In the remainder of this section we will cover the on-flash UBIFS data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) structures in more detail. The TNC is of less importance here since it is never
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) persisted onto the flash directly. More details on UBIFS can also be found in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) [UBIFS-WP].
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) UBIFS Index & Tree Node Cache
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) Basic on-flash UBIFS entities are called *nodes*. UBIFS knows different types
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) of nodes. Eg. data nodes (``struct ubifs_data_node``) which store chunks of file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) contents or inode nodes (``struct ubifs_ino_node``) which represent VFS inodes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) Almost all types of nodes share a common header (``ubifs_ch``) containing basic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) information like node type, node length, a sequence number, etc. (see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) ``fs/ubifs/ubifs-media.h`` in kernel source). Exceptions are entries of the LPT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) and some less important node types like padding nodes which are used to pad
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) unusable content at the end of LEBs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) To avoid re-writing the whole B+ tree on every single change, it is implemented
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) as *wandering tree*, where only the changed nodes are re-written and previous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) versions of them are obsoleted without erasing them right away. As a result,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) the index is not stored in a single place on the flash, but *wanders* around
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) and there are obsolete parts on the flash as long as the LEB containing them is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) not reused by UBIFS. To find the most recent version of the index, UBIFS stores
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) a special node called *master node* into UBI LEB 1 which always points to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) most recent root node of the UBIFS index. For recoverability, the master node
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) is additionally duplicated to LEB 2. Mounting UBIFS is thus a simple read of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) LEB 1 and 2 to get the current master node and from there get the location of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) the most recent on-flash index.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) The TNC is the in-memory representation of the on-flash index. It contains some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) additional runtime attributes per node which are not persisted. One of these is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) a dirty-flag which marks nodes that have to be persisted the next time the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) index is written onto the flash. The TNC acts as a write-back cache and all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) modifications of the on-flash index are done through the TNC. Like other caches,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) the TNC does not have to mirror the full index into memory, but reads parts of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) it from flash whenever needed. A *commit* is the UBIFS operation of updating the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) on-flash filesystem structures like the index. On every commit, the TNC nodes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) marked as dirty are written to the flash to update the persisted index.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) Journal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) ~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) To avoid wearing out the flash, the index is only persisted (*commited*) when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) certain conditions are met (eg. ``fsync(2)``). The journal is used to record
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) any changes (in form of inode nodes, data nodes etc.) between commits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) of the index. During mount, the journal is read from the flash and replayed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) onto the TNC (which will be created on-demand from the on-flash index).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) UBIFS reserves a bunch of LEBs just for the journal called *log area*. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) amount of log area LEBs is configured on filesystem creation (using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) ``mkfs.ubifs``) and stored in the superblock node. The log area contains only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) two types of nodes: *reference nodes* and *commit start nodes*. A commit start
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) node is written whenever an index commit is performed. Reference nodes are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) written on every journal update. Each reference node points to the position of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) other nodes (inode nodes, data nodes etc.) on the flash that are part of this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) journal entry. These nodes are called *buds* and describe the actual filesystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) changes including their data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) The log area is maintained as a ring. Whenever the journal is almost full,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) a commit is initiated. This also writes a commit start node so that during
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) mount, UBIFS will seek for the most recent commit start node and just replay
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) every reference node after that. Every reference node before the commit start
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) node will be ignored as they are already part of the on-flash index.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) When writing a journal entry, UBIFS first ensures that enough space is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) available to write the reference node and buds part of this entry. Then, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) reference node is written and afterwards the buds describing the file changes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) On replay, UBIFS will record every reference node and inspect the location of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) the referenced LEBs to discover the buds. If these are corrupt or missing,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) UBIFS will attempt to recover them by re-reading the LEB. This is however only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) done for the last referenced LEB of the journal. Only this can become corrupt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) because of a power cut. If the recovery fails, UBIFS will not mount. An error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) for every other LEB will directly cause UBIFS to fail the mount operation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) | ---- LOG AREA ---- | ---------- MAIN AREA ------------ |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) -----+------+-----+--------+---- ------+-----+-----+---------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) \ | | | | / / | | | \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) / CS | REF | REF | | \ \ DENT | INO | INO | /
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) \ | | | | / / | | | \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) ----+------+-----+--------+--- -------+-----+-----+----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) | | ^ ^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) | | | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) +------------------------+ |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) +-------------------------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) Figure 2: UBIFS flash layout of log area with commit start nodes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) (CS) and reference nodes (REF) pointing to main area
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) containing their buds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) LEB Property Tree/Table
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) ~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) The LEB property tree is used to store per-LEB information. This includes the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) LEB type and amount of free and *dirty* (old, obsolete content) space [1]_ on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) the LEB. The type is important, because UBIFS never mixes index nodes with data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) nodes on a single LEB and thus each LEB has a specific purpose. This again is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) useful for free space calculations. See [UBIFS-WP] for more details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) The LEB property tree again is a B+ tree, but it is much smaller than the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) index. Due to its smaller size it is always written as one chunk on every
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) commit. Thus, saving the LPT is an atomic operation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) .. [1] Since LEBs can only be appended and never overwritten, there is a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) difference between free space ie. the remaining space left on the LEB to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) written to without erasing it and previously written content that is obsolete
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) but can't be overwritten without erasing the full LEB.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) UBIFS Authentication
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) This chapter introduces UBIFS authentication which enables UBIFS to verify
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) the authenticity and integrity of metadata and file contents stored on flash.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) Threat Model
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) ------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) UBIFS authentication enables detection of offline data modification. While it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) does not prevent it, it enables (trusted) code to check the integrity and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) authenticity of on-flash file contents and filesystem metadata. This covers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) attacks where file contents are swapped.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) UBIFS authentication will not protect against rollback of full flash contents.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) Ie. an attacker can still dump the flash and restore it at a later time without
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) detection. It will also not protect against partial rollback of individual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) index commits. That means that an attacker is able to partially undo changes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) This is possible because UBIFS does not immediately overwrites obsolete
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) versions of the index tree or the journal, but instead marks them as obsolete
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) and garbage collection erases them at a later time. An attacker can use this by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) erasing parts of the current tree and restoring old versions that are still on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) the flash and have not yet been erased. This is possible, because every commit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) will always write a new version of the index root node and the master node
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) without overwriting the previous version. This is further helped by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) wear-leveling operations of UBI which copies contents from one physical
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) eraseblock to another and does not atomically erase the first eraseblock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) UBIFS authentication does not cover attacks where an attacker is able to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) execute code on the device after the authentication key was provided.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) Additional measures like secure boot and trusted boot have to be taken to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) ensure that only trusted code is executed on a device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) Authentication
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) --------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) To be able to fully trust data read from flash, all UBIFS data structures
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) stored on flash are authenticated. That is:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) - The index which includes file contents, file metadata like extended
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) attributes, file length etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) - The journal which also contains file contents and metadata by recording changes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) to the filesystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) - The LPT which stores UBI LEB metadata which UBIFS uses for free space accounting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) Index Authentication
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) ~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) Through UBIFS' concept of a wandering tree, it already takes care of only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) updating and persisting changed parts from leaf node up to the root node
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) of the full B+ tree. This enables us to augment the index nodes of the tree
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) with a hash over each node's child nodes. As a result, the index basically also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) a Merkle tree. Since the leaf nodes of the index contain the actual filesystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) data, the hashes of their parent index nodes thus cover all the file contents
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) and file metadata. When a file changes, the UBIFS index is updated accordingly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) from the leaf nodes up to the root node including the master node. This process
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) can be hooked to recompute the hash only for each changed node at the same time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) Whenever a file is read, UBIFS can verify the hashes from each leaf node up to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) the root node to ensure the node's integrity.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) To ensure the authenticity of the whole index, the UBIFS master node stores a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) keyed hash (HMAC) over its own contents and a hash of the root node of the index
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) tree. As mentioned above, the master node is always written to the flash whenever
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) the index is persisted (ie. on index commit).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) Using this approach only UBIFS index nodes and the master node are changed to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) include a hash. All other types of nodes will remain unchanged. This reduces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) the storage overhead which is precious for users of UBIFS (ie. embedded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) devices).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) +---------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) | Master Node |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) | (hash) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) +---------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) +-------------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) | Index Node #1 |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) | branch0 branchn |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) | (hash) (hash) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) +-------------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) | ... | (fanout: 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) +-------+ +------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) v v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) +-------------------+ +-------------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) | Index Node #2 | | Index Node #3 |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) | | | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) | branch0 branchn | | branch0 branchn |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) | (hash) (hash) | | (hash) (hash) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) +-------------------+ +-------------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) | ... | ... |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) v v v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) +-----------+ +----------+ +-----------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) | Data Node | | INO Node | | DENT Node |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) +-----------+ +----------+ +-----------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) Figure 3: Coverage areas of index node hash and master node HMAC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) The most important part for robustness and power-cut safety is to atomically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) persist the hash and file contents. Here the existing UBIFS logic for how
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) changed nodes are persisted is already designed for this purpose such that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) UBIFS can safely recover if a power-cut occurs while persisting. Adding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) hashes to index nodes does not change this since each hash will be persisted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) atomically together with its respective node.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) Journal Authentication
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) ~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) The journal is authenticated too. Since the journal is continuously written
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) it is necessary to also add authentication information frequently to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) journal so that in case of a powercut not too much data can't be authenticated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) This is done by creating a continuous hash beginning from the commit start node
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) over the previous reference nodes, the current reference node, and the bud
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) nodes. From time to time whenever it is suitable authentication nodes are added
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) between the bud nodes. This new node type contains a HMAC over the current state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) of the hash chain. That way a journal can be authenticated up to the last
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) authentication node. The tail of the journal which may not have a authentication
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) node cannot be authenticated and is skipped during journal replay.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) We get this picture for journal authentication::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) ,,,,,,,,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) ,......,...........................................
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) ,. CS , hash1.----. hash2.----.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) ,. | , . |hmac . |hmac
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) ,. v , . v . v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) ,.REF#0,-> bud -> bud -> bud.-> auth -> bud -> bud.-> auth ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) ,..|...,...........................................
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) , | ,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) , | ,,,,,,,,,,,,,,,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) . | hash3,----.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) , | , |hmac
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) , v , v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) , REF#1 -> bud -> bud,-> auth ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) ,,,|,,,,,,,,,,,,,,,,,,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) REF#2 -> ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) V
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) Since the hash also includes the reference nodes an attacker cannot reorder or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) skip any journal heads for replay. An attacker can only remove bud nodes or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) reference nodes from the end of the journal, effectively rewinding the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) filesystem at maximum back to the last commit.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) The location of the log area is stored in the master node. Since the master
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) node is authenticated with a HMAC as described above, it is not possible to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) tamper with that without detection. The size of the log area is specified when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) the filesystem is created using `mkfs.ubifs` and stored in the superblock node.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) To avoid tampering with this and other values stored there, a HMAC is added to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) the superblock struct. The superblock node is stored in LEB 0 and is only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) modified on feature flag or similar changes, but never on file changes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) LPT Authentication
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) ~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) The location of the LPT root node on the flash is stored in the UBIFS master
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) node. Since the LPT is written and read atomically on every commit, there is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) no need to authenticate individual nodes of the tree. It suffices to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) protect the integrity of the full LPT by a simple hash stored in the master
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) node. Since the master node itself is authenticated, the LPTs authenticity can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) be verified by verifying the authenticity of the master node and comparing the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) LTP hash stored there with the hash computed from the read on-flash LPT.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) Key Management
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) --------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) For simplicity, UBIFS authentication uses a single key to compute the HMACs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) of superblock, master, commit start and reference nodes. This key has to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) available on creation of the filesystem (`mkfs.ubifs`) to authenticate the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) superblock node. Further, it has to be available on mount of the filesystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) to verify authenticated nodes and generate new HMACs for changes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) UBIFS authentication is intended to operate side-by-side with UBIFS encryption
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) (fscrypt) to provide confidentiality and authenticity. Since UBIFS encryption
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) has a different approach of encryption policies per directory, there can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) multiple fscrypt master keys and there might be folders without encryption.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) UBIFS authentication on the other hand has an all-or-nothing approach in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) sense that it either authenticates everything of the filesystem or nothing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) Because of this and because UBIFS authentication should also be usable without
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) encryption, it does not share the same master key with fscrypt, but manages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) a dedicated authentication key.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) The API for providing the authentication key has yet to be defined, but the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) key can eg. be provided by userspace through a keyring similar to the way it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) is currently done in fscrypt. It should however be noted that the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) fscrypt approach has shown its flaws and the userspace API will eventually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) change [FSCRYPT-POLICY2].
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) Nevertheless, it will be possible for a user to provide a single passphrase
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) or key in userspace that covers UBIFS authentication and encryption. This can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) be solved by the corresponding userspace tools which derive a second key for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) authentication in addition to the derived fscrypt master key used for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) encryption.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) To be able to check if the proper key is available on mount, the UBIFS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) superblock node will additionally store a hash of the authentication key. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) approach is similar to the approach proposed for fscrypt encryption policy v2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) [FSCRYPT-POLICY2].
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) Future Extensions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) In certain cases where a vendor wants to provide an authenticated filesystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) image to customers, it should be possible to do so without sharing the secret
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) UBIFS authentication key. Instead, in addition the each HMAC a digital
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) signature could be stored where the vendor shares the public key alongside the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) filesystem image. In case this filesystem has to be modified afterwards,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) UBIFS can exchange all digital signatures with HMACs on first mount similar
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) to the way the IMA/EVM subsystem deals with such situations. The HMAC key
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432) will then have to be provided beforehand in the normal way.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) References
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) [CRYPTSETUP2] https://www.saout.de/pipermail/dm-crypt/2017-November/005745.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) [DMC-CBC-ATTACK] https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) [DM-INTEGRITY] https://www.kernel.org/doc/Documentation/device-mapper/dm-integrity.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) [DM-VERITY] https://www.kernel.org/doc/Documentation/device-mapper/verity.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) [FSCRYPT-POLICY2] https://www.spinics.net/lists/linux-ext4/msg58710.html
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) [UBIFS-WP] http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags