EP3732843A1

EP3732843A1 - Systems and methods for providing authentication and/or authorization

Info

Publication number: EP3732843A1
Application number: EP17832245.9A
Authority: EP
Inventors: Kai Römer; Philipp Paul Spangenberg; Andreas Schmid; Maximilian WAHLER
Original assignee: Blueid GmbH
Current assignee: Blueid GmbH
Priority date: 2017-12-28
Filing date: 2017-12-28
Publication date: 2020-11-04
Also published as: WO2019129351A1

Abstract

The present invention relates to a system for providing authentication and/or authorization. The system comprises a central unit configured to generate and transmit a token that permits execution of a command on a secured object, a mobile unit configured to receive the token transmitted by the central unit and to transmit the token to the secured object, wherein the token comprises a public key of the mobile unit.

Description

Systems and Methods for Providing Authentication and/or Authorization

1. Technical Field

The present invention relates to systems and methods for providing authentication and/or authorization.

2. Technical Background

Besides common locking systems based on physical keys and corresponding locks electronic locking systems have been established in the past years. Nowadays, electronic devices like smartphones or radio keys are regularly utilized to unlock objects like cars, apartment doors or locks of all sorts and therefore oftentimes replace common locking systems.

Concerning common locking systems, the ownership of a physical key provides the right to unlock an object. In contrast, when using an electronic locking system, the right to unlock an object is provided by a predefined data structure stored on an electronic device, which therefore replaces the physical key of a common locking system. When using such an electronic device for unlocking an object, a user has to bring the electronic device in close proximity to the object. Then, the electronic device establishes a connection with the object and transmits the predefined data structure. Then, the object is able to determine that the electronic device is within a specific range and tries to authenticate the electronic device based on the transmitted predefined data structure. If the authentication is successful, an unlock routine is triggered to grant the user of the electronic device access to the object.

Therefore, electronic locking systems are often utilized in the area of car sharing services, holiday apartment rental services etc. A user of such a service or system requests an authorization by the corresponding service provider, e.g. via his

smartphone. Then, the service provider transmits a data structure to the smartphone which grants the user the permission to unlock the desired object (a car or an apartment). This avoids the cumbersome and time-consuming process of picking-up and returning a physical key. Thus, electronic locking systems are particularly useful if a plurality of users participate in such a system. In addition, an electronic locking system may also increase comfort for opening an individually owned car or apartment. Instead of having a physical key with them, owners of cars or apartments may use their smartphone for unlocking the car or apartment. If the smartphone gets lost or stolen, the operator of the locking system may electronically withdraw the authorization from the stolen or lost smartphone to unlock the car or apartment. Therefore, performing an expensive replacement of a door or car lock in the case of a lost or stolen smartphone becomes superfluous.

However, in contrast to the usage of common physical keys, security-sensitive data has to be transmitted between a plurality of components operated in an electronic locking system. For example, the electronic device has to transmit specific data to the object to be unlocked. For reasons of comfort, this transmission is commonly realized via a wireless communication channel. Furthermore, in electronic locking systems, the electronic device has to be configured to be able to act as a key. During the process of configuration, specific security-sensitive configuration data has to be transmitted to the electronic device. This data is oftentimes communicated through the internet or other public networks to the electronic device.

Accordingly, a hacker or an eavesdropper is able to intercept the communicated data and may manipulate it in order to gain unauthorized access to the object. Therefore, to minimize the risk of an unauthorized access, it is necessaiy to ensure that all components involved in the electronic locking system are highly secured, that they can validate the identity of each other and that the communicated security-sensitive data is protected by secure cryptographic mechanisms.

However, applying cryptographic mechanisms in the known ways may result in undesired overhead concerning the communication between the involved components. In addition, the cryptographic mechanisms may slow down the process of unlocking an object because a plurality of computational-intensive ciyptographic algorithms have to be executed by each of the involved component. This may result in unacceptably long time spans for unlocking an object which significantly reduces the user experience.

Moreover, the flexibility of electronic locking systems may suffer when applying cryptographic mechanisms. When, for example, the data to be communicated is encrypted, it is difficult to provide a user with the possibility to retrieve information from it or to add further user-defined information to the data.

Therefore, known systems have to make a trade-off between security, flexibility and efficiency to be able to satisfy at least in part the user demands made on electronic locking systems. In other words, when security is increased, flexibility and efficiency suffer. In contrast, when the level of flexibility and efficiency is increased, security suffers.

It is for example known from US 4,405,829 to use a private-public key pair of an asymmetric cryptosystem, generated based on the Rivest, Shamir und Adleman (RSA) cryptosystem, for transmitting data between two entities in a secure manner without the need to exchange a symmetric key over a secured communication channel before the secured communication can be performed. This is because the public key of a private-public key pair can be securely communicated between two entities in an unsecure communication channel because it is only required to encrypt data. For the process of decryption, the private key of the key pair is required which has not to be communicated, but only has to be securely stored at the receiver of the encrypted data. Because the public key of an asymmetric cryptosystem can be transmitted in an unsecure communication channel, key rotation is easy to realize. If a new key pair is generated, the public key can be simply transmitted to the participating entities via any unsecure communication channel.

However, asymmetric cryptosystems are less efficient compared to so-called symmetric cryptosystems like the Advanced Encryption System (AES) as disclosed in Joan Daemen, Vincent Rijmen:“The Design of Rijndael. AES: The Advanced Encryption Standard”. Springer, Berlin u. a. 2002, ISBN 3-540-42580-2. Due to the underlying mathematical methods of an asymmetric cryptosystem, significantly more time is required for enciypting and deciypting the data intended to be securely exchanged between the participating entities. Therefore, an asymmetric ciyptosystem is less practical for communicating encrypted data if the time for enciypting and deciypting the data has to be low.

Therefore, commonly, when the time for encryption and decryption shall be kept low, symmetric cryptosystems like the aforementioned AES are commonly utilized. However, symmetric cryptosystems require that a key is securely synchronized between the participating entities. This makes a symmetric cryptosystem rather inflexible, particularly in respect to key rotation. In more detail, when a new key shall be used for further secured communications (e.g. because a currently used key is expired), the new key has to be synchronized between the participating entities via a non-public tap-proof communication channel which is difficult to establish, in particular when a plurality of different devices is involved.

Besides the secure communication of data, it is oftentimes required to ensure that an entity is the entity it pretends to be. To do so, digital certificates are used. A prominent certificate system is the so-called X.509 system. An X.509 certificate comprises a public key and an identity, and is commonly signed by a trusted authority. When a certificate is signed, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key. However, the usage of X.509 certificates requires the operation of or at least the cooperation with a trusted authority.

Furthermore, when a certificate is renewed due to expiration, it has to be renewed on any participating device. In addition, the validation of an identity requires

communication with the trusted authority which produces undesired communication overhead.

To mitigate the above-mentioned drawbacks of symmetric and asymmetric

cryptosystems, they are usually utilized in a combined manner. Then, as first step, public keys generated according to an asymmetric ciypto system are exchanged between the participating entities. The public keys are then used to encrypt and synchronize a symmetric key between the entities. The symmetric key is then used for encrypting and deciypting the actual security-sensitive data, allowing the

communication of the security-sensitive data in an unsecure communication channel. To avoid the usage of digital certificates, the public keys used by the entities can be securely distributed among the participating devices and can then be used to validate the identity of a communication partner without being signed by an authority.

However, as can be seen, to mitigate the drawbacks, a plurality of different systems and methods have to be operated in a nested or composed manner. Currently known authorization and/or authentication systems are therefore difficult to implement and require the execution of a plurality of computational-intensive algorithms for transmitting data in a secured manner and to validate the identity of the individual participating entities. As a result, flexibility suffers and establishing an infrastructure for secure communication and conducting secure communication, including identity validation, requires a lot of time. Furthermore, revoking already granted authorizations and restoring lost data structures may be difficult. Therefore, known systems are inappropriate for scenarios in which a plurality of communication entities may dynamically join the system. Moreover, such a system is even more inappropriate when only a short amount of time shall be used for performing a secure communication of security-sensitive data from one entity to another by at the same time verifying the identity of the participating entities.

EP l 910 134 Bi discloses an identification and/or locking system for identifying and/or unblocking a technical system comprising a central computing unit operable to generate and transmit a signal, at least one mobile transceiver unit operable to receive, store and modify the signal transmitted from the central computing unit and to retransmit wirelessly the modified signal, at least one control receiving unit operable to receive wirelessly the signal transmitted from the mobile transceiver unit and to execute at least one control function based thereon, wherein the signal comprises digital data operable to trigger the execution of the control function.

Therefore, there is a need to improve known systems for providing authorization and/ or authentication.

3. Summary of the Invention

These and other problems are at least in part solved by a system for providing authentication and/or authorization. In the embodiment of claim 1, the system comprises a central unit configured to generate and transmit a token that permits execution of a command by a secured object, and a mobile unit configured to receive the token transmitted by the central unit and to transmit the token to the secured object, wherein the token comprises a public key of the mobile unit.

This system architecture may provide a secure, efficient and at the same time a flexible way to manage authentication and/or authorization of a plurality of users to execute a command on a plurality of secured objects. Accordingly, the central unit may be responsible for generating tokens that may then be used by mobile units, to execute a specific command on a secured object. The command may be suitable for triggering an unlock routine on the secured object so that the user of the electronic unit may gain access to the secured object. This may comprise unlocking a door lock or any other routine suitable for unlocking the secured object.

The secured object may be an individually owned car, a car of a car sharing service, an autonomously driving car, a drone, an airplane, an individually owned apartment, a rental holiday apartment, a protected computer system or any other electronic device. Moreover, the secured object may be a lock, e.g. comprising an electronic control unit configured for unlocking the lock. Accordingly, such a lock may be installed in any kind of object.

The central unit may be a server, a computer or a computer center and may be implemented in software, in hardware or in a combination of soft- and hardware. It may be connected to a network. It may provide a user of the electronic unit to request permission to execute a command on a specific secured object. Then, the central unit may generate a corresponding token and transmit it to the electronic unit. The transmission may be performed on any suitable communication channel. It may not be required to use a secured non-public communication channel.

To generate a token, the central unit may comprise all information required for generating a token. The token may be considered as a ticket that grants access to a secured object. Therefore, the token may constitute an authorization for the user of the mobile unit that receives the token to gain access to a corresponding secured object. Thus, the token combined with the mobile unit may be considered as a key usable for getting access to the secured object. To transmit a generated token, the central unit may use the aforementioned network as a communication channel.

The transmitted token may be received by a mobile unit, e.g. via the aforementioned network. However, any other communication channel may be suitable for transmitting a generated token from the central unit to a mobile unit. Such a mobile unit may for example be a smartphone or any other portable electronic device. Furthermore, the mobile unit may be a vehicle like a drone, a car, an autonomously driving car, a robot or an autonomously acting craft. In this respect, the functionality as described herein with respect to the mobile unit may be directly implemented in one of the aforementioned vehicles, e.g. by means of an electronic device included in the vehicle. It is also possible that such a vehicle may cariy an electronic device that may act as the mobile unit. In this respect, the electronic device may be attached to the chassis and/or to the housing of the vehicle.

The token may comprise information that the user of the mobile unit may be authorized to access the secured object. Besides said information, the token may comprise a public key of a mobile unit intended for receiving the token. Including the public key in the token may provide an efficient way for establishing a secure communication channel between the secured object and the mobile unit when the token has been transmitted to the secured object. In more detail, when the mobile unit transmits the token to the secured object in order to get permission to execute a command on the secured object, no further communication step may be required to transmit the public key to the secured object. Including the public key in the token may reduce communication overhead because a second communication step for

transmitting the public key separately may be omitted. The public key may enable the secured object to determine the identity of the mobile unit. Furthermore, the public key may enable the secured object to use a plurality of routines for verifying the identity of the mobile unit without any extra communication.

Furthermore, including the public key in the token, may relieve the secured object from the burden of storing all the public keys of the electronic units. Thus, if a new secured objected is added to the system, the initialization process of the newly added secured object may be simplified because the public keys of the users or electronic units may be transmitted to the secured object on demand, and not all at once during the process of initialization.

In another aspect, the token may further comprise a signature based on a private key of the central unit usable for checking the integrity of the token. In addition, the secured object may be configured to perform an integrity check based on the signature and/or may be further configured to deny execution of the command if the integrity check is not successful. The signature may be based on a cryptographic signature system and/or may cover at least a part of the token. Furthermore, a parser of the secured object may only parse the token after a successfully validation of the signature. A signature, e.g. a digital signature, included in the token may enable the secured object to verify that the received token has not been manipulated or corrupted during transmission. Such a signature may be based on a ciyptographic signature system, wherein such a signature is able to cover the complete content of the token or at least a part of it, including the public key. Therefore, the signature may enable verification of the correct transmission of the token content and of the public key included in the token. This may allow a transmission of the token from the central unit to the mobile unit and/or from the mobile unit to the secured object without being encrypted in a public non-secured communication channel by at the same time not negatively affecting the security of the system.

Moreover, the signature may prevent any malicious third-party, e.g. a hacker, from faking tokens and therefore from executing the command on the secured object in an unauthorized manner, e.g. executing an unlock command to gain access to the secured object.

In addition, the signature may allow verification that a token has been generated by an authorized central unit and not by any unauthorized unit, e.g. operated by a malicious third-party.

In another aspect, the mobile unit is further configured to sign the token with a private key of the mobile unit.

Besides the above-described signature, the mobile unit may use a private key that may be part of a private-public key pair of the mobile unit to sign the token, including the signature.

This further signature may allow the secured object to verify that the token has been received from a mobile unit that is authorized to transmit tokens to the secured object. This verification may be performed based on the public key included in the token. This public key cannot be corrupted or modified because it is protected by the signature as outlined above.

In another aspect, signing the token with the private key of the mobile unit may be based on a first nonce transmitted from the mobile unit to the secured object and on a second nonce transmitted from the secured object to the mobile unit. To improve the cryptographical strength, one or more nonces may be transmitted between the mobile unit and the secured object. In cryptography, a nonce is an arbitraiy number that may only be used once. A nonce may be a random or pseudo- random number and may be used to ensure that previous communications between two or more entities cannot be reused in replay attacks.

In another aspect, the token may comprise the command, wherein the command may be an unlock command configured for unlocking the secured object.

To increase flexibility, the command may be specified within the token. This may allow the system to support a plurality of different commands on the secured object. For example, the command may be a command for unlocking the secured object. In respect to cars, the command may further be suitable for starting the engine of the car.

However, the command may further be any kind of command useable for controlling the secured object. In addition, a plurality of commands may be included in the token.

In yet another aspect, the token may further comprise a mobile unit identity usable for identifying the mobile unit, and/or a secured object identity usable for identifying the secured object, and/or a validity time indicating a time span in which the authorization to execute the command on the secured object is valid, and/or a token identity usable for identifying the token.

The mobile unit identity may be used to ensure that the token has been received by the desired mobile unit. Furthermore, the mobile unit identity may enable the secured object to determine from which mobile unit it has received the token.

The validity time may allow the system to define a period in which the mobile unit is authorized to execute the command on the secured object. Thus, the system may be able to avoid conflicts between a plurality of mobile units that have requested a token for being authorized to execute one or more commands on the same secured object.

In addition, the token may comprise a token identity that may allow to identify a token among a plurality of tokens. In a further aspect, the secured object may further be configured to receive a revocation list, wherein the revocation list may comprise a mobile unit identity and/or a token identity.

To provide the possibility to revoke an already granted authorization, the system may support to transmit a revocation list to the secured object. The revocation list may comprise the identity of one or more mobile units. The mobile unit identity may be used by the secured object to withdraw an authorization granted in terms of one more tokens issued for a specific mobile unit. Thus, a plurality of tokens issued for said specific mobile unit may be revoked at once.

In addition, to provide flexibility, the revocation list may also comprise one or more token identities. Then, only the specified token may be revoked and not all tokens generated for a specific mobile unit.

Both aspects, combined or individual, may enable the system to provide a flexible and efficient way to revoke one or all tokens generated for one or more mobile units.

In another aspect, the revocation list may be included in the token received from the mobile unit and/or may be included in a message received from a gateway.

The revocation list may be included in a token. This provides an efficient mechanism to provide the secured object with the revocation list without requiring any additional communication besides the token transmission. When the token is transmitted to the secured object, e.g. when the corresponding mobile unit transmits the token to the secured object in order to execute a command, the secured object may automatically be supplied with the revocation list.

However, it may also be possible to transmit the revocation list outside the token to a secured object. This may be implemented in a direct communication channel between the central unit and the secured object which may utilize a gateway like an internet router etc. Such a direct gateway-based communication channel may ensure a fast delivery of the revocation list to the intended secured object.

In a further aspect, the secured object may further be configured to deny the execution of a command included in a second token if a mobile unit identity in the revocation list corresponds to a mobile unit identity included in the second token and/or if a token identity in the revocation list corresponds to a token identity included in the second token.

The mobile unit identity and/or the token identity in the revocation list may enable the secured object to withdraw an authorization to execute one or more commands on the secured object granted in terms of one more tokens.

In another aspect, the mobile unit may further be configured to receive a revocation confirmation from the secured object if the token comprises the revocations list and if the token is successfully transmitted to the secured object and/or the mobile unit may be configured to transmit the revocation confirmation to the central unit.

To inform the central unit about a successful transmission of the revocation list to the secured object, the secured object may transmit a revocation confirmation, e.g. in terms of a message, to the central unit. This may be done by transmitting the revocation confirmation to the mobile unit. Then, the mobile unit may transmit the revocation confirmation to the central unit, e.g. when it has established a communication channel to the central unit to receive further tokens.

It may also be possible to transmit the revocation confirmation from the secured object to the central unit directly, e.g. on the same communication channel used for transmitting the revocation list from the central unit to the secured object, as for example outlined above in respect to the gateway.

In another aspect, the secured object may further be configured to sign the revocation confirmation with a private key of the secured object and/or the secured object may further be configured to transmit a public key of the secured object to the central unit, wherein the public key may be usable by the central unit to verify the integrity of the revocation conformation.

Signing the revocation confirmation may provide manipulation protection. Signing the revocation confirmation with the private key of a public-private key pair of the secured object may enable the central unit to perform an integrity check based on the corresponding public key. To do so, the secured object may transmit its public key to the central unit which may be configured to store the public keys of all participating secured objects.

In another aspect, the secured object may further be configured to refrain from transmitting revocation confirmations to the mobile unit if the secured object was instructed accordingly by the mobile unit.

The secured object may not be informed by the central unit whether the central unit may have received the revocation confirmation. However, the central unit may inform the mobile unit accordingly such that the mobile unit may inform the secured object to refrain from further transmitting revocation confirmations concerning specific tokens. This may avoid unnecessaiy communications of revocation confirmations and thus may increase efficiency of the system.

In another aspect, the central unit may further be configured to encrypt the token at least in part.

As outlined above, it is not necessary to encrypt the token in respect to security.

However, it might be desirable to protect at least a part of the data of a token due to privacy reasons so that hackers and/or eavesdropper may not be able to read the encrypted data of the token.

In another aspect, the present invention provides a central unit that may be configured to receive a public key of a mobile unit, to receive a request to generate a token, to generate the token comprising the public key of the mobile unit and to transmit the token.

The central unit as described here may be used in conjunction with the above-described system. The central unit may comprise a database for storing information and an interface for receiving a public key of a mobile unit. The public key may be

communicated to the central unit via any suitable communication channel, e.g. the internet. The public key may be transmitted to the central unit in an unprotected manner. The public key along with other information relating to the mobile unit may be stored in the database. The other information may for example comprise an identity of the mobile unit. The central unit may receive a request to generate a token. The request may define for which secured object an authorization shall be granted. It is also possible that the request may specify that a token may be generated that grants authorization for a plurality of secured objects. In response to the request, the central unit may generate the token by including the required payload (e.g. the identity of one or more secured objects) as well as the public key of the mobile unit to which authorization shall be granted. After a successful token generation, the central unit may transmit the generated token to the mobile unit to which the public key in the token belongs to.

In yet another aspect, the central unit may further be configured to generate a signature based on a private key of the central unit, wherein the signature may be usable for checking the integrity of the token.

The signature based on the private key of the central unit may provide manipulation detection concerning the token and its content. The manipulation detection may be performed by the secured object that receives the token and may act as an integrity check. The integrity check may ensure that the content of the token has not been modified during or after transmission. In particular, due to the signature, it may not be possible to modify the token by the user of the mobile unit. In addition, a hack or an eavesdropper may not compromise the content of the token during transmission.

Furthermore, the signature may be able to perform an identity check usable for checking the identity of the central unit.

The signature may allow a transmission of the token in an unenciypted manner which may increases efficiency because no unnecessaiy ciyptographic method has to be applied to the token. In addition, the unencrypted token may enable the mobile unit to read the content of the token which may enable a further check that the correct token has been transmitted to the correct mobile unit. In addition, the signature may increase security.

In yet another aspect, the central unit may further be configured to insert a command into the token based on the request. The command may be an unlock command usable for unlocking a secured object.

During generation of the token, the central unit may insert one or more commands into the token. The one or more commands may be specified in the request directed to the central unit. As a result, the token may provide authorization to the mobile unit intended for reception of the token to execute the one or more commands on one or more secured objects. For example, the one or more commands may grant

authorization to a user of a mobile unit to execute an unlock routine on the secured object in order to gain access to it and/or to unlock it.

In a further aspect, the request may be received from the mobile unit and/or from a third-party unit.

Receiving the request directly from the mobile unit may enable the central unit to grant an authorization to the mobile unit. However, it may also be possible that any third- party unit, e.g. a computer, a service, a cloud service, an identity management system etc. may transmit the request to the central unit. This may increase flexibility of the central unit by allowing different units of different owners to request tokens for one or more mobile units.

In another aspect, the token may further comprise a mobile unit identity usable for identifying the mobile unit and/or a secured object identity usable for identifying the secured object and/or a validity time indicating a time span in which an authorization to execute the command on the secured object is valid and/or a token identity usable for identifying the token.

The validity time may allow the system to define a valid time in which the mobile unit is authorized to execute the command on the secured object. Therefore, the central unit may be able to coordinate authorization between a plurality of involved mobile units. Thus, the central unit may be able to avoid conflicts between a plurality of mobile units that may have been provided with an authorization by means of one or more tokens to execute one or more commands on the same secured object. In addition, the validity time may enable that a mobile unit may store more than one token that provides authorization to execute one or more commands on the same secure object, i.e. the validity time may define that one of said tokens is valid for a first period of time, whereas another token may be valid for another, e.g. later, period of time. In addition, the token may comprise a token identity that may allow to identify a token among a plurality of tokens.

In yet another aspect, the central unit may further be configured to transmit a revocation list to the secured object. The revocation list may be included in the token and may be transmitted to the secured object via the mobile unit. Furthermore, the revocation list may be transmitted in a message to the secured object via a gateway. The revocation list may comprise a token identity of a second token and/or a mobile unit identity. The central unit may further be configured to receive a revocation

confirmation when the revocation list is successfully received by the secured object. In another aspect, the revocation confirmation may be received from the gateway or from the mobile unit. The revocation confirmation may be signed by the secured object with a private key of the secured object. A public key of the secured objected may be transmitted to the central unit, wherein the public key of the secured object may be usable by the central unit to verify the integrity of the revocation confirmation.

To provide the possibility to revoke an already granted authorization, the central unit may support to transmit a revocation list to the secured object. The same benefits as outlined above to the revocation list and revocation confirmation in respect the system may also apply the central unit.

In a further aspect, as outlined in respect to the above described system, the central unit may be configured to enciypt the token at least in part.

In another aspect, the present invention provides a mobile unit that may be configured to receive a token, wherein the token may comprise a public key of the mobile unit and wherein the mobile unit may further be configured to transmit the token to a secured object.

By receiving a token from the central unit, the mobile unit may be granted

authorization to execute on or more commands o the secured object. The mobile unit may be a smartphone or an electronic handheld device. However, any electronic transceiver unit may be suitable to act as a mobile unit. Furthermore, the mobile unit may be implemented in software. According to a further aspect, the mobile unit may further be configured to transmit the public key to a central unit.

To be able to participate in the system as described above, the mobile unit may transmit its public key to the central unit. This may be considered as a registration of the mobile unit to the system.

In another aspect, the mobile unit may further be configured to generate a private- public key pair and to securely store at least the private key of said key pair.

The aforementioned public key may be generated by the mobile unit as a part of a private-public key pair. To maintain the security, the private key may be stored securely on the mobile unit, e.g. in a secured container file. Furthermore, the private key may be stored securely in the credential store of an Android™ device or in the key chain of an iOS™ device, providing specialized protection by said operating systems. The secured container file, the credential store or the key chain may be protected by means of a two- factor-authentication, a fingerprint or face recognition mechanism. The public key may also be securely stored. However, the public key may also be stored in an unsecured location on the mobile unit.

In another aspect, the mobile unit may further be configured to request a token from the central unit.

The mobile unit may transmit a request to the central unit to obtain a token from the central unit. In response, the central unit may generate a token, may store the public key of the mobile unit in the token and may transmit the token to the mobile unit. In this way, the user of the mobile unit may be able to receive a token directly from the central unit without any detours.

In another aspect, the mobile unit may further be configured to receive a revocation confirmation from the secured object in response to transmitting a revocation list to the secured object. The mobile unit may further be configured to transmit the revocation confirmation to the central unit and/or the revocation confirmation may be signed by the secured object with a private key of the secured object. The revocation confirmation may comprise a token identity of a second token and/or the revocation confirmation may comprise a mobile unit identity. The benefits of these aspects have already been outlined above in respect to the system and may apply in the same way to the mobile unit.

In another aspect, the mobile unit may further be configured to receive a challenge of a challenge-response process from the secured object in response to transmitting the token to the secured object. The mobile unit may further be configured to generate a response in reply to the challenge and to transmit the response to the secured object. Generating the response may comprise signing the received challenge with the private key of the mobile unit.

The secured object may transmit a challenge to the mobile unit and may request the mobile unit to sign the challenge with its private key. Then, the mobile unit may sign the challenge and may transmit the signed challenge back to the secured object. The secured object may then use the public key of the mobile unit included in the token to verify the signed challenge. This may authenticate the mobile unit as being entitled to execute the one or more commands on the secured object, e.g. to gain access to it and/or to unlock it.

Because the public key is already included in the token, no additional communication is required between the mobile unit and the secured object to perform the challenge response process. This may provide a fast authentication of the mobile unit and may lead to a fast execution of the one or more commands on the secured object. For example, this may lead to a fast unlocking of the secured object.

According to a further aspect, the present invention provides a secured object that may be configured to receive a token from a mobile unit, wherein the token may comprise a public key of the mobile unit, and wherein the secured object may be configured to execute a command if it is determined by the secured object that the execution of the command is permitted by the first token.

The secured object may be a car. In more detail, the mobile object may be an individually owned car or may be a car of a car sharing service. The mobile unit may also be a car owned by a car rental service. However, the secured object may be any kind of object that may require access protection and/or controlled execution of one or more commands. Therefore, the secured object may also be lock that may comprise a control unit for locking and/or unlocking the lock. The control unit of the lock may comprise a receiver and/or sender to receive the token and to transmits messages to a mobile unit from which the token was received. In addition, the secured object may be an electronic device like a computer or a computer system. The secured object may comprise an interface that may be used to receive the token. The interface may be a wireless or wire-based interface that may be usable for establishing a network connection to the mobile unit. The mobile unit may also be implemented in software.

The benefits as already outlined above with respect to the system may also apply to the secured object. The secured object may be able to process the received token and may determine based on the received token whether a user of the mobile unit is permitted to execute on or more commands on the secured object, e.g. an unlocking routine to get access to the secured object. The determination may be performed in an efficient manner because the token may comprise a public key of the mobile unit that transmits the token to the secured object. Including the public key in the token may avoid a separate transmission of the public key to the secured object which may reduce communication overhead. In addition, including the public key in the token may accelerate the process of determining whether the mobile unit or the user of the mobile unit shall be permitted to execute on or more commands on the secured object.

In a further aspect, determining that the token permits the execution of the command may comprise generating a challenge of a challenge-response process. The challenge may be generated by the secured object based on a random or pseudo-random algorithm and may be transmitted to the mobile unit in response to receiving the token. The secured object may be configured to verify a response according to the challenge- response process received from the mobile unit and may verify the response is based on the public key of the mobile unit.

The same benefits of the challenge-response process as outlined above with respect to the mobile unit may also apply to the challenge-response process as described by these aspects concerning the secured object.

In another aspect, the secured object may further be configured to validate the token based on the public key of the central unit. The command may be an unlock command usable to unlock the secured object. The command may be included in the token. The central unit may have signed the token with its private key. When the token is received from the mobile unit by the secured object, the secured object may use the public key of the central unit to verify that the token is not corrupted and/or may not have been modified during transmission.

The signature applied to the token by the central unit may take into account the data of the token (e.g. the validity time, the one or more commands etc.) and may take into account the public key of the mobile unit included in the token. Therefore, it may be detected whether the data or the public key included in the token have been corrupted or modified during transmission. If a modification and/or change of the data and/or the public key is detected, the secured object may reject the token and may not permit the execution of one or more commands included in the token, e.g. an unlock command.

In another aspect, the secured object may further be configured to retrieve a revocation list and the revocation list may comprise a mobile unit identity and/or a token identity. The revocation list may be included in the token received from the mobile unit and/or included in a message received from a gateway. The secured object may further be configured to deny the execution of a command included in a second token if a mobile unit identity in the revocation list corresponds to the mobile unit identity included in the second token. In a further aspect, the secured object may further be configured to transmit a revocation confirmation to the mobile unit or to the gateway and the revocation confirmation may comprise a signature based on a private key of the secured object.

These aspects may provide the same benefits as outlined with respect to the revocation of tokens and/or mobile identities performed by the above described system.

In another aspect, the secured object may further be configured to transmit a public key of the secured object to the central unit. Furthermore, the secured object may be a car, an autonomously driving car, an airplane and/or a drone.

The public key may belong to a private-public key pair of the secured object. The key pair may be generated by the secured object itself or may be generated by an initialization unit which then copies or moves the key pair to the secured object. In either case, the private key may be stored in a secured location on the secured object, e.g. in a secured container file, in a credential store or in a key chain as outlined before, whereas the public key may be stored in an unsecure location.

In another aspect, the present invention provides a token usable in a system for providing authentication and/or authorization as described above. The token may comprise a public key of a mobile unit, wherein the token may be configured for permitting execution of a command on a secured object. The public key of the mobile unit may be stored in the token by a central unit. The token may comprise one or more of: one or more commands; a validity time indicating a time span in which the command is permitted to be executed by the secured object; a secured object identity usable for identifying the secured object; a mobile unit identity usable for identifying the mobile unit; a signature based on a private key of the central unit; a token identity usable for identifying the token; a revocation list including one or more token identities.

Aspects of the present invention also relate to using a system, a central unit, a mobile unit, a token and/or a secured object as described above.

Furthermore, aspects of the present invention relate to a method for providing authentication and/or authorization. The method may comprise the step of generating and transmitting, by a central unit, a token that permits execution of a command by a secured object. The method may further comprise the step of receiving, by a mobile unit, the token transmitted by the central unit and may further comprise the step transmitting, by the mobile unit, the token to the secured object, wherein the token may comprise a public key of the mobile unit.

In another aspect, the method may further comprise the step of checking the integrity of the token based on a signature. The signature may be based on a private key of the central unit.

The method may further comprise the steps of performing, by the secured object, an integrity check based on the signature and/or denying, by the secured object, executing the command if the integrity check is not successful.

The signature may be based on a cryptographic signature system and/or the signature may cover at least a part of the token. The method may further comprise the step of only parsing, by the secured object, the token after successfully validating the signature.

In another aspect, the method may further comprise the step of signing, by the mobile unit, the token with a private key of the mobile unit. In another aspect, the method may further comprise one or more of the steps of:

transmitting, from the mobile unit to the secured object, a first nonce, transmitting, from the secured object to the mobile unit, a second nonce, wherein signing the token with the private key of the mobile unit may be based on the first nonce and on the second nonce. In another aspect, the token may comprise the command.

In a further aspect, the command may be an unlock command. In yet a further aspect, the method may further comprise the step of unlocking the secured object by executing the command by the secured object.

In a further aspect, the token may further comprise a mobile unit identity usable for identifying the mobile unit.

In another aspect, the token may further comprise a secured object identity usable for identifying the secured object.

In a further aspect, the token may further comprise a validity time indicating a time span in which the authorization to execute the command on the secured object is valid. In yet another aspect, the token may further comprise a token identity usable for identifying the token.

In a further aspect, the method may further comprise the step of receiving, by the secured object, a revocation list, wherein the revocation list comprises a mobile unit identity and/or a token identity. In yet another aspect, the method may further comprise the step of including the revocation list in the token received from the mobile unit and/or including the revocation list in a message received from a gateway. According to a further aspect, the method may further comprise the step of

determining, by the secured object, if a mobile unit identity in the revocation list corresponds to a mobile unit identity included in a second token and/or if a token identity in the revocation list corresponds to a token identity included in the second token. The method may further comprise denying, by the secured object, the execution of a command included in the second token, if the mobile unit identity in the revocation list corresponds to the mobile unit identity included in the second token and/or if the token identity in the revocation list corresponds to the token identity included in the second token.

In yet another aspect, the method may further comprise the steps of receiving, by the mobile unit, a revocation confirmation from the secured object if the token comprises the revocations list and if the token is successfully transmitted to the secured object, and/or transmitting, by the mobile unit, the revocation confirmation to the central unit.

According to a further aspect, the method may further comprise the steps of signing, by the secured object, the revocation confirmation with a private key of the secured object, and/or transmitting, by the secured object, a public key of the secured object to the central unit, wherein the public key is usable by the central unit to verify the integrity of the revocation conformation.

In a further aspect, the method may further comprise the step of refraining, by the secured object, from transmitting revocation confirmations to the mobile unit if the secured object was instructed accordingly by the mobile unit.

In yet another aspect, the method may further comprise the step of encrypting, by central unit, the token at least in part.

In a further aspect, the present invention relates to a method for operating a central unit, wherein the method may comprise one or more of the steps of receiving, by the central unit, a public key of a mobile unit, receiving, by the central unit, a request to generate a token, generating, by the central unit, the token comprising the public key of the mobile unit, and transmitting, by the central unit, the token. In yet another aspect, the method may further comprise the step of generating, by the central unit, a signature based on a private key of the central unit, wherein the signature may be usable for checking the integrity of the token.

In a further aspect, the method may further comprise the step of inserting, by the central unit, a command into the token based on the request.

In another aspect, the command may be an unlock command usable for unlocking a secured object.

In yet another aspect, the request may be received from the mobile unit and/or from a third-party unit.

In a further aspect, the method may further comprise the step of inserting, by the central unit, a mobile unit identity into the token usable for identifying the mobile unit.

In a further aspect, the method may further comprise the step of including a secured object identity into the token usable for identifying the secured object.

In yet another aspect, the method may further comprise the step of inserting, by the central unit, a validity time into the token, the validity time indicating a time span in which an authorization to execute the command on the secured object is valid.

In yet another aspect, the method may further comprise the step of inserting, by the central unit, a token identity usable for identifying the token.

In another aspect, the method may further comprise the step of transmitting, by the central unit, a revocation list to the secured object.

According to a further aspect, the method may further comprise one or more of the steps of inserting, by the central unit the revocation list into the token and transmitting, by the central unit, the token to the secured object via the mobile unit, and

transmitting, by the central unit, the revocation list in a message to the secured object via a gateway.

In another aspect, the method may further comprise the step of inserting, by the central unit, a token identity of a second token and/or a mobile unit identity into the revocation list. In yet another aspect, the method may further comprise the step of receiving, by the central unit, a revocation confirmation when the revocation list is successfully received by the secured object.

In a further aspect, the revocation confirmation may be received from the gateway or from the mobile unit. The revocation confirmation may be signed by the secured object with a private key of the secured object.

According to a further aspect, the method may further comprise one or more of the steps of receiving, by the central unit, a public key of the secured objected, and verifying, by the central unit, the integrity of the revocation confirmation via the public key of the secured object.

In another aspect, the method may further comprise the step of encrypting, by the central unit, the token at least in part.

Another aspect of the present invention relates to a method for operating a mobile unit. The method may comprise one or more of the steps of receiving, by the mobile unit, a token, wherein the token may comprise a public key of the mobile unit, and

transmitting, by the mobile unit, the token to a secured object.

In another aspect, the method may further compris the step of transmitting, by the mobile unit, the public key to a central unit.

In yet another aspect, the method may comprise one of the steps of generating, by the mobile unit, private-public key pair, and securely storing, by the mobile unit, at least the private key of said key pair.

In a further aspect, the method may further comprise the step of requesting, by the mobile unit, a token from the central unit.

In another aspect, the method may further comprise the step of receiving, by the mobile unit, a revocation confirmation from the secured object in response to transmitting a revocation list to the secured object.

In a further aspect, the method may further comprise one or more of the steps of transmitting, by the mobile unit, the revocation confirmation to the central unit, and/or wherein revocation confirmation is signed by the secured object with a private key of the secured object.

In yet another aspect, the revocation confirmation may comprise a token identity of a second token and the revocation confirmation may comprise a mobile unit identity.

In a further aspect, the method may further comprise the step of receiving, by the mobile unit, a challenge of a challenge-response process from the secured object in response to transmitting the token to the secured object.

According to another aspect, the method may further comprise one or more of the steps of generating, by the mobile unit, a response in reply to the challenge, and transmitting, by the mobile unit, the response to the secured object.

In another aspect, the step of generating the response may comprise the step of signing the received challenge with the private key of the mobile unit.

Another aspect of the present invention relates to providing a method for operating a secured object, wherein the method may comprise one or more of the steps of receiving, by the secured object, a token from a mobile unit, wherein the token may comprise a public key of the mobile unit, determining, by the secured object, that an execution of a command is permitted by the first token, and executing, by the secured object, the command if it is determined by the secured object that the execution of the command is permitted by the first token.

According to another aspect, the step of determining that the token permits the execution of the command may comprise the step of generating a challenge of a challenge-response process.

In yet another aspect, the method may further comprise the step of generating, by the secured object, the challenge based on a random or pseudo-random algorithm.

In a further aspect, the method may further comprise the step of transmitting, by the secured object, the challenge to the mobile unit in response to receiving the token. In another aspect, the method may further comprise the step of verifying, by the secured object, a response according to the challenge-response process received from the mobile unit.

In another aspect, the step of verifying the response may be based on the public key of the mobile unit.

In a further aspect, the method may further comprise the step of validating, by the secured object, the token based on the public key of the central unit.

According to another aspect, the step of validating may further comprise the step of using the public key of the central unit to verify that the token is not corrupted and/or that the token has not been modified during transmission.

In yet another aspect, the command may be an unlock command usable to unlock the secured object and the command may be included in the token.

In a further aspect, the method may further comprise the step of retrieving, by the secured object, a revocation list, wherein the revocation list may comprise a mobile unit identity and/or a token identity.

According to a further aspect, the revocation list may be included in the token received from the mobile unit and/or may be included in a message received from a gateway.

In yet another aspect, the method may further comprise the step of denying, by the secured object, the execution of a command included in a second token if a mobile unit identity in the revocation list corresponds to the mobile unit identity included in the second token.

According to another aspect, the method may further comprise the step of transmitting, by the secured object, a revocation confirmation to the mobile unit or to the gateway, wherein the revocation confirmation may comprise a signature based on a private key of the secured object.

In a further aspect, the method may further comprise the step of transmitting, by the secured object, a public key of the secured object to the central unit. In addition, the present invention provides a computer program comprising instructions for performing any of the preceding methods relating to the operation of a system, a central unit, a mobile unit and/or a secured object as described above.

4. Short Description of the Figures

In the following description, aspects of the invention are further described with reference to the following figures, wherein:

Fig. l: illustrates a system comprising a central unit, a mobile unit and a secured object according to an aspect of the present invention.

Fig. 2: illustrates a system comprising a central unit, a mobile unit and a secured object in respect to identity creation according to an aspect of the present invention.

Fig. 3: illustrates a system comprising a central unit, a mobile unit and a secured object in respect to authorization according to an aspect of the present invention.

Fig. 4: illustrates the structure of a token according to an aspect of the present invention.

Fig. 5: illustrates a system comprising a central unit, a mobile unit and a secured object in respect to authentication according to an aspect of the present invention.

Fig. 6: illustrates a sequence diagram showing the process of initializing a mobile unit according to an aspect of the present invention.

Fig. 7: illustrates a sequence diagram showing the process of initializing a secured object according to an aspect of the present invention.

Fig. 8: illustrates the structure of a token according to an aspect of the present invention.

Fig. 9: illustrates a sequence diagram showing the process of executing a command on a secured object according to an aspect of the present invention. Fig. 10: illustrates a sequence diagram showing a first process of revoking a permission to execute a command on a secured object according to an aspect of the present invention.

Fig. 11: illustrates a sequence diagram showing a second process of revoking a permission to execute a command on a secured object according to an aspect of the present invention.

Fig. 12: illustrates a sequence diagram showing the communication between a mobile unit and a secured object according to an aspect of the present invention.

Fig. 13: illustrates a signed token and a signed response according to an aspect of the present invention.

Fig. 14: illustrates a key store of a mobile unit according to an aspect of the present invention.

Fig. 15: illustrates a further key store of a mobile according to an aspect of the present invention.

Fig. 16: illustrates the structure of a central unit according to an aspect of the

present invention.

5. Detailed Description of the Figures

Various aspects of the novel system, central unit, mobile unit, secured object, token, methods and computer programs are described more fully hereinafter with reference to the accompanying drawings. These aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

Figure 1 illustrates a system 1 comprising a central unit 10, a mobile unit 20 and a secured object 30 according to an aspect of the present invention. The system 1 may is not be limited to one central unit 10, to one mobile unit 20 or to one secured object 30, but may comprise a plurality of central units 10, mobile units 20 and secured objects 30. If the system l comprises more than one central unit to, it may be required that the central units 10 synchronize with each other.

The central unit to may be a computer, a computer center, a computer cluster, a cloud, a processing unit or any other computing device. Furthermore, the central unit to may be implemented in software, in hardware or in a combination of soft- and hardware. It may comprise one or more processors and a memory. Furthermore, it may comprise one or more database systems for storing data.

The central unit to may be operated by a security service provider. It may not be required that the service provider also operates one or more mobile units 20 or one or more secured object 30. Instead, it is possible that the one or more mobile units 20 and the one or more secured objects 30 are operated and/or owned by one or more other parties. For example, the central unit 10 may be operated by a security provider that may offer security services to said parties.

The central unit 10 may comprise a network interface configured to connect the central unit 10 to one or more networks. The one or more networks may be wireless networks (e.g., WLAN, UMTS, LTE, GPRS, Socket-based, NFC, Bluetooth® etc. ) or wire-based networks (e.g. LAN etc.).

The mobile unit 20 may be a smartphone, a cellular phone, a laptop, an electronic car key, a personal data assistant, an NFC card or an RFID card, an electronic

entertainment device, a vehicle control unit, an embedded control unit, a machine, an autonomous machine or any other portable communication device. The mobile unit may comprise a network interface to connect the mobile unit 20 to one or more networks of the aforementioned types listed in respect to the central unit 10.

The secured object 30 may be an individual owned car, a car provided by a car sharing service, an autonomously driving car, an airplane, a drone or a car provided by a car rental service. In addition, the secured object may be a rental apartment, a common apartment, a house, a lock, a machine, a bulb or virtually any object that may require access control with respect to controlling the execution of one or more commands on it, like a computer system. Moreover, the secured object 30 may be an electronic lock. The secured object 30 may comprise a controller that may comprise an interface to connect the secured object 30 to one or more networks of the aforementioned types listed in respect to the central unit to. As a result, the central unit to, the mobile unit 20 and the secured object may be communicatively coupled with each other.

The central unit may comprise a central unit identity 12 that allows identification of the central unit 10. Therefore, the central unit identity 12 may be a unique alphanumeric string. In addition, the mobile unit 20 and the secured object 30 may also comprise such an identity 22, 32. When using a unique alphanumeric string as an identification (instead of, for example, a device ID, a phone number or a code of a car registration plate) for the central unit 10, for the mobile unit 20 and/or for the secured object 30, privacy may be improved because an alphanumeric string may not provide any further information about the corresponding unit or object.

Furthermore, the central unit 10, the mobile unit 20 and the secured object 30 may comprise a private-public key pair comprising a private key 16, 26, 36 and a public key 14, 24, 34. Each key pair may be generated based on the RSA cryptosystem or on an elliptic curve ciyptosystem (ECC). However, any other public-key based cryptosystem may be suitable for generating the private-public key pairs.

The central unit 10, the mobile unit 20 and the secured object 30 may generate the key pairs themselves, but it may be possible that the key pairs are generated by one or more third devices. In this case, a third device may copy or move the respective key pair to the central unit 10, to the mobile unit 20 and/or to the secured object 30. After having generated or received the key pair, the central unit 10, the mobile unit 20 and the secured object 30 may store at least the private key 16, 26, 36 in a secured manner. This may be achieved by placing the private key 16, 26, 36 into an encrypted container file or into a key store. Storing the private key 16, 26, 36 in a secure location may prevent that the private key 16, 26, 36 may be stolen by any malicious third-party. Once received or generated, the private keys 16, 26, 36 may never leave the respective unit 10, 20 or object 30. In contrast, the public key 14, 24, 34 may be stored in an arbitrary location which does not need to be secured.

The length of the private keys 16, 26 and 36 of the central unit 10, of the mobile unit 20 and of the secured object 30 may be at a ration 4:2:1. For example the private key 16 of the central unit 10 may have a length of 2048 bit, the length of the private key 26 of the mobile unit 20 may have a length of 1024 bit, whereas the private key 39 of the secured object 30 may have a length of 512 bit. Such a ratio may provide an acceptable trade-off between security and the required computational resources for processing the keys.

Figure 2 illustrates the exchange of the public keys 14, 24, 34 between the central unit 10, the mobile unit 20 and the secured object 30 according to an aspect of the present invention. In step 2, the secured object 30 may transmit its public key 34 to the central unit 10 using one of the above described networks. After reception of the public key 34, the central unit 10 may store the public key 34, e.g. in the aforementioned database. In step 3, the central unit 10 may transmit its public key 14 to the secured object 30 which may store the public key 14 in a secure location. Then, the central unit 10 may store the public key. The public key 14 may be stored in an unsecure location. Additionally or alternatively, the private key 16 may be used to sign the public key 34, wherein the signed public key 34 may be sent back to the secured object 30. The secured object 30 may store the signed public key 34 in a secure place. Furthermore, the central unit 10 may store it in the database. In step 4, the mobile unit 20 may transmit its public key 24 to the central unit 10. The public key 24 may be stored by the central unit 10 in the same way as it stores the public key 34 received from the secured object 30. The order of the execution of steps 2, 3 and 4 may vary.

When all the public keys 14, 24, 34 have been exchanged, the system 1 may be considered as initialized. When a further mobile unit 20 is integrated into the system 1, it may execute step 3 to transmit its public key 24 to the central unit 10. When a further secured object 30 is integrated into the system 1, it may execute step 2 to transmit its public key 34 to the central unit 10. In addition, the central unit 10 may execute step 3 to transmit its public key 14 to the secured object 30 to be integrated into system 1. This may allow an integration of an arbitrary number of mobile units 20 and secured objects 30 into the system 1 at any time. Therefore, the system 1 may provide improved scalability. The integration of further mobile units 20 and/or secured objects 30 may not interrupt the operation of system 1.

The process of Figure 2 may also be used for key rotation of the key pairs stored on the mobile unit 20, which may further improve security. Thus, the key pairs may be exchanged regularly. Figure 3 illustrates how a mobile unit 20 requests a token from the central unit 10 according to an aspect of the present invention. This process may be considered as authorizing the mobile unit 20 or the user thereof to execute one or more commands on one or more secured objects 30. In step 5, the mobile unit 20 may transmit a request to the central unit 10. The request may include the identity 32 of the secured object 30 to which the mobile unit 20 wants to be authorized. The request may be transmitted to the central unit 10 by means of one of the aforementioned networks and may include a plurality of secured objects identities 32. In response to the request, the central unit 10 may generate a token 40. The token 40 may then be transmitted in step 6 to the requesting mobile unit 20. If the mobile unit 20 had requested authorization for a plurality of secured objects 30, the central unit 10 may either generate one token 40 that provides authorization for all the desired secured objects or it may generate one token 40 per requested authorization.

Requesting a token 40 may also be conducted by a third-party entity. Such a third-party entity may transmit a request to the central unit 10. Besides the one or more secured objects 30, such a third-party request may comprise the mobile unit identity 22 of the mobile unit 20 to which authorization shall be granted. In response to the third-party request, the central unit 10 may generate one or more tokens 40 and may transmit the one or more tokens 40 to the mobile unit 20 specified in the third-party request. Both the third-party request and the transmission of the one or more tokens may be transmitted via the aforementioned networks.

Figure 4 illustrates the structure of a token 40 according to an aspect of the present invention. The token may comprise a token identity 47 which may identify the token 40. The token identity 47 may be a unique alphanumeric string and may be generate before or during the token 40 generation by the central unit 10.

Furthermore, the token 40 may include on or more commands 42. The one or more commands 42 may be specified in the request received by the central unit 10 from the mobile unit 20 and/or from the third-party entity. Such a command 42 may be suitable for triggering a corresponding routine on the secured object 30 that receives a token 40 that includes the command 42. This may for example be an unlock command, an open command, a close command or any other suitable type of command. The one or commands 42 may comprise an unlock command, a lock command, an engine-start command etc. The command 42 may be suitable for triggering virtually any kind of routine, mechanism or process that is implemented by the secured object 30 or by a device that is coupled with or attached to the secured object 30.

The underlying system 1 may only support the execution of just one command 42, e.g. an unlock routine. If this is the case, no command 42 may be included in the token 40. Instead, the token 40 itself may represent the command 42. Thus, when a secured object 30 receives a token 40 without a command 42 in a system 1 that supports only one command 42, the secured object 30 may know which routine, process or mechanism to trigger in response to receiving the token 40.

Furthermore, the token 40 may comprise a validity time 41 that may define a time span in which the mobile unit 20 is authorized to execute the one or more commands 42 on the secured object 30. The validity time 41 may allow the system 1 to define a period in which the mobile unit 20 is authorized to execute the one or more commands 42 on the secured object 30, e.g. between 10 - 11 o’clock. Therefore, the system 1 may be able to coordinate authorization between a plurality of involved mobile units 20. For example, the time span in a token 40 may define that a first mobile unit 20 is authorized to execute on or more commands between 10 - 11 o’clock, whereas another token 40 intended for another mobile unit 20 may specify that this other mobile unit 20 is only authorized to execute one or more command 42 between 11 - 12 o’clock. Thus, the system 1 may be able to avoid conflicts between a plurality of mobile units 20 that have requested a token for being authorized to execute one or more commands 42 on the same secured object 30. In addition, the validity time 41 may enable that a mobile unit 20 may store more than one token 40 that provides authorization to execute one or more commands 42 on the same secure object 30, i.e. the validity time 41 may define that one of said tokens 40 is valid for a first period of time, whereas another token 40 may be valid for another, e.g. later, period of time.

The token 40 may comprise a public key 45 of the mobile unit 20 that is intended to receive the token 40. The public key 45 included in the token 40 may serve as a basis for an efficient and secure authentication process between the secured object 30 to which the token 40 may be transmitted and the mobile unit 20. In addition, the token 40 may comprise a mobile unit identity 44 that may identify the mobile unit 20 intended to receive the token 40. The token 40 may also comprise a plurality of mobile unit identities 44. This may allow a valid reception of the token 40 by a plurality of mobile units 20. If a user that participates in the system 1 operates more than one mobile unit 20, a plurality of mobile unit identities 44 may allow a reception of the token 40 on all the mobile units 20 of said user. In this case, the token 40 may also comprise a plurality of public keys 45, wherein each of the plurality of public keys 45 may correspond to one of the plurality of mobile units 20.

Furthermore, the token 40 may comprise a secured object identity 43 that identifies the secured object 30 which is intended to receive the token 40 from the mobile unit 20. The secured object identity 43 may enable the secured object 30 that receives the token 40 to determine whether it is the secured object 30 intended for reception of the token 40. Therefore, the secured object identity 43 may provide an efficient protection against a transmission of the token 40 to an incorrect secured object 30. The token 40 may comprise a plurality of secured object identities 43. This may allow a valid transmission of the token 40 to a plurality of secured objects 30.

The token 40 may also comprise a token identity 47. The token identity 47 may be used by the central unit 10 to identify and/or to revoke each generated token 40. Therefore, the token 40 may comprise a revocation list 48. The revocation list 48 may comprise one or more token identities 47 of other tokens 40 and/or one or more mobile unit identities 22. The process of revocation will be described in more detail with respect to Figures 10 and 11 below.

In addition, the token 40 may comprise a signature 46 based on the private key 16 of the central unit 10. When all desired information 41, 42, 43, 44, 45, 47, 48 (which may be considered as payload) are included in the token, the central unit 10 that generates the token 40 may calculate a digital signature 46 that covers the complete payload. The calculation is based on the private key 16 of the central unit. Then, after a successful calculation, the digital signature 46 may be stored in the token besides the payload. If the payload gets corrupted or is modified during transmission, e.g. by a hacker or an eavesdropper, the digital signature 46 may not match any more to the payload.

Therefore, an entity that holds the public key 14 of the central unit 10 may be able to detect the change of the payload. Due to the digital signature 46, the token 40 may be transmitted between the central unit 10 and the mobile unit 20 and/or between the mobile unit 20 and the secured object 30 without being encrypted. Any modification or change of the payload of the token 40 may be detected by verifying the digital signature 46 against the payload by means of the public key 14 of the central unit. Therefore, the digital signature 46 may provide an efficient and secure way for transmitting the token 40 between the entities of the system 1. However, it may also be possible to transmit the token 40 in an encrypted manner. This may improve privacy, because a hacker or an eavesdropper may not be able to gain any privacy-related information from the token 40.

Figure 5 illustrates a token-based authentication according to an aspect of the present invention. As outlined above in respect to Figure 2, the reception of a token 40 may authorize a mobile unit 20 to execute one or more commands 42 on a secured object 30. However, before the secured object 30 executes the one or more commands 42, an authentication of the mobile unit 20 or the respective user may be required. Therefore, the secured object 30 may determine that the mobile 20 effectively is the mobile unit 20 that it pretends to be.

In step 7, the mobile unit 20 may transmit the token 40 to the secured object 30. After reception, the secured object 30 may verify the digital signature 46 against the payload of the token 40. This verification is based on the public key 14 of the central unit 10 that may have been transmitted previously to the secured object 30, as for example outlined with respect to Figure 2.

If the verification of the digital signature 46 is successful, the secured object 30 may transmit a challenge according to a challenge-response process to the mobile unit 20 in step 8. A challenge-response process is a protocol in which one party presents a question (the challenge) and another party must provide a valid answer (the response) to be authenticated. The challenge may comprise a random or pseudo-random number, e.g. in form of one or more nonces. Then, the mobile unit 20 may use its private key 26 to create a signature of the token 40 and/or of the one or more nonces. Afterwards, the signature is transmitted to the secured object 30 as a response to the challenge in step 9. Afterwards, the secured object 30 may use the public key 45 of the mobile unit 20 that is included in the token 40 to verify the received response. If the verification is successful, it may be ensured that the mobile unit 20 effectively is the one it pretends to be and thus may be considered as authenticated.

If the mobile unit 20 is successfully authorized as for example outlined according to the description with respect to Figure 3 and if the mobile unit 20 is successfully

authenticated as outlined here, the mobile unit 20 may be permitted to execute the one or more commands 42 included in the token on the secured object 20. Executing the one or more commands 42 on the secured object 30 may comprise extracting the one or more commands 42 from the token 40 by the secured object 30 and using the one or more commands 42 to trigger one or more corresponding mechanisms, routines and/or processes on the secured object 30.

By including the public key 45 of the mobile unit 20 in a signed token 40, the mobile unit may be authorized and authenticated without having to modify the token 40. Furthermore, since the public key 45 is included in the token, the authentication of the mobile unit may be executed in a short time because the secured object 30 may directly transmit a challenge to the mobile unit 20, before or during the extraction of the public key 45 from the received token 40. As a result, the one or more commands 42 may also be executed in a short time.

The architecture of system 1 combined with the structure of the token 40 may provide an efficient and secure authentication and/or authorization system. Encryption and verification mechanisms may only be used where they are required. Furthermore, the system architecture and the token structure may provide scalability. A plurality of mobile units 20 and/or secured objects 30 may be integrated into the system 1.

Moreover, this integration may not require interrupting the operation of system 1. In addition, the lean architecture of system 1 may allow to implement the functions of the involved entities in software having small size. For example, the required software functions of the mobile unit 20 may be small enough to be directly implemented on the Bluetooth® stack and/or on the Bluetooth® stack of the secured object 30 and/or in the Bluetooth® integrated circuit of the respective component. This may further accelerate the process of authentication and/or authorization because the time-consuming process of pairing the mobile unit 20 with the secured object 30 may be skipped or at least accelerated. Pairing may be automated by a directory service of the secured object 30 in the central unit 10. The directory service may provide all relevant information for automating Bluetooth® low energy communication, e.g. BT MAC UUID, to a secured object 30, or any other communication technology.

In addition, system l provides flexibility because the involved entities may be operated by different operators. Assuming that the system l is utilized with respect to a car sharing service, the central unit to may be operated by a security provider offering security service to the car sharing provider. The security provider may focus on providing a secure infrastructure for operating the central unit to. The secured object io may be owned and/or operated by the car sharing service, whereas the mobile units 20 may be operated by customers of the car sharing service. Because the security of system l may originate from its architecture and not only from the utilized

cryptographic systems as such, the interface and protocol definitions required for communication between the involved entities may not need to be protected or kept in secret.

More generally, an operator may also be considered as an identity. Several identities (or operators) may exist in the central unit io. Thus, the central unit io may exclusively assign a key chain for each of the operators, wherein each operator may only control his assigned key chain and/or may only access his assigned key chain. An operator may be mapped to a customer (e.g. a company that uses the security services provided by a security service provider as a part of their access control system) or even an original equipment manufacturer (OEM), e.g. a car manufacturer. Each operator registered with the central unit io may have its own key pair consisting of a public key 14 and a private key 16 as well as a certificate. The cryptographic method used for generating the key pairs (e.g. ECC or RSA) and the key length used may depend on the use case and/or on the hardware built into the secured object 30.

Every mobile unit 20 and secured object 30 may belong to exactly one operator and each may have a unique identity. Each operator may be in total control of the authorizations that are required by a mobile unit 20 to access a secured object 30 and/or to execute one or more commands 42 on it.

Figure 6 illustrates the process 60 of initializing a mobile unit 20 according to an aspect of the present invention in terms of a sequence diagram. In step 61, the mobile unit 20 may transmit initialization information to the central unit 10. The initialization information may comprise an application programmer interface (API) key of a software-related communication interface provided by the central unit to. The usage of an API key may ensure that only mobile units 20 that have a valid API key may communicate with the central unit to. Therefore, the system l may control which mobile units 20 may be integrated by only providing valid API keys to the desired mobile units 20. Furthermore, the API key may map the mobile unit 20 to an operator. The API key may be a string of 40 characters, a token or a certificate etc.

In step 62, the central unit 10 may communicate to the mobile unit 20 which

cryptographic method and/or which cryptosystem, protocol and/or version may be used for generating the private-public key pair of the mobile unit 20. In addition, the length of the keys may be communicated. This may allow dynamically changing the required key length during operation of the system 1.

In step 63, the mobile unit 20 may generate the private-public key pair, wherein Figure 6 denotes the private key 26 as privKeyMU and the public key 24 as pubKeyMU. The private key 26 may be stored securely, whereas the public key 24 may be stored in an unsecure location. A secure location for storing the private key 26 may be a memory region which may not be accessible by external interfaces, e.g. a key store.

In step 64, the public key 24 of the mobile unit 20 is retrieved from the memory.

In step 65, the mobile unit 20 may transmit its pubic key 24 to the central unit 10 together with the API key. The API key may ensure that only a desired mobile unit 20 may transmit its public key 24 to the central unit 10.

In step 66, in response to the transmission of the public key 24, the central unit may generate a mobile unit identity 22 and a certificate based on the public key 24 of the mobile unit 20 which may be signed by an operator certificate, wherein an operator may be a customer that makes use of the services provided by the operator of the central unit 10, e.g. a security service provider. This may allow the usage of the central unit 10 to provide security services to a plurality of different operators at the same time. After generating the mobile unit identity 22 and the certificate, the central unit may transmit the mobile unit identity 22 and the certificate to the mobile unit 20. Figure 7 illustrates the process 70 of initializing a secured object 30 according to an aspect of the present invention in terms of a sequence diagram. In step 71, an initialization service 11 may transmit initialization information to the central unit 10. The initialization information may comprise an API key of a software-related communication interface provided by the central unit 10. The usage of an API key may ensure that only initialization services 11 that have a valid API key may communicate with the central unit 10. Therefore, the system 1 may control which initialization service 11 may be integrated by only providing valid API keys to the desired initialization services 11. Furthermore, the API key may map the secured object 30 and/or the initialization service 11 to an operator. The API key may be a string of 40 characters, a token or a certificate etc.

An initialization service 11 may be provided by a computing device operated and/or owned by the owner/provider of the secured objects 30. Instead of using an

initialization service 11, the functionality implemented by the initialization service 11 may be implemented directly on the secured object 30 to be initialized.

In step 72, the central unit 10 may communicate to the initialization service 11 which cryptographic method and/or which ciyptosystem may be used for generating the private-public key pair of the secured object 30. In addition, the length of the keys may be communicated. This may allow dynamically changing the required key length during operation of the system 1.

In step 73, the initialization service 11 may generate the private-public key pair, wherein Figure 7 denotes the private key 36 as privKeySO and the public key 34 as pubKeySO.

In step 74, the public key 34 is retrieved from the memory.

In step 75, the initialization service 11 may transmit the pubic key 34 of the secured object 30 to the central unit 10 together with the API key. Again, the API key may ensure that only a desired initialization service 11 may transmit the public key 34 of the secured object 30 to the central unit 10.

In step 76, in response to the transmission of the public key 34, the central unit may generate a secured object identity 32 and a certificate based on the public key 34 of the secured object 30 which may be signed by an operator certificate of an operator as already outlined above with respect to Fig. 6. After generating the secured object identity 32 and the certificate, the central unit 10 may transmit the secured object identity 32 and the certificate to the initialization service 11. Then, not shown in Fig. 7, the initialization service 11 may transmit the certificate, the secured object identity 32 as well as the private-public key pair comprising the public key 34 and the private key 36 to the secured object 30.

Fig. 8 illustrates the structure of a token 40 according to an aspect of the present invention. The token 40 may be subdivided into several sections comprising a header, content and a signature 46.

The header may indicate the algorithm that has to be used to verify the signature 46 which may be encoded in 2 bytes. Furthermore, the header may indicate the length of the signature 46 which may also be encoded in 2 bytes. In addition, the header may indicate the content type and the content length, wherein each of the two indications may be encoded in 2 bytes, respectively. Thus, the header may have a size of 8 bytes in total.

The content may comprise a token identity 47, a secured object identity 43 and a mobile unit identity 44. All three identities 43, 44, 47 may be encoded in 16 bytes, respectively. In addition, the content may comprise a validity time 41, represented by a start time and an end time, wherein both times may be encoded in 4 bytes, respectively. Furthermore, the content may comprise at least one command 42, wherein a maximum number of eight commands may be allowed. The at least one command 42 may be encoded in 40 bytes. In addition, the content may comprise at least one channel, wherein a maximum number of four channels may be allowed. The at least one channel may also be encoded in 40 bytes. The channels may correspond to the above listed network types as outlined in respect to the system 1. Thus, the communication between the involved entities may be based on one or more of the channels defined in the token 40. This may improve flexibility and compatibility between the involved entities regarding communication.

The content may also comprise one or more extension which may be encoded in 4 bytes. In addition, the content may comprise a maximum number of five extension descriptors encoded in 5 bytes. The extension descriptors may be used to define what kind of extensions may be included in the content. Furthermore, the content may comprise zero or more extensions which may be encoded in 72 - 268 bytes. However, the skilled person will appreciate that the number of bytes of the zero or more extension may vary according to the respective needs. The extensions may be used to communicate further information to a secured object 30. The extensions may for example hold revocation information, personal data of the user of a mobile unit 20 or may comprise timing-related data to synchronize clocks between the central unit 10, the mobile unit 20 and/or the secured object 30.

In addition, the content may comprise the public key 45 of the mobile unit 20 which may be encoded in 68 bytes. The public key 24 may have been generated based on ECC using the secp256n curve, as it may provide a good comprise between security and speed. However, also the curves secp224ri, secp384ri and secp52iri are possible. Commonly, the usage of ECC may reduce the amount of memory required for generating key pairs, calculating signatures and/or verifying signatures. Furthermore, the content may comprise a revocation list that may be encoded in 64 bytes. In addition, the central unit 10 may store a timestamp in the content of the token 40 that may define the generation time of the token 40. Furthermore, it may be possible that the timestamp defines the time when the token 40 has been downloaded by a mobile unit 20. Finally, the content may comprise a user payload which may be encoded in 132 bytes. The user payload may hold personal data (name, address, phone number, email address, payment information etc.) of the user of the mobile unit 20.

The content and the header may be signed by a digital signature 46. The digital signature 46 may be generated by means of ECC based on the secp256ri curve. The signature may be encoded in 64 bytes. When the signature has been successfully calculated, it may also be included into the token 40.

Figure 9 illustrates the process 90 of executing a command 42 on a secured object 30 in terms of a sequence diagram according to an aspect of the present invention. In step 91, an operator backend 13 may transmit a request to the central unit 10 the generate one or more tokens 40. In order to be able to create a token 40, the operator backend 13 may have to authenticate itself at the central unit 10. Possible authentication methods may comprise a username-password-based method, a certificate-based method or an 0Auth2-token-based method. The operator backend 13 may be a computing device. In response, the central unit 10 may generate the one or more requested tokens 40. In addition, also the mobile unit 20 may request the generation of a token 40 in a similar way as described with respect to the operator backend 13.

In step 92, the mobile unit 20 may request to transmit the one or more tokens 40 from the central unit 10 to the mobile unit 20. In response, in step 93, the central unit 10 may transmit the one or more tokens 40 to the mobile unit 20. In case that one or more tokens 40 are lost after transmission, e.g. if they are accidentally deleted by the user of the mobile unit 20, steps 92 and 93 may be repeated. Therefore, steps 92 and 93 may be considered as a synchronization of the one or more tokens 40 between the central unit 10 and the mobile unit 20. To do so, the central unit 10 may either store the generated tokens 40 until they expire or they may be generated again. The expiration may be determined based on the validity time 41 that may be included in the one or more tokens 40. Thus, an easy way of restoring tokens 40 may be provided. Restoring tokens 40 may also be used if a user replaces on old mobile unit 20 with a new one. Then, the user may be able to receive all his previously requested and generated tokens 40, preferably with an expiration time lying in the future, from the central unit 10. The synchronization may be triggered manually be the mobile unit 20 and/or by an external notification, like a push notification or a cloud-based message. The synchronization may also be activated in a time-controlled manner, e.g. once per hour, once per day etc. It may also be possible that the content of a token 40 may have been changed at the central unit 10. Then, the aforementioned synchronization may be used to update the tokens 40 that have already been transmitted to the mobile unit 20.

After a successful reception of the one or more tokens 40, in step 94, the mobile unit 20 may store the one or more tokens, e.g. in a local memoiy. The token may be considered as an authorization of the mobile unit 20 to execute one or more commands 42 on the secured object 30. To execute one or more commands 42, the mobile unit 20 may select a token 40 of the received ones in step 95.

Then, in step 96a, the mobile unit 20 may establish a connection, wireless or wire- based, with the secured object 30. In step 96b, the mobile unit 20 may transmit a list of supported protocols to the secured object 30. The secured object 30 may select a protocol of the list of protocols which it supports. In step 96c, the secured object 30 may transmit an indication to the mobile unit 20 to indicate which protocol has been selected. In step 96d, the mobile unit 20 may transmit one of the one or more tokens 40 to the secured object 30. In response, in step 96e, the secured object 30 may verify the token 40 based in the signature 46 and, if the verification is successful, the secured object may consider the mobile unit 20 as being authorized and may execute in step 96f one or more commands 42 included in the token 40. After a successful execution of the one or more commands 42, in step 96g, the secured object may transmit a response to the mobile unit 20 indicating that the execution was successful. The response may comprise user specified data, e.g. specified by an OEM, a user access log, the time at which the response is transmitted, a log level and/or a version number, e.g. of the used firmware of the secured object 30.

Figure 10 illustrates a sequence diagram showing a first process 100 of revoking a permission to execute a command 42 on a secured object 30 according to an aspect of the present invention. In step 101, the operator backend 13 may transmit a request to the central unit 10 to request the revocation of a token 40. Then, the central unit 10 may generate corresponding revocation information and may sign the revocation information with the private key 16 of the central unit. The revocation information may comprise the token identity 47 of the token 40 to be revoked. In step 102, a gateway 50 may request transmission of the revocation information. In response, in step 103, the central unit 10 may transmit the revocation information to the gateway 50. After the reception of the revocation information, in step 104, the gateway 50 may transmit the revocation information to the secured object 30 for which the one or more revoked tokens 40 were intended to provide permission to execute one or more commands 42.

In step 105a, the secured object 30 may verify the revocation information using the public key 14 of the central unit 10. If the verification is successful, in step 105b, the secured object 30 may store the revocation information. In step 105c, the secured object 30 may generate a revocation confirmation and may sign it using its private key 36. After signing, the secured object 30 may transmit the signed revocation

confirmation to the gateway 50. In step 107, the gateway 50 may transmit the revocation confirmation to the central unit 10. The central unit 10 may then use the public key 34 of the secured object to verify the correct transmission of the revocation confirmation. In step 108, the central unit to may store the revocation confirmation and/or may change the status of the revoked token 40 to“removed”.

If the revoked token 40 is now transmitted to the secured object 30, even if its expiration time has not been reached, the secured object 30 may determine based on the stored revocation information that the token 40 may not provide permission to execute the one or more commands 42 anymore included in the token 40. Thus, the execution of the one or more commands 42 may be blocked and/or denied.

The process 100 may also be performed without the gateway 50. Then, the central unit 10 may directly communicate with the secured object 30.

Figure 11 illustrates a sequence diagram showing a first process no of revoking a permission to execute a command 42 on a secured object 30 according to an aspect of the present invention. In step 111, the operator backend 13 may transmit a request to the central unit 10 to request the revocation of a second token 40. Then, the central unit 10 may generate corresponding revocation information. The revocation information may comprise the token identity 47 of the token 40 to be revoked. Then, the central unit 10 may include corresponding revocation information into a revocation list 48 of a first token 40 that is not to be revoked.

In step 112, the mobile unit 20 may request transmission of a token 40 for the secured object 20. In response, in step 113, the central unit transmit the first token 40 including the revocation information in the revocation list 48 to the mobile unit 20. After the reception of the token 40, in step 114, the mobile unit 20 may update its token store with the newly received token 40. When the mobile unit wants to get permission to execute one or more commands 42 on the secured object 10, it may select the token in step 115. In step 116a, the mobile unit 20 may then establish a connection with the secured object 30. Afterwards, in step 116b, the mobile unit 20 may transmit the token 40 to the secured object 30 followed by a verification of the token 40 by the secured object 30. A possible way for transmitting and verifying the token according to step 116b is explained in more detail with respect to Figure 12. If the transmission and verification is successful, in step 116c, the secured object 30 may store the revocation information. In step n6d, the secured object 30 may generate a revocation

confirmation and may sign it using its private key 36. After signing, the secured object 30 may transmit the signed revocation confirmation to the mobile unit 30. In step 117, the mobile unit 20 may cache the received revocation confirmation and may then transmit the revocation confirmation to the central unit 10 in step 118. The central unit 10 may then use the public key 34 of the secured object to verify the correct

transmission of the revocation confirmation. In step 119, the central unit 10 may store the revocation information.

If the revoked second token 40 is now transmitted to the secured object 30, the secured object 30 may determine based on the stored revocation information that may include the token identity 47 of the revoked second token 40 that the second token 40 may not be any more permit to execute the one or more commands 42 included in the second token 40. Thus, the execution of the one or more commands 42 may be blocked and/or denied.

In step 119a, the operator backend 13 may request status information from the central unit 10 about the status of at least a part of the process 110. For example, the operator backend 13 may request status information about the execution of each of the steps 111, 112, 113, 114, 115, 116a, 116b, 116c, n6d, n6e, 117, 118, 119, 119a and/or 119b of process 110.

Figure 12 illustrates the process 120 of the communication between a mobile unit 20 and a secured object 30 according to an aspect of the present invention. In step 121a, the mobile unit 20 may transmit a number of protocols to the secured object 30 that it supports. Then, in step 121b, the mobile unit 20 may transmit the supported protocols. In response, in step 121c, the secured object 30 may transmit a selected protocol supported by the secured object 30 so that that mobile unit 20 and the secured object 30 may communicate with each other based on that protocol.

The following steps i22a-j, process 122k and steps i23a-e exemplarily outline one of the supported protocols.

In step 122a, the mobile unit 20 may transmit the signature algorithm that has been used to sign the token 40 that shall be used to permit the mobile unit 20 permission to execute one or more commands 42 on the secured object 30. Afterwards, in step 122b, the mobile unit 20 may transmit the token 40 to the secured object 30, wherein the token 40 may have been signed with the private key 16 of the central unit 10, denoted as privKeyCU in Figure 12. The token 40 to be transmitted may be selected

automatically. If more than one token 40 exists, the token 40 may be selected that has been generated last. Also a manual selection may be possible. Then, the one or more commands 42 of the token 40 are transmitted to the secured object 30 followed by steps I22d and I22e in which the mobile unit 20 may transmit extensions and parameters and/or data relating to the one or more commands 42. Both steps i22d and i22e may be looped until all extensions and parameters and/or data have been transmitted to the secured object 30. After successful transmission of all extensions and parameters and/or data, in step i22f, the mobile unit 20 may transmit a signal to the secured object 30 indicating that no more extensions will be transmitted. Then, in step I22g, the mobile unit 20 may transmit a randomly or pseudo-randomly generated nonce to the secured object 30. In response, in step 122I1, the secured object 30 may transmit a randomly or pseudo-randomly generated nonce back to the mobile unit 20. The nonces may serve to prevent man-in-the-middle attacks. Once the nonce is received by the mobile unit 20 from the secured object 30, the mobile unit may calculate a signature with respect to the data that have been transmitted in steps 122c- h. The signature is calculated based on the private key 26 of the mobile unit 20, denoted as privKeyMU in Figure 12. After successful calculation, the mobile unit 20 transmits the signature to the secured object 30 in step i22j. In process 122k, the secured object 30 may validate the signature using the public key 24 that may be included in the transmitted token 40. Due to the validated signature, no non-validated data may be parsed. For example, the validation may avoid that malicious code is injected into secured object 30. If the signature is verified successfully, the secured object 30 may execute the one or more commands 42 that have been transmitted previously.

To further improve security, the signature 46 based on the private key 16 of the central unit may be verified by the secured object 30 using the public key 14 of the central unit 10. With respect to this verification, the nonces are not considered.

After a successful verification, the mobile unit 20 may be identified.

In step 123a, the secured object 30 may transmit an authorization to the mobile unit 20 which may serve as a confirmation, followed by a transmission of a response code in step 123b. The authorization may indicate whether a token 40 is valid or not. For example, a token 40 may be considered as invalid if it has been revoked, if it is not yet valid, if it includes an unauthorized command 42 and/or if it is not assigned to the secured object 30 to which it has been transmitted. The response code may vary between different types of implementations of the system 1 and may be implemented in form of a return value, wherein the number of possible return values may vaiy between o - 255. The response code may for example indicate that a specific command 42 has been successfully executed.

Then, the secured object 30 may transmit an extension information to the mobile unit 20 in step 123c, followed by a transmission of parameters and/or data in step 123d. Steps i23c-d may be repeated until all extensions and parameters and/or data are transmitted to the mobile unit 20. If all extensions, parameters and/or data have been transmitted, the secured object 30 may transmit in step i23e a signal to the mobile unit 20 that indicates that no more extensions, parameters and/or data will be transmitted. Providing the communication of extension in the above described manner, the central unit 10 may be able to receive revocation information without having to establish an additional communication channel with the secured object 30 which may improve efficiency.

Figure 13 illustrates a signed token 40 and a signed response according to an aspect of the present invention. As shown, the token 40 may comprise the public key 45 of a mobile unit 20 in its payload, denoted as pubKeyMU in Figure 13. The payload of token 40 may be signed with the private key 16 of the central unit, denoted as privKeyCU in Figure 13. The token 40 as well as the signature 46 may be signed with the private key 26 of the mobile unit 20, denoted as privKeyMU in Figure 13.

A response transmitted from the secured object 30 to the mobile unit 20 or to the gateway 50 may be signed with the private key 36 of the secured object 30, denoted as privKeySO in Figure 13.

Figure 14 illustrates a key store 140 of a mobile unit 20 according to an aspect of the present invention. A mobile unit 20 of the present invention may be operated by iOS™ 8 or later versions provided by Apple® Inc. The Keychain of iOS™ is the designed place to store user specific sensitive key material protected on devices that run iOS™ 8 or later versions. Additionally, an iPhone® only allows apps to run on the device that are checked, allowed and signed by Apple®. iOS™ 8 Keychain features:

· Keychain is implemented in TEE of ARM® CPU

• Trust Manager is gate keeper to Keychain

• Checks signature of developer & Apple®

• Every app gets separate compartment

• Checks user fingerprint and passcode

· Authorizes app to access private key

• Content is protected against copying, backing up and migrating to another

device

Figure 15 illustrates a further key store 150 of a mobile unit 20 according to an aspect of the present invention. A mobile unit 20 of the present invention may be operated by Android™ 5 or later versions.

Android™ Hardware Backed Credential Store is the designed place to store user specific sensitive key material protected on devices operated by Android™ 5 or later versions.

Features provided by Android™ Hardware Backed Credential Store (AHBCS):

• AHBCS is implemented in TEE of ARM® CPU providing hardware security.

• A Crypto Engine (SE Linux) is the only interface to the keys in the TEE storage

• Like on a Smartcard, private Keys are secured behind the Crypto Engine in TEE

• All crypto operations like private key generation, signing etc. are done in TEE

• SE Linux grants access to TEE only to generating app

• Private keys are protected against copying, backup and migrating to another device

Figure 16 illustrates the structure of a central unit 10 according to an aspect of the present invention. The central unit 10 implements several barriers to mitigate attacks from hackers. It may be able to securely communicate with the operator backend 13, with a mobile unit 20 and a secured object 30. The central unit 10 may act as a trust center. The trust center (functioning as a central database) may generate digital access authorizations, the so-called tokens 40. Generating a token 40 may be compared to cutting a conventional key. In other words, the trust center may generate digital keys for a user.

Furthermore, the trust center may be the starting point and may allow customers to easily connect to their own back-end or booking system. The trust center may be, as the name implies, a centralized and trustworthy authority that may issue all authorizations and may transmit them in encrypted form to smartphones.

The trust center may be linked to customer-specific back-ends and/or booking systems. This way, all business data may remain in the systems of the operator. The operator's specific back-end may be connected via an operator API, a specialized interface. This interface makes it possible to utilize the customer-internal business logic of the operator back-end during the automated generation and management of electronic authorizations. Therefore, it is possible not only to integrate system l into systems such as SAP or Siebel, but also into car hire or parking facility management systems.

The operator API may support the following core functionalities: · Generation of tokens 40 in the trust center

• Issuance of a list of all tokens ever generated

• Issuance of a list of the operator’s own secured objects 30

• Revocation of tokens 40 in the trust center

The interface may be RESTful. This allows it to be interoperable with almost all modern programing languages.

The following table provides a comparison of X.509 certificates and the tokens 40 according to the present invention.

The method steps of the processes described herein may be implemented in software, in hardware or in a combination of hardware and software. In addition, all components may be implemented in software, in hardware or in a combination of hardware and software.

Claims

Claims 1 - 129 l. A system (l) for providing authentication and/or authorization, comprising: a central unit (10) configured to generate and transmit a token (40) that permits execution of a command (42) by a secured object (30);

a mobile unit (20) configured to receive the token (40) transmitted by the central unit (10) and to transmit the token (40) to the secured object (30);

wherein the token (40) comprises a public key (45) of the mobile unit (20).

2. The system (1) according to claim 1, wherein the token (40) further comprises a signature (46) based on a private key of the central unit (10) usable for checking the integrity of the token (40). 3. The system (1) according to claim 2, wherein the secured object (30) is configured to perform an integrity check based on the signature (46) and/or wherein the secured object (30) is further configured to deny execution of the command (42) if the integrity check is not successful.

4. The system (1) according to any of the claims 2 - 3, wherein the signature (46) is based on a ciyptographic signature system and/or wherein the signature (46) covers at least a part of the token (40).

5. The system (1) according to any of the claims 2 - 4, wherein a parser of the

secured object (30) only parses the token (40) after a successfully validation of the signature (46). 6. The system (1) according to any of the claims 2 - 5, wherein the mobile unit (20) is further configured to sign the token (40) with a private key (26) of the mobile unit (20).

7 The system (1) according to claim 6, wherein signing the token (40) with the private key (26) of the mobile unit (20) is based on a first nonce transmitted from the mobile unit (20) to the secured object (30) and on a second nonce transmitted from the secured object (30) to the mobile unit (20).

8. The system (1) according to any of the preceding claims, wherein the token (40) comprises the command (42). 9. The system (1) according to any of the preceding claims, wherein the command

(42) is an unlock command configured for unlocking the secured object (30).

10. The system (1) according to any of the preceding claims, wherein the token (40) further comprises a mobile unit identity (44) usable for identifying the mobile unit (20). li. The system (l) according to any of the preceding claims, wherein the token (40) further comprises a secured object identity (43) usable for identifying the secured object (30).

12. The system (1) according to any of the preceding claims, wherein the token (40) further comprises a validity time (41) indicating a time span in which the authorization to execute the command (42) on the secured object (30) is valid.

13· The system (1) according to any of the preceding claims, wherein the token (40) further comprises a token identity (47) usable for identifying the token (40).

14· The system (1) according to any of the preceding claims, wherein the secured object (30) is further configured to receive a revocation list (48), wherein the revocation list (48) comprises a mobile unit identity (22) and/or a token identity (47)·

15. The system (1) according to claim 14, wherein the revocation list (48) is included in the token (40) received from the mobile unit (20) and/or included in a message received from a gateway (50). 16. The system (1) according to any of the claims 14 - 15, wherein the secured object

(30) is further configured to deny the execution of a command (42) included in a second token (40) if a mobile unit identity (44) in the revocation list (48) corresponds to a mobile unit identity (44) included in the second token (40) and/or if a token identity (47) in the revocation list (48) corresponds to a token identity (47) included in the second token (40).

17. The system (1) according to any of the claims 14 - 16, wherein the mobile unit (20) is further configured to receive a revocation confirmation from the secured object (30) if the token (40) comprises the revocations list (48) and if the token

(40) is successfully transmitted to the secured object (30) and/or wherein the mobile unit (20) is configured to transmit the revocation confirmation to the central unit (10).

18. The system (1) according to claim 17, wherein the secured object (30) is further configured to sign the revocation confirmation with a private key (36) of the secured object (30) and/or wherein the secured object (30) is further configured to transmit (2) a public key (34) of the secured object (30) to the central unit (10), wherein the public key (34) is usable by the central unit (10) to verify the integrity of the revocation conformation.

19. The system (1) according to any of the claims 17 - 18, wherein the secured object (30) is further configured to refrain from transmitting revocation confirmations to the mobile unit (20) if the secured object (30) was instructed accordingly by the mobile unit (20).

20. The system (1) according to any of the preceding claims, wherein the central unit (10) is further configured to encrypt the token (40) at least in part.

21. A central unit (10) configured to receive a public key (24) of a mobile unit (20), to receive (5) a request to generate a token (40), to generate the token (40) comprising the public key (24) of the mobile unit (20) and to transmit (6) the token (40).

22. The central unit (10) according to claim 21, wherein the central unit (10) is

further configured to generate a signature (46) based on a private key of the central unit (10), wherein the signature (46) is usable for checking the integrity of the token (40).

23. The central unit (10) according to any of the claims 21 - 22, wherein the central unit (10) is further configured to insert a command (42) into the token (40) based on the request.

24. The central unit (10) according to any of the claims 21 - 23, wherein the

command (42) is an unlock command usable for unlocking a secured object (30).

25. The central unit (10) according to any of the claims 21 - 24, wherein the request is received from the mobile unit (20) and/or from a third-party unit (60).

26. The central unit (10) according to any of the claims 21 - 25, wherein the token (40) further comprises a mobile unit identity (44) usable for identifying the mobile unit (20).

27. The central unit (10) according to any of the claims 21 - 26, wherein the token (40) further comprises a secured object identity (43) usable for identifying the secured object (30).

28. The central unit (10) according to any of the claims 21 - 27, wherein the token (40) further comprises a validity time (41) indicating a time span in which an authorization to execute the command (42) on the secured object (30) is valid.

29. The central unit (10) according to any of the claims 21 - 28, wherein the token (40) further comprises a token identity (47) usable for identifying the token (40).

30. The central unit (10) according to any of the claims 21 - 29, wherein the central unit (10) is further configured to transmit a revocation list (48) to the secured object (30).

3i· The central unit (10) according to claim 30, wherein the revocation list (48) is included in the token (40) and transmitted to the secured object (30) via the mobile unit (20) and/or wherein the revocation list is transmitted in a message to the secured object (30) via a gateway (50).

32. The central unit (10) according to any of the claims 30 - 31, wherein the

revocation list (48) comprises a token identity (47) of a second token (40) and/or a mobile unit identity (44).

33. The central unit (10) according to any of the claims 30 - 32, wherein the central unit (10) is further configured to receive a revocation confirmation when the revocation list (48) is successfully received by the secured object (30).

34 The central unit (10) according to claim 33, wherein the revocation confirmation is received from the gateway (50) or from the mobile unit (20).

35. The central unit (10) according to any of the claims 33 - 34, wherein the

revocation confirmation is signed by the secured object (30) with a private key (36) of the secured object (30), and/or wherein a public key (34) of the secured objected (30) is transmitted to the central unit (10), wherein the public key (34) of the secured object (30) is usable by the central unit (10) to verify the integrity of the revocation confirmation.

36. The central unit (10) according to any of the claims 21 - 35, wherein the central unit (10) is configured to encrypt the token (40) at least in part.

37. A mobile unit (20) configured to receive a token (40), wherein the token (40) comprises a public key (24) of the mobile unit (20) and wherein the mobile unit (20) is further configured to transmit the token (40) to a secured object (30).

38. The mobile unit (20) according to claim 37, wherein the mobile unit (20) is further configured to transmit (3) the public key (24) to a central unit (10). 39. The mobile unit (20) according to any of the claims 37 - 38, wherein the mobile unit (20) is further configured to generate a private-public key pair and to securely store at least the private key (26) of said key pair.

40. The mobile unit (20) according to any of the claims 38 - 39, wherein the mobile unit (20) is further configured to request a token (40) from the central unit (10). 41. The mobile unit (20) according to any of the claims 37 - 40, wherein the mobile unit (20) is further configured to receive a revocation confirmation from the secured object (30) in response to transmitting a revocation list (48) to the secured object (30).

42. The mobile unit (20) according to claim 41, wherein the mobile unit (20) is further configured to transmit the revocation confirmation to the central unit (10) and/or wherein the revocation confirmation is signed by the secured object (30) with a private key (36) of the secured object (30). 43. The mobile unit (20) according to any of the claims 41 - 42, wherein the

revocation confirmation comprises a token identity (47) of a second token (40) and/or wherein the revocation confirmation comprises a mobile unit identity (22).

44. The mobile unit (20) according to any of the claims 37 - 43, wherein the mobile unit (20) is further configured to receive (8) a challenge of a challenge-response process from the secured object (30) in response to transmitting the token (40) to the secured object (30).

45. The mobile unit (20) according to claim 44, wherein the mobile unit (20) is

further configured to generate a response in reply to the challenge and to transmit (9) the response to the secured object (30).

46. The mobile unit (20) according to claim 45, wherein generating the response comprises signing the received challenge with the private key (26) of the mobile unit (20).

47. A secured object (30), configured to receive a token (40) from a mobile unit (20), wherein the token (40) comprises a public key (24) of the mobile unit (20), and wherein the secured object (30) is configured to execute a command (42) if it is determined by the secured object (30) that the execution of the command is permitted by the first token (40). 48. The secured object (30) according to claim 47, wherein determining that the token (40) permits the execution of the command (42) comprises generating a challenge of a challenge-response process.

49. The secured object (30) according to claim 48, wherein the challenge is generated by the secured object (30) based on a random or pseudo-random algorithm.

50. The secured object (30) according to any of the claims 48 - 49, wherein the challenge is transmitted to the mobile unit (20) in response to receiving (7) the token (40).

51. The secured object (30) according to any of the claims 48 - 50, wherein the

secured object (30) is configured to verify a response according to the challenge- response process received from the mobile unit (20).

52. The secured object (30) according to claim 51, wherein verifying the response is based on the public key (45) of the mobile unit (20).

53. The secured object (30) according to any of the claims 47 - 52, wherein the

secured object (30) is further configured to validate the token (40) based on the public key (14) of the central unit (10).

54. The secured object (30) according to claim 53, wherein validating comprises using the public key (14) of the central unit (10) to verify that the token (40) is not corrupted and/or that the token (40) has not been modified during transmission. 55· The secured object (30) according to any of the claims 47 - 54, wherein the

command (42) is an unlock command usable to unlock the secured object (30) and/or wherein the command (42) is included in the token (40).

56. The secured object (30) according to any of the claims 47 - 55, wherein the

secured object (30) is further configured to retrieve a revocation list (48) and wherein the revocation list (48) comprises a mobile unit identity (22) and/or a token identity (47).

57. The secured object (30) according to claim 56, wherein the revocation list (48) is included in the token (40) received from the mobile unit (20) and/or included in a message received from a gateway (50).

58. The secured object (30) according to claim 56 - 57, wherein the secured object (30) is further configured to deny the execution of a command (42) included in a second token (40) if a mobile unit identity (44) in the revocation list (48) corresponds to the mobile unit identity (44) included in the second token (40). 59 The secured object (30) according to claim 57 - 58, wherein the secured object (30) is further configured to transmit a revocation confirmation to the mobile unit (20) or to the gateway (50) and/or wherein the revocation confirmation comprises a signature based on a private key (36) of the secured object (30). 60. The secured object (30) according to claim 59, wherein the secured object (30) is further configured to transmit (2) a public key (34) of the secured object (30) to the central unit (10).

The secured object (30) according to claims 47 - 60, wherein the secured object (30) is a car, an autonomously driving car, an airplane and/or a drone.

62. A token (40) usable in a system (1) for providing authentication and/or

authorization, comprising a public key (45) of a mobile unit (20), wherein the token (40) is configured for permitting execution of a command (42) on a secured object (30). 63. The token (40) according to claim 62, wherein the public key (45) of the mobile unit (20) is stored in the token (40) by a central unit (10).

64. The token (40) according to claim 63, further comprising one or more of:

- one or more commands (42)

- a validity time (41) indicating a time span in which the command (42) is permitted to be executed by the secured object (30)

- a secured object identity (43) usable for identifying the secured object (30)

- a mobile unit identity (44) usable for identifying the mobile unit (20)

- a signature (46) based on a private key (16) of the central unit (10)

- a token identity (47) usable for identifying the token (40)

- a revocation list (48) including one or more token identities (47).

65. Using a system (1) according to any of the claims 1 - 20.

66. Using a central unit (10) according to any of the claims 21 - 36.

67. Using a mobile unit (20) according to any of the claims 37 - 46.

68. Using a secured object (30) according to any of the claims 47 - 61 and/or a token according to any of the claims 62 - 64.

69. A method for providing authentication and/or authorization comprising the steps of:

generating and transmitting, by a central unit (10), a token (40) that permits execution of a command (42) by a secured object (30);

receiving, by a mobile unit (20), the token (40) transmitted by the central unit (10) and transmitting, by the mobile unit (20), the token (40) to the secured object (30), wherein the token (40) comprises a public key (45) of the mobile unit (20).

70. The method according to claim 69, further comprising the step of checking the integrity of the token (40) based on a signature (46), the signature (46) based on a private key of the central unit (10).

71. The method according to claim 70, further comprising the steps of performing, by the secured object (30), an integrity check based on the signature (46) and/or denying, by the secured object (30), executing the command (42) if the integrity check is not successful.

72. The method according to any of the claims 70 - 71, wherein the signature (46) is based on a ciyptographic signature system and/or wherein the signature (46) covers at least a part of the token (40).

73. The method according to any of the claims 70 - 72, further comprising the step of only parsing, by the secured object (30), the token (40) after successfully validating the signature (46).

74. The method according to any of the claims 69 - 73, further comprising the step of signing, by the mobile unit (20), the token (40) with a private key (26) of the mobile unit (20).

75. The method according to claim 74, further comprising the steps of:

transmitting, from the mobile unit (20) to the secured object (30), a first nonce; and transmitting, from the secured object (30) to the mobile unit (20), a second nonce, wherein signing the token (40) with the private key (26) of the mobile unit (20) is based on the first nonce and on the second nonce.

76. The method according to claims 69 - 75, wherein the token (40) comprises the command (42). 77. The method according to claims 69 - 76, wherein the command (42) is an unlock command, the method further comprising the step of unlocking the secured object (30) by executing the command (42) by the secured object (30).

78. The method according to claims 69 - 77, wherein the token (40) further

comprises a mobile unit identity (44) usable for identifying the mobile unit (20). 79. The method according to claims 69 - 78, wherein the token (40) further

comprises a secured object identity (43) usable for identifying the secured object (30).

80. The method according to claims 69 - 79, wherein the token (40) further

comprises a validity time (41) indicating a time span in which the authorization to execute the command (42) on the secured object (30) is valid.

81. The method according to claims 69 - 80, wherein the token (40) further

comprises a token identity (47) usable for identifying the token (40).

82. The method according to claims 69 - 81, further comprising the step of receiving, by the secured object (30), a revocation list (48), wherein the revocation list (48) comprises a mobile unit identity (22) and/or a token identity (47).

83. The method according to claim 82, further comprising the steps of including the revocation list (48) in the token (40) received from the mobile unit (20) and/or including the revocation list (48) in a message received from a gateway (50).

84. The method according to any of the claims 82 - 83, further comprising the steps of:

determining, by the secured object (30), if a mobile unit identity (44) in the revocation list (48) corresponds to a mobile unit identity (44) included in a second token (40) and/or if a token identity (47) in the revocation list (48) corresponds to a token identity (47) included in the second token (40); and denying, by the secured object (30), the execution of a command (42) included in the second token (40), if the mobile unit identity (44) in the revocation list (48) corresponds to the mobile unit identity (44) included in the second token (40) and/or if the token identity (47) in the revocation list (48) corresponds to the token identity (47) included in the second token (40).

85. The method according to any of the claims 82 - 84, further comprising the steps of:

receiving, by the mobile unit (20), a revocation confirmation from the secured object (30) if the token (40) comprises the revocations list (48) and if the token (40) is successfully transmitted to the secured object (30); and /or

transmitting, by the mobile unit (20), the revocation confirmation to the central unit (10).

86. The method according to claim 85, further comprising the steps of:

signing, by the secured object (30), the revocation confirmation with a private key (36) of the secured object (30); and/or

transmitting (2), by the secured object (30), a public key (34) of the secured object (30) to the central unit (10), wherein the public key (34) is usable by the central unit (10) to verify the integrity of the revocation conformation.

87. The method according to any of the claims 85 - 86, further comprising the step of refraining, by the secured object (30), from transmitting the revocation confirmations to the mobile unit (20) if the secured object (30) was instructed accordingly by the mobile unit (20).

88. The method according to any of the claims 69 - 87, further comprising the step of encrypting, by the central unit (10), the token (40) at least in part.

89. A method for operating a central unit (10) comprising the steps of:

receiving, by the central unit (10), a public key (24) of a mobile unit (20);

receiving, by the central unit (10), a request to generate a token (40);

generating, by the central unit (10), the token (40), the token (40) comprising the public key (24) of the mobile unit (20); and

transmitting (6), by the central unit (10), the token (40).

90. The method according to claim 89, further comprising the step of generating, by the central unit (10), a signature (46) based on a private key of the central unit (10), wherein the signature (46) is usable for checking the integrity of the token (40). 91. The method according to any of the claims 89 - 90, further comprising the step of inserting, by the central unit (10), a command (42) into the token (40) based on the request.

92. The method according to any of the claims 89 - 91, wherein the command (42) is an unlock command usable for unlocking a secured object (30).

93. The method according to any of the claims 89 - 92, wherein the request is

received from the mobile unit (20) and/or from a third-party unit (60).

94. The method according to any of the claims 21 - 25, further comprising the step of inserting, by the central unit (10), a mobile unit identity (44) into the token (40) usable for identifying the mobile unit (20). 95. The method according to any of the claims 89 - 94, further comprising the step of including a secured object identity (43) into the token (40) usable for identifying the secured object (30).

96. The method according to any of the claims 89 - 95, further comprising the step of inserting, by the central unit (10), a validity time (41) into the token (40), the validity time (41) indicating a time span in which an authorization to execute the command (42) on the secured object (30) is valid.

97. The method according to any of the claims 89 - 96, further comprising the step of inserting, by the central unit (10), a token identity (47) usable for identifying the token (40).

98. The method according to any of the claims 89 - 97, further comprising the step of transmitting, by the central unit (10), a revocation list (48) to the secured object (30). 99 The method according to claim 98, further comprising the steps of:

inserting, by the central unit (10) the revocation list (48) into the token (40) and transmitting, by the central unit (10), the token (40) to the secured object (30) via the mobile unit (20); and/or

transmitting, by the central unit (10), the revocation list (48) in a message to the secured object (30) via a gateway (50).

100. The method according to any of the claims 98 - 99, further comprising the step of inserting, by the central unit (10), a token identity (47) of a second token (40) and/or a mobile unit identity (44) into the revocation list (48). 101. The method according to any of the claims 98 - 100, further comprising the step of receiving, by the central unit (10), a revocation confirmation when the revocation list (48) is successfully received by the secured object (30).

102. The method according to claim 101, wherein the revocation confirmation is

received from the gateway (50) or from the mobile unit (20); and/or wherein the revocation confirmation is signed by the secured object (30) with a private key

(36) of the secured object (30).

103. The method according to any of the claims 101 - 102, further comprising the steps of:

receiving, by the central unit (10), a public key (34) of the secured objected (30); and

verifying, by the central unit (10), the integrity of the revocation confirmation via the public key (34) of the secured object.

104. The method according to any of the claims 89 - 103, further comprising the step of enciypting, by the central unit (10), the token (40) at least in part. 105. A method for operating a mobile unit (20) comprising the steps of:

receiving, by the mobile unit (20), a token (40), wherein the token (40) comprises a public key (24) of the mobile unit (20); and

transmitting, by the mobile unit (20), the token (40) to a secured object (30).

106. The method according to claim 105, further comprising the step of transmitting, by the mobile unit (20), the public key (24) to a central unit (10).

107. The method according to any of the claims 105 - 106, further comprising the step of generating, by the mobile unit (20), a private-public key pair; and

securely storing, by the mobile unit (20), at least the private key (26) of said key pair.

108. The method according to any of the claims 106 - 107, further comprising the step of requesting, by the mobile unit (20), a token (40) from the central unit (10).

109. The method according to any of the claims 105 - 108, further comprising the step of receiving, by the mobile unit (20), a revocation confirmation from the secured object (30) in response to transmitting a revocation list (48) to the secured object (30).

110. The method according to claim 109, further comprising the steps of:

transmitting, by the mobile unit (20), the revocation confirmation to the central unit (10); and/or

wherein the revocation confirmation is signed by the secured object (30) with a private key (36) of the secured object (30).

111. The method according to any of the claims 109 - 110, wherein the revocation confirmation comprises a token identity (47) of a second token (40) and/or wherein the revocation confirmation comprises a mobile unit identity (22).

112. The method according to any of the claims 105 - 111, further comprising the step of receiving (8), by the mobile unit (20), a challenge of a challenge-response process from the secured object (30) in response to transmitting the token (40) to the secured object (30).

113. The method according to claim 112, further comprising the steps of:

generating, by the mobile unit (20), a response in reply to the challenge; and transmitting (9), by the mobile unit (20), the response to the secured object (30).

114. The method according to claim 113, wherein the step of generating the response comprises the step of signing the received challenge with the private key (26) of the mobile unit (20).

115. A method for operating a secured object (30) comprising the steps of:

receiving, by the secured object (30), a token (40) from a mobile unit (20), wherein the token (40) comprises a public key (24) of the mobile unit (20);

determining, by the secured object (30), that an execution of a command is permitted by the first token (40); and

executing, by the secured object (30), the command (42) if it is determined by the secured object (30) that the execution of the command is permitted by the first token (40).

116. The method according to claim 115, wherein the step of determining that the token (40) permits the execution of the command (42) comprises the step of generating a challenge of a challenge-response process. 117· The method according to claim 116, further comprising the step of generating, by the secured object (30), the challenge based on a random or pseudo-random algorithm.

118. The method according to any of the claims 116 - 117, further comprising the step of transmitting, by the secured object (30), the challenge to the mobile unit (20) in response to receiving (7) the token (40).

119. The method according to any of the claims 116 - 118, further comprising the step of verifying, by the secured object (30), a response according to the challenge- response process received from the mobile unit (20).

120. The method according to claim 119, wherein the step of verifying the response is based on the public key (45) of the mobile unit (20).

121. The method according to any of the claims 115 - 120, further comprising the step of validating, by the secured object (30), the token (40) based on the public key (14) of the central unit (10).

122. The method according to claim 121, wherein the step of validating further comprises the step of using the public key (14) of the central unit (10) to verify that the token (40) is not corrupted and/or that the token (40) has not been modified during transmission. 123. The method according to any of the claims 115 - 122, wherein the command (42) is an unlock command usable to unlock the secured object (30) and/or wherein the command (42) is included in the token (40).

124. The method according to any of the claims 115 - 123, further comprising the step of retrieving, by the secured object (30), a revocation list (48), wherein the revocation list (48) comprises a mobile unit identity (22) and/or a token identity (47)·

125. The method according to claim 124, wherein the revocation list (48) is included in the token (40) received from the mobile unit (20) and/or included in a message received from a gateway (50). 126. The method according to claim 124 - 125, further comprising the step of denying, by the secured object (30), the execution of a command (42) included in a second token (40) if a mobile unit identity (44) in the revocation list (48) corresponds to the mobile unit identity (44) included in the second token (40).

127. The method according to claim 125 - 126, further comprising the step of

transmitting, by the secured object (30), a revocation confirmation to the mobile unit (20) or to the gateway (50) and/or wherein the revocation confirmation comprises a signature based on a private key (36) of the secured object (30).

128. The method according to claim 127, further comprising the step of transmitting (2), by the secured object (30), a public key (34) of the secured object (30) to the central unit (10).

129. A computer program comprising instructions for performing a method of any of the claims 69 - 88, 89 - 104, 105 - 114 and/or 115 - 128.