One of the standards that has become normal in the US federal sector is the requirement that all mobile devices, such as laptops, have encrypted drives. This was a direct result of a number of laptop thefts earlier in the decade that resulted in the supposed leaking of personal information. As a former federal contractor, I watched a number of successful and not so successful methodologies implemented and deployed. Some resulted in real data protection and some resulted in wonderful bricks. In some cases on a regular (read daily) basis.
One of the more successful tools is the Trust Platform Module (TPM) chip. When properly implemented, it allows you to improve encryption, ensure that even if your disk is removed from your laptop, it is still secure and greatly enhances security. So, imagine my surprise, upon rejoining the private sector that my new company does not have a policy for encrypting laptops, even though almost every individual in the company has one.
I was issued a brand-new Dell, with a TPM chip and Windows XP on it. Of course, the first thing I did was download a copy of Fedora and set about reformatting the machine, including setting up the TPM and installing ext4 and enabling Linux disk encryption and went along my merry way, not really thinking about it. That was six months ago.
Like most laptop users, when disk space gets low, you have two options. Replace the disk with a larger one and reinstall or clone the disk to a larger one. After only six months, I was in no mood to do a reinstall, so I decided I would go the clone route. But wait, I had a TMP protected, encrypted disk. How was I supposed to do this? Surely this was a routine sort of thing. So I set out to the Internet and did some research. And was underwhelmed with what I discovered. Essentially, while there are a number of sites that will tell you how to clone your disk (something I am very familiar with), there are almost none that talk about the issues of encryption. Which left me in a bit of a quandary.
Finally, I decided to give it a shot and hope that I could make it work. The first question was what tool to use. I decided to go with dd because it does a bit for bit copy, rather than needing access to the file system. This is important because the disk, for the most part, is encrypted.
The other decision I made was to remove the disk from the machine and put it in a cage and put the second disk in a cage as well. I then booted the diskless machine with a LiveCD (I used Fedora 14 desktop) and connected the disks. Sure enough my encrypted disk popped up and I got an warning indicating that it was encrypted. I canceled the option to type in my password and connected my second disk and set to work doing the copy.
I was moving some 150 GB of disk from one machine to another, via USB. It took close to ten hours to do this successfully. So while dd worked, there are probably faster alternatives. Your mileage may vary.
After the copy was successful, I installed the new disk, pushed the power button and crossed my fingers. I am happy to report that the drive fired up, and after a successful password, decrypted itself and I was back in business.
But wait a minute.... Yes, what about the TPM chip? Remember that one of the things a TPM chip is supposed to do is prevent me from reading a disk not attached to the motherboard. I should not only not have been able to read it once mounted in the cage, I should not have been able to copy it at all - at least not to any sort of usable form. And I did. Why? Well, my leading thought is I did not set up the module correctly or that Dell has not set it up correctly to add the additional level of protection to the disk. It is also possible I did not install Linux in such a way to take advantage of the chip. In either case, while I am getting security through the Linux-based disk encryption, I am not getting any additional protection from the TPM chip.
The takeaways then are this. You can use dd to copy Linux-encrypted disks successfully. And never assume you are secure unless you test your security. Better yet, have someone else test it. Chances are you are not as secure as you think you are.
Using dd to clone an encrypted disk
These instructions assume you are using similar drive types (such as SATA), have access to a pair of cages or disk carriers, and a significant amount of time to copy the data.
1) Remove the disk you want to copy from the system and place it in a cage. This step is optional.
2) Set up your secondary disk in a cage.
3) Boot your system with a LiveCD. This will allow you to unmount the disks you are planning to clone, which is critical to a successful clone.
4) Open a couple of terminals. In one terminal su to root or execute the following command with sudo:
tail -f /var/log/messages
This will open a running window from your messages file, which is important for determining what disks are where as well as any error messages that are not logged to the console during the dd process. /var/log/messages is the default location for most OSs. Double check to see if it is the same for you.
5) Plug in your source drive and watch the log file for the name assigned to it. For example, if it is a SATA drive, and there are no other drives connected it will most likely pop up as /dev/sdb. (If you did not remove your drive, it is likely /dev/sda.)
6) Plug in the second drive and note its name. In my case it was /dev/sdc.
7) If you need to format your new drive, now is the time. Create a single partition, and make sure you choose ext4 as the file type. Once the disk is prepared, unmount both disks.
8) In a terminal, as root, run the following:
dd if=source drive of=destination drive
dd if=/dev/sdb of=/dev/sdc
Go and prepare Thanksgiving dinner (and possibly get a leg up on Christmas dinner if you have a large disk).
9) Once the copy is complete (and you will know because the command prompt will come back), install your new disk into your machine and boot it up.
Best of luck!
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- Build a Skype Server for Your Home Phone System
- Why Python?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Reply to comment | Linux Journal
7 min 3 sec ago
- Reply to comment | Linux Journal
57 min 16 sec ago
- Not free anymore
4 hours 59 min ago
8 hours 46 min ago
- Reply to comment | Linux Journal
8 hours 54 min ago
- Understanding the Linux Kernel
11 hours 9 min ago
13 hours 38 min ago
- Kernel Problem
23 hours 41 min ago
- BASH script to log IPs on public web server
1 day 4 hours ago
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?