VERIFICATION OF A LICENSE TO USE AT LEAST ONE PERFORMANCE FEATURE IN AN INTERNET OF THINGS (IoT) DEVICE

Description

[0001] The invention relates to a method for verifying a license for the use of at least one performance feature in an Internet of Things (IoT) device using a license identifier.

[0002] The licensing of software or individual software features is a common requirement in both the consumer and enterprise sectors, as well as in industrial applications. In addition to software licensing, functions on devices can also be enabled based on a license. Devices such as an IoT edge device, a machine, or even a motor vehicle are manufactured and distributed once. An IoT edge device is a component connected to a communications network that is located at the network edge and provides the network transition to the core network of a company or service provider.

[0003] However, the scope of services or features that a user uses during the lifetime of the devices is not fixed and can vary depending on the licensing model. Providers of such higher-value services often apply licensing models that relate to the type and quality of the data and functions to be evaluated. For example, a connection to cloud systems via certain protocols or the use of certain data types can be tied to licenses. Industrial functions, such as the control of a machine tool or a substation, can also increasingly be implemented and marketed in software that is provided on generic white-box hardware such as an industrial PC or an edge computing platform. Edge computing refers to decentralized data processing that is carried out at the edge of the network.

[0004] To date, this has been solved, for example, through control mechanisms that can query and evaluate contract / license information. For this purpose, the devices typically have web connectivity, and backend systems on the licensor's side are integrated into the evaluation. In cases where no or no permanent connection to the provider's systems is available, license files and / or hardware dongles are generally used, through which licenses are permanently installed. Cryptographically protected license information is often delivered via license files or a cryptographically generated license code. This information is read, verified, and evaluated by the corresponding software product or device.

[0005] The solutions discussed relate to license protection and software integrity protection. Software is protected, for example, encrypted, delivered, and can only be used with a suitable dongle (a key that implements a corresponding license). This particularly applies to the fact that devices and the software running on them are in use by the customer, i.e., they are no longer under the manufacturer's direct access or control, so protection against possible manipulation / license circumvention by the end user is desired.

[0006] US 2015 / 082420 A1 describes a system-on-chip (SoC) comprising multiple hardware modules implemented on a substrate. A validation module, implemented in the SoC's boot code, manages security certificates to control access to the multitude of security features.

[0007] US 2003 / 140255 A1 discloses a licensing method in which it is first determined whether an electronic circuit design is licensable for use within a target circuit. To this end, license information is verified in a set of predetermined vectors associated with the electronic circuit design.

[0008] BRUNNER CLEMENS CLEMENS BRUNNER-EN-TRUST AT ET AL: "DID and VC:Untangling Decentralized Identifiers and Verifiable Credentials for the Web of Trust", 2020 THE 4TH INTERNATIONAL CONFERENCE ON BIG DATA RESEARCH (ICBDR'20), ACMPUB27, NEW YORK, NY, USA, December 14, 2020 (2020-12-14), pages 61-66, XP058587048, DOI: 10.1145 / 3446983.3446992 ISBN: 978-1-4503-8896-2 gives an overview of the workflow for decentralized authentication using the standard for Decentralized Identifiers (DID) and Verifiable Credentials (VC).

[0009] The work of the Verifiable Credentials (VC) Working Group in combination with the work of the Decentralized Identifiers (DID) Working Group, see e.g. https: / / www.w3.org / TR / did-usecases / of the World Wide Web Consortium, or W3C for short, deals with the standardized description of properties / assurances, also called claims, which are verifiable, see Data Model https: / / www.w3.org / TR / vc-data-model / . A key property of Verifiable Credentials (VC), also referred to as verifiable credentials, is that they are machine-verifiable. They are therefore suitable for a variety of use cases, such as proving certifications and personal data such as ID data, or for online applications for documents or access. At https: / / www.w3.org / TR / vc-use-cases describes various use cases, including the use of VC to verify the origin / authenticity of devices and the detection and exclusion of counterfeits / plagiarisms. The use of VC for licensing is not described there, and the system model underlying VC is also conceptually unsuitable for licensing.

[0010] It is therefore an object of the present invention to better and securely support an improved license check, particularly for dynamic use cases in which licenses must be renewed or changed during the operation of a device, and to provide it with low development effort.

[0011] The object is achieved by the measures described in the independent claims. Advantageous developments of the invention are presented in the subclaims. According to a first aspect, the invention relates to a method for verifying a license for the use of at least one performance feature in an Internet of Things (IoT) device using a license identifier, comprising Specifying at least one license condition for the use of the performance feature of the IoT device by at least one attribute contained in the license identifier, transferring and storing the license identifier on the IoT device, checking the license conditions by a) generating a pseudo-access associated with the performance feature of the IoT device by a pseudo-holder function implemented on the IoT device, and b) checking an authorization for the pseudo-access by checking the attributes of the license identifier by a verification function implemented on the IoT device, and activating the at least one performance feature if the pseudo-access is confirmed as permitted by a positive test result of the license identifier, wherein the license identifier, the pseudo-holder unit and the verification unit are designed based on a specification for verifiable credentials of the World Wide Web Consortium (W3C).

[0012] The license verification in the IoT device is simulated by the pseudo-holder accessing a license identifier assigned to the licensed feature using functions and processes based on the Verifiable Credential Specification of the World Wide Web Consortium. However, due to the different objectives of the license verification compared to the typical use of DID / VC for authentication between a user and a node, adaptations to the underlying technology are necessary. A key difference is that both the pseudo-holder unit and the verification unit are implemented in the IoT device, meaning that the pseudo-holder unit and the verification unit are implemented in the same IoT device. The pseudo-holder unit corresponds to a modified role of the holder, also called "holder," in the VC specification.The verification unit corresponds to a modified role of the verifier, also called "verifier", of the VC specification.

[0013] The IoT device can, for example, be a control unit of a cyber-physical system, e.g., an industrial automation system, or a communications device. The license relates to features, particularly from the physical world. Examples of features in an IoT device, particularly in an IoT Edge device, include support for specific protocols, higher / lower sampling rates, or sensor data accuracies. Examples of features in a motor vehicle include modified acceleration modes with higher or lower performance, autonomous driving, or additional online services, and the like. In the following, the IoT device is also referred to synonymously as a device.

[0014] This has the advantage that a Decentralized Identifiers (DID) / Verifiable Credential (VC) infrastructure and corresponding tools and libraries can be used to implement license protection, eliminating the need to develop a specific technical solution for managing and verifying licenses. A general DID / VC infrastructure, used for example for user authentication and authorization management, can be used to implement license verification. This allows a licensing solution to be implemented and operated with less effort than using dedicated licensing tools.

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

[0016] This has the advantage that the license identifier and thus the license conditions are not only defined and incorporated into the device before commissioning, but license conditions can also be applied to the device during operation. Furthermore, devices can be manufactured independently of their subsequent use, and the device's intended use can only be determined later, during operation.

[0017] In an advantageous embodiment, the license identifier is re-transferred to the IoT device during operation of the IoT device and the stored license identifier is replaced or supplemented.

[0018] This has the advantage of license knowledge and allows the license conditions to be renewed and / or supplemented during the lifetime of the device.

[0019] In an advantageous implementation variant, the transfer of the license identifier from a license server to the IoT device is initiated from outside the IoT device and sent to the IoT device. Alternatively, the transfer of the license identifier is initiated by an application on the IoT device itself. In this case, the license identifier is retrieved from the license server by the IoT device.

[0020] In an advantageous embodiment, the pseudo access is repeatedly generated and checked when the IoT device is started or when the feature is started on the IoT device and / or during operation.

[0021] This determines the time at which the license check is performed. The license check is performed, in particular, at the time the licensed feature is started or when the IoT device is started. Optionally, additional pseudo-accesses can be generated during operation. Depending on the result of the check, the feature can be activated or enabled at a later time, or deactivated or blocked if the check result is negative.

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

[0023] The license verification can thus be performed flexibly on IoT devices with different configurations. The proposed license verification can thus be performed on both real, physical devices and virtual devices. The hardware platform can, in particular, be a hardware-based compute platform.

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

[0025] If the IoT device is virtualized, it exists, for example, as a virtual machine (VM) image or a container image. When such an image is executed, the IoT device becomes "real" as a whole. Such an image then includes the operating system and applications, just as would be the case with a hardware-based device.

[0026] In an advantageous embodiment, the pseudo-holder unit and the verification unit are implemented on a common hardware platform. Alternatively, the pseudo-holder unit and the verification unit are implemented on different, locally interconnected platforms.

[0027] This allows license verification even on distributed IoT devices. Furthermore, by distributing the pseudo-holder unit and the verification unit across different hardware platforms, device-internal but platform-specific licensing can be implemented.

[0028] In an advantageous embodiment, the verification unit checks a who attribute in the license identifier, which specifies an IoT device authorized to activate the feature, against a verification platform identifier of the verification platform.

[0029] The who attribute can preferably be implemented as a "subject" attribute in a Verifiable Credential (VC) according to the W3C VC specification. The who attribute can be used, in particular, to verify and enforce a license bound to a specific device instance or component of a device. The who attribute specifies the device for which the license is intended. Additional environmental information such as operator ID, location, runtime environment, software application, device type, or version can be included in the who attribute. If the who attribute is empty, i.e., not assigned, no verification is performed against an executing unit of the feature.

[0030] In an advantageous embodiment, the verification unit checks a What attribute in the license identifier, which specifies further conditions for activating the feature or for activating options of the feature.

[0031] The verification unit only accepts the license identifier if the attributes confirmed in the "What" attribute, which characterize the respective permitted execution environment, match the determined characteristics of the execution environment of the feature. This allows the license conditions to be verified and enforced. Characteristics of the execution environment include, for example, an operator identifier, location, runtime environment, software application, type and / or version of the IoT device.

[0032] In an advantageous embodiment, the verification unit checks a security attribute in the license identifier, which includes a cryptographic identifier of an issuer of the license identifier.

[0033] The license identifier is only verified as valid by the verification unit, and the pseudo-access is confirmed as permitted, if the security attribute is confirmed. The security attribute includes, for example, a signature from a known and trusted licensing authority.

[0034] In an advantageous embodiment, a first license identifier is issued by an IoT device-external license creation unit and / or a second license identifier is issued by an IoT device-internal license creation unit and stored on the IoT device, and the first license identifier specifies properties of the execution environment in which the verification unit is executed, the second license identifier comprises the properties actually present in the IoT device, and the first and second license identifiers are checked by the verification unit of the license identifiers against the properties of the existing execution environment of the verification unit.

[0035] The license identifier can thus be issued not only as an initial license identifier by a license creation unit located external to the IoT device, but also by a license creation unit integrated into the IoT device. The verification unit checks whether the information about the required execution environment in the license identifier matches the information about the actual execution environment in the VC platform information.

[0036] In another embodiment, a third license identifier is issued by a confirmation issuing unit external to the IoT device. The third license identifier confirms an IoT device property, for example, that the device has not been detected as tampered with by a security monitoring system and is therefore considered untampered. The confirmation issuing unit external to the IoT device is typically different from the IoT device external issuing unit that issued the first license identifier.

[0037] In an advantageous embodiment, the license identifier is designed as an anonymous verifiable authorization certificate and the verification unit only checks the presence of at least one specific attribute, but not the content of the attribute.

[0038] An anonymous verifiable credential only makes it possible to determine whether certain attributes are present, i.e. whether they are confirmed as correct by the license holder.

[0039] In an advantageous embodiment, the feature is a software container, and the license key is used to manage and control a software container infrastructure. Alternatively, the feature is a software application or a hardware component of the IoT device.

[0040] This means that the license key can be used flexibly in different technical areas.

[0041] A second aspect of the invention relates to an arrangement for checking a license for the use of at least one performance feature in an Internet of Things (IoT) device using a license identifier, comprising a license issuing unit configured to specify at least one license condition for the use of the performance feature of the IoT device by at least one attribute contained in the license identifier, to transfer the license identifier to the IoT device, and the IoT device configured to store the license identifier, to check the license conditions by a) generating a pseudo-access associated with the performance feature of the IoT device by a pseudo-holder unit configured on the IoT device, and b) checking an authorization for the pseudo-access by checking the attributes of the license identifier by a verification unit configured on the IoT device, and to activate the at least one performance feature if the pseudo-access is confirmed as permitted by the verification unit through a positive test result of the license identifier, wherein the license identifier,The pseudo-holder unit and the verification unit are based on a specification for verifiable credentials of the World Wide Web Consortium (W3C).

[0042] The process and arrangement enable simple and automated license deployment during runtime, i.e., when the IoT device and applications are in operation. This makes the process and arrangement particularly suitable for industrial use, i.e., in cases where direct manual access to a device is frequently not possible. Only at runtime, or after successful licensing, is it determined which functionality is available to the license holder. A device can be designed in such a way that it provides initialization interfaces through which the license can be securely loaded in the form of the license identifier. This allows license terms to be adapted / replaced during the lifetime of the device.License evaluation can be implemented with fine granularity and, in addition to the device context (e.g., checking the hardware instance), also include the immediate environment (e.g., identifying the user via DID). If the device is installed in a different environment, for example, unauthorized use can be restricted or prevented in a controlled manner.

[0043] By using VC and DID, license evaluation can also be implemented in offline scenarios. This means that the devices do not require a permanent connection to a license server, making it suitable for use in isolated networks. In general, the advantages of DID and VC are transferred to the licensing process shown. This means that the licensor or license holder only needs to provide the information required for the license check for validation.

[0044] A third aspect of the invention relates to a computer program product comprising a non-transitory computer-readable medium that is directly loadable into a memory of a digital computer, comprising program code parts that, when executed by a digital computer, cause the digital computer to carry out the steps of the method.

[0045] Unless otherwise stated in the following description, the terms "specify", "transmit", "check" and the like preferably refer to actions and / or processes and / or processing steps that change and / or generate data and / or convert the data into other data, wherein the data can be represented or present in particular as physical quantities, for example as electrical impulses.

[0046] The respective "unit," for example, a license issuing unit or the IoT device, can be implemented in hardware and / or software. In a hardware implementation, the respective unit can be embodied as a device or as part of a device, for example, as a computer, a microprocessor, or a vehicle control computer. In a software implementation, the respective unit can be embodied as a computer program product, as a function, as a routine, as part of a program code, or as an executable object.

[0047] A computer program product, such as a computer program means, can be provided or delivered, for example, as a storage medium, such as a memory card, USB stick, CD-ROM, DVD, or in the form of a downloadable file from a server in a network. This can be done, for example, in a wireless communications network by transferring a corresponding file to the computer program product or the computer program means.

[0048] Embodiments of the method and system according to the invention are illustrated by way of example in the drawings and are explained in more detail in the following description. They show: Fig. 1 shows a role model of the verifiable authorization credentials, known in English as virtual credentials, according to the W3C specification "VC-data model"; Fig. 2 shows an embodiment of the method according to the invention in the form of a flowchart; Fig. 3 shows an embodiment of a data structure of a license identifier according to the invention in a schematic representation; and Fig. 4 shows an embodiment of an arrangement according to the invention with an IoT device according to the invention in a schematic representation.

[0049] Corresponding parts are provided with the same reference numerals in all figures.

[0050] The processes and roles specified by W3C according to Verifiable Credentials (VC) and Decentralized Identifiers (DID) are abbreviated as DID / VC and the corresponding Verifiable Credential is abbreviated as VC.

[0051] However, due to the different objectives in the case of license verification compared to the usual use of DID / VC for authentication between users / nodes, adaptations to the underlying technology are necessary. In a state-of-the-art VC solution, see Fig. 1 a distinction is made between the roles of issuer 11, called issuer, holder 12, called holder, verifier 13, called verifier, and subject 14. An issuer 11 issues a verifiable credential (VC) and makes it available to a holder 12. The holder 12 uses the VC to create a verifiable presentation with which it can prove certain attributes (properties, claims) confirmed by the VC from the issuer 11 to a verifier 13. In a special case, a VC can also be used directly as a verifiable presentation. The attributes confirmed by the VC are assigned to the subject. In general, the holder 12 itself can represent the subject. However, the holder 12 of a VC can also confirm attributes of the subject on behalf of a subject. A verifiable data registry 14 stores identifiers and usage schemas.

[0052] However, the present licensing solution has different roles and objectives. On the one hand, the concept of an issuer of license information is different—usually the manufacturer of the IoT device or software that implements a virtual IoT device. The device / software assumes a different role by activating certain features or authorizing their use depending on the license information. Furthermore, the objective is not to check whether an accessor is authorized, but rather to check whether the specific entity—i.e., the device / software that performs the verification itself—is allowed to activate the feature or not. There is no access by an accessor, as is the case with an access control system, for which VCs were developed.

[0053] However, the following aspects can be incorporated from a VC / DID solution into the license verification process according to the invention. A license issuing unit can assume the role of the VC issuer 11 and generate license identifiers based on VCs that generate the licensing information. The IoT device / software can assume the role of the VC verifier 13 and verify the license identifier, i.e., a provided modified VC or, more precisely, a Verifiable Presentation VP, and, depending on this, release or activate a functionality in the IoT device / software.

[0054] However, since a license check is conceptually different from a classic access control, the concepts of "Subject" and "Holder" from Verifiable Credentials VC cannot be mapped unchanged to roles of a license check.

[0055] Therefore, adaptations are proposed to implement a licensing solution using VC. The basic idea is that the IoT device performing the licensing check combines the VC roles of verifier 13 and holder 12, and possibly also the subject. Internally, it executes a pseudo-access associated with an unlockable feature. Depending on whether access is permitted according to a given license identifier based on a VC structure, the feature is enabled or unlocked.

[0056] Based on Fig. 2 an embodiment of the method is described.

[0057] To verify a license for the use of at least one feature in an Internet of Things (IoT) device, in a first process step S1, at least one license condition for the use of the feature of the IoT device is defined using at least one attribute contained in the license identifier. The license identifier is then transferred to the IoT device and stored there (see S2). In the subsequent process step S3, the license conditions are verified.

[0058] For this purpose, a pseudo-holder function implemented on the IoT device generates pseudo-access to the feature assigned to the license identifier (see step S31). Subsequently, in step S32, the verification unit of the IoT device checks whether the pseudo-access by the pseudo-holder unit is authorized. For this purpose, the verification unit checks the attributes of the license identifier. If the check of the attributes results in a positive check result, i.e., if the attributes specified as confirmed in the license identifier are fulfilled by an execution platform of the feature, the feature is activated (see step S4). If the check result is negative and at least one of the attributes is not fulfilled, the activation of the feature is refused and therefore not executed.For the verification of the license identifier, in particular the license identifier, the pseudo-holder unit and the verification unit, processes and procedures are developed based on a specification for verifiable credentials of the World Wide Web Consortium (W3C).

[0059] The IoT device is embodied as a physically independent device or as a software-based virtual device distributed across one or more hardware platforms. Pseudo-access can occur, in particular, at the time the IoT device is started. Optionally, further pseudo-accesses can be repeated during operation, and depending on the result, a feature can be enabled or enabled at a later time, or deactivated or blocked if the result is negative. The pseudo-holder unit can be embodied, for example, as part of a software application, as part of an execution environment of the software application, or by an operating system of the IoT device. The holder is referred to as a pseudo-holder unit because it is not an accessor, but merely a local unit that provides the license identifier to the verification unit.

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

[0061] The license examination, see S3 in Fig. 2 , is performed by the verification unit of the IoT device. In the following description, reference is made to the Fig. 4 The IoT device 50 shown is referenced. The IoT device 50 comprises a pseudo-holder unit 52, a verification unit 52, and a hardware component 55, for example, a trust anchor of the IoT device. The pseudo-holder unit 52 receives the license identifier LK, for example, via a service interface 57, and stores it.

[0062] The pseudo-holder unit 52 is implemented on the platform of the IoT device 50, for example, a processor or a software container or part of a software container on which the license check is to be implemented in a verification unit 53. This pseudo-holder unit 52 loads the license identifier and provides it locally to the verification unit 53. The license identifier LK is provided, for example, from a local file system, via a configuration interface, from a download server, from a device management server, from a DID infrastructure, from a database, from a distributed database infrastructure, or from a web service. The provisioning 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 the pseudo-access, which serves to capture the at least one relevant license identifier LK and provide it locally to the verification unit 53.

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

[0064] 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. The security attribute is cryptographically verified and checks whether the license identifier LK was issued by a known and trusted licensing authority.

[0065] The verification unit 53 further checks whether the "Wer" attribute contained in the license identifier LK, which is preferably based on the "Subject" attribute of the VC, matches the current execution environment of the verification unit 53. In one variant, the verification unit 53 determines information about the current execution environment of the verification unit 53 itself. This information can, for example, be a hardware identifier (hardware ID). The "Wer" attribute does not have the conventional meaning of a VC, but rather represents a verification criterion, in particular an IoT device authorized to activate the feature, which is verified by the verification unit 53 itself against a verification platform identifier of the verification platform.

[0066] This step is optional, as the "Who" attribute does not need to be set. For licenses that are not tied to a specific execution environment, such as a device instance, the "Who" attribute is free or undefined. Instead of the "Subject" attribute, a differently named attribute can also be used in a VC to specify the target execution environment in the license identifier (LK).

[0067] Furthermore, a "What" attribute in the license identifier LK is checked by the verification unit 53. The "What" attribute specifies further conditions for activating the feature or for activating options of the feature. The "What" attribute is preferably represented by the "Claim" attribute of a VC. The verification unit 53 accepts the license identifier LK or the verifiable presentation created from it only if the conditions contained in the "What" attribute, which characterize the respective permissible execution environment, match the determined characteristics of the execution environment. For this purpose, the features in the IoT device are checked to determine which of the features is enabled by this license identifier LK. For this purpose, a list of possible feature parameters is checked. It is checked whether they are confirmed as correct by the "What" attribute in the license identifier LK.If this is the case, only the features specified as permissible in the license identifier LK are activated or released by the verification unit 53.

[0068] Fig. 3 shows an example of an embodiment of a data structure according to the invention of a license identifier 30 in a machine-readable encoding of license terms. The license identifier 30 preferably refers to the W3C Verifiable Credential specification in a "@context" parameter. The document contains attributes typical for verifiable credentials. A unique identifier for a license is specified in the "id" 34 attribute. For automated evaluation, a Verifiable Credential VC is specified in the "type" 35 attribute under reference character 36, and a license identifier with "SWLic" is specified under reference character 37. The "Issuer", "IssDate", and "ExpDate" attributes contain information about a license issuing entity issuing the license identifier 30, or generally a licensor, an issue date, and its expiration date. The "ExpDate" attribute is only filled in the case of a time-limited license identifier.

[0069] The license identifier 30 comprises the 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 typically contained in the "Subject" attribute, a what attribute W2-Att 32 in the "Claim" attribute, and a security attribute S-Att 33 in the "Proof" attribute of a VC.

[0070] Since there is no accessor in the classic sense of a VC during the license check, the who attribute 31 or a subject specification in the license identifier 30 can be omitted or used for another purpose, for example, to encode information about the target specification. However, the who attribute 31 is preferably used to encode an explicit target specification. This is, for example, the IoT device 50 for which the license is intended. In a further embodiment according to the invention, further environmental information such as an operator ID, location, runtime environment, software application, device type, and version can be included in the who attribute 31.

[0071] As already mentioned above, Fig. 4 An embodiment of an arrangement according to the invention comprising the IoT device 50, for example, an industrial device, and an external license issuing unit 43. The device 50 is arranged in an environment of a licensor 41, for example, a factory. The license issuing unit 43 is arranged, for example, in an environment of a provider 42 of the application or feature, for example, in a cloud backend. The device 50 comprises a pseudo-holder unit 52 with 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 or confirms the license identifier LK and transmits it to the IoT device 50. This can be done via a manufacturing operations management unit 44.

[0072] A feature, such as an application, starts and is ready to use, but does not yet perform any functionality that requires a license.

[0073] The license identifier LK not only positively confirms attributes as correct, but in one implementation variant also defines additional necessary checks that are verified by the verification unit 53. The attributes positively confirmed in the license identifier LK may only be used as correct if the defined additional checks are verified as correct. This occurs independently of a verifiable credentials system or by checking additional verifiable credentials.

[0074] In one variant, a second license issuing device 56 located locally at the execution level of the virtual or physically real IoT device 50 provides a second license identifier LK2, which confirms properties of the execution environment in which the verification unit 53 is executed. This second license identifier LK2 can also be referred to as VC platform information, since it confirms the platform on which a functionality, in this case the verification unit 53, is executed. In this case, the verification unit 53 checks whether the information regarding the required execution environment in the second license identifier matches the information regarding the actual execution environment in a VC platform information.

[0075] When using a license identifier that is designed as an anonymous verifiable authorization credential, 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 only makes it possible to determine whether certain attributes are present, i.e., whether they are confirmed as correct by the anonymous license identifier, in the form of a verifiable credential (VC) or a verifiable presentation. However, the information cannot be read directly as with explicitly encoded license identifier data structures; rather, it can only be determined by checking whether a certain attribute is confirmed as correct by the anonymous license identifier. An anonymous license identifier represents the statements confirmed by the license issuing unit 43 in a tamper-proof and privacy-protected manner. The check is performed in a similar way to the general description above.The difference is that the anonymous license identifier or its verifiable presentation does not contain the corresponding information in an explicitly encoded form in the attributes, but in a privacy-protected form that only allows the existence of attributes to be checked.

[0076] In a further training, the license key also contains meta-information that defines the scope of the "scope" test, i.e., the set of attributes to be checked.

[0077] To perform the license check, also called license enforcement, the validity of the license identifier is verified by verifying the security attribute, ie a signature of the licensor or the license issuing authority 43. In addition, depending on the license criteria to be checked, a runtime environment 54 is also checked. In the Fig. 4In the example shown, the license is tied to a specific hardware instance. This can also be cryptographically verified, for which purpose the hardware instance's authorization credentials, also called credentials, are used, for example, via a hardware-based or hardware-bound trust anchor 55. To verify a deployment environment, the license check can, for example, also include verifying that the application is only operated in a valid customer environment. For this purpose, a "client" attribute is provided as part of the How attribute 32. It is encoded by a DID. The check can, for example, be performed by passing an additional third license identifier that identifies the license holder.

[0078] The license verification procedure demonstrated can be used efficiently, for example, for managing / controlling container infrastructures. Containers, a container image, a virtual machine image, or an application can only be started if the corresponding VC (which expresses the license) is present. Furthermore, functionalities of an app execution environment (Runtime Environment RTE, especially of an edge component), such as load balancing, migration of running instances, failover, full memory encryption, disk encryption, and confidential computing, can be enabled depending on a VC license. Furthermore, the use of hardware accelerators, such as a graphics processor (GPU), an AI accelerator, a crypto accelerator, or a network accelerator, can be enabled depending on VC license information.

[0079] Following successful license validation, the license identifier can be stored on the device. This allows a new license check to be performed upon startup after restarting the IoT device / application, eliminating the need for re-initialization. License identifiers can therefore be used similarly to license files.

[0080] All method steps can be implemented by the corresponding devices suitable for carrying out the respective method step. All functions that can be performed by physical features can be a method step of the method. All described and / or illustrated features can be advantageously combined with one another within the scope of the invention. The invention is not limited to the described embodiments.

Claims

1. Method for checking a license for using at least one performance feature in an Internet-of-Things (IoT) device (50) on the basis of a license identifier (LK), comprising - stipulating (S1) at least one license condition for using the performance feature of the IoT device (50) by means of at least one attribute contained in the license identifier (LK), - transmitting and storing (S2) the license identifier (LK) on the IoT device (50), - checking (S3) the license conditions by a) generating (S31) pseudo-access assigned to the performance feature of the IoT device (50) by means of a pseudo-holder unit (52) formed on the IoT device (50), and b) checking (S32) an authorization for the pseudo-access by checking the attributes of the license identifier (LK) by means of a verification unit (53) formed on the IoT device (50), and - activating (S4) the at least one performance feature if the pseudo-access is confirmed as permitted by a positive checking result for the license identifier (LK), wherein the license identifier (LK), the pseudo-holder unit (52) and the verification unit (53) are designed on the basis of a specification for verifiable credentials of a World Wide Web Consortium (W3C for short), and the license identifier (LK) is based on a structure of the verifiable credentials, 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 verification unit (53) with the license identifier (LK) .

2. 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. Method according to one of the preceding claims, wherein the license identifier (LK) is transmitted again to the IoT device (50) during operation of the IoT device (50) and the stored license identifier (LK) is replaced or supplemented.

4. Method according to one of the preceding claims, wherein the pseudo-access is generated and checked when starting the IoT device (50) or when starting the performance feature on the IoT device (50), and / or the pseudo-access is repeatedly generated and checked during operation.

5. Method according to one of the preceding claims, wherein the IoT device (50) is in the form of a physically independent device or is in the form of a software-based virtual device distributed over one or more hardware platforms.

6. Method according to one of the preceding claims, wherein the pseudo-holder unit (52) of the IoT device (50) is formed as part of a software application, as part of an execution environment of the software application or by an operating system of the IoT device (50).

7. Method according to one of the preceding claims, 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 that are locally connected to one another.

8. Method according to Claim 7, wherein the verification unit (53) checks a who attribute (31) in the license identifier (30, LK), which indicates an IoT device (50) authorized to activate the performance feature, against a verification platform identifier of the verification platform.

9. Method according to one of the preceding claims, wherein the verification unit (53) checks a what attribute (32) in the license identifier (30, LK), which indicates further conditions for activating the performance feature or for activating options of the performance feature.

10. Method according to one of the preceding claims, wherein the verification unit (53) checks a security attribute (33) in the license identifier (30, LK), which comprises a cryptographic identifier of an issuer of the license identifier (30, LK).

11. Method according to one of Claims 8 to 10, wherein a first license identifier (LK1) is issued by a license creation unit outside the IoT device and / or a second license identifier (LK2) is issued by a license creation unit inside the IoT device and is stored on the IoT device (50), and the first license identifier (LK1) specifies properties of the execution environment in which the verification unit (53) is executed, the second license identifier (LK2) comprises the properties actually available in the IoT device (50), and the first and second license identifiers (LK1, LK2) are checked by the verification unit (53) against the properties of the present execution environment of the verification unit (53).

12. Method according to one of the preceding claims, wherein the license identifier (LK) is in the form of an anonymous verifiable credential, and the verification unit (53) checks only the presence of at least one specific attribute, but not the content of the attribute.

13. Method according to one of the preceding claims, 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.

14. Arrangement for checking a license for using at least one performance feature in an Internet-of-Things (IoT) device (50) on the basis of a license identifier (LK), comprising a license issuing unit (43) which is designed - to stipulate at least one license condition for using the performance feature of the IoT device (50) by means of at least one attribute contained in the license identifier (LK), - to transmit the license identifier to the IoT device (50), and the IoT device (50) is designed - to store the license identifier (LK), - to check the license conditions by a) generating pseudo-access assigned to the performance feature of the IoT device (50) by means of a pseudo-holder unit (52) formed on the IoT device (50), and b) checking an authorization for the pseudo-access by checking the attributes of the license identifier (LK) by means of a verification unit (53) formed on the IoT device, and - to activate the at least one performance feature if the pseudo-access is confirmed as permitted by a positive checking result for the license identifier (LK), wherein the license identifier (LK), the pseudo-holder unit (52) and the verification unit (53) are designed on the basis of a specification for verifiable credentials of the World Wide Web Consortium (W3C for short), and the license identifier (LK) is based on a structure of the verifiable credentials, the verification unit (53) corresponds to a modified verifier and the pseudo-holder unit (52) corresponds to modified holder which is formed as a local unit on the IoT device (50) and provides the verification unit (53) with the license identifier (LK).

15. Computer program product comprising a non-volatile computer-readable medium which can be loaded directly into a memory of a digital computer, comprising program code parts which, when the program code parts are executed by a digital computer, cause the latter to carry out the steps of the method according to one of Claims 1 to 13.