15 Secret Key Lifecycle Management

15.1 Overview

This chapter specifies the management of secret keys in AMATELUS, particularly emergency procedures for: device theft, loss, damage, device replacement, account rotation, death, and guardianship.

15.1.1 Key Principles

1. Determinism Principle: Only operations with secret key signatures are cryptographically deterministic

2. Contactability Limit: Only reachable Issuers can respond; unreachable Issuers cannot help

3. Mathematical Safety Limit: Safe recovery of DIDs without identity credential linkage is impossible

15.1.2 Scenario Classification

Secret key issues fall into six categories:

1. Leakage: Secret key in hand, possibly compromised to third party

2. Loss with Abuse Concern: Suspected theft or compromise (backup available)

3. Loss without Abuse Concern: Device damage/loss without compromise risk

4. Update: Planned key rotation (both old and new keys available)

5. Death: Legal status change; key-copy accessibility remains unknown

6. Guardianship: Capacity-restricted individual under legal guardianship

15.2 Secret Key Leakage Response Flow

15.2.1 Preconditions

• Old secret key available: Holder still possesses possibly-compromised key

• Signature operations possible: Can cryptographically sign revocation requests

• Third party compromise suspected: Key copy may exist with attackers

15.2.2 Response Procedure

Step 1: Emergency Response Initiation

1. Holder generates new secret key pair \((newDID, newSK)\)

2. Holder creates revocation signature using old key:

   • Sign the complete emergency-revoke payload with the old-signer role, as defined below.

Step 2: Revocation Request to All Issuers

Holder prepares a separately addressed, signed request for each reachable Issuer:

KeyPayload = {
  version: 1, operation: "emergency-revoke",
  targetIssuer, oldDID, newDID?, scope,
  requestId, challenge?, issuedAt, expiresAt,
  reason, transitionDays: 0
}
oldSignature = Sign(oldSK, keyBytes(payload, "old"))

The old signature proves access to that key, including access by an attacker holding a leaked copy. It does not prove rightful ownership or authorize personal VC reissuance. Emergency disablement and identity recovery are separate actions.

Step 3: Issuer Processing

Each Issuer executes:

1. Verify the complete payload, operation, target issuer, signed scope, time window, challenge when required, and signature.

2. Atomically record the request ID and revoke only credentials within the signed scope that this issuer controls. Exact retries have no second effect.

3. Update and publish new Merkle Root

4. Apply the issuer’s compromised-key policy within its authority; a scoped credential revocation does not silently become a global DID blacklist.

5. Reissue personal credentials only after issuer identity-record verification binds old DID, new DID and scope, plus proof of control of the new key.

Step 4: Revocation Completion Verification

Holder confirms:

1. Check each Issuer’s MerkleRevocationList (VCs revoked)

2. List unreachable Issuers (unrevoked VCs remain)

Timeline

T=0:      Leakage detection
T=+5min:  New key generation, revocation signature
T=+30min: Revocation requests sent to all Issuers
T=+1h:    Issuer revocation processing complete (target SLA)
T=+24h:   Revocation confirmation, re-issuance begins

Security Characteristics

15.3 Secret Key Loss: Abuse Concern

15.3.1 Scenario

• Device theft, malware infection, or compromise suspected

• Old secret key unavailable, but backup recovery possible

15.3.2 Response

If backup recovery possible: Execute Section 3 (leakage response)

If no backup: Proceed to Section 5 (trust inheritance flow)

15.4 Secret Key Loss: Trust Inheritance Flow

15.4.1 Preconditions

• Old secret key unavailable (device lost/damaged)

• No abuse concern (device not stolen)

• New secret key pair generated

15.4.2 Case A: Identity Credential Available

Trust Inheritance Principle

Old DID (oldDID)
  └─ Identity VC (e.g., driver's license VC)
      └─ Issuer = Police/Municipality
      └─ Linked to real-world identity document

↓ Trust Inheritance

New DID (newDID)
  └─ DID Migration VC (DIDMigrationVC)
      └─ Issuer = Police/Municipality
      └─ Proves same-person relationship

Response Procedure

Step 1: Real-World Identity Verification at Municipality

Holder presents:

1. Physical identity document (driver’s license, national ID card, etc.)

2. New DID (newDID)

3. Old DID information if available

Step 2: Issuer Record Verification

Issuer checks:

1. Physical identity document authenticity

2. Past VC issuance records

3. Link between document and oldDID

Step 3: DID Migration VC Issuance

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "DIDMigrationCredential"],
  "issuer": "did:amatelus:police-station-tokyo",
  "issuanceDate": "2025-10-14T11:00:00Z",
  "credentialSubject": {
    "id": "did:amatelus:new456...",
    "oldDID": "did:amatelus:old123...",
    "migrationType": "trustInheritance",
    "migrationReason": "Device damage causing key loss",
    "verificationMethod": "Physical identity document verification",
    "identityDocument": {
      "type": "DriversLicense",
      "documentNumber": "123456789012",
      "issuerName": "Tokyo Public Safety Commission",
      "verifiedAt": "2025-10-14T10:30:00Z"
    }
  },
  "proof": {
    "type": "Dilithium2Signature2025",
    "verificationMethod": "did:amatelus:police-station-tokyo#key-1"
  }
}

Step 4: Re-issuance from Other Issuers

Holder presents to other Issuers:

1. DID Migration VC

2. New ZKP generated with newDID

Issuer judgment: Accept re-issuance following policy

Security Characteristics

15.4.3 Case B: No Identity Credential

Problem

• No cryptographic signature capability (old key lost)

• No real-world identity link in system

• Issuer cannot verify “who” was the oldDID owner

Mathematical Safety Limit Theorem:

Safe recovery of DIDs without identity credential linkage is information-theoretically impossible.

Issuer Policy Examples

Each Issuer must develop independent policy:

University Transcript VC:

• Present student ID at window

• Photo identification

• Cross-reference past issued transcripts

• Re-issue for new DID

Online Service Member VC:

• Confirmation code to registered email

• Security questions

• Cross-reference usage history

• Re-issue for new DID

Anonymous Service VC:

• No identity verification possible

• Re-issuance impossible

• Re-register as new user

Practical Conclusion

DIDs without identity-credential linkage are effectively unrecoverable if lost.

Preventive strategies:

1. Always obtain identity credential first

2. Maintain secret key backups in multiple locations

3. Use multi-device support

4. Perform periodic key updates

15.5 Planned Secret Key Update Flow

15.5.1 Preconditions

• Both old and new secret keys available

• Both key operations possible

• Planned update (not emergency)

15.5.2 Use Cases

1. Device replacement (new smartphone)

2. Multi-device support (PC and smartphone)

3. Periodic key rotation (security policy)

4. Backup device preparation

15.5.3 Procedure

Step 1: Dual-Key Relation Proof

1. Generate new secret key pair \((newDID, newSK)\)

2. Create dual-signature relation proof:

   • \(sig_{old} = \operatorname {Sign}(oldSK, keyBytes(p,\text{old}))\)

   • \(sig_{new} = \operatorname {Sign}(newSK, keyBytes(p,\text{new}))\)

Step 2: DID Update Notification

p = KeyPayload {
  version: 1, operation: "rotate", targetIssuer,
  oldDID, newDID, scope, requestId, challenge?,
  issuedAt, expiresAt, reason, transitionDays
}
request = { payload: p, oldSignature, newSignature }

Cryptographic guarantee:

• Both signatures prove consent by the controllers of oldDID and newDID; personal reissue additionally requires issuer-approved identity verification

Step 3: Issuer Processing (Flexible Options)

Option A: Issue new VC with new DID

• New VC with newDID as subject

• Keep old VC valid

Option B: Extend old VC validity

• Set transition period

• Next update issues new VC

Option C: Issue DID Update Credential

• Prove oldDID to newDID relation

• Allow other Verifiers to verify link

Step 4: Transition Period Management

Transition period (e.g., 30 days):
- Both old and new DIDs valid
- Holder can use either

After transition:
- Old DID VC revoked (optional)
- New DID primary

Security Characteristics

15.5.4 Multi-Device Scenario

Recommendation: Each device gets distinct DID

Device A (Smartphone):
  DID: did:amatelus:user123-mobile
  SK: SK_mobile

Device B (PC):
  DID: did:amatelus:user123-pc
  SK: SK_pc

Approach:
1. Assign unique DID per device
2. Use Section 5 procedure for each device
3. Request VCs from each Issuer for both DIDs
4. Identify with Issuer: "Same person, different devices"
5. Dual-signature verifies both key controllers consent
6. Issuer approval establishes the claimed same-subject reissue

15.6 Death of Holder

15.6.1 Death Is Not Key Destruction

Death establishes a person’s legal status, not the destruction of devices, backups, or leaked keys. A surviving copy can still produce valid signatures and proofs. The Lean state therefore reports unknown key accessibility after death; no theorem claims zero misuse risk or negligible damage.

The municipality follows its existing death-registration and issuance-record procedures. Each issuer acts on authenticated death evidence and its own scope. Where family or a legal representative is involved, a separately verified representative VC establishes the permitted actions. Neither possession of the deceased person’s key nor a death certificate makes the representative the original subject of personal qualifications.

Uncontacted issuers may retain active credentials. Verifiers observe the available status evidence and its age and apply their service policy. No universal online death registry or automatic global revocation is introduced. Incomplete revocation leaves residual risk even when the person has died.

15.7 Guardianship (Capacity Restriction)

15.7.1 Scenario

Holder becomes capacity-restricted (legal guardianship):

• Individual is alive and retains device access

• Judgment capacity is legally restricted

• Guardian has legal authority

Difference from death:

Death:
- Key copies may remain usable; revocation still matters

Guardianship:
- Secret key access: Possible (person alive) → Misuse risk exists
- Problem: Individual may sign inappropriate contracts
- Solution: Guardian can revoke/cancel contracts

15.7.2 Guardianship Initiation Flow

Family Court Guardianship Order

1. Application to family court (family member, prosecutor, etc.)

2. Family court review of capacity

3. Capacity evaluation

4. Guardianship order and guardian appointment

Municipality Guardian VC Issuance

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "GuardianCredential"],
  "issuer": "did:amatelus:city-hall-tokyo",
  "issuanceDate": "2025-10-14T14:00:00Z",
  "credentialSubject": {
    "id": "did:amatelus:guardian-789...",
    "guardianOf": "did:amatelus:ward-123...",
    "guardianType": "成年後見人",
    "authority": [
      "VC revocation request",
      "DID blacklist registration",
      "Contract cancellation",
      "Property management"
    ],
    "wardInfo": {
      "courtDecisionDate": "2025-10-01",
      "courtCaseNumber": "Reiwa 7 (Fam) No. 12345",
      "registrationNumber": "Reiwa 7 Guardianship No. 67890",
      "guardianshipStartDate": "2025-10-01"
    },
    "verificationMethod": "Court decision and registration certificate",
    "expirationDate": "2026-10-14T23:59:59Z"
  }
}

Key fields:

• guardianOf: Ward’s DID

• authority: Authority types

• courtCaseNumber: Legal case reference

• registrationNumber: Guardianship registry number

15.7.3 Guardian VC Notification to Issuers

Guardian notifies all Issuers:

1. Present Guardian VC

2. Request VC revocation

3. Request DID blacklist

Issuer processing options:

Option A: Complete revocation

• Add to MerkleRevocationList

• Add DID to blacklist

Option B: Conditional validity

• Mark as “under guardianship”

• Verifier requires guardian approval

• Small transactions allowed

Option C: Defer to Verifier

• No Issuer action

• Verifier checks guardianship

15.7.4 Verifier Guardianship Confirmation Flow

Recommended at contract time:

1. Receive ZKP from Holder

2. Check MerkleRevocationList (standard)

3. New: Query guardianship status

   • Call municipal guardianship confirmation API

   • Check if DID is under guardianship

Guardianship confirmation API:

GET /api/v1/guardianship/check/{did}

Response:
{
  "did": "did:amatelus:ward-123...",
  "underGuardianship": true,
  "guardian": {
    "did": "did:amatelus:guardian-789...",
    "type": "Legal Guardian",
    "guardianVC": {
      "issuer": "did:amatelus:city-hall-tokyo",
      "expiresAt": "2026-10-14T23:59:59Z"
    }
  },
  "restrictions": [
    "No new VC issuance",
    "Large contracts require guardian approval",
    "Small transactions (under 10,000 yen) permitted"
  ]
}

15.7.5 Contract Cancellation by Guardian

If ward makes inappropriate contract:

Legal Basis

Civil Code Article 9: “A person under guardianship may cancel their legal acts.”

Cancellation Procedure

1. Guardian identifies inappropriate contract

2. Presents Guardian VC to Verifier

3. Requests contract cancellation and refund

4. Verifier verifies Guardian VC and executes cancellation

Verifier verification:

1. Verify Guardian VC signature

2. Check authority includes “contract cancellation”

3. Verify contract was with ward’s DID

4. Execute cancellation and refund

15.8 Security Considerations

15.8.1 Key Leakage Attacks

Attack: Attacker uses leaked key to generate ZKP

Defense:

• Holder immediately revokes old DIDs

• Issuer revokes old VCs

• Verifier checks current MerkleRevocationList

Vulnerability window: Time between leak and revocation completion

15.8.2 Fraudulent DID Migration

Attack: Attacker claims old DID as their own for re-issuance

Defense:

• With old key signature: Operation-bound key consent only; leaked keys remain usable by attackers

• Without old key: Identity credential physical verification prevents fraud

• Without identity credential: No defense (information-theoretic impossibility)

15.8.3 Guardian VC Forgery

Attack: Attacker forges Guardian VC

Defense:

• Guardian VC issued by trusted municipality (cryptographic signature)

• Signature forgery requires breaking Dilithium2 (128-bit security)

• Recommended: Verify guardianship in legal registry API

15.9 Implementation Recommendations

15.9.1 Holder Responsibilities

• Store secret key in device secure storage (Keychain, TEE)

• Maintain encrypted backups in multiple locations

• Obtain identity credential before other VCs

• Update DIDs periodically (annually recommended)

• Keep Issuer contact list

• Test revocation procedures annually

15.9.2 Issuer Responsibilities

• Define and publish revocation SLA (e.g., 1 hour for high priority)

• Implement automatic signature verification

• Maintain up-to-date MerkleRevocationLists

• Provide 24/7/365 revocation acceptance (high SLA)

• Document DID migration trust policies

• Keep audit logs of revocation requests and completions

15.9.3 Verifier Responsibilities

• Report authenticated revocation evidence and its age, including unknown status

• Apply the local service freshness policy; do not impose a universal version-lag rule

• For guardianship scenarios: Query guardianship API

• Define transaction thresholds for guardian approval

• Process contract cancellation requests from guardians

• Log all guardian-related transactions

15.10 Formal Theorems

15.10.1 Operation Binding and Personal Reissue

The revocation entry point accepts only emergency revocation. The DID-update entry point accepts only rotation. Regression checks reuse actual payload-bound fixture signatures across operations and issuers and require rejection. personal_reissue_requires_identity_records proves that acceptance by the reissue entry point implies approval by the identity-record checker. The checker’s soundness and the signature backend remain implementation contracts. The old tagged evidence unions model assumed outcomes only.

15.10.2 Theorem: Recovery Impossibility Without Identity Credential

theorem recovery_impossible_without_identity_credential
    (holder : Holder)
    (oldDID : DID)
    (newDID : DID)
    (h_no_key : ¬holder.hasKey oldSK_old)
    (h_no_identity_vc : ¬∃ (vc : VC),
      vc.issuer.isIdentityAuthority ∧
      vc.subject = oldDID) :
  ¬∃ (issuer : Issuer),
    issuer.canVerifyRecovery oldDID newDID

Result: Safe recovery is information-theoretically impossible.

15.11 Policy Recommendation Summary

15.11.1 Revocation SLA

15.11.2 Identity Verification Standards

• Leakage/Update: Signature verification (automatic)

• Loss with ID VC: Physical identity document + record linkage

• Loss without ID VC: Issuer-specific policy or impossible

• Death: Municipal record linkage

• Guardianship: Court order + family court registration verification

15.11.3 Key Design Principles

1. Determinism when possible: Use cryptography to avoid judgment

2. Identity-first: Obtain identity credential before other VCs

3. Backup preparation: Require users to backup keys and test recovery

4. Transparency: Publish all policies and procedures publicly

5. Practical limits: Accept that some scenarios are unrecoverable

15.12 Resident VC Recovery and Seed Continuity

Use the existing real-world identity verification, issuance-record lookup and DIDMigrationCredential flow for resident VC recovery. The issuer restores the same national ID, seed and complete seed history into the new resident VC. The issuer retains protected records sufficient for that restoration. There is no separate seed-recovery protocol and no automatic seed rotation for device loss.

Relocation uses the resident-held old VC as continuity evidence for the receiving municipality, with recipient-bound confidential handover and proof of original issuance. Initial seed generation occurs at birth or first registration. Reissue, relocation, ordinary key rotation and new benefit events preserve the seed. Exceptional seed updates preserve signed history and category-local service restrictions as specified in the audit chapter.

Dual-key consent is not proof of a shared physical person. Same-subject reissue requires issuer approval; delegated presentations retain the principal/proxy roles. Recovery does not imply that every old credential is instantly revoked: the issuer processes the old qualification under its rules, and offline verifiers report the actual age and uncertainty of their evidence. Initial-registration deception is handled by municipal records and existing administrative procedures, not a new national AMATELUS deduplication infrastructure.

15.13 Canonical Key-Operation Requests

The signed preimage is RequestBinding.keyBytes. Every field is encoded as its decimal UTF-8 byte length, a colon, and its bytes. Nested records and lists are framed again as single fields; optional values have explicit none/some tags. DIDs use their canonical wire strings and numbers use unsigned decimal notation. The fixed field order is: domain AMT-KeyOperation-v1, version, operation, signer role, target issuer, old DID, optional new DID, scope, request ID, optional challenge, issue time, expiry time, reason, and transition days. Scope is either an explicit credential-reference list or all credentials issued by the target issuer. A signature over any older tuple is not a valid request in this profile.

An interactive profile requires an issuer-issued challenge bound to this payload and consumed atomically with its effect. An asynchronous profile may omit the challenge but still requires signed audience, request ID, expiry and issuer-local replay state. The receiver checks both signatures for rotation. Reusing a request ID with altered content is rejected; an identical verified retry is idempotent. The request ledger and state change must commit in one transaction. No shared cross-issuer registry is needed. Challenge state and the ledger are receiver-owned.

All personal credential reissue paths, including leakage, planned rotation and lost-device recovery, require the existing issuer identity-record check and new key-control evidence. A key signature alone permits only the specifically accepted key-management operation. Resident seed and history recovery follows the existing municipality procedure and does not rotate the seed merely because a key or device was replaced.