I recently read an article on the TriLUG blog mirror discussing access to data after the death of the owner. I’ve also given this a lot of thought as well and had previously come to the same conclusion as the original author of the article has:
“I created a file called “deathnote.txt” which I then encrypted using GPG. This will encrypt the file so that both Bob and Alice can read it (and I can too). I then sent it to several friends unrelated to them with instructions that, upon my death (but not before), please send this file to Bob and Alice.”
To be honest, I didn’t actually go through with this project as there were just too many variables that I hadn’t figured out. There is a lot of trust involved in this that potentially requires a very small number of people (2) to really hose things up. It’s not that I wouldn’t trust my “trusted friends” with the responsibility but it potentially makes them targets and two is just a really low threshold for an adversary to recover this information.
What really threw me was that the author also included a copy of his private key in case they couldn’t locate it on his computer to, I’m assuming here, access other data. I have one word for this: NOPE!
Okay, short of the private key thing, what was proposed was quite logical. Like I said above, I had a very similar idea a while back. Springboarding from that idea, I’d like to propose another layer of security into this whole process.
Splitting up the data
So you have your encrypted blob of information that goes to person A when you kick off but you don’t want person A to have it before. Import some trusted friends and you have a means of providing the information to person A upon your demise. But letting a single person, or even two people, control this information is dangerous. What if you could split up that data into further encrypted parts and handed those parts out to several friends? Then, not one single person would hold all the information. You’d likely want some overlap so that you wouldn’t need ALL the friends to present the information (maybe it got lost, maybe the friend got hit by the same bus that you did, etc) so we’d want to build in a little redundancy.
Shamir’s Secret Sharing Scheme (ssss) is a neat piece of software that takes some information, encrypts it, and then break it into pieces. Redundancy can be added so that not all parts are required to reassemble the data (think RAID 5).
“In cryptography, a secret sharing scheme is a method for distributing a secret amongst a group of participants, each of which is allocated a share of the secret. The secret can only be reconstructed when the shares are combined together; individual shares are of no use on their own.”
–From the SSSS website
Implementing the solution
Because ssss can only share relatively small strings (less than 1024 bits), my “death” instructions would likely need to be stored whole as a cipher text and the key (symmetric) being the shared object.
The other piece of this solution would be whom to get to hold the shared bits of keys. It would likely be best if the individuals were not only trusted but also didn’t know the others involved in the share. That way there is a smaller chance that these individuals could get together to put the key back together.
Also, if person A is the one holding the cipher text, even if the individuals did find each other they would only have a key and not be able to decode the actual texts.
I’m quite happy that I read the original article and I hope to do the same thing that the author did before I kick the bucket. I’m quite sure that there are other ways to do what Tarus and I wrote about and actual implementation will vary depending upon the individual, their technical level, and their personal privacy requirements. This problem, though, is one that deserves to be solved as more and more of our information is kept digitally.
Due to a bug in mod_ssl, the ability to remove TLS 1.0 (and only support TLS 1.1 and/or TLS 1.2) has not been available. The fix has now made it to CentOS 6 and you can now fine-tune your cryptographic protocols with ease.
Before the fix my /etc/httpd/conf.d/ssl.conf file had this line:
SSLProtocol all -SSLv2 -SSLv3
This allows all SSL protocols except SSLv2 and SSLv3 to be used with httpd. This isn’t a bad solution but there are a couple of sites that I’d prefer to further lock down by removing TLS 1.0 and TLS
1.2 1.1. With the fix now in mod_ssl my settings can now look like this:
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
…and I’ll only support TLS 1.2 and beyond. Of course doing this will significantly reduce the number of clients that can connect to my server. According to SSLLabs I’m blocking all IE users before IE 11, Android before 4.4.2, Java 7, and Firefox 24.2.0 ESR. But luckily I really don’t have a problem with any of these browsers for a couple of things I do so I’ll likely tighten up security there and leave my more public sites alone.
NSS and mod_nss for httpd wasn’t discussed because it’s not in use on my systems. it should be noted that mod_nss can be similarly configured as mod_ssl however mod_nss does not support TLS 1.2 and you’ll max out at TLS 1.1.