- 23 Oct 2024
- 2 Minutes to read
- DarkLight
Device binding with standard licenses
- Updated on 23 Oct 2024
- 2 Minutes to read
- DarkLight
Mobile Authenticator Studio post activation process involves synchronizing the server and device, binding the authenticator to the server, and transferring a device seed for generating valid responses. The device seed is scrambled with an OTP for security. The process can be done online or offline, with options to display messages and re-generate codes. The configuration file allows customization of the derivation code length and display pattern. Failure to acknowledge the activation process may result in authenticator destruction. The process enhances security by ensuring only the bound device can generate valid responses.
Once Mobile Authenticator Studio has been activated locally, the server must receive the information to ensure that both parties are synchronized. This is a Mobile Authenticator Studio post-activation process.
In addition to the synchronization between the server and the device, the post-activation process can be used to bind the authenticator on a device to its BLOB on the server. This binding process consists in injecting a device seed in the authenticator's BLOB. Because this seed is used by the Mobile Authenticator Studio application to generate responses, only the authenticator installed on the bound device will generate valid responses.
Device binding is an enhancement of the regular server activation process.
Device binding
The seed used to identify the device is computed from the available device information. To transfer the device seed to the authenticator BLOB on the authentication server, it is scrambled with an OTP in the derivation code. Once this code is verified on the server, the authenticator BLOB secrets will be derived using the device seed. The derivation code is verified by the Authentication Server Framework AAL2DeriveTokenBlobs function.
The derivation code can be transferred to the authentication server during online or offline post-activation. The post-activation process starts right after Mobile Authenticator Studio has been activated on the device. This process is enabled in the post-activation section of the application’s configuration file.
With online post-activation, the derivation code is sent to the server via a network request.
Device binding (online post-activation)
If the server does not acknowledge the post-activation process by returning a non-zero return code, Mobile Authenticator Studio will display the message returned by the server. In addition, if the destroyOnFailure attribute of the PostActivation element in the configuration file is set to true, it will destroy the authenticator instance.
If the displayMessageOnSuccess attribute of the PostActivation element in the configuration file is set to true, Mobile Authenticator Studio will display the message sent by the server even if the return code is zero.
With offline post-activation, the derivation code is displayed to the user, who needs to submit it to the authentication server.
Device binding (offline post-activation)
The cryptographic application that generates the OTP used to create the derivation code is configured in the authenticator's configuration file. Any Response-Only, Challenge/Response, or multi-mode application can be used. You can also apply a display pattern for the derivation code.
In the post-activation section of the configuration file, the application can be configured to provide a button for re-generation in the Settings menu. Thus, users will be able to re-generate the derivation code if needed.
If the derivation attribute in the configuration file is set to false, the device seed will not be used and a simple OTP will be generated in place of the derivation code.
The derivation code can be between 5 and 26 characters long. If a display pattern is used, the maximum length must be used to define the pattern.
Length(OTP) +1 <= length(derivation code) <= length OTP + 10