Hello, Lately with the new HIPAA HI Tech ruling going into affect clients are requiring us to send encrypted file attachments more frequently (on top of end-to-end SSL). In a pinch we have been using 7zip to create an self extracting encrypted zip. The problem we have been running into is the encrypted attachments are getting isolated by spam filters due to AV not able to scan the file. To circumvent this we have been sending the attachments via LiquidFiles. Is anything in the wheel house for the ability to encrypt the attachments during the upload process and add them to an encrypted container before sending to the recipient? Thanks, Chris
Johan Allard September 27, 2013 22:39 Chris, LiquidFiles sends files using HTML 5. There are no plugins. The only thing we have available in the browser that can process anything is JavaScript and encrypting bulk data with JavaScript would be horribly slow. When it comes to encryption, it's either encrypted or not. Encrypting things twice doesn't make it more secure so this requirement sounds strange. Can you send the details of the HIPAA ruling? If what you're really after is encrypting of data at rest, I would suggest implementing LiquidFiles with an encrypted filesystem instead: http://support.liquidfiles.net/entries/470279-Encrypted-Filesystem Fabian August 11, 2014 16:50 Hi I have just found LiquidFiles by accident, and it seems to be THE solution and even a not-so-expensive one. Concerning the above-mentioned question. I fully understand this requirement, would be great for us as well in this case: An employee sends some confidential file to a customer, this file should not be visible even to the IT, thus the file is automatically encrypted when stored in LiquidFiles Storage, e.g. by using the password provided to the customer. Would be really great if this is feasible, the workaround with creating an encrypted file for yourself doesn't really work (there are always "stupid" users). The solution with encrypted FS is ok, but does not prevent IT from seeing these files. Thanks Fabian
Johan Allard September 27, 2013 22:39 Chris, LiquidFiles sends files using HTML 5. There are no plugins. The only thing we have available in the browser that can process anything is JavaScript and encrypting bulk data with JavaScript would be horribly slow. When it comes to encryption, it's either encrypted or not. Encrypting things twice doesn't make it more secure so this requirement sounds strange. Can you send the details of the HIPAA ruling? If what you're really after is encrypting of data at rest, I would suggest implementing LiquidFiles with an encrypted filesystem instead: http://support.liquidfiles.net/entries/470279-Encrypted-Filesystem Fabian August 11, 2014 16:50 Hi I have just found LiquidFiles by accident, and it seems to be THE solution and even a not-so-expensive one. Concerning the above-mentioned question. I fully understand this requirement, would be great for us as well in this case: An employee sends some confidential file to a customer, this file should not be visible even to the IT, thus the file is automatically encrypted when stored in LiquidFiles Storage, e.g. by using the password provided to the customer. Would be really great if this is feasible, the workaround with creating an encrypted file for yourself doesn't really work (there are always "stupid" users). The solution with encrypted FS is ok, but does not prevent IT from seeing these files. Thanks Fabian
Johan Allard August 12, 2014 00:10 We aim to build things with real security, not perceived security. The purpose of encrypting a file before it hits the LiquidFiles server would roughly fall into these different categories: Prevent an attacker that has successfully gained root access from getting access to the data. Prevent the IT department from getting access to the data. In case something is wrong in the LiquidFiles access restrictions, prevent access to the data. Audit requirement. The technologies we have available to automatically encrypt data during uploads are: JavaScript The technologies we have available to automatically decrypt data during downloads are: None Even if it would technically be possible to use JavaScript to encrypt data on the fly it would be very, very slow. JavaScript is an interpreted language, running inside a browser. It was built to manipulate things on the screen, it was never intended to do bulk data encryption. So in practice, we cannot automatically encrypt data during uploads. JavaScript is also not available at the time a file is downloaded so automatic decryption is also not even technically possible. This means that what we would technically have to do is: perform the upload as it is now and store the data in a temporary area encrypt the data and store it in it's permanent location securely delete the temporary file and the encryption key If we aim to automatically decrypt the data before the data is downloaded, the above steps would have to be reversed. Now, if we go back and look at our attack vectors, in light of us wanting to build real security, not perceived security: If someone has root access, they can just as easily and automatically grab all the data from the temporary area in the time it takes to encrypt/decrypt the data. And if at any point the LiquidFiles server would have access to the encryption key, it would be safe to assume that so would an attacker with root access to the system. To the best of our knowledge. No attacker has ever been able to get root access since we started selling LiquidFiles. If you're worried about this. The best way to protect yourself is to limit access to ssh to a dedicated range of network addresses and treat the root password as very sensitive information only shared with the minimum amount of users. If the IT department wanted to. They could even more easily perform the same attack as an attacker with root access as they have legitimate root access. Building an access management system is much, much, much easier than building an encryption system and it's much, much, much easier to test access management. LiquidFiles gets audited all the time. Please make sure that you perform whatever tests you need to make sure you are comfortable that the access management is right. Unless you are an encryption expert with many years in the field, it's unlikely you would have been able to perform a meaningful audit of a similar encryption system. Audit requirement. The only real reason that this makes sense is if we drop the requirement that we want to build real security. We could build something to meet an audit requirement so that they could tick a box. But the audit requirement to encrypt data at rest would also be met with an encrypted filesystem. The biggest problem with building perceived security is that people perceive it as secure when it isn't. Now, you could argue that for an attacker or rouge IT staff member with root access, they would only be able to access new files. Not files that are already encrypted, which is a fair point. But if an IT staff member wanted to circument this requirement, they could have circumented this from day one, and if some attacker is clever enough to get root access to the system, they would likely be clever enough to cover their tracks and retain access for a long time. And if we at any pointed wanted to perform automatic decryption, the LiquidFiles system would need access to the encryption key and in that case it would be like locking the safe and leaving the key in the door. If the encryption key is stored on the LiquidFiles system, a rouge IT staff member or an attacker with root access would be able to retreive any encryption key. So the only real secure way of building this would be to perform the encryption outside of the LiquidFiles server. We have an Outlook plugin and Windows Agent, and more platforms on the way so using the Outlook plugin would be one way of encrypting the data outside of the LiquidFiles server, and we may add this at some point. The next challenge is encrypted data transport. The first thing that springs to mind is encrypted zip files, which is a good option with wide platform support. But an individual file within a zip file cannot be larger than 2Gb and LiquidFiles supports unlimited file size. Of the top of my mind, I cannot think of another widely supported transport mechanism for encrypted data that supports unlimited file size, but we could enable this feature for files less than 2Gb to make it as easy to use as possible. Or we would have to build our own. With LiquidFiles target market, the overwhelmingly majority of customers use Windows so we could make this a Windows to Windows only feature to cover the majority, and extend to Macs further down the line. But it's unlikely that we'll ever get to a point where we could get anywhere near the wide platform support that zip has. The next challenge once we have encrypted the data is to transport the encryption key. To get a secure encryption key aiming for 128 bit+ entropy, this would be 22 characters of randomized characters a-z, A-Z, 0-9 looking something like this: qX0ZgQ6EOAlnocnJ5mcCFz. This key would have to be sent to the recipient or recipients in a way to protect against the attack vectors above, which basically means that we cannot use the Internet (including fixed phone lines which in all modern companies use IP telephony, at least internally) as we would have to assume that an attacker with root access to one system would likely have achieved root access on other systems and ability to sniff network traffic, and any rouge IT staff would surely target other systems such as email just as they would the LiquidFiles system. So the only practical method of transport is the encryption key would be to send a SMS, which would mean typing a key like the one above manually on the phone keyboard, and by each recipient back on a keyboard. Obviously you can already now use something like encrypted zip files to send encrypted data (less than 2Gb in size) and send the (long random) encryption key in an SMS to the recipients, and if you're really worried about the attack vectors described, that would be the recommended option. But Fabians comment about "stupid users" would in reality make this almost unworkable in real life, regardless if this is added to the Outlook plugin, or used separately with encrypted zip files. As you can see from this very generic description of the problem. Encrypting individual files is hard if we're aiming for real security. And as you can also see, there's nothing LiquidFiles specific about these problems. Any vendor looking to undertake this would have to solve this problem and if they claim that they have, ask them how. It's likely that even a non-security professional will be able to poke holes in the architecture with any form of automatic encryption method. In almost all cases: automation != security. What will happen though in the next major release of LiquidFiles (v2.5) is that we will introduce a User Admin level (we're always looking to improve LiquidFiles both from a useability and security level). A User Admin is an admin that doesn't have access to the data. Interestingly enough, some organisations wants the complete opposite - they want to ensure admins have access to all the data sent so that they can audit that the staff member is not sending any data they shouldn't. So more access and less access - both in the name of security. With the User Admin level though, you will largely be able to achieve both, or at least limit the exposure by not having all admins access tot he data. If we ever figure out an easy to use, secure way to do this automatically, it will be added to LiquidFiles. The biggest hope at this point would be either as an extension to HTML5 or in the next version after HTML5, but I haven't seen anything in terms of anything close to this being added to the standard.
Fabian August 12, 2014 07:26 Johan, thanks for this very comprehensive answer. I see your points, 100% security is not realistic anyway. With a User Admin the main issue is solved for me. Thus we still have the advantage that someone could check which files are sent ... So, just need to find some Budget and it will be purchased. Ville Kanninen September 23, 2015 07:59 Hi! What do you think about Owncloud's file encryption on fly method (https://owncloud.com/wp-content/uploads/2014/10/Overview_of_ownCloud_Encryption_Model_1.1.pdf)? Would it be possible to implement this kind of solution on Liquid Files too? Johan Allard September 23, 2015 08:36 From the looks of it, this is not "on the fly" encryption. What they outline is just how they encrypt the files ones they are uploaded, which quite frankly is the easy part, and there's just a remark that it's possible to integrate into future client side encryption. What this means, reading between the lines, is that all files are still accepted unencrypted and then encrypted on the server. When they are requested for download, the file must be decrypted before a browser can download it. This means that all the fancy encryption of file keys and stuff will just be side stepped and an attacker (or rogue admin) can just take the file before it's been encrypted, or after it's been decrypted. If/when we build something, it needs to be in such a way that it's never stored unencrypted on the server or you don't add real security.
