Non-Repudiation and Digital Signatures

Non-repudiation is the assurance that someone cannot deny the validity of something they created or approved. In cybersecurity, it means a sender cannot deny sending a message, and a signer cannot deny signing a document. Digital signatures are the primary cryptographic tool used to achieve non-repudiation. They provide three core security services:

SY0-701 tests your ability to identify when non-repudiation is needed (e.g., legal contracts, audit logs) and how digital signatures differ from other cryptographic controls like hashing or encryption.

Digital signatures rely on asymmetric cryptography (public/private key pairs). The process involves two phases: signing and verification.

Signing (by the sender): 1. The sender creates a message (e.g., an email or document). 2. A cryptographic hash function (e.g., SHA-256) produces a fixed-size digest of the message. The hash is unique; any change to the message produces a different hash. 3. The sender encrypts the hash using their private key. This encrypted hash is the digital signature. 4. The sender attaches the digital signature to the message and sends both to the recipient.

Verification (by the recipient): 1. The recipient separates the message and the digital signature. 2. The recipient decrypts the digital signature using the sender's public key. This yields the original hash (as computed by the sender). 3. The recipient independently computes the hash of the received message using the same hash function (e.g., SHA-256). 4. The recipient compares the two hashes. If they match, the message is authentic and unaltered.

Why this provides non-repudiation: Only the sender's private key could have produced the encrypted hash. Since the private key is known only to the sender, successfully decrypting with the public key proves the sender signed it. The sender cannot later claim they didn't—unless their private key was compromised.

Hash Functions: - SHA-256 (Secure Hash Algorithm 256-bit) is the most common for digital signatures. SHA-1 is deprecated due to collision attacks. MD5 is never used for signatures. - Hash length: SHA-256 produces a 256-bit (32-byte) digest.

Asymmetric Algorithms: - RSA (Rivest-Shamir-Adleman): Most widely used. Key sizes: 2048 bits minimum (SY0-701 expects 2048 or higher). - DSA (Digital Signature Algorithm): Used in federal standards (FIPS 186). Key size: 1024-3072 bits. - ECDSA (Elliptic Curve Digital Signature Algorithm): Uses smaller keys for equivalent security (e.g., 256-bit ECC ≈ 3072-bit RSA).

Digital Signature Standards: - PKCS#7 / CMS (Cryptographic Message Syntax): Used for signing and enveloping data. - X.509: Public key certificate format that binds an identity to a public key. - RFC 3161: Timestamp protocol to prove existence of data at a specific time.

Public Key Infrastructure (PKI): - Certificate Authority (CA): Issues digital certificates containing the public key and identity. - Registration Authority (RA): Verifies identity before certificate issuance. - Certificate Revocation List (CRL) / Online Certificate Status Protocol (OCSP): Check if a certificate is revoked.

Attackers exploit weak signature implementations: - Hash collision attacks: If an attacker can find two messages with the same hash, they could swap a signed message with a malicious one. SHA-256 is currently collision-resistant; SHA-1 is not (e.g., SHAttered attack in 2017). - Private key theft: If an attacker steals the private key, they can sign messages as the victim. Defenders protect private keys with hardware security modules (HSMs) or smart cards. - Certificate forgery: Attackers may create fake certificates if a CA is compromised (e.g., DigiNotar breach). Defenders use certificate transparency logs and pinning. - Replay attacks: An attacker re-sends a previously signed message. Defenders use timestamps and nonces.

Defenders deploy digital signatures for: - Code signing: Software publishers sign executables to prove authenticity. Windows uses Authenticode. - Email signing: S/MIME (Secure/Multipurpose Internet Mail Extensions) signs emails. - Document signing: PDF signing with Adobe Acrobat or Microsoft Office digital signatures. - Audit logs: Signed logs ensure tamper evidence and non-repudiation of log entries.

Using OpenSSL to sign and verify:

# Generate a private key
openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048

# Extract the public key
openssl rsa -pubout -in private.pem -out public.pem

# Create a message file
echo "This is a signed message." > message.txt

# Sign the message (create signature)
openssl dgst -sha256 -sign private.pem -out signature.bin message.txt

# Verify the signature
openssl dgst -sha256 -verify public.pem -signature signature.bin message.txt

Using GnuPG (GPG) for signing:

# Generate a key pair
gpg --gen-key

# Sign a file
gpg --sign file.txt

# Verify a signed file
gpg --verify file.txt.gpg

Windows PowerShell for code signing:

# Sign a script with a certificate
Set-AuthenticodeSignature -FilePath script.ps1 -Certificate (Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert)

# Verify signature
Get-AuthenticodeSignature -FilePath script.ps1

A software company distributes an update for its application. The development team signs the executable with a code signing certificate issued by a trusted CA. When a user downloads the update, Windows checks the digital signature. If the signature is valid and the certificate chain is trusted, Windows allows the installation. If the signature is missing or invalid, Windows displays a warning: "Windows protected your PC." A security analyst in the SOC might see a security event ID 1008 (Signature Verification) or a SmartScreen warning. The correct response is to verify the publisher's certificate and ensure the file hash matches the official release. A common mistake is ignoring the warning and allowing the unsigned executable to run, potentially installing malware. The analyst should use tools like sigcheck from Sysinternals to inspect the signature:

sigcheck.exe -a installer.exe

A bank's compliance team requires that all log entries from critical servers be digitally signed to ensure non-repudiation. The logging system generates a hash of each log entry and signs it with the server's private key. Logs are stored in a central SIEM. An auditor later reviews the logs and verifies signatures using the server's public key. If a log entry was altered, the signature verification fails. The SIEM can automatically alert on signature mismatches. A common mistake is relying solely on hashing without signing—hashing only provides integrity, not non-repudiation. An attacker could modify logs and recompute the hash. With digital signatures, the attacker would need the private key to re-sign. The correct response is to keep private keys in HSMs and rotate them periodically.

A doctor sends a patient's prescription via email. The email is signed using S/MIME with the doctor's personal certificate. The recipient (pharmacy) verifies the signature to confirm the email came from the doctor and hasn't been altered. If the signature is valid, the pharmacy can trust the prescription. If the signature is invalid, the email may be a phishing attempt. A security analyst might see a failed S/MIME verification in email gateway logs (e.g., Exchange Online message trace). The correct response is to quarantine the email and notify the intended recipient. A common mistake is assuming that encryption alone provides non-repudiation—encryption only provides confidentiality. The exam often tests this distinction.