GnatDB: A SMALLFOOTPRINT, SECURE DATABASE SYSTEM

1
GnatDB A SMALL-FOOTPRINT, SECURE DATABASE SYSTEM

• Author Radek Vingralek

2
Outline

• Introduction
• Related Work
• Architecture
• Store Implementation
• Secure Device Implementation
• Experimental Evaluation
• Lessons Learned

3
1. Introduction

• Gnat
• Any of various small, biting, two-winged flies,
  such as a punkie or black fly.

4
1. Introduction

• GnatDb design goals
• High security
• Low resource consumption
• Small-footprint
• Acceptable performance

5
1. Introduction

• High security
• Maintains data integrity against system crash
• Protects data against malicious corruption
  (temper-detection) and unauthorized reading
  (secrecy)

6
1. Introduction

• Examples of tempering
• Cracking phone-smartcard
• Cracking TV set-top box
• Sample application
• DRM system

7
1. Introduction

• Low resource consumption
• RAM is limited on some devices (single-chip
  device)
• RAM is used for other purpose (stream buffering)

8
1. Introduction

• Small-Footprint
• Supports only atomic and durable updates
• No concurrency control
• Log-structured storage model
• Code footprint stack heap lt 11KB memory

9
2. Related Work

• TDB
• Suitable for PCs or similar devices (code
  footprint 142KB 108KB)
• Integrate Merkle tree for data protection
• GnatDb
• Suitable for appliances with very limited
  resources (code footprint lt 10KB)
• Not using Merkle tree

10
2. Related Work

• File system security
• Read-only File System (SFSRO) - Fu, Kasshoek and
  Mazieres
• Protected File System (PFS) - Stein, Goward and
  Seltzer
• Transparent Cryptographic File System (TCFS) -
  Cattaneo et. Al.
• Secure Data Repository (SUNDR) - Mazieres and
  Shasha

11
2. Related Work

• File system security
• Focus on ease of integration of secrecy and
  temper-detection to a file system
• Not optimized for low memory consumption
• Not supporting atomic and durable updates

12
2. Related Work

• Other DMBS security
• Protecting data structure stored in memory using
  a Merkle tree Blum et. al.
• Protecting logs by hashing Schneier and Kelley
• etc

13
2. Related Work

• PicoDBMS
• Not providing secrecy and tamper-detection
• Implements query processing
• Storage model suitable for memories that can
  perform word-based write (EEPROM) but not
  block-based write (Flash, HD)

14
3. Architecture

• Hardware requirement

15
3. Architecture

• Assumptions
• Attacker cannot access the GnatDb executable in
  the ROM
• Attacker cannot access state written by GnatDb to
  the RAM
• Attacker cannot read a secret value stored in the
  ROM.
• etc

16
3. Architecture

• Assumptions in summary
• Attacker cannot attack the security perimeter
• Attacker can attack stable storage

17
3. Architecture

• Three logic layers (from bottom to top)
• Device layer
• A thin interface on top of the raw hardware
• Secure Device layer
• Guarantees secrecy, tamper-detecting
• Store layer
• Supports atomic and durable updates of sets of
  records

18
3. Architecture

• Device layer
• Consists of read, write, erase and flush
  operations
• Read/write fixed length pages
• One or more pages form a block ,which is an unit
  for erase operation

19
3. Architecture

• Secure Device layer
• Secrecy
• Pages written by Secure Device can be read only
  by calling the read operation of Secure Device.
• Tamper-detection
• The read operation of Secure Device raises an
  exception if the value of the page being read is
  different from the value most recently written by
  the write or erase operation of Secure Device.

20
3. Architecture

• Benefits of the Secure Device layer
• Top layer does not have to consider security
• Ease of verifying security
• Secure Device layer can be removed transparently

21
3. Architecture

• Store layer
• Implements atomic and durable updates of sets of
  records
• Records can be allocated, read, written and
  de-allocated.
• Records are persistently identified by record
  ids.
• The commit operation atomically and durably
  writes a sequence of records

22
3. Architecture

• Store layer
• RecordId allocate()
• Allocates a new record id. The record id is
  reserved until the next commit.
• Buffer read (RecordId)
• Returns the content of a record.
• Void commit (ltRecordId, Buffergt)
• Atomically and durably writes a sequence of
  record ids and buffers. Records are de-allocated
  by committing their record ids with an empty
  buffer.

23
4. Store Implementation
24
4. Store Implementation

• Benefits of log-structured storage organization
• Records are not overwritten, implementing atomic
  updates is straightforward
• Writes are compacted to a minimal number of
  blocks at the tail of the log
• Round-robin log allows integrity check to be done
  in constant time without the need of building a
  Merkle tree
• Erase operations are distributed uniformly across
  all blocks

25
4. Store Implementation

• Benefits of log-structured storage organization
• Records are not updated in place, traffic
  analysis of the accesses to stable storage is
  harder
• Records are never overwritten, its straight
  forward to support variable-sized records
• Does not have to interpret two representations of
  a record

26
4. Store Implementation

• Record ID allocation
• allocates a new record id by scanning the index
  array for the first de-allocated record id or by
  extending the index array (if there are no
  de-allocated records).
• Record Read
• Determines the id of the page containing the
  record from index array, then locate the record
  version using the page index.

27
4. Store Implementation

• Commit
• Accumulates the written records in a write page
  buffer and write to the data segment log tail
  with the buffer is filled up. Also write a new
  index copy at the tail of the index segment log.
• Cleaning
• Clean Ahead All live record versions in a block
  must be written to the stable storage before the
  block is erased.

28
4. Store Implementation

• Recovery
• Scans the index segment and finds the index copy
  with the highest version number.

29
5. Secure Device Implementation

• Possible attacks
• Snooping
• Reading the contents of a page directly from the
  raw hardware (secrecy violation)
• Spoofing
• Replacing a page with generated data
  (tamper-detection violation)
• Splicing
• Replacing a page with a duplicate of another
  valid page (tamper-detection violation)
• Replay
• Replacing a page with an older version of the
  same page (tamper-detection violation)

30
5. Secure Device Implementation

• Counter measures
• Secure Device layer prevents Snooping, Spoofing
  and Splicing by encrypting all pages and include
  a Message Authentication Code (MAC) for each
  page.
• Secure Device layer prevents the reply attack by
  including version number in each page.

31
5. Secure Device Implementation

• Expected version number (where c is the current
  value of the counter)

32
6. Experimental Evaluation

• Hardware setup
• Cirrus Logic evaluation board EP7209
• ARM7 microprocessor, a MMU and 8KB on-chip cache
• SmartMedia NAND flash card (erase in 8 KB blocks,
  read/write in 512 byte pages)
• NOR flash (erase in 16KB blocks, read/write in 4
  bytes with 512 byte pages emulation)

33
6. Experimental Evaluation

• Test data
• DRM database
• n counters 20 byte static description and a 4
  byte value
• Serial execution of 1000 transactions, each
  transaction selects a random number of counters
  between 1 to 5 reads the value of the
  counter(s), increments the value by 1, and then
  commits.

34
6. Experimental Evaluation

• Memory consumption

35
6. Experimental Evaluation
36
6. Experimental Evaluation
37
6. Experimental Evaluation
38
6. Experimental Evaluation
39
7. Lessons Learned

• GnatDb (optimized for memory consumption) was
  designed by revising TDB (optimized for
  performance).
• GnatDBs location map (as an array) has size
  1.8KB only whereas TDBs location map (as a
  hierarchy) has size 142KB.
• GnatDb cleaner cleans segments in round-robin
  manner (700 Bytes) while TDBs cleaner clean
  segments based on statistics (46KB).
• GnatDB was implemented in C and TDB was
  implemented in C.

40
Thank you