From 62c15649eb3503b933c22843cde8d32f6746bd69 Mon Sep 17 00:00:00 2001 From: Alexander Neumann Date: Sat, 3 Jan 2015 15:28:33 +0100 Subject: [PATCH] Describe threat model --- doc/Design.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/doc/Design.md b/doc/Design.md index ca2148066..d9990ab61 100644 --- a/doc/Design.md +++ b/doc/Design.md @@ -269,3 +269,46 @@ The implementation aims for 1MiB chunk size on average. For modified files, only modified chunks have to be saved in a subsequent backup. This even works if bytes are inserted or removed at arbitrary positions within the file. + +Threat Model +============ + +The design goals for restic include being able to securely store backups in a +location that is not completely trusted, e.g. a shared system where others can +potentially access the files or (in the case of the system administrator) even +modify or delete them. + +General assumptions: + + * The host system a backup is created on is trusted. This is the most basic + requirement, and essential for creating trustworthy backups. + +The restic backup program guarantees the following: + + * Accessing content of backup-up files and meta data should not be possible + without a password for the repository. Everything except the `version` file + and the meta data included for informational purposes in the key files is + encrypted and then signed. + + * Modifications (intentional or unintentional) can be detected automatically + on several layers: + + 1. For all accesses of data stored in the repository it is checked whether + the cryptographic hash of the contents matches the storage ID (the + file's name). This way, modifications (bad RAM, broken harddisk) can be + detected easily. + + 2. Before decrypting any data, the HMAC signature on the encrypted data is + checked. If there has been a modification, the signature check will + fail. This step happens even before the data is decrypted, so data that + has been tampered with is not decrypted at all. + +However, the restic backup program is not designed to protect against attackers +deleting files at the storage location. There is nothing that can be done about +this. If this needs to be guaranteed, get a secure location without any access +from third parties. If you assume that attackers have write access to your +files at the storage location, attackers are able to figure out (e.g. based on +the timestamps of the stored files) which files belong to what snapshot. When +only these files are deleted, the particular snapshot vanished and all +snapshots depending on data that has been added in the snapshot cannot be +restored completely. Restic is not designed to detect this attack.