SELF-ADAPTABLE SECURITY ARCHITECTURE FOR POWER-AWARE EMBEDDED SYSTEMS

BULETINUL INSTITUTULUI POLITEHNIC DIN IAŞI Publicat de Universitatea Tehnică Gheorghe Asachi din Iaşi Tomul LVI (LX), Fasc. 3, 2010 SecŃia AUTOMATICĂ şi CALCULATOARE SELF-ADAPTABLE SECURITY ARCHITECTURE FOR POWER-AWARE EMBEDDED SYSTEMS BY NICOLAE ALEXANDRU BOTEZATU, VASILE ION MANTA and ANDREI STAN Abstract. Securing embedded systems is a challenging and important research topic due to limited computational and memory resources. Moreover, battery powered embedded systems introduce power constraints that make the problem of deploying security more difficult. This problem may be addressed by optimizing the trade-off between minimizing energy consumption and maintaining a proper security level. This paper proposes a self-adaptable security architecture for embedded systems. The proposed method points out a conceptual blueprint needed for the implementation of such self-adaptable mechanisms. An example case study is described in order to better understand how an adaptable security mechanism can be implemented, also pointing out the effect on energy consumption. Key words: embedded systems, power constrains, energy consumption, security. 2000 Mathematics Subject Classification: 68M01, 94C99. 1. Introduction Many embedded systems interact with the real world. Form microwave ovens to MP3 players and photo cameras to cell phones, embedded computing has a huge impact on our everyday life. The research and technological advances that made all this possible, determined an increase in the system s complexity, also spurring a downside: the raise of security costs. The development of new, faster, more feature rich embedded systems has boosted the emergence and improvement of security methods in parallel to ranges of new and more power types of attacks. While security method s and protocol s designers address the security

58 Nicolae Alexandru Botezatu et al. problem from a functional perspective (the traditional way), all embedded systems are constrained, in a way or another, by the available internal resources and the external environment dynamics. Also, security is often perceived by the system designers as an additional or optional feature. In fact, security should be considered in the design process along costs, performance and power. The problems arising from the aforementioned, between necessities and capabilities, are described and classified as a set of gaps [1]. One of these gaps, the battery gap, emphasizes the overheads in energy consumption introduced by supporting security on battery powered devices. This is due to the slow pace of advancement in battery technology that has not kept up with the progress in processing capabilities (and consequently energy consumption). Therefore, the primary challenge in providing security in battery powered embedded devices is to minimize power consumption and maximize security. Due to the conflicting nature of the two elements, there is an intrinsic need to understand the relation between energy consumption and security parameters. One way to approach this problem is by adaptable security. By changing in some automated or semi-automated way, the security mechanisms respond to internal or external system events, consequently causing a variation in energy consumption. The link between this variation and the dynamics of adaptable security must be determined in order to assess and optimize the energy consumption level. As the paper name implies, we propose a conceptual design for the infrastructure needed for adapting security, also providing a fundamental operational structure. We also suggest a functional description of the architecture s requirements by presenting an implementation example. The paper is organized as follows. Section 2 briefly outlines the related work presented in the literature. Section 3 explains the architecture and describes its components, whereas in Section 4 we present an implementation example. Section 5 highlights some perspectives for further research. 2. Related Work We focus on giving an overview on papers that cover the aspects of adaptable security or energy consumption, due to the lack of papers covering the two topics at theoretical level. We also centered over the papers presenting these aspect at a more practical level. Reference [2] proposes some guidelines for designing a standardized Adaptive Security Infrastructure (ASI). The problems raised by this concept are presented in a structured way and include: the components of an ASI, the principles and issues of formalization and the term of security policy described as a system specification. Also, the author proposes some broad research directions, covering the discussed topics. In [3] the self-adaptable security is addressed at system level, centered on the concept of security policy. The authors propose a domain-independent

Bul. Inst. Polit. Iaşi, t. LVI (LX), f. 3, 2010 59 methodology for system security adaptability. The security policy adaptability scheme allows the system to keep a constant security level even when certain stimuli influence it. Reference [4] presents an overview of the current trends in energyefficient computing. The strengths and weaknesses of present power management are discussed, considering the ACPI standard as a case study. Also, the author s vision on energy consumption reduction is presented as an optimization problem. Three stages are outlined for approaching a solution on energy-efficiency: constructing a power model; determining the performance requirements of tasks or the workload; implementing means of deciding an energy-efficient configuration of the hardware at all times while operating. In [5], the authors acknowledge the importance of constructing poweraware applications. The paper also briefly surveys some of the most recent directions in supporting power-efficiency for battery powered devices. Furthermore, a power efficiency framework is proposed which addresses both power consumption measurements and high level power efficiency metrics in a unified way, thus providing real-time feedback to applications. Next, in [6] the authors, using real-life experimentation based profiling, measure and model the power consumption of some cryptographic algorithms. Also, they propose a way for minimizing vulnerability subject to power constraints. The vulnerability metric is defined as a quantity dependent on the success probability of a cryptanalysis attack. This metric is used as the objective function to formulate two optimization problems. Moreover, the paper proposes algorithms that solve these problems, giving optimal power consumption and security vulnerability levels. The research presented in [7] deals with the implementation of security primitives on reconfigurable hardware. The reconfiguration thresholds are based on external events that point out any incoming attacks. The paper also presents a functional description for the monitoring blocks used to detect attacks and for the SSC (system security controller) and SPC (security primitive controller) that are used in the reconfiguration process. 3. Self-adaptable Architecture In this section we present our vision on the security self-adaptable method. As shown in Fig. 1 the architecture is based on three functional blocks: Sensing, Analysis and Enforcement. The data sets required as input for the blocks are represented by the System status, System descriptors and System goals. The workflow of the architecture is the following: when the Sensing block detects a change in the parameters defined in the data sets, it signals the Analysis block to determine what changes in security must be made in order to match some requirements defined in the System goals. Last, the Enforcement block applies changes to the system. The following subsections present the six new concepts.

60 Nicolae Alexandru Botezatu et al. 3.1. System Status The system status may be viewed uniquely defined by a set of specific parameters. These parameters can be grouped as internal or external, where the internal ones are specific to the systems hardware configuration (e.g. what functional blocks does the system have that can influence the status) and to the software applications that can run on the system (e.g. the application s requirements concerning different hardware properties of the system). As for the external parameters, they are represented by the systems external conditions as the user of the system (e.g. tasks that are defined or ran by the user) and the environment in which the system is operating (e.g. sunlight condition for systems with photovoltaic power cells). All this data is acquired through the use of monitoring devices and sensors. Fig. 1 Adaptive security architecture blocks and related relations. In general, for an application that needs to know the system status there must be defined a list of parameters that can influence the status of the system in the current context of operation. All the values of the parameters, the valid values transitions that are important for the applications, all the connections between the parameters and their values that are valid at system runtime must be analyzed. More, in order to have accurate information about the system, a comprehensive set of monitored parameters must be defined.

Bul. Inst. Polit. Iaşi, t. LVI (LX), f. 3, 2010 61 Also, the rate at which the system status is sampled is important. Different parameters may be sampled at different rates based on the speed of their temporal variation. The sampling rate may vary for the same parameter for specific intervals of its values (e.g. the sampling rate for the voltage of a NiMH cell can be raised for a Depth of Discharge (DOD) over 80%, due to the increase in voltage decline rate). Specific to the current architecture are the following properties that outline the system status: a) Current security level for every running application; b) The available energy of the system, expressed conveniently as a combination of drawn current, battery capacity, discharge rate, nominal power etc. An example of selected parameters is presented in Section 4. 3.2. System Descriptors The system descriptors are represented by a collection of data that describe the hardware and software components of the system. The data is organized in a hierarchical manner, based on a class collection that describes and groups the systems elements with respect to their energy and security properties. The base model for this branching hierarchy is presented in Fig. 2. The first three levels of the class collection make a broad classification of the system components, as from level four onwards specific classes may be derived in order to describe the system components (e.g. from the energy suppliers class we can derive new classes to describe batteries, photovoltaic cells or other types of supplies). Fig. 2 System descriptor hierarchy.

62 Nicolae Alexandru Botezatu et al. The properties of the objects that describe the hardware components depend on the operating modes used during application execution. A complete profile for every system element is obtained by describing the energy properties for all the operating modes, based on usage patterns. For example, if we consider a LCD backlight, the energy consumption must be determined and described for every backlight intensity mode available. By defining these properties, a connection is established between energy consumption, workload and operating mode. For the software components, security properties must be considered. Also, the objects describing the software components are used to determine their energy, workload and security footprints. In order to achieve this, the properties for the software components also specify the hardware resources used and how they are used. Concerning the security primitives, their properties are described for all the usage options available (e.g. different key lengths, variable number of encryption rounds) as a usage cost (e.g. energy consumption, hardware needs). Also, for the security primitives the throughput must be considered as a property for every usage option. 3.3. System Goals The system goals are determined based on the correlations between the energy resources of the system and its security demands. Ravi et al. in [1] have identified several gaps regarding the capabilities and demands of current embedded systems. In the context of the current architecture, the system goals are to be determined taking into account two of the proposed gaps: the battery and the flexibility gaps. The first one highlights that the current energy consumption overheads of supporting security on battery powered embedded devices are very high, whereas the second one emphasizes an embedded system s need to run a large and diverse set of security primitives and methods. Also, the authors state the existence of a processing gap because the current embedded architectures cannot keep up with the rising computational demands of new and more complex security algorithms. To sum up, the system goals must be described as a maximization of operating time while maintaining the requested security levels for the system. In order to better understand this concept, the following example is considered: an embedded system has two running applications A1 and A2. A1 processes two types of data, the first one requiring a security level of S1 and the second one S2. A2 needs a security level of S3. The system, using the built in security primitives can provide a maximum security level of Smax, where Smax=S3>S1>S2. So, if the system would consider a constant security level for all the applications, the extra

Bul. Inst. Polit. Iaşi, t. LVI (LX), f. 3, 2010 63 security delivered for application A1 would consume a part of the systems energy to no purpose. In order to decrease the used energy, the security level would have to be adapted to the application s needs, this process being transparent to the user. Moreover, if the security demands of an application varies at runtime, based on some environment variations (e.g. the transition from an unsecure wireless network to a secure one), this fact must also be considered when determining the system goals. 3.4. Sensing Block The sensing block monitors the state of the system. The states of the system are defined as the elements of a finite set S = {s 1, s 2,, s n }, those states being determined based on the combinations and correlations between the environment parameters (System status) and the system descriptors. When a state transition occurs this block decides if a request to reevaluate the security is sent to the Analysis block. Its purpose is to determine the state of the system and to filter out the transitions that are not relevant in the context of energy consumption optimization. On a time basis, the sensing block samples the environment parameters and system descriptors and evaluates an f function which has the aforementioned parameters, thus determining the system state. In order to filter out the transitions not relevant to the system a prediction module is used. Its role is to express a probability for any status transition. This means that following a state transition, the system must remain in the new state long enough to account for the extra energy used by the reevaluation of security and the related security setup cost (e.g. generation of new encryption keys). The mechanism of the prediction module is explained hereinafter. First, all the transitions have a default probability value. In order to evaluate the validity of a transition, its probability is compared to a threshold value. If the test is passed (initially all transitions are considered valid) and a reevaluation request is sent to the Analysis block, the energy level used by the analysis step is assessed. Also, the energy consumed by the system, for enforcing security, until the next state transition is determined. Based on these results the probability is modified by applying a correction factor accordingly. 3.5. Analysis Block This block receives security reevaluation requests from the Sensing block, based on system states transitions. Depending on the goals and the new state of the system, it decides what security elements should be modified consequently.

64 Nicolae Alexandru Botezatu et al. When designing this module, its response time should be taken into account because it has the potential to be the most expensive of the entire architecture. Moreover, the extra delay introduced by adapting the security primitives used may have a negative impact on security (e.g. unsafe operation from the state change until the enforcement of the new security parameters) as well as on the energy consumption (e.g. the overhead introduced by the analysis), resulting in a performance decline. After the analysis process, if there are available a number of possible security adaptations sets, equivalent for the system goals, the timing factor must be considered. For a better understanding, let us account the following example: two primitives could be used for securing an application. The first one has a high setup cost (and a subsequent higher enforcement delay) and a low usage cost (e.g. in a mj/bit metric), whereas the second one has a smaller setup cost and a higher usage one. In this case, the analysis block should select to enforce the second set of security methods as first option. 3.6. Enforcement Block This block receives security reconfiguration requests from the analysis module. It tries to apply the changes to the system, the result (success or fail) being feed-backed to the analysis module. If the reconfiguration request cannot be satisfied, the analysis module must propose other security alternatives. It also offers an interface to the OS (if any) and the underlying system applications, acting as a bridge between the system s security primitives and methods and the running applications. Dictating security changes can also indirectly influence the system s status and goals. For example, one of the status parameters is the battery voltage or one of the goals is based on the same parameter. Knowing that a change in the system s load (sink/source current), based on security adjustment, determines a voltage value variation, a threshold cross could determine a false response. Therefore, care must be taken in order to minimize the negative impact of these influences. 4. Implementation Example We propose a simple implementation example in order to show how the functions of the fore mentioned blocks can be described, without presenting any implementation details. First, the software and hardware parts of the system will be described grouped after the base classes illustrated in the previous section.

Running Application Bul. Inst. Polit. Iaşi, t. LVI (LX), f. 3, 2010 65 Table 1 System States and Security Requirements Battery Dod State Security Requirements A1m1 S1 A1 DES16 A1m2 S2 A1 DES A1m1 < 50% S3 & A2 50% S4 A1m2 < 50% S5 & A2 50% S6 A1 DES16 A2 DES8 A1 DES16 A2 FEAL A1 DES A2 DES8 A1 DES A2 FEAL Algorithm Table 2 Encryption Algorithms Characteristics Encryption Time for 64 Bit Data, [µsec] MCU Workload, [%] Power [mw] DES16 1380 47.57 22.05 DES8 775 26.72 15.67 FEAL 53 1.83 8.05 The system we built runs two applications: the first one resides permanently and has two operating modes; the two modes alternate on a time basis, the application spending 5 min in the first mode (referred to as A1m1), after that spending 10 min in the second mode (referred to as A1m2). The second application runs for 30 min, only after an external event arises (e.g. in our hardware setup the event was the push of a button). As for the security primitives, there are two symmetric key ciphers implemented on the system: Data Encryption Standard (DES) and Fast Data Encipherment Algorithm (FEAL) [8]. The DES algorithm can be used with 16 encryption round and with 8 encryption rounds (referred as DES16 and DES8), while the FEAL cipher is used in the default form. Now, the security requirements for the applications can be defined. The first application when operating in mode 1 needs to be secured using DES16 and when operating in mode 2 it has a more general requirement, needing DES. This means that either DES16 or DES8 can be used. The second application

66 Nicolae Alexandru Botezatu et al. considers FEAL to maintain a sufficient security level and DES8 to provide good security. We will see later how this requirement is translated into measurable properties. From the hardware perspective, we only consider the MCU as energy consumer, due to the variation of energy consumption in run and sleep modes. The systems battery is considered as an energy supplier class object, its sole property being the initial energy level. The chosen metric for estimating the systems energy status is the battery s depth of discharge (DOD), expressed in percents. The DOD is approximated based on the battery capacity, the system power consumption and the system s components operating time vs. modes. The hardware platform used is based on an ARM Cortex-M3 MCU and on rechargeable NiMH batteries (we used batteries with a capacity of 2000 mah) [9]. We have chosen two parameters with dynamic variation at runtime (system status) that influence the system s state: the DOD and a parameter that shows what applications are running and in what mode (if applicable). Based on this information, Table 1 shows the system states that can be identified by the sensing block. For the parameter showing the DOD level we considered a threshold at 50% value. This threshold is used to influence the selection of security primitive used for application 2: below 50% DES8 is used and FEAL above this value. The system goals are the following: a) to provide the security level required by the applications security goal; b) to use the security methods with the lowest energy consumption level energy goal. The Analysis block functions are constant, because the system goals do not change over time. This means that the same security primitives are constantly chosen for every state based on a look-up table, also shown in Table 1. The security goal is satisfied by providing the desired security for every application as illustrated in the System descriptors. The energy goal is met for states S2, S5 and S6, when application 1 is operating in mode 2 and its security requirements are satisfied by DES. The system chooses to use DES8 due to its lower energy consumption. The Enforcement block matches the security algorithms, indicated by the Analysis block, with the applications data in order to encrypt them. Concerning the operation of the system, when the conditions of state transition are met (the variation of DOD over the 50% threshold or a change in the application s operating mode) the algorithms for securing the system are selected. Based on the system specifications, which were randomly selected, the process of securing the running applications consists of the encryption of 80 bytes of data, for every application, in a time window of 29 milliseconds. The

Bul. Inst. Polit. Iaşi, t. LVI (LX), f. 3, 2010 67 remaining idle time, after all the data bytes are encrypted, is spent by the MCU in a low-power consumption sleep mode. The time, workload and power consumption characteristics for the security primitives, relative to the system s specifications, are presented in Table 2 [9], [10]. a Fig. 3 Power level (a); energy consumption variation at runtime (b). b

68 Nicolae Alexandru Botezatu et al. Fig. 3 a presents the variation of the power consumed by the system over a period of 60 min. The system passes through all possible states, the operating period of application 2 being asynchronous with the mode change of application 1. In the first 16 min and 15 sec only application 1 is running on the system, alternating it s mode of operation two times. After that application 2 also start, thus implying the state change from S1 to S3. After another 15 and a half min, the value of the battery s DOD passes the 50% threshold causing a transition from S3 to S4. The change in the security requirement for application 2, from DES8 to FEAL, brings a significant variation to the consumed power level. When application 2 terminates execution, due to the small/low consumption level of the FEAL primitive, the variation of the power level has lower amplitude. The energy consumed for the operating period is shown in Fig. 3 b. If both applications are secured with the safest available primitive, meaning DES16 [6], and the variations in the battery s DOD level or application operating modes are not considered, an increase of 550 mj in the consumed energy level can be observed. In the current context, this method for providing uniform security at system level may be considered to be the simplest available, even the safest available, but is certainly not the cheapest available. Therefore, by using this adaptive security method, a decrease of roughly 31% in energy consumption is obtained at runtime. This example shows that even when the security is adapted to the system s need in a simple manner, important energy savings can be achieved. 5. Conclusions We have presented our vision on how to address security selfadaptability in order to minimize energy consumption. The proposed methodology points out the main functionality needed for the implementation of such self-adaptable mechanisms, along the interactions within the system and with the environment. An example case study is described, in order to better understand how an adaptable security mechanism can be implemented, also pointing out the effect on energy consumption. Further work implies the implementation of the self-adaptable security method on different embedded architectures. This involves enhancements for the system s status, descriptors and goals entities in order to define them in a more consistent and homogeneous way. Also, different implementations for the functional blocks will be investigated. The evaluation of the blocks under real life scenarios is important in order to appreciate the relation between the required system performance and the used resources.

Bul. Inst. Polit. Iaşi, t. LVI (LX), f. 3, 2010 69 A c k n o w l e d g e m e n t s. This work was supported by the research project SIMPA, Contract no. 11-070/2007. Received: June 4, 2010 Gheorghe Asachi Technical University of Iaşi, Department of Computer Engineering e-mails: nbotezatu@cs.tuiasi.ro vmanta@cs.tuiasi.ro andreis@cs.tuiasi.ro R E F E R E N C E S 1. Ravi S., Kocher P., Hattangady S., Security in Embedded Systems: Design Challenges. ACM Trans. on Embedded Comp. Syst., Vol. 2, 3, 461 491, Aug. 2004. 2. Marcus L., Introduction to Logical Foundations of an Adaptive Security Infrastructure. Presented at the Workshop on Logical Foundations of an Adaptive Security Infrastructure, Turku, Finland, July 12 13, 2004. 3. Ferrante A., Taddeo V., Sami M., Mantovani F., Fridkins J., Self-adaptive Security at Application Level: a Proposal. Proc. of the 4th Workshop on Embedded Syst. Security, Grenoble, France, 2009, Paper 4. 4. Brown D., Reams C., Toward Energy-Efficient Computing. In Communications of the ACM, 53, 3, 50 58, March 2010. 5. Tudor D., Marcu M., Designing a Power Efficiency Framework for Battery Powered Systems. Proc. of SYSTOR 2009: The Israeli Experimental Syst. Conf., Haifa, Israel, 2009, 5. 6. Chandramouli R., Bapatla S., Subbalakshmi K.P., Battery Power-Aware Encryption. In ACM Trans. on Inform. a. Syst. Security, 9, 2, 162 180, May 2006. 7. Gogniat G., Wolf T., Burleson W., Reconfigurable Security Architecture for Embedded Systems. Proc. of the 39th Hawaii Internat. Conf. on Syst. Sci., Kauai, Hawaii, USA, 2006. 8. Menezes A., Van Oorschot P., Vanstone S., Handbook of Applied Cryptography. CRC Press, 2001. 9. Botezatu N.A., Stan A., Panduru L., Power-aware Framework for Encrypted Communications. Proc. of the 20th DAAAM World Symp. Intelligent Manufacturing & Automation: Theory, Practice & Education, Vienna, Austria, 825 826 (2009). 10. Stan A., Botezatu N.A., Data Encryption Methods for Power-Aware Embedded Systems used in Patient Monitoring. Proc. of the 10th Internat. Carpathian Control Conf., Zakopane, Poland, 269 272 (2009).

70 Nicolae Alexandru Botezatu et al. ARHITECTURĂ DE SECURITATE AUTO-ADAPTIVĂ PENTRU SISTEME ÎNCORPORATE POWER-AWARE (Rezumat) Securizarea sistemelelor încorporate reprezintă o direcńie de cercetare provocatoare şi importantă datorită resurselor de calcul şi de memorie limitate. Mai mult, sistemele încorporate alimentate de la baterie introduc constrângeri ale consumului de putere ce cresc dificultatea procesului de implementare a securităńii. Acestă problemă poate fi adresată prin determinarea unui raport optim între un consum scăzut de energie şi un nivel de securitate adecvat. Această lucrare propune o arhitectură de securitate auto-adaptivă pentru sistemele încorporate, descriind o schemă conceptuală necesară pentru implementarea unui astfel de mecanism. Pe lângă modul de interacńiune al blocurilor componente, lucrarea prezintă şi problemele ridicate de implementarea acestora. De asemenea, este prezentat şi un exemplu de implementare pentru mai buna înńelegere a mecanismelor auto-adaptive ale arhitecturii propuse. Efectul asupra consumului de energie este evaluat, obńinându-se o reducere a consumului de până la 30%.