WO2015128094A1 - Revokation eines sicherheitselements - Google Patents

Revokation eines sicherheitselements Download PDF

Info

Publication number
WO2015128094A1
WO2015128094A1 PCT/EP2015/000461 EP2015000461W WO2015128094A1 WO 2015128094 A1 WO2015128094 A1 WO 2015128094A1 EP 2015000461 W EP2015000461 W EP 2015000461W WO 2015128094 A1 WO2015128094 A1 WO 2015128094A1
Authority
WO
WIPO (PCT)
Prior art keywords
security element
identity
identifier
blocking
token
Prior art date
Application number
PCT/EP2015/000461
Other languages
English (en)
French (fr)
Inventor
Rainer Urian
Original Assignee
Giesecke & 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 & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Publication of WO2015128094A1 publication Critical patent/WO2015128094A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Definitions

  • the present invention relates to the revocation of security elements. More particularly, the invention relates to a method for checking a validity of a security element and a corresponding security element, a test device and a locking device, which are suitable to perform a corresponding method.
  • the security element In order to be able to block a stolen or lost security element, for example an identity card, the security element must be able to be uniquely identified by a service provider, for example an online service, to whom the security element is presented.
  • security elements are only used in conjunction with anonymous credentials, such as proof of age.
  • proof of age For reasons of data economy, only a security element always transmits data to the service provider that is necessary in the context of the current authorization verification. In the case of a proof of age, these are therefore only information about the age of the user of the security element. Based on such data, however, a stolen or lost security element can not be identified. According to the principles of data economy, the following properties should always be met: Firstly, the security credentials of various service providers should not be correlated.
  • credentials of a security element should not be correlated with the same service provider, that is, the service should not detect whether two credentials originate from two different security elements or from the same security element.
  • Various methods for checking the validity of a security element are known in the prior art.
  • Underlying and security element contains an individual, secret RI key.
  • the security element calculates a kind of pseudonym from the RI base value and the RI key.
  • Each service provider then includes an individual list of pseudonyms of locked or withdrawn security elements from the revocation service.
  • This method has two major disadvantages: it only meets the first of the above-mentioned data economy characteristics. The second requirement, that credentials of the same security element can not be correlated with a service provider, is not met. On the other hand, the effort for the blocking service is very high since every service provider needs an individual revocation list for reasons of the present system architecture.
  • Another method meets data-saving needs
  • this method scales very poorly with the size of the revocation list because the security element must provide zero-knowledge evidence online for each entry in the revocation list.
  • the object of the present invention is therefore to propose a method and a system for checking the validity of a security element, which meets the requirements of data economy.
  • such a system can be implemented such that the computational effort in the security element can be minimized.
  • a preferred embodiment of a method for checking validity of a security element comprises the following steps:
  • a revocation service creates a revocation list.
  • Such a blacklist includes lock identifiers, each invalid, i. designate locked or withdrawn security elements.
  • each security element ie both the invalid security elements which are to be designated in the revocation list and security elements to be checked according to the present method, may comprise a unique identifier, for example a number or any other character string.
  • this identifier is referred to as a "blocking identity.”
  • a blocking identifier of the blocking list can correspond to such a blocking identity or be derived from such a blocking identity, for example by means of an encryption method or the like.
  • the revocation service then makes the revocation list available to corresponding auditing authorities. Alternatively, the blocking service may itself act as a reviewing entity instead of separate auditing entities or in addition to such auditing entities.
  • the safety element to be tested by a test instance determines a test identifier in a next step.
  • This check identifier is usually derived by a suitable operation, for example an encrypted message, from the above-mentioned check identity uniquely assigned to the security element.
  • test identifier By means of this test identifier, the security element to a certain extent with respect to the test instance for the purpose of validation. 15 The security element transfers the test identifier to the
  • the checking instance searches the blocking list to see whether it includes a blocking identifier corresponding to the checking identifier.
  • a lock identifier corresponds to the test identifier in particular
  • the checkpoint evaluates the security element as invalid, otherwise valid.
  • the test identifier is formed in such a way that it is not possible to deduce the identity of the security element from the test identifier. In other words, the security element remains anonymous and can not be identified by the check identifier.
  • the identity of the security element will not be recognizable, at least in the case where the revocation list does not include a revocation identifier corresponding to the validation identifier, i. in the case where the security element is valid.
  • the method offers the advantage that the requirements of data economy are met to the extent that a validity check can be carried out without the identity of the security element becoming recognizable.
  • the security element randomly determines the test identifier, ie when the test identifier is created, random data is included in the determination of the test identifier.
  • a basic idea of the invention thus consists in that a test identifier transmitted by a security element can be compared anonymously with a blocking list made available to the checking instance. Specifically, this can happen in different ways. In particular, this process can be used, which in the literature under the keyword "Searchable encryption” (to be translated as "searchable encryption”).
  • searchable encryption to be translated as "searchable encryption”
  • both lock identifiers and test identifiers are present as suitably encrypted data, which does not necessarily have to be decrypted for searching the block list.
  • the identity of the security element remains hidden in any case.
  • the blocking list may comprise a blocking identity for each blocked security element, for example in the form of a number or any character string which uniquely identifies the security element.
  • the revocation list includes the revocation identities in plain text.
  • a security element which identifies itself to a checking instance, forms the check identifier, for example, in that a corresponding check identity of the security element, which is given by the described number or character string, is subjected to a hash function. The hash value is then transferred to the test instance as test identifier.
  • the check instance then compares this hash value with corresponding ones
  • Hash values about the blocking identities of the revocation list can also be provided as a block list with a list of hash values via the blocking identities.
  • a hash value via a blocking identity matches the hash value via the check identity, it can be concluded that the check identity is equal to the blocking identity. This means that the tested security element has to be considered as blocked and thus invalid.
  • the checked security element is valid.
  • the identity of the security element in this case can not be recognized on the basis of the hash value-at least not if the security element is recognized as valid.
  • the test identifier can be determined randomly.
  • the security element forms the hash value, for example via a character string, which comprises the check identity and a random number.
  • the corresponding hash value and the random number are now transferred to the check instance as test identifiers.
  • the security element randomly identifies itself with a different check identifier at each validity check.
  • This first embodiment is also advantageous in that the calculations to be performed by the security element are minimal.
  • the security element merely has to form the hash value via the check identities or, in addition, additionally select a random number.
  • the search of the blocking list is carried out according to a PEKS method.
  • PEKS stands for "public key encryption with keyword search” and generally describes a procedure that allows a lot of encrypted keywords to be passed through. search without the content of the keywords becoming recognizable.
  • Such a PEKS process was first described by D. Boneh et al. in an article of the same name (Public Key Encryption with Key Word Search, in: Advances in Cryp- tology - EUROCRYPT 2004, International Conference on the- Theory and Applications of Cryptographic Techniques, Interlaken, Switzerland, May 2-6, 2004; 506-522).
  • a PEKS method is based on a known asymmetric encryption system, ie each user of the system has a public and a secret key.
  • the application described in the article differs fundamentally from the present application. The goal was to allow an e-mail provider to forward such e-mails, which contain a predefined keyword, to a recipient, ie an e-mail account owner, with the provider, provided that this is the case in that the e-mails are encrypted and that the provider should not receive any other information from the e-mail than whether the keyword unknown to the provider occurs therein or not.
  • the authors of the article describe a method in which an intended for the recipient e-mail using the public key of the recipient is encrypted, and attached by means of the public key encrypted, predetermined keywords of the e-mail.
  • Such encrypted by the public key of the recipient keyword is referred to as a PEKS token.
  • the receiver in turn provides the provider with a so-called trapdoor token, which is generated in a predefined manner on the basis of the predefined key word by means of the secret key of the recipient.
  • the provider can now identify from the trapdoor token whether that encrypted email includes a corresponding PEKS token.
  • the present invention makes use of such a PEKS method according to the second embodiment as follows.
  • the blocking service according to the invention corresponds to the owner of the e-mail account
  • the security element to be checked corresponds to the sender of an encrypted e-mail
  • a checking instance according to the invention corresponds to the e-mail provider.
  • a trapdoor token is used as the lock identifier in each case.
  • Trapdoor token corresponds to a blocking identity of a locked or withdrawn security element encrypted by means of a secret key of the blocking service.
  • the check identifier used is a PEKS token. Such includes an encrypted by a public key of the blocking service verification identity.
  • it is then checked whether a trapdoor token of the revocation list corresponds to the PEKS token, i. it is checked whether the check identity corresponds to the blocking identity.
  • the PEKS method comprises the following steps:
  • Two groups Gi and G2 of a given prime order p are provided as security parameters and a bilinear mapping e: Gi x Gi-G2.
  • This map e is preferably computable in polynomial time (in terms of the size of the input data). Furthermore, the map e should not be degenerate, ie that e (g, g) should be a generator of the group G 2 if g is a generator of the group Gi.
  • a hash function Hi ⁇ 0,1 ⁇ * -> Gi and a hash function H 2 : G 2 -> ⁇ 0, 1 ⁇ lo gp are provided.
  • the lock service generates a key pair (A pu b, A pr iv) as follows: An element e Z p is randomly selected and a generating element ge Gi.
  • a trapdoor token Tw for a blocking identity W'e ⁇ 0,1 ⁇ * is calculated by Hi (W ') a e Gi.
  • the security element transmits the test identifier to the checking instance via a secure data communication channel can be sure that the received test identifier has actually been generated and transmitted by the security element to be tested.
  • a corresponding data communication channel is preferably anonymous, i. constructed in such a way that the identity of the security element is not recognizable. Furthermore, the channel is used to carry out a data transmission, preferably encrypted.
  • a secured data communication channel can be produced, for example, by anonymously agreeing a session key between the security element to be checked and the checking instance on the basis of volatile key pairs, by means of which subsequent data communication can be encrypted.
  • the test identifier can be signed by the security element before it is transmitted to the checking instance.
  • a signature is used, based on which the Security element can not be identified, at least not by the auditing authority.
  • Suitable signature keys in this case are, for example, anonymous group keys.
  • UICC / SIM
  • the method is equally suitable for testing security elements in the form of software security modules.
  • a "trusted execution environment” (TEE) according to the "Global Platform Specification” or a virtual security element, for example in the form of a virtual mobile radio card (vSIM), can be mentioned here.
  • TEE trusted execution environment
  • vSIM virtual mobile radio card
  • a security element according to the invention is accordingly set up to be tested for validity in accordance with a method described above.
  • the security element is in particular configured to determine or calculate a corresponding check identifier, generally based on a check identity unambiguously assigned to the security item, and to assign the check identifier to a check identifier
  • the security element is preferably set up to randomly determine the test identifier.
  • test device for example a terminal or the like, is set up to check such a security element with regard to its validity in accordance with a method described above.
  • the test device is set up in particular, a block list of to receive the revocation service, at least in the event that the verifier does not itself agree with the revocation service.
  • the checking device is set up to search the blocking list according to whether it comprises a blocking identifier corresponding to the checking identifier received by the security element.
  • a locking device is arranged to support a described method for checking a validity of a security element.
  • the blocking device is set up to create and possibly to update the blocking list and to provide the blocking list to one or more checking devices.
  • the lock identities that are used to create the lock identifiers on the revocation list can access the lock service from different locations. Such blocking identities generally correspond to security elements that have been lost to the respective legitimate user, whether by ordinary loss, theft or otherwise.
  • a system according to the invention comprises a blocking device according to the invention, at least one testing device according to the invention and at least one security element according to the invention.
  • Figure 1 shows schematically elements of a preferred embodiment of a system according to the invention
  • FIG. 2 shows by way of example steps of a preferred embodiment of a method according to the invention.
  • a system 1000 which makes it possible to test a validity of a security element 10 by a test device 100, comprises a memory device 200, generally a plurality of test devices 100, 100 at least temporarily connected to the barrier device 200 ', 100 "and at least one security element 10.
  • the blocking device 200 can be assigned to different instances. If, for example, identity cards or passports are to be checked for validity as security elements 10, the blocking device 200 may be subordinate to a government agency. The functionalities of the blocking device 200 will be described below with reference to FIG. The same applies to the testing devices 100, 100 ', 100 "and the security element 10.
  • the services of the service provider can also vary.
  • the checking devices 100 can be used, for example, at border crossings or the like be arranged.
  • the security elements can be designed as hardware security modules, as software security modules or as a combination of hardware and software security module.
  • security modules are smart cards, USB tokens, RFID tokens, NFC modules, trusted platform Modules (TPM), mobile radio cards (UICC / SIM) and the like in the class of hardware security modules and a "trusted execution environment" (TEE) according to the "Global Platform Specification", which as a combination of hardware and software security module or as pure software security module can be designed.
  • TEM trusted execution environment
  • the last-mentioned class includes, for example, a virtual security element, for example in the form of a virtual mobile communications card (vSIM).
  • vSIM virtual mobile communications card
  • FIG. 2 shows steps of a preferred embodiment of a method for checking the validity of a security element 10.
  • Each security element 10 is identified by a security element 10 uniquely assigned identity. Such identity may be given for example by a number or any character string. If a user of a security element 10, for example an identity card, the security element 10 is stolen or the user loses the security element 10, he can inform the blocking device 200 about it, d. H. it communicates the identity of the security element to the blocking device 200. The blocking device 200 then takes this identity, which will henceforth be called a blocking identity, as described with reference to step S1.
  • step S2 the blocking device 200 creates a revocation list based on all the blocking identities received in step S1.
  • This revocation list includes revocation subscribers, each invalid, ie. H. designate as blocked or withdrawn security elements.
  • the blocking identifiers can correspond to the blocking identities received or else from these be derived suitable.
  • the lock identifiers are present in the blocking list in encrypted form, for example in the form of the trapdoor token described in detail above.
  • a trapdoor token is created by encrypting the blocking identity according to a predetermined mathematical procedure using a secret key assigned to the blocking device 200. This secret key together with a public key forms a key pair of the locking device 200.
  • step S3 the lock device 200 provides the created lock list to the various test devices 100, 100 ', 100 "From time to time, the lock list may be updated by the lock device 200, for example, when other lock identities have been received Block list can then be forwarded to the test devices 100, 100 ', 100 ".
  • a tester 100 checks the validity of a security element 10 in the following manner.
  • step S4 a secured data communication channel is established between the test apparatus 100 and the security element 10.
  • the security element 10 determines a check identifier which serves to "identify" the security element 10 in the context of the checking procedure
  • the check identifier is formed by the security element 10 such that the identity of the security element 10 can not be deduced from the check identifier .
  • the security element 10 may calculate the check identifier as a PEKS token.
  • an identity that uniquely identifies the security element, the verification identity for example in the form of a number or a character string, is encrypted in a suitable manner described above in detail by means of the public key of the blocking device 200.
  • blocking identity and “testing identity” refer to the same concepts, i. are designated like identifiers.
  • a security element noted on the blacklist is referred to as a "blackout identity”, but as a "check identity” with respect to a currently-audited security element. If it is determined that the "check identity" corresponds to a "blocking identity", i.
  • the security element 10 transmits the check identifier to the checking device 100.
  • the security element 10 may suitably digitally sign the check designator beforehand preferably to use an anonymous signature, for example a signature generated by means of a group key.
  • step S7 the verifying means 100 searches the revocation list received in step S3, and checks, as indicated with respect to step S8, whether the revocation list includes a revocation identifier corresponding to the check identifier received from the security element 10 in step S6. In this case, an inspection If the check identifier is derived from a check identity that is similar to the trap identity from which the corresponding lock identifier was derived. As described above several times, according to various embodiments, a correspondence between the test identifier and the lock identifier can be recognized without the test identity becoming recognizable.
  • step S9 If a blocking identifier corresponding to the test identifier is present in the block list, the security element 10 is declared invalid in step S9. On the other hand, if no blocking identifier corresponding to the test identifier is found in the block list, then the test device 100 is in step S10, the security element 10 as valid.
  • the described method is characterized in particular by the fact that the identity of the security element 10 can not be determined on the basis of the check identifier. If necessary, in the cases in which the security element 10 has been recognized as invalid, the verification identity of the security element 10 may appear in clear text, depending on the search method used. As a rule, however, both the revocation labels of the revocation list and the test identifiers of the inspection facility are available only in encrypted form.
  • the checking device searches the blocking list by means of a suitable "searchable encryption" method adapted to the respective encryption according to a blocking identifier corresponding to the checking identifier.
  • the security element In the case of a lost and found again security element, the security element is first locked, so the lock identifier published in the blacklist, and then unlocked again, so the lock identifier deleted again in the blacklist. For all check instances, which have noticed the deleted entry, now the anonymity of the security element would be lost.
  • the auditor receives the audit identifier and can use the undeleted entry to identify the identity of the security element.
  • the system can therefore be improved if the blocking service 200 assigns a new blocking identity to the formerly blocked security element 10.
  • the revocation service 200 may notify the security element 10 of the new identity.
  • the blocking service 200 can periodically assign a new blocking identity to a security element 10.
  • the blocking identity can be changed every day, week, or month.
  • the blocking identity is derived from a time specification, such as the day, the week, the month, or the date.
  • the blocking identity can be changed periodically, in parallel (that is, independently of each other) in the blocking service and in the security element. Alternatively or in addition to a periodic change, a "challenge" t assigned by the revocation service could also be used. a random or pseudorandom value to send to the security element. The security element checks that the value t has not yet been used to create an identity.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Algebra (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Ein Verfahrens zur Prüfung einer Gültigkeit eines Sicherheitselements (10) umfasst die folgenden Schritte: Durch einen Sperrdienst (200) wird eine Sperrliste erstellt (S2), welche Sperrbezeichner umfasst, die jeweils ungültige, Sicherheitselemente bezeichnen. Die Sperrliste wird einer Prüfinstanz (100) bereitgestellt (S3). Das zu prüfende Sicherheitselement (10) bestimmt (S5) einen Prüfbezeichner und überträgt (S6) diesen an die Prüfinstanz, welche (S7) die Sperrliste danach durchsucht, ob darin ein dem Prüfbezeichner entsprechenden Sperrbezeichner vorliegt (S8). Falls ja, so gilt das Sicherheitselement als ungültig (S9), ansonsten als gültig (S10). Der Prüfbezeichner wird derart gebildet, dass aus dem Prüfbezeichner nicht auf die Identität des Sicherheitselements zurückgeschlossen werden kann. Beim Durchsuchen der Sperrliste wird die Identität des Sicherheitselements zumindest in dem Fall nicht erkennbar, in dem die Sperrliste keinen dem Prüfbezeichner entsprechenden Sperrbezeichner umfasst.

Description

R e v o k a t i o n e i n e s S i c h e r h e i t s e 1 e m e n t s Die vorliegende Erfindung betrifft die Revokation von Sicherheitselementen. Genauer betrifft die Erfindung ein Verfahren zur Prüfung einer Gültigkeit eines Sicherheitselements sowie ein entsprechendes Sicherheitselement, eine Prüfeinrichtung sowie eine Sperreinrichtung, welche geeignet sind, ein entsprechendes Verfahren durchzuführen.
Um ein gestohlenes oder verlorengegangenes Sicherheitselement, beispielsweise einen Personalausweis, sperren zu können, muss das Sicherheitselement von einem Dienstanbieter, beispielsweise einem Onlinedienst, dem das Sicherheitselement präsentiert wird, eindeutig identifiziert werden können. In vielen Fällen allerdings werden Sicherheitselemente lediglich im Zusammenhang mit anonymen Berechtigungsnachweisen verwendet, beispielsweise als Altersnachweis. Aus Gründen der Datensparsamkeit werden in der Regel von einem Sicherheitselement stets lediglich solche Daten an den Dienstanbieter übertragen, die im Rahmen des aktuellen Berechtigungs- nachweises notwendig sind. Im Falle eines Altersnachweises sind dies somit lediglich Angaben über das Alter des Nutzers des Sicherheitselements. Anhand solcher Daten kann ein gestohlenes oder verloren gegangenes Sicherheitselement aber nicht identifiziert werden. Gemäß den Prinzipien der Datensparsamkeit sollen stets folgende Eigenschaften erfüllt sein: Zum einen sollen Berechtigungsnachweise von Sicherheitselementen bei verschiedenen Dienstanbietern nicht korreliert werden können. Zum anderen sollen Berechtigungsnachweise eines Sicherheitselements bei demselben Dienstleister ebenso wenig korreliert werden können, d.h. der Dienst soll nicht erkennen, ob zwei Berechtigungsnachweise von zwei verschiedenen Sicherheitselementen stammen oder von ein- und demselben Sicherheitselement. Im Stand der Technik sind verschiedene Verfahren zum Prüfen der Gültigkeit eines Sicherheitselements bekannt.
Gemäß der Spezifikation TR 03110 des Bundesamtes für Sicherheit in der Informationstechnik ist ein so genanntes„Restricted Identification (RI) Pro- tocol" bekannt. Dabei erhält jeder Dienstanbieter einen individuellen RI-
Basiswert und das Sicherheitselement enthält einen individuellen, geheimen Rl-Schlüssel. Das Sicherheitselement berechnet aus dem RI-Basiswert und dem Rl-Schlüssel eine Art Pseudonym. Jeder Dienstanbieter enthält von dem Sperrdienst dann eine individuelle Liste von Pseudonymen gesperrter oder zurückgezogener Sicherheitselemente. Dieses Verfahren hat zwei wesentliche Nachteile: es erfüllt lediglich die erste der vorstehend genannten Eigenschaften der Datensparsamkeit. Die zweite Anforderung, wonach Berechtigungsnachweise desselben Sicherheitselements bei einem Dienstanbieter nicht korreliert werden können, ist nicht erfüllt. Zum anderen ist der Auf- wand für den Sperrdienst sehr hoch, da jeder Dienstanbieter auf Gründen der vorliegenden Systemarchitektur eine individuelle Sperrliste benötigt.
Ein anderes Verfahren, gemäß dem EPID- Protokoll („Enhanced Privacy ID from Bilinear Pairing", Ernie Brickell, Jiangtao Li; vgl. http: / / eprint.iacr.org/ 2009/095.pdf), erfüllt zwar die Anforderungen der Datensparsamkeit. Jedoch skaliert dieses Verfahren sehr schlecht mit der Größe der Sperrliste, da das Sicherheitselement online für jeden Eintrag der Sperrliste einen Zero- Knowledge-Beweis führen muss. Aufgabe der vorliegenden Erfindung ist es demnach, ein Verfahren und ein System zur Prüfung der Gültigkeit eines Sicherheitselements vorzuschlagen, welches den Anforderungen der Datensparsamkeit genügt. Vorzugsweise ist ein solches System derart implementierbar, dass der Rechenaufwand im Si- cherheitselement minimiert werden kann.
Diese Aufgabe wird durch ein Verfahren, ein Sicherheitselement, eine Prüfeinrichtung, eine Sperreinrichtung sowie ein System mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen und Weiter- bildungen sind in den abhängigen Ansprüchen angegeben.
Eine bevorzugte Ausführungsform eines Verfahrens zur Prüfung einer Gültigkeit eines Sicherheitselements umfasst die folgenden Schritte: Durch einen Sperrdienst wird eine Sperrliste erstellt. Eine solche Sperrliste umfasst Sperrbezeichner, welche jeweils ungültige, d.h. gesperrte oder zurückgezogene Sicherheitselemente bezeichnen.
Dabei ist zu erwähnen, dass jedes Sicherheitselement, d.h. sowohl die ungül- tigen Sicherheitselemente, welche in der Sperrliste bezeichnet werden sollen, als auch gemäß dem vorliegenden Verfahren zu prüfende Sicherheitselemente, einen eindeutigen Bezeichner umfassen kann, beispielweise eine Zahl oder eine beliebige andere Zeichenkette. Im Zusammenhang mit einem gesperrten Sicherheitselement wird dieser Bezeichner als„Sperridentität" be- zeichnet. Im Zusammenhang mit einem zu prüfenden Sicherheitselement - zur begrifflichen Unterscheidung - als„Prüfidentität". Ein Sperrbezeichner der Sperrliste kann dabei einer solchen Sperridentität entsprechen oder von einer solchen Sperridentität abgeleitet worden sein, beispielsweise mittels eines Verschlüsselungsverfahrens oder dergleichen. Der Sperrdienst stellt die Sperrliste anschließend entsprechenden Prüfinstanzen bereit. Der Sperrdienst kann alternativ selbst, d.h. anstelle separater Prüfinstanzen, oder zusätzlich zu solchen Prüfinstanzen als Prüf instanz tätig 5 sein.
Das durch eine Prüfinstanz zu prüfende Sicherheitselement bestimmt in einem nächsten Schritt einen Prüfbezeichner. Dieser Prüfbezeichner wird in der Regel durch eine geeignete Operation, beispielsweise eine Verschlüsselt) l ng, aus der vorstehend erwähnten, dem Sicherheitselement eindeutig zugeordneten Prüf Identität abgeleitet.
Mittels dieses Prüfbezeichners weist sich das Sicherheitselement gegenüber der Prüfinstanz zum Zwecke der Gültigkeitsprüfung gewissermaßen aus. 15 Das Sicherheitselement überträgt den Prüfbezeichner dazu an die
Prüfinstanz.
Die Prüfinstanz durchsucht in einem weiteren Schritt die Sperrliste danach, ob diese einen dem Prüfbezeichner entsprechenden Sperrbezeichner umf asst. 20 Ein Sperrbezeichner entspricht dabei dem Prüfbezeichner insbesondere
dann, wenn die Sperridentität, von der der Sperrbezeichner abgeleitet worden ist, gleich der Prüfidentität ist, von der der Prüfbezeichner abgeleitet worden ist.
25 Umfasst die Sperrliste einen dem Prüfbezeichner entsprechenden Sperrbezeichner, so bewertet die Prüfinstanz das Sicherheitselement als ungültig, ansonsten als gültig. Der Prüfbezeichner wird dabei derart gebildet, dass aus dem Prüfbezeichner nicht auf die Identität des Sicherheitselements zurückgeschlossen werden kann. Mit anderen Worten bleibt das Sicherheitselement anonym und kann anhand des Prüfbezeichners nicht identifiziert werden.
Auch beim Durchsuchen der Sperrliste wird die Identität des Sicherheitselements zumindest in dem Fall nicht erkennbar, in dem die Sperrliste keinen dem Prüfbezeichner entsprechenden Sperrbezeichner umfasst, d.h. in dem Fall, in dem das Sicherheitselement gültig ist.
Das Verfahren bietet demnach den Vorteil, dass die Anforderungen der Datensparsamkeit insoweit erfüllt sind, dass eine Gültigkeitsprüfung durchgeführt werden kann, ohne dass die Identität des Sicherheitselements dabei erkennbar wird.
Gemäß einer bevorzugten Ausführungsform des Verfahrens bestimmt das Sicherheitselement den Prüfbezeichner randomisiert, d.h. beim Erstellen des Prüfbezeichners gehen Zufallsdaten mit in die Bestimmung des Prüfbezeichners ein. Auf diese Weise wird es ermöglicht, dass auch die beiden vorge- nannten Anforderungen der Datensparsamkeit erfüllt werden können. D.h. Berechtigungsnachweise eines Sicherheitselements können sowohl bei verschiedenen als auch bei ein- und demselben Dienstanbieter nicht korreliert werden. Ein Grundgedanke der Erfindung besteht somit darin, dass ein von einem Sicherheitselement übertragener Prüfbezeichner anonym mit einer der Prüfinstanz zur Verfügung gestellten Sperrliste abgeglichen werden kann. Konkret kann dies auf verschiedene Arten geschehen. Insbesondere können hierzu Verfahren verwendet, welche in der Literatur unter dem Stichwort „searchable encryption" (etwa mit„durchsuchbare Verschlüsselung" zu übersetzen) zusammengefasst werden. Dabei liegen in der Regel sowohl Sperrbezeichner als auch Prüfbezeichner als geeignet verschlüsselte Daten vor, welche zum Durchsuchen der Sperrliste nicht notwendigerweise ent- schlüsselt werden müssen. In der Regel bleibt die Identität des Sicherheitselements in jedem Fall verborgen.
Bevorzugte Ausführungsformen des Verfahrens werden im Folgenden knapp und lediglich exemplarisch dargestellt.
Gemäß einer ersten, sehr einfachen Ausführungsform kann die Sperrliste für jedes gesperrte Sicherheitselement eine Sperridentität umfassen, beispielsweise in Form einer Zahl oder einer beliebigen Zeichenkette, welche das Sicherheitselement eindeutig bezeichnet. Mit anderen Worten umfasst die Sperrliste die Sperridentitäten im Klartext.
Ein Sicherheitselement, welches sich gegenüber einer Prüfinstanz ausweist, bildet gemäß dieser Ausführungsform den Prüfbezeichner beispielsweise dadurch, dass eine entsprechende Prüfidentität des Sicherheitselements, wel- che durch die beschriebene Zahl oder Zeichenkette gegeben ist, einer Hash- funktion unterzogen wird. Der Hashwert wird dann als Prüfbezeichner an die Prüf instanz übertragen.
Die Prüfinstanz vergleicht dann diesen Hashwert mit entsprechenden
Hashwerten über die Sperridentitäten der Sperrliste. Alternativ kann der Prüfeinrichtung als Sperrliste auch bereits eine Liste von Hashwerten über die Sperridentitäten bereitgestellt werden. In dem Fall, dass ein Hashwert über eine Sperridentität mit dem Hashwert über die Prüf identität übereinstimmt, kann gefolgert werden, dass die Prüfidentität gleich der Sperridenti- tät ist, d.h. dass das geprüfte Sicherheitselement als gesperrt und somit als ungültig zu gelten hat. Im gegenteiligen Fall, dass keiner der Hashwerte über die Sperridentitäten mit dem Hashwert über die Prüfidentität übereinstimmt, gilt das geprüfte Sicherheitselement als gültig. Weiterhin kann die Identität des Sicherheitselements in diesem Fall anhand des Hashwertes nicht erkannt werden - zumindest dann nicht, wenn das Sicherheitselement als gültig erkannt wird.
Gemäß einer Variante dieser Ausführungsform kann der Prüfbezeichner randomisiert bestimmt werden. Dabei bildet das Sicherheitselement den Hashwert beispielsweise über eine Zeichenkette, welche die Prüfidentität und eine Zufallszahl umfasst. Als Prüfbezeichner werden nun der entsprechende Hashwert und die Zufallszahl an die Prüfinstanz übertragen. Diese bildet in analoger Weise Hashwerte über die Sperridentitäten in Verbindung mit der Zufallszahl und vergleicht die resultierenden Hashwerte mit dem empfangenen Hashwert. Gemäß dieser Variante weist sich das Sicherheitselement randomisiert bei jeder Gültigkeitsprüfung mit einem anderen Prüfbezeichner aus. Diese erste Ausführungsform ist auch dahingehend vorteilhaft, dass die durch das Sicherheitselement durchzuführenden Berechnungen minimal sind. Das Sicherheitselement muss zum Bilden des Prüfbezeichners lediglich den Hashwert über die Prüfidentitäten bilden bzw. vorab zusätzlich eine Zufallszahl wählen.
Gemäß einer zweiten bevorzugten Variante erfolgt das Durchsuchen der Sperrliste gemäß einem PEKS- Verfahren. PEKS steht dabei für„public key encryption with keyword search" und beschreibt allgemein ein Verfahren, welches es ermöglicht, eine Menge verschlüsselter Schlüsselwörter zu durch- suchen, ohne dass der Inhalt der Schlüsselwörter erkennbar wird. Ein solches PEKS- Verfahren wurde erstmals von D. Boneh et al. in einem gleichnamigen Artikel (Public Key Encryption with Key word Search; in: Advances in Cryp- tology - EUROCRYPT 2004, International Conference on the Theory and Ap- plications of Cryptographic Techniques, Interlaken, Switzerland, May 2-6, 2004; pp. 506-522) beschrieben.
Ein PEKS- Verfahren beruht grundsätzlich auf einem bekannten asymmetrischen Verschlüsselungssystem, d.h. jeder Verwender des Systems besitzt ei- nen öffentlichen und einen geheimen Schlüssel. Die in dem Artikel beschriebene Anwendung unterscheidet sich grundsätzlich von der hier vorliegenden Anwendung. Ziel war es dort, einem E-Mail Provider zu erlauben, solche E-Mails, die ein vorgegebenes Schlüsselwort umfassen, einem Empfänger, d.h. einem Besitzer eines E-Mail Accounts bei dem Provider, gezielt wei- terleiten zu können, allerdings unter der Voraussetzung, dass die E-Mails verschlüsselt vorliegen, und dass der Provider keine andere Information aus der E-Mail erhalten soll, als die, ob das - dem Provider unbekannte - Schlüsselwort darin vorkommt oder nicht. Die Autoren des Artikels beschreiben ein Verfahren, in dem eine für den Empfänger bestimmte E-Mail mittels des öffentlichen Schlüssels des Empfängers verschlüsselt wird, und mittels des öffentlichen Schlüssels verschlüsselte, vorgegebene Schlüsselwörter der E-Mail angehängt werden. Ein solches mittels des öffentlichen Schlüssels des Empfängers verschlüsseltes Schlüsselwort wird als PEKS-Token bezeichnet. Der Empfänger wiederum stellt dem Provider ein so genanntes Trapdoor-Token bereit, welches auf Basis des vorgegebenen Schlüsselwortes mittels des geheimen Schlüssels des Empfängers in vorgegebener Weise erzeugt wird. Der Provider kann nun anhand des Trapdoor-Tokens erkennen, ob eine für den Empfänger be- stimmte, verschlüsselte E-Mail ein entsprechendes PEKS-Token umfasst. Die zu Grunde liegenden mathematischen Einzelheiten sollen an dieser nicht weiter diskutiert werden. Im Folgenden finden sich Einzelheiten mit Bezug auf eine bevorzugte Variante.
Die vorliegende Erfindung macht sich gemäß der zweiten Ausführungsform ein solches PEKS- Verfahren wie folgt zu Nutze. Der erfindungsgemäße Sperrdienst entspricht dabei dem Besitzer des E-Mail- Accounts, das zu prüfende Sicherheitselement dem Sender einer verschlüsselten E-Mail und eine erfindungsgemäße Prüfinstanz entspricht dem E-Mail-Provider.
Wird ein PEKS- Verfahren im Zusammenhang mit dem vorliegenden Verfahren zur Prüfung einer Gültigkeit eines Sicherheitselements verwendet, so wird jeweils ein Trapdoor-Token als Sperrbezeichner verwendet. Ein
Trapdoor-Token entspricht dabei einer mittels eines geheimen Schlüssels des Sperrdienstes verschlüsselten Sperridentität eines gesperrten oder zurückgezogenen Sicherheitselements. Auf der anderen Seite wird als Prüfbezeichner ein PEKS-Token verwendet. Ein solches umfasst eine mittels eines öffentlichen Schlüssels des Sperrdienstes verschlüsselte Prüfidentität. Im Rahmen des PEKS- Verfahrens wird dann geprüft, ob ein Trapdoor-Token der Sperrliste dem PEKS-Token entspricht, d.h. es wird geprüft, ob die Prüfidentität der Sperridentität entspricht.
Gemäß einer bevorzugten Variante, welche im Wesentlichen in dem vorste- hend angegebenen Artikel beschrieben ist, umfasst das PEKS- Verfahren folgende Schritte:
Es werden zwei Gruppen Gi und G2 einer vorgegebenen Primzahlordnung p als Sicherheitsparameter bereitgestellt sowie eine bilineare Abbildung e: Gi x Gi—► G2. Diese Abbildung e ist vorzugsweise in polynomieller Zeit (bezüglich der Größe der Eingabedaten) berechenbar. Weiterhin sollte die Abbildung e nicht degeneriert sein, d.h. dass e(g, g) ein Erzeuger der Gruppe G2 sein sollte, wenn g ein Erzeuger der Gruppe Gi ist.
Weiterhin werden eine Hashfunktion Hi: {0,1}*— > Gi und eine Hashfunktion H2: G2->{0,l}log p bereitgestellt.
Der Sperrdienst erzeugt ein Schlüsselpaar (Apub, Apriv) wie folgt: Es wird ein Element e Zp zufällig gewählt sowie ein erzeugendes Element g e Gi.
Der öffentliche Schlüssel Apub wird gesetzt als Apub := [g, h= ga] und der geheime Schlüssel Apriv wird gesetzt als Apriv := ct.
Das Bestimmen eines PEKS-Tokens PEKS( Apub, W) für eine Prüfidentität W e {0,1}* umfasst die folgenden Schritte: Es wird ein Wert t := e(Hi(W), hr) e G2 für ein zufällig gewähltes Zp berechnet. Das PEKS-Token wird dann bestimmt als PEKS(Apub, W) := [gr, H2(t)].
Ein Trapdoor-Token Tw für eine Sperridentität W'e {0,1}* wird berechnet vermöge Hi(W')a e Gi.
Die Sperrliste wird dann durchsucht, indem für jedes Trapdoor-Token Tw' und das PEKS-Token S = [A, B] der folgende Test(Apub, S, Tw) durchgeführt wird:
- Prüfe, ob H2(e(Tw, A) = B;
Falls ja, so gilt W = W',
sonst W W. Im Zusammenhang mit dem vorstehend spezifisch beschriebenen PEKS- Verfahren ist es vorteilhaft, wenn ein zu prüfendes Sicherheitselement bereits mit dem Wert t' = e(H1(W), h) personalisiert wird. Auf diese Weise muss das Sicherheitselement zum Berechnen des Wertes t zum Bestimmen des PEKS-Tokens, wegen der Bilinearität der Funktion e und der Identität e(Hi( W), hr) = e(Hi(W), h) r, lediglich noch ein r e Z* zufällig wählen und den Wert (t')r berechnen. Diese Berechnung kann ressourcenschonend erfolgen, im Vergleich zu einer aufwändigen Berechnung der„pairing" -Funktion e. Vorzugsweise überträgt das Sicherheitselement den Prüfbezeichner über einen gesicherten Datenkommunikationskanal an die Prüfinstanz. Auf diese Weise können Manipulationen des Verfahrens vermieden werden. D. h. die Prüfinstanz kann sicher sein, dass der empfangene Prüfbezeichner tatsächlich von dem zu prüfenden Sicherheitselement erzeugt und übertragen wor- den ist.
Ein entsprechender Datenkommunikationskanal ist dabei vorzugsweise anonym, d.h. derart aufgebaut, dass die Identität des Sicherheitselements nicht erkennbar wird. Weiterhin dient der Kanal dazu, eine Datenübertra- gung gesichert, vorzugsweise verschlüsselt, durchzuführen. Ein derart gesicherter Datenkommunikationskanal kann beispielsweise dadurch hergestellt werden, dass zwischen dem zu prüfenden Sicherheitselement und der Prüfinstanz auf der Basis flüchtiger Schlüsselpaare anonym ein Sitzungsschlüssel vereinbart wird, mittels dessen eine nachfolgende Datenkommuni- kation verschlüsselt werden kann.
Alternativ oder zusätzlich kann der Prüfbezeichner von dem Sicherheitselement signiert werden, bevor dieser an die Prüfinstanz übertragen wird. Auch hier ist es bevorzugt, dass eine Signatur verwendet wird, anhand derer das Sicherheitselement nicht identifiziert werden kann, zumindest nicht durch die Prüfinstanz. Geeignete Signaturschlüssel sind in diesem Fall beispielsweise anonyme Gruppenschlüssel. Mittels des beschriebenen Verfahrens lassen sich verschiedenste Sicherheitselemente hinsichtlich ihrer Gültigkeit prüfen. Auf der einen Seite können Sicherheitselemente in Form von Hardware-Sicherheitsmodulen geprüft werden. Dies betrifft beispielsweise Smart-Cards, USB-Token, RFID-Token, NFC-Module, Trusted-Plattform Module (TPM), Mobilfunkkarten
(UICC/SIM) und dergleichen. Auf der anderen Seite eignet sich das Verfahren in gleicher Weise zur Prüfung von Sicherheitselementen in Form von Software-Sicherheitsmodulen. Genannt werden können hier beispielsweise ein„trusted execution environment" (TEE) gemäß der„Global Platform Spe- cification" oder ein virtuelles Sicherheitselement, beispielsweise in Form ei- ner virtuellen Mobilfunkkarte (vSIM).
Ein erfindungsgemäßes Sicherheitselement ist demnach eingerichtet, gemäß einem vorstehend beschriebenen Verfahren hinsichtlich seiner Gültigkeit geprüft zu werden. Mit anderen Worten ist das Sicherheitselement insbeson- dere eingerichtet, einen entsprechenden Prüfbezeichner, in der Regel ausgehend von einer dem Sicherheitselement eindeutig zugeordneten Prüf Identität, zu bestimmen oder zu berechnen und den Prüfbezeichner an eine
Prüfinstanz zu übertragen. Vorzugsweise ist das Sicherheitselement eingerichtet, den Prüfbezeichner randomisiert zu bestimmen.
Eine erfindungsgemäße Prüfeinrichtung, beispielsweise ein Terminal oder dergleichen, ist eingerichtet, ein solches Sicherheitselement hinsichtlich seiner Gültigkeit gemäß einem vorstehend beschriebenen Verfahren zu prüfen. Dazu ist die Prüfeinrichtung insbesondere eingerichtet, eine Sperrliste von dem Sperrdienst zu empfangen, zumindest in dem Fall, dass die Prüfeinrichtung nicht selbst mit dem Sperrdienst übereinstimmt. Weiterhin ist die Prüfeinrichtung eingerichtet, die Sperrliste danach zu durchsuchen, ob diese einen dem von dem Sicherheitselement empfangenen Prüfbezeichner entsprechenden Sperrbezeichner umfasst.
Eine erfindungsgemäße Sperreinrichtung ist eingerichtet zum Unterstützen eines beschriebenen Verfahrens zum Prüfen einer Gültigkeit eines Sicherheitselements. Mit anderen Worten ist die Sperreinrichtung eingerichtet zum Erstellen und gegebenenfalls zum Aktualisieren der Sperrliste sowie zum Bereitstellen der Sperrliste an ein oder mehrere Prüfeinrichtungen. Die Sperridentitäten, auf deren Basis die Sperrbezeichner der Sperrliste erstellt werden, können dem Sperrdient von verschiedenen Stellen zugehen. Solche Sperridentitäten entsprechen in der Regel Sicherheitselementen, die dem jeweiligen legitimen Nutzer abhanden gekommen sind, sei es durch gewöhnlichen Verlust, Diebstahl oder auf sonstige Weise.
Ein erfindungsgemäßes System schließlich umfasst eine erfindungsgemäße Sperreinrichtung, zumindest eine erfindungsgemäße Prüfeinrichtung sowie zumindest ein erfindungsgemäßes Sicherheitselement.
Im Folgenden wird die vorliegende Erfindung mit Bezug auf die beiliegenden Zeichnungen beispielhaft beschrieben. Darin zeigen:
Figur 1 schematisch Elemente einer bevorzugten Ausführungsform eines erfindungsgemäßen Systems und
Figur 2 exemplarisch Schritte einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens. Wie in Figur 1 Schema tisch dargestellt, umfasst ein System 1000, welches eine Prüfung einer Gültigkeit eines Sicherheitselements 10 durch eine Prüfein- richtung 100 ermöglicht, eine Speichereinrichtung 200, in der Regel eine Mehrzahl von mit der Sperreinrichtung 200 zumindest temporär verbundenen Prüfeinrichtungen 100, 100' ,100" sowie zumindest ein Sicherheitselement 10.
Je nach der Art der zu prüfenden Sicherheitselemente kann die Sperreinrich- tung 200 verschiedenen Instanzen zugeordnet sein. Sollen als Sicherheitselemente 10 beispielsweise Personalausweise oder Reisepässe auf ihre Gültigkeit geprüft werden, so kann die Sperreinrichtung 200 einer staatlichen Stelle untergeordnet sein. Die Funktionalitäten der Sperreinrichtung 200 werden nachfolgend mit Bezug auf Figur 2 beschrieben. Das Gleiche gilt für die Prüfeinrichtungen 100, 100', 100" und das Sicherheitselement 10.
Die Prüfeinrichtungen 100, 100', 100" können als Terminals eines Dienstanbieters ausgebildet sein. Je nach Art der zu prüfenden Sicherheitselemente können auch die Dienste des Dienstanbieters variieren. Im Zusammenhang mit der Prüfung von Personalausweisen oder Reisepässen können die Prüfeinrichtungen 100 beispielsweise an Grenzübergängen oder dergleichen angeordnet sein.
Mit dem nachfolgend exemplarisch beschriebenen Verfahren können ver- schiedenste Sicherheitselemente hinsichtlich ihrer Gültigkeit geprüft werden. Die Sicherheitselemente können dabei als Hardware-Sicherheitsmodule, als Software-Sicherheitsmodule oder als eine Kombination von Hard- und Software-Sicherheitsmodul ausgebildet sein. Beispiele solcher Sicherheitsmodule sind Smart-Cards, USB-Token, RFID-Token, NFC-Module, Trusted-Plattform Module (TPM), Mobilfunkkarten (UICC/SIM) und dergleichen in der Klasse der Hardware-Sicherheitsmodule sowie ein„trusted execution environment" (TEE) gemäß der„Global Platform Specification", welches als Kombination eines Hard- und Software-Sicherheitsmoduls oder als reines Software- Sicherheitsmodul ausgebildet sein kann. Zur letztgenannten Klasse zählt beispielsweise ein virtuelles Sicherheitselement, beispielsweise in Form einer virtuellen Mobilfunkkarte (vSIM).
Figur 2 zeigt Schritte einer bevorzugten Ausführungsform eines Verfahrens zur Prüfung einer Gültigkeit eines Sicherheitselements 10.
Jedes Sicherheitselement 10 ist über eine dem Sicherheitselement 10 eindeutig zugeordnete Identität gekennzeichnet. Eine solche Identität kann beispielsweise durch eine Zahl oder eine beliebige Zeichenkette gegeben sein. Wird einem Nutzer eines Sicherheitselements 10, beispielsweise eines Personalausweises, das Sicherheitselement 10 gestohlen oder verliert der Nutzer das Sicherheitselement 10, so kann er die Sperreinrichtung 200 darüber informieren, d. h. er übermittelt die Identität des Sicherheitselement an die Sperreinrichtung 200. Die Sperreinrichtung 200 nimmt dann diese Identität, die fortan Sperridentität genannt wird, entgegen, wie dies mit Bezug auf Schritt Sl gezeigt ist.
In Schritt S2 erstellt die Sperreinrichtung 200 auf Basis aller in Schritt Sl empfangenen Sperridentitäten eine Sperrliste. Diese Sperrliste umfasst Sperrbe- Zeichner, welche jeweils ungültige, d. h. als gesperrt oder zurückgezogen anzusehende Sicherheitselemente bezeichnen.
Im Rahmen des konkret verwendeten Verfahrens können die Sperr bezeich- ner den empfangenen Sperridentitäten entsprechen oder aber von diesen geeignet abgeleitet sein. In der Regel liegen die Sperrbezeichner in der Sperrliste in verschlüsselter Form vor, beispielsweise in Form vorstehend im Detail beschriebener Trapdoor-Token. Ein Trapdoor-Token entsteht dadurch, dass die Sperridentität gemäß einem vorgegebenen mathematischen Verfah- ren unter Verwendung eines geheimen, der Sperreinrichtung 200 zugeordneten Schlüssels verschlüsselt wird. Dieser geheime Schlüssel bildet zusammen mit einem öffentlichen Schlüssel ein Schlüsselpaar der Sperreinrichtung 200.
In Schritt S3 stellt die Sperreinrichtung 200 die erstellte Sperrliste den ver- schiedenen Prüfeinrichtungen 100, 100', 100" zur Verfügung. Von Zeit zu Zeit kann die Sperrliste von der Sperreinrichtung 200 aktualisiert werden, beispielsweise wenn weitere Sperr Identitäten empfangen worden sind. Eine aktualisierte Sperrliste kann den Prüfeinrichtungen 100, 100', 100" dann wiederum zugeleitet werden.
Wie mit Bezug auf die Schritte S4 bis S10 dargestellt, prüft eine Prüfeinrichtung 100 die Gültigkeit eines Sicherheitselements 10 in der folgenden Weise.
In Schritt S4 wird ein gesicherter Datenkommunikationskanal zwischen der Prüfeinrichtung 100 und dem Sicherheitselement 10 hergestellt. Auf diese Weise kann die Prüfeinrichtung 100 sicherstellen, dass ein nachfolgend von dem Sicherheitselement 10 empfangener Prüfbezeichner tatsächlich von dem zu prüfenden Sicherheitselement 10 stammt. In Schritt S5 bestimmt das Sicherheitselement 10 einen Prüfbezeichner, welcher dazu dient, das Sicherheitselement 10 im Rahmen des Prüfverfahrens „auszuweisen". Der Prüfbezeichner wird dabei seitens des Sicherheitselements 10 derart gebildet, dass aus dem Prüfbezeichner nicht auf die Identität des Sicherheitselements 10 zurückgeschlossen werden kann. Beispielsweise kann das Sicherheitselement 10, mit Bezug auf ein vorstehend bereits beschriebenes PEKS- Verfahren, den Prüfbezeichner als PEKS-Token berechnen. Dabei wird eine das Sicherheitselement eindeutig bezeichnende Identität, die Prüfidentität, beispielsweise in Form einer Zahl oder einer Zeichenkette, in geeigneter, vorstehend im Detail beschriebener Weise mittels des öffentlichen Schlüssels der Sperreinrichtung 200 verschlüsselt.
Zum eindeutigen Verständnis sei nochmals angemerkt, dass mit Bezug auf die vorliegende Erfindung mit den Begriffen„ Sperr identität" und„Prüfiden- tität" die gleichen Konzepte, d.h. gleichartige Bezeichner bezeichnet sind.
Lediglich begrifflich soll die Unterscheidung dahingehend getroffen werden, dass ein entsprechender Bezeichner im Zusammenhang mit einem als zu sperren gemeldeten Sicherheitselement, d.h. einem Sicherheitselement, das auf der Sperrliste vermerkt ist, als„Sperridentität" bezeichnet wird, hinge- gen mit Bezug auf ein aktuell zu prüfendes Sicherheitselement als„Prüf identität". Wird festgestellt, dass die„Prüf identität" einer„Sperridentität" entspricht, d.h. gleich einer„Sperr identität" ist, so ist das Sicherheitselement als ungültig erkannt. In Schritt S6 überträgt das Sicherheitselement 10 den Prüfbezeichner an die Prüfeinrichtung 100. In einem optionalen, nicht gezeigten Schritt kann das Sicherheitselement 10 den Prüfbezeichner zuvor geeignet digital signieren. Hierbei ist vorzugsweise eine anonyme Signatur zu verwenden, beispielsweise eine mittels eines Gruppenschlüssels erzeugte Signatur.
In Schritt S7 durchsucht die Prüfeinrichtung 100 die in Schritt S3 empfangene Sperrliste und prüft, wie mit Bezug auf Schritt S8 angegeben, ob die Sperrliste einen Sperrbezeichner umf asst, der dem in Schritt S6 vom dem Sicherheitselement 10 empfangenen Prüfbezeichner entspricht. Dabei gilt ein Prüfbe- zeichner als einem Sperrbezeichner entsprechend, wenn der Prüfbezeichner von einer Prüfidentität abgeleitet worden ist, die derjenigen Sperridentität gleicht, von der der entsprechende Sperrbezeichner abgeleitet worden ist. Wie vorstehend mehrfach beschrieben, kann gemäß verschiedener Ausfüh- rungsformen eine Entsprechung von Prüfbezeichner und Sperrbezeichner erkannt werden, ohne dass die Prüfidentität erkennbar wird.
Liegt in der Sperrliste ein dem Prüfbezeichner entsprechender Sperrbezeichner vor, so wird das Sicherheitselement 10 in Schritt S9 als ungültig erklärt. Findet sich in der Sperrliste hingegen kein dem Prüfbezeichner entsprechender Sperrbezeichner, so befindet die Prüfeinrichtung 100 in Schritt S10 das Sicherheitselement 10 als gültig.
Das beschriebene Verfahren zeichnet sich insbesondere dadurch aus, dass anhand des Prüfbezeichners die Identität des Sicherheitselements 10 nicht festgestellt werden kann. Allenfalls in den Fällen, in denen das Sicherheitselement 10 als ungültig erkannt worden ist, kann gegebenenfalls, je nach dem verwendeten Suchverfahren, die Prüfidentität des Sicherheitselements 10 im Klartext erscheinen. In der Regel aber liegen sowohl die Sperrbezeich- ner der Sperrliste als auch die Prüfbezeichner der Prüfeinrichtung lediglich in verschlüsselter Form vor. Die Prüfeinrichtung durchsucht dann die Sperrliste mittels eines geeigneten, an die jeweilige Verschlüsselung angepassten „searchable encryption" -Verfahrens nach einem dem Prüfbezeichner entsprechenden Sperrbezeichner.
Im Fall eines verloren geglaubten und wieder gefundenen Sicherheitselements, wird das Sicherheitselement zunächst gesperrt, also der Sperrbezeichner in der Sperrliste veröffentlicht, und anschließend wieder entsperrt, also der Sperrbezeichner wieder in der Sperrliste gestrichen. Für alle Prüfinstanzen, welche sich den gelöschten Eintrag gemerkt haben, wäre nun die Anonymität des Sicherheitselements verloren. Die Prüfinstanz empfängt den Prüfbezeichner und kann anhand des nicht gelöschten Ein- trags die Identität des Sicherheitselements erkennen.
Das System kann daher verbessert werden, wenn der Sperrdienst 200 dem ehemals gesperrten Sicherheitselement 10 eine neue Sperridentität zuordnet. Der Sperrdienst 200 kann dem Sicherheitselement 10 die neue Identität mit- teilen.
Insbesondere kann der Sperr dienst 200 einem Sicherheitselement 10 periodisch eine neue Sperridentität zuordnen. Beispielsweise kann die Sperridentität jeden Tag, jede Woche oder jeden Monat geändert werden. Denkbar ist es alternativ zwar auch das Schlüsselpaar des Sperrdienstes periodisch zu ändern, jedoch wäre diese Änderung dann auch in allen Sicherheitselementen und Sperrlisten zu berücksichtigen.
Insbesondere ist es vorteilhaft, wenn die Sperridentität von einer Zeitangabe, wie Tagesangabe, Wochenangabe, Monatsangabe oder Datumsangabe, abgeleitet wird. Die Sperridentität w kann beispielsweis aus einem vorgegebenen Anteil wO und der Zeitangabe gebildet werden: w=w0 | 1 1. Die Sperridentität kann periodisch, parallel (also unabhängig voneinander) in dem Sperrdienst und in dem Sicherheitselement geändert werden. Alternativ oder ergänzend zu einer periodischen Änderung könnte auch eine vom Sperrdienst vergebene "Challenge" t, d.h. ein zufälliger oder pseudo-zufälliger Wert, an das Sicherheitselement gesendet werden. Das Sicherheitselement prüft dabei, dass der Wert t noch nicht für die Bildung einer Identität verwendet wurde.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Prüfung einer Gültigkeit eines Sicherheitselements (10), umfassend die Schritte:
Erstellen (S2) einer Sperrliste, wobei die Sperrliste Sperrbezeichner umfasst, welche jeweils ungültige Sicherheitselemente (10) bezeichnen;
Bestimmen (S5) eines Prüfbezeichners und Übertragen (S6) des Prüf- bezeichners an eine Prüfinstanz (100) durch das Sicherheitselement
(10);
Durchsuchen (S7, S8) der Sperrliste danach, ob diese einen dem Prüfbezeichner entsprechenden Sperrbezeichner umfasst;
dadurch gekennzeichnet, dass
- der Prüfbezeichner derart gebildet wird, dass aus dem Prüfbezeichner nicht auf die Identität des Sicherheitselements (10) zurückgeschlossen werden kann und dass
beim Durchsuchen der Sperrliste die Identität des Sicherheitselements (10) zumindest in dem Fall nicht erkennbar wird, in dem die Sperrliste keinen dem Prüfbezeichner entsprechenden Sperrbezeichner umfasst.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass
ein Sperrbezeichner von einer einem ungültigen Sicherheitselement eindeutig zugeordneten Sperridentität abgeleitet wird und dass
der Prüfbezeichner von einer dem zu prüfenden Sicherheitselement
(10) eindeutig zugeordneten Prüfidentität abgeleitet wird, wobei
der Sperrbezeichner dem Prüfbezeichner entspricht, wenn die Sperridentität der Prüfidentität gleicht.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Sicherheitselement (10) den Prüfbezeichner randomisiert bestimmt.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeich- net, dass zum Durchsuchen der Sperrliste ein PEKS- Verfahren verwendet wird,
wobei als Sperrbezeichner so genannte Trapdoor-Token verwendet werden, wobei ein Trapdoor-Token eine mittels eines geheimen Schlüssels eines Sperrdienstes verschlüsselte Sperridentität eines ungültigen Sicher- heitselements umfasst, und
wobei als Prüfbezeichner ein so genanntes PEKS-Token verwendet wird, welches eine mittels eines öffentlichen Schlüssels des Sperrdienstes verschlüsselte Prüfidentität des zu prüfenden Sicherheitselements umfasst, und
wobei im Rahmen des PEKS- Verfahrens geprüft wird, ob ein
Trapdoor-Token der Sperrliste dem PEKS-Token entspricht, da die Prüfidentität gleich der Sperridentität ist.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das PEKS- Verfahren folgende Schritte umfasst:
Bereitstellen zweier Gruppen Gi und G2 einer vorgegebenen Primzahlordnung p als Sicherheitsparameter sowie einer bilinearen Abbil
Figure imgf000023_0001
Bereitstellen einer Hashfunktion Hi: {0,1}*— > Gi und einer Hashfunk- tion H2: G2^{0,l}log P;
Erzeugen eines Schlüsselpaares (Apub, ApriV) durch den Sperrdienst wie folgt:
Wählen eines Elements a e Zp zufällig sowie eines erzeugenden Elements g e Gi und Setzen des öffentlichen Schlüssels Apub := [g, h= ga] und
Setzen des geheimen Schlüssels Apriv := ;
Bestimmen eines PEKS-Tokens PEKS( Apub, W) für eine Prüf identität W e {0,1}* wie folgt:
- Berechnen des Wertes t := e(H1(W)/ hr) e G2 für ein zufällig gewähltes r e p und
Bestimmen des PEKS-Tokens PEKS(Apub W) := [gr, H2(t)];
Berechnen eines Trapdoor-Tokens Tvv für eine Sperridentität W'e {0,1}* vermöge H^W')-3 e Gr,
- Durchsuchen der Sperrliste, indem für jedes Trapdoor-Token Tvv und das PEKS-Token S = [A, B] der Test(Apub, S, Tvv) durchgeführt wird:
Prüfe, ob H2(e(Tw, A) = B;
Falls ja, so gilt W = W',
sonst W ^ .
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass ein zu prüfendes Sicherheitselement mit dem Wert t' = e(Hi(W), h) personalisiert wird, so dass das Sicherheitselement zum Berechnen des Wertes t zum Bestimmen des PEKS-Tokens, wegen der Bilinearität der Funktion e und der Identität e(Hi(W), hr) = e(Hi(W), h) r, lediglich noch ein r e Z* zufällig wählen und den Wert (t')r berechnen muss.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der Prüfbezeichner über einen gesicherten Datenkommunikations- kanal übertragen wird.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass der gesicherte Datenkommunikationskanal dadurch hergestellt wird (S4), dass zwischen dem zu prüfenden Sicherheitselement (10) und der Prüfinstanz (100) auf der Basis flüchtiger Schlüsselpaare anonym ein Sitzungsschlüssel vereinbart wird, mittels dessen eine nachfolgende Datenkommunikation verschlüsselt werden kann.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass der Prüfbezeichner von dem Sicherheitselement (10) signiert wird.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Signatur derart ausgebildet wird, dass anhand der Signatur seitens der Prüfinstanz (100) nicht auf die Identität des Sicherheitselements (10) zurückgeschlossen werden kann.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass die Gültigkeit eines Sicherheitselements (10) in Form eines Hard- ware-Sicherheitsmoduls geprüft wird, insbesondere einer Smart-Card, eines USB-Tokens, eines RFID-Tokens, eines NFC-Moduls, eines TPM oder einer UICC/SIM-Mobilf unkkarte, oder dass die Gültigkeit eines Sicherheitselements (10) in Form eines Software-Sicherheitsmoduls geprüft wird, insbesondere eines TEE oder eines virtuellen Sicherheitsmoduls, beispielsweise einer virtuellen Mobilfunkkarte.
12. Sicherheitselement (10), welches eingerichtet ist, mittels eines Verfahrens nach einem der Ansprüche 1 bis 11 hinsichtlich Gültigkeit geprüft zu werden.
13. Prüfeinrichtung (100), welche eingerichtet ist, eine Gültigkeit eines Sicherheitselements (10) nach Anspruch 12 mittels eines Verfahrens nach einem der Ansprüche 1 bis 11 zu prüfen.
14. Sperreinrichtung (200), welche eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 11 zu unterstützen.
15. System (1000), umfassend eine Sperreinrichtung (200) nach Anspruch 14, zumindest eine Prüfeinrichtung (100) nach Anspruch 13 sowie zumindest ein Sicherheitselement (10) nach Anspruch 12.
PCT/EP2015/000461 2014-02-28 2015-02-27 Revokation eines sicherheitselements WO2015128094A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014003009.1A DE102014003009A1 (de) 2014-02-28 2014-02-28 Revokation eines Sicherheitselements
DE102014003009.1 2014-02-28

Publications (1)

Publication Number Publication Date
WO2015128094A1 true WO2015128094A1 (de) 2015-09-03

Family

ID=52737048

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/000461 WO2015128094A1 (de) 2014-02-28 2015-02-27 Revokation eines sicherheitselements

Country Status (2)

Country Link
DE (1) DE102014003009A1 (de)
WO (1) WO2015128094A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110087880A1 (en) * 2008-12-19 2011-04-14 Sap Ag Revocation of credentials in secret handshake protocols

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2384563B1 (de) * 2009-01-31 2013-07-17 International Business Machines Corporation Überprüfung von datenobjekten in datenverarbeitungssystemen

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110087880A1 (en) * 2008-12-19 2011-04-14 Sap Ag Revocation of credentials in secret handshake protocols

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "BSI TR-03110 Advanced Security Mechanisms for Machine Readable Travel Documents", 20 March 2012 (2012-03-20), XP055029789, Retrieved from the Internet <URL:https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr03110/index_htm.html> [retrieved on 20120613] *
D. BONEH ET AL.: "Public Key Encryption with Keyword Search", ADVANCES IN CRYPTOLOGY - EUROCRYPT 2004, INTERNATIONAL CONFERENCE ON THE THEORY AND APPLICATIONS OF CRYPTOGRAPHIC TECHNIQUES, 2 May 2004 (2004-05-02), pages 506 - 522
DAN BONEH ET AL: "Public Key Encryption with Keyword Search", 17 April 2004, ADVANCES IN CRYPTOLOGY - EUROCRYPT 2004; [LECTURE NOTES IN COMPUTER SCIENCE;;LNCS], SPRINGER-VERLAG, BERLIN/HEIDELBERG, PAGE(S) 506 - 522, ISBN: 978-3-540-21935-4, XP019005037 *
ERNIE BRICKELL ET AL: "Enhanced Privacy ID from Bilinear Pairing", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20090302:082808, 25 February 2009 (2009-02-25), pages 1 - 23, XP061003320 *

Also Published As

Publication number Publication date
DE102014003009A1 (de) 2015-09-03

Similar Documents

Publication Publication Date Title
EP3057025B1 (de) Computerimplementiertes verfahren zur zugriffskontrolle
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
DE102012206341B4 (de) Gemeinsame Verschlüsselung von Daten
DE102016224537B4 (de) Masterblockchain
EP2765752B1 (de) Verfahren zum versehen eines mobilen endgeräts mit einem authentisierungszertifikat
WO2018073071A1 (de) Bereitstellung und prüfung der gültigkeit eines virtuellen dokuments
EP2443853A1 (de) Verfahren zum einbuchen eines mobilfunkgeräts in ein mobilfunknetz
DE10026326B4 (de) Verfahren zur kryptografisch prüfbaren Identifikation einer physikalischen Einheit in einem offenen drahtlosen Telekommunikationsnetzwerk
DE102019212959B3 (de) Verfahren zur geschützten Kommunikation eines Fahrzeugs mit einem externen Server, Vorrichtung zur Durchführung der Schlüsselableitung bei dem Verfahren sowie Fahrzeug
DE102020003739A1 (de) Verfahren zur Verteilung und Aushandlung von Schlüsselmaterial
DE102017105771A1 (de) Verfahren zur Zugangskontrolle
DE102013203436A1 (de) Generieren eines Schlüssels zum Bereitstellen von Berechtigungsinformationen
WO2014095001A1 (de) Reputationssystem und verfahren
EP2730050B1 (de) Verfahren zur erstellung und überprüfung einer elektronischen pseudonymen signatur
EP4111399A1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
EP3556071B1 (de) Verfahren, vorrichtung und computerlesbares speichermedium mit instruktionen zum signieren von messwerten eines sensors
EP3734478A1 (de) Verfahren zur vergabe von zertifikaten, leitsystem, verwendung eines solchen, technische anlage, anlagenkomponente und verwendung eines identitätsproviders
DE102015216630A1 (de) Indirekter Berechtigungstransport
DE102018002466A1 (de) Verfahren und Anordnung zum Herstellen einer sicheren Datenübertragungsverbindung
WO2015128094A1 (de) Revokation eines sicherheitselements
DE102009031143B3 (de) Vorrichtung und Verfahren zum Erstellen und Validieren eines digitalen Zertifikats
EP1675298A1 (de) Verfahren zur Überprüfung der Identität einer ersten Entität gegenüber einer anderen Entität in einem System sowie System zum Durchführen des Verfahrens
DE102014010455A1 (de) Datensparsame Authentisierung
WO2018091703A1 (de) Verfahren und vorrichtung zum sichern einer elektronischen datenübertragung
WO2018146133A1 (de) Verfahren zum erkennen von unberechtigten kopien digitaler sicherheits-token

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: 15712043

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15712043

Country of ref document: EP

Kind code of ref document: A1