AES High-Level SystemC Modeling using Aspect Oriented Programming Approach

The increasing complexity of the cryptographic modeling and security simulation of the Advanced Encryption Standard (AES) necessitate fast modeling and simulation security environment. The SystemC language is used in Electronic System Level (ESL) that allows cryptographic models to achieve high security and modeling simulation speed. Yet, the use of SystemC in the security simulation requires modifications of the original code which increases the modeling complexity. The AspectOriented Programming (AOP) can be used in the cryptographic modeling and security simulations without any code modification. In this paper, a new AES SystemC model using the AOP technique is presented. A functional verification environment is proposed to test the functionality of the AES SystemC AOP model, the impact of AOP on simulation time, and the size of the executable files. The design of the AES model is developed with the weaving of all modules by AspectC++ which is an AOP language. The Simulation results show the efficiency of the proposed AES model and the uses of the AOP technique do not have a significant impact on simulation time or on the size of the executable file. Keywords-security; cryptographic; AES; SystemC; AOP; highlevel

INTRODUCTION Cryptographic systems are implemented in embedded systems to protect secret information. Those systems store the encryption key in conjunction with the cryptographic algorithm execution [1][2][3]. The modeling complexity of cryptographic systems is increasing more than the verification capability and the design of the developers [4]. SystemC is used for the modeling and verification of complex systems. It has been considered as a suitable language for developing cryptographic models. Yet, its uses need to modify the original SystemC code in order to weave any cryptographic modules [5,6]. To avoid modifying the cryptographic algorithms code under test, a new technique is used: Aspect Oriented Programming (AOP). It consists of weaving a module into the original code without any modification [7,8]. Until now, a few cryptographic models and verification security environments using SystemC and AOP have been presented. In [9], the authors presented a security SystemC benchmark for high-level synthesis. They developed a security benchmark suite in a behavioral language supported by all major HLS vendors with different types of trojan hardware which produce different effects. A security threat analysis using SystemC to simulate the power attacks is presented in [10]. The authors developed a new approach to simulate power attacks in early stages. The authors also developed a power consumption graphical interface to analyze the security of the elliptic curve cryptography and RSA encryption against simple power attacks and differential power attacks respectively. The authors in [7] proposed a new fault injection system based on aspect-oriented programming (AspectC++). This system allows an automated injection of errors without modifying the original code. The authors showed that their system provides automatisms to generate the test environment of embedded systems. In this paper, we present a new AES SystemC model using the AOP technique. We summarize our contributions as: • AspectC++ has been used as an AOP technique to avoid modifying the cryptographic algorithm code.
• A new cryptographic AES SystemC model using the AOP technique is proposed.
• A functional verification environment is proposed to test the functionality of the AES SystemC AOP model.
• The proposed AES SystemC-AOP model has been simulated in order to estimate the impact of AOP on simulation time and on the size of the executable files. Through the simulations, it was shown that the efficiency of the proposed AES model and the uses of AOP technique do not have a significant impact on simulation time and on the size of the executable file.
II. ASPECT ORIENTED PROGRAMMING AOP is a programming technique based on the principle of the separation of concerns [7,8]. In the AOP, an application is made up of classes and aspects. The transversal code linked to non-functional concerns is put into modules in the form of aspects. The aspects will then be weaved into the functional code in order to generate a complete application. Aspects are used to implement technical functionalities that are found to be dispersed in the code of an application. An aspect consists of two parts: Pointcut and advice code.
• Pointcut allows defining the place where the code of the transverse functionality of the associated aspect will be applied. This is defined by one or more Join Points. Each Join Point represents a point in which the code of a transverse functionality will be inserted. There are two types of Join Points: call and execute.
• An advice code is a part of the code that will be inserted in the places defined by the Join Points. It denotes the way in which cross functionality will be weaving.
An aspect can include several advice codes at the same time where each advice is associated with a cut. There are three types of advice codes: • before: the code will be executed before the cut.
• after: the code will be executed after the cut.
• around: part of the code will be executed before the cut and another will be executed after.
To weave a new feature like an aspect into the code of an application, junction points must be defined in the primary code to indicate where the aspect should act. Figure 1 shows how the aspect code of the new functionality is weaving into the application code. The AOP technique is widely used in the field of testing embedded programs written in C ++ and Java. In our work, in order to avoid the modifications of the source code when inserting the codes relating to the AES model and the analysis of the cryptographic system, the use of the AOP technique to design a new AES model is proposed. Since the AOP technique allows the separation of transversal concerns, we can obtain a new distribution of the cryptographic model. This distribution consists of class and aspects which present the codes relating to the modules to be inserted. Weaving aspect code into source code.  III. SYSTEMC AES MODELING The goal of this section is to design an AES model in SystemC using the AOP approach. For this purpose, the cryptographic operations performed by the AES cryptosystem were divided into several modules. Figure 2 presents a detailed description of the proposed AES model. The diagram of the AES SystemC model presents the different cryptographic modules as well as their interconnections using AspectC++ which is an AOP language. The AES SystemC AOP model is described in 7 modules: Figure 3 presents the flowchart of the aspect used by the AES cryptosystem. The aspect code is woven by the aspectC++ weaver into original code. The SystemC-AOP flow has four main phases. The Aspect phase consists to create a new aspect for each AES cryptosystem module using AspectC++. The point-cutting phase consists to define the weaving location for each module. The third phase is to insert all modules in the pointcuts and then execute all functions: • The Input_Interface module reorganizes the input flow according to a standard format defined by the communications protocol. It executes the Input_Data_Buffer and Intput_Key_Buffer functions.
• The Controller_Unit module is a state controller that allows the synchronization of all modules of AES cryptographic model.
• The Database module stores all variables and constants used in the encryption and decryption process. It processes two functions: Variables and Constants.
• The Fault Detection sSheme (FDS) module is developed to protect the AES module against fault attacks. It executes Fault_Detection and Fault_Analysis functions.
• The Output_Interface module reorganizes the encrypted stream according to a standard format defined by the communications protocol. It executes the Output_Data_Buffer function.
In the fourth phase, after the weaving process, the resulting source code can be compiled by SystemC and AspectC++ compilers and the resulted executable file is therefore generated.

IV. FUNCTIONAL VERIFICATION ENVIRONMENT
In this section, the proposed functional verification environment developed to validate the AES model is presented. This environment is inspired by the transaction-based verification environment in the SystemC. The AES model verification environment includes a reference model that presents a high level design description. This model is executed in parallel with the proposed model in order to compare the output results during the simulation. The reference model often models the interaction between modules at the transactional level rather than at the signal level. In this case, this module is written in TLM. Figure 4 shows the proposed environment architecture. As presented by Figure 4, the testbench SCV is a module that randomly generates the encryption keys and plaintext for the proposed and the reference models. The transactor receives the stimuli from the testbench SCV and applies them to the inputs of the proposed model. At the end of each transaction, the outputs are compared and the results are generated by a comparator module.  (1) + (2): The stimuli are generated randomly by the testbench SCV towards the two cryptographic models: proposed and reference models. V. RESULTS AND DISCUSSION This section is devoted to the evaluation of the proposed SystemC-AOP model as well as to the analysis of the impact of using SystemC and AspectC++ at the ESL level on the cryptographic design. First, we will perform a series of simulations to validate the proposed SystemC-AOP model. This validation is performed using the functional verification environment where the proposed model is compared with the reference model. Secondly, we will analyze the impact of using the AOP technique on the simulation time and on the size of the executable file of cryptographic model. The modeling was carried out with SystemC 2.3.2 language and AspectC++ 2.2, and the validation of the AES SystemC AOP model was carried out on a PC equipped with the Ubuntu 18.4 operating system, an Intel Core I3-4010U 1.7GHz microprocessor, a RAM of 6GB, and the gcc 7.2.0 compiler.

A. AES SystemC AOP Model Validation
A series of simulations will be performed in order to validate the proposed SystemC-AOP model. The validation is performed using the functional verification environment. The keys and data randomly generated by the testbench module are distributed to the reference AES model and the proposed AES model through the transactor module. The two models are simulated with the same simulation model and using the same test conditions. The verification results show that the proposed AES SystemC model works perfectly and it provides the same results as the reference model. Figure 5 shows an extract of the report simulation results.

B. Impact of AOP on Simulation Time
To analyze the impact of AOP on simulation time, a series of simulations were performed using the developed environment. This process consists of measuring kernel time (kTime) and user time (uTime) using two fault detection schemes. Note that kTime and uTime depend on the number of Join Points as well as the number of modules to be inserted via the AOP technique. Table I shows the simulation results in terms of kTime and uTime using two scenarios (SystemC and SystemC_AOP). We can see that the margin of error of the measurement tool (Linux commands) that was used is very low and does not affect the accuracy of the simulation results. These results show that the weaving of Key_generator, Controller_unit, Database, Input_interface, Output_interface and FDS modules into the SystemC model, using the AOP technique, does not affect simulation times. Another very important parameter for analyzing the impact of AOP is the size of the resulting executable file. Table II   1.226Mo 1.219Mo AES model protected by FDS [11] 1.305Mo 1.309Mo AES model protected by FDS [12] 1.346Mo 1.350Mo VI. CONCLUSION In this paper a new AES SystemC model using the AOP technique at the Electronic System Level was presented. A functional verification environment was proposed to test the functionality of the AES SystemC AOP model, the impact of AOP on simulation time and on size of the executable files. The simulation results show the efficiency of the proposed AES model and the weaving of AES modules using the AspectC++ does not have a significant impact on simulation time and on the size of the executable file.