Secure network onboarding of network devices

Abstract

There are provided measures for secure network onboarding of network devices Such measures exemplarily comprise establishing connection with a device to be securely onboarded into a network, transmitting, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, and receiving, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device.

Description

[0001] SECURE NETWORK ONBOARDING OF NETWORK DEVICES

[0002] Field

[0003] Various example embodiments relate to secure network onboarding of network devices. More specifically, various example embodiments exemplarily relate to measures (including methods, apparatuses and computer program products) for realizing secure network onboarding of network devices, and in particular, of internet of things (loT) devices.

[0004] Backo round

[0005] The present specification generally relates to integration and onboarding of loT devices into mobile networks such as 3rdGeneration Partnership Project (3GPP) 6thGeneration (6G) and beyond networks.

[0006] While such loT devices often do not support a subscriber identity module (SIM), for flexible application and operation of loT devices and similar, an integration and onboarding of such loT devices and similar into such mobile networks and the support of such integration and onboarding of loT devices and similar by mobile networks would be necessary.

[0007] Hence, the problem arises that mechanics are to be provided which allow integration and onboarding of loT devices and similar into mobile networks.

[0008] Hence, there is a need to provide for secure network onboarding of network devices.

[0009] Various example embodiments aim at addressing at least part of the above issues and / or problems and drawbacks.

[0010] Various aspects of example embodiments are set out in the appended claims.

[0011] According to an exemplary aspect, there is provided a method, comprising establishing connection with a device to be securely onboarded into a network,transmitting, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, and receiving, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device.

[0012] According to an exemplary aspect, there is provided an apparatus connectable with a device to be securely onboarded into a network, the apparatus comprising establishing circuitry configured to establish connection with said device to be securely onboarded into said network, transmitting circuitry configured to transmit, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, and receiving circuitry configured to receive, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device.

[0013] According to an exemplary aspect, there is provided an apparatus connectable with a device to be securely onboarded into a network, the apparatus comprising at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform establishing connection with said device to be securely onboarded into said network, transmitting, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, and receiving, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device.

[0014] According to an exemplary aspect, there is provided a method, comprising establishing connection with a verified device to be securely onboarded into a network, receiving, from said verified device, a credential request for said verified device, said credential request including an identifier of said verified device, addingan own identifier to said credential request, and transmitting, towards a network entity of said network, said credential request including said own identifier.

[0015] According to an exemplary aspect, there is provided an apparatus connectable with a device to be securely onboarded into a network, the apparatus comprising establishing circuitry configured to establish connection with a verified device to be securely onboarded into a network, receiving circuitry configured to receive, from said verified device, a credential request for said verified device, said credential request including an identifier of said verified device, adding circuitry configured to add an own identifier to said credential request, and transmitting circuitry configured to transmit, towards a network entity of said network, said credential request including said own identifier.

[0016] According to an exemplary aspect, there is provided an apparatus connectable with a device to be securely onboarded into a network, the apparatus comprising at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform establishing connection with a verified device to be securely onboarded into a network, receiving, from said verified device, a credential request for said verified device, said credential request including an identifier of said verified device, adding an own identifier to said credential request, and transmitting, towards a network entity of said network, said credential request including said own identifier.

[0017] According to an exemplary aspect, there is provided a computer program product comprising computer-executable computer program code which, when the program is run on a computer (e.g. a computer of an apparatus according to any one of the aforementioned apparatus-related exemplary aspects of the present disclosure), is configured to cause the computer to carry out the method according to any one of the aforementioned method-related exemplary aspects of the present disclosure.

[0018] Such computer program product may comprise (or be embodied) a (tangible) computer-readable (storage) medium or the like on which the computer-executable computer program code is stored, and / or the program may be directly loadable into an internal memory of the computer or a processor thereof.Any one of the above aspects enables an efficient application and operation of loT devices and similar in mobile networks even if the devices do not support a SIM, to thereby solve at least part of the problems and drawbacks identified in relation to the prior art.

[0019] By way of example embodiments, there is provided secure network onboarding of network devices. More specifically, by way of example embodiments, there are provided measures and mechanisms for realizing secure network onboarding of network devices.

[0020] Thus, improvement is achieved by methods, apparatuses and computer program products enabling / realizing secure network onboarding of network devices.

[0021] Brief description of the drawings

[0022] In the following, the present disclosure will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which

[0023] FIG. 1 is a block diagram illustrating an apparatus according to example embodiments,

[0024] FIG. 2 is a block diagram illustrating an apparatus according to example embodiments,

[0025] FIG. 3 is a schematic diagram of a procedure according to example embodiments,

[0026] FIG. 4 is a block diagram illustrating an apparatus according to example embodiments,

[0027] FIG. 5 is a schematic diagram of a procedure according to example embodiments,

[0028] FIG. 6 shows a schematic diagram of an example of a system environment with signaling variants,

[0029] FIG. 7 is a schematic diagram of a procedure in such example system environment of FIG. 6,FIG. 8 shows a schematic diagram of signaling sequences according to example embodiments,

[0030] FIG. 9 shows a schematic diagram of signaling sequences according to example embodiments, and

[0031] FIG. 10 is a block diagram alternatively illustrating apparatuses according to example embodiments.

[0032] Detailed description

[0033] The present disclosure is described herein with reference to particular non-limiting examples and to what are presently considered to be conceivable embodiments. A person skilled in the art will appreciate that the disclosure is by no means limited to these examples, and may be more broadly applied.

[0034] It is to be noted that the following description of the present disclosure and its embodiments mainly refers to specifications being used as non-limiting examples for certain exemplary network configurations and deployments. Namely, the present disclosure and its embodiments are mainly described in relation to 3GPP specifications being used as non-limiting examples for certain exemplary network configurations and deployments. As such, the description of example embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the disclosure in any way. Rather, any other communication or communication related system deployment, etc. may also be utilized as long as compliant with the features described herein.

[0035] Hereinafter, various embodiments and implementations of the present disclosure and its aspects or embodiments are described using several variants and / or alternatives. It is generally noted that, according to certain needs and constraints, all of the described variants and / or alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various variants and / or alternatives).As used herein, "at least one of the following: " and "at least one of " and similar wording, where the list of two or more elements are joined by "and" or "or", mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0036] According to example embodiments, in general terms, there are provided measures and mechanisms for (enabling / realizing) secure network onboarding of network devices.

[0037] Bootstrapping remote secure key infrastructure (BRSKI) is an Internet Engineering Task Force (IETF) -standardized protocol designed to automate the secure onboarding of devices, primarily in loT and industrial environments.

[0038] The protocol enables new or reset devices to authenticate with a network securely and receive cryptographic credentials with minimum human intervention.

[0039] BRSKI leverages public key infrastructure (PKI) and builds on the enrollment over secure transport (EST) protocol to establish a trusted device identity.

[0040] Key components of BRSKI are a pledge, a registrar, a manufacturer authorized signing authority (MASA), and a voucher.

[0041] The pledge is in general a new or factory-reset device. The new or factory-reset device initiates the onboarding process by connecting to a network that will issue it a secure identity.

[0042] The registrar is a trusted network entity responsible for authenticating the pledge and issuing it credentials. The registrar facilitates certificate enrollment and acts as an intermediary between the pledge and a PKI-based authorization server (MASA).

[0043] The MASA is a remote PKI-based server managed by the device manufacturer. The MASA holds information about valid devices and can authorize or deny their network access based on device authenticity and compliance records. The MASA provides vouchers to certify the device's identity to the registrar.A voucher is a cryptographically signed artifact issued by the MASA to the registrar and then relayed to the pledge. This voucher authorizes the pledge's identity and allows the device to trust the network, certifying that it has been onboarded securely.

[0044] A BRSKI workflow includes discovery, initial contact and authentication, voucher request and verification, certificate enrollment, and secure configuration.

[0045] In the discovery step of the BRSKI workflow, the pledge discovers the registrar on the network, usually through mechanisms like domain name system service discovery (DNS-SD) or multicast domain name system (mDNS).

[0046] In the initial contact and authentication step of the BRSKI workflow, the pledge connects to the registrar, establishing an HTTPS (TLS) connection for initial security. The pledge provides its initial device identifier (IDevID), an identity provisioned by the manufacturer. An Initial Device Identifier (IDevID) is an IEEE 802.1AR-compliant X.509 certificate that is unique to each device. The IDevID certificate follows the X.509 format and contains:

[0047] • A unique Subject Distinguished Name (DN)

[0048] • A Public Key

[0049] • A Manufacturer-issued Signature

[0050] • The Manufacturer's Root Certificate Authority (CA)

[0051] The corresponding private key is securely stored in the device / pledge and is not accessible or replaceable by the user.

[0052] In the voucher request and verification step of the BRSKI workflow, the registrar contacts MASA to verify the pledge's authenticity and request a voucher, and the MASA checks the pledge's details and generates a voucher if the pledge is legitimate. This voucher is then relayed back to the pledge through the registrar.

[0053] In the certificate enrollment step of the BRSKI workflow, with the voucher verified, the pledge can request a certificate from the registrar through enrollment over secure transport (EST). EST enables the device to enroll in the PKI infrastructure, obtaining a locally significant device identifier (LDevID) for further secure communications.

[0054] In the secure configuration step of the BRSKI workflow, once the certificate enrollment completes, the pledge is considered authenticated, registered, and cansecurely communicate on the network. Any subsequent connections by the pledge to network resources are authenticated by the PKI infrastructure.

[0055] FIG. 6 shows a schematic diagram of an example of a system environment with signaling variants, and in particular illustrates a multivendor network implementing principles of BRSKI.

[0056] In such multivendor network, there could be a manufacturer service for each manufacturer that supports devices, or an integrator could provide a generic service authorized by multiple manufacturers.

[0057] It is, however, unlikely that an integrator could provide ownership tracking services for multiple manufacturers due to the required sales channel integrations necessary to track ownership.

[0058] The domain is the managed network infrastructure with a key infrastructure that the pledge (e.g., loT device) is joining.

[0059] The domain provides initial device connectivity sufficient for bootstrapping through a proxy. The domain registrar authenticates the pledge, makes authorization decisions, and distributes vouchers obtained from the manufacturer service.

[0060] Optionally, the registrar also acts as a PKI certificate authority (CA).

[0061] FIG. 7 is a schematic diagram of a procedure in such example system environment of FIG. 6, and in particular illustrates states of the pledge.

[0062] In a step 1 of FIG. 7, the pledge discovers a communication channel to a registrar.

[0063] In a step 2 of FIG. 7, the pledge identifies itself. This is done by presenting e.g. an X.509 IDevID credential to the discovered registrar (via the proxy) in a TLS handshake. The registrar credentials may be only provisionally accepted at this time.

[0064] In a step 3 of FIG. 7, the pledge requests to join the discovered registrar. A unique nonce is included, ensuring that any responses can be associated with this particular bootstrapping attempt.In a step 4 of FIG. 7, the pledge imprints on the registrar. This requires verification of the manufacturer-service-provided voucher. A voucher contains sufficient information for the pledge to complete authentication of a registrar.

[0065] In a step 1 of FIG. 7, the pledge enrolls. After imprint, an authenticated TLS (HTTPS) connection exists between the pledge and the registrar. EST can then be used to obtain a domain certificate from a registrar.

[0066] As a result, the pledge is a member of, and can be managed by, the domain and will only repeat the discovery aspects of bootstrapping if it is returned to factory default settings.

[0067] As mentioned above, with a focus to mobile networks such as 6G and beyond, it is to be considered that many loT devices will not support SIM card. However, 6G network needs to support also those devices.

[0068] Namely, dynamic onboarding of loT devices (e.g. bought from a loT device manufacturer) in a network operated e.g. by a telecom operator directly without inserting a SIM card is very much required in 6G to speedily onboard the IOT devices.

[0069] While BRSKI may be considered as providing the framework in IETF, the BRSKI framework cannot be adopted as is in 6G.

[0070] In particular, the 3GPP / 6G Core (6GC) has to be prepared / enhanced for such operation exploiting the BRSKI framework.

[0071] More specifically, the 3GPP / 6G Core has to be prepared / enhanced for provision of loT credentials and handling thereof by a 3GPP entity from an external server.

[0072] Further, the 3GPP / 6G Core has to be prepared / enhanced for interaction needed between 3GPP and non-3GPP entity for loT device to make it up and running.

[0073] It is in this regard to be further considered that many loT devices are not provisioned with any symmetric credentials like long term Key.Hence, in brief, according to example embodiments, mechanics for a MASA validation and voucher retrieval phase and mechanics for a credential provisioning phase are provided.

[0074] Namely, in the MASA validation and voucher retrieval phase, an loT device may be bought by a user owning a terminal such as a user equipment (UE), according to example embodiments, the user connects the loT device to the UE via device-to-device (D2D) connection (e.g. Bluetooth, etc.), according to further example embodiments, the loT device sends a voucher request to the UE which is then forwarded via 6G mobility management network function (MM NF) and sent to a MASA server (application function (AF)), according to still further example embodiments, the MASA server validates the loT device and provides a voucher to the 3GPP network (domain registrar), and, according to still further embodiments, the domain registrar / domain register provides an loT ID and a voucher to the UE, and the UE provides the loT ID and the voucher to the loT device after verification. According to example embodiments, the operator CA identity and root certificates of the CA is provided as well to the loT device. Further, the UE also indicates the approved loT voucher to the 6G MM NF, and the 6G MM NF sends a provision IDevID certificate to the operator CA.

[0075] Further, in the credential provisioning phase, according to example embodiments, the loT device goes via UE. In particular, the loT device sends an loT credentials request with an loT device ID to the UE, and the UE adds its own UE ID before forwarding it to the 6G MM NF. According to further example embodiments, the 6G MM NF fetches the credentials and policy information for the loT device. According to still further example embodiments, the 6G MM NF forwards the credentials and policy information for the loT device to the loT device via the UE. Credentials and policies are stored in the loT device.

[0076] Example embodiments are specified below in more detail.

[0077] FIG. 1 is a block diagram illustrating an apparatus according to example embodiments. The apparatus may be a terminal 10 such as a user equipment (terminal, user equipment, mobile station, modem, etc.) comprising an establishing circuitry 11, a transmitting circuitry 12, and a receiving circuitry 13. The establishing circuitry 11 establishes connection with a device to be securely onboarded into anetwork. The transmitting circuitry 12 transmits, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device. The receiving circuitry 13 receives, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device. FIG. 3 is a schematic diagram of a procedure according to example embodiments. The apparatus according to FIG. 1 may perform the method of FIG. 3 but is not limited to this method. The method of FIG. 3 may be performed by the apparatus of FIG. 1 but is not limited to being performed by this apparatus.

[0078] As shown in FIG. 3, a procedure according to example embodiments comprises an operation of establishing (S31) connection with a device to be securely onboarded into a network, an operation of transmitting (S32), towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, and an operation of receiving (S33), from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device.

[0079] FIG. 2 is a block diagram illustrating an apparatus according to example embodiments. In particular, FIG. 2 illustrates a variation of the apparatus shown in FIG. 1. The apparatus according to FIG. 2 may thus further comprise a performing circuitry 21 and / or a changing circuitry 22.

[0080] In an embodiment at least some of the functionalities of the apparatus shown in FIG.

[0081] 1 (or 2) may be shared between two physically separate devices forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes.

[0082] According to a variation of the procedure shown in FIG. 3, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to exampleembodiments may comprise an operation of receiving, from said device, said request for said voucher for said device, and an operation of transmitting, towards said device, said voucher response including said voucher for said device.

[0083] According to further example embodiments, said request for said voucher for said device includes a first identifier of said device, a serial number of said device, and information on a manufacturer authorized signing authority entity managed by a manufacturer of said device.

[0084] According to further example embodiments, said first identifier of said device includes at least one of the following:

[0085] a device level identifier related to said device, or

[0086] an application level identifier related to said device, or

[0087] a protocol specific identifier related to said device, or

[0088] a context specific identifier related to said device, or

[0089] a network level identifier related to said device.

[0090] According to further example embodiments, said voucher response includes a second identifier of said device, manufacture information on said device, and certificate related information.

[0091] According to a variation of the procedure shown in FIG. 3, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of performing a verification processing of said device utilizing said manufacture information on said device.

[0092] According to further example embodiments, said verification processing includes receipt of a user input related to verification of said device based on said manufacture information on said device.

[0093] According to a variation of the procedure shown in FIG. 3, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, said voucher response includes information on a degree of verification of said device, an exemplary method according to example embodiments may comprise an operation of changing, if said information on saiddegree of verification of said device is indicative of incompleteness of verification of said device, and if, as a result of said verification processing, said device is verified, said information on said degree of verification of said device to be indicative of completeness of verification of said device.

[0094] According to a variation of the procedure shown in FIG. 3, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of transmitting, towards said network entity of said network, if, as a result of said verification processing, said device is verified, information on approval of said device.

[0095] According to further example embodiments, said voucher response includes information on a domain type for which said device is designed, and validity information on a type of said voucher.

[0096] According to further example embodiments, said domain type includes at least one of the following:

[0097] a medical domain, or

[0098] an industrial domain, or

[0099] a software as a service domain, or

[0100] an automotive domain, or

[0101] a variable domain.

[0102] According to further example embodiments, said type of said voucher includes at least one of the following:

[0103] owner authorized, or

[0104] provisional, or

[0105] permanent, or

[0106] time limited.

[0107] According to further example embodiments, said connection is a device-to-device connection.

[0108] According to further example embodiments, said connection is a Bluetooth connection.According to further example embodiments, said network entity of said network is a 6G mobility management network function entity.

[0109] FIG. 4 is a block diagram illustrating an apparatus according to example embodiments. The apparatus may be a terminal 10 such as a user equipment (terminal, user equipment, mobile station, modem, etc.) comprising an establishing circuitry 41, a receiving circuitry 42, an adding circuitry 43, and a transmitting circuitry 44. The establishing circuitry 41 establishes connection with a verified device to be securely onboarded into a network. The receiving circuitry 42 receives, from said verified device, a credential request for said verified device, said credential request including an identifier of said verified device. The adding circuitry 43 adds an own identifier to said credential request. The transmitting circuitry 44 transmits, towards a network entity of said network, said credential request including said own identifier. FIG. 5 is a schematic diagram of a procedure according to example embodiments. The apparatus according to FIG. 4 may perform the method of FIG. 5 but is not limited to this method. The method of FIG. 5 may be performed by the apparatus of FIG. 4 but is not limited to being performed by this apparatus.

[0110] As shown in FIG. 5, a procedure according to example embodiments comprises an operation of establishing (S51) connection with a verified device to be securely onboarded into a network, an operation of receiving (S52), from said verified device, a credential request for said verified device, said credential request including an identifier of said verified device, an operation of adding (S53) an own identifier to said credential request, and an operation of transmitting (S54), towards a network entity of said network, said credential request including said own identifier.

[0111] In an embodiment at least some of the functionalities of the apparatus shown in FIG.

[0112] 4 may be shared between two physically separate devices forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes.

[0113] According to a variation of the procedure shown in FIG. 5, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to exampleembodiments may comprise an operation of receiving, from said network entity of said network, a credential response, said credential response including information indicative of a granted access of said verified device to said network and operator credentials provisioned for said verified device.

[0114] According to further example embodiments, said operator credentials provisioned for said verified device are non-certificate-based credentials.

[0115] According to further example embodiments, said credential response includes information indicative of access related policies for said verified device.

[0116] According to a variation of the procedure shown in FIG. 5, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of transmitting, towards said verified device, said credential response.

[0117] According to further example embodiments, said verified device is verified by means of verification processing utilizing manufacture information on said verified device.

[0118] According to further example embodiments, said verification processing includes receipt of a user input related to verification of said verified device based on said manufacture information on said verified device.

[0119] According to further example embodiments, said identifier of said verified device includes at least one of the following:

[0120] a device level identifier related to said device, or

[0121] an application level identifier related to said device, or

[0122] a protocol specific identifier related to said device, or

[0123] a context specific identifier related to said device, or

[0124] a network level identifier related to said device.

[0125] According to further example embodiments, said connection is a device-to-device connection.According to further example embodiments, said connection is a Bluetooth connection.

[0126] According to further example embodiments, said own identifier is a terminal identifier, a user equipment identifier, a mobile station identifier, or a modem identifier.

[0127] According to further example embodiments, said network entity of said network is a 6G mobility management network function entity.

[0128] Example embodiments outlined and specified above are explained below in more specific terms.

[0129] FIG. 8 shows a schematic diagram of signaling sequences according to example embodiments, and in particular illustrates the above mentioned MASA validation and voucher retrieval phase.

[0130] In a step 1 of FIG. 8, an example customer bought a number of (e.g. 1000) loT devices and provides respective serial numbers to operators, and operators create profiles but marks them suspended.

[0131] In a step 2 of FIG. 8, according to example embodiments, during initial boot of an loT device, the loT device / IoT-UEl (i.e., new loT device) uses auto discovery (e.g. similar to proximity- based service (ProSe)) or configuration to connect to operator and to locate a 6G UE (e.g. UE2) or 6G NodeB.

[0132] According to example embodiments, the (end-)user who is the owner of UE2 connects the loT device / IoT-UEl with UE2 via D2D technology such as Bluetooth, etc. The loT device could connect via 6G UE (UE2) or NodeB to the local registrar (e.g. 6G MM NF). According to example embodiments, in such case, the 6G UE (UE2) or 6G NodeB would act as a relay to exchange the traffic between the loT device and 6G MM NF.

[0133] In a step 3 of FIG. 8, according to example embodiments, the loT device (loT-UEl) sends a voucher request with loT serial number, IDevID certificate with MASA information. The MASA information is used by the 6G MM NF to route the messages to MASA (external non-3GPP entity) AF.The loT voucher request is forwarded by the 6G MM NF towards MASA. According to example embodiments, the 6G MM NF also includes a 6G MM NF signature using a key pair (e.g. pre-shared between MASA and domain registrar).

[0134] In a step 4 of FIG. 8, according to example embodiments, the MASA verifies the claims sent by the loT device (loT-UEl) and issues the voucher. The voucher contains several information which could be used by the loT device (loT-UEl) and also by the 6G MM NF for further verification.

[0135] According to example embodiments, after the 6G MM NF examines the voucher (the assertion type may be for example "partial"), and derives device information from it which compromises e.g. Device Type, Make and Model.

[0136] According to example embodiments, the 6G MM NF assigns an loT ID (loT ID is used for future reference in the 6G MM NF, e.g. later during credential provisioning phase) and an operator CA identity, a root certificate of the CA along with a policy (policy is not mandatory at this step, but, according to example embodiments, can also be configure later) in the NAS response to the UE device (UE2).

[0137] According to example embodiments, the UE (UE2) stores the device information (e.g. Device Type, Make and Model). According to example embodiments, the (end-)user (of UE2) is prompted to verify the device information (corresponding to loT-UEl).

[0138] According to example embodiments, if the end-user gives consent (based on the device information (corresponding to loT-UEl)) that it is the same loT device that the end-user wants to join the network, the assertion type may be changed from "partial" to "completed" (completely verified).

[0139] It is noted that MASA will only validate if it is a legitimate loT device or not, but MASA cannot validate if it is same device the UE intends to join the network or not. The device information helps the (end-)user cross-check the device details to identify if it is indeed the same device or not.

[0140] According to example embodiments, the UE notifies the domain registrar (6G MM NF) that loT voucher is approved by the end-user.According to example embodiments, then, the 6G MM NF (registrar) provisions the IDevID certificate to the operator CA. The UE (UE2) sends the loT voucher response with the voucher, loT ID, operator CA identity, root certificate of the CA, and optionally the policy for loT device.

[0141] In a step 5 of FIG. 8, according to example embodiments, the new certificate is provisioned to the loT device (e.g., using EST RFC7030) via UE (UE2). Step 5 may correspond to the credential provisioning phase (UE (UE2) acting as trust broker) explained below with reference to FIG. 9. The credential provisioning phase may follow a certificate-based approach. Namely, if the certificate-based authentication is used, the loT will fetch the certificate from CA directly. On the other hand, the credential provisioning phase may follow a non-certificate-based approach.

[0142] In a step 6 of FIG. 8, according to example embodiments, the loT device registers with the network after the client certificate is provisioned.

[0143] According to example embodiments, the loT voucher request (message) may be structured as follows:

[0144] loT Voucher request

[0145] Message definition

[0146] The IOT VOUCHER. REQUEST message is sent by the 6G UE to the external non-3GPP entity via 6G MM NF to get the voucher. Message type: IOT VOUCHER REQUEST

[0147] Significance: dual

[0148] Direction: loT device to network

[0149] The following table provides an overview on the IOT VOUCHER REQUEST message content:

[0150]

[0151] With the following information elements (IE):

[0152] loT uplink CID

[0153] This IE shall be included in the message when the loT device is assigned for this uplink connection.

[0154] It could include information like listed below

[0155] - Device level identifiers like MAC address, device ID, etc., or

[0156] - Application-level identifier like client ID, endpoint identifier, etc.,

[0157] - Protocol specific identifier like MQTT packet ID, CoAP message ID, etc. - Context specific identifier like transaction ID, process identifier, etc.

[0158] - Network level identifier like IP address, Device address, port number, etc.

[0159] loT serial number

[0160] This IE is included in the message with serial number of the loT device hardware. When processing a voucher, an loT device must make sure that its serial number matches this value. If there is no match, then loT device must not process this voucher.

[0161] loT Device ID CERT container

[0162] This IE is included in the message with loT IDevID certificate. The Authority Key Identifier OCTET STRING from the loT's IDevID certificate. Optional since some serial-numbers are already unique within the scope of a MASA. Inclusion of the statistically unique key identifier ensures statistically unique identification of the IOT device hardware. When processing the loT voucher, an loT device MUST ensure that its IDevID Authority Key Identifier matchesthis value. If no match occurs, then the loT device MUST NOT process this assigned loT voucher. When issuing an loT voucher, the MASA MUST ensure that this field is populated for serial-numbers that are not otherwise unique within the scope of the MASA.

[0163] AuthorityKeyldentifier : : = SEQUENCE {

[0164] keyidentifier [0] Keyidentifier OPTIONAL, authorityCertlssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL

[0165] }

[0166] MASA information

[0167] This IE is included in the message with MASA routing information which 3GPP entity can use to route the voucher request form loT device.

[0168] Nounce

[0169] This IE is optionally included in the message with loT device provided nonce to handle anti replay attack of voucher. loT device sends this nonce in loT voucher request and this is embedded in the loT voucher response message in the voucher itself. When voucher is received from the MASA, then the loT device will verify if this nonce received in voucher is same as what has been sent to MASA in request message.

[0170] According to example embodiments, the loT voucher response (message) may be structured as follows:

[0171] Message definition

[0172] The IOT VOUCHER RESPONSE message is sent by the external non-3GPP entity via 6G MM NF to loT device with voucher containing initial credentials of an loT device.

[0173] Message type: IOT VOUCHER RESPONSE

[0174] Significance: dual

[0175] Direction: Network to loT device

[0176] The following table provides an overview on the IOT VOUCHER. RESPONSE message content:

[0177]

[0178] With the following information elements (IE):

[0179] loT downlink CID

[0180] This IE shall be included in the message when the loT device is assigned for this downlink connection.

[0181] Voucher creation date and time

[0182] This IE is included in the message when (date and time of creation) the loT is assigned a voucher.

[0183] Voucher expires date and time

[0184] This IE is included in the message when (date and time of creation) the loT assigned voucher expires.

[0185] Voucher Assertion type

[0186] This IE is included in the message with different type of information which MASA server (non-3GPP entity) provides and this information can be furtheruseful for 3GPP entity (registrar) to support more detailed policy checks for loT device.

[0187] Enum {

[0188] IoT_verification_completed,

[0189] IoT_verification_partial,

[0190] IoT_verification_needed

[0191] }

[0192] "IoT_verification_completed" means the MASA server has verified successfully the loT device Serial number and Device ID CERT with sales channel integration. As the loT verification is completed by the MASA server, then it could have following characteristics.

[0193] - A long-term voucher which will not expire and is valid for indefinitely period. - These are for stable environment.

[0194] - These could be domain specific validation performed. This means "Domain type" is one for which this voucher is tied up to and should not be used for other domain types.

[0195] "IoT_verification_partial" means the MASA server has performed the minimal verification which is partial (the loT device Serial number and Device ID CERT provided is partially verified). Further verification can be carried out by the 3GPP entities for the loT device.

[0196] As the loT verification is partially verified by the MASA server, then it could have following characteristics.

[0197] - A Short-term voucher which will expire and is valid for only limited period. - As there is more unstable environment, MASA server performs minimal verification and further to be carried by 3GPP entity.

[0198] - During loT device transfer from owner to other owner (sale of a particular device), then owner authorized voucher is issued by the MASA. So, the owner could later login to transfer the ownership and for this purpose these voucher is used.

[0199] "IoT_verification_needed" means the MASA server has verified the loT device Serial number and Device ID CERT. But there could be some issues with this loT device. It requires some verification that the loT and 3GPP entity are incommunication but is still dependent on analysis of the logs to detect unexpected events from this loT device.

[0200] - This means loT voucher is provisional and voucher was issued without any strong authorization / verification at MASA server.

[0201] - Nonceless Voucher means this voucher is used for multiple loT devices. - Used only for onboarding purposes.

[0202] Voucher Domain type

[0203] This IE is included in the message to cover the domain specific information issued in Voucher. If this loT device is meant for particular domain like healthcare (Medical), travel, SaaS (Software as a service), Automotive, industrial, variable (could be used for different domains), etc. Also, this domain type is included in the Voucher assertion type for which this was issued. So, when Voucher is presented to 3GPP later, it is allowed for only those services related to domain specific and not for other services for other domains.

[0204] Enum {

[0205] IoT_domain_Medical,

[0206] IoT_domain_Industrial,

[0207] IoT_domain_SaaS,

[0208] IoT_domain_Automative,

[0209] IoT_domain_variable

[0210] }

[0211] Voucher type

[0212] This IE is included in the message to cover the voucher type meant for this loT device.

[0213] Enum {

[0214] IoT_voucher_type_Owner_Authorized,

[0215] IoT_voucher_type_provisional,

[0216] IoT_voucher_type_permanent,

[0217] IoT_voucher_type_time-limited,

[0218] IoT_voucher_type_others

[0219] }

[0220] loT serial numberThis IE is included in the message with serial number of the loT device hardware. When processing a voucher, an loT device must make sure that its serial number matches this value. If there is no match, then loT device must not process this voucher.

[0221] loT Device ID CERT container

[0222] This IE is included in the message with loT IDevID certificate. The Authority Key Identifier OCTET STRING from the loT's IDevID certificate. Optional since some serial-numbers are already unique within the scope of a MASA. Inclusion of the statistically unique key identifier ensures statistically unique identification of the IOT device hardware. When processing the loT voucher, an loT device MUST ensure that its IDevID Authority Key Identifier matches this value. If no match occurs, then the loT device MUST NOT process this assigned loT voucher. When issuing a loT voucher, the MASA MUST ensure that this field is populated for serial-numbers that are not otherwise unique within the scope of the MASA.

[0223] AuthorityKeyldentifier : : = SEQUENCE {

[0224] keyidentifier [0] Keyidentifier OPTIONAL, authorityCertlssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

[0225] Domain CERT Information

[0226] This certificate is used by an loT device to trust a Public Key Infrastructure in order to verify a domain certificate supplied to the loT device separately by the bootstrapping protocol. The domain certificate MUST have this certificate somewhere in its chain of certificates. This certificate MAY be an end-entity certificate, including a self-signed entity.

[0227] Nounce

[0228] This IE is optionally included in the message with loT device provided nonce to handle anti replay attack of voucher. loT device sends this nonce in loT voucher request and this is embedded in the loT voucher response in the voucher itself. When voucher is received from the MASA, then the loT device will verify if this nonce received in voucher is same as what has been sent to MASA in request message.FIG. 9 shows a schematic diagram of signaling sequences according to example embodiments, and in particular illustrates the above mentioned credential provisioning phase (non-certificate based approach).

[0229] In such credential provisioning phase, according to example embodiments, the UE (UE2) acts as a trust broker, which ensures that trust can be established, maintained and managed in a secure and reliable manner across different network entities in a 3GPP system.

[0230] In such case, according to example embodiments, the loT device (loT-UEl) goes via UE.

[0231] Namely, according to example embodiments, the loT device (loT-UEl) sends (step 5bl of FIG. 9) an loT credentials request with loT device ID to the UE (UE2), and the UE (UE2) adds its own ID (UE ID) before forwarding (step 5b2 of FIG. 9) the loT credentials request to the 6G MM NF.

[0232] According to example embodiments, the 6G MM NF fetches (step 5b3 of FIG. 9) the credentials (non-certificate-based credentials) and policy information for the loT device (loT-UEl).

[0233] According to example embodiments, the 6G MM NF sends (step 5b4 of FIG. 9) an loT credentials response in a NAS message to the UE (UE2) with grant access for the loT device and the policy for the loT device (policy will be configured if it is not sent in initial steps of FIG. 8) and operator credentials.

[0234] According to example embodiments, the UE (UE2) forwards (step 5b5 of FIG. 9) the loT credentials response to the loT device (loT-UEl).

[0235] According to example embodiments, the credentials and policies are stored in the loT device (loT-UEl) (step 5b6 of FIG. 9).

[0236] The above-described procedures and functions may be implemented by respective functional elements, processors, or the like, as described below.In the foregoing exemplary description of the network entity, only the units that are relevant for understanding the principles of the disclosure have been described using functional blocks. The network entity may comprise further units that are necessary for its respective operation. However, a description of these units is omitted in this specification. The arrangement of the functional blocks of the devices is not construed to limit the disclosure, and the functions may be performed by one block or further split into sub-blocks.

[0237] When in the foregoing description it is stated that the apparatus, i.e. network entity (or some other means) is configured to perform some function, this is to be construed to be equivalent to a description stating that a (i.e. at least one) processor or corresponding circuitry, potentially in cooperation with computer program code stored in the memory of the respective apparatus, is configured to cause the apparatus to perform at least the thus mentioned function. Also, such function is to be construed to be equivalently implementable by specifically configured circuitry or means for performing the respective function (i.e. the expression "unit configured to" is construed to be equivalent to an expression such as "means for").

[0238] In FIG. 10, an alternative illustration of apparatuses according to example embodiments is depicted. As indicated in FIG. 10, according to example embodiments, the apparatus (terminal) 10' / 40' (corresponding to the terminal 10 / 40) comprises a processor 101, a memory 102 and an interface 103, which are connected by a bus 104 or the like. The apparatus may be connected via link 109 with another apparatus, e.g. an interface of the another apparatus.

[0239] The processor 101 and / or the interface 103 may also include a modem or the like to facilitate communication over a (hardwire or wireless) link, respectively. The interface 103 may include a suitable transceiver coupled to one or more antennas or communication means for (hardwire or wireless) communications with the linked or connected device(s), respectively. The interface 103 is generally configured to communicate with at least one other apparatus, i.e. the interface thereof.

[0240] The memory 102 may store respective programs assumed to include program instructions or computer program code that, when executed by the respective processor, enables the respective electronic device or apparatus to operate in accordance with the example embodiments.In general terms, the respective devices / apparatuses (and / or parts thereof) may represent means for performing respective operations and / or exhibiting respective functionalities, and / or the respective devices (and / or parts thereof) may have functions for performing respective operations and / or exhibiting respective functionalities.

[0241] When in the subsequent description it is stated that the processor (or some other means) is configured to perform some function, this is to be construed to be equivalent to a description stating that at least one processor, potentially in cooperation with computer program code stored in the memory of the respective apparatus, is configured to cause the apparatus to perform at least the thus mentioned function. Also, such function is to be construed to be equivalently implementable by specifically configured means for performing the respective function (i.e. the expression "processor configured to [cause the apparatus to] perform xxx-ing" is construed to be equivalent to an expression such as "means for xxx- i ng").

[0242] According to example embodiments, an apparatus representing the terminal 10 comprises at least one processor 101, at least one memory 102 including computer program code, and at least one interface 103 configured for communication with at least another apparatus. The processor (i.e. the at least one processor 101, with the at least one memory 102 and the computer program code) is configured to perform establishing connection with a device to be securely onboarded into a network (thus the apparatus comprising corresponding means for establishing), to perform transmitting, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device (thus the apparatus comprising corresponding means for transmitting), and to perform receiving, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device (thus the apparatus comprising corresponding means for receiving).

[0243] According to example embodiments, an apparatus representing the terminal 40 comprises at least one processor 101, at least one memory 102 including computerprogram code, and at least one interface 103 configured for communication with at least another apparatus. The processor (i.e. the at least one processor 101, with the at least one memory 102 and the computer program code) is configured to perform establishing connection with a verified device to be securely onboarded into a network (thus the apparatus comprising corresponding means for establishing), to perform receiving, from said verified device, a credential request for said verified device, said credential request including an identifier of said verified device (thus the apparatus comprising corresponding means for receiving), to perform adding an own identifier to said credential request (thus the apparatus comprising corresponding means for adding), and to perform transmitting, towards a network entity of said network, said credential request including said own identifier (thus the apparatus comprising corresponding means for transmitting).

[0244] For further details regarding the operability / functionality of the individual apparatuses, reference is made to the above description in connection with any one of FIGs. 1 to 9, respectively.

[0245] For the purpose of the present disclosure as described herein above, it should be noted that

[0246] - method steps likely to be implemented as software code portions and being run using a processor at a network server or network entity (as examples of devices, apparatuses and / or modules thereof, or as examples of entities including apparatuses and / or modules therefore), are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;

[0247] - generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the embodiments and its modification in terms of the functionality implemented;

[0248] - method steps and / or devices, units or means likely to be implemented as hardware components at the above-defined apparatuses, or any module(s) thereof, (e.g., devices carrying out the functions of the apparatuses according to the embodiments as described above) are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (IntegratedCircuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components;

[0249] - devices, units or means (e.g. the above-defined network entity or network register, or any one of their respective units / means) can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved;

[0250] - an apparatus like the user equipment and the network entity / network register may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution / being run on a processor;

[0251] - a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

[0252] In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and / or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

[0253] Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present disclosure. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person.

[0254] Software in the sense of the present description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computerprogram or a computer program product) embodied on a tangible medium such as a computer-readable (storage) medium having stored thereon a respective data structure or code means / portions or embodied in a signal or in a chip, potentially during processing thereof. The present disclosure also covers a non-transitory computer readable medium comprising instructions, which, when executed by an apparatus, cause the apparatus to perform the methods herein described. The term "non-transitory", as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0255] The present disclosure also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.

[0256] In view of the above, there are provided measures for secure network onboarding of network devices. Such measures exemplarily comprise establishing connection with a device to be securely onboarded into a network, transmitting, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, and receiving, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device. Such measures exemplarily comprise establishing connection with a verified device to be securely onboarded into a network, receiving, from said verified device, a credential request for said verified device, said credential request including an identifier of said verified device, adding an own identifier to said credential request, and transmitting, towards a network entity of said network, said credential request including said own identifier.

[0257] Even though the disclosure is described above with reference to the examples according to the accompanying drawings, it is to be understood that the disclosure is not restricted thereto. Rather, it is apparent to those skilled in the art that the present disclosure can be modified in many ways without departing from the scope of the inventive idea as disclosed herein.List of acronyms and abbreviations

[0258] 3GPP 3rd Generation Partnership Project

[0259] 6G 6th Generation

[0260] 6GC 6G Core

[0261] AF application function

[0262] AIoT ambient internet of things

[0263] AN access network

[0264] BR.SKI bootstrapping remote secure key infrastructure CA certificate authority

[0265] D2D device-to-device

[0266] DNS-SD domain name system service discovery EST enrollment over secure transport

[0267] HN home network

[0268] HN SMC home network security mode command IDevID initial device identifier

[0269] IE information element

[0270] IETF Internet Engineering Task Force

[0271] loT internet of things

[0272] LDevID locally significant device identifier

[0273] MASA manufacturer authorized signing authority mDNS multicast domain name system

[0274] ME mobile equipment

[0275] MM NF mobility management network function

[0276] NF network function

[0277] PKI public key infrastructure

[0278] ProSe proximity- based service

[0279] SaaS software as a service

[0280] SIM subscriber identity module

[0281] SKMF security key management function

[0282] SN serving network

[0283] UE user equipment

Claims

I / We Claim:

1. A method, comprisingestablishing connection with a device to be securely onboarded into a network, transmitting, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, andreceiving, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device.

2. The method according to claim 1, further comprisingreceiving, from said device, said request for said voucher for said device, and transmitting, towards said device, said voucher response including said voucher for said device.

3. The method according to claim 1 or 2, whereinsaid request for said voucher for said device includes a first identifier of said device, a serial number of said device, and information on a manufacturer authorized signing authority entity managed by a manufacturer of said device.

4. The method according to claim 3, whereinsaid first identifier of said device includes at least one of the following:a device level identifier related to said device, oran application level identifier related to said device, ora protocol specific identifier related to said device, ora context specific identifier related to said device, ora network level identifier related to said device.

5. The method according to any of claims 1 to 4, whereinsaid voucher response includes a second identifier of said device, manufacture information on said device, and certificate related information.

6. The method according to claim 5, further comprising32performing a verification processing of said device utilizing said manufacture information on said device.

7. The method according to claim 6, whereinsaid verification processing includes receipt of a user input related to verification of said device based on said manufacture information on said device.

8. The method according to claim 6 or 7, whereinsaid voucher response includes information on a degree of verification of said device, andthe method further compriseschanging, if said information on said degree of verification of said device is indicative of incompleteness of verification of said device, and if, as a result of said verification processing, said device is verified, said information on said degree of verification of said device to be indicative of completeness of verification of said device.

9. The method according to any of claims 6 to 8, further comprising transmitting, towards said network entity of said network, if, as a result of said verification processing, said device is verified, information on approval of said device.

10. The method according to any of claims 1 to 9, whereinsaid voucher response includes information on a domain type for which said device is designed, and validity information on a type of said voucher.

11. The method according to claim 10, whereinsaid domain type includes at least one of the following:a medical domain, oran industrial domain, ora software as a service domain, oran automotive domain, ora variable domain.

12. The method according to claim 10 or 11, whereinsaid type of said voucher includes at least one of the following:owner authorized, or33provisional, orpermanent, ortime limited.

13. The method according to any of claims 1 to 12, whereinsaid connection is a device-to-device connection, and / orsaid connection is a Bluetooth connection.

14. The method according to any of claims 1 to 13, whereinthe method is operable at or by a terminal, user equipment, mobile station or modem, and / orsaid network entity of said network is a 6G mobility management network function entity.

15. An apparatus connectable with a device to be securely onboarded into a network, the apparatus comprisingestablishing circuitry configured to establish connection with said device to be securely onboarded into said network,transmitting circuitry configured to transmit, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, andreceiving circuitry configured to receive, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device.

16. The apparatus according to claim 15, further comprisingreceiving circuitry configured to receive, from said device, said request for said voucher for said device, andtransmitting circuitry configured to transmit, towards said device, said voucher response including said voucher for said device.

17. The apparatus according to claim 15 or 16, whereinsaid request for said voucher for said device includes a first identifier of said device, a serial number of said device, and information on a manufacturer authorized signing authority entity managed by a manufacturer of said device.

18. The apparatus according to claim 17, whereinsaid first identifier of said device includes at least one of the following:a device level identifier related to said device, oran application level identifier related to said device, ora protocol specific identifier related to said device, ora context specific identifier related to said device, ora network level identifier related to said device.

19. The apparatus according to any of claims 15 to 18, whereinsaid voucher response includes a second identifier of said device, manufacture information on said device, and certificate related information.

20. The apparatus according to claim 19, further comprisingperforming circuitry configured to perform a verification processing of said device utilizing said manufacture information on said device.

21. The apparatus according to claim 20, whereinsaid verification processing includes receipt of a user input related to verification of said device based on said manufacture information on said device.

22. The apparatus according to claim 20 or 21, whereinsaid voucher response includes information on a degree of verification of said device, andthe apparatus further compriseschanging circuitry configured to change, if said information on said degree of verification of said device is indicative of incompleteness of verification of said device, and if, as a result of said verification processing, said device is verified, said information on said degree of verification of said device to be indicative of completeness of verification of said device.

23. The apparatus according to any of claims 20 to 22, further comprisingtransmitting circuitry configured to transmit, towards said network entity of said network, if, as a result of said verification processing, said device is verified, information on approval of said device.

24. The apparatus according to any of claims 15 to 23, whereinsaid voucher response includes information on a domain type for which said device is designed, and validity information on a type of said voucher.

25. The apparatus according to claim 24, whereinsaid domain type includes at least one of the following:a medical domain, oran industrial domain, ora software as a service domain, oran automotive domain, ora variable domain.

26. The apparatus according to claim 24 or 25, whereinsaid type of said voucher includes at least one of the following:owner authorized, orprovisional, orpermanent, ortime limited.

27. The apparatus according to any of claims 15 to 26, whereinsaid connection is a device-to-device connection, and / orsaid connection is a Bluetooth connection.

28. The apparatus according to any of claims 15 to 27, whereinthe apparatus is operable as or at a terminal, user equipment, mobile station or modem, and / orsaid network entity of said network is a 6G mobility management network function entity.

29. An apparatus connectable with a device to be securely onboarded into a network, the apparatus comprisingat least one processor, and36at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform:establishing connection with said device to be securely onboarded into said network,transmitting, towards a network entity of said network, a device validation related request, said device validation related request including a request for a voucher for said device, andreceiving, from said network entity of said network, a device validation related response, said device validation related response including a voucher response, said voucher response including said voucher for said device, wherein said voucher is a cryptographically signed artifact certifying an identity of said device.

30. A computer program product comprising computer-executable computer program code which, when the program is run on a computer, is configured to cause the computer to carry out the method according to any one of claims 1 to 14.

31. The computer program product according to claim 30, wherein the computer program product comprises a computer-readable medium on which the computerexecutable computer program code is stored, and / or wherein the program is directly loadable into an internal memory of the computer or a processor thereof.37

Images