Access control system

Abstract

Provided is a method for access control, performed by an access control apparatus, including obtaining access authorization information that is communicated to the access control apparatus having at least one access authorization parameter and first check information; using at least the communicated access authorization parameters, the communicated first check information and a second key from a key pair, which second key is stored in the access control apparatus, to perform a first check on whether the communicated first check information has been produced by performing cryptographic operations by means of access authorization parameters corresponding to the communicated access authorization parameters using at least one first key from the key pair, and deciding whether access can be granted, based on the first check delivers a positive result and it is established that at least one predefined set of the communicated access authorization parameters respectively provides access authorization.

Claims

1. An access control apparatus comprising at least one processor and at least one memory that includes program code, wherein the memory and the program code are configured to cause the access control apparatus with the at least one processor to perform and/or control: an obtaining of access authorization information communicated to the access control apparatus and comprising at least one or more access authorization parameters and first check information; a first checking, using at least the communicated access authorization parameters, of the communicated first check information and a second key of a symmetrical or asymmetrical key pair, said second key being stored in the access control apparatus, as to whether the communicated first check information was generated by performing cryptographic operations on access authorization parameters corresponding to the communicated access authorization parameters using at least a first key of the key pair; a deciding whether access is permitted to be granted, wherein necessary conditions for granting access are that the first checking yields a positive result and that it is determined that at least one predefined set of the communicated access authorization parameters, in view of respective pieces of reference information present in the access control apparatus at least at the time of the first checking, respectively authorize for access; and wherein the memory and the program code are further configured to cause the access control apparatus with the at least one processor to perform and/or control action group A or action group B as defined below: action group A: an obtaining of information communicated to the access control apparatus and comprising at least one fourth key encrypted using at least the first key of the key pair and usable in an authentication of the access control apparatus vis-?-vis an access authorization proving apparatus that communicates the access authorization information to the access control apparatus, or in the check of the authenticity and/or integrity of information communicated to the access control apparatus; and a decrypting of the encrypted fourth key using at least the second key of the key pair in order to obtain the fourth key; action group B: an obtaining of information communicated to the access control apparatus and comprising at least one combinationencrypted using at least the first key of the key pairof a fourth key and an identifier for the access authorization information or for an access authorization proving apparatus that communicates the access authorization information to the access control apparatus, wherein the fourth key is usable in an authentication of the access control apparatus vis-?-vis an access authorization proving apparatus that communicates the access authorization information to the access control apparatus, or in the check of the authenticity and/or integrity of information communicated to the access control apparatus; and a decrypting of the encrypted combination using at least the second key of the key pair in order to obtain the fourth key and the identifier, wherein the identifier further constitutes one of the communicated access authorization parameters, and wherein it is determined that the identifier contained in the communicated access authorization information authorizes for access if the identifier contained in the communicated access authorization information corresponds to the identifier obtained by decrypting the encrypted information or if the identifier contained in the communicated access authorization information corresponds to the identifier obtained by decrypting the encrypted information and the identifier is not contained in a rejection list stored in the access control apparatus.

2. The access control apparatus as claimed in claim 1, wherein the key pair is a symmetrical key pair, and wherein the first checking comprises performing the cryptographic operations on the communicated access authorization parameters using at least the second key of the key pair for obtaining locally generated first check information and comparing the communicated first check information with the locally generated first check information.

3. The access control apparatus as claimed in claim 2, wherein the cryptographic operations serve for determining a message authentication code as check information.

4. The access control apparatus as claimed in claim 1, wherein one of the communicated access authorization parameters is an identifier for only one access control apparatus or a group of access control apparatuses, and wherein it is determined that the identifier authorizes for access if the identifier corresponds to an individual identifier of the access control apparatus that is stored in the access control apparatus and/or a group identifier for a group of access control apparatuses to which the access control apparatus belongs.

5. The access control apparatus as claimed in claim 1, wherein the memory and the program code are configured to cause the access control apparatus with the at least one processor to perform and/or control action group A, and wherein one of the communicated access authorization parameters is an identifier for the access authorization information or for an access authorization proving apparatus which communicates the access authorization information to the access control apparatus, and wherein it is determined that the identifier authorizes for access if the identifier is not contained in a rejection list stored in the access control apparatus.

6. The access control apparatus as claimed in claim 5, wherein the memory and the program code are further configured to cause the access control apparatus with the at least one processor to perform and/or control: an obtaining of rejection information communicated to the access control apparatus and comprising at least one new rejection list with identifiers for access authorization information to be rejected or for access authorization proving apparatuses from which access authorization information is to be rejected at the access control apparatus, and fourth check information, and a storing of the communicated new rejection list only under the precondition that it is determined in a check based at least on the communicated fourth check information, the second key of the key pair and the communicated rejection information, that the communicated fourth check information was generated by performing cryptographic operations on the rejection information corresponding to the communicated rejection information using at least the first key of the key pair.

7. The access control apparatus as claimed in claim 6, wherein the rejection information further comprises a counter that is incremented with each new rejection list, and wherein the new rejection list is stored in the access control apparatus only under the further precondition that the value of the counter comprised by the rejection information is greater than a value of a counter provided in the access control apparatus, and wherein the value of the counter of the access control apparatus is updated to the value of the counter comprised by the rejection information in or after the storage of the new rejection list in the access control apparatus.

8. The access control apparatus as claimed in claim 6, wherein the rejection information further comprises an identifier of only one access control apparatus or a group of access control apparatuses on which the new rejection list is intended to be stored, and wherein the new rejection list is stored in the access control apparatus only under the further precondition that an individual identifier of the access control apparatus that is stored in the access control apparatus or a group identifier for a group of access control apparatuses that contains the access control apparatus corresponds to the identifier comprised in the rejection information.

9. The access control apparatus as claimed in claim 1, wherein the memory and the program code are configured to cause the access control apparatus with the at least one processor to perform and/or control action group B, and wherein the access authorization information communicated to the access control apparatus is stored in identical form on at least two access authorization proving apparatuses, wherein the identical access authorization information stored on the at least two access authorization proving apparatuses in each case has the same identifier for the access authorization information and said access authorization information is associated in each case with the same fourth key.

10. The access control apparatus as claimed in claim 9, wherein the access authorization information communicated to the access control apparatus has a limited temporal validity and/or has only a limited permissible number of access processes within its period of validity and/or can be or is only communicated to the access control apparatus by the access authorization proving apparatus if it is determined at the access authorization proving apparatus that there is a need for the access to the access control apparatus.

11. The access control apparatus as claimed in claim 1, wherein the fourth key together with a third key forms a symmetrical or asymmetrical key pair, and wherein the communicated access authorization information further comprises third check information, wherein the memory and the program code are further configured to cause the access control apparatus with the at least one processor to perform and/or control: a second checking, using at least a challenge generated by the access control apparatus, of the communicated access authorization parameters, the communicated first check information, the communicated third check information and the fourth key, whether the communicated third check information was generated by performing cryptographic operations on information corresponding to the generated challenge, the communicated access authorization parameters and the communicated first check information, using at least the third key, wherein a further necessary condition for granting the access is that the second checking yields a positive result.

12. The access control apparatus as claimed in claim 1, wherein the memory and the program code are further configured to cause the access control apparatus with the at least one processor to perform and/or control: an authenticating vis-?-vis an access authorization proving apparatus that includes the access authorization information, using at least the fourth key, wherein the access authorization information is communicated to the access control apparatus by the access authorization proving apparatus only in the event of successful authentication.

13. The access control apparatus as claimed in claim 1, wherein the memory and the program code are configured to cause the access control apparatus with the at least one processor to perform and/or control action group A.

14. The access control apparatus as claimed in claim 1, wherein the memory and the program code are configured to cause the access control apparatus with the at least one processor to perform and/or control action group B.

15. An apparatus comprising at least one processor and at least one memory that includes program code, wherein the memory and the program code are configured to cause the apparatus with the at least one processor to perform and/or control: a generating of first check information by performing cryptographic operations on one or more access authorization parameters using at least a first key of a symmetrical or asymmetrical key pair; a generating of access authorization information comprising at least the one or more access authorization parameters and the first check information; and an outputting of the access authorization information for storage on an access authorization proving apparatus configured to communicate the access authorization information to at least one access control apparatus in order to enable the latter to decide whether access is permitted to be granted on the basis of the communicated access authorization information, wherein necessary conditions for granting access are that a first checking, using at least the communicated access authorization parameters, the communicated first check information and a second key of the key pair, said second key being stored in the access control apparatus, whether the communicated first check information was generated by performing cryptographic operations on access authorization parameters corresponding to the communicated access authorization parameters using at least the first key of the key pair, yields a positive result and it is determined that at least one predefined set of the communicated access authorization parameters , in view of respective pieces of reference information present in the access control apparatus at least at the time of the first checking, respectively authorize for access; wherein the memory and the program code are further configured to cause the apparatus with the at least one processor to perform and/or control action group A or action group B as defined below: action group A: an encrypting of a fourth key using at least the first key of the key pair, wherein the fourth key can be used in an authentication of the access control apparatus vis-?-vis the access authorization proving apparatus, which communicates the access authorization information to the access control apparatus, or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus,; a generating of information comprising at least the encrypted fourth key; and an outputting of the information for storage on the access authorization proving apparatus, which is configured to communicate the information at least to the access control apparatus in order to enable the latter to decrypt the encrypted fourth key using at least the second key of the key pair and to use said fourth key; action group B: an encrypting of a combination of a fourth key and an identifier for the access authorization information or for the access authorization proving apparatus, which communicates the access authorization information to the access control apparatus, using at least the first key of the key pair, wherein the fourth key can be used in an authentication of the access control apparatus vis-a-vis an access authorization proving apparatus, which communicates the access authorization information to the access control apparatus, or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus, a generating of information comprising at least the encrypted combination, and an outputting of the information for storage on the access authorization proving apparatus, which is configured to communicate the information at least to the access control apparatus in order to enable the latter to decrypt the encrypted combination using at least the second key of the key pair, in order to obtain the fourth key and the identifier, wherein the identifier further constitutes one of the access authorization parameters, and wherein it is determined in the access control apparatus that the identifier contained in the communicated access authorization information authorizes for access if the identifier contained in the communicated access authorization information corresponds to the identifier obtained by decrypting the encrypted combination, or if the identifier contained in the communicated access authorization information corresponds to the identifier obtained by decrypting the encrypted combination and the identifier is not contained in a rejection list stored in the access control apparatus.

16. The access control apparatus as claimed in claim 15, wherein the memory and the program code are configured to cause the apparatus with the at least one processor to perform and/or control action group A.

17. The access control apparatus as claimed in claim 15, wherein the memory and the program code are configured to cause the apparatus with the at least one processor to perform and/or control action group B.

18. An apparatus comprising at least one processor and at least one memory that includes program code, wherein the memory and the program code are configured to cause the apparatus with the at least one processor to perform and/or control: a communicating of access authorization information comprising at least one or more access authorization parameters and first check information to an access control apparatus in order to enable the latter to decide whether access is permitted to be granted on the basis of the communicated access authorization information, wherein necessary conditions for granting access are that a first checking, using at least the communicated access authorization parameters, the communicated first check information and a second key of a symmetrical or asymmetrical key pair, said second key being stored in the access control apparatus, whether the communicated first check information was generated by performing cryptographic operations on access authorization parameters corresponding to the communicated access authorization parameters using at least a first key of the key pair, yields a positive result and it is determined that at least one predefined set of the communicated access authorization parameters , in view of respective pieces of reference information present in the access control apparatus at least at the time of the first checking, respectively authorize for access; wherein the memory and the program code are further configured to cause the apparatus with the at least one processor to perform and/or control action group A or action group B as defined below: action group A: a communicating to the access control apparatus of information comprising at least one fourth key that is encrypted using at least the first key of the key pair and that can be used in an authentication of the access control apparatus vis-a-vis the access authorization proving apparatus, or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus, in order to enable the latter to decrypt the encrypted fourth key using at least the second key of the key pair and to use said fourth key; action group B: a communicating to the access control apparatus of information comprising at least one combinationencrypted using at least the first key of the key pairof a fourth key and an identifier for the access authorization information or for the access authorization proving apparatus, wherein the fourth key can be used in an authentication of the access control apparatus vis-a-vis the access authorization proving apparatus or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus, in order to enable the latter to decrypt the encrypted combination using at least the second key of the key pair, in order to obtain the fourth key and the identifier, wherein the identifier further constitutes one of the access authorization parameters, and wherein it is determined in the access control apparatus that the identifier contained in the communicated access authorization information authorizes for access if the identifier contained in the communicated access authorization information corresponds to the identifier obtained by decrypting the encrypted combination, or if the identifier contained in the communicated access authorization information corresponds to the identifier obtained by decrypting the encrypted combination and the identifier is not contained in a rejection list stored in the access control apparatus.

19. The access control apparatus as claimed in claim 18, wherein the memory and the program code are configured to cause the apparatus with the at least one processor to perform and/or control action group A.

20. The access control apparatus as claimed in claim 18, wherein the memory and the program code are configured to cause the apparatus with the at least one processor to perform and/or control action group B.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

(1) Further advantageous exemplary configurations of the invention can be gathered from the following detailed description of some exemplary embodiments of the present invention, in particular in conjunction with the figures. However, the figures accompanying the application are intended to serve only for the purpose of clarification, but not for extending the scope of protection of the invention. The accompanying drawings are not necessarily true to scale and are merely intended to reflect by way of example the general concept of the present invention. In particular, features contained in the figures ought not under any circumstances be deemed to be a necessary part of the present invention.

(2) In the figures:

(3) FIG. 1: shows a schematic illustration of one exemplary embodiment of a system according to the present invention;

(4) FIG. 2: shows a schematic illustration of one exemplary embodiment of an apparatus according to the present invention;

(5) FIG. 3: shows a schematic illustration of a further exemplary embodiment of a system according to the present invention;

(6) FIG. 4: shows a flow diagram of one exemplary embodiment of a communication of access authorization information between a handheld scanner/cellular phone and a parcel box according to the present invention;

(7) FIG. 5: shows a flow diagram of one exemplary embodiment of a communication of access authorization information between a tag and a parcel box according to the present invention;

(8) FIG. 6: shows a flow diagram of one exemplary embodiment of a communication of rejection information between a handheld scanner/cellular phone/tag and a parcel box according to the present invention;

(9) FIG. 7: shows a flow diagram of one exemplary embodiment of a communication of group key information between a handheld scanner/cellular phone/tag and a parcel box according to the present invention;

(10) FIG. 8: shows a flow diagram of one exemplary embodiment of a communication of keys and access authorization information between the key server and further components of an exemplary system according to the invention;

(11) FIG. 9: shows a schematic illustration of the distribution of group keys and access authorization information in an exemplary system according to the invention;

(12) FIG. 10: shows a schematic illustration of the assignment of parcel boxes to different delivery areas in accordance with one exemplary embodiment of the invention; and

(13) FIG. 11: shows a flow diagram of the possible order of operations in one exemplary embodiment of a parcel box according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

(14) An overview of one exemplary embodiment of a system 1 according to the invention is illustrated in FIG. 1. The system comprises an access authorization generation apparatus 2, an access authorization proving apparatus 3 and an access control apparatus 4. Particularly the access authorization proving apparatus 3 and the access control apparatus 4 can be present multiply, but are constituted only singly in each case for reasons of simplifying the illustration. The components 2, 3 and 4 constitute respective exemplary apparatuses in accordance with the first, second and third aspects of the invention, the properties of which have already been thoroughly outlined. FIG. 1 therefore serves primarily for clarification of what keys are stored in the individual components and what information is exchanged between the components. Access authorization generation apparatus 3 stores in particular the first individual key S.sub.1 and optionally also a first group key S.sub.T1, which together with a second individual key S.sub.2 and a second group key S.sub.T2, respectively, in the access control apparatus 2 respectively form an individual key pair (S.sub.1, S.sub.2) and a group key pair (S.sub.T1, S.sub.T2). These pairs can each form a symmetrical or asymmetrical key pair, wherein both keys are identical in the case of a symmetrical key pair, that is to say that e.g. S.sub.1=S.sub.2=S and/or S.sub.T1=S.sub.T2=S.sub.T hold(s) true, and S.sub.1?S.sub.2 and/or S.sub.T1?S.sub.T2 hold(s) true in the case of an asymmetrical key pair.

(15) The access authorization proving apparatus 2 generates and transmits one or more of the following pieces of information to the access authorization proving apparatus 3: access authorization information B and first check information V, the fourth key H.sub.4 encrypted with S.sub.1 or S.sub.T1, in the context of the information A, a third key H.sub.3, the group key information W and the second check information V.sub.W, and/or the rejection information L and the fourth check information V.sub.L.

(16) This information can be transmitted for example at least partly (or completely) within the same communication session between the access authorization generation apparatus 2 and the access authorization proving apparatus 3 (that is to say for example between the setting up and clearing down of a communication connection between the access authorization generation apparatus 2 and the access authorization proving apparatus 3), or else in different communication sessions. However, the group key information W can be transmitted for example less frequently than the for example the access authorization information B and the rejection information L, since the need to change them arises less often.

(17) This information can be transmitted from the access authorization generation apparatus 2 to the access authorization proving apparatus 3 at least partly wirelessly (e.g. via mobile radio or WLAN), particularly if the access authorization proving apparatus 3 is a portable user device (e.g. a cellular phone) or a portable deliverer device (e.g. a handheld scanner). In this case, the transmission does not have to be performed directly, but rather can be performed via one or more intermediate stations (e.g. the decentralized units that will be discussed further below), as will be discussed in even greater detail below. If the access authorization proving apparatus 3 is a tag (e.g. an RFID or NFC tag), the transmission of the information should be understood as logical and can mean, for example, that the information is communicated to a server of a production system for the tags and stored there in the tags.

(18) The third key H.sub.3 and the fourth key H.sub.4 here again form a key pair (H.sub.3, H.sub.4), which for example can be symmetrical, that is to say H.sub.3=H.sub.4=H, or can be asymmetrical, that is to say H.sub.3?H.sub.4.

(19) From the pieces of information communicated to the access authorization proving apparatus 3 by the access authorization generation apparatus 2, in principle each piece of information, apart from the third key H.sub.3, can be communicated further to the access control apparatus 4 by the access authorization proving apparatus 3 and can then be used in the access control apparatus 4 for checking whether this information is authentic and has integrity and whetherin the case of the access authorization informationthe operator of the access authorization proving apparatus 3 is permitted to be granted access.

(20) In this case, the third key H.sub.3 is stored in the access authorization proving apparatus 3 and used for example in the context of the mutual authentication between access authorization proving apparatus 3 and access control apparatus 4, wherein the latter has received the counterpart to the third key H.sub.3, namely the fourth key H.sub.4, communicated in encrypted form (information A) and, after decryption, stores it at least temporarily.

(21) FIG. 2 shows a schematic illustration of one exemplary embodiment of an apparatus 5 according to the present invention. Apparatus 5 can represent for example the access authorization generation apparatus 2, the access authorization proving apparatus 3 or the access control apparatus 4 from FIG. 1.

(22) Apparatus 5 comprises a processor 50 with assigned main memory 52 and program memory 51. The processor executes for example program instructions stored in the program memory 51. The program instructions perform the method in accordance with the first, second or third aspect of the invention and/or control it. Thus, the program memory 51 contains a computer program according to the first, second or third aspect of the invention and constitutes a computer program product for storing it.

(23) The program memory 51 can be for example a persistent memory, such as a read-only memory (ROM), for example. The program memory can for example be fixedly connected to the processor 50, but can alternatively also be releasably connected to the processor 50, for example as a memory card, floppy disk or optical data carrier medium (e.g. a CD or DVD). Further information can also be stored in the program memory 51, or in a separate memory. If apparatus 5 is the access authorization generation apparatus 2, this information can include for example the keys S.sub.1 and/or S.sub.T1 and/or the keys H.sub.3 and/or H.sub.4, as well as, for example, information about the access control apparatus for which access authorization information is intended to be generated (e.g. the identifier of the access control apparatus) and information concerning the access authorization information, the group key information and/or the rejection information and the assigned check information thereof. If apparatus 5 is the access authorization proving apparatus 3, said information can include for example the information obtained from the access authorization generation apparatus 2 (in particular B, V, W, V.sub.W, L, V.sub.L, A, H.sub.3). If apparatus 5 is the access control apparatus 4, said information can include the keys S.sub.2 and/or S.sub.T2 and also reference information on the basis of which obtained access authorization parameters are checked to determine whether they provide authorization in each case for granting access (e.g. an identifier of the access control apparatus, a rejection list, one or more counters e.g. for group key information or rejection information, etc.).

(24) The main memory 52 is used for example for storing temporary results during the processing of the program instructions; this is for example a volatile memory, such as a random access memory (RAM), for example.

(25) The processor 50 is further operatively connected to a communication unit 53, which enables information to be exchanged with external apparatuses, for example.

(26) If the apparatus 5 represent the access authorization generation apparatus 2, the communication unit 53 can be configured for example for communication via a network such as the Internet, for example, in order to be able to transmit information for example to one or more the following units: to a server of a manufacturer of access control apparatuses 4 (cf. server 72 in FIG. 9) and/or to a server of a manufacturer of access authorization proving apparatuses 3 (cf. server 73 in FIG. 9), and/or to an interface server of a mobile communication network via which information is intended to be transmitted wirelessly to an access authorization proving apparatus 3 (e.g. a cellular phone or a handheld scanner), and/or to a management server (e.g. provision server 66 in FIG. 3), under the control of which the distribution of the information to decentralized units (see 71-2 in FIG. 8) for transmission to access authorization proving apparatuses 3 (e.g. deliverer devices) takes place, and/or at least indirectly to a computer (e.g. a decentralized unit 71-2 in FIG. 8), by which or under the control of which the information is then intended to be communicated to access authorization proving apparatuses 3 (e.g. deliverer devices) (for example wirelessly (e.g. via a LAN) or in a wired manner (e.g. via a WLAN)).

(27) If the apparatus 5 represents the access authorization proving apparatus 3 in the form of a user device or deliverer device, the communication unit 53 can comprise the following, for example: a mobile radio interface for receiving information from the access authorization generation apparatus 2, an interface for wireless (e.g. by WLAN) or wired reception (e.g. via a docking station) of information of an apparatus (for example a decentralized unit) to which the access authorization generation apparatus 2 transmitted this information for transmission to the access authorization proving apparatus 3, a radio interface for communication with the access control apparatus 2, in particular a Bluetooth interface and/or an RFID interface and/or NFC interface.

(28) If the apparatus 5 represents the access authorization proving apparatus 3 in the form of a tag, the communication unit 53 can comprise the following, for example: a radio interface for communication with the access control apparatus 2, in particular a Bluetooth interface and/or an RFID interface and/or an NFC interface.

(29) The apparatus 5 can also contain further components, for example a graphical user interface, in order to permit an operator to interact with the apparatus 5, particularly if apparatus 5 constitutes an access authorization proving apparatus 3 in the form of a user device or deliverer device. If apparatus 5 constitutes a deliverer device, the apparatus 5 can comprise for example a unit for in particular optically detecting information (e.g. a scanner), and/or for example a user interface for detecting handwritten inputs, such as e.g. a signature.

(30) If apparatus 5 represents an access control apparatus 4, a for example optical and/or acoustic user interface can likewise be provided, in order to be able to output to the operator for example information about the status of the access control apparatus 4 and/or about the success of an attempt to be granted access at the access control apparatus 4 with access authorization information. In the case of an access control apparatus 4, the apparatus 5 can also comprise control means for controlling a locking unit (e.g. for unlocking same) depending on the decision whether access can be granted. The locking unit can comprise for example an in particular electronically controllable lock. In the context of the description of the exemplary embodiments in FIGS. 3-10, a unit comprising at least the processor 50, the memories 51 and 52 and the locking unit is referred to as lock. In the case of an access control apparatus 4, the apparatus 5 can further also comprise one or more sensors, for example for detecting a current locking state of the locking unit. In the case of an access control apparatus 4, the apparatus 5 can comprise for example a battery (whether or not e.g. rechargeable), in particular as sole power supply. In the case of an access control apparatus 4, the apparatus 5 can have for example no connection to a wired network, that is to say in particular no connection to a LAN, and/or for example no connection to a WLAN or a mobile radio network (in particular a cellular mobile radio network).

(31) In the case of an access authorization proving apparatus 3 in the form of a tag, the apparatus 5 can comprise for example no dedicated power supply and draw its energy for communication from the field of a reading unit of the access control apparatus 4. In the case of such a tag, it is also possible for no user interface to be present.

(32) The components 50-53 can be embodied for example jointly as a module or unit, or can be embodied at least partly as individual modules, in order to ensure easy exchangeability in the event of possible defects.

(33) A concretized exemplary embodiment of an access control system 6 according to the invention, which is illustrated in FIG. 3, is presented below with reference to FIGS. 3-10. In the case of this access control system 6, the access authorization generation apparatus 2 is embodied as a key server 60, the access control apparatuses 4 are embodied as parcel boxes 69 (or units thereof that control access, in particular locks) that are assigned to users 63 (e.g. users registered for use of the parcel boxes), and the access authorization proving apparatuses 3 are embodied as handheld scanners 68 or tags 74 of deliverers 70 or as cellular phones 61 or tags 62 of users 63, which are referred to overall as token. The users 63 here are for example the owners of parcel boxes or other persons (e.g. from the same household or the neighborhood) who have registered themselves to receive mail in a specific parcel box 69 or to be able to have said mail collected from said parcel box. The users 63 are also referred to as parcel box users. The deliverers 70 can be for example parcel deliverers, combination deliverers (who deliver both letters and parcels) or letter deliverers. For the parcel deliverers and combination deliverers it is important, for example, to be able to open the parcel box in order to deliver parcels therein or to be able to retrieve parcels therefrom. For combination deliverers and letter deliverers it is important, for example, to be able to open the parcel box in order that large-format letters (e.g. maxi-letters) which, under certain circumstances, do not fit through a letter slot of the parcel box can be delivered into the parcel box by the latter being opened.

(34) However, the concretization of the components 2, 3 and 4 that is effected in FIGS. 3-10 and the associated description serves only for explanation purposes and ought not to be understood as essential or restrictive. In particular, the interaction of the thus concretized components 2, 3 and 4 also in general formthat is to say detached from the concrete embodiment of these componentsshould be understood as disclosed. This likewise applies to the transmission techniques concretized for explanation purposes, in particular Bluetooth and NFC, which should be understood merely as an example of one possible form of the wireless communication between access authorization proving apparatuses 3 and access control apparatuses 4. A parcel box 69 is a container having at least one lockable door which is configured at least to receive parcels, for example at least one parcel having the dimensions 45?35?20 cm (which corresponds to a so-called Packset L), or at least two or three of such parcels. The parcel box 69 can also have a letter compartment (but alternatively can also have no letter compartment), into which letters can be inserted for example through a letter slot with or without a covering flap. The letter compartment can be lockable with its own door (with a mechanical or electronic lock) or can alternatively be locked by means of a door of the parcel box 69 together with a parcel compartment provided for receiving the parcels. If a door for the parcel compartment and a door for the letter compartment are respectively provided, for example a common access control apparatus can be provided, which either opens one door (e.g. the door of the parcel compartment, e.g. for the deliverer 70) or opens both doors (e.g. for the user 63), depending on the access authorization. The parcel box 69 can be provided for mounting in or on a wall, for example a house wall, or as a free-standing unit for fixing to the ground, e.g. in front of a house. The user 63 is notified of newly delivered mail (parcels and/or letters) for example via email and/or SMS. It is also possible for the user 63 to insert franked mail into the parcel box 69 and to request collection online or over the telephone. If no collection is ordered, the mail is collected, under certain circumstances, with somewhat of a delay when a deliverer opens the parcel box the next time and finds the mail there. As evidence of collected mail, a receipt is left in the parcel box by the deliverer, for example.

(35) The key server 60 is operated for example in a suitable computer center of a delivery company, in particular of Deutsche Post DHL. It generates keys and access authorizations and communicates them in particular to the provision server 66. As will be described in even greater detail below with reference to FIG. 8, the provision server, from the access authorizations (and also keys, if appropriate) obtained from the key server 66, makes a selection of access authorizations required for respective delivery areas, augments this information with address information of parcel boxes and/or the users thereof (and also, if appropriate, the MAC addresses of the locks of the parcel boxes 69, with the aid of which the handheld scanners 68 can initiate a Bluetooth connection, without time-consuming Bluetooth pairing being necessary) obtained from the parcel box management system 65, and makes this information available to the handheld scanners 68 directly or indirectly. In this case, the selection is based on so-called area cutting, that is to say the assignment of mail to be delivered or collected to delivery areas for which the deliverers 70 can register with their handheld scanners 68, this area cutting being performed by the assignment server 67, which has access to the mail data.

(36) In parallel the parcel recipients 63 obtain their keys and access authorization information which they can use to open the parcel boxes 69. The purchase of a parcel box 69 by a user 63 and/or the registration for a parcel box 69 are/is performed for example via an online portal 64 (e.g. the domain www[dot]Paket[dot]de) that exchanges information in this regard with the server of the parcel box management 65. In addition or as an alternative to the handheld scanners 70 of the deliverers, tags 74 are also provided, which can be used by the deliverers 70 (in particular letter deliverers) to open in each case a plurality of parcel boxes 69, for example all the parcel boxes 69 of a delivery area. Said tags are also referred to hereinafter as Group Lock Access (GLA) token. In a similar manner, tags 62 are also provided for the users 63 in addition or as an alternative to the cellular phones 61, which tags, however, generally only open the parcel box 69 respectively assigned to a user 62, said tags also being referred to hereinafter as Individual Lock Access (ILA) token. The access authorization information and keys contained on the tags 62, 74 are likewise generated by the key server 60 and then stored on the tags, as is indicated by the dashed lines in FIG. 3.

(37) If the user 63 uses a cellular phone for opening the parcel box 69, said cellular phone can communicate with the key server 60 for example via a software application (referred to hereinafter as app). The app itself and/or its communication with the key server 60 can be configured particularly securely here, for example by measures such as encrypted communication, version control, hardening, password protection, etc.

(38) Firstly, the components of the access control system 6 in FIG. 3 are described in greater detail below.

(39) Locks

(40) Locks are integrated in the parcel boxes 69 used by delivery companies to deliver both parcels and letters to customers 63. Since letters and parcels ought to be delivered exclusively to the original recipient 63, the parcel boxes 69 are responsible for the actual access authorizations. Accordingly, the parcel boxes 69 are equipped with (more particularly electronically controllable) locks and a communication interface. Further, they include the logic for obtaining access authorizations and proving and ensuring the access, that is to say the opening. Parcel boxes 69 are either owned by individual customers 63 or shared by different customers 63.

(41) Access Authorizations

(42) Deliverers 70 or users 63 are granted access to parcel boxes 69 only if they are in possession of a valid access authorization. Access authorizations comprise one or more of the access authorization parameters already described. In this case, access authorizations are reproduced in electronic form and written on a physical token. An access authorization can be limited both with regard to a period of use (not before and not later) and with regard to the number of their usesfor opening a lock.

(43) Physical Tokens

(44) A physical token includes the access authorization. There are three different types here: handheld scanners 68, NFC tags 62, 74 and cellular phones 61, for example smartphones 61. In this case, handheld scanners 68 are used for example exclusively by deliverers 70 for delivery and collection of mail (e.g. parcels). Cellular phones 61 are typically used by the customers 63. NFC tags 62, 74 can be used both by deliverers 70 and by users 63. While delivery personnel 70 who deliver letters that do not fit in the letter slot of the parcel box 69 need access to a group of parcel boxes 69, users 63 and parcel deliverers 70 with handheld scanners 68 require individual access to parcel boxes 69. Therefore, Group Lock Access (GLA) tokens (for group access) and Individual Lock Access (ILA) tokens (for individual access) are differentiated and used in the system in FIG. 3. Therefore, ILA tokens are used on the cellular phone 62 of a user 63, the NFC tag 62 of a user 63 and the handheld scanner 68 of a (parcel) deliverer 70, while GLA tokens are used on the NFC tags 74 of a (letter) deliverer 70.

(45) Key Server

(46) The key server 60 manages all the access authorizations of the system 6. In particular it contains information about all the users 63, all the parcel boxes 69 and the associated access rights. Therefore, it also generates the actual access authorizations that can be used on the physical tokens.

(47) Cryptographic Keys of the Locks

(48) Each lock of a parcel box 69 has two keys used for differentiating between the types of tokens discussed above.

(49) For ILA tokens: A lock has an individual key S.sub.2. In order to open a lock, an ILA requires a valid access authorization B. The key S.sub.2 is used to verify the access authorization B. Further, the key S.sub.2 is used to validate a rejection list and/or group key information. The key S.sub.2 together with a key S.sub.1 forms a key pair, which can be symmetrical or asymmetrical. In the case of a symmetrical key S.sub.1=S.sub.2, for example AES-128 is used as symmetrical cryptographic primitives and is used for the encryption of, for example, the so-called Cipher Block Chaining (CBC) mode together with a random initialization vector (IV). The IV can be generated individually by a random number generator (RNG) for example for each encryption and be transmitted for example as plain text. In the case of an asymmetrical key pair, for example, a digital signature is provided for checking integrity.

(50) For GLA tokens: A lock has a group key S.sub.T2. In order to open the lock, a GLA token requires a valid access authorization B. In this case, the key S.sub.T2 is in turn used to verify the access authorization B. The key S.sub.T2 together with a key S.sub.T1 forms a key pair, which can be symmetrical or asymmetrical.

(51) The keys S.sub.2 and S.sub.T2 are generated in the process for producing the lock, for example, and are stored in the lock. Both keys must be adequately protected in the lock against unauthorized accesses. Both keys, together with management data of the lock and a unique identifier (LockID), are communicated to the key server 60 and stored there. The key server 60 then uses the keys S.sub.1 and S.sub.T1 for cryptographic protection of the access authorizationsin order to allow the verification of the validity of the access authorizations at the lockand the key S.sub.1 further for protection of the rejection list and the group key information.

(52) Cryptographic Keys for ILA Tokens

(53) Each ILA token is equipped with a third key H.sub.3, which together with a fourth key H.sub.4 forms a symmetrical (that is to say H.sub.3=H.sub.4) or asymmetrical (that is to say H.sub.3?H.sub.4) key pair (H.sub.3, H.sub.4). Said key H.sub.3 is used for authentication of the ILA token at the lock to which the key H.sub.4 is made available at least temporarily. In this case, the key server uses the key pair (H.sub.3, H.sub.4) in order to ensure access authorization to the lock by the ILA token. During the initialization of the ILA token, in the process the key H.sub.3 is installed and stored on the key server.

(54) The key H.sub.3 can further be issued for a group of ILA tokens. In this case, all the ILA tokens of a group are then equipped with the same key H.sub.3. A plurality of keys can exist in parallel on an ILA token, that is to say that one or more group keys can be present alongside one or more individual keys on an ILA token. (Even though mention is made here of groups of tokens, these should nevertheless be regarded as individual access authorizations that allow access to individual locks rather than to groups of locks.)

(55) A group key can be installed on the device during or after the initialization process, but the key must exist on the device at all events prior to use.

(56) Cryptographic Keys for GLA Tokens

(57) Each GLA token is equipped with a key H.sub.3 which, together with a key H.sub.4, forms a symmetrical or asymmetrical key pair (H.sub.3, H.sub.4). The key H.sub.3 is used to obtain access to a group of locks that have the key H.sub.4 at least temporarily. The key server uses the key pair (H.sub.3, H.sub.4) to allocate access authorizations for a group of locks to the GLA token.

(58) The key H.sub.3 is installed on the device during the initialization process and is stored on the key server.

(59) Structure of the Access Authorizations

(60) Access authorizations are granted by the key server. An access authorization can contain one or more of the following access authorization parameters: KeyID: ID of the access authorization (allocated by the key server) LockID: ID of the lock For ILA tokens: The lock number and MAC address are communicated to the key server by the task management. Part of the LockID can be used for example to differentiate or to identify different lock manufacturers. For GLA tokens: In this case, the LockID is the ID of the group to which the parcel box with the concrete key belongs. NotBeforeDate: Date valid from with year/month/day NotAfterDate: Date valid until with year/month/day StartTimeOfDate: Time of day starting from when the access authorization is valid (standard e.g. 00:00:00) EndTimeOfDay: Time of day until when the access authorization is valid (standard e.g. 23:59:59) MaxUses: Number of uses; standard 0 means unlimited Permissions: Setting permission for safety-critical operations, e.g. whether it is permitted to open the parcel compartment and/or to open the parcel compartment and the letter compartment.

(61) An access authorization can be identified by a unique KeyID. The LockID describes the lock (or the group of locks) for which the access authorization is valid. In this case, for example, a predefined number of bit positions of the LockID (e.g. four bits) can carry a coding that indicates whether an individual identifier or a group identifier is involved. With such a code, the lock can recognize which key it is supposed to use for the decryption: the individual key S.sub.2 or one of group keys S.sub.T2. The manufacturer from which the lock originates can also be coded in this code, or in other bit positions of the LockID.

(62) It may happen that a lock must include a plurality of group keys if the parcel box is situated in a zone that constitutes an overlap of two delivery groups. This will be explained in even further detail below.

(63) The two parameters NotBeforeDate and NotAfterDate define the period of validity of the access authorization, with the accuracy of one day. NotBeforeDate defines the date of the first use and NotAfterDate defines the last date in the period of validity. Further, StartTimeOfDay specifies the time of day from when the period of validity begins, and EndTimeOfDay specifies when said period of validity ends. The accuracy is one second, for example. However, other possibilities for the definition of validity intervals are also conceivable, for example in the form of a printer or index that refers to individual entries of a plurality of predefined periods of validity which for example are stored in each case in the key server and in the lock or can be calculated from the index according to a predefined rule. By way of example, in the case of access authorizations that are valid for a respective date, just the date of validity can be used as access authorization parameter, said date being specified for example as an offset with regard to a predefined reference date (e.g. 1.1.2014), that is to say for example as 20 if the access authorization is intended to be valid on 1.21.2014. MaxUses defines how often the key can be used to open a lock. In this case, the value 0 stipulates for example that the key is permitted to be used without limitation in the period of time. Permissions codes, for example by the setting of individual bits in a bit string, what security-critical operations a token is permitted to perform, as has already been enumerated above by way of example (a bit set to 1 then indicates for example in each case the presence of the authorization).

(64) The key server grants an access authorization B for a lock. Depending on the type of token, the server generates the value V, as the result of cryptographic operations on the access authorization B using the key S.sub.1 or the key S.sub.2. The cryptographic operations can designate for example the formation of an MAC value by means of B with a symmetrical key S.sub.1 or the formation of a digital signature by means of B using an asymmetrical key S.sub.1, to give just a couple of non-restrictive examples.

(65) Structure of the Rejection List

(66) KeyIDs can be locked for a lock by rejection lists from the key server 60. In this case, the list contains all KeyIDs of the access authorizations which were revoked for an associated period of time of the access authorizations by the lock. Access authorizations that are no longer valid on account of their period of validity are removed from the list, for example, in order to keep said list short and thus to ensure a low storage requirement in the locks. It is for example not possible to reverse a revocation of an access authorization once said revocation has been initiated. If an access authorization has been revoked, it is no longer possible to open the lock using this access authorization.

(67) The key server 60 generates the rejection information L (which contains the rejection list) and check information VL, which for example is again based on cryptographic operations on L using the key S1.

(68) The rejection information L can contain for example the identifier (e.g. LockID) of the lock to which the rejection list relates, and a list of the KeyIDs to be locked. Further, a unique counter for the rejection list can be included, which indicates the ordinal number of the present rejection list for the lock. A corresponding counter can then be implemented in the lock in order to be able to check the validity of the current rejection information.

(69) Lock Opening Using a Handheld Scanner or a Cellular Phone

(70) A lock is opened after a token has authenticated itself by communicating a valid access authorization. This process is illustrated in the flow diagram 400 in FIG. 4.

(71) The token (handheld scanner 68 or cellular phone 61) has received for example the following data from the key server: an access authorization B and first check information V, a third key H3 and an authentication value A, which comprises a combinationencrypted using S1of at least H4 and the KeyID of the access authorization B. In the case of a symmetrical encryption, the initialization vector IV of a CBC mode of the encryption may likewise have been received.

(72) The process 400 of opening a lock then proceeds as illustrated as follows (cf. FIG. 4).

(73) In a step 401, firstly a Bluetooth connection between token 61, 68 and lock (of the parcel box 69) is set up, preferably using the MAC address of the lock that is known to the token 61, 68, in order to avoid Bluetooth pairing.

(74) In a step 402, the token 61, 68 authenticates itself vis-?-vis the lock on the basis of the key H3. For this purpose, at least the information A is communicated to the lock, from which information the lock can obtain the key H4 using its key S2. On the basis of H3 and H4, the token 61, 68 and the lock can then perform an authentication protocol known to the person skilled in the art, for example a challenge-response method, in which the token 61, 68 applies the key H3 to a challenge (and possibly further information) received from the lock and transmits that as a response to the lock, which can then in turn check the response on the basis of the key H4 in order to determine the authenticity of the token 61, 68.

(75) After authentication of the token 61, 68 has been performed, or in a process combined with said authentication, the token 61, 68 further communicates the information B and V to the lock.

(76) In a step 403, the lock can then check the authenticity and integrity of B and V vis-?-vis the key server 60, that is to say determine whether B and V originate from the key server and have not been altered. The lock uses the key S.sub.2 for this purpose. In the case of a successful check, the access authorization parameters of B are checked against reference information present in the lock, in order to determine whether the lock can be opened on the basis of B.

(77) In particular, in this casedepending on the presence of the respective access authorization parameters in the access authorization informationthe following can be checked, wherein the order of the checks can be arbitrary and they can already be terminated in the event of a condition not being met, or the process can jump to step 404, in order to save time and/or power: Whether the KeyID (decrypted from A) corresponds to the KeyID of the access authorization. Whether the access authorization is still valid from a temporal standpoint (by comparison with a clock of the lock), Whether the access authorization is not in the rejection list for the lock. Whether the LockID of the access authorization matches the LockID of the lock. What extent of access is permitted by the Permissions. MaxUses is coordinated against the internal counter of the lock and the counter is correspondingly incremented.

(78) In step 404, a feedback indication is then signaled to the token 61, 68 (e.g. OK, ERROR, WARNING), and, given a positive result of all the checks performed, preparations are made for the lock opening.

(79) The key H.sub.3 was issued to the token 61, 68 for example during an initialization phase (particularly in the case of the token 61, for example an initialization of an app on the cellular phone 61) or was transferred as group key H.sub.3 (particularly in the case of the token 68). The corresponding or identical key H.sub.4 is communicated to the lock in encrypted form. As a result, the lock need not store all keys H.sub.4 of all devices and can be used extremely flexibly and offline. Further, the KeyID of the access authorization is encrypted together with the key H.sub.4. The key of the token is thus linked to the current access authorization of the lock. The challenge-response method is used in order to protect the protocol against so-called replay attacks.

(80) Lock Opening Using an NFC Tag

(81) A lock is opened after a token 62, 74 has authenticated itself vis-?-vis the lock (of a parcel box 69) by communicating a valid access authorization.

(82) This process is illustrated in the flow diagram 500 in FIG. 5.

(83) The token 62, 74 has for example once again received the information B, V, A and H3, and if appropriate IV, and stores this information, wherein, in the case of an ILA token, V is based on cryptographic operations on at least B with the key S1 and, in the case of a GLA token, V is based on cryptographic operations on at least B with the key ST1. In a similar manner, in the case of an ILA token, A is based on an encryption of the combination of at least H4 and the KeyID of B with S1 and, in the case of a GLA token, A is based on an encryption of a combination of at least H4 and the KeyID of B with ST1. In the case of ILA tokens and GLA tokens, the key H3 (and its partner H4) can be chosen differently for example for each token. In contrast to the tokens 61, 68, in the case of the tokens 62, 74, the information B, V, A and H3 possibly has greater longevity since the outlay for writing this information is costly and is preferably implemented only once, in particular during the production of the tags 62, 74 or in the context of delivery or start-up.

(84) Depending on the architecture of the token 62, 74, the third key H3 (which can also be referred to as device key) can be stored in a memory of the token, said memory not being accessible externally, and can be accessible only internally, for example for a processor of the token 62, 74, while the authentication information A is stored for example in a memory area that can be read by a reader (e.g. an NFC reader in particular of the lock). B and V can be contained in a memory area that is enabled for reading for example only if a mutual authentication has taken place between the reader/lock and the token 62, 74.

(85) The process 500 of opening a lock then proceeds as illustrated in FIG. 5. In a step 501, an initialization of the NFC communication between token 62, 74 and lock takes place.

(86) In step 502, a mutual authentication takes place between token 62, 74 and lock on the basis of the keys H3 and H4. For this purpose, the lock for example firstly reads out the information A from the token 62, 74 and obtains the key H4 therefrom by decryption using the key S2 or the key ST2. Which key S2 or ST2 has to be used by the lock can be identified by the lock for example on the basis of the LockID, which for example is likewise read out from the token 62, 74 (for example as part of A or separately therefrom), for example on the basis of predefined bit positions indicating whether an ILA token (->use of S2 necessary) or a GLA token (->use of ST2 necessary) is involved. Insofar as necessary depending on the type of encryption, an initialization vector IV can also be read out from the token 62, 74, for example as part of A or separately therefrom. On the basis of H3 (token) and H4 (lock), an authentication protocol is then performed, for example the DESFire authentication protocol or any other authentication protocol, which can be based for example on a challenge-response method. It may also suffice here, for example, for the lock to authenticate itself vis-?-vis the token 62, 74, for example to convert a challenge supplied by the token into a response using its key H4, said response being counterchecked in the token on the basis of H3.

(87) In the case of successful authentication, the token 62, 74 can enable the lock (or the reader thereof) for example to read out the information B and V.

(88) The authenticity and integrity of B and V are then checked in step 503 analogously to the description given with regard to step 403 in FIG. 4, but V is checked either on the basis of S2 (in the case of ILA tokens) or on the basis of ST2 (in the case of GLA tokens). Which key S2/ST2 is intended to be used can be decided on the basis of the structure of the LockID contained in the token, as has already been explained.

(89) With regard, too, to the check of the access authorization parameters contained in B, reference can be made to the description concerning step 403 in FIG. 4, with the difference that the LockID contained in B is compared either with the LockID of the lock (in the case of ILA tokens) or with the GroupID of the lock (in the case of GLA tokens).

(90) The lock is opened if B and V have been found to be authentic and to have integrity, the check of the access authorization parameters in relation to their reference variables present in the lock has proceeded positively and the permissions indicate that opening of at least one door is permissible.

(91) Communication of the Rejection List

(92) In the communication of the rejection list, the token need not authenticate itself, for example. A reply attack cannot be performed on account of the counter (Counter) contained in the rejection list. The distribution of the rejection lists among the locks can preferably be performed by the handheld scanners 68 and the cellular phone 61; however, GLA tokens 74 can also be used for this purpose, which GLA tokens are specifically reprogrammed for this case, such that they can include and communicate rejection lists.

(93) The process 600 for communicating the rejection list by means of ILA tokens (e.g. handheld scanner 68, cellular phone 61 and tag 62) is described below. In this case, the ILA token receives for example the following information from the key server: rejection information L (which contains the rejection list) and fourth check information V.sub.L, which is generated for example by cryptographic operations being performed on at least L using S.sub.1 (ILA token) or S.sub.T1 (GLA token).

(94) The process 600 then proceeds as follows. In step 601, the token 61, 68, 74, after a Bluetooth or NFC connection has been set up, communicates the rejection information L and the validation feature V.sub.L. In step 602, the lock checks the authenticity of L on the basis of V.sub.L and the key S.sub.2 or S.sub.T2, which are in turn selected on the basis of the structure of the LockID in L. For example the contents of L can then be checked, that is to say e.g. whether the LockID matches the LockID of the lock, and/or whether the value of Counter is greater than the value maintained in the lock for the rejection lists. If this is the case, the new rejection list from L is accepted in the lock (by replacement of the old rejection list) and the value for the rejection lists in the lock is set to the value of Counter from L. In step 603, a feedback indication is then signaled to the token (OK, ERROR, WARNING) (step 603).

(95) The value of Counter ensures that the rejection list cannot be replaced by an old rejection list. Since the rejection listwhen it is generatedis complete, the key can replace all previous KeyIDs with the current KeyIDs. In this case, in particular KeyIDs of access authorizations that are no longer valid are removed from the rejection list in order to keep the latter small.

(96) Update of Group Keys

(97) The key S2 that is responsible for the individual access remains constant for example during the complete life cycle of the lock. However, the key ST2 that is responsible for the group access possibly needs to be exchanged once or a number of times (this can occur, for example, if a parcel box is moved to a different delivery area). For this reason, the changeable key ST2 is protected according to the invention by the invariableand therefore more securekey S2.

(98) By way of example, handheld scanner 68 and cellular phone 61 are intended to be able to exchange the key ST2 (or, if appropriate, a plurality of keys ST2 present on the lock). For this purpose, the key server 60 creates group key information comprising, for example, one or more components from the following: a LockID, that is to say the ID of the lock to which the update relates, an update_counter as unique counter for the update, and one or more entries, that is to say the group key list with the tuples (GroupID, ST2).

(99) The token 61, 68 then receives from the key server 60 for example a packaged key value W, which encrypts at least the new group key(s) ST2 and respective new GroupIDs using the individual key S1 of the lock (or for example the entire group key information). Thus, the new key ST2 is not present in plain text on the handheld scanner 68 or cellular phone 61 and can be decrypted only by the respective lock. Further, the key server 60 also creates a validation value VW, which is generated for example by cryptographic operations on at least W using the first key S1. The cryptographic operations can in turn constitute for example an MAC function or a digital signature using S1.

(100) The communication process 700 illustrated in FIG. 7 then proceeds as follows. In step 701, a token 68 communicates W and VW to the lock. Step 702 then involves evaluating the check information VW in order to determine the authenticity and integrity of W and VW using the key S2. In the event of a positive result, the group key list can be decrypted using the key S2 and further checks can be performed to ascertain whether this group key list is permitted to be accepted in the lock, e.g. on the basis of a check whether the LockID from the group key information (obtained by decryption of W) matches the LockID of the lock, and/or whether the value update_counter from the group key information is greater than the corresponding value of the update-counter for the current group key(s) in the lock. If the checks are successful, the current group key(s) ST2 and the respective GroupID are replaced by the new values from the group key list and the update_counter in the lock is replaced by the value of the update_counter from the group key information. Step 703 then involves signaling the feedback indication to the token (OK/NOK).

(101) In this case, the update_counter in turn prevents replay attacks in which the attacker might attempt to position one or more old group key(s) in the lock. The LockID in the group key information ensures that the update comes from key server 60 and was created for the concrete lock. A further important process step, which is not presented explicitly here, is that the key server 60 receives the return information (for example from the token 68) as to whether or not the new group key(s) were stored in the lock. This information is necessary in order that the key server can generate in the future usable access authorizations for GLA tokens.

(102) Order of the Operations

(103) FIG. 11 shows an exemplary flow diagram 1100 which illustrates the possible order of operations in a lock according to the invention. What operations are generally intended to be performed by the lock can be communicated to the lock from the token for example by means of one or more commands. In this regard, it is possible, for example, to perform a plurality of operations in a communication session, for example a group key update, an installation of a new rejection list and a check of access authorization in order to bring about opening of the door. Depending on the desired operation, one or more of the above-described values B, V, A, W, V.sub.W, L, V.sub.L illustrated in FIG. 1 are then transmitted from the token to the lock.

(104) After the Start 1101, either one or more group keys can be updated on the lock (step 1102), a new rejection list can be installed in the lock (step 1103), a token authentication (with the aid of the key H4) can be performed (step 1104) or a firmware update of the lock software (step 1110) can be performed. As illustrated in FIG. 11, some steps here, e.g. steps 1102, 1103 and 1104, can also be performed one after another. FIG. 11 should be understood such that each operation is optional, in principle, that is to say that for example only step 1102, step 1104 and step 1109 can be performed if so desired. Further, the processing can therefore also be ended after each operation, for example after step 1102.

(105) After successful token authentication 1104, either the electronics can be reset (Reset in step 1109), the status of the lock can be interrogated (step 1108), or a check of an access authorization B obtained can be performed (step 1105). After both steps, a reset can optionally also be performed (step 1109). If the access authorization B provides authorization for example for opening one or more doors of the parcel box 69, said door(s) is/are opened (step 1106). After interrogation of the status (step 1108), too, optionallygiven the presence of authorizationthe door can be opened (step 1106).

(106) As is evident from FIG. 11, no opening of the door takes place after the reset (step 1109) or the firmware update (step 1110). Further, the installation of the rejection list (step 1102) and the update of the one or the plurality of group keys (step 1102) always takes place before the access authorization check since the rejection list or the group key(s) may be required in this check.

(107) An explanation is given below, for the exemplary embodiment of the access control system in FIG. 3, of how the assignment of the access authorizations and keys to the devices of the deliverers 70 and users 63 and to the parcel boxes 69 is performed.

(108) Delivery Process Using Handheld Scanner

(109) The assignment server 69 performs the so-called area cutting, that is to say dynamically defines delivery areas on the basis of the daily amount of mail and the available delivery personnel. In the context of said area cutting, the parcel boxes 69 belonging to a respective area are identified on the basis of their parcel box address (or the addresses of their users). It is assumed that this assignment is performed dynamically, that is to say that beforehand no statement can be made regarding which parcel boxes 69 will belong to which area.

(110) The master datadescribed in even greater detail belowof the parcel boxes, which comprise inter alia the access authorizations to the respective parcel boxes and the key H3, and for example also the address data of the parcel box users are then distributed regionally in a plurality of intermediate steps, the intermediate steps being irrelevant to the following considerations. Ultimately, in general one, but if appropriate also a plurality of areas are assigned to a decentralized unit (e.g. a computer or a server) from which the refueling of the handheld scanners 68 with the master data (and the address data of the parcel box users) for a chosen area is performed. The mail data (desired data) are likewise transferred to the handheld scanner from the decentralized unit in the context of the refueling.

(111) The assignment of the handheld scanners to an area is performed dynamically and downstream of the area cutting.

(112) The above process can be summarized as follows: 1. Define delivery areas (for example primarily on the basis of the delivery/collection addresses of mail, the amount of mail and the available delivery personnel) 2. Distribute master data of the parcel boxes (and address data of the parcel box users) assigned to the delivery areas among the decentralized units 3. Register deliverer 70 with the handheld scanner 68 at the decentralized unit 4. Deliverer 70 collects parcels for his/her area 5. Deliverer 70 delivers the parcels for the parcel boxes 69 in his/her area

(113) If the access authorization is created for a handheld scanner 68, 1 day, for example, is provided as the period of validity. Further, a parameter that limits the maximum number of uses of said access authorization is provided, for example.

(114) Access Authorizations for Handheld Scanners

(115) The key server 60 generates access authorizations B for each lock (of a parcel box 69) together with a respective corresponding validation feature V. Each deliverer 70 is intended to receive, together with the validation features V, access authorizations B for those parcel boxes 69 (i.e. their locks) to which said deliverer is intended to deliver on the day, that is to say those of his/her delivery area.

(116) FIG. 8 gives an overview of one exemplary process 800 of delivery with access authorizations. The sequence is as follows:

(117) The key server 60 generates in step 801 every day, for example, the access authorizations B.sub.i (wherein the index i=1 . . . N denotes the respective lock from a total of N locks), which are validated in each case with a corresponding lock key S.sub.1,i (which once again together with a key S.sub.2,i stored in the lock forms a symmetrical or asymmetrical key). For this purpose, pairs (B.sub.i,V.sub.i) are calculated, wherein B.sub.i is an access authorization and V.sub.i is the associated first check information already described here which is generated using the key S.sub.1,i. Further, the key server generates e.g. a device key H.sub.4 (which together with a further key H.sub.3 forms a symmetrical or asymmetrical key pair), with which a handheld scanner 68 can authenticate itself vis-?-vis a lock of a parcel box 69, and encrypts the latter (and for example one or more further parameters, e.g. the KeyID) with the respective lock key S.sub.1,i, in order to generate an authorization feature A.sub.i.

(118) In step 802, all the access authorizations are transmitted e.g. daily (for example in accordance with the generation frequency of the key server 60) from the key server 60 to the provision server 66. In particular, the following master data are transmitted per lock: access authorization B.sub.i, validation V.sub.i, and authorization feature A.sub.i. The LockID can also optionally be contained therein. In the provision server, the master data can be augmented by further information, for example the MAC address of the lock, and/or address information of the parcel box and/or address information of the users of the respective parcel boxes, to give just a few examples. However, such information may also already have been added to the master data at the key server 60. As already mentioned, the MAC address is the Medium Access Control address of the lock, by means of which the lock can be addressed directly for example without the need for Bluetooth pairing. Only the transmission of the plurality of master data sets {Bi, Vi, Ai} and of the lock H.sub.3 to the provision server is illustrated in step 802 in FIG. 8, for reasons of clarity.

(119) In step 803, the area cutting takes place in the assignment server 67.

(120) In step 804, each of the L decentralized units 71-1 . . . 71-L receives all the access authorizations for the areas assigned to it on this day. This is constituted symbolically by the notation {B.sub.i, V.sub.i, A.sub.i}.sub.l in step 804, wherein the index l runs from 1 to L and the notation {B.sub.i, V.sub.i, A.sub.i}.sub.l denotes the master data of all the parcel boxes in the area l (wherein once again for reasons of clarity the further master data elements LockID, address information and MAC address are not illustrated and it is assumed that each decentralized unit obtains only the master data of the parcel boxes of a respective delivery area, although this is not mandatory). A decentralized unit then refuels one (or else a plurality of) handheld scanner(s) within a delivery area l with the master data {B.sub.i, V.sub.i, A.sub.i}.sub.l of the parcel boxes of this delivery area.

(121) A handheld scanner 68-2 (this is, for example, a handheld scanner assigned to the second decentralized unit 71-2 and the delivery area l=2 thereof) obtains, in the context of the refueling, the master data {B.sub.i, V.sub.i, A.sub.i}.sub.2 of the parcel boxes for the area l=2 to which it was allocated (step 805). This can be performed for example by means of wired communication (e.g. via a docking station which is connected to the decentralized unit 71-2 and into which the handheld scanner 68-2 is placed) and/or wireless communication (e.g. by means of WLAN or GRPS).

(122) In step 806, the handheld scanner 68-2for the purpose of opening a parcel box 69-k in its area, selected by way of examplewith the aid of the MAC address of the lock of said parcel box 69-k determines a Bluetooth connection to the lock and transmits the access authorization B.sub.k, the validation information V.sub.k, the authorization feature A.sub.k and further validation information, as described with regard to FIG. 4, to the lock (step 806).

(123) In step 807, the lock validates the authorization on the basis of V.sub.k and S.sub.2,k (analogously to the description of FIG. 4) and opens in the case of correct authorization. Step 808, finally, involves sending a corresponding status message and for example the battery status back to the handheld scanner.

(124) As is evident from the explanations above, the authentication of the handheld scanner 68-2 vis-?-vis the lock of the parcel box 69-k is performed with the aid of the key H.sub.3. No individual device key H.sub.3 is assigned to the handheld scanner 68-2. Instead, a group key H.sub.3 is generated, wherein all the handheld scanners 68 form the group in this regard and use the same key H.sub.3. In the context of the refueling, the group key H.sub.3 is transmitted to a handheld scanner. An access authorization for this group key H.sub.3 is then issued per lock, said access authorization effectively being valid for all the handheld scanners. The key H.sub.3 is transmitted for example from the key server 60 to the provision server (step 802), and then to all the decentralized units (step 804), preferably via secure connections, in order to prevent it from being spied out. By way of example, the transmission from the key server 60 to the provision server 66 and/or to the decentralized unit 71-2 is performed in an encrypted manner by means of SSL/TLS. The connection between decentralized unit 71-2 and handheld scanner 68-2 in the refueling should likewise be correspondingly safeguarded.

(125) Blocking of Handheld Scanners

(126) The access authorizations with which the handheld scanners 68 operate are in each case issued anew for example for 1 day. If it is necessary to block a handheld scanner 68, for example after loss of the device, it is necessary to create a rejection list for each lock to which the handheld scanner 68 had access. The rejection list would then have to be brought by means of a kind of token to the corresponding locks and loaded therein, but this means a considerable outlay.

(127) This problem is adequately solved by virtue of the fact that the access authorizations B are issued for as narrow a time window as possible (e.g. temporal validity only 1 day) and/or for the fewest possible uses (e.g. a maximum of 3 uses per day). Further or alternatively, the handheld scanner software can restrict the use of the access authorizations as much as possible, for example by the opening of a lock of a parcel box 69 being offered only if a corresponding piece of mail is also present for said parcel box 69 (this can be achieved for example by coordination of the address data (e.g. zip code, street and house number, contained in coded form in the so-called routing code) of mail with the address data (which are coded for example in a similar form to that in the case of the routing code)contained in the master dataof parcel boxes 69 and/or the addresses (which are coded for example in a similar form to the case of the routing code) of the users 63 of parcel boxes 69 (by means of which a parcel box 69 can then in turn be uniquely assigned). These addresses are transmitted to the handheld scanner particularly for this purpose). In particular, the situation should also be prevented in which a blocked handheld scanner, in particular after loss, on subsequent days is connected to a decentralized unit and refueled.

(128) As a result of this procedure, a dedicated blocking of handheld scanners 68 by means of rejection lists is not absolutely necessary. In particular, the rejection lists that serve for blocking other lost ILA and/or GLA tokens (e.g. cellular phones 61, deliverer tags 74 and user tags 62) then remain smaller, which is advantageous since they have to be stored by the lock. The advantages afforded by rejection lists for the use of cellular phones 61 and, if appropriate, NFC tags 74, 62 (on which the access authorizations have a longer temporal validity than the access authorizations present on the handheld scanners 68) do not exist for the handheld scanners in the case of the procedure described above.

(129) Transmission of the Rejection Lists

(130) As is evident from FIG. 11, the handheld scanner 68 does not have to authenticate itself vis-?-vis the lock in the transmission of a rejection list (step 1103). Accordingly, the limitations that occur with the use of access authorizations (in particular with regard to authentication) do not exist. The rejection lists can be augmented for example per lock as master data in the provision server 66 and can be transmitted to the handheld scanners 68 in refueling. This may have the effect that the opening of a lock takes longer, since, in accordance with FIG. 11, the communication of the rejection list to the lock (step 1103) takes place before the authorization check (step 1105). Since, moreover, the key server 60 has no information about the successful communication of a rejection list to a lock, the current rejection list would be distributed and transmitted in the event of each access to the lock.

(131) The following procedure appears to be advantageous: blockings are performed by a main user, a co-user or on behalf thereof. The rejection lists thereupon generated by the key server 60 are then transmitted to the lock of the parcel box 69 by the corresponding cellular phone. Via the provision server 66, the handheld scanner 68 notifies the key server 60 of the successful or unsuccessful transmission of the rejection list to the lock.

(132) Keys for Delivery Personnel with NFC Tokens

(133) As described in sections, there is a difference between tokens of the ILA type (handheld scanner 68, cellular phone 61, NFC tokens 62 of parcel box users 63) and of the GLA type (NFC tokens 74 of delivery personnel 70). There are various reasons for this differentiation, which are mentioned below: 1. NFC tokens cannot be equipped with access authorizations without a certain outlay. 2. NFC tokens of delivery personnel should be able to open all locks in a specific, in particular static, area. 3. NFC tokens are unable to store many access authorizations.

(134) Requirement (2) makes it clear that delivery personnel 70 should be equipped with an NFC token 74 that is valid in a specific area. For this purpose, a group key S.sub.T2 that can open a group of locks (and thus parcel boxes 69) is stored on the NFC token 74. As is evident from requirement (3), it is not possible to equip delivery personnel 70 with individual access authorizations for all locks in a specific area.

(135) For this reason, the lock is equipped with two or possibly more (symmetrical or asymmetrical) keys: one key S.sub.2 (individual key, with a corresponding symmetrical or asymmetrical key S.sub.1) for interacting with ILA tokens, and one or more keys S.sub.T2 (group key, with a corresponding symmetrical or asymmetrical key S.sub.T1) for operations with the GLA tokens of the delivery personnel 70. The main difference between these keys is that the first-mentioned key S.sub.2 is unique for each lock and the further key S.sub.T2 is shared by a plurality of locks.

(136) While the unique key S.sub.2 of the lock is applied during the production processand is invariable, in particularthe group key S.sub.T2 can be changed dynamically (e.g. by a handheld scanner 68) during the operating time of the lock.

(137) The exchangeable keys S.sub.T2 for GLA tokens are described below.

(138) The key server 60 generates an access authorization and provides the latter with validation information in accordance with the corresponding group keys S.sub.T1 of a respective delivery area. The device keys are applied, together with an access authorization, to the NFC tokens of the delivery personnel.

(139) This is illustrated schematically in FIG. 9. Here the NFC tokens (M pieces) 74-1 . . . 74-M are distributed to respective delivery personnel (e.g. via a server of token production 73), in order to be able to open locks in N areas (area 1 . . . area N). Correspondingly, via the server of lock production 72 (or later by means of the update function for group keys), the group keys S.sub.T2,1 . . . S.sub.T2,N are stored in the locks of the parcel boxes of the respective areas 1 . . . N, that is to say group keys S.sub.T2,1 are stored in the locks of the parcel boxes of area 1, etc.

(140) It is assumed that an NFC token i requires access to all locks in a delivery area j. In this case, the token i requires the following information (data): access authorizations B.sub.i; validation feature V.sub.i of the delivery area j (formed by cryptographic operations on Bi using the group key S.sub.T1,j); authentication value A.sub.i, which in turn comprises at least one combinationencrypted using S.sub.T1,jof at least the key H.sub.4,i and the KeyID.sub.i and for example further comprises the LockID.sub.j that codes the group identifier of the area j. It then holds true that, in a delivery area j (j from 1 to N), any delivery personnel having access authorization for the area j can open every lock using the NFC token of said delivery personnel.

(141) Delivery areas are static in their nature. In this case, requirement (1) must be taken into consideration, which states that it is technically and economically laborious to alter (update) the access authorizations too often. On the other hand, use should not be made of access authorizations which are valid forever, which constitutes an increased security risk. For this reason it is expedient to issue access authorizations for an extended but limited period of time, e.g. a few months or years. After the period of validity has expired, all tokens must be reprogrammed in order to obtain new access authorizations Bi.

(142) Group Keys

(143) In the system in FIG. 3 it may be provided, for example, that letter deliverers use the NFC tags 74 for opening parcel boxes (for example for delivering large-format letters), and that the NFC tags 74 are also used by parcel deliverers at least at times (for example as an alternative to handheld scanners 68). In this case, it should be taken into consideration that delivery areas for deliverers in ZB (standard delivery, delivery bases) and ZSPL (combination delivery, that is to say delivery of letters and parcels) can overlap.

(144) Therefore, there is the possibility that a parcel box sometimes is opened using a tag that belongs to one specific delivery area, and sometimes is opened using a different tag that belongs to a different delivery area.

(145) This is illustrated schematically in FIG. 10. In this case, a first parcel box 110 is assigned only to a first delivery area 11 (ZB), and a second parcel box 120 is assigned to a second delivery area 12 (ZSPL), while a third parcel box 130 is assigned both to the first delivery area 11 and to the second delivery area 12.

(146) This problem can be solved by virtue of the fact that those parcel boxes which are situated in an overlap area (e.g. parcel box 130 in FIG. 10) can obtain two group keys and then grant access for both tags (possibly even more than two, but for example a maximum of five).

(147) Each delivery area (group) has a GroupID (group identifier). The group keys S.sub.T2 are then stored together with corresponding GroupIDs in the lock:

(148) (GroupID.sub.1, S.sub.T2,1), (GroupID.sub.2, S.sub.T2,2), . . .

(149) If the delivery base area ZB 11 has a GroupID GroupZB and the ZSPL 12 has a GroupID GroupZSPL, and S.sub.T2,ZB and S.sub.T2,ZSPL are the corresponding group keys, then the lock of the parcel box 110 has stored the tuple (GroupZB, S.sub.T2,ZB), the lock of the parcel box 120 has stored the tuple (GroupZSPL, S.sub.T2,ZSPL), and the lock of the parcel box 130 has stored both tuples (GroupZB, S.sub.T2,ZB) and (GroupZSPL, S.sub.T2,ZSPL). Each of the locks further also has a respective individual key S.sub.2,l, as has already been described above.

(150) During the authentication phase, a token transmits the LockID, which is also situated in the access authorization for the lock. The LockID gives the lock an instruction (e.g. by means of a coding of predetermined bit positions of the LockID) with regard to which key is intended to be used for the decryption and validation. The LockID indicates either the individual key S.sub.2 of the lock or one of potentially a plurality of group keys S.sub.T2 by virtue of the GroupID being correspondingly coded into the LockID.

(151) In the above example, a deliverer of ZB 11 can open the lock of the parcel box 130 by communicating GroupZB as part of the LockID. Equally, a deliverer of ZSPL 12 can open the lock of the parcel box 130 by communicating GroupZSPL as a part of the LockID. The lock has both keys and can react accordingly.

(152) If a GLA token, e.g. from the area ZB 11, is lost, only the locks of the parcel boxes in the area ZB 11, in particular the parcel boxes 110 and 130, have to receive a corresponding rejection list update. By contrast, the locks of the parcel boxes of ZSPL 12 do not have to be provided with a new rejection list.

(153) Keys H and Access Authorizations of the NFC Token of the Owner

(154) An explanation has already been given of how the key server 60 generates the access authorizations and keys for the handheld scanners 68 and how these access authorizations are transmitted to the handheld scanners 68. The key server 60 also generates the keys and access authorizations for the user 63 of the parcel box, in particular the owner thereof. The user 63 of the parcel box always has an NFC token 62 available, for example. By way of example, the user 63 obtains two NFC tokens 62 for his/her parcel box 69 in the course of an order.

(155) The opening of the lock of the parcel box 69 using an NFC token 62 then proceeds as follows. The key server 60 generates the access authorization B for the NFC token 62, which is validated in each case with a corresponding (lock-specific) key S.sub.1. The key S.sub.1 together with a key S.sub.2 stored in the lock forms a symmetrical or asymmetrical key pair. A pair (B,V) is calculated as already described a number of times, wherein B constitutes an access authorization and V constitutes for example an MAC or a digital signature for the authorization B using the key S.sub.1. An authentication feature A is also calculated, which comprises a combinationencrypted using S1of at least the key H4 and the KeyID and for example further the LockID, wherein H.sub.4 together with a key H.sub.3 forms a symmetrical or asymmetrical key pair and the key H.sub.3 is stored in the token. KeyID is an identifier of the access authorization and LockID codes the individual identifier of the lock. The authorization B and the features V and A and the key H.sub.3 are transferred to a programming station. The programming station writes the data B, V, A, H.sub.3 to the NFC token(s) 62 of the user 63. For opening the parcel box 69, the NFC token 62 determines a connection to the lock of the parcel box 69, authorizes itself vis-?-vis the lock and transmits the access authorization and validation features (cf. the description concerning FIG. 5). The lock validates the authorization with the aid of the validation features and opens in the case of sufficient authorization.

(156) As exemplary embodiments of the present invention, the following are further intended to be disclosed:

(157) Exemplary Embodiments 1-33: The embodiments defined in claims 1-33.

(158) Exemplary Embodiment 34:

(159) A method for generating access authorization information (B, V), the method comprising generating first check information (V) by performing cryptographic operations on one or more access authorization parameters (B) using at least one first key (S.sub.1, S.sub.T1) of a symmetrical or asymmetrical key pair, generating access authorization information (B, V) comprising at least the one or the plurality of access authorization parameters (B) and the first check information (V), and outputting the access authorization information (B, V) for storage on an access authorization proving apparatus (3) configured to communicate the access authorization information (B, V) to at least one access control apparatus (4) in order to enable the latter to decide whether access is permitted to be granted on the basis of the communicated access authorization information (B, V), wherein necessary conditions for granting access are that first checking, using at least the communicated access authorization parameters (B), the communicated first check information (V) and a second key (S.sub.2, S.sub.T2) of the key pair, said second key being stored in the access control apparatus (4), whether the communicated first check information (V) was generated by performing cryptographic operations on access authorization parameters (B) corresponding to the communicated access authorization parameters (B) using at least the first key (S.sub.1, S.sub.T1) of the key pair, yields a positive result and that it is determined that at least one predefined set of the communicated access authorization parameters (B), in view of respective pieces of reference information present in the access control apparatus (4) at least at the time of the first checking, respectively authorize for access.

(160) Exemplary Embodiment 35:

(161) The method according to exemplary embodiment 34, wherein the key pair is an asymmetrical key pair, wherein generating the first check information (V) comprises generating a digital signature by means of the access authorization parameters (B) using at least the first key of the key pair.

(162) Exemplary Embodiment 36:

(163) The method according to exemplary embodiment 34, wherein the key pair is a symmetrical key pair, and wherein the first checking comprises performing the same cryptographic operations (KRYPT) as are used when generating the first check information (V), on the communicated access authorization parameters (B) using at least the second key (S.sub.2, S.sub.T2) of the key pair for obtaining locally generated first check information and comparing the communicated first check information (V) with the locally generated first check information.

(164) Exemplary Embodiment 37:

(165) The method according to exemplary embodiment 36, wherein the cryptographic operations serve for determining a message authentication code (MAC) as check information (V).

(166) Exemplary Embodiment 38:

(167) The method according to any of exemplary embodiments 34-37, wherein the access control apparatus (4) constitutes an access control apparatus (4) from a plurality of access control apparatuses, wherein a second key (S.sub.2) of a symmetrical or asymmetrical individual key pair is stored in the access control apparatus (4), said second key being stored only on the access control apparatus (4), but on none of the other access control apparatuses of the plurality of access control apparatuses, and wherein the first key (S, S.sub.T1) of the key pair that is used when generating the first check information is the first key (S.sub.1) of the individual key pair.

(168) Exemplary Embodiment 39:

(169) The method according to any of exemplary embodiments 34-37, wherein the access control apparatus (4) constitutes an access control apparatus (4) from a plurality of access control apparatuses,

(170) wherein a second key (S.sub.2) of a symmetrical or asymmetrical individual key pair is stored in the access control apparatus (4), said second key being stored only on the access control apparatus (4), but on none of the other access control apparatuses of the plurality of access control apparatuses, wherein a second key (S.sub.T2) of a symmetrical or asymmetrical group key pair is further stored in the access control apparatus (4), said second key being different than the second key of the individual key pair and being stored in all the access control apparatuses of a group of access control apparatuses from the plurality of access control apparatuses that comprises the access control apparatus (4), wherein the first key (S.sub.1) of the key pair that is used when generating the first check information is either the first key (S.sub.1, S.sub.T1) of the individual key pair or the first key (S.sub.T1) of the group key pair.

(171) Exemplary Embodiment 40:

(172) The method according to exemplary embodiment 39, wherein at least one second key (S.sub.T2) of a symmetrical or asymmetrical further group key pair is further stored in the access control apparatus (4), said at least one second key being different than the second key (S.sub.2) of the individual key pair and the second key (S.sub.T2) of the group key pair and being stored in all the access control apparatuses of a further group of access control apparatuses from the plurality of access control apparatuses that comprises the access control apparatus (4), said further group including, however, at least one or more other access control apparatuses in comparison with the group of access control apparatuses, and wherein the second key (S.sub.2, S.sub.T2) of the key pair that is used in the first checking is either the second key (S.sub.2) of the individual key pair, the second key (S.sub.T2) of the group key pair or the second key (S.sub.T2) of the further group key pair.

(173) Exemplary Embodiment 41:

(174) The method according to either of exemplary embodiments 39-40, wherein provision is not made for changing the second key (S.sub.2) of the individual key pair in the access control apparatus (4), for erasing said second key or for exchanging it for another key, but wherein it is provided that the second key (S.sub.T2) of the group key pair can be changed or erased or exchanged for another key.

(175) Exemplary Embodiment 42:

(176) The method according to any of exemplary embodiments 39-41, further comprising: generating group key information (W) comprising at least one second key (S.sub.T2)encrypted with the first key (S.sub.1) of the individual key pairof a new symmetrical or asymmetrical group key pair for the same or an at least partly different group of access control apparatuses from the plurality of access control apparatuses, outputting the group key information (W) for storage on the access authorization proving apparatus (3), which is configured to communicate the group key information at least to the access control apparatus (4) in order to enable the latter to store in the access control apparatus (4) the second key (S.sub.T2) of the new group key pair, which second key is obtainable by decryption of the communicated encrypted second key (S.sub.T2) of the new group key pair using at least the second key (S.sub.2) of the individual key pair, such that the second key (S.sub.2, S.sub.T2) of the key pair that is used in the first checking is either the second key (S.sub.2) of the individual key pair or the second key (S.sub.T2) of the new group key pair,

(177) Exemplary Embodiment 43:

(178) The method according to exemplary embodiment 42, further comprising: generating second check information (V.sub.W), and outputting the second check information (V.sub.W) for storage on the access authorization proving apparatus (3), which is configured to communicate the second check information (V.sub.W) at least to the access control apparatus (4), and wherein the second key of the new group key pair, which second key is obtainable by the decryption, is stored in the access control apparatus (4) only under the precondition that, in the case of a check based at least on the communicated second check information (V.sub.W), the second key (S.sub.2) of the individual key pair and the communicated group key information (W), it is determined that the communicated second check information (V.sub.W) was generated by performing cryptographic operations on the group key information corresponding to the communicated group key information (W) using at least the first key (S.sub.1) of the individual key pair.

(179) Exemplary Embodiment 44:

(180) The method according to exemplary embodiment 43, wherein the group key information (W) further comprises a counter (update_counter) that is incremented with each new group key pair, and wherein the second key (S.sub.T2) of the new group key pair that is obtained by the decrypting is stored in the access control apparatus (4) only under the further precondition that a value of a counter (update_counter) comprised by the group key information is greater than a value of a counter provided in the access control apparatus (4), and wherein, in or after the storage of the second key (S.sub.T2) of the new group key pair in the access control apparatus (4), the value of the counter in the access control apparatus (4) is updated to the value of the counter (update_counter) comprised by the group key information.

(181) Exemplary Embodiment 45:

(182) The method according to either of exemplary embodiments 43-44, wherein the group key information further comprises an individual identifier (LockID) of the access control apparatus (4), and wherein the second key (S.sub.T2) of the new group key pair that is obtained by the decrypting is stored in the access control apparatus (4) only under the further precondition that an individual identifier (LockID) of the access control apparatus (4) that is stored in the access control apparatus (4) corresponds to the individual identifier (LockID) comprised in the group key information.

(183) Exemplary Embodiment 46:

(184) The method according to any of exemplary embodiments 42-45, wherein the group key information further comprises a group identifier (GroupID) associated with the new group key pair, said group identifier being common to all the access control apparatuses of the group of access control apparatuses for which the new group key pair is intended, and wherein the group identifier (GroupID) obtained by the decrypting is stored in the access control apparatus (4).

(185) Exemplary Embodiment 47:

(186) The method according to any of exemplary embodiments 34-46, wherein one of the access authorization parameters is an identifier (LockID) for only one access control apparatus (4) or a group of access control apparatuses, and wherein it is determined in the access control apparatus (4) that the identifier authorizes for access if the identifier (LockID) corresponds to an individual identifier (LockID) of the access control apparatus (4) that is stored in the access control apparatus (4) and/or a group identifier (GroupID) for a group of access control apparatuses to which the access control apparatus (4) belongs.

(187) Exemplary Embodiment 48:

(188) The method according to any of exemplary embodiments 39-46, wherein one of the access authorization parameters is an identifier (LockID) only for the access control apparatus (4) or a group of access control apparatuses which includes the access control apparatus (4), wherein it is determined in the access control apparatus (4) that the identifier (LockID) authorizes for access if the identifier corresponds to an individual identifier (LockID) of the access control apparatus (4) that is stored in the access control apparatus (4) and/or a group identifier (GroupID) for a group of access control apparatuses to which the access control apparatus (4) belongs, wherein the first check information (V) of access authorization information which has an identifier (LockID) only for the access control apparatus (4) is generated by performing cryptographic operations on the access authorization parameters (B) using at least the first key (S.sub.1) of the individual key pair, and wherein the first check information (V) of access authorization information which has an identifier (LockID) for the group of access control apparatuses is generated by performing cryptographic operations on the access authorization parameters using at least the first key (S.sub.T1) of the group key pair.

(189) Exemplary Embodiment 49:

(190) The method according to exemplary embodiment 48, wherein on the basis of the identifier (LockID), in particular on the basis of a predefined format of the identifier, in the access control apparatus (4), it is possible to identify whether an identifier for only one access control apparatus (4) or an identifier for a group of access control apparatuses is involved, such that either the second key (S.sub.2) of the individual key pair or the second key (S.sub.T2) of the group key pair can be selected in each case appropriately for the first checking.

(191) Exemplary Embodiment 50:

(192) The method according to any of exemplary embodiments 34-49, wherein one of the access authorization parameters (B) is an identifier (KeyID) for the access authorization information (B, V) or for the access authorization proving apparatus (3) which communicates the access authorization information (B, V) to the access control apparatus (4), and wherein it is determined that the identifier (KeyID) authorizes for access if the identifier is not contained in a rejection list (RL) stored in the access control apparatus (4).

(193) Exemplary Embodiment 51:

(194) The method according to any of exemplary embodiments 34-50, further comprising: encrypting a fourth key (H.sub.4) using at least the first key (S.sub.1, S.sub.T1) of the key pair, wherein the fourth key (H.sub.4) can be used in an authentication of the access control apparatus (4) vis-?-vis the access authorization proving apparatus (3), which communicates the access authorization information to the access control apparatus (4), or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus (4), generating information (A) comprising at least the encrypted fourth key (H.sub.4), and outputting the information (A) for storage on the access authorization proving apparatus (3), which is configured to communicate the information (A) at least to the access control apparatus (4) in order to enable the latter to decrypt the encrypted fourth key using at least the second key (S.sub.2, S.sub.T2) of the key pair and to use said fourth key.

(195) Exemplary Embodiment 52:

(196) The method according to any of exemplary embodiments 34-50, further comprising: encrypting a combination of a fourth key (H.sub.4) and an identifier (KeyID) for the access authorization information (B, V) or for the access authorization proving apparatus (3), which communicates the access authorization information (B, V) to the access control apparatus (4), using at least the first key (S.sub.1, S.sub.T1) of the key pair, wherein the fourth key (H.sub.4) can be used in an authentication of the access control apparatus (4) vis-?-vis an access authorization proving apparatus (3), which communicates the access authorization information (B, V) to the access control apparatus, or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus (4), generating information (A) comprising at least the encrypted combination, and outputting the information (A) for storage on the access authorization proving apparatus (3), which is configured to communicate the information (A) at least to the access control apparatus (4) in order to enable the latter to decrypt the encrypted combination using at least the second key (S.sub.2, S.sub.T2) of the key pair, in order to obtain the fourth key (H.sub.4) and the identifier, wherein the identifier (KeyID) further constitutes one of the access authorization parameters (B), and wherein it is determined in the access control apparatus (4) that the identifier (KeyID) contained in the communicated access authorization information (B, V) authorizes for access if the identifier (KeyID) contained in the communicated access authorization information (B, V) corresponds to the identifier (KeyID) obtained by decrypting the encrypted combination.

(197) Exemplary Embodiment 53:

(198) The method according to any of exemplary embodiments 34-50, further comprising: encrypting a combination of a fourth key (H.sub.4) and an identifier (KeyID) for the access authorization information (B, V) or for the access authorization proving apparatus (3), which communicates the access authorization information (B, V) to the access control apparatus (4), using at least the first key (S.sub.1, S.sub.T1) of the key pair, wherein the fourth key (H.sub.4) can be used in an authentication of the access control apparatus (4) vis-?-vis an access authorization proving apparatus (3), which communicates the access authorization information (B,V) to the access control apparatus (4), or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus (4), generating information (A) comprising at least the encrypted combination, and outputting the information (A) for storage on the access authorization proving apparatus (3), which is configured to communicate the information (A) at least to the access control apparatus (4) in order to enable the latter to decrypt the encrypted combination using at least the second key (S.sub.2, S.sub.T2) of the key pair, in order to obtain the fourth key (H.sub.4) and the identifier, wherein the identifier (KeyID) further constitutes one of the access authorization parameters (B), and wherein it is determined in the access control apparatus (4) that the identifier (KeyID) contained in the communicated access authorization information (B, V) authorizes for access if the identifier (KeyID) contained in the communicated access authorization information (B, V) corresponds to the identifier (KeyID) obtained by decrypting the encrypted combination and the identifier (KeyID) is not contained in a rejection list (RL) stored in the access control apparatus (4).

(199) Exemplary Embodiment 54:

(200) The method according to either of exemplary embodiments 52-53, wherein the access authorization information (B, V) communicated to the access control apparatus (4) is stored in identical form on at least two access authorization proving apparatuses (3), wherein the identical access authorization information (B, V) stored on the at least two access authorization proving apparatuses (3) in each case has the same identifier (KeyID) for the access authorization information (B, V) and said access authorization information (B, V) is associated in each case with the same fourth key (H.sub.4).

(201) Exemplary Embodiment 55:

(202) The method according to exemplary embodiment 54, wherein the access authorization information (B, V) communicated to the access control apparatus (4) has a limited temporal validity and/or has only a limited permissible number of access processes within its period of validity and/or can be or is only communicated to the access control apparatus (4) by the access authorization proving apparatus (3) if it is determined at the access authorization proving apparatus (3) that there is a need for the access to the access control apparatus (4).

(203) Exemplary Embodiment 56:

(204) The method according to any of exemplary embodiments 51-55, wherein the fourth key (H.sub.4) together with a third key (H.sub.3) forms a symmetrical or asymmetrical key pair, the method further comprising: outputting the third key (H.sub.3) to the access authorization proving apparatus (3) in order to enable the access authorization proving apparatus (3), by performing cryptographic operations on a challenge (R) generated by the access apparatus, the access authorization parameters (B) and the first check information (V) using at least the third key (H.sub.3), to generate third check information (V) and to communicate it to the access control apparatus (4), wherein a further necessary condition for granting access is a second checking, performed on the access control apparatus, using at least the challenge (R), the communicated access authorization parameters (B), the communicated first check information (V), the communicated third check information (V) and the fourth key (H.sub.4), reveals that the communicated third check information (V) was generated by performing cryptographic operations on information corresponding to the challenge (R), the communicated access authorization parameters (B) and the communicated first check information (V), using at least the third key (H.sub.3).

(205) Exemplary Embodiment 57:

(206) The method according to any of exemplary embodiments 51-55, wherein the access control apparatus (4) can authenticate itself vis-?-vis the access authorization proving apparatus (3) using at least the fourth key (H.sub.4), wherein the access authorization information (B, V) is communicated from the access authorization proving apparatus (3) to the access control apparatus (4) only in the event of successful authentication.

(207) Exemplary Embodiment 58:

(208) The method according to either of exemplary embodiments 50 and 53, further comprising: generating fourth check information (V.sub.L) by performing cryptographic operations on rejection information (L) using at least the first key (S.sub.1, S.sub.T1) of the key pair, wherein the rejection information (L) comprises at least one new rejection list (RL) with identifiers (KeyIDs) for access authorization information (B, V) to be rejected or for access authorization proving apparatuses (3) that are to reject access authorization information (B, V) at the access control apparatus (4), and outputting the rejection information (L) and the fourth check information (V.sub.L) for storage on the access authorization proving apparatus (3), which is configured to communicate the rejection information (L) and the fourth check information (V.sub.L) at least to the access control apparatus (4), wherein the communicated new rejection list (RL) is stored in the access control apparatus (4) only under the precondition that, in the case of a check based at least on the communicated fourth check information (V.sub.L), the second key (S.sub.2, S.sub.T2) of the key pair and the communicated rejection information (L), it is determined that the communicated fourth check information (V.sub.L) was generated by performing cryptographic operations on the rejection information corresponding to the communicated rejection information (L) using at least the first key (S.sub.1, S.sub.T1) of the key pair.

(209) Exemplary Embodiment 59:

(210) The method according to exemplary embodiment 58, wherein the rejection information (L) further comprises a counter (Counter) that is incremented with each new rejection list (RL), and wherein the new rejection list (RL) is stored in the access control apparatus (4) only under the further precondition that the value of the counter (Counter) comprised by the rejection information (L) is greater than a value of a counter provided in the access control apparatus (4), and wherein the value of the counter of the access control apparatus (4) is updated to the value of the counter (Counter) comprised by the rejection information (L) in or after the storage of the new rejection list (RL) in the access control apparatus (4).

(211) Exemplary Embodiment 60:

(212) The method according to either of exemplary embodiments 58-59, wherein the rejection information (L) further comprises an identifier (LockID) of only one access control apparatus (4) or a group of access control apparatuses on which the new rejection list (RL) is intended to be stored, and wherein the new rejection list (RL) is stored in the access control apparatus (4) only under the further precondition that an individual identifier (LockID) of the access control apparatus (4) that is stored in the access control apparatus (4) or a group identifier (GroupID) for a group of access control apparatuses that contains the access control apparatus (4) corresponds to the identifier comprised in the rejection information.

(213) Exemplary Embodiment 61:

(214) Exemplary Embodiment 62:

(215) Exemplary Embodiment 63:

(216) The method according to any of exemplary embodiments 34-60, wherein one of the access authorization parameters (B) indicates to what extent, in particular to which openings of the access control apparatus (4) or to which openings of an apparatus controlled by the access control apparatus (4), access is intended to be granted.

(217) Exemplary Embodiment 64:

(218) A computer program, comprising program instructions that cause a processor to perform and/or control the method according to any of exemplary embodiments 34 to 63 if the computer program runs on the processor.

(219) Exemplary Embodiment 65:

(220) An access authorization generation apparatus (2), configured to perform and/or control the method according to any of exemplary embodiments 34-63 or comprising respective means for performing and/or controlling the steps of the method according to any of exemplary embodiments 34-63.

(221) Exemplary Embodiment 66:

(222) A method for proving an access authorization, performed by an access authorization proving apparatus (3), the method comprising: communicating access authorization information (B, V) comprising at least one or more access authorization parameters (B) and first check information (V) to an access control apparatus (4) in order to enable the latter to decide whether access is permitted to be granted on the basis of the communicated access authorization information (B, V), wherein necessary conditions for granting access are that first checking, using at least the communicated access authorization parameters (B), the communicated first check information (V) and a second key (S.sub.2, S.sub.T2) of a symmetrical or asymmetrical key pair, said second key being stored in the access control apparatus (4), whether the communicated first check information (V) was generated by performing cryptographic operations on access authorization parameters (B) corresponding to the communicated access authorization parameters (B) using at least a first key (S.sub.1, S.sub.T1) of the key pair, yields a positive result and that it is determined that at least one predefined set of the communicated access authorization parameters (B), in view of respective pieces of reference information present in the access control apparatus (4) at least at the time of the first checking, respectively authorize for access.

(223) Exemplary Embodiment 67:

(224) The method according to exemplary embodiment 66, wherein the access authorization information (B, V) is generated by an access authorization generation apparatus (2) and stored in the access authorization proving apparatus (3) before the access authorization proving apparatus (3) is issued for the first time to a user of the access authorization proving apparatus (3).

(225) Exemplary Embodiment 68:

(226) The method according to exemplary embodiment 67, wherein the access authorization proving apparatus (3) is a portable RFID or NFC unit, in particular an RFID or NFC tag.

(227) Exemplary Embodiment 69:

(228) The method according to exemplary embodiment 66, wherein the access authorization information (B, V) is generated by an access authorization generation apparatus (2) and communicated to the access authorization proving apparatus (3) via an at least partly wireless communication link, in particular a cellular mobile radio network.

(229) Exemplary Embodiment 70:

(230) The method according to exemplary embodiment 69, wherein the access authorization proving apparatus (3) is a portable terminal configured for wireless communication, in particular a cellular phone.

(231) Exemplary Embodiment 71:

(232) The method according to exemplary embodiment 66, wherein the access authorization information (B, V) is generated by an access authorization generation apparatus (2), is transmitted via a communication network to a computer and, under the control thereof, is communicated to the access authorization proving apparatus (2).

(233) Exemplary Embodiment 72:

(234) The method according to exemplary embodiment 71, wherein the access authorization proving apparatus (3) is a handheld scanner.

(235) Exemplary Embodiment 73:

(236) The method according to any of exemplary embodiments 66-72, wherein communicating information from the access authorization proving apparatus (3) to the access control apparatus (4) is performed wirelessly, in particular by means of RFID, NFC or Bluetooth communication.

(237) Exemplary Embodiment 74:

(238) The method according to any of exemplary embodiments 66-73, wherein the key pair is an asymmetrical key pair, wherein the first check information (V) is generated as a digital signature by means of the access authorization parameters (B) using at least the first key (S.sub.1) of the key pair.

(239) Exemplary Embodiment 75:

(240) The method according to any of exemplary embodiments 66-73, wherein the key pair is a symmetrical key pair, and wherein the first checking comprises performing the same cryptographic operations (KRYPT) as are used when generating the first check information (V), on the communicated access authorization parameters (B) using at least the second key (S.sub.2, S.sub.T2) of the key pair for obtaining locally generated first check information and comparing the communicated first check information (V) with the locally generated first check information.

(241) Exemplary Embodiment 76:

(242) The method according to exemplary embodiment 75, wherein the cryptographic operations serve for determining a message authentication code (MAC) as check information (V).

(243) Exemplary Embodiment 77:

(244) The method according to any of exemplary embodiments 66-76, wherein the access control apparatus (4) constitutes an access control apparatus (4) from a plurality of access control apparatuses, wherein a second key (S.sub.2) of a symmetrical or asymmetrical individual key pair is stored in the access control apparatus (4), said second key being stored only on the access control apparatus, but on none of the other access control apparatuses of the plurality of access control apparatuses, and wherein the first key (S.sub.1, S.sub.T1) of the key pair that is used when generating the first check information is the first key (S.sub.1) of the individual key pair.

(245) Exemplary Embodiment 78:

(246) The method according to any of exemplary embodiments 66-76, wherein the access control apparatus (4) constitutes an access control apparatus (4) from a plurality of access control apparatuses,

(247) wherein a second key (S.sub.2) of a symmetrical or asymmetrical individual key pair is stored in the access control apparatus (4), said second key being stored only on the access control apparatus, but on none of the other access control apparatuses of the plurality of access control apparatuses, wherein a second key (S.sub.T2) of a symmetrical or asymmetrical group key pair is further stored in the access control apparatus (4), said second key being different than the second key of the individual key pair and being stored in all the access control apparatuses of a group of access control apparatuses from the plurality of access control apparatuses that comprises the access control apparatus (4), wherein the first key (S.sub.1, S.sub.T1) of the key pair that is used when generating the first check information is either a first key (S.sub.1) of the individual key pair or a first key (S.sub.T1) of the group key pair.

(248) Exemplary Embodiment 79:

(249) The method according to exemplary embodiment 78, wherein at least one second key (S.sub.T2) of a symmetrical or asymmetrical further group key pair is further stored in the access control apparatus (4), said at least one second key being different than the second key (S.sub.2) of the individual key pair and the second key (S.sub.T2) of the group key pair and being stored in all the access control apparatuses of a further group of access control apparatuses from the plurality of access control apparatuses that comprises the access control apparatus (4), said further group including, however, at least one or more other access control apparatuses in comparison with the group of access control apparatuses, and wherein the second key (S.sub.2, S.sub.T2) of the key pair that is used in the first checking is either the second key (S.sub.2) of the individual key pair, the second key (S.sub.T2) of the group key pair or the second key (S.sub.T2) of the further group key pair.

(250) Exemplary Embodiment 80:

(251) The method according to either of exemplary embodiments 78-79, wherein provision is not made for changing the second key (S.sub.2) of the individual key pair in the access control apparatus (4), for erasing said second key or for exchanging it for another key, but wherein it is provided that the second key (S.sub.T2) of the group key pair can be changed or erased or exchanged for another key.

(252) Exemplary Embodiment 81:

(253) The method according to any of exemplary embodiments 78-80, further comprising: communicating group key information (W) comprising at least one second key (S.sub.T2)encrypted with the first key (S.sub.1) of the individual key pairof a new symmetrical or asymmetrical group key pair for the same or an at least partly different group of access control apparatuses from the plurality of access control apparatuses, to the access control apparatus (4) in order to enable the latter to store in the access control apparatus (4) the second key (S.sub.T2) of the new group key pair, which second key is obtainable by decryption of the communicated encrypted second key (S.sub.T2) of the new group key pair using at least the second key (S.sub.2) of the individual key pair, such that the second key (S.sub.2, S.sub.T2) of the key pair that is used in the first checking is either the second key (S.sub.2) of the individual key pair or the second key (S.sub.T2) of the new group key pair,

(254) Exemplary Embodiment 82:

(255) The method according to exemplary embodiment 81, further comprising: communicating second check information (V.sub.W) to the access control apparatus, wherein the second key of the new group key pair, which second key is obtainable by the decrypting, is stored in the access control apparatus (4) only under the precondition that, in the case of a check based at least on the communicated second check information (V.sub.W), the second key (S.sub.2) of the individual key pair and the communicated group key information (W), it is determined that the communicated second check information (V.sub.W) was generated by performing cryptographic operations on the group key information corresponding to the communicated group key information (W) using at least the first key (S.sub.1) of the individual key pair.

(256) Exemplary Embodiment 83:

(257) The method according to exemplary embodiment 82, wherein the group key information (W) further comprises a counter (update_counter) that is incremented with each new group key pair, and wherein the second key (S.sub.T2) of the new group key pair that is obtained by the decrypting is stored in the access control apparatus (4) only under the further precondition that a value of a counter (update_counter) comprised by the group key information is greater than a value of a counter provided in the access control apparatus (4), and wherein, in or after the storage of the second key (S.sub.T2) of the new group key pair in the access control apparatus (4), the value of the counter in the access control apparatus (4) is updated to the value of the counter (update_counter) comprised by the group key information.

(258) Exemplary Embodiment 84:

(259) The method according to either of exemplary embodiments 82-83, wherein the group key information further comprises an individual identifier (LockID) of the access control apparatus (4), and wherein the second key (S.sub.T2) of the new group key pair that is obtained by the decrypting is stored in the access control apparatus (4) only under the further precondition that an individual identifier (LockID) of the access control apparatus (4) that is stored in the access control apparatus (4) corresponds to the individual identifier (LockID) comprised in the group key information.

(260) Exemplary Embodiment 85:

(261) The method according to any of exemplary embodiments 81-84, wherein the group key information further comprises a group identifier (GroupID) associated with the new group key pair, said group identifier being common to all the access control apparatuses of the group of access control apparatuses for which the new group key pair is intended, and wherein the group identifier (GroupID) obtained by the decrypting is stored in the access control apparatus (4).

(262) Exemplary Embodiment 86:

(263) The method according to any of exemplary embodiments 66-85, wherein one of the access authorization parameters (B) is an identifier (LockID) for only one access control apparatus (4) or a group of access control apparatuses, and wherein it is determined in the access control apparatus (4) that the identifier authorizes for access if the identifier (LockID) corresponds to an individual identifier (LockID) of the access control apparatus (4) that is stored in the access control apparatus (4) and/or a group identifier (GroupID) for a group of access control apparatuses to which the access control apparatus (4) belongs.

(264) Exemplary Embodiment 87:

(265) The method according to any of exemplary embodiments 78-85, wherein one of the access authorization parameters is an identifier (LockID) only for the access control apparatus (4) or a group of access control apparatuses which includes the access control apparatus (4), wherein it is determined in the access control apparatus that the identifier (LockID) authorizes for access if the identifier corresponds to an individual identifier (LockID) of the access control apparatus (4) that is stored in the access control apparatus (4) and/or a group identifier (GroupID) for a group of access control apparatuses to which the access control apparatus (4) belongs, wherein the first check information (V) of access authorization information which has an identifier (LockID) only for the access control apparatus (4) is generated by cryptographic operations being performed by means of the access authorization parameters (B) using at least the first key (S.sub.1) of the individual key pair, and wherein the first check information (V) of access authorization information which has an identifier (LockID) for the group of access control apparatuses is generated by performing cryptographic operations on the access authorization parameters using at least the first key (S.sub.T1) of the group key pair.

(266) Exemplary Embodiment 88:

(267) The method according to exemplary embodiment 87, wherein on the basis of the identifier (LockID), in particular on the basis of a predefined format of the identifier, in the access control apparatus (4), it is possible to identify whether an identifier for only one access control apparatus (4) or an identifier for a group of access control apparatuses is involved, such that either the second key (S.sub.2) of the individual key pair or the second key (S.sub.T2) of the group key pair can be selected in each case appropriately for the first checking.

(268) Exemplary Embodiment 89:

(269) The method according to any of exemplary embodiments 66-88, wherein one of the access authorization parameters (B) is an identifier (KeyID) for the access authorization information (B, V) or for the access authorization proving apparatus (3), and wherein it is determined that the identifier (KeyID) authorizes for access if the identifier is not contained in a rejection list (RL) stored in the access control apparatus (4).

(270) Exemplary Embodiment 90:

(271) The method according to any of exemplary embodiments 66-89, further comprising: communicating to the access control apparatus (4) information (A) comprising at least one fourth key (H.sub.4) that is encrypted using at least the first key (S.sub.1, S.sub.T1) of the key pair and that can be used in an authentication of the access control apparatus (4) vis-?-vis the access authorization proving apparatus (3), or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus (4), in order to enable the latter to decrypt the encrypted fourth key using at least the second key (S.sub.2, S.sub.T2) of the key pair and to use said fourth key.

(272) Exemplary Embodiment 91:

(273) The method according to any of exemplary embodiments 66-89, further comprising: communicating to the access control apparatus (4) information (A) comprising at least one combinationencrypted using at least the first key (S.sub.1, S.sub.T1) of the key pairof a fourth key (H.sub.4) and an identifier (KeyID) for the access authorization information (B, V) or for the access authorization proving apparatus (3), wherein the fourth key (H.sub.4) can be used in an authentication of the access control apparatus (4) vis-?-vis the access authorization proving apparatus (3) or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus (4), in order to enable the latter to decrypt the encrypted combination using at least the second key (S.sub.2, S.sub.T2) of the key pair, in order to obtain the fourth key (H.sub.4) and the identifier, wherein the identifier (KeyID) further constitutes one of the access authorization parameters (B), and wherein it is determined in the access control apparatus (4) that the identifier (KeyID) contained in the communicated access authorization information (B, V) authorizes for access if the identifier (KeyID) contained in the communicated access authorization information (B, V) corresponds to the identifier (KeyID) obtained by decrypting the encrypted combination.

(274) Exemplary Embodiment 92:

(275) The method according to any of exemplary embodiments 66-89, further comprising: communicating to the access control apparatus (4) information (A) comprising at least one combinationencrypted using at least the first key (S.sub.1, S.sub.T1) of the key pairof a fourth key (H.sub.4) and an identifier (KeyID) for the access authorization information (B, V) or for the access authorization proving apparatus (3), wherein the fourth key (H.sub.4) can be used in an authentication of the access control apparatus (4) vis-?-vis the access authorization proving apparatus (3) or in the checking of the authenticity and/or integrity of information communicated to the access control apparatus (4), in order to enable the latter to decrypt the encrypted combination using at least the second key (S.sub.2, S.sub.T2) of the key pair, in order to obtain the fourth key (H.sub.4) and the identifier, wherein the identifier (KeyID) further constitutes one of the access authorization parameters (B), and wherein it is determined in the access control apparatus (4) that the identifier (KeyID) contained in the communicated access authorization information (B, V) authorizes for access if the identifier (KeyID) contained in the communicated access authorization information (B, V) corresponds to the identifier (KeyID) obtained by decrypting the encrypted combination and the identifier (KeyID) is not contained in a rejection list (RL) stored in the access control apparatus (4).

(276) Exemplary Embodiment 93:

(277) The method according to either of exemplary embodiments 91-92, wherein the access authorization information (B, V) communicated to the access control apparatus (4) is stored in identical form on at least two access authorization proving apparatuses (3), wherein the identical access authorization information (B, V) stored on the at least two access authorization proving apparatuses (3) in each case has the same identifier (KeyID) for the access authorization information (B, V) and said access authorization information (B, V) is associated in each case with the same fourth key (H.sub.4).

(278) Exemplary Embodiment 94:

(279) The method according to exemplary embodiment 93, wherein the access authorization information (B, V) communicated to the access control apparatus (4) has a limited temporal validity and/or has only a limited permissible number of access processes within its period of validity and/or can be or is only communicated to the access control apparatus (4) by the access authorization proving apparatus (3) if it is determined at the access authorization proving apparatus (3) that there is a need for the access to the access control apparatus (4).

(280) Exemplary Embodiment 95:

(281) The method according to any of exemplary embodiments 90-94, wherein the fourth key (H.sub.4) together with a third key (H.sub.3) forms a symmetrical or asymmetrical key pair, the method further comprising: generating third check information (V) by performing cryptographic operations on a challenge (R) generated by the access apparatus, the access authorization parameters (B) and the first check information (V) using at least the third key (H.sub.3), communicating the third check information (V) to the access control apparatus, wherein a further necessary condition for granting access is a second checking, performed at the access control apparatus, using at least the challenge (R), the communicated access authorization parameters (B), the communicated first check information (V), the communicated third check information (V) and the fourth key (H.sub.4), reveals that the communicated third check information (V) was generated by cryptographic operations being performed by means of information corresponding to the challenge (R), the communicated access authorization parameters (B) and the communicated first check information (V), using at least the third key (H.sub.3).

(282) Exemplary Embodiment 96:

(283) The method according to any of exemplary embodiments 90-94, wherein the access control apparatus (4) can authenticate itself vis-?-vis the access authorization proving apparatus (3) using at least the fourth key (H.sub.4), and wherein the access authorization information (B, V) is communicated from the access authorization proving apparatus (3) to the access control apparatus (4) only in the event of successful authentication.

(284) Exemplary Embodiment 97:

(285) The method according to either of exemplary embodiments 89 and 92, further comprising: generating fourth check information (V.sub.L) by performing cryptographic operations on rejection information (L) using at least the first key (S.sub.1, S.sub.T1) of the key pair, wherein the rejection information (L) comprises at least one new rejection list (RL) with identifiers (KeyIDs) for access authorization information (B, V) to be rejected or for access authorization proving apparatuses (3) that are to reject access authorization information (B, V) at the access control apparatus (4), and communicating rejection information (L) comprising at least one new rejection list (RL) with identifiers (KeyID) for access authorization information (B, V) to be rejected or for access authorization proving apparatuses (3) that are to reject access authorization information (B, V) at the access control apparatus (4), and communicating fourth check information (V.sub.L) generated by performing cryptographic operations on the rejection information (L) using at least the first key (S.sub.1, S.sub.T1) of the key pair, to the access control apparatus, wherein the communicated new rejection list (RL) is stored in the access control apparatus (4) only under the precondition that, in the case of a check based at least on the communicated fourth check information (V.sub.L), the second key (S.sub.2, S.sub.T2) of the key pair and the communicated rejection information (L), it is determined that the communicated fourth check information (V.sub.L) was generated by performing cryptographic operations on the rejection information corresponding to the communicated rejection information (L) using at least the first key (S.sub.1, S.sub.T1) of the key pair.

(286) Exemplary Embodiment 98:

(287) The method according to exemplary embodiment 97, wherein the rejection information (L) further comprises a counter (Counter) that is incremented with each new rejection list (RL), and wherein the new rejection list (RL) is stored in the access control apparatus (4) only under the further precondition that the value of the counter (Counter) comprised by the rejection information (L) is greater than a value of a counter provided in the access control apparatus (4), and wherein the value of the counter of the access control apparatus (4) is updated to the value of the counter (Counter) comprised by the rejection information (L) in or after the storage of the new rejection list (RL) in the access control apparatus (4).

(288) Exemplary Embodiment 99:

(289) The method according to either of exemplary embodiments 97-98, wherein the rejection information (L) further comprises an identifier (LockID) of only one access control apparatus (4) or a group of access control apparatuses on which the new rejection list (RL) is intended to be stored, and wherein the new rejection list (RL) is stored in the access control apparatus (4) only under the further precondition that an individual identifier (LockID) of the access control apparatus (4) that is stored in the access control apparatus (4) or a group identifier (GroupID) for a group of access control apparatuses that contains the access control apparatus (4) corresponds to the identifier comprised in the rejection information.

(290) Exemplary Embodiment 100:

(291) The method according to any of exemplary embodiments 66-99, wherein one of the access authorization parameters (B) indicates to what extent, in particular to which openings of the access control apparatus (4) or to which openings of an apparatus controlled by the access control apparatus (4), access is intended to be granted.

(292) Exemplary Embodiment 101:

(293) A computer program, comprising program instructions that cause a processor to perform and/or control the method according to any of exemplary embodiments 66 to 100 when the computer program runs on the processor.

(294) Exemplary Embodiment 102:

(295) An access authorization proving apparatus (3), configured to perform and/or control the method according to any of exemplary embodiments 66-100 or comprising respective means for performing and/or controlling the steps of the method according to any of exemplary embodiments 66-100.

(296) Exemplary Embodiment 103:

(297) A system, comprising: an access control apparatus (4) according to exemplary embodiment 32, an access authorization generation apparatus (2), in particular according to exemplary embodiment 65, and an access authorization proving apparatus (3), in particular according to exemplary embodiment 102, wherein the access authorization information (B, V) is generated by the access authorization generation apparatus (2) and is communicated to the access control apparatus (4) by the access authorization proving apparatus (3).

(298) The exemplary embodiments of the present invention described by way of example in this specification are intended also to be understood as disclosed in all combinations with one another. In particular, the description of a feature comprised by an embodimentunless explicitly explained to the contraryin the present case also ought not be understood to mean that the feature is indispensible or essential for the function of the exemplary embodiment. The sequence of the method steps in the individual flow diagrams as outlined in this specification is not mandatory; alternative sequences of the method steps are conceivable. The method steps can be implemented in various ways; an implementation in software (by program instructions), hardware or a combination of both is thus conceivable for implementing the method steps. Terms used in the patent claims such as comprise, have, include, contain and the like do not exclude further elements or steps. The wording at least partly includes both the case partly and the case completely. The wording and/or is intended to be understood to the effect that the disclosure is intended to include both the alternative and the combination, that is to say A and/or B means (A) or (B) or (A and B). In the context of this specification, units, persons or the like in the plural mean a plurality of units, persons or the like. The use of the indefinite article does not exclude the plural. An individual device can perform the functions of a plurality of units or devices mentioned in the patent claims. Reference signs indicated in the patent claims should not be regarded as limitations of the means and steps used.