如何用Java Security库验证Android端NativeScript生成的ECDSA签名

1. 签名算法与哈希策略的一致性 #

Android Keystore的ECDSA签名算法命名严格，必须和验证端完全匹配，否则会导致验证失败：

• 确认NativeScript中Keystore签名时指定的算法：是SHA256withECDSA（先对消息做SHA256哈希再签名）还是NONEwithECDSA（直接对原始消息字节签名）。注意算法名的大小写和完整格式，Android不支持简写的ECDSA。
• Java后端（BouncyCastle）验证时，必须使用和签名端完全一致的算法。例如签名用SHA256withECDSA，验证时不能用NONEwithECDSA或仅ECDSA，否则会因哈希步骤不匹配导致验证失败。
• TypeScript端的elliptic库默认是对原始消息字节签名/验证，若Keystore用了带哈希的算法（如SHA256withECDSA），TS端需先对消息做SHA256哈希，再传入椭圆曲线验证方法；若用NONEwithECDSA，则直接用原始消息字节验证。

2. 签名格式的兼容性 #

ECDSA签名有两种主流格式：ASN.1/DER编码（Android Keystore默认输出）和紧凑格式（r+s拼接的64字节），跨端格式不匹配是常见问题：

• 检查NativeScript中Keystore签名的输出格式：将签名字节转成十六进制后，判断是否符合DER编码特征（通常开头是30，后续包含r和s的长度标记），还是直接是64字节的紧凑格式。
• Java端用BouncyCastle验证时，若签名是DER格式，需用Signature类直接加载；若为紧凑格式，需手动拆分r和s字段，再通过ECDSASigner类验证。
• TypeScript端elliptic库默认期望紧凑格式签名，若Keystore输出DER格式，需用ASN.1解析工具（如asn1js）提取r和s的大整数，再转成紧凑格式后传入验证方法。

3. 公钥格式与一致性验证 #

确保跨端使用的公钥完全匹配，且格式兼容：

• 确认远程端使用的公钥是从Keystore中导出的版本，而非直接从助记词派生的公钥（虽然理论上一致，但需排除Keystore导入密钥时的格式转换错误）。
• 检查公钥格式：Android Keystore导出的公钥通常是X.509格式（带0x3082...的头部），而elliptic库需要的是去掉头部的非压缩公钥（65字节，以0x04开头）或压缩公钥（33字节）。Java端若用BouncyCastle，需确保公钥的编码格式（如X.509或PKCS#8）与加载方式匹配。

4. 消息处理的一致性 #

针对“十六进制消息”的处理，必须确保各端的解码逻辑完全一致：

• 确认NativeScript中签名时的消息处理：是将十六进制字符串解码为原始字节数组（如"abc123"转成[0xab, 0xc1, 0x23]），还是直接将字符串作为UTF-8字节处理？
• Java和TS端验证时，必须执行完全相同的消息转换步骤：比如同样的十六进制解码方式、相同的字符编码（若涉及字符串转字节）。任何一步差异都会导致消息内容不匹配，验证失败。

5. 确定性ECDSA的参数配置 #

虽然本地验证通过，但需排除Keystore签名的非确定性导致的问题（可能性较低，但值得排查）：

• 检查NativeScript中Keystore生成密钥时的参数：在API 23及以上，需通过KeyGenParameterSpec指定setDigests(DigestAlgorithm.SHA256)并配置ECGenParameterSpec("secp256r1")，确保启用RFC6979标准的确定性ECDSA签名。若未配置，Keystore可能生成非确定性签名，但这通常不影响验证，除非远程端错误假设签名固定。

快速验证技巧 #

• 把NativeScript中生成的签名、公钥、原始消息（十六进制或字节）导出，分别在Java和TS端编写最小化测试用例，直接硬编码这些值进行验证，逐步排查是算法、格式还是消息的问题。

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