No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Fat AP and Cloud AP V200R008C00 CLI-based Configuration Guide

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Understanding PKI

Understanding PKI

Basic Concepts of PKI

The core of PKI is digital certificate lifecycle management, including applying for, issuing, and using the digital certificates. During the lifecycle, PKI uses the symmetric key cryptographic, public key cryptographic, digital envelope, and digital signature. Figure 26-18 shows the evolution of these technologies. Users A and B communicate through the Internet, and user C is the attacker who targets the communication data between users A and B.

Figure 26-18  Technology evolution

The concepts mentioned in the figure will be described in later sections.

Cryptography

Cryptography is the basis for secure information transmission on networks. Cryptography is to convert plaintext (to be hidden) into ciphertext (unreadable data) using mathematics.

Symmetric Key Cryptography

Symmetric key cryptography, which is also called shared key cryptography, uses the same key to encrypt and decrypt data.

Figure 26-19 shows the symmetric key encryption and decryption process.

Figure 26-19  Symmetric key encryption and decryption process

Users A and B have negotiated the symmetric key. The encryption and decryption process is as follows:
  1. User A uses the symmetric key to encrypt data and sends the encrypted data to user B.

  2. User B decrypts the data using the symmetric key and gets the original data.

Symmetric key cryptography features high efficiency, simple algorithm, and low cost. It is suitable for encrypting a large amount of data. However, it is difficult to implement because the two parties must exchange their keys securely before communication. Besides, it is difficult to expand because each pair of communicating parties needs to negotiate keys, and n users needs to negotiate n*(n-1)/2 different keys.

The algorithms commonly used in symmetric key cryptography include Data Encryption Standard (DES), Triple Data Encryption Standard (3DES), and Advance Encrypt Standard (AES).

Public Key Cryptography

Public key cryptography, which is also called asymmetric key cryptography, uses different keys (public and private) for data encryption and decryption. The public key is open to public, and the private key is possessed by only the owner.

Public key cryptography prevents the security risks in the distribution and management of a symmetric key. In an asymmetric key pair, the public key is used to encrypt data and the private key is used to decrypt data. The two parties do not need to exchange keys before a secure communication session. The sender uses the public key of the receiver to encrypt the data, and the receiver uses its own private key to decrypt data. The receiver's private key is only known by the receiver, so the data is secure.

Figure 26-20 shows the public key encryption and decryption process.

Figure 26-20  Public key encryption and decryption process

Assume that user A has the public key of user B. The encryption and decryption process is as follows:
  1. User A uses the public key of user B to encrypt data and sends the encrypted data to user B.

  2. User B decrypts the data using its own private key and gets the original data.

Attackers cannot use one key in a key pair to figure out the other key. The data encrypted by a public key can only be decrypted by the private key of the same user. However, the public key cryptography requires a long time to encrypt a large amount of data, and the encrypted data is too long, consuming much bandwidth.

Public key cryptography is suitable for encrypting sensitive information such as keys and identities to provide higher security.

The algorithms commonly used in public key cryptography include Diffie-Hellman (DH), Ron Rivest, Adi Shamirh, LenAdleman (RSA), and Digital Signature Algorithm (DSA).

Digital Envelope and Digital Signature
Digital Envelope

A digital envelope contains the symmetric key encrypted using the peer's public key. When receiving a digital envelope, the receiver uses its own private key to decrypt the digital envelope and obtains the symmetric key.

Figure 26-21 shows the encryption and decryption process for a digital envelope.

Figure 26-21  Digital envelope encryption and decryption process

Assume that user A has the public key of user B. The encryption and decryption process is as follows:

  1. User A uses a symmetric key to encrypt data.
  2. User A uses the public key of user B to encrypt the symmetric key and generate a digital envelope.
  3. User A sends the digital envelope and encrypted data to user B.
  4. User B uses its own private key to decrypt the digital envelope and obtains the symmetric key.
  5. User B uses the symmetric key to decrypt the data and obtains the original data.

The digital envelope has the advantages of both symmetric key cryptography and public key cryptography. It speeds up key distribution and encryption and improves key security, extensibility, as well as efficiency.

However, the digital envelope still has a vulnerability. The attacker may obtain information from user A, use its own symmetric key to encrypt the forged information, use the public key of user B to encrypt its own symmetric key, and send the information to user B. After receiving the information, user B decrypts it and considers that the information is sent from user A. To address this problem, the digital signature is used to ensure that the received information was sent from the correct sender.

Digital Signature

Digital signature is generated by the sender by encrypting the digital fingerprint using its own private key. The receiver uses the sender's public key to decrypt the digital signature and obtain the digital fingerprint.

A digital fingerprint, which is also called information digest, is generated by the sender using the hash algorithm on plaintext information. The sender sends both digital fingerprint and plaintext to the receiver, and the receiver uses the same hash algorithm to calculate the digital fingerprint on the plaintext. If the two fingerprints are the same, the receiver knows that the information has not been tampered with.

Figure 26-22 shows the encryption and decryption process for a digital signature.

Figure 26-22  Digital signature encryption and decryption process

Assume that user A has the public key of user B. The encryption and decryption process is as follows:

  1. User A uses the public key of user B to encrypt data.
  2. User A performs hash on the plaintext and generates a digital fingerprint.
  3. User A uses its own private key to encrypt the digital fingerprint, generating the digital signature.
  4. User A sends both the ciphertext and digital signature to user B.
  5. User B uses the public key of user A to decrypt the digital signature, obtaining the digital fingerprint.
  6. After receiving the ciphertext from user A, user B uses its own private key to decrypt the information, obtaining the plaintext information.
  7. User B performs hash on the plaintext and generates a digital fingerprint.
  8. User B compares the generated fingerprint with the received one. If the two fingerprints are the same, user B accepts the plaintext; otherwise, user B discards it.

The digital signature proves that information is not tampered with and verifies the sender's identity. The digital signature and digital envelope can be used together.

However, the digital signature still has a vulnerability. If the attacker modifies the public key of user B, then user A obtains the attacker's public key. The attacker can obtain information from user B to user A, sign the forged information using its own private key, and send the forged information encrypted using user A's public key to user A. After receiving the encrypted information, user A decrypts the information and verifies that the information has not been tampered with. In addition, user A considers that the information was sent by user B. The digital certificate can fix this vulnerability. It ensures that one public key is possessed by only one owner.

Digital Certificate

A digital certificate, or certificate, which is signed by the trusted certificate authority (CA) using digital signature, includes the certificate owner's public key and identity information.

The digital certificate is similar to the passport or identity card. People are requested to show their passports when entering foreign countries. The digital certificate shows the identity of a device or user that requests to access a network.

It ensures that one public key is possessed by only one owner.

Digital Certificate Structure

An X.509 v3 digital certificate contains mandatory information such as public key, name, and digital signature of the CA, and optional information such as validity period of the key, issuer (CA) name, and serial number. Figure 26-23 shows the typical structure of a digital certificate.

Figure 26-23  Digital certificate structure diagram

Meaning of each field in the digital certificate:

  • Version: version of X.509. Generally, the v3 (0x2) is used.
  • Serial Number: a positive and unique integer assigned by the issuer to the certificate. Each certificate is uniquely identified by the issuer name and the serial number.
  • Signature Algorithm ID: signature algorithm used by the issuer to sign the certificate.
  • Issuer: name of the device that has issued a certificate. It must be the same as the subject name in the digital certificate. Generally, the issuer name is the CA server's name.
  • Validity: time interval during which a digital certificate is valid, including the start and end dates. The expired certificates are invalid.
  • Subject: name of the entity that possesses a digital certificate. In a self-signed certificate, the issuer name is the same as the subject name.
  • Subject Public Key Info: public key and the algorithm with which the key is generated.
  • Extensions: a sequence of optional fields such as key usage and CRL distributing address.
  • Signature: signature signed on a digital certificate by the issuer using the private key.
Digital Certificate Types

There are four types of certificates, as described in Table 26-14.

Table 26-14  Certificate types
Type Definition Description

Self-signed certificate

A self-signed certificate, which is also called root certificate, is issued by an entity to itself. In this certificate, the issuer name and subject name are the same.

If an applicant fails to apply for a local certificate from the CA, it can generate a self-signed certificate. The self-signed certificate issuing process is simple.

Huawei devices do not support lifecycle management (such as certificate renewal and revocation) for self-signed certificates.

CA certificate

CA's own certificate. If a PKI system does not have a hierarchical CA structure, the CA certificate is the self-signed certificate. If a PKI system has a hierarchical CA structure, the top CA is the root CA, which owns a self-signed certificate.

An applicant trusts a CA by verifying its digital signature. Any applicant can obtain the CA's certificate (including the public key) to verify the local certificate issued by the CA.

Local certificate

A certificate issued by a CA to the applicant.

-

Local device certificate

A certificate issued by a device to itself according to the certificate issued by the CA. The issuer name in the certificate is the CA server's name.

If an applicant fails to apply for a local certificate from the CA, it can generate a local device certificate. The local device certificate issuing process is simple.

Certificate Formats

Three certificate formats are supported, as described in Table 26-15.

Table 26-15  Certificate formats
Format Description Description

PKCS#12

Saves certificate files in binary format, including or excluding the private key. The commonly used file name extensions include .P12 and .PFX.

If the file name extension of a certificate is .CER or .CRT, use the Notepad to open this certificate and check the certificate content to differentiate the certificate format.

  • If the certificate starts with "-----BEGIN CERTIFICATE-----" and ends with "-----END CERTIFICATE-----", the certificate format is PEM.
  • If the certificate content is displayed as garbled characters, the certificate format is DER.

DER

Saves certificate files in binary format, excluding the private key. The commonly used file name extensions include .DER, .CER, and .CRT.

PEM

Saves certificate files in ASCII format, including or excluding the private key. The commonly used file name extensions include .PEM, .CER, and .CRT.

PKI System Structure

As shown in Figure 26-24, a PKI system consists of the end entity, certificate authority (CA), registration authority (RA), and certificate/certificate revocation list (CRL) storage database.

Figure 26-24  PKI system structure

  • End entity

    An end entity, or PKI entity, is the end user of PKI products or services. It can be an individual, an organization, a device (for example, a router or firewall), or process running on a computer.

  • Certificate Authority (CA)

    The CA is the trusted entity that issues and manages digital certificates. The CA is an authoritative, trustable, and fair third-party organization. Generally, a CA is a server, for example, a server running Windows Server 2008.

    Figure 26-25 shows a hierarchical CA. The CA on the top of the hierarchy is the root CA and the others are subordinate CAs.

    • The root CA is the first CA (trustpoint) in the PKI system. It issues certificates to subordinate CAs, computers, users, and services. In most certificate-based applications, the root CA can be traced through the certificate chain. The root CA holds a self-signed certificate.

    • A subordinate CA can only obtain a certificate from its upper-level CA. The upper-level CA can be the root CA or another subordinate CA authorized by the root CA to issue certificates. The upper-level CA is responsible issuing and managing certificates of lower-level CAs, and the CAs at the bottom issue certificates to end entities. For example, CA 2 and CA 3 are subordinate CAs, holding the certificates issued by CA 1, and CA 4, CA 5, as well as CA 6 are also subordinate CAs, holding the certificates issued by CA 2.

    When a PKI entity trusts a CA, the trust is derived along the certificate chain. A certificate chain is a set of certificates from the end entity to the root certificate. When a PKI entity in communication receives a certificate to be authenticated, the PKI entity verifies each issuer along the certificate chain.

    Figure 26-25  Hierarchical CA diagram

    Certificate management is the major function of CAs, including issuing, renewing, revoking, querying, and archiving certificates as well as distributing the Certificate Revocation List (CRL).

  • Registration Authority (RA)

    An RA enrolls and approves digital certificates. It is a proxy for the CA and provides extended applications of certificate issuing and management. The RA processes the certification enrollment and revocation requests from users, verifies user identities, and decides whether to submit certificate issuing or revocation requests to the CA.

    The RA may be part of the CA server, or independent of CA to share workload of CA and enhance CA system security.

  • Certificate/CRL database

    A certificate may need to be revoked for the reasons such as entity name changing, private key leaking, or service interruption. Revoking a certificate is to unbind the public key from the PKI entity identity information. The PKI system uses a CRL to revoke certificates.

    After a certificate is revoked, the CA issues a CRL to declare that the certificate is invalid and lists the serial numbers of revoked certificates. The CRL provides a method to verify certificate validity.

    The certificate/CRL database stores and manages information about certificates and CRLs and allows information query. The certificate/CRL database can be built using a File Transfer Protocol (FTP) server, Hypertext Transfer Protocol (HTTP) server, or database.

PKI manages the entire lifecycle of local certificates, including application, issue, storage, download, installation, authentication, renewal, and revocation.

Certificate Application

Certificate application is certificate enrollment. It is a process in which an entity registers with a CA and obtains a certificate from the CA. Generally, a PKI entity generates a pair of public and private keys. The public key and entity's identity information (included in certificate enrollment request) are sent to the CA to generate a local certificate. The private key is stored by the PKI entity to perform digital signature and decrypt the ciphertext sent from the peer.

A PKI entity can use either of the following methods to apply for a local certificate from CA:

  • Online

    The PKI entity sends certificate enrollment requests to the CA by using the Simple Certificate Enrollment Protocol (SCEP).

  • Offline (PKCS#10)

    The PKI entity prints the local certificate enrollment request in PKCS#10 format and saves it as a file. Then the user transfers the file to the CA server in out-of-band mode (web, disk, or email).

In addition, a PKI entity can issue a self-signed or local certificate to itself.

Certificate Issue

If an RA is available, the RA verifies the PKI entity's identity information when the PKI entity applies for a local certificate from CA. After the PKI entity passes verification, the RA sends the request to CA. The CA generates a local certificate based on the public key and identity information of the PKI entity, and then returns the local certificate information to the RA. If no RA is available, the CA verifies the PKI entity.

Certificate Storage

After the CA generates a local certificate, the CA or RA distributes the certificate to the certificate/CRL database. Users can download or browse directory of the certificates in the database.

Certificate Downloading

A PKI entity can download a local certificate, a CA/RA certificate, or a local certificate of another PKI entity from the CA server using SCEP, HTTP, or out-of-band mode.

Certificate Installation

A downloaded certificate (a local certificate, CA/RA certificate, or certificate of another PKI entity) must be installed on the device, that is, imported to the device memory; otherwise, the certificate does not take effect.

Certificate Authentication

Before a PKI entity uses a certificate obtained from the peer, for example, for the purposes of setting up a security tunnel or connection, the PKI entity authenticates the certificate and CA (whether the certificate is valid and issued by the expected CA). If the certificate is invalid, the PKI considers all certificates issued by this CA invalid. This seldom occurs because a device renews the CA certificate before expiration in normal situations.

The PKI entity uses CRL or Online Certificate Status Protocol (OCSP) to authenticate certificates. In CRL mode, the PKI entity searches for the certificate in the CRL stored in local memory. If the certificate is included in the CRL, it indicates that the certificate has been revoked. If no CRL is available in local memory, a CRL needs to be downloaded and installed. In OCSP mode, the PKI entity sends a certificate status query message to the OCSP server, and the OCSP server returns the certificate state, including valid (not revoked), expired (revoked), and unknown (OCSP server cannot find the certificate status).

Certificate Renewal

When a certificate expires or the private key is leaked, the PKI entity must replace the certificate. The PKI entity can apply for a new certificate or use SCEP to renew the existing certificate.

When a certificate is about to expire, the device applies for a shadow certificate. When the certificate expires, the shadow certificate becomes active.

The shadow certificate application process is the enrollment process for the new certificate.

Certificate Revocation

When the user identity, user information, or public key is modified or user service needs to be interrupted, a certificate revocation is required. Certificate revocation unbinds a public key from the PKI entity's identity information. The CA uses CRL or OCSPto revoke certificates for PKI entities, whereas a PKI entity revokes its own certificate in out-of-band mode.

PKI Working Mechanism

On a PKI network, a PKI entity applies for a local certificate from the CA and the applicant device authenticates the certificate. Figure 26-26 shows the PKI working process.

Figure 26-26  PKI working process

  1. A PKI entity applies for a CA certificate (CA server's certificate) from the CA.

  2. When receiving the application request, the CA sends its own certificate to the PKI entity.

  3. The PKI entity installs the CA certificate.

    If the PKI entity uses SCEP for certificate application, it computes a digital fingerprint by using the hash algorithm on the received CA certificate, and compares the computed fingerprint with that pre-defined for the CA server. If the fingerprints are the same, the PKI accepts the CA certificate; otherwise, it discards the CA certificate.

  4. The PKI entity sends a certificate enrollment message (including the public key carried in the configured key pair and PKI entity information) to the CA.

    If the PKI entity uses SCEP for certificate application, it encrypts the enrollment message using the CA certificate's public key and signs the message using its own private key. If the CA server requires a challenge password, the enrollment message must contain a challenge password, which must be the same as the CA's challenge password.

  5. The CA receives the enrollment message from the PKI entity.

    If the PKI entity uses SCEP to apply for a local certificate, the CA uses its own private key to decrypt the enrollment message and the PKI entity's public key to decrypt the digital signature, and verifies the digital fingerprint. When the fingerprints are the same, the CA verifies the PKI entity's identity information. When the PKI entity's identity information passes verification, the CA accepts the application and issues a local certificate to the PKI entity. The CA uses the PKI entity's public key to encrypt the certificate and its own private key to digitally sign the certificate, and sends the certificate to the PKI entity. At the same time, the CA also sends the certificate to the certificate/CRL database.

  6. The PKI entity receives the certificate from CA.

    If the PKI entity has applied for a local certificate using SCEP, the PKI entity uses its own private key to decrypt the certificate and the CA's public key to decrypt the digital signature, and verifies the digital fingerprint. If the digital fingerprint is the same as its local one, the PKI entity accepts and installs the local certificate.

  7. The PKI entities in a communication session need to obtain and install each other's local certificates. The PKI entities can download the peer's local certificates through HTTP. In special scenarios, such as IPSec application, the PKI entities actively send their local certificates to the peer.

  8. After the peer's local certificate is installed on the local end, the local end uses CRL or OCSP to check whether the peer certificate is valid.

  9. The PKI entities use the public keys in peer certificates for secure communication only after they confirm that the peer certificates are valid.

If an RA is available in a PKI system, the PKI entities also need to download the RA's certificate. The RA verifies the local certificate enrollment messages from PKI entities, and forwards the messages to the CA after verifications are passed.

Translation
Download
Updated: 2019-01-11

Document ID: EDOC1000176006

Views: 114075

Downloads: 309

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next