Access control system

Abstract

Method for access control, carried out by an access control device (4), the method comprising - receiving access authorization information (B, V) communicated to the access control device (4), which comprises at least one or more access authorization parameters (B) and first check information (V), - first checking, using at least the communicated access authorization parameters (B), the communicated first check information (V) and a second key (S2, S T2 ) of a symmetric or asymmetric key pair, whether the communicated first check information (V) by performing cryptographic operations on the communicated access authorization parameters (B) corresponding access authorization parameters (B) using at least one first key (S1, S T1 ) of the key pair was generated, - deciding whether access may be granted, whereby necessary conditions for granting access are that the first check provides a positive result and it is determined that at least a predefined set of the communicated access authorization parameters (B) authorize access with regard to the respective reference information present in the access control device (4) at least at the time of the first check, wherein the access control device (4) represents one access control device (4) from a plurality of access control devices, wherein a second key (S2) of a symmetric or asymmetric individual key pair is stored in the access control device (4), which second key is not stored in any of the other access control devices of the plurality of access control devices, wherein in the access control device (4) in addition to the second key (S2) of the individual key pair, a second key (S T2 ) of a symmetric or asymmetric group key pair is stored, which is stored in all access control devices of a group of access control devices of the plurality of access control devices comprising the access control device (4), and wherein the second key (S2, S T2 ) of the key pair, either the second key (S2) of the individual key pair or the second key (S T2 ) of the group key pair.

Description

Field of InterestExemplary embodiments of the invention relate to an access control system, its components and methods carried out by these components. Exemplary embodiments of the invention relate in particular to a system for controlling the access of different persons to parcel or goods delivery containers.BackgroundAccess control systems are used in many ways, for example for controlling the access of persons to rooms of a building, as is the case, for example, with hotels, office complexes or laboratories, to events or also in abstract form to functions, resources or services, for example computer functions or resources or server services.A specific application of access control systems also constitutes the control of the access of persons to openings of containers, such as e.g. lock boxes or goods delivery containers, in particular parcel boxes. Parcel boxes provide a novel form of delivery / collection of packages for persons who wish to receive or send packages even in the absence of or near their residence. For this purpose, parcel boxes are usually installed in front of the residence of the parcel box user-similar to a mailbox but with a larger capacity-and packages are then delivered by the delivery agent by inserting them into the parcel box or are collected by removing them from the parcel box. In order to prevent abuse and theft, the parcel box must have a lock. Both the delivery agent and the parcel box user must then be equipped with physical or logical keys in order to be able to use the parcel box.U.S. Pat. No. 5,768,379 describes access control systems which are restricted to authorized time slots which can be extended by means of a portable storage device. The system comprises for this purpose an element (LE) which generates electronic keys. These keys are loaded into devices such as memory cards (C). At the various (physical or logical) locations, the access of which must be protected, electronic locks (L) are mounted for checking the electronic keys. They are used to control access to buildings or computer systems.US 2002 / 0180580 A1 describes a system and method for receiving packets. The system includes a housing having a plurality of walls forming a surround. At least one of the compartments is unequal in size relative to the other compartments. In the compartments, packages of different sizes can be accommodated simultaneously. A plurality of lockable doors disposed in the housing allow access to at least one of the compartments in the housing. The locks can be switched between a locked and an unlocked state by means of at least one authorisation code.In "Angewandte Cryptography" by B. Schneier, Addison Wesley, 1996, basic protocols for key exchange and authentication are described on pages 57-62.Summary of Some Exemplary Embodiments of the InventionTo date, there is no satisfactory access control system for installing a plurality of parcel boxes which allows the boxes to operate without network connectivity - i.e., offline - while still ensuring secure and flexible allocation of parcel box access permissions to both the delivery agents and the parcel box users.The present invention has therefore set itself the object of overcoming this problem.According to a first aspect of the invention, there is disclosed an access control method performed by an access control device according to claim 1.According to the first aspect of the invention, the use of an access credential device for communicating access credential information to the access control device according to the first aspect of the invention is further disclosed.According to a second aspect of the invention, a method for generating access authorisation information according to claim 30 is disclosed, in particular carried out by an access authorisation generating device.According to a third aspect of the invention, there is disclosed a method of detecting access authorisation performed by an access authorisation detection device according to claim 33.In accordance with each of these aspects of the invention, there are further disclosed:a computer program comprising program instructions which cause a processor to execute and / or control the method according to the respective aspect of the invention when the computer program runs on the processor. In this specification, a processor is to be understood to mean, inter alia, control units, microprocessors, microcontrollers such as microcontrollers, digital signal processors (DSPs), application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In this case, either all steps of the method can be controlled, or all steps of the method can be carried out, or one or more steps can be controlled and one or more steps can be carried out. The computer program can be distributed, for example, via a network such as the Internet, a telephone or mobile radio network and / or a local network. The computer program may be at least partially software and / or firmware of a processor. It may likewise be implemented at least partially as hardware. The computer program can be stored, for example, on a computer-readable storage medium, e.g., a magnetic, electrical, electromagnetic, optical and / or other type of storage medium. The storage medium can be part of the processor, for example, a (non-volatile or volatile) program memory of the processor or a part thereof.a device configured to execute and / or control the method according to the respective aspect of the invention or comprising respective means for executing the steps of the method according to the respective aspect of the invention. In this case, either all steps of the method can be controlled, or all steps of the method can be carried out, or one or more steps can be controlled and one or more steps can be carried out. One or more of the means may also be executed and / or controlled by the same unit. For example, one or more of the means may be formed by one or more processors.a device comprising at least one processor and at least one memory comprising program code, wherein the memory and the program code are configured to cause the device with the at least one processor to execute and / or control at least the method according to the respective aspect of the invention. In this case, either all steps of the method can be controlled, or all steps of the method can be carried out, or one or more steps can be controlled and one or more steps can be carried out.According to a fourth aspect of the invention, there is disclosed a system as claimed in claim 36.These four aspects of the present invention have, among other things, the partially exemplary properties described below.Access control is carried out at an access control device, for example access to rooms of buildings (e.g. hotels, office complexes, laboratories) or devices, events (e.g. concerts, sports events), functions (e.g. of a computer, e.g. via a login), resources or services (e.g. to a service provided by a server, e.g. online banking, social networks, email accounts) is controlled. Examples of access to rooms of devices are access to rooms of receptacles such as lock boxes, spins, refrigerators, goods delivery containers, mailboxes, parcel boxes or combined mailboxes and parcel boxes, which are closed, for example, with doors and secured by closing devices.The access control device can be, for example, one or more processors which control one or more locking devices, for example an electronically controllable lock, and can thus, for example, bring about an opening and / or closing of the lock. The lock can be equipped, for example, with a latch function, so that the access control device only has to control, for example, an opening of the lock (for example, by at least temporarily transferring the latch into an open position, for example, by an electric motor), while a closing of the lock is performed manually by a user, in that the user uses the latch function and, for example, displaces the latch from the closed position into the open position by pushing a door, and after the closing is ended, the latch automatically returns to the closed position again, for example, by spring prestress.The access control device can also comprise the closing devices and further components. The access control device can be part of a device to which it controls access, for example a receiving device. The access control device can be battery-operated, for example, and for example have no, in particular continuous, power connection. The access control device can be configured, for example, in such a way that, during operation, it is configured exclusively for communication with access authorisation verification devices and, for example, is not configured for communication with the access authorisation generation device. The access control device has, for example, no connection to a mobile radio network, a local area network (LAN), a wireless local area network (WLAN) or the Internet, and therefore represents, for example, an "offline" access control device. The wireless communication of the access control device can be configured, for example, for communication with devices in the immediate vicinity of the access control device (for example, less than 100 m). The wireless communication of the access control device can be limited to communication by means of radio frequency identification (RFID) and / or near field communication (NFC) and / or Bluetooth (e.g. Bluetooth version 2.1 and / or 4.0), for example. RFID and NFC- are specified, for example, according to ISO Standards 18000, 11784 / 11785 and ISO / IEC Standards 14443-A and 15693. The Bluetooth specifications are available from www.bluetooth.org. The access control device can nevertheless have, for example, a universal serial bus (USB) interface, via which the access control device can be maintained, for example.The access control can consist, for example, in deciding, on the basis of presented access authorisation information, whether access can be granted. If it is decided that access may be granted, access is granted, for example, by issuing a control signal, for example to a lock, in order to unlock and / or open a door to one or more rooms (e.g. receiving rooms of a receiving device), for example, in order to allow access to the one or more rooms. Access can be granted to varying extents; for example, in the presence of a plurality of receptacles, access to specific receptacles or groups of receptacles can only be granted. The extent of the access can be defined, for example, in an access authorisation parameter of the access authorisation information.Access authorisation information which has been communicated to the access control device is obtained at the access control device, in particular from an access authorisation verification device, on which the access authorisation information is stored at least temporarily. The access authorisation information can be communicated to the access control device, for example, via wireless communication, for example, via communication by means of RFID, NFC or Bluetooth.The access proof device may be, for example, a portable electronic device. The device is assigned, for example, to a user (e.g., a user registered with respect to the access control device) who wishes to gain access with the access authorisation information at the access control device and is therefore referred to below as a "user device". The user device has, for example, a graphical user interface and / or its own power supply. The user device is, for example, a mobile telephone, a personal digital assistant (PDA), a media player (e.g. an iPod), or a navigation device. If the access control device is assigned to a parcel box, the user device can belong, for example, to a parcel box user, i.e., for example, an owner of the parcel box, or to a person who is allowed to receive parcels via the parcel box or insert them for delivery by a delivery agent). A delivery agent is not understood in this sense as a user. The user device is configured for wireless communication with the access control device, for example via Bluetooth and / or RFID and / or NFC. The device has, for example, the capability to communicate via a cellular mobile radio network (e.g. a mobile radio network based on the Global System for Mobile Communication (GSM), the Universal Mobile Telecommunications System (UMTS) and / or the Long Term Evolution (LTE) system).Alternatively, the access proof device can be, for example, a portable electronic device of a deliverer, in particular if the access control device is assigned to a parcel box. This device is referred to as a "delivery device" below. The delivery device has, for example, a graphical user interface and a functionality for wirelessly detecting information of packages, for example by optically scanning package labels and / or detecting information of packages via radio (e.g. RFID) or magnetic fields (e.g. NFC), for example if the package has an RFID tag or NFC tag. The delivery agent device may have the capability, for example, of communicating via a cellular mobile radio network, but this may also not be the case. The delivery agent device can have, for example, the capability to communicate via WLAN and / or via a cellular mobile radio system (in particular via GRPS). The delivery agent device can have, for example, the capability to communicate via Bluetooth and / or NFC, for example also by corresponding retrofitting. An example of a delivery device is a hand-held scanner, for example LXE Tecton MX7 from Honeywell.If the access proof device (in particular the user device and / or the delivery device) communicates access proof information to the access control device by means of Bluetooth, it is advantageous that the medium access control (MAC) address of the access control device is known to the access proof device, since then the Bluetooth communication can be started without the need for the time-consuming Bluetooth pairing. The MAC address of the access control device is communicated to the access credential device, for example, together with the access credential.Alternatively, the access proof device may be, for example, a portable electronic unit for wireless communication with the access control device. This portable electronic unit will be referred to as a "tag" hereinafter. The tag may have, for example, no capability for communication by means of cellular mobile radio, and / or no capability for communication by means of WLAN and / or no capability for communication by means of Bluetooth. The tag may for example not have a graphical user interface and / or a power supply of its own. The tag can communicate, for example, only when a (e.g. electromagnetic or magnetic) read field of a reading device is present. The tag may be, for example, an RFID or NFC tag (e.g., a MiARE tag from N XP). The tag may have different form factors, for example. It can be designed, for example, as a key fob or as a card (e.g., for example with the form factor of a credit card). The tag may have, for example, small dimensions (e.g. less than 9 cm or 5 cm height / length / width) and low weight (e.g. less than 50 g). The information stored on the tag (e.g. the access authorisation information) can be communicated, for example, to a corresponding reading device, for example also only after successful authentication of the reading device with respect to the tag. The reading device can be, for example, a component of the access control device or be operatively connected thereto. The tags can operate, for example, at 120-135 kHz, 13.56 MHz or 865-869 MHz, but other, in particular higher, frequencies are also possible. The information transmission can be based, for example, on capacitive coupling, inductive coupling or on electromagnetic waves (e.g. backscatter methods). The tag may include, for example, an antenna, an analog circuit for transmitting and receiving (also referred to as a transceiver), a digital circuit (e.g., a microcontroller), and a memory (e.g., an EEPROM (electrically erasable programmable read-only memory). The access authorisation information can be modulated, for example, onto a high-frequency signal generated by a reading unit, for example in the form of a load modulation. The reading unit can then thereby obtain the authorisation information from the tag.The access authorisation information is generated on the access authorisation generating device, which can be designed, for example, as one or more servers, and is then output for storage on an access authorisation verification device. This can be done, for example, by the access authorisation information being transmitted to the access authorisation verification device via a communication connection between the access authorisation generation device and the access authorisation verification device and being stored there, in particular if the access authorisation verification device is a user device (e.g. a mobile telephone, as described above). For example, a functionality is then present on the access credential device, for example as an application ("app"), which can be downloaded from an online market place, for example, which serves, inter alia, for the retrieval of access credential information. For this purpose, the access authorisation information can be actively pushed by the access authorisation generation device to the access authorisation verification device (i.e. transmitted without request by the access authorisation verification device), for example, or can be transmitted to the access authorisation verification device only upon request by the access authorisation verification device (or another entity) (and for example also generated only upon the request). The communication connection between the access credential generation device and the access credential device may be based on one or more communication networks, at least one of which is, for example, a mobile network or a WLAN network. If the access credential device is, for example, a user device (e.g., a mobile phone), the access credential information may be obtained from the access credential generation device, for example, via a hypertext transfer protocol (HTTP) or hypertext transport protocol secure (HTTPS) connection, which is based, for example, on a general packet radio (GPRS) connection.If the access authorisation verification device is, for example, a delivery agent device (e.g. a hand scanner of a delivery agent), the access authorisation information can be transmitted, for example, via the Internet to a computer (e.g. a computer in a delivery base with which the delivery agent device is at least temporarily associated) and under the control thereof can then be transmitted, for example, by wire (e.g. by means of a docking station) or wirelessly (e.g. by means of WLAN) to the delivery agent device. This can be done anew, for example, every day.For example, if the access credential generation device is a tag (e.g., an RFID or NFC tag, as described above), the access credential generation device outputs the access credential to the tag for storage, for example, by transmitting the access credential to a writing unit (e.g., via the Internet) that then writes the access credential to the tag. For example, the access authorization information is transmitted to a computer of a supplier or manufacturer of tags, which then carries out the writing of the access authorization information into the tags. This occurs, for example, before the tags are output to the persons who are to use the access authorisation information for the access authorisation verification (e.g. users and / or delivery agents). The validity of the access authorisation information stored on tags may be longer than the validity of the access authorisation information stored on the user devices and / or delivery agent devices due to the higher effort of replacing the access authorisation information in the tags compared to the user devices and / or delivery agent devices.The access authorisation information contains one or more access authorisation parameters. This can be, for example, an (in particular unique) identifier for the access control device, an (in particular unique) identifier for the access authorisation information itself, temporal validity information (e.g. in the form of a "non-date before", a "non-date after", a "start time of the day" and an "end time of the day", which specify within which days and within which time of day access can be granted, for example from 27.3.2014 00:00:00 to 28.3.2014 23:59:59), an upper limit of the permitted uses of the access authorisation information in order to obtain access, and information to what extent access can be granted (i.e. for example whether all doors of a parcel box can be opened, or only one or a specific group). The one or more access authorisation parameters are together also referred to in this specification as access authorisation.At least a predefined set (e.g., all, or only some) of the access authorisation parameters are checked with respect to respective reference information whether they respectively authorize access. For example, the identification for the access control device as access authorisation parameter can be checked with respect to an identification of the access control device stored in the access control device and, if they match, it can be established that this access authorisation parameter authorizes access The time validity information as access authorisation parameters can be checked, for example, with respect to a time information (e.g. date and time) obtained from a clock of the access control device, for example in such a way that a time period defined by the validity information must contain the current time according to the clock of the access control device, so that access can be granted. In this case, a predefined time tolerance can be permitted in order to compensate for possible time differences between the clock of the access control device and a clock in the access authorization generating device. A communicated upper limit of the permitted uses can be checked accordingly against a counter stored in the access control device, which counter is incremented by one each time this access authorisation information is used for providing access to the access control device. The comparison of the communicated upper limit with the counter as reference information reveals that access is permitted if the counter is less than the communicated upper limit.For example, while the identifier of the access control device and the time information obtained from the clock are constantly present in the access control device, there may be one or more access authorisation parameters which have to be checked with respect to reference information which is not constantly present in the access control device but, for example, only during the first checking or shortly before the first checking. This can be the case, for example, for the identifier of the access authorisation information or of the access authorisation proof device as access authorisation parameter if this identifier is obtained, for example in encrypted form (or alternatively in combination with a fourth key), only together with the access authorisation information or before or after the access authorisation information (but for example in the same communication session) at the access control device. Here too, it is necessary for granting access that the identifier of the access authorisation information communicated as the access authorisation parameter matches the identifier of the access authorisation information obtained by decryption from the encrypted identifier. Similarly, the identifier of the access credential or the access credential device may also be checked for a rejection list as an example of reference information. This rejection list may be stored on the access control device, for example, not already initially but only after a certain elapsed operating time of the access control device. For example, the case may occur that the rejection list is obtained at the access control device in the same communication session in which the access authorisation information is also transmitted to the access control device, for example before the access authorisation information.An access authorisation parameter which is not checked against reference information is, for example, the information to what extent access is to be granted. This information is taken into account, for example, when granting access, but not, for example, when checking whether access is to be granted. For example, the information to what extent access is to be granted may indicate which door or which group of doors of a plurality of doors of a building or device is to be opened when it has been decided that access is permitted to be granted. If the device is a parcel box with a door for a parcel compartment and a door for a mailbox, the information can indicate, for example, whether only the parcel compartment (for example for a delivery agent) or both the parcel compartment and the mailbox (for example for a user of the parcel box) are to be opened.However, before the individual access authorisation parameters are checked with regard to their respective reference information in the access control device, the first checking must provide a positive result. The first checking analyzes the first checking information included in the access credential to determine the integrity (tamperproof) and authenticity (authenticity or origin from the suspected source) of the access credential, as will be explained in more detail below. The authenticity of the access authorisation information is determined primarily in that the entity issuing the access authorisation information, i.e. the access authorisation generating device, has used during the cryptographic operations the first key of a key pair held as secret between the access control device and the access authorisation generating device, which can be checked by the access control device on the basis of the second key of this key pair, the first checking information and the communicated access authorisation parameter. During this check, the integrity of the communicated access authorisation parameters is also confirmed None of the keys of the key pair is known, for example, outside the access control device and the access authorisation generation device; in particular, the access authorisation verification device or its users do not know these keys either. The key pair can be, for example, a symmetrical key pair, which means that the first key and the second key are identical. Encryption and decryption using such symmetric keys can be carried out, for example, according to the methods Advanced Encryption Standard (AES), DES (Data Encryption Standard), Data Encryption Algorithm (DEA), Triple-DES, IDEA (International Data Encryption Algorithm) or Blowfish, just to name a few examples. Symmetric keys may be chosen pseudo-randomly, for example. In the case of an asymmetric key pair, on the other hand, both keys are different, for example in the case of an asymmetric key pair according to the RSA (Rivest, Shamir, Adleman) method or according to the method according to McEliece, Rabin, Chor-Rivest or Elgamal. Methods for generating symmetric and asymmetric keys for generating digital signatures, message authentication codes (MACs) and for encrypting and decrypting are given in the publication "Special Publication 800-133 Recommendation for Cryptographic Key Generation" of the National Institute of Standards and Technology (NIST) of the U.S. Department of Commerce.Access is thus granted if the first checking has run positively, that is to say in particular integrity and authenticity of the access authorisation information has been confirmed, and it has also been established for at least a specific set of the access authorisation parameters that they authorize access with regard to their respective reference information in the access control device. If it is decided that access is allowed, a corresponding control signal is output, for example, to a lock. Otherwise, for example, an alarm or a warning is output, e.g. in a visual or acoustic manner.The access control system embodied according to the first to fourth aspects of the invention has a number of advantages. Because the access control device and the access authorisation generation device treat the key pair as secret, on the one hand the access authorisation generation device is enabled to generate access authorisation information for the access control device exclusively itself. On the other hand, the access control device may trust the access right information generated by the access right generating device. Therefore, the access authorisation parameters can also be communicated to the access control device in a fundamentally unencrypted form: using the second key of the key pair, the integrity thereof and the authenticity of the access authorisation information can be sufficiently confirmed. Since the access control device uses either reference information that is invariable over the long term, such as the identifier of the access control device, or reference information that can be managed itself, such as the time information derived from the local clock of the access control device, or the counter for the granted accesses that have already been made with specific access authorisation information, for checking the communicated access authorisation parameters, the access control device is essentially autonomous and does not require a network connection. This also reduces power consumption, which is also significant in a battery powered device. Furthermore, the cryptographic operations are carried out in the access control device via the communicated access authorisation parameters, and not via locally present access authorisation parameters. This makes it possible in particular to separate the checking of the integrity of the information obtained from the checking of the contents thereof. If, for example, the "expected" first checking information were calculated in the access control device as an alternative and then compared with the communicated first checking information, the expected first checking information would have to be formed for a plurality of times depending on the granularity of the temporal validity (e.g. 1 minute, 10 minutes, 1 hour) used as access authorisation parameters and compared with the communicated first checking information in order to "meet" the communicated checking information exactly with at least one expected first checking information. Instead, in the present access control system, the integrity of the communicated temporal validity is established and this temporal validity is compared with the temporal information in the access control device in order to establish substantially more easily and quickly whether the difference is still within a predefined tolerance.In the access control system embodied according to the first to fourth aspects of the invention, the access control device represents an access control device from a plurality of access control devices, wherein the access control device stores a second key of a symmetrical or asymmetrical individual key pair, which is stored only on the access control device but not on any of the other access control devices of the plurality of access control devices, wherein the access control device additionally stores a second key of a symmetrical or asymmetrical group key pair, which second key differs from the second key of the individual key pair and is stored in all access control devices of a group of access control devices of the plurality of access control devices comprising the access control device, and wherein the second key of the key pair used in the first checking is either the second key of the individual key pair or the second key of the group key pair. Accordingly, the first key of the individual key pair or the first key of the group key pair is then also used when generating the first checking information (in particular at the access authorisation generating device). The access authorisation information generated for a specific access control device with the first key of the individual key pair is unique and can be used only for one access control device, but not for any other of the access control devices. In the event of loss of an access proof device with stored access proof information of this type, thus only abuse with one access control device and not with a plurality of access control devices is possible. Moreover, however, the group key pair makes it possible to generate access authorisation information which can be used to prove authorisation at a plurality of access control devices. This is advantageous, for example, if service personnel in a hotel are to gain access to a plurality of rooms provided with respective access control devices or delivery agents of packages are to gain access to a plurality of package boxes provided with respective access control devices, e.g. in a delivery district. Such access authorisation information generated with a first key of the group key pair can be stored, for example, on a tag (e.g. an RFID or NFC tag). Since such tags can have a relatively long period of validity (e.g. several months) and could be used for misbeat access to numerous access control devices if lost, it is advantageous that such tags or the access authorisation information located thereon are provided with a unique identifier which can be blocked, for example, by a rejection list stored in the access control device, as will be explained in more detail below.Further advantages of the disclosed access control system are described below with reference to exemplary embodiments, the disclosure of which is intended to apply equally to all four aspects of the invention and all respective categories (method, apparatus / system, computer program).In an exemplary embodiment of all aspects of the invention, the key pair is an asymmetric key pair, and the first checking comprises checking the communicated first checking information as a digital signature about the access authorisation parameters using at least the second key of the key pair and the communicated access authorisation parameters. The first and second keys of the asymmetric key pair are then different. For example, the first key is a private key and the second key is a public key, or vice versa. The digital signature is formed (in particular in the access authorization generating device), for example, by forming a hash value via the access authorization parameters, for example according to an algorithm of the Secure Hash Algorithm (SHA) family as specified by the National Institute of Standards and Technology (NIST), for example a SHA-1, SHA-224 or SHA-256, just to name a few examples. The hash value is then encrypted, for example, with the first key in order to obtain the first checking information. Alternatively, the access authorisation parameters can also be encrypted without hash value formation. To check the signature, the first checking information is decrypted using the second key and the hash value obtained thereby is compared with a hash value formed locally using the communicated access authorisation parameters according to the same algorithm. If the hash values match, the authenticity of the access authorisation information and the integrity of the access authorisation parameters can be assumed. If no hashing takes place, the access authorisation parameters obtained by decryption are directly compared to the communicated access authorisation parameters.In an exemplary embodiment of all aspects of the invention, the key pair is a symmetric key pair, and the first checking comprises performing the cryptographic operations on the communicated access authorisation parameters using at least the second key of the key pair to obtain locally generated first checking information and comparing the communicated first checking information with the locally generated first checking information. The symmetric key pair then comprises twice the same key, for example an AES key, e.g. an AES-128 key. The first checking information can be generated, as in the case of an asymmetric key pair, by encrypting the access authorisation parameters or a hash value thereof using the first key (in particular in the access authorisation generation device). The checking is then carried out by decrypting the communicated first checking information using the second key (identical to the first key) and comparing the result with either the access authorisation parameters or a hash value of the access authorisation parameters generated locally according to the same algorithm. If there is a match, the authenticity of the access authorisation information and the integrity of the access authorisation parameters are assumed. For example, the encryption / decryption may use a block cipher, for example, with an electronic code book (ECB), a cipher block chaining (CBC), a cipher feedback (CFB), an output feedback, or a counter mode of operation, as known to those skilled in the art, to enable the encryption / decryption of information longer than the block of the block cipher. Depending on the operating mode (e.g. in the CBC or CFM operating mode), an initialization vector (IV) may be required in addition to the keys during encryption / decryption. This can either be permanently agreed upon (and then stored in the access control device, for example) or communicated to the access control device for each access authorisation information. Instead of encryption / decryption of the access authorization parameters or their hash value in order to obtain the first check information, a message authentication code (MAC) can also be used for generating the first check information, which is formed via the access authorization parameters and likewise takes into account the first key. Examples of MACs are the Message Authentication Algorithm (MAA), the Keyed Hash Message Authentication Code (HMAC) or the Cipher-Based Message Authentication Code (CMAC) specified by the NIST. In the case of a MAC, for example, a type of hash value is created via the access authorisation parameters in a combined process and the first key is also taken into account in the process. The result is the first check information. For checking the first checking information, the access control device is configured on the basis of the identical rule about the communicated access authorisation parameters using the second (to the first identical) key of the MAC, and the result, the locally generated first checking information, is compared with the communicated first checking information. If matched, the authenticity of the access authorisation information and the integrity of the access authorisation parameters are verified.For example, at least one second key of a symmetrical or asymmetrical further group key pair, which is different from the second key of the individual key pair and the second key of the group key pair, is stored in the access control device, said second key being stored in all access control devices of a further group of access control devices of the plurality of access control devices comprising the access control device but containing at least one or more other access control devices in comparison with the group of access control devices, and wherein the second key of the key pair used during the first checking is either the second key of the Individualschlüsselpaars the second key of the group key pair or the second key of the further group key pair. The access control device then has, for example, the second keys of the individual key pair and two group key pairs. If the access control device is assigned to a parcel box, for example, it can occur, for example, when dynamically defining delivery areas, that the same parcel box is assigned to a first delivery area on one day and to a second delivery area on another day. In order that the parcel box can nevertheless be opened both by the delivery agent of the first delivery area and by the delivery agent of the second delivery area, it is advantageous to store the respective second keys of two group key pairs on the access control device. The access authorisation information of the deliverer of the first delivery area (in particular its first checking information) is then based on the first key of a first group key pair, and the access authorisation information of the deliverer of the second delivery area (in particular its first checking information) is then based on the first key of a second group key pair. This access authorisation information can then be stored, for example, on respective tags for the respective delivery areas (a first tag for the first delivery area and a second tag for the second delivery area).For example, it may not be provided to change, delete or exchange the second key of the individual key pair in the access control device, but it may be provided that the second key of the group key pair may be changed or deleted or exchanged for another key. The second key of the individual key pair can thus form, in particular, a fixedum which is not changed during the useful life of the access control device. In particular, the second key of the individual key pair can be used to check also information (for example group key information or rejection information) different from the access authorisation information, in particular generated by the access authorisation generating device using the first key of the individual key pair, for authenticity and integrity, as will be explained in more detail below. The second keys of the group key pairs, on the other hand, can be changed, deleted or exchanged, which is relevant, for example, if a parcel box has to be moved into another delivery area due to the removal of its owner. How this is done is explained below.In an exemplary embodiment of all aspects of the invention, group key information communicated to the access control device at the access control device, which group key information comprises at least one second key of a new symmetrical or asymmetrical group key pair encrypted with the first key of the individual key pair for the same or an at least partially different group of access control devices of the plurality of access control devices, the communicated encrypted second key of the new group key pair is decrypted with the second key of the individual key pair, and the second key of the new group key pair obtained by the decrypting is stored in the access control device, such that the second key of the key pair used in the first checking is at least either the second key of the individual key pair or the second key of the new group key pair. The group key information can be generated in particular at the access authorisation generation device and communicated to the access control device by means of the access authorisation verification device, for example within the scope of the same communication session in which the access authorisation information is also communicated to the access control device, but temporally before the access authorisation information, so that the second key of the new group key pair can already be taken into account when checking the access authorisation information if necessary. The second key of the already present group key pair can be deleted or retained. For example, the group key information can contain a list of one or more encrypted second keys of respective one or more new group key pairs, which replaces all second keys of respective group key pairs already present in the access control device. The individual key pair in turn serves here as a trust basis between the access control device and the access authorisation generating device, but does not allow checking of authenticity or integrity, since the second keys of the respective one or more group key pairs are not additionally transmitted unencrypted. However, the encryption ensures that no one, besides the access authorisation generation device and the access control device, can read the second keys of the respective one or more new group key pairs in plain text, in particular not the access authorisation verification device. In the case that the individual key pair is a symmetric key pair, for example, symmetric AES encryption takes place in the CBC operating mode. An initialization vector for the CBC mode can be communicated, for example, together with the group key information, e.g. as a component thereof, to the access control device in order to be used there in the decryption.In order to enable checking the authenticity and integrity of the communicated group key information, the following can be carried out, for example. Second checking information communicated to the access control device is obtained, and the second key of the new group key pair obtained by the decrypting is stored in the access control device only on the condition that, in a checking based on at least the communicated second checking information, the second key of the individual key pair and the communicated group key information, it is determined that the communicated second checking information was generated by performing cryptographic operations on the group key information corresponding to the communicated group key information using at least the first key of the individual key pair. The calculation of the second checking information and its checking can be carried out, for example, analogously as already described above on the basis of the first checking information, wherein the cryptographic operations are carried out via the group key information instead of the access authorisation parameters. Thus, for example, digital signatures or MACs can again be used as second checking information. The second check information is generated in particular at the access authorisation generation device and then communicated from the access authorisation verification device to the access control device.The group key information can additionally comprise a counter (update_counter) which is incremented with each new group key pair, wherein the second key of the new group key pair obtained by the decryption is stored in the access control device only on the additional 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 device, and wherein, during or after the storage of the second key of the new group key pair in the access control device, the value of the counter in the access control device is updated to the value of the counter (update_counter) comprised by the group key information. The counter comprised by the group key information is then, for example, a copy of a counter which is incremented in the access authorisation generation device upon each new generation of group key information (i.e. for example each time one or more second keys of respective one or more new group keys are to be brought to the access control device).The group key information can, for example, additionally comprise an individual identifier of the access control device, and the second key of the new group key pair obtained by the decryption can, for example, be stored in the access control device only on the additional prerequisite that an individual identifier of the access control device stored in the access control device matches the individual identifier comprised in the group key information. The group key information is thus uniquely assigned only to one access control device.In addition, since the second check information is formed via the group key information, the integrity of the individual identifier in the group key information is ensured.The group key information can additionally comprise, for example, a group identifier associated with the new group key pair, which is common to all access control devices of the group of access control devices for which the new group key pair is intended, and the group identifier obtained by the decryption is stored, for example, in the access control device. The group identifier may serve as reference information for checking an identifier communicated as access authorisation parameter of that access control device for which the access authorisation information is intended, and may facilitate the selection of the second key of the key pair which is used in the first checking, as will be explained in more detail below.In an exemplary embodiment of all aspects of the invention, one of the communicated access authorisation parameters is an identifier for only one access control device or a group of access control devices, wherein it is determined that the identifier authorizes access if the identifier matches an individual identifier of the access control device stored in the access control device and / or a group identifier for a group of access control devices to which the access control device belongs. An identifier contained in the access authorisation information is thus used for assigning the access authorisation information to an access control device, either on the basis of its individual identifier or on the basis of its group identifier.In an exemplary embodiment of all aspects of the invention, one of the communicated access authorisation parameters is an identifier for only one access control device or for a group of access control devices, wherein it is determined that the identifier authorizes access if the identifier matches an individual identifier of the access control device stored in the access control device and / or a group identifier for a group of access control devices to which the access control device belongs, wherein the first checking information of communicated access authorisation information which has an identifier for only one access control device is generated by carrying out cryptographic operations on the access authorisation parameters using at least one first key of the individual key pair, and wherein the first checking information of communicated access authorisation information which has an identifier for a group of access control devices, by performing cryptographic operations on the access authorisation parameters using at least one first key of the group key pair. An identifier contained in the access authorisation information is thus used for assigning the access authorisation information to an access control device, either on the basis of its individual identifier or on the basis of its group identifier. An additional assignment of the access authorisation information takes place via the selection of the group key pair: if the access authorisation information contains an identifier for only one access control device, its first checking information is generated using the first key of the individual key pair (and correspondingly checked in the access control device on the basis of the second key of the individual key pair). If, however, the access authorisation information contains an identifier for a group of access control apparatus, its first checking information is generated using the first key of the group key pair (and correspondingly checked in the access control apparatus on the basis of the second key of the group key pair).For example, it can be recognized in the access control device on the basis of the identifier, in particular on the basis of a predefined format of the identifier, whether it is an identifier for only one access control device or an identifier for a group of access control devices, so that either the second key of the individual key pair or the second key of the group key pair can be selected in a suitable manner in the access control device for the first checking. For example, a predefined occupancy of one or more predefined bit locations of the identifier may indicate whether it is an identifier for only one access control device (e.g.: last bit location="0") or an identifier for a group of access control devices (e.g.: last bit location="1")In an exemplary embodiment of all aspects of the invention, one of the communicated access authorisation parameters is an identifier for the access authorisation information or for an access authorisation verification device which communicates the access authorisation information to the access control device, and it is determined that the identifier authorizes access if the identifier is not contained in a rejection list stored in the access control device. This is advantageous in particular because, in the event of loss of access authorisation verification device with access authorisation information stored thereon, blocking of the access authorisation information concerned is possible. The rejection list on the access control device may be updated, for example, by other access credential devices on the access control device and then also include newly lost access credential devices / access credential information, as will be described in more detail below.In an exemplary embodiment of all aspects of the invention, it is further provided that information communicated to the access control device is obtained which comprises at least one fourth key encrypted using at least the first key of the key pair, which fourth key is usable during authentication of the access control device with respect to an access credential device which communicates the access credential to the access control device, or during checking the authenticity and / or integrity of information communicated to the access control device, and that the encrypted fourth key is decrypted using at least the second key of the key pair in order to obtain the fourth key. In contrast to the second key of the key pair or the key pair itself, which represents a secret between the access authorisation generation device and the access control device, the fourth key is assigned to the access authorisation verification device.The fourth key can form a symmetrical or asymmetrical key pair with a third key, for example. The fourth key is provided to the access credential device by the access credential generation device, for example, in encrypted form (using the first key of the key pair) as described above for communication to the access control device, and additionally, for example, the third key may be provided to the access credential device in unencrypted form, for example, so that the access credential device may thereby perform cryptographic operations, which are, for example, related to authentication of the access control device to the access credential device or to enable verification by the access control device of authenticity and / or integrity of information communicated to the access control device. The access control device can then determine, for example on the basis of the decrypted fourth key, the second key of the key pair and the communicated access authorisation information (with the first checking information contained therein), that the access authorisation information is intended for the access control device (on the basis of the first checking information and the second key of the key pair as described in detail above) and has been communicated by an access authorisation verification device (authorised by the access authorisation generation device) (checked by authentication with respect to the access authorisation verification device by means of H or by checking the authenticity and / or integrity of information communicated to the access control device by the access authorisation verification device by means of H). The information with the encrypted fourth key can be communicated to the access control device by the access credential device, for example, in the same session in which the access credential information is also communicated from the access credential device to the access control device.In an exemplary embodiment of all aspects of the invention, it is further provided that information communicated to the access control device is obtained which comprises at least one combination of a fourth key and an identifier for the access authorisation information encrypted using at least the first key of the key pair or for an access authorisation verification device which communicates the access authorisation information to the access control device, wherein the fourth key is usable when the access control device is authenticated with respect to an access authorisation verification device which communicates the access authorisation information to the access control device or when checking the authenticity and / or integrity of information communicated to the access control device, and that the encrypted combination is decrypted using at least the second key of the key pair in order to obtain the fourth key and the identifier, wherein the identifier additionally represents one of the communicated access permission parameters, and wherein it is determined that the identifier included in the communicated access permission information permits access if the identifier included in the communicated access permission information matches the identifier obtained by decrypting the encrypted information. The explanations regarding the preceding embodiment apply to the present embodiment accordingly. In contrast to the previous embodiment, however, in the present embodiment the fourth key is additionally bound to the identifier together with the identifier by the encryption, and thus also to the access authorisation information or access authorisation verification device identified by the identifier. It is advantageous here firstly that a possibility is provided of providing the access control device with reference information for checking the identifier of the access authorisation information or access authorisation verification device contained in the access authorisation information as access authorisation parameters, which reference information is not present in the access control device (in contrast to other reference information such as, for example, the identifier of the access control device or the time information) Moreover, the access control device can then determine, on the basis of the decrypted fourth key, the decrypted identifier, the second key of the key pair and the communicated access authorisation information (with the identifier contained therein as access authorisation parameter and the first checking information), that the access authorisation information is determined for the access control device (on the basis of the first checking information and the second key of the key pair as described in detail above), an access credential device (authorized by the access credential generation device) has been communicated (checked by authentication to the access credential device by means of H or by checking the authenticity and / or integrity of information communicated to the access control device from the access credential device by means of H), and that the access credential device has been specifically authorized by the access credential generation device for this access credential. The information with the encrypted combination of the fourth key and the identifier can be communicated to the access control device by the access credential device, for example, in the same session in which the access credential is also communicated from the access credential device to the access control device.In an exemplary embodiment of all aspects of the invention, it is further provided that information communicated to the access control device is obtained which comprises at least one combination of a fourth key and an identifier for the access authorisation information encrypted using at least the first key of the key pair or for an access authorisation verification device which communicates the access authorisation information to the access control device, wherein the fourth key is usable during an authentication of the access control device with respect to an access authorisation verification device which communicates the access authorisation information to the access control device or during the checking of the authenticity and / or integrity of information communicated to the access control device, that the encrypted combination is decrypted using at least the second key of the key pair in order to obtain the fourth key and the identifier, wherein the identifier additionally represents one of the communicated access authorisation parameters, and it is determined that the identifier included in the communicated access permission information permits access if the identifier included in the communicated access permission information matches the identifier obtained by decrypting the encrypted information and the identifier is not included in a reject list stored in the access control device. The explanations relating to the two preceding embodiments apply correspondingly to the present embodiment. In the present embodiment, however, the identifier of the access authorisation information or access authorisation verification device contained in the encrypted combination or in the access authorisation information performs a dual function: firstly, it serves to ensure that the communicated access authorisation information originates from an access authorisation verification device authorised by the access authorisation generation device (established by comparison of the identifier contained in the encrypted combination with the identifier contained in the access authorisation information), and secondly, it is used for matching with a rejection list stored in the access control device, which thus represents reference information for checking the access authorisation parameters represented by the identifier.For example, the access authorisation information communicated to the access control device can be stored in identical form on at least two access authorisation verification devices, wherein these identical access authorisation information stored on the at least two access authorisation verification devices each have the same identifier for the access authorisation information and these access authorisation information are each associated with the same fourth key (i.e. for example the respective identifier for the access authorisation information is each encrypted as a combination with the same fourth key using the first key of the key pair, for example in order to bind the respective identifier to the fourth key). For example, a plurality or all of the access authorisation information contained on the access authorisation verification device which communicates the access authorisation information to the access control device can also be associated with this fourth key, wherein the identifiers of this access authorisation information which are in particular intended for different access control devices differ. For example, all access authorisation information contained on a plurality of access authorisation verification devices can also be associated with this fourth key. There is then, for example, (at least at one time) only a single fourth key for the access credential devices and their access credential information. The identifier of the access authorisation information is then, for example, only specific in each case for the access control device for which the access authorisation information is intended, but not specific for the access authorisation verification device on which the access authorisation information is stored.The use of a same fourth key for a plurality of different access authorisation information items on a plurality of access authorisation verification devices and the use of identifiers of the access authorisation information items specific only for the access control devices but not specific for the access authorisation verification device can allow a considerable reduction in the effort associated with the generation and assignment of the fourth key and the access authorisation information items, in particular in the case of large numbers of access authorisation devices and access control devices compared with fourth keys individually selected per access authorisation verification device and for each pairing of access control device and access authorisation verification device individual identifiers of the access authorisation information items, since access authorisation information item only has to be generated for each access control device and the number of combination of the fourth key with the identifier of the access authorisation information item which has to be encrypted with the first key of the key pair for a respective access control device, This also corresponds only to the number of access control devices. This simplification, however, entails the disadvantage that each access authorisation verification device can now gain access to all access control devices whose access authorisation information contains them. The access authorisation information is thus only still bound to a respective access control device, but not to a specific access authorisation verification device. Thus, for example, if a group of M access credential devices (e.g., delivery devices) is each equipped with access credential information for N different access control devices (e.g., packet boxes) (wherein the access credential information for a particular access control device is the same on each of the M access credential devices and only the access credential information for different access control devices respectively differ) so that each of these access credential devices can provide access to each of the N access control devices, loss of an access credential device can result in the N access credential information stored on that access credential device being locked only by the identifiers for that N access credential information being entered in respective reject lists on all N access control devices. However, no other of the M-1 access credential devices can then provide access to the N access control devices. This disadvantage, due to a simplified management possibility, can be solved by a series of measures, as will be presented below.For example, it can be provided that the access authorisation information communicated to the access control device has a limited temporal validity (which is, for example, 1 month, 2 weeks, 1 week, 3 days or 1 day) and / or only has a limited permissible number of access processes within its validity period (for example, less than 5, 4 or 3 access processes) and / or can be communicated from the access authorisation verification device only to the access control device if it is determined at the access authorisation verification device that there is a need for access to the access control device (for example, because a packet or a shipment is to be inserted into a packet box controlled by the access control device or is to be fetched therefrom).The limitation of the temporal validity and / or the number of the permissible number of access processes reduces the possibility of abuse in terms of time and with regard to the number of possible abuse actions per access control device.Considering the need for access limits the possibility of abuse to the access control devices where access procedures are actually needed, which is usually only a small part of the access control devices for which an access credential device has stored access credential information. The need for access can be determined, for example, on the basis of shipment data stored on the access authorisation verification device, e.g. a delivery agent appliance. For example, the delivery agent can optically scan an identification of the shipment from a package, acquire it or read it by radio and input it into the delivery agent device. The delivery agent device can then ascertain, for example, the shipment data belonging to the identification in the delivery agent device and, on the basis of a comparison of the address data (e.g. zip code, street and house no.) of the shipment and the addresses of the parcel boxes and / or the addresses of the users of parcel boxes likewise stored in the delivery agent device, select that parcel box for which the shipment is intended. By means of these measures, it is possible, for example, to completely dispense with the blocking of identifiers for access authorisation information which were stored on the released access authorisation verification device under certain circumstances and / or thus to significantly reduce the length of the rejection lists managed in the access control device (for example, only identifiers of access authorisation information which were stored on lost tags are then contained there, but not those of access authorisation information stored on the released delivery agent devices).For example, the access credential communicated to the access control device may be stored in identical form on at least two access credential devices, wherein these at least two access credential devices each have the same third key. Therefore, the same third key is used on the at least two access credential devices (or, for example, on all access credential devices of a group of access credential devices), which third key forms a symmetrical or asymmetrical key pair with the fourth key. Thus, for example, these access proof devices are authenticated with respect to the access control device using the same third key. However, the disadvantage of potentially slightly reduced security associated with the use of an identical third key for multiple access credential devices (or, for example, all of a group or system) that enables a significant reduction in the amount of security associated with the generation and distribution of the third key to the access credential devices (and also the generation and use of the fourth key) may be mitigated or eliminated by one or more (e.g., all) of the actions outlined in the preceding section.The fourth key can additionally or alternatively also be used for the purposes described below.For example, the fourth key forms a symmetric or asymmetric key pair with a third key, the communicated access authorisation information further comprises third checking information, and a second checking, using at least one challenge generated by the access control device, the communicated access authorisation parameter, the communicated first checking information, the communicated third checking information and the fourth key, is also performed at the access control device whether the communicated third checking information has been generated by carrying out cryptographic operations over information corresponding to the generated challenge, the communicated access authorisation parameters and the communicated first checking information using at least the third key, wherein a further necessary condition for granting access is that the second checking provides a positive result. The challenge can be, for example, random information (e.g. a binary random number sequence) which is transmitted from the access control device to the access proof device. The access credential device can generate the third item of verification information by carrying out cryptographic operations on the basis of the challenge, the access credential parameters, the first item of verification information and the third key, for example according to one of the methods already described above for generating the first item of verification information. If the fourth key is part of a symmetric key pair, the cryptographic operations can, for example, generate a MAC as third checking information, or a digital signature can be generated if the fourth key is part of an asymmetric key pair. By means of the second checking, the access control device can check, in particular, the authenticity and integrity of the access authorisation parameters and first checking information communicated by the access authorisation verification device, that they have thus been communicated by the access authorisation verification device and have not been changed. The use of challenge protects against replay attacks. This use of the fourth key can be used, for example, when the access authorisation information is transmitted from a user device (e.g. a mobile telephone) or a delivery device (e.g. a hand scanner) to the access control device, for example by Bluetooth transmission.Alternatively, the fourth key can be used in authenticating against an access credential device containing the access credential using at least the fourth key, wherein the access credential is communicated from the access credential device to the access control device only upon successful authentication. If the fourth key (and consequently the third key also) is a symmetric key, for example, the access control device and the access proof device can, for example, mutually confirm that they each have the symmetric key, for example by encrypting challenges obtained from the opposite side and local counter checking. If the access authorisation verification device is, for example, a tag, for example an NFC tag from the Mifare tag of N XP, the symmetrical key can be stored in the tag and access (in particular to the access authorisation parameters and the first checking information, which are stored, for example, in an "application" of the tag) can be permitted to the access control device only if both the tag and the access control device accessing the tag have mutually verified that they have the symmetrical key (for example, via a so-called three-step mutual authentication (three-step mutual authentication)).In an exemplary embodiment of all aspects of the invention, provision is further made for rejection information (L) communicated to the access control device, which comprises at least one new rejection list having identifiers for access authorisation information to be rejected or for access authorisation devices from which access authorisation information is to be rejected at the access control device, and fourth checking information to be obtained at the access control device, and for the communicated new rejection list to be stored on the access control device only on the proviso that, in a checking based at least on the communicated fourth checking information, the second key of the key pair and the communicated rejection information, it is determined that the communicated fourth checking information was generated by carrying out cryptographic operations on the rejection information corresponding to the communicated rejection information using at least the first key of the key pair. On the basis of the fourth check information, the authenticity and integrity of the reject information obtained can be checked at the access control device, for example on the basis of one of the methods as already explained above for the first check information. A new rejection list can be communicated to the access control device, for example, as soon as it has become known that at least one identifier of an access authorisation information or access authorisation verification device is to be blocked, for example, due to the loss of an access authorisation verification device. As already explained above, on the access control device it can be a prerequisite for granting access that the identifier of the access authorisation information with which access is requested is not contained on the rejection list.The rejection information may additionally comprise, for example, a counter which is incremented with each new rejection list, wherein the new rejection list is stored in the access control device only on the additional prerequisite that the value of the counter comprised by the rejection information is greater than a value of a counter provided in the access control device, and wherein the value of the counter of the access control device is updated to the value of the counter comprised by the rejection information during or after the storage of the new rejection list in the access control device. This can prevent an attempt from being made to install an old rejection list (which does not contain identifiers that are currently to be blocked, for example) on the access control device.The rejection information can additionally comprise, for example, an identifier of only one access control device or of a group of access control devices on which the new rejection list is to be stored, wherein the new rejection list is stored in the access control device only on the additional prerequisite that an individual identifier of the access control device stored in the access control device or a group identifier for a group of access control devices containing the access control device matches the identifier comprised in the rejection information. This identifier ensures that the rejection list can only be installed on a specific access control device or group of access control devices.The exemplary embodiments described above and exemplary configurations of all aspects of the present invention are also intended to be understood as disclosed in all combinations with one another.Further advantageous exemplary embodiments 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. The figures attached to the application are intended, however, for the purpose of illustration only, but not for the purpose of determining the scope of the invention. The accompanying drawings are not necessarily to scale, and are intended to reflect, by way of example only, the general concept of the present invention. In particular, features included in the figures are not to be considered as a necessary part of the present invention in any way.The following are shown: FIG. 1 is a schematic illustration of an exemplary embodiment of a system according to the present invention, FIG. 2 is a schematic illustration of an exemplary embodiment of an apparatus according to the present invention, FIG. 3 is a schematic illustration of another exemplary embodiment of a system according to the present invention; FIG. 4 is a flow diagram of an exemplary embodiment of communication of access entitlement information between a hand held scanner / mobile phone and a parcel box in accordance with the present invention; FIG. 5 is a flow diagram of an exemplary embodiment of communication of access entitlement information between a tag and a packet box in accordance with the present invention; FIG. 6 is a flow diagram of an exemplary embodiment of communication of rejection information between a hand held scanner / mobile phone / tag and a parcel box according to the present invention; FIG. 7 is a flow diagram of an exemplary embodiment of communication of group key information between a hand held scanner / mobile phone / tag and a packet box in accordance with the present invention; FIG. 8 is a flow diagram of an exemplary embodiment of a communication of keys and access authorisation information between the key server and further components of an exemplary system according to the invention; FIG. 9 is a schematic illustration of the distribution of group keys and access authorisation information in an exemplary system according to the invention; FIG. 10 : shows a schematic illustration of the assignment of parcel boxes to different delivery areas according to an exemplary embodiment of the invention; and FIG. 11 is a flow chart of the possible order of operations in an exemplary embodiment of a package box according to the present invention.An overview of an exemplary embodiment of a system 1 according to the invention is shown in FIG. 1. The system comprises an access credential generation device 2, an access credential device 3 and an access control device 4. In particular, the access credential device 3 and the access control device 4 may be present multiple times, but are only singly represented in each case for the sake of simplifying the illustration. Components 2, 3 and 4 represent exemplary devices according to the first, third and second aspect of the invention, respectively, the properties of which have already been described in detail. FIG. 1 therefore serves primarily to illustrate which keys are stored in the individual components and which information is exchanged between the components. Access authorization generating device 2 stores in particular the first individual key S 1 and optionally also a first group key S T1, which form in each case an individual key pair (S 1, S 2) or a group key pair (S T1, S T2) with a second individual key S 2 or a second group key S T2 in the access control device 4. These pairs can each form a symmetrical or asymmetrical key pair, wherein in the case of a symmetrical key pair both keys are the same, i.e. for example S 1= S 2= S and / or S T1= S T2= S T applies and in the case of an asymmetrical key pair S 1 ≠S 2 and / or S T1 ≠S T2 applies.The access credential generation device 2 generates and transmits one or more of the following information to the access credential device 3:access authorisation information B and first checking information V,- the signal with S 1 od. S T1 encrypts fourth key H 4, within the scope of information A,a third key H 3,the group key information W and the second check information V W, and / orthe rejection information L and the fourth check information V L,This information can be transmitted, for example, at least partially (or completely) within the same communication session between the access authorisation generation device 2 and the access authorisation verification device 3 (that is to say, for example, between the establishment and the initiation of a communication connection between the access authorisation generation device 2 and the access authorisation verification device 3), or else in different communication sessions. However, the group key information W can be transmitted less frequently than the access authorisation information B and the rejection information L, for example, since there is less frequently a need for its changeThe transmission of this information can be effected at least partially wirelessly (e.g. via mobile radio or WLAN) from the access authorisation generation device 2 to the access authorisation verification device 3, in particular if the access authorisation verification device 3 is a portable user device (e.g. a mobile telephone) or a portable delivery device (e.g. a hand scanner) The transmission does not have to be effected directly in this case, but can be effected via one or more intermediate stations (e.g. the decentralized units still discussed below), as will be discussed in more detail below. If the access proof device 3 is a tag (e.g. an RFID or NFC tag), the transmission of the information is to be understood logically and can mean, for example, that the information is transmitted to a server of a production system for the tags and stored there in the tags.The third key H 3 and the fourth key H 4 in turn form a key pair (H 3, H 4), which can be symmetrical, for example, that is to say H 3= H 4= H, or asymmetrical, that is to say H 3 ≠H 4.Of the information which is transmitted from the access authorisation generation device 2 to the access authorisation verification device 3, in principle any information, except for the third key H 3, can be communicated further from the access authorisation verification device 3 to the access control device 4 and then used in the access control device 4 for checking whether this information is authentic and integer and whether-in the case of the access authorisation information-access can be granted to the operator of the access authorisation verification device 3.The third key H 3 is stored in the access proof device 3 and used, for example, in the context of the mutual authentication between the access proof device 3 and the access control device 4, wherein the latter has received the counterpart to the third key H 3, namely the fourth key H 4, transmitted in encrypted form (information A) and stores it at least temporarily after decryption.FIG. 2 shows a schematic representation of an exemplary embodiment of a device 5 according to the present invention. Device 5 can represent, for example, access authorisation generation device 2, access authorisation verification device 3 or access control device 4 of FIG. 1.Device 5 comprises a processor 50 with associated working memory 52 and program memory 51. The program instructions execute and / or control the method according to the first, second or third aspect of the invention. Thus, the program memory 51 contains a computer program according to the first, second or third aspect of the invention and represents a computer program product for storing the same.The program memory 51 may be, for example, a persistent memory such as a read only memory (ROM). The program memory can be permanently connected to the processor 50, for example, but can alternatively also be releasably connected to the processor 50, for example as a memory card, a floppy disk or an optical data carrier medium (e.g. a CD or a DVD). Further information can also be stored in the program memory 51, or in a separate memory. If device 5 is access authorisation generation device 2, this information can include, for example, keys S 1 and / or S T1 and / or keys H 3 and / or H 4 as well as, for example, information about the access control device for which access authorisation information is to be generated (e.g. the identifier of the access control device) and information about the access authorisation information, the group key information and / or the rejection information and their associated checking information. If device 5 is access credential device 3, this information may include, for example, the information obtained from access credential generation device 2 (in particular, B, V, W, V w, L, V L, A, H 3). If device 5 is access control device 4, these items of information can include keys S 2 and / or S T2 and reference information, on the basis of which access authorisation parameters obtained are checked to determine whether they each authorize access to grant access (e.g. an identifier of the access control device, a rejection list, one or more counters, e.g. for group key information or rejection information, etc.).The working memory 52 is used, for example, for storing temporary results during the execution of the program instructions; this is, for example, a volatile memory, such as a random access memory (RAM) memory.The processor 50 is further operatively connected to a communication unit 53 that allows, for example, information exchange with external devicesIf the device 5 represents the access authorisation generation device 2, the communication unit 53 can be configured, for example, for communication via a network such as the Internet, in order, for example, to be able to transmit information to one or more of the following units:to a server of a manufacturer of access control devices 4 (cf. server 72 in FIG. 9 ) and / orto a server of a manufacturer of access proof devices 3 (cf. server 73 in FIG. 9 ), and / oran interface server of a mobile communication network, via which information is to be transmitted wirelessly to an access credential device 3 (e.g. a mobile telephone or a hand-held scanner), and / ora 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 credential devices 3 (e.g. delivery agent devices) takes place, and / orat least indirectly to a computer (e.g. a decentralised unit 71-2 in Fig. 8), from or under the control of which the information is then to be transmitted to access authorisation verification devices 3 (e.g. delivery agent devices) (for example wirelessly (e.g. via a WLAN) or by wire (e.g. via a LAN)).If the device 5 represents the access proof device 3 in the form of a user device or delivery agent device, the communication unit 53 can comprise, for example:a mobile radio interface for receiving information from the access right generating device 2,an interface for wirelessly (e.g. via WLAN) or wirelessly (e.g. via a docking station) receiving information from a device (for example a decentralised unit) to which the access authorisation generation device 2 has transmitted this information for transmission to the access authorisation verification device 3)a radio interface for communication with the access control device 4, in particular a Bluetooth interface and / or an RFID interface and / or an NFC interface.When the device 5 represents the access credential device 3 in the form of a tag, the communication unit 53 may include, for example:a radio interface for communication with the access control device 4, in particular a Bluetooth interface and / or an RFID interface and / or an NFC interface.The device 5 can also contain further components, for example a graphical user interface, in order to allow an operator to interact with the device 5, in particular if device 5 represents an access authorisation verification device 3 in the form of a user device or delivery device. If device 5 represents a delivery agent device, a unit for, in particular, optical detection of information (e.g., a scanner) can be included by device 5, for example, and / or a user interface for detecting handwritten inputs, such as a signature, for example.If device 5 represents an access control device 4, an, for example, optical and / or acoustic user interface can likewise be provided in order to be able to output, to the operator, information about the status of access control device 4 and / or about the success of an attempt to gain access granted to access control device 4 using access authorisation information. In the case of an access control device 4, the device 5 can also comprise control means for controlling a locking unit (e.g. for unlocking the same) depending on the decision whether access can be granted. The locking unit can comprise, for example, a lock that can be actuated in particular electronically. In the context of describing the embodiments of Figures 3-10, a unit comprising at least processor 50, memories 51 and 52, and the locking unit is referred to as a "lock.". In the case of an access control device 4, the device 5 can additionally also comprise one or more sensors, for example for detecting a current closed state of the locking unit. In the case of an access control device 4, the device 5 can comprise, for example, a battery (for example, rechargeable or even not), in particular as the only power supply. In the case of an access control device 4, the device 5 can have, for example, no connection to a wired network, i.e., in particular no connection to a LAN, and / or can have, for example, no connection to a WLAN or a mobile radio network (in particular a cellular mobile radio network).In the case of an access proof device 3 in the form of a tag, the device 5 may for example not comprise its own power supply and may draw its energy for communication from the field of a reading unit of the access control device 4. No user interface may be present in such a day.The components 50- 53 can be configured together as a module or unit, for example, or can be configured at least partially as individual modules in order to ensure easy exchangeability in the event of any defects.In the following, a concrete exemplary embodiment of an access control system 6 according to the invention is presented on the basis of FIGS. 3-10, which is illustrated in FIG. 3 : in this access control system 6, the access authorisation generating device 2 is designed as a key server 60, the access control devices 4 are designed as packet boxes 69 (or access-controlling units thereof, in particular "locks") which are assigned to users 63 (e.g. users registered for the use of the packet boxes), and the access authorisation verification devices 3 are designed as hand scanners 68 or tags 74 of deliveryers 70 or as mobile telephones 61 or tags 62 of users 63, which are collectively referred to as "tokens". The users 63 are here, for example, the owners of parcel boxes or other persons (e.g. of the same household or the neighborhood) who have registered in order to be able to receive shipments in a specific parcel box 69 or to be able to collect them from them. The users 63 are also referred to as parcel box users. The delivery agents 70 may be, for example, parcel delivery agents, compound delivery agents (which deliver both letters and packages), or delivery agents. For example, it is important for the parcel deliveryers and the group deliveryers to be able to open the parcel box in order to be able to deliver parcels into it or collect packages from it. For example, it is important for compound dispensers and letter dispensers to be able to open the parcel box in order to be able to deliver large-format letters (e.g. maxibriefe) which may not fit through a letter slot of the parcel box into the latter by opening the parcel box.The specification of the components 2, 3 and 4 carried out in FIGS. 3-10 and the associated description is, however, merely for illustrative purposes and should not be understood as essential or restrictive. In particular, the interaction of the components 2, 3 and 4 concreted in this way should also be understood as disclosed in general form-i.e. separately from the concrete embodiment of these components. This also applies to the transmission techniques, in particular Bluetooth and NFC, which are concreted for the purpose of explanation and which are to be understood merely as an example of a possible form of wireless communication between access authentication devices 3 and access control devices 4. A parcel box 69 is a container with at least one lockable door, which is configured at least for receiving parcels, for example at least one parcel with the dimensions 45 x 35 x 20 cm (which corresponds to a so-called "parcel set L"), or at least two or three such parcels. The parcel box 69 can also have a mailbox (alternatively, however, it can also have no mailbox), into which letters can be inserted, for example, through a mailbox with or without a covering flap. The mailbox can be lockable with its own door (with a mechanical or electronic lock), or alternatively can be locked via 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 mailbox are provided in each case, a common access control device can be provided, for example, which either opens a door (e.g. the door of the parcel compartment, e.g. for the delivery agent 70) or opens both doors (e.g. for the user 63) depending on the access authorisation. The parcel box 69 can be provided for mounting in or on a wall, for example a house wall, or as a self-standing unit for fastening to the floor, for example in front of a house. The user 63 is notified, for example via email and / or SMS, of newly delivered items (packages and / or letters) It is also possible for the user 63 to insert franked items into the package box 69 and request a pickup online or by telephone. If no collection is requested, the shipment may be collected somewhat delayed if a delivery agent opens the parcel box the next time and finds the shipment there. As evidence for a fetched consignment, the delivery agent will leave evidence in the parcel box, for example.The key server 60 is operated, for example, in a suitable data center of a delivery company, in particular the Deutsche Post DHL. It generates keys and access permissions and communicates them in particular to the provision server 66. As will be described in more detail below with reference to FIG. 8, the provision server selects access permissions required for respective delivery areas from the access permissions (and gfs. also keys) obtained from the key server 66, allocates this information with address information of parcel boxes and / or their users (and gfs. also the MAC addresses of the locks of the parcel boxes 69, with the aid of which the hand scanners 68 can initiate a Bluetooth connection without the time-consuming Bluetooth pairing being required) obtained from the parcel box management system 65, and provides these directly or indirectly to the hand scanners 68. The selection is based on the so-called district cutting, i.e. the assignment of shipments to be delivered or picked up to delivery districts for which the delivery agents 70 can log in with their hand scanners 68, wherein this district cutting is carried out by the assignment server 67 which has access to the shipment data.In parallel, the packet receivers 63 receive their keys and access authorisation information with which they can open the packet boxes 69. A user 63 buys a parcel box 69 and / or registers a parcel box 69 via, for example, an online portal 64 (e.g., the domain www.parcelde) that exchanges information related to this with the server of the parcel box management 65. In addition or as an alternative to the hand scanners 70 of the delivery agents, tags 74 are also provided with which the delivery agents 70 (in particular delivery agents) can each open a multiplicity of parcel boxes 69, for example all parcel boxes 69 of a delivery area. In a similar manner, tags 62 are also provided for the users 63 in addition or alternatively to the mobile telephones 61, although these tags usually only open the packet box 69 assigned to a user 63 in each case, which are also referred to as individual lock access (ILA) tokens in the following. The access authorization information and keys contained on the tags 62, 74 are also generated by the key server 60 and then stored on the tags, as indicated by the dashed lines in FIG. 3.When the user 63 uses a mobile phone to open the parcel box 69, this mobile phone can communicate with the key server 60 via, for example, a software application (hereinafter referred to as "app"). The app itself and / or its communication with the key server 60 can be designed to be particularly secure, for example by means of measures such as encrypted communication, version control, curing, password protection, etc.In the following, the components of the access control system 6 of FIG. 3 will first be described in more detail.LocksLocks are incorporated into the parcel boxes 69, which are used by the delivery company to deliver both packages and letters to customers 63. Since letters and packages are to be delivered exclusively to the original recipient 63, the package boxes 69 are responsible for the actual access authorisations. The parcel boxes 69 are accordingly equipped with (in particular electronically controllable) locks and a communication interface. Furthermore, they contain the logic to obtain access authorisations and to verify and ensure access, that is to say opening. Parcel boxes 69 are either owned by individual customers 63 or they are shared by different customers 63.Access PermissionsDelivery agents 70 or users 63 are granted access to parcel boxes 69 only if they are in possession of a valid access authorisation. Access authorisations comprise one or more of the already described access authorisation parameters. Access authorisations are reproduced in electronic form and written to a physical token. Access authorisation can be restricted both with respect to a useful life (not before and not later) and with respect to the number of uses thereof-for opening a lock.Physical TokensA physical token includes the access right. There are three different types: hand scanners 68, NFC tags 62, 74 and mobile telephones 61, for example smartphones 61; hand scanners 68 are used here, for example, exclusively by deliveryers 70 for delivering and picking up shipments (e.g. packages). Mobile telephones 61 are typically used by customers 63. NFC tags 62, 74 may be used by both delivery agents 70 and users 63. While delivery workers 70 who do not 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 books 70 with hand scanners 68 need individual access to parcel boxes 69, and therefore, in the system of FIG. 3, group lock access (GLA) tokens (for group access) and individual lock access (ILA) tokens (for individual access) are distinguished and used on the mobile telephone 61 of a user 63, the NFC tag 62 of a user 63 and the hand scanner 68 of a (parcel) user 70, ILA tokens are therefore used, while GLA tokens are used on the NFC tags 74 of a (letter) token 70.Key ServerThe key server 60 manages all access authorisations of the system 6. in particular, it maintains information about all users 63, all packet boxes 69 and the associated access rights. It therefore also generates the actual access permissions that can be used on the physical tokens.Cryptographic Keys of the LocksEach lock of a parcel box 69 has two keys which are used for distinguishing the types of tokens mentioned above.For ILA tokens: A lock has an individual key S 2. To open a lock, an ILA requires a valid access credential B. The key S 2 is used to verify the access credential B. Further, the key S 2 is used to validate a reject list and / or group key information. The key S 2 forms with a key S 1 a key pair which can be symmetrical or asymmetrical. In the case of a symmetric key S 1= S 2 for example, AES-128 is used as symmetric cryptographic primitive and for the encryption for example the so-called cipher block chaining (CBC) mode is used 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 can be transmitted, for example, as plain text. In the case of an asymmetric key pair, for example, a digital signature is provided for integrity checking.For GLA Tokens: A lock has a group key S T2. In order to open the lock, a GLA token requires a valid access authorisation B. The key S T2 is in this case again used to verify the access authorisation B. The key S T2 forms with a key S T1 a key pair which can be symmetrical or asymmetrical.The keys S 2 and S T2 are generated, for example, during the production process of the lock and are stored in the lock. Both keys must be adequately protected in the lock from unauthorized access. Both keys are transmitted to the key server 60 together with management data of the lock and a unique identifier (LockID) and stored there. The key server 60 then uses the keys S 1 and S T1 for cryptographic protection of the access authorisations-in order to allow verification of the validity of the access authorisations at the lock-and the key S 1 in addition to protection of the rejection list and the group key information.Cryptographic Keys on ILA TokensEach ILA token is equipped with a third key H 3 which, with a fourth key H 4 forms a symmetrical (i.e. H 3= H 4) or asymmetrical (i.e. H 3 ≠H 4) key pair (H 3, H 4). This key H 3 is used for authenticating the ILA token at the lock, to which the key H 4 is made available at least temporarily. The key server uses the key pair (H 3, H 4), in order to guarantee the access right to the lock by the ILA token. During the initialization of the ILA token, the key H 3 is installed and stored on the key serverThe key H 3 may also be issued for a group of ILA tokens. In this case, all ILA tokens of a group are then equipped with the same key H 3. On an ILA token, multiple keys may exist in parallel, that is, one or more group keys may be present on an ILA token in addition to one or more individual keys (although groups of tokens are referred to herein, they are nevertheless to be considered as individual access permissions that allow access to individual locks rather than groups of locks.)A group key may be installed on the device during or after the initialization process, but in any event the key must exist on the device prior to use.Cryptographic Keys on GLA TokensEach GLA token is equipped with a key H 3 which forms a symmetrical or asymmetrical key pair (H 3, H 4) with a key H 4 The key H 3 is used to gain access to a group of locks which at least temporarily have the key H 4. The key server uses the key pair (H 3, H 4) to assign access permissions for a group of locks to the GLA token.The key H 3 is installed on the device during the initialization process and stored on the key server.Structure of Access PermissionsAn access right may include one or more of the following access right parameters:• KeyID:ID of Access Right (Allocated by Key Server)• LockID:ID of the lock◯ For ILA Message a: The lock number and MAC address are transmitted by the Client to the key server.◯ For GLA To Box with ken: in this case, the LockID is the ID of the group to which the parcel of the specific lock belongs.• NotBeforeDa:Date "valid of" year / month / day• NotAfterDa:Date "valid to" year / month / day• StartTimeOfDa:Time from when the access authorization is valid (standard, for example, 00:00:00)• EndTimeOfDa:Time until when the access authorization is valid (standard, for example, 23:59:59)• MaxUs:Number of uses; Standard 0 means "unlimited"• Missions:Setting permission for safety-critical operations, for example whether the opening of the parcel compartment and / or the opening of the parcel compartment and the mailbox is permitted.An access right may be identified by a unique KeyID. The "LockID" describes which lock (or group of locks) the access authorisation is valid for. For example, a predefined number of bit locations of the LockID (e.g., four bits) may carry a code indicating whether it is an individual identifier or a group identifier. With such a code, the lock can identify which key it is to use for decryption: the individual key S 2 or one of group keys S T2. In this code, or in other bit positions of the LockID, it is also possible to code from which manufacturer the lock originatesIt may happen that a lock must contain several group keys if the parcel box is located in a zone representing an overlap of two delivery groups. This will be explained in more detail below.The two parameters "NotBeforeDa" and "NotAfterDa" define the period of validity of the access authorisation, with the accuracy of one day. "NotBeforeDa" defines the day of initial use and "NotAfterDa" specifies the last day in the period of validity. "StartTimeOfDa" further specifies the time from when the period of validity begins and "EndTimeOfDa" specifies when this ends. The accuracy is, for example, one second. However, other possible definitions of validity intervals are also conceivable, for example in the form of a pointer or index which points to individual entries of a multiplicity of predefined validity periods which are stored, for example, in each case in the key server and in the lock or can be calculated from the index according to a predefined rule. For example, in the case of access authorisations which are valid for a respective day, only the day of validity can be used as an access authorisation parameter, wherein this day is specified, for example, as an offset to a predefined reference day (e.g. the 1.1.2014), that is to say, for example, as "20", if the access authorisation is intended to be valid on the 21.1.2014. "MaxUs" defines the number of times the key can be used to open a lock. The value "0" specifies, for example, that the key may be used indefinitely in the period of time. "Transmissions" are encoded, for example by setting individual bits in a bit string, which may execute a token during safety-critical operations, as has already been listed above by way of example (a bit set to 1 then indicates, for example, the presence of the authorisation).The key server issues a lock access right B. Depending on the type of token, the server generates the value V as a result of cryptographic operations via the access authorisation B using the key S 1 or the key S T1. The cryptographic operations may, for example, denote formation of a MAC value over B with a symmetric key S 1 or formation of a digital signature over B using an asymmetric key S 1 to name just a few non-limiting examples.Structure of Reject ListKeyIDs can be locked to a lock by reject lists from key server 60. The list contains all KeyIDs of the access authorisations which have been cancelled by the lock for an associated period of the access authorisations. Access authorisations which are no longer valid because of their period of validity are removed from the list, for example, in order to keep them short and thus ensure a low storage requirement in the locks. It is not possible, for example, to undo a one-time initiated call-back of an access authorization. If an access authorisation has been cancelled, there is no longer a possibility of opening the lock with this access authorisation.The key server 60 generates the rejection information L (containing the rejection list) and a checking information V L, which is again based on, for example, cryptographic operations over L using the key S 1The rejection information L may include, for example, the identifier (e.g., LockID) of the lock to which the rejection list relates and a list of KeyIDs to be locked. A corresponding counter can then be carried in the lock in order to be able to check the validity of the current rejection information.Lock Opening with a Hand Scanner or a Mobile TelephoneA lock is opened after a token has authenticated itself by the transmission of a valid access authorisation. This process is illustrated in the flow chart 400 of FIG. 4.The token (hand scanner 68 or mobile telephone 61) has received the following data from the key server, for example: an access authorisation B and a first checking information V, a third key H3 and an authentication value A which comprises a combination of at least H4 and the KeyID of the access authorisation B encrypted with S 1. In the case of symmetric encryption, the initialization vector IV of a CBC mode of encryption may also have been received.The process 400 of opening a lock then proceeds as set forth below (see FIG. 4 ). In a step 401, a Bluetooth connection is first established between token 61, 68 and lock (of packet box 69), preferably using the lock's MAC address known to token 61, 68, in order to avoid Bluetooth pairing.In a step 402, the token 61, 68 authenticates itself to the lock based on the key H 3. For this purpose, at least the information A is transmitted to the lock, from which the lock can obtain the key H 4 with its key S 2. Based on H 3 and H 4 the token 61, 68 and the lock can then carry out 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 H 3 to a challenge obtained from the lock (and gfs. further information) and sends it as a response to the lock, which can again check the response on the basis of the key H 4 in order to determine the authenticity of the token 61, 68.After the token 61, 68 has been authenticated or in a process combined with this authentication, the token 61, 68 furthermore transmits the information B and V to the lock.The lock can then check the authenticity and integrity of B and V with respect to the key server 60, i.e. determine whether B and V originate from the key server and have not been changed, in a step 403. For this purpose, the lock uses the key S 2. Upon successful verification, the B access authorisation parameters are checked against reference information present in the lock to determine whether the lock can be opened due to B.In particular, depending on the presence of the respective access authorization parameters in the access authorization information, the following can be checked, wherein the sequence of the checks can be arbitrary and can already be aborted or jumped to step 404 in the event of an unsatisfaction of a condition, in order to save time and / or power:whether the KeyID (decrypted from A) corresponds to the KeyID of the access right.whether the access authorization is still valid in terms of time (by comparison with a clock of the lock).whether the access right is not in the reject list for the lock.whether the LockID of the access authorisation matches the LockID of the lock.What extent of access the "permit submissions".MaxUs is matched against the internal counter of the lock and the counter is incremented accordinglyIn step 404, a feedback to the token 61, 68 (e.g. OK, ERROR, ALERTING) then takes place and, if all checks carried out are positive, the preparation for the lock opening takes place.The key H 3 has been handed over to the token 61, 68, for example during an initialization phase (in particular in the case of the token 61, for example an initialization of an app on the mobile telephone 61), or has been transferred as a group key H 3 (in particular in the case of the token 68). The corresponding or identical key H 4 is transmitted to the lock in encrypted form As a result, the lock does not have to store all the keys H 4 from all the devices and can be used in an extremely flexible and offline manner. In addition, the KeyID of the access authorisation is encrypted together with the key H 4 The key of the token is thus bound to the current access authorisation of the lock. The challenge-response method is used to protect the protocol against so-called "replay attacks".Lock Opening with an NFC TagA lock is opened after a token 62, 74 has authenticated itself by the transmission of a valid access authorisation to the lock (a packet box 69).This process is illustrated in the flow diagram 500 of FIG. 5.The token 62, 74 again has, for example, the information B, V, A and H 3 and gfs. IV obtain and store them, wherein in the case of an ILA token V is based on cryptographic operations over at least B with the key S 1 and in the case of a GLA token V is based on cryptographic operations over at least B with the key S T1 Similarly in the case of an ILA token A is based on encryption of the combination of at least H 4 and the keyID of B with S 1 and in the case of a GLA token A is based on encryption of a combination of at least H 4 and the keyID of B with S T1. The key H 3( and its partner H 4) can be chosen differently for each token, for example, in the case of ILA tokens and GLA tokens. In contrast to the tokens 61, 68, the information B, V, A and H 3 gfs is longer-lived in the case of the tokens 62, 74, since the outlay for writing this information is complicated and is preferably carried out only once, in particular during the production of the tags 62, 74 or as part of the delivery or commissioning.Depending on the architecture of the token 62, 74, the third key H 3( which can also be referred to as a device key), can be stored in a memory of the token that is not accessible to the outside 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 reading device (e.g. an NFC reading device, in particular of the lock). B and V can be contained in a memory area which is, for example, only released for reading when a mutual authentication has taken place between the reader / lock and the token 62, 74.The process 500 of opening a lock then proceeds as shown in FIG. 5.In a step 501, the NFC communication between token 62, 74 and lock is initialized.In step 502, a mutual authentication between token 62, 74 and lock takes place based on the keys H 3 and H 4. For this purpose, the lock first reads out the information A from the token 62, 74, for example, and obtains the key H 4. from it by decryption using the key S 2 or the key S T2. Which key S 2 or S T2 the lock must use can recognize, for example, on the basis of the LockID, which is likewise read out from the token 62, 74, for example (for example as part of A or separately therefrom), for example on the basis of predefined bit positions which indicate whether it is an ILA token (>use of S 2 required) or a GLA token (->use of S T2 required). An initialization vector IV can also be read out of the token 62, 74, if necessary depending on the type of encryption, for example as part of A or separately therefrom. Based on H 3( Token) and H 4( Lock), an authentication protocol is then carried out, for example the DESFire authentication protocol or any other authentication protocol which can be based, for example, on a challenge-response method. In this case, it may also be sufficient, for example, for the lock to authenticate itself with respect to the token 62, 74, for example for a challenge supplied by the token to be converted using its key H 4 into a response which is checked counter to the token on the basis of H 3 in the token.In the case of successful authentication, the token 62, 74 can enable the lock (or its reading device) to read out the information B and V, for example.The authenticity and integrity of B and V are then checked in step 503 analogously to step 403 of FIG. 4, wherein V is checked either on the basis of S 2( for ILA tokens) or S T2( for GLA tokens). Which key S 2 / S T2 is to be used can be decided on the basis of the structure of the LockID contained in the token, as has already been explained.Also with regard to checking the access authorisation parameters contained in B, reference can be made to the description of step 403 of 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).The lock is opened if B and V have been found authentic and integer, the checking of the access authorisation parameters against their reference values present in the lock has run positively and the missions indicate that an opening of at least one door is permitted.Transmission of Reject ListWhen transmitting the rejection list, the token does not have to authenticate itself, for example. A replay attack cannot be performed due to the counter (counter) included in the reject list. The distribution of the rejection lists to the locks can preferably be carried out by the hand scanners 68 and the mobile telephone 61; however, GLA tokens 74 can also be used for this purpose, which are reprogrammed specifically for this case, so that they can contain and transmit rejection lists.The process 600 for transmitting the reject list using ILA tokens (e.g., hand held scanner 68, cellular telephone 61, and tag 74) 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 checking information V L, which is generated, for example, by carrying out cryptographic operations via at least L using S 1( ILA tokens) or S T1( GLA tokens).The process 600 then proceeds as follows. In step 601, after a Bluetooth or NFC connection is established, token 61, 68, 74 conveys rejection information L and validation feature V L. In step 602, the lock checks the authenticity of L using V L and the key S 2 or S T2 which in turn are selected using the structure of the LockID in L. Then, for example, the contents of L can be checked, i.e. e.g. whether the LockID matches the LockID of the lock, and / or whether the value Counter is greater than the value retained in the lock for the rejection lists. If so, the new L-reject list is accepted into the lock (by replacing the old one) and the value for the L-reject lists in the lock is set to the value of counter. In step 603, a feedback to the token (OK, ERROR, ALERTING) then takes place (step 603).The value Counter ensures that the reject list cannot be replaced by an older reject list. Since the reject list is complete when it is generated, the lock can replace all previous KeyIDs with the current KeyIDs. In this case, in particular KeyIDs of no longer valid access authorisations are removed from the rejection list in order to keep them small.Group Key UpdateThe key S 2, which is responsible for the individual access, remains constant, for example, during the complete life cycle of the lock However, the key S T2, which is responsible for the group access, may have to be exchanged one or more times (this may occur, for example, when a parcel box is moved into another delivery area). For this reason, the changeable key S T2 is protected according to the invention by the invariable-and therefore more secure-key S 2For example, hand scanner 68 and mobile telephone 61 should be able to exchange the key S T2( or, as the case may be, several keys S T2) present on the lock. For this purpose, the key server 60 generates group key information, which comprises, for example, one or more components of the following: a LockID, i.e. the ID of the lock to which the update relates, an update_counter as a unique counter for the update, and one or more entries (entries), i.e. the group key list with the tuple (GroupID, S T2).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) S T2 and respective new groupIDs with the individual key S 1 of the lock (or for example the entire group key information). Thus, the new key S T2 is not present in plain text on the hand scanner 68 or mobile telephone 61 and can only be decoded by the respective lock. In addition, the key server 60 also creates a validation value V W, which is generated, for example, by cryptographic operations over at least W using the first key S 1. The cryptographic operations can in turn represent, for example, a MAC function or a digital signature using S1.The transmission process 700 illustrated in FIG. 7 then proceeds as follows. In step 701, a token 68 transmits W and V W to the lock. In step 702, the evaluation of the checking information V W for establishing the authenticity and integrity of W and V W is then carried out using the key S 2. If the result is positive, the group key list can be decrypted with the key S 2 and further checks can be carried out as to whether this group key list can be accepted in the lock, for example on the basis of a check as to whether the LockID from the group key information (obtained by decrypting 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) S T2 and the respective GroupID are replaced with the new values from the group key list and the update_counter in the lock is replaced with the value of the update_counter from the group key information. In step 703, the feedback to the token (OK / NOK) is then carried out.The update_counter again prevents replay attacks in which the attacker could attempt to place 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 specific lock. A further important process step, which is not explicitly listed 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) has been stored in the lock. This information is necessary in order for the key server to be able to generate access authorisations for GLA tokens that can be used in the future.Order of OperationsFIG. 11 shows an example flow diagram 1100 illustrating the possible order of operations in a lock according to the invention. Which operations are generally to be carried out by the lock can be communicated to the lock by the token, for example by one or more commands. Thus, for example, it is possible to carry out a plurality of operations in a communication session, for example a group key update, installation of a new rejection list and checking of the access authorisation 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 W, L, V L, shown in FIG. 1 are then transmitted from the token to the lock.After the start 1101, either one or more group keys on the lock may be updated (step 1102), a new reject list installed in the lock (step 1103), token authentication (made from key H 4) (step 1104), or a firmware update of the lock software (step 1110) may be made. As shown in FIG. 11, some steps, e.g., steps 1102, 1103, and 1104, may be performed in series. It should be understood from FIG. 11 that each operation is basically optional, that is, for example, only step 1102, step 1104, and step 1109 may be executed, if so desired.After successful token authentication 1104, either the electronics can be reset (reset in step 1109), the status of the lock queried (step 1108), or a check of an obtained access authorization B can be made (step 1105). After both steps, a reset can optionally also be carried out (step 1109). If the access authorisation B authorisations, for example, to open one or more doors of the parcel box 69, this door(s) is / are opened (step 1106). Also after the status has been queried (step 1108), the door can optionally be opened-if the authorization is present (step 1106).As can be seen from FIG. 11, after the reset (step 1109) or the firmware update (step 1110), the door is not opened. Further, the installation of the reject list (step 1102) and the update of the one or more group keys (step 1102) always take place before the access authorisation check, since the reject list or the group key / s may be required in this check.In the following, for the exemplary embodiment of the access control system of FIG. 3, it is explained how the access authorisations and keys are assigned to the devices of the delivery agents 70 and users 63 and to the packet boxes 69Process Delivery by Hand Held ScannerThe allocation server 67 implements the so-called district cutting, i.e. dynamically sets delivery districts on the basis of the daily shipment volume and the delivery personnel available. It is assumed that this assignment is carried out dynamically, that is to say that no statement can be made beforehand about which packet boxes 69 will belong to which district.The master data of the packet boxes, which are described in more detail below and which comprise, inter alia, the access authorisations to the respective packet boxes and the key H3, and for example also the address data of the packet box users, are then distributed regionally in a plurality of intermediate steps, wherein the intermediate steps are irrelevant for the subsequent considerations. Finally, as a rule, one or possibly also several districts are assigned to a decentralised unit (e.g. a computer or server), from which the hand scanners 68 are "filled" with the master data (and the address data of the parcel box users) for a selected district. The shipment data (desired data) are likewise transferred from the decentralised unit to the hand scanner as part of the refueling.The assignment of the hand scanners to a county is effected dynamically and downstream of the county cutting.The above process can be summarized as follows: 1. delivery domains are defined (for example primarily on the basis of the delivery / pickup addresses of shipments, the shipment volume and the delivery personnel present), 2. master data of the parcel boxes assigned to the delivery domains (and address data of the parcel box users) are distributed to the decentralized units 3. delivery agents 70 log in to the decentralized unit with the hand scanner 68. delivery agent 70 fetches packages for its domain from 5. delivery agent 70 delivers the packages for the parcel boxes 69 in its domainIf the access authorization for a hand scanner 68 is established, for example 1 day is provided as a validity period. In addition, for example, a parameter is provided which limits the maximum number of uses of this access authorization.Access Permissions for Hand-held ScannersThe key server 60 generates access authorisations B for each lock (of a parcel box 69) together with respectively corresponding validation feature V. Each delivery agent 70 is intended to receive access authorisations B for those parcel boxes 69 (i.e. their locks) together with the validation features V to which it is intended to deliver on the day, that is to say those of its delivery district.FIG. 8 provides an overview of an example process 800 of delivery with access permissions. The procedure is as follows:In step 801, the key server 60 generates, for example, each day the access permissions B i( wherein the index i=1..N denotes the respective lock of a total of N locks), which are each validated with a corresponding lock key S 1,i( which in turn forms a symmetrical or asymmetrical key pair with a key S 2,i stored in the lock). For this purpose, pairs (B i, V i) are calculated, wherein B i is an access authorisation and V i is the already described associated first checking information, which is generated using the key S 1,i. In addition, the key server generates, for example, a device key H 4( which forms a symmetrical or asymmetrical key pair with a further key H 3 with which a hand scanner 68 can authenticate itself with respect to a lock of a parcel box 69, and encrypts this (and, for example, one or more further parameters, for example the KeyID) with the respective lock key S 1,i, in order to generate an authorization feature A i.All access permissions are transmitted from the key server 60 to the provisioning server 66, e.g., daily (e.g., according to the generation frequency of the key server 60) in step 802. In particular, the following master data are transmitted per lock: access authorization B i, validation V i, and authorization feature A i. Optionally, the LockID can also be contained therein. In the provisioning server, the master data can be enriched with further information, for example the MAC address of the lock, and / or an address information of the parcel box, and / or address information of the users of the respective parcel boxes, to name just a few examples. Such information may, however, also have already 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, via which the lock can be addressed directly, for example without the need for Bluetooth pairing. For reasons of clarity, FIG. 8 shows in step 802 only the transmission of the plurality of master datasets {B i, V i, A i} and the key H 3 to the provisioning server.In step 803, district cutting takes place in the allocation server 67.In step 804, each of the L remote units 71- 1 gets. 71-L all access permissions for the domains assigned to it on this day. This is symbolically represented in step 804 by the notation { B i, V i, A i}l wherein the index l runs from 1 to L and the notation { B i, V i, A i}l designates the master data of all parcel boxes in the district l (wherein again for reasons of clarity the additional master data elements LockID, address information and MAC address are not represented and it is assumed that each decentralized unit receives only the master data of the parcel boxes of a respective delivery district, which is however not obligatory). A decentralized unit then "tanks" one (or even more) hand scanners within a delivery district l with the master data {B i, V i, A i}l of the parcel boxes of this delivery district.A hand scanner 68- 2 (here, by way of example, it is a hand scanner which is assigned to the second decentralized unit 71- 2 and the delivery district l=2 thereof) receives, as part of the refueling, the master data {B i, V i, A i}2 of the parcel boxes for the district l=2 to which it was allocated (step 805). This can be effected, for example, via wired communication (e.g. via a docking station which is connected to the decentralised unit 71- 2 and into which the hand scanner 68- 2 is placed) and / or wireless communication (e.g. via WLAN or GRPS).In step 806, the hand scanner 68- 2-for opening an exemplarily picked parcel box 69- kof its district-establishes a Bluetooth connection with the lock with the aid of the MAC address of the lock of this parcel box 69- kand transmits the access authorisation B k, the validation information V k, the authorisation feature A k and further validation information to the lock as described with reference to FIG. 4 (step 806).In step 807, the lock validates the authorisation on the basis of V k and S 2,k( analogously to the description of FIG. 4 ) and opens when authorisation is correct. Finally, in step 808, a corresponding status message and, for example, the battery status is sent back to the hand-held scanner.As can be seen from the above explanations, the authentication of the hand scanner 68- 2 with respect to the lock of the parcel box 69- ktakes place with the aid of the key H 3. An individual device key H 3 is not assigned to the hand scanner 68- 2; instead, a group key H 3 is generated, all hand scanners 68 forming the group in question and using the same key H 3. As part of the refueling, the group key H 3 is transmitted to a hand-held scanner. An access authorization for this "group key" H 3 is then issued per lock, which is effectively valid for all hand scanners. The key H 3 is transmitted, for example, from the key server 60 to the provisioning server (step 802) and then to all decentralized units (step 804), preferably via secure connections, in order to prevent its spuding. For example, the transmission from the key server 60 to the provisioning server 66 and / or to the remote unit 71- 2 takes place in encrypted form by means of SSL / TLS. Likewise, the connection between decentralised unit 71-2 and hand scanner 68-2 should be secured accordingly during refueling.Locking of Hand-held ScannersThe access permissions with which the hand scanners 68 operate are each re-issued for one day, for example. If it is necessary to lock a hand scanner 68, for example, after loss of the device, a reject list must be created for each lock that the hand scanner 68 had access to. The rejection list would then have to be moved to the corresponding locks by means of some "token" and installed, which, however, means a considerable outlay.This problem is adequately solved by issuing the access authorisations B for a time window which is as narrow as possible (e.g. validity over time only 1 day) and / or for as few uses as possible (e.g. a maximum of 3 uses per day). Additionally or alternatively, the hand-held scanner software can restrict the use of access authorisations as much as possible, for example by offering the opening of a lock of a parcel box 69 only when a corresponding shipment is also present for this parcel box 69 (this can be achieved, for example, by matching the address data (e.g. zip code, street and house number, contained in coded form in the so-called "routing code") of shipments with the address data contained in the master data (which are coded, for example, in a similar form as in the case of the routing code) of parcel boxes 69 and / or the addresses (which are coded, for example, in a similar form as in the case of the routing code) of the users 63 of parcel boxes 69 (via which a parcel box 69 can then in turn be uniquely assigned). These addresses are transmitted in particular for this purpose on the hand-held scanner. In particular, it should also be prevented that a "blocked" hand scanner is connected to a decentralized unit and fuelled, in particular after loss, on subsequent days.This approach does not necessarily require dedicated locking of hand scanners 68 via rejection lists. In particular, the rejection lists used to disable other lost ILA and / or GLA tokens (e.g., mobile phones 61, delivery agent tags 74, and user tags 62) then remain smaller, which is advantageous because they must be stored by the lock. The advantages that rejection lists have for the use of mobile telephones 61 and possibly NFC tags 74, 62 (on which the access permissions have a longer temporal validity than the access permissions present on the hand scanners 68) do not exist with the hand scanners in the above-described procedureTransmission of Rejection ListsAs can be seen from Figure 11, the hand held scanner 68 does not need to authenticate itself to the lock upon transmission of a reject list (step 1103). Accordingly, the restrictions which occur when access authorisations are used (in particular with regard to the authentication) do not exist. The rejection lists can be enriched per lock as master data in the provisioning server 66, for example, and transmitted to the hand scanners 68 during refueling. This may result in a longer time for opening a lock, since, according to FIG. 11, the transmission of the rejection list to the lock (step 1103) takes place before the authorisation checking (step 1105). In addition, since the key server 60 does not have information about the successful delivery of a reject list to a lock, each time the lock is accessed, the current reject list would be distributed and transmitted.The following procedure appears to be advantageous: Locks are made by a main user, a co-user or in their order. The reject lists then generated by the key server 60 are then transmitted by the appropriate mobile telephone to the lock of the parcel box 69. The hand scanner 68 reports to the key server 60 the successful or unsuccessful transmission of the rejection list to the lock via the provision server 66.Keys for Delivery Forces with NFC TokensAs described in the section, there is a difference between tokens of the ILA (hand held scanner 68, mobile telephone 61, NFC token 62 from parcel box users 63) and the GLA type (NFC token 74 from delivery forces 70). For this distinction there are different reasons which are mentioned below: 1. NFC tokens cannot be provided with access authorisations without certain effort, 2. NFC tokens of delivery forces should be able to open all locks in a specific, in particular static, region. 3. NFC tokens are unable to store many access permissions.Requirement (2) illustrates that delivery forces 70 should be equipped with an NFC token 74 that is valid in a specific area. To this end, a group key S T1 is stored on the NFC token 74, which can open a group of locks (and thus packet boxes 69). As can be seen from requirement (3), it is not possible to equip delivery forces 70 with individual access authorisations for all locks in a specific area.For this reason, the lock is equipped with two or possibly more (symmetrical or asymmetrical) keys: a key S 2( "Individualschlüssel"with corresponding symmetrical or asymmetrical key S 1), in order to interact with ILA tokens, and one or more keys S T2( "group keys", with corresponding symmetrical or asymmetrical key S T1) for operations with the GLA tokens of the delivery forces 70. The main difference between these keys is that the first-mentioned key S 2 is unique for each lock and the further key S T2 is shared by a plurality of locks.While the unique key S 2 of the lock is applied during the production process-and in particular is invariable-the group key S T2 can be changed dynamically during the operating time of the lock (e.g. by a hand scanner 68).The replaceable keys S T2 for GLA tokens will be described below.The key server 60 generates access authorisation and provides it with validation information according to the corresponding group keys S T1 of a respective delivery area. The device keys are applied to the NFC token of the delivery personnel together with access authorisation.This is schematically illustrated in FIG. 9. Here, the NFC tokens (M pieces) 74- 1... 74-M to respective delivery forces (e.g., via a token production server 73) to lock in N areas (area 1... Region N) can be opened. Accordingly, the group keys S T2,1.. S T2,N are stored in the locks of the packet boxes of the respective areas 1... N via the server of the lock production 72 (or later by means of the update function for group keys), that is to say group keys S T2,1 are stored in the locks of the packet boxes of the area 1 etc.Assuming 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 permissions B j; validation feature V j of the delivery area j (formed by cryptographic operations via B j using the group key S T1,j); authentication value A j, which in turn comprises at least one combination of at least the key H 4,i and the keyID j encrypted with S T1,j and for example additionally comprises the lockID j encoding the group identifier of the area j. Now, in a delivery area j (j from 1 to N), each delivery force having access authority for the area j can open each lock with its NFC token.Delivery areas are static in nature. Here, Requirement (1) must be considered, which implies that it is technically and economically cumbersome to change (update) the access permissions too often. On the other hand, no access permissions should be used that are always valid, which represents an increased security risk. Therefore, it is reasonable to issue access permissions for an extended but limited period of time, e.g. several months or years. After the expiration of the validity period, all tokens must be reprogrammed to obtain new access permissions B j.Group KeysIn the system of FIG. 3, it can be provided, for example, that mail suppliers 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 suppliers at least temporarily (for example, as an alternative to hand scanners 68). It should be noted that delivery areas for delivery agents in ZB (Rule Delivery, Delivery Bases) and ZSPL (Compound Delivery, i.e. delivery of letters and packages) may overlap.Thus, there is a possibility that a parcel box is opened once with one day "belonging to a certain delivery area" and once with another day belonging to another delivery area.This is schematically illustrated in FIG. 10. A first parcel box 110 is assigned only to a first delivery district 11 (ZB), and a second delivery district 12 (ZSPL) is assigned to the second parcel box 120, while a third parcel box 130 is assigned to both the first delivery district 11 and the second delivery district 12.This problem can be solved in that such packet boxes located in an overlapping area (e.g. packet box 130 in FIG. 10 ) receive two group keys and can then grant access to both tags (possibly also more than two, but for example at most five).Each delivery area (group) has a GroupID (group identifier). The group keys S T2 are then stored in the lock together with corresponding GroupIDs:If the delivery base area ZB 11 has a GroupID GroupZB and the ZSPL 12 has a GroupID GroupZSPL, and S T2,ZB and S TZ,ZSPL which are respective group keys, then the packet box lock 110 has stored the tuple (GroupZB, S TZ,ZB) the packet box lock 120 has stored the tuple (GroupZSPL, S TZ,ZSPL) and the packet box lock 130 has stored both tuple (GroupZB, S T2,ZB) and (GroupZSPL, S T2,ZSPL). Each of the locks additionally also has a respective individual key S 2,i as has already been described above.During the authentication phase, a token transmits the LockID, which is also in the access authorisation for the lock. The LockID gives the lock an instruction (e.g. by encoding predetermined bit positions of the LockID) as to which key is to be used for decryption and validation. Either the LockID points to the individual key S 2 of the lock or to one of potentially several group keys S T2 in that the GroupID is correspondingly coded into the LockID.In the above example, a deliverer of ZB 11 may open the lock of the parcel box 130 by transmitting GroupZB as a part of the LockID. Likewise, a deliverer of ZSPL 12 may open the lock of parcel box 130 by communicating GroupZSPL as a part of LockID. The lock has both keys and can react accordingly.If a GLA token is lost, e.g. from the area ZB 11, only the locks of the packet boxes in the area ZB 11, in particular the packet boxes 110 and 130, need to get a corresponding reject list update. The locks of the packet boxes of ZSPL 12, on the other hand, do not have to be provided with a new reject list.Key H and Access Permissions of the Owner's NFC TokenIt has already been explained how the key server 60 generates the access permissions and keys for the hand scanners 68 and how these access permissions are transmitted to the hand scanners 68. The key server 60 also generates the keys and access authorisations for the user 63 of the packet box, in particular its owner. The user 63 of the packet box always has an NFC token 62, for example. For example, when ordering, the user 63 receives two NFC tokens 62 for his packet box 69.The opening of the lock of the parcel box 69 with an NFC token 62 then runs as follows. The key server 60 generates the access authorization B for the NFC token 62, which are each validated with a corresponding (lock-specific) key S 1. The key S 1 forms a symmetrical or asymmetrical key pair with a key S 2 stored in the lock. A pair (B,V) is calculated as already described several times, wherein B represents an access authorisation and V represents, for example, a MAC or a digital signature for authorisation B using the key S 1. An authentication feature A is also calculated, which comprises a combination of at least the key H 4 and the keyID encrypted with S 1 and, for example, additionally the lockID, wherein H 4 forms a symmetrical or asymmetrical key pair with a key H 3 and the key H 3 is stored in the token. KeyID is an identifier of the access authorisation and LockID encodes the individual identifier of the lock. The authorisation B and the features V and A and the key H 3 are transferred to a programming point. The programming point writes the data B, V, A, H 3 to the NFC token / tokens 62 of the user 63. To open the packet box 69, the NFC token 62 establishes a connection with the lock of the packet box 69, authorizes itself with respect to the lock and transmits the access authorisation and validation features (cf. the description of FIG. 5 ). The lock validates the authorisation with the aid of the validation features and opens it if authorisation is sufficient.Exemplary embodiments of the present invention are also to be disclosed:Embodiment 34: Method for generating access authorisation information (B, V) according to claim 30.Embodiment 35: The method of embodiment 34, wherein the key pair is an asymmetric key pair, wherein generating the first checking information (V) comprises generating a digital signature about the access authorisation parameters (B) using at least the first key of the key pairEmbodiment 36: The method of embodiment 34, wherein the key pair is a symmetric key pair, and wherein the first checking comprises performing the same cryptographic operations (CRYPT) as used in generating the first checking information (V) over the communicated access authorisation parameters (B) using at least the second key (S 2, S T2) of the key pair to obtain locally generated first checking information and comparing the communicated first checking information (V) with the locally generated first checking informationEmbodiment 37: The method of embodiment 36, wherein the cryptographic operations are to determine a message authentication code (MAC) as checking information (V).Embodiment 38: -Embodiment 39: -Exemplary embodiment 40: Method according to one of exemplary embodiments 34-37, wherein at least one second key (S T2) of a symmetrical or asymmetrical further group key pair, which is different from the second key (S 2) of the individual key pair and the second key (S T2) of the group key pair, is additionally stored in the access control device (4), said second key being stored in all access control devices of a further group of access control devices of the plurality of access control devices comprising the access control device (4) but containing at least one or more other access control devices in comparison with the group of access control devices, and wherein the second key (S 2, used during the first checking operation, S T2) of the key pair is either the second key (S 2) of the Individualschlüsselpaars the second key (S T2) of the group key pair or the second key (S T2) of the further group key pair.Exemplary embodiment 41: method according to one of exemplary embodiments 34-37 or 40, wherein it is not provided to change, delete or exchange the second key (S 2) of the individual key pair in the access control device (4), wherein it is provided, however, that the second key (S T2) of the group key pair can be changed or deleted or exchanged for another key.Embodiment 42: The method of any of Embodiments 34-37 or 40-41, further comprising:generating group key information (W) comprising at least one second key (S T2) of a new symmetric or asymmetric group key pair encrypted with the first key (S 1) of the individual key pair for the same or an at least partially different group of access control devices of the plurality of access control devices,outputting the group key information (W) for storage on the access proof device (3) configured to communicate the group key information at least to the access control device (4) to enable the access control device (4) to store the second key (S T2) of the new group key pair obtainable by decrypting the communicated encrypted second key (S T2) of the new group key pair using at least the second key (S 2) of the individual key pair in the access control device (4), so that the second key (S 2, used in the first checking, S T2) of the key pair is either the second key (S 2) of the individual key pair or the second key (S T2) of the new group key pair.Embodiment 43: The method of Embodiment 42, further comprising:generating second test information (V W), andoutputting the second checking information (V W) for storage on the access proof device (3), which is configured to communicate the second checking information (V W) at least to the access control device (4), and wherein the second key of the new group key pair, which key can be obtained by the decrypting, is stored in the access control device (4) only on the proviso that in a checking based at least on the communicated second checking information (V W), the second key (S 2) of the individual key pair and the communicated group key information (W), it is determined, the communicated second checking information (V 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 1) of the individual key pair.Exemplary embodiment 44: Method according to exemplary embodiment 43, wherein the group key information (W) additionally comprises a counter (update_counter), which is incremented with each new group key pair, and wherein the second key (S T2) of the new group key pair obtained by the decrypting is stored in the access control device (4) only on the additional 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 device (4), and wherein, during or after the storage of the second key (S T2) of the new group key pair in the access control device (4), the value of the counter in the access control device (4) is updated to the value of the counter (update_counter) comprised by the group key information.Exemplary embodiment 45: Method according to one of exemplary embodiments 43-44, wherein the group key information additionally comprises an individual identifier (LockID) of the access control device (4), and wherein the second key (S T2) of the new group key pair obtained by the decryption is stored in the access control device (4) only on the additional prerequisite that an individual identifier (LockID) of the access control device (4) stored in the access control device (4) matches the individual identifier (LockID) comprised in the group key information.Embodiment 46: The method according to any of embodiments 42-45, wherein the group key information additionally comprises a group identifier (GroupID) associated with the new group key pair, which is common to all access control devices of the group of access control devices 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 device (4).Exemplary embodiment 47: Method according to one of exemplary embodiments 34-37 or 40-46, wherein one of the access authorisation parameters (B) is an identifier (LockID) for only one access control device (4) or a group of access control devices, and wherein it is determined in the access control device (4) that the identifier authorizes access if the identifier (LockID) matches an individual identifier (LockID) of the access control device (4) stored in the access control device (4) and / or a group identifier (GroupID) for a group of access control devices to which the access control device (4) belongs.Exemplary embodiment 48: Method according to one of exemplary embodiments 34-37 or 40-46, wherein one of the access authorisation parameters is an identifier (LockID) only for the access control device (4) or for a group of access control devices which the access control device (4) contains, wherein it is determined in the access control device (4) that the identifier (LockID) authorizes access if the identifier matches an individual identifier (LockID) of the access control device (4) stored in the access control device (4) and / or a group identifier (GroupID) for a group of access control devices to which the access control device (4) belongs, wherein the first item of checking information (V) of access authorisation information, which has an identifier (LockID) only for the access control device (4) is generated by carrying out cryptographic operations on the access authorisation parameters (B) using at least the first key (S 1) of the individual key pair, and wherein the first checking information (V) of access authorisation information which has an identifier (LockID) for the group of access control devices is generated by carrying out cryptographic operations on the access authorisation parameters using at least the first key (S T1) of the group key pair.Exemplary embodiment 49: Method according to exemplary embodiment 48, wherein it is possible to identify in the access control device (4) on the basis of the identifier (LockID), in particular on the basis of a predefined format of the identifier, whether it is an identifier for only one access control device (4) or an identifier for a group of access control devices, such that either the second key (S 2) of the individual key pair or the second key (S T2) of the group key pair can be selected in each case in a suitable manner for the first checking.Embodiment 50: The method according to any one of embodiments 34-37 or 40-49, wherein one of the access authorisation parameters (B) is an identifier (KeyID) for the access authorisation information (B, V) or for the access authorisation verification device (3) which communicates the access authorisation information (B, V) to the access control device (4), and wherein it is determined that the identifier (KeyID) authorizes access if the identifier is not contained in a rejection list (RL) stored in the access control device (4).Embodiment 51: The method of any of Embodiments 34-37 or 40-50, further comprising:encrypting a fourth key (H 4) using at least the first key (S 1, S T1) of the key pair, wherein the fourth key (H 4) is usable when the access control device (4) is authenticated with respect to the access proof device (3) which communicates the access proof information to the access control device (4) or when checking the authenticity and / or integrity of information communicated at the access control device (4),generating information (A) comprising at least the encrypted fourth key (H 4) andoutputting the information (A) for storage on the access proof device (3) which is configured to communicate the information (A) at least to the access control device (4) in order to enable the latter to decrypt and use the encrypted fourth key using at least the second key (S 2, S T2) of the key pair.Embodiment 52: The method of any of Embodiments 34-37 or 40-50, further comprising:encrypting a combination of a fourth key (H 4) and an identifier (KeyID) for the access authorisation information (B, V) or for the access authorisation verification device (3) which communicates the access authorisation information (B, V) to the access control device (4) using at least the first key (S 1, S T1) of the key pair, wherein the fourth key (H 4) is authenticated by the access control device (4) with respect to an access authorisation verification device (3) which communicates the access authorisation information (B, V) to the access control device, or can be used when checking the authenticity and / or integrity of information communicated at the access control device (4),generating information (A) comprising at least the encrypted combination, andoutputting the information (A) for storage on the access proof device (3) which is configured to communicate the information (A) at least to the access control device (4) in order to enable the latter to decrypt the encrypted combination using at least the second key (S 2, S T2) of the key pair in order to obtain the fourth key (H 4) and the identifier, wherein the identifier (KeyID) additionally represents one of the access proof parameters (B), and wherein it is determined in the access control device (4) that the identifier (KeyID) contained in the communicated access proof information (B, V) authorizes access if the identifier (KeyID) contained in the communicated access proof information (B, v) corresponds to the identifier (KeyID) obtained by decrypting the encrypted combination.Embodiment 53: The method of any of Embodiments 34-37 or 40-50, further comprising:encrypting a combination of a fourth key (H) and an identifier (KeyID) for the access authorisation information (B, V) or for the access authorisation verification device (3) which communicates the access authorisation information (B, V) to the access control device (4) using at least the first key (S 1, S T1) of the key pair, wherein the fourth key (H 4) is usable when authenticating the access control device (4) with respect to an access authorisation verification device (3) which communicates the access authorisation information (B, V) to the access control device (4) or when checking the authenticity and / or integrity of information communicated at the access control device (4),generating information (A) comprising at least the encrypted combination, andoutputting the information (A) for storage on the access proof device (3) which is configured to communicate the information (A) at least to the access control device (4) in order to enable the latter to decrypt the encrypted combination using at least the second key (S 2, S T2) of the key pair in order to obtain the fourth key (H 4) and the identifier, wherein the identifier (KeyID) additionally represents one of the access proof parameters (B), and wherein it is determined in the access control device (4) that the identifier (KeyID) contained in the communicated access proof information (B, V) authorizes access if the identifier (KeyID) contained in the communicated access proof information (B, v) corresponds to the identifier (KeyID) obtained by decrypting the encrypted combination, and the identifier (KeyID) is not included in a rejection list (RL) stored in the access control device (4).Exemplary embodiment 54: Method according to one of exemplary embodiments 52-53, wherein the access authorisation information (B, V) communicated to the access control device (4) is stored in identical form on at least two access authorisation verification devices (3), wherein the identical access authorisation information (B, V) stored on the at least two access authorisation verification devices (3) each have the same identifier (KeyID) for the access authorisation information (B, V) and these access authorisation information (B, V) are each associated with the same fourth key (H 4).Exemplary embodiment 55: Method according to exemplary embodiment 54, wherein the access authorisation information (B, V) communicated to the access control device (4) has a limited temporal validity and / or has only a limited permissible number of access processes within its validity period and / or can be communicated from the access authorisation verification device (3) only to the access control device (4) or is made if it is determined at the access authorisation verification device (3) that there is a need for access to the access control device (4).Embodiment 56: The method of any of embodiments 51-55, wherein the fourth key (H 4) forms a symmetric or asymmetric key pair with a third key (H 3) the method further comprising:outputting the third key (H 3) to the access credential device (3) to enable the access credential device (3) to generate and communicate to the access control device (4) a third item of checking information (V') by performing cryptographic operations via a challenge (R) generated by the access device, the access credential parameters (B) and the first item of checking information (V) using at least the third key (H 3) wherein a further necessary condition for granting access is that a second checking, performed at the access control device, using at least the challenge (R), the communicated access credential parameters (B), the communicated first item of checking information (V) is, The communicated third checking information (V') and the fourth key (H 4), show that the communicated third checking information (V') has been generated by performing cryptographic operations on information corresponding to the challenge (R), the communicated access right parameters (B) and the communicated first checking information (V) using at least the third key (H 3).Exemplary embodiment 57: Method according to one of exemplary embodiments 51-55, wherein the access control device (4) can authenticate itself to the access proof device (3) using at least the fourth key (H 4) wherein the access proof information (B, V) is communicated from the access proof device (3) to the access control device (4) only when there is successful authentication.Embodiment 58: The method of any of Embodiments 50 and 53, further comprising:generating fourth checking information (V L) by performing cryptographic operations on rejection information (L) using at least the first key (S 1, S T1) of the key pair, wherein the rejection information (L) comprises at least one new rejection list (RL) with identifiers (KeyIDs) for access authorisation information (B, V) to be rejected or for access authorisation verification devices (3) from which access authorisation information (B, V) is to be rejected at the access control device (4), andoutputting the rejection information (L) and the fourth checking information (V L) for storage on the access proof device (3) which is configured to communicate the rejection information (L) and the fourth checking information (V L) at least to the access control device (4), wherein the communicated new rejection list (RL) is stored in the access control device (4) only on the proviso that a check based at least on the communicated fourth checking information (V L), the second key (S 2, S T2) of the key pair and the communicated rejection information (L) is detected, the communicated fourth checking information (V 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 1, S T1) of the key pair.Embodiment 59: The method according to embodiment 58, wherein the rejection information (L) additionally 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 device (4) only on the additional prerequisite 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 device (4), and wherein the value of the counter of the access control device (4) is updated to the value of the counter (counter) comprised by the rejection information (L) during or after the storage of the new rejection list (RL) in the access control device (4).Exemplary embodiment 60: Method according to one of exemplary embodiments 58-59, wherein the rejection information (L) additionally comprises an identifier (LockID) of only one access control device (4) or of a group of access control devices on which the new rejection list (RL) is to be stored, and wherein the new rejection list (RL) is stored in the access control device (4) only on the additional precondition that an individual identifier (LockID) of the access control device (4) stored in the access control device (4) or a group identifier (GroupID) for a group of access control devices containing the access control device (4) matches the identifier contained in the rejection information.Embodiment 61: -Embodiment 62: -Exemplary embodiment 63: Method according to one of exemplary embodiments 34-37 or 40-60, wherein one of the access authorisation parameters (B) specifies the extent to which, in particular to which openings of the access control device (4) or to which openings of a device controlled by the access control device (4), access is to be granted.Embodiment 64: A computer program comprising program instructions that cause a processor to execute and / or control the method according to one of the embodiments 34-37 or 40-63 when the computer program runs on the processor.Exemplary embodiment 65: Access authorisation generation device (2) set up for executing and / or controlling the method according to one of exemplary embodiments 34-37 or 40-63 or comprising respective means for executing and / or controlling the steps of the method according to one of exemplary embodiments 34-37 or 40-63.Embodiment 66: The method for detecting access authorisation according to claim 33.Embodiment 67: The method according to embodiment 66, wherein the access credential (B, V) is generated by an access credential generation device (2) and stored in the access credential device (3) before the access credential device (3) is first issued to a user of the access credential device (3).Exemplary embodiment 68: Method according to exemplary embodiment 67, wherein the access authorisation verification device (3) is a portable RFID or NFC unit, in particular an RFID or NFC tag.Exemplary embodiment 69: Method according to exemplary embodiment 66, wherein the access authorisation information (B, V) is generated by an access authorisation generation device (2) and communicated to the access authorisation verification device (3) via an at least partially wireless communication link, in particular a cellular mobile radio network.Embodiment 70: The method according to embodiment 69, wherein the access credential device (3) is a portable terminal configured for wireless communication, in particular a mobile phone.Embodiment 71: The method according to embodiment 66, wherein the access authorisation information (B, V) is generated by an access authorisation generation device (2), transmitted via a communication network to a computer and communicated under the control thereof to the access authorisation verification device (2).Embodiment 72 The method according to embodiment 71, wherein the access credential device (3) is a hand-held scanner.Exemplary embodiment 73: Method according to one of exemplary embodiments 66-72, wherein the communication of information from the access authorisation verification device (3) to the access control device (4) takes place wirelessly, in particular by means of RFID, NFC or Bluetooth communication.Embodiment 74: Method according to one of embodiments 66-73, wherein the key pair is an asymmetric key pair, wherein the first checking information (V) is generated as a digital signature about the access authorisation parameters (B) using at least the first key (S 1) of the key pair.Embodiment 75: The method according to any one of embodiments 66-73, wherein the key pair is a symmetric key pair, and wherein the first checking comprises performing the same cryptographic operations (CRYPT) as are used in generating the first checking information (V) over the communicated access authorisation parameters (B) using at least the second key (S 2, S T2) of the key pair to obtain locally generated first checking information and comparing the communicated first checking information (V) with the locally generated first checking information.Embodiment 76: The method of embodiment 75, wherein the cryptographic operations are used to determine a message authentication code (MAC) as checking information (V).Embodiment 77: -Embodiment 78: -Exemplary embodiment 79: Method according to one of exemplary embodiments 66-76, wherein at least one second key (S T2) of a symmetrical or asymmetrical further group key pair, which is different from the second key (S 2) of the individual key pair and the second key (S T2) of the group key pair, is additionally stored in the access control device (4), said second key being stored in all access control devices of a further group of access control devices of the plurality of access control devices comprising the access control device (4) but containing at least one or more other access control devices in comparison with the group of access control devices, and wherein the second key (S 2, used during the first checking operation, S T2) of the key pair is either the second key (S 2) of the Individualschlüsselpaars the second key (S T2) of the group key pair or the second key (S T2) of the further group key pair.Exemplary embodiment 80: method according to one of exemplary embodiments 66-76 or 79, wherein it is not provided to change, delete or exchange the second key (S 2) of the individual key pair in the access control device (4), but it is provided that the second key (S T2) of the group key pair can be changed or deleted or exchanged for another key.Embodiment 81: The method of any of Embodiments 66-76 or 79-80, further comprising:communicating group key information (W) comprising at least one second key (S T2) of a new symmetric or asymmetric group key pair encrypted with the first key (S 1) of the individual key pair for the same or an at least partially different group of access control devices of the plurality of access control devices to the access control device (4) in order to enable the access control device (4) to store the second key (S T2) of the new group key pair obtainable by decrypting the communicated encrypted second key (S T2) of the new group key pair using at least the second key (S 2) of the individual key pair in the access control device (4), so that the second key (S 2, S T2) of the key pair used in the first checking is either the second key (S 2) of the individual key pair or the second key (S T2) of the new group key pair.Embodiment 82: The method of Embodiment 81, further comprising:communicating second checking information (V W) to the access control device, wherein the second key of the new group key pair, which key can be obtained by decrypting, is stored in the access control device (4) only on the condition that a check is established based at least on the communicated second checking information (V W), the second key (S 2) of the individual key pair and the communicated group key information (W), the communicated second checking information (V 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 1) of the individual key pair.Exemplary embodiment 83: Method according to exemplary embodiment 82, wherein the group key information (W) additionally comprises a counter (update_counter), which is incremented with each new group key pair, and wherein the second key (S T2) of the new group key pair obtained by the decrypting is stored in the access control device (4) only on the additional 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 device (4), and wherein, during or after the storage of the second key (S T2) of the new group key pair in the access control device (4), the value of the counter in the access control device (4) is updated to the value of the counter (update_counter) comprised by the group key information.Exemplary embodiment 84: Method according to one of exemplary embodiments 82-83, wherein the group key information additionally comprises an individual identifier (LockID) of the access control device (4), and wherein the second key (S T2) of the new group key pair obtained by the decrypting is stored in the access control device (4) only on the additional prerequisite that an individual identifier (LockID) of the access control device (4) stored in the access control device (4) matches the individual identifier (LockID) comprised in the group key information.Embodiment 85: The method according to any of embodiments 81-84, wherein the group key information additionally comprises a group identifier (GroupID) associated with the new group key pair, which is common to all access control devices of the group of access control devices 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 device (4).Exemplary embodiment 86: Method according to one of exemplary embodiments 66-76 or 79-85, wherein one of the access authorisation parameters (B) is an identifier (LockID) for only one access control device (4) or a group of access control devices, and wherein it is determined in the access control device (4) that the identifier authorizes access if the identifier (LockID) matches an individual identifier (LockID) of the access control device (4) stored in the access control device (4) and / or a group identifier (GroupID) for a group of access control devices to which the access control device (4) belongs.Exemplary embodiment 87: Method according to one of exemplary embodiments 66-76 or 79-85, wherein one of the access authorisation parameters is an identifier (LockID) only for the access control device (4) or for a group of access control devices which the access control device (4) contains, wherein it is determined in the access control device (4) that the identifier (LockID) authorizes access if the identifier matches an individual identifier (LockID) of the access control device (4) stored in the access control device (4) and / or a group identifier (GroupID) for a group of access control devices to which the access control device (4) belongs, wherein the first item of checking information (V) of access authorisation information corresponds, which has an identifier (LockID) only for the access control device (4) is generated by carrying out cryptographic operations on the access authorisation parameters (B) using at least the first key (S 1) of the individual key pair, and wherein the first checking information (V) of access authorisation information which has an identifier (LockID) for the group of access control devices is generated by carrying out cryptographic operations on the access authorisation parameters using at least the first key (S T1) of the group key pair.Exemplary embodiment 88: Method according to exemplary embodiment 87, it being possible to identify in the access control device (4) on the basis of the identifier (LockID), in particular on the basis of a predefined format of the identifier, whether it is an identifier for only one access control device (4) or an identifier for a group of access control devices, such that either the second key (S 2) of the individual key pair or the second key (S T2) of the group key pair can be selected in each case in a suitable manner for the first checking.Embodiment 89: The method according to any one of embodiments 66-76 or 79-88, wherein one of the access authorisation parameters (B) is an identifier (KeyID) for the access authorisation information (B, V) or for the access authorisation verification device (3), and wherein it is determined that the identifier (KeyID) authorizes access if the identifier is not contained in a rejection list (RL) stored in the access control device (4).Embodiment 90: The method of any of Embodiments 66-76 or 79-89, further comprising:communicating information (A) comprising at least one fourth key (H 4) encrypted using at least the first key (S 1, S T1) of the key pair, which key is usable during authentication of the access control device (4) with respect to the access proof device (3), or during checking the authenticity and / or integrity of information communicated to the access control device (4), to the access control device (4) in order to enable said access control device to decrypt and use the encrypted fourth key using at least the second key (S 2, S T2) of the key pair.Embodiment 91: The method of any of Embodiments 66-76 or 79-89, further comprising:communicating information (A) which comprises at least one combination of a fourth key (H 4) and an identifier (KeyID) for the access authorisation information (B, V) or for the access authorisation verification device (3) encrypted using at least the first key (S 1, S T1) of the key pair, wherein the fourth key (H 4) is usable during authentication of the access control device (4) with respect to the access authorisation verification device (3) or during checking of the authenticity and / or integrity of information communicated to the access control device (4), to the access control device (4) in order to enable the latter, the encrypted combination to decrypt using at least the second key (S 2, S T2) of the key pair in order to obtain the fourth key (H 4) and the identifier, wherein the identifier (KeyID) additionally represents one of the access authorisation parameters (B), and wherein it is determined in the access control device (4) that the identifier (KeyID) contained in the communicated access authorisation information (B, V) authorizes access if the identifier (KeyID) contained in the communicated access authorisation information (B, V) matches the identifier (KeyID) obtained by decrypting the encrypted combination.Embodiment 92: The method of any of Embodiments 66-76 or 79-89, further comprising:communicating information (A) which comprises at least one combination of a fourth key (H 4) and an identifier (KeyID) for the access authorisation information (B, V) or for the access authorisation verification device (3) encrypted using at least the first key (S 1, S T1) of the key pair, wherein the fourth key (H 4) is usable during authentication of the access control device (4) with respect to the access authorisation verification device (3) or during checking of the authenticity and / or integrity of information communicated to the access control device (4), to the access control device (4) in order to enable the latter, the encrypted combination using at least the second key (S 2, S T2) of the key pair to decrypt the fourth key (H 4) and the identifier, wherein the identifier (KeyID) additionally represents one of the access authorisation parameters (B), and wherein it is determined in the access control device (4) that the identifier (KeyID) contained in the communicated access authorisation information (B, V) authorizes access if the identifier (KeyID) contained in the communicated access authorisation information (B, v) corresponds to the identifier (KeyID) obtained by decrypting the encrypted combination, and the identifier (KeyID) is not included in a rejection list (RL) stored in the access control device (4).Exemplary embodiment 93: Method according to one of exemplary embodiments 91-92, wherein the access authorisation information (B, V) communicated to the access control device (4) is stored in identical form on at least two access authorisation verification devices (3), wherein the identical access authorisation information (B, V) stored on the at least two access authorisation verification devices (3) each have the same identifier (KeyID) for the access authorisation information (B, V) and these access authorisation information (B, V) are each associated with the same fourth key (H 4).Exemplary embodiment 94: Method according to exemplary embodiment 93, wherein the access authorisation information (B, V) communicated to the access control device (4) has a limited temporal validity and / or has only a limited permissible number of access processes within its validity period and / or can be communicated from the access authorisation verification device (3) only to the access control device (4) or is made if it is determined at the access authorisation verification device (3) that there is a need for access to the access control device (4).Embodiment 95: The method of any of embodiments 90-94, wherein the fourth key (H 4) forms a symmetric or asymmetric key pair with a third key (H 3) the method further comprising:generating third checking information (V') by performing cryptographic operations on a challenge (R) generated by the access device, the access authorisation parameters (B) and the first checking information (V) using at least the third key (H 3),communicating the third checking information (V') to the access control device, wherein a further necessary condition for granting access is that a second checking, performed at the access control device, using at least the challenge (R), the communicated access authorisation parameters (B), the communicated first checking information (V), the communicated third checking information (V') and the fourth key (H 4), results in that the communicated third checking information (V') has been generated by performing cryptographic operations on information corresponding to the challenge (R), the communicated access authorisation parameters (B) and the communicated first checking information (V) using at least the third key (H 3).Exemplary embodiment 96: Method according to one of exemplary embodiments 90-94, wherein the access control device (4) can authenticate itself to the access proof device (3) using at least the fourth key (H 4) and wherein the access proof information (B, V) is communicated from the access proof device (3) to the access control device (4) only when there is successful authentication.Embodiment 97: The method of any of Embodiments 89 and 92, further comprising:generating fourth checking information (V L) by performing cryptographic operations on rejection information (L) using at least the first key (S 1, S T1) of the key pair, wherein the rejection information (L) comprises at least one new rejection list (RL) with identifiers (KeyIDs) for access authorisation information (B, V) to be rejected or for access authorisation verification devices (3) from which access authorisation information (B, V) is to be rejected at the access control device (4), andcommunicating rejection information (L) comprising at least one new rejection list (RL) with identifiers (KeyIDs) for access authorisation information (B, V) to be rejected or for access credential devices (3) from which access authorisation information (B, V) is to be rejected at the access control device (4) and fourth checking information (V L), generated by performing cryptographic operations on the rejection information (L) using at least the first key (S 1, S T1) of the key pair to the access control device, wherein the communicated new rejection list (RL) is stored in the access control device (4) only on condition, wherein, in a test based on at least the communicated fourth check information (V L), the second key (S 2, S T2) of the key pair and the communicated rejection information (L), it is determined that the communicated fourth check information (V L) has been generated by performing cryptographic operations on the rejection information corresponding to the communicated rejection information (L) using at least the first key (S 1, S T1) of the key pair.Embodiment 98: The method of embodiment 97, wherein the rejection information (L) additionally comprises a counter (counter) incremented with each new rejection list (RL), and wherein the new rejection list (RL) is stored in the access control device (4) only on the additional prerequisite 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 device (4), and wherein the value of the counter of the access control device (4) is updated to the value of the counter (counter) comprised by the rejection information (L) during or after the storage of the new rejection list (RL) in the access control device (4).Exemplary embodiment 99: Method according to one of exemplary embodiments 97-98, wherein the rejection information (L) additionally comprises an identifier (LockID) of only one access control device (4) or of a group of access control devices on which the new rejection list (RL) is to be stored, and wherein the new rejection list (RL) is stored in the access control device (4) only on the additional precondition that an individual identifier (LockID) of the access control device (4) stored in the access control device (4) or a group identifier (GroupID) for a group of access control devices containing the access control device (4) matches the identifier contained in the rejection information.Exemplary embodiment 100: Method according to one of exemplary embodiments 66-76 or 79-99, wherein one of the access authorisation parameters (B) specifies the extent to which access is to be granted, in particular to which openings of the access control device (4) or to which openings of a device controlled by the access control device (4).Embodiment 101: A computer program comprising program instructions that cause a processor to execute and / or control the method according to one of the embodiments 66-76 or 79-100, when the computer program runs on the processor.Exemplary embodiment 102: Access authorisation verification device (3) set up for executing and / or controlling the method according to one of exemplary embodiments 66-76 or 79-100, or comprising respective means for executing and / or controlling the steps of the method according to one of exemplary embodiments 66-76 or 79-100.The exemplary embodiments / exemplary embodiments of the present invention described in this specification are also to be understood as being disclosed in all combinations with one another. In particular, the description of a feature encompassed by an embodiment-unless explicitly explained to the contrary-should not be understood here as meaning that the feature is indispensable or essential for the function of the exemplary embodiment. The method steps can be implemented in various ways, thus an implementation in software (by program instructions), hardware or a combination of both is conceivable for implementing the method steps. Terms such as "comprising", "having", "including", "containing" and the like used in the claims do not exclude further elements or steps. The phrase "at least partially" includes both the case "partially" and the case "completely". The phrase "and / or" is to be understood to mean that both the alternative and the combination are to be disclosed, i.e., "A and / or B" means "(A) or (B) or (A and B)". A plurality of units, persons or the like in the context of this specification means a plurality of units, persons or the like. The use of the indefinite article does not exclude a plurality. A single device can carry out the functions of several units or devices mentioned in the patent claims. Reference numerals indicated in the claims should not be regarded as limitations of the means and steps used.

Claims

Method for access control, performed by an access control device (4), the method comprising - obtaining access authorisation information (B, V) communicated to the access control device (4) comprising at least one or more access authorisation parameters (B) and first checking information (V), - first checking, using at least the communicated access authorisation parameters (B), the communicated first checking information (V) and a second key (S 2, S T2) of a symmetric or asymmetric key pair stored in the access control device (4), whether the communicated first item of checking information (V) has been generated by carrying out cryptographic operations on the communicated access authorisation parameters (B) corresponding access authorisation parameters (B) using at least one first key (S 1, S T1) of the key pair, - deciding whether access is allowed, wherein necessary conditions for granting access are that the first checking delivers a positive result and it is determined that at least one predefined set of the communicated access authorisation parameters (B) respectively authorize access with respect to respective reference information present in the access control device (4) at least at the time of the first checking, wherein the access control device (4) represents an access control device (4) from a plurality of access control devices, wherein the access control device (4) stores a second key (S 2) of a symmetrical or asymmetrical individual key pair which is not stored in any of the other access control devices of the plurality of access control devices, wherein the access control device (4) stores, in addition to the second key (S 2) of the individual key pair, a second key (S T2) of a symmetrical or asymmetrical group key pair which is different from the latter and is stored in all access control devices of a group of access control devices of the plurality of access control devices comprising the access control device (4), and wherein the second key (S 2, used during the first checking, S T2) of the key pair is either the second key (S 2) of the individual key pair or the second key (S T2) of the group key pair.The method of claim 1, wherein the key pair is an asymmetric key pair, and wherein the first checking comprises checking the communicated first checking information (V) as a digital signature about the access authorisation parameters (B) using at least the second key of the key pair and the communicated access authorisation parameters (B).The method of claim 1, wherein the key pair is a symmetric key pair, and wherein the first checking comprises performing the cryptographic operations on the communicated access authorisation parameters (B) using at least the second key (S 2, S T2) of the key pair to obtain locally generated first checking information and comparing the communicated first checking information (V) with the locally generated first checking information.Method according to Claim 3, wherein the cryptographic operations are used for determining a message authentication code (MAC) as checking information (V).Method according to one of Claims 1 - 4, wherein at least one second key (S T2) of a symmetrical or asymmetrical further group key pair, which is different from the second key (S 2) of the individual key pair and the second key (S T2) of the group key pair, is additionally stored in the access control device (4), said second key being stored in all access control devices of a further group of access control devices of the plurality of access control devices comprising the access control device (4) but containing at least one or more other access control devices in comparison with the group of access control devices, and wherein the second key (S 2, used during the first checking operation, S T2) of the key pair is either the second key (S 2) of the Individualschlüsselpaars the second key (S T2) of the group key pair or the second key (S T2) of the further group key pair.Method according to one of claims 1 - 5, wherein it is not provided to change, delete or exchange the second key (S 2) of the individual key pair in the access control device (4), wherein it is provided, however, that the second key (S T2) of the group key pair can be changed or deleted or exchanged for another key.Method according to any of claims 1-6, further comprising: - obtaining group key information (W) communicated to the access control device (4) comprising at least one second key (S T2) encrypted with the first key (S 1) of the individual key pair of a new symmetric or asymmetric group key pair for the same or an at least partially different group of access control devices of the plurality of access control devices, - decrypting the communicated encrypted second key (S T2) of the new group key pair with the second key (S 2) of the Individualschlüsselpaars, and storing the second key (S T2) of the new group key pair obtained by the decryption in the access control device, so that the second key (S 2, S T2) of the key pair used in the first checking is at least one of the second key (S 2) of the individual key pair and the second key (S T2) of the new group key pair.Method according to claim 7, further comprising: - obtaining second checking information (V W), communicated to the access control device (4); and - storing the second key (S T2) of the new group key pair obtained by the decrypting in the access control device (4) only on the premise that a check based at least on the communicated second checking information (V W), the second key (S 2) of the individual key pair and the communicated group key information (W) is detected, the communicated second checking information (V 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 1) of the individual key pair.Method according to claim 8, wherein the group key information additionally comprises a counter (update_counter) which is incremented with each new group key pair, and wherein the second key (S T2) of the new group key pair obtained by the decrypting is stored in the access control device (4) only on the additional prerequisite 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 device (4), and wherein, during or after the storage of the second key (S T2) of the new group key pair in the access control device (4), the value of the counter in the access control device (4) is updated to the value of the counter (update_counter) comprised by the group key information.Method according to one of Claims 8 - 9, wherein the group key information additionally comprises an individual identifier (LockID) of the access control device (4), and wherein the second key (S T2) of the new group key pair obtained by the decrypting is stored in the access control device (4) only on the additional prerequisite that an individual identifier (LockID) of the access control device (4) stored in the access control device (4) matches the individual identifier (LockID) comprised in the group key information.Method according to any of claims 7-10, wherein the group key information additionally comprises a group identifier (GroupID) associated with the new group key pair, which is common to all access control devices of the group of access control devices 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 device (4).Method according to one of claims 1 - 11, wherein one of the communicated access authorisation parameters is an identifier (LockID) for only one access control device (4) or a group of access control devices, and wherein it is determined that the identifier authorizes access if the identifier (LockID) matches an individual identifier (LockID) of the access control device (4) stored in the access control device (4) and / or a group identifier (GroupID) for a group of access control devices to which the access control device (4) belongs.Method according to one of Claims 1 - 12, wherein one of the communicated access authorisation parameters is an identifier (LockID) for only one access control device (4) or for a group of access control devices, wherein it is established that the identifier (LockID) authorizes access if the identifier matches an individual identifier (LockID) of the access control device (4) stored in the access control device (4) and / or a group identifier (GroupID) for a group of access control devices to which the access control device (4) belongs, wherein the first item of checking information (V) of communicated access authorisation information which has an identifier (LockID) for only one access control device (4), by performing cryptographic operations on the access authorisation parameters (B) using at least one first key (S) of the individual key pair, and wherein the first checking information (V) of communicated access authorisation information which has an identifier (LockID) for a group of access control devices is generated by performing cryptographic operations on the access authorisation parameters using at least one first key (S T) of the group key pair.Method according to claim 13, wherein it is possible to identify in the access control device (4) on the basis of the identifier (LockID), in particular on the basis of a predefined format of the identifier, whether it is an identifier for only one access control device (4) or an identifier for a group of access control devices, such that either the second key (S 2) of the individual key pair or the second key (S T2) of the group key pair can be selected as appropriate for the first checking.Method according to one of claims 1 - 14, wherein one of the communicated access authorisation parameters (B) is an identifier (KeyID) for the access authorisation information (B, V) or for an access authorisation verification device (3) which communicates the access authorisation information (B, V) to the access control device (4), and wherein it is determined that the identifier (KeyID) authorizes access if the identifier is not contained in a rejection list (RL) stored in the access control device (4).Method according to one of Claims 1 - 14, further comprising: - obtaining information (A) communicated to the access control device (4) which comprises at least one fourth key (H 4) encrypted using at least the first key (S 1, S T1) of the key pair and usable during authentication of the access control device (4) with respect to an access credential device (3) which communicates the access credential to the access control device (4) or during checking the authenticity and / or integrity of information communicated to the access control device (4), and - decrypting the encrypted fourth key using at least the second key (S 2, S T2) of the key pair, to obtain the fourth key (H 4).Method according to one of Claims 1 - 14, further comprising: - obtaining information (A) communicated to the access control device (4) which comprises at least one combination of a fourth key (H 4) and an identifier (KeyID) for the access authorisation information (B, V) or for an access authorisation device (3) which communicates the access authorisation information (B, V) to the access control device (4) which combination is encrypted using at least the first key (S 1, S T)1 of the key pair, wherein the fourth key (H 4) is used during authentication of the access control device (4) with respect to an access authorisation device (3) which communicates the access authorisation information (B, v) to the access control device (4) or usable in checking authenticity and / or integrity of information communicated to the access control device (4), and - decrypting the encrypted combination using at least the second key (S 2, S T2) of the key pair to obtain the fourth key (H 4) and the identifier (KeyID), wherein the identifier (KeyID) additionally represents one of the communicated access authorisation parameters (B), and wherein it is determined that the identifier (KeyID) contained in the communicated access authorisation information (B, V) authorizes access if the identifier (KeyID) contained in the communicated access authorisation information (B, v) corresponds to the identifier (KeyID) obtained by decrypting the encrypted information.Method according to one of Claims 1 - 14, further comprising: - obtaining information (A) communicated to the access control device (4) which comprises at least one combination of a fourth key (H 4) and an identifier (KeyID) for the access authorisation information (B, V) or for an access authorisation device (3) which communicates the access authorisation information (B, V) to the access control device (4) which combination is encrypted using at least the first key (S 1, S T1) of the key pair, wherein the fourth key (H 4) is authenticated by the access control device (4) with respect to an access authorisation device (3) which communicates the access authorisation information (B, v) to the access control device (4) or usable in checking authenticity and / or integrity of information communicated to the access control device (4), and - decrypting the encrypted combination using at least the second key (S 2, S T2) of the key pair to obtain the fourth key (H 4) and the identifier (KeyID), wherein the identifier (KeyID) additionally represents one of the communicated access authorisation parameters (B), and wherein it is determined that the identifier (KeyID) contained in the communicated access authorisation information (B, V) authorizes access if the identifier (KeyID) contained in the communicated access authorisation information (B, v) corresponds to the identifier (KeyID) obtained by decrypting the encrypted information, and the identifier (KeyID) is not included in a rejection list (RL) stored in the access control device (4).Method according to one of Claims 17-18, wherein the access authorisation information (B, V) communicated to the access control device (4) is stored in identical form on at least two access authorisation verification devices (3), wherein the identical access authorisation information (B, V) stored on the at least two access authorisation verification devices (3) each have the same identifier (KeyID) for the access authorisation information (B, V) and these access authorisation information (B, V) are each associated with the same fourth key (H 4).Method according to claim 19, wherein the access authorisation information (B, V) communicated to the access control device (4) has a limited temporal validity and / or has only a limited permissible number of access processes within its validity period and / or can be communicated from the access authorisation verification device (3) only to the access control device (4) if it is determined at the access authorisation verification device (3) that there is a need for access to the access control device (4)Method according to any of claims 16-20, wherein the fourth key (H 4) forms a symmetric or asymmetric key pair with a third key (H 3) and wherein the communicated access authorisation information (B, V, V') further comprises third checking information (V'), the method further comprising: - second checking, using at least one challenge (R) generated by the access control device (4), the communicated access authorisation parameter (B), the communicated first checking information (V), the communicated third checking information (V') and the fourth key (H 4), whether the communicated third checking information (V') is obtained by performing cryptographic operations on information, which correspond to the generated challenge (R), the communicated access authorisation parameters (B) and the communicated first checking information (V) were generated using at least the third key (H 3) wherein a further necessary condition for granting access is that the second checking provides a positive result.Method according to one of claims 16 - 20, the method further comprising: - authenticating against an access credential device (3) containing the access credential (B, V) using at least the fourth key (H 4), wherein the access credential (B, V) is communicated from the access credential device (3) to the access control device (4) only upon successful authentication.Method according to one of claims 15 and 18, further comprising: - obtaining rejection information (L) communicated to the access control device (4) comprising at least one new rejection list (RL) with identifiers (KeyIDs) for access authorisation information (B, V) to be rejected or for access authorisation verification devices (3) from which access authorisation information (B, V) is to be rejected at the access control device (4) and fourth checking information (V L), and - storing the communicated new rejection list (RL) only on the premise that, in the case of at least one fourth checking information (V L), communicated, the second key (S 2, S T2) of the key pair and the communicated rejection information (L) based verification, it is determined that the communicated fourth verification information (V L) has been generated by performing cryptographic operations on the rejection information corresponding to the communicated rejection information (L) using at least the first key (S 1, S T1) of the key pair.Method according to claim 23, wherein the rejection information (L) additionally comprises a counter (counter) incremented with each new rejection list (RL), and wherein the new rejection list (RL) is stored in the access control device (4) only on the additional prerequisite 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 device (4), and wherein the value of the counter of the access control device (4) is updated to the value of the counter (counter) comprised by the rejection information (L) at or after the storage of the new rejection list (RL) in the access control device (4).Method according to one of Claims 23 - 24, wherein the rejection information (L) additionally comprises an identifier (LockID) of only one access control device (4) or a group of access control devices on which the new rejection list (RL) is to be stored, and wherein the new rejection list (RL) is stored in the access control device (4) only on the additional prerequisite that an individual identifier (LockID) of the access control device (4) stored in the access control device (4) or a group identifier (GroupID) for a group of access control devices containing the access control device (4) matches the identifier comprised in the rejection information.Method according to one of Claims 1 - 25, wherein one of the communicated access authorisation parameters (B) specifies the extent to which, in particular to which openings of the access control device (4) or of a device controlled by the access control device (4), access is to be granted.A computer program comprising program instructions that cause a processor to execute and / or control the method according to any one of claims 1 to 26 when the computer program runs on the processor.Access control device, configured for executing and / or controlling the method according to one of claims 1 - 26 or comprising respective means for executing and / or controlling the steps of the method according to one of claims 1 - 26.Use of an access credential device (3) for communicating access credential information to an access control device (4) according to claim 28.Method for generating access authorisation information (B, V), the method comprising - generating first checking information (V) by carrying out cryptographic operations over one or more access authorisation parameters (B) using at least one first key (S 1, S T1) of a symmetrical or asymmetrical key pair, - generating access authorisation information (B, V) comprising at least the one or more access authorisation parameters (B) and the first checking information (V), and - outputting the access authorisation information (B, V) for storage on an access authorisation verification device (3) which is configured to communicate the access authorisation information (B, V) to at least one access control device (4) in order to enable it to decide to, whether access can be granted on the basis of the communicated access authorisation information (B, V), wherein necessary conditions for granting access are that a first checking, using at least the communicated access authorisation parameters (B), of the communicated first checking information (V) and a second key (S 2, S T2) of the key pair stored in the access control device (4), whether the communicated first checking information (V) has been generated by carrying out cryptographic operations on the access authorisation parameters (B) corresponding to the communicated access authorisation parameters (B) using at least the first key (S 1, S T1) of the key pair delivers a positive result and is determined, at least one predefined set of the communicated access authorization parameters (B) with respect to respective reference information present in the access control device (4) at least at the time of the first checking, wherein the access control device (4) represents an access control device (4) from a plurality of access control devices, wherein the access control device (4) stores a second key (S 2) of a symmetrical or asymmetrical individual key pair, which is not stored in any of the other access control devices of the plurality of access control devices, wherein a second key (S T2) of a symmetrical or asymmetrical group key pair, which key differs therefrom, is stored in the access control device (4) in addition to the second key (S 2) of the individual key pair, An access control device of the plurality of access control devices comprising the access control device (4) is stored in all access control devices, and wherein the first key (S 1, S T1) of the key pair used in generating the first checking information is either a first key (S 1) of the individual key pair or a first key (S T1) of the group key pairA computer program comprising program instructions that cause a processor to execute and / or control the method according to claim 30 when the computer program runs on the processorAccess authorisation generating device (2) adapted to perform and / or control the method according to claim 30 or comprising respective means for performing and / or controlling the steps of the method according to claim 30.A method for detecting access authorisation performed by an access authorisation verification device (3), the method comprising: - communicating access authorisation information (B, V) comprising at least one or more access authorisation parameters (B) and first checking information (V) to an access control device (4) in order to enable the same to decide whether access is allowed on the basis of the communicated access authorisation information (B, V), wherein necessary conditions for granting access are that a first checking, using at least the communicated access authorisation parameters (B), the communicated first checking information (V) and a second key (S 2, S T2) of a symmetrical or asymmetrical key pair stored in the access control device (4), is performed, whether the communicated first item of checking information (V) has been generated by carrying out cryptographic operations on the communicated access authorisation parameters (B), supplies a positive result by carrying out corresponding access authorisation parameters (B) using at least one first key (S 1, S T1) of the key pair, and it is determined that at least one predefined set of the communicated access authorisation parameters (B) respectively authorizes access with respect to respective reference information present in the access control device (4) at least at the time of the first checking, wherein the access control device (4) represents an access control device (4) from a plurality of access control devices, wherein a second key (S 2) of a symmetrical or asymmetrical individual key pair is stored in the access control device (4), None of the other access control devices of the plurality of access control devices is stored in any of the other access control devices, wherein, in addition to the second key (S 2) of the individual key pair, a second key (S T2) of a symmetrical or asymmetrical group key pair different from the latter is stored in the access control device (4), said second key being stored in all access control devices of a group of access control devices of the plurality of access control devices comprising the access control device (4), and wherein the first key (S 1, used in generating the first checking information, S T1) of the key pair is either a first key (S 1) of the individual key pair or a first key (S T1) of the group key pair.A computer program comprising program instructions that cause a processor to execute and / or control the method according to claim 33, when the computer program runs on the processor.Access credential device (3) adapted to perform and / or control the method according to claim 33, or comprising respective means for performing and / or controlling the steps of the method according to claim 33.A system (1) comprising: - an access control device (4) according to claim 28, - an access authorisation generation device (2), in particular according to claim 32, and - an access authorisation verification device (3), in particular according to claim 35, wherein the access authorisation information (B, V) is generated by the access authorisation generation device (2) and communicated from the access authorisation verification device (3) to the access control device (4).

Images