Enforcing the security of component-based embedded systems with Information Flow Control

Takoua Abdellatif LIP2/ESSTHS

University of Sousse, Tunisia Takoua.Abdellatif@essths.rnu.tn

Nejla Rouis FSEGS

University of Sfax, Tunisia Nejla.Rouis@yahoo.fr

Wafa Saïdane ENISO

University of Sousse, Tunisia Waf_saidane@yahoo.fr

Tahar Jarboui Proxym-IT

www.proxym-it.com Tahar.jarboui@proxym-it.com

Abstract—Information Flow Control (IFC) is mandatory to enforce the confidentiality and the integrity of data. It is a technique implemented in recent operating systems to track the information flow in the applications and therefore detect security leakage. In this paper, we apply this technique to a component-based Framework for securing embedded systems. We demonstrate the gain the component-based architecture provides to extend the Framework with no visible overhead on the nominal execution of the system.

Keywords: Component-based architecture; Software Security; Information Flow Control (IFC); embedded systems, Think Framework

I. INTRODUCTION Embedded systems, ranging from cars to cell phones,

mp3 players and home equipments, dominate more and more our lives. The security of these systems is a real challenge since embedded applications are generally constructed by developers that are not necessarily experts in security. Furthermore, embedded systems are often highly cost-sensitive and adding security features can increase highly this cost. Thus developing security in embedded systems has to be based on practical solutions, simple to implement, to configure and to reconfigure when needed without requiring specific expertise and without introducing resource overhead.

Like in other systems, access control is classically the security policy considered in embedded systems for controlling the secrecy and integrity of data. Nevertheless, this is not enough to ensure an end to end security. For example, if we consider three processes p1, p2 and p3. p2 may have access to p1’s data and p3 may have access to p2’s data. Nevertheless, how to control that p2 is not going to send secret p1’s data to p3? This issue is called the interference problem. Information Flow control (IFC) is a technique consisting in tracking how data flow between processes. IFC allows controlling the spreading of secret information and their integrity. Recent studies [10] [9] focus on building IFC operating systems to control the interactions between processes. To reach this goal, they attribute security levels to data called Labels. Data have the right to flow only to data with more restricted level. Otherwise, a security leakage may occur. The application of these solutions to embedded systems is not directly possible. Indeed, each embedded system comes with its particular operating system and

rebuilding the embedded OS with IFC for each system configuration is a tedious and costly work especially for small teams that are not generally experts in security. For this reason, we find more interesting to address the IFC for component-based embedded systems. Indeed, component-based engineering (CBSE) used to be an interesting approach to hide the heterogeneity of embedded systems and to simplify the development of embedded applications. In a component-based system, each part is encapsulated in a component which represents an independent unit of configuration and deployment. The components are explicitly bound with communication bindings that are established at deployment time independently of the component code. Bindings can also be broken and re-established at configuration time. These features are very interesting to track how data are exchanged between components and therefore to build IFC. In this paper, we extend the Think Framework [1] [2] which is a component-based embedded system in order to provide IFC to embedded applications. We demonstrate how to secure a classical embedded application thanks to IFC without performance degradation. Our work shows also the benefits that component-based architecture can provide to implement IFC. Even though our experience is based on the Think Framework, we show that it is applicable to any other component-based systems.

The rest of the paper is structured as follows. First, we present the main works related to ours. Then, we present the component-based system properties and the Think Framework. Then, in section IV, we highlight the need for IFC through the description of the security requirements. In section V, we introduce information flow control and its main concepts. Then, we demonstrate how IFC can be applied to Think, in section VI. In section VII, we present our evaluation results. Finally, in section VIII, we conclude and present future works.

II. RELATED WORKS

A. Security in embedded systems Security works in embedded systems rely generally on

cryptographic algorithms. For example security protocols, as IPSec [13] and SSL [14], ensure secure communication channels between embedded systems. Besides, other works propose new architectures to preserve the confidentiality and

International Conference on Wireless and Ubiquitous Systems 8-10 October 2010, Sousse, TUNISIA

978-1-4244-9257-2/10/$26.00 ©2010 IEEE

integrity of code and data [16] [17] [15] by blocking illegal accesses to protected areas in memory. IFC-based applications built on top of these solutions can take profit of the isolation features they provide.

Regarding the component-based approach, recent embedded systems rely on the explicit component-based architecture to enforce security. For instance, CAmkES [6] presents a layered architecture following a component model where the component is the unit of encapsulated behaviour. Components expose interfaces that allow applications and other components to access their features through explicit architectural elements called connectors and connections. CAmkES runs on the L4/Iguana embedded operating system, so it profits from the features it provides, especially for security. Indeed, the main security model provided by CAmkES is based on Iguana’s capability model that enforces access control provided to components at the connector level. Different access control mechanisms can co-exist by using different connectors which shows the flexibility of the component-based architecture for developing security policies. Nevertheless, the interference problem is not addressed. We believe that our solution can be directly applied to CAmkes since it relies only on component interfaces and connections abstractions.

Like our work, CRACKER [5] proposes an extension of the Think Framework to secure component-based systems built with Think. The CRACKER security architecture introduces two security components, the Reference Monitor (RM) and the Policy Manager (PM). The RM intercepts the inter-component calls at runtime and the PM checks the access rights. The interception mechanisms is very costly, the reason why CRACKER suffers from performance issues. Nevertheless, the component-based architecture provides a wide range of authorization policies, and permits policy reconfiguration, in the same or in different security models. Our work is similar as CRACKER in implementing security policies in separate components for flexibility and reconfiguration. We additionally handle the interference issue not addressed in CRACKER.

B. OS-based IFC solutions There has been much work on IFC for OS like Flume [4],

Histar [10], Asbestos [9]. These solutions target securing enterprise machines equipped with rich resources and cannot be directly used in embedded systems. Furthermore, it is not clear how to reuse or adapt these solutions to the embedded systems. The component abstraction helps reusing code since the security configuration is independent of the encapsulated code and hardware. Moreover, in our work we address the dynamic reconfiguration issue which is not addressed in the above solutions.

The idea of using components for IFC has been proposed in a previous work for distributed systems [8]. In this work, the focus was put on deployment in a distributed un-trusted network. The preservation of security properties at runtime when a reconfiguration occurs is not addressed. Furthermore, a coarse-grained granularity (components encapsulating servers) is considered whereas, we consider in this work components co-located in a same device. Therefore, we do not address the same security model and not the same performance requirements.

III. THINK: A COMPONENT-BASED FRAMEWORK

Think is a framework to design and build embedded component based software. It is an open source C implementation of the FRACTAL [3] model for the development of embedded Kernels.

Figure 1. Main concepts of the fractal component model

As illustrated in Figure1, a component is the unit of (re)configuration in THINK. It interacts with its environment (other components) through typed interfaces specified using a language-agnostic Interface-Description-Language (IDL). For a given component, we distinguish the interfaces provided by the components (that correspond to a service offered by the component such as a memory manager or thread scheduler) from the interfaces that are required by the components (and that corresponds to services needed by the component). THINK components are recursive: a component can act as a container of sub-components. Components are connected together (via their interfaces) through bindings. A binding is a communication channel between components. Thus communications are generally based on method calls through bindings between client and server interfaces. Components and bindings between component interfaces are specified in ADL (Architecture Description Language). Furthermore, the THINK software framework comes bundled with a library of reusable component called KORTEX that provides various operating system services such as CPU scheduling, interrupt handling, networking and file systems.

Besides, many works [7] show the efficiency of the Think Framework to support easily and efficiently typical non-functional properties. Actually, view specific architectural patterns were defined and implemented in think to enforce property-specific views on a target system (Behavioural view, Reconfiguration view, Protection view, Isolation view and Quality of Service View). In our work, we take profit from the isolation property that helps tracking the flow of information in the system.

IV. SECURITY REQUIREMENTS Access control is a classical security property that has to

be provided in any embedded system. It guarantees the protection of confidential data from being read or modified by unauthorized users. Access control can be implemented as a separate component or as a controller within a single component. Like in CRACKER [5], the goal is checking the identity of messages going through input interfaces.

Nevertheless, the access control falls short to guarantee an end to end application security. Indeed, it helps to prevent information release but not to regulate the propagation of information after it has been released for processing by a program. Suppose the following component-based

application secured with access control, which means only authorized communication bindings can be established between components. For instance, a component A is allowed to read a component B's data. As B cannot control how A distributes the information it has read, an attacker, having knowledge about the source code of the program, can deduce information about B’s data from the public outputs of A. This leads to the interference problem. It is required to enforce the data security with information flow control. In order to illustrate our solution on a real scenario, let us consider the calendar component-based application developed with Think and presented in Figure 2.

Figure 2. Scenario of a simple calendar application

The calendar application can be embedded in any device

or machine (car, rented printer, etc.) and be shared between a set of users. The Terminal component encapsulates the program interacting with users. The Meeting_manager is in charge of checking the availability of users from their registered calendars when a meeting is proposed. Finally, the File-server component contains the code accessing to users calendars. Let us consider the following scenario, the users Alice and Bob keep respectively private data files calendar_Alice, calendar_Bob describing their schedules. Bob wants to schedule a meeting with Alice so he suggests some meetings and waits for a response. The Meeting_manager component examines these suggestions in accordance with data read from calendar_Alice and calendar_Bob then informs the Terminal component if these meetings are available or not. If Bob is a malicious user, he can deduce information about Alice’s calendar by testing several meeting proposals which leads to the interference problem. The challenge here is to let the Meeting_manager combine Alice’s and Bob’s private data without leaking information unless Alice chooses to reveal her private data to Bob as she considers him a trusted user.

V. INFORMATION FLOW CONTROL TOOLS In order to describe the security level of components and

data, we reuse the Lables and Capablities defined in the Flume [4] system. In this section, we describe these tools as presented in the Flume system. We explain how they are adapted to component-based systems in section VI.

A. Labels A Label indicates the security level of a process in terms

of confidentiality Sp (secrecy) and integrity Ip (integrity). Each Label is a set of tags; a tag is a marker associated with data. For example a process p has the Label Sp = {Alice, Bob} means that p contains secret data of Alice and Bob. And p has the integrity Label Ip = {Alice} means that Alice

certifies that the data is approved by her. The set of Labels defines a Lattice with a partial order which allows classifying the data secrecy and integrity. For example, if we have two processes p1 and p2 with respectively Sp1={Alice, Bob} and Sp2={Bob} means that p1 is more restrictive than p2. Respectively, if we have Ip1={Alice, Bob} and Ip2={Bob} means that p2 is more restrictive than p1.

B. Capabilities A capability is a marker that indicates a process’s ability

to add or remove its tags. Each process has a set of capabilities Op. For example, a process having Op = {T+, T -}, means that p owns T+ capability giving it the privilege to add the tag T to its Labels; and owns T – capability giving it the privilege to remove the tag T from its Labels.

For secrecy Labels, adding a tag T (clearance) means having the permission to receive secret information tainted T. Removing it (declassification) means that the process can communicate previously classified information.

For integrity Labels, adding a tag T (endorsement) means that a process can require additional integrity restrictions on received data and enforce integrity on sent data.

Suppose a system containing two processes p and q with the following Label configuration:

As p has a+ and a- capabilities, it can receive and communicate data tainted a and it can endorse or downgrade the security of these data. p reads data from a file A tagged by the tag a, so p contains secret data from file A certified by A. Supposing now that p wants to send data to process q. This communication is not tolerated as p contains secret data that q hasn’t seen. Thanks to the concept of capabilities, the process p, considered as trusted process, can temporarily declassify data tainted a and so there is no secrecy violation any more and communication is tolerated.

VI. APPLYING INFORMATION FLOW CONTROL TO THINK

In order to specify the security level of exchanged messages, the developer in Think has to attribute Labels to the communication interfaces. As applied to privacy, assigning secrecy Label S to an output interface I1 means that all messages sent through I1 need to keep the level of privacy S. For an input interface I2, having the secrecy Label S means that received messages will be treated as having the level of privacy S.

As applied to integrity, assigning integrity Label I to an output interface I1 means that all messages sent through it are certified and having I as level of integrity. For an input interface I2 having the integrity Label I, I2 receives only messages with at least I as integrity level.

Therefore, a communication between two components C1 and C2 with respectively output interface I1 and input interface I2, is tolerated only if S(C1.I1) ⊆ S(C2.I2) (“no read up, no write down” [11]) and I(C2.I2) ⊆ I(C1.I1) (“no read down, no write up” [12]).

S p= {a} Sq ={} Op = {a+, a-} I p = {a} Iq = {} Oq = { }

Furthermore, within a single component C with input interfaces I1, I2 , In and output interface I’, the system has to forbid the output messages from I’ to reveal secret input data coming from input interfaces. Therefore, we have also to check the following dependency relation between the union of I1, ..,, In secrecy Labels and the I’ secrecy Label: SI’ ⊆

∪ ( SI1,SI2, ., SIn.). Similarly, the dependence relation between

the intersection of I1, I2, ... In integrity Labels to I’ integrity Label needs to be maintained : ∩ (II1, II2, ..., IIn ) ⊆ II’. These

dependency rules have to be ensured for each output. The capabilities are attributed to components. Their role is to control when a Label modification (mainly endorsement or declassification) is possible. In other words, capabilities represent the policy for dynamic security modification. A dynamic security policy can be changed when the administrator authorises relaxing a security constraint and allows an interference to occur at a precise state of the system.

Therefore, the system has to ensure that the safety rules (the intra-component and inter-component dependency rules) are respected at the configuration and deployment time as well as at runtime even when the system architecture changes. In order to achieve this task, we introduce to Think Framework a set of security components presented in Figure 3: the Factory component and the IFCmanager (Information Flow Control Manager).

Note that in our work, the bindings are unidirectional message-based communications, whereas in Think they are generally based on method calls. Since it is important to distinguish between security Labels of sent messages and returned one, it is easier to adopt message-based communications. However, the same principle is applicable to method calls by specifying the labels of parameters and returned values.

Figure 3. Calendar application enforced with IFC

In Figure 3, we have the overall architecture of the extended Think Framework and its application to the Calendar application. We explain in this section, the role of each security component and how they help in securing the calendar application. At configuration step, the administrator

has to attribute the security Labels and Capabilities to component ports. The security components check the security rules and allow or not accordingly the binding establishment. For system configuration, the Label is a specific property that can be set directly in the ADL or in the code of a component. Each component is enhanced with a provided interface for configuring the Label properties. The set of these Labels presents the initial Label configuration of the system. At deployment time, this configuration is verified by the IFCmanager in order to build the initial architecture of the system. At execution time, the administrator can modify the Labels respecting the component Capabilities or modify the system architecture by adding or removing components or bindings. For each reconfiguration, the system has to check again the safety rules.

A. Factory component It is an extension of the classical binding controller of

Think Framework. Before creating a component instance or a binding, the Factory asks the IFCmanager if the safety rules are respected.

B. IFCmanager component It is a composite component that stores the list of

interfaces with their Labels, the capabilities of each component and the binding’s states. The IFCmanager is consulted in two situations: at deployment time and for each Label modification. We distinguish between valid and invalid bindings. A valid binding corresponds to the one respecting the IFC safety rules; otherwise this binding is set invalid. When a reconfiguration occurs, leading to the modification of a Label, the IFCmanager is consulted to calculate the states of the systems bindings. It reads the Labels of each interface from the configuration files and then decides, according to the safety rules, about the validity of the binding between interfaces. Once the binding is valid, the IFCmanager changes the state of the binding to valid and notifies the Factory to establish it. If we have an invalid binding, the IFCmanager checks the capabilities of the component to verify if it has the privilege to declassify/clearance secrecy Labels or to endorse/downgrade integrity Labels. When the component succeeds to update the Labels of the interface considered, so that the state of the binding changes to valid and the binding is created, else the state of the binding remains invalid and the binding is broken.

At runtime, the system executes according to the initial architecture unless a change of a Label occurs. A Label change can break the validity of established bindings and can be propagated to the rest of the system. Indeed, if an input interface Label changes in a component, the output interfaces Labels need to be checked and possibly modified. If no Label modification is authorized and/or the IFC rules are not respected, the binding becomes invalid and the Factory is notified to break it. Inside the IFCmanager composite, the Decision component stores the Labes and the state of bindings. The Administration component exposes the interfaces that the human administrator can use to configure or reconfigure the system. Finally, the Policy component allows implements the system policy. It takes the decision when a label can change.

The Figure 4 presents the communication message exchange between the system components of the Calendar application and the security components. At deployment or

reconfiguration time, the Factory consults the IFCmanager to check the validity of components and bindings. For example, in the previous scenario, the initial Label configuration is set with the intention that the connected user will consult his private calendar, so according to this configuration the binding between (Terminal.I2) interface and (Meeting_manager.I2) interface is established, since there is no risk of revealing the privacy of his data. Therefore, the user can have a response for each request he sends and exploits the content of his calendar.

Figure 4. Communication flow between system components

Suppose now that, Bob wants to propose a meeting to Alice. The File_server will read from Alice’s calendar. Consequently, the File-server interfaces Labels are set at least to the Labels of Alice’s calendar:

As the interface (File_server.I3) is bound to (Meeting_manager.I3), its configuration has to be modified to lead to a valid binding. Indeed, according to the safety rules, there is a secrecy violation as:

Right now, the binding between File_server.I3 and Meeting_manager.I3 is invalid, but the IFCmanager should check the capabilities of the component Meeting_manager to check if declassification is possible. For this case, IFCmanager should check if Meeting_manager has the privilege to add the tag a to its secrecy Labels which means

that this interface accepts private data tainted a. According to its set of capabilities O+= {a, b}, it has this privilege and so the change can be done.

After declassification, the resulting Labels will be:

At this stage,

there is no secrecy or integrity violation and the binding that becomes valid is established. Allowing this binding means that the component Meeting_manager is allowed to contain and transfer some private data about Alice. This administrator configuration, tolerating the declassification, assumes that there is no risk to reveal this private data at this system state.

As every change of input interface Labels infers to the change of output interface Labels, all output data Labels need to be recalculated for safety rule preservation. In our example, the change that occurred in the input interface (Meeting_manager.I3) Labels causes the change in Labels of the output interfaces: (Meeting_manager.I2) and (Meeting_manager.I4).

Similarly, the interface (Meeting_manager.I4) is bound to interface (File_server.I4), this binding should be recalculated as well as the binding between (Meeting_manager.I2) and (Terminal.I2). According to the IFC rules, these bindings are temporarily invalid:

The IFCmanager has to refer to the set of capabilities O-

= {}, and checks if it has the privilege to declassify Bob’s private data (to write it in the private file of Alice), and Alice’s private data (to show it to Bob on the Terminal). Nevertheless, this is not the case as O-= {} doesn’t contain a or b.

Consequently, the secrecy violation persists yet and these bindings are invalid and so broken. The change of the initial Label configuration causes the change of the initial architecture presented in Figure 5.

S (File_server.I3) = {a}, I (File_server.I3) = {a} S (File_server.I4) = {a}, I (File_server.I4) = {a}

S(File_server.I3)={a};S(Meeting_manager.I3) ={b}

S(File_server.I3) ⊄ S(Meeting_manager.I3)

secrecy violation

I(Meeting_manager.I3)={} ⊆ I(File_server.I3)={a}

S(Meeting_manager.I3)={a,b}

I(Meeting_manager.I3)={}

S(Meeting_manager.I2)={a,b}

I(Meeting_manager.I2)={}

S(Meeting_manager.I4)={a,b}

I(Meeting_manager.I4)={}

S(Meeting_manager.I2)={a,b}; S(terminal.I2)={b}

S(Meeting_manager.I2) ⊄ S(terminal.I2)

secrecy violation

S(Meeting_manager.I4)={a,b};

S(File_server.I4)={a}

S(Meeting_manager.I4) ⊄ S(File_server.I4)

Figure 5. System architecture after reconfiguration

According to this architecture, the application protects Alice’s private data from being revealed to Bob as the binding between (Meeting_manager.I2) and (Terminal.I2) is broken. Thus, Bob has no idea about the availability of the meeting he proposed and has to wait for a response from Alice. Also, since the binding between (Meeting_manager.I4) and (File_server.I4) is broken, there is no risk to leak Bob’s private data to Alice’s calendar.

VII. PERFORMANCE EVALUATION We evaluate the overhead of the Think Framework

extension in terms of memory and processing time. We ran a simulation of Think, version NUPTSE, on an ubuntu V 9.10 Linux distribution with a 2.6.31-21-generic kernel. We performed our tests on an INTEL(R) core(TM) 2 Duo T6500 @2,10GHz machine with 3 GB of RAM. The Think kernel was compiled with gcc 4.4.1.

The memory required to introduce the IFCmanager is about 139 KB which is comparable to an application component (the three application components require 428.8 KB). Regarding the processing time, it is important to mention that the IFCmanager is executed at deployment time and if a reconfiguration occurs which means that there is no overhead on the nominal running of the application. For verifying a binding validity, 0.132 ms is required. This number is obviously multiplied by the number of bindings to obtain the needed time for security checking at deployment or reconfiguration time. For our application, this means 0.528 ms. These results show an acceptable overhead of the Think Framework extension.

In terms of development time, the developer needs only to set security configuration parameters either in the ADL file or directly in the code. Setting the security properties of a system becomes an administration task since it only requires a configuration effort. The developer is not asked to be expert in security and to write a new code for each application. These properties are very important to reduce the development time and cost.

VIII. CONCLUSION AND FUTURE WORK This paper presents a solution for IFC in component-

based embedded systems. We applied this solution as an extension for the Think Framework. We demonstrate through a classical application how this can enforce the secrecy of data with no observable overhead. We notice that our work is applicable to any other component-based system since it assumes only the existence of bindings and components as abstractions. The encapsulated code is not taken into account. This feature is important to secure embedded systems which are generally an assembly of heterogeneous code. The

security properties are set at configuration time and there is no need to be expert in security to understand the system functionality. Again, this feature is important in embedded system context where the developers are small teams not necessarily aware of advanced security issues. As a future work, we intend to generalize our approach to secure the distributed services the embedded devices are communicating with and to introduce cryptography for securing remote communications.

REFERENCES [1] J.-P. Fassino, J.-B. Stefani, J. Lawall, and G. Muller, “Think: A

Software Framework for Component-Based Operating System Kernels,” in USENIX Annual Technical Conference, 2002.

[2] Think web site. http://think.ow2.org/

[3] E. Bruneton, T. Coupaye, M. Leclerc, V. Quema, J.-B. Stefani, “The Fractal Component Model and its Support in Java”, Software - Practice and Experience (SP&E), special issue on Experiences with Auto-adaptive and Reconfigurable Systems, 36, no 11-12, 2006, pp. 1257-1284.

[4] M. Krohn, A. Yip, M. Brodsky, N. Cliffer, M. F. Kaashoek, E. Kohler, and R. Morris, “Information flow control for standard OS abstractions”, In Proc. of the 21st SOSP, Stevenson, WA, October 2007.

[5] T. Jarboui, M. Lacoste and H. Ruan, “A component-Based policy-Neutral Architecture for Kernel-Level Access Control”. Annales des Télécommunications 64(1-2): 121-146 (2009)

[6] I. Kuz, Y. Liu, I. Gorton, and G. Heiser, “CAmkES: A Component Model for Secure Microkernel-Based Embedded Systems”, Journal of Systems and Software, vol. 80, no. 5, pp. 687– 699, 2006.

[7] A. Matthieu, H. Ruan, T. Jarboui, M. Lacoste, O. Lobry, G. Lorant, M. Louvel, J. Navas, V. Olive, J. Polakovic, M. Poulhiès, J. Pulou, S. Seyvoz, J. Tous and T. Watteyne, “Think: View-Based Support of Non-Functional Properties in Embedded Systems”. ICESS’09

[8] L. Sfaxi, T. Abdellatif, Y. Lakhnech and R. Robbana, “IFC for distributed systems” (Contrôle du flux d’information des systèmes distribués à base de composants). Notere 2010, Tunisia.

[9] S. VanDeBogart, P. Efstathopoulos, E. Kohler, M. Krohn, C. Frey, D. Ziegler, F. Kaashoek, R. Morris, and D. Mazières. Labels and event processes in the Asbestos operating system. ACM TOCS, 25(4):11:1–43, December 2007.

[10] N. B. Zeldovich, S. Boyd-Wickizer, E. Kohler, and D. Mazières, “Making information flow explicit in HiStar”. In Proc. 7th OSDI, Nov. 2006.

[11] D. E. Bell and L. L. Padula. Secure computer system: Unified exposition and multics interpretation. Technical Report MTR-2997, Rev. 1, MITRE Corp., Bedford, MA, March 1976.

[12] K. J. Biba. Integrity considerations for secure computer systems. Technical Report MTR-3153, Rev. 1, MITRE Corp., Bedford, MA, 1976.

[13] IPSec Working Group. http://www.ietf.org/html.charters/ipsec-charter.html.

[14] SSL 3.0 Specification. http://wp.netscape.com/eng/ssl3/.

[15] Discretix Technologies Ltd. http://www.discretix.com.

[16] D. Lie, C. A. Thekkath, M. Mitchell, P. Lincoln, D. Boneh, J. C. Mitchell, and M. Horowitz, “Architectural support for copy and tamper resistant software,” in Proc. ACM Architectural Support for Programming Languages and Operating Systems (ASPLOS), pp. 168–177, 2000.

[17] G. E. Suh, D. Clarke, B. Gassend, M. van Dijk, and S. Devadas, “AEGIS: Architecture for Tamper-Evident and Tamper-Resistant Processing,” in Proc. Intl Conf. Supercomputing (ICS ’03), pp. 160–171, June 2003.