Slashdot Mirror
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.
...and uhm, just how do you plan to sync between these in a realistically usable data valume? -also the question was specifically about "site-wide" not some across the legalities of the world data privacy strategy.
The post here doesn't say very well what is wanted. Is the desire to have possibly a large number of servers, a huge number of files, and a huge number of users, so that every file is encrypted but every authorized user of every file can access the file? In other words is the idea to replace all access control with encryption? That is going to be hard. Or is the idea to possibly encrypt whole servers and somehow have all users able to access the servers, but the server is only encrypted once? Encrypted-hardware disks kinda do this, but have to have some way to get set up and they only protect data in the case of someone stealing a disk drive. The problem of allowing access is still hard.
I once implemented a partial system in which an init process that checked that it was running at boot time by the boot process would start keying everything else. Some of the new "secure boot path" tech is a similar approach. But this is not completely bullet-proof. Disassembly is hard to resist, whatever you do to a piece of code. Wasn't as common ~30 years ago.
A police function would probably want to take entire systems. That suggests that the keys to a disk-crypt system might want to be in someone's mind, possibly requiring several people to cooperate to each load part of the secret. Lotsa luck. Rubber-hose crypto, "duress" keys, decisions when to have the data get lost irrevocably, or how if at all you will have backups, all need to be thought about. The problem stated says nothing.
Let's start simple: what threat are you worried about?
The first thing I'd do is start with files. Then I would add data to said files. Then I would use cryptography to encrypt all of those files containing data. There you have it: site-wide file encryption.
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
The solutions I have help implement are based upon using an internal CA with an HSM device for the master key storage. BUT, there are gotchas on any solution. You have to have a "master key" available for all devices. This can be multiple master keys for each type. You then need the skill and resources to manage the various keys (Certificates).
The other gotcha which is just as complex is there is no one overall solution which fits everything. Sure you can have solutions for each, MDM, Notebook/Desktop Servers, clouds and NAS. You will need skills within each group to manage, maintain, implement and support.
In the end it is a gordian knot of its own. Examples which use PKI for the encryption; Bitlocker, Thales, NetApp, Airwatch.
And don't forget Backup encryption options as well. That and removable devices are a prime source for loss.
I assume no. Then WTF do you need site-wide encryption for? The majority of the content on your network is boring shit. I'd consider selective encryption for documents that matter, like HR data, contracts, C-level email (unless there are legal requirements for any of those categories to be in the clear).
Did you just say "nothing to hide, nothing to fear" ?
CAPTCHA: infamy
- 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.
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.
"we are all atheists about most of the gods that societies have ever believed in. Some of us just go one god further."
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
Where I work, all laptops are using BitLocker, with a policy being set by the IT group. Keys are managed by IT, just in case anything happens. Laptops have dedicated HW that make encryption not feel slower than without.
By the way, I am sure there is another better place to ask these questions.
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.
Because when you encrypt just the important bits, suddenly all the bad guys know just which parts to go after.
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.
I really don't understand the question. It is very nonsensical.
Slashdot will hate me for saying this, but Microsoft does a really good job with this issue. Bitlocker, their (AES128 or 256) whole disk encryption system stores keys in the TPM chip and Active Directory. Bitlocker is used on servers and workstations alike. It is very nearly seamless for users during daily use, but once the machine is off the network, there's no getting in without the correct password and PIN or 48 character decryption key.
The decryption key is stored in Active directory, by I also maintain a printed list in a secure location, along with important passwords.
On the Linux side, there's no easy way to accomplish the same functionality, at this time. If you use whole disk encryption on these systems you have to maintain a list of passwords or/and keys and manually enter them at boot, unless you leave the USB key plugged in at all times, which kind of defeats the purpose of encryption.
Was wondering if there is a site or blog that has tried to respond or negate each of the findings of the CIA dump?
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.
An LDAP server handling authentication and authorisation while a separate PKI server or similar handling the encryption keys lifecycle management with all file servers encrypted using a system-level encryption key and any individual user files further seamlessly encrypted with their private key.
You name one innocent person who's been fucked over by the government in the 10 years since PRISM was started, and I'll name a hundred million people directly harmed every day by Facebook/Google/Apple/etc. through the magic of data hoarding. Sure, hypothetically getting shipped off to Gitmo because the NSA misinterpreted your emails to mom would be terrible, but averaged out by the actual probability of that happening comes to much less damage than constant daily immersion in targeted advertising does to your pocketbook (And I know, I know, we're all much too smart to fall for ads (or to not block them). But clearly *someone's* clicking them or it wouldn't be a trillion dollar business.)
Just because Zuckerberg isn't officially a member of government doesn't disqualify him from being Big Brother.
It looks like we know where Marines United is going to be hosted next. :)
This has been bubbling to the surface for years and it really comes down to central key and certificate management; the only optionions that scale and work with both internal and external CA's I've seen are Lemur (Netflix tool that's open sourced) or Venafi, which has support for something crazy like 300 different OS and Appiance combinations and is used by the majority of the Fortune 500.
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 construction, we have absolutely no idea how many have been fucked over.
The fact that we are not allowed to know, means that it is >>0. My guess would start with Congress, the Judiciary and the military brass. But there are also plenty of luckless dope dealers and Arabs whose fate has been outsourced to an "ally".
Prove anything by multiplying Huge Number times Tiny Number
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?...
So in other words, you have nothing? Thanks.
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...
The requesters question is quite sketchy, I suggest writting a specification first with the neccessary "must haves" and possible use cases.
Yeah, this is particularly frustrating - the fella gets his question out in front of the community but then forgets to ask a question we can answer.
Protecting the drives from junk salvagers upon decommissioning is such a different problem than protecting the data on the system from the CIA. Your two-layer solution is clever, but it's going to be slow if you have each one in a different jurisdiction. Having the keys in various jurisdictions may protect from a large class of problems without requiring manual intervention or additional cost.
If you decide to implement server-level encryption across all your servers, how do you manage the necessary keys/passwords/passphrases to ensure 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?
ensure: make certain that (something) will occur or be the case.
insure: arrange for compensation in the event of damage to or loss of (property), or injury to or the death of (someone), in exchange for regular payments to a company or to the state
If you're writing something, it is presumably with the intent of convincing the reader of whatever it is you have to say. But when a practised reader sees a grammar (or spelling) mistake, it temporarily distracts them as they re-read your writing to ensure they correctly understand what you were trying to say, distracting them from your actual message.
LUKS across all systems, done.
Solves 2 issues.
a) no more Windows.
b) no more Microsoft Updates.
Been running LUKS encryption on almost all our systems for years. Use 2FA to unlock the encrypted partitions - a short-ish passphrase (only 20 characters) + HW token input.
No passphrase (there are 8 different slots for multi-user systems), no unlock.
No HW token, no unlock.
Of course, you need to be there physically during boot to make it work - or have remote USB passthru working.
Check out OnlyKey https://www.amazon.com/OnlyKey... to get started.
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?
Classic stack overflow retardation.
"You don't need the thing you asked for, do it my stupid way."
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.
There's that, but there's also the issue of having to decide what should and shouldn't be encrypted and if you accidentally copy something that should have been encrypted to an unencrypted disk there's a slight possibility of it either still being there when an adversary breaks into the system or it being recoverable if you later delete it. Neither case is particularly desirable.
Designate Navajo a designated language for classified documentation. Or select some other tribe.
Basically hire entire tribe and make a designated record keeper. Worked as a quasi encryption during ww2, will work now.
And, yes. Go paper. Old secrets can be safely be burned, when no longer relevant.
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.
The whole point of a system like this is to exclude those who are unauthorized,
To do this, passwords that may be re-used provide a strong enough security problem to make it unworkable.
The best solution is to use some aspect of the people that is unique to them to provide access.
We have seen that retain and fingerprint are far to easy to beat.
It will likely have to be either chemical (DNA?) or electrical ( brain waves or other aspects of the body?) to be secure enough.
One time us password systems help, but are a bear to maintain and support.
I'm curious what Full Disk Encryption is going to help on a running system.
Are you people retarded?
Basic metric of success is removal of the highest possible portion of overall system from trust path as possible.
The best approach I know of is for all writers to have their data turned into encrypted blobs by means of transmission to separate security server. Writers then store subsequent blob output on the appropriate file or application servers.
All readers present blobs obtained from these systems to security server. Security server authenticates reader and uses blob metadata to check access policy before decrypting content.
This allows for arbitrary complexity of application servers and data storage without compromising content should these systems be compromised.
Security server must be physically secure and vigorously designed with a minimal defensible surface. It must be made as "dumb" as feasible.
The recent demonstration of a combination hack escaping from browser, OS, and VM hypervisor demonstrates how people put too much faith in these "container" abstractions. People who are serious about security have realized this since the beginning, always noting that things like VMs and VLANs are nice for resource management and time-sharing, but probably insufficient to really protect sensitive data. Even on non-virtualized hardware, serious people consider exfiltration by other paths such as compromised firmware, and have costly procedures to scrub and change hardware from one security class to another, e.g. you can't even be confident about wiping a system to redeploy it for a different purpose the next week or next year. Sometimes secure wiping ends with physical destruction as the only way to be sure.
The recent news illustrates how encryption of messages can protect them in flight, but the endpoints can be compromised to snoop on data before/after it passes the encrypted path. Encryption at rest has a similar set of vulnerabilities depending on your threat model. An encrypted disk can save you from physical theft of an inactive disk, but not from the many server compromises which can steal data from inside the server software itself while it is in its normal operating mode. All your elaborate key management techniques are useless if the server can be tricked into serving up the plaintext to an attacker. One nice aspect of whole-disk encryption is that it can turn disk wipe/repurposing into a simple act of key destruction instead of requiring secure scrubbing of every persistent bit.
Secure end systems can encrypt data before it gets to the server, and treat the server like a dumb file clerk. The server never has the keys and can at worst corrupt or lose the data from an availability standpoint (using cryptographic signatures to protect yourself from malicious tampering of data by the server). But a compromised server can still expose you to traffic analysis, potentially revealing data-sharing paths (communication) between clients and other temporal properties which might reveal weakness in the cryptography, e.g. the attacker gets multiple snapshots of the same file over time to see how ciphertext changes with common modification patterns.
Concerns for efficiency, usability, high-availability and disaster recovery all oppose strong data security. If you expect a server fleet to recover from power loss or other failures and resume operation unattended, you make key material easier to steal. Hardware-based key managers seem to be the current best option here, as the key lives in the server but is about as tamper-proof as we know how to build. But having trusted humans (a two man crew?) restart servers and reintroduce keys might be safer. But how do they know the server wasn't tampered while it was off, in order to be confident to reintroduce the key material? Similarly, what about backups and offsite replicas? If you back up the encrypted cipher text, you could easily "erase" all backups by losing your key. If you back up the plaintext, you created many more points on a long path where data can be stolen. If you use the dumb file-clerk approach to storage servers, you risk that individual clients lose their keys and "erase" their data. The administrators cannot recover this data for the unlucky user, unless they also keep another key around which then makes the administrator or administrative systems the juicy target for attack to get the keys to the kingdom.
That is what DAC is for. Automate away your problems...
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.
ZFS has native encryption now so you can do some really sick shit with it... exporting encrypted ZVOL's and iSCSI's, per user / dataset encryption, encrypted replication, etc. PEFS is additional user based homedir encryption. On top of all the usual GELI full disk / block device encryption. Of course you can only get all these things with FreeBSD, because well, that's where it's at.
Windows is what most slashdot users use and is a joke as far as security and surveillance goes.
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, as supposedly being the "safe" one. Whether the cert is self-signed or LE, it's still ENCRYPTION. That's categorically safer! I know the warning is technically to prevent browsing to a site while being "man in the middle'd", but 9999 out of 10000 times, it's just a perfectly fine SS or LE cert. The browser warnings do nothing but scare people away from safer sites.
This idea isn't novel at all. What solutions have been put into place in places with high security requirements and very deep pockets?
You need to keep in mind is the objective of an attacker is not to defeat the crypto, but to find a way around it and get the plaintext or keys.
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.
Hardware key vault that wipe the keys if compromised. Even works for cloud based VM images
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
Wrap all of you servers in tinfoil. If you are worried about how to encrypt you entire existence, I'm sure you are very familiar with the stuff.
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 see four issues here:
Encryption in storage: Technology and practices exist for this already. If there are multiple servers, they can have individual keys.
Encryption in transit: Technology and practices exist for this already. If there are multiple servers, they will need to use the same key.
Proviso: The above can be different systems, requiring a computer to decrypt the data from storage and then encrypt it for transmission. Or conversely, decrypt received data and then encrypt it for storage. It astounds me that no hardware has been built to do this given existing technology, such as GPUs, can perform the bulk of the work. For extra hardening, the keys can be flashed onto the hardware.
Preventing leakage at workstations: There must be some way of preventing users making a local copy on their machines. This means software such as local email clients are disallowed, unless one implements encryption in storage on workstations too. To keep data off the workstation, an X-windows-type terminal needs to implemented via Java and browsers.
Preventing theft of the server: With a well-funded thief able to keep power and RAM alive during a robbery, the server needs to be location aware so it shuts down when it leaves the server room. This can be as simple as a simple ping program on the server: If the server doesn't receive the correctly numbered echo from the network, it shuts down.
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.
Use a hardware security module, like a Safenet KeySecure, to manage your keys. Use different keys for different aspects of your systems so that if one key is compromised only some data is compromised. Use versioned keys to allow frequent key rotation without downtime. Separation of concerns is also important. No one person should know how to get all the keys.
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.
Very sneaky NSA, very sneaky, but you'll have to get up pretty early in the morning to fool this woke fox. I {retracted} my {retracted} with {retracted} {retracted], you yellow bellied sons of {retracted} {retracted}!
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?