AP® Cybersecurity · Unit 5: Securing Applications and Data · Topic 5.3
Protecting Stored Data with Cryptography
Cryptography can transform readable stored information into protected data, help reveal unauthorized changes, and keep password verifiers safer—but its strength depends on appropriate algorithms, trustworthy implementations, and careful control of cryptographic keys.
What is data at rest?
Data at rest is information stored on a device or storage system rather than actively moving across a network or being processed in memory. Examples include files on a laptop, messages on a smartphone, records in a database, objects in cloud storage, backups, removable drives, and archived media.
Stored
A student record saved in a database, a photo on a phone, or a backup on offline media.
Moving
Data traveling between a browser and server, between cloud regions, or through a wireless network.
Being processed
Data opened by an application, held in memory, displayed to a user, or used in a calculation.
Storage encryption is mainly designed to reduce disclosure when storage, devices, files, snapshots, or backups are lost, stolen, copied, or accessed outside approved controls. Its exact protection depends on what is encrypted, when it is unlocked, where keys are held, and which threats the design addresses.
Cryptography vocabulary and purpose
| Term | Meaning | Practical idea |
|---|---|---|
| Plaintext | Original readable data supplied to a cryptographic operation. | A readable medical record before encryption. |
| Ciphertext | The transformed output of encryption, intended to be unreadable without authorized decryption. | Protected bytes stored on an encrypted drive. |
| Encryption | Transforms plaintext into ciphertext using an algorithm and key. | Protects confidentiality of stored cloud files. |
| Decryption | Uses an authorized key and algorithm to recover plaintext from ciphertext. | An approved application unlocks a record for an authorized user. |
| Algorithm | A defined mathematical process for a cryptographic operation. | A reviewed encryption standard specifies how transformations occur. |
| Cryptographic key | A secret or controlled value that determines a cryptographic result. | Different keys produce different ciphertext from the same plaintext. |
Conceptual notation: ciphertext C = EK(P) and plaintext P = DK(C). Here, P is plaintext, C is ciphertext, K is the key, E is encryption, and D is decryption.
Secure cryptography assumes the algorithm may be known; protection should depend on controlling the key, not on hiding how the algorithm works. Organizations should use widely reviewed, approved algorithms and maintained implementations rather than inventing their own ciphers.
Symmetric and asymmetric cryptography
| Feature | Symmetric cryptography | Asymmetric cryptography |
|---|---|---|
| Keys | One shared secret key is used for encryption and decryption. | A mathematically related public-private key pair is used; the private key must remain controlled. |
| Strength | Efficient for protecting large amounts of stored data. | Supports key establishment, key wrapping, and digital signatures without sharing a private key. |
| Challenge | Authorized parties need a secure way to receive or access the shared key. | More computationally expensive; public keys must be associated with the correct owner. |
| Typical stored-data use | Encrypt files, disks, database fields, devices, backups, and cloud objects. | Protect or transport symmetric data-encryption keys and verify signed software or records. |
Symmetric: one controlled secret
With symmetric encryption, the same secret key—or efficiently related working keys within a system—is used to protect and recover data. Because it is fast, symmetric cryptography is the usual choice for bulk storage encryption. Anyone who obtains the relevant secret key may be able to decrypt the protected data, so key access must be tightly limited.
Asymmetric: a key pair
A public key can be distributed, while the related private key remains controlled. Depending on the scheme, the public key can help protect a small secret for its owner or verify a signature made with the private key. Asymmetric cryptography is usually not used to encrypt an entire large backup directly.
Choosing the storage-encryption layer
The best layer depends on the asset, users, workflow, threat model, recovery requirements, and who controls the keys. Multiple layers may be appropriate, but complexity must remain manageable.
Full-disk encryption
Protects nearly all data on a disk when the device is powered off or locked. It is valuable for lost laptops and mobile devices, but data may be readable after an authorized user unlocks the device.
File and folder encryption
Protects selected content and may preserve protection when files are moved. It requires careful handling of filenames, metadata, sharing, copies, and recovery keys.
Database encryption
May protect storage volumes, database files, backups, or selected fields. Application and database authorization still determine who can query readable data.
Device encryption
Smartphones and tablets commonly integrate encryption with a screen lock and hardware-backed key protection. Strong lock settings, updates, and remote-management controls remain important.
Cloud storage encryption
Providers may encrypt storage by default, while customer-managed-key options provide different control. Organizations must understand key ownership, identity permissions, logs, regions, sharing, and deletion behavior.
Backup encryption
Backups, snapshots, and archives can contain complete data sets. Encrypt copies, separate key access, restrict operators, test restores, document retention, and preserve recoverability during incidents.
Removable media
Approved encrypted USB drives or other media can reduce disclosure if lost. Inventory, physical control, malware precautions, and secure disposal are still necessary.
Application-level encryption
An application can encrypt sensitive fields before they reach general storage. This may narrow exposure but increases key, search, indexing, access, and recovery design complexity.
Volume or container encryption
A protected volume groups selected data under one encryption boundary. Users must know when it is mounted, unlocked, copied, backed up, and safely closed.
Coverage question: identify the data → locate every copy → choose the encryption boundary → identify when plaintext exists → control keys and identities → test recovery and monitoring.
Hashing is not encryption
A cryptographic hash function accepts input of almost any size and produces a fixed-length digest. Hashing is designed to be one-way: there is no decryption key that converts the digest back into the original message. A secure hash should make it impractical to find an input matching a chosen digest or two different inputs with the same digest.
Conceptual notation: digest h = H(m), where m is the message and H is a cryptographic hash function. If the file changes, a new digest will almost certainly differ.
| Question | Encryption | Hashing |
|---|---|---|
| Reversible? | Yes, by an authorized party with the correct key and method. | Designed to be one-way; there is no decryption operation. |
| Main goal? | Confidentiality; authenticated modes can also detect tampering. | Fingerprinting and change detection; authentication requires a trusted digest, MAC, or signature context. |
| Output? | Ciphertext length depends on the data and scheme. | A fixed-length digest for a given hash function. |
| Password use? | Passwords generally should not be stored in reversibly encrypted form for routine verification. | Store a salt and output from a suitable, deliberately expensive password-hashing scheme. |
Safe password storage
Salt each password
A salt is a unique random value combined with a password before hashing. The salt does not need to be secret and is stored with the verifier. Unique salts cause identical passwords to produce different stored results and defeat simple precomputed lookup reuse.
Use a password-hashing scheme
A suitable password-hashing or key-derivation scheme includes a tunable cost that makes each guess more expensive. Store the salt, resulting verifier, algorithm/version, and cost—not the plaintext password. Raise the cost responsibly as computing improves.
Key management is the security system around the cipher
Strong mathematics cannot compensate for exposed, reused, unavailable, or unmanaged keys. A key-management lifecycle assigns owners, permitted uses, access, evidence, backup and recovery rules, and a cryptoperiod—the approved time or volume of use for a key.
- Generate and registerUse an approved source of randomness, suitable algorithm and key size, unique identifier, owner, purpose, and permitted operations.
- Store and useKeep keys separate from protected data when practical, limit access, use secure key stores, authenticate requests, and log sensitive operations.
- Rotate, back up, recoverReplace keys according to policy or risk; protect recovery copies, test authorized recovery, and retain old keys only while legitimately needed to decrypt retained data.
- Revoke and destroyStop use after compromise, role change, expiration, or retirement; re-protect affected data where needed and securely destroy keys and remaining copies when retention ends.
Hardware security module
An HSM is a dedicated hardware system designed to generate, protect, and use cryptographic keys within a controlled boundary. It can enforce policy and record key operations without routinely exposing raw keys to applications.
Trusted Platform Module
A TPM is a device security component that can protect device-bound keys and measurements. It often helps unlock disk encryption only when expected device and authentication conditions are satisfied.
Secure key stores
Operating systems, mobile secure hardware, cloud key-management services, and protected application vaults can limit key export and centralize permissions, rotation, auditing, and recovery.
Cryptography is a layer, not the whole defense
Weak or obsolete choices
Algorithms, modes, parameters, or key sizes may become unsuitable. Organizations need an inventory and migration plan, follow current authoritative guidance, and update systems before protections become unsafe or unsupported.
Unlocked data
Applications and users need plaintext to do work. Malware, excessive permissions, insecure exports, screenshots, or compromised sessions may expose data after authorized decryption.
Metadata and copies
Encryption may not protect filenames, sizes, access patterns, indexes, thumbnails, temporary files, logs, caches, snapshots, or old backups. Map the entire data lifecycle.
Authentication and authorization
Identity controls decide who may request decryption and what plaintext they may access. Encryption does not make a broad database role least-privileged.
Backups and availability
Encryption cannot reconstruct deleted, corrupted, or ransomware-affected data. Maintain isolated, protected backups and test restoration with the required keys and documentation.
Patching and monitoring
Secure software and configuration protect the cryptographic implementation. Logs and alerts help reveal unusual key use, mass decryption, failed unlocks, exports, and policy changes.
Defense in depth: classification + access control + strong authentication + appropriate encryption + protected keys + secure backups + patching + monitoring + tested response.
Real-world protection decisions
School records
A school encrypts database storage and backups, restricts decryption through role-based application access, uses MFA for administrators, and logs bulk exports. A lost backup cartridge reveals ciphertext, while tested recovery keys keep authorized restoration possible.
Medical and financial information
A service encrypts sensitive fields and volumes, limits key operations to approved services, separates key administrators from database operators, and uses authenticated encryption for confidentiality and tamper detection. Audit alerts flag unusual mass decryption.
Cloud files and mobile devices
A company uses managed mobile-device encryption, strong screen locks, remote lock capabilities, approved cloud storage, and carefully scoped sharing. Cloud key permissions and mobile recovery are reviewed so protection survives loss without blocking legitimate recovery.
Encrypted backups
A business stores encrypted backups in separate locations. Key recovery material is independently protected, inventoried, and tested during restore exercises. Retired copies and expired keys are destroyed only after retention, legal, and recovery requirements are confirmed.
Watch: cryptography for stored data
As you watch, identify the plaintext, ciphertext, key, protection goal, and one supporting control in each example.
Knowledge check: lock, hash, manage
What the quiz covers
These 10 questions test data at rest, plaintext and ciphertext, symmetric and asymmetric uses, storage-encryption limits, hashing and salts, integrity, envelope encryption, key lifecycle, hardware-backed storage, and defense in depth.
How it works
Answer every question, then choose Check my score. After submission, each question displays exactly one correct answer, your feedback and explanation, and you can restart for another attempt.
Study toolkit
For any cryptography scenario, identify five things: the data state, protection goal, algorithm type, key owner, and recovery plan. Extend your learning with this beginner’s guide to cryptography, explore related computer science resources, or organize revision with these AP® self-study strategies.
Cryptoperiod
The approved time span or amount of use for a cryptographic key.
Key wrapping
Protecting one cryptographic key with another suitable cryptographic key.
Digest
The fixed-length output produced by a cryptographic hash function.
Salt
A unique random value used with a password before password hashing.
MAC
A message authentication code uses a secret key to help verify integrity and authenticity.
Recovery key
A tightly protected key or mechanism that restores authorized access when the normal unlock path is unavailable.
Frequently asked questions
1. What does data at rest mean?
Data at rest is information stored on a device or storage service rather than actively moving across a network or being processed. Examples include files, databases, cloud objects, mobile-device content, snapshots, archives, backups, and removable media.
2. Does encryption always protect data integrity?
No. Basic encryption primarily protects confidentiality. An authenticated-encryption scheme can also detect tampering, while a suitable MAC or digital signature can provide integrity and authenticity in other designs. The system must handle verification failures safely.
3. What is the difference between symmetric and asymmetric encryption?
Symmetric encryption uses a shared secret key and is efficient for bulk data. Asymmetric cryptography uses a public-private pair and is commonly used for key establishment, protecting smaller keys, and digital signatures. Many systems combine them.
4. What does full-disk encryption protect?
It protects stored data against offline access when a device is powered off or locked, which is valuable after loss or theft. Once an authorized user unlocks the device, applications—and potentially malware—may access readable data.
5. Is hashing a form of encryption?
No. Encryption is reversible with an authorized key. Cryptographic hashing is designed to be one-way and produces a fixed-length digest. Hashes support fingerprinting and change detection, but a plain hash needs a trusted reference to provide useful integrity assurance.
6. Why are passwords salted before hashing?
A unique random salt makes identical passwords produce different stored results and prevents straightforward reuse of precomputed lookup tables across many accounts. The salt is stored with the verifier; security comes from a suitable password-hashing scheme and cost, not secrecy of the salt.
7. What happens if an encryption key is lost?
If no authorized recovery copy or alternate access path exists, the ciphertext may be permanently unrecoverable. Organizations should protect, inventory, separate, and test recovery material without making it an easy bypass around normal key controls.
8. What are HSMs and TPMs?
An HSM is dedicated hardware for protected key generation, storage, and cryptographic operations. A TPM is a device security component that can protect device-bound keys and measurements. Both reduce routine exposure of key material but still need policy, access control, updates, and recovery planning.
9. Should cloud providers or customers control encryption keys?
There is no universal answer. Provider-managed and customer-managed keys offer different operational control, responsibility, availability, cost, and risk. Organizations should evaluate data sensitivity, permissions, separation, logging, recovery, legal needs, and staff capability.
10. Why can’t encryption replace backups and access controls?
Encryption does not stop an authorized but overprivileged account from reading data, and it does not restore deleted or corrupted information. Least privilege, strong authentication, tested backups, patching, monitoring, and incident response address different failure modes.
Trusted references
- NIST SP 800-111—storage-encryption technologies for end-user devices.
- NIST FIPS 197—the Advanced Encryption Standard.
- NIST SP 800-57 Part 1 Rev. 5—general cryptographic key-management guidance.
- NIST SP 800-63B-4—current authentication and password-verifier storage guidance.
AP® is a trademark registered by the College Board, which is not affiliated with and does not endorse this page. This lesson is for defensive education. Use approved organizational tools and procedures; do not attempt to access keys or decrypt information without authorization.
