WiFi Easy Connect - DPP 1.1

Design

The Device Provisioning Protocol (DPP, also known as WiFi Easy Connect) allows enrolling of devices without a user interface in a secure WiFi network. The device enrollment process uses many methods, such as QR code-based authentication. 

In DPP, a Configurator provides the network credentials to the devices. Any STA or AP device can act as a Configurator. The three phases of DPP connection establishing are authentication, configuration, and network introduction.

Implementing DPP support requires a combination of: OpenSync target implementation enhancements, authenticator (e.g. hostap) enhancements, and driver enhancements.

Broadcast Action Frame Rx

Both HW and SW Rx filters must be adjusted to accept and process frames with RA or BSSID addresses accordingly. These addresses use the format FF:FF:FF:FF:FF:FF. DPP uses such frames when initiating authentication (when no MAC is provided in the bootstrap info) or when chirping.

Filter adjustment can be addressed autonomously by the driver, or through additional runtime settings. If the latter is done, the target API or platform-specific userspace helpers shall compensate.

Off-channel Tx

Off-channel Tx is required for the Responder Enrollees. The OpenSync AP may need to go off-channel to initiate the DPP authentication.

For example, a cfg80211 driver shall respect the following fields in the cfg80211_mgmt_tx_params when processing the mgmt_tx op:

• wait

• offchan

• chan

Protected Management Frames (PMF/MFP/11w)

The protected management frames are required to support the DPP Authentication and Key Management (AKM). Some older drivers may need extra work to support 11w.

DPP AKM (aka DPP Connector)

The DPP AKM requires pre-auth capabilities to set up PMKID cache during DPP Network Introduction.

DPP Client’s Public Key Access

The underlying platform needs to be able to tell what public key a client had used when it connected to the AP. The key’s hash needs to be exposed to the northbound API.

Requirements

Base DPP Requirements

AKM Configuration

The target must not use the security column in Wifi_VIF_Config and Wifi_VIF_State. Instead, the target is respected and reported:

• wpa

• wpa_key_mgmt

• wpa_psks

DPP AKM Configuration

The target must respect and report:

• dpp_netaccesskey_hex

• dpp_csign_hex

• dpp_connector

DPP Authentication Configuration

The target API implementation must implement new functions:

• target_dpp_config_set

• target_dpp_supported

The target API implementation must call new functions to report back these events:

• target_radio_ops::op_dpp_conf_enrollee

• target_radio_ops::op_dpp_conf_failed

DPP Client Key Reporting

The target reports the schema_Wifi_Associated_Clients structure through the target_radio_ops’ op_client and op_clients with an additional column being filled for the clients using DPP AKM:

• dpp_netaccesskey_sha256_hex

The field is a sha256 (hex-string encoded) of the ephemeral DPP authentication-derived public key of the Client which has been signed by the configurator and handed out to the Client as the DPP Connector. The key is presented during the DPP Network Introduction to the AP to work out the PMK.

Enabling Enrollment of Chirping Devices

To enable enrollment of the chirping devices, the following functions are required on top of the base DPP support:

• dpp_cc

• target_radio_ops::op_dpp_announcement

Node Onboarding

To enable node onboarding, the following functions are required on top of the base DPP support:

• call target_radio_ops::op_dpp_conf_network when the network configuration is handed over

• implemented target_dpp_key_get