Destroy a key and confirm the data is unreadable

short · 50 min · Objective 4.5

Before you start — what this lab needs

OpenSSL on your own machine, with the key held as a file you control -- the one form of key you can destroy on demand. The commands this lab uses:

mkdir -p lab/crypto/.disabled && cd lab/crypto
openssl rand -out key.bin 32
openssl enc -aes-256-cbc -pbkdf2 -salt -in data.txt -out data.enc -pass file:key.bin
openssl enc -d -aes-256-cbc -pbkdf2 -in data.enc -pass file:key.bin

A managed key service (a cloud KMS, or an emulator of one) behaves differently at step 4, and the difference is part of the lesson; if you have one, repeat steps 3 and 4 there as well. The key and data are throwaway artefacts, which matters, because step 4 makes the ciphertext permanently unreadable by design.

Task

Crypto-shredding is the cloud's answer to secure erasure, and it is only convincing once you have done it. Encrypt data with a key you control, make copies, then destroy the key and confirm every copy is unreadable.

Steps

Write a line or two into lab/crypto/data.txt, create the key, encrypt, and confirm the decrypt command prints your text back.
Copy data.enc into three directories under lab/crypto/ -- backup/, snapshot/ and replica/ -- standing in for a backup, a snapshot and a cross-region replica. Confirm each decrypts.
DISABLE the key: mv key.bin .disabled/. The key still exists; nothing that looks for it can use it, which is what a KMS disable does. Attempt all three decryptions and record the failures in lab/crypto/shred.md. Then re-enable it (mv .disabled/key.bin .) and confirm all three decrypt again -- disabling is reversible, which is why it is the first response to a suspected compromise.
DESTROY the key: shred -u key.bin. Attempt all three decryptions again and record that nothing brings them back. Then record what a managed service does instead: it will not destroy a key on request. Scheduling deletion starts a waiting period of days (7 to 30 on AWS KMS) in which decryption already fails and the deletion can still be cancelled; only when it ends is the key gone. Write why a provider forces that wait on you.
Write the two sentences this proves: what crypto-shredding does to copies you cannot enumerate, and why a key missing in a destination region breaks a cross-region restore.

Verify

cd lab/crypto
for d in backup snapshot replica; do
  openssl enc -d -aes-256-cbc -pbkdf2 -in $d/data.enc -pass file:key.bin >/dev/null 2>&1 \
    && echo "$d: STILL READABLE" || echo "$d: unreadable"
done
test -e key.bin || test -e .disabled/key.bin && echo "a key file survives -- not destroyed"
grep -Eci 'disabl' shred.md
grep -Eci 'reversib|re-enabl' shred.md
grep -Eci 'waiting|pending|cancel' shred.md

Three "unreadable" lines and no surviving key file, after step 4. The notes must record decryption working again after the re-enable -- if it did not, the key was destroyed rather than disabled -- and the waiting period a managed service imposes. One caution the file version teaches that a KMS does not: on flash storage or a copy-on-write filesystem shred cannot promise the old blocks are gone, which is part of why a managed key is destroyed inside hardware built for it rather than as a file.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.