14 Audit Mechanism: Anonymous Hash Identifier (AHI)

14.1 Overview

This chapter specifies the optional audit mechanism within AMATELUS protocol. The Anonymous Hash Identifier (AHI) is used only when required by Issuer or Verifier, protecting citizen privacy while enabling audits based on legal procedures and accountability.

14.1.1 Key Premise: AHI is Optional

AHI is used only in the following cases:

1. Services requiring audit:

   • Tax and benefit services

   • Licensing and permits

   • Financial institution compliance

2. Anti-Sybil services:

   • Social networks (misinformation prevention)

   • Ticket sales (scalping prevention)

   • Online gaming (multi-accounting prevention)

3. Services explicitly requiring AHI

When AHI is not required, standard VC and ZKP mechanisms provide complete privacy.

14.1.2 Problem Statement

Traditional audit DIDs had critical vulnerabilities:

• Intentional key loss: Citizens could discard secret keys to evade tracking

• Cross-service linkage: Single audit DID creates profiling risks across services

• Privacy-security tradeoff: Difficult to balance audit capability with privacy

AHI resolves these through cryptographic binding to national identity numbers.

14.1.3 Design Goals

• Optionality: AHI is protocol-optional, not mandatory

• Privacy: Prevent government centralization of citizen information

• Anti-linkage: Prevent profiling across different services

• Audit guarantee: Make evasion technically impossible for audit-required services

• Legal alignment: Enable audits based on court warrants and legal procedure

• Global applicability: Work with or without national ID systems

14.2 Architecture

14.2.1 Actors and Roles

14.2.2 System Architecture

The audit mechanism involves three key components:

1. Audit Section Identifier: Public identifier issued by government for each audit purpose

2. Anonymous Hash Identifier: Hash computed as \(H(\text{AuditSectionID} \parallel \text{NationalID})\)

3. Zero-Knowledge Proof: Proves hash generation correctness without revealing NationalID

Critical: These components are used only when AHI is required.

14.2.3 National ID System Abstraction

AMATELUS does not depend on specific national ID schemes. Compatible systems include:

• My Number (Japan)

• Social Security Number (USA)

• National Insurance Number (UK)

• Other national identification schemes

For countries without national ID systems, AHI functionality is unavailable, but other AMATELUS features (VC, ZKP, DID) work normally.

14.3 Data Structures

14.3.1 Audit Section Identifier

structure AuditCategoryId where
  id : String
  purpose : String              -- e.g., "taxation", "benefits", "licensing"
  issuer : ValidDID             -- Government or audit authority DID
  issuedAt : Nat                -- Issuance timestamp
  deriving Repr, DecidableEq

Properties:

• Issued by government for each audit purpose

• Verifiable in public registry

• Guaranteed unique (UUID or random string)

• Example: "tax-2025", "subsidy-education-2025", "permit-building-tokyo"

14.3.2 Anonymous Hash Identifier

def generateAnonymousHashId
    (categoryId : AuditCategoryId)
    (myNumber : String) : ByteArray :=
  -- Post-quantum cryptography resistant hash function
  Hash.pqcHash (categoryId.id ++ "||" ++ myNumber)

Mathematical definition:

where \(H\) is a PQC-resistant hash function.

Properties:

• Uses post-quantum cryptography (SHA-3, BLAKE3, etc.)

• Service-specific identifiers (prevents cross-service linking)

• One-way function (irreversible)

• Collision-resistant

14.3.3 National ID Verifiable Credential

Important: This VC is required only when using AHI. Services not requiring AHI do not need it.

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "HouseholdCredential"],
  "issuer": "did:amatelus:city-hall-tokyo",
  "issuanceDate": "2025-10-14T00:00:00Z",
  "credentialSubject": {
    "id": "did:amatelus:citizen123...",
    "myNumber": "encrypted_my_number",
    "name": "Taro Tanaka",
    "address": "Tokyo, Shinjuku...",
    "birthDate": "1990-01-01"
  },
  "proof": {
    "type": "Dilithium2Signature2025",
    "verificationMethod": "did:amatelus:city-hall-tokyo#key-1",
    "proofValue": "..."
  }
}

Critical design:

• National ID is encrypted in VC’s data field

• Wallet decrypts only for AHI generation (when required)

• Services not requesting AHI never see the encrypted data

14.3.4 Zero-Knowledge Proof for AHI

structure AnonymousHashZKP where
  -- Public inputs
  publicInputs : {
    anonymousHashId : ByteArray        -- AHI
    categoryId : AuditCategoryId       -- Audit section ID
    vcIssuer : ValidDID                -- Household VC issuer DID
  }
  -- Secret inputs (used only within ZKP)
  witness : {
    myNumber : String                  -- National ID
    householdVC : HouseholdVC          -- Household VC
    vcSignature : Signature            -- VC signature
  }
  -- ZKP proof data
  proof : ZKProof
  deriving Repr

Proof contents verified within ZKP circuit:

1. householdVC.proof is valid (issued by municipality)

2. myNumber matches householdVC.credentialSubject.myNumber

3. anonymousHashId = Hash(categoryId.id || myNumber) computation is correct

4. vcIssuer matches householdVC.issuer

14.4 Audit Flows

14.4.1 Standard Flow: Without AHI (Privacy-Preserving Mode)

Most services use this flow. AHI is not required.

1. Citizen presents attribute proofs via ZKP (no personal information)

2. Service verifies ZKP

3. Service provides service

Sequence:

Citizen Wallet              Service Provider
    |                            |
    |--- ZKP (attribute) ------->|
    |                            |
    |                      ZKP verification
    |                            |
    |<------ Service provided ----|

In this flow:

• National ID is never used

• No hash identifiers created

• Complete privacy is maintained

14.4.2 Audit-Required Flow: With AHI

Only services explicitly requiring AHI use this flow.

Preconditions:

• Service provider explicitly requires AHI

• Citizen resides in country with national ID system

• Citizen possesses national ID VC

Flow:

1. Citizen presents ZKP (attribute proof), AHI, and ZKP(AHI validity)

2. Service verifies ZKP and AHI validity

3. Service records AHI (not national ID)

4. Service provides service

Sequence:

Citizen Wallet              Service Provider
    |                            |
    |--- ZKP + AHI + ZKP(AHI) ->|
    |                            |
    |                      ZKP verification
    |                      AHI validation
    |                      AHI recording
    |                            |
    |<------ Service provided ----|

Critical property: National ID remains non-disclosed (secret input within ZKP).

14.4.3 Audit Section ID Generation and Publication

This step is performed only for audit-required services.

1. Government/audit authority defines audit purpose

2. Generates unique audit section ID

3. Publishes to public registry

4. Service providers requesting AHI obtain the ID

5. Service notifies citizens that AHI is required

Examples:

• Government services: "tax-2025", "subsidy-education-2025"

• Private services: "sns-service-x", "ticket-sales-y"

14.4.4 AHI Generation Flow

1. Wallet obtains national ID from household VC

2. Wallet obtains audit section ID from government registry

3. Wallet computes: \(\text{AHI} = H(\text{AuditCategoryID} \parallel \text{NationalID})\)

4. Wallet generates ZKP proving valid hash without revealing national ID

5. Wallet presents AHI and ZKP to service provider

6. Service verifies ZKP and records AHI

Sequence diagram:

Citizen Wallet      Government Registry    Service Provider
    |                    |                      |
    |--- Request ID ---->|                      |
    |<------ ID ---------|                      |
    |                    |                      |
    |--- Compute AHI -----|                      |
    |--- Generate ZKP ----|                      |
    |                    |                      |
    |--- AHI + ZKP --------------------------->|
    |                    |                      |
    |                    |                  ZKP verification
    |                    |                  AHI recording
    |                    |                      |
    |<------------ Service provided ----------|

14.4.5 Fraud Investigation and Audit Flow

1. Fraud detection: Service provider detects suspicious activity

2. Report: Service identifies corresponding AHI

3. Legal request: Investigating agency requests disclosure

4. Court review: Court verifies legitimacy and issues warrant

5. Reverse lookup: Municipality matches AHI to national ID

6. Disclosure: Municipality reveals national ID to agency

7. Investigation: Agency identifies and investigates individual

Reverse lookup algorithm:

For each nationalID in municipality_database:
  if Hash(auditSectionID || nationalID) == suspicious_AHI:
    return nationalID  // Individual identified

Sequence diagram:

Service    Agency    Court    Municipality
    |        |        |            |
    |--fraud report->|            |
    | (AHI)         |            |
    |        |--disclosure------>|
    |        |   request         |
    |        |        |          |
    |        |        |---warrant|
    |        |        |          |
    |        |        |  reverse |
    |        |        |  lookup  |
    |        |<-----national ID-|
    |        |       |          |
    |--investigation-|          |

14.5 Private Sector Applications

14.5.1 Multi-Account Prevention

Services that may require AHI:

• Social networks

• Ticket sales platforms

• Online gaming

• Marketplace fraud prevention

Account registration flow:

1. Service generates and publishes service-specific identifier

2. Service notifies citizens: "AHI required for registration"

3. Citizen computes AHI from service ID and national ID

4. Service verifies AHI validity via ZKP

5. Service checks AHI uniqueness in database:

   • Duplicate found \(\Rightarrow \) Reject (multi-account prevention)

   • No duplicate \(\Rightarrow \) Accept and record AHI

Account ban enforcement:

• Service terminates account for policy violation

• Service blacklists corresponding AHI

• If same person attempts re-registration: Same national ID \(\Rightarrow \) Same AHI

• Service queries blacklist \(\Rightarrow \) Match found \(\Rightarrow \) Registration denied

• Result: Re-registration is prevented

14.6 Financial Institution Applications

14.6.1 Account Opening with AHI

Preconditions:

• Institution legally requires AHI (compliance mandate)

• Customer has national ID VC

Flow:

1. Institution generates purpose-specific identifiers

2. Institution notifies: "AHI required for compliance"

3. Customer computes AHI

4. Institution verifies AHI via ZKP

5. Institution links AHI to customer information (not national ID)

6. System enables cross-institutional AML tracking using AHI

Benefits:

• Money laundering prevention

• Traceability of high-value transactions

• Reduced national ID exposure risk

• Cross-bank transparency for regulatory compliance

14.7 Security Requirements

14.7.1 Hash Function

• Requirement: Post-quantum cryptography resistant

• Recommended: SHA-3, BLAKE3

• Properties:

  • One-way (preimage resistance)

  • Collision resistance

  • Second preimage resistance

14.7.2 Zero-Knowledge Proof

• Requirement: PQC-resistant ZKP scheme

• Proof contents:

  • Household VC validity

  • National ID possession

  • Hash computation correctness

• UX consideration: Pre-computation for minimal response time

14.7.3 Household VC Management

• Encrypted storage in wallet

• National ID tampering prevention

• VC issuer signature verification

14.7.4 Municipality National ID Management

• Warrant legitimacy verification

• Access logging for all reverse lookups

• Unauthorized access prevention

• Database encryption

• Multi-factor authentication for staff

14.7.5 Audit Section ID Management

• ID uniqueness guarantee

• Public registry verifiability

• ID misuse prevention (rate limiting)

14.8 Privacy Protections

14.8.1 Anti-Linkage Across Services

14.8.2 National ID Non-Disclosure

• Citizens never directly present national ID

• Service providers cannot learn national ID

• Only municipalities and investigating agencies handle national IDs

14.8.3 Evasion Prevention

• Even if citizen discards secret keys, audit is still possible

• AHI is deterministically derived from national ID

• Municipality can always reverse-lookup the AHI

• Intentional evasion is technically impossible

14.9 Legal and Regulatory Requirements

14.9.1 Warrant Issuance Standards

• Reasonable suspicion of fraud

• Investigative necessity and proportionality

• Privacy violation minimization

14.9.2 Disclosure Procedure Transparency

• Warrant issuance records

• Municipality disclosure execution logs

• Post-disclosure citizen notification (where legally permitted)

14.9.3 Social Consensus Formation

• Clear definition of audit-required services

• Appropriate audit section design and granularity

• Legal interpretation of national ID hash usage

14.10 Implementation Guidelines

14.10.1 Wallet Implementation

Required Functions

class AuditWallet where
  -- Household VC storage
  storeHouseholdVC : HouseholdVC → IO Unit

  -- AHI generation
  generateHashId : AuditCategoryId → IO ByteArray

  -- ZKP generation
  generateZKP : AuditCategoryId → IO AnonymousHashZKP

  -- Secure national ID storage (encrypted)
  secureStore : EncryptedData → IO Unit

Security Requirements

• National ID encryption: Use device secure storage (Keychain, TEE)

• Hash generation UX: One-click generation

• ZKP pre-computation: Minimize response time via offline generation

• Audit history: Local logging of when and which audit section identifiers were used

14.10.2 Service Provider Implementation

Database Schema

CREATE TABLE anonymous_hash_identifiers (
  hash_id BYTEA PRIMARY KEY,
  audit_category_id VARCHAR(255) NOT NULL,
  first_seen_at TIMESTAMP NOT NULL,
  service_data JSONB,
  is_blacklisted BOOLEAN DEFAULT FALSE,
  INDEX idx_category (audit_category_id),
  INDEX idx_blacklist (is_blacklisted)
);

ZKP Verification

def verifyServiceRequest
    (hashId : ByteArray)
    (zkp : AnonymousHashZKP)
    (categoryId : AuditCategoryId) : IO (Result ServiceToken) := do
  -- 1. ZKP verification
  if !verifyAnonymousHashZKP zkp then
    return .error "ZKP verification failed"

  -- 2. Audit section consistency
  if zkp.publicInputs.categoryId ≠ categoryId then
    return .error "Category mismatch"

  -- 3. Duplicate check
  if ← isDuplicate hashId then
    return .error "Duplicate registration"

  -- 4. Blacklist check
  if ← isBlacklisted hashId then
    return .error "Blacklisted hash"

  -- 5. Issue service token
  issueServiceToken hashId

Performance Optimization

• Parallel ZKP verification

• Short-term ZKP verification caching

• Index optimization on hash_id, audit_category_id, is_blacklisted

14.10.3 Municipality Implementation

Reverse Lookup

def reverseLookup
    (hashId : ByteArray)
    (categoryId : AuditCategoryId)
    (warrant : Warrant) : IO (Option String) := do
  -- 1. Warrant validity verification
  if !verifyWarrant warrant then
    return none

  -- 2. Access logging
  logAccess warrant hashId categoryId

  -- 3. Reverse lookup in national ID database
  for myNumber in ← getAllMyNumbers do
    let computed := generateAnonymousHashId categoryId myNumber
    if computed = hashId then
      -- 4. Disclosure logging
      logDisclosure myNumber hashId warrant
      return some myNumber

  return none

Security Requirements

• Warrant management system integration with real-time verification

• Complete access logging for all reverse lookups

• National ID database encryption at rest

• Multi-factor authentication and role-based access control

14.11 Formal Verification

14.11.1 Theorem: Anti-Linkability Across Audit Domains

theorem different_categories_prevent_linkability
    (myNumber : String)
    (cat1 cat2 : AuditCategoryId)
    (h : cat1.id ≠ cat2.id) :
  generateAnonymousHashId cat1 myNumber ≠
  generateAnonymousHashId cat2 myNumber := by
  -- By hash function collision resistance,
  -- different inputs produce different outputs
  apply Hash.collision_resistance
  simp [generateAnonymousHashId]
  exact String.append_ne_of_prefix_ne h

Result: Linking AHIs across services is computationally infeasible.

14.11.2 Theorem: Evasion Prevention

theorem audit_always_possible
    (citizen : Citizen)
    (myNumber : String)
    (cat : AuditCategoryId)
    (h1 : citizen.householdVC.credentialSubject.myNumber = myNumber) :
  ∃ (hashId : ByteArray),
    hashId = generateAnonymousHashId cat myNumber ∧
    canReverseLookup hashId myNumber cat := by
  -- As long as municipality maintains national ID database,
  -- reverse lookup is always possible
  exists generateAnonymousHashId cat myNumber
  constructor
  · rfl
  · apply municipality_has_database
    exact h1

Result: Audit is always possible via legal procedure.

14.11.3 Theorem: Privacy Preservation

theorem zkp_preserves_privacy
    (zkp : AnonymousHashZKP)
    (adversary : Adversary) :
  computationallyInfeasible
    (adversary.extractMyNumber zkp) := by
  -- By ZKP soundness property,
  -- secret inputs cannot be extracted from proof
  apply ZKP.knowledge_soundness
  apply ZKP.zero_knowledge_property

Result: Service providers and third parties cannot learn national IDs.

14.11.4 Cryptographic Security Summary

14.12 Future Research Directions

14.12.1 Technical Challenges

• PQC ZKP optimization (proof generation time and size)

• UX improvement for hash and ZKP generation

• Scalability for large-scale reverse lookups

14.12.2 Institutional Challenges

• Clear definition of audit-required services

• Legal framework for national ID hash usage

• Appropriate audit section granularity design

14.12.3 Standardization

• AMATELUS protocol detailed specifications

• Interoperability with other SSI systems

• International standardization (W3C, ISO)

Key Design Principles (Audit Mechanism)

1. Optionality: AHI is used only when required by service

2. Privacy by default: Services not requiring AHI provide complete privacy

3. Service-specific identifiers: Each service gets different hash, preventing profiling

4. Legal alignment: Audit is possible only via court warrants and legal procedure

5. Transparency: All reverse lookups are logged and auditable

6. Citizen control: Citizens retain cryptographic control over their identities

7. Non-repudiation: Service providers cannot deny or forge audit records