Title: INTROSEC / public_key_infra
Tags: public_key_infra TLS public_key_cert cryptographic_protocols certificate_transparency

Q: What are public key certificates used for?
A: A public key certivicate is a digital document used to prove the authenticity of a public key.

Q: Who issues public key certificates?
A: Certificate Authority (CA)

Q: What are common contents of a certificate?
A: - Public Key, parameters (e.g. RSA, modulus, etc.)
- Key Usage (encryption, signing, etc.)
- Subject (Information about the key owner)
- Subject Alternative Names (subdomains, etc.)
- Issuer (CA info)
- Signature (algorithms used, signature value)
- Validity (from / until)

Q: Describe the process of creating a certificate.
A: 1. Registration authority verfies the correctness of the data about the subject
2. Data in the certificate is signed with the CA's private key
3. The signature is entered into the certificate

Q: Whats the difference between a Registration Authority and a Certificate Authority?
A: The RA verifies identities and collects information, the CA issues the actual certificates and signs them with its private
key to ensure their authenticity.

Q: How can a Signature be validated?
A: With the public key of the issuing CA.

Q: When validating a certificate chain, where does the process stop?
A: When a root certificate is found.

Q: What is a self-signed certificate?
A: A self-signed certificate is a certificate, in which the subject and the issuer ar the same entity.

Q: What is a root certificate?
A: A root certificate is a self-signed certificate that identifies a root CA.

Q: What are the entities of a Public Key Infrastructure?
A: - Registration Authority
- Certification Authority
- Revocation lists
- Directory service
- Validation service
- Certificate policies

Q: What is the Registration Authority?
A: The registration authority is the entity of the PKI where persons and other subjects (e.g., subordinated CAs) can apply for certificates. The registration authority verifies the correctness of the data contained in the certificate request.

Q: What are the tasks of a CA?
A: - issues certificates for other subjects
- creating and managing certificates and (private) key of the PKI to which the CA belongs
- revocation of certificates before their expiry date

Q: What is a certificate revocation list?
A: A certificate revocation list (CRL) contains certificates that have been revoked before their
expiration.
Revocation is not reversible!

Q: What is the purpose of a CAs validation service?
A: Validation of certificates in real time (e.g. when revocation list is not updated regularly)

Q: What is a PKI certificate policy?
A: A certificate policy is a document that describes the different entities that compose a PKI, their roles, duties and working principles.
○ Description of the PKI’s architecture
○ Registration process and verification modalities
○ Key generation process
○ Implemented mechanisms to protect the PKI
○ Management of certificate revocation lists
○ Legal assurance
Purpose of the document is to allow outsiders to analyze the PKI’s trustworthiness

Q: What is Certificate Transparency?
A: Certificate Transparency is a standard to increase transparency of the certificate issuing process.
1. The domain owner files a request to obtain a valid certificate for their domain
2. The CA verifies that the owner is entitled to request the certificate and sends a pre-certificate (not valid!) to one or more logs
3. Each contacted log performs the following operations:
- verifies the certificate chain
- send a signed certificate timestam to the CA, a promise to add the pre-certifiacte to the log - within a certain timeframe
- adds the pre-certificate to the log
4. CA issues a certificate containing the same information as in the pre-certificate and the SCT issued by the logs

Q: What is an interleaving attack?
A: A message generated in a protocol session is exploited by the attacker to interact with another simultaneously ongoing session

Q: What is a reflection attack?
A: An interleaving attack where a message is sent back to its generator.

Q: How can reflection attack be avoided?
A: By inserting the originators identfier (or the intended reciever's one) into the message.

Q: What is a replay attack?
A: The same message is duplicated and sent several times to the intended recipient.

Q: How can replay attacks be avoided?
A: exploit a challenge-response nonce handshake:
- A nonce is a randomly generated number n, used in a single protocol session and then
discarded
- An authentication request is accepted only if no authentication request with the same
nonce has previously been accepted

Q: What securites does TLS guarantee?
A: - confidentiality (using semmetric encryption)
- integrity (using MACs)
- authentication (using asymmetric algorithms and certificates)

Q: Explain the TLS handshake.
A: 1. Negotiation of security parameters
2. Server authenitcation and key exchange
3. Client authentication (optional) and continuation of the key exchange
4. Completion of the handshake

Name all steps of a TLS Handshake.

Q: Describe the first step of the TLS Handshake.
A: ClientHello:
- Latest TLS version supported by client
- list of suported cipher suites and compression methods
- random byte sequence for computing master secret
ServerHello:
- Selected TLS version, cipher suite and compression methods to be used
- Random byte seequence for computing master secret
Connection is terminated, if:
- server does not support any of the TLS versions, cipher suites or compression methods suggested by client
- the server selects a cipher suite or TLS version not supported by client

Q: What are Cipher Suites?
A: A cipher suite defines a combination of 4 cryptographic mechanisms:
- The key exchange algorithm
- The authentication mechanism for clients and servers
- The symmetric encryption algorithm used to encrypt data
- A hash function used as basis for key-derivation

Q: What is forward secrecy?
A: Session keys of past encrypted communications cannot be compromised even if the attacker obtains the private key of the server; typically implemented with an ephemeral Diffie-Hellman key exchange.

Q: Describe the second step of the TLS Handshake.
A: - \((\text{Server}\rightarrow\text{Client}):\) [optional] Server's Certificate (if server authentication is enabled)
- \((\text{Server}\rightarrow\text{Client}):\) [optional] SeverKeyExchange (if additional information is needed to establish master secret, e.g. with ephemeral Diffie-Hellman)
- \((\text{Server}\rightarrow\text{Client}):\) ServerHelloDone

Q: What are the steps for validating the server's certificate in TLS?
A: For every certificate in the chain:
1. verify the signature of the certificate with the public key contained in the next certificate of the chain
2. check validity period
3. check if it has been revoked
4. verify that each certificate (except the first) can be used to sign certificates
For the first certificate in the chain:
- one of the domains in the certificate matches the domain the client wants to connect to

Q: Explain Step 3 of the TLS Handshake
A: \((\text{Client}\rightarrow\text{Server}):\) Client Key Exchange
Content depends on the selected key exchange mechanism.

Q: How is the premaster secret computed in TLS?
A: Depends on the key exchange.
Diffie-Hellman: Server can use the client's public value and its own private value to comptue the premaster secret (analogous for the client)j

Q: How is the master secret computed in TLS?
A: The master secret is  derived from the premaster secret and the randomly generated byte sequences of client and server.
All keys (encryption keys, keys for HMAC calculation, …) are derived from the master secret.

Q: Explain Step 4 of the TLS Handshake.
A: First the client, then the server send the following messages:
- ChangeCipherSpec: communicates that the negotiated algorithms and parameters will be used from now on
- Finished: first message encrypted with the negotiated symmetric algorithm, contains the HMAC (computed over all previous handshake messages)