浅谈YSM多人联机下的模型安全

看到最近很多人在讨论 YSM 的安全措施有感，在这里写一篇短文浅谈这个问题。

首先，这个问题是客观存在且无法解决的，解决模型安全根本就是不现实的。我整理了几个社区内常被提及的解决方案，并逐一说明为什么它们行不通。

提前加密模型，服主只能拿到加密后的模型

如果客户端能解密，那么服主同样能解密。因为客户端要渲染，最终就必须拿到明文的模型，那服主只要在服务端内置一份客户端的解密逻辑，就能解密。毕竟只要是开源的，把这套逻辑移植过去并不是什么难题；就算闭源，也会有人把它逆向出来。

提前把模型渲染好再发送

是的，这就是 YSM 现在采用的方案。但它仍然可以被 YSMParser 反渲染算法直接恢复成 Blockbench 工程。

使用签名 + 在线验证，而非加密

来源：https://github.com/YesSteveModel/YSM-Wiki-Issues/issues/407

原文：

首先，应弃用 .ysm 格式。应创建一个新格式，内部包含：

    模型本身。此模型本身可以被直接还原为 blockbench 等可以编辑的格式，并且可读（也即不做加密）。
    对前一个数据的摘要的 非对称加密 签名。

在加载（启用）模型时，mod 将进行：

    从文件中读取该模型，并进行摘要运算。
    使用该摘要向服务器进行查询请求。该查询请求将返回模型作者的公钥、元数据（如是否允许在网易上运行，授权的账号的uuid，是否允许非正版登录用户使用）等。
    （如果查询失败）显示该模型尚未被发布，提示用户可能下载到盗版模型。
    （如果查询成功）使用公钥解密（验证）签名。将解密结果跟 (1) 中的结果进行对比。如果不一致，显示该模型被篡改，提示用户可能下载到盗版模型并提供原作者的联系方式、正版下载链接等（包含在元数据中）。
    根据元数据的限制对环境进行检查。如果不通过，显示不满足模型使用要求，并（同上）。
    最终允许进行加载。

同时，添加一个开启需要 多次确认 的 开发者模式，在开发者模式下将跳过上述过程。可以为开发者模式添加限制，如在多人模式时 不允许 未开启开发者模式的用户看到开启开发者模式的用户的皮肤（用于防止有提示打开开发者模式，因为不是所有人都会开）。

注意，在请求服务器时需要使用 https + 自己的证书公钥而不信任系统证书，以防止 hosts / 代理攻击。

本系统提出的 关键 目的就是 允许导出，允许修改，但限制再分发。这是最大限度符合 Remix Culture 的，不需要防止。

这个方案看着很完备，却忽略了一个关键问题：倒狗根本不会去修改模型，也不会擦除版权信息，甚至懒得看你的模型，往往直接拿你的名字来给模型分类命名。 而真要二次分发，他只需把模型重新签名一次，既然模型本身允许被还原成 Blockbench 这类可编辑格式，那重新签名后照样验证通过、允许加载。换句话说，这套机制解决不了任何问题，甚至不用https、hosts什么的都可以绕过。

使用端对端加密（Telegram模式）

RSA 密钥分为公钥和私钥：公钥用于加密，对应的私钥用于解密。基于这一点，方案的逻辑大致是：

每个客户端各自生成一对 RSA 密钥，私钥始终只保存在本机；
进入服务器后，客户端把自己的公钥上报给服务器；
更换模型时，发送方先获取场景内所有目标玩家的公钥，用对方的公钥分别加密模型，再把密文通过服务端中转给对应玩家；
目标玩家收到密文后，用自己的私钥解密。

乍看很有道理，服务端似乎根本没机会接触明文模型。但这个方案存在一个巨大的问题：服务器完全可以给你下发假的公钥，而它自己持有这假公钥对应的私钥。你的客户端用假公钥加密后，服务器就能用对应的私钥直接解出明文。 这就是典型的中间人攻击，整套端对端加密在不可信的服务器面前形同虚设。

要堵住这个漏洞，就得引入一个中心化的密钥交换/验证服务器来确保公钥的真实性。可这成本更高：不仅要保证全球范围内的连接可用性，还得有一个真正可信的第三方团体来维护，一旦它分发假公钥，泄露风险依旧存在。更现实的问题是，这套方案对服主几乎没有任何好处：带宽消耗更高，同时还让服主失去了对模型的监管权。所以即便真的把它实现出来，服主也没有理由采用。

真正的威胁

很多人误解了一点：真正的威胁其实来自服务器里的其他玩家。只要你的模型需要被渲染，它就必须被发送到其他玩家的客户端上。尽管YSM发送的是已渲染的模型、本地cache也做了加密，但这些数据依然是可逆向、可还原的。也就是说，即便服主完全可信，服务器里的其他玩家也未必可信，他们只需要解开本地缓存即可获得明文的模型。