Horus: Fine-Grained Encryption- Based Security for High Performance - - PowerPoint PPT Presentation

▶
horus fine grained encryption based security for high
SMART_READER_LITE
LIVE PREVIEW

Horus: Fine-Grained Encryption- Based Security for High Performance - - PowerPoint PPT Presentation

Jun 28, 2023 355 likes •533 views

Horus: Fine-Grained Encryption- Based Security for High Performance Petascale Storage Ranjana Rajendran Ethan L. Miller Darrell D. E. Long Storage Systems Research Center University of California, Santa Cruz Sunday, November 13, 11

slide-1
SLIDE 1

Ranjana Rajendran • Ethan L. Miller • Darrell D. E. Long Storage Systems Research Center University of California, Santa Cruz

Horus: Fine-Grained Encryption- Based Security for High Performance Petascale Storage

Sunday, November 13, 11

slide-2
SLIDE 2

What’s the problem?

  • Ever-increasing volume of data
  • More files
  • Larger files
  • Ever-increasing threat
  • Intrusions
  • Insider attacks
  • Accidental data leakage
  • HPC systems have a lot of vulnerabilities
  • Storage nodes
  • Metadata servers
  • Thousands of clients
  • Goal: limit the risk of data leakage in an HPC system
  • Goal: allow protection of some parts of a file

2

Sunday, November 13, 11

slide-3
SLIDE 3

Typical HPC storage environment

  • Clients interact with MDS

to open files

  • Clients interact directly

with storage to read/write data

  • Maat [SC07] can provide

authorization

  • No encryption...

3

MDS 1: open() 2: capability 3: I/O request 4: I/O response Policy control MDS Disk Disk Disk Disk Disk Disk Disk Disk Disk Disk Client Client Client Client Client Client

Sunday, November 13, 11

slide-4
SLIDE 4

Threat model: leakage of confidential HPC data

  • Traditional encryption: one key per file
  • Data can be encrypted at the client
  • Still vulnerable to leaks
  • Compromised storage devices / nodes
  • Little risk if data is encrypted
  • High risk if done with other compromises
  • Compromised metadata servers
  • Potential for leaking keys
  • Difficult to secure given complexity
  • Compromised client (compute) nodes
  • Keys from a single client can leak the whole file!
  • There are thousands of clients...

4

Sunday, November 13, 11

slide-5
SLIDE 5

Keyed hash trees

  • Solution: use keyed hash trees to generate block keys from the file

key

  • Clients only get the block keys they need
  • Clients can’t encrypt / decrypt data for which they don’t have keys
  • Nodes at any level of the tree can be given out
  • Value of a key depends on parent and key’s position
  • Simple to derive block key from any key above it

5

KR (file root key) K1,0 K1,1 K2,0 K2,1 K2,2 K2,3 K2,4 K2,5

K3,0 K3,1 K3,2 K3,3 K3,4 K3,5 K3,6 K3,7 K3,8 K3,9 K3,10 K3,11

K1,2 K2,6 K2,7 K2,8 K2,9

K3,12 K3,13 K3,14 K3,15 K3,16 K3,17 K3,18 K3,19

Sunday, November 13, 11

slide-6
SLIDE 6

Keyed hash trees

  • Solution: use keyed hash trees to generate block keys from the file

key

  • Clients only get the block keys they need
  • Clients can’t encrypt / decrypt data for which they don’t have keys
  • Nodes at any level of the tree can be given out
  • Value of a key depends on parent and key’s position
  • Simple to derive block key from any key above it

5

KR (file root key) K1,0 K1,1 K2,0 K2,1 K2,2 K2,3 K2,4 K2,5

K3,0 K3,1 K3,2 K3,3 K3,4 K3,5 K3,6 K3,7 K3,8 K3,9 K3,10 K3,11

K1,2 K2,6 K2,7 K2,8 K2,9

K3,12 K3,13 K3,14 K3,15 K3,16 K3,17 K3,18 K3,19

Block keys

Sunday, November 13, 11

slide-7
SLIDE 7

Keyed hash trees

  • Solution: use keyed hash trees to generate block keys from the file

key

  • Clients only get the block keys they need
  • Clients can’t encrypt / decrypt data for which they don’t have keys
  • Nodes at any level of the tree can be given out
  • Value of a key depends on parent and key’s position
  • Simple to derive block key from any key above it

5

KR (file root key) K1,0 K1,1 K2,0 K2,1 K2,2 K2,3 K2,4 K2,5

K3,0 K3,1 K3,2 K3,3 K3,4 K3,5 K3,6 K3,7 K3,8 K3,9 K3,10 K3,11

K1,2 K2,6 K2,7 K2,8 K2,9

K3,12 K3,13 K3,14 K3,15 K3,16 K3,17 K3,18 K3,19

Range keys

Sunday, November 13, 11

slide-8
SLIDE 8

Generating block keys

  • Start at root key
  • At each level, generate

new key from

  • Parent key
  • Level number
  • “Offset” in the level
  • Process can be split
  • Simple to go down the tree
  • “Difficult” to go up the tree

(or sideways)

6

for x = start + 1 to end do k ← keyed_hash(k, x || ⎣b/Bx⎦) end for return k

KR (file root key)

K1,0 K2,0 K2,1 K2,2 K2,3

K3,0 K3,1 K3,2 K3,3 K3,4 K3,5 K3,6 K3,7 K3,8

K2,4 K1,1

Sunday, November 13, 11

slide-9
SLIDE 9

Handing out range keys

  • Provide only needed range keys to each client
  • Ranges cover any number of blocks
  • Ranges must be aligned to key
  • Hand out multiple range keys to a client if needed
  • Range key usage is flexible
  • Multiple clients can get key for a single block
  • Any range key that “covers” a block can be used to generate its

key

7

C D A B

KR

Root key Range keys File blocks Clients

Sunday, November 13, 11

slide-10
SLIDE 10

Using Horus

  • Key Distribution Cluster

can run

  • Separately
  • Stateless: easier to reset between

computations

  • On MDS
  • On nodes doling out work

units for computation

  • Keys stored using public-

key encryption

  • Client forwards key to KDC
  • KDC could request key from

MDS directly

8

MDS

1: open() 2: Protected KR 7 : I / O r e q u e s t 8 : I / O r e s p

  • n

s e

MDS Disk Disk Disk Disk Disk Disk Disk Disk Disk Disk Client Client Client Client Client Client Key Distribution Cluster

3: Protected KR 5: Range key(s) 9: Decrypt data 4: Calculate permitted range key(s) 6: Calculate block key

Sunday, November 13, 11

slide-11
SLIDE 11

Storing file root keys

  • Encrypt file root keys with users’ public keys
  • Lockbox structure similar to those used in many secure

file systems

  • Store file root keys in the file system
  • In a separate file
  • In extended attributes attached to the file
  • Alternative approach: supply file keys as part of

the setup for the computation

  • More secure?
  • May require additional infrastructure

9

Sunday, November 13, 11

slide-12
SLIDE 12

Using Horus as an encryption layer

  • In-kernel implementation
  • May be a bit faster
  • Requires OS changes
  • User-level implementation
  • No OS changes
  • Could leverage data layout

knowledge

  • Divide file by content rather than by

block offset

10

OS kernel OS kernel HDF/ NetCDF Horus System calls File system HDF/ NetCDF Horus System calls File system

In-kernel User-level

Sunday, November 13, 11

slide-13
SLIDE 13

Horus security

  • Data is only in the clear on clients
  • Storage nodes can’t leak data
  • MDS can’t leak data (or keys)
  • Only a client can leak data
  • Client can only leak data for which it has a key
  • Requires large-scale client compromise to leak the

entire file

  • Can’t leak “idle” files without obtaining user’s

private key

  • Revocation is an issue (as with other encrypted file

systems)

11

Sunday, November 13, 11

slide-14
SLIDE 14

Ongoing work

  • User-level implementation of Horus
  • Layered just above system calls
  • Uses extended attributes for key storage
  • Includes protocol to communicate with KDC
  • Explore tradeoffs between deeper tree and wider

range keys

  • Eventually, integrate into HPC file system such as

Ceph or PVFS

12

Sunday, November 13, 11

slide-15
SLIDE 15

Conclusions

  • Security is becoming increasingly important for

HPC

  • Leaving data in the clear may no longer be acceptable
  • Horus prevents many attacks
  • Compromise of disks or MDS
  • Small-scale compromise of compute nodes & clients
  • Horus allows sharing differential security for

portions of large files

  • Horus can run in the kernel or at user level

➡Provide greater confidentiality for HPC data

13

Sunday, November 13, 11

slide-16
SLIDE 16

14

Supported by

Questions?

Sunday, November 13, 11