0

これが私の状況の（簡略化された）例です。
ユーザーはゲームをプレイし、200 ポイントのハイスコアを獲得します。ハイスコ​​アには賞金、つまり 1 ユーロ / 10 ポイントを与えます。ユーザーは 20 ユーロを獲得したという「領収書」を印刷し、それを私に渡します。私は領収書が本物で、一度も使用されていないことを確認し、賞品を彼に渡します。
私の「問題」は、明らかに太字の部分にあります。手で「領収書」を検証できるはずですが、他のオフライン方法を使用したソリューションも歓迎します (つまり、私の電話用の小さな .jar アプリケーション)。また、偽造レシートも作りにくいはずです。

これが私がこれまでに考えたこと、それらの長所と短所です。

  • 一般的なアルゴリズム、つまり SHA512を使用したハッシュ

    • 長所: モバイル デバイスで簡単に検証でき、より高い値 (コンテキスト依存のソルト、つまりユーザー名が使用されている場合) で偽装することに強い耐性があります。
    • 短所: 複数回使用できますが、手動で検証することはできません。

  • 自作のハッシュアルゴリズム

    • 長所: 手で検証できます。
    • 短所：簡単に壊れる可能性があり、複数回使用できます。

  • 証明書コード: サーバーと電話の 2 つのデータベースにコードのリストがあります。領収書が印刷されるたびに、これらのいずれかが印刷され、データベースに「使用済み」として設定されます。私の電話でも同じことを行います。コードがデータベースにあり、まだ使用されていないかどうかを確認し、データベースで「使用済み」として設定します。

    • 長所: 同じコードを複数回使用することはできません。
    • 短所: 領収書を偽造するのは非常に簡単で、手で確認することはできません。
4

2 に答える 2

2

これは、ハッシュベースのメッセージ認証コード(HMAC) アルゴリズムの典型的な使用例のように思えます。「手作業」 のアイデアは「スマートフォンを使用する」ことであり、「紙、紙、心で」ではなく、ハッシュを計算してレシートに印刷し、電話またはバックエンドで検証できます。サーバ。

于 2013-01-18T12:09:19.053 に答える
-1

The "missing point" is to use more systems at once so that, together, they work in the needed way. In this case, we can use HMAC for authenticating the message and a list of "certificate codes" to make sure one doesn't use the same receipt over and over.
Another idea might also be to hash the time when the receipt is outputted to the client and print it on the receipt. When someone shows you the code on the receipt, you make sure that hash hasn't been used yet and that it's valid (i.e. the message produces that hash), then you add it to the list of "used hashes".

Thanks to @RossPatterson for suggesting HMAC.

于 2013-01-18T18:14:21.550 に答える