ミニ証明書で信頼を獲得
「私のインストールパッケージには、1つのアプリケーションと多くのライブラリが含まれています。ハッカーが個々のライブラリ、特にlicense.dllを置き換えるのを防ぐ必要があります。チェックサムを使うのも手かもしれないが、パッケージ全体を再コンパイルして配布し直さなければいけません。」これは、世界中のソフトウェア開発者が直面する典型的な問題です。この課題、あるいはシリアル番号の安全なチェックのような同様の問題に対する彼らの答えは、通常、ミニ証明書です。どんなことができるのでしょうか？
単純なチェックサム
チェックサムは、任意の長さのデータ文字列を1つの数値に変換する関数の最終結果です。データが変更された場合、チェックサムも変更されます。代表的なものにCRCやModulo演算があり、データ入力や送信時のミスを防止・低減するために頻繁に使用されます。クレジットカード番号やIBAN番号にはチェックサムがついており、銀行や小売店、サービスプロバイダーにデータが送信される前に、システムが不正な入力に気づくことができるようになっています。
暗号化チェックサム
単純なチェックサムでは、悪意ある行為に対する有効な防御とはなりません。効果的な不正防止には、基礎となるデータのわずかな変更に対応して大幅に変化する暗号チェックサムが必要です。例えば、同じチェックサムになるまで空白を追加するなど、チェックサムそのものが変化しないようにデータを操作することは不可能です。暗号チェックサムとして現在よく使われているのはSHA256で、過去によく使われていたMD5は現在では安全でないと考えられています。
暗号化チェックサムには限界があります。チェックサムをテストするためには、チェックサムが最初に作成されたときと同じ情報、つまり関数そのものと、共有秘密としてオプションのソルト値が必要です。この情報は、チェックサムがテストされるソフトウェアに保存されている必要があります。もし、たった一人の攻撃者がこの情報を入手することに成功すれば、システム全体が危険にさらされます。なぜなら、オリジナルとは別に、決して識別できない有効なチェックサムが作成されてしまう可能性があるからです。
この概念上の制約から、異なるライブラリのチェックサムを別のライブラリに保持したり、コアアプリケーションに保持したりと、迷宮入りの構造になっており、知らず知らずのうちに、先に述べたソフトウェアパッケージ全体のアップデートの問題を引き起こしているのです。
非対称暗号
非対称暗号方式は、秘密鍵と公開鍵のペアで構成され、秘密鍵は秘密にして、公開鍵は公開することで解決します。秘密鍵はその正当な所有者のみが署名に使用でき、公開鍵はその署名を確認するために誰でも使用することができます。しかし、公開鍵を持っているからといって、誰でも有効な署名を作成できるわけではありません。
非対称暗号は通常、ある程度の大きさのデータを必要とするため時間と手間がかかることから、暗号チェックサムと組み合わせて使われることが多いです。まず、データのチェックサムを作成し、秘密鍵で署名します。後のテストのために、再度同じチェックサムを作成し、公開鍵と署名に対してテストします。この分野では、ECDSAやRSAが確立されたプロセスです。
基本的なツール
ここでは、私たちのライブラリやアプリケーションに署名するための基本的なツールキットを説明します。開発プロセスの最初のステップとして、公開鍵がソフトウェアに含まれています。
コンパイル後、秘密鍵は各モジュール（ライブラリやアプリケーション）の署名を作成するために使用されます。署名はモジュールと一緒に、別ファイルまたはリソースセクションの専用場所に納品されます。
テスト時には、リソースに含まれる可能性のある署名をスキップしてチェックサムを再度作成します。作成されたチェックサムは、署名と公開鍵と照合されます。
1つの署名では不十分
しかし、将来は、予想しなければならない新たな課題をもたらすかもしれません。開発者は、まだ存在しない問題を解決しようとしないことを求めるクリーンコードの原則と決別し、セキュリティ開発者は常に2歩先を考えるべきです。
- 秘密鍵が盗まれても大丈夫なようにしたいのか？
- 複数の開発者にモジュールに署名する機能を持たせるか？
- ビジネスパートナーからのモジュールは、私たちの製品群に含めるべきでしょうか？
- テスト用と運用向けのシステムは完全に分けるべきですか？
このようなケースは、事実上ミニ証明書にとって最適です。ミニ証明書は基本的に、一つの公開鍵、定義された一連の権利（フラグ）、公開鍵に対する署名を含んでいます。X.509証明書の例をモデルにしていますが、より無駄がなく、自分で定義したバイナリ形式で簡単に使うことができます。
ミニ証明書を取得する方法
最初のステップでは、新しいキーペア、いわゆる「ルート」キーを作成します。公開鍵は再びソフトウェアに統合されます。同時に、別の秘密鍵ペアを作成し、ルート鍵の秘密鍵を使用して、新しいペアの公開鍵のミニ証明書を作成します。その後、プライベート・ルート・キーはロックされ、侵入不可能となり、不正なアクセスから保護されます。専門家は、ハードコピーとデジタルコピーの2つを別々の場所に保管することを推奨しています。プライベート・ルート・キーは、この時点以降、ほとんど必要とされないからです。
その後、新しい秘密鍵を使用して、作成したモジュールにルーチン的に署名します。新しい公開鍵のミニ証明書をモジュールに追加し、証明書と公開ルート鍵、保護されたデータの署名とミニ証明書の公開鍵を比較するチェックを行います。
より多くのリンク、より強力なチェーン–証明書のチェーン
この方式では、ルート鍵ペアとアクティブに使用する鍵ペアの2つの階層があり、これが推奨される最小限のセットを形成することになります。2つ目の秘密鍵が3つ目の鍵ペアの公開鍵に署名し、最終的に暗号木全体に成長するように、システムには2つ以上の階層を簡単に含めることができます。設定したフラグに応じて、より多くのミニ証明書を割り当てるなどして権利を継承させることができます。
追加のキー
秘密ルート鍵が再び必要になるのは、追加の鍵を作成したり、古い鍵を削除したりする場合だけです。プロセスで2つ以上の階層を使用する場合、その可能性はさらに低くなります。この場合、ルート鍵が再び使用されるのは、第2層の鍵が追加または削除される場合だけです。
キーの削除
キーを削除する方法は2つあります。
- 失効リスト
- 証明書の自動有効期限
失効リストには、無効な証明書がすべて記録される。このリストにアクセスできないデバイス（オフラインのためなど）は、古い無効な証明書でまだ動作することになります。これを防ぐために、自動期限切れで証明書の更新を強制します。本質的には、カバーしたいデバイスに必要なデータの転送でしょう。2つの可能な戦略の選択は、「信頼性第一」か「セキュリティ第一」かの選択であるべきです。
安全なシリアル番号チェック
ミニ証明書は、シリアル番号を安全にチェックするのにも適しています。CmDongle はキーペアを与えられ、プライベート・ルート・キーは公開キーのミニ証明書を作成するために使用されます。これは、例えばCmDongle上の拡張保護されたデータとして、ユーザーに配信されます。
テストシステムは、CmDongleが秘密鍵で署名するいわゆるチャレンジを作成します（より具体的には、両側がそれぞれチャレンジの一部を作成します）。チャレンジに対するレスポンスとミニ証明書が送り返され、公開ルート鍵でミニ証明書をテストし、レスポンスがチャレンジと一致することを含有鍵で確認します。すべてがうまくいけば、CmDongleのアイデンティティは証明されたとみなされます。
このプロセスは、FlexnetのセキュアIDや、サービスネットワークにおけるレーザー機器のセキュア認証など、IDの確認にすでに頻繁に使用されています。
整合性保護の使用例
この技術は、安全なIDの証明として機能するだけでなく、モジュールの交換やその他の変更からモジュールを保護するために主に使用されます。license.dll は、ライセンスが利用可能であるかのようにデバイスを騙す偽の .dll と置き換えることはできないのです。このシステムは、ライセンスをカプセル化するためのエレガントで使いやすい手段ですが、Wibu-Systemsでは、各モジュールをCodeMeter Protection Suiteで自動的に保護し、そこにライセンスチェックを統合することを今でも推奨しています。CodeMeter Protection Suiteがどのようにソフトウェアの保護を強化するかは、「ソフトウェアの自動保護」で概説しています。
KEYnote 36 – Edition Fall 2018