Ask Slashdot: How Would You Implement Site-Wide File Encryption? 151
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?
Virtual Private Raid (Score:3, Interesting)
Re: Virtual Private Raid (Score:1)
But the chance of losing your data is triple.
Re: (Score:1)
RAID5 may help.
Re: (Score:3)
DRBD / Mars (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
Re: (Score:1)
Re: Virtual Private Raid (Score:4)
But the chance of losing your data is triple.
I was about to say, "That's not how probability works!" but it turns out that you are actually correct.
If each site has a 1% chance of being seized, then it means each site has a 99% chance of not being seized. Multiplying these probabilities together gives .99^3 = .970299 or about a 97.03% chance that no site will be seized — which means that you've got about a 3% chance of having one or more site seized.
The key here is that 1 – (1 – x)^3 is very close to 3x for small x.
Re: (Score:1)
But the chance of losing your data is triple.
[because] each one gets only a 3rd of each file
I think the meaning was if you spread your data across 3 nodes, but you need 3/3 nodes to access the data then the chance of losing all your data is times three.
If you used a parity system like RAID 5 across 3 nodes, then you could lose 1 node but still access your data. Losing 2 or more nodes means all data is lost, but also means the party performing the seizure needs 2/3 servers to recover the data.
Re: (Score:2)
However the chances of your kneecaps giving way is very high.
Re: (Score:3)
I used to run a secure, encrypted server... until I took an arrow to the knee...
Re: (Score:1)
Hmm... /dev/md4 /mnt/vpraid /mnt/vpraid .. lost+found
3x Linux Network Block Devices through device mapper
1 RAID-0 array through the device mapper with nbd members
Make an ext4 filesystem...
Let's see:
# mount
# ls -a
.
It works, so I think it already exists. Personally I'd probably use RAID-5 or RAID-6 if I wanted to use this regularly.
Re: Virtual Private Raid (Score:1)
How do you ensure you are not being keylogged when you enter the passphrase on reboot?
Re: (Score:3)
1. You could boot the system from the flash drive that is removed after boot. The part of the key resides on the same flash, the second part is entered. It's quite possible to do, at least for FreeBSD. THEY need both a keylogger in a keyboard or bios and a seizure of the boot flash. Additionally there is no place on the disk where THEY could implant a child pornography if THEIR other efforts fail.
2. You could setup the security system that signals the systems to erase the keys and shutdown on intrusion so y
Re: (Score:2)
The best way to secure the BIOS:
1. Remove BIOS chip and discard
2. Burn your own BIOS chip
3. Enable write protect if available
4. Physically remove the write enable pin, or even better apply high voltage until the FET fails
5. Replace chip and test
6. Glue chip into motherboard
You have to make sure you have a CPU without backdoor features though, or sabotage them somehow.
Re:Virtual Private Raid (Score:4, Informative)
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.
GlusterFS supports striping across volumes that can be hosted on different servers: https://gluster.readthedocs.io/en/latest/Quick-Start-Guide/Architecture/
Re: Virtual Private Raid (Score:1)
Re:Virtual Private Raid (Score:4, Informative)
Sounds like Tahoe-LAFS.
Re: (Score:2)
Tahoe-LAFS can be configured to distribute data in a RAID-0-like manner such that there is no redundancy.
Re: (Score:3)
What you want for this is some variation on Shamir's Secret Sharing algorithm. Yes, he's the Shamir in RSA.
https://en.wikipedia.org/wiki/... [wikipedia.org]
What this does is break a secret up into n different parts, but unlike raid, you can break it up in such a way that there is a threshold for the number of parts required to reconstruct the secret. So, for example, you could break a secret up into 6 parts and specify that any 4 parts will reconstruct the original data. If you have only 3 parts, then the secret is complet
Re: (Score:2)
In the SAN/NAS world, this is called bay redundancy. A few vendors have geo separation options that would meet your criteria, but network latency would be a factor just as it is with layer 2 tunneling.
Openstack SWIFT has something via zones, but the complete copy is present on all three redundancy nodes as it's mirroring so that's not what you want unless you use a disk adapter that supports encryption, but that's still the full copy in one place.
However, you can also set up DRBD with this, but the encrypti
Re: (Score:2)
Would it not be simpler just to go with parrallel networks. One purely internal with all data secured and encrypted and the other open to the internet for internet communications. The secure network has only one point of digital data input, by network security staff. Who take in new data, scan and validate it, prior to loading onto the internal secure network. Smart terminals on the secure network with only manual data input, no possibility of adding data digitally to the secure network.
The comms network o
Re: (Score:1)
Re: (Score:2)
I think this is a major part of TAHOE-LAFS. https://tahoe-lafs.org/trac/ta... [tahoe-lafs.org]
Tahoe-LAFS is a system that helps you to store files. You run a client program on your computer, which talks to one or more storage servers on other computers. When you tell your client to store a file, it will encrypt that file, encode it into multiple pieces, then spread those pieces out among multiple servers. The pieces are all encrypted and protected against modifications. Later, when you ask your client to retrieve the file,
Re: (Score:2)
It's not hugely hard, all of the code is out there, just graft the raid-5 code onto XtreemFS [xtreemfs.org], throw some money there way and they may even do it for you.
Full Spectrum Problem (Score:4, Insightful)
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).
Re: (Score:2)
What about immediate shutdown on tamper?
Re: (Score:3)
Re: (Score:2)
Many servers have a case open switch already. Combine with a script that triggers when USB devices are connected.
Re: (Score:3)
Usb devices? The os, and therefore you, decides what happens when usb devices connect.
Nope. USB operates at a lower level than the OS. USB is capable of talking to other pieces of hardware without the OS's involvement (or knowledge). USB even has Direct Memory Access.
Usb is not a magic backdoor, unless your os is seriously flawed.
Yes it is. Many OSes even cooperate by providing APIs for forensic/diagnostic/recovery tools that operate via USB.
Most oses will not autoexec something on an usb stick, for example.
Most oses will not autoexec something on a valid USB stick. The BIOS will though. And just because something is connected via USB doesn't mean it has to tell the truth about what it is. The stick could present as a d
Re: (Score:2)
With DDR3, one used to be able to read the RAM within about 15 minutes of shutting off a PC. DDR4 took that down to only a few seconds to where it's not really practical anymore (as if immediately moving RAM sticks to a machine to analyze them and figure out which bits are the encryption keys was ever very practical). Each time they increase the speed and lower the voltage, the possibility of using this as an exploit goes down exponentially as the power leaks out of the cells too quickly.
It may fire bac
Re: Full Spectrum Problem (Score:2)
https://web.eecs.umich.edu/~taustin/papers/HPCA17-coldboot.pdf
Re: (Score:3)
LUKS (Score:2, Interesting)
- 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 fr
Re: LUKS (Score:2)
That sounds really complex, and potentially expensive as the number of devices scales. Also, fragile and difficult to maintain.
The easiest way is just use LUKS and a secure passphrase.
If you want to restrict knowledge of the passphrase to admins but allow users to reboot, that's a harder problem. However, If you have a TPM chip, you can use it to secure a random LUKS passphrase that unlocks only in a verified clean boot. You'll need trustedGRUB and tpm-luks, but it does secure against fairly sophisticat
Re: (Score:2)
Re: LUKS (Score:2)
But how should sys-admins implement site-wide fil (Score:1)
But how should sys-admins implement site-wide file encryption?
I guess I would start with a search for "full disk encryption"
Or with raising the middle finger and telling to encrypt that.
Depends on the day.
Nothing useful in standard system directories (Score:2)
Re:Nothing useful in standard system directories (Score:4)
Re: (Score:2)
Re: (Score:2)
You cannot assume the system was shutdown before the attack occurs. You would still want to protect the integrity of the entire file system. The goal of this encryption would be so that any part of the system that doesn't have the encryption key cannot get to the encrypted data. So if I can attack at the bios of the HD, or HD controller, I could re-write /usr/bin/passwd... if those were not encrypted, to then allow the running system to give up encrypted data once that program is accessed by any process
Re: (Score:3)
Because the file /usr/bin/child_pornography.jpg could magically appear out of nowhere if your filesystem is in wrong hands.
Trying to draw the specification for this or not . (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
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.
It's bitztream (Score:1)
The autism-hating, custom EpiPen-hating, Musk-hating Slashdot troll!
So (Score:2)
May not be popular, but windowsrm is a pretty slic (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Simple way... (Score:1)
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.
It depends what you mean by 'site wide' (Score:3)
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
"You done goofed" encryption (Score:1)
hire someone (Score:5, Insightful)
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?
Re: (Score:2)
Hire someone who knows what they are doing.
Stop with the crazy talk! This is slashdot- we have standards and we expect you not to exceed them.
I would tell them (Score:2)
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!!"
Network HSM (Score:2)
There are already mature tools to do this.... (Score:1)
a bot (Score:1)
What is lacking (Score:2)
Thank you (Score:2)
What type of attack? (Score:2)
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 onc
Tahoe-LAFS (Score:2)
Enterprise solution (Score:2)
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
Erm these are all KISS violating suggestions (Score:1)
Let's Encrypt works great, mostly... (Score:1)
This may be slightly off-topic, but I use free Let's Encrypt certificates for my httpS websites. Personally, I have never had problems with them, however some browsers and mobiles throw up the same OMG WARNING HAXXXORS screen that you get when using a self-signed cert. This has forced me to turn off server-forwarding rules I had in place to direct folks to the httpS site when they used the http URL.
The irony is that these ill-conceived browser warning messages are herding them to use the un-encrypted site,
Clevis & Tang (Score:2)
Cant fix what the NSA and GCHQ created (Score:2)
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 clie
Turn off IPS/IDS etc. (Score:3)
Client-side (Score:2)
step back and think (Score:2)
Re: (Score:1)
boring shit must be encrypted to be protected, boring shit like customers data from hackers, company documents from competition, etc.. etc...
Re: (Score:2)
Re: (Score:1)
We don't know how many have been fucked over, because the Deep State is not telling and refuses oversight, using FISA gag orders, etc.
Anyone who tries to sue is out of luck because the courts conveniently say they lack legal standing. Even if you have knowledge of malfeasance, it does not count, because you are not allowed to have that knowledge. Good luck if you are in Gitmo, some black site, or been targeted for some light-hearted rendition.
Combined with enthusiastic "Three Felonies a Day" and parallel
Re: (Score:2)
[...] 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.
Re: (Score:2)
Don't hijack this. It's not about Trump, Obama, Bush, Clinton, Republicans, Democrats.... It's about the whole damned captured establishment.
Re: (Score:2)
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.
Re: (Score:2)
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/... [billmoyers.com]
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 conge
Re: (Score:2)
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!
Re: (Score:2)
I sincerely hope you recognize that you also live in an echo chamber.
Re: (Score:2)
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".
Re: (Score:2)
I sincerely hope you recognize that you also live in an echo chamber.
So say we all.
Re: (Score:1)
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 op
Re: (Score:1)
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 su
Illegal? Could be medical records ... (Score:3)
... or any other personal confidential data. Or maybe company IP. There's a pretty broad legal use-case if you think about it.