WO2022043019A1

WO2022043019A1 - Enrollment of an enrollee device to a wireless network

Info

Publication number: WO2022043019A1
Application number: PCT/EP2021/071862
Authority: WO
Inventors: Fengchang ZHANG; Xin Ge; Hai GU; Fulong Ma
Original assignee: Koninklijke Philips N.V.
Priority date: 2020-08-27
Filing date: 2021-08-05
Publication date: 2022-03-03

Abstract

Proposed concepts thus aim to provide schemes, solutions, concepts, designs, methods and systems pertaining to DPP onboarding in wireless networks. In particular, embodiments aim to support permitted enrollee devices in a DPP bootstrapping process with a third party involved without sharing network security credentials. For example, embodiments may introduce control points by splitting the DPP bootstrapping process into request, approve and execute stages.

Description

ENROLLMENT OF AN ENROLLEE DEVICE TO A WIRELESS NETWORK

FIELD OF THE INVENTION

The present invention is generally related to wireless communications and, more particularly, to controlling enrollment of an enrollee device to a wireless network according to a device provisioning protocol (DPP).

BACKGROUND OF THE INVENTION

The device provisioning protocol defines device roles during provisioning (configuration) and connectivity (introduction) of device to a wireless network.

There are two types of roles, Configurator and Enrollee on the one hand and Initiator and Responder on the other.

A Configurator supports the setup of Enrollee. The Configurator and the Enrollee engage in DPP bootstrapping, DPP authentication, and the DPP configuration protocol.

Either of the Configurator or the Enrollee may perform the role of Initiator in the DPP Bootstrapping protocol and in the DPP Authentication protocol. However, only Enrollees initiate the DPP Configuration protocol and the DPP Introduction protocol.

The DPP Authentication protocol requires the Initiator to obtain the bootstrapping key of the Responder as part of a prior bootstrapping mechanism. Optionally, both devices in the DPP Authentication protocol may obtain each other’s bootstrapping keys in order to provide mutual authentication. After the authentication completes, the Configurator provisions the Enrollee for device-to-device communication or infrastructure communication. As part of this provisioning, the Configurator enables the Enrollee to establish secure associations with other peers in the network.

The DPP Authentication protocol has a decentralized architecture with no central authority to coordinate or control authentication. It therefore relies on a direct trust model.

In a bootstrapping process with a third-party involved, security threats are introduced by the third-party. For instance, a critical value that a third-party in a bootstrapping process may transfer is the enrollee device’s bootstrapping. For example, a common scenario is that of a third-party worker (e.g. installer) needing to perform device installation or maintenance at a user’s home when the home network owner is not present at the home. In such scenario, if the third-party takes the configurator role in the device provisioning process based on DPP, there is a security risk associated with sharing network security credentials with an untrusted third-party. Another security risk is associated with provisioning devices without permission of the home network owner, which could introduce other security issues to the home network.

Accordingly, there is a need to support DPP enrollment of a device to a wireless network with the help of a third party (that is potentially untrusted).

SUMMARY OF THE INVENTION

The invention is defined by the claims.

According to examples in accordance with an aspect of the invention, there is provided an intermediary device for facilitating enrollment of an enrollee device to a wireless network according to a DPP, the intermediary device comprising: an interface configured to obtain authentication data associated with the enrollee device; and a communication module configured to generate an enrollment request based on the authentication data and to communicate the enrollment request to control apparatus for controlling enrollment of an enrollee device to the wireless network.

Also, according to other examples in accordance with an aspect of the invention, there is provided a control apparatus for controlling enrollment of an enrollee device to a wireless network according to DPP, the control apparatus comprising: a control component configured to receive an enrollment request and to generate a notification relating to the enrollment request; and an authentication component configured to approve or deny the enrollment request related to the generated notification, and wherein the control component is further configured to permit communication of the authentication data associated with the enrollee device to a configurator device of the wireless network responsive to the enrollment request being approved by the authentication component.

According to further examples in accordance with an aspect of the invention, there is provided a system for controlling enrollment of an enrollee device to a wireless network according to a DPP, the system comprising: an intermediary device according to a proposed embodiment; and a control apparatus according to a proposed embodiment.

Proposed concepts thus aim to provide schemes, solutions, concepts, designs, methods and systems pertaining to DPP onboarding in wireless networks. In particular, embodiments aim to support permitted enrollee devices in a DPP bootstrapping process with a third party involved without sharing network security credentials. For example, embodiments may introduce control points by splitting the DPP bootstrapping process into request, approve and execute stages. In particular, embodiments may employ two steps of responsibility separation: (i) the first step separating out DPP bootstrapping from the DPP Authentication and Configuration; and (ii) the second step further separating DPP bootstrapping responsibilities into requestor, approver and controller groups.

Modifying the DPP to support the use of control apparatus which controls the delivery of authentication data to the configurator device may enable simple and secure enrollment of a device into a wireless network. The use of an intermediary device according to proposed embodiment may reduce complexity whilst also ensure that enrollment requests are only delivered to the configurator device if approved (e.g. confirmed to be authentic or allowable).

Additionally, proposed concepts may support multiple intermediary devices, and thus improve scalability of a deployment. In some implementations, an intermediary device apparatus may assisting with the provisioning of devices for a wireless network without sharing security/authentication credentials of the wireless network to the intermediary device.

According to some embodiments, there is proposed a concept of provisioning an enrollee device for a wireless network with the assistance of an intermediary device, a control component, and an authentication component. The intermediary device may obtain enrollee device authentication data (e.g. bootstrapping data) associated with the enrollee device and send it to the control component. The control component notifies the authentication component (i.e. administration device) about the enrollment request. The authentication component may approve the enrollment request or reject it after receiving the notification from the control component. If the request is approved by the authentication component, the control component sends the authentication data to the configurator device. The configurator device may then use the enrollee authentication data in an authentication process between the configurator device and the enrollee device. Following the authentication, the enrollee device may be configured by the configurator device such that the enrollee device may access the wireless network.

In some embodiments, the authentication component may be configured to approve or deny the enrollment request based on a user input indicating approval of the enrollment request. In this way, embodiments may be configured to support manual approval of an enrollment request, thus ensuring network owner/administrator involvement. In other embodiments, the authentication component may be configured to approve or deny the enrollment request based on stored security credentials (or other trusted information). In this way, approval of an enrollment request may be undertaken in an automated manner.

Also, the control component may be configured to, responsive to the enrollment request being denied by the authentication component, prevent communication of authentication data associated with one or more of the enrollee devices to the configurator device.

The authentication data associated with an enrollee device may comprise bootstrapping information.

Also, in some embodiments, the intermediary device may be configured to obtain authentication data via an out-of-band method. This may facilitate control of a bootstrapping procedure, wherein an out-of-band technique is used (which typically involves proximity or physical association with the enrollee device). For example, bootstrapping may include scanning a Quick Response® (QR) code that encodes a public bootstrap key. By providing support for this form of authentication, proposed embodiments may still allow certain devices (such as Internet-of-Things (IOT) devices, wearable accessories, home automation devices, etc.) that lack a user interface to be authenticated and enrolled.

In some embodiments, the intermediary device may comprise a legacy device that does not natively support the DPP, and the intermediary device is configured to communicate the generated enrollment request via an application layer at the legacy device. Such embodiments may thus support the use of a legacy device, thereby encouraging adoption of the DPP. For example, because the intermediary device may comprise a legacy device while still facilitating control of the enrollment of a plurality of enrollee devices, the DPP can be readily adopted by users having legacy devices.

Some embodiments may further comprise a verification component configured to sign the authentication data associated with the enrollee device using a private signing key associated with the configurator device. In this way, the configurator device can verify the authenticity of authentication data using a configurator public verification key that corresponds to the configurator private signing key.

According to other examples in accordance with an aspect of the invention, there is provided a method for controlling enrollment of an enrollee device to a wireless network according to a device provisioning protocol, DPP, the method comprising: obtaining, with an intermediary device, authentication data associated with the enrollee device and to generate an enrollment request based on the authentication data; receiving, at a control component, the generated enrollment request; generating, at the control component, a notification relating to the received enrollment request; and approving or denying, at an authentication component, the enrollment request related to the generated notification; and responsive to the enrollment request being approved at the authentication component, communicating authentication data associated with the enrollee device to a configurator device of the wireless network.

According to another aspect, there is provided a computer program product, wherein the computer program product comprises a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code configured to perform all of the steps of a proposed embodiment.

Thus, there may also be provided a computer system comprising: a computer program product according to proposed embodiment; and one or more processors adapted to perform a method according to a proposed concept by execution of the computer-readable program code of said computer program product.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment(s) described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

Figure 1 a simplified diagram of an exemplary embodiment of a system for controlling enrollment of an enrollee devices to a wireless network according to a DPP;

Figure 2 is a flow diagram of a method for controlling enrollment of an enrollee device to a wireless network according to a DPP; and

Figure 3 is a simplified block diagram of a computer within which one or more parts of an embodiment may be employed.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The invention will be described with reference to the Figures. It should be understood that the detailed description and specific examples, while indicating exemplary embodiments of the apparatus, systems and methods, are intended for purposes of illustration only and are not intended to limit the scope of the invention. These and other features, aspects, and advantages of the apparatus, systems and methods of the present invention will become better understood from the following description, appended claims, and accompanying drawings. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality.

It should be understood that the Figures are merely schematic and are not drawn to scale. It should also be understood that the same reference numerals are used throughout the Figures to indicate the same or similar parts.

Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and/or solutions pertaining to controlling enrollment of a an enrollee device for DPP onboarding in wireless networks. According to proposed concepts, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.

The term “DPP -based Wi-Fi network” refers to a network formed by multiple Wi-Fi device such that at least one of the Wi-Fi repeaters is capable of acting or otherwise functioning as a DPP configurator.

The term “smart device” refers to a device that is capable of reading QR code information present on a Wi-Fi repeater as well as connecting to a wireless access point (AP).

The terms “configured device” or “enrolled device” refer to a device that is onboarded in a wireless network (e.g., DPP -based Wi-Fi repeater network or MAP-R2 network) using a DPP mechanism. A configured (or enrolled) device is capable of acting or otherwise functioning as a DPP initiator.

The terms “unconfigured device” and “enrollee device” refer to a device that is not yet onboarded into the wireless network. Thus, a new device that is not yet configured for a network may be referred to as an enrollee device. A DPP may be used to facilitate configuration of an enrollee device being introduced to the network. For example, the DPP may provide authentication and authenticated key establishment between the enrollee device and a configurator device. A configurator device provides the configuration used by the enrollee device to join the network. Each of the enrollee device and the configurator device may have associated authentication data (e.g. a public bootstrap key (also sometimes referred to as a “public identity key”)) which is trusted between the devices and which can be used for an initial authentication. In some implementations, the authentication data is used for generating a temporary provisioning key.

When a public bootstrap key of another device is obtained using an out-of- band technique, the process of obtaining the public bootstrap key is referred to as “bootstrapping.” Bootstrapping provides trust in the public bootstrap key because the out-of- band technique typically involves proximity or physical association with the enrollee device. For example, bootstrapping may include scanning a Quick Response® (QR) code that encodes the public bootstrap key. Support for this form of authentication may allow certain devices (such as IOT devices, wearable accessories, home automation devices, etc.) that lack a user interface to be authenticated with a configurator device.

According to the proposed concept(s), a DPP may be enhanced to cater for involvement of a third party without exposing sensitive information (e.g. security credentials) to the third party. Embodiments may serve as authentication arrangement between an enrollee device and the configurator device. For example, embodiments may facilitate and control “bootstrapping” between the enrollee device and the configurator device. The embodiments may obtain enrollment request associated with the enrollee device via a third party and control provision of the enrollee authentication data to the configurator device according to approval/denial of the enrollment request.

In some implementations, the intermediary apparatus employed by a third party may comprise a legacy device. A legacy device refers to any device which is does not natively support the DPP or which is not capable of utilizing the DPP for its own network configuration. However, the legacy device may be capable of executing a client application which can communicate with a host service of the configurator device. Therefore, even though the legacy device does not implement the DPP, the client application running on the legacy device can still be used to facilitate the control of enrollment of enrollee devices.

Purely by way of example, a proposed embodiment may provide a method to enable enrollment of an enrollee device based on DPP by using an intermediary device of a third party, such as a smart phone. The method may avoid the sharing of network credentials with the third party and may comprise the following main steps: a. Bootstrapping request - The intermediary device (typically associated with a third party) obtains authentication data (e.g. bootstrapping data) via out-of-band method (e.g. scans a QR code) and generates an associated enrollment request (e.g. bootstrapping request); b. The control component receives the enrollment request, and notifies the authentication component (e.g. a separate admin device); c. The authentication component approves or rejects the enrollment request; d. The control component only sends an approved authentication data to the configurator device of the wireless network; and e. The configurator device completes the authentication process, which will further trigger DPP authentication and configuration processes as defined in the DPP specification.

From the above, it will be understood that proposed embodiments may support permitted enrollee devices in DPP bootstrapping process with third-party involvement without sharing Wi-Fi credentials. This is achieved by introducing control points, which split the DPP bootstrapping process into request, approve and execute stages. In general, there may bet two stages of responsibility separation. The first stage separates DPP bootstrapping from the DPP Authentication and Configuration, and the second stage further separates DPP bootstrapping responsibilities into requestor, approver and controller groups.

The first stage of separation provides an opportunity of implementing a headless and fixed location DPP Configurator, which is important for developing an AP product with DPP authentication and configuration capability enabled. Given that there is an application level communication between the control component and the configurator device transferring DPP authentication data, legacy devices, like a smart phone, tablet, etc. have the opportunity of assisting the DPP bootstrapping process. A combination of transferring DPP bootstrapping, authentication and configuration responsibility may require a mandatory device upgrade (e.g. OS, firmware level etc.) to support DPP authentication and configuration protocols.

The second stage of separation further extends the DPP authentication flexibility to support an improved security trust model where a third party is involved. The original responsibly of DPP authentication is to decompose into DPP bootstrapping request, approve and execute, and the third-party could be involved into executing DPP enrollment request responsibility as an intermediary device. However, only after approval from a control component (e.g. administrator device), is the DPP authentication and configuration process executed by a DPP configurator device.

Referring now to Figure 1, there is depicted a simplified diagram of an exemplary embodiment of a system for controlling enrollment of an enrollee device to a wireless network according to a DPP.

The system 100 comprises control apparatus that is configured to support enrollment of an enrollee device 110 in a DPP bootstrapping process with a third-party intermediary device 130 involved without sharing Wi-Fi credentials. Specifically, in this example, the control apparatus comprises an interface 130, a control component 140, and an authentication component 150.

The intermediary device 130 is configured to obtain authentication data (containing bootstrapping data) associated with the enrollee device 110. More specifically, the intermediary device 130 is owned and operated by third party and comprises a legacy device 130, namely a smart phone 130, configured to capture authentication data via an out- of-band method. For instance, a camera 135 of the smart phone 130 is configured to capture a respective QR code 105 associated with the enrollee device 110. Such a QR code 105 comprises the bootstrapping data (e.g. a boot strapping key) for the enrollee device 110 in a machine-readable format.

Based on the authentication data, a communication module 137 of the smart phone 130 generates an enrollment request and communicates the generated enrollment request to a control component 140 of the control apparatus. In this example, the generated enrollment request comprises a bootstrapping request including the bootstrapping data.

The control component 140 is configured to receive the generated enrollment request and to generate notification relating to the enrollment request. The generated notification is communicated to the authentication component 150.

The authentication component 150 is configured to approve or deny the enrollment request that the generated notification relates to. In this example, the authentication component 150 presents information about the enrollment request to a user (via a display screen) so that the user can decide whether to approve the enrollment request. Using a user interface of the authentication component 150, the user provides a user input to the authentication component 150 indicating denial or approval of the enrollment request. responsive to the enrollment request being approved by the authentication component. In this way, the authentication component 150 may be thought of as being an ‘admin device’ that is operated by an owner or administrator of the wireless network.

Responsive to the enrollment request being approved at the authentication component 150, the control component permits the authentication data associated with the enrollee device 110 to be communicated to the configurator device 120 of the wireless network. Conversely, responsive to the enrollment request being denied at the authentication component, the control component 140 prevents communication of authentication data associated with the enrollee device to the configurator device 120.

Such an approach introduces a concept of using a control device to provide enrollment requests from a third party to an authentication/admin device for approval.

By way of example, one may consider a situation where a third party worker is helping a network owner to a smart appliance (enrollee device), such as a smart air conditioner, to his/her wireless home network.

To connect the smart appliance to the wireless, the third party worker scans a QR code on the smart appliance using a smartphone (intermediary device). Using the scanned QR code, the smart phone generates an enrollment request and forwards which is then provided to a smartphone (control component) of the network owner.

The enrollment request can then be approved manually using an authentication application (authentication component) provided on the smartphone (e.g. because the worker is known to the network owner as being trusted). In response to the enrollment request being approved, the bootstrapping data of the smart appliance is communicated to the wireless router to complete bootstrapping. In this way, the smart appliance can be connected to the wireless network, while the third party’s smartphone need not be connected to the same wireless network (thus avoiding exposure of the network security credentials/password to the third party’s smartphone).

It will also be appreciated that the proposed embodiments may enable the intermediary device 130 to acquire authentication data of an enrollee device 110 through any of the out-of-band methods specified in the DPP specification, e.g. QR-Code, NFC, and Bluetooth etc. In this way, many forms or types of interface may be employed to obtain authentication data (e.g. graphical user interface, camera, short-range communication link interface, etc.). Some embodiments may thus require the development of communication protocols, along with accompanying software and/or hardware enabling the communication protocols. By way of further example, a flow diagram of a method for controlling enrollment of an enrollee device to a wireless network according to a DPP is depicted in Figure 2.

Referring to Figure 2, the method begins with the step 210 of a smartphone (i.e. intermediary device) capturing authentication data associated with an enrollee device. In this example, the authentication data comprises enrollee bootstrapping data associated with the enrollee device.

The captured authentication data is then used, in step 220, to generate and send an enrollment request to the control component. In this example, the generated enrollment request comprises a bootstrapping request including the bootstrapping data.

In step 230, a notification relating to the received enrollment request is generated and communicate to the authentication component. This may be done, for example, by sending a targeted notification to the authentication component.

The authentication component then approves or denies the enrollment request in step 240.

Responsive to the enrollment request being approved, the method proceeds to step 260, wherein the control component communicates the authentication data associated with the enrollee device to a configurator device of the wireless network. The authentication data communicated to the configurator device in step 260 is then used by the configurator device to execute enrollee device enrollment.

Responsive to responsive to the enrollment request being denied by the authentication component, the method proceeds from step 250 to step 280 wherein communication of authentication to the configurator device is prevented by the intermediary apparatus and the intermediary apparatus is notified of the denial of the enrollment request.

In preceding exemplary method, it may be preferable to configure the communications to secured using appropriate communication security technologies. The implementation of an appropriate secured communication may depends on the deployment relationships between the communication pair, and could be any appropriate technologies. For example, communication between the control component and the configurator device may be based on a strong/secure communication mechanism. Conversely, a relatively weak/insecure communication mechanism could be used in the communication between the intermediary device and the control component.

The communications among the various components could use local communication technologies, remote communication technologies or any of the combination of local and remote communication technologies. The local communication technologies includes but are not limited to Inter-Process Communication (IPC), Share Memory and Sharing Data files etc. The remote communication technologies includes but are not limited to TCP/IP, HTTP/HTTPS, SMTP, FTP/FTPS etc. Any of the remote communication network could be communicatively coupled to communication network through one or more gateway devices.

It will therefore be appreciated that there are many different ways of implementing the invention. For instance, an AP could be upgraded by incorporating some of the proposed apparatus. Also, loT platform operators could implement a cloud based control component according to a proposed embodiment. Yet further, a smart phone may be configured to include or implement part or all of the proposed intermediary apparatus.

By way of further example, Figure 3 illustrates an example of a computer 300 within which one or more parts of an embodiment may be employed. Various operations discussed above may utilize the capabilities of the computer 300. For example, one or more parts of a system for controlling enrollment of an enrollee device to a wireless network according to a DPP may be incorporated in any element, module, application, and/or component discussed herein. In this regard, it is to be understood that system functional blocks can run on a single computer or may be distributed over several computers and locations (e.g. connected via internet).

The computer 300 includes, but is not limited to, PCs, workstations, laptops, PDAs, palm devices, servers, storages, and the like. Generally, in terms of hardware architecture, the computer 300 may include one or more processors 310, memory 320, and one or more I/O devices 370 that are communicatively coupled via a local interface (not shown). The local interface can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor 310 is a hardware device for executing software that can be stored in the memory 320. The processor 310 can be virtually any custom made or commercially available processor, a central processing unit (CPU), a digital signal processor (DSP), or an auxiliary processor among several processors associated with the computer 300, and the processor 310 may be a semiconductor based microprocessor (in the form of a microchip) or a microprocessor. The memory 320 can include any one or combination of volatile memory elements (e.g., random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and non-volatile memory elements (e.g., ROM, erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), disk, diskette, cartridge, cassette or the like, etc.). Moreover, the memory 320 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory 320 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 310.

The software in the memory 320 may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. The software in the memory 320 includes a suitable operating system (O/S) 350, compiler 340, source code 330, and one or more applications 360 in accordance with exemplary embodiments. As illustrated, the application 360 comprises numerous functional components for implementing the features and operations of the exemplary embodiments. The application 360 of the computer 300 may represent various applications, computational units, logic, functional units, processes, operations, virtual entities, and/or modules in accordance with exemplary embodiments, but the application 360 is not meant to be a limitation.

The operating system 350 controls the execution of other computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. It is contemplated by the inventors that the application 360 for implementing exemplary embodiments may be applicable on all commercially available operating systems.

Application 360 may be a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program is usually translated via a compiler (such as the compiler 340), assembler, interpreter, or the like, which may or may not be included within the memory 320, so as to operate properly in connection with the O/S 350. Furthermore, the application 360 can be written as an object oriented programming language, which has classes of data and methods, or a procedure programming language, which has routines, subroutines, and/or functions, for example but not limited to, C, C++, C#, Pascal, BASIC, API calls, HTML, XHTML, XML, ASP scripts, JavaScript, FORTRAN, COBOL, Peri, Java, ADA, NET, and the like.

The I/O devices 370 may include input devices such as, for example but not limited to, a mouse, keyboard, scanner, microphone, camera, etc. Furthermore, the EO devices 370 may also include output devices, for example but not limited to a printer, display, etc. Finally, the EO devices 370 may further include devices that communicate both inputs and outputs, for instance but not limited to, a NIC or modulator/demodulator (for accessing remote devices, other files, devices, systems, or a network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc. The EO devices 370 also include components for communicating over various networks, such as the Internet or intranet.

If the computer 300 is a PC, workstation, intelligent device or the like, the software in the memory 320 may further include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of essential software routines that initialize and test hardware at startup, start the O/S 350, and support the transfer of data among the hardware devices. The BIOS is stored in some type of read-only-memory, such as ROM, PROM, EPROM, EEPROM or the like, so that the BIOS can be executed when the computer 300 is activated.

When the computer 300 is in operation, the processor 310 is configured to execute software stored within the memory 320, to communicate data to and from the memory 320, and to generally control operations of the computer 300 pursuant to the software. The application 360 and the O/S 350 are read, in whole or in part, by the processor 310, perhaps buffered within the processor 310, and then executed.

When the application 360 is implemented in software it should be noted that the application 360 can be stored on virtually any computer readable medium for use by or in connection with any computer related system or method. In the context of this document, a computer readable medium may be an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method.

The application 360 can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium.

The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

A single processor or other unit may fulfill the functions of several items recited in the claims.

It will be understood that the disclosed methods are computer-implemented methods. As such, there is also proposed a concept of a computer program comprising code means for implementing any described method when said program is run on a processing system.

The skilled person would be readily capable of developing a processor for carrying out any herein described method. Thus, each step of a flow chart may represent a different action performed by a processor, and may be performed by a respective module of the processing processor.

As discussed above, the system makes use of a processor to perform the data processing. The processor can be implemented in numerous ways, with software and/or hardware, to perform the various functions required. The processor typically employs one or more microprocessors that may be programmed using software (e.g. microcode) to perform the required functions. The processor may be implemented as a combination of dedicated hardware to perform some functions and one or more programmed microprocessors and associated circuitry to perform other functions.

Examples of circuitry that may be employed in various embodiments of the present disclosure include, but are not limited to, conventional microprocessors, application specific integrated circuits (ASICs), and field-programmable gate arrays (FPGAs).

In various implementations, the processor may be associated with one or more storage media such as volatile and non-volatile computer memory such as RAM, PROM, EPROM, and EEPROM. The storage media may be encoded with one or more programs that, when executed on one or more processors and/or controllers, perform the required functions. Various storage media may be fixed within a processor or controller or may be transportable, such that the one or more programs stored thereon can be loaded into a processor.

Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. If the term “adapted to” is used in the claims or description, it is noted that the term “adapted to” is intended to be equivalent to the term “configured to”. Any reference signs in the claims should not be construed as limiting the scope.

Claims

CLAIMS:

1. An intermediary device (130) for facilitating enrollment of an enrollee device (110) to a wireless network according to a device provisioning protocol, DPP, the intermediary device comprising: an interface (135) configured to obtain authentication data associated with the enrollee device; and a communication module (137) configured to generate an enrollment request based on the authentication data and to communicate the enrollment request to control apparatus (140) for controlling enrollment of an enrollee device (110) to the wireless network.

2. The intermediary device of claim 1, wherein the interface is configured to obtain authentication data via an out-of-band method.

3. The intermediary device of claim 1 or 2, wherein the intermediary device (130) comprises a legacy device that does not natively support the DPP, and wherein the intermediary device is configured to communicate the generated enrollment request via an application layer at the legacy device.

4. Control apparatus for controlling enrollment of an enrollee device (110) to a wireless network according to a device provisioning protocol, DPP, the apparatus comprising: a control component (140) configured to receive an enrollment request and to generate a notification relating to the enrollment request; and an authentication component (150) configured to approve or deny the enrollment request related to the generated notification, and wherein the control component is further configured to permit communication of the authentication data associated with the enrollee device to a configurator device (120) of the wireless network responsive to the enrollment request being approved by the authentication component.

5. The apparatus of claim 4, wherein the authentication component (150) is configured to approve or deny the enrollment request based on: a user input indicating approval of the enrollment request.

6. The apparatus of claim 4 or 5, wherein the control component (140) is configured to, responsive to the enrollment request being denied by the authentication component (150), prevent communication of authentication data associated with the enrollee device to the configurator device (120).

7. The apparatus of any of claims 4 to 6, further comprising a verification component configured to sign the authentication data associated with the enrollee device using a private signing key associated with the configurator device.

8. The apparatus of any of claims 1 to 7, wherein the authentication data associated with an enrollee device comprises enrollee bootstrapping data associated with the enrollee device, and wherein the generated enrollment request comprises a bootstrapping request including the bootstrapping data.

9. A system for controlling enrollment of an enrollee device to a wireless network according to a device provisioning protocol, DPP, the system comprising: an intermediary device according to any of claims 1 to 3; and control apparatus according to any of claims 4 to 8.

10. A method for controlling enrollment of an enrollee device to a wireless network according to a device provisioning protocol, DPP, the method comprising: obtaining (210), with an intermediary device, authentication data associated with the enrollee device and to generate an enrollment request based on the authentication data; receiving (220), at a control component, the generated enrollment request; generating, (230) at the control component, a notification relating to the received enrollment request; and approving or denying (240), at an authentication component, the enrollment request related to the generated notification; and 19 responsive to the enrollment request being approved at the authentication component, communicating (260) authentication data associated with the enrollee device to a configurator device of the wireless network.

11. The method of claim 10, further comprising: responsive to the enrollment request being denied at the authentication component, preventing (270) communication of authentication data associated with the enrollee device to the configurator device.

12. The method of any of claims 10 to 11, wherein obtaining (210) authentication data associated with the enrollee device employs an out-of-band method.

13. The method of any of claims 10 to 12, wherein the authentication data associated with an enrollee device comprises enrollee bootstrapping data associated with the enrollee device, and wherein the generated enrollment request comprises a bootstrapping request including the bootstrapping data.

14. The method of any of claims 10 to 13, wherein the intermediary device comprises a legacy device that does not natively support the DPP, and wherein the method comprises communicating the generated enrollment request via an application layer at the legacy device.

15. A computer program product comprising computer program code means which, when executed on a computing device having a processing system, cause the processing system to perform all of the steps of the method according to any of claims 10 to 14.