EP2932446A1 - Système de réputation et procédé - Google Patents

Système de réputation et procédé

Info

Publication number
EP2932446A1
EP2932446A1 EP13805779.9A EP13805779A EP2932446A1 EP 2932446 A1 EP2932446 A1 EP 2932446A1 EP 13805779 A EP13805779 A EP 13805779A EP 2932446 A1 EP2932446 A1 EP 2932446A1
Authority
EP
European Patent Office
Prior art keywords
reputation
user
terminal
security module
identity
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
EP13805779.9A
Other languages
German (de)
English (en)
Inventor
Gisela Meister
Dirk Wacker
Katharina WALLHÄUSSER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient GmbH
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 Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP2932446A1 publication Critical patent/EP2932446A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Buyer or seller confidence or verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/384—Payment protocols; Details thereof using social networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

  • the present invention relates to a method for saving a transaction in a reputation system and to a terminal for carrying out the method and a reputation system.
  • Reputation systems are now widely used in the face of increasing digital communication and increasing commerce through non-personal, digital communication channels.
  • the goal is always to enable a communication or trading partner to assess the credibility of the specified identity and the trustworthiness of the other communication or trading partner without the need for personal experience.
  • Each participant in the reputation system is assigned a so-called reputation value. This may change depending on how the participant behaves over time to the other participants.
  • the reputation value of a participant thus results from its previous relationships with other participants in the reputation system and reflects qualitative and / or quantitative aspects of its previous involvement in the system. Reputation values therefore allow a comparison of different participants of such a system.
  • An Internet retailer for example, who always delivers punctually perfect goods, will thereby obtain a high / positive reputational value, mainly due to the incoming positive reviews of his customers. However, a customer who is distracted by poor payment habits and ongoing unfounded complaints will eventually become a more low / negative recipient. attributed value because the trading partners of the customer evaluate this rather negatively.
  • Reputation systems can basically be designed in different ways.
  • a first class of such systems is characterized by a central entity that essentially mediates and manages all communication between the participants of the system.
  • a subscriber always logs in to the system in front of the central instance before a transaction within the reputation system is possible.
  • An example of such a reputation system with a central instance is a social network, whereby the operator of the network assumes the role of the central instance.
  • reaction is to be broadly understood in the context of the present invention and includes any type of analogue and digital data communication within a reputation system involving an exchange of information.
  • the term is particularly not limited to purely business transactions in which there is a monetary value
  • such communications should include, but are not limited to, communications in which information, information or opinions are provided by one and collected by others.
  • Reputation systems are generally described, for example, in US 2007/0203852 AI, US 2011/0276604 AI or US 2009/0204542 AI.
  • the credibility of such reputation systems may be compromised by forging or manipulating the reputation values of individual participants.
  • a given digital identity can easily be a pseudonym. It can not be ruled out that a plurality of digital identities in a system can act as a real person. In this case, however, it must be avoided that a real person can also specify several persons via different digital identities.
  • Document WO 2012/163970 discloses a method for performing an anonymous payment transaction.
  • a user can use a pseudonym to pay.
  • the user authenticates himself to a smart card.
  • the chip card transmits user data to a card reader.
  • the card reader sends encrypted user data with the pseudonym to a bank server.
  • the bank server provides the user with a unique identity from the encrypted data of the user.
  • US 2004/0003247 discloses a peer-to-peer network in which network users authenticate each other.
  • Object of the present invention is to take into account the aforementioned disadvantages and to propose a method for participation in a reputation system, which avoids the disadvantages mentioned.
  • This object is achieved by a method, a terminal and a reputation system having the features of the independent claims.
  • Advantageous embodiments and further developments are specified in the dependent claims.
  • the invention is based on the basic idea of coupling the real identity of a user to a digital identity used by the user in a reputation system by authenticating the user to the terminal using an electronic identity certificate before logging on to the reputation system by means of a terminal necessary is.
  • the reputation system includes the terminal of the
  • the terminal includes a security module. Furthermore, the reputation system comprises another security module and / or a server.
  • a method of securing a transaction in a reputation system comprises a step of providing electronic proof of identity on the security module.
  • the user of the terminal authenticates himself by means of an electronic proof of identity on the security module for enabling authentication data of the digital identity.
  • the activation takes place after successful authentication of the user.
  • This authentication step is preferably performed with respect to the terminal. It would also be an authentication against the security module conceivable, for example by means of PIN.
  • the unlocked authentication data of the digital identity It may relate to the real but also digital identity of the user, in particular.
  • the authentication data may also relate to one or more digital pseudonyms. Thus, for example, after successful authentication by the user only for the user possible pseudonyms available. The user could even choose a pseudonym from the set of possible pseudonyms. It would also be conceivable that the terminal and / or security module selects a pseudonym.
  • a digital pseudonym assigned to the user of the terminal is authenticated to the reputation system by means of the terminal using authentication data relating to the digital pseudonym.
  • the authentication data are preferably stored on the terminal and / or on the security module.
  • the reputation system provides a reputation value based on the authentication data. Reputational value concerns digital identity. This means that, if a pseudonym is used, authentication data corresponding to the pseudonym is used, but the reputation system determines a reputation value relating to the digital identity.
  • the transaction to be saved is executed. After
  • Transaction updates the reputation value of the digital identity regarding the transaction by the reputation system.
  • the user and the reputation system as well as other users always have current reputation values at their disposal.
  • a security module may be a portable data carrier, such as a smart card, a secure mass storage card, or a USB token. Portable data carriers can - for contact-type communication with the terminal - reversibly be used in the terminal.
  • the security module may also be a security module permanently installed in a terminal, such as a trusted platform module (TPM), a short-range communication (NFC) module, an M2M module, a user identification module or a decoder module.
  • TPM trusted platform module
  • NFC short-range communication
  • M2M short-range communication
  • the security module is a hardware security module. These options are basically independent of each other for all listed security modules.
  • the security module can thus be preferably as an electronic identity card or passport in the form of a portable data carrier.
  • the security module includes the electronic proof of identity. With the electronic proof of identity, a clear assignment of the digital identity to the real identity is possible.
  • the electronic proof of identity may be a personal electronic card, in particular an electronic identity card in the form
  • a portable terminal device such as, for example, a mobile radio terminal, a smartphone, a tablet, a notebook or the like is particularly suitable as terminal.
  • the data communication of the terminal with the reputation system takes place via a suitable communication network, for example via the Internet or the telecommunications network.
  • the security module can be provided in the terminal.
  • the security module can be supplied with information from a provider, in particular a TSM, a publisher of the security module, the reputation system itself and / or an identity card with data concerning the digital identity of the user and / or the authentication data.
  • a personal indicates certain personal data of the user, for example the digital identity, authentication data and / or pseudonyms, to the security module of the terminal.
  • an application on the security module of the user's terminal could obtain personalization data necessary for personalization from the network of the reputation system.
  • the provider in particular a central unit, information about the presence of the data on the security module and / or the transmission of the data to the security module of the user's terminal can be transmitted. From this information, in the present case, the personal ID card for providing the data to other security modules can be blocked.
  • a provider or publisher of the personal ID card for a reputation system only permits certain, in particular certified, pseudonyms or electronic identities.
  • the terminal authenticates the user by checking the electronic proof of identity. After successful authentication by the terminal authentication data for performing the authentication of the digital pseudonym to the reputation system are enabled.
  • authentication and authentication are used in accordance with the usual language usage.
  • one party identifies itself to the other party or "authenticated”. For example, using an electronic credential or using other authentication data, such as a username and a password, the other party then "authenticates” the one party by checking the submitted authentication data.
  • the entire process ie the authentication and the subsequent authentication, is again described overall with the term "authentication”.
  • the terminal and / or the security module comprises a reputation securing device.
  • This is set up to perform an authentication of a digital identity associated with a user of the terminal with respect to a reputation system using authentication data that is stored on the terminal and relates to the digital identity.
  • the reputation assurance device is set up to perform an authentication of the user on the basis of an electronic identification of the user coupled to the terminal.
  • the reputation-securing device is preferably set up to release the authentication data stored on the terminal, in particular security module, relating to a digital pseudonym only after successful authentication of the user on the basis of the electronic identity proof.
  • the reputation-securing device according to the invention is preferably designed as a trustworthy application, as a rule within a secure environment of the terminal.
  • the reputation assurance device can be designed as a so-called "trustlet” within a so-called “trusted execution environment”.
  • One "Trusted Execution Environment” consists of a special security hardware environment and a security operating system operating in this environment, such as Applicant's MobiCore® security operating system, which can be used in conjunction with a security hardware architecture in accordance with ARM® TrustZone® technology
  • the invention can solve the problems and deficiencies known from the prior art, by combining with the electronic proof of identity, a higher liability can be achieved on the part of a subscriber of the reputation system, thereby strengthening the credibility in the identity of the subscriber and its credibility
  • the inventive use of the electronic proof of identity allows a clear, trusted authentication of the respective subscriber, without it being necessary, its true ide identity in the reputation system. In particular, the participant may act under a pseudonym without this compromising its credibility.
  • Manipulation attempts such as the deletion of an old pseudonym or an old digital identity and the subsequent creation of a new digital identity for the same real user are reliably detected and prevented by the reputation assurance device in conjunction with the electronic identification.
  • the reputation value unique to the subscriber and / or user can be determined and exchanged.
  • the invention is not limited to financial transactions only. Rather, the use of the invention is also to other networks, such as social networks to see.
  • By providing a "correct" and unique reputation value for the user their trustworthiness in the network can be ensured Users themselves but all other participants in the network, in particular transaction partners of the user. Based on the reputation value, it could be decided whether a message is accepted by the user or the transaction partner.
  • the security of the network could be increased by excluding subscribers with a certain reputational value and worse.
  • the reputation system is part of the network.
  • a network here is the successful log in (login) in a system, eg. For example, a social network.
  • the reputation system can also be independent of the network. For the sake of simplicity, however, no distinction is made here.
  • the step of authenticating the digital pseudonym to the reputation system preferably takes place with respect to a central instance of the reputation system, in particular a server or a multiplicity of central servers, provided that the reputation system comprises such a central entity.
  • the operator of the network will receive and authenticate the authentication data. If the authentication is successful, the subscriber, represented by a pseudonym linked to the digital identity, can establish contact with other subscribers in the reputation system and carry out any desired transactions.
  • the reputation system does not include a central instance, such as in connection with a peer-to-peer network, the step of authenticating the digital pseudonym to any other participant in the reputation system.
  • This other subscriber may be a server, computer or other security module. Of the other participants is part of the reputation system. After successful authentication by this subscriber, and possibly authentication and authentication in the opposite direction, the transaction between these two subscribers can then take place in the reputation system.
  • a manipulation of digital identities can be reliably prevented by interaction of the inventive reputation-securing device with the electronic proof of identity.
  • the guiding idea is to enable a reputation backup device on a terminal, the security module and / or the reputation system itself to be able to reliably check whether a real person has more than one digital identity in the terminal, security module or the reputation system is created.
  • the reputation-securing device deriving a user-specific key from an electronic proof of identity, which a user presents to the terminal in the context of authentication, by the reputation-securing device, that is to say in a secure and trustworthy manner.
  • the key is preferably derived in such a way that the key can not be used to deduce the true identity of the user, even if the user's personal data, such as a name, a date of birth, an address, is used to derive the key or the like.
  • the key can be formed for example by means of a hash value over a predetermined record of the electronic proof of identity. This allows a user to remain anonymous - and yet be clearly identifiable.
  • the user-specific key only depends on the data stored on the electronic proof of identity. In other words, regardless of which terminal device and at what point in time a key derivation is based on one and the same electronic proof of identity, the result is always the same.
  • the reputation assurance device couples the derived, user-specific key with the digital identity assigned to the user. For example, the key may be together saved with the authentication data of the user assigned digital identity. This coupling can already take place during a personalization of the reputation assurance facility.
  • the reputation-assurance device checks that the respective digital identity matches. That is, it is checked whether the digital identity associated with the user currently authenticated to the end device and / or security module matches the digital identity that is coupled to the already-stored identical key , If the digital identities are also identical, this means that a user is authenticated in the usual way repeatedly to the terminal and / or security module.
  • the reputation assurance device can reliably detect such a manipulation attempt and prevent it, for example, by the fact that the corresponding current authentication with respect to the terminal and / or the security module is considered as failed and the method is aborted. Authentication data for logging into the reputation system is therefore not released.
  • Another known variant of a manipulation of digital identities namely the deletion of a digital identity and the subsequent creation of a new digital identity - the same real user - can easily thereby preventing the reputation-assurance facility from deleting once-derived user-individual keys, even if a digital identity coupled thereto is deleted in the reputation system.
  • the creation of the new identity then fails due to the fact that the reputational security device still authenticates the old user in the terminal and / or security module by means of the electronic identification of the newly created digital identity on the basis of the derived, user-specific key stored, recognizes.
  • the reputation system can then check an assignment of the digital identity to the user-specific key in the manner described.
  • the reputation system may, for example, create a database in which all ever-received user-specific keys are stored, each coupled to the digital identity that authenticated on the first occurrence of the key in the reputation system. With each authentication of a digital identity with respect to the system, the latter then checks whether a key transferring the authentication data assigned to the digital identity already exists in the database, and if so, whether this existing key is coupled to a digital identity which is currently up-to-date authenticating digital identity.
  • the received user-specific keys are preferably administered there.
  • each further security module or each server or computer of another subscriber of the reputation system must undertake a corresponding data backup and check.
  • these tasks are also performed by the reputation assurance facility.
  • the reputation assurance device is preferably present on each security module and / or computer of each participant of the reputation system. Each participant in such a system can then detect at least one type of manipulation and prevent another party from attempting to authenticate to that subscriber using different digital identities.
  • Performing a transaction in the reputation system may require that a subscriber's digital identity be to update the reputation value with respect to the reputation system. Such updating is done by the reputation system according to predetermined procedures, rules, and rules that are not the subject of the present invention.
  • the reputation value is usually updated by the central instance of the reputation system.
  • reputation values of the identities participating in the system are also stored there.
  • a reputation value in this scenario can also be stored on the subscriber's terminal and / or on a security module containing the electronic proof of identity, preferably a personal identity card.
  • the step of updating the reputation value of the user's digital identity is preferably done by the terminal.
  • the reputation assurance device can be set up to update a reputation value relating to the digital identity according to predetermined rules.
  • a reputation value can alternatively or additionally be stored on a security module containing the user's electronic proof of identity.
  • the user dials into the network and selects a pseudonym to maintain anonymity.
  • the user is authenticated to the security module by means of the terminal.
  • Personal data such as authorization certificate, pseudonym and user authentication data can be exchanged with the security device. be adjusted.
  • the user is finally authenticated by the security module and / or the terminal.
  • the security module and / or the end device generates a cryptogram for authentication with respect to the network.
  • the security module of the transaction partner receives from the network a cryptogram that includes the reputation value of the user.
  • the security module of the transaction partner presents the submitted reputation value to the transaction partner.
  • the user starts the transaction.
  • Data such as transaction partner and transaction ID
  • the security module creates a cryptogram of the transaction data and sends the cryptogram to the network.
  • the security module of the transaction partner receives the cryptogram with the transaction data and, after the first check, transfers it to the transaction partner.
  • the transaction partner then creates an evaluation of the transaction.
  • the rating is transmitted to the network as a cryptogram by the security module of the transaction partner.
  • the user's security module receives the transaction evaluation cryptogram and updates the reputation.
  • the reputation assurance device may be configured to authenticate various users of the terminal. It then unlocks the authentication data for that digital identity associated with the real user of the terminal identified and authenticated by the presented credentials.
  • a user can be a participant in various reputation systems. He can use different pseudonyms, but they are all linked to a digital identity. Excluded is that a user in a reputation system participates in the same reputation system using a plurality of pseudonyms with different reputational values.
  • the reputation value of a user is always associated with a unique digital identity, which is secured by means of an electronic proof of identity. In a reputation system, therefore, only one reputational value is ever available to a user. Accordingly, the reputation assurance device can be set up to perform an authentication of one or more pseudonyms to different reputation systems.
  • a user is a subscriber in several reputation systems using one or more pseudonyms, and this user can be assigned different reputation values in the various reputation systems, it may be provided to form a reputation profile of the user.
  • the various reputation values concerning the pseudonyms are suitably taken into account.
  • a start reputation value of the user for participation in another reputation system can be derived from a reputation profile formed in this way. The determination of the reputation profile and the start reputation value can also be supported or performed by the reputation assurance facility.
  • the authentication data relating to the digital identity and, if appropriate, one or more reputation values and / or a reputation profile are stored in the terminal in a secure environment, preferably in a "trusted execution environment.” Only the reputation backup device then has access to them and only to them according to the procedure described above.
  • a rating created by the user, a transaction partner and / or the reputation system can be used.
  • the user and / or the transaction partner can make an input to his terminal.
  • the user evaluates the transaction partner and thus exerts influence on the reputation value of the transaction partner.
  • the transaction partner can in turn perform an evaluation of the user and thus influence the reputation of the user.
  • An evaluation by the reputation system can be calculated using various parameters, for example an evaluation of the transaction data, the transaction contents and / or the log-on times in a social network, the transfer of funds and / or a course of goods.
  • the reputation value can then be determined with different weightings and, if appropriate, the use of time intervals.
  • a precise reputation value of the user and / or of another subscriber can be provided. After the evaluation, a final update is usually performed by the reputation system, so that the following transactions always take place with current reputation values.
  • the security module can go through a personalization phase.
  • a secured channel can be established with a network, for example with a reputation system and / or a social network.
  • an authentication takes place between the security module and the network. After successful authentication, the network transmits an authorization certificate to the security module.
  • the security module then transmits a pseudonym (Restricted ID) to the network.
  • the security module then generates a key pair.
  • the network generates a certificate and a start reputation.
  • the network can be supported in all steps by a third party, for example a TSM (Trusted Service Manager, trusted mediator of data as a service provider who has access to secure areas, for example a Trusted Execution Environment (TEE), of a security module) or replaced.
  • TSM Trusted Service Manager
  • TEE Trusted Execution Environment
  • the terminal is advantageously designed to authenticate a digital pseudonym assigned to a user of the terminal to a reputation system using authentication data stored by the terminal and relating to the digital pseudonym.
  • the reputation assurance device is set up to perform an authentication of the user on the basis of an electronic identification of the user coupled to the terminal.
  • the reputation-securing device is designed to store the authentication data stored on the terminal and relating to a digital pseudonym only after successful authentication of the user Unlock the basis of electronic credentials and create a cryptogram that is capable of providing reputational values related to digital identity through the reputation system.
  • the cryptogram may represent the transmission of a reputation value for a user of the terminal.
  • the cryptogram may comprise data with which the reputation value can be derived by the reputation system, for example by means of a database.
  • the database is stored at the reputation assurance device or on a server.
  • the cryptogram can directly include the reputation value.
  • the reputation system is expediently executed with a central instance.
  • the central entity is executed as a server and preferably also comprises a reputation assurance device.
  • a cryptogram created by the reputation assurance device may include a user-made rating.
  • the inventive method, the terminal and the reputation system can be used both for a user as a sender of a transaction and for a recipient of a transaction. Furthermore, it can be provided that the central entity carries out a comparison of the current reputation value to the digital identity of a user when authenticating the security module to the network (reputation system). The adjustment can cause a pre-update of the reputation value on the security module or the central instance.
  • the reputation system according to the invention can thus not only be a system consisting of the security module and the user's terminal, wherein an entity concerns a user's digital identity Provides reputation value. Rather, the system may comprise a central entity consisting of one or more servers provided, for example, by a provider of the reputation system. If at least temporarily no central entity is available in the reputation system, the reputation system according to the invention can be limited to the security module and the user's terminal and a computer and / or server of the transaction partner. Thus, an exchange of the reputation values may be performed before a transaction, and possibly also an update of the reputation values after a transaction.
  • FIG. 1 shows a real user 1 who can be a participant in various reputation systems 100, 200.
  • the user 1 is assigned an electronic proof of identity 10 and a terminal 20.
  • the electronic proof of identity 10 is stored securely in a portable data carrier.
  • the portable data carrier may typically be a card-shaped personal electronic ID in the form of a smart card, such as an identity card, passport, bank card, driver's license, personal access card issued by an operator of a reputation system 100, 200, or the like Designs of portable data carriers, such as other card formats or token-like, are also possible.
  • the terminal 20 is shown in the present example as a smartphone.
  • Other, similar terminals such as a mobile station, a tablet, a notebook or the like are alternatively usable.
  • stationary terminals such as conventional personal computers, can be used.
  • the electronic proof of identity 10 is set up to communicate with the terminal 20 in data communication. This can be done without contact, for example via a contactless short-range communication protocol such as NFC, or also contact-based via corresponding data communication protocols.
  • the electronic proof of identity 10 is set up to issue an authentication cryptogram upon request by a terminal 20.
  • the authentication cryptogram can be any type of data that is suitable for uniquely and authentically identifying the issuing entity, that is to say the electronic identity proof 10.
  • the electronic credential 10 may also be configured to execute an application that includes a digital identity of a user and / or a user's identity. managed profile and returns a digital identity or a user profile on a request from a terminal 20.
  • the electronic proof of identity 10 may be adapted to check external authentication data supplied to it by a terminal 20.
  • the electronic proof of identity 10 can be designed to execute all security-relevant steps resulting from a transaction, with the terminal only functioning as a transparent auxiliary or conversion unit between the electronic identity proof 10 and the reputation system 100, 200.
  • the end device 20 comprises an application 22 trustworthy for a reputation system 100, 200, a so-called “trustlet”, which represents a reputation protection device 22 described in detail below with reference to FIGS. 2 and 3.
  • the application 22 is preferably in stored in a secure area, in a so-called “Trusted Execution Environment”, and is executed there.
  • the terminal 20 comprises external and internal authentication data 24, 26. These serve in particular, as explained below, to authenticate a digital identity assigned to the user 1 to a reputation system 100, 200.
  • a user 1 is in principle assigned exactly one digital identity, which can be proved by means of the electronic identification certificate 10. For a given unique digital identity, a user 1 may also have a
  • the respective digital pseudonym hereinafter referred to simply as a pseudonym, is together with any further data relevant to a reputation system 100, 200 in a user profile saved.
  • relevant data may be, for example, information about payment paths or voluntary information of a user.
  • the user profile can be completely or partially stored in embodiments on the electronic proof of identity 10 and managed by this.
  • the pseudonyms are appropriately managed by the reputation assurance device 22. In embodiments, they may also be managed by the electronic credential 10 or by the reputation system 100, 200.
  • the external authentication data 24 are known to the user and must be presented by the user.
  • the external authentication data 24 may be, for example, a user name or a password. They also authenticate a user 1 to the trusted application 22. They may also serve to generally authenticate a user to a reputation system 100, 200.
  • the external authentication data 24 can also include a plurality of information that must be presented one after the other.
  • the internal authentication data 26 contain at least information that allows a reputation system 100, 200 to assign a unique digital identity to a user 1.
  • the internal authentication data 26 can be, for example, the digital identity of the user 1 itself, an identifier, parts of the user profile or information derived from or pre-stored from said data.
  • the internal authentication data 26 contain information that can be verified by the reputation system 100, 200, which confirms that the digital identity is determined for a pseudonym by the terminal 20 or by the electronic identification certificate 10 was tested.
  • the internal authentication data 26 are known only to the trusted application 22 and the reputation system 100, 200, but not to the user 1.
  • a user-specific key 28 can be stored in the terminal 20. The type and method of key generation as well as the use of the key 28 will be described in detail below with reference to FIG. Alternatively, the user-individual key 28 can also be stored on electronic identification evidence 10.
  • the reputation system 100 illustrates a first basic embodiment of such a system, such as a social network.
  • a central entity 110 of the reputation system 100 for example the operator of the social network, manages and stores all data relevant to the participants 20, 101, 102 of the system 100 and essential for the operation of the reputation system.
  • the central entity 110 manages and stores data for the authentication of the subscribers 20, 101, 102 as well as a subscriber 20, 101, 102 currently assigned reputational values.
  • the authentication of a subscriber 20, 101, 102 in relation to the system 100 always takes place with respect to the central entity 110, as described with reference to FIG. 2.
  • the central entity 110 further updates reputation values of individual subscribers 20, 101, 102 according to predetermined rules. All transactions within the system 100 are handled via the central entity 110.
  • the reputation system 200 represents a second basic embodiment of a reputation system, in which no central administration entity is provided, but only equal participants 20, 210, 220, which can each contact each other directly.
  • the Reputation Onssystem 200 is described here as a peer-to-peer network.
  • the authentication of one subscriber 20 with respect to another, selected subscriber 210 is effected by mutual authentication, as described in detail with reference to FIG.
  • Reputation values of individual subscribers 20, 210, 220, necessary information for mutual authentication as well as reputation values are stored by the individual subscribers 20, 210, 220 themselves.
  • the updating of reputation values also takes place locally at the individual subscriber 20, 210, 220.
  • the subscribers 20, 101, 102, 210, 220 can represent different roles.
  • Reputation values of individual participants reflect their previous activity in the reputation system and are usually based primarily on an evaluation by other participants in the system.
  • a social network is set up for the reputation system 100 (see FIG. 1).
  • step S 1 the terminal 20 sends a connection request to the central entity 110 of the reputation system 100 in order to register a digital identity assigned to a user 1 of the terminal 20 with the system 100.
  • the user 1 can thereby different digital pseudonyms are available; if this is the case, the user 1 selects in a preparatory step an from it; the selected digital pseudonym can be identical to the digital identity of the user 1.
  • step S2 the central entity 10 sends an authentication request to the terminal 20 for the connection request. It may be provided that the central entity 110 and the terminal 20 or the reputation-protection device 22 first carry out a one- or two-way authentication. for example, by a challenge-response method. The authentication request is authenticated
  • the reputation-securing device 22 performs the authentication with respect to the system 100 only if the user 1 has previously successfully authenticated against the terminal 20.
  • the user 1 presents to the terminal 20 external authentication data 24, for example a user name and a password.
  • the presented external authentication data 24 are compared by the reputation assurance device 22 with that stored in the terminal 20.
  • the terminal 20 diverts the external authentication data 24 presented by the user 1 in full or in part to a checkpoint from the user for this also to be presented electronic proof of identity 10 on.
  • the authentication takes place at the central instance 110.
  • the user 1 authenticates himself by means of an electronic proof of identity 10, that is to say by means of an electronic identity card, with respect to the reputation securing device 22, thus with respect to the terminal 20.
  • the terminal 20 Unless already done, such as for the examination of external authentication data 24, the user 1 the terminal 20 correspondingly presents an electronic proof of identity 10. It is expediently provided that the terminal 20 and the electronic proof of identity 10 first perform a mutual authentication, for example by a challenge Response procedure, and establish a secure channel in which the subsequent data exchange is encrypted.
  • the reputation assurance device 22 enters into a data exchange with the electronic proof of identity 10 in step S3
  • Data exchange can be automatic or require user 1 activity.
  • an electronic identity card is always used for easier description.
  • the reputation assurance device 22 transmits the identity card 10 a request, to which the identity card 10 returns an authentication cryptogram.
  • the request may, for example, be an entitlement certificate that directly or indirectly supports the reputa- onssy system 100, 200 called. It can also be contained in parts or even completely in the authentication request of the central entity 110.
  • the request forms a command to which an application is executed on the identity card 10.
  • the application may be that the ID card 10 immediately identifies and verifies a digital identity.
  • the identity card 10 can also determine a pseudonym.
  • the digital identity and / or the pseudonym are returned to the reputation assurance device 22 as an authentication cryptogram.
  • the ID card 10 returns only information confirming that a digital identity and / or a pseudonym in the ID card 10 has been positively tested.
  • the application on the ID card 10 entire user profiles can be managed.
  • the identity card 10 additionally returns the user profile or parts thereof to the reputation assurance device 22 in response to an application execution command.
  • the identity card 10 can also be used to manage reputation values.
  • the identity card 10 in response to an application execution command in the authentication cryptogram additionally returns a reputation value assigned to a digital identity or a pseudonym to the reputation assurance device 22.
  • the identity card 10 forms a complete or substantially complete internal authentication data 26 in response to a command for application execution.
  • the function of the reputation backup device 22 with respect to the handling of such internal authentication data 26 is then essentially a matter of entering these into a to communicate with the reputation system 100, 200 appropriate protocol implement.
  • the provision of the internal authentication data 26 can also be provided with a time limit, according to which they lose their validity.
  • step S4 the reputation assurance device 22 checks the authentication cryptogram. In a simple manner, the check can be made by comparison to a reference value stored in the terminal 20.
  • the reputation assurance device 22 determines a digital identity and a user profile for the authentication cryptogram. With both of them determines authentication data 26, which unlocks them in step S5.
  • the authentication device 22 determines an associated user profile after successful authentication of the identity card 10, then forms authentication data 26 and enables it in step S5. If the reputation protection device 22 has received a user profile from the identity card 10, it completes it if necessary, thus forms authentication data 26 and releases it in step S5.
  • the internal authentication data 26 in this case contain the digital identity and / or the pseudonym. In a variant, it can be provided that the verification of the authenticity of the digital identity and / or associated pseudonyms is carried out by the reputation assurance device 22.
  • the reputation assurance device 22 checks whether the digital identity or the pseudonym is authentic and forms confirmation information. In an embodiment of the variant, it can further be provided that the reputation assurance device 22 manages the reputation values for a digital identity or the associated pseudonyms. In this case, the reputation assurance device 22 assigns a reputation value to a positively verified identity or an assigned pseudonym. The confirmation information inserts the reputation assurance device 22 into the internal authentication data 26. Likewise, it inserts a possibly assigned reputation value into the internal authentication data 26.
  • step S6 the reputation assurance device 22 sends the unlocked internal authentication data 26 to the central entity 110.
  • the central entity 110 In addition to the authentication, other functionalities of the electronic identity card 10 can be used, moreover.
  • the resulting results are also transmitted to the central entity 110 in step S6. If the authentication of the user 1 fails, for example because this submits a false identity proof 10, the method is aborted.
  • the internal authentication data 26 are then not enabled and authentication of the digital identity to the system 100 is not possible.
  • the central entity 110 checks the received internal authentication data 26 in step S7 and thus authenticates the pseudonym as a participant of the reputation system 100. If the authentication is successful, the reputation system 100 determines the digital identity for the pseudonym and assigns it a reputation value.
  • the reputation system 100 checks this and assigns it a reputation value.
  • the reputation system 100 checks the confirmation information and then assigns the pseudonym one Reputation value too. If the confirmation information only confirms that the digital identity has been checked by the reputation assurance device 22 or by the electronic identification certificate 10, the reputation system 100 checks whether the pseudonym used by the user 1 is authentic. In the case of credit, it assigns a reputation value to the pseudonym.
  • the reputation system 100 If the reputation system 100 has already assigned a reputation value assigned by the reputation assurance device 22 or by the electronic identification certificate 0 in the internal authentication data 26, the reputation system 100 takes over this. Subsequently, the user 1 is registered in the system 100 and, using the selected pseudonym and his user profile and with the associated reputation value, can contact other participants of the reputation system 100 via the central entity 110 and carry out transactions. If the authentication fails, transactions with other participants are not possible.
  • Each transaction in the system 100 involving the digital instance of the user 1 typically results in a change in the reputation value associated with the digital identity in the reputation system 100. To capture this, the reputation value is therefore updated regularly. The update is performed by the reputation system 100 itself, ie, by the central entity 110. In the central instance 110, the current reputation values of the subscribers are expediently stored for this purpose.
  • a reputation value of a subscriber may additionally also be stored at the subscriber himself, for example in the terminal 20, and / or in the electronic identification document 10.
  • a user may be a participant in various reputation systems 100, 200.
  • a user 1 can use several and different pseudonyms for their digital identity.
  • a digital identity can be assigned different reputation values. Different pseudonyms for a digital identity are assigned in a reputation system 100, 200 but only one reputation value.
  • the reputation assurance device 22 can also form a reputation profile for the user 1 from various reputation values and store and manage it in a tamper-proof manner in the secure area of the terminal 20. From such a reputation profile, for example, when the user becomes a participant in another - not shown - reputation system, a start reputation value can be calculated.
  • a second preferred embodiment of a method for saving a transaction in a reputation system 200 which is represented here by way of example as a peer-to-peer network (see FIG. Insofar as the method steps are the same as those described above in the method with reference to FIG. 2, a repetition of the description is omitted. Only the essential differences of the two methods should be pointed out.
  • the reputation system 200 makes contact with a subscriber 20 with the system 200 directly via any freely selectable subscriber 20 'of the system 200.
  • the activity of the subscriber 20 within the system 200 is then limited to the connection with the selected party 20 '.
  • a transaction with another subscriber requires further authentication also to this other subscriber.
  • step T12 Since the system 200 comprises only equal participants, as a rule all activities for preparing a transaction (see step T12) are to be executed in the same manner by both users 20, 20 'in each case.
  • a respective authentication of the respective users 1, 2 Before a mutual authentication can be carried out, which is indicated with reference to the steps T7 to T10, a respective authentication of the respective users 1, 2 must take place with respect to their respective terminal 20, 20 '. This is indicated in the steps T1, T2 and T3, T4. If the authentication in step T2, T4, was successful, subsequently the respective internal authentication data 26 in the terminals 20, 20 'can be released from the respectively executed reputation securing devices 22 (compare steps T5, T6) in order to obtain an authentication with respect to each other participants 20, 20 '(see steps T7, T8).
  • the mutual authentication can be done wholly or partially with the involvement of the identity card 10, if this is set up.
  • the terminal 20 transmits the ID card 10 to the internal authentication data 26 received from the respective other terminal 20, 20 'for examination.
  • the respective reputation values can optionally be exchanged in step TU. This enables each participant 20, 20 'to make a realistic and up-to-date assessment of the respective other party before carrying out the transaction.
  • the respective reputation securing devices 22 may be the respective ones update reputation values associated with digital identities, as indicated by steps T13 and T14.
  • one participant may rate the other participant's behavior during the transaction. This score may then be included in the updated reputation value as part of the update in step T13, 14.
  • Step S6 is slightly modified, steps S4.1, S4.2 and S7.1 are added.
  • step S4.1 the reputation assurance device 22 derives a user-specific key 28 from the authentication cryptogram provided by the electronic identification certificate 10, for example using a hash value or the like.
  • the reputation assurance device 22 subsequently checks whether a key corresponding to the derived key 28, ie identical key, is already stored in the terminal 20. If this is not the case, then the reputation assurance device 22 stores the key 28 together with the authentication data 24. This establishes a coupling of the electronic identity proof 10 with the digital identity assigned to the user 1. Such a coupling takes place only in the first authentication of the user 1 with respect to the terminal 20. If an identical key to the key 28 already exists in the terminal 20, the reputation assurance device 22 checks whether the user profile intended for use by the user 1 is based on the digital identity coupled to the stored key. If this is the case, the method continues with step S5 as described, otherwise aborted.
  • step S6 ' in contrast to step S6 according to FIG. 2, in addition to the authentication data, the key 28 is also transmitted to the central entity 110 of the reputation system 100.
  • the central entity 110 performs, in addition to the authentication of the digital identity (step 7) in step S7.1, a check of an assignment of the key 28 to the authenticating digital identity. Essentially, this check is analogous to the key check in step S4.2. In this respect, step S4.2 could be omitted.
  • manipulation attempts already detected in step S .2 relieve the resources of the reputation system 100, since then the method, as described, is already aborted in step S4.2 and steps S7 and S7.1 no longer have to be executed.
  • the central entity 110 stores all user-specific keys that have ever entered the entity together with authentication data , In this respect, manipulation attempts can be detected in step S7.1, which are not yet recognizable in step S4.2.
  • the central entity 110 checks in step S7.1 whether a key identical to the received key 28 has already been stored in a database of the central entity 110. This is equivalent to the fact that a digital identity has previously been authenticated in the reputation system 100 with the additional presentation of a key identical to the key 28. The key 28 may not be confused with the authentication data 24. These are checked in step S7. If the key 28 is not yet present in the system 100, the central entity 110 stores the key 28 together with details of the currently authenticating digital identity.
  • the central instance 110 checks whether the digital identity coupled to the already existing key is identical to the currently authenticating digital identity. If this is the case, the authentication of the digital identity is successful, otherwise the procedure is aborted. As will be readily apparent, the method described with reference to FIG. 3 may also be adapted accordingly.
  • FIG. 5 shows a further process sequence according to the invention.
  • the social network 300 comprises a reputation system.
  • a terminal 20 of the user 1 comprises a security module elDl.
  • a further terminal 20 'of the further user 2 comprises a further security module eID2.
  • Both security modules elD1 and eID2 are expediently designed as elements embedded in the terminals 20, 20 '.
  • the security module elDl is already personalized to the user 1.
  • To personalize the security module elDl connects in this embodiment, the user 1 with the terminal 20 to the social network 300.
  • a secure channel is made, for example by means of TLS (Transport Layer Security) protocol.
  • TLS Transport Layer Security
  • the security module elDl authenticates itself to the network 300.
  • the network 300 transmits an authorization certificate to the security module elDl.
  • the security module elDl then transmits to the social network 300 a pseudonym corresponding to the digital identity of the user 1.
  • the security module elDl generates, for example, a PKI key pair for authentication in the network 300.
  • the security module elDl sends a public key to the network 300.
  • the network 300 generates a certificate and a root key for verification of certificates for the received key.
  • the network 300 generates a start-up reputation.
  • the starting reputation is an initial reputation value that each "new" user receives from the social network 300.
  • the value may be a neutral value, such as the number zero or "50%," depending on the severity of the reputation scale.
  • the start reputation can be a statement of "new user.”
  • the certificate, the root key, and the start reputation are transmitted to the security module elDl of the user 1.
  • the user 1 authenticates himself in the step Ul.l with respect to the security module elDl.
  • the user 1 can select the network 300 and a pseudonym.
  • the user 2 authenticates independently thereof to the further security module eID2.
  • the security module elDl In step 2.1, the security module elDl generates a cryptogram based on the pseudonym of the user 1, its reputation value and the authentication with respect to the network 300. The security module elDl transmits this cryptogram via the network 300 to the transaction partner, ie the user 2.
  • the further security module eID2 of the user 2 receives a cryptogram from the network 300 in step U2.2. From this cryptogram the further security module eID2 recognizes the pseudonym of the user 1 and its reputation value.
  • the further security module eID2 transmits the information recognized by the cryptogram to the user 2 for checking. This is done, for example, by display and input to the terminal 20 'of the user. 2
  • the user 1 In step U3.1, the user 1 initiates a transaction.
  • the data of the transaction, the pseudonym and a transaction ID are sent to the network 300 in the form of a cryptogram by the security module elDl in step U3.2.
  • the further security module eID2 of the user 2 receives the cryptogram in step U3.3 from the network 300 and in step U3.4 transfers the data to the terminal 20 'for checking and inspection by the user 2.
  • the user 2 creates in step U4.1 an evaluation of the transaction and passes this to the further security module eID2.
  • the further security module eID2 transmits the evaluation in a cryptogram to the network 300 in step U4.2.
  • the network 300 transmits a cryptogram with the evaluation to the security module elD1.
  • the security module elDl receives in step U4.4 from the network 300 a cryptogram with the rating.
  • a reputation assurance device (not shown) of the security module elDl then updates the reputation value of the first user 1 using the rating.
  • the reputation value in step U2.1 of the user 1 can not be provided by the security module elDl but by the network 300.
  • the network 300 receives the reputation value relating to the user 1 from a background-operating reputation system, in particular a server. Accordingly, the evaluation of the user 2 from the cryptogram is intercepted by the reputation system in step U4.2 and processed to a current reputation value of the user 1. As can be seen from the representation of FIG. 5, a so-called peer-to-peer connection exists between the user 1 and the user 2.
  • the network can include a server that manages the connection and, if necessary, modifies the cryptograms between the security modules elDl and eID2.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Tourism & Hospitality (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé permettant de sécuriser une transaction (T12) dans un système de réputation (100; 200), ledit procédé consistant à : authentifier (S3; T1; T3) un utilisateur (1; 2) par rapport à un terminal (20; 20') au moyen d'une preuve d'identité électronique (10; 10') afin de valider les données d'authentification (24; 26) enregistrées sur le terminal (20; 20') pour l'identité numérique; et authentifier (S6; T7; T8) le pseudonyme numérique attribué à l'utilisateur (1; 2) par rapport au système de réputation (100; 200) au moyen du terminal (20; 20') en utilisant les données d'authentification (24; 26) enregistrées concernant le pseudonyme numérique. En particulier, la preuve d'identité électronique (10) peut se présenter en tant que carte d'identité électronique sous la forme d'un support de données portable.
EP13805779.9A 2012-12-17 2013-12-09 Système de réputation et procédé Ceased EP2932446A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102012024831 2012-12-17
PCT/EP2013/003719 WO2014095001A1 (fr) 2012-12-17 2013-12-09 Système de réputation et procédé

Publications (1)

Publication Number Publication Date
EP2932446A1 true EP2932446A1 (fr) 2015-10-21

Family

ID=49766029

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13805779.9A Ceased EP2932446A1 (fr) 2012-12-17 2013-12-09 Système de réputation et procédé

Country Status (3)

Country Link
US (1) US10867326B2 (fr)
EP (1) EP2932446A1 (fr)
WO (1) WO2014095001A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10083295B2 (en) * 2014-12-23 2018-09-25 Mcafee, Llc System and method to combine multiple reputations
US20180374151A1 (en) * 2017-06-27 2018-12-27 Intuit Inc. Dynamic reputation score for a digital identity
US11177937B1 (en) * 2018-03-08 2021-11-16 Anonyome Labs, Inc. Apparatus and method for establishing trust of anonymous identities
FR3083356B1 (fr) * 2018-06-29 2020-09-11 Ingenico Group Procede de realisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
CN114386043B (zh) * 2021-12-09 2024-06-14 北京理工大学 一种面向群智感知的去中心隐私保持信誉评估方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7003480B2 (en) * 1997-02-27 2006-02-21 Microsoft Corporation GUMP: grand unified meta-protocol for simple standards-based electronic commerce transactions
DE19718827C2 (de) * 1997-05-05 2000-01-05 Deutsche Telekom Mobil Verfahren und Vorrichtung zum Authentisieren von Mobilfunkteilnehmern
US7043760B2 (en) * 2000-10-11 2006-05-09 David H. Holtzman System and method for establishing and managing relationships between pseudonymous identifications and memberships in organizations
US20040003247A1 (en) 2002-03-11 2004-01-01 Fraser John D. Non-centralized secure communication services
US7512649B2 (en) * 2002-03-22 2009-03-31 Sun Microsytems, Inc. Distributed identities
DE102005033436A1 (de) * 2005-07-27 2007-02-01 Giesecke & Devrient Gmbh System mit wenigstens einer Rechnerplattform und wenigstens einem Benutzertoken
US20070124589A1 (en) * 2005-11-30 2007-05-31 Sutton Ronald D Systems and methods for the protection of non-encrypted biometric data
US8635679B2 (en) * 2005-12-08 2014-01-21 Webler Solutions, Llc Networked identity framework
US20070203852A1 (en) 2006-02-24 2007-08-30 Microsoft Corporation Identity information including reputation information
DE102007044905A1 (de) * 2007-09-19 2009-04-09 InterDigital Patent Holdings, Inc., Wilmington Verfahren und Vorrichtung zur Ermöglichung einer Dienstnutzung und Feststellung der Teilnehmeridentität in Kommunikationsnetzen mittels softwarebasierten Zugangsberechtigungsausweisen (vSIM)
US20090204542A1 (en) 2008-02-11 2009-08-13 Novell, Inc. Privately sharing relying party reputation with information card selectors
JP2012527678A (ja) * 2009-05-20 2012-11-08 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ポータブルなユーザー評判を可能にする方法および装置
US8621654B2 (en) 2009-09-15 2013-12-31 Symantec Corporation Using metadata in security tokens to prevent coordinated gaming in a reputation system
US8805881B2 (en) 2010-05-06 2014-08-12 International Business Machines Corporation Reputation based access control
US8819437B2 (en) * 2010-09-30 2014-08-26 Microsoft Corporation Cryptographic device that binds an additional authentication factor to multiple identities
US9213980B2 (en) * 2010-11-12 2015-12-15 Ebay Inc. Using behavioral data in rating user reputation
EP2530868A1 (fr) 2011-05-31 2012-12-05 Gemalto SA Procédé pour générer un jeton d'identification anonyme ne pouvant être lié et pouvant être acheminé

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2014095001A1 *

Also Published As

Publication number Publication date
WO2014095001A1 (fr) 2014-06-26
US10867326B2 (en) 2020-12-15
US20150332361A1 (en) 2015-11-19

Similar Documents

Publication Publication Date Title
EP3574625B1 (fr) Procédé de réalisation d'une authentification
EP2443853B1 (fr) Méthode de registration d'un terminale mobile dans un réseau sans fil
DE60200093T2 (de) Sichere Benutzerauthenifizierung über ein Kommunikationsnetzwerk
DE60200081T2 (de) Sichere Benutzer- und Datenauthenifizierung über ein Kommunikationsnetzwerk
EP2415228B1 (fr) Procede de lecture des attributes d'un token utilisant une connexion radio
WO2016128454A1 (fr) Procédé mis en œuvre par ordinateur pour un contrôle d'accès
DE102010028133A1 (de) Verfahren zum Lesen eines Attributs aus einem ID-Token
EP3764614B1 (fr) Système d'authentification distribué
DE102008040416A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
EP2932446A1 (fr) Système de réputation et procédé
EP2454702A1 (fr) Procédé de migration pour modules matériels de sécurité (hsm)
DE102008042582A1 (de) Telekommunikationsverfahren, Computerprogrammprodukt und Computersystem
EP3125464B1 (fr) Service de révocation pour un certificat généré par un jeton d'id
EP3271855B1 (fr) Procédé de génération d'un certificat pour un jeton de sécurité
WO2013075799A1 (fr) Procédé pour authentifier une personne se trouvant au niveau d'une instance de serveur
DE112020005586T5 (de) Verfahren zum Unterstützen des OTP-Dienstes durch Identifizierung von Benutzern mithilfe eines persönlichen URL-Mediums, Passwortes oder anderer Informationen
EP3107029B1 (fr) Procede et dispositif de signature electronique personnalisee d'un document et produit-programme d'ordinateur
EP4092958B1 (fr) Émission d'une identification numérique vérifiable
EP2645670A1 (fr) Mise à disposition d'attributs d'identité d'un utilisateur
DE102020210810A1 (de) Verfahren und Vorrichtung zum gegenseitigen Bewerten von Leistungserbringern und Leistungsempfänger mittels einer dezentralen Transaktionsdatenbank
EP3967009A1 (fr) Procédé d'authentification d'un utilisateur final vis-à-vis d'un service dépendant
DE102009028064A1 (de) Verfahren zur HSM Migration
DE102010030167A1 (de) Verfahren zur HSM Migration

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20150717

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH

17Q First examination report despatched

Effective date: 20171010

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20191204