Javaスマートカードを使用してソフトウェアを保護する。 第5章セキュリティ

画像



このシリーズの記事では、ソフトウェアを保護するためのJavaスマートカード(電子キーの安価なアナログ)の使用について説明します。 サイクルはいくつかの章に分かれています。



記事の情報を読んで理解するには、次のスキルが必要です。



サイクルの目標は、読者にJavaマップを紹介することです(ロシア語での使用に関する文献はほとんどありません)。 このサイクルは、「Javaマップに基づくソフトウェア保護の開発のためのガイドライン」のステータスや「Javaマップへのガイド」のタイトルを主張していません。



サイクルの構成:







90%のケースでは、次のすべてのプロパティを持つようなアルゴリズムを思い付くことができません。



これらの90%に該当する場合、間違いなく次のことを行う必要があります。



1.カードとのデータ交換の暗号化



強力な保護を構築する場合は、トラフィック暗号化キーを変更する必要があります。 少なくともアプリケーションを起動するたびに、新しいキーを生成する必要があります。 セッションキーは、カードとプログラムによって提供されるデータに基づいて生成する必要があります。 保護されたセッションのメカニズムは、 プリミティブバージョンでは次のようになります。







注意! 説明されているとおりに実行しないでください。



解読されたデータがカードにとって正しくないと思われる場合、ブロックする必要があります。 このようなオプションを実装する最も簡単なオプションは、アプレットクラスにCardIsLockedブール型フィールドを設定し、渡されたコマンドコードに対応するメソッドを呼び出す前に、プロセスメソッドでその内容を確認することです。 CardIsLockedの場合-ソフトウェアにデータの代わりにエラーを返します。



2. Themidaの機能の使用



Themidaは、プロテクターを削除するのが最も難しいものの1つと当然考えられています。 ただし、プロジェクターを上から吊るすだけでは不十分です。 本当に信頼できる保護を構築する場合は、Themida APIを最大限に使用する必要があります。





3.暗号トラップ。 あなたを待っている数百万人のうちの数人。



暗号化を使用する場合、自分が何をしているか、何ができるか、何ができないかを理解することが重要です。 もちろん、スマートカードでコンソールテトリスを保護している場合は、何でも買うことができます。 しかし、このテトリスが一意であり、明日100万ドルをもたらす場合...そして、たとえば、特定のDESキーで特定の初期化ベクトルを使用したら、再度それをしないでください。



独自の極秘非公開の独自の暗号化およびハッシュアルゴリズムを発明しないでください。 GSM A5 / 3暗号の運命と、それらがスーパークリプトグラフであると決定した貧しい著者たちを思い出してください。



超耐性のセキュリティシステムを設計するときは、BS-Clientに基づく銀行のクライアントのように丸い穴を残さないでください。



4.患者の読者のおかげで



この場所を読んでくれたみんなに感謝します。 感謝とresみが受け入れられます。



コメント内の質問に喜んで対応し、回答が含まれるように記事を更新してみます。



All Articles