将数字签名和签名方公钥存储在JSON文件是否安全？PKCS#7是否更优？

自定义JSON存公钥+签名的方案安全性 #

该方案没有原理性的安全问题，但实际落地时极易出现安全漏洞，生产环境不建议直接使用：

• 公钥可信问题：如果公钥和签名存在同一个JSON文件里，且没有更高层级的可信根校验公钥合法性，攻击者只要篡改JSON里的公钥，就能用自己的私钥伪造签名，整个校验机制完全失效。
• 实现漏洞多：自定义场景下很容易踩字符串编码不一致、字段拼接逻辑缺陷、base64编解码异常等坑，轻则正常签名校验失败，重则出现可被利用的签名伪造漏洞。
• 扩展性差：自定义JSON通常不会存储签名算法、哈希算法的元数据，后续要升级算法（比如从SHA-256换到SHA-3）难度很高，还可能被攻击者利用算法替换漏洞绕过校验。

是否推荐使用PKCS#7 #

除了极简单的内部私有场景、且你能完全掌控所有签名、校验环节的所有实现细节之外，所有生产级场景都推荐使用PKCS#7。

二者的核心差异 #

• 标准化程度：PKCS#7是国际通用的标准格式，跨语言、跨工具都有成熟的原生实现，不需要自行写序列化、反序列化逻辑；自定义JSON格式完全是业务私有定义，只能内部用，跨系统对接成本高，还容易出现不同端实现不一致的问题。
• 安全能力：PKCS#7默认支持携带签名算法元数据、公钥证书、证书链、时间戳，还支持多主体签名、附加原文等能力，所有逻辑都有规范约束，不会出现自定义实现时的安全遗漏；自定义方案的所有扩展能力都要自己开发，很容易留下安全缺口。
• 稳定性：PKCS#7的二进制/PEM格式是标准结构化格式，不会出现JSON字段顺序变化、特殊字符转义、编码不一致等导致的偶发校验失败问题，稳定性远高于自定义方案。
• 适用场景：自定义JSON仅能用于极轻量的内部私有场景；PKCS#7适用于所有生产级签名校验场景，包括需要和第三方对接的公开业务场景。

内容的提问来源于stack exchange，提问作者Sanket Shevkar