JavaCard小程序烧录后代码完整性验证方案咨询

针对你遇到的问题——分发商烧录小程序后无法验证完整性，客户拿到卡片后能确认代码未被篡改，以下是几个可落地的方案：

1. 基于GlobalPlatform安全域的签名绑定 #

GlobalPlatformPro的--dap-sign虽已废弃，但可以遵循GP规范的发卡域（CID）签名机制实现：

• 你生成一套RSA/ECC签名密钥对，将公钥预先注入卡片的发卡安全域（ISD）或专门创建的验证安全域（SD），这个操作只能由卡片的主控密钥持有者完成，分发商无权修改。
• 你对编译好的.cap文件计算SHA-256哈希，用私钥签名该哈希值，将签名交付分发商，要求他们在安装小程序时，将签名写入ISD下的受保护专用文件（EF），该文件仅ISD有权限修改。
• 客户验证流程：通过自定义APDU命令让小程序在卡片内部计算自身代码的哈希值（而非读取静态存储值），同时读取ISD中存储的签名，用你的公钥验证哈希与签名是否匹配。分发商若篡改小程序，卡片计算的哈希会变化，签名验证直接失败。

2. 小程序内置自验证逻辑 #

核心是利用JavaCard代码段的只读特性，避免静态数据被篡改：

• 将你的公钥硬编码到小程序的只读代码段（JavaCard中static final类型的密钥数据会被放入只读区域，烧录后无法修改）。
• 在小程序中实现一个自定义APDU命令，功能是遍历自身的代码空间，计算SHA-256哈希值，并返回该哈希值以及你预先用私钥签名好的原始.cap文件哈希签名（签名同样嵌入只读代码段）。
• 客户验证时，发送该APDU命令获取哈希和签名，用公钥验证签名是否对应卡片实时计算的哈希。分发商若篡改小程序代码，卡片计算的哈希会和签名绑定的原始哈希不符，验证不通过。

3. 第三方CA签名验证 #

如果对安全性要求极高，可借助可信JavaCard CA：

• 提交你的.cap文件给CA，由CA对其进行签名，生成带CA签名的小程序安装包。
• 要求分发商必须安装带CA签名的包，同时卡片的ISD预先配置信任该CA的公钥。
• 客户验证时，通过GP标准命令触发卡片对小程序的签名验证，卡片会自动校验签名是否来自信任CA，并返回验证结果。此方案依赖CA的公信力，适合合规要求严格的场景。

补充：为什么你的初始思路存在漏洞 #

你之前想的“将哈希和签名存入小程序”的问题在于，如果存储在可修改的数据区，分发商可轻易篡改这些值；但如果将签名嵌入只读代码段，或者让卡片实时计算哈希而非读取静态值，就能从根本上避免篡改风险。

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