XCA-ロシアおよびドイツのプログラマーに関するエンタープライズレベルまたはサガの認定センター

誰もあなたと同じくらい深くコードを見たことがないと思います。
ChristianHohnstädt、プログラミング、翻訳、テストXCA

翻訳：

私のコードをあなたほど深く見た人はいないと思います。
ChristianHohnstädt、XCA開発者

認証局（CA）はかなり複雑な生物であり、多くのコンポーネントで構成されるソフトウェアとハ​​ードウェアの複合体だけでなく、その性能を確保するために高度な資格を持つ専門家のスタッフ全員の存在も必要です。 なぜ認証センターが必要なのか、それはどのような製品を生産し、どこで使用されているのでしょうか？

x509証明書と市民パスポートの共通点は何ですか？
パスポートオフィスと認証局の共通点は何ですか？

CAセンターの主な機能は、電子署名検証キー（SKEPEP）の証明書の作成と保守です。これには、証明書所有者の要求に応じたキーペアの作成が含まれます。 すぐに予約を入れてください。私の確信では、CAセンターの最新のサービスは有害で危険です。
証明書とキーペア（秘密キーと公開キー、または電子署名検証キーとも呼ばれます）を受け取った人は、いつでもドキュメントの下で電子署名（ES）を放棄し、CAでキーが盗まれた可能性があると主張できますその世代の瞬間。 したがって、自分でキーペアを生成し、それを目の当たりとして保存し、CAで生成する場合は、回復不能なキーを持つPKCS＃11トークン/スマートカードでのみ正しいです。

CAは、標準X.509 v.3（ RFC 5280 ）に従って証明書を発行することに注意してください。
一般に、CAの機能は、パスポートオフィスの機能とほぼ一致します 。これは、ロシア内務省の責任です。
パスポートのような証明書は、申請書といくつかの文書の提供に基づいて発行されます。 証明書を取得するためのドキュメントのリストは、通信省によって認定されている認証センターにあります。
市民が受け取ったパスポートの主なものは何ですか？ これはシリーズと番号で、発行者、発行日時、パスポートの写真と市民自身の手書きの署名、警察官の署名によって認証され、封印されています。
そして、証明書の主なものは何ですか？ また、発行者のシリアル番号、SNILSとTINの両方を含む市民に関する情報、および市民の写真と手書き署名の類似物も持っています。これは公開キーまたは電子署名検証キーです。 そして、これはすべてCAの電子署名によって認証されています。 また、受信したドキュメント（ファイル）は証明書と呼ばれます。 あなたは、秘密鍵はどこにあるのかと尋ねます。実際、その助けを借りて、文書の下に電子署名が置かれていますか？ そして、私たちが上で言ったように、秘密鍵は市民が電子メディア（フラッシュドライブ、トークン/スマートカード）に保管する必要があります。これは、彼が個人の署名を置く方法を知っている方法と似ています。 そのため、文書に市民の有効な署名を絶対に自信を持って言うことができます。 奇妙なことに、電子署名を使用した同様の状況。 秘密鍵を持っていると、市民は明確に公開鍵を取得し、文書が署名されているかどうかを証明書で確認できます！
そして、市民がパスポートを盗んだり紛失した場合、市民はどうすればよいのでしょうか？ ATSのパスポートオフィスで緊急に申告する必要があります。 その後、パスポートは無効とみなされ、 無効なロシアのパスポートのリストに含まれます 。 この時点から、紛失したパスポートに関する法的措置は無効になります。 証明書の失効に関する同様の状況。 秘密キーが失われた場合（通常、ティアオフメディア（フラッシュドライブ、トークン、スマートカードなど）に保存されている場合）、またはコピーされた疑いがある場合は、CAに緊急に連絡して証明書を失効させる（無効にする）必要があります。 この場合、彼はSAS-失効した証明書のリストに分類されます。 証明書、つまり秘密鍵が失われても証明書は取り消されないことに注意してください。 証明書自体は公開されており、その複製は常にCAで学習できます。

x509証明書が必要なのはなぜですか？

それで、なぜロシア連邦の市民と法人のために証明書が必要なのですか？ 最も認識できるのは、公共サービスのポータルへのアクセスです。 連邦税務サービスポータルへのアクセスも重要です。 次に-電子入札など。 原則として、このリストは通信省に登録されている各CAにあります。
ロシア連邦の法人と市民により、すべてが明確です。 また、特定の企業の従業員が電子署名の検証証明書を必要とするのはなぜですか？ 多くのことが判明しました。 PKCS＃11インターフェースを備えたトークンまたはスマートカードに保存された個人証明書（証明書とキーペア）は、企業の領土へのパスとしても機能し、コンピューターへのアクセスを提供し、ドキュメントへの署名と暗号化、エンタープライズポータルでの個人アカウントへのアクセス、企業VPNサービスは、承認されたHTTPSを介してエンタープライズポータルにアクセスできます。 このため、通信省およびマスメディアの認可を受けたCAで企業外の証明書を取得し、これにお金を払う必要はまったくありません。 一方、中小規模の企業での本格的なCAの展開は、手頃な価格であるだけでなく、大砲からスズメを撃つことに似ています。 中小企業は、このような複合体のほとんどの機能を必要としません。スケーラビリティ、ホットバックアップ、権限の分離などが必要です。

XCA （X Window System認証局）の出現の前提条件

公開のためにx509v.3証明書を発行するには、広く使用されているOpenSSLコマンドユーティリティを使用できます。特に、次の機能を実行できます。

• 鍵の生成（例：openssl genrsa ...）;
• x509 v.3証明書を取得するための要求をPKCS＃10形式で生成します。
• x509 v.3証明書エディション。
• 失効した証明書のリストの作成（/ CRL）;
• など

注意深く見ると、これらはすべてCAの機能であり、さらに、OpenSSLユーティリティのコマンドの1つ、つまりCAコマンドは、最低限必要な機能を備えたCAであることがわかります。

$openssl ca -md <hash> -in <req_file> -out <cert_file> 

ここで：

• ca-CAと協力するチーム
• md-電子署名（ES）の証明書証明書キーを発行するために使用するハッシュ関数（sha1、sha512、gosthashなど）を示すオプション
• in-ES検証キーの証明書の要求をファイル<req_file>から取得することを示すオプション
• out-ESをチェックするためのキーの生成された証明書をファイル<cert_file>に書き込む必要があることを示すオプション

OpenSSLコマンドユーティリティを使用することの欠点は明らかです。

• 多数のチームとさらに多くのコマンドパラメーター、特に、 少なくとも5つのチームが証明書の発行にのみ必要です。
• かなり複雑な構成ファイルopenssl.cnf;
• しかし、最も重要なことは、証明書の単一の保管庫（データベース）がないことです。これにより、証明書の管理プロセスが非常に困難になります。

プロジェクトNSS（Network Security System）は、Mozillaのプロジェクト、GoogleのChromeブラウザーなどで証明書の処理に広く使用されているOpenSSLプロジェクトと本質的に同一であるため、より良い点を区別する最後のポイントです。 また、利便性について話す場合、証明書（認証局）の公開と管理のためのX Windowsシステムに基づく単一のグラフィカルインターフェイスが必要です。 X Window System-グラフィカルユーザーインターフェイスを構築するための標準ツールとプロトコルを提供するウィンドウシステム。

XCA機能

これらの仮定に基づいて、 XCAオープンソースプロジェクトが誕生しました。OpenSSLライブラリは暗号化変換に使用され、Qtライブラリはグラフィカルインターフェイスに使用され、C ++言語はプログラミング言語として使用されます。 グラフィカルインターフェースの設計には、Qt Designer（デザイナーユーティリティ）が使用されました。これにより、新しい証明書のグラフィカルインターフェースの形式（ファイル〜/ src / ui / NewX509.ui）など、ロシアの法律や規制当局の規制行為の特定の要件を考慮してグラフィカルインターフェースを簡単に変更できます：



XCAにCAオブジェクトを保存するために、パスワードで保護されたデータベースが作成されます。
証明機関としてのXCAグラフィックインターフェイスは、5つの機能タブと2つのドロップダウンメニューの形式で実装されます。
-キー、証明書、およびその他のXCAオブジェクトに関する情報を保存するように設計されたデータベース管理機能。

-キーを作成および管理するための機能。

-証​​明書要求管理（PKCS＃10）;


-x509 v3証明書管理機能。


-クエリのテンプレート管理機能。


-失効した証明書のリストを管理する機能（/ CRL）;


-PKCS＃11トークン/スマートカード管理機能。

XCAグラフィカルアプリケーションは、証明書発行および管理センター（以降、XCA CAと呼びます）であると安全に言えます。

XCAでのロシアの暗号化アルゴリズムのサポートについて

次に、XCA CAでロシアの暗号化アルゴリズムをサポートすることに興味があります。 そして、これが2012年以前に起こった場合、すべてがうまくいくでしょう。その時までに、OpenSSLプロジェクトはすでにGOST R 34.10-2001とGOST R 34.11-94とGOST 28147-89の両方をサポートしていました。 しかし、2012年には新しい暗号化アルゴリズムGOST R 34.10-2012とGOST R 34.11-2012が承認され、2015年にはバッタとマグマの新しい暗号化アルゴリズム、すなわちGOST R 34.12-2015とGOST R 34.13が承認されました2015年。
残念ながら、現在OpenSSLは新しいロシアのアルゴリズムをサポートしていません。 この場合、問題を解決する方法は2つあります。 1つ目は、既存のlibgostと同様に、新しいロシアアルゴリズムをサポートする新しいエンジンの開発に関連しています。 2番目の方法は、ロシア語のアルゴリズムをOpenSSLに直接埋め込むことです。 TK-26の新しい要件を実装するという観点からは、少なくともPKCS＃12コンテナに対しては、最初のケースではOpenSSLをアップグレードする必要があるため、2番目の方法がより望ましいようです。 新しいアルゴリズムのインストールは、まず、OpenSSLプロジェクト（obj_mac.h）にTK-26が推奨するロシアのOIDを含めることを意味します。

 #define SN_cryptopro "cryptopro" #define NID_cryptopro 805 #define OBJ_cryptopro OBJ_member_body,643L,2L,2L #define SN_cryptocom "cryptocom" #define NID_cryptocom 806 #define OBJ_cryptocom OBJ_member_body,643L,2L,9L #define SN_id_tc26 "id-tc26" #define NID_id_tc26 958 #define OBJ_id_tc26 OBJ_member_body,643L,7L,1L … 

XCAにGOSTアルゴリズムを組み込み、OpenSSLを使用してIDを組み込むために、GOSTのキーのタイプを決定する導入された定数にも注意してください。

 #define EVP_PKEY_GOST3410 NID_id_GostR3410_2001 #define EVP_PKEY_GOST3410_2012_256 NID_id_GostR3410_2012_256 #define EVP_PKEY_GOST3410_2012_512 NID_id_GostR3410_2012_512 

NewKey.cppのstruct typelist typelist []構造は次のようになります。

 static const struct typelist typeList[] = { { "RSA", EVP_PKEY_RSA }, { "DSA", EVP_PKEY_DSA }, #ifndef OPENSSL_NO_EC { "EC", EVP_PKEY_EC }, #endif /*  34.10-2001 */ { "GOSTR3410-2001", EVP_PKEY_GOST3410}, /*  34.10-2012    256 */ { "GOSTR3410-2012-256", EVP_PKEY_GOST3410_2012_256}, /*  34.10-2012    512 */ { "GOSTR3410-2012-512", EVP_PKEY_GOST3410_2012_512}, }; 

そして、このようなOpenSSLの改良により、ロシアの暗号化アルゴリズムを「XCA」CAに埋め込むことができます。 「XCA」CAは、GOSTキーの生成から始めて、CAのすべての機能を実行できるようになりました。



証明書の発行と証明書失効リストの発行で終わる（CRL / CAC）：



プライベートキーと証明書は、企業の従業員が引き裂き媒体で受け取る必要があると上記で述べました。 そのような媒体として、PKCS＃11インターフェースを備えたトークン/スマートカードが「XCA」CAで使用されます。 ロシアの暗号化のサポートについて話す場合、TK-26（pkcs11_gost.h）の推奨事項に従ってPKCS＃11トークンをサポートするためにプロジェクトを完成させる必要があります。

  … #define NSSCK_VENDOR_PKCS11_RU_TEAM 0xd4321000 //0x80000000|0x54321000 #define NSSCK_VENDOR_PKSC11_RU_TEAM NSSCK_VENDOR_PKCS11_RU_TEAM #define CK_VENDOR_PKCS11_RU_TEAM_TC26 NSSCK_VENDOR_PKCS11_RU_TEAM … 

エンタープライズでのCA「XCA」の配置

そのため、最終的には、ロシアの暗号化を完全にサポートする、完全に機能するエンタープライズ規模のCAができます。
XCA CAを配置する場所 最も合理的なのは、人事部門またはセキュリティサービスです。 雇用時にこれらのサービスのいずれかに到着すると、従業員はここで、とりわけ、回復不能なキーが生成されるトークンを受け取ります。



そしてその証明書がインストールされます：



その結果、センターのルート自己署名証明書と会社の従業員の証明書の両方が「XCA」CAのデータベースに保存されます。



データベースには、秘密鍵の保存場所に関する情報も含まれています。

お正月の雑用

そして今、プロジェクトの綿密な研究の後、新年の前夜に次の手紙が著者クリスチャン・ホーンシュタットに送られました：

こんにちはクリスチャン！
製品XCAを監視します。 それを探求し、私たちはプロを育てます
レベル。 ロシアの暗号化アルゴリズムを使用するように調整します。 感謝の気持ちで
あなたの仕事のために、私たちはあなたに贈り物（ロシアのウォッカのボトル）を送りたいです、
しかし、残念ながら、あなたの郵便アドレスはわかりません。 教えてください
それで、私たちはあなたに贈り物を送ることができます。

翻訳すると、次のようになります。

こんにちはクリスチャン！
XCA製品をフォローしています。 それを探求して、私たちは専門レベルを向上させます。 ロシアの暗号化アルゴリズムに適合させました。 あなたの仕事に感謝して、私たちはあなたに贈り物（ロシアのウォッカのボトル）を送りたいと思っていますが、残念ながら、私たちはあなたの住所を知りません。 教えてください。

そして著者は答えた：

ありがとう、会社の住所に送ってください。
小包サービスがパケットを配達するとき、私は通常家にいません。

Innominate Security Technologies
クリスチャン・ホーンシュエット
ルードワー・ショッセ13
12489ベルリン
ドイツ

著者の回答で注目に値するもの：

ありがとう、私の会社に送ってください。 配達サービスが荷物を配達するとき、私は通常家にいません。

ドイツのプログラマーだけでなく、ロシア人および世界中のすべてのプログラマーがほとんどの時間を仕事に費やしていることが判明しました！
そしてもちろん、私たちの伝統的なロシアのプレゼント、ウォッカのボトルとチョコレートの箱が、柔らかいおもちゃのLysenkoを追加して、著者に届けられました!!!

しかし、その前に、記事の冒頭にある抜粋である手紙がありました。

プログラマーが私のコードに問題やバグを見つけた場合、
私もそれらを修正できるように、それらについて教えてください。
誰もあなたと同じくらい深くコードを見たことがないと思います。

そして、ここに翻訳があります：

あなたのプログラマーが私のコードにエラーを見つけた場合、私がそれらを修正できるように、それらについて私に知らせてください。
私のコードをあなたほど深く見た人はいないと思います。

このような評価には大きな価値があります。
ここに何を追加できますか？ 「XCA」CAがLinux、Mac OS X、他のUnixフォーク、MS Windowsを実行しているだけです。
PS Oneは、ロシア連邦とドイツ連邦共和国という2つの偉大な国のプログラマーのこのような協力と理解を夢見ています。