IBM Robotic Process Automation Vault
Learn more about the security of IBM Robotic Process Automation Vault.
IBM Robotic Process Automation Vault uses asymmetric encryption. This type of encryption uses a pair of keys:
- Public keys that can be propagated
- Private keys that only the owner knows about it
In this encryption system, any person can encrypt a message using the public key. However, the message can only be decrypted using the private key. With this, strong encryption security is ensured without the need to share a single common key across all parties.
The IBM Robotic Process Automation Vault is split into two functionalities: the system and the user vault. Both of them use asymmetric encryption, with slight differences.
Contents
What is a credential?
A credential is a key that identifies in IBM Robotic Process Automation a user and password pair. You use credentials to access an application, module, or a specific feature that is being automated. You can also use credentials to automatically unlock the machine where the bot will be executed.
For the system vault, the credential represents a set of user and password, whereas, for the user vault, the credential itself does not represent a specific user, nor a set of user and password, but rather a “profile” of a specific user and password pairs.
Credentials are used in bots for users who must perform a task or process. These credentials are also used in the execution of user-scheduled requests in IBM Robotic Process Automation, and in these cases, the system impersonates the user represented by the credential logged in at the time of scheduling. Note that all user access permissions are used to perform the task.
System and user Vault
The system vault, also called RPA Vault, is recommended for unattended bots, where the automation process runs without the need for human intervention. This vault must be configured in the Web Client by uploading a public key and specifying the location of the private key so it can be found in the Client’s computer or a search method reference for the Windows Certificate Store. The private key is not stored in IBM Robotic Process Automation Server.
The credentials from the system vault are specified by the user and are encrypted with the public key configured in the Web Client. When the bot needs the credential, during the getVaultItem command execution, the bot, running locally in the Client’s computer, gets the encrypted credential from the Server and decrypts it locally using the private key specified in the Web Client.
The user vault, also called RDA Vault, is recommended for attended automation, where the bot works with the user to accomplish a task. In this case, the credential definition is created in the Web Client, but the configuration of its values is informed locally in the Vault component.
The Vault component is responsible for the configuration and encryption of the credentials. The vault generates a pair of public and private keys based on the user's master password. Since it can be propagated, the public key is stored as a string literal in the database, and the private key is strongly encrypted using techniques such as Hash PBKDF2. For more information, see Data encryption.
Registering credentials in the user vault is not made centralized in the Web Client, but individually by each user. Each user that uses the component needs to configure their credentials beforehand.
What is asymmetric key encryption?
Asymmetric key encryption, also known as public key encryption, uses two distinct keys:
- A public key that can be freely disclosed
- A private key that must be kept secret by its owner
When the information is encoded with one of the keys, only the other key of the pair can decode it. The private key can be stored in different ways, such as a file on the computer, a smartcard, or a token. Examples of cryptographic methods that use asymmetric keys are Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm (DSA), Elliptic-curve cryptography (ECC), and Diffie-Hellman. These cryptographic methods are used by financial institutions and governments to protect highly sensitive documents and data transmission.
Asymmetric key encryption, despite having slower processing than symmetric key, solves several problems because it makes management easier because it does not require keeping a secret key of each one that it needs to communicate with. Additionally, it eliminates the need for a secure communication channel for key sharing.
Data encryption
IBM Robotic Process Automation uses an encryption subsystem that largely employs AES and RSA algorithms, among other standards. This subsystem is used throughout IBM RPA’s product line for the protection of sensitive data.
In Cryptography, the Advanced Encryption Standard (AES), also known as Rijndael, is a block cipher adopted as the standard encryption algorithm by the United States government. It is not only used worldwide, as it is also extensively analyzed and tested, just like its predecessor, the Data Encryption Standard (DES). AES was announced by NIST (National Institute of Standards and Technology) on the US FIPS PUB (FIPS 197) on November 26, 2001, after 5 years of standardization. Since 2006, the AES is one of the most popular algorithms for symmetric key encryption.
This algorithm has a high resistance to attacks such as “power attack” and “timing attack” and requires little memory, which makes it suitable to operate in restricted environments like “smartcards”, PDAs and cell phones.
The RSA, on the other hand, is considered one of the safest, as it has resisted all attempts to break it. It was also the first algorithm to enable digital encryption and signature, and one of the major innovations in public key cryptography. One of the security measures used in the adoption of this widely used algorithm was to implement very large keys.
This subsystem has been created so that, in the case that the client’s password or digital certificate is lost, the data can never be recovered. This mechanism prevents the secret/password/encryption key from being in IBM RPA’s possession, either as files or stored on servers.
The bot that runs locally on the Client’s machine gets the encrypted credential from the Server and decrypts it locally using the private key specified during the configuration in the Web Client.
In the user vault, the database Server stores data with enabled auditing (at the database instance level, a resource available since SQL Server 2014) and the Bot Agent authenticates the requests through a proprietary method that combines different encryption techniques, including the use of a one-time pad (OTP). After authentication, the Bot Agent encrypts data with recursive routines using a variety of asymmetric key pairs with variable length, including 2048 bits. This encrypted data is stored in the database through a request to the application servers and the data traffic is also encrypted.
One-Time Pad (OTP) – single-use cipher or single-use key – is an encryption technique that cannot be broken if used correctly. Just as a comparison, it is an evolution of the token used by banks to validate a customer.
Single-use ciphers are “theoretically secure information” since encrypted messages do not provide any information about the original message to a cryptanalyst except its maximum possible size. This is a very strong notion of security first developed and mathematically proven during World War II by Claude Shannon, whose results were published in the Bell Laboratories Technical Journal in 1949. The single-use cipher, if used correctly, is secure even if the opponent has infinite computational capacity.
The only way to decrypt the stored data in the Server is by executing a reverse encryption process and inserting the user’s password, referenced as master password. In other words, it is impossible to reveal the encrypted data without the master password.
The difference between this process and the one adopted by the system vault is that the encrypted credentials can only be decrypted if the computer trying to get the credentials has the private key stored in the specified Web Client configuration.
Note: The master password is never stored in the platform and, if forgotten, there is no way to recover the registered credentials. The user has to redefine the master password and all the credentials.
Data at rest
In the system vault, the private key security is under the responsibility of the security systems of the Client’s computer in which the key is stored since this is an uncontrolled environment not managed by IBM Robotic Process Automation. The public key is stored as a string literal in the database.
In the user vault, the public and private key pair is stored in the IBM Robotic Process Automation’s database. The public key is stored as a string literal and the private key is stored with a robust encryption algorithm based on the master password.
Data in use
To protect the user vault’s credentials, the Bot Runtime requests them to the Bot Agent when needed. Then, the Bot Agent makes another request to the Vault system, which prompts the user to open the Vault if it is not opened yet and returns the encrypted master password to the Bot Agent. With this, the Bot Agent now requests to the IBM Robotic Process Automation API the public and private key pair and, after they are returned, they are used to decrypt the master password and get the credential. In the system vault, the private key is obtained using the specified configuration in the Web Client and the public is stored in the Server.
When used in the IBM Robotic Process Automation Studio, both Vaults use a special protected variable type that can only be used by certain commands and does not allow any way to visualize their content.
Data in transit
The data traffic between the IBM Robotic Process Automation Server and the Vault, both user and system vaults, is encrypted using polymorphic algorithms, employing a variety of secure encryption algorithms and OTP.
Data in-memory
To protect the credentials, the Bot Agent and the Vault interface both use the Windows Data Protection resource to secure confidential memory locations. For more information on Windows Data Protection, see the Microsoft documentation.