2
2
mirror of https://github.com/octoleo/restic.git synced 2024-11-22 21:05:10 +00:00

Merge pull request #2536 from MatthewVance/threat-model

Update threat model
This commit is contained in:
Alexander Neumann 2021-01-28 14:26:03 +01:00 committed by GitHub
commit 84822d44d4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -566,43 +566,100 @@ 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.
in a location that is not completely trusted (e.g., a shared system where
others can potentially access the files) or even modify or delete them in
the case of the system administrator.
General assumptions:
- The host system a backup is created on is trusted. This is the most
basic requirement, and essential for creating trustworthy backups.
basic requirement, and it is essential for creating trustworthy backups.
- The user uses an authentic copy of restic.
- The user does not share the repository password with an attacker.
- 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.
- The whole repository is re-encrypted if a key is leaked. With the current
key management design, it is impossible to securely revoke a leaked key
without re-encrypting the whole repository.
- Advances in cryptography attacks against the cryptographic primitives used
by restic (i.e, AES-256-CTR-Poly1305-AES and SHA-256) have not occurred. Such
advances could render the confidentiality or integrity protections provided
by restic useless.
- Sufficient advances in computing have not occurred to make bruteforce
attacks against restic's cryptographic protections feasible.
The restic backup program guarantees the following:
- Accessing the unencrypted content of stored files and metadata should
not be possible without a password for the repository. Everything
except the metadata included for informational purposes in the key
files is encrypted and authenticated.
- Unencrypted content of stored files and metadata cannot be accessed
without a password for the repository. Everything except the metadata
included for informational purposes in the key files is encrypted and
authenticated. The cache is also encrypted to prevent metadata
leaks.
- Modifications to data stored in the repository (due to bad RAM, broken
harddisk, etc.) can be detected.
- Data that has been tampered will not be decrypted.
- Modifications (intentional or unintentional) can be detected
automatically on several layers:
With the aforementioned assumptions and guarantees in mind, the following are
examples of things an adversary could achieve in various circumstances.
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.
An adversary with read access to your backup storage location could:
2. Before decrypting any data, the MAC on the encrypted data is
checked. If there has been a modification, the MAC check will
fail. This step happens even before the data is decrypted, so data
that has been tampered with is not decrypted at all.
- Attempt a brute force password guessing attack against a copy of the
repository (even more reason to use long, 30+ character passwords).
- Infer which packs probably contain trees via file access patterns.
- Infer the size of backups by using creation timestamps of repository objects.
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.
An adversary with network access could:
- Attempt to DoS the server storing the backup repository or the network
connection between client and server.
- Determine from where you create your backups (i.e., the location where the
requests originate).
- Determine where you store your backups (i.e., which provider/target system).
- Infer the size of backups by using creation timestamps of repository objects.
The following are examples of the implications associated with violating some
of the aforementioned assumptions.
An adversary who compromises (via malware, physical access, etc.) the host
system making backups could:
- Render the entire backup process untrustworthy (e.g., intercept password,
copy files, manipulate data).
- Create snapshots (containing garbage data) which cover all modified files
and wait until a trusted host has used forget often enough to forget all
correct snapshots.
- Create a garbage snapshot for every existing snapshot with a slightly different
timestamp and wait until forget has run, thereby removing all correct
snapshots at once.
An adversary with write access to your files at the storage location could:
- Delete or manipulate your backups, thereby impairing your ability to restore
files from the compromised storage location.
- Determine which files belong to what snapshot (e.g., based on the timestamps
of the stored files). When only these files are deleted, the particular
snapshot vanishes 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.
An adversary who compromises a host system with append-only access to the
backup repository could:
- Render new backups untrustworthy *after* the host has been compromised
(due to having complete control over new backups). An attacker cannot delete
or manipulate old backups. As such, restoring old snapshots created *before*
a host compromise remains possible.
*Note: It is **not** recommended to ever run forget automatically for an
append-only backup to which a potentially compromised host has access
because an attacker using fake snapshots could cause forget to remove
correct snapshots.*
An adversary who has a leaked key for a repository which has not been re-encrypted
could:
- Decrypt existing and future backup data. If multiple hosts backup into the same
repository, an attacker will get access to the backup data of every host.