ライセンスキーは、違法コピー対策としてのデファクトスタンダードです。正直なところ、これは (in)曖昧なセキュリティ のように私を襲います。ライセンスキー生成の良い(安全な)例は何ですか?彼らが使用している暗号プリミティブ(もしあれば)は何ですか?メッセージダイジェストですか?もしそうなら、彼らはどんなデータをハッシュしているのだろうか?クラッカーが独自のキージェネレータを構築するのを困難にするために開発者はどのような方法を採用しますか?キージェネレーターはどのように作られていますか?
昔のCDキーでは、CDキー(どんな文字列でも構いません)の生成が簡単で検証が簡単なアルゴリズムを作成するだけの問題でしたが、valid-CDキーとinvalid-CDキーの比率キーが非常に小さいので、ランダムにCDキーを推測しても有効なものになる可能性は低いです。
スタークラフトと半減期はどちらも同じチェックサムを使いました。したがって、最初の12桁には何でも入力でき、13桁目(10の可能性しかない)を推測でき、悪名高い1234-56789-1234
につながります。
検証のためのアルゴリズムは公開されており、次のようになります。
x = 3;
for(int i = 0; i < 12; i++)
{
x += (2 * x) ^ digit[i];
}
lastDigit = x % 10;
Windows XPはかなりの量の情報を受け取り、それを暗号化して、文字/数字のエンコーディングをステッカーに貼ります。これによりMSはあなたのキーを検証することとが同時に製品タイプ(Home、Professionalなど)を取得することを可能にしました。さらに、オンラインアクティベーションが必要です。
完全なアルゴリズムはかなり複雑ですが、ドイツで出版されている this (完全に合法的な!)論文にうまく概説されています。
もちろん、あなたがオンラインサービスを提供しているのでない限り(たとえWorld of Warcraftのように)、どんな種類のコピー防止も失速しているだけです。残念ながら、それが価値のあるゲームであれば、誰かがCDキーアルゴリズムや他のすべての著作権保護を破る(または少なくとも回避する)でしょう。
オンラインサービスでは、バイナリファイルを使用する場合でも、その使用を許可するためにサーバーで認証する必要があるため(例:WoWアカウントを持っているため)、生活は少し簡単になります。 World of WarcraftのCDキーアルゴリズム - たとえば、プレイタイムカードを購入するときに使用される - は、おそらく次のようになります。
- 暗号的に安全な非常に大きな乱数を生成します。
- データベースに保存してカードに印刷してください。
次に、誰かがプレイタイムカード番号を入力したら、それがデータベースにあるかどうかを確認し、入力されている場合は、その番号を現在のユーザーに関連付けて、二度と使用できないようにします。
オンラインサービスの場合、上記のスキームを使用する理由はありませんない。何か他のものを使うと 問題が生じる可能性があります 。
私が最初にこの答えを書いたとき、それは質問がライセンスキーの「オフライン」検証に関するものであるという仮定の下にありました。他の答えの大部分は、オンライン検証を扱います。これは、かなり処理が簡単です(ほとんどのロジックはサーバー側で実行できます)。
オフライン検証で最も困難なことは、膨大な数の一意のライセンスキーを生成しながら、簡単に妥協することのない強力なアルゴリズムを維持することです(単純なチェックデジットなど)。
私は数学にあまり精通していませんが、これを行う1つの方法は、グラフをプロットする 数学関数 を使用することです。
プロットされた線は(あなたが十分に細かい頻度を使うなら)何千ものユニークな点を持つことができるので、あなたはそのグラフ上のランダムな点を選び、何らかの方法で値を符号化することによってキーを生成できます
例として、このグラフをプロットし、4つの点を選び、 "0、-500; 100、-300; 200、-100; 100,600"のように文字列にエンコードします。
既知の固定キーで文字列を暗号化し(非常に弱いですが目的にかなっています)、結果のバイトを Base32 で変換して最終的なキーを生成します。
その後、アプリケーションはこの処理を逆にし(base32から実数に、復号化し、ポイントをデコードし)、それらの各ポイントが秘密のグラフ上にあることを確認できます。
非常に少量のコードで、大量の一意で有効なキーを生成できます。
しかしそれはあいまいさによる非常に多くのセキュリティです。コードを分解するために時間をかけている人は誰でも、グラフ作成関数と暗号化キーを見つけ、それからキージェネレータをモックアップすることができますが、それはおそらく偶然の違法コピーを遅くするために非常に役に立ちます。
Partial Key Verification にあるこの記事をチェックしてください。
ライセンスキーは、入力が簡単なものでなければなりません。
チャージバックや盗難にあったクレジットカードでの購入の場合は、ライセンスキーをブラックリストに載せる(取り消す)ことができなければなりません。
キーをテストするための「電話のかけ方」はありません。このやり方はますます普及してきていますが、私はまだユーザーとしてそれを認めていません、それで私のユーザーにそれに我慢するように頼まないでしょう。
クラッカーが私たちのリリースしたアプリケーションを逆アセンブルしてそれから実用的な“ keygen”を生成することは不可能なはずです。これは、我々のアプリケーションが検証のために鍵を完全にテストしないことを意味します。鍵の一部だけをテストする必要があります。さらに、アプリケーションの各リリースはキーの異なる部分をテストする必要があります。そのため、以前のリリースに基づく偽のキーは、当社のソフトウェアの今後のリリースでは機能しません。
重要:正当なユーザーが誤って無効なキーを入力しても機能するように見えますが、誤字のために将来のバージョンで失敗することはあり得ません。
私は人々が実際にCDキーを生成するために何をしているかについての経験を持っていません、しかし(あなたがオンラインアクティベーションの道を踏み出したくないと仮定します)
あなたが多くのキーにアクセスできる場合、推測するのは簡単ですが、潜在的な文字列の大部分は無効になるでしょう。同様に、キーのチェックサムが既知の値と一致する必要があります。
キーの前半が既知の値と連結されている場合、キーの後半までハッシュすることを要求します。もっと良いのですが、プログラムにはキーの生成と検証に必要なすべての情報が含まれています。
既知の値+ nonceを(秘密鍵で)暗号化して鍵を生成します。これは、対応する公開鍵を使用して復号化し、既知の値を検証することによって検証できます。プログラムは、キーを生成できなくてもキーを検証するのに十分な情報を得ました。
これらはまだ攻撃に対してオープンです:プログラムはまだそこにあり、チェックをバイパスするようにパッチを当てることができます。 Clevererは、プログラムに値を格納するのではなく、私の3番目の方法からの既知の値を使用してプログラムの一部を暗号化することであるかもしれません。この方法では、プログラムを復号化する前にキーのコピーを見つける必要がありますが、復号化された後にコピーされ、1人のユーザに合法コピーを入手してもらうのは危険です。
CDキーは、ネットワークに接続されていないものにはそれほど安全ではないため、技術的には安全に生成する必要はありません。もしあなたが.netを使っているなら、あなたはほとんどGuid.NewGuid()を使うことができます。
最近の主な用途は、サーバーがCDキーを検証できるマルチプレイヤーコンポーネントです。そのため、「渡されたものは何でもルックアップし、他の誰かがすでにそれを使用しているかどうかを確認する」という結果になるので、それがどの程度安全に生成されたかは重要ではありません。
それは言われて、あなたは2つの目的を達成するためにアルゴリズムを使用したいと思うかもしれません:
そうは言っても、海賊版が有効な鍵を推測し(データベースでは有効だが、それでも店の棚に入っている)、その箱を買おうとする正当な顧客を台無しにしないためには。
鍵の長さを特に気にしないのであれば、非常に試行錯誤された方法として、公開鍵と秘密鍵の暗号化を使用します。
基本的にある種のノンスと固定の署名があります。
例えば:0001-123456789
0001はあなたのナンスであり、123456789はあなたの固定署名です。
次に、秘密鍵を使ってこれを暗号化してCD鍵を入手します。ABCDEF9876543210
その後、アプリケーションと一緒に公開鍵を配布します。公開鍵を使用してCD鍵「ABCDEF9876543210」を復号化できます。その後、その公開鍵を使用しての固定署名部分を検証します。
これにより、秘密鍵を持っていないため、誰かがCD鍵がナンス0002用であると推測できなくなります。
唯一の大きな欠点は、秘密鍵と公開鍵のサイズが1024ビットの場合、CDの鍵がかなり長くなることです。あなたは些細な量の情報を暗号化しないように十分に長い一回だけを選ぶ必要もあります。
欠点は、この方法は「アクティベーション」を行わなくても機能することです。また、Eメールアドレスやライセンシー名などをナンスとして使用することもできます。
キーシステムにはいくつかのプロパティが必要です。
あなたにこれらを与えるべきである一つの解決策は 公開鍵署名方式 を使うことでしょう。 「システムハッシュ」から始めましょう(ソートされたNICのMac、ソートされたCPU-ID情報、およびその他すべてのものをまとめて連結し、結果のMD5を取得します(実際にはそうしたくありません)。処理 個人を特定できる情報 CDのシリアル番号を追加して、何らかのレジストリキー(またはデータファイル)にBLOBの有効な署名がない限り、起動を拒否します。ユーザーがBLOBをあなたに出荷することによってプログラムをアクティブにし、あなたは署名を送り返します。
潜在的な問題はあなたが誰かが 選ばれた平文 そして/または 選ばれた暗号文 攻撃を実行すると仮定する必要があるようにあなたが事実上何かに署名することを申し出ているということを含みます。与えられたシリアル番号をチェックして無効なものからのリクエストを処理することを拒否することと、一定のs/nから一定の数を超えるクエリを処理することを拒否すること(1年に2回)によって軽減できます。
私がいくつか指摘しておく必要があります。まず、熟練した決心した攻撃者は、無制限にアクセスできる部分(すなわちすべてがCDに含まれる部分)であらゆるセキュリティを回避することができます。そのアカウントでできるのは、正当なアクセスを取得するよりも違法なアクセスを取得しにくくすることです。第二に、私は専門家ではないので、この提案された計画に重大な欠陥があるかもしれません。
プロセスに複数のステップを組み込んだDRM動作もあります。最もよく知られている例の1つは、Creative Suiteのインストールを検証するためのアドビの方法の1つです。ここで説明した従来のCDキー方式が使用され、その後アドビのサポートラインが呼び出されます。 CDキーはアドビの担当者に渡され、ユーザーが使用するためのアクティベーション番号を返します。
しかし、ステップに分割されているにもかかわらず、これは通常のプロセスで使用されるクラッキングの同じ方法の餌食となります。元のCDキーと照合されるアクティベーションキーを作成するためのプロセスがすぐに発見され、両方のキーを組み込んだジェネレータが作成されました。
ただし、この方法は、インターネットに接続していないユーザーが製品を確認するための方法としてまだ存在しています。将来的には、インターネットアクセスが広く普及するにつれて、これらの方法がどのように排除されるのかを理解するのは簡単です。
CDのみのコピー防止アルゴリズムは、違法コピーに対する保護を提供することなく、正直なユーザーに不快感を与えます。
「海賊」は1つの正当なCDとそのアクセスコードへのアクセス権を持っている必要があるだけで、彼はそれからn個のコピーを作成してそれらを配布することができます。
暗号化による暗号の安全性に関係なく、CDでプレーンテキストで提供する必要があります。そうしないと、正当なユーザーがソフトウェアをライセンス認証することはできません。
最も安全なスキームは、ソフトウェアを実行するマシンの詳細(cpuのシリアル番号、MACアドレス、IPアドレスなど)をソフトウェアのサプライヤに提供するか、サプライヤのWebサイトにソフトウェアを登録するためのオンラインアクセスを必要とします。代わりにアクティベーショントークンを受け取ります。最初の選択肢は多くの手作業による管理を必要とし、非常に価値の高いソフトウェアにしか価値がありません。2番目の選択肢は、ネットワークアクセスが制限されている場合やファイアウォールの背後にいる場合には偽装されて不愉快になります。
全体として、あなたの顧客と信頼関係を築くのはずっと簡単です。