安全模型

安全架构是基于把经 Debian a和 The Update Framework 证明的模型集成到 Android 系统已经提供的模型中去。 F-Droid 的运行方式很大程度上受到了 Debian、Fedora、Ubuntu 等知名 GNU/Linux 发行版运作方式的事实安全模型的启发。 我们非常强调在“阳光下运作”并使所有内容都公开可用。 我们发布二进制文件时会包括源代码压缩包和构建日志。 这些内容将尽可能长时间存档,以供回溯审查。 所有这一切被许多不同的团体镜像在互联网上的许多地方。

虽然当前设置已经是一个可靠的平台,但仍有许多改进值得实施:

为了防御持有应用存储库签名密钥的攻击者,必须有一个值得信赖的信息源进行比较。可重复构建意味着具有相同源代码的任何人都将生成完全相同的二进制文件。与审计系统配合使用时,很容易捕获插入构建过程中而不是源代码的恶意软件,如 XCodeGhost。可重复构建还可以让发布二进制文件的所有构建具有完全相同的哈希值。然后,任何应用存储库都可以只从源代码构建应用,并拥有来自构建相同应用的任何其他应用存储库的验证数据源。从源代码构建软件已经变得足够便宜,以至于 gitlab.com 和 Travis CI 等许多公司都在云中提供免费的自动化构建服务。由于整个 F-Droid 工具集是自由软件并且易于设置,因此设置自动审计的障碍非常低。世界上不同地区具有不同风险状况的人们可以运行验证服务器以提供更可靠的信息。

构建服务器设置签名过程 的安全模型分别记录。

应用签名

  • 当构建完全可重复时,可以使用开发者自己的签名分发应用。
  • 默认情况下,“发布”服务器将为每个单独应用生成和管理签名密钥。 要在不同应用间分享签名密钥,必须使用 config.yml 中的 keyaliases机制进行专门配置。
  • 所有应用均由 专用于该应用的密钥 进行签名,除非上游 专门 请求多个应用由同一个密钥签名,且须经 fdroiddata 维护者批准。
  • f-droid.org,所有的应用签名均在专用的、气隙隔离的离线机器上完成。
  • 任何时候,一旦实现了可重复构建,就可以将开发者自己的签名添加到开发者发布于 f-droid.org 的应用。另外,由 f-droid.org 密钥签署的版本将继续分发。
  • 在官方 F-Droid 客户端应用中,新安装默认使用开发者自己的签名。
  • 我们鼓励应用开发人员和维护人员考虑在 f-droid.org 上进行发布时是否要为应用使用特殊的应用程序 ID,以避免与其他版本发生冲突。 一种常见的模式是通过 Gradle Build Flavor 将.fdroid添加到应用程序 ID 的末尾。

初始安装

大多数 F-Droid 的用户从 f-droid.org 下载 APK 并安装它。 这是一个内置应用商店没有的潜在攻击载体。 因此,我们采取了许多额外的安全预防措施,以使其尽可能地难以利用这一载体。

F-Droid 作为内置应用商店

当 F-Droid 内置到 Android 中时,无论是作为 ROM 的一部分,还是通过刷新 OTA 更新,它不再需要启用“未知来源”功能。这是首选的操作方法,因此我们的目标是让用户尽可能轻松地以这种方式运行 F-Droid。刷入 F-Droid 的 OTA 包 特权扩展 具有相同或更低的风险 profile 安装标准的“gapps”包,许多人将其置入到自定义 ROM 上。因此,这种交付方式不会增加这些用户的风险状况。

在此基础上,F-Droid 使其尽可能容易地 构建到 ROM 项目中。 它已经包含在 CalyxOSReplicantLineageOS for microGFairphone Open

防范恶意贡献者产生的数据

应用描述是由各种各样的人提交的,它们也可以从应用的源代码库中获取。 这些数据最终通过 f-droid.org 交付给 Android 客户端或用户的浏览器。

HTTPS/TLS 配置

F-Droid 长久以来支持所有仍在运行的 Android 设备,这意味着尽可能长时间地维护兼容性。 为此,只要运行当前 Android 版本的用户不处于风险之下,我们就仍然支持旧的 TLS 配置。 这是我们的网站仍开启 TLSv1.0 和 TLSv1.1 的原因。 我们相信这不会增加更新软件的用户的风险。一台运行 Android 1.6 系统的设备应该可以安装旧版本的 F-Droid,并有一个基本够用的应用商店。

某些安全扫描器会标记此网站,因其仍支持 TLSv1.1 和 TLSv1.0。 但更重要的是,此网站同样支持 TLSv1.3 和 TLSv1.2,这两者均提供降级保护。 此外,最新的浏览器和 F-Droid 客户端完全禁用 TLSv1.1 和 TLSv1.0,使得攻击者不可能迫使它们使用有漏洞的 TLS 版本。 因此,这些为数不多使用旧的 TLS 版本的连接实际上需要旧的客户端和浏览器版本才能运作。 还在使用 TLS 1.0 或 1.1 的设备上本就存在许多知名的安全漏洞,旧 TLS 版本相比之下也就算不上什么了。

如果你想测试你的浏览器是否仍支持 TLS 1.0 或 1.1,单击下方链接看看是否显示错误信息。

安全审计

  1. 2013年,当时的研究生丹尼尔·麦卡尼(Daniel McCarney)(又名_pd0x_)完成了一个快速、非正式的 安全审计archived)。

  2. 第一个由 开放技术基金 资助的”Bazaar”项目包括来自 Cure53外部公共审计

  3. 由开放技术基金资助的第二个”Bazaar 2”项目包括来自 Radically Open Security外部公共审计

  4. The NLnet 资助的项目”Tracking the Trackers” 和 “The Search for Ethical Apps”提供了由 Radically Open Security 执行的 审计