ASP. NET Core Data Protection part 1, coreprotection

ASP. NET Core Data Protection part 1, coreprotection

Preface

The previous article recorded How to Use HTTPS (SSL) in Kestrel, which is actually used in our current project.

Data security is often a part that developers can easily ignore, including myself. In the past two years, many serious events have occurred due to security issues. Therefore, security is very important to our developers and we are responsible for the security of our code.

At work, we often see encode, base64, sha256, rsa, hash, encryption, md5, etc. Some people are still confused about them, I don't know when to use them. Some people think that MD5 is an encryption algorithm.

In ASP. NET Core, a batch of new APIs are provided for data protection, including encryption and decryption mechanisms. Let's take a look at them.

Directory
• Differences Between encryption, encoding, and hash
• Data Protection
• Data Protection in ASP. NET Core
• Conclusion

Differences between encoding, encryption, and hash 

1. Encoding

Encoding is the process of converting information from one form or format to another. They are reversible.
Such as url, base64, jsunicode, UTF-8, and so on.

2. Encryption
Encryption is reversible. Similar to encoding, data is converted from one form to another. It uses a specific encryption key to decrypt the data. Two encryption and decryption algorithms are available: symmetric encryption algorithms and asymmetric encryption algorithms.
Symmetry: DES, AES, SM1, RC4, etc.
Asymmetric: RSA, ECC, SM2, etc.

3. Hash
The "hash" refers to converting data of any length into a "fingerprint" of a fixed length. This process is irreversible. As long as the input changes, the output hash value is also very different.
Another feature is that the same input always has the same results. This feature is suitable for saving passwords.
Such as MD5, SHA256, SHA512, RipeMD, and WHIRLPOOL.

Introduction to Data Protection

When reading the official data protection documents, Microsoft's documents are written in this way, which roughly means that they are based on several requirements, you need to develop a set of data-protected libraries for use by trusted clients and untrusted clients. These requirements are:

1. authenticity and integrity
For example, the server generates a token that contains the permission xyz and will expire at a certain time in the future. In this case, you need to request a new token, how to ensure that the request token is not tampered.

2. Confidentiality
The server must ensure that the request is trusted. Therefore, it must contain information about the specific operation environment, such as a path, a permission, a handle, or other things that are specific to the server, this information should not be disclosed to untrusted clients, that is, similar to private keys.

3. Isolation
Then, a component must be made and independent from other components in the system. For example, if a bearer token component needs to use this component, it does not need to reference the anti-CSRF mechanism.

Further narrow down the demand scope. Encrypted data does not need to be used in systems other than the system. In addition, the processing speed should be as fast as possible, because each web Request uses an encryption component once or multiple times.

Based on the above requirements, Microsoft proposed to use cryptography, because it is a typical cryptography application scenario. This is indeed an Application Scenario of cryptography and an asymmetric encryption algorithm. However, we all know that asymmetric encryption is used by a public key and a private key to ensure security. Even if the public key is leaked, the entire communication is still secure, which is better than symmetric encryption. However, asymmetric encryption also has a disadvantage, that is, it takes a long time to encrypt and decrypt, and the speed is slow.

But the above requirement is to be as fast as possible. What should I do? So Microsoft engineers came up with a way to achieve this by streamlining and optimizing the asymmetric encryption mechanism. Because there is no need for cross-system or cross-language communication, no protocols or the like are required, which brings more possibilities to optimization.

At this point, I thought, how should I design and develop such a system based on the above points? How can we meet the requirements?
With this question, let's take a look at how Microsoft is doing it?

The following are some Summarized Design Principles:

1. configuration should be as simple as possible. By default, it should be free of configuration, and developers can run it directly.

2. Provide a Simple API, which should be easy to use and will not be easy to use and error.

3. Developers do not need to learn how to manage these keys (public keys and private keys). The system should automatically select algorithms and manage the key lifecycle. Ideally, developers should not access the original files of these keys.

4. The key should be protected and will not be remotely called. The system should have an automatic protection mechanism that can be automatically applied.

If I design such a library, I may not think so much, maybe only think of the first three points.

Let's take a look at the target audience:

1. application developers and framework developers (no need to learn any knowledge ).

2. Application developers and System Administrators (do not use the default configuration, but set some paths ).

3. provide scalable APIs or specific demand extensions for developers with higher security awareness (components requiring system rewriting have some unique requirements ).

The above shows how Microsoft analyzes the problem when developing a component. Maybe we can learn something from it.

Data protection in ASP. NET Core 

Web applications often need to store sensitive data (such as user passwords). Windows provides DPAPI for desktop programs, but it is not suitable for Web systems. ASP. NET Core provides a set of easy-to-use APIs to protect data.

ASP. in. NET Core, data protection is designed for the server to replace ASP. NET 1. in the x-4.x, machineKey is primarily used to ensure encryption and decryption of Cookie data when Form authentication is used to ensure that it is not modified. Or the ViewState data encryption and decryption are not tampered with, and the session Status identifier is verified.

Let's take a look at the simplest method:

Using System; using Microsoft. aspNetCore. dataProtection; using Microsoft. extensions. dependencyInjection; public class Program {public static void Main (string [] args) {// Add data protection to the service var serviceCollection = new ServiceCollection (); serviceCollection. addDataProtection (); var services = serviceCollection. buildServiceProvider (); // create an instance named MyClass var instance = ActivatorUtilities from DI. createInstance <MyClas S> (services); instance. runSample ();} public class MyClass {IDataProtector _ protector; // The parameter 'provider' comes from DI public MyClass (IDataProtectionProvider) {_ protector = provider. createProtector ("Contoso. myClass. v1 ");} public void RunSample () {Console. write ("Enter input:"); string input = Console. readLine (); // encrypted string protectedPayload = _ protector. protect (input); Console. writeLine ($ "Pro Tect returned: {protectedPayload} "); // decrypt string unprotectedPayload = _ protector. unprotect (protectedPayload); Console. writeLine ($ "Unprotect returned: {unprotectedPayload}") ;}}/ ** output: ** Enter input: Hello world! * Protect returned: CfDJ8ICcgQwZZhlAlTZT... OdfH66i1PnGmpCR5e441xQ * Unprotect returned: Hello world! */

In CreateProtector ("Contoso. myClass. in v1 "), the parameter" Contoso. myClass. v1 "can be understood as a public key, because ASP. NET Core Data Protection is non-symmetric encryption (see the previous section), so there should be a key in the system. The key here is ASP. NET Core helps you maintain it within the system.

Some may ask, how does one maintain my key in the system? Let's take a test first.

First, in my development environment, I first comment out the decryption code in the above program, then run the above program and enter a "Hello World !" To obtain an encrypted string CfDJ8ICcgQwZZhlAlTZT... OdfH66i1PnGmpCR5e441xQ (slightly written ).

Then I copied the same program to another machine in the development environment, and commented out the encryption code above, using the CfDJ8ICcgQwZZhlAlTZT generated in the first step... odfH66i1PnGmpCR5e441xQ for decryption. Note that we use "Contoso. myClass. v1 "as the public key.

Run the program and view the result:

The program throws a "System. Security. Cryptography. CryptographicException" exception.

Why?This is because each machine has its own private key. Because the private key is different during decryption, decryption fails and an exception is thrown.

Private Key 

Where is the private key stored?

1. If the program is hosted in Microsoft Azure, it is stored in the "% HOME % \ ASP. NET \ DataProtection-Keys" folder.

2. If the program is hosted in IIS, it is stored in the ACLed special registry key of the HKLM registry and accessible only by working processes, it is encrypted using windows DPAPI.

3. If the current user is available, that is, win10 or win7, it is stored in the "% LOCALAPPDATA % \ ASP. NET \ DataProtection-Keys" folder, and windows DPAPI encryption is also used.

4. If none of these are met, the private key is not persistent. That is to say, when the process is closed, the generated private key is lost.

The following is the private key file on the VM:

An xml configuration file in the C: \ Users \ USERNAME \ AppData \ Local \ ASP. NET \ DataProtection-Keys folder named: key-c37e3ed9-fbb5-47bc-9e8c-128afaf1c6d9.xml with the following content:

 <?xml version="1.0" encoding="utf-8"?><key id="c37e3ed9-fbb5-47bc-9e8c-128afaf1c6d9" version="1"> <creationDate>2016-08-15T05:21:16.7925949Z</creationDate> <activationDate>2016-08-15T05:21:16.7165905Z</activationDate> <expirationDate>2016-11-13T05:21:16.7165905Z</expirationDate> <descriptor deserializerType="Microsoft.AspNetCore.DataProtection.AuthenticatedEncryption.ConfigurationModel.AuthenticatedEncryptorDescriptorDeserializer, Microsoft.AspNetCore.DataProtection, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60">  <descriptor>   <encryption algorithm="AES_256_CBC" />   <validation algorithm="HMACSHA256" />   <encryptedSecret decryptorType="Microsoft.AspNetCore.DataProtection.XmlEncryption.DpapiXmlDecryptor, Microsoft.AspNetCore.DataProtection, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60" xmlns="http://schemas.asp.net/2015/03/dataProtection">    <encryptedKey xmlns="">     <!-- This key is encrypted with Windows DPAPI. -->     <value>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAArS6GBZu5C024S8VcNDckGgAAAAACAAAAAAAQZgAAAAEAACAAAABBUO4j0CscEZsdcHDAStXnDvtx+zFucmsG90sdhyjfgQAAAAAOgAAAAAIAACAAAABGr9fgvZkLAlgIZkGym5uLiufpaEcuVsp35+J96ItTYlABAADEZxVArK0QtxufuaRt/kVR2ZBZEoLhlYJ44BhvQDd6b9tN0L9Y7W2eeBPBefcZaGZk5xILwZYI5box9omwC/mp8t9wopVaratjZuNs21Al+JzxS+PeV9X0iPtRyfx2K7DJYOUT6IqoFR2ykL5MI9jvkIbUxcQOs0BKOwAHl4yAlYF2tR8pz1FkXKqZafovc11aOZeZhkfd2hiA53tan94bQOP43Z4HF+QWSazrq5IIqdFSOyZQemWL9Z7eYyoNpEktf3eGZQu/KBOg/BH5yizWa+6b7RLcEX6JdQ2/jpmnHNl+HPMIah3UZV0mRfAE2j58cUjosnV+LDQZoLn4OP70YWtO/tTBc4tsEY3n/WboL4PgPPmQ+2jfd/zmEQIon+4d7TY+mGh4c6wXAmAZF517UAHQMC1icx4HSJC8DTuWPlINihPyufejuPmLqW6CW8NAAAAA7ziObXv+Ax4Mm0AtZiGw0/IepDv/gJSxhEwLIDhfvQIQJv//G500EYtIbZJW6sWit//ypfjrUZYglHgKV+GpbA==</value>    </encryptedKey>   </encryptedSecret>  </descriptor> </descriptor></key> 

The file contains a creation date and an expiration date. If the interval is 90 days, the key becomes invalid after 90 days. The system automatically generates a new key and sets the new key as the active key. As long as the expired key still exists on the system, you can still decrypt any protected data.

The article should not be too long. I will write it later.

Summary 

This article gives a general introduction to ASP. NET Core Data Protection and contains a simple usage method. In actual use, many components are actually used internally, such as Session middleware, Identity middleware, and Authercation middleware, which may not be used by common developers during coding, however, if you do not understand this mechanism during distributed system deployment, you may be in trouble (For details, refer to this article on the cricket blog). You can still look forward to the following article, learn more about it and master it.

The above is all the content of this article. I hope it will be helpful for your learning and support for helping customers.