1

http - Web 応答にデジタル署名しようとしています。基本的に、HTML とマルチパート コンテンツ タイプの応答を作成し、応答に署名してから、デジタル署名を応答に追加します。追加された署名は実際には HEXtoString であるため、これは真の PGP 署名ではないため、私は近いと思いますが、いくつかのステップから外れています。大きなことは、応答を正しく解釈できるように、署名を正しく表現できることです。私はこれにかなり慣れているので、ここでいくつかの提案を使用できます。よろしくお願いします..以下は、私が現在使用しているコードのスニペットです。

    StringBuffer myResponse = new StringBuffer("");
            myResponse.append(getHttpHeader());
            KeyPair pair2 = loadKeyPair();//loads a key pair from generated files

    if (signer==null)
        signer = Signature.getInstance("MD5withRSA");
    signer.initSign(pair2.getPrivate());
    signer.update(message.getBytes());
    byte[] b = signer.sign();
    FileOutputStream sigfos = new FileOutputStream(getFileLocation(0,localTest));
    sigfos.write(b);
    sigfos.close();
    //verify
    signer.initVerify(pair2.getPublic());//pubKey);
    signer.update(message.getBytes());
    if (signer.verify(b)){
        myResponse.append(message);
    }

    StringBuffer signed= new StringBuffer("");
    signed.append(boundary);
    signed.append(CRLF);
    signed.append("content-type: application/pgp-signature");
    signed.append(CRLF);
    signed.append("-----BEGIN PGP MESSAGE-----");
    signed.append(CRLF);
    signed.append("Version: 1");//update this
    signed.append(CRLF);
    signed.append(CRLF);

    signed.append(digSignature);//generated as HexString representation of signed file from above
    signed.append(CRLF);

    signed.append("-----END PGP MESSAGE-----");
    signed.append(CRLF);
    signed.append(boundary+"--");

            myResponse.append (signed);
            ServletOutputStream.println(myResponse);

結果として送信される「署名」は、署名されたファイルのバイトハッシュ hexToString 表現です。私は標準の Java クラスを使用していますが、他のライブラリが 0-9a-f 表現以外の文字を含む真の PGP 表現を提供してくれるかどうかはわかりません。アイデア??

4

2 に答える 2

0

確認コードはどのようにクライアントにダウンロードされますか? 問題のアプリケーションの詳細は? HTTP 経由でダウンロードされた検証スクリプトである場合、スキームは根本的に壊れています。特にすでにそのように主張している場合は、おそらく SSL を使用する必要があります。

システムについて詳しく知らなくても、中間者攻撃の敵は次のことを行うだけでよいように思えます。

  1. 検証コードの公開鍵を独自のものに置き換えます。
  2. 独自の署名を使用して、すべての「安全な」通信を放棄します。
  3. スクリプトがチェックする公開鍵は攻撃者によって変更されているため、スクリプトは何も問題を認識しません。

言うまでもなく、すべての通信はプレーンテキストで行われます (個人情報や機密情報が送信されないことを願っています)。

SSL はこの問題を回避します。これは、すべての証明書が、Web ブラウザーによって信頼されている、または Web ブラウザーと共にインストールされているルート認証局によって署名されている必要があるためです。CA は、ドメインの証明書を管理/所有者にのみ発行することになっています。したがって、以前の攻撃は機能しません。

ここで、クライアントが信頼できる方法でインストールされ、敵対者が改ざんできないようになっている場合は、スキームを続行しても安全です。たとえば、クライアントが手動でクライアント PC にインストールされるか、別の方法 (SSL 経由やコード署名の使用など) で安全に配信される場合です。

(MD5 ハッシュへの言及に気付きました。MD5 ハッシュは使用しないでください。MD5 は壊れています。)

于 2011-01-11T16:55:30.273 に答える
0

この問題は、NAESB-EDI 標準によるものです。http リクエストでファイルが送信され、特定のレスポンスを生成する必要がある場合。SSL を使用しており、元のペイロードは暗号化されているはずです。応答はプレーンな html (4 項目) で、応答のデジタル署名が追加されています。私が考えたのは、応答を作成し、生成された応答に基づいて既存の pgp ソフトウェアに署名を作成させ、署名を応答に追加することです。したがって、私はもう MD5 を使用しておらず、キーを公開していません (私たちが特に取引しているものを除く)。したがって、James の回答は部分的に正しく、SSL を使用していないため、応答がクリア テキストであるため、スニッフィングに対する保護はほとんど提供されません。しかし、要求に必要な情報がなければ、適切な応答を得ることさえできません。

于 2011-07-13T13:41:06.557 に答える