News | Project Presentation | Architecture | Data Structures | Security | References | Project Page

SecCube presentation

• Project motivations
• What is a SecCube ?
• SecCube Requirements

Background - Project Motivations

From an end-user point of view, PGP (Pretty Good Privacy) and its open source counterpart, GnuPG (Gnu Privacy Guard) are among the most famous applications of cryptology. They offer encryption, signing and key management services to end-users. These applications are however completely file oriented. Each GnuPG command typically involves an input file (or an input stream) that it secures accordingly to the command. Hence, GnuPG is convenient to secure individual isolated files, but far less convenient for entire directories, partitions or file systems.

To cope with such tasks, several other projects have emerged, commercial products (PGP Disk, SBox Disk, BestCrypt...) or open source projects (TrueCrypt, EncFS, dm-crypt ...). Unfortunately, none of these are really suited for an embedded environment (e.g. storing data on a Flash device), and they seldom support different operating systems and file systems. This strong dependency to a given architecture frequently results in data, being "trapped" in a given configuration, unable to access from another system. Typically, users with an encrypted mail partition have no easy means to carry their mail around on a PDA or a laptop with a different OS, because partitions won't mount, data formats are different etc.

Presentation of SecCubes

The solution proposed by the SecCube project is the following: a SecCube is an opaque secure archival box, where users store, retrieve and list sensitive records (a record is a data blob, for example, it may be a file, a part of a file, a part of a stream - see architecture).

A SecCube is meant to be a lightweight archival box, to be run with only few resources. It typically targets embedded systems, PDAs, USB keys. On the other hand, this means it is not designed for holding giga-bytes of information, and should not expect the system to have much storage spage, RAM or a recent processor.

The tools to handle this SecCube (configure, add / remove / list records ...) are platform dependant (although it is of course advisable those tools are coded so they are easy to port !), but the resulting SecCube is portable, i.e it may be transferred to another operating system or platform and used from there (with platform's SecCube tools).

A SecCube could be compared to an encrypted ZIP or TAR, where the archive is portable across platforms (Unix, Windows...) as long as the (small) ZIP/TAR program is available. A few differences should however be noted:

• SecCubes' format natively deal with records (not files) as data units. The fact a file may be added to a SecCube (possibly including some additional meta-data such as its path) is the work of SecCube upper layers (see architecture).
• adding / removing a given record does not mean re-encrypting the entire archival box, such as straight-forward encrypted zips would require.
• SecCubes are meant to operate with limited resources, so space, memory and safety are particularly important issues.

SecCube Requirements

1. format portability: possibility to migrate a SecCube transparently from a given operating system to another. For example, from Linux to Windows. Note we are only talking of format portability. This does not mean SecCube tools immediately work on all systems (!)
   
2. light-weight: runs with limited storage capability and RAM.

1. atomicity: as much as possible, keep the SecCube consistent at all times. For instance, if a crash occurs in the middle of an overwrite, make sure (at least) the ancient record is not lost.
2. wear-leveling: when the SecCube is written on a Flash, try to minimize write/erase cycles that damage Flash cells.
3. recovery: even with atomicity or wear-leveling techniques, it is possible a SecCube gets damaged. Propose offline tools to recover / optimize the SecCube.