You are not logged in.

#1 2012-09-23 13:50:23

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

[solved] Switching to encrypted disk

I have been thinking for a while that I should really have set my laptop up to use encryption. I recently installed Fedora on another machine which offers encryption during installation. Obviously that hasn't told me much about how it works but it has more-or-less convinced me that it can work well.

I've been reading the wiki on this and I have a few queries. I'm thinking of using dm-crypt + LUKS partly because that's what Fedora has used (so setting it up on Arch would kill two virtual birds with one virtual stone as I'd hopefully understand it better generally) and partly because it seems to be fairly standard, well-tested and to fit the kind of thing I'm looking for.

1) I understand that securely wiping the hard drive with /dev/urandom can take a while. Is there any way of estimating how long this might take in my particular case? I saw the examples in the wiki but I'm not sure how to relate those to my situation.

2) I assume that it is better to wipe the entire disk rather than simply wiping partitions individually. Is that correct? (I'm thinking that wiping partitions individually won't actually get everything even if all partitions are wiped in this way and that it won't create (non-)uniformly random across the entire disk.)

3) Can I copy the contents of partitions back to the encrypted set up from backup or is it necessary to reinstall the system from scratch? This seems like an obvious question and I'm convinced it must be in the wiki somewhere but haven't been able to find it so far.

4) The wiki mentions having /boot alone unencrypted. Am I correct in thinking that the EFI partition should also be unencrypted? I can't see how the machine could possibly boot otherwise.

5) Is it possible to require decryption on wake from sleep? (I'm pretty sure the answer to this is no but I'm not sufficiently confident of my understanding to be certain.)

6) EDIT: The wiki recommends using:

#dd if=/dev/urandom of=/dev/<drive> bs=1M

but elsewhere I've seen instructions using bs=4M because it is faster. Is it faster and, if so, is there any reason not to use it?

Last edited by cfr (2012-11-10 23:18:08)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#2 2012-09-23 14:07:12

65kid
Member
From: Germany
Registered: 2011-01-26
Posts: 663

Re: [solved] Switching to encrypted disk

cfr wrote:

1) I understand that securely wiping the hard drive with /dev/urandom can take a while. Is there any way of estimating how long this might take in my particular case? I saw the examples in the wiki but I'm not sure how to relate those to my situation.

you can just as well use /dev/zero, although I don't know if it is actually faster than urandom. you usually use dd for this which doesn't show any progress. You can however send SIGUSR1 to dd to see how fast it is going (killall -SIGUSR1 dd). I bet there are tools for this which actually show you the progress, but none come to mind.

cfr wrote:

2) I assume that it is better to wipe the entire disk rather than simply wiping partitions individually. Is that correct? (I'm thinking that wiping partitions individually won't actually get everything even if all partitions are wiped in this way and that it won't create (non-)uniformly random across the entire disk.)

if you wipe the partitions individually you won't overwrite the MBR and any space that is between the partitions (although there usually shouldn't be any by my understanding).

cfr wrote:

3) Can I copy the contents of partitions back to the encrypted set up from backup or is it necessary to reinstall the system from scratch? This seems like an obvious question and I'm convinced it must be in the wiki somewhere but haven't been able to find it so far.

should work, you just have to make sure that mkinitcpio / the initramfs is set up correctly (encrypt hook etc.).

cfr wrote:

4) The wiki mentions having /boot alone unencrypted. Am I correct in thinking that the EFI partition should also be unencrypted? I can't see how the machine could possibly boot otherwise.

yes, EFI partition must be unencrypted too, kernel and initramfs must be readable after all.

cfr wrote:

5) Is it possible to require decryption on wake from sleep? (I'm pretty sure the answer to this is no but I'm not sufficiently confident of my understanding to be certain.)

should be possible with hibernate, but not with suspend. Just lock your screen before suspending. whoever wants to get around the screenlocker must at least shut down first, and then your harddrive is locked again. wink

Offline

#3 2012-09-23 14:10:23

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: [solved] Switching to encrypted disk

Offline

#4 2012-09-23 14:13:25

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved] Switching to encrypted disk

I see you are going to go through with encrypting your stuff.  As I've mentioned to you before, I have never actually done this before.  Though I have looked into it a little.  In my mind, it is pretty apparent that if /boot is left unecrypted, the ESP should definitely not be encrypted.  Especially since it is not particular to your operating system, and the method you mention is encrypting on a software level. 

Speaking of which, since you have a Thinkpad, can't you do full disk encryption?  That is, do it via hardware, rather than at a software level.   See this FAQ (top hit from google):

http://support.lenovo.com/en_US/researc … MIGR-69621

Maybe that might be worth looking at before you proceed.  Also, I see no reason not to use bs=4m, but I am also unfamiliar with any potential differences byte size might create on a bit level.  But my assumption is that if you are randomizing anyway... whats the difference between 4M of random and 1M of random.  Can anyone shed more light on that?

In any case, I wish you the best of luck and look forward to reading your experience.


Edit: I just noticed that

# hdparm -I /dev/sdX

gives you info on the time it will take to securely erase your device.  I assume that this is not via dd, but might be useful info.
My Momentus XT says "100min for SECURITY ERASE UNIT. 100min for ENHANCED SECURITY ERASE UNIT" and my mSATA Mushkin SSD says "2min for SECURITY ERASE UNIT"

Last edited by WonderWoofy (2012-09-23 19:02:07)

Offline

#5 2012-09-23 20:24:53

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved] Switching to encrypted disk

Thanks to everyone for your answers.

I'm not clear whether frandom is as good as urandom but perhaps it is good enough?

WonderWoofy wrote:

Speaking of which, since you have a Thinkpad, can't you do full disk encryption?  That is, do it via hardware, rather than at a software level.   See this FAQ (top hit from google):

http://support.lenovo.com/en_US/researc … MIGR-69621

Maybe that might be worth looking at before you proceed.

Thanks for this. I'm not sure if I can do this or not. That is, I'm not sure if you have to have a special disk (a self-encrypting disk?) in order to use this or whether there is something which any ThinkPad can make use of.

The user manual for this model explains several passwords which may be set in BIOS (supervisor, power on, user, hard disk... - there seem to be rather a lot).

Regarding hard disk drives specifically, it says:

Hard disk security

Your computer supports an enhanced security solution for solid state drive or hard disk drive. To protect
passwords from unauthorized security attacks, several of the latest technologies and algorithms are
integrated into UEFI BIOS and hardware design of ThinkPad notebooks.

To maximize security, do the following:

1. Set a power-on password as well as a hard disk password for your internal solid state drive or hard disk
drive. Refer to the procedures in “Power-on password” on page 56 and “Hard disk passwords” on page
57. For security, a longer password is recommended.

2. If a Disk Encryption hard disk drive and Encryption solid state drive is installed in your computer,
be sure to protect the contents of your computer memory from unauthorized access by use of drive
encryption software.

3. Before you dispose of, sell, or hand over your computer, make sure to delete data stored on it. Refer to
“Notice on deleting data from your hard disk drive or solid state drive” on page 63.

Note: The hard disk drive can be protected by UEFI BIOS.

Disk Encryption hard disk drive and Encryption solid state drive

Some models contain the Disk Encryption hard disk drive or Encryption solid state drive. This feature
helps to protect your computer against security attacks on media, NAND flash or device controllers by use
of a hardware encryption chip. For the efficient use of the encryption feature, be sure to set a Hard disk
passwords for the internal storage device.

I'm pretty sure my hard drive is not a special encryption drive. hardinfo shows the model as ST320LT007 - 9ZV14 and although I cannot find this model exactly, I suspect it may be the ST320LT007 - 9ZV142 which is not an SED according to Seagate's product literature.

So I guess I'm pretty confused about what the security features enabled just by (1) are. The instructions for securely deleting data before selling the computer, for example, suggest using Lenovo payware/pay services which seem to require a couple of hours unless "Encryption solid state drive or Disk Encryption hard disk drive is supported and installed in your computer" in which case you can just delete the cryptographic key. So that makes me think that whatever the general options in BIOS do, they don't protect the hard drive in a way which would prevent the data being read. I'm not even clear whether the "enhanced security features" are just *supported* - i.e. if you install a special drive - or whether they are supposed to have some effect even with a standard set up - i.e. without installing such a drive.

Maybe somebody here knows something about Lenovo's security on ThinkPads?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#6 2012-09-23 21:01:33

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved] Switching to encrypted disk

I know that the passwords on thinkpads are pretty secure.  Whereas most manufacturers use the cmos to store bios password, Thinkpads have a separate non-volatile chip that stores the passwords.  So you cannot simply remove the cmos battery like most computers.  But this is still not disc encryption and if you were to move the hdd to another computer I am fairly certain you could simply boot it right up.  You may need to look into that further though. 

I think that for most a thinkpad bios password would be enough, but you have mentioned to me before that you would prefer the full encryption for your university. 

Also, upon further investigation, you are indeed correct that it seems that you need a special hdd for the thinkpad full disk encryption.

Offline

#7 2012-09-23 22:19:09

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved] Switching to encrypted disk

Shame, though.

It probably is enough. I just tend to be paranoid.  (I doubt the university cares much - in my experience, universities tend to care only after they've been sued. Sometimes not even then.)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#8 2012-09-24 00:26:17

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,429

Re: [solved] Switching to encrypted disk

The HDD password you set in Lenovo bios (as any other bios allowing to set one, which are not too many) actually stays on the HDD controller. So, if you put the drive into another machine, you still have to input it to boot it. But there are ways to shortcut that (electrically) and without encryption (SED or other like dm-crypt) the data can be recovered without the password.

The HDD password itself has nothing to do with the encryption used even in self-encrypting drives. It 'merely' authorizes access. The other way round, without a HDD password set a SED drive looks as transparent as any other drive when mounted (transparency is relative :-)
When setting a HDD password, one should also be aware that there have been cases of it getting corrupted (another reason to backup).

If you go forward with it, my 5 cent to your initial questions:
1. As the wiki also states: When choosing the method, it's worthwhile to remember that the randomization just has do be done _once_ as long as the drive/partition is used encrypted.
2. You can also do it afterwards (that's a pretty elegant way the Luks wiki has on that)

Offline

#9 2012-09-24 01:10:10

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved] Switching to encrypted disk

Interesting.

According to Lenovo, if you have an SED drive then setting the HDD password encrypts the key used for encryption. That's why I wasn't clear what it did if you didn't have such a drive.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#10 2012-09-24 11:16:29

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,429

Re: [solved] Switching to encrypted disk

Yes, I remember reading that also somewhere and believe they got that wrong. At least if they were referring to the HDD password (aka ATA security), because that's an old ATA industry specification.

I'd happily be wrong myself, because user-encrypting the SED-key would make much more sense. A SED-chipset could do that (take the HDD password as passphrase), but afaik it's not done. What they probably meant to say is that the HDD password itself is encrypted before it is stored on the drive. 

Yet also if I am right, I'd still give them credit for keeping the Bios option while a lot other manufacturers just don't provide it, probably because it can cause service problems.

Offline

#11 2012-09-25 12:46:09

teateawhy
Member
From: GER
Registered: 2012-03-05
Posts: 1,138
Website

Re: [solved] Switching to encrypted disk

I enabled the Full Disk Encryption on my thinkpad after reading this yesterday. My SSD has the 'FED' specification. You can enable it easily by setting a passwort for the harddrive in the BIOS.  It_will_not_erase your existing installation of arch. This is by far the easiest way of encryption in my opinion.

Offline

#12 2012-09-25 14:10:25

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved] Switching to encrypted disk

Yeah, but the key is that you have a FDE specified hard drive.  Out of curiosity, what model do you have?

Offline

#13 2012-09-25 14:25:07

teateawhy
Member
From: GER
Registered: 2012-03-05
Posts: 1,138
Website

Re: [solved] Switching to encrypted disk

The model has the msata size, that means you need a special connector in your computer. It is called XM13 mSATA SSD. I do not want to write the brand here.
link to manufacturer website.
I use it in my laptop together with a seperate HDD, that means i can have two disks in a 12 inch laptop.

Offline

#14 2012-09-25 19:07:07

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved] Switching to encrypted disk

Yes I ma familiar with the msata drives.  I use a Mushkin Atlas 120GB mSATA, and it is amazing.  It is not the device that was an option for the computer though.  I could not justify spending so much money (IIRC $50-$60) for a 15GB SSD.  That just makes no sense.  So I opted to just buy my own, and surprisingly they were not that expensive compared to normal form factors.


Edit: If that link is the drive you have, it is an adata.  Thy are really nice drives.  I actually was eyeing one of those when I was searching for mSATA ssd's.  So did yours come with the computer, or was it preinstalled as a cache drive?  Because I thought that Lenovo had an agreement with SanDisk for their caching drives.

Last edited by WonderWoofy (2012-09-25 22:34:30)

Offline

#15 2012-09-25 22:49:56

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved] Switching to encrypted disk

Even if I were in the market for an SSD, I believe my choice would be limited as the slot in the x121e takes a smaller-than-standard drive (iirc).

Anyway, it looks like I definitely need to do this the long way if I do it at all. I'm not sure whether setting passwords in BIOS adds any security or whether it just makes it more likely something will go wrong smile.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#16 2012-09-25 23:08:00

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved] Switching to encrypted disk

I do think it adds en element of security.  But I think that any truly motivated individual would be able to bypass it, even if the HDD password is stored on the drive itself.  But I think since you origianlly created this thread looking for opinions on encryption, you should go with your original plan of dm-crypt+LUKS, as (link you mentioned) it seems to be the common way of doing it.

Offline

#17 2012-09-25 23:15:06

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved] Switching to encrypted disk

Yep. I think that's what I'll do but I will wait until I've got time to do it at my own pace as I'd rather not screw it up. I'll report back then with triumph or disaster... (though I doubt I'll manage to "treat those two impostors just the same"!).

Last edited by cfr (2012-09-25 23:15:49)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#18 2012-09-25 23:17:30

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved] Switching to encrypted disk

I sure hope it is not disaster... I have faith that you can do it, you seem competent enough.  You certainly do your share of documentation reading.  I would have to agree that it is probably not something you should rush.  Though that seems like something i might try to do... "I have a couple hours, I'm going to try something that could destroy my computer!"

Offline

#19 2012-10-02 09:48:14

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,429

Re: [solved] Switching to encrypted disk

cfr wrote:

Anyway, it looks like I definitely need to do this the long way if I do it at all.

I also like your approach to it. Two of my reasons:

Hardware vs software
SSDs are still a fast moving technology with (imho) infancy problems. For encryption one example was a number of the manufacturers re-calling drives from the shelves (!), because the controllers on it failed the advertised encryption level (i.e. they encrypted, but only with a fallback method afaik). A hardware bug that passed the product development and quality control of all those involved firms. That was this spring only. 

Your choice is FOSS
Amongst other benefits, it gives more user-flexibility to control (e.g. access to and backup of) the encrypted data and is more fun anyway. That's why we are here smile In the latest LUKS they added an amazing (experimental) feature to allow the encryption of an existing unencrypted system by the way. So it's another option for your "longer term planning" coming.

Offline

#20 2012-10-02 13:20:36

Pres
Member
Registered: 2011-09-12
Posts: 423

Re: [solved] Switching to encrypted disk

I recently just went through this myself. Full disk encryption was something I had wanted to do for awhile, but figured it would be difficult to migrate my system to.

What I ended up doing was taking a spare hard drive and setting it up with LVM over LUKS exactly as I wanted. I first made sure to regenerate my initramfs with the needed modules and hooks (jasonwryan has a good guide on it here. Just remove the RAID parts if you are not using that). I then mounted the partitions with a live CD and rsynced my entire system over to it. I was able to boot into it and everything worked fine.

Then I just erased my main drive with /dev/urandom, and set everything up the same way I did before. Once I rsynced everything back over, it worked perfectly.

You don't have to do it this way of course, but I decided this was the best way as I could do a test run and make sure everything worked fine first. I also kept a second backup while doing this just in case.

Offline

#21 2012-10-03 00:32:45

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved] Switching to encrypted disk

I don't have enough hard drives to do that but thanks anyway. And I don't have an SSD.

I do wonder how much this is going to impact on performance once I find time to set it up but I guess everything has a downside smile.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#22 2012-10-03 03:53:37

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved] Switching to encrypted disk

I am also curious how much harder it will make your laptop work.  I know that you have already been experiencing power regressions and/or heat increases.  So what is this extra work going to do with that already occuring.

Offline

#23 2012-10-03 10:49:56

hunterthomson
Member
Registered: 2008-06-22
Posts: 794
Website

Re: [solved] Switching to encrypted disk

Hello cfr smile

I have read through your post and all of the comments and feel that I can offer some useful information. I have recently implemented full-disk encryption on my laptop and home server, also spent 2 months watching and reading everything I could find about disk encryption..... Plus I am vary passionate about the subject of security tongue

To make it easier for me to write and for you to understand I will simply go through all your numbered questions one by one.

1) Instead of using dd install and use dcfldd from the extra repo. This will tell you what the heck is going on while it is writing to a device i.e. KB written and blocks written. Yes, use /dev/urandom if you don't first fill your hard disk drive with random data the attacker will be able to see where the encryption starts and stops … bla bla, it will leak information that can make it easier to crack the crypto. Basically, how long it will take is a moot point because it is so critical. However, you can dcfldd if=/dev/urandom of=/home/$(whoami)/speed.test … let it write out 1G and Ctl+C that calculate how long it will take.

2) Hum well, yes-no; kind of; yes. However, Meh, you don't have to bother with that on a hard drive. I would really suggest you delete all the partitions except the UEFI and /boot. Then create one big one and encrypt that. Then put LVM on top. That way you don't have to do the whole chain-encrypted stuff nor mess with the /etc/crypttab file at all.

3) I am a vary strong advocate of TAR for backups. First make sure you have enough disk space for the backups, or use like sshfs to mount a remote partition to write the tar backups to.
.......Shoot, I just spent the past two hours writing this backup script tongue

#!/bin/bash
#
# GPLv2
# dwyer AT tormail.org
#
# Backup with TAR script
# Created on: Tue Oct  2 22:18:48 HST 2012
#

#
# Change this directory to whatever directory
# you want the backups to be written to
BACKUP_DIR=/mnt/backup

#
# This is the array of directories to backup
# Change as needed but this looks good to me for a full backup
# Note: If recovering to a an empty file system,
# You will also need to create the directories that are not backed up
# Becuase they contain temp data
# Such as, /run /tmp /sys /proc ...and stuff
BACK_ME_UP=(boot bin sbin lib lib64 etc root home usr srv var opt)

#
# This will create a variable named DAY_WEEK_YEAR
# With the value Week-in-year followed by the Year
# Example: Tue-40-2012
# We will prepend this date to the name of each tar file created
DAY_WEEK_YEAR=`date +%a-%V-%Y`

##
## DO NOT CHANGE ME
## THESE ARE DEFUALT SETTINGS
##
## For questions asked in the recover function
ROLLBACK_DATE='Tue-40-2012'
RECOVER_yn='n'
##
## Default answer to main() question
BACKUP_OR_RECOVER='bla'


main () {
	#
	# Check if the user is root
	# If not warn them that the permissions will not be recoverable
	# and not all files will be readable
	# If the script is not run as root
	if [ $(whoami) != "root" ] ;then
		echo '!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!'
		echo '  You Are Not Running As Root User!'
		echo '  Not all files will be readable'
		echo '  Not all permissions will be recoverable'
		echo '!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!-!'
		echo ''
	fi


	MAIN_LOOP=true
	while $MAIN_LOOP ;do
		#
		# Ask the user if they would like to backup
		# Or if the user would like to recover
		echo 'Current backup location'
		echo $BACKUP_DIR
		echo ''
		echo 'Current list of directories to backup/recover'
		echo ${BACK_ME_UP[@]}
		echo ''
		read -p 'Backup, Recover, or Exit ? (b/r/x): ' BACKUP_OR_RECOVER
		if [ -z $BACKUP_OR_RECOVER ] ;then
			BACKUP_OR_RECOVER='null'
		fi

		if [ $BACKUP_OR_RECOVER == 'b' -o $BACKUP_OR_RECOVER == 'B' ] ;then

			backup
			MAIN_LOOP=false

		elif [ $BACKUP_OR_RECOVER == 'r' -o $BACKUP_OR_RECOVER == 'R' ] ;then

			recover
			MAIN_LOOP=false

		elif [ $BACKUP_OR_RECOVER == 'x' -o $BACKUP_OR_RECOVER == 'X' ] ;then

			MAIN_LOOP=false

		else
			echo ''
			echo ''
			echo ''
			echo ''
			echo 'YOU MUST ENTER: b or r or x'
		fi
	done
} # End of Main Function

backup () {
	#
	# Change to the / root directory so we know where we are
	cd /

	#
	# Loop through all the directories in $BACK_ME_UP
	# Create a .tar file backup of each directory
	# Save the new .tar backup in the $BACKUP_DIR
	# Name the backup files $DAY_WEEK_YEAR-DirectoryName.tar
	for i in ${BACK_ME_UP[@]} ;do
		echo "Backing up $i"

		#
		# Create a tar file in $BACKUP_DIR named $DAY_WEEK_YEAR-$i.tar
		# of Direcory in $BACK_ME_UP
		tar --create --preserve-permissions --file=$BACKUP_DIR/$DAY_WEEK_YEAR-$i.tar $i

		echo "Done Backing up $i"
		sleep 3
	done
} # End of Backup Function


recover () {
	#
	# Ask the user for the date string to rollback to
	# Save it to the variable $ROLLBACK_DATE
	echo 'Enter the Date-String you would like to rollback to'
	echo ''
	read -p 'Such as, Tue-40-2012 : ' ROLLBACK_DATE
	echo ''

	#
	# Change to the / root directory so we know where we are
	cd /

	#
	# Loop through all the directories in $BACK_ME_UP
	# Un-tar each of the backup.tar files
	for i in ${BACK_ME_UP[@]} ;do
		#
		# Check if the file exists and is readable
		if [ -r $BACKUP_DIR/$ROLLBACK_DATE-$i.tar ] ;then
			RECOVER_LOOP=true
			while $RECOVER_LOOP ;do
				#
				# Ask the user if they would like to recover the directory
                                echo ''
				echo 'Recovering this directory is a Destructive Process!'
				read -p "Recover $BACKUP_DIR/$ROLLBACK_DATE-$i.tar ? (y/n):" RECOVER_yn
				echo ''
				if [ -z $RECOVER_yn ] ;then
					RECOVER_yn='null'
				fi

				#
				# If the user entered y or Y then recover the directory
				if [ $RECOVER_yn == 'y' -o $RECOVER_yn == 'Y' ] ;then
					echo "Recovering directory $i"
					RECOVER_LOOP=false

					#
					# Extract and Preserve all the permissions for the backuped.tar file
					tar --extract --preserve-permissions --file=$BACKUP_DIR/$ROLLBACK_DATE-$i.tar

					echo '...'
					echo "Done Recovering directory $i"

				elif [ $RECOVER_yn == 'n' -o $RECOVER_yn == 'N' ] ;then
					echo "$BACKUP_DIR/$ROLLBACK_DATE-$i.tar Will NOT be recovered..."
					RECOVER_LOOP=false

				else
					echo ''
					echo "You Must Enter y or n"
				fi

			done

		else
			echo "$BACKUP_DIR/$ROLLBACK_DATE-$i dose not exist or is not readable"
		fi
	done
} # End of Recover Function

#
# Execute the Main Function
main
exit 0

4) Yes, both the /boot and UEFI partitions need to be readable
Idealy, you would encrypt your /boot partition too; THEN create a GRUB2 Boot CD with your kernel, initramfs, and menu list (like how I did it in the linked post below). That way the unencrypted kernel and initramfs will be on Read-Only media. Second best would be to put your boot partition on a USB Stick that you always carry with you., and add noauto to the fstab for /boot, so you can just pull out the USB Stick after it boots.

https://bbs.archlinux.org/viewtopic.php?id=144100

5) Yes, you can Sleep and Hibernate with LUKS-dm-crypt. However, I have not tried it. I never use hibernation or sleep... But it is suppose to work.

6) Sure you can use 4M. This just specifies the chunk size of data that will be written to the disk. So, like if you see disk benchmarks 4k writes are slow as crap but larger size writes are faster. On my SSD I used 512K because it is the Erase Block size of my disk.

NO!, Do NOT use the Proprietary Hard disk/SSD “Black Box” encryption systems. There is no way you can trust them because you don't know how they work. The ones that people do know how they work are crazy insecure. Like they use the ATA Password for the encryption i.e. ya that password that is written in plain text to the hard disk.

All the new Ivy-Bridge CPU's and AMD CPU's support AES-NI which is Hardware Accelerated Encryption. However, this allows you to use your own Open Source encryption system with it. Unfortunately, your i3-2367M dose not have this. AES 256 is “kind of” broken in cbc mode is. It is down from 2^256 to 2^99 or 6 of 14 rounds are broken.... correct me if I am wrong. As such, and that you don't get any hardware acceleration... you may want to take a tiny more of a hit in speed and go with TwoFish. Also specify the -h hash to use for your LUKS password... I have AES-NI so this is what my cryptsetup like looks like

cryptsetup -h sha512 -c aes-xts-plain64 -y -s 512 luksFormat /dev/sdX#

Heck, here are all the relevant files for my LVM-on-LUKS, /boot on USB-drive & grub2-bios installed to the USB-drive

/etc/mkinitcpio.conf

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
MODULES="aesni_intel ata_generic ata_piix nls_cp437 ext4 intel_agp i915 dm-snapshot"

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=""

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options
# like so:
#    FILES="/etc/modprobe.d/modprobe.conf"
FILES=""

# HOOKS
HOOKS="base udev autodetect pata scsi sata keymap usb encrypt lvm2 filesystems usbinput fsck"

# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.


# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=""

/etc/fstab

#
# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
tmpfs           /tmp    tmpfs   nodev,nosuid,noatime,nodiratime,size=10G 0 0

# UUID=XXXXXXXXXXXXX   LABEL=ROOT
/dev/mapper/VolGroup00-lvolroot /               ext4            rw,noatime,nodiratime,discard,stripe=128,data=ordered,errors=remount-ro0 1

# UUID=XXXXXXXXXXXX LABEL=VAR
/dev/mapper/VolGroup00-lvolvar  /var            ext4            rw,noatime,nodiratime,discard,stripe=128,data=ordered,errors=remount-ro0 2

# UUID=XXXXXXXXXXX LABEL=HOME
/dev/mapper/VolGroup00-lvolhome /home           ext4            rw,noatime,nodiratime,discard,stripe=128,data=ordered,errors=remount-ro0 2

# Mount the downloads folder in to a tempfs
tmpfs           /home/USER/Downloads    tmpfs   rw,nodev,noatime,nodiratime,noexec,nosuid,uid=1000,gid=100,mode=700,size=10G 0 0

# UUID=XXXXXXXXXXXX LABEL=BOOT
/dev/sdb1               /boot           ext4            rw,noauto,noatime,nodiratime,stripe=128,data=ordered 0 2

/etc/default/grub
Only Changed GRUB_CMD_LINUX=

GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda1:root:allow-discards"

Commands I used to create my disks setup

cryptsetup -h sha512 -c aes-xts-plain64 -y -s 512 luksFormat --align-payload=8192 /dev/sda1

cryptsetup --allow-discards luksOpen /dev/sdb2 cryptroot

pvcreate /dev/mapper/cryptroot

vgcreate VolGroup00 /dev/mapper/cryptroot

for i in root var home ;do
	if [ $i == “root” ] ;then
		lvcreate -L 25G VolGroup00 -n lvol$i

	elif [ $i == “home” ] ;then
		lvcreate -L 77G VolGroup00 -n lvol$i

	elif [ $i == “var” ] :then
		lvcreate -L 8G VolGroup00 -n lvol$i

	fi
mkfs.ext4 -b 4096 -E stride=128,stripe-width=128 /dev/mapper/VolGroup00-lvol$i
done

Last edited by hunterthomson (2012-10-03 22:25:24)


OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec

Offline

#24 2012-10-03 14:51:15

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,429

Re: [solved] Switching to encrypted disk

@hunterthompsom: No, what the heck. That's an amazing post with a great deal of helpful hints.

Just three comments, if I may:
3) Great, I am sure you not only wrote but also tested your script. I would still put a disclaimer into it to inform any potential user. 

5) I have totally avoided EFI bios modes so far, but have used Luks hibernate and suspend on numerous machines and never ever had any issues (if the machine resumed without of course). Suspend usually works out-of-the-box with Luks, The wiki has everything you need to know for hibernate. Resuming from hibernate requires LUKS-unlocking, with suspend the blockdevice stays unlocked.

6) Out-of-topic for the inclined: The SHA2-successor has just been announced yesterday. The winners of the competition work for chip manufacturers other than the one you refer to.
edit: Noting that for equality reasons. smile

Last edited by Strike0 (2012-10-03 15:04:30)

Offline

#25 2012-10-03 21:52:58

hunterthomson
Member
Registered: 2008-06-22
Posts: 794
Website

Re: [solved] Switching to encrypted disk

tongue Ya, I kind of got carried away..., but I justified spending the time because I also plan to use this a my personal documentation.

3) Yes, I did test it. Ya, I guess I should worn the user that when they recover they will be overwriting or deleting the directories in question. I do at least ask the user before recovering each directory.... Okay, change made.

5) Awe, cool. That is good to know.

6) Owe cool, SHA-3 has been named. I'll have to look into that. Thanks for the info.

Last edited by hunterthomson (2012-10-03 21:57:42)


OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec

Offline

Board footer

Powered by FluxBB