デジタル署名は、単純なドキュメント、コード、電子メールの署名について話している場合でも、今日の暗号通貨やブロックチェーンで見られるようなより高度な暗号化の実装について話している場合でも、オンラインビジネスの未来です。
Digital Logic Ltd.は、非接触RFIDカードを使用したデジタル署名ソリューションを実装した世界で最初の企業の1つです。
連絡先カードを使用している古いシステムは、すぐに過去のものになると予想しています。
μFR署名者は、ファイルにデジタル署名するためのRSAとECDSAの両方の暗号化アルゴリズムをサポートしています。
ソフトウェアは、当社のμFRシリーズのNFCデバイス(ナノ、クラシック、クラシックCS、アドバンス)での使用を目的としています。
μFR署名者は、RSAおよびECDSAをサポートするすべてのカードで動作します。 デモ動画では、JCOPカードJ3D081を使用しました。
DL 署名者カードは、RSA または ECDSA 非対称暗号アルゴリズムを使用して、カード自体のデータおよび文書のデジタル署名を提供します。 PKI インフラストラクチャーがサポートされており、DL Signer カードでは、カード自体で生成された暗号鍵のペアに関連する X.509 証明書を保管することができます。 ルート証明書からエンドエンティティ証明書までの信頼チェーンを構成するすべての X.509 証明書を格納することがサポートされています。
DL署名者カードで生成された公開鍵は、証明書署名要件(以下CSR)を作成する際にリクエストの本文に配置されます。 要求は、カード自体を離れることはなく、キーペアを生成した後に読み取ることができない適切な秘密鍵を使用してカード自体に署名されます。 さらに、CSRは認証機関に送信され、それに基づいてX.509証明書を作成して署名します。 このエンドエンティティ証明書は、信頼チェーンからの他の証明書とともに DL Signer カードに配置され、データおよび文書にデジタル署名する準備ができています。 ユーザーは、サービスの使用を希望する任意の認証機関にCSRを送信できます。 Digital Logicは、システムをテストするためにエンドエンティティ証明書を発行するためのメカニズムを提供しています。 エンドエンティティ証明書の基本的な特性の 1 つは、そのような証明書に含まれる公開キーとペアになっている秘密キーを他の証明書の署名に使用してはならないことです。
暗号化キーペアの生成を開始し、CSRを生成し、DL署名者カードのPINおよびPUKコードを管理し、X.509証明書の内容を操作し、データとファイルに署名するWindowsソフトウェアツールは、「ufr署名者」として配布されます。
「署名検証者」は、RSAおよびECDSAデジタル署名を検証するWindowsアプリケーションです。
署名のデジタル署名と検証は、この目的のために開発したufr-pkcs11モジュールを使用して、Adobe Acrobat Reader DCアプリケーションから行うこともできます。 当社の PKCS#11 モジュールは、一般的な Mozilla の電子メールクライアントやウェブブラウザ、および PKCS#11 仕様と互換性のある他のソフトウェアツールでも使用できます。
また、X.509証明書と署名付きPDFファイルをオンラインでチェックするためのWebサービスも提供しました。
「uFR Signer」は、暗号鍵ペアの生成を開始し、CSR要求を生成し、DL署名者カードのPINおよびPUKコードを管理し、X.509証明書の内容を操作し、データとファイルに署名するソフトウェアツールです。
アプリケーションは、タブ コントロールのビジュアル コンポーネントを使用して複数の論理単位に分割されます。 タブには、次のユニットの名前でラベルが付けられています。
「RSA キー」および「EC キー」は、RSA または ECC キーペアを作成および操作するために使用されます。
RSA(Rivest、Shamir、& Adleman)とECC(Elliptic Curve Cryptography)は、現代の非対称暗号アルゴリズムを表しています。 DL 署名者カードは、3 つの RSA キーと 3 つの ECC キーの個別の保管をサポートします。 各暗号鍵は、異なる長さと特性を持つことができ、暗号アルゴリズムと鍵索引によって示されます。
「PINコード」タブは、uFRリーダーフィールドにあるDL署名者カードにユーザーPINコードを管理して記録することを指します。 暗証番号は「個人識別番号」の略称です。 このタブでは、PINコードに加えて、PUKコードを使用して最終的にブロックされたカードのロックを解除することもできます。 PUKは「PINロック解除キー」の略です。
[カードオブジェクト]タブは、インデックスを介してそれぞれの暗号化キーに関連付けられているCA証明書とエンドエンティティ証明書を管理するために使用されます。 証明書は X.509 バージョン 3 の下にある必要があります。 エンドエンティティ資格情報には、DL Signer カードで最初に生成された公開鍵と、関連付けられた秘密鍵が含まれている必要があります。 証明書の主な目的は、PKCS#11 モジュールを介した署名の準備に使用することです。 X.509証明書の存在は、独自のアプリケーションでDL署名者カードを使用するために必須ではありません。
[署名]タブには、デジタル署名を作成するためのオプションがあります。 バイト配列、テキスト入力、またはファイルに署名することができます。 これらの署名は、「署名検証」アプリケーションを使用して検証できます。
パフォーマンスの問題に効率的に対処するために、DL署名者カードは、データのブロックにできるだけ簡潔に署名するように設計されています。 したがって、PKCS#1 v1.5 スキームで定義されている RSA アルゴリズムを使用してデータにデジタル署名することをお勧めします。 ECDSA アルゴリズムの場合、デジタル署名生成手順、パディング、および位置合わせメカニズムは RFC 6979 で定義されています。
uFRSignerアプリケーションの最新バージョンは1.5.3.0であり、uFCoderライブラリバージョン5.0.1以降とuFRファームウェアバージョン5.0.7以降を使用する必要があります。
PINコードは「個人識別番号」の略です。 DL署名者カードには、2つの異なるPINコードが含まれています。 これらはSO(セキュリティオフィサー)のPINとユーザーPINコードです。 いわゆる「セキュリティ担当者」は、DL署名者カード上のセキュリティオブジェクトにアクセスするための管理者権限を持つユーザーです。 したがって、PINコードはユーザーのPINコードとは異なる必要があります。
「セキュリティオフィサー」は、PINコードとPUKコードを変更し、キーと証明書のストレージの内容を変更する必要がある場合、カードにアクセスするためにログインする必要があります。 ハッシュされたデータ文字列のデジタル署名を取得するには、ユーザーのPINコードを使用してログインする必要があります。
DL署名者カードのPINコードは、最小4文字、最大8文字です。 ここでは、文字の下に、英数字(大文字と小文字を区別)または印刷可能な文字があります。 印刷可能な文字は、主に標準キーボードの句読点を指します。 PINコードを変更する場合、個々のローカライズされたキーパッドでのみ検出できる特定の文字を使用することはお勧めしませんが、ASCII標準であり、標準の米国英語キーボードに存在する文字のみを使用することはお勧めしません。
すべてのDL署名者カードでは、デフォルトのPINコードとユーザーPINコードが最初に設定されており、8つの連続した数字「0」(ゼロ)または「00000000」で構成されています。
間違った連続PINコードの入力の最大数は5です。 PINコードの入力を連続して誤る回数を超えると、そのPINコードはブロックされます。 PINコードはブロックされていませんが、正しいPINコードを入力すると、誤って入力されたPINコードカウンターがリセットされます。
PINのブロックを解除する唯一の方法は、正しいPUKコードを入力することです。 PUKは「PINロック解除キー」の略語です。 SO PUKコードはSO PINコードのブロックを解除し、ユーザーPUKはユーザーPINコードのブロックを解除するためにのみ機能します。 PUKコードが10回連続して誤って入力された場合、PUKコードは使用できなくなり、ブロックされたPINコードが関連するカードの機能は永久にブロックされたままになります。
[RSA キー] タブには、RSA キーを作成および管理するためのオプションがあります。 RSA キーを使用する前に、DL 署名者カードが、ufr-signer アプリケーションを実行しているコンピューターに接続されている uFR リーダー・フィールドにある必要があります。 また、SO(セキュリティオフィサー)はログインする必要があります。
「ECキー」タブには、ECキーを作成および管理するためのオプションがあります。 EC キーを処理する前に、DL 署名者カードは、ufr-signer アプリケーションを実行しているコンピューターに接続されている uFR リーダー・フィールドにある必要があります。 また、SO(セキュリティオフィサー)はログインする必要があります。
DL 署名者カードは、以下の標準 ECC 曲線をサポートしています。
DL署名者22:
SEP112R1, SECP112R2, SECP128R1, SEP128R2, SEP160K1, SEP160R1, SEP160R2, SEP192K1, SEP192R1, SEP224K1, SEP224R1, SEP256K1, SETP256R1, SECP384R1, SECP521R1, SET113R1, SET113R2, SET131R1, SECT131R2, Sect163K1, Sect163R1, Sect163R2, Sect193R1, Sect233K1, Sect233R1, Sect239K1, Sect283K1, Sect283R1, Sect409K1, Sect409R1.
DL署名者30:
secp192k1, secp192r1, secp256k1, secp256r1, secp384r1.
DL署名者145:
secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, secp256r1, secp384r1, secp521r1.
これは PKCS#10 標準によって定義され、特に識別名に証明書のユーザーに関する基本情報を含む標準化されたレコードを表します。 特性名に基づいて、いわゆるサブジェクト(サブジェクトフィールド)が最終的なX.509証明書に形成されます。 さらに、CSR レコードには、認証局 (CA) が認証ポリシーに応じて検討または破棄できる X.509 標準で指定された拡張子が含まれている場合もあります。 CSRの基本的な部分は確かに公開鍵とそのパラメータです。 PKCS#10 標準で定義された形式でパッケージ化されたこれらのデータはすべて、最終的に適切な暗号化ダイジェスト アルゴリズムに渡され、結果は適切な秘密キーを使用してカードに署名されます。 このようにして取得したデジタル署名は、CSRの不可欠な部分になります。
CSRは、いわゆる認証局(CA)を表す証明書の目的の発行者に送信されます。 証明書発行者は、それぞれの秘密キーによって署名された X.509 エンドエンティティ証明書を生成し、適切な中間 CA 証明書またはルート CA 証明書に含まれる公開キーに関連付けます。 このようにして、エンドエンティティ証明書は、証明機関 (CA) によって保証された信頼チェーンの一部になります。
「証明書署名要求(CSR)」ダイアログは、「識別名(DN)」、「拡張子」の入力のための別のグループであり、コンボボックスのグループの右上にあり、ハッシュアルゴリズムと暗号化キーの定義を制御します。 右下には、CSRの生成に関連するアクティビティを選択するためのボタンのグループがあります。
DN と呼ばれる識別名は、属性グループを表す相対識別名 (RDN) グループで構成されます。 DN を定義する場合、RDN フィールドの順序は非常に重要です。 DN 内で 1 つの RDN フィールドを複数回繰り返すことができることに注意してください。 認証局(CA)は、CSRで定義されているのと同じDNで証明書を発行する義務はありませんが、DNは、以前に実装されたユーザーのIDの検証中に取得した独自のルールとデータに基づいて形成できることに注意してください。
DN の形成は、コンボ ボックスから適切な RDN を選択し、テキスト ボックスに目的の値を入力することによって行われます。 「Put」ボタンを押すと、宣言されたRDNがDNを定義するリスト(リストボックス)に配置されます。 リストで RDN フィールドの 1 つが選択されている場合、選択したフィールドと前のフィールドの間に新しい RDN が挿入されます。 DN リストで何も選択されていない場合は、新しい RDN フィールドがリストの最後に挿入されます。 リストの選択を解除するには、「選択解除」ボタンを押します。 正しくないRDNは、「削除」を押すとリストから削除できます。 RDNフィールドの順序は、リストで選択したRDNの冗長性に影響を与える[上へ移動]ボタンと[下へ移動]ボタンを使用して変更できます。
拡張機能は CSR のオプション部分であり、証明機関 (CA) は、証明ポリシーに応じて、拡張機能を検討または拒否できます。 より多くの属性を割り当てることが可能であり、サブジェクトの代替サブジェクト (サブジェクトの別名、省略された subjectAltName) 内に電子メール アドレスを定義することが望ましいのは、この目的の通常の場所で最も一般的な証明書発行者であるためです。 拡張機能の場合、個々の属性の順序は重要ではありません。 鍵の望ましい目的、鍵の拡張された目的、および修飾証明書に関連するステートメントを引き続き定義できることが想定されています。 繰り返しになりますが、証明書の発行者は拡張機能を無視でき、いわゆる適格電子証明書を発行できるのは一部の人だけであることを強調する必要があります。 いずれにせよ、拡張機能内で、ユーザーは将来の証明書の望ましい要素を示すことができますが、繰り返しになりますが、X.509証明書の最終的な削除は発行者にのみ依存し、すべての詳細は発行契約の締結前にポリシーに完全に精通している必要があります。
ハッシュアルゴリズムの選択は、「署名者ダイジェストアルゴリズム」でマークされたコンボボックスから行われます。 デフォルトの選択は SHA-256 で、出力に 256 ビットまたは 32 バイトの SHA2 アルゴリズムに関連しており、CSR に使用することをお勧めします。 SHA1は推奨されなくなり、出力のバイト数が多いSHA2(384および512)とSHA3アルゴリズムは、将来より頻繁に使用される予定です。
キーとそのパラメータ(「署名者暗号アルゴリズム」および「署名者キーインデックス(カード)」)はここでは変更できず、このダイアログを開いたタブ(「RSAキー」または「ECキー」)ですでに定義されており、ここでの目的は情報提供のみを目的としています。 CSRダイアログを開いた「RSA鍵」または「EC鍵」が、RSA鍵のサイズを示すラベル上に、カードから以前に読み取られた対応する公開鍵がなかった場合、ECDSA曲線は「公開鍵が設定されていない」と示される。 公開鍵が設定されていない場合、「署名して保存CSR」を実行することはできませんが、既存のCSR、いわゆるTBS CSRからDNや内線を読み込むことは可能です。
TBS CSRは、複数の共通機能を持つCSRリクエストを作成するためのテンプレートとして機能する、いわゆる「署名される」リクエストと呼ばれる内部レコードフォーマットです。 TBS CSR には暗号化キーは含まれず、DN と内線番号のみが保存されます。
「エントリのクリア」ボタンを押すと、DNと拡張子のすべての項目が削除され、ダイアログが新しいエントリ用に準備されます。
「署名してCSRを保存」キーを押すと、カード内のCSRに署名し、選択したファイルに保存します。 カードが接続されたuFRリーダーのフィールドにない場合、または間違ったユーザーPINコードを入力した場合は、適切な説明を含むエラーメッセージが表示されます。
CSR を生成した後の最後の作業は、CSR を発行者に送信して X.509 証明書を受信することです。 商用または非商用の証明書発行者を選択するか、[証明書をオンラインで取得]ボタンを押すことで、CSRをWebサービスに送信して、「Digital Logic Ltd」が発行するデモンストレーションのテスト証明書を取得できます。テスト証明書。 デモンストレーションでは、テスト証明書はテストでの使用のみを目的としており、その有効期間は3か月です。 付属のルート CA 証明書と中間 CA 証明書は 、http://ca.d-logic.com からダウンロードできます。
[証明書をオンラインで取得]ボタンをクリックすると、以前に保存した「.pem」拡張子のCSRファイルを入力するよう求められ、HTTPサーバーに送信されます。 https://certificates.d-logic.com 上のサーバーへの接続に成功し、X.509証明書が発行されると、証明書を保存するためのファイル名の入力を求められます。 それ以外の場合は、適切なエラー メッセージが表示されます。
このタブは、DL 署名者カードの証明書に関連する X.509 オブジェクトを管理することを目的としています。 カードから X.509 オブジェクトを読み取るために、PIN コードを使用してログインする必要はありません。 カード上のX.509オブジェクトのストレージの内容を変更するには、「PINコード」ページでSO PINコードを使用してログインする必要があります。
[X.509 オブジェクト] タブで、アプリケーションはすぐに uFR リーダーのフィールドに存在するカードを読み取ろうとします。 フィールドにDL署名者カードがない場合は、次の図に示すようにエラーメッセージが表示されます。
X.509 オブジェクト・ストレージがカードから正常に読み取られると、証明書表示リストにその内容が取り込まれます。 これらのリストは、目的のカードをリーダーフィールドに配置し、[カードからオブジェクトを更新する]ボタンを押すことで、いつでも更新できます。
X.509証明書ファイルの選択は、「証明書ファイルを開く」キーを押すことによって行われます。 拡張子が「.pem」のPEM形式(Base64エンコード)のファイル、または拡張子が「.crt」、「.cer」、「.der」を持つASN.1標準(DERエンコード)で記述されたバイナリファイルから証明書を読み取ることもできます。 有効なファイルを選択すると、選択した X.509 証明書の内容を示すシステム ダイアログが表示されます。 証明書項目を確認後、「OK」ボタンを押して確認すれば十分です。
選択した証明書をカードに保存するには、カードに保存されている他の証明書に関して一意である必要がある目的のオブジェクト ID(任意の英数字文字列)を入力する必要があります。 オブジェクト ID は、「オブジェクト ID:」というラベルの付いたテキスト ボックスに入力されます。 提案は、RSA公開鍵を含む証明書は、例えばのIDでマークされるべきであるということです。"0001" から "0003" および ECDSA 公開鍵を含むものは、例えば の ID でマークされます。"1001" から "1003" まで。 CA証明書にはカードに固有のIDタグも必要であるため、たとえば「5001」から「5012」のタグを付けることをお勧めします。 キーの種類を選択する必要があります。 RSA および ECDSA タイプの場合、カード内の秘密キー インデックスはその証明書にバインドされ、これらのインデックスは一貫している必要があります。 CA 認証局の場合、インデックスの順序は関係ありませんが、推奨事項による透明性のため、ルートから中間など、順番にペアで入力する必要があります。 PKCS#11 モジュールをサポートし、X.509 証明書を使用するアプリケーションは、カードからすべての公開オブジェクトを読み取り、証明書自体の内容に基づいて信頼チェーンをチェックすることによって機能します。 最後に、「指定されたID、オブジェクトタイプ、およびインデックスを使用して、ファイルから証明書をカードに入れる」というわかりやすい名前のボタンを押す必要があります。
CA証明書のルートと中間のペアについて説明しましたが、これをさらに明確にする必要があるかもしれません。 ここでは、信頼チェーン内のエンドエンティティ証明書が、ルート CA 証明書の中間を通じて確立されることを前提としています。 これは、証明書の公式発行者による信頼チェーンを形成する通常の方法です。 ただし、これは厳密なルールではなく、信頼チェーンを形成する CA 証明書を変更する他の構成も可能です。 チェーンの先頭、いわゆるルート(ルート)CA証明書とチェーンエンドエンティティ証明書(リーフ証明書)の最後に、常に2つの最終証明書があることを強調することが重要です。
[署名]タブには、カードからデジタル署名を取得するためのコマンドがあります。 「M:」(メッセージ)というラベルの付いた入力行からのデータのセット、または「署名するファイルを設定」ラジオボタンをクリックしてパスを設定できるファイルに署名できます。 データは、16 進数 (HEX) 形式、Base64 エンコード、または ASCII コード レイアウトで入力できます。
16 進数 (HEX) 形式には、スペースで区切ることができる 16 進数のペアが含まれます。 Base64形式は、X.509証明書の暗号化およびPEMレコードでよく使用されます。 ここでは、Base64形式については詳しく説明しません。 ASCIIコードレイアウトは、すべての英数字とすべての標準句読点を含むテキストデータセットを記録するために一般的に使用される標準です。 原則として、標準の米国英語キーボードから入力できるものはすべてASCIIコードレイアウトでカバーされています。 万が一、ASCIIコードレイアウトの一部ではない文字が入力され、このオプションが選択されている場合、これらの文字は内部的に文字「?」に置き換えられます。 ASCIIコードレイアウトの一部ではない文字は、一部のローカライズされたキーボードを使用するか、「M:」テキストボックスのコンテキストメニューから「貼り付け」オプションを選択して入力できます。
入力行に何らかのデータが入力された場合、入力エラーの場合を除き、目的のレコードフォーマット(HEX / Base64 / ASCIIオプション)を選択するだけで、別の種類のレコードに変換されます。
「署名するファイルを設定」ラジオボタンをクリックすると、Windowsオペレーティングシステムの標準であるファイル選択ダイアログが開きます。 ファイルを選択すると、そのパスは "M:" テキスト ボックスに設定されます。
「メッセージをバイナリファイルに保存」ボタンを押すと、「M:」テキストボックスに入力されたバイト配列をバイナリファイルに格納することができます。
「署名を取得」を選択すると、署名されるデータは選択されたハッシュアルゴリズム(メッセージダイジェストアルゴリズム)を通過し、その結果がカードに送信されます。 次に、カードは、「暗号アルゴリズム」コンボボックス(RSAまたはECDSA)から選択された暗号化アルゴリズムとカード内のキーインデックス(「カード内のキーインデックス」コンボボックス)に基づいて署名を生成します。 カードに署名するには、事前にユーザーPINコードでログインする必要があります。
署名が成功すると、選択したオプションに応じて、デジタル署名の値が HEX または Base64 形式の [署名] テキスト ボックスに表示されます。 HEX/Base64の選択を変更することで、署名表示を変換することができます。 署名は、「署名をバイナリファイルに保存」ボタンを押すとバイナリファイルに保存できます。
デジタル署名のハッシュ値を計算するオプションも実装されています。 この目的のためのハッシュアルゴリズムの選択には、一部の古い暗号化システムがまだこのメカニズムに依存しているため、歴史的な理由から廃止されたMD5アルゴリズムも含まれています。 デジタル署名のハッシュ値は、「ハッシュをファイルに保存」ボタンを押すことでバイナリファイルに保存できます。
ソフトウェア開発キット(SDK)は、 当社のソフトウェアリポジトリからダウンロードできます。
μFRシリーズNFCリーダ、ファームウェアバージョン3.9.53以上、μFRライブラリバージョン4.3.3以上
他のソフトウェア例を閲覧またはダウンロードするには、 Gitlabソフトウェアリポジトリにアクセスしてください。
デバイスの購入については、 公式オンラインストアにアクセスしてください。
ソフトウェアの例についてご不明な点がございましたら、 テクニカルサポートまでお気軽にお問い合わせください 。
