Chapter 4 Setting Up a Smart Card (Overview)

This chapter provides an overview of setting up a smart card.

This is a list of the topics in this chapter.

• "Deactivating or Activating Card Services "

• "Adding or Changing the ATR on a Smart Card"

• "Loading the SolarisAuthApplet Applet"

• "Creating User Information on a Smart Card"

• "Defining Authentication Properties on a Smart Card"

• "Setting Up the Default Authentication Mechanism for the OCF Server and Client Applications"

• "Default Authentication for Client Applications"

• "Enabling Smart Card Operations"

You can set up a smart card either with the SmartCard Console or the command line. For step-by-step instructions on setting up a smart card using the Console, see Chapter 5, Setting Up a Smart Card (Tasks). Where appropriate, this chapter also gives examples using the command line. See "How to Start the SmartCard Console (Command Line)" for step-by-step instructions on starting the SmartCard Console.

Deactivating or Activating Card Services

By default, the OCF server recognizes the following card services:

• Schlumberger Cyberflex

• Schlumberger Payflex

• Dallas Semiconductor iButton

The Card Services dialog box lets you verify that services for a particular card are active. You also use this dialog box to deactivate a card service. See "How to Deactivate or Activate Card Services (Console)" for step-by-step instructions on deactivating or activating card services.

Adding or Changing the ATR on a Smart Card

The answer-to-reset (ATR) property contains numeric values that identify the smart card version. Smart card manufacturers supply the ATR property.

Supported smart cards have the following ATR property values:

PayFlex.ATR      = 3B6900005792020101000100A9 
                   3B69110000005792020101000100
IButton.ATR      = 008F0E0000000000000000000004000034909000
CyberFlex.ATR    = 3B169481100601810F 3B169481100601811F

You identify the ATR on the smart card to the OCF server when you first set up smart cards.

You need to change the answer-to-reset property (ATR) on a system if the manufacturer of the smart card used by your site issues a new card type with a different ATR. Change this property on every system that needs to accept the new card.

You might also need to add an ATR if you are loading an applet from the SmartCard Console and the following message is displayed:

No compatible devices inserted

See "How to Add or Change the ATR on a Smart Card (Console)" for step-by-step instructions on adding or changing the ATR on a new smart card.

Loading the SolarisAuthApplet Applet

You must add the default SolarisAuthApplet applet to the card before you can add the user profile information.

See "How to Load an Applet Onto a Smart Card (Console)" for step-by-step instructions on loading the applet onto the smart card.

Creating User Information on a Smart Card

After the default applet has been loaded, create the user profile information on the card. The user profile information identifies personal information about the user, such as login name and password, a personal identification number (PIN), and the protected application.

See "How to Create User Information on a Smart Card (Console)" for step-by-step instructions on creating user information on the smart card.

Defining Authentication Properties on a Smart Card

You set the properties on each smart card based on the user's requirements, your site's security policies, and the limitations of the type of smart card used. Using the Configure Applets dialog box, you define corresponding properties for each smart card. The client and server programs on the system read the properties on the smart card to determine whether to give the user access to a particular application.

These properties apply only to cards initialized with the SolarisAuthApplet applet provided with Solaris Smart Cards. If your site uses a different smart card applet, the available properties might differ. Refer to the smartcard(1M) man page for more information.

PIN Property

The PIN property is an authentication property that defines a personal identification number (PIN) for the card. The default PIN created on the card is $$$$java. Either you or the user can change $$$$java to a personalized PIN. Consider giving all users at your site the same default PIN name (for example, changeme). Then make sure each user changes the PIN to a value known only to that user.

Although each application in the SolarisAuthApplet applet can have a different login name and password combination, only one PIN can be defined for the applet.

See "How to Change a PIN on a Smart Card (Console)" for step-by-step instructions on changing the PIN on a smart card.

Users can later change this PIN, as described in "How to Change the PIN on Your Smart Card (Command Line)".

User and Password Properties

The user and password properties are authentication properties that identify the user and associate the user with the smart card's PIN. To set these properties, you must know the user's login name and password.

How the User and Password Properties Work

On systems using the default authentication mechanism of PIN Password, ocfserv verifies the authenticity of the PIN as explained in "How the PIN Password Works". Next, ocfserv reads the user and password properties on the card. If the password on the smart card matches the user's entry in the system's password database, ocfserv gives the user access to the application.

You can define more than one user and password combination on a smart card. For example, the user of a smart card might need different login names and passwords to access different applications. Moreover, for a system administrator, you can define a standard login name and password, and a password for root on the card. However, the smart card can have only one PIN.

Application Property

Use the application authentication property to designate which applications the user needs to log in to with a login name and password. For example, to require a smart card login to the desktop, you must specify dtlogin as the application associated with the login name and password on the card. You can also require a smart card login for an application specific to your site, such as a financial package or personnel database, by specifying its name as the application property.

Before initializing an application on the card, find out which applications a user needs to access through smart card authentication. This step is particularly important when preparing a smart card for a system administrator or other user who might need to log in to an application as root or another restricted login name.

How the Application Property Works

The application property on the smart card works in tandem with the other authentication properties. For example, suppose you initialized a smart card for user Frank with the following information:

• A000000062030400 - The SolarisAuthApplet applet.

• '$$$$java' - The default PIN for this card, which user Frank can change later.

• dtlogin - The application requiring the smart card login.

• frank - The name Frank must provide to log in to the desktop.

• changeme - The password Frank must type to log in to the desktop.

The preceding information would be entered on the command line, as follows:

# smartcard -c init -A A000000062030400 -P `$$$$java' application=dtlogin
user=frank password=changeme

When Frank inserts his card into the reader and tries to log in to the desktop (dtlogin), ocfserv reads the card to check if any authentication properties are associated with dtlogin. The ocfserv server finds that the user and password properties are associated with dtlogin.

The ocfserv server prompts Frank for his PIN, and the typed PIN is compared with the PIN stored on the smart card assigned to the dtlogin application. Also, ocfserv uses the login name and password on Frank's card, along with the passwords in the system`s password database, to verify that Frank is whom he claims to be. If these properties match, Frank is logged in to the desktop.

Setting Up the Default Authentication Mechanism for the OCF Server and Client Applications

The authmechanism property defines the authentication mechanism that the client application uses on the local system. Solaris Smart Cards offers three authentication mechanisms:

• Password - Password associated with the individual's login name must be on the smart card or typed when the user tries to access a client application

• PIN - Individual's personal identification number (PIN) must be on the smart card or typed when the user tries to access a client application

• Challenge-Response - Challenge-response authentication sequence must occur between the system and the smart card before the individual can access the client application

The default authmechanism property is PIN Password.

How the PIN Password Works

The default authentication mechanism for ocfserv and client applications is PIN Password. In this scenario, the user tries to log in to an application, such as the desktop. The application requests that the user type a PIN.

The ocfserv server verifies the authenticity of the user by comparing the PIN typed by the user to the PIN on the smart card. If the PINs match, the user is either given access to the application, or ocfserv reads additional authentication properties on the card.

See "How to Set Up the Default Authentication Mechanism for the Server and Client Applications (Command Line)" for step-by-step instructions on setting this property with the command line.

Default Authentication for Client Applications

You set up authentication on the local system so it denies access to anyone who does not have the corresponding authentication mechanisms on the smart card. The server's authentication mechanisms are the default mechanisms used by ocfserv during smart card login.

If the user tries to access a client application with a different sequence set, ocfserv uses the client authentication mechanisms during login.

ocfserv authentication mechanisms must be activated before you can configure client authentication properties. By default, all authentication mechanisms supported by Solaris Smart Cards are activated when the Solaris 8 release is installed. These mechanisms are:

• Password

• PIN

• Challenge-Response

You must define properties for the default smart cards and the default authentication sequence used by the individual OCF client application. You protect sensitive applications running on the local system by configuring them to require login with a smart card. The default application to be protected is dtlogin, the application that controls logging into the Common Desktop Environment (CDE).

An application does not need to have the same authentication sequence as ocfserv. The client authentication sequence takes precedence over a different authentication sequence assigned to ocfserv. For example, you can configure "password" as the default authentication mechanism for ocfserv. However, you might want to add "PIN authentication" into the authentication sequence for anyone trying to access a client application, such as the Solaris desktop.

See "How to Set Up the Default Authentication Mechanism for the Server and Client Applications (Command Line)" for step-by-step instructions on setting this property from the command line.

Enabling Smart Card Operations

The final step in setting up a smart card is to enable smart card operations.

See "How to Enable Smart Card Operations (Command Line)" for step-by-step instructions on enabling smart card operations.

You cannot log in through dtlogin if you enable smart cards and:

• You do not have a working smart card, or

• You have not configured a smart card successfully

If you do not have a working smart card configuration and you enable smart cards, do the following:

1. Select Command Line Login from the Options menu in the dtlogin login screen.

2. Log in as superuser (root).

3. Disable smart card operations.

See "How to Disable Smart Card Operations (Command Line)" for step-by-step instructions on disabling smart card operations.