Dr. Greg Bernstein
October 12th, 2021
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.
From NCyTE
From NCyTE
From NCyTE
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!
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
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?
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.
From NCyTE
From NCyTE
From NCyTE
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!
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.
From NCyTE
From NCyTE
RSA (Rivest Shamir Adleman) signatures
Elliptic Curve Signatures
DSA: Digital Signature Algorithm
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
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!
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!
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.")
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!")
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
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
From NCyTE
A digital certificate is an electronic document that binds a public key with an entity (person, organization).
It includes:
From NCyTE
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.”
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.
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
A 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.
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.
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
From Wikipedia X.509
In the X.509 system, an organization that wants a signed certificate requests one via a certificate signing request (CSR).
To do this, it first generates a key pair, keeping the private key secret and using it to sign the CSR.
From Wikipedia X.509
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.
The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority.
The certification authority issues a certificate binding a public key to a particular distinguished name.
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
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.
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.
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.
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
Client Hello
Server Hello
Wikipedia: Pretty Good Privacy – includes OpenPGP discussion
[]
TBD