🔐 Cryptography Foundations Overview

Brief Overview
This note covers Cryptographic Concepts and was created from a 97‑page PDF on
cryptographic concepts ([Link]
47c6-adac-dbbf805a02ca/documents/[Link]).
The notes walk through the basics of encryption, hashing, key management, and the trust
infrastructure that keeps our digital communications secure.

Key Points
Plaintext ↔ ciphertext fundamentals
Symmetric encryption workflow and trade‑offs
Key lengths and brute‑force resilience
Digital signatures and PKI basics

Cryptographic Concepts 🔐
Plaintext (cleartext) – The original, unencrypted message.

Ciphertext – The encrypted version of the plaintext.

Algorithm – The systematic method used to transform plaintext into ciphertext and
back again.

Cryptanalysis – The art and science of breaking cryptographic systems.

Hashing – A one‑way function that produces a fixed‑length digest from data of any
size.

Symmetric Encryption – Encryption where the same secret key is used for both
encryption and decryption.

Asymmetric Encryption – Encryption that uses a paired public key (for encryption)
and private key (for decryption).
 Characters –

Alice: sender of a legitimate message.

Bob: intended recipient.
Mallory: malicious attacker.
The diagram below visualizes the flow of messages among these characters:

The flowchart shows the relationships and interactions between Alice, Bob, and Mallory in
a cryptographic exchange.

Symmetric Encryption 🔑
Symmetric Encryption – A cryptographic process where a single secret key encrypts
and decrypts data, providing confidentiality.

Substitution & Transposition

Substitution cipher – Replaces each plaintext character with another character.
Example: ROT13 shifts letters 13 places (A → N).
Transposition cipher – Keeps characters unchanged but rearranges their order.
Example: writing text in columns and reading rows produces the ciphertext
“HLOOLELWRD”.
Modern algorithms combine both techniques in complex ways to resist cryptanalysis.

Symmetric Encryption Workflow

1. Key agreement – Alice and Bob agree on a cipher and share a secret key.
2. Encryption – Alice encrypts the file with the shared key.
3. Transmission – Alice sends only the ciphertext to Bob.
4. Decryption – Bob decrypts using the same key.
The process is illustrated below:

Alice encrypts “HelloWorld” → ciphertext “rWoeldlolH”. Bob decrypts the ciphertext with
the same secret key to retrieve the original file.
Strengths
Very fast; suitable for bulk data encryption.
Strong security when the key remains secret.
Weaknesses
Key exchange problem – Securely sharing the secret key is difficult; if Mallory
obtains the key, confidentiality is lost.
Does not provide authentication or integrity on its own.
Command‑line example (AES)

# Encrypt
aes -e -p ToughPassword [Link]

# Decrypt
aes -d -p ToughPassword [Link]

Key Length & Brute‑Force Resistance 📏

 Key – The secret value used by an algorithm; its secrecy protects the
ciphertext.
Keyspace – All possible values a key can take. Larger keyspaces make
brute‑force attacks impractical.
Cipher Key Length Keyspace Typical Use
(possible keys)
ROT13 5 bits (13) 25 possible shifts Educational demo
AES‑128 128 bits 2
128
General‑purpose
encryption
AES‑256 256 bits 2
256
Highly sensitive
data
Key length directly impacts security: AES‑256’s keyspace is astronomically larger than
AES‑128’s, but longer keys require more processing power and memory.

Asymmetric Encryption 🗝️
Asymmetric Encryption – Uses a mathematically linked public/private key pair; the
public key encrypts, the private key decrypts.

Workflow
1. Key‑pair generation – Bob creates a public and private key; keeps the private
key secret.
2. Public key distribution – Bob publishes the public key.
3. Encryption – Alice encrypts a message with Bob’s public key.
4. Transmission – Alice sends the ciphertext to Bob.
5. Decryption – Bob uses his private key to retrieve the plaintext.
The diagram below visualizes these steps:
Bob’s public key encrypts “HelloWorld” → ciphertext “rWoeldlolH”. Only Bob’s private key
can reverse it.
Strengths & Weaknesses
Aspect Strength Weakness
Security Public key can be shared Computationally intensive;
openly; private key never slower than symmetric
transmitted. encryption.
Key Exchange Enables secure exchange Not suitable for bulk data
of a symmetric session key encryption.
(hybrid encryption).

Common Algorithms & Recommended Key Lengths

Algorithm Recommended Private Key Length
RSA 2,048 bits
ECC (Elliptic Curve) 256 bits (equivalent security to ~3,072‑bit
RSA)

Hashing 🔒
 Cryptographic Hashing – Generates a fixed‑length digest from data of any size; it is
computationally infeasible to reverse or find collisions.

Integrity Verification
1. Password verification – Server stores only the hash of a password. During
login, the entered password is hashed and compared.
2. File integrity – Sender publishes a hash of a file; receiver hashes the
downloaded file and compares.
The following infographic shows the five‑step integrity check process:

Alice publishes a file and its hash; Bob validates the hash after download, detecting any
tampering by Mallory.
Popular Hash Algorithms
Algorithm Digest Size Security Notes
SHA‑256 256 bits Currently considered
strong.
MD5 128 bits Faster but vulnerable to
collisions; used only for
compatibility.
A command‑line screenshot (checksum verifier) illustrates practical usage:
Digital Signatures ✍️
Digital Signature – A cryptographic construct that combines hashing and asymmetric
encryption to provide message authentication, integrity, and non‑repudiation.

Signing Process
1. Digest creation – Sender hashes the message (e.g., using SHA‑256).
2. Signature generation – Sender encrypts the digest with their private key.
3. Transmission – Message and signature travel together.
4. Verification – Receiver decrypts the signature with the sender’s public key to
obtain the original digest, hashes the received message, and compares the two
digests.
The workflow is depicted below:

If the digests match, integrity and sender authenticity are confirmed.

Standards
PKCS#1 – RSA‑based signatures.
DSA – Uses ElGamal; ECDSA (Elliptic Curve DSA) is now preferred.
🏢
Certificate Authorities (CAs) 🏢
Certificate Authority – A trusted entity that issues digital certificates binding public
keys to verified identities, solving the “who owns this public key?” problem.

Without a CA, a public key alone cannot prove the owner’s identity, leaving
e‑commerce and secure communications vulnerable to impersonation.
CAs sign certificates with their own private key; browsers and operating
systems trust the CA’s public key, enabling validation of a site’s certificate (e.g.,
“DigiCert TLS RSA SHA‑256 2020 CA1”).
The browser security notification screenshot demonstrates a valid certificate indicator:

The icon confirms a secure connection and that the certificate is issued by a trusted
authority.

Public Key Infrastructure (PKI) 🔐

Public Key Infrastructure – A framework that binds public keys to their owners via
digitally signed certificates, enabling trust relationships between clients and servers.

The PKI workflow establishes trust through the following steps:

1. Root certificate creation – The Certificate Authority (CA) generates a
self‑signed root certificate and publishes its public key.
2. Root trust store – Clients add the CA’s root certificate to their trusted store.
 3. CSR generation – A web server creates a Certificate Signing Request (CSR)
containing its public key.
4. Certificate signing – The CA signs the CSR, producing a server certificate.
5. Certificate validation – The client verifies that the server’s certificate is signed
by a trusted CA.
6. Secure connection – A trusted, encrypted session is established.
Third‑party CA functions
Provide a range of certificate services to the community.
Verify applicant identity (registration).
Build trust with users, regulators, and enterprises.
Manage repositories that store and serve certificates.
Perform lifecycle tasks such as revocation and renewal.

The diagram visualizes how a client establishes a trusted TLS connection using certificates
issued by a CA.

Digital Certificates 📄
Digital Certificate – A digitally signed data structure that binds a subject’s public key
to identifying information about the subject and the issuing CA (the issuer).
Key components (as shown in the certificate viewer):
Subject Public Key – The public key belonging to the certificate holder.
Issuer – The CA that signed the certificate.
Validity period – “Not Before” and “Not After” timestamps.
Extensions – e.g., Subject Alternative Name (SAN), Key Usage, etc.
Certificates follow the X.509 standard (RFC 5280) and are often issued under the PKCS
family of standards.

The view shows the public key information and the trust chain up to the root CA.

Root of Trust 🔑
 Root of Trust – The topmost, self‑signed certificate in a PKI hierarchy. Possession of
the root certificate enables verification of all certificates signed beneath it.

PKI models
Model Description Typical Use Pros Cons
Single CA One root CA Private Simple Single point of
issues networks deployment. failure; if
certificates compromised,
directly to end the entire PKI
entities. collapses.
Hierarchical A root CA signs Public/B2B Allows policy More complex
(third‑party) one or more communications segregation, infrastructure.
intermediate easier
CAs, which in revocation, and
turn issue leaf finer‑grained
certificates. trust paths.

The chain demonstrates how a server certificate is linked to an intermediate CA, which is
signed by a trusted root.

Self‑Signed Certificates 🛡️
Self‑Signed Certificate – A certificate signed with its own private key rather than by a
trusted external CA.

Common in internal testing, development environments, or consumer router

admin pages.
Browsers mark them untrusted; users must manually override warnings.
 Lack of third‑party validation makes them unsuitable for protecting critical
services.

Certificate Signing Requests (CSR) ✍️

Certificate Signing Request – A file containing a public key and the applicant’s
distinguished name, submitted to a CA for certificate issuance.

CSR creation workflow

1. Generate an asymmetric key pair (e.g., RSA 2048, ECC 256).
2. Populate CSR fields (Common Name, Organization, SANs, etc.).
3. Submit the CSR to the CA (often via a web form).
4. CA validates the request (domain ownership, identity).
5. CA signs the request and returns the certificate.

The diagram outlines the end‑to‑end CSR process.

This screenshot illustrates the UI where administrators define CSR parameters.

Subject Name Attributes 🌐

Subject Alternative Name (SAN) – An X.509 extension that lists additional identifiers
(DNS names, IP addresses, email addresses) for which the certificate is valid.

The legacy Common Name (CN) field is deprecated for host validation;
browsers now prioritize SAN.
Wildcard SAN (e.g., *.[Link]) covers all first‑level subdomains of a
domain.
Although SAN is preferred, retaining the FQDN in the CN remains a
best‑practice for backward compatibility.
Attribute Purpose Example
CN Historically identified the [Link]
host.
SAN (DNS) Lists all hostnames/IPs a [Link],
certificate covers. [Link]
 SAN (IP) Allows direct IP address [Link]
validation.
Wildcard Matches any subdomain at *.[Link]
one level.

The view highlights the SAN field with several DNS names, illustrating how a single
certificate can secure multiple domains.

Certificate Revocation 🚫
Certificate Revocation – The process of invalidating a certificate before its scheduled
expiration, typically because the private key is compromised or the holder’s status
 changes.

Revocation reasons
Reason Code Description
Unspecified No specific reason given.
Key Compromise Private key is known to be exposed.
CA Compromise The issuing CA’s private key is
compromised.
Superseded Certificate replaced by a newer one.
Cessation of Operation Entity no longer needs the certificate.
Certificate Hold Temporary suspension (can be
re‑enabled).
Mechanisms
Certificate Revocation List (CRL) – A signed list published by the CA
containing revoked certificates.
Online Certificate Status Protocol (OCSP) – Real‑time query service that
returns the status of a single certificate.
Key CRL fields:
Publish Period – When the CRL is generated.
Distribution Points – URLs where the CRL can be fetched.
Validity Period – How long the CRL is considered authoritative.
Signature – CA’s digital signature verifying authenticity.

Shows the “CRL Distribution Points” extension that tells clients where to download the
revocation list.
Provides a snapshot of the revocation list metadata used by clients during validation.

Key Management 🔐
Key Management – The set of operational practices governing the lifecycle of
cryptographic keys, from generation to retirement.

Lifecycle stages
1. Generation – Create symmetric or asymmetric keys with sufficient entropy.
2. Storage – Protect private/secret keys against unauthorized access and loss.
3. Revocation – Invalidate compromised keys; re‑encrypt data with fresh keys.
4. Expiration & Renewal – Enforce limited lifespans; renew certificates before
expiry.
Management models
Model Description Trade‑offs
 Decentralized Keys are generated and Easy deployment; harder
stored locally on each to detect compromise.
endpoint.
Centralized (KMS) A dedicated Stronger control and
server/appliance stores auditing; higher
keys; clients use KMIP to infrastructure complexity.
request cryptographic
operations.

Cryptoprocessors & Secure Enclaves 🧩

Cryptoprocessor – Dedicated hardware (e.g., TPM or HSM) that generates, stores, and
uses cryptographic keys without exposing them to the host OS.

Trusted Platform Module (TPM)

Implemented as discrete, integrated, or firmware chips.
Provides tamper resistance (discrete) or leverages CPU secure enclave
(firmware).
Supports PKCS#11 API for applications.
Hardware Security Module (HSM)
Stand‑alone appliance or removable device (USB, PCIe).
Used for centralized key storage or portable key transport.
Often FIPS 140‑2 Level 2 certified.
Feature TPM HSM
Form factor Chip on motherboard / Rack‑mounted, PCIe, USB
firmware
Primary use Platform integrity, secure High‑value key storage,
boot signing services
Attack surface Low (discrete) / higher Moderate (appliance)
(firmware)
Typical deployment Laptops, servers, Data centers, PKI
embedded devices infrastructures
Illustrates an HSM device used for secure key storage and cryptographic operations.
Secure Enclave (Trusted Execution Environment)
Extends protection by shielding decrypted data in RAM from privileged
processes.
Examples: Intel SGX, ARM TrustZone.
Enclaves are locked to a set of digitally signed applications, preventing even
root‑level access without authorization.

Key Escrow 🔐
Key Escrow – The practice of storing cryptographic keys with a trusted third party,
enabling recovery if the original key is lost.

M‑of‑N control: M out of N designated Key Recovery Agents (KRAs) must

approve any key retrieval, reducing insider risk.
Escrowed keys can be split into shards, each held by a different escrow
provider.
Depicts the steps from key generation to escrow and authorized recovery.

Encryption Supporting Confidentiality 🔒

Confidentiality – Ensuring that information is accessible only to authorized parties;
encryption converts plaintext into unreadable ciphertext.

Data states
Data at rest – Stored on disks, tapes, or other persistent media.
Data in transit – Transmitted over networks (e.g., HTTPS, VPN).
Data in use – Residing in volatile memory (RAM, CPU registers) during
processing.
Bulk encryption – Symmetric algorithms (AES, ChaCha20) encrypt large
volumes efficiently; asymmetric schemes are unsuitable for bulk due to high
computational overhead.

3.3.2 Disk and File Encryption 💾

Full‑Disk Encryption (FDE) – Encrypts the entire contents of a storage device,
including free‑space and metadata, protecting data against physical theft.

Self‑Encrypting Drive (SED) – Disk firmware contains a cryptoprocessor that

stores keys internally, preventing the OS from seeing the raw keys.
Partition‑Level Encryption – Individual partitions can be encrypted with
separate keys, allowing selective protection (e.g., leaving boot/system
partitions clear while encrypting data partitions).

Volume Encryption – Encrypts a logical storage volume (a mountable filesystem).

Implemented by software such as BitLocker (Windows) or FileVault (macOS). May or
may not encrypt free space and file metadata.
 File‑Encryption – Encrypts individual files or directories; often requires filesystem
support (e.g., Windows Encrypting File System – EFS).

Key points
Encryption of free space prevents data remnants from being recovered after
file deletion.
TPM/HSM integration can store encryption keys, allowing the disk/volume to
be locked automatically at boot.

The diagram shows the progression from key generation to encryption of the disk/volume
and the role of a TPM in unlocking the key.
Level Scope Typical Notes
Implementation
Full‑Disk Entire device SED, BitLocker, Best for protecting
(including free FileVault against theft
space)
Partition Selected partitions Custom partition Allows mixed
only encryption tools encrypted/unencrypt
parts
Volume Single filesystem BitLocker, FileVault May or may not
volume cover metadata
File Individual EFS, Fine‑grained
files/folders application‑level control; requires OS
encryption support

3.3.3 Database Encryption 🗄️

 Transparent Data Encryption (TDE) – Database‑ or page‑level encryption applied
automatically as data moves between disk and memory; the DBMS handles
encryption/decryption transparently.

Cell/Column (Record‑Level) Encryption – Encrypts specific fields within a table,

keeping the rest of the database in plaintext. Often implemented with “Always
Encrypted” (SQL Server) where the client holds the decryption keys.

Granularity comparison
Granularity What is encrypted Performance Management
impact complexity
Database‑Level All pages, logs, Higher (full‑disk Simple – single key
(TDE) backups encryption) per database
Record‑Level Selected Lower – only Higher – key
columns/cells protected fields management per
processed column or row

Key hierarchy –

1. Key Encryption Key (KEK) – Asymmetric key pair (RSA/ECC) protecting the
Data Encryption Key (DEK).
2. Data Encryption Key (DEK) – Symmetric key (AES‑256/512) used to encrypt
the actual data.

Workflow – The DEK encrypts database files; the KEK (stored in a certificate)
encrypts the DEK. Clients retrieve the DEK by decrypting it with the KEK, then use it to
read/write encrypted columns.
Illustrates the relationship between KEK, DEK, and encrypted data.

3.3.4 Transport Encryption and Key Exchange 🌐

Transport Encryption – Protects data‑in‑motion using symmetric session keys, while
asymmetric cryptography secures the exchange of those session keys.

Common transport security protocols

Protocol Primary Use Underlying Mechanism
WPA / WPA2 Wireless LAN PSK or 802.1X + AES
IPsec VPN tunnel between ESP/AH with IKE key
hosts/networks exchange
TLS Web, email, other Handshake → RSA/ECC for
application‑layer traffic key exchange, then AES (or
ChaCha20) for data
Digital envelope (key exchange) steps
1. Obtain the recipient’s public key (via a certificate).
2. Generate a random session key (symmetric, e.g., AES).
3. Encrypt the message with the session key.
4. Encrypt the session key with the recipient’s public key.
5. Send ciphertext + encrypted session key (digital envelope).
6. Recipient decrypts the session key with their private key, then decrypts the
ciphertext.

Integrity & Authenticity – Often provided by an HMAC (H M AC =

H (key, message) ) or by an Authenticated Encryption mode (e.g., AES‑GCM) that
guarantees both confidentiality and integrity in a single operation.

3.3.6 Salting and Key Stretching 🧂

Salt – A random, non‑secret value concatenated with a password before hashing to
ensure that identical passwords produce different hashes.
 Key Stretching – Repeatedly hashes a salted password (often thousands of iterations)
to increase computational cost for attackers.

Salted hash formula

hash = SHA(salt, ∣, password)

The salt is stored alongside the hash; it is not secret.

Prevents the use of pre‑computed rainbow tables.
Key stretching example – PBKDF2
Input: password, salt, iteration count (e.g., 10 000).
Output: derived key of desired length.
Technique Purpose Typical Use
Salting Add uniqueness to each Password storage (e.g.,
password hash UNIX /etc/shadow)
Key Stretching (PBKDF2, Increase attacker workload WPA‑PSK, modern
bcrypt, scrypt, Argon2) authentication systems

3.3.7 Blockchain ⛓️
Blockchain – A decentralized ledger where each block contains a set of transactions, a
timestamp, and the hash of the previous block, creating a cryptographically linked
chain.

Immutability – Changing any block would require recomputing all subsequent

hashes, which is computationally infeasible.
Decentralization – The ledger is replicated across many nodes in a P2P
network, eliminating a single point of failure.
Typical applications
Financial transaction records (cryptocurrencies)
Smart contracts, legal agreements
Supply‑chain provenance, voting systems, identity management

3.3.8 Obfuscation 🕶️
 Obfuscation – The practice of making data or code difficult to locate or understand;
often considered “security through obscurity” and used as a complementary measure.

Techniques
Technique Description Typical Use
Steganography Embeds hidden data within Covert communication
a carrier (e.g., image,
audio)
Data Masking Redacts or replaces Development/testing
characters (e.g., environments
“xxxx‑1234”) while
preserving format
Tokenization Substitutes sensitive values PCI‑DSS compliance,
with randomly generated de‑identification
tokens; original data stored
in a secure vault
De‑identification Removes or obscures Research datasets
personally identifiable
information to enable safe
data sharing
Covertext – The carrier file (e.g., an image) that holds the hidden message.
Tokenization is reversible (via the token vault), whereas masking is typically
irreversible.

4.1.1 Authentication Design 🔐

Authentication – The process where a claimant presents credentials to a server, which
verifies them against stored records.

Design goals
Confidentiality – Credentials must remain secret; leakage enables
impersonation.
Integrity – Authentication mechanisms must resist tampering and spoofing.
Availability – Authentication should be reliable and not hinder legitimate
access.
Factors (credential types)
Something You Know – Passwords, passphrases, PINs (device‑specific).
Something You Have – Smart cards, hardware tokens, mobile OTP apps.
Something You Are – Biometrics (fingerprint, facial recognition).
Somewhere You Are – Location/IP‑based checks (geofencing, network
segment).

Note: Combining at least two different factor categories yields Multifactor

Authentication (MFA), which is stronger than using a single factor.

4.1.2 Password Concepts 🔑

Password Policy – A set of rules governing password creation, management, and
lifecycle to mitigate credential‑based attacks.

Policy Element Description

Length Minimum (and possibly maximum)
character count.
Complexity Mix of uppercase, lowercase, digits, and
special characters; avoid username
inclusion.
Age Enforce periodic password changes after
a defined number of days.
Reuse & History Prevent reuse of recent passwords;
maintain a history count.
Minimum Age Block immediate reuse after a change,
forcing a true rotation.
NIST guidance deprecates mandatory complexity and frequent aging in favor
of longer passphrases and checking against known‑breach lists.
Password reuse across sites remains a risk; organizations can only influence it
via user education and technical controls (e.g., password managers).

4.1.3 Password Managers 🗝️

 Password Manager – Software that stores credentials in an encrypted vault, protected
by a master password.

Workflow
1. User selects a password‑manager application (built‑in OS manager or
third‑party like LastPass).
2. Master password secures the vault; vault may be cloud‑synced or locally stored.
3. When creating a new account, the manager generates a strong, random
password adhering to policy.
4. On subsequent logins, the manager auto‑fills credentials after verifying the
site’s TLS certificate.
Risks
Weak master password compromises the entire vault.
Vendor‑side breaches could expose stored vaults.
Phishing attacks may trick the manager into autofilling credentials on malicious
sites.

4.1.4 Multifactor Authentication (MFA) 🔐✨

MFA – Authentication that requires two or more distinct factors (knowledge,
possession, inherence, location).

Factor categories
Something You Have – Smart card, hardware token, mobile authenticator app.
Something You Are – Fingerprint, facial scan, voice recognition.
Somewhere You Are – Geolocation, IP address, network segment.

Note: Combining two knowledge factors (e.g., PIN + date‑of‑birth) is not MFA; true
MFA must involve different factor families.

Typical MFA implementations

Implementation Example
OTP Token Time‑based OTP (Google Authenticator)
Push Notification Approve login on a mobile app
 Biometric + Password Fingerprint + password
Location‑Based Controls Deny access if login originates from
unexpected country

4.1.5 Biometric Authentication 👆

Biometric Authentication – Uses unique physiological or behavioral traits to verify
identity.

Enrollment Process
1. Capture – Sensor records the biometric sample.
2. Feature Extraction – Generates a mathematical template representing
distinctive features.
Operational Verification – New sample is captured and compared against the stored
template; access granted if similarity exceeds a tolerance threshold.
Performance Metrics
Metric Definition
False Rejection Rate (FRR) Legitimate users denied access (Type I
error).
False Acceptance Rate (FAR) Impostors granted access (Type II error).
Crossover Error Rate (CER) Point where FRR = FAR; lower CER =
higher reliability.
Throughput Time required for enrollment and
verification.
Failure to Enroll Rate (FER) Percentage of users who cannot be
enrolled.
Cost/Implementation Hardware expense, integration
complexity, privacy concerns.
Fingerprint – Most common; uses capacitive or optical sensors; inexpensive,
but susceptible to dirt/moisture.
Facial Recognition – Uses optical/IR cameras; incorporates multiple facial
landmarks; harder to spoof with photos.
Illustrates the Android UI prompting users to move their finger to capture a complete
fingerprint template.

4.1.6 Hard Authentication Tokens 🪙

Hard Token – A physical device that generates or stores a one‑time credential, serving
as the “something you have” factor.

Token types
Type Mechanism Advantages Drawbacks
Certificate‑Based Stores a private Strong Requires PKI
key; signs cryptographic infrastructure and
authentication assurance; management
challenges integrates with PKI
 One‑Time Generates a No PKI needed; Must protect the
Password (OTP) temporary numeric simple integration secret seed; codes
code using a shared expire quickly
secret + timestamp
(TOTP) or counter
(HOTP)
Fast Identity (Details not — —
provided in
transcript)
OTP tokens often rely on HMAC‑based algorithms; each code is valid for a
short window, mitigating replay attacks.
Certificate‑based tokens provide non‑repudiation but incur higher
administrative overhead due to certificate lifecycle management.

4.1.7 Soft Authentication Tokens 📱

Soft authentication token – A one‑time password (OTP) generated by the identity
provider and delivered to the user’s device (e.g., via SMS, email, or an authenticator
app).

Delivery methods
SMS / email – typically counter‑based tokens with an expiry period.
Authenticator app – installed on a computer or smartphone; the
shared secret is provisioned via a QR code.
Key points
Tokens sent by SMS or email do not count as an ownership factor;
they are best described as two‑step verification rather than true
MFA.
Such tokens are highly vulnerable to interception (e.g., SS7 attacks,
email compromise).
Authenticator apps reduce interception risk but run on a shared
device, so malware could compromise the app.
Users must unlock the app with the device credential (PIN/biometric)
before viewing the OTP.
Figure 1 – Using an authenticator app to sign in:
The user logs in with a password, then the site prompts for a push notification. The
smartphone displays “Approve” or “Deny” icons; approving sends the OTP to complete
authentication.

4.1.8 Password‑less Authentication 🚪

Password‑less authentication – An authentication flow that eliminates
knowledge‑based factors (passwords) and relies solely on cryptographic proof of
possession and local user verification.

FIDO2 / WebAuthn workflow

1. Choose authenticator – Roaming (e.g., USB security key) or
platform (e.g., Windows Hello, Face ID).
2. Local verification – User presents a biometric, PIN, or gesture; the
authenticator validates locally.
3. Registration – For each relying party (service), the authenticator
creates a unique public/private key pair; the public key is stored with
the account.
4. Authentication challenge – The relying party sends a challenge; the
user unlocks the private key with the local gesture, which signs the
challenge.
5. Verification – The relying party validates the signature using the
stored public key.
Attestation – During registration, the authenticator can provide an attestation
certificate proving the device model and brand (not a unique identifier).
Privacy note – Attestation keys are not unique per device to avoid
tracking individuals.
Comparison with U2F
Aspect U2F FIDO2 / WebAuthn
Password usage Optional backup None (password‑less)
API support Limited to browser Native web API
extensions
Credential management Single key pair per site Per‑site key pair generated
automatically
Attestation Available but optional Standardized and optional

🛡️
4.2.1 Discretionary and Mandatory Access Control 🛡️
Access control model – A set of rules that dictate how authenticated subjects obtain
rights to objects.

Discretionary Access Control (DAC)

DAC – Ownership‑centric model where the resource owner controls access via an
Access Control List (ACL).

Characteristics
Every object has an owner who can modify its ACL.
Implemented by default in most UNIX/Linux and Windows file
systems.
Flexibility → Weakness: central policy enforcement is difficult;
vulnerable to insider threats and compromised accounts.
Mandatory Access Control (MAC)
MAC – Policy‑driven model based on classification labels and clearance levels,
enforced by the system, not by owners.

Key concepts
Object label (e.g., Top Secret, Secret, Confidential).
Subject clearance – Users can read objects at their clearance level
or lower (read‑down) but may only write up (write‑up).
Compartmentalization – Labels can include compartments (e.g.,
HR), requiring matching clearance for access.
Strengths – Centralized, non‑discretionary rules reduce risk of accidental or
malicious ACL changes.

4.2.2 Role‑ and Attribute‑Based Access Control 🎯

RBAC – Assigns permissions to roles; users acquire rights by being assigned to roles.
ABAC – Makes access decisions based on a combination of attributes (subject, object,
environment).
Role‑Based Access Control (RBAC)
Workflow
1. Define roles that represent job functions.
2. Assign permissions to each role.
3. Principals (users/services) are added to one or more roles.
Security groups act as a discretionary bridge to RBAC: users gain rights
through group membership rather than direct ACL assignments.
Considerations
Roles are managed by a system owner → nondiscretionary.
Over‑assignment can lead to privilege creep; careful role design is
essential.
Attribute‑Based Access Control (ABAC)
Decision factors
Subject attributes – role, clearance, device type.
Object attributes – sensitivity level, owner.
Contextual attributes – IP address, time of day, patch status.
Fine‑grained policies enable conditions such as “allow access only from
corporate IP during business hours”.
Advanced capabilities – Supports M‑of‑N approval, separation of duties, and
dynamic risk assessments.
Feature RBAC ABAC
Granularity Role‑level Attribute‑level
(fine‑grained)
Policy definition Static role‑to‑permission Dynamic rules using
mapping multiple attributes
Scalability Good for stable role sets Excellent for environments
with many contextual
factors
Complexity Lower Higher (requires attribute
management)

📏
4.2.3 Rule‑Based Access Control 📏
Rule‑based access control – Any model where access decisions are driven by
system‑enforced rules rather than user‑initiated ACL changes.

Examples of rule‑based models

RBAC, ABAC, MAC – all rely on predefined policies.
Conditional access – evaluates conditions (e.g., location, device
health) during a session; may prompt for re‑authentication or block
access.
User Account Control (UAC) and sudo – enforce elevation prompts
based on policy rules.
Key behavior – If no rule explicitly grants access, the default is implicit deny.

4.2.4 Least Privilege Permission Assignments 🛡️

Least privilege – The principle of granting users only the minimal rights necessary to
perform their duties.

Implementation steps
1. Analyze workflows to identify required tasks.
2. Map tasks to roles/permissions with the smallest scope possible.
3. Assign those permissions to users or groups.
4. Monitor for authorization creep (gradual accumulation of rights).
Risks of mis‑implementation
Issue Effect
Over‑privileged accounts Increased attack surface; easier for
malware to exploit.
Over‑restriction Productivity loss; higher support
overhead.
Authorization creep Users retain rights long after they are
needed.
Mitigation – Periodic audits, automated review of group memberships, and
timely revocation of temporary privileges.
🗂️
4.2.5 User Account Provisioning 🗂️
Provisioning – The structured process of creating, configuring, and managing user
accounts and related assets.

Typical provisioning workflow

1. Identity proofing – Verify the individual’s identity (documents, background
checks).
2. Issuing credentials – Set a user‑chosen password, enroll biometrics, or assign
token‑based authenticators.
3. Assigning hardware/software – Provide computers, smartphones, and
licensed applications; guard against shadow IT.
4. Policy awareness training – Educate the new user on security policies,
acceptable use, and personal‑device rules.
5. Permissions assignment – Determine required roles, map to
RBAC/MAC/ABAC policies, and configure group memberships.
6. Deprovisioning – When a user leaves or a contract ends: remove group/role
memberships, disable or delete the account, and reclaim assets.
Deprovisioning options – Immediate deletion, or a delayed disable period
before permanent removal.

4.2.6 Account Attributes and Access Policies 📋

Account attributes – Metadata associated with a user account (e.g., SID, name, email,
department, profile picture, home folder).

Core identifiers
SID – Unique Security Identifier used in access token comparisons
against ACLs.
Credentials – Passwords, certificates, or token keys.
Profile data – Full name, contact info, department, stored settings, and
optional media.
Access rights – Assigned directly or inherited via security groups or roles;
enforced through ACLs on files, services, or network resources.
Policy enforcement in Windows AD –
 Group Policy Objects (GPOs) define user rights (e.g., log‑on locally,
remote desktop).
GPOs can be linked to sites, domains, or Organizational Units
(OUs).
Figure 1 – Configuring GPOs: The screenshot shows the “User Rights Assignment” pane
with policies such as “Allow log on through Remote Desktop Services”.

Access Token Overview 🔐

Access token – A data structure generated at logon that contains a user’s SID, group
SIDs, and privileges; used by the OS to enforce security.

Components
User SID – Unique identifier for the account.
Group SIDs – List of security groups the user belongs to (e.g.,
Domain Admins, Enterprise Admins).
Privileges (user rights) – Capabilities such as “Change system time”
(often disabled).
How it works
When a user accesses a file/folder, the OS compares the user SID in
the token to the SIDs listed in the object’s ACL.
Match → access granted (subject to the rights defined); no match →
implicit deny.
Practical demonstration
whoami /all displays the complete token, revealing SIDs and
privileges.
Modifying group membership (e.g., adding a user to the Marketing
group) updates the token after a logoff/logon cycle, influencing
subsequent access attempts.
Key takeaway – The access token is the central mechanism tying
authentication to authorization; changes to group membership or privileges
only take effect after the token is refreshed.

Access Token Refresh & Group Membership 🔄

 Access token – The data structure created at user logon that contains the user’s SID,
group SIDs, and privileges; it is used by the OS to enforce security decisions.

When a user logs in, the access token captures the group memberships that
exist at that moment.
Changes made to group membership after logon are not reflected in the
current token.
To incorporate a newly‑added group (e.g., Marketing) into the token, the user
must log off and log back in, causing the system to issue a fresh token that
includes the updated groups.

Example command:

whoami /all

The output shows the list of groups present in the token; after re‑login, the
Marketing group appears, granting the expected share permissions.

Account Restrictions 📋 (4.2.7)

Policy‑based restrictions – Controls that limit account usage based on contextual
factors such as location or time, helping mitigate credential‑theft risks.

Location‑Based Policies
Logical network location identified by IP address, subnet, VLAN, or OU.
Can block logon to certain servers or OUs.
Geolocation (e.g., GeoIP) maps an IP to a map location; accuracy varies with
ISP granularity.
Device location services use GPS, cell‑tower triangulation, Wi‑Fi, or Bluetooth
to pinpoint a device’s position.
Time‑Based Policies
Policy Type Description
Time‑of‑day restriction Defines allowed login windows for an
account.
 Duration‑based login Limits the maximum session length after
authentication.
Impossible‑travel / risky login Detects implausible geographic jumps
(e.g., NYC → LA within minutes) and
disables the account.
Temporary permissions Removes a user from a role or group after
a predefined period.

Privileged Access Management (PAM) 🧑‍💻 (4.2.8)

Privileged account – An account capable of making significant configuration changes
(e.g., installing software, disabling firewalls) and managing network appliances, servers,
or databases.

Standard accounts have limited rights; they can run programs and modify only
their own profile files.
PAM objectives: identify privileged accounts, enforce visibility, and protect
credentials.
Best Practices
Minimize the number of administrative accounts.
Never share privileged accounts; enforce accountability.
Use strong passwords and ideally MFA or password‑less methods.
Perform privileged work on a Secure Administrative Workstation (SAW) – a
hardened system with minimal software.
Permission Models
Model Description Typical Mechanism
Just‑In‑Time (JIT) / Zero Elevation granted only Windows UAC, Linux sudo
Standing Privileges when needed, for a limited
time.
Temporary Elevation User gains admin rights for UAC prompt, sudo timeout
a short session.
Password Vaulting / Privileged credentials are Enterprise password vaults
Brokering “checked out” from a (e.g., CyberArk)
 secure vault, with a
justification logged and
possibly an M‑of‑N
approval workflow.
Ephemeral Credentials System creates a Cloud IAM temporary roles
short‑lived account or
token for the task, then
destroys it automatically.
PAM also applies to service accounts, which should be managed with the same
rigor as human administrators.

Authentication Types – Local, Network, Remote 🔐

(4.3.1)
Knowledge‑based authentication – Uses a password that is stored as a
cryptographic hash; the plaintext password is never transmitted or stored.

Windows Authentication
Scenario Component Typical Protocol
Local sign‑in LSASS validates credentials Interactive logon
against the Security
Accounts Manager (SAM)
database (registry).
Network sign‑in LSASS forwards credentials Kerberos (preferred) or
to an Active Directory NTLM (legacy)
(AD) domain controller.
Remote sign‑in Authentication occurs over Various VPN or TLS‑based
VPN, enterprise Wi‑Fi, or methods
web portal, establishing a
secure tunnel before
credential verification.

Linux Authentication
Local accounts: usernames in /etc/passwd; password hashes in /etc/shadow.
 Network login: typically via SSH, which can use public‑key authentication
instead of passwords.
Pluggable Authentication Modules (PAM) provide a flexible framework for
integrating smart cards, LDAP, or other authentication providers.

Directory Services 📂 (4.3.2)

Directory service – A centralized repository storing objects (users, computers, groups,
services) and their attributes, accessible via LDAP.

Schema defines required and optional attributes for each object class.
Distinguished Name (DN) uniquely identifies an object; composed of
comma‑separated attribute‑value pairs from most specific to broadest.
Example DN:

CN=WIDGETWEB, OU=Marketing, O=Widget, C=UK, DC=widget, DC=foo

Common attributes: CN (common name), OU (organizational unit), O

(organization), C (country), DC (domain component).

Single Sign‑On (SSO) – Kerberos Authentication 🗝️

(4.3.3)
Kerberos – A network authentication protocol using a trusted Key Distribution Center
(KDC) that issues tickets to prove identity without transmitting passwords.

Core Components
Authentication Service (AS) – Issues the Ticket‑Granting Ticket (TGT) after
verifying the user’s password hash.
Ticket‑Granting Service (TGS) – Exchanges the TGT for service tickets that
grant access to specific application servers.
Workflow Overview
1. TGT Request – User sends AS a request encrypted with a hash of their
password.
 2. AS Response – Returns a TGT (encrypted with the KDC’s secret key) and a TGS
session key (encrypted with the user’s password hash).
3. Service Ticket Request – User presents the TGT and an authenticator
(timestamp encrypted with the TGS session key) to the TGS, requesting access
to a specific service.
4. TGS Response – Issues a service ticket (encrypted with the service’s secret
key) and a service session key (encrypted with the TGS session key).
5. Access – User sends the service ticket plus a new authenticator (encrypted
with the service session key) to the target server.
The tickets act as logical tokens confirming identity and authorizations without
revealing passwords.

Single Sign‑On (SSO) – Kerberos Authorization 🔑 (4.3.4)

Service ticket – Contains the user’s SID, group SIDs, timestamps, and the service
session key; it is encrypted for the target server and cannot be read by the client.

The server validates the ticket, decrypts the authenticator, and verifies
freshness (timestamp) to prevent replay attacks.
Mutual authentication may be performed: the server returns the timestamp
encrypted with the service session key, proving its own identity to the client.
Once authenticated, the server enforces its access control list (ACL) using the
group SIDs present in the ticket.

Federation 🌐 (4.3.5)
Federation – Enables trust between separate identity domains, allowing users to
access resources in another organization using their native credentials.

Typical Flow
1. Service Provider (SP) redirects the user to an Identity Provider (IdP).
2. User authenticates with the IdP and receives a claim token (signed by the IdP).
3. User presents the token to the SP.
4. SP validates the token’s signature (trust relationship) and maps the user to local
authorizations.
Federation expands access beyond internal employees to partners, suppliers, or
customers, often using claims‑based identity.

📜
Security Assertion Markup Language (SAML) 📜 (4.3.6)
SAML – An XML‑based standard for exchanging authentication and authorization data
(assertions) between an IdP and an SP.

Transport: HTTP/HTTPS with optional SOAP.

Security: Assertions are digitally signed using XML Signature, ensuring
integrity and authenticity.
Use case: Cloud providers (e.g., AWS) act as SPs, trusting corporate IdPs to
authenticate users without creating separate cloud accounts.

Open Authorization (OAuth) 🔐 (4.3.7)

OAuth – A protocol that enables delegated access to resources without exposing user
credentials, using access tokens.

Primary Roles
Role Description
Resource Owner End user who authorizes access to their
data.
Client Application requesting access (registered
with the Authorization Server).
Authorization Server Authenticates the user and issues access
tokens.
Resource Server Hosts the protected APIs; validates access
tokens.
Grant types (flows) vary by context (e.g., authorization code, client credentials,
implicit).
Tokens are often JSON Web Tokens (JWT) – Base64‑encoded strings
containing claims, optionally signed for integrity.
Simplified Flow
1. Client redirects user to Authorization Server for consent.
2. User authenticates and grants permission.
3. Authorization Server issues an access token (and optionally a refresh token).
 4. Client presents the access token to the Resource Server to access protected
resources.

Implementation Guidelines for Identity & Access

Management 📑
Align authentication design with confidentiality, integrity, and availability
goals.
Choose MFA or password‑less methods based on risk and usability; consider
hardware tokens, OTP apps, or biometrics (FAR/FRR/CER metrics).
Apply least‑privilege principles across discretionary, mandatory, RBAC, and
ABAC models; include conditional access (location, time).
Secure privileged credentials via PAM (JIT, vaulting, ephemerals) and conduct
privileged work on a SAW.
Use SAML for cross‑domain SSO where XML assertions are required; employ
OAuth for API‑centric, mobile‑friendly delegation.
Establish provisioning and de‑provisioning processes to manage digital
identities throughout their lifecycle.