Technical Note TN2150

Using Secure Event Input Fairly

This Technical Note discusses the proper use of the EnableSecureEventInput function and the ramifications that a process has on other processes when this function is used improperly. It explains changes to the behavior of application processes which intercept keyboard events when a process uses EnableSecureEventInput improperly.

Introduction
Discussion
Using Secure Event Input Fairly
Summary
References
Document Revision History

Introduction

EnableSecureEventInput 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.

Discussion

The 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.

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.

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.

Using Secure Event Input Fairly

If 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.

Summary

A 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.

References



Document Revision History


DateNotes
2007-06-08

New document that describes the proper use of EnableSecureEventInput.