We work with many customers who struggle to figure out the best way to provision credentials. Credentials are the “keys to the kingdom” and it is critical that customers find an adequately secure provisioning process. When provisioning credentials, extreme vigilance must be maintained. None of us want to consider some unauthorized party getting access to the resources the credentials are intended to protect.
There are a number of challenges to securely provisioning tokens.
- How can I communicate with the end user in a secure manner?
- How can I vet the identity of the recipient?
- How can I be sure that only the intended recipient was able to access the credentials?
- How can I provision what may be a large number of credentials efficiently?
This comes down to a common thread throughout all security-related procedures: finding the right balance between convenience and security.
When credential provisioning is involved, it is also important to consider the frequency. Provisioning is not something that should occur on a regular basis, so I find that most customers lean more toward security than convenience. Focus on convenience for the day-to-day authentication mechanisms, not the provisioning process.
I used to work for a company that had what I considered to be a very secure password (or password reset) provisioning process. If you forgot your password and called the help desk, they asked you your location and then directed you to walk to the nearest guard station. At the guard station, the help desk called the guard and asked them to check your photo identification badge to verify your identity. After the guard had verified your identity, they handed you the phone and the IT help desk provided a temporary password that had to be changed at your next logon.
This was clearly a very secure process involving a “trusted third party” (i.e. the guard) and a previously issued credential (the user’s security badge), but it was not what I would consider to be very convenient. Passwords could not be reset if you were off-site, and outside of normal working hours you might have a long walk to the nearest manned guard station. On the other hand, forgetting your password or needing a new password was something that should not occur on a regular basis.
Securely provisioning credentials requires customers to avail themselves of every protection available. This follows another core security tenant: leverage defense-in-depth wherever possible. Unlike a physical credential (i.e. a key), electronic credentials offer the administrator a number of additional defenses. Electronic credentials can be enabled only once we have verified they’ve been received by the intended recipient. Some credentials may also involve a personal identification number (PIN) as an additional defense. If possible, administrators should provide a temporary PIN (changed at first use) along with the credential. Others may have a password that can be used as an additional level of protection for the credential while in transit. All of these mechanisms improve the security of the credential while in transit.
Case in point: RSA SecurID Software Tokens and Compressed Token Format
RSA SecurID software tokens can be provisioned using a Compressed Token Format (CTF) code. This is a credential provisioning format that contains the token initialization values (i.e., seed, serial number, start date) in a convenient code that can be emailed to the end user and is easily imported into a device. These values are typically encrypted with a password and another value called the binding ID. While extremely convenient, care must be taken to leverage all available CTF protection mechanisms depending on the potential exposure of the data during the provisioning process.
The binding ID is a value generated during the installation of the software token and is provided to the administrator by the end user. The software token attempts to make this as convenient as possible by providing a link that generates an email containing the binding ID. The administrator uses this value to generate a CTF code that, in conjunction with a password, can be used to initialize a software token. Note that this creates a “two-factor authentication” mechanism for the CTF (which we all know is better than a single factor).
Software tokens may also be provisioned through mechanisms that greatly limit the exposure of the CTF value. For example, the CTF can be provided to the software token as a graphical “QR Code” displayed from a secure self-service web portal. Since accessing this portal would have already required the end user to have performed some form of authentication, adding an additional password may be unnecessary and inconvenient. On the other hand, if the administrator was sending the CTF code via unencrypted email, an additional password (provided to the end user through some other, secure mechanism) would be critical to the security of the provisioning process.
Since the binding ID also contributes to security, it would also be important to have procedures that keep this value and the CTF code separate. An administrator that received a binding ID via email should use care to not simply reply to the same email (as this leaves the binding ID in the email response). During this sensitive process, we want to make it as inconvenient as possible for any bad actors that may be attempting to steal credentials. Replying to a “Binding ID” email with a CTF code would create a neat package of data that, if obtained by a malicious party, would provide them with many pieces of the puzzle. Intercepting just a CTF code without the corresponding binding ID would leave the bad actor looking for this and other data. Optimally, the binding ID would have been provided to the administrator through some other channel, such as a phone call.
This begs the question: “How does the binding ID contribute to the security of the solution?” While it is a factor that is used to protect the CTF code, the binding ID also helps the administrator prevent a legitimate user from installing the software token on more than one device (which poses a separate security risk). If we assume the bad guy has somehow gained access to the user’s binding ID, it provides little protection from someone, using a rooted or jail-broken device who attempts to use an ill-gotten CTF code to clone the token. In this scenario, the CTF password is critical and would help prevent the bad actor from creating a copy of the token. Thank goodness for defense-in-depth! Since the administrator was very security-conscious, the token was also left disabled until the administrator could confirm it was received by the recipient, and a temporary PIN was set (which was separately provided to the end user through a secure channel). These additional steps add significantly to the security of the provisioning process. Even if a bad actor was able to obtain and use the CTF code, they would not know the temporary PIN associated with the credential and the intrusion would be quickly discovered.
Threat Modeling for Provisioning
Security administrators should be creating and maintaining an internal threat model specific to their credential provisioning practices and procedures. I like to start by focusing on the most valuable assets and look at how those might be compromised. The other critical activity is to identify a number of threat model assumptions. These are very helpful to simplify and create a “boundary” for the model. The goal of threat modeling will be to develop a level of confidence that the procedures in place will be sufficient to stop a simple and undetectable attack. This exercise will also identify points at which provisioning data may leave your control, which could lead you to consider additional layers of security that could be added to further complicate and prevent unauthorized access. In the CTF example above, data being sent by unencrypted email was a clear point at which some control of the provisioning information was lost.
In general, this process leads to a long sequence of “what if?” questions, which in turn lead to security mechanisms that are rooted in the model’s assumptions. Some examples:
- How do end users prove their identities to the administrator?
- Who is authorized to provision credentials and how is that process controlled?
- How will the credential be transmitted to the end user and what protects it during this process?
- If this is a software-based authenticator:
- How to I control devices (i.e. phone, laptop, tablet) the end user can use as an authenticator?
- How can I be sure the end user has the correct software?
- If a credential is compromised during the provisioning process, what could the adversary do with the credential and what could they access?
And perhaps one of the most important questions: are the assumptions on which I am basing my threat model correct?
Once the model is complete, it should help you make any necessary changes to the provisioning process to close any identified security gaps. Every threat model should result in a plan-of-action with changes to enhance your security posture.
Keys to the Kingdom
Bottom line, when provisioning credentials, you are intending to provide the keys to your kingdom (or a small part of it) to a trusted associate. Make sure that they are the only person who can actually get those keys by following these steps:
- Develop a credential provisioning threat model while carefully examining your security assumptions. This model should form the basis of your credential provisioning procedures.
- Consider additional steps to add “defense-in-depth” to the provisioning process. I recommend that our customers make use of every available protection, especially in the sensitive credential provision process.
- Review and audit the actual procedures for adherence to the security plan. Security procedures are only effective if they are being followed.
- As the security landscape is constantly changing, revise and update the threat model and procedures on a regular basis.
For more information, please take a look at the RSA Authentication Manager Software Tokens Best Practices Guide (DOC-35128).