EP3732843A1 - Systèmes et procédés permettant de fournir une authentification et/ou une autorisation - Google Patents

Systèmes et procédés permettant de fournir une authentification et/ou une autorisation

Info

Publication number
EP3732843A1
EP3732843A1 EP17832245.9A EP17832245A EP3732843A1 EP 3732843 A1 EP3732843 A1 EP 3732843A1 EP 17832245 A EP17832245 A EP 17832245A EP 3732843 A1 EP3732843 A1 EP 3732843A1
Authority
EP
European Patent Office
Prior art keywords
token
secured object
mobile unit
central unit
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP17832245.9A
Other languages
German (de)
English (en)
Inventor
Kai Römer
Philipp Paul Spangenberg
Andreas Schmid
Maximilian WAHLER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Blueid GmbH
Original Assignee
Blueid GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Blueid GmbH filed Critical Blueid GmbH
Publication of EP3732843A1 publication Critical patent/EP3732843A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H04W12/43—Security arrangements using identity modules using shared identity modules, e.g. SIM sharing

Definitions

  • the present invention relates to systems and methods for providing authentication and/or authorization.
  • the ownership of a physical key provides the right to unlock an object.
  • 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.
  • 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.
  • an electronic locking system is particularly useful if a plurality of users participate in such a system.
  • 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.
  • security-sensitive data has to be transmitted between a plurality of components operated in an electronic locking system.
  • 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.
  • the electronic device has to be configured to be able to act as a key.
  • 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.
  • 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 necerney 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.
  • the flexibility of electronic locking systems may suffer when applying cryptographic mechanisms.
  • 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.
  • 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.
  • AES Advanced Encryption System
  • symmetric cryptosystems like the aforementioned AES are commonly utilized.
  • 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.
  • 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.
  • X.509 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.
  • X.509 certificates requires the operation of or at least the cooperation with a trusted authority.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the token combined with the mobile unit may be considered as a key usable for getting access to the secured object.
  • 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.
  • a mobile unit may for example be a smartphone or any other portable electronic device.
  • the mobile unit may be a vehicle like a drone, a car, an autonomously driving car, a robot or an autonomously acting craft.
  • 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.
  • 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
  • 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.
  • the public key in the token may relieve the secured object from the burden of storing all the public keys of the electronic units.
  • 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.
  • the token may further comprise a signature based on a private key of the central unit usable for checking the integrity of the token.
  • 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.
  • 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.
  • 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.
  • a malicious third-party e.g. a hacker
  • 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.
  • the mobile unit is further configured to sign the token with a private key of the mobile unit.
  • 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.
  • 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.
  • one or more nonces may be transmitted between the mobile unit and the secured object.
  • 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.
  • the token may comprise the command, wherein the command may be an unlock command configured for unlocking the secured object.
  • the command may be specified within the token. This may allow the system to support a plurality of different commands on the secured object.
  • the command may be a command for unlocking the secured object.
  • the command may further be suitable for starting the engine of the car.
  • the command may further be any kind of command useable for controlling the secured object.
  • a plurality of commands may be included in the token.
  • 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.
  • 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.
  • the token may comprise a token identity that may allow to identify a token among a plurality of tokens.
  • 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.
  • 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.
  • a plurality of tokens issued for said specific mobile unit may be revoked at once.
  • 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.
  • 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.
  • the token 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.
  • a direct communication channel between the central unit and the secured object which may utilize a gateway like an internet router etc.
  • a direct gateway-based communication channel may ensure a fast delivery of the revocation list to the intended secured object.
  • 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.
  • 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.
  • 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.
  • a revocation confirmation e.g. in terms of a message
  • 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.
  • 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 unnec unfairy communications of revocation confirmations and thus may increase efficiency of the system.
  • the central unit may further be configured to encrypt the token at least in part.
  • 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
  • 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.
  • 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.
  • 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.
  • due to the signature it may not be possible to modify the token by the user of the mobile unit.
  • a hack or an eavesdropper may not compromise the content of the token during transmission.
  • 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 unnecaciy ciyptographic method has to be applied to the token.
  • 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.
  • the signature may increase security.
  • 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.
  • 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.
  • 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.
  • the one or more commands may grant
  • 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.
  • 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.
  • 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 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 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.
  • 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.
  • the token may comprise a token identity that may allow to identify a token among a plurality of tokens.
  • 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.
  • 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
  • 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.
  • 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.
  • the central unit may be configured to enciypt the token at least in part.
  • 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.
  • the mobile unit may be granted
  • 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.
  • 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.
  • 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.
  • the private key may be stored securely on the mobile unit, e.g. in a secured container file.
  • the private key may be stored securely in the credential store of an AndroidTM device or in the key chain of an iOSTM 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • the data of the token e.g. the validity time, the one or more commands etc.
  • 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.
  • 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.
  • the secured object may further be configured to transmit a public key of the secured object to the central unit.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method may further comprise the step of signing, by the mobile unit, the token with a private key of the mobile unit.
  • the method may further comprise one or more of the steps of:
  • the token may comprise the command.
  • the command may be an unlock command.
  • the method may further comprise the step of unlocking the secured object by executing the command by the secured object.
  • the token may further comprise a mobile unit identity usable for identifying the mobile unit.
  • the token may further comprise a secured object identity usable for identifying the secured object.
  • 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.
  • the token may further comprise a token identity usable for identifying the token.
  • 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.
  • 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.
  • the method may further comprise the step of
  • 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.
  • 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.
  • 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.
  • 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.
  • the method may further comprise the step of encrypting, by central unit, the token at least in part.
  • 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.
  • 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.
  • the method may further comprise the step of inserting, by the central unit, a command into the token based on the request.
  • the command may be an unlock command usable for unlocking a secured object.
  • the request may be received from the mobile unit and/or from a third-party unit.
  • 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.
  • the method may further comprise the step of including a secured object identity into the token usable for identifying the secured object.
  • 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.
  • the method may further comprise the step of inserting, by the central unit, a token identity usable for identifying the token.
  • the method may further comprise the step of transmitting, by the central unit, a revocation list to the secured object.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the method may further comprise the step of encrypting, by the central unit, the token at least in part.
  • 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
  • the method may further compris the step of transmitting, by the mobile unit, the public key to a central unit.
  • 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.
  • the method may further comprise the step of requesting, by the mobile unit, a token from the central unit.
  • 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.
  • 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.
  • the revocation confirmation may comprise a token identity of a second token and the revocation confirmation may comprise a mobile unit identity.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method may further comprise the step of generating, by the secured object, the challenge based on a random or pseudo-random algorithm.
  • 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.
  • 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.
  • the step of verifying the response may be based on the public key of the mobile unit.
  • the method may further comprise the step of validating, by the secured object, the token based on the public key of the central unit.
  • 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.
  • the command may be an unlock command usable to unlock the secured object and the command may be included in the token.
  • 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.
  • 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 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.
  • 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.
  • the method may further comprise the step of transmitting, by the secured object, a public key of the secured object to the central unit.
  • 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.
  • 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
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • the mobile unit 20 and the secured object 30 may also comprise such an identity 22, 32.
  • 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.
  • 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).
  • ECC elliptic curve ciyptosystem
  • 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.
  • 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.
  • 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.
  • the private keys 16, 26, 36 may never leave the respective unit 10, 20 or object 30.
  • 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.
  • 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
  • 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.
  • FIG. 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.
  • the secured object 30 may transmit its public key 34 to the central unit 10 using one of the above described networks.
  • the central unit 10 may store the public key 34, e.g. in the aforementioned database.
  • 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.
  • the central unit 10 may store the public key.
  • the public key 14 may be stored in an unsecure location.
  • 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.
  • the system 1 may be considered as initialized.
  • a further mobile unit 20 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.
  • a further secured object 30 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.
  • 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.
  • FIG. 2 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.
  • 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.
  • 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.
  • a third-party entity may transmit a request to the central unit 10.
  • a third-party request may comprise the mobile unit identity 22 of the mobile unit 20 to which authorization shall be granted.
  • 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.
  • FIG 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.
  • 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.
  • 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.
  • the secured object 30 may know which routine, process or mechanism to trigger in response to receiving the token 40.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the token 40 may comprise a signature 46 based on the private key 16 of the central unit 10.
  • 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.
  • an entity that holds the public key 14 of the central unit 10 may be able to detect the change of the payload.
  • 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.
  • the reception of a token 40 may authorize a mobile unit 20 to execute one or more commands 42 on a secured object 30.
  • 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.
  • the mobile unit 20 may transmit the token 40 to the secured object 30.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the lean architecture of system 1 may allow to implement the functions of the involved entities in software having small size.
  • 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.
  • 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
  • an operator may also be considered as an identity.
  • identities or operators
  • 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
  • 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.
  • FIG. 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.
  • 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.
  • API application programmer interface
  • 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.
  • 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.
  • step 62 the central unit 10 may communicate to the mobile unit 20 which
  • the 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.
  • the length of the keys may be communicated. This may allow dynamically changing the required key length during operation of the system 1.
  • 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.
  • step 64 the public key 24 of the mobile unit 20 is retrieved from the memory.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • the functionality implemented by the initialization service 11 may be implemented directly on the secured object 30 to be initialized.
  • 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.
  • the length of the keys may be communicated. This may allow dynamically changing the required key length during operation of the system 1.
  • 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.
  • step 74 the public key 34 is retrieved from the memory.
  • 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.
  • 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.
  • 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.
  • the central unit 10 may transmit the secured object identity 32 and the certificate to the initialization service 11.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the content may comprise a revocation list that may be encoded in 64 bytes.
  • 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.
  • the timestamp defines the time when the token 40 has been downloaded by a mobile unit 20.
  • 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.
  • FIG. 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.
  • an operator backend 13 may transmit a request to the central unit 10 the generate one or more tokens 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.
  • the central unit 10 may generate the one or more requested tokens 40.
  • 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.
  • 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.
  • the central unit 10 may transmit the one or more tokens 40 to the mobile unit 20.
  • 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.
  • 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.
  • 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.
  • 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.
  • the mobile unit 20 may select a token 40 of the received ones in step 95.
  • step 96a the mobile unit 20 may establish a connection, wireless or wire- based, with the secured object 30.
  • 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.
  • step 96c the secured object 30 may transmit an indication to the mobile unit 20 to indicate which protocol has been selected.
  • step 96d the mobile unit 20 may transmit one of the one or more tokens 40 to the secured object 30.
  • 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.
  • 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.
  • FIG. 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.
  • the operator backend 13 may transmit a request to the central unit 10 to request the revocation of a token 40.
  • 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.
  • a gateway 50 may request transmission of the revocation information.
  • the central unit 10 may transmit the revocation information to the gateway 50.
  • 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.
  • 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
  • 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.
  • the central unit to may store the revocation confirmation and/or may change the status of the revoked token 40 to“removed”.
  • 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.
  • 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.
  • the mobile unit 20 may request transmission of a token 40 for the secured object 20.
  • the central unit transmits the first token 40 including the revocation information in the revocation list 48 to the mobile unit 20.
  • the mobile unit 20 may update its token store with the newly received token 40.
  • 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.
  • the mobile unit 20 may then establish a connection with the secured object 30.
  • 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.
  • step 116c the secured object 30 may store the revocation information.
  • step n6d the secured object 30 may generate a revocation
  • the secured object 30 may transmit the signed revocation confirmation to the mobile unit 30.
  • 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
  • the central unit 10 may store the revocation information.
  • 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.
  • 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.
  • 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.
  • the mobile unit 20 may transmit a number of protocols to the secured object 30 that it supports.
  • the mobile unit 20 may transmit the supported protocols.
  • 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.
  • steps i22a-j, process 122k and steps i23a-e exemplarily outline one of the supported protocols.
  • 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.
  • 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
  • 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.
  • the mobile unit 20 may transmit a randomly or pseudo-randomly generated nonce to the secured object 30.
  • 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.
  • 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.
  • 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.
  • 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.
  • the mobile unit 20 may be identified.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG 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 iOSTM 8 or later versions provided by Apple® Inc.
  • the Keychain of iOSTM is the designed place to store user specific sensitive key material protected on devices that run iOSTM 8 or later versions. Additionally, an iPhone® only allows apps to run on the device that are checked, allowed and signed by Apple®.
  • 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 AndroidTM 5 or later versions.
  • AndroidTM Hardware Backed Credential Store is the designed place to store user specific sensitive key material protected on devices operated by AndroidTM 5 or later versions.
  • 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
  • FIG 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.
  • 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
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Lock And Its Accessories (AREA)

Abstract

La présente invention concerne un système permettant de fournir une authentification et/ou une autorisation. Le système comprend une unité centrale conçue pour générer et transmettre un jeton qui permet l'exécution d'une commande sur un objet sécurisé, une unité mobile conçue pour recevoir le jeton transmis par l'unité centrale et transmettre le jeton à l'objet sécurisé, le jeton comprenant une clé publique de l'unité mobile.
EP17832245.9A 2017-12-28 2017-12-28 Systèmes et procédés permettant de fournir une authentification et/ou une autorisation Withdrawn EP3732843A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2017/084756 WO2019129351A1 (fr) 2017-12-28 2017-12-28 Systèmes et procédés permettant de fournir une authentification et/ou une autorisation

Publications (1)

Publication Number Publication Date
EP3732843A1 true EP3732843A1 (fr) 2020-11-04

Family

ID=61005786

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17832245.9A Withdrawn EP3732843A1 (fr) 2017-12-28 2017-12-28 Systèmes et procédés permettant de fournir une authentification et/ou une autorisation

Country Status (2)

Country Link
EP (1) EP3732843A1 (fr)
WO (1) WO2019129351A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3726324B1 (fr) 2019-04-17 2023-03-01 Raytheon Technologies Corporation Passerelle de communication d'un moteur à turbine à gaz avec capteurs internes
EP3726480B1 (fr) * 2019-04-17 2024-09-25 RTX Corporation Mises à jour à distance d'un moteur à turbine à gaz
CN117178304A (zh) * 2021-04-08 2023-12-05 亚萨合莱有限公司 用于合并lacs认证的pacs修改

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4405829A (en) 1977-12-14 1983-09-20 Massachusetts Institute Of Technology Cryptographic communications system and method
JP4890248B2 (ja) * 2003-07-18 2012-03-07 コアストリート、 リミテッド 所定の区域へのアクセスの制御
PL1910134T3 (pl) 2005-07-19 2013-11-29 Blueid Gmbh System identyfikacyjny i/lub zamykający do identyfikacji i/lub odblokowania systemu technicznego oraz sposób jego pracy
SE529849C2 (sv) * 2006-04-28 2007-12-11 Sics Swedish Inst Of Comp Scie Accesstyrsystem och förfarande för att driva systemet
DE102015216630A1 (de) * 2015-08-31 2017-03-02 Baimos Technologies Gmbh Indirekter Berechtigungstransport
EP3244568B1 (fr) * 2016-05-13 2019-01-09 Talenta s.r.o. Système de verrouillage électronique

Also Published As

Publication number Publication date
WO2019129351A1 (fr) 2019-07-04

Similar Documents

Publication Publication Date Title
US10127377B2 (en) Mobile credential revocation
CN106452782B (zh) 为终端设备生成安全通信信道的方法和系统
US8064598B2 (en) Apparatus, method and computer program product providing enforcement of operator lock
US8724819B2 (en) Credential provisioning
US20140365781A1 (en) Receiving a Delegated Token, Issuing a Delegated Token, Authenticating a Delegated User, and Issuing a User-Specific Token for a Resource
US10771467B1 (en) External accessibility for computing devices
EP2721764B1 (fr) État de révocation utilisant d'autres justificatifs
JP6667371B2 (ja) 通信システム、通信装置、通信方法、及びプログラム
WO2006132597A1 (fr) Systemes, procedes et logiciels permettant d'autoriser un acces ponctuel
US10320774B2 (en) Method and system for issuing and using derived credentials
EP3813073A1 (fr) Méthode et système de sécurité des informations confidentielles
US9443069B1 (en) Verification platform having interface adapted for communication with verification agent
CN112513844A (zh) 用于处理和认证数字密钥的安全元件及其操作方法
US9323911B1 (en) Verifying requests to remove applications from a device
EP3732843A1 (fr) Systèmes et procédés permettant de fournir une authentification et/ou une autorisation
CN110311937B (zh) 数据转发系统
KR101078839B1 (ko) 이동단말에 대한 사용 제한 방법 및 이를 위한 이동단말
US20240129139A1 (en) User authentication using two independent security elements
CN111246480A (zh) 基于sim卡的应用通信方法、系统、设备及存储介质
US20220021547A1 (en) Digital method for controlling access to an object, a resource or service by a user
Kasper et al. Rights management with NFC smartphones and electronic ID cards: A proof of concept for modern car sharing
US20240223370A1 (en) Method for authentication of a service provider device to a user device
KR101737925B1 (ko) 도전-응답 기반의 사용자 인증 방법 및 시스템
WO2023228220A1 (fr) Authentification avec échange de justificatifs d'identité d'autorisation

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200727

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SPANGENBERG, PHILIPP PAUL

Inventor name: ROEMER, KAI

Inventor name: WAHLER, MAXIMILIAN

Inventor name: SCHMID, ANDREAS

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220215

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20240301