Method, apparatus and computer program product for checking permission to use at least one performance feature in an Internet of Things device

Abstract

A method for checking permission for use of at least one performance feature in an Internet of Things (IoT) device (50) based on a permission identifier (LK), comprising: - setting at least one permission condition for use of the performance feature of the IoT device (50) by at least one attribute included in the permission identifier (LK); - transmitting and storing the permission identifier (LK) on the IoT device (50); - checking the permission condition by: a) generating a pseudo-access assigned to the performance feature of the IoT device (50) by a pseudo-holder unit (52) formed on the IoT device (50); and b) checking the authorization of the pseudo-access by checking the attribute of the permission identifier (LK) by a verification unit (53) formed on the IoT device (50); and - activating the at least one performance feature if the pseudo-access is confirmed to be permitted by a positive check result of the permission identifier (LK), wherein the permission identifier (LK), the pseudo-holder unit (52) and the verification unit (53) are designed based on the specification of a verifiable authorization credential (verifiable credential).

Description

Technical Field

[0001] The present invention relates to a method for checking permission to use at least one performance feature in an Internet of Things (IoT) device based on a permission identifier. Background Art

[0002] Licensing software or individual features of software is a common requirement not only in the consumer sector but also in corporate environments and for industrial applications. In addition to licensing software, functions on devices can also be enabled based on licenses. Devices, such as IoT edge devices, machines or motor vehicles are manufactured and sold once. IoT edge devices are components connected to communication networks, which are located at the edge of the network and ensure network transition to the core network of an enterprise or service provider.

[0003] However, the performance range or the characteristics of the user's use during the service life of the device are not fixedly predetermined and may vary depending on the licensing model. Providers of such higher-value services often use licensing models that are related to the type and quality of data and functions to be evaluated. For example, a connection to a cloud system via a specific protocol or the use of specific data types may be bound to a license. Industrial functions, such as the control of machine tools or substations, can also be increasingly implemented and marketed in software provided on general-purpose white box hardware (e.g. industrial PCs or edge computing platforms). Edge computing here refers to decentralized data processing at the edge of the network.

[0004] To date, this has been solved, for example, by monitoring mechanisms, which can query and evaluate the contract / license information for this purpose, for which the device usually has network connectivity and the backend system on the license issuer side is included in the evaluation. In the case where no connection to the provider's system is available or no continuous connection to the provider's system is available, license files and / or hardware dongles are usually used, to which the license is permanently loaded. Password-protected license information is usually delivered via a license file or a license code formed in a password. These license information are read, verified and evaluated by the corresponding software product or device.

[0005] The solution in question concerns the license protection and integrity protection of software. The software is delivered in a protected form, for example encrypted, and can only be used with the aid of a suitable dongle (key implementing the corresponding license). This relates in particular to the fact that the device and the software executed thereon are used on the customer side, that is, are no longer directly accessible and under the control of the manufacturer, and therefore are intended to be protected from any manipulation / license circumvention by the end user.

[0006] The work of the Verifiable Credentials (VC) Working Group, in conjunction with the work of the Decentralized Identifiers (DID) Working Group (see also, for example, https: / / www.w3.org / TR / did-use-cases / of the World Wide Web Consortium, W3C for short), is aimed at the standardized description of properties / guarantees that can be checked / verified, also called claims, see data model https: / / www.w3.org / TR / vc-data-model / . An important property of Verifiable Credentials (VC) (hereinafter also referred to as Verifiable Authorization Credentials) is that they are machine verifiable. They are therefore suitable for various use cases, such as proof of the issuance of a license and the use of personal data (e.g. identity data) for online application documents or access portals. Various use cases are described at https: / / www.w3.org / TR / vc-use-cases, such as the use of VCs for verifying the origin / authenticity of a device or for identifying and excluding counterfeit / fake products. On the one hand, the use of VCs for issuing licenses is not described there, and the system model on which VCs are based is also conceptually unsuitable for issuing licenses. Summary of the invention

[0007] It is therefore the object of the present invention to better and more securely support and to provide an improved license check with less development effort, in particular for dynamic application cases in which licenses must be updated or modified during operation of the device.

[0008] This object is achieved by the measures described in the independent claim. Advantageous developments of the invention are described in the dependent claims.

[0009] According to a first aspect, the invention relates to a method for checking permission to use at least one performance feature in an Internet of Things (IoT) device based on a permission identifier, comprising:

[0010] - at least one permission condition for using a performance feature of the IoT device is set by at least one attribute contained in the permission identifier,

[0011] -Transmit and store the consent identifier on the IoT device,

[0012] - Check the licensing conditions by:

[0013] a) generating a pseudo access to a performance characteristic assigned to the IoT device by means of a pseudo holder function formed on the IoT device, and

[0014] b) checking the authorization of the pseudo-access by checking the properties of the permission identifier through a verification function formed on the IoT device, and

[0015] - activating the at least one performance feature if a positive check of the permission identifier confirms that the pseudo access is permitted,

[0016] The license identifier, the pseudo holder unit and the verification unit are designed based on the Verifiable Authorization Credentials specification of the World Wide Web Consortium (W3C).

[0017] The permission check in the IoT device is simulated by a pseudo-holder using functions and processes based on the Verifiable Credentials specification of the World Wide Web Consortium to pseudo-access the permission identifier assigned to the permitted performance feature. However, since the target setting is different in the permission check case compared to the way DID / VC is usually used in the identity authentication between users and nodes, the basic technology needs to be adapted. The essential difference is that both the pseudo-holder unit and the verification unit are formed in the IoT device, that is, the pseudo-holder unit and the verification unit are implemented in the same IoT device. The pseudo-holder unit corresponds here to the modified role of the holder of the VC specification, also called "holder". The verification unit corresponds here to the modified role of the verifier of the VC specification, also called "verifier".

[0018] An IoT device can be, for example, a control device of an information-physical system (e.g. an industrial automation system) or a communication device. The license relates to performance characteristics, in particular performance characteristics from the physical world. Examples of performance characteristics in IoT devices (in particular IoT edge devices) are support for specific protocols, higher / lower sampling rates or accuracy of sensor data. Examples of performance characteristics in motor vehicles are changed acceleration modes with higher or lower performance, autonomous driving or additional online services, etc. IoT devices are also synonymously referred to as devices hereinafter.

[0019] The benefit of this is that the decentralized identifier (DID) / verifiable credential (VC) infrastructure and the corresponding tools and libraries can be used to implement license protection, so there is no need to develop special technical solutions to manage and check licenses. For example, the general DID / VC infrastructure used for user authorization management and identity authentication can also be used to implement license checks. As a result, the license issuance solution can be implemented and operated with less cost than when using specific license issuance tools.

[0020] In an advantageous embodiment, the license identifier is stored on the device before or during operation of the device.

[0021] This has the advantage that not only can the license identifier and thus the license conditions be set and introduced into the device before the device is put into operation, but the license conditions can also be applied to the device during operation. In addition, the device can be manufactured without regard to subsequent use and the purpose for which the device is used can be set later at operating time.

[0022] In one advantageous embodiment, the permission identifier is retransmitted to the IoT device during operation of the IoT device and replaces or supplements the stored permission identifier.

[0023] This has the advantage that the license identifier and thus the license conditions can be updated and / or supplemented during the service life of the device.

[0024] In an advantageous embodiment variant, the transmission of the license identifier from the license server to the IoT device is initiated from outside the IoT device and sent to the IoT device. Alternatively, the transmission of the license identifier is initiated by an application on the IoT device itself. In this case, the IoT device retrieves the license identifier from the license server.

[0025] In an advantageous embodiment variant, the pseudo accesses are generated and checked repeatedly when the IoT device is started or when a performance feature is started on the IoT device and / or during operation.

[0026] The point in time at which the permission check is performed is thereby set. In particular, the permission check is performed at the point in time at which the permitted performance feature is started or when the IoT device is started. Optionally, further pseudo-accesses can be generated during the ongoing operation and the performance feature can be activated or enabled at a later point in time depending on the check result, or it can be deactivated or blocked in the case of a negative check result.

[0027] In an advantageous embodiment variant, the IoT device is designed as a physically independent device or as a software-based virtual device distributed on one or more hardware platforms.

[0028] Thus, the license check can be flexibly performed on IoT devices of different designs. Thus, the proposed license check can be performed both on real physically existing devices and on virtually designed devices. The hardware platform can in particular be a hardware-based "computing platform".

[0029] In an advantageous embodiment variant, the dummy holder unit of the IoT device is formed as part of a software application, as part of an execution environment of a software application or by an operating system of the IoT device.

[0030] If the IoT device is designed to be virtualized, it exists, for example, as a virtual machine (VM) image or container image. If such an image is executed, the IoT device as a whole "really" exists. The corresponding image then includes an operating system and applications, just like in the case of hardware-based devices.

[0031] In an advantageous embodiment variant, the dummy holder unit and the verification unit are formed on a common hardware platform. Alternatively, the dummy holder unit and the verification unit are formed on different platforms which are locally connected to each other.

[0032] This makes it possible to check the license even on IoT devices that are structured in a distributed manner. In addition, since the pseudo holder unit and the verification unit are distributed on different hardware platforms, device-internal but platform-specific license distribution can be achieved.

[0033] In an advantageous embodiment variant, a who attribute in the license identifier is checked by the verification unit against the verification platform identifier of the verification platform, which attribute indicates the IoT device that is authorized to activate the performance feature.

[0034] The who attribute can preferably consist of a "subject" attribute in a verifiable authorization certificate VC in accordance with the W3C VC specification. The who attribute can be used to check and implement in particular the licenses that are bound to a specific device entity or device component. The who attribute indicates the device for which the license is specifically used. Further environmental information, such as operator ID, location, runtime environment, software application, device type or version, can also be incorporated into the who attribute. If the who attribute is empty, i.e. not occupied, no check of the execution unit relative to the performance characteristics is performed.

[0035] In an advantageous embodiment variant, a “what” attribute in the license identifier is checked by the verification unit, which attribute indicates further conditions for activating a feature or an option for activating a feature.

[0036] The verification unit accepts the license identifier only if the attributes characterizing the relevant allowed execution environment identified in the "what" attribute are consistent with the characteristics of the execution environment of the determined performance characteristics. Thus, the license conditions can be checked and implemented. Characteristics of the execution environment are, for example, operator identifiers, locations, runtime environments, software applications, types and / or versions of IoT devices.

[0037] In an advantageous embodiment variant, a security attribute in the license identifier is checked by the verification unit, the security attribute comprising a cryptographic identifier of the issuer of the license identifier.

[0038] Only if the security attributes are confirmed, the verification unit checks the license identifier as valid and confirms the pseudo-access as allowed. The security attributes include, for example, a signature of a known and trusted license authority.

[0039] In an advantageous embodiment variant, the first license identifier is issued by a license creation unit external to the IoT device, and / or the second license identifier is issued by a license creation unit internal to the IoT device and stored on the IoT device, and

[0040] The first license identifier specifies a property of an execution environment in which the verification unit is executed,

[0041] The second permission identifier includes a characteristic that is actually present in the IoT device, and

[0042] The first and second license identifiers are checked by the license identifier verification unit against characteristics of a current execution environment of the verification unit.

[0043] Therefore, the license identifier can be issued not only as the first license identifier by a license creation unit arranged outside the IoT device, but also by a license creation unit integrated in the IoT device. The verification unit checks whether the description of the required execution environment in the license identifier is consistent with the description of the actual execution environment in the VC platform information.

[0044] In another embodiment, the third permission identifier is issued by a confirmation issuing unit external to the IoT device. The third permission identifier confirms the characteristics of the IoT device, for example: the device has been identified as not manipulated by the security monitoring system and is therefore considered not manipulated. The confirmation issuing unit external to the IoT device is usually different from the issuing unit external to the IoT device that issues the first permission identifier.

[0045] In an advantageous embodiment variant, the license identifier is formed as an anonymous, verifiable authorization document and the verification unit checks only the presence of at least one specific attribute but not the content of this attribute.

[0046] An anonymous verifiable authorization credential only enables the determination of whether a specific attribute exists, ie, whether it is correct, as confirmed by the permission identifier.

[0047] In an advantageous implementation variant, the performance characteristic is a software container and the license identifier is used to manage and control the software container infrastructure. Alternatively, the performance characteristic is a software application or a hardware component of an IoT device.

[0048] Therefore, the license identifier can be used flexibly in different technology areas.

[0049] A second aspect of the present invention relates to an apparatus for checking permission to use at least one performance feature in an Internet of Things (IoT) device based on a permission identifier, comprising:

[0050] A license issuing unit designed to:

[0051] - at least one permission condition for using a performance feature of the IoT device is set by at least one attribute contained in the permission identifier,

[0052] - transmitting the permission identifier to an IoT device, and the IoT device is designed to:

[0053] - store the license identifier,

[0054] - Check the licensing conditions by:

[0055] a) generating a pseudo access to a performance characteristic assigned to the IoT device by means of a pseudo holder unit formed on the IoT device, and

[0056] b) checking the authorization of the pseudo-access by checking the attributes of the permission identifier through the verification unit formed on the IoT device, and

[0057] - activating the at least one performance feature if the verification unit confirms that the pseudo access is permitted by a positive check of the license identifier,

[0058] The license identifier, the pseudo holder unit and the verification unit are designed based on the Verifiable Credentials specification of the World Wide Web Consortium (W3C for short).

[0059] The method and the device enable simple and automatable license acquisition during runtime (that is, when IoT devices and applications are running). Therefore, the method and the device are also particularly suitable for industrial use, that is, in situations where direct manual access to the device is generally not possible. Only at runtime or after the successful issuance of the license is it set which functions are available to the license holder. In this case, the device can be configured so that it provides an initialization interface through which the license can be securely loaded in the form of a license identifier. Thus, the license terms can be adapted / replaced during the service life. The license evaluation can be implemented in a fine-tuned manner and, in addition to the device context, such as the check of the hardware entity, the surrounding environment can also be included, such as the identification of the user by a DID. If the device is built in another environment, for example, unauthorized use can be restricted / prevented in a monitored manner in this case.

[0060] By using VC and DID, license evaluation can be realized even in offline scenarios. That is, these devices do not require a permanent connection to the license server and are therefore also suitable for use in a separate network. In general, the advantages of DID and VC are usually transferred to the licensing method shown. Therefore, the license issuer or license holder only needs to provide the information required for the license check for verification.

[0061] A third aspect of the invention is directed to a computer program product comprising: a non-volatile computer-readable medium directly loadable into a memory of a digital computer, comprising a program code portion which, when executed by a digital computer, causes the computer to perform the steps of the method.

[0062] Unless otherwise stated in the following description, the terms "setting", "transmitting", "checking" etc. preferably relate to actions and / or processes and / or processing steps of changing and / or generating data and / or converting data into other data, wherein the data are in particular represented as physical parameters or can exist as physical parameters, for example as electrical pulses.

[0063] A corresponding "unit", such as a license issuing unit or an IoT device, can be implemented in hardware and / or also in software. In the case of a hardware implementation, the corresponding unit can be formed as a device or part of a device, such as a computer or a microprocessor or a control computer of a vehicle. In the case of a software implementation, the corresponding unit can be formed as a computer program product, a function, a routine, a part of a program code or an executable object.

[0064] The computer program product (e.g., computer program means) can be provided or supplied, for example, as a storage medium, such as a memory card, a USB stick, a CD-ROM, a DVD, or in the form of a file that can be downloaded from a server in a network. This can be done, for example, in a wireless communication network by transferring the corresponding file to the computer program product or the computer program means. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Exemplary embodiments of the method according to the invention and of the system according to the invention are shown by way of example in the drawings and are explained in more detail based on the following description.

[0066] Figure 1 The role model of the Verifiable Authorization Credentials (Virtual Credentials in English) is shown, which corresponds to the W3C specification "VC-datamodel";

[0067] Figure 2 An embodiment of the method according to the present invention is shown in the form of a flow chart;

[0068] Figure 3 An embodiment of a data structure of a license identifier according to the present invention is shown schematically; and

[0069] Figure 4 An embodiment of an apparatus according to the invention with an IoT device according to the invention is shown in a schematic diagram.

[0070] In all the figures, parts which correspond to one another are provided with the same reference symbols. DETAILED DESCRIPTION

[0071] The processes and roles specified by W3C based on verifiable authorization credentials VC and decentralized identifiers (Decentralized Identifiers, DID) are referred to as DID / VC in the following text, and the corresponding verifiable authorization credentials are referred to as VC.

[0072] However, since the goal setting is different in the case of permission checking compared to the way DID / VC is usually used in identity authentication between users and nodes, the basic technology needs to be adapted. Figure 1 , distinguishing between the roles of issuer 11 (also called Issuer), holder 12 (also called Holder), verifier 13 (also called Verifier) ​​and subject 14 (also called Subject). Issuer 11 issues a verifiable authorization certificate VC and provides it to holder 12. Holder 12 uses VC to form a verifiable representation, which the holder can use to prove the attributes (characteristics (Eigenschaften), claims) confirmed by issuer 11 through VC to the verifier 13. In special cases, VC can also be used directly as a verifiable representation. The attributes confirmed by VC are assigned to the subject. Holder 12 itself can usually represent the subject. However, the subject can also confirm the holder 12 of VC representing the subject attributes of the subject. The verifiable data registry 14 stores identifiers and usage patterns.

[0073] However, in current licensing solutions there are other roles and other targeting. One difference is the concept of the issuer of the licensing information, which is usually the manufacturer of the IoT device or the software that implements the virtual IoT device. The device / software assumes different roles in that, depending on the licensing information, certain performance features are activated or their use is enabled. Furthermore, the targeting is not to check whether the accessing party is authorized, but rather to check whether the specific entity, i.e. the device / software that performs the check itself, is allowed to activate the feature. The accessing party cannot have access like in the access control systems that VC has been developed for.

[0074] However, the following aspects can be incorporated into the license checking method according to the present invention from the VC / DID solution. The license issuing unit can assume the role of VC issuer 11 and can generate a license identifier based on the VC that generates the license issuance information. The IoT device / software can assume the role of VC verifier 13 and can check the license identifier, that is, the provided modified VC, or more precisely the verifiable representation VP, and can enable or activate functions in the IoT device / software based on this.

[0075] However, since permission checking is conceptually different from traditional access control, the concepts of "holder" and "subject" of verifiable credentials VC cannot be mapped to the roles of permission checking without changes.

[0076] Therefore, in order to implement a licensing solution when using VC, an adaptation is proposed. The basic idea is that the IoT device that performs the licensing check combines the VC roles of the verifier 13 and the holder 12 and possibly additionally the VC role of the subject. It internally performs a pseudo-access assigned to the enabled performance features. Depending on whether the access is allowed or not in accordance with the current license identifier of the VC-based structure, the performance feature is activated or enabled.

[0077] use Figure 2 An embodiment of the method is described below.

[0078] In order to check the permission for using at least one performance feature of an Internet of Things (IoT) device, at least one permission condition for using the performance feature of the IoT device is set in a first method step S1 by means of at least one attribute contained in a permission identifier. Subsequently, the permission identifier is transmitted to the IoT device and stored there, see S2. In the subsequent method step S3, the permission condition is now checked.

[0079] To this end, a pseudo-holder function formed on the IoT device generates a pseudo-access to the performance feature assigned to the license identifier, see step S31. Then, in step S32, the verification unit of the IoT device checks whether the pseudo-access is authorized by the pseudo-holder unit. To this end, the attributes of the license identifier are checked by the verification unit. If the check of the attributes yields a positive check result, that is, the execution platform of the performance feature satisfies the attributes indicated as confirmed in the license identifier, the performance feature is activated, see step S4. If the check result is negative and at least one of the attributes is not met, the activation of the performance feature is rejected and therefore not executed. Here, in order to check the license identifier, in particular the license identifier, the pseudo-holder unit and the verification unit are designed for processes and sequences based on the specifications of the Verifiable Credentials of the World Wide Web Consortium (W3C).

[0080] The IoT device is formed as a physically independent device, or as a software-based virtual device distributed on one or more hardware platforms. Pseudo-access can be performed in particular at the time when the IoT device is started. Optionally, further pseudo-access can be repeated in the ongoing operation, and the performance feature can be activated or enabled at a later time point depending on the result, or the performance feature can be deactivated or blocked in the case of a negative result. The pseudo-holder unit can, for example, be formed as part of a software application, as part of the execution environment of a software application, or by an operating system of the IoT device. The holder is called a pseudo-holder unit because it is not an access party, but only a local unit that provides a license identifier to the verification unit.

[0081] The pseudo holder unit can be implemented on the platform of the verification unit itself, or can alternatively be implemented as a separate component that is locally connected to the platform. The platform of the verification unit and the pseudo holder unit can be locally connected via a direct interface, such as USB, RS232, PCIe, I2C, SPI, optical fiber or via a local Ethernet interface, a local Bluetooth interface or a local WLAN interface.

[0082] Permission check, see Figure 2 S3 in is executed by the verification unit of the IoT device. In the following description, reference Figure 4 The IoT device 50 shown in FIG. 5 includes a pseudo holder unit 52, a verification unit 52 and a hardware component 55, such as a trust anchor of the IoT device. The pseudo holder unit 52 receives the license identifier LK via the service interface 57, for example, and stores it.

[0083] A pseudo holder unit 52 is implemented on the platform of the IoT device 50 on which the license check in the verification unit 53 should be implemented, such as a processor or a software container or a part of a software container, and the pseudo holder unit 52 loads the license identifier and provides it locally to the verification unit 53. The license identifier LK is provided by a download server, a device management server, a DID infrastructure, a database, a distributed database infrastructure or a Web service, for example, from a local file system via a configuration interface. The provision can be initiated either by an external unit or by the IoT device 50 or an application on the IoT device. The pseudo holder unit 52 implements a pseudo access, which is used to detect at least one relevant license identifier LK and provide it locally to the verification unit 53.

[0084] The pseudo holder unit 52 may provide the at least one license identifier directly or in a modified form as a verifiable representation to the verification unit 53. Here, the pseudo holder unit 52 may be implemented on the IoT device 50 itself or by an external component that initiates a call to the IoT device 50.

[0085] The verification unit 53 first checks the validity of the license, which is preferably provided in the form of a security attribute of the license identifier LK. Here, the security attribute is cryptographically verified and checks whether the license identifier LK was issued by a known and trusted license issuing authority.

[0086] The verification unit 53 also checks whether the who attribute contained in the license identifier LK, preferably based on the subject attribute of the VC, is consistent with the current execution environment of the verification unit 53. In a variant, the verification unit 53 determines information about the current execution environment of the verification unit 53 itself. This information can be, for example, a hardware identifier (hardware ID). The who attribute does not have the conventional meaning of VC here, but represents a check criterion, in particular an IoT device that is authorized to activate the performance feature and is checked by the verification unit 53 itself in terms of content relative to the verification platform identifier of the verification platform.

[0087] This step is optional, since the who attribute does not need to be occupied. In the case of a license that is not associated with a specific execution environment (e.g., a device entity), the who attribute is free or undefined. Instead of the attribute "subject", another known attribute in VC can also be used to specify the target execution environment in the license identifier LK.

[0088] In addition, the What attribute in the license identifier LK is checked by the verification unit 53. The What attribute indicates further conditions for activating a performance feature or an option for activating a performance feature. The What attribute is preferably represented by the attribute "Claim" of the VC. The verification unit 53 accepts the license identifier LK or a verifiable representation formed thereby only if the conditions characterizing the relevant allowed execution environment contained in the What attribute are consistent with the determined characteristics of the execution environment. To this end, a check of the performance features is performed in the IoT device to determine which of the performance features is enabled by the license identifier LK. To this end, a list of possible performance feature parameters is checked. It is checked whether these performance feature parameters are confirmed to be correct by the What attribute in the license identifier LK. If this is the case, the verification unit 53 only activates or enables the performance features indicated as allowed in the license identifier LK.

[0089] Figure 3 An example of an embodiment of a data structure according to the invention of a license identifier 30 in a machine-readable encoding of a license condition is shown. The license identifier 30 in the parameter "@context" preferably refers to the specification of the W3C Verifiable Credentials. This document contains properties that are typical for verifiable credentials. In the attribute "id" 34, a unique identifier for the license is indicated. For an automatable evaluation, in the attribute "type" 35, the verifiable credential VC is indicated by reference numeral 36 and the license identifier with "SWLic" is indicated by reference numeral 37. The attributes "Issuer", "IssDate" and "ExpDate" contain information about the issue date and its validity date for the license issuing unit that issued the license identifier 30 or, in general, for the license issuer. The attribute "ExpDate" is only filled in if the license identifier has a time limit.

[0090] The license identifier 30 includes a who attribute W1-Att 31, a what attribute W2-Att 32, and a security attribute S-Att 33. The who attribute W1-Att 31 is usually included in the "Subject" attribute, the what attribute W2-Att 32 is usually included in the "Claim" attribute, and the security attribute S-Att 33 is usually included in the "Proof" attribute of the VC.

[0091] Since there is no access party in the traditional sense of the VC in the case of a license check, the who attribute 31 or the subject description in the license identifier 30 may be missing or may be used in another way, for example to encode information about the target description. However, the who attribute 31 is preferably used to encode an explicit target description. For example, this is the IoT device 50 that the license is specifically for. In another embodiment variant according to the invention, additional environmental information, such as operator ID, location, runtime environment, software application, device type or version, can also be included in the who attribute 31.

[0092] As already mentioned above, Figure 4 An embodiment of an apparatus according to the present invention is shown, the apparatus comprising: an IoT device 50 (e.g., an industrial device) and an external license issuing unit 43. The device 50 is arranged in an environment (e.g., a factory) of a license issuer 41. The license issuing unit 43 is, for example, arranged in an environment of a provider 42 of an application or performance feature, for example, in a cloud backend. The device 50 comprises a pseudo holder unit 52 having a storage unit, a verification unit 53, and a hardware component 55, which, for example, forms a trust anchor and confirms parameters of the hardware component 55. The license issuing device 43 creates and confirms a license identifier LK and transmits it to the IoT device 50. This can be done via the production operation management unit 44.

[0093] Performance characteristics, such as the application is started and ready to run, but is not performing any functions that require a license.

[0094] The license identifier LK not only confirms that the attribute is correct, but also, in a variant embodiment, additionally defines the required additional checks that are checked by the verification unit 53. Only if the defined additional checks are checked as correct, the attributes confirmed positively in the license identifier LK are allowed to be used as correct under the said premise. This is done independently of the verifiable credential system or by checking further verifiable credentials.

[0095] In a variant, a second license issuing device 56 arranged locally on the execution level of the virtual or physically real IoT device 50 provides a second license identifier LK2, which confirms the characteristics of the execution environment in which the verification unit 53 is executed. This second license identifier LK2 can also be called VC platform information, because it confirms: on which platform the function is executed, here the verification unit 53. In this case, the verification unit 53 checks whether the description of the required execution environment in the second license identifier is consistent with the description of the actual execution environment in the VC platform information.

[0096] In the case of a license identifier formed as an anonymous verifiable authorization credential, which is based on a privacy-preserving credential and is referred to below as an anonymous license identifier, a special type of check can also be performed: the anonymous license identifier makes it possible to determine only whether a specific attribute exists, that is, whether the anonymous license identifier confirms it as correct in the form of a verifiable credential VC or a verifiable representation. However, this information cannot be read directly as in the case of an explicitly encoded license identifier data structure, but can only be determined by checking: whether a specific attribute is confirmed as correct by the anonymous license identifier. The anonymous license identifier represents the statement confirmed by the license issuing unit 43 in a tamper-proof and privacy-preserving manner. The check is performed in a manner similar to that generally described above. The difference is that the anonymous license identifier or its verifiable representation does not contain the corresponding information in these attributes in an explicitly encoded form, but rather contains the corresponding information in a privacy-preserving form that only allows the existence of the attribute to be checked.

[0097] In one embodiment, the license identifier additionally contains meta-information which defines the extent of the “scope” check, ie, the set of properties to be checked.

[0098] To perform a license check, also called license enforcement, the validity of the license identifier is performed by verifying the security attribute, namely the signature of the license issuer or license issuing authority 43. In addition, the runtime environment 54 is also checked according to the license criteria to be checked. Figure 4 In the example shown, the license is bound to a specific hardware entity. This can also be cryptographically verified, for which the authorization certificate (also called Credential) of the hardware entity is used in a protected manner, for example by using the authorization certificate through a hardware-based or hardware-bound trust anchor 55. In order to check the use environment, the license check can also include, for example, checking whether the application is only running in a valid customer environment. For this purpose, for example, a "client" attribute is set as part of the "how" attribute (Wie-Attribut) 32. It is encoded by the DID. For example, the check can be performed in the following way: an additional third license identifier that proves the identity of the license holder is transmitted.

[0099] The license checking method shown can be effectively used, for example, to manage / control container infrastructure. Therefore, a container or container image or virtual machine image or application can only be started if the corresponding VC (indicating a license) exists. In addition, functions of the application execution environment (runtime environment RTE, especially edge components), such as load balancing, migration of running entities, failover, full memory encryption, disk encryption, confidential computing, can also be activated based on VC licenses. In addition, the use of hardware accelerators, such as graphics processors GPUs, AI accelerators, cryptographic accelerators, or network accelerators, can be enabled based on VC license information.

[0100] After a successful license verification, the license identifier can be stored on the device side. Thus, after the IoT device / application is restarted, the license check can be re-performed at startup, thus eliminating the need for re-initialization. Therefore, the license identifier is used in a similar way to the license file.

[0101] All method steps can be implemented by corresponding devices suitable for performing the corresponding method steps. All functions that can be performed by essential features can be method steps of the method. All features described and / or depicted can be advantageously combined with each other within the scope of the present invention. The present invention is not limited to the described embodiments.

Claims

1. A method for checking permission to use at least one performance feature in an Internet of Things (IoT) device (50) based on a license identifier (LK), comprising: - setting (S1) at least one permission condition for using a performance feature of the IoT device (50) by means of at least one attribute contained in the permission identifier (LK), - transmitting and storing (S2) the license identifier (LK) to the IoT device (50), - Checking (S3) the permission conditions by: a) generating (S31) a pseudo access assigned to a performance characteristic of the IoT device (50) by means of a pseudo holder unit (52) formed on the IoT device (50), and b) checking (S32) the authorization of the pseudo-access by checking the attributes of the license identifier (LK) by a verification unit (53) formed on the IoT device (50), and - if the pseudo access is confirmed as permitted by a positive result of the check of the license identifier (LK), activating (S4) the at least one performance feature, The license identifier (LK), the pseudo-holder unit (52) and the verification unit (53) are designed based on the specifications of the verifiable authorization credential of the World Wide Web Consortium, and the license identifier (LK) is based on the structure of the verifiable authorization credential, the verification unit (53) corresponds to a modified verifier, and the pseudo-holder unit (52) corresponds to a modified holder, which is designed as a local unit on the IoT device (50) and provides the license identifier (LK) to the verification unit (53).

2. The method according to claim 1, wherein the license identifier (LK) is stored on the IoT device (50) before or during operation of the IoT device (50).

3. A method according to any one of the preceding claims, wherein: During the operation of the IoT device (50), the license identifier (LK) is retransmitted to the IoT device (50) and replaces or supplements the stored license identifier (LK).

4. The method according to claim 1 or 2, wherein: The pseudo access is generated and checked when the IoT device (50) is started or when a performance feature on the IoT device (50) is started, and / or the pseudo access is repeatedly generated and checked during operation.

5. The method according to claim 1 or 2, wherein the IoT device (50) is formed as a physically independent device or is formed as a software-based virtual device distributed on one or more hardware platforms.

6. The method according to claim 1 or 2, wherein: The pseudo holder unit (52) of the IoT device (50) is formed as a part of a software application, a part of an execution environment of the software application or by an operating system of the IoT device (50).

7. The method according to claim 1 or 2, wherein: The pseudo holder unit (52) and the verification unit (53) are formed on a common platform, or the pseudo holder unit (52) and the verification unit (53) are formed on different platforms which are locally connected to each other.

8. The method according to claim 7, wherein a who attribute (31) in the license identifier (30, LK) is checked by the verification unit (53) against a verification platform identifier of the verification platform, the who attribute indicating the IoT device (50) that is authorized to activate the performance feature.

9. The method according to claim 1 or 2, wherein an attribute (32) in the license identifier (30, LK) is checked by the verification unit (53), which attribute indicates a further condition for activating the performance feature or an option for activating the performance feature.

10. The method according to claim 1 or 2, wherein a security attribute (33) in the license identifier (30, LK) is checked by the verification unit (53), the security attribute comprising a cryptographic identifier of an issuer of the license identifier (30, LK).

11. The method according to claim 8, wherein: The first license identifier (LK1) is issued by a license creation unit outside the IoT device, and / or the second license identifier (LK2) is issued by a license creation unit inside the IoT device and stored on the IoT device (50), and The first license identifier (LK1) specifies a property of an execution environment in which the verification unit (53) is executed. The second license identifier (LK2) includes a characteristic actually present in the IoT device (50), and The first and second license identifiers (LK1, LK2) are checked by the verification unit (53) against characteristics of a current execution environment of the verification unit (53).

12. The method according to claim 9, wherein: The first license identifier (LK1) is issued by a license creation unit outside the IoT device, and / or the second license identifier (LK2) is issued by a license creation unit inside the IoT device and stored on the IoT device (50), and The first license identifier (LK1) specifies a property of an execution environment in which the verification unit (53) is executed. The second license identifier (LK2) includes a characteristic actually present in the IoT device (50), and The first and second license identifiers (LK1, LK2) are checked by the verification unit (53) against characteristics of a current execution environment of the verification unit (53).

13. The method according to claim 10, wherein: The first license identifier (LK1) is issued by a license creation unit outside the IoT device, and / or the second license identifier (LK2) is issued by a license creation unit inside the IoT device and stored on the IoT device (50), and The first license identifier (LK1) specifies a property of an execution environment in which the verification unit (53) is executed. The second license identifier (LK2) includes a characteristic actually present in the IoT device (50), and The first and second license identifiers (LK1, LK2) are checked by the verification unit (53) against characteristics of a current execution environment of the verification unit (53).

14. The method according to claim 1 or 2, wherein the license identifier (LK) is formed as an anonymous verifiable authorization credential and the verification unit (53) only checks the presence of at least one specific attribute but not the content of the attribute.

15. The method according to claim 1 or 2, wherein: The performance feature is a software container and the license identifier is used to manage and control a software container infrastructure, or the performance feature is a software application or a hardware component of the IoT device.

16. An apparatus for checking permission to use at least one performance feature in an Internet of Things (IoT) device (50) based on a license identifier (LK), comprising: A license issuing unit (43) is designed to: - setting at least one permission condition for using a performance feature of the IoT device (50) by means of at least one attribute contained in the permission identifier (LK), - transmitting the license identifier to the IoT device (50), and the IoT device (50) is designed to: - storing said license identifier (LK), - Check the licensing conditions by: a) generating a pseudo access to a performance feature assigned to the IoT device (50) by means of a pseudo holder unit (52) formed on the IoT device (50), and b) checking the authorization of the pseudo access by checking the attributes of the license identifier (LK) by a verification unit (53) formed on the IoT device, and - activating said at least one performance feature if said pseudo access is confirmed as permitted by a positive result of the check of said license identifier (LK), The license identifier (LK), the pseudo-holder unit (52) and the verification unit (53) are designed based on the specifications of the verifiable authorization credential of the World Wide Web Consortium, and the license identifier (LK) is based on the structure of the verifiable authorization credential, the verification unit (53) corresponds to a modified verifier, and the pseudo-holder unit (52) corresponds to a modified holder, which is designed as a local unit on the IoT device (50) and provides the license identifier (LK) to the verification unit (53).

17. A computer program product comprising: A non-volatile computer-readable medium that can be directly loaded into the memory of a digital computer, comprising: a program code portion, when the program code portion is executed by a digital computer, the program code portion causes the digital computer to perform the steps of the method according to any one of claims 1 to 15.

Images