3

PHP スクリプト (authentication.php?UserID=ClientsEmail@email.com&ClientsID=81E17) と通信するアプリケーションを作成していますダウンロードできます。インターネット上のすべての通信は AES-256 (CBC) で暗号化され、メインの暗号化キーは実行可能ファイルにハード コードされます。このメイン キーは、exe を再コンパイルし、アップグレードとしてすべてのクライアントに渡すことによって、年に 1 回だけ変更されます。このキーはめったに変更されないため、できれば繰り返さない初期化ベクトルを生成することが重要です。

私の暗号テキスト出力は Base 64 なので、IV をできるだけ統一するようにしました。つまり、IV が暗号テキスト出力の一部であるかのように見えるようにしました。

したがって、私の最初の質問は、以下の関数が繰り返される可能性がどのくらいかということです。タイマーがオンになっているテストアプリを作成し、以下の関数をループしてデータベースに追加し、繰り返されるかどうかを確認しました。テスト アプリは一晩実行され、合計 69369 回のループがあり、繰り返しはありませんでした。

// Generate a  16 bytes = 128 bits Initialization vector Used for AES-256
Function TfrmMain.GenerateIV:String;
  Var
   i,j : Integer;

   Const
    {Uppercase}
    alpa_L : array[1..26] of string = ('a','b','c','d','e','f','g','h','i','j','k',
                                       'l','m','n','o','p','q','r','s','t','u','v',
                                       'w','x','y','z');
    {Lowercase}
    alpa_U : array[1..26] of string = ('A','B','C','D','E','F','G','H','I','J','K',
                                       'L','M','N','O','P','Q','R','S','T','U','V',
                                       'W','X','Y','Z');
    {numeric}
    Num : array[1..10] of string     = ('0','1','2','3','4','5','6','7','8','9');
Begin
  Result := '';
  Randomize;
  for i := 1 to 16 do //16 bytes = 128 bits AES=Fixed 128 Blocks
   Begin
      j := RandomRange(1, 4); //RandomRange - Delphi's help says inclusive but it is non-inclusive
      case j of
        1: Result := Result + alpa_L[RandomRange(1, 27)]; {alphabetic Uppercase}
        2: Result := Result + alpa_U[RandomRange(1, 27)]; {alphabetic Lowercase}
        3: Result := Result + Num[RandomRange(1, 11)]     {numeric}
      end;
   end;        
end;

そうは言っても、まとめようとしている別のアイデアがあります。私の考えは、メインの暗号化キーを実行可能ファイルにハードコーディングする代わりに、次のとおりです。私のサーバーは暗号化キーをランダムに生成し、保護されていない状態でアプリケーションに渡します。サーバーとアプリ間のすべての通信は、そのセッションのこのキーを使用して暗号化され、すべてのファイルがダウンロードされると、セッションが閉じられます。

上記の唯一の問題は、暗号化キーがそのセッションで保護されていないアプリケーションに送信されるため、少し知識があれば、アプリとサーバーが通信しているものを確認でき、ハッカーは認証がどのように行われるかを確認できることです。これを知ったら、アプリケーションをサーバーにリダイレクトして認証部分を実行し、通常どおり続行できます。これを回避する唯一の方法は、このキーを保護することですが、「実行可能ファイルにハードコードされた」という正方形に戻ります。

したがって、このアプリケーションの最初のバージョンでは、上記の問題が解決されるまで、キーを実行可能ファイルにハード コードすることになります。

残念ながら、サーバーは (HTTPS) プロトコルをサポートしていません

4

2 に答える 2

1

機能の再現性について

答えは、それは非常にまれですが、最終的には関数が繰り返される可能性があるということです。

その理由は、乱数の生成方法にあります。Delphiを含むほとんどのコンパイラは、疑似乱数ジェネレータを使用します。これらのジェネレーターは、シードと呼ばれる特定の初期値に基づいて疑似乱数を生成するアルゴリズムを使用します。

シードと使用されるアルゴリズムの両方を知っていれば、生成された数値を複製することが可能になります。アルゴリズムは簡単にわかるかもしれませんが、シードはそうではありません。Delphiでは、GetTickCountまたはQueryPerformanceCounterを呼び出すRandomizeを使用してシードを確立します。

あなたのコードを考えると、私はあなたにそれが起こるのを見る可能性は非常に低いと思いますが、私はあなたにそれについての証拠を与えることはできません。この問題の詳細については、こちらをご覧ください。

キーコミュニケーションについて

あなたの最善の策は、@MadHatterが提案したものを使用することです。このタイプの環境に適したセキュリティスキーマは次のとおりです。

  1. 非対称暗号化を使用して、サーバーとエンドユーザーが通信に使用する暗号化キーを確立します。ここでの最良のオプションは、公開鍵暗号を使用することです。この例として、RSAとDiffie-Hellmanがあります。
  2. 次に、サーバーとエンドユーザーだけがAESの暗号化キーまたは任意の対称暗号化アルゴリズムとして知っている生成されたキーを使用します。

理論的には、通信全体に非対称暗号を使用することもできますが、対称バージョンよりもオーバーヘッド（計算コスト）が高いため、上記のスキーマを使用することをお勧めします。

HTH

于 2012-04-19T07:07:22.563 に答える
1

暗号化キーが実行可能ファイルに埋め込まれ、年に 1 回変更されると、安全な通信ができなくなります。セッションキーを安全に交換できる安全なキー交換プロトコルがあります (つまり、Diffie-Hellman を探してください)。もちろん、話すべき相手と話していることを確認する必要があります (中間者ではなく)。そのため、エンドポイントの認証も必要になる場合があります。

また、サーバーが HTTPS をサポートしていない場合でも、プレーンな HTTP (またはその他のプロトコル) で同じ手法を使用できます。SSL は決して HTTP に関連付けられていません。Web サーバーがすべての「面倒な作業」を行うことに単に依存するのではなく、より多くのコードを記述する必要があるだけです。

于 2012-04-18T12:06:20.167 に答える