Figure 1. Key hierarchy
The Eternity server represents itself the whole service in fact. It uses routing mechanism provided by Mixes. We assume the ES gets from mix the public key to be used to encrypt the message and then it passes the message to mix. A mix ensures any further processing involved. The public key is typically the key specified in the access certificate of the recipient.
It is necessary to ensure that any information that could reveal any knowledge about contents of stored data (the data itself, lists of keywords, client requests etc.) have to be concealed from anybody including the server operator. Such data could be processed inside the TCB only. When disposed outside the TCB it have to be encrypted either with some of TCB keys either with public key of the recipient.
In similar manner should be managed encryption keys used by TCB. We suggest to use layered system of keys. Keys at any layer are disposed outside the TCB encrypted with some key from the next higher layer. The key at the highest layer - a master key - have to be protected by some other means. In the case of hardware based TCB it should be never disposed outside the secure perimeter in any form. In the case of software implementation of the TCB it should be stored in some unusable form. For example it should be encrypted with a key constructed from a pass-phrase that have to be entered during initialization of the master key.
It is necessary to realize that a key itself is self-identificating. It means, that any key is likely to be unique within whole system, because the set of actually used keys is relatively very, very tiny in comparison to the space of all possible keys. This is why all keys shared together with anyone have to be regularly changed. The symmetric keys should be used only for one session.
The assumptions just described above lead to need of large number of keying material. In principle there are two ways to acquire a key. The first way is to use method based on truly random generator of randomness. This way should be used to create any long-term key at least. In the case the running of truly random generator is too time consuming or any other way complicated, the other keys used only once or within short time period could be generated with software-based pseudo-random number generator seeded with truly random value.
Due to slowness of public key operations, we substitute any such encryption (with exactly one exception - the creation of unique copy of the data) with so called sealing. The sealing consists of two steps. In the first step the data is encrypted with randomly selected symmetric key and only the key itself is encrypted using public key and then concatenated to encrypted data. Only the owner of appropriate private key is able to decrypt symmetric key and unseal the data.
The approximate schema of the key management is at Figure 1. As mentioned above all keys except the top most key - the master key are stored encrypted with some higher layer key. We assume that in order to achieve smaller operational overhead caused by encryption, at least all long term keys should be loaded into TCB during initialization and stored inside in some ready to use form until the TCB is deactivated or so.
In the case of software TCB, we can this way prepare even more the most often used keys. For example we can maintain sort of recently used keys. It is necessary to avoid any residues. If possible the memory in which any keying material or any internal tables of cryptographic algorithm or intermediate values are stored should be allocated in such way that memory manager will not swap out corresponding pages into disc. Before such memory block is released, it is necessary to wipe its content.
The process of initialization of many modern encryption algorithm is time consuming. For example initialization of the Blowfish algorithm is equivalent to encryption of more than 1kB of data. Especially in the case of ring and cert_ring keys the initialization takes many times more instructions than the encryption of useful data itself. To overcome such ineffectiveness we can store not only the key itself, but the whole initialized internal tables of the encryption algorithm. Such data structure we will call the context. It could be subkeys generated from key, some substitution, permutation or any other key dependent tables and many more. The context should be handled accordingly to principles stated for handling of keys.
The key ring in fact is only an logical structure in fact. The real physical implementation of it depends on the selection of the implementation team. There are two principal approaches to the problem. Both of them have their advantages and disadvantages.
The first approach is to implement ring as one physical block (or structure consisting from fixed size blocks). When the key is to be used the appropriate block is processed and the key is found. (In the case of more blocks we can maintain some evidence which block contains which key to can access only the relevant block directly).
The second approach is to encrypt every key separately with ring key and concatenate it to relevant file. Because the key should be used only to encrypt or decrypt the file such arrangement looks very reasonable.
The advantages of the second approach are evident. The handling of keys and in turn the files is simpler, we can avoid repeated decryption of ring file, the updates of ring (adding of new keys, deleting expired ones, .) are trivial. The only (but serious) disadvantage is the complicated exchange of the ring key. In such key we have to access all files to reencrypt the storage key with the new ring key. Maybe the good solution will be to implement ring as a structure of blocks containing one key each.
Implementation of CRing is entirely arbitrary.
We suggest that any symmetric key used by TCB is coupled with some appropriate unique identification and type description. For example this information could be XORed to the key itself. Before the key is used, the identification and type have to be specified and XORed to the key again (and thus removed). Internal mechanism of TCB should check correctness of every key use. Before the key is used, its integrity should be checked. Any encrypted data should be concatenated with used key identification both before and after the encryption is performed. Figure 1 describes both problems discussed in this paragraph.
The TCB should perform following functions (besides the functions it provides to ES generic manager module):
Figure 1. Key hierarchy
Figure 2. Key and encrypted item internal structure