Identity, access and cryptographic protection
This domain tests the identity lifecycle and the mechanisms that turn an identity into an authorised action. Expect questions that separate authentication from authorisation and that ask which access control model fits a scenario.
Lifecycle and fundamentals
Identity management covers joiner-mover-leaver events: provisioning, role change with revocation of old entitlements, and timely deprovisioning. Identification claims an identity, authentication verifies it, authorisation decides what it may do, and accounting records what it did.
Factors are something you know (password, PIN), something you have (token, smart card, phone) and something you are (biometrics); location and behaviour act as contextual signals. MFA requires two different categories - two passwords are not MFA.
Access control models
- DAC - the owner can grant permissions under the system policy; its suitability depends on the control requirements rather than an automatic classification as weak.
- MAC - labels and clearances enforced by the system.
- RBAC - permissions bundled into roles; suits stable job functions.
- ABAC - attributes of subject, object, action and environment; suits fine-grained, context-aware rules.
- Rule-based and risk-based variants are common in cloud platforms.
Protocols
Kerberos uses a KDC and tickets (TGT, then service ticket) for single sign-on in Windows domains. SAML 2.0 carries federated authentication assertions. OAuth 2.0 delegates authorisation and issues access tokens; OIDC adds an identity layer on top. LDAP is a directory-access protocol with authentication operations such as Bind; it is not by itself a complete federated single-sign-on architecture.
Worked example
A finance clerk moves to sales. The correct sequence is: HR triggers the mover event, the RBAC role changes from finance-clerk to sales-rep, and finance entitlements such as shared drives, ERP roles and approval limits are reviewed and removed or explicitly justified under the approved transition plan. Keeping both roles "for convenience" creates a toxic combination that fails least-privilege and segregation-of-duties review.
Traps
- Claiming OAuth authenticates users; it authorises access, while OIDC authenticates.
- Confusing FAR and FRR: a stricter biometric threshold lowers FAR but raises FRR.
- Forgetting that privileged accounts need vaulting, session recording and just-in-time elevation.
- Leaving orphaned accounts after a leaver event because the ticket was closed early.
This domain tests which primitive solves which problem and how keys are handled across their life. Calculation questions are rare; selection and reasoning questions are common.
Primitives and their jobs
- Symmetric encryption - AES (128/192/256), SM 4, ChaCha 20. Fast, used for bulk data, requires a shared key.
- Public-key methods include suitable RSA-based schemes and elliptic-curve constructions, with distinct algorithms for encryption, key agreement and signatures. Authenticate keys and use appropriate padding or protocol design rather than treating every public-key operation as one cipher.
- Cryptographic hash examples include SHA-256 and SM 3; fixed-output variants produce a digest and are designed for preimage and collision resistance. A bare fast digest is not an appropriate password-storage construction.
- MAC/HMAC - integrity and authenticity using a shared key.
- Digital signature - use the specified signature algorithm with the signer’s private key and verify with the corresponding authenticated public key. A signature is not generically encryption with a private key. It supports integrity and origin evidence; non-repudiation also depends on key custody, validation and process.
Modes and common misuse
For confidential multi-block application data, ECB leaks repeated-block patterns: identical plaintext blocks produce identical ciphertext. Prefer authenticated modes such as GCM or CCM, or encrypt-then-MAC; encryption without integrity allows bit-flipping. Store passwords with a salted, slow KDF (bcrypt, scrypt, Argon 2, PBKDF 2 with high iterations), never with a fast hash or reversible encryption. Salt defeats rainbow tables; a pepper adds a secret kept outside the database.
Key management
Keys pass through generation, distribution, storage, use, rotation, archival, recovery and destruction. Use a KMS or HSM for root keys, apply split knowledge and dual control to the most sensitive material, and protect secret and private key material from exposure in code or configuration; authenticated public keys can legitimately be distributed. Under PKI, certificates move through enrolment, issuance by a CA, chain validation, revocation via CRL or OCSP, and renewal before expiry.
Worked example
Two banks exchange a large file and must prove origin. Generate a random AES-256 key, encrypt the file with AES-GCM, wrap the AES key with the recipient's RSA public key, then sign the hash of the ciphertext with the sender's RSA private key. The recipient unwraps the key, verifies the signature, then decrypts. Confidentiality, integrity, authenticity and non-repudiation each map to a named mechanism.
Traps
- Saying a hash encrypts data; hashing is one-way and irreversible.
- Signing with the recipient's public key, or encrypting with your own private key and calling it confidential.
- Reusing an IV or nonce with GCM, which destroys both confidentiality and integrity.