TFG · GTEL · UIB

Disseny i implementació d'una arquitectura SSI per a l'automatització del control d'accessos en entorns industrials

Àngel Joan Gamundí
Tutors: Macià Mut Puigserver i Maria Magdalena Payeras Capellà
Escola Politècnica Superior, UIB
ÍNDEX
01Context i problema
02Arquitectura
03Implementació
04Resultats i validació
05Demostració en viu
06Conclusions i treballs futurs
02 · CONTEXT

La gestió CAE viu en paper i PDF

  • Certificats mèdics d'aptitud
  • Formacions obligatòries de prevenció
  • Permisos i homologacions professionals
VÀLID FINS ?
  • Documents estàtics ⊘ sense revocació
  • Verificació manual
  • El treballador no custodia els seus documents
02 · LA IDEA

El model actual contra el model proposat

  • Una persona designada al DCAE valida tota la documentació
  • Procés manual, lent i propens a errors humans
  • Sense disponibilitat fora de l'horari laboral

Identitat Sobirana (Self-Sovereign Identity): cada individu custodia les seves credencials al dispositiu i decideix què comparteix

  • El treballador presenta les credencials, ningú les custodia per ell
  • Cap dependència d'un servidor central
03 · Per què no un PDF signat?
  • Depèn d'un servidor central la clau pública viu al servidor: si cau, no hi ha verificació
  • No es pot revocar en temps real

Granularitat per atributs, no "tot o res"

Signatura monolítica JWT / PDF
Tot o res
CL-Signatures (AnonCreds)
Qualificació soldador✓ Provat
Nom completOcult
DNIOcult
Data de naixementOcult
Atribut per atribut
04 · ARQUITECTURA · CONFIANÇA

Confien sense conèixer-se

Emissor
Verificador
Titular wallet al mòbil
Blockchain BCovrin · DID + Schema + CredDef
no es coneixen

La confiança criptogràfica ve sempre del registre, no d'un canal directe entre emissor i verificador.

04 · ARQUITECTURA · COMUNICACIÓ

Dos canals xifrats, sempre pel titular

Emissor
DIDComm credencial signada
Titular peça activa
DIDComm prova criptogràfica
Verificador

La confiança ve del registre; les dades sempre passen pel dispositiu de l'operari.

04 · ARQUITECTURA

Tres emissors sobirans, cap coordinació

OT
Oficina Tècnica
Ordre de treball
clau + CredDef pròpia
ATEX
Emissor ATEX
Atmosferes explosives
clau + CredDef pròpia
S
Emissor soldador
Homologació professional
clau + CredDef pròpia
Wallet de l'operari BC Wallet · 3 credencials
Verificador
Punt de control d'accés
05 · CREDENCIALS

Tipus de credencials i accés

FORMAT

AnonCreds

Revelació selectivaMostrar un atribut, amagar la resta
Prova de coneixement zeroDemostrar una propietat sense revelar el valor
Provar que un certificat no ha caducat sense ensenyar la data
MODEL D'ACCÉS

ABAC dinàmic

La política surt de l'ordre de treballNo hi ha regles fixes a la porta
Construïda en temps d'execucióL'OT diu quins certificats calen aquell dia
La política d'accés és la credencial mateixa
06 · IMPLEMENTACIÓ · AGENTS

Un únic lloc crea tots els agents

FabricaAgents.ts
Askarclaus AnonCredscredencials IndyVdrblockchain DIDCommcomunicació
OTOrdre de treball
ATEXCertificació ATEX
SSoldador
VVerificador

Tots comparteixen la mateixa base; el setup de cada emissor s'executa un únic cop.

Formulari web d'emissió d'ordres de treball de l'Oficina Tècnica
Seqüència de les dues rondes de verificació ABAC
06 · IMPLEMENTACIÓ · ORDRE ESTRICTE

Ronda 1: s'atura al primer que falli

01
Data La data de l'OT ha de ser la d'avui
si no → DENEGAT
02
Revocació Consulta la Bitstring Status List de l'emissor OT
si revocada → DENEGAT
03
Riscos i certificacions buits? Si la tasca no requereix res més
→ CONCEDIT, sense ronda 2

Si l'OT declara riscos o certificacions, en canvi, es passa a la ronda 2.

06 · IMPLEMENTACIÓ · RONDA 2

La sol·licitud es construeix a mida de l'OT

si riscos conté atex
zona nivell_atex data_expiració ≥ avui ZKP
si certificacions conté soldador
procés norma data_expiració ≥ avui ZKP

Si l'OT requereix totes dues, es combinen en una sola prova, un únic gest al mòbil.

Mateix canal DIDCommja obert, cap QR nou per a l'operari
cred_def_id com a restricciórebutja atributs d'un emissor no autoritzat
06 · IMPLEMENTACIÓ · PRIVACITAT

El verificador no rep la credencial, rep una Verifiable Presentation

GENERANT VP
ATEX
Certificat ATEX
al wallet
VP Prova de possessió d'una credencial vàlida (signatura CL + link secret, sense revelar-la)
zonaZona-1-Gasrevelat
nivell_atexII 2G Ex ia IIC T4revelat
data_expiracio≥ avui ✓predicat ZKP

El valor de data_expiracio no surt mai: el verificador només rep la prova que la condició es compleix.

06 · IMPLEMENTACIÓ · REVOCACIÓ
Sistema natiu d'AnonCredsRevRegs + tails files
El titular ha de descarregar un fitxer al mòbil
Depèn de connexió i alenteix el flux

La meva solució: Bitstring signada, servida per HTTP

OTEmissor OT
00100010
0 vàlida1 revocada
16.384 bits · GZIP · una per OT
status-list.json signat Ed25519
GET · públic
VVerificador
  1. Verifica la signatura amb la clau pública
  2. Llegeix el bit de l'índex de l'OT
  3. Bit 1 → DENEGAT
06 · IMPLEMENTACIÓ · PANELL

La cara visible: un QR d'accés, veredicte en temps real

CONTROL D'ACCÉS
✓ CONCEDIT ✕ DENEGAT
QR d'invitació a la pantallaL'operari l'escaneja i s'obre la connexió DIDComm segura
Veredicte a la pantallaVerd si es concedeix, vermell si es denega
Un QR per intentEs regenera després de cada verificació o timeout: cada operari estrena invitació neta
07 · RESULTATS

Validació casos i rendiment

CasResultat
OT vàlida sense riscosCONCEDIT
OT + ATEX + SoldadorCONCEDIT
OT d'un altre diaDENEGAT
Credencial revocadaDENEGAT
4060s
flux complet, cas més exigent
BCovrin Testnet
Túnel Cloudflare
Codi + criptografia

El coll d'ampolla és l'entorn, no l'arquitectura. Amb una xarxa Indy pròpia es reduiria dràsticament.

08 · DEMO

Demo en viu

09 · CONCLUSIONS

Un cicle complet, tres propietats garantides

Emissió Recepció al wallet Verificació Revocació
IDENTITAT SOBIRANA Les credencials viuen al mòbil; el verificador rep proves, no atributs en clar
AUTENTICITAT I INTEGRITAT Signatura AnonCreds validada contra la CredDef; qualsevol alteració invalida la prova
REVOCACIÓ EN TEMPS REAL El verificador comprova l'estat sense dependre de l'emissor. Validat en concessió i denegació
09 · CONCLUSIONS · LIMITACIONS

Decisions de prototip, no de l'arquitectura

01
Persistència de la status listExclosa del control de versions: un entorn nou arrenca amb la llista buida
02
Dependència de BCovrin TestnetXarxa pública sense garanties: punt de fallada únic de la demo
03
Sense multi-tenancyCada emissor és un procés independent amb el seu wallet i port
04
Directori d'operaris en JSONNo transaccional: emissions simultànies podrien causar condicions de cursa

Cap és una limitació de la SSI. Totes són simplificacions conscients amb un camí de solució clar.

09 · CONCLUSIONS · FUTUR

Dues vies: madurar el sistema i extrapolar l'arquitectura

Cap a producció
  • Xarxa Hyperledger Indy pròpia, gestionada per un consorci
  • Protegir la clau de signatura fora del disc
  • Status list en infraestructura dedicada i replicada
  • Directori d'operaris sobre base de dades transaccional
Cap a entorns digitals
  • Control d'accés a serveis regulats per edat
  • Majoria d'edat via ZKP, sense revelar la data
  • Sancions lligades a la identitat, no al compte
  • Anonimat davant el servei, complint el RGPD
FI

Una demostració rigorosa de viabilitat, no un producte de producció

Substituir una carpeta de papers que algú revisa a mà per una credencial digital que el treballador controla i que la porta verifica sola.

github.com/angeljoan1/TFG-SSI

Gràcies. Quedo a la vostra disposició.

Q&A · BACKUP A

AnonCreds vs JWT / SAML

CriteriJWT / SAMLAnonCreds
Revelació selectivaNO
Proves ZKP (predicats)NO
Clau públicaSERVIDORLEDGER
Revocació interoperableFEBLESTATUS LIST
Correlació entre verificadorsALTABAIXA
Q&A · BACKUP B

Bitstring Status List vs RevRegs natius

CriteriRevRegs natiusBitstring Status List
Compatibilitat Credo-TS v0.5TRENCADAOK
Descàrrega de fitxer pel titularTAILS FILECAP
Dependència de connectivitatALTABAIXA
Publicació a blockchain per revocarNO
Interoperabilitat W3CPARCIAL
ComplexitatALTABAIXA
Q&A · BACKUP C

La clau Ed25519: del disc a HSM / KMS

ARA
Clau privada en JSON al discQui accedeix al filesystem pot signar status lists falses
01
Variable d'entorn / secret manager
02
HSM o KMSLa clau mai surt del mòdul

L'arquitectura no canvia: només l'origen de la signatura de la Status List.

Q&A · BACKUP D

Peer-to-peer? Transport vs xifratge

XARXA
Túnel Cloudflare + HTTP
Mòbil Cloudflare Agent
Hi ha un intermediari de transport. NO és peer-to-peer.
HTTP
Petició POST a l'adreça pública de l'agent
El túnel només fa arribar els paquets al port local.
DIDComm
Xifratge d'extrem a extrem
Mòbil 🔒 xifrat 🔒 Agent
Cloudflare no pot llegir res. La seguretat és extrem a extrem.

El terme peer-to-peer descrivia la propietat de seguretat (ningú al mig llegeix), no la topologia de xarxa. El correcte: canal xifrat d'extrem a extrem sobre transport HTTP.

SSI · CONTROL D'ACCESSOS