4

次のようにシリアルキーを作成するアプリケーションがあります。

Take customername
Sign customername using privatekey and sha/dsa algorithm

次に、公開鍵でデコードし、顧客名の一致を確認することで、ライセンスを確認できます

生成されたシリアルがかなり長いことを除けば、これは問題なく機能します。そのため、お客様がシリアル キーを入力するのは現実的ではなく、代わりにファイルでシリアル キーを提供する必要があります。これは、ミスト アプリケーションや動作とはかなり異なり、混乱を招きます。

他の多くのアプリケーションは、購入時にユーザーに Guid を提供するだけです

すなわち 5bd1060b-8608-4817-93ca-207f7c828e2f

ユーザーは、アプリケーションのライセンスを取得するために、電子メール アドレスと GUID を入力する必要があります。

これはユーザーにとってより適切なソリューションのように見えますが、データベースで電子メールアドレス/GUID のペアをチェックしてすべてオンラインで行わない限り、そのようなアプリケーションが無効な GUID から有効な GUID を検証する方法がわかりません。しかし、それ以外の場合はオンラインチェックを必要とせずに、ある種の検証を行うことを本当に望んでいます:

a>インターネット接続/サーバーがダウンしている場合、または b>インターネット アクセスを無効にすることでチェックを回避できる場合、アプリケーションは機能しません

編集：

以下の回答で提案されている私の理解ソリューション：

ユーザーが購入する電子メール アドレス
+ ソルトを取る
SHA1 で暗号化すると 160 ビット ハッシュが得
られる 16 進数表記に変換すると 20 個の 16 進値、つまり 40 文字
が得られる 最後の 8 文字を切り取って Guid
電子メール ユーザーがプログラムに入力する GUI と電子メール アドレス プログラムは、電子メール アドレスを取得し、salt を追加し、ectera を暗号化してチェックすると、有効な GUID が生成されます。

これに関する私の主な問題は、ソルトをプログラムのどこかに保存する必要があることです。したがって、ハッカーがソルトを見つけて、私が何をしているのかを突き止めれば、任意の電子メール アドレスに対して有効なライセンス キー ジェネレーターを作成できます。

別のプログラムの現在の方法:

公開鍵/秘密鍵のペアを生成しました
ユーザーが購入します電子メール
アドレスに署名してライセンスを生成します 生成されたライセンスを
BaseEncode
してユーザーにライセンスを送信し
ます

私の問題は、電子メールアドレスに署名すると長すぎるため、ユーザーがフィールドに入力する代わりにファイルに入れることになりますが、16 進数に変換するのではなく、base64 エンコーディングを行っていることが問題なのかもしれません。

署名の出力の長さは、入力の長さに依存しますか、それとも常に同じですか?

公開鍵でキーを復号化するため、ライセンス キーの一部の文字を削除することはできませんが、生成キーが 40 文字しかない場合は問題ないと思います

この方法の利点は、ハッカーが私のやり方を突き止めたとしても、ライセンス ジェネレーターを作成できないためライセンス ジェネレーターを作成できず、秘密鍵は私のサーバーにしか保存されていないため取得できないことだと思います。彼らは、新しい秘密鍵と公開鍵のペアを作成した場合にのみライセンスを生成でき、アプリケーションで公開鍵がエンコードされている場合、アプリケーションはとにかくライセンスを拒否できました。

もちろん、アプリケーションをハッキングすることはできますが、アプリケーションが定期的に更新されていた場合、これは多大な労力になります。

要約 すると、これを正しく理解しているか、どの方法が最適か、2番目のアプローチで生成されるデータの量.

4

2 に答える 2

1

署名アプローチが現在のベストプラクティスだと思います。ところで。このトピックをカバーする無料のライブラリが多数あります。

ライセンス キーの長さは、少なくとも署名キーの長さによって決まります。1024 ビットのキーは、128 バイトのライセンスを生成します (他のペイロードが追加されていない場合)。

多くの場合、ライセンス ファイルは、有効期間、ライセンスされたサブモジュール、スループットなど、ライセンスされた使用自体に関する詳細情報で構成されています。署名自体はこの構造に埋め込まれています。このようにして柔軟性が得られます。ライセンスがさらに大きくなった場合でも、このソリューションを強くお勧めします。

アプリケーションにライセンスをインポートするには、ハイブリッドな方法を採用できます (私たちが行ったように)。一方では、従来の「ライセンス ファイルのインポート」ソリューションを提供できます。もう 1 つは、ランダムな短い ID (GUID など) を生成し、それをライセンス データに関連付けます。登録時にユーザーが短い ID を入力すると、アプリケーションは HTTP 経由で完全なライセンスを検索します。一度だけオンラインにする必要があります。複雑なライセンスを提供することもでき、ユーザーは短い ID のみを必要とします。

編集

  1. 署名の長さは鍵の長さです。例: 1024 ビット (または 128 バイト)
  2. アプリケーションが署名されているデータ (メールなど) を認識している場合は、この署名を単独で使用できます。
  3. メール以外のプロパティを含む「ライセンス文書」に署名できます。この場合、ライセンスにはプロパティと署名が含まれます (したがって、署名だけよりも長くなります)。
  4. ライセンスチェックのためのオンライン接続は必要ありません。アプリケーションでライセンスをインポートするだけで、いつでも確認できます。
  5. ライセンス ファイルのインポートに加えて、短い ID をキーとしてライセンス ファイルをオンラインでダウンロードできます。ライセンスがダウンロードされ、オフラインになります。したがって、両方の長所を活用できます。
于 2012-09-01T09:01:19.690 に答える
0

「秘密の」ソルトで連結されたユーザー情報をハッシュしてから、ハッシュを切り捨てることができます。

ハッカー (彼らがあなたのプログラムに興味を持っている場合) は、ソースをリバース エンジニアリングすることによってそれをクラックします: 彼らはハッシュ アルゴリズムと秘密のソルトの両方を見つけます。

しかし、これは署名と検証のソリューションでも発生します。チェックをバイパスして true を返すことができます。

そのため、sign&verify ソリューションはより複雑ですが、安全ではありません。

于 2012-08-23T17:07:50.397 に答える