3.9 - Given a scenario, implement public key infrastructure. Flashcards by Isabelle S

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

How well did you know this?

Not at all

Perfectly

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”

How well did you know this?

Not at all

Perfectly

Certificate authority

How well did you know this?

Not at all

Perfectly

Intermediate CA

How well did you know this?

Not at all

Perfectly

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

How well did you know this?

Not at all

Perfectly

CRL

Certificate revocation list

How well did you know this?

Not at all

Perfectly

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)

How well did you know this?

Not at all

Perfectly

OCSP

Online Certificate Status Protocol

How well did you know this?

Not at all

Perfectly

CSR

Certificate signing request

Create a key pair, send the public key to the CA
to be signed

How well did you know this?

Not at all

Perfectly

Common Name
– The FQDN (Fully Qualified
– Domain Name) for the certificate

How well did you know this?

Not at all

Perfectly

Subject alternative name

– Extension to an X.509 certificate
– Lists additional identification information
– Allows a certificate to support many
different domains

How well did you know this?

Not at all

Perfectly

Expiration

How well did you know this?

Not at all

Perfectly

Wildcard

– Certificates are based on the name of the server
– A wildcard domain will apply to all server names
in a domain
– *.professormesser.com

How well did you know this?

Not at all

Perfectly

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

How well did you know this?

Not at all

Perfectly

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

How well did you know this?

Not at all

Perfectly

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