2

PDF ファイルのデジタル署名を検証する必要があります。
私は使用itextpdfし、cryptopro

cryptopro必要なアルゴリズムに次のエイリアスを提供します。

, JCP: Signature.GOST3411withGOST3410EL -> ru.CryptoPro.JCP.Sign.GostElSign
  aliases: [1.2.643.2.2.3, OID.1.2.643.2.2.3, 1.2.643.2.2.9with1.2.643.2.2.19]

itextpdf「GOST3411withECGOST3410」を取得しようとすると、「そのようなアルゴリズムはありません:プロバイダー JCP の GOST3411withECGOST3410」で失敗します

これは機能します：

Provider prov = Security.getProvider(PROVIDER_NAME);
prov.put("Alg.Alias.Signature.GOST3411withECGOST3410", "GOST3411withGOST3410EL");

それが正しい方法かどうかはわかりません。

Exception in thread "main" ExceptionConverter: java.security.NoSuchAlgorithmException: no such algorithm: GOST3411withECGOST3410 for provider JCP
    at sun.security.jca.GetInstance.getService(GetInstance.java:70)
    at sun.security.jca.GetInstance.getInstance(GetInstance.java:190)
    at java.security.Signature.getInstance(Signature.java:324)
    at com.itextpdf.text.pdf.security.PdfPKCS7.initSignature(PdfPKCS7.java:692)
    at com.itextpdf.text.pdf.security.PdfPKCS7.<init>(PdfPKCS7.java:452)
    at com.itextpdf.text.pdf.AcroFields.verifySignature(AcroFields.java:2349)
    at org.foo.PdfVerifier.verify(PdfVerifier.java:83)
    at org.foo.PdfVerifier.main(PdfVerifier.java:53)
4

1 に答える 1

2

あなたがすることはOKであり、実際には他に選択肢はありません。

しかし、真の問題はitextpdf働き方にあります。これは主要なアルゴリズムの BouncyCastle の名前をハードコードしますECGOST3410が、CryptoPro JCP はGOST3410EL同じアルゴリズムの名前を持っています。これにより、あなたの場合のように、異なるセキュリティ プロバイダーによって生成されたキーを使用するように切り替えることが難しくなります。

ライブラリは、 Key.getAlgorithm()を使用してキーから同じ値を取得できます。これにより、ハードコーディングの必要がなくなり、ライブラリの「セキュリティ プロバイダ依存」が少なくなります。ハードコーディングは、 PdfPKCS7コンストラクターでセキュリティ プロバイダーの選択が可能であることを考慮すると、特に悪い考えです。

于 2014-02-21T11:21:44.033 に答える