FR3114891A3 - Système d’identification biométrique - Google Patents

Abstract

La présente invention concerne un système informatique d’identification biométrique comprenant : un dispositif de capture configuré pour au moins capturer une première donnée biométrique d’un utilisateur; un serveur biométrique configuré pour stocker la première donnée biométrique de l’utilisateur et pour générer un jeton ID pour l’utilisateur associé aux informations de l’utilisateur; et au moins un point de contact couplé de façon communicative au serveur biométrique, chaque point de contact étant configuré pour capturer une deuxième donnée biométrique de l’utilisateur; le serveur biométrique étant configuré pour comparer la deuxième donnée biométrique de l’utilisateur avec la première donnée biométrique associée à l’utilisateur. Le serveur biométrique est configuré pour récupérer le jeton ID de l’utilisateur et pour permettre l'accès à l’utilisateur par le point de contact lorsque la deuxième donnée biométrique correspond à la première donnée biométrique. Figure pour l’abrégé : Fig. 1

Description

Système d’identification biométrique

L’invention concerne un système de gestion des informations de voyage qui est configuré pour authentifier un voyageur à partir de ses données biométriques.

Les systèmes de reconnaissance permettent d’authentifier une personne sur la base de ses références biométriques et de son identité. Cependant ces systèmes fonctionnent indépendamment des informations de voyage. Si ces systèmes permettent de simplifier l’accès des personnes par la reconnaissance faciale par exemple, ils ne simplifient pas les autres procédures de voyage telles que par exemple la vérification ou l’impression des cartes d’embarquement. Par ailleurs les systèmes de reconnaissance biométriques existant aujourd’hui sont déployés dans des systèmes indépendants qui ne communiquent pas entre eux. Ainsi les données biométriques d’un individu stockées dans un système donné ne sont généralement pas réutilisables dans un autre système utilisant la reconnaissance biométrique.

La présente invention vient améliorer la situation et vise une architecture basée sur la création d’un Jeton ID unique qui est attribué à un voyageur. Ce jeton ID est associé aux données biométriques et identitaires du voyageur pour la reconnaissance biométrique. Par ailleurs le jeton ID unique est associé aux données de voyage du voyageur. Cette double association permet de simplifier grandement les procédures du voyageur. En effet les données de voyage peuvent être récupérées et vérifiées à toute étape du voyage par le système ce qui affranchit le voyageur de la contrainte de présenter à chaque fois son passeport et/ou sa carte d’embarquement par exemple. En outre, l’architecture selon l’invention vise un jeton ID qui est unique pour chaque voyageur et qui est réutilisable dans d’autres systèmes biométriques ce qui facilite le déploiement et favorise l’évolutivité. Le système selon l’invention facilite le déploiement à grande échelle car il est prévu une application sécurisée qui permet à chaque voyageur de s’enrôler et d’enregistrer ses propres données biométriques.

Avantageusement, les données biométriques et les informations de voyages sont accessibles de manière sécurisée en réseaux ce qui rend la reconnaissance possible à travers plusieurs systèmes.

Les éléments de fonctionnalité listés ci-dessus sont donnés à titre d'exemples illustratifs et non limitatifs.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-après présentant des exemples possibles de réalisation, et à l'examen des dessin annexés :

La figure 1 représente une structure générale de l’architecture au sens de l’invention.

La figure 2 représente une architecture fonctionnelle pour l’interopérabilité.

La figure 3 représente une architecture fonctionnelle pour l’enrôlement.

Les figures 4 et 5 représentent une architecture fonctionnelle pour le partage sécurisé des données.

La figure 6 représente un système au sens de la présente invention.

La figure 7 représente une architecture de haut niveau du système au sens de l’invention.

On a représenté sur la figure 1 une structure générale de l’architecture de gestion des identifiants biométriques. Cette architecture comprend une plateforme centrale (3000) adaptée pour la gestion d’identifiants biométriques tels que le « jeton ID ». Le « jeton ID » est dans un exemple de réalisation lié à l’itinéraire du voyageur. En référence à la figure 1, on montre une interface qui établit le lien entre le « jeton ID » et par exemple l’itinéraire de voyage généré par un producteur d’itinéraires de voyage. A chaque fois qu’un nouvel itinéraire est créé, une mise à jour sera effectuée pour associer le nouvel itinéraire au « jeton ID ». Ainsi cette interface établit un lien entre le « jeton ID » et un ensemble d’itinéraires du voyageur. Dans une réalisation, le « jeton ID » est produit par un producteur d‘identifiants numériques (20, 3352’, 3352, 600, 601). Dans une autre réalisation, le « jeton ID » est créé par une application client « TID.app » hébergée sur le terminal (101) du voyageur. Le « jeton ID » va être utilisé pour identifier le voyageur au niveau des points de contact. La plateforme (3000) comprend un module (251) de gestion d’identifiant (par exemple de « jeton ID »), un module qui regroupe les fonctions de gestion d’itinéraires de voyage (322), un module (110) qui représente l’ensemble les fonctions de la couche d’accès (10), et un module de gestion de l’expérience du passager (322’). On montre en référence à la figure 1, une interface de communication entre le module de gestion de l’expérience (322’ ; 3000) de gestion du « jeton ID » et une plateforme de services (334). Les fonctions des modules (322) et (322’) peuvent être réalisées par un orchestrateur (302) présenté à la figure 7. Les identifiants gérés par la plateforme sont utilisés pour identifier le voyageur et pour faciliter la gestion des itinéraires et transactions du voyageur. Le « jeton ID » est utilisé par le module de gestion de l’expérience du passager (322’) pour identifier au sein de ce module un ensemble d’expériences. A cet effet, le module de gestion de l’expérience du passager (322’) de la plateforme dispose d’au moins une interface de communication avec une plateforme de services de voyage (334). Typiquement, une telle plateforme de services de voyage (334) fournit par exemple des services d’information de voyage (3340), de paiement en ligne (3341), de planification de voyage (3342). Le « jeton ID » est utilisé de manière transparente pour identifier de manière unique le voyageur lorsque que celui-ci/celle-ci accède ou utilise différents services (3340, 3341, 3342, 3343, 3344). Le module (110) comprenant l’ensemble les fonctions de la couche d’accès (10) dispose d’au moins une interface de communication avec des plateformes de propriétaires et gestionnaires de dispositifs de captures (103, 105, 107, 109, 111 ; 102 ; 104). Ces dispositifs de captures (103, 105, 107, 109, 111 ; 102 ; 104) étant localisés dans des aéroports (600) ou des agences de voyage (3353) ou des hôtels (700), ou organisation gouvernementales (3352) ou même dans des véhicules (3351). Le module qui regroupe les fonctions de gestion d’itinéraires de voyage (322) dispose d’une interface avec les producteurs d’itinéraires (333, 333’) tels que les agences de voyage (3353), les compagnies aériennes (601), les organisations gouvernementales ou privées (3352, 3352’), les hôtels (700) ou même les véhicules (3351). Le « jeton ID » unique est utilisé dans la gestion des déplacements du voyageur. Par exemple Le « jeton ID » unique d’un voyageur donné est utilisé pour identifier tout itinéraire créé pour ce voyageur. A cet effet, le jeton qui présente l’identifiant unique du voyageur va associer le voyageur à plusieurs itinéraires créés par divers fournisseurs de services tels que les agences de voyages, les compagnies aériennes, les hôtels, les véhicules.

On a représenté également sur la figure 1, une interface de communication entre le module (251) de gestion d’identifiant (par exemple du « jeton ID ») et un fournisseur d’identifiants (20). Le fournisseur d’identifiants fournit des identifiants aux organisations privées (3352’) ou gouvernementales (3352), aux aéroports (600) et compagnies aériennes (601). Le « jeton ID » peut être produit par un des producteurs d‘identifiants numériques (3352’, 3352, 600, 601). Une description des fonctions de fournisseur d’identifiants est présentée ci-après.

En référence à la figure 1, on a représenté schématiquement un module de cœur (3691) ayant pour fonction la transmission d’un identifiant du voyageur (par exemple un identifiant basé sur le « jeton ID ») entre les différents modules (251, 322, 110, 322’) de la plateforme centrale (3000).

La figure 1 présente également une plateforme de gestion de l’identité biométrique (3001) couplée de manière communicative à la plateforme de services de voyage (334). La plateforme de gestion de l’identité biométrique (3001) permet aux services d’identifier un passager donné à l’aide d’un identifiant biométrique créé pour ce passager. Typiquement, un identifiant géré par cette plateforme (3001) va être utilisé pour permettre à un voyageur d’accéder à un ou plusieurs services ou pour lui permettre de réaliser une ou plusieurs transactions de services (3340, 3341, 3342, 3343, 3343). Avantageusement, l’utilisation d’un identifiant biométrique géré de cette manière affranchit le voyageur de la contrainte de l’utilisation de pièces d’identité en papier. Les fonctions de la plateforme (3001) seront par exemple assurées par des fournisseurs tels Gemalto ® , ICM ®, IN Group ®, NEC ®, Idemia ®, Visionbox ® etc.

On décrit en référence à la figure 2, une architecture fonctionnelle pour la réalisation de l’interopérabilité d’un identifiant biométrique et plus particulièrement d’un « jeton ID ». Comme indiqué précédemment, le serveur d’interopérabilité (200) dispose d’une interface d’interopérabilité (206) pour vérifier que le « jeton ID » permanent est unique et interopérable avec d’autres systèmes d’authentification. On a représenté à la figure 2, le module (251) de gestion du « jeton ID » au sein du serveur d’interopérabilité (200). L’interface d’interopérabilité (206) est configurée pour le couplage du module (251) de gestion du « jeton ID » à un fournisseur d’identités biométriques. Dans l’exemple de la figure 2, le fournisseur d’identités biométriques est un fournisseur de « jetons ID » (20). Dans un exemple bien particulier, un fournisseur de « jetons ID » est également producteur de « jetons ID ». La production de « jetons ID » peut être réalisée par certains fournisseurs privés.

En référence à la figure 2, l’interface d’interopérabilité (206) est configurée pour permettre à plusieurs producteurs et/ou fournisseurs de « jetons ID » de se connecter de manière sécurisée au serveur d’interopérabilité (200). Ainsi plusieurs fournisseurs d’identités numériques pourront distribuer des « jetons ID » de manière transparente et sécurisée par l’intermédiaire de l’interface d’interopérabilité (206). Un producteur et/ou fournisseur de « jetons ID » peut créer un « jeton ID » à partir des données personnelles d’un voyageur. Un producteur et/ou fournisseur de « jetons ID » va typiquement mettre en œuvre une base de données (4009) pour stocker des données personnelles (4111) d’un voyageur. Bien entendu les données personnelles (4111) d’un passager sont par ailleurs stockées dans au moins une autre base de données (4013) à l’extérieur du domaine du producteur/fournisseur (20).

Ces données personnelles «External.PersonalData» (4111) peuvent être dérivées d’informations de passeport du voyageur ou de tout autre document d’identité du voyageur. Le producteur et/ou fournisseur de « jetons ID » va créer un « jeton ID » (4113) à partir de ces données personnelles (4111). Les données de passeport sont bien adaptées pour la création d’un « jeton ID » car l’unicité des données de passeport favorise la création de « jeton ID » unique pour chaque voyageur. Bien entendu plusieurs moyens peuvent être mis en œuvre pour la création d’un « jeton ID » unique pour le voyageur. Le « jeton ID » peut être stocké sous plusieurs formes, et dans l’exemple de la figure 2, un « jeton ID » (4113) est stocké en tandem avec des données d’identité « TID.ExternalID » (4115) et des données personnelles (4111) d’un passager.

Le « jeton ID » peut être utilisé par le module (251) de gestion du « jeton ID » pour créer plusieurs identifiants du voyageur. Par exemple en référence à la figure 2, l’identifiant «TID.IDreference» (4211) créé par le module de gestion (251) est une chaîne de caractères comprenant pour préfixe le « jeton ID » ou «TID » (4113) et pour suffixe un identifiant de référence «IDreference ». L’identifiant de référence du voyageur est par exemple généré par le module de gestion (251).

On peut prévoir bien entendu la création de plusieurs autres identifiants à partir du « jeton ID » pour identifier le voyageur et l’itinéraire du passager. Par exemple l’identifiant «TID.username» (4213) est créé par le module de gestion (251) et forme une chaîne de caractères ayant pour préfixe le « jeton ID » ou «TID » (4113) et pour suffixe un non d’usage ou «username» du passager. Par ailleurs, l’identifiant d’itinéraire de voyage «TID.token.journeyID» (4215) est également créé par le module de gestion (251) et forme une chaîne de caractères ayant pour préfixe le « jeton ID » ou « TID » (4113) et pour suffixe la chaîne de caractères «token.journeyID» identifiant un itinéraire du voyageur. On montre à la figure 2 une interface de communication entre le module de gestion des identifiants (251, 200) et le module de gestion de voyage (322). Les identifiants qui sont gérés par le module de gestion d’identifiants sont utilisés au sein du module de gestion de voyage (322). D’autres identifiants (4219 ; 4221) peuvent être générés pour identifier des informations telles que les données contextuelles du voyageur ou des données de services ou des photos et vidéos du voyageur. L’architecture d’interopérabilité de la figure 2 réalise avantageusement la décentralisation de la création d’identifiants puisque des entités autre que le producteur initial (20) sont capables de créer des identifiants pour le voyageur. Par ailleurs cette architecture permet d’attribuer de multiples identifiants à un seul voyageur à partir d’un seul « jeton ID » pour des applications diverses. Ceci favorise la gestion d’identifiants individuels, chaque identifiant pouvant être géré indépendamment du «jeton ID». L’unicité de chaque identifiant étant garantie par l’unicité du « jeton ID » car celui-ci est la racine ou le préfixe commun à tous les autres identifiants. Cette architecture favorise également la scalabilité car de nouveaux identifiants peuvent être créés selon les applications. L’architecture d’interopérabilité de la figure 2 met en œuvre une ou plusieurs bases de données (4001, 4003, 4013) pour le stockage de ces divers identifiants.

Dans un mode de réalisation, les fonctions de gestion d’itinéraires de voyage (322) et les fonctions du module de gestion (251) ont accès aux bases de données (4001; 4003) pour utiliser les identifiants dans la gestion de voyage d’un passager donné.

Il apparaît à la figure 2, que l’identifiant d’itinéraire de voyage «TID.token.journeyID» (4215) et l’identifiant de données de services (4221) ont été transmis à un module (110) de la couche d’accès (10). Ceux-ci peuvent bien entendu être stockés dans une base de données (4011) accessible à cette couche. Ces identifiants seront donc disponibles aux multiples couches physiques des dispositifs de captures (103, 105, 107, 109, 111 ; 102 ; 104) présentés précédemment.

En référence à la figure 2, il apparaît que l’identifiant de données de service (4221, 4223) peut être utilisé par le détenteur du « jeton ID » pour fournir à celui-ci un service externe (4015). Un voyageur ayant reçu un « jeton ID » (4113) attribué par l’architecture selon l’invention peut utiliser un identifiant de données de services (4221, 4223) dérivé de son « jeton ID » pour s’identifier auprès du fournisseur de services (4015). Par exemple, le voyageur peut réaliser un paiement avec son identifiant (4223). Dans un mode de réalisation particulier, la plateforme de service est configurée pour stocker l’identifiant (4223) dans une base de données sécurisée (4017). L’utilisation de l’identifiant (4223) facilite le retrait de données de service de l’utilisateur stockées au sein d’une base de données (4017).

Dans un exemple de réalisation, un identifiant «TID.app» (4252) est créé et forme une chaîne de caractères ayant pour préfixe le « jeton ID » ou «TID » (4113) et pour suffixe par exemple la chaîne de caractères « app ». Cet identifiant (4252) a pour vocation d’identifier de manière unique une application utilisée par l’utilisateur de « jeton ID ». Les applications ainsi identifiées sont par exemple les applications intégrées à un système d’exploitation tel que « Android® » ou autres applications de type web. Ces applications sont typiquement hébergées sur un terminal (101) de l’utilisateur. Comme indiqué précédemment, le terminal (101) est couplé de manière communicative à une passerelle (4007). Ainsi le terminal (101) de l’utilisateur communique avec le module (251) de gestion du « jeton ID » par l’intermédiaire de la passerelle (4007).

On décrit maintenant en référence à la figure 3, une architecture pour l’enrôlement selon l’invention. Cette architecture fonctionnelle a pour rôle de permettre à un voyageur d’envoyer ses données biométriques brutes à un producteur d’identifiants biométriques. Dans un scénario, l’utilisateur envoie une photo de type « Selfie » par exemple au producteur (20). Le producteur (20) va générer au moins un identifiant biométrique pour l’utilisateur à partir de la donnée brute envoyée. L’identifiant biométrique est alors associé à la donnée biométrique brute. La création d’identifiant biométrique peut s’accompagner de la création de « jeton ID » par le producteur d’identifiants (20). Dans un exemple de réalisation le producteur d’identifiants biométriques effectue également les fonctions de producteur de « jeton ID ». On envisage que les producteurs d’identifiants numériques sont en mesure de créer des identifiants biométriques pour l’identification d’un voyageur.

On présente à la figure 3, une plateforme du producteur d’identifiants (20’) couplée de manière communicative avec une plateforme du producteur d’identifiant biométrique (20). On prévoit une interface de communications entre au moins une plateforme de producteur d’identifiants biométriques (20, 20’) et le module (251) de gestion du « jeton ID ».

En référence à la figure 3, on représente une plateforme de gestion de l’identité biométrique (3001) couplée de manière communicative au module (251) de gestion du « jeton ID ». Afin de réaliser l’enrôlement, la donnée biométrique brute de l’utilisateur capturée comme décrite précédemment ainsi que l’identifiant associé à cette donnée biométrique brute sont stockés dans un serveur ou une base de données (3033) de la plateforme de gestion de l’identité biométrique (3001). Dans un mode de réalisation cette plateforme de gestion de l’identité biométrique (3001) peut être implémentée au sein du serveur biométrique (400) présentée à la figure 6.

Dans un mode de réalisation, l’enrôlement comprend l’enregistrement de la donnée biométrique ainsi que l’enregistrement de l’identifiant biométrique. Cet enrôlement peut être initié par l’intermédiaire d’un dispositif de capture tel que le téléphone de l’utilisateur (101) ou par l’intermédiaire d’un kiosk (103).

L’architecture des figures 4 et 5 met en œuvre des services de sécurité, de transport et de stockage des données biométriques et des identifiants biométriques. Cette architecture propose également un environnement pour certifier les services de sécurité utilisés dans la protection des données biométriques et des identifiants biométriques. En référence à la figure 5, on présente des clefs de sécurité (7001) pour assurer la confidentialité des « jetons ID » et/ou des identifiant biométriques stockées au sein d’une base de données (3053) du producteur (20). Ces clefs sont typiquement des clefs de chiffrement symétriques partagées avec les autres modules de l’architecture (251, 110, 101, 322). Ainsi par exemple, un «jeton ID» et/ou un identifiant biométrique transporté depuis la plateforme de producteur (20) vers le module de gestion (251) est chiffré par une clef de chiffrement partagée entre les plateformes du producteur et du module de gestion. L’architecture des figures 4 et 5 permet le transport de données biométriques et/ou d’identifiants biométriques depuis le dispositif d’un voyageur (101) jusqu’au « point de contact » (110) ou « Kiosk » (103). Les identifiants biométriques sont également transportables depuis un fournisseur/producteur d’identité externe (20) jusqu’au « point de contact » (110) ou « Kiosk » (103).

De la même manière, les données d’identité (« jetons ID » et/ou identifiants biométriques) sont transportées de manière sécurisée entre le module de gestion (251) et les autres entités (par exemple une base de données (6031) affiliée au module (110) de la couche d’accès (10)). Par ailleurs, les données biométriques ainsi qu’au moins un identifiant utilisable par une application du dispositif de l’utilisateur (101) sont transportés entre le dispositif de l’utilisateur (101) et la plateforme de gestion (251) de manière sécurisée au moyen d’une clef de chiffrement (7003).

L’architecture des figures 4 et 5 met en œuvre, en outre, des mémoires (3033, 6031), de type mémoire vive, visant à stocker des données pour une durée limitée. Par exemple la base de données (3033) hébergée au sein de la plateforme de gestion de l’identité biométrique peut servir à stocker des données telles que le « jeton ID » temporaire (202) présenté ci-avant. Ces données sont également protégées par des services de sécurité de chiffrement au moyen d’une clef de chiffrement (7005). En référence à la figure 5, les données stockées dans la base de données (6031) associée au module (110) de la couche d’accès (10) sont également chiffrées. Il est prévu que le chiffrement d’une donnée soit réalisé de bout en bout entre la source de la donnée et le destinataire de la donnée. A cet effet une clef symétrique de chiffrement sera utilisée pour le chiffrement d’un identifiant, par exemple «TID.app », transporté depuis le producteur d’identifiants (20) jusqu’au dispositif du voyageur (101). Une autre clef de chiffrement sera utilisée pour le transport sécurisé d’une autre donnée entre deux entités de l’architecture.

On a représenté sur la figure 6 une architecture selon l’invention comprenant au moins un dispositif de capture (101; 103, 105, 107, 109, 111), chacun étant configuré pour la capture des données biométriques des voyageurs. On distingue deux groupes de dispositifs de captures. Un premier groupe comprend l’ensemble des dispositifs de capture dédiés (101, 103) qui sont utilisés pour l’enregistrement des données biométriques. Le deuxième groupe comprend l’ensemble des dispositifs de capture (105, 107, 109, 111) qui sont configurés pour l’authentification biométrique à partir des données biométriques capturées par les dispositifs du premier groupe. Les dispositifs de capture du premier groupe (101, 103) permettent également d’initier l’enregistrement de données biométriques. Ces dispositifs dédiés (103) qu’on appelle « point de contact» ou « Kiosk » (103) ou les terminaux (101) implémentent une application sécurisée qui communique avec un serveur du système. L’architecture met en œuvre un serveur Biométrique (400) ayant pour vocation de stocker de manière sécurisée les données biométriques des voyageurs. Des terminaux de passage (105, 107, 109, 111) également appelés points de contact sont adaptés pour authentifier le voyageur en saisissant au cours de son passage ses données biométriques. Ces dispositifs de capture vérifient donc que les données biométriques capturées du voyageur sont conformes aux données préalablement enregistrées. Ces dispositifs (105, 107, 109, 111) peuvent être déployés à des points où l’authentification du voyageur est requise comme par exemple aux portes de sécurité et d’accès des aéroports.

Dans une réalisation, le dispositif de capture (101, 103) est relié au serveur biométrique (400) par un lien sécurisé de type VPN (« Virtual Private Network » en Anglais) par exemple.

Dans un scénario, le terminal de capture (101) peut être un ordinateur, un téléphone portable ou autre dispositif réservé à l’usage personnel du voyageur.

Typiquement, un tel dispositif de capture dispose d’un scanner ou d’un appareil photo ou d’une caméra (129) pour la saisie de données biométriques. Les données biométriques ainsi saisies peuvent être stockées localement dans une mémoire (131) du dispositif. Un voyageur peut se servir de son téléphone portable pour par exemple prendre une photo qui sera plus tard transformée en donnée biométrique de référence. La donnée biométrique de référence étant une donnée biométrique qui sera enregistrée dans le système et qui servira à reconnaître le voyageur.

On décrit plus en détail, en référence à la figure 6, les fonctionnalités du dispositif de capture selon l’invention. Il est prévu une application (100) client pour la gestion des références biométriques du voyageur. Cette application (100) peut être installée localement sur le dispositif ou sur un serveur distant et accessible par une interface (123 ; 125). Il s’agit d’une application informatique de type SaaS (pour « Software as a service » en Anglais) qui peut être compatible avec un navigateur web par exemple. Cette application peut être implémentée à l’aide d’un outil de développement, en Anglais « Software Development Kit », qui facilite l’implémentation sur plusieurs Systèmes d’exploitation. Le voyageur peut ainsi, par cette application (100), accéder à un compte (123) pour gérer ses références biométriques. En particulier l’application (100) dispose d’une interface (125) qui permet à l’utilisateur de donner son consentement pour l’enregistrement de ses données biométriques. L’application permet également au voyageur de retirer son consentement. L’accord ou le retrait du consentement est enregistré par un module (411) de gestion du consentement sur le serveur biométrique.

On décrit en référence à la figure 6, un scénario de capture à l’aide d’un dispositif (par exemple un téléphone portable (101)). Le voyageur va par exemple lancer l’application et se prendre en photo ou faire un film de son visage pendant une période prédéterminée.

Une donnée brute sous forme de photo ou de vidéo est alors créée et stockée sur le dispositif dans un format approprié (e.g JPEG, TIFF, PNG, PDF, PSD, RAW ; MPEG- 1,2,4, 7, Div X; QuickTime ®, RealVideo®, Windows Media ®, etc).

Dans un mode de réalisation privilégié, la donnée capturée à l’état brute par le dispositif est envoyée de manière sécurisée au serveur biométrique (400). La donnée à l’état brute est ainsi stockée de manière sécurisée dans une mémoire (403) du serveur biométrique (400).

Dans le mode de réalisation privilégié, le serveur biométrique (400) génère un identifiant appelé « jeton ID » qui va identifier le voyageur de manière unique. Plusieurs moyens peuvent être mis en œuvre pour la création de ce « jeton ID ». Dès sa création, le « jeton ID » est associé au voyageur et à la donnée biométrique du voyageur.

Afin de créer une référence biométrique, le serveur biométrique (400) convertit la donnée brute du voyageur en une maquette biométrique (405) qui est également stockée sur le serveur biométrique (400).

Le « jeton ID » qui a pour rôle d’identifier sans équivoque le voyageur, est associé à la fois à la donnée brute du voyageur et à la maquette biométrique créée à partir de cette donnée brute. Une entité de gestion (409) hébergée sur le serveur biométrique associe le « jeton ID » à la donnée brute (403) du voyageur et à la maquette biométrique (405).

Par la suite, Il conviendra d’appeler donnée biométrique de référence toute donnée comprenant au moins une telle maquette biométrique stockée sur le serveur (400). Lorsque la donnée biométrique du voyageur est stockée de manière sécurisée dans le serveur biométrique (400), l’étape d’enrôlement du voyageur est terminée.

Plusieurs données biométriques peuvent être stockées pour un seul voyageur identifiable par un « jeton ID » et ces données sont stockées dans une unité (413) du serveur biométrique (400).

Dans une réalisation le « jeton ID » peut être généré antérieurement à l’enrôlement et donc à l’enregistrement de la donnée biométrique de référence et peut être attribué au voyageur avant ou au moment de cette phase d’enrôlement.

En pratique, un voyageur peut initier la phase d’enrôlement de sa donnée biométrique de référence via l’application présentée ci-dessus à partir de son portable ou d’un des dispositifs de capture dédiés. Par exemple, le voyageur peut initier son enrôlement auprès d’un « point de contact » ou d’un « Kiosk » (103) ou d’un poste d’enregistrement équipé d’un dispositif de capture dédié. Cette étape d’enrôlement peut se faire au moment où le voyageur arrive dans un aéroport ou au moment où le voyageur enregistre ses bagages. Le voyageur peut également faire cet enrôlement chez lui avant son voyage.

On va maintenant décrire la phase d’enrôlement qui comprend l’enregistrement de la donnée biométrique et des informations d’un document d’identité. La donnée biométrique brute du voyageur est enregistrée d’une manière décrite plus haut et les informations d’identité du voyageur sont également obtenues à partir d’un document d’identité tel un passeport ou une carte d’identité. Dans une réalisation le dispositif de capture (103) comprend également un lecteur de document tel un scanner pour capturer et enregistrer les informations de passeport sous une forme numérique.

En pratique, un dispositif de capture dédié (103) et disponible au grand public peut réaliser à l’aide d’un programme informatique les fonctions de capture de données biométriques brutes et la lecture de document d’identité. Dans un scenario, un tel dispositif est équipé d’une interface tactile, d’une caméra et d’un scanner. Ce dispositif peut être un dispositif de type«CUTE » (pour « Common Use Terminal Equipment » en Anglais) qui implémente par exemple des programmes Paxtrack ® de Resa ® .

Dans une réalisation, la donnée biométrique à stocker est créée à partir des informations des données biométriques à l’état brute et des informations d’identité obtenues d’un passeport par exemple. On peut envisager plusieurs fonctions mathématiques pour combiner ces informations et créer une donnée biométrique unique et sécurisée pour le voyageur. Par exemple les fonctions de Hachage telles que MD5 (« Message Digest Algorithm 5» en Anglais) ou SHA -2, -3 (pour « Secure Hashing Algorithm -2, -3» en Anglais) sont bien adaptées puisqu’elles produisent une valeur de sortie appelée communément empreinte numérique ou valeur de hachage à partir de laquelle il est impossible de calculer la donnée d’entrée. De telles fonctions cryptographiques sont bien adaptées pour protéger la sécurité des données biométriques brutes et les informations de passeport.

Dans une réalisation, le « jeton ID » est créé au moyen d’une fonction mathématique de hachage et à partir des données biométriques brutes et/ou des données d’information de passeport. Bien entendu plusieurs moyens et méthodes peuvent être mis en œuvre pour la création d’un « jeton ID » unique pour le voyageur.

On va décrire maintenant, en référence à la figure 6, les moyens mis en œuvre pour l’authentification d’un voyageur lorsqu’un voyageur se présente au niveau d’un des dispositifs de passage ou points de contact (105, 107, 109, 111). Ces dispositifs font parti de l’ensemble des dispositifs du deuxième groupe (105, 107, 109, 111).

Cette authentification selon l’invention n’est pas limitée à la reconnaissance faciale et peut également s’appliquer à la reconnaissance d’empreintes digitales.

On considère qu’un voyageur a déjà participé à l’enrôlement décrit précédemment. Par conséquent les données biométriques du voyageur sont déjà stockées dans le server Biométrique (400) et le voyageur dispose déjà d’un « jeton ID », lequel est associé à la donnée biométrique de référence du voyageur. Un module de gestion (401) est prévu dans le serveur Biométrique (400) pour réaliser cette association entre le « jeton ID » et la donnée biométrique de référence du voyageur.

Un dispositif de capture du deuxième groupe (105, 107, 109, 111) va obtenir une donnée biométrique brute, par exemple une image numérique du visage du voyageur d’une manière décrite précédemment. Le dispositif de capture est adapté pour associer cette donnée brute du voyageur au « jeton ID » attribué au voyageur pendant son enrôlement.

Cette donnée brute est envoyée avec le « jeton ID » de manière sécurisée par des moyens de cryptographie au serveur Biométrique (400).

Le Serveur Biométrique (400) convertit cette donnée brute en une donnée biométrique par des moyens de conversion du module (405) déjà présentés plus haut. Le serveur biométrique (400) se sert du « jeton ID » pour récupérer la donnée biométrique de référence stockée pour le voyageur pendant la phase d’enrôlement. Le serveur (400) compare la donnée biométrique capturée à la donnée biométrique de référence stockée pour le voyageur. Le serveur (400) vérifie que cette donnée biométrique capturée associée au « jeton ID » correspond à la donnée biométrique de référence stockée pour le voyageur.

La comparaison est effectuée par un module de comparaison (407) utilisant des fonctions mathématiques de comparaison de motifs par exemple.

Lorsqu’il résulte de cette comparaison que la donnée biométrique reçue associée au « jeton ID » correspond à la donnée biométrique de référence stockée pour le même « jeton ID » le serveur biométrique envoie un message de succès au dispositif de capture (103, 105, 107, 109, 111).

Ainsi le dispositif de capture (103, 105, 107, 109, 111) reçoit la confirmation du serveur biométrique que le voyageur est authentifié.

Avantageusement cette méthode d’authentification biométrique évite au voyageur de présenter un passeport ou une carte d’identité à chaque fois qu’il passe un point de contact (103, 105, 107, 109, 111) où son identité doit être vérifiée.

Si le dispositif de capture est associé à une porte de passage, l’authentification d’un voyageur selon la méthode décrite précédemment peut déclencher automatiquement l’ouverture d’une porte pour permettre le passage du voyageur.

Dans les aéroports par exemple, une architecture selon l’invention permet de réduire considérablement les temps de passage au niveau des portes de sécurité et/ou d’embarquements (105, 107, 109, 111).

L’authentification des personnes par les données biométriques permet d’améliorer la fluidité du flux de personnes au niveau d’une porte d’accès par exemple.

Avantageusement, le système selon l’invention est facilement déployable. Il suffit pour ce déploiement de mettre à jour des dispositifs de capture (101, 103, 105, 107, 109, 111) avec les programmes capables d’exécuter les instructions de l’application selon l’invention. Grâce à l’enrôlement, l’architecture permet au voyageur d’être authentifié depuis tout point connecté au server biométrique (400). Ainsi, le système d’authentification biométrique selon l’invention est ubiquitaire.

L’architecture selon l’invention offre une plus grande flexibilité de déploiement car les dispositifs ordinaires tels les téléphones portables peuvent être utilisés pour l’enrôlement et l’enregistrement des données biométriques de référence.

Les données biométriques de référence stockées peuvent être transférées de manière sécurisée entre plusieurs plateformes. Ainsi le voyageur n’aura pas besoin de refaire un enrôlement à chaque fois qu’il visite une nouvelle plateforme lorsque ses données biométriques ont déjà été transférées avant son déplacement.

On décrit maintenant un exemple de création du « jeton ID » unique qui est attribué au voyageur lors de la phase d’enrôlement selon un mode de réalisation.

Dans une réalisation, un dispositif de capture dédié est apte à générer un « jeton ID » temporaire (202) lors de la phase d’enrôlement par exemple. Un serveur d’interopérabilité (200) va convertir le « jeton ID » temporaire en un « jeton ID » permanent (204) pour le voyageur. Cette conversion assure que le « jeton ID » permanent généré est unique et qu’il peut être réutilisé par d’autres systèmes de reconnaissance. Le serveur d’interopérabilité dispose ainsi d’une interface d’interopérabilité (206) pour vérifier que le « jeton ID » permanent est unique et interopérable avec d’autres systèmes d’authentification. A cet effet, le serveur d’interopérabilité dispose d’une entité de certification (208) qui est apte à certifier l’origine du « jeton ID ».

En référence à la figure 6, l’interface d’interopérabilité (206) est configurée pour être couplée de manière communicative à un fournisseur de « jetons ID » (20).

Le « jeton ID » unique facilite la gestion des données car le « jeton ID » unique est associé à la fois aux données biométriques du voyageur et à ses informations de voyage. Par exemple, on peut envisager une application qui associe un ensemble de données de voyages d’un voyageur au « jeton ID ». En utilisant par ailleurs l’association entre le « jeton ID » et les données biométriques du voyageur, on peut retrouver ou vérifier l’identité du voyageur. Cette double association peut également être réutilisée pour proposer de manière sécurisée plusieurs applications et services au voyageur au vu de ses voyages antérieurs.

Le « jeton ID » qui identifie de manière unique le voyageur peut être réutilisé plusieurs fois pour associer le voyageur à ses différents voyages.

On décrit maintenant une fonction de gestion des informations de voyage du voyageur. Le système selon l’invention prévoit un serveur nommé « orchestrateur » (300) qui stocke les informations de voyage tels que les informations de carte d’embarquement et/ou les étapes de voyage. Dans un mode de réalisation, ce serveur (300) associe également les informations de voyage d’un voyageur au « jeton ID » de ce voyageur. Par exemple une table de correspondance (301) peut être prévue pour associer les informations de voyage du voyageur au « jeton ID » lui ayant été attribué. Le « jeton ID » du voyageur est disponible à l’orchestrateur (300) car ce dernier a établi une interface de communication (350) sécurisée avec le serveur biométrique (400). En pratique les fonctions de l’orchestrateur (300) peuvent être réalisées par le serveur biométrique ou par un autre serveur distinct du serveur biométrique.

La fonction de l’orchestrateur permet de récupérer les informations de voyage (e.g la carte d’embarquement) à chaque fois qu’un dispositif de capture vérifie l’identité d’un voyageur de la manière présentée précédemment.

Avantageusement, cette fonction permet au voyageur de progresser dans un aéroport par exemple sans être contraint de transporter sur lui sa carte d’embarquement car celle-ci peut être disponible à tout point de passage (point de contact) ou la vérification selon l’invention est effectuable. Dans certains scénarios, on peut envisager l’impression de la carte d’embarquement seulement au moment de l’accès à l’avion ce qui élimine le risque d’égarer la carte d’embarquement.

Dans un exemple de scénario selon un mode de réalisation, le voyageur peut déclencher lui-même le retrait de sa carte d’embarquement au moyen d’un module (127) de l’application (100) à partir du « jeton ID ». Le module (127) représente également des fonctionnalités de gestion de voyage telles que par exemple des fonctions de gestion d’itinéraires.

Lorsque les fonctions de l’orchestrateur et du serveur biométrique sont combinées, l’architecture selon l’invention améliore la sécurité et la fluidité du flux des voyageurs. Lors du passage du voyageur à un point de contact (105, 107, 109, 111), le voyageur sera authentifié automatiquement par ses données biométriques et le jeton ID attribué est utilisé pour récupérer les informations de voyage. Ainsi le voyageur n’aura pas besoin de présenter à chaque fois un passeport par exemple et une carte d’embarquement, ce qui réduit considérablement les temps d’attente.

On décrit maintenant en référence à la figure 7, une architecture fonctionnelle de haut niveau correspondant à l’architecture de la figure 6. On fera ci-après référence aux deux figures. La figure 7 présente une couche d’accès (10), une première couche de services (11) et une deuxième couche de services (21) et des interfaces (31, 35) de communications entre ces couches. Les fonctions du serveur biométrique sont présentées dans la première couche de services (11) qui se situe entre la deuxième couche de services (21) et la couche d’accès (10). La couche d’accès (10) est commune à plusieurs dispositifs de capture (103, 105, 107, 109, 111) et/ou dispositifs d’enregistrement (102 ; 104). La couche d’accès se situe entre les multiples couches physiques des dispositifs (103, 105, 107, 109, 111 ; 102 ; 104) de l’architecture et la première couche de services (11) qui comprend les fonctions biométriques. La couche d’accès (10) permet aux fonctions biométriques et aux fonctions de gestion de données de voyage (301 ; 302) d’avoir un accès direct aux dispositifs physiques (102; 103 ; 104 ; 105 ; 107 ; 109 ; 111). Une interface (31) de communication est configurée pour le transport des données entre les dispositifs et la première couche de services (11).

En référence à la figure 7, la première couche de services (11) comporte le premier bloc (12) des fonctions biométriques et un deuxième bloc des fonctions locales de l’orchestrateur (301). Le bloc des fonctions locales de l’orchestrateur correspond à l’ensemble des fonctions de l’orchestrateur (301 ; 302 ) qui sont réalisées et utilisées au niveau d’un aéroport donné.

Les blocs de services biométriques (12) et des fonctions locales (301) de l’orchestrateur communiquent entre eux par l’intermédiaire d’une interface (33). Cette interface permet de combiner les fonctions du premier bloc (12) du serveur biométrique et les fonctions locales de l’orchestrateur (301). Ainsi cette interface (33) est configurée pour réunifier les fonctions d’authentification biométriques et les fonctions de gestion des données de voyages disponibles localement.

Comme indiqué précédemment, une donnée capturée par un dispositif dédié tel qu’un « point de contact » ou un « Kiosk » (103) ou un terminal (101) peut être envoyée de manière sécurisée au bloc de fonctions biométriques (12 ) par l’intermédiaire de l’interface (31). On rappelle que les fonctions biométriques (12) sont implémentées, sur le serveur biométrique (400) présenté à la Figure 6. Le bloc des fonctions biométriques (12) représente l’ensemble des fonctions d’authentification biométriques y compris la comparaison et la vérification des données biométriques telles que précédemment décrites.

Les blocs (401, 403, 409, 411, 413) de le Figure 7 représentent les fonctions des entités de gestion et de mémoire du serveur biométrique (400) de la figure 6 ayant les mêmes références. Les fonctions biométriques peuvent contrôler un dispositif d’accès en envoyant une commande à ce dispositif par l’intermédiaire de l’interface (31). Par exemple Lorsqu’un qu’un dispositif de capture est associé à une porte de passage (105 ; 107 ; 109 ; 111), l’authentification d’un voyageur selon la méthode décrite précédemment peut automatiquement déclencher l’ouverture de la porte.

En référence à la figure 7, la deuxième couche (21) de services comprend au moins un premier bloc des services de l’enrôlement (23) et un deuxième bloc des services de gestion de l’interopérabilité (25). Ces services peuvent par exemple être implémentés par l’application d’enrôlement (100) et par le server d’interopérabilité (200) décrits plus-haut.

La deuxième couche de services (21) comprend également un troisième bloc de services (302) représentant une partie des fonctions de l’orchestrateur (300). Ce bloc comprend les fonctions de gestion de voyage y compris de gestion d’itinéraires de voyage (322). Il comprend également un ensemble de fonctions d’exécution de services (323). Ce troisième bloc fonctionnel est couplé de manière opérationnelle au bloc des fonctions locales de l’orchestrateur (301). La figure 7 illustre une interface de couplage (35) entre les deux blocs de l’orchestrateur. Ainsi les données d’un voyageur stockées localement au sein d’un aéroport par exemple peuvent être rendues disponibles à la couche des autres services de l’enrôlement (23) et de l’interopérabilité (25). Par ailleurs les résultats des opérations d’authentification biométriques sont rendus disponibles aux autres services de l’enrôlement (23) et de l’interopérabilité (25) par les fonctions de l’orchestrateur (301, 302 ; 300).

Les fonctions de cette deuxième couche de services (21) sont accessibles et disponibles en réseaux à plusieurs autres plateformes. Par exemple les fonctions de cette couche peuvent être disponibles à d’autres aéroports (600), à des hôtels (700) ou à d’autres types de fournisseurs de services (800). La couche de service (21) est configurée pour communiquer avec ces autres plateformes par l’intermédiaire du bloc fonctionnel de l’orchestrateur (302). Par exemple les informations liées à l’authentification d’un voyageur et/ou les données de voyage d’un voyageur peuvent être transférées de manière sécurisée depuis ce bloc fonctionnel (302) vers les autres plateformes (600, 700, 800) et vice versa. On peut également envisager le partage même des données biométriques stockées localement si celui-ci est négocié et réalisé en toute sécurité. Ce partage d’informations est bien entendu soumis au consentement de l’utilisateur. A cet effet il est prévu des fonctionnalités de gestion du consentement (321) de l’utilisateur au sein de l’orchestrateur (302 ; 300). Ce partage d’information permet aux autres systèmes comme par exemple les systèmes de réservation d’hôtel (700) de bénéficier d’informations du voyageur présentes sur l’architecture au sens de l’invention. Par ailleurs le partage d’informations concernant les données biométriques permet au voyageur de ne pas avoir à refaire un enrôlement lorsqu’il visite une nouvelle plateforme. Lorsque les données biométriques sont préalablement transférées, le voyageur peut gagner du temps en évitant la phase d’enrôlement des données biométriques à chaque fois qu’il visite un des aéroports partenaires (600, 601).

Claims (9)

1. Système d’identification biométrique comprenant: un dispositif de capture (101, 102, 103, 104) configuré pour au moins capturer une première donnée biométrique d’un utilisateur, la première donnée biométrique comprenant une caractéristique biométrique; un serveur biométrique (400) configuré pour stocker la première donnée biométrique de l’utilisateur et pour générer un jeton ID pour l’utilisateur associé aux informations de l’utilisateur; et au moins un point de contact (105, 107, 109, 111) couplé de façon communicative au serveur biométrique, chaque point de contact étant configuré pour capturer une deuxième donnée biométrique de l’utilisateur, la deuxième donnée biométrique comprenant au moins la caractéristique biométrique de la première donnée biométrique; le serveur biométrique étant configuré pour comparer la deuxième donnée biométrique de l’utilisateur avec la première donnée biométrique associée à l’utilisateur; le serveur biométrique étant configuré pour récupérer le jeton ID de l’utilisateur et pour permettre l'accès à l’utilisateur par le point de contact lorsque la deuxième donnée biométrique correspond à la première donnée biométrique.
2. Système selon la revendication 1, comprenant une première couche de services (11) qui implémente au moins les fonctions du serveur biométrique (12 ; 400) ; une deuxième couche de services (21) qui implémente les fonctions d’une application (23 ; 100), les fonctions d’un serveur d’interopérabilité (25 ; 200) et les fonctions d’un orchestrateur (27, 302 ; 300); et une couche d’accès (10) pour le couplage du dispositif de capture (101, 102, 103, 104) et de l’au moins un point de contact (105, 107, 109, 111) à l’au moins une couche de services (11, 21).
3. Système selon la revendication 2 dans lequel l’application (100) est configurée pour la gestion de l’au moins une donnée biométrique de l’utilisateur, la gestion comprenant au moins la capture et/ou l’enregistrement de l’au moins une donnée biométrique.
4. Système selon la revendication 2 ou 3, dans lequel le serveur d’interopérabilité (200) est configuré pour gérer le jeton ID pour l’utilisateur, le serveur d’interopérabilité étant couplé de manière communicative à l’application (100).
5. Système selon l’une quelconque des revendications 2 à 4, dans lequel l’orchestrateur (300) est configuré pour gérer les informations de l’utilisateur, l’orchestrateur étant couplé de manière communicative au serveur biométrique (400) et au serveur d‘interopérabilité (200).
6. Système selon l’une quelconque des revendications 2 à 5, dans lequel l’orchestrateur est configuré pour associer le jeton ID de l’utilisateur aux informations de l’utilisateur.
7. Système selon l’une quelconque des revendications 1 à 6, comprenant une interface utilisateur d’enrôlement accessible à l’utilisateur par le dispositif de capture; l’interface étant configurée pour recevoir la première donnée biométrique de l’utilisateur.
8. Système selon l'une quelconque des revendications 1 à 7, dans lequel le serveur biométrique est configuré pour récupérer le jeton ID et les informations de l’utilisateur lorsque la deuxième donnée biométrique correspond à la première donnée biométrique.
9. Système selon l'une quelconque des revendications 1 à 8, dans lequel les données biométriques sont capturées par un scanner et/ou une caméra et/ou un appareil photo.