Protecting credentials with encryption, key wrapping, and separation of duties

We take security very seriously and we invested in a complex set of safeguards to protect your calendar credentials. Access controls and encryption keys are segregated such that no one person or machine has direct access to all the pieces necessary to access or utilize your credentials. Your data is protected against malicious attackers, whether external (who might have gained control over one of the machines) or part of our staff (on the development or operations teams). Multiple coordinated breaches or individuals working together are necessary to compromise the data.

We encrypt all calendar access credentials whether they are passwords or OAuth refresh tokens. Data is encrypted with a AES 256-bit key. At all times, whether in storage or when loaded in memory by the production machines, this AES key is itself encrypted with another RSA 4096-bit key (aka key wrapping). The only moment the AES key is in the clear (unwrapped) is inside the function call that performs the decryption.

FreeBusy is built on Windows Azure cloud services. The wrapped AES key is stored in Azure Storage together with the rest of the user account details. The service runs on machines utilizing the latest Windows Server OS. The wrapping RSA key-pair is packaged as a X.509 certificate and stored in the local machine certificate store provided by the Windows Server OS. The key generation ceremony is local to the production machines and happened on the first deployment such that the wrapping RSA key-pair only exists in the certificate store of the production machines and nowhere else. Access to the RSA key-pair on the production machine is restricted to the application Windows OS service account.

Why this choice for keys and key wrapping?

  • We chose AES to encrypt the actual data because decrypting with symmetric keys (AES) is much faster than with asymmetric keys (RSA)
  • We chose to wrap the AES key with an RSA key (rather than another AES key) because in order to implement separation of duties we need to persist the keys in distinct stores with distinct access control mechanisms. Windows OS already has a store that can persist RSA key-pairs and uses distinct access controls (the certificate store). It's easier and more secure to use the OS' existing infrastructure.
  • We didn't want to have both keys loaded in memory at the same time in case the web server gets hacked from a zero-day vulnerability that enables it to access its memory directly (like Heartbleed). The OS certificate store provides a natural separation. The RSA private key is loaded into the web server process' memory only during decryption and it's securely flushed afterwards.

DevOps staff does not have access to the Windows OS service account and cannot read the RSA key-pair from the local certificate store. DevOps staff also does not have access to the Administrator account on the production machine. The password for the Administrator account is generated randomly at deployment time and then thrown away. If we have problems with a production machine that would necessitate Administrator access to fix, we throw it away and rebuild new one.

For your protection we do NOT backup the RSA or AES keys so as to not create further copies that would have to be secured. This is perhaps they only case known to us where not creating a backup leads to more protection. The only place where both the encryption and and storage access keys exist at rest is in the Azure Management Service and the CEO is the only person who has access to that account. If a catastrophic event were to happen the consequence of losing the keys is small: all users would have to reauthorize FreeBusy (for calendar providers who support OAuth) or re-enter their password. It's a small price to pay for the extra security.

Key Management for Enterprises

Companies who purchase FreeBusy for Enterprise get their own dedicated set of encryptions keys, created and managed using Azure Key Vault, rather than using the general, multi-tenant keys described above. The algorithm for protecting credentials remains the same, however dedicated keys are generated and stored in hardware security modules (HSMs) rather than in Azure Storage. Key operations are done inside the HSMs, which are certified FIPS 140-2 Level 2, allowing the enterprise to audit key usage.