Software Token ProfilesSoftware Token Profiles
Software token profiles specify software token configurations and distribution processes. A software token profile is required for each platform for which you plan to distribute software tokens. Only a Super Admin can add software token profiles to the deployment. Software token profiles are available to the entire deployment and are not specific to a security domain.
Device Definition FileDevice Definition File
A device definition file is an XML file that defines the capabilities and attributes of software tokens used on a specific platform, for example, the Android platform or the iOS platform. The file identifies the following:
-
the supported tokencode characteristics
-
the token type
-
whether the token is CT-KIP-capable or QR Code-capable
-
CT-KIP link format
-
whether the token is CTF-capable
-
the supported binding attributes
When RSA releases applications for new software token types, the applications often require new device definition files. You must import the new device definition file when you create a software token profile using the new token type. To determine whether you need to import a new device definition file, see the Release Notes for your software token application.
Software Token ConfigurationSoftware Token Configuration
SecurID software tokens are factory-set as PINPad PIN type (PIN integrated with tokencode), 8-digit tokencode length, and 60-second tokencode interval. However, you can configure the tokencode interval, PIN type, and tokencode length of software tokens for each software token profile that you create. Depending on configuration options set in the device definition file, you can set the tokencode length to 6 or 8 digits and the tokencode interval to 30 or 60 seconds. You can change the PIN type so that the token allows alphanumeric PINs, just like a fob-style hardware token. You can also reconfigure the token to be tokencode only.
Software Token Delivery MethodsSoftware Token Delivery Methods
The following methods are available for providing token data to a software token application:
Dynamic Seed Provisioning (CT-KIP) Dynamic Seed Provisioning (CT-KIP)
The dynamic seed provisioning method uses the four-pass Cryptographic Token Key Initialization Protocol (CT-KIP) to exchange information between an SecurID client application running on a mobile device, laptop, or desktop, and the CT-KIP server, which is a component of the Authentication Manager server. Information exchanged between the client and server generates a unique shared secret (token seed). This information is encrypted during transmission using a public-private key pair. The generated token seed value is never transmitted across the network.
The four-pass CT-KIP protocol is initiated by a request from the client application to the CT-KIP server when the user selects an import token option on the client device. The client application must be provided with the activation code, either through manual user entry, or as part of a URL string.
Dynamic seed provisioning uses a unique, one-time provisioning activation code to ensure that the request is legitimate. There are two ways to deliver software tokens using CT-KIP:
-
Send the user an email containing the CT-KIP URL and activation code. Clicking the link imports and activates the token.
-
Provide the user with a QR Code that encapsulates the CT-KIP URL and activation code. Scanning the QR Code in the Self-Service Console imports and activates the token.
If you configured activation codes to expire, a user must provide the activation code to the client application before the code expires. If the activation code is not used before the expiration time, you must redistribute the token, and provide the CT-KIP URL and the new activation code to the user.
RSA recommends using the RSA Authentication Manager dynamic seed provisioning feature because the CT-KIP process helps prevent the potential interception of the token’s seed. Only use SDTID or CTF if your company policy dictates that the Token apps cannot connect to the Internet or that a CT-KIP server cannot be set up.
File-Based Provisioning File-Based Provisioning
With file-based provisioning, Authentication Manager generates token data contained within a file, which is added to a ZIP file for download. Software token files provisioned using this method have the extension .sdtid. The data in the token file includes the seed used by the SecurID algorithm and other metadata, including the token serial number, expiration date, number of digits in the tokencode, and so on. To protect the seed against attack, the seed is encrypted using the AES encryption algorithm and an optional password that you can assign during the configuration process. RSA recommends protecting file-based tokens with a strong password that conforms to guidelines provided in the RSA Authentication Manager Security Configuration Guide.
Compressed Token Format (CTF) Provisioning Compressed Token Format (CTF) Provisioning
E-mail programs on some mobile device platforms cannot interpret .sdtid file attachments. In such cases, you can deliver file-based tokens using Compressed Token Format (CTF). Authentication Manager generates token data in the form of a CTF URL string, which you deliver to the user's device by e-mail as a URL link. CTF URL strings contain the encoded token data needed by the software token application. This encoded data includes the seed used by the SecurID algorithm and other metadata, including the token serial number, expiration date, number of digits in the tokencode, and so on. The URL format signals the device that the URL link contains data relevant to the software token application. RSA recommends protecting CTF format tokens with a strong password that conforms to guidelines provided in the RSA Authentication Manager Security Configuration Guide.
The email with the encoded token data should not contain the binding ID and should be sent to only the intended recipient.
Device AttributesDevice Attributes
Device attributes are used to add information to software tokens. You can use the DeviceSerialNumber field to restrict the installation of a token to a device platform or to a specific device. The default DeviceSerialNumber value associated with the device type binds the token to a specific platform. Binding to a device platform allows the user to install the token on any device that runs on that platform, for example, any supported Android device. The user cannot install the token on a different platform, such as iPhone that uses iOS.
You can bind a token to a single, device-specific identification number, for example, a separate, unique device ID assigned by the SecurID software token application. Binding is engineered to allow the token to only be installed on the device that has the device-specific ID. If a user attempts to import the token to any other device, the import fails. You can bind tokens before you distribute them. In some cases, you must obtain the device binding information from the user. The user must install the software application before providing the binding information. For more information, see your SecurID software token documentation.
The Nickname field allows you to assign a user-friendly name to the token. When the token is installed into the application on the device, the application displays the token nickname. If you do not assign a nickname, the application displays a default name, for example, the token serial number. Not all software token applications support nicknames.
