Проверка подписи в Java

Глянув на отрицательный modulus после конвертирования в BigInteger, понял, что он должен быть конвертирован без учета знака. Исправленный вариант для тех, кто будет ковыряться:

1) Создавать числа не через new BigInteger(byte[]), а через new BigInteger(1, byte[])
2) Подпись представляет из себя аргумент функции sign, зашифрованный в режиме RSA/ECB/PKCS1Padding с ключом на токене. Соответственно, обратное преобразование - расшифровать подпись в таком режиме и проверить на совпадение с тем, что передавалось в функцию sign().

Код:

Session tokenSession = token.createSession();
tokenSession.login(pin);
            
TokenObj privKey = tokenSession.findObjects(new AttributeList(new Attribute[]{
    Attribute.CLASS_PRIVATE_KEY, Attribute.PRIVATE_TRUE, Attribute.TOKEN_TRUE,
    new Attribute(PKCS11Constants.CKA_LABEL, ruToken.KEY_LABEL)
}))[0];
            
byte[] signature = privKey.sign(CryptoUtils.sha256(contents), Mechanism.SIGN_RSA);
    
BigInteger modulus = new BigInteger(1, (byte[]) privKey.getAttributeValue(PKCS11Constants.CKA_MODULUS));
BigInteger pubExp  = new BigInteger(1, (byte[]) privKey.getAttributeValue(PKCS11Constants.CKA_PUBLIC_EXPONENT));
        
PublicKey localKey = KeyFactory.getInstance("RSA").generatePublic(new RSAPublicKeySpec(modulus, pubExp));
            
Cipher c = Cipher.getInstance("RSA/ECB/PKCS1Padding");
c.init(Cipher.DECRYPT_MODE, localKey);
System.out.println(Arrays.equals(c.doFinal(signature), CryptoUtils.sha256(contents)));

JCA через sunPKCS11 я не использовал. Проверка подписи через Cipher - оффлайн операция по отношению к токену, и она использует стандартный провайдер JVM. Собственно, ради это все и затевалось - необходимо проверить подпись, сделанную токеном на другой машине, которая токена не имеет. И для этого надо экспортировать публичный ключ в стандартном формате, и проверять при помощи других инструментов. Ибо, как я видел по коду, ваш класс Signature делает ровно то же самое - создает класс MessageDigest, извлекает TokenObj из ключа, который ему дали и в процессе подписи вызывает TokenObj.sign(). Что, кстати, не совместимо с форматом подписи в Signature, ибо там подписывается ASN.1 объект. В этом же приложении надо было расшифровывать RSA через токен. Судя по исходному коду класса Cipher, он умеет только ГОСТ-овые алгоритмы, а через TokenSession.decryptSingle - получилось.

Кроме того, мне не нравится сам принцип построения JCA API, ибо по моим представлением, работа с токеном идет по алгоритму:

1) Нашли все токены в системе
2) По какому-то признаку (серийник, метка, или токен всего один подключен) выбрали нужный
3) Залогинились на токен с PIN-кодом
4) Начали выполнять криптографические операции

Единственное, что более-менее удовлетворяет таким критериям - класс SessionFactory, который описан у вас в документации. Собственно, от него я и начинал изучение внутреннего API и обнаружил, что SessionFactory корнями уходит в JRT11. Остальные же классы - Cipher, Signature, KeyPairGenerator нуждаются, как минимум, в указании PIN-кода каждый раз, а по-хорошему - в задании серийника, чтобы не получилось так, что ты сгенерировал ключ на одном токене, а попытался подписать на другом. И, как я уже сказал, имеются проблемы совместимости. Подпись, сгенерированная вашим классом Signature, только на нем и проверяется, методы SHA256withRSA и SHA256withrtRSA несовместимы. Ключи возвращают null для getEncoded(), и прочие существенные недостатки.