Lesson A14.1
Strong cryptography begins before an algorithm is selected. It begins with architecture questions: what are we protecting, where does trust cross a boundary, who owns the key, what happens when that key rotates, and how will the organization prove the design still works later?
This lesson uses fictional cryptographic architecture records and safe lifecycle metadata only. It does not require real keys, certificates, cracking, bypass, extraction, or attack testing.
Lesson Progress
High School Advanced • A14: Cryptography and Key Management Concepts • Lesson 1 of 10
Readiness Check
0/4 ready
Professional Hook
Imagine two systems both say “encryption enabled.” One has a named key owner, documented rotation, tested recovery, current certificate inventory, clear data classification, and monitoring. The other has an old key nobody owns and no record of what would happen during a restore. The technical label may look similar, but the architecture quality is completely different.
Cryptography becomes trustworthy when protection goals, key ownership, lifecycle, trust, resilience, and evidence all line up.
Learning Objectives
Explain cryptography as an architecture capability that supports confidentiality, integrity, authenticity, trust, and lifecycle rather than as a single feature called encryption.
Map where cryptographic protections belong across data in transit, data at rest, identity, application trust, software artifacts, backups, integrations, and recovery.
Evaluate fictional cryptographic design records using protection goal, owner, trust boundary, key or certificate dependency, lifecycle, resilience, and evidence.
Identify architecture risks such as unclear protection goals, duplicated key ownership, hidden legacy paths, missing recovery design, and stale cryptographic evidence.
Build a Cryptography Architecture Map that becomes the first artifact in the A14 Key-Management Design Recommendation.
Protection Goals
Who should be able to read this data, and under what conditions?
Examples
Sensitive application data, stored records, backups, transport between services.
Cryptographic role
Encryption can reduce unauthorized disclosure when keys and access boundaries are governed correctly.
Important caution
Encryption does not automatically solve authorization, ownership, retention, or recovery.
How can the architecture detect that data or an artifact changed unexpectedly?
Examples
Configuration packages, files, software artifacts, stored records, messages.
Cryptographic role
Hashing or digital signatures can help provide integrity evidence depending on the trust goal.
Important caution
A hash alone does not prove who created the data.
How can the system gain confidence about the identity of a signer, service, or endpoint?
Examples
Signed software, service identity, trusted web endpoints, partner integrations.
Cryptographic role
Digital signatures and certificates can support authenticity when trust relationships are valid.
Important caution
Trust depends on key ownership, certificate lifecycle, and validation, not just the presence of a signature.
What cryptographic relationship allows one system to trust another?
Examples
Certificate chains, service certificates, signing keys, federation-related service trust.
Cryptographic role
Certificates, public keys, and signing relationships can help establish bounded trust.
Important caution
Trust should be scoped and lifecycle-managed rather than treated as permanent.
How will keys and certificates be issued, stored, rotated, renewed, recovered, revoked, and retired?
Examples
Application keys, storage keys, signing keys, partner certificates, recovery keys.
Cryptographic role
Key and certificate management turns cryptography from a one-time configuration into a sustainable control.
Important caution
A strong algorithm with weak lifecycle governance can still create serious risk.
What happens when a key, certificate, provider, device, or recovery path becomes unavailable?
Examples
Certificate expiration, key rotation, backup restoration, service migration, disaster recovery.
Cryptographic role
Recovery and redundancy planning preserve secure operations during change or failure.
Important caution
Recovery must not become a permanent bypass around normal trust controls.
Data States
Data moving between users, applications, services, networks, or external partners.
Design questions: Which endpoints communicate? What identity or service trust is required? Who owns the certificate or trust relationship?
Data stored in databases, object storage, local disks, file systems, archives, or backups.
Design questions: What storage contains sensitive data? Which key protects it? Who owns the key? What happens during restore?
Data actively processed by an application or service.
Design questions: Which identities and workloads are allowed to process the data? What does cryptography not protect once authorized processing begins?
Copies stored for restoration, continuity, or archive purposes.
Design questions: Are backup copies protected consistently? Can recovery succeed if the key lifecycle changes?
Reports, files, or data packages leaving the normal application boundary.
Design questions: Who can create exports, where are they stored, how are they protected, and what integrity or disclosure controls apply?
Information exchanged with partner systems, APIs, queues, or service-to-service workflows.
Design questions: Which service identities, certificates, transport protections, and partner trust relationships are required?
Architecture Placement
Protect application sessions, sensitive workflows, software artifacts, and application-owned data relationships.
Examples: Protected web sessions, signed application packages, application-level secrets governance.
Typical owner: Application Team / Application Security
Protect databases, storage services, exports, archives, and backups.
Examples: Storage encryption, backup protection, data-classification-driven crypto requirements.
Typical owner: Data Platform / Storage Owner
Support service identity, endpoint trust, signing relationships, and certificate lifecycle.
Examples: Certificates, public-key trust, service authentication relationships.
Typical owner: Identity / PKI / Platform Security
Protect platform services and infrastructure-managed storage or transport boundaries.
Examples: Managed encryption services, platform key stores, protected administrative connections.
Typical owner: Cloud / Infrastructure Security
Protect partner, vendor, API, and service-to-service trust relationships.
Examples: Partner certificates, service identity, protected transport, signed artifacts.
Typical owner: Integration Owner / Service Owner
Preserve confidentiality and trust while supporting backup restoration, disaster recovery, and service migration.
Examples: Recovery keys, backup-key dependencies, certificate renewal during recovery.
Typical owner: Resilience / Platform / Security
Ownership
Defines sensitivity, business purpose, retention, and acceptable disclosure risk.
Defines how the application uses cryptographic services and what data flows require protection.
Is accountable for key purpose, lifecycle, storage class, rotation, recovery, and retirement.
Is accountable for certificate identity binding, renewal, expiration, revocation, and relying services.
Operates the service or infrastructure where cryptographic controls are implemented.
Defines policy, approved standards, exceptions, review cadence, and evidence expectations.
Architecture Principles
Choose cryptographic controls because they solve a defined confidentiality, integrity, authenticity, trust, or lifecycle problem.
Review: Can the team state exactly what the cryptographic control is supposed to protect?
Encrypted data can still be overexposed to identities that are legitimately allowed to decrypt or use it.
Review: Are identity and access decisions governed separately from encryption?
The key that protects data has ownership, lifecycle, storage, recovery, and dependency requirements.
Review: Can the design explain who owns the key and what happens when it rotates or becomes unavailable?
Certificates are not only files; they connect identities, public keys, issuers, validity, and relying services.
Review: Can the team explain who trusts the certificate and why?
Protection should follow where data crosses between users, services, systems, environments, or organizations.
Review: Does the map show where data crosses a boundary and what cryptographic relationship protects it?
A backup is not recoverable if its required key is lost or inaccessible during restoration.
Review: Can the organization restore protected data under realistic recovery conditions?
Keys and certificates age, rotate, expire, move, and retire.
Review: Does the architecture have defined lifecycle events and evidence?
Inventories, renewal records, rotation status, source health, and owner confirmation help verify that the cryptographic design is still valid.
Review: Is current evidence available, or is the team relying on old assumptions?
Vocabulary
The use of mathematical techniques and managed trust relationships to support goals such as confidentiality, integrity, authenticity, and secure communication.
A reversible protection process that transforms readable information into a protected form using a key.
A one-way transformation used to produce a fixed-size digest that can support integrity and related security goals.
A cryptographic mechanism that can provide evidence about integrity and signer authenticity.
A structured trust object that binds identity information to a public key under an issuing relationship.
Cryptographic material used by an algorithm to perform operations such as encryption, decryption, signing, or verification.
The sequence of generation, approval, storage, distribution, use, rotation, recovery, revocation or retirement, and evidence.
A point where data, identity, or responsibility crosses between systems, environments, organizations, or control domains.
A system relationship that depends on a key, certificate, trust anchor, or cryptographic service to function securely.
The planned replacement of cryptographic key material or related trust objects according to policy or event triggers.
The process of marking a certificate, key relationship, or trust object as no longer acceptable before its normal end of life.
A governed record of cryptographic assets, owners, purposes, dependencies, lifecycle states, and evidence.
Fictional Architecture Register
Data
Student support session data
State
In transit
Protection goal
Confidentiality + service authenticity
Trust boundary
Browser ↔ Student Services Portal
Crypto dependency
Managed service certificate + transport protection
Key / trust owner
Platform Security
Data owner
Student Services
Lifecycle
Certificate renewal + endpoint policy review
Resilience
Renewal monitoring + emergency replacement path
Evidence
Current certificate inventory + endpoint monitoring
Architecture concern
Application authorization still determines which signed-in users may access student-support functions.
Data
Student support records
State
At rest
Protection goal
Confidentiality
Trust boundary
Database storage boundary
Crypto dependency
Managed storage encryption key
Key / trust owner
Data Platform
Data owner
Student Services
Lifecycle
Managed rotation + ownership review
Resilience
Restore procedure includes key availability
Evidence
Storage policy + key lifecycle metadata
Architecture concern
Encryption at rest does not replace database authorization or retention policy.
Data
Sensitive generated report
State
Export
Protection goal
Confidentiality + integrity
Trust boundary
Reporting platform → approved export storage
Crypto dependency
Protected storage + integrity evidence
Key / trust owner
Analytics Platform
Data owner
Analytics Product Owner
Lifecycle
Export policy review + storage key lifecycle
Resilience
Fallback export workflow documented but not recently reviewed
Evidence
Current policy + stale fallback review
Architecture concern
The primary protection is current, but fallback evidence needs review.
Data
Partner scheduling messages
State
Integration
Protection goal
Confidentiality + partner service authenticity
Trust boundary
Northbridge ↔ Scheduling Partner
Crypto dependency
Partner service certificate
Key / trust owner
Partner / Integration trust relationship
Data owner
Integration Owner
Lifecycle
Certificate renewal in 45 days
Resilience
Renewal owner and replacement window documented
Evidence
Current certificate + sponsor + renewal record
Architecture concern
Renewal must complete before expiration to avoid operational disruption.
Data
Historical reporting output
State
At rest + integration
Protection goal
Historical confidentiality
Trust boundary
Legacy application ↔ report storage
Crypto dependency
Legacy encryption key
Key / trust owner
Unknown
Data owner
Reporting Operations
Lifecycle
No current rotation evidence
Resilience
Recovery dependency unclear
Evidence
Partial inventory + stale documentation
Architecture concern
Unknown key ownership and unclear recovery dependency prevent confident governance.
Data
Encrypted production backups
State
Backup
Protection goal
Confidentiality + recoverability
Trust boundary
Production services → recovery repository
Crypto dependency
Recovery-bound encryption key
Key / trust owner
Resilience Team
Data owner
Multiple service owners
Lifecycle
Rotation coordinated with recovery testing
Resilience
Restore test includes key-access validation
Evidence
Current recovery test + key inventory
Architecture concern
Future key changes must continue to be tested with realistic restore procedures.
Data
Release artifact
State
Artifact
Protection goal
Integrity + authenticity
Trust boundary
Build system → deployment environment
Crypto dependency
Signing key + verification relationship
Key / trust owner
Release Engineering
Data owner
Application Team
Lifecycle
Signing-key rotation + release trust review
Resilience
Replacement signing process documented
Evidence
Artifact signature metadata + owner confirmation
Architecture concern
Verification must remain part of the deployment trust process rather than an optional check.
Fake Dashboard
Fictional protection goals, ownership, lifecycle, and evidence summary
Crypto records reviewed
7
Transport, storage, exports, integration, legacy, backup, and software-release protection
Confirmed
4
Modern transport, storage, backup, and release trust designs have current evidence
Conditional
2
Reporting fallback and partner certificate renewal need follow-up
Blocked
1
Legacy key ownership and recovery dependency are unresolved
Fake SOC Alert
Source: Fictional Cryptography Architecture Review • Time: 09:41
Cryptography vs. Authorization
Encryption protects data from parties that do not possess or cannot access the required key relationship. It does not decide whether a legitimately authenticated application user should have access to the underlying business data. Those are separate architecture questions.
Is data protected from unauthorized disclosure or change while it crosses or remains inside this boundary?
Which identity or workload is allowed to access the resource or perform the action after trust is established?
Fake Log Panel
[08:03] CRY-01 portal-transport cert=CURRENT owner=PLATFORM_SECURITY state=CONFIRMED [08:27] CRY-02 database-at-rest key_owner=DATA_PLATFORM lifecycle=CURRENT state=CONFIRMED [08:51] CRY-03 report-export fallback_review=STALE state=CONDITIONAL [09:16] CRY-04 partner-cert renewal_due=45d sponsor=CURRENT state=CONDITIONAL [09:41] CRY-05 legacy-key owner=UNKNOWN rotation=UNKNOWN recovery=UNKNOWN state=BLOCKED [10:05] CRY-06 backup-key restore_test=CURRENT state=CONFIRMED [10:29] CRY-07 release-signing verification=REQUIRED lifecycle=CURRENT state=CONFIRMED
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Common Design Mistakes
Why it fails: Teams deploy cryptographic controls without explaining what confidentiality, integrity, authenticity, or trust problem they solve.
Better approach: Define the protection goal first and then choose the cryptographic capability.
Why it fails: A team assumes encrypted data is safe even when too many identities are authorized to read it.
Better approach: Govern identity and authorization separately from cryptographic protection.
Why it fails: The design shows encrypted databases but never shows key ownership, rotation, or recovery dependency.
Better approach: Treat keys as first-class architecture assets.
Why it fails: Renewal, expiration, issuer trust, relying-service dependency, and ownership are ignored.
Better approach: Model certificates as lifecycle-managed trust relationships.
Why it fails: Backups are encrypted but restore plans never verify that the required keys are available during recovery.
Better approach: Test key availability as part of recovery design.
Why it fails: Old applications continue using keys or certificates nobody owns because modern inventory covers only new services.
Better approach: Keep legacy cryptographic dependencies visible until they are modernized or retired.
Why it fails: Development, staging, and production reuse cryptographic relationships without considering environment boundaries.
Better approach: Treat environment as part of scope and ownership.
Why it fails: A design is considered secure because it was reviewed years ago.
Better approach: Use current inventories, lifecycle evidence, owner confirmation, and review triggers.
Scenario Decision Lab
A legacy reporting application still works and its stored reports are encrypted, but nobody can identify the current key owner or confirm the recovery dependency.
Scenario Decision Lab
A partner service certificate is current and the integration is healthy, but the certificate expires in 45 days and renewal work is scheduled.
Safe Fictional Lab
Use fictional applications, data flows, certificates, keys, owners, and evidence only. Do not inspect, export, manipulate, or test any real cryptographic material.
Create at least fifteen fictional cryptography architecture records.
Give every record a stable CRY ID.
Record the system or service.
Record the data or artifact being protected.
Record the data state: transit, rest, use, backup, export, integration, or artifact.
State the protection goal.
Identify the trust boundary.
Record the cryptographic dependency type.
Assign a key, certificate, platform, or trust owner.
Assign a data or application owner.
Record lifecycle requirements.
Record rotation or renewal triggers.
Record recovery dependencies.
Record evidence source and freshness.
Classify status as Confirmed, Conditional, Unknown, Blocked, Accepted Risk, or Not Applicable.
Include at least three transit examples.
Include at least three at-rest examples.
Include at least two certificate trust examples.
Include at least two integrity/signature examples.
Include at least two recovery or backup examples.
Include at least one legacy cryptographic dependency and keep it Blocked if ownership is unresolved.
Add change triggers for application, environment, owner, key, certificate, provider, data classification, and recovery changes.
Lab boundary
Do not use real private keys, certificates, passwords, secrets, tokens, encrypted files, or production cryptographic settings. This lab is architecture mapping only.
Analyze the Evidence
Advanced Challenge
A fictional organization has encrypted databases, protected web sessions, partner certificates, signed release artifacts, and encrypted backups, but its diagrams omit key ownership, renewal dates, recovery dependencies, and environment boundaries. Redesign the architecture model conceptually.
Protection goals
Data states
Trust boundaries
Key ownership
Certificate ownership
Data ownership
Environment scope
Rotation triggers
Renewal triggers
Recovery dependencies
Backup key availability
Artifact-signing trust
Partner trust lifecycle
Legacy key inventory
Evidence freshness
Architecture decision states
The goal is not to add cryptography everywhere. The goal is to make every important protection decision explainable, owned, lifecycle-aware, recoverable, and supported by current evidence.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the first artifact for your A14 Key-Management Design Recommendation: a fictional Cryptography Architecture Map with at least fifteen records. Include CRY ID, system/service, data or artifact, data state, protection goal, trust boundary, cryptographic dependency, key/certificate/trust owner, data/application owner, lifecycle, rotation/renewal trigger, recovery dependency, evidence source, freshness, status, concern, next action, and change trigger.
Confidence / Readiness Reflection
A14.2 compares symmetric and asymmetric encryption concepts. Before continuing, make sure you can explain where encryption belongs in the architecture and why key relationships matter as much as the encryption mechanism itself.
I can distinguish confidentiality, integrity, authenticity, and trust goals.
I can map cryptography to transit, rest, backup, export, integration, and artifact states.
I can explain why key ownership and lifecycle are architecture concerns.
I can explain why encryption does not replace authorization.
I can keep legacy and stale cryptographic evidence visible instead of assuming it is safe.
Portfolio Build Guide
State whether the architecture is protecting confidentiality, integrity, authenticity, trust, lifecycle, or resilience.
Transit, rest, backup, export, integration, and artifact states often need different controls and owners.
Make it clear where data or identity moves between systems, environments, or organizations.
Do not draw an encrypted database or trusted service without showing what trust material the design depends on.
Data owner, application owner, key owner, certificate owner, and governance owner may be different.
Rotation, renewal, recovery, revocation, and retirement should appear as architecture events.
Current, Partial, Stale, Missing, and Unknown evidence should affect confidence.
A14.2 will use this map to compare symmetric, asymmetric, and hybrid encryption roles.
Key Takeaways
Lesson Safety Boundary
Do not attempt to crack encryption, recover keys, extract secrets, bypass certificate validation, downgrade protected connections, or manipulate real cryptographic systems. All keys, certificates, trust records, and evidence in this lesson are fictional.
Lesson Complete
You now have a system-level model for cryptographic protection, including goals, data states, trust boundaries, ownership, keys, certificates, lifecycle, recovery, and evidence. Next, A14.2 compares Symmetric and Asymmetric Encryption Concepts.