Calendar technology is not encrypted by default. That means any individual or provider between you and your calendar notifications can read and potentially store that information. Data deserves to be owned and secured by users through the use of open source paired with end-to-end encryption.
Many people are familiar with the iCal format (.ics files) for calendaring. It is one of the rare success stories of federated protocols, as different vendors achieved relative consensus on the calendaring format. It's also stood the test of time; created in 1998, it is now more than 20 years old. The calendar protocol must be doing something right.
CalDAV needs an update
The client-server story is newer (only 13 years old), but it is in dire need of an update. CalDAV, the protocol for exchanging calendar info with a server, basically says "fetch iCal files via WebDAV" (which is similar to FTP).
The problem with CalDAV is the same problem we have with IMAP for email: Users depend on their service providers to keep their data safe. All internet access requires some level of trust. Security by trust has its place, but it doesn't protect against data breaches: Big providers have accumulated so much data that they have become lucrative targets for cybercriminals. This is one reason encryption must become the new normal.
Increasing privacy by encrypting calendar traffic
Oddly enough, a lot of modern protocols don't support end-to-end encryption. The best solution proposed is self-hosting a calendar service. Self-hosting definitely has advantages; however, it is no small task to run a calendar system and keep it online. And even with self-hosting, your data is still not private because your domain-hosting provider can access your data. Thus, many people take the path of least resistance and choose free providers. These providers, however, do not encrypt information and often monetize user data.
To rip all the advantages and cost savings of shared hosting and preserve user privacy at the same time, we must encrypt. If we can encrypt the entire mailbox, why can't we encrypt calendars?
Designing an encrypted calendar service
End-to-end encryption comes with a unique set of challenges. At Tutanota, our main goal in developing our encrypted calendar was that our server must not know when, where, or with whom your events are taking place, yet you must still be able to receive alarms and share your calendars with other users.
Encrypting the data—the what, where, and with whom events are taking place—is relatively easy. However, a lot of this data is sent in an alarm and delivered to users via notifications, which can leak important information. That's why we also needed to encrypt alarms and hide times of events from our servers.
The challenge with encrypting alarms is that alarms must be available even when there's no user password to decrypt them. The easiest solution would have been to schedule alarms locally on the device where the user created the alarm. But cloud services set users' expectations: If you set an alarm on your desktop, you would expect to receive it in the mobile app. To become a viable alternative to mainstream cloud calendars, we needed a solution for private alarms.
This can be done with a messaging service. Most applications use a cloud service in this case, but that can be particularly troublesome: When services use proprietary push tools, not only can the service see all the information in the notification, but it can also store it and use it for other purposes. To keep the calendar completely private, we needed an alternative that guaranteed privacy. After much research and consideration, we built our own open source notification service.
While using non-encrypted alarms would have been much easier, we decided to adapt this secure calendaring system to make it work for alarms. With security and privacy baked into the code from the start, users remain completely in control over their data.
How notification encryption works
The solution looks like this: We encrypt part of the event information just for this device without risking storing the calendar key on the device. The notification system we use for email already includes mechanisms for handling different devices, has encryption keys per device, and can handle missed updates.
So, what happens when a user sets up an alarm? Alarm details are encrypted for each device, and a silent notification is sent to each device. Because different devices already have a shared secret between them (i.e., other device keys are available to the logged-in user but not to the device in the background), we can use symmetric encryption (AES) to securely and efficiently encrypt updates of alarms.
Devices either receive it immediately or fetch notifications when they come online. The user doesn't notice this process. If the device key is compromised, the attacker still can't decrypt the rest of the calendar, which greatly limits the impact of a potential attack. Users can replace or revoke device keys at any moment, so no further information will be encrypted with the old key.
The devices store the alarms using their device encryption key and schedule alarms locally on the device. This way, our server is not involved when the alarm pops up on the user's device. As a consequence, we remain completely blind to users' calendar events.
How event encryption works
All the details of the calendar events are encrypted with the calendar key, which means that only the person who created the calendar (and those it was shared with) can access it. The encryption chain looks like this:
user key –> calendar key –> calendar event session key –> field of the calendarWhen a calendar is shared, the calendar key is encrypted with the recipient's public key and put into the invitation. After the invitation is accepted, asymmetric encryption is not used anymore for the calendar because users now have a shared secret between them: the calendar key. This way, in the best spirit of end-to-end encryption, we stay completely oblivious to the calendar's contents while still facilitating sharing and collaboration.
The project's status
Currently, our client is fully open source. However, you need a server implementation for storing the data. The Tutanota server software is not currently published because it doesn't make sense to have multiple servers until there's a federation protocol for encryption, and we want to solve post-quantum encryption first.
Tutanota uses a layer of encryption. For instance, there's some encryption in the crypto directory. The functions there walk the description of a data type and transform it into an encrypted object. For example, here's one for a calendar event.
There are also native parts for Android that decrypt alarms (e.g., in alarms/AlarmInfo.java) and native code for iOS (in Sources/Alarms/TUTAlarmNotification.m).
You can adapt the Tutanota client for a custom server, or you can just review the encryption code to see how it's implemented. If you're not inclined to hack together your own system, Tutanota.com is available as a service.
Privacy is a right
We believe CalDAV has served its purpose. Now it is time to replace it with something that supports encryption as well as end-to-end encrypted alarms. The open source components that make up Tutanota prove that this is possible. We think that iCal is still a good file format for "offline" exchange, and the Tutanota calendar supports import and export with it.
End-to-end encryption is not used widely—not because it cannot be implemented—because it's not in the interest of big players. We believe that privacy is a right that open source users care about, and Tutanota's calendar is designed to get us there. Stay secure out there.
Comments are closed.