このスレッドを検討してください:
私もよく似た状況です。 USB eToken 5110 JC(Aladdin)を持っていますが、これは主な目的であるため、アクセスできない秘密キーがあります。 pkcs11-tool --module /lib/libeToken.so.9 -l --pin -s -i
を使用できます。 libeToken.so.9は、SAC 9.1(Safenet Authentication Tool)ドライバーによって提供されます。ここまでは順調ですね。
私の問題は、証明書を生成して、このeTokenで署名する必要があることです。 opensslでpkcs11エンジンを使用しようとしましたが、成功しませんでした。たぶん設定ミスが原因です(私は https://github.com/OpenSC/libp11 方法を試しましたが、多くのエラーが発生し、あきらめました)
Gpgを使用しようとしましたが、カードの学習中にエラーが発生しました。
USBトークンから証明書と公開キーを簡単にエクスポートできるので、openssl x509 -force_pubkey
を実行できるので、Valentin Bossiのヒントは良さそうです。これまでのところ正しいですか?
これを行うことの問題は何ですか?署名は、一部のデータのハッシュを生成し、それを秘密鍵で暗号化するプロセスであることを知っています。一部のデータが署名付きで誰かに送信されると、受信者はハッシュアルゴリズムが何であるかを確認し、同じアルゴリズムでデータのハッシュを生成し、送信者の公開鍵で復号化されたハッシュデータと比較します。よろしいですか?
したがって、証明書を生成する場合、データがCSRからのものかstdinからのものかに関係なく、公開鍵を介して作成された署名はデジタル署名を保証しません。
ならどうしよう?何がいけないのですか?
秘密鍵を使用して暗号化されたデータは、公開鍵を使用して復号化でき、その逆も可能です。しかし、同じキーを使用して暗号化と復号化が可能であることを知りませんでした(キーが非対称であるため)。
混乱していると思います。別の問題について言及している質問では、適切な秘密鍵を使用してCSRに署名できないが、このCSRに基づいて証明書を作成することについて言及しています。これは、CSRの署名がCSRの作成者が実際に秘密鍵にアクセスできることを確認するためにのみ使用され、証明書を作成するために秘密鍵は実際には必要ないため、可能です。
代わりに、証明書への署名について尋ねています。これは、CSRへの署名とは異なり、CSRへの署名とは異なる目的を果たします。証明書の署名は、証明書の有効性をチェックするために不可欠であるため、それをスキップしたり、(別の秘密鍵を使用して)偽造したりすることはできません。したがって、秘密鍵に何らかの方法でアクセスすることなく、つまり秘密鍵自体を使用するか、署名に使用できる鍵を含むデバイスを使用することなく、証明書に適切に署名する方法はありません。