2011-06-23 11 views
1

昨年の夏、私はハードウェアを統合するための見込顧客のコンピュータの適合性をテストしたアプリケーションを開発していました。提案された考えの1つは、ツールによって生成されたHTMLレポートを特定の状況での払い戻しの正当性として使用することでした。自動生成されたレポートに署名して確認する

私の直ちに反応は「真正性を検証するためにこれらの報告書に署名する必要があります」私が想像した解決策は、レポートの署名を作成し、それをメタタグに埋め込むことでした。残念ながら、このシナリオでは、アプリケーションにレポートに署名する必要があります。つまり、秘密鍵が必要です。アプリケーションが秘密鍵を格納すると、真正性が保証されていない正方形に戻ります。

私の次のアイデアは、電話で家に帰ってレポートに署名することでしたが、ハードウェアの互換性をテストするためだけにインターネットに接続する必要がありました。さらに、アプリケーションはサーバーで認証する必要があり、利害関係者はそれを行うために使用していた資格情報を把握することができます。

私の質問はこれです。アプリケーションが実際にレポートを生成したことを確認するために、難読化以外の方法はありますか?

答えて

1

ユージンは私の最初の答えが受信機を認証することであると正しく指摘しました。アプリケーションがクライアント側で配備されている

は、あなたが生成した秘密鍵を保持している自己署名PFX証明書を導入:私は

は、送信者を認証し、送信者を認証するための別のアプローチを提案してみましょう。 PFXのためのあなたのクライアントとパスフレーズの

詳細は、クライアントによって設定され、..あなたはそれが印刷され、彼らはちょうど生成した鍵のためにそれらが責任を保持するために、紙に自分のクライアントによって署名を取得できるかもしれ

署名できる秘密鍵があり、HTMLレポートをエクスポートするときに証明書をレポートと共にエクスポートすることができます。

これは低コストのソリューションであり、以前の投稿でEugeneが示したように秘密鍵を秘密鍵に入れるほど安全ではありません。

受信機を認証:

は、あなたの受信側でRSA 2048鍵ペアを持っています。公開鍵を送信者にエクスポートします。

送信者がレポートを生成した場合は、レポートをAES 256などの対称キーで暗号化します。対称キー自体を公開キーで暗号化/ラップさせます。

暗号化されたレポートを受け取ったら、秘密キーを使用して対称キーをアンラップ/復号化し、次に暗号化されたレポートを対称キーで復号化します。

このようにして、目的の受信者だけがレポートを表示できるようにします。

+0

タスクは、受信者ではなく送信者を認証することです。 –

+0

@Eugene、はい、あなたは正しいです。私はその記事を誤解した。私は以前の答えを残して、私の答えを編集します。そうすれば、質問の逆を探している人には恩恵を受けることができます。 – Raj

+0

これは良い解決策です。何らかの理由で、署名プロセス全体がユーザーにとって透過的であると仮定しました。もちろん、払い戻しのためにレポートを使用しようとすると、明示的に認証してはならない理由はありません。 – jpm

1

私は、可能性のあるリスクを再評価する必要があり、考えられるほど重要ではない可能性が高いと考えています。その理由は、レポートには貴重な価値がありますが、顧客にとってはそうした可能性は低いからです。それは多かれ少なかれビジネス上の仕事であり、プログラミング上の仕事ではありません。

具体的な質問に答えるために、署名に使用される秘密鍵を盗まれないように保護する簡単な方法はありません。内部に秘密鍵を格納した暗号トークンを使用するより複雑なソリューションでは、cryptotoken自体がハードウェアであり、シナリオでは不必要にスキームが複雑になります。

+1

このシナリオでは、顧客への価値(したがって実際のセキュリティリスク)が制限されていることは間違いありません。このように、私が到着した解決策には悩まされませんでした。ソフトウェアの各リリースビルドには、ランダムに生成された塩が関連付けられていました。ソルトはクライアントアプリケーションに埋め込まれ、ソルトレポートをハッシュして作成された「シグネチャ」が作成されました。これは単純で、埋め込まれた秘密鍵で署名するほど安全です。誰かがアプリから塩を掘り出すほど悪い払い戻しを望んでいたら、彼らはそれを持つことができると考えました。 – jpm

関連する問題