You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Backups can be authenticated as whole, not just individual VMs (at best).
Atomicity: When computer crashes during backup, partial backup does not cause problems.
It can obscure what file belongs to what VM. (But data usage patterns can still leak it, at least to some degree.)
Allows buffering volumes. (Better performance, can potentially obscure data access patterns when upload is reordered.)
Allow some data checks on remote. It can check hashes, because they are keys.
BackupStorageVM<->dom0 interface
Rather a simple key-value interface:
get/set KDF params (operates with unauthenticated plaintext and simple KDF params format)
getRoot – returns signed root with timestamp
setRoot (or maybe compareAndSetRoot) – atomically stores a new signed root
getBlob – returns an encrypted blob by ciphertext hash
putBlob – uploads a new blob
deleteBlob – removes blob
dom0 <-> BDVM interface
The interface should be very similar to BackupStorageVM<->dom0, but dom0 has to verify the permissions and maybe handle encryption.
Directory structure
Directory structure would be implemented on top of the mentioned key-value storage as Merkle tree.
What to decide
How to handle permissions to particular files without leaking any data?
How to buffer files in the target VM without leaking any data when maliciously modified? (When buffering, one has to send unauthenticated chunks.) Do we want this at all?
How to handle garbage collection? Maybe it will require parsing and traversing directory structure in dom0. OTOH, it should be a rather simple format.
When user removes a VM and creates a VM with the same name, should they be related in any way?
The text was updated successfully, but these errors were encountered:
All items of Merkle tree are encrypted and somehow linked to the particular VM. TODO: describe details.
MAC is not needed for any node except the root one, because other node's ciphertext are authenticated by hash stored in a node that is already authenticated.
Root item
creation date
link to previous root item?
root directory
Directory structure
List of directory item descriptions ordered by name.
Directory item description
ASCII filename with limited set of characters
item type (file or directory)
creation date (?)
size
hash(es) of ciphertext (also this is identifier under which it will be references)
Why?
BackupStorageVM<->dom0 interface
Rather a simple key-value interface:
dom0 <-> BDVM interface
The interface should be very similar to BackupStorageVM<->dom0, but dom0 has to verify the permissions and maybe handle encryption.
Directory structure
Directory structure would be implemented on top of the mentioned key-value storage as Merkle tree.
What to decide
The text was updated successfully, but these errors were encountered: