Dependencies

The AMATELUS protocol is a cryptographic authentication mechanism integrating:

• Decentralized Identifiers (DIDs)

• Verifiable Credentials (VCs)

• Zero-Knowledge Proofs (ZKPs)

This chapter covers audit mechanism: anonymous hash identifier (ahi) aspects of AMATELUS.

This chapter covers trust chain architecture aspects of AMATELUS.

AMATELUS relies on the following cryptographic security assumptions:

• Collision-resistant hash: SHA3-512 provides 128-bit security against quantum adversaries

• Unforgeable signatures: Dilithium2 provides 128-bit security against quantum adversaries

• ZKP soundness: Standard zero-knowledge properties (completeness, soundness, zero-knowledge)

This chapter covers deployment models aspects of AMATELUS.

The did:amt method is a Decentralized Identifier (DID) that is algorithmically generated and resolved without reliance on any external Verifiable Data Registry (VDR) such as a blockchain. This method is designed for high-stakes environments (public administration, government) where data integrity and operational robustness are paramount.

This chapter covers implementation guidance aspects of AMATELUS.

This chapter covers secret key lifecycle management aspects of AMATELUS.

This chapter covers multi-device support aspects of AMATELUS.

This chapter covers privacy architecture aspects of AMATELUS.

This chapter covers merkle tree revocation aspects of AMATELUS.

This chapter covers formally verifiable json schema subset aspects of AMATELUS.

This chapter covers technical specifications aspects of AMATELUS.

This chapter covers trust architecture aspects of AMATELUS.

AMATELUS delivers the following cryptographic capabilities:

• Public key infrastructure (PKI) based distributed identifiers

• Zero-knowledge proof-based attribute ownership verification

• Verifiable credentials for claim issuance and storage

• Cryptographic trust guarantees

AMATELUS does not provide:

• Centralized directory services (DID resolution is local-only)

• Mediation or relay infrastructure

• User authorization decisions

• Communication endpoint management

• Message delivery guarantees

AMATELUS is a cryptographic authentication mechanism, not a communication infrastructure.

Man-in-the-Middle attacks are mitigated at the transport layer.

While AMATELUS provides cryptographic identity verification, ECDH-1PU authenticated encryption and TLS/HTTPS are the responsibility of service providers.

Replay attack prevention (preventing legitimate users from reusing the same ZKP) is NOT a responsibility of AMATELUS protocol. This is an application-layer responsibility.

Important distinction:

• Impersonation attacks (attacker with different secret key): PREVENTED by AMATELUS through DIDComm

• Replay attacks (legitimate user reusing same ZKP): NOT handled by AMATELUS. Applications requiring single-use semantics must implement nonce mechanisms.

Applications that require ZKP single-use guarantees should implement nonce handling at the application layer:

• Generate unique session nonces for each verification

• Record and verify nonce freshness (checking that the nonce has not been used before)

• Maintain nonce history in application database

Applications where ZKP reuse is acceptable (e.g., age verification, permission checks, one-time access grants) do not require additional replay prevention mechanisms.

Multiple DID possession is intentional protocol design for privacy protection.

While a single entity can control multiple DIDs, Anonymous Hash Identifiers (AHI) restrict per-audit-domain abuse through cryptographic binding to national identity systems.

The boundary between cryptographic verification (AMATELUS responsibility) and service provision (service provider responsibility) eliminates distributed infrastructure complexity while preserving cryptographic security properties.

A did:amt identifier is generated locally on the owner’s device without network registration.

The generation process consists of:

1. Generate Ed25519 key pair

2. Prepare information pair: AMT Version Number + Public Key

3. Select DID Document template corresponding to AMT version

4. Derive DID through local cryptographic operations

The resolution of a did:amt is completed locally by a verifier.

No external Verifiable Data Registry (blockchain, centralized service) or network calls are required. Verifier receives the [AMT Version Number, Public Key] pair from the owner and executes the same local derivation steps for verification.

Impersonation attacks (attacker with different secret key) are cryptographically prevented through DIDComm.

Mechanism:

• Verifier receives ZKP along with sender’s public key via DIDComm (senderDoc)

• ZKP must be cryptographically signed with secret key corresponding to this public key

• If attacker uses different secret key, the signature verification fails

• Attacker cannot reuse legitimate ZKP with different SK (cryptographically impossible)

Security guarantee: Impersonation attacks are prevented by DIDComm alone.

Impersonation attacks with different secret keys are cryptographically prevented.

If an attacker uses a different secret key to forge a ZKP, the signature verification will fail because DIDComm makes the sender’s public key known to the recipient.

Privacy is maintained despite public key transmission via DIDComm due to:

• Ephemeral Communication DIDs: Each session uses distinct DIDs with different key pairs

• Different services, different keys: User generates new keys for each service

• Cryptographic unlinkability: Public keys from different sessions cannot be linked (requires \(2^{128}\) quantum operations to link, assuming quantum-resistant hash functions)

• Service-specific communication DIDs: Verifier knows only the communication DID, not the user’s persistent identity DID

Result: While DIDComm requires public key disclosure for impersonation prevention, the use of ephemeral DIDs with distinct key pairs per service ensures cross-service unlinkability and privacy.

DIDComm establishes cryptographic certainty between ZKP and secret key correspondence.

By requiring explicit transmission of DIDDocument (containing public key), the protocol ensures:

• Verifier definitively knows which public key corresponds to the ZKP

• ZKP is bound to exactly one secret key (the corresponding private key)

• Any ZKP signed with different secret key will fail verification

Result: Cryptographic correspondence is certain, making impersonation impossible.