Slashdot Mirror
Why Not Use Full Disk Encryption on Laptops?
Saqib Ali asks: "According to the 2006 Security Breaches Matrix, a large number of the data leaks were caused due to stolen/missing laptops. Mobile devices will be stolen or lost, but one way to easily mitigate the harm is to use Full Disk Encryption (FDE) on all mobile devices. So, why don't we encrypt all our HDDs?"
"Cost, and performance impact are the usual arguments.
Analysis shows that the access time increases by 56%-85% after FDE. As HDDs fills up the fragmentation increases and so will the file access time. With FDE, the swap file (system's virtual memory) gets encrypted as well. This will impact the system's performance noticeably when the virtual memory is being used more often.
Encryption key & password management blues follow. What happens when the user forgets his/her new FDE password? How to manage the encryption key backup files? Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys? Who can access the system and its encrypted files? How frequently does the password need to be changed? How to prevent the user from writing the passwords down? Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!
Cost for Full Disk Encryption solutions ranges from $0-$300.
Is it not worth using Full Disk Encryption on mobile devices after all the data leaks we have seen in the last few years?"
Analysis shows that the access time increases by 56%-85% after FDE. As HDDs fills up the fragmentation increases and so will the file access time. With FDE, the swap file (system's virtual memory) gets encrypted as well. This will impact the system's performance noticeably when the virtual memory is being used more often.
Encryption key & password management blues follow. What happens when the user forgets his/her new FDE password? How to manage the encryption key backup files? Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys? Who can access the system and its encrypted files? How frequently does the password need to be changed? How to prevent the user from writing the passwords down? Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!
Cost for Full Disk Encryption solutions ranges from $0-$300.
Is it not worth using Full Disk Encryption on mobile devices after all the data leaks we have seen in the last few years?"
If the summary answers its own questions why even bother posting comments? Except to be a smart-ass (like me).
Philosophy.
Because that would make WAY too much sense. Who wants that?
Victory or awesome!
Really, we all know that people will forget/lose the password. Or they'll write it down and leave it in the laptop case.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Doesn't Vista have a built-in feature for full disk (or all but system files) encryption? Can't you even just check off the 'encrypt' option on the properties sheet for your my docs folder (even on XP) ... or your entire user profile (to cover outlook OST etc, though that is already encrypted I believe, or can be configured to be in outlook).
Most of the key management problems have actually been solved. PGP disk for a long time had the ability to encrypt using multiple keys, fraction keys (eg. 3 out of 5 must have their keys to open), key expiration, etc.
The real problem is convenience. People don't like to use secure passphrases each time they turn on their computer. How many people actually used the BIOS password feature? An easier thing would be to use some identification based (USB fob, fingerprint scanner) access, but the acceptance rate of those are very small.
Unless security is important to them personally, people just don't care. (checking under my keyboard for the root password for all the machines at work)
Will the War in Iraq get better or worse in 2007? Vote here
It's simple, really: We're too busy caring about when one politician calls another politician a "dog" to worry about real things like the environment or information security.
http://outcampaign.org/
I for one, do use full encryption... Suits me just fine...
But then again, I use linux. Encryption is actually pretty simple under it for people who actually know how to admin a Linux system.
At one time, I even ran Win2k under VMware from an image on the encrypted disk. Which means the *ENTIRE* win2k "partition" was encrypted -- something that I understand to be impossible when run natively.
The real reasons why most don't do it?
1) Ignorance -- it is not a built-in feature in Windows
2) Hassle -- overtasked IT professionals aren't going to incur extra liability for encrypting a disk, handling lost passwods, etc. (It would be really bad to forget the password)
3) Performance -- Encrypted disks aren't good for high I/O apps... Fortunately, most apps aren't!
I sleep much better, knowing that my data is safe even if I loose possession of it. I have no qualms about storing tax returns, financial records, etc on my laptop.
Boosting system memory is one good way to mitigate the problems of FDE. Eliminating the need for swap space and buffering commonly accessed files helps reduce the amount of disk throughput needed. Sticking browser caches and other temporary file space in a virtual drive would also greatly improve performance. It might even be worthwhile looking to produce slow but inexpensive RAM just so you could make volatile RAM drives for this purpose.
IBM have been providing encryption hardware for laptops for a while.
Because it slows it down, laptops can have user authorisation anyway (fingerprint or username/password combo) - and short of physically taking the harddrive out and reading it or booting from a CD there's very little someone can do to access the info on it without that. The point is - people just shouldn't be putting confidential stuff on laptops in the first place because of the security risk not just from theft but from casual users finding something they shouldn't or the computer geek repairing it.
Video Game cheats, hints a
Though I'm not very crypto-savvy, there's one thing that I've learned from hard experience about mobile devices and hard drives: they have a very short life span.
Anything with moving parts is bound to break, and if you move it about it'll just break all the faster.
So can't it be a serious problem if your data is encrypted and bytes get knocked out here and there?
Also, mobile devices are usually much slower than stationary ones and will only get slower if it has to apply complex algorithms to all data that goes in and out. And that would probably also put a real big penalty on your battery life.
It boils down to one thing: You have to select a cost-effective level of paranoia. It would make your life infinitely complex to secure yourself against every possible scenario. How important is the secrecy of your data?
Is the juice worth the squeeze?
Granted, I am not encrypting the *whole* thing, but /home should take care of most of the sensitive data. I am using GBDE on FreeBSD which is strong enough for the weakest point to be the password. Yes, if I do lose the password, the data is unrecoverable. However, a simple way around this problem is to regularly back up the entire partition. The backup should be unencrypted, of course, so that if I lose my password, I can still get back my data. With GBDE, this is easily done. The encrypted data on my machine resides in /dev/da0s1g and after I have typed in the password, the decrypted content appears under /dev/da0s1g.bde - all I need to do is dump that partition.
Certainly, encrypting all other partitions would increase security, but I am feeling pretty safe as it is. Also, FreeBSD is probably obscure enough for most laptop thieves by itself :). One last thing to note is that because the file system on *NIX is well structured, there actually should not be any sensitive data anywhere in /usr anyway - just application binaries and source.
Besides, how many laptops would then have the password for FDE engraved into them, or with a nice post-it note on them? And what would this password be? Their mother's name? Their birthday? Their dog's name? The street they live on? Users are notorious for using horrendously uncomplicated passwords.
on the other hand, if someone were to use say MdLg25GvNtUp35
Then yea, it would be effective. Brute forcing that would take what, 50 years?
Of course if the password must rotate every so often, then users will be CONSTANTLY requesting resets (as someone mentioned a moment ago I believe), which will drive up help-desk costs and also drive productivity down.
The BEST solution is to EDUCATE the user, and have strict IA policies in place. Period.
System Preferences -> Security. Click "turn on file vault". A few minutes later, you're done.
Also check "Use secure virtual memory" (aka encrypt swap) on the same tab.
Now swap and your home directory (so all important data) is encrypted. The OS and applications are not. As a result performance degredation is minimal.
In the business enviornment the business can set a recovery password in case the user forgets, dies, whatever. The user's login password is the only password they need.
Free. Easy to use, you do nothing. Minimal performance impact. So the real reason most people aren't doing it? They are stuck with Windows bloatware or are ignorant.
Unless you plan on memorizing an extraordinarily long password, the encryption you're going to get is not going to be very good. Better than nothing if you don't have anything too important on your drive, but if you have anything important on the drive then you're gonna have to consider it leaked when your laptop goes missing.
How would that work? I thought the key in the hardware token was constantly changing - not something that can be implemented in a standard hard drive.
What do you mean "Why don't we use full disk encryption?"
The company I work for(financial services) has been using this for over a year now. Not just on laptops, but also all desktops in the company.
Posting anon for obvious reasons, but those of you banking at JPMC may rest assured that we already do use full disk encryption on laptops. Wouldn't be at all surprised to learn other banks do.
A co-worker activated the (mandatory per IBM security policies) hard disk encryption and when asked for the password, he entered it wrongly (twice!) and he couldn't access it. He spent several hours trying all the permutation of his password, but he was lucky and eventually got the correct one. :-)
I'm sorry, the number you have dialed is an imaginary number. Please rotate your phone 90 degrees and dial again.
Because the people who steal laptops are often the type of people who won't know about this, so it won't protect you from being robbed...
Full Disk Encryption gives you the access overhead that comes with encryption/decryption for every access to the hard disk. Why not just encrypt the sensitive data if you want to avoid leaks of the sensitive data?
Plus, a lot of the recent newsworthy leaks would be avoided or minimized by using encrypted access to sensitive databases via an application on the laptop, rather than people copying large databases of sensitive data to their laptop to take it home and work on it, and then losing the laptop.
and it has been around since Win 2000.
p pro/deploy/cryptfs.mspx for more
It's not really "full disk" encryption, as it applies to a single file or folder.
See http://www.microsoft.com/technet/prodtechnol/winx
Because a disk encrypted with password qwerty or abc123 won't be much more secure than an unencrypted disk? :)
NEVER underestimate people's stupidity/lazyness ...
This post written from a laptop with a LUKS-root filesystem. I catted a 280 MB file into dev null, it took 17.8 seconds. I copied that file to a filesystem on the exact same drive, umounted the filesystem, remounted it, and tested that, it took 12.5 seconds Top showed the crypt activity as taking about 50% of my cpu in the first case, my Pentium M at the time of measurement clocked only up to 800 MHz to accommodate the load. This test was repeated a few times with a small degree of variation.
/, and didn't notice a problem at all.
Anyway, those metrics are actually more different than I would have expected. I was hoping to demonstrate that the difference isn't that much, but objectively it is disk io performance hit. In general use I don't notice it. I already had a crappy hard drive that was dog slow, and in the end adding encryption made it... still a crappy hard drive that is dog slow, and the extra slowness I didn't even bother perceiving until I tried to measure it. I used this laptop for a few weeks with no encryption, and on the next install did encryption from the get go on everything from
XML is like violence. If it doesn't solve the problem, use more.
keep it off of portable devices. We grappled with this problem at the bank where I used to work. We opted for Citrix/Remote Desktop inside a VPN tunnel secured via RSA token and accessed via Verizon wireless broadband cards. This kept all non-public information off of laptops, securely stored in our datacenter.
-ted
Proud member of the Weirdo-American community.
because I trash laptops and have to recover data more often than I need to worry about it having been stolen.
If you do need to ensure something isn't stolen and you absolutely have to have it on your laptop without a net connection, then there are plenty of utilities that allow you to mount encrypted partitions.
We do. At least all federal agencies do now, as a result of this fallout.
Just had mine encrypted a few months ago.
A new addition to the 2.6.19 Linux kernel, eCryptfs, addresses many of these problems:
k start.html
http://ecryptfs.sf.net/
eCryptfs is an actual filesystem operating at the VFS layer of the Linux kernel. It stacks on top of other filesystems like ext3 and encrypts files one at a time, with each file getting its own key.
Who cares about encrypting libc or the x.org libraries? People want to encrypt their financial, medical, and other such data. eCryptfs makes it easy to encrypt only what users want to encrypt.
Some ways that eCryptfs deals with the issues raised:
What happens when the user forgets his/her new FDE password?
The best answer is, ``You're screwed.'' That is the way it should be; without the secret, nobody -- not even you -- can get to the data.
Now, out here in reality, things can't be quite that convenient. Try telling the CEO that his third-quarter reports are lost forever. The next-best thing is intelligent key escrow. I tend to recommend (m,n)-threshold sharing, wherein a certain number of people in a group need to collude (say, 3 out of 5 people in the company) in order to reconstruct the secret value.
eCryptfs userspace tools have a pluggable key management infrastructure, and thus it can keep the secret value in any token device for which a module exists. These hardware devices do not need to be expensive. In fact, Thinkpads come with TPM chips built-in, and a TPM key module already exists for eCryptfs:
http://trousers.sourceforge.net/tpm_keyring2/quic
How to manage the encryption key backup files?> Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys?
All of these are addressed with something like (m,n)-threshold sharing:
http://en.wikipedia.org/wiki/Secret_sharing
Also, because eCryptfs encrypts on a per-file basis, an incremental backup utility can just access the encrypted files on the lower filesystem. All of the information needed to decrypt the files is right in the header of each file; all you need is the key.
Who can access the system and its encrypted files?
This is a semantic security problem that the tools should definitely address. eCryptfs, in its current form, provides fairly flexible key management options, but the design goals of eCryptfs are much more ambitious, and they seek to address these sorts of issues:
http://ecryptfs.sourceforge.net/ecryptfs.pdf
How frequently does the password need to be changed?
Ideally, one would use eCryptfs in public key mode, so that is largely a non-issue. The secret can remain locked in a TPM chip, and the key can be escrowed.
How to prevent the user from writing the passwords down?
There is nothing wrong with writing passwords down, as long as the paper on which the passwords are written is stored in a location that can be made at least as secure as is necessary to protect the data that the passwords are protecting. In any event, the secret value can depend on a password *and* something else, like a file. The OpenSSL key module can be used in that way.
Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!
Not really; many laptops shipped today have TPM chips built-in.
Oh, yeah, and all of eCryptfs -- both the kernel and userspace components -- are GPL. Give it a try.
An unjust law is no law at all. - St. Augustine
All the FDE drives being marketed will have a hidden root key that allows the bearer of the key to decrypt any data on the drive. I suppose if you forget your key you could ask the drive maker nicely if they would share the root key, but I don't know if they would.
I thought that encrypting just the home directory was a great security idea on my group's laptops. It is very effective in limiting liability against laptop theft.
Except that every day's incremental backup becomes a de facto full backup. So you have to start the backup as soon as you get to the office if you want to leave on time.
This is slightly off the topic, but in the same vein...
I continue to wonder, after every major laptop theft, why NOBODY is working on physical security.
Notebook hard drives are easily pocket-sized, and the only thing keeping the hard drive from sliding out of most laptops is the thin plastic shell of the unit. Build laptops with a very simple hinging door over the drive would be absolutely trivial. You probably also want to add thin aluminum shell around the drive to protect it from static discharge and other abuse.
Then, you tell employees to keep the drive in their pockets when they go into public. If it's really critical data, attaching a retractable cable (as seen attached to your janitor's keyring) between your belt and the drive will stop all but the most skilled, equiped and determined theives.
It's as if everyone in IT has forgotten the lessons learned from the past several thousand years of (physical) security developments.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
The first time I used full disk encryption was KoH on my 386/25 laptop that ran G2 & G3 to clone those pesky flip and brick Motorola's. As for modern day FDE, the best implementation that I have seen was a friend of mine's laptop who worked for Morgan Stanley in their International Banking division. The OS was Windows XP, the hardware was a ThinkPad and the authentication mechanism was a PC-Card. Without the card, the laptop wouldn't even boot.
File Vault is included with ther OS to encrypt your home folder.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
To encrypt entire disk it is a stupid idea. Few points:
- Performance - encrypting everything (cache, program files and so on) is a serious hit on performance, now you can say that hardware/performance it is not a problem. But don't say it to me when I see brand new laptop booting long time since you can login and launching MS Office in *few* seconds.
- Anyway why encrypt everything when it is the data (and not all of it) that you want to encrypt?
- Hassle - I mean when it is an option to just tick "encrypt my harddrive" checkbox it is paradoxically way to easy. You can imagine every clueless marketing staff member just ticking it to encrypt their worthless data. It is good that hard encryption is bit "hard" (like you need to provide a password and a key and have a clue what is going on) so people will use it only when they need it, so they will probably remember their passwords.
My boss asked me for this feature. I've just installed TrueCrypt for this. Told him to click on this icon and *remember* his password (probably he wrote it down and locked in a safe - perfectly normal and wise) so he can get his "special safe disk" for his important documents.
I'm going to use LUKS as my example, since the classic cryptoloop and older dm-crypt stuff can't do this.
The solution is for IT to have a person perform the install (already was going to be hard not to do so with the current state of installers). The IT person makes a master copy of the key using the company's chosen password, and uses a different key slot for the employee-known password. When password changes occur, IT people have to go and change the IT-friendly key slot to the new password, but leave the employee's alone. Then IT can recover data from laptops at user requests. This doesn't guarantee data recovery from a system if the user who can change the password on their own key slot doesn't want them to, but if the user wants to play nice to keep IT able to assist them it can work. If the user botches the IT key slot and needs recovery, tough. Data on a laptop in that circumstance should be relatively transient if remotely important, with the real copies on file servers where IT can manage backup and recovery as they see fit.
At work the mandate for Windows laptops is to use the built in encrypted folders mechanism, which is a lot like encfs. If they loose their user password for the account the data is gone, and this is just a fact of life they have to live with. One person went further and put some third-party whole disk encryption on their Windows laptop, a la dm-crypt, but I don't know if it is like classic dm-crypt setups where the key itself is simply a hash of the password, or if it is LUKS style, where the key is random (or at least psuedo-random) and itself is encrypted using the hash of passwords, allowing for trivial password changes and multiple valid passwords.
XML is like violence. If it doesn't solve the problem, use more.
Encrypted swap and encrypted / the way to go in linux. In Windows there exists third party software that encrypts more widely Basically at the earliest screen before the XP logo is even displayed, someone has to blind type the password for it to boot. Guy at work uses it, I know no more details than that.
XML is like violence. If it doesn't solve the problem, use more.
TrueKrypt Foundation has a good stable and open source package.
don't cut it off www.mgmbill.org
All the fingerprint and user authentication in the world is a poor defense against someone ripping out the drive, which is easy if the laptop is stolen. That's why it is generally a larger issue on laptops than desktops. Desktops tied to your desk at work have whatever physical security the company has invested in protecting it, leaving it open only to the possiblity of remote attackers (well, within reason, the physical security can be bypassed, but assume a perfect company for discussion). The whole threat of a laptop is physical security breaches, otherwise the discussion wouldn't be laptop-centered. As to not putting confidential stuff on laptops, it is a good idea, but that is a policy rooted in trusting the user to always be vigilant about the confidentiality of the data set they are working, trusting their judgment, and expecting them not to take convenient short cuts at 5pm on a Friday so they can get it done on the weekend without staying late or looking bad on Monday. I use full disk encryption so I don't have to even think about it. I'm fairly sure I have nothing on my laptop remotely of interest to anyone, but I never have to think too hard about it.
XML is like violence. If it doesn't solve the problem, use more.
and you can buy now while stocks last !
(please dont search google for not only free but better alternative products to reccomend to your enterprise)
my corporate-owned laptop runs ubuntu only. I encrypt swap, and the partitions where the stuff I work on for my company is kept. I've never noticed any performance problems.
now as to why other people don't, I have no idea.
I use FileVault on my MacBook and it's not slow at all.
Why not encrypt your disk? Because there are more effective ways of protecting data and mitigating liabilities.
. asp
You don't really need to carry the data around. http://www.tadpole.com/products/notebooks/comet15
I need my /boot unencrypted or else grub can't load my kernel, and of course the initrd with dmsetup and cryptsetup in it.
As for / and every other persistent storage, you're good encrypting it.
XML is like violence. If it doesn't solve the problem, use more.
I had Apple's FileVault enabled on my Powerbook. I decided that I no longer needed it and tried to disable it. I moved all the large files out of my personal folder first, so it would take less time to decrypt. I had plenty of free disk space, and the dumb thing still wouldn't decrypt! I ended up wiping out that install of OS X to get the encryption turned off.
Sent from my iPhone
I work as a SW consultant for the mobile sector and all laptops in our firm have encrypted hard drives. The system is so that username and password is asked right when the laptop is booted kinda like bios password and after windows is loaded it automatically logins you to windows with those credentials. It's easy to use, no need to remember any additional passwords and also added benefit is that the administrators can login into it with their credentials if a user forgets his password.
:).
The performance hit is real and noticeable though, but mostly affects hard drive related tasks, so that does not hinder my working too much.
Also all firms that I have been dealing with use encrypted laptops, so in my perspective the FDE is pretty widely used already
And then there's the "You're at the airport and some people want to inspect what's on your computer" situation. Having a fully (perhaps even partially) encrypted system might generate some unwanted and unneeded suspicion.
I'm posting this from a laptop with FDE right now and I think it's great (I do have 2GB of RAM though).
If they can't write the data that quickly anyway, where's the harm in providing it more slowly?
...for a 7 week gig at a semiconductor maker. IBM (yeah, now Lenovo) Thinkpad, and I had to enter a password at boot. No sweat, they asked me to give the password to the tech who received the equipment when I turned it in, but it could have been reformatted since I kept nothing on the local drive worth saving.
For what it's worth, this gig was all wireless on campus too, with VPN inside and outside the firewalls. I'm doing a long-term gig with a major financial firm now, and they don't use FDE. And they have NO, repeat NO NO NO wireless. The security team trolls constantly for unauthorized wireless and anything that transmits is confiscated as soon as they find it - cut out and trashed.
Both these firms suffer the same risks for their data. Either would suffer financially and risk complete failure if a critical breach ocurred. Just different ways of doing things.
deleting the extra space after periods so i can stay relevant, yeah.
Encrypting your whole disk on Linux is somewhere between a minor pain and a complete nightmare. Support for it doesn't even exist on certain high-profile commercial distros (Red Hat) which you would THINK would have had it long ago because it's something their customers would want.
I had to put together my own unofficial packages to get an encrypted root filesystem on Fedora Core 5. (And then it broke on FC6, so no upgrading yet...) In theory, the support will officially be in Fedora Core 7, but there's still a bunch of code to be written between now and then.
How am I supposed to fit a pithy, relevant quote into 120 characters?
There should be some software that automatically decrypts a partition using a key on an usb-stick whenever it is inserted. This removes the hassles and problems arising from remembering and managing passwords. One only needs to remember not to leave the usb-stick with the laptop.
http://forums.pgpsupport.com/viewforum.php?f=54&si d=749efb5b59855bac7e1a06eda016e4a9
If you need a reason why people aren't encrypting their disks, visit the PGP Whole Disk Encryption forum and take your pick.
-----
PGP Key ID 0xCB8FF658
I'm posting this from a laptop with the entire disk encrypted with LUKS. It's a pentium-M notebook I use for development and mail/web. I don't notice any slowness at all. As long as you have enough memory to not use swap, it's perfect. And with the new Debian installer, it's easy too.
Give it a try.
Another advantage for corporate types who have to dispose of old disks securely: If all the data that's ever touched a drive has been encrypted you can probably get rid of it without the DBAN hassle. (No offense to DBAN, it's great)
Encrypted hard drives have been mandatory for last 5 years on laptops. Working for telco, Welcome to europe.
In a number of contexts, loss of data is a more serious concern than loss of confidentiality. For the vast majority of self-generated data on my hard drive, I would be seriously inconvenienced by the loss of the data, but would not at all mind the data becoming public. For a significantly smaller amount of data, I would seriously mind the data becoming public, but I would more mind losing the data. Only a very small fraction of data on my computer is such that I would mind the data becoming public more than I would losing it.
In such a context, given that FDE makes data recovery harder and more time-consuming, it can make sense to encrypt only that tiny fraction of data where one would more mind its becoming public than one's losing it. In other contexts, it will be different.
.. and that's "What happens if and when something goes wrong with the encryption solution and you lose all your data"?
When I was issued a company laptop, I jumped right on the encryption bandwagon. I used Linux, so I encrypted umy home directory sing loop-aes. Unfortunatly I was usin Gentoo at the time, and this was early in the 2.6 kernel series, before loopback encryption was standard in the kernel. So I was using some kind of third-party kernel AES crypto module (still not exactly sure what it wasusing, emerge took care of the details).
Anyways, months later, my OS install goes haywire. For what reason now I don't remember. No big deal I thought, I will just re-install.
Problem was, with the current Gentoo, I couldn't decrypt my drive.
Skip ahead 4 days later. I have tried *everything* to decrypt this data - posted in forums, talked to crypt developers, even tried writing an AES routine myself to get the raw volume at least. Nada. I ended up giving up and starting over - after all, nothing *important* was lost, but I did lose 2 years woth of archived emails I really would have liked to keep.
Oh, what about backups you say? Well security-consious as I was, I decided to back up the encrypted volume.
Needless to say I remain very wary of full-disk encryption in any form. And I always back up unencryupted. Secure? maybe not. But at least I know that if I have a filesystem crash I can use standard ext2 recoveryt ools to get my essential files back.
I have a laptop owned by the US Government for my work. The three letter agency that I do work for requires that laptop to run Pointsec to encrypt the hard drive. Overall it is a lacking product that slows processing considerably and takes the battery runtime and effectively makes it 1/3 of what the manufacturer states. I understand the need to keep data private from meddling hands, but it is a really hard sell when you effectively make the user plug into the wall and make the laptop more prone to crashing.
Was it the hard drive password that the system asks for before even trying to start the boot loader, or is this co-worker in Lenovo land where actual encryption is required by the government agreement?
IBM company wide policy requires the hard drive password, but that isn't encryption (you can tell because on a normal hard drive with data on it can have a password applied and no work has to be done that would have to be done with encryption. The hard drive password is just something on the drive controller's non-volatile storage that the drive's controller board has to validate before it will service requests from the motherboard's drive controller. I don't know details, but at the very worst all that is required is to swap out the drive controller board to defeat it, hence why the government required stricter standards that actually do encrypt for IBM employees in a building shared by Lenovo people.
Yes, there have been several high profile laptop losses but compare this to the millions of laptops out there. So long as it is troublesome to deal with these encryption issues, costs significant IT resources or requires difficult procedures for the end user it just isn't worth it.
It is tempting to think of companies as simple top down structures where the management sets policies and the workers follow them but I think we all know this isn't entierly true. It is important to keep your workers happy and if laptop passwords are annoying to use their will be strong pressure not to use them or otherwise get around them.
Additionally one needs to take into account the fact that it is often harder to recover from HD mishaps when the data is encrypted.
Before we start seeing widespread adoptiong of FDE encryption I think we need hardware level two key systems. That is the diskdrive itself should encrypt all data entering the HD and decrypt all data leaving it after being furnished with the correct key. This key would be required to be represented *only* after the laptop had been shut or powered off (alternatively it could only be required to represent after the laptop has been powered off and the OS could lock when the laptop is closed which would require a power off to avoid). Management or IT would have a master key which could not be changed by the user allowing them to read the HD should the user forget the password or otherwise screw things up.
Furthermore this encyrption system should have the property that anyone knowing the key, the location of a block on the HD and the contents of this block should be able to decrypt this block, i.e., the encryption of a block on the HD doesn't depend on the values of other blocks. This would make data recovery no more problematic than it is today since management would have the appropriate key.
If you liked this thought maybe you would find my blog nice too:
There is absolutely no need to encrypt the main hard drive. What? You afraid of someone stealing C:\WINNT?
The simply solution is to use USB disks/keys with encryption and stick all sensitive data on those. You can get 4 Gb solid-state and larger if you use something like an iPod. How many people really need > 4 Gb of secure data available off-net? The vast majority would be fine with fast USB 2.0 memory sticks.
Key escrow solves the "I lost my password" as well as employees that leave without telling their boss/replacement the passwords.
For super-secure stuff, make them call home first to check a CRL and validate they still have permission.
For those that don't like the USB stick solution, then partition hard drives and just don't encrypt C:\.
Charles
Learning HOW to think is more important than learning WHAT to think.
Here is why you don't want to encrypt everything on your laptop:
Redundancy:
Encrypting files who's contents are known, the operating system, for instance opens your encryption method to known plain-text attacks. This is a big reason WEP is so easy to break. Known attacks for WEP exploit the redundancy in TCI/IP packets. Practical Cryptography by Bruce Schneier has a fun read about WEP.
Corruption:
Encryption makes files susceptible to corruption. A bit wrong in plain-text ruins a character of a text file. A wrong bit in an encrypted file ruins not only it's self, but propagates errors elsewhere.
It's mandatory policy where I work that all windows notebooks have hard-drive encryption on, and also run network backup software. They were pretty annoying about it, and I'm certain there are people who've avoided/evaded it, they pushed it on the whole company.
It doesn't really affect the devs on my team...they just remote in to the beefy tower under their desk to do builds...the notebook is essentially a terminal/email/comm client system for them.
Laugh while you can, monkey-boy!
With USB flash drives up to 4GB, and 100GB+ USB hard drives that will fit in a pocket, why not just keep it on your person (encrypted if necessary)?
We only want a quiet place to finish working while God eats our brains.
--Bruce Sterling
My employer uses EncryptionPlus Hard Disk since a data theft from a laptop in 2004 that compromised a hundred or more Social Security Numbers. I don't know how robust EP Hard disk 7.1 is, but it is such a big deal that all 60,000 employee laptops use the software.
You can only reclaim space from deleted files in file vault by logging out of the user account. This can be quite annoying.
I'll inform all the buyers of low cost paper weights on EBay that they're missing this important feature of the IBM laptops.
While yours is a true statement for some laptops, it isn't a blanket statement for all laptops. There are many exceptions to the rule that BIOS/HDD laptop passwords are easy to break.
You're reading Slashdot. Of course you like Linux and pc hardware
Jetico has a new piece of software in Beta which I am testing on an XP laptop and desktop. It works quite well! I would like to see a full third party review of the source though, as it is closed source.. but it is perfectly stable and I have not noticed any performance drops. Of course I am not much of a gamer and didn't do any benchmarks but it does work for me. It encrypts the entire hard drive so you even need a password to boot. (On Linux I use LUKS.) Check it out here.
Based on the readme, it looks like encfs (which uses fuse and openssl). It might obscure more detail (i.e. with encfs you know how many files and directories there are, and their timestamps). How does it differ from encfs (http://encfs.sourceforge.net/)?
/boot (which I do). This has benefit for protecting against physical threats and people trying to reboot your system using a live cd or other such attacks. However, the key is always available to the kernel and all the data is visible, so a remote or local attack that acheives root privileges means all the data is exposed since a very coarse grained attack was used. On the bright side, it is also appropriate as a codified standard because users can't generally be trusted to correctly perform risk assessments on every save or understand all the temporary places they may save to, and it's the only way to protect swap patitions. I use dm-crypt with LUKS partitions for / and swap on my laptop, with a small /boot for the kernel and luks-enabled initrd.
/tmp is always exposed and swap is still dm-crypt protected on that system.
encfs is of course per user, and a somewhat nifty thing there is the pam_encfs module which can optionally used to get the authentication token to unlock its key. The implementation (since it's obviously has to be since it's a fuse thing) is more userspace than ecryptfs, but functionally speaking, what's the difference?
I understand well the benefits compared with dm-crypt strategy based on the circumstances and requirements.
With block level strategies, you have to decide the total size of the block device for protected vs. non-protected data. If you don't understand your needs well, it's difficult to apply a finer-grained approach to security, particularly if you are required to codify it into a company standard for people who you definitely won't understand perfectly the needs of. Because of this, the only generally feasible approach is to encrypt everything save for
encfs and similar strategies feasibly allow finer grained policies to go into place without making the tough size decisions as is needed with block strategies. This provides all the protection from theft and such like dm-crypt does. And if the policies are fine grained and the directories are only mounted as needed, a remote attacker achieving root access will only be able to get to file systems currently mounted, which may be a smaller set than the whole. The difficulty here is that when defining a finer-grained policy, you have to know which directories could ever hold sensitive data, If you are to protect swap you can't use a swap partition, but a swapfile in a directory protected by such a scheme, and in the end on a single user system (almost all laptops), effectively no matter what all the encrypted filesystems will be mounted anyway most all the time, so it's really not ultimately much of a functional difference. I make encfs available on a couple of multi-user systems, and generally have pam_encfs there to make their home directories encrypted.
XML is like violence. If it doesn't solve the problem, use more.
Encrypted data is great. It's annoying but it's great for the security it can offer. But what is it we want encrypted? The entire OS? Hell no! Just the data we're working with... just the data that needs to be protected. And in the applications that use this critical data, there's invariably a username and login or some means of authentication into these critical applications. Hey! What a great time to introduce a little encryption based on some keys + username + password hash action you know?
Hell, for that matter, make sure critical data isn't stored on the system's drive! Make it link to a database online! Make the LINK encrypted.
The real solution is to identify the critical data and be careful with it.
You can't make safe cars no matter how you try... you can only make safer drivers.
I know this is slightly off-topic since we're talking about laptops, but for encrypting desktops I recommend:
http://siig.com/product.asp?catid=106&pid=474
or
http://siig.com/product.asp?catid=106&pid=475
It's 56-bit DES, but it's better than nothing and would stop most thieves.
. . . don't like it.
I deal with some highly confidential data with my job. On my Linux laptop, I keep all the secure data in truecrypt partitions that I mount as needed. Under Windows I used PGPDisk and they were both more then adequate for my needs. Recently, the organization started implementing HDE across all the laptops. Their solution, while quite secure, is slow and annoying. NONE of the users like it. It adds time to the boot sequence, it puts a vulnerable (and easily lost) dongle on the laptop every time it's in use, and it adversly affects system performance on a laptop that's already straining under a corporate mandated software load.
Is my data safer? Not much, in my case (my important stuff's already encrypted). But for the average user? Yes. A lot safer. Are the users happy with this situation? No. Not at all. HDE's unpopular mostly for user inconvenience issues. We won't even go into the cost issues for administration and implementation.
The real reason we don't see more of it is because for most organizations, the security benefits don't outweigh the costs and user resistance.
Never attribute to malice what can as easily be the result of incompetence...
mainly for notebooks, battery power.
... I have my laptop turn itself on every day in the morning, and five minutes after that amarok starts playing my favourite songs on a low volumn, slowly turning it up over the next 10 minutes, to wake me up. Having to input a password would sorta ruin that :)
Real men don't write sigs
There is an inherent flaw with many of the commercial laptop full-disk encryption solutions out there. I have the most experience with Utimaco's Safeguard Easy, but I know many of the other big players have the same fault -
The software has a feature called "Pre-boot Authentication", by which the encryption software is loaded after the bios, but before the (generally Windows) operating system. The user's password is used to generate the decryption key, so theorhetically not even the NSA could decrypt the laptop without the user's password.
Here's the flaw - the software has a checkbox to disable Pre-boot authentication. What this does is generate a default user with a random password, and then store this random password obfuscated but in clear-text in the same disk area decryption software. When you talk to the sales-people, they sell this as a feature, in fact about half of Utimaco's customers (so I'm told) run it in this mode because the encryption becomes transparent and it is much less intrusive on the user. (Basically the disk is automatically decrypted each time the laptop is booted, but you have to have a valid Windows login to get in.) Buried in the help documentation are warnings "For security reasons, you should Never disable pre-boot authentication". So the engineers and the company know the weakness of disabling pre-boot authentication, but they don't tell their customers when they sell the software.
Today it seems to break into these laptops with pre-boot authentication disabled you would need somewhat sophisticated tools and techniques, basically the same tools and techniques people commonly use to "crack" commercial software today. But I'm guessing that it won't be very long before someone takes the time to build this crack and releases it, rendering the laptop encryption useless to anyone who can Google for "Utimaco Crack", etc. Basically all the crack would need to do is grab the default user's password off the disk and use or duplicate the decryption algorithms that are also in clear-text on the disk.
I've talked to a number of IT security folks, and basically it seems like most people trust the sales folks and don't understand that its basically impossible to have strong encryption without having the decryption key stored off the disk (like on a smart card, or in the brain of the user.)
There is absolutely no need to encrypt the main hard drive. What? You afraid of someone stealing C:\WINNT?
No, but I'm sure no one wants people going through their C:\Pr0n directory.
Try fitting that sucker on a USB flash drive!
The company I work for uses pointsec on our laptops. There is integrated login (we use a novell client on winderz) that works just dandy, it does add about 5 seconds to bootup, but there is really no overhead to speak of when using the laptop (IBM T-41) and I am fully with using the encryption. I know someone above mentioned using encryption with Linux, but we don't use Linux on the desktop, we are about 15,000 employees, and use XP on the desktop/laptop with the exception of security guys (ME) we use a second partition or we use whopix or knopix and boot to a cd for pen/vuln testing. What I am trying to say is... I have never noticed any slowdown or issues with using it, and password reset can be handled with a one time pad, or by calling the helpdesk for a password reset.
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
Analysis shows that the access time increases by 56%-85% after FDE. As HDDs fills up the fragmentation increases and so will the file access time.
And who requested that analysis, if I may ask? The owners of laptops with very sensitive company data, who ALSO wanna get high framerate on Doom3?
Lower I/O performance is not an excuse for low or no security, is it? Not to mention that most of not all of the business/enterprise apps out there just aren't I/O intensive to begin with (and if they are, can't you wait, say a couple of seconds more to open that DB).
Why isn't the computer full of Social Security numbers/credit card numbers/addresses of people in the Witness Protection Program bolted to the goddamn desk?
If the worker bees handling this data need to work overtime, they should do it at the damn office. And if they can't, it's a human resources problem (i.e. hire more people).
AES-256 + disk encryption + password="mittens" == moot.
How about we train people who hold sensitive data on how to manage it?
There's a shocking cool idea...
Tom
Someday, I'll have a real sig.
Here is another solution to the question about whether to encypt laptop HDDs: take a deep
breath and chant:
"Security is an illusion."
"Security is an illusion."
"Security is an illusion."
(repeat at least 7 more times)
After that you should be enlightened.
Should this apply as well to "field technicians," or people who travel to client sites to perform essential job functions?
A little off-topic, but which is the laptop backup solution you people use (Windows if possible)???
I've tried Brightstor ArcServe for Laptops and Desktops, and it's awful.
I've heard there's a solution from Symantec but I never tested it.
An ideal solution would have the possibility to backup from the field (VPN? Encrypted traffic?). The Brightstor solution actually promised that it would send the data in packets so as not to interfere with normal usage but didn't work that way in practise.
My boss even asked for a solution that allows the possibility to restore from the field, but that seems very far-fetched.
There are three kinds of lies: lies, damned lies, and statistics.
****Encrypted filesystems require your boot partition have the encryption keys unencrypted so that they can be read, which sort of mitigates the whole point.****
Unencrypted? Couldn't they just use a hash?
The traditional method dm-crypt and cryptoloop used was basically what you say, a hash of the password was used to encrypt the entire disk. Of course, no one ever devised a way to change the password in place, and even if they did, it would require all data on the disk to be re-encrypted. The key used to actually encrypt the data would likely be cryptographically weaker to crack, in theory. If you ever ever write down the password (I don't but some do) and then lose the paper, you can never be sure about the security of your data again short of re-encrypting the whole thing. I think this is probably the single thing people not researching it thoroughly misunderstand, if the technology you see is definitely encryption of a large data set, and you can essentially instantly change the password protecting it, the key used to encrypt the actual data is certainly not the password itself, as it requires a huge amount of effort to change the key on large amounts of encryted data.
In the LUKS scheme the key material used for the very large data set will probably be more cryptographically sound. With a large data set, cryptographically weak keys could more likely be crackable than strong keys, in a large number of the type of attacks historically seen in cryptography. A small data set (data comprised only of the actual key) is generally more resistant to data analysis attacks, so a somewhat weaker password hash based key may be less exposed in that context. If you ever think a malicious user has had opportunity to get your password (the most likely thing in general for an attacker to get), you can change the password and the old key slot be shredded such that the knowledge obtained becomes useless. Sure, the 'master password' being compromised would mean the disk is irrevocably compromised, but that would be the case in the classical strategy anyway, since changing the password isn't feasible. Now if you want to actually re-encrypt data in the way a password change would require in the previous example, you can always reformat with a different key (or re-encrypt in place if implementation allowed), and have the same degree of 'changing the master password' as you put it.
Keep in mind the 'master password' (or rather the actual key) in this context is probably a random 256 bit value. To achieve a comparable level of randomness, a password consisting of typable characters would have to be about 40 characters long consisting of completely random keypresses. If a person is ever in a position to actually get that master key value, you've already lost the data because before they can get to that key they have to:
-Get root privilges while the volume is mounted to get dmsetup table output, but if it's mounted they could just grab the data anyway.
-Get low-level physical access to your hardware to begin to crack the LUKS header of the partition or the content itself. If they are in a position to do so, they could/would image your entire volume and return your drive. In which case no matter what you do to the copy you got back (re-encrypt, change password, whatever), they can continue whatever crypto-analysis they want on their image of the data as it was when they first took it. You may be able to protect newly written data, but whatever risk of breaking the encryption on existing data is permanently there once imaging is possible.
-Get low-level access to your system and somewhere along the chain insert something to dump the key material to them once available. Again, once this is in play, it's already over no matter what you do, if they can dump that table, they can dump the data directly. In this case, let's assume one of those keyboard bugs slashdot had an article a while back was discovered by you in your system. Knowing that your passphrase is potentially compromised, with the key not based directly on the password, but just encrypted by the password, you can re-encrypt the key once the bug is removed and shred the old slot, and their keylog data becomes useless for the purposes of defeating your filesystem encryption. If the master key is essentially whatever you typed, you are significantly more hosed.
XML is like violence. If it doesn't solve the problem, use more.
Wuss, my passwords are almost always inclusive of non-alpha/non-numerical values and are at least 10 characters long. My strategy is ofter to randomly hit buttons without looking, making generous use of the shift key on the number keys...
Example: cS#e(k5L@^
(note: not an actual password, but generated in the same way I generate passwords)
Maybe I'm >50% autistic then since I can remember these...
On some occasions I wuss out and if appropriate to the password parsing/entry technology, make a mostly coherent sentence 64 characters long or so, which I believe is still an order of magnitude more secure than a mere 10 characters of even complete garbage, but it is much quicker to type 10 garbage characters than a whole sentence...
XML is like violence. If it doesn't solve the problem, use more.
Easy solution; don't keep stuff like movies in your home folder. I can't really imagine any reason why those would need to be encrypted, and as you discovered, doing so does carry a large performance penalty.
/Users/Shared/Music and ~/Movies and /Users/Shared/Movies; this keeps FileVault from encrypting my iTunes music library or my movie collection. It also means that on a multiuser system, other users can access the movies and music, without me having to enter my password or give them access to the rest of my files. (Actually I now have the movies and music on another drive.)
On my systems, I have symlinks set up between ~/Music and
If you do it this way, FileVault doesn't carry too huge a performance hit. It also has the advantage of allowing you to back up your documents in a secure fashion pretty easily: you log in as a different user, and just back up the File Vault sparseimage as a single file.
The "do you want to recover space" logout screen is fairly obnoxious, agreed; I hate it just because it stops the shutdown process with a dialog that requires human interaction. I wish it had some sort of a 30-second-countdown-to-default timer, so that if I hit "shutdown" and walk away, the process doesn't get hung up and just sit there, unsecured, forever.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Full disk encryption is built into Windows Vista. It supports TPM 2.1
Jibe!
For anyone that wants to experiment with Debian, DM-Crypt and Luks, check out the howtos and/or the USB installer at http://feraga.com./
/boot encrypted for over a year and haven't had a issue. I'm sure its a little slower but dont notice it much.
I've been running lately from a USB Flash Drive (1GB) with everything but
This also allows you to leave a full installation with no private or incriminating data on the hard drive so if they ask to see the laptop......just let them.
So if I've got to put up with locking screensavers anyway, might as well have it lock the filesystem as well, especially since it demands a password when I wake the system up after closing the lid to sleep/hibernate it.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The most incredibly useful application of this is sshfs, which basically lets you mount a remote machine as a filesystem without being root (as long as the FUSE kernel module is loaded). This has caused a huge productivity increase for me.
There is also an encrypted file system that runs under FUSE
http://arg0.net/users/vgough/encfs
So, you basically can have a big encrypted file lying around which you mount as a file system when you need it. The keys are encrypted in a separate control file, so there are no unencrypted keys lying around. You need both the pass phrase and the encrypted key file to mount the big file as an FS.
I was just pointing out that if a slow drive is your bottleneck, then providing data more slowly might not make an impact on your times in every instance.
If it's just theft you're worried about, the regular disk password schemes should be fine.
Did I miss anything?
- If you're worried about the KGB stealing your laptop because they want the info in it, yes, you need to encrypt swap also.
- If you're worried about some junkie stealing your laptop to make some quick cash, you probably don't need crypto at all, but if fences have gotten smarter about the value of information for identity thieves, maybe you do.
- If you're worried about smarter thieves who will opportunistically use the information on the system if they can access it, then file system encryption is critical but swap space encryption probably isn't.
I'd guess that 95% of the threat model, for people who aren't keeping military secrets or unencrypted personnel files, is such that encrypting swap isn't that important - you're better off deploying a solution that doesn't do that than you are not deploying it at all.Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The reason to encrypt the whole drive as opposed to the writable sections is simply convenience - if you've got hardware assistance, it's probably designed to encrypt the whole disk using some crypto chip in the disk controller, and administratively simpler to use, and if you don't have that, it's probably easier to encrypt individual partitions or filesystems, or sometimes directories, rather than hack up some CPU-based driver that encrypts the whole disk.
From a performance standpoint, it's probably faster *not* to encrypt your program filesystems, and as far as encrypting swap goes, you took the big hit when you started to swap anyway, and rotational+seek latency is usually more of a limitation than overall throughput, so if this bothers you, but some more RAM. Encryption chips on the disk controller are probably faster than CPU software drivers, but not necessarily - your mileage is extremely variable.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The notion here would be that your documents would get stored in Notes as "syncable" objects. Any time you connect to the central server, you can push/pull updates, which may be (optionally) stored in encrypted form.
If your laptop blows up due to bad batteries or gets ripped off at the airport, there are therefore two huge merits:
If you're not part of the solution, you're part of the precipitate.
hard drives die.
I use Utimaco Safeguard Easy on my corporate laptop. I do not notice any performance degregation at all.
Modern processors have plenty of spare cycles to use for encryption while they wait for a hard drive to feed them data. Even a 10% decrease in performance will not be missed by the common laptop user.
I think all people storing sensitive data on a laptop should run software like this.
That's the question that needs to be answered... A security-minded entity (corporate, government, personal) has to ask that question and seriously look at the risk vs. reward of storing the data on a portable device. If the entity in question doesn't look at this perspective of the issue, they ultimately don't care about security in general or enforcing a data storage policy in particular.
When I do consulting work (especially with regards to security), I often compare putting sensitive data on a laptop to putting the company's main database directly accessible on the Internet and hoping that whoever attacks it can't exploit it or guess a username/password combination. That will usually scare a few people into thinking about what they are doing, and the others who think that it is alright probably deserve nothing less than getting hacked.
As for disk encryption, it works well IF it is transparent to the user and IF the overall security is indeed strengthened by such encryption, because a weak link like a poor password adds no actual security value where it is expected.
Does anybody know if there is any possibility to have full disk encryption, or even only the encryption a folder on a partition (transparently) on Solaris 10? I know that ZFS encryption is coming in the far future, but are there any other solutions or hacks, which are available right know?
Under Linux, the easiest thing to do is to encrypt the swapfile. It's trivial - just modify /etc/fstab: /dev/hda6 swap swap defaults,loop=/dev/loop0,encryption=AES256 0 0
and requires no further user-intervention: a new key is automatically generated at boot, and discarded on shutdown.
The advantage of this is that *anything* could get swapped out, and would remain there for some time. This is true even if you deleted the original file (or it was in RAM, and never saved, such as, perhaps, a password/phrase). This is going after the low-hanging fruit, but it's a big improvement over nothing, and it does protect against bad luck and trivial forensic analysis of the filesystem.
From my point of few I do not see any reason why the hard drive of a cooperate laptop computer should not be encrypted as soon as the mobile computer contains sensitive data (and it usually does). In my opinion it is just irresponsible to carry any mobile device (laptop, USB stick, etc.) out of the company if the data is not secured there, and the series of data leaks known to us all proves this. It might be a bit more inconvenient, it might cause some overhead in computing, but in my opinion this measures needs to be done.
I have a Linux laptop (IBM T30, 2GHz Pentium 4) and I have not a full disc encryption, but /tmp, /var, /usr/local, /home, /root and the swap area are encrypted (256bit AES). With the 2.6 kernel series it has become easy to set up encrypted partitions with dm-crypt and recently with my new acquired external harddrive I started to use the Linux Unified Key Setup (LUKS) which makes it even more convenient to have encrypted drives (now I can give away my external harddrive to a friend and he can use it without knowing my key, the system allows up to 8 keys and each of them can be revoked easily). I have never noticed any lack in performance and nowadays computers are even faster than my Pentium 4.
Further, if it comes to data loss due to a lost key, then may I ask, where is the backup? I have a backup of my system, for sure encrypted (Dar is here for me a great help). In a cooperate setting backups should be standard as well (harddrive failures happen as happen that keys get forgotten). So loosing a key should not be a problem. One does not need to encrypt the backup either, after all the encryption should only prevent data from being read when the laptop gets stolen and into wrong hands. If the backup is secure in the cooperation than there is nothing (big) to fear if it is not encrypted.
So what point really justifies to take the risk of data leak in a cooperate setting??
What is needed is to put block-level, hardware encryption into IDE/SATA controllers. In fact, it should probably simply be a standard part of the protocol; even a "no encryption" version should still use a password and XOR the disk with it so that all system software has to deal with this.
An additional problem is that the devices for which this feature is most important, mobile devices, make it most difficult to install it as an add-on. For a desktop, you can easily buy add-ons that provide hardware encryption, but for laptops, you're stuck with software.
As long as SATA encryption remains a specialty item, it's not going to be well supported and it's not going to be widely used. And as long as it's not full disk encryption, people are going to forget encrypting their stuff.
Of course, one reason why this isn't happening is because neither the government nor the manufacturers have any interest to make it happen. The government is worried about impeding law enforcement, and manufacturers don't like the added cost and complexity (however slight). Between those two, it's not going to happen and we'll have to live with sluggish software solutions.
http://en.opensuse.org/Encrypted_Root_File_System_ with_SUSE_HOWTO
Thankfully not hard.
Don't all of today's hard disk drives have a drive password option that is physically part of the hard drive's firmware? And don't most of today's portable computers have a BIOS option to enable this hard drive password? And isn't it impossible to reset this password without knowing the original, even if the drive is physically moved to another computer?
Now this is certainly not data encryption, but it seems like a much easier method of securly protecting the hard drive in a portable computer. And it doesn't rely on any software to be installed, or any additional resources to be used during disk reads or writes. And it's damn near impossible to crack the hard drive's firmware password for the average (or even above average) computer thief.
It seems to me that this problem of "what if the notebook is stolen" already has a solution in place that simply need to be enabled by those who want the extra protection.
- James
Comment removed based on user account deletion
Most of the OS on a machine is well-known, especially in the sort of environment in which you could mandate things like FDE. Given that, a determined attacker would have hundreds of megabytes of known plaintext to use as a crib in breaking the encryption.
Of course, you could put the OS on its own unencrypted partition, and encrypt the others, but it's hard to provide enough space for things like application upgrades without leaving enough room for the "savvy" user to put sensitive data on the "fast" partition.
Basically, you keep coming back to the fact that it's really hard to find a reliable technical solution (mandatory encryption) to a behavioral problem (users handling sensitive data carelessly).
I have my /home directory in a different partition, which is totally encrypted, it's easy as pie and as fast as an unecrypted partition. If someone steals my laptop, they can access the root partition, but every important thing is stored in the encrypted partition. The only problem I could have would be that someone stole my laptop, changed something (I'm booting from disk only and GRUB has a password, so I guess the easiest way would be to plug the HD into a different computer), and returned the laptop back. If I didn't notice, she could get my passwords and hence the data in my laptop.
How pathetic do you have to be to try and turn a bitter insult directed at an ex-lover after a very public and very humiliating break up into "him and his entire political party are sexist and hate all women"? Belinda is a "cheating whore", and for the people who she's fucked over to be a little bitter towards her is quite understandable. For liberals to try to turn this into a political situation is sad and reflects on them, not on the conservatives.
Just some ideas. To improve performance of encrypted hard disk, somekind of standard encrypting/unencrypting hardware should be included on the hard disk itself or in the notebook. Hardware implements a hardware algorithm. Encryption should not depend on the hardware, encryption/decription hardware is just an hardware accelerator for the encryption software. It can be implemented completely by software. In case of hardware failure encrypted data can be recovered and decrypted on any other computer, independently of the hardware accelerator. Only keys and right algorithm are required for decripting the data. For secure access to the Notebook, instead of using a fingerprint reading device, why not use a small integrated camera and face recognition software. What techniques are available and how easily can they be fooled? If the face recognition is smart enough, the computer can lock itself automatically when the user walks away and unlock itself when he/she turns back. Can security be improved combining face recognition with optional/mandatory keyboard passwords or smartcards? For example, when starting the computer or dehibernating it, password/smartcad+face recognition is required. While working with the computer to lock/unlock it when user walk for a moment away, just face recognition is required. One caveat of smartcards, user can leave it always inserted in computer. What about some kind of badge the user always carries with him, which connects to the computer by radio or infrared: Bluetooth, RFID, Infrared. Could a mobile phone/PDA be used for this functionality? No need to carry additional devices. In case of lost or forgotten mobile phone, phone provider could provide a replacement ( if system implemented right) To avoid data lock if encryption keys are lost, use a second trusted party for key storage and recovery, regeneration of smartcards, etc. In worst case scenario, delivery of hard disk to trusted company/service, through trusted delivery system, to have it backed up and/or reinstalled in new HD or notebook. Would it be nice that hardware provider like HP, DELL, etc provided such a combination of hardware and service to companies and profesionals? Wonder is Google would be interested in such a service. If solution implemented through mobile phones, maybe some other companies could find it interesting. By the way, is this idea already patented? ;-)
If what the parent post says is true, it deserves an interesting rating. If it is not true, I'd like to see somebody explain the real situation.
Perhaps you mean, they'll return it to where you used to live before the other nice boys at the FBI have detained you indefinately at an undisclosed location, prior to shipping your ass to Syria for 'interrogation'?
What if the drive has a hiccup for some reason ? Say a sector or even a single byte gets written wrong for some reason (power loss, OS reboot, falling off the lap...). From what I understand of encrypted discs, you loose the whole thing and you cannot build redundancies which would weaken the encryption. How is this issue addressed ?
Non-Linux Penguins ?
We don't encrypt the entire disk because it's total utter nonsense (except if you try to sell a product).
/home (or /Users for us Mac-heads) is sufficient for most machines. So look into system settings and Security and you'll find File Vault. Activate, done. No need to buy some snakeoil some idiot is trying to sell (*).
Most of the data on most machines is neither secret nor special - it's the OS and applications binaries, libraries, graphics, etc.
Encrypting
(*) and he's conveniently not telling you that encryption isn't the end-all solution. There are plenty of ways of breaking even the best crypto without actually breaking it. Getting the key is often easy because people write it down or treat it carelessly.
Assorted stuff I do sometimes: Lemuria.org
Check the following presentation.
n gerprints_in_10_minutes.mp4
http://rehash.whatthehack.org/tmp/wth_spoofing_fi
The guy made a false fingerprint with the help of the original owner of the print within 10 minutes.
It even spoofed the most expensive and best fingerprint scanners.
Fingerprint scanners schould only be used where security doesn't depend on the fingerprint but you want to make someone easily identifiable. Like the mailboxes we have on our network printers. You still can supply a separate PIN code, to prevent just anyone accessing your print jobs.
Same counts for RFID.
>> There is absolutely no need to encrypt the main hard drive.
>> What? You afraid of someone stealing C:\WINNT?
Unfortunately many windows applications including IE and Office write loads of stuff to C drive including temp files and of course that is where the swap file is by default.
Many other badly written windows apps store data in their program files directories.
Therefore encrypting everything is the safest option.
It is unrealistic and unlikely to expect every disk manufacturer or computer manufacturer to include this extra hardware overnight. Howver, it should be possible to make something that can fit between the disk and the data bus that does the encryption or decryption. It would have to be pretty slim to fit into the average laptop, but this should be possible. When the computer boots up with the key in, then the key should get passed to the new gadget, and thereafter the encryption and decryption should be invisible to the user. When the computer is powered down, the key should be lost.
Ordinary USB drives make good physical keys. You can stick these on keyrings. If someone sticks their house keys and office keys on the keyring, then they are unlikely to leave them in the laptop. Once the drive is unlocked, they will stick them back in their pocket.
This ought to give reasonable security to the average Joe without changing their life too much. The weakest point is now the OS. A malicious rootkit could copy the key. To combat this you will probably need some reputable software organization to track the relentless progress of malware - it is beyond what dumb hardware can achieve. You might stick a bootable sector on the USB drive and have a physical switch to enable writing for when you want to change the key or update the software. I am surprised McAffee or Norton haven't made this sort of thing.
Which, incidentally, is an option Apple has been offering on OSX for years...
Herve S.
For years now, it has been possible to get hardware encryption for ATA drives that operates at above maximum ATA spec speed, i.e. it is totally transparent and does not cause any reduction in performance.
The cheap stuff only uses 3DES and they key is a USB thumb drive type device, not very secure. But you can get AES capable devices which use password hashes supplied by the BIOS. Something like this... http://www.enovatech.net/products/mx_info.htm
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I suggest you look at the problems with DRM first. Sample problems with single point of failure, need to be everywhere before it's not holed, total lack of recovery methods (I know that's the point here, but sometimes data loss is even worse than disclosure, and you'd make this choice non-optional).
:-).
Protect what needs to be protected, but leave it off the rest. Disk/file encryption isn't that high a load. If we'd take some processing power back from making fancy animated cursors and pre-spell checks we'd have plenty for encryption. A good step is to stop using Windows - plenty of cycles left then
The OP cites several drawbacks to full disk encryption. So? Protecting people's privacy is important.
My employer, US Bank, requires full disk encryption for all laptops. Even ones, like mine, that do not and never will contain a single bit of customer data.
There's more to it than this.
You said, "Unfortunately, MS encrypted folders use a key that is uniquely generated for your account, and once you lose the account (on the dead computer) you can't decrypt anything."
It is good to provide a stronger warning. Many, many people are losing all their data.
If your Windows XP computer is not part of a domain, and you use Microsoft's Encrypting File System (EFS), you could lose everything you have encrypted! Microsoft is a truly heartless company, I think, because there is no warning about this, even though it has been discussed with Microsoft employees many times.
With a stand-alone computer, EVEN IF YOU SAVE YOUR CRYPTOGRAPHY KEYS, you could lose all your data, because EFS uses your account information as part of the password!
-
Bush lied. Thousands died. Impeach. Imprison.
Be very careful about the software linked here which claims to be able to retrieve your EFS keys! It may not work if you move to a new computer because your old computer failed.
EFS Key says, Encryption password must be known or SAM database must be present (Windows 2000).
Elcomsoft claims: "Finally, AEFSDR is also a state-of-the-art computer forensics tool that could be used by law enforcement, military and intelligence agencies to open secured files."
According to them, EFS provides no protection at all, since anyone can buy the software. But they don't provide information about when their software won't work, such as if you have moved a hard drive to a new computer.
-
Bush lied. Thousands died. Impeach. Imprison.
I hope all you pencil pushing, gonna change the world, self righteous wanna be do gooders arent to traumatized, that you wont need to see your therapist, or go to therapy. Remember last year when Junior didnt get his new tonka toy, oh my, it was horrible, thank goodness we had a good therapist. ( What is this country coming to honey, they even raised the taxes at our country club, where we try to play golf ).
Full disk encryption (FDE) is simple, is easy to use, is readily available, imposes negligible user-visible performance penalties on Windows laptops, and is completely effective in solving "theft of laptop" problems. Not using it should be automatic evidence of gross negligence.
I've deployed both PointSec and DriveCrypt Plus Pack for over five years on a large number of machines, and even for heavy-duty software development, where "rebuild world" takes many minutes, the actual impact--in terms of effect on end-user activities--is negligible.
Sure, if you imagine performance is an issue, you can try any of the vastly more difficult to manage solutions that try to "encrypt only sensitive data", or the even sillier solutions that "delete sensitive data" when the laptop connects to the Internet after it's stolen, but why bother? Try it yourself, and you'll find that performance is NOT an issue in the vast majority of real-world situations. As long as you don't use FDE on heavy-duty I/O-bound database servers and such, you'll rarely notice a difference. Modern computers are so fast that encryption just isn't an issue.
Yes, key management requires some attention. For example, as system administrator, you can just generate some reasonably long passphrases, write them on little cards, and give them to your users to carry in their wallets--and explain the rules. Don't allow users to change them, and keep a copy along with other critical corporate records, and key management is a solved problem. Worried about users losing wallet and laptop simultaneously? Take the cards back after a week, and obfuscate their contents to begin with. Worried about backup? Keep two copies. And so forth. Sure, it could be stronger, and some users will always work around the system, but users will lie, cheat, and steal in other ways, too. In the corporate world, at least, your goal is risk management, not perfection.
Too hard to type a password when you boot the machine? Gosh, fifteen characters at one character per second is, yes, fifteen whole seconds--and anyone will learn to type it more quickly over even a short period of use. Don't change the passwords, either: they're not shared, and not transmitted over networks, so there's virtually no risk of interception--just pick a good one and stay with it.
Backup and recovery also requires some thought. I've actually recovered encrypted drives occasionally, but most recovery is done from file-level backups, where the data is backed up in the clear, over a secured network, and stored on other encrypted volumes. That's really no different when using FDE as not.
If computer theft is the problem, full disk encryption is the answer. It's not the whole answer, and it's not perfect, but it sure goes a long way toward solving the problem. Heck, even Microsoft is offering it in Windows Vista, only a decade or so too late.
For any theft involving Medically related data (e.g. VA) there should be HIPPA penalties involved ($20K per individual). If penalties for one or more of a single person's data (amoungst thousands) should more than offset the cost of full disk encryption.
The procedure is pretty simple.The terrible Debian/Etch partion creation could be much easier to use. That is the only difficulty. Once it is setup at install time no additional packages or software are required. When a new kernel image is installed the initrd will be created with encryption support.
The keys are managed via LUKS. Multiple passphrases or key files can be added to unlock the disk. A backup key could be stored on removable media and stored in a safe place.
Because the encryption is entirely in software and supported natively by the linux kernel an encrypted harddrive could be moved to another computer to recover the data after hardware failure, etc.
Suspend to disk works.
I am using this setup on my laptop. The performance hit on laptops is minimal as the laptop harddrive is already pretty slow. Encrypted swap can be problematic so a good ammount of ram is important. (1GB is more then sufficient for my needs.) I will consider the same setup with my desktop and fileserver when I reinstall those computers.
A similar question was asked in June here: http://ask.slashdot.org/article.pl?sid=06/06/01/23 182544 54668
My answer was this: http://slashdot.org/comments.pl?sid=187274&cid=15
Nothing has changed in the last 4 months...
What's proven to be a very successful solution for me is the use VMware virtual machines encapsulated as files inside a truecrypt volume. The volume is on top of an XFS partition with realtime extension, so you have contiguous extents and the I/O performance is as close as native as you can get. At the same time, I keep the benefits of having a VM, so I can boot it anywhere and I can move/copy the file. I loose the capability of doing good rsync incremental backups because the changing nature of the encrypted file, but I run a full file backup twice a week what gives me acceptable levels of functionality/performance.
Since I started doing that on my Thinkpad T41p, I noticed an 6% increase in my I/O overhead and an 11% on my CPU overhead. If you consider those numbers on a 1.7Ghz laptop, they become virtually irrelevant in a larger configuration with faster disks and CPUs.
The fact that the windows password is the only thing that is between an intruder and the the encrypted data shows the weak point of windows encrypted folders. If one breaks the windows Password (which is far easier than breaking 128 bit encryption) your encrypted data is in the clear.
I think most of the full encryption products can be better than that.
Block-level encryption with a password that's provided to the controller is not DRM. Nor is it a "single point of failure" (at least not anymore than the disk controller itself). All it does is rearrange the bits within each block. If a block gets corrupted you lose no more than without block-level encryption: you lose exactly and only the contents of that block.
You can't use standard backup software with encrypted user directories (e.g., Mac OS X), because the backups copied from such volumes are not themselves encrypted. Backing up the underlying hdimage files is crude because they are not compressible (contents are effectively random already, remember?), so you wind up storing 80 Gb or more instead of 80 Mb of incremental differences. Even an enterprise-wide encrypted file system that works on any drive plugged in is flawed, because it distributes exposure to the very inside-job artistes we'd like to block out in the first place. I suspect encryption is still a choice reserved for individuals and shops who can enforce their own protocols.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
Being a general user and having no dicipline.
http://www.truecrypt.org/ is awsome and easy.
But users...are...getting...worse.
When your concept of file structure is such that you can't navigate to a file outside of "My Documents", security is really futile.
Until companies put a moratorium on hiring art-history majors and giving them a laptop, it's a bit much to ask.
No, you don't put unencrypted keys in the boot partition. The boot loader, kernel, and/or initrd (initial ramdisk) can ask for your password.
/home, /tmp, swap, and anything else where you might write sensitive data. (possibly /var) The rest is optional; do whatever is easy. I strongly suggest encrypting the data itself with a random 256-bit key, then encrypting the key itself with your password. The key gets stored in the unencrypted part of the disk.
:-)
The solution is fairly simple:
Do not encrypt the boot loader, boot config, initrd (if used), or kernel. Encrypt
If hostile people get access to the laptop and then you recover the laptop, you assume that the unencrypted partitions have been trojaned to grab your password. If seriously paranoid, you assume that a transmitter has been installed to broadcast your keystrokes.
I've been using WinMagic's boot-mode (int13h hook + windows storage filter driver) encryption product (SecureDoc) for several months now and haven't had a single problem with it. I routinely perform builds (a disk I/O intensive process) and notice little overhead from the encryption. The initial conversion of your disk, from plain text to encrypted, is extremely slow. I imagine this is due to the fact that the conversion is a transaction-oriented process that can survive power-loss/crashes. After the initial conversion, you'll likely notice little or no overhead from the encryption. I like the fact that none of our (or our partners') IP can leak out the door though my machine (if I misplace it).
You're doing bulk reads. Those are plenty fast either way.
Seeks are painfully slow. You can do about 100 to 300 seeks per second. Crypto won't really change that.
If you really want to see the problem of data exposure reduced to a very tolerable level, the best solution is NOT to fully encrypt the drives of mobile computers, but to change our mobile computing paradigm entirely. Once viable alternatives to general purpose mobile computing are commercially available, we as an industry will finally be able to reduce the events. In other words, once thin-client mobile computing takes off, these full disk encryption products will likely not be needed at all.
Imagine a world where executives, sales people, and most other road-warrior types have a mobile computer that looks like a laptop, but instead of running its own full-blown OS, it simply rides the vast array of mobile carrier networks (like Blackberries currently do) to deliver a virtual desktop hosted in a nice segmented/protected internal network in their employers' data centers (e.g. Citrix, Terminal Servers, or X Windows). Instead of the critical, highly-valuable information floating all over the network and beyond in general purpose computers, we will see a return to the centralized computing paradigm reminiscent of the mainframe days, but with all of the flexibility of the point-and-click user interfaces. Users will interact with their desktops over nice TLS/SSL/IPSEC tunnels over a variety of wireless carrier and 802.11 networks. As long as there's bandwidth, there will be productivity. The thin client hardware will be cheaper and last longer-- another sure foothold that will bring them into the mobile market. And best of all, if one is lost, it will only cost pennies to replace the device since the data does not reside within it. Provisioning will be faster than disk-imaging techniques, and the massive back-end systems can be heavily virtualized with tools like VMWare.
Dan Geer recently said that as Moore's Law for computing power doubles every 18 months, disk space doubles every 12 and bandwidth doubles every 9 months. In our "data in motion" world, the best way for organizations to really protect data is to only "present" it to thin client endpoints. RIM has been wildly successful with introducing us to this concept via its Blackberry product line, it will only be a matter of time before some other company changes the way we think about thin clients as a mobile computing solution.
Before I am blasted by those whose religion is the PC based (decentralized) world, let me be the first to say this will not solve the problem for everybody-- just 99.9% of those cases where laptops are stolen or lost. Thin computing will not necessarily help the end-user market, but it will assist fixing their problems as well.
-Tim
I have a 40 gig partition sitting on my disk which I mount via the cryptoloop kernel module (available by default - nothing special required). I use this as a simple secure data store, and the directories I think are sensitive I put in there via symlink. The CPU (Core Duo 1.83Ghz) doesn't even break a sweat. I have a small shell script that's run by /etc/gdm/Default/Init (if I remember correctly) that pops up a zenity dialog asking for my disk password (which must be at least 25 characters in length) before it asks for my regular username/password. After that dialog, the filesystem is mounted, and I can forget that I'm encrypting anything.
/home is based there (via symlink). I've also created a 'secure' postgres tablespace, which houses my books and records development database snapshots. Very likely I should also be putting various */tmp directories there, as well, and any suggestions would be appreciated. I hadn't even thought of swap, but with 2G of RAM, I barely ever touch swap anyway. I'll be thinking about how to do this as well, though. I don't suspect it'd be much different than mounting the existing datastore -- just an extra swapon command for the loopback device.
Obviously,
I am a small corporation, and very likely the only theft of my laptop would be the typical smash-n-grab thief. I don't consider him the type who would spend the time breaking my encryption, and so I consider this measure to be sufficient to safeguard my information.
I've thought several times about starting a "secure laptop project", where we'd try to release scripts/RPM/deb for various distros (I use Ubuntu) to lock them down right. Really, though, the distros should detect that they're installing on a laptop and prompt for this type of thing at setup. It'd be a lot easier to do this at setup than after the filesystems have been populated -- more consistent and complete as well.
Anyway, my first cup of coffee hasn't kicked in yet, so please forgive me if this isn't totally coherent.
It's exactly what we use. It's not the only enterprise grade whole disk encryption out there, but it's a good one. For enterprise use it's GOT to provide some central mechanism for key recovery as you can't afford to run something that locks users out forever from their machine if they forget the key, it's just not practical. Pointsec has a bit of an overhead, it slows down older laptops but doesn't hurt reasonable spec ones too much...
Yeah, but FileVault is different. FileVault just encrypts your Home directory, this doesn't include parts of the operating system, libraries, or applications. Encrypting those will definitely slow things down. Interesting side note: My iBook claims I need 4084 GB free to encrypt my 23 GB Home directory. But this brings up an interesting issue. With the new Dual-Core processors (like those used in the MacBooks), what kind of performance hit do people take with their usual usage? One core decrypts, one executes code. Theoretically, aside from waiting for code to be decrypted, there shouldn't be a big hit on speed at all.
Rawr
okay, so you encypt all of your stuff. then Uncle Samuel's best comes back to talk you and wants to know what is on your machine. They can torture or your children or take to gawdknowswhere and keep you there until you talk.
Better to say in the clear as you as you live in the police states of the U.S.A.
WHO are "they"???? And why would "they" want to see the laptop?
May I use your sig please?
This is a study I have just completed on this. I welcome any thoughts on this, if they are well thought out and stated.
Requirements:
Full disk encryption required: This is required because of the nature of the security threat our users face.
If the laptop is stolen the entire contents MUST be encrypted in order to keep the data from being recovered. This is our top priority.
If we were to use a repository / single file based encryption mechanism the user would be required to move all files they are working with into and out of that system. Our users usually have no idea where the files are physically located on their hard drive and would have very little probability of moving the correct files to the correct place.
This also leaves open the availability of recovering the "Protected" files from the systems temporary file management system and swap space after they have been opened. This is a common practice which computer forensics investigators use to recover deleted files during an investigation.
As a securities industry regulatory agency our investigators machines become a prime target for identity theft, con artist, corporate espionage, and any other type of thief would like to have a chance to view the investment records of a firm who we regulate. The first line of defense against this would be to not store any exams on the laptop which are not absolutely necessary for the examiner at the time of fielding. This still leave the possibility of their being current exams on the machine and traces of previous exams in the systems temporary and swap file space. In order to guard against this type of data loss and exposure to liability we must encrypt the data with cryptographic industry standard encryption systems. In order to be sure we have encrypted everything, we must encrypt the entire hard drive.
Three levels of authentication required:
1. Something you know (Password)
2. Something you have (Biometric Fingerprint Reader with Smartcard)
3. Something you are (Fingerprint)
When using a password only authentication system our users are exposed to the possibility of a shoulder surfer who is watching either directly or using cameras, remember that most cell phones now come with built in cameras which can be used to photo or video the position of the users fingers while they are typing the password in.
This also exposes the system to a brute force password attack which given time and equipment can eventually come up with the correct password. If the identity thief - Con artist thinks they will be able to make a few million dollars from the data on that laptop they will be willing to go to great lengths and expense to obtain it.
We have chosen biometrics as the 2nd/3rd level of authentication due to the fact that if a smart card / USB key is used it will simply be kept in the case with the laptop therefore negating it as a security solution in the event of laptop theft and reducing the level from 2 to only 1 instead of 3. If the reader is kept in the bag we still have 2 levels with the #3 being the most secure of all.
The biometric solution we have selected uses 4 levels of security in theory by requiring a smartcard and USB reader however we feel that the added security is negated due to the fact that the user will leave the smartcard in the reader and the reader in the bag with the laptop when not being used.
If we try to tell the users they must keep these items separate and not keep them with the laptop they will simply lose or damage them. They usually have enough items to carry while moving from site to site and the more compact the system can be the less chance they will leave something or that some thing will be grabbed with out their notice.
Our users are not usually accessing a network when outside of our office and the access to the local hard drive is protected through the windows logon and file sharing already when they do. This will keep intruders
First: if your people in the field are running 1.2GHz laptops, and want to upgrade to 1.6GHz laptops, can you justify the cost? Probably not, because for most people using laptops, it's not the speed that matters (after a point); it's the portability. Yes, it sucks to be slower, but nobody ever gets a computer that's as fast as they want, and we used to run around with high-end laptops running 550mhz P3s. Your users won't care if they don't know.
Second: if the data is so important that losing access to it (due to a lost key or whatnot) is a big risk, then losing access to it due to physical damage, a bad drive, or theft is equally bad. The thing is, if you're not encrypting, then all of those cases (including theft) are a data LOSS issue; however, you're still open to data THEFT (as opposed to laptop theft.) Add encryption, and your data is safe when the laptop is stolen -- and is no worse off for data loss due to a forgotten key than it is for data loss due to other reasons.
In short: if the security of your data is important enough to justify the LOE involved with training for, implementation of and support of an encryption solution, DO IT, and ignore the speed/lost key issues as red herrings.
I agree that if your threat model is an idiot who wants to make an easy buck off your data, encrypting swap is not important. However, there are two factors the come into play:
/etc/rc.sysinit above the swapon line: /sbin/cryptsetup -c aes-cbc-plain -s 128 -d /dev/urandom create cryptswap /dev/hda3 /sbin/mkswap /dev/mapper/cryptswap
/etc/fstab to replace /dev/hda3 with /dev/cryptswap
.. if I'm swapping hard I'm already screwed on performance.
1) For a huge number of people in the world, the most realistic threat model isn't some crackhead trying to make a buck... it's their own government looking for excuses to give them a hard time. The government might be staffed by twits but the twits have expensive tools. Crypting swap would help.
2) Encrypted swap is utterly trivial and has none of the key management issues of encrypted FS. Really, all OSes should ship with swap encrypted by default. Here is what it took to encrypt the swap on my Linux laptop:
Add two lines to
(hda3 is my swap partition)
And edit
Done.
The key is randomly changed every time I restart the computer and is never stored (except in kernel memory).
Performance?