J F Charpentier

T Ahmed-Ali

I Munteanu
email: iulian.munteanu@ugal.ro

Abstract-This paper deals with the experimental validation of a Matlab-Simulink simulation tool of marine current turbine (MCT) systems. The developed simulator is intended to be used as a sizing and site evaluation tool for MCT installations. For that purpose, the simulator is evaluated within the context of speed control of a permanent magnet synchronous generatorbased (PMSG) MCT. To increase the generated power, and therefore the efficiency of an MCT, a nonlinear controller has been proposed. PMSG has been already considered for similar applications, particularly wind turbine systems using mainly PI controllers. However, such kinds of controllers do not adequately handle some of tidal resource characteristics such as turbulence and swell effects. Moreover, PMSG parameter variations should be accounted for. Therefore, a robust nonlinear control strategy, namely second-order sliding mode control, is proposed. The proposed control strategy is inserted in the simulator that accounts for the resource and the marine turbine models. Simulations using tidal current data from Raz de Sein (Brittany, France) and experiments on a 7.5-kW real-time simulator are carried out for the validation of the simulator. Index Terms-Marine current turbine (MCT), modeling, nonlinear control, permanent magnet synchronous generator (PMSG), second-order sliding mode (SOSM), simulation.

I. INTRODUCTION

T HERE ARE basically two ways of generating electricity from marine and tidal currents: 1) by building a tidal barrage across an estuary or a bay in high tide areas or 2) by extracting energy from free-flowing water (tidal kinetic energy). Within the last few decades, developers have shifted toward technologies that capture tidally driven coastal currents or tidal stream [START_REF] Benelghali | Marine tidal current electric power generation technology: State of the art and current status[END_REF]. The astronomic nature of this resource makes it predictable, to within 98% accuracy for decades, and independent of prevailing weather conditions. This predictability is critical to a successful integration of renewable energy in the electrical grid [START_REF] Meisen | Harnessing the untapped energy potential of the oceans: Tidal, wave, currents and OTEC[END_REF]. It is therefore obvious that there is a need to quantify the potential of generating electricity from these various sites [START_REF] Myers | Simulated electrical power potential harnessed by marine current turbine arrays in the Alderney Race[END_REF].

This paper reports then on the experimental validation of a practical Matlab-Simulink simulation tool based on the modeling of the resource and the tidal turbine rotor. The BEM approach is in this case used for the turbine modeling.

In this paper, the simulator is evaluated within the context of the speed control of a permanent magnet synchronous generator (PMSG)-based marine current turbine (MCT). In previous works, different control strategies of control, mainly for doublyfed induction generator-based MCT, have been tested to evaluate the generated power [START_REF] Benelghali | High-order sliding mode control of DFIG-based marine current turbine[END_REF]- [START_REF] Park | Wide speed operation of a doublyfed induction generator for tidal current energy[END_REF]. In this paper, and in order to be able to compare and choose the adequate technology, a robust nonlinear control of a PMSG-based MCT is carried out [START_REF] Abu Sharkh | Performance of an integrated water turbine PM generator[END_REF], [START_REF] Benelghali | High-order sliding mode control of a marine current turbine driven permanent magnet synchronous generator[END_REF]. The adopted control strategy, namely second-order sliding mode (SOSM), relies on the resource and the marine turbine models that were validated by experimental data [START_REF] Benelghali | A simulation model for the evaluation of the electrical power potential harnessed by a marine current turbine[END_REF]. Simulations using tidal current data from Raz de Sein (Brittany, France) and experiments on a 7.5-kW real-time simulator are carried out for validation purposes.

II. MARINE CURRENT TURBINE MODELING [9]

The global scheme for a grid-connected MCT is given by Fig. 1.

A. Resource Model 1) Resource Potential:

The total kinetic power in an MCT has a similar dependence to that of a wind turbine and is governed by the following equation [START_REF] Couch | Tidal current energy extraction: Hydrodynamic resource characteristics[END_REF]:

P = 1 2 ρAV 3 tide . (1)
However, a marine energy turbine can only harness a fraction of this power due to hydrodynamic behavior and (1) is modified as follows:

P = 1 2 ρC p AV 3 tide . (2)
For marine turbines, C p is estimated to be in the range 0.35-0.5 [START_REF] Myers | Power output performance characteristics of a horizontal axis marine current turbine[END_REF].

2) Resource Model: Tidal current data are given by the SHOM and are available for various locations in chart form. The SHOM available charts give, for a specific site, the current velocities for spring and neap tides. These values are given at hourly intervals, starting at 6 h before high waters and ending 6 h after. Therefore, knowing tide coefficients, it is easy to derive a simple and practical model for tidal current speeds V tide

V tide = V nt + (C -45)(V st -V nt ) 95 -45 (3)
where C is the tide coefficient which characterizes each tidal cycle (95 and 45 are, respectively, the spring and neap tide medium coefficient). This coefficient is determined by astronomic calculation of earth and moon positions. V st and V nt are, respectively, the spring and neap tide current velocities for hourly intervals starting at 6 h before high waters and ending 6 h after. For example, 3 h after the high tide in Brest, V st = 1.8 knots and V nt = 0.9 knots. Therefore, for a tide coefficient C = 80, V tide = 1.53 knots. This first-order model is then used to calculate the tidal velocity each hour. The implemented model will allow the user to compute tidal velocities in a predefined time range. For illustration, Fig. 2 shows the model output for a month (March 2007). This adopted resource model has several advantages, including its modularity, not to mention its simplicity. Indeed, the marine turbine site can be changed, the useful current velocity can be adapted, and the time range taken into account can also be adapted from one month to one year.

B. Turbine Rotor Model

The harnessing of the energy in a tidal flow requires the conversion of kinetic energy in a moving fluid, in this case water, into the motion of a mechanical system, which can then drive an electrical generator. It is not too surprising, therefore, that many developers suggest using technology that mirrors that which has been successfully utilized to harness the wind, which is also a moving fluid [START_REF] Benelghali | Marine tidal current electric power generation technology: State of the art and current status[END_REF]. Moreover, much of the technology is based upon the use of horizontal-axis turbines, such as that shown in Fig. 3. There are, however, a number of fundamental differences in the design and operation of marine turbines. Particular differences entail changes in force loadings, immersion depth, different stall characteristics, and the possible occurrence of cavitations [START_REF] Batten | Hydrodynamics of marine current turbines[END_REF].

The BEM method has therefore been used for the marine turbine rotor modeling. Indeed, it is widely used in the industry as a computational tool to predict aerodynamic loads and power of turbine rotors [START_REF] Mattarolo | Modelling and simulation techniques applied to marine current turbine[END_REF].

It is relatively simple and computationally fast meeting the requirements of accuracy and control loop computational speed.

C. PMSG Model

The generator chosen for the marine current system was the PMSG [START_REF] Conroy | Frequency response capability of full converter wind turbine generators in comparison to conventional generation[END_REF]- [START_REF] Carrasco | Power-electronic systems for the grid integration of renewable energy sources: A survey[END_REF]. Indeed, the benefit of using a PMSG in renewable energy applications as an alternative to conventional generators is its higher efficiency. Moreover, the elimination of the gearbox and the introduction of variable speed control would further increase the availability of the system, reducing its active weight and the need for maintenance. A schematic diagram of a PMSG-based generation system is shown in Fig. 4.

The PMSG dynamic equations are expressed in the d-q reference frame. The model of electrical dynamics in terms of voltage and current can be given as (4) [START_REF] Tan | Optimum control strategies in energy conversion of PMSG wind turbine system without mechanical sensors[END_REF] ?

V d = RI d + L d dI d dt -ωL q I q V q = RI q + L q dI q dt + ωL q I q -ωφ f . (4)
The electromagnetic torque in the rotor is written as

T em = 3 2 p [(L d -L q ) I d I q -φ f I q ] . (5)

III. CONTROL OF PMSG-BASED MCT

A. Problem Formulation

A common practice in addressing PMSG control problem is to use a linearization approach [START_REF] Chinchilla | Control of permanentmagnet generators applied to variable-speed wind-energy systems connected to the grid[END_REF], [START_REF] Tan | Optimum control strategies in energy conversion of PMSG wind turbine system without mechanical sensors[END_REF]. However, due to the tidal resource characteristics such as turbulence and swell effects and the inevitable uncertainties inherent in PMSG-based marine current turbines, such control methods come at the price of poor system performance and low reliability [START_REF] Mirecki | Architecture complexity and energy efficiency of small wind turbines[END_REF]. Hence, there is the need for nonlinear and robust control to take into account these control problems.

Although many modern techniques can be used for this purpose, sliding mode control has proved to be particularly appropriate for nonlinear systems, presenting robust features with respect to system parameter uncertainties and external disturbances [START_REF] Munteanu | Energyreliability optimization of wind energy conversion systems by sliding mode control[END_REF]- [START_REF] Valenciaga | Variable structure control of a wind energy conversion system based on a brushless doubly fed reluctance generator[END_REF].

Sliding mode control copes with system uncertainty, keeping a properly chosen constraint by means of high-frequency control switching. Featuring robustness and high accuracy, the standard (first-order) sliding mode usage is, however, restricted due to the chattering effect caused by the control switching and the equality of the constraint relative degree to 1. Higher order sliding mode approach (HOSM) suggests treating the chattering effect using a time derivative of control as a new control, thus integrating the switching [START_REF] Levant | Integral high-order sliding modes[END_REF], [START_REF] Fridman | Higher order sliding modes[END_REF].

Up to now, a few SOSM control approaches have been introduced for wind and marine applications [START_REF] Benelghali | High-order sliding mode control of DFIG-based marine current turbine[END_REF], [START_REF] Valenciaga | High-order sliding control for a wind energy conversion system based on a permanent magnet synchronous generator[END_REF], [START_REF] Beltran | High-order sliding mode control of variable speed wind turbines[END_REF].

B. Second-Order Sliding Mode Control Approach

As the chattering phenomenon is the major drawback of practical implementation of sliding mode control, the most efficient way to cope with this problem is HOSM. This technique generalizes the basic sliding mode idea by acting on the higher order time derivatives of the sliding manifold, instead of influencing the first time derivative as it is the case in the standard (firstorder) sliding mode. This operational feature allows mitigating the chattering effect, keeping the main properties of the original approach [START_REF] Valenciaga | High-order sliding control for a wind energy conversion system based on a permanent magnet synchronous generator[END_REF].

The proposed control strategy is based on a step-by-step procedure.

1) First, the speed reference ω ref is generated by an MPPT strategy [START_REF] Benelghali | Modeling and control of a marine current turbine driven doubly-fed induction generator[END_REF]. 2) Then, an optimal electromagnetic torque, which ensures the rotor speed convergence to ω ref , is computed using the following equation:

T em_ref = T m + f ω -α(ω -ω ref ) + J ωref (6)
where α is a positive constant. Afterwards, current references are derived to ensure the PMSG torque convergence to the optimal one ? I d_ref = 0

I q_ref = 2 3 T em pφ f . (7)
To ensure currents convergence to their references, a SOSM strategy is used. Let us define the following sliding surfaces:

?

S 1 = I d -I d_ref S 2 = I q -I q_ref . (8)
It follows that where ϕ 1 (t, x), ϕ 2 (t, x), γ 1 (t, x), and γ 2 (t, x) are uncertain bounded functions that satisfy

? Ṡ1 = İd -İd_ref S1 = ϕ 1 (t, x) + γ 1 (t, x) Vd (9)
? Ṡ2 = İq -İq_ref S2 = ϕ 2 (t, x) + γ 2 (t, x) Vq (10)
? ϕ 1 > 0, |ϕ 1 | > Φ 1 , 0 < Γ m1 < γ 1 < Γ M 1 ϕ 2 > 0, |ϕ 2 | > Φ 2 , 0 < Γ m2 < γ 2 < Γ M 2 .
The main problem with HOSM algorithm implementations is the increased required information. Indeed, the implementation of an nth-order controller requires the knowledge of Ṡ, S, ... S, . . . , S (n-1) . The exception is the supertwisting algorithm, which only needs information about the sliding surface S [START_REF] Levant | Integral high-order sliding modes[END_REF], [START_REF] Fridman | Higher order sliding modes[END_REF]. Therefore, the proposed control approach has been designed using this algorithm. The proposed SOSM controller contains two parts

? V d = u 1 + u 2 V q = w 1 + w 2 ( 11
)
where

? u1 = -α 1 sign(S 1 ) u 2 = -β 1 |S 1 | ρ sign(S 1 ) ? ẇ1 = -α 2 sign(S 2 ) w 2 = -β 2 |S 2 | ρ sign(S 2 ).
In order to ensure the convergence of the sliding manifolds to zero in finite time, the gains can be chosen as follows [START_REF] Fridman | Higher order sliding modes[END_REF]:

⎧ ⎪ ⎨ ⎪ ⎩ α i > Φ i Γ mi β 2 i ≥ 4Φ i Γ 2 mi Γ mi (α i +Φ i ) Γ mi (α i -Φ i ) 0 < ρ ≤ 0.5 i = 1, 2.
The above proposed SOSM control strategy for a PMSGbased MCT is illustrated by the block diagram in Fig. 5. Finally, and as an additional justification of such an advanced controller, it should be noted that its practical implementation implies an online computational cost similar to that of PI or PID controllers [START_REF] Valenciaga | High-order sliding control for a wind energy conversion system based on a permanent magnet synchronous generator[END_REF].

IV. VALIDATION RESULTS

A. Validation Using Developed Simulator 1) Validation Data and Parameters:

In this paper, the Raz de Sein site (Brittany, France) was chosen above several others listed in the European Commission report EUR16683 [START_REF]The exploitation of tidal marine currents[END_REF] due to the presence of high-speed current coupled with appropriate depths suitable for marine turbine.

Moreover, the marine current speed distribution for most of the time is greater than the minimum, estimated to be 1 m/s, required for economic deployment of marine turbine. The studied area is shown in Fig. 6, where A and C are the area ends and B the expected installation site for the marine current turbine.

The turbine rotor model was validated through the comparison of the simulation model with experimental data from the available literature [START_REF] Benelghali | A simulation model for the evaluation of the electrical power potential harnessed by a marine current turbine[END_REF] (Fig. 7). The adopted marine current turbine is of 1.44 m diameter rated at 7.5 kW. For the given turbine geometry, the power for each rotor speed and a tidal current speed is determined by the BEM hydrodynamic model. In this context, the obtained power coefficient C p and the extractable power curves are shown in Fig. 8.

The 7.5-kW PMSG parameters are given in the Appendix.

2) Simulations: In this case, the MCT is simulated considering a resource first-order model (3). Therefore, for speed references given by Fig. 9 (MPPT) and a resource illustrated by Fig. 10, the PMSG-based MCT control performances are shown in Figs. 111213, respectively, illustrating the current, the rotor speed, and the generated power. The obtained results show good tracking performances of the PMSG current and rotor speed. Moreover, regarding [START_REF] Benelghali | Modeling and control of a marine current turbine driven doubly-fed induction generator[END_REF] and as expected, the generated power is smoothest. by reducing the sampling time, those peaks will considerably decrease (even disappear), but the simulation time will greatly increase.

B. Experimental Tests

For experimental validation of the proposed SOSM control approach, experiments were carried out using a renewable energy test bench built at the Grenoble Institute of Technology, France (G2Elab).

1) Test Bench [START_REF] Munteanu | Energyreliability optimization of wind energy conversion systems by sliding mode control[END_REF]: The test bench presented in Fig. 14 allows the physical simulation of the marine power system. The MCT is emulated by a dc motor, which reproduces the torque and the inertia with respect to current tidal speeds and turbine rotational speed. The dc motor is coupled to a 7.5-kW PMSG (Appendix).

2) Experimental Tests: The experimental tests were carried out to be as close as possible to the simulation conditions for the MCT in Fig. 7. In these conditions, Figs. 15 and16 show experimental control performances of the emulated PMSG-based MCT. These results show very good tracking performances in terms of the PMSG current and rotor speed.

For comparison purposes, Figs. 17 and 18 show simulation versus experimental results of the rotor speed and the generated power. Considering the real-world marine conditions, the obtained results are satisfactory. The test bench is equipped with current and torque limitations that explain some of Fig. 18 differences, in particular for high power generation.

Moreover, negative powers which transduce a motor behavior of the PMSG-based MCT can be enlightened by two main facts. The first one is that low tidal current speeds generate low torques, which, in certain cases, are able to lead the PMSG to the operating point imposed by the MPPT. The second one is the MCT acceleration that requires much more power to reach the targeted operating point.

V. CONCLUSION

This paper has dealt with the experimental validation of a Matlab-Simulink simulation tool of MCT systems. The simulator was evaluated within the context of speed control of a PMSG-based MCT. For that purpose, a SOSM approach has been proposed for the control of a PMSG-based MCT. The proposed control strategy relies on the resource and the marine turbine models. Its main features are a chattering-free behavior, a finite reaching time, and robustness with respect to external disturbances (e.g., grid) and unmodeled dynamics.

Tidal current data from Raz de Sein (Brittany, France) have been used to run simulations of a 7.5-kW prototype over various flow regimes and experimental tests have been carried out on a 7.5-kW real-time simulator. The obtained results are satisfactory and very encouraging regarding the validation of the MCT systems simulator.

As the developed simulator is intended to be used as a sizing and site evaluation tool for MCT installations, the subsequent work should focus on the experimental validation of the simulator for a doubly-fed induction generator-based MCT [START_REF] Benelghali | High-order sliding mode control of DFIG-based marine current turbine[END_REF]. This will allow the use of the simulator to compare generator technologies that best fit a specific marine site. Natural future works are mainly due to the MCT simulator configuration. Indeed, due to its modularity, numerous improvements should be promptly considered. The first one is to include vertical-axis turbine models. This will give opportunities to investigate some of the numerous projects available in the literature [START_REF] Benelghali | Marine tidal current electric power generation technology: State of the art and current status[END_REF]. The second one is to include the grid-connection. This will initiate very interesting works on grid-connection constraints as at the moment there is no real-word feedback.

APPENDIX

See Tables I and II.

Fig. 1 .

 1 Fig. 1. Marine current turbine global block diagram.

Fig. 2 .

 2 Fig. 2. Tidal velocity in Raz de Sein for March 2007.

Fig. 3 .

 3 Fig. 3. Horizontal-axis tidal turbine.

Fig. 4 .

 4 Fig. 4. Schematic diagram of a PMSG-based generation system.

Fig. 5 .

 5 Fig. 5. Proposed control structure.

Fig. 6 .

 6 Fig. 6. Marine current turbine expected site of installation.

Fig. 7 .

 7 Fig. 7. Tested marine turbine [28].

Fig. 8 .

 8 Fig. 8. Performances of the studied marine current turbine. (a) Cp(λ, V tides ) curves. (b) The extractable power P (ω, V tides ).

Fig. 9 .

 9 Fig. 9. Power curves for different tidal current speeds.

Figs. 11

 11 and 13 exhibit a number of short peaks. These peaks are due to the Matlab-Simulink solver configuration and are not due to the PMSG-based MCT model. Indeed,

Fig. 10 .

 10 Fig. 10. Resource tidal speed.

Fig. 11 .

 11 Fig. 11. PMSG Iq current tracking performances.

Fig. 12 .

 12 Fig. 12. PMSG rotor speed tracking performances.

Fig. 13 .

 13 Fig. 13. PMSG generated power.

Fig. 14 .

 14 Fig. 14. Components of the G2Elab test bench, Grenoble, France: ? 1 dc motor, ? 2 PMSG, ? 3 Power electronics for driving the dc motor, ? 4 Power electronics for driving the PMSG, ? 5 DSP TMS320F240 implementing dc motor control, ? 6 DSP DS1005 (dSPACE) implementing PMSG-based MCT control. Moreover, Figs. 11-13 have high peaks at t = 0. These peaks are due to the initial value of the used integral blocs in Matlab-Simulink. To overcome this problem in the experiments, the MCT connection to the PMSG has been delayed a few seconds.

Fig. 15 .

 15 Fig. 15. Experimental PMSG Iq current tracking performances.

Fig. 16 .

 16 Fig. 16. Experimental PMSG rotor speed tracking performances.

Fig. 17 .

 17 Fig. 17. Rotor speed: Experiments versus simulation.

Fig. 18 .

 18 Fig. 18. Output power: Experiments versus simulation.

  Student Member, IEEE, Mohamed El Hachemi Benbouzid, Senior Member, IEEE, Jean Frédéric Charpentier, Member, IEEE, Tarek Ahmed-Ali, and Iulian Munteanu, Member, IEEE

	Experimental Validation of a Marine Current Turbine
	Simulator: Application to a Permanent Magnet
	Synchronous Generator-Based System
	Second-Order Sliding Mode Control
	Seifeddine Benelghali,

TABLE I PARAMETERS

 I OF SIMULATED AND TESTED PMSG TABLE II PARAMETERS OF DC MOTOR

ACKNOWLEDGMENT

The authors would like to thank Prof. S. Bacha from the Grenoble Electrical Engineering Laboratory (G2Elab), Grenoble, France, for allowing the use of the G2Elab renewable energy experimental facilities.

This work was supported in part by Brest Métropole Océane (BMO), in part by the European Social Fund (ESF), and in part by the GDR SEEDS CNRS 2994 under the Internal Project HYDROLE. S. Benelghali was with the EA

Mohamed El Hachemi Benbouzid (S'92-M'95-SM'98) was born in Batna, Algeria, in 1968. He received the B.Sc. degree in electrical engineering from the University of Batna, Batna, Algeria, in 1990, the M.Sc. and Ph.D. degrees in electrical and computer engineering from the National Polytechnic Institute of Grenoble, Grenoble, France, in 1991 and 1994, respectively, and the Habilitation à Diriger des Recherches degree from the University of Picardie "Jules Verne," Amiens, France, in 2000.

After receiving the Ph.D. degree, he joined the Professional Institute of Amiens, University of Picardie "Jules Verne," where he was an Associate Professor of electrical and computer engineering. In September 2004, he joined the University Institute of Technology (IUT) of Brest, University of Brest, Brest, France, as a Professor of electrical engineering. His main research interests and experience include analysis, design, and control of electric machines, variable-speed drives for traction, propulsion, and renewable energy applications, and fault diagnosis of electric machines. In 2002, he was a Fellow of the Marie Curie European Framework Program at the Electrical Engineering Laboratory of Grenoble, Grenoble, France. He is currently with the Department of Electronics and Telecommunications, "Dunȃrea de Jos" University of Galat ,i. His current research interests include optimal control of renewable energy systems.

Jean Frédéric Charpentier


Hassane Aissaoui-Mehrez

Pascal Urien
email: pascal.urien@telecom-paristech.fr

Guy Pujolle
email: guy.pujolle@lip6.fr

SecFuNet : Embedded Framwork in OpenSSL to support Smart Cards

Keywords: Cloud Computing, Virtual Environment, Secure Element, SDK SmartCard, Hypervisor Xen, HSM, OpenSSL, TLS

Smartcards are becoming increasingly popular as a means for personal identification and authentication in many secure application areas such as e-Banking and e-Commerce. Millions of users have a smart card in their pocket without even knowing it. The SecFuNet project proposes solutions for integrating secure microcontrollers in order to develop a security framework for Cloud Computing and virtual environment. This framework introduces, among its many services: authentication and authorization functions for virtual environments, based on Remote Grid of Secure Elements (RG0SE). The objective is to implement an open standard framework, based on smart cards and OpenSSL. This framework provides TLS secure channels for establishing trust relationships among Users, Virtual Machines (VMs), Hypervisor (XEN) and RG0SE. The authentication is done directly between smart cards (owned by users or associated to VM) and SecFuNet Identity Management (IdM). This framework concerns a highly secure authentication with secure microcontrollers allowing users' (or VMs') strong mutual authentication with SecFuNet Services and provides some libraries to the developers. It defines and describes the features and the modules added to OpenSSL in order to supply easily the Application Protocol Data Unit (APDU) -described by the ISO 7816 standard -transferred to smart cards.

I. INTRODUCTION

The SecFuNet objective is to implement an open standard framework, based on the authentication servers and smart cards. The proposed SecFuNet framework provides TLS secure channels for establishing trust relationships among Users, Virtual Machines (VMs), Hypervisor (XEN) and Remote Grid of Secure Element (R-GoSE). The authentication is done directly between Smart Card (owned by users or associated to VM) and SecFuNet Identity Management (IdM). This paper concerns a highly secure authentication with secure microcontrollers allowing users' or (VM) strong mutual authentication with SecFuNet Services and provides some libraries to the developers. It defines and describes the features and the modules added to OpenSSL in order to supply easily the APDU commands transferred to smart cards. This paper describes how to integrate a Hardware Security Module (HSM) -EAP-TLS Smart Cardwithin the OpenSSL tool kit using libraries of Smart Card API on the one hand and the new "s_scard and s_hypervisor" command lines to test connection with SSL/TLS server developed in SecFuNet Project on the other hand. The "s_scard and s_hypervisor" programs may be used for evaluation EAP-TLS Smart Card purposes, for any use. EAP-TLS Smart Card is designed to perform sensitive cryptographic tasks and to securely manage cryptographic keys and data. The security-relevant actions can be executed and security relevant information can be stored. It can be used as a universal, independent security component for heterogeneous computer systems.

The first part of paper concerns the definition of the primitive functions and libraries. The second part describable the implementation of "s_scard and s_hypervisor" command lines to use with EAP-TLS Smart Card.

II. CONCEPTS AND STATE OF ART

To address some of the security issues, we explore the application of secure elements, such as Smart Cards, to improve the trustworthiness of network infrastructure services for future networks.

Two classes of secure microcontrollers have been studied, smart cards and TPMs (Trusted Platform Modules). These electronics chips have different computing capabilities, smart cards usually run a Java Virtual Machine (JVM) and therefore are able to execute complex procedures (such as the TLS protocol), while TPMs are dedicated to the RSA algorithm. However, these devices may be used in order to enforce trust for the TLS protocol or to guarantee secure storage for cryptographic keys. These security properties are directly provided by smart cards (thanks to dedicated embedded software), but require additional software components for TPMs.

In this document we call secure element a device such as Smart Card, which is able to totally or partially handle the TLS protocol and to realize the secure storage or computing of a cryptographic key. The main goal of this section is to briefly overview the EAP-TLS smart cards services.

A. Eap-Tls Smart Card

EAP [START_REF]Extensible Authentication Protocol[END_REF] is a universal and flexible authentication framework. Because it can transport about any authentication protocol, it solves the interoperability concerns that their number and their disparity had risen. Formally, EAP protocol is built on three kinds of messages: requests delivered by servers; responses returned by clients; and notifications issued by servers in order to indicate success or failure of authentication procedures.

The EAP-TLS smartcards functionality and binary encoding interface are detailed in [START_REF]EAP-Support in Smart card[END_REF]. These devices process EAP methods and act as server or client entity. They communicate via a serial link, whose throughput ranges between 9600 and 230,000 bauds. There are two classes of operations, sending data (writing to smart card) and receiving data (reading from smart card); information is segmented in small blocks (up to 256 bytes) named APDUs, described by the ISO 7816 standard.

A smartcard [START_REF] Jurgensen | Smartcards: The Developer's Toolkit[END_REF] is a tamper resistant device, including CPU, RAM and non-volatile memory. Packets exchanged to/from this device are named APDUs and are detailed by the ISO7816 standard. Security is enforced by multiple physical and logical countermeasures. To interface with smart card and smart card reader, we can use PC/SC (short for "Personal Computer/Smart Card") specification for smart-card integration into computing environments without any change. Most of these electronic chips support a Java Virtual machine (JVM) and execute software written in this programming language [START_REF] Recordon | Openid 2.0: A platform for user-centric identity management[END_REF]. The use of smartcards in TLS authentication has now a rather long history and has been largely developed according to different models. These devices run the OpenEapSmartcard JAVA open stack, introduced in [START_REF] Menon | Optimizing network virtualization in xen[END_REF] and which comprises four logical components "Fig. 1": 1) The EAP Engine Object is mostly in charge of the I/O management (i.e. APDUs exchange). It is also responsible of EAP messages segmentation and reassembly. In fact, the APDU payloads maximum length is 255 bytes for input data and 256 bytes for output data, while EAP packets maximum length is about 1300 bytes of data. Consequently, EAP packets are split into several ISO 7816 units, and the Engine entity parses them in order to rebuild the proper EAP packet. 2) The Credential Object holds all the credentials required by EAP-TLS method, that is to say: the Certification Authority certificate, the server Certificate and its associated private key. The EAP-TLS State Machine is reset and its according method is initialized with appropriate credentials, each time an EAP-Identity.Response message is received. This object also works as an Identity module. For now, it only holds a unique server Identity but one could possibly load different server Identities issued by several companies which, upon success, would grant different kind of access or services depending of the Client's Identity and its subscription to one or several companies' Network.

3) The Authentication Interface object implements all services fulfilled by EAP-TLS methods, whose main procedures are initialization, packet processing or MSK key downloading.

4) Lastly, the EAP-TLS object is in charge of packets processing, as specified in EAP standard [START_REF] Urien | Remote APDU Call Secure[END_REF]. Since TLS packets size may exceed the Ethernet frame capacity, EAP-TLS supports internal segmentation and reassembly mechanisms.

B. PC/SC Standard

PC/SC is a standard proposed by the PC/SC workgroup which is a conglomerate of representative from major smart card manufacturers and other companies. This specification tries to abstract the smart card layer into a high level API so that smart cards and their readers can be accessed in a homogeneous fashion. PC/SC is the de-facto standard to interface Personal Computers with Smart Cards (and smartcard readers of course). This high-level and standardized API allows the developer to focus on the smartcard itself, without dealing with various aspects of every smartcard reader. PC/SC is available on Windows integrated in the OS, available through winscard.dll library. Thanks to open-source PC/SC-Lite project, PC/SC is also implemented on numerous UNIX platforms (including GNU/Linux and Mac OS X).

It is formed by a server deamon (pcscd) and a client library (libpcsclite.so) that communicates via IPC. This toolkit was written in ANSI C that can be used with most compilers and does NOT use complex and large data structures such as vectors, etc.

The PC/SC advantage is that applications do not have to acknowledge the details corresponding to the smart card reader when communicating with the smart card.

C. APDU Commands

To handle or invoke smart cards, we use the APDU commands (Application Protocol Data Unit). The APDU is the communication unit between a smart card reader and a smart card. The structure of the APDU is defined by ISO/IEC 7816-4. According to the ISO7816 standards secure element process ISO7816 request messages and return ISO7816 response messages, named APDU. An APDU request comprises two parts: an optional body that may be empty. Its maximum size is 255 bytes and the header is a set of four or five bytes noted:

 CLA indicates the class of the request, and is usually bound to standardization committee (00 for example means ISO request).

 INS indicates the type of request, for example B0 for reading or D0 for writing.

 P1/P2 gives additional information for the request (such index in a file or identifier of cryptographic procedures).

 P3 indicates the length of the request body (from P3=01 to P3=FF), or the size of the expected response body (a null value meaning 256 bytes). Short ISO7816 requests may comprise only 4 bytes.

An APDU response comprises two parts an optional body and a mandatory status word.

 The optional body is made of 256 bytes at the most.

 The response ends by a two byte status noted SW. SW1 refers the most significant byte and SW2 the less significant byte.

D. OpenSSL Project

The OpenSSL Project is a collaborative effort to develop robust applications. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation. OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The toolkit is licensed under an Apache-style license, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions. This software package uses strong cryptography, so even if it is created, maintained and distributed from liberal countries in Europe (where it is legal to do this), it falls under certain export/import and/or use restrictions in some other parts of the world. OpenSSL is fullfeatured, and Open Source implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLSv1) network protocols as well as a full-strength general purpose cryptography library and related cryptography standards. The openssl program is a command line tool for using the various cryptography functions of OpenSSL's crypto library from the shell. It can be used for:  s_client and s_server commands are two applications Client/Server to test the SSL/TLS protocols.



III. SMART CARDS SUPPORT EMBEDDED WITHIN OPENSSL

The OpenSSL program provides a rich variety of basic cryptography library, certificate services and commands, each of which often has a wealth of options and arguments. In most cases its just used to provide the backend for SSL enhanced protocols like https or ssh. But it also offers a standardized API to other solutions.

The only lack of OpenSSL as a security suite is its tight strings to keys that are stored on a hard disk. This might become a huge security concern, as in most cases anyone with access to the system can just grab the key files and walk away. There are a lot of things an administrator (or a virus with root privileges) can do to steal your key, then the attacker has all time to decrypt the data. That's typically without anyone notifying that the keys and data have been stolen. If the key is on a smart card there is usually no way to export the private key, so if you pull the card from the reader no one can use your keys. And if you use a certified and sealed reader device you can even be reasonably sure that no one can steal your PIN.

The OpenSSL project offers the possibility to source out cryptographic functionality to plug-in specific modules. Usually there is one of two reasons for doing this, performance and security. The performance reason is rather obvious, specialized hardware can do cryptography much faster than a general purpose computer. The reason for using a smart card typically is a security reason. So it is essential to store such keys in a secure manner that requires much more effort to access the keys and ideally disallows the keys to be copied off in an insecure or unattended manner. One solution is to bind OpenSSL to a security device like a TPM, Smartcard, USB Token… or a so called Secure Element (SE) or Hardware-Security-Module (HSM). As a result the key is stored inside such a device and all operations with that key are also done within the secure boundaries. Additional benefits are also, that a key cannot be easily taken away by someone with access to the system, if configured properly it can also not be extracted in any insecure way from the HSM.

Many applications have been written supporting smart cards for various purposes. The most solutions to get the HSM hooked up are based on OpenSSL's engine concept. However, OpenSSL does not include smart card support. Therefore application developers had to resort to creating their own Software Development kit (SDK) wrappers to access the native PC/SC API for Smart Cards. It is a difficult and time consuming task, time that would better be spent on developing the application itself. Indeed, some vendors supply their own patches that would require OpenSSL to be modifed and re-compiled. These vendors spend significant resources on developing and maintaining such patches, with the claim that it would be supported.

Our approach is to introduce the SDK Smart Cards API (SDK-SC-API) within OpenSSL that we are developed in SecFuNet project. The SDK-SC-API consists on adding to OpenSSL several primitives in order to handle smart card and to supply packets exchanged to/from the Smart Card device. The SDK-SC-API is a set of procedures written in ANSI C that can be used with most compilers and for easy access to smart cards from OpenSSL toolkit. This SDK-SC-API implements wrapper functions for accessing GSM SIM and 3GPP USIM cards through PC/SC smartcard library. As this moment, these functions are used to implement authentication routines for EAP-TLS Smart Card based on SSL stack.

These procedures are based on routines specified in winscard like those in the winscard API provided under Windows(R). These procedures are mainly an abstraction of smart cards. It gives a common API for management to most smart cards (EAP-TLS Smart Card, SIM, USIM...) in a homogeneous fashion. Using the SDK-SC-API, an application developer no longer needs to create their own SDK, but rather uses a convenient API that provides a level of abstraction than the native PC/SC API. So instead of patching, modifying and re-compiling your OpenSSL, which might break some system dependencies, make use of standard API's and wrappers.

A. SDK-SC-API Product Offerings

SDK-SC-API is not just a wrapper for the PC/SC but provides a framework that can be extended to support any Smart Card authentication (i.e. Using a 2G SIM card. It is described in RFC 4186 from the IETF or using UMTS 3rd generation USIM functionality.

It is described in RFC 4187). Indeed, it is sufficient that smart card reader must comply with the PC/SC standard.

OpenSSL already support third party crypto providers using its engine concept and a command line tool for using the various cryptography functions of OpenSSL's crypto library from the shell. In our proposition "Fig 2", the additional SDK-SC-API to OpenSSL is available as a source code implemented in C and thus it is managed code in: The changes are minor in openssl in order to not impact its structure. Indeed, we have first added two variables in SSL structure:

 scard_pcsc_api directory,
 SCard_Is_On for indicate to the program (i.e. s_scard) to initialize smartcard reader.

 Reader_nbr for indicate witch smart card reader index to handle.

The second modification consists to modify Makefile in order to build OpenSSL with SDK-SC-API. This SDK has many advanced features, such as support for secure PIN entry. The following list is an overview of the more important files:  scarddebug: supplies methods to manage a reader's events and debug it. These functions are used to print conditional debugging and error messages. The output may be directed to stdout, stderr.

 scardpcsc: contents all procedures and methods which supplies functions to manage readers and to connect to the inserted smart card. Gives the list of readers plugged to the Xen Server and the list of readers having a smart card plugged-in active.

 s_hypervisor: is proxy server, contents all procedures and methods which supplies functions to manage remote readers and associate Smart Card to the authenticated VM. When a VM needs to open a TLS session, the proxy parses all requests (i.e: ClientHello, Certificate Exchange, Client key Exchange…) coming from VM in order to perform this connection using Smart Card associated to this VM.

The SDK module includes sample implementations showing how to achieve complete EAP-TLS Smart Card authentication with an OpenSSL Server.

An Example is making available in the "s_scard.c" program and its "tls_scard_clnt.c" library. The s_scard command is an implementation to test the EAP-TLS Smart Card authentication with an OpenSSL Server.

B. Authentication With "s_scard" command

s_scard.c program has been built in a way that makes it easy to customize and modify to suit each developer's requirements. Developers can write and test a custom module according to their own unique requirements.

This program shows how to interact with an OpenSSL Server, how to store keys, and to request TLS/SSL connection. This program can serve as a starting point for developing a specific module. It should be noted that the "s_scard" command include just an implementation with EAP-TLS Smart Card with an EAP-TLS Smart Card stack "Fig. 1". This program handles locally connected smart card, and can be used for end-to-end testing of TLS client authentication.

As mentioned above, the EAP-TLS Smart Card is an EAP-TLS stack embedded in Smart Card which functions according to the ISO 7816 standard.

For working with EAP-TLS Smart Cards using any PC/SC Smart Card reader, you need make an easy configuration. The use of the PC/SC interface must be enabled and the functions which encapsulate the PC/SC interface have to be adapted so that they can handle the responses from the Smart Card.

IV. PLATFORM DESIGN AND USE CASE

The platform we have designed for experimental purposes and performances evaluation is represented in "Fig, 3", and is built on three main components:

 TLS Server based on OpenSSL, come with a number of tools to facilitate testing, in particular with a TLS/SSL Server environment called "s_server" program.

 EAP-TLS Smart Card device running the OpenEapSmartcard JAVA open stack [START_REF] Menon | Optimizing network virtualization in xen[END_REF].

 The client host where the Smart Card device is docked and managed by a specific dedicated program. "s_scard.c", which we will call TLS Proxy Client (TLS-PC) for comprehension purposes.

The TLS-PC accesses our EAP-TLS Smart Card, either remotely, or on an internal bus if the TLS server and the TLS-PC are located on the same host. To test the TLS/SSL session with our "s_scard" command line, first, we launch a TLS/SSL Server thanks "openssl s_server" command line.

In our testing example the TLS/SSL Server is running with the following arguments. Ensure that you are familiar with the OpenSSL ToolKit : #./openssl s_server -msg -debug -tls1 -accept 443 -verify 1 -CAfile root.pemcert tls_server_cert.pem -key tls_server_key.pem -pass pass:pwd Fig. 3. The Platform design and experimental of "s_scard" command In client side, "openssl s_scard" command line is running with the following arguments: #. /openssl s_scard -tls1-debug -connect remote_tls_server:443 pin_code This command executes the TLS client session between the EAP-TLS smart card and the TLS server on port 443. Note that the TLS Client only needs the remote server name and PIN code.

Our TLS-PC program intermediate between TLS Server and EAP-TLS Smart Card to create TLS/SSL connections, whose TLS messages are encapsulated into EAP packets and then, which are forwarded to the EAP-TLS Smart Card thanks to "tls_scard_clnt.c" library dedicated to Smart Cards management.

Once it has been launched, the TLS-PC creates a new connection which will initiate a TLS connection with the TLS Server "Fig, 4". The last server generates a thread on port 443, waiting for socket connections. Each time it receives a connection on this port with EAP-TS Smart Cards according to the main following procedures implemented in "s_scard.c" program and its "tls_scard_clnt.c" library:  It generates stream sockets connected with the distant TLS Server. Those sockets are used to receive and send the TLS datagram to the TLS Server.

 It checks the datagram, parses it and verifies if it is a proper TLS datagram, or corresponding to an encapsulated EAP message incoming from smart card.

 It splits the EAP message into the appropriate number of APDUs. The EAP message is transported by APDUs thanks to an EAP-Process command, created for that purpose.

 It generates an appropriate context for the APDUs so that they shall be recognized by the Smart Card, which redirects the incoming connection to the proper EAP-TLS Smart Card and whose syntax is specific.

 Upon answer from the smartcard, it parses and reassemblies the EAP packets, in case it has been split by the smartcard into several APDUs, and waits until all the EAP-Request packets have been transmitted.

 It checks the incoming EAP packet from EAP-TLS Smart Card, retrieves the TLS message and encapsulates it into a TLS datagram, and forwards it to the TLS Server.

Once the authentication is successful (or not) and once the keys (key blocs and MSK) have been generated, the Smart Card associated to a TLS session is released and free to be used by a new incoming session. This procedure is renewed as often as necessary until all sessions have been treated and client authenticated. The strong authentication based on smart card has become a critical factor of good system design, it expands as the primary medium for secure communication. In this paper, our contribution consists to add a software development kit "SDK-SC-API" within OpenSSL in order to make easy a development of smart card and to give to developers the possibility to enable a test with smart cards. Furthermore, the security and the advantages it provides shall be a great addition to OpenSSL Toolkits in general as well as a key asset to securing Cloud Computing infrastructures.

We have concluded that the benefits of implementing SDK-SC-API into OpenSSL have many advanced features, such as support for secure PIN entry. The following list is an overview of the more important advantages:  The client private key is secretly stored and used by the smartcard. The client certificate is autonomously checked by the TLS Server.

 Reduces development time by eliminating the need to create your own SDK wrapper.

 Makes your applications independent of the underlaying smart card devices. The application can be used with PC/SC API and our SDK-SC-API without any change of OpenSSL.

 EAP-TLS Smart Card and (U)SIM can be written on top of SDK-SC-API and can be supported via custom modules.

Fig. 1 .

 1 Fig. 1. The EAP-TLS Smartcard components and grids architecture



  Creation and management of private keys, public keys and parameters; Creation of X.509 certificates, CSRs and CRLs; Public key cryptographic operations; Calculation of Message Digests; Encryption and Decryption with Ciphers; Handling of S/MIME signed or encrypted mail;  Time Stamp requests, generation and verification;

Fig. 2 .

 2 Fig. 2. The Additional modification added to OpenSSL

Fig. 4 .

 4 Fig. 4. The Interaction between "s_scard" command and tls server

ACKNOWLEDGMENT

This work has had financial support from CNPQ through process 590047/2011-6 (SecFuNet project) and also through processes 307588/2010-6 and 384858/2012-0. We also thank CAPES for the financial support with PhD scholarship.