See Also
 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
This document details the design of the Authentication Reset system, including overall architecture, hooks for 3rd-party components, updating existing code, and a new Authentication Reset Component. This architecture is part of the systems management and security solution for Windows Mobile devices.
A new system is in place to allow users with forgotten passwords to recover and continue using Windows Mobile devices without loss of data. This also extends to 3rd-party authentication systems, such as smartcards. With this system in place, users will be able to re-enroll for authentication without possessing the previously-required authentication information.
This document will acquaint a reader who already has knowledge of the Windows Mobile systems management and security solution with the architecture for Authentication Reset. It describes the two major components, the Local Authentication Plugin (LAP)and the Authentication Reset Component (ARC), their relationship, and how the ARC can be replaced by 3rd parties.
For information on implementing a 3rd-party LAP, or instructions for replacing the default Windows Mobile LAP, refer to the See Also section below.
Design
|
Security |
The architecture allows for components to be designed that meet two security goals:
|
|
3rd-party LAP compatibility |
Maintain compatibility with 3rd-party LAP components, and provide the ability for 3rd-party LAPs to easily add Authentication Reset features to a LAP. |
|
Admin control and flexibility |
The architecture allows 3rd-party Authentication Reset Component implementations which offer administrators full control over the process. |
|
3rd-party device management solution compatibility |
The architecture allows 3rd-party Authentication Reset Component implementations which require neither an ActiveSync partnership nor an Exchange Server back-end. |
|
User convenience |
The architecture allows simple and convenient solutions. |
Terminology
|
LAP |
Local Authentication Plug-in. An authentication mechanism that plugs into LASS. It is typically created by an OEM to enable application-independent authentication. Windows Mobile supplies a default password LAP, but a custom LAP can be created as needed. |
|
LASS |
Local Authentication Subsystem. The infrastructure that enables user authentication independent of the application and the specific authentication mechanism. LASS is provided by Windows Embedded CE . |
|
Enrollment |
The process by which a user establishes authentication on the device, e.g., creating a password. |
|
Verification |
The process by which a user is authenticated on the device, e.g., entering a password. |
High-Level Design
The Authentication Reset Component is a Windows Mobile -specific piece of the LASS/LAP architecture defined by Windows Embedded CE . Windows Mobile provides a default LAP component as mandated by WinCE. It also allows LAPs to take advantage of the Authentication Reset architecture. Use of the Authentication Reset APIs is optional for LAPs.
The architecture for Authentication Reset requires two replaceable components:
Because each component may be replaced by 3rd parties, specific required APIs are designated for communication but the implementation of each is unknown to the other component and may not be assumed. Windows Mobile dictates the manner in which new components are registered and suggests implementation guidelines and requirements. Otherwise, each component is considered a "black box". However, Windows Mobile provides default implementations for each of these components. The default implementations are described in this document.
Architecture
The architecture for Authentication Reset is as generic as possible, allowing maximum flexibility. A LAP component should call AuthResetSetupduring enrollment if it wants to make Authentication Reset available to the user at a later time. During verification, the LAP calls AuthResetRequestfunction in Aygshell to begin the process. This API determines if a 3rd-party Authentication Reset Component has been registered, then loads the specified DLL and calls the corresponding API in that DLL. The AuthResetGetValueAPI is supplied to provide a mechanism for feedback between the components.
By default, the Authentication Reset process does not save any state information (other than failure attempts). If the user resets the device during this process, the process will begin again. LAPs and Authentication Reset Components may choose to save state information.
Setup Workflow
Windows Mobile implements default LAP and Authentication Reset Components. 3rd parties may replace one or both of these components. During enrollment, the default Windows Mobile LAP generates an Admin Key passes it to AuthResetSetupas Reset Data to allow the Authentication Reset Component to prepare the device for future Authentication Resets. In the default Authentication Reset component, a generated key is used to encrypt the Admin Key, which is returned as Request Data. The generated key is stored on the Exchange Server using ActiveSync. The LAP will store this information along with other enrollment information and uses it to make requests in the future. The LAP will initiate authentication reset setup after the Authentication Reset feature is used. Afterwards, the Request Data is already stored and does not need to be retrieved again.
Request Workflow
The data flow is important because it provides maximum security for the user despite the lack of knowledge about 3rd-party components. When a user begins the Authentication Reset process they will first be required to enter the new proposed password. Next, the Authentication Reset Component is called, passing in the Request Data stored during setup. This is a blocking call on the VerifyUser thread and depending on the Authentication Reset Component can take milliseconds or days, and can require input from the user. The proposed password is permanently stored only when AuthResetRequestreturns successfully and provides the matching Admin Key. This way, there is no potential for an unauthorized user who possesses the device to inject an unwanted password anywhere in the process. In addition, the user is prompted to verify again after completing the Authentication Reset process. For security it is recommended that 3rd-party LAPs follow this model, but it is not required.
Remarks
A LAP will need dual pin support in order to support the Authentication Reset System.