web-dev-qa-db-ja.com

ファイルに「署名する」とはどういう意味ですか?

私はセキュリティに少し慣れていないので、概念を適切に理解しようとしています。

ファイル(証明書、apkファイル、またはその他の何か)に正確に「署名する」とはどういう意味ですか?

  1. 暗号化されるようにファイル全体に署名しますか?
  2. たとえば、Zipなどの署名してパススルーするプレーンテキストのようなものはありますか?受信側に、それ以上進む前に特定のプロトコルに基づいてそのピースをチェックさせますか?
  3. または、他の何か?

私の知る限り、ファイル全体に署名すると、内容が暗号化(または署名)されるため、より安全になります。しかし、私はあなたが全部ではなくテキストの一部にのみ署名するいくつかの例を見たり聞いたりしたことがあります。

任意のアイデアをいただければ幸いです。

PS:私はすでにチェックしました キー署名はどういう意味ですか?

26
zgulser

残念ながら、署名はメッセージダイジェストの暗号化と同等であると主張するここでの回答は完全に正しいわけではありません。署名には、メッセージのダイジェストの暗号化は含まれません。暗号化操作は、メッセージ自体ではなく、暗号化ハッシュアルゴリズムによって作成されたメッセージのダイジェストに適用されることは正しいですが、署名の動作は暗号化とは異なります。

https://www.cs.cornell.edu/courses/cs5430/2015sp/notes/rsa_sign_vs_dec.php から取得:

教科書の抽象的な世界では、RSA署名とRSA解読は同じものです。実際の実装では、そうではありません。したがって、RSA復号の実際の実装を使用してRSA署名を計算しないでください。最良のケースでは、実装はあなたが気づく方法で壊れます。最悪の場合、攻撃者が悪用する可能性のある脆弱性を導入します。

さらに、RSAから一般化して、任意の暗号化スキームをデジタル署名アルゴリズムとして適合させることができると誤解しないでください。この種の適応は、RSAとEl Gamalでは機能しますが、一般的には機能しません。


メッセージのデジタル署名を作成するには、メッセージを ハッシュ関数 で実行し、メッセージのダイジェスト(固定サイズ表現)を作成します。数学的操作は、秘密値(秘密鍵のコンポーネント)と公開値(公開キーのコンポーネント)を使用してダイジェストに対して行われます。この操作の結果が署名であり、通常はメッセージに添付されるか、メッセージと一緒に配信されます。メッセージが秘密鍵を所持している誰かによって署名されたかどうかは、署名と公開鍵を持っているだけで誰でも知ることができます。それで、これはどのように機能しますか?

アルゴリズムの例として [〜#〜] rsa [〜#〜] を使用します。最初に、RSAのしくみについて少し説明します。 RSA暗号化では、整数として表されるメッセージを取得し、既知の値(この値は、多くの場合3または65537)で累乗します。この値は、各公開鍵に固有の公開値で除算されます。残りは暗号化されたメッセージです。これは モジュロ演算 と呼ばれます。 RSAでの署名は少し異なります。メッセージは最初にハッシュされ、ハッシュダイジェストはsecret数で累乗され、最後に公開鍵の同じ一意の公開値で除算されます。残りは署名です。これは暗号化とは異なります。これは、数値を既知のパブリックな値で累乗するのではなく、署名者だけが知っている秘密の値で累乗されるためです。

RSA署名の生成は、紙の上のRSA復号に似ていますが、実際のRSA署名の動作には大きな違いがあります。現実の世界では、 パディング と呼ばれる機能が使用されており、このパディングはアルゴリズムのセキュリティにとって絶対に不可欠です。暗号化または復号化にパディングを使用する方法は、署名に使用する方法とは異なります。以下の詳細はより技術的です...


非対称暗号化の例として textbook RSA を使用するには、メッセージmを暗号文cに暗号化しますc≡mを計算して行いますe (mod N)、ここでeは公開値(通常は Fermatプライム )、および [〜#〜] n [〜#〜]は、2つの秘密の素数の秘密でない積です。一方、ハッシュmの署名には、s≡mの計算が含まれます。d (mod N)、ここでdeのモジュラー逆行列であり、秘密の素数。これは、暗号化よりもdecryptionにはるかに近いですが、署名の復号化の呼び出しはまだ 正しくない です。他の非対称アルゴリズムは完全に異なる手法を使用する場合があることに注意してください。 RSAは、例として使用できる一般的なアルゴリズムにすぎません。

署名のセキュリティは、秘密の素数を知らないとdを取得するのが難しいという事実から来ています。実際、[〜#〜] n [〜#〜]からdを取得する唯一の既知の方法は、[〜#〜] n [〜#〜]を構成要素の素数に、pq、およびd≡eを計算します-1 mod(p-1)(q-1)。非常に大きな整数を因数分解することは、古典的なコンピュータにとって扱いにくい問題であると考えられています。これにより、かどうかを判断する必要があるため、署名を簡単に検証できます。e ≡m(mod N)。ただし、署名を作成するには、秘密鍵の知識が必要です。

33
forest

ファイルに署名しても、ファイルは暗号化されません。アリスがファイルに署名するとき、彼女は通常ファイル全体に署名します。そこで、彼女はファイル全体のハッシュを計算し、そのハッシュのみに秘密鍵で署名し、この情報をファイルに添付します。
ボブは彼女の公開鍵を使用してそれを検証し、計算されたハッシュを取得します。次に、自分でファイルのハッシュを(もちろん署名なしで)計算し、両方のハッシュをチェックします。それらがアリスが送信したファイルと同じ正確なバージョンと一致する場合。それらが一致しない場合、マロリーはそれを変更した可能性があります。

ファイル自体が暗号化されることはありません。もちろん、署名を削除するだけで済みますが、その後は署名されません(したがって、価値がありません)。

より技術的で詳細な情報については、フォレストの回答を参照してください: https://security.stackexchange.com/a/198473/19145

42
Lithilion

もちろん、必要な情報(の一部)に署名し、その他の部分には署名しないようにすることもできます。ただし、通常、「ファイルに署名する」とは、ファイル全体とファイルメタデータ(ファイル変更タイムスタンプなど)に署名することを指します。これがOpenPGPとGPGの仕組みです。

ただし、それがファイルではない場合、たとえばXML署名である場合は、XMLコンテンツのどの部分が実際に署名の対象となるかを指定する必要があります。

また、署名と暗号化を区別するようにしてください。これらは2つの独立した問題です。 1つのファイルは、非暗号化+署名、または暗号化+署名なし、または他の任意の組み合わせにすることができます。

6
papajony

ファイルに署名すること、またはより一般的には一部のコンテンツ(電子メールメッセージ、電子メールメッセージの本文、XMLドキュメントのサブツリー、証明書の一部、TLSハンドシェイクなど)に署名することは、バイトのシーケンスを作成することを意味しますこれはsignatureと呼ばれます。このプロセスには特定の特性があります。

  • 署名を検証する方法があります。署名を検証すると、「これはファイルの適切な署名です」または「これはファイルの適切な署名ではありません」というブール値の結果が得られます。
  • ファイルの適切な署名が別のファイルの適切な署名になることはありません。したがって、適切な署名は、ファイルがauthenticであることを保証します。 Authenticityは、セキュリティ上、一部のデータが実際には本来の場所から取得されることを意味します。
  • 秘密鍵または秘密鍵と呼ばれる秘密値があります。その秘密の値がわからない場合、ファイルの適切な署名を作成することは不可能です。
  • 公開鍵スキームでは、公開鍵と呼ばれる秘密鍵に関連付けられた値があります。公開鍵がわかっている場合は、署名を検証できますが、別のファイルの署名を作成することはできません。

誰でもファイルに署名できることを知っておくことは重要ですが、ファイルに署名できるのは自分の秘密鍵だけです。たとえばコンピュータをハッキングするなどして何らかの方法で秘密鍵を入手できなければ、他人の秘密鍵でファイルに署名することはできません。したがって、ファイルにaの良い署名が付いていることを知っていても、何も言われません。重要なのは、期待どおりに作成された良い署名があることを知ることです。秘密鍵。つまり、検証者は事前に公開鍵を知っている必要があります。公開鍵が署名とメッセージとともに送信される場合、それ自体は何も証明しませんが、検証者が公開鍵を検証できるようにするメカニズムがある場合に役立ちます。このようなメカニズムは _公開鍵インフラストラクチャ と呼ばれます。つまり、署名操作により、秘密鍵の機密性の保証と公開鍵の信頼性の保証が、ファイルの信頼性の保証に変わります。

署名は通常、「このコンテンツを承認する」ことを意味します。 「承認」の意味は、状況によって異なります。例えば:

  • MicrosoftがMicrosoftのWindows更新署名キーで署名されたWindows更新を配布する場合、署名はこの特定のコード更新がMicrosoftによって承認されたことを意味します。誰かがマルウェアを配布し、それをWindowsの更新プログラムとして偽装したい場合、そのユーザーは適切な署名を作成できないため、Windows Updateアプリケーションは更新プログラムを拒否します。
  • 署名されたメールを受け取った場合は、そのメールが署名者によって実際に作成された(またはマシンが侵害された)ことを意味します。電子メールのFrom:行からこの保証を得るのは一般的ではありません。なぜなら、誰でも必要なものを誰でも書けるからです。 (一部の配布システムはそれを難し​​くしますが、一般的にインターネットでは、人々がFrom:行に好きなものを書くのを防ぐ方法はありません。)
  • 認証局が証明書に署名するとき、彼らが言っているのは、証明書にリストされているドメイン名の所有者が、対応する公開鍵が証明書にある秘密鍵の所有者であることを確認したということです。名前を公開鍵に関連付けるこの種のステートメントは、 公開鍵インフラストラクチャ の基礎です。
  • TLSサーバーがTLS接続のハンドシェイクに署名すると、クライアントは自分が本人であることを確認できます。誰でもTLSハンドシェイクに署名できますが、google.comの公開署名でTLSハンドシェイクに署名できるのはGoogleだけです。

署名は別のデータです。これは、署名されたデータとともにZipファイルにバンドルしたり、電子メールの添付ファイルとして追加したり、XMLファイルに個別のノードとして追加したりできます。証明書では、署名は署名されたデータと一緒にバンドルされます。 TLSハンドシェイクでは、署名はサーバーから送信されるメッセージの個別の部分です。

暗号化されるようにファイル全体に署名しますか?

いいえ。署名はファイルの内容によって異なりますが、署名からファイルの内容を復元することはできません。コンテンツは署名とともに送信する必要があります。コンテンツは暗号化できますが、署名に依存しません。

たとえば、Zipなどの署名してパススルーするプレーンテキストのようなものはありますか。受信する側は、特定のプロトコルに基づいてその部分をチェックしてから先に進みますか?

はい、正確に。送信者は、署名するファイルのコンテンツ(Zipまたはテキストなど)と秘密鍵を署名関数に渡し、署名を取得します。 (「署名」という言葉は、このプロセスまたはこのプロセスの出力を指します。)受信者はコンテンツと公開キーを検証機能に渡し、「良い」または「悪い」という結果を受け取ります。一般に、受信者は、署名が悪い場合、コンテンツの操作を拒否します。

私の知る限り、ファイル全体に署名すると、内容が暗号化(または署名)されるため、より安全になります。

何かに署名しても、何も暗号化されません。ファイル全体に署名することは、署名が署名された部分についてのみセキュリティを提供するという意味で、ファイルの一部に署名するよりも安全です。ファイルの一部に署名する場合、署名されていない部分は何でもかまいません。