Intro

Les citoyens possèdent généralement de nombreux certificats : carte d’identité, permis de conduire, diplômes, certificats d’aptitudes pédagogiques, cartes bancaires, carte d’assurance maladie, prescriptions médicales, extrait de casier judiciaire, carte de stationnement pour personnes handicapées, titres de propriété, billets de concert… Ces documents peuvent être physiques ou numériques et contiennent des données personnelles souvent sensibles.

Lorsque vous présentez un tel certificat, vous divulguez souvent plus d’informations à propos de vous que celles strictement nécessaires. Or, cela peut poser problème, notamment dans un monde numérique. Les données sont lues en une fraction de seconde et peuvent ensuite être conservées pendant de nombreuses années, ce qui permet de dresser votre profil de manière plus complète.

Voici deux exemples :

• Pour acheter de l’alcool ou des feux d’artifice, ou pour accéder à des sites web à contenu érotique, il suffit en principe de prouver que l’on est majeur. Pour participer à des jeux de hasard ou à des paris, l’âge minimal est de 21 ans. La date de naissance exacte, sans parler du lieu de naissance ou du numéro de registre national, n’ont pas d’importance. Ce n’est qu’en cas d’abus, tel que la tricherie, que l’identité de la personne concernée doit pouvoir être révélée.
• Pour participer à un sondage organisé par la ville de Louvain, il suffit en principe de prouver que l’on réside effectivement dans cette ville et que l’on n’a pas encore participé, éventuellement en communiquant des informations supplémentaires telles que la tranche d’âge et la commune, à des fins statistiques.

Les technologies de certification couramment utilisées aujourd’hui ne permettent pas une divulgation sélective des données personnelles ; soit vous montrez le certificat complet avec toutes les données personnelles qu’il contient, soit vous ne montrez rien. Au cours des dernières décennies toutefois, de nombreux travaux de recherche et de développement ont été menés pour mettre au point une technologie capable de remédier à cela facilement. Cette technologie, appelée “titres numériques anonymes”, a déjà été abordée dans un précédent article de blog.

Il s’agit d’une technologie favorisant la confidentialité qui recourt aux preuves à divulgation nulle de connaissance (zero-knowledge (ZK) proof) pour divulguer de manière sélective des informations personnelles. Les preuves ZK permettent à une partie de prouver une affirmation (par exemple, être âgé de plus de 18 ans) à une autre partie sans divulguer plus de détails sur cette affirmation (par exemple, la date de naissance exacte). Bien que le titre numérique lui-même soit délivré par un émetteur autorisé, la divulgation sélective ne nécessite plus le recours à un tiers de confiance.

David Chaum a réalisé en 1985 les premiers travaux novateurs et révolutionnaires en proposant une monnaie numérique anonyme. Chaum mettait déjà en garde à l’époque contre l’impact des évolutions technologiques sur la vie privée des citoyens. Sur cette base, les deux premières propositions de titres numériques anonymes ont suivi rapidement. En 2000, Stefan Brands a publié sa solution U-Prove, et en 2001, Jan Camenisch (IBM) et Anna Lysyanskaya (MIT) ont proposé Idemix, une solution plus avancée.

Au cours de ces années, j’ai manié cette technologie dans le cadre de mon doctorat, ce qui m’a valu, entre autres, un best paper award à SECRYPT 2009 à Milan, avec une solution permettant aux détenteurs de titres numériques d’utiliser un service de manière anonyme, mais pas plus d’un nombre déterminé de fois par période, par exemple pas plus de 10 fois par mois.

Caractéristiques

Tout comme pour les certificats numériques classiques, un titre numérique anonyme est délivré par un émetteur autorisé (issuer ou identity provider) au détenteur (holder).
Au moyen de preuves ZK, ce dernier peut ensuite prouver de manière sélective des informations issues du titre numérique à un vérificateur (verifier).

Les caractéristiques de base des titres numériques anonymes sont les suivantes :

• Infalsifiabilité (Unforgeability). Il est impossible de falsifier un titre numérique anonyme. Seul l’émetteur peut créer des titres numériques anonymes.
• Divulgation sélective d’attributs (selective attribute disclosure). Seule une partie sélectionnée des informations contenues dans le titre numérique anonyme est divulguée. Il peut s’agir de valeurs d’attributs, telles que la date de naissance, mais aussi d’informations dérivées, telles que la majorité. Toutes les autres informations contenues dans le titre numérique restent cachées au vérificateur. Idemix et U-Prove prennent tous deux en charge cette fonctionnalité.
• Non-corrélabilité (Unlinkability). Des présentations multiples d’un même titre numérique anonyme à un vérificateur (identique ou différent) ne peuvent pas être reliées entre elles. U-Prove ne disposait pas encore de cette fonctionnalité, contrairement à Idemix.

En fonction de la technologie spécifique, des fonctionnalités supplémentaires peuvent être prises en charge, notamment :

• Durée de validité limitée. Le détenteur prouve au vérificateur que la date d’expiration du titre numérique anonyme n’est pas encore atteinte, sans divulguer d’autres informations sur cette date d’expiration.
• Révocation. Un titre numérique anonyme peut être révoqué, par exemple après que la clé privée correspondante a été compromise ou parce que les données personnelles ont été modifiées, par exemple en cas de déménagement ou de retrait du permis de conduire. Chaque fois qu’un détenteur présente un titre numérique à un vérificateur, il prouve également que l’identifiant du titre numérique figure sur une liste blanche ou qu’il ne figure pas sur une liste noire. Ces listes peuvent être compressées en une seule valeur compacte, laquelle est actualisée à chaque nouvelle révocation. C’est ce que l’on appelle un accumulateur dynamique.
• Anonymat conditionnel. En cas d’abus, l’anonymat du détenteur du titre numérique peut être levé, avec la coopération d’un tiers de confiance, et son identité est alors révélée. La justice peut ainsi faire son travail et éventuellement engager des poursuites.
• Délégation. Un détenteur de titres numériques peut déléguer des titres numériques anonymes. Une personne pourrait ainsi déléguer son droit (ou son obligation) de vote à son partenaire, ce qui équivaut alors à une procuration. Pour des raisons juridiques, la délégation ne sera généralement possible que pour des individus ayant une capacité juridique et donc pas pour des mineurs, par exemple.
• Combinabilité. Une divulgation sélective peut être dérivée de plusieurs titres numériques anonymes, potentiellement émis par différents émetteurs. Par exemple, un détenteur de titres numériques peut prouver avec une seule preuve ZK qu’il est titulaire d’un permis de conduire valide et qu’il est assuré, sans pour autant divulguer d’identifiant commun, tel que son numéro de registre national. Il prouve simplement que les deux titres numériques anonymes contiennent le même identifiant, comme illustré dans un précédent article.

Il est évident que les titres numériques anonymes constituent une technologie particulièrement puissante et recèlent un potentiel considérable. Malheureusement, cela ne signifie pas nécessairement qu’ils sont adoptés à grande échelle. Les sections suivantes traitent 1) des initiatives destinées à parfaire cette technologie et à la faire adopter, 2) de son utilisation dans la pratique et 3) des défis liés à la résistance à l’informatique quantique.

Initiatives

Lorsque j’ai commencé à travailler avec Idemix il y a environ vingt ans, la signature d’un accord de confidentialité était indispensable. Depuis, la situation s’est complètement inversée et il existe désormais divers projets open source. Les principaux sont IBM Idemix, Microsoft U-prove, Yivi et Hyperledger AnonCreds. Ces deux derniers proposent actuellement leurs propres implémentations d’Idemix.

La Commission européenne a déjà investi des dizaines de millions d’euros dans la recherche et le développement de technologies de titres numériques anonymes à travers des projets tels que PRIME (2004-2008), PrimeLife (2008-2011) et ABC4Trust (2011-2014).

Le battage médiatique autour de la blockchain (entre 2015 et 2019 environ) s’est accompagné d’un regain d’intérêt pour les titres numériques anonymes, en tant que concrétisation technologique du paradigme de l’identitié auto-souveraine (Self-sovereign identity – SSI). La blockchain et les titres numériques anonymes promettaient en effet quelque chose de très similaire : redonner le contrôle aux citoyens, en le retirant des mains des autorités et des intermédiaires. Beaucoup ont alors supposé à tort que la SSI nécessitait la blockchain. Ce n’est pas nécessairement le cas, mais la blockchain peut néanmoins jouer un rôle, notamment pour répertorier de manière distribuée les émetteurs reconnus et donc dignes de confiance.

Hyperledger est un projet open source sous l’égide de la Linux Foundation destiné à développer une technologie pour les réseaux blockchain autorisés (fermés et contrôlés). Hyperledger a adopté le paradigme SSI ; Hyperledger AnonCreds, actuellement un projet en incubation, met spécifiquement en œuvre une technologie de titres numériques anonymes.

Sovrin était le pionnier le plus influent dans le domaine de la SSI utilisant la blockchain et recourrait notamment à Hyperledger AnonCreds comme base. Malheureusement, le réseau Sovrin est passé à la trappe au début de cette année. Les raisons invoquées étaient une baisse de l’utilisation, une incertitude législative, des défis techniques et un engagement limité de la part de la communauté.

Le portefeuille d’identité numérique de l’UE (EU digital identity wallet ou EUDIW en anglais), défini dans la réglementation eiDAS 2.0 (en vigueur depuis mai 2024), offre en principe une nouvelle occasion d’exploiter le potentiel des titres numériques anonymes (avec ou sans blockchain). Malheureusement, il semble que l’on ne s’oriente pas dans cette direction. En juin 2024, un groupe de cryptographes éminents a formulé  des critiques à l’égard de la conception actuelle de l’EUDIW et estime qu’une nouvelle conception, avec un soutien explicite aux titres numériques anonymes, s’impose pour améliorer la confidentialité. La conception actuelle de l’EUDIW n’autorise par exemple pas la non-corrélabilité. L’intégration de titres numériques anonymes est l’un des “sujets en suspens”, mais aucun plan d’action n’a encore été établi à ce jour.

Depuis 2012, un projet appelé IRMA, qui signifie “I Reveal My Attributes” est en cours aux Pays-Bas. Il a été développé à l’université Radboud de Nimègue. En 2023, il a été rebaptisé Yivi. Yivi entend redonner aux citoyens le contrôle de leurs données, sans recourir à la technologie blockchain. 

Dans la pratique

Yivi dispose notamment de sa propre implémentation du protocole Idemix ainsi que de sa propre app, qui serait utilisée par des centaines de milliers de Néerlandais. Elle est proposée par la ville de Nimègue comme solution d’identité respectueuse de la vie privée. La ville l’utilise notamment pour mener des enquêtes anonymes auprès de ses habitants.

Parallèlement, les compagnies d’assurances soutiennent Yivi, étant donné que les autres solutions d’identité numérique aux Pays-Bas ne sont pas utilisables dans ce contexte ; DigiD n’est possible qu’auprès des institutions gouvernementales, iDIN passe par une banque et n’est utilisable que par les personnes titulaires d’un compte bancaire aux Pays-Bas. Les considérations pratiques semblent ici primer sur l’aspect de la vie privée.

L’administration de la province canadienne de Colombie-Britannique a investi massivement dans le développement et l’adoption de titres numériques anonymes. Elle a consacré plus d’un million de lignes de code au projet Hyperledger Aries. La Colombie-Britannique utilise également cette technologie dans la pratique, notamment avec Hyperledger AnonCreds :

• 

  OrgBook BC met à disposition de nombreuses informations sur les entreprises de la province : numéros d’entreprise, adresses, certificats d’enregistrement, licences de vente de cannabis… Afin d’accroître la confiance dans leur exactitude, ces données sont mises à disposition sous la forme de titres numériques anonymes révocables, délivrés par des organismes du secteur public. Les citoyens peuvent obtenir, stocker et présenter des titres numériques vérifiables les concernant ou concernant leur entreprise grâce à leur BC Wallet.
• Le Justice Project permet aux juges et aux avocats de consulter en ligne des documents judiciaires sensibles, auxquels seuls les juristes agréés ont accès, sans révéler leur identité.

Les applications ci-dessus se situent au niveau local. Cependant, il ne faut pas oublier que les titres numériques anonymes sont également utilisés à l’échelle mondiale.

Signal, l’application de messagerie sécurisée populaire qui compte quelque 70 millions d’utilisateurs, utilise des titres numériques anonymes pour gérer des groupes privés ; les serveurs de Signal ne voient pas quels sont les membres d’un groupe privé. Lorsqu’un membre du groupe ajoute ou supprime quelqu’un du groupe, les serveurs de Signal ne voient pas qui exécute cette action, mais seulement que cette personne en a le droit. Signal utilise pour cela des Keyed-Verification Anonymous Credentials (KVAC), i.e. des titres numériques anonymes, où l’émetteur et le vérificateur partagent une clé secrète, ce qui permet de gagner en efficacité.

Un TPM (Trusted Platform Module) est une puce de sécurité intégrée à un ordinateur. Il est notamment capable de prouver l’intégrité du système à une entité externe dans le respect de la vie privée. Pour ce faire, il utilise la technologie Direct Anonymous Attestation (DAA). Celle-ci utilise une sorte de titre numérique anonyme, lié à la puce TPM. La technologie SGX d’Intel utilise une variante de la DAA, appelée Enhanced Privacy ID (EPID). À ce jour, plus de 2,5 milliards de titres numériques EPID ont été émis. Il s’agit probablement aujourd’hui de l’application la plus réussie de la technologie des titres numériques anonymes.

Malgré ces quelques cas d’usage à l’échelle mondiale, nous ne constatons à ce jour qu’une adoption très limitée des titres numériques anonymes dans le contexte où nous les attendons le plus, à savoir la gestion des identités.

Résistance à l’informatique quantique

Comme déjà expliqué en détail dans des articles précédents de Smals Research, il existe un risque que de puissants ordinateurs quantiques puissent à l’avenir briser la cryptographie moderne à clé publique.

L’illustration ci-dessous présente les principales techniques en matière de titres numériques anonymes proposées par le monde académique. La première génération était basée sur RSA ou les courbes elliptiques. À partir de 2004, une génération basée sur les applications bilinéaires (pairings) a suivi. La troisième génération de titres numériques anonymes est basée sur les treillis et est la première génération à utiliser une cryptographie supposée résistante à l’informatique quantique.

Illustration 1 Chronologie des principales publications relatives aux titres numériques anonymes (source)

À l’heure actuelle, seuls quelques systèmes résistants à l’informatique quantique ont donc été proposés pour les titres numériques anonymes. Ces systèmes sont encore récents et leurs performances sont insuffisantes pour être utilisés dans la pratique. De plus amples recherches s’imposent donc pour trouver des solutions efficaces et résistantes à l’informatique quantique pour les titres numériques anonymes.

Nous avons mentionné plus haut qu’un groupe éminent de scientifiques spécialisés en cryptographie plaidait en faveur de la prise en charge des titres numériques anonymes dans le portefeuille d’identité numérique de l’UE (EUDIW).  Ils avancent deux arguments valables pour expliquer pourquoi la menace quantique n’est pas (encore) d’actualité.

• Les titres numériques anonymes sont utilisés pour l’authentification ; une session d’authentification n’est valable que pendant un très court laps de temps, quelques minutes tout au plus. Pensez par exemple à l’authentification avec itsme, à des années-lumière du chiffrement (par exemple, la communication), où un pirate dispose de plusieurs années pour déchiffrer les données chiffrées interceptées (harvest now decrypt later). On a ainsi beaucoup plus de temps (au moins une décennie, selon votre auteur).
• Les technologies de titres numériques anonymes les plus populaires aujourd’hui, comme celles proposées par Camenisch et Lysyanskaya en 2004, offrent une sécurité inconditionnelle ; même un pirate hypothétique disposant d’une puissance de calcul infinie (classique ou quantique) ne pourrait la briser, bien que la technologie – cela peut sembler contradictoire – utilise en coulisse des éléments constitutifs qui pourraient être brisés par de puissants ordinateurs quantiques.

Sur le plan technologique, rien n’empêche donc l’adoption de la technologie des titres numériques anonymes. Il existe toutefois un autre obstacle… la perception ! Emad Heydari Beni, chercheur en cryptographie au COSIC (KU Leuven) et chez Bell Labs, a récemment publié le message suivant sur LinkedIn : “Si ce n’est pas post-quantique, les acteurs de l’industrie ne veulent pas en entendre parler.”  La double argumentation évoquée plus haut n’est donc probablement pas suffisamment convaincante pour l’industrie.

Dans tous les cas, veillez à ce que votre solution soit crypto-agile si vous utilisez des titres numériques anonymes, afin de pouvoir migrer rapidement vers une technologie plus récente si nécessaire.

Conclusion

En résumé, après des décennies de recherche et de développement, et malgré leur nombreux avantages, les titres numériques anonymes ne sont encore que peu utilisés dans la pratique pour réellement protéger les données à caractère personnel. Leur potentiel est loin d’être pleinement exploité, même si des projets tels que Hyperledger leur donnent une impulsion positive. Grâce notamment à Signal et Intel SGX, certains types de titres numériques anonymes sont toutefois largement adoptés.

L’absence de normes constitue un obstacle à leur adoption dans le contexte de la gestion des identités. Grâce au travail préparatoire réalisé notamment par le W3C, la Decentralized Identity Foundation, l’IETF/IRTF et l’ISO, cela devrait être possible assez rapidement, à condition qu’il y ait une volonté politique, selon le groupe de cryptographes mentionné précédemment. La technologie doit toutefois relever un autre défi, à savoir devenir résistante à l’informatique quantique.

Il est donc encore trop tôt pour dire si cette technologie va s’imposer comme un outil de gestion des identités respectueux de la vie privée. Peut-être est-ce au secteur public de prendre l’initiative et de faire des titres numériques anonymes un succès.

N’hésitez pas à nous contacter si vous êtes intéressé !

Intro

Burgers hebben doorgaans heel wat certificaten. Voorbeelden zijn de identiteitskaart, rijbewijs, diploma’s, bekwaamheidsbewijzen, bankkaarten, de ziekteverzekeringskaart, medische voorschriften, een uittreksel uit het strafregister, een parkeerkaart voor personen met een handicap, eigendomsaktes en concerttickets. Deze kunnen een fysieke of digitale vorm aannemen en bevatten – vaak gevoelige – persoonsgegevens.

Wanneer we een dergelijk certificaat tonen, geven we vaak meer gegevens over onszelf prijs dan strikt noodzakelijk. Vooral in een digitale wereld kan dit problematisch worden. De data worden in een fractie van een seconde uitgelezen en vervolgens misschien vele jaren bewaard, waarbij mogelijk een ruimer profiel over jou aangelegd wordt.

Een tweetal voorbeelden:

• Om alcohol of vuurwerk te kopen, of om toegang te krijgen tot websites met erotische inhoud, moet je in principe enkel aantonen dat je meerderjarig bent. Om deel te nemen aan kansspelen of weddenschappen is de minimumleeftijd 21 jaar. De exacte geboortedatum, laat staan de geboorteplaats of rijksregisternummer, doen er niet toe. Enkel in geval van misbruik, zoals valsspelen, moet de identiteit van de persoon in kwestie onthuld kunnen worden.
• Om deel te nemen aan een bevraging georganiseerd door de stad Leuven, moet je in principe enkel aantonen dat je effectief in die stad woont, en nog niet eerder gestemd hebt, eventueel aangevuld met extra info zoals leeftijdscategorie en deelgemeente, voor statistische doeleinden.

De vandaag gangbare certificaattechnologieën laten een dergelijke selectieve prijsgave van persoonsgegevens niet toe; je toont ofwel het volledige certificaat met al de persoonsgegevens die erin vervat zitten, ofwel niets. Toch is er in de laatste decennia al heel wat onderzoek en ontwikkeling gebeurd naar een technologie die daar wel vlot mee overweg kan. Die technologie luistert naar de naam anonieme credentials en kwam reeds in een vorige blogpost aan bod.

Het is een privacy bevorderende technologie die beroep doet op zero-knowledge proofs (ZKPs) om selectief persoonsinformatie prijs te geven. ZKPs laten een partij toe een bewering (vb. ouder dan 18 jaar) aan een andere partij te bewijzen zonder verdere details over die bewering (vb. exacte geboortedatum) prijs te geven. Hoewel de credential zelf wordt uitgegeven door een geautoriseerde uitgever, hoeft bij een selectieve prijsgave verder geen beroep meer gedaan te worden op een vertrouwde partij.

David Chaum deed reed in 1985 het eerste baanbrekend en visionair werk met een voorstel voor anoniem digitaal geld. Chaum waarschuwde toen reeds voor het effect van de technologische ontwikkelingen op de privacy van burgers. Daarop verder bouwend volgden kort op elkaar de twee eerste voorstellen voor anonieme credentials. In 2000 publiceerde Stefan Brands zijn oplossing U-Prove, en in 2001 werd het geavanceerdere Idemix voorgesteld door Jan Camenisch (IBM) en Anna Lysyanskaya (MIT).

In die jaren werkte ik tijdens mijn doctoraat met die technologie, wat me onder meer een best paper award opleverde op SECRYPT 2009 in Milaan, met een oplossing die credential houders toelaat anoniem van een dienst gebruik te maken, maar niet vaker dan een vast aantal keer per tijdsvenster, bijvoorbeeld niet vaker dan 10 keer per maand.

Eigenschappen

Net zoals bij klassieke digitale certificaten, wordt een anoniem credential uitgegeven door een geautoriseerde uitgever (de issuer of identity provider) aan de eigenaar (de holder). De laatste kan vervolgens, m.b.v. ZKPs selectief informatie uit de credential bewijzen aan een verifier.

De basiseigenschappen van anonieme credentials zijn:

• Onvervalsbaarheid (Unforgeability). Het vervalsen van een anonieme credential is onmogelijk. Enkel met behulp van de issuer kunnen anonieme credentials aangemaakt worden.
• Selectieve attribuutprijsgave (selective attribute disclosure). Slechts een geselecteerd deel van de informatie die in het anonieme credential vervat zit, wordt prijsgegeven. Dit kunnen attribuutwaarden zijn, zoals geboortedatum, maar ook afgeleide informatie, zoals meerderjarigheid. Alle andere informatie in de credential blijft verborgen voor de verifier. Zowel Idemix als U-Prove ondersteunen dit.
• Onlinkbaarheid (Unlinkability). Meerdere vertoningen van eenzelfde anonieme credential aan (eenzelfde of andere) verifier kunnen niet aan elkaar gekoppeld worden. U-Prove had deze eigenschap nog niet, Idemix wel.

Afhankelijk van de specifieke technologie kunnen bijkomende eigenschappen ondersteund worden, waaronder:

• Beperkte geldigheidsduur. De holder bewijst aan de verifier dat de vervaldatum van de anonieme credential nog niet bereikt is, zonder verdere info over die vervaldatum prijs te geven.
• Revocatie. Een anoniem credential kan gerevoceerd worden, bijvoorbeeld nadat de bijhorende private sleutel gecompromitteerd werd of omdat de persoonsgegevens gewijzigd zijn, bijvoorbeeld door een verhuis of intrekken rijbewijs. Telkens wanneer een holder een credential toont aan een verifier, bewijst hij ook dat de identifier van de credential zich op een whitelist bevindt of dat deze identifier zich niet op een blacklist bevindt. Die lijsten kunnen gecomprimeerd worden tot één compacte waarde, die geactualiseerd wordt bij elke nieuwe revocatie. Dit noemt met een dynamische accumulator.
• Conditionele anonimiteit. In geval van misbruik kan de anonimiteit van de credential holder, met medewerking van een vertrouwde partij, opgeheven worden en wordt de identiteit dus onthuld. Op die manier kan het gerecht zijn werk doen en eventueel tot vervolging overgaan.
• Delegatie. Een credential holder kan anonieme credentials delegeren naar andere personen. Een persoon zou zo bijvoorbeeld haar recht (of plicht) om te stemmen kunnen delegeren naar haar partner. Dit is dan het equivalent van een volmacht. Delegatie zal omwille van juridische redenen veelal enkel door handelingsbekwame personen uitgevoerd kunnen worden, en dus niet door vb. minderjarigen.
• Combineerbaarheid. Een selectieve prijsgave kan afgeleid worden uit meerdere anonieme credentials, potentieel uitgegeven door verschillende issuers. Een credential holder kan bijvoorbeeld met één enkel ZKP bewijzen dat hij over een geldig rijbewijs beschikt en verzekerd is, zonder daarbij een gemeenschappelijke identifier, zoals rijksregisternummer, prijs te gegeven. Hij bewijst enkel dat beide anonieme credentials dezelfde identifier bevatten, zoals ook geïllustreerd in een eerder artikel.

Het is duidelijk dat anonieme credentials een bijzonder krachtige technologie zijn en heel wat potentieel hebben. Dit betekent helaas niet per se dat er ook brede adoptie is. De volgende secties bespreken 1) de initiatieven om de technologie verder te ontwikkelen en ingang te doen vinden, 2) het gebruik ervan in de praktijk en 3) de uitdagingen m.b.t. kwantumresistentie.

Initiatieven

Toen ik ongeveer twintig jaar geleden met Idemix aan de slag ging, kon dit enkel mits het ondertekenen van een geheimhoudingsverklaring. Ondertussen is de situatie helemaal omgekeerd en zijn er diverse open source projecten. De voornaamste zijn IBM Idemix, Microsoft U-prove, Yivi en Hyperledger AnonCreds. Die twee laatsten bieden momenteel eigen implementaties van Idemix aan.

Vanuit de Europese Commissie werden via projecten zoals PRIME (2004-2008), PrimeLife (2008-2011) en ABC4Trust (2011-2014) reeds tientallen miljoenen euro’s geïnvesteerd in onderzoek en ontwikkeling naar anonieme credential technologie.

De blockchain hype (ruwweg 2015-2019) ging gepaard met een hernieuwde interesse in anonieme credentials, als technologische invulling van het Self-sovereign identity (SSI) paradigma. Blockchain en anonieme credentials beloofden immers iets zeer gelijkaardig; de controle teruggeven aan de burger, uit de handen van de allerlei autoriteiten en men-in-the-middle. Velen gingen er toen onterecht vanuit dat SSI blockchain vereist. Dat is niet noodzakelijk, maar toch kan blockchain een rol spelen, onder meer om op een gedistribueerde wijze bij te houden welke issuers erkend zijn, en dus vertrouwd kunnen worden.

Hyperledger is een open-source project onder de vleugels van de Linux Foundation dat bouwt aan technologie voor permissioned (gesloten, gecontroleerde) blockchain netwerken. Hyperledger omarmde het SSI-paradigma; Hyperledger AnonCreds, momenteel een incubatieproject, implementeert specifiek anonieme credential technologie.

Sovrin was de meest toonaangevende pionier in SSI m.b.v. blockchain en gebruikte onderliggend onder meer Hyperledger AnonCreds. Helaas werd het Sovrin netwerk begin dit jaar uitgedoofd. De redenen die gegeven werden waren een dalend gebruik, wetgevende onzekerheid, technische uitdagingen en beperkte betrokkenheid vanuit de community.

De EU digital identity wallet (EUDIW), gedefinieerd in de eiDAS 2.0 regulering (van kracht sinds mei 2024), biedt in principe opnieuw een kans om het potentieel van anonieme credentials te ontsluiten (met of zonder blockchain). Toch lijkt men helaas niet in die richting te kijken.  Een groep van vooraanstaande cryptografen formuleerde in juni 2024 kritieken op het huidige ontwerp van de EUDIW en menen dat een nieuw design, met expliciete ondersteuning voor anonieme credentials, nodig is om de privacy te verbeteren. Het huidige EUDIW-ontwerp laat bijvoorbeeld geen onlinkbaarheid toe. Integratie van anonieme credentials is één van de “open topics”, maar een roadmap ontbreekt vooralsnog.

Sinds 2012 loopt er in Nederland een project genaamd IRMA, wat staat voor I Reveal My Attributes. Het werd ontwikkeld aan de Radboud Universiteit in Nijmegen. In 2023 werd het omgedoopt naar Yivi. Yivi wil de controle over haar gegevens teruggeven aan de burger, zonder daarbij een beroep te doen op blockchain technologie.

In de praktijk

Yivi heeft onder meer zijn eigen implementatie van het Idemix protocol alsook een eigen app, die door honderdduizenden Nederlanders gebruikt zou worden. Het wordt aangeboden door de stad Nijmegen als privacy-vriendelijke identiteitsoplossing. De stad gebruikt het onder meer voor anonieme bevragingen van Nijmegenaren.

Daarnaast ondersteunen verzekeringsinstellingen Yivi, gezien de andere digitale  identiteitsoplossingen in Nederland in dit kader niet bruikbaar zijn; DigiD is alleen mogelijk bij overheidsinstellingen, iDIN verloopt via een bank en is enkel bruikbaar door mensen met een bankrekening in Nederland. Hier lijkt de praktische overweging belangrijker dan het privacy-aspect.

Het bestuur van de Canadese provincie British Columbia heeft stevig geïnvesteerd in de ontwikkeling en adoptie van anonieme credentials. Ze heeft meer dan een miljoen regels code gecommit naar het Hyperledger Aries project. British Columbia gebruikt de technologie, samen met onder meer Hyperledger AnonCreds ook in de praktijk:

• 

  OrgBook BC stelt heel wat informatie over bedrijven in de provincie ter beschikking: ondernemingsnummers, adressen, registratiebewijzen, licenties om cannabis te verkopen, etc. Om het vertrouwen in de juistheid ervan te verhogen, worden deze data ter beschikking gesteld onder de vorm van revoceerbare anonieme credentials, uitgegeven door publieke sectororganisaties. Burgers kunnen met hun BC Wallet verifiable credentials over henzelf of over hun onderneming verkrijgen, opslaan en tonen.
• Het Justice Project laat rechters en advocaten toe gevoelige gerechtelijke documenten, waar enkel erkende juristen toegang tot mogen hebben, online op te vragen zonder hun identiteit prijs te geven.

Bovenstaande toepassingen situeren zich op een lokaal niveau. Toch mogen we niet vergeten dat anonieme credentials ook op globale schaal toegepast worden.

Signal, de populaire beveiligde berichten app die ongeveer 70 miljoen gebruikers telt, maakt gebruik van anonieme credentials voor het beheer van private groepen. De Signal servers zien niet wie tot een private groep behoort. Wanneer een groepslid iemand aan de groep toevoegt of eruit verwijdert, zien de Signal servers niet wie dit doet, enkel dat die persoon het recht daartoe heeft. Signal gebruikt daarvoor Keyed-Verification Anonymous Credentials (KVACs), wat anonieme credentials zijn, waarbij de issuer en de verifier een geheime sleutel delen, wat leidt tot efficiëntiewinsten.

Een TPM (Trusted Platform Module) is een security chip in een computer. Het is, onder andere, in staat om op een privacyvriendelijke manier de integriteit van het system aan een externe entiteit te bewijzen. Daarvoor maakt het gebruik van Direct Anonymous Attestation (DAA). DAA gebruikt een soort anonieme credential, gekoppeld aan de TPM-chip. Intels SGX gebruikt een DAA-variant, genaamd Enhanced Privacy ID (EPID). Ondertussen werden meer dan 2,5 miljard EPID-credentials uitgegeven. Het is vandaag wellicht de meest succesvolle toepassing van anonieme credential technologie.

Ondanks deze enkele globale use cases zien we tot op vandaag slechts een zeer beperkte adoptie van anonieme credentials in de settings waar we het het meest zouden verwachten: identiteitsbeheer.

Kwantumresistentie

Zoals reeds uitvoerig in eerdere Smals Research artikels toegelicht, is er het gevaar dat krachtige kwantumcomputers in de toekomst moderne publieke sleutelcryptografie zouden kunnen breken.

De onderstaande figuur geeft een overzicht van de belangrijkste technieken voor anonieme credentials die door de academische community voorgesteld werden. De eerste generatie was gebaseerd op RSA of elliptische krommen. Vanaf 2004 volgde een generatie gebaseerd op bilineaire afbeeldingen (pairings). De derde generatie anonieme credentials is gebaseerd op lattices en is de eerste generatie die gebruik maakt van cryptografie die verondersteld is kwantumresistent te zijn.

Figuur 1 Tijdlijn van belangrijkste publicaties m.b.t. anonieme credentials (bron)

Momenteel zijn er dus slechts enkele kwantumresistente systemen voor anonieme credentials voorgesteld. Deze systemen zijn nog jong en onvoldoende performant om in de praktijk inzetbaar te zijn. Er is dus meer onderzoek vereist naar efficiënte kwantumresistente oplossingen voor anonieme credentials.

Dit artikel vermeldde reeds dat een vooraanstaande groep wetenschappers in cryptografie ervoor pleiten om ondersteuning voor anonieme credentials  in de EU digital identity wallet (EUDIW) te voorzien. Ze geven twee geldige argumenten waarom de kwantumdreiging niet of nog niet van toepassing is.

• Anonieme credentials worden gebruikt voor authenticatie; een authenticatiesessie blijft maar een zeer korte tijd geldig; niet meer dan enkele minuten. Denk bijvoorbeeld aan authenticatie met ItsMe. Dit staat in schril contrast tot encryptie (bijvoorbeeld communicatie), waarbij een aanvaller vele jaren heeft om de onderschepte vercijferde data te decrypteren (harvest now decrypt later). We kunnen voor authenticatie dus veel korter op de bal spelen en hebben dus veel meer tijd (minstens een decennium, volgens jouw schrijver).
• De vandaag meest populaire anonieme credential-technologieën, zoals diegene voorgesteld door Camenisch en Lysyanskaya in 2004 bieden onvoorwaardelijke veiligheid; zelfs een hypothetische aanvaller met oneindige (klassieke of kwantum-) rekenkracht zou ze niet kunnen breken, hoewel de technologie – dit kan contradictorisch klinken – onderliggend gebruik maakt van bouwblokken die wel met krachtige kwantumcomputers gebroken zouden kunnen worden.

Er zijn dus geen technologische redenen die de adoptie van anonieme credential-technologie in de weg staan. Wel is er nog een ander obstakel… perceptie! Emad Heydari Beni, een onderzoeker cryptografie aan COSIC (KU Leuven) en Bell Labs, postte onlangs op LinkedIn het volgende bericht: “Indien het niet postkwantum is, willen de mensen uit de industrie niet eens naar je luisteren”. Bovenstaande tweeledige argumentatie is bijgevolg wellicht onvoldoende overtuigend voor de industrie.

Zorg er in elk geval voor dat je oplossing crypto-agile is als je met anonieme credentials aan de slag gaat, zodat je snel kan migreren naar een nieuwere technologie wanneer nodig.

Conclusie

Samengevat worden anonieme credentials na decennia onderzoek en ontwikkeling en ondanks hun potentieel in de praktijk nog maar in beperkte mate gebruikt om persoonsgegevens echt te beschermen. Haar potentieel wordt nog bijlange niet ten volle benut, al geven projecten zoals Hyperledger er wel een positieve stimulans aan. Ook worden dankzij onder meer Signal en Intel SGX specifieke types anonieme credentials wel degelijk breed geadopteerd.

Een obstakel voor de adoptie in de context van identiteitsbeheer is het gebrek aan standaarden. Dankzij het voorbereidend werk door onder meer W3C, de Decentralized Identity Foundation, IETF/IRTF en ISO zou dat, mits een politieke wil, vrij vlot mogelijk moeten zijn, aldus de eerder vermeldde groep cryptografen. De technologie heeft trouwens nog een andere uitdaging op haar pad, met name overtuigend kwantumresistent worden.

Het blijft momenteel dus koffiedik kijken of de technologie zal doorbreken als tool voor privacyvriendelijk identiteitsbeheer. Misschien is het aan de publieke sector om hier het voortouw in te nemen en anonieme credentials tot een succesverhaal te maken.

Aarzel niet ons te contacteren bij interesse!

Om na te gaan wat het inhoudt om een custom assistant te voorzien, raken we hieronder de verschillende benodigde componenten aan. Die componenten zijn samengevat in onderstaand schema: de gebruikersinterface (gebruikerservaring), het conversational platform, de spraakdiensten en de back-end.

Gebruikerservaring

Een eerste aspect is de gebruikerservaring. Bij een integratie met een virtuele assistent, zoals Conversational Actions in Google Assistant, kunnen we gebruik maken van het volledige ecosysteem van de virtuele assistent. Conversationele ervaringen kunnen dan aangeboden worden op tal van toestellen waaronder smartphone, smart speaker, tot in de auto toe. Als we een eigen assistant bouwen, dan kunnen we geen gebruik meer maken van dat ecosysteem en verliezen we voor een stuk het gebruiksgemak dat daarmee gepaard gaat, zoals het aanroepen van een assistant met één druk op de knop of een trigger word. We moeten zelf een gebruikersinterface voorzien, doorgaans in de vorm van een app of webtoepassing.

Standaard kan het er voor een gebruiker uitzien als een chattoepassing waarbij input kan gegeven worden via zowel tekst als spraak. Op het scherm kan de gebruiker de historiek zien van de volledige conversatie. In het voorbeeld hieronder is een rudimentaire interface te zien. Uiteraard kan de look & feel naar believen aangepast worden. Dit is een dialoog-gedreven interface waarbij er na elke input van de gebruiker feedback wordt gegeven door de toepassing via tekst en spraak.

Daarnaast kunnen we ons een klassieke interface inbeelden met inputvelden, waarbij spraak als extra feature wordt toegevoegd om parameters aan te leveren. Er is dan geen echte dialoog over-en-weer, maar de mogelijkheid om via continue spraak-input parameters aan te leveren. Een voorbeeld hiervan is Speechly, een tool die toelaat om intents en parameters te herkennen uit een audio-inputstream en daar events aan koppelt. Die events kunnen dan gebruikt worden in de gebruikersinterface om de gedetecteerde parameters in te vullen in velden op het scherm. In de screenshot hieronder is te zien hoe je met een hold-to-talk knop parameters kan ingeven via spraak. De ingesproken tekst is links bovenaan zichtbaar (“book a flight from Brussels to Paris“). De parameters (Brussels en Paris) worden automatisch ingevuld in de betreffende velden van het formulier. De demo kan je hier zelf uitproberen. Momenteel ondersteunt Speechly enkel Engels en Fins.

Conversational platform

Naast de front-end hebben we uiteraard een conversational platform nodig om een custom assistant te bouwen. Die staat in voor het herkennen van intents en entities (parameters), dialoogbeheer en het capteren van alle benodigde parameters om op een vraag te kunnen antwoorden (slot filling). Naast de features en kwaliteit van het conversational platform kan het deployment model van belang zijn in functie van gegevensbescherming en privacy: wordt het platform gehost in de public cloud, of kan het platform in een meer gecontroleerde omgeving draaien (private cloud of on-premise op eigen infrastructuur)? Heel wat aanbieders, zoals Chatlayer, Google en Oswald, bieden een conversational platform onder SaaS-vorm aan in de public cloud. FOD BOSA biedt een raamcontract voor een ‘bot platform as managed service’ dat gebaseerd is op een SaaS-platform. Enkele aanbieders, zoals Cognigy en Nuance bieden daarnaast ook de mogelijkheid om het platform on-premise te draaien.

De keerzijde van het zelf hosten van een oplossing is dat we dan ook zelf moeten instaan voor de infrastructuur waarop het draait, waarbij de nodige aandacht moet uitgaan naar beschikbaarheid, performantie, veiligheid, etc. Die aspecten brengen een zekere kost met zich mee.

Spraakdiensten

Om naast een tekstuele interface ook een spraakinterface aan te bieden zijn er diensten nodig voor spraakherkenning (speech-to-text) en spraaksynthese (text-to-speech). Net zoals bij de conversationele platformen zijn er heel wat spraakdiensten beschikbaar in de public cloud, zoals Amazon, Google en Microsoft. Daarnaast zijn er oplossingen die ook on-premise kunnen gehost worden, zoals Deepgram, Microsoft, Nuance en Speechmatics. De Microsoft speech services uit de Azure cloud kunnen elders gehost worden onder de vorm van Docker containers, in een private cloud of on-premise. Het is zo dat in beide gevallen (Azure public cloud en containers) er een pay-per-use verbruiksmodel gehanteerd wordt.

Bij het zelf hosten van een dergelijke oplossing winnen we hiermee enerzijds aan controle: de verwerkte spraakgegevens verlaten onze eigen infrastructuur niet. Anderzijds moeten we zelf instaan voor de hosting, wat gepaard gaat met extra kosten zoals hierboven beschreven bij het conversational platform.

Tot slot

Eén van de weinige voorbeelden van een custom spraakassistent is KBC Kate. Die laat toe om bepaalde info op te vragen of transacties uit te voeren vanuit de KBC Mobile app via tekst of spraak. In principe zijn de tools voorhanden om een dergelijke custom assistant te bouwen. Een belangrijk aandachtspunt is evenwel gegevensbescherming en privacy. Indien public cloud services geen optie zijn, kunnen we gebruik maken van on-premise alternatieven. Die betekenen echter een extra kost op vlak van hosting, en niet elke aanbieder biedt de mogelijkheid tot een on-premise deployment. Om te experimenteren met dergelijke technologie kan gekozen worden voor een oplossing die zowel in de public cloud als on-premise beschikbaar is. Op die manier kan relatief goedkoop gestart worden met een public cloud oplossing en indien nodig overgeschakeld worden naar een on-premise installatie om tegemoet te komen aan vereisten rond gegevensbescherming en privacy.

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Conversational Actions

Eén van de manieren om een spraaktoepassing aan te bieden is via Conversational Actions van Google. Dat houdt de mogelijkheid in om Google Assistant uit te breiden met een eigen conversationele toepassing. In juni kondigde Google echter de stopzetting van Conversational Actions aan. Standaardfuncties zoals smart home functies (lichten aanzetten) en afspelen van muziek, blijven behouden. Maar de mogelijkheid om custom conversational actions toe te voegen aan Google Assistant verdwijnt. Toepassingen zoals “Hé Google, submit a Dimona!” zijn niet meer mogelijk.

Over de reden van de stopzetting zegt Google dat ontwikkelaars willen voortbouwen op hun bestaande investeringen in Android apps. Google kiest er met andere woorden voor om ontwikkelaars te ondersteunen bij het uitbreiden van hun bestaande Android Apps met spraak, en te vermijden dat er een aparte conversationele toepassing (conversational action) moet ontwikkeld worden. Daarnaast kunnen we ook vermoeden dat conversational actions via Google Assistant, los van apps, niet de verhoopte uptake kennen.

De concrete datum van de stopzetting is 13 juni 2023, datum waarop third party conversational actions niet meer te gebruiken zullen zijn. Voor wie vandaag een dergelijke conversational action aanbiedt is dit een streep door de rekening en stelt zich de vraag welke alternatieven er zijn. We zien 3 mogelijke kandidaten:

1. App Actions
2. Alternatieve virtual assistant
3. Custom assistant

Hieronder bespreken we deze opties en evalueren we de praktische haalbaarheid ervan.

App Actions

Google verwijst zelf naar App Actions als alternatief voor Conversational Actions. App Actions laten toe om apps te lanceren en door te linken naar een app vanaf Google Assistant. Zo kan je bijvoorbeeld zeggen: “Hey Google, order a pizza on ExampleApp.” Als resultaat kom je op het relevante scherm terecht in de betreffende app, of wordt er een widget getoond in Google Assistant.

Het voorbeeld hierboven maakt gebruik van een zogeheten built-in intent (in dit geval “order menu item”), een commando dat door Google standaard ondersteund wordt en waarbij Google ervoor zorgt dat de intentie van de gebruiker goed begrepen wordt. Wordt de functionaliteit die je wil bieden in je app niet ondersteund via een built-in intent, dan kan je een custom intent voorzien.

App Actions lijken een interessant alternatief om op een eenvoudige manier spraak toe te voegen aan een app. In de praktijk zien we echter een aantal beperkingen bij custom intents. Eerst en vooral is er de beperkte taalondersteuning: enkel Engels wordt ondersteund; Nederlands en Frans bijvoorbeeld niet. Daarnaast zijn er slechts beperkte mogelijkheden om parameters door te geven. Er worden slechts 4 types ondersteund (date, time, text, number). En het blijkt ook niet mogelijk om extra parameters op te vragen na het eerste commando. Er is bijgevolg niet echt sprake van een conversatie, maar eerder van een “one-shot” commando.

Deze beperkingen zorgen ervoor dat App Actions op dit ogenblik geen valabel alternatief zijn voor conversational actions.

Alternatieve virtual assistant

Naast Google bieden ook Amazon (Alexa), Apple (Siri) en Samsung (Bixby) een virtual assistant aan. We kunnen ons afvragen of die een goed alternatief bieden. Amazon laat toe om toepassingen (skills) toe te voegen aan de Alexa virtual assistant, vergelijkbaar aan Google conversational actions. Maar helaas biedt Alexa nog geen ondersteuning voor het Nederlands. Bixby, de virtuele assistent van Samsung, ondersteunt ook geen Nederlands en wordt bijgevolg net als Alexa nauwelijks gebruikt in ons land. Met Siri kan je wél interageren in het Nederlands, maar Siri biedt met App Intents enkel functionaliteit die gelijkaardig is aan Google’s App Actions. 

Custom assistant

Een derde alternatief is om zelf een “custom assistant” te voorzien. Dat houdt in dat we geen gebruik meer maken van Google Assistant, maar zelf een app of webapp voorzien waarmee de gebruiker kan interageren via spraak. In een volgende blogpost gaan we hier dieper op in.

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Link to the pdf document: Download

1.   Introduction, Goals, Context

During the Covid19 pandemic, Belgian government IT services responded quickly with solutions to administrate tracking, tracing, and eventually vaccination of citizens. An important pillar of these projects was, and remains to this day, the option to send someone a short message with an instruction or other important info, such as a PCR code. The obvious answer to implement this capability, was the use of the cell phone network’s Short Message Service (SMS).

Using SMS, we were able to reach millions of people expediently. The expense, however, was proportionate. At some point during the crisis costs rose to a very high level, and they are expected to remain high for some time. This problem was seen as one of several linked to the chosen approach. SMS, all things considered, is a technology over 30 years in age, and has other disadvantages. For example, the texts are sent in clear text, readable by intermediaries, such as the carrier. Also, in and of themselves, they only allow for purely textual content, not multimedia. Guarantees with regard to the identity of the person receiving the messages could be enhanced. The use of the mobile phone number had a good fit with the tracking and tracing use case, but did not enable a more general adoption for government communications.

A solution based on mobile applications (Apps) has therefore been conceived. There are many examples of Apps being able to receive messages, containing any kind of content, over the internet, and informing the user with a timely notification. The conceived solution can reduce dependence on SMS and replace many other communication channels. In future embodiments, it will evolve towards a reusable service, operating as an App, capable of centralizing a citizen’s communication with government services entirely. To expedite adoption by as many people as fast as possible, the first embodiment will leverage the existing CovidSafeBe App, already installed on 8.5 million smartphones, using it to encourage the public to install the new communications App.

2.   Solution description

The concept includes integration of the following technologies in order to provide an integrated and secure communications system:

• Fully service oriented design, disclosed by APIs, where the central SMIS (see section 4) governs which channels are used to contact a citizen, and several other services control only a specific channel (such as the Mobile App channel, but also, non-exhaustively, SMS and e-Mail).
• Integration with secure mailbox systems such as e-Box, so messages can contain a link to a document in the e-Box that, when clicked on, can open that document in a mobile App.
• Integration in a digital wallet.
• Identification of the citizen based on a high quality identity scheme and base registry such as used for the NISS number.
• Strong authentication mechanisms such as ITSME.
• End-to-end Encryption between an eGovernment system that sends a message to a citizen, and that citizen’s device, which means the SMIS will only know the sender and the channel preferences, and any service specific to a channel will only know where it is sending a message.
• A pseudonymization system, meaning that the SMIS does not know the addressee and the initial sender does not get additional information about the addressee (such as phone number when only the NISS is known, or vice versa).
• Asynchronous feedback, e.g. via an event subscription mechanism, making it possible to alert a sending application when a message delivery was attempted, when it was successful, and perhaps even when it was read.
• A broadcast mechanism, allowing messages to be sent to groups of people or even the entire country.
• Automated code of conduct imposed on applications using the messaging service, so that citizens do not feel they receive too many messages of little significance.

3.   Initial embodiment

A thorough description of the solution requires us to make a distinction between a short-term strategy, a first embodiment focused on mitigating the SMS expenses currently involved in dealing with the pandemic, and a longer-term strategy, with further embodiments focused on streamlining the eGovernment’s communication with its citizens.

For the short-term strategy, the high-level architecture for the entire implementation is depicted in Figure 1. Key to our approach is the development of a number of centralized, reusable services, and the development of a mobile Application to receive messages for a citizen. For the first embodiment, an initial version of the “Short Messaging Integration Service” (SMIS) meant to unify the use of all communication channels towards the end user, will be built. Furthermore this first embodiment includes the mobile Application itself, plus a second service, specifically meant to drive the transmission of messages, coming from SMIS, towards this App.

3.1.      Short Messaging Integration Service

The Short Messaging Integration Service (SMIS), one of the central components in this solution, will receive messaging requests, via a REST API, from three already existing services (PLF, CTPC and the Tracing BP engine).

The SMIS will be able to use the Mobile App Messaging service or the existing service by RingRing, to send its messages. The primary scheme will be to first try to send a message via the App, and to fall back to SMS, should the former fail for some reason.

On the picture, you can also see the Paloma service. It is yet to be decided whether that service will use the SMIS in the first embodiment or in (one of the) later embodiments.

3.2.      Mobile App Messaging Service + App

The basic functionality of the App in the first embodiment is relatively simple: it will serve to receive and display short messages coming from a government institution, containing text and certain media, such as two-dimensional images, allowing, for example, the depiction of QR codes. It will also employ the smartphone’s functionality called “notifications”, giving the end user an immediate audiovisual queue when new messages are received.

To steer the transmission of messages, a central component is required: the Mobile App Messaging service. This will be a reusable service, offering the capability to other services to transmit a message to an individual citizen. The first implementation of this service should also provide the following immediate feedback to the calling service: whether the App is installed for this citizen, and whether they have the notifications turned on or off at that moment.

3.3.      Authentication and Security

To be able to receive a personal message, a citizen will need to provide some form of identification. There are two possibilities here: phone number, or NISS.

Since for the initial embodiment, SMS is used, the short term strategy will focus on the former, using a simple mechanism often used to confirm an end user’s phone number. The user will register their phone number in the App. A confirmation SMS will then be sent with a unique code. The user then has to fill in this code in the App to prove they are the owner of the phone number.

4.   Expected benefits of the complete solution

• Cost benefits due to reduced number of SMS messages.
• High quality identity based on government base registries.
• Strong authentication based upon high quality identification.
• Privacy protection with encryption and pseudonymization.
• Integration with multiple business systems and multiple administrations.
• Integration with multiple services, e.g. eBox or digital wallet.
• Communication from multiple administrations to mobile systems form multiple recipients without knowledge of the phone number of the device.

In een face-to-face scenario controleert een autoriteit de identiteit terwijl de persoon fysiek aanwezig is. Diegene die de controle uitvoert is getraind in het detecteren van vervalste identiteitsdocumenten en het vergelijken van gezichten. In bepaalde situaties is het niet mogelijk of wenselijk voor iemand om zich fysiek te presenteren voor zo’n identiteitsverificatie. De vraag is dan of die procedure ook van op afstand kan uitgevoerd worden, op een betrouwbare manier. Men spreekt dan over remote identity proofing of remote identity verification naargelang het standpunt van  wie zijn identiteit wil bewijzen of wie een identiteit wil controleren.

In de financiële sector is deze trend het duidelijkst, waarbij banken de mogelijkheid bieden om het onboarding proces volledig online uit te voeren. De pandemie heeft deze trend nog versneld. Online banken hebben zelfs geen kantoren meer waar je fysiek kan langsgaan. Daar is een procedure vanop afstand de enige optie.

Hoe gaat het in zijn werk?

Diverse spelers bieden een oplossing aan voor identiteitsverificatie op afstand op basis van een identiteitsdocument zoals een paspoort, nationale identiteitskaart of rijbewijs. De stappen die een gebruiker doorloopt, worden hieronder besproken. Enkele voorbeelden van oplossingen zijn: IDnow, iProov, Jumio, Onfido en ReadID.

Documentverificatie

In een eerste stap worden de gegevens van het identiteitsdocument uitgelezen, zoals de naam en de geboortedatum, en de geldigheid en validiteit van het document gecontroleerd. Er zijn heel wat oplossingen beschikbaar die deze taken optisch uitvoeren: het capteren van de gegevens en het uitvoeren van controles gebeurt dan op basis van een foto of beelden van het document. Maar dergelijke optische systemen hebben het moeilijk met het detecteren van gemanipuleerde of gekopieerde documenten. Bovendien is OCR (optical character recognition) onderhevig aan fouten waardoor de correctheid/kwaliteit van de gecapteerde gegevens niet gegarandeerd is. Een alternatief is om de gegevens uit te lezen uit de chip van het identiteitsdocument. Dat laat toe om correcte en betrouwbare data te bekomen. Daarbij kan ook de digitale handtekening gecontroleerd  worden die gezet werd door het land van uitgifte van het identiteitsdocument. In deze Quick Review van ReadID wordt uit de doeken gedaan hoe het uitlezen via NFC praktisch in zijn werk gaat. Bij NFC wordt de foto van de houder van het document in hogere kwaliteit bekomen in vergelijking met een optische scan. Die kwaliteit is belangrijk voor de volgende stap: houderverificatie.

Houderverificatie

Na de documentverificatie wordt in een tweede stap gecontroleerd dat de gebruiker die het document presenteert ook effectief de rechtmatige houder ervan is. Daarvoor wordt een selfie (beeld of video) genomen van de persoon die zich presenteert, waarna dat gecapteerde beeld van het gezicht wordt vergeleken met de foto op het identiteitsdocument. De betrouwbaarheid van deze matching is afhankelijk van de bron van de foto. De foto op een identiteitsdocument kan overplakt worden om identiteitsfraude te plegen, wat ongemerkt kan blijven als de foto optisch gecapteerd wordt. Betrouwbaarder is een foto die uitgelezen wordt uit de NFC-chip of een foto die opgehaald wordt uit een authentieke bron. 

Bewijs van leven

Een specifieke aanvullende controle bij de houderverificatie is zogeheten liveness detection: een controle dat de persoon voor de camera een echte, levende persoon is. Er zijn namelijk manipulaties mogelijk waarbij iemand zich probeert voor te doen als iemand anders, door een foto of video te tonen of een masker te dragen.

Een geval waarin een bewijs van leven nodig is, is het uitkeren van pensioenen aan gerechtigden die permanent in het buitenland verblijven en niet beschikken over een Belgisch authenticatiemiddel (eID of Itsme). Gerechtigden moeten zich periodiek fysiek presenteren bij een autoriteit (ambassade of consulaat) om een formulier te laten afstempelen als bewijs van leven en dat papieren document opsturen. Op basis van een oplossing voor remote identity proofing zou die procedure van op afstand, bij wijze van spreken vanuit de luie zetel, kunnen uitgevoerd worden.

Mogelijke obstakels

Betrouwbaarheid

In principe kan het volledige identiteitsverificatieproces uitgevoerd worden door software. Dat betekent dat algoritmes inschattingen maken en beslissingen nemen. Denk bijvoorbeeld aan het matchen van de selfie met de foto op het identiteitsdocument. Leveranciers geven doorgaans weinig informatie over de accuraatheid van hun software, zoals false acceptance rates (FAR) die aangeven welk percentage verkeerdelijk gematched wordt. In het geval het algoritme geen uitsluitsel kan geven over een beslissing kunnen mensen ingeschakeld worden, of er kan voor gekozen worden om elke beslissing van het algoritme te laten valideren door een mens. Het inschakelen van mensen brengt uiteraard een kost met zich mee.

Gebruikerservaring

In principe heeft een gebruiker enkel een toestel nodig met een front-facing camera, zoals een smartphone of een laptop met webcam. Er zijn zowiezo een aantal stappen te doorlopen, dus de leveranciers doen er alles aan om het proces zo vlot mogelijk te laten verlopen. Zo tracht men te vermijden dat een gebruiker actief actie moet ondernemen bij het nemen van een selfie-beeld of -video, zoals knipperen met de ogen of het hoofd bewegen. Het inschakelen van human operators voor het uitvoeren van validaties kan het proces aangenamer maken, maar kan meer tijd in beslag nemen.

Ondersteunde identiteitsdocumenten

Niet alle identiteitsdocumenten beschikken vandaag over een NFC-chip. Op basis van de EU verordening 2019/1157 zijn de EU lidstaten sedert augustus 2021 verplicht om de ICAO 9303 standaarden te volgen bij het uitreiken van identiteitskaarten, waaronder het voorzien van een NFC-chip. Omdat identiteitskaarten in België 10 jaar geldig zijn, zal het nog enige tijd duren eer elke Belg effectief een identiteitskaart met NFC-chip heeft.

Naast identiteitskaarten kunnen ook paspoorten met NFC chip (ePassports) gebruikt worden. Zowat 150 landen hebben dergelijke ePassports. Rijbewijzen of andere identiteitsdocumenten komen ook in aanmerking. Bij gebrek aan een NFC-chip kan een identiteitsdocument eventueel optisch gescand worden of kan de Machine Readable Zone (MRZ) ingelezen worden. 

Wettelijk kader

Tot slot zijn er ook een aantal juridische aandachtspunten. De identiteitsgegevens die verwerkt worden zijn gevoelig, dus stelt zich de vraag in welke mate die gegevens verwerkt mogen worden door een commerciële speler. Een specifiek aandachtspunt is het geval waarbij de aanbieder zijn oplossing host in de cloud. De vraag stelt zich ook naar aansprakelijkheid: wie is verantwoordelijk als het systeem een verkeerde beslissing neemt?

Conclusie

Er zijn oplossingen voorhanden die identiteitsverificatie van op afstand toelaten waardoor gebruikers zich niet moeten verplaatsen om een face-to-face identificatie uit te voeren. Er zijn echter een aantal belangrijke aandachtspunten. In een overheidscontext willen we voldoende zekerheid hebben over de identiteit, zeker als er op basis van de identiteitsverificatie een authenticatiemiddel uitgereikt wordt van een bepaald niveau. Daarom moet een oplossing voldoende betrouwbaar zijn. 

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Niets dan voordelen lijkt het. Maar het voorzien van voicebots is niet zo eenvoudig. Er zijn enkele uitdagingen.

Spraak

Het fundamentele verschil tussen een chatbot en een voicebot is de spraak. In theorie komt het er eenvoudigweg op neer om de gesproken vraag om te zetten naar tekst, deze tekstuele vraag te voeden aan een chatbot en het tekstuele antwoord tenslotte terug om te zetten naar spraak. Het omzetten van spraak naar tekst (Speech-To-Text, STT) is echter niet zo eenvoudig. Systemen voor STT werken beter naarmate ze meer getraind worden. Voor het Engels is er veel trainingsmateriaal voorhanden en zijn de resultaten goed. Aangezien er voor het Nederlands minder trainingsmateriaal voorhanden is, is de kwaliteit van de omzetting iets minder goed.

De beperktere audiokwaliteit bij telefoongesprekken kan ook roet in het eten gooien bij het correct omzetten van spraak naar tekst. Voeg daarbij nog de mogelijke dialecten toe van de bellers en het wordt duidelijk dat de spraak niet altijd even goed begrepen wordt. 

Intentie

Na de omzetting van spraak naar tekst is het de taak van de voicebot om de intentie van de beller te herkennen. Dit is in principe hetzelfde als bij een “klassieke” tekstuele chatbot, maar fouten in de omzetting van spraak naar tekst kunnen de intentieherkenning verstoren.

Als de intentie van de beller niet met voldoende zekerheid kan bepaald worden, dan is het noodzakelijk dat de beller kan doorgestuurd worden naar een menselijke agent. In elk geval verwacht de beller dat hij/zij geholpen wordt bij contactname met het contactcenter.

Om de kwaliteit van de voicebot te kunnen verbeteren is het cruciaal om feedback te vragen aan de beller. Een eenvoudige ja/nee vraag (“bent u geholpen?”) kan al belangrijke input leveren om de voicebot te verbeteren.

Scope

Een specifieke uitdaging bij voicebots is het aangeven van de scope: hoe maken we een beller duidelijk welke vragen hij kan stellen? Deze uitdaging stelt zich al bij tekstuele chatbots, maar is bij voicebots nog groter aangezien er helemaal geen scherm is om de opties te presenteren. Een mogelijkheid is om de scope in het begin aan te geven, eventueel met een voorbeeldvraag. Maar als er teveel mogelijkheden zijn, kan er voor gekozen worden om de beller volledig vrij zijn vraag te laten stellen. Als de vraag binnen de scope valt van de voicebot kan de bot de vraag onmiddellijk beantwoorden, zoniet kan er een transfer gebeuren naar een menselijke agent. 

Personalisatie

Naast algemene vragen zou een voicebot ook kunnen antwoorden op specifieke dossiervragen, bijvoorbeeld “wanneer kan ik op pensioen?”  Antwoorden op vragen over het eigen dossier vereisen dat de identiteit van de beller met voldoende zekerheid gekend is. Waar we de gebruiker bij een klassieke webtoepassing kunnen laten aanmelden met één van de digitale sleutels, is dat bij een telefoonoproep niet evident. Een minimale vorm kan erin bestaan om zich te baseren op het telefoonnummer van de beller. Voorwaarde is dat het telefoonnummer op voorhand gekoppeld werd aan het profiel van de beller. Een andere mogelijkheid is om een aantal vragen te stellen waar enkel de beller het antwoord op kent.

In het ideale geval kan de beller zich authenticeren op basis van zijn/haar stem; de beller hoeft dan geen expliciete actie te ondernemen. Dergelijke voice authentication vereist echter een zekere setup: er moeten voldoende geluidssamples verzameld worden om een voldoende betrouwbare voiceprint te kunnen opstellen. Dit is te vergelijken met het instellen van een fingerprint op een smartphone waarbij je meerdere keren een vinger op de lezer legt vanuit verschillende hoeken. Die voiceprint moet dan nog eens op een betrouwbare manier gekoppeld worden aan de juiste identiteit. Het is met andere woorden verre van evident om een beller op deze manier betrouwbaar te authenticeren.

Privacy

Het is mogelijk dat de conversaties van bellers met de voicebot een tijd bijgehouden worden voor analytische doeleinden. Er moet dan ook stilgestaan worden bij de geldende regels rond privacy, in het bijzonder omdat het gaat over stemopnames. Indien de omzetting van spraak naar tekst gebeurt op basis van een cloud service, is dit een bijkomend aandachtspunt.

Conclusie

Voicebots hebben het potentieel om de werklast van een contactcenter te verlichten en een betere service te bieden aan de beller. Dit is echter op voorwaarde dat de scope van de vragen waar de voicebot op kan antwoorden beperkt is, dat het gaat over algemene vragen (geen specifieke dossiervragen) en dat de spraakinput van voldoende kwaliteit is.

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

In zijn eenvoudigste vorm wordt er informatie getoond in het gezichtsveld van de gebruiker via een head-up display (HUD). Denk aan een schermpje in de wagen waarbij een bestuurder navigatie-instructies te zien krijgt in zijn gezichtsveld of een gevechtspiloot die vluchtgegevens te zien krijgt in zijn gezichtsveld en op die manier niet naar beneden moet kijken naar de instrumenten. In een meer geavanceerde vorm worden objecten accuraat toegevoegd aan de werkelijke wereld, rekening houdend met het 3D-perspectief, zodat ze volledig geïntegreerd lijken met de werkelijke wereld. Met die objecten kan je dan mogelijks ook interageren.

Augmented Reality is niet hetzelfde als Virtual Reality (VR). Waar AR iets toevoegt aan de werkelijke wereld, vervangt VR de werkelijke wereld volledig door een gesimuleerde wereld.
Een standaard smartphone is al voldoende om een AR ervaring te beleven. Zowel Google (ARCore) als Apple (ARKit) leveren frameworks om AR toepassingen te bouwen. Ze laten toe om de positie van de smartphone te traceren en de plaats ervan in de omgeving beter in te schatten. De grootte en positie van oppervlakken, zoals de grond of een tafel, wordt zo goed mogelijk gedetecteerd zodat virtuele objecten zo realiteitstrouw mogelijk toegevoegd kunnen worden aan de werkelijke wereld.

Naast de smartphone zijn er specifieke AR brillen, zoals de Google Glass Enterprise Edition en Iristick Z1 Premium, die informatie kunnen tonen in het gezichtsveld van de gebruiker via een head-up display en op die manier een handenvrije ervaring kunnen bieden. De Hololens van Microsoft gaat nog een stapje verder en laat toe om objecten te integreren in de werkelijke wereld en ermee te interageren.

Toepassingen

Eén van de bekendere voorbeelden van een AR toepassing is het spel Pokémon Go, waarbij spelers virtuele Pokémon moeten zoeken en vangen. Andere voorbeelden zijn de Quiver app waarmee kleurplaten tot leven gebracht worden en de Woody Wereld waarbij de Woodydieren op pyjama’s tot leven komen.

Naast gaming en entertainment zijn er ook toepassingen in de gezondheidszorg. Chirurgen kunnen ondersteuning krijgen bij het uitvoeren van ingrepen. Zo kan via een AR bril informatie of medische beelden gevisualiseerd worden in het gezichtsveld van de chirurg, zoals een tumor of de belangrijkste bloedvaten. Dat kan chirurgen helpen bepalen waar een incisie exact moet gebeuren. Daarnaast kan essentiële informatie over de patient in het gezichtsveld getoond worden bij dringende ingrepen, in plaats van die informatie af te lezen op papier of te consulteren in een elektronisch dossier. Bij hun opleiding kan AR zorgverstrekkers de mogelijkheid beiden om de menselijke anatomie in 3D te verkennen.

In de retail zijn er toepassingen waarbij een meubel virtueel in de woonkamer kan geplaatst worden, zoals met de Ikea Place app, of om te zien hoe je staat met een bepaald kledingstuk.

Ook in de industrie zijn er voorbeelden te vinden: digitale handleidingen en onderhoudsinstructies kunnen geprojecteerd worden op de werkomgeving zodat men de handen vrij heeft om het werk uit te voeren in plaats van een papieren handleiding te moeten doorbladeren. Via de camera van een AR bril kan een collega/expert van op afstand meekijken en assistentie bieden.

Dit is slechts een greep uit de toepassingsmogelijkheden van Augmented Reality. Met al deze voorbeelden kunnen we ons de vraag stellen of dit ook nuttig kan zijn binnen een overheidscontext. Om hier meer inzicht in te krijgen voert Smals Research momenteel experimenten uit in de context van inspectie-opdrachten. Hiermee willen we zelf ervaring opbouwen omtrent de technische mogelijkheden van AR, uitzoeken wat de concrete mogelijkheden zijn voor ondersteuning van inspecteurs op het terrein, en inspiratie bieden voor eventuele andere toepassingsmogelijkheden.

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Als organisatie kan je zelf toepassingen toevoegen aan die spraakassistenten. Amazon spreekt van skills; Google noemt dit actions. Om conversaties met dergelijke spraaktoepassingen zo vlot mogelijk te laten verlopen, schenken we best de nodige aandacht aan een aantal principes voor het ontwerp ervan (conversation design).

Errors

De manier waarop een spraaktoepassing omgaat met fouten bepaalt in sterke mate de gebruikerservaring. Een fout die niet of slecht opgevangen wordt kan ervoor zorgen dat de gebruiker de toepassing snel de rug toekeert. Dit zijn de drie soorten errors die we best opvangen in de conversatie:

Geen match

In bepaalde gevallen begrijpt de toepassing het antwoord van de gebruiker niet, of kan het dat niet correct interpreteren in de context van de conversatie. Dat kan voorvallen als de gebruiker niet volledig of duidelijk antwoordt, niet spreekt tegen de toepassing (maar even iets bespreekt met een andere persoon), of radicaal van onderwerp verandert. Het kan ook voorvallen dat er een fout gebeurd is bij het omzetten van de spraak-input van de gebruiker naar een tekstuele vorm. De gebruiker kan ook een relevant antwoord geven dat niet begrepen wordt door de toepassing. Een voorbeeld:

Gebruiker: “Ik wil tickets kopen”

Toepassing: “Ok, voor hoeveel personen?”

Gebruiker: “Voor mij en de kinderen.”

Toepassing : “Sorry, voor hoeveel personen?”

Om dit op te vangen vraagt de toepassing best nogmaals kort en to the point de nodige input. Loopt het dan weer verkeerd, dan kan de vraag nogmaals gesteld worden met iets meer detail, of eventueel een voorbeeld van een passend antwoord. Lukt het dan nog niet, dan wordt de conversatie best afgesloten om verdere frustratie te vermijden.

Geen input

Soms weet de gebruiker niet goed wat hij moet zeggen, is hij afgeleid of spreekt hij vóór de microfoon openstaat of wacht hij te lang en is de microfoon alweer afgesloten door de virtuele assistent. In die gevallen is er geen input van de gebruiker en moet de toepassing passend reageren. Dat kan door de vraag opnieuw te stellen, eventueel met meer details, een voorbeeld of het expliciet opsommen van de mogelijkheden. Ook hier sluiten we de conversatie best af na twee extra pogingen.

Gebruiker: “Ik wil een aangifte indienen.”

Toepassing: “Ok, wat is het KBO-nummer?”

Gebruiker: <zoekt het KBO-nummer ergens op>

Toepassing: “Wat is het KBO-nummer van de werkgever?”

Systeemfouten

Systeemfouten kunnen voorkomen als een back-end systeem waar de toepassing gebruik van maakt niet beschikbaar is, of een foutmelding teruggeeft.

Toepassing: “Akkoord om deze aangifte in te dienen?”

Gebruiker: “Ja”

Toepassing: “Door een technisch probleem kan ik de aangifte momenteel niet indienen. Wil je dat ik binnen een paar minuten opnieuw probeer?”

In het ontwerp van de conversatie moeten we dus rekening houden met alle mogelijke fouten die zich kunnen voordoen bij elk systeem waar de toepassing op steunt, er duidelijk over communiceren en eventueel een alternatief aanbieden.

Context

Wat een gebruiker zegt, hangt soms af van de context. Dat betekent dat de spraaktoepassing deze context moet bijhouden en er rekening mee moet houden tijdens het verloop van de conversatie zodat wat de gebruiker zegt correct begrepen wordt. Een voorbeeld:

Gebruiker: “Is mijn RVA-kantoor vandaag open?”

Toepassing: “Nee, het kantoor in Hasselt is vandaag gesloten.”

Gebruiker: “En morgen?”

Toepassing: “Morgen is het RVA-kantoor in Hasselt open van 8u30 tot 17u.”

Gebruiker: “En mijn RSZ-kantoor?”

Toepassing: “Het RSZ-kantoor in Hasselt is morgen open van 8u tot 16u30.”

Door rekening te houden met de context kan je de conversatie vlotter laten verlopen en vermijd je dat de gebruiker gefrustreerd geraakt. Het is belangrijk om alle relevante informatie die een gebruiker meegeeft bij te houden zodat de toepassing het begrijpt wanneer de gebruiker er verder in de conversatie naar verwijst. In het voorbeeld hierboven houdt de toepassing bij over welk type kantoor het gaat en over welke datum. Kennis over de lokatie van de gebruiker is vereist om de link te leggen met het desbetreffende lokale kantoor.

Suggesties

In een klassieke grafische gebruikersinterface is het meestal duidelijk welke functionaliteit een toepassing biedt; de gebruiker kan dat afleiden uit de menu’s, invoervelden en knoppen. Bij een spraakinterface is dat minder evident en kan de gebruiker het gevoel hebben dat hij maar moet raden wat hij kan doen. Daarom is het nuttig dat de spraaktoepassing suggesties doet om de gebruiker te helpen bij het beantwoorden van vragen en om bepaalde functionaliteiten te ontdekken.

Gebruiker: “Ik wil een dimona aangifte doen.”

Toepassing: “Ok, wat is de startdatum? Je kan bijvoorbeeld zeggen “4 juni” of “vandaag”.”

De gesproken suggesties kunnen aangevuld worden met suggestie-knoppen op het scherm. Dit biedt de mogelijk om te antwoorden met een druk op de knop en geeft aan welk soort antwoord de toepassing verwacht.

Tot slot

Zo zie je maar dat computers van nature uit niet zo handig zijn in het voeren van conversaties. We moeten een aantal zaken zelf expliciet opvangen in de spraaktoepassing zodat de gebruiker zich op een natuurlijke manier kan uitdrukken en een zinvol antwoord terugkrijgt.

Een goed ontworpen conversationele interface kan een grote meerwaarde betekenen op vlak van gebruiksgemak. Want hoe meer een interface gebruik maakt van menselijke conversaties, hoe minder gebruikers moeten leren omgaan met de interface.

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.