KeyMeld：适用于iPhone和Android的通用密钥以及Zero Vault架构方案

跨平台应用面临一个用户通常未注意到的问题。在屏幕上显示的是同一账户，用户期望在任何设备上都能获得相似的体验，但在iPhone和Android内部，保护机制不同，处理本地密钥的方式也不同。

在iPhone上，应用可以通过Apple Keychain保护本地密钥。而在Android上，则使用Android Keystore。它们的技术都旨在将敏感密钥保持在设备的安全环境中，但不能互换。

对用户而言，这并无关紧要。他只希望在iPhone上打开应用，随后在Android上安装，继续使用相同的受保护数据。

而对开发者来说，这引出了架构上的问题：如何在不转移本地设备密钥，也不将其副本存储在自己后台数据库中的情况下，实现两个平台的通用访问？

分析KeyMeld时，我发现该服务为此提供了一个独立的通用密钥，既不干涉iOS也不干涉Android的内部保护机制。

跨平台的通用密钥

本地设备密钥属于特定的手机，由相应操作系统的安全机制保护。它始终存储在设备的受保护环境中，不适合自由跨设备传输。

KeyMeld的通用密钥是另一种实体。它是为特定项目、账户和保护空间创建的，成为不同平台已授权客户端的共用密钥。

该服务不会读取iPhone中的密钥，也不会将其转移到Android，也不试图将两个不同的密钥合二为一。平台的保护机制保持独立，应用程序获得的是针对自己项目的统一访问级别。

这正是KeyMeld架构的核心作用：它不让iOS和Android变得相同，也不取代它们的内部机制，而是通过增加一个通用级别的密钥，提高项目的跨平台操作能力，从而免除开发者自行处理跨平台密钥调配的复杂性。

为不同的产品和账户建立了独立的密钥空间。因此每个项目维护自己的访问范围，即使在同一设备上的多个账户也能保持隔离。

Zero Vault归属于项目

需要明确的是：Zero Vault并非KeyMeld的名称，而是一种架构模型，由接入的产品自行构建。

KeyMeld作为一个独立的SaaS服务运行。其不会嵌入到应用后台，也不以额外模块的方式存放在项目数据库旁边。通用密钥由一个独立的KeyMeld云端容器进行管理，位于产品后台之外。

为了确保这种模型的持续性，项目与KeyMeld之间的信任边界必须保持独立。后台与外部服务使用不同的认证信息、访问权限和管理机制。

可以将这样的架构称为Zero Vault：其服务器端数据库不存储来自客户端的受保护存储密钥。

Zero Vault并不意味着应用后台完全不存储任何信息。它依然存放账户信息、设置、业务数据及应用运行所需的全部内容，但没有通用密钥的存放位置。

即使后台数据库被攻破，也不会直接泄露通用密钥：因为它未存放于数据库中，同时该模型也不能保证系统的任何部分完全免受故障影响。其核心目标是：将通用密钥从客户端存储中剥离出来，不存放在应用的数据库中。

实际场景：一个账户在iPhone和Android上的使用

设想一个包含本地受保护数据的应用。比如一个身份验证应用、企业客户端或任何需要在设备上直接处理加密信息的服务。

在iPhone上，应用通过iOS机制保护本地密钥，而在Android上，则采用Android自有的保护机制。两个平台的本机密钥不同，这是正常的。

无需额外的公共层，开发者如果要实现两个平台对同一受保护数据的访问，通常会面临设计难题：要么在不同平台上分别存储密钥，要么手动传输或在服务器端保存密钥的副本。

KeyMeld允许免于本地密钥跨设备转移或存储副本，通过引入通用密钥来解决问题。

iPhone客户端和Android客户端都能访问同一通用密钥，只要它们在同一项目和账户授权范围内。同时，两个设备还能独立使用自己的保护机制进行密钥保护。

用户会感受到在不同设备上的账号是统一的，不需要关心内部使用的具体保护技术。当更换设备时，不需要导出旧设备的本地密钥，也不必为新平台专门创建受保护存储。新设备只需连接到同一项目，即可获得相同的通用密钥。

后台负责验证请求，但通用密钥由已授权的客户获取，不会存放在应用的服务器端数据库中。

KeyMeld本身不会迁移应用的数据库，也不代替用户记录的同步机制。它的核心任务是提供给客户端所需的访问密钥，存储内容和更新维护由应用自行负责。

三种不同类型的密钥和秘密

为了区分架构中的不同部分，可以理解以下三种概念：

• 设备本地密钥，属于具体设备，由iOS或Android保护机制维护管理。

• 通用密钥，由一个项目和账户的授权客户端共同使用，它在产品层面连接不同平台。

• 系统秘密，后台用以与KeyMeld安全交互的秘密。不会传递给移动端或浏览器。

系统秘密和通用密钥具有不同的用途。在Zero Vault架构中，通用密钥不会存放在应用的数据库中，也不与后台数据一起存储。

KeyMeld不需要用户姓名、密码、TOTP存储内容或业务记录的具体信息。服务端只关心项目、账户以及客户获得通用密钥的权限绑定关系。

访问控制保持可控

获得通用密钥并非任何客户的自动权利。

如果设备不再被信任、账户状态发生变化，或管理方撤销了项目访问权限，KeyMeld可以停止向该客户提供通用密钥。

这里很重要的一点是，不意味着会立即销毁已有的本地密钥副本。它主要控制密钥的后续发放以及新客户端的接入权限，确保权限动态管理。

对用户而言，这意味着新增设备的接入与管理密钥访问权属于同一体系。

对开发者而言，这样就不用再为iOS和Android单独实现类似逻辑。而整体Zero Vault架构，核心仍依赖项目是否存储了通用密钥，以及是否维护了基础设施和KeyMeld云端之间的隔离。

KeyMeld不做什么

KeyMeld不是密码管理器，也不存储用户的TOTP记录。它不是应用内容的云端数据库，也不会替代内容同步机制。

它不是Apple Keychain或Android Keystore的替代品。服务只在平台本地机制基础上提供了一层公共接口，增强整体安全性和便利性。

它也不是用户身份验证的唯一服务。身份验证和授权可以由其他服务（如MeldID）处理；KeyMeld的任务是为已授权客户提供一个统一的通用密钥，而不将其存放在应用程序的后台中。

最后，KeyMeld不会自动实现Zero Vault。它提供一个外部的通用密钥架构。为了维护这种架构，开发者不应将通用密钥存放在自己服务器的数据库中，而是保持与外部云服务的分离和信任区隔。

潜在适用场景

这套方案适用于多平台、多设备且涉及本地保护数据的应用。例如身份验证器、企业应用、SaaS、多个设备同步的服务或任何需要在iPhone和Android上都能一致使用账户的项目。

对开发者而言，不仅可以降低平台逻辑复杂度，更能明确责任分工：应用后台只存业务数据，而KeyMeld作为外部SaaS服务，提供通用密钥及其后续管理。

经过深入了解，我会将KeyMeld视为一种工具，帮助开发者为自己的产品搭建Zero Vault架构，而非现成的解决方案。

iOS和Android依旧使用各自的保护机制，客户统一通过通用密钥管理。只要后台没有存储该密钥，也确保了基础设施与云端的隔离，就不构成安全隐患。

用户体验上，用户在不同平台上的账户访问保持一致。开发者可以将通用密钥迁出自己的后台。整个项目的架构也因此成为Zero Vault：后端不存储客户数据的密钥。

详细介绍： KeyMeld