BestCrypt Container File Structure

This technical appendix document describes two different versions of BestCrypt container file formats.

Version 7 Format

The Version 7 (V7) container format is the container header structure used in older (pre-8.x) versions of BestCrypt. It is supported for backwards compatibility and used with the KGSHA family of key generators. This container format consists of two parts: a 512-byte hidden sector header and avariable size encoded keyblock that follows. The following sections describe each of these structures separately.

Header

The V7 header is called a hidden sector and has a size of 512 bytes. Its purpose is to record container size, encryption algorithm used for encrypting container data, user-specified description and the following service fields:

KGSHA/KGSHA256 Keyblock

Keyblock contains encoded encryption key for encrypting container data. The specific encoding algorithm and data stored depends on the implementation of the key generation module. The built-in key generator used with V7 container format is KGSHA/KGSHA256. Its keyblock has a size of 1380 bytes and the following structure:

Container data encryption keys are stored in key slots, each encoded by a unique user password. There are three ways to interpret each key slot depending on the key attribute flag: main key slot, hidden key slot and verification slot. All three of these occupy the same space and the generic key slot structure looks like this:

Each key slot is initialized with random data and stored user encryption key and digest encrypted by a unique user password. Key attribute values have one of the following bits set:

• 0x01: Key slot is empty. This bit is also set for hidden key slots.
• 0x02: Key slot is occupied by either the main container key or verification data. Never set for hidden key slots.
• 0x04: Key slot is occupied by verification data.

Verification data is stored once for the main container key to provide a way to verify keys recieved from BestCrypt Enterprise server. Verification slot structure differs in the first 64 bytes of the slot data; instead of the encryption key, it contains a block of random bytes encrypted with the container key.

Hidden Part

Because each slot is initialized with random data and, later, stored key data and digest encrypted by a unique user password, it is indistinguishable from totally random data except for the attribute bit. However, because attribute bits for all key slots are set to 0x01 upon initialization and never changed for the hidden key slot, it is impossible to tell a hidden key slot from an empty, unused key slot just by looking at it.

Version 7 hidden parts are constructed in a very simple (and dangerous) manner. The hidden part is positioned from the end of the main part data minus its size. For instance, if the main part size is 10MB and the hidden part size is 1MB, then it will start at the 9MB offset in the main part.

Currently it is discouraged to use hidden parts in version 7 containers in favor of version 8, which is described in the next section.

Version 8 Format

The Version 8 container format is a container structure used in all current version of BestCrypt on all platforms. It provides such advanced features as better hidden part protection and header encryption. Like all BestCrypt container formats, it consists of a header and a variable-sized encoded key region called keyblock.

Header

A Version 8 header has a size of 1536 bytes (or 1.5 KB), contains basic container information and can be encrypted to make a container file indistingiushable from random data. Its unencrypted structure is as follows:

KGGHOST Keyblock

A keyblock contains an encoded encryption key for encrypting container data. The specific encoding algorithm and data stored depends on the implementation of the key generation module. The built-in key generator used with the V8 container format is KGGHOST.

The aforementioned key map structure inside the container header stores information about the type, location and size of the encoded encryption keys in an encoded keyblock, except for hidden keys. A variable-sized keyblock structure that follows container header is divided into 256-byte key slots. Each slot is described in the key map using the following structure:

This way, a 512-byte key map can store information about 64 encoded key slots, 256 bytes each. Which means that V8 container format can store 16KB of encoded key data in keyblock. The actual format of storing keyblock data is as follows:

• The first 2.5KB of a keyblock are stored after the container header up to a 4KB boundary from the beginning of the container file. This primary keyblock region can store 10 encoded key slots.
• All subsequent keyblock space is allocated as needed in 4KB blocks attached to the end of the container file up to 16KB of additional data.

Each key slot in a KGGHOST keyblock stores encoded key data. There are a number of different encoding algorithms based on the user authentication type. Different algorithms produce encoded data of different sizes, which can be stored in multiple key slots. The current set of encoding algorithms includes password encoding, secret sharing encoding and public key encoding.

Hidden Part

Encoded key data always contains random data regardless of the key encoding used, for both initialized and not-initialized key slots. The only way to know if a group of key slots encode a valid key is to look at the key map structure element indexed by key slot number. Information about hidden key position is never written to the key map, which means that there is no way to know if any hidden parts exist for a particular container and its location.

The data of the version 8 hidden part is layed out much more safely than that of the version 7. When creating a version 8 hidden part of a specified size, BestCrypt will try to store its data inside unused file system clusters of the main part. This way, BestCrypt can prevent multiple hidden parts inside a single container from overlapping. Although writing to the main part can still damage a hidden part, the possibility is much lower as compared to the version 7 container format.