BR112014003054B1 - Processo de gestão e de controle de diferentes dados de identidade de um indivíduo, e, sistema de gestão e de controle de dados de identidade de um indivíduo - Google Patents
Processo de gestão e de controle de diferentes dados de identidade de um indivíduo, e, sistema de gestão e de controle de dados de identidade de um indivíduo Download PDFInfo
- Publication number
- BR112014003054B1 BR112014003054B1 BR112014003054-5A BR112014003054A BR112014003054B1 BR 112014003054 B1 BR112014003054 B1 BR 112014003054B1 BR 112014003054 A BR112014003054 A BR 112014003054A BR 112014003054 B1 BR112014003054 B1 BR 112014003054B1
- Authority
- BR
- Brazil
- Prior art keywords
- identity
- domain
- individual
- data
- derived
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000009795 derivation Methods 0.000 claims description 45
- 230000006870 function Effects 0.000 claims description 24
- 238000004422 calculation algorithm Methods 0.000 claims description 8
- 238000012545 processing Methods 0.000 claims description 8
- 238000004891 communication Methods 0.000 claims description 3
- 238000013523 data management Methods 0.000 abstract 1
- 238000007726 management method Methods 0.000 abstract 1
- 101150068008 gmk gene Proteins 0.000 description 4
- 238000012795 verification Methods 0.000 description 4
- 230000000737 periodic effect Effects 0.000 description 2
- 101100180956 Pseudomonas putida (strain ATCC 47054 / DSM 6125 / CFBP 8728 / NCIMB 11950 / KT2440) gmk gene Proteins 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013481 data capture Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
- H04L9/3231—Biological data, e.g. fingerprint, voice or retina
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
- H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/42—Anonymization, e.g. involving pseudonyms
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Computing Systems (AREA)
- Life Sciences & Earth Sciences (AREA)
- Biodiversity & Conservation Biology (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Storage Device Security (AREA)
- Collating Specific Patterns (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
PROCESSO DE GESTÃO E DE CONTROLE DE DADOS DE DIFERENTES DOMÍNIOS DE IDENTIDADE ORGANIZADOS EM CONJUNTO DE ESTRUTURA. A invenção se refere a um processo e a um sistema de gestão e de controle de diferentes dados de identidade de um indivíduo. Um servidor de gestão de identidade derivada gera para o indivíduo, em função de informações derivadas de dados de identidade de domínios parentes pelo menos uma parte de identidade com as quais o indivíduo pode se autenticar junto a um fornecedor de serviço para o domínio de identidade derivada. O tratamento de geração dos dados de identidade assegura que nenhum link pode ser estabelecido a partir de duas autenticações em dois domínios distintos na ausência de informação do link. Essas informações de link são, se for o caso, transmitidas por um domínio parente a um servidor de identidade derivada para que ele faça o link entre dados de identidade do domínio de identidade derivada e dos dados de identidade do domínio parente, por exemplo, para revogar em cascata um indivíduo de diferente domínio.
Description
[0001] A presente invenção se refere, de maneira geral, à autenticação de indivíduos, e, mais particularmente, às situações nas quais um indivíduo deve se autenticar sem para tanto divulgar seus dados de identidade principais.
[0002] A invenção se aplica notadamente em situações nas quais um indivíduo possui várias "identidades", cada uma se reportando a um grupo de filiação diferente.
[0003] Por “identidade”, entende-se aqui e em todo o presente texto um ou vários dados de identificação próprios ao indivíduo. Os dados de identificação de cada identidade são função do grupo ao qual se refere essa identidade.
[0004] Um mesmo indivíduo pode possuir várias identidades de diferentes níveis, isto é, identidades mais ou menos importantes no sentido de ser preciso já possuir uma identidade de um nível determinado para poder adquirir uma outra identidade de um grupo de filiação de um nível que depende do nível precedente. Por exemplo, é preciso dispor de documentos de identidade nacional para conseguir uma conta bancária ou um cartão de seguridade social.
[0005] Conforme se acaba de ver, a inscrição de um indivíduo em um grupo, a fim de obter uma identidade no meio desse grupo, está frequentemente condicionada à detenção de uma outra identidade, mais importante. Por exemplo, no caso da inscrição em um serviço de internet, a posse de um endereço de e-mail é frequentemente um pré-requisito.
[0006] Todavia, isto pode se mostrar problemático, em particular quando o fornecimento de informações relativas à identidade importante permite a um membro ou a um gestor do novo grupo ter acesso a dados de identidade privados que o indivíduo não desejava comunicar.
[0007] A título de exemplo, cada vez mais indivíduos são expostos, pela utilização de sites da internet, a que dados privados (endereço de internet ou outros dados pessoais) sejam transmitidos, de forma descontrolada, por um lado, ao gestor, depois pelo gestor, se for o caso, a outros atores.
[0008] Existe, portanto, uma necessidade para identificar o indivíduo, a fim de permitir sua adesão a um novo grupo, sem que os dados de identidade utilizados para essa identificação permitam remontar dados principais de identidade, que o indivíduo não desejaria comunicar.
[0009] Foi proposto, no documento EP 1 164 745, um processo de gestão de um grupo, descrevendo a criação e a atribuição de uma assinatura de grupo a um indivíduo, e a identificação do indivíduo por meio dessa assinatura.
[0010] Todavia, nesse documento, a adesão a um grupo por um indivíduo implica necessariamente a comunicação dos dados principais de identidade do indivíduo, por exemplo, seu nome. Esse documento não descreve também como identificar um indivíduo, sem utilizar dados principais de identidade.
[0011] Foi também proposto no documento FR 2 925 732 um método de autenticação biométrica, permitindo a um indivíduo se autenticar, de maneira anônima, nos meios combinados de dados biométricos e criptográficos.
[0012] Esse processo pode ser combinado com a utilização de assinaturas de grupos, tais como, por exemplo, os esquemas de assinaturas de grupo descritos em: - D. Boneh et H. Shacham; “Group signatures with verifier-local revocation”, EM V. Atluri, B. Pzistmann, e P.D. McDaniel, editores, ACM Conference on Computer and Communications Security, págs. 168-177, ACM, 2004, e/ou em - L. Chen et J. Li. “VLR group signatures with indisputable exculpability and eficient revocation”; em A. K. Elmagarmid e D. Agrawal, editors, SocialCom/PASSAT, págs. 727-734, IEEE Computer Society, 2010, - J. Bringer et A. Patey, “Backward unlinkability for a VLR group signature scheme with eficiente revocation check”, Cryptology ePrint Archive - Report 2011/376.
[0013] Esses esquemas de assinaturas de grupo permitem a um indivíduo se autenticar, provando que ele pertence a um grupo determinado, permanecendo anônimo.
[0014] Esse método permite, portanto, criar uma identidade a partir de informações biométricas próprias a um indivíduo, e autenticar o indivíduo conservando o seu anonimato.
[0015] A invenção propõe, quanto a ela, um processo que permite utilizar uma identidade pré-existente para gerar uma identidade dita “derivada”, a identidade derivada sendo ligada à identidade parente, o link entre essas duas identidades sendo, todavia, oculto, de tal modo que é impossível remontar esse link a partir das autenticações de uma ou da outra dessas identidades, esse link podendo, todavia, ser explorável para, por exemplo, poder revogar a identidade “derivada” de um indivíduo, quando a identidade parente desse indivíduo é ela própria revogada.
[0016] Notadamente, ela propõe um processo de gestão e de controle de diferentes dados de identidade de um indivíduo, esses dados correspondendo a vários domínios de identidades organizados em conjunto estruturado, no qual pelo menos um sistema de controle está apto a utilizar para um domínio de identidade determinado uma autenticação do indivíduo a partir dos dados de identidade associados a esse domínio para o indivíduo.
[0017] Para gerar dados de identidade de um domínio de identidade derivada para o qual é necessário dispor de dados de identidade para um ou uns domínios parentes, utiliza-se para cada domínio de identidade parente, a partir dos dados de identidade do indivíduo para o domínio parente, um tratamento de autenticação do indivíduo junto a um servidor de gestão do domínio de identidade derivada no decorrer do qual, - se transmite ao servidor de gestão do domínio de identidade derivada das informações em função dos dados de identidade do domínio parente e pelo menos uma informação de prova de validade desses dados, - o servidor de gestão de identidade derivada autentica o indivíduo para o domínio parente e controla, por meio da informação de prova, a validade das informações transmitidas.
[0018] Em função dos resultados de autenticação e de controle, - o servidor de gestão de identidade derivada gera para o indivíduo, em função das informações transmitidas, pelo menos uma parte de dados de identidade com as quais o indivíduo pode se autenticar junto a um fornecedor de serviço para o domínio de identidade derivada, - esse servidor de gestão de identidade derivada memorizando informações de derivação, comportando o total ou parte das informações trocadas no decorrer do tratamento de autenticação para posteriormente, se for o caso, em função de informações de link transmitidas por um domínio parente, fazer o link entre dados de identidade do domínio de identidade derivada e dados de identidade do domínio parente, o tratamento de geração pelos diferentes servidores de identidade sendo tal que nenhum link pode ser estabelecido a partir de duas autenticações em dois domínios distintos na ausência dessas informações de link.
[0019] Esse processo permite, portanto, a um indivíduo derivar uma identidade, isto é, gerar uma identidade a partir de uma segunda identidade, mais importante, sem levantar o anonimato sobre o indivíduo.
[0020] Além disso, ele torna impossível a fraude durante a autenticação de um indivíduo, apesar do link entre duas identidades de dois níveis distintos de um mesmo indivíduo.
[0021] Em um modo de utilização, para a autenticação de um indivíduo, junto a um fornecedor de serviço para um domínio de identidade, se transmitem a esse fornecedor de serviço informações determinadas em função dos dados de identidade do domínio, o tratamento utilizado para essa determinação, tornando a informação assim transmitida anônima para qualquer entidade com exceção do servidor de gestão do domínio e do indivíduo que se autentica.
[0022] Por outro lado, os dados de identidade de um indivíduo podem comportar dados biométricos do indivíduo e/ou dados obtidos por tratamento de dados biométricos.
[0023] Também, em aplicações, o processo proposto permite também revogações. Dessa forma, quando um indivíduo é revogado para uma identidade, não pode mais se autenticar com essa identidade. O processo permite notadamente revogações em cascata, isto é, é possível revogar um indivíduo de um certo nível (domínio” de identidade se foi revogado de um nível (domínio) de identidade superior (por exemplo, retirar-lhe uma segurança de viatura se tiver perdido sua autorização para dirigir).
[0024] Assim, pode ser previsto para cada servidor de gestão de domínio de identidade um tratamento de revogação de indivíduo, pelo qual ele publica uma informação de revogação utilizada pelos fornecedores de serviço para impedir um indivíduo revogado de um domínio se autenticar, utilizando os dados de identidade associados a esse domínio.
[0025] A geração de dados de identidade derivada a partir dos dados de identidade associados a esse domínio para o indivíduo é então assim tornado impossível.
[0026] Por exemplo, quando de um tratamento de revogação por um servidor de domínio parente, esse servidor transmite a cada servidor de gestão de identidade derivada informações de link associadas a um indivíduo revogado, essas informações sendo tratadas por esse servidor, a fim de realizar o tratamento de revogação do indivíduo, se este possuir dados de identidade derivada.
[0027] Opcionalmente em certos casos é também possível revogar um indivíduo de um domínio, se tiver sido revogado de um domínio de identidade derivada.
[0028] Notadamente, quando de um tratamento de revogação por um servidor de domínio derivado, esse servidor transmite a um servidor de gestão de identidade parente escolhido informações de derivação associadas a um indivíduo revogado, essas informações sendo, se for o caso, tratadas por esse servidor, a fim de realizar o tratamento de revogação do indivíduo para esse domínio parente.
[0029] A invenção propõe, além disso, um sistema de gestão e de controle aplicando o processo proposto.
[0030] Outras características, finalidades e vantagens da presente invenção aparecerão com a leitura da descrição detalhada que vai ser feita a seguir, em relação às figuras anexadas, dadas a título de exemplos não limitativos e nas quais: - a figura 1 representa um exemplo de conjunto de identidades parcialmente ordenadas para o qual um processo de derivação, conforme a invenção, pode ser utilizado; - a figura 2 ilustra esquematicamente um exemplo de utilização de gestão de uma identidade; - as figuras 3a e 3b apresentam respectivamente um exemplo de processo de aquisição de uma identidade e um exemplo de autenticação; - a figura 4 ilustra esquematicamente um exemplo de derivação de identidade, conforme um modo de utilização possível para a invenção; - a figura 5 ilustra esquematicamente as diferentes etapas da derivação ilustrada na figura 4; - a figura 6 ilustra um exemplo de utilização de revogação em cascata. Descrição detalhada de pelo menos um exemplo de utilização Contexto e formalismo
[0031] Com referência à figura 1, ilustrou-se um conjunto E ordenado de domínios de identidades.
[0032] Nesse exemplo, a identidade nacional lj corresponde ao domínio de nível o mais elevado. Ela é necessária para se inscrever junto à seguridade social (domínio de identidade lk) e obter uma permissão para dirigir. Quando a inscrição na seguridade social ou a obtenção da permissão de conduzir é validada, dados secretos de identidade são comunicados ao indivíduo, por exemplo, sendo armazenados em uma memória de tipo cartão com chip.
[0033] Os dados de identidade comunicados, quando da inscrição na segurança social, podem ser necessários a um empregador para contratar assalariados e lhes atribuir créditos para o domínio da empresa li.
[0034] Esse conjunto é organizado, de forma parcialmente ordenada, as seguintes relações aí se aplicam: - reflexividade:
- transitividade:
- anti-simetria: 
[0035] onde x < y significa que o domínio de identidade x está abaixo do domínio da identidade y.
[0036] Em toda a sequência, dir-se-á que um domínio de identidade x do conjunto E parcialmente ordenado é parente de um outro domínio y se y < x e
.
[0037] Por exemplo, de volta à figura 1, o domínio de identidade “permissão para conduzir” é parente do domínio “segurança do veículo”; a identidade nacional é quanto a ela parente da identidade “seguridade social”.
[0038] Na figura, os conectores representados entre dois domínios distintos implicam em qual identidade deve possuir Mi para poder adquirir uma identidade do domínio exato abaixo. No exemplo, para se obter uma identidade do domínio li “segurança do veículo”, o indivíduo Mi deve possuir uma identidade de seguridade social e uma permissão de conduzir.
[0039] A utilização descrita no que se segue utiliza, a título de exemplo, a assinatura de grupo, tal como proposto no artigo de Bringer et Petey já citado. Poder-se-á vantajosamente se referir a esse artigo, o exemplo de utilização detalhado abaixo, retomando as anotações.
[0040] No protocolo proposto nesse artigo, para cada grupo: - o gestor GM possui uma chave secreta msk; - cada indivíduo Mi membro do grupo possui uma chave secreta ski = (fi, xi, Ai) onde o elemento fi é escolhido por Mi e os elementos xi e Ai fornecidos pelo gestor; - para cada indivíduo, existe um token de revogação rti derivado de ski armazenado pelo gestor em uma base de dados DB; no exemplo que se segue, tem- se rti = xi; - o gestor publica uma lista de revogação RL onde são arquivados os tokens de revogações dos usuários revogados do grupo.
[0041] Esse protocolo utiliza particularmente dois algoritmos: - “Sign” que permite a um membro do grupo assinar uma mensagem com o auxílio de sua chave secreta ski; - “Verify” que permite a qualquer pessoa, munida unicamente da lista de revogação, verificar a validade de uma assinatura, o que atesta a filiação do signatário ao grupo.
[0042] No caso, no exemplo que se segue e com referência à figura 2, cada domínio de identidade l é gerado por um gestor de identidade correspondente GMI que é a autoridade que pode liberar uma identidade ao indivíduo MI e que é um gestor de grupo no sentido do artigo precitado.
[0043] Esse gestor GMI pode assumir a forma de um programa informático utilizado no nível de um servidor de gestão de identidade associado a capacidades de armazenamento e notadamente a uma base de dados DBI que armazena os dados de enrolamento dos indivíduos que possuem uma identidade nesse domínio, assim como tokens de revogação próprios a cada indivíduo. Esse programa gera os arrolamentos e revogações, da forma que é descrita a seguir. Ele não participa das autenticações, que são geradas por programas próprios aos fornecedores de serviço, requerendo a possessão de uma identidade desse domínio.
[0044] Para adquirir a primeira identidade IO, a saber, no caso a identidade nacional lj, o indivíduo Mi pode utilizar, assim como ilustrado na figura 3a, um processo de arrolamento similar àquele descrito no documento FR 2 925 732. Em particular, pode, por exemplo, fazer a aquisição por meio de um captador 11 de um traço biométrico b, que é, em seguida, armazenado em um cartão pessoal 12, tal como um cartão com chip, ou uma chave USB. Pode também constituir o objeto de uma impressão em papel.
[0045] Esse traço biométrico b pode ser de qualquer tipo de traço biométrico comumente utilizado, como dados biométricos relativos à íris, ao rosto, a uma impressão digital, etc...
[0046] No caso desse procedimento de arrolamento, o traço biométrico é, por outro lado, protegido, por meio de uma função criptográfica, pelo indivíduo Mi, a função criptográfica sendo, por exemplo, uma função do corte Hash.
[0047] O traço biométrico é também armazenado sobre o cartão 12 sob essa forma protegida
, que constitui o primeiro elemento de uma chave de assinatura de grupo 
.
[0048] Nesse caso, o cartão pessoal 12 do indivíduo Mi pode também memorizar os dois outros elementos de uma chave de assinatura de grupo: I
e , escolhida aleatoriamente pelo gestor no caso da primeira identidade e gerado da forma descrita abaixo no caso de identidades derivadas; 
, gerados pelo gestor GM0 a partir de um parâmetro secreto msk de Y° grupo, do elemento 
do dado biométrico protegido 
. A geração desse elemento é descrita mais em detalhes nos artigos relativos às assinaturas de grupos mencionados antes.
[0049] A chave secreta total que permite autenticar o indivíduo Mi é então uma chave de assinatura de grupo ;
. Nesse exemplo, a chave de assinatura é obtida por meio de elementos biométricos. Outras utilizações são f0 possíveis, por exemplo, escolhendo 
aleatoriamente.
[0050] O cartão pessoal 12 do indivíduo Mi pode, portanto, conter os dados b,
, assim como eventualmente a parte protegida 
do dado biométrico. Autenticação
[0051] O processo de autenticação é ilustrado esquematicamente na figura 3b. Para proceder à autenticação do indivíduo Mi junto a um fornecedor de serviço SP, um dispositivo de controle 21 procede à aquisição de um traço biométrico b’ do indivíduo, lê o traço biométrico de armazenado sobre o cartão, e compara os dois traços biométricos.
[0052] Para isso, o dispositivo de controle 21 é, por exemplo, um dispositivo munido de um captador de dados biométricos e de um leitor do dispositivo de armazenamento pessoal 12 (por exemplo, leitor de cartão com chips), que não estão representados na figura.
[0053] Alternativamente, o dispositivo 21 só compreende uma leitora do dispositivo de armazenamento pessoal 12, a aquisição e a comparação tendo ocorrido no dispositivo de armazenamento pessoal 12.
[0054] Se os dois traços b e b' corresponderem, o dispositivo de controle 21 (ou o dispositivo de armazenamento 12) aplicará ao traço biométrico b a função de corte Hash que ele detém, para se obter o dado
.
[0055] Alternativamente, se o dado
for armazenado no cartão pessoal 12, a leitora poderá proceder à aquisição deste.
[0056] Enfim, se esse processo de autenticação prever a utilização das assinaturas de grupo, o fornecedor de serviços SP poderá enviar uma mensagem m ao dispositivo de controle 21, que responde, transmitindo uma assinatura sobre essa mensagem. Essa assinatura pode ser gerada pelo dispositivo de controle que constitui a leitora 21 ou pelo cartão 12, utilizando o algoritmo Sign, com a chave secreta armazenada no cartão do indivíduo Mi. Enfim, um algoritmo de verificação Verify, tendo por entrada a assinatura da mensagem e a lista de revogação do domínio associado é utilizado pelo fornecedor de serviço para verificar se a assinatura é válida. A validade dessa verificação assegura que o indivíduo associado não é revogado do domínio da identidade referida.
[0057] Esse princípio de autenticação é também descrito no FR 2 925 732. Ele se baseia nos algoritmos de assinatura de grupo (dos quais Sign e Verify) descritos nos artigos citados em introdução do presente texto.
[0058] A assinatura é transmitida ao servidor do fornecedor de serviço é tal que a informação assim transmitida é anônima para qualquer entidade com exceção do indivíduo que se autentica e do servidor de gestão do domínio (grupo) ao qual pertence o indivíduo.
[0059] Descreve-se a seguir o processo de derivações de identidades com referência às figuras 4 e 5.
[0060] Na sequência, considera-se o exemplo de um indivíduo Mi, detendo uma identidade nacional IO, assim como conjunto das identidades lk necessário à obtenção de uma identidade li, e deixando obter a identidade li, por exemplo, “segurança de veículo”. Representaram-se, a título de exemplo, na figura 4, duas identidades lk1 e lk2, cada uma sendo gerada por um servidor ou gestor de grupo respectivo GMk1 e GMk2.
[0061] Quando o indivíduo Mi deseja adquirir uma identidade li, ele aciona um processo de arrolamento 100.
[0062] No decorrer de uma etapa 110, o gestor de grupo GMi envia uma mensagem m de solicitação ao indivíduo Mi, assim como uma função de derivação Hi própria à identidade li. Essa função pode ser pública.
[0063] Em resposta a essa solicitação, o indivíduo assina a mensagem m de solicitação por meio de sua chave de assinatura secreta (Copiar fórmula da página 12 do original), que é possivelmente uma chave de assinatura de grupo e isto para todos os domínios de identidade k necessários à obtenção de dados de identidade no domínio li.
[0064] Essa etapa retoma a fase de autenticação descrita anteriormente com, como fornecedor de serviço requerendo as identidades do domínio lk, o servidor de gestão do gestor do domínio li.
[0065] No decorrer dessa etapa, o indivíduo envia, além disso, uma assinatura de grupo para cada identidade lk, seus tokens ditos de derivação
calculados a partir de cada um dos tokens de revogação 
associados aos lk (que o indivíduo encontra a partir de sua chave secreta) e da função de derivação Hi associada a li.
[0066] Da mesma forma que, no caso da autenticação, os cálculos e trocas são efetuados pelo dispositivo de controle 21 e/ou o cartão 12.
[0067] A utilização da função de derivação Hi garante a confidencialidade dos tokens de revogação
.
[0068] De preferência, essa função Hi é uma função dita de sentido único. Isto significa que não é possível encontrar o antecedente de um sinal codificado pela função e, portanto, garantir que o token de revogação ni seja conhecido apenas do indivíduo Mi do gestor de identidades GMk. Ela pode, por exemplo, ser definida por
na qual Hi é um gerador de um grupo, no sentido algébrico do termo, no qual o programa do logaritmo discreto é difícil.
[0069] A assinatura é, além disso, construída de modo a se assegurar da legitimidade dos tokens de derivação, notadamente assegurando-se da possibilidade de encontrar o link entre tokens ditos de derivação
e os tokens de revogação 
, o que permite a boa aplicação do processo de revogação em cascata descrito na sequência.
[0070] Isto pode, por exemplo, ser realizado com o esquema de Bringer et Petey que permite uma assinatura de grupo VLR (Verificar - Local de Revogação) possuindo a propriedade dita de retro-intraçabilidade ou “Backward-Unlinkability” (segundo a terminologia anglo-saxônica comumente utilizada pelo técnico).
[0071] Essa propriedade, em seu contexto de utilização habitual, implica que as autenticações sejam ligadas a períodos temporais. Assim, um indivíduo pode ser revogado em certos períodos, mas não aos outros, utilizando sempre as mesmas chaves de assinatura.
[0072] Nesse caso particular, os tokens de revogação de cada período são análogos aos tokens de derivação mencionados acima, isto é, existe uma função de sentido único Hi para cada período e que o token de revogação de um indivíduo Mi para o período l é igual a
no qual rti é seu token de revogação global. O conhecimento de token de revogação periódica não permite o conhecimento do token de revogação global. É também impossível saber se dois tokens periódicos para dois períodos diferentes são provenientes do mesmo token de revogação global, sem o conhecimento deste.
[0073] A utilização de uma assinatura do grupo com “backward-unlinkalibity” permite verificar facilmente que o token de derivação é bem associado à assinatura.
[0074] Assim, quando do tratamento de geração de uma nova identidade, o indivíduo vai assinar com sua chave
para um período i fictício associado à função Hi. O token de derivação 
é então o token de revogação periódica para o período fictício l.
[0075] As autenticações utilizadas nos outros casos, e notadamente as autenticações junto aos fornecedores de serviço outros que o gestor de identidade não exploram essa propriedade.
[0076] Para verificar a validade do token de derivação
, o gestor do domínio utiliza, portanto, o teste de revogação associado ao período fictício i com a assinatura o e o token de derivação Hi. No exemplo da assinatura de Bringer et Patey, e seguindo as anotações do artigo associado ele recupera os elementos B e L do o e verifica 
.
[0077] Se é bem o caso para cada um dos domínios parentes lk, o gestor pode passar à etapa seguinte de inscrição.
[0078] As assinaturas de grupo assim geradas permitem ao gestor de identidade GMi lançar a etapa 120 de verificação que o indivíduo Mi possui bem o conjunto das identidades Ik e que o token de derivação (Copiar fórmula da página 15 do original). enviado é bem ligado à assinatura recebida.
[0079] Para isto, o gestor de identidade GMi utiliza o algoritmo Verify citado anteriormente aumento de uma fase de verificação do link entre a assinatura e o token de derivação recebidos para cada uma das identidades Ik. Isto pode, por exemplo, ser realizado com o algoritmo Verify do esquema de Bringer et Patey.
[0080] O gestor de identidades GMi verifica também que o indivíduo Mi não foi revogado de nenhuma identidade Ik no decorrer de uma etapa 130, utilizando em parte o algoritmo Verify e as listas públicas de revogação RLk. Alternativamente, essa verificação pode ser inteiramente incluída na etapa 120.
[0081] Se as duas condições das etapas 120 e 130 forem verificadas, o gestor de identidade GMi pode crer em dados do domínio de identidade derivada Ii para o indivíduo Mi no decorrer de uma etapa 140 de inscrição.
[0082] Essa etapa é análoga ao processo descrito anteriormente com referência à figura 3a, com a diferença que o gestor de identidade não escolhe aleatoriamente o elemento
para o nível l, mas o desvio a partir dos tokens de derivação 
associados aos domínios Ik e Ii recebidos quando da etapa 110.
[0083] Por exemplo, pode ser obtido assim:
! 1 na qual mski é chave secreta do gestor de identidade 
[0084] Esse elemento
é, na realidade, a segunda parte da chave secreta do indivíduo Mi para o nível 
e a esse respeito é armazenado em um cartão de identificação 12 gerada para o indivíduo Mi. Ele é também armazenado na derivação DBi da identidade l além do conjunto dos tokens de derivação 
.
[0085] A primeira parte da chave secreta
é derivada de uma aquisição de um traço biométrico B do indivíduo Mi. Pode tratar-se de uma nova aquisição protegida b’, ou da forma protegida f de uma aquisição b já presente sobre o cartão de identificação do indivíduo para uma identidade parente.
[0086] A terceira parte da chave secreta,
, é gerada pelo servidor de gestão de identidade derivada GMi a partir do resto da chave e do segredo de grupo msk. O token de revogação 
o do indivíduo Mi para a identidade II é derivado dessa chave secreta; por exemplo, este pode ser o elemento 
.
[0087] Assim, posteriormente, se o indivíduo Mi desejar se autenticar, para o domínio Ii, junto a um fornecedor de serviço SPi, basta realizar o processo de autenticação já descrito anteriormente com referência à figura 3b por meio de sua sk1 chave secreta
.
[0088] Por conseguinte, o servidor de gestão do domínio de identidade derivada GMl gera para o indivíduo, em função das informações transmitidas, quando da autenticação, pelo menos uma parte de dados de identidade com as quais o indivíduo pode se autenticar junto a um fornecedor de serviço para o domínio de identidade derivada.
[0089] O servidor GMi memoriza, além disso, em uma derivação privada, o total ou parte das informações trocadas no decorrer do tratamento de autenticação (informação de derivação) para posteriormente, se for o caso, em função de informações de link transmitidas por um domínio parente (na ocorrência, os tokens de revogação) formar o link entre dados de identidade do domínio de identidade derivada e dados de identidade do domínio parente.
[0090] O tratamento de geração pelos diferentes servidores de identidade detalhado acima é, todavia, tal como nenhum link pode ser estabelecido a partir de duas autenticações em dois domínios distintos na ausência dessas informações de link.
[0091] Se o gestor de identidade GMi (gestor parente) desejar revogar o indivíduo, bastará que ele publique na lista de revogação pública RLi o token de revogação
(informação de revogação).
[0092] Assim, os servidores dos gestores de identidade GMm das identidades Im exatamente abaixo do nível l (gestores de identidade derivadas do domínio li) acumulam um processo 150 de revogação descendente (Downwards Revocation), o que permitem as informações de links entre diferentes níveis (tokens de revogação).
[0093] O token de revogação
é publicado em RLi. Assim cada gestor GMm de uma identidade Im aplica a função de derivação Hm a esse token ligeiramente rt^ Publicado 
. Se o resultado obtido for armazenado na base de dados DBm, isto significa que o indivíduo possui também uma identidade para o domínio Im; o gestor GMm encontra então a identidade associada a esse indivíduo para o nível m e publica o token de revogação 
associado no RLm. Esse processo é reiterado de forma recursiva nos níveis inferiores.
[0094] Ao contrário, graças às propriedades das funções de derivação Hi, as assinaturas para diferentes identidades não têm nenhum link entre elas. Em particular, para duas assinaturas realizadas para dois níveis diferentes, é impossível saber se elas teriam sido realizadas pelo mesmo indivíduo ou não. Em particular, em caso de revogação, uma assinatura permanece completamente anônima para os gestores de identidades não impactadas pela revogação.
[0095] Anotar-se-á, além disso, que a publicação das informações de revogação que constituem os tokens de revogação torna impossível a geração de dados de identidade derivada.
[0096] Opcionalmente, um processo 160 de “revogação ascendente” (Upwards Revocation”) é também possível, se um gestor de identidade de um nível l pensar que um gestor de identidade de um nível parente deveria também revogar o indivíduo Mi.
[0097] Nesse caso, o gestor de identidade GMi envia ao gestor de identidade GMk o token de derivação
obtido quando da fase 100. O gestor de identidade GMk pode então aplicar a função Hi ao conjunto dos tokens de revogação 
dos indivíduos Mi inscritos em sua base de dados privada DBk na qual são memorizadas para determinar qual dentre eles concorda com o token de derivação 
.
[0098] O gestor GMk tem então a possibilidade de revogar a identidade do indivíduo, se ele desejar.
[0099] Esse processo de gestão de identidades apresenta as propriedades interessantes de revogações descendente e ascendente, preservando o anonimato dos indivíduos.
[00100] É, além disso, compatível com a utilização de assinaturas de grupos VLR com “Backward Unlinkability” tais como nos artigos mencionados acima. Neste último caso, o processo de derivação, segundo a invenção, permite, além disso, verificar todas as propriedades de segurança requeridas: exatidão, traçabilidade, exculpabilidade (em Inglês exculpability), anonimato (selfless-anonymatly) que são também descritas em publicações.
[00101] Enfim, embora o exemplo descrito aqui utilize a construção de assinatura do grupo ensinada por Bringer et Patey no artigo mencionado na introdução, é, todavia, aplicável a qualquer assinatura de grupo VLR (Verificar - Local Revogação) possuindo a propriedade dita de “Backward Unlinkability” (de acordo com a terminologia anglo-saxônica comumente utilizada pelo técnico).
Claims (19)
1. Processo de gestão e de controle de diferentes dados de identidade de um indivíduo, esses dados correspondendo a vários domínios de identidades organizados em conjunto estruturado, no qual pelo menos um sistema de controle está apto a realizar para um domínio de identidade dado uma autenticação do indivíduo a partir dos dados de identidade associados a esse domínio para o indivíduo, no qual dados de identidade de um indivíduo para um domínio de identidade compreendem uma chave secreta do indivíduo e um token de revogação do indivíduo para dito domínio, em que um tratamento de autenticação do indivíduo se realiza para cada domínio de identidade parente por um servidor de gestão do domínio de identidade parente, a partir dos dados de identidade do indivíduo para o domínio parente, junto a um servidor de gestão do domínio de identidade derivada no decorrer do qual, - se transmite ao servidor de gestão do domínio de identidade derivada informações em função dos dados de identidade do domínio parente e pelo menos uma informação de prova de validade desses dados, - o servidor de gestão de identidade derivada autentica o indivíduo para o domínio parente e controla, por meio da informação de prova, a validade das informações transmitidas, em que, em função dos resultados de autenticação e de controle, - o servidor de gestão de identidade derivada gera pelo menos uma parte de dados de identidade com as quais o indivíduo pode se autenticar junto a um fornecedor de serviço para o domínio de identidade derivada, incluindo uma chave secreta e um token de revogação do indivíduo para o domínio de identidade derivada, - o dito servidor de gestão de identidade derivada memorizando informações de derivação, comportando o total ou parte das informações trocadas no decorrer do tratamento de autenticação para, posteriormente, se for o caso, em função de informações de link transmitidas por um domínio parente, fazer o link entre dados de identidade do domínio de identidade derivada e dados de identidade do domínio parente, o tratamento de geração pelos diferentes servidores de identidade sendo tal que nenhum link possa ser estabelecido a partir de duas autenticações em dois domínios distintos na ausência dessas informações de link, o método sendo caracterizado pelo fato de que o token de derivação
está em comunicação com o servidor de gestão de identidade derivada durante a autenticação do indivíduo para o domínio parente, o token de derivação sendo uma função do token de revogação 
para o domínio de identidade parente, e em que a chave secreta 
e o token de revogação 
para o domínio de identidade derivada são uma função do token de derivação 
.
2. Processo de gestão e de controle, de acordo com a reivindicação 1, caracterizado pelo fato de que, para a autenticação de um indivíduo junto a um fornecedor de serviço, para um domínio de identidade, se transmitem a esse fornecedor de serviço informações determinadas, em função dos dados de identidade do domínio, o tratamento realizado para essa determinação tornando a informação assim transmitida anônima para qualquer entidade, com exceção do servidor de gestão do domínio e do indivíduo que se autentica.
3. Processo de gestão e de controle, de acordo com qualquer uma das reivindicações 1 ou 2, caracterizado pelo fato de que os dados de identidade de um indivíduo comportarem dados biométricos do indivíduo e/ou dados obtidos por tratamento de dados biométricos.
4. Processo de gestão e de controle, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que cada servidor de gestão de domínio de identidade realiza um tratamento de revogação de indivíduo, que publica uma informação de revogação utilizada pelos fornecedores de serviço para impedir o indivíduo revogado de um domínio de se autenticar, utilizando os dados de identidade associados a esse domínio.
5. Processo de gestão de identidade, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de que, quando de um tratamento de revogação por um servidor de domínio parente, esse servidor transmite a cada servidor de gestão de identidade derivada informações de link associadas a um indivíduo revogado, essas informações sendo tratadas pelo dito servidor, a fim de realizar o tratamento de revogação do indivíduo, caso este possua dados de identidade para esse domínio de identidade derivada.
6. Processo de gestão e de controle, de acordo com a reivindicação 5, caracterizado pelo fato de que, quando de um tratamento de revogação por um servidor de domínio derivado, esse servidor transmite a um servidor de gestão de identidade parente escolhido informações de derivação associadas a um indivíduo revogado, essas informações sendo, se for o caso, tratadas pelo dito servidor, a fim de realizar o tratamento de revogação do indivíduo para esse domínio parente.
7. Processo, de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que o tratamento de autenticação junto a um fornecedor de serviço implementa um algoritmo de tipo assinatura de grupo, os dados de identidade de um domínio comportando uma chave de assinatura de grupo própria ao domínio.
8. Processo, de acordo com a reivindicação 4, caracterizado pelo fato de que cada domínio de identidade é associado a uma base de dados pública, contendo uma lista pública de revogação, o tratamento de revogação realizado por um servidor de gestão de domínio para revogar um indivíduo acrescentando à dita lista um token de revogação determinado pelo dito servidor a partir dos dados de identidade do indivíduo, esse token de revogação servindo de informação de revogação utilizada pelos fornecedores de serviço para impedir esse indivíduo revocado de se autenticar, utilizando os dados de identidade associados a esse domínio.
9. Processo, de acordo com qualquer uma das reivindicações 5 e 8, caracterizado pelo fato de que informações de link transmitidas a cada servidor de identidade derivada compreendem o token de revogação do indivíduo para o domínio de identidade parente.
10. Processo, de acordo com a reivindicação 1, caracterizado pelo fato de que as informações de derivação são calculadas a partir das informações de link associadas ao indivíduo, com o auxílio de uma função dita de sentido único associada ao domínio de identidade derivada.
11. Processo, de acordo com a reivindicação 1, caracterizado pelo fato de que o servidor de gestão do domínio de identidade derivada, - calcula, quando do tratamento de geração de novos dados de identidade, os dados de identidade a partir das informações de derivação para cada um dos domínios de identidade parentes e, - memoriza em uma base de dados privada ao mesmo tempo as informações de derivação e os novos dados de identidade de forma a poder encontrar esses dados a partir de uma informação de derivação.
12. Processo, de acordo com qualquer as reivindicações 5, 10 e 11, caracterizado pelo fato de que, quando de um tratamento de revogação de um indivíduo, o servidor de gestão do domínio de identidade parente transmite as informações de link, o servidor de gestão do domínio de identidade derivado calculando as informações de derivação a partir das informações de link assim transmitidas, de forma a poder encontrar os dados de identidade associados caso o indivíduo possua uma identidade para o domínio de identidade derivada e assim revogar o indivíduo associado.
13. Processo, de acordo com a reivindicação 7, caracterizado pelo fato de que a assinatura de grupo utilizada é do tipo VLR com “Backward unlinkability”, segundo a terminologia anglo-saxônica comumente utilizada.
14. Processo, de acordo com a reivindicação 13, caracterizado pelo fato de que os diferentes domínios de identidade são associados, de forma única, aos diferentes períodos temporais do tratamento de assinatura do grupo de tal forma que: - as funções de sentido único associadas aos diferentes domínios de identidade sejam as funções de sentido único associadas aos períodos temporais da assinatura de grupo associada, e - a autenticação realizada, quando do tratamento de geração de uma nova identidade, utilize a assinatura de grupo associada, com o período temporal associado ao domínio de identidade derivado, a assinatura de grupo servindo também de informação de prova de validade dos dados, as autenticações realizadas nos outros casos de utilização não explorando a propriedade de “Backward- Unlinkability”.
15. Processo, de acordo com qualquer uma das reivindicações 1 a 14, caracterizado pelo fato de que os dados de identidade gerados pelo servidor de identidade derivada são armazenados sobre um suporte portátil pessoal que se remete ao indivíduo.
16. Processo, de acordo com a reivindicação 15, caracterizado pelo fato de que o sistema de controle comporta também uma leitora adaptada para a leitura dos dados de identidade armazenados sobre um suporte portátil a leitora e/ou o suporte portátil comportando meios de tratamento para a geração das autenticações e/ou para a comparação de dados biométricos.
17. Processo, de acordo com uma das reivindicações 15 ou 16, caracterizado pelo fato de que a leitora e/ou o cartão integram meios de leitora de traços biométricos sobre o indivíduo.
18. Processo, de acordo com a reivindicação 3, caracterizado pelo fato de que os dados de identidade de um domínio de identidade derivada comportam, para um indivíduo, um dado correspondente a um traço biométrico do indivíduo adquirido quando do tratamento de autenticação realizado para a geração de dados de identidade do indivíduo nesse domínio de identidade derivada, e/ou retomada da aquisição feita quando do tratamento de autenticação realizado para a geração de dados de identidade do indivíduo em um domínio de identidade parente.
19. Sistema de gestão e de controle de dados de identidade de um indivíduo, esses dados correspondendo a vários domínios de identidade organizados em conjunto estruturado, o dito sistema comportando pelo menos um servidor de gestão de domínio de identidade derivada e pelo menos servidor de gestão de domínio de identidade parente, em que um indivíduo possui, para cada domínio de identidade, um dispositivo pessoal de identificação comportando uma memória na qual são armazenados dados associados a esse domínio para o indivíduo, em que os dados de identidade armazenados de um indivíduo para um domínio de identidade compreendem uma chave secreta do indivíduo e um token de revogação do indivíduo para dito domínio, essa memória estando apta a ser lida por um dispositivo de controle, caracterizado pelo fato de que o sistema compreende ainda meios de transmissão de informações função dos dados de identidade do domínio parente e pelo menos uma informação de prova para provar validade desses dados, o servidor de gestão do domínio de identidade derivada comportando meios de tratamento aptos a: • autenticar um indivíduo para o domínio parente com base em um token de derivação
o token de derivação sendo uma função do token de revogação 
para o domínio de identidade parente; • controlar, por meio da informação de prova, a validade das informações em função dos dados de identidade do domínio parente; e • em função dos resultados de autenticação e de controle, gerar para o indivíduo, em função das informações transmitidas, pelo menos uma parte de dados de identidade com os quais o indivíduo pode se autenticar junto a um fornecedor de serviço para o domínio de identidade derivada, incluindo uma a chave secreta 
para o domínio de identidade derivada e um token de revogação 
para o domínio de identidade derivada que são uma função do token de derivação 
o dito servidor de gestão de identidade derivada comportando uma base de dados memorizando informações de derivação que comportam o total ou parte das informações trocadas no decorrer do tratamento de autenticação para posteriormente, se for o caso, em função de informações de link transmitidas por um domínio parente, fazer o link entre dados de identidade do domínio de identidade derivada e dados de identidade do domínio parente, o tratamento de geração pelos diferentes servidores de identidade sendo tal que nenhum link possa ser estabelecido a partir de duas autenticações em dois domínios distintos na ausência destas informações de link.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1157261 | 2011-08-09 | ||
| FR1157261A FR2979044B1 (fr) | 2011-08-09 | 2011-08-09 | Procede de gestion et de controle de donnees de differents domaines d'identite organises en ensemble structure |
| PCT/EP2012/065153 WO2013020890A1 (fr) | 2011-08-09 | 2012-08-02 | Procede de gestion et de controle de donnees de differents domaines d'identite organises en ensemble structure |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| BR112014003054A2 BR112014003054A2 (pt) | 2017-02-21 |
| BR112014003054B1 true BR112014003054B1 (pt) | 2022-04-12 |
Family
ID=46639494
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BR112014003054-5A BR112014003054B1 (pt) | 2011-08-09 | 2012-08-02 | Processo de gestão e de controle de diferentes dados de identidade de um indivíduo, e, sistema de gestão e de controle de dados de identidade de um indivíduo |
Country Status (11)
| Country | Link |
|---|---|
| US (1) | US9407637B2 (pt) |
| EP (1) | EP2742645B1 (pt) |
| JP (2) | JP2014529124A (pt) |
| CN (1) | CN103858377B (pt) |
| AU (1) | AU2012293712B2 (pt) |
| BR (1) | BR112014003054B1 (pt) |
| CA (1) | CA2844762C (pt) |
| FR (1) | FR2979044B1 (pt) |
| IL (1) | IL230870A (pt) |
| RU (1) | RU2602785C2 (pt) |
| WO (1) | WO2013020890A1 (pt) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3005185B1 (fr) * | 2013-04-30 | 2015-04-17 | Morpho | Procede pour generer au moins une identite derivee |
| CN107251477B (zh) * | 2015-02-11 | 2021-01-12 | 维萨国际服务协会 | 用于安全地管理生物计量数据的系统和方法 |
| US10069824B2 (en) * | 2015-05-12 | 2018-09-04 | Branch Banking And Trust Company | Biometric signature authentication and centralized storage system |
| RU2739262C1 (ru) * | 2020-04-05 | 2020-12-23 | Эрвью.ТВ, Инк. | Способ управления предъявлением информации |
| US11824896B2 (en) | 2020-04-06 | 2023-11-21 | Exonym GmbH | Cross-service rulebook management in a dynamic and adversarial environment |
| US11962573B2 (en) | 2021-10-26 | 2024-04-16 | Genetec Inc | System and method for providing access to secured content field |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1164745A3 (en) * | 2000-06-09 | 2005-03-30 | Northrop Grumman Corporation | System and method for usage of a role certificate in encryption, and as a seal, digital stamp, and a signature |
| US7028180B1 (en) * | 2000-06-09 | 2006-04-11 | Northrop Grumman Corporation | System and method for usage of a role certificate in encryption and as a seal, digital stamp, and signature |
| US6993596B2 (en) * | 2001-12-19 | 2006-01-31 | International Business Machines Corporation | System and method for user enrollment in an e-community |
| FR2834598B1 (fr) * | 2002-01-04 | 2004-02-20 | France Telecom | Procede et dispositif de signature anonyme au moyen d'une cle privee partagee |
| WO2003104947A2 (en) * | 2002-06-06 | 2003-12-18 | Hardt Dick C | Distributed hierarchical identity management |
| CN1961270A (zh) * | 2004-05-28 | 2007-05-09 | 皇家飞利浦电子股份有限公司 | 保密信息分配系统中的许可证管理 |
| US7315941B2 (en) * | 2004-12-17 | 2008-01-01 | Ntt Docomo Inc. | Multi-certificate revocation using encrypted proof data for proving certificate's validity or invalidity |
| JP4727353B2 (ja) * | 2005-09-06 | 2011-07-20 | 株式会社Ｋｄｄｉ研究所 | 識別情報生成管理装置およびシステムならびにプログラム |
| CN101039182B (zh) * | 2007-03-07 | 2010-08-11 | 广东南方信息安全产业基地有限公司 | 基于标识的公钥密码认证系统及标识证书发放方法 |
| KR100962399B1 (ko) * | 2007-08-24 | 2010-06-11 | 한국전자통신연구원 | 익명 공개 키 기반구조 제공 방법 및 이를 이용한 서비스제공 방법 |
| FR2925732B1 (fr) * | 2007-12-21 | 2010-02-12 | Sagem Securite | Generation et utilisation d'une cle biometrique |
| CN101272395B (zh) * | 2008-05-20 | 2012-07-11 | 北京交通大学 | 一种通信网络的层次接入控制方法 |
| US20100122080A1 (en) * | 2008-11-11 | 2010-05-13 | Electronics And Telecommunications Research Institute | Pseudonym certificate process system by splitting authority |
| EP2359576B1 (en) * | 2008-11-20 | 2017-12-27 | Mark Kevin Shull | Domain based authentication scheme |
-
2011
- 2011-08-09 FR FR1157261A patent/FR2979044B1/fr active Active
-
2012
- 2012-08-02 AU AU2012293712A patent/AU2012293712B2/en active Active
- 2012-08-02 CN CN201280044555.5A patent/CN103858377B/zh active Active
- 2012-08-02 WO PCT/EP2012/065153 patent/WO2013020890A1/fr active Application Filing
- 2012-08-02 RU RU2014106962/08A patent/RU2602785C2/ru active
- 2012-08-02 CA CA2844762A patent/CA2844762C/fr active Active
- 2012-08-02 BR BR112014003054-5A patent/BR112014003054B1/pt active IP Right Grant
- 2012-08-02 JP JP2014524342A patent/JP2014529124A/ja active Pending
- 2012-08-02 US US14/237,556 patent/US9407637B2/en active Active
- 2012-08-02 EP EP12743968.5A patent/EP2742645B1/fr active Active
-
2014
- 2014-02-06 IL IL230870A patent/IL230870A/en active IP Right Grant
-
2018
- 2018-03-28 JP JP2018062496A patent/JP6688823B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| FR2979044A1 (fr) | 2013-02-15 |
| IL230870A (en) | 2017-09-28 |
| CA2844762C (fr) | 2020-07-28 |
| AU2012293712B2 (en) | 2016-07-21 |
| JP2018137788A (ja) | 2018-08-30 |
| JP2014529124A (ja) | 2014-10-30 |
| RU2014106962A (ru) | 2015-09-20 |
| CA2844762A1 (fr) | 2013-02-14 |
| WO2013020890A1 (fr) | 2013-02-14 |
| EP2742645B1 (fr) | 2018-10-03 |
| US9407637B2 (en) | 2016-08-02 |
| CN103858377A (zh) | 2014-06-11 |
| BR112014003054A2 (pt) | 2017-02-21 |
| FR2979044B1 (fr) | 2013-08-30 |
| US20140181932A1 (en) | 2014-06-26 |
| AU2012293712A1 (en) | 2014-03-27 |
| IL230870A0 (en) | 2014-03-31 |
| JP6688823B2 (ja) | 2020-04-28 |
| EP2742645A1 (fr) | 2014-06-18 |
| RU2602785C2 (ru) | 2016-11-20 |
| CN103858377B (zh) | 2017-02-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11329981B2 (en) | Issuing, storing and verifying a rich credential | |
| US10476879B2 (en) | Blockchain authentication via hard/soft token verification | |
| Leiding et al. | Authcoin: validation and authentication in decentralized networks | |
| US7694330B2 (en) | Personal authentication device and system and method thereof | |
| Burr et al. | Electronic authentication guideline | |
| US7590861B2 (en) | Methods for secure enrollment and backup of personal identity credentials into electronic devices | |
| US8359475B2 (en) | System, method and program product for generating a cancelable biometric reference template on demand | |
| BR112014003054B1 (pt) | Processo de gestão e de controle de diferentes dados de identidade de um indivíduo, e, sistema de gestão e de controle de dados de identidade de um indivíduo | |
| US20090037729A1 (en) | Authentication factors with public-key infrastructure | |
| US9350538B2 (en) | Revocation status using other credentials | |
| Abraham et al. | Revocable and offline-verifiable self-sovereign identities | |
| Yildiz et al. | Towards Interoperable Self-sovereign Identities | |
| US11082236B2 (en) | Method for providing secure digital signatures | |
| Alrodhan et al. | Enhancing user authentication in claim-based identity management | |
| JP2013122680A (ja) | 生体認証システム | |
| Burr et al. | Sp 800-63-1. electronic authentication guideline | |
| Hasan et al. | Interaction provenance model for unified authentication factors in service oriented computing | |
| Albahdal et al. | Trusted BWI: Privacy and trust enhanced biometric web identities | |
| Knutsen et al. | Anonymous tokens–implementation and development | |
| Wankhede et al. | The Decentralized Smart Contract Certificate System Utilizing Ethereum Blockchain Technology | |
| Pärni | On Self-Sovereign Identity: Verifiable Credentials and Presentations with OpenID Connect | |
| Klingelbrunner | Datenschutz in SSI Systemen basierend auf Hyperledger Technologie | |
| Mühle et al. | Computer Science Review | |
| Albahdal | Toward secure, trusted, and privacy-enhanced biometrics in the cloud | |
| Garg | Decentralized Access Control: Overview |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B06F | Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette] | ||
| B06U | Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette] | ||
| B09A | Decision: intention to grant [chapter 9.1 patent gazette] | ||
| B16A | Patent or certificate of addition of invention granted [chapter 16.1 patent gazette] |
Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 02/08/2012, OBSERVADAS AS CONDICOES LEGAIS. |
|
| B25G | Requested change of headquarter approved |
Owner name: MORPHO (FR) |
|
| B25D | Requested change of name of applicant approved |
Owner name: SAFRAN IDENTITY AND SECURITY (FR) |
|
| B25D | Requested change of name of applicant approved |
Owner name: IDEMIA IDENTITY AND SECURITY FRANCE (FR) |