File Request Links is a new feature we implemented which allows users to receive files from one-time collaborators. This was also an interesting engineering challenge that I’d like to explore in this article, particularly because it showcases many of the basic building blocks of a secure sharing process. First I’ll discuss what the feature is and then I’ll demonstrate the cryptographic design process behind it in small, iterative steps.

文件请求链接是我们实施的一项新功能，该功能使用户可以从一次性协作者那里接收文件。 这也是我在本文中要探讨的有趣的工程挑战，特别是因为它展示了安全共享过程的许多基本构建块。 首先，我将讨论该功能是什么，然后我将以较小的迭代步骤演示其背后的密码设计过程。

功能 (The Feature)

The basic idea is that we already let users send files to anyone. Using our share links, users can create links to content they have uploaded to Tresorit, and send them to people they want to grant access to with optional password protection.

基本思想是我们已经允许用户将文件发送给任何人。 使用我们的共享链接，用户可以创建指向已上传到Tresorit的内容的链接，并将其发送给想要通过可选密码保护授予访问权限的人员。

File Request Links work similarly; you create a link that you send to people you want to receive files from. You can also request email verification in case you want to receive uploads from multiple people and you want to connect each file to the uploader (or their email addresses at least).

文件请求链接的工作原理类似； 您创建一个链接，该链接发送给您要从中接收文件的人。 如果您希望接收来自多个人的上载，并且希望将每个文件都连接到上载者(或至少他们的电子邮件地址)，则也可以请求电子邮件验证。

Example use cases:

用例示例：

• Law firms requesting confidential data律师事务所要求提供机密数据
• Inbox for bids on open contracts收件箱中未结合同的投标

• “Dead drop” for journalists receiving data

  接收数据的记者的“ 死角 ”

• HR receiving CVs for open job offers人力资源接受职位空缺的简历

要求 (The Requirements)

When engineering a feature like this, it’s very important to have your requirements laid out before you actually start planning any details, to ensure it will fit in with the overall product and that it will give users the same guarantees your software does everywhere else.

当设计这样的功能时，在实际开始计划任何细节之前先列出您的要求非常重要，以确保它适合整个产品，并为用户提供相同的保证，即您的软件在其他任何地方都可以使用。

• Our servers should not be able to decrypt the data.我们的服务器不应能够解密数据。
• The uploader should be sure that the data is only accessible to the link sender.上传者应确保仅链接发送者可以访问数据。

• The receiver should be able to verify that the uploader’s email address or the data wasn’t changed by the server.接收者应该能够验证服务器没有更改上传者的电子邮件地址或数据。
• The server should not be able to “fake” uploads.服务器不应能够“伪造”上传。

• The receiver should be able to move uploads into their cloud without downloading and re-encrypting it.接收者应该能够将上传的内容移到他们的云中，而无需下载并重新加密。
• The server should be able to verify the email address if the receiver requires it.如果收件人要求，服务器应该能够验证电子邮件地址。

Some of the above might seem strange, but there is an important guarantee we want to provide to our users: even if someone were to try and force us to give up encryption keys, we are not able to — we don’t have access to them. This also makes things harder of course, but it’s what sets us apart, as most other solutions don’t take this into account.

上面的某些内容可能看起来很奇怪，但是我们想向用户提供一个重要的保证：即使有人试图强迫我们放弃加密密钥，我们也无法-我们无权访问他们。 这当然也使事情变得更困难，但这是使我们与众不同的原因，因为大多数其他解决方案都没有考虑到这一点。

实施 (The Implementation)

The above requirements make this an interesting challenge; since we don’t want to trust the server with controlling access, we need to ensure these things cryptographically. I’ll try and explain how we came up with a solution that solves all of the above and give a brief explanation about the crypto behind each step.

上述要求使这成为一个有趣的挑战； 由于我们不想通过控制访问来信任服务器，因此我们需要以密码方式确保这些事情。 我将尝试解释如何解决以上所有问题，并简要说明每个步骤背后的加密方法。

资料格式 (Data format)

Being able to move it into a regular folder without re-encryption means that we have to use the same data format as we do for regular files. This means that the encrypted file content and the metadata about them will be uploaded separately: file content and hashes will be uploaded first each encrypted by a unique key, then all the filenames and keys follow separately in another encrypted structure we call ‘directory’. We will only talk about encrypting and uploading the directory and even that we’ll handle as an arbitrary blob of data because the formats are pre-determined.

能够将其移动到常规文件夹而无需重新加密意味着我们必须使用与常规文件相同的数据格式。 这意味着加密的文件内容和有关它们的元数据将分别上传：文件内容和哈希将首先分别通过唯一的密钥加密，然后所有文件名和密钥分别以另一个称为“目录”的加密结构进行加密。 我们将只讨论加密和上传目录，甚至因为格式是预先确定的，我们也将其处理为任意数据块。

迭代1-URL中的对称密钥 (Iteration 1 — Symmetric key in the URL)

So we have our blob of data and we need to encrypt it somehow. Let’s start simple, add a key into the URL, and encrypt the data using symmetric crypto. We can actually add a key into the URL without it being sent over the network: anything after the # (what we call the hash of the URL) is not sent to the servers, so it won’t appear in firewall logs either.

因此，我们有大量数据，我们需要以某种方式对其进行加密。 让我们开始简单，将一个密钥添加到URL，然后使用对称加密对数据进行加密。 我们实际上可以在不通过网络发送密钥的情况下将其添加到URL：＃(称为URL的哈希)之后的任何内容都不会发送到服务器，因此它也不会出现在防火墙日志中。

Symmetric encryption means that you use the same key for encryption as you use for decryption (hence the symmetry). An example of this is AES-256, which is what most ads refer to as “military-grade encryption”. This means, that the keys you use here are like normal keys: anyone who has the key can unlock anything that was locked by it. Your lock can be super secure (as AES-256 is), but if you hand your key over to someone they can easily unlock it. If you uploaded something, then you’d have to have the key — meaning you can decrypt data uploaded by someone else.

对称加密意味着与解密使用相同的密钥进行加密(因此是对称的)。 例如AES-256，这就是大多数广告所称的“军事级加密”。 这意味着，您在此处使用的钥匙就像普通钥匙：拥有钥匙的任何人都可以解锁被其锁定的任何物品。 您的锁可以是超级安全的(就像AES-256一样)，但是如果您将钥匙交给某人，他们可以轻松地将其解锁。 如果您上传了某些内容，则必须拥有密钥-这意味着您可以解密其他人上传的数据。

迭代2- 非对称加密 (Iteration 2 — Asymmetric crypto)

Since symmetric encryption has this problem, we could try asymmetric instead. It basically means that you have a set of two keys: anything locked (or encrypted) by one can be unlocked (or decrypted) by the other. This seems like an exact fit for our purposes, as the receiver can keep the private key, and we can give the uploaders the public one. These public keys are pretty long though, so we only add an id to the hash, and the uploader can get the key from our servers.

由于对称加密存在此问题，因此我们可以尝试使用非对称加密。 基本上，这意味着您有两个密钥集：一个被锁定(或加密)的任何东西都可以被另一个解锁(或解密)。 这似乎完全符合我们的目的，因为接收者可以保留私钥，而我们可以为上传者提供公共密钥。 这些公共密钥相当长，因此我们仅向哈希添加ID，上传者就可以从我们的服务器获取密钥。

Asymmetric encryption is slower, but there is an even bigger problem: it has a size limit. 2048-bit RSA keys can only encrypt a meager 126 bytes (with OAEP-SHA-512) in one go. This means that we have to generate a symmetric key and use it just like the previous iteration, then encrypt it using the public key. This is actually just a layer on top of Iteration 1.

非对称加密速度较慢，但​​存在一个更大的问题：它具有大小限制。 2048位RSA密钥一次只能加密126个字节(使用OAEP-SHA-512)。 这意味着我们必须生成一个对称密钥并像之前的迭代一样使用它，然后使用公共密钥对其进行加密。 实际上，这只是迭代1之上的一层。

This seems secure if you only consider the uploaders and outside threats, but remember: we still want the data to be secure even if our servers are taken over. If they are, whoever has control could switch out the public key and steal any future uploads. There are multiple ways to get around this, but we’re still missing a few other things, namely, the server can’t check the uploader’s identity and it could fake uploads.

如果仅考虑上传者和外部威胁，这似乎是安全的，但请记住：即使我们的服务器被接管，我们仍然希望数据是安全的。 如果是这样的话，谁控制谁都可以切换出公共密钥并窃取将来的任何上传内容。 解决此问题的方法有多种，但是我们仍然缺少其他一些内容，即服务器无法检查上传者的身份，并且可能会伪造上传内容。

迭代3- 密钥派生 (Iteration 3 — Key derivation)

We could combine the two methods for a bunch of added benefits. This time we could add a relatively short (compared to public keys, anyways) random string to the URL and derive multiple things from it. The link creator can tell the server about parts of this information and use the other part to send information to the uploader without the server seeing it.

我们可以将这两种方法结合使用以获得更多好处。 这次，我们可以向URL添加相对较短的字符串(无论如何与公共密钥相比)，并从URL派生出很多东西。 链接创建者可以告知服务器有关此信息的一部分，并使用另一部分将信息发送到上载器而服务器不会看到。

This is called key derivation: we take a bunch of data and turn it into another bunch of data in a way that can’t be reversed (or at least is very hard to do), e.g.: hashing it. It’s like a fire pole: you can slide down multiple times and get to the same place (same data in this case), but you can’t go back up.

这就是所谓的密钥派生：我们获取一堆数据，然后以一种不可逆的方式(或者至少很难做到)将其转换为另一组数据，例如：对数据进行哈希处理。 这就像一根火把：您可以向下滑动多次并到达同一位置(在这种情况下，是相同的数据)，但是不能返回。

From the random data in the URL, we derive 2 pieces of information: id and key. We can use the id to get both the public key and an encrypted shared secret from the server. We can decrypt this shared secret using the key derived from the URL and use it to encrypt the data produced the same way as above. This makes it another layer on top of the above.

从URL中的随机数据中，我们得出2条信息：id和key。 我们可以使用id从服务器获取公钥和加密的共享机密。 我们可以使用从URL派生的密钥来解密此共享机密，并使用它来加密与上述相同的方式生成的数据。 这使其成为上述之上的另一层。

After all this, it starts to feel like an onion, but it’s worth it: we have a short URL, yet the uploaded data is protected from other uploaders (because of the asymmetric part) and the server can verify that the uploader has the URL but can’t change or steal uploads. There is one last thing still missing though: there is no information about the uploader the receiver could check. If we just upload the metadata to the server, it could still change the uploader’s email address (even if the data is the same) and if it’s encrypted there is no way to send an email to verify the uploader.

经历了所有这些之后，它开始感觉像是一个洋葱，但这是值得的：我们有一个简短的URL，但是上载的数据受到其他上载者的保护(由于不对称部分)，服务器可以验证上载者具有该URL但不能更改或窃取上传内容。 但是，最后一件事仍然缺失：没有关于接收者可以检查的上载器的信息。 如果我们仅将元数据上传到服务器，它仍然可以更改上传者的电子邮件地址(即使数据相同)，并且即使已加密，也无法发送电子邮件来验证上传者。

迭代4- 认证数据 (Iteration 4 — Authenticated Data)

We need to add metadata to the uploads that is both verifiable by the uploader and the server. Luckily, we are using AES-GCM, which allows us to add some associated data to what’s encrypted. It’s like a glass compartment on a locked box: some parts are visible from the outside, but no one can tamper with it. We can upload the email address and the link id in this “glass compartment”, so the server can check both and send a verification email, while the receiver can verify that the server didn’t change them.

我们需要将元数据添加到上传文件中，并且可由上传者和服务器验证。 幸运的是，我们使用的是AES-GCM ，它允许我们向加密的内容中添加一些关联的数据 。 就像锁盒上的玻璃隔间：从外部可以看到一些零件，但是没有人可以篡改它。 我们可以在此“玻璃隔间”中上载电子邮件地址和链接ID，以便服务器可以同时检查并发送验证电子邮件，而收件人可以验证服务器没有更改它们。

验证需求 (Verifying the requirements)

Now that we have a plan, we need to verify that we do actually meet all our requirements.

现在我们有了一个计划，我们需要验证我们确实符合所有要求。

Our servers should not be able to decrypt the data.It would need access to both the private key of the link and the shared secret, but it has access to neither.

我们的服务器不应能够解密数据。 它既需要访问链接的私钥，也需要访问共享密钥，但是都不能访问。

The uploader should be sure that the data is only accessible to the link sender.The uploader is ensured of this by encrypting the key to the uploads using a key from the URL and the public key of the destination. This means that it’s only decryptable by someone who has access to both the URL and the private key of the recipient, both held by the receiver.

上传者应确保只有链接发送者才能访问数据。 通过使用URL的密钥和目标的公共密钥对上传的密钥进行加密，可以确保上传者的安全。 这意味着只有访问者拥有接收者的URL和私有密钥的人才能解密它。

The receiver should be able to verify that the uploader’s email address or the data wasn’t changed by the server.The receiver can verify that nobody tampered with the authenticated data part of the upload, which contains the information about the uploader.

接收者应该能够验证服务器没有更改上传者的电子邮件地址或数据。 接收者可以验证没有人篡改上载的已验证数据部分，该部分包含有关上载者的信息。

The server should not be able to “fake” uploads.The server can’t “fake” uploads, because it doesn’t have access to the shared secret: it’s encrypted by a key derived from the URL, but that isn’t sent to the server.

服务器不应能够“伪造”上传。 服务器无法“伪造”上传，因为它无权访问共享机密：它是由从URL派生的密钥加密的，但不会发送给服务器。

The receiver should be able to move uploads into their cloud without downloading and re-encrypting it.We have treated the data as an arbitrary blob of data, so we can use our normal file formats and it was encrypted by a unique key so we can simply reuse it.

接收者应该能够将上传的内容移到他们的云中，而无需下载并重新加密。 我们已经将数据视为任意数据块，因此我们可以使用常规文件格式，并且通过唯一密钥对其进行加密，因此我们可以简单地重用它。

The server should be able to check the email address if the receiver requires it.The server can check the email address of the uploader because it’s uploaded as authenticated data: something the receiver can verify but the server can see.

如果收件人要求，服务器应该能够检查电子邮件地址。 服务器可以检查上传者的电子邮件地址，因为它已作为经过身份验证的数据上传：收件人可以验证但服务器可以看到的内容。

Everything checks out, meaning you can get data uploaded (almost) straight into your cloud storage safe from everyone, including anyone hacking into our servers (if that ever happens).

一切都检查完了，这意味着您可以从所有人(几乎包括侵入我们的服务器的任何人)(几乎)将数据几乎(几乎)直接上传到云存储中。

结论 (Conclusion)

This means, that our design is done and it does what we originally intended it to do: allow users to request files from non-registered collaborators in a secure manner. The implementation of this design is also a challenge: the limitations and the finer details took months for multiple people to iron out.

这意味着我们的设计已经完成，并且完成了我们最初打算做的事情：允许用户以安全的方式向未注册的协作者请求文件。 这种设计的实现也是一个挑战：局限性和更精细的细节花了几个月的时间才能让多人解决。

All in all, this was a fun and challenging project to work on and I hope I can use it as an example to show the basic building blocks of crypto design and our design process.

总而言之，这是一个有趣且具有挑战性的项目，我希望我可以以它为例来展示加密设计的基本组成部分以及我们的设计过程。