Overview of IHV Extensibility

 

The Native 802.11 framework provides support for an independent hardware vendor (IHV) to add functionality to the Native 802.11 framework.

For example, the IHV can provide support for any of the following:

• Proprietary or non-standard authentication algorithms for port-based network access. For more information, see Extending Support for 802.11 Authentication Algorithms.

• Proprietary or non-standard cipher algorithms for data encryption. For more information, see Extending Support for 802.11 Cipher Algorithms.

• Proprietary PHY configurations. For more information, see Extending Support for 802.11 PHY Configurations.

In order to extend the Native 802.11 functionality, the IHV must provide the following components:

• A Native 802.11 miniport driver that supports the Extensible Station (ExtSTA) operation mode. For more information about this mode, see Extensible Station Operation Mode. For more information about ways the ExtSTA operation mode can extend Native 802.11 functionality, see Extending Native 802.11 Functionality.

• An IHV Extensions DLL, which processes the security packets exchanged through the proprietary authentication algorithms that the IHV supports. The IHV Extensions DLL is also responsible for cipher key derivation through these authentication algorithms, as well as the validation of user data that pertains to the security extensions supported by the IHV.

  For more information about the IHV Extensions DLL, see Native 802.11 IHV Extensions DLL.

• An IHV User Interface (UI) Extensions DLL, which extends the Native 802.11 user interface to configure connectivity and security settings that are validated and processed by the IHV Extensions DLL.

  For more information about the IHV UI Extensions DLL, see Native 802.11 IHV UI Extensions DLL.

For more information about the modules provided by the IHV, see Native 802.11 Software Architecture.

To provide a secure execution environment, the IHV should do the following:

1. Do not log any sensitive information, such as encryption keys, in event or debug logs.

2. Use CryptProtectMemory to protect sensitive encryption keys stored in memory, and SecureZeroMemory to clear memory when done with the keys.

3. Treat the IHV extension portions of the network profile as untrusted data that may have been manipulated by an attacker. IHV extension portions of profiles are opaque to the 802.11 Auto Configuration Module (ACM) and Media Specific Module (MSM) and will not be validated. (See Native 802.11 Software Architecture for descriptions of these modules and configuration control paths.) This IHV extension data should be appropriately parsed to prevent any buffer overflows or attacks that could lead to a local escalation of privileges.