Ask Slashdot: How Would You Implement Site-Wide File Encryption?
Recently-leaked CIA documents prove that encryption works, according to the Associated Press. But how should sys-admins implement site-wide file encryption? Very-long-time Slashdot reader Pig Hogger writes:
If you decide to implement server-level encryption across all your servers, how do you manage the necessary keys/passwords/passphrases to insure that you have both maximum uptime (you can access your data if you need to reboot your servers), yet that the keys cannot be compromised... What are established practices to address this issue?
Keep in mind that you can't change your password once the server's been seized, bringing up the issue of how many people know that password. Or is there a better solution? Share you suggestions and experiences in the comments. How would you implement site-wide file encryption?
Keep in mind that you can't change your password once the server's been seized, bringing up the issue of how many people know that password. Or is there a better solution? Share you suggestions and experiences in the comments. How would you implement site-wide file encryption?
I wish that someone would develop a version of raid for use with servers. Have 3 VPSs in Switzerland, Russia and Holland and each one gets only a 3rd of each file. The chances of any government seizing all 3 is zero.
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
The choices include encrypting files (tar/gz/bz archives), directories, whole user directories, whole physical volumes, whole logical volumes, etc. One large enrypted volume means single point of failure: One key/password gives access to every file. More divisions means more keys/passwords, but less access if one is compromised. Therefore, server level encryption is appropriate if one person is responsible for the entire contents on the server(s).
227-3517
- Linux servers
- LUKS full-disk encryption
- All network traffic tunneled tunneled through some form of SSL (e.g. SSH or OpenVPN) with client authentication, and a decent IDS.
- Tiny custom binary in the initramfs that loads the "password" (a random 1024 bit binary string) from a USB serial device
- BIOS boot options locked down (no removable media boot, password required to change settings)
- Arduino with 6x AA batteries for power backup, a 3-axis accelerometer/gyro, an ambient light sensor & the sensor from an optical mouse, riveted to the inside of the chassis' outer shell, with a small hole in the bottom of the case for the optical sensor.
- As long as the Arduino is undisturbed (i.e. registers no movement or sudden change in lighting level) it will provide the decryption key on request, so the server can boot up unattended.
- As soon as the Arduino registers a disturbance (e.g. somebody moves or opens the computer case to reset the BIOS) it wipes the key from RAM and for the next boot you need to fetch a non-volatile copy of the key from a safety deposit box.
You can seize the servers, but by doing so you effectively render the data inaccessible, and nobody's going to remember the random 1024-bit binary string you need to decrypt one of them.
boring shit must be encrypted to be protected, boring shit like customers data from hackers, company documents from competition, etc.. etc...
Why would you want to encrypt the entire filesystem, there isn't anything of interest in /usr/bin or other standard system directories.
Encrypt /home , /var and wherever else you have sensitive data. the decryption key should be kept on a off-site server that hands your init.d script (or system.d whatever you are using) the key once it passes a IP address lookup and ssh authentication. If moved off site, the servers will not be able to receive the decryption key because the ip's won't match (you could simply drop connections from anywhere but your ip-block straight from iptables or do something more granular) or you could just shut off the authentication server alltogether
Your company may be 100% legit but that does not mean that your expectation of privacy is 0%. I would not trust unknown government agencies with my data regardless of how legit it is. I would find it easier to trust the mafia, at least their intentions are clear.
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
If you decide to implement server-level encryption across all your servers,
This is basically simple you can build a server that does all encryption in ram, meaning the OS is loaded once then the encryption key is used to have it decrypt the content for the outside.
To stop tempering you could setup such a server yourself and equip it with various sensors that detect presence of people or tempering, and if detected it could shut down not compromising the encryption key to forensics.
Firewire(because of its DMA) needs to be disabled and unkown devices need to trigger a shut down event and must otherwise be ignored
con:
However this type of server would still emit the key data as radio spectrum.
con2:
The requesters question is quite sketchy, I suggest writting a specification first with the neccessary "must haves" and possible use cases.
my iscsi-encryption approach
So I can only explain my private approach, I got a root server with big harddrives and those harddrives are exported via iscsi that iscsi-connection is tunneled through ssh.
I de-/encrypt & mount the drives only on my home server and sync the directories with rsync. The harddrives are double encrypted meaning I have two encryption devices and two dependend keys.
This sounds slow, but it isn't I get nearly the full upload bandwith of my connection.
Meaning my root server never "knows" what data is backed up on it - its a "dumb" server
I would suggest a similar approach for the requesters situation, because it solves a first step, separating the encryption key from the encrypted data.
And a second step having two encryption keys making it more difficult to get all two if separated (which is contrary to my use case)
I would expand my approach there to have a "data" server, a level1 encryption server and a level2 encryption server.
level1 decryptes the first encryption layer and level2 does it with the data provided by level1
Usecase:
If only the data server is seized, shut down at least one of the intermediate servers along with its key and the data is inaccessible. And it doesn't matter which "key keeper" server you kill, its a fail-one-fail-all system.
The drawback is however the level2 encryption server shall not be compromised, because there all pure data is accessible.
encrypted backup
With todays highspeed connectivity the servers can be backed up by just cloning the harddrives over iscsi for example, that works quite well.
another idea
Most encryption providers from linux and bsd provide the possiblity of having more than one master key.
Iscsi can also work on image files so you can provide many independed iscsi-volumes and encrpytion can be outsourced to the users computers.
Its biggest issue is to my knowledge it omly works with windows, but for making life had for leakers this is probably the best bet. When you open documents your computer requests the key for ad, the benefit here is if the user cant connect to AD (i.e. They are at home) the whole process wont work. You can also define users who can decrypt data before emailing if they do meed to share the info. It works well as long as you are tied to the windows ecosystem.
Implement a blind-password vault. To access data, everyone supplies the vault password. This password, however, does not decrypt data. The vault retains a randomly generated key and the vault software retrieves and decrypts the file. If data is stolen, even those with passwords cannot access it. Further, the vault keys can be backuped and restored on-demand.
If you want your files encrypted 'at rest' so that if someone comes and pulls your HDD (or software equivalent) then you can implement a strategy similar to:
(a)Encrypt all content with individual symmetric keys (one key per piece of content) - prefix each piece of content with a key ID (for key lookup on exit) - there are many ways to associate content with a key - prefixing is just the simplest
(b)Encrypt those keys (which you'll need stored locally for performance reasons) with a randomly generated one-time pad stored on a removable hardware device (HSM/USB for example)
(c)Decrypt files as appropriate as they exit your webserver - observe the key ID of the content, ask a process on your machine to give you the symmetric key for that ID, decrypt the content, send it back to the requesting connection.
Don't store the master key and/or one time pad locally, simply have a daemon/service/long running process on your web server require (at startup) you to plugin your hardware device (e.g. read a file from a mount that is only there when you plug the thing in.) This means that stealing the content doesn't do them much good (if they crack a key it's only for that particular piece of content, they'll have to crack lots of keys), and if they get the locally stored symmetric key file it doesn't do them much good either because you're protecting that with a VERY strong key and/or cipher which is stored air-gapped - they'd have to not only steal all the files involved, they'd have to inject into the service/daemon that issues symmetric keys.
This type of approach has performance implications of course, and to make it truly close to unbreakable requires more specifics (process injection prevention, signing and impersonation attack prevention, both on the key request side and the service/daemon unlocking scheme, et cetera) - this would be quite a discouraging system to attempt to break.
My $0.02, YMMV
Loading...
Put it behind 7 proxies. I hear that works. https://m.youtube.com/results?...
Hire someone who knows what they are doing. Seriously, if this is for a business, there are lots of complex issues with compliance and audits in addition to availability and the possibility of sabotage. And this causes enough work that you'll probably need to hire someone anyway, so it might as well be someone who knows this stuff.
Dealing with those requires experience. And the very first thing you need to come to terms with is: what risks are you actually trying to protect against? What tradeoffs are you willing to make and what risks (mainly of data loss) are you willing to accept? How much are you willing to spend on this?
... or any other personal confidential data. Or maybe company IP. There's a pretty broad legal use-case if you think about it.
"Consensus" in science is _always_ a political construct.
I would tell them to use encryption for everything all the time or they would be beaten like a rented mule. Then I would randomly beat an employee or two just to drive home the point.
Note that the directive would apply to ALL communication, including asking a coworker where he/she wanted to go to lunch. For example:
Coworker #1: "aZqk jhwf89 489c32r8934 hfh7 246eg6sd17?"
Coworker #2: "KSJED894nc&HE#%32jhdi."
Coworker #1: "$R^WJFC8ewm4f8u(Y3em90r4c987!!"
Just cruising through this digital world at 33 1/3 rpm...
While encryption itself is an issue to be worked out, the real question is key/encryption password management: How do you keep the keys off of a server that you worry about being stolen or physically compromised? Specialized hardware exists specifically for this. There are network versions of hardware security modules and you would put one of these in a secure location, apart from your server, but available to your server over a network so if you need to restart the server, it can access its encryption keys (probably with human intervention on the HSM side.)
HSM equipment comes in all sorts of shapes and sizes with the smallest being the chip in your credit card or a TPM chip in your laptop, to big ones which are rack mounted and require multiple key cards to activate.
The fact you mention disk passwords leads me to believe that you are familiar with consumer grade encryption, but probably not enterprise grade encryption management. Microsoft offers some good tools for this, so do many of the other security vendors. Most of these tools have complex, rolling recovery keys for whole disk encryption and assigned users are still able to log in with their normal AD, but you can go the route of additional factors or ways of protecting the identities. If you have need of an additional layer item level file encryption goes a very long way of securing email and documents that might be sensitive. That said, you have to equally protect the user accounts that can decrypt the system with tools like Privileged Access Management, Additional login Factors and threat detection tools. I'd suggest hiring an expert for this endeavor, it's pretty specialized and if you get it wrong, you only make it harder to manage, not more secure. Consulting organizations do this all the time, and depending on what you need, it doesn't have to be insanely expensive.
I really wouldn't want to ever implement and manage WinRM site-wide though until it was super mature.
Some kind of key management fuckup and you're left with a pile of encrypted gibberish.
Do what CryptoLocker did - bots can do the site-wide encryption. Have triggers on servers and local devices, as needed. You can pick the type of files to encrypt, which cryptography to use, and where to store the key(s) - hopefully in a safe place off site. Users will be the most vulnerable part of the process. They have to be clear about the techniques to access and save the files. Which brings to mind another can of worms...
The problem with encryption software is that most of it isn't designed to be centrally managed. I am an OpenBSD user and I use full disk encryption which is slick as owl shit but there is no way to centrally manage, say, several OpenBSD machines. In order to change the passphrase or key I have to go to each and every machine. There are some commercially available software packages that will implement central management tools but I do not trust them. When it comes to encryption, if I cannot see the source code, I do not trust it.
Thanks to everyone who took the time to suggest their ideas. — OP
What type of attack is being mitigated against and how does the risk of failure of the encryption solution compare to that of the attack vector? There are many ways encryption can fail, including loss of keys or too much exposure to the passwords for these keys.
For example, are we talking about hardware theft or software based intrusion?
For hardware theft, then you would probably want to find a solution where no one needs to know the keys, but it is part of the local infrastructure. This would mean that once hardware is taken out of said infrastructure then it can't access the keys it needs to make sense of the data. Just like anything there are still scenarios where this could fail or be a hinderance.
For software there are so many variables and use cases, I am not going to try to list them, but remember there are both internal vectors of attack and external vectors of attack. Sometimes the hardest one to defend against is social engineering.
Jumpstart the tartan drive.
Just one word: Tahoe-LAFS. Deploy, use, relax.
cpghost at Cordula's Web.
I see a number of good ideas already for home-brew solutions so here's one for an enterprise out of the box solution. (usual crypto caveats apply, if you don't build it yourself, how do you know there's no backdoors... otoh, if you do build it yourself, assuming your not Bruce Schneier, how do you know you got it right? Take as directed, evaluate your risks before using)
I've had good success with Gemalto's protectfile product in this space. The NAE device handles the master key storage, temporal keys are stored in the device driver, encrypted by the master key. Accesses can be controlled by user through any of the usual authentication mechanisms, including saying "This is my backups user, it can read only encrypted data" which is a nice feature I don't see often enough on enterprise level encryption. Saves me from having to trust the sketchy encryption on the backup solution which is almost always backed by the "trust us" guarantee.
Min
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
So in other words, you have nothing? Thanks.
A realistic threat model based on bad laws, the easily observed security/terrorism hysteria that drives them, the steady stream of fear-porn ("news") making that worse, and the (minimal) lack of naivete it takes to know that governments always abuse extraordinary new secret powers (seriously, read any decent history book about the 20th century) ... that is NOT "nothing". That's an honest assessment of the environment in which you operate.
There's a reason so many businesses have become more nervous about operating in the US ever since Snowden made it much harder to be in denial (and before him, that's what it was - denial). In the past you'd have to really do something suspicious to get that kind of attention as a "person of interest", to cause them to bother with you. It just wasn't cost-effective to apply widespread surveillance. Now it's easy and cheap to spy on everybody.
So what are you arguing against, really? Taking technical measures against an event that might not happen? Isn't it better to make reasonable preparations and wind up not needing them? Isn't that better than later wishing you had? Does the way other people configure their systems really bother you enough to speak out against it? Or were you one of those people in denial, and now you're uncomfortable because people are openly talking about how they won't be joining you?
Having no evidence because the courts refuse to allow subpoenas for records is hardly the same thing as there being no evidence in existence. Just look at all the things that we learned when Snowden leaked all those documents, much of that had been considered conspiracy theory stuff by many people.
Now, if the courts would allow subpoenas and there was still no evidence, that's the time when we should be considering the possibility that there just hasn't been any abuse. But, given that things like NSL are subject to a gag order and much of this is happening in secret proceedings, we can safely assume that it's being abused as there's no sunshine to disinfect the proceedings.
The relevant question is whether it's being abused a little bit or a lot.
The best solution is simply ZFS with encryption which is live now. Or VERY soon. Easy peasy. Everything is convoluted, difficult, and will end in tears.
14 years and a solid v4.2 on the SDK ... what exactly is your definition of mature? Microsoft's big failure wrt RMS is their inability to automate roll-outs. It is way too painful to get set up the first time, but once you have done it a few times, it can be done on a demo network in less than 4 hours. RMS is the only solution that covers your entire corporate data and security stack from authentication to network transport to data-at-rest. Adoption success rate is less than stellar though, not inherently because of the product but because IT shops have a tendency to apply controls beyond those necessary. RMS allows an IT shop to do to your entire network what they normally do to a SharePoint server: lock it down until it is useless.
Disclaimer: I am the author of the following projects. At Red Hat, we have been researching this problem for the last few years. This has resulted in the creation of the Clevis[1] & Tang[2] projects for automating decryption. This currently ships in Fedora and we plan to ship it in a future RHEL release. This project currently supports both root volumes and removable storage, as well as any other data you want to encrypt and then automatically decrypt. We are working on adding support for non-root volumes as well. For a video on the problem of automated decryption and the architecture of Clevis & Tang, see my recent talk at FOSDEM: Securing Automated Decryption[3]. [1]: https://github.com/latchset/cl... [2]: https://github.com/latchset/ta... [3]: https://fosdem.org/2017/schedu...
[...] because the Deep State is not telling and refuses oversight [...]
You mean the "Deep State" that Trump accused of wiretapping his personal communications at Trump Tower? Let's think about... If the wiretap was true, the FBI was doing it illegally on Obama's orders or Trump implicated himself in a criminal investigation authorized by the courts. Everyone is denying that the wiretap and Trump is refusing to provide evidence. That's quite a pickle barrel for Trump to put himself in. Eight weeks into his administration, he's already on his tenth golf game for the year.
Don't hijack this. It's not about Trump, Obama, Bush, Clinton, Republicans, Democrats.... It's about the whole damned captured establishment.
Prove anything by multiplying Huge Number times Tiny Number
You wanted "a version of raid for use with servers".
Which is exactly what DRBD and Mars datablock devices are doing.
But they only to RAID1 (replication) accross servers.
For RAID5/6 (1/2 parity out of N-total) isn't supported yet by any direct approach.
Doing software RAID5/6 over iSCSI seems the closest doable with current technologies.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I'm not hijacking anything. You made a comment about the so called "Deep State" and I replied to that comment with the most obvious reference that I know of. The only "Deep State" that exist is in the minds of delusional people in the White House. Until the Trump Administration came along, I've never heard of the term "Deep State" before.
Its their web, the world wide wiretap. From a smart phone to a Room 641A https://en.wikipedia.org/wiki/...
So be aware of how the security services seek out your data.
The NSA and GCHQ will try and add their hardware your hardware as a brand imports hardware.
One at a hardware level in a company any network belongs to the security services.
CIA, MI5 also understand the human dimension. Social engineering or a new relationship, new staff.
The amazing new friend, skilled new staff member, potential client who wants a site tour.
Expect devices that will be part of the existing hardware (smart phone) and will pass any expected network usage detection efforts. The security services will alter your hotels networked TV. Staff will have their smart phone, tablet, computer packed with gov malware.
Data might be stored locally for another human to pick up. No use of any network to remove data. The hardware might be altered by a human and then a network is used to collect later. So not always expect to see a new unexpected upload. A human might place the malware and then collect any results. No litter to find.
So a company watching its networks and devices might not see any network changes at all or just "expected" user/staff data going out later.
How to keep your patents ideas, inventions, banking, designs secure from the USA and UK?
Use a one time pad for that very important message. Don't reuse the one time pad code, consider sending staff out to deliver an important message in person.
Only use the internet network for reaching consumers. Don't allow smart phones or other devices near advanced product development.
Be aware of offers of random friendship at a gym, bar, club, art gallery, business or sports event, cult, faith by very friendly strangers.
The distraction could be used to add malware to your smartphone physically so no network trace will show any changes in usage.
Secure your internet servers that interact with consumers to the best new standards that users can still access.
Get any emerging product work away from computers, return to paper and secure face to face meetings for creative ideas.
Don't allow smart phones or watch devices to secure meetings.
Keep all new friends or random staff with consumer electronics from wondering around any secure areas.
Once all that is in place and working, get your legal team ready for a NSL. Understand that a lot of malware can be networked or can be entered by a human.
Domestic spying is now "Benign Information Gathering"
I guess you did not read the message at the top of the Wikipedia page "This article or section might be slanted towards recent events. Please try to keep recent events in historical perspective. (February 2017)"
Try this from three years ago: http://billmoyers.com/2014/02/...
Yes, the current administration is completely delusional. But so is the opposition, which previously was happy to give power to the Leviathan without considering what would happen if that power were to fall into the hands of less congenial folk.
It is telling that you only heard about the Deep State once Trump came along.
Prove anything by multiplying Huge Number times Tiny Number
It is telling that you only heard about the Deep State once Trump came along.
Not even my lily white, tea party-loving relatives in Idaho knew what the "Deep State" was. They send me all kinds of clippings from the right wing echo chamber. If they had heard about the "Deep State" I would have known — and laughed. Thank God I live in California!
I'd like to suggest something like trevisor, a hypervisor for a single guest VM. Where the user enters a passphrase on boot, and the encryption keys are only stored in debug registers. Though this probably needs some additional work to be production ready.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
I sincerely hope you recognize that you also live in an echo chamber.
Prove anything by multiplying Huge Number times Tiny Number
Just turn off all IPD/IDS, firewall and anti-virus. In an hour or so the ransomware should have the entire site thoroughly encrypted.
Protoplasm. Quiet Protoplasm. I like quiet protoplasm.
I sincerely hope you recognize that you also live in an echo chamber.
So say we all.
Enforce encryption client-side. Server just hosts encrypted files and has no way to decipher them.
If this is for a serious business and you need to ask /. how it is done then back the fuck away from the keyboard and hire someone that understands this or you will be walking into a world of pain. First check what you are really doing justifies encryption, remembering encryption does not protect you from people installing malware, people social engineering access, unsecured buildings, unpatched systems etc etc and this is usually what is being exploited. First you need to get your businesses tech security in order otherwise all you are doing is adding more complexity with very minimal security improvements (basically you solve the issue of someone stealing a harddrive).
This sounds slow, but it isn't I get nearly the full upload bandwith of my connection.
So you 6gb/s ssd drives are limited to a whooping 100mbps. That's slow, bruh. Unless your drives are all IDE this does not scale.
Only the catchy name is new. It is more like an Anonymous, than an illuminati; more a herd of cats than a hierarchy. Vonegut wrote about it in "Catch 22".
Apocalypse Cancelled, Sorry, No Ticket Refunds
The autism-hating, custom EpiPen-hating, Musk-hating Slashdot troll!
How's life in the hypocrite lane?