Password Recovery Software

Introduction

DPAPI architecture and security

• What is DPAPI
• What does DPAPI protect
• DPAPI architecture
• DPAPI security
• DPAPI configuration

Data encryption in DPAPI

• Description of CryptProtectData and CryptUnprotectData functions
• Examples of use for CryptProtectData/ CryptUnprotectData functions
• Data encryption in DPAPI

DPAPI Master Keys

• What is DPAPI Master Key
• Master Key structure
• Generating new Master Key
• Regenerating Master Keys
• Backing up Master Keys and restoring them from backups

Next to the Part 2 of the article >>

Abstract

In this paper, we are making an attempt to analyze the operation of DPAPI, review the undocumented structures and encryption algorithms of DPAPI, understand and describe the internal functioning of the system.

The paper presents the world's first complete (not claiming to be universal though) description of DPAPI operation logic and all the undocumented structures, including DPAPI blobs, Master Keys and credential history files.

We also attempt to point out some functional drawbacks of the latest version of DPAPI and possible ways to eliminating those. Additionally, a deeper analysis of the implementation of the first version of DPAPI, released along with Windows 2000, has revealed the presence of a number of serious vulnerabilities and put the entire security of the system into question.

Much attention is paid to the recovery of DPAPI data when user profile cannot be loaded. For the first time ever, we practically tested the user logon password recovery algorithm without using SAM or NTDS.DIT files.

The operation of DPAPI was analyzed using a set of 6 utilities, integrated into one of the most powerful applications for auditing Windows passwords, Windows Password Recovery. We hope these tools, as well as certain information from our article, is found interesting not only to experts and criminologists but to all researchers in the field of computer security.

What is DPAPI

Beginning with Windows 2000, Microsoft ships their operating systems with a special data protection interface, known as Data Protection Application Programming Interface (DPAPI). DPAPI is currently widespread and used in many Windows applications and subsystems. For example, in the file encryption system, for storing wireless connection passwords, in Windows Credential Manager, Internet Explorer, Outlook, Skype, Windows CardSpace, Windows Vault, Google Chrome, etc. DPAPI has become popular among programmers first of all due to its simplicity of use, as it consists of just a couple of functions for encrypting and decrypting data, CryptProtectData and CryptUnprotectData.

Despite its apparent simplicity, the technical implementation of DPAPI is rather complicated, and these functions' operation logic is much like the cheerful childish rhyme "The House that Jack Built". Perhaps, that's the reason why the internal structures and operating principles of DPAPI had been kept behind a closed curtain for so long.

For the first time, DPAPI was analyzed by Passcape Software in 2003. In 2005, the company released the first commercial application (Outlook Password Recovery) based on that recovery, which could decrypt DPAPI blobs offline, i.e. without logging on to owner's account. The decryption algorithm proposed by Passcape merely simulated DPAPI operation, so the DPAPI system has not been compromised.

With the release of the brand-new version of Windows Password Recovery tool, the offline DPAPI decryption algorithm has gotten a new round. Now, besides decrypting DPAPI blobs, the program could also analyze them, find them on disk, decrypt Master Keys and validate their passwords, extract users' credential history hashes from DPAPI, and much more.

What does DPAPI protect?

DPAPI is utilized to protect the following personal data:

• Passwords and form auto-completion data in Internet Explorer, Google *Chrome
• E-mail account passwords in Outlook, Windows Mail, Windows Mail, etc.
• Internal FTP manager account passwords
• Shared folders and resources access passwords
• Wireless network account keys and passwords
• Encryption key in Windows CardSpace and Windows Vault
• Remote desktop connection passwords, .NET Passport
• Private keys for Encrypting File System (EFS), encrypting mail S-MIME, other user's certificates, SSL/TLS in Internet Information Services
• EAP/TLS and 802.1x (VPN and WiFi authentication)
• Network passwords in Credential Manager
• Personal data in any application programmatically protected with the API function CryptProtectData. For example, in Skype, Windows Rights Management Services, Windows Media, MSN messenger, Google Talk etc.

DPAPI architecture

Beginning with Windows 2000, as it was mentioned earlier, any application can protect its personal data (e.g., passwords) by simply calling the CryptProtectData function, which returns a "non-transparent" binary structure, also known as DPAPI blob. "Non-transparent", by Microsoft's definition, means that besides the original encrypted data of the application it also contains other supplemential stuff, necessary for decrypting that data. Despite that the structure of DPAPI blobs is not documented, with the release of the new version of Windows Password Recovery, for the first time ever it has become possible to decrypt DPAPI blobs offline and thoroughly analyze them.

Other API function, CryptUnprotectData, which, as its name suggests, works similarly, but the other way around, gets an encrypted DPAPI blob at the input and returns decoded data to the application.

Figure No 1. shows the DPAPI flow chart.
[画像:DPAPI flow chart]
Figure 1. DPAPI flow chart.

DPAPI encryption is based upon user password; therefore, data encrypted under one account cannot be decrypted under other account. Moreover, DPAPI allows restricting access to data even within one account by setting an additional secret (entropy). Thus, unless it knows the additional secret, one application cannot access data protected in other application.

Every programmer implementing DPAPI interface must realize that the system only encrypts data. An application must provide a solution for storing the returned DPAPI blobs, including reliable hiding of optional entropy data if it is used.

DPAPI security

DPAPI was created with the view of many aspects in terms of security. Here is a list of key features that distinguish it from similar systems:

• PAPI works on top of CryptoAPI. You can create your own encryption service provider and use it with DPAPI.
• DPAPI uses proven cryptographic algorithms. For example, Windows 7 by default uses the AES256 encryption in the CBC mode, SHA512 for hashing and PBKDF2 as password-based key derivation routine.
• All the algorithms, as well as their key length, can be configured from the registry, which can be accessed only by users with the Administrator privileges. For example, the number of iterations in the PBKDF2 function is set in the following registry key:

Registry key: HKLM/Software/Microsoft/Cryptography/Protect/Providers/%GUID%
Value: MasterKeyIterationCount

• All the parameters that can be configured from the registry have their restrictions and cannot be lesser than the default values. For example, in Windows XP the MasterKeyIterationCount default value is 4000.
• All critical data is protected by integrity check.
• Size of all encryption keys in all algorithms is sufficient to prevent possible brute force attack.
• For the same purpose, PBKDF2 has a rather great iteration counter. The only exception is the first implementation of DPAPI. The table below shows that the Master Key password search speed is sufficient for compromising user password in Windows 2000.
• For security reasons, the validity of the Master Key is limited. However, the implementation of that mechanism has weak points, which will be discussed below.
• All communications with the domain controller are carried out via a secure RPC channel.
• Cached data is written neither to disk, nor to swappable RAM. Intermediate keys and values are reset in the stack after running each encryption function. By the way, when analyzing the SYSKEY utility, Passcape specialists have found an interesting bug related to incorrect stack reset, which resulted in having a part of the system encryption key (SYSKEY) in some systems running under Windows 2000, Windows XP and Windows 2003 stored as plain text, available to all users of the system. Alas, it happens sometimes.

However, there are some nuances, the ignorance of which can weaken the DPAPI security system:

• CRYPTPROTECT_LOCAL_MACHINE - flag set in the CryptProtectData function, quite convenient in certain cases, in fact can compromise user data, not providing adequate protection. When it is set, the encryption does not depend on user's logon password. On the other hand, such behavior does not contradict the DPAPI concept and is related to peculiarities of interface implementation.
• DPAPI can be configured to run in the compatibility mode for Windows 2000, when the backup Master Key is stored locally and can be decrypted using the LSA secret. Thus, in theory, all the DPAPI blobs can be decrypted without knowing user password. That is what Windows Password Recovery demonstrates in practice. See screenshot No 2. Nevertheless, to activate that mode, one needs Administrator access to the registry key with DPAPI configuration.

[画像:Decryptinng DPAPI blob without knowing logon password in Windows 2000]
Figure 2. Decryptinng DPAPI blob without knowing the original user logon password in Windows 2000.

If taken as a whole, DPAPI provides perhaps the strongest to date protection and safety of user data.

OS	Encryption algorithm	Hash algorithm	Number of iterations in PKCS#5 PBKDF2	Password guess speed (pwd/sec)
Windows2000	RC4	SHA1	1	95000
WindowsXP	3DES	SHA1	4000	76
WindowsVista	3DES	SHA1	24000	12
Windows7	AES256	SHA512	5600	10

Table 1. Default algorithms used in DPAPI.

DPAPI configuration

DPAPI runs on top of Crypto API and can use any encryption service provider. The crypto provider is selected as defined in the following registry key:

Registry key: HKLM/Software/Microsoft/Cryptography/Protect/Providers
Value: Preferred

By default, the system uses Microsoft's crypto provider named df9d8cd0-1501-11d1-8c7a-00c04fc297eb, implemented in the psbase.dll library.
The encryption is configured by modifying the respective value in the following registry key:
HKLM/Software/Microsoft/Cryptography/Protect/Providers/%GUID%

Where %GUID% is the service provider's unique identifier. By default, the DPAPI settings key corresponds with
HKLM/Software/Microsoft/Cryptography/Protect/Providers/df9d8cd0-1501-11d1-8c7a-00c04fc297eb

This hive of the registry can be modified by users with Administrator rights only. Here are the descriptions of some keys of this hive.

Value: MasterKeyIterationCount
Data type: REG_DWORD
Description: Iteration counter for function PBKDF2, cannot be smaller than the
 default value. The key generation algorithm is used in the encryption
 of user's Master Key and credential history.

Value:  MasterKeyLegacyCompliance
Data type:  REG_DWORD
Description: Set the registry key to 1 to make DPAPI behavior similar to that of
 Windows 2000 when backing up/restoring Master Keys.

Value: MasterKeyLegacyNt4Domain
Data type: REG_DWORD
Description: Since DPAPI backup/restore support doesn't exist on NT4, DPAPI provides
 a workaround to avoid losing its data and force the client machine to
 use W2K style master key backup/restore. For that, you should set the
 MasterKeyLegacyNt4Domain parameter to 1.

Value: DistributeBackupKey
Data type: REG_DWORD
Description: Determines compatibility settings when backing up or restoring domain
 key. For example, if the domain functional level is set to Windows
 2000 native.

Value: Recovery Version
Data type:  REG_DWORD
Description: Determines version compatibility when backing up and restoring local
 copies of Master Keys. The default version is 2; Windows 7 and Windows
 Server 2008 R2 can be configured to use version 3 by setting the DWORD
 registry value to 3.

Value: ProtectionPolicy
Data type: REG_DWORD
Description: Default data protection policy flag. Corresponds with the dwPolicy flag
 in Master Key header.

Value: Encr Alg, Encr Alg Key Size
Data type: REG_DWORD
Description: Pair of values that control the type of the encryption algorithm used
 in DPAPI and the size of the key used in that algorithm.

Value: MAC Alg, MAC Alg Key Size
Data type: REG_DWORD
Description: Keys for setting the DPAPI data integrity control algorithm.

Description of CryptProtectData and CryptUnprotectData functions

These functions' parameters are pretty much identical, so we are going to take a look only at CryptProtectData, which in C++ is declared as follows:

BOOL WINAPI CryptProtectData(
 __in DATA_BLOB *pDataIn,
 __in LPCWSTR szDataDescr,
 __in DATA_BLOB *pOptionalEntropy,
 __in PVOID pvReserved,
 __in_opt CRYPTPROTECT_PROMPTSTRUCT *pPromptStruct,
 __in DWORD dwFlags,
 __out DATA_BLOB *pDataOut
);

Description of function fields:

Examples of use for CryptProtectData/ CryptUnprotectData functions

For the convenience of running tests, as well as for the purposes of providing an example, we have created two simple utilities of the respective names, which implement mere wraps around DPAPI functions. Thus, DPAPI functions can be called from the command line. Here is the С++ source for CryptProtectData. The compiled ЕХЕ files of these programs are also available for download at: CryptProtectData, CryptUnprotectData.

CryptProtectData source code

// CryptProtectData.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#pragma comment (lib, "Crypt32")
int _tmain(int argc, _TCHAR* argv[])
{
 	if ( argc<3 || argc>5 )
 	{
 		_tprintf(TEXT("Syntax: %s secret output_filename"\
 " [entropy_string] [flags]n"),argv[0]);
		return 1;
 	}
 
 	//Declare variables
 	DATA_BLOB DataIn;
 	DATA_BLOB DataOut;
 	DATA_BLOB DataEntropy;
 	DWORD dwFlags;
 	LPTSTR pFoo;
 
 	//Initialize the structure
 	DataOut.pbData=NULL;
 	DataOut.cbData=0;
 	//
 	DataIn.pbData=(LPBYTE)(argv[1]);
 	DataIn.cbData=(lstrlen(argv[1])+1) * sizeof(TCHAR) ;
 	//
 	if ( argc>=4 )
 	{
 		DataEntropy.pbData=(LPBYTE)(argv[3]);
 		DataEntropy.cbData=(lstrlen(argv[3])+1) * sizeof(TCHAR) ;
 	}
 	//
 	if ( argc==5 )
 		dwFlags=_tcstoul(argv[4],&pFoo,10);
 	else
 		dwFlags=0;
 
 	//Protect the secret
 	if ( !CryptProtectData(
 		&DataIn,
 		TEXT("CryptProtectData by Passcape Software"),
 		argc>=4?&DataEntropy:NULL,
 		NULL,
 		NULL,
 		dwFlags,
 		&DataOut) )
 	{
 		dwFlags=GetLastError();
 		_tprintf(TEXT("CryptProtectData failed with the following"\
 "error code: %lu\n"),dwFlags);
 		exit(1); 
 	}
 
 	//save the output blob
 	FILE *f=NULL;
 	_tfopen_s(&f,argv[2],TEXT("wb"));
 	if ( !f )
 	{
 		if ( DataOut.pbData )
 		{
 			LocalFree(DataOut.pbData);
 			DataOut.pbData=NULL;
 		}
 		_tprintf(TEXT("Can't open output file for writing\n"));
 		exit(2); 
 	}
 
 	//write
 	if ( DataOut.pbData )
 	{
 		size_t written=fwrite(DataOut.pbData,DataOut.cbData,1,f);
 		LocalFree(DataOut.pbData);
 		DataOut.pbData=NULL;
 		if ( written!=1 )
 		{
 			_tprintf(TEXT("Can't write %lu bytes to output file\n")\
 ,DataOut.cbData);
 			exit(3);
 		}
 	}
 
 	fclose(f);
 	return 0;
}

Data encryption in DPAPI

The encryption of user's personal data in DPAPI goes in three phases:

1. First, the application calls the CryptProtectData function, specifying the source data to be encrypted and the optional entropy parameter. If the latter is not specified, any other program in the context of current user may be able to decrypt the data by gaining physical access to the DPAPI blob.
2. The CryptProtectData function belongs to the CryptoAPI family and is located in Crypt32.dll. From there, the request for further processing is forwarded via a secure RPC channel to the Local Security Authority (LSA) system process, and the context of current user is switched to the system. All the further manipulations are run in the context of the local system.
3. In the LSA, the data is actually encrypted and forwarded back to Crypt32.dll via the RPC channel; from there, the data safely travels to the original application.

CryptProtectData and CryptUnprotectData are basically just wrapper functions, since the actual data encryption runs in the context of the system. The magic part of DPAPI takes place in the LSA, and is hidden from the stranger's eye.

The encryption process is lengthy and boring; it may remind of "fulfilling the marital duty after 20 years of living together". In the beginning, we take user's password; then, by applying the PBKDB2 cryptographic standard to it, we get the Master Key encryption key. Now, we use that encryption key to decrypt the Master Key. If the decryption fails, the user password is decrypted using the first hash of the credential history, CREDHIST, which in its turn also gets the Master Key encryption key and attempts to decrypt the Master Key again. If that attempt too ends up in failure, we decrypt the next credential history hash, and so on. The operation continues until either the Master Key is decrypted or the credential history runs out of its items.

To avoid password prompts every time CryptProtectData / CryptUnprotectData is called, Windows caches the password and stores it in the depths of the LSA for the duration of the user profile life. That is why DPAPI works exclusively online, only after the user has logged on to the system.

In 2005, for the first time ever, Passcape Software introduced an algorithm that works in all of the company's products and simulates the offline operation of DPAPI. In other words, to decrypt DPAPI blobs, one no longer needs to load user's context; although having the password is mandatory. In no way does the offline decryption of DPAPI makes the system more vulnerable; at the same time, it remains helpful to researchers, experts and criminalists.

So, user's Master Key resides in a special container file, which can store additional copies - backups - of the Master Key. A Master Key backup is used when the primary copy, for one or the other reason, cannot be decrypted. For example, after a forced password reset. Master Key is a critical element in DPAPI cryptography; therefore, its length is 512 bits, and only proven algorithms are used when encrypting it. See the table 1.

The decryption of Master Key in the first implementation of DPAPI required the NTLM hash of user's password. That was a major: No, that was the greatest blunder of DPAPI developers, which negated the security of the system. All because it technically allowed a potential malefactor to decrypt the Master Key and, consequently, any DPAPI blob by getting the NTLM hash directly from the SAM file; the actual password was not even necessary! In the second, current version of DPAPI, that error was fixed; now Master Key is encrypted using the SHA1 hash.

Once the Master Key is successfully decoded, its source 512-bit data participates in obtaining the symmetric encryption key for the DPAPI blob. For that purpose, the Master Key is "mixed" with random data (which would be then stored in the DPAPI blob) and entropy, if it is specified. Thus we achieve a three-dimensional uniqueness, so to say, of the encryption key for each DPAPI blob.

And, finally, there goes the actual encryption of the source data. In Windows 7, data is encrypted using the AES256 algorithm. All the phases of that intricate process involve using "salt", i.e. set of random data, unifying encryption keys and thus preventing the potential brute force attack with rainbow tables.

By the way, few people know that the first versions of Windows 7 had serious problems with AES encryption. Simply put, this type of encryption did not function at all. Fortunately, the problem was quickly eliminated.

Once the data is encrypted, it is grouped into a single structure along with other system information and sent back to the application as a DPAPI blob. The structure of a DPAPI blob is not documented; however, Passcape researches were able to fully reverse it. Here it is.


Undocumented structure of DPAPI blob
Figure 3. Undocumented structure of DPAPI blob.

What is DPAPI Master Key

A user's Master Key is a binary file that contains encrypted data used for creating the primary encryption key in all DPAPI blobs. Since Master Key encrypts user's confidential data, the key itself requires serious protection. User's password was meaningfully chosen as source data for protecting the Master Key.

Master Key structure
Figure 4. Master Key structure.

Master Key structure

As shown on Figure 4, a Master Key file consists of 5 units:

1. Header and system information
2. User's Master Key
3. Local backup encryption key
4. Unique CREDHIST file identifier
5. Domain Master Key backup

In Windows 2000, instead of the CREDHIST identifier, the system could store the local Master Key backup. That is what made the DPAPI system extremely vulnerable. Windows Password Recovery, for example, can decrypt a Master Key from its local backup and wouldn't even need the user's password to do that.

The header of the Master Key file contains the following information (C++ syntax followed by description of each field):

typedef struct _tagMasterKey
{
	DWORD dwVersion;
	DWORD dwReserved1;
	DWORD dwReserved2;
	WCHAR szGuid[0x24];
	DWORD dwUnused1;
	DWORD dwUnused2;
	DWORD dwPolicy;
	DWORD dwUserKeySize;
	DWORD dwLocalEncKeySize;
	DWORD dwLocalKeySize;
	DWORD dwDomainKeySize;
} MASTERKEY, *PMASTERKEY;

The header is followed by a sequence of 4 Master Key slots. Each slot contains its own header and the actual key.
The header structure is common for all slots. Here is what it looks like for version 1 (Windows 2000):

typedef struct _tagMasterKey1Base
{
	DWORD dwVersion;
	BYTE pSalt[0x10];
	BYTE pKey[];
} MASTERKEY1BASE, *PMASTERKEY1BASE;

In other versions of OS, the structure is complemented with new fields:

typedef struct _tagMasterKey2Base
{
	DWORD dwVersion;
	BYTE pSalt[0x10];
	DWORD dwPBKDF2IterationCount;
	ALG_ID HMACAlgId;
	ALG_ID CryptAlgId;
	BYTE pKey[];
} MASTERKEY2BASE, *PMASTERKEY2BASE;

typedef struct _tagMasterKey3Base
{
	DWORD dwVersion;
	GUID guidCredhist;
} MASTERKEY3BASE, *PMASTERKEY3BASE;

Description of header slot fields:


The table 2 shows the default Master Key encryption algorithms for various operating systems, as well as the analysis of their protection from a potential brute force attack.

OS	CryptAlgId	HMACAlgId	dwPBKDF2IterationCount	Password guess speed (pwd/sec)
Windows2000	RC4	SHA1	1	95000
WindowsXP	3DES	SHA1	4000	76
WindowsVista	3DES	SHA1	24000	12
Windows7	AES256	SHA512	5600	10

Table 2. Master Key encryption algorithms.

Generating new Master Key

Let's take a closer look at the process of creating and encrypting user's new Master Key:

• First, we call the API function RtlGenRandom, which returns 64 pseudo-randomly generated bytes. That's the raw material for the Master Key to be used for encrypting DPAPI blobs.
• Now we need to protect the raw material for the Master Key. For that purpose, we encrypt it using the user's logon password, security identifier (SID) and additional 16 bytes of random data (so-called "salt"). The Master Key encryption process consists of two major steps. First, we use the Password-Based Key Derivation function (crypto standard described in PKCS #5) and get the key out of the password, SID and salt. Then we use that key to obtain a symmetric Master Key encryption key. Different versions of Windows protect Master Key different ways. Thus, in Windows 2000 the default encryption algorithm is RC4, in Windows XP and Win2K3 it's 3DES, and Windows Vista and higher use AES256.
• Master Key obtains a unique name, GUID. Each DPAPI blob stores that unique identifier, which it is bound to via a warm friendly relationship. In other words, Master Key GUID is the key's "link" to the DPAPI blob.
• Master Key, created and encrypted with user's password, is stored in a separate file in the Master Key storage folder along with other system data. MKSF is a special location on disk where Master Keys are stored. User's Master Keys are stored in %APPDATA%/Microsoft/Protect/%SID%, where %APPDATA% is the Application Data directory. For example, C:/Users/John/AppData/Roaming/Microsoft/Protect/S-1-5-21-2893984454-3019278361-1452863341-1003, and %SID% is user's security identifier. In the above example that's S-1-5-21-2893984454-3019278361-1452863341-1003. System's Master Keys are stored in %WINDIR%/System32/Microsoft/Protect and used for decrypting DPAPI blobs, protected under a local system account. All the DPAPI blobs created with the CRYPTPROTECT_LOCAL_MACHINE flag set in the CryptProtectData function are protected with the system's Master Keys.
• Master Key creation, encryption or decryption can be extremely time-consuming, by the standards of the operating system. For example, in Windows 7, it takes over 0.1 of a second to decrypt a Master Key on a modern PC. But DPAPI has internal caching, so once decrypted, a Master Key is placed in the cache, and accessing it again does not involve a new decryption route.

Regenerating Master Keys

If you open Master Key Storage Folder on your disk, having previously allowed the system to show hidden folders and files (Master Key files have the Hidden attribute), you will likely see several Master Key files. Why several? - Because DPAPI, for safety reasons, forces the creation of a new Master Key approximately every 90 days, so any user account normally has several Master Keys; the number depends on the user profile creation date.

The Master Key regeneration period is hard-coded in the system. It is assumed that it cannot be modified. However, there is a "BUT" to it: The Master Key folder contains an 18-byte file named Preferred, which contains the name of the last Master Key created by the system, as well as the creation date.

Preferred file structure

typedef struct _tagPreferredMasterKey
{
	GUID guidMasterKey;
	FILETIME ftCreated;
} PREFERREDMASTERKEY, *PPREFERREDMASTERKEY;

Every time some DPAPI function is called, the system checks the last Master Key creation date in Preferred and, if finds it older than 90 days, creates a new Master Key, updating Preferred along the way. The Master Key regeneration process can be managed manually. To do that, call the CryptProtectData function with the CRYPTPROTECT_CRED_SYNC flag set. The system will re-encrypt all the Master Keys and update them on the disk. That operation is normally performed after changing user's password. To prevent the optional Master Key updates, Windows 7 introduced a Master Key synchronization mechanism, which we are going to cover below.

The data in the Preferred file is not protected by any means, so by modifying the last Master Key creation date by hand, one can manually manage the regeneration process; for example, infinitely extend the life of the last Master Key or create any number of Master Keys. But while the extension of life for a Master Key does not give malefactor any privileges, in the last case, a great number of Master Keys followed by password change can put the system in a lengthy screeching halt, as all Master Keys undergo a mandatory re-encryption every time user's password is changed.

Now, figure out how much time it would take to process, for example, 1000 Master Keys in Windows 7 if processing a single Master Key takes over 0.3 of a second. Thus, in our opinion, the Master Key regeneration process requires a bit of additional work. Ideally, adding data integrity control-the absence of which appears to be just about the only major vulnerability of DPAPI, and even that can hardly be called vulnerability-would be sufficient. Overall, the entire DPAPI system is well balanced and robust.

Backing up Master Keys and restoring them from backups

Backing up Master Keys of a domain PC

When the computer is a member of a domain, the Master Key file stores the backup of user's Master Key. When creating a Master Key, DPAPI sends a request to the domain controller that stores the RSA encryption private/public key pair. The Master Key is encrypted using the domain's public key and stored as backup in the same file with the user's Master Key. If an error occurs while decrypting the primary copy of the Master Key, DPAPI sends the backup to the domain controller. The domain controller decrypts it using its private RSA key and sends the decrypted Master Key back.

Backing up Master Key of a stand-alone PC under Windows XP - Windows 7

When it comes to stand-alone computers of home users (Windows XP and higher), DPAPI employs a different recovery mechanism based on password reset disk. Password reset disk, which user can create at any time in the control panel, allows user to recover a forgotten password. The key phrase in the previous sentence is user can. The burden of data recovery rests entirely on user's shoulders.

But what happens if user changes the password after the password reset disk has been created? Everything is going to be just fine. The process is simple and, at the same time, robust as a village closet. When creating a password reset disk, the system creates a pair of the public and 2048-bit private RSA encryption keys. User's current password is encrypted using the public key and stored in user's registry key HKEY_LOCAL_MACHINE/SECURITY/Recovery/%SID% (for Windows XP - Windows Vista) or in HKEY_LOCAL_MACHINE/C80ED86A-0D28-40dc-B379-BB594E14EA1B (for Windows 7). Anyway, access to these keys is forbidden to all users of the system, including Administrators. And the private key that is required for the decryption of the password is saved on the disk. Thus, if after creating a password reset disk user changes the password, the new password is encrypted with the public RSA key and is saved in the registry, replacing the old one. Since the public RSA key matches the respective private key stored on the disk, the private key can be used any time later for decrypting the new password that has just been created and is stored in the registry. By the way, one of the latest versions of Windows Password Recovery can decrypt user's plaintext logon password when the password reset disk is available.

Backing up Master Keys on a stand-alone PC in Windows 2000

But the password reset system came only in Windows XP. What was before that? Indeed, despite the fact that Windows 2000 did not have password reset disk, user's Master Key backup was still performed on stand-alone computers. Both the primary Master Key and the Master Key backup were stored in the same! That means that any data encrypted with DPAPI could be decrypted by a potential malefactor WITHOUT knowing user's logon password (by just having physical access to the system).

Master Key file structure in Windows 2000
Figure 5. Master Key file structure in Windows 2000.

Microsoft strongly recommends upgrading Windows 2000 to a more current version. But if you have a good reason for not doing it, we are going to show you how to best protect your good old Win2K from a potential compromising. For that purpose, let's take a look at the local Master Key backup creation algorithm. A Win2K Master Key file conventionally consists of 5 units:

1. Header and system information
2. User's Master Key
3. Local backup encryption key
4. Local Master Key backup
5. Domain Master Key backup

Restoring user's Master Key from a local backup of begins with decoding the local backup encryption key. In the decryption process, we use the local computer account password (oh yes, it does have such an account), which is stored in the LSA secret named DPAPI_SYSTEM.

Once the local backup encryption key is obtained, we use it to decrypt the local backup of user's Master Key. It's as easy as 1-2-3. From this point of view, Win2K is more user-friendly, as even if user's password is deliberately erased, DPAPI can always restore the Master Key from the local backup. Hopefully, there's no need to explain the cost of that user-friendliness:

To partially prevent that outrage, we must change the operating mode for SYSKEY. Run the SYSKEY utility (press the WIN + R shortcut on the keyboard, then type in syskey.exe and then click OK), replacing the SYSKEY storage location. Now, to decrypt the DPAPI_SYSTEM LSA secret, a potential malefactor would have to either know the SYSKEY bootup password or have the SYSKEY startup disk.

Next to the Part 2 of the article >>