The Case of the Stolen Laptop: Mitigating the Threats of Equipment Theft
by Steve Riley
Senior Program Manager, Security Business and Technology Unit
See other Security Management columns.
On This Page
The fear of having laptops stolen is a huge worry for all organizations. Maybe it’s even happened to you (I hope not!). The solution is simple, really -- don’t let your laptop get stolen. (I can hear you laughing now.) Keep the thing with you at all times, or leave it in your hotel room when you don’t want to carry it around. Yes, everyone has heard the warnings about hotel room theft, but I’ve never had something stolen from a hotel room and I spend well over 200 nights a year in hotels. (If you travel to a location where the general population has kleptomaniac tendencies, stay in hotels that offer safes in the room.) You’re far more likely to leave your laptop or PDA or smart phone or USB drive lying on the seat in a taxi or on the counter at a bar.
Certainly there are places where theft is a possibility: conferences and airports are common, and even offices can be unsafe at times. I carry a laptop locking cable in my computer bag and use it to lock my laptop to the table whenever I’m presenting at a conference and will need to be away from the room -- but only if I believe the venue to be relatively safe (yes, this is a subjective judgment). If I judge theft to be a danger, I’ll pack the computer back in its bag and carry it around. At airports the laptop is either in my lap or in its bag, and the bag is always in hand or on the floor within reach. Try not to fall asleep in the airport -- that’s what business class seats are for. If you absolutely must sleep at the airport, consider a motion-sensing alarm. But you might be more likely to trigger it yourself as you shift during your slumber.
Whatever you do, don’t advertise the fact that you’re laden with all the latest and coolest battery-powered gadgetry. Are you guilty of carrying a laptop, PDA, digital camera, music player, mobile phone, and a portable video game? What do you carry all this in? Be discreet, even aiming for invisible: avoid computer-branded carrying cases, common accessory brands of bags or packs, or anything that gives away your love for all things transistorized. To carry around bags with logos is to invite unwanted attention -- thieves know that companies sell thousands of logo-emblazoned carrying cases to business travelers toting the latest desirable electronic gear. Instead, take your kid with you and go shopping for a backpack that’ll hold everything you’ve got. It’ll make you feel young again -- or at least be a useful educational experience, not to mention an excuse to exchange your shoulder-killing briefcase for something healthier and more ergonomic.
The mobility of laptops demands additional protection of the often critical and confidential data they store. Three features of Windows 2000 and Windows XP can help you keep your information out of the hands of a thief who somehow manages to get hold of your laptop: passwords, EFS, and SysKey. Do realize that if you use these features, you will most likely frustrate the thief so much that he or she will destroy your laptop in anger and disgust, but this is far preferable to seeing the development plans and source code of your next killer product posted online.
If your laptop is joined to a domain, each time you start it—even when you aren’t physically on the corporate network—you still have to enter your network password. Your computer keeps a set of “cached credentials” in your account profile on the hard drive, requiring you to authenticate before gaining access to your data. These credentials are first hashed with MD4 and then again with MD5; the second hash creates what’s called a “password verifier.” Only the verifier is stored, protected by the computer’s system key (see the section on SysKey below for the details) and is highly resistant to tampering.
If you have a stand-alone laptop, you should still use a password for all local accounts on the computer. On non-domain-joined computers running Windows XP the Administrator account initially has no password. Local accounts that lack passwords can’t be accessed at all over any network -- only when you’re physically sitting in front of the computer. Local accounts without passwords aren’t appropriate for laptops; they’re like bright neon signs inviting an attacker to come help himself or herself to all your information!
A password is required if you want to take advantage of the other two features I describe here. If you don’t have passwords on your local accounts, there’s really nothing else you can do to help protect your data from theft. Make sure that your password works all the time -- some laptop computers don’t engage the desktop lock when you put the computer into standby or hibernation modes. Power control settings vary among hardware manufacturers, so there’s no Group Policy object for this. You’ll need to manually check the configurations of your laptops to ensure that a password is required when resuming.
Access control lists and permissions can help you protect files that are accessed over the network, but they can’t stop someone who has physical access to your computer. A technology called Encrypting File System (EFS) is built into Windows 2000, Windows XP, and Windows Server 2003. EFS is transparent to the normal operation of a computer: you don’t have to enter passwords to open files or subdirectories. Rather, when you log on to your computer, your EFS encryption keys are unlocked when your computer starts and opens your personal master key (see the section below on SysKey for the details of key protection). As you access a file, EFS silently decrypts the file using the private key associated with your EFS certificate and then loads the decrypted file into memory. The file remains encrypted on the hard drive.
To encrypt files simply right-click the file or folder in Explorer, choose Properties, in the Attributes section click Advanced, and then select the Encrypt contents to secure data check box. Stand-alone (non-domain-joined) computers will generate at least three things: an EFS digital certificate, an associated EFS public/private key pair (with the public key stored in the certificate), and a file encryption key (FEK). If you’re encrypting a folder, every file in the folder will have its own unique FEK. EFS encrypts each file with the file’s FEK and then encrypts the FEK with your public EFS key. Future encryption operations will generate only FEKs since you already have an EFS key pair and certificate. I recommend encrypting the entire “My Documents” folder so that anything kept in the folder is automatically encrypted.
Decryption runs in reverse: when you open an encrypted file, EFS first obtains the private key associated with your EFS certificate, uses that to decrypt the file’s FEK, and then uses the FEK to decrypt the file. This all happens with no dialog boxes or user prompting and has no application compatibility issues because the decryption occurs before the application reads the data in the file.
On domain-joined computers the behavior is a bit different. If you’ve implemented a public key infrastructure (PKI), EFS will request a certificate from an enterprise certificate authority (CA). Your computer generates the EFS key pair and associates the public key with the certificate. From there, the process is very similar, except that when you first encrypt a file the computer doesn’t need to generate the EFS certificate or keys since you already have them. If you haven’t implemented a PKI, or if the request to the CA failed, the behavior for domain-joined computers is exactly the same as for stand-alone computers.
The actual file encryption algorithms are different depending on the operating system. All versions of Windows 2000 support only expanded Data Encryption Standard (DESX). Windows XP original release can use either DESX (still the default) or Triple-DES (3DES). Windows XP Service Pack 1 (and later) and Windows Server 2003 support Advanced Encryption Standard (AES) plus DESX and 3DES. AES is the default.
Recovering Encrypted Files
As you might imagine, using EFS presents some operational issues. You can lose access to encrypted files if you lose your EFS key or if you reset your password (password changes work fine, but password resets invalidate EFS keys). A recovery policy designates one or more user accounts to be recovery agents that can help in this situation. Recovery agents can access encrypted files. Windows 2000 mandates a recovery agent either locally or on the domain before you can encrypt files; Windows XP and Windows Server 2003 don’t have this requirement.
On stand-alone Windows 2000 computers, the local administrator becomes the default recovery agent when someone first logs on to the Administrator account. Stand-alone Windows XP doesn’t create a default recovery agent (which eliminates a reason to try to conduct offline attacks against the Administrator account). On domain-joined computers running Windows 2000 or Windows XP with a domain EFS policy, the domain administrator is the default recovery agent.
When you encrypt files, each file’s FEK is also protected by the public key of every recovery agent in the recovery policy. So if you lose your key or reset your password a recovery agent can still access your files. This is also useful when employees leave your organization; a recovery agent can access all that person’s encrypted files and even remove the encryption if necessary. Note that the recovery agent has no access to your EFS keys, so the agent can’t impersonate you. The agent can only decrypt files.
If you decide that EFS is valuable for your organization, I encourage you to investigate deploying a Windows PKI using auto-enrollment. Auto-enrollment takes away most of the usual human interaction required in managing a PKI. And for EFS you can create certificate templates that combine enrollment with key and data recovery methods -- for example, simultaneously enrolling the user and archiving his or her private key. Key archival is a valuable supplement to EFS recovery agents.
Circumventing or cracking EFS is monumentally difficult because each file is encrypted with its own key, which is in turn encrypted with the owner’s EFS key, which is in turn protected by that user’s master key, which is in turn protected by the system startup key. Installing a parallel copy of Windows or any other operating system and cracking the Security Accounts Manager (SAM) database won’t get you the keys you need to decrypt files because the keys aren’t stored in the SAM.
If you’re using local recovery agents, it’s important to export the recovery agent’s private key to separate storage and then remove the key from the computer. A good choice would be a USB drive that is kept separate from the computer. Be sure to protect the exported key with a password (the export process prompts you for one). If a user loses the EFS private key, the recovery agent’s key on the USB drive can recover the user’s files.
There is the chance that EFS will leave plaintext “shreds” of a file on the hard drive. If you encrypt an individual file, EFS first creates a plaintext backup of the file, encrypts the file, and then deletes the backup. Of course, deleting the backup doesn’t actually erase the bits from the surface of the disk, meaning that the plaintext contents are still there and could be recovered with disk editing tools. The proper behavior is to encrypt folders rather than files. All files in the folder will remain encrypted all the time; no plaintext shreds are created. This is also important for applications that create temporary files.
Of course an attacker with physical access could simply replace encrypted files, which would be an interesting form of a denial-of-service attack, but why would someone steal your computer, overwrite your files, and then return your computer? Yes, it can be entertaining to substitute a prank default.html on some unsuspecting Web server, but why would someone replace your marketing plans with pornography and then give you your laptop back? While EFS provides very strong and reliable confidentiality, it isn’t designed to provide integrity. Indeed, encryption of any kind never provides integrity. Integrity comes from digital signature technology that typically computes a one-way hash of the content.
Enabling the System Startup Key
Each time a new user is added to a computer, the Windows Data Protection API (DPAPI) generates a master key that’s used to protect all other private keys used by applications and services running in that user’s context, such as EFS keys, S/MIME keys, and so on. The computer also has its own master key that protects system keys like IPsec keys, computer keys, and SSL keys. All these master keys are then protected by a computer’s startup key. When you start a computer, the startup key decrypts the master keys. The startup key also protects the local SAM database on each computer, the computer’s local security authority (LSA) secrets, account information stored in Active Directory on domain controllers, and the administrator account password used for system recovery in safe mode.
The SysKey utility lets you choose where that startup key is stored. By default, the computer generates a random key and scatters it throughout the registry; a complex obfuscation algorithm ensures that the scatter pattern is different on every Windows installation. You can change this to one of two other choices: you can continue to use a computer-generated key but store it on a floppy disk, or you can have the system prompt during startup for a password that’s used to derive the master key. You can always change between the three modes, but if you’ve enabled either the key-on-floppy or password modes and you’ve lost your floppy or forgotten your password, your only recovery option is to use a repair disk to restore the registry to the state it was in before you enabled the SysKey mode. You’ll lose any other changes made between then and now. To change your startup key, simply open a command prompt, choose Start | Run, or press [Windows]+R, then enter "syskey" to run the SysKey utility.
Changing SysKey to password mode can help protect stolen laptops from information theft. It provides yet another barrier between a determined thief and your data on the hard drive. SysKey passwords can range from 1 to 128 characters; I recommend using at least 12. The combination of EFS (to protect data) and SysKey passwords (additional protection for the EFS keys) can make it computationally infeasible for an attacker to access your data.
Make Yourself Uninteresting
You can address theft with a judicious combination of policy, process, and technology. Help your people become aware of the problem of theft, and use the technologies you already have to mitigate the risks if a computer does get stolen. To learn more about deploying EFS in your organization, visit these links:
Encrypting File System in Windows XP and Windows Server 2003
Public Key Infrastructure for Windows Server 2003