Quattro livelli, quattro confini di fiducia
Il sensore / terminale acquisisce le modalità palmari, esegue liveness e PAD on-device, trasforma il vettore di feature con una transform key vincolata al contesto e inoltra una query trasformata attestata. Non custodisce il seme, frame grezzi a riposo o transform key di altri contesti.
Il telefono, l'Identity Broker, custodisce il seme privato, gestisce il consenso, deriva pseudonimi contestuali, emette authorization capsule ed esegue i flussi di recovery. Non vede dati biometrici grezzi, il corpus di risoluzione o dati di conto dell'esercente.
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. Non vede mai biometria grezza, il template trasformato, il seme o un identificatore globale.
Authorization capsule
La capsule è ciò che rende possibile il pay-with-hand senza che il telefono sia presente. Il telefono emette una credenziale scoped, revocabile, temporanea, firmata con una chiave custodita dal telefono e derivata dal seme per quella parte ricevente e quel contesto, 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 resolution core esegue il match e il policy layer verifica la capsule e i tetti di rischio online. Sopra le soglie di step-up PSD2, il telefono è richiesto per ri-confermare nell'app. Sotto quelle soglie, la capsule è sufficiente. Il telefono può essere spento o assente.
Risoluzione partizionata e claim di privacy stratificato (MVP)
Oggi il resolution core gira in un ambiente di esecuzione hardware-attested (un'enclave di confidential computing come Intel TDX o AMD SEV-SNP) sotto operazione di HamsaID. I template di enrolment trasformati sono memorizzati cifrati a riposo in partizioni per contesto; le chiavi di cifratura e le transform key vincolate al contesto vivono dentro l'enclave.
Le partizioni sono applicate a livello di storage e nel codice. Le query cross-partizione non sono solo vietate dalla policy: nessun percorso di codice è in grado di eseguirle. Lo schema non contiene una chiave di join che colleghi l'handle di un utente nella partizione M a quello nella partizione N.
Framing onesto del claim di privacy nell'MVP: l'utente deve fidarsi che HamsaID operi il resolution core onestamente nel proprio ambiente di esecuzione attestato. L'utente non deve fidarsi di HamsaID, di un esercente o di un partner rispetto alla correlazione cross-contesto o all'esportazione non autorizzata di template. Questo è chiuso dall'architettura.
Roadmap: SMPC con re-randomization contribuita dal telefono
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 che rivela al policy layer solo il blind handle del contesto.
In fase di enrolment, il telefono contribuisce randomness per contesto nella secret-sharing, derivata dal seme e poi dimenticata. Anche una coalizione di operatori che ricostruisce template da due contesti diversi ottiene valori in spazi re-randomized statisticamente non collegati. È ciò che rende il claim di privacy full-fledged strutturalmente non-collusivo invece che basato sulla fiducia nell'operatore.
Pay-with-hand: dentro un programma di biometric checkout di un circuito di pagamento
HamsaID è un 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 un precedente regionale per il framework.
In fase di enrolment, il programma lega il contesto M dell'utente a un PAN tokenizzato tramite il servizio di tokenizzazione del circuito. HamsaID memorizza solo il riferimento al token, scoped al contesto M. Il PAN non entra mai nello scope di HamsaID. La superficie PCI DSS è ridotta ai punti di integrazione della tokenizzazione di rete.
Al terminale, dopo un match riuscito e il check della capsule, il Blind Resolution Layer emette verso il servizio di tokenizzazione un'asserzione di autenticazione di pagamento con riferimento al token, importo e prova di freschezza. Il servizio di tokenizzazione presenta il token all'acquirer; l'acquirer autorizza con l'issuer; il risultato torna sul rail standard di pagamento.
Recovery: non esiste una master key
Oggi l'MVP supporta due percorsi di recovery: migrazione device-to-device end-to-end-encrypted sotto credenziali confermate dall'utente, e un backup cifrato custodito dall'utente protetto da passkey hardware-backed o fattori di recupero robusti che HamsaID non può decrittare da sola. Se l'utente perde il dispositivo senza backup, si ri-registra biometricamente e le capsule emesse in precedenza vengono revocate dal flusso di recovery.
La versione full-fledged sostituisce la secret-sharing con threshold signature (FROST per Ed25519, schemi basati su BLS per le operazioni post-quantum-aware). Il miglioramento sostanziale: il seme non viene 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 una master key HamsaID. Non esiste un meccanismo lato operatore che consenta 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 che facciamo è architetturale: minimizzazione, scoping, separazione dei compiti, autorità custodita dall'utente, controlli dimostrabili. Il sistema è progettato per essere pronto alla DPIA dal primo giorno di ogni deployment.
PCI DSS e PSD2 SCA. Sono gestiti a livello di network dal programma di biometric checkout e dalla tokenizzazione di rete. La biometria è il fattore di inerenza; il PAN tokenizzato legato in fase di enrolment è il fattore di possesso. Sopra le soglie locali di esenzione per transazioni di basso valore (tipicamente €30 per singola transazione con limiti cumulativi), l'architettura passa allo step-up con verifica 1:1 mediata dal telefono per ri-ancorare il possesso al momento del pagamento.
EU AI Act. HamsaID copre autenticazione consentita e scoped e (post-scale) proof-of-humanity, esplicitamente non identificazione biometrica remota in spazi pubblici. Qualsiasi modalità di risoluzione 1:N o 1:few è implementata come ricerca scoped per tenant, senza percorsi di codice in grado di interrogare un corpus illimitato.
Cosa l'architettura non elimina
La crittografia riduce il rischio, compartimenta il potere e rende il misuse osservabile. Non elimina coercizione, difetti di implementazione, compromissione di supply-chain o coercizione legale. Una piena compromissione di un telefono sbloccato può compromettere lo stato derivato dal seme di quell'utente fino a revoca o recovery. Un evento di perdita del telefono senza backup può richiedere ri-registrazione. Nell'MVP l'operatore del resolution core è una parte fidata per il livello biometrico; quel gap è chiuso strutturalmente nella versione full-fledged via SMPC, non per fiducia.