Digital Certificate and its authentication process [reprinted], digital certificate reprinted

Digital Certificate and its authentication process [reprinted], digital certificate reprinted

As we all know, public key cryptography makes it easy to use digital signatures, encrypted communications, and other key services by using the public key and private key pair. The reason why public key technology can be widely used is that for entities that use the public key in the key pair to obtain the Security Service, they can easily obtain the public key, that is, key distribution and management is easier than symmetric key distribution and management. So some people say that asymmetric cryptographic algorithms are a technological revolution in computer security communication.
Of course, public key distribution also requires data integrity protection measures, that is, data integrity services are required to ensure that the public key is not tampered, and ensure that the public key must be bound to the identity of the declared owner. The ultimate goal is to provide a simple and secure identification mechanism, one can ensure the integrity of the public key and its related information, and the other can bind the public key and its related information to the declared owner in a trusted way.
This is the certificate mechanism. The certificate is an authoritative document in e-commerce. The certificate issuer must be trustworthy, it is issued by authoritative, trustable, and impartial third-party organizations. Certificates are a security mechanism that ensures the implementation and completion of PKI identity authentication, integrity, confidentiality and undeniable security services.
A certificate is a new security mechanism, which may be confusing to users in the early stage. For example, an online shopper, an online bank customer, or an administrator of a bank's payment gateway, they often think: why is the security of digital certificates installed in browsers/servers on the Internet? How are they operated in actual authentication? How does it ensure security? To address these common problems, this article discusses the structure and semantics, content and usage of the X.509V3 Public Key Certificate, and the entire process of checking the items of the certificate and how to check them, to describe the security of certificate authentication. I believe that after learning about the "game rules" of certificate authentication, the majority of readers will understand the security services that the certificate mechanism can perform for identity recognition and authentication. Certificates are indeed the patron saint of Online Transaction Security.
1. Related Concepts
1. About CA
CA (Certification Authority), known as the "Certification Authority" in PKI, issues an electronic certificate to each entity in the e-commerce environment, that is, digitally sign the identity information of the entity and the corresponding public key data, used to bind the public key and identity of the entity to prove the authenticity of the identity of each entity on the Internet; and is responsible for testing and managing certificates in transactions. CA is a third-party organization that authenticates the authority, trustworthiness, and impartiality of e-commerce and online banking transactions. It is an important infrastructure for e-commerce and a security guarantee for e-commerce.
2. about digital certificates
Digital certificates are also called electronic certificates, or certificates for short. In many cases, digital certificates, electronic certificates and certificates are synonymous with X.509 Public Key certificates, which comply with the ITU-T X.509 V3 standard. Certificates are a new security mechanism developed along with the formation of PKI, which implements identity identification and identification (authentication), integrity, confidentiality and undeniable Security Services (security requirements ); A digital certificate is a proof of the online id of each entity in e-commerce. It proves the matching relationship between the declared identity of the entity and its public key, so that the real identity is bound with the public key on the certificate; in terms of the public key management mechanism, digital certificates are the media for key management in the public key system. In the public key system, the distribution and transmission of public keys are achieved by the certificate mechanism. Therefore, digital certificates are sometimes referred to as public key certificates. Digital Certificates are authoritative electronic documents issued by authoritative, credible, and impartial third-party organizations (CAS.
Ii. certificate content and usage
The certificates issued by CFCA follow the X.509 V3 standard. The basic format and usage of the certificates are as follows:
1. Certificate Format Version
Certificate version number, used to specify the X.509 version number used in the certificate format for directory query.
2. Certificate Serial Number
Certificate serial number. The Certificate Issuer specifies the unique serial number of the certificate to identify all certificates issued by the CA for directory query.
3. Signature Algorithm Identifier
Signature Algorithm ID, used to specify the signature algorithm used for this certificate (such as SHA-1 and RSA ).
4. Issuer
The Name of the CA that issues the certificate. It is used to specify the unique Name (DN, Distinguished Name) of the CA that issues the certificate for authentication.
5. Validity Period
Certificate validity period, specifying the certificate start date (notBefore) and end date (notAfter), used to verify the certificate validity.
6. Subject
The name of the user body, which is used to specify the unique X.500 name (DN) of the certificate user for authentication.
7. Subject Public Key Information
The public key of the user.
(1) Algorithm Identifier, Algorithm Identifier. The algorithm used to identify the public key.
(2) Subject Public Key, which is the user's main Public Key. Used to identify the public key itself for encryption/decryption and digital signature.
8. Issuer Unique ID
The issuer can select a unique identifier, which is rarely used.
9. Subject Unique ID
The unique identifier of the subject certificate owner, rarely used.
10. Extensions
The extended certificate section (extended domain) is used to specify additional information.
(1) Authority Key Identifier, the public Key ID of the issuer CA.
Key Identifier, Public Key Identifier;
Cert Issuer, the certificate Issuer's Identification name, email, IP address, and so on;
Cert Serial Number, the Serial Number of the issued certificate, used to issue the root certificate and cross-certification.
(2) Subject Key Identifier, the public Key ID of the user's Subject. The unique identifier of the key contained in the certificate body. It is used to distinguish multiple-pair keys of a certificate owner. It is mainly used to decrypt files encrypted by the previous public key.
(3) CRL Distribution Point, CRL Distribution. Specifies the location where CRL segments are located for distributed storage.
(4) Key Usage: the Public Key Usage in the certificate. It is used to specify the Public Key Usage, digital signature, and encryption.
(5) Private Key Usage Period. The validity Period of your Private Key. Specifies the start date and end date of the private key signed by the user.
(6) Certificate ies, a list of Certificate Policies recognized by CA. Specifies the policy applicable to the user certificate. The certificate policy can be expressed by the object identifier, a detailed prompt (200 characters ).
(7) Policy Mappings: Policy ing. It indicates the equivalent ing between one or more policy identifiers between two cas -- only exists in the CA certificate.
(8) Subject Alt Name, the user's substitute Name. Used to specify the user's substitute name.
(9) Issuer Alt Name, the substitute Name of CA. Used to specify the proxy name of the CA.
(10) Basic Constraints: Basic Constraints. Used to indicate whether the certificate user is an end user or a CA and used for the transaction path.
(11) Subject Directory Attributes: Attributes of the user's main Directory. Specifies a series of attributes of the certificate owner.
11. Signature Acgorithm
ID of the CA signature algorithm.
12. CA Signature
CA signature.
Iii. certificate authentication process
The above describes the certificate structure, content, and usage. How do certificates authenticate each other? How do we identify each other's identities? Why is the certificate mechanism secure?
First, let's take a look at the certificate authentication process (also known as the verification process ).
1. Unpack the certificate
The so-called certificate unblocking is to verify whether the issuer's CA Public Key can properly unbind the "issuer's digital signature" in the client's physical certificate ". After the two certificates are exchanged and transmitted, they must be split to see if they can be split. A certificate or certificate chain is used to obtain a public key. It can be X1p? X1 <X2>, which is an infix operation. The left operand is the public key of an authentication authority, and the right operand is a certificate issued by the authentication authority. If it can be properly unlocked, the output result is the user's public key.
The certificate content list shows that the final content of the certificate structure is the digital signature of the CA, that is, a trusted CA has signed the certificate with its own private key. If the CA's public key can be used to split a user entity certificate, the signature is verified to be correct. It proves that this certificate is issued by an authoritative and trusted certification body. Therefore, this entity certificate is authentic and trustworthy.
2. Certificate Chain Verification
The so-called certificate chain verification is to trace the trusted ca root through the certificate chain ). In other words, verify that the CA that issues the user's physical certificate is an authoritative and trusted CA, such as CFCA. Certificate Chain verification requires that each certificate in the path from the final entity to the root certificate is valid, and each certificate must correctly correspond to the authority of the CA that issues the certificate. The operation expression is Ap? A <B> B <C> indicates that this operation uses the public key of A to obtain the Public Key Bp of B from the certificate of B, then, use Bp to unseal the C certificate. The final result of the operation is the C Public Key Cp. This is the process of dismounting the certificate chain.
(1) certificate chain definition. The certificate chain is also called the authentication chain. It is a series of certificates from the final entity to the root certificate. The process of processing this certificate chain is that all the root predecessors point to the initial root certificate, that is, the children are connected to their fathers. 1.
The certificate (whether SET or Non-SET Certificate) is verified by the trust level shown in Figure 1. Each certificate corresponds to the digital signature of the entity that issued the certificate ., SET: CCA (MCA, PCA)-B-R; non-SET: CCA (BCA, UCA)-P-R. In this way, the level-1 public key can be used to unbind the digital signature of each level, and the Trusted root ca root can be traced. They verify the certificate by going to the trust level of the root ca root.
(2) Verify the certificate chain from the user entity certificate to the root ca. The specific practices are shown in figure 2 below.
From the comparison above, we can see that the Authority Key Identifier extension Cert Issuer in the user entity certificate, that is, the certificate Issuer's screening name, it should match the name of the CA that issued the certificate, as indicated by the arrow in. That is, the Subject Name in the CA certificate is the parent Name of the Issuer Name in the user entity certificate, and becomes a sub-Name for the upper-level CA. The Issuer Name in the CA certificate is the Name of the upper-level CA, become a trusted chain structure. In this way, the entity certificates at all levels are verified and gradually traced back to the end point of the chain-Trusted Root CA, such as CFCA.
3. Serial number verification
Serial number verification is to check whether the signature entity serial number in the entity certificate is consistent with the serial number of the issuer certificate to verify the authenticity of the certificate. The verification procedure is: the Authority Key Identifier extension Cert Serial Number in the user's physical Certificate, that is, the Serial Number of the issued Certificate. Check the Serial Number of the Certificate Serial Number Certificate in the CA Certificate. The two should be consistent, otherwise, the certificate is not issued by a trusted CA.
4. Validity Period Verification
Validity Period verification is to check whether the date used by the user certificate is valid or not. The specific practices are as follows:
(1) The Validity Period of the user entity certificate, Validity Period and private Key Priva Key Usege Period, should be within the Validity Period of the CA certificate. 2. As shown in the bold arrow, if the validity period of the CA certificate is exceeded, the entity certificate should be voided and the transaction is insecure.
(2) The notBefore date in Validity Period should be within the Private Key Validity Period of the CA certificate Private Key Usagc Period; otherwise, the certificate is insecure.
5. query the certificate abolition list
The so-called Certificate Revocation List query is to check whether the user's certificate has been voided and published in the Certificate Revocation List. It is generally called CRL query, also known as "blacklist query ". When an entity certificate needs to be abolished due to reasons such as private key leaks, it should be declared to CA as void in a timely manner. CA publishes certificates to the certificate library in X.500 format in real time through the LDAP standard protocol for open queries between entities during access.
Mutual authentication is performed between the browser and the Web server, that is, two-way CRL query. When the Web server queries whether the browser certificate is "blacklisted, the browser also goes to the certificate library to check whether the Web server certificate is valid. This is a two-way authentication mechanism. CFCA's enterprise-level Advanced Certificate is a feature of China's Financial ca pki. Generally, the B-to-B model adopts this method for online banking and online shopping. Of course, there is also a "one-way authentication" method, that is, the Web server only checks the validity of the browser certificate, such as SSL certificate authentication, which is a common practice of CA.
6. authentication of the certificate usage policy
The Certificate is used in the same way as the Certificate Policy or use restriction stated in any declared Policy. That is, the Certificate Policies ies in the user's physical Certificate should be the list of Certificate Policies recognized by the CA. It is limited by special extension domains to specify the policies applicable to user certificates. These policies should be specified in the CA's CPS, and the object identifier should not exceed 200 characters. User Certificates cannot be implemented without CA-recognized policies. For example, the Policy URL and Policy e-mail address must be stated by the root Policy.
7. Confirmation of the final user entity certificate
To ensure the security of certificate usage, the internal administrator certificate issued by the CA must be differentiated from the real certificate of the end user. To this end:
(1) The default value of Basic Constraints in the extended domain represents the End Entity to distinguish other CA internal management certificates and prevent certificates from being used for different purposes.
(2) In the extended domain Key Usage, it must be valid for the declared purpose and used for digital signatures or transmission encryption. to ensure security, it must be clearly separated and cannot be mixed for auditing in case of disputes, provides a basis for arbitration.
Of course, these operations are transparent to users.
Several ideas about digital certificates (two-way) [ZT]
Two-way digital authentication requires that the client and server have their own private key and Public Key (generally X509 Certificate ),
The Project Server is Apache or Tomcat, and the client can usually publish the Pkcs12 package.
How SSL works:
The SSL protocol uses asymmetric encryption technology to securely transmit information between the two parties. Information Transmission is confidential and complete, and both parties can identify the other party. Different from the common http protocol, we use the https protocol when establishing an SSL secure connection with the website, that is, access through https: // ip: port. When we establish an https connection with a website, we need to shake hands between our browser and the Web Server to complete identity authentication and key exchange, so as to establish a secure connection. The specific process is as follows:
Your browser sends the SSL version number, encryption parameters, session-related data, and other necessary information to the server.
The server sends the SSL version number, encryption parameters, session-related data, and other necessary information to the browser, and also sends the server certificate to the browser. If the SSL of the configuration server needs to verify the user identity, you must also send a request asking the browser to provide the user certificate.
The client checks the server certificate. If the check fails, it prompts that an SSL connection cannot be established. If yes, continue. The client browser generates a pre-master secret for this session and sends it to the server after encrypting it with the server public key. If the server requires customer identification, the client must sign other data and send it together with the client certificate to the server.
If the server requires customer identification, check whether the CA that signs the customer certificate is trusted. If the session is not in the Trust List, end the session. If the check succeeds, the server uses its own private key to decrypt the received pre-master secret and uses it to generate the master secret for this session through some algorithms.
Both the client and server use this master secret to generate the session key (symmetric key) for this session ). This session key is used to send any messages after the SSL handshake ends. The main reason for doing so is that symmetric encryption is more than an order of magnitude less computation than asymmetric encryption, which can significantly increase the computing speed of both parties' sessions.
The client notifies the server that all subsequent messages are encrypted using this session key. And notifies the Server client that the SSL handshake has been completed.
The server notifies the client that all subsequent messages are encrypted using this session key. The client server is notified that the SSL handshake has been completed.
The handshake process ends and the session has been established. Both parties use the same session key to encrypt and decrypt the sent and received information respectively.
Concepts:
1. Personal Information Exchange (PKCS #12)
The personal information exchange format (PFX, also known as PKCS #12) allows certificates and related private keys to be transmitted from one computer to another or removable media.
2. DER and Base64 encoding
In various certificates, the private key and its parameters are generally expressed in two ways. Der is a binary representation format, and Base64 is self-explanatory. There is no difference in the application process, but because of Base64 text, it is easy to spread in the HTTP environment.
3. PKCS #10: Describes the certificate request syntax. The certificate request file generally uses the csr extension.
4. The X509 Certificate encapsulates the public key. In general, the certificate can be considered as the public key. Of course, the public key may not exist in the form of an X509 Certificate.
5. PKCS7 is generally used for certificate chain. It ends with p7b.
6. CRL, Certificate revocation list. Certificate failure list.
7. Openssl provides all-round support for CA authentication. Keytool, JCA, and JCE APIs correspond to Java's implementation of PKI.
Several problems.
1. How to issue the client digital certificate and Private Key,
Customers can go to the counter, handled by the salesperson
You can generate your own CSR file and submit it to your website.
The customer adds relevant information on the webpage, which is generated by the system and sent back to the customer.
The above three methods must be used to confirm the authenticity of the customer. The corresponding support system must be developed. Java jce api, Openssl API, Openssl Commandline, and Keytool can be used for implementation.
2. Digital Certificate failure.
If the corresponding key of the Certificate is lost, the customer may need to re-sell the Certificate. Therefore, a complete CA Foundation should be established to support the Certificate revocation list, which requires a complete CA solution. you need to develop a support system.
3. Whether all customers must use digital certificates.
In theory, customers who use and do not use digital certificates will exist at the same time at least during a period of transfer. In this way, two different systems need to be established and the same portal problem must be solved.
4. Does the program require user name and password authentication.
5. Whether USB Key is supported (no additional development work is required ).
6. The project front-end uses Flash to manage the connection to the backend server. After testing, it can read the certificate (and private key) information of the browser that resides and establish a two-way SSL connection.
7. from a security perspective, using a certificate certified by verisign or other trusted CA authorities is not good, but this can improve the customer's trust in the company, enables the company to clearly confirm its identity to the customer. From the implementation perspective, if a self-Signed CA is used, the company's internal CA only signs the customer certificate, if you use a certificate signed by verisign, the company will be a second-level CA, that is, the trust of the certificate requires a certificate chain, also by the company's second-level CA to issue the customer certificate.
8. Steps for investigation and implementation,
Because there is no formal certificate and key, a self-signed certificate is used in the test process, and the complete CA foundation is not used. The CRL problem is not considered, that is, the certificate cancellation problem.