Il 23 maggio scorso l’EDPB ha pubblicato una importantissima opinion, richiesta dal Garante Francese in ordine alla compatibilità del riconoscimento facciale mediante biometria finalizzato all’efficientamento dei flussi di passeggeri in ambito aeroportuale con i principi posti dal GDPR.
La delicatezza dei correlati trattamenti e la potenziale minaccia ai diritti e alle libertà fondamentali delle persone fisiche da essi scaturenti, in ragione dell’utilizzo della biometria, sono autoevidente.
Il tema è altresì particolarmente attuale, e rimarrà tale, considerando che, di recente, il riconoscimento facciale per le finalità sopra indicate è stato adottato dall’aeroporto di Linate e, verosimilmente, sarà introdotto in moltissimi scali in tutta l’Unione.
Indice degli argomenti
Le norme di riferimento individuate dal Garante francese
In sintesi, il Garante francese ha chiesto all’EDPB di esprimere il proprio parere circa la compatibilità con gli articoli 5.1. (e/f), 25 e 32 del GDPR di quattro specifici scenari implicanti l’utilizzo del riconoscimento facciale biometrico per l’efficientamento dei flussi di utenti/passeggeri in ambito aeroportuale.
Essere DPO nel 2025: quali sono le competenze e i requisiti necessari
Prima di passare alla descrizione dei quattro scenari individuati dal Garante francese è necessario ricordare brevemente l’oggetto delle norme appena richiamate; e così:
- l’art. 5.1. (e/f) prescrive, da un lato che i dati personali siano conservati per il minor periodo di tempo compatibile con il trattamento e le sue finalità, dall’altro lato che i medesimi dati siano conservati in modo tale da garantire la loro adeguata sicurezza (in termini di protezione della loro integrità e riservatezza);
- l’art. 25 prescrive che i dati personali vengano protetti mediante misure tecniche ed organizzative concepite armonicamente con la progettazione del trattamento e mediante un approccio progettuale predefinito (privacy by design e by default);
- l’art. 32 esemplifica le misure di sicurezza ritenute coerenti con i principi di privacy by design e by default oggetto dell’art. 25.
I 4 scenari (quesiti) individuati dal Garante francese
L’EDPB ha espresso la sua opinion in relazione a quattro specifici scenari individuati e descritti dal Garante francese, e trasformati in quattro quesiti, precisando che detta opinion non può e non deve essere intesa, né come riferibile a scenari diversi da quelli espressamente considerati, né può essere intesa come riferibile all’utilizzo della biometria per finalità diverse da quella specificata (ad esempio l’uso della biometria per finalità di law enforcement rimane totalmente estraneo ai concetti espressi nella opinion): l’efficientamento dei flussi di passeggeri in ambito aeroportuale (relativi ai check in, alla gestione del bagaglio, all’imbarco, all’accesso alle lounge).
Ecco gli scenari rappresentati all’EDPB:
- Compatibilità, con gli artt. 5.1. (f), 25 e 32, del riconoscimento biometrico laddove i dati biometrici degli utenti siano conservati nei loro dispositivi personali, e dunque nel loro esclusivo controllo, ai fini della loro autenticazione;
- compatibilità, con gli artt. 5.1. (e/f), 25 e 32, del riconoscimento biometrico laddove i dati biometrici degli utenti siano conservati criptati in un data base centralizzato, gestito dall’operatore aeroportuale e collocato nell’aeroporto, con la chiave di decrittazione memorizzata esclusivamente nei loro dispositivi, ai fini della autenticazione degli utenti stessi;
- compatibilità con gli artt. 5.1. (e/f), 25 e 32, del riconoscimento biometrico laddove i dati biometrici degli utenti siano conservati criptati in un data base centralizzato, gestito dall’operatore aeroportuale e collocato nell’aeroporto, con la chiave di decrittazione a sua volta controllata dall’operatore medesimo, ai fini della loro identificazione;
- compatibilità, con gli artt. 5.1. (e/f), 25 e 32, del riconoscimento biometrico laddove i dati biometrici degli utenti siano conservati criptati nel cloud, gestito dall’operatore aeroportuale e/o dal suo service provider, con la chiave di decrittazione a sua volta controllata dall’operatore medesimo e/o dal suo service provider, ai fini della loro identificazione.
A questo punto, prima di entrare nel merito delle risposte dell’EDPB, è necessario precisare che:
- per autenticazione si intende una operazione di raffronto 1/1, dove i dati biometrici dell’utente (template) vengono confrontati con i soli dati in possesso dell’operatore riferibili a quel determinato soggetto;
- mentre per identificazione si intende una operazione di raffronto 1/N, dove i dati biometrici dell’utente (template) vengono confrontati con i dati biometrici di un numero indefinito di persone presenti nel database.
È abbastanza chiaro che, in termini generali, l’identificazione pone minacce assai più serie della autenticazione per i diritti e le libertà fondamentali degli utenti in ragione, sia del maggior numero di dati biometrici oggetto di conservazione e trattamento, sia del conseguente aumento del rischio di falsi positivi o falsi negativi (in considerazione della natura probabilistica delle operazioni svolte dagli algoritmi di riconoscimento).
Le risposte dell’EDPB: gli scenari compatibili
L’EDPB ha ritenuto compatibili con i principi del GDPR gli scenari 1 e 2, mentre ha escluso che tali possano essere gli scenari 3 e 4.
Ma entriamo nel merito.
Scenario 1
Lo scenario 1 comporta la memorizzazione in forma criptata sia dei dati biometrici, sia del template nel proprio smartphone.
Il periodo di conservazione è limitato al tempo necessario per l’autenticazione mentre la chiave di decrittazione è controllata esclusivamente dall’operatore aeroportuale.
In questo scenario l’utente ha il pieno controllo del processo poiché solo lui può rendere disponibili i dati biometrici per l’autenticazione, che avviene mediante comparazione con il template estratto in tempo reale dai pod dedicati a questo tipo di trattamento con decrittazione dei dati affidata ad una key che si cancella, come i dati stessi, ad autenticazione (quindi con un raffronto 1/1) avvenuta.
Secondo l’EDPB la coerenza del trattamento con l’art. 25, e dunque col principio di necessità, si verifica ogniqualvolta l’operatore dimostri che non esiste un metodo alternativo di autenticazione diverso dal trattamento in oggetto (come, ad esempio, il controllo umano dei documenti di identità) capace di ottenere un risultato migliore o equivalente.
Quanto al principio di proporzionalità tra i benefici del trattamento ed i rischi da esso posti, ai sensi dell’art. 32, l’EDPB ritiene che esso sia rispettato tenendo conto del controllo diretto da parte dell’utente dei dati memorizzati nel suo terminale personale e dalle misure di sicurezza (come la criptazione delle chiavi di sicurezza) adottate dall’operatore.
Scenario 2
Lo scenario 2 prevede la conservazione dei dati biometrici in un data base centralizzato residente presso l’aeroporto, mentre la chiave di decrittazione risiede nel terminale dell’utente.
In questo contesto l’utente viene autenticato (verifica 1/1) mostrando il QR code residente nel suo device al pod dedicato, che riceve dal database il template per l’autenticazione.
Tutti i dati rimangono nell’aeroporto di riferimento e non ci sono flussi tra strutture diverse.
Secondo l’EDPB, in questo contesto, i requisiti posti dagli artt. 5 e 25 sono soddisfatti tenendo conto che i dati residenti nel database sono criptati, la chiave di decrittazione è conservata nel terminale dell’utente che ne ha il controllo e la mette a disposizione volontariamente, il terminale cui è asservito il pod di verifica decritta i dati localmente e l’operatore visualizza solo un risultato yes/no.
Anche in questo caso il principio di necessità, ai sensi dell’art. 25 è soddisfatto laddove l’operatore dimostri che non esiste una procedura alternativa in grado di rendere più scorrevole il flusso di autenticazione in modo analogo o superiore.
Il principio di proporzionalità ai sensi dell’art. 32, infine, è rispettato, tenendo conto che l’utente, mediante la chiave di decrittazione residente nel suo terminale è in grado di controllare l’intero processo (considerato che, se non invia detta chiave al pod dedicato, il trattamento non può avere luogo).
Le risposte dell’EDPB: gli scenari incompatibili
Come anticipato sopra, gli scenari 3 e 4 sono stati ritenuti incompatibili col GDPR dall’EDPB; vediamo ora perché.
Scenario 3
Nello scenario 3 i dati dei passeggeri, template, dati di ID e informazioni sul volo, sono memorizzati in un server collocato in aeroporto e criptati (una criptazione differente per ogni categoria di dati con memorizzazione in differenti partizioni del server).
Il trattamento avviene presentandosi davanti al pod dedicato che invia l’immagine del passeggero al database centrale dove essa viene confrontata con i dati ivi salvati.
Si tratta dunque di una identificazione (confronto 1/N, ben più critico del confronto 1/1 tipico della autenticazione).
In questo scenario il periodo di memorizzazione è al massimo di 48 ore, poiché i passeggeri devono registrarsi non più di 48 ore prime del volo acquistato.
Secondo l’EDPB la memorizzazione centralizzata di tutti i dati personali necessari per il trattamento (template, ID, volo, chiave) comporta altissimi rischi per i diritti e le libertà fondamentali delle persone poiché l’alto valore dei dai in sé stessi e la loro completezza, da un lato rendono alta la probabilità di attacchi, mentre dall’altro lato consentono di identificare con precisione le persone mettendone a rischio l’intera sfera personale.
In aggiunta, differentemente dagli scenari 1 e 2, in questo contesto si verifica una identificazione mediante il confronto con i dati di tutte le persone presenti in aeroporto in un determinato lasso di tempo, mentre parallelamente la chiave di decrittazione non è controllata esclusivamente dagli utenti, che dunque non possono esercitare alcun tipo di potere sul trattamento.
In questa prospettiva, le misure di sicurezza descritte nello scenario appaiono inadeguate rispetto a quanto previste dagli artt. 5 e 32 del GDPR.
Ma un contrasto si manifesta anche sotto un altro profilo, non avendo i requisiti per essere compatibile col principio di necessità oggetto dell’art 32: infatti l’efficientamento dei flussi può ben essere coltivato senza l’utilizzo della biometria, e comunque con mezzi meno invasivi e sotto il controllo dell’utente, come avviene nello scenario 1 e nello scenario 2.
Nel primo caso l’utente ha sotto il suo controllo tutto il set di dati ed il trattamento in quanto i dati stessi sono memorizzati nel suo smartphone.
Nel secondo caso l’utente ha comunque il controllo del trattamento poiché la chiave di decrittazione dei suoi dati è nel suo assoluto controllo (memorizzata nel wallet).
Scenario 4
Nello scenario 4 i dati degli utenti sono memorizzati nel cloud dell’operatore aeroportuale situato nel territorio dell’Unione.
In questo contesto avviene una identificazione (raffronto 1/N), mentre, i dati criptati, ivi compresa la chiave di decrittazione, sono tutti sotto il controllo della compagnia aereo e/o del soggetto che ne gestisce il cloud.
Anche in questo caso il trattamento inizia davanti ad un pod dedicato che invia l’immagine del passeggero al database in cloud.
Differentemente dallo scenario precedente, in questo contesto i dati possono essere trasferiti da un aeroporto all’altro poiché condivisi nel cloud della compagnia che li può utilizzare per efficientare i flussi nei suoi vari slots, in astratto, anche al di fuori del territorio dell’Unione.
Secondo l’EDPB le misure di sicurezza implementate in questo scenario sono in compatibili con gli artt. 5 e 32 del GDPR.
Inoltre, non va trascurato che il periodo di conservazione dei dati è potenzialmente illimitato, coincidendo con il periodo di vita dell’account dell’utente presso la compagnia aerea; e ciò, espone inevitabilmente igli utenti ad altissimi rischi di data breach.
Lo scenario è incompatibile anche con l’art. 25, poiché in questo caso il procedimento di identificazione dell’utente avviene con un numero di profili coincidenti con l’intero database clienti della compagnia aerea.
In questo contesto, il principio di necessità è ulteriormente messo a rischio rispetto allo scenario 3, essendo possibile ottenere i medesimi risultati con trattamenti molto meno invasivi.
Conclusioni
Allo stato attuale delle cose, gli scenari 3 e 4 non sono compatibili con i principi posti dal GDPR.
Tuttavia, ciò vale con riferimento alle loro caratteristiche, così come descritte nei quesiti posti all’EDPB.
L’implementazione di misure di sicurezza ed organizzative più efficaci di quelle descritte potrebbero pertanto renderli adeguati ai principi sulla base di nuove valutazioni di impatto che ne tengano conto e ne certifichino l’efficacia e l’adeguatezza.
Preparati per la NIS2: guida essenziale per rispettare gli obblighi cyber in tempo!
