System and method to protect java bytecode code against static and dynamic attacks within hostile execution environments
Abstract
This record has no abstract on file.
Term
Projected expiry 12 November 2030.
- Priority
- Filed
- Granted
- Today
- Projected expiry
49 claims: 17 independent, 32 dependent
- 1Javaバイトコードのタンパリング耐性を向上させるためのシステムであって、1つまたは複数のプロセッサと、前記1つまたは複数のプロセッサの少なくとも1つに操作可能に結合され、前記1つまたは複数のプロセッサの少なくとも1つに実行された際に、前記1つまたは複数のプロセッサの少なくとも1つに、以下の処理を実行させる命令を格納した、1つまたは複数のメモリと、 前記処理は、安全なJavaバイトコードと対応するセキュリティ情報を生成するために、構築時、Javaバイトコードに対して保護を適用することと、前記安全なJavaバイトコードの少なくとも一部をJavaヴァーチャルマシン(JVM)にロードすることと、 前記安全なJavaバイトコードのロード時と実行時にJavaネイティブインタフェース(JNI)ブリッジを介して前記JVMと通信するために、デプロイ時に実行するよう構成されたソフトウエアモジュールを含むセキュリティモジュールに、前記対応するセキュリティ情報をロードすることと、 1つまたは複数の保護機構を介して、前記Javaバイトコードのローディングと実行の間、前記Javaバイトコードへの静的および動的攻撃に対抗すること、とを含み、 前記1つまたは複数の保護機構の少なくとも1つは、前記セキュリティモジュールに組み込まれ、前記静的および動的攻撃は、前記セキュリティモジュールにロードされた前記対応するセキュリティ情報の少なくとも一部に基づいて対抗され、前記セキュリティモジュールは、前記JVMと共に前記JNIブリッジを介して前記安全なJavaバイトコードと共に実行されるよう構成されている、システム。
- 2前記Javaバイトコードが、構築時、複数の部分に分けられ、実行時、前記複数の部分が前記JVMの異なる部分におよび前記セキュリティモジュールに対して実行される、請求項1に記載のシステム。
- 3前記安全なJavaバイトコードが、被保護Javaアプリケーションバイトコードスタブ、被保護アプリケーションペイロード、および暗号化されたクラスバイトコードフレームを含む、請求項1に記載のシステム。
- 4前記被保護Javaアプリケーションバイトコードスタブを介して、前記被保護アプリケーションペイロードが起動される、請求項3に記載のシステム。
- 5前記セキュリティモジュールが、被保護バイトコードクラスローダを含み、前記被保護バイトコードクラスローダを使用して前記暗号化クラスバイトコードフレームにより前記被保護アプリケーションペイロードが起動される、請求項3または4に記載のシステム。
- 6前記セキュリティモジュールが、JVM環境への機能的延長部であり、被保護Javaアプリケーションの信頼の基礎を提供するよう構成され、かつ、複数の異なる安全なJavaバイトコードに整合するよう構成されている、請求項1に記載のシステム。
- 7前記セキュリティモジュールがローカルハードウェアごとの保護技術およびシステムを適用するネィティブプログラミング言語で書かれる、請求項1から6のいずれかに記載のシステム。
- 8前記セキュリティモジュールが、ローカルネィティブソフトウェアごとの保護技術およびシステムを適用するネィティブプログラミング言語で書かれる請求項1から6のいずれかに記載のシステム。
- 9前記セキュリティモジュールが、ホワイトボックスセキュリティ技術を用いて保護される、請求項1から6のいずれかに記載のシステム。
- 10前記1つまたは複数の保護機構中の少なくとも1つの保護機構のパラメータが、ユーザの好みにより構成可能で、かつ、前記ユーザの好みに従って前記安全なJavaバイトコードが生成される、請求項1から9のいずれかに記載のシステム。
- 11前記1つまたは複数の保護機構中の少なくとも1つの保護機構が前記Javaバイトコードの実行の一部を前記セキュリティモジュールへ移動させ、それにより前記JVMが実行時に前記Javaバイトコードのすべてを実行するわけではなくなり、元のJavaバイトコードが、JVM上で完全に観察可能にはならない、請求項10に記載のシステム。
- 12前記1つまたは複数の保護機構中の少なくとも1つの保護機構が、前記Javaバイトコードの選択されたメソッドを、JVMには直接可視的でなく、セキュリティモジュールによってのみ起動可能であるネィティブ形式の機能に変換する、請求項10に記載のシステム。
- 13前記1つまたは複数の保護機構中の少なくとも1つの保護機構が前記Javaバイトコードに対してデータフロー変換を行い、機能性を変更することなしに、前記Javaバイトコードのコード構造を変換する、請求項10に記載のシステム。
- 14前記1つまたは複数の保護機構中の少なくとも1つの保護機構が、前記Javaバイトコードに対する制御フロー変換を行い、機能性を変更することなく前記Javaバイトコードのコード構造を変換する、請求項10に記載のシステム。
- 15前記セキュリティモジュールが、実行されるべきJavaバイトコードを、JVMの作業空間内にジャストインタイムでロードしかつ復元し、かつその後実行後の復元したJavaバイトコードを除去する、請求項10に記載のシステム。
- 16前記1つまたは複数の保護機構中の少なくとも1つの保護機構が、アンチデバッギングモニタリングを行う、請求項1から10のいずれかに記載のシステム。
- 17前記少なくとも1つの保護機構が、 カーネルからのそれ自らのプロセスマップを周期的にチェックし、 防御アクションをトリガすることによりそのメモリ空間内へロードされるJavaのデバッギングに関連するライブラリに応答する、請求項16に記載のシステム。
- 18前記応答が、 防御アクションをトリガすることにより、そのメモリ空間内へロードされるJDPA(Java Platform Debug Architecture)に関連するライブラリに応答するステップを含む、請求項17に記載のシステム。
- 19前記応答が、 防御アクションをトリガすることにより、そのメモリ空間内へロードされるJVMTI(Java Virtual Machine Tool Interface)に関連するライブラリに応答するステップを含む、請求項17に記載のシステム。
- 20前記少なくとも1つの保護機構が、デバッギングスレッドの起動を監視し、かつ 防御アクションをトリガすることにより起動されるデバッギングスレッドに応答する、請求項16に記載のシステム。
- 21前記少なくとも1つの保護機構が、デバッギングツールにより実行されるラインブレークメッセージを監視し、かつ 防御アクションをトリガすることによりラインブレークメッセージの検出に応答する、請求項16に記載のシステム。
- 22前記1つまたは複数の保護機構は、ホウイトボックス(WB)静的セキュリティハンドラを含み、 前記WB静的セキュリティハンドラは、 ユーザからの暗号キーを含む暗号情報を受けて、 構築時に使用されるWB暗号化キーデータと、 実行時、前記セキュリティモジュールにより使用されるWB復号化キーデータおよびWBセキュリティモジュールユーティリティとを生成するものである、請求項1から10のいずれかに記載のシステム。
- 23前記1つまたは複数の保護機構中の少なくとも1つの保護機構が、バイトコード完全性検証(BIV)システムを含み、 構築時に前記安全なJavaバイトコードのハッシュ値が計算され、かつ、 前記タンパリング耐性セキュリティモジュールが、前記構築時ハッシュ値が実行時に計算される前記ハッシュ値に等しいかどうか決定し、前記セキュリティモジュールが、検証失敗に応答してタンパリング対抗策を起動する、請求項1から10のいずれかに記載のシステム。
- 24前記セキュリティモジュールが、 前記JVMで、インタフェースを介してJavaバイトコードを入手し、 前記バイトコードの動的ハッシュ値を計算し、 前記構築時ハッシュ値が実行時に計算した前記ハッシュ値に等しいかどうか決定し、等しくない場合にはタンパリング抵抗策を起動するよう動作することができる、請求項23に記載のシステム。
- 25前記ハッシュ値検証が、タンパリング耐性ゲートキーパーにより行われる、請求項24に記載のシステム。
- 26前記ハッシュ値検証が、構築時と実行時のハッシュ値を明示的に比較することなしに行われる、請求項24に記載のシステム。
- 27前記ハッシュ値検証が、前記Javaバイトコードの選択されたクラスおよびメソッドに対してのみ行われる、請求項25に記載のシステム。
- 28前記ハッシュ値検証ならびに選択されたクラスおよびメソッドに関連するデータが暗号化される、請求項27に記載のシステム。
- 29静的ハッシュ値が、異なるキーデータを使用したWBサイファーにより暗号化される、請求項27に記載のシステム。
- 30BIVシステムが閉じる際に、前記セキュリティモジュールが、BIVシステムにより使用された関連のメモリ空間および他の情報をクリーンにする、請求項27に記載のシステム。
- 31前記1つまたは複数の保護機構が、構築時、被保護Javaアプリケーションバイトコードスタブ、被保護アプリケーションペイロード、および暗号化クラスバイトコードフレームを生成するためのセキュアローディングバイトコード(SLB)ツールを含み、 前記セキュリティモジュールが、SLB動的セキュリティハンドラを含み、このSLB動的セキュリティハンドラが、 前記安全なJavaアプリケーションバイトコードに対応する前記暗号クラスバイトコードフレームをメモリバッファへロードし、 前記暗号化クラスに対応するホワイトボックス被保護復号化キーデータを介して前記暗号化クラスバイトコードフレーム内に含まれる各暗号化クラスを復号化し、かつ 各復号化したクラスバイトコードを、セキュリティモジュールクラスローダーによりアプリケーション作業空間へロードして、前記アプリケーション作業空間内の前記Javaアプリケーションバイトコードを実行するためのものである、請求項1から10のいずれかに記載のシステム。
- 32前記安全なJavaバイトコードの実行時のどの時点においても、当該安全なJavaバイトコードの一部のみが、復号された形式で格納される、 請求項1から10のいずれかに記載のシステム。
- 33Javaバイトコードのタンパリング耐性を向上させるために、1つまたは複数のコンピュータデバイスで実行される方法であって、前記1つまたは複数のコンピュータデバイスの少なくとも1つにより、構築時に、Javaバイトコードに保護を適用して安全なJavaバイトコードと対応するセキュリティ情報とを生成するステップと、前記1つまたは複数のコンピュータデバイスの少なくとも1つにより、前記安全なJavaバイトコードの少なくとも一部をJavaヴァーチャルマシン(JVM)にロードするステップと、 前記安全なJavaバイトコードのロード時と実行時にJavaネイティブインタフェース(JNI)ブリッジを介して前記JVMと通信するために、前記1つまたは複数のコンピュータデバイスの少なくとも1つにより、デプロイ時に実行するよう構成されたソフトウエアモジュールを含むセキュリティモジュールに、前記対応するセキュリティ情報をロードするステップと、 前記1つまたは複数のコンピュータデバイスの少なくとも1つにより、1つまたは複数の保護機構を介して、前記Javaバイトコードのローディングと実行の間、前記Javaバイトコードへの静的および動的攻撃に対抗するステップ、とを含み、 前記1つまたは複数の保護機構の少なくとも1つは、前記セキュリティモジュールに組み込まれ、前記静的および動的攻撃は、前記セキュリティモジュールにロードされた前記対応するセキュリティ情報の少なくとも一部に基づいて対抗され、前記セキュリティモジュールは、前記JVMと共に前記JNIブリッジを介して前記安全なJavaバイトコードと共に実行されるよう構成されている、方法。
- 34前記Javaバイトコードが、構築時、複数の部分に分けられ、実行時、前記複数の部分が前記JVMの異なる部分におよび前記セキュリティモジュールに対して実行される、請求項33に記載の方法。
- 35前記安全なJavaバイトコードが、被保護Javaアプリケーションバイトコードスタブ、被保護アプリケーションペイロード、および暗号化されたクラスバイトコードフレームを含む、請求項33に記載の方法。
- 36前記被保護Javaアプリケーションバイトコードスタブを介して、前記被保護アプリケーションペイロードが起動される、請求項35に記載の方法。
- 37前記セキュリティモジュールが、被保護バイトコードクラスローダを含み、 前記被保護バイトコードクラスローダを使用して前記暗号化クラスバイトコードフレームにより前記被保護アプリケーションペイロードが起動される、請求項35または36に記載の方法。
- 38前記セキュリティモジュールが、JVM環境への機能的延長部であり、被保護Javaアプリケーションの信頼の基礎を提供するよう構成され、かつ、複数の異なる安全なJavaバイトコードに整合するよう構成されている、請求項33に記載の方法。
- 39前記セキュリティモジュールがローカルハードウェアごとの保護技術およびシステムを適用するネィティブプログラミング言語で書かれる、請求項33から38のいずれかに記載の方法。
- 40前記セキュリティモジュールが、ローカルネィティブソフトウェアごとの保護技術およびシステムを適用するネィティブプログラミング言語で書かれる、請求項33から38のいずれかに記載の方法。
- 41前記セキュリティモジュールが、ホワイトボックスセキュリティ技術を用いて保護される、請求項33から38のいずれかに記載の方法。
- 42前記1つまたは複数の保護機構中の少なくとも1つの保護機構のパラメータが、ユーザの好みにより構成可能で、かつ、前記ユーザの好みに従って前記安全なJavaバイトコードが生成される、請求項33から41のいずれかに記載の方法。
- 43前記1つまたは複数の保護機構中の少なくとも1つの保護機構が前記Javaバイトコードの実行の一部を前記セキュリティモジュールへ移動させ、それにより前記JVMが実行時に前記Javaバイトコードのすべてを実行するわけではなくなり、元のJavaバイトコードが、JVM上で完全に観察可能にはならない、請求項42に記載の方法。
- 44前記1つまたは複数の保護機構中の少なくとも1つの保護機構が、前記Javaバイトコードの選択されたメソッドを、JVMには直接可視的でなく、セキュリティモジュールによってのみ起動可能であるネィティブ形式の機能に変換する、請求項42に記載の方法。
- 45前記1つまたは複数の保護機構中の少なくとも1つの保護機構が前記Javaバイトコードに対してデータフロー変換を行い、機能性を変更することなしに、前記Javaバイトコードのコード構造を変換する、請求項42に記載の方法。
- 46前記1つまたは複数の保護機構中の少なくとも1つの保護機構が、前記Javaバイトコードに対する制御フロー変換を行い、機能性を変更することなく前記Javaバイトコードのコード構造を変換する、請求項42に記載の方法。
- 47前記セキュリティモジュールが、実行されるべきJavaバイトコードを、JVMの作業空間内にジャストインタイムでロードしかつ復元し、かつその後実行後の復元したJavaバイトコードを除去する、請求項42に記載の方法。
- 48前記1つまたは複数の保護機構中の少なくとも1つの保護機構が、アンチデバッギングモニタリングを行う、請求項33から42のいずれかに記載の方法。
- 49少なくとも1つのコンピュータ読取り可能な記録媒体であって、1つまたは複数のコンピュータデバイスで実行されたときに、前記1つまたは複数のコンピュータデバイスの少なくとも1つに、請求項33から48のいずれかに記載の方法を実行させるコンピュータ読取り可能な命令を記録した、記録媒体。
Independent claims49
109 paragraphs, as filed
The present invention relates generally to computer software, and more particularly to methods and systems that make computer software resistant to static and dynamic attacks within a malicious execution environment.
In the computer programming industry, the Java programming language is used in all major industrial fields and exists within a wide range of devices, computers and networks. Java applications are written in the Java programming language and compiled into non-existing bytecode that runs on the Java Virtual Machine (JVM). The JVM is a host operating system (OS, Operating System) and a host computer processing unit (CPU, Computer Processing Unit) instruction set architecture (ISA, Instruction Set). Deployed on Archtecture). Java technology has become an ideal technology for network computing due to its versatility, efficiency, platform portability and security. The Java programming language is used in everything from laptops to data centers, game consoles to scientific supercomputers, and mobile phones to the Internet. In fact, portability, scalability, versatility and reliability are Java's key strengths. However, such ubiquity also provides ample opportunity for hackers and related computer attacks.
To prevent attacks and unauthorized access to the Java environment by untrusted applications, Java technology is used on host machines or devices where contaminated software such as viruses and malware can be illegally downloaded or installed. Includes a sandbox security model to protect the execution environment. Preventing such malicious attacks designs critical applications that normally run on highly protected environments and systems such as telecommunications systems, transportation systems, defense systems, industrial automation systems and power management systems. It is indispensable to do. Every year, these important systems are designed and realized one after another using the Java programming language.
Similarly, the consumer electronics industry is entering a new era, with demands for advanced technology and products, rapid media digitization, and continuing declines in consumer electronics prices, leading to rising disposable income in emerging markets. Together, they are accelerating the growth of the consumer electronics market at unprecedented speed and range. Many of these consumer electronics products rely on software applications to function. More because the strengths of some Java programming languages (portability, scalability, versatility, reliability and convenience, etc.) reduce the overall development and deployment costs of consumer electronics products. Java-based platforms and applications are guaranteed to be deployed in new consumer products.
Almost all consumer electronics need to work in untrustworthy environments. In an unreliable environment, software in consumer electronics can be accessed directly for a variety of purposes, from useful reasons (such as receiving necessary services) to undesired reasons (such as hacking the device). As a result, more computer applications run in relatively malicious environments than ever before. For example, areas such as mobile devices (mobile media players or smartphones, etc.), home networking (set-top boxes, media players, computers, etc.) and web-based environments are areas where attackers often spend a lot of resources for long periods of time. is there. Therefore, protecting legitimate software from attacking software is becoming an intensifying arms race. What's more, high-performance hardware and complex attack tools give intruders many new advantages.
Software distributors need to ensure that their software is robust and resistant to attacks. However, a given platform and software is often well known to attackers who have all the time, resources, tools and free-use web professionals. An environment of such malicious attacks is often referred to as a "white box" environment, in which all content is exposed and therefore subject to direct access and tampering. This is the opposite of a "black box" environment, which is a trusted and protected environment where the content is hidden or protected from attack. In the malicious environment of the mainstream white box environment, preventing or stopping direct and automatic attacks on software systems is becoming one of the most severe security issues. In addition, it is necessary to provide strong protection against white box attacks and ensure proper and secure device functions. The Java programming language is not well designed to address these security issues and challenges. In this regard, in fact, some Java strengths pose security vulnerabilities compared to programming with C or C ++.
Unlike the C / C ++ compiler, which works on raw binary data and compiles C / C ++ code into a specific low-level instruction set on the target hardware (x86 or power PC, etc.), the Java compiler is the Java source code. To a higher level of portable bytecode that works with classes and primitive types that Java can translate at runtime. Platform dependencies are encapsulated within the JVM and decoupled from the Java application.
Moreover, standard Java compilers do not perform the compile-time optimizations common to and commonly found in C / C ++ compilers. Instead, Java relies on just-in-time (JIT, Just-In-Time) compilation to perform all run-time optimizations, taking into account execution profiles for better performance. The main C / C ++ code optimizations are performed at compile time. For example, inline substitution gives a copy of a given (member) function scattered around a binary image. That is, if the preprocessor is used in combination with the compile-time evaluation of the representation, it may not leave a trace of the constants specified in the source code. In general, it is more difficult to reverse engineer complex optimized code.
In addition, Java program dependencies are resolved at run time when the class is loaded. Therefore, the name of the class and its method and field names should be present in the class file, along with the names of all imported classes, called methods and accessed fields. On the other hand, C / C ++ programs are statically linked. Therefore, except for the names exported from the dynamic library, the class names, members and variables need not be present in the compiled and linked program.
Finally, the Java application is delivered as a set of Java archive (JAR, Java Archive) files. The JAR format allows multiple files to be bundled into a single archive file that is relatively easy to retrieve individual classes in an essentially unencrypted archive. In comparison, C / C ++ applications are distributed as monolithic executable files that can be linked with some dynamic libraries, so it is not so easy to identify program information and individual code.
Therefore, decompiling Java bytecode to Java source is easier and easier than disassembling C / C ++, and can therefore be fully automated. All program information such as class hierarchy, statements, class names, methods and fields can be recovered from bytecode. Many freeware and commercial Java obfuscation tools are available, but none provide protection to prevent direct attacks on bytecode execution. As a result, Java reverse engineering is now a daily routine.
In addition, the JVM provides an open run-time environment for Java applications. There is little built-in security that protects the JVM and makes the JVM itself robust. It is relatively common to attach it to the JVM itself or to launch an attack using the JVM. Therefore, regardless of the strength of protection applied to the Java application code, the vulnerability of the JVM allows hackers to always use the JVM as the weakest link to carry out whitebox attacks. A more reliable and robust JVM could protect Java applications and thwart whitebox attacks, but this would require major changes to the current Java security model, in connection with this. Requires considerable industrial support and adaptation. Therefore, it is considered preferable to have a reliable and robust element in the industrial standard JVM that protects the application in a white box environment.
<p><patcit num="1"><text>Chow et al., Published March 17, 2009, entitled "Tampering Resistant Software Encoding and Analysis," Patent No. 7,506, 177 issued on 17 MAR 2009 to Chow et al. And titled TAMPER RESISTANT SOFTWARE ENCODING AND ANALYSIS).</text></patcit><patcit num="2"><text>Published December 9, 2008, entitled "Safe Methods and Systems for Handling and Distributing Digital Media," Johnson et al., US Pat. No. 7,464,269 issued on 09 DEC 2008 to Johnson et al. And titled. SECURE METHOD AND SYSTEM FOR HANDLING AND DISTRIBUTING DIGITAL MEDIA).</text></patcit><patcit num="3"><text>Published July 8, 2008, entitled "Systems and Methods for Protecting Computer Software from White Box Attacks," Johnson et al., U.S. Pat. No. 7,397,916 (Patent No. 7,397,916 issued on 08 JUL 2008 to Johnson et al. And titled. SYSTEM AND METHOD FOR PROTECTING COMPUTER SOFTWARE FROM A WHITE BOX ATTACK).</text></patcit><patcit num="4"><text>Patent No. 7,395,433 issued on 01 JUL 2008 to Chow et al. And titled METHOD, Chow et al., Issued July 1, 2008, entitled "Methods and Systems for Sustainable Digital Watermarking." AND SYSTEM FOR SUSTAINABLE DIGITAL WATERMARKING).</text></patcit><patcit num="5"><text>Patent No. 7,350,085 issued on 25 MAR 2008 to Johnson et al. And titled TAMPER RESISTANT SOFTWARE, published March 25, 2008, entitled "Tamperproof Software Mass Data Encoding" by Johnson et al. -MASS DATA ENCODING).</text></patcit><patcit num="6"><text>Patent No. 7,325, 141 issued on 29 JAN 2008 to Chow et al. And titled METHOD AND, Chow et al., Issued January 29, 2008, entitled "Methods and Systems for Secure Access." SYSTEM FOR SECURE ACCESS).</text></patcit><patcit num="7"><text>Patent No. 6,842,862 issued on 1 JAN 2005 to Chow et al. And titled TAMPER RESISTANT SOFTWARE ENCODING ).</text></patcit><patcit num="8"><text>Chow et al., Patent No. 6,779, 1 14 issued on 17 AUG 2004 to Chow et al. And titled, entitled "Tampering Resistant Software Control Flow Coding," published August 17, 2004. TAMPER RESISTANT SOFTWARE-CONTROL FLOW ENCODING).</text></patcit><patcit num="9"><text>Patent No. 6,594,761 issued on 15 JUL 2003 to Chow et al. And titled TAMPER RESISTANT SOFTWARE ENCODING, published July 15, 2003, entitled "Tampering Resistant Software Encoding".</text></patcit></p>
<p num="0014"> An object of the present invention is to eliminate or mitigate the major drawbacks of the Java platform configuration so far.</p><p num="0015"> This specification discloses an invention that provides a secure module capable of dealing with Java platform vulnerabilities and protecting Java bytecodes at runtime. The secure module is realized by C / C ++ as an example. Since the configuration of the security module of the present invention is based on C / C ++, a security technique for securing the C / C ++ software code can be used. Suitable techniques for the purposes of the present invention are provided by Cloakware Inc. of Ottawa, Ontario, Canada. Such security techniques for appropriate purposes are described in detail in Patent Documents 1 to 9, which are prior arts of the same owner, and the full text of each of these patents is incorporated herein by reference.</p><p num="0016"> Existing software security technologies disclosed by the above cited patents and related products from Cloakware allow these applications to be run in a malicious (unreliable) execution environment to prevent whitebox attacks on legitimate applications. Used to protect the functionality and intellectual property of running applications. These existing software security technologies provide practical source code and binary protection tools that protect C / C ++ applications with native editing code and make software and security inseparable by enhancing traditional application building processes. Including.</p>
<p num="0017"> In a first embodiment, the invention provides a device for improving the tampering resistance of Java bytecodes, which devices, at build time, with protective tools for applying security to Java bytecodes and protection. One or more protection mechanisms include a security module that receives secure Java bytecodes from tools and invokes secure Java bytecodes at runtime, and one or more protection mechanisms integrated with the protection tools and security modules. Works against static and dynamic attacks on bytecode.</p><p num="0018"> In a further embodiment of the invention, the device also includes a protected Java application bytecode stub, a secure Java bytecode containing a protected application payload and an encrypted class bytecode frame, each of which contains a secure Java bytecode. Formed by protective tools during construction.</p><p num="0019"> In another embodiment of the invention, the security module is distributed independently as a functional extension to the Java virtual machine environment, provides the basis of trust for the protected Java application, and secure Java bytecodes for the user. It will be distributed separately for each request.</p><p num="0020"> In another embodiment of the invention, the protection tool comprises a mechanism for instructing the protected application payload to be invoked via a protected Java application bytecode stub.</p><p num="0021"> In another embodiment of the invention, the security module includes a protected bytecode class loader, and the protected application payload is encrypted using the protected bytecode class loader. Includes a mechanism that commands it to be invoked via a frame.</p><p num="0022"> In another embodiment, the device comprises a programming engine implemented in a programming language that includes one or more of C, C ++, and Java.</p><p num="0023"> In another embodiment, the device comprises a programming engine implemented in a programming language capable of interacting with a Java virtual machine.</p><p num="0024"> In other embodiments, one or more protection mechanisms are selectable with configuration options. These protection mechanisms include static security handlers formed in protection tools and dynamic security handlers formed in security modules.</p><p num="0025"> In another embodiment, the static security handler comprises a white box (WB) static security handler for receiving cryptographic information including a cryptographic key from the user, whereby one or more of the other static security handlers. Generates the WB encryption key data used and the WB decryption key data and WB security module utility used by one or more dynamic security handlers during the dynamic run-time protection of each security module.</p><p num="0026"> In another embodiment, the static security handler may include a bytecode integrity verification (BIV) static security handler for applying hash code protection to secure Java bytecodes in response to protection marking information. Often, dynamic security handlers include BIV dynamic security handlers to verify hashcode protection at runtime, and security modules invoke countermeasures against tampering in the event of verification failure.</p><p num="0027"> In another embodiment, the device includes a static security handler because, at build time, the static security handler forms a protected Java application bytecode stub, a protected application payload, and an encryption class bytecode frame. Secure Loading Bytecode (SLB) Static security handler may be included, and the dynamic security handler loads and encrypts the encryption class bytecode frame corresponding to the secure Java application bytecode into the memory buffer. Encryption class via WB decryption key data corresponding to the class Decrypt each of the encryption classes contained in the bytecode frame and into the application workspace via the security module class loader, each decrypted class Contains SLB dynamic security handlers for loading bytecode and thereby executing Java application bytecode within the application workspace.</p><p num="0028"> Other aspects and features of the invention will be apparent to those skilled in the art by reading the description of a particular embodiment of the invention below, along with the accompanying drawings.</p>
Examples of the present invention will be described with reference to the accompanying drawings, but the description is for illustrative purposes only.
<figref num="1">It is a figure which shows the known outline of JNI which bridges a Java application and a native code.</figref>
<figref num="2">It is a figure which shows the known mechanism of the static attack against Java application bytecode.</figref>
<figref num="3">It is a figure which shows the known mechanism of the dynamic attack against Java application bytecode.</figref>
<figref num="4">It is a figure which shows the outline of the Java bytecode protection system by this invention.</figref>
<figref num="5">It is the figure of the construction process shown in the upper part of FIG. 4, and is the figure which shows the process which protects the Java application bytecode at the time of construction by this invention.</figref>
<figref num="6">It is the figure of the run-time process shown in the lower part of FIG. 4, and is the figure which shows the process which protects the Java application bytecode at the time of execution by this invention.</figref>
<figref num="7">It is a figure which shows the anti-debugging ability at startup and execution by this invention.</figref>
<figref num="8">It is a figure which shows the external white box (WB) cryptographic library by this invention.</figref>
<figref num="9">It is a figure which shows the internal WB cryptographic facility by this invention.</figref>
<figref num="10">It is a figure which shows the pre-process of the bytecode protection tool by this invention.</figref>
<figref num="11">It is a figure which shows the work flow of the bytecode integrity verification (BIV) static security handler by this invention.</figref>
<figref num="12">It is a figure which shows the work flow of the BIV dynamic security handler by this invention.</figref>
<figref num="13">It is a figure which shows the work flow of the secure loading bytecode (SLB) static security handler by this invention.</figref>
<figref num="14">It is a figure which shows the work flow of the SLB dynamic security handler by this invention.</figref>
<figref num="15">FIG. 5 illustrates a bootstrap interface and secure loading of a cloaked Java application according to the present invention.</figref>
<figref num="16">It is a figure which shows the work flow of the dynamic bytecode decoding (DBD) static security handler by this invention.</figref>
<figref num="17">It is a DBD sequence diagram by this invention.</figref>
<figref num="18">It is a figure which shows the work flow of the DBD dynamic security handler by this invention.</figref>
As can be seen from FIG. 1, the Java platform 100 includes the Java world (including the Java 104, the Java application 106 and the bytecode library 108 loaded in the Java) and the native code world 110 (the application or shared library is C / C ++ /). It further includes a Java Native Interface (JNI) 102 that provides a facility for bridging bidirectional interactions and interactions with (written in other languages such as an assembler and compiled into the host CPUISA). By using the Java programming language and the JNI application programming interface (API) for C / C ++ / assembler code, C / C ++ / assembler native binary code can be called from Java and also Java bytecode can be invoked. .. There are two types of interactions: a "down call" when the Java application code calls a native method, and the native method accesses the data or invokes a method of a given Java application via the JNI environment. There are two types of "upcall" in the case.
At runtime, the security modules of the invention can be run simultaneously in the JVM via JNI, which allows a given Java application to launch secure operations within the security modules of the invention. It is now possible to access and perform protection on Java applications and other Java library code loaded within the JVM.
The approach of the present invention is an effective security add-on to the existing JVM by introducing a fully protected and trusted security module within the JVM via the JNI mechanism. At runtime, the security module acts as the basis of trust and as a protection "trampoline and engine" within the JVM to invoke and execute various protections of Java bytecode. As such, the present invention does not require any widespread changes to the existing Java platform. Rather, both existing and newly deployed systems and equipment can immediately benefit from this solution. In other words, the invention can be treated as an extension of security over existing Java infrastructure to address the security challenges facing current Java applications. Thus, the present invention provides a Java bytecode protection security module that leverages the ability to access bytecode at runtime and execute Java bytecode protection methods in response to static and dynamic attacks on Java applications. ..
The present invention provides reliable protection tools and security modules within a Java bytecode protection system. The present invention does not rely solely on Java application protection based solely on the JVM and Java security. Rather, the present invention introduces the Java Bytecode Protection Security Module (SM), a trusted zone that can work with the JVM via JNI, to activate, execute and manage Java bytecode protection at runtime. To do. The reliability of a security module is ensured by applying known and effective security protections to the C / C ++ code in which the protection tools and security modules are written in the programming language. In this reliable SM, reliability is extended from SM to Java applications and JVMs, with some protection provided by SMs described below.
2 and 3 show typical static and dynamic attacks on Java bytecode. Generally, any given Java application is expanded in Java source form 202 and then compiled into Java bytecode 204 by Java compiler 206, which uses archiver utility 210 before distribution to archive file 208 ( That is, it is stored on the JAR file). This distribution can be done in many formats, including media such as compact discs (CDs) or downloadable files.
The static attacker 212 typically uses a reverse engineering tool (such as a Java decompiler) to extract valuable intellectual property information 214 (ie, property-worthy data or software algorithms) from the code from the distribution medium. To do. In that case, the attacker could make illegal changes to the code or otherwise hurt the underlying code 216. To prevent such static attacks on Java bytecode during the distribution of a given Java application, the present invention applies some level of protection to the application bytecode. This protection is done prior to distribution to ensure that static attacks are an extremely difficult task. After the effective protection is applied by the present invention, the intellectual property embedded in the application bytecode is not easily reverse engineered, and the protected bytecode tampering becomes an impractical act. Further, the static protection of the present invention has the advantage that the tampered bytecode cannot be loaded or executed by the proper JVM.
Unlike static attacks on application bytecode, the dynamic attacker 302 uses a dynamic attack tool to perform an attack on Java bytecode while the JVM is loading and running the Java application. By using dynamic attack tools and methods, an attacker can access JVM304 and application bytecode 306, observing and modifying bytecode 308 for attack purposes and directly with the original specified behavior and importance. Can understand and / and change various values. In addition, an attacker can ascertain secrets from valuable intellectual property 310 and bytecode, including lifting the original bytecode 306. To prevent such dynamic attacks on Java code at run time, the invention configures and implants protection against application bytecode prior to distribution. Moreover, the present invention provides these protections to ensure that any dynamic attack is unrealistic at runtime. The present invention not only prevents dynamic attacks, but also adds the ability to detect and mitigate dynamic attacks to protected applications, and for any potential attacker these attacks. Makes it very expensive in terms of time and resources.
FIG. 4 is a schematic diagram of the bytecode protection system 400 and related methods according to the present invention. Here, the Java bytecode protection system consists of two parts. That is, the build-time protection tool 402 and the run-time security module 404. As mentioned above, the bytecode protection system and related methods are implemented in C / C ++ using the technology available from Cloakware, Ontario, Canada, described above.
Java bytecode protection tool 402 is used to apply security (ie, "cloak") to Java bytecode 406 before deployment. With this Java bytecode protection tool 402, security settings and protection mechanisms can be specified at the time of construction. This tool takes the original Java application bytecode 406, security specifications and WB encryption key as input and generates "cloaked" Java bytecode to be executed in connection with the Java bytecode protection security module 404. The Java bytecode protection tool 402 provides an option to specify how to start the bytecode (Protected Application Bytecode Stub) or Protected Bytecode Classloader (Protected Bytecode Class). Includes options for specifying secure Java bytecode security technologies that have been deployed (via Loader), etc.). The cloaked bytecode of the Java application is distributed in two parts. That is, 1) protected Java application bytecode stub 408 (which is loaded into the target JVM environment 410) and 2) protected data file 412 and whitebox security module (WBSM) utility 414, which are loaded. , Accessed separately by SM at run time. The Java bytecode protection security module 404 of the invention can be distributed with or alone of these two parts until the stage of the application preparation approach. In general, the security module 404 is versatile in that once installed, it can be applied to the cloaked bytecode of any Java application.
Various methods for bytecode protection of the invention, used in connection with the Java bytecode protection system 400 of the present case, are effective. This bytecode protection method addresses static and dynamic attacks on Java applications in bytecode format, respectively.
One method of bytecode protection includes whitebox cryptography or "WB cryptography", which is a cryptographic algorithm that allows these operations to be performed in a malicious environment without leaking cryptographic keys and other cryptographic values. It is a unique encryption technology that protects. In other words, WB cryptography is also feasible against direct attacks. The present invention incorporates two types of WB cryptographic techniques, including an external WB cryptographic library and an internal WB cryptographic facility.
The External WB Cryptography Library provides hidden cryptographic keys and other cryptography so that they can be implemented in C and WB cryptographic operations can be performed by protected Java applications without releasing any valuable information, including keys. Protected by informational tampering resistance. The internal WB cryptographic facility of the present invention is a functional element of the build-time protection tool 402 that accepts cryptographic information and keys, and the protection tool and security module 404 of the present invention encrypts bytecodes and related information of various forms of Java applications. And generate a utility in the WB key data used for decryption.
Other methods of bytecode protection according to the invention include bytecode integrity verification (BIV). BIV-mediated protection can detect and mitigate static and dynamic tampering attacks on Java class or method code, while loading class or executed Java methods. At build time, the methods of the invention calculate the static hash values of the JAR files, classes and method bytecodes from the original application archive file. At load and run time, the methods of the invention calculate the dynamic hash value by addressing the bytecodes of the classes and methods loaded by JVM410 and match the dynamic hash value against the static hash value. Verify completeness.
Other methods of bytecode protection according to the invention include anti-debugging (AD, Anti-Debug), which will be described later with reference to FIG. AD is one of the dynamic security handlers 416 shown in FIG. AD protection can prevent and detect dynamic attacks that use the debugger at runtime. AD consists of technologies that detect attacks by monitoring the internal and external state of the system environment at startup and run time. Appropriate countermeasures are triggered when an anti-debug attack is detected.
Another method of bytecode protection according to the invention is a secure loading bytecode (SLB, Security Loading Bytecode). This SLB protection law blocks and detects static reverse engineer and tampering attacks on archive files and Java class code before it is loaded into the JVM410. At build time, SLB protection introduces the application stub class by encrypting the JAR file from the original application archive file and the selected class file. When the JVM410 loads a protected application, the JVM410 first loads the application stub class and then triggers the loading of the protected application. The SLB dynamic security handler 416, which will be further described below, is a functional element of the Java bytecode protection security module 404 of the invention that connects to the JVM410 via JNI418 during run-time execution. The SLB dynamic security handler 416 manages and controls the loading of protected Java application bytecode into the workspace of the JVM410.
Another method of bytecode protection according to the invention is dynamic bytecode decoding (DBD). DBD protection laws prevent and mitigate dynamic attacks on Java class or method code at runtime.
Other methods of bytecode protection according to the invention include both transfer execution and partial execution. Both of these protections move part of the original execution to the security module 404, exposing only part of the execution within the JVM410, ensuring that run-time dynamic code lifting attacks are thwarted and mitigated. .. For example, a Java bytecode can be converted into a C code (J2C) that can be protected and executed within the security module 404.
Other bytecode protection methods according to the invention include bytecode conversion. This type of protection can be achieved by techniques including data flow transformations and control flow transformations. Bytecode conversion can convert the original bytecode to another code structure while maintaining the original functionality. The converted bytecode is more difficult to reverse engineer and is tamper resistant.
With reference to FIG. 5, the Java bytecode protection tool 402 applies various protection techniques to the bytecodes of the original application. The Java bytecode protection tool 402 thus works with the protected bytecode and associated data as well as the Java bytecode security module at run time to generate utilities that apply these specified protection techniques to Java bytecode. The Java bytecode protection tool 402 receives three inputs via the user interface 518: cryptographic information and key 502, the original JAR file 504, and configuration option 506, and performs these three types of operations.
The first basic operation involves the generation of WB key data and utilities. Using the cryptographic information and the key 502, the WB static handler 508 generates WB encryption key data 510 used by various static security handlers (each described in detail below) and the tool itself. In addition, the build-time process of the protection tool 402 generates WB decryption key data that is stored as part of the run-time data 512 in the data protection folder 514. A WB Security Module (SM) utility 516 is provided that uses the WB decryption key data to perform a WB decryption operation that is invoked by a dynamic security handler at run time.
The second basic operation involves the application of protection techniques. According to the configuration options, the Java bytecode protection tool 402 applies various static security handlers to modify the application bytecode from its original form to a protected form. In doing so, this operation produces a protected Java application bytecode stub 408 and associated protected data files containing application bytecode protected in various forms of protection and important run-time data.
A third basic operation involves packaging a deployable form of protected Java bytecode. At the end of the process, the Java bytecode protection tool 402 properly builds and packs all output files so that the Java application bytecode stub 408 can be loaded by the JVM410. This Java application bytecode stub 408 is an entry point to the cloaked Java application launch and can take various forms. That is, it includes a class file that can be started by an external program, a class file that is started by another Java class, or a Java class loader. The Java bytecode protection tool 402 also properly builds and packs all output files so that the WBSM utility 516 can be invoked by the functional elements of the Java bytecode security module. In addition, the Java bytecode protection tool 402 also properly constructs and packs all output files so that all protected data files are more accessible by some functional element of the Java bytecode security module 404.
FIG. 5 is a schematic diagram of the above build-time process protecting Java application bytecode. In connection with FIG. 5, the main functional elements and data files will be described here.
The Java bytecode protection tool 402 includes a user interface 518 for interfacing with the user to receive user commands and main inputs. Commands and inputs include cryptographic information and key 502 containing cryptographic algorithm selection and original key material, original application bytecode archive file 504 containing protected unprotected bytecode and, for example, a user specific Java class and method. It includes configuration option 506, which includes user options for what and how to operate the Java bytecode protection tool 402 to protect the application bytecode, such as whether it should be protected or not.
The Java bytecode protection tool 402 also includes a protection manager 520. Protection Manager 520 interprets configuration option 506, coordinates various protection techniques in a dependency order and combines them so that the resulting overall protection is stronger than each individual protection. It is provided in. Manager 520 also includes utilities commonly used by other functional elements of the Java bytecode protection tool 402.
The Java bytecode protection tool 402 also includes a static security handler 522. Each individual static handler is invoked by protection manager 520 to perform a predetermined protection technique. In the embodiment, WB static handler 508, BIV static handler 524, AD static handler 526, SLB static handler 528, DBD static handler 530, transfer execution static handler 532, partial execution static handler 534, code conversion. The tool 536 is shown. Each static security handler is described in more detail in the following sections. Protection Manager 520 and Static Security Handler 522 provide a plug-in mechanism that adds and extends security capabilities and new protections by working together to easily integrate additional new security handlers and protection tools. Designed to do.
The Java bytecode protection tool 402 also includes the WB encryption key data 510 generated by the WB static security handler 508. The WB cryptographic key data 510 is used by the manager 520 and the static security handler 522 to encrypt some form of bytecode and protected data.
The Java bytecode protection tool 402 also includes a WBSM utility 516 generated by the WB static security handler 510. The WBSM utility 516 is used by a dynamic security handler (discussed later) within the security module 404.
The Java bytecode protection tool 402 also includes a protected Java application bytecode stub 408. The stub 408 contains only the bootstrap of the protected Java application for JVM410 to first load and then trigger the secure bytecode loader function to load the true protected bytecode from the protected data file.
The Java bytecode protection tool 402 also includes a protected J2C library 538 generated by the tool. Protected J2C library 538 contains various protected codes of C converted from Java bytecodes. This library is dynamically linked and activated by the Java bytecode security module.
The Java bytecode protection tool 402 also includes protected bytecode data 540. The protected bytecode data 540 is a kind of protected data file generated by the tool, and includes various protected bytecodes.
The Java bytecode protection tool 402 also includes run-time data 512. The run-time data 512 includes, but is not limited to, WB decryption key data, integrity verification static hash values, protected class and method information, and various security related information such as tables.
The Java bytecode protection tool 402 shows downloadability. Thus, all output from this protected tool, including protected Java application bytecode stub 408, protected J2C library 538, protected bytecode data 540 and run-time data 512) is downloadable at runtime. ..
FIG. 6 is a schematic diagram showing a run-time process for protecting Java bytecodes according to the present invention with respect to the Java bytecode protection security module 404 shown in FIG. As mentioned above, the Java bytecode protection security module 404 is deployed in the C programming language and is itself protected by tamper resistance technology, such as that provided by Croqueware of Ottawa, Ontario, Canada, and is robust and tampered with. Ring resistant. The programming engine on which the Java bytecode protection tool 402 and the security module 404 are based may be an engine developed in another programming language. In fact, the security module 404 underlying the invention can be deployed in other languages as long as the language can interface with the Java Virtual Machine.
At the start of the run time, the JVM410 loads the protected Java application bytecode stub 408 in the same way it loads a normal Java application. This triggers the Java application bytecode stub 408 to bootstrap the Java application bytecode that is trusted and protected by interfacing with the security module 404 via JNI602. At run time, security module 404 is responsible for managing and controlling the data flow so as to secure and protect the Java application bytecode and execution, thereby preventing dynamic attacks on the bytecode and execution.
Further, with reference to FIG. 6, the main functional elements and data files will be described here. Data and flow control from / to the security module 404 is done via the Java application bytecode workspace 604. Workspace 604 is a virtual workspace for Java applications within JVM410. The actual application bytecode that exists in the JVM410 is managed in various ways at runtime, including loading and executing the application. Each state of the workspace contains application bytecode that is legal and fully functional, but not perfect. Optionally, some parts of these bytecodes can always be kept protected by build-time configuration settings such as enabling transfer execution with the Java and C execution options. If this part of the bytecode needs to be executed, the security module 404 loads and restores them in the workspace just in time into the JVM410 and removes them when the execution is complete. Also, some of the original method bytecode has been converted to C functions that are not directly visible from the JVM410 and can only be invoked by the security module 404. This method allows an attacker to see only part of the original application bytecode at runtime, making it extremely difficult to reverse engineer the entire application bytecode.
The security module 404 (SM) also includes a bridge mechanism shown in FIG. 6, called the JNISM bridge 418. The JNISM bridge mechanism 418 is a dialogue element that enables connection and mutual functioning between the JVM 410 and the security module 404 via JNI 602. Sub-elements of the JNISM bridge 418 include JNI602, which provides the only dialogue mechanism between the JVM410 and the native code. Sub-elements also include downcall stubs 612 and upcall stubs 608. These stubs redirect downcalls from the Java application bytecode workspace 604 of the JVM410 to the dynamic security handler 611 via the security module 404 of the native programming code and upcalls from the security module 404 to the JVM610. Provides a directing application programming interface. The third sub-element in the figure is SM Manager 610. The SM manager 610 is a controller and coordinator for the security module 404. It not only manages and maintains various specified protections for Java application bytecode, but also manages and maintains the security module 404 itself. It also includes utilities commonly used by other functional elements of the security module 404.
The security module 404 includes a plurality of dynamic security handlers 611. Invokes each individual dynamic security handler 611 to implement its own protection technology. As shown, the dynamic security handlers according to some examples are the WB dynamic security handler 614, the bytecode integrity verification dynamic security handler 616, the anti-debug dynamic security handler 618, and the SLB dynamic security handler. It includes a 620, a DBD dynamic security handler 622, a transfer execution dynamic security handler 624, a partial execution dynamic security handler 626, and a code conversion 628. Details of the dynamic security handler 611 will be described later.
Coordinated by the Java bytecode protection tool 402 at build time, SM Manager 610 and Dynamic Security Handler 611 work together to easily integrate security modules and additional new dynamic security handlers for security capabilities and new Designed to provide a plug-in mechanism that extends additional protection.
FIG. 7 shows an example of the method of the invention for external anti-debug monitoring. Here, the Java platform debug architecture (JPDA, Java Platform Debug Architecture) promotes the debugging ability of Java applications. The method of the invention focuses on enabling debugging based on JPDA and detecting subsequent debugging activity. As shown, a multi-layered defense strategy is used to maximize the possibility of capturing static and dynamic debugging activity within a running JVM process. The three agents in the AD method shown in FIG. 7 can be configured to perform normal or legal debugging activities. The three agents are Kernel Monitor Agent (KMA, Kernel Monitor Agent) 702, Debugger Attachment Monitor Agent (DAMA, Debugger Attachment Agent) 710 and Debugging Procedure Monitor Agent (DPMA, Debugging Procedure Monitor). Agent) 718 is included.
For KMA702 accessing kernel space 701, it is necessary for the JVM process to load the debugging library 705 into that memory space before any debugging function can be performed. KMA702 is generated when the Java application starts. KMA702 periodically checks its own process map 703 from the kernel to determine if JDPA-related libraries are loaded into its memory space. If these libraries are found, they will perform the appropriate related actions.
In connection with DAMA710, this agent acts as a second line of defense. The DAMA710 is facilitated by the Java Virtual Machine Tool Interface (JVMTI, Java Virtual Machine Tool Interface) capability and is loaded when the JVM starts 700. A callback function is provided to constantly monitor the thread start screen for all threads created at runtime. Each time the JVM loads some threads that it considers essential for debugging, it can capture the activity of the attached JDPA debugger in the Java application. In this regard, AMA activates the thread start listener 707, detects a new thread start 709, and detects a JDBC-related thread 711.
For DPMA718, this agent is provided as a third line of protection. DPMA718 also operates in a JVMTI environment. The callback function that monitors the debugging procedure (such as hitting a breakpoint line) is triggered every time there is such an action. Detailed messages such as the location of threads and braking points can be collected. In this regard, the DMPA activates the line break listener 713, detects the debugging operation 715, and reports some thread and method information 717. Each of KMA, DAMA and DPMA can trigger an action and disable JVM726.
The static and dynamic security handlers described above are described in detail here. The WB security handler includes the external WB crypto library shown in FIG. 8 and the internal WB crypto facility shown in FIG.
The external WB cryptographic library of FIG. 8 provided by the WB Dynamic Security Handler 614 provides the library used by the Java application for WB encryption and decryption via the JNI Security Module Interface 804. The WB Static Handler 508 generates WB Key Data 803 that receives cryptographic information and the original key 502 from the user and can be distributed and rolled as needed, which the cryptographic library can use for secure cryptographic operations. ..
The internal WB cryptographic facility includes a WB static handler 508 and some static and dynamic elements are shown in FIG. The WB static handler 508 receives the encryption information and the original key 502 from the user and generates the WB encryption key data 904, which is used by another static security handler 906 as a part of various protection techniques. Used for cryptographic operations on various forms of application bytecode. The WB static handler 508 also generates WB decryption key data 908 and provides the WB security module utility 630, each used by the dynamic security handler 611, to decrypt while the security module 914 performs dynamic protection. Perform the operation.
The Java bytecode protection tool 402 also includes the preprocessing method shown in FIG. The preprocessing tool 1001 receives the original Java application bytecode archive file 1005 and translates them into an internal presentation (IR) of the original application bytecode. Specific classes and methods are then marked for protection and aspects of their protection with user option 1003. In this way, the protection mark information 1004 is generated. The original application bytecode 1000 and protection mark information 1004 in IR format are each used by the static security handler 522 for the required protection.
Within each static security handler of Java Protection Tool 402, there is a bytecode integrity verification (BIV). FIG. 11 is a diagram showing a work flow of the BIV static security handler 524. Further, FIG. 12 is a diagram showing a work flow of the BIV dynamic security handler 616. Here, BIV provides unique tampering resistance protection by introducing the ability to verify the dynamic integrity of Java bytecodes at runtime. Generally, at build time, tools are used to sign classes and methods that require BIV protection from which BIV data 1202 is generated and subsequently protected, and BIV actions are constructed in Java bytecode. At run time, BIV actions are triggered for each bytecode via the Java bytecode protection security module 404 for BIV protected classes and methods for which dynamic secure hash values are calculated just in time. Static and dynamic secure hash values are represented in a secure format and are Tamper Resistance Gatekeepers (TRGK, Tamper Resistance Gate). Feed the success and / or failure callback function to Keeper) 1216. The TRGK1216 determines whether the BIV check was successful without explicitly comparing the static secure hash value with the dynamic secure hash value. This can be done via appropriate algorithms in the form of specially designed mathematical calculations. If the static secure hash value and the dynamic secure hash value are the same, it generally indicates that the BIV check passes and the successful callback function can be activated. Otherwise, if the static secure hash value and the dynamic secure hash value are not the same, tampering of a particular class or method will be detected, indicating that the BIV check has failed. In this way, the failure callback function can be activated. These callback functions are user-defined countermeasures against detected tampering attacks.
In the present invention, the process of calculating the dynamic secure hash value 1214 of Java bytecode is a calculation against a normal native binary code in which the calculation only selects the native code directly from the memory allocated to the executable. Different from typical processing. Normally, application code cannot get a code segment directly from memory when Java is executed. Instead, the application code obtains the bytecode of the class or method through the JVM410 mechanism. In the present invention, an upcall to JVM410 is used to recover the bytecode, then a secure dynamic hash value 1214 is calculated and the recovered bytecode is collated with a pre-registered hash value for integrity. By performing a validation check, the security module enhances this capability and the JNI interface.
In connection with FIG. 11, it can be seen that the bytecode integrity verification static security handler 524 includes a bytecode signature. One of the key features of the BIV static security handler 524 is to walk through the application bytecode and use the protection mark information 1105 to check each of the classes and methods, which class or method needs BIV protection. Is to determine. If a class or method requires BIV protection, a particular hash value is calculated by applying a secure hash calculation to the bytecode 1106 or 1107 of that particular class or method. Generally, a secure hash calculation algorithm known in the calculation technique is used. The resulting hash values are stored as BIV data 1108 in a method organized and structured for effective use at runtime.
The BIV data 1108 of the bytecode integrity verification static security handler is a data container containing data of static hash values of classes and methods and other information such as WBBIV cryptographic key data. These data are used at run time by the dynamic BIV security handler. For more effective use, the BIV data 1108 consists of corresponding information about each of the protected classes and methods and their static hash values.
The bytecode integrity verification static security handler 524 is also responsible for converting and encrypting the BIV data 1108. Maintaining the integrity of BIV data 1108 is very important. BIV data can be transferred or downloaded over the network. Therefore, the present invention applies conversion and encryption to these as part of the packing for use. Without such protection, tampering with BIV data can be a step in destroying BIV protection. Upon packaging, the BIV static security handler provides double protection against BIV data to prevent static attacks on sensitive BIV data. First, the BIV static security handler 524 converts the data for these values so that the static hash values can be calculated in the format converted by the dynamic BIV security handler 616 at the time of execution. This ensures that the actual simple values are not exposed. The BIV static security handler 524 then encrypts these converted values so that no tampering occurs on these converted values before they are used dynamically.
The BIV data 1108 is a kind of run-time data used by the dynamic security handler 611 at the time of execution. Run-time data is organized and stored in a single file or multiple files, depending on user options. Multiple run-time data file formats have several advantages, including the ability to update and download data information at a finer particle size. For example, BIV data 1108 may be configured for each of the protected Java classes. Thus, BIV protection can be more practically done on a class-by-class basis.
The bytecode integrity verification static security handler 524 also provides its own BIV trigger. Two approaches to run-time trigger BIV are provided via external BIVAPI and internal BIV triggers. As a first approach that is part of the system of the invention, some external BIVAPIs are provided and the user uses them in appropriate places with clear ideas for performing BIV checks. The user can indicate which Java class or method requires BIV checking. The user has full control of the mitigation actions by using the callback function. The other method is an alternative method to triggering by the user invoking an external API. Instead, BIV triggers can be pre-built within some functionality of the Java bytecode protection security module. Each time the Java application activates these features, an internal BIV action is triggered in a predetermined manner. Some mitigation actions are pre-defined and are incorporated internally by the security module. However, the user still has partial control over the mitigation action. This is effective by providing a preset API to act according to the setting and having the user set the mitigation action to be taken by the security module in advance. In general, the user has full control over whether to use the external BIVAPI and where to use it, and has indirect control over whether to use the internal BIV trigger at build time. The user has no control over where to trigger the internal BIV, as it is hidden and controlled by the security module.
With respect to FIG. 12, it can be seen that the bytecode integrity verification dynamic security handler 616 includes BIV initialization. BIV initialization is performed and the secure static BIV data 1202 is loaded and decrypted using the WBBIV decryption key data 1203, after which they are loaded into memory in a secure format. BIV initialization can be performed with two methods. That is, it is on-demand as part of the security module initialization or during dynamic BIV. The first method can be executed once as part of SM initialization when loading a protected Java application. The second method can be executed by loading what is needed on demand during dynamic BIV. This can be done if BIV is required for the class. BIV data files can be organized at the class level. In a particular class, BIV data is loaded and decrypted only for this class. This second method gives the user more degrees of freedom and can give the BIV data the small changes needed if the class bytecode changes.
The bytecode integrity verification dynamic security handler also performs dynamic BIV1210. As mentioned above, the dynamic BIV of a class or method is invoked by an external BIVAPI call or another functional call from a protected Java application to a security module that contains a predetermined internal BIV trigger. Dynamic BIV includes at least the following key actions: obtaining the latest bytecode, calculating dynamic secure hash values, and providing a tampering resistant gatekeeper (TRGK) 1216.
The latest bytecode is obtained by upcall. In order to securely calculate the secure dynamic hash value for a class or method in the security module, the latest bytecode for the class or method needs to be obtained by upcalling to JVM410 via JNI. You need to translate or compile the same bytecode itself into binary while executing the class or method loaded into JVM410. In the absence of tampering attacks on the bytecode, the bytecode should be the same bytecode with a statically secure hash value calculated.
Dynamically secure hash value calculation actions include typical and well-known hashing calculations, and the resulting value is in protected form and is used in protected form.
The provision of TRGK1216 includes two inputs. TRGK1216 uses both static and dynamic secure hash values (SSHV1212, DSHV1214) for a particular class or method to verify that the bytecode integrity of the class or method is compromised. If the bytecode is tampered with, the DSHV1214 cannot be the same as the SSHV1212. TRGK1216 detects tampering with respect to bytecode. If the BIV verification passes, the TRGK1216 will either trigger a successful callback function or return to the original BIV trigger, otherwise the TGRK1216 will trigger a failed callback function as a mitigation action for the user.
Bytecode integrity dynamic security handler 616 also includes an termination step in the form of BIV termination. Termination of BIV as part of the security module cleans up the memory space and other information used by the BIV dynamic secure handler.
FIG. 13 shows a secure loading bytecode (SLB, Security Loading Bytecode) static security handler 528. The SLB static security handler 528 receives an internal representation of the original Java application bytecode 1301 along with WB encryption 1302, decryption key data 1304 and protection marking information 1306.
An important output of the SLB security handler 528 is the application stub 1308. Application stub 1308 includes a bootstrapping class that initiates the process of loading through the run-time security module. The application stub 1308 is loaded by the JVM410. Application stub 1308 includes each public API required to enable an application launched independently or by another Java application. Application stub 1308 includes a method that invokes the downcall function for the security module, which then decrypts the Java application into the JVM, loads it, and executes it.
To prepare the application stub, the SLB static security handler 528 includes an application bytecode work frame 1310 and an encrypted application bytecode work frame 1312. The application bytecode work frame 1310 is different from the original application bytecode 1301. In general, the classes in the application bytecode work frame 1310 do not require protection and are the same as the original ones. If the class needs to load safely, the class stub replaces the original class bytecode, which makes the class bytecode the original bytecode. The encrypted frame 1312 is obtained by encrypting the application bytecode working frame 1310 using the application encryption key data 1302 via the static security handler 528 at build time and is dynamic at run time. It is decrypted using the WB decryption key data 1304 via the security handler 620.
In addition to the application stub 1308, the application payload 1314 is generated. The application payload 1314 includes an encrypted application work frame 1312 and application WB decryption key data 1316. The application WB decryption key data 1316 in the protected application payload is key data generated by the WB static security handler 508 and is transmitted to the SLB static security handler 528 as part of the WB decryption key data 1302. At run time, it is used to decrypt the encrypted application bytecode work frame 1312.
As shown in FIG. 13, the underlying code can be formed as class bytecode 1318, class stub 1320 or encrypted class byte code 1322. The class bytecode 1318 is the original bytecode. Class stub 1320 includes a bootstrap method that initiates a reliable class loading process via a run-time security module that loads encrypted class bytecode 1322 if necessary. At the time of packaging, the class bytecode 1318 is analyzed. The marked method is replaced by a method that invokes the downcall method on the security module, in which case the security module invokes the original bytecode functionality via the security handler method specified at the time of packaging. The encrypted class bytecode 1322 is obtained by encrypting the class bytecode 1318 using the class WB encryption key data 1302 by the static security handler 528 at the time of construction, and the dynamic security handler at the time of execution. It is decrypted by using the class WB decryption key data via 620.
The encryption class bytecode frame 1324 is generated by the SLB static security handler 528. Includes encryption class bytecode and class WB decryption key for one or more classes. The user has the option of controlling the number of classes a frame can contain within the encrypted class bytecode 1322. The user has the option of loading these at runtime or separately. The class WB decryption key data is generated by the WB static security handler 508 and transmitted to the SLB static security handler 528 as part of the WB decryption key data 1304. At runtime, the class WB decryption key data 1304 is used to decrypt the encrypted class bytecode 1322. The user has the option of generating one or more class WB encryption and decryption keys.
FIG. 14 shows the work flow of the SLB dynamic security handler 620. The SLB dynamic security handler 620 is a functional element of a security module that is connected to the JVM410 by JNI when executing bytecode. The SLB dynamic security handler 620 manages and controls the loading of Java application bytecode into the workspace in JVM410. This capability protects the original Java application bytecode, distributes it in a similarly protected format, and ensures that any static attacks on the application bytecode before it is loaded into the JVM410 can be thwarted. The SLBD-Handler 620 contains two key functional elements, including a secure application load and a secure class load.
The secure application load includes a protected application stub 1404 that is in the classpath and is normally loaded by the JVM410. After loading, the main bootstrap method is executed, and then the application bootstrap method 1403 is invoked via the JNISM bridge 418 via the downcall API. This triggers the next application load action for the SLB dynamic security handler 620. First, the protected application payload 1408 is loaded from the protected data folder. It was encrypted in just-in memory by loading the encrypted application byte code work frame 1410 from payload 1408 into the memory buffer and then using the application WB decryption key data 1304. Includes decrypting the application bytecode work frame 1410. Next, the decrypted application bytecode work frame 1412 is walked through and each class bytecode and class stub is loaded from the work frame into the application workspace by using a special SM class loader 1414. The SM class loader 1414 loads the encrypted bytecode using the security module, decrypts the bytecode, and loads it into the JVM410. Incorporates additional security checks to add BIV protection to the SM class loader 1414 and check the class loader hierarchy and integrity at load and run time. Finally, the execution is passed to the main method of the main application class in the workspace.
The secure class load includes the trigger of the class boot lap method shown in FIG. In general, at run time, encrypted class bytecode frames can be pre-installed or downloaded on the device before running the protected application. This depends on the functional nature of the application. For classes with class stubs, the class bootstrap method is triggered when needed to run the protected application, and the next step 1500 to load the required class from the encrypted class bytecode frame is the JISM bridge. Executed through. First, load the corresponding encrypted class bytecode frame into the memory buffer. Next, each of the encrypted classes contained in the frame's just-in memory is decrypted by using the specific class WB decryption key data. The decrypted class bytecode is loaded into the application workspace using the SM class loader. After that, the execution of the application continues in the workspace.
Note that the JVM allows loading of new classes while it is in progress, unlike running a native application that needs to load all the code first. This allows you to dynamically extend your application by loading classes only when needed. Moreover, this feature of Java provides a good opportunity to use SLB secure class loading against code lifting attacks. First, after a protected class has been safely loaded and executed in SLB, the present invention can provide an option to keep the class protected by restoring it to its class stub. Thus, the original bytecode of the class is available in the JVM image only at runtime, while it remains in protected format at other times.
Dynamic Bytecode Decryption (DBD) includes decrypting the bytecode of a protected method only if the encrypted method is invoked by a running Java program. This ensures that all of the application's unencrypted bytecode does not exist in memory at once.
FIG. 16 shows a work flow at the time of construction of the DBD static security handler 530. At build time, each unprotected class bytecode file 1602 is loaded into the internal buffer and a new class bytecode work frame is constructed and marked for the classes protected by the DBD using protection marking information 1306. The method is replaced with a method stub 1604 that invokes the downcall method that triggers the activation of the DBD dynamic security handler 530 at run time. For each protected Java method, the bytecode is an encrypted method packaged with WB decryption key data 1608 for distribution as part of the bytecode data protected using the method's WB encryption key. Is encrypted by storing in the encrypted method bytecode frame 1606. The original bytecode class is replaced and distributed by the protected class bytecode working frame 1610.
FIG. 18 is an execution time workflow of the DBD dynamic security handler 622. When the encrypted DBD Java method is invoked on the JVM while the protected Java application is running, the method stub is executed first, then the downcall is made, and the method bootstrapping 1802 is the DBD dynamic security. Invoked in handler 622. This includes an example of identifying and decrypting the encrypted method from the encrypted method bytecode frame 1804 by using the WB method decryption key data and restoring the true bytecode to the JVM. In the implementation example for restoring the class bytecode to the JVM, the class is renamed and the copy of the class is reconstructed to the JVM to avoid name confusion in the JVM namespace. An example of this is shown in FIG. In the figure, the partially decrypted class is loaded into the JVM with the new class name.
In FIG. 18, if necessary, the DBD dynamic security handler 622 can copy the state of the class to the real bicode instance when the original bytecode is restored to the JVM, and this option is available at build time. It is determined. The DBD dynamic security handler 622 then invokes the unencrypted method on the JVM410. When the method has finished invoking, the security handler 622 restores the real state from the unencrypted class instance to the encrypted instance, and control returns to the downcall method of origin. FIG. 17 shows a sample method invocation and state copy operation 1700 before calling the unencrypted method. When the unencrypted method finishes executing, its state is copied back to the class instance by the DBD dynamic security handler 622 on the protected method stub. Control returns to the protected method, while the security handler removes the unencrypted class and instance from JVM410.
The above embodiments of the present invention are for illustrative purposes only. Those skilled in the art may modify, modify and modify certain embodiments without departing from the scope of the invention as defined solely by the appended claims.
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| KR20210094300A | Cited by | Republic of Korea | Search report |
16 members in 8 offices
Priority claims6
| Document | Office | Kind | Date |
|---|---|---|---|
| 26088709 | United States of America | P | |
| 2010001761 | Canada | W | |
| 61260887 | – | – | – |
| CA2010001761 | – | – | – |
| US20090260887P | – | – | – |
| WO2010CA01761 | – | – | – |
Members16
| Document | Office | Kind | |
|---|---|---|---|
| CA2774728A1 | Canada | A1 | |
| WO2011057393A1 | World Intellectual Property Organization (WIPO) | A1 | |
| EP2467800A1 | European Patent Office (EPO) | A1 | |
| CN102598017A | China | A | |
| US2012246487A1 | United States of America | A1 | |
| KR20130018642A | Republic of Korea | A | |
| JP2013511077A | Japan | A | |
| JP5689472B2This record | Japan | B2 | |
| IN2458DEN2012A | India | A | |
| US9213826B2 | United States of America | B2 | |
| CN102598017B | China | B | |
| EP2467800A4 | European Patent Office (EPO) | A4 | |
| CA2774728C | Canada | C | |
| EP2467800B1 | European Patent Office (EPO) | B1 | |
| EP3923165A1 | European Patent Office (EPO) | A1 | |
| EP3923165A4 | European Patent Office (EPO) | A4 |
19 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Written notification for declining of transfer of rightsJAPANESE INTERMEDIATE CODE: R360R360 | R360 | |
| Transfer withdrawnWithdrawnJAPANESE INTERMEDIATE CODE: R371R371 | R371 | |
| Written notification for declining of transfer of rightsJAPANESE INTERMEDIATE CODE: R360R360 | R360 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 5689472
- Publication, DOCDB
- 5689472
- Publication, EPODOC
- JP5689472B
- Application
- 2012538154
- Application, DOCDB
- 2012538154
- Application, EPODOC
- JP20120538154
Titles2
- English
- Systems and methods to protect Java bytecode from static and dynamic attacks within a malicious execution environment
- Japanese
- 悪意ある実行環境内での静的および動的攻撃からJavaバイトコードを保護するシステムおよび方法
Classification
- CPC, 4
- G06F21/51
- G06F21/125
- G06F21/14
- G06F9/445
- IPC, 2
- G06F21 12
- G06F21 14