Riassunto di architettura

I due pilastri

Pay-with-hand: l'utente si avvicina a un sensore, presenta la mano, e un pagamento viene autorizzato o un varco si apre. Niente carta, niente tap del telefono, niente PIN al momento del gesto. Il telefono può essere nella borsa, spento o assente.

Architettura privacy-preserving: quella comodità non è ottenuta costruendo un database biometrico centrale. La chiave privata dell'utente non lascia mai il telefono; ogni parte ricevente riceve uno pseudonimo contestuale, mai un identificatore globale; il livello biometrico è strutturalmente isolato da qualsiasi singola parte ricevente.

I due pilastri sono non negoziabili e accoppiati. Pay-with-hand senza l'architettura di privacy è un prodotto di pagamento generico; l'architettura di privacy senza pay-with-hand è un artefatto di ricerca. HamsaID li offre entrambi nello stesso sistema deployato.

Quattro livelli

Il sensore / terminale acquisisce le modalità palmari, esegue liveness e presentation-attack detection on-device, trasforma il vettore di feature con una transform key vincolata al contesto e inoltra una query trasformata attestata. I frame grezzi non lasciano mai il sensore.

Il telefono, l'Identity Broker, custodisce un seme privato in storage hardware-backed, gestisce il consenso, deriva pseudonimi contestuali ed emette authorization capsule. Non vede dati biometrici grezzi o il corpus di risoluzione.

Il Biometric Resolution Core confronta query trasformate contro la partizione del contesto pertinente. Non custodisce identità civile, dati di pagamento, il seme dell'utente o chiavi di firma delle capsule.

La parte ricevente riceve solo uno pseudonimo contestuale, una decisione di accesso o un riferimento a network token di circuito. Mai la biometria grezza, mai un identificatore globale.

Authorization capsule: il motore del pay-with-hand

La capsule è l'oggetto tecnico che permette all'utente di essere presente al varco o al POS mentre il telefono è assente. Il telefono emette una credenziale scoped, revocabile, temporanea, firmata con una chiave custodita dal telefono derivata dal seme per quella parte ricevente, e la registra presso il registro di autorizzazione.

Ogni capsule codifica la parte ricevente, lo scopo (pagamento / accesso / presenza), la classe di terminale, la finestra di validità, la policy di rischio (tetti per transazione e giornalieri per i pagamenti), lo pseudonimo contestuale e un revocation pointer. Non contiene né il seme né materiale biometrico.

Al punto di contatto, il policy layer verifica la capsule e i tetti di rischio online. Sopra le soglie di step-up PSD2 (tipicamente €30 per singola transazione con limiti cumulativi), il telefono è richiesto per ri-confermare. Sotto quelle soglie, la capsule è sufficiente. Il telefono può non essere presente.

Claim di privacy stratificato: perché l'MVP è onesto al riguardo

Il livello di autorità dell'utente (pseudonimi, capsule, consenso, audit, recovery) è end-to-end controllato dall'utente e crittograficamente non collegabile tra contesti. La stessa persona appare come un soggetto non correlato a due esercenti non correlati per costruzione, perché ogni pseudonimo è derivato dal seme usando l'identificatore della parte ricevente come input di domain-separation.

Il livello biometrico è operator-isolated e partizionato. Il corpus di risoluzione è suddiviso in partizioni per contesto; non c'è un join a livello di schema che collegherebbe l'handle di un utente in una partizione al suo handle in un'altra. Le query cross-partizione non sono solo vietate dalla policy: nessun percorso di codice è in grado di eseguirle.

Framing onesto dell'MVP: l'utente deve fidarsi che HamsaID operi il resolution core onestamente nel proprio ambiente di esecuzione hardware-attested. L'utente non deve fidarsi di HamsaID, di un esercente o di un partner rispetto alla correlazione cross-contesto. Questo è chiuso dall'architettura, non da una promessa.

Roadmap: chiudere per costruzione la fiducia in un singolo operatore

La versione full-fledged sostituisce l'isolamento hardware presso un singolo operatore con Secure Multi-Party Computation tra tre operatori legalmente e operativamente separati. I template sono secret-shared; nessun nodo detiene un template completo in alcun momento; il matcher gira come protocollo multi-party.

La re-randomization contribuita dal telefono in fase di enrolment chiude il gap di correlazione cross-contesto che la sola partizione lascia aperto nell'MVP. I template di contesti diversi usano maschere indipendenti per contesto contribuite dal telefono e poi dimenticate. Anche una coalizione di operatori ottiene valori statisticamente non correlati.

Le threshold signature per il recovery (FROST / BLS), le zero-knowledge proof sulla policy delle capsule e la firma ibrida post-quantum arrivano nella stessa fase. Ognuna rafforza una proprietà dell'MVP; nessuna è ciò che rende l'MVP privacy-preserving.

Pagamenti dentro un programma di biometric checkout di un circuito di pagamento

HamsaID opera come Biometric Service Provider all'interno di un programma di biometric checkout di un circuito di pagamento. Il primo pilota europeo di questo tipo (PayEye + Empik, Polonia, giugno 2024) stabilisce il precedente regionale per il framework.

La tokenizzazione di rete gestisce la carta. In fase di enrolment, il programma lega il contesto dell'utente a un PAN tokenizzato; HamsaID memorizza solo il riferimento al token, scoped al contesto. Il PAN non entra mai nello scope di HamsaID. Questo riduce la superficie PCI DSS ai punti di integrazione della tokenizzazione di rete.

Il framing SCA è fornito a livello di network. La biometria è il fattore di inerenza; il PAN tokenizzato legato in enrolment è il fattore di possesso. Sopra le soglie locali di esenzione per transazioni di basso valore, lo step-up a verifica 1:1 mediata dal telefono ri-ancora il possesso al momento del pagamento.

Recovery: non esiste una master key

Il recovery nell'MVP supporta migrazione device-to-device end-to-end-encrypted e un backup cifrato custodito dall'utente protetto da passkey hardware-backed o fattori di recupero robusti che HamsaID non può decrittare da sola. Senza backup, l'utente si ri-registra biometricamente e le capsule emesse in precedenza vengono revocate dal flusso di recovery.

La versione full-fledged usa threshold signature in modo che il seme non venga mai ricostruito in un solo posto durante il recovery. I custodi firmano collaborativamente un'asserzione di recovery; il nuovo dispositivo la verifica e genera materiale di seme fresco localmente, legato all'enrolment dell'utente.

Non esiste un meccanismo lato operatore che permetta a HamsaID, a un partner o a qualsiasi ruolo di backend di ricostruire il seme di un utente. Il recovery combina solo artefatti che l'utente possiede, dispositivi che controlla, o custodi che ha esplicitamente scelto.

Postura di conformità

GDPR. Il materiale biometrico derivato è trattato come dato della categoria speciale ai sensi dell'art. 9 indipendentemente dal fatto che sia trasformato, cifrato o secret-shared. L'argomento è architetturale: minimizzazione, limitazione delle finalità, limitazione della conservazione, integrità e riservatezza, privacy by design e by default, diritti effettivi dell'interessato. Ogni deployment è progettato per essere pronto alla DPIA.

PCI DSS e PSD2. Sono gestiti tramite l'integrazione network-level con il biometric checkout / la tokenizzazione di rete. I dati di PAN non entrano mai nello scope di HamsaID; il framing SCA è stabilito dal programma a livello di network.

EU AI Act. HamsaID copre autenticazione consentita e scoped e (post-scale) proof-of-humanity. L'identificazione biometrica remota in spazi pubblici è esplicitamente fuori dal prodotto. Qualsiasi modalità 1:N o 1:few è implementata come ricerca scoped per tenant; il percorso di codice non può essere invocato contro un corpus illimitato.

Cosa contiene il whitepaper completo

Modello di minaccia e capacità dell'avversario (insider, rete, dispositivo, supply-chain).

Dettaglio crittografico: generazione del seme in storage hardware-backed, albero di derivazione HKDF, emissione e rotazione delle capsule, percorsi di revoca.

Architettura del sensore: acquisizione palmare multimodale, sottosistemi ottico e di compute, firmware attestato, estrazione di feature on-device, neural network sull'edge.

Biometric Resolution Core: architettura dell'enclave nell'MVP, topologia SMPC full-fledged, modalità di ricerca (1:1, 1:few, 1:N scoped per tenant).

App Identity Broker e superficie HamsaID API.

Flussi di protocollo end-to-end: enrolment, autenticazione live con telefono presente, autenticazione hand-only pre-autorizzata, recovery.

Integrazione del biometric checkout di circuito: evidenza di accreditamento, tokenizzazione di rete, gestione dello step-up, propagazione della revoca.

Target di performance per ogni stage della pipeline e target FAR/FRR per fase.

Mappatura GDPR, implicazioni dell'EDPB Opinion 11/2024, allineamento all'EU AI Act, PCI / PSD2 via il programma di biometric checkout.