"}">

プロダクトキー(ソフトウェアキー、シリアルキー、アクティベーションキーとも呼ばれる)は、コンピュータプログラム専用のソフトウェアベースのキーです。これは、プログラムのコピーが正規品であることを証明するものです。
プロダクトキーは、数字や文字、あるいはその両方で構成される文字列です。この文字列は通常、ユーザーがコンピュータソフトウェアのインストール時に入力し、プログラム内の検証機能に渡されます。この検証機能は、アルゴリズムまたは数式に基づいてキー文字列を処理し、有効な解のセットと照合します。ハッシュ関数を用いて文字を数字に変換することもあります。結果が一致すれば、プログラムが有効化され、使用や機能のロック解除が可能になります。プログラムのリバースエンジニアリングなどによってアルゴリズムに関する情報が得られれば、特定のプログラムのキーを生成するキー生成ツール(キーゲン)を作成することが可能です。
標準的なキー生成方法(プロダクトキーを数学的に生成する方法)は、ソフトウェアの著作権侵害を完全に阻止するには不十分です。なぜなら、これらのキーは配布される可能性があるからです。さらに、インターネットの普及による通信技術の向上に伴い、クラック(キーを不要にするツール)やプロダクトキー生成ツールなど、より高度なキー攻撃が一般的になっています。
このため、ソフトウェア発行者は、キーが有効かつ改ざんされていないことを確認するために、追加の製品アクティベーション方法を使用します。1つの方法は、購入者のコンピュータ ハードウェアの固有の機能に基づいて製品キーを割り当てるもので、これはユーザーのハードウェアに依存するため、簡単に複製することはできません。もう1つの方法は、インターネット サーバーで製品キーを一度または定期的に検証することを要求するものです (オンライン コンポーネントを持つゲームの場合は、ユーザーがサインインするたびに実行されます)。サーバーは、無効、重複、欠落、またはその他の改ざんされたキーを提示する、変更されていないクライアント ソフトウェアを非アクティブ化できます。変更されたクライアントはこれらのチェックを回避できますが、サーバーはそれでもそのようなクライアントの情報や通信を拒否できます。[ 1 ]
Windows 95 の小売版プロダクトキーは XXX-XXXXXXX の形式です。[ 2 ]キーが有効かどうかを判断するために、Windows 95 は次のチェックを実行します。
すべてのチェックに合格すれば、プロダクトキーは有効です。したがって、これらの条件下では、000~0000000のプロダクトキーは有効とみなされます。
Windows 95 の OEM キーは、XXXXX-OEM-XXXXXXX-XXXXX の形式です。
Windows XP は、インストール ID、製品 ID、および製品キーを使用してアクティベーションを行います。[ 3 ] [ 4 ]
インストールIDは、50桁の10進数文字列で、6桁ずつ8つのグループに分けられ、各グループの末尾に2桁が付加されます。形式はXXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXです。インストールIDは、msoobe.exeが実行されるたびに再生成されます。
インストールIDの各グループの右端の数字はチェックデジットです。
チェックデジットを削除すると、41桁の10進数エンコードされた136ビットの多倍長整数が得られ、これはバイト配列としてリトルエンディアンのバイト順で格納されます。
インストールIDの下位16バイトは暗号化され、最上位バイトは平文のまま保持されます。インストールIDの暗号化に使用される暗号アルゴリズムは、独自の4ラウンドFeistel暗号です。Feistel暗号に渡される入力バイトのブロックは、同じサイズの2つのブロックに分割されるため、このクラスの暗号は通常、偶数バイトで構成される入力ブロックに適用されます。この場合、17バイトの入力のうち下位16バイトが該当します。暗号のラウンド関数は、4バイトのシーケンスを鍵とするSHA-1メッセージダイジェストアルゴリズムです。
+ は 2 つのバイト シーケンスの連結、^ はXOR演算、L と R は 1 ラウンドの左と右の 8 バイトの入力半分、L' と R' はそのラウンドの出力半分、First-8() は SHA-1 メッセージ ダイジェストの最初の 8 バイトを返す関数を表すものとします。
すると、復号化の1ラウンドは次のようになります。
L' = R ^ First-8(SHA-1(L + Key))
R' = L
復号化の結果は16バイトの平文であり、これに17バイト目の暗号化されていないバイトが加わります。この17バイト目のバイトは、リトルエンディアンのバイト順で4つのダブルワードとそれに続く1バイトとして解釈されます。
H1とH2は、インストールIDに関連付けられているハードウェア構成を指定します。P1とP2、および残りのバイトP3には、インストールIDに関連付けられた製品IDが含まれます。
製品IDは、AAAAA-BBB-CCCCCC-DDEEEのように、5つのグループの10進数で構成されます。
10進数表現の製品IDと、ダブルワードP1およびP2、バイトP3におけるそのバイナリエンコーディングとの間のマッピングを、以下の表にまとめます。
プロダクトキーは XXXXX-XXXXX-XXXXX-XXXXX-XXXXX の形式です。各文字は、次の 24 種類の英数字のいずれかです: BCDFGHJKMPQRTVWXY 2 3 4 6 7 8 9
プロダクトキーの25文字は、プロダクトキーのバイナリ表現を24進数でエンコードしたものです。プロダクトキーは、約115ビットの多倍長整数で、15バイトの配列にリトルエンディアン形式で格納されます。この15バイトのうち、最下位4バイトには、リトルエンディアン形式の生プロダクトキーが格納されます。最下位ビットは、この32ビット値を1ビット左にシフトすることで削除されます。残りの11バイトはデジタル署名を構成し、ハードコードされた公開鍵を使用してプロダクトキーの真正性を検証できます。
CCCCCCC コンポーネントを取得するには、チェックデジットが付加されます。チェックデジットは、チェックデジットを含むすべての桁の合計が 7 で割り切れるように選択されます。プロダクトキーの検証には、複数の公開鍵が利用可能です。最初の公開鍵での検証が失敗した場合は、2 番目の公開鍵が試行され、以降同様に繰り返されます。プロダクト ID の DD コンポーネントは、このシーケンス内のどの公開鍵がプロダクトキーの検証に正常に使用されたかを示します。
インストールIDに関連付けられたハードウェア構成は、H1とH2という2つのダブルワードで表されます。このため、ダブルワードは12個のビットフィールドに分割されます。
ドッキングが可能な場合、アクティベーション機構は将来のハードウェア変更に対してより寛容になります。残りの 10 ビットフィールドのいずれかに対応するハードウェア コンポーネントが存在する場合、対応するビットフィールドには、そのコンポーネントを表すゼロ以外の値が含まれます。値がゼロの場合は、ハードウェア コンポーネントが存在しないことを示します。すべてのハードウェア コンポーネントは、レジストリから取得したハードウェア識別文字列によって識別されます。この文字列をハッシュ化することで、対応するビットフィールドの値が得られます。
ハッシュ結果は、ハードウェア識別文字列をMD5メッセージダイジェストアルゴリズムに入力し、結果として得られるメッセージダイジェスト内の所定の位置からビットフィールドに必要なビット数を選択することによって得られます。異なるビットフィールドには、異なる所定の位置が使用されます。さらに、ハッシュ結果がゼロにならないように、ここで、BitFieldMax は、対象となるビットフィールドに格納できる最大値(例えば、10 ビットのビットフィールドの場合は 1023)であり、「x % y」は x を y で割った余りを表します。これにより、1 から BitFieldMax までの値が得られます。得られた値は、それぞれのビットフィールドに格納されます。
オペレーティングシステムが利用できるRAMの量に関連するビットフィールドは、表に示すように、他のビットフィールドとは異なる方法で計算されます。
なお、RAMの容量はGlobalMemoryStatus()関数を呼び出すことで取得されますが、この関数が報告する値は、実際に物理的にインストールされているRAMの容量よりも数百キロバイト少なくなります。そのため、128MBのRAMは通常「64MB~127MB」と分類されます。
wpa.dblは、RC4で暗号化されたデータベースであり、有効期限情報、アクティベートされたインストールの確認ID、現在のハードウェア構成を表すビットフィールド値、製品アクティベーション時のハードウェア構成を表すビットフィールド値などが格納されています。現在のハードウェア構成は、ハードウェア構成が変更されるたびに変更を反映するために自動的に更新されますが、製品アクティベーション時のハードウェア構成を表す値は固定されています。再アクティベーションが必要かどうかを判断する際には、現在のハードウェア構成のビットフィールド値とアクティベーション時のハードウェア構成のビットフィールド値を比較します。
未使用フィールドと「ドッキング可能」フィールドを除くすべてのビットフィールドが比較されます。製品のアクティベーション以降、現在のハードウェア構成において、これら10個のビットフィールドのうち3個以上が変更されている場合、再アクティベーションが必要です。
H2のビット31が、コンピュータがドッキングステーションをサポートしていることを示している場合、前述の10個のビットフィールドのうち7個のみが比較されます。SCSIホストアダプタ、IDEコントローラ、およびグラフィックボードに対応するビットフィールドは除外されます。残りの7個のビットフィールドのうち、再アクティベーションを必要とせずに変更できるのは最大3個までです。
最も効果的なプロダクトキー保護の中には、不便さ、厳格な適用、厳しい罰則、そして場合によっては誤検出といった理由から、物議を醸すものもある。一部のプロダクトキーは、ライセンス契約を遵守させるために、妥協のないデジタル手順を採用している。
プロダクトキーはエンドユーザーにとって少々不便です。プログラムをインストールするたびに入力する必要があるだけでなく、紛失しないように注意しなければなりません。プロダクトキーを紛失すると、アンインストール前にキー回復アプリケーションを使用しない限り(ただし、すべてのプログラムがこれに対応しているわけではありません)、通常はアンインストール後にソフトウェアが使用できなくなります。[ 5 ]
プロダクトキーは、流通がうまくいかない新たな原因にもなり得る。キーが欠落していたり無効だったりすると、製品自体が役に立たなくなる。例えば、オーストラリアに出荷された『スプリンターセル パンドラトゥモロー』は、当初はプロダクトキーが同梱されていなかった。[ 6 ]
利用違反を検知した企業による永久追放措置は数多く存在する。オンラインシステムでは、クラックやチート行為を行ったアカウントを即座にブラックリストに登録するのが一般的で、その結果、永久追放となる。ソフトウェアの使用を継続したいプレイヤーは、再度購入する必要がある。こうした永久追放措置の動機について、批判の声が上がっているのは当然と言えるだろう。
特に議論の的となっているのは、複数の製品のキーが紐付けられている場合です。製品が他の製品に依存している場合(拡張パックの場合など)、企業が紐付けられたすべての製品を禁止するのはよくあることです。たとえば、拡張パックで偽のキーが使用されると、サーバーは元のゲームの正規のキーを禁止する可能性があります。同様に、ValveのSteamサービスでは、ユーザーが購入したすべての製品が1つのアカウントに紐付けられています。このアカウントが禁止されると、ユーザーは同じアカウントに関連付けられているすべての製品にアクセスできなくなります。[ 7 ]
この「複数禁止措置」は、ユーザーが正当に購入し使用した製品の使用を禁止するものであるため、非常に物議を醸している。
クラックやチートが検出されると、サーバーは直ちにBAN措置を講じ、通常は人間の介入なしに実施します。正当なユーザーが誤ってライセンス違反とみなされ、BANされることもあります。誤検出が多数発生した場合、修正されることもあります(World of Warcraft [ 8 ]のように) 。ただし、個々のケースは特に注意を払われない場合もあります。
誤検出の一般的な原因(上記のWorld of Warcraftのケースと同様)は、サポートされていないプラットフォームのユーザーです。たとえば、LinuxユーザーはWineやCedegaなどの互換レイヤーを介してWindowsアプリケーションを実行できます。このソフトウェアの組み合わせがゲームサーバーのアンチチートソフトウェアをトリガーし、WineやCedegaがLinux用のWindows API互換レイヤーであるため、ゲームサーバーによってサードパーティ(チート)ソフトウェアとみなされ、BANされることがあります。[ 9 ]