Unit 6: Cryptography and Data Protection

Lesson at a glance

| Item | Detail | | --------------------- | ------------------------------------------------------------------------------------------- | | Suggested length | 4 × 60 minutes | | Recommended placement | Weeks 9–10 of Cybersecurity I | | Prerequisite | Units 1–5 | | Materials | Kali VM, OpenSSL, two browsers (Chrome and Firefox), the certificate-inspection lab handout |

Safety: We use real cryptographic tools on lab data. We do not encrypt or hash anything containing real student or family data. The exercise file secret.txt is the only file you encrypt - no exceptions.

Standards & credential alignment

• EHE Domain 4: Cryptography fundamentals.
• VA CTE: Demonstrate understanding of encryption, hashing, and PKI.
• NIST FIPS 180-4 / FIPS 197: SHA / AES references for teacher background.

Learning objectives

By the end of this unit, students can:

1. Distinguish hashing from encryption from encoding.
2. Explain symmetric vs. asymmetric encryption and when each is used.
3. Compute and compare SHA-256 hashes from the command line.
4. Inspect a certificate in a browser and read its issuer, validity, and SAN list.
5. Explain what TLS is doing during the handshake at a high level.
6. Describe data-at-rest vs. data-in-transit vs. data-in-use protection.
7. Articulate why backups exist and what 3-2-1 means.

Vocabulary

• Plaintext / ciphertext - Readable / encrypted form of a message.
• Hash - One-way fingerprint. Same input → same output. Tiny change → wildly different output.
• Salt - Random data mixed into a password before hashing. Defeats rainbow tables.
• Symmetric encryption - One key encrypts and decrypts (AES).
• Asymmetric encryption - Public/private keypair (RSA, ECC). Encrypt with public, decrypt with private (or sign with private, verify with public).
• Digital signature - Proves who signed and that nothing changed since.
• Certificate - Signed assertion that "this public key belongs to this entity," signed by a Certificate Authority.
• PKI - Public Key Infrastructure. The whole system of CAs, certs, and trust.
• TLS / HTTPS - Transport Layer Security. The thing that makes the padlock real.
• Data at rest / in transit / in use - Stored / moving / being processed.

Teacher background

The biggest disservice you can do students in this unit is teach the math. The math doesn't help defenders defend. What helps:

• What does each primitive guarantee? Hashes guarantee integrity. Symmetric guarantees confidentiality (with a shared secret). Asymmetric solves key distribution and signatures. TLS combines all three.
• What goes wrong in the real world? Weak hashes (MD5, SHA-1). Weak ciphers (DES, RC4). Self-signed certs. Expired certs. Misconfigured TLS. Improper key storage.

The single most useful lab moment of the unit: have students change one character of a 1,000-word document and re-run the SHA-256. Watch the entire hash change. That is integrity, made visible.

Materials checklist

• [ ] Kali VM with openssl, sha256sum, gpg installed (defaults)
• [ ] Two browsers per student
• [ ] Lab handout with command sequences
• [ ] Worksheet PDF
• [ ] Wall poster: hashing vs. encryption vs. encoding

Pacing - Day 1 (60 min): Hashing

| Time | Segment | Notes | | ----------- | ------------------------------------------ | ----------------------------------- | | 0:00 – 0:20 | Mini-lesson - what hashing is and isn't | One-way, deterministic, fixed-size. | | 0:20 – 0:50 | Lab - sha256sum on the command line | Demonstrate avalanche effect. | | 0:50 – 1:00 | Mini-lesson - salting and password storage | Why bcrypt/argon2 matter. |

Day 1 - The hashing lab

# Create a test file
echo "The fox jumped over the lazy dog" > sample.txt
sha256sum sample.txt

# Avalanche effect - change ONE character
echo "The Fox jumped over the lazy dog" > sample.txt
sha256sum sample.txt

# Compare to the previous hash. Notice anything?

# What gets the same hash twice?
sha256sum /etc/hostname /etc/hostname

# Bonus - try MD5 (broken) and SHA-1 (broken) for comparison
md5sum sample.txt
sha1sum sample.txt

Land the line: "This is integrity. The download you got off the internet matches the hash on the official site, or it doesn't - and if it doesn't, you don't run it."

Pacing - Day 2 (60 min): Symmetric vs. asymmetric

| Time | Segment | Notes | | ----------- | -------------------------------------------- | -------------------------------------------- | | 0:00 – 0:20 | Mini-lesson - symmetric (AES) | One key, fast, requires secure key exchange. | | 0:20 – 0:35 | Mini-lesson - asymmetric (RSA/ECC) | Two keys, slow, solves key exchange. | | 0:35 – 0:55 | Lab - encrypt and decrypt with OpenSSL | Both modes. | | 0:55 – 1:00 | Discussion - when do real systems use which? | Hybrid (TLS uses both). |

Day 2 - Lab commands

# Symmetric: AES-256
echo "this is the plaintext" > secret.txt
openssl enc -aes-256-cbc -salt -pbkdf2 -in secret.txt -out secret.enc
# (you'll be prompted for a password)

cat secret.enc          # binary garbage
openssl enc -d -aes-256-cbc -pbkdf2 -in secret.enc -out secret.dec
cat secret.dec

# Asymmetric: RSA keypair
openssl genrsa -out alice.key 2048
openssl rsa -in alice.key -pubout -out alice.pub

# Encrypt with Alice's PUBLIC key - only Alice can decrypt
openssl pkeyutl -encrypt -pubin -inkey alice.pub -in secret.txt -out secret.rsa
openssl pkeyutl -decrypt -inkey alice.key -in secret.rsa

The classroom moment: ask "if Alice and Bob have never met, how does Alice send Bob a secret?" Walk it: Bob publishes his public key, Alice encrypts with it, only Bob's private key opens it. That is the entire revolution of asymmetric crypto.

Pacing - Day 3 (60 min): Certificates and TLS

| Time | Segment | Notes | | ----------- | ------------------------------------------------- | ------------------------------- | | 0:00 – 0:20 | Mini-lesson - what a certificate actually is | A signed assertion of identity. | | 0:20 – 0:50 | Lab - inspect a real certificate | Click the padlock. | | 0:50 – 1:00 | Mini-lesson - the TLS handshake at the high level | Five-step diagram. |

Day 3 - Certificate inspection lab

In Chrome (or Firefox):

1. Visit https://example.com.
2. Click the padlock → Connection is secure → Certificate is valid.
3. Read aloud: Subject (who the cert is for), Issuer (who signed it), Validity (start and end dates), SAN (Subject Alternative Names - what hostnames this cert is good for).
4. Look at the certificate chain: leaf → intermediate → root. The root is in your browser's trust store; that's why the padlock shows.

Extension: visit a self-signed development site (or a deliberately broken one like https://expired.badssl.com). Watch the browser warn. Discuss what an attacker would see if you clicked through.

Day 3 - TLS handshake (high level)

Client                                        Server
  | --- ClientHello (cipher suites, SNI) ----> |
  | <-- ServerHello + Certificate ------------ |
  | (verify cert chain against trust store)    |
  | --- Key exchange (ECDHE) ----------------> |
  | <-- Finished (encrypted) ----------------- |
  | --- Finished (encrypted) ----------------> |
  | <== Encrypted application data ==========> |

Land it: "The browser's job in milliseconds is to verify identity, agree on a shared secret, and start encrypting. The padlock only goes on if all three succeed."

Pacing - Day 4 (60 min): Data protection states + backups

| Time | Segment | Notes | | ----------- | ----------------------------------------- | ------------------------------------------ | | 0:00 – 0:25 | Mini-lesson - at rest, in transit, in use | What protects each. | | 0:25 – 0:45 | Lab - backup and restore drill | Tar/zip a folder, delete it, restore. | | 0:45 – 0:55 | Mini-lesson - 3-2-1 rule | And why immutable backups beat ransomware. | | 0:55 – 1:00 | Exit ticket | "What's the 3-2-1 rule?" |

Day 4 - The 3-2-1 backup rule

3 copies of your data. 2 different storage media. 1 copy offsite (or offline / immutable).

Discuss why ransomware operators specifically target backups: an attacker who deletes your backups and your live data has total leverage. Immutable / offline backups are the single most cost-effective defense your school could buy.

Common misconceptions

• "Encoding is encryption." - Base64 is encoding. Anyone can reverse it. There is no key. Encryption requires a key.
• "HTTPS proves the site is trustworthy." - HTTPS proves the site you're talking to controls the certificate for that hostname. It does not prove the content is honest. Phishing sites use TLS too.
• "Self-signed certs are fine for development." - They are, with the warnings. Teach students to never click through a TLS warning on production traffic.

Differentiation

• Math-anxious students: focus on what the primitives guarantee, not how.
• Stretch students: have them implement a one-way hash on paper using a simple algorithm, then break it.

Assessment

• Day 1 lab - screenshot of two hashes (different by one character) annotated.
• Day 3 lab - printed cert chain for one site, with subject/issuer/validity/SAN identified.
• Day 4 exit ticket - short answer rubric.

Career connection

PKI and crypto engineers are some of the highest-paid roles in cyber ($110K–$180K+). Even at the SOC analyst level, every TLS warning, every cert-pinning issue, every code-signing cert that expired at 3 AM is a ticket someone has to triage.

Homework / next class

Find one TLS warning in the wild this week. Take a screenshot. Identify which part of the handshake failed (expired? wrong hostname? self-signed? untrusted CA?). Submit next class.