Tamper Resistant Software Research Articles

SOFTWARE SECURITY OVERVIEW

The article analyzes the main threats and problems of software protection. Methods for protecting information, their advantages and disadvantages are considered, and the possibility of using existing tools to protect software is studied. The possibility of improving and using a number of software protection methods against active fraud attacks was brought. Type of attacks exists and why protection is necessary was specified. Furthermore, we discussed several states of the art protection techniques which can be used in software to protect against analysis and tampering attacks. Analyzed such methods: Client-Server Solutions, Code Encryption, Code Diversity, Code Obfuscation, White-Box Cryptography, Tamper Resistant Software, Software Guards, Oblivious Hashing. Although we considered all these possible techniques separately, it is possible to combine these techniques into one solution.

Two‐stage tamper response in tamper‐resistant software

Malicious modification of software continues to raise concerns; thus, many countermeasures against these threats have been proposed such as obfuscation and tamper resistance techniques that can be combined to create tamper-resistant software. The methods for responding to tampering are an important consideration in tamper-resistant software design. Many tamper response mechanisms deliberately cause the application to crash; however, this response has negative impacts on the developers and users. An alternative approach is to detect and fix malicious changes. However, this approach cannot deter an attacker from attempting to continuously modify target software. This study presents robust tamper-resistant software techniques to mitigate tampering and reverse engineering attacks. The tamper-resistant software is based on an existing control flow flattening scheme and includes extensions for tamper detection and flexibility. Furthermore, the authors introduce a dynamic key in their two-stage tamper response scheme that considers both software stability and continuous attack. When tampering is detected, the proposed two-stage tamper response first produces a warning level response such as self-healing or programme termination. Next, if an attacker continuously attempts to bypass the warning level response, a self-destructive tamper response is triggered, as the result of an incorrectly computed dynamic key.

MAC함수와 동적 링크키를 이용한 소프트웨어 변조 방지 기법

ABSTRACT In order to prevent tampering and reverse engineering of execut ive code, this paper propose a new tamper resistant software mechanism. This paper presents a cryptographic MAC function and a relationship which has its security level derived by the importance of code block instead of by merely getting the encry ption and decryption key from the previous block. In this paper, we propose a cryptographic MAC function which generates a dynamic MAC function key instead of the hash function as written in many other papers. In addition, we also propose a relationships having high, medium and low security levels. If any block is determined to have a high security level then that block will be encrypted by the key generated by the related medium security level block. The low security block will be untouched due to efficiency considerations. The MAC function having this dynamic key and block relationship will make analyz ing executive code more difficult.Keywords: application program protection, reverse engineering, software protection, code obfuscation접수일(2012년 8월 7일), 수정일(1차: 2012년 10월 12일, 2차: 2012년 12월 24일), 게재확정일(2012년 12월 24일)* 본 연구는 방위사업청과 국방과학연구소의 지원으로 수행되었습니다.†주저자, magogos@hanmail.net‡교신저자, donghlee@korea.ac.kr

Improving Memory Encryption Performance in Secure Processors

Due to the widespread software piracy and virus attacks, significant efforts have been made to improve security for computer systems. For stand-alone computers, a key observation is that, other than the processor, any component is vulnerable to security attacks. Recently, an execution only memory (XOM) architecture has been proposed to support copy and tamper resistant software. In this design, the program and data are stored in an encrypted format outside the CPU boundary. The decryption is carried out after they are fetched from memory and before they are used by the CPU. As a result, the lengthened critical path causes a serious performance degradation. We present an innovative technique in which the cryptography computation is shifted off from the memory access critical path. We propose using a different encryption scheme, namely, "pseudo-one-time pad" encryption, to produce the instructions and data ciphertext. With some additional on-chip storage, cryptography computations are carried in parallel with memory accesses, minimizing the performance penalty. We performed experiments to study the trade-off between storage size and performance penalty. Our technique reduces the performance overhead from 20.79 percent to 1.28 percent on average for reasonably sized (64 KB) on-chip storage.

Architectural support for copy and tamper resistant software

Although there have been attempts to develop code transformations that yield tamper-resistant software, no reliable software-only methods are know. This paper studies the hardware implementation of a form of execute-only memory (XOM) that allows instructions stored in memory to be executed but not otherwise manipulated. To support XOM code we use a machine that supports internal compartments---a process in one compartment cannot read data from another compartment. All data that leaves the machine is encrypted, since we assume external memory is not secure. The design of this machine poses some interesting trade-offs between security, efficiency, and flexibility. We explore some of the potential security issues as one pushes the machine to become more efficient and flexible. Although security carries a performance penalty, our analysis indicates that it is possible to create a normal multi-tasking machine where nearly all applications can be run in XOM mode. While a virtual XOM machine is possible, the underlying hardware needs to support a unique private key, private memory, and traps on cache misses. For efficient operation, hardware assist to provide fast symmetric ciphers is also required.

Architectural support for copy and tamper resistant software

Although there have been attempts to develop code transformations that yield tamper-resistant software, no reliable software-only methods are know. This paper studies the hardware implementation of a form of execute-only memory (XOM) that allows instructions stored in memory to be executed but not otherwise manipulated. To support XOM code we use a machine that supports internal compartments---a process in one compartment cannot read data from another compartment. All data that leaves the machine is encrypted, since we assume external memory is not secure. The design of this machine poses some interesting trade-offs between security, efficiency, and flexibility. We explore some of the potential security issues as one pushes the machine to become more efficient and flexible. Although security carries a performance penalty, our analysis indicates that it is possible to create a normal multi-tasking machine where nearly all applications can be run in XOM mode. While a virtual XOM machine is possible, the underlying hardware needs to support a unique private key, private memory, and traps on cache misses. For efficient operation, hardware assist to provide fast symmetric ciphers is also required.

Architectural support for copy and tamper resistant software

Although there have been attempts to develop code transformations that yield tamper-resistant software, no reliable software-only methods are known. This paper studies the hardware implementation of a form of execute-only memory (XOM) that allows instructions stored in memory to be executed but not otherwise manipulated. To support XOM code we use a machine that supports internal compartments---a process in one compartment cannot read data from another compartment. All data that leaves the machine is encrypted, since we assume external memory is not secure. The design of this machine poses some interesting trade-offs between security, efficiency, and flexibility. We explore some of the potential security issues as one pushes the machine to become more efficient and flexible. Although security carries a performance penalty, our analysis indicates that it is possible to create a normal multi-tasking machine where nearly all applications can be run in XOM mode. While a virtual XOM machine is possible, the underlying hardware needs to support a unique private key, private memory, and traps on cache misses. For efficient operation, hardware assist to provide fast symmetric ciphers is also required.