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 five 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: Permanent loss of physical access

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:

   • \(signatureByOldKey = \text{Sign}(oldSK, H(oldDID \parallel newDID \parallel timestamp))\)

Step 2: Revocation Request to All Issuers

Holder sends to all Issuers that issued VCs:

{
  "requestType": "revocationDueToLeakage",
  "oldDID": "did:amatelus:old123...",
  "newDID": "did:amatelus:new456...",
  "timestamp": "2025-10-14T10:30:00Z",
  "revocationReason": "Secret key leakage suspected",
  "signatureByOldKey": "signature(oldSK, hash(oldDID || newDID || timestamp))"
}

Cryptographic guarantee:

• signatureByOldKey cryptographically proves rightful old key owner

• Third party cannot forge signature (Dilithium2 security)

Step 3: Issuer Processing

Each Issuer executes:

1. Verify signatureByOldKey (reject if verification fails)

2. Add all VCs issued for oldDID to revocation list

3. Update and publish new Merkle Root

4. Permanently reject new VC requests from oldDID

5. (Optional) Re-issue VC for newDID following policy

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} = \text{Sign}(oldSK, H(oldDID \parallel newDID \parallel timestamp))\)

   • \(sig_{new} = \text{Sign}(newSK, H(newDID \parallel oldDID \parallel timestamp))\)

Step 2: DID Update Notification

{
  "requestType": "didUpdate",
  "oldDID": "did:amatelus:old123...",
  "newDID": "did:amatelus:new456...",
  "timestamp": "2025-10-14T10:30:00Z",
  "updateReason": "Device replacement",
  "transitionPeriod": "30days",
  "signatureByOldKey": "...",
  "signatureByNewKey": "...",
  "requestedAction": "issueNewVCWithNewDID"
}

Cryptographic guarantee:

• Both signatures prove oldDID and newDID owner is same person

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 proves same-person relationship

15.6 Death of Holder

15.6.1 Key Characteristics

• Secret key permanently inaccessible

• Misuse risk essentially zero (key cannot be used)

• Procedure depends on family status

• VC revocation incomplete but damages minimal

15.6.2 Case A: No Family

Municipal automatic processing:

1. Death registration at municipality

2. Link with VC issuance records via identity document

3. Add holder’s DIDs to municipality MerkleRevocationList

4. (Optional) Issue death certificate VC

Issuer Processing Limitations

• Municipality Issuers: Can revoke (access to death records)

• Private Issuers: Cannot revoke (no access to death records)

Security Impact:

• Private Issuer VCs remain valid

• But key is permanently unusable

• Misuse risk effectively zero

15.6.3 Case B: Family Present

Family-assisted processing:

1. Municipality issues legal representative VC (LegalRepresentativeCredential)

2. Family presents to each Issuer with representative VC

3. Issuer processes based on policy

4. Limited effectiveness (often not executed)

Security Impact:

• Some Issuers may revoke

• Unrevoked VCs remain

• Misuse essentially impossible (no key access)

• Damages minimal compared to leakage scenarios

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:
- Secret key access: Impossible → Misuse risk zero

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: Signature verification prevents fraud

• 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

• Always use current MerkleRevocationList

• Implement MAX_VERSION_LAG (recommended: 5)

• 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 Theorem: Leakage Recovery Determinism

With old key signature capability, revocation is cryptographically deterministic.

theorem leakage_revocation_possible
    (holder : Holder)
    (oldSK : SecretKey)
    (oldDID : DID)
    (newDID : DID)
    (timestamp : Nat)
    (h_possession : holder.hasKey oldSK)
    (h_sign : CanSign oldSK (hash (oldDID ++ newDID ++ timestamp))) :
  ∃ (revocationProof : RevocationProof),
    ∀ (issuer : Issuer),
      issuer.hasVC oldDID →
        Verifiable revocationProof ∧
        issuer.canRevoke oldDID revocationProof

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