3.9 Public Key Infrastructure Flashcards
• 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
Public Key Infrastructure (PKI)
• 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”
The key management lifecycle
• A public key certificate
– Binds a public key with a digital signature
– And other details about the key holder
• A digital signature adds trust
– PKI uses Certificate Authority for additional trust
– Web of Trust adds other users for additional trust
• Certificate creation can be built into the OS
– Part of Windows Domain services
– 3rd-party Linux options
Digital certificates
• Built-in to your browser
– Any browser
• Purchase your web site certificate
– It will be trusted by everyone’s browser
• Create a key pair, send the public key to the CA
to be signed
– A certificate signing request (CSR)
• May provide different levels of trust and
additional features
– Add a new “tag” to your web site
Commercial certificate authorities
• You are your own CA
– Build it in-house
– Your devices must trust the internal CA
• Needed for medium-to-large organizations
– Many web servers and privacy requirements
• Implement as part of your overall computing strategy
– Windows Certificate Services, OpenCA
Private certificate authorities
• Single CA
– Everyone receives their certificates from one authority
• Hierarchical
– Single CA issues certs to intermediate CAs
– Distributes the certificate management load
– Easier to deal with the revocation of an intermediate
CA than the root CA
PKI trust relationships
• 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
Registration authority (RA)
• 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)
Important certificate attributes
• Certificate Revocation List (CRL)
– Maintained by the Certificate Authority (CA)
• Many different reasons
– Changes all the time
• April 2014 - CVE-2014-0160
– Heartbleed
– OpenSSL flaw put the private key of affected
web servers at risk
– OpenSSL was patched, every web server
certificate was replaced
– Older certificates were moved to the CRL
Key revocation
• OCSP (Online Certificate Status Protocol)
– The browser can check certificate revocation
• Messages usually sent to an OCSP responder via HTTP
– Easy to support over Internet links
• Not all browsers/apps support OCSP
– Early Internet Explorer versions did not
support OCSP
– Some support OCSP, but don’t bother checking
Getting revocation details to the browser
• Domain validation certificate (DV)
– Owner of the certificate has some control over
a DNS domain
• Extended validation certificate (EV)
– 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
• Subject Alternative Name (SAN)
– Extension to an X.509 certificate
– Lists additional identification information
– Allows a certificate to support many
different domains
• Wildcard domain
– Certificates are based on the name of the server
– A wildcard domain will apply to all server names
in a domain
– *.professormesser.com
Web server SSL certificates
• 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
Code signing certificate
• The public key certificate that identifies the root CA
(Certificate Authority)
– Everything starts with this certificate
• The root certificate issues other certificates
– Intermediate CA certificates
– Any other certificates
• This is a very important certificate
– Take all security precautions
– Access to the root certificate allows for the
creation of any trusted certificate
Root certificate
• 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
Self-signed 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
Machine and computer certificates
• 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
Email 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
User certificates
• X.509 digital certificates
– The structure of the certification is standardized
– The format of the actual certificate file can take
many different forms
• There are many certificate file formats
– You can convert between many of the formats
– Use openssl or a similar application to view the
certificate contents
Certificate file formats
• 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
DER (Distinguished Encoding Rules)
• 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
PEM (Privacy-Enhanced Mail)
• 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
PKCS #12
• 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
CER (Certificate)
• 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
PKCS #7
• 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
Email 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
User certificates
• 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
Online and offline CAs
• Online Certificate Status Protocol
– Provides scalability for OCSP checks
• The CA is responsible for responding to all
client OCSP requests
– This does not 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
OCSP stapling
• 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
Pinning
• Single CA
– Everyone receives their certificates from one authority
• Hierarchical
– Single CA issues certs to intermediate CAs
• Mesh
– Cross-certifying CAs - Doesn’t scale well
• Web-of-trust
– Alternative to traditional PKI
• Mutual Authentication
– Server authenticates to the client and the client
authenticates to the server
PKI trust relationships
• 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
Key escrow
It’s all about the process
• Need clear process and procedures
– Keys are incredibly important pieces of
information
• You must be able to trust your 3rd-party
– Access to the keys is at the control of the
3rd-party
• Carefully controlled conditions
– Legal proceedings and court orders
It’s all about the process
• 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
Certificate chaining
