如何使用安全的日历协议替代 CalDAV

CalDAV 曾经很好地为我们服务,但其安全和隐私风险意味着现在是时候继续前进了。
99 位读者喜欢这篇文章。
Poll: Upcoming open source conferences

Dafne Cholet。CC BY-SA 2.0。

 

日历技术默认情况下未加密。这意味着您和您的日历通知之间的任何个人或提供商都可以读取并可能存储该信息。数据应该由用户通过使用开源和端到端加密来拥有和保护。

许多人熟悉用于日历的 iCal 格式(.ics 文件)。它是联合协议的罕见成功案例之一,因为不同的供应商在日历格式上达成了相对共识。它也经受住了时间的考验;创建于 1998 年,至今已有 20 多年历史。日历协议一定做得不错。

CalDAV 需要更新

客户端-服务器的故事比较新(只有 13 年历史),但它迫切需要更新。CalDAV,即用于与服务器交换日历信息的协议,基本上是说“通过 WebDAV 获取 iCal 文件”(类似于 FTP)。

CalDAV 的问题与我们使用 IMAP 处理电子邮件的问题相同:用户依赖于他们的服务提供商来保证他们的数据安全。所有互联网访问都需要一定程度的信任。基于信任的安全有其作用,但它不能防止数据泄露:大型提供商积累了如此多的数据,以至于它们已成为网络犯罪分子的有利可图的目标。这是加密必须成为新常态的原因之一。

通过加密日历流量来提高隐私

奇怪的是,许多现代协议都不支持端到端加密。提出的最佳解决方案是自托管日历服务。自托管肯定有优势;但是,运行日历系统并保持其在线状态并非易事。即使使用自托管,您的数据仍然不是私有的,因为您的域名托管提供商可以访问您的数据。因此,许多人选择了阻力最小的路径并选择了免费提供商。然而,这些提供商不加密信息,并且经常将用户数据货币化。

为了充分利用共享托管的优势和成本节约,同时保护用户隐私,我们必须加密。如果我们可以加密整个邮箱,为什么不能加密日历呢?

设计加密日历服务

端到端加密带来了一系列独特的挑战。在 Tutanota,我们开发 加密日历 的主要目标是我们的服务器绝不能知道您的事件何时、何地或与谁发生,但您仍然必须能够接收警报并与其他用户共享您的日历。

加密数据——事件的什么、地点和与谁相关的信息——相对容易。然而,许多此类数据是在警报中发送的,并通过通知传递给用户,这可能会泄漏重要信息。这就是为什么我们还需要加密警报并对我们的服务器隐藏事件时间。

加密警报的挑战在于,即使在没有用户密码来解密它们的情况下,警报也必须可用。最简单的解决方案是在用户创建警报的设备上本地安排警报。但是云服务设置了用户的期望:如果您在桌面上设置了警报,您会希望在移动应用程序中收到它。为了成为主流云日历的可行替代方案,我们需要一种用于私有警报的解决方案。

这可以使用消息传递服务来完成。大多数应用程序在这种情况下都使用云服务,但这可能会特别麻烦:当服务使用专有的推送工具时,服务不仅可以看到通知中的所有信息,还可以存储它并将其用于其他目的。为了保持日历完全私密,我们需要一种保证隐私的替代方案。经过大量的研究和考虑,我们构建了自己的 开源通知服务

虽然使用未加密的警报会容易得多,但我们决定调整这个安全的日历系统,使其适用于警报。从一开始就将安全和隐私融入代码中,用户仍然可以完全控制他们的数据。

通知加密的工作原理

解决方案如下:我们仅针对此设备加密部分事件信息,而不会冒着将日历密钥存储在设备上的风险。我们用于电子邮件的通知系统已经包含了处理不同设备的机制,具有每个设备的加密密钥,并且可以处理错过的更新。

那么,当用户设置警报时会发生什么?警报详细信息针对每个设备进行加密,并向每个设备发送静默通知。由于不同的设备之间已经有了共享密钥(即,登录用户可以使用其他设备密钥,但后台设备不能使用),我们可以使用对称加密 (AES) 来安全有效地加密警报的更新。

设备要么立即接收到它,要么在上线时获取通知。用户不会注意到这个过程。如果设备密钥被泄露,攻击者仍然无法解密日历的其余部分,这大大限制了潜在攻击的影响。用户可以随时更换或撤销设备密钥,因此不会再使用旧密钥加密任何信息。

设备使用其设备加密密钥存储警报,并在设备上本地安排警报。这样,当警报在用户的设备上弹出时,我们的服务器不会参与其中。因此,我们对用户的日历事件完全一无所知。

事件加密的工作原理

日历事件的所有详细信息都使用日历密钥加密,这意味着只有创建日历的人(以及与其共享日历的人)才能访问它。加密链看起来像这样

user key –> calendar key –> calendar event session key –> field of the calendar

当共享日历时,日历密钥使用接收者的公钥加密并放入邀请中。接受邀请后,非对称加密不再用于日历,因为用户现在在他们之间共享了一个秘密:日历密钥。这样,本着端到端加密的最佳精神,我们在仍然促进共享和协作的同时,对日历的内容完全不知情。

项目的状态

目前,我们的客户端是完全开源的。但是,您需要服务器实现来存储数据。Tutanota 服务器软件目前尚未发布,因为在没有用于加密的联邦协议之前拥有多个服务器是没有意义的,并且我们希望首先解决后量子加密问题。

Tutanota 使用加密层。例如,crypto 目录中有一些加密。那里的函数遍历数据类型的描述并将其转换为加密对象。例如,这是 日历事件 的一个。

还有用于 Android 的本机部分,用于解密警报(例如,在 alarms/AlarmInfo.java 中)和用于 iOS 的本机代码(在 Sources/Alarms/TUTAlarmNotification.m 中)。

您可以调整 Tutanota 客户端以用于自定义服务器,或者您可以只查看加密代码以了解它是如何实现的。如果您不倾向于拼凑自己的系统,Tutanota.com 可以作为服务使用。

隐私是一项权利

我们认为 CalDAV 已经完成了它的使命。现在是时候用支持加密以及端到端加密警报的东西来取代它了。构成 Tutanota 的开源组件证明了这是可能的。我们认为 iCal 仍然是“离线”交换的良好文件格式,Tutanota 日历支持使用它进行导入和导出。

端到端加密没有被广泛使用——不是因为它无法实现——而是因为它不符合大玩家的利益。我们认为隐私是开源用户关心的一项权利,Tutanota 的日历旨在让我们实现这一目标。保持安全。

Ivan, Developer at Tutanota
Ivan 对开源和隐私充满热情。他是加密电子邮件服务 Tutanota 的开发人员之一。目标是构建一个安全的开源电子邮件替代方案来替代 Gmail。“我一直都知道政府在监视人们,但在某个时候我才意识到公司追踪我们的一举一动有多么厉害。

贡献者

评论已关闭。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.