Mar 4, 20236 min read

Cryptography Basics - Part II

This post continues on Cryptography Basics - Part I to explore some of the essential concepts in cryptography. Specifically, we will be looking at digital signatures, certificates, different certificate formats and usages.

This is a series blog posts that explores the core concepts in modern cryptography:

Cryptography Basics - Part I: Encryption and Hashing

Cryptography Basics - Part II: Digital Signature and Digital Certificates

Cryptography Basics - Part III: CA, PKI and TLS

1. Digital Signature

Digital signatures can be considered as an electronic version of “fingerprints”. In other words, the digital signature securely associates a signer with a document in a transaction.

Here is the flow on how digital signature is created and verified.

First, the signer generates a hash value from the data and then encrypts the hash value with his private key. The encrypted hash value will be “packaged” together with data and sent to the receiver. After the receiver receives the “package”, he generates a new hash value with the data received. Besides that, the receiver will use a public key published by the signer to decrypt the encrypted hash value from the “package”, which will give us the original hash value. The two hash values are then compared for their values. Any discrepancy means the “package” is not valid and should be discarded.

Let’s take a closer look to see why this is a fail-safe delivery. First, if the encrypted value is not using the signer’s private key, the verifier's decryption will fail. As the public key is published from the Signer’s website, the public key guarantees its originality. This means the private key used to encrypt the data was incorrect. This could be due to a mistake or a hacker’s interception. The data will be discarded in this case. In this case, the public and private keys guarantee the source of the data (the sender) is valid. Next, we need to ensure the validity of the data. Any modification on the data, even so very tiny, will result in a different hash value due to the feature of hashing. If the two hash values are different, it means the data has been tampered and the “package” should be discarded as well.

The failure on the verifier’s side will bring up exceptions in the system which can then be handled by the system. For example, verifiers can ask the signer to send another “package” or some other methods will be used to tackle the situation.

The point here, with the digital signature which leverages Asymmetric Encryption and Hashing, is that message delivery is guaranteed to be successful.

2. Digital Certificate

A Digital Certificate, also known as Public Key Certificate or PKI Certificate, is used to link ownership of a public key with the entity that owns it.

The majority digital certificates serve two main functions:

It verifies the identity of the applicant. With digital certificates, you can be ensured that the entities (website, companies, individuals, etc.) you are interacting with are really who they say they are.
It encrypts the data transferred between two systems so data can only be interpreted by the intended receiver.

The format of digital certificate is defined by X.509, which is an industry standard. It is defined by ITU-T (International Telecommunication Union’s Standardization sector).

3. Certificate Sample

Here is a sample certificate which is the SSL cert for Wikipedia.org. Note it is encoded so it is not human-readable. The “-----BEGIN CERTIFICATE-----” and “-----END CERTIFICATE-----” parts are sometimes required when you import the certificate.

The decoded information is as below:

And more detail information is listed here:

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

03:02:b3:43:f5:59:0b:2e:55:ca:6e:47:59:a4:d3:0f:df:0b

Signature Algorithm: sha256WithRSAEncryption

Issuer:

commonName = Let's Encrypt Authority X3

organizationName = Let's Encrypt

countryName = US

Validity

Not Before: Mar 22 07:01:41 2020 GMT

Not After : Jun 20 07:01:41 2020 GMT

Subject:

commonName = *.wikipedia.org

Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (256 bit)

pub:

04:74:b5:b5:1c:df:2e:26:46:2c:50:ac:cd:51:15:

e6:56:88:0e:ba:b4:bf:38:b6:18:41:0a:91:d8:1e:

cd:7b:66:0a:a1:16:f3:8f:25:3e:71:02:8a:7e:88:

94:ad:eb:17:f0:8e:03:a3:26:cc:09:39:bf:68:65:

77:37:37:5f:4f

ASN1 OID: prime256v1

X509v3 extensions:

X509v3 Key Usage: critical

Digital Signature

X509v3 Extended Key Usage:

TLS Web Server Authentication, TLS Web Client Authentication

X509v3 Basic Constraints: critical

CA:FALSE

X509v3 Subject Key Identifier:

A4:78:12:BA:69:56:E0:CE:DA:1C:14:A7:2C:23:FA:33:2B:65:B0:C6

X509v3 Authority Key Identifier:

keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

Authority Information Access:

OCSP - URI:http://ocsp.int-x3.letsencrypt.org

CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

X509v3 Subject Alternative Name:

DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikipedia.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikipedia.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org

X509v3 Certificate Policies:

Policy: 2.23.140.1.2.1

Policy: 1.3.6.1.4.1.44947.1.1.1

CPS: http://cps.letsencrypt.org

Digital certificates are most commonly used for initializing secure connections (SSL/TLS). Digital certificates are also used for sharing public keys which are used for public key encryption and authentication of digital signatures.

A digital certificate mainly includes:

Public key being certified
Identifying information about the entity that owns the public key
Metadata related to the digital certificate
Digital signature created by the issuer of the certificate

4. Certificate Format

Usually the format of a digital certificate will contain the following information.

5. Certificate Format Types

There are different formats of X.509 certificates: PEM, PCKS#7, DER and PCKS#12.

PEM and PCKS#7 formats use Base64 ASCII encoding while DER and PKCS#12 use binary encoding. The certificate files have different extensions based on the format and encoding they use.

PEM Format

Most CAs provide certificates in PEM format in Base64 ASCII encoded files. The certificate file types can be .pem, .crt, .cer, or .key. The .pem file can include the server certificate, the intermediate certificate and the private key in a single file. The server certificate and intermediate certificate can also be in a separate .crt or .cer file. The private key can be in a .key file.

PEM files use ASCII encoding, so they can be opened in text editor. The certificate is contained between ---- BEGIN CERTIFICATE ---- and ---- END CERTIFICATE ---- statements.

PKCS#7 Format

PKCS#7 format is a cryptographic message syntax standard. PKCS#7 certificate use Base64 ASCII encoding with file extension .p7b or .p7c. Only certificates can be stored in this format, not private keys. The P7B certificates are contained between ---- BEGIN PKCS7 ---- and ---- END PKCS7 ---- statements.

DER Format

The DER certificates are in binary form, contained in .der or .cer files. These certificates are mainly used in Java-based web servers.

PKCS#12 Format

The PKCS#12 certificates are in binary form, contained in .pfx or .p12 files. This format has become popular today.

The PKCS#12 can store server certificate, the intermediate certificate and the private key in a single .pfx file with password protection. These certificates are mainly used on the Windows platform.

6. Certificate Usages

TLS/SSL Server Certificate

In TLS (Transport Layer Security), which is a replacement for SSL, a server is required to present a certificate as part of the initial connection setup. A client connecting to that server will perform the certification validation:

The subject of the certificate matches the hostname, i.e. domain name, to which the client is trying to connect. The certificate is signed by a trusted Certificate Authority.
The primary hostname (domain name of the website) is listed as the Common Name in the Subject field of the certificate. A certificate might be valid for multiple hostnames, that is multiple websites, which are listed under SAN (Subject Alternative Name)

A TLS/SSL server may be configured with a self-signed certificate. In that case, clients generally won’t be able to verify the certificate. Depending on the context, sometimes clients can proceed with access while sometimes they are forced to terminate the connection.

Self-Signed Certificate

A Self-Signed Certificate is a certificate that is not signed by a CA. These certificates are easy to generate and cost-free. Yet, they lack some security properties compared to the ones signed by a CA.

For example, when a web server uses a Self-Signed Certificate to provide HTTPS services, users will see a warning sign in the browser. Sometimes user will be forced by the browser to terminate the connection.

Root Certificate

A Root Certificate is a certificate that identifies a root CA. Root certificates are self-signed and form the basis of X.509-based PKI (Public Key Infrastructure). We will be looking at more details for PKI later.

Intermediate Certificate

An Intermediate Certificate is a certificate used to sign other certificates. It’s within the middle tier in the PKI hierarchy. An intermediate certificate must be signed by another intermediate certificate, or a root certificate.

Leaf Certificate

Leaf certificate is any certificate that cannot be used to sign other certificates. For example, TLS/SSL server certificates.

TLS/SSL Client Certificate

Client certificates are less common compared to server certificates. They are used to authenticate a client connecting to the TLS server as well as providing access control.

Client certificates are more common in RPC systems, where they are used to authenticate devices to ensure that only authorized devices can make certain calls.

Email Certificate

In the secure email protocol, senders need to discover which public key to use for a given recipient. They get this information from an email certificate.

7. Sum Up

In this post, we continued from Cryptography Basics - Part I to look at digital certificates. We first took a peek at digital signature and how it is generated and verified. Then we jumped into digital certificate and viewed some details of its content. After that, different certificate formats are explained and some example usages of digital certificate are listed as well.

We will continue in Cryptography Basics - Part III to look at CA, PKI and TLS.