Trust No One: Eliminating Trust in Tapestry's Design

Wait, I thought the whole point of Tapestry was to establish trust?

In a sense that’s actually true. Tapestry’s purpose was to create an absolutely-trusted backup. That is to say, a user familiar with the program’s operation can create a backup with trust it has not leaked data, store it with trust that it is illegible to remote users, and recover it in the trust it has not been tampered with. However, this approach works precisely because it discards trust in as many factors as possible.

Specifically, Tapestry seeks to remove trust from the user and the storage mechanism.

Why you shouldn’t trust the user?

Tapestry’s design is such that it critically distrusts user input, asking for only the bare minimum and even then accepting very little of it itself. Indeed, once Tapestry is adequately configured, it can be run as a cron job with a minimum of user interaction. The only step in the backup process that requires user intervention is signing, if signing is enabled. This is still not an obstacle to the cron job, as the program will happily wait for the user to return in the morning and enter their pin at that time.

Even then, Tapestry does not directly handle the pin request - the request is caused by providing nothing in the passphrase field to the GPG request, which causes GPG to prompt for it with its native pinentry program. In point of fact, Tapestry executes no code provided it by the user, and since it contains no secrets, it can’t really be exploited by a user either.

This is mostly done to prevent misuse. The user may, without malice, nonetheless mis-type an input or command. Instead, everything is run as automatically as possible under the hood. In a distributed environment, the administrator can simply remove write permission from the relevant tapestry.cfg file to prevent user tampering, or leave it in the exclusive ownership of a dedicated user.

We don’t trust the user’s system either - the encryption step is unbipassable both because it defeats the point, and also because it renders anything to be passed to storage non-executable. If .tap files are being stored on a server, this protects that server.

Why we don’t trust storage?

Simply put, we don’t have to. Tapestry was concieved, from the beginning, as a mechanism for facilitating off-site backups, and it occurred to me fairly early on that the best way to defend against a whole host of attacks was simply not to trust the storage.

Tapestry achieves this in two ways. First, the storage is not assumed to be inherently secure - it is assumed, from the outset, that someone will gain unauthorized access to the storage device. In this eventuality the pimary concern is not actually the loss of data, but its access. If an attacker gains access to a .tap package, even if they correctly diagnosed the version of the software to open it with, it is extremely unlikely they would managed to decrypt it, without also compromising the key. Even if the key was stored on some system rather than on a device like a smart card or in the smart-card emulation “slot” of a Yubikey Neo or similar, the attacker would at the very least need to brute force the passphrase or pin protecting that key. In this way we can say that a .tap file itself is secure against unauthorized access.

Unauthorized destruction, on the other hand, is another matter. If vandalism or loss are in your threat model (and frankly, loss-to-disaster likely should be), it is critical to maintain backups in duplicate. In this way you could suffer the complete loss of both the active system and one of your backup sites and still have access to the data. For the home user, this is overkill, of course. It is sufficient to let the live system be the “backup” of the backup, and vice versa.

Of course, neither unauthorized access and unauthorized destruction account for unauthorized tampering. In a distributed model the Tapestry Key itself is held in common, meaning that your attacker would have access to a public-key version. An attacker with write access to your storage medium, or the ability to replace that medium, could create a malicious backup, which the administrator or user would then recover from. Even if it was immediately obvious the backup had not been fully legitimate (unexpected inclusions or exclusions, for example), it could be very difficult to detect a problem if there were malicious inclusions. It is for this reason that the signing pass is included in Tapestry by default, with backups being individually signed by the user responsible for creating them. As signing is a private-key operation, then, it follows that a signature is incontrovertable, provided there are no errors made in key handling or key security on the part of the user or their organization.

I hope you liked this brief conversation about trust elimination, which has been an area of interest of mine for some time. At a point in the near future we’re going to look at eliminating trust in my other major project, Tarnished Tale. If you liked this article, or some of my other content, I would appreciate it if you stopped by my ko-fi.com account and threw a tip in the coffee can.