An Architecture for Source Code Protection

Abstract—Due to great competition in software industry the source code and binaries have to be protected. Source code available in plain form could be easily stolen and launched on any computer using IDE. We will discuss a protocol that will be used in both (single user and teaming environment) in order to provide source code protection. This would be achieved though authentication, authorization, encryption/decryption and hashing.

Keywords—Encryption; Authentication; Authorization; Hashing; Source code SC; Binaries; Integrated development environment (IDE); Authentication server & Ticket Granting Server (ATGS)

1. INTRODUCTION

In software industry, the most important asset of the industry is the source code of the software which is being developed. There is a lot of work that has been done in the secure communication, secure databases, and other security services in applications but the source code itself is not being protected which might result in a great financial and data loss for an organization. Due to great competition in software Industry Company coming up with new and unique ideas and launches it in the market will in return generate great revenue. So in software industry it’s just about the idea that matters.

Most of the software companies don’t leak out their upcoming products until they are ready to be released in the market. Due to the importance of the idea and source code, source code theft is the biggest threat in software industry. Source code theft could be physical or via some botnet. In physical source code theft a person might get access to your system and copies the source files and takes it to his own system to recompile with the IDE. He got access to all of your work without any difficulty. The other case could be a Lab environment where many users have access to a common machine. In this situation any person logging on the system can view history in the IDE he could also access those source files if they are made available. In the second type where your competitors know the importance of your system might launch a botnet on your machine. In this ways all your important files (including source files etc) could be stolen and sent to a remote machine. The person getting access to these source files might get a great benefit from it.

Our work is to encrypt these source files and binaries generated by the IDE using cryptographic technique. Because if we don’t protect the binaries, the binary could be reversed engineered to extract source code using some decompiler [1]. JAD could be used to launch a reverse engineering attack on binaries [2]. Some software’s are available in the market that encrypts your files (including source files etc) but these files have to be encrypted manually every time. Due to this extra effort people just skip it. In our model source files and binaries would be automatically encrypted whenever the user performs the Save, Save As and Execute operation. In this way the

developer could pay his full attention on software development without caring about its protection. Our technique will provide confidentiality to source code and binaries, tempering of source code and idea leaking.

2. RELATED WORK

The idea of protecting source code and its binaries was influenced from some of its related work

• Guy-Armand Yandji, Lui Lian Hao, Amir-Eddine Youssouf, Jules Ehoussou [3] presented a model for normal file encryption and decryption. The paper describes a methodology using AES and MD5 for encrypting files. The outcome file that will as a result be hashed and strongly encrypted through the software.

• Xiufeng Zhang and Qiaoyan Wen [4] described the flexibility of Java language, which makes the protection become very difficult. Using decompiler [5] such as Jad we can easily extract the source code from the binary file. Therefore, any malicious users can use the anti-compiler tools to make reverse-engineering attacks. The paper presented an AOP-Based J2EE Source Code Protection technique in they gave solution to the problem that arises when encrypting J2EE applications.

• ByungRae Cha [6] presented a CRYPTEX model for protecting software source code. The model presented safe protection and access control of software source codes. The access control to the source code was achieved using digital certificate. The CRYPTEX consisted of software source codes and an algorithm to control access.

• A White Paper sponsored by CA Technologies [7] for Protecting API’s against attack and hijack presented a secure API architecture. APIs are windows into applications and as with any window an API can easily be misused. APIs put applications under the hacker mi croscope and increase attack surface on client application. So a solution was presented using SecureSpan API proxy.

• SVN [8] and CVS [9] are used to control versions.

A version control system keeps track of all work and all changes in a set of files, and allows several developers to access them. Access to these files is controls using authentication and authorization if the files are not open source. Subversion can operate on network which will allow various people to modify and manage the same set of data.

3. RISK FACTORS

Source code is the main asset of any product, if somehow the source code is compromised the whole product get compromised. It should be necessary to become aware of the threats that are caused when source code or the binaries are compromised:

• Source code can be used to steal the idea behind that product and can be used to make a similar product.

• Source code can give attackers information about the working of your application and it will also provide him the loopholes in your application which would help him to launch attacks.

• Binary files can be revered engineered to generate source files using a decompiler and possible attacks could be launched by those source files.

• By having the source code or binaries the attacker can add some unwanted feature to that product and make that malicious product available to the public

• Bypass license checks (patching) in your product and make a free copy available to public.

4. MANUALLY ENCRYPTING AND DECRYPTING

You can encrypt and decrypt the source files and binaries manually using some software but in our approach the source files and binaries would be encrypted and decrypted automatically without any extra effort.

1. Time Consuming

Because we have to do encryption and decryption manually with the help of some software so existing approach might be more time consuming then ours.

2. Purchase of extra Software

We might need to purchase extra software in order to perform this encryption and decryption of source files and binaries. In our approach no extra software is required to perform this task. This would be a feature inside the IDE.

3. More Secure

Our approach is more secure than the existing one because the developer might forget to do this operation and leave the source files and binaries unencrypted. While in our approach whenever you exit the IDE the source files and binaries would be encrypted before closing IDE.

In our approach developer won’t need to care about the protection of source files and binaries these would be secured automatically at backend.

5. SOURCE CODE PROTECTION ENVIRONMENTS

Our focus is on two types of source code protection environments

• Single User Environment

• Teaming Environment

1. Single User Envirnoment

In a single user environment a single user using IDE on his system would face all the challenges to the source code that we have discussed above. The Source code is stored on the local drive onto the system in plain form. Anyone getting access to that drive can misuse the source code. We have to protect this source code by providing some kind of security measures.

• Proposed Solution

First the user will be authenticated. So when the user launches the IDE a login screen will appear he would enter his username and password if his logging for the first time he has to get registered and the hash of the password would be taken and stored with username at some secure place (i.e. database ). If his already registered the entered password has to be hashed and is compared with the hash that is already stored with a particular username. Now if the both hash match then the user would be logged in to the IDE with a particular ID as shown in figure 1. If there is some kind of error the user would be asked to re-enter again, Skip and run IDE normally or exit.

Fig. 1. Authentication sequence diagram

Our main emphasis would be on Save, Save As, Open and execute operations because these operations require security enforcement. Say the user tries to open an existing