Authenticity

Dr. Greg Bernstein

October 12th, 2021

Signatures and Certificates

Learning Objectives

From NCyTE

  • Students will be able to explain the mechanisms used for digital signatures.

  • Students will be able to explain the role of digital certificates and certificate authorities in secure communications.

  • Students will be able to illustrate how digital signatures work using software such as Python, OpenSSL, or GnuPG.

References General

References TLS and X.509

Cryptographic Context

From NCyTE

  • Confidentiality: Encryption algorithms
  • Integrity: (Cryptographic) Hash functions
  • Authenticity: Digital signatures, digital certificates
  • Non-repudiation: Digital signatures, digital certificates

Recall Symmetric Encryption

From NCyTE

Symmetric Cryptography

Recall Public Key Encryption

From NCyTE

Asymmetric Cryptography

Recall: Advantages of Asymmetric Encryption

From NCyTE

  • With asymmetric encryption, users do not have to share a secret value that they have to communicate or agree on beforehand or over a public channel.

  • Public keys are published and available to everyone in the system.

  • Note: Private keys should NOT be shared!

Problem of Authentication

From NCyTE

  • How does Bob know that the message is indeed from Alice?

  • Someone else might have used Bob’s public key, sent him the message, and claimed he/she was Alice!

  • Solution: Digital signatures and certificates

Digital Signatures

From NCyTE

  • In public key cryptography there are schemes that allow the private key to be used for encryption and the public key to be used for decryption. (Contrast this with the use of keys in asymmetric encryption for confidential communication.)

  • Why would we want to do that?

Digital Signatures and Authentication 1

From NCyTE

  • If encrypted with a private key, the successful decryption of a ciphertext with the corresponding public key indicates that the message was indeed encrypted with the private key that corresponds to the public key used for decrypting it.

  • So if we consider the ciphertext of the message as a signature, then a successful decryption indicates the verification of the signature.

Digital Signatures and Authentication 2

From NCyTE

  • In practice, the hash value of the message is encrypted to get the signature, not the message itself. (Recall that a message can be arbitrarily large but the hash value has a fixed length.)

Signature Creation and Verification

From NCyTE

Signature diagram

Digital Signatures and Integrity

From NCyTE

  • If Alice’s signature on a message does not verify, one of two things might have happened:
    1. It wasn’t Alice’s private key that was used to sign the message OR
    2. The message was altered, so the hash of the message does not match the signature.
  • If Alice signed the message, then the digital signature detects the alteration in the message; hence the signature indicates the integrity of the message.

Digital Signatures and Non-repudiation

From NCyTE

  • Non-repudiation refers to the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated.

  • In the scenario for digital signatures, because the private key is known only to the owner, if a signature verifies on a message, it is highly unlikely that it was signed by someone else!

Digital Signatures and Hash Functions 1

From NCyTE

  • Unlike paper equivalents, digital signatures are unique to each document.

  • That is, the same person’s digital signature on one message is different from his/her signature on a different message.

Digital Signatures and Hash Functions 2

From NCyTE

  • Because a message can get arbitrarily large and public key encryption algorithms require the length of messages to be under a certain maximum, instead of the message itself being signed, the hash of the message is signed. (Recall that a message can be arbitrarily large but the hash value has a fixed length.)

Examples of Digital Signature Algorithms

From NCyTE

  • RSA (Rivest Shamir Adleman) signatures

  • Elliptic Curve Signatures

  • DSA: Digital Signature Algorithm

Signatures with OpenSSL – Keys

From How to sign and verify using OpenSSL

# Generate 4096-bit RSA private key and extract public key
openssl genrsa -out key.pem 4096
openssl rsa -in key.pem -pubout > key.pub

Signatures with OpenSSL – Sign

From How to sign and verify using OpenSSL

openssl dgst -sign key.pem -keyform PEM -sha256 -out book.sign -binary sherlockHolmes.txt

Notes: We are signing with our private key!

Signatures with OpenSSL – Verify

From How to sign and verify using OpenSSL

openssl dgst -verify key.pub -keyform PEM -sha256 -signature book.sign -binary sherlockHolmes.txt

Notes: They are verifying with our public key!

Signatures with Python – Verified

See ED25519 Signig

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
private_key = Ed25519PrivateKey.generate()
signature = private_key.sign(b"my authenticated message.")
print(f"length of signature: {len(signature)}")
print(f"start of signature: {signature[0:16].hex()}")
public_key = private_key.public_key()
# Raises InvalidSignature if verification fails
public_key.verify(signature, b"my authenticated message.")

Signatures with Python – Not Verified

See ED25519 Signig

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
private_key = Ed25519PrivateKey.generate()
signature = private_key.sign(b"my authenticated message.")
public_key = private_key.public_key()
# Raises InvalidSignature if verification fails
try:
    # Note slight change in the message
    public_key.verify(signature, b"my authenticated message!")
except:
    print("Message not authenticated!")

Still a Problem: Authenticity

From NCyTE

  • Even though Bob can verify that the signature on a message is signed by the private key corresponding to the public key he used, how does he know that it is indeed Alice who is associated with that public key?

  • Solution: PKI and digital certificates

Public Key Infrastructure (PKI)

Definition: Public Key Infrastructure

From NCyTE

  • The set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography.

  • Provides key distribution and key management

Digital Certificates

From NCyTE

  • A digital certificate is an electronic document that binds a public key with an entity (person, organization).

  • It includes:

    • The owner (subject) name/id
    • The public key of the owner
    • The digital signature (seal) of the issuing entity (authority)
    • Validity period of the certificate
    • Algorithms used and more …

Concept of a Digital Certificate

From NCyTE

Certificate concept

My Certificate 1

Grotto Networking Certificate

My Certificate 2

Grotto Networking Certificate

Certificate Authority (CA) 1

From NCyTE

  • A trusted entity that issues electronic documents and digital certificates that verify a digital entity’s identity on the Internet.

  • Signs these certificates using its private key; its public key is made available to all interested parties in a self-signed CA certificate.

  • CAs use the trusted root certificate to create a “chain of trust.”

Certificate Authority (CA) 2

From NCyTE

  • Many root certificates are embedded in web browsers so they have built-in trust of those CAs.

  • Web servers, email clients, smartphones, and many other types of hardware and software also support PKI and contain trusted root certificates from the major CAs.

Certification Path and Chain of Trust

Cert Chain Grotto

Elements of PKI

  • A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities

  • registration authority, often called a subordinate CA, is certified by a root CA to issue certificates for specific uses permitted by the root.

  • A certificate database, which stores certificate requests and issues and revokes certificates.

  • A certificate store , which resides on a local computer as a place to store issued certificates and private keys.

Types of Certificates 1

From Wikipedia: Public Key Certificates

  • TLS/SSL server certificate: Used all over the Internet to identify servers and support HTTPS.

  • Root certificate, Intermediate certificate: Used to sign other certificates

  • End-entity or leaf certificate: A certificate that cannot sign other certificates

  • Email certificate: Used in secure email.

Types of Certificates 2

From Wikipedia: Public Key Certificates

  • Self-signed certificate: Used in development, should not be trusted on the internet!

  • TLS/SSL client certificate: Can be used to identify a client, but not very common

  • EMV certificate: Used with certain payment cards

  • Qualified certificate: used for some types of signatures in Europe

X.509 Certificate Generation Process 1

From Wikipedia X.509

  1. In the X.509 system, an organization that wants a signed certificate requests one via a certificate signing request (CSR).

  2. To do this, it first generates a key pair, keeping the private key secret and using it to sign the CSR.

X.509 Certificate Generation Process 2

From Wikipedia X.509

  1. The CSR contains information identifying the applicant and the applicant’s public key that is used to verify the signature of the CSR - and the Distinguished Name (DN) that the certificate is for.

  2. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority.

  3. The certification authority issues a certificate binding a public key to a particular distinguished name.

The structure of an X.509 v3 digital certificate

From Wikipedia X.509

Certificate
    Version Number
    Serial Number
    Signature Algorithm ID
    Issuer Name
    Validity period
        Not Before
        Not After
    Subject name
    Subject Public Key Info
        Public Key Algorithm
        Subject Public Key
    Issuer Unique Identifier (optional)
    Subject Unique Identifier (optional)
    Extensions (optional)
        ...
Certificate Signature Algorithm
Certificate Signature

Transport Layer Security

TLS Concepts 1

From Wikipedia: TLS

  • Client-server applications use the TLS protocol to communicate across a network in a way designed to prevent eavesdropping and tampering.

  • The connection is private (or secure) because a symmetric-key algorithm is used to encrypt the data transmitted.

TLS Concepts 2

From Wikipedia: TLS

  • The identity of the communicating parties can be authenticated using public-key cryptography. This authentication is required for the server and optional for the client.

  • The connection is reliable because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.

  • The TLS protocol comprises two layers: the TLS record and the TLS handshake protocols.

TLS Handshake 1

From Wikipedia: TLS

  • The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and the client presents a list of supported cipher suites (ciphers and hash functions).

  • From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.

  • The server usually then provides identification in the form of a digital certificate. The certificate contains the server name, the trusted certificate authority (CA) that vouches for the authenticity of the certificate, and the server’s public encryption key.

TLS Handshake 2

From Wikipedia: TLS

  • The client confirms the validity of the certificate before proceeding.

  • Session keys are generated or exchanged

To see the handshake use the WireShark filter tls.handshake

TLS Handshake 3

Client Hello

Client Hello

TLS Handshake 4

Server Hello

Server Hello

Web of Trust and Email

Alternative to PKI

In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP-compatible systems to establish the authenticity of the binding between a public key and its owner. Its decentralized trust model is an alternative to the centralized trust model of a public key infrastructure (PKI), which relies exclusively on a certificate authority (or a hierarchy of such). As with computer networks, there are many independent webs of trust, and any user (through their identity certificate) can be a part of, and a link between, multiple webs.

Web of Trust

WoT Diagram

References

Secure email

TBD

// reveal.js plugins