- DPO's Blog
- Key issues
How does Rightly keep my data safe?
- 6 minutes
- By Tony Smith
Here at Rightly, being confident that we’re doing the best job we can to keep your data safe is critically important to us. So much so that it’s in every discussion we have about your data, and it’s in (almost) every change we make to our site.
Sure, we do the basics: HTTPS everywhere, encrypted database, encrypted storage volume etc. etc. but our users’ data is theirs, not ours, so we go above and beyond to make sure that we keep it safe.
When your data is stored
When you upload data as part of a request, it’s critical that we store it safely. The normal way to do that is to use encrypted storage, so we start with that. We use encrypted storage for both our database and our file store, where we hold the data that our users and companies exchange as part of request processing.
However, some of that data could be very sensitive, and we don’t want to take any chances with it.
For this reason, we also generate a random cryptographic key for each of our users and then use that as the basis for a separate key for each individual file. This second key is what’s called a ‘derived’ key - it’s mathematically computed from the first one. To derive a key from another, you take your existing key, add some other data of your choice, and put both through a special key derivation function (we use HKDF) which produces a new key.
This means that every file stored on Rightly is:
- First encrypted with a unique key specially derived for that file
- Stored on an encrypted storage volume
The advantage of this process is that we never have to store these derived keys - we just compute them again when we need them - but the randomness in the original key and the extra data, and the use of a cryptographically strong function, all combine to make these keys very strong.
The key we generated for the user is also encrypted before being stored in our encrypted database. It’s never stored on disk in any unencrypted form.
It might also help people to know that Rightly staff do not have access to the data encrypted in this way; call us traditionalists, but it’s your data, not ours.
When your data is being transferred
Data that just sits there is all very well, but the whole point of Rightly is to act as a trusted platform for individuals and companies to use to transfer personal data. It’s therefore important that our users know that only the receiving company can see their data, and that companies know that it’s safe to send data back to you using Rightly.
From user to company
Whenever one of our users sends a file to a company, we have to make sure that we’re only sending that file to the right person. Doing that by email would be bad for a number of reasons:
- Email is not secure by default and not that many people use secure email
- Emails can be forwarded anywhere
- Emails can sit around in peoples’ inboxes, folders and even in the Trash for far longer than necessary
- Emails are only protected by the recipient’s own security measures and we have no idea what those are
To do this, we send companies (by email) a link to a page where the data can be accessed, but protect access to that page using a one-time-code: when they access the page, we send the code to the email address of the intended recipient of the data. If they can enter that code into our site then we know we have the right person on the other end and they have access to the DPO (Data Protection Officer) inbox.
Once we know that, we fetch the data from our encrypted store, derive the key to decrypt it, and then show it to the company as the user intended.
As you would expect, this page uses HTTPS, so the page content, the code entry and the data transfer are all encrypted while in flight between our server and the company user’s browser.
From company to user
Receiving a request is, of course, only half the journey and companies need to feel secure when returning consumer data via the Rightly platform.
In fact, many companies still return data to individuals using email (I know, right!), and we’re passionate advocates for that process to stop. This is because as we mentioned, email is a terribly insecure way to send personal data.
When a company user uploads data to our response page, the data is encrypted using HTTPS from their desk all the way to our servers.
On arrival, it's immediately encrypted using the same key derivation scheme used for user documents: we decrypt the secret key of the intended recipient; derive the key for this new file; encrypt the file; and then store it in our encrypted file store.
From there on, only the requesting user can access the data. They’re notified that new data has arrived (but we don’t send it by email, that would be silly), and directed to login to view the response. Once they’ve logged in, they can download the data.
We don’t store your data for long
We don’t hang on to request data forever. Once a request is closed, we delete all the data attached to the request 90 days later. This includes documents sent by you (the user) to the company (perhaps to identify yourself), and data returned by the company.
This is important because we’re here to help you get the most out of your data, under your rights, not to be a data storage company.
Personal data explained: types, protection and deletion.
- DPO's Blog
- Data basics
Legally ⚖️ , 'personal data' is any information that allows a living person to be directly, or indirectly, identified.
- 5 minutes
GDPR: Everything you need to know
- DPO's Blog
- Data basics
GDPR stands for General Data Protection Regulation. It’s an EU (European Union) law, but it affects businesses worldwide to different extents.
- 5 minutes