Calendar Credentials and Access Authorization

When you Sign In With Your Calendar you authorize FreeBusy to access one or more online calendars that you own, whenever someone checks your availability. Depending on your calendar provider this authorization uses OAUTH or a password. If your calendar allows only password-based authorization, FreeBusy needs to save your password.

Calendar Provider Requires saving your password
Google CalendarNo
G SuiteNo
Office 365No
Outlook.comNo
HotmailNo
FruuxNo
Microsoft ExchangeNo if signing up entire organization,
Yes if signing up individual accounts
WorkMailNo if signing up entire organization,
Yes if signing up individual accounts
Apple iCloudYes
Yahoo! MailYes
KerioYes
ZimbraYes
ZohoYes
SabreDavYes
OwnCloudYes

Rest assured that for calendars where we need to save the password we take extra precautions to encrypt your password and not make it directly accessible to FreeBusy staff. All data is encrypted both in transit and at rest using high-grade industry-standard security with the utmost care for your privacy.

FreeBusy is committed to Enterprise security

We take security very seriously and we invest in a complex set of safeguards to protect your calendar credentials and calendar data. FreeBusy staff does not have access to your calendar data. In addition to data encryption in transit and at rest, when you purchase Enterprise or Dedicated plan you can request compliance audits for a variety of assurance programs, including:

compliance CSA compliance SOC 1 compliance SOC 2 compliance Privacy Shield compliance EU Model Clauses


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

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. 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.