WO2023233173A1 - Mise en œuvre d'une identité auto-souveraine (ssi) sur la base de profils individuels configurables générés en temps réel à partir d'attributs privés stockés dans les éléments sécurisés personnels des utilisateurs - Google Patents

Mise en œuvre d'une identité auto-souveraine (ssi) sur la base de profils individuels configurables générés en temps réel à partir d'attributs privés stockés dans les éléments sécurisés personnels des utilisateurs Download PDF

Info

Publication number
WO2023233173A1
WO2023233173A1 PCT/HU2023/050023 HU2023050023W WO2023233173A1 WO 2023233173 A1 WO2023233173 A1 WO 2023233173A1 HU 2023050023 W HU2023050023 W HU 2023050023W WO 2023233173 A1 WO2023233173 A1 WO 2023233173A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic wallet
card
secure electronic
communication device
secure
Prior art date
Application number
PCT/HU2023/050023
Other languages
English (en)
Inventor
András VILMOS
Original Assignee
Safepay Systems Kft.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Safepay Systems Kft. filed Critical Safepay Systems Kft.
Publication of WO2023233173A1 publication Critical patent/WO2023233173A1/fr

Links

Classifications

    • 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/33—User authentication using certificates
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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
    • 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/3271—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 challenge-response
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys

Definitions

  • the present disclosure relates to a method of generating a digitally signed, special purpose ID card in the ID card holder’s secure wallet for the purpose of sharing the least amount of necessary user specific information with an external third party who wishes to identify the ID card holder.
  • Identity related data also called attribute
  • It may be biometric, like one’s gender, fingerprint, heights, weight; it may be social like name, date and place of birth, citizenship, marital status, address, education; it may be official like ID number of national ID card, passport or driving license.
  • Other forms of less formal or more specific attributes may also have relevance in certain situations like, employment relationships, health status, family ties, circle of friends, etc.
  • attributes For example that the user has the right to vote in an election or that he/she is old enough to purchase alcohol (like in the above example), the user can then simply present the appropriate attribute(s).
  • These attributes must be verifiable by some kind of cryptographic tool to be able to serve their purpose.
  • the other key condition of SSI is the users' ability and obligation to securely store their own personal attributes. This capability allows full control of the users to access their data, without being concerned that such access may be withdrawn or be made conditional, as well as assures the protection of sensitive personal information.
  • DIDs decentralized identifiers
  • SSI is still in its early phase, but it already has a large amount of literature.
  • most solutions and concepts are based on blockchain technology.
  • Such an architecture is described by the European Commission in its document “EIDAS SUPPORTED SELF-SOVEREIGN IDENTITY” in which decentralized identifiers (DIDs) are used as verifiable self-sovereign digital identity.
  • DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority.
  • DIDs are URLs that relate a DID subject to means for trustable interactions with that subject.
  • DIDs resolve to DID Documents — simple documents that describe how to use that specific DID.
  • Each DID Document may contain at least three things: proof purposes, verification methods, and service endpoints. Proof purposes are combined with verification methods to provide mechanisms for proving things. As DIDs are just identifiers, they do not provide information about the subject itself. In practice, DIDs are used in combination with Verifiable Claims (VC) to support digital interactions in which information about the subject must be shared with third parties, by proving to those third parties that the DID subject has ownership of certain attestations or attributes. This proof is based on the cryptographic link between the VC, the DID subject of whom the VC is about, and the issuer of the VC. Trust on the issuer is established either by trusting the issuer’s DID (e.g.
  • the third party can then use the presented cryptographically protected proof to verify the ownership and trustworthiness of the claims about the subject.
  • the presentation of the claims is managed totally by the users, they can decide on which specific pieces of information they want to share with third parties about themselves; by means of this selective disclosure of attributes privacy and personal data protection is reinforced.
  • DID and VC organisations working on Self-Sovereign Identity are relying on the use of Distributed Ledgers I Blockchains to support the registry of identifiers.
  • Blockchain essentially provides a decentralized domain which is not controlled by any single entity. Data stored in any blockchain is readily available (availability property) to any authorized entity (access property). An owner of a particular data (an identity data such as Personally Identifiable Information or PH) has full control over it and dictates how such data can be shared with other users within the blockchain domain, thereby satisfying the disclosure property.
  • identity data such as Personally Identifiable Information or PH
  • a blockchain system can support a few additional advantages in terms of data immutability, provenance, distributed control, accountability and transparency.
  • the document also illustrates three envisioned flows leveraging blockchain technology for a self-sovereign identity.
  • uPort and Jolocom are decentralized identity systems built on top of Ethereum platform. They both consist of a mobile App and several Ethereum smart contracts including a public registry of uPort identity.
  • a user utilizes the respective mobile App to create, update and share identity information with other users. In the backend, such data is controlled by different smart contracts.
  • the bulk of identity data is stored on a distributed file system, whereas the mobile App is used to store the corresponding private key of a uPort identity.
  • Sovrin Identity system utilizes its own blockchain called Sovrin ledger that leverages a novel consensus algorithm called Plenum.
  • a user can utilize a mobile App or a web site which acts as a Sovrin client to interact with the ledger in order to create, update, manage and share their identity data.
  • Sovrin also supports the notion of Agents which can act as a Trusted Third Party to vouch or certify for identity data of a user. Sovrin enables users to exercise control in a way so that they can choose exact the data they want to share with someone else.
  • IDs are typically stored in physical wallets. It keeps them all in one place, protects them, and makes them easy to carry around.
  • a digital wallet has the same purpose and must have the same features as well.
  • Mobile wallets may be built into the operating system of smartphones or other communication devices or may even be dedicated hardware wallets with some communication interface to facilitate online connection for them. Wallets may further be server-side or client-side depending on the actual architecture of the system.
  • FIDO Flust ID Online
  • PKI Public Key Infrastructure
  • the user has a special cryptographic token and with this token the user may generate PKI keypair(s).
  • PKI Public Key Infrastructure
  • the user Upon registration to a third-party online service, the user generates a new keypair and sends it to the service provider.
  • the user later wishes to access the service it receives a challenge from the site which it needs to sign with the private key of the keypair stored in the crypto token.
  • the signed challenge is then returned to the service provider who can verify it with the public key it received from the user upon registration.
  • this technology provides complete independence from third parties, it can only be used for user authentication and not for user identification. The difference being that while in an authorisation it is possible to verify that the user is really the one who they claim to be, however in absence of any further personal data it is not possible to establish their real identity or any of their individual attributes.
  • the present disclosure describes such a technology and method which overcomes the problems associated with the prior art by using a user side secure wallet which is able to generate pseudo, one-time ID cards, containing any selection of attributes the digital wallet contains.
  • the ID holder has the capability to select any attribute or define the property of any attributes contained in their ID card and only present this information for identification purposes.
  • the solution can be implemented by using a secure chip card or similar secure element, which can provide the legally required security protection for the personal information.
  • the ID holder may define the information needed on a communication device, which may be a mobile phone, a tablet, a laptop or any similar device which comprises at least a user interface for data selection and data presentation, one or multiple processors, data storage, communication interface with the secure element (chip card) and preferably also some remote or proximity communication interface to allow sharing the desired information as well as an application (software program) which supports the expected functionality.
  • the ID holder selects the attributes it wants to provide or share with the identifying party by either selecting the specific data (e.g., age) or property of a specific data (e.g., older than 18).
  • this information is transferred to the secure element (e.g., chip card) which prepares a special purpose ID card for the specific identification transaction. This way, the holder of ID card shares only the information they are comfortable with and still satisfy the identification requirements.
  • a method for dynamically generating a special purpose electronic ID card containing selected user attributes comprising:
  • the communication device then transfers the signed dataset to a remote party over the internet to allow identification of the ID card holder, or exchanges this information through a proximity interface, like NFC or simply presents it on its display for visual verification.
  • the signed data group is shared with external parties together with a PKI certificate which allows verification of the digital signature of the data group.
  • the data received in the secure wallet and related to an attribute is a relational information, or statement which is true in respect of a specific attribute in which case the signed data group contains confirmation of the relation or statement, (e.g., older than a specific age, without sharing exact birth information or exact age of the ID holder.)
  • the data received in the secure wallet identifying at least one attribute stored in the secure wallet is initiated by the external party who will assess the adequacy of the user’s attribute.
  • a time stamp is also included in the signed data group.
  • user authentication data is first stored in the secure wallet and the user needs to authenticate itself with the secure wallet before the special purpose electronic ID card may be generated and signed in the secure wallet.
  • the secure wallet may store attributes related to multiple ID cards which may be controlled by the same or different business application(s) running on the communication device.
  • multiple signed datasets may be returned to the user communication device, attributes of which may be stored separately in the secure wallet.
  • the asymmetric key pair is generated in the secure wallet.
  • the private key of the asymmetric key pair is generated and loaded into the secure wallet by, or on behalf of the issuer of the original ID card which is virtualized for the user.
  • the secure wallet may also store information related to the issuer of the ID card, or about the unique specifics of the ID card itself which are also selectable and may be included in the data group to be signed.
  • the present disclosure also relates to a secure wallet, including at least one processor configured to perform some or all of the method steps disclosed herein.
  • the present disclosure also relates to a mobile device or a computing device, including at least one processor configured to perform all or some of the method steps disclosed herein.
  • the present disclosure also relates to one or more non-transitory computer readable mediums having stored thereon instructions or a program that, when executed by at least one processor, cause the at least one processor to perform the steps of the method disclosed herein.
  • the secure wallet may be an embedded secure element in the communication device, or a removable card (e.g., SIM card, SD card) of the communication device, or an external smart card connectable to the communication device, or a software application (e.g., Trusted Execution Environment) of the communication device, or a secure storage facility connected to a remote server, or similar.
  • the secure electronic wallet may also contain the necessary application(s) to carry out its functions.
  • user attributes may be any type of user related information (biometric, social, official, other - see above). Attributes may also refer to the ID card itself or its issuer.
  • a special purpose electronic ID card is any type of electronic code, official or informal, which carries any information about the person the document is related to.
  • Fig. 1 a is a schematic block diagram of an exemplary embodiment of a system suitable for carrying out the method according to various embodiments.
  • Fig. 1 b is another schematic block diagram of an exemplary embodiment of a system using a secure wallet connected to a remote server.
  • Fig. 2a is a more detailed block diagram of certain elements of Fig. 1 a.
  • Fig. 2b is a more detailed block diagram of certain elements of Fig. 1 b.
  • Figs. 3a and 3b are flow diagrams illustrating the steps of an exemplary embodiment according to various embodiments.
  • the exemplary embodiment illustrated in Fig. 1 a comprises a communication device 10 and a secure electronic wallet 20, which in this implementation is directly connected to the communication device 10, and an asymmetric cryptography key pair 50 consisting of a private key 50a and a public key 50b.
  • the asymmetric cryptography infrastructure may be based on any kind of cryptographic algorithms, including postquantum cryptographic algorithms as well.
  • the embodiment shown in Fig. 1 b differs from Fig. 1 a in that the secure electronic wallet 20 is directly connected to a remote computer 80, which is connected to the communication device 10 via an electronic communication channel 60, preferably over the Internet 62.
  • the communication device 10 may be a mobile phone 10a having a processor 11 , a data storage 12, a communication unit 13, and a touch screen (display) 15.
  • the communication device 10 has a secure wallet interface 14 (see Fig. 2a) or, if the secure electronic wallet 20 is placed on a remote computer, such as a remote server 80, such a secure wallet interface 84 is located on the remote server 80 (see Fig. 2b).
  • a secure wallet interface 14 see Fig. 2a
  • a secure wallet interface 84 is located on the remote server 80 (see Fig. 2b).
  • Other type of communication devices than mobile phones could be used as well, such as a tablet, laptop, smart watch, etc. These devices have similar structure or may also have additional components like other type of input interface 16 (e.g. keyboard, mouse, etc.).
  • a program 12a for identifying the at least one attribute/attribute property which should be presented in the special purpose ID card may be stored in the data storage 12 of the communication device (mobile phone) 10.
  • the secure electronic wallet 20 may be a smart card 20a, which is shown in Fig. 2a and Fig. 2b. It may comprise a processor 21 , a storage unit 22 and a communication interface 23 (such as a Global Platform standard JAVA card) and a software application 28.
  • the communication device 10 communicates with the smart card 20a over the smart card interface 14 (see Fig. 2a).
  • the communication between the communication device 10 and the secure electronic wallet 20 in case the smart card 20a is placed on a remote computer (e.g., server 80) is performed by using the communication interface 13 of the communication device 10 over the Internet-based electronic communication channel 60 between the communication device 10 and the remote server 80 and the remote server 80 comprises the smart card interface 84.
  • a remote computer e.g., server 80
  • the private key 50a is stored in the secure storage 22 of the electronic wallet 20.
  • user authentication data 24 and user attributes 25 are also stored in the secure storage 22 of the electronic wallet 20.
  • Other types of secure electronic wallets 20 are also conceivable as will be apparent to a skilled person, for example an embedded secure element in the communication device 10, a removable card (e.g. SIM card, SD card) of the communication device 10, an external smart card connectable to the communication device 10, a software application (e.g. Trusted Execution Environment) of the communication device 10, or a secure electronic wallet in a cloud connected to a remote server.
  • a public key certificate 50b’ generated from the public key 50b of the asymmetric cryptography key pair 50 is preferably stored in the data storage 12 of the communication device 10 as illustrated in Fig. 2a and Fig.2b.
  • Figs. 1 b, 2b show the particular embodiment in which the secure electronic wallet 20 is not directly connected to the communication device 10 but is connected to a remote computer, e.g., a server 80, which communicates with the communication device 10 using the Internet 62 via the electronic communication channel 60.
  • the communication device 10 accesses the secure electronic wallet 20 through the remote server 80, during which the remote server 80 may be a simple proxy but may also play an active role in message exchange.
  • the server 80 receives the message of the communication device 10 at the communication interface 83 suitable for remote communication, and then transfers it to the secure electronic wallet 20 via the smart card interface 84.
  • the method according to various embodiments is illustrated in Figs. 3a and 3b as performed with the system schematically depicted in Figs. 1 a, 1 b as follows. It will be appreciated that the order of some of the steps may differ from the order presented here.
  • the user has a secure electronic wallet 20, which may be a smart card 20a in the present example.
  • the asymmetric cryptography key pair 50 is preferably generated in the smart card 20a and the private key 50a is stored in the secure storage 22 of the smart card 20a, while the public key 50b may be transmitted to the communication device 10 where it is stored in the data storage 12 of the communication device 10 and will be used to generate the public key certificate 50b’.
  • a program 12a is stored in the data storage 12 of the communication device 10, which receives and processes the requests from the user, communicates with the smart card 20a, and presents the results of the smart card 20a actions to the user on the display 15 of the communication device 10.
  • User attributes 25 are also stored in the secure storage 22 of the smart card 20a.
  • step 100 the user authenticates himself by inputting via the input interface 16 (which may be a keyboard, a touchscreen 15, a fingerprint sensor, a camera, an NFC antenna, a mouse, touch pen, etc.) of the communication device 10 user authentication data 24'.
  • the user is authenticated by the smart card 20a connected with the communication device 10 after having received some form of the user authentication data 24' from the communication device 10 by comparing the received user authentication data 24' with the stored user authentication data 24 as will be explained later on.
  • the smart card 20a or the software application 28 has a unique PIN 201 which is a form of user authentication data 24 and which the user needs to know and needs to input upon request to be able to perform any transaction with it.
  • user authentication data 24 may be used as well, such as biometric identifiers.
  • client device 10 is such a device which is typically used by a single user (like the mobile phone)
  • program instance identifier 202 of the program 12a running on the communication device 10 e.g. or some other specific information related to the user device like telephone number or serial number of the mobile phone, IME I, or MAC address
  • a query command 204 is generated with the program 12a stored in the data storage 12 of the communication device 10 to request information 206 of a set of stored user attributes 25 stored in the chip card 20a.
  • the query command 204 may be generated to find out what kind of user attributes 25 are stored in the storage unit 22 of the secure wallet 20.
  • the chip card 20a there may be multiple sets of user attributes 25 stored, belonging to different virtual ID cards, each of which may correspond to an original (real life) ID card (or even to such ID cards which are only issued electronically), and the user needs to pick the virtual ID card or the one or multiple of user attributes 25 he/she intends to use.
  • These multiple sets of user attributes 25 may be managed by one or more applications 28 in the smart card 20a.
  • the program 12a in the communication device 10 may manage the multiple sets of user attributes 25 related to different virtual IDs on the chip card 20a together, or a separate program 12a may be necessary for each set of user attributes 25.
  • step 104 the user authentication data 24' (for example the unique PIN 201 and program instance identifier 202) and the query command 204 are transmitted to the smart card 20a that is connected to the communication device 10 via the smart card interface 14 of the communication device 10.
  • the user authentication data 24' and the query command 204 may be transmitted in separate steps as well.
  • step 106 the smart card 20a or the secure electronic wallet application 28 verifies the user authentication data 24' by comparing it with the user authentication data 24 stored in the storage unit 22 of the smart card 20a and if the verification fails a rejection response 208 is returned to the communication device 10.
  • step 108 in case the user authentication was successful, the smart card 20a collects the information 206 of the set of stored user attributes 25.
  • step 110 the information 206 of the set of stored user attributes 25 is returned to the communication device 10 where the program 12a outputs the information 206 on the user interface (such as the touch screen 15) for the user in step 111.
  • the program 12a outputs the information 206 on the user interface (such as the touch screen 15) for the user in step 111.
  • step 112 user selects the user attributes/attribute properties based on the displayed information 206 of the set of stored user attributes 25 with the program 12a stored in the data storage 12 of the communication device 10 which he/she wants to include in the core content 212 of the special purpose electronic ID card 214.
  • a command 210 identifying the selected user attributes/attribute properties is generated by the program 12a.
  • the user authentication data 24' unique PIN 201 and program instance identifier 202
  • the command 210 identifying the selected user attributes/attribute properties are transmitted to the smart card 20a that is connected to the communication device 10 via the smart card interface 14 of the communication device 10.
  • the user authentication data 24' and the command 210 containing the information about the selected user attributes/attribute properties may be transmitted in separate steps as well. Alternatively, the user authentication may be omitted as the user has already been authenticated at the start of the transaction or user authentication may not be required at all.
  • step 116 the smart card 20a verifies the user authentication data 24' by comparing it to the stored user authentication data
  • step 118 the smart card 20a application 28 collects the selected user attributes and/or attribute properties identified by the command 210 from its secure storage 22 and generates a dataset 216 therefrom.
  • the smart card 20a may append additional data to the dataset 216 like a time stamp, a transaction ID, the ID or name of the issuer of the original ID card, the identification number of the smart card 20a, which data may be mandatory or beneficial for the eventual identification of the user, which data are either already stored on the smart card 20a, or are received from the communication device 10, or are generated by the smart card 20a.
  • additional data are used to generate an appended dataset 216’ by the secure wallet 20.
  • the steps of generating the additional data and the steps of appending the various data to the dataset 216 may follow any order or be carried out in more steps sequentially, as is clear for a person skilled in the art.
  • step 122 the smart card 20a signs the dataset 216 or appended dataset 216’, whichever was prepared, using the private key 50a stored in its secure storage unit 22, whereby a core content 212 of the special purpose electronic ID card 214 is generated.
  • the smart card 20a may store multiple different sets of user attributes
  • private keys 50a stored in the secure storage unit 22 each of which, depending on the configuration of the information on the smart card 20a, may need to be specifically used for signing their related dataset 216.
  • one single private key 50a may be used for signing the dataset 216 irrespective of the fact which set of user attributes 25 it contains.
  • step 124 the signed dataset 216 or the signed appended dataset 216' (together: the core content 212 of the special purpose electronic ID card 214) is returned to the communication device 10 via the communication interface 23 of the smart card 20a.
  • step 126 the program 12a and /or the communication device 10 may further amend or format the secure core content 212 as requested by technology, regulation, standards or other requirements to turn it into the special purpose electronic ID card 214 which can be used for user identification and sharing the least personal data possible.
  • step 127 the special purpose electronic ID card is preferably displayed on the user interface (such as the touch screen 15).
  • step 128 the user may define, by choosing a service on the communication device 10, where he/she wants to use the special purpose electronic ID card 214 to present its information.
  • step 130 the user sends the special purpose electronic ID card 214 to a selected third party 300 to use it for identification together with the public key certificate 50b’ which has been generated from the public key 50b of the asymmetric cryptography key pair 50.
  • the public key certificate 50b’ if sent together with the special purpose electronic ID card 214, will allow the third party 300 to verify the validity of the special purpose electronic ID card 214.
  • the public key certificate 50b’ is preferably signed by the issuer of the ID card the content of which is included in the special purpose electronic ID card 214.
  • Fig. 4 illustrates the steps of a second preferred embodiment.
  • the same reference numerals have been used for corresponding steps and entities. It will be appreciated that the order of the steps may differ from the order presented here.
  • the program 12a running on the communication device 10 has already all the information available about the user attributes 25 stored in the smart card 20.
  • the availability of this information may be the result of storing the information 206 of the set of user attributes 25 previously received in step 110 in the program 12a permanently, or at least for a longer period, to spare synchronizing this information each time before user identification is needed.
  • the information 206 of the set of user attributes 25 may be directly loaded into the program 12a running on the communication device 10 over the air, e.g. by the issuer of the ID card to which the information 206 of the set of user attributes 25 relates to.
  • step 111 the information 206 is displayed for the user following which, in step 112 the user makes the choice to define the selected user attributes/attribute properties and the command 210 identifying the selected user attributes/attribute properties is generated in step 113 by the program 12a.
  • Example 1 Buying alcoholic drinks online when age needs to be verified.
  • the buyer the user of the communication device 10 (in the present situation a mobile phone 10a) opens the program 12a running on the mobile phone 10a and selects a national ID card from among multiple stored ID cards.
  • the user wants to see what information the national ID card has, which could be used to have the purchase authorized.
  • To initiate the query command 204 which will return the information 206 of the stored user attributes 25, the user must input a 4-digit PIN code 201 , which is going to be validated in the smart card 20a connected to the communication device 10, which in the present scenario is a SIM size smart card 20a inserted into to second SIM slot of the mobile phone 10a.
  • the program instance ID (RegID) 202 of the program 12a running on the communication device 10 as the second factor.
  • the user authentication data 24' (unique PIN 201 and program instance identifier 202) and the query command 204 are transmitted to the smart card 20a that is connected to the communication device 10 via the smart card interface 14 of the communication device 10.
  • the application 28 will verify the user authentication data 24' by comparing it to the stored user authentication data 24 and if the received and stored information correspond then the transaction may continue. Otherwise, the smart card 20a will return an error message to the communication device 10, that user authentication failed, PIN input needs to be repeated. Preferably, after the third consecutive erroneous attempt the application 28 will be permanently blocked and it will need to be reinstalled and re-personalized with the user specific attributes. It is also conceivable that the overall smart card 20a is blocked, and may not even be revived.
  • the application 28 will prepare the information 206 of the stored user attributes 25 and will return it to the communication device 10 to have it presented to the user on the display of the communication device 10, which is the mobile phone.
  • the user does not want to show his actual birth data, only wants to assure the seller that he is older than the legal requirement. For this reason, he does not select the birthday information as the attribute to present but rather will inform the merchant about his age.
  • the age of the user is not stored as attribute on the smart card 20a instead it is a property of the stored attribute (birthday) which can be obtained by subtracting the birthday date of the user from the current day of the operation.
  • the user also wants to inform the seller that the information is originated from the national ID card.
  • the program 12a running on the communication device 10 prepares the command identifying selected user attributes 210 (e.g. name of the national ID card and its expiration date) and the selected property of a selected user attribute (e.g. age of the user being a property of the birthdate) and sends it together with the user authentication data 24' (unique PIN 201 and program instance identifier 202) to the smart card 20a that is connected via the smart card interface 14 of the communication device 10.
  • the command containing the information of the selected property of the selected user attribute 210 may further contain additional information like current time, message ID, or other complementary information.
  • the application 28 verifies again the user authentication data 24' by comparing it to the stored user authentication data 24 and if the verification is successful, it starts processing the received command.
  • the application 28 calculates the age of the user by subtracting his birthday date from the current data and will use this data, the name of the national ID card and its expiration date to prepare dataset 216.
  • the application 28 appends a time stamp to the dataset 216and prepares the appended dataset 216”. This time stamp helps proving that the data has been generated quasi real-time and is not a pre-stored information.
  • the application 28 uses the private key 50a stored in the secure storage 22 of the smart card 20a, to digitally sign the appended dataset 216” and thereby generates the core content 212 of the special purpose electronic ID card 214.
  • the smart card 20a may all share the same private key 50a or may have their own individual private key 50a’ to be used to prepare the digital signature.
  • the core content 212 of the special purpose electronic ID card 214 is returned to the communication device 10 and the user is informed that the special purpose electronic ID card 214 has been prepared and is ready to be used. Before usage however, there may be some further technical steps necessary to allow transmission and sharing of the special purpose electronic ID card 214 with external third parties.
  • the special purpose electronic ID card 214 When the special purpose electronic ID card 214 is ready to be presented, the user will include this digitalized document and the public key certificate 50b’ related to the private key 50a used for signing the appended dataset 216” in his purchase request which he sends to the merchant. This message contains only the minimum necessary information about the buyer.
  • the merchant Upon receiving the purchase request the merchant first will make sure that the special purpose electronic ID card 214 is valid, its content has not been modified, it is signed by the person who claims to be signatory and that the data it contains is derived from the ID card, referred to in the core content 212. If these controls are successful, and the user can demonstrate that he/she is old enough then the sale is approved and the purchase transaction may proceed.
  • new special purpose electronic ID card 214 of the present disclosure students can easily prove their place of residency and student status without the need to share either their name, exact address or other personal information which may be used for profiling by the businesses, and thus they can avoid unsolicited commercial offers and advertisement.
  • the student has a mobile phone as the communication device 10, but the secure electronic wallet 20 this time is located remotely and connected to a remote server 80 in the form of a chip card 20a.
  • the physical architecture of the system is transparent for the user, he/she does not recognize the difference between having a smart card 20a inserted into the mobile phone or having the smart card 20a hundreds of kilometers away somewhere in the cloud.
  • the physical transaction flow is obviously more complex in the remote secure wallet 20 configuration as more devices and communication channels are involved in the transaction flow. To avoid the need to describe repeatedly identical technical solutions at each step of the transaction, first a summary description will be provided about the overall transaction flow.
  • the command is transmitted to the remote server 80 through the communication interface 13 of the communication device 10 and the communication interface 83 of the remote server 80 - both being suitable for remote communication - using the Internet 62 over an electronic communication channel 60.
  • the remote server 80 is connected through a smart card interface 84 with the smart card 20a. In the present configuration the remote server 80 has no other role than to transfer the messages received from the communication device 10 to the smart card 20a and return responses of the smart card 20a to the communication device 10.
  • the student identification using the special purpose electronic ID card 214 of the present disclosure is performed as follows.
  • the student has a student card application as the program 12a in her mobile phone.
  • This application is synchronized with the application 28 running in the smart card 20a, as it received related data which is stored in the application 28 when it was loaded into the smart card 20a.
  • the student does not need to query the smart card 20a instead the student can directly define which attributes she wants to present to the local business.
  • the student selects the ZIP code of her address and the name of the school where she studies which attributes are included in the information 206 of the stored user attributes 25.
  • These attributes 25 prove that she is local and is a student. Using these data, the student satisfies the requirements of being eligible for the benefits, but does not share any sensitive information like her name, address, age, etc.
  • the user also must authenticate herself and this time her face ID is used for authentication which is controlled locally in her mobile phone.
  • her face ID is used for authentication which is controlled locally in her mobile phone.
  • the application instance ID 202 of the student card program 12a is also used as the second factor.
  • the communication device 20 Upon the successful verification of the face ID in the mobile phone, the communication device 20 automatically sends the command identifying the selected user attributes 210 together with the application instance ID 202 to the remote smart card 20a as described above.
  • the student card application 28 in the smart card 20a When the student card application 28 in the smart card 20a receives the command, it first verifies the application instance ID 202. If the verification is successful, the application prepares the dataset 216 comprising the ZIP code and the school name as defined by the user.
  • the application 28 appends a time stamp to the dataset 216and prepares the appended dataset 216”.
  • the application 28 uses its own dedicated private key 50a stored in the secure storage 22 of the smart card 20a, to digitally sign the appended dataset 216” and to thereby prepare the core content 212 of the special purpose electronic ID card 214.
  • the core content 212 of the special purpose electronic ID card 214 is returned to the communication device 10 as described above.
  • the student card application 12a links the special purpose electronic ID card 214 with the public key certificate 50b’ containing the public key 50b of the asymmetric cryptography (PKI) key pair 50, which public key certificate 50b’ is digitally signed by the same entity which issued the official student card.
  • PKI asymmetric cryptography
  • the student card application 12a presents the special purpose electronic ID card 214 which has been generated for this specific transaction, to the user on the display of the mobile phone.

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)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un procédé pour générer de manière dynamique une carte d'identité électronique à usage spécial contenant des attributs d'utilisateur sélectionnés, le procédé consistant à : - stocker des attributs d'utilisateur dans une unité de stockage d'un portefeuille électronique sécurisé ; - stocker une clé privée d'une paire de clés de cryptographie asymétrique dans le portefeuille électronique sécurisé ; - recevoir, par le portefeuille électronique sécurisé en provenance d'un dispositif de communication, une instruction identifiant au moins un attribut d'utilisateur ou au moins une propriété d'au moins un attribut d'utilisateur ; - récupérer, par le portefeuille électronique sécurisé, des données du ou des attributs ou de la ou des propriétés du ou des attributs identifiés par l'instruction à partir de l'unité de stockage du portefeuille électronique sécurisé ; - générer, dans le portefeuille électronique sécurisé, un ensemble de données contenant au moins les données récupérées ; - signer l'ensemble de données dans le portefeuille électronique sécurisé à l'aide de la clé privée stockée dans l'unité de stockage du portefeuille électronique sécurisé ; et - transmettre l'ensemble de données signé du portefeuille électronique sécurisé au dispositif de communication de telle sorte que le dispositif de communication peut générer une carte d'identité électronique à usage spécial à partir de l'ensemble de données signé.
PCT/HU2023/050023 2022-05-31 2023-05-09 Mise en œuvre d'une identité auto-souveraine (ssi) sur la base de profils individuels configurables générés en temps réel à partir d'attributs privés stockés dans les éléments sécurisés personnels des utilisateurs WO2023233173A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
HUP2200195 2022-05-31
HUP2200195 2022-05-31

Publications (1)

Publication Number Publication Date
WO2023233173A1 true WO2023233173A1 (fr) 2023-12-07

Family

ID=89662377

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/HU2023/050023 WO2023233173A1 (fr) 2022-05-31 2023-05-09 Mise en œuvre d'une identité auto-souveraine (ssi) sur la base de profils individuels configurables générés en temps réel à partir d'attributs privés stockés dans les éléments sécurisés personnels des utilisateurs

Country Status (1)

Country Link
WO (1) WO2023233173A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150058960A1 (en) * 2012-08-20 2015-02-26 Jericho Systems Corporation Elevating Trust in User Identity During RESTful Authentication and Authorization
US20200178069A1 (en) * 2018-10-30 2020-06-04 Barclays Services Limited Secure data communication
US20220021537A1 (en) * 2020-07-14 2022-01-20 Visa International Service Association Privacy-preserving identity attribute verification using policy tokens

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150058960A1 (en) * 2012-08-20 2015-02-26 Jericho Systems Corporation Elevating Trust in User Identity During RESTful Authentication and Authorization
US20200178069A1 (en) * 2018-10-30 2020-06-04 Barclays Services Limited Secure data communication
US20220021537A1 (en) * 2020-07-14 2022-01-20 Visa International Service Association Privacy-preserving identity attribute verification using policy tokens

Similar Documents

Publication Publication Date Title
US11444782B2 (en) Dynamically managing exchanges of data using a distributed ledger and homomorphic commitments
CN111164594B (zh) 用于将去中心化标识映射到真实实体的系统和方法
CN111316303B (zh) 用于基于区块链的交叉实体认证的系统和方法
CN111213147B (zh) 用于基于区块链的交叉实体认证的系统和方法
CN105659558B (zh) 计算机实现的方法、授权服务器以及计算机可读存储器
EP3721578A1 (fr) Procédés et systèmes de récupération de données au moyen de mots de passe dynamiques
Chadwick et al. Improved identity management with verifiable credentials and fido
US11762746B2 (en) Failover between decentralized identity stores
CN113614725A (zh) 数据位置和政策遵守中的用户选择
US11587084B2 (en) Decentralized identification anchored by decentralized identifiers
WO2020222927A1 (fr) Localisation de données et de revendications associées aux did
US11138341B2 (en) Quick actions for did attestation user interface elements
EP4026291B1 (fr) Contrôle de l'utilisation déléguée de données relatives à des identifiants décentralisés (did)
CN113574528A (zh) 提供针对did数据的遵守策略的存储
WO2020242584A1 (fr) Génération dynamique de pseudonymes
CN117426072A (zh) 可验证凭证中的背书声明
CN113966597A (zh) 使用多个解析器解析分散标识符
KR20240015642A (ko) 검증 가능 클레임을 위한 신뢰성 있는 관리 연속성
CN113994630A (zh) 用于did证明的呈现中断
EP4018614A1 (fr) Délégation/révocation d'identifiant numérique (did) à un autre did
US11288358B2 (en) On skin decentralized identity technologies
WO2023233173A1 (fr) Mise en œuvre d'une identité auto-souveraine (ssi) sur la base de profils individuels configurables générés en temps réel à partir d'attributs privés stockés dans les éléments sécurisés personnels des utilisateurs
WO2024021785A1 (fr) Procédé et appareil de traitement d'entité numérique, dispositif, support et produit-programme
CN115053217A (zh) 发布可验证成对声明

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23741109

Country of ref document: EP

Kind code of ref document: A1