Digital Signature

A digital signature is not your handwritten signature scanned into a jpeg. That is not bound to you in any way, and a malicious actor can scan anyone’s handwritten signature and embed that into a document.

A real digital signature is a binary object that is bound to you, which only you can affix to a document (since you are the only person that has your private key), and anyone can verify that it is your digital signature (through the use of your digital certificate, which contains your public key that is needed to verify the signature). Furthermore, a digital signature provides message integrity , so any change at all to the document since you signed it can be easily detected by anyone.

You create a message digest of the document (using a hash function, such as SHA256) that you want to digitally sign and then encrypt that digest (using an asymmetric key algorithm such as RSA) and your private key. The encrypted message digest (EMD) is your digital signature. Anyone can validate your signature by decrypting the signature using your public key (after validating your certificate that contains your public key). This yields the recovered message digest. The recipient then produces a new message digest of the received document using the same hash function used by the sender. If those two digests match, it’s a valid signature. This provides the recipient with three things:

Signer authentication – Nobody but you could have produced a digital signature that validates with your digital certificate (since only you have the necessary private key to do this).

Message integrity – Had there been any changes whatsoever to the message after you signed it, the signature would fail when you validate it. A digital signature cannot prevent changes to the message, but it can definitely detect them – even a single bit in a digital copy of War and Peace.

Non-repudiation – Since you are the only one who could have signed it, you cannot repudiate it having come from you. Don’t digitally sign any message that might incriminate you!

Note that a digital signature does not provide any privacy. That requires a digital envelope. Digital envelopes are discussed later and involve encryption. The message (M) is still in plaintext, and anyone can read it. It cannot detect whether anyone has read your message along the way.

Creating a Digital Signature

In the following example (Figure 4-1), Alice (the sender) produces a digest (MD) from the message (M) using a hash function, such as SHA256.

The MD is encrypted using an asymmetric key algorithm such as RSA and Alice’s private key, producing the signature (EMD for encrypted message digest).

The message (M), the signature (EMD), and Alice’s certificate (Cert) are then sent to Bob.

Validating a Digital Signature

From there, Bob receives the message (M), the signature (EMD), and Alice’s certificate (Cert) from Alice (Figure 4-2).

He generates a new message digest (MD’) using the same hash function used by the sender, from the received message (M).

He extracts Alice’s public key (Kpub) from her certificate (after validating the certificate).

He then decrypts the signature (EMD) using RSA^-1 (the same asymmetric key algorithm used by the sender, but running in the decrypt direction) and Alice’s public key (Kpub), which yields the recovered message digest (MD”).

Finally, he compares MD’ and MD”. If they match, it’s a good signature.

Note that I use the notation RSA-1 (to be read “RSA inverse”) to indicate running an encryption algorithm in decrypt direction.

Uses of Digital Signatures

Digital signatures are used in S/MIME Secure Email to authenticate the sender to the recipient. It also will detect any changes to the message while it is in transit. If the sender wants for the recipient to acknowledge receipt of the message and authenticate themselves to the sender, the recipient must return a signed receipt (most S/MIME-compliant email clients have the ability to do that).

Digital signatures are used in digital certificates to ensure that nothing in the certificate can be changed without detection and to let everyone know for certain that the certificate was issued by the Certification Authority (CA) shown in the Issuer Distinguished Name.

A Certification Authority is the organization that issues digital certificates to applicants. It will be described in great detail in the chapter on PKI. The Issuer Distinguished Name is a list of name/value pairs that identifies the CA who issued this certificate. A typical IssuerDN is “CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB.”

You can affix a digital signature to any digital document to detect changes (message integrity) and to establish who signed it (signer authentication). This includes PDF files, drawings, MS Office documents, etc. You can even digitally sign binary files, like images or digitized music. Not all applications support adding or verifying a digital signature, but you can create a signed document that includes any of these, for example, an S/MIME email with attachments. MS Office allows affixing and validating digital signatures in any Office document. Adobe supports adding digital signatures to a PDF document and validating them.

Digital Envelope

A digital envelope is built using both symmetric key and asymmetric key cryptography. The encryption of the message is done with symmetric key cryptography , and the symmetric session key is sent to the recipient securely using asymmetric key cryptography.

It only provides privacy, but it also prevents tampering (not just detects it) since the content cannot be seen or modified without the symmetric session key. It doesn’t guarantee delivery – a hacker could still delete or reroute a message (the message headers are not encrypted or signed). But only the intended recipient can open the message body or attachments.

Digital signature and digital envelope are independent. A given message can use either, neither, or both. If you use both, you digitally sign the entire message first, and then all message components are encrypted in a single digital envelope.

Creating the Digital Envelope

Next, Alice (the sender) first generates a symmetric session key (SSK) using a cryptographic random number generator (Figure 4-3).

She then encrypts the message (M) with the symmetric key algorithm (e.g., AES) and the SSK, producing the Encrypted Message (EM).

Then she encrypts the SSK with RSA and Bob’s public key (Kpub), producing the Encrypted Session Key (ESK).

The Encrypted Message (EM) and Encrypted Session Key (ESK) are sent to Bob.

Need for Recipient Certificates

To send a digitally enveloped message to someone, you need their S/MIME Certificate which contains their public key, at the time you send the message. This can be done with a local “personal address book” or a “shared address book” (e.g., with Active Directory). To open a digitally enveloped message to you, you need only your own private key.

One common way to get someone’s digital certificate is to ask them to send you a digitally signed message, as their certificate is usually included with it. Microsoft Outlook has a way to store the S/MIME Certificate on a signed message in your personal address book. It is much better if the network administrator can create a shared address book for use by all users.

If there are multiple recipients, you need the S/MIME Certificate for each recipient. When sending to multiple recipients, a single symmetric session key is generated, and then the message is encrypted with it. Then that symmetric session key is encrypted with each recipient’s public key (from their respective certificates). So, the message contains a single encrypted message plus one encrypted session key for each recipient. When each recipient gets this message, they use their private key to decrypt the session key encrypted with their public key and then decrypt the message using that recovered session key.

Opening the Digital Envelope:

Next, Bob receives the Encrypted Message (EM) and Encrypted Session Key (ESK) from Alice (Figure 4-4).

He first decrypts the ESK using his own private key (KPriv) and RSA in decryption mode, producing the Recovered Session Key (SK’).

Then the Encrypted Message (EM) is decrypted using the selected symmetric key algorithm in decrypt mode (AES^-1) and the Recovered Session Key (SK’), producing the Recovered Message (M’).