ControlSphere Token Management System (TMS)

The Token Management System of ControlSphere is a comprehensive set of tools and functions designed to help companies control the lifecycle of their secure devices (smartcards/tokens) fleet. In additional to that Token Management System (TMS) provides full control over secure data on the ControlSphere-enabled devices. ControlSphere TMS consists of two general parts: TMS server which is as an ASP extension installed on IIS and a client, which is nothing else but the ControlSphere client program itself.

In general ControlSphere TMS provides the following features:
TMS database holds centralized company-wide token, user and security group registry.
TMS database holds complete ControlSphere token data contents, including device PINs.
All changes on ControlSphere data made by a token holder on a client (ControlSphere program) are automatically replicated to the TMS database, including device PIN changes. The replication is done implicitly and securely.
ControlSphere data on a user's tokens can be remotely and securely updated from server using the push technology (pending updates) of TMS. The updates are made implicitly to a user.
TMS database maintains token data update history automatically. Token can be restored to its backed-up state remotely using the push technology of TMS.
It is possible to distribute ControlSphere data objects (such as encryption keys, password entries, configuration items, etc.) to a group of users/tokens using the push technology of TMS.
TMS database can be used to update ControlSphere license information and other configuration items on a token remotely.
TMS can be used to remotely reset locked User PIN.
TMS can ensure that contents of a lost or stolen token will be remotely wiped should someone try to use it.

Quick Links
TMS Management Console
  Group object
  User object
  Token object
  Token data objects and viewers
  TMS Clipboard
  Locating existing or adding a new token to the TMS database
  Preparing Updates for tokens (Token data editor)
  Distribute data to multiple tokens
  Changing administrative password for the TMS server
  Additional Configuration and Maintenance options
  Unlocking / Resetting User PIN remotely with TMS
Frequently Asked Questions (FAQ) on ControlSphere TMS usage


TMS Management Console

TMS Management Console is a part of standard ControlSphere program. It can be opened using ControlSphere tray icon menu, the link is under the "ControlSphere TMS" sub-menu. This menu is usually invisible in standard installations of ControlSphere. To make it visible you will either need to change configuration in windows registry or simply hold down Ctrl key while opening the menu.

To connect to a TMS server type server name to connect to and an administrative password for that server. You can also retrieve the server address and password from a locally connected token if it was setup to hold the configuration. You can store the configuration on a token while changing administrative password for the TMS server.


The main screen of the TMS Management console is split into two parts: the navigation pane containing object trees organized into tabs and the informative pane displaying data for a selected tree node.

The navigation pane holds three tabs, "Groups", "Users" and "Tokens". Each of the tabs contains corresponding tree of objects stored in the TMS database.

The "Groups" tree contains all groups in the TMS database sorted by names. Each group contains an alphabetically sorted list of users assigned to it. Each user, in turn, contains a list of tokens sorted by token description (if provided) or just be hardware serial number of the device.

The "Users" tree contains all users in the TMS database sorted by names. Each user contains a list of tokens sorted by token description (if provided) or just by hardware serial number of the device.

The "Tokens" tree contains all tokens registered in the TMS database. The tokens are divided into the "assigned" and "unassigned" ones. They are sorted by the device hardware serial number.

The object selection is persisted between the tabs. If an object is selected in on of the trees, it will be automatically selected in the other trees as well to simplify navigation and identification.

 
The informative pane displays data for a selected tree node. In general it displays a description on the object, a list of available actions for the node and other information.

There are three main objects in the TMS database: groups, users and tokens.
 
Group object
 
The Group object is a service object which serves as a container for TMS users. There can be a number of groups defined according to the enterprise structure. Group objects may contain user objects.

Group objects have the following attributes:
Name: Name of the groups which is displayed in the navigation tree.
Description: Optional description of the group.
The following actions are available for group objects:
Create new Group Creates a new group. Always available for the root node, in the toolbar and in the menu.
Assign users to the Group This function allows adding one or more TMS users to the group.
Modify Group This function allows changing group name and description.
Delete Group This function deletes a selected group from the TMS database. All users associated with the group are moved to the default one.
 
User object
The User object is a service object which serves as a container for TMS tokens. There can be a number of users defined according to the enterprise employee count. User objects may contain token objects.

User objects have the following attributes:
Last Name: Last name of the user.
First Name: First name of the user.
Description: Optional description of the user object.
Member of: Name of a group the user is member of.
The following actions are available for user objects:
Create new User Creates a new user. Always available for the root node, in the toolbar and in the menu.
Import Users from Active Directory This function allows importing one or more users from an Active Directory. Always available in toolbar and menu.
Modify User This function allows changing user name, last name and description as well as moving user to another group.
Delete User This function deletes a selected user from the TMS. All tokens assigned to the user are moved to the unassigned token pool.
 
Token object
The Token object is a key object of the TMS database. There can be a number of token objects per every hardware device of an enterprise.
The Token object includes a number of sub-objects, such as:
Latest known ControlSphere data on the token (data snapshot of a physical token device)
Pending updates for the token (a set of items to update on the token)
Token data update history (backed up historic changes as complete token data snapshots)

Token objects themselves have the following attributes:
User/Holder Name: Name of the user (if any) to whom the device is assigned.
Description: Optional description of the token object. Token description is an additional token identification mechanism. If present, it is used as a token name in Groups and Users trees.
Device Model: A model of the token device.
Chip Model: A model of the internal chip of the token device.
Serial Number: Software serial number of the device. In most cases it is equal to the hardware serial number.
Hardware Serial Number: Unique hardware serial number of the device.
Token Label: A software label of the token.
ControlSphere Licenses: A list of ControlSphere licenses available for this token.
TMS Server: A single or multiple TMS server addresses. There can be more that one entry, however all of them need to point to the same physical server. Typical configuration is either a single (local) server or local and external (public) name of the server. A configuration with local and external server names defined will allow the TMS connectivity to work from both inside and outside of the enterprise firewall.
Last known User PIN: Last known User PIN of the device. ControlSphere client replicates User PIN changes to the TMS database automatically should user change the PIN.
Administrator/SO PIN: Last known Administrator/SO PIN of the device. ControlSphere client replicates Administrator/SO PIN changes to the TMS database automatically should user change the PIN.
Re-initialization/Card PIN: Re-initialization/Card PIN of the device if present. This type of PIN protects smartcard/token from being re-initialized.
User PIN Reset initiated...: This property is visible in case the Remote User PIN Reset is initiated for the token only. It displays a one-time PIN Reset code which is passed to the token holder. This flag is automatically cleared once the PIN Reset procedure is complete on a client. Please see Unlocking/Resetting User PIN remotely with TMS for details.
The following actions are available for token objects:
Locate / Register new Token This function scans for locally connected token devices and either selects locally connected device in the TMS navigation trees (if the token is already in the TMS database) or initiates a new device registration process with the device. Always available for the root node, in the toolbar and in the menu.
Change Token description This function allows changing the token description.
Delete token (deregister from the TMS database) This action will remove the token object from the TMS database. By deleting the token will disable its management functionality with the ControlSphere TMS.
Add Licenses for one or more services of ControlSphere This action is available for tokens which does not have a license for one or more services of ControlSphere. This action opens an Enterprise License Manager which allows downloading required licenses from the ControlSphere license server to a TMS token. The licenses can then be uploaded to a physical token device remotely should ControlSphere client require them on the token.
Change TMS Server(s) for the token This function allows changing a list of TMS servers for the token. See description of the TMS Server property above for details.
Display Token PINs /
Hide Token PINs 		This function shows or hides token PINs among the token properties. PINs are shown in a clear text and are hidden by default.
Modify Token PINs in the database manually This function allows changing the token PINs in the database manually. Usually the PINs are synchronized by TMS means. TMS administrator can update the PINs manually to correspond the ones on the token device should they become out of sync.
Remotely erase token data / Blacklist token This function should be used in case a token has been lost or stolen only. Blacklisting the token will ensure that its data is not going to be accessed (even is someone knows its PIN) since it will self-erase according to the TMS command. This function will prepare "erase" pending updates for the current token. The function will also mark the token as "blacklisted" but will leave it assigned to the current user for later reference.
Initiate remote User PIN reset /
Cancel remote User PIN reset 		This function has an effect on tokens with a locked User PIN only. It allows TMS administrator to define one-time PIN reset code and initiate Remote User PIN reset process for the token. Please see Unlocking/Resetting User PIN remotely with TMS for details. The initiated PIN reset process can be manually cancelled.
Perform maintenance of the token
(locally connected devices only) 		This action opens ControlSphere Token Maintenance Console (token needs to be physically connected to the local computer) which allows to:
View and modify ControlSphere data on the token directly
Backup and restore token data
Change or Reset User PIN of the token
Change Administrator PIN of the token
Remove ControlSphere-specific data from the token
Re-format the token
All changes on token data are automatically replicated to the TMS database. Same operations are accessible from the ControlSphere tray menu.
Reload Token data and state from the TMS database This action reloads token data and state from the TMS database. It is useful in case the TMS administrator is monitoring changes on the token object in real time, e.g. remote User PIN Reset is initiated and the administrator wants to see if the PIN reset has been accomplished by a user.
 
 
Token data sub-object (latest known ControlSphere data replicated from a token device)
  The Token data sub-node contains latest known ControlSphere data image of the token device. ControlSphere client updates this data image automatically in case of any changes made by a user to the contents of the device. See detailed description on the token data image objects below.
   
 
The following actions are available for Token data sub-objects:
Modify current data
(prepare pending updates for this token)		 This action will open Token data update editor with the current image data. Once completed, pending updates will be set to this token.
Clone to another token
(prepare pending updates for another token)		 This action will open token browser window to select a destination token. Then a Token data update editor with the current image data will be opened to define data subset. Finally the pending update data will be set to the destination token.
Restore on locally connected token This action will open simplified ControlSphere Token data restoration manager window which will use the data image as a source and restore it on a locally connected token device.
   
Pending updates sub-object (updates which are waiting to be downloaded by the ControlSphere client for the token device)
  The Pending updates sub-object is shown in case pending updates exist for the token. Pending updates is a subset of data which is waiting to be downloaded by the ControlSphere client for the token device. Once downloaded and installed on the token, the sub-object is removed, current Token data sub-object of the token is updated and previously known Token data is moved to the token update history.

Pending updates may not contain the complete ControlSphere data set but rather selective data items to be updated on a token only. They are still stored in a format of token data image objects. See detailed description on the token data image objects below.
   
 
The following actions are available for Pending updates sub-objects:
Modify pending updates
This action will open Token data update editor with the current pending update image. Once completed, updated pending updates will be set to this token.
Cancel/Delete all pending updates for the token This action removes all pending updates for the token. The pending update sub-item is removed.
   
Update History sub-object (update/backup history data images for a token device)
  The Update History sub-object is shown in case one or multiple backup images of the token device exists in the TMS database. The sub-object contains a list of historic backup images (see below). The backup images are produced on every token device data update but not more frequent than once a day.
   
 
The following actions are available for the Update History sub-objects:
Delete all backup images This action removes all backup images for the token from the TMS database.
 
Historic backup image of the token (individual backup image under the Update History node)
  The Update History sub-object contains a list of historic backup images sorted by the image creation date. They are stored in a format of token data image objects. See detailed description on the token data image objects below.
The following actions are available for individual historic backup image items:
Restore on this token
(set as pending updates) 		This action will open Token data update editor with the current image data. Once completed, pending updates will be set to this token.
Restore on another token
(set as pending updates for another token) 		This action will open token browser window to select a destination token. Then a Token data update editor with the current image data will be opened to define the data subset. Finally pending updates will be set to the destination token.
Restore on locally connected token This action will open simplified ControlSphere Token data restoration manager window which will use the data image as a source and restore it on a locally connected token device.
Delete backup image This action removes the backup image from the TMS database.
 
 
Token data objects and viewers
TMS database holds token data images in a ControlSphere token data format. They are complete or partial (in case of pending updates) snapshots of ControlSphere data.

The images may contain additional configuration options for pending update nodes, such as TMS Server address update option for a token. Data image contents are displayed in the informative pane of the TMS Management Console.

ControlSphere data items are presented as a multi-branch tree view. In most cases tree nodes have additional actions which can be seen by right-clicking the nodes. Some objects have their attributes enclosed in child tree items but some needs to be right-clicked to activate an object viewer.
ControlSphere TMS allows additional protection for the User data items on user tokens by introducing record locking mechanism. An administrator can lock encrypted volume automation and password records, making them read-only for users. By locking password records will as well disallow users from viewing or copying passwords in clear text.
All data items can be copied to TMS Clipboard by opening item menu (right-click the item) and selecting an appropriate action. Data items copied to the TMS Clipboard can be used in creation of pending updates for single or multiple tokens.
 
 
TMS Clipboard
TMS Clipboard is internal clipboard storage for the TMS Console. Its contents are stored securely and are accessible to the TMS Management console only. The main intention for the TMS Clipboard is ControlSphere token data item exchange between the TMS console tasks. TMS Clipboard is mainly used in preparation of pending updates and data item distribution to multiple tokens process.
Select the desired items to paste or distribute by ticking corresponding tree nodes. Right-click nodes for additional options such as view item contents or remove an item from the TMS clipboard.
 
 
Locating existing or adding a new token to the TMS database
TMS Management console provides easy identification and new token registration functionality. To register a new token with the TMS database or locate an existing token record first connect the desired token to a computer running the TMS Management Console. Then select the Locate / Register New Token option from either menu or toolbar. The program will identify the connected device and will either select a corresponding record in the navigation pane or start new token registration process to the TMS database.

Adding a new token to the TMS database

First of all the program checks if the token has a license for use with ControlSphere TMS. If the device does not contain a license yet, the program will prompt to acquire a license for it using the Enterprise License Manager tool for the TMS service (and possibly other services of ControlSphere). You will need to select desired ControlSphere services to license the token. Then provide an account name/password for your account on the ControlSphere license server. Please refer to your ControlSphere sales provider for details. The device registration process continues once the token has a valid license for the TMS service stored on it.

Then you will be asked to provide current PINs of the device. User and Administrator/SO PINs are mandatory for the device while Re-initialization/Card PIN is optional (provided for reference only) since some of the token models have no support for this type of PIN.

By clicking Use default PIN values will set the default value for each PIN type according to the given token model. This is useful when registering factory- initialized tokens. Do not forget to change the default PINs later. You can force a token user to change the default User PIN on first use by setting a flag in the ControlSphere token security policy (enable the Force User PIN change at next authorization flag).

Then you will be asked to define TMS server configuration for the token. Please make sure to set the current TMS server as a primary one. Secondary servers can be added as aliases to the primary one, e.g. external name(s) of the server to try in case the internal (primary) one can not be contacted. ControlSphere tries to contact the servers in the order they are defined on the token. Please see FAQ on how to define TMS server configuration for a token for additional information.

Finally the token will be registered with the TMS database and the token object will be selected in the navigation pane. The initial ControlSphere data snapshot of the token will be stored in the database as a current Token data.
 
 
Preparing Updates for tokens (Token data editor)
Token data editor is a powerful tool which allows creating customized token data update packages (pending updates). The editor window is split into two parts: data categories to modify on the destination token and the excluded data categories.
The excluded data categories part displays categories which will not be updated on the destination token. Click a category to bring it to the update list.

The data categories to modify on the destination token part displays ControlSphere data item tree to update on a token. The categories (account credentials, encryption keys, password bank and all others) displayed in this part will be updated (rewritten) on a token with the contents exactly shown in the tree.

Right-click tree items for additional options.
 
Available actions for the tree items (right-click options)
There are common and item-specific actions available for the tree items. A set of item-specific actions include such actions as: create new object, delete an object, import an object, view object contents, etc. Common actions apply to categories. They are:
Delete all This action deletes all items from a category. By leaving the category empty will indicate to remove all items of such type from a destination token. E.g. leaving Password Bank category empty will result in removal of all password entries on a destination token.
Exclude this category from updates This action will exclude the category from updates and move it to the excluded data categories area. This category will not be updated on the destination token.
Copy all entries to TMS Clipboard This action copies all items contained in the category to the TMS Clipboard.
 
To merge additional data items to the compilation click the Paste data items from TMS Clipboard button . Doing so will open TMS Clipboard window and allow to select and merge one or more items to the token data update compilation.
 
 
Distribute data to multiple tokens
TMS Management Console provides an ability to prepare data and configuration item updates to multiple tokens in the TMS database. This function greatly simplifies administrator work in case same objects (e.g. new encryption keys) needs to be distributed to a group of users.

First the desired items need to be copied to the TMS Clipboard. Then Distribute data to multiple tokens action needs to be triggered from either toolbar or menu. A list of items in the TMS Clipboard available for distribution will be displayed. Select the desired subset and click Proceed.
Finally a token browser window will be displayed. Select individual tokens or group to distribute the objects to and click OK. The program will then set the selected data item subset as pending updates for the selected tokens.
 
 
Changing administrative password for the TMS server
You can change administrative password for your TMS server by triggering an appropriate menu item from the TMS Server sub-menu. You will be asked to provide the current password as well as new password to set (with confirmation).

We recommend using secure passwords (i.e. passwords containing upper and lower-case letters, digits and special characters) to ensure proper protection against password attacks.
You can store the TMS server connection parameters (server name and password) on a ControlSphere token. In this case you will be able to automatically use your token while connecting to the TMS server. To do so select the Store/update the password on ControlSphere token option. Doing so will create a password entry named "TMS Server" on the token with the current server name and the new password.
 
 
Additional Configuration and Maintenance options
Compacting/De-fragmenting the TMS database
  Although TMS database does not require a lot of space, it is recommended to compact it periodically to avoid performance degradation. The compacting/de-fragmenting process usually takes few seconds or even less. You can submit the compact request to the database by selecting an appropriate menu item in the TMS Server sub-menu.
Selecting token device type to use
  You can temporary switch to a different hardware token type during the TMS Management Console session by selecting an appropriate menu item in the Configuration sub-menu. This is useful if an enterprise is using different hardware token models so the program can quickly change the token type to work with. The changes are not persisted.
 
 
Unlocking / Resetting User PIN remotely with TMS
Smartcard/token devices support automatic User PIN lockup should an incorrect PIN be entered a number of times consecutively (the number of tries is dependent on a token model and device initialization parameters). In this case token data becomes inaccessible until the PIN is unlocked by an Administrator/SO PIN.

A typical solution in such a case is bringing the token to an administrator and resetting the PIN. The Administrator/SO PIN of the device must be known by the administrator person to perform the operation.

ControlSphere TMS provides much more useful solution to the problem. There is no need to physically bring a locked token to an administrator and there is no need the administrator person to remember the Administrator/SO PIN of the device. The TMS database holds all the information instead and the TMS client (ControlSphere program) is able o reset the locked User PIN remotely.
Typical sequence of the remote User PIN reset procedure:
Once the PIN is locked and a token is registered with the TMS, a notification is displayed to a user.  
The user identifies himself as a legitimate token holder to the administrator (up to security policy of the enterprise).
   


The administrator locates user record and the token in the TMS database and enables the Remote User PIN Reset option for it, defining the one-time PIN reset code (any character sequence, at least 4 characters long).		  


The administrator reports the one-time code to the user.


The user then closes the notification with OK. He is then prompted to enter the one-time PIN Reset code. 		 


Once the code is entered, the user is prompted to define a new User PIN for the token.		  
Finally the new User PIN is set and the PIN reset flag is cleared in the TMS database automatically.
Please note that enabling the User PIN Reset flag on a TMS token object with a non-locked PIN has no effect as the flag is automatically cleared next time a user authorizes the token with ControlSphere.


Frequently Asked Questions (FAQ) on ControlSphere TMS usage
How does the TMS client (ControlSphere) communicate with the server? Is there anything special needs to be set up?
  ControlSphere client uses plain HTTP connectivity while communicating with a TMS server. The data in transit is encrypted by super-strong chained AES256 encryption (up to 8 stacked AES256 keys) which ensures maximal data protection. This way there is no need to configure client firewalls as HTTP connectivity is initially setup. There is no need to setup an SSL channel as well.

Using HTTP implies usage of the default 80 port. This can be changed as needed by setting up the TMS server on a different port and configuring TMS Server addresses on the company tokens accordingly.

I need TMS functionality for my token inside and outside of the company firewall. How can I achieve that?
  ControlSphere token may have one or more TMS servers defined. The server list is defined at the time the token is being registered with the TMS database. ControlSphere client tries to contact the servers in the order they are defined on the token.

You should set local TMS server (shown as ssl-server on the screenshot) as a primary one and a name of the public company server/firewall gateway (shown as www.controlsphere.eu:8010 on the screenshot) as a second one.

Then you need to create a "port forwarding" rule in the company firewall for the port 8010 (8010 is just an example, any port number can be used) which will forward the calls to the server locally known as ssl-server:80 (port 80 is the default port for HTTP calls and TMS uses HTTP connectivity).

This way both internal and external calls from TMS clients will be brought to the same server.

Finally you need to ensure that the servers can be accessed directly and the access is not blocked by any type of proxies.

Additional Note: There is a possibility to change the TMS Server list configuration for a token remotely. This way entire enterprise can be migrated to a different TMS server in case of a need.

What kind of improvements to my daily (administrator) tasks will provide usage of ControlSphere TMS?
  ControlSphere TMS provides two general benefits to the enterprise and administrative staff. First of all it provides inventory service for all smartcard/token devices which are used in the enterprise. TMS database serves as a notebook for all ControlSphere data on the smartcard/token of the company, including service information such as device PINs. ControlSphere client replicates all changes (including device PIN changes) to the database in case contents of the registered devices are modified on a client by a user.

Secondly TMS functionality allows remote management of the device contents, such as ControlSphere data or configuration object distribution and remote User PIN Reset functionality. Using the ControlSphere TMS allows remote management of the company smartcard/token devices in remote locations. Distance is no longer an issue.

When does ControlSphere program communicate with the TMS?
 

ControlSphere contacts the TMS server every time token is being authorized (i.e. User PIN is retrieved). This way pending updates and other changes are replicated from/to the server automatically before the token authorization process completes. Token data changes made by users are automatically replicated to the TMS server in background.

A user has lost his token. Is there a way to ensure that no-one is getting the data out of it?
  First of all smartcards/tokens are protected with a User PIN and will rather self-lock then allow someone to access the data. There is thought a probability that someone could steal the "lost" device and somehow find out what the PIN is. In this case he will be able to use the device with ControlSphere and access its contents.

ControlSphere TMS provides extra token data protection for such cases. TMS administrator can optionally mark the token as lost and prepare "empty" pending updates for it. An "empty" update set should contain all the categories (i.e. Windows user accounts, encryption keys, password bank, etc.) with no contents. ControlSphere will automatically download and store (basically empty token contents) the updates to the token should someone try to use it. This ensures that no-one will be able to use the token even if the User PIN is known.

A user located in a remote affiliate has lost or damaged his token. Is there a way to restore the device remotely with the TMS?
  Of course there is no way to restore same device in this case since it either lost of damaged. But ControlSphere TMS can definitely help if there is a spare device (previously registered with a TMS and somehow tagged for identification) is available for the user. Regardless of the unavailability of the hardware device, TMS database always has a latest data snapshot of the ControlSphere data on it. Thus the data is always available for restoration on another smartcard/token device, either locally or remotely.

TMS administrator locates the spare token device record in the TMS database (identified by a tag of the token reported by the user) and assigns it to the user by TMS Management Console means. Then he simply sets pending updates for the new token from the Token data sub-item of the original device. The updates will be downloaded next time the user will authorize (enter User PIN) the new token in the ControlSphere client. This way the user will have a functional clone of his original token which can be used instantly.

It is not necessary for the "spare" tokens to have licenses for the required services of ControlSphere (except the TMS service license which is required) at the time they are registered with the TMS database and shipped to a remote storage. TMS administrator can acquire the licenses in a real time using the Add Licenses for one or more services of ControlSphere function of the token object. The newly acquired licenses will be uploaded to the token by the TMS means when ControlSphere client will require them.

Additional note: the new token will probably have a default User PIN set. TMS Administrator can force a user to change it on the first use by setting a flag in the ControlSphere token security policy (enable the Force User PIN change at next authorization flag) while preparing pending updates for the new token or at the time the "spare" token is registered with the TMS database.