Digital Signatures and Digital Certificates

digital signature

A digital signature is a means of verifying the authenticity and integrity of information. A set of digital signatures includes two operations of signature and verification. Below is a schematic diagram of a simple digital signature.

principle

Digital signatures use asymmetric encryption technology. Everyone has a pair of keys, the private key is known only to the person, the public key is public, the private key is signed, and the public key is verified.

When transmitting information, the information sender uses the private key to generate a signature and sends the public key to the information receiver, and the receiver uses the public key to verify the signature. In the above process, the integrity of the information is verified, but the identity of the sender cannot be known (because anyone can claim to be legal), so an identity authentication agency is introduced.

The identity certification authority is an authority that the recipient of information can trust, and all public keys must be registered with this authority. After registration, the identity certification authority issues a digital certificate to the sender. After signing the file, the sender sends the digital certificate together with the file and the signature to the information receiver, and the receiver asks the identity certification authority to verify whether it is really a file signed with the sender's key.

digital certificate

A digital certificate is an electronic file used to prove the identity of the owner of a public key. This file contains public key information, owner identity information (subject), and the digital signature of the file by the digital certificate authority (issuer).

The essence of a certificate is to digitally sign the public key. The certification authority uses its own private key to digitally sign the public key of the person (or organization) that needs to be certified and generate a certificate.

Type of certificate

We need to know about the following types of certificates

• self-signed certificate
• root certificate
• intermediary certificate
• TLS server certificate
• TLS client certificate

self-signed certificate

Users can generate digital certificates by themselves, but they are not signed by any trusted person. They are mainly used for small-scale testing. Such self-signed certificates are usually not widely trusted, and may encounter security warnings from computer software when using them.

root certificate

Root certificates are widely recognized and are usually pre-installed in various software (including operating systems, browsers, email software, etc.), as the starting point of the chain of trust, from recognized and reliable government agencies, certificate authority companies, non-profit organizations, etc. , and major software vendors have been widely deployed in different software through rigorous verification procedures. Because the deployment procedure is complicated and time-consuming, and requires the authorization of administrative personnel and the verification of the legal identity of the organization, a root certificate may be valid for more than 20 years. In some enterprises, self-signed root certificates may also be installed on internal computers to support enterprise-level software on the intranet; however, these certificates may not be widely recognized and are only applicable within the enterprise.

intermediary certificate

An important task of certification bodies is to issue certificates for clients. Although widely recognized certification bodies already have root certificates and the corresponding private keys can be used to sign other certificates, due to key management and administrative considerations, intermediary certificates are generally issued first. , before digitally signing for the client. The validity period of the intermediary certificate will be shorter than that of the root certificate, and there may be different intermediary certificates for different types of customers.

TLS server certificate

When a website provides services on the Internet, the domain name is the subject on the server certificate, and the name of the relevant organization is written in the column of the organization or unit. The certificate and private key are installed on the server. The client-side software (such as a browser) will perform a certification path validation algorithm to ensure security. If the encrypted channel is not sure whether it is secure (for example, the subject name on the certificate does not correspond to the website domain name, the server uses a self-signed certificate) book, or the encryption algorithm is not strong enough), the user may be warned.

TLS client certificate

Client certificates contain email addresses or personal names, not hostnames. Client certificates are relatively uncommon, because considering the technical barriers and cost factors, it is usually the service provider to verify the client's identity, rather than relying on a third-party certification authority. Usually, the services that need to use the client certificate are enterprise-level software on the intranet. They will set up their own internal root certificate, and the technical personnel of the enterprise will install the relevant client certificate on the internal computer of the enterprise for use. On the open Internet, most websites use login passwords and cookies to authenticate users, rather than client certificates.

The root certificate (self-signed certificate), intermediary certificate and end entity (TLS server/client) certificate form the following chain of trust

certificate format

Certificates generally follow the X.509 format specification

• Version : The current general version is V3
• Serial number : used to identify each voucher, especially useful when revoking vouchers

• Subject : The identity or machine of a legal or natural person who owns this credential, including:

  • Country (C, Country)
  • State/Province (S, State)
  • Region/City (L, Location)
  • Organization/Unit (O, Organization)
  • Common Name (CN, Common Name): In TLS applications, this field is usually the domain name
• Issuer: The digital certificate authority that signed this certificate in the form of a digital signature
• Validity start time : The validity start time of this voucher, before this voucher is not valid
• Validity end time : the validity end time of this voucher, after which the voucher is invalid
• Public key usage : Specify the usage of the public key on the certificate, such as digital signature, server verification, client verification, etc.
• public key
• public key fingerprint
• digital signature
• subject alias

Certificates can be stored in binary or Base64 form, and common file extensions are .cer, .crt, .der, and .pem. If you store the certificate with the private key, you can use the PKCS#12 (.p12) format.

• DER is used for binary DER encoded certificates.
• PEM is used for different types of X.509v3 files and is ASCII (Base64) data prefixed with "-BEGIN...".
• CER and CRT are almost synonymous, and certificates can be encoded as binary DER or ASCII PEM.
• PKCS7 files, also known as P7B, are commonly used in Java Keystores and Microsoft IIS (Windows). They are ASCII files and can contain certificates and CA certificates.
• PKCS12 files, also known as PFX files, are commonly used to import and export certificate chains in Micrsoft IIS (Windows).

application

When we write external API, we do the following design for the security of information transmission

• Sensitive information desensitization, information encryption
• Prevent information from being tampered with and digitally sign

We use SHA256withRSA for signature, the following is a simple example in Java

 public static String sign(byte[] privateKey, String content) {
        try {
            java.security.Signature signature = java.security.Signature
              .getInstance("SHA256withRSA");

            PrivateKey priKey = KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(privateKey));

            signature.initSign(priKey);
            signature.update(content.getBytes(StandardCharsets.UTF_8));

            byte[] signed = signature.sign();
            return URLEncoder.encode(Base64.getEncoder().encodeToString(signed), "UTF-8");
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    public static boolean verify(byte[] publicKey, String content, String signatureToBeVerified) {

        if (StringUtils.isBlank(signatureToBeVerified)) {
            return false;
        }

        try {
            java.security.Signature signature = java.security.Signature.getInstance("SHA256withRSA");

            PublicKey pubKey = KeyFactory.getInstance("RSA").generatePublic(new X509EncodedKeySpec(publicKey));

            signature.initVerify(pubKey);
            signature.update(content.getBytes(StandardCharsets.UTF_8));

            return signature.verify(Base64.getDecoder().decode(URLDecoder.decode(signatureToBeVerified, "UTF-8").getBytes(StandardCharsets.UTF_8)));
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }