Lesson Eleven

Cryptographic Attacks and Public Key Infrastructure

SierraTec Secure CISSP Certification Preparation Course

Lesson Overview

Lesson Ten established how cryptography protects information through:

• symmetric encryption;

• asymmetric cryptography;

• ntication codes;

• digital signatures;

• key establishment;

• key management;

• Hardware Security Modules;

• cryptographic agility;

• post-quantum cryptography.

Lesson Eleven examines the other side of cryptography:

How cryptographic trust fails.

An attacker does not always need to mathematically break AES, RSA, elliptic-curve cryptography, or another strong algorithm.

The attacker may instead exploit:

• weak keys;

• poor protocol design;

• incorrect implementations;

• exposed cryptographic keys;

• timing differences;

• hardware leakage;

• certificate-validation failures;

• compromised certificate authorities;

• credential hashes;

• Kerberos tickets;

• human trust;

• obsolete certificates;

• improper revocation.

This distinction is fundamental.

A mathematically strong algorithm can still participate in an insecure system.

The current CISSP examination places these concepts primarily under Domain 3, Objective 3.7 — Understand methods of cryptanalytic attacks. The current official outline specifically includes:

• brute force;

• ciphertext-only attacks;

• known-plaintext attacks;

• frequency analysis;

• chosen-ciphertext attacks;

• implementation attacks;

• side-channel attacks;

• fault injection;

• timing attacks;

• Man-in-the-Middle attacks;

• pass-the-hash;

• Kerberos exploitation;

• ransomware.

This lesson then expands Public Key Infrastructure, introduced in Lesson Ten.

PKI provides the trust structures necessary to answer questions such as:

• How do I know this public key actually belongs to the claimed organization?

• Who issued this digital certificate?

• Do I trust that issuer?

• Has the certificate expired?

• Has it been revoked?

• Is the certificate being used for an authorized purpose?

• Does the certificate chain terminate at a trusted root?

• What happens if a private key is compromised?

NIST describes X.509 public-key certificates as structures that associate an entity's identity with a public key and protect that binding using the issuing Certification Authority's digital signature.

The central Lesson Eleven question is:

How can attackers defeat cryptographic trust without necessarily breaking the underlying mathematics, and how does PKI establish, validate, maintain, and revoke trust in public keys?

CISSP Exam Objective Alignment

Learning Objectives

After completing this lesson, you should be able to:

1. Define cryptanalysis.

2. Distinguish cryptanalysis from cryptography.

3. Explain why strong algorithms can fail through weak implementation.

4. Explain brute-force attacks.

5. Explain how key size affects brute-force feasibility.

6. Define ciphertext-only attacks.

7. Define known-plaintext attacks.

8. Explain frequency analysis.

9. Define chosen-ciphertext attacks.

10. Explain chosen-plaintext attacks as a related concept.

11. Explain implementation attacks.

12. Define side-channel attacks.

13. Explain timing attacks.

14. Explain power and electromagnetic side-channel concepts.

15. Explain fault-injection attacks.

16. Explain Man-in-the-Middle attacks.

17. Explain why authentication is important during key establishment.

18. Explain pass-the-hash.

19. Explain why pass-the-hash does not require recovering the plaintext password.

20. Explain Kerberos exploitation at a CISSP level.

21. Recognize pass-the-ticket and forged-ticket concepts.

22. Explain ransomware's relationship to cryptographic mechanisms.

23. Explain collision and birthday-attack concepts.

24. Explain downgrade attacks.

25. Describe cryptographic attack mitigation strategies.

26. Define Public Key Infrastructure.

27. Explain the purpose of a digital certificate.

28. Explain X.509 certificate concepts.

29. Describe common certificate fields.

30. Explain the role of a Certificate Authority.

31. Explain the role of a Registration Authority.

32. Explain the role of a relying party.

33. Explain a root CA.

34. Explain an intermediate CA.

35. Explain certificate chains.

36. Define a trust anchor.

37. Explain certificate path validation.

38. Explain Certificate Signing Requests.

39. Describe certificate issuance.

40. Describe certificate renewal.

41. Explain certificate expiration.

42. Explain certificate revocation.

43. Explain Certificate Revocation Lists.

44. Explain Online Certificate Status Protocol.

45. Compare CRL and OCSP.

46. Explain why private-key compromise may require certificate revocation.

47. Explain certificate status checking.

48. Explain certificate extensions at a high level.

49. Explain Subject Alternative Name.

50. Explain Key Usage and Extended Key Usage.

51. Explain trust models.

52. Explain hierarchical PKI.

53. Explain cross-certification conceptually.

54. Explain certificate pinning.

55. Explain certificate-management lifecycle.

56. Explain why certificate inventories matter.

57. Analyze PKI failures in CISSP scenarios.

58. Recognize common cryptographic attack and PKI examination traps.

Part I — Cryptography Versus Cryptanalysis

1. Cryptography

Cryptography designs and uses mathematical mechanisms to protect:

• confidentiality;

• integrity;

• authenticity;

• nonrepudiation.

2. Cryptanalysis

Cryptanalysis studies methods for defeating, weakening, or analyzing cryptographic protections.

The attacker may attempt to:

• determine a cryptographic key;

• recover plaintext;

• forge a signature;

• manipulate protocol behavior;

• exploit implementation weaknesses;

• impersonate another party.

3. Cryptanalysis Does Not Always Mean Breaking Mathematics

Consider a system using a mathematically strong encryption algorithm.

An attacker could still succeed by:

• stealing the key;

• exploiting software;

• observing power consumption;

• tricking a user;

• manipulating certificate validation.

Therefore:

STRONG ALGORITHM

      │

      ▼

WEAK IMPLEMENTATION

      │

      ▼

INSECURE SYSTEM

4. Cryptographic Security Chain

ALGORITHM

    │

    ▼

KEY STRENGTH

    │

    ▼

RANDOMNESS

    │

    ▼

IMPLEMENTATION

    │

    ▼

PROTOCOL

    │

    ▼

KEY MANAGEMENT

    │

    ▼

IDENTITY / CERTIFICATE TRUST

An attacker generally needs to break only one sufficiently important link.

Part II — Brute-Force Attacks

5. What Is Brute Force?

A brute-force attack systematically attempts possible keys or credentials until the correct value is discovered.

Conceptually:

KEY 00000001 → Fail

KEY 00000002 → Fail

KEY 00000003 → Fail

        ...

KEY 91823745 → Success

6. Keyspace

Keyspace is the number of possible cryptographic keys.

For an ideal key of:

n bits

the theoretical keyspace is:

2ⁿ

possible values.

7. Key Length Matters

Increasing key length dramatically increases the search space.

Conceptually:

This is why sufficiently long cryptographic keys resist exhaustive search.

8. Brute Force Does Not Exploit Algorithm Weakness

Brute force may simply try:

Every possible key.

Therefore a strong algorithm can still be vulnerable if its key space is too small.

9. DES Example

DES historically used an effective 56-bit key.

Its keyspace eventually became computationally inadequate.

This is one reason modern systems use stronger alternatives such as AES.

10. Brute-Force Mitigations

Mitigation may involve:

• sufficiently strong keys;

• strong algorithms;

• rate limiting for password authentication;

• MFA;

• secure password hashing;

• lockout or adaptive controls where appropriate.

Part III — Ciphertext-Only Attacks

11. Ciphertext-Only Attack

In a ciphertext-only attack, the attacker possesses ciphertext but does not initially possess the associated plaintext.

Objective:

Infer plaintext or keying information from encrypted messages.

12. Ciphertext-Only Model

ATTACKER HAS:



CIPHERTEXT 1

CIPHERTEXT 2

CIPHERTEXT 3



BUT DOES NOT KNOW:



PLAINTEXT

KEY

13. Strong Modern Cryptography

A properly implemented modern cryptographic system should be designed to resist useful recovery even when attackers possess substantial ciphertext.

Remember:

Attackers can generally obtain ciphertext easily.

Ciphertext secrecy should not be required for cryptographic security.

Part IV — Frequency Analysis

14. What Is Frequency Analysis?

Frequency analysis examines recurring patterns within ciphertext and compares them with expected statistical characteristics of the underlying language or data.

15. Classical Example

In English:

• some letters occur more frequently than others;

• certain letter pairs occur frequently;

• common words create patterns.

A simple substitution cipher may preserve these statistical relationships.

16. Frequency Pattern

CIPHERTEXT SYMBOL



X = 13%

Q = 9%

L = 8%

...



Possible inference:



X may represent

a frequently used letter.

17. Modern Significance

Modern encryption algorithms are designed to eliminate exploitable statistical relationships between plaintext and ciphertext.

For CISSP:

Frequency analysis is strongly associated with attacks against classical substitution-style cryptography.

Part V — Known-Plaintext Attack

18. Known-Plaintext Attack

In a known-plaintext attack, the attacker knows:

• some plaintext;

• its corresponding ciphertext.

The attacker analyzes the relationship in an attempt to determine:

• the key;

• additional plaintext;

• cryptographic weakness.

19. Known-Plaintext Model

ATTACKER KNOWS:



PLAINTEXT A

     │

     ▼

CIPHERTEXT A



ATTACKER ALSO HAS:



CIPHERTEXT B



GOAL:



Recover key or

PLAINTEXT B

20. Where Known Plaintext May Come From

Predictable content may include:

• protocol headers;

• file formats;

• standard messages;

• known document templates.

Strong modern cryptography is expected to resist known-plaintext analysis.

Part VI — Chosen-Plaintext Attack

21. Chosen-Plaintext Concept

Although the current 3.7 objective explicitly names chosen ciphertext, chosen plaintext remains a useful related cryptanalytic concept.

In a chosen-plaintext attack, the attacker can choose plaintext values and observe corresponding ciphertext.

22. Chosen-Plaintext Model

ATTACKER CHOOSES:



"AAAAAA"

     │

     ▼

ENCRYPTION SYSTEM

     │

     ▼

CIPHERTEXT X

The attacker selects additional inputs and analyzes outputs.

23. Security Expectation

Modern cryptographic designs should remain secure even when attackers can obtain encryptions of chosen values under defined attack models.

Part VII — Chosen-Ciphertext Attacks

24. Chosen-Ciphertext Attack

A chosen-ciphertext attacker can submit selected ciphertext values to a system and obtain information associated with decryption behavior.

The attacker uses these results to learn about:

• plaintext;

• keys;

• cryptographic structure.

Chosen-ciphertext attacks are explicitly included in the current CISSP outline.

25. Concept

ATTACKER CREATES

CIPHERTEXT X

      │

      ▼

DECRYPTION FUNCTION

      │

      ▼

OBSERVABLE RESPONSE

      │

      ▼

ATTACKER LEARNS

ABOUT SYSTEM

The response does not always need to reveal the plaintext directly.

Different:

• errors;

• response times;

• success/failure indicators

can reveal useful information.

Part VIII — Implementation Attacks

26. Implementation Attack

Implementation attacks target mistakes or weaknesses in how cryptography is built rather than attacking the underlying mathematical algorithm directly.

27. Examples

Implementation weaknesses may include:

• predictable random numbers;

• hard-coded keys;

• key leakage;

• improper certificate validation;

• nonce reuse;

• unsafe error handling;

• weak cryptographic libraries.

28. Strong Algorithm, Weak Implementation

AES-256

  +

Predictable Key

  =

Weak Protection

Or:

STRONG PUBLIC-KEY CRYPTOGRAPHY

        +

CERTIFICATE VALIDATION DISABLED

        =

MITM RISK

29. CISSP Principle

When the question states:

“The cryptographic algorithm is mathematically strong, but the system was still compromised...”

look for:

• implementation;

• protocol;

• key-management;

• side-channel

weaknesses.

Part IX — Side-Channel Attacks

30. What Is a Side Channel?

A side channel is information leaked through the physical or operational behavior of a cryptographic system.

The attacker may observe:

• time;

• power usage;

• electromagnetic emissions;

• cache behavior;

• sound;

• heat.

31. Side-Channel Model

CRYPTOGRAPHIC DEVICE

        │

        ├── Correct cryptographic output

        │

        └── Unintended information leakage

                │

                ├── Timing

                ├── Power

                └── EM emissions

The attacker focuses on the unintended information.

32. Critical Distinction

Side-channel attacks often do not defeat the mathematics.

They defeat:

the physical or software implementation.

Part X — Timing Attacks

33. Timing Attack

A timing attack examines how long cryptographic operations take.

Small differences may reveal information concerning:

• key bits;

• comparisons;

• branches;

• processing state.

Timing attacks are explicitly identified in CISSP Objective 3.7.

34. Example

Suppose password comparison behaves like:

Character 1 correct?

   ↓

Character 2 correct?

   ↓

Character 3 correct?

and processing stops immediately when a mismatch occurs.

Different response times could leak how much of the value matched.

35. Timing Mitigation

Techniques may include:

• constant-time cryptographic operations;

• hardened libraries;

• reducing observable behavior.

Part XI — Power Analysis

36. Power Side Channel

Electronic components consume different amounts of power depending on the operations they perform.

A sophisticated attacker with appropriate physical access may analyze power-use patterns to infer:

• cryptographic operations;

• key-dependent behavior.

37. CISSP Perspective

You do not need to perform power-analysis mathematics.

Remember:

Power consumption can leak cryptographic information.

Part XII — Electromagnetic Side Channels

38. Electromagnetic Leakage

Electronic devices generate electromagnetic emissions.

Sophisticated analysis may reveal processing behavior.

This demonstrates why:

Cryptography must consider implementation and physical security as well as algorithms.

Part XIII — Fault Injection

39. Fault-Injection Attack

Fault injection intentionally causes abnormal behavior in a device during cryptographic processing.

Possible methods conceptually include manipulating:

• power;

• clocking;

• temperature;

• electromagnetic conditions.

The objective is to cause an error that reveals information or bypasses a control.

40. Concept

NORMAL CRYPTOGRAPHIC OPERATION

            │

      Attacker induces fault

            ▼

INCORRECT CALCULATION

            │

            ▼

OBSERVE OUTPUT DIFFERENCE

            │

            ▼

INFER SECRET INFORMATION

Fault injection is explicitly included in the current CISSP attack objective.

Part XIV — Man-in-the-Middle Attacks

41. Man-in-the-Middle

A Man-in-the-Middle, or MITM, attack occurs when an attacker places themselves between communicating parties and attempts to:

• observe;

• relay;

• modify;

• impersonate.

42. Intended Communication

ALICE ─────────────────────► BOB

43. MITM Communication

ALICE ─────► ATTACKER ─────► BOB

              │

              ▼

        Observe / Modify

Alice may believe she communicates directly with Bob.

Bob may believe he communicates directly with Alice.

44. Key Agreement Without Authentication

Suppose Alice and Bob perform unauthenticated key agreement.

An attacker may establish:

ALICE

   │

 Key A

   ▼

ATTACKER

   │

 Key B

   ▼

BOB

The attacker relays information while maintaining two separate protected sessions.

45. Important CISSP Lesson

Encryption without authentication can still permit impersonation.

That is why secure protocols combine:

• key establishment;

• identity authentication;

• certificate validation.

Part XV — Downgrade Attacks

46. Downgrade Attack

A downgrade attack attempts to force communicating systems to use:

• an older protocol;

• weaker algorithm;

• weaker configuration.

47. Concept

CLIENT SUPPORTS

STRONG + WEAK

     │

     ▼

ATTACKER INTERFERES

     │

     ▼

SYSTEM FALLS BACK

TO WEAK OPTION

48. Mitigation

Organizations should:

• disable obsolete protocols;

• remove weak cipher suites;

• enforce minimum cryptographic standards;

• maintain crypto-agility.

Part XVI — Hash Collisions

49. Collision Review

A collision occurs when two different inputs produce the same hash digest.

MESSAGE A ─► HASH ─► X



MESSAGE B ─► HASH ─► X



A ≠ B

Modern collision-resistant algorithms are designed to make deliberate collisions computationally infeasible.

Part XVII — Birthday Attack Concept

50. Birthday Principle

The birthday paradox illustrates that collisions can become statistically likely with far fewer samples than a simplistic assumption might suggest.

For a hash with an n-bit output, collision security is conceptually associated with approximately:

2ⁿ⁄²

work for an idealized birthday-style collision search.

51. Exam Principle

Do not confuse:

Preimage Resistance

Find an input matching a specific existing hash.

with:

Collision Resistance

Find any two different inputs with the same hash.

Part XVIII — Pass-the-Hash

52. What Is Pass-the-Hash?

Pass-the-hash is an authentication attack in which an attacker uses a captured password-derived hash representation as an authentication credential without first recovering the plaintext password.

This attack is explicitly identified in the current CISSP outline.

53. Important Distinction

Pass-the-hash does not necessarily require:

HASH

  ↓

CRACK PASSWORD

  ↓

LOGIN

Instead, in vulnerable authentication environments:

STEAL AUTHENTICATION HASH

        │

        ▼

REPLAY / USE HASH

        │

        ▼

AUTHENTICATE

54. Why It Matters

Security teams sometimes assume:

“The attacker doesn't know the password.”

But if the authentication protocol accepts a reusable credential representation, the attacker may not need the original password.

55. Mitigation Principles

Mitigations can include:

• protecting credential material;

• limiting administrative logons;

• privileged-access separation;

• MFA where applicable;

• credential-isolation capabilities;

• monitoring lateral movement.

Part XIX — Kerberos Exploitation

56. Kerberos Review

Kerberos uses tickets and trusted authentication infrastructure to allow users and services to authenticate without repeatedly sending passwords across the network.

Detailed Kerberos architecture belongs primarily in Domain 5.

Here the focus is:

How attackers abuse Kerberos trust.

57. Kerberos Attack Concepts

At a CISSP level, recognize that attackers may attempt to:

• steal tickets;

• replay usable authentication artifacts;

• forge tickets after compromising critical secrets;

• request or abuse service tickets;

• exploit weak service-account credentials.

58. Pass-the-Ticket

A stolen Kerberos ticket may sometimes be reused to impersonate an authenticated identity during its usable period.

Conceptually:

VALID USER

   │

   ▼

KERBEROS TICKET

   │

   └──► STOLEN

           │

           ▼

        ATTACKER

           │

           ▼

      IMPERSONATION

59. Forged-Ticket Risk

Compromise of critical Kerberos infrastructure or highly sensitive cryptographic secrets can allow significantly broader trust abuse.

For CISSP:

Protect domain authentication infrastructure as high-value security assets.

60. Kerberos Security Principle

Strong authentication protocols still depend on:

• protected keys;

• trusted servers;

• secure endpoints;

• time integrity;

• account security.

Part XX — Ransomware and Cryptography

61. Why Is Ransomware Listed Here?

Ransomware is not classical cryptanalysis.

However, modern ransomware frequently uses cryptographic mechanisms to deny legitimate organizations access to their own information.

The current CISSP outline explicitly includes ransomware under Objective 3.7.

62. Ransomware Flow

INITIAL COMPROMISE

       │

       ▼

PRIVILEGE / LATERAL MOVEMENT

       │

       ▼

BACKUP INTERFERENCE

       │

       ▼

FILES ENCRYPTED

       │

       ▼

ORGANIZATION LOSES ACCESS

       │

       ▼

EXTORTION

63. Security Objective

Ransomware primarily threatens:

Availability

It can also affect:

• confidentiality through data theft;

• integrity through modification/destruction.

64. Ransomware Mitigation

Defense in depth may include:

• MFA;

• least privilege;

• endpoint protection;

• segmentation;

• monitoring;

• vulnerability management;

• protected backups;

• incident response.

Part XXI — Attack Comparison Table

65. Cryptographic Attack Matrix

Part XXII — Cryptographic Attack Defense Model

66. SierraTec Secure HARDEN Model

Use the HARDEN model when evaluating cryptographic attacks.

H — Harden Algorithms

Use current, approved cryptography.

A — Authenticate Communication

Prevent impersonation and MITM.

R — Restrict Key Access

Protect keys, hashes, and authentication artifacts.

D — Defend Implementations

Use hardened libraries and secure coding.

E — Examine Side Channels

Consider hardware and implementation leakage.

N — Notice and Monitor

Detect abnormal cryptographic and authentication behavior.

67. HARDEN Diagram

H

HARDEN ALGORITHMS

     │

     ▼

A

AUTHENTICATE

     │

     ▼

R

RESTRICT KEY ACCESS

     │

     ▼

D

DEFEND IMPLEMENTATION

     │

     ▼

E

EXAMINE SIDE CHANNELS

     │

     ▼

N

NOTICE & MONITOR

Part XXIII — Public Key Infrastructure

68. Why PKI Exists

Public-key cryptography creates an important challenge:

How do you know whose public key you have?

An attacker can generate a valid cryptographic key pair.

The mathematics does not automatically tell you whether that key belongs to:

• your bank;

• your employer;

• an attacker.

PKI establishes trusted relationships between:

• identities;

• public keys;

• certificate issuers;

• relying parties.

69. PKI Definition

Public Key Infrastructure is an ecosystem of:

• people;

• technologies;

• policies;

• procedures;

• cryptographic keys;

• certificates;

• trust relationships

used to issue, manage, validate, and revoke public-key credentials.

NIST describes large PKIs as including certification authorities, registration authorities, certificate holders, relying clients, and repositories supporting X.509 certificates and certificate revocation.

70. PKI Trust Problem

Without trusted binding:

WEBSITE SAYS:



"I AM SIERRATEC BANK"



Public Key:

XYZ123



Question:



How do you know?

PKI answers using a certificate signed by an issuer the relying party trusts.

Part XXIV — Digital Certificates

71. Digital Certificate

A digital certificate binds:

• an identity or entity;

• to a public key;

• under an issuer's digital signature.

NIST defines an X.509 public-key certificate as containing an entity's public key and identifying information, protected against forgery by the issuing CA's digital signature.

72. Simplified Certificate

┌─────────────────────────────────┐

│       DIGITAL CERTIFICATE       │

│                                 │

│ Subject: www.example.com        │

│ Issuer: Intermediate CA         │

│ Serial Number: 123456           │

│ Valid From: ...                 │

│ Valid Until: ...                │

│ Public Key: ...                 │

│ Key Usage: ...                  │

│ Subject Alt Names: ...          │

│ Issuer Signature: ...           │

└─────────────────────────────────┘

73. Certificate Does Not Contain the Subject's Private Key

Critical exam concept:

CERTIFICATE

   │

   ├── Public key

   └── Identity information



PRIVATE KEY

   │

   └── Must be separately protected

Part XXV — X.509

74. X.509

X.509 is a widely used certificate standard defining structures for public-key certificates.

NIST PKI guidance explicitly references X.509 certificates and certificate revocation lists.

75. Common X.509 Certificate Information

Common fields can include:

• version;

• serial number;

• issuer;

• subject;

• validity period;

• public-key information;

• signature algorithm;

• extensions;

• CA signature.

76. Serial Number

The serial number uniquely identifies a certificate within the issuing CA's namespace.

This becomes important when identifying a certificate for revocation.

77. Issuer

The issuer identifies the CA that signed the certificate.

78. Subject

The subject identifies the entity associated with the public key.

79. Validity Period

Certificates normally contain:

• Not Before;

• Not After

times.

A certificate outside its validity period should normally not be accepted as currently valid.

80. Subject Public Key Information

This field includes the public-key algorithm and public-key material associated with the certificate's subject.

Part XXVI — Subject Alternative Name

81. SAN

Subject Alternative Name allows a certificate to identify additional names or identities.

For web certificates, SAN entries commonly contain the DNS names for which the certificate is valid.

82. Example

Certificate SAN:

DNS:

www.sierratec-example.com



DNS:

portal.sierratec-example.com

The certificate is intended to cover the identities represented by those authorized names.

Part XXVII — Key Usage

83. Key Usage Extension

Key Usage can restrict or indicate permitted cryptographic uses of the certificate's key.

Examples conceptually include:

• digital signature;

• key encipherment;

• certificate signing.

84. Extended Key Usage

Extended Key Usage can identify more specific purposes, such as:

• server authentication;

• client authentication;

• code signing;

• email protection.

85. CISSP Principle

A certificate's key should be used consistently with:

• certificate purpose;

• policy;

• extensions.

Part XXVIII — Certificate Authority

86. What Is a CA?

A Certification Authority or Certificate Authority:

• issues certificates;

• digitally signs certificates;

• may revoke certificates;

• participates in trust relationships.

NIST PKI guidance describes CAs as entities that issue and revoke certificates.

87. CA Signature

A CA signs the certificate using the CA's private signing key.

The relying party can verify that signature using the CA's public key.

88. CA Trust

The CA's signature answers:

Did this trusted issuer certify this public-key identity binding?

It does not mean the subject can never be compromised.

Part XXIX — Registration Authority

89. Registration Authority

A Registration Authority, or RA, performs identity-registration or validation responsibilities on behalf of or in coordination with a CA.

NIST's PKI specification describes registration authorities as entities that vouch for the binding between public keys and certificate-holder identities or attributes.

90. CA Versus RA

Exact architecture varies.

Part XXX — Certificate Holder

91. Certificate Holder

The certificate holder is the entity to which the certificate was issued.

Examples:

• user;

• server;

• device;

• application.

Part XXXI — Relying Party

92. Relying Party

A relying party is an entity that uses the certificate and relies on its validity to make a trust decision.

Example:

A browser validating a website certificate acts as a relying party.

93. Relying Party Responsibilities

The relying party may need to evaluate:

• certificate signature;

• certificate chain;

• trusted root;

• validity period;

• certificate name;

• permitted key usage;

• revocation status.

Part XXXII — PKI Roles Diagram

94. PKI Ecosystem

           REGISTRATION AUTHORITY

                    │

             Validates identity

                    │

                    ▼

             CERTIFICATE AUTHORITY

                    │

            Issues certificate

                    │

                    ▼

            CERTIFICATE HOLDER

                    │

          Presents certificate

                    │

                    ▼

               RELYING PARTY

                    │

          Validates certificate

                    │

                    ▼

             TRUST DECISION

Part XXXIII — Root Certificate Authority

95. Root CA

A root CA exists at the top of a hierarchical PKI trust structure.

The root's certificate is generally:

Self-signed

because there is no higher CA in that hierarchy to sign it.

96. Why Trust a Self-Signed Root?

The root is trusted because its certificate/public key is distributed or installed as a:

Trust Anchor

not because self-signing itself proves trustworthiness.

97. Trust Anchor

NIST key-management guidance describes a trust anchor as an authority or public key for which trust is assumed rather than derived from another certificate in the path.

Part XXXIV — Intermediate CAs

98. Intermediate CA

Intermediate CAs operate beneath a root CA.

ROOT CA

   │

   ▼

INTERMEDIATE CA

   │

   ▼

END-ENTITY CERTIFICATE

99. Why Use Intermediates?

Using intermediates can:

• limit exposure of the root key;

• allow policy separation;

• support multiple issuing authorities;

• simplify lifecycle management.

Root private keys are commonly given especially strong protection because compromise could affect trust across the hierarchy.

Part XXXV — Certificate Chain

100. Certification Path

A certificate chain or certification path links an end-entity certificate through issuing authorities to a trusted anchor.

NIST describes a certification path as beginning at a trust anchor, containing zero or more intermediate certificates, and ending with the certificate containing the user's public key.

101. Chain Diagram

TRUSTED ROOT CA

       │

       │ signs

       ▼

INTERMEDIATE CA

       │

       │ signs

       ▼

SERVER CERTIFICATE

102. Chain Validation

The relying party evaluates the path to determine whether trust can be established.

NIST guidance notes that path validation should examine the certificates in the chain, including revocation status, policy considerations, and suitability of public keys for their intended use.

Part XXXVI — Certificate Path Validation

103. Validation Questions

A relying system may ask:

1. Is the issuer's signature valid?

2. Does the chain reach a trusted root?

3. Is the certificate currently within its validity period?

4. Has a certificate been revoked?

5. Does the certificate identify the expected entity?

6. Is its key usage appropriate?

7. Do policy constraints permit the use?

104. Validation Flow

END-ENTITY CERTIFICATE

        │

        ▼

VERIFY SIGNATURE

        │

        ▼

CHECK INTERMEDIATE

        │

        ▼

BUILD CHAIN

        │

        ▼

TRUSTED ROOT?

        │

        ▼

CHECK VALIDITY

        │

        ▼

CHECK NAME / USAGE

        │

        ▼

CHECK REVOCATION

        │

        ▼

TRUST DECISION

Part XXXVII — Certificate Signing Request

105. CSR

A Certificate Signing Request is a request submitted to obtain a certificate.

It normally contains:

• public-key information;

• identity/name information;

• requested certificate attributes;

• proof associated with the corresponding private key.

106. Key Principle

The private key should normally be generated and protected by the appropriate subject/system rather than casually transmitted to the CA.

107. CSR Lifecycle

GENERATE KEY PAIR

       │

       ▼

PROTECT PRIVATE KEY

       │

       ▼

CREATE CSR

       │

       ▼

IDENTITY VALIDATION

       │

       ▼

CA APPROVAL

       │

       ▼

CERTIFICATE ISSUED

Part XXXVIII — Certificate Issuance

108. Issuance Process

A simplified PKI issuance process is:

1. Generate key pair.

2. Request certificate.

3. Validate identity.

4. CA evaluates request.

5. CA creates certificate.

6. CA signs certificate.

7. Certificate is distributed.

8. Relying parties validate it.

Part XXXIX — Certificate Lifecycle

109. Certificate Lifecycle

IDENTITY / SYSTEM NEED

       │

       ▼

KEY GENERATION

       │

       ▼

REGISTRATION

       │

       ▼

CERTIFICATE ISSUANCE

       │

       ▼

DEPLOYMENT

       │

       ▼

ACTIVE USE

       │

       ▼

MONITORING

       │

       ▼

RENEW / REKEY

       │

       ▼

REVOKE OR EXPIRE

       │

       ▼

RETIRE

110. Why Lifecycle Management Matters

A certificate may become unsafe because:

• private key is compromised;

• owner changes;

• hostname changes;

• organization relationship ends;

• certificate expires;

• algorithm becomes unacceptable.

Part XL — Expiration

111. Certificate Expiration

Certificates have finite validity periods.

Expiration is expected lifecycle behavior.

112. Operational Risk

Failure to renew certificates can cause:

• website failures;

• API failures;

• service outages;

• broken authentication.

Therefore certificate management affects both:

Security + Availability

Part XLI — Revocation

113. What Is Certificate Revocation?

Revocation invalidates a certificate before its normal expiration.

NIST defines revocation as ending the binding or operational trust associated with a certificate/key before its ordinary end of use.

114. Revocation Reasons

Examples include:

• private-key compromise;

• CA compromise;

• certificate misuse;

• ownership changes;

• authorization changes;

• employee departure.

115. Key Compromise

If the private key corresponding to a certificate is compromised:

The certificate's identity-to-key binding can no longer safely establish exclusive control.

NIST key-management guidance states that certificates associated with compromised private keys should be revoked promptly.

Part XLII — Certificate Revocation Lists

116. CRL

A Certificate Revocation List is a digitally signed list of revoked, unexpired certificates issued by a CA.

NIST defines CRLs as lists of revoked public-key certificates created and digitally signed by a Certification Authority.

117. CRL Concept

CERTIFICATE AUTHORITY

        │

        ▼

┌────────────────────────┐

│ REVOCATION LIST        │

│                        │

│ Serial 1038 — revoked  │

│ Serial 2044 — revoked  │

│ Serial 8871 — revoked  │

└────────────────────────┘

        │

        ▼

RELYING PARTY CHECKS LIST

118. CRL Limitation

CRLs are periodic.

A newly revoked certificate may not appear until updated status information is published.

This creates potential:

Revocation latency

119. Large CRLs

Large PKIs may have sizable revocation lists.

Relying parties may need to:

• download;

• cache;

• update

these lists.

Part XLIII — Online Certificate Status Protocol

120. OCSP

Online Certificate Status Protocol provides certificate-status information through an online responder.

NIST describes an OCSP responder as a trusted service that provides signed status information for a certificate in response to relying-party requests.

121. OCSP Flow

RELYING PARTY

      │

      │ "What is the status

      │  of certificate 123?"

      ▼

OCSP RESPONDER

      │

      ▼

SIGNED STATUS RESPONSE

      │

      ▼

GOOD / REVOKED / UNKNOWN

122. OCSP Benefit

OCSP can provide more targeted status information than downloading an entire revocation list.

Part XLIV — CRL Versus OCSP

123. Comparison

Both support revocation/status management.

NIST key-management guidance recognizes both CRLs and OCSP as standard mechanisms for checking certificate status.

Part XLV — OCSP Stapling

124. Concept

With OCSP stapling, a server may obtain a signed OCSP response and present it to the client during the connection process.

This can reduce the need for each client to query the OCSP responder directly.

At CISSP level, understand:

The server provides recent signed certificate-status evidence.

Part XLVI — Soft Fail and Hard Fail

125. Revocation Service Unavailable

Suppose a client cannot reach:

• CRL distribution point;

• OCSP responder.

What should it do?

126. Soft-Fail Concept

Continue despite inability to obtain revocation status.

Benefit:

• availability.

Risk:

• possibly accepting revoked credentials.

127. Hard-Fail Concept

Reject trust when revocation status cannot be established.

Benefit:

• stronger revocation enforcement.

Risk:

• availability impact.

128. CISSP Mindset

There is no universal answer.

The design should consider:

• security sensitivity;

• availability requirements;

• risk.

Part XLVII — PKI Repositories

129. Repository

PKIs may use repositories to distribute:

• certificates;

• CRLs;

• related PKI information.

NIST's PKI architecture includes repositories as one of its major components.

Part XLVIII — Hierarchical Trust Model

130. Hierarchical PKI

A hierarchical model places a root at the top.

              ROOT CA

             /       \

            ▼         ▼

        INT CA A    INT CA B

         /   \        /   \

        ▼     ▼      ▼     ▼

      Cert  Cert   Cert   Cert

Trust flows through the certification hierarchy.

131. Advantages

Hierarchy can provide:

• centralized trust;

• clear certification paths;

• scalable organization.

Part XLIX — Mesh / Network Trust

132. Network Trust Model

In a nonhierarchical model, certification authorities may establish trust relationships with one another.

NIST's PKI guidance historically recognizes both hierarchical and network trust arrangements.

133. Complexity

Network or cross-certified arrangements can provide flexibility but may increase:

• path complexity;

• policy complexity;

• trust-management difficulty.

Part L — Cross-Certification

134. Cross-Certification

Cross-certification allows CAs from different PKIs or domains to establish trust relationships.

Conceptually:

PKI A                       PKI B



CA A ◄──────────────────► CA B

This can allow relying parties to build trusted paths across previously separate infrastructures.

Part LI — Bridge CA Concept

135. Bridge Architecture

A bridge CA can facilitate trust between multiple PKI domains without necessarily becoming the hierarchical parent of each domain.

At CISSP level, associate bridge architectures with:

• connecting separate PKI trust domains;

• more complex trust relationships.

Part LII — Certificate Pinning

136. Certificate Pinning

Certificate pinning restricts trust so a client expects:

• a specific certificate;

• public key;

• or narrowly defined trust relationship

rather than relying only on the general CA trust store.

137. Benefit

Pinning can reduce certain risks from:

• unexpected certificates;

• compromised or mistakenly trusted CAs.

138. Limitation

Pinning can create operational problems when:

• certificates rotate;

• keys change;

• recovery is poorly planned.

Therefore:

Stronger trust restriction can increase management complexity.

Part LIII — Certificate Transparency

139. Concept

Certificate Transparency mechanisms provide public logging of certificate issuance to increase visibility into unexpected or unauthorized certificates.

At a high level:

Organizations can detect certificates issued for their names that they did not expect.

Part LIV — Private CA Versus Public CA

140. Public CA

A public CA issues certificates intended for broad public trust through widely distributed trust stores.

141. Private CA

An organization may operate internal CAs for:

• employees;

• devices;

• servers;

• enterprise applications.

Trust exists because organizational systems explicitly trust the internal root.

142. Exam Principle

Public CA does not automatically mean:

More secure.

Private CA does not automatically mean:

More trusted.

Trust depends on:

• governance;

• policy;

• key protection;

• relying-party trust configuration.

Part LV — CA Private-Key Protection

143. Why CA Keys Matter

A CA's private signing key can issue certificates trusted by relying parties.

Compromise could allow attackers to create apparently legitimate certificates.

144. CA Key Protection

Controls may include:

• HSMs;

• dual control;

• split knowledge;

• physical protection;

• strict administrative access;

• offline root systems.

145. CA Compromise

CA PRIVATE KEY

COMPROMISED

      │

      ▼

FALSE CERTIFICATES

CAN BE SIGNED

      │

      ▼

TRUST INFRASTRUCTURE

AT RISK

This can have consequences far beyond a single end-user certificate.

Part LVI — Offline Root CAs

146. Root Protection

Organizations commonly minimize root CA exposure by keeping high-value root-signing environments offline or rarely online where operationally appropriate.

Intermediate CAs handle routine issuance.

147. Concept

ROOT CA

OFFLINE / HIGHLY PROTECTED

      │

      │ signs

      ▼

INTERMEDIATE CA

ONLINE / ISSUING

      │

      ▼

END-ENTITY CERTIFICATES

Part LVII — PKI Policy

148. Certificate Policy

PKI governance defines:

• how identity is verified;

• who may receive certificates;

• acceptable key algorithms;

• certificate validity;

• revocation conditions;

• audit requirements.

Technology alone does not create trustworthy PKI.

Part LVIII — Certificate Practices

149. Operational Practices

PKI documentation may describe how the CA actually implements:

• registration;

• issuance;

• revocation;

• key protection;

• auditing.

For CISSP:

Trust requires both technical cryptography and governance.

Part LIX — Certificate Renewal and Rekey

150. Renewal

Renewal extends or replaces certificate validity according to policy.

151. Rekey

Rekey involves generating or adopting new cryptographic keying material.

Renewal and rekeying are related but not always identical.

Part LX — Certificate Inventory

152. Why Inventory Matters

Organizations may operate:

• thousands;

• tens of thousands;

• millions

of certificates.

Without inventory:

• certificates expire unexpectedly;

• obsolete algorithms remain;

• unused certificates persist;

• compromised certificates may be missed.

153. Certificate Inventory Fields

A useful inventory may track:

• certificate owner;

• subject;

• issuer;

• serial number;

• expiration;

• algorithm;

• key size;

• system location;

• renewal status;

• revocation status.

Part LXI — Certificate Automation

154. Why Automate?

Large certificate environments benefit from automation for:

• discovery;

• issuance;

• renewal;

• deployment;

• expiration monitoring.

Automation should still be governed and secured.

Part LXII — PKI and Post-Quantum Migration

155. Quantum Impact on PKI

PKI commonly relies on public-key digital signatures.

Post-quantum transition therefore affects:

• CA signing algorithms;

• end-entity certificates;

• certificate-validation software;

• protocols;

• HSMs;

• applications.

156. PKI Crypto Agility

A future-ready PKI should support cryptographic transition without requiring complete infrastructure replacement.

Lesson Ten's crypto-agility principle therefore applies directly to PKI.

Part LXIII — Complete PKI Lifecycle Diagram

157. Lifecycle

BUSINESS / IDENTITY NEED

        │

        ▼

KEY PAIR GENERATED

        │

        ▼

CSR CREATED

        │

        ▼

RA / IDENTITY VALIDATION

        │

        ▼

CA ISSUES CERTIFICATE

        │

        ▼

CERTIFICATE DEPLOYED

        │

        ▼

RELYING PARTIES VALIDATE

        │

        ▼

MONITOR

        │

    ┌───┴────────────┐

    ▼                ▼

 RENEW             REVOKE

    │                │

    ▼                ▼

 REKEY            CRL / OCSP

    │                │

    └──────┬─────────┘

           ▼

         RETIRE

Part LXIV — Worked Cryptanalytic Scenarios

158. Scenario 1 — Exhaustive Key Search

An attacker systematically attempts every possible key for an obsolete encryption system.

Which attack is occurring?

A. Brute force
B. MITM
C. Timing
D. Pass-the-hash

Correct Answer

A

159. Scenario 2 — Known Data

An attacker possesses both several plaintext messages and their corresponding encrypted versions and analyzes them to infer cryptographic information.

Which attack BEST describes this?

A. Known-plaintext
B. Ciphertext-only
C. Ransomware
D. Fault injection

Correct Answer

A

160. Scenario 3 — Patterns

An attacker analyzes letter and symbol frequencies in an old substitution cipher.

Which attack is MOST directly demonstrated?

A. Frequency analysis
B. MITM
C. Brute-force authentication
D. Certificate pinning

Correct Answer

A

161. Scenario 4 — Decryption Oracle

An attacker submits modified ciphertext to a system and analyzes differences in the system's decryption responses.

Which attack category BEST fits?

A. Chosen-ciphertext
B. Known plaintext
C. Ransomware
D. Pass-the-hash

Correct Answer

A

162. Scenario 5 — Response Time

A cryptographic operation takes slightly different amounts of time depending on secret-key values.

What is the PRIMARY risk?

A. Timing attack
B. Brute force only
C. Data remanence
D. Certificate expiration

Correct Answer

A

163. Scenario 6 — Power Measurements

A physically proximate attacker measures the power consumption of a cryptographic device.

What category BEST describes the attack?

A. Side channel
B. Ciphertext only
C. Ransomware
D. Data masking

Correct Answer

A

164. Scenario 7 — Deliberate Device Error

An attacker manipulates electrical conditions to cause abnormal cryptographic calculations and analyzes the faulty result.

Which attack is MOST directly represented?

A. Fault injection
B. Hash collision
C. Data retention
D. Pass-the-hash

Correct Answer

A

165. Scenario 8 — Key Agreement Interception

Two systems perform key agreement but do not authenticate each other's identity.

An attacker inserts itself between them.

Which attack is MOST relevant?

A. MITM
B. Ransomware
C. Brute force only
D. Frequency analysis

Correct Answer

A

Part LXV — Pass-the-Hash and Kerberos Scenarios

166. Scenario 9 — Credential Hash

An attacker obtains a reusable authentication hash and successfully authenticates without determining the user's plaintext password.

What attack occurred?

A. Pass-the-hash
B. Password cracking only
C. Digital signature forgery
D. Certificate revocation

Correct Answer

A

167. Scenario 10 — Stolen Kerberos Ticket

An attacker steals a valid Kerberos authentication ticket and uses it to impersonate a user.

Which general attack concept is demonstrated?

A. Kerberos ticket exploitation
B. Data remanence
C. ECB pattern attack
D. Key escrow

Correct Answer

A

168. Scenario 11 — Ransomware

Malware encrypts production files and demands payment for restoration.

Which security property is MOST immediately affected?

A. Availability
B. Confidentiality only
C. Nonrepudiation
D. Authentication only

Correct Answer

A

Part LXVI — PKI Scenarios

169. Scenario 12 — Certificate Identity

A browser receives a website's public key.

What mechanism helps establish that the public key belongs to the claimed website?

A. Digitally signed certificate
B. Plain hash
C. Data masking
D. RAID

Correct Answer

A

170. Scenario 13 — Root CA

A certificate chain ends at a root certificate already trusted by the endpoint.

What is the root acting as?

A. Trust anchor
B. Symmetric session key
C. Hash salt
D. Data owner

Correct Answer

A

171. Scenario 14 — Registration

An organization separates identity-verification responsibilities from certificate-signing operations.

Which PKI component is MOST associated with identity-validation support?

A. Registration Authority
B. OCSP responder
C. Relying party
D. End user only

Correct Answer

A

172. Scenario 15 — Compromised Private Key

A web server's private key has been stolen.

What should the organization do FIRST after confirming the compromise?

A. Initiate certificate/key compromise procedures, including revocation and replacement.

B. Wait for certificate expiration.

C. Publish the private key.

D. Continue normal operation indefinitely.

Correct Answer

A

NIST guidance states that certificates corresponding to compromised private keys should be revoked promptly.

173. Scenario 16 — Revocation List

A relying party downloads a digitally signed list identifying revoked certificates.

What mechanism is being used?

A. CRL
B. HMAC
C. AES-GCM
D. Key escrow

Correct Answer

A

174. Scenario 17 — Online Status

A client queries a trusted online service to determine the current status of one certificate.

Which mechanism is being used?

A. OCSP
B. CBC
C. HSM
D. Tokenization

Correct Answer

A

175. Scenario 18 — Expired Certificate

A production API fails because its certificate's validity period ended.

Which security property may be most directly affected operationally?

A. Availability
B. Confidentiality automatically
C. Data classification
D. Physical safety

Correct Answer

A

Part LXVII — Certificate Chain Scenario

176. Scenario

A server certificate was signed by Intermediate CA B.

Intermediate CA B was signed by Root CA A.

The client trusts Root CA A.

Conceptually:

ROOT CA A

    │

    ▼

INTERMEDIATE CA B

    │

    ▼

SERVER CERTIFICATE

If all certificate signatures, validity, identity, usage, and status checks succeed, the client may establish a trusted certification path.

Part LXVIII — PKI Failure Examples

177. Failure: Wrong Name

Certificate:

www.bank-example.com

User visits:

secure.otherbank.com

The certificate should not be treated as valid for an unrelated name merely because a trusted CA issued it.

178. Failure: Expiration

Certificate expired yesterday.

Its signature may still mathematically verify.

But:

Validity policy fails.

179. Failure: Revocation

Certificate remains within its original validity period.

However:

its private key was compromised.

Revocation status matters.

180. Failure: Untrusted Root

Every signature in a chain may be cryptographically correct.

But if the chain ends at a root the relying party does not trust:

The required trust relationship has not been established.

181. Failure: Key Usage

A certificate's key may be valid cryptographically but not permitted for the intended use under its certificate constraints.

Part LXIX — Common Cryptanalytic Exam Traps

182. Trap — Brute Force Means Exploiting an Algorithm Flaw

Not necessarily.

Brute force may simply test possible keys until one works.

183. Trap — Side Channel Breaks the Cipher Mathematics

Usually, the side channel exploits:

Information leaked by implementation.

184. Trap — Timing Attack Is Brute Force

No.

Timing attacks analyze computational timing differences.

185. Trap — MITM Means Encryption Is Missing

MITM can occur even when encryption is present if:

• authentication;

• certificate validation;

• trust establishment

is defective.

186. Trap — Pass-the-Hash Means Cracking the Hash

No.

The defining feature is that the captured hash itself is used as a credential in environments where such reuse is possible.

187. Trap — Kerberos Means Passwords Cannot Be Attacked

Kerberos reduces some password exposure but depends on:

• credentials;

• keys;

• tickets;

• trusted infrastructure.

188. Trap — Ransomware Is Only a Confidentiality Problem

Its most obvious immediate objective is often:

Availability

Data theft may add confidentiality impact.

Part LXX — Common PKI Exam Traps

189. Trap — Certificate Contains the Private Key

No.

A standard public-key certificate contains:

Public-key information

The private key must remain separately protected.

190. Trap — Root Is Trusted Because It Is Self-Signed

No.

The root is trusted because it is configured or distributed as a:

Trust Anchor.

191. Trap — CA Verifies Every Connection

The CA issues and manages certificates.

The relying party performs certificate validation when deciding whether to trust a presented certificate.

192. Trap — CRL and OCSP Are the Same

CRL:

Published list.

OCSP:

Online status response.

193. Trap — Certificate Expiration and Revocation Are Identical

Expiration:

Normal validity period ended.

Revocation:

Trust terminated before normal expiration.

194. Trap — Valid Signature Means Valid Certificate

Not enough.

Also consider:

• path;

• trusted root;

• time;

• identity;

• usage;

• revocation.

195. Trap — Public CA Automatically Means Trusted Everywhere

Trust depends on the relying party's trust store and policy.

196. Trap — Private CA Is Insecure

A properly governed private CA can provide strong enterprise trust.

197. Trap — Certificate Renewal Fixes a Compromised Private Key Automatically

If compromise occurred, proper:

• revocation;

• rekeying;

• investigation

may be required.

198. Trap — Certificate Pinning Has No Operational Cost

Pinning may improve trust restriction but complicate:

• rotation;

• replacement;

• disaster recovery.

Part LXXI — SierraTec Secure PKI TRUST Model

199. PKI TRUST

Use the TRUST model for certificate questions.

T — Trace the Chain

Does the certificate lead to a trusted anchor?

R — Review Revocation

Has any relevant certificate been revoked?

U — Understand Usage

Is the certificate authorized for this purpose?

S — Subject and Validity

Does the identity match, and is the certificate currently valid?

T — Trust the Key Only After Validation

Do not trust merely because a certificate exists.

200. TRUST Diagram

T

TRACE CHAIN

    │

    ▼

R

REVIEW REVOCATION

    │

    ▼

U

UNDERSTAND USAGE

    │

    ▼

S

SUBJECT + VALIDITY

    │

    ▼

T

TRUST AFTER VALIDATION

Part LXXII — Knowledge Check

201. Knowledge Check

Question 1

Which attack systematically attempts possible cryptographic keys?

A. Brute force
B. MITM
C. Side channel
D. Ransomware

Correct Answer

A

Question 2

Which attack assumes the attacker possesses only encrypted information?

A. Ciphertext-only
B. Known-plaintext
C. Fault injection
D. Pass-the-hash

Correct Answer

A

Question 3

Which attack uses known plaintext and its corresponding ciphertext?

A. Known-plaintext
B. Ciphertext-only
C. Ransomware
D. OCSP

Correct Answer

A

Question 4

Which technique is especially useful against classical substitution ciphers?

A. Frequency analysis
B. Key escrow
C. Certificate pinning
D. GCM

Correct Answer

A

Question 5

Which attack allows the attacker to select ciphertext inputs and analyze decryption behavior?

A. Chosen-ciphertext
B. Known plaintext
C. Pass-the-ticket
D. Brute force only

Correct Answer

A

Question 6

Which attack exploits information leaked by how a system operates physically or computationally?

A. Side channel
B. Ciphertext only
C. Ransomware
D. Data classification

Correct Answer

A

Question 7

Which side-channel attack measures processing duration?

A. Timing attack
B. Brute force
C. Frequency analysis
D. Ransomware

Correct Answer

A

Question 8

Which attack deliberately causes computation errors in a cryptographic device?

A. Fault injection
B. Known plaintext
C. CRL attack
D. Key escrow

Correct Answer

A

Question 9

What is the primary risk of unauthenticated key agreement?

A. MITM
B. Data remanence
C. Copyright violation
D. Storage limitation

Correct Answer

A

Question 10

Which attack can authenticate using a reusable password hash without first recovering the plaintext password?

A. Pass-the-hash
B. Frequency analysis
C. Side channel
D. Key wrapping

Correct Answer

A

Question 11

Which authentication system uses ticket-based trust?

A. Kerberos
B. AES
C. SHA-3
D. GCM

Correct Answer

A

Question 12

What security objective is most immediately affected when ransomware encrypts business files?

A. Availability
B. Authentication
C. Nonrepudiation
D. Data classification

Correct Answer

A

Question 13

What is PKI primarily designed to manage?

A. Public-key identities and trust relationships
B. Symmetric encryption only
C. Disk storage
D. Physical locks

Correct Answer

A

Question 14

What does a digital certificate bind?

A. Identity information to a public key
B. Password to a private key
C. Firewall rule to network port
D. Disk sector to file

Correct Answer

A

Question 15

Who digitally signs an issued certificate?

A. Certificate Authority
B. Data owner
C. DLP system
D. End user with no authority

Correct Answer

A

Question 16

Which PKI component is commonly involved in validating certificate-request identity information?

A. Registration Authority
B. CRL
C. HMAC
D. TPM

Correct Answer

A

Question 17

What is a trust anchor?

A. Authority or public key for which trust is configured or assumed.

B. Certificate's private key.

C. Network firewall.

D. Hash collision.

Correct Answer

A

Question 18

What is a CRL?

A. Signed list of revoked certificates
B. List of trusted passwords
C. Symmetric key store
D. Hash algorithm

Correct Answer

A

Question 19

What is OCSP used for?

A. Online certificate-status checking
B. File encryption
C. Hash generation
D. Data classification

Correct Answer

A

Question 20

What should normally occur after a certificate's associated private key is confirmed compromised?

A. Revoke and replace affected key/certificate according to policy.

B. Wait until expiration.

C. Publish the private key.

D. Ignore the event.

Correct Answer

A

Part LXXIII — Original CISSP-Style Practice Questions

202. Practice Question 1

A cryptographic algorithm remains mathematically secure, but attackers discover that processing time differs according to secret-key bits.

What is the BEST classification?

A. Timing side-channel attack
B. Brute force only
C. Frequency analysis
D. Ciphertext-only attack

Correct Answer

A

203. Practice Question 2

An attacker cannot break an encryption algorithm but obtains the encryption key from an application configuration file.

What failed?

A. Key management/implementation security
B. Algorithm mathematics
C. Certificate expiration
D. Data classification only

Correct Answer

A

204. Practice Question 3

Two endpoints create encrypted sessions but do not authenticate each other.

An attacker intercepts both and relays the traffic.

Which control is MOST important to prevent this?

A. Authenticated key establishment / identity validation
B. Larger hard drive
C. File retention
D. Data masking

Correct Answer

A

205. Practice Question 4

An attacker steals a password-derived authentication representation and uses it successfully without determining the original password.

Which attack is MOST likely?

A. Pass-the-hash
B. Frequency analysis
C. Chosen ciphertext
D. Hash collision

Correct Answer

A

206. Practice Question 5

A browser receives a certificate that is mathematically valid but is issued for a different hostname.

What should the browser do?

A. Reject the identity binding for the requested hostname.

B. Trust it because the signature is valid.

C. Ignore hostname validation.

D. Disable encryption.

Correct Answer

A

207. Practice Question 6

A certificate is within its stated validity period but its private key was stolen yesterday.

Which mechanism should relying parties use to discover that trust has been terminated?

A. Certificate revocation status such as CRL or OCSP
B. Only expiration date
C. Data retention
D. AES-GCM

Correct Answer

A

208. Practice Question 7

A client validates a server certificate through two intermediate certificates until reaching a trusted CA.

What process is being performed?

A. Certification-path validation
B. Password hashing
C. Data masking
D. Key escrow

Correct Answer

A

209. Practice Question 8

An organization wants to reduce exposure of its highest-value CA private key.

Which architecture is MOST appropriate?

A. Protect the root CA strongly and use intermediate issuing CAs for routine certificate issuance.

B. Store the root private key in every server.

C. Publish the private key.

D. Use one shared password for all PKI administration.

Correct Answer

A

210. Practice Question 9

An organization has thousands of certificates but cannot identify which will expire next month.

What capability is MOST urgently needed?

A. Certificate inventory and lifecycle management
B. Additional ransomware encryption
C. Data masking
D. Password reuse

Correct Answer

A

211. Practice Question 10

An organization plans to transition its PKI to post-quantum algorithms but discovers its certificate-management software cannot support algorithm changes.

What architectural weakness is MOST apparent?

A. Lack of cryptographic agility
B. Too much integrity
C. Excessive certificate validation
D. Too many trust anchors automatically

Correct Answer

A

Part LXXIV — Attack Memory Table

212. If You See This, Think This

Part LXXV — PKI Memory Table

213. PKI Associations

Part LXXVI — Key Terms

214. Key Terms

Cryptanalysis

Study and practice of defeating or analyzing cryptographic protections.

Brute-Force Attack

Systematic testing of possible keys or credentials.

Ciphertext-Only Attack

Attack in which only ciphertext is initially available.

Known-Plaintext Attack

Attack using known plaintext and corresponding ciphertext.

Chosen-Plaintext Attack

Attack in which the attacker chooses plaintext and observes resulting ciphertext.

Chosen-Ciphertext Attack

Attack in which selected ciphertext is submitted for decryption-related analysis.

Frequency Analysis

Analysis of recurring statistical ciphertext patterns.

Implementation Attack

Attack targeting flaws in cryptographic implementation.

Side-Channel Attack

Attack using information leaked indirectly through implementation behavior.

Timing Attack

Side-channel attack using computational timing differences.

Fault Injection

Attack that deliberately introduces system faults to produce exploitable behavior.

Man-in-the-Middle

Attack in which an adversary interposes between communicating parties.

Pass-the-Hash

Use of captured reusable authentication hash material without recovering the original password.

Pass-the-Ticket

Reuse of stolen Kerberos authentication ticket material.

Ransomware

Malware that commonly encrypts or denies access to information for extortion.

PKI

Public Key Infrastructure.

Digital Certificate

Digitally signed structure binding identity information to a public key.

X.509

Widely used standard for public-key certificates.

Certificate Authority

Trusted entity issuing and signing certificates.

Registration Authority

PKI entity assisting with identity verification and certificate registration.

Certificate Holder

Entity to which a certificate is issued.

Relying Party

Entity that uses and validates a certificate in making a trust decision.

Root CA

Top certification authority in a hierarchical PKI.

Intermediate CA

CA certified by another CA.

Trust Anchor

Authority or public key configured as a starting point of trust.

Certification Path

Sequence of certificates connecting an end entity to a trust anchor.

CSR

Certificate Signing Request.

Certificate Revocation

Termination of certificate trust before normal expiration.

CRL

Certificate Revocation List.

OCSP

Online Certificate Status Protocol.

SAN

Subject Alternative Name.

Key Usage

Certificate extension identifying permitted cryptographic uses.

Extended Key Usage

Certificate extension identifying more specific purposes.

Certificate Pinning

Restricting trust to a specific or narrowly defined certificate/public-key relationship.

Part LXXVII — CISSP Exam Focus

215. Cryptanalytic Attack Mindset

Remember:

STRONG CRYPTOGRAPHY

        │

        ▼

ATTACKER LOOKS FOR

        │

 ┌──────┼──────────┬───────────┐

 ▼      ▼          ▼           ▼

KEY   PROTOCOL  IMPLEMENTATION HUMAN /

                         TRUST SYSTEM

For CISSP questions:

• Brute force tests possible keys.

• Ciphertext-only means the attacker starts with ciphertext.

• Known plaintext means some plaintext/ciphertext pairs are known.

• Frequency analysis exploits statistical patterns.

• Chosen ciphertext uses attacker-selected ciphertext inputs.

• Implementation attacks target software or hardware rather than the algorithm itself.

• Side channels exploit indirect information leakage.

• Timing attacks are side-channel attacks.

• Fault injection deliberately causes abnormal computation.

• MITM exploits communication trust.

• Encryption without authentication may remain vulnerable to MITM.

• Pass-the-hash does not necessarily require password cracking.

• Kerberos exploitation focuses on abuse of ticket/credential trust.

• Ransomware most directly threatens availability but may also affect confidentiality and integrity.

• Strong cryptography requires strong key management and implementation.

The official current Objective 3.7 specifically includes all of these major attack families.

216. PKI Mindset

Remember:

IDENTITY

   │

   ▼

PUBLIC KEY

   │

   ▼

CERTIFICATE

   │

   ▼

CA SIGNATURE

   │

   ▼

CERTIFICATION PATH

   │

   ▼

TRUST ANCHOR

   │

   ▼

VALIDITY / REVOCATION /

NAME / USAGE CHECKS

   │

   ▼

TRUST DECISION

For CISSP questions:

• Certificates bind public keys to identities.

• Certificates contain public keys, not the subject's private key.

• CAs issue and sign certificates.

• RAs support registration and identity validation.

• Root CAs act as trust anchors when explicitly trusted.

• Intermediate CAs reduce the need for roots to perform routine issuance.

• A certificate chain connects an end entity to a trusted anchor.

• Signature validity alone does not prove a certificate should be trusted.

• Validate certificate identity, validity, usage, chain, and status.

• Expiration is normal lifecycle completion.

• Revocation ends trust early.

• CRLs publish revoked certificates.

• OCSP provides online certificate-status responses.

• Compromised private keys can require prompt certificate revocation.

• Certificate lifecycle management protects both security and availability.

• CA private keys are especially high-value assets.

• PKI requires governance, not only cryptography.

• Certificate and crypto inventories are essential for algorithm migration.

217. Lesson Summary

Lesson Eleven examined how cryptographic trust can fail.

The current CISSP examination explicitly includes thirteen attack areas under Objective 3.7:

• brute force;

• ciphertext only;

• known plaintext;

• frequency analysis;

• chosen ciphertext;

• implementation attacks;

• side channels;

• fault injection;

• timing attacks;

• MITM;

• pass-the-hash;

• Kerberos exploitation;

• ransomware.

You learned that attackers often do not need to break the underlying mathematics.

Instead, they may attack:

KEYS

  │

  ▼

IMPLEMENTATION

  │

  ▼

PROTOCOL

  │

  ▼

PHYSICAL LEAKAGE

  │

  ▼

AUTHENTICATION

  │

  ▼

TRUST

You learned that brute-force attacks target the keyspace, while known-plaintext, ciphertext-only, and chosen-ciphertext attacks represent different levels of information or interaction available to an attacker.

You examined side-channel attacks involving:

• timing;

• power;

• electromagnetic behavior;

and fault-injection attacks that deliberately disturb cryptographic computation.

You also examined authentication-oriented attacks such as:

• MITM;

• pass-the-hash;

• Kerberos-ticket abuse.

The second half of the lesson expanded Public Key Infrastructure.

PKI answers a central question that cryptographic mathematics alone cannot answer:

Whose public key is this?

NIST defines X.509 public-key certificates as digitally signed structures associating public keys with identities.

A simplified hierarchy is:

TRUST ANCHOR

    │

    ▼

ROOT CA

    │

    ▼

INTERMEDIATE CA

    │

    ▼

END-ENTITY CERTIFICATE

    │

    ▼

RELYING PARTY

NIST's PKI guidance identifies certification authorities, registration authorities, certificate holders, clients/relying parties, and repositories as major PKI components.

You then studied the certificate lifecycle:

KEY GENERATION

     ↓

REGISTRATION

     ↓

ISSUANCE

     ↓

DEPLOYMENT

     ↓

VALIDATION

     ↓

MONITORING

     ↓

RENEW / REKEY

     ↓

REVOKE / EXPIRE

     ↓

RETIRE

Certificate validation involves much more than checking whether the certificate has a digital signature. A relying party should evaluate the certification path, trust anchor, validity, appropriate use, identity, and certificate status. NIST guidance describes path validation as evaluating the certificate path from a trust anchor through any intermediates to the end entity while considering revocation and policy constraints.

You learned that certificate status may be communicated through:

CRL

Revoked certificate list

or:

OCSP

Online certificate-status response

NIST recognizes both as standard revocation/status mechanisms.

The central Lesson Eleven principle is:

Cryptographic strength depends on more than algorithms. Secure systems must protect keys, authenticate endpoints, resist implementation leakage, correctly validate certificates, rapidly revoke compromised trust, and continuously manage the entire cryptographic trust lifecycle.

Exam Readiness Check

Before proceeding to Lesson Twelve, make sure you can explain without reviewing the lesson:

• What cryptanalysis means.

• Why strong algorithms can still fail.

• What brute force does.

• Why key size matters.

• What ciphertext-only means.

• What known plaintext means.

• What frequency analysis means.

• What chosen plaintext means conceptually.

• What chosen ciphertext means.

• What implementation attacks target.

• What side-channel attacks target.

• What timing attacks observe.

• What power-analysis attacks observe.

• What fault injection does.

• What a MITM attack does.

• Why authentication matters during key establishment.

• What downgrade attacks attempt.

• What a hash collision is.

• Why collision resistance differs from preimage resistance.

• What pass-the-hash means.

• Why pass-the-hash does not necessarily require password recovery.

• What Kerberos ticket exploitation means at a high level.

• Why ransomware is included as an important cryptographic attack-related concept.

• What PKI is.

• Why public-key cryptography needs PKI.

• What a digital certificate contains.

• Why a private key is not stored in the public certificate.

• What X.509 means.

• What the issuer field means.

• What the subject field means.

• What certificate validity means.

• What SAN means.

• What Key Usage means.

• What Extended Key Usage means.

• What a CA does.

• What an RA does.

• What a relying party does.

• What a root CA is.

• What an intermediate CA is.

• What a trust anchor is.

• What a certificate chain is.

• What certification-path validation means.

• What a CSR is.

• How a certificate is issued.

• Why certificate inventory matters.

• The difference between expiration and revocation.

• Why private-key compromise normally requires prompt action.

• What a CRL does.

• What OCSP does.

• The difference between CRL and OCSP.

• What soft-fail versus hard-fail concepts mean.

• Why root CA private keys require exceptional protection.

• What hierarchical trust means.

• What cross-certification means.

• What certificate pinning does.

• Why certificate-management automation can improve availability.

• Why PKI also requires crypto agility for post-quantum transition.

Coming Next

Lesson Twelve: Physical and Facility Security Architecture

Lesson Twelve will complete the initial Security Architecture and Engineering sequence by covering CISSP Objectives 3.8 and 3.9 — site and facility security.

Topics will include:

• secure facility design;

• site selection;

• physical threat assessment;

• perimeter security;

• fences;

• gates;

• bollards;

• barriers;

• lighting;

• guards;

• CCTV;

• intrusion detection;

• mantraps/access-control vestibules;

• doors and locks;

• badges;

• biometrics;

• tailgating;

• piggybacking;

• visitor control;

• server rooms;

• data centers;

• wiring closets;

• media-storage facilities;

• evidence-storage facilities;

• restricted areas;

• work-area security;

• electrical utilities;

• UPS;

• generators;

• redundant power;

• HVAC;

• temperature;

• humidity;

• static electricity;

• water leakage;

• natural disasters;

• human-caused disasters;

• fire prevention;

• fire detection;

• fire classes;

• fire suppression;

• sprinkler systems;

• clean-agent systems;

• life-safety principles;

• secure facility diagrams;

• layered physical security;

• original CISSP-style scenarios.

The central Lesson Twelve question will be:

How should physical facilities be designed so people, information, systems, infrastructure, and evidence remain protected against unauthorized access, environmental threats, fire, utility failures, and other physical risks?

Publication and Independence Notice

This lesson is independently developed educational material for the SierraTec Secure CISSP Certification Preparation Course.

CISSP is administered by ISC2. SierraTec Secure's course is independent certification-preparation material and should not be represented as official ISC2 training unless separately authorized.

The current attack-objective mapping was verified against the official CISSP Certification Exam Outline. Objective 3.7 specifically identifies brute force, ciphertext-only, known-plaintext, frequency analysis, chosen-ciphertext, implementation, side-channel, fault injection, timing, MITM, pass-the-hash, Kerberos exploitation, and ransomware.

PKI concepts were supplemented with NIST PKI and key-management material. NIST describes PKI architectures containing certification authorities, registration authorities, certificate holders, relying clients, and repositories; it also defines X.509 certificate structures and recognizes CRL and OCSP mechanisms for certificate status and revocation.

The SierraTec Secure HARDEN and PKI TRUST models, diagrams, scenarios, comparisons, knowledge checks, and practice questions are original instructional material. They are not actual, recalled, leaked, or official CISSP examination questions.