[WCF Security Series] authentication and credential: X.509 Certificate

In the previous article, we talked about common authentication methods: User Name/password authentication and Windows authentication. In the next article, we will introduce another important credential type: X.509 Certificate and the authentication method for X.509 Certificate. However, in order to allow readers to fully understand X.509 certificates, we need to first understand some background knowledge about asymmetric cryptography.

Directory
I. Asymmetric Cryptography (asypolicric Cryptography)
Encryption)
Digital Signature)
Ii. Digital Certificate
Digital Certificate issuing mechanism
Create a digital certificate
3. Analyze the X.509 certificate based on the three attributes of the certificate

 

I. Asymmetric Cryptography (asypolicric Cryptography)

According to Wikipedia, Cryptography is a kind of research or practice on Information Hiding. Modern cryptography is an interdisciplinary research that involves mathematics, computer science, and engineering. From the perspective of message exchange, cryptography is a theory and method that helps us sign and encrypt the entire message or a part of the message.

Digital Signature and encryption depend on the corresponding encryption Algorithm (Cryptographic Algorithm). From a mathematical point of view, the encryption Algorithm uses the encrypted data and key as independent variables, use encrypted data as a function of the dependent variable. The operation opposite to encryption is decryption. Based on whether the encryption and decryption keys are the same, we divide the encryption algorithms into symmetric encryption algorithms and asymmetric encryption algorithms. The former uses the same key for encryption and decryption, and the latter uses a pair of key pairs for encryption and decryption respectively. For asymmetric encryption, we select a key pair to encrypt the message. The ciphertext can only be decrypted through another key. Asymmetric cryptography has two main applications:

• Encrypt messages directly to solve confidentiality issues;
• Identity Authentication and data consistency through digital signatures.

Encryption)

Asymmetric encryption relies on a group of Key pairs consisting of Public Key/Private Key. Therefore, asymmetric encryption is also called Public Key Cryptography ). Specifically, both the public key and private key can be used for encryption. If one of the key pairs is used for encryption, the other is used for decryption. Public Keys are not private and can be obtained by anyone. Private keys belong to the entity that owns the key pair and belong to absolute privacy.

For message exchange, asymmetric message encryption ensures the confidentiality of messages. Specifically, the sender of the message uses the public key of the receiver to encrypt the message, and the receiver decrypts the message using its own private key. Because the private key is only owned by the receiver, no one else can decrypt the ciphertext.

Digital Signature)

The digital signature we mentioned actually involves two main tasks: Signing and Verification. The former creates a digital signature, and the latter verifies the validity of the signature. Next, we will briefly introduce how signatures and verification are implemented in the message exchange scenario.

The signing process is actually very simple, as shown in the whole process. The entire process includes two steps: first, the sender first uses an algorithm to perform hash calculation on the entire message content and obtains a hash code. Then, send and use your own private key to encrypt the hash code. The encrypted ciphertext is a digital signature. The digital signature will eventually be appended to the original message and sent to the receiver together with the public key in the sender's key pair (which is usually embedded in a digital certificate.

After these three items are received by the receiver, it can use this digital signature to verify the sender's real identity and message integrity. This process is called digital signature verification. Shows the entire digital signature verification process. First, the original message is extracted and a hash code is obtained using the same hash algorithm. Then, the digital signature is extracted, and the same algorithm is used to decrypt the digital signature using the public key to obtain the hash code for generating the digital signature. The two hash codes are compared. If they are consistent, the validity of the digital signature and the integrity of the message itself can be proved.

Asymmetric cryptography is used to encrypt messages to address the confidentiality of messages. The role of digital signatures is embodied in the following three aspects:

• Identity Authentication (Authentication ):The digital certificate can help us verify the real identity of the message sending source, because the digital signature content is determined by a private key, the sender generates a digital signature only through the private key of the private key, and uses the digital signature verification implemented by the other party using the public key. The private key is the private information of the owner and is not disclosed to the public. The verification of the digital certificate actually confirms whether the message sending source is the real owner of the private key.
• Deny (Non-repudiation ):The offset here indicates that the received message is digitally signed. If the recipient uses the public key of an entity to verify the digital signature, the entity is the sender of the message, the recipient is not allowed to deny the request. The reason is very simple. The public key can be used to successfully verify a digital signature, proving that the digital signature is generated using the correct private key.
• Message consistency (Integrity ):The digital signature can ensure the consistency of the entire message content, because the hash code originally used for private key encryption is obtained by hashing the entire message content. Once the message content changes, the digital signature verification fails.

When introducing the digital signature process above, we say that the sender's public key will be appended to the Message together with the generated digital signature, and sent to the receiver to assist the receiver in sender authentication. In fact, this public key is generally transmitted in the form of a digital certificate. Digit verification is used as the sender's credential here. Now let's briefly introduce the digital certificate.

Ii. Digital Certificate

A Digital Certificate or Public Key Certificate is a Digital signature statement, it binds the public key value to the identity of the individual, device, or service holding the corresponding private key. Since most general-purpose certificates are based on the X.509 V3 certificate standard, we call them X.509 certificates. X.509 certificates are widely used in Encryption and Digital signatures to provide authentication implementation and ensure data Integrity and Confidentiality ).

From the perspective of public key cryptography, the X.509 certificate is a file that binds the public key in a key pair to a topic. Specifically, binding with the public key includes not only the identifiable Name (DN: Distinguished Name) of the corresponding topic, but also other optional names related to the topic, such as the Email address and DNS Name.

The following code snippet shows the general structure of an X.509 Certificate. Including version (V3), serial number (7829), signature algorithm (md5WithRSAEncryption), issuer (CN = Root Agency), effective date (April 07,201 1 3:37:45 PM to January 01,204 0 7:59:59 AM), topic information (CN = www.artech.com), Public Key (00: b4: 31: 98 :... 52: 7e: 41: 8f), the Public Key algorithm (rsaEncryption), and the issuer's digital signature (93: 5f: 8f: 5f :... b5: 22: 68: 9f ).

   1: Certificate:

   2:    Data:

   3:        Version: V3

   4:        Serial Number: 7829 (0x1e95)

   5:        Signature Algorithm: md5WithRSAEncryption

   6:        Issuer: CN=Root Agency

   7:        Validity   

   8:            Not Before: Thursday, April 07, 2011 3:37:45 PM

   9:            Not After : Sunday, January 01, 2040 7:59:59 AM

  10:        Subject: CN = www.artech.com

  11:        Subject Public Key Info:

  12:            Public Key Algorithm: rsaEncryption

  13:            RSA Public Key: (1024 bit)

  14:                Modulus (1024 bit):

  15:                    00:b4:31:98:... 52:7e:41:8f

  16:                Exponent: 65537 (0x10001)

  17:    Signature Algorithm: md5WithRSAEncryption

  18:    93:5f:8f:5f: ... b5:22:68:9f

Digital Certificate issuing mechanism

In most scenarios, a digital certificate is used as a credential to prove a real identity, and the content of the topic part of the certificate represents the identity of the user certificate. So our first question is, why should we trust this certificate?

By analogy with the certificates used in daily life, we can deepen our understanding of digital certificates. For example, a resident ID card is a typical certificate. An important feature of this certificate is that it is issued by an officially recognized legal authority, generally, the identity card is used by the public security department where the account is located. For digital certificates, especially for commercial purposes, there are also relevant official institutions. We call such an institution a Certification Authority (CA: Certification Authority, (CA ). The familiar CAs include VeriSign and Thawte (OpenSSL. The certificate issuance system is a tree structure. Each CA can have one or more sub-cas, and the top CA is called the Root CA.

In daily life, people's general recognition of Resident Identity Cards comes from the trust of the issuing authority, that is, the public security authority where the accounts are located. This method is also suitable for digital certificates based on the method recognized by the Authority. In general, the certification authority determines the validity of the certificate by verifying the trust degree of the digital certificate CA. However, the question now is: the resident ID card has several anti-counterfeiting marks to help the validators identify authenticity. How can we determine whether a digital certificate is forged? To verify the validity of a digital certificate, you must prevent the following two situations:

• The user forged a certificate to impersonate the identity bound to the certificate's public key, and the certificate has a common CA;
• The user modifies the certificate issued by the CA to change the public key or other identity information. Both problems can be solved through digital signature technology.

From the digital certificate given above, we know that the certificate includes not only basic information about CA, but also an algorithm used for digital signature and signature. CA signs the data part of the certificate through its own private key, and places the signature together with the algorithm used by the signature in the certificate. According to the principle of digital signature we introduced earlier, if we have a CA public key, we can not only verify the CA of the certificate, but also verify whether the certificate content is tampered. So when the certificate is verified, where does the CA Public Key come from?

In fact, the CA Public Key is stored in a digital certificate and stored in a trusted certificate. Depending on the identity of the Certificate, we can divide it into two types: CA Certificate (CA Certificate) and End Entity Certificate (End Entity Certificate, the latter represents the final entity that accepts the CA certificate. In fact, there is no essential difference between the CA certificate and the terminal entity certificate. Except for the top-level Root CA, all CA certificates are issued by the higher-level CA, that is, the higher-level CA serves as the CA of the CA certificate. This hierarchical relationship of CA forms a Trust Chain ).

To store digital certificates, Windows has a corresponding Certificate storage area (Certificate stores ). Depending on the purpose or scope of trust, different certificates are stored in different storage areas. Due to space limitations, I will not introduce certificate storage too much. If you are interested, please refer to the MSDN online documentation. For certificate storage management, you can also use the certmgr.exe tool through command lines.

In several certificate storage areas, there is a storage area called Trusted Root Certificate Authority, all the CA certificates stored in it represent the trusted Certificate Authority. By default, for a certificate to be verified, if any CA on the CA trust chain has a certificate in the bucket, the certificate is legal.

Create a digital certificate

The user's recognition of digital certificates depends on the trust of the Certificate Authority. Therefore, the certificate authority determines the availability of digital certificates. Since officially recognized digital certificate authorities such as VeriSign and Thawte (OpenSSL) have a general degree of trust, they are ideal in most cases. However, we do not need to purchase these commercial certificates for study, research, or development and testing, and use some tools to create certificates manually.

Since the security mechanism of WCF is widely used in digital verification, it is necessary for us to learn to create digital certificates manually. Microsoft provides a powerful digital certificate creation tool named makecert.exe. We can use this tool to create the required digital certificate through command line. Define the meaning of all command line switches, corresponding address for http://msdn.microsoft.com/zh-cn/library/bfsktky3 (v = vs.80). aspx.

• -N x509name:Specifies the Certificate Name of the topic. The simplest way is to specify this Name in double quotes with the prefix CN =, for example, "CN = My Name ";
• -Pe:Mark the generated private key as exported, so that the private key can be included in the certificate;
• -Sr location:The storage location of the digital certificate, which has two optional values: CurrentUser (and LocalMachine. The former is based on the current login user, and the latter is based on the local machine;
• -Ss store:The storage area of the digital certificate;
• -Sky keytype:The key type of the specified topic. It must be signature, exchange, or an integer that represents the provider type. By default, 1 indicates the exchange key, and 2 indicates the signature key.

For example, the following command creates a digital certificate with the topic name www.artech.com. The certificate has an exchange key type and includes a private key.

   1: MakeCert -n "CN=www.artech.com" -pe -sr LocalMachine -ss My -sky exchange

Once the preceding command is successfully executed, the generated certificate is automatically saved to the Personal storage area based on the local machine. You can view the certificate through the Certificate Management Unit (Snap-in) of MMC. For details about how to view the certificate through MMC, refer to this address: http://msdn.microsoft.com/zh-cn/library/ms788967.aspx. Certificate MMC management unit. You can see that the digital certificate we created has been stored in the storage area specified in the command line, and the Authority is set to Root Agency by default.

3. Analyze the X.509 certificate based on the three attributes of the certificate

In the above section, we have introduced digital certificates from the perspective of asymmetric cryptography. Here we will further understand digital certificates from the perspective of User Certificates. We use the three attributes of user creden。 as an example to analyze digital certificates.

• Consistency between creden and declarations:The certificate statement reflects the topic-related information bound to the public key;
• Possession of the Credential by the holder:In most authentication processes, the digital certificate provided by the authenticated party has the corresponding private key. The private key proves to some extent that the digital certificate holder is the certificate owner;
• Certificate validity:This can be verified by the issuer's digital signature to the certificate.

If the authenticated party passes a digital certificate as the user certificate, the authenticated party generally uses the Trust Chain mode to authenticate the certificate. In this mode, the certification party traces the certificate from the direct authority of the digital certificate. If any authority is trusted, the authentication is successful. However, sometimes we still adopt other authentication modes, such as strict comparison of certificate subject information or even serial numbers.

For WCF, a client can not only use a digital certificate as a credential to prove its identity, but also provide it to the server for authentication. You can also bind a service to a digital certificate and use the certificate to represent the identity of the Service for the client to verify. In short, digital certificates are widely used in WCF.