Security+ SY0-701 Cryptography and PKI: Encryption, Hashing, and Certificates

Introduction

Cryptography and public key infrastructure (PKI) support General Security Concepts, Domain 1 of Security+ SY0-701 (12%). Objective 1.4 covers choosing appropriate cryptographic solutions. This lesson connects encryption, hashing, signatures, certificates and key management to practical scenarios: protecting a laptop, authenticating a publisher and storing password verifiers. It builds on Security+ security controls and the CIA triad.

Learning objectives

After this lesson you will be able to:

• Compare symmetric and asymmetric encryption and choose between them for a scenario.
• Name common algorithms and key lengths (AES, 3DES, RSA, ECC, SHA-2, SHA-3) and recognize deprecated ones (DES, MD5, SHA-1).
• Explain hashing, salting, key stretching, and digital signatures.
• Describe a public key infrastructure: certificate authorities, registration authorities, CSRs, CRLs, OCSP, stapling, and certificate types.
• Choose the right encryption level: full-disk, partition, file, volume, database, record, or transport.
• Explain key management, HSMs, TPMs, key escrow, steganography, tokenization, masking, obfuscation, and blockchain basics.

1. Why cryptography: mapping to CIA

2. Symmetric encryption

Symmetric encryption uses one shared secret key for both encryption and decryption. It is fast and suited to large amounts of data.

Block versus stream: a block cipher processes fixed-size blocks (AES uses 128-bit blocks) in a mode of operation such as GCM or CBC; a stream cipher encrypts bit by bit or byte by byte. Authenticated encryption such as AES-GCM provides confidentiality and tamper detection when correctly implemented. Nonces must not repeat under the same GCM key, and authentication tags must be checked before accepting plaintext. AES-CBC alone does not provide integrity.

The weakness of symmetric encryption is key distribution: how do two parties agree on the key over an insecure channel? That is the problem asymmetric cryptography solves.

Example 1: encrypting a backup

A clinic backs up 2 TB of patient records nightly to cloud storage. The team encrypts the archive with AES-256 before upload. Use randomly generated data-encryption keys, with protected wrapping/key access through a KMS, rotation/versioning and a tested recovery process. Authenticated encryption suits bulk data; compliance depends on the complete implementation and applicable requirements, not the algorithm name alone. Losing the recovery keys also loses access to the backup.

3. Asymmetric encryption

Asymmetric encryption uses a key pair: a public key shared with everyone and a private key kept secret. Encryption, signatures and key agreement are different algorithm families and operations; do not treat every key pair as reversible encryption in both directions.

• Confidentiality: encrypt with the recipient's public key; only the recipient's private key decrypts.
• Authenticity and non-repudiation (signatures): sign with your private key; anyone verifies with your public key.

Real protocols combine mechanisms: authenticated key establishment and a key derivation function produce traffic secrets, then symmetric authenticated encryption protects data. Certificate-based TLS 1.3 commonly uses ephemeral Diffie-Hellman with signatures; it does not use legacy RSA key transport. Pre-shared-key modes also exist. See secure communications and enterprise architecture for where transport encryption fits.

Perfect forward secrecy (PFS) uses ephemeral key exchange (DHE or ECDHE) so that a later theft of the server's long-term private key does not reveal past sessions.

Key length and strength: longer keys resist brute force but cost performance. Symmetric: 128-bit AES is strong, 256-bit is a conservative choice. Asymmetric: RSA 2048 minimum. A common exam angle is that quantum computing threatens RSA and ECC, which motivates post-quantum algorithms; NIST finalised FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures) and FIPS 205 (SLH-DSA, signatures) in August 2024. A KEM establishes key material; it is not a signature algorithm or direct bulk-data cipher. Migration requires protocol compatibility, inventory and crypto agility rather than simply increasing an RSA key size.

Example 2: secure email to a lawyer

Maria wants to send a contract to her lawyer so only he can read it. She obtains his public key (from his certificate), encrypts the message, and sends it. If she also wants to prove it came from her, she signs it with her private key. The lawyer decrypts with his private key and verifies her signature with her public key.

4. Hashing

A hash function turns input of any size into a digest. Conventional cryptographic hashes have a fixed output size for the selected variant and aim for determinism, preimage resistance and collision resistance. Collisions necessarily exist because the input space is larger than the output space; the security goal is that finding one is infeasible. Small input changes should substantially change the digest.

Unkeyed hashing is not encryption and has no decryption operation. Attackers can still guess low-entropy inputs, hash them and compare; one-way does not mean an unknown password can never be recovered by guessing.

Uses: comparing files against trusted digests, deduplication, and building authenticated integrity schemes. An attacker who can replace both a file and its published digest can defeat an unkeyed comparison. Password storage needs a dedicated password-hashing scheme, not a fast generic hash alone.

HMAC (hash-based message authentication code) mixes a secret key into the hash so that only holders of the key can produce a valid tag; it authenticates data among holders of the shared key. Any holder can generate a tag, so an HMAC does not provide the same third-party origin evidence as a signature.

4.1 Protecting stored passwords

Storing plain hashes is not enough:

• Salt: a unique random value added to each password before hashing. Identical passwords produce different hashes, and precomputed rainbow tables become useless.
• Key stretching/password hashing raises the cost of each guess. Prefer an appropriate current scheme such as Argon2id for new general-purpose systems; scrypt and PBKDF2 serve other compatibility/compliance needs. Bcrypt remains common in legacy systems and has input-length limits that must be handled correctly. Benchmark memory/work settings for the actual service and record the algorithm, salt and parameters with the verifier.
• Pepper (secret value stored outside the database) can add a further layer.

Worked example: choosing how to store passwords

Scenario. A start-up stores user passwords as unsalted SHA-256. An attacker steals the database containing 500,000 hashes and runs a rainbow table; 40% of passwords are recovered in minutes.

1. Diagnose: SHA-256 is a sound hash, but it is fast and unsalted. Identical passwords yield identical hashes, so one lookup cracks every user with that password.
2. Fix design: use a maintained password-hashing library with a unique random salt and benchmarked work/memory parameters, for example Argon2id in a new general-purpose deployment. Store its encoded algorithm/parameters/salt/verifier; a hard-coded bcrypt cost of 12 is not a universal performance target.
3. Effect: per-user salts prevent reusing a single precomputed table across accounts, while costly verification slows each offline guess. Weak passwords remain guessable; timing depends on hardware, parallelism and parameters, so no fixed milliseconds-per-guess guarantee follows.
4. Why not encrypt the passwords? Encryption is reversible; whoever steals the key gets every password. The application verifies a candidate using the stored scheme; it need not recover the original password. A stolen verifier still permits offline guessing. Coordinate this with identity controls, MFA, and authentication workflows.
5. Why not MD5 with salt? Salting helps, but MD5 is extremely fast and collision-prone, so key stretching is still missing.

5. Digital signatures

A digital signature combines hashing and asymmetric cryptography:

1. A signing scheme processes the message, commonly using hashing as part of the scheme.
2. Its signing algorithm uses the sender's private key to produce a signature. This is not generally encryption of a digest; ECDSA and EdDSA, for example, are signature schemes.
3. The receiver uses the corresponding verification algorithm and a trusted public key to check the signature against the received message.

A valid signature supports integrity and origin authentication under the trusted key. Evidence supporting non-repudiation also depends on key custody, identity binding, timing and compromise/revocation records; a signature is not an unconditional guarantee of a person's intent. Signatures provide no confidentiality unless the message is also encrypted. Code signing uses this to prove that software comes from a publisher and was not modified.

6. Public key infrastructure (PKI)

How do you know a public key really belongs to www.example.com? A certificate binds a public key to an identity, signed by a trusted certificate authority (CA).

6.1 Components

Chain of trust: a browser trusts a root in its store; the root signed an intermediate; the intermediate signed the server's certificate. Validation checks the chain to a configured trust anchor, dates, permitted usages and the requested hostname (normally in SAN). Revocation processing varies with client policy, available mechanisms and cached status; do not assume every browser performs a fresh OCSP lookup for every handshake.

6.2 Certificate types

Important fields: subject, issuer, serial number, validity period, public key, signature algorithm, and key usage. Certificates expire; an expired certificate triggers browser warnings and outages, so inventory and automated renewal (for example with the ACME protocol) matter.

Example 3: certificate trouble in practice

A company renews its web certificate but the site still shows a trust error on some mobile phones. The server sends only its own certificate and not the intermediate. Some clients can use cached intermediates or fetch a missing intermediate; others cannot. Configure the server to present the leaf and required intermediates, usually omitting the already trusted root. If errors persist, also inspect hostname, dates, trust-store compatibility and usages.

7. Encryption levels and where to apply them

Remember that disk encryption protects a stolen powered-off laptop but not a logged-in session; file/database encryption can separate access only if the attacker lacks the relevant decryption authority. A compromised application account that can decrypt records may still read them.

8. Tools that hold or manage keys

• Trusted Platform Module (TPM): a hardware or firmware-backed platform security component that protects keys and supports measurements/sealing; it need not be a separate motherboard chip.
• Hardware security module (HSM): a hardened appliance or cloud service that generates and stores keys and performs cryptographic operations inside a protected boundary; non-exportability and controlled wrapped backup depend on the product and key policy. CAs and payment systems commonly use them.
• Key management system (KMS): central service for key lifecycle (create, rotate, retire, audit).
• Secure enclave: an isolated processor area for sensitive operations.

9. Other obfuscation and protection techniques

Blockchain is a distributed, append-only ledger where each block contains the hash of the previous block. Altering an old block changes its hash and breaks all later links, which provides hash-link tamper evidence. Consensus, validation rules and the network's trust assumptions determine how an accepted history is maintained; blockchain alone does not guarantee truthful input, confidentiality or absolute immutability.

Example 4: tokenization at a payment processor

An online shop must keep a customer's card for monthly billing. Instead of storing the 16-digit number, it stores a token such as tok_9f3a.... The processor's vault maps tokens to real numbers. If the shop's database leaks, the breach need not reveal raw card numbers. Tokens can still have operational value when combined with payment credentials or weak APIs; protect them and restrict detokenization/use. Tokenization may reduce payment-data exposure, but compliance scope depends on the complete design and assessment.

10. Comparison: choosing the right tool

11. Common pitfalls

• Saying hashing encrypts. Hashes are not decrypted, but low-entropy inputs can still be recovered by guessing and comparison.
• Choosing asymmetric encryption for bulk data because it sounds "stronger"; it is slow and hybrid designs exist for this reason.
• Signing with the public key or encrypting for confidentiality with your own private key. Memorize: encrypt with recipient's public; sign with sender's private.
• Treating a wildcard certificate as free of risk; one stolen key compromises every subdomain.
• Assuming self-signed certificates are insecure by cryptography; they are simply not trusted without out-of-band distribution.
• Confusing CRL (periodic list, can be stale) with OCSP (per-certificate, near real time).
• Keeping MD5 or SHA-1 for security uses.

12. Exam tips

• "Tamper evidence" or "file integrity" suggests hashing. "Proof of origin" suggests a digital signature.
• "Smaller key, same strength, resource-constrained device" suggests ECC.
• "Hide the data in a picture" is steganography; "replace with a random value, mapping stored elsewhere" is tokenization.
• "Dedicated tamper-resistant device that stores keys" is an HSM; the chip soldered onto the motherboard is a TPM.
• If passwords are stored and the question mentions rainbow tables, the answer includes a salt; if it mentions slowing brute force, the answer includes key stretching.

13. Mini case study

Case. Contoso Health runs a patient portal. Findings from an audit: (1) the portal's TLS certificate is a wildcard *.contosohealth.example copied to 14 servers; (2) the application stores passwords as MD5 hashes without salt; (3) lab results are exported as files on a shared drive with no integrity protection; (4) the laptops of home-visit nurses have no disk encryption.

Tasks. Recommend a fix for each finding and give the reason.

Solution.

1. Use separate service keys/certificates where appropriate, and protect private-key operations in a suitable HSM/KMS or managed termination service. A public certificate is not the secret; theft of a shared wildcard private key enables impersonation of covered names. Automate inventory and renewal.
2. Migrate to an appropriate salted password-hashing scheme. Rehash after successful legacy verification or use an authorised reset process; an old hash cannot be converted into a proper new password verifier without the password. Assess compromise and require prompt resets where exposure warrants them, rather than leaving dormant accounts indefinitely on MD5.
3. Distribute digests through a separately trusted channel, or sign exports with a protected lab signing key and trusted verification identity. A hash stored beside an attacker-editable export cannot authenticate the lab.
4. Enable platform-supported full-disk encryption with its appropriate TPM or equivalent platform key protection, and controlled, tested recovery-key escrow. This protects a stolen locked/powered-off device under the chosen threat model; it does not repair a compromised logged-in session.

Key terms

• Symmetric / asymmetric: one shared key versus a public-private key pair.
• Hash, salt, key stretching, HMAC: integrity and password storage tools.
• Digital signature: hash signed with a private key.
• CA, RA, CSR, CRL, OCSP: PKI components.
• TPM, HSM: hardware that protects keys.
• Tokenization, masking, steganography, obfuscation: data hiding techniques.
• Perfect forward secrecy: ephemeral keys protect past sessions.
• Blockchain: hash-linked ledger.

Summary checklist

• I can pick symmetric or asymmetric encryption for a scenario and explain the hybrid approach.
• I know which algorithms are current (AES, RSA 2048+, ECC, SHA-2/3) and which are deprecated (DES, 3DES, MD5, SHA-1).
• I can explain salting and work/memory costs, and distinguish Argon2id, legacy bcrypt and PBKDF2 use cases.
• I can describe how a digital signature gives integrity, authentication and non-repudiation.
• I can follow a certificate chain and differentiate CRL, OCSP and stapling.
• I can distinguish TPM from HSM, and tokenization from masking and steganography.
• I can choose the encryption level (disk, file, database, transport) for a threat.

Sources

• CompTIA Security+ SY0-701 exam objectives, objective 1.4: https://www.comptia.org/en-us/certifications/security/v7/ (opens in a new tab)

• NIST SP 800-57 Part 1, Key Management: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final (opens in a new tab)

• NIST FIPS 203, 204 and 205 (post-quantum standards, 2024): https://csrc.nist.gov/projects/post-quantum-cryptography (opens in a new tab)

• RFC 5280, X.509 certificate and CRL profile: https://www.rfc-editor.org/rfc/rfc5280 (opens in a new tab)

• NIST Digital Signature Standard: https://csrc.nist.gov/pubs/fips/186-5/final (opens in a new tab)

• NIST password verifiers: https://pages.nist.gov/800-63-4/sp800-63b.html (opens in a new tab)

• OWASP Password Storage: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html (opens in a new tab)