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