iOS端EC私钥签名数据无法在Java端通过Signature.verify()验证

遇到这种跨平台签名验证不通过的问题，大概率是两端的流程细节没对齐，我帮你梳理几个最可能的遗漏点，按优先级排查：

1. 最容易踩坑：哈希重复计算 #

你提到iOS端先把nonce转成NSData，生成SHA256摘要，再用kSecPaddingPKCS1SHA256签名——这里有个关键误区：kSecPaddingPKCS1SHA256这个填充模式已经包含了SHA256哈希的步骤！

也就是说，如果你自己先算了SHA256，再传给SecKeyRawSign，实际签名的是SHA256(SHA256(nonce))，而Java端的SHA256withECDSA只会对nonce做一次SHA256哈希，两边的哈希值完全不一样，验证肯定失败。

解决方法：iOS端直接传入nonce的原始NSData，不要提前计算哈希，让SecKeyRawSign自动处理哈希和填充：

// 错误示例：提前计算SHA256
// NSData *hashData = [self sha256FromData:nonceData];
// OSStatus status = SecKeyRawSign(privateKey, kSecPaddingPKCS1SHA256, hashData.bytes, hashData.length, sigBytes, &sigLength);

// 正确示例：直接传入原始nonce数据
OSStatus status = SecKeyRawSign(privateKey, kSecPaddingPKCS1SHA256, nonceData.bytes, nonceData.length, sigBytes, &sigLength);

2. 字节序不一致导致nonce数据不匹配 #

64位整数转字节数组时，iOS默认是小端字节序（因为苹果设备是小端架构），而Java的ByteBuffer默认是大端字节序，这会导致两边的nonce字节数组完全不同，哈希结果自然对不上。

解决方法：统一使用大端字节序（网络字节序）：

• iOS端转换时：

  uint64_t nonce = 你的64位随机数;
  uint64_t bigEndianNonce = CFSwapInt64HostToBig(nonce);
  NSData *nonceData = [NSData dataWithBytes:&bigEndianNonce length:sizeof(bigEndianNonce)];
  

• Java端转换时：

  long nonce = 收到的64位随机数;
  byte[] nonceBytes = ByteBuffer.allocate(8)
                                .order(ByteOrder.BIG_ENDIAN)
                                .putLong(nonce)
                                .array();
  

3. 签名格式不兼容（P1363 vs ASN.1 DER） #

iOS的SecKeyRawSign使用kSecPaddingPKCS1SHA256返回的签名是P1363格式：即32字节的r值直接拼接32字节的s值，总共64字节。而Java的SHA256withECDSA默认期望的是ASN.1 DER编码格式的签名（结构是SEQUENCE包含两个INTEGER：r和s，长度通常是70-72字节左右）。

如果你的iOS签名是64字节，那肯定是P1363格式，需要转成ASN.1格式才能被Java验证。

Java端转换代码示例：

import org.bouncycastle.asn1.ASN1Integer;
import org.bouncycastle.asn1.DERSequenceGenerator;
import java.io.ByteArrayOutputStream;
import java.util.Arrays;

public static byte[] convertP1363ToASN1(byte[] p1363Signature) throws Exception {
    if (p1363Signature.length != 64) {
        throw new IllegalArgumentException("P1363签名必须是64字节");
    }
    // 拆分r和s
    byte[] r = Arrays.copyOfRange(p1363Signature, 0, 32);
    byte[] s = Arrays.copyOfRange(p1363Signature, 32, 64);
    
    // 调整ASN.1整数格式：如果最高位是1，需要加0x00前缀避免被解析为负数
    r = adjustASN1Integer(r);
    s = adjustASN1Integer(s);
    
    // 构建ASN.1 SEQUENCE结构
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    DERSequenceGenerator seqGen = new DERSequenceGenerator(baos);
    seqGen.addObject(new ASN1Integer(new BigInteger(1, r)));
    seqGen.addObject(new ASN1Integer(new BigInteger(1, s)));
    seqGen.close();
    return baos.toByteArray();
}

private static byte[] adjustASN1Integer(byte[] data) {
    if ((data[0] & 0x80) == 0) {
        return data;
    }
    byte[] adjusted = new byte[data.length + 1];
    adjusted[0] = 0x00;
    System.arraycopy(data, 0, adjusted, 1, data.length);
    return adjusted;
}

验证时先用这个方法转换签名，再传给signature.verify()。

4. 公钥格式与曲线参数不匹配 #

确保Java端解析的X509公钥是正确的EC公钥，并且曲线参数和iOS端一致（比如都是secp256r1/prime256v1）。你可以在Java端打印公钥信息确认：

PublicKey publicKey = KeyFactory.getInstance("EC")
                                .generatePublic(new X509EncodedKeySpec(x509PublicKeyBytes));
ECPublicKey ecPk = (ECPublicKey) publicKey;
System.out.println("曲线名称：" + ecPk.getParams().getName());

如果输出不是secp256r1或者prime256v1，说明公钥解析有问题，或者两端使用的曲线不一致。

排查顺序建议 #

优先检查第1点（哈希重复），这是最常见的错误；然后检查第2点（字节序）；再验证签名格式；最后确认公钥参数。按这个顺序排查，大概率能解决问题。

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