IntroductionEnableSecureEventInput was implemented in Mac OS X 10.3, to provide a secure means for a process to protect keyboard input to a custom data entry field. This function protects keyboard entry so that keyboard events cannot be intercepted by a keyboard intercept process. A Security Update implemented for Mac OS X 10.4 changes how the system affects keyboard intercept processes when a process uses EnableSecureEventInput. If you process calls EnableSecureEventInput, this Technical Note provides information on how to properly support secure input.
Back to Top  DiscussionThe EnableSecureEventInput function is commonly used with custom user interfaces for entering passwords and other sensitive information. The function provides a means for a process to protect sensitive data from being intercepted by other processes. For the purpose of this Technical Note, a keyboard intercept process is defined as one that uses one of the three following techniques for intercepting keyboard events. Keyboard seize process using the IOHIDDeviceInterface->open function with the kIOHIDOptionsTypeSeizeDevice option. A process can seize control of a keyboard device using the HID (Human Interface Device) Manager, and become responsible for processing all keyboard events generated by that keyboard. Installation of an event tap as defined in CoreGraphics/CGEvent.h. This method, available since Mac OS X 10.4, utilizes an event tap, typically between the HID system driver, and the Core Graphics Window Server, the central process where events are dispatched. The GetKeys function which provides a snapshot of the keys that are currently pressed.
In the first two methods, the intercept or tap process is responsible for taking action so that the keyboard event is processed. The process can forward the event, modify the event, expand the event into additional key events, or swallow the event. The GetKeys is a legacy function commonly used in applications developed prior to Mac OS X. A process which calls GetKeys obtains a key map of which keys are pressed, even though the process is running in the background. Note: Most Carbon and Cocoa applications use system supported API's for private information data entry. For example, Carbon applications implement dialogs or windows with text fields supported by either the kControlEditTextPasswordProc or the kControlEditUnicodeTextPasswordProc control for the entry of password data. A Cocoa application will implement an NSSecureTextField for such purpose. This Technical Note does not apply to applications using these API's as they work properly to secure keyboard events only when necessary. Keyboard intercept processes are useful in diverse ways - for example, by an Accessibility process to support a specialized keyboard device, as a way to add macro capability to applications, to record user actions for replay later on, or to customize keyboard functionality. A critical consideration is that a keyboard intercept process could be implemented to capture private information if provided the keyboard events. To protect against such access, Mac OS X provides the EnableSecureEventInput function for use with custom data entry processes. The original implementation of EnableSecureEventInput was such that when a process enabled secure input entry and had keyboard focus, keyboard events were not passed to intercept processes. However, if the secure entry process was moved to the background, the system would continue to pass keyboard events to these intercept processes, since the keyboard focus was no longer to a secure entry process. Recently, a security hole was found that made it possible for an intercept process to capture keyboard events, even in cases where secure event input was enabled and the secure event input process was in the background. The fix for this problem is to stop passing keyboard events to any intercept process whenever any process has enabled secure event input, whether that process is in the foreground or background. This means that a process which enables secure event input and leaves secure event input enabled for the duration of the program, can affect all keyboard intercept processes, even when the secure event process has been moved to the background. Back to Top Using Secure Event Input FairlyIf you implement a process which specifically calls EnableSecureEventInput, your process has the responsibility to use secure event input fairly. Enable secure event input only when it is needed and disable it when it is no longer needed. Previously, the system ignored the secure input aspect of the process when the keyboard focus changed to a different process. As mentioned previously, if your process enabled secure input and left it enabled when the process moved to the background, the system would allow keyboard intercept processes to receive keyboard events. This is no longer the case. The system will no longer pass keyboard intercept processes keyboard events if your process has enabled secure input even when your process is moved to the background. It now becomes your process' responsibility to call DisableSecureEventInput when secure entry input is not required, such as when your process detects that it is moving to the background. A reminder, if your process uses the Carbon or Cocoa mechanisms to support secure input, then the secure input process will be handled by the system properly. For processes which implement a customs means for protected data entry, the objective is to mimic the the System's implementation of secure event input. Use EnableSecureEventInput only when needed, that is when the keyboard focus moves to a private data entry field. When the keyboard focus changes to a non-secure text field, or when your process detects that it is losing keyboard focus, call DisableSecureEventInput. You can check whether secure event input is enabled by calling IsSecureEventInputEnabled. Call DisableSecureEventInput to tell the system that there is no longer an immediate need to provide secure input for your process. The system will restore access of keyboard events to keyboard intercept processes. When your process detects that it is coming to the foreground, and it still has need to provide secure event input, call EnableSecureEventInput to restore keyboard security. By following these guidelines, the use of secure input by your process will be transparent to keyboard intercept processes. Back to Top SummaryA process should never enable secure event input for general text input or just enable this function for the life of the application. Consider the effect that this call will have on other processes. Mac OS X provides your process with a means for secure event input. Steps have been taken to ensure secure event input. Your process has greater responsibility to disable secure event input when it is not warranted. Use secure entry input fairly. Enable it only when needed. Disable it when it is not needed. Back to Top ReferencesBack to Top Document Revision History| Date | Notes |
|---|
| 2007-06-08 | First Version |
Posted: 2007-06-08
| 
