DPAPI on the fingers
Hello!
Back in December last year, I first encountered the Data Protection Application Programming Interface (abbreviated DPAPI). Then I studied the method of storing usernames / passwords in the Chrome browser . I promised to sign this system in detail and on the fingers. It's not good to lie, so welcome under the cat!
I will start everything from scratch, what DPAPI is, why it was created and who needs it. And then I will tell you how it works.
')
Information security problems have long touched everyone, and Microsoft was no exception, office PCs, home systems, servers — all to one degree or another, required protection from the hands of others.
Storing data in the clear was already at least not solid. Therefore, with the release of Windows 2000, the world saw the nascent and raw version of DPAPI. Its main purpose is to protect stored passwords and confidential information on a computer. Moreover, in such a way that the owner of this data (the user) did not even guess about the existence of protection, and this data was inaccessible to the cracker. The ideology of the system has not changed since then. Algorithms were changing, holes were closing, but the essence was still the same.
As a result, a full-fledged security system appeared in which secret data was available exclusively to the user-owner and to no one else.
This is a trivial scheme for working with DPAPI.
The application accesses the OS by setting the parameters Mysecret (string / bytes, which need to be secret) and Entropy (entropy, about it a little later. This parameter is not required).
At the output we get BLOB.
BLOB - B inary L arge OB ject. Decryption is backronym. In essence, this is an array of binary data. "Big and shapeless."
This BLOB is a kind of container, which contains in the open form the data necessary for decryption, as well as the cipher itself. The application saves it (for example, all the same Chrome, which wrote this BLOB as an array of bytes in one of the SQLITE database fields), and then, if necessary, decrypts (the second half of the scheme).
It looks like the same scheme, but in more detail.
A cryptographic provider is a set of algorithms for hashing, encryption, key exchange and digital signature in the form of a module. For example, in Russia there are our state-of-the-art algorithms and a crypto-provider that unites them, so if you give it to the system, then instead of the standard AES, SHA, RSA, our guests will be used. All this is configured in the registry. From this it follows that DPAPI itself does not make any difference with which algorithms to work; they change “like gloves”, which makes the system universal.
About LSA and CryptoAPI I will answer with a quote from Wikipedia:
All the most interesting things happen in the depths of LSA, mortals have nothing to do there, so it is almost impossible to influence the work of this process.
Now let's talk directly about the encryption / decryption scheme.
In fact, these are only 3 functions:
1) Opening the master key
2) Encryption
3) Decryption
No matter what we want to do - encrypt or decrypt - first you need to open the master key.
The master key (hereinafter referred to as MK ) is the encryption key for the symmetric encryption algorithm (by default in Windows 7 it is AES). It is also a BLOB, in which there is open (ID, algorithms ..) and private (key itself) information.
MK - the most important part of the system, so it is under reliable protection.
Here the developers have a dilemma. How to make so that the user does not get the password (USB-keys), but at the same time how to protect the master key? Obviously, for this you need to take the "personal" and unique information system. That is, it is the user's login password. After logging in, the LSA stores this password and issues it to it when requested by CryptoAPI.
This is, strictly speaking, a key decryption scheme.
SID is a unique security identifier.
The password cache from LSA is the cache of your login password, if not, then null is taken.
Then the settings are read.
HMAC (short for English hash-based message authentication code, message identification hash code).
To put it simply, it is the same hash function that even works on the basis of all the same MD5, SHA ... Only to get the hash, a password is also required, that is, instead of 1 parameter, there are 2 of them.
PBKDF2 - Password-Based Key Derivation Function. Standard key generation based on the password. Uses pseudo-random function to get keys. Key length is not limited. In fact, this is a “complication” of the hashing algorithm. If the same SHA256 is calculated in a fraction of a second, then with its help the calculation will be delayed to 0.1 second. The important parameter here is the number of iterations. On my computer, there are 17400 of them by default. The more of them - the longer the algorithm runs, the harder the selection. If you do not go into the details of the algorithm, then you can imagine that it performs the algorithm SHA256 17400 times.
SHA (SHA (SHA ... SHA (string)) ...)
It takes time to do this, and since SHA claims to be a mythological unidirectional function, the output will be unique.
0.1 seconds is nothing when the algorithm is executed 1 time (from the user's point of view), but it is a nightmare to go through.
MasterKey BLOB is just data with an encrypted key, but it also stores public data that is available for reading by the system, such as salt, master key ID and other service parameters.
As a result, the output we get our key.
Now we proceed to encryption.
Everything is quite simple here, first the key, HMACKEY1 (generated by the system randomly) and the entropy you entered (some more, and I will tell about it in detail) are given to the analog of the HMAC algorithm (now it has 3 incoming parameters). The received data is a private key for encrypted data. Salt is also generated randomly. All this data is used when creating a BLOB, which will already be returned to the program upon an encryption request.
Decryption is similar.
Here, all the necessary data is read from the BLOB'a. At the exit we get our secret.
In the blob master key there is a lot of information open for reading. Version of DPAPI, its ID, various flags, size of MK, salt, number of iterations, hashing algorithm, encryption.
In BLOB'e with encrypted data, too much information. Again, the version used by the crypto-provider, ID MK, which was encrypted, a description, and even a signature (hash sum).
Separately, I want to note such a thing as CredHistory .
Credential History. At first glance - an unnecessary thing, but everything happens.
Let's say you changed your password. From the point of view of the algorithm, your master key has become unreachable. There is nothing to decipher! But this nuance is thought out. The system will re-encrypt the master key. But this process is time consuming ... The key master can be a lot, and you need to re-encrypt them all (by default, a new one is generated every 90 days to increase security, and the encrypted data is tied to a specific key). Therefore, Microsoft created this algorithm. The previous password is not forgotten ... It is encrypted with the current password and saved to the stack. Therefore, if suddenly the system failed to decipher the master key, then it is in no hurry to surrender. Using the current password, she decrypts the first entry in the CredHist. And with the received password it tries to decrypt the master key again. Not? Using this password, she decrypts the next password in the chain. The process will continue until the passwords are exhausted in the chain, or the master key is decrypted. How can it happen that MK does not decipher? For example, if you used third-party software to force a password reset. Typically, such software does not trigger the "re-encryption" of DPAPI keys. So after this procedure, you lose all your passwords saved by this system. But if you change the password after that to the one that is in CredHist, then all passwords will come to life.
Imagine that guests came to you with a child. The child took - and changed the password. Using a third-party utility, you reset the password. All your secret data has become inaccessible to you, but after you have returned your old password, and the data is again with you. If the password was reset with a floppy disk to reset the password, then the system starts re-indexing. Incidentally, the RSA system is used to reset the password with a floppy disk. The public key for encryption and the cipher itself are stored in the registry, and the private key is stored on a diskette. When changing the password, the new password is encrypted with the public key and overwritten.
Now you can tell about the entropy. If you understand how the system works, it has become obvious to you that any data encrypted without entropy (or with the same entropy) is easily decrypted by any application running from the same user. That is, the information is publicly available within the user’s domain. Entropy, in its essence, is a password for specific encrypted data. Set the entropy, and no software on your computer without knowing this parameter can decipher the BLOB.
Microsoft set an interesting example of using entropy in IE. Passwords with logins are stored in the registry. The key name is the hash of the link that is being authenticated, and the content is the encrypted data. So this link is entropy. That is, even having intercepted this data and having an open master key, you will have to iterate through the links, and, as a result, having all the data, you will most likely not be able to fully disclose the stolen data.
The scheme is as follows:
1) The link opens mysite.ru/login.php.
2) IE takes the hash from this link.
3) IE looks for a name among the key names that matches the given hash.
4) Using the contents of the key (BLOB) and the link, as entropy, IE opens the information with logins and passwords.
If, however, at point 3 no matches were found, this means that the user has not yet entered anything on this page.
I want to convey my thanks to the Passcape project and, separately, to the project administrator, who gladly (hopefully) answered all the questions I had about DPAPI. Their application “Windows Password Recovery”, as far as I know, is unique, it fully emulates DPAPI.
Thank you very much for your attention, I will be happy to answer your questions.
Back in December last year, I first encountered the Data Protection Application Programming Interface (abbreviated DPAPI). Then I studied the method of storing usernames / passwords in the Chrome browser . I promised to sign this system in detail and on the fingers. It's not good to lie, so welcome under the cat!
I will start everything from scratch, what DPAPI is, why it was created and who needs it. And then I will tell you how it works.
')
Briefly about the main thing
Information security problems have long touched everyone, and Microsoft was no exception, office PCs, home systems, servers — all to one degree or another, required protection from the hands of others.
Storing data in the clear was already at least not solid. Therefore, with the release of Windows 2000, the world saw the nascent and raw version of DPAPI. Its main purpose is to protect stored passwords and confidential information on a computer. Moreover, in such a way that the owner of this data (the user) did not even guess about the existence of protection, and this data was inaccessible to the cracker. The ideology of the system has not changed since then. Algorithms were changing, holes were closing, but the essence was still the same.
As a result, a full-fledged security system appeared in which secret data was available exclusively to the user-owner and to no one else.
Principle of operation
This is a trivial scheme for working with DPAPI.
The application accesses the OS by setting the parameters Mysecret (string / bytes, which need to be secret) and Entropy (entropy, about it a little later. This parameter is not required).
At the output we get BLOB.
BLOB - B inary L arge OB ject. Decryption is backronym. In essence, this is an array of binary data. "Big and shapeless."
This BLOB is a kind of container, which contains in the open form the data necessary for decryption, as well as the cipher itself. The application saves it (for example, all the same Chrome, which wrote this BLOB as an array of bytes in one of the SQLITE database fields), and then, if necessary, decrypts (the second half of the scheme).
It looks like the same scheme, but in more detail.
A cryptographic provider is a set of algorithms for hashing, encryption, key exchange and digital signature in the form of a module. For example, in Russia there are our state-of-the-art algorithms and a crypto-provider that unites them, so if you give it to the system, then instead of the standard AES, SHA, RSA, our guests will be used. All this is configured in the registry. From this it follows that DPAPI itself does not make any difference with which algorithms to work; they change “like gloves”, which makes the system universal.
About LSA and CryptoAPI I will answer with a quote from Wikipedia:
The local security authentication server (Local Security Authority Subsystem Service, LSASS) is part of the Windows operating system responsible for authorizing local users of a single computer. The service is critical, since without it, logging in to the system for local users (not registered in the domain) is impossible in principle.
CryptoAPI is an application programming interface that provides Windows developers with a standard set of functions for working with a cryptographic provider. Included in the Microsoft operating systems. Most CryptoAPI features are supported since Windows 2000.
All the most interesting things happen in the depths of LSA, mortals have nothing to do there, so it is almost impossible to influence the work of this process.
Even further into the forest
Now let's talk directly about the encryption / decryption scheme.
In fact, these are only 3 functions:
1) Opening the master key
2) Encryption
3) Decryption
No matter what we want to do - encrypt or decrypt - first you need to open the master key.
The master key (hereinafter referred to as MK ) is the encryption key for the symmetric encryption algorithm (by default in Windows 7 it is AES). It is also a BLOB, in which there is open (ID, algorithms ..) and private (key itself) information.
MK - the most important part of the system, so it is under reliable protection.
Here the developers have a dilemma. How to make so that the user does not get the password (USB-keys), but at the same time how to protect the master key? Obviously, for this you need to take the "personal" and unique information system. That is, it is the user's login password. After logging in, the LSA stores this password and issues it to it when requested by CryptoAPI.
This is, strictly speaking, a key decryption scheme.
SID is a unique security identifier.
The password cache from LSA is the cache of your login password, if not, then null is taken.
Then the settings are read.
HMAC (short for English hash-based message authentication code, message identification hash code).
To put it simply, it is the same hash function that even works on the basis of all the same MD5, SHA ... Only to get the hash, a password is also required, that is, instead of 1 parameter, there are 2 of them.
PBKDF2 - Password-Based Key Derivation Function. Standard key generation based on the password. Uses pseudo-random function to get keys. Key length is not limited. In fact, this is a “complication” of the hashing algorithm. If the same SHA256 is calculated in a fraction of a second, then with its help the calculation will be delayed to 0.1 second. The important parameter here is the number of iterations. On my computer, there are 17400 of them by default. The more of them - the longer the algorithm runs, the harder the selection. If you do not go into the details of the algorithm, then you can imagine that it performs the algorithm SHA256 17400 times.
SHA (SHA (SHA ... SHA (string)) ...)
It takes time to do this, and since SHA claims to be a mythological unidirectional function, the output will be unique.
0.1 seconds is nothing when the algorithm is executed 1 time (from the user's point of view), but it is a nightmare to go through.
MasterKey BLOB is just data with an encrypted key, but it also stores public data that is available for reading by the system, such as salt, master key ID and other service parameters.
As a result, the output we get our key.
Now we proceed to encryption.
Everything is quite simple here, first the key, HMACKEY1 (generated by the system randomly) and the entropy you entered (some more, and I will tell about it in detail) are given to the analog of the HMAC algorithm (now it has 3 incoming parameters). The received data is a private key for encrypted data. Salt is also generated randomly. All this data is used when creating a BLOB, which will already be returned to the program upon an encryption request.
Decryption is similar.
Here, all the necessary data is read from the BLOB'a. At the exit we get our secret.
In the blob master key there is a lot of information open for reading. Version of DPAPI, its ID, various flags, size of MK, salt, number of iterations, hashing algorithm, encryption.
In BLOB'e with encrypted data, too much information. Again, the version used by the crypto-provider, ID MK, which was encrypted, a description, and even a signature (hash sum).
"Back to the beginning"
Separately, I want to note such a thing as CredHistory .
Credential History. At first glance - an unnecessary thing, but everything happens.
Let's say you changed your password. From the point of view of the algorithm, your master key has become unreachable. There is nothing to decipher! But this nuance is thought out. The system will re-encrypt the master key. But this process is time consuming ... The key master can be a lot, and you need to re-encrypt them all (by default, a new one is generated every 90 days to increase security, and the encrypted data is tied to a specific key). Therefore, Microsoft created this algorithm. The previous password is not forgotten ... It is encrypted with the current password and saved to the stack. Therefore, if suddenly the system failed to decipher the master key, then it is in no hurry to surrender. Using the current password, she decrypts the first entry in the CredHist. And with the received password it tries to decrypt the master key again. Not? Using this password, she decrypts the next password in the chain. The process will continue until the passwords are exhausted in the chain, or the master key is decrypted. How can it happen that MK does not decipher? For example, if you used third-party software to force a password reset. Typically, such software does not trigger the "re-encryption" of DPAPI keys. So after this procedure, you lose all your passwords saved by this system. But if you change the password after that to the one that is in CredHist, then all passwords will come to life.
Imagine that guests came to you with a child. The child took - and changed the password. Using a third-party utility, you reset the password. All your secret data has become inaccessible to you, but after you have returned your old password, and the data is again with you. If the password was reset with a floppy disk to reset the password, then the system starts re-indexing. Incidentally, the RSA system is used to reset the password with a floppy disk. The public key for encryption and the cipher itself are stored in the registry, and the private key is stored on a diskette. When changing the password, the new password is encrypted with the public key and overwritten.
Entropy
Now you can tell about the entropy. If you understand how the system works, it has become obvious to you that any data encrypted without entropy (or with the same entropy) is easily decrypted by any application running from the same user. That is, the information is publicly available within the user’s domain. Entropy, in its essence, is a password for specific encrypted data. Set the entropy, and no software on your computer without knowing this parameter can decipher the BLOB.
Microsoft set an interesting example of using entropy in IE. Passwords with logins are stored in the registry. The key name is the hash of the link that is being authenticated, and the content is the encrypted data. So this link is entropy. That is, even having intercepted this data and having an open master key, you will have to iterate through the links, and, as a result, having all the data, you will most likely not be able to fully disclose the stolen data.
The scheme is as follows:
1) The link opens mysite.ru/login.php.
2) IE takes the hash from this link.
3) IE looks for a name among the key names that matches the given hash.
4) Using the contents of the key (BLOB) and the link, as entropy, IE opens the information with logins and passwords.
If, however, at point 3 no matches were found, this means that the user has not yet entered anything on this page.
I want to convey my thanks to the Passcape project and, separately, to the project administrator, who gladly (hopefully) answered all the questions I had about DPAPI. Their application “Windows Password Recovery”, as far as I know, is unique, it fully emulates DPAPI.
Thank you very much for your attention, I will be happy to answer your questions.
Source: https://habr.com/ru/post/148602/
All Articles