数字证书与认证基本概念

1.X509Certificate 

X509Certificate refers to a digital certificate that adheres to the International Telecommunication Union's X.509 standard. It is a widely accepted format for public key certificates used to verify the identity of entities involved in secure electronic transactions, such as websites, individuals, or software. These certificates play a crucial role in securing online communications, particularly in SSL/TLS protocols for HTTPS, email encryption, and other forms of secure data transfer.

Key components of an X.509 certificate typically include:

1. Version: Specifies the version of the X.509 standard the certificate adheres to.
2. Serial Number: A unique identifier assigned by the certificate authority (CA) to distinguish the certificate from others it has issued.
3. Issuer: The name of the entity that signed and issued the certificate, usually a trusted certificate authority.
4. Validity Period: The date range during which the certificate is valid, including the start (Not Before) and end (Not After) dates.
5. Subject: Identifies the entity the certificate belongs to, such as a server, organization, or individual.
6. Public Key: The public key portion of the certificate owner's key pair, used for encryption or verifying digital signatures.
7. Signature Algorithm: Specifies the algorithm used by the CA to sign the certificate.
8. Signature: A digital signature created by the issuing CA using its private key, which can be verified using the CA's public key, ensuring the integrity of the certificate.

X.509 certificates are utilized in various ways, including but not limited to:

• Authenticating servers in HTTPS connections.
• Encrypting and decrypting email messages using S/MIME.
• Providing client authentication in mutual TLS scenarios.
• Code signing to verify software integrity and origin.

In programming contexts, such as those involving Java, .NET, or OpenSSL libraries, developers often work with X.509Certificate objects to manage and validate these certificates programmatically.

 

2.SSL interactive flow

The SSL (Secure Sockets Layer) / TLS (Transport Layer Security) interactive flow describes the process by which a secure connection is established between a client (such as a web browser) and a server (like a web server). Although SSL has been deprecated and replaced by TLS, the term SSL is still commonly used. Here is a simplified step-by-step overview of the SSL/TLS handshake process:

1. Client Hello:

   • The client initiates the connection by sending a "Client Hello" message to the server.
   • This message includes the SSL/TLS version the client supports, a random number (ClientRandom), a list of supported cipher suites (encryption methods), and compression methods.

2. Server Hello:

   • The server responds with a "Server Hello" message, selecting the highest SSL/TLS version both support, a random number (ServerRandom), and choosing a cipher suite from the ones offered by the client.
   • The server also sends its digital certificate, containing its public key, which the client will use to verify the server's identity and establish a secure connection.

3. Certificate Verification and Trust:

   • The client verifies the server's certificate by checking if it's signed by a trusted Certificate Authority (CA).
   • If the certificate chain cannot be validated or is self-signed without prior trust setup, the client may display a warning or terminate the connection.

4. Key Exchange (optional):

   • Depending on the chosen cipher suite, a key exchange might occur here. In older SSL/TLS versions or certain cipher suites, the client generates a Premaster Secret and encrypts it with the server's public key before sending it to the server.
   • In TLS 1.3 and some earlier configurations, the key exchange is integrated into the subsequent steps using Diffie-Hellman or Elliptic Curve Diffie-Hellman (ECDHE).

5. Cipher Suite Setup:

   • Both parties use the ClientRandom, ServerRandom, and any exchanged secrets to derive the session keys (symmetric keys for encryption and decryption, and MAC keys for data integrity).

6. Change Cipher Spec:

   • The client sends a "Change Cipher Spec" message to inform the server that all further communication will be encrypted using the newly derived keys.

7. Finished:

   • The client sends a "Finished" message, which is the first message encrypted with the session key. This message includes a hash of all previous handshake messages to verify that the key exchange and cipher setup were successful.

8. Server's Change Cipher Spec and Finished:

   • The server also sends its "Change Cipher Spec" and "Finished" messages, confirming its side of the handshake is complete and all further communication will be encrypted.

After this exchange, the SSL/TLS secure channel is established, and both parties can securely send and receive encrypted application data.

This process ensures confidentiality, authenticity, and integrity of the communication, protecting against eavesdropping, tampering, and man-in-the-middle attacks.

 

3.EVP_PKEY

EVP_PKEY in OpenSSL is an abbreviation for Enhanced (or Encryption and Verification Package) Public Key. It is a versatile and abstract data structure that represents a public key, a private key, or a key pair (public and private keys together) in a way that is agnostic to the underlying cryptographic algorithm. This means that whether you are working with RSA, DSA, elliptic curve (EC), or other cryptographic algorithms, the EVP_PKEY interface provides a consistent way to handle these keys.

Key features and uses of EVP_PKEY include:

• Algorithm Independence: You can use the same functions to perform operations (like encryption, decryption, signing, verification) with keys of different types without having to worry about the specific algorithm.

• Key Management: It simplifies the management of keys, allowing you to load, save, generate, and manipulate keys in a standardized manner.

• Cryptographic Operations: It serves as a parameter for functions performing cryptographic tasks like encryption (EVP_EncryptInit_ex), decryption (EVP_DecryptInit_ex), signing (EVP_SignInit), and verification (EVP_VerifyInit), enabling these operations with any supported algorithm.

• Key Agnosticism: An EVP_PKEY object can encapsulate any kind of key supported by OpenSSL, promoting flexibility and interoperability in cryptographic applications.

• Reference Counting: As mentioned earlier, EVP_PKEY supports reference counting through functions like EVP_PKEY_up_ref and EVP_PKEY_free, which help manage the lifecycle of the key objects efficiently, especially in multi-threaded or shared contexts.

In summary, EVP_PKEY is a fundamental building block in OpenSSL's cryptographic framework, designed to provide a high-level, unified, and flexible interface for working with cryptographic keys. 

 

4.EVP_PKEY_up_ref

`EVP_PKEY_up_ref` is a function in the OpenSSL library that increments the reference count of an `EVP_PKEY` object. The `EVP_PKEY` structure is a fundamental part of OpenSSL and is used to represent public keys, private keys, or a combination of both in a key pair.

When you call `EVP_PKEY_up_ref`, it signifies that another part of your code or another component is taking ownership or using the `EVP_PKEY` object. This is important for managing the lifetime of the key, ensuring it stays in memory as long as it is needed.

Here's a simple usage scenario:

 

EVP_PKEY *key = ...; // Assume 'key' is initialized and points to an EVP_PKEY object.

// Before calling up_ref:
// Assume the current reference count of 'key' is 1.

EVP_PKEY_up_ref(key);

// After calling up_ref:
// The reference count of 'key' is incremented by 1, indicating another reference to it.

 

This mechanism is particularly crucial in multi-threaded environments or when keys are shared across different parts of an application. By tracking the reference count, OpenSSL can determine when it is safe to free the `EVP_PKEY` object's resources with `EVP_PKEY_free`. When the reference count reaches zero after calls to `EVP_PKEY_free`, the memory associated with the key is deallocated.

Proper use of `EVP_PKEY_up_ref` and `EVP_PKEY_free` ensures that keys are managed effectively, preventing memory leaks and premature deallocation of keys still in use.

 

5.EVP_PKEY_free

`EVP_PKEY_free` is a function in the OpenSSL library used to release and free an `EVP_PKEY` structure, which represents a public key, private key, or a key pair. This function is vital for proper memory management within your application to prevent memory leaks when you are finished with using an `EVP_PKEY` object.

When you call `EVP_PKEY_free`, it decreases the reference count of the `EVP_PKEY` object. If the reference count drops to zero, OpenSSL deallocates the memory associated with the key and performs any necessary cleanup.

Here's a typical usage pattern:

 

#include <openssl/evp.h>

// Assume pkey is an EVP_PKEY pointer obtained through some means, e.g., key generation, loading from a file, etc.
EVP_PKEY *pkey = ...;

// Perform operations using pkey...

// When you're done with the key:
EVP_PKEY_free(pkey);
// This should be called when you no longer need the key. It ensures that the resources are freed and prevents memory leaks.

 

It's crucial to match every call to functions that increment the reference count of an `EVP_PKEY` (like `EVP_PKEY_up_ref`) with corresponding calls to `EVP_PKEY_free` to maintain proper reference counting and resource management. Failure to do so can lead to memory leaks or premature freeing of keys that are still in use elsewhere in your program.