Use Cryptographic Solutions for Security+ (SY0-701)

Understand PKI, encryption, hashing, digital signatures, obfuscation, and certificate workflows for the cryptography objectives on Security+.

Cryptography questions on Security+ are rarely about reciting algorithm names in isolation. CompTIA wants you to choose the right cryptographic tool for confidentiality, integrity, authentication, or non-repudiation and then understand the operational pieces around it, such as certificates, trust chains, and revocation.

PKI: Public key infrastructure, the certificate and trust-chain system used to bind identities to public keys.

HMAC: Hash-based message authentication code, which uses a shared secret to protect integrity and sender authenticity.

OCSP: Online Certificate Status Protocol, a way to check whether a certificate is still valid instead of relying only on local certificate lists.

The fastest mental model

Need Strongest first fit
Protect confidentiality of data at rest or in transit Encryption
Detect unauthorized changes Hashing or HMAC
Prove a sender or signer Digital signature and PKI
Hide implementation details without true secrecy Obfuscation
Validate certificate trust PKI, CA chain, CRL, or OCSP

What the exam is really testing

Security+ is usually testing one of these judgments:

  • do you know whether the problem is confidentiality, integrity, authentication, or non-repudiation
  • can you distinguish the algorithm family from the certificate or key-management workflow
  • can you recognize when the cryptography is technically present but operationally weak because the trust chain, expiration, or key handling is wrong

That is why a question about TLS may really be a certificate-lifecycle question, not an encryption-strength question.

PKI flow you should recognize

    flowchart LR
	  A["Root CA"] --> B["Intermediate CA"]
	  B --> C["Leaf certificate"]
	  C --> D["Server or user identity"]
	  D --> E["Client validates trust chain and status"]

What to notice:

  • the root does not usually sign every end-entity certificate directly
  • trust depends on the chain and the status of the certificate
  • expiration, revocation, and wrong subject names can all break trust

Crypto chooser table

Requirement Strongest first fit Why
Bulk data confidentiality Symmetric encryption such as AES Fast enough for real data movement
Key exchange or sender identity Asymmetric cryptography Supports trust and identity use cases
Message integrity plus shared-secret validation HMAC Detects tampering and proves the holder knows the shared secret
Public proof a file came from a trusted signer Digital signature with PKI Supports integrity and non-repudiation
Protect stored secret values from casual disclosure in logs or UI Masking or tokenization when the workflow fits Reduces exposure without always revealing the real value

Practical certificate inspection example

Security+ does not require deep command-line mastery, but it helps to recognize what certificate inspection looks like:

1openssl s_client -connect example.com:443 -servername example.com

What to notice:

  • this kind of command helps inspect the certificate chain and TLS negotiation
  • an investigator might use it to spot expiration, missing intermediates, or hostname mismatch
  • the exam may describe the outcome instead of showing the command directly

You can also inspect a local certificate file directly:

1openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName

What to notice:

  • subject and subjectAltName help confirm hostname fit
  • issuer helps verify where the cert sits in the trust chain
  • dates reveal expiration problems immediately

Certificate troubleshooting lens

When Security+ gives you a certificate failure, work through this order:

  1. Hostname fit: does the CN or SAN match the service the client is visiting?
  2. Validity window: is the certificate expired or not yet valid?
  3. Trust chain: are the intermediate and root trust relationships intact?
  4. Revocation status: is the cert revoked, or is revocation checking failing?
  5. Key handling: is the private key still under the right control?

Do not confuse these concepts

Concept What it is not
Hashing not encryption
Encoding not encryption
Digital signature not the same as encryption, even though public-key crypto is involved
Obfuscation not a substitute for real cryptographic protection

Blockchain and distributed trust

CompTIA includes blockchain in this domain as part of cryptographic solutions vocabulary. You do not need to become a cryptocurrency expert. You do need to understand the broader idea: tamper-evident chained records, cryptographic validation, and a design goal of integrity and trust across a distributed system.

Harder scenario question

A company signs internal software releases and distributes them through a private repository. An administrator wants users to verify that packages were produced by the approved build pipeline and were not modified in transit. Which design is strongest?

A. Encrypt every package with the same shared password and publish that password to the deployment team
B. Hash every package privately but do not publish the expected digest anywhere
C. Sign each release with the build pipeline’s private key and let clients verify the signature with the trusted public certificate
D. Base64-encode each package before upload so tampering is easier to spot

Best answer: C. The core requirement is integrity plus signer identity. A digital signature backed by a trusted certificate is stronger than shared-secret encryption, unpublished hashes, or encoding.

Common traps

  • saying Base64 is encryption
  • choosing hashing when the problem is confidentiality
  • assuming encryption alone proves who sent the message
  • forgetting certificate lifecycle issues such as renewal and revocation

What strong answers usually do

  • identify the security goal first before picking the cryptographic tool
  • separate algorithm choice from certificate and key-lifecycle handling
  • treat trust-chain health as part of the security answer, not just an implementation detail
  • remember that integrity, signer identity, and confidentiality are related but not interchangeable

Quiz

Loading quiz…

Continue with 2. Threats, Vulnerabilities & Mitigations to move from security vocabulary into attack paths and defensive reasoning.