EP3345364A1

EP3345364A1 - Indirect authorization transport

Info

Publication number: EP3345364A1
Application number: EP16748087.0A
Authority: EP
Inventors: Kai Römer; Philipp Spangenberg
Original assignee: Blueid GmbH
Current assignee: Blueid GmbH
Priority date: 2015-08-31
Filing date: 2016-07-27
Publication date: 2018-07-11
Also published as: DE102015216630A1; US20190028487A1; WO2017036686A1

Abstract

The present invention relates to methods and systems for transmitting at least one authorization for a control function of a technical system. In one embodiment, a corresponding method comprises the reception of the at least one authorization via an unsecure communication channel (200, 300) to a verification unit (35) of an object to be protected (30), wherein the at least one authorization is cryptographically signed by a trusted entity (10).

Description

Indirect authorization transport l. Technical area

The present invention relates to methods and systems for securely transferring authorizations for control functions of a technical system, such as

for example, a vehicle. In preferred embodiments, the security of smart cards is combined with the benefits of Internet-enabled smartphones, so that an authorization for an object to be protected can be transmitted over an insecure channel and still be used safely and reliably. 2. Technical background

From the prior art identification and locking systems for the organization of access and use rights in connection with technical systems are known. For example, Applicant's European Patent L 910 134 Bi relates to an identification system for authorization-dependent use of a technical system. With such a system control functions of a vehicle can be triggered, for example by means of a mobile phone or smartphone, so that the vehicle can be opened and / or started with the mobile phone or smartphone, for example. Mobile phones or similar electronic devices (eg smartphones, personal digital assistants (PDAs) and / or tablet computers) can be flexibly provided with appropriate permissions due to their Internet connectivity, if they are connected via a secure connection to the authority that has the permissions issues. However, this only works if an Internet connection actually exists, which is not always the case with applications such as car rental, for example when the vehicle is in an underground car park.

Other known from the prior art identification and locking systems use instead of mobile phones or other electronic devices called smart cards as a "key", on which appropriate permissions

can be stored. In such systems, however, it has hitherto been considered necessary to describe the smartcard locally to a trusted entity (e.g., the vehicle rental company) with the privileges, which is inflexible and labor intensive. The present invention is therefore based on the problem to provide methods and systems with the entitlement carrier, such as smart cards, safe and flexible can be equipped with permissions, so that the above mentioned in connection with the prior art disadvantages are at least partially overcome.

3. Summary of the invention

This problem is solved according to one aspect of the invention by a method for transmitting at least one authorization for a control function of a technical system. In the embodiment according to claim 1, the at least one authorization is transmitted via an unsecured communication channel to a

Verifying unit of an object to be protected received. According to the invention, the at least one authorization is cryptographically signed by a trustworthy entity.

Because the at least one authorization is cryptographically signed by a trustworthy entity (also called "trust center") and preferably also issued by it, the authorization can be transmitted via an insecure or unsecured channel and nevertheless can be used safely and reliably An unsecured channel is a communication between two units via at least one interface, where the transmission path can not be used to ensure that a data packet can be read or changed by unauthorized parties

For example, the Internet, an SMS, a QR code, GSM, BTLE, Zigbee, general radio links such. 866 MHz, a transport channel via a

Entitlement holder, or similar act. Because of the, preferably digital, signature, the TrustCenter secures the scope and content of the authorization cryptographically, which can be checked by the recipient. A digital signature is an asymmetrical cryptosystem in which a sender uses a secret signature key (the private key) to calculate a value for a digital message (in other words, the at least one authorization), which is also called a digital signature. This value allows anyone, with the help of the public verification key (the public key), to make the non-contestable

Authorship and integrity of the message (here the at least one authorization) to examine. As a signature method, for example, those based on

Prime factor decomposition, such as RSA, such as based on discrete logarithms, eg El Gamal, DSA, those based on elliptic curves, eg ECDSA, or similar are used.

According to one aspect of the present invention, the at least one

Authorization over an unsecured communication channel of one

Transport authorization carriers are received. The transport entitlement carrier may have previously received the at least one entitlement from the trusted entity. This makes it possible, for example, the at least one

Permission from the trusted instance (the TrustCenter) to a

Smartphone (which in this example is the transport authorization carrier) and then from the smartphone to the verification unit (which may be located, for example, in a vehicle as an object to be protected). As a result, the flexibility of the method is considerably increased, since any conventional electronic devices, such as smartphones, can be used as a transport medium for the at least one authorization. At the same time, the authenticity of the transmitted at least one authorization is preserved thanks to the signature described above, although the at least one authorization is transmitted via an unsecured channel (for example the internet-enabled smartphone). It is understood that instead of a smartphone any other type of entitlement carrier may be used (further examples below) and that the term "transport" entitlement carrier is merely intended to clarify that the entitlement carrier is used as the means of transport for the at least one entitlement; however, does not rule out that the Entitlement Owner is not also able to actively use authorizations.

Alternatively or additionally, the at least one authorization may have one

unsecured communication channel from the trusted entity. For example, it is conceivable that the verification unit (for example in the vehicle) has the at least one authorization directly, e.g. over a

Internet connection, picks up from the TrustCenter.

Preferably, the at least one authorization is further from the

Verification unit to a destination authorization carrier via a second,

preferably unsecured, communication channel transmitted. This makes it possible for the at least one authorization which the verification unit has possibly received from the above-described transport authorization carrier, eg a smartphone, to transfer to another authorization carrier, for example a smartcard becomes. This aspect of the invention contributes to the demand of some

Car manufacturers bill, according to which a smartphone can be used to unlock the vehicle doors, but not for starting the vehicle, which is done in this example by means of the authorization on the smart card. In this aspect, i. the transfer of at least one entitlement to any one

Authorization carrier via an unsecured communication channel, it shows the significant increase in flexibility of the method according to the invention, which thanks to the signature of at least one permission nevertheless highest

Safety standards are sufficient. The present invention also enables a direct transmission of at least one authorization from a transport authorization carrier to a destination authorization carrier. For this purpose, a method for transmitting at least one authorization for a control function of a technical system is provided, in which the at least one authorization is received by a transport authorization carrier via a third, preferably unsecured, communication channel at a destination authorization carrier. In order to guarantee the authenticity of the at least one authorization, it is also cryptographically signed by a trustworthy entity.

As has already been explained above, the at least one authorization at the transport authorization carrier can be received by the trustworthy entity via a, preferably unsecured, fourth communication channel. Furthermore, as has likewise been described above, it is possible for the at least one authorization to be checked for authenticity and origin in the trustworthy entity, which is preferably carried out by the verification unit of the object to be protected.

Furthermore, the method may include the further step of authenticating the

Have target entitlement bearer against the verification unit. Thus, the destination entitlement bearer (eg, a smartcard) can uniquely prove its identity to the verification unit. Also the

Transport authorization bearer may include an authentication unit to authenticate to the verification unit. It can the

Transport authorization bearers have a lower strong authentication unit than the destination authorization bearer. Preferably, the at least one authorization is one or more

Authorization carriers, for example, at least the destination authorization carrier assigned. Thus, certain destination entitlement bearers may be authorized for certain control functions (e.g., deactivating the immobilizer of a vehicle)

Vehicle, unlocking a vehicle, locking a vehicle, releasing the full vehicle power, start booking, end booking, unlocking additional functions such as. Navigation device or seat heating, or the like).

The entitlement bearers mentioned here, i. the transport entitlement bearer and / or the destination entitlement bearer may be an Internet-enabled entitlement bearer, a mobile phone, a smartphone, a PDA, a tablet computer, a smartwatch, a smartcard, an NFC card, a smart token, a vehicle key, an RFID card and / or a SIM card.

The at least one authorization is preferably a certificate, particularly preferably a digital certificate, for example a public-key certificate according to the standard X.509, or else another proprietary certificate system. The at least one entitlement may have one or more of the following limitations: a temporal one

Limitation, a functional limitation, a channel limitation, a limitation to one or more entitlement carriers and / or entitlement carrier groups, a limitation to one or more objects to be protected, a local limitation and / or a person-related limitation.

In another aspect of the present invention, one or more transport entitlement bearers (20) may be used to transfer the entitlement (or also multiple entitlements) to a destination (i.e., preferably one

Destination entitlement bearer (40) or a verification unit (35)) until the destination confirms this to the sender (10) (i.e., preferably a trusted entity). This will cause the sender, i. In general, the TrustCenter, informed that the authorization has arrived at the destination, even if the authorization for this purpose moves through a chain of authorization holders. It is understood that further aspects of the present invention include such a chain of

Authorization holders can also provide without the above confirmation.

The present invention further relates to a computer program comprising

Instructions for implementing one of the methods discussed above. In addition, a system for transmitting at least one authorization for a control function of a technical system is provided, the system having a verification unit of an object to be protected, which is suitable for receiving the at least one authorization via an unsecured one

Communication channel, wherein the at least one authorization of a

trusted instance is cryptographically signed. Furthermore, a system for transmitting at least one authorization for a control function of a technical system is provided, the system having a destination authorization carrier which is suitable for receiving the at least one authorization via a third communication channel from a transport authorization carrier, wherein the at least one authorization is from a trustworthy entity is cryptographically signed. Incidentally, embodiments of the systems discussed above may be arranged to accommodate all or at least some of the methods discussed above

perform. Further advantageous embodiments of the systems according to the invention are specified in the dependent claims.

4. Character description

In the following the invention will be described in more detail with reference to the attached figures. Show it:

1 is a schematic block diagram illustrating the interaction of various components according to embodiments of the invention; and

2 shows an exemplary authorization in XML format according to embodiments of the invention (so-called "BluelD ticket").

5. Description of preferred embodiments

Preferred embodiments of the present invention provide computer-implemented methods and systems that combine the security of smart cards with the benefits of Internet-enabled smartphones. In this case, at least one authorization for an object to be protected can be transmitted via an insecure channel to an authorization carrier and nevertheless used safely and reliably. Hereinafter, for the sake of simplicity, the term "authorization" will be used both in the singular and in the plural, but it should be understood that the present invention is applicable to any number of permissions. According to the embodiment, inventive systems comprise at least a subset of the components explained below with reference to FIG. 1:

A trustworthy entity 10 (also called "trust center") which is suitable for creating and signing one or more authorizations.

A trust center is generally a service that all parties trust and that is able to issue and then sign permissions. He takes care that only the authorized person can issue authorizations and that the secrets necessary for issuing the authorization are safely stored and used. Ideally, but not necessarily, a TrustCenter is connected to the Internet so that permissions can be easily and quickly distributed. However, as this poses a security risk, the TrustCenter should preferably have multiple shifts in order to achieve better protection and, if necessary, better mitigation during attacks. Typically, the outermost layer has the task of repelling attacks and protecting the inner layer (s). A second layer is

typically responsible for managing and issuing permissions and / or verifying permission to create permissions. A third layer typically handles the signing of permissions. Optimally, a fourth layer is provided for the secure storage of the cryptographic secrets. For this purpose, a so-called hardware secure element is often used, which, however, can also be integrated in the third layer.

A TrustCenter can be arranged at different places in the overall system. Ideally, the site is protected against unauthorized access (both digital and physical), is monitored to detect tampering, and has high availability for retrieving authorizations created. Mostly this will be in a special area of a

Data Center will be the case. However, it is also often chosen a location in the workspace of the security guard. Thus, the security level is low.

For example, a trust center can be operated as a cloud service for a large number of users by a trustworthy entity, such as the applicant's company, or locally by the IT department of the respective company. At least one object to be protected 30 (also called "secured object"), which is managed by the authorization system according to the invention.

These may be, for example, vehicles (e.g., motor vehicles, trucks,

Commercial vehicles), electrical and / or electronic machines (e.g.

Car washes, elevators), locks (e.g.

Cylinder lock, electronic fitting, electronic door opener), barriers and / or gates, sliding doors and / or hinged doors, or the like act.

One or more authorizations, which are preferably assigned to one or more defined authorization carriers. For example, a permission can be defined in XML format.

In the embodiment of FIG. 2, for example, the signature that is stored in the field permission-> signature, formed over all user data between the permission tags. Thus, a verification unit can check the authenticity.

One or more entitlement carriers 20, 40 which are suitable for storing one or more (signed) authorizations. A credential carrier 20, 40 may include an authentication unit capable of cryptographically authenticating to the verification unit 35 (see below). Such an authorization carrier 20, 40 is therefore suitable for the transport and storage or use of at least one authorization (for example a smartcard or a smartphone). Authorization bearers 20, 40 without an authentication unit can not authenticate themselves and thus do not represent full-fledged keys; they only serve to transport at least one authorization (for example a USB stick).

A verification unit 35 in the object 30 to be protected (or connected to the protective object 30) which is suitable for checking whether the at least one authorization originates correctly and unchanged from the trust center 10 and / or if the authorization carrier 20, 40 is the one for which he pretends (authentication).

The verification unit is preferably a sealed system that is protected against manipulation. It may include a processor suitable for controlling communication with the entitlement carrier and / or to perform the verification of the authorization. In a vehicle this is often the BCM (Body Control Module). In particularly small and power-consuming implementations, such as electronic locking cylinders, this is often directly in the

Communication unit, e.g. the BluetoothLE chip.

A particular advantage of the present invention is that an authorization bearer 40 not connected to the Internet can be authorized to execute, initiate or trigger a control function of a technical system 30, without the at least one authorization having the authorization bearer 40 at the trust center 10 must be picked up. This is achieved by the fact that the

Permission and authentication are separate. By means of a digital signature, the trust center 10 secures the scope and content of the authorization cryptographically, that is to say which authorization carrier 40 is allowed to do something. At the time of authoring, the identity of the destination entitlement bearer 40 must be known to the trust center 10.

After creating the authorization in the TrustCenter 10, thanks to the

According to the invention, the authorization and authorization are not only downloaded directly from the trust center 10 to the authorization medium 40, but also via any unsafe channel (for example via another

Authorization carriers 20, a so-called "transport authorization carrier", can be transferred to the destination authorization carrier 40. Nevertheless, the authorization on the destination authorization carrier 40 can be used safely and reliably.

To provide a destination entitlement carrier 40 with one or more

Permissions, the present invention provides various exemplary

Embodiments before:

Example 1:

1. The trust center 10 transmits the authorization over the channel 100 (e.g.

Internet, SMS, QR code, GSM, online connected card reader / writer, or another as mentioned at the beginning unsafe channel) on the

Transport entitlement carrier 20 (e.g., a smartphone). Optionally, the

Transport entitlement bearer 20 likewise have one or more authorizations for the object 30 to be secured and / or the transferred one

Use permission. 2. The transport authorization carrier 20 preferably transmits the authorization via the channel 600 directly (for example, preferably via NFC, as appropriate)

Authorization bearer (e.g., BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the destination entitlement bearer 40 (e.g., a smart card).

It is particularly advantageous here for the authorization to be transferred from the trust center 10 to the destination authorization carrier 40 (e.g.

Smartcard) can be transmitted. In particular, no physical contact between target authorization carrier 20 and TrustCenter 10 is necessary. This

However, the embodiment can be limited by specifications of the transport authorization carrier 20 (for example, not all currently available

Smartphones have a direct communication connection with a smartcard).

Example 2:

1. The trust center 10 transmits the authorization over the channel 100 (e.g.

Transport entitlement carrier 20 (e.g., a smartphone). Optionally, the transport entitlement bearer 20 may also have one or more entitlements for the object 30 to be secured and / or the transferred one

Use permission.

2. The transport authorization carrier 20 transmits the authorization via the channel 200 (eg, preferably Bluetooth LE or classic, NFC, Zigbee, general radio links such as 866 MHz, or another unsafe channel as mentioned above) to the verification unit 35 of the object 30 to be secured (FIG. eg a vehicle).

3. The verification unit 35 transmits the authorization via the channel 400 (eg, preferably NFC, depending on the authorization carrier (eg BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the destination authorization carrier 40 (eg Smartcard), preferably as soon as it communicates with the verification unit 35.

Here too, the authorization can be transmitted via an insecure channel (eg smartphone) from the trust center 10 to the destination authorization carrier 40 (eg smartcard) become. Subsequently, the verification unit 35 can be set up to delete the authorization again from its memory. This may be particularly advantageous in the context of car rental companies, where the verification unit of a given vehicle is loaded in a short time with a plurality of authorizations (for the different customers), which could lead to memory bottlenecks. Further, some automakers require that a permission never be allowed to remain in the vehicle, which is also addressed by this embodiment.

Example 3: 1. The verification unit 35 of the object 30 to be protected loads the

Authorization over the channel 300, preferably directly (e.g., over the Internet, general wireless links such as 866MHz, SMS, GSM, or other such unsafe channel as mentioned above) from the TrustCenter 10.

2. The verification unit 35 transmits the authorization via the channel 400 (eg, preferably NFC, depending on the authorization carrier (eg BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the destination authorization carrier 40 (eg a Smartcard), preferably as soon as it communicates with the verification unit 35.

It is particularly advantageous that the authorization can reach the entitlement carrier without time-consuming detours, since the verification unit is preferably connected directly to the Internet. In addition, the delivery of a permission can be easily understood. A possible disadvantage here is that an online connection is necessary. As soon as e.g. in an underground car park no internet connection at a e.g. Vehicle is present, no new authorization can be loaded. Here then an alternative channel must be used, since the vehicle is not without

Authorization comes from the underground car park.

Once the entitlement has been transferred to the destination entitlement bearer 40, it can be used accordingly. In order to check whether a permission holder is allowed to perform an action, two steps are carried out in preferred embodiments:

1. The authorization is loaded by the verification unit (eg from a local storage or by the authorization holder) and is authorized by the Verification unit checked. In this case, it is preferable to first create a hash over the content and then to verify the signature by means of the public key of the issuing trust center. Now the content is analyzed. If the authorization for the verification unit is determined and the further limitations arrive, the identity of the associated authorization carrier is determined from the

Authorization read out.

2. Now the identity of the authorization holder can be checked. For this purpose, it is preferably checked whether there is a specific secret in the authorization medium. The necessary verification data can be derived from the identity description of the authorization holder. Usually, a random number is sent to the entitlement carrier and its response is cryptographically verified via the public key of the entitlement carrier from the entitlement. If the authorization holder matches the authorization, the action is carried out or released. Further, the present invention also allows embodiments in which the authority remains on the verification unit 35, i. not on the

Target authorization carrier 40 is transmitted. The corresponding processes are:

Example 4:

1. The trust center 10 transmits the authorization over the channel 100 (e.g.

Internet, Internet, general radio links such. 866 MHz, SMS, GSM, or another as mentioned in the beginning unsafe channel) on the

Use permission.

2. The transport authorization carrier 20 transmits the authorization via the channel 200 (eg, preferably NFC, depending on the authorization carrier (eg BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the verification unit 35 of the security to be secured Object 30 (eg a

Vehicle).

Example 5: 1. The verification unit 35 of the object 30 to be protected loads the

As a result, particularly fast verification times can be achieved (see the arrow 500 in FIG. 1), since the authorization does not have to be transmitted to the destination authorization carrier 40. In addition, a pre-verification of the authorization can take place. Thus, the authorization no longer has to be checked at the time of execution, but can already be considered secure.

In all illustrated embodiments, the entitlement bearer 40 and / or the verification unit 35 must preferably be made known to the trust center 10 in order to enable the authentication. This is preferably done before

Creation of at least one authorization by the TrustCenter 10. The

Advertising can include the following:

1. The verification unit receives the public key of the Trust Center, which it should trust, before the start of the assignment. This usually happens during production or during commissioning by means of a configuration tool.

2. The identity of the authorization holder and the identifier of the

The verification unit must be available to the TrustCenter at the latest when creating an authorization, so that it can be entered in the authorization.

All embodiments described herein have in common that the

Authorizations are signed by the TrustCenter 10 and can be checked by the verification unit 35 on their authenticity and their origin in the TrustCenter 10, so that the permissions can also be distributed via unsecured or insecure channels.

In the context of the present invention, inter alia, the following

Authorization carriers 20, 40 are used:

Internet-connected or temporarily connected to the Internet, in the

General Internet-enabled devices: o Smartphone o Mobile phones with the ability to play

Application programs (called "apps") o smartwatch

Offline devices with asynchronous connection without direct internet connection: o NFC card, e.g. Smart card o SmartToken, e.g. Car key, building key, access card, etc. o RFID card o SIM card o Smartwatch

The at least one permission discussed herein may include one or more of the following components:

Time limitation, e.g. Validity period

Functional limitation, e.g. only function "open"

Channel bonding, e.g. only NFC

Limitation to one or more entitlement carriers or their group

Limitation to one or more objects to be protected

Local limitation, e.g. only in Munich or within a radius of x meters of a certain location

Limitation to persons, groups of people and / or user roles

An illustrative application example is explained below, which is intended to illustrate the advantages of the present invention:

In a car rental, each user has a personal loyalty card, namely a smart card 40, which is uniquely assigned to the user. The user books a car directly with his smartphone 20. Shortly before the booking starts, the user receives on the one hand, the digital authorization and the position of the vehicle 30 on his smartphone 20 that are suitable for the time of booking. The user goes to the vehicle 30, which is located in the car rental garage, and opens it with the smartphone 20 by means of, for example, the data channel BLE (FIG. "Bluetooth Low Energy") or

by means of one of the methods described in the European Patents EP 1 910 134 Bi, EP 2 564 583 Bi and EP 2 193 607 Bi of the Applicant and is incorporated into. To increase safety, the starting of the vehicle 30 can only be done with the personal smartcard 40. Therefore, during the opening process of

Smartphone 20 the authorization to start the vehicle 30 on the

Verification unit 35 transmitted, the authorization of the smart card 40 is assigned. The user places the smart card 40 on a reader 35 in the vehicle 30 and the authorization is transferred to the smart card 40. Now the smartcard 40 can be authenticated by the vehicle 30 or the verification unit 35 and the

Authorization to be verified. The vehicle 30 can then be started.

Further, the smartcard 40 may also undertake the localization (Thatchem) and / or the certification (e.g., CC EAL 5+). The use of a smart card from a reputable manufacturer such as e.g. G & D also has the advantage that these cards can be purchased in one version on the market, the highest

Requirements for identity bearers are sufficient. This is e.g. a Common Criteria (e.g., EAL 5+) certification. A smart card that uses NFC as a communication channel also solves the problem of identifying the vehicle's credentials, as they can only be read in a reader that has a reading area limited to a few centimeters.

LIST OF REFERENCE NUMBERS

10 Trusted entity ("TrustCenter") 20 Transport authorization carrier 30 Object to be protected 35 Verification unit 40 Target authorization carrier

100 Transfer of the authorization from the TrustCenter to the

Transport credential Transmission of the authorization from the transport authorization carrier to the verification unit Transmission of the authorization from the TrustCenter to the verification unit Transmission of the authorization from the verification unit to the verification unit

Target authorization carrier Authentication of the target authorization carrier Transmission of the authorization from the transport authorization carrier to the target authorization carrier

Claims

claims

1. A method for transmitting at least one authorization for one

Control function of a technical system, the method comprising the following steps: a. Receiving the at least one authorization over an unsecured communication channel (200, 300) at a verification unit (35) of an object (30) to be protected; b. where the at least one permission is from a trusted one

Instance (10) is cryptographically signed.

The method of claim 1, wherein the at least one privilege is over an unsecured communication channel (200) of a

Transport authorization carrier (20) is received.

The method of claim 1, wherein the at least one privilege is received over an unsecured communication channel (300) from the trusted entity (10).

The method of any one of the preceding claims, further comprising:

Transmitting the at least one entitlement from the verification unit (35) to a destination entitlement bearer (40) via a second communication channel (400).

5. A method for transmitting at least one authorization for one

Control function of a technical system, the method comprising the following steps: a. Receiving the at least one authorization via a third

Communication channel (600) at a destination entitlement bearer (40) from a transport entitlement bearer (20); b. where the at least one permission is from a trusted one

Instance (10) is cryptographically signed.

The method of any preceding claim 2, 4 or 5, further comprising:

Receiving the at least one authorization on the

Transport authorization carrier (20) from the trustworthy entity (10) via a fourth communication channel (100).

The method of any one of the preceding claims, further comprising:

Checking the at least one authorization for its authenticity and its origin in the trustworthy entity (10).

The method of any of the preceding claims 4-7, further comprising: authenticating (500) the destination entitlement bearer (40) to the

Verification unit (35) in the verification unit (35).

The method of any preceding claim 2 or 5-8, wherein the transport entitlement carrier (20) comprises an authentication unit to authenticate to the verification unit (35).

The method of claim 9, wherein the transport entitlement carrier (20) has a lesser strong authentication unit than the destination entitlement carrier (40).

11. The method according to any one of the preceding claims, wherein the at least one authorization a permission carrier (20, 40) or more

Authorization carriers (20, 40) is assigned.

12. The method according to any one of the preceding claims, wherein the

Transport entitlement bearer (20) and / or the destination entitlement bearer (40) an internet-enabled entitlement bearer, a mobile phone, a smartphone, a tablet computer, a smartwatch, a smartcard, an NFC card, a smart token, a vehicle key, an RFID Card and / or a sim card is.

The method according to one of the preceding claims, wherein the at least one authorization is a certificate.

14. The method of claim 1, wherein the at least one authorization has one or more of the following limitations: a time limitation, a functional limitation, a channel limitation, a limitation to one or more authorization carriers and / or

Authorization carrier groups, a limitation to one or more objects to be protected, a local limitation and / or a person-related limitation.

The method of any one of the preceding claims, wherein one or more transport entitlement bearers (20) are used to grant entitlement to a destination, preferably a destination entitlement bearer (40) or a

Verification unit (35) to transmit, as long as the destination this the sender (10), preferably a trusted authority confirms.

16. A computer program comprising instructions for implementing a method according to any of the preceding claims 1-15.

17. A system for transferring at least one entitlement for one

A control function of a technical system, the system comprising: a. a verification unit (35) of an object to be protected (30) adapted to receive the at least one authorization over an unsecured communication channel (200, 300); b. where the at least one permission is from a trusted one

Instance (10) is cryptographically signed.

The system of claim 17, further comprising: a transport entitlement carrier (20) adapted to send the at least one entitlement over an unsecured communication channel (200) to the verification unit (35).

19. The system of claim 15, further comprising: the trusted entity (10) adapted to send the at least one entitlement over an unsecured communication channel (300) to the verification unit (35).

The system of any preceding claim 17-19, further comprising: a destination entitlement carrier (40) adapted to receive the at least one entitlement from the verifying unit (35) via a second communication channel (400).

21. A system for transmitting at least one authorization for one

A control function of a technical system, the system comprising: a. a destination entitlement bearer (40) adapted to receive the at least one entitlement via a third communication channel (600) from a transport entitlement bearer (20); b. where the at least one permission is from a trusted one

Instance (10) is cryptographically signed.