Google, where is the confidentiality in Chrome OS?

Ask an information security expert what the three cornerstones of information security are, and s/he should tell you, Confidentiality, Integrity, and Availability. Google will tell you that Chromebooks are some of the most secure consumer computers available today. How well do they really do?

Integrity

ChromeOS and the hardware specification that Google put out for Chromebooks (specifically around firmware changes) have done a decent job of improving the Integrity of the system. Kernel signing and OS signing (a cryptographic signature on the binary files) goes a long way to stopping malicious root kits.

Of course it also goes a long way to preventing people from messing with the system too. But that would be flexibility, which isn't an underlying principle of information security. Besides, Google gave us developer mode to allow for flexibility. So, you can mess with the system if you want to.

But, what about the application software? Well, that is all managed through the Google Play app store. If Google is managing the ChromeOS app store as well as they are the Android app store, then the integrity of the system has fallen back to be on-par with any other operating system as far as end-user application security goes. And since, by far, the majority of 21st century malicious software is targeting the user at the application layer, not the OS layer, Google has largely missed the boat.

Want to fix this? Take a look at how Apple does things with their app store. Every app is rigorously tested and questioned. Application functionality is tested by Apple's own quality assurance staff and bad applications are rejected. The need for access to system resources (even non-traditional resources like your address book) are questioned and must be justified with actual needs of the application before it gets approved.

Does Google do this? I don't actually know. But I do know that on my Google Phone applications are given a lot more access to things that it makes no sense they should need.

Integrity score: marginally above average.

Availability

Google may argue that they have provided availability too because your system is tied to your Google account and your files get written there if you lose access to your Chromebook for some reason. As long as the Chromebook can work entirely offline, it does provide availability.

It also provides Google with a guaranteed source of valuable information about you that they can use to direct ads that target you specifically. In case you didn't know, advertisers pay a premium for targeted advertisings. Of course, those ads are also what pays for all the google services.

Mind you, the exact same thing is true for Windows users that have a OneDrive account, Apple users that have a iCloud account, and anyone who has bothered to set-up and religiously use any of the plethora of cloud storage providers (Dropbox, Box.net, SugarSync, and a host more).

Availability score: average.

Confidentiality

But, those ads are not what pays for the Chromebook. We, the consumers, pay for our Chromebooks. And, at least some of us, expect to have a high degree of that last tenant of information security: confidentiality. This, Google throws completely out the window. The problem is, information is not secure unless there is a balance of all three.

Google has taken away all the confidentiality. Oh sure, they will say they keep your data private. Except they don't. Their deep content inspection tools dig through it and figure things out about you.  Then they share what they learned with advertisers in the form of targeting ads. Except those things they learned about you they wouldn't know if they had proper confidentiality. Just because it isn't a human looking through your private documents doesn't mean it isn't a loss of confidentiality.

And, while people in the USA are stuck with all sorts of laws that required companies to reveal data on request (sometimes with a court order, sometimes with a warrant, sometimes accompanied by a gag order), may of us don't live in the USA and shouldn't have our data exposed to their laws when we aren't in that country. We have our own mandatory disclosure laws. Yet everyone is stuck with their data being exposed to a foreign government's scrutiny whether they consider this important or not.

Confidentiality score: below average.

Solution

Sadly, Google could very easily fix this. And should have fixed it from the start. Google has had plenty of time to fix it and yet still haven't. In only requires 2 modifications to ChromeOS using existing and available software:

1. Bring back local user authentication. Linux has it built in and ChromeOS is Linux at the core.
2. Implement client side file encryption. These exists this wonderful tool available for Linux (and Windows and OS X and a bunch of other operating systems) called encfs (encrypted filesystem).

Hopefully everyone knows about local user authentication since every modern desktop operating system except for ChromeOS had it built in and uses it by default. So, I won't go into detail about it.

On the other hand, some people may not be aware of EncFS, which stands for Encrypted Filesystem. It works in conjunction with another strange thing called FUSE (which stands for filesystem in user space). Together this pair of tools do something really useful for confidentiality of data. They let you read and write files in one directory just like you normally would but they store those files in an encrypted form in another directory.

Why is this so good? Well, it means that your files are not available for deep content inspection by Google. So Google will probably never implement this too. It also means that if the files you store on your Google Drive slip out to the whole world (like say you accidentally choose to make them public) nobody else can see them because they don't have the encryption key.

At first glance, this does look to be a problem because it means you can't access your files except from your Chromebook. Except, of course, as was said earlier, EncFS is available on pretty much all of the common operating systems in use today.

It wouldn't be all that difficult for a decent programmer to implement an EncFS plugin for Chrome (the web browser) that would do the file decryption client side and encrypt it before sending it back to Google for long term storage.

Admittedly this last part takes a bit of effort but Google should probably make the use of client side encryption optional anyway. Encryption is one of those trade-offs between two of the principles of information security. You give up availability to get more confidentiality.

Conclusion

In my opinion, Google has violated their motto. Or at least the motto they used to have, "Do no evil". Google, if you read this realize that I consider your actions evil.

I have been looking at Chromebooks for a long time and I've been wanting one for years. I will not buy one so long as I must use a Google account in order to use it.

P.S. It would also make my Google account considerably less secure since my password is a 32 character randomly generated password. It should be as difficult to guess as brute force cracking AES256 encryption. I can't memorize it. So, to use a Chromebook I would need to considerably reduce the security of my Google account. And, no, two-factor authentication the google way is not an option because I regularly run the battery down to zero on my cell phone.

Chrome OS and Chromebooks may have made a marginal improvement in the integrity of the core operating system but it was done at the near complete expense of confidentiality and with a loss of flexibility.

Post-Script

If you really want to impress me, Google, take a note from they way Apple manages the shared keychain access across device and use per-device PKI (like PGP or SMIME), to transfer the encryption key between ChromeOS and Chrome browsers installed on all my other systems so that I don't have to worry about losing the key as long as I remember the passphrase I use to lock it. You could even do a proper secure key escrow with that.

And, in the name of flexibility, give me a way to put my own validation key into the firmware of the Chromebook (alongside yours) so I can install my own, custom, OS without having the scary developer mode warning show up. But please do it in a way that hobbyists and small open source developers can reasonably afford to make use it.

Secure Cloud Storage

Google will tell you that Drive is secure. Dropbox will tell you their service is secure. Microsoft tells us that OneDrive is secure. Amazon tells their clients that S3 is secure. Everyone tells us that the cloud storage they give us is secure. But what does that really mean?

For the most part it means that the data might be encrypted at rest (many cloud storage providers tell us this), that you need to authenticate to get access to the data, and that the data is backed-up. And, they are right up to a point.

What they aren't telling us, except for one provider (as far as I know), is that our data is not protected from the cloud storage provider itself. As in: the staff and applications of the cloud provider are able to read out files without us know (although in the case of staff it is probably very limited and requires significant effort).

Google basically admits this in their EULA where they tell us that they will use the content of our files (and e-mails) to help choose ads that are more suited to us. Microsoft claims that they can't see our files because they are encrypted using our login password (or they used to) but I bet there is a way to recover our password if we forgot it (which means they must be able to decrypt the files without our password being entered. The others vary between these two points.

Why does this matter?

For starters, you might want to use the cloud storage to back up sensitive information that you don't want to lose in case your computer hard drive crashes. Say, for example your financial records. Or, for many of us, that huge list of passwords for all the different websites, forums, and online services we all use now. Maybe you are a private type of person who feels uncomfortable knowing that other people might be able to look at your files. There could be files of a personal nature you don't want to get out, even accidentally. 

The point is, there are a lot of very legitimate reasons why a person would want cloud storage and not want the cloud provider to ever have access to those files. Even if it means you might lose access to those files yourself.

The big question is how do we protect our data when it is not on systems entirely under our control? The obvious answer is simple. We encrypt it on systems that are under our control before sending it away. To keep things convenient we really want to have this happen in a way that is transparent, or nearly transparent to us.

Just like cloud storage, we want to write a file to a directory and let some program that runs in the background encrypt it before it gets sent away for safe keeping.

What can we do?

Once upon a time, a long time ago, a smart person with a strong understanding of encryption created a tool called Truecrypt. He created it to solve a different problem. He wanted to be sure that if his laptop got stolen, people couldn't get access to his data. He wasn't worried as much about cloud storage. At least that is what he said. 

Much of the world saw value in Truecrypt and started using it. Many of us saw value in it beyond keeping our laptops safe should they get stolen. We saw it as a way to pass large files to other people securely. We saw it as a way to be sure our files could not be looked at even when they were placed in cloud storage. We liked this too. We trusted this tool.

Unfortunately, the author(s) of Truecrypt decided it was no longer needed and they abruptly shut down the project. The shutdown was so abrupt that many people don't believe the reasons given by the authors of the software. But, they gave a reason. The reason was simple, operating systems now have built-in disk encryption. So, they don't need to maintain Truecrypt and they stopped.

Truecrypt was never an ideal solution for cloud storage. It needed big files to be useful. You put your little files in the big files to keep them safe. This meant a lot of data has to go to the cloud storage provider and come back every time one little file changes (except in the case of Dropbox).

In any case, Truecrypt is no longer supported. There are some alternatives. VeraCrypt and CipherShed have both taken the last public release of the source code to Truecrypt and begun making their own changes and improvements. But, Truecrypt was never ideal for cloud storage because of that big file problem.

Encrypted File System (encfs)

There is this obscure tool that came out in the Linux world around the same time as Truecrypt. It was unstable, unproven, and only worked on Linux at the time. But, it had one major advantage over Truecrypt. It worked at the file level. That is, it encrypts each file separately. So, when the cloud sync happens, it only needs to send the files that actually changed.

EncFS has improved since then. It is now up to version 1.7 on Linux and we are starting to see some effort in getting it to common operating systems in a reliable and consistent manner. The user interface is still ugly. The tools for Windows and OSX are still pretty sparse and buggy but it looks like it is coming.

At the time of this writing there are a couple of Windows and OSX ports worth keeping an eye on:

• Safe (www.getsafe.org) has both Windows and OSX support but seams unstable
• EncFSmp (http://sourceforge.net/projects/encfsmp/?source=directory) supports both Windows and OSX. It appears to be a bit more stable than Safe, is still in Beta, and has a few growing pains to work out with the UI. This is the one I'm currently using.
• OSXFUSE is an implementation of another Linux tool for OSX. FUSE is the tool that encfs was built to use (Safe and EncFSmp appear to have replaced FUSE functionality with alternatives built into Windows and OSX). While there is an OSX FUSE supported encfs, it requires that  you build it yourself.
• Encfs4Win is an experimental port of encfs on Windows that requires fuse4win and is Windows only.

One very important thing to keep in mind if using encfs is that the encryption key is derived from the password you set. This means that the encryption is only as good as the password is complicated. Explaining this can get a bit complicated so here is a simple example:

A one word password taking from the words you know can be guessed by a modern desktop in under 10 seconds.

A password that is 8 characters long and randomly generated using printable characters can be guessed by a modern desktop computer in under 5 minutes. This is about on par with an old encryption algorithm from the 1970's called DES. It is not supposed to be used anymore.

A password that is 16 characters long and randomly generated using printable characters is as complicated as the keys used for AES (the replacement for DES) created in the 1990's. This is still considered acceptable for use today by governments and banks. It is probably good enough for us.

A password that is 32 characters long and randomly generated is as good as AES 256 encryption keys. This is as strong as encfs gets when put in paranoid mode. Odds are it will take a determined government months, or years, to crack this type of encryption key.

The problems with the usable passwords (above) is that most people won't be able to memories them and who in their right mind wants to type 16 (or even 32) characters at a password prompt.

If you aren't trying to prevent people who have access to your computer (or laptop) from seeing the encrypted files, you can keep the password in a text file to cut-and-paste it into the password prompt for encfs. Even better, EncFSmp conveniently saves the password so you don't have to keep entering it.

As to how you generate such an ugly complicated password. That is up to you. I use a tool (that runs on both OSX and Window) called KeePass. Conveniently, it also stores the passwords in a secure way.