Last updated: 
2 months 3 weeks ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Encrypted Information: Law enforcement access

Tuesday, October 22, 2013 - 11:48

The amount of information stored in encrypted form is steadily increasing, supported by recommendations from the Information Commissioner and others. When deciding to adopt encryption, it’s worth planning for what might happen if the police or other authorities need to access it in the course of their duties.

Normally the existing access rules under section 22 of the Regulation of Investigatory Powers Act 2000 (RIPA) or sections 28 and 29 of the Data Protection Act 1998 will be sufficient. When an organisation receives an order or request to disclose information that is encrypted it will simply decrypt it and provide that version (securely!) to the police.

There are three situations where that won’t work:

  • If someone else encrypted the information and the organisation doesn’t have a key to decrypt it;
  • If the information was encrypted using someone else’s public key, so the organisation (not having the private key) can't decrypt it;
  • If the organisation used to be able to decrypt the information but the key has been lost/forgotten/destroyed.

If the police believe that you are refusing to decrypt information, then they can make a disclosure order under s.49 of RIPA. Failing to comply with an order is a criminal offence so if you actually can’t decrypt it then it’s important to be able to explain that. Ideally that explanation will prevent anyone serving an s.49 notice on you in the first place. But even if a notice is served you don’t need particularly strong evidence, just "sufficient evidence to raise an issue" (s.53). Then the prosecution need to prove, beyond reasonable doubt, that you are lying.

Unfortunately neither the legislation nor the very limited case law (the Open Rights Group maintain a list of cases) provide much guidance on what your evidence might look like. But it should help to have a consistent, well-documented explanation of your encryption practice and how it resulted in you being unable to decrypt the required information. For example:

  • If you are advising others on encryption, make sure the guidance tells them how to keep the key secure without revealing it to others (that way there should be less chance of anyone thinking that an organisation can decrypt anything that happens to be on its systems);
  • If you are sending a message to someone else's public key and not keeping a copy encrypted to yourself there's little point in keeping the message you sent: without their private key you'll never be able to read it anyway;
  • If you are encrypting information that you intend to be able to decrypt in future, make sure the keys are kept securely and in a way that's appropriate to the circumstances in which you expect to use the information. Encrypting something that you don't plan to use for months but expecting nonetheless to remember a long and complex key without writing it down doesn't make operational sense and is unlikely to be a plausible story in court;
  • And if you discover at any stage that you are no longer able to decrypt the information then record that at the time, don’t wait till after you’ve been served with a notice!

Finally, if you are using digital signatures, it's probably a good idea to use different keys for signing and encryption. According to s.49(9) an order can't be made to disclose a key that "is intended, and has only been used, for creating digital signatures".


A possible use case for intentionally keeping the cyphertext whilst having destroyed the key or keys is where one knows data is being archived / backed-up and to destroy the data in the archive / backup is too costly or impossible but one wishes, at some point in the future, to "destroy all copies". Thus encrypt the data, allow it to be archived / backed-up and when the time comes that all the copies of the data need to be destroyed, just destroy the key(s). In order to provide cover for yourself you'll need to document why this is necessary, how the process works, how the key(s) are managed, the triggers for destroying the key(s) and most importantly have a good record of when any particular key is destroyed. A reason for multiple keys is that they would allow you to "destroy" data at particular points in the archive / backup.

Nice example, thanks. Same process could also apply if you were backing up encrypted snapshots to the cloud: obviously you'd want to delete the virtual files when their time came, but deleting the keys too might gain extra brownie points with the data protection authorities (at least the European ones who still seem to be hankering after physical destruction).

And it seems to me that in both cases the records of a *series* of keys being destroyed adds additional convincingness to your explanation :)