Architecture & Inner Workings

Privacy by Design & Technical Architecture

How UNONYM proves you are a real, unique human being — without knowing, storing, or sharing your identity.

1. The Core Principle: Zero-PII & Provider Attestation

Traditional identity services demand real names, ID card scans, phone numbers, or credit card details and store them centrally in databases. Such databases represent permanent security risks (honeypots for data breaches and state surveillance).

The UNONYM Invariant: Zero Receipt and Zero Storage of Raw Data

The UNONYM core backend receives zero raw personally identifiable information (PII) at any point. Neither phone numbers, residential addresses, real names, nor ID documents ever appear in API requests, logs, or database tables of the core system.

Step 1User & Client

Challenge & Verification

The user initiates verification (e.g. SMS OTP or ID card NFC). Raw data remains strictly inside the isolated provider channel.

➔ Raw data never leaves client unencrypted

Step 2Quarantine Provider

One-Way Hash & Signature

Verifies the challenge, computes HMAC-SHA256(data, PEPPER), and signs a short-lived proof token.

➔ Raw data immediately purged from memory

Step 3UNONYM Core

Sybil Resistance & Trust

Verifies token signature. Stores exclusively the pseudonymous hash (1:1 protection against duplicate accounts) and awards trust points.

➔ Identity remains 100% anonymous

2. System Architecture & Background Services

UNONYM is modularly structured. The separation of authentication, verification, and core logic ensures that no single service possesses the complete identity chain.

Identity & AuthOry Kratos

Ory Kratos (Identity Engine)

A hardened, open-source identity server. It manages user accounts, sessions, FIDO2/WebAuthn passkeys, TOTP two-factor authentication, and email verification. Passwords are never processed by the UNONYM backend, but hashed directly via state-of-the-art cryptography (Argon2id) in Kratos.

Core APINestJS + PostgreSQL

UNONYM Core API & Trust Engine

Manages trust points, reputation tiers, and public pseudonyms (e.g. uno_...). All endpoints are secured via Kratos session tokens. The database exclusively stores pseudonymous hashes, cryptographic proofs, and points.

Quarantine ServiceVerification Provider

Isolated Verification Provider

A separate quarantine microservice (port 3010, Docker-internal). It shields external verification interfaces (e.g. Firebase Phone Auth) from the core backend. It normalizes data, computes HMAC-SHA256 hashes using secret pepper keys, signs a short-lived proof token, and discards raw data immediately.

Mobile ClientFlutter (Android & iOS)

Flutter Companion App

Enables hardware-bound authentication (Play Integrity, Apple App Attest, passkeys via Credential Manager) and local biometric unlock (fingerprint / Face ID) directly in the smartphone’s Secure Element. Serves as the NFC interface for the digital national identity card (eID).

Infrastructure & Hosting in the EU

Hosting: Operated on dedicated cloud servers of Hetzner Online GmbH in Nuremberg (Germany). 100% European data sovereignty and strict GDPR compliance.
Network Security: Traefik edge proxy with automated TLSv1.3 encryption (Let's Encrypt). Internal services (database, verification provider, Kratos admin) are never directly accessible from the internet.
Cookie-Free Web Analytics: Self-hosted Umami Analytics without personal data collection, fingerprinting, or third-party trackers.

3. Detailed Verification & Protection Processes

A. Authentication via Passkeys (FIDO2 / WebAuthn) & App

Passkeys replace insecure passwords with asymmetric cryptography. When creating an account or registering a passkey, the end device (smartphone, laptop, or hardware key) generates a cryptographic key pair:

Private Key: Remains securely isolated inside the Secure Enclave / StrongBox of your device. It is never transmitted to UNONYM.
Public Key: Transmitted to Ory Kratos and stored there.
Biometrics (Face ID / Fingerprint): Merely unlocks access to the private key on the local device. Biometric templates never leave your device at any time.

B. Phone Number Verification (SMS OTP) Without Storing Phone Numbers

Phone numbers are legally bound to SIM cards and individuals, making them an excellent Sybil-resistance signal (preventing fake and bot accounts). But how does UNONYM ensure a number is only used once without storing it?

1. SMS Challenge: The user enters their mobile number on the web or in the app. Firebase delivers a one-time passcode (OTP) via SMS to the phone.

2. Confirmation: After entering the code, Firebase issues a cryptographically signed Firebase ID token.

3. Quarantine Hashing: The isolated verification-provider receives the token, extracts the verified number, normalizes it into international E.164 format (e.g. +49170...), and calculates:

credentialHash = HMAC-SHA256(e164_phone, PHONE_PEPPER)

The phone number is deleted from memory immediately following computation.

4. Duplicate Check & Trust Credit: The core backend receives exclusively a signed proof token containing the credentialHash. It checks whether this hash is already registered (unique index in PostgreSQL). If new, the hash is stored and +25 trust points are credited.

Result: Even in the event of a full database leak, no attacker can extract phone numbers. Yet the same mobile number can never be linked to a second UNONYM account.

C. German National ID (Online ID / eID via NFC)

Coming Soon

The German national identity card and electronic residence permit contain a BSI TR-03110 certified RFID security chip. With the UNONYM Companion App, it can be read contactlessly via NFC.

The Principle of Pseudonymous Identification (Restricted Identification):

Unlike traditional ID verification services (which require video verification or photo scans), UNONYM leverages the cryptographic capability of the ID chip:

Local PIN: The user enters their 6-digit ID PIN locally on their smartphone. Neither UNONYM nor the server ever receives this PIN.
Zero Personal Attribute Requests: UNONYM requests neither name, birth date, address, nor ID number.
Card- and Service-Specific Pseudonym: The ID chip mathematically derives a deterministic pseudonym valid exclusively for UNONYM.
Mathematical Proof: It is cryptographically guaranteed that this is a unique, living individual holding an official identity document — without UNONYM ever learning who they are.
EUDI Wallet Compatibility: The architecture is designed for the upcoming European Digital Identity Wallet (EUDI Wallet via OpenID4VP).

D. Device Integrity & Hardware Attestation

To eliminate botnets, modified emulators, and automated account farms, the UNONYM app uses hardware-based integrity services provided by mobile platforms:

Google Play Integrity (Android)

Cryptographic proof that the app originates unmodified from the Google Play Store and runs on a certified, non-tampered Android device.

Apple App Attest (iOS)

Hardware attestation via the Apple Secure Enclave chip confirming requests originate from an authentic, unmodified iOS app.

4. How External Services & Partners Integrate UNONYM

Websites, community platforms (such as Reddit subreddits), or news comment sections can integrate UNONYM via the standardized OpenID Connect (OIDC) protocol.

What does a partner learn during UNONYM login?

✓ The partner learns:

Confirmation: This is a real, unique human being.
The verified trust tier (e.g. Level 2: Phone + Device verified).
A partner-specific pseudonymous identifier (PPID), preventing different partners from cross-tracking user activity across platforms.

✗ The partner NEVER learns:

No real name or date of birth.
No phone number or email address.
No identity documents or physical addresses.
No IP address or device telemetry.