USECASES.md 9.73 KB
Newer Older
1 2 3 4
# Use Cases

## Intra-file Variable Security Regions (VSR)

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
5
[StrongBox UC flag: `uc_secure_regions` (deprecated)]
6

7 8 9 10
Communicating classified materials, grand jury testimony, corporate secrets,
etc. require the highest level of discretion when handled, yet sensitive
information like this often appears within a (much) larger amount of data that
we care less about in context.
11

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
12 13 14 15 16 17
In this scenario, a user wants to indicate one or more regions of a file are
more sensitive than the others. For example, perhaps banking transaction
information is littered throughout a document; perhaps passwords and other
sensitive or compromising information exists within a *much* larger data file.
This sensitive information would be encrypted using a less performant (sometimes
*dramatically* so) cipher in exchange for a stronger security guarantee.
18 19

The user will not experience a significant performance hit when perusing the
Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
20 21 22
data if the bulk of it is encrypted using a high performance cipher.
Simultaneously, the more sensitive data regions are future-proofed and more
resilient to attack using a high security cipher.
23

24
Terminology: a "VSR" is a region of a file that is crypted with the alternative
Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
25
rather than the primary cipher that encrypts the remaining majority of the file.
Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
26

27 28 29 30 31 32 33 34
Benefit: we can "future-proof" our encrypted highly sensitive data against more
powerful future attacks/less trustworthy ciphers while preserving the
performance win from using a faster less secure cipher.

### Issues

- Where to store the VSRs?

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
35 36 37 38 39 40 41 42 43
> The data can be stored in "reserved nuggets" which reduce the available space
on the drive by some amount proportional to the total number of VSRs in the
filesystem.

- What do VSRs have to do with our cipher switching strategies?

> Using a slightly modified version of the mirrored cipher switching strategy,
we can effectively "reserve" a portion of the backing store for the VSRs while
the remaining space is used for normal data encryption.
44

45 46 47
In StrongBox II, this is called the `swap_selective` or selective-immediate
cipher switching strategy.

48 49
- How to communicate intent down the stack?

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
50 51 52 53 54 55 56 57
> In an ideal implementation, the low level I/O API (i.e. `write()` in C) would
> be modified to include an extra security parameter so that VSR writes could be
> distinguished from normal writes to StrongBox. Reads would function as normal
> except when an attempt is made to read a VSR; in this case, the read would be
> transparently mapped to the appropriate location on disk where the VSR resides
> and the data decrypted using the appropriate cipher.
>
> Unfortunately, the BUSE subsystem on which StrongBox is based does not support
58
> custom low level I/O requests natively, making a literal implementation an
Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
59 60 61 62 63 64
> unattractive prospect. Hence, for our purposes, we use POSIX message queues
> (IPC) to communicate our security parameter down the stack. In fact, some form
> of the mirrored cipher strategy (but with special write rules rather than dumb
> mirroring) seems well suited to this purpose, where the primary cipher on
> partition 1 is fast and weak while the swap cipher (for the VSRs) on partition
> 2 is slow and strong.
65 66 67

### Tradeoffs

Xunnamius (Markov)'s avatar
Xunnamius (Markov) committed
68 69
- The amount of wasted space (if there is any) increases proportional to the
  number of VSR-enabled files
70

71 72 73 74
> This is because the variable security regions of various files are encrypted
> in the higher security reserved nugget area. The number of nuggets reserved in
> this way is currently 50% of total available nuggets via the selective swap
> strategy.
75

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
76 77
- Slower than exclusively using the weakest cipher to crypt a file's nuggets,
  but the VSR content is stored more securely.
78

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
79 80 81
- Weaker security guarantees than using the strongest cipher to crypt the
  majority of a file's contents, but there is less I/O latency when interacting
  with said file.
82 83 84

### Proto Threat Model

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
85 86 87
- Encrypted data at rest becomes more resilient to targeted attacks, especially
  if the user is concerned about the security properties of a particular cipher,
  or feel that certain potentially powerful adversaries (i.e. nation-state
88
  adversaries) might have means to compromise a reduced round cipher through
Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
89 90 91
  brute force, side channel, or etc. Freestyle, for instance, is more resilient
  to offline brute force attacks thanks to output randomization and the like but
  is much slower in practice than something like ChaCha20.
92 93 94

### Related Work

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
95 96 97 98
- Goodman et al. `An Energy/Security Scalable Encryption Processor Using an
  Embedded Variable Voltage DC/DC Converter`
- Batina et al. `Energy, performance, area versus security trade-offs for stream
  ciphers`
99 100 101

## Balancing Security Goals and the Current Energy Budget

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
102
[StrongBox UC flag: `uc_fixed_energy` (deprecated)]
103 104 105 106 107 108 109 110 111 112 113 114

When our mobile devices enter power saving mode, it is usually because the total
energy/power budget for the device has become constrained for one reason or
another.

When a device enters this mode, all software and components are configured by
the OS to use as little of the available energy as possible. The filesystem
should be made to behave in a manner that is energy-aware as well.

Our goal is to use as little energy as possible (while reasonably preserving
filesystem performance) until the energy budget changes or the device dies.

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
115 116 117 118 119 120 121
Benefit: When constantly streaming data, e.g. using DLNA to stream a high
resolution video wirelessly to a TV on the same network, the ability to adapt to
time-varying data rates and QoS requirements while maintaining confidentiality
and integrity guarantees is paramount. This can be done by trading off a set of
security guarantees with respect to the energy spent crypting each bit. With
cipher switching, the filesystem can react dynamically to the system's total
energy budget while still aiming for the most performant (least latency)
122 123 124 125 126
configuration.

### Issues

- Total benefit will depend on which swap strategy is used to implement this
Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
127
   - Candidate strategies are: forward and aggressive
128 129 130 131

- Total benefit is likely workload dependent
    - Read dominant vs write dominant
    - Which nuggets are hit the most during workload I/O
Xunnamius (Markov)'s avatar
Xunnamius (Markov) committed
132
        - Referred to below as **hot nuggets** and **hot flakes**
133 134 135

- Why not default to the highest/lowest security cipher?

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
136 137
> Because we are trying to optimize for high performance/low latency at the same
> time we are optimizing for low energy use. These are competing concerns.
138 139 140

- Are gains eaten by the switching process?

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
141 142 143 144 145
> ~~Depends on the cipher switching strategy used~~ It is workload dependent. We
> observe acceptable performance near baseline for workloads that end up with
> many hot nuggets, especially if they are read-heavy; for workloads that touch
> a nugget once or twice and then never again we observe a decided performance
> degradation.
Xunnamius (Markov)'s avatar
Xunnamius (Markov) committed
146

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
147
- How to communicate energy-efficiency intent down the stack?
148

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
149 150 151
> We have decided to use POSIX message queues (IPC) for this. See
> `uc_secure_regions` section above for more details on why we favor this over
> an implementation that explicitly modifies the low level I/O API.
152 153 154 155 156 157 158 159 160 161 162 163

### Tradeoffs

- We trade security of hot nuggets for reduced energy consumption when the
  device is in a power saving mode

- We trade energy efficiency of hot nuggets for greater security when the
  device is not in a power saving mode

### Proto Threat Model

- Confidentiality and integrity against active, passive, and offline/brute force
Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
164
  attacks against FDE with respect to energy consumption
165 166 167

### Related Work

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
168 169 170 171 172
- Potlapally et al. `Analyzing the Energy Consumption of Security Protocols`
- Goodman et al. `An Energy/Security Scalable Encryption Processor Using an
  Embedded Variable Voltage DC/DC Converter`
- Batina et al. `Energy, performance, area versus security trade-offs for stream
  ciphers`
173 174 175

## Lockdown: Securing Device Data Under Duress

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
176
[StrongBox UC flag: `uc_lockdown` (deprecated)]
177 178 179 180 181 182 183 184 185 186 187 188 189 190 191

Nation-state and other adversaries have truly extensive compute resources at
their disposal, as well as knowledge of side-channels and access to technology
like q-bit computers.

Suppose one were attempting to re-enter a country through a border checkpoint
after visiting family when one is stopped. Your mobile device is confiscated and
placed in custody of the State. In such a scenario, it would be useful if the
device could swap itself into a more secure state *as quickly as possible*.

Benefit: greater security guarantee achieved using the highest security
encryption available versus powerful adversaries with unknown means and motive.

### Issues

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
192 193
- How do we delete the less secure region of the disk both quickly and
  effectively? TRIM?
194 195 196 197 198 199 200 201 202 203 204

### Tradeoffs

- (TODO)

### Proto Threat Model

- (TODO: expand this more)

### Related Work

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
205
- (TODO: is there any?)
206

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
207
## Detecting and Responding to End-of-Life Slowdown in Solid State Drives
208

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
209
[StrongBox UC flag: `uc_offset_slowdown` (deprecated)]
210

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
211 212 213
Due to garbage collection and the append-mostly nature of SSDs and other NAND
devices, as free space becomes constrained, performance drops off a cliff. This
is a well-studied issue (see related work).
214

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
215 216 217 218 219 220 221 222
If the filesystem is made aware when the backing store is in such a state, we
can offset some of the (drastic) performance loss by swapping the ciphers of hot
nuggets to the fastest cipher available until the disk space problem is
remedied, after which the system can detect return the swapped nuggets to their
former encrypted state.

Benefit: we can mitigate the performance loss of a slowing SSD by using a faster
but less secure cipher.
223 224 225

### Issues

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
226 227 228
- How to communicate down the stack that EOL slowdown was detected?

> We have decided to use POSIX message queues (IPC) for this.
229 230 231 232 233 234 235

### Tradeoffs

- (TODO)

### Proto Threat Model

Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
236
- (TODO: expand this more)
237 238

### Related Work
Xunnamius (Morty)'s avatar
Xunnamius (Morty) committed
239 240 241 242
- (?) Lots of consumer reports/studies on this to cite
- (?) Limplock
- (?) Tiny-tail flash: Near-perfect elimination of garbage collection tail latencies in NAND SSDs
- (TODO: perhaps add a lot of Har's work here)