3.9 - Given a scenario, implement public key infrastructure. Flashcards
PKI
Public key infrastructure
Policies, procedures, hardware, software, people
– Digital certificates: create, distribute, manage,
store, revoke
*
This is a big, big, endeavor
– Lots of planning
*
Also refers to the binding of public keys to people
or devices
– The certificate authority
– It’s all about trust
Key management (lifecycle)
Key generation
– Create a key with the requested strength using
the proper cipher
Certificate generation
– Allocate a key to a user
Distribution
– Make the key available to the user
Storage
– Securely store and protect against unauthorized use
Revocation
– Manage keys that have been compromised
Expiration
– A certificate may only have a certain “shelf life”
CA
Certificate authority
Intermediate CA
RA
Registration authority
The entity requesting the certificate needs to be verified
– The RA identifies and authenticates the requester
Approval or rejection
– The foundation of trust in this model
Also responsible for revocations
– Administratively revoked or by request
Manages renewals and re-key requests
– Maintains certificates for current cert holders
CRL
Certificate revocation list
Certificate attributes
Common Name (CN)
– The FQDN (Fully Qualified
– Domain Name) for the certificate
Subject alternative name
– Additional host names for the cert
– Common on web servers
– professormesser.com and www.professormesser.com
Expiration
– Limit exposure to compromise
– 398 day browser limit (13 months)
OCSP
Online Certificate Status Protocol
CSR
Certificate signing request
Create a key pair, send the public key to the CA
to be signed
CN
Common Name
– The FQDN (Fully Qualified
– Domain Name) for the certificate
Subject alternative name
– Extension to an X.509 certificate
– Lists additional identification information
– Allows a certificate to support many
different domains
Expiration
Wildcard
– Certificates are based on the name of the server
– A wildcard domain will apply to all server names
in a domain
– *.professormesser.com
Code signing
*
Developers can provide a level of trust
– Applications can be signed by the developer
*
The user’s operating system will examine
the signature
– Checks the developer signature
– Validates that the software has not been modified
*
Is it from a trusted entity?
– The user will have the opportunity to stop the
application execution
Self-signed (Types of certificates)
*
Internal certificates don’t need to be signed by
a public CA
– Your company is the only one going to use it
– No need to purchase trust for devices that already
trust you
*
Build your own CA
– Issue your own certificates signed by your own CA
*
Install the CA certificate/trusted chain on all devices
– They’ll now trust any certificates signed by
your internal CA
– Works exactly like a certificate you purchased
Machine/computer (Types of certificates)
*
You have to manage many devices
– Often devices that you’ll never physically see
*
How can you truly authenticate a device?
– Put a certificate on the device that you signed
*
Other business processes rely on the certificate
– Access to the remote access
– VPN from authorized devices
– Management software can validate the end device
*
Use cryptography in an email platform
– You’ll need public key cryptography
*
Encrypting emails
– Use a recipient’s public key to encrypt
*
Receiving encrypted emails
– Use your private key to decrypt
Digital signatures
– Use your private key to digitally sign an email
– Non-repudiation, integrity
User (Types of certificates)
Associate a certificate with a user
– A powerful electronic “id card”
*
Use as an additional authentication factor
– Limit access without the certificate
*
Integrate onto smart cards
– Use as both a physical and digital access card
Root (Types of certificates)
Domain validation
Extended validation
Additional checks have verified the certificate
owner’s identity
– Browsers used to show a green name on the
address bar
– Promoting the use of SSL is now outdated
DER
Distinguished encoding rules
*
Format designed to transfer syntax for data structures
– A very specific encoding format
– Perfect for an X.509 certificate
*
Binary format
– Not human-readable
*
A common format
– Used across many platforms
– Often used with Java certificates
PEM
Privacy enhanced mail
*
A very common format
– BASE64 encoded DER certificate
– Generally the format provided by CAs
– Supported on many different platforms
*
ASCII format
– Letters and numbers
– Easy to email, readable
PFX
Personal information exchange
.cer
Certificate
*
Primarily a Windows X.509 file extension
– Can be encoded as binary DER format or as the
ASCII PEM format
*
Usually contains a public key
– Private keys would be transferred in the
.pfx file format
*
Common format for Windows certificates
– Look for the .cer extension
P12
PKCS #12
*
Public Key Cryptography Standards #12
– Personal Information Exchange Syntax Standard
– Developed by RSA Security, now an RFC standard
*
Container format for many certificates
– Store many X.509 certificates in a single
.p12 or .pfx file
– Often used to transfer a private and public key pair
– The container can be password protected
*
Extended from Microsoft’s .pfx format
– Personal Information Exchange (PFX)
– The two standards are very similar
– Often referenced interchangeably
P7B
PKCS #7
*
Public Key Cryptography Standards #7
*
Cryptographic Message Syntax Standard
– Associated with the .p7b file
*
Stored in ASCII format
– Human-readable
*
Contains certificates and chain certificates
– Private keys are not included in a .p7b file
*
Wide platform support
– Microsoft Windows
– Java Tomcat
Online vs. offline CA
*
A compromised certificate authority
– A very, very bad thing
– No certificates issued by that CA can be trusted
*
Distribute the load
– Then take the root CA offline and protect it
Stapling (OCSP)
Online Certificate Status Protocol
– Provides scalability for OCSP checks
The CA is responsible for responding to all client OCSP requests
– doesn’t scale well
instead, have the certificate holder verify their own status
– Status information is stored on the certificate holder’s server
OCSP status is “stapled” into the SSL/TLS handshake
– Digitally signed by the CA
Pinning
You’re communicating over TLS/SSL to a server
– How do you really know it’s a legitimate server?
*
“Pin” the expected certificate or public key to an application
– Compiled in the app or added at first run
*
If the expected certificate or public key doesn’t match, the
application can decide what to do
– Shut down, show a message
Trust model
Key escrow
Someone else holds your decryption keys
– Your private keys are in the hands
of a 3rd-party
This can be a legitimate business arrangement
– A business might need access to employee
information
– Government agencies may need to decrypt partner data
Certificate chaining
Chain of trust
– List all of the certs between the server
and the root CA
The chain starts with the SSL certificate
– And ends with the Root CA certificate
Any certificate between the SSL certificate
and the root certificate is a chain certificate
– Or intermediate certificate
The web server needs to be configured with
the proper chain
– Or the end user may receive an error
