Fig 1 - uploaded by Mila Dalla Preda
Content may be subject to copyright.
Overview of remote entrusting.

Overview of remote entrusting.

Source publication
Article
Full-text available
Network applications often require that a trust relationship is established between a trusted host (e.g., the server) and an untrusted host (e.g., the client). The remote entrusting problem is the problem of ensuring the trusted host that whenever a request from an untrusted host is served, the requester is in a genuine state, unaffected by malicio...

Contexts in source publication

Context 1
... remote entrusting scenario is shown in Figure 1. S is the trusted host (server) and C is the untrusted host (client) running a certain application P, whose integrity has to be verified upon communication with S. The application P requires a service deliv- ered by S. To receive this service a communication channel is established between C and S and some messages are exchanged: ...
Context 2
... results coming from all the runs have been finally merged and the final Pareto front has been computed. In Figure 10, each data point represents a cut in the Pareto front. X and y axes measure, respectively, the computation and communi- cation costs ( Comp and Comm) while the labels report SecLoss. ...
Context 3
... Figure 10, all points in the graph represent a possible solution to the trade-off problem. Which one to select depends on the most important costs to minimize. ...
Context 4
... us assume that these two constrains correspond to Comp < 1000 and Comm < 200. This means that we can restrict the search in the portion of the graph corresponding to the highlighted (bottom-left) area in Figure 10. For convenience, a zoom-in of this area is shown in Figure 11. ...
Context 5
... means that we can restrict the search in the portion of the graph corresponding to the highlighted (bottom-left) area in Figure 10. For convenience, a zoom-in of this area is shown in Figure 11. ...
Context 6
... all the data points in Figure 11, the most secure solution is represented by P 20 , the point with SecLoss = 20. However, if we are willing to accept a slightly more insecure solution we could consider also the point P 25 . ...
Context 7
... order to decide which one to adopt, a deeper investigation could be done by browsing the involved segments of code. Figure 12 shows the call graph for the portion of code involved in P 25 and P 20 . While the methods changeSpeed and exec are isolated, the rest of the call graph is very connected. ...

Similar publications

Article
Full-text available
Blockchain technology is a database that is operated by multiple parts and forms a chain structure through hash index. The blockchain uses multiple nodes and distributes multiple accesses to data, thereby reducing the dependence on the central Internet server and avoiding the possibility of damage to the central server point due to data and data lo...
Article
Full-text available
A Large-Scale Heterogeneous Network (LS-HetNet) integrates different networks into one uniform network system to provide seamless one-world network coverage. In LS-HetNet, various devices use different technologies to access heterogeneous networks and generate a large amount of data. For dealing with a large number of access requirements, these dat...
Conference Paper
Full-text available
In the Cyber world today managing threats dynamically, is challenging, moreover generation of knowledge and enhancing knowledge management (KM) capabilities is becoming crucial due to the dynamics of technological advancements. In this context a regulatory mechanism is essential; this resilience required is achieved through data analytics which bri...
Research
Full-text available
Cloud storage is one among the service provided by Cloud computing within which information is maintained, managed, secured remotely and created available to users over a network. The user concerning about the integrity of data hold on within the cloud because the user's data will be attacked or changed by outside attacker. Therefore, a new thought...
Conference Paper
Full-text available
Although the current ride hailing services have revolutionized the transportation industry in today's world, they are extremely centralized. Central authority has all the control and maintains data about the users. Such platforms raise concerns about the service policies and data reliability. In case the central server faces data tampering or ranso...

Citations

... Code splitting [6,7] was proposed to mitigate malicious reverse engineering and code tampering attacks by splitting a program into two components. A component is run locally on the end-user machine, while a second component, that contains the security sensitive parts, is run on a protected server (e.g., in the cloud) where it can not be inspected nor tampered with. ...
... The portion of the computation that is moved to the server is secured against man-in-the-end attacks, but it requires constant connectivity to the internet (the protected client program would not run offline) and it involves the additional cost of the cloud infrastructure. In a subsequent work [7], a trade-off between security and performance is investigated by changing the amount of code that is moved to the cloud. In fact, cloud cost could be reduced by moving part of the sensitive code back to the client, at the cost of a less secure solution. ...
Article
Java bytecode is a quite high-level language and, as such, it is fairly easy to analyze and decompile with malicious intents, e.g., to tamper with code and skip license checks. Code obfuscation was a first attempt to mitigate malicious reverse engineering based on static analysis. However, obfuscated code can still be dynamically analyzed with standard debuggers to perform step-wise execution and to inspect (or change) memory content at important execution points, e.g., to alter the verdict of license validity checks. Although some approaches have been proposed to mitigate debugger-based attacks, they are only applicable to binary compiled code and none address the challenge of protecting Java bytecode. In this paper, we propose a novel approach to protect Java bytecode from malicious debugging. Our approach is based on automated program transformation to manipulate Java bytecode and split it into two binary processes that debug each other (i.e., a self-debugging solution). In fact, when the debugging interface is already engaged, an additional malicious debugger cannot attach. To be resilient against typical attacks, our approach adopts a series of technical solutions, e.g., an encoded channel is shared by the two processes to avoid leaking information, an authentication protocol is established to avoid Man-in-the-Middle attacks and the computation is spread between the two processes to prevent the attacker to replace or terminate either of them. We test our solution on 18 real-world Java applications, showing that our approach can effectively block the most common debugging tasks (either with the Java debugger or the GNU debugger) while preserving the functional correctness of the protected programs. While the final decision on when to activate this protection is still up to the developers, the observed performance overhead was acceptable for common desktop application domains.
... The purpose of this paper is to assess the effectiveness of the Client/Server Code Splitting protection, therefore, we do not to repeat all the details of the technique. Interested readers can find more information about the technique and the validations already performed in previous papers [6,5,24]. ...
... The trade off between security loss and run time performance of the program being protected was assessed experimentally on a car race game [5]. Client/Server Code Splitting has been applied to the car race game, so as to produce an initial set of 1,000 cuts (subsets of the barrier slice) of the program to be protected. ...
... Finally, we are interested in studying how hard it is to understand and tamper with a program. We are not interested in evaluating how hard it is to decompile or disassemble compiled code, because there are quite good tools to (at least partially) automate this task 5 . Thus, even if the source code might not be immediately available to an attacker in an intelligible form (e.g., because the program is a compiled binary machine code or it has been obfuscated), we assume that source code almost as comprehensible as the original source could be obtained with proper effort. ...
Article
Full-text available
Context Code hardening is meant to fight malicious tampering with sensitive code executed on client hosts. Code splitting is a hardening technique that moves selected chunks of code from client to server. Although widely adopted, the effective benefits of code splitting are not fully understood and thoroughly assessed. Objective The objective of this work is to compare non protected code vs. code splitting protected code, considering two levels of the chunk size parameter, in order to assess the effectiveness of the protection - in terms of both attack time and success rate - and to understand the attack strategy and process used to overcome the protection. Method We conducted an experiment with master students performing attack tasks on a small application hardened with different levels of protection. Students carried out their task working at the source code level. Results We observed a statistically significant effect of code splitting on the attack success rate that, on the average, was reduced from 89% with unprotected clear code to 52% with the most effective protection. The protection variant that moved some small-sized code chunks turned out to be more effective than the alternative moving fewer but larger chunks. Different strategies were identified yielding different success rates. Moreover we discovered that successful attacks exhibited different process w.r.t. failed ones. Conclusions We found empirical evidence of the effect of code splitting, assessed the relative magnitude, and evaluated the influence of the chunk size parameter. Moreover we extracted the process used to overcome such obfuscation technique.
... In order to further support our analysis of the detection ability of IM we have used data from an experiment involving master students from Politecnico di Torino. The experiment has been performed in the context of the ASPIRE project and aimed at checking the ability of the client-server code splitting technique [45]. Students were asked to attack the gamespace application, a testing application for the ncurses library, that shows the user an interface where a set of entities are moving. ...
Article
Full-text available
Invariants monitoring is a software attestation technique that aims at proving the integrity of a running application by checking likely-invariants, which are statistically significant predicates inferred on variables' values. Being very promising, according to the software protection literature, we developed a technique to remotely monitor invariants. This paper presents the analysis we performed to assess the effectiveness of our technique and the effectiveness of likely-invariants for software attestation purposes. Moreover, it illustrates the identified limitations and our attempts to improve the detection abilities of this technique. Our results suggest that, although further studies and future results might increase its effectiveness and reduce the side effects, software attestation based on likely-invariants is not yet ready for the real world. Software developers should be warned of these limitations, if they would be tempted by adopting this technique, and companies developing software protections should not invest in development without investing in further research too.
... Client/Server Code Splitting transforms a program such that part of the computation is moved to a remote server. This transformation was initially designed as a way to protect programs from malicious tampering [7,8]. In fact, if sensitive portions or critical functionalities are moved to a remote server, they can run securely and without being tampered with by the attacker. ...
... The identification of the most appropriate part to split can be automated, for example as suggested by Ceccato et al. [8]. They relied on static analysis to identify and minimise control and data dependencies that would be impacted by the transformation. ...
... The implementation of the proof-of-concept prototype described in this paper misses the automatic decision of the optimal slice extent. Although automation can be implemented according to algorithm available in the literature [8], the current implementation requires to manually annotate slicing barriers and criteria. Once barriers and criteria are available, the computation of the slice and all the program transformation steps are fully automated. ...
Conference Paper
Anti-tampering is a form of software protection conceived to detect and avoid the execution of tampered programs. Tamper detection assesses programs' integrity with load-or execution-time checks. Avoidance reacts to tampered programs by stopping or rendering them unusable. General purpose reactions (such as halting the execution) stand out like a lighthouse in the code and are quite easy to defeat by an attacker. More sophisticated reactions, which degrade the user experience or the quality of service, are less easy to locate and remove but are too tangled with the program's business logic, and are thus difficult to automate by a general purpose protection tool. In the present paper, we propose a novel approach to anti-tampering that (i) fully automatically applies to a target program, (ii) uses Remote Attestation for detection purposes and (iii) adopts a server-side reaction that is difficult to block by an attacker. By means of Client/Server Code Splitting, a crucial part of the program is removed from the client and executed on a remote trusted server in sync with the client. If a client program provides evidences of its integrity, the part moved to the server is executed. Otherwise, a server-side reaction logic may (temporarily or definitely) decide to stop serving it. Therefore, a tampered client application can not continue its execution. We assessed our automatic protection tool on a case study Android application. Experimental results show that all the original and tampered executions are correctly detected, reactions are promptly applied, and execution overhead is on an acceptable level.
... Процедура аутентификации пользователя может быть выполнена единожды на начальном этапе при создании сессии соединения и поэтому не учитывается при конфигури- ровании. В качестве базовых компонентов защиты рассматриваются компоненты , обеспечивающие:  Защиту беспроводного канала передачи данных (HTTPSпротокол , протокол TCP/IP и алгоритмы симметричного шифрования AES, 3DES);  Защиту данных на сменном носителе [21] (Симметричное шифрование носителя);  Защиту ПО на основе удаленной аттестации (контроль контрольных сумм);  Защиту ПО путем реализации исполнения ПО с применением шифрования (метод Аусмита [5]);  Защиту ПО на основе разделение кода (Метод барьерного разделения кода [6]). ...
Article
Исследование посвящено изучению вопросов проектирования и анализа комбинированных механизмов защиты сложных коммуникационных систем со встроенными и мобильными устройствами. В работе вводится понятие конфигурации устройства, которая представляет собой комбинацию компонентов защиты, развертываемых для поддержки безопасности устройства, а также предоставляемых им программных сервисов. На основе решения оптимизационной задачи с учетом функциональных и нефункциональных свойств отдельных компонентов защиты производится поиск наиболее эффективной конфигурации. Анализ эффективности предложенного подхода к конфигурированию осуществляется на основе экспериментов путем его сравнения с альтернативными стратегиями конфигурирования. В частности, производится сравнение со стратегией «произвольного конфигурирования», которая представляет сценарий «ручного» конфигурирования, проводимого оператором системы без использования автоматизированных средств перебора и оценки возможных конфигураций.
... This solution introduces both a communication overhead and a computation overhead on the server. The trade-off between security and cost of this protection scheme has been studied [4] to search for an optimal solution. ...
Article
Full-text available
CodeBender implements a novel client replacement strategy to counter the malicious host problem and address the problem of guaranteeing client-code security. CodeBender is a tool that implements a novel client-replacement strategy to counter the malicious host problem. It works by limiting the client code's validity and, when the code expires, by having the server provide a new client that replaces the former one. The complexity of analyzing frequently changing, always different (orthogonal) program code deters an adversary's reverse engineering efforts. We've implemented CodeBender and tested its practicability in two case studies.
... This solution introduces both a communication overhead and a computation overhead on the server. The trade-off between the security and cost of this protection scheme has been studied in [5]. It is worth mentioning that the idea of splitting an application between client and server has been already used by Zhang and Gupta in order to prevent software piracy [19]. ...
Conference Paper
Full-text available
ABSTRACT In a typical client-server scenario, a trusted server provi des valu- able services to a client, which runs remotely on an untrusted plat- form. Of the many,security vulnerabilities that may,arise (such as authentication and authorization), guaranteeing the inte grity of the client code is one of the most difficult to address. This secur ity vul- nerability is an instance of the malicious host problem, where an adversary in control of the client’s host environment,tries to tamper with the client code. We propose a novel client replacement,strategy to counter the malicious host problem. The client code is periodically replaced by new orthogonal clients, such that their combination with the server is functionally-equivalent to the original client-server application. The reverse engineering efforts of the adversary are deterr ed by the complexity of analysis of frequently changing, orthogonal program code. We use the underlying concepts of program,obfuscation as a basis for formally defining and providing orthogonality. W e also give preliminary empirical validation of the proposed,approach. Categories and Subject Descriptors C.2.0 [Computer-communication networks]: General—Security
Preprint
Full-text available
Man-at-the-end (MATE) attackers have full control over the system on which the attacked software runs, and try to break the confidentiality or integrity of assets embedded in the software. Both companies and malware authors want to prevent such attacks. This has driven an arms race between attackers and defenders, resulting in a plethora of different protection and analysis methods. However, it remains difficult to measure the strength of protections because MATE attackers can reach their goals in many different ways and a universally accepted evaluation methodology does not exist. This survey systematically reviews the evaluation methodologies of papers on obfuscation, a major class of protections against MATE attacks. For 572 papers, we collected 113 aspects of their evaluation methodologies, ranging from sample set types and sizes, over sample treatment, to performed measurements. We provide detailed insights into how the academic state of the art evaluates both the protections and analyses thereon. In summary, there is a clear need for better evaluation methodologies. We identify nine challenges for software protection evaluations, which represent threats to the validity, reproducibility, and interpretation of research results in the context of MATE attacks.
Conference Paper
Malicious reverse engineering is a prominent activity conducted by attackers to plan their code tampering attacks. Android apps are particularly exposed to malicious reverse engineering, because their code can be easily analyzed and decompiled, or monitored using debugging tools, that were originally meant to be used by developers. In this paper, we propose a solution to identify attempts of malicious reverse engineering on Android apps. Our approach is based on a series of periodic checks on the execution environment (i.e., Android components) and on the app itself. The check outcome is encoded into a Magic Number and send to a sever for validation. The owner of the app is then supposed to take countermeasures and react, by disconnecting or banning the apps under attack. Our empirical validation suggests that the execution overhead caused by our periodic checks is acceptable, because its resource consumption is compatible with the resources commonly available in smartphones.
Thesis
Full-text available
Today’s computing platforms are becoming more and more mobile and networked, while their tasks get increasingly critical. Therefore, the need to verify and identify that a local or remote computing platform behaves as expected has become an important challenge. Software and hardware attestation protocols have been proposed to solve this problem in the past few years. While many vulnerabilities and attacks have been discovered against the proposed software based solutions, hardware based solutions are too costly for lightweight embedded devices. Recently, lightweight solutions requiring minor hardware changes have been proposed for the low-end embedded devices. One of the state of the art approaches is SMART (Secure and Minimal Architecture for Root of Trust), in which memory accesses are controlled by looking at the program counter (PC), proposed by El Defrawy et al. In this thesis, SMART is designed for 8051 platform on a Spartan 6 CGS324 FPGA. This is the first implementation of SMART architecture that shows the cost of the modifications to hardware in terms of area and speed. In addition, a novel hardware architecture that changes memory access layout in order to provide better attestation program in terms of code size and speed is proposed. It is shown that the size of additional program code decreased by 36% and attestation speed is increased by 12% while the area and speed of hardware is optimized. Moreover, 224 bit SHA3 (KECCAK[r=40, c=160]) software is implemented for 8051 by using assembly (ASM) and C programming languages with SDCC compiler. The trade off between code size and speed of SHA3[r=40, c=160] is presented with several implementations. No other SHA3[200] implementation for 8051 can be found in the literature at the time of this thesis is written.