Automatically Secure Code Signing Assets

The problem. As I wrote previously in “Bring Customers Joy With Automation”, we were faced with the challenge of safely securing the customer’s signing assets in an automated way. At this stage, we still had to manually process the data provided from the Appian Provisioner. We wanted to improve our process to make sure that there was no chance that we could see the passwords for our customers’ keychains. Remember, the keychain contains a certificate and a private key that can be used to code-sign a mobile application to prove to users that the application was made by the company and was not modified by someone who may want to harm the company or its users. The Appian Provisioner application encrypts this data before it is ever sent to us. We needed to secure the data sent to us from the Appian Provisioner in such a way that Appian employees were only allowed to store the customer’s data without being able to read it. We also had to make sure that only the build machines could read and decrypt the customer’s credentials in order to code-sign their custom mobile applications. The solution. Appian uses Hashicorp Vault to store this kind of data. Vault is a server that secures, stores, and tightly controls access to tokens, passwords, certificates, and encryption keys for protecting secrets and other sensitive data using a website UI, command line interface, or HTTP API endpoints. To ensure that each entity had the correct permissions, we decided to use Vault’s policies and token roles. A Vault policy allows you to configure authorization access to create, update, read, list, and delete secrets. Policies can be associated with users or groups. A Vault token role allows you to provide a token to another user to take on a role that uses a given policy. For example, there may exist a token role that is tied to a policy that allows a token-holder to read a particular secret. I may not be able to read that secret, but I could create a token that allows you to login on your computer and read that secret without allowing me to do the same. So, that’s what we did. We created two distinct policies: one that allowed us to write — and only write — customer data, and the other that allowed an automated system to read — and only read — customer data. We also secured the method of decrypting the customer’s passwords. I’ll guide you on how to do each of these things so that you too can use this Vault functionality to secure your own sensitive data. Vault setup. To get the most out of this article, I suggest that you set up an instance of Vault as explained in the article Docker compose — Hashicorp’s Vault and Consul Part A. For this example, you can stop after you’ve unsealed Vault (before auditing is enabled). Once you set up your own debug instance of Vault, if you haven’t already, run this command inside of your Vault container: vault kv enable-versioning secret This will allow you to store multiple versions of secrets. If you make a mistake, you can simply revert back to an older version of the secret. Encryption keys. As I wrote above, the Appian Provisioner encrypts the customer’s keychain password and APNS key, and we needed our build system to decrypt this data. To do this, we used a public and private key pair to encrypt and decrypt the data. I used the article Encrypt and decrypt files to public keys via the OpenSSL Command Line as a reference to create the following script that creates a OpenSSL private key and public key in order to perform Public-key encryption.