3.9 - Given a scenario, implement public key infrastructure.

Question 1

PKI

Answer 1

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

Question 2

Key management (lifecycle)

Answer 2

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”

Question 3

CA

Answer 3

Certificate authority

Question 4

Intermediate CA

Question 5

RA

Answer 5

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

Question 6

CRL

Answer 6

Certificate revocation list

Question 7

Certificate attributes

Answer 7

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)

Question 8

OCSP

Answer 8

Online Certificate Status Protocol

Question 9

CSR

Answer 9

Certificate signing request

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

Question 10

CN

Answer 10

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

Question 11

Subject alternative name

Answer 11

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

Question 12

Expiration

Question 13

Wildcard

Answer 13

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

Question 14

Code signing

Answer 14

*
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

Question 15

Self-signed (Types of certificates)

Answer 15

*
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

Question 16

Machine/computer (Types of certificates)

Answer 16

*
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

Question 17

Email

Answer 17

*
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

Question 18

User (Types of certificates)

Answer 18

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

Question 19

Root (Types of certificates)

Question 20

Domain validation

Question 21

Extended validation

Answer 21

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

Question 22

DER

Answer 22

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

Question 23

PEM

Answer 23

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

Question 24

PFX

Answer 24

Personal information exchange

Question 25

.cer

Answer 25

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

Question 26

P12

Answer 26

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

Question 27

P7B

Answer 27

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

Question 28

Online vs. offline CA

Answer 28

*
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

Question 29

Stapling (OCSP)

Answer 29

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

Question 30

Pinning

Answer 30

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

Question 31

Trust model

Question 32

Key escrow

Answer 32

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

Question 33

Certificate chaining

Answer 33

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