インフラストラクチャは単純な電子署名です。 パート2：ターゲットシステムのモデリング

前のパートでは、設計されたPEPインフラストラクチャでシステムを使用する図が作成されました。 次のステップは、このインフラストラクチャのターゲットシステムを分析することです。 私たちの国のターゲットシステムはPEPであり、法律によれば、これは個人の手書き署名に類似しています。 したがって、個人の手書き署名とPEPの両方について、さらに分析が行われます。

カウンターパーティシステムを使用したターゲットシステム

技術的な観点から、手書きの署名は特定の手の動きの発達した運動技能であり、その結果、手の軌跡はモノグラムの形で視覚化され、オプションの追加要素-ストロークとストロークが追加されます。 モノグラムによれば、事務システムは個人データ（PD）に関する情報を受信します。 モノグラムのタイプによって、誰がモノグラムを作成したかを識別できます。 実際、手の運動能力は、手の筋肉のために脳で書かれた一連のコマンドです。 したがって、手書き署名の要素は次のとおりです。人、脳、スキル、手、視覚モノグラム。 これらすべての要素を考慮すると、手書き署名システムの要素の次のモデルを形成できます。



自分の署名を使用するサブジェクトは、 PDのサブジェクトの役割を果たします。視覚イメージ、音イメージ、音声（セマンティック）イメージ-姓、名前、ミドルネーム、環境の場所-居住地、社会の場所-職場、およびPDとして機能することができます位置、および他のPD 。 法的に重要な署名の場合、IDカードに含まれるPDのセットが重要です。

手の運動能力は、個人のアイデンティティに対するユニークで、閉じられた、不可侵の鍵です。

モノグラム （オプションのストロークとストロークを含む）はPDの一意の公開鍵です。

脳は、秘密鍵保管ツール（モーターメモリ）であると同時に、バインド、秘密鍵、および公開鍵のプラットフォームです。



手書き署名システムの機能は、秘密鍵と公開鍵を使用して被験者のPDに関する情報を転送することです。 これは重要なポイントです。 署名は、個人データ情報の転送です。 公開キーがPDに何らかの方法で接続されていない場合、公開キーでPDを判別できない場合、この公開キーは手書きの署名の類似物ではないため、そのような公開キーは法的に重要な署名ではありません。 これは単なるメッセージであり、署名ではありません。 ログイン/パスワードはユーザーの単純な電子署名であるという誤った意見があります。 ログイン/パスワードがPDによって連絡されるまで、これはそうではありません。



上記を考慮すると、使用システムの図の相手方は、秘密鍵および公開鍵を使用してPDメッセージを生成するシステムを有するPDサブジェクトである。 主題は利害関係者であり、設計時には彼の関心を考慮する必要があります。 図では利害関係者を示していないため、カウンターパーティは個人データに関するメッセージを生成するシステムであり、その要素はPD自体であり、公開鍵システムと秘密鍵システムです。 次の図に取引相手を示します。







このモデルは、実際の署名システムに存在する要素（手書き署名用のモノグラム、 PEPキー、またはデジタル署名証明書）を持たないため、やや抽象的です。 これはまだメタモデルです。 メタモデルがモデルになるためには、ターゲットシステムの構造要素を示す必要があります。 実際には署名にはいくつかのアーキテクチャソリューションがあるため、図は多少変更されます。







この図は、同じ機能を実行するいくつかのアーキテクチャソリューションを示しています。 実際には、各技術的ソリューションは建設的なモジュールであり 、その存在はカウンターパーティによって想定されています。



プローブの建設的なソリューション、つまり公開キーを送信するために秘密キーを使用するシステムをより詳細に分析します-これがターゲットシステムです。 まず、質問に答える必要があります-「秘密鍵」 PEPとは何ですか？ FZ-63の PEPの定義からわかるように、これはコードまたはパスワード、つまり特定の文字のセットです。 手書き署名のアナログを設計しているという事実に基づいて、手書き署名の手の正しい運動スキルが相手方のみに知られているように、秘密鍵は相手方のみに知られるべきです。 秘密鍵は機密PEPデータであり、 連邦法63によれば、機密署名データの所有者は機密性を維持する責任があります。 秘密鍵を知っていると、公開鍵転送システムを使用することができます。 一般に、 プローブの公開キーとして使用されるものは、3つの条件に従って、それほど重要ではありません。

1. 公開鍵転送システムへのアクセス、すなわち 署名プロセスについては、秘密鍵の助けを借りてのみ取得できます。
2. 公開鍵は一意である必要があります。 したがって、1対1の通信が実現されます;個人データ-秘密鍵-公開鍵;
3. 手書き署名の場合と同様に、ドキュメントごとに公開鍵を個別に送信する必要があります。 1つのアーカイブファイルでない場合、複数のドキュメントの1つのキー転送は許可されません。

FZ-63の第12条2項では、公開鍵転送システムに追加の条件を規定しています。

1. 電子署名を作成する操作の電子文書に署名する人による確認後にのみ、電子署名を作成します。
2. 電子署名が作成されたことを明確に示します。

さらに、 連邦法-63の第9条によれば、これらの条件は単純な調査には適用されません。 これにより、署名の事実を証明することができなくなり、署名の重要性に悪影響を及ぼします。 技術的な解決策は、 連邦法-63の第12条第2項のすべての条件が満たされることを推奨しています。



実際には、通常、次のソリューションがキーとして使用されます。

1. 情報システムの個人アカウントへのログイン/パスワード。 パスワードは秘密鍵、ログインとして機能し、公開鍵として機能します。 これは、ログイン/パスワードを発行するときに、 PDとの接続が必ず確立される場合に受け入れられるソリューションです。 ただし、前述のように、署名の秘密鍵は公開鍵転送システムのみにアクセスできるようにする必要があります。 したがって、署名時に2つの追加キー（電話番号とSMS確認コード）を追加することをお勧めします。 それ自体がPDである電話番号は、ログインに加えて追加の公開キーとして機能し、確認コードは秘密キーの追加部分になり、公開キー転送システムへのアクセスを提供します。 署名の可能性。
2. 電子メールボックスの使用。 メールアドレスは公開鍵、メールボックスのパスワードは秘密鍵です。 これは、メールアドレスとPDの間に明確な関係が確立されている場合、PEP全体として有効なソリューションです。 ただし、通信そのもの以外のドキュメントへの署名には多くの制限があるため、法的に重要なPEPには適していません。 添付ファイルは重要なPEPによって署名されていると見なすことはできません。これは、各ドキュメントが1つのファイルのアーカイブでない場合、手書き署名のように個別に署名する必要があるためです。 しかし、実際には、添付ファイル付きのレターには、少なくとも2つのドキュメントが含まれています-レター自体と添付ファイル/添付ファイル。 したがって、署名されていると見なされるのはレターのみであり、添付ファイルではありません。 このニュアンスが問題にならない場合、通信に添付ファイルがない場合、または添付ファイルの署名が重要でない場合は、電子メールを使用して重要なPEPを整理することができます。

エージェントシステムを使用するターゲットシステム

エージェントシステム、つまり 事務作業では、取引相手から文書を受け取ると、秘密鍵は使用されず、公開鍵のみが使用されます。 手書き署名の場合、公開鍵はモノグラムです。 オフィス管理のルールによれば、署名はドキュメントの必須条件であるため、ドキュメントはそれを使用するシステムになります。 「ドキュメントの詳細」の概念とそれに含まれる要素は、2つの規範的な行為によって規制されています。

1. GOST R 6.30-2003 「統一されたドキュメントシステム。 組織および管理文書の統一システム。 事務処理の要件”-ロシア語文書の場合
2. 85-「国際情報交換への参加について」 -国際文書。

その結果、システムを使用しているドキュメントでは、次の要素を区別できます。







署名はドキュメントデザインの要素です。 この分析のために、すべての構造設計要素に関心があるわけではないため、2つの構造設計要素（署名とその他の詳細）のみを選択します。 上記で、エージェントシステムの署名は公開キーであると判断しました。







公開鍵転送システムと同様に、公開鍵登録システムにはいくつかの設計ソリューションがあります。 図の量が多いため、ここでは説明しませんが、機能ツリーの形で説明します。



まず、署名はドキュメント自体に含めることも、別のドキュメントとして存在させることもできます。 最初のタイプの署名は埋め込みと呼ばれ、2番目のタイプは切断されます。 次のモデルが表示されます。

1. 文書内の統合公開鍵の登録システム
   
   
   1. 手書き署名アーキテクチャの説明
      
      
      1. モノグラムによる個人データの件名のモノグラム
      2. エージェントの事務作業の規則に従って、取引相手が文書のテキストに追加したモノグラム
   2. シンプルな電子署名アーキテクチャの説明
      
      
      1. 簡単な電子署名コードによって個人データの主題を識別するためのシステム
      2. エージェントの事務作業の規則に従った、電子文書のテキスト内の署名コード
   3. デジタル署名アーキテクチャの説明
      
      
      1. 資格のある証明書、資格のないキー検証証明書、資格のない署名を識別する他の方法によって個人データのサブジェクトを識別するシステム。
      2. 暗号化アルゴリズムを使用して電子文書に追加される情報
2. 公開鍵ドキュメントから切断された登録システム
   
   
   1. 手書き署名アーキテクチャの説明
      
      
      1. モノグラムによる個人データの件名のモノグラム
      2. 代理店の事務の規則に従って、署名された文書の付属書である特別な文書のテキストにカウンターパーティによって追加されたモノグラム
      
      
      
   2. シンプルな電子署名アーキテクチャの説明
      
      
      1. 簡単な電子署名コードによって個人データの主題を識別するためのシステム
      2. 適用法に従ってエージェントとカウンターパーティの間で作成された契約書の署名コード。
      
      
      
   3. デジタル署名アーキテクチャの説明
      
      
      1. 資格のある証明書、資格のない鍵検証証明書、資格のない署名を識別するその他の方法によって個人データのサブジェクトを識別するシステム
      2. 別のデジタル署名ファイルとして保存された情報

これは、ターゲットシステムのモデルです。 シンプルな電子署名インフラストラクチャモデルが構築されていると考えることができます。 モデルは機能を反映し、エージェントとカウンターパーティの署名のインフラストラクチャの機能とアーキテクチャを介して。 しかし、これについてのモデリングは完了したとは見なされません。これは、簡単に説明した別の大規模システムが署名を操作する手順に参加しているためです。 これは、エージェントの事務システム内の運用環境にあるシステムであり、その機能は公開鍵による個人データの識別です。手書き署名のモノグラムまたは単純な電子署名のコードです。 このシステムが単純な電子署名にとって最も問題が多いので、 次の部分でその要素を分析します。