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.
In a couple of weeks (March 11th) the Fedora Security Team will be meeting in Washington, D.C. to hack on training, security fixes, and other issues. All Fedora contributors are welcome to stop by if you’re in the area.
All the information is available on the Security Team FAD 2016 wiki page. Please go there and RSVP!
I’ve been working on securing my postfix configuration to enforce certificate validation and encryption on some known, higher-volume, or more sensitive connections between SMTP servers (port 25).
On many of the connections I’ve setup for secure transport there have been no problems (assuming proper TLS certificates are used). Unfortunately Gmail™ has been a problem. Sometimes it verifies and validates the certificate and other times it doesn’t… for days.
After conferring with Google Security I believe I’ve come up with a solution. In my tls_policy file I’ve added the following:
gmail.com secure match=.google.com:google.com ciphers=high protocols=TLSv1.2
So far this is working
but I’ll continue to test.
If you run your own SMTP server and wish to maintain a secure connection with Gmail this is an easy way to enforce encryption as well as validate the certificate. Of course this doesn’t protect the message while it’s being stored on the server or workstation (or on Google’s internal network). To protect messages at rest (on a server) one should use GPG or S/MIME. Using both TLS over the network between servers and GPG or S/MIME is beneficial to provide protection of the messages going over the Internet.
This configuration is applicable with the OpenSSL version shipped with CentOS 6/RHEL 6. Implementing this on CentOS 7/RHEL7 or another flavor of Linux may require a different/better configuration.
The policy has been updated for CentOS 7/RHEL 7 which supports TLSv1.2 on Postfix. Other services can also be setup similarly:
google.com secure ciphers=high protocols=TLSv1.2 comcast.net secure ciphers=high protocols=TLSv1.2 verizon.net secure ciphers=high protocols=TLSv1.2 hotmail.com secure ciphers=high protocols=TLSv1.2
At the beginning of April, the Fedora Security Team (FST) started on a journey to close all critical and important CVEs in Fedora and EPEL that had originated in 2014 and before. Now that we’re two-thirds the way through I figured it would be a good time to see what we’ve accomplished so far.
Of the 38 CVEs (37 important and 1 critical) we originally identified: 14 have been closed, 1 is currently on QA, and 23 remain open. The 14 closed CVEs represent around a third of all the identified CVEs. So, not bad but also not great; there is still work to be done.
If you want to help get some of these CVEs cleaned up here’s a list of the target packages. We need to make sure that upstream has fixed the problem and that the packagers are pushing these fixes into the repos.
I hope to come back to you at the end of the month with a report on how all of the CVEs were fixed and who helped fix them!
Earlier this month the Fedora Security Team started a 90-day challenge to close all critical and important CVEs in Fedora that came out in 2014 and before. These bugs include packages affected in both Fedora and EPEL repositories. Since we started the process we’ve made some good progress.
Of the thirty-eight Important CVE bugs, six have been closed, three are on QA, and the rest are open. The one critical bug, rubygems-activesupport in EPEL, still remains but maybe fixed as early as this week.
Want to help? Please join us in helping make Fedora (and EPEL) and safer place and pitch in to help close these security bugs.
The Fedora Security Team (FST) has uncovered an interesting problem. Many packages in Fedora aren’t being actively maintained meaning they are unofficially orphaned. This is likely not a problem since at least some of these packages will happily sit there and be well behaved. The ones we worry about are the ones that pick up CVEs along the way, warning of unscrupulous behaviour.
The FST has been plugging away at trying to help maintainers update their packages when security flaws are known to exist. So far we’ve almost hit the 250 bug level. Unfortunately we forced a policy that still isn’t perfect. What do you do with a package that is no longer is supported and has a known vulnerability in it? Unless you can recruit someone to adopt the package the only responsible choice you have is to retire the package and remove it from the repositories.
This, of course, leads to other problems, specifically that someone has that package installed and they know not that the package is no longer supported nor do they know it contains a security vulnerability. This morning, during the FST meeting, we discussed the problem a bit and I had an idea that I’ll share here in hopes of starting a discussion.
Create a file containing all the packages that have been retired from a repository and perhaps a short reason for why this package has been retired. Then have yum/dnf consume this information regularly and notify the user/admin when a package that is installed is added to this list. This allows the system admin to become aware of the unsupported nature of the package and allows them to make a decision as to whether or not to keep the package on the system.