Security requirements

In order to better understand how Tivoli Access Manager for Enterprise Single Sign-On implements operational security we first need to identify which information assets and procedures have to be secured. Tivoli Access Manager for Enterprise Single Sign-On handles the following types of sensitive data:

򐂰 Application credentials

These credentials are stored on behalf of a user to provide automated access to enterprise applications.

򐂰 Encryption keys

These cryptographic keys are used to protect the user credentials.

򐂰 Authentication factors

This secret data provided by a user is for proving one’s identity to the system.

This includes the user’s Tivoli Access Manager for Enterprise Single Sign-On password, biometric data, onetime passwords, and so on.

򐂰 Audit logs

Audit logs must be protected against tampering.

All the sensitive data items listed must be protected as they flow through the system. Thus, the security requirements for Tivoli Access Manager for Enterprise Single Sign-On can be specified as follows:

򐂰 Secure storage

If sensitive data has to be stored, either on the server or the clients, it must be stored in an encrypted form.

򐂰 Secure processing

Sensitive data must be in an unencrypted form while it is being used. The system should prevent other user programs from accessing the unencrypted data while it is held in memory.

򐂰 Secure communication

Sensitive data must be protected from eavesdroppers as it travels between the components.

Securing Wallets

In this section, we discuss how Tivoli Access Manager for Enterprise Single Sign-On protects all sensitive data items in the different components.

Secure storage

When a user signs up with Tivoli Access Manager for Enterprise Single Sign-On, a random cryptographic key, called the common symmetric key (CSK), is generated. This CSK is unique to the user and is used for encrypting the user's credentials in the Wallet. The CSK, in turn, is encrypted using a key derived from either the user's Tivoli Access Manager for Enterprise Single Sign-On password or secret question-and-answer. The user’s authentication factors, such as the password, are not stored anywhere in the system. The CSK can be obtained in unencrypted form only when users authenticate themselves by providing their correct Tivoli Access Manager for Enterprise Single Sign-On password. The CSK can then be used to decrypt the credentials and is discarded when the user logs off.

Secure storage can be on the server or on clients:

򐂰 Secure storage on the server

The IMS Server stores only the encrypted forms of the user’s credentials and CSK in its database, so even breaking into the database does not reveal the CSK nor the credentials. Moreover, the access controls on the database are configured in such a manner that only an IMS Server-specific database account and the database administrators are granted access to the data.

򐂰 Secure storage on the clients

On client workstations the AccessAgent stores a copy of the encrypted credentials and CSK in a secure data file called Cryptobox. Data is stored in an encrypted format. The design of the Cryptobox makes it impossible to read or enumerate the stored data items without knowing their access keys. The access key for the credentials stored in a Cryptobox is derived both from the user's CSK and a secret known only to the AccessAgent. Therefore, the credentials can be extracted from the Cryptobox only after the AccessAgent has authenticated the user and has access to the user's CSK. The

AccessAgent can be configured to delete Cryptoboxes if they have not been used for a specified number of days. This approach can minimize the risk of exposure to brute-force attacks on user credentials stored in Cryptoboxes.

Secure processing

The AccessAgent also protects sensitive data while the data resides in the computer’s memory. A user’s Tivoli Access Manager for Enterprise Single Sign-On password is held in the computer memory in a scrambled form. It is unscrambled only when it is used. This foils any attempt from other user programs to scan the password from the agent’s memory. Similarly, memory locations that temporarily hold a user’s credentials and the CSK are wiped clean after use to prevent object reuse attacks.

Secure communication

When a user logs on to Tivoli Access Manager for Enterprise Single Sign-On, the user’s password is sent to the IMS Server. In addition, when the user captures new credentials or updates them, the credentials are synchronized between the IMS Server and the AccessAgent. The communication channel that carries this sensitive data is protected by using SSL. After the AccessAgent verifies the SSL certificate issued to the server, the communication is encrypted using temporary session keys. This approach prevents eavesdroppers from extracting the sensitive data from network packets.

Secure audit logs

The audit log records stored in the database can optionally be made

tamper-evident through the use of hash chains and signatures. A log verification utility script can be run on demand or on schedule to verify the hash chains and signatures.

Recovering Wallets

As mentioned in the previous sections, a user's Wallet is protected by the CSK, which in turn is protected by the Tivoli Access Manager for Enterprise Single Sign-On password. If the user forgets the password, the credentials stored in the Wallet will not be available, preventing the user from accessing enterprise applications. Tivoli Access Manager for Enterprise Single Sign-On provides the user with a means to recover the Wallet, even if the password is forgotten.

During registration, a user is allowed to register one or more personal secrets.

These secrets are responses to questions only the user is likely to know. The system also stores the user's CSK in an encrypted form with the personal secrets. If the user forgets the password, the user must provide a specified number of correct personal secrets in order to reset the password and recover the Wallet. In this process, Tivoli Access Manager for Enterprise Single Sign-On re-encrypts the user's CSK with the new password provided by the user.

Strengthening the protection of Wallets

As Tivoli Access Manager for Enterprise Single Sign-On provides the user with the ability to log on to multiple enterprise applications, the authentication to Tivoli Access Manager for Enterprise Single Sign-On should be strengthened. Tivoli Access Manager for Enterprise Single Sign-On provides several ways to strengthen the authentication, which are discussed in this section.

Use of password policies

An enterprise can ensure users use strong passwords by enforcing Tivoli Access Manager for Enterprise Single Sign-On password policies. These policies include password aging, password complexity, and lockout policies that can be centrally configured on the IMS Server.

Use of authentication factors

Access to the Wallet can also be strengthened by enforcing the use of additional authentication factors such as RFID badges, biometrics, and USB smart card tokens. The use of such authentication factors increases security, as an attacker now needs to obtain both a physical token and the Tivoli Access Manager for Enterprise Single Sign-On password of a user to gain access to a Wallet. Tivoli Access Manager for Enterprise Single Sign-On can use RFID-enabled facility access badges as authentication factors. Users must present their RFID access badge and password to log on to their systems. To log on using a USB smart

card token, the users supply the smart card PIN, which is verified by the smart card itself. The private data on the smart card is protected by the PIN, which is locked out after a pre-configured number of successive failed attempts. Users with USB smart card tokens can have their credentials stored securely on the smart card instead of on a computer's hard disk. Tivoli Access Manager for Enterprise Single Sign-On uses Public Key Cryptography to authenticate the USB tokens to the IMS Server using 2048-bit RSA keypairs stored on the smart cards.

How the private desktop feature ensures security

The private desktop feature is provided by the AccessAgent. It uses the Windows operating system support to create multiple Windows desktops for different user accounts, using the user’s own Windows privileges, and facilitates the switching between these desktops. This way, the private desktop is only visible to the individual user, no other user (including the administrator) can access it.

When a new user logs on from the AccessAgent GINA, the private desktop first verifies that the user is a valid user, and then creates a Windows desktop for that user. It then loads the user's Windows profile, and creates the user's shell (starting Windows Explorer, and so on) for the user to interact with the desktop.

The private desktop also provides Group Policy Object (GPO) support by invoking the client side extensions to apply the group policies applicable to the user. Next, the user shell in the user's security context is created and therefore, all applications run from the desktop are executed in the user's own security context.

With the private desktop session, each desktop runs with the rights of the user's Active Directory account; therefore, access to each user's desktop or resources remains protected by Windows access control. This means that while each user account does not have administrative rights on the machine, a user cannot possibly access another user's data.

When users log off from their desktop, the private desktop gracefully logs off the users’ applications by sending end session messages to each open window on the users’ desktops. As with a normal Windows logoff, when an application is not ready to end, the private desktop displays a notification to the user and lets the user terminate the logoff processes. In the event of a system restart or shutdown, all private desktops are logged off gracefully before the system restarts or shuts down.

The private desktop is designed to prevent malicious software or some other desktop management software from switching between a current desktop to another user's desktop. If a third-party software tries to perform desktop switching, AccessAgent immediately locks the workstation. If the component of

AccessAgent that implements this security measure is somehow terminated by the administrator, the computer is restarted automatically.

This functionality also prevents the clipboard content on one desktop being accessed from another desktop session. Anything copied onto the clipboard from one desktop is prevented from being pasted into another desktop.

Windows 2000 does not support Fast User Switching (FUS), and Windows XP support for FUS is limited to non-domain logons. With the Tivoli Access Manager for Enterprise Single Sign-On private desktop, Active Directory users can use FUS with domain level security across Windows 2000 and Windows XP.