Archive

Archive for the ‘Security’ Category

A response to ‘Strong Encryption and Death’

2017-01-20 2 comments

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.”

–Tarus

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.

ssss

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.

Conclusion

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.

Fedora Security Team FAD 2016

2016-03-02 Leave a comment

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!

Securing email to Gmail

2015-12-22 3 comments

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.

Update

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

Encryption you don’t control is not a security feature

2015-09-23 Leave a comment

Catching up on my blog reading, this morning, led me to an article discussing Apple’s iMessage program and, specifically, the encryption it uses and how it’s implemented.  Go ahead and read the article; I’ll wait.

The TL;DR of that article is this: encryption you don’t control is not a security feature.  It’s great that Apple implemented encryption in their messaging software but since the user has no control over the implementation or the keys (especially the key distribution, management, and trust) users shouldn’t expect this type of encryption system to actually protect them.

For Apple, it’s all about UI and making it easy for the user.  In reality, what they’ve done is dumbed down the entire process and forced users to remain ignorant of their own security.  Many users applaud these types of “just make it work and make it pretty” interfaces but at the same time you end up with an uneducated user who doesn’t even realize that their data is at risk.  Honestly, it’s 2015… if you don’t understand information security… well, to quote my friend Larry “when you’re dumb, you suffer”.

Yes, that’s harsh.  But it’s time for people to wake up and take responsibility for their naked pictures or email messages being publicized.  I’m assuming most everyone makes at least a little effort toward physically securing their homes (e.g. locking doors and windows).  Why shouldn’t your data be any less protected?

In comparison, I’ll use Pidgin and OTR as an example of a better way to encrypt messaging systems.  OTR doesn’t use outside mechanisms for handling keys, it clearly displays whether or not a message is simply encrypted (untrusted) or whether you’ve verified the key, and it’s simple to use.

One thing I’ll say about Apple’s iMessage is that it at least starts to fix the problem.  I’d rather have ciphertext being sent across the network than plaintext.  Users just need to understand what the risks are and evaluate whether they are okay with those risks or not.

Fedora Security Team 90-Day Challenge to clean up vulnerabilities… an update

2015-05-29 Leave a comment

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.

  • ytnef
  • mediatomb
  • rubygem-httparty
  • rubygem-extlib
  • rubygem-crack
  • nagios
  • libmicrohttpd
  • directfb
  • nagios-plugins
  • dcmtk
  • sahana
  • opensaml-java
  • s3ql
  • tomcat
  • openstack-keystone
  • phpMemcachedAdmin

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!

Fedora Security Team’s 90-day Challenge

2015-04-23 Leave a comment

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.

For discussion: Orphaned package in Fedora

2015-03-26 8 comments

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.

The Idea

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.

Okay, discuss…

Categories: Fedora Project, Security