Windows 7 – How to use Cipher.exe – A Critical Win 7 security Tool

The Cipher.exe command line tool was originally released with Windows 2000, commensurate with the release of NTFS V5.0 and the ability to use the Encrypting File System (EFS). Microsoft continues to upgrade the tool as Windows Operating System security solutions evolve. With the release of Windows 7, the Cipher command becomes a critical component of desktop support.

Most technical support sites and blogs reference use of the Cipher tool to “wipe data from your disk”. While the description is not entirely accurate, the cipher tool can be used to modify the binary content for a designated structure of the hard drive, effectively making it indecipherable. The syntax for this effort is:

Syntax for Cipher.exe Windows 7

 

 

 

Cipher /w:c:\users\user1 would scramble the bits for everything within the \users\user1 directory making it unusable. The solution was designed to scramble the bits within a deleted folder, preventing its recovery, though it could be used to disable an entire directory structure or drive if not used with caution.

Cipher can also be used to encrypt files or folders using the /E option (combined with the /S option for recursive encryption of folders and subfolders). Decryption requires the /D switch. Both switches implement the EFS functionality of NTFS.

Cipher switches added from Windows XP through Windows 7, become essential to the management of security features associated with current OS deployment and operation.

Microsoft Technet provides a table containing the basic Cipher switches. Jack Cobben, Jack’s Server Blog created a straight forward overview while preparing for the Windows 7 MCTS 70-680 exam.

Creation of a recovery agent, for instance, is essential to the management of encrypting file system (EFS), Bitlocker, and other digitally certified features. The /R: switch is mentioned as a means to generate a new recovery agent certificate and private key for your system. If this switch is used, all other switches are ignored, suggesting its relevance. Unfortunately the reason and ramifications are not explained well.

Pay close attention to the following paragraphs. I really wanted to bold and italic that last sentence. Really. Pay attention.

Prior to the development of the Credential Manager, a key Windows Vista and Windows 7 element, the File Encryption Key (FEK) associated with an EFS file was stored in the Security Account Manager. Hacker tools were available to recover a FEK from the SAM. If an administrator took ownership of an encrypted file, with a little effort, they could retrieve the FEK from the SAM and recover the encrypted file. When EFS is used to encrypt a file in Windows 7, the FEK is stored within the encrypting user’s Digital Certificate. If a Digital Certificate does not exist for the user, a public-private key pair and certificate are generated for the user, the FEK is added, and the certificate is stored in the local Windows 7 Credential Manager. The entire process is transparent to the user. To protect the integrity of the PKI model, only the owner of the certificate can export the FEK, or their public key, or their private key, or permissions to access the file. Not even a local or domain administrative account can take ownership, export the FEK, or export a user’s credential.

In order to protect enterprise assets, Microsoft created the concept of a recovery agent. The recovery agent is a pre-defined, public-private key pair and certificate designated to hold any FEK’s created on the system. This effectively grants the administrative owner of the recovery agent the ability to recover an encrypted file. If you don’t create a recovery agent before encrypting any files there is no administrative storage location for the FEK and only the encrypting user has the FEK. Similarly, if the file owner/encrypting user grants file permission to someone who does not have a locally stored digital certificate, NTFS security permissions will be granted BUT there will be no storage location to replicate the FEK and the user granted (or an administrator taking ownership) permissions will be unable to access the encrypted file. For the sake of safety and recovery, you really must have a recovery agent installed on each system. Alternately, Active Directory Certificate integration may be enabled in a domain environment, and group policy can be used to present a recovery agent credential to computers within the domain. But recovery agents only resolve a portion of the encrypted file management and recovery scenario.

To fully maintain the integrity of the PKI model, only the user of a specific credential can export or make a copy of their credential information. Backup solutions will copy encrypted files, but will not copy the Credential Manager content. Migration tools like Windows Easy Transfer (WET) and the User State Migration Tool (USMT) can be configured to capture encrypted files from a source system, and to restore them to a target system. The only method to transfer a user’s credential is for the user to export their own public-private key pair to a folder that will be backed-up or transferred prior to the capture or transfer process. Failing to export the credential, relocate it to the new system, and import it into the new local credential manager can be catastrophic. The outcome – encrypted files are relocated but cannot be decrypted because the FEK (contained within the secured certificate) was not transferred. Recovering a system image that lacks the exported digital certificates will mean that any encrypted data is inaccessible even to the user who originally encrypted the file.

Microsoft provides a great Technet article that incorporates the steps using USMT components to migrate encrypted files. The article provides details for using the MMC Certificate snap-in and export wizard – a sequence which few standard users will be able to follow – for a user to export their own certificate prior to use of WET or USMT. Viable for the technically savvy user, though of little value in a Lite-touch or Zero-touch migration scenario. It would be better to show users how to enter the Credential Manager from the Control Panel and merely select the Back Up Vault link.

For automated sequences, Cipher may come to the rescue. The /X: switch is referenced in the Technet article above, although with minimal definition and no example. A search of the Microsoft Command Line reference for Cipher drops all the way back to Windows XP and does not mention the /X: switch at all.

Using an elevated command prompt and typing Cipher /? Yields the following for the /X: switch.

X Backup EFS certificate and keys into file filename. If efsfile is provided, the current user's certificate(s) used to encrypt the file will be backed up. Otherwise, the user's current EFS certificate and keys will be backed up.

The syntax is either

Export Backup Syntax for Cipher.exe Windows-7
In the first instance you export the entire user credential file, in the latter you export only a credential and the FEK for the file specified. This is useful to export the FEK and credentials for EFS encrypted files, without exporting the entire credential vault that includes server and trust authority credentials. If you do not want user interaction, you will also need to prepare a script that, in order,

  • Confirms the request
  • Identifies a password to protect your exported .pfx file (containing both public and private keys as well as the FEK).
  • Confirm the password via a second, identical entry.

The process creates a file called exportfilename.PFX in the root of the designated user’s profile that can then be exported or copied.

Submitting a command sequence for user execution or forcing a login script will assure that the user has exported their credentials prior to the execution of any backup or migration sequence. The drawback will be the potential exposure of the password protecting the credential file if the command script is captured.

You may also choose to explore the /REKEY and /R switches. These will allow you to reset the key or create a recovery agent for files rather than focusing on the export of individual certificates.

If you are familiar with Powershell, head straight to Posh Tips for examples incorporating Export-PSCredential and Import-PSCredential functions. These provide a more sophisticated and comprehensive credential vault export and import feature.

For more detailed information regarding certificate based EFS, recovery keys, enabling and disabling EFS, exporting and importing keys, and best practices refer to the Microsoft Small Business Security Guidance article. Although the screen shots and context pre-date Windows 7, the material remains relevant toward understanding encryption migration and recovery.

Enjoy,

Steven Fullmer
Interface Technical Training Staff Instructor

Posted in Security, Windows 7 | Posted in , , , , , , , , , | Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">