すべての
火災にもかかわらず、市民の義務を果たす時でした-税金を支払うことです。
State Servicesポータルから税金を支払います。 電子署名（State Servicesポータルの
用語）を
使用して 、State Servicesポータルの個人アカウントを入力します。 認定認証センター（CA）で取得した証明書と秘密キーを手元に持っている。 両方とも、ロシアの暗号化をサポートする
PKCS＃11トークンに保存し
ます 。
そして、市民としての義務を果たしたので、私は
libreofficeオフィススイートで電子署名の動作をもう一度確認することにしました。
なぜこれを行うことにしたのですか？ State Servicesポータルにアクセスするには、Linux OSとRedfoxブラウザーを使用します。Redfoxブラウザーは、ロシアの暗号化のサポートで変更されたMozilla Firefoxブラウザーです。 ご存じのように、libreofficeオフィススイートは証明書ストアとしてNSSストレージも使用します。
Redfox-52ブラウザーは、/ usr / local / lib64 / firefox-52フォルダーにインストールされました。
NOST（Network Security Services）パッケージのライブラリをGOSTアルゴリズムのサポートに接続するには、LD_LIBRARY_PATH変数の値を次のように設定します。
$export LD_LIBRARY_PATH=/usr/local/lib64/firefox-52:$LD_LIBRARY_PATH $
libreofficeは通常、証明書ストアとして、Firefox、Thunderbirdメールクライアント、または統合されたSeamonkeyパッケージの証明書ストアを使用します。 GoogleChrome / Cromiumブラウザの証明書ストアを使用したり、独自の独立したストアを作成したりすることを妨げるものはありません（ツール->オプション->セキュリティ->証明書）：
ストレージを選択したら、ライブラリを接続し、libreofficeを実行し、odtファイルを作成して、署名を試行します（[ファイル]-> [デジタル署名]-> [デジタル署名]）。
Firefox / NSSリポジトリ内の証明書が正常に表示および検証されます。
ただし、証明書を選択して[OK]ボタンを押した後の署名は形成されません。
libreofficeは、NSSがRedfoxブラウザーから使用されるという事実にもかかわらず、ロシアの暗号化アルゴリズムを理解したくないようです。Redfoxブラウザーは、GOSTアルゴリズムを理解し、証明書の検証が成功することで確認されます。
2回目の試行を行います。今回はPDFファイルへの署名を試みます。 これを行うには、準備されたドキュメントをPDF形式でエクスポートします。 PDFファイルに署名するには、当然、ダウンロードする必要があります（ファイル->デジタル署名-> PDFに署名）。 ダウンロードした後、署名を試みます（[ファイル]-> [デジタル署名]-> [デジタル署名]）（上記を参照し、証明書を選択して、たとえばドキュメントに署名する目的を指定します）：
そして、署名が形成されます!!! 署名は、GOST R 34.10-2012 512ビットのキーを持つ「Test 12 512」証明書に基づいて形成されていることがわかります。 署名が正しい。
libreofficeを終了します。 libreofficeを再度実行し、署名されたPDFファイルをロードして、署名を確認します。 すべてがOKです。 署名者証明書を表示します。 すべてがOKです。 奇跡！ PDFへの署名は機能します。 2番目、3番目の署名を配置します...すべてが機能します。 しかし、何かが忘れられません。 追加のチェックを行います。
署名済みPDFファイルを開きます（mcの組み込みエディター-Midnight Commander-Linux用コンソールファイルマネージャーを使用しました）。 電子署名を検索します（/ Type / Sig /）：
ご覧のとおり、署名は16進数のシンボリック形式で保存されています。 コピーしてファイルに保存します。 ファイルをバイナリ（DERエンコード）に変換するには、xxdユーティリティを使用します。
$xxd –p –r < PDF> > <>.der $
結果のファイルには、切断されたDERエンコードPKCS＃7形式の署名が含まれます。 これで、この署名は、asn1-prase、たとえばopensslユーティリティで表示できます。 ただし、NSSパッケージについて説明しているため、derdump
ユーティリティまたは
ppユーティリティを使用します 。
$pp –t p7 –u –i pkcs7_detach.p7 PKCS
そして、すべてがそれほど良いわけではないことが明らかになりました。 はい、ダイジェスト暗号化アルゴリズム：GOST R 34.10-2012署名用に選択された証明書に基づくキー512署名アルゴリズムですが、署名はSHA-256アルゴリズムを使用して計算されたハッシュから生成されます（ダイジェストアルゴリズム（1）：SHA-256）。 そして、これはポイントから間違っています：GOST R 34.10-2012キー512のハッシュは、GOST R 34.11-2012-512アルゴリズムに従って考慮されるべきです。
libreofficeのソースコードの分析に取りかかりましょう。悪魔は描かれているほどひどいものではありません。 この記事では、NSSパッケージを使用して電子署名を生成することを検討します。 MS Windowsプラットフォームを好む人がいる場合は、CryptoAPI（および、それに応じてGOST-CSP）を使用し、この資料と同様に、対応する改訂を行うことができます。
分析の結果、変更は2つのファイルでのみ行う必要があることが示されました。
-〜/ libreoffice-5.3.7.2 / vcl / source / gdi / pdfwriter_impl.cxx-〜/ libreoffice-5.3.7.2 / xmlsecurity / source / pdfio / pdfdocument.cxxこれらの変更は、GOST証明書のハッシュ関数の正しい選択に関連付けられています。 ハッシュ関数の選択は、証明書キーのタイプに応じて決定されます。 たとえば、PDFWriter :: Sign（ファイルpdfwriter_impl.cxx）でのハッシュアルゴリズムの選択は次のようになります。
bool PDFWriter::Sign(PDFSignContext& rContext) { #ifndef _WIN32 SECKEYPublicKey *pubk = NULL; SECOidTag hashAlgTag; HASH_HashType hashType; int hashLen; CERTCertificate *cert = CERT_DecodeCertFromPackage(reinterpret_cast<char *>(rContext.m_pDerEncoded), rContext.m_nDerEncoded); if (!cert) { SAL_WARN("vcl.pdfwriter", "CERT_DecodeCertFromPackage failed"); return false; } /* */ pubk = CERT_ExtractPublicKey(cert); if (pubk == NULL) return NULL; /* */ switch(pubk->keyType){ case gost3410Key: hashAlgTag = SEC_OID_GOSTHASH; hashType = HASH_AlgGOSTHASH; hashLen = SHA256_LENGTH; break; case gost3410Key_256: hashAlgTag = SEC_OID_GOST3411_2012_256; hashType = HASH_AlgGOSTHASH_12_256; hashLen = SHA256_LENGTH; break; case gost3410Key_512: hashAlgTag = SEC_OID_GOST3411_2012_512; hashLen = SHA256_LENGTH * 2; hashType = HASH_AlgGOSTHASH_12_512; break; default: hashAlgTag = SEC_OID_SHA256; hashType = HASH_AlgSHA256; hashLen = SHA256_LENGTH; break; } /* */ HashContextScope hc(HASH_Create(hashType)); . . . }
ロジックの他の変更はこれらに似ています。 ファイル〜/ libreoffice-5.3.7.2 / vcl / source / gdi / pdfwriter_impl.cxxのパッチがあります
ファイル〜/ libreoffice-5.3.7.2 / xmlsecurity / source / pdfio / pdfdocument.cxxのパッチがあります
変更を行った後、libreofficeパッケージをビルドします。 行われた変更は、3つのライブラリ（/ usr / lib64 / libreoffice / program）に影響を与えました。
- libvcllo.so ;
- libxmlsecurity.so ;
- libxsec-xmlsec.so
これら3つのライブラリは、インストールされたlibreofficeディストリビューション（/ usr / lib64 / libreoffice / program）で置き換えられました。
その後、PDFファイル内のGOST署名の署名と検証は問題なく通過しました。 そして、ここでそのような抜粋で目を引くサイトの1つで：
連邦税務局は、法人の統一法人登記簿から抜粋を取得するための優れたサービスを提供しており、完全に無料です。 抽出物は、資格のある電子署名で署名されたPDFドキュメントの形式で取得できます。 そして、そのような抜粋は、商業銀行、政府機関に送ることができ、あなたは紙の形でそれを求められません。 全体として、非常に快適です。
注文、受け取り、確認：
署名者証明書の信頼証明書のチェーンをリポジトリにインストールすることを忘れないでください。 しかし、これは自然なことです。
以上で、PDFファイルで電子署名（1つまたは複数）を使用できるようになりました。 ドキュメントを調整するときとドキュメントを保存するときの両方で非常に便利です。
また、誰かが接続および切断の両方でPKCS＃7形式の古典的な電子署名の
操作に慣れている場合、
GUINSSPYグラフィックパッケージの更新バージョン（LinuxおよびWindowsプラットフォーム用）が
準備されています。
開発はPython3で行われました。Linuxプラットフォームで問題がなければ、MS Windowsではエンコードに悩まされました。 実際、これは別の開発であり、これには別の記事が必要です。 これらのニュアンスはすべてソースコードで見ることができます。
このユーティリティを使用すると、libreofficeの証明書ストアを作成したり、証明書を管理したり、ファイルに署名したりできます。
また、このユーティリティを使用すると、キーペアを生成して証明書リクエストを作成し、証明書センターに転送して、受信した証明書をリポジトリにインストールできます。
また、国内のLinuxフォークのメーカーがロシアの暗号化を使用するためにさまざまなパッケージ（NSS、Firefox、Thunderbiird、GnuPG / SMIME、SSH、KMail、Kleopatra、LibreOffice、OpenSSLなど）を変更した場合、暗号化の分野での輸入代替についてです。