Certificate related knowledge

Source: Internet
Author: User
Tags rfc xslt
Public key encryption

This topic describes the public key encryption elements related to clear email security at a higher level. In addition, you can refer to other materials to learn more about the topic.

Cryptography is a discipline that studies how to protect information by using code and password. Cryptography forms the basic part of mail security.

Simply put, encoding is a process of systematically changing information so that it is not readable (and does not know how the information is changed. One of the earliest and simplest codes, known as the Caesar password, is generated by using the alphabet and moving all letters to a fixed number of digits. Both the sender and recipient should know how many letters are moved and therefore be able to use this code to change the information so that everyone of them can read the information, but no one else can understand the information. The process of changing information to code is called encryption, while the process of changing code to information is called decryption. The original email is called "plain text ". The changed email is called "password ". The information used to change plain text to a password is called the "key ". The specific method used to change key information is called "algorithm ".

Note:
The plain text (or plain text) in this context should not be confused with the plain text mentioned when talking about the email format. In the next context, plain text is used to distinguish the HTML format or RTF format of the email. In the context of discussion about mail security, plain text is used to distinguish passwords to indicate that the text is not encrypted.

For example, if the sender wants to use this method to encrypt the mail, the sender needs to know that every instance of the letter A in plain text will be changed to the letter D in the password by the key; each instance of letter B in plain text will be changed to the letter E in the password, and so on. With this key (using the "Forward letters to three places" algorithm), the word "help" in plain text is encrypted into a "khos" password.

When receiving a password email, the recipient needs to re-convert it to plain text by using the key to decrypt the information. In this example, the letter is removed three times after it is removed to cancel the change.

In this example, the sender and recipient must store the key in secret, because anyone who knows the key can use it to decrypt and read the email. The loss of keys makes encryption worthless. In addition, the intensity of algorithms is also important. An unauthorized party can obtain the encrypted password and use the password to determine the key to crack the encryption.

Note that the sender and recipient use the same key. This type of encryption is called symmetric key encryption because both parties use the same key.

Although this is just a simple example, it illustrates the core concepts and functions of cryptography. The latest advances and improvements in cryptography are gradually produced.

How public key encryption works

In 1976, Whitfield diffe and Martin Hellman created public key encryption. Public key encryption is a major innovation because it fundamentally changes the encryption and decryption processes.

Diffe and Hellman propose two keys instead of one shared key. A private key is kept confidential. It can only be saved by one party, but not shared by all parties. The second key (called the "Public Key") is not confidential and can be widely shared. These two keys are used together in encryption and decryption operations. The key pair has a special complementary relationship, so that each key can only be used with another key in the key pair. This relationship uniquely associates the keys in the key pair with each other: the public key and its corresponding private key form a pair and are not associated with any other key.

Because of the special mathematical relationship between the public key and the private key algorithm, this pairing is possible. Key pairs are related to each other in mathematics. For example, using a key pair can achieve two symmetric keys. Key must be used in combination: each individual key cannot be used to cancel its own operations. This means that each individual key operation is a one-way operation: one key cannot be used to cancel its operation. In addition, when designing an algorithm for using two keys, It is specially designed that one key cannot be used to determine the other key in the key pair. Therefore, the private key cannot be determined based on the public key. However, making the key pair a possible mathematical principle also makes the key pair have a disadvantage that the symmetric key does not have. This means that the algorithm used must be powerful enough to prevent people from trying to use the known public key to decrypt the Information encrypted through it. The public key uses mathematical complexity and Its unidirectional characteristics to make up for the fact that it is well known to prevent people from successfully cracking the information encoded using it.

If this concept is applied to the previous example, the sender encrypts plain text into a password using the public key. Then, the recipient uses the private key to re-decrypt the password into plain text.

Because of the special relationship between the private key and the Public Key in the key pair, a person can use the same key pair when interacting with many people without having to use different keys for each other. As long as the private key is kept confidential, the public key can be freely distributed and used with peace of mind. Making many people use the same key pair represents a major breakthrough in cryptography because it significantly reduces the demand for key management and greatly improves the availability of cryptography. You can share a key pair with any number of people without having to create a separate key for each person.

Use public key encryption to secure emails

Public key encryption is a basic element in mail security. If there is no public key encryption, it is doubtful whether there is a practical mail security solution, because before the emergence of public key encryption, key management is a very troublesome thing. After learning about the basic concepts of public key encryption, the next step is to learn how to use these concepts to achieve mail security.

Public key encryption and digital signature

As discussed in the previous section, the core of digital signature is to uniquely identify the sender of a message. The complementary nature of key pair relationships makes it possible to implement this unique identifier through public key encryption.

Because the private key in the key pair only belongs to one party, as long as the private key is displayed at any time, it can be determined that the key used is its owner. In this way, the use of the private key is similar to a written signature, because only the signature owner can actually perform the signature. The signature represents its owner, just as the private key represents its owner.

If a key pair is successfully used in the encryption and decryption operations, the private key in the key pair must be used in a part of the operation. Since the public key is only associated with a private key, you can use the corresponding public key to identify the unique private key associated with it. If a specific public key is successfully used in the encryption and decryption operations, it can be inferred that the corresponding private key is used in a part of the operation. Because only the key owner can use the private key, this means that only the key owner can perform specific encryption and decryption operations.

Using the private key to determine the identity indicates that the entire encryption and decryption operation has been completed successfully. The complete operation means that you must use the private key to encrypt plain text into a password, and then use the corresponding public key to re-decrypt the password into plain text. If this operation is successfully completed, the private key is used and only the private key is used.

If encryption and decryption are successfully performed, the plain text before encryption and decryption must match the plain text after encryption and decryption. The two groups of plain text must be compared directly, and the two must match completely. A control must exist for comparison and verification.

In email, this control is the actual email. Because the mail can be used by both the sender and recipient, it is a convenient control element.

To use emails in this comparison, you need to "hash" the emails and convert all the text into numbers. Identical mail text will generate identical hash values.

By obtaining the mail hash value at the time of sending and combining it with the private key, the owner of the private key can prove that the mail was sent by him or her.

The combination of the email and the private key is completed by encrypting the hash value (creating the actual digital signature) with the sender's private key. According to the sender's email system configuration, the digital signature will be appended to the bottom of the mail (create a "plaintext signature" mail ), or combine it with the original email into a binary attachment (create an "Opaque signature" email ).

Because the digital signature of a plaintext signature email is added to the original email as an attachment, the e-mail client of S/MIME is not supported to read such emails. The non-S/MIME client discards the signature and displays the original message. However, the email cannot be verified; it is essentially the same as the unsigned email. The disadvantage of a plaintext signature email is that it is more and more likely to interfere with the email gateway to change the email so that the signature is invalid.

On the contrary, in an opaque signature email, because the email and digital signature are considered as a binary attachment, it is unlikely to be changed during the transfer process. However, only the S/MIME client can read the attachment. If the non-S/MIME client receives an opaque signature email, the email is unreadable.

To some extent, an opaque signature email is created to solve the following email system problems: that is, the body of the email changes during the email delivery process. It should be noted that the current email solution complying with the S/MIME standard will not change the mail body. However, many clients cannot read emails with opaque signatures. Therefore, we recommend that you send an email signed in plaintext.

When receiving an email, you can retrieve the digital signature and apply the sender's public key in the decryption operation to generate the original hash value of the email. Then, you can compare the hash value with the hash value of the received mail. Because only one private key can correspond to the public key, and only the owner of the public key can use it to successfully encrypt the hash value, therefore, using the public key to decrypt the hash value means that the owner of the private key encrypts the hash value. Because the hash value is a digital representation of the mail text, if the encrypted hash value matches the hash value of the received mail, it means that the sent mail text matches the received text. Considering that only the private key owner can send the email, the result is that the recipient is sure that only the key owner has sent the email, providing authentication and therefore providing the approval function. It also shows that the email has not been changed, providing data integrity. If the hash value does not match, the recipient knows that the email is changed during transmission, or the public key used does not match the private key used. In both cases, the recipient knows that the email is invalid and should not be trusted.

Therefore, we can see the ways in which public key encryption provides a digital signature security service.

Shows the order of signing when public key encryption supports elements.


Public key encryption and digital signature of emails


  1. Capture emails.
  2. Calculate the mail hash value.
  3. Retrieve the sender's private key.
  4. Use the sender's private key to encrypt the hash value.
  5. Add the encrypted hash value to the email as a digital signature.
  6. Send an email.

Displays the order of verification when public key encryption supports elements.


Public key encryption and digital signature verification for emails


  1. Receive emails.
  2. Retrieve the digital signature that contains the encrypted hash value from the email.
  3. Retrieve emails.
  4. Calculate the mail hash value.
  5. Retrieves the sender's public key.
  6. Use the sender's public key to decrypt the encrypted hash value.
  7. Compare the decrypted hash value with the hash value generated when receiving the email.
  8. If the value matches, the email is valid.

This sequence operation shows how public key encryption provides the necessary functions to enable digital signatures to provide their core security services: identity authentication, authentication, and data integrity.

Public key encryption and email encryption

Unlike digital signatures, the relationship between public key encryption and email encryption is generally simpler, because encryption is the core function of public key encryption. However, email encryption is completed not only by using key pairs to encrypt and decrypt emails. The key pair is used for email encryption, not for the entire email.

Because the purpose of mail encryption is to ensure that only authorized recipients can view the mail, the private key of each recipient is suitable for providing this service. Since only the private key owner can successfully use the private key, using the key during email reading ensures that only the owner of the key can read the email. This feature provides confidentiality as the basis for email encryption. In addition, since public keys can be widely distributed, it allows any number of people to send messages to a private key holder.

However, the key pair is not used in the entire email. This is because, due to the complexity required by the key algorithm, it is expensive to use the key pair for encryption and decryption. Although you need to use a key pair, it is not necessary to use it in the entire email. It needs to be part of the "locked" and "Unlocked" information process. As long as the email cannot be read before the private key is provided, the email can be encrypted.

As mentioned earlier in this topic "how public key encryption works", the public key uses a strong algorithm to make up for this feature. These strong algorithms mean they are larger than the original symmetric keys, so they are used more slowly for computation. Because the private key is only used to unlock information before viewing information, rather than in the entire email, make sure that information is unavailable before providing the private key, using key pairs with as few information as possible, while using Symmetric keys with as much faster as possible is more economical.

A symmetric key uses a key that both parties must know. This process is sometimes called "key negotiation ". If a key pair is used, there is no key negotiation process because a public key can be used by many people. Key pairs can also be used with symmetric keys for key negotiation. You can select a symmetric key and use the public key of the key pair to encrypt the key and send it to the owner of the private key. When sent to multiple recipients, you can use the symmetric key for all recipients, and then encrypt the symmetric key using the public key of each specific recipient. Since only the private key owner can decrypt the symmetric key, the symmetric key remains confidential for unauthorized users. You can generate symmetric keys for one-time use during a specific operation or session. This symmetric key is called a session key ". Public key encryption can enhance the effect of symmetric key encryption, rather than replacing it.

The purpose of email encryption is to ensure that the email is not readable before the private key is presented. You can use a private key in symmetric key negotiation to securely transmit symmetric keys. Since the symmetric key can be securely transmitted to the recipient, you can use the symmetric key to encrypt the email and then use the public key in the key pair to encrypt the symmetric key. Only the private key holder can unlock the symmetric key and then use the unlocked symmetric key to decrypt the email. This operation serves to encrypt and decrypt the entire email using the key. However, because it uses a faster symmetric key for most information, this operation is faster than other operation methods. In this process, the email is always protected before the private key is presented, thus providing confidentiality. This is the basic service of email encryption. Because of the encryption and decryption process, changing the email after encryption will cause decryption to fail, thus providing data integrity.

Although people generally cannot think of using Symmetric keys and their advantages are not immediately displayed, they can increase the speed of email encryption without compromising the security of emails, this enhances mail security. Displays the encryption order with the support elements of public key encryption.


Public key encryption and email encryption


  1. Capture emails.
  2. Retrieve the recipient's public key.
  3. Generates a one-time symmetric session key.
  4. Use the session key to encrypt the email.
  5. Use the public key of the recipient to encrypt the session key.
  6. The encrypted session key is included in the encrypted email.
  7. Send an email.

Display the decryption order when public key encryption supports elements.


Public key encryption and email decryption


  1. Receive emails.
  2. Retrieve encrypted emails and encrypted session keys from emails.
  3. Retrieve the private key of the recipient.
  4. Use the recipient's private key to decrypt the session key.
  5. Use the decrypted session key to decrypt the email.
  6. Return unencrypted emails to recipients.

These activities show how public key encryption supports the following core services of email encryption: confidentiality and data integrity.

Learn how to use public key encryption for both digital signature and email encryption

Digital signatures and email encryption are well-received services. It is helpful to consider how to use public key encryption for each service separately.

Shows the order of signature and encryption when public key encryption supports elements.


Public key encryption and digital signature and encryption for emails


  1. Capture emails.
  2. Calculate the mail hash value.
  3. Retrieve the sender's private key.
  4. Retrieve the recipient's public key.
  5. Use the sender's private key to encrypt the hash value.
  6. Add the encrypted hash value to the email as a digital signature.
  7. Generates a one-time symmetric session key.
  8. Use the session key to encrypt the email.
  9. Use the public key of the recipient to encrypt the session key.
  10. The encrypted session key is included in the encrypted email.
  11. Send an email.

Displays the order in which digital signatures are decrypted and verified when public key encryption is added.


Public key encryption and email decryption and Digital Signature Verification


  1. Receive emails.
  2. Retrieve encrypted emails and encrypted session keys from emails.
  3. Retrieve the private key of the recipient.
  4. Use the recipient's private key to decrypt the session key.
  5. Use the decrypted session key to decrypt the email.
  6. Retrieve the digital signature that contains the encrypted hash value from the email.
  7. Calculate the mail hash value.
  8. Retrieves the sender's public key.
  9. Use the sender's public key to decrypt the encrypted hash value.
  10. Compare the decrypted hash value with the hash value generated when receiving the email.
  11. If the value matches, the email is valid.
  12. Return unencrypted emails to recipients.

These activities show how public key encryption makes digital signatures and email encryption possible.

Note how the two parties need the public key or private key of the other party based on specific operations. For example, a sender must use his or her private key to digitally sign an email, but must use the recipient's public key to send an encrypted email. This process can be confusing. Therefore, a chart is displayed, indicating which party needs the key during the specific operation.


Key requirements based on roles and operations


The next element to be aware of is the digital certificate. Digital Certificates make digital signatures and encryption possible by distributing key pairs.

 

Learn about digital certificates

Although public key encryption simplifies key management by allowing many people to use one key, there is a problem: how to distribute the public key so that users can find it and know it is valid.

In S/MIME, the solution to this problem is to use digital certificates. Digital Certificates are different from many other competing email security solutions.

Understanding about digital certificates and public key encryption

A digital certificate is a digital identity, similar to a passport or driver's license. A digital certificate is a digital credential that provides information about the entity identity and other support information. A digital certificate is issued by an authority called a Certificate Authority (CA. Since digital certificates are issued by the Certificate Authority, the Authority warrants the validity of the certificate information. In addition, the digital certificate is valid only for a specific period of time.

The Digital Certificate supports public key encryption because the digital certificate contains the public key of the entity identified in the certificate. Because the certificate matches the public key with a specific individual and the authenticity of the certificate is guaranteed by the issuing authority, the digital certificate provides a solution to the problem of finding the user's public key and knowing whether it is valid. These problems are solved by obtaining the public key of another user from the digital certificate. This user knows that it is valid because the certificate is issued by a trusted Certificate Authority.

In addition, digital certificates rely on public key encryption to prove their identity. When a digital certificate is issued, the Certificate Authority uses its own private key to sign the certificate. To verify the authenticity of a digital certificate, you can obtain the public key of the Certificate Authority and use the public key of the certificate to determine whether it is signed by the certificate authority.

Understanding the structure of digital certificates

To make a digital certificate useful, its structure must be in an understandable and reliable form so that people can easily retrieve and understand information in the certificate. For example, passports adopt a structure where people can easily understand the information in a type of passport they have never seen before. Similarly, as long as the digital certificate is standardized, people can read and understand the certificate regardless of the Organization that issues the certificate.

S/MIME standard: digital certificates used for S/MIME shall comply with the International Telecommunication Union (ITU) X.509 standard. S/MIME Version 3 explicitly requires that the digital certificate must comply with version 3rd of X.509. Because S/MIME relies on established digital certificate structure recognition standards, S/MIME standards are built on the development of this standard, thus improving its acceptance.

The X.509 standard specifies that digital certificates should contain standardized information. Specifically, the X.509 Version 3 certificate contains the following fields:

  • Version NumberThe X.509 standard version that the certificate complies.
  • Serial numberThe ID that uniquely identifies the certificate and is issued by the certificate authority.
  • Certificate Algorithm IDThe name of a specific public key algorithm used by the certificate authority to sign a digital certificate.
  • Issuer nameThe identifier of the Certificate Authority that actually issues the certificate.
  • Validity PeriodThe period in which the digital certificate remains valid, including the start date and expiration date.
  • User NameThe name of the digital certificate owner.
  • User Public Key InformationThe public key associated with the digital certificate owner and the specific public key algorithm associated with the public key.
  • Unique Identifier of the issuerIt can be used to uniquely identify the information of the digital certificate issuer.
  • Unique User IdentifierThe information that uniquely identifies the digital certificate owner.
  • Extended informationOther information related to the use and processing of certificates.
  • Digital signature of the Certificate AuthorityUse the algorithm specified in the certificate algorithm Identifier Field and the private key of the Certificate Authority for actual digital signature.

Because S/MIME requires an X.509 V3 certificate, this information also describes the features S/MIME uses for its specific certificate.

Important information:
X.509 V3 is the standard for digital certificates. It does not provide standards for certificates specific to S/MIME. Information about the S/MIME-specific digital certificate is described in the S/mime rfc.

Although digital certificates are electronic, remember that since digital certificates are standardized, they can be used on a large number of devices, not just personal computers. Digital certificates can be used on handheld devices, mobile phones, and portable cards (called smart cards. Smart cards can be used on different devices and are suitable for digital certificates in some aspects. A smart card makes digital certificates portable and easy to use like a traditional driver's license or passport.

For S/MIME success, standardization of S/MIME certificates based on S/mime rfc and X.509 Version 3 is a key element, this allows any application that complies with this standard to understand digital certificates.

Digital Certificate and public key infrastructure

One of the advantages of public key encryption is that a key pair replaces a large number of symmetric keys, thus reducing the workload of key management. Digital Certificates further enhance this advantage, which solves the issue of public key distribution and management. However, digital certificates cannot be managed by themselves. Due to the inherent widespread distribution of digital certificates, the distribution of digital certificates must be taken into account when designing management schemes for these certificates. A valid infrastructure is required for digital certificates to manage certificates in the use environment of certificates. Public Key Infrastructure (PKI) is inseparable from digital certificates. PKI is responsible for issuing certificates, which ensure distribution of these certificates through directories and verify certificates. PKI is responsible for basic work, including supporting digital certificates and enabling them to provide functions that services such as S/MIME depend on.

Due to the large scale and complexity of PKI, it is beyond the scope described in this book. The information provided here focuses on how PKI and digital signature work together to achieve mail security. There are many excellent resources to describe PKI. You can obtain detailed information about PKI from PKI vendor documents and other information sources specifically related to PKI.

How to Implement Email Security using PKI

PKI issues a certificate and enables access to the certificate through a directory to enable digital certificates. PKI also verifies the digital certificate by verifying the authenticity of the certificate, the validity of the certificate, and thus verifying the credibility of the certificate. These services are critical to digital certificates because they rely on distributed models by using third-party Certificate Authorities.

The specific method of issuing a digital certificate and publishing it to the directory depends on the specific PKI product and its implementation method. In general, PKI issues digital certificates and publishes information about these certificates to the directory so that other applications can access this information from the directory. Some of the information is used to verify the digital certificate. As discussed in "using public key encryption for mail security" in public key encryption, mail security operations need to access the public keys of both the sender and recipient. As the digital certificate provides this information, access to the user's digital certificate is critical to the mail security system. By providing the accessibility of digital certificates, PKI utilizes the advantages of public key encryption in simplifying Key Management (without manual key exchange. PKI makes digital certificates available through directories so that applications can retrieve digital certificates as needed.

To learn how PKI verifies certificates, remember the role of the Certificate Authority in issuing digital certificates. As discussed in "Understanding digital certificates and public key encryption" above this topic, the Certificate Authority guarantees the validity of the identity and uses its public key to sign the digital certificate. Checking the authenticity of the certificate means that the digital signature of the Certificate Authority must be verified. PKI provides a means to verify the Certificate Authority's signature. If the signature cannot be verified, the certificate may be considered untrusted.

Any security method is not perfect as described at the beginning of this topic. The security of the digital certificate may be compromised, which usually occurs when the private key is lost. To make a digital certificate credible, there must be a way to cancel or "revoke" a digital certificate before it expires, as if to cancel a stolen credit card. Certificate Revocation is another key service used by PKI to support digital certificates. It is also another part of the digital certificate verification process.

Since PKI ensures that digital certificates are trusted, PKI is an indispensable part of digital certificates. Without PKI, you cannot use a digital certificate. Because Exchange Server 2003 supports X.509 V3 certificates, the installation of PKI support for exchange depends on the digital certificate used by exchange. However, from the perspective of mail security, all PKI provides these basic services to support digital certificates. The differences between specific PKI are related to implementation and design, and are related to the specific situation of each PKI deployment.

Use digital certificates for mail security

After learning about the digital certificate and how it supports public key encryption, the next step is to apply this information to the mail security field. The next section describes how digital certificates support core security services, including digital signatures and email encryption.

How to use a digital certificate for Digital Signature

As discussed in "public key encryption and digital signature" in public key encryption, the relationship between the public key and the user's private key enables the recipient to identify and verify the sender's mail. Digital Certificates support public key encryption by providing reliable public key distribution and access methods. When the sender signs the email, the private key associated with the public key available on the digital certificate is provided. In turn, when the recipient verifies the digital signature on the email, the Public Key is obtained from the sender's digital certificate for verification. Shows the order in which the digital certificate is signed when the supporting elements are added.


Digital Certificate and email Digital Signature


  1. Capture emails.
  2. Calculate the mail hash value.
  3. Retrieve the sender's private key from the sender's digital certificate.
  4. Use the sender's private key to encrypt the hash value.
  5. Add the encrypted hash value to the email as a digital signature.
  6. Send an email.

Displays the order of verification when a digital certificate support element is added.


Digital Certificate and digital signature for email Verification


  1. Receive emails.
  2. Retrieve the digital signature that contains the encrypted hash value from the email.
  3. Retrieve emails.
  4. Calculate the mail hash value.
  5. Retrieve the sender's public key from the sender's digital certificate.
  6. Use the sender's public key to decrypt the encrypted hash value.
  7. Compare the decrypted hash value with the hash value generated when receiving the email.
  8. If the value matches, the email is valid.

These operations show that the digital certificate can allow the verification process to access the public key to verify the digital signature.

How to use a digital certificate for email encryption

Just as a digital certificate allows a public key to be used for verification to support digital signatures, a digital certificate also enables the public key to be used for encryption to support mail encryption. As discussed in "public key encryption and email encryption" in public key encryption, the sender can access the recipient's public key, which enables the sender to encrypt the email and ensure that only the recipient can decrypt the email. This time, the encrypted certificate may be the recipient's digital certificate. Like a digital signature, the Public Key in the digital certificate makes this operation possible. Shows the order of encryption with the support elements of the digital certificate.


Digital Certificate and email encryption


  1. Capture emails.
  2. Retrieve the public key from the recipient's digital certificate.
  3. Generates a one-time symmetric session key.
  4. Use the session key to encrypt the email.
  5. Use the public key of the recipient to encrypt the session key.
  6. Include the encrypted session key in the encrypted email.
  7. Send an email.

The order in which the decryption is performed when the supporting elements of the digital certificate are added.


Decryption of digital certificates and emails


  1. Receive emails.
  2. Retrieve encrypted emails and encrypted session keys from emails.
  3. Retrieve the recipient's private key from the recipient's digital certificate.
  4. Use the recipient's private key in the recipient's digital certificate to decrypt the session key.
  5. Use the decrypted session key to decrypt the email.
  6. Return unencrypted emails to recipients.
How to use a digital certificate for digital signature and email encryption

Digital signatures and email encryption complement each other. Shows the order in which digital signatures are signed and encrypted when the supported elements are added.


Digital Certificates and digital signature and encryption of emails


  1. Capture emails.
  2. Calculate the mail hash value.
  3. Retrieve the sender's private key from the sender's digital certificate.
  4. Retrieve the recipient's public key from the recipient's digital certificate.
  5. Use the sender's private key to encrypt the hash value.
  6. Add the encrypted hash value to the email as a digital signature.
  7. Generates a one-time symmetric session key.
  8. Use the session key to encrypt the email.
  9. Use the public key of the recipient to encrypt the session key.
  10. Include the encrypted session key in the encrypted email.
  11. Send an email.

Displays the order in which digital signatures are decrypted and verified when public key encryption is added.


Digital Certificate, email decryption, and digital signature verification


  1. Receive emails.
  2. Retrieve encrypted emails and encrypted session keys from emails.
  3. Retrieve the recipient's private key from the recipient's digital certificate.
  4. Use the recipient's private key in the recipient's digital certificate to decrypt the session key.
  5. Use the decrypted session key to decrypt the email.
  6. Retrieve the digital signature that contains the encrypted hash value from the email.
  7. Calculate the mail hash value.
  8. Retrieve the sender's public key from the sender's digital certificate.
  9. Use the sender's public key to decrypt the encrypted hash value.
  10. Compare the decrypted hash value with the hash value generated when receiving the email.
  11. If the value matches, the email is valid.
  12. Return unencrypted emails to recipients.

By understanding how digital certificates implement public key encryption and how public key encryption provides basic security services for digital signatures and email encryption, you have learned how S/MIME mail security works. These concepts constitute the core of mail security.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.