Achraf Fayad
email: achraf.fayad@telecom-paristech.fr

Badis Hammi
email: badis.hammi@telecom-paristech.fr

Rida Khatoun
email: rida.khatoun@telecom-paristech.fr

An adaptive authentication and authorization scheme for IoT's gateways: a blockchain based approach

Keywords: Authentication, Authorization, Internet of things IoT, Privacy, Smart City, Smart home

Security of the Internet of Things represents a field that strongly attracts academia and industry since it represents one of the main obstacles in its adoption. In this area, authentication and authorization methods holds a golden place in priority rank. Indeed, current approaches suffers from numerous limits. Moreover, generally, deployment systems use separately two methods one dedicated to the authentication and the other to the authorization, while the number of methods that combine both requirements is limited. In this work we propose an adaptive blockchain based authentication and authorization approach for IoT use cases. We provided a real implementation of our approach using Java language. The extensive evaluation provided, shows clearly the ability of our scheme in meeting the different requirements, as well as its ability in ensuring a very lightweight cost.

I. INTRODUCTION

The Internet of Thing (IoT) represents currently a part of our everyday lives and habits. This makes its evolution in exponential growth. Indeed, the number of connected devices such as surveillance cameras, refrigerators, electronic locks, connected cards, smart TVs, etc. is exploding. According to a recent Gartner study, 50 billion connected devices 1 will be deployed by 2020 [START_REF] Gartner | More Than Half of Major New Business Processes and Systems Will Incorporate Some Element of the Internet of Things[END_REF]. IoT has the potential to introduces and develop a smart world by the development of new applications in different domains like smart homes, smart health, smart cities, industry 4.0, Wireless Sensor Networks (WSN), smart agriculture, etc. [START_REF] Hammi | Internet of Things (IoT) Technologies for Smart Cities[END_REF].

In IoT, each physical or virtual device should be reachable and produce content that can be retrieved by users regardless of their location. However, It is very important that only authenticated and authorized users make use of the system. Otherwise, it will be prone to numerous security risks such as information theft, data alteration and identity usurpation. Indeed, security issues remain the major obstacle to the large scale adoption and deployment of IoT since it is highly vulnerable to attacks for multiple reasons such as: (1) most of the communications are wireless, which makes the system more vulnerable to numerous attacks such as identity spoofing, messages eavesdropping, messages tampering and other security issues, and (2) multiple types of devices have limited resources in terms of energy, memory and processing capacity, which prevent them from implementing advanced security solutions [START_REF] Tahar Hammi | Bubbles of Trust: A decentralized blockchain-based authentication system for IoT[END_REF].

IoT is not a simple technology, but a combination of multiple technologies achieving multiple use case scenarios. In many research works IoT is considered as a system-ofsystems [START_REF] Tahar Hammi | Bubbles of Trust: A decentralized blockchain-based authentication system for IoT[END_REF][4] [START_REF] Alur | Systems computing challenges in the internet of things[END_REF]. In many IoT systems and use cases, the used architecture relies on a gateway to ensure the majority of its activity. For example, the Figure 1 describes three use cases:

(1) in a WSN, all the sensors upload some requested data (e.g. temperature, water level, etc.) to a gateway (also called sink). ( 2) in a Wireless Body Area Network (WBAN) all the monitoring sensors and motion detectors send and upload their data to a gateway (also called, sink or personal server). ( 3) In a smart home scenario, all the house components interacts with a gateway which also manages the users remote access. It exists numerous other IoT use cases where a gateway is the heart of the architecture, thus, the authentication and authorization applications are performed at the gateway level [START_REF] Rahmani | Smart e-health gateway: Bringing intelligence to Internet-of-Things based ubiquitous healthcare systems[END_REF] [START_REF] Vasilomanolakis | On the security and privacy of Internet of Things architectures and systems[END_REF].

Current use of gateways represents some limits:

1 -The non heterogeneity of authentication approaches: generally, all the nodes related to a gateway use the same authentication method. For example in WSNs a Pre-Shared Key (PSK) is used to authenticate the sensors. In other use cases, if the gateway use certificate based authentication, all the nodes must implement this same method. However, in numerous cases, the network is composed of different types of devices, each with its computation and energy capacities. For example in a smart home, if some objects, such as heat sensors, can only use PSK based authentication, since symmetric cryptography is less costly than other methods [START_REF] Wang | Comparing symmetric-key and public-key based security schemes in sensor networks: A case study of user access control[END_REF], other more powerful objects, such as smart fridges and TVs can easily use public key cryptography based methods, nonetheless, they still use PSK, since the gateway impose it to satisfy all the existing objects' types. Thus, there is a need to propose an authentication mechanism that adapts to heterogeneous authentication techniques in order to ensure flexible and more resilient security.

2 -The non mobility of nodes: generally, each device is associated to one gateway. However, in some use cases, some nodes can have mobility features (a sensor which location is changed or any other mobility case). To the best of our knowledge, nodes that have mobility features from a gateway to another are not authenticated at this gateway level but using a central server/service accessible through Internet (e.g., Intelligent Transportation Systems). Nevertheless, realizing Fig. 1: IoT use cases authentication at the gateway level can be less time consuming. Moreover, relying on centralized services in an environment such as IoT where the number of devices is exploding (countable in billions) can represent a real bottleneck. Consequently, there is a need to propose a scalable security solution that allows the mobility of nodes while ensuring their authentication at the gateway level.

3-Initialization phase: in the majority of systems, if a new device is added, a physical intervention on the gateway is needed to set up and configure the credential of this new device (e.g., adding the PSK of a new sensor on the gateway). However, knowing that the number of objects is exploding, this feature represent a real brake. Hence, there is a need to propose a security solution that allows an easy integration of new devices as well as new services.

Contribution

We believe, as many researchers [3][9][10] [START_REF] Malviya | How Blockchain will Defend IOT[END_REF] that blockchains represent a very promising technology for the development of decentralized and resilient security solutions in IoT context. Therefore, in this paper we propose a blockchain based authentication and authorization approach for IoT use cases. In our decentralized approach, (1) any device can be added without any physical intervention, (2) can move freely and still be authenticated and authorized at the gateway level and (3) it meets the scalability requirements of IoT.

This paper is organized as follows. Section II describes the related works. Then, Section III exhibits the architecture and the details of our approach. Finally Section V concludes the paper and introduce our future work.

II. RELATED WORKS

There have been numerous works that tackled authentication and authorization in IoT [START_REF] Zhao | A survey on the internet of things security[END_REF][13] [START_REF] Kim Thuat Nguyen | Survey on secure communication protocols for the Internet of Things[END_REF]. Thus, in this section we describe the main known approaches.

Symmetric-key based authentication schemes are widespread since they are more suitable for constrained devices [START_REF] Park | Symmetric key-based authentication and the session key agreement scheme in IoT environment[END_REF][16] [START_REF] Bonetto | Secure communication for smart iot objects: Protocol stacks, use cases and practical examples[END_REF]. Although this solution is lightweight and fast, it does not meet all the performances requirements such as scalability and mobility of nodes.

To meet these requirements, numerous other works adopted public key cryptography [START_REF] Kothmayr | DTLS based security and two-way authentication for the Internet of Things[END_REF][19] and even used X.509 [START_REF] Cooper | RFC 5280: Internet X. 509 Public Key Infrastructure Certificate and CRL profile[END_REF] standard to ensure authentication. Indeed, Transport Layer Security (TLS) [START_REF] Dierks | RFC 5246: The Transport Layer Security (TLS) Protocol Version 1[END_REF] has been recommended by many standards specified by Internet Engineering Task Force (IETF) for security services [START_REF] Kim Thuat Nguyen | Survey on secure communication protocols for the Internet of Things[END_REF]. However, it is proven that TLS is not a wise choice with respect to the security best practices in IoT. In fact, TLS runs normally in a reliable transport protocol like TCP which is not always suitable for constrained resource devices, due to its congestion control algorithm [START_REF] Kim Thuat Nguyen | Survey on secure communication protocols for the Internet of Things[END_REF]. As a replacement for TLS in the tightly constrained environments, the Datagram Transport Layer Security (DTLS) [START_REF] Rescorla | RFC 6347: Datagram Transport Layer Security Version 1[END_REF] protocol has been proposed recently. It operates over the unreliable transport protocol i.e., UDP and provides the same high security levels as TLS. However, it still rely on public key cryptography, which suffers from the high computational cost and energy consumption and thus makes it not really suitable for numerous types of smart things.

In the last years, many works aimed the proposal of IoT security systems that rely on blockchains. Indeed, blockchain usage provides a decentralized architecture, anonymity of users if wished, tamperproof record of data transactions and highly trusted data verification [START_REF] Dorri | Blockchain for iot security and privacy: The case study of a smart home[END_REF].

Dorri et al. [23][24] propose a blockchain based architecture for IoT. Their approach relies on three interconnected blockchains: a local blockchain (private) for each use case, a shared blockchain (private) and an overly blockchain (public). Even if the solution resolve the problem of identification, it has multiple shortcomings like (1) each operation engender at least 8 network communications which can flood quickly the whole communication medium in case of high activity of nodes; and (2) the local blockchains are not distributed but centralized which is contrary to its principle because it can limit its power and availability.

Hardjono et al. [START_REF] Hardjono | Cloud-based commissioning of constrained devices using permissioned blockchains[END_REF] propose ChainAnchor, a privacypreserving method for commissioning an IoT device into a cloud ecosystem. ChainAnchor supports device-owners being remunerated for selling their device sensor-data to service providers, and allow device-owners and service providers to share sensor-data in a privacy-preserving manner. However, Its goal is the full anonymity of the participating devices and is not adapted to numerous IoT use cases where the identification is needed.

In [START_REF] Hammi | BC-Trust: A decentralized authentication blockchain-based mechanism[END_REF] the authors propose a robust, lightweight and energyefficient security protocol for the WSN systems that rely on blockchains. However, this work was proposed for OCARI [START_REF] Tahar Hammi | A lightweight mutual authentication protocol for the iot[END_REF], a very specific WSN architecture.

In a previous work [START_REF] Tahar Hammi | Bubbles of Trust: A decentralized blockchain-based authentication system for IoT[END_REF] we proposed Bubbles of Trust, an efficient decentralized authentication mechanism. This mechanism was implemented upon the public blockchain Ethereum, and aims at the creation of secured virtual zones, where devices can communicate securely.

To summarize, the majority of the existing approaches does not meet all the performances and security requirements such as the mobility of nodes and the adaptability to numerous security mechanisms.

III. TOWARDS AN ADAPTIVE AUTHENTICATION AND AUTHORIZATION APPROACH

Our approach can be applied to a huge number of IoT use cases and does not require special hardware. In this section we describe the different details related to the design and the functioning of the proposed approach. More specifically, our approach relies mainly on a the usage of a blockchain. A blockchain is defined as a distributed database (ledger) that maintains a permanent and tamper-proof record of transactional data. A blockchain is completely decentralized by relying on a peer-to-peer network. More precisely, each node of the network maintains a copy of the ledger to prevent a single point of failure. All copies are updated and validated simultaneously [START_REF] Hammi | BC-Trust: A decentralized authentication blockchain-based mechanism[END_REF] [START_REF] Nakamoto | Bitcoin: A peer-to-peer electronic cash system[END_REF].

Currently numerous works explore blockchain applications in multiple use cases in order to develop secure decentralized applications [START_REF] Dorri | Blockchain for iot security and privacy: The case study of a smart home[END_REF] [START_REF] Huh | Managing iot devices using blockchain platform[END_REF]. Some Blockchains like Ethereum and Hyper Ledger facilitate the implementation of decentralized applications without the need for the modification of the blockchain's main source code, via what is commonly called Smart Contracts (called Chaincodes in Hyper Ledger).

A. Threat model

In this section we present our threat model. The latter is similar to the Dolev-Yao model [START_REF] Dolev | On the security of public key protocols[END_REF].

1) Network model: The overall purpose of an authentication scheme is to allow multiple nodes to communicate in a trustworthy way over a non trusted network. In this work we consider a network that owns a set of devices offering and using different IoT services in a centralized or a distributed architecture. Each device communicates with a large number of other devices, however, each device depends on one or more gateways. Each gateway must hold a copy of the used blockchain. Exchanged messages pass through an unreliable and potentially lossy communication network, such as Internet. We also assume that all participants cannot be trusted. Indeed, the high number of smart things in the network, increases the risk of including compromised ones. Furthermore, the existing devices are of heterogeneous types and do not belong to the same use case. The network function consists in only forwarding packets and does not provide any security guarantee such as integrity or authentication. Thus, a malicious user can read, modify, drop or inject network messages.

2) Attacker Model: In this work, we assume that an attacker or malicious user has a total control over the used network i.e he can selectively sniff, drop, replay, reorder, inject, delay, and modify messages arbitrarily with negligible delay. However, the devices can receive unaltered messages. Nonetheless, no assumptions on the rate of the altered messages are made. Besides, the attacker can benefit from a computation power and storage larger than the implemented devices.

B. Initialization phase

Our approach relies mainly on the usage of a blockchain. Thus, when a new device is added to the network, the user that adds it must register it. This is provided by sending a transaction to the blockchain, which contains the following information about the added object: (1) the object's ID; (2) the authentication method, e.g., PSK, One Time Password (OTP), Certificate, etc.; (3) the authentication parameters e.g, the PSK, the object's public key, the object's certificate, etc.; (4) the authorizations list e.g., only upload to server IP on P ort, upload/download to/from All, upload data of maximum 10 bytes per session, etc. Except the object ID, all the parameters are encrypted as shown in the example of the block content bellow. In this paper, we focus mainly on the protocol exchanges between the objects and the gateways. The details regarding (1) how the informations are encrypted in the Blockchain and which encryption type is used, (2) the blockchain's type and choice, (3) how the gateways downloads safely the blocks and decipher them, is the subject of a future work.

C. System's functioning

First, when a device wants to establish a communication session with the gateway, it sends it a Session Establishment Request (SEReq) that contains the object's ID and its authentication parameters (e.g., PSK). When the gateway receives the request, relying on the Object ID, it downloads, from the blockchain, the block containing the parameters related to that requester object. Then, the gateway decrypts the block and according to the retrieved parameters, it triggers the authentication operation. Afterwards, a Session Establishment Response (SERep) is sent to the device to inform it whether it is successfully authenticated or not. Finally, if there is a successful authentication, then, the session establishment can be set up.

Once the device is successfully authenticated and the session is established, the gateway controls each exchange and communication of the object relying on the list of authorization downloaded within the block. Indeed, since the gateway represents the sole link between the object and all its surroundings, it can control each action outgoing/coming from/to the object.

In our approach, any existing authentication method can be used as it is designed. Thus, the SEReq parameters are secured as it is the case in the method's classical use. Nonetheless, If the authentication method requires the usage of secret information like PSK, as highlighted by Figure 2 we propose a customized SEReq format to protect against man in the middle combined to cryptanalysis attacks as bellow:

IV. EVALUATION AN DISCUSSION

A. Context and use case scenarios

As described earlier, the main advantage of our proposed approach relies in its suitability to the majority of IoT scenarios, all within ensuring an easy integration of new devices and services. In this section we evaluate our approach regarding its execution time as well as its financial cost. For this evaluation we choose two different use cases of the authentication between a gateway and an object:

1) an authentication via a PSK;

2) an mutual authentication using certificates.

Knowing that the usage of the blockchain induces an additional cost, for both scenarios, we measure the time needed for the authentication: (1) in the classical scenario, without relying on our approach; and (2) using our adaptive approach. Also, knowing that the operation of searching a block in the blockchain is feasible in a sequential method (block by block). To verify if the position of the block that owns the parameters needed for the authentication may induce to a additional cost, we use a blockchain having 1000 blocks and for both scenarios, we measure the time needed for the authentication in the following cases: (1) the parameters needed for the authentication are in the first block of the blockchain; (2) the parameters needed for the authentication are in the block 500 of the blockchain; and (3) the parameters needed for the authentication are in the last block of the blockchain (1000).

B. Evaluation framework

In order to evaluate the time consumption of our approach, we used two Virtual Machines (VMs) as end nodes. The first VM was designed as the gateway that hosts the blockchain and the second as a smart thing. Table I We are aware about the difference of performance between VMs and some of the common smart objects. We are also aware about the fact that the obtained results depends on the used language (Java) and are different when using other languages (e.g., C or C++). Nonetheless, the goal of our evaluation is the evaluation of our approach's additional cost in comparison to classical methods. Consequently, the comparison is fair since all the protocol's operations are realized on the same basis, language and material. 1) Security and performance requirements evaluation: Our approach is an adaptive scheme that allows the usage of other authentication methods. Thus, some of the security features and robustness such as integrity, confidentiality, Non repudiation, robustness against replay and spoofing attack, protection against sybil attacks, etc. depends only on the chosen scheme. Ergo, in this section we focus on the evaluation of the security and performance features discussed earlier and that must be satisfied by an adaptive authentication approach:

Scalability: our scheme relies on a blockchain, which, in turn, relies on a peer-to-peer network. It is known that peer-topeer networks are one of the best solutions to meet scalability at large scale [3][30].

Mobility of nodes: in our approach, the parameters related to the authentication and the authorization are stored in a blockchain. Since the blockchain is a decentralized system, all the gateways which are the peers that host the blockchain, host an updated version of the latter and which contains all the parameters needed to the authentication. Thus the nodes' mobility does not represent any obstacle, since any gateway can read the blockchain.

Heterogeneity of supported approaches: our scheme represents a way to extract and send the parameters needed and used by other schemes. Any method's parameters can be stored, thus, our approach supports the use of a multitude of other schemes.

Initialization phase: in order to add a new device, the user needs only to add the parameters needed for the authentication and authorization in the blockchain, which does not require any physical intervention on the gateways. Hence, we propose a very lightweight initialization approach, that brings numerous savings in comparison to other methods.

Robustness against cryptanalysis attacks: our scheme uses the other methods as they are designed. Thus, the robustness to cryptanalysis attacks are exactly the same as in classical cases. Nevertheless, we proposed a customized SAReq (described in Section III-C) where only a hash (HMAC) on the parameters is sent. Therefore, an attacker that intercepts this data, cannot reconstruct the original data, since hash algorithms are injective functions.

2) Numerical results: In this section we present the numerical results obtained upon the time consumption evaluation of our approach. As described in Section IV-A, for each use case (authentication with PSK and mutual authentication with certificate) we measured 4 values of the authentication time:

(1) without our approach, which we present as Classical case in the further results; (2) the parameters needed for the authentication are in the first block of the blockchain, presented as B-1; (3) the parameters needed for the authentication are in the block 500 of the blockchain, presented as B-500; and (4) the parameters needed for the authentication are in the last block of the blockchain, presented as B-1000.

The Figure 3.a exhibits the results obtained from the experimentation of the first use case: authentication using PSK. Each result describes the average obtained through the execution of the same scenario 200 times. Without surprise, the Classical method realizes the best authentication time with 13.13 milliseconds (ms) and a standard deviation of 0.88 ms. Then, closer is the needed block in the blockchain, better is the time needed for the authentication, getting the following times: 13.23 ms, 13.39 ms and 13.43 ms, respectively for the scenarios B-1, B-500 and B-1000. Also, the standard deviations obtained are very narrow with respectively 1.17 ms, 1.56 ms and 1.52 ms. One can note that the additional cost caused by our approach is negligible.

The Figure 3.b describes the results of the second use case: mutual authentication using certificates. As in the last experimentation, each result represents the average obtained through the execution of the same scenario 200 times. We obtained the same ranking of the last experimentation for the needed time to realize the mutual authentication with 188.60 ms, 191.37 ms, 192.15 ms and 193.62 ms, respectively for the Classical, B-1, B-500 and B-1000 scenarios. Similarly to the last use case, the standard deviations obtained are very narrow with respectively 10.51 ms, 15.84 ms, 17.11 ms and 18.87 ms. In this case also, the additional cost caused by our approach is insignificant.

Finally, the time needed to find the block in the blockchain depends on the blockchain used. For exemple, the time needed to look for a transaction in Bitcoin is not the same as for another blockchain less used, due to the number of blocks and transactions stored. However, optimization research approaches can be applied.

Regarding the financial cost related to the blockchain use, there are two cases: (1) if a private blockchain is used, then, there is no need for transaction payment. (2) if a public blockchain is used than, for each device, only one transaction is needed during the initialization phase and which contains the parameters that must be stored in the blockchain. Then, during the system's functioning, the gateways do only reading operations from the blockchain, which are free cost operations. The cost of one transaction depends on the blockchain used. However, it remains, generally, an insignificant cost. For example, if we consider Ethereum Classic blockchain. The cost of the transaction3 is about 0.058 EURO as computed by Equation 1 as it was provided in [START_REF] Tahar Hammi | Bubbles of Trust: A decentralized blockchain-based authentication system for IoT[END_REF]. Moreover, according to studies like [START_REF] Saito | How to Make a Digital Currency on a Blockchain Stable[END_REF] and [START_REF] Jacques | Cryptocurrencies, Monetary Stability and regulation[END_REF], the evolution of the cryptocurrencies rates will get more stable over time. Even better, Ethereum developers and community are working on regulating and stabilizing the amounts of fees related to smart contracts use4 [START_REF] Tahar Hammi | Bubbles of Trust: A decentralized blockchain-based authentication system for IoT[END_REF].

Consequently, considering these experimentations and results, one can conclude about the lightness and the low cost of our approach, while bringing more flexibility to the authentication system.

V. CONCLUSION AND FUTURE WORKS

Despite the numerous works aiming the proposal of new secure approaches and schemes for IoT, still the majority of works does not satisfy all the system's needs and requirements such as allowing the mobility of nodes, the usage of numerous heterogeneous methods or the easy integration of new devices and services. Hence, in this work we propose an adaptive approach that ensures the authentication and the authorization for IoT devices. Our approach relies mainly on the use of a blockchain, which makes it completely decentralized. Furthermore, it satisfies all the discussed requirements. We provided a real implementation of our approach and the results of its evaluation showed clearly its lightness and low cost.

This paper describes only the first phase of approach proposal which is related to the exchange protocol between the devices and the gateways. Thus, in our future work, we will describe the second part of the proposal which concerns the data storage in the blockchain, how it is protected and secured knowing that any user can read blockchain's block, and finally how the gateways can read this secured information.

  ====================================== \textit{SEReq} = [ID, HMAC{PSK || Nonce|| Authentication Method}, Nonce] ====================================== Once the gateway receives this type of request, it retrieves the needed authentication parameters from the blockchain according to the received object ID. Then, it computes the HMAC{PSK || Nonce || Authentication Method} using the received Nonce and the deciphered data. If the obtained HMAC 2 matches the received one, it successfully authenticates the requester device.

Fig. 2 :

 2 Fig. 2: Adaptive authentication approach: PSK use case

Fig. 3 :

 3 Fig. 3: Authentication time needed: (a) PSK use case; (b) Mutual authentication with certificates

  Cost = Number of Transactions × Transaction cost in Gas × Gas cost in ETC × ETC cost in EURO

  describes their features. The development of the authentication approach's steps was provided using Java language.

	CPU archi-	CPU operation	CPU max		Operation
	tecture	mode	speed	RAM	System
	x86_64	32-bits	2 GHz	256 MB	Debian 7.8

TABLE I :

 I Experimentation VMs' features

In the remaining of this paper, we use indifferently the terms device, thing, object and smart thing in order to refer to a connected smart thing.

Any other hash algorithm can be used, and this according to the hosting system's requirements, needs and capacity

The considered ETC value during the writing of this paper (August 2018) is 1 ETC = 11.67 EURO

https://smartereum.com/6777/buterin-expresses-concern-over-stabilizingethereum/.


Badis Hammi
email: badis.hammi@telecom-paristech.fr

Jean Philippe Monteuuis
email: monteuuis@telecom-paristech.fr

Eduardo Salles Daniel
email: eduardo.sallesdaniel@telecom-paristech.fr

Houda Labiod
email: houda.labiod@telecom-paristech.fr

ASN.1 specification for ETSI certificates and encoding performance study

Keywords: C-ITS, ETSI, Certificate, Encoding schemes, ASN.1, Performance

Cooperative Intelligent Transportation Systems (C-ITS) are gaining ground and are almost part of our everyday life. Within these environments, huge amounts of messages are exchanged. Besides, these messages should be secure in order to ensure users' privacy. Public Key Infrastructures (PKI) represent the most common security solution. Due to the vehicles speed, the communication with the PKI should be fully optimized. The European Telecommunications Standards Institute (ETSI) proposes a PKI architecture for C-ITS environments. However, unlike most of security standards as IEEE 1609.2, there is no Abstract Syntax Notation One (ASN.1) specification for the used certificates. For this reason, in this paper, we propose an ASN.1 definition for the ETSI certificate to help developers in its implementation. In addition, we provide an extensive comparative study of the different encoding schemes, applied to this proposal.

I. INTRODUCTION

During the last years, Collaborative Intelligent Transportation Systems (C-ITS) have gained momentum and will soon become essential to roads' users through the different applications they offer. therefore, such applications have evolved and become very greedy in terms of transmitted traffic and used bandwidth. Consequently, huge amounts of data and messages are exchanged continuously. Most of the exchanged messages contain critical data that should be confidential. Furthermore, numerous requested services require authentication to be accessed. To handle these security requirements, Public Key Infrastructures (PKIs) represent the most common solution.

However, using security within vehicular communications costs extra resources. Indeed, the use of wireless technologies for communication such as cellular or ITS-G5/802.11p has a strong impact on the network performance. For instance, messages' size represents a parameter that has to be seriously considered. The chosen encoding scheme has a strong impact on the size of the encoded data and on the encoding and decoding times.

In most of security standards such as IEEE1609.2 [START_REF]Ieee standard for wireless access in vehicular environments-security services for applications and management messages[END_REF] and X509 [START_REF] Cooper | Internet x.509 public key infrastructure certificate and certificate revocation list (crl) profile[END_REF], an Abstract Syntax Notation One (ASN.1) specification, a chosen encoding scheme of the described protocol and the used structures are provided. The goal of ASN.1 is the unicity of implementations through the restriction of interpretations and misunderstandings of the described standards and protocols. Nonetheless, multiple structures of European Telecommunications Standards Institute (ETSI) standards are not defined in ASN.1. ETSI certificate [7], a major component and player of security system is one of these non defined structures. Hence, in this paper we proposed an ASN.1 definition of the ETSI certificate. Beyond this proposal, we provided an extensive experimental study of the different encoding schemes applied to this use case. To the best of our knowledge, our work represent the first study that compares the performances of such a number of encoding schemes in such a context. Consequently, the contributions of this work are: (1) the restriction of wrong interpretations and misunderstandings of the ETSI certificate structure. Indeed, the definition of an ASN.1 structure for the ETSI certificate will help developers to follow the same constrictions and principles, accomplishing the ETSI standard policy; (2) providing a comparative study that allows the usage of the optimal encoding scheme, which allows best performances; and (3) making easier extensions on the certificate structure.

The rest of this paper is organized as follows: in Section II, ASN.1 language description is provided, as well as its different encoding schemes. Section III gives an overview of the related works. Section IV describes our ASN.1 proposal for the ETSI certificate and the followed experimental study that aims the comparison of encoding schemes. Section V discusses the obtained results. Finally, SectionVI concludes the paper and introduces our future works.

II. ASN.1 AND DATA ENCODING

A. ASN.1 definition and utility

Abstract Syntax Notation One (ASN.1) is a standardized language used to describe and to specify, in an abstract way, data-structures, independently of the used platform and the implementation language. Actually, it exists numerous compilers that automatically translate ASN.1 structures into other language's syntax. Besides, in order to represent or store ASN.1 data-structures as hexadecimal or binary values, the use of ASN.1 encoding rules is needed. The latter are also used for the exchange of abstract data in network computing, where each ASN.1 structure becomes a protocol data unit (PDU) and is encoded in a determined number of bytes.

An ASN.1 data-structure can be composed of multiple ASN.1 structures. Thus, the resulting encoding will be the concatenation of the encodings realized on all the structures composing the root ASN.1 definition. The receiver is required to have the ASN.1 definition, in order to be able to decode the structure.

B. Encoding schemes

Numerous encoding rules for ASN.1 exist, e.g: BER, DER, PER, and XER. The latter aim to define a data representation, able of being transmitted as a transfer syntax. In other words, the encoding rules define how an ASN.1 structures are encoded into byte array forms, in order to be transmitted.

The encoding rules follow a defined parametrization called Type-Length-Value (TLV) as follows: (1) Type tag determines the ASN.1 element that is being encoded, i.e. SEQUENCE, CHOICE, INTEGER, etc. For example, the Type tag of SEQUENCE structure is '30' H ; (2) Length tag is build by computing the length of the Value field; (3) Value tag is the actual value of the specific structure or field. In the following, we describe the main ASN.1 encoding schemes.

1) Basic Encoding Rules (BER): The ASN.1 Basic Encoding Rules (BER) give one or multiple ways to represent any ASN.1 structure as an octet string. Its encoding rules follow the TLV policy and operate according to three methods: (1) Primitive with definite-length encoding; (2) Constructed with definite-length encoding; and (3) Constructed with indefinitelength encoding. Simple non-string types employ the primitive with definite-length method; structured types employ any constructed method; and simple string types employ any methods, but, depending on whether the length of the value is known or not; types derived by implicit tagging employ the method of the underlying type. Finally, types derived by explicit tagging employ the constructed methods [START_REF]ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)[END_REF].

2) Distinguished Encoding Rules (DER): The Distinguished encoding rules (DER) represent a subset of BER. These encoding rules are one of the most popular encoding formats, since they are used to encode and to store X.509 certificates in files [START_REF]ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)[END_REF]. Unlike BER, DER encodings have a unique encoding for each ASN.1 value. By the fact that DER is a subset of BER, one could BER-decode from a DER encoding but not vice versa. This is due to the fact that for the same ASN.1 value, BER have different encodings.

3) Packed Encoding Rules (PER) and Unaligned PER (UPER ): Packed encoding rules, BASIC-PER or just PER encoding rules rise from BER encoding style, but more compacted. The aim of compacting the encodings occurred by the fact that BER encodings frequently have possible redundant octets. For instance, Boolean value has a fixed length. Thus, if we suppress the 'Length' of the TLV, one could still decode it correctly as we know the type of value we are dealing with, through the value of 'Type'.

When a structure is encoded, one obtains an array of bytes. However, not all the encoded structures always represent a complete byte array value. For example, a structure represented in 6 bits, one can represent it as a byte (8 bits), or just as a bit array of length 6. The Aligned PER version follows the octet-aligned-bit-fields policy and will insert padding bits to the unfulfilled octets, while in the Unaligned PER (UPER) version, no padding bits are inserted [4].

4) Octet Encoding Rules (OER): OER represents a mix of BER and PER. More precisely, OER follows the octet-aligned-bit-fields policy, as Aligned PER. However, it removes 'Type' and 'Length' tags [6].

5) Canonical Encoding Rules (CER): As DER, CER encoding rules, are a subset of BER. These encoding rules produce an unequivocal transfer syntax for data structures described by ASN.1. Whereas BER gives choices, such as how data values may be encoded. CER -as DER-selects just one encoding from those allowed by the basic encoding rules. Eliminating, thus, the rest of the options [START_REF]ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)[END_REF]. CER and DER differ in the set of restrictions that they place on the encoder. The basic difference between them, is that DER uses definitive length form and CER uses indefinite length form.

6) XML Encoding Rules (XER): XML encoding rules (XER) represent verbose representations of ASN.1 structures. These encoding rules were developed as a link between XML and ASN.1. They are specially useful for interactions with a system configured just to understand XML. XER encoding rules attempt to bridge the gap by providing a textual encoding of defined data structures using ASN.1 notation. Nevertheless, it does not provide any user control over the produced style of XML [5]. In the latter, the 'Type' tag is represented as the name of the elements (SEQUENCE, CHOICE,...).

EXTENDED-XER (E-XER) is a variation of BASIC-XER encodings. They increase verbosity by specifying a set of XER encoding instructions associated with ASN.1 types. In absence of XER encoding instructions, an EXTENDED-XER encoding differs from a BASIC-XER encoding only because it provides more encoders options.

III. RELATED WORKS

Several studies were been provided in order to compare performances of encoding schemes. However, few ones have targeted the ITS and vehicular environments.

Darren et al. [START_REF] Mundy | Comparing the performance of abstract syntax notation one (ASN.1) vs eXtensible Markup Language (XML)[END_REF] and authors in [START_REF] Inc | Alternative Binary Representations of the XML Information Set based on ASN[END_REF], have realized a performance comparison between ASN.1 and XML. The conclusion is that XML is not an effective solution for providing a human readable and easy to parse data representation at the cost of bigger encoding length. Therefore, this cannot be considered as a practical option for ITS communications where the length of encoded data needs to be as small as possible.

Bittl et al. [START_REF] Bittl | Performance Comparison of Data Serialization Schemes for ETSI ITS Car-to-X Communication Systems[END_REF] proposed a performance comparison of encoding schemes for C2X communications based on ETSI standards. In their experiment, the computation time, the memory footprint and the encoded data length, were the three considered parameters of the performance evaluation for each encoding scheme. The evaluated data structure was ETSI Secured Message [7], considering the following encoding schemes: binary, Protocol Buffers (Protobuff) [2], Efficient XML Interchange (EXI) [1] and ASN.1. The authors concluded that ASN.1 encoding outperformed Protobuff and EXI encodings but not binary encoding. Besides, ASN.1 encoding scheme has better results for data length. However, this paper does not provide any details about programming language and especially on how the certificate and secured message have been defined for each syntax, which brings questions about structure optimizations. Furthermore, they used only Unaligned PER ASN.1 encoding scheme, which is restrictive considering the number of existing ASN.1 encoding schemes, especially, because UPER is not the most optimal one.

IV. PROPOSAL OF ASN.1 STRUCTURE FOR ETSI CERTIFICATE

In this section we present and detail our ASN.1 proposal for the ETSI certificate and the performance study that we conducted in order to compare the different encoding schemes. (1) time restrictions and (2) region restrictions. • Signature: covers all the mentioned fields and performed using the private verification key of the authority described in SignerInfo. The different structures of ETSI TS 103097 standard are described by the meaning of a syntax derived from IETF RFC 2246 [START_REF] Dierks | The tls protocol version 1.0. IETF[END_REF] and from IEEE 1609.2-2012 [START_REF]Ieee standard for wireless access in vehicular environments-security services for applications and management messages[END_REF]. However, due to this syntax ambiguity, the implementation of these structures can lead to numerous interpretations. In other words, multiple implementations can be derived from this description (even those that do not respect the standard ). Our motivation behind this work is the proposal of an ASN.1 structure that allows a correct implementation of the certificate.

A. ASN.
Listing 1 contains our ASN.1 proposal for the ETSI certificate. This proposal accurately reflects the one described by ETSI TS 103097 except for few details. These changes were provided in order to secure the generation and use of the certificate. Indeed, due to the flexibility of these structures, they are subject to erroneous generation or to manipulation for malicious purposes. These changes are as follows:

(1) According to the ETSI TS 103097 standard [7] the signerInfoType can be one of the following: (1) self; (2) certificate digest with SHA256; (3) certificate digest with other algorithms; (4) certificate; or (5) certificate chain. However, in the section dedicated to this structure, it is clearly explained that this type have to be only one of the three following : (1) self; (2) certificate digest with SHA256; or (3) certificate digest with an other algorithm. In order to avoid that users choose wrongly unauthorized types, in our proposal, we restricted the choice of the signerInfoType to only authorized types.

(2) [7] describes SubjectAttributes as a vector of variable length which can contain different types of SubjectAttributes. However, it is clearly explained further, that this structure does not support two SubjectAttributes of the same type. Furthermore, a verification key and an assurance level Sub-jectAttribute are mandatory. In order to be compliant with these conditions and to avoid wrong SignerInfo generations, a sequence of multiple SubjectAttributes is defined, including the verification key and assurance level SubjectAttributes as mandatory and the rest as optional.

(3) In the last structure, according to the type of the certificate, an ITS Application IDentifier List (ITS AID List) or an ITS AID Service Specific Permissions (SSP) List is defined, but never both. Even though, as it is defined in the standard, it is possible to generate both of them. To remedy this problem, we define, in the list of SubjectAttributes an attribute called ITSList which consists of a choice between the two different list structures. (4) ValidityRestrictions field, should contain a time Valid-ityRestriction and can contain a region ValidityRestriction. The certificate can comprise multiple ValidityRestrictions in a vector of variable length. Nonetheless, it could not comprise two time restrictions. But, the structure proposed by the standard does not fullfill this condition. To remedy this issue, we define the ValidityRestrictions field as a vector of variable length which can contain only one time ValidityRestriction. It is a choice between all the restrictions of type time. In addition, the vector can comprise unlimited number of region restrictions.

(5) In the last structure, a region Validity Restriction could be of different types, such as: circular, rectangular or polygonal. The rectangular region is defined as a composition of multiple rectangles, at least one and maximum of six. However, the proposed structure does not guarantee this condition. Our solution remedy this problem, by requiring at least one rectangle as well as limiting the maximum number of rectangles to six. (6) According to [7], different compression modes for Elliptic Curve Cryptography (ECC) Points are used. However, the following restrictions have to be followed: For the Verification Key and the Encryption key, x -coordinate -only type should not be used; In Signature field, the r field is an ECC Point and does not support uncompressed type; finally, the reconstructionValue has no constraints in terms of type of compression. To avoid confusion and wrong generations, in our solution, we propose the usage of three ECC Point for i in 1 : X do

SAVEENCODINGSIZE(EncS[j])

8: end procedure of generated certificates, defined by the X parameter. Thus, X takes the following values: 10, 10 2 , 10 3 , 10 4 , 10 5 and 10 6 . Consequently, we realized six experimentations, each realizes encoding and decoding following 10 encoding schemes.

From the receiver side, as described by Algorithm 2, the station decodes each received certificate. Then, For each encoding scheme, it stores the decoding time. We are aware about the difference of performance between computers such as those used in our experimentations and real On Board Units (OBU). We are also aware about the fact that the obtained results depends on the used language (Java) and are different when using other languages. However the goal of our study is the comparison of the different encoding schemes. Consequently, the comparison is fair since all encodings and decodings are realized on the same basis, language and material.

V. EXPERIMENTAL RESULTS AND DISCUSSION

In this section we present the different results that we obtained through our evaluations. The latter covers: (1) encoding time, (2) decoding time, (3) certificate' size and (4) encoding and decoding speeds. For each metric, we compare the obtained results of ASN.1 encodings with Binary, the actual used encoding. Knowing that our material is powerful compared to the one used on board of vehicles, we consider an accuracy of at least 10 -8 , in order to show differences that can occur in a limited material. 1.a describes the evolution of the encoding times sums 2 , over the different realized experimentations, for each different encoding scheme. We can note that, (1) for number of generated certificates taken between 10 and 10 3 , the sum of the different encoding times is very close. (2) From 10 3 to 10 5 the differences between the encoding times begin to be shaped.

(3) Finally, from 10 5 and up, we obtain two groups, XML encodings group and the rest. The second group contains close values following the next ranking (the first has the shortest encoding time, thus the best one): (1) COER, (2) Binary, (3) OER, (4) UPER, (5) DER, (6) BER, (7) PER, (8) CXER, (9) XER, (10) EXER.

For more precision on the obtained results, Table I describes the average, the variance and the standard deviation (SD) of encoding time, decoding time and size of the generated certificates for all the used encoding schemes. The first 3 columns describe statistics on the obtained encoding time as follows: (1) COER have 0.01405544 milliseconds (ms) of average, 0.0004534607 of variance and 0.02129462 ms of SD.

(2) Binary, slower than COER with 0.00427482 ms, thus having an average of 0.01833026 ms, 0.0006636195 of variance which represent the biggest variance after XML encodings (XER, CXER and EXER) and DER, and finally 0.02576081 ms of SD. (3) OER with 0.01834905 ms, thus, slower with only 0.00001879 ms than Binary. (4) UPER with 0.01918138 ms of average encoding time, thus, slower than Binary with 0.00085112 ms. A variance of 0.0002978974, and an SD of 0.01725971 ms. UPER has the smallest obtained variance and SD values. Consequently, we can conclude that UPER is the most stable for encoding. (5) DER with 0.02054847 ms of average (0.00221821 ms slower than Binary), 0.001949473 of variance and 0.04415283 ms of SD. The latter are the biggest obtained values, leading DER to be the most unstable encoding scheme. (6) BER, very close to DER with 0.02057498 ms of average, 0.00224472 ms slower than Binary. (7) PER, with 0.02144488 ms of average time, thus 0.00311462 ms slower 2 Since the messages are sent continuously by an OBU, we believe that using the sum for comparison is more explicit for highlighting times' differences than the average than Binary. (8) CXER, having 0.02967197 ms of average time, thus, 0.01134171 ms slower than Binary. ( 9) XER, slower than Binary with 0.01700968 ms by having 0.03533994 ms of average. (10) Finally, EXER, with 0.04752311 ms of average time (0.02919285 ms slower than Binary).

Even if the interval composed by the SD [Average -SD, Average + SD] is very narrow, we can not have an accurate idea of the obtained encoding times values. Thus, Figure 2.a describes the boxplot realized on the encoding time values of the experimentation involving the generation of 10 6 certificates. For clarity purposes, we focus only on the small interval [0, 0.1] ms, which includes more than 75% of all values. A boxplot is a statistical graphical representation, where, (1) the minimum, (2) first quartile, (3) median, (4) third quartile, and (5) the maximum of a statistical population. Thus Figure 2.a highlights where most of encoding times values are concentrated.

B. Decoding Time

Figure 1.b describes the evolution of the decoding times sums, over the different realized experimentations, for each different encoding scheme. We can note that, (1) when the number of generated certificates is between 10 and 10 3 , the sum of the different decoding times is almost invariant. (2) From 10 3 to 10 5 the differences between the decoding times begin to be shaped. (3) Finally, from 10 5 an up, we obtain, contrarily to encoding times case, a clear ranking of the different sums.

The 5 th , 6 th and 7 th Columns of Table I describe the average, variance and SD of the obtained decoding times. One can note that the obtained ranking is different from the ranking of encoding times: (1) COER keeps the first place of the ranking with an average time of 0.01549953 ms, which means 0.028881 ms shorter than Binary. (2) DER, with 0.02232729 ms of average time (0.02205324 ms shorter than Binary). (3) OER, having 0.02283728 ms, thus 0.02154325 ms less than Binary. (4) UPER, having 0.02672955 ms of average (0.01765098 ms less than Binary). It has a variance of 0.0004372456 and 0.02091042 of SD. As in the case of encoding, variance and SD values are the smallest obtained, 6) PER, having 0.03450128 ms of average time. Which means 0.00987925 less than Binary. (7) Binary, with 0.04438053 ms of average time, having a variance of 0.02209007 and an SD of 0.1486273 ms. We can note that this decoding time is worst than all ASN.1 schemes, except XML ones. (8) CXER, with 0.08626314 ms of average time, which means 0.04188261 ms more than Binary. (9) XER, having 0.09933497 ms of average (0.05495444 ms more than Binary). Finally (10) EXER with 0.18197 ms of average time. Thus, 0.1375895 ms more than the reference encoding.

Figure 2.b describes the boxplot realized on the decoding time values of the experimentation involving the generation of 10 6 certificates. For clarity purposes, we focus only on the small interval [0, 0.1] ms, which includes more than 75% of the values.

C. Certificate's size

The last 3 columns of Table I

D. Encoding and decoding speeds

In this section, we discuss encoding and decoding speeds of the different encoding schemes. A speed is calculated according to the average values using the equation Speed = δsize δtime . If we sort these speeds in order to get a ranking of how fast are the different schemes, we obtain the following ranking. For encoding: (1) To summarize, according to needs, the choice of the encoding scheme could be different. Indeed, COER realizes the best encoding and decoding times, UPER realizes enormous size savings. We can also note that XML encodings are very fast comparing to other encodings but completely not adapted to this use case.

We recall that the experimentations were realized on powerful computers compared to those used on board of vehicles. Thus, in real OBUs, values' differences are more important than those we obtained. However, the comparison still fair, since all encodings and decodings are realized on the same basis, language and material.

VI. CONCLUSION AND FUTURE WORKS

For security purposes, the main transmitted ETSI ITS messages include sender's certificate. Generally, security standards have their own ASN.1 specifications, e.g. IEEE 1609.2 certificate, in order to make easy their implementation and avoid their wrong understanding. However, currently, there is no existing ASN.1 definition for ETSI certificates. For this reason, in this paper we proposed an ASN.1 definition for the ETSI certificate as described in the standard ETSI TS 103097 [7]. This proposal accurately reflects the one described by the standard and allows a secure generation of the certificate. Indeed, due to the ambiguity of the used description language, the described structures are subject to erroneous generation or manipulation.

Beyond this proposal, we provided an extensive study of the different encoding schemes. To the best of our knowledge, it represents the first study that compares the performances of numerous ASN.1 encoding schemes and compare them to Binary encoding scheme in a C-ITS context. This study proves clearly that some ASN.1 encoding schemes are more performant than Binary encoding scheme and their application enhance the networks' performances.

For future works, at a short term, we plan to submit our ASN.1 definition to ETSI in order to be used for the standard description. We also intend to specify an ASN.1 structure for the ETSI secured message and to provide a performance study on which encoding could be the most suitable for it. At a long term perspective, we plan to provide an experimental implementation of the described structures, in a real C-ITS environment and to provide an extensive analysis of their usage.

  [cert.encoding]) 5: end procedure

Fig. 1 :

 1 Fig. 1: Evolution of the sum of: (a) Encoding times; (b) Decoding times

Fig. 2 :

 2 Fig. 2: Boxplot of: (a) Encoding time; (b) Decoding Time, (c ) Size

  1 certificate ETSI certificate is described by the standard ETSI TS 103097 [7]. It is composed of six principal structures : SignerInfo: contains relevant information about the authority signing the certificate. This field is needed in order to identify the signer when checking the signature of the certificate.

	• Version: represents the version of the certificate, currently
	version 2.
	-The reconstruction value containing an ECCPoint (in
	the case of using implicit certificates).
	-The assurance level associated to the certificate.
	-The list of Specific Service Permissions (SSPs) as-
	sociated to the certificate

• • SubjectInfo: specifies the type of the subject owning the certificate, e.g. ITS station (ITSS) or PKI authority and its name (subject name). • SubjectAttribute: comprises data used by security functions and includes: -The verification public key used to generate Elliptic Curve Digital Signature Algorithm (ECDSA) signatures. -The encryption public key used for the Elliptic Curve Integrated Encryption Scheme (ECIES) encryption. • ValidityRestriction: specifies the validity of the certificate. Two types of validity restriction are defined in this field:

TABLE I :

 I Statistics (Average, Variance and Standard Deviation) of the obtained results with 10 6 certificates

	A. Encoding Time
	Figure

  describe statistics of the obtained size values. Figure 2.c describes the boxplot realized on the size values of the experimentation involving the generation of 1 million certificates. From these results we can conclude the following ranking: (1) UPER, with 187.3701 bytes of average size, thus, smaller by 13.1263 bytes from Binary. (2) PER, having 192.3701 bytes of average size and thus 8.1263 bytes smaller than Binary. (3) COER and OER with 198.3701 bytes of average size, 2.1263 bytes smaller than the reference. (5) Binary with 200.4964 bytes of average size. (6) DER and BER, having 251.0994 bytes of average size, thus, 50.603 bytes more than the average size of Binary. (8) and very far, CXER with 1496.422 bytes of average size, having 1295.926 bytes more than the average size of Binary. (9) EXER with 1880.13 bytes. Consequently, it has 1679.634 bytes more than the reference. Finally (10) XER with 1924.137 bytes, which means 1723.641 bytes more than the reference.

www.oss.com/asn1/products/asn1-java/asn1-java.html

ACKNOWLEDGMENT

This work is part of SCOOP@F project. SCOOP@F is a nationwide deployment project, led by the french government and involving numerous industrial partners (e.g. French car manufacturers: Renaults, PSA), road management companies (e.g. SANEF) and research institutions (e.g. Telecom Paris-Tech, Cerema). This is the largest experiment in Europe, with the deployment of approximately 3,000 intelligent vehicles over 2,000 km of connected roads.

structures, one for each described type.

Listing 1: ASN1 definition of the ETSI certificate

Certificate103097 DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS Uint8, Uint16, HashedId8, Time32, TwoDLocation, CircularRegion, Duration, RectangularRegion, HashAlgorithm, SubjectAssurance, SymmAlgorithm FROM IEEE1609dot2BaseTypes {iso(1) identified-organization(3) ieee(111) standards-association-numbered-seriesstandards (2) wave-stds (1609)dot2( 2) base (1) We consider the case of a C-ITS environment, in which two ITSS communicate. Within a communication, a message is encoded by the first station, transmitted and finally decoded by the second one. For authentication purposes, the message contains the sender's certificate. Knowing that certain messages are sent extensively and periodically over a wireless network characterized by its components' high speed, it is very important to choose the optimal data encoding scheme for transmission. To that aim, we realized an extensive experimental campaign that study and compare the different encoding schemes. The latter are : Binary in BigEndian form, PER, UPER, DER, BER, OER, COER, XER, CXER and EXER. To the best of our knowledge, this work is the first that aims to compare all these encoding schemes in a cooperative ITS use case. This study concerns only the ETSI certificate. It considers only the encoding of certificate, without taking into account the structure of the message (secured messages) including this certificate.

For our experimentations, we used two computers; sender and receiver. Both have the same technical features, namely Intel R Xeon R CPU E5-1607 v3 @ 3.10GHz (quad-core) with 8 Giga bytes of RAM. The implementation of the described ASN.1 structure was realized using OSS Nokalva compiler 1 . The latter generates also the Java code of the conceived certificate and provides Java libraries that support all the ASN.1 encoding rules. Consequently, we can also encode and decode the created Java objects. For detailed scenarios, as described by Algorithm 1, the sender generates a random certificate. The randomization covers all the fields of the certificate. After, the generated certificate is encoded sequentially with the mentioned encodings schemes( Binary, PER, UPER, DER, BER, OER, COER, XER, CXER and EXER). For each encoding, the size of the encoded certificate as well as the time of the encoding are stored. In order to get accurate results and deeply feature encodings from time and size perspectives, we realized numerous experimentations by varying, the number