電子キーセキュリティシステムの進化

この記事は、ハードウェアベースのセキュリティシステムの開発、近年発生した攻撃の種類、およびそれらがどのように抵抗するかについて説明します。 ソフトウェアの保護の程度に直接影響する電子キーの可能性、およびこの技術に固有の主な問題が考慮されます。 この記事の著者は、Guardantプロジェクトの主要な開発者であるActive companyです。



最新の電子キーは、対称暗号方式のキー、非対称暗号方式のキー、およびダウンロード可能なコードのキーに分けられます。 後者のタイプのデバイスでは、より詳細な分析が必要ですが、この記事の範囲を超えています。



コンパイルされたプログラミング言語(C、C ++、Pascal、Delphi、Fortranなど)を使用して開発されたWindowsアプリケーションの保護を検討してください。



プログラムと電子キーの間のデータ交換



信頼できる保護を構築する主な方法は、APIライブラリを使用して電子キーを操作することです。 通常、APIは静的および動的ライブラリの形式で提供されます。



静的ライブラリは、動的ライブラリとは異なり、ビルドプロセス中に実行可能プログラムに参加(リンク)します。 それらの使用が最も好ましい 単純なファイルのなりすましの可能性を排除します。 次に、静的ライブラリを使用するアプリケーションの保護について検討します。



このプログラムは、APIライブラリを介して電子キーとデータを交換します。APIライブラリは、電子キードライバと直接やり取りします。 保護されたプログラムと電子キーの間の典型的な交換スキームを図1に示します。



画像



このようなスキームでの攻撃は、異なる防御モジュール間の相互作用を目的としています。 電子キードライバー(1)またはUSBバスドライバー(2)のレベルで電子キーへの要求をインターセプトする場合、静的APIライブラリー(3)への呼び出しをインターセプトするバージョンとは異なり、アプリケーションの各新しいバージョンを再変更する必要はありません。



電子キードライバーへの攻撃



このタイプの攻撃は最も単純です。 電子キーの元のドライバーは、ドライバーエミュレーターに置き換えられます。 キーに転送されて返されたデータはインターセプトされ、ディスク上のファイルに保存されます。 次に、元のキーがコンピューターから抽出され、プログラムはエミュレーターと対話し始め、キーと通信することを心から信じ続けます。



詳細を見ると、Guardant電子キーのソフトウェアエミュレーターに対する保護について詳しく説明します。 Guardantドングルドライバーには、電子署名(ES)が含まれています。 Guardant API関数を呼び出すとき、保護されたアプリケーションはRAM内のドライバー署名を自動的にチェックします。 秘密キーは不明であるため、正しい署名を使用してドライバーエミュレーターを作成することはできません。 仮想マシン(擬似コード)は、スキャンの使用を防ぎ、ドライバーの実行可能ファイルとGuardant APIライブラリを保護します。 検証スキームを図2に示します。



画像



このような保護を実践した後、ソフトウェアエミュレーターはUSBバスのレベルに移行しました(2番目の攻撃オプション)。



USBバスドライバー攻撃



このようなエミュレータを作成するには、電子キードライバーとUSBバスドライバー間の交換プロトコルを検討する必要がありました。 逆説的に聞こえるかもしれませんが、LPTキーはそのような状況でより信頼できることが判明しました。 ドングルドライバーは、コンピューターのI / Oポートを介してLPTドングルと直接対話し、中間ドライバーをバイパスします。



残念ながら、対称暗号方式のキーを使用してUSBバスレベルでソフトウェアエミュレータを完全に取り除くことは不可能です。 それにもかかわらず、電子キーとの絶え間ない交換に基づいて構築された適切な保護は、キーに対するすべての可能なメッセージと回答を記録し、最も不適切な瞬間に違法ユーザーのために働くために1日以上かかる場合があります。 未知の理由で動作を停止するハッキングされたプログラムは、この確認のみです。



また、開発者が電子キーの存在の単純なチェックに限定されている場合の保護についても言及したいと思います。 これは失敗です。 逆アセンブラを使用すると、このようなプログラムに15分で「独立」を示すことができます。



非対称暗号化を使用した電子キーでは、保護されたプログラムと電子キーの間のデータ交換はセッションキーで暗号化されます。 このため、3番目のオプションが唯一の可能な攻撃です。



API静的ライブラリコールインターセプト攻撃



この攻撃は、非対称暗号方式を使用するキーにとって最も論理的なものです。 電子キーの製造元がライブラリの保護に注意を払った場合にのみお勧めします。そうしないと、ライブラリ自体を攻撃するのがはるかに簡単になります。



最新の逆アセンブラを使用すると、プログラム内のAPI関数をすばやく認識できます。 もしそうなら、すべての関数呼び出しは簡単に傍受できます。 これは、アクセスコード、要求、および応答が依然として脆弱であることを意味します。 また、プログラム開発者自身がAPI関数呼び出しを保護しなかった場合、これが攻撃に最適な場所です。



保護されたプログラムで静的APIライブラリへの呼び出しをインターセプトする可能性を排除するには、主要なアプリケーション関数とAPI関数を1つの全体に結合する必要があります。 そうして初めて、パラメーターの分析、呼び出しのインターセプト、またはAPI関数への要求と応答の変更が本当に難しくなります。 実際には、メインアプリケーションコードが記述された後に保護を開発し始めます。 非常に多くの場合、プログラムと電子キーの間の相互作用を深く統合するのに十分な時間がないか、おそらく望んでいません。 保護の品質を改善する最も時間のかからない方法は、コードの分析を複雑にするソフトウェアツールを追加で使用することです。 この場合、プログラム関数と静的APIライブラリの関数の相互作用は理解しにくくなります。



Guardantドングルに戻ると、すべてのGuardant APIライブラリは、仮想マシンを使用した分析および変更から保護されていると言います。 仮想マシンとは、プログラムの元のバイナリコードから取得した擬似コードと、対応するインタープリターを意味します。 擬似コード命令は、生成されたインタープリターでのみ実行できます。 インタプリタは、複数の整合性制御による修正から疑似コードとそれ自体の命令を保護する責任があります。 すべての命令パラメータ、定数、遷移アドレスは、擬似コードのフラグメントとインタプリタ自体のハッシュで復号化されます。 分析を困難にするために、擬似コードインタープリターはポリモーフィックな難読化によって保護されています。 リストされた特性は、仮想マシンの各コピーに独自の方法で実装されます。



擬似コード保護テクノロジーは、 Guardant Armorサービスを使用するすべてのユーザーが利用できます。 このアプローチにはいくつかの利点があります。保護ツールは絶えず更新されており、研究には利用できません。 同時に、Guardantドングルを使用する開発者には特にメリットがあります。 このサービスにより、Guardant API静的ライブラリー( Guardant Monolithテクノロジー)の機能と同時にプログラム機能を保護できます。 アプリケーション内のGuardant APIライブラリの存在は自動的に判断されるため、アプリケーションの追加の再コンパイルは必要ありません。 その結果、アプリケーションを保護するたびに、命令、定数、難読化によって仮想マシンの一意のコピーが作成され、プログラムのロジックが電子キーライブラリと密接に結び付けられます。 ここで、静的ライブラリへの呼び出しを傍受したり、ライブラリ自体を攻撃したりするには、各防御に個別に対処する必要があります。



画像



これを小さなテストアプリケーションの例で考えてみましょう。そのフラグメントを図4に示します。 この例は、アプリケーション内の静的ライブラリへの呼び出しの脆弱性を非常に明確に説明しています。 問題は、電子キーのすべてのメーカーに関係します。



画像



アプリケーション関数MyLogicAndVerifyDongle



に電子キーを使用したソフトウェア計算が含まれているとします。 この機能なしで作業することは不可能です。 アプリケーションの主要なロジックの一部が含まれています。 この場合、関数呼び出しはプログラムコードの重要度の低い部分から実行されます。 電子キーにアクセスするには、静的なGuardant APIライブラリーへの呼び出しが使用されます。 この例では、これらはGrdRead



およびGrdCrypt



。 各機能の開始時には、保護領域VM_Startへの移行のみがあります。 ただし、 MyLogicAndVerifyDongle



関数MyLogicAndVerifyDongle



は保護されないままであり、攻撃を受けやすい可能性があります。



次に、Guardant Onlineサービスを使用してAPI関数と主要なアプリケーション関数を保護します。 保護されたアプリケーションのフラグメントを図に示します 5。



画像



保護後、 MyLogicAndVerifyDongle



関数には、保護領域Guardant_VirtualMachine



への遷移のみが含まれます。 関数実行可能コードが以前に配置されていたアドレスに、ガベージ命令が表示されます。 関数自体は擬似コードに変換され、Guardant API関数と同じ仮想マシンで実行されます。 次のように、API関数呼び出しにブレークポイントを設定することはできなくなりました 遷移は仮想マシン内に隠されています。 つまり、プログラムをハッキングするには、仮想マシンのロジック全体を解く必要があります。これは、API関数の単純なインターセプトよりもはるかに複雑です。



結論



信頼できる保護を構築するための多くの推奨事項。



1.プログラムで静的APIライブラリを使用する必要があります。 APIライブラリ呼び出しは、保護されたプログラムのロジックと緊密に統合する必要があります-これは、強力な保護の作成を保証します。

2.非対称暗号化を使用したキーを使用することをお勧めします。 彼らにとって、表形式のエミュレータを作成する簡単な方法はありません。

3.アプリケーションコードと静的APIライブラリは、ソフトウェア保護ツールを使用して分析から保護する必要があります。この場合、プログラム内のAPI関数の呼び出しをインターセプトする簡単な機能はありません。 Guardantテクノロジーを使用する開発者にとって、Guardant Monolithは理想的なソリューションです。



All Articles